Service 62

Security Best Practices

ArchitectureSecurityPractices

The individual security services (IAM, KMS, Secrets Manager, WAF, Shield, GuardDuty, Macie, Security Hub, ACM) are building blocks; this is the cross-cutting discipline that shows up in every well-secured AWS account. Security on AWS is not a feature you turn on — it is a practice you apply consistently.

Most cloud breaches are not AWS being insecure; they happen when teams skip steps AWS has recommended for a decade.

Identity and Encryption

Every security architecture starts with identity: Identity Center for humans (no IAM users for engineers), roles not access keys for service principals, least privilege, and SCPs for organization-wide non-negotiables (no root use, no unapproved Regions, no disabling CloudTrail). Audit principals with Access Analyzer's unused-access checker.

Encryption at rest is essentially free — enable default encryption on every storage service, use Customer Managed Keys for data that matters, turn on annual key rotation, and use multi-Region keys for cross-Region data. Force TLS in transit wherever the service allows.

Network, Secrets, and Detection

Network controls are defense in depth: default to private subnets, use security groups as the primary firewall referencing other groups (never 0.0.0.0/0 on the database or SSH), use VPC endpoints for AWS-service traffic, and apply WAF at the edge with the Core Rule Set and a rate-based rule. Use Secrets Manager for credentials and Parameter Store for configuration.

For detection: an organization-wide CloudTrail to an immutable bucket in a separate audit account, GuardDuty in every Region of every account, Security Hub with the Foundational Security Best Practices standard, and Macie on customer-data buckets. Route findings to EventBridge — a console nobody watches is no console.

Account Architecture and Incident Readiness

The account boundary is one of AWS's strongest security primitives: separate production from non-production, separate workloads by sensitivity (PCI, HIPAA), centralize networking and logs in dedicated accounts, and use Control Tower for the Landing Zone.

Detection is half the work; response is the other half. Have runbooks for the common incidents (compromised credentials, public bucket, unintended cross-account access), practice them quarterly, and keep forensic-friendly logging (CloudTrail, VPC Flow Logs, access logs) so you have answers when it matters.

Network controls vs identity as the boundary

Identity (IAM, Identity Center) — the primary control plane — who can do what. Get this right and the rest gets easier.

Network controls (security groups, NACLs, WAF) — defense in depth, not the primary boundary, in a Zero Trust model.

Detection (CloudTrail, GuardDuty, Security Hub) — the assumption that some attacks succeed — catch them fast.

Common Mistakes

Creating long-lived IAM access keys for humans instead of Identity Center with federation and MFA.
Granting wildcard permissions 'to be easier later' instead of least privilege tightened from real usage.
Storing credentials in environment variables checked into git — the most common breach pattern in the industry.
Leaving GuardDuty off in non-production or unused Regions, giving an attacker a free hiding spot.
Keeping CloudTrail logs in the same account as the data instead of an immutable bucket in a separate audit account.
Skipping SCPs, so an IAM admin can disable CloudTrail, use the root account, or create resources in unapproved Regions.

Best Practices

Use Identity Center for humans and roles for services; no long-lived access keys; SCPs for non-negotiables.
Enable default encryption everywhere, with Customer Managed Keys and rotation for data that matters.
Default to private subnets; use security groups referencing other groups; never open the database or SSH to the world.
Run an organization-wide CloudTrail to an immutable bucket in a separate audit account.
Enable GuardDuty everywhere, Security Hub with FSBP, and Macie on customer-data buckets; route findings to alerting.
Separate accounts by environment and sensitivity, and keep practiced runbooks for common incidents.

Comparable services GCP Security Foundations Blueprint, Security Command CenterAzure Cloud Adoption Framework security, Defender for Cloud

Knowledge Check

What is the foundation of every AWS security architecture?

Identity — Identity Center for humans, roles for services, least privilege, SCPs for non-negotiables
Network firewalls as the primary boundary, with security groups and NACLs around every subnet doing the main work of keeping attackers out
Encrypting every EBS volume and S3 bucket with KMS and nothing else, treating encryption at rest as the whole of security
Buying Shield Advanced and relying on its DDoS mitigation to serve as the foundation the rest of the architecture builds on

Where should organization-wide CloudTrail logs be stored?

In an immutable (Object Lock) bucket in a separate audit account so even root cannot alter them
In the same account as the workloads they audit, so the team can reach them quickly and conveniently
In each developer's personal account
Only in CloudWatch Logs with 1-day retention

Why enable GuardDuty in Regions and accounts you do not actively use?

An unmonitored account or Region is a free place for an attacker to operate undetected
It is a hard prerequisite for turning on default encryption across every service in that account
It reduces the CloudTrail bill
Findings only appear in unused Regions

What role do network controls play in a modern (Zero Trust) AWS security model?

Defense in depth — important, but not the primary boundary; identity is the control plane
The one and only security boundary that matters, since anything inside the VPC is inherently trusted
They replace IAM entirely
They are unnecessary once you have encryption

You got correct