Introduction to AWS

Cloud Computing Fundamentals

Traditional IT Infrastructure

Client–Server Model in Web Applications

• A client application (such as a web browser) sends a request over the internet (a network of interconnected systems) to a remote server (for example, a Gmail server)
• The server continuously waits for incoming client requests; once a request is received, it can process it and establish communication with the requesting client
• Both clients and servers recognize each other using their IP addresses

Physical Servers and Hardware (HW)

Core Components of a Computer/Server

1. COMPUTE: responsible for executing instructions and processing data
   • Hardware includes CPU (Central Processing Unit) and GPU (Graphics Processing Unit)
   • GPUs typically deliver higher performance than CPUs but come at a higher cost; they are commonly used for graphics rendering, large-scale data processing, machine learning, and generative AI
2. MEMORY: temporarily holds data that is actively being used or accessed frequently, enabling fast retrieval
   • Data stored here is temporary (volatile) and can be lost or overwritten (e.g., during restarts or when running new programs)
   • Hardware component: RAM (Random Access Memory)
3. STORAGE: retains data persistently, although access speeds are slower compared to memory
   • Hardware includes SSD (Solid State Drive) and HDD (Hard Disk Drive)
   • Data can be organized in different formats such as block, object, or file storage
   • Databases (DBs): add structure and logic to stored data, making it easier to search, retrieve, and process compared to basic storage
4. NETWORK (NW): enables communication between systems by sending and receiving data
   • Hardware includes cables, Network Interface Cards (NICs), routers (Layer 3), switches (Layer 2), and DNS servers
   • Data transmission may pass through multiple devices to reach its destination accurately

• Physical hardware can be simulated using technologies like virtualization and containerization, allowing virtual servers and components to run more efficiently on shared physical resources

Challenges of On-Premises Physical Servers

• Traditionally, organizations deployed servers within their own facilities or in data centers

• Common challenges include:
  • Uncertain scaling needs: difficult to estimate how many users will access the application or how usage patterns will change over time
  • Underutilized resources: purchasing large-capacity servers in advance often leads to unused resources, especially early on
  • Operational burden: teams must handle software updates, continuous monitoring, and hardware upgrades or replacements
  • Ongoing maintenance expenses: costs include physical space, electricity, cooling systems, and security personnel
  • Limited geographic distribution and resilience: systems are often centralized, making them vulnerable to disruptions like natural disasters or physical damage
  • High initial investment: setting up infrastructure requires significant upfront capital
• Cloud computing addresses these limitations by allowing users to lease infrastructure resources and avoid the complexities of managing physical hardware

What is Cloud Computing?

Cloud Computing

• Definition: A framework that provides widely accessible, easy, and on-demand network access to a shared pool of configurable IT resources (such as servers, networks, storage, applications, and services)
  • These resources can be quickly created and removed with minimal effort or need for direct interaction with the provider
• Cloud computing has significantly transformed how organizations and individuals use computing services
  • Key benefits include greater scalability, improved flexibility, reduced maintenance, and less reliance on physical infrastructure

Five Key Characteristics of a Cloud Platform

• The five core characteristics are:
  • On-Demand Self-Service
  • Broad Network Access
  • Resource Pooling
  • Rapid Elasticity
  • Measured Service

On-Demand Self-Service

• Users can allocate resources whenever needed without requiring assistance from the provider
  • Management is typically done through interfaces like web consoles, command-line tools, or APIs

Broad Network Access

• Services are delivered over the network and can be accessed using standard methods and devices
  • There is no need for specialized hardware or uncommon protocols

Resource Pooling

• Provider resources are shared among multiple users using a multi-tenant approach
• Users generally do not know the exact physical location of their resources, creating location independence
• This setup allows providers to achieve economies of scale, which leads to lower costs for customers

Rapid Elasticity

• Resources can be scaled up or down quickly depending on demand
  • Helps avoid both over-allocation (waste) and under-allocation (performance issues)
• From the user’s perspective, available resources often seem virtually unlimited
• This is considered one of the most valuable features of cloud computing

Measured Service

• Usage of resources is tracked, managed, and reported, and most importantly, charged accordingly
• With proper setup, users follow a pay-as-you-go pricing model, paying only for what they use
  • However, unused resources should be removed to avoid unexpected charges

Six Advantages of Cloud Computing (AWS Whitepaper)

1. Shift from capital expenses (CAPEX) to operational expenses (OPEX)
   • Reduces overall ownership and operational costs
   • No need to purchase or maintain physical hardware
2. Leverage large-scale economies
   • Cloud providers can lower prices due to operating at massive scale
3. Eliminate capacity guesswork
   • Resources can be adjusted based on actual usage, reducing idle capacity
4. Improve speed and agility
   • Infrastructure can be deployed or removed quickly compared to traditional setups
   • Enables faster experimentation and development
5. Reduce data center management
   • Less need to handle infrastructure maintenance, allowing focus on core business activities
6. Deploy globally with ease
   • Applications can be launched in multiple regions within minutes
   • Global infrastructure helps reduce latency and enhance user experience

Public vs Private vs Multi vs Hybrid Cloud

Types of Cloud Computing

Public Cloud

• Definition: A cloud environment that is open for use by the general public
  • Users access and control their resources through the internet
• Major public cloud providers include:
  • Amazon Web Services (AWS)
  • Microsoft Azure
  • Google Cloud

Multi-Cloud

• Definition: The practice of using more than one public cloud provider to run applications
• Examples:
  • Deploying different parts of an application across separate cloud platforms
  • Mirrored setup: running the same full application in multiple clouds (e.g., AWS and Azure)
    • If one provider experiences failure, the other can continue operating, improving availability
• Recommendation: Avoid relying on single-pane management tools for multi-cloud
  • These tools hide provider-specific features, making it harder to understand each platform’s strengths
  • They typically only expose features that are common across all providers, limiting functionality

Private Cloud

• Definition: A cloud setup that is dedicated to a single organization, usually hosted on-premises
• Major providers also offer solutions for private deployments, such as:
  • AWS Outposts
  • Azure Stack
  • Google Anthos
• To qualify as a true private cloud, the system must still satisfy the five essential cloud characteristics
  • Traditional virtualization platforms (e.g., VMware, Hyper-V, XenServer) may offer similar capabilities but do not fully meet all cloud criteria

Hybrid Cloud

• Definition: A combination of public cloud and private cloud working together as a unified system
  • Both environments are managed using consistent tools, processes, and interfaces
• Important distinction:
  • Simply connecting on-premises infrastructure to a public cloud is considered a hybrid environment or networking setup, not hybrid cloud
  • For it to be classified as hybrid cloud, it must involve both a true private cloud and a public cloud working together

Summary Diagram: Types of Cloud Computing

Cloud Service Models (XaaS)

Infrastructure Stack (or Application Stack)

• Layers of infrastructure involved when running a software application:
  1. Application
  2. Data → databases, data stores
  3. Runtime Environment (RTE) → code libraries, frameworks
  4. Container → Docker, Kubernetes
  5. Operating System (OS) → Linux, Windows, MacOS
  6. Virtualization
  7. Server → physical machine or hardware
  8. Infrastructure → server racks, network devices
  9. Facilities → buildings, power, security, real estate
• Unit of consumption = what the customer pays for and uses
  • Everything below the unit of consumption is handled by the provider
  • The unit itself and everything above is managed by the customer
  • Each cloud service model defines its own unit of consumption
• On-premises deployment → Customers take responsibility for the entire stack
  • More expensive, higher administrative workload, increased risk
  • Offers maximum control and flexibility
• Data Center (DC)-hosted → Customers pay for access to the facilities and manage everything else
  • Common model before widespread cloud adoption

Common Cloud Service Models

IaaS (Infrastructure-as-a-Service)

• Unit of consumption:Operating System (OS)
  • Typically provides virtual machines (VMs)
• Pricing: pay-as-you-go
  • Charged for VM usage by time (seconds, minutes, hours)
  • No charges when the VM is inactive
• Trade some flexibility for reduced cost and lower operational risk
• Highly adopted cloud service model
• Example: Amazon Elastic Compute Cloud (EC2)

PaaS (Platform-as-a-Service)

• Unit of consumption: Runtime Environment (RTE)
• Designed for developers who want to deploy and run applications without managing infrastructure
• Examples: Heroku, AWS Elastic Beanstalk

SaaS (Software-as-a-Service)

• Unit of consumption:Application
  • No need to manage underlying layers
• The software itself is the service
  • Limited customization or control
  • Minimal operational costs and responsibilities
• Pricing: subscription-based
  • Pay monthly or yearly for usage
  • Free tiers or trial versions are often available
• Examples: Netflix, Dropbox, Gmail

Other Cloud Service Models

• FaaS (Function-as-a-Service) → e.g., AWS Lambda
• DBaaS (Database-as-a-Service) → e.g., MongoDB Atlas
• CaaS (Container-as-a-Service) → e.g., Amazon ECS

Key Concept Diagram

AWS Accounts

What is AWS?

Amazon Web Services (AWS)

• Amazon: a major technology company, part of the FAANG group
• Web: services that are accessible over the internet using standard web protocols
• Services: offerings that customers can use for a period of time, usually billed based on actual usage (pay-as-you-go)
  • Example: your Internet Service Provider (ISP) provides internet as a service—you pay a monthly fee for access at a certain speed and can start or stop the service as needed
  • Other examples: Netflix subscription, utility services for your home, charging an electric vehicle at a public station
  • Difference between a service and a product: a product is purchased once and kept (e.g., a lunchbox), whereas a service is ongoing and billed for as long as you use it (e.g., HelloFresh delivering meals regularly)

AWS Cloud Use Cases

• Enables the development and deployment of scalable software applications across any industry
• Applications can optionally reach a global audience
• Common use cases include:
  • Hosting websites or web applications
  • Backing up or storing data in the cloud
  • Performing analytics on large datasets
  • Running gaming servers
  • And many more

AWS Cloud Pricing Model

• Pay-as-you-go is the standard pricing approach
  • Discounts may be available for reserving resources or committing to long-term usage
  • Reduces the high upfront costs of traditional IT infrastructure
• AWS pricing is based on three main categories:
  1. Compute – billed for actual compute time used
  2. Storage – billed for the amount of data stored in AWS
  3. Network –
     • Data transferred into AWS is free
     • Data transferred out of AWS is billed

AWS Shared Responsibility Model & AWS Acceptable Use Policy

AWS Shared Responsibility Model for Security

• Official AWS reference: Shared Responsibility Model

• AWS uses this model to define who handles which aspects of security:
  • Security OF the cloud → managed by AWS
  • Security IN the cloud → managed by the customer
• Related to the concept of the infrastructure stack in different cloud service models (IaaS, PaaS, etc.), which splits responsibilities between vendor and customer. Key differences:
  • Applies across all AWS services
  • Focuses specifically on security
• Useful as a reference while learning AWS—having a visual nearby can help reinforce the concept

AWS Acceptable Use Policy (AUP)

• Covers expected behavior when using AWS services:
  • No illegal, harmful, or offensive activity or content
  • No security violations
  • No network abuse
  • No abuse of email or other messaging services

AWS Accounts – The Basics

AWS Account – Key Concepts

• AWS account = container for identities and resources
  • Important: An AWS account is not the same as a user within the account.
  • Identity: a user, application, or entity that can log in to an AWS account
    • Note: IAM groups are an exception (explained later)
  • AWS resource: software, hardware, or data that exists in AWS and belongs to an account
    • Examples: EC2 virtual machine, S3 bucket with images
    • AWS defines a resource as “an entity you can work with”
    • Resources are created inside AWS services (e.g., S3 bucket is a resource in S3)
  • Simple systems may run from a single account, but complex setups often require multiple accounts (AWS Organizations can help manage multiple accounts)
  • AWS accounts should be treated as disposable; avoid placing all business operations in a single account

• Provisioning an AWS account requires:
  1. Account Name – e.g., “mywebapp-PROD”
  2. Unique email address – used to create the root user
     • Cannot be shared between accounts
     • Gmail trick: add + to make unique (user@gmail.com vs user+aws@gmail.com)
  3. Credit card – used for billing; can be shared between accounts
     • AWS bills based on actual usage (pay-as-you-go)
     • Free tier: some services include free usage each month, useful for learning
• Root User = default account identity
  • Full control of the account, cannot be restricted
  • First and only identity initially created
  • Should be used only for account setup, emergencies, or account closure
  • Daily administration should use a separate IAM identity (e.g., iamadmin)
• IAM (Identity and Access Management)
  • AWS service for creating additional account identities
  • IAM identities include users, groups, and roles
  • Start with no permissions by default and can be granted full or partial access
• Account boundary
  • Everything in the account is isolated by default
  • External access must be explicitly granted
  • Using multiple accounts reduces risk from errors or attacks
    • Example: separate accounts for DEV, TEST, PROD, or different teams/products

Free vs Paid AWS Accounts

• AWS historically offered service free tiers, but no fully free accounts
• Since 2025: AWS offers Free accounts for new customers
  • Free for 6 months, up to $200 in AWS credits
  • After expiration or credit usage, workloads stop until upgraded
  • Not all services/features available in Free accounts

• Free accounts are strictly limited:
  • Each customer can only use one Free account
  • Customer credentials cannot be shared
  • Gmail + trick does not work for Free accounts

• Recommendation: use a Paid account from the start
  • Full access to all services/features
  • No sudden interruptions of workloads
  • Learn responsible usage and budgeting early
  • Paying a small amount while learning AWS prepares you for real-world scenarios

Demo: Creating an AWS Account

• Recommended setup: MFA enabled, budget alarms, and iamadmin identity
• Sign up: AWS Signup Portal
  1. Enter personal details
  2. Prefer Paid account, but Free account possible if eligible
  3. Choose “Basic support – Free”
  4. Activate IAM Access to Billing Information under “Account”

◦ Without this, IAM identities cannot see billing information

• Region recommendation: Northern Virginia (us-east-1)
  • Ensures full service access
  • Optionally, use region closest to you for better performance

MFA (Multi-Factor Authentication)

Why MFA is Important

• Web-based logins typically rely on usernames and passwords
  • If these credentials are exposed, an attacker can easily gain access by pretending to be the user
• Authentication factors are different types of evidence used to verify identity
  • Common categories:
    1. Knowledge – something you know (e.g., username and password)
    2. Possession – something you own (e.g., phone, MFA app, hardware key)
    3. Inherence – something you are (e.g., fingerprint, facial recognition)
    4. Location – where you are (e.g., IP address, geographic location)
  • There is a balance between security and usability:
    • Adding more factors increases protection and makes impersonation harder
    • However, it also adds more steps and effort during login
  • Authentication types based on factors used:
    • SFA (Single-Factor Authentication) – uses only one factor
    • 2FA (Two-Factor Authentication) – uses two different factors
    • MFA (Multi-Factor Authentication) – uses multiple factors

MFA in AWS

• MFA can be enabled for any user, such as the root user or an IAM administrator
  • AWS provides a secret key and setup details, usually in the form of a QR code
  • This information is configured in an MFA application or device (e.g., Google Authenticator, Authy, password managers)
• After setup, the MFA device generates temporary codes that update at regular intervals
• During login, users must provide:
  • Their primary credentials (username and password)
  • The current MFA code from their device
• This adds an extra layer of protection beyond just passwords

Demo: Enabling MFA in an AWS Account

• Go to: Account menu → Security credentials → Assign MFA
• Choose Authenticator App as the MFA method and follow the setup instructions
  • Any standard authenticator app can be used (e.g., Google Authenticator, Authy, 1Password)

Creating a Budget

AWS Free Tier

• More information about the AWS Free Tier: https://aws.amazon.com/free/
  • Some services offer limited-time free trials, others provide a certain amount of free usage each month, and some include always-free options
  • As mentioned in Free vs Paid accounts, eligible users can sign up for a Free account, but it comes with limitations on available services/features and typically lasts for 6 months
• AWS includes detailed cost tracking tools to monitor resource usage (e.g., AWS Cost Explorer)
• Navigate to: Drop-down menu → Billing and Cost Management → Bills
  • Displays previous invoices and current monthly charges
• Under Billing Preferences, enable all available options for better visibility and notifications

Creating a Cost Budget

• AWS Budgets help you track spending and send alerts when usage approaches defined limits
• Navigate to: Billing Dashboard → Budgets → Create a Budget
• A “zero spend budget” is useful if you want to remain fully within the Free Tier
• Labs and demos are typically designed to stay within free usage limits, but unexpected charges can still occur
  • Setting a budget ensures you receive alerts if costs begin to accumulate
  • This allows you to take action, such as deleting resources that are generating charges

AWS IAM 101

Identity and Access Management (IAM) Service

• AWS IAM is a fundamental AWS service used to manage identities and access
  • It performs three primary functions:
    1. Identity management → acts as an Identity Provider (IdP)
    2. Authentication → verifies that an identity is legitimate
    3. Authorization → controls access using policies (allow or deny actions)
  • IAM is free to use
  • It is a global service, meaning it operates across all AWS regions with built-in resilience
• IAM has broad administrative capability, but it only applies to identities within its own account
  • It does not directly manage identities from other AWS accounts
  • Each AWS account has its own isolated IAM system and database
  • An account fully relies on its own IAM instance
• IAM can control nearly all aspects of an account, except:
  • Billing-related actions
  • Closing the account (root user only)
• IAM also supports:
  • Multi-Factor Authentication (MFA)
  • Identity Federation
    • External identities (e.g., from Google, Facebook, or corporate directories) can be used to access AWS resources indirectly

Account Root User

• The root user is the initial identity tied to the AWS account
  • Linked to the account’s email address
  • Has complete and unrestricted access
  • The account inherently trusts the root user
• The root user is not managed by IAM
  • IAM cannot limit or control it
• Best practices:
  • Avoid using the root user for routine activities
  • Reserve it for critical or one-time tasks only (e.g., account recovery or closure)
• Principle of least privilege:
  • Grant users only the permissions they need to perform their roles
  • Restrict all unnecessary access

IAM Identities and Policies

• IAM allows creation of additional identities within an account:
  1. IAM Users
     • Represent individuals or applications needing long-term access
     • Use permanent credentials (username/password and/or access keys)
  2. IAM Groups
     • Collections of users with similar access needs
     • Example: developers, finance team
  3. IAM Roles
     • Used by AWS services or external entities
     • Suitable when multiple or unknown users need access
     • Provide temporary credentials
• IAM Policy
  • A document that defines permissions
  • Attached to users, groups, or roles
  • Specifies which actions are allowed or denied on resources
  • Written in JSON format
  • The account trusts permissions granted through these policies

Demo: Creating an IAM Admin User in an AWS Account

• IAM users access the account through a sign-in URL:
  https://<account-id>.signin.aws.amazon.com/console
  • The account ID is a numeric identifier
  • You can define an account alias to make the URL easier to remember
    • Must be globally unique
    • Provides a cleaner login link:
      https://<account-alias>.signin.aws.amazon.com/console
• In this example, a new IAM user named iamadmin is created with administrator-level permissions
  • This reduces reliance on the root user
  • The root user cannot be restricted, removed, or recreated, making it unsafe for routine tasks
• Steps to create the IAM user:
  • Go to IAM → Users → Add Users
  • Enter a username (iamadmin)
    • Only needs to be unique within the account
  • Assign permissions during setup
    • Attach the AdministratorAccess policy
      • Grants full access to the account, except for actions limited to the root user (such as closing the account)
• After logging in with the new IAM user:
  • The username appears in the top-right corner of the AWS console

• For better security, enable MFA for the iamadmin user

Image Sources

• IAM policy concepts and examples:
  Salesforce Trailhead IAM Policies Module
• IAM policy structure and practical examples:
  MSP360 IAM Policy Guide

Accessing AWS Accounts

3 Ways to Access AWS Accounts, Services, and Resources

1. AWS Management Console UI
2. AWS CLI (Command Line Interface)
3. AWS SDK (Software Development Kit)

AWS Management Console (Commonly called: AWS Console UI)

• A web-based interface accessed through a browser
• Requires login using a valid identity (root user, IAM user, or IAM role)
  • Secured with a password and optionally MFA
• Often referred to as “ClickOps” since actions are performed through the interface
  • In contrast, Infrastructure as Code (IaC) and DevOps practices rely on automation, scripts, and code instead of manual interaction

AWS CLI (Command Line Interface)

• Allows interaction with AWS services by running commands in a terminal or shell
• Communicates with AWS through its public APIs
• Must be installed locally before use
  • Installation guide: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html
• Open-source tool: https://github.com/aws/aws-cli
• Requires IAM access keys for authentication

AWS SDK (Software Development Kit)

• Provides language-specific libraries for developers
  • Enables applications and scripts to interact with AWS programmatically
  • Supports multiple programming languages
• Requires IAM access keys
• The AWS CLI itself is built using an AWS SDK (Python-based)

AWS CloudShell

• A browser-based terminal environment available within the AWS Console
  • Runs inside a selected AWS region
  • Comes preconfigured with AWS CLI, credentials, and region settings
• Includes a small persistent storage space for saving files
• Not available in all AWS regions
  • Supported regions list: https://docs.aws.amazon.com/cloudshell/latest/userguide/supported-aws-regions.html

IAM Access Keys

Long-Term and Short-Term Credentials

• Credentials are pieces of information used by AWS to verify identity (i.e., enable login to an account)
  • Long-term credentials remain valid until manually changed
    • Examples: username and password, IAM access keys
    • The user must update or rotate them when needed
  • Short-term credentials are temporary and expire after a set duration
    • Systems using them must regularly request new credentials to maintain access
• The root user and IAM users rely on long-term credentials, while IAM roles provide short-term credentials
• Credentials typically include:
  • A public component (e.g., username, access key ID)
  • A private component (e.g., password, secret key)
  • MFA acts as an additional private verification factor

IAM Access Keys

• Access to AWS via the CLI or APIs is commonly done using IAM access keys
• IAM access keys are a type of long-term credential consisting of two parts:
  1. Access Key ID (public) – e.g., AKIAIOSF0DNN7EXAMPLE
  2. Secret Access Key (private) – a longer, confidential string shown only once during creation

• Key characteristics:
  • Can be created, deactivated, reactivated, or deleted
  • Cannot be modified once created
    • Instead, they must be rotated (deleted and replaced with new keys)
  • By default, newly created keys are active
• Limits per IAM user:
  • Up to one username/password pair
  • Up to two active access key sets (useful for rotation)
• Although root users can generate access keys, this is strongly discouraged
  • Root access should not be used for routine CLI or API operations

Demo: Creating Access Keys and Configuring AWS CLI v2

• Create access keys:
  • Go to: Account menu → Security Credentials → Create Access Key
  • Download and store the keys securely (e.g., CSV file)
• Install AWS CLI v2:
  • https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html
  • Verify installation:
    • Run aws to see help output
    • Run aws --version to confirm version 2 or higher
• Configure AWS CLI profiles:
  • aws configure → sets up the default profile
  • aws configure --profile iamadmin-general → creates a named profile
    • Provide access key ID, secret key, default region (us-east-1), and output format
• Test access:
  • aws s3 ls → lists S3 buckets
  • If using a named profile:
    • aws s3 ls --profile iamadmin-general
• After successful configuration, it is good practice to remove downloaded credential files from your local system

AWS Fundamentals

AWS Public vs Private Services

AWS Networking Ecosystem

• AWS networking is divided into three main zones:

1. AWS Private Zone

• Defined by customer-controlled private networks (VPCs – Virtual Private Clouds)
  • VPCs are isolated by default, even from other VPCs
• External connectivity must be explicitly configured, such as:
  • Connecting to on-premises environments via VPN or Direct Connect
  • Accessing AWS public services through an Internet Gateway (IGW)
  • Enabling communication with the public internet using an IGW
• Similar to a private network (e.g., a VPN on a laptop), communication only happens when properly configured
• Many AWS services require a VPC to run resources
  • Example: EC2 instances are launched inside a VPC

2. AWS Public Zone

• A network layer managed by AWS that connects VPCs to the public internet
• Hosts public AWS services, such as IAM, Route 53, and S3
  • These services are accessed through public endpoints
  • They do not require a VPC to function
• Communication between a VPC and a public AWS service can occur via an IGW without necessarily traversing the open internet

3. Public Internet

• The global public network used worldwide
• External systems and users interact with AWS through this layer

Key Clarification

• The distinction between AWS private and public services relates only to networking design
  • It does not determine access permissions
• Even if a service has a public endpoint, access is still controlled
  • Proper authentication and authorization are required
  • By default, only the root user has full access
  • Other identities must be granted permissions through IAM

Summary Diagram

High-Availability (HA), Fault Tolerance (FT) & Disaster Recovery (DR)

High Availability (HA)

• A high availability (HA) system is designed to maintain a defined level of performance, typically uptime, for a longer-than-usual duration
  • In simple terms, HA focuses on maximizing system availability
    • If a failure occurs, components can be quickly repaired or replaced, often through automated processes
  • This approach generally costs more than standard systems
    • Requires thoughtful system design and automation
    • Often involves redundant components
• Examples:
  • Keeping a backup physical server ready to take over if the primary one fails
  • Automatic failover mechanisms that switch to standby or replica systems when a failure is detected
• Important: HA does not eliminate failures or prevent outages entirely
  • Downtime can still occur, but it is minimized in duration
  • Temporary disruption to users is acceptable as long as the system recovers quickly
    • Systems may briefly go offline during component replacement
    • Users may need to reconnect
• Summary: HA emphasizes rapid and automated recovery from failures
  • Real-world analogy: carrying a spare tire in a vehicle—you may still stop to fix a flat, but recovery is much faster than waiting for external help

HA Summary Diagram

Fault Tolerance (FT)

• A fault-tolerant (FT) system is built to continue functioning correctly even when one or more components fail
  • The system can operate despite existing faults
    • Failures are handled while the system remains operational
    • Faulty components are isolated, and traffic is automatically redirected
  • FT goes beyond HA and is significantly more expensive
    • Designed for zero downtime
    • Requires a higher level of redundancy
• Example:
  • A hospital heart monitoring system where continuous operation is critical
    • Any interruption could have life-threatening consequences
• Real-world analogy:
  • An aircraft equipped with multiple redundant systems
    • It must remain operational even if a component fails
    • Repairs cannot be performed mid-flight

FT Summary Diagram

Disaster Recovery (DR)

• Disaster Recovery (DR) refers to a combination of strategies, tools, and procedures used to restore or maintain critical systems and infrastructure after a disaster
  • Essentially, it addresses what happens when both HA and FT are insufficient
  • Involves planning for events that can disrupt entire systems
    • Before a disaster: preparation and planning
    • After a disaster: execution of recovery procedures
  • Modern DR processes are often automated to reduce human error
  • Business Continuity (BC) ensures operations continue during a disruption, while DR focuses on restoring systems and data afterward
• During disasters, stress and confusion can lead to poor decisions, making preparation essential
• Key elements of an effective DR strategy:
  1. Develop a clear plan with defined priorities
     • Protect critical assets to enable system rebuilding
  2. Strengthen infrastructure resilience
     • Use additional hardware, servers, or instances
     • Maintain regular backups
       • Backups should be stored offsite, not in the primary location
       • This prevents loss if the main site is affected
  3. Build organizational knowledge
     • Maintain detailed documentation (e.g., access credentials for backup systems)
     • Conduct staff training and regular DR drills
• Real-world analogy:
  • An emergency evacuation system (like parachutes) in an aircraft
    • Equipment can be replaced, but human life cannot

DR Summary Diagram

AWS Global Infrastructure

AWS Global Network

• AWS infrastructure is distributed worldwide, organized into multiple smaller infrastructure groupings that are interconnected through a high-speed global network
  • Reference: https://www.infrastructure.aws/ → visualization of the AWS global network
  • The AWS global network is continuously expanding and evolving
• There are three main types of infrastructure groupings:
  1. Regions
  2. Availability Zones (AZs)
  3. Edge Locations (Points of Presence / PoPs)

AWS Infrastructure Groupings

AWS Region

• A Region is a physical geographic area that contains a complete set of AWS services such as compute, storage, databases, analytics, and more
  • Example: Asia Pacific (Sydney), identified by the code ap-southeast-2
    • “Asia Pacific (Sydney)” refers to the region name, while ap-southeast-2 is its identifier
  • Regions are not the same as countries, states, or continents
    • AWS defines these boundaries based on where it deploys infrastructure
• Regions are connected to one another through high-speed networking
• They enable systems to be designed for global fault tolerance
  • If one region experiences a failure, workloads can operate from another region
• A region must be selected when working with non-global AWS services
  • Global services (such as IAM) do not require a region selection
• Key benefits of using regions:
  1. Geographic isolation (fault separation)
     • Failures in one region are contained and do not affect others
  2. Regulatory and legal separation
     • Data is governed by the laws of the region where it is stored
     • Data does not leave a region unless explicitly configured
  3. Improved performance through proximity
     • Placing infrastructure closer to users reduces latency
• Factors to consider when selecting a region:
  • Regulatory requirements (e.g., data residency rules)
  • Latency and performance based on user location
  • Service availability, since not all services exist in every region
  • Pricing differences across regions

AWS Availability Zone (AZ)

• An Availability Zone (AZ) is a subdivision of a region
  • Each region typically contains 3 to 6 AZs
  • Example: ap-southeast-2a, ap-southeast-2b, ap-southeast-2c within the Sydney region
• AZs provide isolation within a region
  • Each AZ has separate compute, storage, networking, power, and facilities
  • If one AZ fails, services can continue running in other AZs if configured properly
• An AZ is not the same as a single data center
  • One AZ may consist of one or multiple data centers
  • Data centers are physically separated and include redundant power, networking, and connectivity
• AZs are connected to each other with high bandwidth and low latency links
• Some AWS services operate across multiple AZs for resilience

AWS Edge Location (Point of Presence / PoP)

• An Edge Location is a smaller distribution site used to deliver data to users with low latency
  • Much smaller compared to regions
  • Often used for content delivery (e.g., caching media closer to users)
  • Typically located in third-party data centers
  • Primarily storage-focused (e.g., caching), with limited compute capabilities
• These locations support edge computing use cases
• While technically different, Edge Locations and PoPs are commonly treated as the same concept

Resilience of an AWS Service

1. Global resilience
   • A global service operates as a single system with a centralized data layer
     • Data is replicated across multiple regions
     • The service can continue functioning even if an entire region fails
   • Examples include IAM and Route 53
2. Regional resilience
   • A regional service runs within a specific region, using a database located in that region
     • Data is replicated across all AZs within the region
     • Can tolerate failure of a single AZ
     • If the entire region fails, the service becomes unavailable in that region
   • Examples include VPC and S3
     • S3 bucket names are globally unique, but the data resides within a region
3. Availability Zone (AZ) resilience
   • The service operates within a single AZ
     • More vulnerable to failure compared to regional or global services
     • However, architectures can still achieve high availability by distributing workloads across AZs
   • Hardware-level failures may occur without taking down the entire AZ
   • Examples include EC2 and RDS

Amazon S3 (Simple Storage Service) 101

Amazon S3 – Core Concepts

• AWS’s primary storage service
  • Object Storage (not a file system, not block storage)
    • Stores objects (data items) inside buckets (containers for objects)
  • Ideal for large-scale data storage (videos, audio, images, text, unstructured data)
    • Cost-effective
    • Accessible via AWS console, CLI, API, and HTTP(S)
  • Fully public service, supports unlimited storage and multiple users
  • Many AWS services use S3 as their default input/output storage
• S3 is a global service with regional resilience
  • Bucket names must be unique worldwide
  • Data is stored in specific regions and replicated across availability zones
• Key distinctions of S3:
  • Not a File Store → cannot browse it like a typical file system
    • Use Amazon EFS or Amazon FSx for file-based storage
  • Not a Block Store → cannot mount a bucket as a drive like K:\ or /images
    • Use Amazon EBS for mountable block storage

S3 Objects

• Objects are like files (conceptually similar but technically different)
• Object components:
  • Key → the unique identifier for an object within a bucket (like a filename)
    • Example: koala.jpg
  • Value → the actual data/content of the object
    • Size can range from 0B to 5TB
    • 5TB is the maximum size for a single object
  • Other attributes: Version ID, metadata, access control lists (ACLs), and subresources
• Objects exist only inside buckets; they cannot exist independently

S3 Bucket

• Bucket = container for S3 objects
  • Created within a specific region for controlled data residency
    • Its data stays in the region unless explicitly configured to replicate: AWS Global Infrastructure
  • Can hold an unlimited number of objects, making S3 highly scalable
• Bucket names:
  • Must be unique globally
    • Example: koaladata
    • The ARN does not include the region: arn:aws:s3:::koalacampaign13333337
  • Naming rules:
    • 3–63 characters, lowercase letters only, no underscores
    • Must start with a lowercase letter or number
    • Cannot resemble an IP address (e.g., 1.2.3.4)
• Flat storage structure (no true folders or directories)
  • Objects are all stored at the same level
  • AWS console shows folder-like structures, but these are prefixes, not actual directories

Example: /images/badges.jpg appears under /images/, but /images/ is not a folder, just a prefix used to filter/display objects

• Bucket limits per AWS account
  • Default: 10,000 buckets
    • See AWS docs: S3 Bucket Limits
    • Requests to exceed require AWS support approval
  • Limits affect architecture choices; e.g., using prefixes instead of creating one bucket per user for large user bases
• Buckets are private by default
  • AWS includes a failsafe to block all public access

• Turning off the failsafe does not make the bucket public automatically; explicit permissions are still required

Amazon VPC (Virtual Private Cloud) 101

Amazon VPC – Core Concepts

• Create and manage private networks within AWS
  • A Virtual Private Cloud (VPC) is a private virtual network inside an AWS account
    • VPC CIDR defines the IP address range for the VPC (e.g., 172.31.0.0/16)
  • Most AWS services and resources (especially private ones, like EC2 instances) run inside VPCs
• VPCs exist within a single AWS account and region → regionally resilient
  • Subnets (smaller network segments) can be deployed across different availability zones (AZs) in the region
    • If one AZ fails, other AZs in the region keep the VPC operational
  • Subnet CIDR = portion of the VPC’s CIDR
    • Once set, it cannot be modified
• Types of VPCs:
  • Default VPC (0–1 per region)
    • Always comes with preconfigured settings
  • Custom VPCs (0 or more per region)
    • Require manual configuration
    • Private by default
• Custom VPCs are isolated by default
  • No communication with external networks or other VPCs occurs unless explicitly configured
  • Specific setup is required to connect a Custom VPC to:
    • Other VPCs
    • On-premises networks (hybrid cloud)
    • Other cloud platforms (multi-cloud)
    • Public internet
  • Default VPCs are an exception to this strict isolation

Default VPC

• Automatically created by AWS and preconfigured in a consistent way
  • Predictable → useful for quick testing
  • Less flexible → not ideal for production environments
• Default VPC CIDR = 172.31.0.0/16 (always fixed)
• 0–1 per region
  • Can be deleted and recreated
    • “Create VPC” creates a Custom VPC, which is not the same as restoring a Default VPC

• Some AWS services expect a Default VPC, so keeping it is recommended
• Subnets
  • One /20 subnet is created in each AZ of the region
    • Example: us-east-1 (N. Virginia) has 6 AZs → Default VPC has 6 subnets

• Preconfigured components
  • Internet Gateway (IGW), Security Groups (SG), Network ACLs (NACL)
  • By default, resources in the Default VPC are assigned a public IPv4 address, making them reachable from the internet
    • Custom VPCs do not assign public IPs by default

Default VPC – Reference Diagram:

Amazon EC2 (Elastic Compute Cloud) 101

Amazon EC2 – Core Concepts

• AWS’s main compute service
  • IaaS (Infrastructure-as-a-Service) → customers use and manage the OS
  • Users launch instances, which run on physical EC2 hosts
    • Instances are also called virtual machines (VMs) or virtual servers (VSs)
    • Customers manage instances, while AWS manages hosts (except for dedicated EC2 hosts, which the customer manages)
• Instances run inside VPC subnets
  • EC2 instances are private by default
  • EC2 is resilient across availability zones (AZs)

EC2 Instances

• An instance is a virtual machine
  • Customers choose and configure the OS
  • Runtime Environment (RTE), databases, and applications can be installed and managed within the instance
• Instance size and capacity are defined at launch
  • Some configurations can be modified after launch
• Billing: Default is On-Demand → charged per second of usage
• Networking: Deployed inside VPC subnets
  • Private by default
  • Public access requires configuration
• Storage options:
  • Local, ephemeral block storage (Instance Store)
  • External, persistent block storage via Amazon EBS (Elastic Block Store)

EC2 Instance State

• State represents the condition of the instance
• Main states:
  1. Running (Active)
     • Billed for CPU, network, memory, and storage usage
  2. Stopped (Inactive)
     • Billed only for storage
     • Can be restarted
  3. Terminated (Deleted)
     • Completely deleted and cannot be restarted
     • No further charges apply

Connecting to EC2 Instances via SSH

• SSH (Secure Shell) → secure protocol for connecting to instances
  • Uses port 22
  • Authentication through SSH key-pairs (private + public)
    • Private key is downloaded once to the local machine (e.g., A4L.pem)
    • Public key stored on the EC2 instance by AWS
• Once connected via SSH, you can manage the instance via a command-line terminal
• Private key permissions must allow only the owner to read it:
  • chmod 400 A4L.pem (Mac/Linux)
  • Other users on the same machine cannot access the file
  • AWS rejects connections if permissions are incorrect

Connecting to Older Windows Instances via RDP

• Older Windows OS (< Win10) do not support SSH natively
  • Use RDP (Remote Desktop Protocol) instead
    • Runs on port 3389
  • SSH keys are used to retrieve the administrator password
  • Once authenticated, users access the instance via RDP

Amazon Machine Image (AMI)

• AMI = template for launching EC2 instances
  • Similar to a VM snapshot or OS installation media
  • Contains the OS, disk image, kernel, and configuration
• Can launch a new EC2 instance or create an AMI from an existing instance (“snapshot”)
  • Disk image includes OS and any installed software at the time of creation
• Components:
  • Permissions → control who can launch instances from the AMI
    • Public AMI → anyone can use
    • Private AMI → owner only
      • Implicit Allow: AMI owner can launch
      • Explicit Allow: owner can allow specific AWS accounts
    • By default, AMIs are private and owner-only
  • Root/Boot Volume → OS boot drive (e.g., C: for Windows or / for Linux)
  • Block Device Mapping → defines how storage volumes are presented to the OS

Amazon CloudWatch (CW) 101

Amazon CloudWatch – Components and Architecture

• Collects and manages operational data to provide monitoring and operational insights
  • Data includes service performance, metrics, and logs
  • Acts as a core support service for most AWS products
  • Available as a public service
• Main components:
  1. CloudWatch Metrics – the core metrics service
     • Examples: CPU utilization for EC2, disk usage on an on-premises server
     • Can ingest metrics from AWS services, custom applications, or on-premises systems
     • Some metrics are collected automatically by AWS
     • CloudWatch Agent is required to:
       • Collect metrics inside AWS not gathered natively (e.g., internal EC2 processes)
       • Collect metrics from external infrastructure
  2. CloudWatch Logs
     • Can collect logs from AWS services, custom apps, or on-premises servers
     • Some logs are created automatically; others require the CloudWatch Agent
  3. CloudWatch Alarms
     • Trigger notifications via Amazon SNS or initiate events based on metric thresholds
     • Examples: Send an SMS if EC2 CPU usage exceeds 90%
     • Billing alarms also use CloudWatch to send notifications when costs exceed a set budget
  4. Events (now Amazon EventBridge)
     • Works with AWS services and scheduled tasks
     • Generates events that can trigger automated actions
     • Events can be based on:
       1. Conditions (e.g., EC2 instance created or terminated)
       2. Schedules (e.g., every Friday at 18:00)

Amazon CloudWatch – Key Concepts

• Datapoint = Timestamp + Value
  • Example: CPU usage 98.3% at 08:45:45 on 2019-12-03
• Metric = Sequence of datapoints over time
  • Examples: CPU usage, network I/O, disk I/O
  • A metric is not always tied to a single server; by default, CPU usage may reflect all EC2 instances unless specified

• Namespace – Container for metrics to organize monitoring data
  • Prevents naming conflicts
  • Example: AWS/ stores all AWS service metrics
    • Example: AWS/EC2 stores all EC2 metrics
• Dimensions – Attributes to differentiate datapoints within the same metric
  • Example: Within AWS/EC2, dimensions can separate Instance A from Instance B
  • Provides flexibility for monitoring different perspectives

• Alarms trigger actions when metrics reach specified thresholds
  • Example: Notify when budget is exceeded
• Alarm States:
  • INSUFFICIENT DATA – initial state
  • OK – metric within threshold
  • ALARM – metric exceeds threshold, triggers Amazon SNS notifications

AWS CloudFormation (CFN) 101

IaC Basics and AWS CloudFormation

• Infrastructure as Code (IaC)
  • Allows you to create, update, and delete infrastructure using code or templates
  • Code/templates are repeatable and consistent
    • Reduces human errors
    • Faster than manually provisioning or deleting resources
• AWS CloudFormation (CFN) – AWS’s official IaC service
  • Templates written in YAML or JSON define infrastructure within AWS
  • External IaC tools like Terraform or CDK often generate CFN templates to deploy infrastructure

CFN Templates – Structure and Components

• Templates are usually stored in an S3 bucket with prefix CF
  • Note: CFN (CloudFormation) ≠ CF (CloudFront)

Example templates in YAML/JSON:

• Resources → mandatory section defining AWS resources
  • Examples: VPCs, S3 buckets, EC2 instances
  • Resources in templates are logical resources, not the actual physical infrastructure
• AWSTemplateFormatVersion → template version
• Description → optional text explaining template purpose
• Metadata → controls how the template appears in AWS UI

Example:

• Parameters → fields prompting user input when creating a stack

Example:

• Mappings → key-value lookups for conditional values

Example:

• Conditions → control resource creation based on logic
  • Example: create an EC2 instance only in PROD environment

Example:

• Outputs → return information when the template executes
  • Example: “EC2 instance created”

Example:

• Templates can also include intrinsic functions:
  • LatestAmiId → fetch the latest AMI in a region
  • !Ref → reference another resource in the template
  • !GetAtt → get a resource’s attribute

CFN Stacks

• A CFN template defines logical resources and other components
• CFN Stack → live representation of all resources in a template
  • Executed in an AWS account to create, update, or delete infrastructure
  • Each logical resource in the stack corresponds to a physical AWS resource

Syncing Logical and Physical Resources

• Physical resource → exists in AWS, visible in the UI
  • Example: running EC2 instance with ID i-1234567890abcdef0
• Logical resource → defined in CFN templates and stacks
  • Has a type (e.g., AWS::EC2::Instance)
  • Has properties (e.g., ImageID, KeyName)
• CFN ensures logical and physical resources remain in sync
  • Automates infrastructure management and reduces manual effort
  • Allows template-based approval workflows before committing changes
  • Quick one-off deployments are possible
    • Deleting a stack removes both logical and physical resources, automatically cleaning up infrastructure
  • Many SAA-C03 labs use CFN stack deployments

AWS Lambda 101

AWS Lambda – Key Concepts

• Function-as-a-Service (FaaS) lets you run small, specific pieces of code without managing servers.
  • A Lambda function is the code that AWS Lambda executes.
    • Also serves as a unit of configuration in Lambda.
    • Informally, “Lambda” usually refers to the function itself.
• Every function must specify a Runtime Environment (RTE) (e.g., Python 3.8) before it can run.
  • Memory is directly set, while CPU is allocated automatically based on memory.
  • The function executes inside this environment when triggered.
• Billing is based only on actual compute usage during function execution.
  • This is a key part of serverless and event-driven architectures.
  • Lambda is cost-effective: first million requests are free, and subsequent requests are inexpensive.

AWS Lambda – Architecture

• A Lambda function includes code, configuration, and execution wrappers.
  • Required components: programming language, deployment package (downloaded and executed at runtime), and allocated resources.
  • Informally, people may refer to only the code as “Lambda,” but the function encompasses more than the code.
• Supported runtimes include Python, Ruby, Java, Node.js, etc.
  • Lambda Layers can add custom runtimes, such as Rust.
• Choosing a runtime determines the software environment available.
• Each invocation creates a new runtime environment:
  • Code is loaded, executed, and the environment is discarded.
  • Future invocations generally run in a fresh environment; some settings allow reusing previous resources, but this is not default.
• Lambda functions are generally stateless; no data persists between invocations. Code must run correctly in a new environment each time.
• Traditional Docker containers are not standard for Lambda.
  • Lambda supports container images, but these must be built specifically for Lambda, not standard Docker containers.
• Resource limits:
  • Memory: 128 MB – 10,240 MB (1 MB increments)
  • vCPU: assigned automatically based on memory (1 vCPU per ~1,769 MB)
  • Temporary disk space: 512 MB at /tmp by default, up to 10,240 MB
    • Cleared each invocation; only for temporary use.
• Maximum timeout: 900 seconds (15 minutes). Tasks longer than this require Step Functions or other services.
• Execution role: IAM role assigned to the function to control access to AWS resources.

AWS Lambda – Common Use Cases

• Serverless applications: e.g., S3 + API Gateway + Lambda.
• File processing: e.g., processing or transforming files uploaded to S3.
• Database triggers: Lambda runs automatically when items in DynamoDB are added, updated, or deleted.
• Scheduled tasks: using EventBridge or CloudWatch Events to run functions at set times.
• Real-time stream processing: Lambda reacts to new data in streams like Kinesis.

Demo: Create and Test a Lambda Function

1. Deploy the CloudFormation stack provided in the demo, which creates two EC2 instances
2. Create an execution role:
   • Either in IAM or during Lambda creation.
   • Example JSON policy (allow Lambda to start/stop EC2 instances and log to CloudWatch):
   {
   “Version”: “2012-10-17”,
   “Statement”: [
   {
   “Effect”: “Allow”,
   “Action”: [
   “logs:CreateLogGroup”,
   “logs:CreateLogStream”,
   “logs:PutLogEvents”
   ],
   “Resource”: “arn:aws:logs:*:*:*”
   },
   {
   “Effect”: “Allow”,
   “Action”: [
   “ec2:Start*”,
   “ec2:Stop*”
   ],
   “Resource”: “*”
   }
   ]
   }

3. Go to Services → Lambda → Create Function
A. Enter a function name and select a runtime (Python 3.9 in demo)

B. Assign the execution role created earlier

4. Once the function is created, add the code to stop EC2 instances:

A. Stop EC2 instances Python script

import boto3
import os
import jsonregion = 'us-east-1'
ec2 = boto3.client('ec2', region_name=region)def lambda_handler(event, context):
    instances = os.environ['EC2_INSTANCES'].split(",")
    ec2.stop_instances(InstanceIds=instances)
    print('stopped instances: ' + str(instances))

B. Paste the code into the Lambda function editor

5. Set Environment Variables
   • Go to Configurations → Environment variables.
   • Add a variable named EC2_INSTANCES with the EC2 instance IDs, separated by commas (no spaces).
6. Test the function
   • Click Test (no event input needed).
   • After execution, check the EC2 console to confirm the instances were stopped.
7. Create another function to start EC2 instances in a similar way:

A. Start EC2 instances Python script

import boto3
import os
import jsonregion = 'us-east-1'
ec2 = boto3.client('ec2', region_name=region)def lambda_handler(event, context):
    instances = os.environ['EC2_INSTANCES'].split(",")
    ec2.start_instances(InstanceIds=instances)
    print('started instances: ' + str(instances))

B. Test the function and verify in the EC2 console that the instances were started.

8. Clean-up
   • Delete the Lambda functions created.
   • Delete the CloudFormation stack used for the demo.

Amazon R53 (Route 53) 101

Amazon Route 53 – Key Concepts

• DNS-as-a-Service (DNSaaS) → AWS-managed solution for DNS
• Global service
  • Maintains a single database that is replicated across all regions
  • Highly available and resilient worldwide
  • No region selection required in the console
• Main functionalities:
  1. Registered Domains
     • Acts as a domain registrar
  2. Hosted Zones
     • Functions as a DNS hosting service
• Costs: Besides domain registration and renewal fees, hosting the DNS zones also incurs charges

Registered Domains

• R53 interacts with all top-level domains (TLDs) like .com, .net, .io
  • Example: PIR (Public Interest Registry) manages the .org domain
• Process to register a domain (e.g., animals4life.org):
  1. R53 checks if the domain is available
  2. If available, the user accepts the terms and purchases it through R53
  3. R53 generates a ZoneFile for the domain (contains DNS information)
  4. R53 assigns four AWS-managed name servers for the domain
  5. R53 creates a hosted zone
     • ZoneFile is stored across the four NSs
     • Registered Domains and Hosted Zones are updated to reference these NSs
  6. R53 communicates with the TLD registry (e.g., PIR for .org)
     • The TLD points to R53’s NSs, making them authoritative for the domain
• Note: You do not need to purchase a domain to follow AWS CLF-C02 or SAA-C03 courses. Domain registration is optional but required for projects like the Cloud Resume Challenge.
• Transfer lock (default enabled): Prevents the domain from being moved outside of R53
• Important: If a hosted zone is deleted and recreated, you must update the NS records in Registered Domains to reference the new servers. Failure to do so will break DNS resolution.

Hosted Zones

• Each hosted zone runs on four AWS-managed name servers
  • These servers contain DNS records (RRSETs)
• Network visibility:
  1. Public Hosted Zones:
     • Records are visible globally
     • Accessible over the public internet
  2. Private Hosted Zones:
     • Linked to specific VPCs
     • Only accessible within those VPCs
     • Useful for sensitive or internal DNS
• Billing:
  • Monthly hosting fee
  • Charges per query made against the zone
  • Costs can grow with high query volumes, so consider this for large-scale applications