Cargando...
Cargando...
Stop guessing which service to use — master the decision framework that separates passing from failing on 8 AWS certifications
KMS encrypts keys, Secrets Manager rotates secrets, Parameter Store stores config — they complement, not compete
| Feature | KMS Encrypt and control your keys | Secrets Manager Rotate, manage, retrieve secrets | Parameter Store Hierarchical config and secret storage |
|---|---|---|---|
Primary Purpose KMS is a KEY management service — it manages encryption keys, not secrets. Secrets Manager manages secrets. Parameter Store manages configuration AND secrets (but with limitations). | Create, manage, and control cryptographic keys used to encrypt data across AWS services and applications | Securely store, rotate, and retrieve secrets such as database credentials, API keys, and OAuth tokens | Store configuration data and secrets in a hierarchical key-value store; both plaintext and encrypted |
Automatic Secret Rotation CRITICAL: Automatic rotation is the #1 differentiator. If a question mentions 'automatic rotation of database credentials,' the answer is almost always Secrets Manager. | Supports automatic annual key rotation for symmetric KMS keys (key material rotated, key ID stays the same) | Native built-in automatic rotation using Lambda functions; supports RDS, Redshift, DocumentDB, and custom rotation | NO native automatic rotation — you must build custom rotation logic yourself (e.g., via Lambda + EventBridge) |
Cost Model Cost is a real exam dimension. Parameter Store Standard tier is FREE — use this when budget is a constraint and rotation is not needed. Secrets Manager has no free tier. | ~$1/month per customer-managed KMS key; $0.03 per 10,000 API calls; AWS-managed keys are free to use | $0.40 per secret per month; $0.05 per 10,000 API calls — no free tier for secrets storage | Standard parameters: FREE (up to 10,000 parameters, 4KB each); Advanced parameters: $0.05/parameter/month for storage above 10,000 or >4KB |
Encryption Secrets Manager ALWAYS uses KMS under the hood. Parameter Store only uses KMS for SecureString type. KMS is the foundation both services rely on. | IS the encryption service — provides envelope encryption, generates data keys, never exposes plaintext master keys | Encrypts ALL secrets at rest automatically using KMS (uses aws/secretsmanager default key or a customer-managed KMS key) | SecureString parameters are encrypted using KMS; Standard String and StringList parameters are NOT encrypted |
Cross-Account Access For cross-account secret sharing, Secrets Manager is the right answer. Parameter Store cross-account access is complex and not a native feature. | Supported via key policies and IAM — you can grant cross-account access to KMS keys explicitly | Supported — resource-based policies on secrets allow cross-account access; must also grant KMS key access | NOT natively supported via resource-based policies — cross-account access requires IAM roles with assume-role patterns |
Secret Size Limit If you need to store large secrets (>8KB), neither Parameter Store nor Secrets Manager is ideal — consider S3 + KMS encryption instead. | N/A for secrets — KMS keys are cryptographic objects, not data storage; data keys up to 4KB for GenerateDataKey | Up to 65,536 bytes (64KB) per secret value | Standard: up to 4,096 bytes (4KB) per parameter; Advanced: up to 8,192 bytes (8KB) per parameter |
Parameter/Secret Hierarchy & Organization Parameter Store's GetParametersByPath is a favorite exam topic — it lets you retrieve all parameters under a path prefix with one API call, ideal for application config management. | Keys organized by aliases and key IDs; supports tags; no hierarchical path structure | Flat namespace with optional path-like naming convention (e.g., /prod/db/password); supports tags and resource policies | Native hierarchical path structure (e.g., /prod/app/db/password); GetParametersByPath API retrieves all params under a path |
Versioning Both Secrets Manager and Parameter Store support versioning. Secrets Manager uses staging labels (AWSCURRENT/AWSPREVIOUS) which is tested in exam questions about rotation. | Key rotation creates new key material but maintains same key ID; previous key material retained for decryption | Full version history maintained; AWSCURRENT, AWSPREVIOUS, AWSPENDING staging labels; can retrieve any version | Automatic versioning — each update creates a new version; you can retrieve specific versions; history retained |
Native AWS Service Integrations KMS has the broadest integration surface. When a question asks 'how do you encrypt data in Service X,' KMS is almost always part of the answer. | Integrates with 100+ AWS services natively (S3, EBS, RDS, Lambda, DynamoDB, etc.) for server-side encryption | Deep integration with RDS, Redshift, DocumentDB, Aurora for automatic rotation; ECS, EKS, Lambda for secret injection | Deep integration with EC2, ECS, EKS, Lambda, CodeBuild, CodeDeploy, CloudFormation for config retrieval |
Audit & Compliance All three services integrate with CloudTrail. For compliance scenarios requiring proof of key usage, KMS CloudTrail logs are the authoritative source. | Every API call logged to CloudTrail — who used which key, when, for what operation; supports CloudTrail Lake | All API calls (GetSecretValue, RotateSecret, etc.) logged to CloudTrail; rotation events visible | All API calls logged to CloudTrail; no dedicated audit dashboard — relies entirely on CloudTrail |
Resource Policies CRITICAL: KMS key policies are mandatory and different from IAM policies. A common exam trap: even if an IAM policy grants kms:Decrypt, the key policy must also allow it. | Key policies are REQUIRED — every KMS key must have a key policy; IAM policies alone are insufficient without key policy allowing it | Optional resource-based policies on secrets; required for cross-account access | No resource-based policies — access controlled entirely through IAM policies |
VPC Access (Private Connectivity) All three support VPC Interface Endpoints (PrivateLink). Do NOT confuse Interface Endpoints (PrivateLink) with Gateway Endpoints — Gateway Endpoints are only for S3 and DynamoDB. | VPC Endpoint (Interface Endpoint via PrivateLink) available — com.amazonaws.region.kms | VPC Endpoint (Interface Endpoint via PrivateLink) available — com.amazonaws.region.secretsmanager | VPC Endpoint (Interface Endpoint via PrivateLink) available via SSM endpoint — com.amazonaws.region.ssm |
FIPS 140 Compliance For government/regulated workloads requiring FIPS 140-3 Level 3, KMS (and CloudHSM for Level 3 dedicated hardware) are the answers. Secrets Manager and Parameter Store inherit this via KMS. | FIPS 140-3 Security Level 3 validated HSMs protect all KMS keys — keys never leave HSM unencrypted | Relies on KMS for encryption — inherits KMS FIPS compliance for the encryption layer | SecureString parameters rely on KMS — inherits KMS FIPS compliance; plaintext parameters have no HSM protection |
Multi-Region Support For disaster recovery and multi-region applications needing consistent secrets, Secrets Manager Multi-Region Secrets is the exam answer. Parameter Store requires custom replication. | Multi-Region Keys supported — primary key replicated to other regions; same key ID/material across regions for disaster recovery | Multi-Region Secrets supported — replicate secrets to multiple regions; keeps in sync with primary | NO native multi-region replication — you must manually manage parameter replication across regions |
CloudFormation Integration Dynamic references in CloudFormation are frequently tested. SSM Parameter Store uses {{resolve:ssm:}} and Secrets Manager uses {{resolve:secretsmanager:}}. Never hardcode secrets in CloudFormation templates. | Reference KMS keys in CloudFormation; can create KMS keys as resources (AWS::KMS::Key) | Can create secrets in CloudFormation (AWS::SecretsManager::Secret); dynamic references: {{resolve:secretsmanager:MySecret:SecretString:password}} | Dynamic references in CloudFormation: {{resolve:ssm:parameter-name}} and {{resolve:ssm-secure:parameter-name}} for SecureString |
Typical Use Case | Encrypting S3 objects, EBS volumes, RDS databases, generating data keys for client-side encryption, signing/verifying with asymmetric keys | Database passwords with automatic rotation, OAuth tokens, API keys for third-party services, any secret requiring lifecycle management | Application configuration (feature flags, URLs, non-sensitive settings), environment-specific configs, storing secrets when cost is a constraint and rotation is manual |
Asymmetric Key Support Only KMS handles asymmetric cryptography. For digital signatures, certificate signing, or public-key encryption use cases, KMS is the only answer among these three. | Full support — RSA (2048, 3072, 4096), ECC (P-256, P-384, P-521, SM2), and ML-KEM (post-quantum) key specs for encryption and signing | Not applicable — Secrets Manager stores secret values, not cryptographic key objects | Not applicable — Parameter Store stores configuration values, not cryptographic key objects |
Throughput / Request Limits If an application gets ThrottlingException from KMS, the fix is to implement exponential backoff AND consider using data key caching (LocalCryptographicMaterialsCache) to reduce KMS API calls. | Request quotas vary by API and region — all quotas are adjustable except CloudHSM key store quotas; throttling uses token bucket algorithm | Service quotas apply per region per account — adjustable via Service Quotas console | Standard throughput: default API request rate applies; Higher throughput tier available for advanced parameters at additional cost |
Summary
Use KMS when you need to manage cryptographic keys and encrypt data across AWS services — it is the encryption foundation everything else builds on. Use Secrets Manager when you need to store secrets (especially database credentials) with automatic rotation, versioning, and cross-account access. Use Parameter Store when you need hierarchical configuration management, have budget constraints (free tier), or are storing non-sensitive config alongside some encrypted secrets without needing automatic rotation.
🎯 Decision Tree
If the question mentions 'automatic rotation of credentials' → Secrets Manager. If the question mentions 'encrypt data' or 'data key' or 'envelope encryption' → KMS. If the question mentions 'application configuration' or 'free' or 'hierarchical parameters' → Parameter Store. If the question mentions 'database password that must rotate every 30 days' → Secrets Manager. If the question mentions 'storing API keys with no rotation needed and cost matters' → Parameter Store SecureString. If the question mentions 'FIPS 140-3' or 'HSM-backed keys' → KMS. If the question mentions 'cross-account secret sharing' → Secrets Manager + KMS key policy.
AUTOMATIC ROTATION = SECRETS MANAGER. This is non-negotiable. Any exam question mentioning 'automatic rotation of database credentials,' 'rotate every N days,' or 'managed rotation lifecycle' points exclusively to Secrets Manager. Parameter Store has zero native rotation capability. KMS rotates key material (not secrets). If you see 'rotation' in a question about application secrets, pick Secrets Manager every time.
KMS KEY POLICIES ARE MANDATORY AND ADDITIVE WITH IAM. Every KMS key must have a key policy. Even if an IAM policy grants kms:Decrypt to a role, if the key policy does not also allow that principal (or allow IAM to manage access), the call will be denied. The default key policy grants the root account full access, which then allows IAM policies to work — but custom key policies that restrict access override IAM. This is tested constantly in SCS-C02 and SAA-C03.
COST OPTIMIZATION QUESTIONS: Parameter Store Standard = FREE. When an exam scenario mentions 'minimize cost,' 'budget-constrained,' 'hundreds of configuration parameters,' or 'non-sensitive application config,' Parameter Store Standard is the answer. Secrets Manager costs $0.40/secret/month with no free tier. Never recommend Secrets Manager when cost minimization is the goal AND automatic rotation is not required.
CLOUDFORMATION DYNAMIC REFERENCES: Two different syntaxes tested on exams. Parameter Store: {{resolve:ssm:/my/param/name}} for plaintext, {{resolve:ssm-secure:/my/param/name}} for SecureString. Secrets Manager: {{resolve:secretsmanager:MySecret:SecretString:username}}. Never hardcode credentials in CloudFormation templates — this is always wrong on exam questions.
VPC ENDPOINTS FOR ALL THREE: KMS, Secrets Manager, and SSM Parameter Store all support Interface VPC Endpoints (PrivateLink). This allows Lambda functions, EC2 instances, and ECS tasks in private subnets to access these services without traversing the internet. Do NOT confuse with Gateway Endpoints — those are ONLY for S3 and DynamoDB. Any question about 'accessing Secrets Manager from a private subnet without internet access' = Interface VPC Endpoint.
ENVELOPE ENCRYPTION PATTERN: KMS never encrypts your data directly (for large data) — it generates a data key via GenerateDataKey. You use the plaintext data key to encrypt your data, store the encrypted data key alongside the ciphertext, then discard the plaintext key. To decrypt: call KMS Decrypt with the encrypted data key to get the plaintext key, then decrypt your data locally. This is the envelope encryption pattern — it reduces KMS API calls and is the foundation of AWS SDK encryption.
SECRETS MANAGER ROTATION LAMBDA ARCHITECTURE: The rotation Lambda function must have network access to BOTH the Secrets Manager VPC endpoint (or public endpoint) AND the database being rotated. If the database is in a private subnet, the Lambda must be in the same VPC with appropriate security group rules. This is a common architecture question in DVA-C02 and DOP-C02.
PARAMETER STORE GETPARAMETERSBY PATH: Use GetParametersByPath API to retrieve all parameters under a path prefix in a single API call (e.g., get all /prod/myapp/* parameters at once). This is a key exam differentiator for Parameter Store vs environment variables — it's more secure, centralized, and supports hierarchical organization. Recursive flag retrieves nested paths.
The #1 exam trap: Using Parameter Store SecureString instead of Secrets Manager for database credentials that need automatic rotation. Candidates see 'SecureString' and 'KMS encryption' in Parameter Store and assume it's equivalent to Secrets Manager for sensitive credentials. It is NOT — Parameter Store has NO automatic rotation. The moment a question mentions 'automatic rotation,' 'managed credential lifecycle,' or 'rotate every X days,' the only correct answer is Secrets Manager. A secondary trap: assuming KMS and Secrets Manager are alternatives — they are complementary. Secrets Manager USES KMS to encrypt secrets. You need both for a complete secrets management solution.
CertAI Tutor · DVA-C02, DOP-C02, SCS-C02, SAA-C03, SAP-C02, DEA-C01, AIF-C01, CLF-C02 · 2026-02-22
Services
Comparisons
Guides & Patterns