AWS CDN, DNS & Edge

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