Episode 4: AWS Global Infrastructure: Regions, AZs & Edge Locations | SAA-C03 Exam Prep

Hey everyone, Balu Bakir. Welcome back to Tech Talk with Balu. You go to podcast for AWS Solutions Architect Exam preparation. We are now on to episode 4 and today we are covering something absolutely fundamental, it's the AWS Global Infrastructure. Now you might be thinking Balu, this sounds basic but here's the truth. Understanding AWS's global infrastructure is what separates people who memorize facts from people who actually architect real solutions. When you're sitting in that exam and they ask, how do you design a globally distributed application with low latency? You need to understand regions availability zones and edge locations not just as concepts but as building blocks. Today we're going to explore what AWS regions are and how to choose the right one. Availability zones and why they are critical for high availability, edge locations and how they make your applications blazing fast worldwide, global architecture patterns that you will see on the exam and of course exam traps and real world scenarios. By the end of this episode you'll be able to design globally distributed architectures like a pro. So grab your coffee, get comfortable and let's dive into AWS Global Infrastructure. Alright, let's start with the big picture. What exactly is AWS Global Infrastructure? Think of AWS as a massive network of data centers spread across the entire planet. As of 2024, AWS has presents in over 30 geographical regions around the world with over 90 availability zones and more than 400 edge locations in 90 plus countries. That's an insane amount of infrastructure but why does it matter? Imagine your Netflix, you have 200 million subscribers in over 190 countries. Someone in Tokyo wants to watch Stranger Things. Someone in India wants to watch the same show. Someone in London wants to watch it too. All at the same time. If you had all your servers in one location, let's say Virginia in the US, what would happen? The person in Tokyo, their experience massive latency. The video would buffer, the experience would be terrible and they had canceled their subscription. But with AWS Global Infrastructure, Netflix can store content in regions close to the US, use edge locations to cache content even closer, deliver sub-second response times anywhere in the world. That's the power of global infrastructure. The three layers of AWS Global Infrastructure. Think of AWS infrastructure as having three layers. Layer one, regions. They are separate geographical areas around the world. Think US East one, Virginia, EU West one, Ireland, AP, Southeast one, that Singapore. Layer two, availability zones. These are isolated data centers within each region. Multiple AZs in each region provide redundancy. Layer three, edge locations. These are content delivery endpoints for caching content close to the users. There are way more edge locations than regions. So now let's deep dive into each layer because the exam will test you on all of these. Let's talk about AWS regions. This is fundamental and you will see it in the exam all the time. So what's a region? A region is a physical location around the world where AWS clusters data centers. Each region is completely independent and isolated from other regions. Think of regions like countries, just as France is separate from Japan, US East one is completely separate from AP, Northeast one. Important naming conventions. AWS regions have codes like US East one, which is US East North Virginia, EU West three, that's Europe, Paris, AP, Southeast two, Asia Pacific, Sydney, SA East one, South America, South Palo. The naming follows a pattern, geographical area, directional indicator, and a number. The critical example point, most AWS services are regions coped. This is very important. When you launch an EC to instance in US East one, it only exists in US East one. When you create an S3 bucket in EU West one, it exists only in EU West one. You cannot access an EC to instance in Virginia from the Europe region. They are completely separate. There is an exception though. These are global services. Some services are global, not regional. These are tested on the exam. I am identity and access management. They are global. Route 53, that's DNS, that's global. Cloudfront, CDN, that's global and WAF web application firewall, that's global too. Everything else, assume it's regional, unless stated otherwise. So how to choose an AWS region. There are four decision factors. This comes up on the exam all the time. When you're asked, how should a company choose an AWS region? Think of these four factors. Fact in number one, compliance and data governance. Some countries have laws requiring data to stay within their borders. Let's look at the real world example. A German healthcare company must comply with GDPR. Patient data cannot leave the European Union. They must use EU Central one, that's Frankfurt or EU West one, that's Ireland, but not the US East one. The example give you scenarios like financial companies must keep the data in Australia due to regulatory requirements. What's the answer? Use AP Southeast too, which is Sydney. Now on to fact to two. Proximity to customers, aka latency. The closer your resources are to your users, the lower the latency. Another real world example, you're building a gaming platform for players in India. Should you deploy in US East one, Virginia or AP South one, which is Mumbai? Mumbai is the answer obviously. The latency from India to Virginia might be about 200 to 300 milliseconds. From India to Mumbai, that's just five to 10 milliseconds. That's a 30X improvement right there. For gaming, that's the difference between playable and unplayable. On to an example pattern. An application serves users primarily in South East Asia, which a region provides the lowest latency. The answer is AP South East one, which is Singapore or AP Southeast two, which is Sydney depending on the specific country. Now on to factor three available services. Not all services are available in all regions. Newer services and features launch in major regions first. Let's look at a real world example. When AWS launches a new AI service, it might launch in US East one, US West two and EU West one first. It might take months before it's available in AP South one or AF South one. If you need that specific service, you must use a region where it's available. An example tip, AWS provides a regional services list that shows which services are available in which regions. For the exam, just know that not all services are everywhere. On to factor four, which is pricing. Yes, pricing varies by region. The same easy to instance costs different amounts in different regions. Why? That's real estate costs, electricity costs, tax structures, all vary by country. A real world example, M5 large in US East one would cost 0.096 dollars per hour. The same M5 large in AP South one would be about 0.095 dollars per hour. The differences might seem small per hour, but over months and thousands of instances, it adds up to a significant cost differences. Now let's look at an exam scenario. A company needs to deploy an application. They serve global customers equally, have no regulatory restrictions and want to minimize costs. How should they choose a region? The answer is choose the region with the lowest pricing for the required services, while still maintaining acceptable latency for the majority of the users. Now remember the four factor decision framework. When you see a region selection question on the exam, number one, check for compliance or regulatory requirements. That trumps everything. Number two, constriolatency or proximity to users. Number three, verify service availability and number four, compare pricing. Usually the exam will make the answer obvious by emphasizing one factor. Now let's talk about availability zones or AZs for short. This is critical for designing high available architectures and the exam loves this topic. What is an availability zone? An availability zone is one or more discrete data centers within a region, each with redundant power, networking and connectivity. The keyword there is isolated. Each AZ is physically separate from the other AZs. They're in different buildings or different infrastructure with independent power and networking. So why does this matter? If there is a fire, flood, power outage or any disaster at one AZ, the other AZs in the region are unaffected. Your application keeps running. How many AZs can you have per region? Each region has a minimum of three AZs. Most have three, some have four, five or even six. For example, US East 1 has 6 AZs. That's US East 1A, US East 1B, US East 1C, US East 1D, US East 1E, and US East 1F. APS2 has 3 AZs. That would be APS2A, APS2B, and APS2C. Now let's look at the naming convention. AZ names follow the pattern, region code + letter. US East 1A means US East region, availability zone A. So critical example, AZ names are mapped to different physical locations for different accounts. Here's what this means. My US East 1A might be in a different physical data center than your US East 1A. AWS randomly maps the letters to physical locations for each account. So why do they do that? For load distribution. If everyone chose zone A, thinking it was the main one, that zone would be overloaded. For the exam, just know that AZ names are accounts specific, not absolute. Connectivity between AZs. AZs in the same region are connected with high bandwidth, ultra-low latency networking. We are talking private fiber optic cables with less than 2 milliseconds of latency between AZs. This is fast enough that you can synchronously replicate data between AZs in real time. Now let's look at the high availability architecture pattern. This is the most important concept for the exam. Let me break it down. A bad architecture, single AZ. Region is US East 1. AZ US East 1A, bit load balancer, three EC2 instances, and an RDS database. Now what happens if US East 1A has an outage? Everything goes down completely failure. A good architecture would be to use a multi-AZ. So you would have one of the AZs with US East 1A, with a load balancer, automatically spans AZs, two EC2 instances, RDS primary database included. Another easy would be in US East 1B with two EC2 instances, RDS standby database. And you would have a third AZ, which would be US East 1C, with also two EC2 instances. Now if US East 1A goes down, US East 1B and US East 1C keeps running, the application stays online. Now for a real world example. In April 2011, AWS US East 1 had a major outage in one of their availability zone. Websites and services that used only that single AZ went completely offline. That's Reddit, Korra, 4Square, all went down. But companies that architected for multi-AZ, they experienced zero downtime. Netflix kept streaming their infrastructure automatically re-rooted traffic to healthy AZs. That's the power of proper AZ design. Now for an exam question pattern. An application must achieve 99.99% uptime. The application is currently deployed in a single AZ, what should be done? The answer is, deploy the application across multiple AZs in the same region. Use an elastic load balancer to distribute traffic. So the keywords are high availability, fault tolerance, disaster recovery, and then you want to think multi-AZ deployment. So now let's look at the services that support multi-AZ. Know these for the exam. Elastic load balancers. They automatically span multiple AZs. Use specify which AZs and the ELB distributes traffic across them. Auto scaling groups. They can launch instances across multiple AZs. If one AZ fails, ASG launches replacement instances in healthy AZs. Adios multi-AZ. This synchronously replicates your database to a standby in another AZ, automatic fail-over in under a minute. S3 automatically stores data across multiple AZs, at least three. You don't configure this, it's automatic. EBS volumes. These are AZ specific. An EBS volume in US East 1A can only attach to instances in US East 1A. To move an EBS volume to another AZ, you must create a snapshot and restore it in the target AZ. Now onto exam trap for EBS and AZs. Question. An EZ to instance in US East 1A needs to attach an EBS volume from US East 1B. Is this possible? People think they are in the same region, so yes. Wrong. EBS volumes are AZ specific. They cannot attach across AZs. Remember this. The answer is no. You must create a snapshot of the volume and restore it in US East 1A. This comes up all the time on the exam. So what are the multi-AZ best practices for the exam? Know these patterns. Minimum 2AZs. For high availability, use at least two AZs. Better? Three AZs. This is the AWS recommendation. If one AZ is down and another is having issues, you still have a third. Load balancer across AZs. Use elastic load balancers to distribute traffic evenly. Data replication. Use services that automatically replicate data across AZs, like RDS, multi-AZ, S3, EFS, and so on. Now onto an exam scenario. A company needs to deploy a web application that can tolerate the failure of an entire data center. What should they do? The answer is deploy the application across multiple availability zones within a region using auto-scaling groups and an application load balancer. Not to deploy in multiple regions, that's over-engineering for this requirement. And definitely not to use a single AZ with reserved instances because there is no fault tolerance. So let's look at the cost implications of multi-AZ. Multi-AZ does not cost more. You're running resources in multiple locations, but for production workloads, it's non-negotiable. Real-world analogy, it's like car insurance. It costs money, but when you need it, you're glad you have it. For the exam, when they ask about cost versus availability, remember, production workloads should always be multi-AZ. The exam expects this. Alright now, let's talk about edge locations. This is where things get really, really interesting and heavily tested on the exam. So what are edge locations? Edge locations are AWS data centers designed to deliver content to end users with the lowest possible latency. The part of cloud front AWS's content delivery network. Think of edge locations as caching service, position close to your users worldwide. Class of 2024, AWS has over 400 edge locations in more than 90 cities across 40 plus countries. That's way more than regions, 30 plus or availability zones, 90 plus. Why so many? Because edge locations are smaller, simpler facilities. They don't run easy to instances or databases. They just cache and deliver content. So how do edge locations work? Let me explain with the real world scenario. You have a website with images and videos hosted on S3 in US East 1, Virginia. You have users in Tokyo, London, Sydney and Sao Paulo. Without cloud front, no edge locations, user in Tokyo requests an image, requests travels from Tokyo to Virginia, which takes 150 milliseconds, image downloads from Virginia to Tokyo, which takes another 300 milliseconds. So the total round trip time is 450 milliseconds. Now multiply that by 100 images on a webpage. The page takes 45 seconds to load. That's terrible user experience. With cloud front, using edge locations, first time a Tokyo user requests the image, requests goes to Tokyo edge location, which takes 5 milliseconds. Edge location doesn't have the image cached yet. It's called a cache miss. Edge location fetches that from S3 in Virginia, which takes 150 milliseconds. Images now cached at Tokyo edge location. Edge is delivered to user in another 5 milliseconds and the total time for the first user is 160 milliseconds till faster. Now the second user in Tokyo requests the same image. Request goes to Tokyo edge location, which takes 5 milliseconds. Edge location has the image cached. That's a cache hit. Image is delivered immediately within 5 milliseconds. So that's the total time of 10 milliseconds, which would be 45 times faster than without cloud front. This is the magic of edge locations. Cloud front use cases. For the exam, no one to recommend cloud front. Number one, static content delivery. That's for images, CSS JavaScript files, videos and media files, software downloads, or game assets. Number two, dynamic content acceleration. That's for API responses, dynamic web pages, personalized content. Number three, live and on demand video streaming. Netflix uses cloud front to deliver streaming video. Twitch uses it for live gaming streams. Number four, security and DDoS protection. Cloud front integrates with AWS Shield and WAF. Absorbs DDoS attacks at the edge. Now for a real world example with Airbnb. Airbnb uses cloud front to deliver listing images to users worldwide. have millions of dollars. of property photos stored in S3. Without CloudFront, a user in Sydney viewing a New York listing would download images from the US causing slow page loads. With CloudFront, those images are cashed to the Sydney edge location. Page loads are instant. User experience is great. Conversion rate goes up. So, now for an exam question pattern. A company has a website with static content served from S3. User's worldwide reports slow page load times. What should they do? The answer is use Amazon CloudFront to cash content at edge locations worldwide. So the keywords you want to look for are global users, slow performance, static content, always think CloudFront. Edge locations versus regions versus AZs. Let's look at the comparison now. Let me clarify the differences because this confuses people. So regions, the purpose of it is to run AW services. So that could be easy to ideas lambda, etc. You could have 30 plus of them. Scope is broad geographic areas. The services they offer is all AW services. An example is US East one or EU West one. Now for availability zones, the purpose is to provide redundancy within a region. They are 90 plus 3 to 6 per region and the scope is individual data senders within a region and the services they provide regional services deployed here. An example would be US East one A or US East one B. On two edge locations, the purpose is to cash and deliver content to users. There is about 400 plus of them and the scope is major cities worldwide. The services provide CloudFront, Route 53 DNS, AWS Global Accelerator, example Tokyo London, Sao Paulo, Edge locations. On to exam trap question. Can you run easy to instances at edge locations? People think edge locations are AWS infrastructure so maybe. Wrong, edge locations only support CloudFront, Route 53 and Global Accelerator. You cannot run EC2, RDS, Lambda or any other computer database services at edge locations. So the answer is no, EC2 instances can only run in AWS regions within availability zones. Regional edge caches, the middle tire. There's actually a middle tire between edge locations and regions called regional edge caches. Think of it as a hierarchy. User to edge location, there's 400 plus worldwide, edge location to regional edge caches, there's 10 plus of them and regional edge caches to your origin, that's your S3 bucket or server. Regional edge caches are larger than edge locations and the cash content that's less frequently accessed. This reduces load on your origin. For the exam, just know they exist. You will need deep details. CloudFront and S3 transfer acceleration. Another use of edge locations is S3 transfer acceleration. Normal S3 upload from Singapore to US East 1. It travels over the public internet, lots of hops, potential congestion, slow and unpredictable. Using S3 transfer acceleration, the upload goes to Singapore edge location, edge location then transfers to US East 1 over AWS's private network, it's faster, more reliable and consistent speed. For the exam, how can a company speed up uploads to S3 from distant locations if asked? The answer is to enable S3 transfer acceleration. Now let's talk about global architecture patterns. This is where everything comes together and this is what the exam really tests. Pattern 1. Single region multi-AZ. This is the most common. This is your baseline for production applications. The architecture is 1A-bless region, application deployed across three availability zones, elastic load balancer, distributing traffic, auto-skilling group managing instances, RDS multi-AZ for database, S3 for object storage, automatically multi-AZ. So use case that it covers is that an application serves users in one geographical area, example North America only. What are its benefits? High availability, it survives AZ failure, it's cost effective because it's only one region and it's simple to manage. Now what are its limitations? No protection against region failure, high latency for users far from the region and no disaster recovery across regions. A US-based SaaS company with primarily North American customers, they deploy in US East 1 across three AZs. If one AZ fails, the application stays online, cost effective and reliable for their use case. Now for an exam scenario, a company needs high availability for an application serving US customers. What's the most cost effective approach? The answer is to deploy across multiple AZs in US East 1 or another US region with an ELB and auto-scaling enabled. Now for pattern 2, multi-region, active, passive. This is for disaster recovery scenarios, the architecture is primary region, active handling or traffic, multi-AZ deployment, production database, secondary region, passive standby, minimal resources, maybe just an AMI and database snapshot or some resources running at reduced capacity, database replica, cross-region replication. The use case is business critical application that must survive a region failure. How does it work? Normal operations, all traffic to primary region. Region failure, failover to secondary region and then restore to primary when it recovers. For a real world example, a financial trading platform can't afford downtime. Primary region is US East 1, secondary is US West 2. If US East 1 fails completely, that's the entire region goes for an outage, they fail over to US West 2 within minutes using Route 53 Helgex. Artyo and RPO. For disaster recovery, you need to know these two terms. Artyo stands for recovery time objective, that's how long can you be down. Is it four hours, is it one hour or 15 minutes? RPO stands for recovery point objective, that's how much data can you lose. 24 hours of data, one hour of data or zero data loss. Different DR strategies have different RTO or RPO. So the first strategy is backup and restore. It takes regular snapshots, it stores in S3 that's replicated to another region and in disaster it restores from the snapshots. The RTO is typically hours and the RPO is hours to 24 hours and this is the cheapest option. The second strategy is pilot light, which uses minimal resources running in secondary region with the database continuously replicating. In the event of disaster, it scales up to a secondary region. The RTO is roughly about 10 to 30 minutes and the RPO is within minutes and it's with moderate cost. The third strategy is warm standby, where there's a scaled down version running in the secondary region. In disaster, it scales up to full capacity. The RTO is in minutes and the RPO in seconds, but comes with a higher cost. The fourth strategy is multi-site active active. There's full deployment in both regions, both serving traffic. The RTO is zero, that's automatic failover, handled and RPO is zero. This is often the most expensive option. So an exam question, a company needs to achieve an RTO one hour and an RPO of 15 minutes, which DR strategy should it choose? The answer is pilot light or warm standby, both meet the requirements. It's not backup and restore because the RTO and RPO are far too long and it's not multi-site active because that's over engineered and too expensive. Pattern 3 multi-region active active. This is for truly global applications. The architecture is that covers multiple regions or active. Each region serves local users. Route 53 routes uses to nearest region, data synchronized across regions. DynamoDB global tables or RORA global databases can be used. The use cases global applications like Netflix, Facebook or AWS itself. Provides lowest latency for users worldwide. It survives region failure, that's automatic failover handled and highest availability. The challenges are it's most expensive because it's running full infrastructure in multiple regions. There is complex data synchronization and there is potential data consistency issues. Let's look at a real world example of Netflix. This has presents in multiple AWS regions, US East 1, EU West 1 and AP South East 1. A user in Germany connects to EU West 1. A user in California connects to US East 1. Both get sub 50 millisecond response times. If EU West 1 fails, European users are routed to US East 1 with slightly higher latency. But the service still stays online. Now let's look at data synchronization challenges. This is tricky and comes up on the exam. A Scenarios user in USB post a photo. User in Japan views the same profile. There are two possible options. Option 1 is synchronous replication with these following steps. Right to US region, wait for replication to Japan, confirm success. The process data is always consistent and the corn is it's slow rights. There's high latency basically. Option 2 is asynchronous replication. Steps are right to US region, confirm success immediately, replicate to Japan in the background. The pros are fast rights and the corn is temporary inconsistency. Eventually gets consistent. Most global applications use asynchronous replication and accept eventual consistency. So an exam question. A global application needs to provide low latency rights for users worldwide. Data Consistency can be eventual which approach would you choose. The answer is deploy in multiple regions with asynchronous replication. Use dynamodilb global tables or Aurora global database. Now on to pattern 4. Cloudfront with regional origin. This is a hybrid approach. Let's look at the architecture. Application in one region, example US East 1. Cloudfront distribution caches content globally. Dynamic content accelerated through edge locations and static content cached at edge locations. The use case is global audience but application logic doesn't need to be deployed globally. It's much cheaper than multi-region active active. Still provides good global performance and it's simpler to manage. While the limitations are application logic is still in one region that single point of failure and only content or API responses are cached not compute. A real world example would be a blogging platform with readers worldwide. The application runs in US East 1. Blog posts, majestic content are cached via Cloudfront at edge locations globally. Readers worldwide get fast page loads without deploying the app in multiple regions. An exam scenario would be a company has a web application in US East 1 serving global users. Users in Asia report slow page loads. The company wants to improve performance without deploying in multiple regions. What should they do? The answer is use Amazon Cloudfront to cache content at edge locations worldwide. It's not to deploy the application in multiple regions. That's again over engineered for the requirement. Now let's talk about how to actually route users to the closest region. This is where the important route 53 comes in and it's heavily tested. Route 53 is AWS's global DNS service. It routes end users to your application by translating domain names like www.example.com to an IP address. For global applications route 53 has routing policies that intelligently direct users to the optimal endpoint. Let's look at latency-based routing. This is the most important routing policy for global applications. How does it work? One, you deploy your application in multiple regions. Example US East 1 or EU West 1. You then create a route 53 records for each region. Route 53 then measures the latency from users to each region and route 53 automatically routes each user to the region with the lowest latency. A real world example would be that you have an API deployed in US East 1 EU West 1 and AP Southeast 1. User in Germany makes a request. Latency to US East 1 would be 90 milliseconds. Latency to EU West 1 would be 15 milliseconds. Latency to AP South East 1 would be 180 milliseconds. Route 53 routes them to EU West 1 because that is the lowest latency. Now user in Japan makes a request. Latency in US East 1 would be 120 milliseconds. Latency to EU West 1. If it is 200 milliseconds latency to AP South East 1. If it was 20 milliseconds then route 53 routes them to AP South East 1 because that is the lowest latency. This is completely automatic. You just configure it once and route 53 handles the routing based on real-time latency measurements. Now for other route 53 routing policies. For the example, know these. Number one, geolocation routing. This routes based on users' geographical location. Example, all users in Germany gets routed to EU Central 1. All users in US to US East 1. The use case would be content like sensing restrictions or compliance requirements etc. The second one is geoproximity routing. This routes based on geographical location but with a bias. You can shift more or less traffic to a region. Gradual migration from one region to another would be where you would want to use geoproximity routing. The third one is weighted routing. This routes based on assigned weights. Example, you could set 70% to US East 1 and 30% to EU West 1. Use case would be kind of blue-green deployment model or AB testing. The next one would be failover routing where you have primary and secondary endpoints. It only routes to the secondary if the primary is unhealthy. Use case would be active passive kind of disaster recovery architecture. The next one is multi-value answer routing. This returns multiple library addresses. Client and chooses which one to use. The use case would be symbol load distribution. Now for an exam scenario. A company has deployed an application in US East 1, EU West 1 and AP Southeast 1. They want to route users to the region with the best performance. Which route 53 routing policy should they use? The answer is latency based routing. Look for the keywords best performance, lowest latency, multiple regions then go for latency based routing. Now let's look at health checks and failover. Route 53 can monitor the health of your endpoints and automatically failover if one becomes unhealthy. How does this work? Route 53 sends health check request to your application. If the application responds successfully then it's healthy. If it fails to respond that's time out an eventual error, it's unhealthy. Route 53 stops routing traffic to the unhealthy endpoint. For a real well example you have latency based routing to US East 1 and EU West 1. A user in New York normally routes to US East 1 which is closer. But then US East 1 has an outage. Route 53 health checks and detects this failure and then route 53 automatically routes the New York user to EU West 1 instead. It would be higher latency slightly but the application still stays available and online. For an exam question an application is deployed in multiple regions with latency based routing. How can the company ensure traffic is not routed to a failed region? The answer is to configure Route 53 health checks for each region. Route 53 will automatically stop routing to the unhealthy regions. Alright now let's talk about the most common exam traps for AWS global infrastructure. Please pay close attention because these trip people are constantly. For drop one region selection that's compliance, trumps everything. Question a company wants to minimize costs and has no regulatory requirements. They serve global customers equally which region should they choose. People think global customers are probably multiple regions but read carefully no regulatory requirements and minimize costs. So the answer is choose one region with the lowest pricing use cloud front for global content delivery. They're trying to trick you into over engineering. Single region with cloud front is much cheaper than multi region deployment. However if the question mentions compliance or data residency, example like a healthcare company in Germany must comply with GDPR where should they store patient data. Then the answer is EU central one or EU west one which is the European regions. Compliance requirements, override cost and latency considerations. Now for drop two, EBS volumes and availability zones. Question an application needs to share data between EC2 instances in US East 1A and US East 1B. Can they use the same EBS volume? People think it's the same region. So yes wrong. EBS volumes are easy specific. Remember that. So the answer is no. EBS volumes cannot be shared across AZs. Use EFS which is elastic file system instead of cross AZ file sharing or copy data using S3. This comes up in multiple forms on the exam. So memorize it please. EBS is easy locked. Now for trap three. Edge locations for compute. Question to reduce latency for users in token. should the company deploy EC2 instances at the Tokyo Edge location. People think Edge locations are closer to the user so yes wrong. Edge location don't support compute services so the answer is no. Edge locations only support cloud front which is content caching and route 53 which is DNS. Deploy EC2 instances in the AP North East one region which is the Tokyo region not an edge location. Now to trap for S3 and regions question S3 buckets automatically replicate data across regions for durability is this true or false people think S3 is highly durable so probably true wrong S3 buckets are regional the answer is false S3 automatically replicates within a region across multiple AZs but not across regions for cross region replication you must explicitly enable S3 cross region replication which is CRR. Trap 5 multi-AZ for everything the question is an application requires 99.5% availability should it be deployed across multiple regions people think high availability means multiple regions wrong read the requirements carefully 99.5% is only about 3.65 days of downtime per year so the answer is no multiple AZs within a region can achieve in fact 99.99% availability since 52 minutes downtime per year multiple regions are only needed for high availability or disaster recovery across region failures multi-region is more expensive and complex to not over engineer let's look at trap 6 cloud front origin question is can cloud front use an EC2 instance as an origin people think cloud front is only for S3 which is wrong cloud front can use multiple origin types so the answer is yes cloud front can use S3 buckets EC2 instances elastic load balances or on premises service with custom origins any HTTP HCTPS endpoints can be a cloud front origin in fact trap 7 latency based routing and geographical locations question a company uses latency based routing to direct users to the nearest region users in Germany are routed to us east one instead of us one why people think this must be broken Germany's in Europe not necessarily wrong latency based routing is based on actual measured latency not geographical distance so the answer is if the network path from Germany to us east one happens to have a lower latency than to us one this could be maybe due to routing or congestion then route 53 will route to us east one this is working as designed for the exam latency based routing uses actual latency measurements not just geographic pro now on to trap 8 I am is global the question is and I am user created in us east one can only access resources in us east one true or false people think it makes sense user created in a region wrong I am is a global service remember that so the answers false I am users roles and policies are truly global and I am user can access resources in any region as long as they have permissions for those resources remember I am route 53 cloud front and W a F are global services everything else is regional crop 9 RDS multi a Z versus read replicas question a company needs to improve read performance for a database should they enable RDS multi a Z people think multi a Z means more availability so it should help performance wrong multi a Z is for availability not performance the answer is no RDS multi a Z only improves availability that's for failover for read performance use read replicas multi a Z remember is for synchronous replication to standby for failure it cannot read from standby read replicas on the other hand is asynchronous replication to read only copies and it can read from replicas exam loves testing this distinction trap 10 minimum a Z's per region question is how many availability zones does each AWS region have people think it probably varies right correct but there's a minimum the answer is each region has at least three a Z's most have three some have up to six for the exam minimum of three a Z's per region would be the answer on to trap 11 region names are not consistent question which region code represents Tokyo options are AP Northeast one AP East one or AP Tokyo one people think probably AP Tokyo one since Sydney is AP South East to wrong region naming isn't consistent so the answer AP Northeast one is Tokyo there is no AP Tokyo one don't worry for the exam you don't need to memorize all region codes but know the major ones that is US East one which is North Virginia primarily US region US West to Reagan EU West one which is Ireland AP Southeast one which is Singapore and AP Northeast one Tokyo on to trap 12 S3 transfer acceleration versus cloud front question accompany needs to speed up uploads to S3 from worldwide locations should they use cloud front people think cloud front speeds things up globally that is wrong cloud front is for downloads content delivery not uploads so the answer is no use S3 transfer acceleration for faster uploads cloud front is for faster downloads so transfer acceleration uploads to use edge locations to upload faster cloud front on the other hand downloads using cash content at edge locations for faster downloads okay now then let's come to the final wrap up here with some rapid fire examples tip one region decision framework if the question asks about compliance or regulations then a specific region is required if there's no compliance choose based on latency to use us if multiple regions are required consider service availability if it's cost sensitive then check regional pricing tip to multi-az is the default for production unless the question explicitly says development or test or mentions cost constraints always recommend multi-az deployment for production workloads tip number three keywords for cloud front global users static content image or videos slow downloads always use cloud front tip number four keywords for multi-region disaster recovery region failure global active compliance in multiple countries you want to go for multi-region architecture tip five remember EBS is easy locked EBS volumes cannot span multiple ases to move if you take a snapshot copy and restore that in the target is you would like to tip number six latency based routing for performance route users to the nearest region lowest latency best performance use route 53 latency based routing tip seven S3 is regional not global S3 buckets belong to a particular region for cross region replication you must configure it explicitly tip number eight edge locations for caching only cannot run compute workloads at edge locations only you can run cloud front route 53 and global accelerator tip number nine multi-az versus read replicas multi-az provides availability which is for failover scenarios read replicas in the other hand is for performance that is read scaling all right everyone that's episode four AWS global infrastructure let's quickly recap what we have covered we started with the big picture of AWS global infrastructure that's regions ases and edge locations we dove deep into regions how to choose them based on compliance latency service availability and pricing we explored availability zones why multi-az is critical for high availability and how to design resilient architectures we covered edge locations and cloud front how to deliver content globally with low latency we walked through global architecture patterns single region multi-az active passive disaster recovery active active multi-region and cloud front hybrid approaches we discussed route 53 and latency based routing for intelligent traffic management and we covered 12 critical exam traps that trip people up constantly the key takeaway understanding AWS global infrastructure isn't just about memorizing facts it's about knowing how to design architecture that is highly available for provides low latency and cost effective for your specific requirement. When you see a question on the exam about global deployment, you ask yourself, what are the compliance requirements? Where are the users located? What's the availability requirement and what's the budget? Then choose the right combination of the regions, AZs and edge locations. So in our next episode, we will be doing a deep dive on elastic load balancer and then again discussing about exam traps and real world examples. If this episode helps you understand AWS Global Infrastructure, leave a review on Spotify. It helps other exam candidates find the series. So until next time, keep studying, keep practicing and I will see you in the next episode. This is Palo signing off. Bye.