WEBVTT 1 00:00:00.040 --> 00:00:01.040 Okay, let's unpack this. 2 00:00:01.919 --> 00:00:06.040 Have you ever faced a mountain of technical documentation, maybe 3 00:00:06.040 --> 00:00:08.839 for an aws seart or a new project, and just 4 00:00:08.960 --> 00:00:15.560 wished someone could cut straight to the strategic insights, the 5 00:00:15.919 --> 00:00:17.839 aha moments that really matter. 6 00:00:18.039 --> 00:00:18.199 Oh? 7 00:00:18.280 --> 00:00:20.839 Absolutely, well, that's exactly what we're here to do for 8 00:00:20.879 --> 00:00:21.280 you today. 9 00:00:21.440 --> 00:00:24.039 It's true, this sheer volume of information and advance at 10 00:00:24.039 --> 00:00:28.199 AWS networking can be well daunting. Our goal isn't just 11 00:00:28.199 --> 00:00:31.519 to summarize. It's more about connecting those critical dots, offering 12 00:00:31.519 --> 00:00:36.240 the kind of insights that make complex architectural decisions click 13 00:00:36.280 --> 00:00:36.719 into place. 14 00:00:36.920 --> 00:00:40.520 So we're diving deep into the world of advanced AWS networking. 15 00:00:40.719 --> 00:00:44.280 We're drawing from a pretty comprehensive guide here designed for 16 00:00:44.479 --> 00:00:47.719 serious professionals. Think of it as a shortcut maybe to 17 00:00:47.840 --> 00:00:51.640 understanding the backbone of resilient, scalable cloud infrastructure. 18 00:00:51.880 --> 00:00:54.359 Yeah, our mission today is really to distill the crucial 19 00:00:54.399 --> 00:00:57.560 concepts and maybe some unexpected insights you need. Whether you're 20 00:00:57.600 --> 00:01:00.479 aiming for that advanced certification, prepping for a critical design 21 00:01:00.520 --> 00:01:04.200 review where you're just eager to deepen your understanding, you'll 22 00:01:04.239 --> 00:01:07.000 walk away with a clearer picture of how these intricate 23 00:01:07.000 --> 00:01:07.920 pieces fit together. 24 00:01:08.400 --> 00:01:08.760 We're going to. 25 00:01:08.760 --> 00:01:12.840 Explore how you truly design, secure, and automate these enterprise 26 00:01:12.879 --> 00:01:16.719 green networks in the AWS Cloud, focusing on those nuanced 27 00:01:16.760 --> 00:01:20.560 decisions that you know, separate good architecture from great architecture. 28 00:01:21.040 --> 00:01:22.040 So let's begin with. 29 00:01:22.000 --> 00:01:25.400 The very foundation, the absolute core of your cloud kingdom, 30 00:01:25.799 --> 00:01:30.000 the virtual Private cloud or VPC. It's your own isolated 31 00:01:30.079 --> 00:01:32.920 private corner of AWS where you dictate the rules. But 32 00:01:33.599 --> 00:01:36.359 within that there are these advanced patterns that move beyond 33 00:01:36.599 --> 00:01:38.640 just basic connectivity precisely. 34 00:01:39.200 --> 00:01:42.319 Well, you know, a basic VPC setup is familiar to many. 35 00:01:42.760 --> 00:01:46.400 The real power, especially for enterprise environments, often comes from 36 00:01:46.439 --> 00:01:50.239 how you manage private connectivity to aws's own services, and 37 00:01:50.280 --> 00:01:53.040 this brings us to VPC endpoints in private link. 38 00:01:53.280 --> 00:01:55.680 Okay, I've heard these terms thrown around a lot. What's 39 00:01:55.719 --> 00:01:58.480 the fundamental problem they're solving, especially when you think about 40 00:01:58.519 --> 00:01:59.879 these advanced architectures. 41 00:02:00.239 --> 00:02:03.239 Well, the core problem is actually pretty simple. How do 42 00:02:03.280 --> 00:02:07.400 you let instances in your private subnets talk to essential 43 00:02:07.519 --> 00:02:12.159 AWS services like say S three or Dynamo dB without 44 00:02:12.159 --> 00:02:15.639 their traffic ever hitting the public Internet? Oh, because sending 45 00:02:15.680 --> 00:02:19.319 sensitive data over the public Internet, even if it's encrypted, 46 00:02:19.639 --> 00:02:22.520 often presents compliance or security concerns. 47 00:02:22.599 --> 00:02:25.960 So it's about completely eliminating that public internet hop even 48 00:02:26.000 --> 00:02:28.879 for AWS to AWS service communication. That sounds like a 49 00:02:28.879 --> 00:02:31.439 pretty significant security and compliance. 50 00:02:31.000 --> 00:02:34.680 When absolutely think of it like creating a dedicated private 51 00:02:34.719 --> 00:02:38.960 wire directly into those AWS services, all happening within the 52 00:02:39.000 --> 00:02:43.960 AWS network backbone. You avoid exposing your traffic publicly, significantly 53 00:02:44.039 --> 00:02:47.400 enhancing your security posture. And there are two main types 54 00:02:47.439 --> 00:02:48.240 to consider. 55 00:02:47.919 --> 00:02:50.680 Here, and those are gateway endpoints and interface endpoints. Right, 56 00:02:50.719 --> 00:02:53.080 So what's the architectural difference? When would you pick one 57 00:02:53.120 --> 00:02:53.479 over the other? 58 00:02:53.840 --> 00:02:57.479 Correct? So, gateway end points are well simpler, specifically for 59 00:02:57.639 --> 00:03:00.280 S three and Dynamo dB. They essentially just add a 60 00:03:00.319 --> 00:03:04.159 route to your VPC routing table, directing traffic for those 61 00:03:04.159 --> 00:03:07.560 services privately. It's like telling your VPC, hey, for S three, 62 00:03:07.719 --> 00:03:10.080 go this private way, okay. The key thing is they 63 00:03:10.120 --> 00:03:12.479 are not powered by private link and they only support 64 00:03:12.520 --> 00:03:14.680 those two specific services, right okay. 65 00:03:14.840 --> 00:03:17.840 And interface endpoints powered by private link they seem like 66 00:03:17.879 --> 00:03:19.280 a much broader solution then. 67 00:03:19.280 --> 00:03:22.520 They really are interface endpoints at a high level, they 68 00:03:22.560 --> 00:03:25.439 actually provision an elastic network interface and E and I 69 00:03:26.080 --> 00:03:28.840 with a private IP addressed directly in your subnet. Wow. 70 00:03:28.960 --> 00:03:30.240 Okay in my subnet. 71 00:03:30.360 --> 00:03:32.199 Yeah, this E and I then serves as the entry 72 00:03:32.199 --> 00:03:35.919 point to a much wider array of AWS services and 73 00:03:35.960 --> 00:03:39.400 even services hosted by other AWS customers or partners via 74 00:03:39.439 --> 00:03:42.520 private link. It's almost like having a dedicated copy of 75 00:03:42.560 --> 00:03:46.000 that AWS service sort of residing directly within your VPC, 76 00:03:46.240 --> 00:03:49.960 accessible via a private IP. And this flexibility is what 77 00:03:50.000 --> 00:03:52.919 makes private link such a well a game changer for 78 00:03:53.039 --> 00:03:56.840 micro services architectures and really stringent security requirements. 79 00:03:57.120 --> 00:03:58.280 That's a powerful shift. 80 00:03:58.759 --> 00:04:01.439 So instead of just a outing table entry, you literally 81 00:04:01.479 --> 00:04:04.360 have a network interface with a private IP, making that 82 00:04:04.439 --> 00:04:08.280 service look like it's part of your own private network. Okay, 83 00:04:09.120 --> 00:04:12.120 what about connecting and higher vpcs to each other. We 84 00:04:12.159 --> 00:04:15.400 often talk about applications spanning multiple vpcs, right, Yeah. 85 00:04:15.439 --> 00:04:18.879 For connecting two vpcs privately, we use VPC peering. It's 86 00:04:19.199 --> 00:04:22.800 essentially a direct network link between them. It allows resources 87 00:04:22.800 --> 00:04:25.360 in one VPC to communicate with resources in the other 88 00:04:25.720 --> 00:04:29.560 using private IP addresses. This is pretty fundamental for building 89 00:04:29.839 --> 00:04:32.079 multi account or multi application environments. 90 00:04:32.439 --> 00:04:35.040 But there are limitations with tiering, aren't there. I seem 91 00:04:35.040 --> 00:04:37.720 to recall it's not exactly a truly global mesh or 92 00:04:37.759 --> 00:04:38.439 anything like that. 93 00:04:38.600 --> 00:04:41.879 Exactly. That's a key point. The most critical limitation is 94 00:04:41.879 --> 00:04:45.959 that peering connections are non transitive. So if VPCA peers 95 00:04:45.959 --> 00:04:51.480 with VPCB and VPCB peers with VPCC, VPCA cannot directly 96 00:04:51.600 --> 00:04:55.639 talk to VPCC through VPCB. Ah Right, no pass through, 97 00:04:55.720 --> 00:04:58.560 No pass through, You'd need a separate explicit peering connection 98 00:04:58.639 --> 00:05:00.680 between A and C. You can see how that could 99 00:05:00.720 --> 00:05:02.920 lead to a really complex mesh in larger environments. 100 00:05:03.199 --> 00:05:05.399 It gets messy quickly, it does. 101 00:05:05.720 --> 00:05:09.639 And this non transitivity often leads architects to consider other 102 00:05:09.720 --> 00:05:15.480 solutions for that large scale inner VPC connectivity like AWS 103 00:05:15.480 --> 00:05:16.279 transit gateway. 104 00:05:16.680 --> 00:05:17.279 Fascinating. 105 00:05:17.360 --> 00:05:21.639 Okay, so we've designed our isolated custom network environment, we've 106 00:05:21.680 --> 00:05:25.839 connected it intelligently, but how do we truly lock it down? 107 00:05:25.959 --> 00:05:28.759 This guide makes it pretty clear that advanced security is 108 00:05:28.959 --> 00:05:31.040 far more than just basic firewalls. 109 00:05:31.079 --> 00:05:35.160 Absolutely, The Advanced Networking exam really emphasizes a multi layered 110 00:05:35.160 --> 00:05:38.759 security strategy, and understanding the interplay between the different controls 111 00:05:38.839 --> 00:05:41.959 is well crucial. We're not just talking about individual firewalls, 112 00:05:41.959 --> 00:05:44.360 but a coordinated defense, right, and. 113 00:05:44.319 --> 00:05:46.600 A key part of that multi layered defense must be 114 00:05:46.759 --> 00:05:49.360 security groups and network access control lists. 115 00:05:49.439 --> 00:05:50.959 Or nacls for. 116 00:05:50.920 --> 00:05:53.480 Our listeners who are already professionals. What's the nuance maybe 117 00:05:53.480 --> 00:05:56.399 the advanced perspective that often gets overlooked when using these 118 00:05:56.399 --> 00:05:56.920 two together. 119 00:05:57.199 --> 00:06:00.839 Yeah, good question. The nuance is really in their interaction 120 00:06:00.920 --> 00:06:05.759 and their statefulness. Security groups are stateful operating at the 121 00:06:05.759 --> 00:06:08.360 instance level or the E and I level. Really, if 122 00:06:08.399 --> 00:06:12.240 you allow outbound traffic, the return inbound traffic is automatically permitted. 123 00:06:12.600 --> 00:06:14.720 They're typically your first line of defense right at the 124 00:06:14.759 --> 00:06:17.480 resource itself. Okay, stateful at the instance and nacls are 125 00:06:17.480 --> 00:06:22.560 different because they're stateless right exactly. Nacls are stateless firewalls 126 00:06:22.600 --> 00:06:25.720 operating at the subnet level. This means if you allow 127 00:06:25.759 --> 00:06:30.240 inbound traffic, you must also explicitly allow the corresponding outbound 128 00:06:30.360 --> 00:06:33.519 return traffic. Uh okay, you got to remember the return 129 00:06:33.560 --> 00:06:37.040 path you have to. This provides very granular, often broader 130 00:06:37.079 --> 00:06:41.000 control right at the subnet boundary. The advanced perspective here 131 00:06:41.040 --> 00:06:44.519 is really to leverage both strategically. You use security groups 132 00:06:44.519 --> 00:06:48.120 for instance specific maybe more dynamic rules, while nacls provide 133 00:06:48.160 --> 00:06:52.279 a more rigid network segmentation layer. Many advanced designs use 134 00:06:52.360 --> 00:06:55.759 nacls as a kind of baseline deny all unless explicitly 135 00:06:55.759 --> 00:06:58.240 allowed at the subnet level, right, a coarse grain filter, 136 00:06:58.480 --> 00:07:02.279 exactly a coarse grain filter, and then you refine permissions 137 00:07:02.600 --> 00:07:05.560 with the more flexible security groups closer to the instance. 138 00:07:05.879 --> 00:07:09.519 That multi layered approach gives you fantastic control. Yeah, but 139 00:07:09.680 --> 00:07:12.199 it also sounds like it could be well a nightmare 140 00:07:12.199 --> 00:07:14.480 to troubleshoot if something's not working as expected. 141 00:07:14.560 --> 00:07:17.560 Oh, it can be. And that's precisely where VPC flow 142 00:07:17.600 --> 00:07:21.240 logs become your network detective. They are incredibly powerful for 143 00:07:21.279 --> 00:07:25.240 diagnosing connectivity issues. Flow Logs capture a wealth of information 144 00:07:25.319 --> 00:07:28.079 about IP traffic going to and from network interfaces in 145 00:07:28.120 --> 00:07:32.680 your VPC source and destination IPS and ports protocol, and 146 00:07:32.759 --> 00:07:36.879 crucially the action taken, whether the traffic was accepted or rejected. 147 00:07:37.000 --> 00:07:39.560 So if a connection fails, you don't just know it failed, 148 00:07:39.600 --> 00:07:41.879 you potentially know why it failed. Is it a security 149 00:07:41.879 --> 00:07:45.120 group rule, an NaCl rule, or maybe something else entirely. 150 00:07:44.839 --> 00:07:49.120 Precisely, you can analyze patterns, identify I don't know, rogue connections, 151 00:07:49.360 --> 00:07:51.720 or just confirm if your firewall rules are behaving the 152 00:07:51.720 --> 00:07:54.600 way you expect them to. However, and this is vital. 153 00:07:54.839 --> 00:07:57.839 It's important to remember flow logs are not real time. 154 00:07:58.160 --> 00:08:01.519 They also don't perform deepacket inspects, and they don't capture 155 00:08:01.519 --> 00:08:05.000 all traffic. For instance, traffic to the Amazon DNS server 156 00:08:05.360 --> 00:08:08.279 or the instance metadata service isn't logged. They're more of 157 00:08:08.360 --> 00:08:12.000 a historical record, invaluable for post incident analysis. 158 00:08:12.240 --> 00:08:17.399 Got it, so diagnostics, not live threat prevention necessarily. Now, 159 00:08:17.600 --> 00:08:20.600 when we talk about advanced network security, the conversation usually 160 00:08:20.680 --> 00:08:24.519 moves pretty quickly beyond just firewalls. How do AWS native 161 00:08:24.519 --> 00:08:28.920 solutions and maybe third party tools integrate for even deeper protection? 162 00:08:29.120 --> 00:08:31.920 Yeah, that's a common requirement. We often look at solutions 163 00:08:31.959 --> 00:08:36.320 like AWS WEF the Web Application Firewall for application layer threats, 164 00:08:36.720 --> 00:08:40.039 protecting against common web exploits like sequel injection or cross 165 00:08:40.039 --> 00:08:42.960 sight scripting. That works well with services like cloud Front, 166 00:08:43.039 --> 00:08:45.440 application load balancers, and API Gateway. 167 00:08:45.200 --> 00:08:46.879 Right layer seven stuff exactly. 168 00:08:47.080 --> 00:08:49.360 But for even deeper packet inspection where you actually need 169 00:08:49.399 --> 00:08:51.879 to examine the contents of packets from malicious signatures or 170 00:08:51.879 --> 00:08:56.120 maybe data exfiltration attempts, organizations often deploy third party intrusion 171 00:08:56.159 --> 00:09:01.039 prevention or detection systems ipsids or maybe next gen firewalls. 172 00:09:01.080 --> 00:09:04.240 And how are those typically deployed in an AWS environment. 173 00:09:04.399 --> 00:09:05.559 Is there a standard pattern? 174 00:09:06.000 --> 00:09:08.279 Yeah, A common advanced pattern is what's sometimes called a 175 00:09:08.279 --> 00:09:12.000 security VPC or maybe just a dedicated public subnet that 176 00:09:12.039 --> 00:09:15.519 acts as a traffic inspection zone. All traffic that needs 177 00:09:15.559 --> 00:09:19.200 that deep inspection, say northbound, southbound traffic going to the Internet, 178 00:09:19.480 --> 00:09:22.879 or sometimes even east west traffic between application tiers is 179 00:09:23.000 --> 00:09:25.279 routed through these dedicated security appliances. 180 00:09:25.399 --> 00:09:28.240 Ah, okay, so you funnel traffic through it, exactly. 181 00:09:28.279 --> 00:09:31.759 It creates a centralized, auditible choke point for advanced threat 182 00:09:31.759 --> 00:09:32.759 detection and prevention. 183 00:09:33.240 --> 00:09:36.279 Interesting, so we've built our private network, We've fortified it 184 00:09:36.320 --> 00:09:39.759 with these multi layered defenses, and we can even diagnose 185 00:09:39.759 --> 00:09:43.600 issues with flow logs. But as you mentioned, for many businesses, 186 00:09:43.639 --> 00:09:47.279 their entire infrastructure isn't just in the cloud. They often 187 00:09:47.279 --> 00:09:50.200 have traditional data centers that need to be seamlessly connected. 188 00:09:50.440 --> 00:09:54.440 Indeed, bridging that gap between existing on premises infrastructure and 189 00:09:54.480 --> 00:09:58.919 AWS is a major challenge for well many enterprises, and 190 00:09:59.200 --> 00:10:02.519 the on premise environment itself can be quite complex. Right. 191 00:10:02.840 --> 00:10:06.639 A mix of structured data centers, remote offices, diverse equipment, 192 00:10:07.200 --> 00:10:11.320 AWS offers managed services specifically designed to simplify this hybrid 193 00:10:11.360 --> 00:10:12.159 cloud reality. 194 00:10:12.279 --> 00:10:14.679 The first option most people probably think of as VPN, 195 00:10:14.919 --> 00:10:18.200 but for high performance or really critical workloads, it often 196 00:10:18.200 --> 00:10:20.360 comes down to direct connect, doesn't it Exactly? 197 00:10:20.879 --> 00:10:25.759 While AWS managed VPN provides encrypted connectivity over the public Internet, 198 00:10:26.120 --> 00:10:28.720 direct connect is a true game changer for those high 199 00:10:28.759 --> 00:10:32.919 performance requirements. It gives you dedicated private optical links actual 200 00:10:32.960 --> 00:10:36.159 layer two connections between your data center and an AWS 201 00:10:36.159 --> 00:10:37.080 direct connect location. 202 00:10:37.360 --> 00:10:39.159 Wow Layer two Yeah. 203 00:10:38.960 --> 00:10:43.039 And this translates to consistently fast, low latency, and reliable connectivity. 204 00:10:43.200 --> 00:10:47.240 It's crucial for things like large data transfers, real time applications, 205 00:10:47.559 --> 00:10:50.480 or maybe strict compliance needs where public Internet transit just 206 00:10:50.559 --> 00:10:51.799 isn't acceptable. 207 00:10:51.440 --> 00:10:55.360 So it's literally a private line directly into AWS. What 208 00:10:55.480 --> 00:10:59.080 are the key considerations then, for designing a highly available 209 00:10:59.120 --> 00:11:02.360 and secure direct connect link, Because, I mean, one single 210 00:11:02.399 --> 00:11:05.159 link is never enough for a real enterprise setup. 211 00:11:05.600 --> 00:11:09.320 You're absolutely right, redundancy is paramount for high availability. You 212 00:11:09.440 --> 00:11:13.559 typically provision multiple direct connect links, maybe from different physical locations, 213 00:11:13.559 --> 00:11:17.279 sometimes even using different service providers connecting DAWs. Then you 214 00:11:17.399 --> 00:11:21.519 use dynamic routing, specifically with Border Gateway Protocol or BGP 215 00:11:21.720 --> 00:11:25.080 across these links. Okay, BGP, Yeah, BGP lets you dynamically 216 00:11:25.159 --> 00:11:29.159 exchange routing information and crucially failover between paths if one 217 00:11:29.200 --> 00:11:29.960 link goes down. 218 00:11:30.519 --> 00:11:34.879 So BGP acts like the traffic cop automatically redirecting if 219 00:11:34.919 --> 00:11:38.039 a path fails. And what about a truly robust backup 220 00:11:38.120 --> 00:11:40.440 like beyond just multiple direct connects? 221 00:11:40.559 --> 00:11:43.960 Good point from maximum resilience. A really common advanced pattern 222 00:11:44.039 --> 00:11:46.480 is to use VPN over direct connect or perhaps just 223 00:11:46.480 --> 00:11:49.000 a separate site to site VPN connection as a backup 224 00:11:49.039 --> 00:11:51.840 to your main direct connect link. What's fascinating here is 225 00:11:51.840 --> 00:11:56.440 how AWS routing works. It inherently prioritizes direct connect paths 226 00:11:57.000 --> 00:12:00.840 over VPN paths for the same network routes, so traffic 227 00:12:00.879 --> 00:12:04.519 will always prefer the faster private direct connect link unless 228 00:12:04.519 --> 00:12:07.600 it fails. At that point, it automatically routes over the 229 00:12:07.679 --> 00:12:09.679 VPN backup, maintaining connectivity. 230 00:12:09.759 --> 00:12:10.279 That's clever. 231 00:12:10.440 --> 00:12:13.200 Yeah, And you can even use something called bidirectional forwarding 232 00:12:13.240 --> 00:12:18.480 detection or BFD for very very rapid failover detection specifically 233 00:12:18.519 --> 00:12:22.360 on the direct connect links, much faster than standard BGP timers. 234 00:12:22.559 --> 00:12:25.960 Okay, and for security over direct connect even though it's 235 00:12:25.960 --> 00:12:28.960 a private circuit, encryption might still be a requirement for 236 00:12:29.000 --> 00:12:30.200 some right precisely. 237 00:12:30.960 --> 00:12:34.320 While direct connect definitely offers privacy by segregating your traffic 238 00:12:34.320 --> 00:12:37.240 from the public Internet, it's not encrypted by default, it's 239 00:12:37.279 --> 00:12:40.480 just a private Layer two link. So for enhanced turity 240 00:12:40.879 --> 00:12:43.840 or maybe to meet certain compliance mandates, you can establish 241 00:12:43.879 --> 00:12:46.840 an IPC VPN tunnel over your direct connect link. 242 00:12:46.919 --> 00:12:49.039 Ah tunneling inside the tunnel. 243 00:12:48.759 --> 00:12:51.080 Kind of Yeah, it provides end to hand encryption for 244 00:12:51.120 --> 00:12:54.480 all traffics, reversing that private circuit, adding another critical layer 245 00:12:54.480 --> 00:12:54.960 of defense. 246 00:12:55.360 --> 00:12:55.679 Okay. 247 00:12:55.879 --> 00:12:59.679 Connecting these disparate environments is clearly a massive undertaking. But 248 00:12:59.720 --> 00:13:03.320 once they are connected, how do we ensure our applications 249 00:13:03.360 --> 00:13:06.559 themselves are not just available but performing at their peak 250 00:13:06.759 --> 00:13:07.519 maybe globally. 251 00:13:07.600 --> 00:13:09.519 Yeah, this brings us to a more strategic set of 252 00:13:09.559 --> 00:13:13.240 services that directly impact the user experience and application resilience, 253 00:13:13.720 --> 00:13:17.679 specifically elastic load balancing and content delivery networks. It's all 254 00:13:17.720 --> 00:13:19.720 about intelligent traffic management at this point. 255 00:13:19.759 --> 00:13:22.919 Okay, when we talk about elastic load balancing ELB, what 256 00:13:23.039 --> 00:13:26.639 are the key architectural choices and advanced network pro should 257 00:13:26.720 --> 00:13:30.519 be making between say, an application load balancer and a 258 00:13:30.559 --> 00:13:33.639 networkload balancer. It feels like it's more than just Layer 259 00:13:33.679 --> 00:13:35.120 seven versus Layer four these. 260 00:13:35.000 --> 00:13:38.240 Days, oh, it's significantly more nuanced now. The Application load 261 00:13:38.279 --> 00:13:41.480 Balancer ALB, operating at layer seven is really your intelligent 262 00:13:41.519 --> 00:13:45.440 traffic manager for HTTP and HTTPS. It excels at things 263 00:13:45.440 --> 00:13:48.600 like path based routing, host based routing. It can inspect 264 00:13:48.720 --> 00:13:52.679 HTTP headers. This allows for really powerful use cases like 265 00:13:53.000 --> 00:13:55.879 routing images traffic to one set of servers and APPY 266 00:13:55.960 --> 00:13:59.159 traffic to another set, or even routing based on the 267 00:13:59.279 --> 00:14:03.039 browser tie detected in the user agent header. It's fantastic 268 00:14:03.039 --> 00:14:05.240 for micro services and modern web applications. 269 00:14:05.279 --> 00:14:08.759 Okay, and the Network load Balancer NLB, that's pure layer 270 00:14:08.799 --> 00:14:10.200 for right rassbe correct. 271 00:14:10.279 --> 00:14:14.240 The NLB is built for extreme performance and ultralow latency. 272 00:14:14.360 --> 00:14:17.639 It can handle millions of requests per second, and it's transparent, 273 00:14:17.720 --> 00:14:20.840 meaning it forwards packets without modifying the source IP address 274 00:14:20.840 --> 00:14:21.279 of the client. 275 00:14:21.919 --> 00:14:22.399 That's key. 276 00:14:22.480 --> 00:14:25.720 Sometimes it's crucial for certain back end services that absolutely 277 00:14:25.720 --> 00:14:29.120 need to see the client's original IP address. Nlb's are 278 00:14:29.320 --> 00:14:32.600 ideal for high throughput, latency sensitive applications like maybe real 279 00:14:32.600 --> 00:14:37.519 time bidding, gaming, IoT platforms, or also when you need 280 00:14:37.600 --> 00:14:40.440 static IP addresses for your load balancer itself. Because it 281 00:14:40.480 --> 00:14:43.879 supports associating elastic eyeps. Okay, so the choice between ALB 282 00:14:43.960 --> 00:14:46.399 and NLB often boils down to do you need that 283 00:14:46.399 --> 00:14:50.480 application level intelligence and routing flexibility or do you need raw, 284 00:14:50.639 --> 00:14:52.879 transparent high throughput performance. 285 00:14:53.120 --> 00:14:53.639 Makes sense. 286 00:14:54.200 --> 00:14:56.879 So, once traffic hits your load balancer, how do you 287 00:14:56.919 --> 00:15:00.519 then get your content, especially static content, out to users 288 00:15:00.519 --> 00:15:02.320 around the globe as quickly as possible? 289 00:15:02.480 --> 00:15:07.000 Right? That's exactly where cloud Front aws's manage Content Delivery 290 00:15:07.039 --> 00:15:11.720 Network or CDN comes in. It leverages this massive global 291 00:15:11.759 --> 00:15:15.519 network of edge locations to cash and deliver both static 292 00:15:15.600 --> 00:15:20.120 and dynamic content with extremely low latencied end users. But 293 00:15:20.159 --> 00:15:22.919 for advanced use cases, CloudFront isn't just about caching static 294 00:15:22.960 --> 00:15:25.840 files anymore. It supports lambda at edge. 295 00:15:26.120 --> 00:15:28.480 Lambda at edge. That sounds interesting. What does that actually 296 00:15:28.559 --> 00:15:29.039 let you do? 297 00:15:29.159 --> 00:15:31.679 It's pretty powerful. It allows you to run serverless lambda 298 00:15:31.720 --> 00:15:35.000 code at the cloud Front edge locations themselves close to 299 00:15:35.039 --> 00:15:35.480 the user. 300 00:15:35.600 --> 00:15:35.960 Wow. 301 00:15:36.039 --> 00:15:40.200 This means you can dynamically modify content, customize HGDP responses 302 00:15:40.200 --> 00:15:43.840 based on user attributes, perform ab testing logic, or maybe 303 00:15:43.840 --> 00:15:47.759 do device based content customization before the request even reaches 304 00:15:47.799 --> 00:15:49.519 your origin server in the a US reader. 305 00:15:49.639 --> 00:15:51.919 So you're pushing logic right to the edge exactly. 306 00:15:52.000 --> 00:15:55.360 It's incredibly powerful for personalizing user experiences at a global 307 00:15:55.399 --> 00:15:57.799 scale and often reducing latency even further. 308 00:15:58.039 --> 00:16:00.960 Okay, beyond performance, how do you do you secure content 309 00:16:01.039 --> 00:16:04.919 delivery with CloudFront? Especially if you have say restricted or 310 00:16:05.000 --> 00:16:05.840 ped content. 311 00:16:06.279 --> 00:16:09.960 Security is absolutely critical there. CloudFront offers features like signed 312 00:16:10.120 --> 00:16:13.440 URLs and signed cookies. These allow you to generate temporary, 313 00:16:13.600 --> 00:16:17.039 unique credentials that grant access to specific content for a 314 00:16:17.080 --> 00:16:20.480 limited time, ensuring only authorized users can vote it. Right. 315 00:16:20.559 --> 00:16:21.840 For private content. 316 00:16:21.600 --> 00:16:24.399 Exactly, you can also use something called an Origin Access 317 00:16:24.399 --> 00:16:28.000 Identity OAI. This is a special cloud Front identity that 318 00:16:28.039 --> 00:16:30.720 you grant permission to read objects in your S three bucket. 319 00:16:31.279 --> 00:16:33.919 Then you lock down the S three bucket so only 320 00:16:33.960 --> 00:16:37.480 the OAI can access it, preventing users from bypassing cloud 321 00:16:37.519 --> 00:16:39.320 Front and going directly to S three. 322 00:16:39.279 --> 00:16:42.200 Ah clever forces them through the CDN right. 323 00:16:42.320 --> 00:16:44.960 Plus, there's field level encryption, which allows you to encrypt 324 00:16:45.000 --> 00:16:49.679 specific sensitive data fields within an HTTPS post request right 325 00:16:49.679 --> 00:16:52.120 at the edge before it even gets forwarded to your origin. 326 00:16:52.279 --> 00:16:53.279 M interesting. 327 00:16:53.480 --> 00:16:57.080 Okay, and what about DNS root fifty three is obviously fundamental, 328 00:16:57.120 --> 00:16:59.320 but the guide positions it as far more than just 329 00:16:59.360 --> 00:17:02.879 a simple main name service. It's really about intelligent traffic routing, 330 00:17:02.919 --> 00:17:03.360 isn't it? 331 00:17:03.480 --> 00:17:06.640 Precisely? Root fifty three is often called a next generation 332 00:17:06.799 --> 00:17:10.000 DNS service. It offers a one hundred percent SLA, which 333 00:17:10.039 --> 00:17:13.079 is rare, and a really powerful suite of routing policies 334 00:17:13.119 --> 00:17:17.359 that go way beyond simple named IP resolution. This really 335 00:17:17.480 --> 00:17:20.799 raises an important question, how do you direct user traffic 336 00:17:21.079 --> 00:17:25.359 not just reliably, but intelligently based on things like user location, 337 00:17:25.839 --> 00:17:28.480 application health, or maybe even business logic. 338 00:17:28.720 --> 00:17:31.079 So what are some of those advanced routing policies and 339 00:17:31.119 --> 00:17:33.759 maybe when would an architect choose one over another? 340 00:17:34.039 --> 00:17:37.359 Yeah, there are several key ones. For global applications. Latency 341 00:17:37.359 --> 00:17:40.640 based routing is fantastic. It automatically directs users to the 342 00:17:40.680 --> 00:17:44.160 AWS region that provides the lowest network latency for them, 343 00:17:44.200 --> 00:17:45.880 significantly improving their experience. 344 00:17:45.920 --> 00:17:47.920 Okay, fastest response time exactly. 345 00:17:48.200 --> 00:17:51.279 Then there's failover routing, which is perfect for disaster recovery setups. 346 00:17:51.279 --> 00:17:53.880 You can figure a primary site and the secondary site. 347 00:17:54.000 --> 00:17:56.359 If Root fifty three health checks detect that the primary 348 00:17:56.400 --> 00:17:59.559 site is down, it automatically redirects all traffic to the 349 00:17:59.599 --> 00:18:02.599 healthy secondary site, maybe like an S three static website 350 00:18:02.599 --> 00:18:04.799 for a maintenance page or a dr region. 351 00:18:04.759 --> 00:18:07.480 Right, crucial for HADR. And what about things like ab 352 00:18:07.640 --> 00:18:10.799 testing or maybe gradual rollouts of new features. 353 00:18:11.240 --> 00:18:14.839 That's where weighted routing really shines. You can distribute traffic 354 00:18:14.880 --> 00:18:18.240 to multiple endpoints based on percentages you define. So you 355 00:18:18.279 --> 00:18:21.519 could send say ten percent of traffic to a new 356 00:18:21.519 --> 00:18:24.880 application version and ninety percent to the old one, or 357 00:18:24.960 --> 00:18:27.240 distribute load based on server capacity. 358 00:18:27.440 --> 00:18:29.559 Okay, fine grained control. 359 00:18:29.359 --> 00:18:33.200 Very fine grained, and for localized content or data sovereignty requirements. 360 00:18:33.279 --> 00:18:37.359 Geolocation routing sends users to specific endpoints based on their 361 00:18:37.359 --> 00:18:41.319 geographic location, like their country or continent. This ensures they 362 00:18:41.359 --> 00:18:44.359 access the most relevant or compliant version of your application. 363 00:18:44.960 --> 00:18:47.839 And then there's geoproximity routing, which is slightly different. It 364 00:18:47.880 --> 00:18:50.960 directs users based on the geographic distance to your resources, 365 00:18:51.240 --> 00:18:54.000 but it also lets you apply a bias to influence 366 00:18:54.039 --> 00:18:55.279 the reach of certain endpoints. 367 00:18:55.319 --> 00:18:57.160 Wow, lots of options there. 368 00:18:57.000 --> 00:19:00.559 And crucially, almost all these intelligent routing policies can and 369 00:19:00.680 --> 00:19:04.279 usually should, integrate with ROOT fifty three health checks. This 370 00:19:04.319 --> 00:19:06.759 insurance traffic is only ever sent to endpoints that are 371 00:19:06.759 --> 00:19:08.079 actually healthy and available. 372 00:19:08.359 --> 00:19:08.880 Makes sense? 373 00:19:09.079 --> 00:19:11.640 Okay, we've put so much thought into building, securing, and 374 00:19:11.720 --> 00:19:15.119 intelligently routing traffic, but how do we know it's all 375 00:19:15.160 --> 00:19:18.640 working as intended? And maybe more importantly, how do we 376 00:19:18.680 --> 00:19:22.839 react quickly when something inevitably goes wrong. Monitoring isn't just 377 00:19:22.839 --> 00:19:26.720 a nice to have, It's absolutely essential for preventing outages. 378 00:19:27.039 --> 00:19:31.039 Yeah, what's fascinating here is how AWS provides this integrated 379 00:19:31.119 --> 00:19:35.279 suite of pretty powerful tools that give you a comprehensive picture, 380 00:19:35.599 --> 00:19:39.000 not just a performance, but of every action taken and 381 00:19:39.039 --> 00:19:42.359 every flow of traffic. And cloud Watch is truly the 382 00:19:42.400 --> 00:19:44.319 heart of AWS monitoring right. 383 00:19:44.319 --> 00:19:48.240 CloudWatch collects metrics and logs from well virtually every AWS service, 384 00:19:48.279 --> 00:19:50.279 and you can even push logs in metrics from. 385 00:19:50.079 --> 00:19:51.319 On premises systems. 386 00:19:51.599 --> 00:19:53.720 But for advance monitoring, it seems like it's all about 387 00:19:53.759 --> 00:19:56.000 making that raw data actionable. 388 00:19:55.640 --> 00:19:59.240 Right exactly. While the raw metrics are useful for dashboards 389 00:19:59.240 --> 00:20:02.119 and analysis, cloud Watch alarms are where the real power 390 00:20:02.119 --> 00:20:04.599 for action lies. You can set up alarms based on 391 00:20:04.680 --> 00:20:08.279 metric thresholds like CPU utilization going too high, or even 392 00:20:08.279 --> 00:20:10.640 based on specific patterns found within your cloud. 393 00:20:10.359 --> 00:20:12.400 Watch logs, and those alarms can do things. 394 00:20:12.599 --> 00:20:16.079 Oh yeah, an alarm can automatically trigger actions. Common ones 395 00:20:16.119 --> 00:20:19.519 are triggering autoscaling to add or remove instances, sending S 396 00:20:19.519 --> 00:20:21.920 and S notifications to your ops team or Slack channel, 397 00:20:22.400 --> 00:20:25.880 or even initiating an easy to instance recovery action. For 398 00:20:26.000 --> 00:20:29.880 deep log analysis, cloud watch Logs Insights provides really powerful 399 00:20:30.000 --> 00:20:33.680 query capabilities. It lets you quickly filter, parse and visualized 400 00:20:33.720 --> 00:20:37.119 patterns and potentially terabytes of logs to identify root causes 401 00:20:37.279 --> 00:20:38.799