AWS Security

When I first got into the security side of AWS, the hard part wasn’t the concepts. It was the sheer number of services. KMS, Secrets Manager, WAF, Shield, GuardDuty, Inspector, Macie… The names blur together, the docs all say some version of “improves your security posture,” and you end up with a fuzzy idea of what each one actually does.

Once you sit down with it, though, the list gets shorter. All of these services answer four questions:

• How do I protect the data?
• Where do I keep secrets?
• What do I put in front of the application?
• How do I find out when something goes wrong?

This post is my notes on those four, cleaned up.

Encryption: who does the encrypting?

The first thing to get straight is where the data gets encrypted.

Data at rest — data is encrypted while it sits in S3, EBS, or RDS.

Data in transit — data is encrypted while it moves from one place to another.

Browser
   │
   │ HTTPS / TLS 🔐
   ▼
  ALB
   │
   ▼
Application

The HTTPS/TLS between the browser and the ALB is the in-transit part. The object sitting in the bucket is at rest. Two different problems, two different solutions. Don’t mix them up.

S3 encryption options

There are three options you’ll run into on the S3 side, plus client-side encryption, which sits outside all of them.

SSE-S3

Server-Side Encryption with S3-managed keys. S3 does the encrypting and AWS manages the keys.

Object
   ↓
  S3
   ↓
SSE-S3
   ↓
Encrypted Object

You don’t have to manage your own KMS key. This is the option that asks the least of you.

SSE-KMS

Server-Side Encryption with AWS KMS keys. The data is still encrypted server-side, but key management moves over to KMS.

Object
   ↓
  S3
   ↓
 KMS
   ↓
Encrypted Object

What you’re really buying here is control. You can write a key policy, decide through IAM who gets to do what, set up key rotation, and manage cross-account access.

If a question puts “S3” and “KMS” next to each other, the answer is almost certainly SSE-KMS.

SSE-C

Server-Side Encryption with Customer-Provided Keys. This time you supply the key.

Customer
   │
   │ Encryption Key
   ▼
  S3
   │
   ▼
Encrypted Object

AWS doesn’t store the key, so you send it with every request. Naturally, the management overhead is noticeably higher than the other two.

Client-Side Encryption

The difference here matters: you encrypt the data before it ever reaches S3.

Application
    │
    │ Encrypt 🔐
    ▼
Encrypted Data
    │
    ▼
    S3

What S3 sees is already-encrypted data. So roughly:

• SSE → encryption happens on the AWS side
• Client-side → encryption happens before you send

KMS

Once S3 encryption clicks, KMS gets a lot easier. KMS (Key Management Service) exists to manage encryption keys.

One thing worth underlining: KMS is not a password manager. Its job is key management, and that’s it.

Data
  │
  ▼
KMS Key
  │
  ▼
Encrypted Data

Every KMS key also has a key policy. That’s where you control which users or services can use the key and for what.

KMS Key
   │
   └── Key Policy
         │
         ├── User A → Encrypt
         ├── User B → Decrypt
         └── User C → No access

“How do you restrict a user’s access to a KMS key?” almost always comes back to the key policy.

Key rotation and secret rotation are not the same thing

This one tripped me up early on.

KMS does key rotation, meaning it rotates the key material used for encryption. But rotating an RDS database password like this

ABC123
   ↓
XYZ789

is not KMS’s job. That’s where Secrets Manager comes in.

Secrets Manager

Used for storing database passwords, API keys, and similar secrets safely. It shows up alongside RDS constantly.

Application
     │
     │ Get Secret
     ▼
Secrets Manager
     │
     ▼
RDS Password

Its headline feature is automatic rotation. It changes the password on a schedule for you:

ABC123
  ↓
Secrets Manager
  ↓
XYZ789
  ↓
QWE456

If you see “RDS password” and “automatic rotation” in the same question, you don’t need to think about it much.

SSM Parameter Store

Parameter Store solves a slightly different problem. Think about your application’s configuration values:

/db/host
/db/port
/app/environment
/app/api-url

Instead of hardcoding these, you keep them in Parameter Store and read them at runtime. You also get version history on the values:

Version 1 → old-db.com
Version 2 → new-db.com

Lined up side by side, the split is clear:

Get Farukbiberoglu’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

NeedServiceEncryption keyKMSDatabase password / secretSecrets ManagerConfiguration / parameterSSM Parameter Store

ACM

If you’re doing HTTPS, you need a certificate somewhere. That’s exactly what AWS Certificate Manager is for.

User
 │
 │ HTTPS
 ▼
ALB
 │
 └── ACM Certificate

It handles issuing and renewing TLS/SSL certificates. In ALB + HTTPS scenarios it’s basically the default answer.

CloudHSM

KMS and CloudHSM sound similar, but they aren’t the same thing.

• KMS → managed key management service
• CloudHSM → dedicated hardware security module

With CloudHSM, control over the keys and the HSM users stays entirely with the customer. Phrases like “dedicated HSM” or “hardware-based key management” are pointing at this service.

WAF

Leaving encryption behind, let’s move to application security.

AWS WAF inspects and filters the HTTP/HTTPS requests coming into your web application.

Internet
   │
   ▼
  WAF
   │
   ├── SQL Injection ❌
   ├── XSS ❌
   └── Malicious Request ❌
   │
   ▼
  ALB

SQL injection, XSS, request filtering — all WAF territory. Remembering that it operates at Layer 7 makes this easier to recall.

Shield

WAF and Shield are another pair people mix up. Shield’s job is DDoS protection.

Attacker
 ↓ ↓ ↓ ↓ ↓
DDoS Traffic
      ↓
    Shield
      ↓
Application

Put simply: WAF handles web attacks, Shield handles volumetric ones. Shield Standard gives you baseline protection; Shield Advanced adds deeper protection and extra features.

GuardDuty

GuardDuty is less about blocking an attack and more about noticing what’s going on. If an EC2 instance suddenly starts doing network activity it has never done before, GuardDuty catches it and produces a finding.

AWS Environment
      │
      ▼
  GuardDuty
      │
      ▼
Suspicious Activity
      │
      ▼
   Finding

Threat detection points here.

Inspector

Inspector answers a completely different question: what vulnerabilities exist in my systems?

You might have an outdated package or a known CVE on an EC2 instance.

EC2
 │
 └── Old Package
       │
       ▼
   Vulnerability
       │
       ▼
    Inspector

It finds those and gives you remediation guidance.

The easiest way to separate the two is to ask the question each one asks:

• GuardDuty → is something suspicious happening?
• Inspector → is there a hole in the system?

Macie

Macie focuses on sensitive data inside S3. Your bucket might be holding PII, personal details, or sensitive customer records, and Macie helps you discover it.

S3
 │
 ├── Customer data
 ├── PII
 └── Sensitive data
          │
          ▼
        Macie

Wherever you see “sensitive data in S3,” the answer is Macie.

Summary

Rather than memorizing the services one by one, it sticks better to remember which question each one answers:

• Encrypt data → SSE-S3 / SSE-KMS / SSE-C / client-side
• Manage keys → KMS (CloudHSM if you need dedicated hardware)
• Store and rotate secrets → Secrets Manager
• Hold config → Parameter Store
• Certificates → ACM
• Web attacks → WAF
• DDoS → Shield
• Suspicious activity → GuardDuty
• Vulnerabilities → Inspector
• Sensitive data in S3 → Macie