AWS European Sovereign Cloud: the cost questions before a migration

The AWS European Sovereign Cloud is not another region in the existing commercial AWS partition. AWS describes it as separate infrastructure located within the EU. Its first region, in Brandenburg, became generally available on 14 January 2026. Accounts, identity, and billing are separate from the existing AWS cloud.

That makes “What does the same instance cost there?” an incomplete decision question. Before a migration, FinOps, platform engineering, and finance need to establish which costs are comparable, which commitments apply, and how the new bill will enter the monthly report.

Set the decision boundary first

Sovereignty requirements are risk and architecture decisions. FinOps should not replace them with an apparently cheaper price. Cost analysis starts after the organisation has established which workloads genuinely need the additional controls.

Split the portfolio into three groups:

• Workloads with a documented requirement for the separate EU partition.
• Workloads for which an existing EU region and current controls may be sufficient.
• Shared services and data flows that would connect the two environments.

This prevents a blanket migration comparison from mixing a compliance requirement with a pricing exercise.

Review cost at four separate layers

Do not combine these layers into one figure until every assumption has an owner and a source. A list-price comparison can be numerically correct and still support the wrong decision when, for example, a service is unavailable or an existing commitment cannot apply.

Do not confuse EUR pricing with comparability

AWS publishes European Sovereign Cloud pricing and offers contracting in EUR. That is useful for European budgets, but it does not remove every currency question. Check separately:

• The currencies used by the contract, invoice, and internal budget.
• Whether discounts and private terms apply to the new partition.
• The price-list date and exact SKU used in the comparison.
• How tax, support, and Marketplace purchases enter internal reporting.

The AWS Sovereign Cloud documentation identifies the public Price List API as a pricing source. It also shows that not every familiar pricing tool is available inside the new partition. A repeatable export of the rates used is therefore stronger evidence than a calculator screenshot.

Treat billing history as a new data source

A separate partition also creates a separate cost source. Plan its integration as if you were onboarding a new provider dataset:

• Identify the billing account and access path.
• Verify export format, granularity, and delivery delay.
• Map accounts and resources to the same cost centres, teams, and products used by existing reporting.
• Store the currency and cost basis explicitly.
• Reconcile totals to the invoice before using the data for trends or savings reporting.

Historical comparisons need a visible boundary. When a workload changes partition, the report must not mistake the move for organic growth, an anomaly, or a saving. Record the migration date, old and new scope, and one-off migration costs.

Review commitments before moving workloads

Commitment coverage creates value only when the underlying usage occurs in the scope the commitment covers. Before a purchase or migration decision, establish:

• Which existing commitments cover current usage.
• Whether those commitments apply in the Sovereign partition or must be purchased there separately.
• Which commitment terms overlap with the migration plan.
• Who owns the risk of unused commitments if the architecture changes.

The target is not maximum coverage. It is an explicit boundary between stable usage that can be committed and usage that should remain variable until the migration proves its shape.

The decision document to keep

The review can be reduced to one table. For each workload, record:

• the specific sovereignty requirement and its decision owner;
• required services and confirmed availability;
• current and proposed billing scope;
• price source, review date, and currency;
• applicable commitments and private terms;
• one-off and continuing operational effects;
• data and cost flows across the partition boundary;
• open assumptions, owners, and the next review date.

This turns “sovereign cloud costs more or less” into a reviewable decision. Finance sees the budget effect, engineering sees the architecture boundary, and FinOps sees the assumptions that must later be reconciled against real billing data.

Sources and method

The starting sources are AWS's European Sovereign Cloud launch, pricing page, AWS Summit Hamburg recap, and European Sovereign Cloud User Guide, reviewed on 5 September 2026. Vendor sources establish product and billing characteristics; they do not replace an organisation's own legal, security, or contract review.