The Divergence Tax

In April 2015 AWS Lambda went GA, but it didn’t manage to reach GovCloud (US) before 18 May 2017. That’s 25 months, and the GovCloud region had been open since August 2011. AWS’s own policy for new services is twelve months. Anything built on Lambda in that window shipped to the commercial edition alone.

Any organization that trying to make its product compliance-ready, whether that is a FedRAMP authorization or a sovereign region, starts with a budget and a date. The budget is often “soft” even for the people who set it. The GAO’s January 2024 review of FedRAMP found that “data on actual costs were limited.” Agencies and providers had supplied estimates.

However, that doesn’t reveal that this “second environment” is essentially a second product. It gets its own release calendar from day 1. Its dependency list diverges from the commercial one quite rapidly. Every release needs its own evidence, and nobody has budgeted or forecast that divergence.

That boundary is going to be operated as a “second release train”, and the cost unit it runs on is the divergence rate against the commercial version. The same holds for a sovereign or an on-prem edition of the same product. For example, how many features you ship on your commercial edition against your compliant one, and how long the lag runs. That “lag” is old news for anybody who has run GovCloud workloads. However, nobody seems to measure that cost unit. So start measuring that lag, first to keep it stable, then to bring it down. How you build the boundary sets the rate. The regulation has less to say about it than you’d assume.

Where the Lag Comes From

Once the boundary exists, every feature you build ships twice. Or it ships once and waits. That waiting is structured: your pipeline deploys on Tuesday, but the compliant version needs to pass change control and clear the evidence. Once that is attached and every dependency exists inside the boundary it’s ready to ship. This is the “lag” definition.

AWS states it in its own policy. Its partition guidance reads: “Our general policy is to deliver AWS services, features, and instance types to all AWS Regions within 12 months of becoming generally available.” Twelve months is the policy on paper. Lambda took twenty-five.

The pattern is not US-only. The AWS European Sovereign Cloud went GA on 15 January 2026. Its service roadmap expects CloudFront “by the end of 2026” and CodeBuild and CodePipeline in Q1 2027. A product that sits behind a CDN waits close to a year for its sovereign edition. The build tooling waits longer.

Continuous monitoring covers everything inside the boundary, so each deployment into it needs its own artifacts. Scan results, change records, control mappings and approvals, for that environment and that release. A pipeline that emits those as it runs now emits them twice. One that doesn’t leaves someone to reconstruct them by hand. I’ve been through a FedRAMP Moderate authorization on Azure Government, and the controls themselves were rarely the hard part. The hard part was the shared-nothing duplicate of the platform, and the evidence for every release inside it.

Config diverges first. A flag defaults off in the boundary because its dependency is missing. Then a service gets swapped for the one that is there, and now the code differs. Nobody decides to fork the product. The fork accumulates one workaround at a time.

What the Vendors Say

Companies selling the compliant editions document the gap themselves. Microsoft states the mechanism in its Office 365 US Government service description: “there may be some differences or delays for specific service updates due to compliance requirements.” The rows below span both regimes, FedRAMP and GovCloud in the US and the European Sovereign Cloud and Delos in the EU, and are published by the vendors or, where marked, by a partner.

Slack’s engineers wrote the clearest account of how the fork gets built. In “What We Learned from Building GovSlack”, from January 2023, they describe “a full shared-nothing paradigm, which enables the environments to operate in completely different AWS organizations.” The Cloud Foundations team “spent almost two quarters setting up the infrastructure needed to run GovSlack.” Their partition still “lacks some AWS services, such as CloudFront and public zones in Route53.” A boundary built on a boundary inherits both divergence rates. I heard the same thing a few years ago, from a team going through FedRAMP for the first time. People were skeptical that you could build a product on GovCloud without carrying half the platform yourself. By then it held FedRAMP High and DoD IL5, more than the commercial regions did. That was a divergence judgment.

AI Features Lag Most

If you check what the vendors have in common, you will notice the features missing from the compliant editions are the newest ones. Right now the newest features are AI. Microsoft’s list above is all Copilot features, Zoom’s includes AI Companion, and Azure Government lists Defender for AI Services as “Not Available.” The sovereign side lags the same way: Microsoft’s in-country data processing for Copilot reached four countries by the end of 2025, with Germany, Italy, Spain and Sweden promised for 2026.

AI features depend on model endpoints, accelerators and managed AI security, the services least likely to exist inside a boundary. So the AI part of the roadmap carries the highest divergence rate. An agent strategy inherits the lag of every connector it needs. GovSlack does not yet support the MCP server, so an agent that reaches Slack commercially stops at the boundary.

What the Regulation Says

In July 2024, OMB told GSA in Memorandum M-24-15 that “FedRAMP should not incentivize or require commercial cloud providers to create separate, dedicated offerings for Federal use.” The policy asks for shared infrastructure while the market keeps shipping separate editions. FedRAMP 20x, the 2025 redesign of the authorization process, has reformed the evidence. It runs on ten Key Security Indicators and machine-readable submissions instead of control narratives. On tenancy, 20x says nothing. Its Minimum Assessment Scope covers “all information resources that are likely to handle federal information” and contains no provision about tenancy. The Rev5 Authorization Boundary Guidance does not mention tenancy either.

The EU regulates the other end of the same relationship. The Data Act applies since 12 September 2025. It caps the notice period for switching cloud providers at two months and bans switching charges from January 2027. The Act makes leaving a sovereign edition cheaper, and it says nothing about what that edition ships. The sovereign region has the same silence built in. AWS describes its European Sovereign Cloud as “physically and logically separate from other AWS Regions,” with “zero operational control outside of EU borders.”

So the reform on either side lowers the cost of evidence or of exit, but it doesn’t lower the divergence rate. That is because the rate is set by the environments you ship to and what exists inside each one.

What Requires Separation

Some separation is real. The list is shorter than the habit suggests, though many customers require complete control over operational access, or even over telemetry. On the edge and IoT side I’ve seen customers run deep supply-chain audits, even for physical devices, and that results in new requirements and therefore product variants.

At higher impact levels, US-persons requirements govern who may operate and support the environment. The European Sovereign Cloud answers the same question with operations “exclusively by EU residents” and German subsidiaries “led by EU citizens.” ITAR and CJIS bring their own staffing and access rules. FIPS-validated cryptography constrains the libraries and endpoints you can use. Each of these pushes you toward a separate operation. None of them requires a separate release train. Sometimes the operators must differ or the data must sit in one country, and a shared control plane is off the table. Then at least the fork has a price on it.

Two vendors chose shared infrastructure publicly. Cloudflare reached FedRAMP High in August 2026. Cloudflare for Government “runs on the same software and architecture as Cloudflare’s global network,” using what the company calls “software-defined regionality,” the same mechanism its Data Localization Suite sells in Europe. Salesforce runs Government Cloud Plus on its shared Hyperforce infrastructure.

The divergence rate depends on where your dependencies live. A managed service has to exist inside the boundary before you can ship anything built on it. An immutable artifact you build yourself only needs compute, and compute is what a new boundary gets first. The European Sovereign Cloud launched with EC2, Lambda, ECS, EKS, Fargate and ECR on day one. The CDN is expected two years later!

That is the shape that keeps one release train:

• One artifact with one hash, promoted through all deployment targets;
• A shared control plane with isolated data planes per boundary;
• Per-target configuration and feature flags instead of branches, so a missing dependency turns a flag off;
• Evidence, such as the SBOM, the signatures and the scan results, generated by the pipeline run that produced the release.

FedRAMP 20x asks for the same architecture on security grounds. Its Key Security Indicators include Cloud Native Architecture, with “immutable infrastructure with strictly defined functionality and privileges by default” as a validation point.

It is not the default. In CNCF and SlashData’s Q1 2026 developer survey, 7% of the backend developers surveyed report immutable infrastructure practices and 13% use feature flags.

Where to Start

The number I’d put in front of is the divergence rate. Features shipped per year, multiplied by the share that arrive late or never in the boundary, multiplied by the lag. Add the continuous-monitoring evidence per release train. None of it appears on the certification budget. On the P&L, the compliant edition carries a shorter feature list and often a premium. Its revenue is capped while its delivery cost rises, so its gross margin is lower unless the premium covers the gap. The board approved a line item with a date and took delivery of a second product.

1. The tenancy architecture comes first, before the authorization or certification plan. Shared control plane or shared-nothing is an engineering decision, affecting scale and the way data is distributed, and it belongs before the assessor and the budget. Ideally that is the same tenancy model as your public SaaS. When the regime allows it, that is the cheapest option in platform engineering and in divergence rate. Put the projected divergence rate next to the certification cost, in the same approval.

2. List every dependency unavailable in the target boundary. Walk the vendor’s own availability page and mark the services your product touches. Each missing entry is a feature that ships late, so for each one decide whether to wait for the provider or to carry it yourself as a container on the compute the boundary already has. The more of that list you ship as your own immutable artifacts on Kubernetes, the less of your roadmap depends on the provider’s regional calendar. That list is your first estimate of the rate.

3. Make the boundary a deployment target, not a branch: one artifact promoted through every target, with flags scoped to the boundary. The moment the boundary has its own branch it has its own product.

4. Put the divergence rate on the dashboard, features shipped to the commercial edition versus the boundary per quarter and the lag in days, and review it where you review uptime.