Support for European Sovereign Cloud

[MarkitectRoss]

Is your feature request related to a problem? Please describe.
Due to lack of Code Pipeline and other services (e.g. Code Build) and planned road map, it won't be possible to utilize LZA in European Sovereign Cloud region until Q1 2027

Describe the feature you'd like
Ability to deploy LZA in European Sovereign Cloud, given it went GA on 15th January 2026. It seems reasonable that customers would be able to deploy an AWS prescribed multi-account architecture aligned to best practice at the launch of a region that's whole purpose is to provide appropriate security and governance for people in Europe.

Additional context
Presumably this could be fixed by either a) leaning on Code Pipeline and other service teams to advance Q1 2027 delivery or removing the LZA dependency on Code Pipeline, Code Build etc.

[benbridts]

another possible (temporary) solution is:

• using an External pipeline deployment
  .
• Change the build script to use AWS credentials from another source.

The easiest other source is an IAM user access key in the LZA Management account, a much better solution is using the new JWT token based federation (in the commercial region) with SignInWithWebIdentity (in EUSC)

[MarkitectRoss]

another possible (temporary) solution is:

• using an External pipeline deployment
  .
• Change the build script to use AWS credentials from another source.

The easiest other source is an IAM user access key in the LZA Management account, a much better solution is using the new JWT token based federation (in the commercial region) with SignInWithWebIdentity (in EUSC)

Hi Ben,

Thanks for the quick reply. Using an external pipeline, e.g. one from an account in the commercial AWS region, defeats the point of having a European Sovereign Cloud.

None of the customers I would work with who'd be willing to pay a premium for services in the EUSC would do so knowing the very foundations, including permissions and who can access the environment, was being controlled from a pipeline and IaC hosted in the commercial cloud that didn't have the same controls in place.

I might use what you describe for a PoC to see if the templates (e.g. unified config) work, but beyond that we need a proper solution from AWS to this issue. Surprised it wasn't available on day 1 given it's the first thing an enterprise would need...

[benbridts]

Using an external pipeline, e.g. one from an account in the commercial AWS region, defeats the point of having a European Sovereign Cloud.

Different customers will have different requirements, and the external pipeline can be a good (temporary) solution for customers that are going to be running workloads in different partitions anyway.

And in that sense it beats using e.g GitHub (not-enterprise) as a CodeBuild replacement.

but beyond that we need a proper solution from AWS to this issue

I do agree that the only full solution here is CodePipeline, CodeBuild and CodeCommit support in EUSC (and I recommend raising that with your account team as well)

[MarkitectRoss]

With my job zero security hat on if were to orchestrate multiple partitions from one pipeline I'd want to do that from the highest security domain (EUSC), not the lowest security domain (commercial), rather than the other way around.

Maybe there are some use cases where the customer doesn't want EUSC for its enhanced security and governance, but simply because it's a separate partition so entirely separate fault domain for everything including IAM. In that case they'd be treating them as the same security domain so they'd be ok with it. I assume that number of customers will be low though given the EUSC price premium.