Skip to main content
This lesson covers practical security patterns and recommendations for AWS network services: Network Load Balancers (NLB), Gateway Load Balancers (GWLBe), transit networking (Site-to-Site VPN, Direct Connect, Transit Gateway, VPC peering), VPC endpoints / PrivateLink, CloudFront edge protections, and Route 53 resiliency and DNS security. Key goals:
  • Place controls at the right layer (load balancer vs instance vs subnet).
  • Prefer security groups for stateful, host-level filtering and NACLs for stateless, subnet-level defense in depth.
  • Centralize routing where it simplifies operations (Transit Gateway) and insert inspection points where required (GWLBe).
  • Keep sensitive traffic inside AWS with PrivateLink and protect sensitive application fields using field-level encryption at the edge.

​
Network Load Balancer (NLB) — UDP game traffic

Scenario
  • Real-time multiplayer game runs on EC2 instances in a VPC. Backends require low latency and support for UDP.
  • NLB is evaluated because it supports UDP and operates at Layer 4.
Security guidance
  • Restrict ingress to the game UDP port at the load-balancing boundary:
    • Where supported, apply a security group on the load-balancer-target boundary (or on the targets themselves).
    • NACLs remain useful as a stateless, subnet-level filter; use them for defense in depth.
  • Prefer security groups for stateful, host-level access control (they track connection state).
  • Use NACLs to enforce broad subnet-level allow/deny rules (e.g., restrict widely-scoped ports or CIDR ranges).
Best practices checklist
  • Enforce the specific UDP port at the most appropriate boundary (ALB/NLB security group or target security group).
  • Use NACLs to allow necessary inbound/outbound traffic and deny everything else by default.
  • Monitor for anomalous traffic patterns and throttle or blackhole as needed.
AWS WAF protects application-layer HTTP(S) traffic and integrates with ALB and CloudFront. It does not protect raw UDP traffic handled by an NLB—use NACLs, security groups, or inline appliance inspection for UDP.

​
Gateway Load Balancer (GWLBe) — virtual appliance inspection and filtering

Overview
  • Gateway Load Balancers enable inline insertion and scaling of virtual appliances (firewalls, IDS/IPS, DPI).
  • Typical flow:
    1. Application subnet routes traffic to a Gateway Load Balancer Endpoint (GWLBe).
    2. GWLBe forwards flows into the Gateway Load Balancer.
    3. GWLB distributes flows to appliance instances for inspection.
    4. Appliances return traffic back through the GWLBe; traffic proceeds to the original destination (for example, out to the Internet Gateway if approved).
Use cases
  • Centralized threat inspection for east-west and north-south traffic.
  • Managed scaling of virtual appliances using GWLB autoscaling groups.
Operational notes
  • Appliances must be able to handle the expected throughput and stateful flows.
  • Monitor appliance health and ensure proper route table entries and target registration.
A network diagram titled "Gateway Load Balancers" showing an AWS architecture with an Application VPC and Appliance VPC connected via a Gateway Load Balancer endpoint, route tables, and an Internet Gateway. Arrows show traffic flowing through the GWLBe to a cluster of firewall appliances and back out to the internet.

​
Transit networking

This section contrasts common transit and connectivity options: Site-to-Site VPN, Direct Connect, VPC peering, and Transit Gateway. Choose the right tool based on latency, security, scale, and topology requirements.

​
Site-to-Site VPN (IPsec)

Scenario
  • A healthcare organization needs encrypted, reliable connectivity between an on-premises datacenter and AWS (patient data transfer).
Recommended approach
  • Use AWS Site-to-Site VPN with IPsec and dynamic routing (BGP) for resilient, encrypted transit over the public internet.
  • For scale or centralized routing, terminate VPN at a Transit Gateway or a virtual private gateway depending on topology.
Example (VPN terminating at Transit Gateway)
A network diagram showing a site-to-site VPN over the Internet connecting a corporate data center to an AWS region. The AWS Transit Gateway routes traffic from the VPN to multiple VPCs labeled Production, Test, Development and Infrastructure/Shared Services.
When to use VPN
  • Secure, encrypted connectivity without dedicated circuits.
  • Fast to provision and cost-effective for small-to-medium bandwidth.
Use case
  • Multinational with heavy, latency-sensitive workloads needing predictable throughput and reduced public internet variability.
Important distinctions and secure patterns
  • Direct Connect is a dedicated physical/electrical link to AWS that does not traverse the public internet.
  • Direct Connect by itself is not necessarily encrypted. Secure options:
    • Run a VPN over Direct Connect to provide IPsec encryption.
    • Use MACsec (where supported by your Direct Connect provider) for link-layer encryption.
  • Typical flow: Customer datacenter → Direct Connect partner/co-location → Direct Connect → AWS (virtual interface to a virtual private gateway or Transit Gateway).

​
VPC peering — non-transitive, point-to-point

Scenario
  • Three VPCs (DEV, UAT, PROD) in the same region. UAT is peered with both DEV and PROD. Can DEV talk to PROD via UAT?
Core rule
  • VPC peering is point-to-point and non-transitive. Traffic does not route through a peered VPC to reach a third VPC.
  • If DEV must talk to PROD, either:
    • Create a direct peering connection between DEV and PROD, or
    • Use a Transit Gateway to centralize routing.
A slide showing an AWS networking scenario: three VPCs (DEV, UAT, PROD) where UAT is peered to both and a question asking how to enable pushing minor releases from DEV to PROD. Four multiple-choice answer options about route table entries, creating a direct peering, doing nothing, or using overlapping CIDRs are shown.

​
Transit Gateway — hub-and-spoke for many VPCs and on-premises

Use case
  • Organizations with many VPCs or multiple on-premises connections want a simpler, scalable model than a full mesh of VPC peering.
What Transit Gateway provides
  • Centralized routing between VPCs and on-premises networks.
  • Route tables and attachments to control which attachments can communicate.
Security considerations
  • Transit Gateway centralizes routing but does not automatically inspect or encrypt traffic.
  • Retain security at the VPC edge (security groups, NACLs, host-level controls).
  • For centralized inspection, place appliances behind a Gateway Load Balancer and route traffic through them.
Options for securing traffic to Transit Gateway
A colorful infographic posing a scenario about securing data traversing an AWS Transit Gateway for a retail company's VPCs. It lists four numbered answer options describing different approaches (allow all traffic; use security groups/NACLs; use Transit Gateway route tables; use individual VPC peering).
Example topology (VPN → Transit Gateway → VPCs)
A network diagram showing a corporate data center connecting via a site-to-site VPN over the Internet to an AWS Transit Gateway, which routes traffic to multiple VPCs (Production, Test, Development, Infrastructure/Shared Services).
Practical tips
  • Use Transit Gateway route tables and attachment-based route propagation to restrict cross-VPC traffic.
  • Consider AWS Transit Gateway Network Manager for topology visualization and policy enforcement.
  • Combine Transit Gateway with GWLB when inline inspection is required.
Types
  • Gateway endpoints (S3, DynamoDB): configured via route table entries; only for S3 and DynamoDB.
  • Interface endpoints (PrivateLink): ENIs placed in your subnet(s), representing a private connection to an AWS service or a service in another AWS account.
Use case
  • Microservice in a VPC needs to access Secrets Manager without leaving the AWS network.
Recommended approach
  • Create an interface VPC endpoint (PrivateLink) for Secrets Manager.
  • Attach a security group to the interface endpoint to restrict which IPs or security groups may connect to it.
  • Remember that NACLs are subnet-level and are not directly attached to the endpoint; use security groups to control access to interface endpoints.
Important considerations
  • PrivateLink only reaches services that expose an interface endpoint (including cross-account PrivateLink services). It does not provide access to arbitrary Internet-hosted APIs.
  • Gateway endpoints are limited to S3 and DynamoDB.
Quick comparison table

​
Edge networking — CloudFront protections

CloudFront field-level encryption
  • Use case: Protect sensitive form fields (for example, credit card numbers) at the edge before data reaches the origin.
  • How it works:
    • Configure CloudFront with an encryption profile containing the public key.
    • Configure your application to indicate which form fields CloudFront should encrypt.
    • The viewer-to-edge path is protected with TLS; CloudFront additionally encrypts the configured fields within the request payload so the origin can decrypt with the private key.
  • Notes:
    • Field-level encryption protects selected application payload fields in transit; server-side encryption and KMS protect data at rest.
    • Use KMS and secure key management for origin-side decryption and storage.
CloudFront Functions vs Lambda@Edge
  • CloudFront Functions:
    • Lightweight, sub-millisecond execution at the viewer edge.
    • Ideal for header rewrites, redirects, lightweight request/response manipulation.
    • Do not embed secrets in code; follow least-privilege principles.
  • Lambda@Edge:
    • More feature-rich, supports multiple CloudFront event types and longer execution time.
    • Use when you need heavier processing near the edge.
    • Store secrets in a managed secrets store (Secrets Manager / KMS) rather than code/config.
Deploy CloudFront Functions and Lambda@Edge with minimum privileges. Do not hard-code secrets in functions—use AWS Secrets Manager or KMS and restrict access via IAM roles.

​
Route 53, DNS security, and Application Recovery Controller

DNS security with Route 53
  • Recommendations:
    • Restrict changes to hosted zones and records via granular IAM policies.
    • Enable DNSSEC for your domain registrations and where supported to validate authenticity of DNS responses.
    • Use Route 53 Resolver rules to forward queries to on-premises resolvers when centralized resolution is required.
    • Do not grant public write access to DNS records.
A network architecture diagram showing AWS Route 53 with a private hosted zone set as Primary and Standby across two regions (N. Virginia and N. California). Each region has a VPC public subnet with EC2 instances (clients and web servers) and the two VPCs are connected via VPC peering.
Route 53 Application Recovery Controller
  • Use case: Rapidly recover or redirect application traffic during failures; manage readiness checks and recovery groups.
  • Recommended approach:
    • Implement the Application Recovery Controller to define recovery groups and readiness checks.
    • Model component dependencies accurately so recovery actions are safe and predictable.
    • Protect recovery operations with least-privilege IAM policies and multi-person approval workflows if required.
Recovery example (active/standby regions with DynamoDB global tables)
A diagram titled "Route 53 Application Recovery Controller" showing an AWS architecture where Route 53 directs inbound traffic to an active us-east-1 region (with TicTacToe game servers across AZs) and a standby us-west-1 region, both tied to a global Amazon DynamoDB table.
High-level recommendations
  • Place controls at the correct layer:
    • Load balancer boundary (NLB/ALB) for port/protocol filtering where possible.
    • Security groups for stateful, host-level filtering.
    • NACLs for stateless, subnet-level filtering and defense-in-depth.
  • Encrypt transit based on risk:
    • Use Site-to-Site VPN or VPN over Direct Connect for encrypted links.
    • Use MACsec and/or VPN on top of Direct Connect where available and required.
  • Centralize routing when helpful (Transit Gateway) and centralize inspection with GWLB when inline inspection is required.
  • Keep traffic inside AWS with PrivateLink when connecting to AWS services or partner-owned services.
  • Protect sensitive application fields at the edge with CloudFront Field-Level Encryption and protect secrets via KMS/Secrets Manager.
  • Secure DNS and recovery operations with IAM, DNSSEC, Route 53 Resolver, and Application Recovery Controller.
Quick reference table
Thanks for following this lesson on Turning Up Security for Network Services. If you have questions, reach out to michael@goglides.com or in the community forums / Slack.

Watch Video

Practice Lab