A EUSC é uma partição independente — e isso muda tudo
A AWS European Sovereign Cloud (EUSC) é uma nuvem independente, fisicamente e logicamente separada das demais regiões AWS, operada inteiramente dentro da União Europeia. Ela oferece os mesmos serviços, funcionalidades e APIs das regiões comerciais da AWS, mas funciona como uma partição distinta: aws-eusc. Essa partição tem seu próprio plano de controle, AWS Identity and Access Management (IAM), faturamento, console e endpoints de serviço.
A AWS organiza suas regiões em partições. As regiões comerciais estão na partição aws, as regiões da China em aws-cn, as GovCloud em aws-us-gov, e agora a EUSC em aws-eusc — com sua primeira região em Brandemburgo, Alemanha (eusc-de-east-1). Compreender esse conceito de partição é a chave para responder corretamente perguntas sobre consolidação de faturamento, SSO, roles entre contas, AWS Direct Connect e distribuição de imagens.
Algumas diferenças práticas entre a AWS comercial e a EUSC merecem atenção:
- O prefixo de ARN muda de
arn:aws:paraarn:aws-eusc: - O domínio dos endpoints passa de
amazonaws.comparaamazonaws.eu - O AWS Organizations, o IAM Identity Center e o faturamento são instâncias completamente separadas
- Funcionalidades entre partições — como
sts:AssumeRole, VPC peering, Transit Gateway, AWS RAM e replicação S3 — não estão disponíveis entreawseaws-eusc
Isso significa que qualquer integração entre a nuvem comercial e a EUSC deve acontecer na camada de rede ou de API, com credenciais separadas para cada partição.
IaC com consciência de partição
Um dos erros mais comuns ao migrar infraestrutura para a EUSC é deixar ARNs com arn:aws: fixos no código. A AWS recomenda que os scripts Terraform e templates CloudFormation derivem a partição dinamicamente, garantindo que o mesmo código funcione tanto em regiões comerciais quanto na EUSC.
No Terraform, o padrão é usar o data source aws_partition para construir ARNs de forma dinâmica:
# Terraform: partition-aware ARNs (works unchanged in aws and aws-eusc)
data "aws_partition" "current" {}
data "aws_region" "current" {}
data "aws_caller_identity" "current" {}
data "aws_organizations_organization" "current" {}
locals {
partition = data.aws_partition.current.partition # "aws" or "aws-eusc"
account_id = data.aws_caller_identity.current.account_id
org_id = data.aws_organizations_organization.current.id
ecs_task_execution_policy_arn = "arn:${local.partition}:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
central_logs_bucket_arn = "arn:${local.partition}:s3:::${local.org_id}-central-logs"
}
resource "aws_iam_role" "amazon_ecs_role" {
name = "AmazonECSrole"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Action = "sts:AssumeRole"
Effect = "Allow"
Sid = ""
Principal = {
# IAM service principals are "amazonaws.com" across all partitions,
# this stays literal (do NOT use ${AWS::URLSuffix} here).
Service = "ecs-tasks.amazonaws.com"
}
},
]
})
}
resource "aws_iam_role_policy_attachment" "amazon_ecs_role_attach" {
role = "AmazonECSrole"
# Use ${local.partition} rather than hardcoding "aws" in the ARN.
policy_arn = "arn:${local.partition}:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
}No AWS CloudFormation, o pseudo-parâmetro ${AWS::Partition} cumpre o mesmo papel — nunca se deve fixar o valor literal aws em ARNs dentro de templates:
# CloudFormation: use the AWS::Partition pseudo parameter, never a literal "aws"
AWSTemplateFormatVersion: "2010-09-09"
Description: >-
Creates an ECS task execution role. Demonstrates using the ${AWS::Partition}
pseudo parameter in ARNs instead of hardcoding "aws", so the template works
across partitions (aws, aws-cn, aws-us-gov, aws-eusc).
Resources:
ExecRole:
Type: AWS::IAM::Role
Properties:
RoleName: AmazonECSroleCF
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service:
# IAM service principals are "amazonaws.com" across all partitions,
# so this stays literal (do NOT use ${AWS::URLSuffix} here).
- "ecs-tasks.amazonaws.com"
Action: "sts:AssumeRole"
ManagedPolicyArns:
# Use ${AWS::Partition} rather than hardcoding "aws" in the ARN.
- !Sub "arn:${AWS::Partition}:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
Outputs:
ExecRoleArn:
Description: ARN of the created ECS task execution role
Value: !GetAtt ExecRole.ArnVale notar que os service principals do IAM (amazonaws.com) permanecem iguais em todas as partições — este é um dos poucos pontos onde não se usa a variável de partição.
Estrutura de contas e governança
A AWS recomenda seguir o modelo multi-conta do AWS Security Reference Architecture (AWS SRA) para implantações na EUSC. O AWS Control Tower está disponível na partição e orquestra o AWS Organizations, o AWS Service Catalog e o AWS IAM Identity Center para montar uma landing zone em menos de uma hora.
A conta de gerenciamento deve ser usada exclusivamente para governança. Guardrails de segurança universais devem ser aplicados via SCPs (Políticas de Controle de Serviço), RCPs (Políticas de Controle de Recursos) e implantações de serviços como o AWS CloudTrail que afetam todas as contas-membro da organização.
Diferente do que ocorre em regiões comerciais, SCPs de bloqueio de região não são obrigatórios na EUSC no momento — a separação física e lógica da partição já garante o isolamento. Porém, se novas regiões EUSC forem adicionadas no futuro e for necessário restringir o uso a um subconjunto delas, um SCP de bloqueio de região passará a ser relevante.
Identidade: IAM Identity Center como infraestrutura como código
O IAM Identity Center está disponível na EUSC como uma instância independente dentro da partição. É possível conectá-lo ao provedor de identidade corporativo (IdP) — Microsoft Entra ID, Okta, entre outros — via SAML/SCIM, exatamente como nas regiões comerciais. Se a organização já usa o Identity Center na partição comercial, basta apontar uma segunda integração para o mesmo IdP corporativo, mantendo um único conjunto de credenciais para os usuários.
A recomendação é gerenciar permission sets e atribuições como código. O Terraform abaixo define um permission set com política gerenciada pela AWS e política inline de menor privilégio, atribuindo um grupo a uma conta-alvo:
data "aws_ssoadmin_instances" "this" {}
data "aws_partition" "current" {}
# Workload account the group is assigned to.
variable "analytics_workload_account_id" {
type = string
description = "Account ID of the workload account to assign the permission set to"
}
locals {
sso_instance_arn = tolist(data.aws_ssoadmin_instances.this.arns)[0]
identity_store_id = tolist(data.aws_ssoadmin_instances.this.identity_store_ids)[0]
}
resource "aws_ssoadmin_permission_set" "analytics_operator" {
name = "AnalyticsOperator"
description = "Operate analytics workloads; no IAM or billing"
instance_arn = local.sso_instance_arn
session_duration = "PT4H"
}
# Attach an AWS managed policy
resource "aws_ssoadmin_managed_policy_attachment" "analytics_ro" {
instance_arn = local.sso_instance_arn
permission_set_arn = aws_ssoadmin_permission_set.analytics_operator.arn
managed_policy_arn = "arn:${data.aws_partition.current.partition}:iam::aws:policy/ReadOnlyAccess"
}
# Add a least-privilege inline policy (note the partition-aware ARNs)
resource "aws_ssoadmin_permission_set_inline_policy" "analytics_inline" {
instance_arn = local.sso_instance_arn
permission_set_arn = aws_ssoadmin_permission_set.analytics_operator.arn
inline_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Sid = "OperateAnalyticsData"
Effect = "Allow"
Action = ["s3:GetObject", "s3:PutObject", "s3:ListBucket"]
Resource = [
"arn:${data.aws_partition.current.partition}:s3:::analytics-*",
"arn:${data.aws_partition.current.partition}:s3:::analytics-*/*"
]
Condition = {
StringEquals = {
"aws:RequestedRegion" = "eusc-de-east-1"
}
}
}]
})
}
# Group for analytics operators.
resource "aws_identitystore_group" "analytics" {
identity_store_id = local.identity_store_id
display_name = "analytics-operators"
description = "Analytics operators"
}
# Assign the group to a workload account with the permission set
resource "aws_ssoadmin_account_assignment" "analytics_to_workload" {
instance_arn = local.sso_instance_arn
permission_set_arn = aws_ssoadmin_permission_set.analytics_operator.arn
principal_id = aws_identitystore_group.analytics.group_id
principal_type = "GROUP"
target_id = var.analytics_workload_account_id
target_type = "AWS_ACCOUNT"
}Nenhum usuário recebe acesso direto à conta de gerenciamento — todo acesso humano flui via permission sets do IAM Identity Center atribuídos a contas não-gerenciais. Roles entre contas dentro da partição EUSC funcionam normalmente para governança, logging e ferramentas de segurança:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:${AWS::Partition}:iam:::role/SecurityAuditCollector"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "eusc-sec-audit"
},
"ArnLike": {
"aws:PrincipalArn": "arn:${AWS::Partition}:iam::*:role/SecurityAuditCollector"
}
}
}]
} Uma role na partição aws não pode assumir uma role na aws-eusc, e vice-versa.
Logging e monitoramento centralizados na EUSC
Uma arquitetura de logging soberana requer três elementos: um repositório único e imutável para todos os logs de auditoria e operação, uma conta de segurança central que executa controles detectivos e correlaciona findings, e um caminho confiável dentro da partição para alimentar o SIEM sem que os dados saiam do limite soberano.
A conta de Log Archive armazena a trilha organizacional e o bucket central de logs. Uma diferença importante em relação à AWS comercial: na EUSC, eventos de serviços globais como o IAM são registrados dentro da própria partição EUSC, pois o plano de controle é independente e localizado inteiramente na UE.
O Amazon GuardDuty e o AWS Security Hub estão disponíveis na EUSC, mas algumas funcionalidades de habilitação automática em nível organizacional podem diferir da AWS comercial. A recomendação é configurar a conta de Security Tooling como administrador delegado onde suportado. Se a habilitação automática por organização ainda não estiver disponível, use AWS CloudFormation StackSets para habilitar por conta via IaC. Consulte a lista de serviços e funcionalidades da EUSC como fonte de verdade.
Rede e perímetro, incluindo Direct Connect
A EUSC possui seus próprios pontos de presença (PoPs) do AWS Direct Connect, com infraestrutura dedicada e conectividade de provedores europeus. Uma conexão Direct Connect ou gateway Direct Connect da partição comercial não pode ser estendida para a aws-eusc. Para alcançar VPCs na EUSC, é necessário provisionar uma conexão Direct Connect separada que chegue à conta de Rede da partição EUSC.
O design recomendado termina o Direct Connect em uma conta de Rede dedicada e compartilha a conectividade para VPCs de workload usando Transit Gateway (com AWS RAM).
Os principais elementos do design de perímetro incluem:
- Egresso centralizado e inspeção — rotear o tráfego de saída dos workloads por uma VPC de inspeção na conta de Rede (Gateway Load Balancer com firewall de escolha, ou AWS Network Firewall), mantendo VPCs de workload privadas sem internet gateway
- Acesso privado a serviços — usar VPC interface endpoints (VPCe) para chamadas a serviços AWS, mantendo o tráfego na rede AWS dentro da partição
- DNS — a EUSC tem seu próprio Amazon Route 53; para nomes que precisam resolver entre nuvens, usar delegação de subdomínio ou regras de encaminhamento do Resolver sobre o link DX ou VPN
- Segmentação como código — expressar a segmentação com security groups referenciando prefix lists e manter os ranges de IP da EUSC atualizados a partir do arquivo
ip-rangespublicado pela partição
Proteção de dados e gerenciamento de chaves
O AWS Key Management Service (AWS KMS) está disponível na EUSC. A recomendação é usar chaves gerenciadas pelo cliente para todos os datastores sensíveis e impor seu uso via SCPs e políticas de chave.
Para workloads onde regulamentações exigem que o material de chave nunca resida na infraestrutura do provedor de nuvem, a AWS disponibiliza o AWS KMS External Key Store (XKS) na região EUSC. O proxy XKS conecta o AWS KMS ao HSM (Módulo de Segurança de Hardware) baseado na UE — on-premises ou hospedado com um provedor de serviços de confiança europeu — e todas as operações de criptografia e descriptografia são realizadas pelo gerenciador de chaves externo. É importante considerar as contrapartidas: maior latência, SLA de disponibilidade reduzido e maior carga operacional. O XKS deve ser reservado para o subconjunto de dados onde obrigações regulatórias ou contratuais explicitamente o exigem.
A região EUSC já alcançou as certificações SOC 2, BSI C5 Type 1 e sete certificações ISO, incluindo ISO 27001, 27017, 27018 e 27701.
CI/CD seguro e distribuição de imagens entre partições
Não é possível usar replicação cross-partition do Amazon Elastic Container Registry (Amazon ECR), cópia de Amazon Machine Image (AMI) ou replicação do Amazon S3 entre a AWS comercial e a EUSC. A EUSC deve ser tratada como um destino independente na cadeia de suprimentos de software:
- Imagens de container — construir (ou re-taguear e re-assinar) imagens e publicar em um registro ECR dentro da EUSC. A replicação cross-Region do ECR funciona dentro da partição, mas a travessia inicial da nuvem comercial é um push explícito via pipeline usando credenciais EUSC.
- AMIs e imagens — reconstruir imagens golden na EUSC com o EC2 Image Builder (executando o pipeline nativamente na EUSC), ou importar imagens de VM usando o Amazon S3 na EUSC e o comando
aws ec2 import-image. Não há cópia direta de AMI entre partições. - Binários e artefatos — armazenar em um bucket de artefatos na conta de Shared Services da EUSC. Mover pacotes entre partições com
aws s3 syncou AWS DataSync sobre DX ou VPN.
O exemplo abaixo mostra como publicar uma imagem de container no ECR dentro da EUSC (note o endpoint .eu):
# Push a container image to ECR inside EUSC (note the .eu endpoint).
# Credentials/profile must be for the aws-eusc partition.
aws ecr get-login-password --region eusc-de-east-1 --profile eusc-shared-services \
| docker login --username AWS --password-stdin \
111122223333.dkr.ecr.eusc-de-east-1.amazonaws.eu
docker tag company/runtime:7.x \
111122223333.dkr.ecr.eusc-de-east-1.amazonaws.eu/company/runtime:7.x
docker push \
111122223333.dkr.ecr.eusc-de-east-1.amazonaws.eu/company/runtime:7.xPara o plano de implantação, a recomendação é rodar um pipeline nativo na EUSC — AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy ou ferramentas equivalentes implantadas dentro da partição — na conta de Shared Services, com roles de deploy entre contas para os workloads. Se um sistema de CI da partição comercial precisar implantar na EUSC, ele deve ter credenciais separadas para cada partição, pois não existe assunção de role entre partições.
// Deploy role in an EUSC workload account, trusted by the EUSC Shared Services pipeline role
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws-eusc:iam:::role/PipelineDeployRole"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "EUSC-deploy"
}
}
}]
} Para vending de contas e landing-zone-as-code, a AWS recomenda usar o Account Factory for Terraform (AFT) implantado na EUSC. O estado Terraform de cada partição deve ser mantido em um backend Amazon S3 dentro da EUSC com uma tabela de lock no Amazon DynamoDB — nunca compartilhando estado entre partições.
O Landing Zone Accelerator on AWS (LZA) é uma alternativa de implantação que provisiona uma arquitetura de segurança de base com customizações por partição. Uma configuração baseline para a European Sovereign Cloud foi recentemente disponibilizada, acompanhada de um LZA Compliance Workbook que mapeia padrões europeus de segurança a mais de 200 configurações implantadas pelo LZA.
Faturamento e governança de custos
O faturamento deve ser consolidado dentro da organização EUSC — não entre partições. A EUSC possui um payer separado (faturado em EUR pela entidade contratante europeia). A recomendação é habilitar o faturamento consolidado na conta de gerenciamento da EUSC e entregar os AWS Data Exports (Cost and Usage Report 2.0) a um bucket S3 em uma conta de finanças ou governança dedicada. Dados de faturamento não podem ser replicados para a partição comercial.
Conclusão
Arquitetar na AWS European Sovereign Cloud é, em grande parte, construir uma segunda landing zone AWS bem gerenciada, com um princípio organizador que resolve quase todas as dúvidas de design: ela é uma partição independente. A centralização de governança, identidade, logging e faturamento é totalmente alcançável — mas dentro da partição EUSC.
Os limites entre a AWS comercial e a EUSC — sem roles, peering, replicação ou faturamento entre partições — são as garantias de soberania funcionando como esperado. A base deve ser construída como código: uma landing zone AWS Control Tower conduzida pelo AFT, permission sets do IAM Identity Center em Terraform federados ao IdP corporativo, um repositório central imutável de logs, chaves de criptografia gerenciadas pelo cliente restritas à região soberana, e uma conta de Rede terminando um Direct Connect dedicado.
Para acelerar a implantação, a AWS disponibiliza a LZA Universal Configuration for European Sovereign Cloud no GitHub, que empacota muitos dos padrões descritos neste artigo em uma baseline pronta para implantação. Para complementar com conformidade, o LZA Independent Assessment Report for C5:2020 avalia como a baseline de segurança do LZA mapeia para os requisitos técnicos do C5:2020, disponível para download no AWS Artifact.
Leituras recomendadas
- AWS Security Reference Architecture (AWS SRA)
- AWS Well-Architected Framework e o Pilar de Segurança
- AWS European Sovereign Cloud e soberania digital europeia e visão geral de conformidade
- Organizando seu ambiente AWS com múltiplas contas
- AWS Control Tower e Account Factory for Terraform (AFT)
- Guia do IAM Identity Center (EUSC)
Fonte
Architecting a secure landing zone in the AWS European Sovereign Cloud (https://aws.amazon.com/blogs/security/architecting-a-secure-landing-zone-in-the-aws-european-sovereign-cloud/)
Leave a Reply