Networking & DNS

Virtual Private Cloud (VPC) Basics

IP Subnetting

Subnetting – Key Concepts

• Subnetting is the process of dividing a network into smaller segments called subnets.
  • Comparable to cutting a larger structure into smaller, manageable parts.
  • It can be challenging initially but becomes easier with consistent practice.
• A network is represented using CIDR notation, which combines the base IP address with a prefix length.
  • Example:
    • 10.16.0.0 to 10.16.255.255 → 10.16.0.0/16
  • CIDR (Classless Inter-Domain Routing) defines both the network range and its size.
• Key points about prefixes:
  • The prefix indicates how many bits (or octets) are fixed for the network portion.
  • A larger prefix value results in a smaller network range.
  • Examples:
    • /0 represents the entire address space
    • /8 corresponds to a large network (Class A)
    • /16 corresponds to a medium network (Class B)
    • /24 corresponds to a smaller network (Class C)
    • /32 represents a single IP address
• Standard subnetting typically involves splitting a network into equal halves:
  • Example:
    • 10.16.0.0/16 can be divided into two /17 subnets:
      • 10.16.0.0/17
      • 10.16.128.0/17
  • Subnets can be further divided repeatedly into smaller segments (2, 4, 8, etc.).
  • While uneven splits are technically possible, most designs favor equal-sized subnets for consistency.
• Although examples often use IPv4, the same subnetting principles apply to IPv6.

Subnetting Process Step by Step

• It is recommended to follow a visual or guided walkthrough to fully understand the subnetting process.
• Mastery comes through repeated practice and applying subnetting in different scenarios.

Designing Business Networks and IP Plans

Building a reliable infrastructure platform depends as much on strong design decisions as it does on technical implementation.

• Creating an IP plan for a business involves designing one or more networks within that plan.
  • In AWS, this typically means designing a VPC.
  • Understanding VPC sizing and structure is essential to prevent current limitations and future scaling issues.
• Planning IP ranges ahead of time:
  • Done correctly → results in a well-structured and scalable network.
  • Done poorly → difficult and costly to fix later.
    • Decide early whether to use one or multiple CIDR ranges.
    • Ensure that VPCs or networks do not overlap, as this creates major connectivity issues.

Considerations when Designing Business Networks

• Plan with future growth in mind.
  • Consider current and future AWS regions.
  • Account for existing and additional AWS accounts.
  • A practical approach is to reserve multiple networks per region and per account.
    • Example: allocate at least two or more networks per region and account.
  • It is also beneficial to reserve extra tiers and Availability Zones for future use.
• Identify networks that must not overlap.
  • Includes other VPCs, cloud environments, on-premises networks, and partner networks.
  • When uncertain, assume conflicts may exist and plan conservatively.
  • Gathering this information from internal teams is critical before finalizing the design.
• Two common design approaches:
  1. Top-down: start with a large IP range and divide it to meet requirements.
  2. Bottom-up: begin with the smallest required subnet sizes and expand as needed.

VPC Sizing and Structuring – Concepts

VPC Size (CIDR)

• Define the CIDR block for the VPC.
• AWS allows IPv4 VPC sizes ranging from /28 to /16 (16 to 65,536 IP addresses).
• The chosen size determines how many resources and services can be deployed, since each requires an IP address.

VPC Structure (Subnets)

• Determine how the VPC will be divided into subnets.
  • AWS resources are deployed within subnets, not directly in the VPC.
• Tiers represent different application layers:
  • Common model:
    • WEB – frontend servers
    • APP – backend application logic
    • DB – database layer
  • Often, an additional spare tier is included for flexibility.
• Availability Zones (AZs) define resilience:
  • The number of AZs impacts availability and fault tolerance.
  • A common approach is to use at least three AZs, with an optional fourth as a buffer.

VPC Sizing and Structuring – Example

VPC Sizing & Structuring – Considerations

• Key planning questions:

• How many subnets are required?
• How many total IPs and IPs per subnet are needed?
• Example structure:
  • 4 tiers × 4 AZs = 16 subnets
    • If VPC = /16 → each subnet = /20
    • If VPC = /17 → each subnet = /21
• Recommended IP range strategy:
  • Use the 10.x.x.x private range.
  • Avoid commonly used ranges (e.g., 10.1–10.10) to reduce overlap risks.
  • Starting at ranges like 10.16.x.x helps avoid conflicts and aligns well with subnetting boundaries.
• Maintain clear documentation:
  • Track all IP allocations in a structured format such as spreadsheets or diagrams.
  • This improves visibility and simplifies future scaling or troubleshooting.

VPC Design for A4L Scenario

• This architecture represents a complete VPC design example.
• Understanding each component will become easier after covering all VPC-related concepts.

Amazon VPC (Virtual Private Cloud) 101

Amazon VPC – Core Concepts

• Provision and manage private networks within an AWS account
  • A Virtual Private Cloud (VPC) is a logically isolated virtual network inside AWS
    • The VPC CIDR block defines the IP address range of the network (e.g. 172.31.0.0/16)
  • Most AWS services and resources—especially private ones like EC2—operate within a VPC
• VPC scope: single account and single region
  • VPCs are regionally scoped and resilient
  • Subnets (smaller network segments) can be distributed across multiple Availability Zones (AZs)
    • If one AZ fails, workloads in other AZs within the same VPC remain available
  • A subnet CIDR is a subdivision of the VPC CIDR
    • Once assigned, subnet CIDR ranges cannot be modified
• Types of VPCs
  • Default VPC (0–1 per region)
    • Automatically created with a predefined configuration
  • Custom VPCs (0 or more per region)
    • Fully configurable and private by default
• Isolation and connectivity
  • Custom VPCs are isolated by default
    • No inbound or outbound communication is allowed unless explicitly configured
  • Additional setup is required to enable communication with:
    • Other VPCs
    • On-premises networks (hybrid setups)
    • Other cloud providers (multi-cloud)
    • The public internet
  • The Default VPC is an exception and does not follow strict isolation by default

Default VPC

• Automatically provisioned by AWS with a standard configuration
  • Provides a ready-to-use environment, ideal for quick testing and basic deployments
  • Limited flexibility makes it unsuitable for production use cases
• Fixed CIDR block
  • Always uses 172.31.0.0/16 (constant across all regions)
• Availability
  • Only one Default VPC per region
  • Can be deleted and later recreated
    • Recreating the Default VPC is a separate action from creating a new (custom) VPC

• Subnet distribution
  • Automatically creates one /20 subnet per Availability Zone in the region

• Preconfigured components
  • Includes:
    • Internet Gateway (IGW)
    • Security Groups (SGs)
    • Network ACLs (NACLs)
• Public accessibility by default
  • Resources launched in the Default VPC are typically assigned a public IPv4 address
  • This allows direct internet access unless restricted
  • Unlike Custom VPCs, the Default VPC is not isolated by default

Custom VPCs

Amazon VPC – Refresher

• Builds on the foundational concepts of Amazon VPC
• A regional service: when a VPC is created in a region, it can span all Availability Zones within that region, providing regional resilience
• Enables creation of logically isolated networks within AWS:
  • No inbound or outbound traffic is allowed unless explicitly configured
  • Provides an isolated blast radius, meaning any compromise is contained within the VPC and its connected environments
• Supports hybrid networking architectures
  • VPCs can integrate with on-premises environments and other cloud networks
• Offers a modular design approach
  • Start with a basic setup and incrementally add components as needed

Amazon VPC – Custom VPCs

• Fully configurable, customer-managed VPCs
  • Can range from simple designs to complex multi-tier architectures
  • In contrast to Default VPCs, which have a fixed configuration
• Tenancy options
  • Default Tenancy: resources run on shared hardware
  • Dedicated Tenancy: resources run on dedicated hardware
    • Default Tenancy allows flexibility to choose dedicated hardware at the resource level later
    • Dedicated Tenancy at the VPC level enforces dedicated hardware for all resources and cannot be changed
    • Default Tenancy is generally the safer and more flexible option

Custom VPC IP Addressing (Quotas)

IPv4

• Private CIDR blocks are required and form the primary communication range
  • Minimum size: /28 (16 IP addresses)
  • Maximum size: /16 (65,536 IP addresses)
  • A primary private IPv4 CIDR block is mandatory
• Additional secondary IPv4 CIDR blocks can be added after creation
  • Up to 5 by default
  • More can be requested through AWS support
• Public IPv4 addresses can be assigned when external access is required

IPv6

• No distinction between private and public addresses
  • All IPv6 addresses are inherently routable
  • Access is still controlled through security configurations
• Optional /56 IPv6 CIDR block
  • IPv6 support is still evolving, but adoption is increasing
  • Recommended to enable for forward compatibility
• Address allocation:
  • Use AWS-assigned IPv6 ranges or bring your own IPv6 addresses
  • AWS-assigned ranges do not allow selection of specific addresses
• Custom VPCs can be configured as:
  • IPv4-only, or
  • Dual-stack (IPv4 + IPv6)

DNS in VPCs

• VPCs include integrated DNS capabilities, powered by Amazon Route 53
• DNS is accessible at the base IP address + 2
  • Example: for 10.16.0.0, DNS resolver is 10.16.0.2
• Two key configuration settings:
  • enableDnsSupport
    • Enables DNS resolution within the VPC
  • enableDnsHostnames
    • Assigns DNS hostnames to resources with public IP addresses
• These settings are common root causes for DNS-related issues and should be verified during troubleshooting

Demo: Custom VPC Design (Course Scenario)

• Demonstrates designing a custom VPC aligned with real-world architecture requirements
• Focuses on structuring subnets, tiers, and connectivity within a scalable and resilient environment

VPC Subnets & DHCP Options Set

VPC Subnets – Core Concepts

• Definition: A subnet is a logical subdivision of a VPC that exists within a single Availability Zone (AZ)
  • Subnets are the deployment layer where private AWS resources and services operate
  • The design, behavior, and resilience of a VPC are largely determined by how its subnets are structured
• Common diagram conventions
  • Blue represents private subnets (default state)
  • Green represents public subnets
    • A subnet becomes public only after specific configurations are applied
• Availability Zone dependency
  • Subnets are AZ-scoped, meaning each subnet is tied to one AZ
  • If the AZ becomes unavailable, the subnet and all hosted resources are impacted
  • For high availability, workloads should be distributed across multiple subnets in different AZs
  • The AZ assignment of a subnet is permanent and cannot be changed
  • Each AZ can host multiple subnets
• Intra-VPC communication
  • Subnets within the same VPC can communicate by default
  • Network isolation is enforced at the VPC boundary, not between subnets
  • Internal communication is unrestricted unless explicitly controlled

VPC Subnets – IP Addressing

• IPv4 CIDR
  • Required for all subnets
  • Must be a subset of the VPC’s IPv4 CIDR range
• IPv6 CIDR
  • Optional and only available if the VPC has an IPv6 CIDR assigned
  • Each subnet receives a /64 block, derived from the VPC’s /56 range
  • A VPC can support up to 256 IPv6 subnets
• CIDR constraints
  • Subnet CIDR blocks must not overlap with other subnets in the same VPC
• IP assignment settings
  • Auto-assign public IPv4
    • Automatically assigns a public IPv4 address to resources upon launch
    • Required for enabling internet-facing resources in a subnet
  • Auto-assign IPv6
    • Automatically assigns IPv6 addresses to resources
• Reserved IP addresses
  • AWS reserves 5 IP addresses per subnet
  • Example: 10.16.16.0/20
    1. Network address (first IP): 10.16.16.0
    2. VPC router: 10.16.16.1
    3. DNS resolver (provided by Amazon Route 53): 10.16.16.2
    4. Reserved for future use: 10.16.16.3
    5. Broadcast address (last IP): 10.16.31.255
  • These reserved addresses reduce the number of usable IPs
    • Example: a /28 subnet (16 IPs) provides only 11 usable addresses

DHCP Options Set

• Dynamic Host Configuration Protocol (DHCP)
  • Automatically assigns IP configuration to resources within the network
• DHCP Options Set
  • A VPC-level configuration object that defines:
    • DNS servers
    • NTP (time synchronization) servers
    • NetBIOS settings
  • Applies to all subnets within the VPC
  • Only one DHCP options set can be associated with a VPC at any time
  • Cannot be modified after creation; changes require creating and associating a new set

Network Address Translation (NAT)

NAT – Core Concepts

• Network Address Translation (NAT) enables the mapping of private IPv4 addresses to public IPv4 addresses, and vice versa
  • Multiple private resources can share a single public IPv4 address
  • Public IPs are routable on the internet, while private IPs are only routable within internal networks
• Initially introduced to mitigate IPv4 address exhaustion
  • Also provides an indirect security advantage
    • Blocks unsolicited inbound connections from external sources
  • Not required in IPv6 environments due to the vast address space
• NAT is implemented by network devices (such as routers), which maintain translation tables (NAT tables)
  • These tables track mappings between private and public addresses
  • Normally, IP addresses remain unchanged across Layer 3 boundaries—except when NAT is applied

Types of NAT

Static NAT

• One-to-one mapping between private and public IP addresses
  • The association is fixed and persistent
  • In AWS, similar behavior is achieved via an Internet Gateway (IGW)
• Outbound flow
  1. A private resource sends traffic using its private IP as the source
  2. The NAT device replaces the source IP with its public IP and forwards the packet
  3. The destination system perceives the request as originating from the NAT device
• Inbound flow
  1. The external system responds to the NAT device’s public IP
  2. The NAT device consults its translation table and maps the destination back to the private IP
  3. The response is delivered to the originating resource
• Private resources do not possess public IPs; they rely on predefined NAT mappings

Dynamic NAT

• Many-to-many mapping using a pool of public IP addresses
  • Private resources are temporarily assigned a public IP from the pool when initiating connections
• Allocation behavior
  • When a connection is initiated:
    • If a public IP is available, it is assigned and recorded in the NAT table
    • If no IP is available, the connection request fails
  • Once the session ends, the public IP is released back into the pool
• Enables reuse of public IPs across multiple devices over time

Port Address Translation (PAT)

(also known as IP masquerading or NAT overload)

• Many-to-one mapping: multiple private IPs share a single public IP
  • Differentiation is achieved using port numbers
  • Each NAT table entry includes:
    • Private IP + private port
    • Public IP + unique public port
• This is the most widely used form of NAT
  • Common in home routers and enterprise environments
  • In AWS, implemented via NAT instances and NAT Gateways
• Connection handling
  • Multiple internal resources can connect to the same external service using different port mappings
  • The NAT device ensures each session remains unique through port translation
• Security characteristic
  • Only outbound-initiated connections are permitted
  • External systems cannot initiate connections to internal resources unless a mapping already exists
  • This behavior enhances security compared to static NAT, where mappings are permanently defined

VPC Routing, Internet Gateway & Bastion Hosts

VPC Router

• Handles traffic routing within a VPC
  • By default, it routes traffic within and between subnets
  • Additional configuration is required to route traffic outside the VPC
• Exists in every VPC
  • Has a network interface in each subnet
  • Uses the first usable IP (Network + 1) in each subnet
• Highly available by design
  • Operates across all Availability Zones in the VPC
  • No need for manual HA configuration
• Routing behavior is controlled using route tables

VPC Route Table (RT)

• Defines how traffic is directed
  • A route specifies the destination CIDR and the target location
• Key components:
  • Destination
    • CIDR block used to match the packet’s destination IP
    • If no match, the route is ignored
  • Target
    • Where matching traffic is forwarded
    • Examples:
      • local → stays inside the VPC
      • Internet Gateway (IGW) → routed to the internet
      • Other gateways (VGW, TGW, etc.)
• Routing priority rules
  • More specific routes (longer prefix) take precedence
  • Exception: the local route always has priority
• Subnet association
  • Each subnet is linked to exactly one route table
  • Default is the main route table
  • Custom route tables can be assigned as needed
• Local route
  • Automatically present in all route tables
  • Matches the VPC CIDR
  • Cannot be modified or removed
• Default route
  • Used when no other routes match:
    • IPv4: 0.0.0.0/0
    • IPv6: ::/0

Internet Gateway (IGW)

• Provides connectivity between a VPC and the public internet
  • Acts as the boundary between the VPC and AWS public network
  • Required for access to:
    • Public internet
    • Public AWS services (e.g., S3, SNS, SQS endpoints)
• Requirements for usage
  • Resource must have:
    • A public IPv4 address and/or
    • An IPv6 address
  • Route table must include a route pointing to the IGW

• Association rules
  • One IGW can be attached to only one VPC
  • A VPC can have zero or one IGW
• Highly available and managed by AWS
  • Automatically spans all AZs in the region
  • No scaling or maintenance required

IPv4 Behavior with IGW

• Public IPv4 addresses are not assigned directly to instances
  • They are mapped at the IGW level using static NAT
• Inside the instance:
  • Only the private IPv4 address is visible
• Traffic flow:
  • Outbound: private IP → translated to public IP by IGW
  • Inbound: public IP → translated back to private IP
• The IGW maintains the mapping between public and private IPs

IPv6 Behavior

• No NAT is performed
• IPv6 addresses are directly assigned to the instance
• Traffic is routed without translation

Bastion Host / Jump Box

• A secure entry point into private networks
  • Public-facing instance used to access private resources
• Typically deployed in a public subnet
  • External users connect to the bastion
  • Then access internal resources from there
• Can enforce:
  • IP restrictions
  • Authentication controls
  • Logging and monitoring
• Traditional approach for managing private EC2 instances
  • Still valid, but now often replaced by:
    • EC2 Instance Connect
    • AWS Systems Manager (SSM)

NAT Gateways & NAT Instances

Common Scenario: Updating Private EC2 Instances

• Private EC2 instances (in a VPC) are isolated from the internet by default
• If these instances need to download updates or patches, several approaches exist:

1. Convert the subnet to public
   • Allows direct internet access for instances
   • Drawback: breaks standard secure multi-tier architecture design, where private subnets are intentionally isolated
2. Maintain internal update servers
   • Host patch repositories within the VPC
   • Drawback: introduces operational overhead
     • Requires manually downloading updates and distributing them internally
3. Recommended approach: use NAT (Network Address Translation)
   • Enables private instances to access the internet without becoming publicly accessible
   • Deployment options:
     • NAT Instance (self-managed EC2)
     • NAT Gateway (NATGW) (AWS-managed service)

Refresher: Network Address Translation (NAT)

• NAT refers to techniques that modify source or destination IP addresses in network packets
• Relevant only for IPv4 (not required for IPv6)

NAT Types

1. Static NAT
   • One private IP maps to one public IP
   • Used by Internet Gateway (IGW)
2. Dynamic NAT
   • Multiple private IPs share a pool of public IPs
3. Port Address Translation (PAT)
   • Many private IPs share a single public IP
   • Differentiation handled via port numbers
   • Also known as IP masquerading
   • Most commonly used form of NAT in practice

• PAT enables:
  • Outbound-only internet access
  • Private instances can initiate connections
  • External systems cannot initiate connections back
• In AWS:
  • NAT functionality is typically implemented using:
    • NAT Instances
    • NAT Gateways (NATGW)

NAT Architecture in a VPC

• NAT Gateway is placed in a public subnet
• Private subnets route outbound traffic to the NATGW

Traffic Flow

1. Private subnet sends traffic to NATGW
   • Route table default route (0.0.0.0/0) points to NATGW
   • NATGW records sessions in a translation table
2. NATGW modifies source IP
   • Replaces private IP with its own private IP
3. Traffic is forwarded to Internet Gateway (IGW)
   • Via the VPC router
4. IGW performs final translation
   • Replaces NATGW private IP with a public IP
5. Return traffic follows reverse path
   • IGW → NATGW → private instance

NAT Gateway (NATGW) – Key Concepts

• AWS-managed NAT-as-a-Service
• Must be deployed in a public subnet
• Associated with an Elastic IP (static public IPv4)

Characteristics

• Fully managed by AWS
• Auto-scales up to high throughput (~45 Gbps)
• Provides high availability within a single AZ
• Minimal administrative effort required

Limitations

• Not regionally resilient by default
  • To achieve resilience:
    • Deploy one NATGW per AZ
    • Use AZ-specific route tables
• Security Groups are not supported
  • Only NACLs can be applied

Billing Model

• Charged based on:
  • Hourly usage
  • Data processed (per GB)
• Costs increase with:
  • Multiple NAT Gateways
  • High data transfer volumes

NAT Instances

• EC2 instances configured to perform NAT
• Must be deployed in a public subnet

Special Configuration

• Disable Source/Destination Checks
  • Required because NAT instances process traffic not originally addressed to them

NAT Instances vs NAT Gateway

Why NAT Gateway is the default choice

• Better performance and scalability
• AWS-managed → reduced operational overhead
• Built-in high availability (within AZ)

When NAT Instances may be preferred

1. Cost considerations
   • Lower cost for:
     • Small environments
     • Low traffic workloads
   • Can use small or free-tier instances
   • Predictable pricing (fixed instance size)
2. Multi-purpose usage
   • Can act as:
     • Bastion host
     • Port forwarding device
   • NATGW cannot be customized
3. Security flexibility
   • Supports Security Groups and NACLs
   • NATGW supports only NACLs

IPv6 Considerations

• NAT is not used with IPv6
• IPv6 addresses are globally routable

Connectivity Options

• Internet Gateway (IGW)
  • Enables bidirectional communication (inbound + outbound)
• Egress-Only Internet Gateway (EIGW)
  • Allows outbound-only traffic
  • Prevents inbound connections from the internet

Stateless vs Stateful Firewalls

TCP Connections, Ports, and Direction

• TCP is a connection-oriented protocol
  • Establishes a bi-directional session between a client and a server
  • Uses:
    • A random (ephemeral) port on the client
    • A well-known port on the server (e.g., HTTPS uses port 443)
• Ephemeral port range: typically 1024–65535
  • Exact range varies by operating system
  • In practice, firewall rules must allow the full range
• Each TCP session consists of:
  • A request
  • A response
• Traffic direction (inbound vs outbound) is relative
  • Depends on whether you are viewing from the client or server perspective

Stateless Firewall

• Evaluates each packet independently
  • Operates at Layer 3 (Network) and Layer 4 (Transport) of the OSI model
• Does not track connection state
  • Treats request and response as unrelated traffic
• Requires explicit rules for both directions
  • One rule for inbound traffic
  • One rule for outbound traffic
• When allowing inbound connections:
  • Must also allow ephemeral port ranges (1024–65535) for return traffic
• Drawbacks:
  • Higher administrative overhead
  • Greater risk of misconfiguration

Stateful Firewall

• Tracks active connections (sessions)
  • Maintains awareness of request-response relationships
  • Operates with awareness beyond basic packet inspection
• Automatically allows return traffic
  • Only one rule is needed to permit a connection
  • If a request is allowed, the corresponding response is implicitly allowed
• Advantages:
  • Simplifies rule management
  • Reduces likelihood of configuration errors
  • More efficient for handling dynamic traffic patterns

Network Access Control Lists (NACLs)

VPC NACL – Key Concepts

• Subnet-level stateless firewall
  • Network Access Control List (NACL) filters traffic crossing the subnet boundary (inbound/outbound)
  • Traffic inside the subnet is unaffected
  • For traffic between subnets, both NACLs must allow it
• Stateless behavior
  • Treats requests and responses as separate traffic
  • Requires two rules per connection (IN + OUT)
• Subnet association
  • Each subnet has one NACL (default or custom)
  • One NACL can be associated with multiple subnets
  • Only subnets can have NACLs – not individual resources
• Used alongside Security Groups (SGs)
  • SGs allow traffic
  • NACLs can explicitly deny traffic → ideal for blocking bad actors or IP ranges

NACL Rules

• Two rule sets per NACL:
  1. Inbound: affects data entering subnet
  2. Outbound: affects data leaving subnet
• Rule matching is based on:
  1. IP/CIDR (inbound:SRC, outbound:DST)
  2. Port (inbound:SRC, outbound:DST)
  3. Protocol
  • Cannot reference AWS resources (IGW, EC2, etc.)
• Processing order:
  • Rules evaluated lowest number first
  • First match → stop processing
  • Last implicit rule = * → DENY if no match
• Connection coverage:
  • Each app port + ephemeral port pair requires rules for:
    1. Within VPC (subnet-to-subnet)
    2. To VPC (inbound from outside)
    3. From VPC (outbound to outside)

NACL Types

Default NACL

• Automatically created with VPC
• Associated with all subnets by default
• Catch-all allow inbound/outbound → allows all traffic
• Recommended for beginners; AWS suggests using SGs for security

Custom NACL

• Created manually inside VPC
• Initially not associated with any subnet
• Starts with implicit DENY (*) only
  • Associating immediately → all traffic blocked
  • Requires custom rules to allow traffic

Security Groups (SGs)

VPC Security Group (SG) – Key Concepts

• Stateful firewall attached to Elastic Network Interfaces (ENIs) of AWS resources
  • Unlike NACLs, SGs are not attached to VPC subnets
  • SGs are not directly attached to AWS resources
    • When you attach an SG to an EC2 instance, it is actually attached to the ENI of the instance
    • Conceptually, an SG surrounds the ENI
• Inbound & outbound rules
  • Rules apply to traffic entering or leaving the ENI
  • Supports IP/CIDR matching like NACLs
• Stateful behavior
  • Requests allowed inbound/outbound automatically allow the corresponding responses
  • No need to manage ephemeral ports
• Enhanced features
  • Operates at Layer 5, more than Layer 4 like NACLs
  • Can reference other SGs or itself in rules
• Limitation: no explicit deny
  • Only explicit allow or implicit deny
  • Traffic not explicitly allowed is implicitly denied
  • Cannot block specific bad actors – use NACLs for that

VPC SG – Logical References

• To allow a connection to an EC2 instance, an SG rule can reference:
  1. IP of the EC2 instance
     • Not flexible if IP changes
     • Not scalable for many instances
  2. CIDR of the subnet
     • Scalable → new instances in the subnet are automatically allowed
     • Limited granularity → cannot easily exclude specific instances
  3. Security Group of the instance or its subnet
     • Very scalable → automatically applies to new instances with the SG
     • Very flexible → unaffected by IP or subnet changes
     • Maintains granularity and reduces admin overhead

SG Self-References

• SGs can reference themselves to allow traffic between all resources with that SG
  • Automatically handles IP changes
  • Useful for EC2 instances in Auto Scaling Groups
  • Simplifies intra-application communication (e.g., domain controllers or app HA)

Advanced VPC Networking

VPC Flow Logs

• Monitor traffic flow to and from ENIs within a VPC.
• Only capture packet metadata
  • Examples: source/destination IPs, ports, and anything related to the flow of data
  • Flow Logs do not capture packet contents; a packet sniffer is required for that
• Not real-time
  • Logs are delivered with a delay; best-effort capture
• Levels of attachment (captures from the specified point downwards):
  1. VPC-level → captures flow to/from all ENIs in all subnets of the VPC
  2. Subnet-level → captures flow to/from all ENIs in a specific subnet
  3. ENI-level → captures flow to/from a single ENI
• Can capture accepted, rejected, or all traffic metadata
• Log Destinations:
  1. S3
     • Can query with Athena
     • Reference: Flow Logs to S3
  2. CloudWatch Logs (CWLogs)
     • Reference: Flow Logs to CloudWatch
• Traffic excluded from Flow Logs:
  • EC2 Metadata service (http://169.254.169.254)
  • Time server requests (http://169.254.169.123) via NTP
  • DHCP requests inside the VPC
  • Communications with Amazon DNS server
  • Communications with Amazon Windows license server (for Windows EC2 instances)
• Architecture diagram:

Flow Log Records

• Each row represents the flow of a packet through an ENI
• Important fields: srcaddr, dstaddr, srcport, dstport, protocol, action
• Protocol numbers (IANA-assigned):
  • 1 → ICMP (used by ping)
  • 6 → TCP
  • 17 → UDP
• Example: ICMP ping flow log

• ICMP does not use ports, so srcport and dstport are empty
• Two rows indicate stateless filtering, likely NACLs (one row for traffic in, one for traffic out, second rejected)
• Single row would indicate stateful filtering, likely a Security Group, showing the whole connection

Egress-Only Internet Gateway (EIGW)

Differences Between IPv4 and IPv6 in AWS

• IPv4
  • Addresses can be private or public
  • Private resources cannot directly communicate with the public internet or public networks
  • Public resources have publicly routable IPv4 addresses
    • Without security filtering, public resources can access the internet and be accessed from the internet
• IPv6 (in AWS)
  • Addresses are public-only by default

Network Address Translation (NAT) for IPv4

• NAT Gateways (NATGW) and NAT instances:
  1. Allow resources with private IPv4 addresses to access public services and the internet
  2. Side effect: do not allow externally initiated connections into private resources
• NAT exists primarily to address IPv4 address space limitations
  • NAT does not work with IPv6
  • NAT’s behavior of blocking externally initiated connections applies to IPv4 only

Egress-Only Internet Gateway (EIGW)

• Provides outbound-only connections (and responses) for IPv6 resources
  • Connections can be initiated from the VPC, but external networks cannot initiate connections into the VPC
  • Only required for IPv6, not needed for IPv4
• Architecturally similar to standard IGWs:
  • Regionally resilient and highly available across all AZs used by the VPC
  • Traffic-based scaling
  • Stateful
• Route Table Configuration:
  • Default IPv6 route (::/0) should have the EIGW as the target
• Architecture diagram:
  

VPC Endpoints (VPCEs) – Gateway & Interface Types

VPC Endpoints (VPCEs)

• Allow private access to AWS services in the public zone
  • No need to provide additional infrastructure usually required to access public services
• Two types:
  1. Gateway Endpoints (GWEs) – for S3 and DynamoDB
  2. Interface Endpoints (IEs) – for other services (S3 now also supported)
• Both types are very different in architecture

VPC Gateway Endpoints (GWEs)

• VPC gateway object that provides private access to S3 and DynamoDB (DDB)
  • S3 & DDB are public services, but GWEs allow access privately
  • Only S3 and DDB are currently supported by GWEs
  • Private resources can access S3/DDB without any public-access infrastructure
• Created inside a VPC, per-service & per-region
  • GWEs are regional → cannot access cross-region services
  • Associated with one or more subnets in the VPC
  • Highly available across all AZs in the region (no need to worry about placement)
• Prefix List added to the route table of associated subnets
  • GWE is the target of the prefix list → represents S3/DDB IPs, kept up to date by AWS
  • Traffic to S3/DDB goes via GWE instead of IGW
  • No application reconfiguration required
• Endpoint policy can control what can be accessed via the GWE
  • Example: grant access only to a subset of S3 buckets
• Main use cases:
  1. Allow resources access to S3/DDB while keeping VPC private
  2. Support private S3 buckets → prevent leaky buckets
• GWEs are only accessible from the VPC where they are created

Comparison: Access to S3 With and Without GWE

Without GWE

• Public IPv4 or IPv6 resources access S3 via IGW
• Private IPv4 resources go through NATGW → public IP → S3 via IGW
• Problem: private resources accessing S3 also go through the public internet

With GWE

• GWE created in VPC, associated with subnets
• Route tables updated with prefix list pointing to GWE
• Traffic to S3 goes through GWE → no need for NATGW or IGW
• Endpoint policy can further restrict access

VPC Interface Endpoints (IEs)

• ENIs that provide private access to AWS public services
  • Similar purpose to GWEs but different architecture
  • Historically for services other than S3/DDB; S3 now also supports IEs
• Not HA by default
  • Deployed in specific subnets (single AZ)
  • To achieve HA, deploy one IE per AZ
• Network access controlled via SGs
  • Endpoint policies can further restrict access
• Supports only TCP and IPv4
• Uses AWS PrivateLink
  • PrivateLink injects external services into a VPC via ENIs
• IEs have private IPv4 addresses and use DNS
  • Provides new DNS names for accessed services
  • DNS overrides allow private access without modifying apps
• DNS types:
  1. Endpoint Regional DNS – works in any AZ
  2. Endpoint Zonal DNS – resolves to ENI in a specific AZ
  3. Endpoint Private DNS – replaces default service DNS with IE IP automatically

Comparison: Access to SNS With and Without IE

Without IE

• Private instances cannot resolve or access the service (DNS not in VPC)
• Public instances access SNS via IGW

Without IE (without private DNS)

• Private instances can access the service via regional/zonal DNS
• App modification usually required

With IE (with private DNS)

• Both public and private instances use the service’s default DNS
• DNS resolves to IE → traffic goes through IE
• No app modification needed

Comparison: Gateway Endpoints vs Interface Endpoints

Gateway Endpoint (GWE)	Interface Endpoint (IE)
Implemented as a gateway resource within the VPC	Implemented as an Elastic Network Interface (ENI) inside a subnet
Used specifically for S3 and DynamoDB services	Used for most AWS public services except DynamoDB
Supports both IPv4 and IPv6, along with TCP and UDP protocols	Supports only IPv4 and TCP
Highly available across the region by default	Requires one endpoint per Availability Zone to achieve high availability
Does not support Security Groups for controlling traffic	Supports Security Groups for network access control
Does not rely on PrivateLink	Built on AWS PrivateLink technology
Access is controlled via route tables (prefix lists added to routes)	Accessed through DNS resolution within the VPC (assigned a private IPv4 address)
No changes needed in application configuration	May require application updates depending on DNS setup (unless Private DNS is used)
Cannot be used for cross-region access to S3 or DynamoDB	Can be used to access services across different regions

DEMO: VPCEs (IE, GWE) and EIGW

PART 1: Create a VPC Interface Endpoint (IE) to use Instance Connect on a private EC2 instance

1. EC2 instance is in private subnet sn-app-A. By default, we cannot connect via Instance Connect since it has no public IP.
2. Create a VPC IE in sn-app-A via:
   • Instance Connect UI → “EC2 Instance Connect Endpoint”
   • Or directly via VPC → Endpoints
   • Option: Preserve Client IP
     • Enabled → instance sees your machine’s IP
     • Disabled → instance sees the IP of the endpoint’s ENI
3. Once the endpoint is created, Instance Connect can access the private instance.
   • If client IP is not preserved, the instance shows the endpoint ENI IP in the last login info.

PART 2: Create a VPC Gateway Endpoint (GWE) to access S3 privately

1. Private instance in sn-app-A cannot access the public internet or S3.
   • ping 1.1.1.1 fails
   • aws s3 ls shows nothing
2. Create a GWE for S3:
   • VPC → Endpoints → Create Endpoint → Type: AWS Services → filter by s3 → Gateway type
   • Select the main route tables for private subnets (sn-app-A)

3. Once the GWE is created, private instance can access S3:

• aws s3 ls lists buckets
• Example: aws s3 cp s3://<BUCKETNAME>/supersecret.txt supersecret.txt → cat supersecret.txt shows the content

4. Instance remains private: ping 1.1.1.1 still fails

PART 3: Create an Egress-only Internet Gateway (EIGW) for a private IPv6 instance

1. EC2 instance in sn-app-A has an IPv6 address but cannot reach the internet
   • ping -6 ipv6.google.com fails
2. Create an EIGW:
   • VPC → Egress-only Internet Gateway → Create → Attach to A4L-VPC
3. Update the Route Table for main subnets:

• Add default IPv6 route ::/0 → target = EIGW

4. Verify IPv6 connectivity:

• ping -6 ipv6.google.com responds

5. Optional test: confirm another EC2 instance in a different VPC cannot ping this IPv6 instance.

VPC Peering

VPC Peering – Concepts and Features

• Direct, private, and encrypted network link between two VPCs
  • A logical gateway object is created inside both VPCs, referencing the other VPC
  • One peering connection links exactly two VPCs
• Supports same-/cross-region and same-/cross-account peering
• Requirement: VPC CIDRs must not overlap
• Logical gateway objects = Peer gateway objects → routing configuration required
  • Routes with destination IPs from the other VPC point to the peer gateway object
• Optional: Public hostnames can resolve to private IPs
  • Same DNS names can be used to locate resources regardless of VPC
• Transitive peering is not supported
  • Example: VPCA peered with VPCB, VPCB peered with VPCC → VPCA cannot reach VPCC unless a peering is explicitly created
• SGs & NACLs filter traffic
  • Same-region SGs can reference peer SGs
  • Cross-region SGs require using IP addresses/ranges
• Data travels encrypted
  • Cross-region peering uses AWS global secure network
• Architecture diagram:

DEMO: Peering 3 VPCs

1. Start with three private VPCs, one EC2 instance in each.
   • Connect via Session Manager to EC2 in VPCA
2. Ping instance in VPCB → no response (private VPCs by default)
3. Create peering between VPCA and VPCB
   • VPC → Peering connections → Create → VPCA as sender, VPCB as accepter
   • Invitation model: accepter must accept the request
   • Peering remains in Pending state until accepted
4. Update Route Tables in both VPCA and VPCB
   • Add route → destination = other VPC’s CIDR → target = peering object
5. Update Security Groups
   • Add inbound rules to allow ICMP/IPv4 traffic from the other VPC’s SG
6. Ping between VPCA and VPCB instances should now succeed
7. Repeat steps 3–6 to create peering between VPCB and VPCC
8. Attempt A → C ping → fails
   • VPC peering is not transitive; a direct peering between VPCA and VPCC is required
9. Create peering between VPCA and VPCC
   • Ping from VPCA to VPCC now works

Route 53 – Global DNS

Amazon R53 (Route 53) 101

Amazon Route 53 (R53) – Key Concepts

• DNS-as-a-Service (DNSaaS) → fully managed AWS DNS product
• Global service
  • Single database replicated and accessible in all regions
  • Globally resilient
  • No need to select a region in the console
• Two main functionalities:
  1. Registered Domains – R53 as a domain registrar
  2. Hosted Zones – R53 as a DNS hosting provider
• Costs
  • Domain registration
  • Maintaining ownership
  • Hosted zones hosting and query costs

R53 Registered Domains

• Interfaces with TLD registries (.com, .io, .net, .org)
  • Example: PIR manages the .org registry

Domain registration workflow (e.g., animals4life.org):

1. Check if domain is available
2. Accept terms and purchase the domain
3. R53 creates a ZoneFile (database storing DNS info)
4. R53 allocates four AWS-managed name servers (NSs) for this domain
5. Creates a hosted zone with the ZoneFile, storing it on the four NSs
6. R53 communicates with the TLD (e.g., PIR)
   • TLD NS records point to R53’s four servers → these become authoritative

• Transfer lock enabled by default → prevents domain from leaving R53
• If a hosted zone is deleted and recreated, update the NSs in Registered Domains to the new NSs

R53 Hosted Zones

• Hosted on four AWS-managed NSs
• NSs store DNS records (RRSETs)

Network visibility types:

1. Public Hosted Zones – accessible from the internet
2. Private Hosted Zones – linked to one or more VPCs, only accessible from those VPCs

Billing:

• Monthly fee per hosted zone
• Small fee per DNS query
  • Large volume sites can increase query costs significantly

R53 Public and Private Hosted Zones

R53 Public Hosted Zone

• ZoneFile (DNS DB) hosted by four AWS-managed NSs, publicly accessible
  • Stores RRSETs for the zone
• Accessibility
  1. From the public Internet
     • Client walks the DNS tree → Root → TLD → R53 NSs
     • NS records of TLD point to R53 NSs → zone is connected to global DNS
  2. From internal VPCs
     • Via R53 Resolver
     • VPC must have DNS resolution enabled and be linked to the hosted zone
     • Direct NS access via VPC+2 address in each subnet
• External domains can use R53 public hosted zones
  • Example workflow:
    1. Register domain externally (Namecheap, GoDaddy, etc.)
    2. Create public hosted zone in R53 → AWS allocates 4 NSs
    3. Update external registrar to point domain to the 4 R53 NSs

R53 Private Hosted Zone

• Not accessible from public internet, only from associated VPCs
• VPC association
  • Can be done via console, CLI, or API
  • Can associate a VPC in a different account (CLI/API only)
• DNS resolution
  • Resources in associated VPCs use VPC+2 address (R53 resolver)
  • Non-associated VPCs cannot access the zone

Split-View (Split-Horizon) DNS

• Private + public zone with the same domain name
• Purpose:
  • Sensitive/internal records are kept in private zone
  • Public records are exposed to the Internet
  • Allows internal intranet and public website to share same domain
• Records overlap but private records remain inaccessible externally

CNAME Records vs R53 Alias Records

Limitations of CNAME Records

• Function: maps one hostname to another hostname
  • Example: www.catagram.io → catagram.io
• Limitation: cannot be used for the domain apex (naked domain)
  • Example: catagram.io → www.animals4life.org is invalid
  • This restriction exists because the DNS standard does not allow CNAME records at the apex
• Works correctly for subdomains:
  • www.catagram.io → ELB DNS name is valid
  • catagram.io → ELB DNS name is invalid
• Many AWS services (like ELB or CloudFront) provide access via DNS names rather than IP addresses, which makes apex mapping using CNAME impossible

Route 53 Alias Records

• AWS-specific record type, extending standard DNS functionality
• Function: map a hostname directly to an AWS resource
  • Functions like CNAME for subdomains
  • Supports apex/naked domains, enabling mapping such as catagram.io → ELB
• Requirements: must use Route 53 for DNS hosting
• Types of alias records include A-ALIAS, TXT-ALIAS, etc., determined by the record type returned by the AWS resource
• Can point to AWS resources including ELB, CloudFront, API Gateway, Global Accelerator, Elastic Beanstalk, and S3
• Requests for AWS resources using alias records do not incur additional DNS query charges
• Recommended best practice for all DNS records pointing to AWS resources

Key guideline:

Use CNAME for subdomains. Use Alias records for apex/naked domains or when pointing to AWS-managed services.

R53 Simple Routing Policy

Route 53 Routing Policies Overview

• Definition: rules that determine how Route 53 responds to DNS queries for a hosted domain
  • Responses can return IP addresses or AWS resources
• Routing decisions can be based on:
  • Resource health
  • Geographic location of the client
  • Testing or deployment phases
  • Load distribution or balancing
• Use cases:
  • Optimize traffic distribution
  • Reduce latency
  • Implement failover and resilience strategies
• Route 53 offers multiple routing policies to support regional and global architectures, each with different features

Route 53 Simple Routing

• Architecture: one record per hostname; each record can contain multiple values
  • Example: for hostname www, an A record can include multiple IPv4 addresses
  • Route 53 returns all values in random order; the client selects one to connect
• Use case: single service routing (e.g., one web server or load-balanced service)
• Default routing policy in Route 53
• Limitation: does not support health checks
  • No automated detection of unavailable resources
  • Other routing policies allow intelligent routing based on health status
• Pros & Cons:
  • Simple and easy to manage
  • Limited flexibility and lacks resilience features

R53 Health Checks

Route 53 Health Checks Overview

• Purpose: monitor and evaluate the health and performance of resources to support intelligent DNS routing
• Types of health checks:
  1. Endpoint health checks – assess the status of a specific endpoint (internal AWS resource or external IP/domain)
     • State: healthy or unhealthy
     • Status changes based on repeated checks
  2. Calculated health checks – aggregate results from multiple health checks to determine overall application health
  3. CloudWatch Alarm health checks – leverage CloudWatch alarms (configured separately) to reflect application or system-level health

• Integration with routing policies: health checks can influence routing decisions in advanced Route 53 policies
  • Health checks are defined independently from DNS records
• Global health checker network:

• Distributed worldwide to ensure reliable evaluation
• Default check frequency: every 30 seconds; optional 10-second interval at additional cost
• Endpoint must allow queries from health checkers to avoid false negatives
• Health considered healthy if ≥18% of checkers report healthy
• Records marked unhealthy are generally excluded from DNS responses

Endpoint Health Checks – Configuration

Basic options:

• Specify endpoint by IP address or domain name
  • If using domain name, the resolved IP may vary per health checker
• Protocol:
  • TCP: endpoint healthy if TCP connection completes successfully (10-second timeout)
  • HTTP/HTTPS: endpoint healthy if:
    1. TCP connection completes within 4 seconds
    2. Response returns HTTP 2xx/3xx within 2 seconds
  • HTTP/HTTPS checks provide higher accuracy than TCP-only checks

Advanced options:

• Failure threshold: number of consecutive successful/failed checks to change endpoint status, improving stability against intermittent failures
• String matching (HTTP/HTTPS only): endpoint considered healthy only if response body contains specified string within the first 5120 bytes
• Latency measurement: track response times from endpoint to health checker
• Maintenance mode: temporarily disable checks when performing updates or maintenance
• Regional health check control: optionally restrict health checks to specific AWS regions

Health Check Notifications

• Optional integration with CloudWatch Alarms
  • Trigger notifications via SNS or other AWS services if endpoint is unhealthy
• Health checks can still influence DNS routing independently of notifications

R53 Failover Routing Policy

Route 53 Failover Routing – Architecture

• Concept: a single DNS hostname can have primary and secondary records, each pointing to a distinct AWS resource.
• Health check dependency:
  • If the primary resource is healthy, DNS queries return the primary record
  • If the primary resource is unhealthy, queries automatically return the secondary record
• Use case: implement active-passive failover
  • Route traffic to the main resource when operational
  • Redirect to a backup resource during failures or maintenance
• Example scenario:
  • Primary: EC2 instance serving the application
  • Secondary: S3 static website acting as a maintenance or fallback page

This architecture ensures minimal downtime and transparent failover at the DNS level.

DEMO: Setting Up Route 53 Hosted Zones and Routing Policies

Part A – Implementing a Route 53 Failover Routing Policy

Step 1: Create a Health Check for the Primary Resource

1. Navigate to Route 53 → Health Checks → Create Health Check.
2. Configure an endpoint health check for your primary EC2 application:
   • Endpoint can be specified by public IP or DNS name.
   • If using IP, assign an Elastic IP to ensure a static address even if the instance restarts or experiences issues.
3. Health checks initially start in an unknown state and require some time to evaluate the endpoint before marking it healthy or unhealthy.

Step 2: Create Primary and Secondary Failover Records

Go to Route 53 → Hosted Zones → <YOUR_HOSTED_ZONE> → Create Record.

• Choose Wizard mode for guided configuration.

Configure primary failover record:

• Associate it with the health check created for the EC2 instance.

Configure secondary failover record:

• Typically points to a backup resource, such as an S3 static website.

Both records should now exist, with the primary record linked to its health check.

• Route 53 will automatically switch traffic between primary and secondary based on health check status.

Step 3: Validate Failover

1. Simulate failure by stopping the EC2 instance.
   • After a few minutes, traffic should automatically resolve to the secondary (S3) resource.
2. Restart the EC2 instance to simulate recovery.
   • After propagation, traffic should resolve back to the primary EC2 resource.

Part B – Configuring a Private Hosted Zone

• Navigate to Route 53 → Hosted Zones → Create Hosted Zone.

Create a private hosted zone:

• Can use any domain name, even if not publicly owned.
• Private DNS resolution takes precedence over public DNS within the associated VPC(s).
• Supports split-horizon DNS or split-view architectures.

Associate the hosted zone with the target VPC(s):

• Only resources within associated VPCs can resolve records in this zone.

Define DNS records as needed (e.g., A records pointing to private IPs).

Test resolution by pinging the record’s IP from an EC2 instance inside an associated VPC.

• The response should confirm successful private DNS resolution.

R53 Multivalue Answer Routing Policy

Route 53 Multivalue Answer Routing – Architecture

• Supports multiple independent records with the same host name.
  • Example: Three A records named www, each pointing to a different IP address.
  • Each record can be associated with a health check to determine availability.
• When a DNS query is made, up to 8 healthy records are returned to the client:
  • If more than 8 records are healthy, 8 are randomly selected.
  • Clients choose one record to connect to the corresponding resource.
  • Unhealthy records are never returned.
• Combines benefits of simple routing and failover routing:
  • Provides DNS-level active-active availability.
  • Suitable for architectures with multiple resources that can independently handle requests, without requiring knowledge of which specific resource serves which request.
• Improves availability and redundancy at the DNS layer.
• Important: Does not replace a load balancer.
  • Load balancers manage the actual connection and network traffic distribution beyond DNS resolution.

R53 Weighted Routing Policy

Route 53 Weighted Routing – Architecture

• Allows multiple records with the same host name to be assigned weights.
  • Example: Three www records with weights 20, 20, and 10.
  • The total weight for the host name is calculated (in this example, 20 + 20 + 10 = 50).
  • Each record is returned in DNS queries proportionally to its weight relative to the total weight:
    • First record returned 40% of the time, second record 40%, third record 20%.
  • Weight = 0 → record is never returned, unless all weights are 0, in which case all records are treated equally.
• Health checks can be associated with each record:
  • If a record selected by the weighted process is unhealthy, the selection process repeats until a healthy record is chosen.
  • Health checks do not modify the total weight calculation; the selection process is repeated but the weighting itself remains unchanged.
• Common use cases:
  • Simple DNS-level traffic distribution or load balancing.
  • Gradual rollout/testing of new software versions (e.g., sending 5% of traffic to a new version of a web server to validate behavior).

R53 Latency Routing Policy

Route 53 Latency Routing – Architecture

• Supports multiple records with the same host name, typically one per AWS region.
  • Each record is associated with the AWS region where the corresponding infrastructure resides.
  • DNS queries return the record with the lowest latency to the client.
• AWS maintains a latency database that estimates the network delay between the user’s approximate location and the regions tagged in the records.
  • User location is inferred via IP lookup.
  • AWS selects the record predicted to provide the lowest latency.
  • Important limitations:
    • The latency database is not updated in real time; it does not account for transient network issues.
    • Updates occur in the background with no guaranteed schedule.
    • Despite this, using latency-based routing generally improves global performance and user experience.
• Health checks can be associated with each record:
  • If the lowest-latency record is unhealthy, the next lowest-latency healthy record is returned instead.
• Ideal for improving performance and responsiveness of globally distributed applications.

Route 53 Geolocation-Based Routing

Route 53 Geolocation Routing – Architecture

• Supports multiple records with the same host name, each tagged with a geographical location.
  • Location hierarchy (most specific to least specific):
    1. Subdivision (state-level, only applicable in the US)
    2. Country (ISO standard country codes)
    3. Continent (ISO standard continent codes)
    4. Default (optional fallback)
• When a DNS query is received, Route 53 returns the most specific record matching the user’s location.
  • Searches in order: subdivision → country → continent → default.
  • If no match exists and no default is defined, the query receives no response.
• Example scenario:

Client location	Record returned
Houston, Texas, USA	Texas
Sacramento, California, USA	United States
Buenos Aires, Argentina	Argentina
Porto Alegre, RS, Brazil	South America
Toronto, Ontario, Canada	No Answer
Munich, Bavaria, Germany	Europe
Tokyo, Japan	No Answer
Brisbane, Queensland, Australia	No Answer

• If a default record exists, clients that would otherwise receive “No Answer” are returned the default record instead.
• Important distinction: Geolocation routing is based on user location, not proximity to endpoints.
  • Unlike geoproximity routing, distance between client and resource does not influence which record is returned.
  • Example: A client in the UK will receive the record tagged for France or Europe even if the resource is physically closer to the UK.
• Common use cases:
  • Serve content restricted to specific regions (e.g., US-only content)
  • Deliver language-specific content based on user location
  • Distribute traffic across regional endpoints according to customer location

Route 53 Geoproximity-Based Routing

Route 53 Geoproximity Routing – Architecture

• Supports multiple records with the same host name, each assigned a geographic location and optionally a bias.
  • Location assignment:
    • AWS resources: specify location via AWS region (e.g., us-east-1, ap-southeast-2)
    • External resources: specify location using coordinates (latitude + longitude)
• When a DNS query is received, Route 53 returns the record closest to the client geographically, taking bias into account.
  • Routing is distance-based, unlike geolocation routing which uses administrative location.
• Bias modifies the effective geographic coverage of a record:
  • Positive bias expands the area, negative bias shrinks it
  • Example:
    • Records exist in the UK and Australia
    • Client in Saudi Arabia queries DNS
      • Without bias → UK record returned (closer: 6,700 km vs 10,000 km)
      • Adjust biases → Saudi Arabia may fall within Australia’s routing radius, returning the Australia record
• Key advantage: flexible, distance-aware routing that can prioritize or shift traffic using bias settings.
  • Useful for optimizing user experience based on physical proximity to resources.

Route 53 Routing Policies – Overview

Policies with 1–2 records per hostname (basic routing strategies)

Route 53 Routing Policy	Design	Returned Records	Typical Use Cases
Simple	– Single DNS record per hostname, may include multiple IP values – No health monitoring configured	All record values are provided to the client in a non-deterministic order; the client selects which one to use	– Direct traffic to a single application endpoint (e.g., web server) – Straightforward and low-maintenance setup
Failover	– Two DNS records sharing the same hostname: primary and standby – Health check applied to the primary endpoint	– If the primary endpoint is healthy → return primary record – If the primary endpoint fails → return secondary record	– Active-passive disaster recovery setup – Useful for fallback scenarios like outages or maintenance pages

Policies with multiple records per hostname (advanced routing strategies)

Route 53 Routing Policy	Design	Returned Records	Typical Use Cases
Multivalue Answer	Multiple DNS records share the same hostname, all treated with equal priority	Returns up to 8 healthy records, selected randomly	Supports active-active DNS setups and enhances availability
Weighted	Each DNS record is assigned a relative weight	Healthy records are returned proportionally based on their assigned weight compared to the total	– Gradual traffic shifting (e.g., canary releases) – Basic traffic distribution across endpoints
Latency	Records are associated with different AWS Regions	Returns the healthy endpoint with the lowest network latency for the requester	Improves response times and user experience for globally distributed applications
Geolocation	Records are mapped to specific geographic locations	Returns the most precise matching record based on user location (region → country → continent → default)	– Deliver region-specific or localized content – Enforce geographic restrictions – Route users based on location
Geoproximity	Records are linked to geographic coordinates, with optional bias configuration	Returns the closest healthy endpoint to the user, factoring in any configured bias	Enables dynamic routing based on physical proximity and traffic shaping preferences

R53 Interoperability

Route 53 – Domain Registrar vs DNS Hosting Provider

• Registering a domain involves two distinct roles:
  1. Domain registrar – manages domain name ownership
  2. DNS hosting provider – manages DNS records for the domain
• Route 53 can act as both registrar and hosting provider, or just one of the two:
  • Registrar role → R53 Registered Domains
  • Hosting role → R53 Public Hosted Zone
• If only one role is handled by Route 53, a third-party provider fulfills the other role. This requires additional manual configuration, since the registrar and hosting functions are separate.
• Benefits of using Route 53 for both roles:
  • Streamlined configuration and management
  • Integrated experience with AWS services
  • But hybrid setups may exist due to legacy configurations or business requirements
• Domain registration workflow with Route 53:
  1. Customer requests a domain → Route 53 checks availability and processes payment → registrar role
  2. Route 53 allocates 4 name servers → hosting role
  3. Route 53 creates ZoneFile on the allocated NSs → hosting role
  4. Route 53 communicates NS information to the TLD registry → registrar role
     • The TLD registry sets NS records pointing to Route 53’s name servers, making them authoritative
• Key point: registrar and hosting are separate functions, even within Route 53

Route 53 – Registrar and Hosting Combined

• Route 53 handles both registrar and DNS hosting internally. From the customer perspective, this is seamless.
• Fees:
  • Registrar: registration fee + recurring domain ownership fee (annual or every 3 years)
  • Hosting: monthly fee for the public hosted zone

Route 53 – Registrar-Only Setup

• Route 53 only acts as domain registrar
• A third-party provider hosts the domain (creates the ZoneFile and manages NSs)
• External NS details must be manually configured in Route 53, which then communicates with the TLD registry
• This setup is rare and generally not recommended, as most of Route 53’s value comes from DNS hosting

Route 53 – Hosting-Only Setup

• Route 53 only acts as DNS hosting provider
• Route 53 creates a public hosted zone, allocates 4 NSs, and manages the ZoneFile
• NS details are communicated to a third-party registrar, who updates the TLD registry
• This setup is more common than registrar-only:
  • Companies may already have domains registered with other providers
  • Migrating DNS hosting to Route 53 allows leveraging AWS features without changing the registrar

Implementing DNSSEC using R53

Enabling DNSSEC in an Amazon Route 53 Public Hosted Zone

This section covers the steps to enable DNSSEC for an existing Route 53 public hosted zone.

Step 1: Configure Keys and Signing within the Zone

1. Key Signing Key (KSK)
   • KMS is used to generate an asymmetric key pair for the KSK.
   • KSK must be created in the us-east-1 region.
   • Route 53 uses the private KSK to sign the DNSKEY records, producing RRSIG records.
2. Zone Signing Key (ZSK)
   • KMS is not used; Route 53 generates and manages ZSKs internally, including automatic rotation.
3. DNSKEY Records
   • Public KSK and public ZSK are added to the zone’s DNSKEY records.
   • These records provide the cryptographic basis for DNSSEC validation.

Step 2: Establish Chain of Trust with the Parent Zone

1. Provide Public KSK to Parent
   • If Route 53 is the registrar, it can automatically send the public KSK to the TLD registry.
   • If using a third-party registrar, the public KSK must be provided manually to the registrar, who updates the parent zone.
2. Parent Zone DS Records
   • The parent zone stores a hash of the public KSK in its DS records.
   • This establishes trust from the parent zone to the child zone.

Step 3: Monitor DNSSEC Key Health

• Configure Amazon CloudWatch alarms:
  1. DNSSECInternalFailure – detects internal DNSSEC failures.
  2. DNSSECKeySigningKeysNeedingAction – indicates KSK issues or required actions.
• These alarms help ensure the zone’s DNSSEC configuration remains valid and secure.

Step 4: Optional DNSSEC Validation for VPCs

• DNSSEC validation can be enabled for VPCs to enforce trusted responses.
• Records failing validation (e.g., due to signature mismatch) will not be returned.
• Non-DNSSEC zones are unaffected by this setting.

Demonstration: Enabling DNSSEC for animals4life.org

Important: When enabling DNSSEC for a production zone, follow each step in order and allow each change to propagate before continuing. Pay attention to TTL values of domain records.

Step 1: Enable Zone Signing

1. In the Route 53 public hosted zone, enable DNSSEC.
2. Create a KSK for the zone, which generates a KMS key internally.
3. Verify configuration: dig animals4life.org DNSKEY +dnssec
   • If DNSSEC is enabled, the response includes:
     • Public ZSK (flag=256)
     • Public KSK (flag=257)
     • RRSIG for the DNSKEY record
   • If not enabled, no DNSKEY record is returned.

Step 2: Establish Chain of Trust with Parent Zone

1. Obtain the KSK information from the zone.
2. In R53 Registered Domains, under DNSSEC, click “Manage Keys” and provide the public KSK.
3. Verify chain of trust: dig org NS +short # List authoritative NSs for .org
   dig animals4life.org DS @
   • Presence of the DS record confirms the chain of trust.
   • Note: Propagation may take some time depending on TLD registry updates.

Step 3: Secure DNS Records with DNSSEC

• After the chain of trust is established, all DNS records in the zone are automatically signed.
• This ensures integrity and authenticity of DNS responses from the zone.

Global Content Delivery and Network Optimization

Amazon CloudFront (CF) 101

Latency in Global Applications

• Applications accessed by a global user base experience increased latency and slower data transfer over long distances.
• Elevated latency negatively impacts user experience and overall application performance.

Amazon CloudFront – Core Concepts

• CloudFront is a Content Delivery Network (CDN) designed to accelerate content delivery from origin sources to end users.
• It achieves this by caching content across AWS’s global network infrastructure, reducing latency and improving performance.

Key CloudFront Terminology

• Distribution
  • The primary configuration unit in CloudFront.
  • Defines how content is delivered, including associated behaviors.
• Origin
  • The source of the content.
  • Can be an Amazon S3 bucket or a custom origin (e.g., web server).
• Edge Location
  • A geographically distributed site that caches content closer to users.
  • Provides faster response times compared to fetching data from the origin.
• Regional Edge Cache
  • A larger, intermediate caching layer between edge locations and the origin.
  • Reduces direct requests to the origin and improves cache efficiency.

Key Features of CloudFront

• Integration with AWS Certificate Manager (ACM) for SSL/TLS certificate management.
• Designed for content delivery (read operations only).
  • Uploads and write operations are always handled directly by the origin.

CloudFront Architecture Overview

1. Application content is stored in an origin (e.g., an S3 bucket).
2. A CloudFront distribution is configured with the origin.
3. Content is cached at multiple edge locations worldwide.
4. Each distribution is assigned a unique domain name ending in cloudfront.net, with optional support for custom domains.
5. Regional edge caches act as an additional caching layer between edge locations and the origin.

Request Flow

• Cache Hit (Edge Location)
  • Content is served directly from the nearest edge location, resulting in low latency.
• Cache Miss (Edge Location → Regional Cache)
  • If not available at the edge, the request is forwarded to the regional edge cache.
  • If found, it is cached at the edge and returned to the user.
• Cache Miss (Regional Cache → Origin)
  • If not available in the regional cache, the request is sent to the origin.
  • The response is then cached at both regional and edge levels before being delivered.
• This hierarchical caching model reduces origin load and improves performance across all users.

CloudFront Behaviors

• A behavior is a rule-based configuration within a distribution that determines how requests are handled.
• Behaviors use path pattern matching to apply different settings to different content paths.

Behavior Characteristics

• Each distribution includes at least one default behavior (*) that applies to all requests.
• Custom behaviors override the default behavior when their path pattern matches a request.
• Example:
  • img/* → routes image requests to a specific origin or applies different caching/security rules.

Configuration Scope within Behaviors

• Cache control (TTL settings)
• Origin selection
• Access policies (public or restricted)
• Request/response handling rules
• If no custom behavior matches a request, the default behavior is applied.

CloudFront Distributions and Behaviors – Configuration Settings

CF Distribution-level Settings

• High-level configuration applied across the entire distribution
• Price class
  • Controls the set of edge locations used for content delivery
  • Trade-off:
    • Fewer edge locations → reduced cost but increased latency for distant users
    • More edge locations → higher cost but improved global performance

• Alternate domain names (CNAMEs)
  • Each distribution is assigned a default domain ending in cloudfront.net
  • Alternate domain names allow mapping to custom domains
• SSL certificates
  • Default certificate is automatically applied to the default domain
  • Custom certificates are required for alternate domain names
    • Issued via AWS Certificate Manager
    • Supports both SNI and dedicated (non-SNI) configurations

• Security policy
  • Defines supported TLS versions and cipher suites
  • Trade-off:
    • Newer policies provide stronger security
    • Older policies maintain compatibility with legacy clients

• Other settings
  • HTTP protocol versions supported
  • Logging
    • Standard logs delivered to CloudWatch
    • Real-time logs streamed to Kinesis Data Streams
  • Web Application Firewall (WAF)
    • Integrates with AWS WAF using a Web ACL
  • Default root object
    • Defines the object returned when the root path (/) is requested
    • Custom error responses (e.g., 403, 404) can also be configured

• IPv6 support
• Additional global configuration options

CF Behavior-level Settings

• Lower-level configuration applied per behavior
• A distribution can contain one or more behaviors
• Path pattern (e.g., * as the default)
  • Incoming requests are matched against defined patterns
    • Match found → corresponding behavior is applied
    • No match → default behavior is used

• Origin and origin groups
  • Defines where requests are forwarded
  • Origin groups can provide failover capabilities

• Viewer settings
  • Viewer protocol policy
    • Controls HTTP usage (e.g., allow or redirect to HTTPS)
  • Allowed HTTP methods
  • Restrict viewer access
    • Applies access control at the behavior level (independent of origin settings)
    • Enables private content delivery using signed URLs or signed cookies
    • Requires trusted key groups or trusted signers
    • Common design: mix of public and restricted behaviors within the same distribution

• Cache key and origin request settings
  • Managed via cache policies and origin request policies
  • Defines TTL values (minimum, default, maximum)
  • Controls which headers, cookies, and query strings are included in caching decisions

• Response headers policy
  • Determines which headers are included in responses
  • Can influence caching and client-side behavior

• Function associations
  • Allows integration with edge compute such as Lambda@Edge
  • Enables request and response customization at the edge

• Other settings
  • Field-level encryption
    • Encrypts sensitive data from the edge location through the CloudFront network
  • Automatic compression of supported content
  • Additional behavior-specific optimizations

CloudFront TTL and Cache Invalidations

CF Caching – Example Scenario

1. A new image is uploaded to the origin.
2. User A requests the image. Since it is not yet cached, an origin fetch occurs. The image is stored in the local cache with a defined Time-To-Live (TTL) and then returned to User A.
3. The image is later updated at the origin, but the cached copy has not yet expired (still considered valid).
4. User B requests the image. The cached version is served, even though it is now outdated.
   • This highlights a drawback of caching: cached content may become stale.
   • This situation should be minimized where possible, and CloudFront provides mechanisms to handle it.
5. The cached image eventually expires, but it is not immediately removed—only marked as stale.
6. User C requests the image. Since the cached version is expired, the request is forwarded to the origin:
   1. If the origin has a new version, it responds with 200 OK and returns the updated image. The cache is refreshed and the new version is delivered to User C.
   2. If the origin has no changes, it responds with 304 Not Modified. The cache marks the object as valid again and resets its TTL.

• Ideally, cached objects should remain in cache only as long as they remain accurate at the origin.
• In some cases, objects may be removed early due to cache space limits, which simply results in another origin fetch.

CF Time-To-Live (TTL) or Validity Period

• Represents a balance between reducing origin load and maintaining fresh content:
  • Higher cache hit rates:
    • Reduce origin requests and improve performance
    • Increase the chance of serving outdated content
• Default TTL (behavior-level):
  • Applied to all cached objects unless overridden
  • Default value is 24 hours
• Minimum TTL and Maximum TTL:
  • Define the allowed range for object-specific TTL values
• To assign custom TTLs per object, use HTTP headers:
  • Cache-Control: max-age (in seconds)
  • Cache-Control: s-maxage (in seconds)
  • Expires (specific date and time)
    • TTL is calculated based on this expiration timestamp
  • If no TTL is specified → the default TTL is used
  • If TTL falls outside allowed limits → it is adjusted to the nearest boundary (min or max)
• How headers are applied:
  • Custom origins → configured via application or web server
  • S3 origins → set through object metadata

CF Cache Invalidations

• A distribution-wide operation that forces selected cached objects to expire across all edge locations
  • Works regardless of current TTL values
  • Requires time to propagate and incurs cost
• Defined using path patterns:
  • /images/whiskers1.jpg → invalidates a single object
  • /images/whiskers* → invalidates multiple matching objects
  • /images/* → invalidates all objects in a directory
  • /* → invalidates everything in the cache
• Important note:
  • Cost is the same regardless of how many objects match the pattern
  • Best used for fixing mistakes, not routine updates
• For frequent updates, prefer versioned file names instead of invalidations

Versioned File Names

• Example: whiskers1_v1.jpg, whiskers1_v2.jpg, whiskers1_v3.jpg
• Benefits:
  • Ensures users always receive the latest version
  • Avoids reliance on cache invalidation → more cost-efficient
  • Improves tracking and logging (each version is uniquely identifiable)
  • Enables smooth transitions across edge locations since all versions coexist
• Important distinction:
  • These are treated as separate files, not versions of the same object
  • Updating a file with the same name changes its internal version, but CloudFront always serves the latest version available

SSL/TLS Certificate Management (AWS Certificate Manager)

HTTPS Refresher

• HTTP (Hypertext Transfer Protocol) was originally designed without security:
  • No verification of server identity, no authentication, and no encryption
  • This allowed attackers to spoof websites or intercept traffic to read sensitive information
• HTTPS (HTTP Secure) solves these security issues:
  • Uses SSL/TLS protocols to create an encrypted tunnel for HTTP traffic
  • Server authentication through SSL/TLS certificates makes it harder to impersonate a site
    • Certificates are signed by a trusted certificate authority (CA) → forms a chain of trust
    • Ensures that the DNS name and certificate are correctly linked

AWS Certificate Manager (ACM) – Overview

• ACM manages SSL/TLS certificates, including creation, deployment, and renewal
  • Supports public or private CAs:
    • Public CA → trusted by browsers; certificates automatically trusted due to the chain of trust
    • Private CA → requires client configuration to trust certificates
• Certificates can be generated in ACM or imported:
  • Generated certificates → automatically renew, avoiding expiration issues
  • Imported certificates → customer must manage renewal manually
• Certificates can be deployed to supported AWS services, primarily:
  • CloudFront distributions and Application Load Balancers (ALBs)
  • EC2 does not integrate directly with ACM
    • Certificates would need to be manually installed on EC2, exposing them to root-level access
• ACM is region-specific:
  • Certificates must reside in the same region as the service they are used with
    • Example: To use a cert with an ALB in ap-southeast-2, the certificate must also be in ap-southeast-2
  • Exception: CloudFront
    • Since CloudFront is a global service, ACM certificates must be in us-east-1 to associate with a distribution

CloudFront and SSL/TLS Management

SSL in CloudFront

• Every CloudFront distribution comes with a default domain name (CNAME), for example: d111111abcdef8.cloudfront.net.
  • CloudFront automatically provides a default SSL certificate (*.cloudfront.net) covering all distributions using the default domain.
  • Using this default name ensures HTTPS works out-of-the-box.
• Alternate domain names (CNAMEs) let you use your own custom domains for a distribution:
  • Example: cdn.catagram.io pointing to a CloudFront distribution via your DNS provider (like Route 53).
  • An SSL certificate matching the custom domain is required:
    • Enables HTTPS
    • Verifies domain ownership even if HTTPS isn’t enforced
  • Certificates can be generated or imported using ACM:
    • Region must be us-east-1 since CloudFront is a global service.
• HTTPS handling is configured at the behavior level:
  • HTTP and HTTPS allowed: both protocols work
  • Redirect HTTP → HTTPS: forces secure connections
  • HTTPS only: HTTP requests fail
• Two separate SSL connections exist:
  1. Viewer connection → between the client and CloudFront edge
  2. Origin connection → between CloudFront edge and the origin
  • Both require publicly trusted certificates (including intermediate certs)
  • Self-signed certificates are not allowed

Server Name Indication (SNI)

• One server can host multiple domain names on the same IP address:
  • Example: catagram.io and doggogram.io on the same server/IP
  • Browsers normally indicate the desired site via HTTP host headers (OSI Layer 7)
  • SSL/TLS encryption starts at TCP layer (Layer 4), so host headers aren’t available yet
    • Historically, each SSL-enabled site required its own IP address
• SNI solves this problem:
  • TLS extension allowing the client to indicate the desired domain name during the handshake
  • Server can then present the correct certificate before HTTP traffic begins
  • Introduced in 2003, enabling multiple HTTPS sites on one IP

SNI in CloudFront

• SNI is the default and free in CloudFront
• Older browsers (pre-2003) do not support SNI:
  • To support them, CloudFront must assign dedicated IP addresses at edge locations
  • Extra cost: $600/month per distribution for dedicated IPs

SSL & SNI Architecture in CloudFront

• Publicly trusted certificates are mandatory for both viewers and origins:
  • Issued by major CAs (Comodo, DigiCert, Symantec, or ACM)
  • Self-signed certificates are not allowed
• Certificate handling depends on origin type:
  • S3 origin → SSL handled automatically
  • ALB origin → ACM certificate must be applied (generated or imported)
  • Custom origin (EC2, on-premises) → SSL must be applied manually (ACM not supported)
• Viewer certificates must match the domain clients use to access CloudFront
• Origin certificates must match the DNS name CloudFront uses to contact the origin

CloudFront – Origin Types and Architecture

CloudFront Origins and Origin Groups

• Origins are the sources where CloudFront retrieves content to serve via edge locations.
  • When a requested object is not cached or stale, CloudFront performs an origin fetch.
• Origin groups allow multiple origins to be linked for resiliency:
  • If the primary origin is unavailable, CloudFront can failover to a secondary origin.
• Origin settings are defined at the behavior level.

Types of Origins

1. S3 Origins
   • Amazon S3 buckets
   • AWS MediaPackage endpoints
   • AWS MediaStore container endpoints
2. Custom Origins
   • Any web server (on EC2, on-prem, or elsewhere)

Features and restrictions differ between S3 origins and custom origins.

• Static S3 websites can act as either S3 or custom origins:
  • Specified with S3 bucket → treated as S3 origin
  • Specified with the DNS name of the static website endpoint → treated as custom origin

Common features for all origins:

• Origin domain → points directly to the origin (S3 bucket or DNS name)
• Origin path → optional path inside the origin, e.g., /img to access images

CloudFront – S3 Origins

• Easiest to configure, minimal setup required.

Features:

• Origin access → restrict direct access to the S3 bucket so it can only be accessed via CloudFront:
  • Origin Access Control (OAC) → recommended
  • Origin Access Identity (OAI) → legacy option
• Custom headers → headers passed to the origin
• Origin protocol policy → must match viewer protocol policy
  • All HTTP or all HTTPS, no mixing

CloudFront – Custom Origins

• Allow more granular configuration than S3 origins.

Features:

• Origin protocol policy → HTTP-only, HTTPS-only, or match viewer protocol
• Custom ports → configurable for HTTP and HTTPS (default 80/443)
  • S3 origins do not allow port changes
• Minimum origin SSL protocol → best practice: use the latest supported version for maximum security
  • Reference: Supported SSL/TLS protocols & ciphers
• Custom headers → can be used to secure access for custom origins (OAC/OAI not available for custom origins)

CloudFront – S3 Origins vs Custom Origins (Comparison Overview)

S3 Origins	Custom Origins
Amazon S3 buckets, MediaPackage channel endpoints, or MediaStore container endpoints	Backend web servers (e.g., EC2, on-premises, or external services)
Minimal setup required, easy to configure	Offers more advanced and flexible configuration options
Supports secure access using Origin Access Control (OAC) or legacy Origin Access Identity (OAI)	Security typically implemented using custom headers or other mechanisms
Origin protocol policy is always aligned with the viewer protocol	Origin protocol policy can be explicitly set (HTTP only, HTTPS only, or match viewer protocol)
Uses standard HTTP/HTTPS ports by default	Supports both standard and non-standard (custom) ports
No requirement to define a minimum SSL/TLS version for origin communication	Requires specifying the minimum SSL/TLS protocol version for origin connections

Securing CloudFront Origins

CloudFront Content Delivery Path

• Three main zones in content delivery:
  1. Origins – where content is hosted (S3 buckets, custom servers, etc.)
  2. CloudFront network – includes the edge locations and AWS global network
  3. Public internet & end users – consumers of content
• Two paths to secure:
  1. Origin fetch path (Origin → CloudFront)
     • Best practice: restrict origin access so it is only reachable via CloudFront
     • By default, origins can be bypassed if not properly secured
  2. Viewer path (CloudFront → end user)
     • Best practice: protect sensitive content in private behaviors using signed URLs or signed cookies
     • By default, behaviors are public

Securing S3 Origins

Origin Access Control (OAC) – Recommended

• OAC is the modern approach to restrict CloudFront access to S3 origins.
• Bucket policy must be adjusted to allow only requests from the OAC:
  • Typically: deny all by default, explicitly allow CloudFront principal with condition enforcing the OAC
• CloudFront automatically signs all requests to the S3 origin when using OAC

Origin Access Identity (OAI) – Legacy

• AWS recommends OAC over OAI for production environments, but OAIs are still supported.
• OAI is a special CloudFront identity linked to a distribution (not an IAM user/role).
• Bucket policy uses OAIs to grant access:
  • Deny all by default, explicitly allow specific OAI(s)
• When CloudFront accesses an S3 origin, it assumes the associated OAI, determining access.
• Best practice: one OAI per distribution (sharing possible but less common).

• Edge locations access the bucket via OAI
• Direct access to the bucket without OAI → denied

Securing Custom Origins

• OAC and OAI cannot be used for custom origins.
• Steps to secure a custom origin:
  1. Enforce HTTPS on both origin and viewer protocol policies to encrypt traffic
  2. Additional methods to restrict access:
     • Custom headers:
       • Configure the origin to require a specific HTTP header for requests
       • Configure CloudFront to inject the header in origin requests
       • Requests missing the header are denied
       • HTTPS ensures headers cannot be intercepted or spoofed
     • Firewall / NACL restrictions:
       • Protect the origin with a firewall
       • Allow only CloudFront IP ranges (publicly available by AWS)
  • Can use either method individually or combine both for stronger security

LAB: Integrating a CDN with an S3 Static Website

Part 1: Create & Deploy a CloudFront Distribution with S3 Origin

1. Deploy the provided CloudFormation stack

• Creates an S3 bucket with static website hosting
• Problems solved by CloudFront:
  • Poor performance outside the bucket region
  • High request load on the origin (no caching)
  • No HTTPS support (S3 static websites only deliver HTTP)

2. Create a CloudFront distribution

• Set Origin Domain Name to the created S3 bucket → becomes an S3 origin
• If you use the S3 static website endpoint (DNS name), CloudFront treats it as a custom origin

3. Default settings for demo purposes

• Viewer protocol policy: allow HTTP/HTTPS
• Cache policy: CachingOptimized works fine for demo (default TTLs)

4. Set the root default object

• Set index.html as default object → returned when accessing root URL /

5. Deploy distribution

• Deployment can take several minutes

Part 2: Test the CloudFront Distribution

1. Find your default CloudFront domain
   • Ends in cloudfront.net
2. Open distribution in browser
   • Refresh a few times → pages load quickly (good performance)
   • Caching occurs both at the browser and CloudFront edge location
3. Modify an object in S3
   • Example: overwrite merlin.jpg (can use a new image, but keep same name)
   • Verify via S3 static website endpoint that the latest version exists
4. Check CloudFront caching behavior
   • Refresh CF distribution in browser → old image may still appear
   • Browser cache deletion does not bypass edge cache
   • 💡 Updated content is only visible after:
     • Cache TTL expires
     • Or you perform a CloudFront cache invalidation (incurs cost)
5. Strategies for frequently updated content
   • Reduce object TTL in CloudFront
   • Use versioned object names (merlin_v1.jpg, merlin_v2.jpg)
     • Guarantees latest object served
     • Avoids cache invalidation costs
   • Perform cache invalidation sparingly (costly, generally for error fixes)

6. HTTPS support

• CloudFront supports HTTPS out of the box
• S3 static website endpoint only supports HTTP (forcing HTTPS fails)
• Screenshot: view default SSL certificate used by CF in browser

Part 3: Add Alternate CNAME & SSL

1. Requirement: custom domain hosted in Route53
   • Alternatively, follow the demo with placeholder domain
2. Add alternate domain name (CNAME) in CloudFront distribution

3. Request SSL certificate in ACM

• Certificate must match the alternate name

• Verify domain ownership via DNS validation (easy with Route53)

4. Select ACM certificate in CF distribution

• Save and deploy distribution (deployment may take a few minutes)

5. Create Route53 record

• Simple routing, alias A/AAAA record pointing to CF distribution
• Record name must match alternate name

6. Test custom domain

• Opens CloudFront distribution over HTTPS

Part 4: Secure the S3 Origin with Origin Access Control (OAC)

1. Problem: Public S3 bucket
   • By default, the S3 bucket is completely public, allowing all principals.
   • Direct access via S3 static website endpoint bypasses CloudFront, which is not secure.
2. Configure Origin Access Control (OAC)
   • In CloudFront distribution, change Origin Access from Public → Origin access control settings
   • Create an OAC with default configuration → CF signs all requests to the S3 origin
   • Copy the generated policy; it will be used in the S3 bucket policy

3. Update S3 bucket policy

• Paste the policy copied from OAC
• Only allows requests from CloudFront with the specified OAC
• Result: Only this CF distribution can access the bucket

4. Test direct S3 access

• Opening the website via the S3 endpoint → 403 Forbidden
• CF distribution still delivers content normally

5. Deploy distribution changes

• Save and deploy CloudFront distribution
• Once deployed, website is only accessible through CF, securing the origin

6. Clean up

• Tear down demo infrastructure to avoid unwanted charges

CloudFront – Private Distributions and Behaviors

CloudFront – Private Behaviors

• Content accessibility in CloudFront
  • Public: any viewer can access the content freely
  • Private: access is restricted; requests must present a valid signed URL or signed cookie
• Privacy is configured per behavior
  • A single CloudFront distribution can have multiple behaviors, each designated as public or private
  • Combining public and private behaviors allows controlled redirection of unauthorized access from a private behavior to a public one (for example, during authentication flows)
• Signer: the entity authorized to generate signed URLs or cookies
  • Assigning a signer to a behavior makes it private, enforcing the requirement for signed access
• CF Key (Legacy method)
  • Linked to an AWS account root user; only the root user can create the key
  • Once created, this account can act as a trusted signer for a behavior
  • Exam tip: the term “trusted signer” is associated with private CloudFront behaviors
• Trusted Key Group (Modern method)
  • Defines the public keys allowed to generate signed URLs or cookies
  • Does not require root user access
  • Can be managed programmatically via the CloudFront API
  • Supports multiple public keys per behavior, offering more flexibility than legacy CF keys

Signed URL

• Grants access to a single object only
• Suitable for clients that cannot handle cookies
• Historically used for RTMP distributions, but RTMP is now deprecated; this is no longer a relevant limitation

Signed Cookie

• Grants access to multiple objects or entire groups of objects
• Preferred when maintaining consistent URLs across an application is important
• Useful for securing all files under a given path, e.g., /catgifs/

Example Architecture: Serverless Mobile App with Mixed Behaviors

• Backend components: API Gateway (entry point), Lambda (compute), S3 (media storage)
  • Mobile app uses identity federation for login via social media
• Public behavior: handles general, non-sensitive requests
• Private behavior: secures access to sensitive content (e.g., images under catgifs/)

Request flow:

1. App requests a resource from CloudFront (public behavior via API Gateway)
2. When a sensitive image is requested, the Lambda signer validates access
3. If access is authorized, Lambda generates a signed cookie (using Trusted Key Groups)
4. Signed cookie and access information are returned to the app
5. App requests the protected object, sending the signed cookie
6. CloudFront validates the cookie, fetches the content from the S3 origin, and serves it to the app

CF – Lambda@Edge

CloudFront – Lambda@Edge

• Run lightweight Lambda functions at CloudFront edge locations
  • Can manipulate requests and responses between viewers and origins
  • Since they execute at edge locations, they have a limited feature set compared to standard Lambda functions
• Limitations:
  • Supports only Node.js and Python runtime environments
  • Cannot access VPC resources (runs in AWS public space)
  • Lambda Layers are not supported
  • Smaller memory, execution time, and package size limits than regular Lambda functions
• Common use cases:
  • A/B testing (viewer request Lambda)
    • Serve two variations of content (e.g., web pages or images) to different viewers without changing URLs or redirects
  • Migration between S3 origins (origin request Lambda)
    • Gradually route traffic from an old S3 bucket to a new one
  • Content optimization by device (origin request Lambda)
    • Serve higher resolution images to high-DPI devices
  • Content personalization by location (origin request Lambda)
    • Adjust content based on user country or language
• Additional examples and code samples: AWS Lambda@Edge Examples

Lambda@Edge Architecture

• Lambda@Edge functions can be triggered at different points in the CloudFront request/response flow:
  • Viewer Request: runs after CF receives a request from a viewer, before forwarding to origin
  • Origin Request / Response / Viewer Response: functions can execute at other stages to modify requests/responses
• Key point:
  • Size, memory, and execution limits are stricter than standard Lambda, so Lambda@Edge is best suited for lightweight operations such as routing, header modifications, or content personalization

AWS Global Accelerator

Performance Challenges in Single-Region Deployments

• Deploying infrastructure in a single AWS region gives low-latency access for local users, but users in other regions may experience slower performance and degraded user experience.
• Latency increases with distance to the infrastructure due to:
  • More network hops over the public internet
  • Increased variability and risk of packet loss or failures
• Note: The public internet prioritizes distributed, resilient routing over speed, which contributes to delays for distant users.

AWS Global Accelerator – Core Concepts

• Optimizes traffic from users to AWS resources by leveraging AWS global network:
  • Users connect via Anycast IPs at edge locations
  • Traffic is routed over the AWS Global Network, which is faster and more reliable than the public internet
• Works at network layer (L4) – supports TCP and UDP traffic, not specific to HTTP(S)
• Anycast IPs:
  • Shared across multiple edge locations
  • Internet routes user traffic to the closest edge location advertising that IP
• Example:
  • IP 1.2.3.4 may be advertised from London and Sydney edge locations
  • London user hits London edge; Australia user hits Sydney edge, same IP for both users
• Supports single-region or multi-region destinations, improving global performance and failover
• Global Accelerator Flow

CloudFront vs Global Accelerator

• CloudFront:
  • Caches HTTP(S) content at edge locations
  • Optimized for web applications and content delivery
  • Cannot handle non-HTTP(S) traffic
• Global Accelerator:
  • Network (L4) service that routes traffic over the AWS global network
  • No caching or content manipulation
  • Works for any TCP/UDP-based application, including gaming, IoT, and APIs