02 AWS Network Security

Cloud network security is not just about blocking ports. It is about understanding traffic flow, trust boundaries, exposure, segmentation, and how workloads communicate.

Welcome to the AWS Network Security Lab.

In the previous lab, you focused on identity:

Who can access AWS?

In this lab, you will focus on network communication:

Which systems can communicate, through which paths, and under what controls?

You will move from:

I know what a VPC is.

to:

I can assess, secure, troubleshoot, and explain an AWS network architecture.

This lab is designed for learners preparing for roles such as:

• Cloud Security Engineer

• Cloud Engineer

• Network Security Engineer

• DevSecOps Engineer

• Cloud Security Consultant

• Cloud SOC Analyst

• Cloud Penetration Tester

• Cloud Security Architect

🎯 Mission Information

Item	Details
Lab	AWS Network Security
Difficulty	Beginner → Intermediate
Estimated Time	2–3 hours
Primary Focus	AWS VPC & Network Security
Target Roles	Cloud Security Engineer, Cloud Engineer, Network Security Engineer
Certification Alignment	Solutions Architect Associate, Security Specialty
Career Skill	Network Security Assessment & Troubleshooting
Environment	Personal AWS lab account
Cost Awareness	Some networking resources may generate charges

⚠️ Cost Awareness

Networking labs can create billable resources.

Pay particular attention to services such as:

• NAT Gateway

• Elastic Load Balancing

• public IPv4 addresses

• data transfer

• VPC endpoints

For a low-cost lab, you can complete most exercises using:

• VPC

• subnets

• route tables

• Security Groups

• NACLs

• one small EC2 instance if needed

• VPC Flow Logs where appropriate

Delete unnecessary resources when finished.

🏢 Mission Scenario

You have joined the security team of a company migrating a small application into AWS.

The initial architecture was built quickly.

Security has raised several concerns:

• application servers may be unnecessarily exposed to the internet

• Security Groups may contain overly broad rules

• private subnets may have incorrect routes

• subnet-level controls have not been reviewed

• there is limited visibility into network traffic

• workloads may be reaching AWS services through unnecessary public paths

Your task is to:

1. understand the environment

2. identify exposure

3. apply segmentation

4. restrict network access

5. enable visibility

6. troubleshoot connectivity

7. document security findings

🎯 Mission Objectives

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

• explain AWS VPC architecture

• distinguish public and private subnets

• understand route tables

• review internet exposure

• configure Security Groups

• explain Security Groups vs NACLs

• work with Internet Gateways

• understand NAT-based egress

• understand VPC endpoints

• enable VPC Flow Logs

• investigate rejected or unexpected traffic

• identify overly broad rules

• document network-security findings

• explain AWS networking during interviews

📚 Prerequisites

You should understand:

• IP addresses

• CIDR

• TCP/UDP

• ports

• routing

• firewalls

• AWS EC2 basics

• AWS VPC basics

• IAM basics

Recommended previous work:

• AWS Certified Cloud Practitioner

• AWS Certified Solutions Architect – Associate

• AWS Certified Security – Specialty

• AWS IAM Security Lab

🧠 The AWS Network Security Mental Model

Think of network security as:

Source
   ↓
Route
   ↓
Network Control
   ↓
Destination
   ↓
Response Path

For every connectivity question, ask:

Source

Where is traffic coming from?

Destination

Where is it going?

Route

Is there a valid network path?

Security Group

Is the traffic allowed at the workload interface?

NACL

Is subnet-level traffic allowed?

Return Traffic

Can the response return successfully?

DNS

Does the hostname resolve correctly?

Exposure

Does this traffic actually need to be public?

🏗️ Lab Architecture

You will build or review a simple two-tier environment.

Internet
   ↓
Internet Gateway
   ↓
Public Subnet
   ↓
Web / Bastion Test Instance
   ↓
Private Subnet
   ↓
Application Instance

Conceptually, the environment should separate:

Public Exposure
      ↓
Controlled Entry Point
      ↓
Private Workload

🧪 Task 1 — Review Your Existing VPCs

Navigate to:

VPC → Your VPCs

For each VPC, record:

• VPC name

• CIDR

• default/non-default

• number of subnets

• route tables

• attached gateways

Create a quick inventory.

VPC	CIDR	Subnets	Internet Gateway	Notes

🧠 Security Question

Ask:

Why does this VPC exist?

A surprising amount of network risk comes from resources that nobody understands or owns.

🧪 Task 2 — Create a Lab VPC

Create a dedicated VPC.

Example:

Name:
ghc-network-security-lab

CIDR:
10.10.0.0/16

Do not overcomplicate the environment.

🧪 Task 3 — Create Public and Private Subnets

Create two subnets.

Example:

Public Subnet
10.10.1.0/24

Private Subnet
10.10.2.0/24

Place them in an Availability Zone appropriate to your lab.

🧠 Important Concept

A subnet is not public simply because it is named PublicSubnet.

A subnet becomes public when its routing permits internet connectivity through an Internet Gateway and workloads have the required addressing/configuration.

This is a common interview question.

🧪 Task 4 — Attach an Internet Gateway

Create an Internet Gateway.

Example:

ghc-lab-igw

Attach it to the lab VPC.

🔎 Security Analysis

An Internet Gateway does not automatically expose every resource.

Exposure depends on several factors, including:

• routes

• public addressing

• Security Groups

• application listeners

🧪 Task 5 — Configure the Public Route Table

Create a route table for the public subnet.

Add:

Destination:
0.0.0.0/0

Target:
Internet Gateway

Associate the route table with the public subnet.

✅ Expected Architecture

Public Subnet
     ↓
0.0.0.0/0
     ↓
Internet Gateway

🧪 Task 6 — Configure the Private Route Table

Create a separate route table for the private subnet.

Initially, leave it without a default internet route.

You should still have the local VPC route.

This gives you:

Private Subnet
     ↓
Internal VPC Communication Only

for the early part of the lab.

🧠 Interview Concept — What Makes a Subnet Private?

A strong answer is:

A private subnet does not have a direct route to an Internet Gateway for general internet access.

Do not answer only:

It doesn’t have a public IP.

That is incomplete.

🧪 Task 7 — Create a Web Security Group

Navigate:

EC2 → Security Groups

Create:

Name:
ghc-web-sg

Allow only the traffic needed for your test.

For example:

HTTP 80
Source: Your testing source or controlled range

If you use SSH, restrict it tightly.

Avoid:

SSH 22
Source: 0.0.0.0/0

🚨 Security Finding

A common AWS finding is:

Administrative port exposed to the entire internet.

Examples include:

• 22

• 3389

• database ports

💡 Better Options

Depending on architecture, consider:

• Session Manager

• VPN

• bastion with restricted access

• private administrative connectivity

🧪 Task 8 — Create an Application Security Group

Create:

ghc-app-sg

Instead of allowing traffic from the entire VPC CIDR, allow traffic from the web Security Group where appropriate.

Conceptually:

Web SG
   ↓
Allowed
   ↓
App SG

This creates a stronger workload relationship.

🧠 Why Reference Security Groups?

Security Group references let you express:

Allow traffic from workloads that belong to this security group.

rather than relying only on IP addresses.

This can be much easier to maintain in dynamic environments.

🧪 Task 9 — Launch Test EC2 Instances

If budget permits, launch small lab instances.

Example:

Web Instance
→ Public Subnet
→ ghc-web-sg

App Instance
→ Private Subnet
→ ghc-app-sg

Use only minimal resources.

⚠️ Important

Do not expose more services than required.

You are building a security lab, not a permanent internet-facing service.

🧪 Task 10 — Test Allowed Traffic

Test communication that should succeed.

Examples:

• client → web instance

• web instance → application instance

Document the expected flow.

Internet
   ↓
Web
   ↓
Application

🧪 Task 11 — Test Denied Traffic

Now intentionally test something that should fail.

Examples:

• internet → private application directly

• app instance → unexpected port

• arbitrary client → private service

Observe the result.

🎯 Key Learning

Security becomes meaningful only when you test:

allowed

and:

denied

behavior.

🧪 Task 12 — Review Security Group Rules

For every Security Group, ask:

• Why does this rule exist?

• Is the port necessary?

• Is the source too broad?

• Does the rule reference another SG where possible?

• Is IPv6 also exposed?

• Is this ingress or egress requirement still valid?

📋 Security Group Assessment

SG	Direction	Port	Source/Destination	Risk	Recommendation

🚨 Common Security Group Findings

Critical / High

• database exposed to 0.0.0.0/0

• SSH/RDP exposed globally

• broad administrative access

Medium

• entire VPC allowed when only one application tier needs access

• unnecessary outbound access

Low

• stale rules

• unclear naming

• missing documentation

🧪 Task 13 — Understand Stateful Behavior

Security Groups are stateful.

If inbound traffic is allowed and a connection is established, return traffic is automatically permitted as part of that connection state.

This is one reason Security Group troubleshooting differs from NACL troubleshooting.

🧪 Task 14 — Review Network ACLs

Navigate:

VPC → Network ACLs

Identify the NACL associated with each subnet.

Review:

• inbound rules

• outbound rules

• rule numbers

• allows

• denies

🧠 Security Group vs NACL

Feature	Security Group	NACL
Level	ENI/resource	Subnet
Stateful	Yes	No
Allow	Yes	Yes
Explicit Deny	No	Yes
Rule processing	Combined	Ordered

🧪 Task 15 — Create a Controlled NACL Test

Create a lab NACL only if you are comfortable troubleshooting.

Associate it with one lab subnet.

Create deliberate rules that permit required traffic and deny a selected test case.

⚠️ Important

NACLs are stateless.

You need to think about:

• inbound traffic

• outbound traffic

• ephemeral ports

• response path

This is a frequent source of misconfiguration.

🧠 Interview Tip

If a Security Group looks correct but traffic still fails, consider:

• NACL

• route table

• DNS

• service listener

• OS firewall

Do not assume IAM is involved in every AWS problem.

🧪 Task 16 — Investigate Route Tables

For each subnet, document:

Destination
Target
Purpose

Review:

• local route

• internet route

• NAT route

• peering/transit routes if present

🔍 Troubleshooting Question

If a private instance cannot reach another internal subnet:

ask:

1. Is there a route?

2. Do SG rules allow it?

3. Do NACLs allow it?

4. Is the service listening?

5. Is DNS correct?

🧪 Task 17 — Understand NAT Egress

Private workloads often need outbound internet access for:

• updates

• package repositories

• third-party APIs

A common architecture is:

Private Subnet
     ↓
NAT Gateway
     ↓
Internet Gateway
     ↓
Internet

⚠️ Cost Warning

NAT Gateway can generate ongoing charges.

You do not need to leave one running for this lab.

Understand the architecture and create it only if needed for practice.

🧠 Security Question

Ask:

Does this workload actually need general internet access?

Sometimes a private AWS service path is more appropriate.

🧪 Task 18 — Explore VPC Endpoints

Review:

VPC → Endpoints

Understand how VPC endpoints allow private connectivity to supported AWS services.

Common examples include:

• S3

• DynamoDB

• interface-based AWS services

Conceptually:

Private Workload
      ↓
VPC Endpoint
      ↓
AWS Service

instead of:

Private Workload
      ↓
NAT
      ↓
Internet Path
      ↓
AWS Service

🔐 Security Benefit

VPC endpoints can help:

• reduce unnecessary public paths

• support private service access

• enforce endpoint policies

• improve control over data paths

🧪 Task 19 — Review Endpoint Policies

If you create or inspect an endpoint, review its policy.

Ask:

Can every principal use this endpoint for every supported resource?

Consider restricting:

• actions

• resources

• principals

where appropriate.

🧪 Task 20 — Enable VPC Flow Logs

Enable Flow Logs at one suitable level:

• VPC

• subnet

• ENI

Send logs to a destination such as:

• CloudWatch Logs

• S3

depending on your lab configuration.

🧠 What Flow Logs Tell You

Flow Logs provide traffic metadata such as:

• source

• destination

• ports

• protocol

• accept/reject

They are useful for:

• troubleshooting

• security investigations

• network visibility

🧪 Task 21 — Generate Accepted and Rejected Traffic

Create traffic that should be:

ACCEPT

and traffic that should be:

REJECT

Then inspect Flow Logs.

🔎 Investigation Questions

Ask:

• Which source initiated the connection?

• Which destination was targeted?

• Which port?

• Was it accepted?

• Was it rejected?

• Does this align with expected behavior?

🚨 Security Operations Connection

A single rejected connection is not automatically malicious.

Context matters.

Patterns such as:

• repeated port scanning

• unexpected source ranges

• lateral probing

• unusual destinations

may require further investigation.

🧪 Task 22 — Simulate an Overexposed Security Group

Temporarily create a controlled lab misconfiguration.

Example:

TCP 22
Source:
0.0.0.0/0

Do not leave it open longer than necessary.

📝 Create a Finding

Example:

Finding ID:
NET-001

Title:
SSH Exposed to the Internet

Severity:
High

Resource:
ghc-web-sg

Observation:
Port 22 is allowed from 0.0.0.0/0.

Risk:
Internet hosts can directly attempt administrative access to the workload.

Recommendation:
Remove public SSH exposure and use restricted administrative access such as SSM Session Manager or approved management networks.

Then remediate it.

🧪 Task 23 — Review Public Exposure

Check your lab for:

• public IPv4 addresses

• routes to IGW

• permissive Security Groups

• public load balancers

• publicly reachable services

Ask:

Does this component need to be public?

Public exposure should be an architectural decision, not an accident.

🧪 Task 24 — Design a More Secure Three-Tier Pattern

Extend the architecture conceptually.

Internet
   ↓
Public Load Balancer
   ↓
Private Application Tier
   ↓
Private Database Tier

Security relationships:

Internet
   ↓
ALB Security Group
   ↓
Application Security Group
   ↓
Database Security Group

The database does not need internet access.

The application does not necessarily need direct internet exposure.

🧠 Defense in Depth

Good AWS network security combines:

• architecture

• routing

• Security Groups

• NACLs where justified

• private access

• workload hardening

• logging

• monitoring

Do not rely on one control.

🧪 Task 25 — Troubleshooting Challenge 1

Scenario:

The web server cannot connect to the application server on TCP 8080.

Use a structured method.

Step 1 — Confirm the Service

Is the application listening on TCP 8080?

Step 2 — Check Source/Destination

Are you testing the correct IP/hostname?

Step 3 — Check Route

Is there a valid local VPC route?

Step 4 — Check Application SG

Does it allow TCP 8080 from the web SG?

Step 5 — Check NACL

Are inbound and return traffic permitted?

Step 6 — Check OS Firewall

Is the instance-level firewall blocking traffic?

🧪 Task 26 — Troubleshooting Challenge 2

Scenario:

A private EC2 instance cannot download system updates.

Investigate:

Route Table
   ↓
NAT / Egress Path
   ↓
Security Group Egress
   ↓
NACL
   ↓
DNS

Do not immediately make the subnet public.

🧪 Task 27 — Troubleshooting Challenge 3

Scenario:

An internal application needs S3 access, but security does not want general internet egress.

Consider:

VPC endpoint for S3.

Then evaluate:

• routing

• endpoint policy

• bucket policy

• IAM

This demonstrates how networking and IAM intersect.

🧪 Task 28 — Create a Network Security Assessment

Build a professional-style checklist.

Control	Status	Risk	Recommendation
Public subnet design
Private subnet design
SG least privilege
Admin ports restricted
Database exposure
NACL review
Route table review
Internet egress
VPC endpoint usage
Flow Logs

📊 Risk Classification

Use a simple model.

Critical

Direct exposure could lead to immediate major compromise.

High

Significant unnecessary network access exists.

Medium

Architecture or segmentation weakness.

Low

Hardening/documentation improvement.

🚨 Incident Scenario — Suspicious Network Activity

Imagine you receive a GuardDuty or SOC alert indicating:

An EC2 instance is communicating with a suspicious external IP.

How would you respond?

Use:

Validate
   ↓
Identify Workload
   ↓
Review Flow Logs
   ↓
Review Security Group
   ↓
Review CloudTrail
   ↓
Contain
   ↓
Determine Scope
   ↓
Remediate

1. Validate

Confirm:

• instance

• source/destination

• port

• timing

2. Review Network Evidence

Examine:

• VPC Flow Logs

• firewall/security controls

• relevant telemetry

3. Review Identity Activity

Look for unusual:

• IAM role usage

• API calls

• credential activity

4. Contain

Depending on your incident process:

• apply quarantine SG

• restrict egress

• isolate affected workload

5. Preserve Evidence

Do not destroy potentially useful evidence without considering investigation needs.

6. Scope

Determine whether:

• other workloads communicated with the same destination

• credentials were used

• lateral activity occurred

🎤 AWS Network Security Interview Questions

Practise answering these without notes.

Fundamentals

1. What is a VPC?

2. What is a subnet?

3. What makes a subnet public?

4. What makes a subnet private?

5. What is a route table?

Gateways

6. What is an Internet Gateway?

7. What is a NAT Gateway?

8. Internet Gateway vs NAT Gateway?

Security Controls

9. Security Group vs NACL?

10. Why are Security Groups stateful?

11. Why are NACLs harder to troubleshoot?

12. Can Security Groups explicitly deny traffic?

13. Can NACLs deny traffic?

Private Connectivity

14. What is a VPC endpoint?

15. Why would you use a VPC endpoint?

16. Gateway endpoint vs interface endpoint?

Visibility

17. What are VPC Flow Logs?

18. What information do Flow Logs provide?

19. How would you investigate rejected traffic?

Security Architecture

20. How would you secure a three-tier web application?

21. Should a database have a public IP?

22. How would you restrict database access to application servers only?

23. How would you provide administrative access without exposing SSH publicly?

🚨 Scenario Interview Question

A database Security Group allows TCP 3306 from 0.0.0.0/0. What is your assessment?

A strong answer should explain:

• why the exposure is risky

• whether the database is actually publicly reachable

• how route/public addressing also affects reachability

• how to restrict access to the application tier

• how to validate the remediation

🧠 Interview Answer Framework

For connectivity questions use:

Source
   ↓
Destination
   ↓
Route
   ↓
Security Group
   ↓
NACL
   ↓
Service
   ↓
Return Path

This gives your answers structure.

💬 Interview Tip

Do not answer:

“Check the Security Group.”

Say:

“I would first confirm the source, destination, and expected port, then check the route table, destination Security Group, subnet NACL, whether the service is listening, and the return path. I would use Flow Logs if I needed network-level evidence.”

That sounds like an engineer.

📁 Portfolio Evidence

After completing the lab, create a sanitized portfolio package containing:

Architecture Diagram

Show:

• VPC

• public subnet

• private subnet

• traffic flow

Security Group Matrix

Document:

• source

• destination

• protocol

• business reason

Network Findings

Create 2–5 findings.

Flow Log Example

Include sanitized accepted/rejected traffic examples.

Remediation

Explain what you changed and why.

📝 Resume Examples

Instead of:

Knowledge of AWS VPC.

Use:

Built and assessed a segmented AWS VPC lab with public and private subnets, route tables, Security Groups, Network ACLs, and Flow Logs, then remediated excessive network exposure.

Or:

Investigated AWS connectivity issues using route tables, Security Groups, NACLs, and VPC Flow Logs and documented network-security findings and remediation.

⭐ Job-Readiness Check

After this lab, you should be able to:

• explain VPC architecture

• identify public vs private subnets

• read route tables

• review Security Groups

• explain stateful/stateless controls

• review NACLs

• identify public exposure

• understand NAT egress

• explain VPC endpoints

• use Flow Logs for analysis

• troubleshoot common connectivity issues

• document network-security findings

If several of these still feel unclear, repeat the lab.

The objective is not:

I configured a VPC once.

The objective is:

I can look at an unfamiliar AWS network and reason about how traffic flows and where security controls should exist.

🧹 Lab Clean-Up

After completing your evidence collection:

• terminate temporary EC2 instances

• delete unnecessary public IP resources

• remove temporary test Security Groups

• remove test NACLs if no longer needed

• delete temporary Flow Log destinations as appropriate

• remove NAT Gateway if you created one

• remove unused VPC endpoints

• delete the lab VPC if you no longer need it

Check your AWS billing dashboard afterward.

🏆 Mission Complete

You have now practised:

Network Architecture
      ↓
Segmentation
      ↓
Routing
      ↓
Traffic Control
      ↓
Private Connectivity
      ↓
Logging
      ↓
Troubleshooting
      ↓
Security Assessment

These capabilities are essential for:

• Cloud Security Engineers

• Cloud Engineers

• Cloud Security Consultants

• DevSecOps Engineers

• Cloud Penetration Testers

• Cloud Security Architects

🚀 What’s Next?

You now understand who can access AWS and how workloads communicate.

The next step is understanding what security telemetry AWS generates, how to centralize it, and how to identify suspicious activity.

➡️ Next: AWS Logging & Monitoring Lab

In the next lab, you will work with:

• AWS CloudTrail

• Amazon CloudWatch

• AWS Config

• VPC Flow Logs

• centralized logging concepts

• log protection

• alerts

• security investigation

• evidence collection

• SOC-style troubleshooting

• interview scenarios