Site icon IT & Life Hacks Blog｜Ideas for learning and practicing

Complete Guide to AWS Secrets Manager: Systematizing Password & API Key Management with Rotation and Auditing (Compared with GCP Secret Manager / Azure Key Vault)

greeden
AWS Secrets Manager

AWS Secrets Manager

Complete Guide to AWS Secrets Manager: Systematizing Password & API Key Management with Rotation and Auditing (Compared with GCP Secret Manager / Azure Key Vault)

Key Takeaways (for busy readers)

  • AWS Secrets Manager is a managed service that securely stores and retrieves “secrets” such as passwords and API keys, and can also operationalize periodic rotation when needed. :contentReference[oaicite:0]{index=0}
  • Rotation comes in two main styles: managed rotation (managed by Secrets Manager) and Lambda-based rotation (implemented with a Lambda function), depending on your target and requirements. :contentReference[oaicite:1]{index=1}
  • Versioning is operated via staging labels. By default there is AWSCURRENT, and rotation uses labels like AWSPENDING to switch over safely. :contentReference[oaicite:2]{index=2}
  • Pricing is mainly based on the number of stored secrets and API calls; secrets marked for deletion (pending deletion) are not billed—this is the basic framing. :contentReference[oaicite:3]{index=3}
  • On GCP, Secret Manager commonly sends rotation “notifications” to Pub/Sub, and the actual update is executed by workflows (Cloud Functions/Cloud Run, etc.). :contentReference[oaicite:4]{index=4}
  • On Azure, Key Vault encrypts and stores secrets, and updating a secret with the same name creates a new version. It also clearly defines safety nets such as soft-delete and recovery. :contentReference[oaicite:5]{index=5}

Who This Helps (concrete examples)

First, this is for product development teams. If API keys are embedded in environment variables or DB passwords are left in config files, you don’t just risk leakage—you accumulate operational debt like “we don’t know who changed it,” or “rotation is scary so we postpone it.” Secrets Manager reduces anxiety by shifting retrieval, access control, and rotation procedures into a repeatable system. :contentReference[oaicite:6]{index=6}

Next, it helps SREs and operators. During incident response, “recovery that involves secrets” often slows everything down because everyone becomes extra cautious. With versioning plus staging labels, Secrets Manager makes it easier to standardize cutover procedures and explain them in audits. :contentReference[oaicite:7]{index=7}

It’s also useful for architects thinking multi-cloud or future migration. While GCP Secret Manager and Azure Key Vault are conceptually similar, their default rotation “shape” differs: AWS tends toward managed/templates, GCP is notification-driven, and Azure often uses event-driven automation. Understanding those differences stabilizes your design. :contentReference[oaicite:8]{index=8}

1. What AWS Secrets Manager Is: Not “Storage” but “Operations”

AWS Secrets Manager is designed to manage secrets across their lifecycle—not just encrypt and store them, but also schedule automatic rotation when required, as described in official docs. :contentReference[oaicite:9]{index=9}

The important point is that the value is not the vault itself, but the operational system. If humans rotate credentials manually, the steps tend to fragment—(1) update password on the DB/service side, (2) update app config, (3) verify impact, (4) retire old credentials, (5) keep evidence—leading to mistakes. Secrets Manager provides a “single pattern” to consolidate this via versioning, labels, schedules, and rotation procedures. :contentReference[oaicite:10]{index=10}

2. The Core Mechanism: Versions + Staging Labels (Understanding AWSCURRENT)

Secrets Manager becomes easier once you think in terms of versions and staging labels. A secret can have multiple versions, and by default AWSCURRENT marks the version returned on normal retrieval. The docs explain that Secrets Manager returns AWSCURRENT by default, that labels can be moved between versions, and that the same label cannot be attached to two versions at the same time. :contentReference[oaicite:11]{index=11}

A common rotation label is AWSPENDING. During rotation, you create a new “pending” value, test it, and then move AWSCURRENT to the new version. AWS explicitly states that label-update APIs are used to track versions during rotation—once you internalize this, debugging failed rotations becomes far easier. :contentReference[oaicite:12]{index=12}

Rotation “story” (in words)

  • Current secret: Version A (AWSCURRENT)
  • Next candidate: create Version B (AWSPENDING)
  • Update DB/service side to the Version B credential and validate connectivity
  • If OK, move AWSCURRENT to Version B; keep Version A as an old version (cleanup later as needed)

If the team shares this story before writing code, decisions align faster even in emergencies. Being able to discuss states via labels (without relying on a UI) is also an accessibility win for operations. :contentReference[oaicite:13]{index=13}

3. Two Rotation Approaches: Managed vs. Lambda

Official docs describe two main rotation paths.

3-1. Managed rotation (service-managed)

For many “managed secrets,” AWS offers Managed rotation where the service configures and manages rotation without requiring you to operate a Lambda function. :contentReference[oaicite:14]{index=14}
This is attractive when you want low operational overhead and want to start rotating quickly.

3-2. Lambda rotation (templates or custom)

The other approach is Lambda-based rotation. AWS provides rotation function templates as “ready-to-use” implementations that encode best practices. :contentReference[oaicite:15]{index=15}
When templates are insufficient, AWS also provides guidance for building custom rotation functions. :contentReference[oaicite:16]{index=16}

The key design question is: where does the credential live, and how is it updated? A DB, an external SaaS, and an internal API all have different update procedures. Use templates where possible, and reserve custom logic for exceptions—this keeps maintenance stable. :contentReference[oaicite:17]{index=17}

4. Pricing Design: Predictable Growth via “Secrets” + “API Calls”

AWS explains that pricing is basically based on the number of stored secrets and API requests. :contentReference[oaicite:18]{index=18}
Docs also state that secrets marked for deletion are not billed. :contentReference[oaicite:19]{index=19}

In practice, two things matter most:

  • How you split secrets: too granular increases fixed cost; too bundled harms permission boundaries and rotation flexibility.
  • How often you fetch: fetching on every request vs. fetching at startup and caching changes API call counts (balance requirements and safety).

This “predictable scaling” is valuable for teams that must explain security measures together with cost. :contentReference[oaicite:20]{index=20}

5. Common Operational Patterns: Start Small, Define Rules Early

The safest rollout is not “migrate everything at once,” but to build a repeatable pattern starting with the highest-risk items.

Pattern A: DB credentials (where rotation really shines)

  • Target: application DB user credential
  • Policy: schedule rotation, document and template cutover steps
  • Benefit: fewer disputes and delays when people/vendors change

Docs emphasize that rotation involves updating both the secret and the DB/service credential—share this early so everyone understands the dependency. :contentReference[oaicite:21]{index=21}

Pattern B: External API keys (rotation becomes “notification + procedure”)

Some SaaS API keys can’t be rotated automatically via API. In that case, you can still use Secrets Manager for version creation and label-based cutover while running the actual change as a controlled procedure. Labels help even for “semi-automated” operations. :contentReference[oaicite:22]{index=22}

Pattern C: Emergency response (suspected leakage)

When leakage is suspected, speed and correctness conflict. Define in advance: “in emergencies we switch labels in this order,” and “we validate impact using this checklist.” The label-based structure makes emergency runbooks easier to explain and execute. :contentReference[oaicite:23]{index=23}

6. Compared with GCP Secret Manager: Rotation Is Usually “Notification-Driven”

GCP Secret Manager supports rotation operationally. While overviews talk about meeting rotation requirements, the rotation scheduling docs explicitly describe sending rotation notifications to a Pub/Sub topic based on your chosen time/frequency. :contentReference[oaicite:24]{index=24}

In other words, the standard pattern is:

  • Secret Manager sends a “time to rotate” notification, :contentReference[oaicite:25]{index=25}
  • Functions/Run/Workflows perform the actual update,
  • Then you add a new secret version.

Pricing is also structured around “active secret versions,” “operations (access requests),” and “rotation notifications,” which tends to translate cleanly into estimates. :contentReference[oaicite:26]{index=26}

So in GCP-heavy environments, maturity often depends on how well you standardize the Pub/Sub-triggered rotation workflow.

7. Compared with Azure Key Vault: Versioning + Recovery Often Becomes the Core

Azure Key Vault is described as a service for securely storing secrets (tokens, passwords, certificates, API keys, etc.) with strict access control. :contentReference[oaicite:27]{index=27}
It also clarifies that Key Vault doesn’t interpret the secret’s meaning; it encrypts and stores whatever you provide and retrieves it by identifier. :contentReference[oaicite:28]{index=28}

Operationally important: updating a secret with the same name creates a new version, as described in the REST API docs. :contentReference[oaicite:29]{index=29}
As a safety net, Key Vault provides soft-delete where deleted objects remain in a recoverable deleted state until restored or purged, clearly defined in official docs. :contentReference[oaicite:30]{index=30}

For automatic rotation, Azure often leans on building automation with surrounding services (e.g., event-driven approaches around Key Vault events). :contentReference[oaicite:31]{index=31}
So a practical Azure design is: “standardize versioning + recovery,” and “proceduralize rotation via events and functions” per organizational needs.

8. A Stable Multi-Cloud Comparison Framework: 7 Criteria

To choose among AWS Secrets Manager, GCP Secret Manager, and Azure Key Vault, it’s often more stable to compare these seven criteria than to compare feature names:

  1. Versioning model (AWS staging labels; Azure new version on same-name updates; etc.) :contentReference[oaicite:32]{index=32}
  2. Default rotation pattern (AWS managed/Lambda; GCP notify→execute; Azure often event-driven) :contentReference[oaicite:33]{index=33}
  3. Deletion & recovery safety nets (e.g., Azure soft-delete/recovery) :contentReference[oaicite:34]{index=34}
  4. Auditability (who accessed what, when)
  5. Pricing units (AWS secrets + API; GCP active versions + operations + notifications; Azure transactions, etc.) :contentReference[oaicite:35]{index=35}
  6. App integration style (startup fetch, short-term caching, reacting to update signals)
  7. Org operating culture (runbook-driven vs. fully automated; required audit granularity)

Once these are decided, your “design core” stays consistent across clouds, improving operational quality.

Summary: Secrets Manager Helps You Build a Team That Can “Rotate Secrets”

AWS Secrets Manager securely manages secrets and can include scheduled automated rotation. Rotation supports both managed rotation and Lambda-based rotation, with templates and guides that make standardization easier. :contentReference[oaicite:36]{index=36}
Because cutover behavior is defined via versions and staging labels (AWSCURRENT, etc.), teams can align decisions and build reliable runbooks—even under pressure. :contentReference[oaicite:37]{index=37}
Pricing is also easy to explain, centered on stored secret count and API calls, with the rule that pending-deletion secrets aren’t billed. :contentReference[oaicite:38]{index=38}

GCP’s rotation model is explicitly Pub/Sub-notification-driven, making workflow design the key. :contentReference[oaicite:39]{index=39}
Azure’s Key Vault is strong on versioning plus soft-delete/recovery, and rotation automation is commonly implemented via event-driven orchestration. :contentReference[oaicite:40]{index=40}

A solid first step is simply: move production DB credentials into Secrets Manager and document the rotation pattern (when, who, how to verify, how to cut over) both in text and configuration. Start small, but define rules carefully from the beginning—then “secrets” shift from something scary into something you can reliably operate.

Reference Links (mostly official)

Exit mobile version