🔒 Module 05 · Global Infrastructure, IAM & Security

AWS global infrastructure

• 🌎Region A geographic area such as ap-south-1 (Mumbai) or us-east-1 (N. Virginia). Regions are isolated from one another; data does not leave a Region unless you move it. Most services are regional.
• 🏢Availability Zone (AZ) One or more discrete data centres inside a Region, with independent power, cooling and networking, connected by high-bandwidth, low-latency links. Every Region has at least three.
• 📍Local Zone / Wavelength An extension of a Region placed close to a large city or inside a mobile network, for workloads that need single-digit-millisecond latency.
• ⚡Edge location / Point of Presence Hundreds of sites worldwide used by CloudFront and Route 53 to serve users from nearby. There are far more edge locations than Regions.

Choosing a Region — four factors, in this order

Global versus regional services

The Shared Responsibility Model

The single most examinable diagram in AWS. AWS secures the cloud; you secure what you put in it.

AWS Identity and Access Management

IAM answers one question for every single API call in your account: is this principal allowed to perform this action on this resource? The default answer is no.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadOneBucket",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::pushpjeetinitm",
        "arn:aws:s3:::pushpjeetinitm/*"
      ]
    }
  ]
}

Read it as: allow the actions GetObject and ListBucket on that bucket and everything inside it. The bucket ARN and the object ARN are different resources — listing needs the bucket, reading needs the objects. Forgetting one of the two is the most common policy bug.

How a decision is actually made

Root user

The root user is the email address you signed up with. It can do anything, and no policy can restrict it (only an SCP can). Treat it as a break-glass credential:

• Enable MFA on it immediately.
• Delete any root access keys.
• Create an IAM admin user or role and use that for everyday work.
• Only a short list of tasks genuinely require root — closing the account, changing the support plan, changing the account name or email, and restoring an IAM policy that locked everyone out.

Securing accounts, securing data, compliance

Account security baseline

• 🔑MFA everywhere Root first, then every human user. A password alone is not an account control.
• 🎯Least privilege Grant the minimum, then widen only when something genuinely breaks. Start from a managed policy and narrow it, rather than starting from *.
• 🔍CloudTrail on, everywhere It records every API call. Without it you cannot answer "who deleted that?" — and that question always gets asked eventually.
• 🧱Separate accounts Production, development and sandbox in different accounts under one Organization is the cleanest blast-radius control AWS offers.
• 🔄Rotate and remove credentials Use the IAM credential report to find keys nobody has used for 90 days, and delete them.

Securing data

Working to ensure compliance

Key takeaways

• ✅Region → Availability Zone → data centre. Edge locations are separate and far more numerous.
• ✅Choose a Region by compliance, then latency, then cost, then service availability.
• ✅Always design across at least two Availability Zones.
• ✅AWS secures the cloud; you secure what you put in it. The more managed the service, the more AWS does.
• ✅IAM: users and groups for people, roles for machines and temporary access, policies as JSON.
• ✅Explicit deny always wins; everything is denied unless explicitly allowed.
• ✅Never put long-lived access keys on an EC2 instance — attach a role.
• ✅Encrypt at rest with KMS and in transit with TLS; use Artifact for audit reports.

Quiz