Guía técnica del AWS European Sovereign Cloud para arquitectos

Cuando AWS anuncia una nueva región, para la mayoría de nosotros el impacto técnico es mínimo: cambiar un código de región en nuestro provider de Terraform y poco más. Pero el AWS European Sovereign Cloud no es una región más. Es una partición completamente nueva — la sexta en la historia de AWS — y eso cambia las reglas del juego.

En enero de 2026, AWS lanzó la primera región del ESC en el estado de Brandeburgo, Alemania, con el nombre eusc-de-east-1. A diferencia de las regiones europeas que ya conocemos — Irlanda (eu-west-1), Frankfurt (eu-central-1) o España (eu-south-2) — el ESC opera bajo la partición aws-eusc, con su propio plano de control, su propio sistema de IAM, su propia infraestructura de facturación y su propia consola en console.amazonaws-eusc.eu.

¿Qué significa esto en la práctica? Que nuestras cuentas actuales de AWS no tienen visibilidad sobre el ESC. Que no podemos hacer assume role entre particiones. Que los ARNs cambian de prefijo. Que los endpoints de los servicios son diferentes. Y que nuestro código de Terraform necesita adaptaciones para funcionar en este nuevo entorno.

En este artículo vamos a desgranar cada una de estas implicaciones técnicas, con ejemplos concretos y configuraciones de Terraform, para que puedas evaluar qué supone desplegar workloads en el ESC y cómo preparar tu infraestructura como código para soportar múltiples particiones.

Qué es una partición en AWS

#

Antes de entrar en las diferencias técnicas del ESC, es necesario entender qué es una partición en AWS, ya que es un concepto con el que la mayoría no hemos tenido que lidiar en el día a día.

Una partición es un grupo de regiones de AWS que comparten una infraestructura de control común: IAM, facturación, endpoints de API y consola de gestión. Cada cuenta de AWS pertenece a una única partición, y no es posible interactuar directamente entre particiones.

Hasta la llegada del ESC, las particiones conocidas públicamente eran:

Lo que hace especial al ESC es que es la primera partición pública nueva en años y la primera diseñada específicamente para cumplir con requisitos de soberanía europea. Esto tiene consecuencias directas en cómo construimos y operamos nuestra infraestructura.

La diferencia más visible es el sufijo DNS. Mientras que en la partición comercial los endpoints siguen el patrón servicio.region.amazonaws.com, en el ESC el patrón es servicio.eusc-de-east-1.amazonaws.eu. Algunos ejemplos:

Otro detalle importante: en la partición comercial, IAM es un servicio global — las políticas, roles y usuarios se crean una vez y son visibles en todas las regiones. En el ESC, IAM es regional (iam.eusc-de-east-1.amazonaws.eu), lo que refuerza el aislamiento pero cambia cómo gestionamos las identidades.

Del mismo modo, los ARNs cambian de prefijo. Un bucket de S3 en la partición comercial tiene un ARN como:

arn:aws:s3:::mi-bucket

Mientras que el mismo recurso en el ESC sería:

arn:aws-eusc:s3:::mi-bucket

Esto afecta directamente a cualquier política de IAM, referencia en Terraform o configuración de CLI que construya o valide ARNs.

Diferencias técnicas clave

#

Ya hemos visto cómo cambian los endpoints y los ARNs, pero las diferencias van mucho más allá. Esta tabla resume los puntos que más impactan a la hora de diseñar y operar infraestructura en el ESC:

Algunos de estos puntos merecen una explicación más detallada.

El concepto más importante que debemos interiorizar es que no hay conectividad nativa entre particiones. No podemos:

• Hacer VPC peering entre una VPC en eu-west-1 y otra en eusc-de-east-1
• Conectar redes mediante Transit Gateway cross-partition
• Hacer sts:AssumeRole desde una cuenta en aws hacia un rol en aws-eusc
• Compartir recursos con RAM (Resource Access Manager) entre particiones
• Replicar un bucket de S3 directamente entre particiones

Si necesitamos comunicar workloads entre ambas particiones, tendremos que recurrir a mecanismos externos: VPN site-to-site, Direct Connect con conexiones separadas, o integración a nivel de aplicación a través de APIs públicas.

Facturación y contratación. La facturación en el ESC se realiza en euros y el contrato se establece con Amazon Web Services EMEA SARL (Luxemburgo), no con AWS Inc. (Seattle). Esto tiene implicaciones para equipos de procurement y finanzas: los Enterprise Discount Programs (EDP), Reserved Instances y Savings Plans de la partición comercial no son transferibles al ESC.

Operación por personal europeo. AWS ha confirmado que el ESC es operado exclusivamente por personal residente en la UE, con controles técnicos que impiden el acceso desde fuera del territorio europeo. Esto incluye tanto el acceso a los datos de los clientes como la operación de la infraestructura subyacente.

IAM y gestión de identidades

#

Este es probablemente el cambio que más impacta en el día a día operativo. En la partición comercial estamos acostumbrados a que IAM sea global: creamos un rol en us-east-1 y lo usamos desde cualquier región. En el ESC, IAM es regional, y eso cambia muchas cosas.

Necesitamos cuentas nuevas en el ESC. No podemos usar nuestras cuentas existentes de la partición aws. El proceso de registro se realiza desde eusc-de-east-1.signin.amazonaws-eusc.eu, y genera una cuenta completamente independiente con su propio root user, su propia facturación y su propia jerarquía de Organizations. Si nuestra organización tiene 50 cuentas en la partición comercial y quiere desplegar workloads en el ESC, necesitará crear y gestionar un segundo conjunto de cuentas con su propia estructura de OUs, SCPs y políticas.

No hay assume role cross-partition. En la partición comercial, es habitual tener una cuenta de identidad centralizada desde la que hacemos sts:AssumeRole hacia cuentas de workload. Este patrón no funciona entre particiones. Un rol en arn:aws:iam::123456789012:role/MiRol no puede asumir un rol en arn:aws-eusc:iam::987654321098:role/MiRol — simplemente no se ven. Si necesitamos que un pipeline de CI/CD en la partición comercial despliegue también en el ESC, tendremos que gestionar credenciales separadas para cada partición. Una opción es configurar dos identity providers en nuestro sistema de CI (por ejemplo, dos configuraciones de OIDC en GitHub Actions o Forgejo Actions), cada uno apuntando a su respectiva partición.

IAM Identity Center (el antiguo SSO) también está disponible en el ESC, pero como instancia independiente. Si lo usamos en la partición comercial para federar acceso con nuestro IdP corporativo (Entra ID, Okta, etc.), tendremos que configurar una segunda integración con el Identity Center del ESC. La buena noticia es que podemos apuntar ambas instancias al mismo IdP corporativo, de modo que nuestros usuarios usen las mismas credenciales. Pero los permission sets, las asignaciones a cuentas y los grupos deberán gestionarse por separado.

Los service principals y las políticas de confianza también se ven afectados. En la partición comercial usamos patrones como lambda.amazonaws.com o ec2.amazonaws.com. En el ESC, debemos verificar si el service principal mantiene el mismo formato o cambia al dominio .amazonaws.eu. En las políticas de confianza de nuestros roles, cualquier referencia hardcodeada a ARNs de la partición aws dejará de funcionar. La recomendación es usar la variable de condición aws:PrincipalArn con patrones que incluyan el prefijo de partición correcto, o mejor aún, usar el data source aws_partition de Terraform (que veremos más adelante) para construir los ARNs dinámicamente.

Networking y conectividad

#

Como hemos visto, no hay conectividad nativa entre particiones. Pero en la práctica, muchas organizaciones necesitarán comunicar workloads entre el ESC y sus regiones comerciales — al menos durante un periodo de transición. Veamos qué opciones tenemos.

VPN site-to-site es la opción más accesible. Podemos establecer túneles IPSec entre un Virtual Private Gateway (o Transit Gateway) en cada partición, igual que haríamos con un datacenter on-premises. El tráfico viaja cifrado por Internet, con las limitaciones de latencia y ancho de banda habituales. Nada cambia respecto a cómo configuramos VPNs hoy, salvo que ambos extremos son AWS — pero en particiones distintas.

Direct Connect también está disponible en el ESC, pero requiere una conexión dedicada independiente. No podemos reutilizar un Direct Connect Gateway de la partición comercial para alcanzar VPCs en aws-eusc. Si ya tenemos presencia en un punto de interconexión europeo, podemos solicitar una segunda conexión hacia el ESC, pero implica un contrato y coste adicional.

DNS y Route 53. El ESC tiene sus propios name servers dedicados con TLDs europeos, y una instancia independiente de Route 53. Las hosted zones de la partición comercial no son visibles desde el ESC y viceversa. Si gestionamos dominios con Route 53 en la partición aws y queremos resolver registros desde el ESC, tendremos que configurar delegación de subdominios o usar forwarders condicionales. Para dominios nuevos que solo vivan en el ESC, podemos usar directamente el Route 53 de aws-eusc.

VPC Endpoints (PrivateLink). Los interface endpoints y gateway endpoints funcionan dentro del ESC para los servicios disponibles, pero no podemos crear un PrivateLink que cruce particiones. Si tenemos un servicio expuesto vía PrivateLink en eu-west-1, los consumidores en eusc-de-east-1 no podrán acceder a él directamente — necesitarán pasar por la VPN/Direct Connect y acceder al servicio a través de su IP privada o un balanceador intermedio.

Rangos de IP. AWS publica los rangos de IP del ESC en un fichero ip-ranges.json separado, disponible en https://docs.aws.eu/general/latest/gr/aws-ip-ranges.html. Si mantenemos security groups, NACLs o firewalls on-premises con listas de rangos de AWS, tendremos que incorporar este nuevo fichero a nuestros procesos de actualización.

Adaptando Terraform para el ESC

#

Si trabajamos con Terraform, la buena noticia es que el soporte para el ESC ya está integrado en las versiones recientes. Terraform 1.14+ con el AWS provider 6.x resuelve los endpoints del ESC de forma nativa — basta con configurar la región:

provider "aws" {
  region = "eusc-de-east-1"
}

OpenTofu 1.11+ también soporta el ESC de forma nativa. Si estamos en versiones anteriores de Terraform, tendremos que actualizar o configurar los endpoints manualmente.

El data source aws_partition es nuestro mejor aliado para escribir módulos que funcionen en cualquier partición. En el ESC devuelve aws-eusc, lo que nos permite construir ARNs dinámicamente:

data "aws_partition" "current" {}

resource "aws_iam_role" "example" {
  name = "mi-rol"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = {
        Service = "ecs-tasks.amazonaws.com"
      }
      Action = "sts:AssumeRole"
    }]
  })

  managed_policy_arns = [
    "arn:${data.aws_partition.current.partition}:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
  ]
}

Este patrón elimina los ARNs hardcodeados con arn:aws:... que romperían en el ESC.

Despliegues multi-partición con provider aliases nos permiten gestionar recursos en ambas particiones desde el mismo código. Cada alias necesita sus propias credenciales, ya que — como hemos visto — no hay assume role cross-partition:

provider "aws" {
  alias  = "esc"
  region = "eusc-de-east-1"
}

provider "aws" {
  alias  = "commercial"
  region = "eu-central-1"
}

resource "aws_s3_bucket" "sovereign_data" {
  provider = aws.esc
  bucket   = "datos-soberanos"
}

resource "aws_s3_bucket" "public_assets" {
  provider = aws.commercial
  bucket   = "assets-publicos"
}

Estado de Terraform separado por partición. No debemos compartir state files entre particiones — el aislamiento es precisamente el objetivo. Cada partición debe tener su propio backend de S3:

terraform {
  backend "s3" {
    bucket = "mi-tfstate-esc"
    key    = "infrastructure/terraform.tfstate"
    region = "eusc-de-east-1"
  }
}

Módulos partition-aware. Si mantenemos módulos reutilizables, podemos usar variables y locals para adaptar el comportamiento según la partición, especialmente para servicios que aún no están disponibles en el ESC:

data "aws_partition" "current" {}

locals {
  is_sovereign = data.aws_partition.current.partition == "aws-eusc"

  enable_cloudfront    = !local.is_sovereign  # No disponible en ESC todavía
  enable_guardduty_org = !local.is_sovereign  # Limitado en ESC
}

CloudFormation también funciona sin modificaciones, ya que el pseudo-parámetro AWS::Partition devuelve aws-eusc automáticamente. Y AWS CDK soporta el ESC desde agosto de 2025 — basta con configurar la región en el stack. Sin embargo, hay una limitación importante: el Landing Zone Accelerator (LZA) no soporta múltiples particiones. Si lo usamos para desplegar nuestra landing zone en la partición comercial, necesitaremos una instancia de LZA separada para el ESC con su propia configuración.

Servicios disponibles y limitaciones

#

El catálogo de servicios del ESC es sorprendentemente amplio para ser una partición nueva. No estamos ante un lanzamiento con cinco servicios y una página de “coming soon”. Según la tabla de endpoints oficial, el ESC cuenta con más de 90 servicios disponibles desde el primer día, cubriendo los pilares habituales: compute (EC2, Lambda), contenedores (ECS, EKS, Fargate), bases de datos (Aurora, DynamoDB, RDS, Redshift), almacenamiento (S3, EBS, EFS, FSx), networking (VPC, Transit Gateway, Direct Connect, Route 53, ELB), seguridad (IAM, KMS, Secrets Manager, Private CA, WAFv2, GuardDuty), IA/ML (Bedrock, SageMaker), observabilidad (CloudWatch, X-Ray, CloudTrail) e integración (SQS, SNS, EventBridge, Step Functions, API Gateway). En la práctica, si ejecutamos un workload típico en Frankfurt hoy, es muy probable que podamos replicarlo en el ESC.

Dicho esto, hay ausencias notables que debemos tener en cuenta:

• CloudFront — No hay CDN en el ESC. Si nuestra arquitectura depende de distribución en el edge, necesitaremos alternativas. Según tecracer, se espera para finales de 2026.
• IAM Identity Center — La gestión centralizada de SSO a nivel de organización aún no está disponible. Podemos federar con IdPs externos cuenta por cuenta, pero sin la comodidad de los permission sets centralizados.
• Shield Advanced y Firewall Manager — Protección DDoS avanzada y gestión centralizada de reglas de firewall no están disponibles. Shield básico sí está incluido.
• Inspector — No hay escaneo automatizado de vulnerabilidades en workloads.
• GuardDuty — Disponible pero con limitaciones: sin gestión a nivel de organización y sin algunas capacidades de detección más recientes.

En cuanto a precios, el ESC opera con el modelo estándar de pago por uso de AWS, pero con un sobrecoste estimado del 10-15% respecto a Frankfurt (eu-central-1) para servicios comparables. La facturación es en euros.

Estrategia de migración técnica

#

Mover workloads al ESC no es una migración entre regiones — es una migración entre clouds. Cuanto antes interioricemos esto, mejor planificaremos. No hay atajos: no podemos copiar snapshots de EBS entre particiones, no podemos replicar buckets de S3 directamente, y no podemos reutilizar nuestras cuentas ni roles existentes.

Fase 1: Fundación de identidad. Lo primero es establecer la estructura de cuentas en el ESC. Crear la organización, definir las OUs, configurar las SCPs y federar el acceso con nuestro IdP corporativo. Si usamos Control Tower (disponible en el ESC), este es el momento de desplegarlo. Todo esto debería estar codificado en Terraform desde el primer día.

Fase 2: Networking. VPCs, subnets, NAT Gateways, security groups. Si necesitamos conectividad con la partición comercial durante la transición, configurar la VPN o Direct Connect. Definir la estrategia de DNS: qué dominios viven en el Route 53 del ESC, cuáles se delegan desde la partición comercial.

Fase 3: Pipeline de CI/CD. Adaptar nuestros pipelines para que puedan desplegar en ambas particiones. Esto implica configurar credenciales separadas (OIDC o access keys) para el ESC y asegurarnos de que nuestros módulos de Terraform usan aws_partition en lugar de ARNs hardcodeados. Si usamos ECR, necesitamos que el pipeline publique las imágenes de contenedores también en el registro del ESC.

Fase 4: Despliegue de workloads. Empezar con workloads no críticos para validar que todo funciona: la infraestructura, los permisos, los endpoints, el monitoring. Resolver los problemas inevitables antes de tocar producción.

Fase 5: Migración de datos. Normalmente la parte más compleja. Las opciones dependen del volumen y la tolerancia a downtime:

• S3: Usar herramientas como aws s3 sync o DataSync entre particiones, pasando por la red (VPN/Direct Connect o Internet). No hay replicación nativa cross-partition.
• Bases de datos: Export/import con dump nativo, o usar DMS (disponible en el ESC) con un endpoint de origen en la partición comercial accesible por red.
• EBS: Exportar snapshots a S3, transferir a S3 en el ESC, reimportar. No es directo pero funciona.

Fase 6: Cutover. Redirigir el tráfico a los workloads en el ESC. Mantener la infraestructura en la partición comercial como fallback hasta tener confianza, y luego decomisionar.

Un consejo práctico: no intentar migrar todo de golpe. Identificar los workloads que realmente necesitan garantías de soberanía y empezar por ahí. El resto puede quedarse en la partición comercial — no todo necesita estar en el ESC.

Conclusión

#

El AWS European Sovereign Cloud no es simplemente una región más con una etiqueta de soberanía. Es una partición independiente con todas las consecuencias técnicas que eso implica: cuentas separadas, IAM regional, endpoints diferentes, ARNs con nuevo prefijo, sin conectividad nativa con la partición comercial y un catálogo de servicios que, aunque amplio, todavía tiene huecos relevantes.

Para quienes trabajamos con infraestructura como código, la buena noticia es que las herramientas ya están preparadas. Terraform con el provider 6.x resuelve los endpoints nativamente, aws_partition nos permite escribir módulos que funcionan en cualquier partición, y los patrones de provider aliases con estado separado nos dan una base sólida para gestionar despliegues multi-partición.

La clave está en no subestimar el esfuerzo. Esto no es cambiar eu-central-1 por eusc-de-east-1 en un fichero de variables. Es repensar la estructura de cuentas, la gestión de identidades, la conectividad de red, los pipelines de CI/CD y la estrategia de datos. También es tener en cuenta que el catálogo de servicios, aunque cubre los pilares fundamentales, aún no está a la par con la partición comercial — y planificar nuestras arquitecturas en consecuencia. Y sobre todo, es decidir con criterio qué workloads realmente necesitan estar en el ESC y cuáles pueden seguir en la partición comercial.

El ESC responde a una necesidad real del mercado europeo. Pero como toda decisión de arquitectura, requiere entender bien los trade-offs antes de dar el salto.

¿Te ha gustado este artículo? ¡Suscríbete al boletín y sé el primero en saber cuándo se publica uno nuevo!

Referencias

#

• AWS European Sovereign Cloud
• Opening the AWS European Sovereign Cloud
• AWS European Sovereign Cloud FAQs
• The AWS European Sovereign Cloud: A New Horizon for Digital Sovereignty (Keepler)