The Hyvä theme is fast on paper. Whether your Hyvä-themed Adobe Commerce store actually hits its performance ceiling is determined by the infrastructure underneath, and the AWS infrastructure decisions that matter most are not always the ones merchants pay attention to. The instance type, the database configuration, the cache layer, the CDN, and the storage choices each contribute to where the performance ceiling lands. Get them right and a $20M store can run on a four-figure monthly AWS bill. Get them wrong and you spend five figures a month chasing performance problems that the architecture is creating.
This piece walks through the AWS architecture decisions that consistently determine performance on Hyvä-themed Adobe Commerce stores. Bemeir’s infrastructure team operates mid-market and enterprise Adobe Commerce stores across AWS, Adobe Commerce Cloud, and other hosting environments; the patterns below are the ones that have held up across two-year operational runs.
Decision 1: Compute sizing and instance family
The right instance for Adobe Commerce is not the cheapest or the largest; it is the one whose CPU, memory, and network match the workload pattern.
CPU. Adobe Commerce is CPU-bound at peak. PHP execution, especially during cart updates, checkout, and admin operations, will saturate CPU before anything else does. M-family (general purpose) and C-family (compute optimized) instances are both viable. C-family wins when sustained CPU is the bottleneck; M-family wins when the workload is bursty and you need more headroom on memory. Avoid T-family (burstable) for production; the credit-based CPU model causes mysterious performance regressions under sustained load.
Memory. PHP-FPM, OPcache, Realpath cache, and the application itself consume meaningful RAM. A mid-market Adobe Commerce store typically wants 8-16 GB on the application tier, with 32+ GB for stores running heavy custom code or large catalogs.
Network. Adobe Commerce talks to MySQL, Redis, OpenSearch, and the CDN over the network. Instance network performance directly affects request latency. The “up to 10 Gigabit” tier is enough for most mid-market stores; enterprise stores with heavy traffic should be on enhanced networking.
Auto-scaling vs fixed. Auto-scaling groups handle traffic spikes gracefully but introduce cold-start latency on new instances. Many mid-market Adobe Commerce stores run better with a fixed cluster sized for peak rather than auto-scaling sized for average; the math depends on the spikiness of the traffic pattern.
Decision 2: Database
The database is the most common Adobe Commerce performance bottleneck and the most consequential AWS decision.
RDS MySQL vs Aurora MySQL. Aurora’s storage architecture and replica scaling are real advantages for production Adobe Commerce stores at scale. The cost premium is meaningful but the operational benefits (faster failover, better read replicas, automated backups) usually pay for it on stores doing meaningful revenue. Aurora is the right default for Adobe Commerce production.
Instance sizing. Memory matters more than CPU for typical Adobe Commerce workloads because the working set should fit in InnoDB buffer pool. Size the database to keep your hot indexes in memory. The shorthand is buffer pool at 70-80% of available RAM, sized to comfortably exceed the working set.
Read replicas. Adobe Commerce supports MySQL splits: write traffic to the primary, read traffic to replicas. The split improves performance under load but adds operational complexity (replication lag handling, failover testing). For stores at $20M+ annual revenue with consistent traffic, the splits are usually worth the complexity.
Storage and IOPS. Aurora handles IOPS scaling automatically. For RDS MySQL, ensure you are on Provisioned IOPS or General Purpose SSD with sufficient burst capacity. The default GP2 with bursting works for moderate loads; sustained heavy writes need GP3 or io1/io2.
Decision 3: Cache layer
Adobe Commerce caches multiple things across multiple layers; the AWS architecture should support each layer with the right service.
Redis for session and cache. ElastiCache for Redis is the standard. Two separate Redis clusters: one for session, one for full page and configuration cache. Mixing them on a single instance is technically supported but introduces eviction conflicts that cause hard-to-debug issues. Sizing depends on session count and cache pressure; start with cache.r6g.large and scale up based on memory utilization.
Varnish in front of Adobe Commerce FPC. Adobe Commerce supports Varnish natively. Running Varnish on the application instance is workable for small stores; for mid-market and up, dedicated Varnish instances (or CloudFront as the caching layer) is faster and more reliable. Cache hit rates of 85%+ on category and product pages are the target.
OpenSearch (or Elasticsearch) for product search. OpenSearch Service is the AWS managed offering. Adobe Commerce uses it for catalog search and recommendations. Sizing depends on catalog size: a 50,000-SKU catalog runs comfortably on small managed clusters; a 500,000-SKU catalog needs more.
Decision 4: CDN and storage
The static asset and image delivery layer is where the user actually experiences performance.
CloudFront for static assets and images. Setting CloudFront in front of S3 (for media) and in front of Varnish or the application tier (for HTML) is the standard pattern. The CloudFront cache hit ratio for media should be above 90%; product images that miss CloudFront and hit origin every time will demolish LCP.
Image processing. Adobe Commerce’s default image generation is too slow for production. Either move to a CloudFront-fronted image service (CloudFront Functions, Cloudflare Images, or a dedicated image CDN) or to an extension that does background generation and aggressive caching. Inline image generation during cache miss is the LCP killer most stores do not realize they have.
S3 for media storage. Adobe Commerce’s media directory should be on S3, not on the application instance’s local disk. This makes the application tier stateless and allows multi-instance scaling without sync headaches.
Decision 5: Region and availability
Latency to the user is determined by where the infrastructure is.
Single region with global CDN. For US-focused stores, a single AWS region (us-east-1 or us-east-2) with CloudFront’s global edge is the standard. The CDN handles the geographic distribution; the origin stays in one place.
Multi-region for global stores. Stores serving international markets often want regional infrastructure to handle localized features (checkout currency, regional inventory, regional pricing) closer to the user. The complexity premium is significant but justified for stores doing meaningful international revenue.
Availability Zones. Adobe Commerce production should run in multiple AZs with database replication across AZs. Single-AZ deployments save money and create unacceptable risk.
How the choices stack at typical store sizes
| Store size | Compute tier | Database | Cache | CDN | Monthly AWS cost (range) |
|---|---|---|---|---|---|
| Small ($5-20M revenue) | 2x m6i.xlarge | Aurora db.r6g.large | Single Redis cluster | CloudFront | $1,500-3,500 |
| Mid-market ($20-100M) | 4x m6i.2xlarge auto-scaled | Aurora db.r6g.2xlarge + replica | Separate session and cache clusters | CloudFront with image processing | $5,000-12,000 |
| Enterprise ($100M+) | Auto-scaled m6i.4xlarge cluster | Aurora cluster with 2+ replicas | Multi-cluster Redis with persistence | CloudFront + dedicated image CDN | $15,000-40,000+ |
The numbers vary based on traffic patterns, peak load, and operational requirements; treat them as starting points rather than commitments.
Adobe Commerce Cloud vs self-hosted on AWS
Adobe Commerce Cloud runs Adobe Commerce on a managed AWS-backed environment. The trade-offs versus self-hosting on AWS:
Adobe Commerce Cloud advantages. Managed by Adobe, includes monitoring and support, opinionated deployment workflow, support for Adobe Commerce-specific patterns out of the box.
Adobe Commerce Cloud disadvantages. Cost premium over equivalent AWS infrastructure, less flexibility on architecture decisions, opinionated deployment that some custom workflows fight against.
Self-hosted AWS advantages. Full control over architecture, can be cheaper at scale, integrates naturally with custom infrastructure already on AWS.
Self-hosted AWS disadvantages. Operational responsibility falls entirely on you or your agency, no Adobe support for infrastructure issues, more decisions to make and get right.
The decision is rarely about which is technically better; it is about where the operational expertise lives. Stores with strong DevOps in-house often save meaningfully by self-hosting. Stores without dedicated DevOps usually do better on Adobe Commerce Cloud or on a managed AWS hosting provider.
Where merchants most often go wrong
Three patterns appear across the Adobe Commerce stores on AWS that are underperforming:
Undersized database for the working set. The buffer pool does not hold the hot indexes, queries are doing disk I/O on every read, and the application is slow no matter how much you tune PHP. The fix is right-sizing the database, not optimizing the application.
Image processing inline on cache miss. Every cache miss generates an image on the application instance, blocking the request for hundreds of milliseconds. The fix is moving image generation off the critical path.
No real cache tier in front of Adobe Commerce FPC. Varnish or CloudFront fronting cached HTML is the difference between 200ms TTFB and 800ms TTFB. The fix is putting the cache tier in place.
Bemeir sees these three issues on roughly 60% of new client stores. They are not exotic; they are well-documented in the Adobe Commerce performance best practices and the AWS Well-Architected Framework. The merchants who get them right out of the gate save themselves a year of chasing performance problems that the architecture was creating from day one.
