The SOA-C02 exam objective 1.2 asks you to configure Amazon CloudFront, AWS Global Accelerator, and advanced VPC features. For the SysOps Administrator, this is the skill that makes your company's web application fast and reliable for users in Tokyo, London, and São Paulo simultaneously, without building servers in every city. Mastering this chapter means you understand how to deliver content at lightspeed, protect your origin server from being overwhelmed, and give your users a consistently snappy experience — which is exactly what the exam wants you to prove you can do.
Jump to a section
A simple way to picture Advanced Networking and Content Delivery with CloudFront
A city food truck festival organiser. Their job is to get hungry customers to the right trucks as quickly as possible, no matter where each customer is in the city or how many thousands show up at once. Without the organiser, each customer would have to walk to every single truck to see what menu is available, causing massive queues and slow service. The organiser sets up a central 'menu board' at the entrance of the festival grounds. This board shows the latest menu of every truck, so customers decide where to go before walking. If a truck runs out of ingredients and updates its menu, the board updates instantly, so nobody walks to a truck that can't serve them. But the board isn't enough when the city grows and customers are scattered across different neighbourhoods. The organiser now places smaller, local menu boards in each neighbourhood, pre-loaded with the most popular items. When a customer in a distant suburb wants a specific dish, they access their local board instead of walking all the way to the festival. If one local board breaks, the organiser routes the customer to the next closest board. The organiser also gives VIP customers (those paying for premium access) a dedicated express lane that bypasses the main queue entirely. This festival organiser mirrors exactly what Amazon CloudFront does for websites and applications: it caches content at 'edge locations' (the neighbourhood boards), routes users to the nearest healthy server, protects against sudden crowds, and gives premium users faster routing through AWS Global Accelerator.
This analogy captures Advanced Networking and Content Delivery with CloudFront because it shows caching, geographic distribution, health checks (broken board = broken server), and the performance boost of Global Accelerator. Every element maps directly: the menu board is the CloudFront cache, the neighbourhood boards are edge locations, the broken board is an unhealthy origin server, the VIP lane is Global Accelerator's static IP routing, and the sudden crowds are traffic spikes that CloudFront absorbs without crashing the main website.
Let us start with the basic problem that CloudFront solves. Imagine you host a website on a server in Virginia, USA. A user in Australia tries to load a picture on your site. That picture data has to travel across an undersea cable, through multiple internet routers, and all the way from Virginia to Sydney. This journey takes time — often over 200 milliseconds. Now multiply that by every image, script, and video on your page. The total delay makes your site feel sluggish. This problem is called 'latency' (the time it takes for data to travel from one point to another). Latency is the enemy of user experience.
CloudFront is a Content Delivery Network (CDN). A CDN is a network of servers placed in data centres all over the world. These data centres are called 'edge locations'. There are over 600 edge locations globally. When you use CloudFront, you store copies of your website's static files (images, CSS, JavaScript files, videos) at these edge locations. When a user in Sydney visits your site, CloudFront automatically serves the content from the nearest edge location — perhaps one in Sydney or Singapore — instead of fetching it from Virginia. This reduces latency from 200 milliseconds to maybe 10 milliseconds. The user gets a much faster experience.
But CloudFront does not just cache content. It also protects your origin server. The origin server is the main server where your website lives (it could be an Amazon EC2 instance, an S3 bucket, or an on-premises server). If millions of users hit your origin server simultaneously, it could crash under the load — this is called a 'traffic spike' or a 'flash crowd'. CloudFront absorbs this traffic because most requests are served from edge locations, not the origin. Only requests for uncached content — or dynamic content that cannot be cached — get forwarded to your origin. This is called 'origin offload'.
Now we move to AWS Global Accelerator, a separate service often studied alongside CloudFront. Global Accelerator solves a different problem: improving the performance of applications that rely on real-time communication — like a multiplayer game, a video conferencing app, or a banking API — where caching is not possible because the data changes every second. Global Accelerator gives you two static IP addresses (fixed addresses that never change) that serve as the entry point for all traffic. These IPs are announced globally across the AWS edge network. When a user connects to one of these IPs, their traffic enters the AWS network at the nearest edge location, then travels over AWS's private, high-speed backbone to the nearest healthy application endpoint (for example, an EC2 instance or an Application Load Balancer). This avoids the slow, congested public internet for most of the journey, reducing latency and jitter (variability in delay). Global Accelerator also provides health checks. If your primary application endpoint in Virginia fails, it automatically routes traffic to a healthy endpoint in Oregon without changing the user's IP address — so no reconnection is needed.
How does CloudFront work in detail? You create a 'distribution', which is the configuration object that tells CloudFront where your origin server is, what behaviour rules apply, and how to cache content. A distribution has a domain name like 'd123.cloudfront.net'. You point your website (e.g., www.example.com) to this distribution via a DNS record. When a user visits your site, their browser sends a request to the CloudFront domain. CloudFront routes the request to the nearest edge location. At the edge, CloudFront checks its cache. If the requested file is cached and not expired, it returns the cached copy immediately — this is a 'cache hit'. If the file is not cached or has expired, it is a 'cache miss', and CloudFront fetches the file from the origin, caches it at the edge, and returns it to the user.
Cache expiration is controlled by 'TTL' (Time To Live), which you set in seconds. A TTL of 3600 means the cached copy is considered fresh for one hour. After that, the edge location will re-fetch the file from the origin on the next request. You can also 'invalidate' cached files manually — for example, if you update an image and want the new version to appear immediately everywhere.
CloudFront integrates with custom origins. Custom origins include any HTTP/HTTPS server: an EC2 instance, an on-premises server, or even a non-AWS server. For security, you can create an 'origin access identity' (OAI) — a virtual user identity — that allows CloudFront to access your S3 bucket without making the bucket public. This is a best-practice for securing S3 content.
Global Accelerator works differently. You create an 'accelerator', assign it to one or more 'listeners' (typically port 80 for HTTP and port 443 for HTTPS), and then you associate it with 'endpoint groups' (which are AWS regions). Inside each endpoint group, you list your endpoints (Application Load Balancers, Network Load Balancers, EC2 instances, or Elastic IPs). Global Accelerator then monitors the health of these endpoints using health checks. Traffic is routed to the healthy endpoint nearest the user. Because the traffic stays on the AWS backbone, performance is more consistent. Global Accelerator also provides 'client IP preservation' — the user's IP address is visible to your backend servers, which is important for logging and security audits.
Why does this matter for the SysOps Administrator? You are the one who will troubleshoot slow site performance, configure caching rules, set up SSL/TLS certificates for CloudFront, manage invalidations, and ensure your Global Accelerator endpoints are healthy. The SOA-C02 exam will test your ability to choose between CloudFront and Global Accelerator based on the scenario, to configure caching behaviours, to secure content with OAI, and to integrate with Web Application Firewall (WAF) and AWS Shield for DDoS protection.
Create a CloudFront Distribution
Log in to the AWS Management Console, navigate to CloudFront, and click 'Create Distribution'. Choose either Web (for HTTP/HTTPS) or RTMP (for streaming, now deprecated). For the web distribution, you will specify the origin — this is the source of your content. It could be an S3 bucket, an EC2 instance, an Application Load Balancer, or an external server. You also set the origin domain name, which is the DNS name of your origin. This step defines where CloudFront will fetch content when there is a cache miss.
Configure Cache Behaviour Settings
After creating the distribution, you define cache behaviours for different URL path patterns. For example, you can set path pattern '/images/*' to cache for 7 days, and path pattern '/api/*' to cache for 0 seconds. You also configure whether to forward query strings, cookies, or headers. Forwarding query strings can reduce cache effectiveness because each unique query string creates a separate cached object. Best practise: only forward what is necessary to serve the correct content.
Set Up Origin Access Identity (OAI) for S3
If your origin is an S3 bucket, you should create an OAI — a special CloudFront user identity. After creating the OAI, you update the S3 bucket policy to grant read access only to that OAI. This ensures that users cannot bypass CloudFront and access the S3 bucket directly, which would break your security model and possibly incur extra costs. This step is critical for securing content.
Attach SSL/TLS Certificate and Configure Custom Domain
CloudFront provides a default domain name (like d123.cloudfront.net), but you will want to use your own domain (like www.example.com). To do this, you request or import a custom SSL certificate from AWS Certificate Manager (ACM) in the US East (N. Virginia) region. Then, in the CloudFront distribution settings, you select that certificate and specify the CNAME (your custom domain). Finally, you update your DNS provider to point your domain to the CloudFront distribution, typically using an Alias A record in Route 53.
Create a Global Accelerator and Add Endpoints
For non-cacheable, real-time workloads, create a Global Accelerator. In the console, name your accelerator, and configure a listener (e.g., TCP port 443). Then add endpoint groups — these are AWS regions where your application runs. Inside each group, add your endpoints (e.g., a Network Load Balancer or EC2 instance). You can set traffic dials (e.g., 100% for primary region, 0% for secondary unless failover). Global Accelerator will automatically perform health checks and route traffic to healthy endpoints. This step is done when caching is not beneficial.
Test and Monitor Performance
After deployment, use tools like CloudFront reports in the console, Amazon CloudWatch metrics (e.g., cache hit ratio, latency, error rates), and third-party performance tests to verify that your configuration is working. If cache hit ratio is low, adjust TTLs or review cache key settings. For Global Accelerator, check endpoint health and traffic distribution. Monitoring is essential to catch issues like a misconfigured origin that causes all traffic to miss cache.
You work as a SysOps Administrator for a global e-commerce company called ShopFast. ShopFast sells electronics and ships worldwide. Your website has a catalogue with thousands of product images, a checkout page that processes credit card payments, and real-time inventory data that updates every 30 seconds. The company is growing fast, and users in Asia and Europe are complaining that pages take 8 seconds to load, while users in the US get pages in 1 second.
Your first task is to identify the problem. The website runs on an EC2 instance in the US East (Virginia) region. Every image, style sheet, and script is loaded directly from that single server. Users in India wait for data to cross 15,000 km. You decide to implement CloudFront.
Here is what you actually do step by step:
Create a CloudFront distribution with the EC2 instance's domain name as the custom origin.
Configure cache behaviour settings: for images and static files (file extensions .jpg, .png, .css, .js), set a TTL of 7 days (604800 seconds). For the checkout page (dynamic content), set a TTL of 0 seconds so that CloudFront always checks the origin for fresh data.
Create an Origin Access Identity (OAI) for any S3 buckets that store product images, ensuring the bucket is only accessible via CloudFront.
Attach an AWS WAF web ACL to the CloudFront distribution to block common attacks like SQL injection and cross-site scripting.
Update the DNS for www.shopfast.com to point to the CloudFront distribution domain name.
After deployment, you monitor CloudFront metrics. Cache hit ratio should be above 90% for static content. If it is lower, you might adjust TTLs or check that your cache key (the way CloudFront identifies unique objects) is not too granular — for example, if every user gets a unique URL due to session IDs in query strings, CloudFront will not cache effectively.
Now your company launches a live flash sale. Thousands of users rush to the site simultaneously. Without CloudFront, the EC2 instance would likely crash. With CloudFront, the edge locations absorb over 95% of the traffic. Your origin server handles only the checkout requests and inventory updates.
Next, the company launches a mobile banking app (ServeFast) that needs real-time balance updates and low latency for users worldwide. Caching is not possible because balances must be current within milliseconds. You deploy Global Accelerator. - Create an accelerator with a listener on TCP port 443. - Add two endpoint groups: one in US East (Virginia) and one in EU West (Ireland). Each group points to a Network Load Balancer (NLB) that distributes traffic across multiple EC2 instances running the app. - Global Accelerator health checks every 10 seconds. If the Virginia endpoint fails, all traffic automatically shifts to Ireland within seconds — users experience a brief pause but no connection failure.
The result: app users in India connect to the Mumbai edge location, their traffic travels over AWS's private network to Ireland, and latency drops from 350ms to 80ms.
As a SysOps Administrator, you also need to:
Set up CloudFront access logs and store them in S3 for analysis.
Configure custom SSL/TLS certificates using AWS Certificate Manager (ACM) so that CloudFront serves HTTPS.
Plan for scheduled maintenance: you can create a custom error page in CloudFront to show a 'We'll be back soon' message when the origin is down.
Use CloudFront real-time logs to debug if a particular region is experiencing high error rates.
The SOA-C02 exam will test your knowledge of Amazon CloudFront, AWS Global Accelerator, and their integration with other AWS services. You must understand when to use each service and how to configure them correctly. The exam questions are scenario-based: they describe a business requirement (reduce latency, protect origin, serve static content), and you must pick the right solution.
Here are the specific concepts the exam loves:
CloudFront origins: You will be asked whether to use an S3 bucket, an Application Load Balancer, an EC2 instance, or an on-premises HTTP server as the origin. Trap: they might specify that the S3 bucket needs to be publicly accessible — but the correct answer is to use an Origin Access Identity (OAI) to keep the bucket private. Another trap: they might suggest using a Lambda@Edge function when a simpler cache invalidation would suffice.
Cache behaviours and TTLs: Questions will test if you know how to configure different TTLs for different URL patterns. For example, /images/* gets a long TTL, /api/* gets a short or zero TTL. Trap: they might set TTL to 0 for static assets, which would defeat the purpose of a CDN. Correct approach: maximise TTL for static content.
CloudFront security: You must know how to restrict access to content using signed URLs or signed cookies (for premium content), how to integrate AWS WAF, and how to use geo-restriction (allow or block countries). Trap: they might confuse signed URLs with OAI — remember, OAI is for restricting S3 bucket access to CloudFront only, while signed URLs control who can access individual files.
Global Accelerator vs CloudFront: This is the most asked distinction. The exam will present a scenario: 'An application has dynamic real-time content that cannot be cached. Users worldwide need low latency.' The correct answer is Global Accelerator, not CloudFront. Trap: they might offer CloudFront with a 0-second TTL — technically possible, but it would not improve latency as much as Global Accelerator's AWS backbone routing. Global Accelerator also provides fixed IP addresses, which is critical for applications that require IP whitelisting (e.g., banking APIs).
Health checks and failover: Global Accelerator performs health checks on endpoints. If an endpoint fails, traffic is routed to the next healthy endpoint. Trap: they might suggest using Route 53 health checks with failover routing as the primary solution — but Global Accelerator provides faster failover (within seconds) and does not rely on DNS caching which can cause delays.
Integration with AWS Shield: CloudFront and Global Accelerator both include AWS Shield Standard (free, protects against layer 3/4 DDoS attacks). For premium DDoS protection, you add AWS Shield Advanced (costs extra). Trap: they might claim Shield Advanced is automatically enabled — it is not; you must purchase it.
Pricing and cost: CloudFront charges by data transfer out to the internet, and by request count. Global Accelerator charges by hourly usage and data transfer. The exam will not ask for exact prices, but may ask about the most cost-effective solution for a given traffic pattern.
Common question patterns:
'A company wants to serve static content from S3 with the lowest possible latency and high security. What should they do?' Answer: Use CloudFront with an OAI and S3 bucket configured for OAI access.
'A gaming company needs low-latency UDP traffic for its multiplayer game.' Answer: Global Accelerator supports UDP traffic; CloudFront only supports HTTP/HTTPS.
'A SysOps admin needs to block traffic from a specific country.' Answer: Use CloudFront geo-restriction (allow list or block list).
Remember: CloudFront is a CDN (caching), Global Accelerator is a networking accelerator (non-caching). Both use the AWS global edge network. Both can be integrated with WAF and Shield. Both support HTTP/HTTPS, but only Global Accelerator supports TCP and UDP.
CloudFront is a CDN that caches content at edge locations to reduce latency and offload traffic from your origin server.
Global Accelerator improves latency for non-cacheable, real-time traffic by routing it over the AWS global backbone instead of the public internet.
Always use an Origin Access Identity (OAI) to keep your S3 bucket private when fronting it with CloudFront.
Set a high TTL (e.g., 7 days) for static content and a very low TTL (0) for dynamic content in CloudFront cache behaviours.
Global Accelerator provides two static IPv4 addresses that never change, making it ideal for applications that require IP whitelisting.
Global Accelerator supports TCP and UDP protocols; CloudFront supports only HTTP and HTTPS.
You can restrict access to CloudFront content by country using geo-restriction, or by user using signed URLs or signed cookies.
Both CloudFront and Global Accelerator include AWS Shield Standard for free DDoS protection; add Shield Advanced for enhanced protection.
CloudFront can serve custom error pages (e.g., maintenance mode) when the origin is unavailable.
AWS WAF can be attached directly to a CloudFront distribution or a Global Accelerator endpoint group to filter malicious traffic.
These come up on the exam all the time. Here's how to tell them apart.
CloudFront
Designed to cache content at edge locations
Supports only HTTP and HTTPS protocols
Provides domain name (e.g., d123.cloudfront.net) — no static IPs
Global Accelerator
Does not cache content; optimises network path
Supports TCP and UDP protocols
Provides two static IPv4 addresses that never change
Cache Hit
Requested content is found in CloudFront edge cache
Content is served directly from edge without contacting origin
Results in lower latency and reduced origin load
Cache Miss
Requested content is not in edge cache or has expired
CloudFront fetches content from the origin server
Results in higher latency and origin load until the content is cached
Signed URL
Controls access to individual files by generating time-limited URLs
Used to restrict access to premium content, such as paywalled videos
Works at the user level — each user gets a unique signed URL
Origin Access Identity (OAI)
Controls access to an entire S3 bucket from CloudFront
Used to keep the S3 bucket private while allowing CloudFront to fetch content
Works at the service level — all CloudFront requests are authenticated via the OAI
CloudFront Geo-Restriction
Native CloudFront feature that blocks or allows entire countries at the edge
Simple to set up — just select countries from a list
Does not allow fine-grained control like IP addresses within a country
AWS WAF Geo Match
A rule in AWS WAF web ACL that can block or allow geographic regions
Can be combined with other WAF rules (e.g., rate limiting)
More flexible — allows exceptions for specific IPs even if the country is blocked
Mistake
CloudFront and Global Accelerator are basically the same service; you can use either for caching.
Correct
CloudFront is a Content Delivery Network that caches content at edge locations. Global Accelerator does not cache content; it optimises the network path for non-cacheable, real-time traffic like APIs and gaming.
The names sound similar and both improve performance using the AWS edge network. Beginners assume they are interchangeable without understanding the caching distinction.
Mistake
If I set a TTL of 0 seconds on CloudFront, the content will never be cached, so it is useless.
Correct
TTL of 0 is used for dynamic content that must always be fresh. CloudFront still provides benefits like SSL termination, DDoS protection, and origin offload (by handling the connection to the user), even with TTL=0.
Beginners think caching is the only feature of a CDN. They overlook the additional security and connection management benefits.
Mistake
CloudFront automatically makes my S3 bucket secure without any configuration.
Correct
CloudFront does not automatically make your S3 bucket private. You must configure an Origin Access Identity (OAI) and update the bucket policy to allow only CloudFront access. Otherwise, the bucket remains publicly readable.
Amazon markets CloudFront as a secure delivery service, so beginners assume security is default. They miss the critical step of configuring OAI, which can lead to a data leak.
Mistake
Global Accelerator can serve static website content faster than CloudFront because it uses the AWS backbone.
Correct
For static content with caching, CloudFront is faster and more cost-effective because it serves from cache at the edge, avoiding any origin fetch. Global Accelerator always routes to the origin, so static content would still be served from the origin server, which is slower.
The concept of the AWS backbone is appealing; beginners think it is always faster. They do not realise that caching at the edge eliminates the round trip to the origin entirely.
Mistake
I can use CloudFront to improve latency for a real-time multiplayer game because it uses edge locations.
Correct
CloudFront is for HTTP/HTTPS traffic only and is designed for caching. Real-time games often use UDP or TCP protocols for low-latency communication. Global Accelerator supports both UDP and TCP and optimises the network path without caching, making it the correct choice.
Beginners hear 'edge locations = fast' and assume it applies universally. They do not check protocol support or caching suitability.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
CloudFront is a CDN that caches static and dynamic content at edge locations to reduce load on your origin and speed up delivery. Global Accelerator optimises the network path for non-cacheable traffic (like APIs and real-time communication) by routing it over the AWS global backbone, providing low latency and fixed IP addresses.
Yes, if you want to serve content over HTTPS (which you should for security). You can use a default CloudFront certificate (*.cloudfront.net) for the default domain, but for your own custom domain, you must attach a custom SSL certificate from AWS Certificate Manager (ACM) in the US East (N. Virginia) region.
Yes, CloudFront includes AWS Shield Standard at no extra cost, which protects against common layer 3 and layer 4 DDoS attacks. For more advanced protection, you can add AWS Shield Advanced, which costs extra and provides real-time visibility and cost protection against scaling attacks.
An OAI is a special CloudFront user that you can create to restrict access to an S3 bucket. When you configure your S3 bucket policy to allow only the OAI, users can only access the content through CloudFront, not directly via the S3 URL. Use it whenever you front an S3 bucket with CloudFront to keep your bucket private.
You can create a cache invalidation request in the CloudFront console, specifying the paths you want to invalidate (e.g., /images/*). This tells CloudFront to remove those files from edge caches so that the next request fetches the fresh version from the origin. Invalidations cost extra, so use them sparingly or version your filenames instead.
Yes, you can use a custom origin that points to your on-premises HTTP/HTTPS server. You just need to make sure that server is accessible over the internet and that you configure the appropriate security groups and firewalls to allow CloudFront's IP addresses to reach it.
Yes, you can use both together. For example, you could serve static content via CloudFront (cached), and use Global Accelerator in front of your dynamic API endpoints (non-cached). They complement each other but are not mutually exclusive.
You've just covered Advanced Networking and Content Delivery with CloudFront — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?