Build a Secure VPC on AWS

Design a multi-AZ VPC with layered security groups, NACLs, and Flow Logs.

Introduction

30 Second Summary

Every time you use an online banking app or shop on a website, your data travels through networks with invisible security layers keeping attackers out. These layers work together so that even if one is breached, others still stand.

In this project, you will build a production-grade secure network on AWS that isolates workloads, controls traffic at multiple layers, and monitors all activity using the same patterns that companies use in real production environments.

What You'll Build

A multi-Availability Zone VPC with layered network security following the AWS Well-Architected Framework security best practices.

By the end of this project, you'll have:

A VPC with public and private subnets across two Availability Zones, with a NAT gateway enabling controlled outbound-only internet access from private subnets.
Layered network security using tiered security groups and a custom Network ACL working together as defense-in-depth.
Traffic monitoring via VPC Flow Logs publishing to CloudWatch for complete visibility into all network activity.
Secret Mission: implement a deny rule in your Network ACL that blocks a suspicious IP range, then verify the block appears in your Flow Logs.

Are there any prerequisites?

You need an AWS account with a credit card on file. The NAT gateway in this project costs approximately $0.045 per hour, so you should complete the project and delete resources promptly to keep costs under $1.

No prior AWS experience is required. This project walks you through every click.

Set Up Your AWS Account for the Project

Before you build any network infrastructure, you need a properly configured AWS environment. Every resource you create in this project must live in the same region, and you need visibility into costs from the start.

In this step, you will sign in to the AWS Management Console, select a region, verify billing alerts, and navigate to the VPC console where you will do all of your work.

In this step, get ready to:

Sign in to the AWS Management Console and set your region.
Verify billing alerts are enabled.
Navigate to the VPC Dashboard.

Sign in to the AWS Management Console and set your region

All resources in this project must live in the same AWS region. Choosing a region now ensures everything you build is co-located and can communicate.

Open your web browser and navigate to https://console.aws.amazon.com/.
Sign in with your root account credentials (the email and password you used to create your AWS account).
In the top-right corner of the console, click the region dropdown.
Select a region close to you. For example, select US East (N. Virginia) us-east-1.

Why does region matter?

AWS runs data centers in regions around the world. When you create a resource like a VPC or subnet, it only exists in the region you selected. If you accidentally switch regions mid-project, you will not see your previously created resources.

Pick one region now and stick with it for the entire project. Note which one you chose.

Verify billing alerts are enabled

This project uses a NAT gateway that costs $0.045 per hour while running. Billing alerts notify you if costs exceed your expectations so there are no surprises.

In the top search bar, type Billing and select Billing and Cost Management from the results.
In the left navigation pane, click Billing preferences.
Confirm that Receive billing alerts or CloudWatch billing alerts is enabled.
If it is not enabled, toggle it on and click Save preferences.

Delete resources when you finish

The NAT gateway is the primary cost driver in this project. You will delete all resources in the Before You Go section at the end. Completing the project in one sitting and cleaning up immediately keeps your total cost well under $1.00.

Navigate to the VPC console

The VPC console is where you will build your entire network architecture. Everything from subnets to security groups lives here.

In the top search bar, type VPC and select VPC from the results.
You should see the VPC Dashboard with an overview of your account's existing VPC resources.

What is a VPC?

A VPC (Virtual Private Cloud) is your own isolated network inside AWS. Think of it as a private data center that only you control. You decide which IP addresses to use, how to divide the network into sections, and what traffic is allowed in or out.

Every AWS account comes with a default VPC, but production workloads use custom VPCs with carefully designed security boundaries. That is exactly what you will build next.

Your AWS environment is ready. Next up, you will create your secure VPC with public and private subnets spread across two Availability Zones.

Create Your Secure VPC with Subnet Tiers

Your AWS account is ready and you know where you are in the console. Now it's time to build the network that everything else sits on.

Every production workload on AWS starts with a VPC (Virtual Private Cloud). A VPC is your own isolated slice of the AWS network where you control exactly who gets in and what goes out. In this step, you'll create a VPC with separate public and private subnets spread across two Availability Zones.

In this step, get ready to:

Create a full VPC architecture using the AWS wizard (VPC, subnets, gateways, route tables, and S3 endpoint).
Verify your resources using the Resource map.
Understand how routing works across your public and private subnets.

Create the VPC with public and private subnets

AWS provides a wizard called "VPC and more" that creates your entire network architecture in one operation. This includes the VPC itself, subnets, route tables, gateways, and endpoints.

On the VPC Dashboard, choose Create VPC.
For Resources to create, choose VPC and more.
For Name tag auto-generation, enter secure-prod.
For IPv4 CIDR block, keep the default 10.0.0.0/16.
For Number of Availability Zones, choose 2.
For Number of public subnets, choose 2.
For Number of private subnets, choose 2.
For NAT gateways, choose In 1 AZ.
For VPC endpoints, keep the S3 Gateway default selected.
For DNS options, keep the defaults (Enable DNS hostnames checked, Enable DNS resolution checked).
Review the Preview pane on the right side. It shows an architecture diagram of all the resources that will be created.
Choose Create VPC.
Wait for all resources to show a green "Available" status. This takes 1-2 minutes.

What is the VPC wizard doing?

The "VPC and more" wizard creates all of these resources in one operation:

1 VPC with IP range 10.0.0.0/16 (65,536 available addresses).
2 public subnets (internet-facing) and 2 private subnets (isolated) across 2 Availability Zones.
1 internet gateway for public subnet internet access.
1 NAT gateway so private subnets can reach the internet for updates without being reachable from the internet.
Route tables that wire everything together.
An S3 gateway endpoint that keeps AWS traffic private.

Cost warning

The NAT gateway charges $0.045 per hour from this point forward. Complete the project and delete your resources promptly to minimize costs.

If you step away, come back and delete your VPC as soon as possible. The Before You Go section walks you through cleanup.

Why 1 NAT gateway instead of 2?

In production, AWS recommends one NAT gateway per Availability Zone for high availability. For this learning project, one NAT gateway teaches the same security pattern at half the cost.

VPC creation stuck or failed?

If you see an error during creation, check that you selected a region that supports all the required resources. US East (N. Virginia) us-east-1 is the safest choice.

If the NAT gateway stays in "Pending" state for more than 5 minutes, try refreshing the page.

Help me troubleshoot my VPC creation error.

Verify the created resources using the Resource map

Now that your VPC is created, you need to confirm that all the pieces are in place. The Resource map gives you a visual overview of your entire architecture.

After creation completes, click View VPC.
Select the Resource map tab to display a visualization of your resources.
Click Show details to reveal CIDR blocks and connection details.
Confirm you can see: 1 VPC, 2 public subnets (green), 2 private subnets (blue), 1 internet gateway, 1 NAT gateway, route tables, and the S3 gateway endpoint.
Note the CIDR blocks assigned to each subnet. You will need these values when writing security rules in later steps.

How to read the Resource map

Solid lines represent relationships between resources (like a subnet being associated with a route table). Dotted lines represent network traffic flowing to gateways and endpoints.

Public subnets appear in green and private subnets appear in blue. The Availability Zone is shown as a letter (e.g., 1a, 1b) beside each subnet.

Understand the routing architecture

Route tables are the traffic rules of your VPC. They tell AWS where to send network packets based on their destination address. Understanding your routes is critical for knowing how traffic flows between your subnets and the internet.

In the left navigation pane, choose Route tables.
Find the route table associated with a public subnet. Click on it to view its routes.
Confirm it has a route with destination 0.0.0.0/0 pointing to the internet gateway (igw-...).
Find the route table associated with a private subnet. Click on it to view its routes.
Confirm it has a route with destination 0.0.0.0/0 pointing to the NAT gateway (nat-...).
Confirm the private route table also has a route for the S3 prefix list pointing to the VPC endpoint (vpce-...).

Why do the routes matter?

The public subnet route sends all outbound traffic directly to the internet gateway. This means resources in public subnets can be reached from the internet (if their security group allows it).

The private subnet route sends outbound traffic through the NAT gateway instead. This means private resources can download updates from the internet, but nothing on the internet can initiate a connection back to them. The S3 endpoint route keeps traffic to Amazon S3 on the private AWS backbone, bypassing the NAT gateway entirely.

What is a CIDR block?

A CIDR block (like 10.0.0.0/16) defines a range of IP addresses. The number after the slash tells you how many addresses are available. A /16 gives you 65,536 addresses. Each subnet gets a smaller slice (like a /24 with 256 addresses).

Can't find your route tables?

Make sure you're filtering by the correct VPC. In the Route tables view, use the search bar or the VPC filter dropdown to show only route tables belonging to your secure-prod-vpc.

Help me find and read my VPC route tables.

Your secure network foundation is in place. You have public subnets that can reach the internet, private subnets that are shielded from inbound traffic, and an S3 endpoint keeping AWS traffic off the public internet. Next up, you'll add layered security groups to control exactly which traffic flows between tiers.

Configure Layered Security Groups

Your VPC now has the foundation in place: subnets, route tables, and gateways that control where traffic can flow.

But controlling where traffic flows is only half the story. You also need to control who is allowed to talk to each resource. In this step, you'll create security groups that act as firewalls around your resources, enforcing a strict trust path between tiers.

In this step, get ready to:

Create a load balancer security group that allows internet traffic in.
Create an application security group that only accepts traffic from the load balancer tier.
Verify the security group chain so the app tier is unreachable from the public internet.

Create a load balancer security group

In a production architecture, the load balancer is the only resource that should face the public internet directly. Its security group needs to allow HTTP and HTTPS traffic from anywhere.

In the VPC console navigation pane on the left, click Security groups.
Click Create security group.
For Security group name, enter secure-prod-lb-sg.
For Description, enter Allows inbound HTTP/HTTPS from the internet.
For VPC, remove the default VPC and select your secure-prod-vpc.

Now add the inbound rules that allow web traffic from the internet.

Under Inbound rules, click Add rule.
For the first rule, set Type to HTTP and Source to Anywhere-IPv4 (0.0.0.0/0).
Click Add rule again.
For the second rule, set Type to HTTPS and Source to Anywhere-IPv4 (0.0.0.0/0).
Leave the Outbound rules at the default (All traffic to 0.0.0.0/0).
Click Create security group.

What is a security group?

A security group acts as a virtual firewall for any resource it's attached to. It controls which traffic is allowed in (inbound rules) and out (outbound rules).

Security groups are stateful. If an inbound request is allowed in, the response is automatically allowed out. You don't need to create a matching outbound rule for return traffic.

You should see a success banner confirming your security group was created.

Don't see your VPC in the dropdown?

Make sure you're in the same region where you created your VPC. Check the region selector in the top-right corner of the console.

Help me find my secure-prod VPC when creating a security group.

Create an application server security group

The application tier should never be directly reachable from the internet. Instead, it should only accept traffic from the load balancer. You'll enforce this by referencing the LB security group as the source.

Click Create security group again.
For Security group name, enter secure-prod-app-sg.
For Description, enter Allows inbound only from the load balancer security group.
For VPC, remove the default VPC and select your secure-prod-vpc.

Now add the inbound rule that restricts access to only the load balancer tier.

Under Inbound rules, click Add rule.
Set Type to HTTP.
For Source, select Custom.
In the search field that appears, type secure-prod-lb-sg and select the secure-prod-lb-sg security group from the dropdown.
Leave the Outbound rules at the default (All traffic to 0.0.0.0/0).
Click Create security group.

Why reference a security group instead of an IP address?

By setting the source to a security group ID rather than an IP range, you're saying "only resources that belong to secure-prod-lb-sg can send traffic here." This is called security group chaining.

If the load balancer gets a new IP address, the rule still works because it's tied to the security group membership, not a specific IP. This is the production best practice for controlling cross-tier traffic.

You should see a success banner confirming the second security group was created.

Can't find secure-prod-lb-sg in the source dropdown?

Make sure you selected the correct VPC (secure-prod-vpc) for this new security group. Security groups from other VPCs won't appear in the source dropdown.

Help me reference the LB security group as a source for my app security group.

Verify the security group chain

Before moving on, confirm that the security group chaining pattern is correctly configured. This is the single most important check in this step.

In the left navigation pane, click Security groups.
Select secure-prod-app-sg from the list.
Click the Inbound rules tab in the details pane below.
Confirm the Source column shows a security group ID (starting with sg-), not an IP address.

What does this prove?

The source being a security group ID means only traffic originating from resources in the LB security group can reach the app tier. Direct internet access to the app tier is impossible, even if someone knows the IP address of an app server.

Your traffic is now locked into a strict path: internet to LB, LB to app. Next up, you'll add a second layer of defense at the subnet level using Network ACLs.

Add Defense-in-Depth with Custom Network ACLs

Your security groups are now enforcing a trusted traffic path between tiers. However, security groups operate at the instance level only. If a misconfiguration slips through, there is no second barrier protecting your private subnets.

In this step, you will add a second layer of network filtering using a custom Network ACL. Network ACLs operate at the subnet level and are stateless, meaning they evaluate every packet independently. This gives your private subnets two independent security controls working together.

In this step, get ready to:

Create a custom Network ACL for your private subnets.
Add explicit inbound and outbound allow rules.
Associate the NACL with both private subnets to activate defense-in-depth.

Create a custom Network ACL for the private subnets

A custom Network ACL starts by blocking ALL traffic in both directions. You will build it up by adding explicit allow rules for only the traffic your private subnets need.

In the VPC console navigation pane on the left, click Network ACLs.
Click Create network ACL.
For Name, enter secure-prod-private-nacl.
For VPC, select your secure-prod-vpc.
Click Create network ACL.

Why does a custom NACL block everything by default?

This follows the principle of least privilege. A custom Network ACL denies all inbound and outbound traffic until you explicitly add allow rules. This is the opposite of the default NACL that AWS creates with your VPC, which allows everything.

You are about to add only the specific rules your private subnets need. Anything not explicitly allowed remains blocked.

You should see your new secure-prod-private-nacl listed in the Network ACLs table.

Don't see your new NACL?

Make sure you selected the correct VPC (secure-prod-vpc) when creating it. If you accidentally chose the default VPC, delete the NACL and create it again in the correct VPC.

Help me find my new Network ACL in the VPC console.

Add inbound and outbound rules

Your NACL currently blocks everything. You need to add rules that allow HTTP and HTTPS traffic from within the VPC, plus return traffic from outbound internet connections via the NAT gateway.

Select secure-prod-private-nacl from the list.
Go to the Inbound rules tab.
Click Edit inbound rules.
Click Add new rule and enter the following:

Rule number: 100, Type: HTTP (80), Source: 10.0.0.0/16, Action: Allow.
Rule number: 110, Type: HTTPS (443), Source: 10.0.0.0/16, Action: Allow.
Rule number: 120, Type: Custom TCP, Port range: 32768-65535, Source: 0.0.0.0/0, Action: Allow.

Click Save changes.

What do these inbound rules do?

Rules 100 and 110 allow HTTP and HTTPS traffic that originates from within your VPC (the 10.0.0.0/16 range). This means only the load balancer and other VPC resources can send web traffic to the private subnets.

Rule 120 allows return traffic from the internet for outbound connections that your private instances make via the NAT gateway. These responses arrive on ephemeral ports (32768-65535). Without this rule, your private instances could send requests out but never receive the responses.

Now add the outbound rules so your private subnets can send traffic out.

Go to the Outbound rules tab.
Click Edit outbound rules.
Click Add new rule and enter the following:

Rule number: 100, Type: HTTP (80), Destination: 0.0.0.0/0, Action: Allow.
Rule number: 110, Type: HTTPS (443), Destination: 0.0.0.0/0, Action: Allow.
Rule number: 120, Type: Custom TCP, Port range: 32768-65535, Destination: 10.0.0.0/16, Action: Allow.

Click Save changes.

What do these outbound rules do?

Rules 100 and 110 allow your private instances to make outbound HTTP and HTTPS connections to the internet (via the NAT gateway). This is how they download updates and call external APIs.

Rule 120 allows response traffic back to resources within the VPC (10.0.0.0/16) on ephemeral ports. This completes the communication loop for inbound requests from the load balancer tier.

Why NACLs need explicit return-traffic rules

Network ACLs are stateless. They evaluate each packet in isolation with no memory of previous packets. This is different from security groups, which are stateful and automatically allow return traffic.

That is why you need both inbound and outbound rules for ephemeral ports. Without them, half of every conversation would be blocked.

Associate the NACL with your private subnets

Your NACL has rules but is not protecting anything yet. A Network ACL only takes effect once you associate it with specific subnets.

With secure-prod-private-nacl selected, go to the Subnet associations tab.
Click Edit subnet associations.
Select both private subnets: secure-prod-subnet-private1 and secure-prod-subnet-private2.
Click Save changes.

You should see both private subnets listed under the Subnet associations tab for your NACL.

What is defense-in-depth?

Your private subnets now have two independent layers of network filtering. Security groups filter at the instance level and are stateful. Network ACLs filter at the subnet level and are stateless.

If one layer is misconfigured, the other still blocks unauthorized traffic. AWS recommends this approach in the Well-Architected Framework Security Pillar: apply security at all layers.

Subnets not appearing in the association list?

Each subnet can only be associated with one NACL at a time. Your private subnets are currently using the default NACL. When you select them here, they will be reassigned from the default NACL to your custom one.

If you do not see any subnets listed, confirm your NACL is in the same VPC (secure-prod-vpc) as your subnets.

Help me associate my NACL with my private subnets.

Your private subnets are now protected by both security groups and a custom Network ACL. Next up, you will enable VPC Flow Logs so you can see every packet that hits these security controls.

Enable VPC Flow Logs for Traffic Monitoring

You've built a layered network with security groups controlling instance-level traffic and a custom Network ACL filtering at the subnet level. But how do you know if those rules are actually working?

In this step, you'll enable VPC Flow Logs to capture every network packet decision across your VPC. Flow Logs record whether traffic was accepted or rejected, giving you complete visibility into your security posture.

In this step, get ready to:

Create a VPC Flow Log that sends all traffic data to CloudWatch Logs.
Verify the Flow Log is active and the log group is receiving data.
Inspect flow log records to understand the ACCEPT and REJECT fields.

Create a VPC Flow Log to CloudWatch Logs

VPC Flow Logs can publish to either CloudWatch Logs or an S3 bucket. You'll use CloudWatch Logs because it lets you view and query records immediately without extra setup.

In the VPC console navigation pane on the left, click Your VPCs.
Select the checkbox next to your secure-prod-vpc.
Click Actions, then select Create flow log.

The Create flow log form appears with several configuration options.

For Filter, choose All. This captures both accepted and rejected traffic.
For Maximum aggregation interval, choose 1 minute.
For Destination, choose Send to CloudWatch Logs.
For Destination log group, enter /vpc/secure-prod-flow-logs.
For IAM role, choose Set Up Permissions. AWS will auto-create an IAM role that gives Flow Logs permission to publish to CloudWatch.
For Log record format, choose AWS default format.
Click Create flow log.

Why capture All traffic instead of just Reject?

ACCEPT records show you the normal traffic patterns in your VPC. REJECT records show traffic that was blocked by your security groups or NACLs.

In production, security teams analyze both. Unusual ACCEPT patterns can reveal compromised resources. REJECT spikes can indicate port scans or brute-force attempts.

What is Set Up Permissions doing?

VPC Flow Logs needs an IAM role with permission to write to CloudWatch Logs. Clicking Set Up Permissions opens a new tab where AWS creates this role for you automatically. Accept the defaults and close the tab to return to the flow log form.

Verify the Flow Log is active

After creation, you should see the flow log listed under your VPC with Status showing Active.
In the search bar at the top of the console, type CloudWatch and select CloudWatch from the results.
In the CloudWatch console navigation pane, expand Logs and click Log groups.
Find the /vpc/secure-prod-flow-logs log group in the list.

Don't see the log group yet?

The log group can take 2-5 minutes to appear after the first traffic flows through your VPC. Wait a few minutes and refresh the page.

If it still doesn't appear after 5 minutes, go back to the VPC console and confirm the flow log status is Active (not Error). An error status usually means the IAM role wasn't created properly.

Help me troubleshoot why my VPC Flow Log group isn't appearing in CloudWatch

Inspect a flow log record

Each flow log record captures a single network decision. Understanding the fields helps you identify what traffic is being allowed and what is being blocked.

Click on the /vpc/secure-prod-flow-logs log group.
Click into one of the log streams to view individual records.

Each record contains these fields in the AWS default format:

version, account-id, interface-id identify which network interface the record belongs to.
srcaddr, dstaddr, srcport, dstport show the source and destination of the connection.
protocol, packets, bytes describe the traffic volume.
action is the critical security field. It shows either ACCEPT or REJECT depending on whether your security groups or NACLs allowed the traffic.

What do REJECT entries tell you?

REJECT entries show traffic that was blocked by your security groups or Network ACLs. In a production environment, a sudden spike in REJECT entries from the same source IP could indicate a port scan or brute-force attack.

You can filter for these patterns in CloudWatch Logs Insights, which you'll use in the Secret Mission.

You now have complete traffic visibility across your entire VPC. Every connection attempt is recorded with its source, destination, and whether it was allowed or blocked. Next up, you'll put these monitoring capabilities to the test in the Secret Mission.

Secret mission

Block a Suspicious IP Range and Verify in Flow Logs

Your VPC has layered security, but what happens when you identify a known malicious IP range? In this mission, you'll add an explicit deny rule to your Network ACL and then query your Flow Logs to verify the block is in place.

Clean Up Your Resources

Decide whether to keep your resources running or delete them entirely. The NAT gateway in this project costs $0.045 per hour (roughly $1.08 per day), so deleting promptly is recommended unless you plan to continue experimenting.

Cost warning

Your NAT gateway charges $0.045/hour from the moment it was created. If you leave it running overnight, that is roughly $1.08/day. The Elastic IP is free while associated with the NAT gateway, but costs $0.005/hour if the NAT gateway is deleted and the EIP is not released.

Delete your resources as soon as you finish the project to avoid unnecessary charges.

Resources you used:

NAT gateway (costs $0.045/hour).
Elastic IP associated with the NAT gateway (free while associated, $0.005/hour if unassociated).
CloudWatch Log Group: /vpc/secure-prod-flow-logs (minimal ingestion cost).
VPC (secure-prod-vpc) with subnets, route tables, internet gateway, security groups, Network ACLs, and S3 gateway endpoint (all free).
VPC Flow Log and IAM role (no ongoing cost).

Keep everything running

No action needed. Choose this if you are still actively experimenting with your VPC architecture or want to add more security rules.

Your NAT gateway continues to charge $0.045/hour.
All other resources (VPC, subnets, security groups, NACLs, route tables, internet gateway, S3 endpoint) are free.
CloudWatch Logs will continue to ingest flow log data at minimal cost.

Pause - I'll come back to this later

Remove the cost-incurring resource (NAT gateway) while keeping the rest of your VPC intact for future reference.

In the VPC console navigation pane, choose NAT gateways.
Select your NAT gateway, choose Actions, then Delete NAT gateway.
Type delete to confirm, then choose Delete.
In the navigation pane, choose Elastic IPs.
Select the Elastic IP that was associated with your NAT gateway, choose Actions, then Release Elastic IP addresses.
Confirm by choosing Release.

Your VPC, subnets, security groups, NACLs, and flow logs remain intact at no cost. Private subnet instances would lose outbound internet access without the NAT gateway.

Delete - I don't want to use this again

Remove all project resources completely. This is the recommended option once you have finished the project.

First, delete the NAT gateway:

In the VPC console navigation pane, choose NAT gateways.
Select your NAT gateway, choose Actions, then Delete NAT gateway.
Type delete to confirm, then choose Delete.
Wait about 1-2 minutes for the NAT gateway status to change to Deleted.

Next, delete the VPC and all associated resources:

In the VPC console navigation pane, choose Your VPCs.
Select secure-prod-vpc, choose Actions, then Delete VPC.
AWS displays the resources it will delete for you (subnets, route tables, internet gateway, security groups, NACLs, and the S3 gateway endpoint). Review the list.
Type delete to confirm, then choose Delete.

Now release the Elastic IP:

In the VPC console navigation pane, choose Elastic IPs.
Select any Elastic IP that shows Not associated (this was your NAT gateway's EIP).
Choose Actions, then Release Elastic IP addresses.
Confirm by choosing Release.

Finally, delete the CloudWatch Log Group:

Navigate to the CloudWatch console by searching CloudWatch in the top search bar.
In the navigation pane, choose Logs, then Log groups.
Select the /vpc/secure-prod-flow-logs log group.
Choose Actions, then Delete.
Confirm the deletion.

What about the IAM role and VPC Flow Log?

The VPC Flow Log is automatically removed after the VPC is deleted. The auto-created IAM role remains in your account but incurs no cost. You can leave it or delete it via the IAM console if you prefer a tidy account.

Nice Work!

You just built a production-grade secure VPC on AWS from scratch. This is the exact network architecture pattern that cloud engineers and solutions architects deploy for real production workloads.

Here's what you accomplished:

Built a multi-AZ VPC with public and private subnet tiers, a NAT gateway for controlled outbound-only internet access, and a gateway VPC endpoint for S3 to keep AWS traffic off the public internet.
Implemented layered network security using security group chaining between tiers and a custom Network ACL as a subnet-level defense-in-depth layer.
Enabled VPC Flow Logs publishing to CloudWatch Logs for complete traffic visibility and security monitoring.
Secret Mission: Added an IP blocklist DENY rule to your Network ACL and verified monitoring with CloudWatch Logs Insights queries.

Ready to quiz yourself?