Introduction to AWS Secrets Manager

AWS Secrets Manager is a managed service that stores, rotates, and audits secrets such as database passwords, API keys, and OAuth tokens throughout their lifecycle. It matters because hard-coded credentials in application code are one of the most common causes of data breaches and compliance failures. The recommended action is to migrate all application secrets to Secrets Manager, configure a customer-managed KMS key for encryption, enable automatic rotation, and turn on CloudTrail Data Access logging for all secret retrieval events.

Quick Answer: What Does AWS Secrets Manager Do?

AWS Secrets Manager is a centralized secrets store that eliminates hard-coded credentials from application code. It encrypts every secret at rest using AWS KMS (AES-256-GCM envelope encryption), transmits secrets only over TLS, provides automatic credential rotation via AWS Lambda for supported databases and custom targets, controls access through IAM resource-based policies, and logs every secret access in CloudTrail. It natively integrates with Amazon RDS, Amazon DocumentDB, Amazon Redshift, and over 100 other AWS services. Secrets Manager is distinct from AWS KMS: KMS manages encryption keys; Secrets Manager manages the secrets those keys protect. For the KMS encryption layer, see our guide on How Secure Are Key Management Services of Amazon (AWS KMS)?

Key Takeaways

• Secrets Manager eliminates hard-coded credentials: Every secret is stored in a central managed service and retrieved via API call, removing credentials from source code, configuration files, and CI/CD pipelines where they are routinely exposed in version control and logs.
• Encryption uses KMS envelope encryption with AES-256-GCM: The secret value is encrypted with a data key generated by AWS KMS. The plaintext data key is discarded immediately after use. By default, the AWS-managed key (aws/secretsmanager) is used. Customer-managed keys provide an independent audit trail and revocation capability for compliance workloads.
• Automatic rotation is the defining capability over competing services: Secrets Manager provides built-in Lambda-based rotation for Amazon RDS, DocumentDB, and Redshift. Custom Lambda functions support rotation for any other secret type including third-party API keys, on-premises databases, and OAuth tokens.
• IAM resource-based policies are the primary access control mechanism: Every secret has a resource policy that controls which principals can retrieve, rotate, or delete it. This provides fine-grained control at the secret level, separate from account-level IAM identity policies.
• CloudTrail integration provides the compliance audit trail: Every Secrets Manager API call (GetSecretValue, CreateSecret, RotateSecret, DeleteSecret) is logged in CloudTrail with the requesting identity, secret ARN, and timestamp. Enabling KMS Data Access logging additionally captures every decryption event tied to secret retrieval.

What Is AWS Secrets Manager?

AWS Secrets Manager is a fully managed secrets management service that handles the storage, retrieval, rotation, and audit of application secrets throughout their lifecycle. A secret in this context is any piece of sensitive credential information that an application or service uses to authenticate to another resource: database usernames and passwords, API keys, OAuth access tokens, TLS private keys, SSH credentials, and service account passwords.

Without a centralized secrets manager, credentials are typically embedded in application code, configuration files, environment variables, CI/CD pipeline definitions, or scripts. Any of these locations can inadvertently expose credentials through version control systems, log aggregation, build artifacts, or container image layers. AWS Secrets Manager replaces all of these patterns with a single API call that retrieves the current secret value on demand, over an encrypted channel, to an authenticated caller.

AWS Secrets Manager is a separate service from AWS Key Management Service (AWS KMS). KMS manages the cryptographic keys that protect secrets; Secrets Manager manages the secrets themselves. The two services work together: every secret stored in Secrets Manager is encrypted by an AWS KMS data key before being written to Secrets Manager’s persistent storage. Understanding this distinction matters for compliance mapping and for deciding which KMS key type to use. For full coverage of the KMS encryption layer, see our guide on AWS KMS Deep Dive.

How AWS Secrets Manager Encrypts Secrets

Every secret value stored in AWS Secrets Manager is encrypted at rest using envelope encryption via AWS KMS. The process works as follows:

1. When you store a secret, Secrets Manager calls the AWS KMS GenerateDataKey operation, specifying the KMS key configured for that secret.
2. AWS KMS returns a plaintext AES-256 data key and an encrypted copy of the same data key (wrapped by the KMS key).
3. Secrets Manager uses the plaintext data key to encrypt the secret value using AES-256-GCM (Authenticated Encryption with Associated Data).
4. Secrets Manager stores the encrypted secret value and the encrypted data key together in its persistent storage.
5. The plaintext data key is discarded immediately from memory. It is never persisted anywhere.
6. When a secret is retrieved, Secrets Manager sends the encrypted data key to AWS KMS for decryption. KMS returns the plaintext data key.
7. Secrets Manager uses the plaintext data key to decrypt the secret value and returns the plaintext secret to the caller over a TLS-encrypted connection.
8. The plaintext data key is again discarded from memory after use.

Secrets Manager never stores secret values in plaintext in any persistent storage layer. The encrypted data key stored alongside the secret is useless without access to the KMS key that wrapped it, which means compromising Secrets Manager’s storage alone is not sufficient to recover plaintext secrets.

Native KMS Key vs. Customer-Managed KMS Key: Which to Use

By default, Secrets Manager uses an AWS-managed KMS key with the alias aws/secretsmanager. This key is created automatically in your account the first time you create a secret without specifying a KMS key. Switching to a customer-managed KMS key (CMK) is the compliance-grade configuration for regulated workloads.

Property	AWS-Managed Key (aws/secretsmanager)	Customer-Managed KMS Key (CMK)
Key generated by	AWS automatically	You, in your AWS KMS console or via API
Key policy control	None (AWS manages fully)	Full (you define who can use and manage the key)
Per-operation CloudTrail audit log	No (limited events only)	Yes (every Encrypt and Decrypt tied to secret retrieval)
Independent key disable/revoke	No	Yes (disable CMK to immediately block all secret retrieval)
Automatic key rotation	Yes (AWS-controlled schedule)	Yes (configurable 90 days to 7 years)
BYOK support	No	Yes (import your own key material via KMS Import Jobs)
FIPS 140-2 Level 3 option	No	Yes (with CloudHSM custom key store)
Additional cost	None	$0.06 to $2.50/key version/month + $0.03/10k KMS ops
Best for	Development, non-regulated workloads	Regulated workloads: PCI DSS, HIPAA, FedRAMP, GDPR

For workloads where AWS must have zero access to the secret encryption key (HYOK/Hold Your Own Key requirements), the appropriate approach is to encrypt the secret value client-side before passing it to Secrets Manager, using a key held outside AWS entirely. Secrets Manager would then store the already-encrypted value. This adds operational complexity and removes the ability to use native rotation, but fully excludes AWS from the key trust chain. Encryption Consulting’s HSM as a Service provides the external FIPS 140-2 Level 3 key management infrastructure for HYOK implementations.

How Automatic Secret Rotation Works

Automatic rotation is the capability that most distinguishes AWS Secrets Manager from simpler parameter stores. When rotation is triggered, Secrets Manager executes an AWS Lambda function that follows a four-step lifecycle:

1. CreateSecret: The Lambda function generates a new credential value and creates a new version of the secret in Secrets Manager with the staging label AWSPENDING. The previous version retains the AWSCURRENT label throughout this step, so existing connections continue to use the current credential.
2. SetSecret: The Lambda function updates the credential in the target service (the database, API, or other service) with the new value. The target service now accepts both the old credential (still in AWSCURRENT) and the new one.
3. TestSecret: The Lambda function tests the new credential against the target service to confirm it works before the old one is retired. If the test fails, rotation stops and the old credential remains active.
4. FinishSecret: The Lambda function moves the AWSCURRENT label to the new version and moves AWSPREVIOUS to the old version. The new credential is now current. The old credential version is retained briefly so that any in-flight connections using it can complete.

For Amazon RDS (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB), Amazon DocumentDB, and Amazon Redshift, AWS provides managed Lambda rotation functions that handle all four steps automatically. These are the easiest rotation deployments and are ready to configure through the Secrets Manager console or via AWS CloudFormation. For any other secret type, you deploy a custom Lambda function that implements the same four-step pattern. This supports rotation for on-premises databases, third-party API services, SSH keys, OAuth tokens, and any credential that has a programmable update mechanism.

Rotation can be configured to run on a schedule (the minimum interval is 1 day) or triggered immediately on demand. For compliance workloads under PCI DSS Requirement 8.3.9 (periodic authentication credential rotation), automatic rotation on a 90-day or shorter schedule satisfies the requirement without manual intervention.

IAM Access Model: Controlling Who Can Retrieve Secrets

Access to secrets in AWS Secrets Manager is controlled through two layers: IAM identity policies and secret resource-based policies. Both must permit a principal before access is granted.

Secret resource-based policy (primary control): Each secret has a resource policy that explicitly defines which AWS principals (IAM roles, IAM users, AWS accounts, or AWS services) can perform which operations on that specific secret. The key operations to control are secretsmanager:GetSecretValue (retrieve the secret), secretsmanager:RotateSecret (trigger rotation), secretsmanager:DeleteSecret (schedule deletion), and secretsmanager:PutSecretValue (write a new secret value). The resource policy provides secret-level granularity: an application’s service account can be granted GetSecretValue on its specific secrets only, with no access to any other secret in the account.

IAM identity policy (secondary layer): IAM policies attached to roles, users, or groups can grant Secrets Manager permissions. For access to succeed, both the identity policy and the resource policy must permit the operation. This dual-layer model means you can use identity policies to grant broad Secrets Manager access and then restrict it at the secret level with resource policies, or vice versa.

Cross-account access: Secrets Manager supports cross-account secret access by adding the external account’s principal to the secret’s resource policy and granting the secret’s KMS key usage to the external account. This pattern is useful for shared services accounts managing secrets for multiple application accounts, or for centralizing secrets management in a dedicated secrets account.

Tag-based access control: Secrets Manager supports AWS resource tags. You can use IAM policy conditions based on secret tags (for example, aws:ResourceTag/Environment: Production) to restrict access to production secrets to specific roles, while development roles can only access development-tagged secrets. This is useful for large environments where managing individual secret ARNs in policies is impractical.

Service Control Policies (SCPs): If your accounts are in an AWS Organization, SCPs can enforce organization-wide guardrails: require that all secrets use customer-managed KMS keys, deny deletion of secrets tagged as production, or require that the Secrets Manager VPC endpoint is used for all secret retrievals within a specific OU.

CloudTrail Audit Logging for Secrets Manager

AWS Secrets Manager is fully integrated with AWS CloudTrail. Every Secrets Manager API call generates a CloudTrail event recording the operation name, the secret ARN, the requesting IAM identity, the source IP address, the AWS region, and the timestamp. This audit trail is the primary evidence source for compliance reviews covering secret access.

Management events (CreateSecret, DeleteSecret, RotateSecret, PutResourcePolicy, TagResource) are logged automatically in CloudTrail and cannot be disabled. These events capture the administrative lifecycle of each secret.

Data events (GetSecretValue) must be enabled separately in CloudTrail. Enabling data events for Secrets Manager creates a log entry for every secret retrieval, showing exactly which application or user retrieved which secret and when. For PCI DSS Requirement 10, HIPAA Audit Control requirements, and FedRAMP AU controls, data events must be enabled. Without data event logging, you can prove a secret was created and rotated, but you cannot prove who retrieved it or when.

KMS Data Access logs add a second layer: every KMS Decrypt call triggered by a Secrets Manager GetSecretValue request generates a CloudTrail event showing the KMS key ARN used, the requesting Secrets Manager service, and the timestamp. This log is the cryptographic evidence that a specific secret was decrypted at a specific time.

Key alerts to configure from CloudTrail Secrets Manager events: alert immediately on DeleteSecret for any production secret; alert on GetSecretValue calls from IAM principals not in the approved application role list; alert on high-frequency GetSecretValue calls that may indicate automated credential harvesting; and alert on PutResourcePolicy changes to any production secret that could expand access.

Core Features of AWS Secrets Manager

Integration with AWS KMS: Every secret is encrypted at rest using AWS KMS envelope encryption. Secrets Manager supports both AWS-managed keys (aws/secretsmanager) and customer-managed KMS keys. When a customer-managed CMK is configured, every secret retrieval generates a CloudTrail KMS Decrypt event, providing a per-operation audit trail tied to the secret’s encryption key. Disabling the CMK immediately prevents any further secret retrieval from that secret without deleting the secret itself.

Multi-version secret storage: Secrets Manager maintains multiple versions of each secret simultaneously using staging labels. The label AWSCURRENT marks the version in active use. During rotation, the incoming version is labeled AWSPENDING until rotation completes, at which point it becomes AWSCURRENT and the previous version becomes AWSPREVIOUS. Applications can retrieve a specific version by label or version ID, which allows zero-downtime rotation without requiring coordinated application restarts.

Native database service integration: Secrets Manager has built-in support for natively rotating credentials for Amazon RDS (all supported database engines), Amazon DocumentDB, Amazon Redshift, and Amazon ElastiCache. For these services, you enable rotation from the Secrets Manager console, select a rotation schedule, and Secrets Manager handles the full rotation workflow without requiring you to write or deploy Lambda functions manually.

Cross-region secret replication: Secrets Manager supports replicating secrets to multiple AWS regions. When a secret is updated or rotated in the primary region, the update is propagated to replica regions automatically. Cross-region replication is useful for multi-region applications where services in each region need access to the same credential without making cross-region API calls, and for disaster recovery configurations where the secondary region must be able to authenticate to databases without dependency on the primary region.

VPC private endpoint: By default, Secrets Manager API calls travel over the public internet (over HTTPS). For workloads where all traffic must remain within the AWS network boundary (compliance requirements, network security policies, or latency requirements), you can configure a Secrets Manager VPC endpoint using AWS PrivateLink. The endpoint creates a private connection from your VPC to the Secrets Manager service endpoint, ensuring secret retrieval requests never traverse the public internet.

Deletion protection and recovery: Secrets Manager does not delete secrets immediately. When you delete a secret, it is scheduled for deletion after a minimum recovery window of 7 days (configurable up to 30 days). During this window you can restore the secret and all its versions. After the window expires, the secret and all its versions are permanently destroyed. To delete a secret immediately (bypassing the recovery window), use the AWS CLI with the --force-delete-without-recovery flag. This immediate deletion option is not available in the console.

Primary Use Cases for AWS Secrets Manager

Eliminating hard-coded database credentials: The most common use case. Application code retrieves database connection credentials from Secrets Manager at runtime using the GetSecretValue API rather than reading from environment variables, configuration files, or source code. The secret is cached in the application’s connection pool and refreshed when a rotation event occurs. This eliminates the risk of credentials being exposed in version control history, build logs, container image layers, or deployment artifacts.

Automated database credential rotation: For Amazon RDS databases, Secrets Manager can rotate the database user password on a schedule (for example, every 30 or 90 days) without any downtime. The rotation Lambda creates a new password in RDS, tests it, and then updates the secret in Secrets Manager. Applications using the Secrets Manager SDK with caching automatically pick up the new password without restart.

API key and OAuth token lifecycle management: Third-party API keys, OAuth client credentials, and service account tokens can be stored in Secrets Manager and rotated using custom Lambda functions. When the API provider supports programmatic credential rotation, the Lambda function calls the provider’s rotation API to generate a new key, tests it, and updates the Secrets Manager secret. This eliminates manual credential rotation processes that are error-prone and frequently missed.

Centralized secrets management for multi-account AWS environments: In AWS Organizations environments with multiple accounts (development, staging, production, shared services), Secrets Manager with cross-account resource policies and cross-region replication provides a centralized secrets governance model. Secrets are created and managed in a dedicated secrets account, accessed by applications in other accounts via cross-account IAM policies, and audited centrally through CloudTrail in the audit account.

On-premises and hybrid workload credential management: Applications running on-premises or in non-AWS environments can retrieve secrets from Secrets Manager via the public API endpoint or through a VPC-connected private endpoint. This allows hybrid cloud architectures to centralize secrets management in AWS even for workloads that have not been fully migrated to the cloud.

AWS Secrets Manager vs. SSM Parameter Store

AWS Systems Manager Parameter Store (SSM Parameter Store) is the other AWS native option for storing secrets and configuration. Both services can store encrypted values using KMS, but they serve different primary use cases.

Dimension	AWS Secrets Manager	SSM Parameter Store
Primary purpose	Secrets lifecycle management (rotate, audit, replicate)	Application configuration and parameter storage
Cost	$0.40/secret/month + $0.05/10k API calls	Free for standard parameters; $0.05/10k API calls for advanced encrypted parameters
Automatic rotation	Yes (native for RDS/DocumentDB/Redshift; custom Lambda for others)	No (must build externally)
Secret versioning	Yes (AWSCURRENT, AWSPENDING, AWSPREVIOUS labels)	Yes (version numbers)
Cross-account access	Yes (via resource policy)	Limited (more complex setup)
Cross-region replication	Yes (built-in)	No (must build externally)
VPC endpoint	Yes (AWS PrivateLink)	Yes (via SSM VPC endpoint)
KMS encryption	Always on (AWS-managed or CMK)	Optional (SecureString type uses KMS)
Max secret size	65 KB	4 KB (standard) / 8 KB (advanced)
Best for	Database credentials, API keys, tokens requiring rotation	App config, feature flags, non-rotated parameters

The decision rule is straightforward: if the secret needs automatic rotation or cross-account/cross-region access, use Secrets Manager. If it is a configuration parameter or a credential that does not rotate, SSM Parameter Store is sufficient and significantly cheaper.

AWS Secrets Manager Cost and Optimization

AWS Secrets Manager pricing has two components: a per-secret storage charge and a per-API-call charge. The current pricing is $0.40 per secret per month and $0.05 per 10,000 API calls. A 30-day free trial is available for new Secrets Manager users.

For a typical application retrieving a single database secret 1 million times per month (via cached retrieval at connection pool creation, not on every query), the monthly cost would be approximately $0.40 for the secret plus $0.05 for the API calls, totaling less than $1 per month. The cost scales linearly with the number of secrets and API call volume.

The primary cost optimization technique for Secrets Manager is client-side caching. The AWS Secrets Manager SDK includes a built-in caching client for Java, Python, .NET, Go, and JavaScript. The caching client retrieves the secret once, stores it in memory, and serves subsequent requests from the cache for a configurable TTL (default 1 hour). The cache is automatically refreshed when a rotation event occurs. Caching reduces API call volume by orders of magnitude for high-frequency applications.

If a customer-managed KMS key is configured for the secret, additional KMS API call costs apply: $0.03 per 10,000 KMS cryptographic operations. Every GetSecretValue call triggers a KMS Decrypt call. For high-volume applications, combining the Secrets Manager caching SDK with a CMK key configured for the secret is the standard approach to controlling both Secrets Manager and KMS costs simultaneously.

Multi-Cloud and Hybrid Secret Management Architecture

AWS Secrets Manager is an AWS-native service and does not natively manage secrets for Azure or GCP workloads. Organizations operating multi-cloud or hybrid environments need an explicit strategy for secrets management across cloud providers. Three patterns address this:

• Per-cloud native secrets manager: Use AWS Secrets Manager for AWS workloads, Azure Key Vault for Azure workloads, and GCP Secret Manager for GCP workloads. Each cloud’s applications use their native service. A centralized secrets governance platform aggregates audit logs and policy enforcement across all three providers, providing cross-cloud visibility without introducing cross-cloud latency for secret retrieval.
• Centralized secrets manager with per-cloud delivery: A third-party or self-hosted secrets manager (running outside all cloud providers, or in one authoritative cloud) stores the master copy of all secrets. Per-cloud agents or synchronization mechanisms push secrets to each cloud’s native service (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) as needed. The master copy is the source of truth for rotation, audit, and access policy.
• Direct cross-cloud API access: AWS workloads access only AWS Secrets Manager; Azure and GCP workloads access only their respective native services. Shared secrets (such as a third-party API key used by services across all three clouds) are stored in each cloud’s native secrets service independently, with rotation synchronized across all three when the credential changes. Encryption Consulting’s CBOM Secure helps discover and inventory all secrets and keys across multi-cloud environments to identify gaps in rotation coverage and access policy consistency.

Compliance: PCI DSS, HIPAA, FedRAMP, and GDPR

PCI DSS v4.0.1 (mandatory since March 31, 2025): Secrets Manager directly addresses several PCI DSS requirements. Requirement 8.6.2 prohibits hard-coding credentials in scripts, code, or configuration files; Secrets Manager’s API-based retrieval model satisfies this requirement by design. Requirement 8.3.9 requires periodic rotation of authentication credentials; automatic rotation on a schedule satisfies this requirement for database credentials and service accounts. Requirement 3.5.1 (protect stored account data using strong cryptography) is satisfied when a customer-managed KMS key with CloudHSM backing is used. CloudTrail data event logging of GetSecretValue calls satisfies Requirement 10 (audit logging of access to cardholder data environment).

HIPAA: AWS Secrets Manager is covered under AWS’s Business Associate Agreement (BAA). For ePHI-adjacent systems (applications that authenticate to databases or services that store ePHI), Secrets Manager prevents credential exposure in code (access control safeguard, 45 CFR 164.312(a)(1)). CloudTrail logging of GetSecretValue calls satisfies the Audit Control standard (45 CFR 164.312(b)) for access to credentials that unlock ePHI systems.

FedRAMP: AWS Secrets Manager is included in AWS’s FedRAMP High authorization package. For FedRAMP High workloads requiring FIPS 140-2 Level 3 key protection for the KMS key used to encrypt secrets, configure a customer-managed KMS key backed by a CloudHSM custom key store. This satisfies SC-12 (Cryptographic Key Management) and SC-28 (Protection of Information at Rest) at the High baseline. See our guide on AWS KMS security for the CloudHSM configuration detail.

GDPR: GDPR Article 32 requires appropriate technical measures for personal data protection. Using Secrets Manager to prevent hard-coded database credentials from appearing in source code, logs, and build artifacts is a technical measure that reduces the attack surface for unauthorized access to systems containing personal data. Automatic rotation reduces the window of exposure if a credential is compromised. CloudTrail logging provides the audit trail for demonstrating access controls to supervisory authorities.

How Encryption Consulting Can Help

Encryption Consulting is an applied cryptography and cloud security firm with ISO/IEC 27001:2022 and SOC 2 certifications. We help organizations design, implement, and audit AWS Secrets Manager deployments from initial architecture through ongoing compliance evidence generation.

• Secrets Manager Architecture and Migration: We assess your current credential management posture (identifying hard-coded credentials in code, configuration, environment variables, and CI/CD pipelines), design the target Secrets Manager architecture (secret hierarchy, KMS key configuration, resource policy model, rotation schedule per secret type), and implement the migration plan. See our cloud advisory services.
• Customer-Managed KMS Key Configuration for Secrets: We configure customer-managed KMS keys for Secrets Manager secrets, design the key policy separating key administrators from key users, enable CloudTrail Data Access logging for both Secrets Manager and KMS to provide the per-retrieval audit trail required by PCI DSS and HIPAA, and configure CloudWatch alerts for anomalous access patterns. For FIPS 140-2 Level 3 requirements, we configure CloudHSM-backed custom key stores. See our HSM as a Service.
• Automatic Rotation Implementation: We implement and test automatic rotation Lambda functions for supported AWS database services and for custom secret types (on-premises databases, third-party API keys, OAuth tokens). We configure rotation schedules aligned with your compliance requirements (PCI DSS 90-day rotation, HIPAA policy-defined rotation) and test rotation events to ensure zero-downtime operation in production environments.
• CBOM Secure for Secrets Discovery: AWS environments that have grown organically often have secrets scattered across environment variables, hard-coded in code, stored in SSM Parameter Store without encryption, or duplicated across multiple accounts. Encryption Consulting’s CBOM Secure discovers and inventories all secrets storage locations across your AWS accounts, identifies unencrypted or poorly-governed secrets, and generates a Cryptographic Bill of Materials (CBOM) in CycloneDX format supporting PCI DSS v4.0.1 Requirement 12.3.3 compliance documentation.
• PCI DSS and HIPAA Compliance Advisory: We map your Secrets Manager configuration to the specific requirements of PCI DSS v4.0.1, HIPAA, FedRAMP High, and GDPR. We identify control gaps, produce the compliance evidence package, and assist with QSA and auditor inquiries covering secrets management. See our Compliance Advisory Services.

To discuss your secrets management architecture or compliance requirements, contact Encryption Consulting.

Conclusion

AWS Secrets Manager addresses one of the most persistent and exploited vulnerabilities in cloud application security: credentials in code. By providing a central API-based secrets store with KMS encryption at rest, automatic rotation, IAM-controlled access, and CloudTrail audit logging, Secrets Manager removes the need for any credential to exist in plaintext outside of an HSM or an authenticated API response.

The configuration decisions that matter most are: using a customer-managed KMS key rather than the default AWS-managed key (for the per-operation audit trail and independent revocation capability), enabling CloudTrail data events for GetSecretValue (so you can prove who retrieved what and when), enabling automatic rotation on a compliance-aligned schedule, and using the SDK caching client to control API call costs at scale.

For organizations with existing AWS KMS deployments, Secrets Manager slots into the same key management and audit infrastructure without additional architectural complexity. For organizations starting from scratch, Secrets Manager combined with a customer-managed KMS key and CloudTrail data events is the fastest path to a defensible, auditable secrets management posture. For the encryption key management layer that underpins Secrets Manager, see our Deep Dive on AWS Key Management Service.

Frequently Asked Questions

What is AWS Secrets Manager?

AWS Secrets Manager is a managed service that stores, retrieves, rotates, and audits secrets such as database credentials, API keys, OAuth tokens, and SSH keys. Every secret is encrypted at rest using AWS KMS envelope encryption (AES-256-GCM). Secrets are never stored in plaintext. Applications retrieve secrets via API call instead of reading from environment variables or hard-coded code, eliminating credential exposure in source code and build artifacts.

How does AWS Secrets Manager encrypt secrets?

Secrets Manager uses AWS KMS envelope encryption. When a secret is stored, Secrets Manager calls KMS GenerateDataKey to get an AES-256 data key, encrypts the secret value with it (AES-256-GCM), and stores the encrypted secret and the encrypted data key together. The plaintext data key is discarded immediately. When retrieved, Secrets Manager calls KMS Decrypt to recover the data key, decrypts the secret, and returns the plaintext value over TLS. The default key is the AWS-managed aws/secretsmanager key; customer-managed KMS keys provide audit trail and independent revocation for compliance workloads.

How does AWS Secrets Manager rotate secrets automatically?

Rotation uses an AWS Lambda function that follows four steps: CreateSecret (generate a new version), SetSecret (update the credential in the target service), TestSecret (verify the new credential works), and FinishSecret (mark the new version AWSCURRENT). For Amazon RDS, DocumentDB, and Redshift, AWS provides managed rotation Lambda functions. For any other service, you deploy a custom Lambda implementing the same four steps. Rotation runs on a configurable schedule (minimum 1 day) or on demand.

What is the difference between AWS Secrets Manager and AWS Systems Manager Parameter Store?

Secrets Manager costs $0.40/secret/month and provides built-in automatic rotation, cross-account access, cross-region replication, and up to 65 KB secret size. SSM Parameter Store is free for standard parameters (up to 10,000) and is best for application configuration and non-rotated credentials. Choose Secrets Manager when you need automatic rotation or cross-account/cross-region access. Choose SSM Parameter Store for general configuration parameters and cost-sensitive workloads that do not require rotation.

Does AWS Secrets Manager meet PCI DSS and HIPAA requirements?

Yes, when configured correctly. Secrets Manager satisfies PCI DSS v4.0.1 Requirements 8.6.2 (no hard-coded credentials), 8.3.9 (periodic rotation), and 10 (audit logging via CloudTrail data events). A customer-managed KMS key with CloudHSM backing satisfies Requirement 3.5.1 and 3.7.1. For HIPAA, Secrets Manager is covered under AWS’s BAA and prevents credential exposure in code (access control safeguard, 45 CFR 164.312(a)(1)). CloudTrail logging satisfies the Audit Control standard (164.312(b)).

How do I access AWS Secrets Manager secrets from an application?

Call the GetSecretValue API with the secret name or ARN. The calling identity (IAM role or user) must have secretsmanager:GetSecretValue permission on that specific secret ARN, granted in both the IAM identity policy and the secret’s resource policy. Use the AWS Secrets Manager SDK caching client to cache the secret in memory and reduce API call frequency. For workloads that must not make internet-bound calls, configure a Secrets Manager VPC endpoint (AWS PrivateLink) to route secret retrieval traffic within your VPC.