Certified: The GIAC GCLD Audio Course

Networking primitives quietly shape reachability, exposure, and lateral movement, which is why cloud incidents so often involve someone misunderstanding how traffic can actually flow. In this episode, we focus on the core building blocks of cloud networking and how their routing behaviors determine what can talk to what, under what conditions, and through which paths. Many teams treat networking as a one-time setup, but in practice it is an evolving system of boundaries and exceptions that changes as applications scale, as teams add services, and as connectivity requirements grow. When you understand the primitives, you stop guessing about exposure and you start reasoning about it, which is essential for both security design and incident response. You also become better at identifying when a configuration change creates unintended reachability, because you can trace the consequences in your head instead of relying on hope. The goal is not to become a network engineer overnight, but to build a working mental model that aligns with how cloud platforms implement virtual networks. When that model is clear, segmentation decisions become more reliable and troubleshooting becomes far faster.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

A Virtual Private Cloud (V P C) or Virtual Network (V N E T) is an isolated virtual network in the cloud that provides the foundational boundary for private addressing, routing, and security controls. You can think of it as the container for your internal network space, where you define IP ranges, segment traffic, and decide what connectivity exists between your workloads and the outside world. Isolation does not mean absolute separation from everything else, because V P C and V N E T designs usually include connectivity options to other networks, services, and the internet, but those connections must be explicitly configured. This is why V P C and V N E T are often the first place you express security intent, such as separating production and development, isolating sensitive systems, and constraining where public access is allowed. Within that boundary, you control routing behavior, which decides whether a packet stays internal, crosses to another segment, or leaves the network entirely. You also attach security controls that determine whether allowed routes are actually usable by traffic. When people say cloud networking is software-defined, this is what they mean: the network is built from defined primitives, and behavior follows configuration rather than physical cabling.

Subnets are segments within a V P C or V N E T that subdivide the address space and provide a way to apply separate routing and controls. A subnet is not just an IP range; it is also a unit of organization that influences where workloads are placed and how traffic is shaped. Subnets often represent different trust zones, such as public-facing segments for entry points, private segments for application workloads, and more restricted segments for data stores or shared services. The separation is useful because you can attach different route tables, security controls, and monitoring expectations to different subnets, making it easier to enforce least exposure patterns. However, subnets are not magic walls, and their security value depends on routing and filtering decisions, not on the existence of a subnet label. Subnet design becomes most effective when it reflects clear intent, such as minimizing what is reachable from the internet and limiting east-west traffic between workloads. It also supports operational clarity, because teams can reason about where workloads belong and what connectivity should exist. When subnets are used thoughtfully, they become the scaffolding that makes segmentation practical.

Route tables are the rules that decide where traffic can go, and they are one of the most important primitives to understand because they determine reachability at a fundamental level. A route table typically matches destination prefixes, such as a subnet range or a broader network range, and specifies the next hop, which could be internal routing, a gateway, a network appliance, or another connection. If a route exists, traffic has a path; if no route exists, traffic cannot reach that destination even if security rules would otherwise allow it. That distinction matters because security groups and network access controls often get more attention, but routing is the first question: is there a path at all. Route tables can be associated with subnets, and different subnets can follow different routing logic, such as a private subnet that routes outbound traffic through a N A T device while a public subnet routes directly to an internet gateway. Route tables also play a key role in connecting to other networks, such as on-premises environments or peered virtual networks, and those connections can dramatically expand lateral movement potential if not carefully constrained. Understanding route tables means you can explain why traffic is flowing, not just observe that it is flowing.

Gateways and N A T are the primitives that create paths to and from the internet, and they are a common source of exposure confusion. An internet gateway is a component that enables traffic between a virtual network and the public internet when routing and security controls allow it. In many architectures, only specific subnets are intended to have direct internet reachability, and those subnets are often used for hardened entry points rather than for sensitive workloads. Network Address Translation, or N A T, is commonly used to allow outbound internet access from private subnets without allowing inbound internet-initiated connections to those workloads. The key idea is that N A T supports outbound connectivity while preserving a form of inbound reachability restriction, but it is not a security control by itself, because outbound connectivity can still enable data exfiltration and command-and-control if other controls are weak. Gateways and N A T devices also interact with route tables, because the route table decides whether traffic will use them at all. If a private subnet accidentally has a default route to an internet gateway rather than to a N A T path, the subnet may effectively become public from a routing perspective. Understanding gateways and N A T is therefore essential for preventing unintentional exposure and for diagnosing how internet connectivity is actually occurring.

Security groups and network access control lists are traffic permission layers that sit on top of routing and decide whether a permitted path can actually be used. A security group is typically a stateful rule set applied at the workload or interface level, allowing you to specify which inbound and outbound traffic is permitted based on ports, protocols, and source or destination ranges. Stateful behavior means that return traffic for an allowed connection is typically permitted automatically, which simplifies design but also requires careful thinking about what inbound connections are allowed in the first place. Network access control lists are often stateless controls applied at the subnet boundary, meaning they evaluate inbound and outbound traffic separately and require explicit rules for both directions. The combination can be powerful because you can enforce broad subnet-level restrictions while also applying more precise workload-level rules. The common mistake is to treat one layer as sufficient, but layered permissions provide defense in depth when designed with intent. Another practical point is that permissive outbound rules are common and can undermine segmentation, because if everything can talk out to everything, lateral movement becomes easier once an attacker gets inside. Permission layers should therefore be designed alongside routing, not as an afterthought, because routing decides the possible paths and permissions decide which paths are usable.

Tracing one packet path from the internet to a workload is an effective way to validate your mental model, because it forces you to reason through every primitive in sequence. Start at the internet edge and identify the entry component that receives the traffic, such as a load balancer or gateway service, then identify which subnet it resides in and what route table applies. Confirm that the route table provides a path to the target workload’s subnet, and then evaluate whether any intermediate components, such as firewalls or routing appliances, influence the path. Next, evaluate the permission layers, including whether the workload’s security group allows the inbound protocol and port from the source, and whether subnet-level access controls allow the traffic in and the return traffic out. Finally, consider how the response packet returns to the client, because asymmetric routing or missing return permissions can create failures that look like application problems. This exercise also highlights where logging should exist, because each hop and control point can generate evidence that helps confirm the path. When you can trace the path cleanly, you can also spot where exposure might occur if a route or rule is changed. This kind of reasoning is exactly what helps teams avoid misconfigurations that only become obvious after an incident.

A major pitfall is assuming subnet boundaries automatically block all lateral movement, which leads to false confidence and overly flat internal connectivity. Subnets separate address space and can separate routing and access controls, but they do not inherently prevent workloads in different subnets from communicating if routing and permissions allow it. In many environments, default routing enables broad internal reachability, and outbound rules are permissive, which means an attacker who compromises one workload can often scan and connect to many other internal targets. Lateral movement becomes especially easy when teams use broad security group rules, rely on implicit trust inside a V P C or V N E T, or fail to restrict east-west traffic between tiers. Another common trap is placing sensitive systems in a private subnet and assuming they are safe because they are not directly internet-facing, while still allowing broad connectivity from application subnets that are easier to compromise. True segmentation requires deliberate constraints on routes and traffic rules, not just subnet labels. The lesson is that subnets are building blocks, but security depends on how you connect and filter those blocks. When you treat subnetting as the start rather than the end of segmentation, your designs become far more resilient.

A practical quick win is to use explicit routes and deny-by-default inbound rules so you can reason about exposure with fewer surprises. Explicit routing means you avoid overly broad default routes that send traffic everywhere, and you prefer narrowly scoped routes that reflect intended connectivity. Deny-by-default inbound rules mean that workloads accept inbound traffic only when there is a clear business need, and the allowed sources are tightly defined, ideally limited to known entry points or trusted internal segments. This approach reduces the chance that a new workload becomes reachable simply because it was placed in a subnet with permissive rules. It also reduces the chance that a rushed change, such as opening a port for troubleshooting, turns into a permanent exposure. Deny-by-default forces teams to justify inbound access and encourages the use of centralized entry points rather than scattered public interfaces. Combined with explicit routing, it creates an environment where connectivity is deliberate and reviewable. The operational benefit is that troubleshooting becomes more systematic because fewer unknown paths exist.

A scenario that tests understanding is a misrouted subnet exposing private resources publicly, which is a common failure mode when routing changes are made quickly. In this scenario, a subnet intended for private workloads accidentally receives a route table association that includes a default route to an internet gateway instead of routing outbound through N A T. If the workloads in that subnet also have public addressing or are attached to interfaces that can be reached through that path, they may suddenly become internet reachable in ways the team did not intend. Even without direct inbound reachability, the misrouting can create unexpected egress pathways that enable external command-and-control or data exfiltration. The investigation hinges on understanding which route table was associated, what routes existed, and which security group and access control rules were in place at the time. Responders must also confirm what was exposed, whether any inbound connections occurred, and whether the change was exploited before it was corrected. This scenario illustrates why routing should be monitored and why changes to route tables are high-risk control-plane events. It also shows how quickly a single routing mistake can collapse the intended trust boundaries of an environment.

Networking primitives should be mapped to logging sources so visibility aligns with design, and flow logs are a common foundation for understanding what traffic actually occurred. Flow logs can provide evidence of accepted and rejected traffic, revealing whether segmentation rules are effective and whether unexpected east-west or outbound patterns exist. When troubleshooting reachability, flow evidence can confirm whether packets are reaching a subnet boundary, whether a security group allowed the connection, and whether traffic is being denied consistently with expectations. Route table changes, gateway configuration changes, and network access control changes are also control-plane events that should be logged and monitored because they can alter connectivity at scale. Mapping primitives to logs helps you choose what to collect, because you can identify which components represent high-impact decision points, such as route associations, gateway attachments, and permission changes. It also helps detection, because network anomalies often show up first as unusual flows, such as unexpected outbound destinations or new internal scanning patterns. When flow logs and control-plane network logs are combined, you can reconstruct both the design intent and the observed behavior. This alignment between primitives and evidence is what makes network investigations tractable.

A helpful memory anchor is roads, intersections, and checkpoints. Routes are the roads that determine where traffic can travel, route tables and associations are the decisions about which roads connect to which neighborhoods, and gateways are the intersections where your network connects to outside worlds. Security groups and network access controls are the checkpoints that decide which vehicles can pass, under what conditions, and in which directions. Subnets are the neighborhoods, defining where workloads live and what local rules may apply. If you add a new road or open a checkpoint without thinking, you may create a shortcut that bypasses the controls you thought were protecting a sensitive area. If you remove a road or misconfigure an intersection, you may break critical connectivity and create outages that look like application failures. The anchor helps because it reinforces that reachability is not one setting, it is the result of multiple linked decisions. When you think in roads and checkpoints, tracing a packet path becomes intuitive and mistakes become easier to spot. That mental model is exactly what cloud networking requires.

As a mini-review, V P C and V N E T are isolated virtual networks that define the foundational boundary for private addressing, routing, and security controls. Subnets segment that network and allow different routing and permission models to be applied to different groups of workloads. Route tables decide where traffic can go, and they are often the first determinant of reachability before any permission checks occur. Gateways and N A T create paths to and from the internet, shaping whether subnets have direct inbound and outbound connectivity or only outbound connectivity through translation. Security groups and network access control lists provide permission layers that allow or deny traffic along the routes that exist, and layered use supports defense in depth. Tracing a packet path validates understanding by forcing you to reason through routing and permissions in sequence. Assuming subnets block lateral movement is a pitfall, while explicit routes and deny-by-default inbound rules are practical quick wins. Visibility through flow logs and control-plane network change logs ties the design to evidence, enabling troubleshooting and detection. When these primitives are understood together, network security becomes a matter of reasoning rather than guessing.

To conclude, draw your mental network map in words today, because the ability to explain your V P C or V N E T design clearly is a strong indicator that you can defend it and troubleshoot it. A verbal map should include which subnets exist, what their intended trust roles are, how route tables connect them, which gateways or N A T paths exist, and what the permission layers allow inbound and east-west. It should also include where public exposure is intentionally permitted and where it is intentionally prevented, because that is where mistakes become most costly. When you can describe the network as a set of deliberate roads and checkpoints, you are less likely to accept vague assumptions about reachability and more likely to catch risky changes early. This habit also improves incident response, because responders can quickly reason about potential lateral movement paths and containment options. The simplest way to improve cloud network security is to make the model clear enough that it can be explained without diagrams. Draw your mental network map in words today.