Project 03 — Enterprise Network Security Project

Learning Path

☁️ Phase 02 – AWS Cloud Security

🚀 Enterprise Cloud Security Projects & Capstone Labs

🎯 Lesson Objective

In this project, you will work as CloudNova Technologies’ Lead Cloud Security Engineer and design an enterprise AWS network-security architecture.

You will move beyond creating individual VPCs, subnets and security groups.

You will design a scalable multi-account network that supports:

Multiple business units
Development, testing and production environments
Centralised network connectivity
Centralised traffic inspection
Controlled internet ingress
Controlled internet egress
Private access to AWS services
Hybrid cloud connectivity
Network segmentation
DNS security
Network telemetry
Incident isolation
Disaster recovery
Zero Trust networking
Enterprise governance

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

Assess an existing enterprise AWS network.
Design a multi-account network architecture.
Define an enterprise IP-addressing strategy.
Design VPCs and subnets across Availability Zones.
Explain hub-and-spoke network architecture.
Design AWS Transit Gateway connectivity.
Design Transit Gateway route-table segmentation.
Build centralised network inspection.
Design AWS Network Firewall policies.
Control internet ingress and egress.
Design inspection VPCs and egress VPCs.
Use gateway and interface VPC endpoints.
Explain AWS PrivateLink.
Design Route 53 Resolver inbound and outbound endpoints.
Implement Route 53 Resolver DNS Firewall.
Design hybrid connectivity using Direct Connect and VPN.
Apply security groups and network ACLs.
Implement network logging and monitoring.
Design network incident-response controls.
Apply Zero Trust network principles.
Produce professional enterprise network-security documentation.

📚 Lesson Information

Area	Details
Project	CloudNova Enterprise Network Security
Project Type	Network Architecture, Security Engineering and Governance
Estimated Time	16–20 Hours
Difficulty	Advanced
Delivery Mode	DIY or Instructor-Led
Primary Services	Amazon VPC, AWS Transit Gateway, AWS Network Firewall
Supporting Services	Route 53 Resolver, DNS Firewall, AWS PrivateLink, VPC Flow Logs, Direct Connect, Site-to-Site VPN
Security Services	GuardDuty, Security Hub, CloudWatch, CloudTrail, AWS Config
Main Deliverable	Enterprise Network Security Architecture
Environment	Dedicated training or sandbox AWS environment
Prerequisite	Lesson 02 – Enterprise Identity & Zero Trust Implementation Project

🏢 Business Scenario

CloudNova Technologies has completed:

Its enterprise AWS landing zone
Its multi-account organisational structure
Its IAM Identity Center architecture
Its Role-Based Access Control model
Its Attribute-Based Access Control model
Its privileged-access process
Its workload-identity standards

CloudNova now operates hundreds of AWS accounts across several business units.

Application teams have independently created VPCs in their AWS accounts.

The current network environment includes:

Development VPCs
Testing VPCs
Production VPCs
Data analytics VPCs
Kubernetes VPCs
Shared services VPCs
Internet-facing applications
Private internal applications
Connections to corporate data centres
Connections to third-party organisations

The internal security assessment has identified several problems:

VPC CIDR ranges overlap.
Development networks can communicate with production networks.
Internet egress is not centrally controlled.
Several workloads use public IP addresses unnecessarily.
NAT gateways have been created independently in many accounts.
Network inspection differs between application teams.
Security groups allow unrestricted inbound access.
Network ACLs are poorly documented.
VPC Flow Logs are not enabled consistently.
DNS queries are not centrally monitored.
Applications can resolve known malicious domains.
Direct Connect and VPN routes are not centrally governed.
Network changes are performed without security review.
Incident responders cannot isolate compromised VPCs quickly.
Network diagrams are incomplete or outdated.
No formal network-security ownership model exists.

CloudNova plans to support:

More than 500 AWS accounts
Thousands of VPCs
Multiple AWS Regions
Global customer-facing applications
Hybrid connectivity
Regulated workloads
24×7 security operations
Disaster-recovery environments

The Chief Information Security Officer asks:

“How can we connect hundreds of AWS accounts securely while preventing unrestricted communication, inspecting sensitive traffic and maintaining complete visibility?”

You have been assigned to lead the CloudNova Enterprise Network Security Project.

🧑‍💼 Your Role

You are working as the:

Lead Cloud Security Engineer

Your responsibilities include:

Assessing the current AWS network.
Defining network-security requirements.
Designing the enterprise IP-addressing strategy.
Designing the VPC architecture.
Establishing network segmentation.
Designing Transit Gateway connectivity.
Designing centralised inspection.
Controlling internet ingress and egress.
Securing DNS.
Designing private service access.
Designing hybrid connectivity.
Defining network logging standards.
Developing incident-isolation procedures.
Establishing network governance.
Presenting the architecture to technical and executive stakeholders.

1. Enterprise Network Security Strategy

Enterprise network security must answer:

Which systems are allowed to communicate?
Which protocols and ports are required?
Which traffic must be inspected?
Which workloads require internet access?
Which applications must remain private?
Which networks can connect to production?
How will on-premises networks connect to AWS?
How will DNS requests be controlled?
How will network activity be logged?
How will compromised workloads be isolated?
Who approves network changes?
How will network rules be reviewed?

CloudNova’s network-security strategy will be based on:

Explicit connectivity
Default isolation
Least-privilege traffic flows
Centralised routing governance
Centralised inspection
Private service access
Restricted internet exposure
Controlled DNS resolution
Complete network telemetry
Multi-account separation
Multi-Region resilience
Automated validation
Continuous monitoring

2. Zero Trust Networking

Zero Trust networking assumes that network location alone does not establish trust.

A workload must not be trusted simply because it is:

Inside an AWS VPC
Inside a private subnet
Connected through a corporate network
Hosted in a production account
Connected through Direct Connect
Located behind a firewall

Every connection should be evaluated based on:

Source identity
Destination identity
Application
Protocol
Port
Environment
Data classification
Business requirement
Device or workload posture
Current risk
Approved policy

Zero Trust Network Principles

Default Isolation

Networks and workloads should begin without unnecessary connectivity.

Explicit Traffic Authorisation

Every permitted flow must have a documented business requirement.

Application-Level Trust

Use workload identity, application authentication and encryption rather than relying only on IP addresses.

Minimise Public Exposure

Private applications should not receive public IP addresses.

Inspect High-Risk Traffic

Traffic crossing trust boundaries should be inspected where technically and operationally appropriate.

Log Important Network Activity

Network flows, DNS activity, firewall events and configuration changes must be recorded.

Assume Compromise

The architecture must support rapid containment of compromised workloads and accounts.

3. Current-State Network Assessment

Before designing the target architecture, CloudNova must understand its existing environment.

The assessment should identify:

AWS accounts
AWS Regions
VPCs
CIDR ranges
Subnets
Route tables
Internet gateways
NAT gateways
Transit gateways
VPC peering connections
VPN connections
Direct Connect connections
VPC endpoints
Security groups
Network ACLs
Route 53 Resolver endpoints
Private hosted zones
Public IP addresses
Network inspection systems
Flow-log status
Traffic dependencies
Application owners
Network owners

Current-State Assessment Questions

Are any CIDR ranges overlapping?
Which VPCs communicate with each other?
Which workloads require internet ingress?
Which workloads require internet egress?
Which systems communicate with on-premises networks?
Are network paths documented?
Is traffic inspection implemented?
Are VPC Flow Logs enabled?
Are DNS logs enabled?
Are security groups reviewed?
Are unused network connections present?
Are any production resources directly reachable from development?

4. Enterprise Network Architecture

                         Internet

                            |

                    AWS Shield and WAF

                            |

                  Central Ingress Services

                            |

                    Ingress Inspection VPC

                            |

                    AWS Transit Gateway

          +-----------------+------------------+
          |                 |                  |
          v                 v                  v
   Production VPCs   Non-Production VPCs   Shared Services
          |                 |                  |
          +-----------------+------------------+
                            |
                            v
                    Inspection VPC
                            |
                    AWS Network Firewall
                            |
                            v
                       Egress VPC
                            |
                       NAT Gateway
                            |
                         Internet

Corporate Data Centres
          |
          v
AWS Direct Connect / Site-to-Site VPN
          |
          v
AWS Transit Gateway

5. Multi-Account Network Model

CloudNova will separate networking responsibilities across AWS accounts.

Proposed Network Accounts

Account	Purpose
Network Management	Transit Gateway, routing governance and shared connectivity
Network Inspection	AWS Network Firewall and traffic inspection
Network Egress	Centralised outbound internet access
Network Ingress	Shared inbound application entry points
DNS Services	Route 53 Resolver endpoints and DNS Firewall
Shared Services	Enterprise shared applications and directory services
Security Tooling	Network monitoring, analytics and incident response

Depending on operational requirements, some functions may be combined.

Highly regulated environments may require stronger separation of duties between:

Routing administration
Firewall administration
DNS administration
Security monitoring
Workload administration

6. Enterprise IP-Addressing Strategy

An enterprise IP-addressing plan is required before creating VPCs.

Poor IP planning can cause:

Overlapping CIDR ranges
Routing conflicts
Failed acquisitions
Hybrid connectivity problems
Transit Gateway limitations
Difficult network troubleshooting
Application migration delays

CloudNova will maintain a central IP Address Management process.

Example Address Allocation

CloudNova Enterprise Private Address Space

10.0.0.0/8

├── 10.0.0.0/10       Europe
├── 10.64.0.0/10      Asia-Pacific
├── 10.128.0.0/10     North America
└── 10.192.0.0/10     Shared, Security and Future Use

Example Regional Allocation

Europe

10.0.0.0/10

├── 10.0.0.0/12       eu-west-2
├── 10.16.0.0/12      eu-west-1
├── 10.32.0.0/12      eu-central-1
└── 10.48.0.0/12      Reserved

Example Environment Allocation

eu-west-2

10.0.0.0/12

├── 10.0.0.0/14       Production
├── 10.4.0.0/14       Non-Production
├── 10.8.0.0/15       Shared Services
├── 10.10.0.0/16      Network Security
├── 10.11.0.0/16      Data Platforms
└── 10.12.0.0/14      Reserved

7. AWS VPC IP Address Manager

AWS VPC IP Address Manager can help CloudNova:

Plan IP-address allocations.
Monitor IP-address usage.
Allocate CIDR ranges.
Detect overlapping ranges.
Track regional allocations.
Govern multi-account addressing.
Identify unused address space.
Support IPv4 and IPv6 planning.

IPAM Governance Requirements

Central ownership
Delegated administration
Approved address pools
Region-based allocation
Environment-based allocation
Automated allocation where possible
Regular utilisation reviews
Documented exceptions
Integration with account provisioning

8. VPC Design Principles

Each VPC should have:

A documented owner
A documented business purpose
A non-overlapping CIDR
Multiple Availability Zones where required
Public, private and isolated subnet categories
Explicit route tables
Security-group standards
Network ACL standards
VPC Flow Logs
DNS settings
Endpoint strategy
Connectivity requirements
Data-classification information
Incident-isolation procedures

9. Enterprise Subnet Design

CloudNova will design subnets according to function.

Public Subnets

Public subnets may contain:

Internet-facing load balancers
NAT gateways
Approved network appliances
Bastion alternatives where formally required

Application servers and databases should not be placed in public subnets merely for convenience.

Private Application Subnets

Private application subnets may contain:

EC2 application servers
ECS workloads
EKS worker nodes
Internal load balancers
Lambda VPC integrations
Application services

Isolated Data Subnets

Isolated subnets may contain:

Relational databases
Data warehouses
Sensitive storage services
Internal data-processing systems
Security appliances

Isolated subnets should not have direct routes to an internet gateway.

10. Multi-Availability Zone VPC Architecture

VPC: 10.20.0.0/16

Availability Zone A

├── Public Subnet
├── Private Application Subnet
├── Isolated Data Subnet
└── Transit Gateway Subnet

Availability Zone B

├── Public Subnet
├── Private Application Subnet
├── Isolated Data Subnet
└── Transit Gateway Subnet

Availability Zone C

├── Public Subnet
├── Private Application Subnet
├── Isolated Data Subnet
└── Transit Gateway Subnet

11. Hub-and-Spoke Architecture

CloudNova will use a hub-and-spoke model for enterprise connectivity.

                         Transit Gateway
                              |
       +----------------------+----------------------+
       |                      |                      |
       v                      v                      v
 Production Spokes     Non-Production Spokes   Shared Services
       |                      |                      |
       v                      v                      v
 Application VPCs      Development VPCs         Platform VPCs

Benefits include:

Central routing
Scalable VPC connectivity
Simplified governance
Network segmentation
Centralised inspection
Shared hybrid connectivity
Reduced peering complexity

12. AWS Transit Gateway

AWS Transit Gateway acts as a central routing hub connecting:

VPCs
AWS accounts
AWS Regions
Site-to-Site VPN connections
Direct Connect gateways
Network appliances

Transit Gateway does not automatically create unrestricted trust.

Connectivity depends on:

Attachments
Route-table associations
Route propagation
VPC route tables
Security groups
Network ACLs
Firewall policies
Application controls

13. Transit Gateway Attachments

Common attachment types include:

VPC attachments
VPN attachments
Transit Gateway peering attachments
Direct Connect gateway associations
Connect attachments

Every attachment should have:

An owner
A business purpose
An environment classification
An approved route-table association
Approved propagation
Monitoring
Lifecycle documentation

14. Transit Gateway Route Tables

Transit Gateway route tables create network segmentation.

CloudNova will not use a single unrestricted route table for every network.

Proposed Route Tables

Route Table	Purpose
Production	Routes approved production traffic
Non-Production	Routes development and testing traffic
Shared Services	Routes approved shared-service traffic
Inspection	Routes traffic through security inspection
Hybrid	Routes approved on-premises connectivity
Quarantine	Isolates compromised or suspended networks

15. Transit Gateway Segmentation

Development VPCs
       |
       v
Non-Production TGW Route Table
       |
       +----> Shared Development Services
       |
       +----> Inspection VPC
       |
       X----> Production VPCs

Production VPCs
       |
       v
Production TGW Route Table
       |
       +----> Approved Shared Services
       |
       +----> Inspection VPC
       |
       X----> Development VPCs

The X represents a deliberately prohibited network path.

16. Transit Gateway Routing Workflow

Source Workload

↓

Source Subnet Route Table

↓

Transit Gateway Attachment

↓

Transit Gateway Route Table

↓

Inspection Attachment Where Required

↓

Destination Transit Gateway Attachment

↓

Destination VPC Route Table

↓

Security Group and Network ACL Evaluation

↓

Destination Workload

17. Appliance Mode

When stateful network appliances inspect traffic through Transit Gateway, routing symmetry is important.

Appliance mode can help maintain consistent traffic through the same Availability Zone path for supported inspection architectures.

CloudNova must validate:

Symmetric routing
Return paths
Availability Zone design
Transit Gateway attachment settings
Firewall endpoint routing
Failover behaviour

18. Centralised Inspection Architecture

CloudNova will use a dedicated inspection VPC.

Spoke VPC

   |

Transit Gateway

   |

Inspection VPC Attachment

   |

AWS Network Firewall Endpoints

   |

Transit Gateway

   |

Destination VPC or Egress VPC

The inspection VPC separates:

Security enforcement
Firewall administration
Workload administration
Routing management
Security logging

19. AWS Network Firewall

AWS Network Firewall provides managed network-traffic inspection for VPC environments.

CloudNova may use it to inspect:

VPC-to-VPC traffic
Outbound internet traffic
Inbound internet traffic
Hybrid traffic
Traffic crossing security zones

Core Components

Component	Purpose
Firewall	Associates the policy with protected VPC subnets
Firewall Policy	Defines stateless and stateful rule groups
Stateless Rule Group	Evaluates packet-level attributes
Stateful Rule Group	Maintains connection state and inspects sessions
Firewall Endpoint	Processes traffic within an Availability Zone
Logging Configuration	Sends alert and flow information to approved destinations

20. Stateless and Stateful Inspection

Stateless Rules

Stateless rules evaluate individual packets.

They may evaluate:

Source address
Destination address
Source port
Destination port
Protocol
TCP flags

Stateful Rules

Stateful rules track network sessions and can support:

Domain-based controls
Protocol inspection
Connection-state analysis
Threat signatures
Suricata-compatible rules
Stateful allow or deny decisions

21. Firewall Policy Strategy

CloudNova will use layered firewall policies.

Baseline Rules

Applied to all inspected environments:

Block known malicious traffic.
Block prohibited protocols.
Restrict administrative ports.
Log rejected connections.
Protect approved DNS paths.
Detect suspicious outbound connections.

Environment Rules

Development

Controlled broader testing access
Approved software repositories
Restricted production connectivity
Enhanced logging

Production

Strict destination allow lists
Restricted administrative access
Approved service dependencies only
Mandatory encryption
High-severity alerting

Regulated Workloads

Explicit source and destination rules
Strict data-flow controls
Full logging
Formal change approval
More frequent rule review

22. Example Stateful Rules

pass tls 10.20.0.0/16 any -> any 443 (
  tls.sni;
  dotprefix;
  content:".amazonaws.com";
  endswith;
  sid:100001;
)

drop tcp any any -> any 23 (
  msg:"Block outbound Telnet";
  sid:100002;
)

alert tcp any any -> any 445 (
  msg:"Monitor outbound SMB traffic";
  sid:100003;
)

Example rules must be tested in an authorised non-production environment before deployment.

23. Firewall Rule Lifecycle

Rule Requirement

↓

Business Justification

↓

Security Review

↓

Rule Development

↓

Policy Validation

↓

Non-Production Testing

↓

Change Approval

↓

Production Deployment

↓

Traffic Monitoring

↓

Periodic Review

↓

Retirement

24. Centralised Internet Egress

CloudNova will centralise outbound internet access where appropriate.

Private Application VPC

        |

Transit Gateway

        |

Inspection VPC

        |

AWS Network Firewall

        |

Egress VPC

        |

NAT Gateway

        |

Internet Gateway

        |

Internet

Benefits include:

Centralised policy enforcement
Reduced public exposure
Consistent logging
Central allow and deny controls
Simplified incident response
Centralised threat detection

25. Distributed and Centralised Egress

CloudNova must evaluate both models.

Centralised Egress

Advantages:

Central inspection
Central policy management
Consistent logging
Easier governance

Considerations:

Routing complexity
Data-processing charges
Transit Gateway costs
Availability design
Regional dependencies
Potential shared-service impact

Distributed Egress

Advantages:

Simpler local routing
Reduced dependency on a central egress VPC
Localised failure domains

Considerations:

More NAT gateways
Distributed policy management
Inconsistent controls
Increased operational overhead

CloudNova may use a hybrid model based on:

Environment
Data classification
Region
Application criticality
Performance
Cost
Regulatory requirements

26. Controlled Internet Ingress

Internet-facing applications should use approved ingress services.

Internet

   |

Amazon CloudFront

   |

AWS WAF

   |

Application Load Balancer

   |

Private Application Targets

Depending on the application, CloudNova may also use:

AWS Shield
Global Accelerator
API Gateway
Network Load Balancer
AWS Network Firewall
Third-party inspection appliances

27. Ingress Security Requirements

Internet-facing applications must have:

An approved business requirement
Documented ownership
TLS encryption
Valid certificates
WAF protections where applicable
DDoS protections
Restricted security groups
Application logging
Load-balancer logging
Vulnerability management
Threat monitoring
Incident-response procedures

28. Private Service Access

Workloads should access AWS services privately where practical.

CloudNova will use VPC endpoints to reduce unnecessary internet paths.

Gateway Endpoints

Gateway endpoints support private routing to selected AWS services.

Common examples include:

Amazon S3
Amazon DynamoDB

Interface Endpoints

Interface endpoints use elastic network interfaces with private IP addresses.

They can provide private access to many AWS services and endpoint services.

29. AWS PrivateLink

AWS PrivateLink enables private connectivity between VPCs and services without requiring:

Public IP addresses
Internet gateways
NAT gateways
Public internet routing
Direct VPC peering for the service connection

PrivateLink Architecture

Consumer VPC

    |

Interface VPC Endpoint

    |

AWS PrivateLink

    |

Endpoint Service

    |

Provider Network Load Balancer

    |

Private Application Service

30. VPC Endpoint Policies

Endpoint policies can restrict which principals and resources may use a VPC endpoint.

Example objectives:

Allow access only to approved S3 buckets.
Restrict access to organisation-owned resources.
Prevent access to personal AWS accounts.
Restrict actions to read-only operations.
Require approved IAM principals.

Example S3 Endpoint Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowApprovedCloudNovaBuckets",
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::cloudnova-approved-data/*"
      ]
    }
  ]
}

31. DNS Architecture

DNS is a critical enterprise security dependency.

CloudNova’s DNS architecture must support:

AWS resource resolution
Private hosted zones
On-premises domain resolution
AWS-to-on-premises queries
On-premises-to-AWS queries
DNS query logging
Malicious-domain blocking
Centralised DNS governance
Resilience
Incident investigation

32. Route 53 Resolver

Route 53 Resolver supports DNS resolution for AWS resources.

CloudNova may use:

Inbound Resolver endpoints
Outbound Resolver endpoints
Resolver rules
Rule sharing
Query logging
DNS Firewall

33. Inbound Resolver Endpoints

Inbound endpoints allow on-premises DNS systems to resolve selected AWS private domains.

On-Premises Workload

        |

Corporate DNS Server

        |

Direct Connect or VPN

        |

Route 53 Resolver Inbound Endpoint

        |

Private Hosted Zone

        |

AWS Private Resource

34. Outbound Resolver Endpoints

Outbound endpoints allow AWS resources to resolve selected on-premises domains.

AWS Workload

    |

Route 53 Resolver

    |

Outbound Resolver Endpoint

    |

Direct Connect or VPN

    |

Corporate DNS Server

    |

On-Premises Resource

35. Route 53 Resolver DNS Firewall

DNS Firewall can filter outbound DNS queries made through Route 53 Resolver.

CloudNova may use DNS Firewall to:

Block known malicious domains.
Block command-and-control domains.
Restrict prohibited categories.
Allow approved enterprise domains.
Monitor suspicious DNS activity.
Protect against certain DNS-based threats.
Support incident containment.

36. DNS Firewall Rule Strategy

Priority 100 — Enterprise Allow List

Allow required corporate and critical service domains.

Priority 200 — Threat Intelligence Block List

Block known malicious or compromised domains.

Priority 300 — Restricted Categories

Block prohibited domains based on enterprise policy.

Priority 400 — Monitoring Rules

Alert on suspicious domains requiring investigation.

Priority 500 — Default Behaviour

Apply the approved default action.

37. DNS Query Logging

CloudNova should collect DNS query logs for:

Threat hunting
Malware investigations
Command-and-control detection
Data-exfiltration investigations
Policy validation
Application troubleshooting
Incident response

DNS logs may be sent to approved destinations such as:

CloudWatch Logs
Amazon S3
Kinesis Data Firehose
Security Lake
Enterprise SIEM

38. Security Groups

Security groups are stateful virtual firewalls associated with supported resources.

CloudNova standards require:

Least-privilege inbound rules
Least-privilege outbound rules
Approved source references
Security-group referencing where practical
No unrestricted administrative access
Documented ownership
Regular review
Removal of unused rules
Automated compliance checks

Poor Rule

Protocol: TCP
Port: 22
Source: 0.0.0.0/0

Improved Rule

Protocol: TCP
Port: 22
Source: Approved management security group
Purpose: Time-bound administrative access

Prefer managed access solutions that avoid direct SSH or RDP exposure where possible.

39. Security Group Referencing

Security-group references can express application relationships.

Internet-Facing Load Balancer Security Group

        |

Allows HTTPS to

        |

Application Security Group

        |

Allows Database Port to

        |

Database Security Group

This is more maintainable than relying entirely on changing IP addresses.

40. Network ACLs

Network ACLs provide stateless controls at the subnet boundary.

CloudNova may use network ACLs for:

Broad subnet-level restrictions
Known malicious CIDR blocking
Additional boundary controls
Incident containment
Compliance requirements

Network ACLs must be designed carefully because:

Rules are evaluated numerically.
Allow and deny rules are supported.
Return traffic must be permitted explicitly.
Ephemeral ports must be considered.
Incorrect rules can interrupt many resources.

41. Security Groups and Network ACLs

Control	Security Group	Network ACL
Scope	Resource or network interface	Subnet
State	Stateful	Stateless
Rules	Allow only	Allow and deny
Evaluation	Combined allowed rules	Ordered rule numbers
Typical Use	Workload-level access	Subnet boundary control

CloudNova will primarily use security groups for workload-level controls and use network ACLs where a documented subnet-level requirement exists.

42. Hybrid Connectivity

CloudNova connects AWS to corporate data centres and offices.

Possible connectivity options include:

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

43. AWS Direct Connect

Direct Connect provides dedicated network connectivity between customer environments and AWS.

CloudNova must still implement:

Authentication
Encryption where required
Route filtering
Traffic inspection
Network segmentation
Redundant connectivity
Monitoring
Incident response

A dedicated connection does not automatically create trusted traffic.

44. Site-to-Site VPN

Site-to-Site VPN provides encrypted connectivity using IPsec tunnels.

CloudNova may use it for:

Primary connectivity for smaller locations
Backup connectivity for Direct Connect
Rapid connectivity deployment
Disaster-recovery access
Partner connections

45. Hybrid Connectivity Architecture

Corporate Data Centre A
          |
      Direct Connect
          |
          v
Direct Connect Gateway
          |
          v
AWS Transit Gateway
          |
          +----> Inspection VPC
          |
          +----> Production VPCs
          |
          +----> Shared Services

Corporate Data Centre B
          |
      Site-to-Site VPN
          |
          v
AWS Transit Gateway

46. Hybrid Route Governance

CloudNova must control:

Advertised on-premises routes
AWS routes advertised on-premises
Production network reachability
Non-production network reachability
Default routes
Backup routes
Route preference
Overlapping networks
Partner routes
Route ownership

47. Inter-Region Connectivity

CloudNova may use Transit Gateway peering for approved inter-Region connectivity.

Inter-Region design must consider:

Data residency
Latency
Bandwidth
Cost
Failure isolation
Route management
Encryption
Compliance
Disaster recovery
Operational ownership

Not every VPC requires global connectivity.

48. Network Logging Architecture

VPC Flow Logs
      |
Network Firewall Logs
      |
Route 53 Resolver Query Logs
      |
Load Balancer Logs
      |
CloudTrail Network Configuration Events
      |
      v
Central Log Archive
      |
      v
Amazon Security Lake
      |
      v
SIEM and SOC
      |
      v
Threat Detection and Investigation

49. VPC Flow Logs

VPC Flow Logs record metadata about IP traffic associated with supported network interfaces and network boundaries.

They can support:

Traffic analysis
Security investigations
Rejected-traffic analysis
Troubleshooting
Threat hunting
Compliance
Network baselining

VPC Flow Logs are not full packet captures.

50. Network Firewall Logging

CloudNova will configure:

Alert logs
Flow logs
Central destinations
Retention policies
Access controls
SIEM integration
High-severity alerting

Firewall logging should support:

Rule tuning
Threat detection
Incident investigation
Policy validation
Application troubleshooting

51. Traffic Mirroring

VPC Traffic Mirroring can copy supported network traffic to monitoring or security appliances.

Possible use cases include:

Deep packet inspection
Network forensics
Intrusion detection
Application troubleshooting
Threat hunting

Traffic Mirroring must be carefully governed due to:

Sensitive data exposure
Storage requirements
Processing costs
Privacy implications
Performance considerations
Access-control requirements

52. Network Threat Model

Threat	Potential Impact	Primary Control
Unrestricted east-west traffic	Lateral movement	Transit Gateway segmentation
Publicly exposed administration	Account or workload compromise	Restricted security groups
Malicious outbound traffic	Command-and-control communication	Network Firewall and DNS Firewall
DNS tunnelling	Data exfiltration	DNS logging and advanced detection
Route manipulation	Traffic interception or outage	Restricted route administration
Overlapping CIDRs	Failed or incorrect routing	Central IPAM
Uninspected hybrid traffic	Threat movement from on-premises	Central inspection
Security-group drift	Unauthorised access	AWS Config and continuous review
Flow-log deletion	Loss of evidence	Central logging protection
Public S3 access paths	Data exposure	VPC endpoints and bucket policies
Compromised VPC	Enterprise lateral movement	Quarantine route table
Firewall bypass	Uninspected communication	Routing validation and monitoring
Misconfigured NACL	Application outage	Change control and testing
Unrestricted internet egress	Malware downloads and exfiltration	Centralised egress controls
Unapproved VPC peering	Governance bypass	SCPs and configuration monitoring

53. Network Incident Isolation

CloudNova must be able to isolate compromised workloads quickly.

Possible containment actions include:

Replace the resource security group.
Remove public IP addresses.
Update subnet routes.
Move a Transit Gateway attachment to a quarantine route table.
Apply restrictive network ACLs.
Block malicious domains.
Add firewall deny rules.
Disable compromised load-balancer listeners.
Isolate a Kubernetes workload.
Preserve flow and firewall logs.

54. Quarantine Architecture

Compromised VPC

      |

Transit Gateway Attachment

      |

Quarantine Route Table

      |

No Production Connectivity

      |

Limited Access to:

- Incident Response Services
- Forensic Storage
- Security Tooling
- Approved Patch Repositories

55. Network Change Management

All significant network changes require:

Business justification
Source and destination
Protocol and port
Environment
Data classification
Risk assessment
Security review
Test evidence
Implementation plan
Rollback plan
Change window
Post-change validation
Rule expiry where temporary

56. Firewall Rule Review

Every firewall rule should have:

Field	Example
Rule ID	NET-FW-00231
Source	Payments production subnet
Destination	Fraud API endpoint
Protocol	TCP
Port	443
Business Purpose	Payment fraud validation
Owner	Payments Platform
Approver	Cloud Security
Expiry	Permanent with annual review
Logging	Enabled
Last Reviewed	2026-07-01

57. Network Governance Model

Team	Responsibility
Cloud Network Engineering	Routing, Transit Gateway and hybrid connectivity
Cloud Security Engineering	Firewall and network-security architecture
DNS Services Team	Resolver endpoints, zones and DNS controls
Application Teams	Application-level connectivity requirements
SOC	Monitoring and incident response
Cloud Platform Team	VPC automation and account integration
Internal Audit	Independent control validation
Change Advisory Board	High-risk production changes

58. Network Security Metrics

CloudNova will monitor:

Number of public resources
Unrestricted security-group rules
Unused security groups
VPC Flow Log coverage
DNS logging coverage
Firewall policy coverage
Rejected connection trends
Malicious-domain blocks
Unapproved routes
Unapproved VPC peering
Quarantine events
Mean time to isolate
Firewall-rule review completion
Network-control exceptions
Internet-egress volume
Cross-environment traffic

59. Enterprise Network Implementation Phases

Phase 1 — Discovery

Inventory VPCs.
Inventory CIDRs.
Identify network owners.
Map traffic flows.
Review hybrid connections.
Identify public workloads.
Review network logs.
Identify high-risk rules.
Identify overlapping CIDRs.

Phase 2 — Design

Define IP-addressing strategy.
Define VPC standards.
Design Transit Gateway.
Design route-table segmentation.
Design inspection VPC.
Design egress.
Design ingress.
Design DNS.
Design hybrid connectivity.
Define logging standards.

Phase 3 — Build

Deploy IPAM.
Deploy Transit Gateway.
Deploy route tables.
Deploy inspection VPC.
Deploy Network Firewall.
Deploy egress VPC.
Deploy Resolver endpoints.
Deploy DNS Firewall.
Configure VPC endpoints.
Configure central logging.

Phase 4 — Validate

Test approved traffic flows.
Test prohibited traffic flows.
Validate inspection paths.
Validate route symmetry.
Validate DNS filtering.
Validate endpoint access.
Validate hybrid routing.
Validate flow logs.
Test incident isolation.

Phase 5 — Migrate

Attach VPCs in controlled waves.
Update route tables.
Remove legacy peering.
Migrate internet egress.
Migrate DNS forwarding.
Validate applications.
Monitor for denied traffic.
Roll back where required.

Phase 6 — Operate

Monitor network drift.
Review firewall rules.
Review routes.
Review public exposure.
Review DNS activity.
Review connectivity exceptions.
Test quarantine procedures.
Report security metrics.

🛠 Hands-on Project Labs

Lab 01 — Conduct the Enterprise Network Assessment

Mission

Assess CloudNova’s current AWS network environment.

Student Actions

Create:

03-Enterprise-Network-Security/
└── 01-Assessment/
    └── Current-State-Network-Assessment.md

Document:

AWS accounts
Regions
VPCs
CIDR ranges
Subnets
Route tables
Internet gateways
NAT gateways
VPC peerings
Transit gateways
VPNs
Direct Connect
Security groups
Network ACLs
VPC endpoints
Resolver endpoints
Flow-log status
Network owners

Evidence

Network inventory
Current-state architecture
Overlapping CIDR report
Public exposure report
High-risk findings
Remediation priorities

Lab 02 — Design the Enterprise IP-Addressing Plan

Mission

Create a scalable IP-addressing strategy for CloudNova.

Requirements

Design allocations for:

Three AWS Regions
Production
Development
Testing
Shared services
Security
Data platforms
Kubernetes
Disaster recovery
Future acquisitions

Student Actions

Create:

03-Enterprise-Network-Security/
└── 02-IP-Addressing/
    ├── IP-Addressing-Strategy.md
    └── CIDR-Allocation-Register.md

Evidence

CIDR hierarchy
Allocation table
Reserved address space
Overlap-validation results
IPAM architecture

Lab 03 — Design the Multi-VPC Architecture

Mission

Design CloudNova’s VPC and subnet standards.

Student Actions

Define:

VPC size
Availability Zone strategy
Public subnets
Private application subnets
Isolated data subnets
Transit Gateway subnets
Firewall subnets
Endpoint subnets
Route-table standards
Naming standards
Tagging standards

Required Diagram

Application VPC

├── Availability Zone A
│   ├── Public Subnet
│   ├── Private Application Subnet
│   ├── Isolated Data Subnet
│   └── Transit Gateway Subnet
│
├── Availability Zone B
│   ├── Public Subnet
│   ├── Private Application Subnet
│   ├── Isolated Data Subnet
│   └── Transit Gateway Subnet
│
└── Availability Zone C
    ├── Public Subnet
    ├── Private Application Subnet
    ├── Isolated Data Subnet
    └── Transit Gateway Subnet

Lab 04 — Build the Transit Gateway Segmentation Model

Mission

Design Transit Gateway connectivity and route-table segmentation.

Required Route Tables

Production
Non-Production
Shared Services
Inspection
Hybrid
Quarantine

Student Actions

Document:

Attachments
Route-table associations
Route propagation
Allowed connections
Prohibited connections
Inspection paths
Failure behaviour
Quarantine process

Verification Scenarios

Development cannot initiate traffic to production.
Production can reach approved shared services.
On-premises users can reach approved production applications.
Internet-bound traffic passes through inspection.
Compromised VPCs can be moved to quarantine.

Lab 05 — Design the Central Inspection VPC

Mission

Design AWS Network Firewall deployment for CloudNova.

Student Actions

Document:

Inspection VPC CIDR
Availability Zones
Firewall subnets
Transit Gateway subnets
Firewall endpoints
Route tables
Stateless rules
Stateful rules
Logging
High availability
Failure handling
Rule-change process

Evidence

Inspection architecture
Firewall policy
Sample rule groups
Routing matrix
Validation plan

Lab 06 — Build the Centralised Egress Architecture

Mission

Design secure outbound internet access.

Student Actions

Create:

Egress VPC architecture
NAT gateway design
Network Firewall path
Approved destination strategy
DNS controls
Logging
Resilience plan
Cost considerations
Failure scenarios

Required Traffic Path

Private Workload

↓

Transit Gateway

↓

Inspection VPC

↓

AWS Network Firewall

↓

Egress VPC

↓

NAT Gateway

↓

Internet

Lab 07 — Implement Private AWS Service Access

Mission

Reduce unnecessary public internet paths using VPC endpoints.

Student Actions

Design endpoints for:

Amazon S3
Amazon DynamoDB
AWS Systems Manager
Amazon EC2 Messages
Systems Manager Messages
Amazon ECR
CloudWatch Logs
AWS KMS
Secrets Manager
AWS STS

Document:

Endpoint type
Endpoint subnet
Security group
Endpoint policy
Private DNS
Resource policy
Logging
Ownership

Lab 08 — Design Enterprise DNS Security

Mission

Create CloudNova’s hybrid DNS and DNS Firewall architecture.

Student Actions

Design:

Inbound Resolver endpoints
Outbound Resolver endpoints
Resolver rules
Rule sharing
Private hosted zones
DNS query logging
DNS Firewall rule groups
Malicious-domain response
Incident investigation workflow

Required Diagram

AWS Workloads

↓

Route 53 Resolver

↓

DNS Firewall

↓

Outbound Resolver Endpoint

↓

Corporate DNS

↓

Approved Internal Domains

Lab 09 — Build the Network Monitoring and Isolation Runbook

Mission

Create an operational runbook for detecting and isolating network threats.

Required Scenarios

Public administrative port detected
Malware command-and-control traffic
DNS tunnelling alert
Unapproved VPC peering
Compromised production EC2 instance
Route-table manipulation
Firewall bypass
Unexpected outbound data transfer

Runbook Sections

Detection source
Initial validation
Traffic analysis
Business-owner contact
Containment options
Evidence preservation
Recovery
Post-incident review

Lab 10 — Conduct the Enterprise Network Architecture Review

Mission

Present CloudNova’s target network-security architecture to the Architecture Review Board.

Review Participants

Chief Information Security Officer
Cloud Security Architect
Network Architect
Cloud Platform Lead
SOC Manager
Application Architect
Data Architect
Compliance Manager
Disaster-Recovery Lead
Finance Representative

Review Topics

IP addressing
VPC design
Transit Gateway
Segmentation
Inspection
Internet ingress
Internet egress
DNS
Hybrid connectivity
Private endpoints
Network monitoring
Incident isolation
Resilience
Cost
Migration risks

💻 AWS Console Walkthrough

Students should explore or configure:

Amazon VPC
VPC IP Address Manager
Subnets
Route tables
Internet gateways
NAT gateways
Security groups
Network ACLs
VPC Flow Logs
Transit Gateway
Transit Gateway attachments
Transit Gateway route tables
AWS Network Firewall
Firewall policies
Rule groups
Firewall logging
VPC endpoints
Endpoint policies
Route 53 Resolver endpoints
Resolver rules
DNS Firewall
Site-to-Site VPN
Direct Connect architecture
CloudWatch network logs

💻 AWS CLI Exercises

Run these commands only in an authorised training or sandbox environment.

# Display the current AWS identity
aws sts get-caller-identity

# List VPCs
aws ec2 describe-vpcs

# List subnets
aws ec2 describe-subnets

# List route tables
aws ec2 describe-route-tables

# List internet gateways
aws ec2 describe-internet-gateways

# List NAT gateways
aws ec2 describe-nat-gateways

# List security groups
aws ec2 describe-security-groups

# List network ACLs
aws ec2 describe-network-acls

# List VPC peering connections
aws ec2 describe-vpc-peering-connections

# List VPC endpoints
aws ec2 describe-vpc-endpoints

# List VPC Flow Logs
aws ec2 describe-flow-logs

Transit Gateway Commands

# List Transit Gateways
aws ec2 describe-transit-gateways

# List Transit Gateway attachments
aws ec2 describe-transit-gateway-attachments

# List Transit Gateway route tables
aws ec2 describe-transit-gateway-route-tables

# List VPC attachments
aws ec2 describe-transit-gateway-vpc-attachments

# Search a Transit Gateway route table
aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id tgw-rtb-EXAMPLE \
  --filters Name=state,Values=active

Network Firewall Commands

# List firewalls
aws network-firewall list-firewalls

# Describe a firewall
aws network-firewall describe-firewall \
  --firewall-name CloudNova-Central-Inspection

# List firewall policies
aws network-firewall list-firewall-policies

# List rule groups
aws network-firewall list-rule-groups

# Describe firewall logging
aws network-firewall describe-logging-configuration \
  --firewall-name CloudNova-Central-Inspection

Route 53 Resolver Commands

# List Resolver endpoints
aws route53resolver list-resolver-endpoints

# List Resolver rules
aws route53resolver list-resolver-rules

# List rule associations
aws route53resolver list-resolver-rule-associations

# List DNS Firewall rule groups
aws route53resolver list-firewall-rule-groups

# List DNS Firewall domain lists
aws route53resolver list-firewall-domain-lists

# List Resolver query-log configurations
aws route53resolver list-resolver-query-log-configs

VPC IPAM Commands

# List IPAM configurations
aws ec2 describe-ipams

# List IPAM pools
aws ec2 describe-ipam-pools

# List IPAM scopes
aws ec2 describe-ipam-scopes

# View allocations in an IPAM pool
aws ec2 get-ipam-pool-allocations \
  --ipam-pool-id ipam-pool-EXAMPLE

Example VPC Flow Log Creation

aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-EXAMPLE \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name CloudNova-VPC-Flow-Logs \
  --deliver-logs-permission-arn arn:aws:iam::111122223333:role/CloudNovaFlowLogsRole

Example Interface Endpoint Creation

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-EXAMPLE \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.eu-west-2.secretsmanager \
  --subnet-ids subnet-EXAMPLE1 subnet-EXAMPLE2 \
  --security-group-ids sg-EXAMPLE \
  --private-dns-enabled

✅ Technical Verification Checklist

Network Assessment

All VPCs are inventoried.
All CIDR ranges are documented.
Overlapping CIDRs are identified.
Public resources are identified.
Existing network connections are documented.
Network owners are recorded.

IP Addressing

Enterprise IP strategy exists.
Regional pools are defined.
Environment pools are defined.
Reserved ranges are documented.
IPAM ownership is assigned.
Allocation workflow is documented.

VPC Architecture

VPC standard is documented.
Subnet categories are defined.
Availability Zone requirements are defined.
Route-table standards are defined.
VPC naming and tagging are defined.
Flow Logs are included.

Transit Gateway

Transit Gateway architecture is documented.
Attachments have owners.
Route tables are segmented.
Production and development are isolated.
Inspection routing is validated.
Quarantine routing is designed.

Network Firewall

Inspection VPC is designed.
Firewall endpoints exist in required Availability Zones.
Stateful rules are documented.
Stateless rules are documented.
Firewall logging is enabled.
Rule-change workflow exists.
Failure behaviour is documented.

Internet Access

Internet ingress is documented.
Internet egress is documented.
Public IP usage is justified.
NAT gateway strategy is defined.
Approved outbound destinations are governed.
DDoS and WAF requirements are documented.

Private Connectivity

Required VPC endpoints are defined.
Endpoint policies are reviewed.
Private DNS is configured appropriately.
S3 and DynamoDB gateway endpoints are assessed.
PrivateLink requirements are documented.

DNS

Inbound Resolver architecture is documented.
Outbound Resolver architecture is documented.
Resolver rules are governed.
DNS Firewall is designed.
DNS query logging is enabled.
Malicious-domain response is documented.

Hybrid Connectivity

Direct Connect architecture is documented.
VPN backup is documented.
Route advertisements are governed.
Hybrid traffic inspection is defined.
Resilience is documented.
Monitoring is enabled.

Monitoring and Response

VPC Flow Logs are centralised.
Firewall logs are centralised.
DNS logs are centralised.
Network alerts are defined.
Quarantine procedures are documented.
Isolation exercises are tested.

🔧 Troubleshooting Guide

Issue 1 — VPCs Cannot Communicate Through Transit Gateway

Possible causes:

Missing Transit Gateway route
Incorrect route-table association
Route propagation not enabled
Missing VPC route
Security-group denial
Network ACL denial
Overlapping CIDR ranges

Resolution:

Verify both attachments.
Review Transit Gateway route tables.
Review route propagation.
Review source and destination VPC routes.
Review security groups.
Review network ACLs.
Confirm CIDR uniqueness.
Use VPC Reachability Analyzer.

Issue 2 — Traffic Bypasses the Network Firewall

Possible causes:

Direct route to the destination
Incorrect Transit Gateway association
Missing inspection route
Alternative VPC peering path
Public IP path
Incorrect firewall subnet route table

Resolution:

Review all available routes.
Remove unauthorised direct connectivity.
Validate Transit Gateway route tables.
Review inspection VPC routing.
Check internet-gateway and NAT paths.
Review VPC peering.
Test using Reachability Analyzer.

Issue 3 — Return Traffic Uses a Different Path

Possible causes:

Asymmetric routing
Incorrect route propagation
Multiple default routes
Appliance mode not configured
Availability Zone path mismatch

Resolution:

Map forward and return routes.
Review Transit Gateway attachment settings.
Review appliance mode.
Validate Availability Zone routing.
Remove conflicting routes.
Test each traffic direction separately.

Issue 4 — Interface Endpoint Is Not Reachable

Possible causes:

Private DNS disabled
Endpoint security group blocks traffic
Incorrect subnet selection
DNS settings disabled in the VPC
Endpoint policy denies access
Resource policy denies access

Resolution:

Confirm endpoint status.
Confirm private DNS.
Review endpoint security groups.
Review VPC DNS settings.
Review endpoint policy.
Review target-resource policy.
Test DNS resolution.

Issue 5 — DNS Queries Do Not Reach On-Premises DNS

Possible causes:

Missing outbound endpoint
Incorrect Resolver rule
Rule not associated with the VPC
Network route missing
Security group blocking DNS
On-premises DNS not permitting the endpoint addresses

Resolution:

Verify the outbound endpoint.
Review the forwarding rule.
Confirm VPC association.
Review hybrid routes.
Permit TCP and UDP DNS as required.
Review corporate DNS access controls.
Review Resolver query logs.

Issue 6 — DNS Firewall Blocks a Required Domain

Possible causes:

Domain included in a block list
Rule priority conflict
Overly broad wildcard
Threat-intelligence false positive
Missing approved-domain exception

Resolution:

Review the query log.
Identify the matching rule.
Validate the business requirement.
Add a controlled allow-list entry.
Test in non-production.
Document the exception.
Review the domain regularly.

Issue 7 — VPC Flow Logs Are Missing

Possible causes:

Flow Logs not enabled
Delivery role lacks permissions
Log destination is incorrect
KMS permissions are missing
Region mismatch
Log group or bucket policy issue

Resolution:

Review Flow Log status.
Verify the delivery role.
Review the destination.
Review KMS permissions.
Review CloudWatch or S3 policies.
Confirm the correct Region.
Generate test traffic.

Issue 8 — Security Group Change Breaks Application Access

Possible causes:

Required source removed
Incorrect source security group
Missing outbound rule
Wrong port
Load-balancer health-check traffic blocked
Database dependency overlooked

Resolution:

Review application flow documentation.
Check load-balancer health checks.
Review source and destination groups.
Review VPC Flow Logs.
Restore the approved previous rule.
Validate the application.
Update dependency documentation.

🏢 Enterprise Best Practices

CloudNova network-security standards:

Use non-overlapping CIDR ranges.
Maintain central IP-address governance.
Use separate VPCs for major trust boundaries.
Separate production and non-production.
Use Transit Gateway route tables for segmentation.
Avoid unrestricted VPC-to-VPC connectivity.
Use a dedicated inspection VPC.
Inspect traffic crossing sensitive boundaries.
Validate routing symmetry.
Use centralised egress where appropriate.
Minimise public IP addresses.
Use approved ingress services.
Use AWS WAF for supported web applications.
Use VPC endpoints for private AWS service access.
Restrict endpoint policies.
Use Route 53 Resolver for hybrid DNS.
Apply DNS Firewall controls.
Enable DNS query logging.
Enable VPC Flow Logs.
Enable Network Firewall alert and flow logs.
Centralise network telemetry.
Use security-group references where practical.
Avoid unrestricted SSH and RDP.
Review security groups regularly.
Use network ACLs only with a defined requirement.
Encrypt hybrid and application traffic where required.
Maintain redundant hybrid connectivity.
Test incident-isolation procedures.
Use Infrastructure as Code.
Validate network changes before production.
Maintain current network diagrams.
Assign owners to routes, rules and connections.
Remove unused network paths.
Review network exceptions regularly.

🚫 Common Mistakes

Allowing overlapping VPC CIDRs.
Using one unrestricted Transit Gateway route table.
Assuming Transit Gateway provides firewall inspection.
Allowing development networks to reach production.
Deploying Network Firewall without validating routes.
Ignoring asymmetric routing.
Creating direct VPC peering that bypasses inspection.
Using public IP addresses for private workloads.
Allowing unrestricted internet egress.
Allowing SSH or RDP from the internet.
Using default security groups for applications.
Failing to review outbound security-group rules.
Creating overly complex network ACLs.
Forgetting ephemeral ports in network ACLs.
Not enabling VPC Flow Logs.
Treating Flow Logs as packet captures.
Failing to log DNS queries.
Allowing workloads to use unauthorised DNS servers.
Using broad DNS Firewall wildcard rules without testing.
Creating interface endpoints without endpoint policies.
Assuming Direct Connect traffic is automatically trusted.
Advertising unrestricted on-premises routes.
Failing to design hybrid-connectivity redundancy.
Making firewall changes directly in production.
Leaving temporary firewall rules permanently active.
Failing to document network owners.
Not testing network-isolation procedures.
Ignoring the cost impact of centralised traffic paths.
Failing to consider data residency in inter-Region routing.
Building a single shared network failure domain.

📦 Required Project Deliverables

Students must create the following project files:

CloudNova-Enterprise-Security/

└── 03-Enterprise-Network-Security/
    ├── README.md
    ├── 01-Assessment/
    │   ├── Current-State-Network-Assessment.md
    │   ├── Network-Inventory.md
    │   ├── Public-Exposure-Assessment.md
    │   └── Network-Risk-Assessment.md
    ├── 02-IP-Addressing/
    │   ├── IP-Addressing-Strategy.md
    │   ├── CIDR-Allocation-Register.md
    │   ├── IPAM-Architecture.md
    │   └── Overlap-Assessment.md
    ├── 03-VPC-Architecture/
    │   ├── Enterprise-VPC-Standard.md
    │   ├── Subnet-Design.md
    │   ├── Route-Table-Standard.md
    │   └── VPC-Naming-and-Tagging.md
    ├── 04-Transit-Gateway/
    │   ├── Transit-Gateway-Architecture.md
    │   ├── Attachment-Register.md
    │   ├── Route-Table-Design.md
    │   ├── Segmentation-Matrix.md
    │   └── Quarantine-Routing.md
    ├── 05-Network-Firewall/
    │   ├── Inspection-VPC-Design.md
    │   ├── Firewall-Policy.md
    │   ├── Stateless-Rule-Groups.md
    │   ├── Stateful-Rule-Groups.md
    │   └── Firewall-Rule-Review.md
    ├── 06-Internet-Access/
    │   ├── Central-Egress-Architecture.md
    │   ├── Internet-Ingress-Architecture.md
    │   ├── Public-Exposure-Standard.md
    │   └── Approved-Destination-Register.md
    ├── 07-Private-Connectivity/
    │   ├── VPC-Endpoint-Strategy.md
    │   ├── Endpoint-Policy-Standards.md
    │   ├── PrivateLink-Architecture.md
    │   └── Endpoint-Register.md
    ├── 08-DNS/
    │   ├── Enterprise-DNS-Architecture.md
    │   ├── Resolver-Endpoint-Design.md
    │   ├── DNS-Firewall-Policy.md
    │   └── DNS-Logging-Strategy.md
    ├── 09-Hybrid-Connectivity/
    │   ├── Direct-Connect-Architecture.md
    │   ├── VPN-Architecture.md
    │   ├── Hybrid-Route-Policy.md
    │   └── Connectivity-Resilience.md
    ├── 10-Monitoring/
    │   ├── Network-Logging-Strategy.md
    │   ├── VPC-Flow-Log-Standard.md
    │   ├── Network-Alert-Catalogue.md
    │   └── Network-Security-Dashboard.md
    ├── 11-Incident-Response/
    │   ├── Network-Isolation-Runbook.md
    │   ├── Quarantine-Procedure.md
    │   ├── Malicious-DNS-Runbook.md
    │   └── Firewall-Incident-Runbook.md
    ├── 12-Governance/
    │   ├── Network-Change-Procedure.md
    │   ├── Firewall-Rule-Request.md
    │   ├── Network-Exception-Process.md
    │   └── Network-Ownership-Matrix.md
    ├── 13-Evidence/
    │   ├── Screenshots/
    │   ├── CLI-Outputs/
    │   ├── Connectivity-Tests/
    │   ├── Flow-Log-Evidence/
    │   └── Verification-Checklist.md
    └── 14-Reports/
        ├── Network-Architecture-Review.md
        ├── Executive-Network-Strategy.md
        ├── Risk-Register.md
        └── Lessons-Learned.md

🧪 DIY Enterprise Challenge

CloudNova acquires a global retail company called RetailSphere.

RetailSphere currently operates:

60 AWS accounts
110 VPCs
Eight AWS Regions
Multiple overlapping CIDR ranges
75 VPC peering connections
Two Transit Gateways
Four Direct Connect connections
Twelve Site-to-Site VPNs
Internet egress from every workload account
Public IP addresses on application servers
No central Network Firewall
Inconsistent VPC Flow Logs
No DNS Firewall
Shared production and development networks
Unrestricted administrative security-group rules
No network-isolation runbook
Undocumented partner connections

Design a complete network transformation and migration plan.

Your submission must include:

Current-state network assessment
VPC and CIDR inventory
Overlapping CIDR remediation strategy
Target IP-addressing architecture
VPC design standard
Transit Gateway architecture
Route-table segmentation model
Inspection VPC architecture
Network Firewall policy
Centralised egress design
Internet ingress design
VPC endpoint strategy
Hybrid DNS architecture
DNS Firewall policy
Direct Connect and VPN architecture
VPC Flow Log strategy
Security-group remediation plan
Network incident-isolation runbook
Migration sequence
Rollback plan
Operational-risk assessment
Cost considerations
Architecture review
Executive summary

📊 Knowledge Check

Question 1

What is the primary objective of enterprise network segmentation?

Answer:
To limit unnecessary communication between systems, reduce the blast radius of compromise and enforce approved trust boundaries.

Question 2

Why should CloudNova avoid overlapping CIDR ranges?

Answer:
Overlapping CIDRs create routing ambiguity and can prevent VPC, hybrid and Transit Gateway connectivity.

Question 3

What is the purpose of AWS Transit Gateway?

Answer:
It provides central routing connectivity between VPCs, AWS accounts, VPNs and supported hybrid or inter-Region connections.

Question 4

Does Transit Gateway automatically inspect network traffic?

Answer:
No. Traffic inspection requires routing through a firewall or approved inspection appliance.

Question 5

Why should Transit Gateway use multiple route tables?

Answer:
Multiple route tables allow CloudNova to segment production, non-production, shared services, hybrid and quarantine networks.

Question 6

What is the purpose of an inspection VPC?

Answer:
It centralises network-security controls and separates firewall administration from application workload administration.

Question 7

What is AWS Network Firewall used for?

Answer:
It provides managed stateless and stateful network-traffic filtering and inspection within VPC architectures.

Question 8

What is the difference between stateless and stateful firewall inspection?

Answer:
Stateless inspection evaluates individual packets, while stateful inspection tracks connections and evaluates traffic in the context of a session.

Question 9

Why is symmetric routing important for stateful inspection?

Answer:
The firewall must see both directions of a connection to maintain and evaluate the session correctly.

Question 10

What is centralised internet egress?

Answer:
It routes outbound internet traffic from multiple VPCs through shared inspection and egress services.

Question 11

Why should private workloads avoid public IP addresses?

Answer:
Removing unnecessary public exposure reduces the attack surface and supports private, controlled connectivity.

Question 12

What is the difference between a gateway endpoint and an interface endpoint?

Answer:
A gateway endpoint adds private routes for supported services, while an interface endpoint creates private network interfaces for access to supported services.

Question 13

What is AWS PrivateLink?

Answer:
It enables private connectivity between VPCs and services without requiring public IP addresses or public internet paths.

Question 14

Why are VPC endpoint policies important?

Answer:
They can restrict which principals, actions and resources may be accessed through the endpoint.

Question 15

What is the purpose of a Route 53 Resolver inbound endpoint?

Answer:
It allows networks outside the VPC, such as on-premises networks, to resolve approved AWS private DNS names.

Question 16

What is the purpose of a Route 53 Resolver outbound endpoint?

Answer:
It allows AWS workloads to forward selected DNS queries to external DNS servers, such as corporate DNS.

Question 17

What does Route 53 Resolver DNS Firewall control?

Answer:
It filters outbound DNS queries that pass through Route 53 Resolver based on configured domain rules.

Question 18

Why should DNS query logs be collected?

Answer:
They support threat detection, malware investigations, DNS-tunnelling detection, troubleshooting and compliance.

Question 19

What is the difference between a security group and a network ACL?

Answer:
A security group is stateful and applies to supported resources or network interfaces, while a network ACL is stateless and applies at the subnet boundary.

Question 20

Why should administrative ports not be open to 0.0.0.0/0?

Answer:
It exposes management services to the entire internet and significantly increases the risk of compromise.

Question 21

What information do VPC Flow Logs provide?

Answer:
They provide metadata about network flows, including accepted and rejected traffic, but they do not provide complete packet contents.

Question 22

Why is Direct Connect not automatically a trusted network path?

Answer:
Dedicated connectivity does not verify user or workload identity and does not replace segmentation, encryption, inspection or authorisation controls.

Question 23

What is a quarantine Transit Gateway route table?

Answer:
It is a restrictive route table used to isolate compromised or suspended VPCs while retaining limited access to approved security services.

Question 24

Why must firewall rules have owners and review dates?

Answer:
Ownership and review dates prevent obsolete or temporary access from remaining active indefinitely.

Question 25

What is the final outcome of this project?

Answer:
A secure, segmented, observable and scalable enterprise AWS network architecture supporting multi-account workloads, private connectivity, central inspection, hybrid operations and rapid incident isolation.

💡 Key Takeaways

After completing this lesson, you should understand that enterprise network security is not limited to creating VPCs and security groups.

A mature enterprise network combines:

Central IP-address governance
Multi-account VPC architecture
Transit Gateway connectivity
Route-table segmentation
Centralised traffic inspection
AWS Network Firewall
Controlled internet ingress
Controlled internet egress
Private AWS service access
AWS PrivateLink
Enterprise DNS
DNS Firewall
Hybrid connectivity
Network telemetry
Threat detection
Incident isolation
Continuous governance

A strong network architecture allows CloudNova to provide only the connectivity required by the business while preventing unnecessary communication, reducing public exposure and maintaining complete security visibility.

🎓 Project Completion Criteria

You have completed this project when:

The current network environment has been assessed.
The network inventory is complete.
The IP-addressing strategy is documented.
The VPC standard is complete.
Transit Gateway architecture is designed.
Route-table segmentation is validated.
The inspection VPC is designed.
The Network Firewall policy is documented.
Internet ingress and egress are documented.
VPC endpoint requirements are defined.
PrivateLink architecture is documented.
Enterprise DNS architecture is complete.
DNS Firewall policy is defined.
Hybrid connectivity is documented.
VPC Flow Log standards are complete.
Network incident-isolation procedures exist.
Network governance is documented.
Connectivity tests have been completed.
The architecture review has been conducted.
All evidence is stored in the project repository.
The executive network-security strategy is ready for presentation.

🚀 Next Lesson

➡️ Lesson 04 — Enterprise Security Operations Platform Project

In the next lesson, you will design and implement CloudNova’s central security monitoring and operations platform using:

AWS CloudTrail
Amazon CloudWatch
AWS Config
Amazon GuardDuty
AWS Security Hub
Amazon Detective
Amazon Inspector
Amazon EventBridge
Amazon Security Lake
Security automation
SIEM integration
Detection engineering
Threat hunting
Incident-management workflows