Módulo 3: Secrets Management

3. SSM Parameter Store vs. Secrets Manager: cuándo cada uno

Descripción

AWS ofrece dos servicios gestionados que resuelven las tres propiedades de la lección anterior —control de acceso, auditoría, rotación—, y una pregunta razonable, la primera vez que alguien se topa con los dos, es por qué existen ambos en vez de uno solo. Esta lección responde esa pregunta con un criterio de decisión concreto, verificado contra la documentación oficial y el pricing real de agosto de 2026 —no con una preferencia personal ni con "usa el que te resulte más cómodo"—.

Conexión con el módulo

Las lecciones 4 y 5 aplican, de forma práctica y ejecutada, exactamente el criterio que esta lección establece: la firma HMAC del webhook de aduanas va a SSM Parameter Store (lección 4); el usuario/contraseña de la API de aduanas va a Secrets Manager (lección 5). Ninguna de esas dos decisiones es arbitraria — esta lección es la que las justifica antes de construirlas.


Analogía: la caja de herramientas y la caja fuerte, en el mismo taller

Imagina un taller con dos muebles distintos para guardar cosas: una caja de herramientas con compartimentos etiquetados, donde vive todo lo que el taller necesita para funcionar día a día —tornillos, medidas, notas de configuración de una máquina—, y una caja fuerte más pequeña, con cerradura de combinación, reservada exclusivamente para lo que abriría una puerta si cayera en manos equivocadas. Ambos muebles están en el mismo taller, ambos protegen contenido, y es tentador guardar todo en la caja fuerte "por las dudas" — pero eso la vuelve lenta de usar para lo que no necesita ese nivel de ceremonia, y la caja de herramientas nunca fue diseñada para guardar la llave de la puerta principal. SSM Parameter Store es la caja de herramientas: rápida, barata, pensada para todo lo que el sistema necesita para configurarse, con la opción de guardar algo sensible cuando hace falta. Secrets Manager es la caja fuerte: más cara, más lenta de aprovisionar, pero con un mecanismo de cambio de combinación —rotación nativa— que la caja de herramientas nunca tuvo.


El criterio de decisión, en tres preguntas

Pregunta 1 — ¿Es configuración o es una credencial?

SSM Parameter Store nació, históricamente, como un almacén de configuración: valores que un sistema necesita para funcionar, pero que no representan, por sí mismos, acceso a otro sistema —una URL de un endpoint, un nombre de ambiente, una bandera de feature flag—. Que soporte también el tipo SecureString (cifrado con KMS, el tema de la lección 4) no cambia su vocación original: sigue siendo el lugar donde vive la mayoría de la configuración de un proyecto, con la opción de cifrar la que lo necesite.

Secrets Manager nació exclusivamente para credenciales: contraseñas de bases de datos, claves de API, tokens de OAuth — valores cuya única razón de existir es autenticar algo frente a otra cosa. No tiene un tipo "no cifrado"; todo lo que entra a Secrets Manager está cifrado con KMS por defecto, sin excepción.

Pregunta 2 — ¿Necesita rotación automática?

Esta es la diferencia técnica más concreta entre los dos servicios, y la que más pesa en una decisión real de arquitectura. Secrets Manager tiene rotación nativa: puedes asociar una función Lambda de rotación a un secreto, y AWS ejecuta el ciclo completo —crear una versión nueva, actualizar el sistema externo, probar que funciona, promover la versión nueva a activa— en el schedule que definas, sin que ningún humano tenga que intervenir en cada ciclo. La lección 6 de este módulo desarrolla ese mecanismo con precisión.

SSM Parameter Store no tiene ningún mecanismo de rotación nativo. Puedes versionar un parámetro —cada PutParameter con overwrite = true crea una nueva versión, y puedes leer versiones anteriores explícitamente—, pero coordinar cuándo rotar y qué hacer con el sistema externo en cada rotación es trabajo tuyo, sin ningún andamiaje nativo de AWS que lo automatice.

Pregunta 3 — ¿Qué tan sensible al costo es este caso?

Esta pregunta, verificada contra el pricing oficial de AWS de agosto de 2026, tiene una respuesta contundente:

SSM Parameter Store (Standard)Secrets Manager
Costo de almacenamientoSin costo adicionalUS$0.40 por secreto, por mes
Costo de llamadas a la APISin costo con throughput estándarUS$0.05 por cada 10.000 llamadas
Tamaño máximo de valor4 KB (tier Standard)Sin ese límite específico
Rotación nativaNo

Para un proyecto con decenas o cientos de valores de configuración —el caso típico de SSM Parameter Store—, ese costo cero es la diferencia entre un almacén de configuración viable y uno que se vuelve caro a escala. Para un puñado de credenciales genuinamente sensibles —el caso típico de Secrets Manager—, US$0.40 al mes por secreto es, en la práctica, un costo trivial frente al riesgo que mitiga.


La tabla de decisión completa

CriterioSSM Parameter StoreSecrets Manager
Tipo de valorConfiguración (con opción de cifrar con SecureString)Credenciales exclusivamente
Rotación automáticaNo — versionado manualSí — nativa, con Lambda propia
Costo (tier Standard)Gratis hasta 10.000 parámetrosUS$0.40/secreto/mes + US$0.05/10.000 llamadas
Tamaño máximo (tier Standard)4 KBSin ese límite
Formato del valorString, StringList, SecureStringTexto plano o JSON estructurado
Caso típico en Andes CargoLa firma HMAC del webhook de aduanas — un único valor, sin rotación automática necesariaEl usuario/contraseña de la API de aduanas — un par estructurado, candidato natural a rotación futura

Qué esperar (literal — pricing oficial de AWS, agosto de 2026, verificado contra la fuente directa citada al final de esta lección): el tier Standard de SSM Parameter Store, hasta 10.000 parámetros por cuenta y región, con un máximo de 4 KB por valor, no tiene ningún costo adicional. Secrets Manager cobra US$0.40 por secreto por mes, sin importar si el secreto se lee o no, más US$0.05 por cada 10.000 llamadas a su API.


Aplicando el criterio a los dos casos de Andes Cargo

Con las tres preguntas resueltas, la decisión de las lecciones 4 y 5 deja de ser arbitraria:

La firma HMAC del webhook de aduanas → SSM Parameter Store, SecureString. Es un único valor, usado para verificar la firma de una notificación entrante — no hay ningún sistema externo cuya contraseña haya que rotar coordinadamente, porque no es una credencial de autenticación, es una clave de verificación de integridad. SecureString la cifra con KMS, resolviendo el riesgo real (que alguien la lea en texto plano) sin pagar el costo de un servicio pensado para un problema distinto.

El usuario/contraseña de la API de aduanas → Secrets Manager. Es, literalmente, la definición de "credencial": autentica a Andes Cargo frente a un sistema externo. Es candidato natural a rotación periódica —exactamente el tipo de valor que Secrets Manager fue diseñado para rotar de forma automática—, y su estructura (dos campos relacionados, usuario y contraseña) encaja de forma natural con el soporte nativo de Secrets Manager para secretos en formato JSON.


Errores comunes

Usar Secrets Manager para todo "por las dudas" (de costo, ignorando la Pregunta 3). Qué pasa: alguien, después de aprender que Secrets Manager es "el servicio más seguro", empieza a guardar ahí también valores de configuración no sensibles. Cómo detectarlo: si tu factura de Secrets Manager crece con secretos que, aplicando la prueba del REDACTED de la lección 1, en realidad son configuración. Cómo corregirlo: US$0.40 por secreto por mes no suena a mucho hasta que un proyecto acumula cien valores de configuración ahí — a esa escala, la diferencia frente a SSM Parameter Store (gratis para el mismo volumen) es real. Reserva Secrets Manager para lo que la Pregunta 1 clasifica genuinamente como credencial.

Usar SSM Parameter Store para un secreto que necesita rotación automática (de la Pregunta 2, ignorada). Qué pasa: alguien guarda la contraseña de una base de datos de producción en un aws_ssm_parameter tipo SecureString, porque "también cifra con KMS, ¿cuál es la diferencia?". Cómo detectarlo: si tu plan de rotación para ese secreto es "alguien lo va a actualizar a mano cuando toque". Cómo corregirlo: SecureString resuelve el cifrado en reposo (la misma protección técnica), pero no resuelve el problema de coordinar un cambio de credencial sin romper nada durante la propagación — eso es exclusivo de Secrets Manager, con el mecanismo que desarrolla la lección 6.

Asumir que SecureString de SSM Parameter Store es "menos seguro" que Secrets Manager (de percepción, no de hechos). Qué pasa: alguien concluye que, porque Secrets Manager cuesta dinero y SSM Parameter Store no, el primero debe ser criptográficamente más fuerte. Cómo detectarlo: si tu razón para preferir Secrets Manager es "es más seguro", sin poder nombrar cuál de las tres preguntas de esta lección lo justifica. Cómo corregirlo: ambos cifran con KMS por defecto — la diferencia no es de fortaleza criptográfica, es de funcionalidad: rotación nativa, límites de tamaño, y el modelo de costo. Un SecureString bien configurado protege un valor tan bien como un secreto de Secrets Manager; lo que no tiene es el mecanismo de rotación automática.


Ejercicios

Ejercicio 1 — Clasifica cinco valores nuevos con la tabla de decisión. Para cada uno, decide SSM Parameter Store o Secrets Manager, y justifica con la pregunta correspondiente: (a) el nombre del bucket de logs de un ambiente de staging; (b) la contraseña de un usuario de servicio de una base de datos RDS; (c) un feature flag booleano que activa una funcionalidad nueva; (d) el token de API de un servicio de envío de correos transaccionales; (e) la URL base de la API de aduanas.

Ver solución

(a) SSM Parameter Store — configuración, sin necesidad de rotación (Pregunta 1). (b) Secrets Manager — credencial de autenticación, candidata natural a rotación periódica (Preguntas 1 y 2). (c) SSM Parameter Store — configuración pura, ni siquiera necesita cifrado (String, no SecureString). (d) Secrets Manager — es una credencial de autenticación frente a un sistema externo, el mismo patrón que el usuario/contraseña de aduanas de esta lección. (e) SSM Parameter Store — es una URL, configuración, no otorga ninguna capacidad por sí misma (aplica también la prueba del REDACTED de la lección 1).

Ejercicio 2 — Justifica el costo de Secrets Manager frente a un gerente de producto. Un gerente de producto, viendo la factura de AWS de Andes Cargo, pregunta por qué pagar US$0.40 al mes por un secreto cuando SSM Parameter Store es gratis. Responde en dos o tres frases, usando el criterio de esta lección, no solo "es más seguro".

Ver solución

Una respuesta completa suena, más o menos, así: "No es que Secrets Manager sea más seguro en el cifrado —ambos usan KMS—, es que Secrets Manager incluye rotación automática nativa: para una credencial real, como la contraseña de la API de aduanas, eso significa que el sistema puede cambiar esa contraseña periódicamente sin que un humano tenga que coordinar manualmente el cambio en cada lugar donde se usa. US$0.40 al mes es barato comparado con el riesgo de una credencial que nunca rota porque nadie se acordó de hacerlo a mano, o el costo de ingeniería de construir ese mecanismo de rotación nosotros mismos."

Ejercicio 3 — Calcula el costo real de un escenario concreto. Andes Cargo tiene 40 valores de configuración (SSM Parameter Store, tier Standard) y 3 credenciales reales (Secrets Manager), con un total combinado de 50.000 llamadas de lectura al mes entre ambos servicios, repartidas proporcionalmente. Estima el costo mensual aproximado, usando la tabla de pricing de esta lección.

Ver solución

SSM Parameter Store: 40 parámetros en tier Standard, sin costo de almacenamiento; el throughput estándar de llamadas tampoco tiene costo adicional (solo lo tendría si se solicitara higher throughput explícitamente) → US$0 de SSM, en este escenario. Secrets Manager: 3 secretos × US$0.40/mes = US$1.20 de almacenamiento; asumiendo que buena parte de las 50.000 llamadas del mes corresponden a los 3 secretos (por ejemplo, 10.000 llamadas), eso agrega 1 × US$0.05 = US$0.05 adicionales. Total aproximado: ~US$1.25/mes. El punto del ejercicio no es el número exacto —depende de cuántas de las 50.000 llamadas van a cada servicio—, sino confirmar que, con el criterio correcto de esta lección (SSM para configuración, Secrets Manager solo para credenciales reales), el costo total de gestionar secretos correctamente es, en la práctica, casi irrelevante frente al riesgo que evita.


Resumen y siguiente paso

En esta lección construiste un criterio de decisión real —configuración frente a credencial, rotación nativa frente a manual, costo verificado contra pricing oficial de agosto de 2026— para elegir entre SSM Parameter Store y Secrets Manager. Aplicaste ese criterio a los dos secretos concretos de Andes Cargo que vas a construir en las lecciones siguientes: la firma HMAC del webhook de aduanas (SSM Parameter Store) y el usuario/contraseña de la API de aduanas (Secrets Manager).

Antes de avanzar deberías poder: responder las tres preguntas del criterio de decisión para cualquier valor nuevo; explicar por qué SecureString no vuelve a SSM Parameter Store "tan seguro como" Secrets Manager en el sentido que importa (rotación, no cifrado); y justificar, con el pricing real, por qué usar Secrets Manager para todo sería un error de costo, no solo de estilo.

La lección 4 declara el primer recurso real de este módulo: aws_ssm_parameter, tipo SecureString, aplicado y leído con awslocal ssm get-parameter --with-decryption.

Recursos

  1. AWS Docs — Choosing parameter tiers in Parameter Store — la fuente oficial de los límites de tamaño y costo del tier Standard, citados en la tabla de esta lección.
  2. AWS — AWS Systems Manager Pricing — pricing oficial completo de Parameter Store, incluido el costo del tier Advanced (US$0.05/parámetro/mes) que esta lección no usa pero vale la pena conocer.
  3. AWS — AWS Secrets Manager Pricing — pricing oficial completo de Secrets Manager (US$0.40/secreto/mes, US$0.05/10.000 llamadas), citado en la tabla de esta lección.
  4. AWS Docs — Rotate AWS Secrets Manager secrets — introducción oficial a la rotación nativa, desarrollada con precisión en la lección 6 de este módulo.