Speaker 1: Welcome back to the deep dive. Today we're pulling back
Speaker 1: the curtain on something well fundamental yet often kind of unseen,
Speaker 1: the intricate world of cloud networking on AWS.
Speaker 2: That's right, you've sent.
Speaker 1: Us a stack of sources looks like excerpts from an
Speaker 1: AWS certification book, and our mission is pretty clear. Distill
Speaker 1: those crucial insights. We give you a shortcut really to
Speaker 1: being genuinely well informed about the hidden physics of the cloud.
Speaker 1: Let's umpact this.
Speaker 2: It is fascinating, isn't it, Because you know, cloud services
Speaker 2: can feel almost like magic, but underneath they're built on
Speaker 2: these deeply rooted networking principles, just with a dynamic global twist.
Speaker 2: So today, yeah, we're going to try and uncover those
Speaker 2: aha moments. We'll go from the virtual network interfaces powering
Speaker 2: your instances all the way to how global traffic is managed,
Speaker 2: how it's secured, revealing the key bits and importantly the
Speaker 2: unseen challenges that keep everything running.
Speaker 1: Okay, So where do we even begin with something as
Speaker 1: big as cloud networking? Maybe start right at the foundation
Speaker 1: makes sense.
Speaker 2: Let's talk about the elastic network interface, the E and I,
Speaker 2: The E and I.
Speaker 1: Right, So think of it like the cloud's virtual network
Speaker 1: card for your EC two instances. Every single bit of
Speaker 1: network traffic in and out it flows through an E
Speaker 1: and I exactly. But the key thing about E and i's,
Speaker 1: it seems, isn't just that they're virtual NICs. It's their flexibility, right, Absolutely,
Speaker 1: the flexibility is huge.
Speaker 2: You can attach them, detach them in different states too,
Speaker 2: Like you.
Speaker 1: Can do a hot attachment while the instance is actually running.
Speaker 2: Yep, hot attachment, while running warm attachment if it's stopped,
Speaker 2: or even coal attachment right when you'll launch it.
Speaker 1: Wow, And an instance can have more than one, like
Speaker 1: connected to different parts of your network.
Speaker 2: Yeah, definitely, you can have multiple E and i's on
Speaker 2: a single EC two instance, each connected to a different
Speaker 2: VPC subnet, maybe for different security zones or traffic types.
Speaker 2: That detachment flexibility really changes how you think about high availability.
Speaker 1: Okay, so that's the interface. What about the addresses themselves
Speaker 1: inside aws?
Speaker 2: Good question. Let's dive into IP addressing. So mostly you'll
Speaker 2: see vpcs using private IP ranges, you know, the standard
Speaker 2: RFC nineteen eighteen stuff.
Speaker 1: Right like ten dot or one seventy two dot sixteen exactly.
Speaker 2: But subnets can also allow for the auto assignment of
Speaker 2: public IPv four addresses when you'll launch an instance.
Speaker 1: Ah okay, but wait if those auto assigned public ips
Speaker 1: can just change, say if you stop and start the instance. Yeah,
Speaker 1: how do you deal with services that absolutely need a fixed,
Speaker 1: unchanging external address, like a web server or something.
Speaker 2: That's a fantastic question, and that's precisely where elastic IP
Speaker 2: addresses or EPs come in. They're indispensable for that hpiece.
Speaker 2: They are static public IPv four addresses. You basically allocate
Speaker 2: them to your AWS account, not directly to an instance initially.
Speaker 1: Ah okay, So they belong to the account.
Speaker 2: Right, and then you could associate an EP with an
Speaker 2: E and I or directly with an EC two instance.
Speaker 2: The crucial flexibility here is that the EEP isn't permanently
Speaker 2: tied to that specific piece of hardware or virtual.
Speaker 1: Hardware, so you can move it around exactly.
Speaker 2: If an instance fails or you need to swap something out,
Speaker 2: you just reassociate that same EP with a different instance
Speaker 2: or E and I. Gives you that stable public phase
Speaker 2: for your applications, regardless of the underlying instance churn.
Speaker 1: That makes a lot of sense, okay. Building on managing IPS, efficiently.
Speaker 1: The sources mentioned something called prefix lists. What are those about?
Speaker 1: How do they make life simpler?
Speaker 2: Prefix lists are actually quite clever. They're basically custom managed
Speaker 2: lists of IP address ranges or prefixes. You maintain these
Speaker 2: lists and then you can reference them consistently in your network.
Speaker 1: Can fix like in security groups or route tables precisely.
Speaker 2: Instead of typing out or copying and pasting potentially huge
Speaker 2: lists of IP addresses over and over again, you just
Speaker 2: refer to the prefix list by its name. It simplifies
Speaker 2: policy creation immensely.
Speaker 1: Okay, so you define it once, use it many times exactly.
Speaker 2: And they are two types. You've got AWS managed prefix lists,
Speaker 2: which AWS maintains for their own services, makes it super
Speaker 2: easy to allow traffic to S three or DynamoDB for example.
Speaker 1: Oh nice.
Speaker 2: And then you have customer managed prefix lists where you
Speaker 2: define your own groups of ips. Maybe you create one
Speaker 2: called all dev resources that includes all this CIDR blocks
Speaker 2: for your development VPCS makes managing access way easier.
Speaker 1: Right, I can see how that would tidy things up.
Speaker 1: Now for something that sounds a bit more mysterious, the hyperplane.
Speaker 1: What on earth is that?
Speaker 2: Yeah? It does sound a bit sci fi doesn't it.
Speaker 2: Think of the hyperplane as like the virtual network engine
Speaker 2: of AWS. It's the massively distributed underlying infrastructure that takes
Speaker 2: the physical network and slices it up virtually for every customer.
Speaker 2: That's what makes vpcs and all these services actually work.
Speaker 1: Okay, the engine behind the scenes, But what's surprising about it.
Speaker 2: What's surprising or at least really important to understand, is
Speaker 2: how it operates with these artificial limits. AWS puts these
Speaker 2: in place to ensure fair resource allocation across all tenants.
Speaker 1: Limits like bandwidth.
Speaker 2: Yeah, bandwidth or throughput limits are part of it, and
Speaker 2: they very hugely depending on the service. You know, a
Speaker 2: transit gateway VPC attachment might go up to fifty gigabits
Speaker 2: per second, whereas a single VPN tunnel might top out
Speaker 2: at say one point twenty five gvps and direct connect
Speaker 2: depending on the port, maybe one ten or even one
Speaker 2: hundred gvps. Now, these numbers kind of show the different
Speaker 2: skills you're working at.
Speaker 1: That huge difference between TGW and a VPN tunnel is striking.
Speaker 1: But you mentioned something else, something trickier than just bandwidth.
Speaker 2: Yes, and this is the one that catches people out,
Speaker 2: even experienced folks. It's the packets per second or PPS limitations.
Speaker 1: Packets per second. Why is that trickier?
Speaker 2: Because you can often hit the PPS limit before you
Speaker 2: hit the bandwidth limit, especially with lots of small packets,
Speaker 2: like certain types of application traffic, or maybe even a
Speaker 2: d DOS attack using small packets.
Speaker 1: And what happens?
Speaker 2: Then you start dropping packets silently. Your bandwidth monitors might
Speaker 2: look totally fine, nowhere near saturated, but packets are just
Speaker 2: vanishing into the ether because the hyperplane component handling your
Speaker 2: traffic can't process them fast enough.
Speaker 1: Ouch. So how do you even spot that? If there are,
Speaker 1: as you said, no obvious signs, That.
Speaker 2: Is the challenge. It feels like a ghost in the machine.
Speaker 2: Diagnosing it usually means you need to look beyond just throughput.
Speaker 2: You need metrics on packet counts, maybe packet drop counters
Speaker 2: if the service exposes them, or you have to use
Speaker 2: tools like VPC flow logs or even VBC traffic mirroring,
Speaker 2: which we can get into later, to try and see
Speaker 2: what's actually happening at the packet level. It definitely defies
Speaker 2: traditional bandwidth troubleshooting.
Speaker 1: Okay, that's a really crucial subtle point So we've got
Speaker 1: the building blocks E and i's ips limits. But clouds
Speaker 1: aren't usually isolated islands, right, You need them to talk
Speaker 1: to each other.
Speaker 2: Absolutely, Connecting things is key.
Speaker 1: So moving beyond individual instances, how do we connect these
Speaker 1: cloud components. What's the simplest way? VPC peering.
Speaker 2: Yeah, VPC peering is often the starting point. It creates
Speaker 2: a direct private connection between two vpcs using aws's backbone.
Speaker 2: It's pretty straightforward to set up. And actually there aren't
Speaker 2: explicit throughput limits imposed by the peering connection itself, beyond
Speaker 2: instance or other limits.
Speaker 1: Sounds good, but there have to be catches.
Speaker 2: Right, Oh, definitely key considerations. First, it's nontransitive, meaning if
Speaker 2: VPCA is peered with VPCB and VPCD is peered with VPCC,
Speaker 2: VPCA cannot automatically talk to VPCC just by going through B.
Speaker 2: There's no implicit routing pass through. You'd need a separate
Speaker 2: peering connection directly between A and C. Ah.
Speaker 1: Okay, so no hubbin spoke, just using peering exactly.
Speaker 2: And the second big one, maybe even bigger. It absolutely
Speaker 2: cannot be used if the vpcs have overlapping CADR ranges.
Speaker 1: Right, If both vpcs use ten point zero point zero
Speaker 1: point zero one six For example.
Speaker 2: YEP peering just won't work. Routing across peered vpcs relies
Speaker 2: on static routes. You have to manually add to the
Speaker 2: route tables in both vpcs for traffic to flow back
Speaker 2: and forth.
Speaker 1: That IP overlap thing, that sounds like a potential nightmare.
Speaker 1: You mentioned company mergers earlier. Imagine trying to connect two
Speaker 1: company networks that both picked say ten point one hundred
Speaker 1: point zero points zero one six independently peering is out?
Speaker 1: Is there any way to make workloads with overlapping IPS talk?
Speaker 2: You're right, it's a huge challenge in mergers or large
Speaker 2: organizations VPC peering it's a wall there. There is a solution,
Speaker 2: though it's not perfect. Yeah, using private net gateways.
Speaker 1: Not gateways, but usually those are forgetting out to the internet.
Speaker 2: Correct, those are public net gateways, but you can also
Speaker 2: set up private net gateways. They allow workloads in one
Speaker 2: DPC to initiate connections to workloads in another VPC, even
Speaker 2: if they have overlapping IPS, because the neat gateway handles
Speaker 2: the address translation on the way out.
Speaker 1: Ah, clever, but you said initiate.
Speaker 2: Yeah, that's the caveat. The communication generally have to be
Speaker 2: initiated from the side using the neat gateway. It's not
Speaker 2: a truly transparent bidirectional connection like peering would be if
Speaker 2: the ips didn't overlap. Solves a specific problem, but it's
Speaker 2: not a universal fix for overlapping CIDRs.
Speaker 1: Okay, so peering is simple, but limited, especially by transitivity
Speaker 1: and IP overlap. How did AS addressed the need for larger,
Speaker 1: more complex, maybe hub and spoke networks in the cloud.
Speaker 2: Well, the community first came up with solutions like the
Speaker 2: Transit VPC. This usually involves setting up dedicated EC two
Speaker 2: instances running routing software, network virtual appliances or mvas in
Speaker 2: the central VPC to act as a hub.
Speaker 1: So building your own router in the cloud basically.
Speaker 2: Pretty much it worked, But managing those mvas, worrying about
Speaker 2: their scaling, high availability, it's complex. So AWS eventually released
Speaker 2: a mandaged service to solve this much more elegantly, the
Speaker 2: AWS Transit Gateway or TGW Transit Gateway.
Speaker 1: Okay, how's that different.
Speaker 2: TGW acts as a fully managed, highly scalable central cloud
Speaker 2: router or hub. You attach your vpcs, your VPN connections,
Speaker 2: your direct connections all to the TGW. It simplifies INNERVPC
Speaker 2: connectivity massively and also makes hybrid networking connecting to on
Speaker 2: premises much cleaner. It takes the routing burden off you
Speaker 2: and puts it into a managed AWS service. A true
Speaker 2: hub and spoke model becomes easy.
Speaker 1: Got it? So TDW is the modern way for complex connectivity. Now,
Speaker 1: speaking of hybrid, what about that dedicated link you mentioned,
Speaker 1: Direct connect or DX. Why would someone go for DX
Speaker 1: instead of just setting up a VPN over the Internet.
Speaker 1: It seems like VPNs are pretty common.
Speaker 2: They are common and often sufficient, but direct connect offers
Speaker 2: several really critical advantages, especially for larger enterprises or sensitive workloads.
Speaker 2: Like what First, Privacy and security DX provides a dedicated
Speaker 2: private circuit. Your traffic isn't going over the public Internet,
Speaker 2: so it can't be snooped on easily. Second, reliability, DX
Speaker 2: comes with service level Agreements slas, promising certain levels of uptime.
Speaker 2: The public Internet is inherently best effort.
Speaker 1: Okay, so more secure, more reliable, and.
Speaker 2: Third performance significantly higher bandwidth as possible. D X connections
Speaker 2: come in one gbp's, ten gvps and now even one
Speaker 2: hundred gbp's flavors, plus you generally get lower and more
Speaker 2: consistent latency compared.
Speaker 1: To the Internet one hundred gigs. Wow. And it's literally
Speaker 1: a physical connection right like a cable.
Speaker 2: Yes, Fundamentally you work with AWS or a partner to
Speaker 2: get a physical cross connect cable run in a shared
Speaker 2: data center, a direct connect location between your networking equipment
Speaker 2: and aws's equipment. There's even a document involved, the Letter
Speaker 2: of Authorization in Connecting Facility Assignment or LOACFA, that you
Speaker 2: use to authorize the data center technicians to make that
Speaker 2: physical link. It's a tangible piece of your cloud connection.
Speaker 1: A physical manifestation of the cloud. Okay, that's cool. So
Speaker 1: DX sounds robust. What if one link isn't enough bandwidth
Speaker 1: or you need more redundancy, and how do you actually
Speaker 1: get that physical pipe connected into your virtual network your.
Speaker 2: Vpcs great questions for more bandwidth or redundancy. AWS offers
Speaker 2: link aggregation groups or lags. This is pretty neat. It
Speaker 2: lets you bundle multiple physical DX connections together, say for
Speaker 2: one gbp's links, and treat them as a single logical
Speaker 2: connection with combined bandwidth like four gbps. It simplifies management too.
Speaker 1: Ah like bonding network interfaces.
Speaker 2: Exactly like that, and to extend that physical connectivity into
Speaker 2: your actual AWS resources, you use virtual interfaces or visifs.
Speaker 2: Vifs essentially carve up that physical DX connection or LAG
Speaker 2: into logical pathways using VLAN tagging standard A to two
Speaker 2: point one qvland tags. This lets you run different types
Speaker 2: of network traffic over the same physical.
Speaker 1: Link, different type.
Speaker 2: Yeah, we mainly distinguish between three types. Private vifs, which
Speaker 2: are used to connect directly to your vpcs, usually via
Speaker 2: a component called a virtual private gateway PGW or more
Speaker 2: commonly now a transit gateway. Then there are public vifs,
Speaker 2: which let you access public AWS services like S three
Speaker 2: or EC two APIs over your private DX link bypassing
Speaker 2: the Internet.
Speaker 1: Okay, private for vpcs, public for AWS services. What's the third?
Speaker 2: The third is the transit VIF. This one is specifically
Speaker 2: designed to connect your direct connect link to a transit gateway.
Speaker 1: Right for that hub and spoke model with TGW precisely.
Speaker 2: And there's a crucial point here about transit, vis and TGW.
Speaker 2: I've heard about something called hairpinning that can get really
Speaker 2: expended if you're not careful.
Speaker 1: Ah. Yes, hairpinning. You're absolutely right to bring that up.
Speaker 1: It's a potentially very costly mistake. If you're using transit
Speaker 1: gateway with direct connect, it's critical that you use a
Speaker 1: single transit VIF per TGW connection to your on premises site.
Speaker 2: Why just one, because if you have multiple or misconfigure routing,
Speaker 2: you can end up with hair pinning. This is where
Speaker 2: traffic comes in from your on prem network via DX,
Speaker 2: goes to the TGW maybe needs to get to another VPC,
Speaker 2: but instead of routing directly, the TGW rows it back
Speaker 2: out the same DX connection towards your on prem router,
Speaker 2: only for your router to send it immediately back into
Speaker 2: AWS over DX again to reach the intended VPC.
Speaker 1: So it makes a U turn back through your own network.
Speaker 2: Exactly, a totally unnecessary round trip out of AWS and
Speaker 2: back in. And since you pay for a data egress
Speaker 2: from AWS, that double egress gets incredibly expensive really fast.
Speaker 2: A single transit VIF for TGW connection point, along with
Speaker 2: proper route propagation and filtering, prevents this costly detour.
Speaker 1: Wow. Okay, definitely noted avoid the hairpin So last piece
Speaker 1: on connectivity, what if you need your vpcs to talk
Speaker 1: privately to services could be aws's owned services or maybe
Speaker 1: third party sauce providers you use, but you don't want
Speaker 1: to go out to the Internet, and you don't want
Speaker 1: to route through net gateways if you can avoid it,
Speaker 1: what's the play there?
Speaker 2: That's the perfect use case for AWS private link private
Speaker 2: LINKA private link uses a component called a VPC endpoint.
Speaker 2: It essentially creates a secure private connection directly from your
Speaker 2: VPC to the service. The service endpoint effectively gets a
Speaker 2: private IP address within your vpc's address range, making the
Speaker 2: external service appear as if it's running right there inside
Speaker 2: your network.
Speaker 1: Ah So no Internet gateway, no, not no public eyps
Speaker 1: involved for that service connection.
Speaker 2: Correct traffic stays entirely within the AWS network backbone. It
Speaker 2: massively improves security by keeping sensitive data off the public Internet,
Speaker 2: and it simplifies your network architecture because you don't need
Speaker 2: complex firewall rules or net setups just to reach those
Speaker 2: services privately. It's very powerful for secure service consumption.
Speaker 1: Okay, that covers a lot of ground on how to
Speaker 1: connect things, but even with the best designs, things go wrong.
Speaker 1: Cloud networks, maybe even more than traditional ones, can have
Speaker 1: these elusive problems. Because so much is abstracted. How do
Speaker 1: you start peeling back those layers when inevitably something breaks.
Speaker 1: Let's talk about potential problems first. What kind of things
Speaker 1: typically bite you in cloud networking?
Speaker 2: Oh, there's a whole list. We definitely see IP address
Speaker 2: allocation issues pretty often, like a subnet just runs out
Speaker 2: of available IPS, IP exhaustion, yeah, or worse, those overlapping
Speaker 2: CIDR ranges we talked about causing weird routing conflicts. If
Speaker 2: someone tries to connect things that shouldn't be connected, then
Speaker 2: there are root scale limitations. AWS services have limits on
Speaker 2: the number of routes they can handle. Exceed those and
Speaker 2: routes might just disappear, or BGP sessions with your on
Speaker 2: prem gear might tear down.
Speaker 1: Okay, limits again. What else?
Speaker 2: Packet size mismatches. This is a subtle one. Issues with
Speaker 2: maximum transmission unit MTU or maximum segment size MSS can
Speaker 2: cause fragmentation. This often doesn't look like a network down problem,
Speaker 2: but it hits applications. You might see really slow file
Speaker 2: transfers or some web apps timing out without obvious network errors.
Speaker 1: Right because the network itself is passing packets just fragmented
Speaker 1: ones the application struggles with exactly.
Speaker 2: Then we have the hard limits we discussed band with
Speaker 2: throughput limitations which are usually pretty core quotas, and those
Speaker 2: tricky PPS limitations causing those silent packet drops that are
Speaker 2: so hard to diagnose.
Speaker 1: Still scary.
Speaker 2: Yeah, and related to that just general packet loss, maybe
Speaker 2: due to unreliable transit somewhere between regions, or maybe the
Speaker 2: end hosts themselves are just overwhelmed and dropping packets. And finally,
Speaker 2: never underestimate plain old security misconfiguration, a wrong rule in
Speaker 2: a security group or more often a network Access control
Speaker 2: list NaCl is a super frequent cause of it just
Speaker 2: doesn't connect problems.
Speaker 1: That's quite a list. Sounds like troubleshooting could be finding
Speaker 1: a needle in a haystack. What tools does AWS actually
Speaker 1: give you to get visibility to see inside this sometimes
Speaker 1: opaque window.
Speaker 2: Well, the courterstone of observability in AWS is definitely Amazon
Speaker 2: cloud Watch.
Speaker 1: Cloud Watch right, that's for metrics and logs for pretty
Speaker 1: much everything exactly.
Speaker 2: It's the central hub you need to understand its core components.
Speaker 2: There are name spaces, which are basically containers for metrics
Speaker 2: from a specific service like EC two or ELB. Then
Speaker 2: the metrics themselves. Those are the actual time series data
Speaker 2: points like CPU utilization or network in. Then you have dimensions,
Speaker 2: which are key value pairs that help you filter in
Speaker 2: group metrics like instant seed or autoscaling group name, and
Speaker 2: finally periods which define the time interval over which the
Speaker 2: data is aggregated, like one minute or five minutes. Cloud
Speaker 2: Watch is your main dashboard for performance, health and setting alarms.
Speaker 1: So cloud watch gives you the high level metrics. But
Speaker 1: what about seeing the actual traffic flows, like which connections
Speaker 1: are being allowed or denied. That sounds more like VPC
Speaker 1: flow logs precisely.
Speaker 2: VPC flowlugs give you metadata about the IP traffic flowing
Speaker 2: through your VPC. They capture information for each flow like
Speaker 2: source and destination, IP ports protocol, the number of packets
Speaker 2: and bytes, and crucially, the forwarding decision made by the
Speaker 2: VPC router, whether the traffic was accepted or rejected.
Speaker 1: That accept traject status seems key for troubleshooting.
Speaker 2: It is, but remember flow lugs are not full packet captures.
Speaker 2: They don't show you the payload, but they give you
Speaker 2: really valuable insight into network level decisions, and you can
Speaker 2: even set up custom formats for flow logs now custom formats.
Speaker 1: How would you use that?
Speaker 2: Well, for instance, you could include TCP flags in your logs.
Speaker 2: That might help you troubleshoot specific issues like TCP handshake problems.
Speaker 2: Are you seeing syn packets but no syn ACKs back?
Speaker 2: Things like that. It lets you tailor the logs to
Speaker 2: the problem you're investigating.
Speaker 1: That's handy. Now to make this concrete, the source material
Speaker 1: had this Prailcats troubleshooting example. Can you walk us through that?
Speaker 1: It seemed like a good illustration of using these tools systematically.
Speaker 2: Yeah, the Trailcats examples classic. They had a website and
Speaker 2: it was having these mysterious connectivity problems between two of
Speaker 2: its back end servers. So the first thing they did
Speaker 2: was enable VPT flow logs, but they did it at
Speaker 2: the NI level for the servers involved.
Speaker 1: Okay, looking right at the server's network interfaces, right, and.
Speaker 2: Those logs showed nothing rejected all ec SPTT. So initial
Speaker 2: thought might be, okay, the network's fine, must be an
Speaker 2: application problem.
Speaker 1: A dead end potentially exactly.
Speaker 2: But they didn't stop there. They widened the scope. They
Speaker 2: enabled flow logs, but this time at the subnet.
Speaker 1: Level AH one level up from the instance NI YEP
Speaker 1: and boom.
Speaker 2: The subnet level logs immediately showed rejected traffic between those
Speaker 2: two servers.
Speaker 1: So what did that point to?
Speaker 2: It pointed directly to a network Access control list or ANACL.
Speaker 2: Because nacls operated at the subnet boundary, they were blocking
Speaker 2: the traffic before it even got to the instance's E
Speaker 2: and I. The ENI level logs never saw the rejected
Speaker 2: packets because they never or reach the E ANDI.
Speaker 1: That's a brilliant example of how changing your observation point
Speaker 1: widening the scope is critical in cloud troubleshooting.
Speaker 2: Absolutely, you have to look at the different layers.
Speaker 1: Okay, so flow logs give metadata except reject But what
Speaker 1: if you do need to see the actual packet contents,
Speaker 1: like you suspect something weird in the payload or you
Speaker 1: need deep protocol analysis. Is there an equivalent to plugging
Speaker 1: in wire shark via a span port like in a
Speaker 1: physical data center.
Speaker 2: Yes, there is. That's VPC traffic mirroring. It essentially provides
Speaker 2: that span port capability in the cloud.
Speaker 1: Okay, how does it work?
Speaker 2: It lets you capture network traffic from a specific source,
Speaker 2: usually an EC two instances E and I and mirror
Speaker 2: it send a copy to a designated target.
Speaker 1: What kind of target?
Speaker 2: The target could be another E and I, maybe on
Speaker 2: an instance running wire shark or some security tool. Or
Speaker 2: it could be a network load balancer or even a
Speaker 2: gateway load balancer which might front a whole fleet of
Speaker 2: monitoring appliances.
Speaker 1: And you can control what traffic gets mirrored. You don't
Speaker 1: want to flood your monitoring tool, right.
Speaker 2: You use a filter which is basically an access control
Speaker 2: list using the standard five tuple format source itis ip
Speaker 2: port protocol to specify exactly which flows you want a mirror,
Speaker 2: and the whole thing source target filter is tied together
Speaker 2: in a session.
Speaker 1: So Source E and I filter the traffic, send it
Speaker 1: to a target for analysis exactly.
Speaker 2: It's incredibly powerful for deep packet inspection, security threat analysis,
Speaker 2: compliance monitoring, and just advanced troubleshooting where flow lugs aren't enough,
Speaker 2: you get the full packet.
Speaker 1: Got it? And just quickly you mentioned visibility for larger networks.
Speaker 1: Transit Gateway Network Manager TGNM. What's its role?
Speaker 2: Think of TGNM primarily as a unified dashboard and visualization tool,
Speaker 2: especially if you have a complex network involving multiple transit gateways, vpcs,
Speaker 2: VPNs direct connect maybe even reaching into different AWS regions
Speaker 2: or connecting to on premises sites. TGNM helps you see
Speaker 2: it all, so draws you a mapped pretty much. It
Speaker 2: gives you a logical and often a geographical view of
Speaker 2: your global network topology. You can register your on prem
Speaker 2: devices and sights too. It helps with monitoring the health
Speaker 2: and status of your TGW attachments and routes all in
Speaker 2: one place. It brings that bird's eye view which is
Speaker 2: vital as network scale.
Speaker 1: Okay, that makes sense, essential for managing complexity. Now, let's
Speaker 1: shift gears slightly, but stay related security. It's non negotiable. Obviously.
Speaker 1: A TOBS talks about a layered approach to traffic control
Speaker 1: right from the edge all the way down to the instance.
Speaker 1: How does that layering start way out at the global edge.
Speaker 2: Right before traffic even gets close to your VPC? AWS
Speaker 2: offers protection. The first line is often AWS Shield. This
Speaker 2: is primarily for a distributed denial of service or d
Speaker 2: DO protection.
Speaker 1: Shield just protection well.
Speaker 2: Shield standard is automatically enabled and protects against common network
Speaker 2: level DIDOS attacks, but Shield Advanced is a paid service
Speaker 2: that gives you much more. Totion four seven Access to
Speaker 2: aws's d DOOS Response Team DRT, detailed attack diagnostics and importantly,
Speaker 2: economic protection. AWOS can help cover cost and CURD due
Speaker 2: to d DOO sub driven spikes and usage on services
Speaker 2: like cloud Front or load balancers.
Speaker 1: Oh okay, insurance against DDOSE costs too. What else is
Speaker 1: out at the edge?
Speaker 2: Then you have ABUS WAFT the Web application firewall. This
Speaker 2: operates at layer seven, the application layer. It helps protect
Speaker 2: your web applications from common exploits like SEQL injection, cross
Speaker 2: sided scripting, XSS file inclusion, things that target vulnerabilities in
Speaker 2: your application code itself. You apply WAFT rules typically to
Speaker 2: cloud Front distributions or application load balancers.
Speaker 1: So shield handles the flood. Why handles the malicious application requests?
Speaker 2: Got it? Now? Bringing that firewall capability inside your vpcs?
Speaker 2: What about AWS Network Firewall? How does that work? AWS
Speaker 2: Network Firewall is a managed stateful firewall service that you
Speaker 2: deploy within your vpcs. It gives you fine grained control
Speaker 2: over traffic flowing between subnets between vpcs or in and
Speaker 2: out to the internet or on prem networks. You deploy
Speaker 2: firewall endpoints into specific subnets.
Speaker 1: And how do people typically design with it? The sources
Speaker 1: mention different patterns.
Speaker 2: Yeah, there are few common architectural patterns. One is the
Speaker 2: distributed design. You put a network firewall end point in
Speaker 2: basically every VPC that needs protection pros and cons pro
Speaker 2: granular policy control per VPC. Potentially lower latency as traffic
Speaker 2: doesn't have to leave the VPC for inspection. Con can
Speaker 2: get expensive and complex to manage policies across many firewalls.
Speaker 1: Okay, what's the alternative?
Speaker 2: The centralized design? Here you create a dedicated security VPC
Speaker 2: or inspection VPC. All traffic inner VPC, Internet ingresscress VPNDX
Speaker 2: traffic gets routed through network firewall end points in this central.
Speaker 1: VPC AH single choke point for inspection exactly.
Speaker 2: Pro cost savings, fewer end points, centralized management and policy
Speaker 2: enforcement condishing potentially adds latency as traffic has to detour
Speaker 2: through the inspection VPC and that VPC becomes a critical dependency.
Speaker 1: Makes sense any other patterns.
Speaker 2: There's also often a combination design trying to get the
Speaker 2: best of both worlds. Maybe you centralize inspection for east
Speaker 2: west inner VPC traffic, but you distribute the firewalls for
Speaker 2: Internet and gresscress traffic within each VPC to reduce latency
Speaker 2: for external connections. It's about balancing cost, latency, and manageability.
Speaker 1: Okay, choices depending on your needs. Now let's drill down
Speaker 1: to the absolute fundamentals inside of VPC. Remind us again
Speaker 1: about security groups sgs versus network access control lists and acls.
Speaker 1: They both filter traffic. But how are they different and
Speaker 1: where do people get tripped up?
Speaker 2: This is super important and yeah, confusion here causes a
Speaker 2: lot of issues. Okay, security groups or sg's think of
Speaker 2: them as stateful firewalls operating at the instance level, really
Speaker 2: the e NI level.
Speaker 1: Stateful meaning stateful.
Speaker 2: Means if you allow an outbound connection from your instance,
Speaker 2: say on part eighty, the SG automatically allows the return
Speaker 2: traffic back to the instance for that specific connection without
Speaker 2: needing a separate inbound rule. It understands the connection state.
Speaker 2: Also with sgs, the order of the rules as matter.
Speaker 2: All allow rules are evaluated, and importantly, sg's only support
Speaker 2: allow rules. There's an implicit deny at the end.
Speaker 1: Okay, stateful instance level allow rules only order doesn't matter.
Speaker 1: What about nacls.
Speaker 2: Network Access control lists or nacls. These are stateless firewalls
Speaker 2: operating at the subnet.
Speaker 1: Level stateless meaning stateless.
Speaker 2: Means they don't track connection state. If you allow outbound
Speaker 2: traffic on port eighty, you must also have an explicit
Speaker 2: inbound rule allowing traffic back on the ephemeral ports typically
Speaker 2: high numbered ports. For the response to get through, you
Speaker 2: need rules for both directions. Ah more work YEP and
Speaker 2: NEACL rules are processed in order, from the lowest numbered
Speaker 2: rule to the highest. The first rule that matches the
Speaker 2: traffic is applied, and that's it. Crucially, nacls support both
Speaker 2: allow and DNY rules, so you can create explicit blocks.
Speaker 2: There's also an implicit deny at the very end rule number.
Speaker 1: Asterisk okay, stateless subnet level order matters allow and deny rules.
Speaker 1: So where's the common mistake?
Speaker 2: Often people forget the stateless nature of nacls and don't
Speaker 2: add the return traffic rules, or they mess up the
Speaker 2: rule order, having a d and an Y rule that
Speaker 2: accidentally blocks traffic they intended to allow because it comes
Speaker 2: before the allow rule. Because they're at the subnet level.
Speaker 2: A misconfigured NaCl can cut off a whole group of instances.
Speaker 1: Got it. Be careful with nacls now. This race is
Speaker 1: an important question. Load balancers. We usually think of them
Speaker 1: for performance and availability, but how do they fit into
Speaker 1: the security and traffic flow picture, especially the different types?
Speaker 2: Absolutely critical role for both. Okay, let's bring it down first.
Speaker 2: Network load balancers or nlbs. These operate down at layer
Speaker 2: thirty four the network and transport layers. They look at
Speaker 2: IP addresses and ports, typically using a five touple hash
Speaker 2: source it st IP sources support protocol to distribute connections.
Speaker 1: Okay, lower level, what's key about them? For security?
Speaker 2: A key feature of nlbs is that they preserve the
Speaker 2: original client source IP address when forwarding traffic to the
Speaker 2: back end instances. This is super sportant for logging, security analysis,
Speaker 2: or applying IP based rules on the back end. Also,
Speaker 2: because they operate at layer four, they're often used for
Speaker 2: inserting third party network virtual appliances and vas like firewalls
Speaker 2: or intrusion detection systems into the traffic path non disruptively.
Speaker 1: Ok. NLB layer four keeps client IP good for mvas.
Speaker 1: What about albs.
Speaker 2: Application load balancers or albs? These are smarter, operating up
Speaker 2: at layer seven the application layer hgtph GTPs. They can
Speaker 2: make routing decisions based on things like the requested urlpath
Speaker 2: like images are appy hosttheaders, gray string parameters, even HTTT.
Speaker 1: Method much more granular routing.
Speaker 2: Exactly, and a big function of alb's is TLS termination.
Speaker 2: They handle the HTTPS decryption encryption, offloading that compute intensive
Speaker 2: work from your back end web servers.
Speaker 1: That sounds good for performance any security implications.
Speaker 2: Yes, while offloading TLS is efficient, it does mean the
Speaker 2: connection between the ALB and your back end instance is
Speaker 2: typically unencrypted HTTP unless you specifically configure re Encryptionechnically, it
Speaker 2: breaks into end encryption within your VPC boundary. There Also,
Speaker 2: because the ALB terminates the connection, the back end instance
Speaker 2: doesn't see the original client IP directly. It sees the
Speaker 2: alb's IP.
Speaker 1: Ah, so you lose the client IP.
Speaker 2: You do unless the ALB adds the x forwarded four
Speaker 2: HTTP header and your applications configure to read and trust
Speaker 2: that header to find the original client IP. Many web
Speaker 2: frameworks do this, but it's an extra step.
Speaker 1: Okay. ALB layer seven smart routing TLS termination with caveats
Speaker 1: needs x foard the four or for client IP. What's
Speaker 1: the third type GLB.
Speaker 2: Keitway load balancers or glbs. These are a bit different
Speaker 2: They are specialized built on NLB technology, but designed specifically
Speaker 2: for simplified service insertion of MVAS, particularly security appliance is
Speaker 2: like firewalls, IPS, sides, et cetera.
Speaker 1: How do they simplify it Compared to using an NLB
Speaker 1: for MVAS.
Speaker 2: Glb's use a special tunneling protocol called genety encapsulation. Essentially,
Speaker 2: when traffic hits the GLB, it wraps the original network
Speaker 2: packet in another packet, the genev packet, and sends it
Speaker 2: to one of the registered security appliances.
Speaker 1: NVA's okay, it puts the packet in a package.
Speaker 2: Why because this preserves the entire original packet headers and
Speaker 2: all the security appliance can inspect it fully see the
Speaker 2: original source and destination everything. Then, after inspection, the appliance
Speaker 2: sends the potentially modified or approved back it back to
Speaker 2: the GLB. Still encapsulated, the GLB unwraps it and sends
Speaker 2: the original packet on its way.
Speaker 1: Ah, so the NVA doesn't even need to know about
Speaker 1: the network routing. It's exactly the GLB handles all the
Speaker 1: routing complexities. The NVA just receives packets, inspects them, and
Speaker 1: sends them back It makes the security appliance fleet function
Speaker 1: like a transparent bump in the wire, super elegant for
Speaker 1: deploying security services scalably.
Speaker 2: That is clever is shifting from network traffic security to
Speaker 2: DNS security equally vital. How does AWS Root fifty three
Speaker 2: help lock down DNS both for the Internet and internally?
Speaker 1: Where fifty three is aws's DNS service and it plays
Speaker 1: a big role. First, you have public hosted zones. These
Speaker 1: manage DNS records for your Internet routable domain names like
Speaker 1: your company's website. Standard DNS stuff, right. But then you
Speaker 1: also have private hosted zones. These are associated with one
Speaker 1: or more of your vpcs and manage DNS records for
Speaker 1: internal domain names that should only be resolvable from within
Speaker 1: those vpcs, like Service.
Speaker 2: Dot, Internal dot Corp exactly. This allows you to have
Speaker 2: a split DNS or split horizon DNS architecture. Your internal
Speaker 2: servers or instances within the VPC can resolve both internal
Speaker 2: names from the private hosted zone and external Internet names
Speaker 2: via standard DNS resolution. It keeps your internal namespace private
Speaker 2: and secure, preventing internal host names or service names from
Speaker 2: leaking or being resolved externally.
Speaker 1: That makes sense for separating internal and external views. What
Speaker 1: about those advanced Route fifty three routing policies The sources
Speaker 1: listed simple failover, latency weighted, geolocation. Can you quickly unpack
Speaker 1: what each is for.
Speaker 2: Sure offer powerful traffic managing capabilities. Simple is just basic
Speaker 2: round robin DNS no health check standard failover is for
Speaker 2: active passive setups. You define a primary record and a
Speaker 2: secondary record. If the primary resource becomes unhealthy based on
Speaker 2: Root fifty three health checks, Root fifty three automatically starts
Speaker 2: returning the secondary records. IP think the old Twitter failwaale.
Speaker 1: Page okay, high availability YEP.
Speaker 2: Latency based routing is cool. Root fifty three has data
Speaker 2: on network latency from different parts of the Internet to
Speaker 2: AWS regions. It directs users to the AWSN point like
Speaker 2: a load balancer or instance in a specific region that
Speaker 2: provides the lowest latency for.
Speaker 1: Them, directing users to the closest healthy server latency wise.
Speaker 2: Exactly weighted routing lets you distribute traffic across multiple resources
Speaker 2: based on percentages you define. You could send ninety percent
Speaker 2: of traffic to your stable version and ten percent to
Speaker 2: a new version for EV testing, or just balance load
Speaker 2: across endpoints. Unevenly if needed, useful for rollouts very and
Speaker 2: geolocation routing lets you wrap traffic based on the user's
Speaker 2: actual geographic location, like sending all European users to your
Speaker 2: Frankfort Regent servers and all US users to your Virginia
Speaker 2: region servers. Good for localization or data sovereignty.
Speaker 1: Got it? And finally, what about DNSEC? What problem does
Speaker 1: that solve? Is it about encryption?
Speaker 2: Good question. Dns sec is not about encrypting DNS queries
Speaker 2: or responses. Its purpose is authentication and integrity. It uses
Speaker 2: digital signatures and public key cryptography to allow a DNS
Speaker 2: resolver like your ISP's resolver or a public onelike Google's,
Speaker 2: to verify that the DNS records that receive actually came
Speaker 2: from the authoritative DNS server and haven't been tampered with
Speaker 2: in transit.
Speaker 1: So it prevents DNS spoofing or cash poisoning exactly.
Speaker 2: It builds a chain of trust from the root DNAs
Speaker 2: servers down to your domain, ensuring the IP address you
Speaker 2: get back for a host name is authentic. It's about trust,
Speaker 2: not confidentiality.
Speaker 1: Okay, authentication and integrity for DNS makes sense. Yeah, now
Speaker 1: let's zoom out Again, we've talked about the components, the connections,
Speaker 1: the security. How is all this modern cloud infrastructure actually
Speaker 1: built and managed? Especially at scale? This brings us to
Speaker 1: ideas like DevOps and crucially in structure as code or IAC.
Speaker 1: What's the core philosophy here right?
Speaker 2: DevOps broadly is about breaking down silos between development and
Speaker 2: operations teams, focusing on automation, collaboration, and faster, more reliable
Speaker 2: software delivery. Infrastructure is code or IAC is a key
Speaker 2: practice enabling DevOps for infrastructure?
Speaker 1: And what's the central idea of IIC?
Speaker 2: The core idea is managing and provisioning your infrastructure, your servers, networks, databases,
Speaker 2: load balancers, everything through machine readable definition files using code
Speaker 2: rather than manual configuration or clicking around in a console.
Speaker 2: It's about making your infrastructure ephemeral andmaleable.
Speaker 1: Ephemeral and malleable meaning easily created, destroyed, change precisely.
Speaker 2: You treat your infrastructure definitions like application code, and this
Speaker 2: leads to arguably the most game changing insight of IIC,
Speaker 2: the concept of immutability.
Speaker 1: Immutability that sounds important, What does that actually mean when
Speaker 1: you're managing cloud resources? Why is it such a big deal?
Speaker 1: For reliability and speed.
Speaker 2: Fundamental paradigm shift immutability means that once infrastructure is deployed,
Speaker 2: say a server or a cluster, you don't make changes
Speaker 2: to it directly. You don't log in and patch it
Speaker 2: or reconfigure it.
Speaker 1: In place, So no patching. How does that work?
Speaker 2: If you need to update or change something, apply a patch,
Speaker 2: deploy new code, change it, config you don't modify the
Speaker 2: existing infrastructure. Instead, you build a new instance or set
Speaker 2: of instances from your updated IAC definition which includes the
Speaker 2: patch or new code. Deploy the new set, test it,
Speaker 2: switch traffic over, and then you simply destroy the old
Speaker 2: unchanged infrastructure.
Speaker 1: The whole cattle not pets analogy exactly.
Speaker 2: You don't nurse sick pet servers back to health. You
Speaker 2: replace the disposable cattle units. Yeah. You treat your infrastructure
Speaker 2: definitions like source code, store them in version control depositories
Speaker 2: like get, use declarative specification documents like YAML for cloud formation,
Speaker 2: and rely on automation to deploy consistently.
Speaker 1: And the benefit isn't just avoiding manual work.
Speaker 2: No, the core benefit isn't primarily cost savings, although that
Speaker 2: can happen. It's about speed, consistency, and safety Deployments become
Speaker 2: repeatable and predictable. Rollbacks are easier. Just redeploy the previous
Speaker 2: version of the code. Drift between environments is minimized. If
Speaker 2: there's a problem, you don't spend hours troubleshooting a potentially
Speaker 2: broken server. You just redeploy a known good state from
Speaker 2: code in minutes. It fundamentally changes how you approach operations.
Speaker 1: That's a really powerful concept. Okay, So focusing on aws's
Speaker 1: main iac tool, AWS CloudFormation, how do its templates enable
Speaker 1: this immutable approach.
Speaker 2: CloudFormation templates are where you define your AWS resources declaratively,
Speaker 2: usually in Yamel or JSON. You state what you want
Speaker 2: like I want a VPC with this cid R block,
Speaker 2: I want two subnets inside it. I want an EC
Speaker 2: two instance with this AMI and one subnet. You don't
Speaker 2: specify the how like the API calls to make. CloudFormation
Speaker 2: figures that out.
Speaker 1: So you declare the desired state exactly.
Speaker 2: And the power comes from features within the templates. You
Speaker 2: have parameters which let you pass in values ad deployment time,
Speaker 2: like the vpc, CIDR block, or the instance type or
Speaker 2: maybe an environment name devastating PROD. This makes templates reusable.
Speaker 1: Okay, parameters for reusability, what else.
Speaker 2: And you have intrinsic functions. These are special functions you
Speaker 2: can use right inside the template code, things like differ
Speaker 2: lets you reference the ID or attribute of another resource
Speaker 2: defined in the same template, like getting the idea of
Speaker 2: the VPC to create a subnet in it, get at
Speaker 2: fetches an attribute. Sitor can calculate subnet CIDR blocks based
Speaker 2: on a main VPC block. Select can pick an item
Speaker 2: from a list, maybe an availability zone. These functions allow
Speaker 2: you to create dynamic, interconnected infrastructure definitions without hard coding everything.
Speaker 1: So templates define the what parameters make them reusable, and
Speaker 1: functions add dynamic capabilities.
Speaker 2: Got it and quickly. For developers who might prefer Python
Speaker 2: or Java overwriting YAML, what's the AWS Cloud Development Kit
Speaker 2: or CDK. CDK is another way to do iac On
Speaker 2: aws IT lists, developers define their cloud infrastructure using familiar
Speaker 2: programming languages Python, Typescript, Java, c shark Go. You write
Speaker 2: code using CDK constructs, which represent AWUS resources.
Speaker 1: So you write Python code to define a VPC YEP, and.
Speaker 2: Then when you run the CDK toolkit, it synthesizes your
Speaker 2: Python code or whatever language you used into a standard
Speaker 2: AWS CloudFormation template.
Speaker 1: Ah, so it generates the CloudFormation for you exactly.
Speaker 2: The benefit is you can use the power of your
Speaker 2: programming language loops, conditionals, object oriented programming, existing libraries, code
Speaker 2: completion in your ide to define infrastructure. You can create
Speaker 2: reusable components and patterns more easily than with raw CloudFormation templates.
Speaker 2: Sometimes it's particularly good for complex applications or for teams
Speaker 2: already comfortable with those programming languages, allowing them to define
Speaker 2: both their app and its infrastructure in the same language ecosystem.
Speaker 1: Very cool, leveraging programming skills for infrastructure. Okay, huh, that
Speaker 1: was quite the journey. So there you have it, a
Speaker 1: real deep dive pulling back the layers on AWS networking.
Speaker 1: We went from the basic virtual network cards, the e
Speaker 1: andi's and wrestled with the hyperplane's.
Speaker 2: Hidden limits of those PPS limits right.
Speaker 1: Then we looked at all the ways to connect things peering, TGW,
Speaker 1: direct connect, and the security layers from shield and wef
Speaker 1: down to sgs nacls, plus the nuances of different load balancers,
Speaker 1: and finally how modern teams actually build and manage all
Speaker 1: this using infrastructure as code.
Speaker 2: It really shows how AWS provides this incredibly rich toolkit
Speaker 2: right for control, for monitoring, for automation. It turns what
Speaker 2: could be overwhelming complexity into manageable patterns, which is what
Speaker 2: ultimately enables all that innovation we see happening in the cloud. Absolutely,
Speaker 2: and I think understanding these layers, you know, from the
Speaker 2: foundational e andi's the strategic use of transit gateways, all
Speaker 2: the way to that philosophical shift towards the infrastructure as code,
Speaker 2: it means you're not just like using cloud services passively,
Speaker 2: You're truly starting to harness their underlying power.
Speaker 1: Yeah, understanding the physics behind the magic exactly.
Speaker 2: It encourages us, encourages you listening to look beyond the
Speaker 2: console surface and constantly ask, Okay, what hidden network physics
Speaker 2: might be a play here, and how can we leverage
Speaker 2: that or maybe mitigate its effects to build something even better,
Speaker 2: even more innovative.
Speaker 1: That is a powerful thought to leave everyone with, isn't it?
Speaker 1: How can you leverage or mitigate those hidden physics? Fantastic? Well,
Speaker 1: thank you for joining us on this deep dive. Until
Speaker 1: next time, keep that curiosity well fed.