AWS Core for SREs: VPC, Networking and IAM Explained Visually

A story to begin with

How AWS is organised

flowchart TB
  subgraph Region[Region: ap-south-1 Mumbai]
    subgraph AZa[AZ a]
      A1[Subnet<br/>servers]
    end
    subgraph AZb[AZ b]
      B1[Subnet<br/>servers]
    end
    subgraph AZc[AZ c]
      C1[Subnet<br/>servers]
    end
  end
  Edge[Edge locations<br/>CloudFront, Route 53] --> Region
  style Region fill:#1e293b,color:#fff

• Region: a separate geographic area, isolated from other regions.
• Availability Zone (AZ): one or more data centers inside a region with independent power, cooling and networking. Spread across at least two, ideally three.
• Edge locations: points of presence that serve CloudFront and DNS close to users.
• Some services are regional (S3, DynamoDB), some are AZ-bound (an EBS volume, an EC2 instance), and some control planes are global (IAM, Route 53). Know which is which when you design for failure.

Designing a VPC

A VPC is your own private network inside AWS. Think of it as a building with floors (subnets) and doors (gateways).

flowchart TB
  I((Internet)) --> IGW[Internet Gateway]
  IGW --> ALB[Application Load Balancer<br/>across 3 AZs]
  subgraph VPC[VPC 10.0.0.0/16]
    subgraph PUB[Public subnets]
      ALB
      NAT[NAT Gateway per AZ]
    end
    subgraph APP[Private app subnets]
      EC[EKS or EC2 nodes]
    end
    subgraph DATA[Private data subnets]
      DB[(RDS Multi-AZ)]
      CA[(ElastiCache)]
    end
  end
  ALB --> EC
  EC --> DB
  EC --> CA
  EC --> NAT --> IGW
  EC -. gateway endpoint .-> S3[(S3)]
  style ALB fill:#6366f1,color:#fff
  style DB fill:#22d3ee,color:#012

Key ideas:

• A subnet is public only because its route table sends 0.0.0.0/0 to an Internet Gateway. Servers in private subnets reach the internet through a NAT Gateway.
• Use three tiers: public (load balancers), private app, private data. Databases never get public IPs.
• One NAT Gateway per AZ. A single NAT is a cross-AZ single point of failure and adds data charges (also a classic surprise bill).
• VPC endpoints keep traffic to services like S3 and DynamoDB inside AWS, improving security and cutting NAT cost (gateway endpoints for S3 and DynamoDB are free).
• Plan CIDR ranges up front; overlapping ranges block peering later. Remember Kubernetes pods can consume many IPs.

Connecting networks

Security groups vs NACLs

Best practice: let security groups reference other security groups (for example "app tier may talk to db tier") instead of listing IP ranges.

Load balancing

• ALB (layer 7): host and path routing, gRPC, WebSockets, WAF integration.
• NLB (layer 4): extreme performance, static IPs, preserves client IP.
• Know the error codes: 502 bad response from a target, 503 no healthy targets, 504 target timed out.
• Enable cross-zone balancing, set a deregistration delay for graceful draining, and keep app keep-alive timeouts longer than the load balancer idle timeout (60 seconds by default on ALB).

DNS with Route 53

Policies: simple, weighted, latency-based, failover (with health checks) and geolocation. Use alias records for AWS endpoints. Keep TTLs short for records involved in failover, and remember clients and resolvers may cache longer than you expect.

IAM: who can do what

flowchart LR
  P[Principal<br/>user, role, service] --> E{Policy evaluation}
  E --> D1[Explicit deny?<br/>then DENY]
  E --> D2[Allowed by identity policy<br/>and not blocked by SCP<br/>or boundary?]
  D2 -- yes --> OK[ALLOW]
  D2 -- no --> NO[Implicit DENY]
  style OK fill:#34d399,color:#062
  style NO fill:#f87171,color:#fff
  style D1 fill:#f87171,color:#fff

• Roles over users: roles give short-lived credentials and are assumed by people, services and workloads. Avoid long-lived access keys.
• Policy logic: explicit deny always wins; otherwise you need an explicit allow; the default is deny.
• Guardrails: Service Control Policies (SCPs) in AWS Organizations and permission boundaries cap what any policy can grant.
• Workload identity: EC2 instance profiles, ECS task roles, IRSA or EKS Pod Identity for pods.
• Least privilege: start narrow, use Access Analyzer and CloudTrail to see what is actually used.
• Multi-account: separate accounts for production, non-production, logging and security limit blast radius. Use IAM Identity Center (SSO).

{"Effect":"Allow","Action":["s3:GetObject"],"Resource":"arn:aws:s3:::acme-reports/*",
 "Condition":{"StringEquals":{"aws:PrincipalOrgID":"o-abc123"}}}

Common failure patterns

Shared fate and false confidence

Two traps appear again and again in cloud architecture. First, teams form beliefs about how reliable a foundation service is. When something almost never fails, people quietly build critical paths on top of it, and the day it does fail the damage is far larger than anyone planned. Second, reliability maths must account for correlated failures: three servers in one data center are not three independent chances to survive. On AWS, an availability zone, a NAT gateway, the IAM or DNS control plane and a single account are all shared fates. Your design is only as independent as its weakest shared component.

How to implement a safe AWS foundation in your organization

If you are the engineer who wants every team to build on solid ground, a landing zone approach beats case-by-case advice.

flowchart TD
  A[AWS Organization] --> B[Management account<br/>billing and guardrails only]
  A --> C[Security and logging accounts<br/>CloudTrail, Config, GuardDuty]
  A --> D[Shared services account<br/>networking, CI/CD]
  A --> E[Non-production accounts<br/>dev, test]
  A --> F[Production accounts<br/>per product or tier]
  B -. SCP guardrails .-> E
  B -. SCP guardrails .-> F
  style F fill:#6366f1,color:#fff
  style C fill:#22d3ee,color:#012

Step 1: design the account structure first. Separate production from non-production, and keep security logs in a dedicated account that workload teams cannot modify. Use AWS Organizations and Control Tower (or an equivalent) so new accounts come with baselines. Accounts are your strongest boundary for blast radius, quotas and cost.

Step 2: publish a golden VPC module. One Terraform module that creates the three-tier, multi-AZ layout from this lesson (public, private-app, private-data subnets, a NAT per AZ, gateway endpoints for S3 and DynamoDB, flow logs on). Teams consume it instead of inventing networks. Version it and announce changes.

Step 3: set guardrails with SCPs and policy. Examples of org-wide rules:

• Deny disabling CloudTrail, Config or GuardDuty.
• Deny creating public S3 buckets (or turn on account-level Block Public Access).
• Restrict allowed regions.
• Require encryption for volumes and buckets.
• Deny creating IAM users with long-lived access keys in production.

Step 4: standardise identity. SSO through IAM Identity Center, roles for people and workloads, no shared users, short sessions, MFA, permission sets reviewed quarterly. Use IRSA or Pod Identity for Kubernetes workloads.

Step 5: create a design review checklist. Every new service answers:

• Does it span at least two AZs, with data stores Multi-AZ?
• Are there any single points of failure (NAT, single instance, single AZ)?
• What happens if a dependency, an AZ or the region is unavailable?
• What are the SLOs and how are they measured?
• Who owns it, and where are the runbooks?

Step 6: automate compliance checks. AWS Config rules or a tool such as Checkov scanning Terraform in CI. Publish a weekly report of non-compliant resources per team and track it down.

Step 7: make cost visible. Mandatory tags (team, service, environment), budgets and anomaly alerts per account, a monthly review of NAT, data-transfer and idle resources.

Metrics that show progress

Percentage of workloads in multi-AZ designs, number of accounts on the baseline, policy violations per month, time to provision a compliant new environment, incidents caused by single points of failure.

Pitfalls

• One giant account for everything.
• Hand-built VPCs with overlapping CIDR ranges.
• Guardrails introduced with no exceptions process, causing teams to work around them.
• Long-lived access keys scattered in CI systems.
• Treating a region failure as "someone else's problem" with no documented answer.

Interview questions

Q1. Design a VPC for a three-tier app that survives an AZ loss. Three AZs, public/private-app/private-data subnets in each, an ALB across AZs, an Auto Scaling group spanning AZs with headroom so survivors absorb load, a NAT Gateway per AZ, a Multi-AZ database and VPC endpoints for S3 and DynamoDB.

Q2. Instances in a private subnet cannot reach the internet. How do you debug? Check the route table for a route to a NAT Gateway, that the NAT sits in a public subnet with a route to the Internet Gateway and has an Elastic IP, security group egress, NACL ephemeral ports and DNS resolution.

Q3. How do you give a pod access to S3 safely? Use IRSA or EKS Pod Identity with a role scoped to the required bucket and prefix, no static keys, bucket policy conditions and CloudTrail data events for audit.

Q4. Security group vs NACL? Security groups are stateful, instance-level and allow-only. NACLs are stateless, subnet-level and support allow and deny with ordered rules.

Q5. What is the difference between a role and a user? A user has long-lived credentials; a role is assumed and issues temporary credentials. Roles are preferred for people (via SSO) and especially for workloads.

Next: unlock the rest of the AWS track for compute (EKS, ECS, Lambda), data stores, CloudWatch and multi-region resilience.