1. Introduction to AWS

👈 Back to: 📝 Blog | 💼 LinkedIn | ✍️ Medium

1.1 Introduction to the Critical Elements of AWS

  • Regions → AZs → Data Centers

    • One can deploy AWS services in different AWS Regions
    • AWS Regions consist of Availability Zones (AZs).
    • AZs consist of one or more physical data centers.

  • Root account first steps (non‑negotiable)

    1. Enable MFA on the root user immediately
    2. Create an IAM Administrator role
      • Full service creation permissions
      • No account‑level or billing changes
    3. Lock away root credentials

  • IAM policies cannot restrict the root user

    • Root user always has unrestricted access, regardless of IAM policies.

  • Shared Responsibility Model

    • AWS = security of the cloud
    • Customer = security in the cloud

  • Every activity in AWS is an API call

    • Console clicks, CLI commands, SDK calls → all become authenticated & authorized AWS API requests.

1.2 Choose the Right AWS Region

Essential takeaway:
Choose Region in this order:

  1. Compliance / data residency
  2. Latency
  3. Service availability
  4. Cost
  5. Availability & DR needs

flowchart LR
  A((Start:<br>AWS Region<br>Selection))

  %% Parallel decision branches
  A --> B{"Compliance /<br>Data Residency?"}
  A --> C{"Latency-sensitive<br>workload?"}
  A --> D{"Required AWS<br>services and features<br>available?"}
  A --> E{"Cost a<br>key driver?"}
  A --> F{"Availability /<br>Disaster Recovery<br>(DR) needs?"}

  %% Compliance
  B -->|Yes| B1["Restrict to Regions<br>that satisfy<br>regulatory and<br>residency needs"]
  B -->|No| G

  %% Latency
  C -->|Yes| C1["Prefer Regions<br>closest to users /<br>systems"]
  C -->|No| G

  %% Services
  D -->|No| D1["Adjust shortlist<br>based on AWS<br>Regional Services<br>availability"]
  D -->|Yes| G

  %% Cost
  E -->|Yes| E1["Compare Regions<br>using AWS Pricing<br>Calculator"]
  E -->|No| G

  %% Availability / DR
  F -->|Single Region OK| F1["Design Multi-AZ<br>within one Region"]
  F -->|Needs regional DR /<br>global users| F2["Design Multi-Region:<br>active / active<br>or<br>active / passive"]

  %% Convergence
  B1 --> G
  C1 --> G
  D1 --> G
  E1 --> G
  F1 --> G
  F2 --> G

  G((End:<br>Finalize Region<br>choice))

  %% Notes
  D1 -.-> N1["Note:<br>New services and features<br>roll out gradually<br>and may not exist in<br>all Regions"]
  E1 -.-> N2["Note:<br>Pricing differs by Region<br>due to local costs<br>(power, land,<br>taxes)"]

1.3 Availability Zones

  • Each Region contains multiple AZs
  • Each AZ = one or more data centers
  • Data centers are:
    • Physically separate
    • Redundantly powered and networked
  • AZs are connected by low‑latency, high‑bandwidth links
  • AZ names:
    • <region><letter> (example: us-east-1a)
    • Letter mappings differ per account
  • Resource location example:
    • us-east-1c → AZ “c” inside us-east-1

flowchart TB
  R["AWS Region<br/>(e.g., ap-south-1)"]

  R --> AZ1[Availability Zone A]
  R --> AZ2[Availability Zone B]
  R --> AZ3[Availability Zone C]

  AZ1 --> DC1A[Data Center A1]
  AZ1 --> DC1B[Data Center A2]

  AZ2 --> DC2A[Data Center B1]
  AZ2 --> DC2B[Data Center B2]

  AZ3 --> DC3A[Data Center C1]

  %% Notes
  DC1A -.-> N1[Independent power, cooling & security]
  AZ1 -.-> N2[AZs are physically separated\nand fault isolated]
  R -.-> N3[Region provides data residency\nand compliance boundary]

1.4 Scope of AWS Services

Scope summary:

  • Global services

    • Single logical control plane across AWS
    • Example: IAM, Route 53, CloudFront

  • Regional services

    • Live within a Region, usually span multiple AZs
    • Example: S3, DynamoDB, VPC, RDS Multi‑AZ

  • Zonal services

    • Bound to a single AZ
    • Example: EC2, EBS, RDS Single‑AZ

Availability & durability:

  • Some services are AWS‑managed
  • Others require customer‑designed HA/DR

flowchart LR
  A[AWS Services: Scope<br>& Responsibility]
  %% Scope buckets
  %% =========================
  G[Global Scope<br/>One logical<br>control plane across AWS]
  R["Regional Scope<br>Resources live in a Region<br>May span multiple AZs"]
  Z["Zonal /<br>AZ Scope<br>(tied to 1 Availability Zone)"]

  %% =========================
  %% GLOBAL
  %% =========================
  subgraph G1[Global Scope]
    G --> IAM["[AWS IAM]"]
    G --> R53["[Amazon Route 53]"]
    G --> CF["[Amazon CloudFront]"]
  end

  %% =========================
  %% REGIONAL
  %% =========================
  subgraph R1[Regional Scope]
    R --> S3["[Amazon S3]"]
    R --> DDB["[Amazon DynamoDB]"]
    R --> RDSMA["[Amazon RDS<br>(Multi-AZ deployment)]"]
    R --> VPC["[Amazon VPC]"]
    R --> ALB["[ALB (cross-zone)]"]
    INTER{{"AWS managed<br>but customer<br>designs HA<br>by creating subnets<br>across AZs"}}
  end

  %% =========================
  %% ZONAL / AZ
  %% =========================
  subgraph Z1[Zonal / AZ Scope]
    Z --> EC2["[Amazon EC2 instance]"]
    Z --> EBS["[Amazon EBS volume]"]
    Z --> RDSSA["[Amazon RDS (Single-AZ)]"]
  end

  %% =========================
  %% Responsibility overlay
  %% =========================
  A --> H{Who provides<br/>Availability & Durability?}

  H -->|Service-managed by AWS| AWSM[AWS manages<br>durability/availability<br/>based on the service design]
  H -->|Customer-designed| CUST["Customer must<br>architect HA/DR<br/>(multi-AZ,<br>backups, replication,<br>autoscaling)"]

  AWSM -.-> G
  AWSM-.->R
  CUST-.-> INTER -.->VPC
  INTER -.->ALB

  CUST -.-> Z
  %% =========================
  %% Subgraph styling (visibility)
  %% =========================
  style G1 fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
  style R1 fill:#e8f5e9,stroke:#43a047,stroke-width:2px
  style Z1 fill:#fff3e0,stroke:#fb8c00,stroke-width:2px

1.5 Cost vs Resiliency - 2 Sides of a Coin

flowchart LR
    A[Design Phase] --> B[Implementation]
    B --> C{The Twin Metrics}
    
    C -->|Reliability| D[Uptime/Latency]
    C -->|Economics| E[Unit Cost / Waste]
    
    D --> F[Happy Users]
    E --> G[Sustainable Business]
    
    F & G --> H[Feedback to Engineers]
    H --> A

    style C fill:#fff,stroke-dasharray: 5 5
    %%style E fill:#ff9,stroke:#333

1.5A How to Maintain Resiliency

  • Prefer Region‑scoped managed services
  • Otherwise:
    • Deploy across multiple AZs
    • Minimum two AZs
  • AZ failure ≠ application outage when designed correctly

1.5B Cost Optimization as an Architectural Choice - A Mindset View

In the cloud, every architectural decision is a financial decision. - So many wise folks!

flowchart TD
    Start((<b>The Design Choice:</b><br/>Architectural Decision)) 
    
    Start --> Obs["<b>Visibility</b><br/>How will I tag and<br/>track this spend?"]
    Start --> Clean["<b>Waste Prevention</b><br/>How do I ensure this<br/>deletes itself when idle?"]
    Start --> Fit["<b>Right-Sizing</b><br/>What is the 'minimum'<br/>viable capacity?"]
    Start --> Buy["<b>Procurement</b><br/>Should I commit long-term<br/>or stay flexible?"]
    Start --> Modern["<b>Architecture</b><br/>Can I use Serverless/Managed Services<br/>to offload management?"]

    %% Convergence into Value
    Obs & Clean & Fit & Buy & Modern --> Value((<b>Business Value</b><br/>Cost per Unit of Work))

1.6 Security and the AWS Shared Responsibility Model

Core distinction

  • AWS responsibility (security of the cloud):

    • Physical data centers
    • Hardware, networking
    • Host OS and virtualization layer

  • Customer responsibility (security in the cloud):

    • IAM, access control
    • Data protection & encryption
    • Network security (SGs, NACLs)
    • Backups and recovery

AWS manages the infrastructure.
You secure what you build on top of it.

1.7 Protect the AWS Root User

Authentication vs Authorization

  • Authentication:
    “Who are you?” (passwords, MFA, tokens)

  • Authorization:
    “What are you allowed to do?” (IAM policies)

AWS Root User

  • Created with the AWS account
  • Has full, unrestricted access
  • Credentials:
    • Email + password (console)
    • Access keys (programmatic)

Critical facts:

  • IAM policies cannot limit root
  • Root should never be used for daily work

Root User Best Practices

  • Enable MFA
  • Strong, unique password
  • Delete root access keys once other roles are created. Can be reactivated for account closure or other activities, when needed
  • Use root only for:
    • Account setup
    • Billing
    • Rare account‑level tasks

1.8 Every AWS Activity Is an API Call

A. How does IAM allow you to reach a AWS service?

flowchart LR
  U[You / App] --> I{How do you<br/>interact with AWS?}

  I --> C["AWS Management Console<br/>(click, create, update)"]
  I --> L["AWS CLI<br/>(aws ec2..., aws s3...)"]
  I --> S["AWS SDKs<br/>(Boto3 / Java / JS / .NET)"]

  C --> RQ[Signed AWS API Request]
  L --> RQ
  S --> RQ

  RQ --> IAM{AuthN + AuthZ<br/>IAM policy evaluation}

  IAM -->|Allowed| API[AWS Service<br/>API Endpoint]
  IAM -->|Denied| DENY[AccessDenied]

  • Console, CLI, SDK → AWS API
  • API calls are:
    • Authenticated
    • Authorized
    • Evaluated by IAM
  • Understanding this explains:
    • IAM behavior
    • Auditing (CloudTrail)
    • Automation (IaC, CI/CD)
    • Security boundaries

By understanding APIs, IAM, Regions, AZs, and responsibility boundaries — one understands AWS.

B. What kind of work does the AWS service do after IAM allows it?

  • Control Plane → provide the administrative APIs/ define what exists (CRUDL)
  • Data Plane → provide the primary function of the service

Source: Control Planes and Data Planes in AWS

flowchart LR
  API[AWS Service API Endpoint]

  API --> CP[Control Plane APIs<br/>Create / Describe / Update<br/>Delete / List]
  API --> DP[Data Plane APIs<br/>Use the provisioned<br/>resource]

  %% Examples: control plane
  CP --> EC2CP[EC2:<br/>RunInstances /<br/>DescribeInstances]
  CP --> S3CP[S3:<br/>CreateBucket]
  CP --> SQScp[SQS:<br/>CreateQueue /<br/>GetQueueAttributes]

  %% Examples: data plane
  DP --> S3DP[S3:<br/>PutObject / GetObject]
  DP --> EBSDP[EBS:<br/>Read / Write<br/>volume blocks]
  DP --> R53DP[Route 53:<br/>Answer DNS queries<br/>+ Health checks]

  %% Key takeaway
  CP -.-> NOTE1["AWS Control Plane<br/>= administrative APIs (CRUDL)<br/>e.g., launch EC2,<br/>create S3 bucket,<br/>describe SQS queue"]
  DP -.-> NOTE2["AWS Data Plane<br/>= primary service function<br/>e.g., put/get S3 objects,<br/>read/write EBS,<br/>Route 53 DNS answers"]

C. Control Plane vs Data Plane - S3 as Example

S3 Control plane APIs (AWS CLI examples)

✅ Create a bucket (control plane)

aws s3api create-bucket \
  --bucket my-example-bucket-123 \
  --region ap-south-1 \
  --create-bucket-configuration LocationConstraint=ap-south-1

create-bucket “Creates a new S3 bucket.”

  • Rule of thumb: Anything Bucket (create bucket, put bucket encryption, put bucket policy, lifecycle, versioning…) is typically “control plane” style because you’re configuring the container and its behavior.
aws s3api delete-object \
  --bucket my-example-bucket-123 \
  --key docs/readme.txt
  • Rule of thumb: Anything Object (PutObject/GetObject/ListObjects/DeleteObject/HeadObject) is “data plane” because you’re interacting with the stored data.