We close the security chapter with a very practical problem we've been postponing: where do you store your application's secrets? Database passwords, API keys, tokens... they can't be written in the code or in versioned .tfvars files (as we warned in subchapter 19.4). AWS offers two services to store them securely: Secrets Manager and Parameter Store. Let's see what they are and when to use each one.

Every application needs secrets: sensitive data that gives it access to other systems. For example, the password to connect to its database. The beginner's mistake is to put them directly in the code or configuration:

Remember what we saw in subchapter 19.4: never write secrets in versioned files. The solution is to store them in a secret manager and have the application read them at the moment it needs them.

A secret manager stores sensitive data encrypted and with controlled access. The application, when it starts or when it needs to, requests the secret from the manager (proving it has permission) and receives it. The secret is never written in the code.

Secrets are encrypted with KMS (subchapter 23.5) and access is controlled with IAM (Chapter 7), applying the least privilege principle: only the application that needs a secret has permission to read it.

AWS offers two services for this, and it's important to know the difference:

Secrets Manager is specifically designed for secrets (passwords, API keys, credentials). Its standout feature is automatic rotation: it can automatically change passwords periodically, integrating with databases like RDS to update the password both in the secret and in the database, without interruptions.

Parameter Store (part of AWS Systems Manager) is a more general service for storing configuration parameters, which can also store secrets (as "secure strings" encrypted with KMS). It's more simple and its basic use is free, but it does not offer the automatic rotation of Secrets Manager.

Analogy: Parameter Store is like a general safe where you keep important documents and also some jewelry; it works, it's cheap and versatile. Secrets Manager is like a specialized safe for extremely valuable jewels, with an extra service that periodically changes the combination for you (rotation). It costs more, but for your most critical secrets, that rotation service is worth it.

The decision mainly depends on whether you need automatic rotation and the cost:

• Use Secrets Manager when: you need automatic rotation of credentials (especially database passwords), or you want its native integration with RDS. It's the most robust option for critical secrets.
• Use Parameter Store when: you want a simple and free option to store configuration and secrets that don't need automatic rotation, or you're just starting out and want to minimize costs.

To start: Parameter Store (free tier) is perfect for securely storing your first configurations and secrets. When you handle critical credentials that must be rotated (like in production with sensitive databases), move up to Secrets Manager.

The usual pattern connects everything we've learned:

For example, Terraform can read an existing secret with a data block (remember the data sources from subchapter 14.2) instead of having it written. And an application in a Lambda or a container requests the secret at startup. ⚠️ Remember (from subchapter 11.2) that if Terraform reads a secret, it may end up in the state, so the state must be encrypted and protected.

Real world example: an application needs to connect to its production database. The password is stored in Secrets Manager with monthly automatic rotation. The application, at startup, requests the password from Secrets Manager (it has IAM permission for that specific secret, and for no other). When Secrets Manager rotates the password, it updates both the secret and the database, and the application simply requests the new one again: all without any human ever seeing or writing the password. If an attacker got the application's code, they would not find any password in it.

• Secrets (passwords, API keys, tokens) should never go in the code or in versioned files; they are stored in a secret manager and the application reads them at the moment, with permissions.
• Secrets are encrypted with KMS (subchapter 23.5) and access is controlled with IAM (least privilege).
• Secrets Manager: designed for secrets, with automatic credential rotation (its big advantage) and native database integration; paid.
• Parameter Store: general service for configuration and secrets (as encrypted strings), simple and with a free tier, but without automatic rotation.
• Choose Secrets Manager if you need automatic rotation (critical credentials, production DB); Parameter Store for simple and free use. To start, Parameter Store is enough.
• Pattern: the secret lives in the manager (encrypted), the app/Terraform reads it with IAM, and it never appears in the code. ⚠️ If Terraform reads it, protect the state (which may contain it).

You've finished Chapter 23! You now master defense-in-depth security in AWS: organizational boundaries, compliance, threats, centralized vision, encryption, and secrets. In Chapter 24 we'll see the other essential side of operating in production: observability (logs, metrics, and traces).