Adobe Commerce Cloud done without the cloud-bill nightmare

It depends on your team and traffic profile. ACC is worth it when (a) you don’t want to manage servers, Fastly, New Relic, deploy pipelines, and Adobe-tier patching, (b) your traffic is variable and elastic scaling matters, or (c) you need the bundled support & SLA. It’s not worth it when (a) your team already runs DevOps fluently, (b) traffic is small and steady so a $50/mo VPS would do, or (c) you want full control over kernel-level optimisations. Most stores in $1k-$15k/mo MRR profit from ACC; below that, self-hosted on Hetzner/AWS is cheaper.

The four biggest wins, in order:

• Right-size your environments, most ACC stores are 2-3× oversized on RAM & CPU. Adobe doesn’t volunteer this analysis.
• Fix Fastly cache-hit rate, moving from 60% to 90%+ cache-hit rate cuts origin bandwidth 10× and origin compute alongside.
• Audit add-ons, paid add-ons (extra environments, BlackHat, B2B, etc.) often carry beyond their useful life.
• Optimise asset storage, old media library, unused product images, orphaned PDFs, all billed monthly.

A 90-day audit typically uncovers 30-50% potential savings on the monthly invoice.

Common culprits:

• Static content compilation runs on every deploy, fix with SCD_ON_DEMAND_IN_PRODUCTION or skip-static-content build hooks.
• Composer install fetches from scratch, fix with cached composer + COMPOSER_AUTH proper setup.
• Deploy hooks run sequentially when they could parallelise.
• Database upgrade scripts on every deploy, fix with skip patches that haven’t changed.

Tuned correctly, ACC deploys go from 25-40 minutes to 3-5 minutes. We do this on every Standard Cloud Migration project.

ECE-Tools (Magento\CloudPatches + magento/ece-tools composer package) is the deploy/build orchestrator for ACC. It runs your .magento.app.yaml + .magento.env.yaml hooks, generates static content, applies Adobe’s cloud patches, and configures redis/varnish/fastly. Tuning ECE-Tools is the difference between a 5-minute and a 40-minute deploy. Most stores never look at it. We do.

The default Fastly config that ships with ACC is generic, it’s a starting point, not the destination. Real tuning involves:

• Custom VCL for query-param normalisation, geo-routing, A/B-test splitting
• Image optimisation edge rules (WebP/AVIF on the fly)
• ESI fragments for personalised blocks (cart, customer name)
• Proper Surrogate-Key tagging so cache-purge is targeted not nuclear
• Bot-protection rules + rate limits

Done right, you go from 60% to 90%+ cache-hit rate, which cuts origin compute by 10× and bandwidth costs alongside.

Yes, with proper planning. The pattern: (1) spin up ACC Integration with a full database dump from your current production, (2) validate functionality on Integration + Staging, (3) set up real-time DB replication from old → new for the cutover window, (4) off-peak DNS swap with TTL pre-lowered to 60s, (5) keep old system warm for 72 hours as roll-back. Total downtime: typically 0-30 seconds during the DNS flip. Order data flows to new system immediately.

ACC Starter: Single AWS region, shared infrastructure, no Fastly Image Optimizer, max 4 envs, minimal SLA. Best for stores under $1M GMV. ACC Pro: Dedicated 3-node AWS cluster, Fastly Image Optimizer included, unlimited envs, 99.99% SLA, dedicated support. Best for stores over $1M GMV or with B2B / multi-region needs. Pro is roughly 4-6× Starter pricing but the SLA + Image Optimizer alone often justify it for serious stores.

ACC enforces a 3-tier git branch strategy by design:

• Integration: ephemeral feature branches per developer/PR. Each push triggers a deploy. Used for PR review.
• Staging: mirrors Production data (sanitised) and infrastructure. UAT happens here.
• Production: live store. Only promotions from Staging are allowed.

Done right, each branch has its own data-bridge so a Staging deploy can be tested against real-shape data without touching Production. We set this up properly on every project.

Yes, fully, ACC is just Magento 2 on AWS with managed orchestration. You ship custom modules via composer + git just like self-hosted. The constraints: (a) no kernel-level access (can’t install OS packages), (b) PHP extensions are restricted to Adobe’s supported list, (c) cron jobs run on Adobe’s schedule infrastructure. For 95% of stores, none of this matters. The remaining 5% are typically B2B with custom payment processors or ERP middleware, those need careful pre-project audit to confirm fit.

ACC backs up your DB + media every 6 hours and retains 7 days by default (longer on Pro). However, vendor backups are necessary but not sufficient, for real DR you also want: (a) off-cloud backup copies (S3 to a different account), (b) tested restore runbooks (most teams have backups but never tested restore), (c) point-in-time recovery for transactional data, (d) annual DR drill. Standard Cloud Migration includes setting all of this up; Enterprise includes the DR drill.

Less than you think. ACC is just Magento 2 + AWS + Fastly + New Relic. Your codebase is portable, same composer.json works on a self-hosted server. The only ACC-specific bits are .magento.app.yaml + .magento.env.yaml + ECE-Tools dependency, all of which are open-source. Realistic exit time: 4-6 weeks to migrate from ACC back to self-hosted, vs 8-12 weeks the other way (because you’d need to set up the hosting from scratch). So lock-in is real but recoverable, much less sticky than e.g. Shopify.

Adobe doesn’t publish list prices, but the formula is roughly: base licence (tied to your GMV tier, typically $40k-$200k/year) + infrastructure (compute, bandwidth, storage, typically $1k-$15k/month) + add-ons (extra environments, B2B module, AI services, etc.). Real total: Starter stores pay $5k-$30k/year all-in, Pro stores pay $50k-$300k/year+. The bill grows quickly with traffic and bad caching, which is why our cost-optimisation pass typically pays for itself within 2-3 months from invoice savings alone.