Skip to main content
In this lesson we cover best practices and the AWS services available for secrets management, with an emphasis on SDLC automation in DevOps. Proper secrets management prevents hardcoding sensitive data (passwords, API keys, certificates) in source code, configuration files, or build artifacts. Choosing the right AWS tool depends on access patterns, rotation needs, cost, and integration complexity. The two primary AWS options are AWS Secrets Manager and AWS Systems Manager Parameter Store. Below is a clear comparison of their purpose, features, and recommended use cases.

​
Secrets Manager vs Parameter Store

  • AWS Secrets Manager
    • Purpose-built for storing, managing, and retrieving secrets.
    • Supports built-in automatic rotation for many credential types (for example, RDS).
    • Integrates well with AWS services and CI/CD pipelines.
    • Additional features: secret staging labels, larger max secret size, and lifecycle controls.
    • Cost: typically higher per-secret and per-API-call charges (trade-off for rotation/lifecycle).
    • Recommended when you need automatic rotation, central secret lifecycle management, or advanced secret features.
  • AWS Systems Manager Parameter Store
    • General-purpose key–value store for configuration and secrets.
    • Supports encrypted values (SecureString) using KMS.
    • No built-in automatic rotation (you implement custom rotation via Lambda/EventBridge).
    • Often more cost-effective for simple configuration values or non-rotated secrets.
    • Recommended for storing configuration settings, feature flags, and smaller numbers of secrets where rotation is not required.
A slide titled "AWS Services for Secrets Management" featuring the AWS Secrets Manager icon. It lists that Secrets Manager helps securely store, manage, and retrieve secrets and provides automatic secret rotation for databases and other services.
If your design requires automatic rotation, Secrets Manager is the clear choice. If you only need encrypted key–value configuration without rotation, Parameter Store is typically sufficient.
A presentation slide titled "AWS Services for Secrets Management" highlighting the Parameter Store. It notes that Parameter Store saves configuration data and secrets as key–value pairs and supports encrypted storage using AWS Key Management Service.
Both services can encrypt values with KMS. The defining difference is rotation: Secrets Manager supports built-in managed rotation, while Parameter Store does not (you must implement rotation yourself when needed).

​
Quick Feature Comparison

​
Secrets in CI/CD Pipelines

Inject secrets at build or deploy time (runtime injection) rather than committing them to source control. Both Secrets Manager and Parameter Store can be used by AWS CodePipeline, CodeBuild, CodeDeploy, and other CI/CD tools to supply secrets during build or deployment steps. Typical pipeline flow:
  • Developer pushes code to GitHub
  • CodePipeline triggers a pipeline
  • CodeBuild retrieves secrets to build or run tests
  • CodeDeploy deploys artifacts to EC2, ECS, or Lambda
This pattern prevents credentials from ever being hard-coded in repositories or baked into build artifacts.
A diagram titled "Using Secrets in CI/CD Pipelines" showing a developer pushing code to GitHub which triggers an AWS CodePipeline (GitHub → CodeBuild → CodeDeploy) that deploys to an EC2 instance. AWS Secrets Manager is depicted below, providing secrets to the build and deploy steps.
Parameter Store is appropriate in pipelines when you only need configuration or non-rotated secrets. Use Secrets Manager when you need rotation, centralized lifecycle, or secret staging. Example AWS CLI commands (use these in build or deploy steps):
  • Retrieve a Secrets Manager secret:
  • Retrieve a Parameter Store SecureString:

​
Secret Rotation

Automatic rotation reduces exposure from leaked credentials by replacing them on a schedule. Secrets Manager provides:
  • Managed rotation for supported targets (AWS handles rotation logic).
  • Custom rotation using Lambda functions for unsupported or advanced scenarios.
Parameter Store requires you to implement rotation workflows—for example, an EventBridge schedule triggering a Lambda that updates the secret and the dependent service credentials.
A slide titled "Rotating Secrets in AWS Secrets Manager" that compares two options: "Managed Rotation" (with a cloud icon) and "Rotation by Lambda Function" (with the AWS Lambda logo). Each option has brief bullet points describing how rotation is handled (AWS-managed vs. Lambda-managed).
Managed rotation reduces maintenance overhead. Use Lambda rotation when you need custom logic to update third‑party systems or to coordinate multi-step rotations.

​
Encryption, Auditing, and Access Control

  • Use KMS for encryption; prefer customer-managed keys when you need granular control over key policies, access, and rotation.
  • Use CloudTrail to audit API activity for both Secrets Manager and Parameter Store.
  • Apply least-privilege IAM policies and resource-level constraints so services only access the secrets they require.
  • Combine IAM policies with KMS key policies to tightly control who or what can decrypt secrets.
A slide with a comparison table titled "Parameter Store vs Secrets Manager" comparing AWS Secrets Manager and Parameter Store across features like automatic rotation, cost, max secret size, CloudTrail audit, KMS encryption, and fine‑grained IAM access. The table highlights differences such as automatic rotation and higher cost for Secrets Manager versus manual rotation and lower cost for Parameter Store.
AWS pricing and limits change over time. Secrets Manager historically has a per-secret monthly charge and per-API-call costs; Parameter Store provides free standard parameters but charges for advanced parameters. Always consult the latest AWS documentation and pricing pages before making cost-sensitive decisions.

​
Pricing Considerations

Secrets Manager typically has a higher per-secret cost plus API request charges; this is the trade-off for built-in rotation and lifecycle features. Parameter Store is often more cost-effective for simple configuration scenarios (standard parameters are free; advanced parameters incur charges). Focus on architectural trade-offs—rotation, integration, auditability, and operational overhead—before optimizing for cost.
A presentation slide titled "Pricing Considerations" showing the AWS Secrets Manager icon. Three numbered points list pricing: 0.40 per secret per month, 0.05 per 10,000 API calls, and that it includes automated rotation.
A slide titled "Pricing Considerations" showing a "Parameter Store" icon on the left. On the right are three numbered blocks listing pricing notes — "01: Free for standard parameters," "02: Charged for advanced parameters," and a third item shown but faint.

​
Security and IAM

Grant least-privilege IAM roles to services (for example, give CodeBuild permissions only to the secrets it needs). An example minimal IAM policy to allow CodeBuild read access to a Secrets Manager secret:
Additionally:
  • Use resource-level IAM policies, avoid wide * permissions.
  • Add KMS key policies to limit decrypt access to only the necessary roles/services.
  • Monitor access via CloudTrail and set up alerts or anomaly detection for unusual access patterns.
A diagram titled "Security and Access Control" showing AWS IAM granting permissions and a role to AWS CodeBuild, which sends requests to and returns secrets from AWS Secrets Manager.

​
Best Practices

  • Never hard-code secrets in source code, configuration checked into repositories, or build scripts.
  • Use IAM roles and least privilege for services (attach narrowly scoped roles to CodeBuild, ECS tasks, etc.).
  • Prefer Secrets Manager automatic rotation where appropriate to reduce credential exposure.
  • Inject secrets at runtime (environment variables or secure secret mounts) rather than baking them into artifacts.
  • Encrypt secrets with KMS; use customer-managed keys for fine-grained control.
  • Regularly audit access with CloudTrail and consider anomaly detection for access patterns.
  • Keep secret lifetimes short when feasible and rotate credentials on compromise or schedule.
A slide titled "Secrets Management – Best Practices" showing five illustrated recommendations: never hardcode secrets, use IAM roles with least privilege, enable automatic rotation, regularly audit access logs, and use environment variables securely in Lambda/ECS/EC2. Each recommendation is shown inside a rounded box with an icon.
Over-securing is rarely harmful—prioritize safe, maintainable patterns that minimize operational overhead while ensuring applications can securely access secrets.

​
Key Takeaways

  • Use AWS Secrets Manager when you need built-in rotation, secret lifecycle features, and advanced secret management.
  • Use Systems Manager Parameter Store for simple, cost-effective configuration and secrets (SecureString) when rotation is not required or is implemented externally.
  • Always enforce least-privilege IAM, KMS encryption, and CloudTrail auditing for any secrets you manage.
Further reading and references: This lesson included a demo illustrating an integrated pipeline and practical patterns for secrets management in CI/CD environments. Use the guidance above to choose the right AWS service and to design secure, maintainable secret workflows.

Watch Video