03 AWS Network Security Review

A secure AWS network is not defined by the number of firewalls it has. It is defined by whether traffic paths, trust boundaries, segmentation, exposure, and monitoring are intentionally designed and continuously reviewed.

Welcome to the AWS Network Security Review Runbook.

You have already completed the hands-on AWS Network Security Lab.

This runbook now gives you a repeatable methodology for reviewing an unfamiliar AWS network from the perspective of a:

• Cloud Security Engineer

• Network Security Engineer

• Security Consultant

• Cloud Security Architect

• Cloud Penetration Tester

• AWS Security Engineer

The AWS Security – Specialty study guide emphasizes network segmentation, Security Groups, Network ACLs, VPC endpoints, Transit Gateway, VPN, Direct Connect, PrivateLink, VPC Flow Logs, secure egress, and host/network-layer protection as key infrastructure-security areas.

🎯 Runbook Information

Item	Details
Runbook	AWS Network Security Review
Difficulty	Intermediate → Advanced
Estimated Time	2–6 hours depending on environment
Primary Focus	AWS Network Architecture & Exposure
Target Roles	Cloud Security Engineer, Network Security Engineer, Security Consultant, Architect
Certification Alignment	AWS Certified Security – Specialty
Output	Network Findings, Risk Ratings, Remediation Plan, Architecture Review

🏢 Scenario

You have been given access to an AWS environment and asked:

“Can you review the network architecture and tell us whether it is secure?”

The environment may contain:

• multiple VPCs

• public and private subnets

• EC2 instances

• load balancers

• databases

• VPC endpoints

• NAT Gateways

• peering

• Transit Gateway

• VPN

• Direct Connect

• multiple AWS accounts

Your responsibility is not simply to check:

Which ports are open?

You need to understand:

• how traffic flows

• which systems are public

• which systems should be private

• how workloads are segmented

• whether east-west traffic is controlled

• whether internet egress is necessary

• how hybrid connectivity is protected

• whether network telemetry exists

🎯 Review Objectives

By the end of this runbook, you should be able to:

• inventory VPCs

• understand subnet architecture

• review route tables

• identify internet exposure

• assess Security Groups

• assess Network ACLs

• review NAT and egress

• review VPC endpoints

• assess VPC Peering

• assess Transit Gateway

• review PrivateLink

• assess VPN / Direct Connect

• review Flow Logs

• identify segmentation weaknesses

• identify unnecessary public access

• produce findings

• recommend remediation

• explain network risk to stakeholders

⚠️ Scope and Authorization

Before reviewing network security, confirm:

• AWS accounts in scope

• Regions in scope

• VPCs in scope

• production vs non-production

• whether hybrid connectivity is included

• whether networking changes are allowed

• whether assessment is read-only

Do not modify routes, Security Groups, NACLs, gateways, or production connectivity unless explicitly authorized.

🧭 Network Security Review Workflow

Use:

Scope
  ↓
VPC Discovery
  ↓
Subnet Review
  ↓
Routing Review
  ↓
Public Exposure
  ↓
Security Groups
  ↓
NACLs
  ↓
Egress Review
  ↓
Private Connectivity
  ↓
Inter-VPC Connectivity
  ↓
Hybrid Connectivity
  ↓
Flow Logs
  ↓
Findings
  ↓
Remediation
  ↓
Validation

01 — Understand the Network Architecture

Start with the architecture, not individual rules.

Identify:

• how many VPCs exist

• why each VPC exists

• workload ownership

• production/non-production separation

• shared-service networks

• central network accounts

Create:

VPC	Account	Region	CIDR	Purpose	Environment

🧠 First Question

Ask:

Why does this VPC exist?

If nobody knows, ownership and security governance may already be weak.

02 — Review VPC CIDR Design

For each VPC record:

• IPv4 CIDR

• IPv6 CIDR where used

• overlapping ranges

• future-growth considerations

🚨 Watch For

• overlapping CIDRs preventing clean connectivity

• extremely broad ranges without design justification

• unplanned address-space consumption

03 — Inventory Subnets

Create:

Subnet	CIDR	AZ	Public/Private	Purpose

Identify:

• public subnets

• private application subnets

• private database subnets

• inspection/security subnets

• shared-service subnets

🧠 Do Not Trust the Name

A subnet called:

private-subnet

is not necessarily private.

Review the route table.

04 — Determine What Makes Each Subnet Public

Check whether the associated route table includes a route such as:

0.0.0.0/0
    ↓
Internet Gateway

Also consider whether workloads have public addressing.

🧠 Interview-Level Principle

A public subnet is determined by network routing architecture, not simply by the subnet name.

05 — Review Internet Gateways

Inventory attached Internet Gateways.

For each VPC ask:

• does this VPC need internet-facing resources?

• which subnets route to the gateway?

• are sensitive workloads behind those subnets?

🚨 Risk Pattern

Internet Gateway
       ↓
Public Route
       ↓
Sensitive Workload

may indicate unnecessary attack surface.

06 — Review Route Tables

For every subnet, document:

Destination	Target	Purpose	Risk

Look for routes involving:

• Internet Gateway

• NAT Gateway

• Transit Gateway

• VPC Peering

• VPN

• Virtual Private Gateway

• VPC endpoints

🧠 Routing Review Question

Ask:

Where can this subnet send traffic?

and:

Which networks can send traffic back?

07 — Identify Publicly Addressed Resources

Inventory resources with public exposure.

Examples:

• EC2 public IPv4

• Elastic IPs

• internet-facing ALBs/NLBs

• public RDS configurations

• public APIs

Create:

Resource	Public?	Business Need	Control	Finding

08 — Review Public Administrative Access

Look specifically for:

• SSH

• RDP

• database administration

• Kubernetes management interfaces

• custom management ports

🚨 High-Risk Patterns

TCP 22
Source 0.0.0.0/0

TCP 3389
Source 0.0.0.0/0

These should receive immediate scrutiny.

09 — Review Security Groups

For every Security Group review:

• purpose

• associated resources

• ingress

• egress

• source/destination

• protocol

• port

• IPv4

• IPv6

📋 Security Group Review Matrix

SG	Direction	Port	Source/Destination	Business Need	Risk

10 — Identify Overly Broad Sources

Look for:

0.0.0.0/0
::/0

Then determine:

• resource type

• port

• business requirement

• actual reachability

🧠 Context Matters

Public TCP 443 on an internet-facing load balancer may be expected.

Public TCP 3306 on a database probably requires serious investigation.

11 — Review Security Group References

Where appropriate, determine whether SG-to-SG references are used.

Example:

ALB Security Group
        ↓
Application Security Group
        ↓
Database Security Group

This can provide stronger logical segmentation than broad CIDR rules.

12 — Review Egress Rules

Do not review ingress only.

Check whether workloads have:

All Traffic
→ 0.0.0.0/0

Ask:

Does this workload really need unrestricted outbound internet access?

🧠 Security Principle

Attackers often need egress for:

• command and control

• downloads

• data exfiltration

Outbound control matters.

13 — Review Security Group Lifecycle

Look for:

• unused Security Groups

• stale rules

• temporary rules never removed

• unclear descriptions

💡 Professional Tip

Require useful rule descriptions where operational processes support them.

A rule is easier to review when you know why it exists.

14 — Review Network ACLs

For each subnet review:

• associated NACL

• inbound rules

• outbound rules

• deny rules

• rule order

🧠 Remember

The AWS Security – Specialty material distinguishes Security Groups as stateful controls and NACLs as stateless subnet-level controls.

15 — Review NACL Complexity

Ask whether custom NACL rules:

• provide meaningful additional protection

• or create unnecessary troubleshooting complexity

Do not add controls simply to have more controls.

16 — Review Return Traffic

Because NACLs are stateless, verify:

• application ports

• ephemeral ports

• outbound rules

• return path

🚨 Common Finding

Required application traffic intermittently fails because response traffic is not permitted by the subnet NACL.

This is availability and security architecture, not only configuration.

17 — Review NAT Architecture

Identify:

• NAT Gateways

• NAT instances where applicable

• private subnet routes

Ask:

• which private workloads have internet egress?

• why is it required?

• is egress centralized?

• is it monitored?

💰 Architecture Consideration

NAT design affects:

• security

• availability

• cost

• operational complexity

18 — Identify Workloads That Do Not Need Internet Egress

Examples may include:

• databases

• internal processing tiers

• sensitive workloads

Ask whether they can use:

• VPC endpoints

• private package repositories

• approved proxy/egress controls

19 — Review VPC Endpoints

Inventory:

• gateway endpoints

• interface endpoints

The AWS Security – Specialty study guide highlights VPC endpoints and PrivateLink for private access to AWS services without unnecessary internet exposure.

20 — Review Endpoint Policies

For each endpoint ask:

• which principals can use it?

• which services/resources can be accessed?

• is the endpoint policy overly broad?

🚨 Example

A private S3 endpoint does not automatically mean:

all S3 access is secure.

IAM and bucket policies still matter.

21 — Review S3 Private Access Architecture

For sensitive S3 access, evaluate whether the organization uses patterns such as:

Private EC2
     ↓
S3 Gateway Endpoint
     ↓
S3 Bucket

with policies that restrict access appropriately.

22 — Review VPC Peering

Inventory peerings.

For each:

• source VPC

• destination VPC

• account

• Region

• purpose

• route tables

🧠 Important Question

Ask:

Does this peering create broader network trust than required?

23 — Review Peering at Scale

If the organization has many peerings, evaluate management complexity.

Large peer meshes may become difficult to:

• understand

• secure

• troubleshoot

This may justify a hub-based design depending on requirements.

24 — Review Transit Gateway

Where Transit Gateway exists, inventory:

• attachments

• route tables

• account ownership

• segmentation

🧠 Key Security Question

Ask:

Are all connected networks able to communicate with each other?

They should not necessarily be.

Transit Gateway route-table segmentation can be important.

25 — Review Shared Networking

In multi-account environments, determine whether networking is centralized.

Possible structure:

Network Account
│
├── Transit Gateway
├── Egress VPC
├── Inspection VPC
└── Shared Connectivity

Assess whether security responsibilities are clear.

26 — Review AWS PrivateLink

Where used, determine:

• service provider

• service consumer

• endpoints

• Security Groups

• access policies

🧠 Why PrivateLink Matters

PrivateLink can expose a service without creating broad VPC-to-VPC network connectivity.

This can reduce trust boundaries.

27 — Review Hybrid Connectivity

Identify:

• Site-to-Site VPN

• Direct Connect

• Transit Gateway integration

• on-premises networks

The study guide highlights VPN, Direct Connect, Transit Gateway, and PrivateLink as important secure-connectivity mechanisms.

28 — Review Site-to-Site VPN

Check:

• business purpose

• route propagation/static routes

• tunnel availability

• monitoring

• encryption

29 — Review Direct Connect

Remember:

Dedicated connectivity does not automatically mean encrypted connectivity.

Review whether additional encryption requirements exist.

30 — Review Routing Between Cloud and On-Premises

Understand:

On-Premises
     ↓
VPN / Direct Connect
     ↓
Transit Gateway / VGW
     ↓
AWS VPCs

Ask:

• which on-prem networks can reach production?

• which AWS networks can reach on-prem?

• is segmentation intentional?

31 — Review DNS Architecture

Assess:

• Route 53

• private hosted zones

• resolver endpoints

• hybrid DNS

🧠 Security Relevance

DNS can expose:

• internal resource naming

• misrouting

• unexpected resolution paths

32 — Review Load Balancers

For internet-facing load balancers assess:

• listener ports

• TLS

• certificates

• Security Groups

• target groups

• access logs

🔐 Application Security Connection

Where applicable, review integration with:

• AWS WAF

• AWS Shield

• CloudFront

33 — Review Internal Load Balancers

Confirm that internal services are not unnecessarily internet-facing.

34 — Review Database Network Placement

For RDS/Aurora or similar databases assess:

• public accessibility

• subnet groups

• Security Groups

• application-tier access

🚨 Preferred Pattern

Application SG
      ↓
Database SG

rather than:

0.0.0.0/0
      ↓
Database Port

35 — Review Management Access

Determine how administrators reach workloads.

Look for:

• public SSH/RDP

• bastion hosts

• VPN

• SSM Session Manager

The SCS-C02 study guide explicitly highlights SSM Session Manager as a method for EC2 administration without exposing port 22.

💡 Security Principle

Administrative access should be:

• authenticated

• authorized

• logged

• limited

• preferably private

36 — Review VPC Flow Logs

Check coverage at:

• VPC

• subnet

• ENI

The study guide identifies VPC Flow Logs for traffic auditing, troubleshooting, and incident investigation.

37 — Review Flow Log Storage

Assess:

• destination

• retention

• encryption

• access

38 — Review Flow Logs for Suspicious Patterns

Examples:

• repeated rejects

• unusual outbound destinations

• internal scanning

• unexpected ports

🧠 Important

Flow Logs provide metadata.

They are not packet captures.

39 — Review Network Monitoring Integration

Determine whether network telemetry feeds:

• CloudWatch

• S3

• GuardDuty

• SIEM

• SOC workflows

40 — Review Network Security Across Accounts

If multiple AWS accounts exist, assess:

• centralized network account

• Transit Gateway sharing

• RAM

• routing ownership

• security ownership

41 — Review Environment Segmentation

Ask whether:

Production
Development
Test
Security
Shared Services

have appropriate network separation.

🚨 Finding Pattern

Development systems should not automatically have unrestricted network access to production.

42 — Review Sensitive Workload Segmentation

High-value systems may require stronger isolation.

Examples:

• payment systems

• identity systems

• regulated workloads

• security tooling

43 — Review Attack Surface

Create an exposure map.

Internet
│
├── ALB :443
├── EC2 :22   ← Review
├── RDS :3306 ← High Risk
└── API Gateway

🧠 Attack Surface Question

Ask:

Which of these services genuinely require internet exposure?

44 — Review East-West Attack Surface

Do not focus only on the internet.

Review lateral pathways between:

• web tier

• application tier

• database tier

• shared services

• other VPCs

45 — Create a Network Trust Map

Example:

Internet
   ↓
Web Tier
   ↓
Application Tier
   ↓
Database Tier

Dev VPC ─X→ Production DB

This makes intended and prohibited trust clearer.

46 — Identify Findings

Use:

Condition
+
Exposure
+
Attack Path
+
Business Impact
+
Recommendation

📄 Standard Finding Format

Finding ID:

Title:

Severity:

Affected Resource:

Network Path:

Observation:

Evidence:

Risk:

Business Impact:

Recommendation:

Validation:

47 — Example Finding — Public SSH

Finding ID:
NET-001

Title:
SSH Exposed to the Internet

Severity:
High

Affected Resource:
Production EC2 Security Group

Observation:
TCP/22 is permitted from 0.0.0.0/0.

Risk:
The workload is directly exposed to internet-based administrative access attempts.

Recommendation:
Remove unrestricted public SSH and use SSM Session Manager, VPN, or tightly controlled management access.

48 — Example Finding — Public Database

Finding ID:
NET-002

Title:
Production Database Publicly Reachable

Severity:
Critical / High

Observation:
Database is publicly accessible and allows the database service port from a broad network range.

Risk:
Direct network exposure significantly increases the attack surface of a sensitive data system.

Recommendation:
Move database access behind private network controls and permit connections only from authorized application workloads.

49 — Example Finding — Unrestricted Egress

Finding ID:
NET-003

Title:
Sensitive Application Has Unrestricted Internet Egress

Severity:
Medium / High depending on workload

Observation:
The application tier can initiate unrestricted outbound internet connections.

Risk:
A compromised workload could communicate with external infrastructure or exfiltrate data.

Recommendation:
Evaluate business-required destinations and implement appropriate egress restrictions or controlled proxy/private-service paths.

50 — Rate Network Risk

Use:

Exposure
+
Reachability
+
Service Sensitivity
+
Exploitability
+
Business Impact
=
Risk

🔴 Critical

Examples:

• public sensitive database

• exposed privileged management plane

🟠 High

Examples:

• public SSH/RDP

• broad production-to-production trust

• major segmentation failure

🟡 Medium

Examples:

• unnecessary egress

• missing Flow Logs

• overly broad internal ranges

🔵 Low

Examples:

• stale Security Group

• missing rule descriptions

• unused network resource

51 — Prioritize Remediation

Recommended order:

Critical Public Exposure
        ↓
Administrative Exposure
        ↓
Sensitive Lateral Access
        ↓
Egress Weaknesses
        ↓
Monitoring Gaps
        ↓
Architecture Cleanup

52 — Create a Remediation Roadmap

Finding	Recommendation	Priority	Owner
Public DB	Remove public exposure	Immediate	DB/Cloud Team
Public SSH	Move to SSM	Immediate	Platform Team
Open egress	Restrict outbound	Short Term	Network Team
Missing Flow Logs	Enable visibility	Short Term	Security Team

53 — Validate Remediation

After remediation, test both:

Required Traffic → Works

Unauthorized Traffic → Fails

🧠 Do Not Validate by Console Alone

Where safe and authorized, test actual connectivity.

54 — Review for Unintended Side Effects

Network changes can cause outages.

Validate:

• applications

• monitoring

• dependencies

• DNS

• integrations

55 — Create the Network Architecture Diagram

Your assessment report should include a simple architecture.

Example:

Internet
   ↓
CloudFront / WAF
   ↓
ALB
   ↓
Private App Subnets
   ↓
Private Database Subnets

        ↓
 VPC Endpoint → S3

56 — Create an Exposure Summary

Exposure Type	Count
Public EC2
Public Load Balancers
Public DBs
Open Admin Ports
Internet Egress Paths

57 — Create a Security Group Summary

Summarize:

• high-risk inbound rules

• broad internal rules

• unrestricted egress

• stale SGs

58 — Create the Executive Summary

Example:

The AWS network security review identified unnecessary public exposure and overly permissive east-west connectivity.

The highest-priority concerns include internet-accessible administrative interfaces and broad access to sensitive application tiers.

Immediate remediation should focus on reducing public exposure, restricting Security Group trust relationships, and validating segmentation between application and database workloads.

Longer-term improvements should include stronger egress controls, private AWS-service access, and centralized network visibility.

59 — Prepare the Technical Report

Recommended structure:

1. Scope
2. Architecture Overview
3. VPC Inventory
4. Public Exposure
5. Security Group Review
6. NACL Review
7. Routing & Egress
8. Private Connectivity
9. Inter-VPC Connectivity
10. Hybrid Connectivity
11. Monitoring
12. Findings
13. Remediation Roadmap

🎤 AWS Network Security Review Interview Questions

Practise without notes.

Architecture

1. How would you review AWS network security?

2. What information would you gather first?

3. How do you identify internet-facing resources?

Subnets & Routing

4. What makes a subnet public?

5. Internet Gateway vs NAT Gateway?

6. How would you troubleshoot a private subnet that cannot access the internet?

Security Groups

7. What do you look for during a Security Group review?

8. Security Group vs NACL?

9. Why use Security Group references instead of broad CIDRs?

10. Why should egress be reviewed?

Private Access

11. What is a VPC endpoint?

12. Why use an S3 gateway endpoint?

13. What is PrivateLink?

Connectivity

14. VPC Peering vs Transit Gateway?

15. When would Transit Gateway be appropriate?

16. VPN vs Direct Connect?

Monitoring

17. What do VPC Flow Logs provide?

18. How would you investigate suspicious outbound traffic?

🚨 Scenario Interview Question 1

You discover that a production RDS database is publicly accessible. What would you review before assigning severity?

A strong answer should consider:

• public accessibility

• route path

• Security Group

• database port

• source range

• authentication

• data sensitivity

• business purpose

🚨 Scenario Interview Question 2

An application server needs access to S3, but security policy prohibits general internet access. What would you recommend?

Discuss:

• S3 VPC endpoint

• endpoint policy

• IAM

• bucket policy

🚨 Scenario Interview Question 3

Security Group rules look correct, but traffic still fails. What would you investigate?

Use:

Route
↓
Security Group
↓
NACL
↓
DNS
↓
Service Listener
↓
OS Firewall
↓
Return Path

🚨 Scenario Interview Question 4

Twenty VPCs need controlled connectivity. Would you use VPC Peering or Transit Gateway?

Do not answer based on service popularity.

Discuss:

• topology

• scale

• routing

• segmentation

• management overhead

• cost

🧠 Interview Answer Framework

For AWS network questions use:

Source
   ↓
Destination
   ↓
Route
   ↓
Network Control
   ↓
Workload Control
   ↓
Return Path
   ↓
Telemetry

💬 Interview Tip

Avoid:

“Check the Security Group.”

A stronger answer:

“I would identify the source and destination first, verify the expected routing path, review Security Group rules on the relevant interfaces, check subnet NACLs and return traffic, verify the application is listening, and then use Flow Logs to correlate network behavior.”

📁 Portfolio Deliverables

Create sanitized examples of:

• VPC inventory

• architecture diagram

• public-exposure matrix

• Security Group review

• route analysis

• network findings

• remediation roadmap

• trust-boundary diagram

📝 Resume Examples

Instead of:

Experience with AWS networking.

Use:

Performed an AWS network security review covering VPCs, public/private subnets, route tables, Security Groups, NACLs, VPC endpoints, public exposure, and Flow Logs.

Or:

Identified excessive network exposure and lateral-access paths in an AWS lab environment and produced prioritized remediation recommendations with architecture diagrams and validation steps.

⭐ Runbook Readiness Check

You should be able to:

• inventory AWS network architecture

• identify public/private subnets

• interpret route tables

• identify public exposure

• evaluate Security Groups

• review NACLs

• assess outbound traffic

• explain VPC endpoints

• review VPC Peering

• assess Transit Gateway

• understand hybrid connectivity

• use Flow Logs

• create network findings

• recommend practical remediation

The objective is not:

I reviewed every Security Group.

The objective is:

I understand which network paths exist, which trust relationships are necessary, which exposures create risk, and how to reduce attack surface without disrupting required business communication.

🏆 Runbook Complete

You now have a repeatable methodology for:

Network Discovery
      ↓
Exposure Analysis
      ↓
Segmentation Review
      ↓
Routing Analysis
      ↓
Traffic Control Review
      ↓
Private Connectivity
      ↓
Network Visibility
      ↓
Risk Analysis
      ↓
Remediation
      ↓
Validation

This methodology directly supports roles such as:

• Cloud Security Engineer

• AWS Security Engineer

• Network Security Engineer

• Cloud Security Consultant

• Cloud Security Architect

🚀 What’s Next?

You have now completed the AWS security assessment runbooks for:

AWS Account Security Assessment
        ↓
AWS IAM Security Review
        ↓
AWS Network Security Review

The next runbook brings together the detection, investigation, containment, evidence, and recovery skills from the AWS Incident Response Lab into a repeatable professional response methodology.

➡️ Next: AWS Incident Response Runbook

In the next runbook, you will cover:

• incident intake

• severity classification

• compromised credentials

• IAM investigation

• EC2 compromise

• evidence preservation

• CloudTrail analysis

• Flow Log analysis

• GuardDuty/Security Hub findings

• containment decisions

• eradication

• recovery

• incident timeline

• root cause analysis

• post-incident reporting