AWS KMS vs Secrets Manager Which One Should You Use

Summary:

• AWS KMS handles cryptographic key management and encryption operations, while Secrets Manager stores, rotates, and retrieves sensitive credentials with built-in lifecycle automation.
• Decide between AWS KMS and Secrets Manager based on whether you need to protect encryption keys or store retrievable credentials
• Why Secrets Manager always uses KMS under the hood, making the two services complementary rather than competing
• When to use customer-managed KMS keys with Secrets Manager for cross-account access, compliance auditing, or granular key policy control

Choosing between AWS KMS and Secrets Manager is not actually a choice at all for most production workloads. The two services occupy different layers of the security stack. Understanding where each belongs prevents both over-engineering and dangerous gaps. KMS manages cryptographic keys that never leave hardware security modules. Secrets Manager stores and rotates credentials your applications retrieve at runtime.

The confusion arises because Secrets Manager encrypts every secret using KMS, creating a dependency that makes the services inseparable in practice. This guide breaks down the architectural boundaries, cost implications, and decision criteria so you can deploy both services correctly from day one.

What is AWS KMS?

AWS Key Management Service solves the problem of cryptographic key lifecycle management without requiring you to operate hardware security modules yourself. KMS generates, stores, and controls access to symmetric and asymmetric encryption keys that protect data across more than 100 integrated AWS services. The keys themselves never leave FIPS 140-3 validated HSMs, which means your application code requests cryptographic operations rather than handling raw key material. This architecture eliminates an entire class of key exposure vulnerabilities that plague self-managed encryption systems.

KMS supports three key ownership models that determine cost, control, and operational overhead. AWS-owned keys are free and fully managed by AWS, used transparently by services like S3 default encryption. AWS-managed keys are created automatically when you enable encryption on services like RDS or EBS. These keys are visible in your account but not deletable or configurable beyond viewing audit logs.

Customer-managed keys provide full control over key policies, rotation schedules, and cross-account sharing, but incur monthly storage fees and per-request charges. Most compliance-sensitive workloads require customer-managed keys because auditors need evidence of explicit key policy governance.

The service operates through envelope encryption, a two-tier system where KMS generates data keys that encrypt your actual data, then encrypts those data keys under a KMS key. Your application receives both the plaintext data key for immediate use and the encrypted data key for storage alongside the ciphertext. Decryption reverses this process. KMS decrypts the data key, and your application uses the plaintext data key locally. This design minimizes KMS API calls while keeping the root key material protected. Understanding envelope encryption is essential before evaluating how Secrets Manager integrates with KMS.

What is AWS Secrets Manager?

Secrets Manager eliminates hardcoded credentials from application source code by providing a secure, centralized store for database passwords, API keys, OAuth tokens, and other sensitive strings. Applications retrieve secrets at runtime through API calls, replacing static configuration files with dynamic credential injection. This shift fundamentally changes how credentials flow through your deployment pipeline. Secrets no longer exist in version control, container images, or environment variable definitions visible to operators.

The service differentiates itself from simple encrypted storage through automatic rotation. Secrets Manager can rotate credentials on a schedule you define, coordinating the update between the secret store and the target service. For supported databases like Amazon RDS, Aurora, Redshift, and DocumentDB, AWS provides managed Lambda rotation functions that handle the credential change without application downtime.

For custom services, you write a Lambda function implementing four rotation steps. First, create the new secret version. Second, set the credential in the target system. Third, test the new credential. Fourth, finalize the rotation. This automation reduces the operational burden of credential hygiene from a manual process to a configuration setting.

Every secret stored in Secrets Manager is encrypted at rest using envelope encryption with a KMS key. By default, Secrets Manager uses an AWS-managed key named aws/secretsmanager at no additional KMS charge. You can alternatively specify a customer-managed KMS key when creating or updating a secret. This enables cross-account secret access, custom key policies, and separation of encryption key administration from secret administration. The encryption happens transparently. When you call GetSecretValue, Secrets Manager decrypts the data key using KMS, then decrypts the secret value using that data key before returning plaintext to your application.

AWS KMS vs Secrets Manager core differences

The fundamental distinction is what each service stores and returns. KMS stores cryptographic keys that never leave the HSM boundary. You send data to KMS for encryption or decryption, and KMS returns the result. Secrets Manager stores arbitrary secret values up to 65,536 bytes and returns the plaintext when authorized applications request it. KMS is a cryptographic primitive. Secrets Manager is a credential management system built on top of that primitive.

Storage model and data handling

KMS keys exist only within HSMs. When you call Encrypt or GenerateDataKey, KMS performs the operation internally and returns ciphertext or a data key. You cannot export a KMS key’s raw material unless you created it with external key material import, and even then the material remains protected by the HSM during use. This design provides strong guarantees against key compromise but means KMS cannot store retrievable secrets like database passwords.

Secrets Manager stores the actual secret value, encrypted, in AWS-managed infrastructure. When you call GetSecretValue, the service decrypts and returns the plaintext. This makes Secrets Manager appropriate for credentials that applications need to use directly, such as connection strings, API tokens, or certificate private keys. The trade-off is that the plaintext exists momentarily in memory during retrieval, whereas KMS key material never exists outside the HSM.

Rotation capabilities

KMS supports automatic key rotation for symmetric customer-managed keys, generating new cryptographic material annually while preserving the ability to decrypt data encrypted under previous versions. This rotation is transparent to applications because the key ID remains constant. However, KMS rotation applies to the encryption key itself, not to credentials protected by that key.

Secrets Manager rotation changes the actual secret value and coordinates that change with the target system. A rotation Lambda function generates a new password, updates the database user, tests connectivity, and promotes the new version to current. This is operationally complex but solves the real-world problem of credential expiration and compromise response. KMS rotation and Secrets Manager rotation address different layers of the security stack and are not substitutes for each other.

Here’s a comparison table for AWS KMS and AWS Secrets Manager:

Cost modeling at scale

Pricing differences between KMS and Secrets Manager become significant at scale. The interaction between the two services creates cost dynamics that are not obvious from reading pricing pages in isolation. Understanding these economics prevents budget surprises and informs architectural decisions about caching, key reuse, and regional deployment.

KMS pricing structure

Customer-managed KMS keys incur a monthly storage fee regardless of usage. Each cryptographic API request (Encrypt, Decrypt, GenerateDataKey, and similar operations) incurs a per-request charge. The request cost varies by key type. Symmetric operations are cheapest, RSA operations cost more, and elliptic curve operations fall between. Multi-region keys incur the monthly fee in each region where a replica exists.

Cost optimization strategies include:

• Data key caching: The AWS Encryption SDK supports caching generated data keys, reducing GenerateDataKey calls by reusing keys for multiple encryption operations within configurable limits.
• S3 Bucket Keys: For S3 server-side encryption with KMS, enabling Bucket Keys reduces KMS request volume by using a bucket-level key to derive object keys locally.
• Quota monitoring: Approaching request quotas triggers throttling, which can cascade into application failures. CloudWatch alarms on KMS request metrics prevent this.

Secrets Manager pricing structure

Secrets Manager charges per secret per month, plus a per-10,000-API-call fee for retrieval operations. The monthly secret fee applies regardless of how often the secret is accessed. Secrets replicated to additional regions incur the per-secret fee in each region. Rotation using AWS-provided Lambda functions incurs standard Lambda charges for the rotation function invocations.

Cost optimization strategies include:

• Client-side caching: The Secrets Manager caching library stores retrieved secrets in memory with configurable TTL, dramatically reducing GetSecretValue calls.
• Secret consolidation: Storing multiple related credentials as key-value pairs within a single secret reduces the per-secret monthly fee, though this trades off against granular access control.
• Cost allocation tags: As of May 2025, Secrets Manager supports cost allocation tags, enabling per-team or per-application expense tracking through AWS Cost Explorer.

Combined cost considerations

When Secrets Manager uses a customer-managed KMS key, every secret encryption and decryption operation generates KMS API calls. High-frequency secret retrieval without caching can produce substantial KMS charges on top of Secrets Manager fees. The default aws/secretsmanager key avoids these KMS charges but sacrifices cross-account access and custom key policy capabilities. Evaluate whether your compliance requirements justify the additional cost of customer-managed keys.

Cross-region and multi-account architectures

Global applications require secrets and encryption keys available in multiple regions with minimal latency. Both KMS and Secrets Manager offer replication features, but they work differently and serve different architectural needs.

KMS multi-region keys

Multi-region KMS keys share the same key ID and key material across selected regions. Data encrypted in one region can be decrypted in another without cross-region API calls, enabling disaster recovery and active-active architectures. You designate one region as primary and replicate to others. The primary key is the source of truth for shared properties like key material and rotation configuration. Each replica is a fully functional key that operates independently if the primary region becomes unavailable.

Secrets Manager cross-region replication

Secrets Manager replicates the encrypted secret value and metadata to selected regions. Each replica is encrypted with a KMS key in its destination region, which can be the default aws/secretsmanager key or a customer-managed key you specify. When you rotate the primary secret, Secrets Manager automatically propagates the new value to all replicas. Replication status is visible in the console and through the DescribeSecret API.

The critical architectural difference is this. KMS multi-region keys allow decryption without cross-region calls, while Secrets Manager replication creates independent copies that applications access locally. For secrets, this means applications in each region call their local Secrets Manager endpoint, reducing latency and eliminating cross-region dependencies during retrieval.

Decision framework for when to use each service

The decision is rarely either/or. Most production architectures use both services in their appropriate roles. The following criteria help you determine which service handles which responsibility.

Use KMS alone when

AWS KMS is a suitable option when:

• You need to encrypt data at rest or in transit without storing retrievable credentials
• You are integrating with AWS services that handle encryption transparently (S3, EBS, RDS encryption at rest)
• You require digital signing or verification operations
• You need asymmetric encryption for scenarios like client-side encryption with public key distribution

Use Secrets Manager when

AWS Secrets Manager is a suitable when:

• Applications need to retrieve credentials at runtime (database passwords, API keys)
• You require automatic credential rotation with target system coordination
• You want centralized secret management with audit logging
• You need cross-region secret availability for global applications

Use both together when

This is the default for Secrets Manager usage. Every secret is encrypted with a KMS key. The question is whether to use the default AWS-managed key or a customer-managed key. Choose customer-managed keys when you need cross-account access, custom key policies, or compliance requirements that mandate explicit key governance documentation.

Security and compliance considerations

Both services integrate with IAM for access control, CloudTrail for audit logging, and AWS Config for compliance monitoring. However, the security boundaries differ in ways that affect your compliance posture.

KMS key policies define who can use a key for cryptographic operations and who can administer the key. These policies are separate from IAM policies and must explicitly grant access. A common misconfiguration is creating a key without granting any principals administrative access, which can result in an unusable key that requires AWS Support intervention to recover.

Secrets Manager supports both IAM policies and resource-based policies attached to individual secrets. Resource-based policies enable cross-account access without requiring IAM role assumption in some scenarios. The service also integrates with Amazon GuardDuty for anomaly detection on secret access patterns.

For compliance frameworks like SOC 2, PCI DSS, and HIPAA, both services provide the necessary controls. KMS keys are generated and stored in FIPS 140-2 validated HSMs. Secrets Manager encrypts all data at rest and in transit. CloudTrail logs provide the audit trail required for most compliance certifications. The key differentiator is that customer-managed KMS keys give you documented evidence of key policy governance, which some auditors require.

Conclusion

AWS KMS and Secrets Manager are complementary services that address different security requirements. KMS provides the cryptographic foundation through key generation, storage, and operations within hardware security modules. Secrets Manager builds on that foundation to store, retrieve, and rotate credentials that applications need at runtime. The confusion between them dissolves once you recognize that Secrets Manager is a KMS customer, not a competitor.

For most architectures, the practical decision is not which service to use but how to configure their integration. Start with the default aws/secretsmanager KMS key for simplicity. Migrate to customer-managed keys when cross-account access, custom key policies, or compliance documentation requirements emerge. Implement client-side caching for both services to control costs and avoid throttling at scale. Monitor request quotas through CloudWatch and Service Quotas before they become production incidents.

The services will continue evolving. KMS has added post-quantum TLS support and expanded multi-region key capabilities. Secrets Manager now supports cost allocation tags for granular expense tracking. Stay current with AWS announcements, but the architectural boundary between key management and credential management will remain stable. Build on that boundary, and your security architecture will scale with your application.