Tom Adamski, Principal Solutions Architect at AWS specializing in networking, brings a unique perspective to cloud security. With a background spanning economics, ISP operations, and Telco network design, Tom understands how to model complex systems while keeping them manageable.
In this episode, Tom breaks down the fundamentals of network segmentation in AWS, explains why simplicity beats complexity every time, and shares how Zero Trust is transforming network architecture. His “3 AM test” for network design has become a guiding principle for organizations building secure, scalable cloud environments.
You can read the complete transcript of the episode here >
What is network segmentation and why does it matter?
Tom uses a simple analogy to explain network segmentation: think of it like plumbing in a building. You have hot water pipes and cold water pipes—both carry water, but they serve different purposes and should never mix until they reach a specific control point, like a tap.
Similarly, you wouldn’t mix a sewage line with a water pipe unless it went through a treatment facility first. Network segmentation creates these isolated units within your environment.
While it’s possible to run a flat network successfully, segmentation serves as a critical defense-in-depth layer. The primary drivers for implementing it include:
- Risk assessment: Aligning with data classification needs
- Compliance: Meeting requirements like PCI, which mandate keeping payment networks isolated
- Blast radius control: Separating production from non-production environments
- Management plane separation: Preventing human errors in test environments from impacting production
Tom emphasizes that segmentation isn’t just about the data plane (traffic flow)—it also applies to the management and control plane. This separation prevents configuration changes in non-production from accidentally affecting live services.
What is the “3 AM test” for network design?
Tom’s most important rule for network design is what he calls the “3 AM test”:
“Any design needs to pass the 3 AM test, where someone can wake up at 3 AM to get paged, look at the network diagram, and immediately understand what’s going on.”
Cloud environments offer immense flexibility, allowing for highly complex configurations. But complexity often leads to unmanageability. To maintain simplicity:
- Avoid over-granularity: Don’t use the network for extremely granular controls if simpler methods exist
- Understand the limits: AWS Transit Gateway limits route tables to 20 by default to discourage customers from creating a unique route table for every VPC
- Start with requirements: Don’t start with the tool—start with the risk assessment and map it to technical capabilities
- Validate continuously: Use tools like AWS Reachability Analyzer in CI/CD pipelines to verify that paths (e.g., prod to dev) don’t exist after changes
The more complex your network becomes, the harder it is to troubleshoot during an incident. Simplicity isn’t just elegant—it’s essential for operational resilience.
How should you use security groups, NACLs, and firewalls?
These tools should be viewed as an “AND” rather than an “OR”—they provide defense in depth. Each has its place:
Security Groups
- Characteristics: Stateful, default deny, scales to ~1,000 entries
- Best use case: The default starting point for all resources
- When to use: Applied to network interfaces/VMs for granular allow rules
Security groups are always on—you can’t deploy a resource in AWS without one. They’re stateful firewalls that span subnets and IP addresses, making them flexible and powerful.
Network Access Control Lists (NACLs)
- Characteristics: Stateless, limit of 40 entries, default allow
- Best use case: Optional, for broad deny rules
- When to use: Blocking specific ports (e.g., Telnet) or IP ranges across a subnet
NACLs are less commonly used because they’re stateless—if you allow traffic one way, you must remember to allow the reverse flow. Tom recommends using them sparingly for broad use cases like denying specific ports or IP ranges.
Firewalls and Deep Packet Inspection
- Characteristics: Layer 7 inspection, can examine URIs and hostnames
- Best use case: Advanced security requirements
- When to use: When decisions need to be based on packet contents, or when you need scale beyond security group limits
For ingress traffic, consider Web Application Firewall (WAF) for specialized protection against web-based attacks.
Why is the VPC the real segmentation boundary?
This is a crucial insight that differs from on-premise networking:
In AWS, the VPC (Virtual Private Cloud) is the effective segmentation boundary, not the subnet.
Unlike on-premise networks where subnets are separated by routers, all subnets within a VPC can talk to each other implicitly. There’s an implicit router inside every VPC, making it more like a layer 2 network than layer 3.
Key implications:
- Don’t use subnets as security boundaries unless you’re using NACLs
- Think of subnets as containers for IP addresses
- Use VPCs to separate different security levels (production, PCI environments, etc.)
- When traffic leaves the VPC (to Transit Gateway, CloudWAN, etc.), it’s treated as a whole VPC—you can’t get subnet-level granularity
This understanding is critical when designing segmentation strategies in AWS.
How does Kubernetes impact network visibility?
When using Kubernetes (EKS) in AWS, containers receive IP addresses directly from the VPC range through the Container Network Interface (CNI). This makes containers “first-class citizens” in the VPC.
However, there’s an important visibility gap:
The VPC networking layer (Flow Logs, Security Groups) cannot see traffic between two containers on the same worker node.
This traffic never leaves the node, so VPC-level controls don’t apply. To secure this traffic:
- Use Kubernetes-native constructs: Network policies control communication between services and namespaces
- Use security groups for pods: AWS now supports security groups for pods to control access to VPC resources
- Understand the boundary: Traffic leaving the worker node is visible to VPC controls; traffic staying on the node is not
For larger clusters, most traffic will leave the worker node to reach services on other nodes, so VPC-level visibility covers the majority of communication.
How is Zero Trust changing network architecture?
Zero Trust moves security controls beyond simple IP addresses and ports to include identity and context. It builds on top of traditional networking rather than replacing it.
Tom highlights two key AWS services that illustrate this shift:
AWS Verified Access
Replaces traditional remote access VPNs. Users connect to applications over the web, authenticated by an identity provider (Okta, PingOne, etc.). Access decisions are based on:
- User groups and attributes
- Device health (integration with CrowdStrike, Jamf)
- Security posture (antivirus status, encryption)
This provides much more context than traditional VPNs, which only consider username, password, and IP address.
VPC Lattice
An Application Layer 7 proxy for app-to-app communication. It abstracts the underlying network complexity (IPs, load balancers, transit gateways) and allows access policies based on IAM roles.
Key benefits:
- Eliminates mTLS complexity: No need to manage certificates on every client
- Uses IAM credentials: Leverage existing IAM roles and policies
- Simplifies architecture: No need for load balancers or transit gateways for app-to-app communication
Zero Trust doesn’t eliminate traditional network controls—it enhances them with identity and context awareness.
What role do firewalls play in cloud environments?
Firewalls remain the most common security appliance. Almost every conversation about connecting regions or VPCs leads to “how do I firewall this?”
Organizations typically choose between:
- Third-party vendors: Palo Alto, Fortinet, Checkpoint, ValtX—familiar tools with existing skills and tooling
- Native managed services: AWS Network Firewall—no infrastructure management or patching required
Gateway Load Balancer: Solving the Availability Problem
Previously, routing traffic to a firewall appliance was fragile. If the appliance died, the route would blackhole traffic because VPC routes aren’t health-aware.
Gateway Load Balancer (GWLB) solved this:
- Acts as the destination for routes
- Distributes traffic across multiple firewall instances
- Handles health checks and failover automatically
- Enables horizontal scaling by adding more firewall instances
Even AWS Network Firewall uses GWLB under the hood—it’s just managed by AWS so you don’t see it.
What are the best practices for production vs. non-production segmentation?
Tom is emphatic about this: separating production and non-production environments is not just a best practice—it’s essential.
At minimum, separate the data planes:
- Use different VPCs for production and non-production
- Use Transit Gateway with separate route tables for each environment
- Ensure production cannot accidentally communicate with non-production
For the control/management plane, it depends on your change control maturity:
- Strict separation: Use separate Transit Gateways if you’re making frequent, experimental changes in non-production
- Shared management: Use a single Transit Gateway with separate route tables if you have strong automation and CI/CD validation
The key is preventing human errors in non-production from impacting production services.
How should organizations approach remote access in the cloud?
The most common pattern is still remote access VPNs (AWS Client VPN or third-party solutions). Users connect to an endpoint in AWS and land inside a VPC, inheriting whatever connectivity that VPC has.
This is why VPC-level segmentation matters—when you bring remote users into a production VPC, they get production access.
However, the landscape is evolving toward Zero Trust Network Access (ZTNA):
- More context: Beyond IP addresses, consider user identity, device health, and security posture
- Granular policies: Policy-driven access rather than network-level access
- Browser-based: Solutions like AWS Verified Access allow browser-based access without VPN clients
The shift is toward making access decisions based on who is accessing what, not just where they’re connecting from.
What should organizations prioritize for network security?
Tom emphasizes three key priorities:
- Simplicity: If you can’t understand it at 3 AM, it’s too complex
- Defense in depth: Use multiple layers (security groups, NACLs, firewalls) appropriately
- Early security involvement: Include security teams early in the development process, not as a final gate
He also stresses the importance of testing—not just security testing, but availability testing. Practice your failover scenarios and disaster recovery procedures. It’s hard work, but when something really happens, you’ll be prepared.
