This chapter covers two foundational AWS networking services: Amazon CloudFront, a global content delivery network (CDN), and Amazon Route 53, a scalable domain name system (DNS) web service. Both are critical for building fast, secure, and highly available applications on AWS. For the CLF-C02 exam, this topic falls under Domain 3: Cloud Technology Services, Objective 3.4, which tests your understanding of how these services enable global content delivery and DNS routing. While the exact percentage varies, Domain 3 typically accounts for about 24% of the exam, and this objective is a key component. Mastering CloudFront and Route 53 is essential for any cloud practitioner because they directly impact user experience, security, and reliability of cloud applications.
Jump to a section
Imagine you run a chain of high-end bakeries in New York City that ships custom cakes nationwide. Your main kitchen is in Manhattan, but customers in Los Angeles want your cakes. If every order had to be baked in Manhattan and shipped overnight, the cake would arrive stale, and shipping costs would be high. Instead, you partner with a global express delivery service that pre-positions pre-baked cake layers in freezer warehouses in Los Angeles, Chicago, and Dallas. When a customer in LA orders a cake, the delivery service immediately assembles and finishes the cake at the nearest warehouse using locally stored layers, then delivers it fresh within hours. This service also automatically routes orders away from any warehouse that is under repair or overloaded. In this analogy, your Manhattan kitchen is the origin server (e.g., an EC2 instance or S3 bucket). The express delivery service is Amazon CloudFront, a content delivery network (CDN) that caches copies of your content at edge locations worldwide. The freezer warehouses are CloudFront edge locations and regional edge caches. When a user requests a file, CloudFront automatically serves it from the nearest edge location if cached, reducing latency and load on the origin. Just as the delivery service can route around a closed warehouse, CloudFront can failover to another origin if the primary is unhealthy. You pay only for the data transfer and requests, similar to paying per delivery. This mechanism is not just about speed—it also provides security with AWS Shield and AWS WAF integration, and can restrict access using signed URLs or cookies, like requiring a signature for delivery.
What is Amazon CloudFront and the Problem It Solves
Amazon CloudFront is a fast content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency and high transfer speeds. The core problem CloudFront solves is the latency and origin load caused by serving content from a single geographic location. Without a CDN, every user request must travel across the internet to the origin server (e.g., an Amazon S3 bucket, an EC2 instance, or an on-premises web server). This round trip can be hundreds of milliseconds, especially for users far from the origin. Additionally, a sudden spike in traffic (e.g., a viral video) can overwhelm the origin. CloudFront mitigates this by caching content at edge locations—a global network of data centers that are closer to users. When a user requests content, CloudFront routes the request to the nearest edge location, serving cached content if available, thus reducing latency and offloading the origin.
How CloudFront Works: The Mechanism
CloudFront operates on a pull-through caching model. Here's the step-by-step mechanism:
Distribution Creation: You create a CloudFront distribution, which is the unit of configuration. You specify one or more origins (e.g., an S3 bucket, an HTTP server) and default cache behavior settings (e.g., TTL, allowed HTTP methods).
Edge Location Request: When a user requests a file (e.g., https://d111111abcdef8.cloudfront.net/image.jpg), the DNS resolves the CloudFront domain to the IP of an edge location that is closest to the user (lowest latency).
Cache Hit or Miss: The edge location checks its cache for the requested file. If the file is cached and not expired, it serves it directly (cache hit). If not (cache miss), the edge location forwards the request to the origin.
Origin Fetch and Caching: The origin responds with the file, and the edge location caches it according to the TTL (Time to Live) you set in the cache behavior. Subsequent requests for the same file are served from the edge cache until TTL expires.
Regional Edge Cache: For objects that are less popular but still requested, CloudFront uses regional edge caches to reduce the load on the origin. These are larger caches located in AWS regions that sit between the edge locations and the origin. If an edge location misses, it checks the regional edge cache before going to the origin.
Key Features and Configurations
Origin: Can be an S3 bucket (with Origin Access Control for security), an Elastic Load Balancer, an EC2 instance, or an on-premises HTTP server. You can set up multiple origins and route different paths to different origins.
Cache Behaviors: You can configure multiple cache behaviors based on URL path pattern. Each behavior has its own TTL, allowed HTTP methods, and origin. For example, /images/* might have a longer TTL than /api/*.
Price Class: CloudFront offers three price classes: Price Class All (all edge locations), Price Class 200 (most locations, excluding the most expensive ones), and Price Class 100 (only North America and Europe). Choosing a lower price class reduces cost but may increase latency for users in excluded regions.
Security: CloudFront integrates with AWS WAF (Web Application Firewall) to block malicious requests, AWS Shield for DDoS protection, and supports field-level encryption. You can also restrict access using signed URLs or signed cookies for premium content.
Custom SSL/TLS: You can use your own SSL certificate via AWS Certificate Manager (ACM) or upload one. CloudFront supports both dedicated IP and SNI (Server Name Indication) custom SSL.
Lambda@Edge: You can run Lambda functions at edge locations to modify requests and responses (e.g., rewrite URLs, add headers, A/B testing).
Origin Failover: You can set up an origin group with a primary and secondary origin. If the primary returns an error (e.g., HTTP 5xx), CloudFront automatically fails over to the secondary.
Pricing Model
CloudFront pricing is based on: - Data Transfer Out: Charged per GB, varying by region. The first 1 TB per month is free for the first year (for new AWS accounts). - HTTP/HTTPS Requests: Charged per 10,000 requests, with a higher rate for HTTPS. - Regional Edge Cache: No additional charge; it's included.
What is Amazon Route 53 and the Problem It Solves
Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service. The problem it solves is translating human-readable domain names (e.g., www.example.com) into IP addresses (e.g., 192.0.2.1). It also provides domain registration and health checking. Route 53 is designed to be reliable and fast, with a global network of DNS servers. It offers several routing policies to optimize traffic flow, such as latency-based routing, geolocation routing, and weighted routing. Route 53 also integrates with other AWS services like CloudFront and ELB to route traffic to healthy endpoints.
How Route 53 Works: The Mechanism
When a user types a domain name into a browser, the following happens:
DNS Query: The browser sends a DNS query to a recursive resolver (usually provided by the ISP).
Name Server Lookup: The resolver queries the root DNS servers, which direct it to the TLD (top-level domain) servers (e.g., .com). The TLD servers then direct it to the authoritative name servers for the domain, which are Route 53 name servers.
Route 53 Response: Route 53 looks up the record for the domain (e.g., A record for IPv4) and returns the IP address to the resolver, which then returns it to the browser.
Connection: The browser then connects to that IP address.
Key Features and Record Types
- Record Types: A (IPv4), AAAA (IPv6), CNAME (canonical name), MX (mail exchange), TXT (text), NS (name server), SOA (start of authority), and alias records. Alias records are unique to Route 53 and allow you to route traffic to AWS resources like CloudFront distributions, ELBs, and S3 buckets (configured for static website hosting) without being charged for DNS queries. - Routing Policies: - Simple: Routes traffic to a single resource (e.g., one web server). - Weighted: Distributes traffic across multiple resources based on assigned weights (e.g., 80% to version A, 20% to version B). - Latency: Routes traffic to the resource with the lowest latency for the user. - Failover: Routes traffic to a primary resource; if health check fails, routes to a secondary. - Geolocation: Routes traffic based on the geographic location of the user (e.g., route users in Europe to a European endpoint). - Geoproximity: Routes traffic based on geographic location and allows you to shift traffic between resources using a bias value. - Multivalue Answer: Returns up to 8 healthy records in response to a DNS query, allowing client-side load balancing. - Health Checks: Route 53 can monitor the health of endpoints (e.g., HTTP/S, TCP) and automatically reroute traffic away from unhealthy ones. Health checks can be associated with failover routing policies. - Domain Registration: You can register new domains or transfer existing ones to Route 53. It supports most TLDs. - DNSSEC: Route 53 supports DNS Security Extensions (DNSSEC) to protect against DNS spoofing.
Pricing
Route 53 pricing is based on: - Hosted Zones: Monthly charge per hosted zone (e.g., $0.50 per hosted zone for the first 25 zones). - DNS Queries: Charged per million queries (e.g., $0.40 per million queries for standard queries). Alias records to AWS resources are free. - Health Checks: Charged per health check per month (e.g., $0.50 per health check). - Domain Registration: Varies by TLD (e.g., .com is about $12 per year).
Comparison to On-Premises or Competing Approaches
Before CloudFront, organizations had to set up their own CDN infrastructure or use third-party CDNs like Akamai or Cloudflare. CloudFront's advantage is deep integration with other AWS services (e.g., S3, EC2, Lambda@Edge, WAF) and pay-as-you-go pricing. For DNS, on-premises solutions require managing authoritative name servers, which can be complex and less reliable. Route 53 offers a fully managed, global DNS service with a 100% SLA for DNS queries (when using with health checks). Competitors like GoDaddy DNS or Cloudflare DNS are alternatives, but Route 53's tight integration with AWS resources and advanced routing policies make it the preferred choice for AWS-centric architectures.
Create a CloudFront Distribution
To start using CloudFront, you create a distribution. In the AWS Management Console, navigate to CloudFront and click 'Create Distribution'. Choose a delivery method: Web (for HTTP/HTTPS) or RTMP (for Adobe Flash streaming, deprecated). For web distributions, you define the origin: select an S3 bucket, or enter an HTTP server domain. You can also configure origin path, origin ID, and enable Origin Shield (a managed cache layer that reduces load on the origin). Next, set default cache behavior: allowed HTTP methods (GET, HEAD, etc.), cache policy (e.g., CachingOptimized), and TTL values (minimum, default, maximum). You can also attach a WAF web ACL. Finally, choose price class, SSL certificate, and default root object (e.g., index.html). Click 'Create Distribution'. AWS then provisions the distribution with a domain name like d111111abcdef8.cloudfront.net. Behind the scenes, AWS propagates configuration to all edge locations, which takes about 5-10 minutes.
Configure Cache Behaviors and TTL
After creating a distribution, you can add multiple cache behaviors to handle different URL patterns. For example, you might want `/images/*` to have a long TTL (e.g., 1 year) because images rarely change, while `/api/*` has a short TTL (e.g., 0 seconds) to ensure real-time data. To add a cache behavior, go to the distribution's 'Behaviors' tab and click 'Create Behavior'. Specify the path pattern (e.g., `/images/*`), then choose an origin (or keep default). Set the cache policy: you can use a managed policy like 'CachingOptimized' (cache based on URL query strings and headers) or create a custom policy. For TTL, you set Minimum TTL, Maximum TTL, and Default TTL. CloudFront uses these to determine how long to cache objects. If you set all to 0, CloudFront will not cache at all (but still forward requests to origin). You can also enable 'Compress Objects Automatically' for gzip/brotli compression. Remember that cache behaviors are evaluated in order; the first match wins, so order them from most specific to least specific.
Set Up Route 53 as DNS with CloudFront
To use your own domain name (e.g., www.example.com) with CloudFront, you need Route 53. First, register the domain or transfer it to Route 53. Then, create a hosted zone for the domain. In the hosted zone, create an alias record (A or AAAA) that points to your CloudFront distribution. Choose 'Alias' to 'Yes', then select the CloudFront distribution from the dropdown. Alias records are free and automatically handle changes if the distribution's IP addresses change. Alternatively, you could use a CNAME record, but CNAMEs cannot be used for the root domain (e.g., example.com) without a workaround. Alias records work for both root and subdomains. Route 53 will then respond to DNS queries with the CloudFront distribution's IP addresses. This integrates with CloudFront's edge locations because CloudFront provides a set of IP addresses that Route 53 returns based on the user's location.
Implement Security with Signed URLs and WAF
To restrict access to content delivered via CloudFront, you can use signed URLs or signed cookies. This is common for premium content like paywalled videos. First, create a CloudFront key pair (only the root AWS account can do this). Then, using the private key, you generate signed URLs with an expiration time. The URL includes a signature that CloudFront validates. Alternatively, for multiple files, you can set signed cookies. To enforce, in the distribution's behavior settings, set 'Restrict Viewer Access' to 'Yes' and choose 'Trusted Key Groups' (or 'Trusted Signers' for older method). You also need to create a key group and add the public key. Additionally, you can associate a WAF web ACL to block common attacks (e.g., SQL injection, cross-site scripting) and geo-block requests from specific countries. WAF integration is done at the distribution level. This layered security helps protect both the edge and the origin.
Monitor and Troubleshoot with Metrics and Logs
CloudFront integrates with CloudWatch to provide metrics like total requests, error rates (4xx, 5xx), and data transfer. You can set alarms. For deeper analysis, enable access logs: specify an S3 bucket to store logs that contain details like timestamp, edge location, client IP, URI, and response status. Route 53 also provides DNS query logs via CloudWatch Logs (if enabled). To troubleshoot a cache miss, check the `X-Cache` header in the response: `Hit from cloudfront` or `Miss from cloudfront`. If you see `Miss`, the object was not cached. Common reasons: TTL expired, query string varies (if not forwarded), or the object was evicted due to low popularity. You can also use CloudFront's 'Real-time Logs' feature to stream logs to a Kinesis Data Stream for near real-time analysis. For Route 53 health checks, you can view health check status in the console and configure CloudWatch alarms to notify you of failures.
Scenario 1: Global E-commerce Website
A large e-commerce company hosts its product images, CSS, and JavaScript on an S3 bucket and serves the web application from EC2 instances behind an Application Load Balancer. To improve load times for users worldwide, they place CloudFront in front of both the S3 bucket and the ALB. They create a CloudFront distribution with two origins: one S3 bucket for static assets and one ALB for dynamic API calls. They configure cache behaviors so that /static/* has a TTL of 1 day and /api/* has TTL of 0 (no caching). They use Route 53 with latency-based routing to direct users to the nearest CloudFront edge location. Additionally, they enable CloudFront's Origin Shield to further reduce load on the ALB. This setup reduces page load times from 3 seconds to under 500 milliseconds for users in Asia. Cost considerations: data transfer out from CloudFront is slightly higher than from EC2 direct, but the reduced origin load and better user experience justify it. Misconfiguration: originally, they forgot to enable 'Query String Forwarding' for the API behavior, causing all API requests to be cached incorrectly, leading to stale data. They fixed it by setting the cache policy to forward all query strings.
Scenario 2: Video Streaming Platform
A media company streams live events and on-demand videos to a global audience. They use CloudFront with AWS Media Services (e.g., MediaLive, MediaPackage). For on-demand content stored in S3, they use signed URLs to restrict access to paying subscribers. They create a CloudFront distribution with an S3 origin and enable 'Restrict Viewer Access' with a trusted key group. They generate signed URLs programmatically when a user logs in. For live streaming, they use MediaPackage as the origin, which outputs HLS and DASH formats. CloudFront caches the segments, reducing load on MediaPackage. They also use Route 53 with geolocation routing to direct users to the closest regional MediaPackage endpoint for live origin ingestion. Cost: data transfer out for video is high, so they use Price Class 200 to avoid the most expensive edge locations. Misconfiguration: they initially set TTL too high for live segments, causing viewers to see delayed content. They corrected by setting TTL to 2 seconds for live content.
Scenario 3: SaaS Application with Blue/Green Deployments
A SaaS company uses Route 53 weighted routing to perform blue/green deployments. They have two environments: blue (current production) and green (new version). Both are behind an Application Load Balancer. They create two Route 53 records with the same name but different set identifiers, each pointing to the respective ALB. They set weights: blue=100, green=0 initially. To test the new version, they change weights to blue=90, green=10, routing 10% of traffic to green. They monitor error rates and performance. Once confident, they shift to green=100. They also use Route 53 health checks to automatically failover if the primary ALB is unhealthy. This approach minimizes downtime. Misconfiguration: they forgot to update DNS TTL to a low value (e.g., 60 seconds) before changing weights, so some users experienced stale routing for hours. They learned to lower TTL before deployments.
Exactly What CLF-C02 Tests on This Objective
Domain 3: Cloud Technology Services, Objective 3.4: 'Identify the services that enable global content delivery and DNS routing.' The exam expects you to understand the purpose and basic features of Amazon CloudFront and Amazon Route 53. You need to know:
CloudFront is a CDN that caches content at edge locations for low latency.
Route 53 is a DNS service that translates domain names to IP addresses and offers routing policies.
Common use cases: speeding up static content, serving dynamic content, DNS resolution, failover routing.
Integration points: CloudFront can use S3, EC2, ELB as origins; Route 53 can route to CloudFront, ELB, S3.
Key concepts: edge locations, origins, cache behaviors, TTL, routing policies (simple, weighted, latency, failover, geolocation).
Security features: signed URLs, signed cookies, AWS WAF integration, Origin Access Control (OAC).
Common Wrong Answers and Why Candidates Choose Them
Choosing 'CloudFront is used for DNS routing' – Candidates confuse CloudFront with Route 53 because both are global. CloudFront is a CDN, not a DNS service. Route 53 handles DNS.
Selecting 'Route 53 provides content caching at edge locations' – This is the reverse confusion. Route 53 is DNS only; it does not cache content. CloudFront caches.
Picking 'CloudFront can only serve static content' – CloudFront can serve both static and dynamic content. It can cache dynamic content with appropriate TTL or forward requests to origin without caching.
Believing 'Route 53 health checks are only for failover routing' – Health checks can be used with failover routing, but also with latency, weighted, and multivalue routing. They are not exclusive to failover.
Thinking 'CloudFront distributions can only have one origin' – A distribution can have multiple origins, each associated with different cache behaviors.
Specific Terms That Appear Verbatim
Edge location, origin, cache behavior, TTL, distribution, signed URL, signed cookie, Origin Access Control (OAC), Origin Access Identity (OAI) – OAI is older, OAC is newer.
Route 53: hosted zone, record set, alias record, routing policy (simple, weighted, latency, failover, geolocation, geoproximity, multivalue answer), health check.
Price classes: Price Class All, Price Class 200, Price Class 100.
Lambda@Edge, AWS WAF, AWS Shield.
Tricky Distinctions
CloudFront vs. S3 Transfer Acceleration: Both speed up transfers, but CloudFront is a CDN for serving content to many users, while S3 Transfer Acceleration speeds up uploads to S3 only.
Route 53 Alias vs. CNAME: Alias records can point to AWS resources (CloudFront, ELB, S3) and work for root domains; CNAMEs cannot be used for root domains and are charged differently. Alias records are free.
CloudFront vs. Global Accelerator: Global Accelerator uses edge locations to improve TCP/UDP performance for non-HTTP protocols, while CloudFront is for HTTP/HTTPS content delivery.
Decision Rule for Multiple Choice
If the question involves 'low latency', 'caching', 'content delivery', 'static assets', 'video streaming', or 'edge locations', answer CloudFront. If it involves 'domain name', 'DNS resolution', 'routing traffic', 'health checks', 'failover', or 'domain registration', answer Route 53. If both are mentioned together, look for integration scenario (e.g., Route 53 routes to CloudFront). Eliminate options that mix up the two services.
Amazon CloudFront is a global CDN that caches content at edge locations to reduce latency and offload origin servers.
Amazon Route 53 is a scalable DNS service that translates domain names to IP addresses and offers multiple routing policies.
CloudFront supports multiple origins (S3, EC2, ELB, custom) and cache behaviors with configurable TTL.
Route 53 alias records can point to AWS resources (CloudFront, ELB, S3) and are free; CNAME records cannot be used for root domains.
CloudFront integrates with AWS WAF for web security and supports signed URLs/cookies for access control.
Route 53 routing policies include simple, weighted, latency, failover, geolocation, geoproximity, and multivalue answer.
Both services are global and fully managed; they are often used together for high-performance web applications.
For the CLF-C02 exam, know the key differences between CloudFront (CDN) and Route 53 (DNS) and their common use cases.
These come up on the exam all the time. Here's how to tell them apart.
Amazon CloudFront
Content delivery network (CDN) that caches content at edge locations
Delivers HTTP/HTTPS content with low latency
Supports static and dynamic content, video streaming, APIs
Integrates with AWS WAF, Shield, Lambda@Edge
Pricing based on data transfer out and request count
Amazon Route 53
Domain Name System (DNS) service that resolves domain names to IPs
Routes traffic based on routing policies (latency, geolocation, weighted, failover)
Provides domain registration and health checks
Supports alias records for AWS resources (free)
Pricing based on hosted zones, queries, and health checks
CloudFront with S3 Origin
Global edge caching reduces latency for users worldwide
Offloads requests from S3, reducing S3 costs for data transfer
Supports custom SSL, WAF integration, signed URLs
Can handle dynamic content by forwarding to other origins
Additional cost for CloudFront data transfer out
S3 Static Website Hosting with Direct Access
Content served directly from S3 bucket (regional)
Higher latency for users far from the S3 region
Limited security features (bucket policies, IAM)
Only static content (no dynamic processing)
Lower cost if traffic is low and regional
Mistake
CloudFront caches content on the origin server.
Correct
CloudFront caches content at edge locations, which are separate from the origin. The origin is the source server (e.g., S3, EC2) where the original content lives. CloudFront edge locations are distributed globally and cache copies of objects to serve users faster.
Mistake
Route 53 can cache web content to improve latency.
Correct
Route 53 is a DNS service only; it does not cache web content. It resolves domain names to IP addresses. Content caching is done by CloudFront. Route 53 can route users to the nearest endpoint via latency-based routing, but it does not store or serve content.
Mistake
You must use Route 53 to use CloudFront.
Correct
CloudFront can be used without Route 53. You can use any DNS provider to point your domain to the CloudFront distribution's domain name (e.g., using a CNAME). Route 53 is recommended because of alias records and tight integration, but it is not required.
Mistake
CloudFront only works with S3 as an origin.
Correct
CloudFront can use any HTTP/HTTPS server as an origin, including EC2 instances, Elastic Load Balancers, on-premises servers, and even other cloud providers' servers. S3 is a common origin, but not the only one.
Mistake
Route 53 routing policies are mutually exclusive.
Correct
Routing policies can be combined. For example, you can use latency-based routing with health checks to ensure traffic goes to healthy endpoints. You can also use weighted routing with failover by creating separate records with different set identifiers.
CloudFront is a content delivery network (CDN) that caches content (like images, videos, web pages) at edge locations around the world to deliver it to users with low latency. Route 53 is a Domain Name System (DNS) service that translates domain names (like www.example.com) into IP addresses. While CloudFront speeds up content delivery by serving from edge caches, Route 53 handles DNS queries and can route traffic based on latency, geography, or health. They are often used together: Route 53 can point your domain to a CloudFront distribution, and CloudFront serves the content. For the exam, remember: CloudFront = CDN, Route 53 = DNS.
Yes, CloudFront can serve dynamic content. You can configure cache behaviors to forward requests to the origin without caching (TTL=0) or with caching based on headers, cookies, or query strings. CloudFront also supports Lambda@Edge, which allows you to run code at edge locations to modify requests and responses (e.g., personalize content, A/B testing). So CloudFront is not limited to static content; it can handle APIs, dynamic web pages, and more. For the exam, know that CloudFront can serve both static and dynamic content.
An alias record is a Route 53-specific record type that maps a domain name to an AWS resource (e.g., CloudFront distribution, ELB, S3 bucket configured for static website hosting). Unlike a CNAME record, an alias record can be used for the root domain (e.g., example.com) and is free of charge. Alias records automatically respond with the IP addresses of the underlying resource, and if the resource's IP changes, Route 53 updates the alias record automatically. For the exam, remember that alias records are a key feature of Route 53 and are commonly tested.
You can secure CloudFront content in several ways: (1) Use Origin Access Control (OAC) to restrict access to your S3 bucket so only CloudFront can access it. (2) Use signed URLs or signed cookies to restrict access to individual users (e.g., for premium content). (3) Integrate with AWS WAF to block malicious requests. (4) Use AWS Shield for DDoS protection. (5) Configure custom SSL/TLS certificates for encrypted connections. For the exam, know that signed URLs and signed cookies are used for access control, and OAC is the recommended way to secure S3 origins.
Route 53 supports the following routing policies: Simple (routes to a single resource), Weighted (distributes traffic based on weights), Latency (routes to the resource with lowest latency), Failover (routes to primary, fails over to secondary if health check fails), Geolocation (routes based on user location), Geoproximity (routes based on location with bias), and Multivalue Answer (returns up to 8 healthy records). For the exam, you should be able to identify which policy to use in a given scenario. For example, use failover for disaster recovery, latency for performance, weighted for A/B testing.
CloudFront is a CDN optimized for HTTP/HTTPS content delivery, with caching at edge locations. Global Accelerator is a networking service that improves performance for TCP/UDP traffic (including HTTP) by using edge locations to route traffic to the nearest AWS region, but it does not cache content. Global Accelerator provides static IP addresses and can handle non-HTTP protocols. For the exam, if the question involves caching and content delivery, choose CloudFront. If it involves improving latency for any TCP/UDP application with static IPs, choose Global Accelerator.
CloudFront pricing is based on three main factors: (1) Data Transfer Out: you pay per GB of data served from edge locations to users. Rates vary by geographic region (e.g., US/Europe is cheaper than South America). (2) HTTP/HTTPS Requests: you pay per 10,000 requests, with HTTPS costing more than HTTP. (3) Price Class: you can choose which edge locations to use. Price Class All includes all locations; Price Class 200 excludes the most expensive ones; Price Class 100 includes only US and Europe. Additionally, there are charges for Lambda@Edge and Origin Shield if used. For the exam, know that CloudFront has a free tier (1 TB data transfer and 10 million requests per month for the first 12 months).
You've just covered Amazon CloudFront and Route 53 — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?