Parameter Store SecureString pour la plupart des secrets, Secrets Manager pour les rares qui exigent rotation, accès inter-comptes ou réplication multi-régions. C'est la répartition que nous appliquons sur les environnements AWS que nous auditons, du produit mono-compte à l'organisation multi-comptes. Le niveau standard de Parameter Store stocke des valeurs chiffrées via KMS sans frais de stockage ; Secrets Manager facture par secret et par appel. Cette ligne mensuelle ne vaut d'être payée que si vous utilisez les fonctions de cycle de vie qu'elle finance.
Que fournit gratuitement le niveau standard de Parameter Store ?
Le niveau standard stocke jusqu'à 10 000 paramètres par région sans frais de stockage, y compris des valeurs SecureString chiffrées avec une clé KMS que vous contrôlez. Les valeurs sont plafonnées à 4 Ko, le débit de lecture par défaut reste volontairement modeste, et il n'existe aucune rotation native : quand un identifiant doit changer, c'est à vous de construire ce qui le change.
Les lectures à débit standard n'entraînent aucun coût Parameter Store ; le déchiffrement d'un SecureString passe toutefois par KMS, qui a sa propre forme de coût par requête. La clé gérée par AWS suffit au départ, mais une clé gérée par le client vous donne la main sur la politique de clé et sur l'audit. Activez le débit supérieur et la facturation bascule vers un modèle par interaction pour la région. La documentation Parameter Store détaille les limites et la page de tarification Systems Manager tient les chiffres à jour ; nous ne citons ici que des formes de coût, car les chiffres bougent.
Que payez-vous réellement avec Secrets Manager ?
Secrets Manager facture un montant mensuel fixe par secret stocké plus un montant mesuré par tranche d'appels d'API ; la page de tarification officielle donne les chiffres actuels. En échange, vous obtenez la rotation native, des politiques de ressource pour l'accès inter-comptes, la réplication multi-régions et un plafond de 64 Ko par secret.
La rotation tranche généralement la question : la rotation gérée couvre les identifiants RDS, Redshift et DocumentDB sans code sur mesure, et une fonction Lambda que vous possédez peut faire tourner n'importe quel autre secret selon un calendrier. Les étiquettes de version permettent aux consommateurs de continuer à fonctionner pendant la rotation. Une politique de ressource autorise un autre compte à lire un secret directement, sans copie d'identifiants ni gymnastique IAM inter-comptes. La réplication maintient un secret synchronisé dans d'autres régions pour la bascule. Les deux composantes de coût croissent avec l'usage, et c'est précisément pourquoi le pattern de cache plus bas compte.
Quand le niveau avancé de Parameter Store se justifie-t-il ?
Le niveau avancé porte la limite de valeur à 8 Ko, relève le plafond de paramètres par région et ajoute des politiques de paramètre, comme les dates d'expiration et les notifications d'absence de changement. Sa forme de coût, un montant mensuel par paramètre avancé plus une facturation par interaction, le place entre le niveau standard gratuit et Secrets Manager.
Les paramètres avancés peuvent aussi être partagés entre comptes via AWS RAM, ce qui comble une partie de l'écart. Ce qui n'arrive jamais, c'est la rotation : une politique d'expiration vous signale qu'une valeur est périmée, elle ne la change pas. Les équipes qui accumulent des paramètres avancés pour imiter Secrets Manager finissent souvent avec une facture comparable et moins de fonctionnalités. Nous réservons le niveau avancé aux grosses charges de configuration : c'est un outil de configuration, pas un outil de cycle de vie des secrets.
Vous hésitez sur les secrets qui justifient le passage à Secrets Manager ? Décrivez votre système : diagnostic d'une page sous 48 h.
Recevoir mon diagnostic →Comment éviter un appel d'API à chaque invocation Lambda ?
En cachant dans l'environnement d'exécution. L'extension AWS Parameters and Secrets Lambda s'exécute comme layer, sert les deux services via un point d'accès HTTP local sur le port 2773 et met les réponses en cache avec un TTL configurable. Après la première lecture, un secret ne coûte que la latence locale et n'ajoute rien à la facture d'API.
import os, json, urllib.request
# L'extension écoute dans la sandbox ; l'en-tête de jeton est obligatoire
def get_secret(name):
url = "http://localhost:2773/secretsmanager/get?secretId=" + name
req = urllib.request.Request(url, headers={
"X-Aws-Parameters-Secrets-Token": os.environ["AWS_SESSION_TOKEN"]
})
with urllib.request.urlopen(req) as r:
return json.loads(r.read())["SecretString"]
Le même point d'accès sert Parameter Store sous /systemsmanager/parameters/get. Ajustez SECRETS_MANAGER_TTL et SSM_PARAMETER_STORE_TTL à votre fenêtre de rotation, et traitez un échec d'authentification comme un signal de rafraîchissement, car un secret tourné n'atteint le cache qu'à l'expiration du TTL. La documentation de l'extension couvre la mise en place ; notre article sur les bonnes pratiques AWS Lambda couvre les patterns d'environnement d'exécution associés.
Notre choix par défaut : Parameter Store d'abord, promotion des secrets qui le méritent
Nous stockons la configuration et les secrets statiques en paramètres SecureString au niveau standard, et nous déplaçons un secret vers Secrets Manager le jour où il exige rotation, accès inter-comptes ou réplication. Seul ce secret migre, pas tout le parc. La facture suit alors les besoins réels de cycle de vie plutôt que l'habitude.
Les hiérarchies de paramètres comme /app/prod/db offrent des lectures par chemin et un IAM par préfixe, que Secrets Manager n'approxime qu'avec des conventions de nommage. La séparation garde des politiques lisibles : ssm:GetParameter sur un préfixe pour la configuration, secretsmanager:GetSecretValue sur des ARN précis pour la poignée de valeurs sensibles. Quand nous passons en revue une structure de comptes lors d'une mission d'architecture AWS, les secrets mal placés apparaissent dans les deux sens : des frais mensuels payés pour des valeurs statiques, et des identifiants de base de données tournés à la main alors que la rotation gérée ferait mieux.
Face à face : coût, rotation, limites, partage
Le tableau condense la décision. Lisez la dernière ligne d'abord : la plupart des parcs ont besoin des deux services en même temps, pour des secrets différents, et rien n'empêche ce mélange au sein d'un même compte ou d'une même application. Les prix bougent et les quotas sont révisés, nous comparons donc des formes de coût et des comportements plutôt que des chiffres.
| Critère | Parameter Store (niveau standard) | Secrets Manager |
|---|---|---|
| Forme de coût | Stockage et lectures à débit standard gratuits ; KMS par requête pour SecureString ; le niveau avancé ajoute un mensuel par paramètre plus un coût par appel | Mensuel par secret plus appels d'API mesurés |
| Rotation native | Aucune | Gérée pour RDS, Redshift, DocumentDB ; via Lambda pour tout le reste |
| Taille max de valeur | 4 Ko (8 Ko en avancé) | 64 Ko |
| Débit | Modeste par défaut ; l'option débit supérieur change la facturation | Quotas par défaut élevés, facturation par appel |
| Inter-comptes | Niveau avancé uniquement, via AWS RAM | Oui, via politiques de ressource, plus réplication multi-régions |
| Quand il gagne | Configuration et secrets statiques, parcs sensibles au coût, lectures massives de valeurs stables | Identifiants en rotation, secrets consommés entre comptes, bascule multi-régions |
Check-list de décision
Passez chaque secret, pas chaque application, au crible de ces questions :
- Rotation automatique nécessaire ? Secrets Manager.
- Lu depuis un autre compte ? Secrets Manager, ou niveau avancé via AWS RAM si la rotation n'est pas requise.
- Doit exister dans plusieurs régions, synchronisé ? Réplication Secrets Manager.
- Configuration statique ou secret rarement modifié sous 4 Ko ? Parameter Store SecureString, niveau standard.
- Lu par Lambda à chaque invocation ? Ajoutez l'extension et un TTL avant de changer de service.