Securing Your Cloud, Part 3: AWS Without the Regrets

This is part 3 of GRAYTECH.ONE's "Securing Your Cloud" series — practical hardening for the three big clouds. Part 1 covered GCP, part 2 covered Azure.

AWS is the oldest of the three clouds and it shows — in good ways and bad. The good: fifteen years of documented breach post-mortems mean every common failure mode is known and fixable. The bad: AWS gives you enough rope to hang yourself in a dozen ways before lunch, and its default state (no root MFA, permissive S3, open security groups) has ended up in the news more than once.

1. The root account: exist, then never use it

• MFA on root is non-negotiable — hardware key, not SMS. The root account can literally delete the organization.
• Root never gets access keys. Delete them (IAM → Account settings → root access keys) and do daily business with an assumed admin role instead.
• Set an organization SCP (service control policy) that denies IAM changes made by the root user. Even if the root credential leaks, it can't do anything interesting.

2. IAM: roles over users, always

• No long-lived access keys for humans. People assume roles via SSO (Identity Center — formerly AWS SSO). If a human has a static AKIA... key, that's a finding.
• Workloads get instance roles or OIDC roles — an EC2 instance profile, a GitHub Actions OIDC trust. Keys in .env files and CI variables are how repos leak into crypto farms.
• Permission boundaries on anything third-party touches. Scope contractor roles to named resources — arn:aws:s3:::company-prod-logs/* beats s3:* every time.

3. S3 and the public bucket problem

The open S3 bucket is the classic AWS breach, and it's fully preventable with three account-level switches:

• Block Public Access at the account level — on, everywhere, even if you think you need an exception. Exceptions get made deliberately, bucket by bucket, with a ticket.
• Default encryption SSE-S3 minimum, KMS where it matters — free, one click per bucket now the default.
• Versioning + Object Lock on anything ransomware-relevant. Encrypted backups you can't delete are the difference between an incident and a catastrophe.

4. Network: security groups and the VPC edge

• No 0.0.0.0/0 on 22 or 3389. SSM Session Manager gives shell access with zero open ports and full session logging. It's the modern answer; "but we've always RDP'd" is the old problem.
• Separate security groups per tier (web / app / data), referencing each other by SG ID, not CIDR. Changes become readable and diffs matter.
• VPC Flow Logs to a central S3 — cheap, and when something weird happens it's the difference between a story and a mystery.

5. Detection: the two things worth day one

• GuardDuty: flip it on in every region you use anything. It's the managed threat detection that catches credential misuse, mining images, and probing — for pennies per GB of logs.
• CloudTrail org trail — one trail, all accounts, all regions, to a locked-down S3 bucket. Every serious AWS post-mortem starts with "we wish we'd had this."

The AWS five-minute audit

1. IAM → Credential report: any root keys, any password + key humans, any key older than 90 days?
2. S3 → account-level Block Public Access: on in every region?
3. EC2 → Security Groups → filter 0.0.0.0/0 on 22/3389/3306/5432. Each hit is a finding.
4. IAM → check for AdministratorAccess attached to more than a couple of entities.
5. GuardDuty + CloudTrail: enabled in every active region?

AWS's defaults have improved — new accounts get better guardrails every year — but the account you built in 2023 carries whatever era it was born in. The audit above takes five minutes and clears most of the archaeology.

That's the series: three clouds, one pattern — tight identity, boring networks, logs worth reading. The details differ; the discipline doesn't.