Configuración y secretos gestionados con AWS Systems Manager Parameter Store - Estructura jerárquica y cifrado

Se explica la gestión de valores de configuración y secretos con Parameter Store, el diseño de la estructura jerárquica y cómo elegir entre Parameter Store y Secrets Manager.

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

Descripción general de Parameter Store

Parameter Store es un almacén de clave-valor que gestiona de forma jerárquica los datos de configuración y los secretos. Mientras que Secrets Manager ofrece funciones como la rotación automática de credenciales, Parameter Store gestiona tanto la configuración general de las aplicaciones (indicadores de funciones, URL de endpoints, umbrales) como los secretos. Los parámetros Standard son gratuitos y se pueden crear hasta 10,000.

Estructura jerárquica y elección entre Parameter Store y Secrets Manager

La estructura jerárquica se construye usando separadores de ruta (/) en los nombres de los parámetros. Los parámetros se organizan por entorno y componente, como en /myapp/prod/db/host y /myapp/prod/db/password, y con GetParametersByPath se obtienen en bloque los parámetros que hay bajo una ruta concreta. En cuanto a la elección entre ambos, elegir Secrets Manager es adecuado para las credenciales de base de datos que requieren rotación automática, y elegir Parameter Store es adecuado para los demás valores de configuración y secretos. Parameter Store también admite referencias a Secrets Manager (aws:secretsmanager:) y permite utilizar ambos servicios de forma integrada.

Integración con Lambda y ECS

Para obtener parámetros de Parameter Store desde una función de Lambda, se utiliza AWS Parameters and Secrets Lambda Extension. Como la extensión almacena en caché los parámetros de forma local, se reducen las llamadas a la API en cada ejecución de Lambda. En la sección secrets de la definición de tarea de ECS se hace referencia a los parámetros de Parameter Store y se inyectan como variables de entorno del contenedor. Los parámetros SecureString se cifran con KMS, y los permisos de descifrado se controlan con políticas de IAM. Con el control de versiones de los parámetros se sigue el historial de cambios, y se puede volver a una versión anterior cuando surge un problema. Con las políticas de parámetros se establecen fechas de caducidad y se envían notificaciones automáticas sobre los parámetros caducados.

Precios de Parameter Store

Los parámetros Standard son gratuitos, y se pueden almacenar hasta 10,000 parámetros por cuenta y región. Los parámetros Advanced cuestan unos 0.05 USD al mes por parámetro y admiten un tamaño de hasta 8KB, políticas de parámetros y un límite de 100,000 parámetros (a fecha de agosto de 2026). Las llamadas a la API cuestan unos 0.05 USD por cada 10,000 solicitudes con la configuración de alto rendimiento (una configuración distinta de los niveles de parámetros). En comparación con Secrets Manager (0.40 USD al mes por secreto), con Parameter Store resulta más fácil contener los costes de los valores de configuración que no requieren rotación automática.

IAM y control de acceso basado en rutas

Los permisos de Parameter Store se diseñan aprovechando la jerarquía de los nombres de los parámetros. Si en la especificación de recursos de una política de IAM se limita la ruta, como en /myapp/prod/*, se puede controlar el acceso para que solo los roles de producción puedan acceder a los parámetros del entorno de producción. Para descifrar un SecureString se necesita, además del permiso para obtener el parámetro, el permiso de descifrado de la clave de KMS usada para el cifrado. Usar una clave de KMS dedicada para cada aplicación y aplicar el mínimo privilegio tanto en las políticas de claves como en las políticas de IAM contribuye a reducir el riesgo de que los secretos se lean de forma no intencionada.

Operación segura de los cambios de configuración

Cada vez que se actualiza un parámetro, se le asigna automáticamente un número de versión, y se pueden consultar valores anteriores o volver a una versión previa. Si los cambios de la configuración de producción se aplican desde un pipeline de CI/CD tras una revisión de código, se pueden reducir los accidentes causados por el trabajo manual. Como los cambios de parámetros se pueden detectar como eventos de EventBridge, se puede montar un mecanismo que envíe notificaciones o inicie automáticamente el procesamiento relacionado cuando se reescribe una configuración concreta. También existe la opción de hacer referencia a las configuraciones importantes indicando de forma explícita el número de versión, para que los valores no cambien en momentos no previstos.

Patrones de obtención desde las aplicaciones y errores comunes

Cuando una aplicación obtiene parámetros con frecuencia, hay que prestar atención al throttling de la API. El número de llamadas a la API se contiene con medidas como leer los parámetros una sola vez al arrancar y almacenarlos en caché en memoria, u obtener varios parámetros juntos con GetParameters. En CloudFormation y CDK se puede hacer referencia a los parámetros de forma dinámica dentro de las plantillas e incrustar los valores de configuración más recientes en el momento del despliegue. No obstante, se tiene cuidado con el tratamiento de los lugares donde se hace referencia a ellos para no exponer un SecureString en las salidas de la plantilla o en los registros. Cuando la frecuencia de acceso es alta, se considera la configuración de alto rendimiento (una configuración distinta de los niveles de parámetros).

Uso compartido entre varias cuentas / varias regiones

Cuando se usa la misma configuración en varias cuentas o varias regiones, como Parameter Store es independiente en cada región, se diseña colocando los mismos parámetros en cada región o leyéndolos desde una cuenta compartida. Cuando se quiere distribuir una configuración común a toda la organización, preparar un mecanismo que la sincronice con cada entorno mediante CI/CD hace menos probable la deriva, en la que la configuración diverge entre entornos. Como los parámetros Advanced tienen un límite de tamaño grande por parámetro, también existe la opción de gestionar varias configuraciones JSON pequeñas juntas en un solo parámetro. Si los valores se vuelven demasiado grandes, se considera dividir la configuración o usar S3 de forma combinada.

Resumen

Parameter Store es un servicio que gestiona de forma jerárquica la configuración de las aplicaciones y los secretos. La caché de la extensión de Lambda acelera la obtención de la configuración, y con la sección secrets de la definición de tarea de ECS se puede pasar a los contenedores. Los parámetros Standard son gratuitos y se pueden almacenar hasta 10,000, y en comparación con Secrets Manager resulta más fácil contener los costes de los valores de configuración que no requieren rotación automática.

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.

El mecanismo de sincronización horaria interna de AWS - Amazon Time Sync Service y el diseño de smearing de segundos intercalaresExplicamos el mecanismo de Amazon Time Sync Service operado de forma independiente por AWS, la fuente de tiempo de alta precisión con GPS y relojes atómicos, la decisión de diseño de absorber los segundos intercalares mediante smearing y la importancia de la sincronización horaria en sistemas distribuidos.Centralización de registros de auditoría SaaS con AWS AppFabric - Estandarización OCSF e integración con Security LakeExplicamos la recopilación de registros de auditoría de aplicaciones SaaS con AppFabric, la estandarización al formato OCSF y la construcción de pipelines de análisis.Implementación de Feature Flags con AWS AppConfig - Despliegue seguro de configuración y rollbackDespliega cambios de configuración de forma independiente al código mediante estrategias Linear y Exponential. Garantiza la seguridad con rollback automático activado por alarmas de CloudWatch.Revisión de arquitectura - Evaluación sistemática de cargas de trabajo con AWS Well-Architected ToolExplica la revisión de arquitectura de cargas de trabajo con AWS Well-Architected Tool. Presenta la evaluación basada en los 6 pilares, la elaboración de planes de mejora y el uso de lentes personalizadas.Diseño y operación de logs de auditoría - Registro completo de actividad API con CloudTrailExplica las técnicas de diseño de logs de auditoría con AWS CloudTrail, el registro de actividad API, el almacenamiento a largo plazo en S3 y la respuesta de cumplimiento mediante integración con Config.Lecciones de sistemas distribuidos a partir de los informes de incidentes de AWS (COE) - Principios de diseño transformados por los grandes incidentes del pasadoA partir de los Correction of Errors (COE) y los informes de incidentes publicados por AWS, explica las causas raíz de grandes incidentes del pasado, como el incidente de S3, el incidente de DNS en us-east-1 y el incidente de Kinesis, y cómo cambiaron los principios de diseño de AWS.El diseño de tags determina las operaciones - Curiosidades y reglas de nomenclatura prácticas de la estrategia de tags de recursos AWSExplicamos por qué los tags de recursos AWS no son simples etiquetas sino la base de la asignación de costos, control de acceso y automatización, las reglas de nomenclatura de claves de tags, cómo usar el límite de 50 tags y la gobernanza mediante políticas de tags.Por qué existen las cuotas de servicio de AWS - Diseño multitenant que protege la infraestructura compartidaExplicamos que las cuotas de servicio de AWS (antes límites de servicio) no son simples restricciones sino un diseño para proteger a otros clientes en un entorno multitenant, desde el problema del vecino ruidoso, la diferencia entre límites soft y hard, y el trasfondo de las solicitudes de aumento.