DEV Community

Luciano Loyola
Luciano Loyola

Posted on

IAM Identity Center multi-Region con Identity Center directory: guía práctica con AWS CLI

#architecture #aws #cli #security

Si tus usuarios viven en el directorio nativo de IAM Identity Center, desde julio de 2026 los podés replicar a otras regiones de AWS. En este post vamos directo a la práctica: todo el camino por AWS CLI, desde la KMS key hasta probar el login en la región adicional.

Si querés el contexto completo (qué se replica, qué no y por qué importa), lo escribí en este artículo de Medium.

Lo que vamos a armar

Este es el diagrama oficial de AWS para una arquitectura multi-Region con Identity Center. Fijate en dos cosas: la replicación de identidades de us-east-1 a us-west-2, y la KMS key multi-Region con su réplica en la región destino.

Arquitectura oficial de AWS: IAM Identity Center en us-east-1 replicado a us-west-2, con la KMS key multi-Region y su réplica
Diagrama oficial del AWS Big Data Blog, "Multi-Region identity-based access to Amazon Redshift and S3 Tables". En ese ejemplo la identidad viene de un IdP corporativo; con Identity Center directory, los usuarios se crean directamente en Identity Center y ese recuadro desaparece.

La parte analítica del diagrama (Redshift, Lake Formation) no la necesitamos. Lo que nos interesa es la columna de la izquierda: Identity Center, la KMS key y cómo ambos aparecen replicados en la otra región.

Antes de empezar

Chequeá esto o vas a chocar contra un error a mitad de camino:

  • Organization instance de IAM Identity Center (no funciona con account instances).
  • Identity source: Identity Center directory o IdP externo. Con Active Directory no está soportado.
  • Regiones soportadas: desde el 1 de octubre de 2026 el soporte se extendió a regiones opt-in, y a replicación dentro de GovCloud (US) y dentro de las regiones de China. Confirmá tu región primaria y la adicional en AWS Capabilities by Region.
  • Las apps de AWS que usás tienen que soportar Identity Center con customer managed key. Revisá la tabla de compatibilidad antes del paso 3.
  • Cuota: 6 regiones por instancia por defecto (se puede ampliar).

Con Identity Center directory no tenés que tocar ACS URLs ni ningún IdP externo. Ese paso existe solo para IdPs externos.

Paso 0: datos de tu instancia 

aws sso-admin list-instances
Enter fullscreen mode Exit fullscreen mode

De la salida guardá el ARN de la instancia:

export INSTANCE_ARN="arn:aws:sso:::instance/ssoins-1234567890abcdef"
export PRIMARY_REGION="us-east-1"
export DR_REGION="eu-west-1"
Enter fullscreen mode Exit fullscreen mode

Paso 1: la key policy

La KMS key tiene que permitir que Identity Center e Identity Store la usen. AWS publica una baseline key policy; esta es la versión oficial, con los placeholders a reemplazar:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowIdentityCenterAdminAccounts",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::111122223333:root",
          "arn:aws:iam::444455556666:root"
        ]
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowIdentityCenterAndIdentityStoreToDescribeKey",
      "Effect": "Allow",
      "Principal": {
        "Service": ["identitystore.amazonaws.com", "sso.amazonaws.com"]
      },
      "Action": "kms:DescribeKey",
      "Resource": "*",
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "${aws:ResourceAccount}" }
      }
    },
    {
      "Sid": "AllowIdentityCenterAndIdentityStoreToUseKey",
      "Effect": "Allow",
      "Principal": {
        "Service": ["identitystore.amazonaws.com", "sso.amazonaws.com"]
      },
      "Action": [
        "kms:Decrypt",
        "kms:ReEncryptTo",
        "kms:ReEncryptFrom",
        "kms:GenerateDataKeyWithoutPlaintext"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "${aws:ResourceAccount}" },
        "ForAnyValue:StringEquals": {
          "kms:EncryptionContextKeys": [
            "aws:sso:instance-arn",
            "aws:identitystore:identitystore-arn"
          ]
        }
      }
    },
    {
      "Sid": "AllowOrgPrincipalsViaIdentityCenterAndIdentityStore",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "kms:Decrypt",
      "Resource": "*",
      "Condition": {
        "StringEquals": { "aws:PrincipalOrgID": "${aws:ResourceOrgID}" },
        "StringLike": {
          "kms:ViaService": ["sso.*.amazonaws.com", "identitystore.*.amazonaws.com"]
        },
        "ForAnyValue:StringEquals": {
          "kms:EncryptionContextKeys": [
            "aws:sso:instance-arn",
            "aws:identitystore:identitystore-arn"
          ]
        }
      }
    },
    {
      "Sid": "AllowManagedApps",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "kms:Decrypt",
      "Resource": "*",
      "Condition": {
        "Bool": { "aws:PrincipalIsAWSService": "true" },
        "StringEquals": { "aws:SourceOrgID": "${aws:ResourceOrgID}" },
        "StringLike": {
          "kms:ViaService": ["identitystore.*.amazonaws.com", "sso.*.amazonaws.com"]
        },
        "ForAnyValue:StringEquals": {
          "kms:EncryptionContextKeys": [
            "aws:sso:instance-arn",
            "aws:identitystore:identitystore-arn"
          ]
        }
      }
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Guardala como key-policy.json y reemplazá:

  • 111122223333: la cuenta de tu instancia de Identity Center (la management account de AWS Organizations).
  • 444455556666: tu cuenta de administración delegada. Si no usás administración delegada, sacá ese principal.

Las variables ${aws:ResourceAccount} y ${aws:ResourceOrgID} van tal cual: las resuelve IAM.

Paso 2: crear la KMS key multi-Region

La key tiene que ser simétrica, de tipo "encrypt and decrypt", estar en la misma región que la instancia y en la misma management account. Y tiene que nacer multi-Region: una key single-Region no se puede convertir después.

aws kms create-key \
    --multi-region \
    --description "IAM Identity Center encryption at rest" \
    --policy file://key-policy.json \
    --region "$PRIMARY_REGION"
Enter fullscreen mode Exit fullscreen mode

Las keys multi-Region tienen un ID que empieza con mrk-. Guardá el ARN:

export KEY_ARN="arn:aws:kms:us-east-1:111122223333:key/mrk-1234abcd12ab34cd56ef1234567890ab"
Enter fullscreen mode Exit fullscreen mode

Paso 3: que Identity Center use tu key

Antes de este paso, revisá que las apps de AWS que usás soporten customer managed keys. Si alguna no lo soporta, no sigas.

aws sso-admin update-instance \
    --instance-arn "$INSTANCE_ARN" \
    --encryption-configuration \
        KeyType=CUSTOMER_MANAGED_KEY,KmsKeyArn="$KEY_ARN"
Enter fullscreen mode Exit fullscreen mode

Dos cosas tranquilizadoras de la documentación: el cambio no afecta las sesiones activas, e Identity Center valida que puede cifrar y descifrar con la key. Si la policy está mal, te muestra el error y sigue usando la key anterior.

Y una que no lo es: si la key se borra, se deshabilita o la policy queda mal, ni tus usuarios ni tus admins van a poder usar Identity Center. Restringí quién puede deshabilitar o borrar la key, y tené un procedimiento de break-glass.

Paso 4: replicar la key a la región adicional 

aws kms replicate-key \
    --key-id "$KEY_ARN" \
    --replica-region "$DR_REGION" \
    --policy file://key-policy.json \
    --region "$PRIMARY_REGION"
Enter fullscreen mode Exit fullscreen mode

Uso la misma policy a propósito. AWS recomienda usar la misma policy en todas las réplicas para que la autorización sea consistente, y KMS no sincroniza las key policies entre regiones: si mañana cambiás la policy, la tenés que actualizar en cada región.

Paso 5: agregar la región en Identity Center 

aws sso-admin add-region \
    --instance-arn "$INSTANCE_ARN" \
    --region-name "$DR_REGION"
Enter fullscreen mode Exit fullscreen mode

Y consultá el estado hasta que figure ACTIVE:

aws sso-admin describe-region \
    --instance-arn "$INSTANCE_ARN" \
    --region-name "$DR_REGION"
Enter fullscreen mode Exit fullscreen mode

La primera replicación tarda según el volumen de datos de tu instancia. Después, los cambios incrementales se replican en segundos en la mayoría de los casos.

Si preferís la consola: Settings → Management → Regions for IAM Identity Center → Add Region.

Consola de IAM Identity Center: pestaña Management con la key de cifrado y la sección de regiones
Captura oficial del AWS Security Blog: pestaña Management con la configuración de cifrado y las regiones.

Consola de IAM Identity Center: replicación inicial en progreso hacia la región agregada
Captura oficial del AWS Security Blog: replicación inicial en progreso.

Paso 6: probar el login en la región adicional

El portal de la región adicional tiene otra URL. Ni el d-xxxxxxxx.awsapps.com/start clásico ni tu custom alias existen ahí:

# IPv4, sin /start al final
https://ssoins-111111h2222j33pp.eu-west-1.portal.amazonaws.com

# Dual-stack, sin /start al final
https://ssoins-111111h2222j33pp.portal.eu-west-1.app.aws
Enter fullscreen mode Exit fullscreen mode

La autorización de la CLI no se replica entre regiones, así que armá un perfil "DR" por cada perfil que ya tengas. En ~/.aws/config:

[sso-session corp-dr]
sso_start_url = https://ssoins-111111h2222j33pp.eu-west-1.portal.amazonaws.com
sso_region = eu-west-1

[profile prod-admin-dr]
sso_session = corp-dr
sso_account_id = 111122223333
sso_role_name = AdministratorAccess
Enter fullscreen mode Exit fullscreen mode

Y probalo hoy, no el día del incidente:

aws sso login --profile prod-admin-dr
aws sts get-caller-identity --profile prod-admin-dr
Enter fullscreen mode Exit fullscreen mode

Si el get-caller-identity te devuelve el rol esperado, el camino de failover funciona.

Lo que no vas a poder hacer desde la región adicional

Esto define tu runbook. Según la tabla oficial de APIs soportadas en regiones adicionales:

API En regiones adicionales
Identity Store Solo lectura
Identity Center Lectura y escritura de aplicaciones; lectura de instancia, permission sets y asignaciones
OIDC Todas las operaciones
Access Portal Todas las operaciones
SCIM Ninguna

En un failover, tu equipo entra con los permisos que ya estaban provisionados y replicados. No vas a poder crear usuarios ni asignar permission sets nuevos hasta que vuelva la primaria. Sí podés revocar sesiones desde la región adicional.

Checklist final

  • Key multi-Region creada con la baseline policy.
  • Identity Center usando la key (update-instance).
  • Key replicada con la misma policy.
  • Región agregada y en ACTIVE.
  • Allow-lists del firewall con los dominios del portal regional.
  • URL del portal regional comunicada al equipo.
  • Perfiles de CLI "DR" probados con sts get-caller-identity.
  • Break-glass definido y probado.

Fuentes

La explicación conceptual completa está en Medium. La versión en video corto está en YouTube, TikTok e Instagram, y el resumen en carrusel en LinkedIn.

━━━━━━━━━━━━━━━━━━━━
🟧 dev.luchops
Cloud & DevOps, explicado sin vueltas.

▸ Medium → medium.com/@lucianonicolasloyola
▸ YouTube → youtube.com/@dev.luchops
▸ TikTok / Instagram → @dev.luchops
━━━━━━━━━━━━━━━━━━━━

Top comments (0)