KMS vs Secrets Manager: Different Jobs

In cloud infrastructure, confusion often arises between AWS Key Management Service (KMS) and AWS Secrets Manager. Both handle sensitive data, both integrate with IAM, and both are essential for security. However, treating them as interchangeable alternatives leads to architectural flaws. The correct mental model is not "KMS or Secrets Manager," but rather recognizing their distinct roles in the encryption chain: KMS manages the cryptographic keys, while Secrets Manager manages the sensitive values encrypted by those keys.

This distinction dictates how you design your security controls, manage costs, and automate operations.

The Core Mechanism: Keys vs. Values

To understand the difference, we must look at what each service actually stores and manages.

AWS KMS is a Key Management Service. Its primary artifact is the KMS key (formerly known as a Customer Master Key or CMK). A KMS key is a cryptographic key used to encrypt and decrypt data. KMS handles the generation, storage, rotation, and policy enforcement of these keys. When you use KMS, you are interacting with cryptographic primitives. You might use KMS to encrypt an S3 object, an EBS volume, or a database field. The "secret" here is the key itself, which is never exposed in plaintext to your application code. For more details on key types, see the AWS KMS Developer Guide.

AWS Secrets Manager is a Secret Storage Service. Its primary artifact is the secret value—a string, password, API key, or database credential. Secrets Manager provides features specifically designed for the lifecycle management of these values: versioning, automated rotation, and fine-grained access control. Crucially, Secrets Manager does not generate encryption keys. It relies on KMS to encrypt the secret values it stores.

AWS Secrets Manager encrypts secrets with a KMS key. This dependency is fundamental: every secret in Secrets Manager is encrypted with a KMS key, either one you specify or the default AWS managed key (aws/secretsmanager) if you don't.

Data Flow and Encryption

The relationship between KMS and Secrets Manager is hierarchical. Secrets Manager uses KMS as its backend encryption engine.

When you store a secret, such as a database password, Secrets Manager performs the following steps:

1. It generates a unique encryption key for that specific secret version (or uses a dedicated KMS key).
2. It encrypts the plaintext password using that KMS key.
3. It stores the ciphertext in its internal database.
4. It returns only the ciphertext to the storage layer.

When your application retrieves the secret, the flow reverses:

1. Your application requests the secret from Secrets Manager via IAM-authenticated API.
2. Secrets Manager retrieves the ciphertext.
3. Secrets Manager calls KMS to decrypt the ciphertext using the associated KMS key.
4. Secrets Manager returns the plaintext password to your application.

This mechanism ensures that your application never sees the KMS key, and KMS never sees the plaintext secret directly (it only sees the ciphertext and the decryption request). This separation of duties is critical for security. If you were to store secrets in plain text in S3 or DynamoDB, you would need to manage the encryption keys yourself. By using Secrets Manager, you offload the encryption process to KMS, while gaining additional features like rotation and audit trails. See the AWS Secrets Manager documentation for IAM policy examples.

Operational Use Cases: Rotation and Integration

While both services secure data, their operational features cater to different needs.

Secrets Manager excels at secret rotation. For databases like Amazon RDS, Secrets Manager can automatically rotate credentials using Lambda functions. You define a rotation schedule, and Secrets Manager updates the password in the database and updates the stored secret value. KMS has no concept of rotating database passwords; it only rotates the encryption keys it uses.

KMS excels at data-at-rest encryption. If you are encrypting large datasets, such as S3 buckets or EBS volumes, KMS is the appropriate tool. You do not need Secrets Manager to encrypt an S3 bucket. You simply configure the bucket to use a KMS key. The data is encrypted at rest, and KMS manages the key lifecycle. Secrets Manager is not involved in this process.

Furthermore, Secrets Manager integrates directly with RDS to automate credential rotation. You can configure an RDS instance's rotation schedule so Secrets Manager updates the database password on a regular cadence using a Lambda rotation function. KMS does not provide this integration.

Cost and Complexity Considerations

The pricing models for KMS and Secrets Manager reflect their different roles.

KMS pricing is based on two components:

1. A monthly fee per KMS key.
2. A per-request fee for encrypt, decrypt, generateDataKey, and other operations.

High-volume encryption operations can incur significant costs if not optimized. For example, frequent Decrypt calls on high-traffic endpoints can lead to noticeable charges. If you use a single KMS key for many objects, the cost is manageable.

Secrets Manager pricing is based on the number of secrets stored per month, plus a small fee for API requests. If you have thousands of short-lived secrets, Secrets Manager costs can become significant. However, if you only have a few dozen database credentials, the cost is negligible.

Using both services together is the standard pattern. You might use one KMS key to encrypt all secrets in Secrets Manager. This minimizes KMS costs (one key) while gaining the benefits of Secrets Manager (rotation, versioning). If you use separate KMS keys for each secret, you will incur a monthly fee for each key, which can become expensive. See the AWS Pricing Calculator for detailed cost estimates.

Conclusion

KMS and Secrets Manager are not competitors; they are complementary services. KMS manages the cryptographic keys that secure data. Secrets Manager manages the sensitive values that need to be rotated and accessed securely.

For most applications, the recommended architecture is:

1. Use KMS to create and manage KMS keys.
2. Use Secrets Manager to store and rotate database credentials, API keys, and other secrets.
3. Configure Secrets Manager to use your KMS keys for encryption.

This approach leverages the strengths of both services: the cryptographic security of KMS and the operational convenience of Secrets Manager. By understanding their distinct roles, you can build more secure, maintainable, and cost-effective cloud infrastructure.

Pitfalls

A common architectural mistake is using Secrets Manager to encrypt large datasets, such as entire S3 buckets or EBS volumes. Secrets Manager is optimized for small, short-lived secrets, not bulk data encryption, and attempting to do so leads to unnecessary complexity and cost. Conversely, using KMS alone for secret rotation without integrating with a service like Secrets Manager or Lambda requires building custom logic for credential lifecycle management, which is error-prone and lacks the built-in audit trails and versioning that Secrets Manager provides.

Takeaways

• KMS manages keys: It handles the generation, storage, and policy enforcement of cryptographic keys.
• Secrets Manager manages values: It stores sensitive strings (passwords, API keys) and handles their lifecycle, including rotation.
• Dependency: Secrets Manager relies on KMS to encrypt the secrets it stores; they are not mutually exclusive.
• Use Case Fit: Use KMS for data-at-rest encryption (S3, EBS) and Secrets Manager for dynamic secret management (RDS credentials, API keys).

FAQ

Can I use Secrets Manager without KMS? No. Secrets Manager always encrypts secret values with a KMS key. If you don't specify a customer managed key, it automatically uses the default AWS managed key (aws/secretsmanager).

How does pricing compare between KMS and Secrets Manager? KMS charges a monthly fee per key and a per-request fee for encryption/decryption operations. Secrets Manager charges a monthly fee per secret and a small fee for API requests. Costs can add up in both services if you have high volumes of operations or many short-lived secrets, respectively.

Do I need both services? For most applications, yes. You typically use KMS to encrypt data at rest (like S3 buckets) and Secrets Manager to manage dynamic secrets like database credentials. They serve different parts of the security chain.