Episode 14: Content Delivery & Global Apps - CloudFront, Caching Strategies & Latency Optimization | SAA-C03

Hey everyone, Balu here. Welcome back to Tech Talk with Balu. Your complete guide to asing the AWS Solutions Architect Associate exam. We're on episode 14 today and we're going to tackle a topic that's all about making your applications fast for users no matter where they are in the world. We are covering content delivery and global apps, specifically Amazon Cloud Front, caching strategies and latency optimization. Let me explain why this matters with a simple scenario. Imagine you've built a beautiful web application and your servers are sitting in the US East region in Virginia. A user in Tokyo opens your website. Every single image, every CSS file, every API call has to travel from Tokyo all the way across the Pacific Ocean to Virginia and then back. Each trip takes hundreds of milliseconds. The user clicks something, waits, clicks again, waits, the experience is slow and frustrating. Now, here's the magic. What if we could store copies of your content at hundreds of locations around the world, including one right there in Tokyo? When that user requests an image, it comes from the Tokyo location, just a few milliseconds away, instead of crossing the ocean. That's exactly what a content delivery network does. And AWS Cloud Front is one of the best sedients in the world. Today, we're going to deep dive into how Cloud Front works, the different types of origins it can pull from, how caching actually behaves, how to secure your content, how to invalidate the cache when things change, and will compare Cloud Front to global actuator, since the exam loves to test the difference between these two services. We'll also touch on Edge computing with Cloud Front functions and Lambda at Edge. By the end of this episode, you will understand how to design globally distributed low latency applications on AWS, and you'll be ready for Cloud Front questions that show up consistently in the exam. So let's dive straight in. So before we dive into Cloud Front specifically, let's understand what a content delivery network is, and why it transforms application performance. The fundamental problem is the speed of light. As fast as light is, it still takes time to travel. A network packet going from London to Sydney has to physically travel that distance and along the way bounces through dozens of routers and network hops. Each hop adds latency. By the time the packet arrives, you might have spent 300 to 400 milliseconds just on the roundtrip. Now multiply that by every image on your page, every API call your application makes, and every video chunk it streams, the user experience degrades dramatically. Acedion solves this by caching copies of your content at locations close to users. AWS has hundreds of these locations distributed around the globe. They are called points of presence or edge locations. When a user requests something, the request goes to a nearest edge location, not your origin server. If the content is already cached there, the user gets it just in a few milliseconds. If it is not cached yet, the edge location fetches it from your origin and caches it locally and returns it to the user. The next user in the same region gets it instantly from the cache. But CDNs do more than just speed things up. CloudFront also provides DDoS protection. Because the traffic hits hundreds of edge locations distributed worldwide, an attacker can't easily overwhelm any single point. CloudFront integrates with AWS shield for DDoS protection and with AWS web application firewall or WAF for short for protection against application layer attacks like SQL injection or cross-site scripting. So you get a performance boost and the security boost at the same time. There's also a cost benefit here. When content is served from the edge cache, your origin server doesn't have to handle that request at all. If you have a million users downloading the same video, your origin might only serve it a handful of times, once to each edge location that needs to cache it. The rest of the deliveries come from the cache. This dramatically reduces the load on your origin and reduces your data transfer costs. For the exam, remember the core value proposition here. CloudFront is a CDN. It improves read performance by caching contents at hundreds of edge locations globally. It provides DDoS protection and integrates with shield and WAF and it reduces load on your origin. Now let's talk about origins. The origin is where your actual content lives, the source that CloudFront pulls from when it doesn't have something cached. CloudFront supports three types of origins and understanding the differences matter for the exam. The first type is an S3 bucket. This is the most common origin for static content. You store your images, videos, javascript files, CSS files in an S3 bucket, and CloudFront caches them at the edge. This works beautifully for static websites, file downloads and media distribution. CloudFront can also be used to upload files to S3 not just download them, so users can upload through CloudFront edge locations using something called transfer acceleration, which we will touch on a bit later. Now, when your origin is an S3 bucket, you have a security consideration to make. By default, an S3 bucket is private. If you want CloudFront to serve content from it, you need to grant CloudFront permission. The recommended way to do this is using origin access control, or what you call OAC. With an OAC, you keep the S3 bucket completely private to the public internet, but you grant CloudFront permission to read from it. The bucket policy is configured to only allow access from your specific CloudFront distribution. This is a critical security pattern right there. Users can never bypass CloudFront and hit your S3 bucket directly. All traffic now flows through the CDN, which means caching always works, your data is protected, and you get a clean security boundary. The second type of origin is a VPC origin. This is a relatively newer feature and it's powerful. With VPC origins, CloudFront can deliver content from applications hosted inside your VPC private subnets without exposing them to the public internet. Your application load balancer, network load balancer, or EC2 instances can stay completely private, never receiving traffic directly from the public internet. CloudFront connects to them through a private path. This is fantastic for security. Your backend infrastructure doesn't need any public IP addresses or internet facing endpoints, yet CloudFront can still pull content from it and serve it globally. The third type is a custom origin, which essentially means any HTTP backend. This could be an S3 bucket configured as a static website, which is different from a regular S3 bucket, because you have to enable the static website hosting feature there. It could be a public application load balancer, it could be a server outside of AWS. If you have an on-premises web server with a public IP, CloudFront can use it as an origin. As long as it speaks HTTP, CloudFront can pull from it. Now there's a security consideration if you're using a public ALB or a public EC2 instance as a custom origin. Without proper configuration, someone could discover your ALB's address and bypass CloudFront hitting your origin directly. To prevent this, you configure the security group on your ALB or EC2 to only accept traffic from CloudFront's edge location IP ranges. AWS publishes a list of these IPs and you reference them in your security group. Alternatively, you can use a custom header that only CloudFront sends and configure your ALB to require to use that header. Either approach ensures only CloudFront router traffic reaches your origin. For the exam, remember these three origin types. S3 bucket secured with origin access control. VPC origins for private buckets and custom origins for any public HTTP endpoints with security groups restricted to CloudFront's IP ranges. Let's now really understand how caching works in CloudFront because this is where the exam can get tricky. When a user makes a request, here's what happens step-by-step. The request first hits the closest CloudFront edge location based on the user's geographic location. CloudFront checks its local cache to see if it asks the requested content. If yes, and this is called a cache hit, we covered this earlier. CloudFront returns the cached contents immediately. The user gets a very fast response and your origin never knows about the request. If it's a no, then this is called a cache miss. CloudFront forwards the request to your origin, gets the content, stores it in its edge cache and returns it to the user. So subsequent requests for the same content from the users in that region will be cache hits. The key question is, how long does CloudFront keep something in the cache? This is controlled by what we call TTL which stands for Time to Live. The TTL can be set in a few different ways. Your origin can include a cache control header in its response that tells CloudFront how long to cache the content. You can also configure default TTLs at the distribution level and you can create cache behaviors which are rules that apply different TTLs to different parts. For example, you might cache images for 24 hours but cache API responses for only one minute. This brings us to caching strategies which is what we promised in the episode title. So let me walk you through the main approaches. The first strategy is caching static content aggressively. Images, videos, phones, compiled JavaScript and CSS, these rarely change so cache them for a long time. A TTL of one day or even longer is perfectly reasonable here. This maximizes cache hits and minimizes load on your origin. The second strategy is caching dynamic content carefully. Some content changes frequently, like news articles, product listings, search results and so on. You can still cache it, but with shorter TTLs, maybe 60 seconds or 5 minutes. This way, even if the content goes stale briefly, you still get massive performance gains during the cache window. With a 60 second TTL, even if you have a million requests per minute, your origin only needs to serve the content once per edge location per minute. The third strategy is not caching truly dynamic content. Things like a user's shopping cart, their account balance, their personalized recommendations, these are all different for every user you can imagine. You can configure a cloud front to forward these requests to the origin every time with a TTL of zero. The benefit here isn't caching, but you still get a cloud front's other advantages. The AWS global network for faster transit, the DDoS protection and the connection pooling between edge and origin, which improves latency. A really important concept is cache keys. A cache key is what cloud front users to identify a cached object. By default, the cache key is just the URL. So example.com/image.jpg is cached once, and every user gets the same cached copy. But sometimes the same URL needs to return different content. Maybe you want to return a different version based on the user's language, or based on whether they are on mobile or a desktop app. You can configure cloud front to include headers, query strings or cookies in the cache key. Be careful though, the more variations you add to the cache key, the more cached versions you create. And your cache hit rates goes down because each variation has its own cache entry. Another concept worth knowing is cache behaviors. A distribution can have multiple cache behaviors each configured to different URL patterns. For example, part starting with /api/ might forward your API gateway origin with no caching. Part starting with /image/ might go to your estuary origin with a one-day TTL. Part starting with /video/ might use a different cache configuration entirely. This gives you a fine grain control over how each part of your application behaves. For the exam, remember the caching fundamentals. Cache hit equals fast response from edge. Cache miss equals fetch from origin and then cache locally. TTL controls how long the content stays cached. Cache behavior lets you apply different rules to different parts. Cache keys determine what counts as the same content. Okay, now what happens when you update something at your origin and you don't want to wait for the TTL to expire? You have fixed a typo on your homepage, for example, but CloudFront is still serving the old version because the TTL says cache it for a day. You don't want to wait a day for the fix to propagate. This is where cache invalidation comes in. Invalidation lets you force CloudFront to forget about cache content before the TTL expires. You can invalid everything by specifying a wildcard just like an asterisk. Or you can invalidate specific parts like /index.html or /images/star to clear just the images folder. When you submit an invalidation request, CloudFront marks those files as invalid across all its edge locations globally. The next request for that content will be a cache miss, forcing CloudFront to fetch the fresh version from your origin. This is incredibly useful for deployment scenarios where you have pushed the new version of your site and won the changes to be live immediately. There's a cost how are you to consider. AWS gives you a certain number of invalidation parts for free each month, typically the first thousand parts. Beyond that, you pay per path invalidated. So if you find yourself invalidating constantly, that's a sign you should either use shorter TTLs or version your file names. Versioning of file names means renaming files when they change, so instead of style.css, you use style hyphen v2.css. Now the URL itself changes so there is no cache to invalidate. The new URL is just a cache miss the first time then cached normally. This is the recommended pattern for production deployments. For the exam, remember that invalidations let you bypass the TTL for specific parts or all content. They're useful for emergency content updates but can get expensive at scale. Best practice is to version your file names where possible. Cloudfront has some powerful security features beyond just being part of AWS Shields DDoS protection. The first one is geo restriction, also called geo blocking. This lets you control who can access your content based on the country they're connecting from. You can configure an allow list which means only users from approved countries can access your content. Or you can configure block list which means users from specific countries are blocked. The country is determined using a third-party geo IP database that maps IP addresses to countries. A common use case is copyright laws. Maybe you have licensed a video for streaming only in certain countries. With geo restriction, you can ensure that the users outside those countries can't access the content. Another use case is regulatory compliance. Some content might be illegal in certain jurisdictions and geo restriction lets you comply without writing any code. Beyond geo blocking, you can also control access through signed URLs and signed cookies. These are mechanisms for sharing private content with authorized users. A signed URL is a URL that includes a signature providing the requester has permission to access the content. You can generate the signed URL on your server with an expiration time, then give it to authorized users. Now when Cloudfront receives a request with that signed URL, it verifies the signature and its expiration. And if it's valid and not expired, the content is served. If not, the request is denied. This is perfect for scenarios like premium video streaming where you only want paying subscribers to get the video URLs and you want those URLs to expire after a shorter time. Signed cookies work similarly but apply to multiple files at once. Instead of generating individual signed URLs for every file, you give the user a signed cookie that authorizes access to a whole set of resources. When the browser requests those resources, the signed cookie is included automatically and Cloudfront validates it. This is great for protecting an entire section of a site like a member's area with many pages and assets. Cloudfront also integrates with AWS web application firewall which I mentioned earlier. WAF lets you create rules to block common attacks, which is like SQL injection attempts, cross-site scripting, request from specific IP addresses or even custom rules based on request patterns. By attaching a WAF web ACL to your Cloudfront distribution, you get application led protection at the edge before traffic ever reaching your origin. For the exam, remember the security features. Use your restriction for country-based blocking. Use signed URLs and signed cookies for authorizing access to private content. Use WAF integration for blocking malicious requests at the edge. Now let's look at Cloudfront versus S3 cross-region replication. By the way, this is a comparison that shows up regularly on the exam. So let's make sure you understand the differences. Both Cloudfront and S3 cross-region replication can be used to get content closer to users, but they work very differently and they are suited to different use cases. Cloudfront uses a global edge network with hundreds of edge locations worldwide. Content is cached at the edge for a TTL maybe a day, maybe longer. The cache is best suited for static content that doesn't change often but needs to be available everywhere with low latency. Images, videos, static website assets, these are perfect Cloudfront workloads. You upload them once to your origin and Cloudfront distributes them across the global edge network on demand. S3 cross-region replication, on the other hand, is fundamentally different. Instead of caching at edge locations you actually replicate your S3 bucket to other AWS regions. Let's say you have a primary bucket in, say, US East one and you set up replication to create a copy in E-US one and another in AP Southeast one. Updates flow from the primary to the replicas in near real time. Your application then reads from whichever region is closest to the user. Here's how to think about when to use which. Cloudfront is the right choice when your content can tolerate being cached for a period of time, when you have global users and when you want to manage CDN with built-in DDoS protection. The content can be stale by the TTL duration but you get massive performance improvements. Cross-region replication is the right choice when you need the data itself, not just cached copies available in multiple regions. That is for example when you need real time updates. Users in Europe should see the latest version within seconds of an update in the US or when you have applications running in multiple regions that need read access to the data with low latency. Well, it's also useful for disaster recovery since you have actual copies of your data in multiple regions here. A subtle point I want to cover here is that cross-region replication only flows in one direction by default. The primary bucket is a source of truth and the replicas are read only copies. If you need bi-directional replication where any region can be the source of the rights, you have to configure that explicitly. For the exam, the keywords to watch for are static content available everywhere with low latency. Then that's CloudFront. Dynamic content updated in near real time in specific regions, then go for cross region replication. Okay, now let's go on to one of the most commonly tested comparisons on the entire exam. CloudFront versus AWS Global Accelerator. Both services use the AWS Global Network and Edge locations. Both integrate with AWS Shield for DDoS protection. So what's the difference here? CloudFront is a CDN. Its job is to deliver content from the Edge. It excels at caching content, images, videos, static assets that's close to the user. It can also accelerate dynamic content because the requests travel over AWS's optimized backbone network instead of the public internet. CloudFront sits at the application lab, so it understands HTTP, HTTPS, and works with web content. Global Accelerator, on the other hand, is a network layer service. Instead of caching content at the edge, it provides static IP addresses that route traffic through AWS's global network to your application running in one or more AWS regions. The packets are proxied through the Edge locations to your origin, which gives you the speed of the AWS backbone for the entire trip. Here are the key differences for the exam. CloudFront works only with HTTP and HTTPS. Global Accelerator works with any TCP or UDP protocol. So this makes Global Accelerator the right choice for non-HTTP applications like gaming, which often uses UDP or IoT devices using MQTT protocol or voice over IP protocols. If you see those use cases mentioned in a question, the answer is almost certainly Global Accelerator. CloudFront's IP addresses change. The DNS results to whatever edge location is closest to the user and that IP can change over time. Global Accelerator provides two static anycast IP addresses that never change. This is hugely important when your clients can't easily handle changing IPs. For example, if you have IoT devices in the field with hard-coded IPs, you want stable IPs there. Or if a corporate firewall wireless requires specific IPs to allow through, Global Accelerator static IPs simplify that configuration. Only two external IPs need to be in the allow list here. CloudFront serves cashed content from the Edge. The content is at the Edge location itself. Global Accelerator doesn't cash. It proxies traffic to your origin region. So if your origin goes down, CloudFront might still serve cash content for a while, but Global Accelerator's traffic just stops. Failure behavior is another one big differentiator. Global Accelerator performs health checks on your application and provides fast regional fail-over, typically that's less than one minute if a region becomes unhealthy. This makes Global Accelerator excellent for disaster recovery scenarios where you have your application running in multiple regions and you need automatic and deterministic fail-over. CloudFront, on the other hand, doesn't provide this regional fail-over the same way because its job is delivering content from the Edge, not routing traffic between regions. Now, let me give you exam scenarios to crystallize this concept. Scenario 1. You want to make a global gaming application faster where your users connect via UDP to game service. The answer is to use Global Accelerator. CloudFront can't even handle UDP. On to scenario 2, you have a static website with images and videos that need to load quickly for users worldwide. The answer is to use CloudFront. Static content caching at the Edge is exactly what it does best. Scenario 3. You have a corporate API that's accessed by clients with strict firewall rules requiring specific IPs. Static IPs are critical here and Global Accelerator does that better. On to scenario 4, you have multiple regional deployments of your application and need automatic fail-over under one minute if a region fails. The fast regional fail-over is its specialty. And finally scenario 5. You want both caching of static assets and dynamic IP acceleration for an HTTPS application. What would you use? The answer is CloudFront. It does both. It's able to cache content at the Edge and provide dynamic content through AWS's backbone. So for the exam, here's the mental shortcut. HTTP, HTTPS and caching equals CloudFront. Non-HTTP protocols, static IPs or fast regional fail-overs equals to Global Accelerator. Remember that they are complimentary services that solve different problems. Okay, now let's talk about Edge Computing. CloudFront has evolved beyond just serving content. It can also run your code at Edge locations which means you can customize behavior or do computations close to users without round-tripping to a backend. This is called Edge Computing and CloudFront offers two flavors. There is CloudFront Functions and Lambda at Edge. Both let you write code that runs at Edge locations but they have important differences. CloudFront Functions are very lightweight functions written in JavaScript. They have sub-millisecond startup times and can handle millions of requests per second. The trade-off is that they are highly constrained. The maximum execution time is under one millisecond. Memory is limited to two megabytes. Total package size is 10 kilobytes. They have no network access and no file system access. They can only modify the viewer's request. That's the request coming in from the client or the viewer response. That's the response going back to the client. So what can you actually do with CloudFront Functions despite the constraints? There's quite a lot actually. You can do cache key normalization that's taking variations in headers, cookies, query strings and URLs and normalizing them so different versions of essentially the same request all hit the same cache entry. You can manipulate headers. That's insert security headers, modify or delete existing headers. You can do URL readwrites and redirects that sending users from old URLs to new ones, redirecting based on country or device type and you can also do simple authentication and authorization that's validating JWT tokens for example to decide whether to allow a request. Lambdaed Edge on the other hand is more powerful but also more expensive and slower. It's Lambda functions written in Node.js or Python that run a CloudFront Edge locations. The maximum execution time is 5 to 10 seconds. Memory ranges from 128 megabytes up to 10 gigabytes. Package size can be 1 to 50 megabytes. It supports network access and file system access. It can access the body of HTTP requests which CloudFront Functions cannot. Lambdaed Edge can trigger at 4 different points. Viewer request, origin request, origin response and viewer response. So it gives you more places to intervene in the request response flow. The use case for Lambda at Edge are when you need longer execution time. When you need adjustable CPU memory, when your code depends on third party libraries like the AWS SDK to access other services, when you need network access to call external services or when you need file system access or access to the body of HTTP requests. A common practical example is when you want to dynamically resize images at the edge. A user requests an image with a specific size in the query string. Lambda at Edge intercepts the request, generates the resized image, caches it and returns it. This works because Lambdaed Edge has the execution time and memory to do real image processing where CloudFront Functions wouldn't be able to do. You write Lambdaed Edge Functions in one specific region, U.S. East one, and CloudFront automatically replicates them to all locations worldwide. So you deploy once and it runs everywhere. For the exam, here's how to choose. If you need ultra fast, simple request manipulation at massive scale, then your option is CloudFront Functions. If you need more powerful code with network access, external libraries or longer execution time, then go for Lambdaed Edge. CloudFront Functions are roughly one-sixth of the price of Lambdaed Edge, so use them when they are sufficient. Now let's put all of what we've learned together with the real architecture patterns. The first pattern is serving of static website globally and securely. You have an S3 bucket containing your HTML, CSS, JavaScript and images. You create a CloudFront distribution with that S3 bucket as the origin, secured with origin access control. The S3 bucket policy is configured to only allow access from your specific CloudFront distribution, uses from anywhere in the world to hit the nearest CloudFront edge location, which serves the cash content with very low latency. If they request something not yet cashed, CloudFront fetches it from S3 securely and caches it. This is the classic serverless static website architecture and it scales to enormous traffic with minimal cost. The second pattern adds a serverless API to that static website. The static assets still come through from S3 to CloudFront, but you also create an API gateway endpoint that invokes Lambda functions, which you read and write to DynamoDB. CloudFront can also sit in front of API gateway as a second origin, Accelerating those API code. calls and providing caching for cashable API responses. So you have one cloud front distribution that routes different parts to different origins. Request for slash image slash goes to estri. Request for slash API slash goes to the API gateway and lambda. The user sees a unified experience here, but behind the scenes, you're using multiple AWS services optimally. The third pattern leverages DynamoDB global tables for true multi-region. The static content still serves from Cloud front. The API still goes through API gateway and lambda. But now your DynamoDB is configured with global tables, meaning the database is replicated across multiple AWS regions. Combined with Cloud front's global edge network, your users get a fast experience no matter where they are. Static content from the nearest edge dynamic content from Lambda functions hitting a regional DynamoDB global tables replica. The fourth pattern is a thumbnail generation flow that uses Cloud front for both reading and uploading. Users upload photos through Cloud front with estri transfer acceleration, which means uploads also benefit from the edge network. The estri bucket has an event that triggers when a new photo arrives, which invokes a lambda function to generate a thumbnail. The thumbnail is stored in a separate estri bucket. Then Cloud front serves both the original photos and the generated thumbnails to viewers globally. So you've got a complete photo sharing application using Cloud front on both the read and write parts. These architectures show Cloud front isn't just for static files. It's a foundational piece for building truly global applications. Now combine it with API gateway, Lambda, DynamoDB, global tables, and Route 53 latency-based routing. And you have a global application that performs very well anywhere in the world. For the exam, watch the scenarios that describe global users, low latency requirements, static and dynamic content mixed together, or the need for DDoS protection. These signals point to Cloud front as part of the answer. OK, now let's go through some common Cloud front traps that catch people on the exam. Trap number one, Cloud front versus estri cross region replication. If the question is about static content cache globally with some staleness acceptable, the answer is always Cloud front. If the question is about dynamic content updated in real time available in specific regions, the answer is estri cross region replication. Don't mix these up. Onto trap number two, Cloud front versus global accelerator. If you see HTTP or HTTPS caching or web content, always lean toward Cloud front. If you see UDP, TCP, non-HTTP, static IP is needed, gaming, IoT, or fast regional failover, then lean towards global accelerator. Static IP requirement is the strongest signal for global accelerator. Onto trap number three, origin access control versus public estri bucket. If a question described serving content from estri through Cloud front and asks for the most secure approach, the answer is always origin access control with a bucket policy, restricting access to Cloud front. You don't want to make the bucket public. Onto trap number four, Cloud front and HTTPS. Cloud front supports HTTP and you can configure your distribution to require HTTPS, redirect HTTP to HTTPS, or use SSL certificates from AWS certificate manager. Watch for questions about enforcing encryption in transit. Trap number five, signed URLs versus signed cookies. If the question is about giving access to one specific file with an expiration, the answer is signed URLs. If the question, on the other hand, is about giving access to many files like a whole subscription area, the answer is signed cookies. Trap number six, cache invalidation costs. Invalidations are useful, but costs money beyond the free tier. The exam might describe a scenario with frequent invalidations and asks for a better approach. The answer is usually to use shorter details or to version your file names instead. Trap number seven, Cloud front with VPC origins. If the question describes wanting to serve contents from an application in a private subnet, without exposing it to the internet, the modern answer is Cloud front with VPC origins. All the patterns use custom origins with security group restrictions, but VPC origins is the cleaner solution here. Onto trap number eight, dual restriction implementation. Geo restriction is a built-in Cloud front feature. You don't need a separate service or custom code. If a question describes restricting access by country, the answer is Cloud front geo-restriction. Trap number nine, Cloud front functions versus lambda at edge. If the question describes simple header manipulation, URL rewrites, or cache key normalization at massive scale, the answer is Cloud front functions. If the question on the other hand describes longer execution, network access or processing the request body itself, the answer is lambda at edge. Trap number 10, regional services don't cache. Cloud front caches at edge locations, but the API gateway timeout of 29 seconds still applies even when Cloud front is in front of it. Adding Cloud front doesn't extend back in timeouts. Remember that. Onto trap number 11, cache behaviors and routing. If a question describes routing different URL parts to different backends from a single Cloud front distribution, the answer involves multiple cache behaviors, each with its own origin configuration. And finally for trap number 12, default behavior versus path-based behaviors. Every Cloud front distribution has a default cache behavior. You add additional behaviors with path patterns like slash API slash star or slash images slash star. The most specific pattern wins. The default behavior is the fallback when nothing else matches. And so finally, let's look at some exam quick tips. Let me give you the rapid fire summary to lock all of this in. Cloud front is a CDN, hundreds of edge locations globally. Caches content close to the users, improves performance, reduces origin load, and provides dedos protection through AWS shield integration. There are three origin types. There are S3 buckets with origin access control, VPC origins for private backends, and custom origins for any public HTTP backend. Remember that TTL controls cache duration. Cache behaviors apply different rules to different parts. Cache invalidations bypass detail for a specific path, but cause money. Versioning file names is usually always better. Joe restriction blocks access by country. Signed URLs, authorize access to individual files, while signed cookies authorize access to many files. Remember that Cloud front caches content globally, versus S3 cross region replication is basically replicated content in specific regions. Cloud front remember is HTTP and HTTPs with caching versus global accelerator, which is any TCP or UDP with static IPs and fast regional failure. Edge computing is Cloud front functions for lightweight, massive scale customization. You want to use Lambda Edge for more complex code with network access. Do you handle static content globally? Then use Cloud front. If your content is mixed static and dynamic with HTTPS, then use Cloud front. If it is not HTTP protocols or static IPs, then think global accelerator. If you need data physically multiple regions, then it's S3 cross region replication, or DynamoDB global tables. Alrighty, that is episode 14 right there on content delivery and global apps. We covered everything you need to know about Cloud front and global content delivery. We started with YCDN matters, reducing latency by caching content close to users. We specifically explored the three Cloud front origin types, S3 with origin access control, VPC origins for private buckets and custom origins for anything else. We then dove deep into caching, cache hits, cache misses, TTL, cache behaviors, and cache keys. We covered cache invalidation and Y versioning filenames is usually a better pattern. We looked at the security features, that's geo restriction, signed URLs, signed cookies, and WAF integration. We tackled two critical comparisons, Cloud front versus S3 cross region replication, and Cloud front versus global accelerator. We touched on edge computing with Cloud front functions and Lambda at edge. We brought all of this together with real architecture patterns combining Cloud front with S3, API gateway, Lambda, and DynamoDB global tables. And then we finally went through 12 common exam traps to watch out for. The big takeaway is that Cloud front isn't just a content delivery network. It's a foundational service for building globally distributed, high performance secure applications on AWS. Master the caching strategies, understand when to use Cloud front versus when to use global accelerator, and you will handle these questions confidently on the exam. We have now completed 14 main episodes. You've covered compute, storage, databases, networks, serverless messaging, and now content delivery. So that's a really comprehensive foundation for the AWS solution architect exam. If this episode helps you learn Cloud front and finally it clicks for you, please do consider to leave a five star rating on Spotify and subscribe to my channel. Also, please do share this podcast with anybody else studying for the AWS exam. It genuinely helps the channel grow. So until next time, keep building, keep optimizing, and I will see you in the next episode. This is Balu signing off all the best, bye.