Estrategia multi-región de AWS Secrets Manager - Replicación y uso compartido entre cuentas

Aprenda a lograr recuperación ante desastres con replicación multi-región y construir gestión centralizada desde una cuenta de seguridad usando acceso entre cuentas.

Unos 7 min de lecturaÚltima actualización: 2026-10-29

Secretos multi-región

La función de secretos multi-región de Secrets Manager sincroniza automáticamente el secreto de la región primaria con hasta cuatro regiones de réplica. La réplica de cada región tiene su propio ARN, pero puede acceder a ella con el mismo nombre de secreto. Las aplicaciones obtienen el secreto desde el endpoint propio de cada región, por lo que, aunque falle la región primaria, pueden seguir accediendo desde una región de réplica. Las réplicas son de solo lectura, y las actualizaciones se ejecutan únicamente en la región primaria. Ante un fallo de la región primaria, si promueve la réplica a primaria, también es posible escribir en ella.

Acceso entre cuentas

En entornos multi-cuenta, la configuración recomendada es gestionar los secretos en una cuenta de seguridad central y consultarlos desde las cuentas de carga de trabajo. Configure una política basada en recursos en el secreto y permita GetSecretValue a los roles de IAM de las cuentas de carga de trabajo. En la cuenta de carga de trabajo, asocie al rol de IAM una política que permita el acceso al ARN del secreto de la cuenta de seguridad. También es necesario configurar el permiso Decrypt entre cuentas en la política de clave de la clave de KMS. Con esta configuración, puede centralizar la gestión de los secretos y, al mismo tiempo, las aplicaciones de cada cuenta pueden acceder a ellos de forma segura.

Versionado y disponibilidad durante la rotación

Secrets Manager gestiona las versiones de los secretos mediante etiquetas. AWSCURRENT indica la versión vigente, y AWSPREVIOUS, la versión inmediatamente anterior. Durante la rotación, la nueva contraseña se crea con la etiqueta AWSPENDING y, una vez completadas la actualización de la contraseña en la base de datos y la prueba de conexión, pasa a AWSCURRENT. La estrategia de usuarios alternos utiliza dos usuarios de base de datos por turnos y, mientras se rota la contraseña de uno, mantiene la conexión con el otro. En la aplicación, el diseño recomendado es usar la biblioteca de caché del SDK, seguir usando la contraseña anterior a la rotación dentro del TTL de la caché y obtener la nueva contraseña al vencer el TTL.

Precios de Secrets Manager

El precio de Secrets Manager es de aproximadamente 0.40 USD al mes por secreto y de aproximadamente 0.05 USD por cada 10,000 llamadas a la API (a fecha de agosto de 2026). Con la replicación multi-región, los secretos de las regiones de réplica también generan la misma tarifa mensual. Si replica en cuatro regiones, el costo es de aproximadamente 2.00 USD al mes por secreto (0.40 × 5 regiones). El costo es mayor que el de SecureString de Parameter Store (los parámetros estándar son gratuitos), pero la elección se hace teniendo en cuenta el valor de la rotación automática y de la replicación multi-región.

Funcionamiento de las réplicas y DR

Secrets Manager puede replicar los secretos en varias regiones. Cuando actualiza el secreto de la región primaria, su contenido se refleja automáticamente en las regiones de réplica. Las aplicaciones de cada región pueden leer el secreto desde una región cercana, por lo que evitan la latencia del acceso entre regiones. Desde el punto de vista de la recuperación ante desastres, si la región primaria deja de estar disponible, puede cambiar a una región de réplica y continuar con la operación. Un mecanismo que distribuye de forma fiable las mismas credenciales a varias regiones es la base de un sistema de alta disponibilidad.

Cifrado y gestión de claves en la replicación

Los secretos se cifran por región, así que, al crear una réplica, especifique la clave de cifrado que se usará en la región de réplica. Como no es posible usar la misma clave entre regiones, prepare una clave para cada región y diseñe los permisos de modo que cada una pueda descifrar. Así, las aplicaciones de cada región pueden obtener los secretos de forma segura con la clave de esa región. Al separar la gestión de claves por región, el control de acceso por región también queda claro. Al diseñar la replicación, es importante planificar no solo los datos en sí, sino también, junto con ellos, la ubicación de las claves que los descifran y sus permisos.

Diseño de aplicaciones multi-región

En las aplicaciones que despliegan servicios en varias regiones, es importante que cada región pueda funcionar de forma autónoma. Si replica de antemano los secretos en cada región, las aplicaciones pueden obtener las credenciales localmente y funcionar sin depender de regiones externas. Así, aunque haya fallos de comunicación entre regiones, cada región puede mantener sus funciones de forma independiente. Completar el procesamiento en una región cercana a los usuarios también acelera las respuestas. En los servicios desplegados a escala global, un diseño que distribuye componentes comunes como los secretos a cada región permite lograr a la vez disponibilidad y rendimiento.

Consideraciones operativas

La operación de secretos multi-región tiene varios puntos a tener en cuenta. La replicación tarda un breve tiempo en reflejar los cambios, así que tenga en cuenta la posibilidad de que se lea un valor antiguo en la réplica justo después de una actualización. Cuando actualice las credenciales mediante la rotación, compruebe que el cambio se propague de forma fiable a cada región. Al crear réplicas, el secreto se almacena en cada región y genera el costo correspondiente, por lo que limite las réplicas a los secretos que realmente necesite en varias regiones. Elimine las réplicas que ya no necesite. Operar teniendo presentes tres puntos, la coherencia de las réplicas, la propagación de la rotación y el costo, es la clave para estabilizar una configuración multi-región.

Resumen

Con la replicación multi-región y el uso compartido entre cuentas de Secrets Manager, puede lograr una gestión de secretos a escala empresarial. Al combinar la ubicación de réplicas para la recuperación ante desastres, la gestión centralizada en la cuenta de seguridad y la disponibilidad durante la rotación mediante el versionado, puede construir una base sólida para la gestión de secretos.

Referencias (recursos oficiales de AWS)

Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.

Si esta página y la documentación oficial difieren, prevalece la documentación oficial.

Detección de permisos excesivos con IAM Access Analyzer - Análisis de acceso externo y permisos no utilizadosDetecte los permisos no utilizados de los roles IAM a partir de CloudTrail y genere automáticamente políticas de mínimo privilegio. Explicamos desde la detección de acceso externo hasta la incorporación de verificaciones de políticas personalizadas en CI/CD.Gestión automatizada de certificados SSL/TLS con AWS Certificate Manager - De la emisión a la rotaciónExplicamos la emisión gratuita de certificados públicos con ACM, la validación DNS, la renovación automática y el despliegue en ALB / CloudFront.Obtención de informes de cumplimiento con AWS Artifact - Respuesta a auditorías y gestión de contratosPresenta cómo obtener informes de auditoría SOC, PCI DSS e ISO bajo demanda, y aplicar BAA y GDPR DPA de forma masiva a toda la organización con Organizations.Automatización de auditorías - Recopilación continua de evidencias de cumplimiento con AWS Audit ManagerExplica la recopilación automática de evidencias de auditoría con AWS Audit Manager. Presenta la evaluación automática basada en frameworks (SOC 2, PCI DSS, GDPR, etc.), gestión centralizada de evidencias y generación de informes de auditoría.La estructura oculta de los 12 dígitos del ID de cuenta de AWS - Por qué son 12 dígitos y qué se puede inferirUna exploración curiosa de por qué los ID de cuenta de AWS son números de 12 dígitos, la intención de diseño incorporada en la estructura ARN, y las consideraciones de seguridad sobre lo que se puede inferir a partir de un ID de cuenta.Por qué el usuario root de una cuenta AWS es peligroso - Filosofía de diseño de separación de privilegios y práctica de selladoExplicamos por qué el usuario root de AWS tiene privilegios que IAM no puede restringir, la lista de operaciones que solo el usuario root puede realizar, cómo configurar MFA y la estrategia de sellado mediante la gestión de acceso root de Organizations.Gestión de certificados y HTTPS - Operaciones automatizadas de certificados TLS con AWS Certificate ManagerAprenda sobre la emisión de certificados TLS/SSL, renovación automática y despliegue usando AWS Certificate Manager (ACM). Cubre la integración con CloudFront, ALB y API Gateway, validación DNS y uso de Private CA.Gestión dedicada de claves con AWS CloudHSM - Cifrado compatible con FIPS 140-3 Level 3Logre gestión de claves compatible con FIPS 140-3 Level 3 con instancias HSM dedicadas. Aprenda cuándo elegir CloudHSM sobre KMS y cómo integrar ambos mediante almacenes de claves personalizados de KMS.