• Trade capital expense (CAPEX) for operational expense (OPEX) (Trade fixed expense for variable expense):
  • Pay On-Demand: don’t own hardware;
  • Reduced Total Cost of Ownership (TCO) & Operational Expense (OPEX);
• Benefit from massive economies of scale:
  • Prices are reduced as AWS is more efficient due to large scale;
• Stop guessing capacity:
  • Scale based of actual measured usage;
• Increase speed and agility;
• Stop spending money running and maintaining data centers;
• Go global in minutes: leverage the AWS global infrastructure.

Problems solved by the cloud:

• Flexibility: change resource types when needed;
• Cost-Effectiveness: pay as you go, for what you use;
• Scalability: accommodate larger loads by making hardware stronger or adding additional nodes;
• Elasticity: ability to scale out and scale-in when needed;
• High-availability and fault-tolerance: build across data centers;
• Agility: rapidly develop, test and launch software applications.

• Stop guessing your capacity needs;
• Test systems at production scale;
• Automate to make architectural experimentation easier;
• Allow for evolutionary architectures;
  • Design based on changing requirements;
• Drive architectures using data;
• Improve through game days;
  • Simulate applications for flash sales days.

AWS Cloud Best Practices - Design Principles:

• Scalability: vertical & horizontal;
• Disposable Resourcs: servers should be disposable & easily configured;
• Automation: Serverless, Infrastructure as a Service, Auto Scaling..;
• Loose Coupling: change or failure in one component should not cascade to other;
• Services, not Servers: use managed services, databases and serverless, instead of just EC2.

Well-Architected Framework (6 Pillars):

• Operational Excellence: Prepare, Operate, Evolve. Includes the ability to run and monitor systems to deliver business value and to continually improve supporting processes and procedures:
  • Perform operations as code (IaaS);
  • Make frequent, small, reversible changes: So in a case of failure, it can be reversed;
  • Refine operations procedures frequently: Ensure that team members are familiar with it;
  • Anticipate failure;
  • Learn from all operational failures;
  • Use managed services: to reduce operational burden;
  • Implement observability for actionable insights: performance, reliability, cost, etc;
• Security: Identity and Access Management, Detective Controls, Infrastructure Protection, Data Protection, Incident Response. Includes the ability to protect information, systems and assets while delivering business value through risk assessments and mitigation strategies:
  • Implement a strong identity foundation: Centralize privilege management and reduce reliance on long-term credentials. Principle of least privilege;
  • Enable traceability: Integrate logs and metrics with systems to automatically respond and take action;
  • Apply security at all layers: Like edge network, VPC, subnet, load balancer, every instance, operating system and application;
  • Automate security best practices;
  • Protect data in transit and at rest: Encryption, tokenization and access control;
  • Keep people away from data: Reduce incident response simulations and use tools with automation to increase your speed for detection, investigation and recovery;
  • Shared Responsibility Model;
• Reliability: Foundations, Change Management, Failure Management. Ability of a system to recover from infrastructure or service disruptions, dynamically acquire computing resources to meet demand and mitigate disruptions such as misconfigurations or transient network issues:
  • Test recovery procedures: Use automation to simulate different failures or to recreate scenarios that led to failures before;
  • Automatically recover from failure: Anticipate and remediate failures before they occur;
  • Scale horizontally to increase aggregate system availability: Distribute requests across multiple, smaller resources to ensure that they don’t share a common point of failure;
  • Stop guessing capacity: Maintain the optimal level to satisfy demand without over or under provisioning: use auto scaling;
  • Manage change in automation: Use automation to make changes to infrastructure;
• Performance Efficiency: Selection, Review, Monitoring, Tradeoffs. Includes the ability to use computing resources efficiently to meet system requirements, and to maintain that efficiency as demand changes and technologies evolve:
  • Democratize advanced technologies: Advance technologies become services and hence you can focus more on product development;
  • Go global in minutes: Easy deployment in multiple regions;
  • Use serverless architectures: Avoid burden of managing servers;
  • Experiment more often: Easy to carry our comparative testing;
  • Mechanical sympathy: Be aware of all AWS services;
• Cost Optimization: Expenditure Awareness, Cost Efective Resources, Matching supply and demand, Optimizing Over Time. Includes the ability to run systems to deliver business value at the lowest price point:
  • Adopt a consumption mode: Pay only for what you use;
  • Measure overall efficiency: use CloudWatch;
  • Stop spending money on data center operations: AWS does the infrastructure part and enables customer to focus on organization projects;
  • Analyze and attribute expenditure: Accurate identification of system usage and costs, helps measure return on investment (ROI): Make sure to use tags;
  • Use managed and application level services to reduce cost of ownership: As managed services operate at cloud scale, they can offer a lower cost per transaction or service;
• Sustainability: EC2 Auto Scaling, Lambda and Fargate, Cost Explorer, EC2 Spot Instances, EFS-IA, Amazon S3 Glacier, Amazon Data Lifecycle Manager, Read Local, Write Global (RDS Replical, DynamoDB Global table, CloudFront). The sustainability pillar focuses on minimizing the environmental impact of running cloud workloads:
  • Understand your impact: establish performance indicators, evaluate improvements;
  • Establish sustainability goals: Set long-term goals for each workload, model return on investments (ROI);
  • Maximize utilization: Right size each workload to maximize the energy efficiency of the underlying hardware and minimize idle resources;
  • Anticipate and adopt new, more efficient hardware and software offering: and design for flexibility to adopt new technologies over time;
  • Use managed services: Shared services reduce the amount of infrastructure; Managed services help automate sustainability best practices as moving infrequent accessed data to cold storage and adjusting compute capacity;
  • Reduce the downstream impact of your cloud workloads: Reduce the amount of energy or resources required to use your services and reduce the need for your customers to upgrade their devices. They are not something to balance or trade-offs, they are a synergy.

AWS Customer Carbon Footprint Tool: track, measure, review and forecast the Carbon emissions generated from your AWS usage. Helps you meet your own sustainability goals.

AWS Cloud Adoption Framework (AWS CAF) helps you build and then execute a comprehensive plan for your digital transformation through innovating use of AWS.

• Business Perspective: helps ensure that your cloud investments accelerate your digital transformation abitions and business outcomes;
• People Perspective: serve as a bridge between technology and business, accelerating the cloud journey to help organizations more rapidly evolve to a culture of continuous growth, learning and where change becomes business-as-normal, with focus on culture, organizational structure, leadership and workforce;
• Governance Perspective: helps you orchestrate your cloud initiatives while maximizing organizational benefits and minimizing transformation-related risks;
• Platform Perspective: helps you build an enterprise-grade, sclable, hybrid cloud platform; modernize existing workloads; and implement new cloud-native solutions;
• Security Perspective: helps you achive the confidentiality, integrity and availability of your data and cloud workloads;
• Operations Perspective: helps ensure that your cloud services are delivered at a level that meets the needs of your business.

AWS CAF - Transformation Domains:

• Technology: using the cloud to migrate and modernize legacy infrastructure, aplications, data and analyticas platforms;
• Process: digitizing, automating and optimizing your business operations:
  • Leveraging new data ad analytics platforms to create actionable insights;
  • Using machine learning (ML) to improve your customer service experience;
• Organization: Reimagining your operating model:
  • Organizing your teams around products and value streams;
  • leveraging agile methods to rapidly iterate and evolve;
• Product: reimagining your business model by creating new value propositions (products & services) and revenue models.

AWS Right sizing: is the process of matching instance types and sizes to your workload performance and capacity requirements at lowest possible cost.

• APN Technology Partners: Independent Software Vendors (ISVs), tools providers, platform providers, and others;
• APN Consulting Partners: System Integrators (SIs), agencies, consultancies, Managed Service Providers (MSPs), and others;
• APN Training Partners: a breadth of AWS Training options for learners of all levels, also provides classroom and digital offerings, and live instructors, on-demand courses. Finds who can help you learn AWS.

AWS IQ: quickly find professioal help for your AWS projects. Engage and pay AWS Certified third-party experts for on-demand project work. Video-conferencing, contract management, secure collaboration, integrated billing.

AWS re:Post: AWS-managed Q&A service.

AWS Managed Services (AMS) provides infrastructure and application support on AWS. Offers a team of AWS experts who manage and operate your infrastructure for security, reliability and abailability.

AWS Global Infrastructure:

AWS Regions: is a physical location around the world where we cluster data centers. We call each group of logical data centers an Availability Zone. Each AWS Region consists of a minimum of three, isolated, and physically separate AZs within a geographic area.

• AWS has Regions all around the world;
• Names can be us-east-1, eu-west-2..;
• A region is a cluster of data centers;
• Most AWS services are region-scoped.

How to choose an AWS Region:

• Compliance with data governnance and legal requirements: data never leaves a region without your explicit permission;
• Proximity to customers: reduced latency;
• Available services with a Region: new services and new features aren’t available in every Region;
• Pricing: pricing varies region to region and is transparent in the service pricing page.

AWS Availability Zones (AZ): is one or more discrete data centers with redundant power, networking, and connectivity in an AWS Region. AZs give customers the ability to operate production applications and databases that are more highly available, fault tolerant, and scalable than would be possible from a single data center.

• Each region has many availability zones (min 3, max 6): ap-southeast-2a, ap-southeast-2b, ap-southeast-2c;
• Each availability zone (AZ) is one or more discrete data centers with redundant power, networking and connectivity;
• They’re separate from each other, so that they’re isolated from disasters;
• They’re connected with high bandwidth, ultra-low latency networking.

AWS Local Zone location is an extension of an AWS Region where you can run your latency sensitive applications using AWS services such as Amazon Elastic Compute Cloud, Amazon Virtual Private Cloud, Amazon Elastic Block Store, Amazon File Storage, and Amazon Elastic Load Balancing in geographic proximity to end-users.

AWS Edge Locations (Point of Presence): is a site that Amazon CloudFront uses to store cached copies of your content closer to your customers for faster delivery.

• Amazon has 400+ Points of Presence (400+ Edge Locations & 10+ Regional Caches) in 90+ cities across 40+ countries;
• Content is delivered to end users with lower latency.

AWS WaveLenght are infrastructure deplaoyments, embedded within the telecommunications providers’ datacenters at the edge of the 5G networks.

AWS Outposts are “server racks” that offers the same AWS infrastructure, services, APIs & tools to build your own applications on-premises just as in the cloud. AWS will setup and manage “Outpost racks” within your on-premises infrastructure. Customer is responsible of the Outposts Rack physical security.

• Low-latency access to on-premises systems;
• Local data processing;
• Data residency;
• Easier migration from on-premises to the cloud;
• Fully managed service.
• Supported services on Outposts: EC2, EBS, S3, EKS, ECS, RDS, EMR

Service: AWS offers a broad set of global cloud-based products including compute, storage, database, analytics, networking, machine learning and AI, mobile, developer tools, IoT, security, enterprise applications, and much more.

Tools to access AWS Services:

• AWS Management Console: WEB-UI management tool (protected by password + MFA);
• AWS CLI: direct access to the public APIs of AWS services via command-line shell;
• AWS SDK: language specific APIs (set of libraries), enables access and manage AWS services programmatically (embedded in application).

AWS Shared Responsibility Model:

• Customer responsibility for the security IN the cloud: Customers are responsible for the security of everything that they create and put in the AWS Cloud;
  • EC2 instances:
    • Customer is responsible for management of the guest OS (including security patches and updates), firewall & network configuration, IAM;
    • Encrypting application data.
  • S3:
    • Bucket configuration;
    • Bucket policy / public setting;
    • IAM user and roles;
    • Enabling encryption.
• AWS responsibility for the security OF the cloud: AWS operates, manages, and controls the components at all layers of infrastructure;
  • Protecting infrastructure (hardware, software, facilities and networking):
  • Managed services (like S3, DynamoDB, RDS, etc);
  • S3:
    • Guarantee unlimited storage;
    • Guarantee encryption;
    • Ensure separation of the data between different cutomers;
    • Ensure AWS employees can’t access customer’s data.
• Shared controls:
  • Patch management, Configuration Management, Awareness & Training.

AWS Identity and Access Management:

IAM (Identity and Access Management) enables you to securely control access to Amazon Web Services services and resources for your users.
Users are people within your organization, and can be grouped. Users don’t have to belong to a group, and user can belong to multiple groups. Groups only contain users, not other groups. Root privileges has complete access to all AWS services and resources. Root account created by default.

Actions that can be performed only by the root user:

• Change account settings (account name, email address, root user password, root user access keys);
• View certain tax invoices;
• Close your AWS account;
• Restore IAM user permissions;
• Change or cancel AWS Support plan;
• Register as a seller in the Reserved Instance Marketplace;
• Configure an Amazon S3 bucket to enable MFA;
• Edit or delete an Amazon S3 bucket policy that includes an invalid VPC ID or VPC endpoint ID;
• Sign up for GovCloud.

Policies define the permissions of the users and groups described in JSON documents.

IAM Roles for services set of permission attached to some AWS services to perform actions on your behalf (EC2, Lambda, CloudFormation).

IAM Policy is a JSON document that defines permissions. ┌─────────────────────────────────────────────────────────────┐ │ IAM POLICY │ ├─────────────────────────────────────────────────────────────┤ │ Version (Required) - Policy language version │ │ Id (Optional) - Policy identifier │ │ Statement (Required) - Array of permission blocks │ │ ├── Sid (Optional) - Statement ID │ │ ├── Effect (Required) - “Allow” or “Deny” │ │ ├── Principal (Required*) - Who the policy applies to │ │ ├── Action (Required) - What actions are permitted │ │ ├── Resource (Required) - Which resources are affected │ │ └── Condition (Optional) - When the policy applies │ └─────────────────────────────────────────────────────────────┘

• Principal is required for resource-based policies, not identity-based

Policy Types:

• Identity-based - Attached to users, groups, or roles (no Principal needed)
• Resource-based - Attached to resources like S3 buckets (Principal required)

Best IAM practices:

• Root account shouldn’t be used or shared;
• In IAM Policies apply the least privilege principle: don’t give more permissions than a user needs;
• Create individual IAM users for each person who needs to access AWS. One user - one physical user;
• Assign users to groups and assign permissions to Groups;
• IAM roles are ideal for situations in which access to services or resources needs to be granted temporarily, instead of long-term.

IAM Credentials Report (account-level) a report that lists all your account’s users and the status of their various; IAM Access Advisor (user-level) - access advisor shows the service permissions granted to a user and when those services were last accessed. Can be used to revise policies.

AWS Resource Access Manager (AWS RAM) helps you securely share your resources across AWS accounts, within your organization or organizational units (OUs) and with IAM roles and users for supported resource types (Aurora, VPC Subnets, Transit Gateway, Route53, EC2 Dedicated Hosts, License Manager Configurations, etc). Avoid resource duplication.

AWS Service Catalog self-portal to launch a set of authorized products pre-defined by admins.

AWS STS (Security Token Service): enables you to create temporary, limited-privileges credentials to access your AWS resources.

Session Policies: Optional policy passed when calling AssumeRole — further restricts the role’s permissions for that session only.

Amazon Cognito:

User → Cognito User Pool → JWT Token → Cognito Identity Pool → AWS Credentials → AWS Services

⚠️ Exam trap: User Pools = authentication (who are you?), Identity Pools = authorization (AWS access)

IAM Access Analyzer:

• Identifies resources shared with external entities (S3, IAM roles, KMS, Lambda, SQS)
• Validates IAM policies against best practices
• Generates policies based on access activity (least privilege)
• Zone of trust = Organization or Account

AWS Directory Services:

┌─────────────────────────────────────────────────────────────────────────────┐
│                       AWS Directory Services                                │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  1. AWS Managed Microsoft AD (two-way trust)                                │
│                                                                             │
│       ┌──────────┐      trust       ┌──────────────────┐                    │
│  auth │          │◄────────────────►│  AWS Managed AD  │ auth               │
│  ◄────┤ On-Prem  │                  │       [MS]       ├────►               │
│       │    AD    │                  └──────────────────┘                    │
│       └──────────┘                                                          │
│                                                                             │
│  2. AD Connector (proxy only - NO users stored in AWS)                      │
│                                                                             │
│       ┌──────────┐      proxy       ┌──────────────────┐                    │
│       │          │◄────────────────►│   AD Connector   │ auth               │
│       │ On-Prem  │                  │       [⚡]        ├────►               │
│       │    AD    │                  └──────────────────┘                    │
│       └──────────┘                                                          │
│                                                                             │
│  3. Simple AD (standalone - NO on-prem connection)                          │
│                                                                             │
│                                     ┌──────────────────┐                    │
│                          ❌         │    Simple AD     │ auth               │
│              (no on-prem)           │       [DB]       ├────►               │
│                                     └──────────────────┘                    │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

⚠️ Exam trap: AD Connector is just a proxy — it does NOT store users, only redirects authentication to on-prem AD.

AWS Organizations (Global service):

┌─────────────────────────────────────────────────────────────────────┐
│                    Root Organizational Unit (OU)                    │
│  ┌────────────────┐                                                 │
│  │  Management    │  ← Full admin power, SCPs do NOT apply here     │
│  │  Account       │                                                 │
│  └────────────────┘                                                 │
│                                                                     │
│  ┌──────────────────────┐      ┌──────────────────────────────────┐ │
│  │     OU (Dev)         │      │          OU (Prod)               │ │
│  │  ┌────┐  ┌────┐      │      │  ┌────┐  ┌────┐                  │ │
│  │  │Acct│  │Acct│      │      │  │Acct│  │Acct│                  │ │
│  │  └────┘  └────┘      │      │  └────┘  └────┘                  │ │
│  │   Member Accounts    │      │  ┌────────────┐ ┌──────────────┐ │ │
│  └──────────────────────┘      │  │  OU (HR)   │ │ OU (Finance) │ │ │
│                                │  │ ┌──┐ ┌──┐  │ │  ┌──┐ ┌──┐   │ │ │
│                                │  │ │  │ │  │  │ │  │  │ │  │   │ │ │
│                                │  │ └──┘ └──┘  │ │  └──┘ └──┘   │ │ │
│                                │  └────────────┘ └──────────────┘ │ │
│                                └──────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘

• Member accounts can only be part of ONE organization
• Consolidated Billing - single payment method, volume discounts
• Shared Reserved Instances and Savings Plans across accounts
• API available to automate account creation

Consolidated Billing Benefits:

• Combined Usage across all accounts → volume pricing discounts
• One Bill for all accounts in the Organization
• Pooling of Reserved EC2 instances for optimal savings

Multi-Account Strategies:

• Account per department / cost center / dev-test-prod
• Regulatory restrictions enforcement (via SCP)
• Resource isolation (separate VPCs)
• Separate per-account service limits
• Isolated logging account (CloudTrail → central S3, CloudWatch → central account)

Service Control Policies (SCP):

• Whitelist or blacklist IAM actions at OU or Account level
• Must have explicit Allow from root → through each OU → to target account
• Affects ALL Users and Roles in account, including Root user
• Does NOT apply to Management Account (full admin power always)
• Does NOT affect service-linked roles

⚠️ Exam trap: SCPs don’t affect Management Account — if question asks “restrict ALL accounts”, Management Account is still unrestricted!

⚠️ Exam trap: Service-linked roles are NOT affected by SCPs — they always work!

What SCPs CANNOT do:

• ❌ Restrict the Management Account
• ❌ Affect service-linked roles
• ❌ Grant permissions (only restrict what’s already allowed)
• ❌ Affect actions in the Management Account itself

AWS Organizations – Tag Policies:

• Standardize tags across resources in an AWS Organization
• Define allowed tag keys and values
• Prevent non-compliant tagging operations (no effect on resources without tags)
• Generate compliance reports for tagged/non-compliant resources
• Use EventBridge to monitor non-compliant tags
• Helps with Cost Allocation Tags and Attribute-Based Access Control

IAM Conditions - restrict API calls based on:

⚠️ Exam trap: Fake condition keys! Only these are real:

• ✅ aws:RequestedRegion, aws:SourceIp, aws:SourceVpc, aws:SourceVpce
• ❌ aws:SourceRegion, aws:Region, ec2:SourceRegion — DON’T EXIST

S3 Bucket Policies vs IAM Policies:

S3 Access Decision Logic:

IAM Policy ALLOWS  +  S3 Bucket Policy ALLOWS  →  ACCESS ✅
IAM Policy ALLOWS  +  S3 Bucket Policy (silent) →  ACCESS ✅
IAM Policy (silent) +  S3 Bucket Policy ALLOWS  →  ACCESS ✅  (if same account)
IAM Policy DENIES   OR  S3 Bucket Policy DENIES →  DENIED ❌

Cross-account: BOTH must explicitly Allow

Common S3 Policy Conditions:

Example - Require HTTPS:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": "arn:aws:s3:::bucket/*",
  "Condition": {
    "Bool": { "aws:SecureTransport": "false" }
  }
}

⚠️ Exam trap: "Principal": "*" = anonymous access. "Principal": {"AWS": "*"} = any authenticated AWS user.

⚠️ Exam trap: Cross-account S3 access — bucket policy must explicitly allow the external principal AND the external account needs IAM permissions.

⚠️ Exam trap: S3 ARN patterns matter!

• arn:aws:s3:::bucket → Bucket-level actions (ListBucket, GetBucketLocation)
• arn:aws:s3:::bucket/* → Object-level actions (GetObject, PutObject, DeleteObject)
• Missing /* = Access Denied for object operations!

IAM Roles vs Resource-Based Policies (Cross-Account Access):

Two ways to access S3 in another account:

Option 1: Role as Proxy (AssumeRole)
┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│    User      │─────►│    Role      │─────►│   Amazon S3  │
│  Account A   │      │  Account B   │      │  Account B   │
└──────────────┘      └──────────────┘      └──────────────┘
                      (become this role,
                       lose Account A perms)

Option 2: Resource-Based Policy (S3 Bucket Policy)
┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│    User      │─────►│  S3 Bucket   │─────►│   Amazon S3  │
│  Account A   │      │   Policy     │      │  Account B   │
└──────────────┘      └──────────────┘      └──────────────┘
                      (grants access to
                       Account A user directly,
                       keeps Account A perms)

Example: User in Account A needs to scan DynamoDB in Account A AND dump to S3 in Account B → Use resource-based policy on S3 (keeps DynamoDB permissions)

EventBridge Target Permissions:

Memory trick: “Can the target say WHO is allowed to invoke it?”

• YES → Resource-based policy (Lambda, SNS, SQS, S3, API Gateway)
• NO → EventBridge needs IAM Role to assume

Memory hook: “SLSS + API GW” = Resource-based (SNS, Lambda, SQS, S3, API Gateway) Memory hook: “KEES” = IAM Role needed (Kinesis, EC2 Auto Scaling, ECS, SSM)

⚠️ Exam trap: Lambda = resource-based, Kinesis = IAM role. Don’t mix them up!

IAM Permission Boundaries:

• Supported for users and roles only (NOT groups)
• Sets MAXIMUM permissions an IAM entity can get
• Effective permissions = intersection of Identity Policy ∩ Permission Boundary ∩ SCP

┌───────────────────────────────────────────────────────────┐
│                                                           │
│      ┌─────────────┐         ┌─────────────────┐          │
│      │Organizations│         │   Permissions   │          │
│      │    SCP      │         │    Boundary     │          │
│      │      ✓      │    ✓    │       ✓         │          │
│      │         ┌───┴─────────┴───┐             │          │
│      │         │                 │             │          │
│      └─────────┤   Effective     ├─────────────┘          │
│                │   Permissions   │                        │
│      ┌─────────┤       ✓         ├─────────────┐          │
│      │         │                 │             │          │
│      │         └───┬─────────────┘             │          │
│      │  Identity   │         ✓                 │          │
│      │   Policy    │                           │          │
│      │      ✓      │                           │          │
│      └─────────────┘                           │          │
│                                                           │
└───────────────────────────────────────────────────────────┘

Use Cases:

• Delegate IAM user creation to non-admins (within boundaries)
• Allow developers to self-assign policies without privilege escalation
• Restrict specific user (vs SCP restricts whole account)

⚠️ Exam trap: Permission Boundaries do NOT apply to groups! Only users and roles.

IAM Policy Evaluation Logic (order matters):

                         ┌─────────────────┐
                         │  Start: DENY    │
                         └────────┬────────┘
                                  ▼
                    ┌─────────────────────────┐
                    │   Explicit Deny?        │──── YES ────► DENY ❌
                    └─────────────┬───────────┘
                                  │ NO
                                  ▼
                    ┌─────────────────────────┐
                    │   In Org with SCP?      │──── NO ─────► Skip to Resource-Based
                    └─────────────┬───────────┘
                                  │ YES
                                  ▼
                    ┌─────────────────────────┐
                    │   SCP Allows?           │──── NO ─────► DENY ❌ (implicit)
                    └─────────────┬───────────┘
                                  │ YES
                                  ▼
                    ┌─────────────────────────┐
                    │   Resource-Based        │──── ALLOW + same account ──► ALLOW ✅
                    │   Policy Allows?        │
                    └─────────────┬───────────┘
                                  │ (continue if cross-account or no resource policy)
                                  ▼
                    ┌─────────────────────────┐
                    │   Identity Policy       │──── NO ─────► DENY ❌ (implicit)
                    │   Allows?               │
                    └─────────────┬───────────┘
                                  │ YES
                                  ▼
                    ┌─────────────────────────┐
                    │   Permission Boundary   │──── NO ─────► DENY ❌ (implicit)
                    │   Allows? (if exists)   │
                    └─────────────┬───────────┘
                                  │ YES
                                  ▼
                    ┌─────────────────────────┐
                    │   Session Policy        │──── NO ─────► DENY ❌ (implicit)
                    │   Allows? (if exists)   │
                    └─────────────┬───────────┘
                                  │ YES
                                  ▼
                         ┌─────────────────┐
                         │   ALLOW ✅      │
                         └─────────────────┘

Key Rules:

• Explicit Deny ALWAYS wins (checked first)
• Must have Allow at EVERY applicable level
• Same-account: Resource-based Allow alone can grant access
• Cross-account: BOTH sides must Allow

AWS IAM Identity Center (successor to AWS SSO):

• One login for: AWS accounts, Business apps (Salesforce, Box, M365), SAML2.0 apps, EC2 Windows
• Identity providers: Built-in store, Active Directory, OneLogin, Okta

Active Directory Integration:

Option 1: AWS Managed Microsoft AD (out-of-box integration)
┌──────────────────┐              ┌─────────────────────┐
│  IAM Identity    │───connect───►│ AWS Managed         │
│  Center          │              │ Microsoft AD        │
└──────────────────┘              └─────────────────────┘

Option 2: Self-Managed AD (two approaches)
┌──────────────────┐     ┌─────────────────┐    two-way trust    ┌────────────┐
│  IAM Identity    │─────│ AWS Managed     │◄──────────────────►│ On-Prem AD │
│  Center          │     │ Microsoft AD    │                     └────────────┘
└────────┬─────────┘     └─────────────────┘
         │
         │               ┌─────────────────┐       proxy          ┌────────────┐
         └───────────────│  AD Connector   │◄────────────────────►│ On-Prem AD │
                         └─────────────────┘                      └────────────┘

Permission Sets: Collection of IAM Policies assigned to users/groups for AWS access ABAC: Fine-grained permissions based on user attributes (cost center, title, locale)

AWS Control Tower - multi-account governance:

• Runs on top of AWS Organizations
• Automates environment setup and ongoing policy management

Guardrails (ongoing governance):

Detective Guardrail Flow:

┌─────────────────────────────────────────────────────────────────────┐
│  AWS Control Tower                                                  │
│  ┌─────────────┐                                                    │
│  │ Guardrail   │ trigger                                            │
│  │ (Detective) ├───────────►┌─────┐ notify  ┌───────┐               │
│  │             │(NON_COMPLIANT)│ SNS │────────►│ Admin │             │
│  │ AWS Config  │             └──┬──┘         └───────┘              │
│  └──────┬──────┘                │                                   │
│         │ monitor               │ invoke                            │
│         ▼                       ▼                                   │
│  ┌────────────────┐       ┌──────────┐                              │
│  │ Member Accounts│◄──────│  Lambda  │ remediate (add tags)         │
│  └────────────────┘       └──────────┘                              │
└─────────────────────────────────────────────────────────────────────┘

⚠️ IAM Exam Traps Summary

🎯 IAM Quick Decision Table

🎯 MASTER SUMMARY: IAM & Organizations Exam Guide

Part 1: Core Principles (Understand WHY → Derive WHAT)

Principle 1: Implicit Deny by Default

Everything starts DENIED. You must explicitly Allow. This applies to:

• IAM policies
• SCPs
• Permission Boundaries

Why? Security principle — if you forget something, it’s denied (safe default).

Derive: If SCP only allows EC2 → everything else is denied. No need to memorize “deny lists.”

Principle 2: Explicit Deny ALWAYS Wins

No matter how many Allows exist, one Deny = blocked.

Why? Prevents privilege escalation — you can always restrict, never override a restriction.

Derive: To block an action, just add Deny anywhere in the chain. Order doesn’t matter for Deny.

Principle 3: Permissions = Intersection, Not Union

Effective permissions = what ALL layers allow together.

SCP ∩ Permission Boundary ∩ Identity Policy = Effective Permissions

Why? Each layer is a guardrail — you can only narrow, never expand beyond any layer.

Derive: If SCP allows S3+EC2, but Identity Policy only allows S3 → only S3 works.

Principle 4: Management Account is Untouchable

SCPs never apply to Management Account. It always has full power.

Why? Someone must be able to fix things if SCPs lock everyone out.

Derive: “Restrict ALL accounts” questions — Management Account is the exception.

Principle 5: Scope Determines Tool

• Whole account restriction → SCP
• Specific user/role restriction → Permission Boundary
• Action-level control → IAM Policy + Conditions

Why? Different granularity needs different tools.

Derive: “Prevent developers from escalating privileges” → Permission Boundary (user-level, not account-level).

Principle 6: Cross-Account = Two Choices

1. Assume Role → Give up original identity, become the role
2. Resource-based Policy → Keep original identity + access target

Why? Sometimes you need both source AND target access (e.g., DynamoDB scan → S3 dump).

Derive: “Access DynamoDB in Account A AND S3 in Account B” → Resource-based policy on S3.

Principle 7: Temporary Credentials > Long-term

STS provides temporary, auto-expiring credentials.

Why? Reduces blast radius of compromise — credentials expire.

Derive: Cross-account access, federation, MFA → all use STS behind the scenes.

Principle 8: Authentication ≠ Authorization

• Cognito User Pools = Authentication (who are you?)
• Cognito Identity Pools = Authorization (what can you access?)
• IAM Identity Center = Both for AWS accounts

Why? Separation of concerns — different systems handle different problems.

Derive: “Millions of mobile users need S3 access” → User Pool (auth) + Identity Pool (AWS creds).

Principle 9: Service-Linked Roles are Special

SCPs don’t affect them. They’re created BY AWS FOR AWS services.

Why? AWS services need guaranteed permissions to function.

Derive: “SCP blocks everything but service still works” → It’s using a service-linked role.

Principle 10: IAM is Global

No region selection. Users, roles, policies exist everywhere.

Why? Identity should be consistent — you’re YOU regardless of region.

Derive: “Create IAM user in us-east-1” → Trick question, IAM has no region.

Part 2: Decision Trees

Cross-Account Access Decision

Need cross-account access?
    │
    ├─► Need BOTH source + target permissions?
    │       │
    │       └─► YES → Resource-based policy
    │
    └─► Need different identity/permissions?
            │
            └─► YES → Assume Role

Restriction Scope Decision

What to restrict?
    │
    ├─► Entire account(s)?
    │       │
    │       └─► SCP (attach to OU or Account)
    │
    ├─► Specific user/role?
    │       │
    │       └─► Permission Boundary
    │
    └─► Specific actions with conditions?
            │
            └─► IAM Policy with Conditions

Identity Provider Decision

Who needs access?
    │
    ├─► Internal employees to AWS accounts?
    │       │
    │       └─► IAM Identity Center
    │
    ├─► External users (millions, mobile/web)?
    │       │
    │       └─► Cognito
    │
    └─► Corporate IdP (SAML)?
            │
            ├─► To AWS Console → IAM Identity Center
            └─► Programmatic → AssumeRoleWithSAML

The “CANNOT” List

Part 3: Scenario Pattern Recognition

Pattern: “Restrict ALL member accounts from using a service”

Keywords: all accounts, prevent, organization-wide, block service Answer: SCP at Root OU level Why: SCPs cascade down OUs. Root OU = all member accounts (not Management).

Pattern: “Allow developers to create IAM users but prevent privilege escalation”

Keywords: delegate, self-service, prevent escalation, limit what they can create Answer: Permission Boundary Why: Boundary limits max permissions of created entities.

Pattern: “User needs to access resources in two accounts simultaneously”

Keywords: scan + dump, read from A write to B, both accounts Answer: Resource-based policy (on target resource) Why: AssumeRole would lose access to source account.

Pattern: “Millions of mobile app users need S3 access”

Keywords: mobile, web app, millions, external users, S3/DynamoDB access Answer: Cognito User Pools + Identity Pools Why: User Pools authenticate, Identity Pools give temporary AWS credentials.

Pattern: “Corporate employees need SSO to multiple AWS accounts”

Keywords: SSO, single sign-on, multiple accounts, employees, SAML, Active Directory Answer: IAM Identity Center Why: Built for this — integrates with AD, manages permission sets across accounts.

Pattern: “Detect untagged resources across organization”

Keywords: detect, compliance, untagged, non-compliant, monitor Answer: Control Tower Detective Guardrail (uses AWS Config) Why: Detective = monitoring (not blocking). Uses Config rules.

Pattern: “Prevent creating resources in unapproved regions”

Keywords: prevent, block, region restriction, all accounts Answer: SCP with aws:RequestedRegion condition (or Control Tower Preventive Guardrail) Why: Preventive = blocking. SCPs stop the action.

Pattern: “Share VPC subnets across accounts”

Keywords: share, subnets, cross-account, Transit Gateway, avoid duplication Answer: AWS RAM (Resource Access Manager) Why: RAM shares resources without duplication.

Pattern: “Find resources shared with external accounts”

Keywords: identify, find, external access, shared externally, audit Answer: IAM Access Analyzer Why: Analyzes policies to find external principal access.

Pattern: “Temporary credentials for cross-account access”

Keywords: temporary, cross-account, assume, programmatic Answer: STS AssumeRole Why: Returns temporary credentials for the target role.

Pattern: “Require MFA for sensitive operations”

Keywords: MFA, multi-factor, sensitive, delete, critical Answer: IAM Policy Condition: aws:MultiFactorAuthPresent Why: Condition key checks MFA status.

Pattern: “Standardize tag format across organization”

Keywords: standardize, tags, enforce, format, organization-wide Answer: Tag Policies Why: Define allowed tag keys/values, prevent non-compliant tags.

Pattern: “Connect IAM Identity Center to on-premises AD”

Keywords: on-premises, Active Directory, Identity Center, trust Answer: Two-way trust with AWS Managed Microsoft AD, OR AD Connector (proxy) Why: Can’t connect directly — need AWS AD service in between.

Part 4: Quick Reference Tables

SCP vs Permission Boundary vs IAM Policy

Directory Services Comparison

STS API Quick Reference

Part 5: Ultimate Instant-Answer Table

Part 6: Elimination Checklist

□ Is it about restricting accounts?
  → Yes = Think SCP
  → But Management Account? = SCP won't work

□ Is it about restricting a specific user/role?
  → Yes = Think Permission Boundary
  → Is it a group? = Permission Boundary won't work

□ Is it cross-account access?
  → Need both source + target access? = Resource-based policy
  → Need different identity? = Assume Role

□ Is it millions of external users?
  → Yes = Cognito (not IAM users)
  → Need AWS credentials? = Identity Pools required

□ Is it corporate employees to AWS?
  → Yes = IAM Identity Center

□ Is it about compliance/detection?
  → Yes = Detective Guardrail / AWS Config

□ Is it about blocking/prevention?
  → Yes = Preventive Guardrail / SCP

🏆 The Golden Rules

1. Implicit Deny — Everything denied until explicitly allowed
2. Explicit Deny Wins — One Deny overrides all Allows
3. Intersection Rule — Effective = SCP ∩ Boundary ∩ Policy
4. Management Account Exception — SCPs don’t touch it
5. Service-Linked Roles Exception — SCPs don’t affect them
6. Permission Boundaries ≠ Groups — Only users and roles
7. AssumeRole = Identity Switch — You become the role, lose original
8. Resource-Based = Keep Both — Keep original + access target
9. User Pools ≠ AWS Access — Need Identity Pools for credentials
10. IAM = Global — No region, ever
11. SCP Allow = Everything Else Denied — Like IAM, implicit deny default
12. FullAWSAccess SCP — Default SCP that allows everything (remove carefully!)

Amazon VPC:

VPC (Virtual Private Cloud) is a service that lets you launch AWS resources in a logically isolated virtual network that you define.

• Max 5 VPCs per region (soft limit)
• Max 5 CIDRs per VPC
• CIDR range: min /28 (16 IPs) → max /16 (65,536 IPs)
• Only private IPv4 ranges allowed:
  • 10.0.0.0/8 (10.0.0.0 – 10.255.255.255)
  • 172.16.0.0/12 (172.16.0.0 – 172.31.255.255)
  • 192.168.0.0/16 (192.168.0.0 – 192.168.255.255)
• VPC CIDR should NOT overlap with other networks (e.g., corporate)

CIDR – IPv4:

CIDR (Classless Inter-Domain Routing) — method for allocating IP addresses. Used in Security Groups, NACLs, and all AWS networking.

⚠️ Exam trap: “Need 29 IPs for EC2” → /27 (32 IPs) is NOT enough! AWS reserves 5 IPs per subnet (first 4 + last 1) → 32 - 5 = 27 < 29. Use /26 (64 - 5 = 59 ✓)

AWS Reserved IPs per subnet (5):

• .0 — Network Address
• .1 — VPC Router
• .2 — Amazon DNS
• .3 — Future use
• .255 — Broadcast (not supported, but reserved)

IP Addresses:

• IPv4 (4.3 billion addresses)
• IPv6 (3.4 × 10³⁸ addresses) — every IPv6 address in AWS is public and internet-routable (no private range)
• Elastic IP: fixed public IPv4 address attached to EC2 instance

IPv6 in VPC:

• IPv4 cannot be disabled for VPC and subnets
• Enable IPv6 to operate in dual-stack mode (IPv4 + IPv6)
• EC2 gets at least a private IPv4 + a public IPv6
• Communicate via either IPv4 or IPv6 to internet through IGW

⚠️ Exam trap: “Can’t launch EC2 in subnet” → NOT because of IPv6 (space is huge). It’s because no available IPv4 in the subnet → solution: create a new IPv4 CIDR in your subnet.

Subnets:

Subnets partition your network inside VPC.

• Public subnet — accessible from the internet (has route to IGW)
• Private subnet — NOT accessible from the internet
• Route Tables — define access to the internet and between subnets

Internet Gateway (IGW):

Internet gateway helps VPC instances connect with the internet (public subnets have a route to IGW).

• Scales horizontally, highly available and redundant
• Created separately from VPC
• One VPC ↔ One IGW (1:1 mapping)
• IGW alone does NOT allow internet access → Route Tables must be edited!

NAT (Network Address Translation):

NAT allows instances in private subnets to access the internet while remaining private.

Private Subnet EC2 ──► NAT (Public Subnet) ──► IGW ──► Internet
       10.0.0.20          EIP: 12.34.56.78         ▲
                           (translates src IP)      │
                                                    │
                    Response comes back to NAT ◄────┘
                    NAT forwards to 10.0.0.20

NAT Instance (self-managed, outdated but still on exam):

• EC2 instance with special AMI in public subnet
• Must disable Source/Destination Check on EC2
• Must have Elastic IP attached
• Must configure Route Tables (private subnet → NAT Instance)
• You manage Security Groups, patching, HA (ASG + multi-AZ)
• Can be used as Bastion Host

NAT Gateway (AWS-managed):

• Created in specific AZ, uses Elastic IP
• 5 Gbps → auto-scales to 100 Gbps
• Can’t be used by instances in the same subnet
• Requires IGW (Private Subnet → NATGW → IGW)
• No Security Groups to manage

NAT Gateway HA: Resilient within single AZ only → create one NATGW per AZ for fault tolerance. No cross-AZ failover needed.

NAT Gateway vs NAT Instance:

⚠️ Exam trap: “NAT + Security Groups” → NAT Instance (NAT Gateway has NO SGs). “NAT + Bastion Host” → also NAT Instance.

⚠️ Exam trap: “Private instances need internet, managed, HA” → NAT Gateway. NAT Instance is legacy — only pick it if question says “existing NAT Instance” or needs SG/Bastion.

Bastion Host:

Bastion Host = EC2 instance in public subnet used to SSH into private instances.

Users ──SSH (port 22)──► Bastion Host (Public Subnet) ──SSH──► EC2 (Private Subnet)
                         BastionHost-SG                        LinuxInstance-SG
                         Inbound: port 22                      Inbound: port 22
                         from corp CIDR                        from BastionHost-SG

• Bastion SG: allow inbound port 22 from restricted CIDR (e.g., corporate public IP)
• Private EC2 SG: allow inbound port 22 from Bastion Host SG or Bastion’s private IP

⚠️ Exam trap: “SSH into private EC2” → Bastion Host (or SSM Session Manager for no-SSH approach). NOT NAT Gateway — NAT is for outbound internet only.

Security Groups vs NACLs:

Network ACL (NACL) — firewall at subnet level. Can have ALLOW and DENY rules. Rules only include IP addresses. Automatically applies to all instances in the subnet. STATELESS: Return traffic must be explicitly allowed. Checks packets both ways.

• Default NACL: allows ALL inbound and outbound traffic
• Custom NACL: denies ALL traffic by default until you add rules

Security Groups — firewall at instance (ENI) level. Can have only ALLOW rules. Rules include IP addresses and other security groups. STATEFUL: Return traffic is automatically allowed.

• Default SG: denies all inbound, allows all outbound
• Inbound/Outbound rules are separate — they control who initiates the connection, not who responds
• Applies to any service with an ENI: EC2, RDS, Aurora, ElastiCache, ECS (awsvpc), Lambda (in VPC), EFS mount targets, ALB, NLB, VPC Endpoints (Interface)

Inbound port 22 allowed:   Outside ──SSH──► Your EC2  ✅ (response auto-allowed out)
Outbound port 22 allowed:  Your EC2 ──SSH──► Outside  ✅ (response auto-allowed in)

⚠️ Exam trap: “Default NACL” → allows all traffic. “Custom NACL” → denies all by default. Don’t confuse them!

Ephemeral Ports:

• Client connects to a defined port (e.g., 443), response comes back on a random ephemeral port
• NACL must allow ephemeral port range for return traffic (because stateless!)
• Windows: 49152 – 65535 | Linux: 32768 – 60999

Client (11.22.33.44)                          Web Server (55.66.77.88)
    ──► Src Port: 50105, Dest Port: 443 ──►      (fixed port 443)
    ◄── Dest Port: 50105, Src Port: 443 ◄──      (response to ephemeral port)

NACL with Ephemeral Ports — Example (Web → DB):

  Web Subnet (Public)                              DB Subnet (Private)
  ┌──────────────────┐                             ┌─────────────────┐
  │    EC2 (Web)     │                             │ RDS (port 3306) │
  │                  │                             │                 │
  └────────┬─────────┘                             └────────┬────────┘
           │                                                │
        Web-NACL                                         DB-NACL
     ┌───────────────┐                           ┌───────────────┐
     │ OUTBOUND:     │    ── request ──►         │ INBOUND:      │
     │  port 3306    │                           │  port 3306    │
     │  to DB CIDR   │                           │  from Web CIDR│
     │               │                           │               │
     │ INBOUND:      │    ◄── response ──        │ OUTBOUND:     │
     │  port 1024-   │                           │  port 1024-   │
     │  65535         │                           │  65535        │
     │  from DB CIDR │                           │  to Web CIDR  │
     └───────────────┘                           └───────────────┘

4 NACL rules needed (because stateless = each direction, each NACL):

⚠️ Exam trap: With SGs you’d only need 2 rules (allow 3306 each side) — stateful handles the rest. With NACLs you need 4 rules — don’t forget the ephemeral port rules for return traffic!

⚠️ Exam trap: “NACL blocking return traffic” → you forgot to allow ephemeral ports outbound (server side) or inbound (client side). SGs don’t have this problem (stateful).

VPC Flow Logs:

VPC Flow Logs capture information about IP traffic going into your interfaces:

• VPC Flow Logs
• Subnet Flow Logs
• Elastic Network Interface (ENI) Flow Logs
• Captures network info from AWS managed interfaces: ELB, RDS, ElastiCache, Redshift, WorkSpaces, NATGW, Transit Gateway
• Data can go to S3, CloudWatch Logs, Kinesis Data Firehose

Flow Log Syntax:

version account-id interface-id srcaddr dstaddr srcport dstport packets bytes start end protocol action log-status
2 123456789010 eni-1235b8ca srcIP dstIP 20641 22 6 20 4249 ... ACCEPT OK
2 123456789010 eni-1235b8ca srcIP dstIP 49761 3389 6 20 4249 ... REJECT OK

Key fields:

• srcaddr / dstaddr — identify problematic IPs
• srcport / dstport — identify problematic ports
• action — ACCEPT or REJECT (due to SG or NACL)

Troubleshoot SG vs NACL using Flow Logs (ACTION field):

Memory trick: “ACCEPT then REJECT” = always NACL (stateless blocks return traffic). SG would never block return traffic (stateful).

Flow Logs Architectures:

• Flow Logs → CloudWatch Logs → Contributor Insights → Top-10 IP addresses
• Flow Logs → CloudWatch Logs → Metric Filter (SSH, RDP) → CW Alarm → SNS alert
• Flow Logs → S3 → Athena (SQL queries) → QuickSight (visualization)

VPC Peering:

VPC Peering — privately connect two VPCs using AWS’ network, behave as if same network.

• Must NOT have overlapping CIDRs
• NOT transitive — must create peering for each pair (A↔B, A↔C, B↔C)
• Must update Route Tables in each VPC’s subnets
• Works across different accounts and regions
• Can reference a Security Group in peered VPC (cross-account, same region only)

VPC-A ◄──Peering──► VPC-B ◄──Peering──► VPC-C
  │                                        │
  └──────────Peering (A↔C needed!)─────────┘
         (B does NOT relay traffic)

⚠️ Exam trap: “VPC A peers with B, B peers with C, can A talk to C?” → NO! Not transitive. Need separate A↔C peering. If you need many VPCs connected → use Transit Gateway instead.

VPC Endpoints:

VPC Endpoints connect to AWS services using private network instead of public internet.

• Redundant and scale horizontally
• Remove the need for IGW, NATGW to access AWS services
• Troubleshooting: check DNS Resolution in VPC + check Route Tables

Two types:

Option 1 (costly):     Lambda (VPC) ──► NAT GW ──► IGW ──► DynamoDB (public)
Option 2 (free/better): Lambda (VPC) ──► Gateway Endpoint ──► DynamoDB (private)

⚠️ Exam trap: “S3 or DynamoDB access from VPC” → Gateway Endpoint (free, preferred on exam). Interface Endpoint only when access needed from on-premises (VPN/Direct Connect), different VPC, or different region.

⚠️ Exam trap: “Lambda in VPC can’t reach DynamoDB” → either add NAT GW + IGW, or (better) use VPC Gateway Endpoint for DynamoDB.

⚠️ Exam trap - “VPC resources access SQS/SNS/KMS privately (no internet)”:

• ✅ VPC Interface Endpoint (PrivateLink) — private ENI, traffic stays on AWS network
• ❌ VPN = connects on-prem ↔ AWS, doesn’t solve VPC → AWS service
• ❌ NAT instance/gateway = still routes through public internet
• ❌ Internet Gateway = is the public internet — exactly what they want to avoid

AWS PrivateLink (VPC Endpoint Services):

AWS PrivateLink — expose a service in your VPC to other VPCs privately.

• 3rd party VPC: Network Load Balancer (service provider)
• Customer VPC: ENI (Interface Endpoint, consumer)
• No VPC peering, IGW, NAT, or route tables needed
• Works across accounts

Site-to-Site VPN:

Site-to-Site VPN — encrypted connection between on-premises and AWS over the public internet.

Components:

• Virtual Private Gateway (VGW) — VPN concentrator on AWS side, attached to VPC
  • Can customize ASN (Autonomous System Number)
• Customer Gateway (CGW) — software or physical device on customer side

Setup:

• CGW IP: use public IP of your device (or public IP of NAT device if behind NAT-T)
• Enable Route Propagation for VGW in route table associated with your subnets
• To ping EC2 from on-prem → add ICMP protocol to inbound Security Group rules

AWS VPN CloudHub:

• Secure communication between multiple on-prem sites via multiple VPN connections
• Low-cost hub-and-spoke model over public internet
• Setup: multiple VPN connections on same VGW + dynamic routing + route tables

⚠️ Exam trap: “Ping EC2 from on-premises doesn’t work” → check ICMP allowed in SG inbound + Route Propagation enabled.

Direct Connect (DX):

Direct Connect — dedicated private physical connection from on-premises to AWS.

• Setup at AWS Direct Connect Location (co-location facility)
• Requires Virtual Private Gateway on VPC
• Access both public (S3) and private (EC2) resources on same connection
• Supports IPv4 and IPv6
• Lead time: often > 1 month to establish

Virtual Interfaces (VIFs):

• Private VIF → access VPC resources (EC2 in private subnet)
• Public VIF → access public AWS services (S3, Glacier)
• Transit VIF → access VPCs via Transit Gateway

Corporate DC ──► Customer Router ──► DX Endpoint ──► VPG ──► VPC
                                     (DX Location)
                                      VLAN 1 (Private VIF) ──► EC2
                                      VLAN 2 (Public VIF)  ──► S3, Glacier

Connection Types:

Direct Connect Gateway:

• Connect DX to VPCs in multiple regions (same account)
• One DX connection → DX Gateway → multiple VPCs across regions

Resiliency:

• High resiliency: one connection at multiple DX locations
• Maximum resiliency: separate connections on separate devices at multiple locations

Backup:

• DX fails → backup with another DX (expensive) or Site-to-Site VPN (cheaper)

⚠️ Exam trap: “Private, dedicated, consistent connection” → Direct Connect. “Encrypted over internet” → Site-to-Site VPN. DX is NOT encrypted by default (add VPN on top for encryption).

⚠️ Exam trap: “Improve connection within days/1 week” → NOT Direct Connect (takes > 1 month). Use Site-to-Site VPN for quick setup. DX is only the answer when time is not a constraint.

AWS Client VPN:

AWS Client VPN — connect end-devices (laptops) to AWS or on-premises via OpenVPN over the internet. Access EC2 using private IP.

Transit Gateway:

Transit Gateway — transitive peering hub for thousands of VPCs and on-premises (hub-and-spoke / star topology).

• Regional resource, can work cross-region (peering)
• Share cross-account using Resource Access Manager (RAM)
• Route Tables: control which VPC can talk to which
• Works with: Direct Connect Gateway, VPN connections
• Only AWS service that supports IP Multicast

                    ┌──► VPC-A
                    │
Corporate DC ──► Transit Gateway ──► VPC-B
  (VPN/DX)          │
                    ├──► VPC-C
                    │
                    └──► VPC-D

Without TGW: complex mesh of VPC peering + VPN connections (N² connections) With TGW: single hub, all spokes connect to it (N connections)

ECMP (Equal-Cost Multi-Path Routing):

• Forward packets over multiple best paths to increase bandwidth
• Use case: multiple Site-to-Site VPN connections to TGW for more bandwidth

Share DX across accounts:

• Transit Gateway + Direct Connect Gateway + Transit VIF
• Use RAM to share Transit Gateway with other accounts

⚠️ Exam trap: “Connect many VPCs + on-premises, simplify topology” → Transit Gateway. NOT VPC Peering (not transitive, mesh complexity).

⚠️ Exam trap: “Increase VPN bandwidth to AWS” → multiple VPN connections + Transit Gateway with ECMP. VGW limited to 1.25 Gbps.

VPC Traffic Mirroring:

Traffic Mirroring — capture and inspect network traffic in your VPC.

• Source: ENIs → Target: ENI or NLB
• Can filter traffic, optionally truncate packets
• Source and target can be in same or different VPCs (via peering)
• Use cases: content inspection, threat monitoring, troubleshooting

Source A (ENI) ──┐
                 ├──► Traffic Mirroring ──► NLB ──► ASG (Security Appliances)
Source B (ENI) ──┘    (filter optional)

Egress-only Internet Gateway:

Egress-only IGW — like a NAT Gateway, but for IPv6.

• Allows instances outbound connections over IPv6
• Prevents the internet from initiating inbound IPv6 connections
• Must update Route Tables

IPv4 outbound: Private EC2 ──► NAT Gateway ──► IGW ──► Internet
IPv6 outbound: EC2 ──► Egress-only IGW ──► Internet  (no inbound initiated)

⚠️ Exam trap: “IPv6 instances need outbound internet but block inbound” → Egress-only IGW (NOT NAT Gateway — NAT is for IPv4 only).

Networking Costs:

Core principle: Ingress is free, egress costs money. Keep traffic inside AWS to minimize costs.

EC2 Data Transfer Costs (per GB):

Cost optimization tips:

• Use private IP instead of public IP → saves money + better network performance
• Use same AZ for maximum savings (trade-off: less HA)
• DX locations co-located in same region → lower egress cost
• Keep heavy processing (DB queries) inside AWS, send only results out

⚠️ Exam trap: “Lowest egress cost” with Direct Connect available

• DX egress < Internet egress (~$0.02/GB vs ~$0.09/GB)
• Strategy: keep big data transfers inside AWS (free/cheap), send only small results to users via DX (not internet)
• ❌ “Access over internet” → always more expensive egress than DX
• ❌ “Deploy on-premises + query AWS” → large query results cross the boundary on EVERY request (expensive even via DX)

NAT Gateway vs VPC Gateway Endpoint (for S3):

Subnet 1: EC2 ──► NAT GW ──► IGW ──► S3         (costly: ~$0.09/GB)
Subnet 2: EC2 ──► VPC Gateway Endpoint ──► S3    (free endpoint, ~$0.01/GB)

⚠️ Exam trap: “Reduce cost of S3 access from VPC” → Gateway Endpoint (free, no NAT GW charges). Route table entry with pl-id for Amazon S3 → vpce-id.

S3 Data Transfer Pricing (USA):

⚠️ Exam trap: “Deliver S3 content to users cheaply” → CloudFront ($0.085/GB vs $0.09/GB direct) + caching + 7x cheaper S3 request pricing.

AWS Network Firewall:

AWS Network Firewall — protect your entire VPC, Layer 3 to Layer 7.

• Inspect traffic in any direction:
  • VPC to VPC
  • Outbound to internet
  • Inbound from internet
  • To/from Direct Connect & Site-to-Site VPN
• Internally uses AWS Gateway Load Balancer
• Rules centrally managed cross-account by AWS Firewall Manager

Fine-Grained Controls:

• 1000s of rules: IP/port filtering (10,000s of IPs), protocol blocking (e.g., block SMB outbound)
• Stateful domain list: allow only *.mycorp.com outbound
• Regex pattern matching
• Traffic filtering: Allow, Drop, or Alert
• Active flow inspection (intrusion prevention)
• Logs → S3, CloudWatch Logs, Kinesis Data Firehose

⚠️ Exam trap: “Sophisticated VPC-wide network protection, Layer 3-7, inspect all traffic directions” → AWS Network Firewall. NOT just NACLs/SGs (those are basic). NOT WAF (WAF is Layer 7 HTTP only).

🎯 MASTER SUMMARY: VPC & Networking Exam Guide

Part 1: Core Principles (Understand WHY → Derive WHAT)

Principle 1: Everything Starts with Routing

Traffic doesn’t flow just because resources exist — Route Tables are the backbone. IGW, NAT, VPC Peering, Endpoints — none work without correct route table entries. If connectivity fails, check routes first.

Key insight: Most “can’t connect” troubleshooting answers involve Route Tables, SGs, or NACLs.

Principle 2: Public vs Private = Route to IGW

A subnet is “public” only because its route table has 0.0.0.0/0 → igw-id. There’s no checkbox. No route to IGW = private subnet, regardless of what you call it.

Principle 3: Stateful vs Stateless = The Fundamental Security Split

• SG (Stateful): Allow outbound → return automatically allowed inbound. Only control who initiates.
• NACL (Stateless): Must explicitly allow BOTH directions, including ephemeral ports for responses.

Derivation: If the exam says “ACCEPT then REJECT in flow logs” → always NACL. SGs never block return traffic.

Principle 4: Private Subnet Internet Access = NAT (IPv4) or Egress-only IGW (IPv6)

Private instances can’t reach internet directly. They need a “translator” in a public subnet:

• IPv4 → NAT Gateway (managed) or NAT Instance (legacy)
• IPv6 → Egress-only IGW (all IPv6 is public, so NAT isn’t needed — just block inbound)

Principle 5: AWS Services from VPC = Endpoints (Stay Private)

Instead of routing through IGW to reach AWS services, use VPC Endpoints:

• Gateway Endpoint (free) → S3 and DynamoDB only
• Interface Endpoint (paid) → everything else, accessible from on-prem

Derivation: “Reduce cost of S3 access” or “private access to S3” → Gateway Endpoint.

Principle 6: On-Premises Connectivity = Speed vs Cost vs Time

Three options, each with trade-offs:

• VPN: Fast to set up, encrypted, over internet, up to 1.25 Gbps (or more with TGW+ECMP)
• Direct Connect: Takes >1 month, private physical line, up to 100 Gbps, NOT encrypted
• Client VPN: For individual users (laptops), not site-to-site

Principle 7: Transitivity Doesn’t Exist in VPC Peering

VPC Peering is point-to-point. A↔B and B↔C does NOT mean A↔C. For hub connectivity → Transit Gateway.

Principle 8: Transit Gateway = The Universal Hub

TGW solves three problems: (1) transitive routing, (2) VPN bandwidth scaling (ECMP), (3) sharing DX across accounts. If question mentions “many VPCs” or “simplify network” → TGW.

Principle 9: Network Protection is Layered

Layer 3-4:  NACLs (subnet) → Security Groups (ENI)
Layer 7:    WAF (HTTP/HTTPS only)
Layer 3-7:  AWS Network Firewall (entire VPC, all directions)
Cross-acct: AWS Firewall Manager (centralize rules)

Principle 10: Egress Costs Money, Ingress is Free

All AWS networking pricing follows this: data IN = free, data OUT = costs. Minimize egress by keeping processing inside AWS and using private IPs.

Part 2: Decision Tree (Follow Keywords → Find Answer)

Connectivity Decision Tree

Need to connect to AWS?
│
├─ From on-premises SITE?
│  ├─ Need it NOW (days)? ──► Site-to-Site VPN
│  ├─ Need dedicated/private/consistent? ──► Direct Connect
│  ├─ Need encryption on DX? ──► VPN on top of DX
│  ├─ Multiple sites to connect? ──► VPN CloudHub
│  └─ Need DX to multiple regions? ──► DX Gateway
│
├─ From individual LAPTOP?
│  └─► AWS Client VPN (OpenVPN)
│
├─ VPC to VPC?
│  ├─ Just 2 VPCs? ──► VPC Peering
│  ├─ Many VPCs (hub-and-spoke)? ──► Transit Gateway
│  └─ Expose specific service? ──► PrivateLink (NLB + ENI)
│
└─ VPC to AWS Service (S3, DynamoDB, etc.)?
   ├─ S3 or DynamoDB? ──► Gateway Endpoint (free)
   ├─ Other service? ──► Interface Endpoint
   └─ Need on-prem access too? ──► Interface Endpoint

Security Decision Tree

Need to control traffic?
│
├─ At instance/ENI level? ──► Security Group (ALLOW only, stateful)
├─ At subnet level? ──► NACL (ALLOW + DENY, stateless)
├─ Block specific IPs (Layer 3)? ──► NACL (has DENY rules)
├─ Block HTTP patterns/SQL injection? ──► WAF (Layer 7)
├─ VPC-wide, all directions, L3-L7? ──► AWS Network Firewall
└─ Centralize across accounts? ──► AWS Firewall Manager

The CANNOT List

Part 3: Scenario Pattern Recognition

Pattern: “Private instances need internet access, managed, scalable”

Keywords: private subnet, internet, managed, scales Answer: NAT Gateway Why: AWS-managed, auto-scales to 100 Gbps, no SG/patching needed

Pattern: “SSH into private EC2 instances”

Keywords: SSH, private subnet, access, developers Answer: Bastion Host (or SSM Session Manager) Why: Bastion in public subnet acts as SSH jump box. SG: port 22 from corporate public CIDR

Pattern: “ACCEPT then REJECT in flow logs”

Keywords: flow logs, allowed then blocked, return traffic Answer: NACL is blocking (not SG) Why: SGs are stateful — they never block return traffic. Only NACLs (stateless) do this

Pattern: “Can’t launch EC2 in subnet”

Keywords: launch failure, subnet, no capacity Answer: No available IPv4 addresses → add new CIDR Why: IPv6 space is huge; the bottleneck is always IPv4

Pattern: “VPC A peers with B, B peers with C, can A reach C?”

Keywords: VPC peering, transitive, multiple VPCs Answer: NO — VPC Peering is not transitive Why: Need A↔C peering, or use Transit Gateway

Pattern: “Connect many VPCs + on-premises, simplify”

Keywords: many VPCs, hub-and-spoke, simplify, on-premises Answer: Transit Gateway Why: Single hub, N connections instead of N² mesh

Pattern: “Increase VPN bandwidth beyond 1.25 Gbps”

Keywords: VPN throughput, scale bandwidth, more than 1.25 Answer: Transit Gateway with ECMP + multiple VPN connections Why: VGW uses only 1 tunnel (1.25 Gbps); TGW uses both (2.5 Gbps) and stacks connections

Pattern: “Private, dedicated, consistent connection to AWS”

Keywords: dedicated, private, consistent, not internet Answer: Direct Connect Why: Physical private connection, doesn’t traverse internet

Pattern: “Improve connectivity within days/1 week”

Keywords: quickly, fast setup, days, immediately Answer: Site-to-Site VPN (NOT Direct Connect) Why: DX takes >1 month to establish

Pattern: “DX backup, cost-effective”

Keywords: Direct Connect fails, backup, cheap Answer: Site-to-Site VPN as backup Why: Second DX is expensive; VPN is cheap and quick

Pattern: “Access S3/DynamoDB from VPC privately”

Keywords: S3, DynamoDB, private access, no internet, reduce cost Answer: VPC Gateway Endpoint (free) Why: Free, route table entry, no NAT GW charges

Pattern: “Access AWS service from on-premises via DX/VPN”

Keywords: on-premises, AWS service, private access, VPN, Direct Connect Answer: VPC Interface Endpoint (not Gateway) Why: Gateway Endpoints can’t be accessed from on-prem

Pattern: “Connect multiple on-prem sites, backup over internet”

Keywords: multiple sites, hub-and-spoke, VPN, backup Answer: AWS VPN CloudHub Why: Multiple VPN connections on same VGW, over public internet

Pattern: “Expose service from one VPC to another privately”

Keywords: expose, service, private, cross-VPC, cross-account Answer: AWS PrivateLink (NLB + ENI) Why: No peering, no IGW, no routes needed

Pattern: “IPv6 outbound internet, block inbound”

Keywords: IPv6, outbound, prevent inbound, internet Answer: Egress-only Internet Gateway Why: NAT is IPv4 only; Egress-only IGW is the IPv6 equivalent

Pattern: “Capture IP traffic information/metadata”

Keywords: capture, IP traffic, information, logs, metadata Answer: VPC Flow Logs Why: Flow Logs = metadata (IPs, ports, action). Traffic Mirroring = full packet capture

Pattern: “Inspect actual network traffic content”

Keywords: inspect, deep packet, content, security appliance Answer: VPC Traffic Mirroring Why: Copies actual packets to ENI/NLB for analysis

Pattern: “500 Mbps Direct Connect”

Keywords: 500 Mbps, DX, connection Answer: Hosted connection Why: Dedicated = 1/10/100 Gbps only. Anything in between = Hosted

Pattern: “VPC-wide network protection, Layer 3-7”

Keywords: sophisticated, entire VPC, Layer 3-7, all directions Answer: AWS Network Firewall Why: NACLs/SGs are basic, WAF is HTTP-only. Network Firewall covers L3-L7 in all directions

Pattern: “DX to VPCs in multiple regions”

Keywords: Direct Connect, multiple regions, VPCs Answer: Direct Connect Gateway Why: One DX → DX Gateway → VPCs across regions

Part 4: Quick Reference Tables

On-Premises Connectivity Comparison:

VPC Endpoint Comparison:

Security Layers:

Key Numbers:

Part 5: Ultimate Instant-Answer Table

Part 6: Elimination Checklist

Connectivity Questions

□ Is it on-premises → AWS?
  → Yes: VPN, DX, or Client VPN
    □ Need it fast (days)?
      → Yes = Site-to-Site VPN
      → No (can wait months) = Direct Connect
    □ Individual user (laptop)?
      → Yes = Client VPN
    □ Multiple on-prem sites?
      → Yes = VPN CloudHub
  → No: VPC-to-VPC or VPC-to-service

□ Is it VPC → VPC?
  → 2 VPCs = VPC Peering
  → Many VPCs = Transit Gateway
  → Expose single service = PrivateLink

□ Is it VPC → AWS Service?
  → S3 or DynamoDB = Gateway Endpoint
  → Anything else = Interface Endpoint
  → Needs on-prem access = Interface Endpoint

Security Questions

□ What layer?
  → L3-L4 per instance = Security Group
  → L3-L4 per subnet = NACL
  → L7 HTTP only = WAF
  → L3-L7 entire VPC = Network Firewall

□ Need DENY rules?
  → Yes = NACL (SGs only have ALLOW)

□ Stateful or stateless matters?
  → "Return traffic blocked" = NACL (stateless)
  → "Ephemeral ports needed" = NACL

Cost Questions

□ Private IP or Public IP?
  → Private = cheaper (free same-AZ, $0.01 cross-AZ)
  → Public = $0.02 even same-AZ

□ S3 access path?
  → NAT GW → IGW = expensive
  → Gateway Endpoint = free

□ Content delivery?
  → S3 direct = $0.09/GB
  → CloudFront = $0.085/GB + caching

🏆 The Golden Rules

1. Route Tables are the backbone (no routes = no connectivity, regardless of gateways)
2. SG = stateful, NACL = stateless (derive all firewall behavior from this)
3. “ACCEPT then REJECT” = always NACL (SGs never block return traffic)
4. Gateway Endpoint for S3/DynamoDB (free, always preferred on exam)
5. VPC Peering is NOT transitive (many VPCs → Transit Gateway)
6. DX takes >1 month (quick fix → VPN, DX backup → VPN)
7. Dedicated DX = 1/10/100 Gbps (anything else → Hosted)
8. NAT Gateway has NO Security Groups (SGs/Bastion → NAT Instance)
9. VPN max 1.25 Gbps via VGW (more → TGW + ECMP)
10. IPv4 outbound = NAT, IPv6 outbound = Egress-only IGW (don’t mix them)
11. 5 IPs reserved per subnet (always add 5 to your requirement)
12. Private IP = cheaper + better performance (always prefer over public)
13. Ingress = free, egress = costs money (keep processing inside AWS)
14. Reference SGs in rules (more secure and dynamic than CIDR-based rules)
15. DX is NOT encrypted (add VPN on top for encryption)

Amazon Route53:

┌──────────┐   example.com?   ┌─────────────┐
│  Client  │ ───────────────→ │  Route 53   │
│          │ ←─────────────── │             │
└────┬─────┘   54.22.33.44    └─────────────┘
     │
     │  54.22.33.44
     ▼
┌─────────────────────────────────────┐
│            AWS Cloud                │
│     ┌──────────────────────┐        │
│     │    EC2 Instance      │        │
│     │  Public IP:          │        │
│     │  54.22.33.44         │        │
│     └──────────────────────┘        │
└─────────────────────────────────────┘

AWS Route53 is a managed DNS (Domain Name System), collection of rules and records which helps clients understand how to reach a server through URLs.

⚠️ Exam trap: Route 53 is a global service — no region selection needed!

DNS Terminologies:

        http://api.www.example.com.
               │   │       │     │ │
               │   │       │     │ └── Root (.)
               │   │       │     └──── TLD (.com, .gov, .org)
               │   │       └────────── SLD (example.com)
               │   └────────────────── Sub Domain (www)
               └────────────────────── Sub Domain (api)
               
        └────────────────────────────┘
            FQDN (Fully Qualified Domain Name)

DNS Resolution Flow:

┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
│ Browser │───→│   OS    │───→│   ISP   │───→│  Root   │───→│   TLD   │───→│  Name   │
│  Cache  │    │  Cache  │    │  Cache  │    │ Server  │    │ Server  │    │ Server  │
└─────────┘    └─────────┘    └─────────┘    └─────────┘    └─────────┘    └────┬────┘
                                                                                │
                                              ┌─────────────────────────────────┘
                                              ▼
                                        IP Address
                                     (cached on way back)

1. Browser cache → OS cache → ISP DNS Resolver
2. Root Server → “Go ask .com TLD”
3. TLD Server → “Go ask example.com Name Server”
4. Name Server → Returns IP address
5. Caches populated on the way back

Route 53 – Records:

Each record contains:

⚠️ Exam trap: CNAME cannot be used for Zone Apex (example.com) — only for subdomains (www.example.com). Use Alias for apex!

Route 53 – Hosted Zones:

A container for records that define how to route traffic to a domain and its subdomains.

    PUBLIC HOSTED ZONE                    PRIVATE HOSTED ZONE
    ──────────────────                    ───────────────────
         
    ┌────────┐  example.com?              ┌─────────────────────────────────┐
    │ Client │ ──────────────┐            │              VPC                │
    └────────┘               │            │  ┌─────────────────────────┐    │
         ▲                   ▼            │  │  Private Hosted Zone    │    │
         │            ┌────────────┐      │  └───────────┬─────────────┘    │
         │            │  Public    │      │              │                  │
         └────────────│  Hosted    │      │   ┌──────────┴──────────┐       │
       54.22.33.44    │  Zone      │      │   ▼                     ▼       │
                      └─────┬──────┘      │ api.example     db.example      │
                            │             │ .internal?      .internal?      │
                            ▼             │   │                     │       │
                    ┌───────────────┐     │   ▼                     ▼       │
                    │ S3, CloudFront│     │ 10.0.0.10          10.0.0.35    │
                    │ EC2, ALB      │     │ (EC2)              (RDS)        │
                    └───────────────┘     └─────────────────────────────────┘

• Cost: $0.50/month per hosted zone

Route 53 – TTL (Time To Live):

              myapp.example.com? 
┌────────┐ ─────────────────────→ ┌──────────┐
│ Client │ ←───────────────────── │ Route 53 │
└───┬────┘                        └──────────┘
    │  A 12.34.56.78 (TTL) 
    │
    │  Client caches result for TTL duration
    │
    │        HTTP Request
    └──────────────────────────→ ┌────────────┐
    ←─────────────────────────── │ Web Server │
             HTTP Response       └────────────┘

• TTL is mandatory for each DNS record (except Alias records)
• Strategy: Lower TTL before planned changes → make change → raise TTL back

⚠️ Exam trap: Changed DNS record but users still go to old IP? → TTL caching! Clients cache until TTL expires.

Route 53 – CNAME vs Alias:

AWS resources expose ugly hostnames (e.g., lb1-1234.us-east-2.elb.amazonaws.com) — you want myapp.mydomain.com

⚠️ Exam trap: Need to point mydomain.com (root) to an ALB? → Alias (CNAME won’t work!)

Route 53 – Alias Records:

AWS extension to DNS that maps a hostname to an AWS resource. Automatically recognizes IP changes on the target.

┌───────────────────────────────────────────────┐
│  Route 53 Alias Record                        │
│  ┌────────────────────────────────────────┐   │
│  │ Record: example.com                    │   │
│  │ Type: A                                │   │
│  │ Value: MyALB-123456789.us-east-1...    │   │
│  └────────────────────────────────────────┘   │
└───────────┬───────────────────────────────────┘
            │ AWS-Managed (IP changes tracked)
            ▼
    ┌──────────────────┐
    │ Application      │
    │ Load Balancer    │
    │ (MyALB-1234...)  │
    └──────────────────┘

⚠️ Exam trap: Alias records — you cannot set TTL (Route 53 manages it automatically)

Targets:

• Elastic Load Balancers (ALB, NLB, Classic LB)
• CloudFront Distributions
• API Gateway
• Elastic Beanstalk environments
• S3 Websites
• VPC Interface Endpoints
• Global Accelerator
• Route 53 records in same hosted zone

⚠️ Exam trap: Cannot use Alias for EC2 DNS names — use regular A record or CNAME instead!

Route 53 – Routing Policies:

DNS responds to queries (does NOT route traffic like a load balancer).

Route53 policies:

• Simple routing policy: Use for a single resource that performs a given function for your domain, for example, a web server that serves content for the example.com website. You can use simple routing to create records in a private hosted zone;
• Weighted routing policy: Use to route traffic to multiple resources in proportions that you specify. You can use weighted routing to create records in a private hosted zone.
• Failover routing policy: Use when you want to configure active-passive failover. You can use failover routing to create records in a private hosted zone;
• Latency routing policy: Use when you have resources in multiple AWS Regions and you want to route traffic to the Region that provides the best latency. You can use latency routing to create records in a private hosted zone;
• Geolocation routing policy: Use when you want to route traffic based on the location of your users. You can use geolocation routing to create records in a private hosted zone;
• Geoproximity routing policy: Use when you want to route traffic based on the location of your resources and, optionally, shift traffic from resources in one location to resources in another location. You can use geoproximity routing to create records in a private hosted zone;
• Multivalue answer routing policy: Use when you want Route 53 to respond to DNS queries with up to eight healthy records selected at random. You can use multivalue answer routing to create records in a private hosted zone;
• IP-based routing policy: Use when you want to route traffic based on the location of your users, and have the IP addresses that the traffic originates from.

⚠️ Exam trap: “Routing” in Route 53 ≠ Load Balancer routing. DNS responds to queries; it doesn’t route actual traffic!

Routing Policy – Simple:

SINGLE VALUE                    MULTIPLE VALUES
─────────────                   ──────────────────

    foo.example.com                foo.example.com
         │                              │
         │ A 11.22.33.44               │ A 11.22.33.44
┌─────────────────┐            ┌─────────────────────┐
│  Client         │            │  Client chooses     │
│  Gets 1 value   │            │  a random value     │
└─────────────────┘            └─────────────────────┘
                                   │ A 55.66.77.88
                                   │ A 99.11.22.33

• Use for single resource (typical case)
• Can return multiple values in same record — client picks one randomly
• ❌ Cannot use with Health Checks
• When Alias enabled → only one AWS resource allowed

⚠️ Exam trap: Simple policy with multiple values ≠ load balancing! No health checks, no failover.

Routing Policy – Weighted:

• Control % of traffic to each resource via relative weights
• Formula: traffic % = weight for record / sum of all weights
• Weights don’t need to sum to 100
• Records must have same name and type
• ✅ Can use with Health Checks
• Use cases: Load balancing between regions, A/B testing, canary deployments (e.g., 5% to new Elastic Beanstalk env)
• Weight = 0 → stops traffic to that resource
• All weights = 0 → all records returned equally

⚠️ Exam trap: Weighted ≠ round-robin! It’s percentage-based distribution, not sequential rotation. ⚠️ Exam trap: Weight = 0 stops all traffic to that resource (useful for maintenance)

Routing Policy – Latency-based:

• Routes to resource with lowest latency (best response time) to user
• Latency measured between user and AWS Regions
• ✅ Can use with Health Checks (failover capability)
• Use case: App in multiple regions → minimize response time for users

⚠️ Exam trap: Latency ≠ Geography! German user may be directed to US if that has lowest latency. ⚠️ Exam trap: “Best user experience” / “minimize response time” → Latency, not Geolocation!

Route 53 – Health Checks:

Multi-region failover architecture:

                    ┌───────────┐
                    │ Route 53  │
                    │ DNS Record│
                    └─────┬─────┘
                          │
            ┌─────────────┴─────────────┐
            ▼                           ▼
       ❤ Health Check              ❤ Health Check
            │                           │
   ┌────────┴────────┐         ┌────────┴────────┐
   │    us-east-1    │         │    eu-west-1    │
   │  ┌───────────┐  │         │  ┌───────────┐  │
   │  │    ALB    │  │         │  │    ALB    │  │
   │  └─────┬─────┘  │         │  └─────┬─────┘  │
   │        ▼        │         │        ▼        │
   │  ┌───────────┐  │         │  ┌───────────┐  │
   │  │    ASG    │  │         │  │    ASG    │  │
   │  └───────────┘  │         │  └───────────┘  │
   └─────────────────┘         └─────────────────┘

How endpoint monitoring works:

  ❤ Health Checker   ❤ Health Checker   ❤ Health Checker
     (us-east-1)        (us-west-1)        (sa-east-1)
          │                  │                  │
          └──────────────────┼──────────────────┘
                             │ HTTP request to /health
                             ▼ 200 code
                    ┌─────────────────┐
                    │    eu-west-1    │
                    │  ┌───────────┐  │
                    │  │    ALB    │──┼── Must allow Route 53
                    │  └─────┬─────┘  │   Health Checker IPs!
                    │        ▼        │
                    │  ┌───────────┐  │
                    │  │  EC2/ASG  │  │
                    │  └───────────┘  │
                    └─────────────────┘

IP ranges: https://ip-ranges.amazonaws.com/ip-ranges.json

⚠️ Exam trap: Must configure firewall/security group to allow Route 53 Health Checker IPs!

• HTTP Health Checks work only for public resources
• Integrated with CloudWatch metrics

⚠️ Exam trap: Only 3 health check types! No direct SQS, SNS, or other service monitoring — use CloudWatch Alarm instead.

⚠️ Exam trap: Private resources → use CloudWatch Alarm health checks (HTTP checks can’t reach them!)

Health Checks for Private Resources:

                              ┌─────────────────────────────────┐
                              │              VPC                │
┌─────────────────┐           │  ┌───────────────────────────┐  │
│ Health Checker  │           │  │     Private subnet        │  │
│  (us-east-1)    │           │  │    ┌─────────────┐        │  │
└────────┬────────┘           │  │    │  EC2 (T2)   │        │  │
         │                    │  │    └──────┬──────┘        │  │
         │ ✖ Can't reach!     │  │           │ monitor       │  │
         │                    │  │           ▼               │  │
         │    monitor         │  │    ┌─────────────┐        │  │
         └────────────────────┼──┼───→│ CloudWatch  │        │  │
                              │  │    │   Alarm     │        │  │
                              │  │    └─────────────┘        │  │
                              │  └───────────────────────────┘  │
                              └─────────────────────────────────┘

• Route 53 health checkers are outside VPC — can’t reach private endpoints
• Solution: Create CloudWatch Metric → CloudWatch Alarm → Health Check monitors the alarm

Routing Policy – Geolocation:

• Routes based on user location (not latency!)
• Specify: Continent → Country → US State (most precise wins)
• Must create “Default” record for unmatched locations
• ✅ Can use with Health Checks
• Use cases: Website localization, content/access restrictions by country, regional load balancing

⚠️ Exam trap: Geolocation ≠ Latency! Geolocation = user’s geography; Latency = network performance. ⚠️ Exam trap: “Legal requirement” / “restrict access by country” → Geolocation (not Latency!)

Routing Policy – Geoproximity:

• Routes based on geographic location of users AND resources
• Use bias to shift traffic between resources:
  • Expand (1 to 99) → more traffic to resource
  • Shrink (-1 to -99) → less traffic to resource
• Resources: AWS (specify region) or Non-AWS (specify lat/long)
• Requires Route 53 Traffic Flow

⚠️ Exam trap: Geoproximity requires Traffic Flow (paid feature). Geolocation does NOT!

Routing Policy – IP-based:

  User B              User A
(200.5.4.100)      (203.0.113.56)
      │                  │
      └────────┬─────────┘
               ▼
          ┌─────────┐
          │Route 53 │
          └────┬────┘
               │
     ┌─────────┴─────────┐
     │  CIDR Collection  │
     ├───────────────────┤
     │ location-1: 203.0.113.0/24 │
     │ location-2: 200.5.4.0/24   │
     └─────────┬─────────┘
               │
     ┌─────────┴─────────┐
     │      Records      │
     ├───────────────────┤
     │ example.com → 1.2.3.4 (location-1) │
     │ example.com → 5.6.7.8 (location-2) │
     └─────────┬─────────┘
               │
       ┌───────┴───────┐
       ▼               ▼
   EC2 (5.6.7.8)   EC2 (1.2.3.4)
    User B →         User A →

• Routes based on client IP address (CIDR blocks)
• You define: CIDR → Location → Endpoint mappings
• Use cases: Optimize performance, reduce network costs, route specific ISP users

Routing Policy – Multi-Value:

• Returns multiple values/resources (up to 8 healthy records)
• ✅ Can use with Health Checks — returns only healthy resources
• Client chooses one from the returned values

⚠️ Exam trap: Multi-Value is NOT a substitute for ELB! It’s client-side selection, not load balancing.

Domain Registrar vs. DNS Service:

• Registrar usually provides DNS service, but you can use a different DNS provider
• Example: Buy domain from GoDaddy → Use Route 53 to manage DNS records
• To use Route 53 with 3rd party registrar: Create Public Hosted Zone → Update NS records at the registrar (not in Route 53!)

⚠️ Exam trap: Update NS records at the registrar (GoDaddy), not in Route 53! And use Public Hosted Zone for internet-facing domains.

Route 53 – Hybrid DNS:

Route 53 Resolver automatically answers DNS queries for:

• Local domain names for EC2 instances
• Records in Private Hosted Zones
• Records in public Name Servers

Hybrid DNS = Resolving DNS queries between VPC (Route 53 Resolver) and your networks (other DNS Resolvers)

Route 53 – Resolver Endpoints:

Inbound Endpoint — On-premises DNS resolvers can query Route 53 Resolver for AWS resources

                                    ┌─────────────────────────────────────────┐
                                    │               us-east-1                 │
   On-Premises Data Center          │  ┌───────────────────────────────────┐  │
  ┌──────────────────────┐          │  │              VPC                  │  │
  │                      │          │  │     Private Hosted Zone           │  │
  │  ┌────────────────┐  │          │  │       (aws.private)               │  │
  │  │ DNS Resolvers  │  │          │  │  ┌─────────────────────────────┐  │  │
  │  │(onpremise.     │  │          │  │  │     Private Subnet          │  │  │
  │  │  private)      │──┼── DNS Query: app.aws.private? ──────────────→│  │  │
  │  └────────────────┘  │          │  │  │  ┌────────────┐  ┌────────┐ │  │  │
  │         ▲            │          │  │  │  │    EC2     │  │Resolver│ │  │  │
  │         │            │          │  │  │  │(app.aws.   │←─│Inbound │ │  │  │
  │  ┌──────┴───────┐    │          │  │  │  │  private)  │  │Endpoint│ │  │  │
  │  │    Server    │    │          │  │  │  └────────────┘  └───┬────┘ │  │  │
  │  │ (web.onprem  │    │◀═══VPN or DX═══════════════════════════╝     │  │  │
  │  │  .private)   │    │          │  │  └─────────────────────────────┘  │  │
  │  └──────────────┘    │          │  └──────────────┬────────────────────┘  │
  └──────────────────────┘          │                 │ lookup               │
                                    │                 ▼                      │
                                    │           Route 53 Resolver            │
                                    └─────────────────────────────────────────┘

⚠️ Exam trap: Inbound = queries coming IN to AWS. Outbound = queries going OUT from AWS. Think from AWS perspective!

Outbound Endpoint — Route 53 Resolver forwards DNS queries to on-premises DNS Resolvers

                                    ┌─────────────────────────────────────────┐
                                    │               us-east-1                 │
   On-Premises Data Center          │  ┌───────────────────────────────────┐  │
  ┌──────────────────────┐          │  │              VPC                  │  │
  │                      │          │  │     Private Hosted Zone           │  │
  │  ┌────────────────┐  │          │  │       (aws.private)               │  │
  │  │ DNS Resolvers  │  │          │  │  ┌─────────────────────────────┐  │  │
  │  │(onpremise.     │←─┼── DNS Query: web.onpremise.private? ────────│  │  │
  │  │  private)      │  │          │  │  │  ┌────────────┐  ┌────────┐ │  │  │
  │  └────────────────┘  │          │  │  │  │    EC2     │─→│Resolver│ │  │  │
  │         │            │          │  │  │  │(app.aws.   │  │Outbound│ │  │  │
  │         ▼            │          │  │  │  │  private)  │  │Endpoint│─┼──┼──┘
  │  ┌──────────────┐    │          │  │  │  └────────────┘  └────────┘ │  │
  │  │    Server    │    │◀═══VPN or DX═════════════════════════════════╝  │
  │  │ (web.onprem  │    │          │  │  └─────────────────────────────┘  │
  │  │  .private)   │    │          │  └──────────────┬────────────────────┘
  │  └──────────────┘    │          │                 │                    │
  └──────────────────────┘          │                 ▼                    │
                                    │           Route 53 Resolver          │
                                    └──────────────────────────────────────┘

Route 53 – Resolver Rules

Resolver Rules = define how DNS queries are forwarded from Outbound Endpoints

• Rules can be shared across accounts via AWS RAM
• Use case: Centralized DNS management in multi-account setup

Resolver Rules Example:

Query: db.corp.local           Query: api.example.com
         │                              │
         ▼                              ▼
    ┌──────────────────────────────────────┐
    │         Resolver Rules               │
    │  ┌────────────────────────────────┐  │
    │  │ *.corp.local → 10.0.0.53       │──┼──▶ On-prem DNS
    │  │ *.example.com → System Rule    │──┼──▶ Route 53
    │  │ * (default) → Recursive        │──┼──▶ Public DNS
    │  └────────────────────────────────┘  │
    └──────────────────────────────────────┘

⚠️ Exam trap: “Share DNS resolution across accounts” → Resolver Rules + AWS RAM

Route 53 – DNSSEC

DNSSEC = DNS Security Extensions — protects against DNS spoofing/cache poisoning

Setup steps:

1. Enable DNSSEC signing in Route 53
2. Create KSK (Key Signing Key) in KMS — must be in us-east-1
3. Establish chain of trust with parent zone (add DS record at registrar)

⚠️ Exam trap: “Prevent DNS spoofing” or “verify DNS response authenticity” → DNSSEC ⚠️ Exam trap: DNSSEC KMS key must be in us-east-1 (like CloudFront certificates)

🎯 MASTER SUMMARY: Route 53 Exam Guide

Part 1: Core Principles (Understand WHY → Derive WHAT)

Principle 1: DNS ≠ Load Balancer

Route 53 responds to DNS queries — it returns IP addresses. It does NOT route actual network traffic.

• “Routing policy” = how Route 53 answers DNS queries
• Client receives IP(s), then connects directly to the resource
• This is why Multi-Value is NOT a replacement for ELB

Principle 2: Alias = AWS’s DNS Superpower

CNAME has limitations (can’t use at Zone Apex, costs money). AWS invented Alias to solve this:

• Works at Zone Apex (example.com) ✅
• Free of charge ✅
• Auto-tracks IP changes ✅
• Native health check integration ✅

Rule: If pointing to AWS resource → use Alias. If pointing to non-AWS → use CNAME (or A record).

Principle 3: Zone Apex = Root Domain Problem

example.com (no subdomain) = Zone Apex = Root Domain

DNS standard forbids CNAME at apex. AWS Alias bypasses this limitation.

Principle 4: Health Checks = Failover Enabler

Health checks are the foundation of high availability in Route 53:

• Without health check → no automatic failover
• Health checks are public — they run from outside your VPC
• Private resources → use CloudWatch Alarm health checks

Principle 5: TTL = Caching Control

TTL determines how long clients cache DNS responses:

• High TTL = less Route 53 traffic, lower cost, stale records risk
• Low TTL = more traffic, higher cost, fresh records
• Strategy: Lower TTL before changes → make change → raise TTL

Principle 6: Latency ≠ Geography

Two commonly confused policies:

• Latency: Routes to region with best network performance (may cross continents!)
• Geolocation: Routes based on user’s physical location (for legal/content restrictions)

German user might be routed to US-East if that has lower latency than EU-West.

Principle 7: Resource Policies for Cross-Service/Cross-Account

When another AWS service or another account needs access:

• Update NS records at the registrar (not in Route 53)
• Use Public Hosted Zone for internet-facing domains

Principle 8: Hybrid DNS = Inbound + Outbound

Think from AWS’s perspective:

• Inbound Endpoint: Queries coming IN to AWS (on-prem → AWS)
• Outbound Endpoint: Queries going OUT from AWS (AWS → on-prem)

Part 2: Decision Tree (Follow Keywords → Find Answer)

Step 1: What type of record do you need?

                    What are you pointing to?
                              │
        ┌─────────────────────┼─────────────────────┐
        ▼                     ▼                     ▼
   IPv4 Address         AWS Resource          Another Hostname
        │                     │                     │
        ▼                     ▼                     ▼
    A Record              Alias A/AAAA          Is it Zone Apex?
                          (FREE!)                   │
                                            ┌───────┴───────┐
                                            ▼               ▼
                                           Yes              No
                                            │               │
                                            ▼               ▼
                                         Alias           CNAME ok
                                       (required)

Step 2: Which routing policy?

                        What's the requirement?
                              │
    ┌────────────┬────────────┼────────────┬────────────┬────────────┐
    ▼            ▼            ▼            ▼            ▼            ▼
 Single      Traffic %    Best User    User's      Failover     Client IP
 Resource    Control      Experience   Country     HA Setup     Routing
    │            │            │            │            │            │
    ▼            ▼            ▼            ▼            ▼            ▼
 Simple      Weighted     Latency    Geolocation  Failover     IP-based

Step 3: Feature-Based Decision Table

The “NOT” Rules (Eliminate Wrong Answers Fast)

The “CANNOT” List

Part 3: Scenario Pattern Recognition

Pattern: “Point root domain to AWS resource”

Keywords: example.com (no www), Zone Apex, ALB, CloudFront, root domain

Answer: Alias record (A type)

Why: CNAME cannot be used at Zone Apex. Alias can.

Pattern: “Minimize response time / Best user experience”

Keywords: lowest latency, best performance, fastest response, multi-region app

Answer: Latency-based routing

Why: Routes to AWS region with best network performance, regardless of geography.

Pattern: “Restrict access by country / Legal compliance”

Keywords: country restrictions, content localization, legal requirement, GDPR

Answer: Geolocation routing

Why: Routes based on user’s physical location, not network performance.

Pattern: “Gradual migration / Canary deployment”

Keywords: A/B testing, percentage of traffic, gradual rollout, 10% to new version

Answer: Weighted routing

Why: Control exact percentage of traffic to each resource.

Pattern: “Active-passive / Disaster recovery”

Keywords: primary and secondary, failover, standby, DR site

Answer: Failover routing policy + Health checks

Why: Automatically switches to secondary when primary fails health check.

Pattern: “On-premises needs to resolve AWS private domains”

Keywords: hybrid cloud, on-premises DNS, resolve Private Hosted Zone from datacenter

Answer: Inbound Resolver Endpoint

Why: Allows on-prem DNS servers to query Route 53 for AWS resources.

Pattern: “AWS resources need to resolve on-premises domains”

Keywords: EC2 needs to reach on-prem by hostname, resolve corp.local from VPC

Answer: Outbound Resolver Endpoint + Forwarding Rules

Why: Forwards DNS queries from VPC to on-premises DNS servers.

Pattern: “Users still seeing old IP after DNS change”

Keywords: DNS not updating, old IP, change not propagating

Answer: TTL caching issue

Solution: Wait for TTL to expire, or lower TTL before making changes.

Pattern: “Health check for private/internal resource”

Keywords: private subnet, internal EC2, RDS health, can’t reach from internet

Answer: CloudWatch Alarm-based health check

Why: Route 53 health checkers are public — can’t reach private resources.

Pattern: “Prevent DNS spoofing / Verify DNS authenticity”

Keywords: DNS security, cache poisoning, MITM, verify DNS response

Answer: DNSSEC

Remember: KMS key must be in us-east-1.

Pattern: “Share DNS configuration across accounts”

Keywords: multi-account, centralized DNS, share resolver rules

Answer: Resolver Rules + AWS RAM

Why: Resolver Rules can be shared across accounts via Resource Access Manager.

Pattern: “Buy domain elsewhere, use Route 53 for DNS”

Keywords: GoDaddy, third-party registrar, use Route 53

Answer: Create Public Hosted Zone → Update NS records at the registrar

Why: NS records tell the internet where to find your DNS. Update at registrar, not Route 53.

Part 4: Quick Reference Tables

Routing Policy Comparison

Record Type Quick Reference

Alias Targets (What Can Alias Point To?)

Health Check Types

Key Numbers to Remember

Part 5: Ultimate Instant-Answer Table

Part 6: Elimination Checklist

When stuck between options, eliminate systematically:

□ Is it Zone Apex (root domain)?
  → Yes = eliminate CNAME, must use Alias or A
  → No = CNAME is acceptable

□ Do they need health checks?
  → Yes = eliminate Simple routing
  → Failover REQUIRES health checks

□ Is it about USER LOCATION?
  → Physical location = Geolocation
  → Network performance = Latency

□ Is the resource PRIVATE?
  → Yes = eliminate direct HTTP health check
  → Use CloudWatch Alarm instead

□ Is it pointing to AWS resource?
  → Yes = prefer Alias (free, auto-tracking)
  → No = use CNAME or A record

□ Do they need traffic PERCENTAGE control?
  → Yes = Weighted routing
  → Just failover = Failover routing

□ Is it HYBRID (on-prem + AWS)?
  → On-prem queries AWS = Inbound Endpoint
  → AWS queries on-prem = Outbound Endpoint

□ Is it about DNS SECURITY?
  → Spoofing/authenticity = DNSSEC
  → KMS key must be in us-east-1

🏆 The Golden Rules

1. Zone Apex + AWS = Alias (CNAME doesn’t work at root)
2. Alias is FREE (CNAME costs money)
3. Alias TTL = auto-managed (you can’t set it)
4. Latency ≠ Geography (latency = network speed, geolocation = physical location)
5. Private resources = CloudWatch Alarm (health checkers can’t reach them)
6. Failover REQUIRES health checks (no health check = no failover)
7. Route 53 = DNS responses, not traffic routing (it returns IPs, doesn’t route packets)
8. Third-party registrar = update NS at registrar (not in Route 53)
9. Inbound = INTO AWS, Outbound = OUT OF AWS (from AWS perspective)
10. DNSSEC KMS key = us-east-1 (like CloudFront certificates)
11. Route 53 = 100% SLA (only AWS service with this guarantee)
12. Weight = 0 stops ALL traffic (useful for maintenance)

AWS CloudFront & Global Accelerator:

AWS Services: Global vs Regional:

Understanding which services are global vs regional is critical for:

• Certificate placement (ACM)
• Data residency requirements
• Disaster recovery planning
• Cross-region access patterns

Always Global Services (no region selection):

Regional Services (must select region):

Certificate (ACM) Placement Rules:

Memory trick: “Where does TLS terminate?”

• CloudFront terminates TLS → us-east-1
• Regional service terminates TLS → same region

Global Services That “Feel” Regional:

Cross-Region Capabilities Summary:

⚠️ Exam trap: “CloudHSM multi-region” → IMPOSSIBLE. CloudHSM is single-region only, no replication.

⚠️ Exam trap: “Same KMS key in two regions” → Possible with Multi-Region Keys (mrk- prefix). Regular keys are regional.

⚠️ Exam trap: “Lambda@Edge in eu-west-1” → Wrong. Lambda@Edge must be created in us-east-1, CloudFront replicates it.

AWS CloudFront is a Content Delivery Network (CDN), improves read performance, content is cached at the edge.

• Hundreds of Points of Presence globally (edge locations, caches)
• DDoS protection (worldwide), integrates with Shield + WAF

⚠️ Exam trap: CloudFront SSL/TLS certificates must be in us-east-1 (even if origin is in another region)

CloudFront Origins:

⚠️ Exam trap: “Restrict S3 access to CloudFront only” → OAC + S3 Bucket Policy

• Create OAC in CloudFront, update S3 bucket policy to allow only CloudFront
• Wrong: S3 Access Points = simplify access management, not redirect
• OAI (Origin Access Identity) = legacy, replaced by OAC

CloudFront with VPC Origin (Private Resources):

                                    ┌─────────────────────────────────────┐
                                    │ VPC                                 │
                                    │  ┌─────────────────────────────┐    │
Users ──▶ CloudFront ──▶ VPC Origin │  │ Private Subnet              │    │
          (Edge)                    │  │  ├─▶ ALB                    │    │
                                    │  │  ├─▶ NLB                    │    │
                                    │  │  └─▶ EC2                    │    │
                                    │  └─────────────────────────────┘    │
                                    └─────────────────────────────────────┘

CloudFront vs S3 Cross-Region Replication:

CloudFront Origin Groups (Failover)

• Origin Group = primary origin + secondary origin for failover
• CloudFront automatically fails over when primary returns error (5xx, 4xx, timeout)
• Use case: High availability, disaster recovery

CloudFront Origin Groups (Failover):

                         ┌─────────────────────┐
                         │   Origin Group      │
                         │                     │
Users ──▶ CloudFront ───▶│  Primary: S3 (us-east-1)
                         │      │              │
                         │      ▼ (on error)   │
                         │  Secondary: S3 (eu-west-1)
                         │                     │
                         └─────────────────────┘

⚠️ Exam trap: “CloudFront high availability” or “origin failover” → Origin Groups

• Not Route 53 failover (that’s DNS-level, not CDN-level)

CloudFront Cache Invalidations

• Origin updated → CloudFront doesn’t know until TTL expires
• Invalidation = force cache refresh, bypass TTL
• Invalidate all files (/*) or specific path (/images/*)

Cache Invalidation Flow:

Admin ──▶ Invalidate /images/* ──▶ CloudFront ──▶ Edge Locations
                                                   │
                                        ┌──────────┴──────────┐
                                        ▼                     ▼
                                   [Cache]               [Cache]
                                   index.html ✓          index.html ✓
                                   /images/ ✗            /images/ ✗
                                   (invalidated)         (invalidated)

CloudFront Behaviors & Path Patterns

Behaviors = rules that define how CloudFront handles requests for different paths

• Each distribution has a default behavior (matches all paths /*)
• Add custom behaviors for specific paths (e.g., /api/*, /images/*)
• Order matters: most specific path wins

CloudFront Behaviors Example:

Request Path          Behavior              Origin
─────────────────────────────────────────────────────
/api/*            ──▶ API Behavior     ──▶ ALB (no cache)
/images/*         ──▶ Images Behavior  ──▶ S3 (long TTL)
/static/*         ──▶ Static Behavior  ──▶ S3 (long TTL)
/* (everything)   ──▶ Default Behavior ──▶ ALB (short TTL)

⚠️ Exam traps:

• “Different cache settings for /api vs /images” → Behaviors with path patterns
• “Forward cookies only for /api/” → Custom behavior for /api/
• “Redirect HTTP to HTTPS” → Viewer Protocol Policy in behavior

CloudFront Signed URLs & Signed Cookies

• Distribute private content to authorized users
• Attach policy: URL expiration, allowed IP ranges, trusted signers

Signed URL vs S3 Pre-Signed URL:

⚠️ Exam trap: “Private content via CloudFront” → Signed URL/Cookie

• 1 file → Signed URL
• Multiple files → Signed Cookie
• Direct S3 access (no CF) → S3 Pre-Signed URL

CloudFront Functions vs Lambda@Edge

Both run code at edge locations, but different scale/capabilities:

CloudFront Request Flow:

                    CloudFront           CloudFront
                     Functions            Functions
                        │                     │
User ──▶ Viewer Request ▼ ──▶ Cache ──▶ Origin Request ──▶ Origin (S3/ALB)
              │                              │
              │         Lambda@Edge      Lambda@Edge
              │              │                │
         Viewer Response ◀───┘ ◀── Origin Response ◀──────┘

Use Cases:

⚠️ Exam traps:

• “Lightweight, high-scale” → CloudFront Functions
• “Network access, longer execution” → Lambda@Edge
• “Viewer-only triggers” → both work; “Origin triggers” → Lambda@Edge only

CloudFront Geo Restriction

• Restrict access by country (Allowlist or Blocklist)
• Country determined by 3rd party Geo-IP database
• Use case: Copyright laws, regional content licensing

⚠️ Exam trap: “Block/allow by country” → Geo Restriction

• Wrong: OAC = S3 origin access (not geo blocking)
• Wrong: Security Groups = can’t attach to CloudFront
• Wrong: Route 53 Latency = routes to nearest, doesn’t block

CloudFront Pricing & Price Classes

• Cost varies by edge location (US/EU cheapest → India most expensive)
• Reduce cost by limiting edge locations via Price Classes

⚠️ Exam trap: “Reduce CloudFront costs” → use Price Class 100/200 (fewer edge locations)

AWS Global Accelerator

Problem: Global users → public internet → many hops → high latency

Without Global Accelerator (Public Internet):

America ───┐
           │    ┌───┬───┬───┬───┐
Europe ────┼───▶│hop│hop│hop│hop│───▶ Public ALB (India)
           │    └───┴───┴───┴───┘
Australia ─┘         (latency)

Solution: Use AWS internal network via Anycast IPs

• Unicast IP: one server = one IP
• Anycast IP: all servers share same IP → client routed to nearest

How it works:

• 2 static Anycast IPs created for your app
• Traffic → nearest Edge Location → AWS private network → your app
• Up to 60% improvement in latency

With Global Accelerator:

Users ──▶ Anycast IP ──▶ Edge Location ──▶ AWS Private Network ──▶ ALB/NLB/EC2
          (static)       (nearest)         (fast, optimized)

Supported Targets: Elastic IP, EC2, ALB, NLB (public or private)

Features:

Endpoint Weights & Traffic Dial:

• Endpoint weights: distribute traffic % between endpoints in same group (0-255)
• Traffic dial: % of traffic to send to an endpoint group (0-100%)
• Use case: Blue/green deployments, gradual rollouts

Global Accelerator vs CloudFront

⚠️ Exam traps:

• “Non-HTTP” (gaming, IoT, VoIP) → Global Accelerator
• “Static IP required” → Global Accelerator
• “Fast regional failover” → Global Accelerator
• “Cache at edge” → CloudFront
• “Static IP + host-based routing + global” → Global Accelerator + ALB

Global Accelerator vs ELB vs Route 53

Scenario-Based Selection:

Failover Speed:

Route 53:         DNS TTL (30s - 5min+) before clients see change
Global Accel:     < 1 minute (health check driven, no DNS caching)

⚠️ Exam traps:

• “Fastest failover” → Global Accelerator (not Route 53)
• “DNS-based routing” → Route 53
• “Static IP + global” → Global Accelerator
• “Single region balancing” → ELB

⚠️ Exam trap — Blue-green deployment + DNS caching + tight deadline:

• Route 53 weighted routing seems logical but mobile devices cache DNS → users won’t see new deployment for hours/days
• Global Accelerator uses static Anycast IPs (no DNS change) → adjust endpoint weights to shift traffic instantly, no client caching issue
• ELB = single region only, can’t do cross-deployment traffic splitting
• CodeDeploy = deployment tool, doesn’t control traffic routing at network level
• Key trigger words: “DNS caching”, “mobile phones”, “tight timeframe”, “blue-green global” → Global Accelerator

CloudFront Field-Level Encryption

• Encrypt sensitive fields at edge (e.g., credit card numbers)
• Data stays encrypted through entire request flow → only your app can decrypt
• Uses asymmetric encryption (public key at edge, private key in app)

⚠️ Exam trap: “Encrypt specific form fields at edge” → Field-Level Encryption

• Different from HTTPS (encrypts entire payload, not specific fields)

Quick Reference: Service Comparison Matrix

Decision Tree:

🎯 MASTER SUMMARY: CloudFront & Global Accelerator Exam Guide

Part 1: Core Principles (Understand WHY → Derive WHAT)

Principle 1: Global vs Regional — Know Where Services Live

Understanding which services are global vs regional is fundamental for certificate placement, data residency, and cross-region patterns.

Always Global (no region selection):

• IAM, Route 53, CloudFront, Global Accelerator, WAF (for CloudFront), Organizations

Regional with Multi-Region Options:

• DynamoDB (Global Tables), Aurora (Global Database), KMS (Multi-Region Keys), Secrets Manager

Regional Only (no cross-region):

• CloudHSM, VPC, EC2, ELB

Derive: “Where does TLS terminate?” = where certificate must be

• CloudFront terminates TLS → cert in us-east-1
• Regional service terminates TLS → cert in same region

Principle 2: CloudFront = Content, Global Accelerator = Connections

Two different problems, two different solutions:

• CloudFront: Cache content at edge → reduce latency for static/dynamic content (HTTP/HTTPS)
• Global Accelerator: Route connections through AWS backbone → reduce latency for any TCP/UDP traffic

CloudFront caches. Global Accelerator proxies (no caching).

Principle 2: Edge Locations = AWS’s Global Presence

Both services use AWS’s 400+ edge locations worldwide:

• CloudFront: Caches content at edge, serves from nearest location
• Global Accelerator: Entry point to AWS private network, routes to your endpoints

Edge = closer to users = lower latency.

Principle 3: Anycast vs Unicast IPs

• Unicast: One IP = one server (traditional)
• Anycast: One IP = many servers, routed to nearest (Global Accelerator magic)

Global Accelerator gives you 2 static Anycast IPs → users connect to same IPs worldwide, routed to nearest edge.

Principle 4: TTL = Cache Control

CloudFront caches based on TTL (Time To Live):

• High TTL = better cache hit ratio, but stale content risk
• Low TTL = fresher content, but more origin requests
• Invalidation = force refresh, bypass TTL

Origin updates don’t propagate until TTL expires (or you invalidate).

Principle 5: Behaviors = Path-Based Routing

CloudFront Behaviors let you:

• Route different paths to different origins (/api/* → ALB, /images/* → S3)
• Apply different cache policies per path
• Set different viewer protocols (HTTP, HTTPS, redirect)

More specific path patterns take precedence.

Principle 6: Origin Access Control (OAC) = S3 Security

OAC ensures only CloudFront can access your S3 bucket:

• Create OAC in CloudFront
• Update S3 bucket policy to allow only CloudFront
• Users can’t bypass CloudFront to access S3 directly

OAI (Origin Access Identity) is legacy → use OAC.

Principle 7: Edge Compute = CloudFront Functions vs Lambda@Edge

Two options for running code at edge:

• CloudFront Functions: Lightweight, JavaScript, <1ms, millions req/sec, viewer triggers only
• Lambda@Edge: Full Lambda, Node.js/Python, up to 10s, network access, all triggers

Simple = CloudFront Functions. Complex = Lambda@Edge.

Principle 8: Failover Speed Matters

Different services, different failover speeds:

• Route 53: DNS TTL delay (30 sec to minutes)
• Global Accelerator: <1 minute (health check driven, no DNS caching)
• CloudFront Origin Groups: Automatic on origin error

Need instant failover? → Global Accelerator.

Part 2: Decision Tree (Follow Keywords → Find Answer)

Step 0: Is the service Global or Regional?

Which service?
│
├─► IAM, Route 53, CloudFront, Global Accelerator
│   └─► GLOBAL (no region, but CloudFront certs in us-east-1)
│
├─► DynamoDB, Aurora, KMS, Secrets Manager
│   └─► REGIONAL but has MULTI-REGION options
│
├─► CloudHSM
│   └─► REGIONAL ONLY (no cross-region!)
│
└─► EC2, ELB, VPC, Lambda, API Gateway
    └─► REGIONAL (deploy per region)

Step 1: HTTP or non-HTTP?

                    What protocol?
                          │
            ┌─────────────┴─────────────┐
            ▼                           ▼
      HTTP/HTTPS                   TCP/UDP (non-HTTP)
            │                           │
            ▼                           ▼
    Need caching?              Global Accelerator
            │                   (gaming, IoT, VoIP)
     ┌──────┴──────┐
     ▼             ▼
    Yes            No
     │             │
     ▼             ▼
CloudFront    Global Accelerator
              (if static IPs needed)

Step 2: What’s the main requirement?

                    What's the goal?
                          │
    ┌──────────┬──────────┼──────────┬──────────┐
    ▼          ▼          ▼          ▼          ▼
  Cache     Static     Fast      Edge      Block
 Content     IPs     Failover   Compute   Country
    │          │          │          │          │
    ▼          ▼          ▼          ▼          ▼
CloudFront  Global    Global    CloudFront  CloudFront
           Accel     Accel     Functions/   Geo
                               Lambda@Edge  Restriction

Step 3: Feature-Based Decision Table

The “NOT” Rules (Eliminate Wrong Answers Fast)

The “CANNOT” List

Part 3: Scenario Pattern Recognition

Pattern: “Cache static content globally”

Keywords: CDN, cache, static files, images, videos, global distribution

Answer: CloudFront

Why: CloudFront caches at 400+ edge locations. Global Accelerator doesn’t cache.

Pattern: “Gaming / IoT / VoIP application”

Keywords: UDP, TCP, gaming, real-time, MQTT, non-HTTP

Answer: Global Accelerator

Why: CloudFront = HTTP/HTTPS only. Global Accelerator supports any TCP/UDP.

Pattern: “Need static IPs for whitelisting”

Keywords: static IP, firewall whitelist, fixed IP addresses

Answer: Global Accelerator (2 Anycast IPs)

Why: CloudFront uses dynamic IPs. Global Accelerator provides 2 static Anycast IPs.

Pattern: “Fastest possible failover”

Keywords: instant failover, <1 minute, DR, disaster recovery

Answer: Global Accelerator

Why: Route 53 = DNS TTL delay. Global Accelerator = health-check driven, <1 min.

Pattern: “Origin failover for CloudFront”

Keywords: CloudFront HA, origin fails, backup origin

Answer: CloudFront Origin Groups

Why: Primary + secondary origin. Automatic failover on 4xx/5xx errors.

Pattern: “Restrict S3 access to CloudFront only”

Keywords: S3 only via CloudFront, prevent direct S3 access, secure S3 origin

Answer: OAC (Origin Access Control) + S3 Bucket Policy

Why: OAC creates CloudFront identity. S3 policy allows only that identity.

Pattern: “Private content via CloudFront”

Keywords: authenticated users, premium content, temporary access

Answer: Signed URL (1 file) or Signed Cookie (multiple files)

Why: Signed URLs/Cookies include expiration, IP restrictions, trusted signers.

Pattern: “Different settings for different paths”

Keywords: /api/, /images/, path-based, different cache, different origin

Answer: CloudFront Behaviors

Why: Each behavior = path pattern + origin + cache policy + settings.

Pattern: “Block users by country”

Keywords: geo blocking, country restriction, copyright, regional licensing

Answer: CloudFront Geo Restriction

Why: Allowlist or blocklist countries. Based on Geo-IP database.

Pattern: “Run code at edge (simple)”

Keywords: URL rewrite, header manipulation, JWT validation, lightweight

Answer: CloudFront Functions

Why: <1ms execution, JavaScript, millions req/sec, 1/6 cost of Lambda@Edge.

Pattern: “Run code at edge (complex)”

Keywords: database lookup, external API call, image resize, origin trigger

Answer: Lambda@Edge

Why: Up to 10s execution, network access, Node.js/Python, all 4 triggers.

Pattern: “Force cache refresh after update”

Keywords: stale content, cache not updating, force refresh

Answer: CloudFront Invalidation

Why: Bypass TTL, force edge locations to fetch new content from origin.

Pattern: “Reduce CloudFront costs”

Keywords: cost optimization, cheaper CDN, reduce edge locations

Answer: Price Class 100 or 200

Why: Fewer edge locations = lower cost (but potentially higher latency for excluded regions).

Pattern: “Encrypt specific form fields”

Keywords: credit card encryption, PII at edge, field-level security

Answer: CloudFront Field-Level Encryption

Why: Encrypts specific fields at edge → stays encrypted through entire flow.

Pattern: “SSL certificate for CloudFront”

Keywords: HTTPS, custom domain, SSL/TLS certificate

Answer: ACM certificate in us-east-1

Why: CloudFront is global but requires certificates in us-east-1 region.

Part 4: Quick Reference Tables

Global vs Regional Services

*Edge-Optimized API Gateway lives in one region but uses CloudFront for routing

CloudFront vs Global Accelerator

CloudFront Functions vs Lambda@Edge

Signed URL vs Signed Cookie vs S3 Pre-Signed URL

Service Comparison: When to Use What

Failover Speed Comparison

CloudFront Origin Types

Key Numbers to Remember

Part 5: Ultimate Instant-Answer Table

Part 6: Elimination Checklist

When stuck between options, eliminate systematically:

□ Is it HTTP/HTTPS?
  → Yes = CloudFront or Global Accelerator
  → No (UDP, raw TCP) = Global Accelerator only

□ Do they need CACHING?
  → Yes = CloudFront
  → No = Global Accelerator (or neither)

□ Do they need STATIC IPs?
  → Yes = Global Accelerator (or NLB)
  → No = CloudFront is fine

□ What's the FAILOVER requirement?
  → Instant (<1 min) = Global Accelerator
  → DNS-based = Route 53
  → Origin failover = CloudFront Origin Groups

□ Is it about EDGE COMPUTE?
  → Simple (headers, rewrites) = CloudFront Functions
  → Complex (network, DB) = Lambda@Edge
  → Origin triggers = Lambda@Edge only

□ Is it about PRIVATE CONTENT?
  → 1 file = Signed URL
  → Multiple files = Signed Cookie
  → Direct S3 = S3 Pre-Signed URL

□ Is it about S3 ORIGIN SECURITY?
  → Restrict to CloudFront = OAC + Bucket Policy
  → OAI mentioned = legacy, use OAC

□ Is it about COUNTRY RESTRICTION?
  → Block/allow by country = Geo Restriction
  → Not Security Groups (can't attach to CF)

□ What REGION for SSL cert?
  → CloudFront = us-east-1 (always)
  → ALB = same region as ALB

🏆 The Golden Rules

1. Global services = IAM, Route 53, CloudFront, Global Accelerator — no region selection
2. CloudHSM = regional ONLY — no cross-region replication (unlike KMS Multi-Region)
3. CloudFront cert MUST be in us-east-1 — even if origin elsewhere
4. Lambda@Edge authored in us-east-1 — CloudFront replicates globally
5. Edge-Optimized API Gateway cert in us-east-1 — uses CloudFront behind scenes
6. Regional API Gateway cert in same region — no CloudFront involved
7. CloudFront = caching, Global Accelerator = routing — different purposes
8. Non-HTTP (gaming, IoT, VoIP) = Global Accelerator — CloudFront is HTTP only
9. Static IPs = Global Accelerator — 2 Anycast IPs
10. Fastest failover = Global Accelerator — <1 min, no DNS TTL delay
11. Origin failover = Origin Groups — primary + secondary origin
12. OAC replaces OAI — use OAC for S3 origin security
13. Signed URL = 1 file, Signed Cookie = many files
14. CloudFront Functions = lightweight, Lambda@Edge = complex
15. Origin triggers = Lambda@Edge only — CloudFront Functions = viewer only
16. Price Class = cost control — fewer regions = lower cost
17. Invalidation = force refresh — bypass TTL for immediate updates
18. Global Accelerator doesn’t cache — it proxies packets through AWS backbone

AWS EC2 (Elastic Compute Cloud)

EC2 (Elastic Compute Cloud) is virtual computer (instance) in the cloud.
EC2 consists:

• Renting virtual machine (EC2);
• Storing data on virtual machine (EBS);
• Distributing load across machines (ELB);
• Scaling the services using an auto-scaling group (ASG).

EC2 configuration options:

• Operating System (OS): Linux, Windows or Mac OS;
• How much compute power & cores (CPU);
• How much random-access memory (RAM);
• How much storage space:
  • Network-attached (EBS & EFS);
  • Hardware (EC2 Instance Store).
• Network card: speed of the card, Public IP address;
• Bootstrap script (launching commands when a machine starts for the first time): EC2 User Data - Installing updates, Downloading files and etc.

EC2 Instance Types:

• General Purpose: provides a balance of compute, memory, and networking resources:
  • application servers;
  • gaming servers;
  • backend servers for enterprise applications;
  • small and medium databases;
• Compute Optimized: processing workloads, media transcoding, high-performance web servers, machine learning and etc;
  • high-performance web servers;
  • compute-intensive applications servers;
  • dedicated gaming servers
  • batch processing workloads (that require processing many transactions in a single group);
• Memory Optimized: real-time processing of large unstructured in-memory data sets (preloaded in memory before running an application);
  • high-performance database;
  • real-time processing of a large amount of unstructured data;
• Accelerated Computing: use directly on hardware accelerators, or coprocessors, which is more efficiently than is possible in software running on CPUs:
  • functions with floating-point number calculations;
  • graphics processing;
  • data pattern matching;
• Storage Optimized: designed for workloads that require high, sequential read and write access to large datasets on local storage;
  • SQl and NoSQL databases;
  • data warehousing applications;
  • distributed file systems;
  • high-frequency online transaction processing (OLTP) systems;
• HPC Optimized: built to offer the best price performance for running HPC workloads at scale on AWS, for applications that benefit from high-performance processors;
  • large, complex simulations;
  • deep learning workloads.

T/M → General (Typical, Moderate) C → Compute (CPU) R → Memory (RAM) P/G → Accelerated (Processing/GPU) I/D → Storage (I/O, Disk)

r6i.2xlarge │││ └─── Size within the instance class ││└────── Additional capabilities (i = Intel) │└─────── Generation of hardware (6th) └──────── Family - instance class (R = Memory Optimized)

EC2 Placement group: control over the EC2 Instance placement strategy. Placement group strategies:

• Cluster—clusters instances into a low-latency group in a single Availability Zone (10 Gbps bandwidth). AZ fail causes full outage;
• Spread—spreads instances across underlying hardware (max 7 instances per group per AZ). Maximizes high availability via isolation;
• Partition—spreads instances across many different partitions (which rely on different sets of racks) within an AZ. Scales to 100s of EC2 instances per group (Hadoop, Cassandra, Kafka).

CLUSTER (same rack)        SPREAD (diff racks)       PARTITION (diff racks)
┌─────────────────┐        ┌───┐ ┌───┐ ┌───┐        ┌─────┐ ┌─────┐ ┌─────┐
│ ┌──┐┌──┐┌──┐┌──┐│        │EC2│ │EC2│ │EC2│        │Part1│ │Part2│ │Part3│
│ │  ││  ││  ││  ││        └───┘ └───┘ └───┘        │┌──┐ │ │┌──┐ │ │┌──┐ │
│ └──┘└──┘└──┘└──┘│        Rack1 Rack2 Rack3        ││  │ │ ││  │ │ ││  │ │
└─────────────────┘        (max 7 per AZ)           │└──┘ │ │└──┘ │ │└──┘ │
  10 Gbps, 1 AZ                                     └─────┘ └─────┘ └─────┘
  Low latency              High availability        100s instances (Kafka)

⚠️ Exam trap: Cluster = same rack (low latency, high risk); Spread = different racks (max 7/AZ); Partition = different racks (100s instances, Kafka/Cassandra)

AMI (Amazon Machine Image) - customization of an EC2 instance, added ext. software.

• A Public AMI: Amazon provided;
• Your own AMI: you make and maintain them yourself;
• An AWS Marketplace AMI: an AMI someone else made (and potentially sells).

⚠️ Exam trap: AMIs are region-specific. Cannot launch EC2 from AMI in another region — must copy AMI to target region first (creates new AMI ID)

EC2 Image Builder service to automate the creation, maintain, validate and test of Virtual Machine or container images. Can be run on schedule.

Elastic Network Interfaces (ENI): logical component in a VPC that represents a virtual network card. Bound to a specific AZ.

ENI attributes:

• Primary private IPv4, one or more secondary IPv4;
• One Elastic IP (IPv4) per private IPv4;
• One Public IPv4;
• One or more security groups to each ENI;
• MAC address to each ENI.

NOTE: You can create ENI independently and attach them on the fly (move them) on EC2 instances for failover.

Security Groups vs NACLs:

┌─────────────────────────────────────────────────────────┐
│                         VPC                             │
│  ┌───────────────────────────────────────────────────┐  │
│  │           Subnet (with NACL)                      │  │
│  │  ┌─────────────────────┐  ┌─────────────────────┐ │  │
│  │  │ Security Group      │  │ Security Group      │ │  │
│  │  │  ┌───────────────┐  │  │  ┌───────────────┐  │ │  │
│  │  │  │      EC2      │  │  │  │      EC2      │  │ │  │
│  │  │  └───────────────┘  │  │  └───────────────┘  │ │  │
│  │  └─────────────────────┘  └─────────────────────┘ │  │
│  └───────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────┘

⚠️ Exam trap: Security Groups = stateful (allow inbound → outbound auto-allowed). NACLs = stateless (must explicitly allow both directions)

EC2 Instance Lifecycle:

• Stop: data on EBS disk kept intact for next start
• Terminate: root EBS volumes destroyed (unless configured otherwise)
• Start behavior:
  • First start: OS boots + EC2 User Data script runs
  • Following starts: OS boots + applications start + caches warm up (takes time)

EC2 Hibernate:

• In-memory (RAM) state is preserved → much faster boot (OS not stopped/restarted)
• How it works: RAM state written to file in root EBS volume
• Root EBS volume must be encrypted
• Use cases: long-running processing, saving RAM state, services with slow initialization

EC2 Hibernate - Requirements & Limits:

• Instance RAM: must be < 150 GB
• Root volume: must be EBS, encrypted, not instance store, and large enough
• Supported purchasing options: On-Demand, Reserved, and Spot Instances
• NOT supported: Dedicated Hosts, bare metal instances
• Max hibernation period: 60 days

⚠️ Exam trap: Root EBS must be encrypted for hibernate. Max 60 days, max 150GB RAM

EC2 Purchasing Options:

Spot Instances:

• Can be interrupted with 2-minute warning
• Define max spot price — terminated if current price > max
• Spot Block (deprecated): 1-6 hour uninterrupted blocks
• Spot Fleet: collection of Spot + On-Demand instances

⚠️ Exam trap: Spot = cheapest but can be terminated. Use for batch jobs, data analysis, CI/CD, NOT databases

Reserved Instances:

• Standard RI: Up to 72% discount, can change AZ, instance size (same family)
• Convertible RI: Up to 66% discount, can change instance family, OS, tenancy
• Scheduled RI (deprecated): Reserve for specific time windows

⚠️ Exam trap: Reserved = commit for 1-3 years. Convertible RI = less discount but more flexibility

Connect to EC2:
ssh -i /<path>/<key_pair_name>.pem <instance_user_name>@<instance_public_dns_name/IP>
Example:
ssh -i /home/kali/Downloads/aws.pem ubuntu@51.20.123.211

🎯 MASTER SUMMARY: EC2 Exam Guide

Part 1: Core Principles (Understand WHY → Derive WHAT)

Principle 1: EC2 is Just a Virtual Computer — Everything Else Solves Its Limitations

EC2 alone is just a VM. The entire ecosystem exists to solve its inherent problems:

• Single point of failure → ELB (distribute load), ASG (replace failed instances)
• Data loss on termination → EBS (persistent storage), EFS (shared storage)
• Manual scaling → ASG (automatic scaling)
• No redundancy → Placement groups, Multi-AZ deployments

Deriving answers: When you see a limitation scenario, think: “What problem is this solving?” The answer maps to the appropriate service.

Principle 2: Instance Types = Optimize for the Bottleneck

Every workload has a bottleneck. Match the instance family to it:

Deriving answers: “Processing large datasets in-memory” → Bottleneck is RAM → R family. “Batch processing” → Bottleneck is CPU → C family.

Principle 3: Placement Groups Trade-off = Latency vs. Availability

You can’t have both maximum performance AND maximum availability. Choose your priority:

Deriving answers:

• “10 Gbps network” or “lowest latency” → Cluster (same rack = fastest network)
• “Critical application, high availability” → Spread (isolation = safety)
• “Hadoop, Kafka, Cassandra” → Partition (needs both scale AND isolation)

Principle 4: AMI = Snapshot of Everything, But Region-Locked

An AMI is a complete image (OS + software + config). The trade-off: specificity vs. portability.

• AMIs are region-specific — they can’t cross region boundaries without copying
• Copy creates a NEW AMI ID in the target region

Deriving answers: “Launch instance in another region from existing AMI” → Must copy first (can’t use original AMI ID)

Principle 5: Security Groups vs NACLs = Instance vs. Subnet, Stateful vs. Stateless

WHY stateful matters: If you allow traffic IN, the response OUT is automatic. You don’t need to think about return traffic.

WHY stateless matters: You must explicitly allow BOTH directions. More control, more work.

Deriving answers: “Block specific IP” → NACLs (SGs can’t deny). “Allow port 443 inbound” → Both work, but SGs don’t need outbound rule.

Principle 6: Hibernate = RAM Preserved, But Has Constraints

WHY hibernate exists: Cold boots are slow because RAM is empty. Hibernate saves RAM state.

WHY encryption is required: RAM contains sensitive data — writing it to disk unencrypted = security risk.

Deriving answers:

• “Reduce startup time” + “preserve state” → Hibernate
• Root volume NOT encrypted? → Hibernate won’t work
• RAM > 150GB? → Hibernate won’t work
• Hibernation > 60 days? → Not supported

Principle 7: Purchasing Options = Trade Money for Flexibility

The fundamental trade-off: commitment = savings. More flexibility = more cost.

Most Expensive                                    Cheapest
(Most Flexible)                                   (Least Flexible)
     │                                                  │
     ▼                                                  ▼
On-Demand ─→ Capacity Res ─→ Savings Plans ─→ Reserved ─→ Spot
   100%         100%            ~72%            ~72%      ~90%

But Spot has a catch: AWS can take it back. Use only for work that can be interrupted.

The Mental Model:

• “I need it now, unpredictable duration” → On-Demand
• “I’ll commit to using X amount” → Reserved/Savings Plans
• “I can handle interruption” → Spot
• “I need the capacity but can’t commit” → Capacity Reservation (no discount)

Principle 8: Dedicated = Compliance, Not Performance

Dedicated Hosts and Dedicated Instances exist for compliance, not speed.

Deriving answers: “Bring your own license” or “socket-based licensing” → Dedicated Host

Principle 9: Spot Instances = Interruptible, 2-Minute Warning

Spot is AWS’s “leftover capacity” at a discount. The trade-off: they can take it back.

Critical rules:

• 2-minute warning before termination
• Define max price — terminated if current price exceeds max
• Spot Fleet = pool of Spot + On-Demand (for reliability)

Good for: Batch processing, CI/CD, data analysis, anything that can restart Bad for: Databases, user-facing apps, anything that can’t handle interruption

Principle 10: EC2 Lifecycle = What Happens to Your Data?

Deriving answers: “Data survives restart?” → EBS only. “RAM survives?” → Hibernate only.

Part 2: Decision Tree (Follow Keywords → Find Answer)

Instance Type Selection

What's the bottleneck?
        │
        ├─→ "Nothing specific" ─────────────→ T/M (General Purpose)
        │
        ├─→ "CPU" / "batch" / "compute" ───→ C (Compute)
        │
        ├─→ "RAM" / "in-memory" / "cache" ─→ R (Memory)
        │
        ├─→ "GPU" / "ML" / "AI" ───────────→ P/G (Accelerated)
        │
        └─→ "IOPS" / "database" / "OLTP" ──→ I/D (Storage)

Placement Group Selection

What's the priority?
        │
        ├─→ "Lowest latency" / "10 Gbps" ──→ Cluster
        │
        ├─→ "High availability" / "isolation" ─→ Spread (max 7/AZ)
        │
        └─→ "Kafka" / "Hadoop" / "Cassandra" ─→ Partition

Purchasing Option Selection

Can it be interrupted?
        │
        ├─→ YES ─────────────────────────────→ Spot (90% savings)
        │
        └─→ NO
             │
             └─→ How long do you need it?
                      │
                      ├─→ "Hours/days" ──────→ On-Demand
                      │
                      ├─→ "1-3 years" ───────→ Reserved/Savings Plans
                      │
                      └─→ "Guaranteed capacity, no commit" ─→ Capacity Res

The “CANNOT” List

Part 3: Scenario Pattern Recognition

Pattern: “Need lowest network latency between instances”

Keywords: low latency, 10 Gbps, HPC, tightly coupled Answer: Cluster placement group Why: Same rack = same network switch = lowest latency. Trade-off is single point of failure.

Pattern: “Critical application, maximize availability”

Keywords: high availability, fault tolerance, critical, isolated Answer: Spread placement group Why: Different racks = different failure domains. Limit: 7 instances per AZ.

Pattern: “Kafka/Hadoop/Cassandra with 100s of instances”

Keywords: Kafka, Hadoop, Cassandra, distributed, large scale, partitions Answer: Partition placement group Why: Partition-aware applications distribute replicas across partitions. Scales to 100s.

Pattern: “Processing large in-memory datasets”

Keywords: in-memory, real-time analytics, caching, SAP HANA Answer: Memory Optimized (R family) Why: Bottleneck is RAM. R = RAM.

Pattern: “Batch processing, video encoding”

Keywords: batch, transcoding, compute-intensive, scientific modeling Answer: Compute Optimized (C family) Why: Bottleneck is CPU. C = CPU.

Pattern: “Cost-effective, fault-tolerant workload”

Keywords: cost-effective, can tolerate interruption, batch, CI/CD Answer: Spot Instances Why: 90% savings, but can be interrupted with 2-min warning. OK for resilient workloads.

Pattern: “Steady-state database, long-term”

Keywords: database, steady, 24/7, long-term, predictable Answer: Reserved Instances Why: 72% savings for 1-3 year commitment. Databases run continuously.

Pattern: “Bring your own license (BYOL)”

Keywords: BYOL, per-socket, per-core, software license Answer: Dedicated Host Why: You need visibility into physical server (sockets/cores) for licensing.

Pattern: “Reduce startup time, preserve application state”

Keywords: fast boot, preserve RAM, reduce initialization time Answer: EC2 Hibernate Why: RAM saved to EBS, no cold boot. Must have encrypted root volume.

Pattern: “Block specific IP address”

Keywords: block IP, deny traffic, blacklist Answer: NACL (not Security Group) Why: Security Groups can only ALLOW. NACLs can DENY.

Pattern: “Launch instance in another region from existing AMI”

Keywords: cross-region, AMI, different region Answer: Copy AMI to target region first Why: AMIs are region-specific. Cannot use AMI ID from another region.

Pattern: “Compliance requires dedicated hardware, don’t need server visibility”

Keywords: compliance, dedicated, isolated hardware Answer: Dedicated Instance Why: Simpler than Dedicated Host when you don’t need socket/core visibility.

Pattern: “Need guaranteed capacity in specific AZ, no long-term commitment”

Keywords: capacity, guarantee, specific AZ, no discount needed Answer: On-Demand Capacity Reservation Why: Reserves capacity immediately. No commitment required, but no discount either.

Pattern: “Flexible commitment across instance types”

Keywords: flexible, multiple instance types, Savings Plans Answer: Compute Savings Plans Why: Commit $/hour, use across any instance type/region. More flexible than Reserved.

Part 4: Quick Reference Tables

Instance Type Families

Placement Group Comparison

Purchasing Options Quick Comparison

Hibernate Requirements

Part 5: Ultimate Instant-Answer Table

Part 6: Elimination Checklist

Choosing Instance Type

□ Is the workload CPU-bound?
  → Yes = C family
  → No = continue

□ Does it need lots of RAM?
  → Yes = R family
  → No = continue

□ Does it need GPU?
  → Yes = P/G family
  → No = continue

□ Does it need high disk IOPS?
  → Yes = I/D family
  → No = T/M (General Purpose)

Choosing Purchasing Option

□ Can workload tolerate interruption?
  → Yes = Consider Spot (90% savings)
  → No = continue

□ Is usage predictable for 1-3 years?
  → Yes = Reserved or Savings Plans
  → No = continue

□ Do you need flexibility across instance types?
  → Yes = Savings Plans
  → No = Reserved Instances

□ Short-term, unpredictable?
  → Yes = On-Demand

Choosing Placement Group

□ Need lowest possible latency?
  → Yes = Cluster
  → No = continue

□ Need maximum isolation/availability?
  → Yes = Spread (max 7/AZ)
  → No = continue

□ Running Kafka/Hadoop/Cassandra at scale?
  → Yes = Partition
  → No = No placement group needed

Hibernate Eligibility

□ Is root volume EBS and encrypted?
  → No = Hibernate NOT available
  
□ Is RAM < 150GB?
  → No = Hibernate NOT available
  
□ Is it Dedicated Host or bare metal?
  → Yes = Hibernate NOT available
  
□ All above passed?
  → Hibernate available

🏆 The Golden Rules

1. Instance family = bottleneck (C=CPU, R=RAM, I/D=Disk, P/G=GPU)
2. Cluster = same rack = fastest but risky (one failure = all fail)
3. Spread = different racks = safest (max 7 instances per AZ)
4. Partition = different racks + scale (Kafka, Hadoop, Cassandra)
5. AMIs are region-locked (copy to use in another region)
6. Security Groups = allow only, stateful (NACLs = allow+deny, stateless)
7. Hibernate = RAM preserved (needs encrypted EBS, <150GB RAM, max 60 days)
8. Spot = cheapest but interruptible (90% savings, 2-min warning)
9. Reserved = commit for savings (72%, 1-3 years)
10. Dedicated Host = you see the server (for BYOL, socket licensing)
11. NACL to DENY, SG to ALLOW (SGs can’t block specific IPs)
12. Savings Plans = flexible Reserved (commit $/hour, not instance type)

Storage:

Amazon EC2 Instance store provides temporary block-level storage for your instance. This storage is located on disks that are physically attached to the host computer. Instance store is ideal for temporary storage of information that changes frequently, such as buffers, caches, scratch data, and other temporary content. It can also be used to store temporary data that you replicate across a fleet of instances, such as a load-balanced pool of web servers.

Amazon EBS (Elastic Block Store) volume is a block-level storage, it’s a network drive, not physical drive - uses the network to communicate the instance, has a bit of latency. EBS has a provisioned capacity (size in GBs, and IOPS) that can be increased over time (billed by provisioned, not used).

• Can be attached to instances quickly and while they run. It allows instances to persist data, even after termination;
• Can be mounted only to one instance at a time. And locked to a specific availability zone. (To move to another AZ use EBS Snapshot).

EBS Delete on Termination attribute controls the EBS behaviour when an EC2 instance terminates. Root EBS volme is going to be deleted by default, any other attached EBS volume will get disabled Termination attribute.

EBS Snapshot backup (snapshot) of your EBS volume at a point in time. Not necessary to detach volume, but recommended. Snapshots consume IO - avoid during high traffic. Possible to copy snapshots across AZ or Regions. EBS Snapshot Archive EBS Snapshots could be moved to Archive (that is 75% cheaper, but it takes within 24 to 72 hours for restoring the archive).* Recycle Bin rules to retain deleted snapshots to recover them after an accidental deletion (from 1 day to 1 year) Fast Snapshot Restore (FSR) - eliminates latency on first use of EBS volume created from snapshot by pre-initializing all data blocks. Without FSR, volumes load data lazily from S3 causing performance penalty until “warmed up”. Enabled per snapshot per AZ. Expensive - use for critical workloads needing immediate full performance (databases, time-sensitive apps).

EBS Snapshot - Cross-Region & Encryption Flow:

┌─────────┐   snapshot   ┌───────────┐   copy      ┌───────────┐
│   EBS   │ ───────────→ │  Snapshot │ ─────────→  │  Snapshot │
│ (AZ-A)  │              │ (Region A)│  (encrypt)  │ (Region B)│
└─────────┘              └─────┬─────┘             └─────┬─────┘
                               │ restore                 │ restore
                               ▼                         ▼
                         ┌─────────┐               ┌─────────┐
                         │   EBS   │               │   EBS   │
                         │ (AZ-A)  │               │ (AZ-X)  │
                         └─────────┘               └─────────┘

• Snapshots are stored in S3 (region-level, not AZ-locked)
• Can copy to another region for DR
• Can enable encryption during copy (encrypt unencrypted volume)

Local EC2 Instance Store a high-performance hardware disk (better I/O performance than network drives - EBS volumes). Good for buffer / cache / scratch data / temporary content (Risk of data loss if hardware fails). Backups and Replication are your responsibility

⚠️ Exam trap: Instance Store = ephemeral (data lost on stop/terminate). Best I/O performance but no persistence

Instance Store Limitations:

• Ephemeral: data lost on stop/terminate/hardware failure;
• Cannot detach/reattach: tied to specific instance;
• No snapshots: manual backups required;
• Fixed size: varies by instance type, cannot resize (e.g., i3.large: 475 GB, i4i.32xlarge: 30 TB);
• Cannot add after launch: must be specified at instance creation.

EBS Volume Types

• General Purpose SSD (1 GiB - 16 TiB): General purpose SSD volume that balances price (cost effective storage) and performance (low-latency) for a wide variety of workloads: System boot volumes, Virtual desktops, Development and test environments;
  • gp2 (older): 3,000 - 16,000 IOPS (linked to size - 3 IOPS per GB, means max IOPS at 5,334 GB);
  • gp3 (newer): 3,000 - 16,000 IOPS, 125 - 1000 MiB/s (independent from IOPS size);

⚠️ Exam trap: gp2 IOPS linked to size (3 IOPS/GB); gp3 IOPS independent — know the difference!

Provisioned IOPS (PIOPS) SSD - Highest-performance SSD volume for mission-critical low-latency or high-throughput workloads: System boot volumes, databases workloads. Supports EBS Multi-attach; - io1: 4 GiB - 16 TiB, up to 64,000 IOPS (linked to size - 50 IOPS per 1 GiB, max IOPS at 1,280 GB); - io2 (higher durability - 99.999%): 4 GiB - 16 TiB, up to 64,000 IOPS (linked to size - 50 IOPS per 1 GiB, max IOPS at 1,280 GB); - io2 Block Express (sub-ms latency): 4 GiB - 64 TiB, up to 256,000 IOPS, (linked to size - 50 IOPS per 1 GiB, max IOPS at 1,280 GB);

EBS Multi-Attach: Achieve higher application availability in clustered Linux applications (ex: Teradata) by connecting the same EBS volume to multiple (up to 16) EC2 Instances at a time. Must be in the same AZ and only cluster-aware (GFS2, OCFS2, and NOT EXT4/XFS) file system is supported.

*64,000 IOPS on Nitro instances, 32,000 on others

HDD Volume Types (Cannot be boot volumes)

• st1 (HDD): 125 GiB - 16 TiB, up to 500 IOPS, max 500 MiB/s (independent from IOPS size); Low cost HDD volume designed for frequently accessed, throughput-intensive workloads: Big Data, Data Warehouses, Log Processing;
• sc1 (HDD): 125 GiB - 16 TiB, up to 250 IOPS, max to 250 MiB/s (independent from IOPS size); Lowest cost HDD volume designed for less frequently accessed workloads: Infrequent access, lowest cost;

⚠️ Exam trap: HDD (st1/sc1) cannot be boot volumes. Only SSD (gp2/gp3/io1/io2) can boot

EBS Encryption: Fully managed, transparent encryption using KMS (AES-256) with minimal latency impact. Encrypts:

• Data at rest inside the volume;
• Data in flight between instance and volume;
• All snapshots created from the volume;
• All volumes created from encrypted snapshots.

*Encrypt unencrypted EBS volume: Create snapshot → Copy snapshot with encryption enabled → Create volume from encrypted snapshot → Attach to instance.

Amazon EFS (Elastic File System) - managed NFS that can be mounted on many EC2 instances and on-premises (multi-AZ). Highly available, auto-scaling (petabytes, no capacity planning), expensive (~3x gp2 cost, pay-per-use). Use cases: content management, web serving, data sharing, WordPress.

• NFSv4.1 protocol; access controlled via security groups;
• Linux only (POSIX file system); encryption at rest using KMS.

⚠️ Exam trap: EFS = Linux only (POSIX). Performance Mode cannot be changed after creation; Throughput Mode can

EFS Performance & Throughput Modes:

• Performance Mode (Set at creation, CAN NOT be changed later):
  • General Purpose (default): latency-sensitive (web server, CMS);
  • Max I/O: higher latency, higher throughput, highly parallel (big data, media processing);
• Throughput Mode (CAN be changed anytime):
  • Bursting: 1 TB = 50 MiB/s + burst up to 100 MiB/s;
  • Provisioned: set throughput regardless of size (e.g., 1 GiB/s for 1 TB);
  • Elastic: auto-scales (up to 3 GiB/s reads, 1 GiB/s writes) - for unpredictable workloads.

EFS Storage Classes (lifecycle policies move files after N days):

• Storage Tiers:
  • Standard: frequently accessed files;
  • Infrequent Access (EFS-IA): lower storage cost, retrieval fee (up to 92% cheaper);
  • Archive: rarely accessed (few times/year), 50% cheaper than IA;
• Availability:
  • Standard: Multi-AZ for production;
  • One Zone: single AZ, for dev (90%+ cost savings), backup enabled by default.

Amazon FSx for Windows File Server fully managed, highly reliable and scalable Windows native shared file system based on SMB protocol and Windows NTFS (Integrated with Microsoft Active Directory).

Amazon FSx for Lustre (Linux cluster) a fully managed high-performance, scalable file system for High Performance Computing (HPC): machine learning, analytics, video processing and financial modeling.

Instance Store vs EBS vs EFS:

┌─────────────┐     ┌─────────────┐     ┌─────────────────────────┐
│ Instance    │     │    EBS      │     │          EFS            │
│   Store     │     │  (Network)  │     │     (Multi-AZ NFS)      │
├─────────────┤     ├─────────────┤     ├─────────────────────────┤
│ ┌─────────┐ │     │   ┌─────┐   │     │   ┌───┐ ┌───┐ ┌───┐    │
│ │   EC2   │ │     │   │ EC2 │   │     │   │EC2│ │EC2│ │EC2│    │
│ │ ┌─────┐ │ │     │   └──┬──┘   │     │   └─┬─┘ └─┬─┘ └─┬─┘    │
│ │ │Disk │ │ │     │      │      │     │     └─────┼─────┘      │
│ │ └─────┘ │ │     │   ┌──┴──┐   │     │       ┌───┴───┐        │
│ └─────────┘ │     │   │ EBS │   │     │       │  EFS  │        │
└─────────────┘     │   └─────┘   │     └───────┴───────┴────────┘
  Ephemeral         └─────────────┘         Shared across AZs
  Best I/O            Single AZ             Linux only, pay-per-use

AWS Storage Gateway: bridge between on-premise data and cloud data in S3, hybrid storage service to allow on-premise to seamlessly use the AWS Cloud. Use cases: disaster recovery, backup & restore, tiered storage.

Types of Storage Gateway:

• File Gateway:
  • Amazon S3: a file interface that enables you to store files as objects in Amazon S3 using the industry-standard NFS and SMB file protocols;
  • Amazon FSx fully managed, highly reliable, and scalable file shares in the cloud using the industry-standard NFS and SMB protocols;
• Volume Gateway: applications’ block storage volumes using the iSCSI protocol. Data written to these volumes can be asynchronously backed up as point-in-time snapshots of your volumes, and stored in the cloud as Amazon EBS snapshots. It’s possible to back up on-premises Volume Gateway volumes using the service’s native snapshot scheduler or by using the AWS Backup service;
• Tape Gateway: an iSCSI-based virtual tape library (VTL) of virtual tape drives.

        On-Premises                              AWS Cloud
┌─────────────────────────┐              ┌─────────────────────────┐
│                         │              │                         │
│  ┌───────────────────┐  │              │  ┌─────────────────┐    │
│  │   File Gateway    │──┼──────────────┼─→│   S3 / FSx      │    │
│  └───────────────────┘  │   NFS/SMB    │  └─────────────────┘    │
│                         │              │                         │
│  ┌───────────────────┐  │              │  ┌─────────────────┐    │
│  │  Volume Gateway   │──┼──────────────┼─→│  EBS Snapshots  │    │
│  └───────────────────┘  │   iSCSI      │  └─────────────────┘    │
│                         │              │                         │
│  ┌───────────────────┐  │              │  ┌─────────────────┐    │
│  │   Tape Gateway    │──┼──────────────┼─→│ S3 Glacier/Deep │    │
│  └───────────────────┘  │   VTL        │  └─────────────────┘    │
└─────────────────────────┘              └─────────────────────────┘

⚠️ Exam trap: File Gateway = S3/FSx (NFS/SMB); Volume Gateway = EBS snapshots (iSCSI); Tape Gateway = Glacier (VTL)

AWS S3:

S3 (Simple Storage Service) provides object storage through a web service interface — “infinitely scaling” storage.
Amazon S3: allows to store objects (files) in ‘buckets’ (directories).
Amazon S3 offers unlimited storage space. The maximum file size for an object in Amazon S3 is 5 TB.

Use Cases: Backup/storage, Disaster Recovery, Archive, Hybrid Cloud storage, Media hosting, Data lakes & big data analytics, Static websites, Software delivery

Buckets:

• Must have globally unique name (across all regions, all accounts)
• Defined at the region level (looks global in console, but created in a region)

⚠️ Exam trap: “Can’t create bucket” + correct IAM permissions → name already taken globally

Naming convention:

• No uppercase, No underscore;
• 3-63 characters long;
• Not an IP;
• Must start with lowercase letter or number;
• Must NOT start with the prefix xn–;
• Must NOT end with the suffix -s3alias.

Objects have a Key, which is a full path to them (s3://<bucket_name>/<folder_name>/<file-name>). Max size of an Object is 5TB (5000GB), if uploading more than 5GB, should be used “multi-part upload”.

• No real directories — just keys with slashes / (UI tricks you)
• Metadata: system/user key-value pairs
• Tags: up to 10 Unicode key-value pairs (useful for security/lifecycle)
• Version ID: if versioning enabled

S3 Consistency Model:

• Since Dec 2020, S3 is strongly consistent for all operations (read-after-write)
• PUT overwrite → immediate read returns latest version (not old data)
• DELETE → immediate read returns 404 (not stale object)
• No eventual consistency, no extra cost — built-in

⚠️ Exam trap: “Overwrite object, immediately read” → S3 always returns the latest version. Old “eventual consistency” behavior is gone. Distractors mentioning “might return previous data” or “might return new data” are wrong.

Amazon S3 Versioning protects against unintended deletes. It is enabled at the bucket level.

• Same key overwrite increments version: 1, 2, 3…
• Files before versioning enabled have version “null”
• Suspending versioning does not delete previous versions
• Easy rollback to any previous version

Amazon S3 Replication:

• Cross-Region Replication (CRR) — compliance, lower latency, cross-account
• Same-Region Replication (SRR) — log aggregation, prod-to-test sync
• Must enable Versioning in source AND destination
• Buckets can be in different AWS accounts
• Copying is asynchronous
• Only new objects replicated after enabling (use S3 Batch Replication for existing)
• DELETE: delete markers can be replicated (optional), version ID deletes are NOT replicated
• No chaining: bucket1 → bucket2 → bucket3 won’t replicate bucket1 objects to bucket3

┌───────────┐
│ S3 Bucket │ (eu-west-1)
└─────┬─────┘
      │ asynchronous
      │ replication
      ▼
┌───────────┐
│ S3 Bucket │ (us-east-2)
└───────────┘

S3 Security:

• User-Based: IAM Policies (which API calls allowed for specific user)
• Resource-Based:
  • Bucket Policies — bucket-wide JSON rules, allows cross-account
  • Object ACL — finer grain (can be disabled)
  • Bucket ACL — less common (can be disabled)

S3 Access Scenarios:

1. IAM User Access          2. EC2 Instance Access       3. Cross-Account Access
   ┌──────────┐                ┌──────────┐                 ┌──────────┐
   │IAM Policy│                │ IAM Role │                 │  Bucket  │
   └────┬─────┘                └────┬─────┘                 │  Policy  │
        │                           │                       └────┬─────┘
   ┌────▼─────┐                ┌────▼─────┐                      ▼
   │ IAM User │───────────────▶│   EC2    │─────────────▶  ┌───────────┐
   └──────────┘                └──────────┘                │ S3 Bucket │
        │                                                  └───────────┘
        ▼                                                        ▲
   ┌──────────┐                                            ┌─────┴─────┐
   │ S3 Bucket│              4. Public Access              │ IAM User  │
   └──────────┘                 ┌──────────┐               │Other Acct │
                                │  Bucket  │               └───────────┘
                                │  Policy  │
                                │Principal:│
                                │   "*"    │
                                └────┬─────┘
                                     ▼
                           ┌───────────────────┐
                           │ Anonymous Visitor │───▶ S3 Bucket
                           └───────────────────┘

Bucket Policy (JSON): Resources, Effect (Allow/Deny), Actions (API calls), Principal (account/user)

• Use cases: grant public access, force encryption at upload, cross-account access

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

Block Public Access — prevent data leaks:

• Leave ON if bucket should never be public
• Can be set at account level (applies to all buckets)

Access granted if: (IAM permissions ALLOW it OR resource policy ALLOWS it) AND no explicit DENY

⚠️ Exam trap: Bucket policy ALLOWS but user can’t access → check for explicit DENY in IAM policy (DENY always wins)

Encryption: encrypt objects using encryption keys

S3 Static Website Hosting:

• URL: http://bucket-name.s3-website-<region>.amazonaws.com or http://bucket-name.s3-website.<region>.amazonaws.com
• 403 Forbidden? → bucket policy must allow public reads

S3 Durability & Availability:

• Durability: 99.999999999% (11 9’s) across all storage classes — lose 1 object per 10,000 years if storing 10M objects
• Availability: varies by class (S3 Standard: 99.99% = ~53 min/year downtime)

S3 Storage Classes:

• Amazon S3 Standard - General Purpose: used for frequently access data, low latency and high throughput, sustain 2 concurrent facility failures (Big Data analytics, CDN);
• Amazon S3 Standard-Infrequent Access (IA) (99.9% availability): for data that is less frequently accessed, but requires rapid access. Lower cost than S3 Standard (Disaster Recovery, backups);
• Amazon S3 One Zone-Infrequent Access (99.5% availability): data will be lost when AZ is destroyed (storing secondary backup copies, data you can recreate);
• Amazon S3 Glacier Instant Retrieval: (milisecond retrieval, but once a quarter, minimum storage duration 90 days). Low-cost object storage with pricing for storage and retrieval cost;
• Amazon S3 Glacier Flexible Retrieval (minimum storage duration of 90 days):
  • Expedited (1 to 5 minutes);
  • Standard (3 to 5 hours);
  • Bulk (5 to 12 hours) - free.
• Amazon S3 Glacier Deep Archive: minimum storage duration of 180 days:
  • Standard (12 hours);
  • Bulk (48 hours).
• Amazon S3 Intelligent Tiering: moves objects automatically between Access Tiers based on usage, small monthly monitoring and auto-tiering fee, but there are no retrieval charges. Ideal for data with unknown or changing access patterns. Requires a small monthly monitoring and automation fee per object.
  • Frequent Access tier (automatic): default tier;
  • Infrequent Access tier (automatic): object not accessed for 30 days;
  • Archive Instant Access tier (automatic): objects not accessed for 90 days;
  • Archive Access tier (optional): configurable from 90 days to 700+ days;
  • Deep Archive Access tier (optional): configurable from 180 days to 700+ days.
• S3 Express One Zone (99.95% availability): high-performance single-AZ class using Directory Buckets. 10x faster than Standard (single-digit ms latency), 50% lower cost. Co-locate compute + storage in same AZ. Use cases: AI/ML training, HPC, financial modeling. Integrates with SageMaker, Athena, EMR, Glue.

Move between classes manually or using S3 Lifecycle configurations

⚠️ Exam traps - Storage Classes:

• “Unknown access pattern” → Intelligent-Tiering (auto-moves, no retrieval fee)
• “Single AZ” → One Zone-IA or Express One Zone (data lost if AZ destroyed)
• “Millisecond retrieval from archive” → Glacier Instant (not Flexible!)
• “Cheapest archive” → Glacier Deep Archive (but 12-48hr retrieval)
• “Lowest latency” → Express One Zone (10x faster than Standard)
• Default choice without usage details → Intelligent-Tiering (most cost-effective)
• Glacier Flexible modes: Expedited / Standard / Bulk only (NO “Instant” mode — that’s a separate class)
• Glacier Deep Archive modes: Standard / Bulk only (NO Expedited)

S3 Storage Classes Comparison:

Durability: 99.999999999% (11 9’s) for ALL classes

⚠️ Exam trap: Lifecycle transition timing must respect minimum storage duration

• IA classes (Standard-IA, One Zone-IA) = 30-day minimum charge
• Glacier Instant/Flexible = 90-day minimum charge
• Glacier Deep Archive = 180-day minimum charge
• Transitioning before the minimum → you pay for both the old class AND the minimum of the new class = more expensive
• Example: Standard → One Zone-IA after 7 days = you still pay 30 days of IA → wasteful. Transition at 30 days instead
• “Re-creatable data” = One Zone-IA is fine (single AZ risk acceptable = cheaper than Standard-IA)

S3 Performance:

• Latency: 100-200 ms
• Per prefix limits:
  • 3,500 PUT/COPY/POST/DELETE requests/sec
  • 5,500 GET/HEAD requests/sec
• No limit on number of prefixes in a bucket
• Prefix = path between bucket and file name (e.g., bucket/folder1/sub1/file → prefix: /folder1/sub1/)
• Spread across N prefixes → N × 5,500 GET/sec (e.g., 4 prefixes = 22,000 GET/sec)
• S3 Transfer Acceleration: use CloudFront edge locations for faster uploads (long distance)
• S3 Multi-Part Upload: parallelize uploads, retry failed parts only (required >5GB, recommended >100MB)
  • Single PUT limit = 5GB (error if exceeded without multi-part)
• S3 Byte-Range Fetches: request specific byte ranges in parallel
  • Speed up downloads (parallel parts)
  • Retrieve partial data (e.g., just the file header)
  • Better resilience (retry only failed parts)

⚠️ Exam traps:

• “Read first X bytes” / “file header/metadata” → Byte-Range Fetch
• “Large files + unstable connection” → Multi-Part Upload + Transfer Acceleration
• Multi-Part = resilience (retry parts), Transfer Acceleration = speed (edge locations)
• “Faster S3 uploads” → S3 Transfer Acceleration (NOT Global Accelerator — GA is for ALB/NLB/EC2 endpoints, not S3)
• “Cost-effective faster uploads” → S3TA + Multipart (NOT Direct Connect — expensive, months to set up; NOT VPN — no speed improvement)

S3 Batch Operations:

• Bulk operations on existing objects with a single request
• Use cases: modify metadata, copy between buckets, encrypt objects, modify ACLs/tags, restore from Glacier, invoke Lambda per object
• Job = object list + action + optional parameters
• Manages retries, tracks progress, sends notifications, generates reports
• Use S3 Inventory to get object list, Athena to filter objects

⚠️ Exam trap: “Encrypt existing objects” / “change encryption on all files” → S3 Batch Operations

• Lifecycle Rules = transition/delete (NOT encrypt)
• CRR = replication (NOT in-place encryption)
• Access Points = access control (NOT encryption)

S3 Inventory ──▶ Athena (filter) ──▶ S3 Batch Operations ──▶ Processed Objects
     │                                      ▲
     └── Objects List Report                │
                                   User: operation + params

S3 Lifecycle Rules:

• Automate transitions between storage classes
• Transition Actions: move objects to another class after X days
• Expiration Actions: delete objects/versions/incomplete uploads after X days
• Rules can target: prefix (s3://bucket/mp3/*) or object tags (Department: Finance)

⚠️ Exam trap:

• “Delete old versions to reduce costs” → Expiration Actions (not Transition!)
• “Delete incomplete multipart uploads” → Expiration Actions (Lifecycle Rule)
• Transition = move to cheaper storage class
• Expiration = permanently delete (objects, versions, or incomplete uploads)

Storage Class Transitions (allowed paths):

Standard ──┬──▶ Standard-IA ──┬──▶ Intelligent-Tiering ──┬──▶ One Zone-IA
           │                  │                          │
           │                  ▼                          ▼
           ├──▶ Glacier Instant ◀────────────────────────┤
           │                                             │
           ▼                                             ▼
      Glacier Flexible ◀─────────────────────────────────┤
           │                                             │
           ▼                                             ▼
      Glacier Deep Archive ◀─────────────────────────────┘

(All classes can transition DOWN, never UP)

Lifecycle Scenarios:

S3 Analytics - Storage Class Analysis:

• Recommendations for Standard and Standard-IA only (NOT One Zone-IA/Glacier)
• Report updated daily, 24-48 hours to start seeing data
• Good first step to create/improve Lifecycle Rules

⚠️ Exam trap: “Optimal days to transition” / “Lifecycle recommendations” → S3 Analytics (not Inventory!)

S3 Requester Pays:

• Normally bucket owner pays for storage + data transfer
• With Requester Pays: requester pays for requests + data download
• Use case: share large datasets with other accounts
• ⚠️ Requester must be authenticated (cannot be anonymous)

S3 Event Notifications:

• Events: S3:ObjectCreated, S3:ObjectRemoved, S3:ObjectRestore, S3:Replication
• Object name filtering possible (*.jpg)
• Delivery: typically seconds, can take a minute+
• Destinations: SNS, SQS, Lambda Function
• Requires resource policies on destination (SNS/SQS/Lambda must allow S3 to invoke)

           ┌──▶ SNS
           │
S3 Events ─┼──▶ SQS
           │
           └──▶ Lambda

S3 Event Notifications with EventBridge:

• S3 → EventBridge → 18+ AWS services as destinations
• Advanced filtering: JSON rules (metadata, object size, name)
• EventBridge capabilities: Archive, Replay Events, Reliable delivery

⚠️ Exam trap: “Get notified on object upload” → Event Notifications (NOT Access Logs, Analytics, or Select)

• Access Logs = audit logging (no notifications)
• Analytics = storage class recommendations
• S3 Select = query data inside objects

S3 Storage Lens

Overview:

• Analyze and optimize storage across entire AWS Organization
• 30 days of usage & activity metrics
• Aggregate by: Organization, accounts, regions, buckets, or prefixes
• Export metrics daily to S3 (CSV, Parquet)

                    ┌─ Organization
                    ├─ Accounts
S3 Storage Lens ───▶├─ Regions        ───▶ Aggregate ───▶ Dashboard ───▶ ┌─ Summary Insights
   (Configure)      └─ Buckets                           (Analyze)       ├─ Data Protection
                                                                         └─ Cost Efficiency
                                                                            (Optimize)

Default Dashboard:

• Multi-Region and Multi-Account data
• Preconfigured by AWS, can’t be deleted (only disabled)

Metrics Categories:

Free vs Paid:

S3 Encryption

4 Encryption Methods:

⚠️ Exam trap: “Customer manages keys” + “never store keys in AWS” → SSE-C or Client-Side

• SSE-C: encryption happens in S3, but YOU send the key with each request (S3 discards after use)
• Client-Side: encryption happens on YOUR side before upload, S3 never sees unencrypted data
• Both = keys never stored in AWS; difference = WHERE encryption happens

⚠️ Exam trap: “Keys in AWS OK” + “control rotation policy” → SSE-KMS

• SSE-S3 = AWS manages everything (no rotation control)
• SSE-KMS = keys in AWS, but YOU control rotation (automatic yearly or on-demand)

⚠️ Exam trap: “Encrypt all objects by default” → Do nothing (SSE-S3 is automatic since Jan 2023)

• All new objects encrypted with SSE-S3 by default
• HTTPS = encryption in transit (not at rest)
• Versioning = version history (not encryption)

Encryption Evaluation Order:

1. Bucket Policy evaluated first (can deny/require specific encryption)
2. Default Encryption applied if no encryption header in request

SSE-S3 (Server-Side Encryption with S3-Managed Keys):

User ──── HTTP(S) + Header ────▶ ┌─────────────────────────────────┐
          (upload object)        │           Amazon S3             │
                                 │  Object + S3 Owned Key          │
                                 │         ↓                       │
                                 │    [Encryption]                 │
                                 │         ↓                       │
                                 │    S3 Bucket (encrypted)        │
                                 └─────────────────────────────────┘

SSE-KMS Limitation:

• Upload calls GenerateDataKey API, download calls Decrypt API
• Counts toward KMS quota: 5,500 / 10,000 / 30,000 req/s (region-dependent)
• Request quota increase via Service Quotas Console

SSE-KMS (Server-Side Encryption with KMS Keys):

User ──── HTTP(S) + Header ────▶ ┌─────────────────────────────────┐
          (upload object)        │           Amazon S3             │
                                 │  Object + KMS Key (API call)    │
                                 │         ↓                       │
                                 │    [Encryption]                 │
                                 │         ↓                       │
                                 │    S3 Bucket (encrypted)        │
                                 └─────────────────────────────────┘
                                            ▲
              ┌─────────┐                   │ API call
              │ KMS Key │───────────────────┘
              └─────────┘
        (GenerateDataKey / Decrypt)

⚠️ Exam trap: “High-throughput S3” + “encryption” → SSE-S3 (not SSE-KMS!)

• SSE-KMS has API quota limits + extra cost per request
• SSE-S3 = no limits, no extra cost, still AES-256

SSE-C (Server-Side Encryption with Customer-Provided Keys):

User ──── HTTPS ONLY ──────────▶ ┌─────────────────────────────────┐
     (object + key in header)    │           Amazon S3             │
                                 │  Object + Client-Provided Key   │
                                 │         ↓                       │
                                 │    [Encryption]                 │
                                 │         ↓                       │
                                 │    S3 Bucket (encrypted)        │
                                 └─────────────────────────────────┘
                                 (S3 discards key after use)

Client-Side Encryption:

┌──────┐   ┌────────────┐   ┌──────────────┐            ┌───────────┐
│ File │ + │ Client Key │ → │ [Encryption] │ → HTTP(S) → │ S3 Bucket │
└──────┘   └────────────┘   │ (client-side)│            │(encrypted)│
                            └──────────────┘            └───────────┘
           (Customer manages keys + encryption cycle)

Force Encryption in Transit (HTTPS):

• Use bucket policy with aws:SecureTransport condition
• Deny requests where aws:SecureTransport: false

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "Bool": { "aws:SecureTransport": "false" }
  }
}

S3 CORS (Cross-Origin Resource Sharing)

• Origin = scheme (protocol) + host (domain) + port
  • Example: https://www.example.com (port 443 implied for HTTPS)
• Same origin: http://example.com/app1 & http://example.com/app2
• Different origins: http://www.example.com & http://other.example.com
• Browser-based mechanism to allow requests to other origins
• Requests blocked unless cross-origin server allows via CORS Headers

CORS Flow (Preflight Request):

┌────────────────┐                           ┌────────────────┐
│  Web Server    │                           │  Web Server    │
│   (Origin)     │                           │ (Cross-Origin) │
│ example.com    │                           │  other.com     │
└───────┬────────┘                           └───────▲────────┘
        │                                            │
        │ HTTPS Request                              │
        ▼                                            │
   ┌─────────────┐    1. OPTIONS (Preflight)         │
   │ Web Browser │──────────────────────────────────▶│
   │             │    Host: other.com                │
   │             │    Origin: example.com            │
   │             │◀──────────────────────────────────│
   │             │    2. Preflight Response          │
   │             │    Access-Control-Allow-Origin:   │
   │             │      https://example.com          │
   │             │    Access-Control-Allow-Methods:  │
   │             │      GET, PUT, DELETE             │
   │             │──────────────────────────────────▶│
   └─────────────┘    3. GET / (actual request)      │
                      Host: other.com                │
                      Origin: example.com            │

S3 CORS:

• If client makes cross-origin request to S3 bucket, must enable correct CORS headers
• Configure CORS on the cross-origin bucket (the one being requested)
• Allow specific origin or * (all origins)

S3 CORS Example (Static Website with Assets in Different Bucket):

┌─────────────┐   1. GET /index.html                    ┌─────────────────────┐
│ Web Browser │────────────────────────────────────────▶│ S3: my-bucket-html  │
│             │◀────────────────────────────────────────│ (Static Website)    │
│             │   index.html                            │ Origin bucket       │
│             │                                         └─────────────────────┘
│             │   2. GET /images/coffee.jpg
│             │      Host: my-bucket-assets.s3-website...
│             │      Origin: my-bucket-html.s3-website...
│             │────────────────────────────────────────▶┌─────────────────────┐
│             │◀────────────────────────────────────────│ S3: my-bucket-assets│
│             │   Access-Control-Allow-Origin:          │ (Static Website)    │
└─────────────┘     my-bucket-html.s3-website...        │ Cross-origin bucket │
                                                        │ ← CORS config here  │
                                                        └─────────────────────┘

⚠️ Exam trap: CORS errors on S3 → configure CORS on the target bucket (the one being requested), not the origin

S3 MFA Delete

Requires MFA code before critical S3 operations

• MFA required for:
  • Permanently delete an object version
  • Suspend versioning on bucket
• MFA NOT required for:
  • Enable versioning
  • List deleted versions
• Prerequisites: Versioning must be enabled
• Only root account can enable/disable MFA Delete

S3 Access Logs

• Log all requests to S3 bucket (authorized AND denied)
• Logs stored in another S3 bucket (same region)
• Use for audit, security analysis
• Analyze logs with Amazon Athena (serverless SQL queries on S3 data)

⚠️ Exam trap: Never set logging bucket = monitored bucket → creates infinite loop, bucket grows exponentially

⚠️ Exam trap: “Audit who accessed/tried to access S3” → S3 Access Logs + Athena

• Access Logs = captures all requests (including denied)
• Athena = serverless SQL to analyze log files in S3
• Wrong: CloudTrail = API calls only (not data access patterns)
• Wrong: Bucket Policy = controls access, doesn’t log attempts

S3 Pre-Signed URLs

• Generate via Console, CLI, or SDK
• User inherits permissions of URL generator for GET/PUT

Expiration:

Use Cases:

• Allow logged-in users to download premium content
• Dynamically generate download URLs for changing user list
• Temporary upload access to specific S3 location

S3 Access Points

• Simplify security management for S3 buckets at scale
• Each Access Point has:
  • Own DNS name (Internet Origin or VPC Origin)
  • Access Point policy (like bucket policy)
• Use case: different teams need access to different prefixes

S3 Access Points:

Users (Finance) ───▶ Finance Access Point ───┐
                     (R/W to /finance/*)     │
                                             ▼
Users (Sales) ─────▶ Sales Access Point ────▶ S3 Bucket ◀── Simple
                     (R/W to /sales/*)       │               Bucket
                                             │               Policy
Users (Analytics) ─▶ Analytics Access Point ─┘
                     (R to entire bucket)

VPC Origin Access Points:

• Access Point accessible only from within VPC
• Requires VPC Endpoint (Gateway or Interface)
• VPC Endpoint Policy must allow access to bucket AND Access Point