Amazon API Gateway cost vs self-hosted Apache APISIX: where the break-even sits
Amazon API Gateway bills per call, so its cost rises with traffic, while a self-hosted Apache APISIX deployment carries mostly fixed costs for compute, etcd, load balancing, monitoring and the engineers who run them. A finance or platform lead facing a renewal or a steadily growing API Gateway invoice should expect the break-even to depend on one number: the monthly call volume across every API, stage and region. No figure in our research gives the current AWS rate for REST, HTTP or WebSocket calls, the charges for caching by the hour, or the data transfer rates, so pull those from the AWS pricing pages for your region and from your own usage reports before comparing anything.
The trade-off runs in one direction as volume grows. At low volumes, the per-call model is usually cheaper because you pay nothing for idle capacity and no one has to patch a gateway. As volume climbs, the fixed side of the ledger becomes the cost to beat: the nodes that must stay sized for peak traffic, a highly available etcd cluster, load balancers, log and metrics storage, and the share of platform engineering time spent on upgrades. APISIX's three deployment modes, including standalone mode that reads routes from a file and needs no etcd, change how large that fixed base is, so model each mode separately.
Build the comparison from components, not from a single headline rate. List every cost you would carry: compute for the data plane at peak plus headroom, the control plane, etcd, storage, cross-zone and egress traffic, monitoring, certificates, and on-call coverage. Then ask your vendor or integrator for a written quote that separates one-time work such as migration and hardening from recurring work such as upgrades and support. Also check whether features you rely on, such as caching or AWS-native authorizers, need replacement plugins with their own run cost. The break-even point is where the modeled self-hosted monthly cost falls below your measured Amazon API Gateway bill, and it moves whenever your traffic pattern changes.
Which cost components change between the two options
This table compares each cost component of Amazon API Gateway with the matching component of a self-hosted Apache APISIX deployment, and marks whether each one is one-time or recurring. Read the commercial column for what AWS meters and the self-hosted column for what your team pays for directly. No prices are given, so use the rows to build your own inventory before requesting quotes.
| Cost component | Amazon API Gateway (metered by AWS) | Self-hosted Apache APISIX (your infrastructure and staff) |
|---|---|---|
| API calls by protocol (REST, HTTP, WebSocket) | Billed per call, with REST, HTTP and WebSocket APIs priced on separate tiers. Recurring and scales with traffic. | No per-call fee. Cost scales with the gateway nodes needed for peak throughput, so it is recurring infrastructure. |
| Caching | Cache capacity is billed by the hour for each stage. Recurring for as long as caching is enabled. | No separate cache fee. Use node memory or a cache you already run. Confirm APISIX caching plugins for your use case. |
| Data transfer | Outbound data transfer from AWS is billed separately. Recurring and driven by response size. | Depends on where nodes run. Cross-zone or egress charges from your cloud or data center links are recurring. |
| Gateway compute | Included in the per-call charge. Nothing to size or patch. | APISIX nodes on VMs, containers or Kubernetes. Sized by throughput and latency targets. Recurring hosting cost plus one-time sizing and load testing. |
| etcd (configuration store) | Not applicable. Configuration is managed by the AWS control plane. | Three-node etcd cluster in traditional or decoupled mode, or no etcd in standalone mode. Recurring hosting, backup and monitoring. |
| Load balancers | Included in the managed endpoint. Custom domains and certificates handled by AWS. | Network or application load balancer in front of APISIX nodes. Recurring cloud or appliance cost, plus one-time setup of TLS and health checks. |
| Monitoring and logging | Access logs and metrics billed through AWS logging and monitoring services. Recurring and driven by log volume. | Prometheus, Grafana or log storage you operate. Recurring storage and licensing-free tooling, plus staff time to tune alerts. |
| Implementation and migration | Export and rebuild effort for stages, authorizers, usage plans and keys. One-time, mostly internal or partner effort. | Platform build, plugin mapping, authentication setup and cutover testing. One-time, paid to internal staff or an implementation partner under a written scope. |
| Support and upgrades | Covered by the AWS service model. Upgrades happen without your scheduling. | No vendor support fee in the open-source license. Upgrades, security patches and CVE tracking are recurring staff work unless you buy a support contract from a provider. |
| Internal skills and operations | Minimal platform operations. Recurring staff effort is mainly configuration and IAM policy. | Recurring on-call, capacity planning, etcd operations and incident response. Confirm skills exist in-house or budget for training. |
How per-call tiers and self-run nodes bill differently
Amazon API Gateway bills REST, HTTP and WebSocket APIs on different meters, so a single request-count figure rarely explains the invoice. REST and HTTP APIs are charged per API call at tiered rates, while WebSocket APIs add a connection-time component and a per-message component. Caching is billed separately by the hour for the cache size you provision, and data transfer out of AWS is billed on top of both. Confirm the current rates for your Region on the AWS pricing page, because the tiers and the cache sizes change over time.
- REST and HTTP calls: Count requests per month per API and note which tier each volume falls into, since the rate drops as volume rises.
- WebSocket connection minutes: Extract connection duration for each API, because long-lived sockets accrue cost even when little data moves.
- WebSocket message counts: Pull inbound and outbound message totals separately, as each is metered.
- Caching by the hour: Record the cache capacity you enabled per stage and the hours it ran, including stages you forgot were active.
- Data transfer out: Separate traffic leaving AWS from traffic that stays inside the same Region, because the rates differ.
Before comparing, check your bill line by line against these five meters so the comparison uses the same volumes on both sides.
Apache APISIX is licensed under Apache-2.0, according to its GitHub repository, so the software itself carries no license fee. Your recurring costs move to the infrastructure and the people who run it. A typical deployment runs APISIX data plane nodes sized for throughput, an etcd cluster when you use traditional or decoupled mode, load balancers in front of the nodes, and monitoring. In standalone mode, APISIX reads its configuration from a YAML or JSON file and does not need etcd, which changes the fixed footprint.
- Gateway nodes: Size them for peak requests per second, connections and any WebSocket concurrency, then add headroom for failover.
- etcd cluster: Required in traditional and decoupled modes, and it adds its own instances and storage to run.
- Load balancers: Usually a cloud or hardware load balancer in front of the nodes, billed or licensed by its own rules.
- Monitoring and logs: Metrics, log storage and alerting, which often grow with request volume.
- Staff time: Platform engineers who patch, upgrade and respond to incidents, and this is often the largest recurring line.
APISIX 3.19.0 was released on September 28, 2026, according to the APISIX downloads page, and the page does not mark any release as long-term support. Ask your team which version policy you will follow and budget upgrades accordingly.
A fair comparison puts both billing models on the same traffic profile over the same period. Start with a month of real AWS billing data and map each meter to a self-hosted equivalent: requests to node capacity, WebSocket minutes and messages to concurrent connections, cache hours to memory on the nodes, and egress to your network costs. The result is an illustrative model, not a quote, and its accuracy depends on how well your own volumes are measured.
- Use a full billing cycle: Traffic peaks and seasonal swings change the break-even point, so one quiet month can mislead.
- Separate fixed and variable costs: Nodes, etcd and load balancers are largely fixed, while per-call and egress charges scale with use.
- Include one-time work: Migration, testing, hardening and documentation are paid once, and the model should amortize them explicitly.
- Model growth: Run two or three volume scenarios to see where self-hosting starts to pay off for your workload.
- Ask for written scope: A DeployOpen quote follows a written scope, so list the APIs, environments and WebSocket use before requesting one.
Record every assumption in the model so your finance and security teams can review it.
The Apache-2.0 license means APISIX has no license fee and no per-call charge from the project. Support is a separate question. The community provides documentation and project channels, while commercial support comes from third parties such as API7.ai, which describes its API7 Enterprise offering on its website. Whether you buy support, use an internal team or engage an implementation partner is a cost decision that belongs in the model, not a licensing requirement.
- Community versus paid support: Decide which incidents your team can resolve alone and which need a vendor response time.
- Version currency: Plan a regular upgrade cadence, since no release is marked long-term support on the downloads page.
- Plugin ownership: Custom plugins written in Lua or through plugin runners need owners who maintain them after each upgrade.
- Third-party modules: Confirm which plugins your use case depends on are part of the open-source build and not in a commercial add-on.
- Security reviews: Budget time for patch review and vulnerability tracking across the gateway and etcd.
Ask the support provider for its response commitments in writing and compare them with the internal hours your team can realistically commit.
What moves the comparison most
Six drivers decide whether self-hosting Apache APISIX costs less than Amazon API Gateway for a given workload. Most of them change the per-call side of the bill and the node count, so check each one against your own traffic before comparing totals.
Call volume and peak ratio
Per-call pricing scales linearly with requests, so steady high volume pushes the managed bill up in a straight line. Self-hosted cost moves in steps, set by how many APISIX nodes you need to absorb peak load with headroom. A high peak-to-average ratio narrows the gap, because you pay for managed calls only when they happen but must provision nodes for the busiest minute. Ask your team for hourly request profiles for at least one full business cycle before building a model.
Number of APIs and environments
Each stage, account and environment adds a separate managed footprint, while a self-hosted gateway can serve many routes from one control plane. Development, test and staging tiers add cost on the managed side mainly through their traffic, and on the self-hosted side through extra nodes and etcd clusters. Count APIs, stages and regions in your inventory, because this number often changes the answer more than raw traffic does.
WebSocket connection use
WebSocket APIs are billed on connection time and messages, so long-lived connections and chatty clients raise the managed bill in ways that REST call counts do not show. Self-hosted APISIX handles WebSocket proxying as a standard protocol, so cost there depends on concurrent connections per node and memory headroom. Measure concurrent connections and message rates separately, and confirm the billing dimensions in the current AWS pricing pages before you extrapolate.
Caching hit rate
Managed caching is billed by the hour for the cache size you provision, whether or not it is full, so low hit rates make it expensive per useful response. A self-hosted gateway can cache in memory on nodes you already run or in a separate cache you size yourself, so the cost is driven by node memory and cache engine operations. Measure your hit rate per route before deciding, because a route with a low hit rate may not justify any cache at all.
Cross-region and on-premises traffic
Data transfer charges apply when traffic leaves AWS or crosses regions, and they grow when clients or back ends sit in other clouds or data centers. Running APISIX close to those back ends can reduce transfer on the managed side, but it adds nodes you operate in each location. Map where clients, upstreams and logs sit, then ask AWS for transfer charges for those specific paths rather than assuming a flat rate.
Skills on the platform team
Self-hosting moves operations work to your staff: upgrades, certificates, etcd health, backups, scaling and incident response. Teams already running NGINX, Kubernetes and etcd absorb this at lower cost than teams starting from scratch, and that staff time is a recurring cost that belongs in the model. Count the hours your engineers already spend on the current gateway and ask whether a DeployOpen retainer or in-house hires would cover the gap.
How to build the comparison with your own numbers
This sequence turns your current API Gateway bill and measured traffic into a side-by-side cost model for self-hosted Apache APISIX, so the break-even call volume comes from your own environment rather than from assumptions. Every line is traceable to a report, a load test or a written quote.
Export call counts per API and protocol
Pull request counts from the API Gateway usage reports and CloudWatch metrics for each stage, grouped by API and by protocol: REST, HTTP and WebSocket. WebSocket connection minutes and messages should be recorded separately because they are metered differently from request calls. Ask your AWS account team or review the billing and cost allocation data to confirm which metric maps to which billed unit. The step is done when you have a monthly table of calls per API, per protocol and per stage for at least one representative quarter, with peaks noted.
Record caching and data transfer usage
Capture which stages have caching enabled, the cache capacity configured for each, and the hours those caches run, since cache charges accrue by the hour regardless of traffic. Then pull outbound data transfer from the billing reports for API traffic, separating traffic to the internet from traffic to services in the same region. Note any large response payloads, because they drive transfer cost. The step is done when each stage has a cache line item and a data transfer line item tied to actual billed amounts.
Price the current AWS bill at published rates
Using the current AWS pricing pages for your region, rebuild the API Gateway charge from your call and cache figures, then compare the result with the invoice lines. Any gap usually comes from tiered pricing, regional differences or data transfer that is billed under another service. Record the rates you used and the date you checked them, because published rates change. The step is done when your recalculated monthly total matches the invoice within a difference you can explain, and you have a baseline you can reuse for each traffic scenario.
Size APISIX nodes from a load test
Run a load test against a staging APISIX deployment that mirrors your route, plugin and authentication configuration, using a request mix taken from step one. Measure sustainable requests per second per node at your target latency, with the plugins you actually need enabled, such as the openid-connect plugin if you validate tokens at the gateway. Repeat with a peak profile and a headroom margin for failover. Your performance team or DeployOpen can design the test, but the results must come from your own workload. The step is done when you have a node count per environment derived from measured throughput.
Add etcd, load balancing, monitoring and logging
Add the supporting components that a self-hosted gateway needs beyond the gateway nodes themselves. In traditional or decoupled mode, APISIX depends on an etcd cluster for configuration, so price its nodes, storage and backups. Include the load balancer in front of the gateway nodes, the metrics and log pipeline, and certificate management. For each, record the cloud or hardware cost, the software cost (most of these components are open source), and the operational effort. Confirm the etcd and cluster sizing with the APISIX deployment modes documentation and your own availability targets. The step is done when every infrastructure line has an owner and a monthly figure.
Add one-time migration and implementation effort
List the one-time work: exporting APIs, mapping integrations to upstreams, rebuilding authorizers and usage plans as APISIX plugins, parallel running, cutover and decommissioning. Estimate effort in person-days per API group from a pilot, not from a generic rule, and ask any implementation partner for a fixed-scope written quote that names deliverables and timelines. Keep this figure separate from recurring costs so the payback calculation is clear. The step is done when you have a one-time total with its assumptions written beside it.
Add the recurring staffing and support line
Estimate the recurring people cost for operating the gateway: platform engineers for upgrades and patching, on-call coverage, security review of plugins and certificates, and any support contract or retainer you choose. Base the share of time on your own team's capacity, and record who is accountable. Then compare monthly totals at several call volumes, including your current volume, half of it and double it. The break-even point is the volume where the self-hosted monthly total, including staffing, falls below the AWS total. The step is done when a chart or table shows both cost curves and the break-even range, with every assumption listed beside it.
When self-hosting APISIX pays off and when it does not
Self-hosting APISIX starts to pay off when the fixed cost of running gateway nodes, etcd, load balancers and monitoring, plus the staff hours to operate them, falls below the metered per-call spend on API Gateway. The break-even point depends on your own numbers, so build a model that prices each component separately. For REST, HTTP and WebSocket APIs, pull the request counts per stage for the last twelve months from CloudWatch, multiply by the tier rates in the current AWS price list for your region, and add caching by the hour and data transfer out. Then size the APISIX side: how many data plane nodes you need at your peak requests per second with headroom for failure, what etcd cluster you would run, the load balancer and log pipeline, and the share of an engineer's time for patching and on-call. Compare the two totals over three years, not one. The balance tends to tip toward self-hosting in three situations. The first is steady, high call volume, where the per-call charge grows linearly while a gateway cluster costs roughly the same at 2x traffic as at 1x. The second is APIs spread across several clouds or in your own data centers, where running API Gateway in one place and separate gateways elsewhere doubles your policy work and your audit scope. The third is data residency: if regulators or contracts require that traffic logs, tokens or payload samples stay inside a boundary you control, a self-hosted gateway in that boundary may be the only compliant design, and the cost comparison becomes secondary.
The managed service often stays cheaper for low-volume or highly variable workloads. A small number of APIs with bursty traffic may leave a self-hosted cluster idle most of the day, and the minimum footprint for high availability still applies. If your team has no one who can own an etcd cluster, TLS certificates and gateway upgrades, the staff cost can outweigh any saving on calls. Also check what you already pay for: if API Gateway is tightly tied to Lambda, Cognito and IAM, moving authorizers and usage plans carries rework that a per-call comparison does not show. Ask your team to estimate the migration effort separately and to name who would carry the on-call rotation. Run both scenarios with your own volumes, and confirm current APISIX release and support status on the APISIX downloads page before you commit to a version line.
Questions buyers ask before comparing costs
How much effort does moving from Amazon API Gateway to APISIX take?
The effort depends mainly on how many APIs you run, how many integration types they use, and how much of your authentication and usage logic lives in API Gateway settings rather than in code. Plan the work in four parts: exporting and inventorying definitions, rebuilding routes and upstreams in APISIX, re-creating authorizers, usage plans and API keys as APISIX plugins, and testing and shifting traffic. Usage plans and API keys do not export with the OpenAPI definition, so they usually take the most manual rebuilding. Ask any implementation partner to break the quote into these parts so you can see where the hours go.
Can our team run APISIX without outside help?
A capable platform team can run APISIX without outside help if it already operates Kubernetes or Linux services, can manage etcd, and has someone who owns the gateway configuration. APISIX supports traditional, decoupled and standalone deployment modes, so you can choose the simplest one that fits your operating model. Outside help is most useful for the first build, for hardening and for writing the runbooks, backups and upgrade procedures that your team will rely on later. Confirm with your own staff which of these skills you already have before deciding how much to outsource.
How long does a migration from API Gateway take?
The timeline is set by the number of APIs, the number of stages still in use, the complexity of authorization and quota rules, and how many consumers must be notified or retested before cutover. No researched figure for duration is available here, so ask any partner for a timeline built from a written scope. A common pattern is to run APISIX alongside API Gateway, move one stage or API group at a time, and keep the old endpoint available until consumers confirm their traffic works. Build time for parallel running and rollback into the plan from the start.
What skills does a team need to operate APISIX?
Operating APISIX needs skills in four areas:
- Linux, container or Kubernetes administration to run the data plane nodes and load balancers.
- etcd operations, including cluster health, backups and access control for the configuration store.
- Configuration as code, usually YAML or the Admin API, with a review process for routes and plugins.
- Identity integration, since the openid-connect plugin works with providers such as Keycloak, Microsoft Entra ID and Okta and supports flows including authorization code and client credentials.
If you write custom plugins, add Lua or one of the supported plugin runner languages. Map these skills to your current staff before budgeting for training or outside support.
Does an APISIX enterprise support subscription change the cost math?
A vendor support subscription can change the math by shifting some operating risk, response commitments and upgrade effort to a supplier, but it adds a recurring fee that you must model next to the open-source baseline. API7.ai offers an enterprise product built around APISIX, described on its enterprise page, so ask the vendor directly what is included, what the support terms are, and what the fee is based on. Apache APISIX itself is licensed under Apache-2.0, so the software does not require a subscription to run. Compare any support fee against the internal staff time it would replace, not against the per-call charges you are leaving.
What should we ask for in a migration quote?
Ask for a quote built from a written scope that lists each deliverable and what is excluded. Useful items to request include:
- An inventory of APIs, stages, integrations, authorizers, usage plans and API keys in scope.
- The APISIX deployment mode, hosting model and etcd design, with backup and recovery steps.
- Work for identity integration, cutover testing, rollback and parallel running.
- Documentation, runbooks, knowledge transfer and any post-cutover support or retainer terms.
Also ask how changes to scope are priced. DeployOpen plans and implements these engagements under fixed scope, with the scope, deliverables and timelines agreed in writing before work starts.
Official sources to check before you build the model
Before you put a number into a cost model, confirm the APISIX version you plan to run against the APISIX downloads page, which lists the current releases and states whether a release is marked as long-term support. The page showed APISIX 3.19.0 as the latest gateway release and APISIX Ingress Controller 2.2.0 as the latest ingress release, but it does not mark any release as long-term support. That gap matters for the model: if you budget for upgrades every year, the recurring engineering time is part of the self-hosted cost, and you should decide how often your team will move to a new minor release. Check the Apache APISIX downloads page on the day you build the model, and record the version and date in the assumptions tab so the figures can be reproduced later.
Sizing is the step where most self-hosted models go wrong, so read the APISIX deployment modes documentation before you choose node counts. The three modes, traditional, decoupled and standalone, have different footprints. Traditional mode runs the data and control plane together and serves client traffic on port 9080 with the Admin API on port 9180. Decoupled mode adds a shared etcd cluster, so etcd becomes a separate line item with its own nodes, backups and operators. Standalone mode removes etcd and loads configuration from a file such as conf/apisix.yaml, which lowers the component count but moves change control to your deployment pipeline. Your model should cost the mode you will actually run, and the choice should be signed off by the platform team before the figures are shared.
License and feature assumptions belong in the model too. Confirm the Apache License 2.0 status and the feature list in the apache/apisix repository on GitHub, since that is where the project states its license and supported protocols. Also confirm which of the plugins your current Amazon API Gateway setup depends on, such as the openid-connect plugin for your identity provider, and whether they are in the open-source build or come from a commercial vendor. For vendor-backed support, read the terms on API7 Enterprise directly. Pricing for AWS itself, including per-call rates for each API type, caching by the hour and data transfer, is not supplied here, so take those rates from AWS's published pricing pages for your region and account, and record the date you read them.
How DeployOpen scopes a fixed-scope APISIX implementation
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an Amazon API Gateway cost review, we start by measuring your real call volumes and cost components, then agree the APISIX build in writing before work begins.
How we scope
- We inventory existing API Gateway stages, routes, authorizers, caching and data transfer costs before proposing any change.
- The written scope names the APISIX deployment mode, etcd layout, load balancers, monitoring and the APIs in each migration wave.
- Deliverables, timelines and responsibilities are agreed in writing before work starts, and the quote follows from that scope.
How we build
- We deploy APISIX in your environment, configuring routes, upstreams and plugins to match the behavior of your current API Gateway setup.
- Authentication flows use the openid-connect plugin wired to your existing identity provider, tested for authorization code and client credentials.
- We run functional, performance and security tests against the APISIX build, including the traffic patterns that drive your per-call costs.
How we hand over
- You receive architecture records, runbooks for etcd, nodes and certificates, and a cost model with each component itemized.
- Configuration is handed over as version-controlled files, so your team can review, roll back and reproduce every route and plugin.
- Knowledge transfer sessions cover day-to-day operations, upgrades and the monitoring signals your team should watch.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
- Upgrades to newer APISIX releases are planned and tested against your routes and plugins before any production change.
- Ask us to confirm support windows, patching responsibilities and escalation paths in the written retainer scope.
