Security services · Prasanta Kumar Behera

The AWS security services a platform engineer uses weekly: KMS keys and envelope encryption, secrets in Secrets Manager or Parameter Store, CloudTrail for audit, GuardDuty for threat detection, and Config and Security Hub for posture.

The security toolkit

Service	Answers
KMS	Who can use which encryption key?
Secrets Manager / Parameter Store	Where do credentials and config live, and who can read them?
CloudTrail	Who did what, when, from where?
GuardDuty	Is something malicious happening?
AWS Config	Is every resource configured the way it should be, and how did it change?
Security Hub	One place for findings and compliance scores across accounts

Securing a building: KMS is the key cabinet (only certain people may use certain keys, and every use is written down). Secrets Manager is the safe for passwords. CloudTrail is the CCTV recording of everything anyone did. GuardDuty is the alarm system that spots burglars. Config is the inspector checking every door is still locked the way it should be.

KMS: keys under control

AWS managed keys (e.g. aws/s3) are convenient; customer managed keys give you key policies, rotation settings and separate audit.
Key policies decide who may administer and who may use a key. Encrypting data with a customer managed key means access requires both permission on the data and permission on the key: a second lock.
Envelope encryption: services generate a data key, encrypt data locally with it, and store the data key encrypted by your KMS key. The KMS key never leaves KMS.
Enable automatic rotation for customer managed keys where appropriate.

EKS uses exactly this for encrypting Kubernetes Secrets (see Kubernetes Security, lesson 11).

Secrets Manager vs Parameter Store

	Secrets Manager	SSM Parameter Store
Built for	Secrets, with rotation	Config values and secrets (`SecureString`)
Rotation	Built-in, via Lambda functions (native for some databases)	Do it yourself
Cost	Per secret per month + API calls	Standard parameters: no extra charge
Cross-account sharing	Resource policies	Limited

A common pattern: Secrets Manager for credentials that rotate, Parameter Store for configuration. In Kubernetes, pull both into pods with the External Secrets Operator, using Pod Identity (no static keys).

CloudTrail: the audit trail

Records management events (API calls) by default for 90 days in the console. Create a trail (or organisation trail) to keep everything long-term in S3.
Protect it: a separate logging account, bucket with Object Lock, and log file validation.
Data events (e.g. every S3 GetObject) are optional and cost extra. Enable them for sensitive buckets.

GuardDuty, Config, Security Hub

GuardDuty: enable in every region and account (via Organizations). It covers suspicious API use, compromised instances, crypto-mining, and has EKS protections (audit log analysis and runtime monitoring).
AWS Config: records resource configuration history and evaluates rules ("S3 buckets must block public access", "EBS volumes must be encrypted").
Security Hub: aggregates findings from GuardDuty, Config, Inspector and others, with benchmark scores (e.g. CIS AWS Foundations).

Try it: encryption, secrets and audit (sandbox account)

Create a customer managed KMS key with alias alias/lab-data; encrypt and decrypt a small file with aws kms encrypt / decrypt.
Create an S3 bucket with default encryption using that key. Upload an object, then remove your permission to use the key (in the key policy for a test role) and try to read the object.
Store a secret in Secrets Manager and a parameter in Parameter Store; read both with a role that has only those permissions.
Find your own CreateKey call in CloudTrail event history.
Enable GuardDuty and look at the sample findings (aws guardduty create-sample-findings).

Going deeper: security at organisation scale

Enable CloudTrail, GuardDuty, Config and Security Hub organisation-wide, with a delegated administrator in a security account.
Protect the protectors: SCPs that deny disabling CloudTrail, GuardDuty and Config.
Route high-severity findings into your incident process with owners and SLAs. Unread findings are just noise.
Treat KMS key deletion as dangerous: it has a waiting period for a reason. Alert on ScheduleKeyDeletion.

Recap

KMS: customer managed keys, key policies, envelope encryption, rotation.
Secrets Manager for rotating secrets, Parameter Store for config; deliver them to pods via External Secrets.
CloudTrail for audit (central, protected, long-term); GuardDuty for threats; Config and Security Hub for posture.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.