"Protect Information, Systems, and Assets"
Security in the cloud is not a single firewall at the edge of your network. Think of it like a medieval castle: there's a moat, a drawbridge, outer walls, inner walls, guards at each door, and a vault for the crown jewels. Each layer provides defense even if the outer layer is breached. This concept is called Defense in Depth.
The Security pillar formalizes this layered approach and adds a critical principle: security should be automated, not manual. A human reviewing access logs once a week will always miss something. A tool that alerts in real-time will not.
Design Principles
- Implement a strong identity foundation: Centralize privilege management using IAM. Follow the Principle of Least Privilege — every user, role, and service gets only the permissions it needs to do its specific job, and nothing more. The root account should never be used for daily operations.
- Enable traceability: Log and audit everything using CloudTrail (API calls), CloudWatch Logs (application logs), and VPC Flow Logs (network traffic). You must be able to answer: "Who did what, to which resource, at what time?"
- Apply security at all layers: Secure the VPC, the subnet, the load balancer, the EC2 instance OS, the application code, and the database. Compromising one layer should not mean compromising everything.
- Automate security best practices: Use AWS Config rules to automatically detect open S3 buckets or overly permissive security groups. Use GuardDuty to detect anomalous behavior automatically.
- Protect data in transit and at rest: Encrypt data moving between services (TLS) and data stored on disk (KMS). Treat unencrypted data as a vulnerability.
- Keep people away from data: Developers should rarely have direct SSH access to production servers or direct read access to production databases. Use Systems Manager Session Manager instead of SSH, and use automated pipelines instead of manual deployments.
A common interview question is: "What is the Shared Responsibility Model?" AWS is responsible for security of the cloud (physical hardware, hypervisor, managed service infrastructure). You are responsible for security in the cloud (your OS patches, your IAM policies, your data encryption, your application code). Misunderstanding this boundary is one of the most common causes of cloud security breaches. For example, AWS secures the S3 infrastructure — but if you configure a bucket as public, that is your responsibility.
Key Services: IAM, AWS KMS (encryption key management), GuardDuty (threat detection), AWS Shield (DDoS protection), AWS WAF (web application firewall), Amazon Inspector (vulnerability scanning), CloudTrail (audit logging).