WEBVTT 00:00:00.000 --> 00:00:02.819 If you're building anything significant in the 00:00:02.819 --> 00:00:04.580 cloud, you really care about two big things, 00:00:05.320 --> 00:00:08.179 security and speed. And often those two things 00:00:08.179 --> 00:00:10.439 meet, sometimes collide right there in the networking 00:00:10.439 --> 00:00:13.560 layer. So today we're doing a deep dive into, 00:00:13.560 --> 00:00:15.820 well, the core architecture of AWS networking 00:00:15.820 --> 00:00:18.239 and also content delivery. This is really the 00:00:18.239 --> 00:00:20.120 engine that lets your applications talk securely 00:00:20.120 --> 00:00:23.539 and globally. That's spot on. And our mission 00:00:23.539 --> 00:00:26.390 for you... the listener, is to really get beyond 00:00:26.390 --> 00:00:29.629 just memorizing terms. We want you to grasp the 00:00:29.629 --> 00:00:31.829 architectural choices, understand the thinking 00:00:31.829 --> 00:00:34.689 behind why these AWS services exist, how they 00:00:34.689 --> 00:00:37.149 let applications connect across the world, and 00:00:37.149 --> 00:00:39.509 really form the backbone for high -performance, 00:00:39.789 --> 00:00:42.250 solid cloud setups. Right. And we're tackling 00:00:42.250 --> 00:00:44.920 this in two main parts. First up... building 00:00:44.920 --> 00:00:47.960 that secure, isolated network foundation, your 00:00:47.960 --> 00:00:50.780 sort of digital plot of land. And then second, 00:00:51.159 --> 00:00:53.359 how do we take what's on that secure foundation 00:00:53.359 --> 00:00:56.780 and speed up its delivery like everywhere across 00:00:56.780 --> 00:01:00.619 the country? Starting with that foundation, the 00:01:00.619 --> 00:01:03.060 Canvas itself, we have to begin with the Amazon 00:01:03.060 --> 00:01:05.519 Virtual Private Cloud, the VPC. I mean, pretty 00:01:05.519 --> 00:01:08.400 much every AWS resource you launch ends up living 00:01:08.400 --> 00:01:10.519 inside one of these. It's really the cornerstone 00:01:10.519 --> 00:01:13.200 of your security posture because it's your own 00:01:13.200 --> 00:01:16.180 private, isolated network bubble within the bigger 00:01:16.180 --> 00:01:18.579 AWS cloud. Yeah, that's a great analogy. Think 00:01:18.579 --> 00:01:21.579 of the whole AWS region as maybe a giant apartment 00:01:21.579 --> 00:01:24.079 building, the VPC. That's your specific apartment. 00:01:24.420 --> 00:01:26.560 You've got the keys, you control who comes in. 00:01:26.780 --> 00:01:29.099 When you create a VPC, you define its IP address 00:01:29.099 --> 00:01:31.299 range. That's CIDR block. And that's your first 00:01:31.299 --> 00:01:34.200 big architectural decision. Say you choose a 00:01:34.200 --> 00:01:37.620 10 yellow 0 .016, that gives you over 65 ,000 00:01:37.620 --> 00:01:39.700 private addresses. Plenty, right. But you've 00:01:39.700 --> 00:01:41.140 got to make sure it doesn't clash with, say, 00:01:41.219 --> 00:01:43.459 your office network or maybe other VPCs you might 00:01:43.459 --> 00:01:45.280 want to connect later. It's all about planning 00:01:45.280 --> 00:01:47.879 your space carefully up front. OK, so we've carved 00:01:47.879 --> 00:01:50.379 out this big block of addresses. What's the next 00:01:50.379 --> 00:01:53.519 step for making things resilient? How do subnets 00:01:53.519 --> 00:01:56.099 fit in? subnets. They're absolutely critical 00:01:56.099 --> 00:01:59.200 because a subnet ties a specific range of those 00:01:59.200 --> 00:02:02.379 IP addresses to a single availability zone, an 00:02:02.379 --> 00:02:05.599 AZ. For high availability, and you always want 00:02:05.599 --> 00:02:07.859 that, you must spread your subnets across multiple 00:02:07.859 --> 00:02:11.560 AZs. That way, if one AZ has an issue, your resources 00:02:11.560 --> 00:02:13.800 in the subnets and other AZs just keep running. 00:02:14.459 --> 00:02:16.340 That's the core pattern for resilience right 00:02:16.340 --> 00:02:18.659 there. And we generally talk about three main 00:02:18.659 --> 00:02:20.680 types of subnets based on how they connect outwards. 00:02:20.740 --> 00:02:22.300 You've got your public subnet. That one uses 00:02:22.300 --> 00:02:24.379 an internet gateway, an IGW, to talk directly 00:02:24.379 --> 00:02:26.199 to the internet. Pretty straightforward. Then 00:02:26.199 --> 00:02:28.719 there's the private subnet. Now this one can 00:02:28.719 --> 00:02:30.520 initiate connections going out maybe for software 00:02:30.520 --> 00:02:32.479 updates, but the internet can't initiate connections 00:02:32.479 --> 00:02:35.930 in. And finally, the isolated subnet. completely 00:02:35.930 --> 00:02:39.750 cut off, no internet path in or out, perfect 00:02:39.750 --> 00:02:42.250 for really sensitive things like your core databases, 00:02:42.330 --> 00:02:44.849 maybe. And the root tables then act like the 00:02:44.849 --> 00:02:47.330 traffic cops, right? Directing traffic from the 00:02:47.330 --> 00:02:49.409 instances within those subnets. So for a public 00:02:49.409 --> 00:02:51.590 subnet, the root table points internet -bound 00:02:51.590 --> 00:02:54.189 traffic straight to that IGW. Okay, but hang 00:02:54.189 --> 00:02:57.229 on. If I have, say, a backend application server 00:02:57.229 --> 00:02:59.750 in a private subnet, It needs to download security 00:02:59.750 --> 00:03:02.490 patches, right? But I definitely don't want random 00:03:02.490 --> 00:03:04.189 connections coming in from the internet. How 00:03:04.189 --> 00:03:06.189 does it get out securely? That is the classic 00:03:06.189 --> 00:03:08.870 problem, yes. And the answer is usually... A 00:03:08.870 --> 00:03:11.870 network address translation gateway or NAT gateway. 00:03:12.150 --> 00:03:14.610 The NAT gateway lives in one of your public subnets. 00:03:14.909 --> 00:03:16.750 Instances in your private subnets were out there 00:03:16.750 --> 00:03:19.110 outbound internet traffic to it. The NAT gateway 00:03:19.110 --> 00:03:21.210 then forwards the request using its own public 00:03:21.210 --> 00:03:23.409 IP, gets the response, and sends it back to the 00:03:23.409 --> 00:03:25.770 correct private instance. So outbound is allowed, 00:03:25.789 --> 00:03:28.530 but no unsolicited inbound connections can reach 00:03:28.530 --> 00:03:30.590 those private instances. Now here's a really 00:03:30.590 --> 00:03:32.909 key architectural point. You could technically 00:03:32.909 --> 00:03:35.370 set up your own EC2 instance to do this in that 00:03:35.370 --> 00:03:38.789 instance, but AWS offers the man NAT Gateway 00:03:38.789 --> 00:03:41.689 service. And honestly, it offers way better availability, 00:03:42.289 --> 00:03:44.930 much higher bandwidth, and basically zero management 00:03:44.930 --> 00:03:47.870 hassle for you. So yeah, in almost any serious 00:03:47.870 --> 00:03:49.870 setup, the managed NAT Gateway is the go -to 00:03:49.870 --> 00:03:51.650 choice, even though it costs a bit more per hour. 00:03:51.889 --> 00:03:53.550 That operation reliability is usually worth it. 00:03:53.750 --> 00:03:56.210 Okay, right. That makes sense. Now... Here's 00:03:56.210 --> 00:03:57.689 where it gets really interesting, especially 00:03:57.689 --> 00:04:00.969 thinking about cost and maybe compliance. We 00:04:00.969 --> 00:04:03.069 figured out how to talk to the wider internet 00:04:03.069 --> 00:04:06.569 via the NAT gateway. But what if my private instance 00:04:06.569 --> 00:04:09.889 just needs to talk to another AWS service, like 00:04:09.889 --> 00:04:12.569 S3, for example? Why should that traffic have 00:04:12.569 --> 00:04:15.650 to hairpin out through a NAT gateway, possibly 00:04:15.650 --> 00:04:18.290 racking up data charges just to talk to another 00:04:18.290 --> 00:04:21.420 service already inside AWS? Exactly. It shouldn't 00:04:21.420 --> 00:04:23.939 have to, and that is precisely the purpose of 00:04:23.939 --> 00:04:26.540 VPC endpoints, often powered by something called 00:04:26.540 --> 00:04:29.579 PrivateLink. This is a huge architectural win. 00:04:30.100 --> 00:04:32.279 VPC endpoints let your private resources connect 00:04:32.279 --> 00:04:35.439 directly to supported AWS services S3, DynamoGB, 00:04:35.519 --> 00:04:39.000 many others, without needing an IGW, a VPN connection, 00:04:39.040 --> 00:04:41.720 or even that NAT device. The traffic stays entirely 00:04:41.720 --> 00:04:44.220 within the secure AWS backbone network. It never 00:04:44.220 --> 00:04:46.040 touches the public internet. That's a big plus 00:04:46.040 --> 00:04:48.220 for security, and often for compliance needs 00:04:48.220 --> 00:04:50.120 too. And I remember there are a couple of flavors 00:04:50.120 --> 00:04:52.120 of these endpoints. Correct. There are two main 00:04:52.120 --> 00:04:55.480 types. First, interface endpoints. These essentially 00:04:55.480 --> 00:04:58.439 plays an elastic network interface, an ENI, with 00:04:58.439 --> 00:05:01.399 private IP address from your subnet right into 00:05:01.399 --> 00:05:03.819 your VPC. It acts like a private entry point 00:05:03.819 --> 00:05:06.439 to the service. Then there are gateway endpoints. 00:05:06.779 --> 00:05:08.879 These are a bit simpler conceptually. They act 00:05:08.879 --> 00:05:11.740 as a target in your route table. specifically 00:05:11.740 --> 00:05:14.319 for traffic heading to S3 and DynamoDB currently. 00:05:14.699 --> 00:05:16.240 You just add a route, point it at the endpoint, 00:05:16.560 --> 00:05:19.079 and boom, traffic to S3 or DynamoDB from that 00:05:19.079 --> 00:05:21.319 subnet now goes privately. It's a really easy 00:05:21.319 --> 00:05:23.939 way to tighten access to your storage. OK, fantastic. 00:05:24.079 --> 00:05:25.740 So the pathways are getting clearer. Now let's 00:05:25.740 --> 00:05:28.100 talk about the final control layer inside the 00:05:28.100 --> 00:05:31.120 VPC itself, the firewalls. I see we have security 00:05:31.120 --> 00:05:34.680 groups and also network ACLs or NACLs. Why two 00:05:34.680 --> 00:05:36.860 different firewall layers? Isn't that just like 00:05:36.860 --> 00:05:38.959 more complexity to manage? It's a great question, 00:05:38.959 --> 00:05:41.240 and it really comes down to the principle of 00:05:41.240 --> 00:05:44.600 defense in depth. You want layers. They protect 00:05:44.600 --> 00:05:46.120 things differently. They operate at different 00:05:46.120 --> 00:05:49.680 levels. And importantly, they behave differently. 00:05:50.279 --> 00:05:52.199 So security groups act at the instance level. 00:05:52.579 --> 00:05:54.579 Think of them as the firewall attached directly 00:05:54.579 --> 00:05:57.360 to your server's virtual network card. And the 00:05:57.360 --> 00:06:00.100 absolute key thing to remember. They are stateful. 00:06:00.399 --> 00:06:03.040 If you allow inbound traffic on, say, port 80 00:06:03.040 --> 00:06:05.620 for web traffic, the return traffic going back 00:06:05.620 --> 00:06:08.120 out is automatically permitted. You don't need 00:06:08.120 --> 00:06:10.439 a separate outbound rule for the reply. They're 00:06:10.439 --> 00:06:12.680 mostly about allowing specific traffic to an 00:06:12.680 --> 00:06:14.759 instance. OK, stateful at the instance level. 00:06:14.800 --> 00:06:17.160 What about the second layer, the NACLs? Right, 00:06:17.240 --> 00:06:19.839 the Network Assets Control List, or NACL. This 00:06:19.839 --> 00:06:22.040 one operates at the subnet level. So it's like 00:06:22.040 --> 00:06:23.939 a guard at the entrance to the entire neighborhood, 00:06:24.079 --> 00:06:26.720 not just one house. It affects all instances 00:06:26.720 --> 00:06:28.980 within that subnet. and the crucial difference 00:06:28.980 --> 00:06:32.319 here. NACLs are stateless. If you allow inbound 00:06:32.319 --> 00:06:34.740 traffic on port 80, you must also explicitly 00:06:34.740 --> 00:06:37.339 create an outbound rule to allow the return traffic 00:06:37.339 --> 00:06:39.860 on the appropriate ephemeral ports. And maybe 00:06:39.860 --> 00:06:42.379 even more importantly, NACLs support explicit 00:06:42.379 --> 00:06:45.360 deny rules. Security groups only have allow rules, 00:06:45.459 --> 00:06:48.339 so use both together. The NACL can block broad 00:06:48.339 --> 00:06:50.379 ranges of unwanted traffic at the subnet boundary, 00:06:50.579 --> 00:06:53.040 maybe deny all traffic from a known bad IP range. 00:06:53.519 --> 00:06:55.540 Then the security group allows only the specific 00:06:55.540 --> 00:06:57.379 necessary traffic to the individual instance. 00:06:57.699 --> 00:07:00.139 It's layered security. Perfect. That clears it 00:07:00.139 --> 00:07:04.040 up. So the VPC is our isolated, secure canvas. 00:07:04.459 --> 00:07:07.199 We build it with resilience using AZs and subnets. 00:07:07.600 --> 00:07:10.339 We control traffic flow with root tables, IGWs, 00:07:10.600 --> 00:07:12.819 NAT gateways, and those private VPC endpoints. 00:07:13.120 --> 00:07:15.879 And we lock it down with two layers of firewalls. 00:07:16.120 --> 00:07:18.879 Staple security groups and stateless NACLs. The 00:07:18.879 --> 00:07:21.279 house is built and secured. Now, let's tackle 00:07:21.279 --> 00:07:23.569 that global challenge. Our application is running 00:07:23.569 --> 00:07:26.529 happily and securely in a VPC, maybe in Virginia. 00:07:27.350 --> 00:07:29.290 But our user, they're trying to access it from, 00:07:29.290 --> 00:07:32.550 say, Japan. That physical distance, that's a 00:07:32.550 --> 00:07:34.629 huge problem for latency, right? How do we fix 00:07:34.629 --> 00:07:37.110 that? That distance is absolutely the killer 00:07:37.110 --> 00:07:39.490 for perceived performance in modern web applications. 00:07:39.790 --> 00:07:41.129 And the standard solution is, well, you don't 00:07:41.129 --> 00:07:43.189 move the server. You move the content closer 00:07:43.189 --> 00:07:45.250 to the user. You use a content delivery network, 00:07:45.310 --> 00:07:48.209 a CDN. And within AWS, the service for this is 00:07:48.209 --> 00:07:50.410 Amazon CloudFront. It's a massive globally distributed 00:07:50.410 --> 00:07:52.689 network of servers. Its whole job is to securely 00:07:52.689 --> 00:07:54.870 deliver your data, static files, videos, APIs, 00:07:55.069 --> 00:07:57.189 entire applications with really low latency, 00:07:57.269 --> 00:07:59.750 super fast, no matter where your end users actually 00:07:59.750 --> 00:08:02.069 are. OK, walk us through how that actually works. 00:08:02.550 --> 00:08:04.829 Where does the data live initially? how does 00:08:04.829 --> 00:08:07.230 CloudFront make it fast? So it starts with your 00:08:07.230 --> 00:08:09.149 origin server. This is the definitive source 00:08:09.149 --> 00:08:12.250 of your content. It could be an S3 bucket holding 00:08:12.250 --> 00:08:14.990 website files, maybe an EC2 instance running 00:08:14.990 --> 00:08:18.050 your application, or even an elastic load balancer 00:08:18.050 --> 00:08:21.250 distributing traffic to multiple servers. CloudFront 00:08:21.250 --> 00:08:23.790 then relies on its network of edge locations. 00:08:24.069 --> 00:08:27.050 These are hundreds of smaller data centers AWS 00:08:27.050 --> 00:08:29.129 has placed strategically all around the world, 00:08:29.610 --> 00:08:31.970 usually very close to major population centers 00:08:31.970 --> 00:08:34.389 and internet exchange points. Ah, so when my 00:08:34.389 --> 00:08:37.110 user in Japan makes a request, instead of that 00:08:37.110 --> 00:08:38.980 request... traveling all the way across the Pacific 00:08:38.980 --> 00:08:42.259 to Virginia. Exactly. The request gets intelligently 00:08:42.259 --> 00:08:45.279 routed by DNS to the nearest cloud front edge 00:08:45.279 --> 00:08:47.519 location, perhaps one in Tokyo. And then what 00:08:47.519 --> 00:08:49.600 happens at that edge location? That's where the 00:08:49.600 --> 00:08:52.580 magic of caching comes in. If another user nearby 00:08:52.580 --> 00:08:55.779 recently requested the same file, say, a company 00:08:55.779 --> 00:08:59.899 logo image, a CSS file, maybe even a common API 00:08:59.899 --> 00:09:02.860 result, It might already be stored or cached 00:09:02.860 --> 00:09:05.519 at that Tokyo edge location. If it is cached, 00:09:05.820 --> 00:09:07.659 CloudFront serves it immediately from Tokyo. 00:09:08.019 --> 00:09:10.059 That request travels maybe tens of miles instead 00:09:10.059 --> 00:09:12.720 of thousands. Latency just plummets. If it's 00:09:12.720 --> 00:09:15.000 not in the cache yet, a cache miss, the edge 00:09:15.000 --> 00:09:16.779 location goes and fetches it from your origin 00:09:16.779 --> 00:09:18.879 server in Virginia, stores it in its cache for 00:09:18.879 --> 00:09:20.860 next time, and then delivers it to the user in 00:09:20.860 --> 00:09:23.220 Japan. The speed benefit is obvious. What are 00:09:23.220 --> 00:09:25.480 the other big wins for someone using CloudFront? 00:09:25.720 --> 00:09:27.980 Oh, there's several key benefits. First, as we 00:09:27.980 --> 00:09:30.480 said, performance and global reach. It's just 00:09:30.480 --> 00:09:33.440 faster for almost everyone. Second, security 00:09:33.440 --> 00:09:36.340 is a big one. CloudFront integrates tightly with 00:09:36.340 --> 00:09:39.559 AWS Way, the web application firewall. So you 00:09:39.559 --> 00:09:41.879 can filter out common attacks like SQL injection 00:09:41.879 --> 00:09:44.559 or cross -site scripting right at the edge before 00:09:44.559 --> 00:09:47.320 they even get near your origin. Plus things like 00:09:47.320 --> 00:09:50.539 HTTP SSL are standard and you can do geo -restrictions 00:09:50.539 --> 00:09:53.299 blocking access from certain countries. Third, 00:09:53.639 --> 00:09:56.639 cost optimization. Think about it. Every request 00:09:56.639 --> 00:09:58.720 served from the edge cache is a request your 00:09:58.720 --> 00:10:01.139 origin server doesn't have to handle. That reduces 00:10:01.139 --> 00:10:04.940 load on your EC2 instances or ELBs. And crucially, 00:10:05.299 --> 00:10:08.100 data transfer out from an AWS region can be expensive. 00:10:08.519 --> 00:10:10.500 Data transfer out from Clifront edge locations 00:10:10.500 --> 00:10:13.059 is often much cheaper, so it can save you significant 00:10:13.059 --> 00:10:15.399 money. Yeah, I remember hearing about folks using 00:10:15.399 --> 00:10:17.740 it not just for static stuff like images, but 00:10:17.740 --> 00:10:20.500 to accelerate dynamic API calls too. They saw 00:10:20.500 --> 00:10:23.059 huge latency drops for international users just 00:10:23.059 --> 00:10:25.539 by routing API traffic through CloudFront. Absolutely. 00:10:25.740 --> 00:10:28.620 Even for dynamic content, CloudFront optimizes 00:10:28.620 --> 00:10:31.000 the network pass back to your origin. But you 00:10:31.000 --> 00:10:33.580 also get fine -grained control. You can use cache 00:10:33.580 --> 00:10:35.740 behaviors to customize how things are cached. 00:10:36.100 --> 00:10:38.840 You can define the time to live, the TTL, how 00:10:38.840 --> 00:10:41.419 long content stays cached. You can control whether 00:10:41.419 --> 00:10:43.679 things like QWERTY strings or cookies are forwarded 00:10:43.679 --> 00:10:46.120 to the origin, which is essential for personalized 00:10:46.120 --> 00:10:49.000 content. Lots of levers to pull there. But the 00:10:49.000 --> 00:10:51.120 feature that seems like a real game changer, 00:10:51.340 --> 00:10:53.600 the real aha moment for developers lately, seems 00:10:53.600 --> 00:10:56.519 to be Lambda at Edge. What's that about? Yeah. 00:10:56.649 --> 00:10:59.250 Lambda Edge is incredibly powerful. It lets you 00:10:59.250 --> 00:11:02.409 run small snippets of code. AWS Lambda functions 00:11:02.409 --> 00:11:04.750 directly at the CloudFront Edge locations. Close 00:11:04.750 --> 00:11:07.029 to the user. Think about the possibilities. Before 00:11:07.029 --> 00:11:09.090 the request even hits your main application, 00:11:09.529 --> 00:11:12.210 you could resize images on the fly based on the 00:11:12.210 --> 00:11:14.450 user's device type detected from request headers. 00:11:15.029 --> 00:11:17.470 Or you could run A -B testing logic right at 00:11:17.470 --> 00:11:19.789 the edge, routing users to different versions. 00:11:20.389 --> 00:11:23.470 Or perform custom authentication checks. or even 00:11:23.470 --> 00:11:25.529 generate simple responses directly from the edge 00:11:25.529 --> 00:11:28.169 without ever bothering your origin. You're essentially 00:11:28.169 --> 00:11:30.350 pushing compute logic out to the very perimeter 00:11:30.350 --> 00:11:33.309 of the network. It maximizes speed and efficiency 00:11:33.309 --> 00:11:36.350 for certain tasks. This really transforms CloudFront 00:11:36.350 --> 00:11:38.549 from just a caching layer into, well, a kind 00:11:38.549 --> 00:11:40.690 of globally distributed compute platform. It 00:11:40.690 --> 00:11:43.190 enables really advanced use cases, super fast 00:11:43.190 --> 00:11:45.629 serverless websites, smooth video streaming, 00:11:46.210 --> 00:11:48.490 accelerating mobile app APIs, all sorts of things. 00:11:48.830 --> 00:11:51.049 Okay, wow. That really brings us nicely to the 00:11:51.049 --> 00:11:53.230 end of this deep dive. them. We started by laying 00:11:53.230 --> 00:11:55.990 that secure network foundation with VPC. We looked 00:11:55.990 --> 00:11:58.110 at some nets, how traffic gets in and out securely 00:11:58.110 --> 00:12:00.929 with things like NAT gateways, and the efficiency 00:12:00.929 --> 00:12:03.470 and security boost from VPC endpoints. Then we 00:12:03.470 --> 00:12:05.909 moved on to accelerating content globally using 00:12:05.909 --> 00:12:08.470 CloudFront, leveraging those edge locations and 00:12:08.470 --> 00:12:11.250 caching, plus the power of Lambda at edge. So 00:12:11.250 --> 00:12:12.850 what does this all mean for you, the listener? 00:12:13.809 --> 00:12:16.129 Well, truly understanding these two core components, 00:12:16.350 --> 00:12:19.070 VPC for the foundation, CloudFront for the delivery, 00:12:19.210 --> 00:12:21.500 it's just non -negotiable. If you want to build 00:12:21.500 --> 00:12:24.500 anything robust, scalable, and secure on AWS 00:12:24.500 --> 00:12:27.279 from a simple website to a complex global application, 00:12:27.860 --> 00:12:29.740 you need to have a solid grasp of these networking 00:12:29.740 --> 00:12:33.399 and content delivery principles. Right. And to 00:12:33.399 --> 00:12:35.220 leave you with something to chew on, a final 00:12:35.220 --> 00:12:37.820 provocative thought. We talked about security 00:12:37.820 --> 00:12:39.820 groups being stateful firewalls at the instance 00:12:39.820 --> 00:12:42.559 level and NACLs being stateless firewalls at 00:12:42.559 --> 00:12:45.120 the subnet level with that power to explicitly 00:12:45.120 --> 00:12:48.259 deny traffic. So think about this. When designing 00:12:48.259 --> 00:12:50.419 your security, is it enough to rely just on the 00:12:50.419 --> 00:12:52.899 stateful allow rules of security groups around 00:12:52.899 --> 00:12:55.299 your critical servers? Or should you also be 00:12:55.299 --> 00:12:57.840 using restrictive stateless NACLs one layer up, 00:12:58.080 --> 00:13:00.379 explicitly denying anything not expressly permitted 00:13:00.379 --> 00:13:03.139 to enforce a stricter default deny posture at 00:13:03.139 --> 00:13:05.279 the subnet boundary? How does that stateless 00:13:05.279 --> 00:13:07.419 deny capability change your defense in -depth 00:13:07.419 --> 00:13:09.019 strategy? Something to keep digging into.