AWS European Sovereign Cloud: the cost questions before a migration

The AWS European Sovereign Cloud is not one more AWS region. It is a second AWS cloud with its own partition (aws-eusc), its own accounts, its own IAM and its own billing. The first region, eusc-de-east-1 in Brandenburg, has been generally available since 14 January 2026. You contract with Amazon Web Services EMEA SARL, and prices are set in EUR.

So asking what the same instance costs over there answers the smaller half of the question. The larger half is what it costs to run a second organisation with its own payer, its own commitments and its own cost history, and how that second bill reaches the monthly report. This framework orders the questions FinOps, platform engineering and finance should settle before anything moves.

Where things stand on 10 October 2026

Since launch, AWS has added cost tooling inside the partition and described its billing architecture in more detail. These are the points that matter for a cost decision:

On 24 October 2026 AWS plans to disconnect the partition from the AWS global backbone for several hours to demonstrate independent operation. AWS says service availability will not be affected, though brief connectivity interruptions are possible when traffic switches. For a cost decision this is governance evidence, not a pricing change.

Set the decision boundary first

Whether a workload needs sovereignty controls is a risk and architecture call. A cheaper or dearer-looking price should never settle it. The cost work starts once the organisation knows which workloads genuinely need the extra controls, and who decided that.

Split the portfolio into three groups:

• Workloads with a documented requirement for the separate EU partition, with the source of that requirement (contract, tender, supervisor).
• Workloads for which an existing EU region in the commercial partition and current controls may be enough.
• Shared services and data flows that would connect the two environments: logging, identity, CI/CD, monitoring, backups.

The third group is the one teams forget, and often the most expensive. IAM roles cannot be assumed across the partition boundary, VPC endpoints stop at it, and a Direct Connect connection in the commercial partition cannot be extended into aws-eusc. Every shared service meant to serve both sides ends up existing twice or needs its own bridge.

Review cost at four separate layers

Do not roll the four layers into one figure until each assumption has an owner and a source. A list-price comparison can be arithmetically right and still point the wrong way: a service is missing, a commitment keeps running on the old side, or parallel running lasts three months rather than three weeks.

EUR pricing is not comparability

EUR prices make a European budget easier to read. Most teams, though, compare against a commercial AWS bill priced in USD. That raises two questions that have nothing to do with the partition: which exchange rate the comparison uses, and whether a difference comes from the rate card or from the currency. For a UK team reporting in GBP, there may be a third conversion on top.

Check each one separately:

• The currency of the contract, the invoice and the internal budget, and where a rate is applied.
• Whether enterprise discounts and private terms apply to the new partition or have to be renegotiated.
• The price-list date and exact SKU used in the comparison.
• How tax, support and Marketplace purchases enter internal reporting.

Published third-party comparisons quote flat premiums over Frankfurt. Do not reuse them: they depend on SKU, date and purchase model. Pull the rates for your actual resources from the official price sources of both partitions and keep the export next to the decision, together with the exchange rate used, its source and its date.

A second organisation is a second cost source

AWS describes a separate organisation for the partition, with its own management account and consolidated billing only within that organisation. There is no roll-up across partitions, and billing data cannot be replicated into the commercial partition. Treat the new side the way you would treat a new provider's billing data:

1. Identify the management account, the payer and the access path; avoid direct access to the payer account.
2. Set up a Data Export (CUR 2.0) into a dedicated finance account inside the partition and verify format, granularity and delivery delay. Decide first whether your tooling needs CUR 2.0 or FOCUS.
3. Map accounts and resources to the same cost centres, teams and products as existing reporting, using the same tag keys.
4. Store the currency and cost basis on every record.
5. Reconcile totals to the invoice before building trend or savings reports on the data.

Trends need a visible break at the move. If the report does not know about the partition change, the move shows up as a saving on the old bill and as growth on the new one. Write down the migration date, the old and new scope, and the one-off migration costs.

Review commitments before moving workloads

A commitment only pays off when usage happens inside its scope. With a separate payer and a separate billing system, assume that Savings Plans and reservations bought in the commercial partition do not cover usage in aws-eusc until AWS confirms otherwise in writing. That is an inference from the documented separation, not an AWS statement.

Before buying or moving, find out:

• Which existing commitments cover the usage that is due to move, and when they end.
• Which purchase options the partition offers; its EC2 pricing page lists On-Demand, Savings Plans and Spot, and does not list Reserved Instances.
• Who carries the risk of unused commitments on the old side.
• When the new usage will be stable enough for a commitment of its own.

Maximum coverage is the wrong goal here. Keep the new usage on demand until the migration has shown what it really looks like.

Failure patterns to watch for

• Apparent saving: the commercial bill drops because workloads moved, and nobody adds the new bill.
• Underestimated parallel running: both environments run longer than intended, with duplicated data and monitoring.
• Stranded commitments: a Savings Plan keeps running on the old side after the usage has left.
• Mixed currencies: USD and EUR amounts are summed without a documented rate.
• Duplicated platform services: logging, security tooling and network connectivity are rebuilt per partition and missing from the business case.

Checklist for the decision document

For each workload, record:

• the specific sovereignty requirement and its decision owner;
• required services and confirmed availability in eusc-de-east-1;
• current and proposed billing scope, meaning payer and organisation;
• price source with review date, SKU and currency;
• applicable commitments and private terms on both sides;
• one-off costs, length of parallel running and continuing operational effects;
• data and cost flows across the partition boundary;
• open assumptions, owners and the next review date.

With that table, the argument over whether the AWS European Sovereign Cloud costs more or less becomes something people can check. The same review for Microsoft's deployment models is in Microsoft Sovereign Cloud: compare controls and cost correctly, and the exit side of a move in EU Data Act: plan cloud switching costs before 2027. Where Costfluent itself is based, where its data is held and how it reaches your cloud are set out on the digital sovereignty page.

What Costfluent covers

Costfluent reads the AWS FOCUS Data Export through a read-only IAM role, as the AWS integration page describes. That connection is built for accounts in the commercial AWS partition. Because a role in aws cannot assume a role in aws-eusc, it does not reach an account in the AWS European Sovereign Cloud, and Costfluent does not offer such a connection.

On the commercial side, Costfluent supports the preparation: the baseline per cost centre, team and product before the move, the visible drop after it, and the cost that keeps running on the old side until then. Commitment coverage and utilisation reporting is Planned. The new partition is analysed with the cost tooling inside it.

Sources and method

Checked on 10 October 2026: AWS's Opening the AWS European Sovereign Cloud (14 January 2026), AWS European Sovereign Cloud pricing, Amazon EC2 pricing in the partition, Architecting a secure landing zone in the AWS European Sovereign Cloud (16 September 2026), Console Home cost and usage widget (28 July 2026), AWS European Sovereign Cloud: Demonstrating an independent operation (28 September 2026), the AWS European Sovereign Cloud User Guide and the AWS Summit Hamburg 2026 recap.

Vendor sources establish product and billing characteristics. The tables and checklists are Costfluent recommendations and do not replace an organisation's own legal, security or contract review.