WEBVTT 00:00:00.000 --> 00:00:02.600 Welcome to the deep dive. You know, whenever 00:00:02.600 --> 00:00:05.040 we talk about the cloud, it's easy to picture 00:00:05.040 --> 00:00:07.379 this sort of abstract limitless thing floating 00:00:07.379 --> 00:00:10.539 around. But the reality, which I find much more 00:00:10.539 --> 00:00:13.560 interesting actually, is that the cloud is intensely 00:00:13.560 --> 00:00:15.859 physical. It's this living, breathing network 00:00:15.859 --> 00:00:19.460 of actual fiber optic cables, massive buildings, 00:00:20.339 --> 00:00:23.640 data centers, hardware, spanning the entire globe. 00:00:23.879 --> 00:00:26.420 It's what powers pretty much every big digital 00:00:26.420 --> 00:00:28.739 thing we use. It really is a paradox, isn't it? 00:00:28.820 --> 00:00:31.019 The cloud feels like it's everywhere and nowhere 00:00:31.019 --> 00:00:33.740 at the same time, but its feet are firmly planted 00:00:33.740 --> 00:00:36.240 in specific geographical spots, and that's what 00:00:36.240 --> 00:00:39.159 we're diving into today, the AWS global infrastructure. 00:00:39.780 --> 00:00:41.600 We're drawing from guides specifically designed 00:00:41.600 --> 00:00:43.439 for people learning about cloud foundations, 00:00:43.439 --> 00:00:45.859 so it gives us a really solid map. Yeah, and 00:00:45.859 --> 00:00:47.140 our mission here is pretty straightforward. We 00:00:47.140 --> 00:00:49.539 want to take you on a guided tour of this enormous 00:00:49.539 --> 00:00:51.320 global footprint. We need to get our heads around 00:00:51.320 --> 00:00:54.560 how AWS uses physical geography, turns it into 00:00:54.560 --> 00:00:57.280 a real strategic tool to give us the speed, the 00:00:57.280 --> 00:01:01.179 reliability, and the resilience that modern applications 00:01:01.179 --> 00:01:03.979 absolutely demand everywhere. Exactly. And look, 00:01:04.099 --> 00:01:06.500 this isn't just about learning names. It's fundamental. 00:01:06.599 --> 00:01:08.879 If you're building anything serious in the cloud, 00:01:09.239 --> 00:01:12.659 understanding this physical layout is, well, 00:01:12.739 --> 00:01:14.659 it's non -negotiable. OK, so let's start right 00:01:14.659 --> 00:01:17.900 at the top. Why does a company like AWS invest 00:01:18.140 --> 00:01:21.239 I mean, billions and billions of dollars into 00:01:21.239 --> 00:01:24.239 building out this huge complex physical network 00:01:24.239 --> 00:01:27.340 across the planet. What's the main driver? Fundamentally, 00:01:27.519 --> 00:01:29.879 it really boils down to controlling three key 00:01:29.879 --> 00:01:33.340 things for anyone using the cloud. Performance, 00:01:33.719 --> 00:01:36.299 availability, and crucially, legal compliance, 00:01:37.040 --> 00:01:39.459 where your resources, your compute, your data 00:01:39.459 --> 00:01:42.019 actually live, physically dictates how well you 00:01:42.019 --> 00:01:43.920 can deliver on those three. Right. And those 00:01:43.920 --> 00:01:46.400 are the big three worries for any developer architect, 00:01:46.439 --> 00:01:48.459 aren't they? You have the most elegant code, 00:01:48.700 --> 00:01:51.980 but if it's slow for users in, say, Europe, or 00:01:51.980 --> 00:01:54.780 if it suddenly goes offline, or maybe even worse, 00:01:54.939 --> 00:01:57.560 if you accidentally violate some local data privacy 00:01:57.560 --> 00:02:01.000 law, then the whole thing's a bust. Precisely. 00:02:01.340 --> 00:02:03.480 Let's take an example. Imagine you're building, 00:02:03.540 --> 00:02:05.319 I don't know, a new streaming app. You've got 00:02:05.319 --> 00:02:08.139 users in Tokyo, users in Sao Paulo, users in 00:02:08.139 --> 00:02:10.639 Toronto. You absolutely need the videos to start 00:02:10.639 --> 00:02:13.159 playing almost instantly. That's low latency. 00:02:13.659 --> 00:02:15.780 You also need it to keep working even if there's 00:02:15.780 --> 00:02:18.120 a major power outage in one of those cities. 00:02:18.539 --> 00:02:21.460 That's high availability. And critically important 00:02:21.460 --> 00:02:23.860 these days, you have to make sure that customer 00:02:23.860 --> 00:02:27.789 data from, say, Germany stays in Germany, or 00:02:27.789 --> 00:02:30.550 at least within the EU, to comply with laws like 00:02:30.550 --> 00:02:33.750 GDPR, that's the compliance piece, or data sovereignty. 00:02:34.030 --> 00:02:36.770 Ah, OK. So choosing where you put your stuff, 00:02:36.870 --> 00:02:39.870 which AWS region you use, it's not just a technical 00:02:39.870 --> 00:02:42.789 decision about speed. It's also a legal and strategic 00:02:42.789 --> 00:02:44.830 one. Yeah. That really changes how you have to 00:02:44.830 --> 00:02:46.750 think about designing things. It absolutely does. 00:02:46.770 --> 00:02:48.870 That's the key takeaway here. You need to understand 00:02:48.870 --> 00:02:51.069 this infrastructure map to build architectures 00:02:51.069 --> 00:02:53.430 that can genuinely operate globally but still 00:02:53.430 --> 00:02:56.409 feel local, perform locally. and critically comply 00:02:56.409 --> 00:03:00.030 locally. Okay, got it. So let's unpack the actual 00:03:00.030 --> 00:03:02.889 components then. If we were to draw a map of 00:03:02.889 --> 00:03:06.229 the AWS world, what are the main physical building 00:03:06.229 --> 00:03:08.469 blocks? Let's start with the biggest one, the 00:03:08.469 --> 00:03:12.169 region. Right. A region is basically a distinct 00:03:12.169 --> 00:03:14.689 geographic area, think Northern Virginia, or 00:03:14.689 --> 00:03:18.030 Ireland, or Tokyo. Within that area, AWS sets 00:03:18.030 --> 00:03:21.270 up multiple data centers. Crucially, each region 00:03:21.270 --> 00:03:23.870 is designed to be completely isolated and independent 00:03:23.870 --> 00:03:26.110 from other regions. Separate power, separate 00:03:26.110 --> 00:03:28.770 networking, everything. Totally self -contained 00:03:28.770 --> 00:03:31.590 for fault tolerance. So when I choose, say, US 00:03:31.590 --> 00:03:34.189 East 1 in Northern Virginia, I'm picking that 00:03:34.189 --> 00:03:36.610 specific geographic cluster. And I'd pick it 00:03:36.610 --> 00:03:39.469 based on Well, those factors you mentioned. Approximately 00:03:39.469 --> 00:03:42.009 to my users, maybe sufficient compliance needs. 00:03:42.289 --> 00:03:45.030 Exactly that. Latency to your end users is often 00:03:45.030 --> 00:03:47.430 the primary driver, but sometimes data sovereignty 00:03:47.430 --> 00:03:49.389 rules dictate your choice. You have to be in 00:03:49.389 --> 00:03:51.229 Frankfurt for certain German data, for instance. 00:03:51.729 --> 00:03:53.650 Okay, so regions of the big geographic zones. 00:03:53.870 --> 00:03:55.530 Now, inside each region, you mentioned clusters 00:03:55.530 --> 00:03:57.229 of data centers. That brings us to availability 00:03:57.229 --> 00:04:00.250 zones or AZs. These sound important for reliability. 00:04:00.460 --> 00:04:03.099 They are the key to high availability. An AZ 00:04:03.099 --> 00:04:05.580 is essentially one or more discrete physical 00:04:05.580 --> 00:04:08.300 data centers within a region. Each one has its 00:04:08.300 --> 00:04:10.979 own redundant power, cooling, networking the 00:04:10.979 --> 00:04:14.199 works. Most regions have at least three AZs. 00:04:14.439 --> 00:04:17.759 And here's the clever bit. These AZs are physically 00:04:17.759 --> 00:04:20.819 separate. often by miles, so a fire or a flood 00:04:20.819 --> 00:04:23.120 at one won't take out another. But they're linked 00:04:23.120 --> 00:04:26.319 together with really fast, private, low -latency 00:04:26.319 --> 00:04:29.339 fiber optic connections. Ah, OK. So they're separate 00:04:29.339 --> 00:04:31.480 enough to be safe from each other, physically, 00:04:31.860 --> 00:04:34.500 but connected so closely network -wise that they 00:04:34.500 --> 00:04:36.779 can almost act like one logical data center for 00:04:36.779 --> 00:04:39.019 my application. That's the magic, precisely. 00:04:39.180 --> 00:04:41.759 You design your application to run across multiple 00:04:41.759 --> 00:04:44.259 AZs within that region. If something catastrophic 00:04:44.259 --> 00:04:47.519 happens, say a whole AZ loses power, your application 00:04:47.660 --> 00:04:49.800 and the other AZs just keep running and take 00:04:49.800 --> 00:04:52.220 over the load, ideally without users even noticing. 00:04:52.420 --> 00:04:55.399 That's the goal, seamless failover. Okay, regions 00:04:55.399 --> 00:04:57.839 and AZs give us that core redundancy and geographic 00:04:57.839 --> 00:05:00.300 placement. But what about getting data really, 00:05:00.300 --> 00:05:02.779 really fast to the end user, that last mile problem? 00:05:03.060 --> 00:05:04.579 That's where the edge comes in, right? It started 00:05:04.579 --> 00:05:07.560 with edge locations. Correct. Edge locations 00:05:07.560 --> 00:05:10.139 are a different beast. Think of them as smaller, 00:05:10.180 --> 00:05:12.660 more numerous points of presence scattered all 00:05:12.660 --> 00:05:15.899 over the world. AWS has, I think, over 400 of 00:05:15.899 --> 00:05:19.300 them now. job is to cache content closer to users. 00:05:19.879 --> 00:05:21.899 Services like Amazon CloudFront, the Content 00:05:21.899 --> 00:05:25.279 Delivery Network, or CDN use these edge locations. 00:05:25.779 --> 00:05:28.839 So CloudFront puts copies of my website's images, 00:05:29.120 --> 00:05:31.660 videos, JavaScript files, things like that, into 00:05:31.660 --> 00:05:34.279 these edge locations. Exactly. So when a user 00:05:34.279 --> 00:05:36.759 in, say, Sydney requests an image, they get it 00:05:36.759 --> 00:05:39.180 from a nearby edge location in Australia, not 00:05:39.180 --> 00:05:41.220 all the way from your main server, maybe in the 00:05:41.220 --> 00:05:43.910 US or Europe. much faster. OK, that makes sense 00:05:43.910 --> 00:05:46.009 for static stuff that can be cached. But some 00:05:46.009 --> 00:05:48.430 applications need low latency for dynamic data, 00:05:48.589 --> 00:05:50.470 things that change all the time. This leads us 00:05:50.470 --> 00:05:52.689 to local zones, right? Something more specialized. 00:05:52.990 --> 00:05:55.790 Yes. Local zones are an extension of an AWS region, 00:05:55.930 --> 00:05:59.009 but they push core AWS services like compute, 00:05:59.310 --> 00:06:02.430 storage, database into specific large metropolitan 00:06:02.430 --> 00:06:05.089 areas much closer to end users than the main 00:06:05.089 --> 00:06:07.370 regional AZs might be. So they're for things 00:06:07.370 --> 00:06:10.420 like. Maybe real -time gaming servers or video 00:06:10.420 --> 00:06:13.540 editing in the cloud or live analytics dashboards 00:06:13.540 --> 00:06:16.279 where every millisecond counts. Perfect examples. 00:06:16.620 --> 00:06:19.000 Anything super latency sensitive where you need 00:06:19.000 --> 00:06:21.540 compute power really close to a specific city 00:06:21.540 --> 00:06:25.160 or business hub benefits from local zones. And 00:06:25.160 --> 00:06:27.560 pushing that latency boundary even further, especially 00:06:27.560 --> 00:06:30.899 with mobile tech, we get wavelength zones. This 00:06:30.899 --> 00:06:33.220 sounds like it's tied directly into 5G networks. 00:06:33.420 --> 00:06:36.339 It absolutely is. Wavelength zones embed AWS 00:06:36.339 --> 00:06:39.100 compute and storage directly inside the telecommunications 00:06:39.100 --> 00:06:42.379 provider's 5G network data centers. This is for 00:06:42.379 --> 00:06:45.319 ultra -low latency use cases, think single -digit 00:06:45.319 --> 00:06:47.680 milliseconds, needed for things like real -time 00:06:47.680 --> 00:06:51.300 AI inference on video streams, complex AR -VR, 00:06:51.660 --> 00:06:53.959 maybe even controlling autonomous vehicles over 00:06:53.959 --> 00:06:55.699 the 5G network. It's right at the edge of the 00:06:55.699 --> 00:06:58.139 mobile network. Wow, okay. That's quite a spectrum 00:06:58.139 --> 00:07:00.180 from region down to wavelength. But there's one 00:07:00.180 --> 00:07:01.699 more type of infrastructure that sort of goes 00:07:01.699 --> 00:07:03.920 the other way, bringing the cloud back to the 00:07:03.920 --> 00:07:06.449 customer's own building. Outposts. What's the 00:07:06.449 --> 00:07:08.730 deal there? Yeah, outposts are interesting. It's 00:07:08.730 --> 00:07:11.410 basically AWS designed hardware racks of servers 00:07:11.410 --> 00:07:13.990 and storage that AWS installs and manages in 00:07:13.990 --> 00:07:16.189 your own data center or co -location facility. 00:07:16.689 --> 00:07:19.970 It runs the same AWS services, APIs, and tools, 00:07:20.089 --> 00:07:24.209 but physically on your premises. But hang on. 00:07:24.449 --> 00:07:27.209 If it's on my premises, doesn't that defeat the 00:07:27.209 --> 00:07:30.110 purpose of the cloud, like the elasticity and 00:07:30.110 --> 00:07:32.009 not managing hardware? Why would someone do that? 00:07:32.209 --> 00:07:34.339 Great question. It seems counterintuitive, but 00:07:34.339 --> 00:07:37.279 it solves specific problems. The main drivers 00:07:37.279 --> 00:07:39.540 are usually ultra -low latency requirements where 00:07:39.540 --> 00:07:41.920 data processing has to happen locally, maybe 00:07:41.920 --> 00:07:44.639 controlling factory equipment, or, very commonly, 00:07:45.160 --> 00:07:47.699 data residency roles where certain data absolutely 00:07:47.699 --> 00:07:49.779 cannot leave the customer's physical site for 00:07:49.779 --> 00:07:52.660 regulatory or policy reasons. Outposts let them 00:07:52.660 --> 00:07:55.040 use AWS tools while keeping the data physically 00:07:55.040 --> 00:07:57.620 locked down. It's for those hybrid cloud scenarios. 00:07:57.860 --> 00:07:59.920 OK, that makes sense, like a bridge for specific 00:07:59.920 --> 00:08:02.120 needs. So looking at this whole picture, what 00:08:02.120 --> 00:08:05.379 is it? 32 regions now, over 100 AZs, hundreds 00:08:05.379 --> 00:08:09.000 of edge locations. The scale is just immense. 00:08:09.160 --> 00:08:11.220 It is staggering. And that scale, that physical 00:08:11.220 --> 00:08:13.120 distribution, is what lets you architect for 00:08:13.120 --> 00:08:15.540 both performance and serious resilience, like 00:08:15.540 --> 00:08:18.120 disaster recovery across continents, while still 00:08:18.120 --> 00:08:19.920 being able to choose exactly where your data 00:08:19.920 --> 00:08:21.870 lives for compliance. Right, and this is where 00:08:21.870 --> 00:08:24.009 it gets really powerful, I think. It's not just 00:08:24.009 --> 00:08:26.589 having the physical locations. It's the services 00:08:26.589 --> 00:08:29.509 AWS builds on top to intelligently use that network. 00:08:29.790 --> 00:08:32.370 You don't just build roads. You need smart traffic 00:08:32.370 --> 00:08:34.750 control. Let's talk about a few key ones, starting 00:08:34.750 --> 00:08:39.090 with Amazon Route 53. Route 53 is AWS's DNS service 00:08:39.090 --> 00:08:41.740 domain name system. Think of it as the Internet's 00:08:41.740 --> 00:08:44.419 phone book, but way smarter. It translates human 00:08:44.419 --> 00:08:48.220 -readable domain names like www .example .com 00:08:48.220 --> 00:08:51.120 into the IP addresses computers use. But its 00:08:51.120 --> 00:08:54.000 real power lies in its routing policies. It can 00:08:54.000 --> 00:08:55.899 direct users to different backend resources, 00:08:56.139 --> 00:08:58.480 could be servers, could be load balancers, anything 00:08:58.480 --> 00:09:01.080 based on various criteria. What are some of those 00:09:01.080 --> 00:09:03.279 key routing policies? You mentioned latency earlier. 00:09:03.460 --> 00:09:06.720 Yes, latency -based routing is huge. Route 53 00:09:06.720 --> 00:09:09.039 can figure out which AWS region will give the 00:09:09.039 --> 00:09:11.519 lowest network latency for that specific user 00:09:11.519 --> 00:09:14.080 making the request and send them there automatically. 00:09:14.559 --> 00:09:16.700 Super important for global performance. Another 00:09:16.700 --> 00:09:19.120 critical one is failover routing. You set up 00:09:19.120 --> 00:09:21.759 a primary endpoint and a secondary backup endpoint. 00:09:22.179 --> 00:09:24.320 Route 53 constantly runs health checks on the 00:09:24.320 --> 00:09:26.960 primary if it becomes unhealthy. It automatically 00:09:26.960 --> 00:09:29.480 redirects all the traffic to the backup endpoint 00:09:29.480 --> 00:09:32.860 in another region or AZ. Exactly. Seamlessly 00:09:32.860 --> 00:09:36.100 handles failures. Essential for resilience. Makes 00:09:36.100 --> 00:09:39.139 sense. OK, next up, we mentioned Amazon CloudFront 00:09:39.139 --> 00:09:41.899 earlier, the CDN. Right. So CloudFront, as we 00:09:41.899 --> 00:09:44.600 said, uses that big global network of edge locations. 00:09:44.860 --> 00:09:47.740 Its whole job is to cache your static content 00:09:47.740 --> 00:09:50.740 images, videos, CSS files. physically close to 00:09:50.740 --> 00:09:53.860 your users. This drastically cuts down load times 00:09:53.860 --> 00:09:56.100 for that content because the data travels a much 00:09:56.100 --> 00:09:58.320 shorter distance. It works hand in glove with 00:09:58.320 --> 00:10:01.539 storage like S3 or compute like EC2 where the 00:10:01.539 --> 00:10:03.820 original content lives. Got it. Faster static 00:10:03.820 --> 00:10:06.240 content delivery. Now, what if you need better 00:10:06.240 --> 00:10:08.679 performance for dynamic traffic, stuff that can't 00:10:08.679 --> 00:10:11.019 be cached, and you want to avoid the unpredictable 00:10:11.019 --> 00:10:13.200 nature of the public internet? That's where AWS 00:10:13.200 --> 00:10:16.330 Global Accelerator comes in. Precisely. Global 00:10:16.330 --> 00:10:18.450 Accelerator tackles the middle mile problem. 00:10:18.610 --> 00:10:21.029 When a user connects, instead of their traffic 00:10:21.029 --> 00:10:23.769 hopping across the regular public internet, Global 00:10:23.769 --> 00:10:26.789 Accelerator provides static IP addresses that 00:10:26.789 --> 00:10:29.990 act as an entry point onto the AWS private global 00:10:29.990 --> 00:10:32.710 network backbone. It then routes the traffic 00:10:32.710 --> 00:10:36.250 over AWS's optimized, reliable, high bandwidth 00:10:36.250 --> 00:10:38.850 network directly to the best endpoint region 00:10:38.850 --> 00:10:41.470 for your application. It bypasses a lot of the 00:10:41.470 --> 00:10:43.850 congestion and variability of the public internet. 00:10:44.110 --> 00:10:46.110 So it's like getting onto a private high -speed 00:10:46.110 --> 00:10:48.830 highway instead of local roads. Ideal for things 00:10:48.830 --> 00:10:51.830 needing consistent performance, like video conferencing, 00:10:52.190 --> 00:10:54.769 maybe financial trading, online gaming. Exactly. 00:10:54.830 --> 00:10:56.909 Those kinds of real -time latency -sensitive 00:10:56.909 --> 00:10:59.830 applications benefit massively. It improves both 00:10:59.830 --> 00:11:02.149 performance and availability by using that controlled 00:11:02.149 --> 00:11:04.690 AWS network path. And quickly, there's also S3 00:11:04.690 --> 00:11:06.649 transfer acceleration, which just leverages the 00:11:06.649 --> 00:11:09.269 edge locations to speed up file uploads and downloads 00:11:09.269 --> 00:11:11.769 to S3 buckets, right? Yep. Another smart use 00:11:11.769 --> 00:11:14.259 of the existing edge network. specifically for 00:11:14.259 --> 00:11:17.000 accelerating large data transfers into and out 00:11:17.000 --> 00:11:20.519 of S3 storage. Now, if we tie all this infrastructure 00:11:20.519 --> 00:11:25.360 back to business continuity, this global footprint 00:11:25.360 --> 00:11:28.519 is the foundation for robust disaster recovery 00:11:28.519 --> 00:11:31.960 or dire UDECL. Being able to operate in multiple 00:11:31.960 --> 00:11:34.919 places is how you survive major outages. Right. 00:11:35.120 --> 00:11:37.879 And AWS documentation usually outlines four main 00:11:37.879 --> 00:11:40.120 DR strategies, kind of escalating in complexity 00:11:40.120 --> 00:11:42.820 and cost that use this infrastructure. Can you 00:11:42.820 --> 00:11:45.059 walk us through those? Sure. The simplest is 00:11:45.059 --> 00:11:47.460 backup and restore. Basically, you just regularly 00:11:47.460 --> 00:11:49.519 backup your data, maybe your databases and files, 00:11:49.659 --> 00:11:52.379 to another AWS region. If your primary region 00:11:52.379 --> 00:11:54.379 goes down, you restore that data in the secondary 00:11:54.379 --> 00:11:56.590 region and start services there. OK, so that's 00:11:56.590 --> 00:11:58.509 relatively cheap. It could take hours, maybe 00:11:58.509 --> 00:12:00.950 longer, to get back online, right? The recovery 00:12:00.950 --> 00:12:03.490 time objective, or RTO, is high. Correct. It's 00:12:03.490 --> 00:12:06.669 the lowest cost, but slowest recovery. Stepping 00:12:06.669 --> 00:12:09.289 up, you have pilot light. Here, you have the 00:12:09.289 --> 00:12:11.950 core infrastructure, maybe just the databases 00:12:11.950 --> 00:12:14.769 replicated, and a minimal set of application 00:12:14.769 --> 00:12:17.590 servers running idle or very scaled down in the 00:12:17.590 --> 00:12:21.029 secondary region. If disaster strikes, you ignite 00:12:21.029 --> 00:12:23.970 the pilot light. Scale up the servers, switch 00:12:23.970 --> 00:12:27.309 DNS, and bring the application fully online there. 00:12:27.470 --> 00:12:29.710 Faster than backup restore, but costs a bit more 00:12:29.710 --> 00:12:32.070 because some resources are always running. Okay. 00:12:32.409 --> 00:12:35.029 Faster recovery. Then comes warm standby. Right. 00:12:35.309 --> 00:12:37.649 Warm standby means you have a scaled down but 00:12:37.649 --> 00:12:39.350 fully functional version of your application 00:12:39.350 --> 00:12:41.909 already running in the secondary region. Maybe 00:12:41.909 --> 00:12:43.789 it's handling a small fraction of live traffic 00:12:43.789 --> 00:12:46.250 or just ready to scale up very quickly. Recovery 00:12:46.250 --> 00:12:48.970 is much faster here, maybe minutes. But obviously 00:12:48.970 --> 00:12:51.090 it costs more because you're running a more significant 00:12:51.090 --> 00:12:53.730 chunk of your infrastructure 247 in that standby 00:12:53.730 --> 00:12:55.919 region. And the ultimate level. That's multi 00:12:55.919 --> 00:12:58.059 -site active -active. Here, you're running your 00:12:58.059 --> 00:13:00.779 full application at full scale simultaneously 00:13:00.779 --> 00:13:03.740 in multiple regions. Traffic is distributed across 00:13:03.740 --> 00:13:06.519 all of them all the time. If one region fails, 00:13:06.840 --> 00:13:08.759 the others just absorb its share of the load. 00:13:09.299 --> 00:13:11.500 This gives you near zero downtime, potentially 00:13:11.500 --> 00:13:14.940 zero data loss, but it's the most complex to 00:13:14.940 --> 00:13:17.139 build and operate, and usually the most expensive. 00:13:17.360 --> 00:13:19.740 That makes sense. A clear trade -off between 00:13:19.740 --> 00:13:22.700 cost, complexity, and recovery speed. And speaking 00:13:22.700 --> 00:13:25.720 of cost, that's a crucial point with global infrastructure, 00:13:25.940 --> 00:13:28.559 isn't it? Moving data around isn't always free. 00:13:28.940 --> 00:13:31.460 Definitely not. It's a major design consideration. 00:13:31.899 --> 00:13:34.149 The general rule of thumb is... data transfer 00:13:34.149 --> 00:13:37.250 within a single AWS region, like between AZs, 00:13:37.370 --> 00:13:40.490 is often free or very cheap. However, data transfer 00:13:40.490 --> 00:13:42.509 between different regions, say from the US to 00:13:42.509 --> 00:13:44.990 Europe, almost always incur significant costs. 00:13:45.330 --> 00:13:47.830 You pay for data going out of a region. So that 00:13:47.830 --> 00:13:50.070 strongly encourages you to design for high availability 00:13:50.070 --> 00:13:53.190 within a region first, using multiple AZs, before 00:13:53.190 --> 00:13:55.110 going multi -region, just from a cost perspective. 00:13:55.309 --> 00:13:57.669 Exactly. And services like CloudFront and Global 00:13:57.669 --> 00:13:59.669 Accelerator also have their own pricing, usually 00:13:59.669 --> 00:14:01.690 based on data transferred out from the edge or 00:14:01.690 --> 00:14:03.480 through the accelerator. need to model those 00:14:03.480 --> 00:14:06.940 costs. Okay. And managing all this complexity 00:14:06.940 --> 00:14:11.200 across potentially dozens of regions, you can't 00:14:11.200 --> 00:14:13.450 do that manually. Thankfully, there are tools. 00:14:13.950 --> 00:14:16.610 What are the key ones for managing global deployments 00:14:16.610 --> 00:14:18.730 consistently? Oh, yeah, you'd absolutely need 00:14:18.730 --> 00:14:21.389 automation. Three key services come to mind. 00:14:21.549 --> 00:14:24.710 First, AWS Organizations. This lets you group 00:14:24.710 --> 00:14:27.710 multiple AWS accounts together. You can centralize 00:14:27.710 --> 00:14:29.610 billing, which is nice, but more importantly, 00:14:29.730 --> 00:14:31.830 you can apply governance policies called Service 00:14:31.830 --> 00:14:34.889 Control Policies, or SCPs, across all accounts. 00:14:35.389 --> 00:14:37.529 Think of them as guardrails ensuring compliance, 00:14:37.750 --> 00:14:39.690 like preventing users from launching resources 00:14:39.690 --> 00:14:41.909 in unapproved regions. Essential for control. 00:14:42.059 --> 00:14:44.500 than for actually deploying infrastructure consistently. 00:14:44.860 --> 00:14:47.960 That's where AWS CloudFormation comes in. It's 00:14:47.960 --> 00:14:51.080 infrastructure as code, or IAC. You define your 00:14:51.080 --> 00:14:53.919 entire environment's servers, databases, networks, 00:14:54.460 --> 00:14:56.740 everything in a template file. You can then use 00:14:56.740 --> 00:14:59.220 that same template to reliably and repeatedly 00:14:59.220 --> 00:15:02.019 deploy the exact same setup in any region you 00:15:02.019 --> 00:15:04.799 choose. It guarantees consistency, which is vital 00:15:04.799 --> 00:15:07.460 for global operations and auditing. your blueprint 00:15:07.460 --> 00:15:09.820 for the cloud. And finally, how do you keep an 00:15:09.820 --> 00:15:11.840 eye on everything once it's running everywhere? 00:15:12.480 --> 00:15:15.120 For operational visibility and management, AWS 00:15:15.120 --> 00:15:17.600 Systems Manager is key. It gives you a single 00:15:17.600 --> 00:15:20.159 pane of glass, a unified interface. From one 00:15:20.159 --> 00:15:22.059 place, you can see resources across different 00:15:22.059 --> 00:15:24.139 regions and accounts, automate patching, run 00:15:24.139 --> 00:15:26.399 commands, troubleshoot issues. It really helps 00:15:26.399 --> 00:15:29.139 manage that sprawl. Excellent. OK, so let's try 00:15:29.139 --> 00:15:31.039 and quickly recap the absolute must -knows from 00:15:31.039 --> 00:15:33.960 our deep dive today. For you listening, we defined 00:15:33.960 --> 00:15:36.539 those core infrastructure building blocks. The 00:15:36.539 --> 00:15:38.639 big regions, the fault tolerant availability 00:15:38.639 --> 00:15:41.519 zones within them, the content caching edge locations, 00:15:41.980 --> 00:15:44.500 the metro area local zones, and the ultra -low 00:15:44.500 --> 00:15:47.320 latency wavelength zones, plus the on -premises 00:15:47.320 --> 00:15:50.100 outposts. Understanding that hierarchy is key. 00:15:50.659 --> 00:15:52.799 And we highlighted three critical services that 00:15:52.799 --> 00:15:55.659 leverage this global network. Route 53 for intelligent 00:15:55.659 --> 00:15:58.659 DNS routing, CloudFront for fast CDN delivery 00:15:58.659 --> 00:16:01.580 via the edge, and AWS Global Accelerator for 00:16:01.580 --> 00:16:04.460 optimized routing over the AWS backbone. And 00:16:04.460 --> 00:16:06.120 pulling it all together, I think the big picture 00:16:06.120 --> 00:16:08.840 thought is this. AWS provides this incredible 00:16:08.840 --> 00:16:11.879 global infrastructure for scale and speed, especially 00:16:11.879 --> 00:16:14.259 pushing closer to users with local and wavelength 00:16:14.259 --> 00:16:17.299 zones. That drive for low latency is powerful, 00:16:17.600 --> 00:16:20.080 but the constant tension for anyone billing applications 00:16:20.080 --> 00:16:21.960 is balancing those speed benefits you get at 00:16:21.960 --> 00:16:23.740 the edge against the hard requirements of data 00:16:23.740 --> 00:16:25.980 sovereignty and local regulations, which often 00:16:25.980 --> 00:16:27.980 pull you back towards keeping data pinned within 00:16:27.980 --> 00:16:32.039 specific core regions. Yeah. So when technology 00:16:32.039 --> 00:16:34.289 pulls you towards the edge for speed, but the 00:16:34.289 --> 00:16:36.909 law forces data to stay central, what does that 00:16:36.909 --> 00:16:39.269 push and pull mean for how we design and build 00:16:39.269 --> 00:16:41.950 distributed systems in the future? That's definitely 00:16:41.950 --> 00:16:43.730 something interesting to chew on. Thank you for 00:16:43.730 --> 00:16:44.750 joining us on the deep dive.