AWS Security: IAM, VPCs & Shared Responsibility

The Shared Responsibility Model

AWS security operates on a fundamental principle that trips up many organizations: AWS is responsible for the security of the cloud; you are responsible for security in the cloud. AWS secures the physical data centers, the hypervisor, the managed service infrastructure, and the underlying network fabric. You are responsible for everything you build on top: your data, your applications, your IAM configurations, your security group rules, your encryption choices, and your logging.

This boundary shifts depending on the service type:

• IaaS (EC2): you manage the OS, runtime, application, and data
• PaaS (RDS, Lambda): AWS manages the OS and runtime; you manage the application and data
• SaaS (Amazon WorkMail): AWS manages nearly everything; you manage access and data

Misconfiguring your side of the boundary — an S3 bucket left public, an overpermissive IAM role, a security group open to 0.0.0.0/0 — is your responsibility, regardless of how secure AWS's infrastructure is.

IAM: The Most Critical AWS Security Control

AWS Identity and Access Management (IAM) controls who can do what across every AWS service. Getting IAM right is the single most impactful thing you can do for AWS security.

Root Account Protection

The AWS root account has unrestricted access to everything and cannot be locked down with policies. Protect it:

• Enable hardware MFA on the root account immediately after account creation
• Do not create access keys for root — ever
• Only use root for tasks that specifically require it (billing, account settings, support plan changes)
• Set up billing alerts via CloudWatch so you notice unexpected usage

IAM Users, Roles, and Policies

For human users, prefer IAM Identity Center (formerly SSO) with federated identities from your corporate directory over individual IAM users. For machine identities (EC2 instances, Lambda functions, ECS tasks), always use IAM Roles rather than hardcoded access keys — roles provide temporary credentials that rotate automatically.

Write policies using the principle of least privilege:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-app-bucket/*"
  }]
}

Use IAM Access Analyzer to identify overpermissive policies and external access to your resources. Run credential reports regularly (aws iam generate-credential-report) to audit unused access keys and users.

Service Control Policies (SCPs)

In AWS Organizations, SCPs act as maximum permission boundaries across entire accounts or OUs. Use them to enforce guardrails organization-wide:

• Deny disabling CloudTrail
• Restrict which regions can be used
• Prevent creation of public S3 buckets
• Require MFA for sensitive operations

VPCs: Network Isolation in AWS

A Virtual Private Cloud (VPC) is your private network within AWS. Design it with security in mind from the start:

Subnet Design

Separate resources into public, private, and data subnet tiers:

• Public subnets: only load balancers and NAT Gateways — nothing else
• Private subnets: application servers, Lambda functions, ECS tasks — no direct internet access
• Data subnets: RDS databases, ElastiCache, and other data stores — no internet path whatsoever

Resources in private subnets reach the internet via NAT Gateway (for outbound only). Inbound internet traffic should only enter through a load balancer in the public subnet.

Security Groups vs. NACLs

Security Groups are stateful firewalls attached to individual resources — if you allow inbound port 443, return traffic is automatically allowed. Apply the principle of least privilege: source from specific security group IDs rather than IP ranges where possible.

Network ACLs are stateless and apply at the subnet level — both inbound and outbound rules must be defined. Use NACLs for broad subnet-level controls and security groups for per-resource granularity.

VPC Flow Logs

Enable VPC Flow Logs to all subnets and ship them to CloudWatch Logs or S3. Flow logs capture source/destination IPs, ports, protocol, and accept/reject decisions — essential for forensics and anomaly detection.

Logging and Monitoring: The Security Visibility Stack

• CloudTrail: records every AWS API call — who did what, when, from where. Enable in all regions, enable log file validation, and ship to an S3 bucket with an SCP preventing deletion. This is non-negotiable.
• AWS Config: records configuration changes to AWS resources and evaluates them against compliance rules
• Amazon GuardDuty: ML-powered threat detection analyzing CloudTrail, VPC Flow Logs, and DNS logs to detect credential compromise, instance compromise, and reconnaissance
• AWS Security Hub: aggregates findings from GuardDuty, Config, Inspector, and third-party tools into a single console with CIS benchmark scoring

S3 Security

Publicly exposed S3 buckets remain one of the most common causes of cloud data breaches. Enforce at the account level:

• Enable S3 Block Public Access at the account level — this overrides any bucket-level settings
• Enable default encryption (SSE-S3 or SSE-KMS) on all buckets
• Enable S3 Object Lock for buckets containing audit logs to prevent deletion
• Use bucket policies to enforce HTTPS only: aws:SecureTransport: false → Deny
• Audit bucket permissions regularly with Macie for sensitive data discovery