Magento hosting cost calculator

AWS wins on Magento share, ecosystem, and price-perf in us-east. Roughly 65-70% of self-hosted Magento stores in my book run on AWS. The canonical stack is EC2 (compute) + RDS Aurora MySQL (database) + ElastiCache Redis (sessions + cache) + OpenSearch Service (catalog search) + CloudFront / S3. Every Magento agency and freelancer has tuned this stack a dozen times.

Azure wins when you’re a Microsoft shop. If the customer is on Azure AD, Microsoft 365, Power BI, Dynamics ERP, running Magento on Azure App Service + Azure Database for MySQL + Azure Cache for Redis means one bill, one IAM, one support contract. The Magento community is smaller on Azure but Adobe officially supports it.

GCP is the dark horse. Best raw price-perf, especially with Cloud Run + Cloud SQL HA + Memorystore. But the Magento community on GCP is tiny, expect to do more DevOps work yourself because there are fewer pre-baked Terraform / Pulumi modules. I’d only pick GCP if the customer is already there.

Rule of thumb: AWS unless there’s a Microsoft-shop reason to choose Azure or a strategic-deal reason to choose GCP. The price difference at most workloads is <15%, not enough to override ecosystem maturity.

Both are Magento-native managed hosts with similar stacks (PHP-FPM + Varnish + Redis + MySQL + OpenSearch) and similar price bands. The real differences:

• MageMojo is leaner, more DevOps-focused, and historically the cheaper option for high-traffic stores. Founder is a long-time Magento contributor; support is via Slack with senior engineers. Best for stores at $1M, $10M GMV that want managed-Magento without paying Adobe Cloud prices.
• Nexcess (Liquid Web brand) is more product-tiered: StoreBuilder for SMB, Magento Cloud Pro for mid-market, Enterprise tier for larger. Support is 24/7 with a ticket system; bench is deeper but less direct-to-senior-eng access. Best for stores that want a single managed-hosting bill including backups, staging environments, and managed updates.

Calculator tie-breakers:

• If your traffic is spiky (Black Friday, drops), MageMojo’s auto-scale on Kubernetes wins.
• If you need staging environments / dev sandboxes included, Nexcess Pro tiers bundle them.
• If you want a phone number to call at 3am, Nexcess.
• If you want a Slack channel with the engineer who wrote your tuning, MageMojo.

Both run open-source Magento and Adobe Commerce. Both can host Hyvä. Both will migrate you in 7-14 days. The pricing difference is usually <20% at the same tier.

Adobe Commerce Cloud is worth the premium when all three of these are true:

1. You’re already on the Adobe Commerce licence (B2B Companies, Quotes, Shared Catalogs, Page Builder Premium, BI). Open-source Magento on Adobe Cloud is paying for hosting features you can replicate elsewhere for a third of the price.
2. Your team has zero DevOps capacity. Cloud Pro bundles Fastly CDN, New Relic APM, Adobe-managed PHP / Varnish / Redis tuning, and a single Adobe SLA. If you have to hire a DevOps engineer to run AWS yourself, the Adobe Cloud premium is often cheaper all-in.
3. You value “one throat to choke.” When Magento breaks, you don’t care which layer it was, Adobe owns it end-to-end. That single-vendor accountability matters in regulated industries (finance, pharma) where post-mortems need a paper trail.

It’s a trap when you’re on open-source Magento, have any internal DevOps muscle, and just want fast PHP hosting. You’ll pay $4k, $12k/mo for a stack that costs $1k, $3k all-in on AWS + Nexcess. The premium goes to features you’re not using.

Price bands today: Starter ($2k, $4k/mo), Pro ($4k, $8k/mo), Pro Plus ($8k, $15k+/mo). Annual contracts only; no monthly. Plan a 30-90 day onboarding window because Adobe has to provision your project on their managed Kubernetes.

From measured data across 30+ Luma → Hyvä migrations I’ve shipped, the median compute saving is 22%, with a spread of 15% to 35%. The driver: Hyvä renders pages with Alpine.js + Tailwind in the browser, so the PHP layer does less templating work and Varnish hits last longer.

Where the saving lands:

• PHP-FPM worker count drops 20-30% for the same peak concurrent. A Luma store needing 32 workers can run on 24 on Hyvä.
• Varnish hit rate climbs 5-10 points because Hyvä-rendered pages are smaller and more cacheable.
• Redis traffic drops 10-20% because Knockout-driven cart refreshes are gone.
• OpenSearch query rate is unchanged, this is a frontend-only optimisation.
• Database load is unchanged.

On a typical $1k/mo AWS Magento bill, Hyvä saves $150, $300/mo on compute. On a $5k/mo Adobe Cloud bill, it’s $700, $1.5k/mo. The calculator models this as a flat -22% compute multiplier when you toggle “Hyvä yes”, conservative middle of the band.

Caveat: the saving only materialises when you actually downsize after the migration. If you keep the same instance sizes, the saving is “headroom for traffic growth” rather than cash.

Multi-region active-active hosting roughly doubles the base bill, with a spread of +50% to +120% depending on architecture.

What you’re paying for:

• 2x compute, running a full Magento cluster in each region.
• Database replication, Aurora Global Database or RDS read-replicas. Adds ~30% to DB bill, plus inter-region data transfer (~$0.02, $0.09 per GB).
• Cache + search replicas, ElastiCache and OpenSearch in each region.
• CDN routing, Fastly multi-shield, Cloudflare Argo, or Route 53 latency routing. ~$100, $500/mo on top.
• DNS health checks + automated failover, minor cost, major value when one region goes dark.

Region cost variance for the same instance family (AWS examples):

• us-east-1 (Virginia): baseline (cheapest).
• us-west-2 (Oregon): +5%.
• eu-west-1 (Ireland): +18%.
• eu-central-1 (Frankfurt): +22%.
• ap-south-1 (Mumbai): +12%.
• ap-northeast-1 (Tokyo): +28%.
• sa-east-1 (São Paulo): +60%.

Most stores don’t need true multi-region. A single region in us-east-1 fronted by Fastly / Cloudflare with global edge cache delivers fast TTFB worldwide for 90% of Magento traffic. Multi-region is for stores with hard requirements: regulatory data residency, compliance, or active-active uptime targets >99.99%.

For Magento workloads on AWS / Azure / GCP, reservations save 30-55% over on-demand pricing for the same compute. The exact split:

• 1-year, no-upfront reservation: ~30% saving over on-demand.
• 1-year, all-upfront reservation: ~40% saving (you pre-pay the year).
• 3-year, no-upfront: ~45% saving.
• 3-year, all-upfront: ~55-60% saving (deepest discount but biggest commitment).
• Savings Plans (AWS): ~30-50% with more flexibility across instance families.

When to reserve:

• Baseline always-on instances (web tier, RDS primary, Redis primary), reserve at 3-year all-upfront if you’re confident you’ll still be on Magento + AWS in 3 years. ROI is positive at month 14.
• Auto-scaling tier (workers, async queue consumers), keep on-demand or use AWS Spot Instances at -70% (with the caveat that they can vanish).
• OpenSearch dedicated nodes, reserve. They’re always-on, expensive, and worth the discount.

Don’t reserve if you’re mid-migration, evaluating providers, or have less than 12 months of historical traffic data. The lock-in penalty is bigger than the saving.

The calculator output is on-demand pricing. Apply -35% mentally if you’re planning to reserve at 1-year, -50% for 3-year reservations.

Aurora is worth it for Magento above ~500k orders/year or any store with heavy reporting / B2B workflows. Below that, vanilla RDS MySQL is fine and significantly cheaper.

What you get for the Aurora premium (~30-50% over RDS MySQL):

• 3x read performance on typical Magento queries (storage layer is purpose-built for high-IOPS).
• Sub-100ms replica lag vs ~300-800ms on RDS Read Replicas, matters for Magento because catalog reindex hits the primary and inventory queries hit replicas.
• Storage scales 0-128TB automatically. You don’t over-provision storage upfront.
• Global Database for cross-region replication (~1 sec lag), only Aurora has this.
• Better failover, sub-30-second to a replica vs 1-5 minutes on RDS Multi-AZ.

When RDS MySQL wins:

• Stores under 100k orders/year, vanilla RDS handles it on a db.t4g.large for ~$120/mo.
• Dev / staging environments, Aurora’s per-second billing is poorly matched to start-and-stop workflows.
• Budget under $500/mo for the entire DB tier.

Practical pattern I deploy most often: Aurora MySQL in production (Multi-AZ, 2 reader replicas), RDS MySQL in staging / dev. Best of both.

Caveat: Aurora’s I/O pricing can surprise you on write-heavy workloads. Always model with the AWS pricing calculator using your actual write rate before reserving.

Use Redis. Always. Magento has officially recommended Redis since 2.3.x and the cost difference vs Memcached is negligible at the same memory footprint.

What Redis buys you that Memcached doesn’t:

• Persistent sessions, cart survives a cache restart. Memcached is volatile.
• Two-DB architecture, Magento uses Redis DB0 for cache and DB1 for sessions. Separate eviction policies, separate sizing.
• Page-cache (FPC) layer, you can run a third Redis DB or a separate Redis cluster for FPC, dramatically reducing Varnish dependency.
• Cluster mode, horizontal scaling for stores above 1M orders/year.
• Persistent across deploys, reduces cold-cache penalty after every release.

Pricing reference (ElastiCache):

• cache.t4g.small (1.5GB): ~$25/mo. Good for <$200k GMV stores.
• cache.m6g.large (6.4GB): ~$110/mo. Good for $200k, $2M GMV.
• cache.m6g.xlarge (12.9GB): ~$220/mo. Good for $2M, $10M GMV.
• cache.r6g.large (13.1GB, memory-optimised): ~$140/mo. The sweet spot for most $1M+ Magento stores.

The calculator assumes Redis (it’s the only sane choice). If you’re still on Memcached and on Magento 2.4.x, switch, the migration takes 4-8 hours of dev time and prevents an entire class of session-loss bugs.

For 95% of Magento stores, the answer is managed OpenSearch Service (AWS) or equivalent on your cloud. Self-hosting OpenSearch is a DevOps trap that costs more once you count the operational hours.

AWS OpenSearch Service pricing reference:

• t3.small.search (~$30/mo), dev / staging only; not for production.
• t3.medium.search (~$60/mo), production for <5k SKU stores under $200k GMV.
• m6g.large.search (~$140/mo), production for 5k, 50k SKU stores, $200k, $2M GMV.
• m6g.xlarge.search (~$280/mo), mid-market, 50k+ SKUs, $2M+ GMV.
• m6g.2xlarge.search (~$550/mo) + dedicated master nodes, enterprise tier, 200k+ SKUs.

Sizing rule of thumb: OpenSearch needs ~1.5GB RAM per million catalog documents (including all attribute permutations). Add 30% headroom for reindex bursts. Always run with at least 2 data nodes for HA in production.

When to self-host: Only when you’re on a Magento-native managed host (MageMojo / Nexcess) that includes a tuned OpenSearch in the bundle, or when you have a dedicated DevOps engineer who is going to keep an eye on cluster health weekly. Otherwise the “cheap” self-hosted t3.medium VM ends up being the most expensive line item in your stack when it fails on Black Friday.

No. Magento 2 is a PHP monolith with stateful sessions, persistent database connections, scheduled cron jobs, queue consumers, indexers, and message brokers (RabbitMQ / SQS). None of that fits the Vercel / Netlify model, which is stateless serverless functions + edge-cached static assets.

What Vercel / Netlify can do for a Magento store:

• Host a PWA / headless frontend talking to Magento’s REST / GraphQL APIs. PWA Studio, Vue Storefront, Hyvä Commerce headless, all of these front-ends deploy beautifully on Vercel / Netlify.
• Edge-cache static catalog pages using on-demand revalidation.
• Host a separate marketing / blog site that links into Magento.

What stays on Magento-capable PHP hosting (AWS / Azure / GCP / MageMojo / Nexcess / Adobe Cloud):

• The Magento backend (admin, cron, indexers, integrations).
• The database (MySQL / Aurora).
• The cache layer (Redis).
• The search layer (OpenSearch).
• The order / quote / customer data.

So if you’re thinking “move to Vercel,” what you’re really planning is a headless migration where Vercel hosts the storefront and your existing Magento becomes a commerce-API backend on its existing hosting. That’s a separate engagement ($40k, $120k) and a different decision tree than the “which hosting provider” question this calculator addresses.

Adobe Commerce Cloud lock-in is medium. Harder than vanilla AWS, easier than Shopify Plus. The data is yours and the code is open-source Magento, but the deployment toolchain, Fastly config, and Magento Cloud-specific extensions tie you to the Adobe-managed Kubernetes platform.

What you can take with you (no lock-in):

• The Magento code, database, media, and customer data.
• The Adobe Commerce licence (if you’re on B2B / Enterprise), portable to any host.
• Most marketplace extensions.

What you have to redo on a new host:

• CI/CD pipeline. Magento Cloud uses a proprietary deployment workflow (`.magento.app.yaml`, `magento-cloud` CLI). On AWS / managed-Magento you’ll set up GitHub Actions / GitLab CI / Capistrano.
• Fastly VCL. If you’ve customised the bundled Fastly cache config, you’ll port it to your new CDN (Cloudflare / Akamai / a self-managed Fastly).
• New Relic. Magento Cloud bundles it; on a new host you’ll set it up separately (or switch to Datadog / Grafana).
• Cron + queue topology. Magento Cloud’s job scheduler is different from cron / supervisord.
• Email transport. Bundled in Magento Cloud; separate (SendGrid / SES) on a new host.

Typical migration cost off Magento Cloud: $15k, $40k for the engineering work, plus 4-8 weeks of calendar time. The savings appear from month 2 if you’re going to a cheaper managed-Magento host (Nexcess / MageMojo) and from month 6 if you’re going to raw AWS.

The lock-in cost isn’t crazy, it’s ~3-6 months of the Adobe Cloud bill. The lock-in friction is higher because you’ll need a developer who knows both the Adobe Cloud deployment model and your target platform.

Re-evaluate the hosting decision every 18-24 months, or whenever one of these trigger events fires:

• Annual renewal with a price hike >15%. Time to negotiate or shop.
• You’ve crossed a GMV threshold. $200k/mo, $1M/mo, $5M/mo are the natural inflection points where the previous tier stops making sense.
• You’ve migrated to Hyvä, ~22% compute saving means you can downsize or move to a cheaper provider.
• Performance has regressed, LCP > 3s, INP > 200ms, or 5xx error rate > 0.5% sustained. Sometimes a hosting move fixes it; sometimes it’s code, not infra.
• You’ve moved to / from Adobe Commerce licence. Adobe Cloud only makes sense on the licence; moving off means you’re paying for unused features.
• Major version upgrade (2.4.x → next major). Treat the upgrade as a hosting-review trigger because tuning changes anyway.
• Multi-region requirement appears. If you suddenly need EU data residency or APAC latency, your single-region host may not cut it.

What “re-evaluate” means:

1. Re-run this calculator with current traffic + GMV. See if the recommended provider has changed.
2. Get 1-2 informal quotes from the calculator-recommended providers. Don’t spend more than a week.
3. Stack the all-in cost (hosting + ops + tooling + opportunity cost of migration) against staying.
4. Migration cost ~$5k, $25k means the saving has to clear $500, $2k/mo for 12+ months to be worth it.

Don’t re-evaluate more than every 12 months, migrating hosting is a 4-8 week project, and constant shopping is a tax on your engineering team. Lock in 24-month contracts when you find a fit.