Cloud & Infrastructure

18 practices · AWS Well-Architected Security Pillar + general infra hardening

Account-level controls for the cloud estate — identity, network boundaries, encryption, logging and recovery. For a fast pass over a single AWS account, use the AWS Quick Checklist instead.

Ticking these off for a specific project? The Project Security Checklist tracks all nine categories in one place. For why these patterns keep recurring, see Security Best Practices.

1. Enforce MFA Everywhere, Retire Root Use

Description

Every human identity that can reach the cloud console — especially the root/organization account — should require multi-factor authentication. Lock the root account away (hardware MFA in a vault) and never use it day to day; create an admin IAM role instead.

Example 
aws iam enable-mfa-device --user-name alice ...
// Org-level guardrail (SCP):
"Condition": { "BoolIfExists":
{ "aws:MultiFactorAuthPresent": "false" } } → Deny *

2. Least-Privilege IAM & Short-Lived Credentials

Description

Grant only the specific actions and resources a role needs — never Action:"*" — and issue temporary, auto-expiring credentials via STS/SSO instead of long-lived access keys that can leak.

Example 
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::app-uploads/*"
}
// scoped to one bucket, one action — not AdministratorAccess

3. Secrets Manager With Automatic Rotation

Description

Database passwords, API keys, and service credentials live in a secrets manager (AWS Secrets Manager, Vault) with rotation scheduled automatically — not in .env files, Dockerfiles, or CI variables that outlive the person who set them.

Example 
aws secretsmanager rotate-secret \
--secret-id prod/db/password \
--rotation-lambda-arn arn:...:rotateFn \
--rotation-rules AutomaticallyAfterDays=30

4. Encrypt Data at Rest by Default

Description

Turn on KMS-backed encryption for every S3 bucket, EBS volume, and RDS instance by default — via account-level policy, not a per-resource checkbox someone might forget.

Example 
S3      → Default encryption: SSE-KMS
EBS     → "Always encrypt new volumes" account setting: ON
RDS     → StorageEncrypted: true

5. TLS Everywhere, No Exceptions

Description

Every connection — client-to-server, service-to-service, and service-to-database — runs over TLS 1.2+. Certificate validation is never disabled, even temporarily, even in a script that "just needs to run once."

Example 
// Node/Postgres — never do this:
{ ssl: { rejectUnauthorized: false } }
// Instead: mount the CA bundle and validate it properly

6. Network Segmentation

Description

Put anything that isn't meant to be public in a private subnet, and use security groups as a default-deny allowlist between tiers — the database should only ever hear from the application layer, never the internet.

Example 
DB security group inbound:
only from app-tier SG, port 5432
No 0.0.0.0/0 rules on anything but the public ALB

7. WAF & DDoS Protection at the Edge

Description

Put a Web Application Firewall (AWS WAF, Cloudflare) in front of public endpoints to block common attack patterns before they reach application code, and enable managed DDoS protection for anything public-facing and important.

Example 
AWS WAF managed rule groups:
AWSManagedRulesCommonRuleSet
AWSManagedRulesSQLiRuleSet
attached to CloudFront / ALB

8. Session Manager Instead of Open SSH

Description

Access EC2 instances through AWS Systems Manager Session Manager (or a bastion behind SSO+MFA) instead of exposing port 22 to the internet — every session is logged and requires no long-lived SSH key.

Example 
aws ssm start-session --target i-0123456789abcdef0
# security group: no inbound 22 from 0.0.0.0/0

9. Centralized Logging & Real-Time Alerting

Description

Every account feeds CloudTrail, VPC Flow Logs, and application logs into a central SIEM, with GuardDuty/Security Hub findings routed to an on-call channel — logs nobody looks at are not a control.

Example 
GuardDuty finding → EventBridge rule → SNS → PagerDuty
(not just "visible in a dashboard someone might check")

10. Data Classification & Handling Policy

Description

Not all data needs the same protection — tag and classify data (public/internal/confidential/restricted) so encryption, retention, and access requirements scale with sensitivity instead of being applied uniformly or not at all.

Example 
S3 bucket tag: DataClassification=Restricted
→ triggers stricter bucket policy + access logging

11. Centralize Identity With SSO

Description

Federate every account through a single identity provider (Okta, Azure AD, AWS IAM Identity Center) instead of creating individual IAM users per account. Offboarding becomes one action instead of a checklist across a dozen systems.

Example 
IAM Identity Center → permission sets mapped to
AD/Okta groups
(no per-account IAM users for humans)

12. Automated Patch Management

Description

OS and dependency patching runs on a schedule via Systems Manager Patch Manager (or equivalent), not as a manual quarterly task someone remembers eventually — critical patches roll out in days, not months.

Example 
SSM Patch Manager:
patch baseline auto-approves
Critical/Security patches after 2 days

13. Infrastructure as Code + Security Scanning

Description

Infrastructure is defined in Terraform/CloudFormation, version-controlled, and scanned by a policy tool (tfsec, Checkov) in CI before it's ever applied — catching a public bucket or open security group before it exists.

Example 
checkov -d ./infra --check CKV_AWS_18,CKV_AWS_20
# fails the PR on a public bucket or missing encryption

14. Container & Image Security

Description

Base container images come from a trusted, minimal source (distroless/alpine), are scanned for known CVEs before deploy, and run as a non-root user with a read-only filesystem where possible.

Example 
FROM gcr.io/distroless/nodejs20
USER 1000
# + trivy image scan in CI, fail on HIGH/CRITICAL

15. Tested Backups & Disaster Recovery

Description

Automated backups exist for every stateful service, and — critically — someone has actually restored from one recently. An untested backup is a hope, not a plan.

Example 
Quarterly game-day:
restore prod DB snapshot to a scratch VPC,
verify row counts + app boot, time the whole thing

16. Multi-Account Strategy With Guardrails

Description

Separate prod, staging, and dev into different AWS accounts under an Organization, with Service Control Policies enforcing account-wide guardrails that even an admin in that account can't override.

Example 
SCP: Deny cloudtrail:StopLogging, cloudtrail:DeleteTrail
attached at the Organizational Unit level

17. Configuration Drift Detection & CSPM Scanning

Description

Continuously evaluate live infrastructure against your intended policy and known-bad patterns — public buckets, open security groups, disabled logging — using AWS Config/OPA for drift and a cloud security posture management (CSPM) tool for broader benchmark checks, so a manual console change gets flagged and reverted before an attacker finds it first.

Example 
AWS Config rule: s3-bucket-public-read-prohibited
→ auto-remediation Lambda re-blocks public access
Prowler / Security Hub (CSPM), scheduled daily scan
vs. CIS AWS Foundations Benchmark → Slack alert

18. Incident Response Plan & Game Days

Description

Have a written runbook for "what do we do when X happens" (leaked key, ransomware, data exposure) before it happens, and rehearse it at least annually — the first incident is a bad time to design the process.

Example 
Tabletop: "Our Stripe key just appeared in a public repo."
Walk the runbook: rotate → audit usage → notify → postmortem

Last updated: September 2026 · Source: Offspring — Security Best Practices.pptx (Part 4) + Security Best Practices Checklist.xlsx