When an application runs on your laptop, you can just drop the database password into a file next to the code. In the cloud you can't: colleagues see the code, files end up in version control, there are many servers and they come and go on their own. That's why AWS has dedicated services for two tasks that used to be handled "somehow": where to store secrets safely and how to understand what is actually going on inside your servers.

This article is about four such services. Secrets Manager and SSM Parameter Store store passwords and settings. KMS handles encryption. CloudWatch collects logs and metrics and sends alerts when something goes wrong. Alongside them we'll also cover CloudTrail — a companion audit tool that records who did what in the account. We'll go through each one in turn, in plain language and with example commands you can try yourself.

Secrets Manager: a safe for passwords

A secret is any sensitive string: a database password, a key to a third-party API, a token. Secrets Manager is a managed store for such strings. You put a secret in once, and the application requests it by name at startup.

The main thing you get in exchange for a couple of lines in a file:

  • Encryption — the secret is stored encrypted; it never exists in plaintext anywhere on disk.
  • Versions — when you change a password, the old value isn't lost, so you can roll back.
  • Audit — every read of the secret is recorded, so you can see who accessed it and when.
  • Automatic rotation — Secrets Manager can change a database password on a schedule by itself.

Storing a secret and reading it are two commands:

aws secretsmanager create-secret --name prod/db/password --secret-string "s3cr3t-value"
aws secretsmanager get-secret-value --secret-id prod/db/password --query SecretString --output text

Rotation is more interesting than it looks. When you enable it for an RDS database, AWS sets up a small function (Lambda) that runs on a schedule through four steps: it creates a new password, writes it into the database, verifies login with the new password, and only then makes it the current one. During the change, both passwords — old and new — work for some time, so the application doesn't fall over: even if it still holds the old value, it has time to reread the new one. This is what changing a password with no downtime means.

Who is allowed to read the secret? Not a person, but a service role — IAM roles are covered in detail in the article on AWS fundamentals. As a result, the password is nowhere in the code, in version control, or in the build variables — only in Secrets Manager. That closes off a whole class of leaks: there's nothing to steal, because the secret simply isn't in the repository.

SSM Parameter Store: settings and cheap secrets

SSM Parameter Store (part of the AWS Systems Manager service) is a store for application settings: addresses of other services, feature flags, bucket names. Parameters come in two types: a plain string (String) and an encrypted one (SecureString). A SecureString is encrypted with KMS — that is, Parameter Store can store secrets too.

aws ssm put-parameter --name /prod/app/feature-x --type String --value enabled
aws ssm put-parameter --name /prod/db/password --type SecureString --value "s3cr3t-value"
aws ssm get-parameter --name /prod/db/password --with-decryption --query Parameter.Value --output text

Why have two services then? The difference is simple and mostly about money and convenience. The standard tier of Parameter Store is free — you pay nothing for storage or for requests. Secrets Manager costs about $0.40 per secret per month plus pennies per request, but gives you what Parameter Store doesn't: automatic rotation of passwords and a ready-made integration with databases.

A practical beginner's rule:

  • you need automatic database password changes — Secrets Manager;
  • just settings or a rare secret without rotation, and you'd rather not pay — SSM Parameter Store with the SecureString type.

And one more analogy for the line between a secret and a setting: if you'd be embarrassed to see the value in a log — it's a secret, so encrypt it. If you wouldn't (a service address, a flag) — it's a plain parameter.

KMS: where encryption keys live

Any encryption rests on a key. If the key sits next to the encrypted data, the encryption isn't worth much. KMS (Key Management Service) solves this problem: keys are stored inside protected AWS hardware and never leave it. You don't get the key itself — you ask KMS to encrypt or decrypt something with that key.

For a beginner, KMS most often looks like "a checkbox you mustn't forget." When you create a disk, an S3 bucket, an RDS database, or a queue, there's an "encrypt at rest" option — and it uses exactly KMS. The modern approach is simple: encrypt everything.

There are two kinds of keys:

  • AWS managed — AWS creates and maintains the key for you. Suitable for most data.
  • Customer managed — you create the key yourself, can revoke it, and see every use in the audit trail. Used for especially sensitive data.

Sometimes KMS shows up right in the code — a technique called envelope encryption. The data is encrypted with an ordinary data key, and that key itself is encrypted with a master key in KMS. An analogy: you put a letter into an envelope with a lock (the data key), and lock the envelope's key inside a bank vault (KMS). This is rarely needed, and when it is, you use a ready-made library (the AWS Encryption SDK) rather than writing the cryptography yourself: homemade encryption almost always contains bugs.

CloudTrail: who did what in the account

CloudTrail records every action in an AWS account: who, what, when, and from where. It's not a tool only for security people — it's your way to figure things out when something breaks. "Who deleted the queue?", "when was the database setting changed?", "which role read the secret?" — the answer is found in minutes. CloudTrail is on by default; all you need is to know it's there and look into it when investigating incidents.

CloudWatch: logs, metrics, and alerts

CloudWatch is the native AWS observation system. It has three parts that are easy to mix up:

  • Logs — text logs from applications and services.
  • Metrics — numbers over time: database CPU load, queue length, request count.
  • Alarms — rules of the form "if a metric crosses a threshold, send an alert."

A big plus for a beginner: metrics from managed services appear in CloudWatch on their own, with no setup. Create an RDS database and its CPU load and connection count are already visible. From there, you can attach an alarm to any metric:

aws cloudwatch put-metric-alarm \
  --alarm-name rds-cpu-high \
  --namespace AWS/RDS \
  --metric-name CPUUtilization \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2

Application logs can be sent to CloudWatch and searched. A useful tip for the start: write logs in a structured way (in JSON format, not as one continuous block of text) — then they're easy to filter and to build metrics from. The minimum useful fields are a level (error/info), a message, and a request identifier that lets you tie together the lines of a single request.

One important detail about the bill: in CloudWatch you pay for the volume of logs and for your own metrics. If you log every little thing or create a metric for every unique parameter, the bill grows fast. Keep the log volume under control, and the costs stay predictable.

Many teams use CloudWatch together with their own observation tools (for example, Grafana): they keep application metrics and request traces on their side, and pull managed-service metrics from CloudWatch into a shared dashboard. That gives one screen for everything with two data sources — a common mature setup.

Where this is used

These four services show up in any cloud project as soon as it goes beyond "I ran it on my laptop." Secrets Manager and SSM hide passwords when working with databases from the article on managed data and DynamoDB; KMS encryption is turned on for S3 and object storage; CloudWatch goes next to scaling and availability and serverless functions so you can see the load. When you describe infrastructure as code — with Terraform, CloudFormation, or CDK — secrets, keys, and alarms are defined there too, and the build pipelines from the section on CI/CD read secrets from these stores rather than from their own variables.

Typical beginner mistakes:

  • A secret in the code or in version control. The most common leak. A password always lives in Secrets Manager or SSM; only the secret's name goes into the repository.
  • A role with overly broad permissions. A service role should read only its own secrets and its own buckets — that's the principle of least privilege; for roles see AWS fundamentals and IAM.
  • Encryption left off. The extra checkbox seems unnecessary right up until the first audit. Turn encryption on the moment you create a resource.
  • No alarms, so you learn about the problem from users. Even a couple of alarms on database load and application errors save a lot of nerves.
  • Logs pouring out as plain text, and an unexpectedly large CloudWatch bill. Structure your logs and don't write extra.

What to learn next: get to grips with IAM and networking — access to secrets and encryption rests on them; see how to wire these services into an application in the article on integrating an application with AWS; then resilience and disaster recovery and cost optimization, where logs and metrics help you find wasteful spending. A consolidated view of all of this is given by the Well-Architected Framework.