Running Magento (now Adobe Commerce open source) on Amazon Web Services is one of the most common infrastructure decisions in mid-market US e-commerce, and one of the easiest to get expensively wrong. The platform is powerful, extensible and famously resource hungry, while AWS bills for almost everything by the hour, the gigabyte and the request. Put the two together without a plan and a store that should cost a few thousand dollars a month can quietly drift toward a six-figure annual bill that nobody signed off on.
This guide walks through what a production Magento stack actually needs on AWS, where the runaway costs hide, and how retail and engineering teams can size, monitor and control the bill without compromising Black Friday performance. It is written for the operator who has to defend the cloud invoice to a CFO, not just the engineer who has to keep the site up. If you are still deciding whether Magento is the right platform at all, start with our guide on how to choose the right e-commerce platform before committing to the infrastructure work below.
In short
- Magento is CPU and memory heavy, so the AWS bill is driven mostly by EC2 compute and database (RDS or Aurora), not by storage or bandwidth in most stores.
- The six-figure surprise usually comes from four sources: oversized always-on instances, an undersized cache that pushes load onto the database, data transfer and NAT gateway charges, and forgotten non-production environments left running.
- A right-sized single-region stack for a store doing $5M to $20M a year typically lands in the $1,500 to $5,000 per month range, not the $8,000 plus that many teams accidentally provision.
- Caching is the single biggest lever: Varnish or a CDN in front, Redis (or ElastiCache) for sessions and the Magento cache, and read replicas only when query load genuinely demands them.
- Adobe Commerce Cloud is a managed AWS environment with a fixed license, so the real comparison is self-managed AWS flexibility versus managed predictability, not AWS versus something cheaper.
Why Magento on AWS is a decision worth getting right in 2026
Magento remains one of the most widely deployed open-source commerce platforms in the United States, particularly among catalog-heavy B2B sellers, regional retailers and brands that outgrew a hosted SaaS plan. Its strength is control: custom checkout logic, complex catalog rules, deep ERP integration and full ownership of the data model. That control is exactly why teams put it on AWS rather than a fixed shared host, because AWS gives them the room to scale each layer independently.
The catch is that flexibility and cost discipline pull in opposite directions. AWS will happily let you run a fleet of large instances around the clock, attach generous storage, and spin up staging copies that nobody turns off. None of those actions trigger a warning. The bill simply grows, and because it is spread across dozens of line items, the total often surprises the people who approved the project.
In 2026 the pressure is sharper for three reasons. Compute prices have stabilized rather than fallen, so you cannot expect the next instance generation to bail out a sloppy architecture. Adobe’s licensing changes have pushed more teams toward the open-source build on self-managed infrastructure, which means more stores are now responsible for their own AWS bill. And consumer traffic is spikier than ever, concentrated around a handful of promotional days, which tempts teams to over-provision year round for a few peak hours.
Getting the architecture right is therefore both a performance question and a financial one. The good news is that the same decisions that control cost (aggressive caching, sensible right-sizing, autoscaling for peaks) are the same decisions that keep the storefront fast.
It also helps to be honest about why teams land on this combination in the first place. Magento (see the platform background on Wikipedia) carries a heavier operational footprint than a hosted SaaS cart, and AWS is the most common place to run it because nothing else offers the same breadth of managed building blocks for compute, database, cache and content delivery under one bill. The trade is real: you gain near-unlimited room to scale and tune, and you take on the responsibility of deciding how much of that room to actually pay for. Stores that treat that responsibility as a recurring finance task, not a one-off launch decision, are the ones that keep the invoice proportional to revenue. The sections that follow turn that principle into specific, defensible numbers.
Key terms and definitions you actually need
Before sizing anything, it helps to share a vocabulary. AWS and Magento each bring their own jargon, and the cost conversation falls apart when the engineer and the finance lead are using the same word to mean different things.
The AWS building blocks
EC2 is raw compute: the virtual servers that run PHP and the Magento application. RDS is managed relational database (MySQL or MariaDB), while Aurora is Amazon’s higher-performance MySQL-compatible database that costs more but scales storage automatically. ElastiCache is managed Redis or Memcached, used by Magento for sessions and cache storage.
S3 is object storage for media and backups, cheap and rarely the cost problem. CloudFront is the AWS content delivery network. A NAT gateway lets private instances reach the internet for updates and API calls, and it bills per hour plus per gigabyte processed, which makes it a frequent and overlooked line item.
The Magento layers
Full page cache is Magento’s mechanism for serving rendered pages without rebuilding them on every request, usually backed by Varnish. Indexers rebuild the searchable, denormalized views of catalog data, and they are CPU intensive. Cron drives scheduled work such as reindexing, email and cache flushes, and it needs its own headroom so it does not compete with storefront traffic.
The single most important concept for cost is the difference between always-on baseline and peak capacity. Baseline is what you run every hour of every day. Peak is the extra capacity you need for a few hours during a sale. Paying peak prices for baseline hours is the most common reason a Magento bill balloons.
How a production Magento stack runs on AWS
A healthy production deployment separates the layers so each can be sized and scaled on its own. Collapsing everything onto one big instance feels simpler but removes every lever you have for controlling both performance and cost.
The reference architecture
A typical mid-market layout puts the storefront behind CloudFront, terminates traffic at an Application Load Balancer, and runs the Magento application on a small group of EC2 web nodes behind it. Varnish handles full page cache, ElastiCache (Redis) holds sessions and the Magento cache, and the database sits on RDS or Aurora in a private subnet. Media and backups live in S3, and a separate small instance or scheduled task handles cron and indexing so background jobs never starve the storefront.
This separation is what lets you scale the web tier for a flash sale without paying for a bigger database the rest of the year. It also means a failure in one layer does not automatically take down the others, which matters as much for the on-call engineer as it does for the budget.
Single instance versus distributed
Smaller stores sometimes start on a single EC2 instance running everything, and that is a reasonable place to begin for a store doing under $1M a year with modest traffic. The trouble is that a single instance forces you to size for peak load at all times, because you cannot add web capacity independently. The moment traffic becomes spiky, the distributed layout pays for itself by letting the baseline stay small.
Where autoscaling fits
Autoscaling adds and removes web nodes based on demand, so you run two nodes on a quiet Tuesday and eight during a promotion. It works beautifully for the stateless web tier and not at all for the database, which is why the database has to be sized for sustained load while the web tier flexes. Teams that try to autoscale the whole stack, database included, usually end up disappointed, because relational databases do not scale horizontally the way PHP nodes do.
Where the six-figure surprise actually comes from
When a Magento AWS bill is much higher than it should be, the cause is almost never a single dramatic charge. It is the accumulation of four predictable patterns, each of which looks reasonable in isolation.
The first is oversized always-on compute. Teams provision large instances for a peak that lasts a few hours, then leave that capacity running for all 8,760 hours in the year. The second is an undersized or misconfigured cache, which pushes query load onto the database and tempts the team to upgrade to a much larger (and much pricier) database tier to compensate, when the real fix was a properly tuned Redis layer.
The third is data transfer and NAT gateway charges, which are invisible until you read the bill carefully. Cross-availability-zone traffic, NAT gateway processing fees and outbound transfer to the internet add up quietly, especially when chatty integrations or misrouted internal traffic flow through the NAT gateway unnecessarily. The fourth is forgotten environments: staging, UAT and developer copies that were spun up for a project and never shut down, each quietly billing every hour.
A realistic cost breakdown
The table below shows roughly how a right-sized single-region stack distributes cost for a store doing $5M to $20M a year. Figures are illustrative monthly ranges and will vary by region, reserved-instance commitment and traffic profile, but the proportions are what matter.
| Layer | Typical service | Share of bill | Indicative monthly range |
|---|---|---|---|
| Web compute | EC2 (web nodes, autoscaled) | 30 to 40 percent | $600 to $1,800 |
| Database | RDS or Aurora MySQL | 25 to 35 percent | $500 to $1,600 |
| Cache | ElastiCache (Redis) | 8 to 12 percent | $150 to $500 |
| CDN and transfer | CloudFront, data transfer, NAT | 10 to 18 percent | $200 to $800 |
| Storage and backups | S3, EBS, snapshots | 5 to 10 percent | $80 to $400 |
| Non-production | Staging, UAT, dev copies | 5 to 15 percent | $100 to $700 |
The cache and database relationship
The most expensive mistake on this list is treating the database as the place to throw money at a performance problem. When pages are slow, the database is often the symptom, not the cause, because a weak cache layer is forcing it to answer queries that should never reach it. Upgrading the database tier does buy temporary relief, but it is the most costly possible fix and it masks the real issue.
A properly configured Redis layer for sessions and the Magento cache, combined with Varnish full page cache and a CDN, removes the majority of read load before it touches the database. Many teams that were running an oversized Aurora cluster discover they can drop two tiers after fixing caching, which alone can cut the monthly bill by a third. This is the same cost discipline that separates a lean stack from a bloated one in any platform, a theme we explore in our breakdown of the real cost difference between headless and monolithic builds.
Common mistakes and how to avoid them
Most Magento AWS overspend traces back to a handful of habits. None require deep expertise to fix, only the discipline to look.
Provisioning for peak as the baseline
The fix is to define baseline and peak as separate numbers, run the baseline on reserved or savings-plan pricing, and use autoscaling or scheduled scaling for the peak. A store that sees 80 percent of its traffic concentrated in business hours can scale down overnight and save a meaningful slice of compute cost with no customer impact.
Ignoring reserved instances and savings plans
On-demand pricing is the most expensive way to run anything you know you will keep for a year. Baseline compute and the database almost always qualify for one-year or three-year commitments that cut the rate by 30 to 60 percent. The common error is staying on-demand because the team is unsure of future size, when a one-year savings plan on the known baseline is nearly always safe.
Leaving non-production environments running
Staging and developer environments rarely need to run outside working hours. Scheduling them to stop on nights and weekends can cut their cost by two thirds. Better still, treat them as ephemeral: spin them up from infrastructure-as-code when needed and tear them down after, so there is nothing to forget.
Misreading data transfer and NAT charges
Route internal service traffic through VPC endpoints rather than the NAT gateway where possible, keep chatty services in the same availability zone, and serve all static media through CloudFront so origin transfer stays low. These are small architectural choices that compound into real savings over a year.
Skipping cost monitoring entirely
The cheapest fix of all is visibility. AWS Cost Explorer, budget alerts and resource tagging cost nothing and surface the runaway line items before they become a quarterly shock. Tagging every resource by environment and team turns an opaque bill into an accountable one.
Examples from US retail and e-commerce
The patterns above are easier to see in concrete situations. The following composites reflect common US mid-market scenarios rather than any single named company, but they map closely to what operators encounter.
Consider a regional home-goods retailer doing about $12M a year on Magento, whose bill had crept to roughly $9,000 a month. An audit found an Aurora cluster two sizes too large, a Redis instance that had been under-provisioned and was effectively bypassed, and three staging environments running around the clock. Fixing the cache, right-sizing the database, and scheduling staging to stop overnight brought the bill under $4,500 with no measurable change in storefront speed. The cache fix alone allowed the database downsize.
A second common case is the B2B distributor with heavy catalog and complex pricing rules, where indexing load is the real driver. Here the answer was not a bigger storefront tier but a dedicated, modestly sized instance for cron and indexing, so reindexing no longer competed with customer traffic. Moving indexing off the web nodes let the team run a smaller web tier the rest of the time.
The third recurring example is the brand preparing for a major promotional day. Rather than running peak capacity for the whole quarter, the team used scheduled scaling to pre-warm capacity hours before the event and scale back down afterward, paying for the surge only when it was needed. For teams whose growth path eventually points away from Magento, the same cost logic applies to the exit, which we cover in our guide on migrating off Magento and where stores end up.
Tools, partners and vendors worth knowing
You do not have to assemble all of this alone. A small set of tools and partner types covers the practical needs of a Magento-on-AWS operation, and choosing among them is mostly a question of how much you want to manage yourself.
| Option | What it is | Best for | Cost predictability |
|---|---|---|---|
| Self-managed AWS | Your own VPC, EC2, RDS and cache, run by your team or a partner | Teams wanting maximum control and willing to own tuning | Variable, requires active cost management |
| Managed Magento host on AWS | A specialist host (for example Cloudways, Nexcess or similar) running Magento on AWS for you | Lean teams without dedicated DevOps | More predictable, monthly plan based |
| Adobe Commerce Cloud | Adobe’s managed PaaS, itself built on AWS, bundled with the license | Enterprises wanting one vendor and SLA | Most predictable, highest fixed cost |
| DIY with automation | Self-managed AWS plus infrastructure-as-code (Terraform, CloudFormation) | Engineering-led teams scaling multiple environments | Variable but controllable and repeatable |
The supporting toolset
For the application layer, Adobe publishes the official Adobe Commerce system requirements, which define the PHP, database and search versions any AWS build has to match. For search, OpenSearch (the AWS-supported successor to Elasticsearch) is the standard companion, and AWS offers it as a managed service that slots neatly beside the rest of the stack.
On the operational side, infrastructure-as-code tools such as Terraform turn a fragile hand-built environment into something you can recreate and tear down on demand, which is the single biggest practical defense against forgotten-environment costs. For monitoring, pairing AWS Cost Explorer with an application performance tool gives you both the financial and the technical view, so you can tell whether a slow page is a code problem or a capacity problem before you spend money on the wrong fix. A fuller list of platform tooling lives in our roundup of tools and vendors for Magento in 2026.
A practical right-sizing playbook
Pulling the threads together, here is the sequence most teams should follow to bring a Magento AWS bill under control without risking the storefront. The order matters, because fixing caching before touching the database prevents you from downsizing the database into an outage.
- Turn on visibility first. Enable Cost Explorer, set budget alerts, and tag every resource by environment and team before changing anything.
- Fix caching. Confirm Varnish full page cache, a correctly sized Redis layer for sessions and cache, and CloudFront for static media are all working as intended.
- Right-size the database. Only after caching is solid, downsize RDS or Aurora to match real sustained load, and add a read replica only if query latency genuinely demands it.
- Separate baseline from peak. Move baseline compute and the database onto savings plans or reserved instances, and use autoscaling or scheduled scaling for promotional peaks.
- Tame non-production. Schedule staging and dev to stop outside working hours, or rebuild them on demand from infrastructure-as-code.
- Audit transfer and NAT. Route internal traffic through VPC endpoints, keep chatty services co-located, and serve all media through the CDN.
Run that sequence once and most stores find a 30 to 50 percent reduction without any drop in performance. The deeper lesson is that cost control on AWS is an ongoing discipline rather than a one-time project, and the teams that build it into their monthly rhythm are the ones that never get the six-figure surprise. The architecture choices here also shape how easily you can adopt newer patterns later, including the modular approaches we describe in composable commerce stacks and the cross-border setup work in our Shopify Markets walkthrough. Whichever direction your roadmap takes, revisiting how to choose the right e-commerce platform on a regular cadence keeps the infrastructure spend tied to a business case rather than to inertia.
FAQ
How much does it cost to host Magento on AWS?
A right-sized single-region stack for a US store doing $5M to $20M a year typically costs $1,500 to $5,000 per month, driven mostly by EC2 compute and the database. Stores often pay far more than this because of oversized always-on instances and forgotten environments rather than genuine traffic needs.
Is Magento on AWS cheaper than Adobe Commerce Cloud?
Self-managed AWS is usually cheaper in raw infrastructure but shifts the cost of management, tuning and on-call onto your team. Adobe Commerce Cloud bundles a managed AWS environment with the license, trading higher fixed cost for predictability and an SLA. The right choice depends on whether you have the DevOps capacity to manage the stack yourself.
What is the biggest driver of a high Magento AWS bill?
Compute and database almost always dominate. The single biggest avoidable driver is provisioning peak capacity as a permanent baseline, closely followed by an undersized cache that pushes load onto an expensive database tier. Fixing caching often allows a significant database downsize.
Do I need Aurora or is RDS MySQL enough?
RDS MySQL is sufficient for most mid-market Magento stores, especially once caching is tuned. Aurora is worth its premium for high-traffic stores that need its faster storage layer and automatic scaling, but many teams pay for Aurora to mask a caching problem that RDS would handle fine once fixed.
How do I handle Black Friday traffic without paying for it year round?
Keep a small baseline and use autoscaling or scheduled scaling for the web tier, pre-warming capacity before the event and scaling down afterward. Size the database for sustained peak rather than autoscaling it, since relational databases do not scale horizontally like stateless web nodes.
Why is my data transfer bill so high?
The usual culprits are cross-availability-zone traffic, NAT gateway processing fees and origin transfer for media that should be served through the CDN. Routing internal service calls through VPC endpoints and serving all static assets through CloudFront usually brings these charges down sharply.
Can a small store run Magento on a single AWS instance?
Yes, a store under $1M a year with modest traffic can run everything on one EC2 instance to start. The limitation is that you must size for peak at all times, so once traffic becomes spiky the distributed layout pays for itself by letting the baseline stay small.
How can I reduce my Magento AWS bill without hurting performance?
Follow the order that protects the storefront: turn on cost visibility, fix caching, then right-size the database, then move baseline onto savings plans, then tame non-production environments, then audit transfer and NAT. Done in sequence this typically cuts the bill 30 to 50 percent with no measurable performance loss.
Should I use a managed Magento host instead of running AWS myself?
If you lack dedicated DevOps capacity, a specialist managed host running Magento on AWS gives you more predictable monthly costs and offloads tuning and patching. If you have an engineering-led team comfortable with infrastructure-as-code, self-managed AWS offers more control and often a lower bill, at the cost of ownership.