Lesson 03 — Enterprise Network Segmentation, VPC Design & Secure Connectivity

Learning Path

☁️ Phase 02 – AWS Cloud Security

📘 Module 12 – AWS Security Architecture

🎯 Lesson Objective

By the end of this lesson, you will be able to:

Explain enterprise network segmentation.
Design secure Amazon VPC architectures.
Differentiate public, private and isolated subnets.
Design secure routing and internet access.
Apply Security Groups and Network ACLs appropriately.
Reduce network attack surface.
Design VPC-to-VPC connectivity.
Explain VPC peering and AWS Transit Gateway.
Design secure hybrid connectivity using VPN and AWS Direct Connect.
Use VPC endpoints and AWS PrivateLink.
Design centralised network inspection.
Apply AWS Network Firewall.
Design DNS security using Amazon Route 53 Resolver.
Apply Zero Trust principles to cloud networking.
Document network flows, trust boundaries and security controls.
Perform an enterprise AWS network security review.

📚 Lesson Information

Estimated Time: 6–7 Hours
Difficulty: Advanced
Prerequisites: Lesson 02 – Secure Multi-Account Architecture, Landing Zones & AWS Security Reference Architecture
Hands-on Labs: Yes
Primary Role: AWS Security Architect / Cloud Network Security Engineer

💼 Business Scenario

CloudNova Technologies is expanding its SecurePay platform across multiple AWS accounts and Regions.

The current environment includes:

Production AWS accounts
Development AWS accounts
Shared services
Centralised security tooling
Hybrid connectivity to on-premises data centres
Internet-facing applications
Internal business applications
Amazon EKS workloads
Amazon ECS services
AWS Lambda functions
Amazon RDS databases
Partner API integrations

A recent architecture assessment identifies several network-security weaknesses:

Production and development workloads share the same VPC.
Databases are deployed in public subnets.
Security Groups allow inbound access from 0.0.0.0/0.
Administrators connect directly through public IP addresses.
All private workloads use a shared NAT gateway.
VPC peering connections have grown without central governance.
DNS queries are not centrally logged.
East-west traffic is not inspected.
On-premises networks have broad access to AWS workloads.
Workloads access AWS services through public endpoints.
Route tables are poorly documented.
No formal network-flow approval process exists.

The CISO asks:

“How can CloudNova design a secure AWS network that isolates workloads, controls connectivity, limits lateral movement and provides central visibility?”

As the AWS Security Architect, you must design the enterprise network architecture.

What Is Network Segmentation?

Network segmentation divides an environment into smaller security zones.

Each zone contains systems with similar:

Business purpose
Trust level
Data sensitivity
Exposure requirements
Compliance obligations
Operational ownership

Enterprise Network

├── Internet-Facing Zone
├── Application Zone
├── Data Zone
├── Management Zone
├── Security Inspection Zone
├── Shared Services Zone
└── Partner Connectivity Zone

Segmentation limits unnecessary communication between systems.

Why Segmentation Matters

Without segmentation:

Compromised Web Server

↓

Access to Application Servers

↓

Access to Databases

↓

Access to Administrative Systems

↓

Enterprise-Wide Impact

With segmentation:

Compromised Web Server

↓

Restricted Security Group

↓

No Direct Database Access

↓

Limited Workload Role

↓

Detection and Isolation

Segmentation helps:

Reduce blast radius
Limit lateral movement
Protect sensitive workloads
Simplify compliance
Improve monitoring
Apply workload-specific controls
Separate environments
Support incident containment

Network Segmentation vs Network Isolation

Segmentation

Systems are separated but controlled communication is permitted.

Application Tier

↓

Approved Database Port

↓

Database Tier

Isolation

Communication is intentionally blocked except through tightly controlled mechanisms.

Restricted Workload

↓

No Direct Network Route

↓

Approved Security Broker or API

Not every workload requires complete isolation, but every connection should have a documented business purpose.

Amazon VPC

Amazon Virtual Private Cloud provides a logically isolated network environment in AWS.

A VPC contains:

IP address ranges
Subnets
Route tables
Internet gateways
NAT gateways
Security Groups
Network ACLs
VPC endpoints
Traffic-monitoring capabilities
Connectivity components

AWS Region

└── Amazon VPC
    ├── Availability Zone A
    │   ├── Public Subnet
    │   ├── Private Application Subnet
    │   └── Isolated Data Subnet
    │
    └── Availability Zone B
        ├── Public Subnet
        ├── Private Application Subnet
        └── Isolated Data Subnet

VPC Design Principles

CloudNova follows these principles:

Design for multiple Availability Zones.
Avoid overlapping CIDR ranges.
Separate workloads by environment.
Separate workloads by sensitivity.
Minimise public IP usage.
Restrict routes.
Use private connectivity where possible.
Inspect traffic at defined boundaries.
Log important network activity.
Automate network configuration.
Document every permitted flow.
Design for future growth.

IP Address Planning

Poor IP planning can create long-term operational problems.

CloudNova must consider:

Number of AWS accounts
Number of Regions
Number of VPCs
Future workload growth
On-premises CIDR ranges
Partner networks
Kubernetes pod ranges
Container workloads
Hybrid connectivity
Mergers and acquisitions

Example Enterprise IP Plan

Enterprise Private Address Space

10.0.0.0/8

├── India Region
│   └── 10.0.0.0/12
│
├── Europe Region
│   └── 10.16.0.0/12
│
├── North America Region
│   └── 10.32.0.0/12
│
├── Shared Services
│   └── 10.48.0.0/12
│
└── Reserved Growth
    └── Remaining Address Space

Each account and VPC receives a non-overlapping CIDR block.

Why Overlapping CIDRs Are a Problem

Example:

Production VPC
10.10.0.0/16

Development VPC
10.10.0.0/16

Direct routing between these VPCs becomes difficult because both networks use the same address space.

Overlapping CIDRs may complicate:

VPC peering
Transit Gateway routing
Hybrid connectivity
Network inspection
DNS resolution
Incident response

Public, Private and Isolated Subnets

Public Subnet

A public subnet has a route to an internet gateway.

Typical resources:

Internet-facing load balancers
NAT gateways
Controlled bastion alternatives where required

A public subnet does not automatically make every resource public. A resource also requires public addressing and suitable routing and security controls.

Private Subnet

A private subnet does not provide direct inbound internet access.

It may use a NAT gateway for outbound internet access.

Typical resources:

Application servers
ECS tasks
EKS worker nodes
Internal load balancers
Lambda VPC integrations

Isolated Subnet

An isolated subnet has no route to an internet gateway or NAT gateway.

Typical resources:

Databases
Sensitive data services
Internal security appliances
Highly restricted workloads

Three-Tier VPC Architecture

                         Internet

                            │

                     Internet Gateway

                            │

              ┌─────────────┴─────────────┐
              │                           │
       Public Subnet A              Public Subnet B
       Load Balancer                Load Balancer
       NAT Gateway                  NAT Gateway
              │                           │
              └─────────────┬─────────────┘
                            │
              ┌─────────────┴─────────────┐
              │                           │
     Private Application A       Private Application B
              │                           │
              └─────────────┬─────────────┘
                            │
              ┌─────────────┴─────────────┐
              │                           │
       Isolated Data A             Isolated Data B

Route Tables

Route tables determine where network traffic is sent.

Each subnet is associated with a route table.

Example public route table:

Destination        Target

10.20.0.0/16       Local
0.0.0.0/0          Internet Gateway

Example private route table:

Destination        Target

10.20.0.0/16       Local
0.0.0.0/0          NAT Gateway

Example isolated route table:

Destination        Target

10.20.0.0/16       Local

Routing Security Principles

CloudNova applies:

Least-route design
Separate route tables by security zone
No default route where unnecessary
Controlled propagation
Documented Transit Gateway routes
Explicit inspection routes
Separate production and non-production routing domains
Change approval for sensitive routes

Internet Gateway

An internet gateway allows communication between a VPC and the internet.

Secure architecture should:

Attach internet gateways only to approved VPCs.
Keep databases and internal workloads in private or isolated subnets.
Avoid assigning public IP addresses to workloads unnecessarily.
Restrict inbound access using edge services and Security Groups.
Monitor public exposure continuously.

NAT Gateway

A NAT gateway allows private resources to initiate outbound internet connections.

Private Workload

↓

Private Route Table

↓

NAT Gateway

↓

Internet Gateway

↓

Internet

Typical uses:

Operating-system updates
Package downloads
External API access
Container-image downloads

NAT Gateway Security Considerations

A NAT gateway does not inspect whether outbound traffic is malicious.

CloudNova should consider:

Restricting outbound destinations
Using VPC endpoints
Centralising egress inspection
Monitoring flow logs
Applying DNS controls
Using AWS Network Firewall
Preventing direct internet access where unnecessary

Centralised Egress Architecture

Workload VPCs

↓

AWS Transit Gateway

↓

Egress VPC

↓

AWS Network Firewall

↓

NAT Gateway

↓

Internet Gateway

↓

Internet

Benefits include:

Central inspection
Consistent egress policies
Central logging
Reduced duplicate infrastructure
Simplified allow-list management

The design must also consider:

Availability
Route symmetry
Throughput
Cost
Failure impact
Cross-AZ traffic
Regional architecture

Security Groups

Security Groups are stateful virtual firewalls associated with supported AWS resources and network interfaces.

They control:

Inbound traffic
Outbound traffic
Protocol
Port
Source
Destination

Stateful Behaviour

If an inbound request is allowed, the response traffic is automatically permitted.

Approved Request

Client → Application

Automatic Response

Application → Client

A separate outbound response rule is not required for return traffic associated with an established permitted connection.

Security Group Referencing

Security Groups can reference other Security Groups.

Example:

Load Balancer Security Group

↓

Application Security Group allows port 443
from Load Balancer Security Group only

↓

Database Security Group allows port 5432
from Application Security Group only

This is more maintainable than permitting broad CIDR ranges.

Enterprise Security Group Pattern

Internet

↓

ALB-SG

Allows:
443 from approved internet sources

↓

APP-SG

Allows:
443 from ALB-SG

↓

DB-SG

Allows:
5432 from APP-SG

Security Group Best Practices

Deny unnecessary access by omitting rules.
Avoid 0.0.0.0/0 for management ports.
Use Security Group references.
Restrict outbound traffic where practical.
Separate rules by application tier.
Add clear descriptions.
Review unused Security Groups.
Remove temporary rules.
Automate rule deployment.
Monitor rule changes.

Network ACLs

Network ACLs are stateless controls applied at the subnet level.

They contain:

Inbound rules
Outbound rules
Rule numbers
Allow actions
Deny actions

Because they are stateless, response traffic must be permitted explicitly.

Security Groups vs Network ACLs

Area	Security Groups	Network ACLs
Applied To	Resource or network interface	Subnet
State	Stateful	Stateless
Rules	Allow rules	Allow and deny rules
Evaluation	All rules evaluated	Evaluated by rule number
Typical Use	Primary workload firewall	Subnet-level guardrail
Return Traffic	Automatically allowed	Must be explicitly permitted

Network ACL Use Cases

Network ACLs may be used to:

Block known malicious CIDR ranges
Add subnet-level protection
Restrict traffic at a trust boundary
Support temporary incident containment
Enforce coarse-grained controls

They should not replace properly designed Security Groups.

Ephemeral Ports

Stateless Network ACLs must account for ephemeral ports used for return traffic.

Example:

Client connects to server port 443

Client source port:
High-numbered ephemeral port

Server response:

Source port 443
Destination ephemeral port

Incorrect Network ACL rules may block legitimate return traffic.

VPC Flow Logs

VPC Flow Logs capture metadata about IP traffic.

They can be configured for:

VPCs
Subnets
Network interfaces

Flow logs may record:

Source address
Destination address
Source port
Destination port
Protocol
Traffic acceptance or rejection
Packets
Bytes
Timestamps
Interface identifiers

Flow Log Architecture

VPC Network Interfaces

↓

VPC Flow Logs

↓

CloudWatch Logs or Amazon S3

↓

Security Analytics

↓

Alerts and Investigation

Flow Log Use Cases

Investigating rejected traffic
Detecting unusual communication
Identifying lateral movement
Reviewing internet exposure
Validating Security Group rules
Supporting incident response
Understanding application dependencies
Creating network baselines

Flow logs do not capture the complete payload content.

Traffic Mirroring

VPC Traffic Mirroring can copy selected network traffic from supported network interfaces to monitoring appliances.

Use cases include:

Deep packet inspection
Intrusion detection
Forensic analysis
Network-performance troubleshooting

Workload Network Interface

├── Normal Traffic → Destination
│
└── Mirrored Traffic → Security Appliance

Traffic Mirroring must be designed carefully due to:

Volume
Cost
Privacy
Storage
Security-tool capacity

VPC Peering

VPC peering connects two VPCs using private IP addresses.

VPC A

↔

VPC Peering Connection

↔

VPC B

Characteristics include:

Private connectivity
No transitive routing
Route-table updates required
Security controls still apply
CIDR ranges must not overlap

No Transitive Routing

Example:

VPC A ↔ VPC B ↔ VPC C

VPC A cannot automatically communicate with VPC C through VPC B.

A separate connection or central routing architecture is required.

VPC Peering Challenges at Scale

A large number of peering connections creates:

Complex routing
Difficult change management
Poor visibility
Difficult troubleshooting
Increased governance overhead

For enterprise environments, AWS Transit Gateway is often more manageable.

AWS Transit Gateway

AWS Transit Gateway acts as a central network routing hub.

                 Production VPC

                        │

Development VPC ── Transit Gateway ── Shared Services VPC

                        │

                  Network VPC

                        │

                On-Premises Network

Transit Gateway Benefits

Hub-and-spoke connectivity
Central route management
VPC connectivity
VPN connectivity
Direct Connect integration
Network segmentation
Centralised inspection
Reduced peering complexity

Transit Gateway Route Tables

Different attachments can use separate Transit Gateway route tables.

Example:

Production Route Table

Allows:
Production → Shared Services
Production → Inspection VPC

Denies:
Production → Development

Development Route Table

Allows:
Development → Shared Services
Development → Inspection VPC

Denies:
Development → Production

This enables network-domain separation.

Transit Gateway Segmentation

AWS Transit Gateway

├── Production Routing Domain
├── Development Routing Domain
├── Shared Services Routing Domain
├── Security Inspection Routing Domain
└── Partner Routing Domain

Connectivity is controlled through:

Attachment associations
Route propagation
Static routes
Blackhole routes
Inspection routing

Centralised Inspection VPC

An inspection VPC hosts network-security controls.

Spoke VPC

↓

Transit Gateway

↓

Inspection VPC

↓

AWS Network Firewall

↓

Approved Destination

The inspection design must preserve symmetric routing.

Symmetric Routing

Stateful firewalls generally require both directions of a network session to pass through the same inspection path.

Incorrect:

Outbound Traffic → Firewall A

Return Traffic → Different Path

Correct:

Outbound Traffic → Firewall A

Return Traffic → Firewall A

Asymmetric routing can cause sessions to fail or bypass inspection.

AWS Network Firewall

AWS Network Firewall provides managed network traffic filtering.

It can support:

Stateful rules
Stateless rules
Domain-list filtering
Protocol filtering
Intrusion-prevention patterns
Central traffic inspection
Network activity logging

Network Firewall Architecture

Workload VPC

↓

Transit Gateway

↓

Inspection VPC

↓

Firewall Endpoint

↓

NAT Gateway or Destination VPC

Stateless and Stateful Rule Processing

Stateless Rules

Evaluate individual packets without maintaining connection state.

Possible actions include:

Pass
Drop
Forward for stateful inspection

Stateful Rules

Evaluate traffic in the context of a connection.

Use cases include:

Domain filtering
Protocol validation
Threat-signature detection
Session-based policy enforcement

VPC Endpoints

VPC endpoints allow private connectivity to supported AWS services without requiring public internet access.

Types include:

Gateway endpoints
Interface endpoints
Gateway Load Balancer endpoints

Gateway Endpoints

Gateway endpoints are commonly used for services such as:

Amazon S3
Amazon DynamoDB

Private Subnet

↓

Gateway Endpoint

↓

Amazon S3

No internet gateway or NAT gateway is required for this path.

Interface Endpoints

Interface endpoints use AWS PrivateLink.

They create network interfaces with private IP addresses inside the VPC.

Private Application

↓

Interface Endpoint

↓

AWS Service

Common uses include private access to:

AWS Secrets Manager
AWS Systems Manager
AWS KMS
Amazon ECR APIs
Amazon CloudWatch
AWS Security Token Service

Endpoint Policies

Endpoint policies can restrict which resources and actions are accessible through an endpoint.

Example security objective:

Production VPC S3 Endpoint

Allows:
Access only to approved production buckets

Denies:
Access to unrelated S3 buckets

Endpoint policies should complement, not replace:

IAM policies
Resource policies
Service Control Policies
KMS key policies

AWS PrivateLink

AWS PrivateLink provides private service connectivity between VPCs and supported services without exposing traffic to the public internet.

Example:

Service Provider VPC

↓

Network Load Balancer

↓

Endpoint Service

↓

Interface Endpoint

↓

Consumer VPC

Benefits include:

Private connectivity
Reduced exposure
No need for full network routing
Service-level access
Overlapping CIDR support in some service-consumption patterns

PrivateLink vs VPC Peering

Area	AWS PrivateLink	VPC Peering
Connectivity	Specific service	Broader VPC network connectivity
Routing	No full bidirectional routing	Route-table based
Exposure	Service endpoint only	Reachable routed networks
CIDR Overlap	Can support service access without broad routing	Not supported
Typical Use	Publish or consume a service privately	Connect two VPC networks

Hybrid Connectivity

CloudNova must connect AWS to:

Corporate data centres
Branch offices
Disaster-recovery sites
Partner environments
Security operations facilities

Common options include:

AWS Site-to-Site VPN
AWS Client VPN
AWS Direct Connect
Transit Gateway
Third-party SD-WAN appliances

Site-to-Site VPN

Site-to-Site VPN creates encrypted tunnels between AWS and an external network.

On-Premises Network

↓

Customer Gateway

↓

Encrypted VPN Tunnels

↓

Virtual Private Gateway or Transit Gateway

↓

AWS VPC

VPN Security Considerations

Use redundant tunnels.
Monitor tunnel health.
Restrict advertised routes.
Apply strong cryptographic settings.
Separate partner and corporate connections.
Log route and configuration changes.
Test failover.
Avoid granting broad network access.

AWS Direct Connect

AWS Direct Connect provides dedicated private connectivity between an external location and AWS.

Corporate Data Centre

↓

Direct Connect Location

↓

Private Virtual Interface

↓

Direct Connect Gateway

↓

Transit Gateway or VPC

Direct Connect does not automatically encrypt traffic at the application layer.

Encryption requirements must be evaluated separately.

Direct Connect and VPN Together

A resilient hybrid design may use:

Primary Path

AWS Direct Connect

Secondary Path

Site-to-Site VPN

Traffic engineering, failover and route priorities must be tested.

AWS Client VPN

AWS Client VPN provides managed remote-user connectivity.

Typical use cases:

Administrators
Developers
Support engineers
Remote employees

Access should be controlled through:

Federated authentication
MFA
Authorisation rules
Network segmentation
Logging
Least privilege

Administrative Access Architecture

Insecure design:

Administrator Laptop

↓

Public Internet

↓

Public EC2 IP

↓

SSH or RDP

Secure design:

Administrator

↓

Identity Provider and MFA

↓

Approved Access Role

↓

AWS Systems Manager Session Manager

↓

Private EC2 Instance

Session Manager reduces the need for:

Public IP addresses
Inbound SSH rules
Inbound RDP rules
Shared private keys
Bastion hosts

Bastion Hosts

Where bastion hosts are required, they should be:

Highly restricted
Patched
Monitored
Multi-AZ where appropriate
Protected by MFA-driven access
Free from shared credentials
Used only for administration
Logged centrally

Bastion hosts should not become a permanent workaround for poor access design.

DNS Architecture

DNS is a critical part of network security.

CloudNova uses Amazon Route 53 and Route 53 Resolver for:

Public DNS
Private hosted zones
Hybrid DNS resolution
Conditional forwarding
Central DNS governance
DNS query logging

Route 53 Resolver

Route 53 Resolver supports DNS resolution:

Within VPCs
Between AWS and on-premises networks
Through inbound endpoints
Through outbound endpoints
Using Resolver rules

Hybrid DNS Architecture

On-Premises DNS

↓

Resolver Inbound Endpoint

↓

AWS Private Hosted Zones

AWS Workload

↓

Resolver Outbound Endpoint

↓

On-Premises DNS

DNS Security Risks

DNS tunnelling
Malicious domains
Data exfiltration
Unauthorised DNS servers
Misconfigured forwarding rules
Split-horizon inconsistencies
Domain hijacking
Excessive query permissions

DNS Security Controls

CloudNova applies:

Resolver query logging
Central DNS ownership
Route 53 Resolver DNS Firewall
Domain allow and block lists
Restricted outbound DNS
Protected hosted-zone changes
DNSSEC where appropriate
Monitoring of unusual query behaviour

Route 53 Resolver DNS Firewall

DNS Firewall can filter outbound DNS queries based on domain lists.

Workload DNS Query

↓

Route 53 Resolver DNS Firewall

├── Approved Domain → Allow
├── Suspicious Domain → Alert
└── Blocked Domain → Deny

Ingress Security Architecture

CloudNova internet-facing applications use layered controls.

Internet

↓

Amazon Route 53

↓

AWS Shield

↓

Amazon CloudFront

↓

AWS WAF

↓

Application Load Balancer

↓

Private Application Workloads

Benefits include:

DDoS protection
Web-request filtering
TLS termination
Reduced direct origin exposure
Central logging
Global content delivery

Egress Security Architecture

Private Workload

↓

VPC Route Table

↓

Transit Gateway

↓

Inspection VPC

↓

AWS Network Firewall

↓

NAT Gateway

↓

Internet

Egress controls may restrict:

Destination domains
Destination IP addresses
Protocols
Ports
Unapproved software repositories
Data-exfiltration paths

East-West vs North-South Traffic

North-South Traffic

Traffic entering or leaving the environment.

Examples:

Internet to application
Application to internet
On-premises to AWS
Partner to AWS

East-West Traffic

Traffic between internal systems.

Examples:

Application to database
VPC to VPC
Service to service
Account to account
Container to container

East-west traffic requires the same architectural attention as internet traffic.

Microsegmentation

Microsegmentation applies fine-grained controls between workloads.

Frontend Service

↓

Approved API Port Only

↓

Payment Service

↓

Approved Database Port Only

↓

Transaction Database

Microsegmentation can be implemented using:

Security Groups
Kubernetes network policies
Service meshes
Application identity
Workload-specific IAM roles
PrivateLink
Service-level authorisation

Zero Trust Network Principles

CloudNova does not treat network location as sufficient proof of trust.

Every connection should consider:

Source identity
Workload identity
Destination resource
Requested action
Device context
Session context
Data sensitivity
Current risk

Connection Request

↓

Verify Identity

↓

Verify Authorisation

↓

Evaluate Context

↓

Permit Minimum Required Access

↓

Monitor Connection

Network Trust Zones

CloudNova defines the following zones:

Zone	Trust Level	Typical Workloads
Public Edge	Untrusted	CloudFront and public endpoints
Presentation	Restricted	Load balancers and API gateways
Application	Private	ECS, EKS, EC2 and Lambda workloads
Data	Highly Restricted	Databases and sensitive storage
Management	Privileged	Administration and operations
Security	Restricted	Inspection and monitoring services
Partner	Externally Controlled	Third-party connections
Development	Lower Assurance	Development and testing workloads

Network Flow Matrix

Every permitted flow should be documented.

Source	Destination	Port	Protocol	Purpose	Owner
Internet	CloudFront	443	HTTPS	Customer access	Digital Platform
ALB	Application	443	HTTPS	Application traffic	Application Team
Application	Database	5432	TCP	Database access	Database Team
Application	Secrets Manager endpoint	443	HTTPS	Secret retrieval	Security Team
On-premises SOC	Security tooling	443	HTTPS	Security operations	SOC

Network Change Governance

Sensitive changes should require approval.

Examples:

Internet gateway attachment
Public IP assignment
0.0.0.0/0 Security Group rules
Transit Gateway route changes
Direct Connect route advertisements
Firewall-policy changes
PrivateLink service exposure
DNS forwarding changes
VPC peering creation
Network ACL deny rules

Infrastructure as Code for Networking

CloudNova deploys network resources using:

AWS CloudFormation
Terraform
Approved CI/CD pipelines
Policy-as-code controls

Benefits include:

Consistency
Version control
Peer review
Automated validation
Repeatable deployments
Drift detection
Audit evidence
Safer rollback

Example Secure Network Review Pipeline

Network Code Commit

↓

Pull Request

↓

Peer Review

↓

Syntax Validation

↓

Security Policy Scan

↓

Route Analysis

↓

Approval

↓

Deployment

↓

Post-Deployment Validation

↓

Continuous Monitoring

Threat Modelling the Network

CloudNova evaluates threats such as:

Public workload exposure
Lateral movement
Data exfiltration
Route hijacking
DNS tunnelling
Unauthorised partner access
Firewall bypass
Misconfigured Security Groups
Compromised administrative endpoints
Cross-account network access

Example Network Attack Path

Public Application

↓

Application Vulnerability

↓

Compromised EC2 Instance

↓

Unrestricted Outbound Access

↓

Command-and-Control Server

↓

Credential Theft

↓

Access to Internal Database

Breaking the Attack Path

AWS WAF

+

Patched Application

+

Restricted Security Group

+

Restricted Workload IAM Role

+

Egress Inspection

+

DNS Filtering

+

GuardDuty Detection

+

Database Authentication

Centralised Enterprise Network Architecture

                         Internet

                            │

                 CloudFront + WAF + Shield

                            │

                    Application VPCs

                            │

                    AWS Transit Gateway

          ┌─────────────────┼─────────────────┐
          │                 │                 │
     Inspection VPC    Shared Services VPC   Network VPC
          │                 │                 │
 AWS Network Firewall   DNS and Directory   VPN and Direct Connect
          │
     Egress Controls
          │
     NAT Gateway
          │
       Internet

Multi-Account Network Ownership

CloudNova separates responsibilities.

Component	Owning Account
Transit Gateway	Network Account
Direct Connect	Network Account
VPN Connectivity	Network Account
Network Firewall	Network or Security Account
Resolver Endpoints	Shared Services or Network Account
Central Flow Logs	Log Archive Account
Security Findings	Security Tooling Account
Application VPC	Workload Account
Workload Security Groups	Workload Account
Enterprise Network Policies	Central Security and Network Teams

Shared VPC Considerations

AWS Resource Access Manager can share selected network resources across accounts.

Centralised subnet sharing may provide:

Central IP management
Central routing
Consistent network controls
Reduced duplication

It may also introduce:

Shared operational dependencies
Complex ownership
Larger failure domains
Governance challenges

The design should reflect organisational maturity and workload requirements.

Network Resilience

A secure network must also be resilient.

CloudNova designs for:

Multiple Availability Zones
Redundant VPN tunnels
Redundant Direct Connect connections where required
Multiple firewall endpoints
Multiple NAT gateways
Health monitoring
Tested failover
Route-table recovery
Infrastructure-as-Code redeployment
Regional recovery plans

Network Failure Scenarios

Failure	Expected Response
NAT gateway failure	Route traffic through healthy AZ design
Firewall endpoint failure	Use tested fail-safe routing
VPN tunnel failure	Use secondary tunnel
Direct Connect failure	Fail over to backup connectivity
DNS endpoint failure	Use redundant Resolver endpoints
Route misconfiguration	Detect, roll back and restore approved state
Compromised VPC	Isolate Transit Gateway attachment
Malicious endpoint	Block through DNS and firewall controls

Network Monitoring Architecture

CloudNova collects:

VPC Flow Logs
AWS Network Firewall logs
Route 53 Resolver query logs
Transit Gateway Flow Logs
Elastic Load Balancing logs
AWS WAF logs
CloudTrail network-configuration events
GuardDuty findings
VPN tunnel metrics
Direct Connect metrics

Network Telemetry

↓

Central Log Archive

↓

Security Analytics

↓

Detection Rules

↓

SOC Investigation

↓

Containment

Network Security Metrics

CloudNova tracks:

Metric	Purpose
Public Resources	Measures internet exposure
Open Security Group Rules	Identifies broad access
Rejected Flow Events	Detects blocked or misconfigured traffic
Firewall Rule Hits	Measures control effectiveness
DNS Block Events	Identifies suspicious domain access
Unapproved Routes	Detects route drift
VPN Availability	Measures hybrid connectivity
Direct Connect Availability	Measures private-connectivity health
Unused Security Groups	Reduces configuration sprawl
Network Exceptions	Tracks temporary risk
Cross-Account Connections	Maintains connectivity inventory
VPC Endpoint Usage	Measures private AWS service access

🛠 Lab 01 — Design a Secure Three-Tier VPC

Objective

Design a Multi-AZ VPC for the SecurePay application.

Requirements

Use:

One VPC
Two Availability Zones
Two public subnets
Two private application subnets
Two isolated database subnets
One internet-facing Application Load Balancer
NAT gateway architecture
Private application workloads
Private database
Separate route tables
Security Groups
VPC Flow Logs

Suggested CIDR Plan

VPC:
10.20.0.0/16

Public Subnet A:
10.20.0.0/24

Public Subnet B:
10.20.1.0/24

Private Application Subnet A:
10.20.10.0/24

Private Application Subnet B:
10.20.11.0/24

Isolated Database Subnet A:
10.20.20.0/24

Isolated Database Subnet B:
10.20.21.0/24

Deliverables

VPC architecture diagram
CIDR allocation table
Route-table design
Security Group matrix
Network-flow matrix
Failure analysis

🛠 Lab 02 — Design Security Group Rules

Objective

Create least-privilege Security Group rules for a three-tier application.

Required Security Groups

securepay-alb-sg
securepay-app-sg
securepay-db-sg

Rule Design

Load Balancer Security Group

Inbound:

HTTPS 443 from approved internet sources

Outbound:

HTTPS to securepay-app-sg

Application Security Group

Inbound:

HTTPS 443 from securepay-alb-sg

Outbound:

PostgreSQL 5432 to securepay-db-sg
HTTPS 443 to approved VPC endpoints

Database Security Group

Inbound:

PostgreSQL 5432 from securepay-app-sg

Outbound:

Only required database response and service traffic

Deliverable

Security Group	Direction	Protocol	Port	Source or Destination	Purpose
ALB-SG	Inbound	TCP	443	Approved clients	Customer HTTPS
APP-SG	Inbound	TCP	443	ALB-SG	Application traffic
DB-SG	Inbound	TCP	5432	APP-SG	Database traffic

🛠 Lab 03 — Create a Network Flow Matrix

Objective

Document approved communication for SecurePay.

Include

Customer to CloudFront
CloudFront to load balancer
Load balancer to application
Application to database
Application to Secrets Manager
Application to CloudWatch
SOC to security tooling
On-premises to shared services
Partner to API

Deliverable

Flow ID	Source	Destination	Protocol	Port	Authentication	Encryption	Owner

🛠 Lab 04 — Design Transit Gateway Segmentation

Objective

Create separate routing domains for production, development, shared services and security inspection.

Required Attachments

Production VPC
Development VPC
Shared Services VPC
Inspection VPC
Network VPC

Required Rules

Production can reach shared services.
Development can reach shared services.
Development cannot reach production.
Production egress must pass through inspection.
On-premises access must pass through approved routes.
Partner routes must be isolated.

Deliverable

AWS Transit Gateway

├── Production Route Table
├── Development Route Table
├── Shared Services Route Table
├── Inspection Route Table
└── Partner Route Table

Document:

Attachment association
Route propagation
Static routes
Blackhole routes
Inspection path

🛠 Lab 05 — Design Private AWS Service Access

Objective

Reduce internet dependency by designing VPC endpoints.

Required Endpoints

Evaluate endpoints for:

Amazon S3
AWS Secrets Manager
AWS Systems Manager
AWS KMS
Amazon ECR
Amazon CloudWatch
AWS Security Token Service

Deliverable

AWS Service	Endpoint Type	Subnets	Security Group	Endpoint Policy
Amazon S3	Gateway	Private application subnets	Not applicable	Approved buckets only
Secrets Manager	Interface	Private application subnets	Endpoint SG	Approved secrets only

🛠 Lab 06 — Design Centralised Egress Inspection

Objective

Design an egress VPC using Transit Gateway, AWS Network Firewall and NAT gateways.

Required Flow

Workload VPC

↓

Transit Gateway

↓

Inspection VPC

↓

AWS Network Firewall

↓

NAT Gateway

↓

Internet

Document

Route tables
Firewall endpoints
Availability Zones
NAT gateways
Symmetric routing
Logging
Failure handling
Allowed destinations
Blocked destinations

🛠 Lab 07 — Design Secure Hybrid Connectivity

Objective

Design connectivity between CloudNova’s on-premises data centre and AWS.

Requirements

AWS Direct Connect as the primary path
Site-to-Site VPN as backup
Transit Gateway integration
Restricted route advertisements
Redundant connectivity
Monitoring and alerting
Encryption requirements
Failover testing

Deliverables

Hybrid network diagram
Route design
Trust-boundary analysis
Failure scenarios
Security controls
Operational runbook

🛠 Lab 08 — Build a DNS Security Design

Objective

Design centralised DNS and DNS filtering.

Include

Private hosted zones
Resolver inbound endpoints
Resolver outbound endpoints
Conditional forwarding
Resolver query logging
DNS Firewall
Domain allow list
Domain block list
On-premises DNS integration

Deliverable

AWS Workloads

↓

Route 53 Resolver

↓

DNS Firewall

├── Approved Domain → Allow
├── Suspicious Domain → Alert
└── Malicious Domain → Block

🛠 Lab 09 — Perform a Network Security Architecture Review

Objective

Review a proposed VPC design containing:

Public EC2 instances
Public RDS database
Open SSH access
One route table for all subnets
No Flow Logs
No VPC endpoints
Direct VPC peering between fifteen VPCs
No central firewall
No DNS logging

Identify

Architectural risks
Attack paths
Missing controls
Required remediation
Residual risks
Priority order

Deliverable

Finding	Severity	Business Impact	Recommendation	Owner
Public database	Critical	Customer-data exposure	Move to isolated subnets	Database Team
SSH open to internet	Critical	Administrative compromise	Use Session Manager	Platform Team

💻 AWS Console Walkthrough — Create a Secure VPC Foundation

Step 1 — Open Amazon VPC

Sign in to the AWS Management Console.
Search for VPC.
Open the Amazon VPC console.
Select the approved AWS Region.

Step 2 — Create the VPC

Create:

Name:
cloudnova-securepay-vpc

IPv4 CIDR:
10.20.0.0/16

Enable DNS resolution and DNS hostnames where required.

Step 3 — Create Subnets

Create subnets across at least two Availability Zones.

Public:
10.20.0.0/24
10.20.1.0/24

Private Application:
10.20.10.0/24
10.20.11.0/24

Isolated Database:
10.20.20.0/24
10.20.21.0/24

Step 4 — Create an Internet Gateway

Create an internet gateway.
Name it:

cloudnova-securepay-igw

Attach it to the SecurePay VPC.

Step 5 — Create Public Route Table

Add:

Destination:
0.0.0.0/0

Target:
Internet Gateway

Associate only the approved public subnets.

Step 6 — Create Private Route Tables

Create separate private route tables.

Where outbound internet access is required, route traffic through approved NAT gateways.

Step 7 — Create Isolated Route Table

Do not add a default internet route.

Associate the database subnets.

Step 8 — Create Security Groups

Create:

Load balancer Security Group
Application Security Group
Database Security Group
VPC endpoint Security Group

Use Security Group references rather than broad CIDR rules wherever possible.

Step 9 — Enable VPC Flow Logs

Send Flow Logs to:

CloudWatch Logs, or
A protected Amazon S3 destination

For enterprise deployments, centralise the logs in the Log Archive account.

Step 10 — Validate Public Exposure

Review:

Public IPv4 addresses
Elastic IP addresses
Internet gateway routes
Load balancer scheme
Security Group rules
Network ACLs
Database public-access settings

💻 AWS CLI Lab

Verify Current Identity

aws sts get-caller-identity

Set the AWS Region

aws configure set region ap-south-1

Create a VPC

aws ec2 create-vpc \
  --cidr-block 10.20.0.0/16 \
  --tag-specifications \
  'ResourceType=vpc,Tags=[{Key=Name,Value=cloudnova-securepay-vpc}]'

Record the returned VPC ID.

export VPC_ID="vpc-REPLACE_ME"

PowerShell:

$VPC_ID = "vpc-REPLACE_ME"

Enable DNS Support

aws ec2 modify-vpc-attribute \
  --vpc-id "$VPC_ID" \
  --enable-dns-support '{"Value":true}'

Enable DNS Hostnames

aws ec2 modify-vpc-attribute \
  --vpc-id "$VPC_ID" \
  --enable-dns-hostnames '{"Value":true}'

Create a Public Subnet

aws ec2 create-subnet \
  --vpc-id "$VPC_ID" \
  --cidr-block 10.20.0.0/24 \
  --availability-zone ap-south-1a \
  --tag-specifications \
  'ResourceType=subnet,Tags=[{Key=Name,Value=securepay-public-a}]'

Create a Private Application Subnet

aws ec2 create-subnet \
  --vpc-id "$VPC_ID" \
  --cidr-block 10.20.10.0/24 \
  --availability-zone ap-south-1a \
  --tag-specifications \
  'ResourceType=subnet,Tags=[{Key=Name,Value=securepay-app-a}]'

Create an Isolated Database Subnet

aws ec2 create-subnet \
  --vpc-id "$VPC_ID" \
  --cidr-block 10.20.20.0/24 \
  --availability-zone ap-south-1a \
  --tag-specifications \
  'ResourceType=subnet,Tags=[{Key=Name,Value=securepay-db-a}]'

Create an Internet Gateway

aws ec2 create-internet-gateway \
  --tag-specifications \
  'ResourceType=internet-gateway,Tags=[{Key=Name,Value=cloudnova-securepay-igw}]'

Record the internet gateway ID.

export IGW_ID="igw-REPLACE_ME"

Attach the Internet Gateway

aws ec2 attach-internet-gateway \
  --internet-gateway-id "$IGW_ID" \
  --vpc-id "$VPC_ID"

Create a Public Route Table

aws ec2 create-route-table \
  --vpc-id "$VPC_ID" \
  --tag-specifications \
  'ResourceType=route-table,Tags=[{Key=Name,Value=securepay-public-rt}]'

Record the route table ID.

export PUBLIC_RT_ID="rtb-REPLACE_ME"

Create the Internet Route

aws ec2 create-route \
  --route-table-id "$PUBLIC_RT_ID" \
  --destination-cidr-block 0.0.0.0/0 \
  --gateway-id "$IGW_ID"

Create an Application Security Group

aws ec2 create-security-group \
  --group-name securepay-app-sg \
  --description "Security group for SecurePay application workloads" \
  --vpc-id "$VPC_ID"

List Security Groups

aws ec2 describe-security-groups \
  --filters "Name=vpc-id,Values=$VPC_ID"

Review Route Tables

aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=$VPC_ID"

Review Public IP Settings

aws ec2 describe-subnets \
  --filters "Name=vpc-id,Values=$VPC_ID" \
  --query 'Subnets[*].{SubnetId:SubnetId,CIDR:CidrBlock,PublicIP:MapPublicIpOnLaunch,AZ:AvailabilityZone}'

Create an S3 Gateway Endpoint

Replace the route-table IDs with the approved private route-table IDs.

aws ec2 create-vpc-endpoint \
  --vpc-id "$VPC_ID" \
  --service-name com.amazonaws.ap-south-1.s3 \
  --vpc-endpoint-type Gateway \
  --route-table-ids rtb-PRIVATE_ROUTE_TABLE_ID

List VPC Endpoints

aws ec2 describe-vpc-endpoints \
  --filters "Name=vpc-id,Values=$VPC_ID"

List Transit Gateways

aws ec2 describe-transit-gateways

List Transit Gateway Attachments

aws ec2 describe-transit-gateway-attachments

List VPC Peering Connections

aws ec2 describe-vpc-peering-connections

List Network Firewalls

aws network-firewall list-firewalls

List VPC Flow Logs

aws ec2 describe-flow-logs

✅ Verification Checklist

Verify that you can:

🔍 Troubleshooting

Problem — Private Workload Cannot Reach the Internet

Review:

Private subnet route table
NAT gateway state
NAT gateway subnet
Internet gateway attachment
Security Group outbound rules
Network ACL rules
DNS resolution
Availability Zone design

Problem — Application Cannot Reach the Database

Review:

Application Security Group
Database Security Group
Database port
Subnet route tables
Network ACL rules
Database endpoint
DNS resolution
Application credentials

Problem — Interface Endpoint Is Not Reachable

Review:

Endpoint subnet selection
Endpoint Security Group
Private DNS setting
Application Security Group
Network ACLs
Route 53 DNS resolution
Endpoint service availability in the Region

Problem — Transit Gateway Traffic Is Not Routed

Review:

VPC attachment state
Subnet association
Transit Gateway route-table association
Route propagation
Static routes
VPC route tables
Security Groups
Network ACLs
Overlapping CIDR ranges

Problem — Traffic Bypasses the Firewall

Review:

Workload route tables
Transit Gateway routes
Inspection VPC routes
Firewall endpoint routes
Route propagation
Symmetric routing
Direct VPC connections
Alternative internet gateways or NAT gateways

Problem — Network Firewall Drops Valid Traffic

Review:

Stateless rule groups
Stateful rule groups
Rule order
Domain-list behaviour
TLS-encrypted traffic limitations
Source and destination CIDRs
Required ephemeral ports
Firewall logs

Do not disable the firewall without documenting and approving the risk.

Problem — VPN Tunnel Is Down

Review:

Customer gateway IP
Tunnel configuration
Pre-shared key
Routing protocol
BGP settings
Firewall rules
Tunnel metrics
On-premises device logs
Route advertisements

Problem — DNS Resolution Fails Between AWS and On-Premises

Review:

Resolver endpoint status
Resolver rules
Rule associations
Security Groups
Network ACLs
Port 53 TCP and UDP
On-premises forwarding rules
Private hosted-zone association
Overlapping DNS namespaces

Problem — VPC CLI Command Returns Access Denied

Verify:

Current AWS identity
IAM permissions
Permission boundary
Service Control Policy
Session policy
AWS Region
Resource ownership

Run:

aws sts get-caller-identity

🏢 Enterprise Best Practices

CloudNova’s network standards include:

Use separate AWS accounts and VPCs for major trust boundaries.
Design a non-overlapping enterprise IP-address plan.
Deploy critical workloads across multiple Availability Zones.
Place only approved edge resources in public subnets.
Place application workloads in private subnets.
Place databases in isolated subnets.
Minimise public IP addresses.
Use Security Group references instead of broad CIDRs.
Restrict management access.
Use Systems Manager Session Manager where possible.
Use VPC endpoints for private AWS service access.
Centralise routing using Transit Gateway where appropriate.
Separate production and non-production routing domains.
Inspect egress and sensitive east-west traffic.
Preserve symmetric routing through stateful appliances.
Log VPC, Transit Gateway, DNS and firewall activity.
Use DNS filtering to block known malicious destinations.
Automate networking through Infrastructure as Code.
Review public exposure continuously.
Document every approved network flow.
Test network failover and incident-isolation procedures.

🚫 Common Mistakes

❌ Using overlapping VPC CIDR ranges.

❌ Placing databases in public subnets.

❌ Assigning public IP addresses to private workloads.

❌ Allowing SSH or RDP from 0.0.0.0/0.

❌ Using one Security Group for every tier.

❌ Allowing unrestricted outbound traffic without review.

❌ Using one route table for every subnet.

❌ Assuming NAT gateways provide security inspection.

❌ Creating large numbers of unmanaged VPC peering connections.

❌ Allowing development networks to access production.

❌ Bypassing central inspection routes.

❌ Ignoring asymmetric routing.

❌ Using only network location as proof of trust.

❌ Failing to enable VPC Flow Logs.

❌ Sending DNS queries directly to unapproved public resolvers.

❌ Giving partner networks broad access.

❌ Using public AWS service endpoints when private endpoints are available and required.

❌ Making manual routing changes outside approved pipelines.

🧪 DIY Enterprise Challenge

CloudNova is building a global SecurePay platform across India, Europe and North America.

The platform must support:

Three AWS Regions
Production and non-production accounts
Internet-facing customer services
Private application workloads
Restricted financial databases
Centralised network inspection
Hybrid connectivity
Partner API connectivity
Secure DNS
Centralised logging
Disaster recovery
Zero Trust access

Prepare the following deliverables:

Enterprise IP Address Management Plan
Regional VPC Architecture
Public, Private and Isolated Subnet Design
Route-Table Design
Security Group Matrix
Network ACL Standard
Transit Gateway Architecture
Central Inspection VPC Design
AWS Network Firewall Policy
Egress-Control Strategy
VPC Endpoint Strategy
PrivateLink Service Design
Hybrid Connectivity Architecture
DNS and Resolver Architecture
Network Flow Matrix
Network Logging Strategy
Network Incident-Response Runbook
Network Resilience Plan
Risk Register
Executive Architecture Summary

📊 Knowledge Check

What is network segmentation?
How does segmentation reduce blast radius?
What is the difference between segmentation and isolation?
What is an Amazon VPC?
Why should VPC CIDR ranges not overlap?
What is the difference between public, private and isolated subnets?
What makes a subnet public?
What is the purpose of a NAT gateway?
Why is a NAT gateway not a security firewall?
How do route tables affect security?
What is a Security Group?
Why are Security Groups considered stateful?
What is a Network ACL?
Why must ephemeral ports be considered with Network ACLs?
What information is captured by VPC Flow Logs?
What is the difference between VPC peering and Transit Gateway?
What does non-transitive routing mean?
How can Transit Gateway route tables create network segmentation?
Why is symmetric routing important for stateful inspection?
What is AWS Network Firewall?
What is the difference between gateway and interface VPC endpoints?
What is AWS PrivateLink?
How does PrivateLink differ from VPC peering?
What is Site-to-Site VPN?
What security consideration remains with Direct Connect?
Why is Session Manager preferred over public SSH or RDP?
What is Route 53 Resolver?
How does DNS Firewall reduce risk?
What is east-west traffic?
What is microsegmentation?
Why should production and development use separate routing domains?
What should be included in a network-flow matrix?
Which network changes should require approval?
How does Infrastructure as Code improve network governance?
Which logs should be centralised for network-security monitoring?

💡 Key Takeaways

After completing this lesson, you should understand:

Enterprise network segmentation separates workloads according to trust, purpose, environment and data sensitivity.
Secure VPC design uses multiple Availability Zones, non-overlapping CIDRs and separate public, private and isolated subnets.
Route tables, Security Groups and Network ACLs must work together to permit only required communication.
Security Groups provide stateful resource-level filtering, while Network ACLs provide stateless subnet-level controls.
VPC endpoints and AWS PrivateLink reduce internet exposure and enable private access to AWS and internal services.
AWS Transit Gateway simplifies large-scale connectivity and supports separate routing domains for production, development, shared services and inspection.
Centralised inspection using AWS Network Firewall can enforce consistent east-west and outbound network policies.
Hybrid connections using VPN and Direct Connect must use restricted routing, redundancy, monitoring and tested failover.
DNS is a critical security layer and should include central governance, query logging and malicious-domain filtering.
Zero Trust architecture does not grant access merely because a workload or user is inside a trusted network.
Network telemetry, change governance and Infrastructure as Code are essential for maintaining a secure enterprise network.
Every permitted connection should have a documented business purpose, owner and security control.

🚀 Next Lesson

➡️ Lesson 04 — Enterprise Identity Federation, Zero Trust Access & Privileged Access Architecture

Lesson 03 — Enterprise Network Segmentation, VPC Design & Secure Connectivity

🎯 Lesson Objective

💼 Business Scenario

What Is Network Segmentation?

Why Segmentation Matters

Network Segmentation vs Network Isolation

Segmentation

Isolation

Amazon VPC

VPC Design Principles

IP Address Planning

Example Enterprise IP Plan

Why Overlapping CIDRs Are a Problem

Public, Private and Isolated Subnets

Public Subnet

Private Subnet

Isolated Subnet

Three-Tier VPC Architecture

Route Tables

Routing Security Principles

Internet Gateway

NAT Gateway

NAT Gateway Security Considerations

Centralised Egress Architecture

Security Groups

Stateful Behaviour

Security Group Referencing

Enterprise Security Group Pattern

Security Group Best Practices

Network ACLs

Security Groups vs Network ACLs

Network ACL Use Cases

Ephemeral Ports

VPC Flow Logs

Flow Log Architecture

Flow Log Use Cases

Traffic Mirroring

VPC Peering

No Transitive Routing

VPC Peering Challenges at Scale

AWS Transit Gateway

Transit Gateway Benefits

Transit Gateway Route Tables

Transit Gateway Segmentation

Centralised Inspection VPC

Symmetric Routing

AWS Network Firewall

Network Firewall Architecture

Stateless and Stateful Rule Processing

Stateless Rules

Stateful Rules

Network Firewall Best Practices

VPC Endpoints

Gateway Endpoints

Interface Endpoints

Endpoint Policies

AWS PrivateLink

PrivateLink vs VPC Peering

Hybrid Connectivity

Site-to-Site VPN

VPN Security Considerations

AWS Direct Connect

Direct Connect and VPN Together

AWS Client VPN

Administrative Access Architecture

Bastion Hosts

DNS Architecture

Route 53 Resolver

Hybrid DNS Architecture

DNS Security Risks

DNS Security Controls

Route 53 Resolver DNS Firewall

Ingress Security Architecture

Egress Security Architecture

East-West vs North-South Traffic

North-South Traffic

East-West Traffic

Microsegmentation

Zero Trust Network Principles

Network Trust Zones