You Don't Need Adobe Commerce Cloud to Survive Black Friday

Everyone treats Adobe Commerce Cloud like it's the only thing standing between their store and a Black Friday meltdown. It's the platform that survives the spike, the managed fortress you can't possibly replicate, the reason the six-figure invoice is worth it. So let's pull the curtain back and look at what a Pro production environment actually is.

It's three virtual machines behind a load balancer, replicated across three AWS availability zones. That's it. That's the fortress. Adobe's own architecture docs describe the Pro production environment as having "three virtual machines (VMs) behind an Elastic Load Balancer," and each project "replicated on three separate AWS or Azure Availability Zones." Once you've seen that, the Black Friday question changes shape completely. It stops being "how do I buy the platform that survives" and becomes "can I build a three-node, multi-AZ cluster on AWS?" And you already know the answer to that one.

What Adobe Commerce Cloud Pro actually is

Strip the branding and Pro is a managed, dedicated cluster on AWS (Azure is an option, but AWS is the common case). Three nodes, and here's the part people get wrong: it's not a primary with two hot spares. It's active-active. Adobe runs a Galera cluster where "all three instances accept reads and writes," with an auto-increment setting of three so IDs stay unique across every node. They explicitly contrast this with "a traditional active-passive master or master-slave setup." All three nodes take traffic, all three take writes, and losing one AZ doesn't take the store down.

Each of those three nodes carries the full stack:

• Fastly in front for CDN, WAF, and image optimization (more on that below).
• NGINX with PHP-FPM as the web tier.
• Galera / MariaDB as the active-active database, one instance per node.
• Redis (Valkey on newer releases), one server per VM, "with only one active and the other two as replicas."
• Elasticsearch or OpenSearch for catalog search, and which one depends on your version. Elasticsearch on older Commerce releases, OpenSearch from 2.4.4 onward. Never say just "Elasticsearch" without checking the version, because on a current store it's almost certainly OpenSearch.
• GlusterFS as the shared file store, keeping media and static assets synced across the three nodes.

Now, the "six nodes" number you may have heard is real, but it is not the baseline. Adobe's scaled architecture splits the stack into a tiered layout: "a minimum of six nodes: three nodes for the core database and services and three nodes for the web server." That only kicks in on "the Pro 48 cluster or greater." So the default Pro store surviving your Black Friday is three nodes, and the six-node split is a bigger-plan upgrade, not the standard. If someone tells you Adobe Cloud is inherently a six-node monster, they're describing a tier most stores never buy.

The part that actually survives the spike

Here's the thing worth internalizing before you write a check: none of what makes this cluster survive Black Friday is proprietary Adobe magic. It's a handful of well-understood architecture decisions, and every one of them is a pattern you can name.

Full-page caching at the edge. Fastly is a Varnish-based service that caches "site pages, assets, CSS, and more" at global edge nodes. On Black Friday, the overwhelming majority of your traffic is people looking at the same category and product pages. If those are served from cache, they never touch PHP or the database at all. This is the single biggest reason the cluster holds: the origin only sees the long tail of uncacheable, personalized, add-to-cart requests. Fastly also runs the WAF, though note it's "available on Pro and Starter Production environments only," so your staging traffic isn't behind it.

An active-active database with no single writer. Because all three Galera nodes accept writes, there's no lone primary whose death stops checkout, and no failover dance while the replicas get promoted. Don't read that as three times the write throughput, though. Every write is still certified and applied on every node, so Galera buys you availability and spread-out connections, not linear write scaling. For a Black Friday store, availability is the part that matters.

A web tier you can throw hardware at. NGINX and PHP-FPM are stateless request handlers. The session and cart state live in Redis, the catalog in the database and search index. That statelessness is what makes horizontal scaling possible at all: nothing about node two knows or cares what node one just served.

Multi-AZ as the failure story. Three availability zones means a whole datacenter can have a bad day and your store stays up on the other two. This isn't a performance feature, it's a survival feature, and it's the one people most often skip when they roll their own and then regret at the worst possible moment.

Four patterns. Edge cache, active-active writes, stateless autoscaling web tier, multi-AZ redundancy. Hold onto those, because rebuilding Adobe Cloud is really just rebuilding those four things.

Rebuilding it on AWS

You don't have to guess at the mapping, because AWS published it. Their whitepaper on migrating Magento Open Source or Adobe Commerce to AWS lays out a reference architecture that mirrors the Adobe Cloud stack service-for-service. AWS has since stamped it "for historical reference only," and the software versions in it have aged, but the service mapping hasn't. The pieces line up like this.

The mappings, straight from AWS's reference:

• CDN: Amazon CloudFront (or keep Fastly in front of AWS, plenty of stores do).
• Full-page cache: Varnish on EC2 in an Auto Scaling group. AWS's own reference keeps Varnish rather than leaning entirely on the CDN, which mirrors Magento's built-in Varnish integration.
• Load balancing: Application Load Balancer across multiple AZs.
• Web / PHP tier: EC2 instances in an Auto Scaling group across multiple availability zones. ECS or EKS is a common modern variant, but the AWS whitepaper itself uses plain EC2 plus autoscaling, so don't feel you need containers to be legitimate here.
• Database: Amazon RDS for MySQL or Aurora, and if you pick Multi-AZ, AWS deploys "a synchronously replicated secondary database" with "automated failover from the primary." That's not literally Galera active-active, and that's an honest difference worth sitting with: Aurora Multi-AZ gives you synchronous replication and automatic failover, not three simultaneously-writable nodes. For the vast majority of stores, failover-in-seconds is what you actually needed anyway.
• Cache: Amazon ElastiCache with the Redis engine.
• Search: Amazon OpenSearch Service.
• Message queue: Amazon MQ, the managed AMQP broker that stands in for RabbitMQ.
• Shared media: AWS's reference uses Amazon S3 via the remote-storage module. If you want the closer analogue to GlusterFS's POSIX shared mount, EFS does that, at a different cost profile. Both are legitimate; S3 is what AWS reached for.

The load-bearing piece, the database, is a few lines of Terraform. Multi-AZ with automatic failover, plus a subnet group that spans three zones so the standby always lands somewhere other than the primary:

# Plain RDS for MySQL. Aurora is a different resource shape
# (aws_rds_cluster + aws_rds_cluster_instance), same idea.
resource "aws_db_instance" "commerce" {
  engine                  = "mysql"
  instance_class          = "db.r6g.2xlarge"
  allocated_storage       = 500
  multi_az                = true          # synchronous standby in a second AZ, automatic failover
  backup_retention_period = 7
  storage_encrypted       = true
  # subnet group spanning three AZs so the standby lands in a different zone
  db_subnet_group_name    = aws_db_subnet_group.three_az.name
}

resource "aws_db_subnet_group" "three_az" {
  name       = "commerce-three-az"
  subnet_ids = [aws_subnet.az_a.id, aws_subnet.az_b.id, aws_subnet.az_c.id]
}

And the web tier is an Auto Scaling group that adds PHP-FPM instances when CPU climbs, which is exactly the behavior you want when the 9am doorbuster hits:

resource "aws_autoscaling_group" "web" {
  min_size            = 3                # one warm instance per AZ
  max_size            = 30              # room to absorb the spike
  vpc_zone_identifier = [aws_subnet.az_a.id, aws_subnet.az_b.id, aws_subnet.az_c.id]
  target_group_arns   = [aws_lb_target_group.web.arn]

  launch_template {
    id      = aws_launch_template.php_fpm.id   # NGINX + PHP-FPM baked into the AMI
    version = "$Latest"
  }

  # scale out on sustained CPU - the doorbuster signal
  # (a target-tracking policy at ~60% CPU is the boring, correct default)
}

None of this is exotic. It's the standard AWS reference architecture, and it produces the same four survival properties the Adobe cluster has.

What you actually give up (and what you gain)

So if the architecture is reproducible, what is Adobe's invoice buying? Be honest about this, because it's the whole decision.

You give up operations. Adobe patches the OS, manages the Galera cluster, runs the Fastly relationship, bundles New Relic, mirrors your production topology in a Staging environment, and answers the phone when something breaks at 2am. That last one is not nothing. When you self-host, the pager is yours. The person who wakes up when RDS fails over is on your team, not Adobe's. For a lot of merchants, "we don't want to be the ones holding the pager on Black Friday" is a completely rational reason to pay.

You also give up some conveniences that are genuinely bundled: Fastly at no additional cost, a Staging environment that mirrors Production, the managed WAF, the support SLA. Rebuild it yourself and each of those is a line item and a responsibility.

What you gain is control and economics. You pick your AWS region instead of taking whatever Adobe provisions. You get root on your own boxes. You're not gated behind a Pro 48 plan to split your tiers, you scale exactly the component that's hot. And past a certain size, the raw AWS bill for this architecture is a fraction of the Adobe Cloud license, because you're paying for compute instead of for compute-plus-platform-plus-support.

So do you need it?

Here's the verdict, and it's a fork, not a slogan. Surviving Black Friday is an architecture problem, and the architecture is a three-node, multi-AZ, edge-cached, autoscaling cluster that you can absolutely build on AWS. Adobe Commerce Cloud does not sell you a secret that makes traffic spikes survivable. It sells you the operational burden lifted off your team, on infrastructure that is, underneath the branding, a standard AWS deployment.

So the real question was never "can my store survive Black Friday without Adobe Cloud." It obviously can. The real question is "do I want to run this myself, or pay someone to run it for me." If you have a platform team that's comfortable with Terraform, RDS failover, and an on-call rotation, self-hosting gets you the same survival properties with more control and a smaller bill. If you don't, and you'd rather your engineers ship features than babysit a Galera cluster at midnight, then paying Adobe to hold the pager is a defensible call, as long as you're paying for the operations and not because you believed the infrastructure was something you couldn't build.

Just don't let anyone tell you it's a fortress you couldn't have built. It's three nodes behind a load balancer, across three zones. You've built bigger.

---

Originally published at andriiboyko.com.