Design a Secure Multi-Tier VPC

Introduction

30 Second Summary

Every time you use an app, your data travels through a network that someone designed. When that network is poorly segmented, a single misconfiguration can expose an entire system to the internet.

In this project, you will design and deploy a secure multi-tier VPC architecture on AWS from scratch. You'll build it the way an AWS Solutions Architect would for a client engagement.

What You'll Build

You'll browse to a public IP address in your browser and see a live web page served from an EC2 instance running inside a network you architected from the ground up, with every security layer visible and explainable.

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

• A custom VPC with intentional CIDR planning, public and private subnets, and routing that exposes only your web tier to the internet.
• Layered defense-in-depth security using both security groups and network ACLs, so even if one layer is misconfigured, the other catches the mistake.
• A running web server deployed with user data automation and keyless access via IAM and Session Manager, proving your architecture works end to end.
• Secret Mission: Extend your architecture to span two Availability Zones and assess its resilience.

Are there any prerequisites?

You need an active A Cloud Guru (Pluralsight) subscription with access to the AWS cloud sandbox. The sandbox provides temporary AWS credentials at no extra cost, so you won't need your own AWS account.

Familiarity with basic AWS console navigation (finding services, clicking through settings) is helpful but not strictly required.

Before We Start

Before we dive into the AWS console, let's lock in what you're about to build and the security problem it solves.

You are designing a secure multi-tier VPC from scratch, the way an AWS Solutions Architect would for a client. The default VPC that AWS gives every account treats all resources as publicly accessible. Your architecture replaces that with intentional network segmentation and layered security controls.

Set Up and Plan Your Architecture

A Solutions Architect never opens the console first. Before touching any cloud resource, you define your requirements, constraints, and security posture in writing. Without a plan, VPC designs end up with overlapping CIDR blocks, single-AZ failures, and overly permissive security groups.

In this step, you will start your cloud sandbox, document your architecture decisions, and then examine the default VPC to see firsthand why it is a security liability.

In this step, get ready to:

• Start your A Cloud Guru sandbox and sign into the AWS console.
• Document your architecture requirements in a local text file.
• Identify the security problems in the default VPC.

Start your A Cloud Guru sandbox

The A Cloud Guru sandbox gives you a temporary AWS environment that auto-deletes after 4 hours. You will not be charged for anything you build inside it.

• Log in to your A Cloud Guru (Pluralsight) account at app.pluralsight.com.
• Click Hands-on in the navigation menu.
• Click Get Started in the Cloud Sandboxes tile.
• Click Open Sandbox next to AWS.
• Click Start Sandbox. Wait for the sandbox to generate credentials. You will see a URL, a username, and a password.

What do these sandbox credentials do?

The sandbox generates temporary AWS credentials tied to a real AWS account. They expire when the sandbox session ends (after 4 hours). Everything you build inside is deleted automatically.

• Copy the sandbox URL, username, and password.
• Open an incognito or private browser window. Press Cmd+Shift+N (macOS) or Ctrl+Shift+N (Windows) to open one.
• Paste the sandbox URL into the incognito window and sign in with the generated username and password.
• Once you are in the AWS Management Console, click the region dropdown in the top-right corner and select US East (N. Virginia) us-east-1.

You should see the AWS Management Console home page with N. Virginia displayed in the top-right corner.

Sandbox not starting or credentials not appearing?

The sandbox can take up to a minute to provision. If credentials do not appear, refresh the sandbox page. Make sure you are using an incognito window for the AWS sign-in so your personal AWS account does not interfere.

Help me troubleshoot my sandbox

Document your architecture requirements

A Solutions Architect defines requirements before building. This document becomes the blueprint you will follow for the rest of the project.

• Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
• Type TextEdit (macOS) or Notepad (Windows) and press Enter to open it.
• Create a new file and paste the following architecture notes:

VPC CIDR: 10.0.0.0/16 (65,536 addresses).
Public subnet: 10.0.1.0/24 (web tier, us-east-1a).
Private subnet: 10.0.2.0/24 (data tier, us-east-1a).
Region: us-east-1.
Security model: Defense-in-depth (security groups + NACLs).
Access model: No SSH keys — IAM + Session Manager.

What do these decisions mean?

• `10.0.0.0/16` gives you 65,536 IP addresses. That is the largest VPC CIDR block AWS allows, leaving room for future subnets.
• The /24 subnets each provide 256 addresses (251 usable, since AWS reserves 5). One faces the internet (web tier), the other is completely isolated (data tier).
• Defense-in-depth means two separate security layers: security groups at the instance level and network ACLs at the subnet level.
• No SSH keys means you use IAM roles and Session Manager for instance access. This eliminates key management and reduces attack surface.

• Save the file as architecture-notes.txt on your Desktop.

✔️ Awesome, I've got everything!

Great. Make sure you have saved your file. You will refer back to these values throughout the project.

ⓧ I'd like to double check the full code

Your architecture-notes.txt should contain exactly this:

VPC CIDR: 10.0.0.0/16 (65,536 addresses).
Public subnet: 10.0.1.0/24 (web tier, us-east-1a).
Private subnet: 10.0.2.0/24 (data tier, us-east-1a).
Region: us-east-1.
Security model: Defense-in-depth (security groups + NACLs).
Access model: No SSH keys — IAM + Session Manager.

Identify the default VPC security problem

Now that your requirements are documented, you need to see the problem you are solving. The default VPC that AWS creates in every account is designed for convenience, not security.

• In the AWS console, type VPC in the search bar at the top and click VPC to open the VPC dashboard.
• In the left navigation pane, click Your VPCs.
• You will see one VPC already listed. The Default VPC column shows Yes. Click on its VPC ID to open it.

Now investigate the three security issues with this default VPC.

• In the left pane, click Route tables. Find the route table associated with the default VPC. Click on it and look at the Routes tab. You will see a route with Destination 0.0.0.0/0 pointing to an internet gateway. This means every subnet in this VPC is public by default.
• In the left pane, click Internet gateways. You will see an internet gateway already attached to the default VPC. It was created automatically.
• In the left pane, click Security groups. Find the security group named default that belongs to this VPC. Click on it.
• Click the Inbound rules tab.

Before you look at the rules, predict: what do you think the default security group allows inbound? Something specific and restricted, or wide open?

You will see an inbound rule that allows All traffic from a source that is the security group's own ID. This means any resource assigned to this default security group can send any traffic to any other resource in the same group. Click the Outbound rules tab and you will see all traffic allowed to 0.0.0.0/0.

Why is the default VPC a problem?

The default VPC has an internet gateway already attached, all subnets route to it (making them public), and the default security group allows all internal traffic. Any resource launched here without explicit security configuration is potentially internet-accessible.

Your custom architecture solves this by creating a VPC where only the web tier has internet access, the data tier is completely isolated, and security groups enforce least-privilege per resource.

Don't see the default VPC?

Make sure your region is set to us-east-1 (check the top-right corner). ACG sandboxes are restricted to us-east-1 and us-west-2. The default VPC exists in every region, so if you see nothing, you may be in the wrong region.

Help me find the default VPC

You have documented your architecture plan and seen firsthand why the default VPC is insecure. Next up, you will build your custom VPC with proper network segmentation to eliminate these exact problems.

Build the Custom VPC with Network Segmentation

In Step 1, you identified the security problem with the default VPC: every subnet is public and the security group allows all inbound traffic from itself.

Now you will build the replacement. A Solutions Architect segments the network into layers based on data sensitivity and access requirements. Your web tier needs internet access so users can reach it. Your data tier must be completely isolated so nothing from the public internet can touch it. This separation is the foundation of the AWS Well-Architected Framework Security Pillar (SEC05-BP01).

In this step, get ready to:

• Create a custom VPC with intentional CIDR planning.
• Create a public subnet for the web tier.
• Create a private subnet for the data tier.

Create the custom VPC

The VPC is your isolated network boundary. Everything you build lives inside it, and nothing outside can reach in unless you explicitly allow it.

• In the AWS console, navigate to the VPC service using the search bar at the top.
• In the left sidebar, click Your VPCs.
• Click Create VPC.
• Select VPC only.
• Enter architect-vpc in the Name tag field.
• Enter 10.0.0.0/16 in the IPv4 CIDR block field.
• Leave Tenancy as Default.
• Click Create VPC.

You should see a green success banner confirming the VPC was created.

What is a CIDR block?

A CIDR block defines the range of IP addresses available inside your VPC. The /16 means the first 16 bits are fixed, leaving 65,536 possible addresses. This gives your architecture plenty of room to add more subnets later without running out of IP space.

Next, enable DNS hostnames so instances launched in this VPC receive public DNS names.

• Select architect-vpc in the VPC list.
• Click Actions, then click Edit VPC settings.
• Check the box next to Enable DNS hostnames.
• Click Save changes.

Confirm the DNS hostnames field in the VPC details now shows Enabled.

Why enable DNS hostnames?

Without DNS hostnames, instances only get private IP addresses as identifiers. Enabling this setting means your web server will receive a public DNS name that resolves to its public IP, which is essential for serving web traffic.

Don't see architect-vpc in the list?

Make sure you are in the us-east-1 region. Check the region selector in the top-right corner of the console. The VPC only appears in the region where you created it.

help me find my VPC in the AWS console

Create the public subnet

A subnet is a subdivision of your VPC's IP range. The public subnet will host your web server, the only resource that needs to face the internet.

• In the left sidebar, click Subnets.
• Click Create subnet.
• In the VPC ID dropdown, select architect-vpc.
• Enter public-web-subnet in the Subnet name field.
• Select us-east-1a for the Availability Zone.
• Enter 10.0.1.0/24 in the IPv4 subnet CIDR block field.
• Click Create subnet.

You should see a success message and public-web-subnet now appears in the subnet list.

Now enable auto-assign public IPv4 so any instance launched in this subnet automatically gets a public IP address.

• Select public-web-subnet in the subnet list.
• Click Actions, then click Edit subnet settings.
• Check the box for Enable auto-assign public IPv4 address.
• Click Save.

Confirm the Auto-assign public IPv4 address field in the subnet details now shows Yes.

Why auto-assign public IPv4?

A public IP address is what makes a resource reachable from the internet. By enabling auto-assign on this subnet, every instance you launch here automatically gets a public IP without extra configuration. Your private subnet will NOT have this enabled, keeping those resources invisible to the outside world.

Create the private subnet

The private subnet isolates your data tier. Resources here have no direct internet access, which is exactly what you want for databases and application backends.

• In the Subnets page, click Create subnet.
• In the VPC ID dropdown, select architect-vpc.
• Enter private-data-subnet in the Subnet name field.
• Select us-east-1a for the Availability Zone.
• Enter 10.0.2.0/24 in the IPv4 subnet CIDR block field.
• Click Create subnet.

Do NOT enable auto-assign public IPv4 for this subnet. The whole point of the private tier is that nothing here is directly reachable from the internet.

What makes a subnet public or private?

A subnet is not inherently public or private based on its name alone. A subnet becomes public when it is associated with a route table that has a route to an internet gateway. Right now, neither of your subnets has internet access yet. You will make public-web-subnet truly public in the next step by creating an internet gateway and routing traffic through it.

Before you move on, take a moment to predict what you expect to see in the Subnets list. How many subnets are in architect-vpc, and which one has auto-assign public IPv4 enabled?

• In the Subnets page, filter by VPC by selecting architect-vpc in the VPC filter dropdown.

You should see exactly two subnets: public-web-subnet (10.0.1.0/24) and private-data-subnet (10.0.2.0/24). The public subnet shows Yes under Auto-assign public IPv4 address. The private subnet shows No.

Only seeing one subnet or none?

Check that the VPC filter at the top of the Subnets page is set to architect-vpc and not the default VPC. If you see subnets from the default VPC, clear the filter and re-select.

help me find my subnets in the VPC console

Your network is segmented. You have a clear boundary between the web tier and the data tier. Next up, you will give the public subnet actual internet access by creating an internet gateway and a route table.

Configure Internet Access and Routing

Your VPC has two subnets, but right now both are equally isolated. Without an internet gateway and a route table pointing to it, instances in your "public" subnet have no path to the internet.

A Solutions Architect makes a subnet public by explicitly granting internet access through routing, not by default. In this step, you will create that explicit path so only your web tier can reach the outside world.

In this step, get ready to:

• Create and attach an internet gateway to your VPC.
• Create a public route table with an internet route.
• Associate only the public subnet with that route table, keeping the private subnet isolated.

Create and attach an internet gateway

An internet gateway is the bridge between your VPC and the public internet. Without one attached, no resource inside the VPC can send or receive traffic from outside.

• In the left-hand navigation of the VPC console, click Internet gateways.
• Click Create internet gateway.
• In the Name tag field, enter architect-igw.
• Click Create internet gateway.

The gateway is created but not yet attached to any VPC. You need to connect it to architect-vpc.

• With architect-igw selected, click Actions and choose Attach to VPC.
• In the Available VPCs dropdown, select architect-vpc.
• Click Attach internet gateway.

You should see the State column change to Attached next to architect-igw.

What is an internet gateway?

An internet gateway is a horizontally scaled, redundant VPC component that allows communication between your VPC and the internet. It performs network address translation for instances that have public IPv4 addresses.

A VPC can have only one internet gateway attached at a time. The default VPC comes with one pre-attached, which is why everything in it is public by default.

Can't find architect-vpc in the dropdown?

Make sure your region is set to us-east-1 in the top-right corner of the console. The VPC you created in Step 2 only exists in that region.

If the gateway already shows Attached status, it is already connected and you can move on.

Help me troubleshoot my internet gateway attachment.

Create a public route table and add the internet route

The internet gateway is attached, but no subnet knows about it yet. A route table tells traffic where to go. You need a custom route table that points 0.0.0.0/0 (all internet-bound traffic) at your new gateway.

• In the left-hand navigation of the VPC console, click Route tables.
• Click Create route table.
• In the Name field, enter public-rt.
• In the VPC dropdown, select architect-vpc.
• Click Create route table.

The route table is created with only a local route (10.0.0.0/16) by default. Now add the internet route.

• With public-rt selected, click the Routes tab.
• Click Edit routes.
• Click Add route.
• In the Destination field, enter 0.0.0.0/0.
• In the Target dropdown, select Internet Gateway, then select architect-igw.
• Click Save changes.

The Routes tab should now show two routes: the local route (10.0.0.0/16) and your new route (0.0.0.0/0 pointing to architect-igw).

Why a separate route table instead of the main one?

Every VPC has a main route table. Subnets that are not explicitly associated with a custom route table use the main one automatically. If you added the internet route to the main route table, your private subnet would inherit it and become public.

By creating a separate route table and associating only the public subnet with it, you ensure the private subnet stays isolated. This is how network segmentation works at the routing layer.

Associate the public subnet with the public route table

The route table exists with the correct routes, but no subnet is using it yet. You need to explicitly associate public-web-subnet with public-rt.

• With public-rt still selected, click the Subnet associations tab.
• Click Edit subnet associations.
• Check the box next to public-web-subnet.
• Do NOT select private-data-subnet. It must remain on the main route table with no internet access.
• Click Save associations.

What makes a subnet public or private?

A public subnet is simply a subnet associated with a route table that has a route to an internet gateway. A private subnet is one associated with a route table that does not have such a route.

There is no "public" checkbox in AWS. The distinction is entirely about routing. Your private-data-subnet stays on the main route table, which has no route to the internet gateway. That is what keeps it isolated.

Verify your routing configuration

Before you move on, predict: if you look at the main route table for architect-vpc, will it have a route to the internet gateway? Why or why not?

• Navigate to Route tables in the VPC console.
• Select public-rt and confirm it has a route 0.0.0.0/0 targeting architect-igw in the Routes tab.
• Click the Subnet associations tab and confirm public-web-subnet is listed under Explicit subnet associations.
• Now select the main route table for architect-vpc (it will have "Yes" in the Main column).
• Check its Routes tab and confirm it has NO route to the internet gateway.
• Check its Subnet associations tab and confirm private-data-subnet is implicitly associated with it.

The main route table only has the local route (10.0.0.0/16). No internet gateway route exists there. This is exactly the separation you designed for.

Public-rt doesn't show the internet route?

Make sure you clicked Save changes after adding the route. If you navigated away before saving, the route was lost. Select public-rt, click Edit routes, and re-add the 0.0.0.0/0 route targeting architect-igw.

Help me fix my route table configuration.

Your network routing is in place. The public subnet now has a clear path to the internet, while the private subnet stays completely walled off. Next up, you will layer security controls on top of this routing to control exactly which traffic is allowed through.

Implement Defense-in-Depth Security Controls

Your VPC now has clearly separated tiers with intentional routing. The public subnet can reach the internet and the private subnet cannot. But routing alone does not control what traffic reaches your instances. Without security controls, any traffic that enters the public subnet can hit any port on any instance inside it.

A single security layer is a single point of failure. The AWS Well-Architected Framework Security Pillar (SEC05-BP02) recommends layered controls: security groups for instance-level stateful filtering AND network ACLs for subnet-level stateless filtering. You will create both, so even if one layer is misconfigured, the other catches the mistake.

In this step, get ready to:

• Create a security group restricting inbound traffic to HTTP only.
• Create a custom network ACL with explicit allow rules for web traffic.
• Associate the NACL with your public subnet to replace the default allow-all rules.

Create the web tier security group

Security groups act as virtual firewalls at the instance level. They are stateful, meaning if you allow inbound traffic on a port, the response traffic is automatically allowed out. You only need to define the inbound rule.

• In the left navigation pane of the VPC console, click Security Groups.
• Click Create security group.
• Set Security group name to web-sg.
• Set Description to Allow HTTP inbound only.
• For VPC, remove the default VPC from the dropdown and select architect-vpc.
• In the Inbound rules section, click Add rule.
• Set Type to HTTP (this auto-fills Port range to 80).
• Set Source to Anywhere-IPv4 (0.0.0.0/0).

Leave the Outbound rules section at its default, which allows all outbound traffic.

• Click Create security group.

You should see a green success banner and your new web-sg security group listed with one inbound rule allowing HTTP on port 80.

Why only HTTP and not SSH?

A Solutions Architect eliminates SSH access entirely by using IAM roles and Session Manager for instance management. This removes the need for SSH key pairs and closes port 22, reducing attack surface.

Your security group enforces least-privilege access. Only the traffic your web server actually needs (HTTP on port 80) is allowed in.

Don't see architect-vpc in the VPC dropdown?

The dropdown defaults to your account's default VPC. Click the X next to the pre-selected VPC to clear it, then search for architect-vpc by name. If it does not appear, confirm you are in the us-east-1 region (check the top-right corner of the console).

Help me find my VPC when creating a security group

Create a custom network ACL for the public subnet

Network ACLs add a second layer of filtering at the subnet boundary. Unlike security groups, NACLs are stateless. This means you must explicitly allow return traffic in both directions.

• In the left navigation pane, click Network ACLs.
• Click Create network ACL.
• Set Name to public-nacl.
• For VPC, select architect-vpc.
• Click Create network ACL.

Your new NACL appears in the list. By default, a custom NACL denies all inbound and outbound traffic. You need to add explicit allow rules.

• Select public-nacl from the list by clicking its checkbox.
• Click the Inbound rules tab in the lower panel.
• Click Edit inbound rules.
• Click Add new rule. Set Rule number to 100, Type to HTTP (80), Source to 0.0.0.0/0, and Allow/Deny to Allow.
• Click Add new rule again. Set Rule number to 200, Type to Custom TCP, Port range to 1024-65535, Source to 0.0.0.0/0, and Allow/Deny to Allow.
• Click Save changes.

You should see two numbered rules (100 and 200) plus the default deny-all (*) rule in the inbound rules list.

Why allow ports 1024-65535?

When a client sends an HTTP request to your server on port 80, the server sends its response back to the client on a random high-numbered port called an ephemeral port. Linux instances use ports 1024-65535 for this purpose.

Because NACLs are stateless, the response traffic is not automatically allowed. Without this rule, your web server could receive requests but its responses would be blocked at the subnet boundary.

Now add the outbound rules to mirror the inbound configuration.

• Click the Outbound rules tab.
• Click Edit outbound rules.
• Click Add new rule. Set Rule number to 100, Type to HTTP (80), Destination to 0.0.0.0/0, and Allow/Deny to Allow.
• Click Add new rule again. Set Rule number to 200, Type to Custom TCP, Port range to 1024-65535, Destination to 0.0.0.0/0, and Allow/Deny to Allow.
• Click Save changes.

You should see two numbered rules (100 and 200) in the outbound rules tab, matching your inbound structure.

Why do outbound rules also need HTTP and ephemeral ports?

The outbound HTTP rule (port 80) allows your web server to fetch data from external services. The outbound ephemeral port rule (1024-65535) allows response packets from your server to reach clients who sent inbound HTTP requests.

Together, the inbound and outbound rules form a complete picture: inbound HTTP lets requests in, outbound ephemeral ports let responses out, and vice versa.

Associate the NACL with the public subnet

Your NACL exists but is not yet protecting anything. A NACL only takes effect when it is associated with a subnet, replacing that subnet's previous NACL association.

• With public-nacl still selected, click the Subnet associations tab.
• Click Edit subnet associations.
• Select the checkbox next to public-web-subnet.
• Click Save changes.

This replaces the default allow-all NACL with your restrictive public-nacl on the public subnet.

Before you verify, think about this: if you navigate to Security Groups and Network ACLs right now, what rules should you see on each resource?

• Navigate to Security Groups in the left sidebar and select web-sg. Confirm it shows one inbound rule: HTTP (port 80) from 0.0.0.0/0.
• Navigate to Network ACLs and select public-nacl. Confirm the Inbound rules tab shows Rule 100 (HTTP Allow) and Rule 200 (Custom TCP 1024-65535 Allow).
• Confirm the Outbound rules tab shows Rule 100 (HTTP Allow) and Rule 200 (Custom TCP 1024-65535 Allow).
• Confirm the Subnet associations tab shows public-web-subnet is associated.

What is defense-in-depth?

You now have two independent security layers protecting your web tier. The security group filters at the instance level (stateful). The NACL filters at the subnet boundary (stateless). If someone accidentally opens a port on the security group, the NACL still blocks it.

This layered approach is exactly what the AWS Well-Architected Framework calls defense-in-depth (SEC05-BP02): control traffic flow within network layers using multiple mechanisms.

NACL not showing in subnet associations?

Make sure you selected public-nacl (not the default NACL) before clicking the Subnet associations tab. The default NACL and your custom NACL are separate entries in the list.

Also confirm you checked the box next to public-web-subnet specifically (not private-data-subnet) and clicked Save changes.

Help me associate my NACL with the correct subnet

Your architecture now has two layers of security filtering protecting the public subnet. Next up, you will deploy a web server into this secured network and prove the architecture works end-to-end.

Launch the Web Server with IAM Role and User Data

Your network architecture is fully secured with layered controls at the instance level and the subnet boundary. Security groups filter traffic per instance, NACLs filter at the subnet edge, and routing ensures only your public tier can reach the internet.

Now it is time to put something in that network. In this step, you deploy a web server into your public subnet using automated configuration via a user data script. You also create an IAM role that grants management access through Session Manager, eliminating SSH key management entirely.

In this step, get ready to:

• Create an IAM role for Session Manager access.
• Launch an EC2 instance with automated configuration via user data.
• Verify the web server is accessible through your security architecture.

Create an IAM role for the EC2 instance

Traditional server access uses SSH keys. Keys need to be generated, distributed, rotated, and revoked. A Solutions Architect avoids this overhead entirely by granting management access through an IAM role and AWS Systems Manager.

• In the AWS console, use the search bar at the top to search for IAM and select it.
• In the left navigation pane, click **Roles**.
• Click **Create role**.
• For **Trusted entity type**, select **AWS service**.
• Under **Use case**, select **EC2**.
• Click **Next**.

• On the **Add permissions** page, search for AmazonSSMManagedInstanceCore in the search field.
• Select the checkbox next to AmazonSSMManagedInstanceCore.
• Click **Next**.
• For **Role name**, enter web-server-role.
• Click **Create role**.

You should be returned to the Roles page with a success banner confirming the role was created.

Why Session Manager instead of SSH keys?

SSH keys are a persistent credential. If a key is leaked or not rotated, anyone with it can access your server indefinitely.

Session Manager uses temporary, automatically rotated credentials issued through the IAM role. There is no key file to lose, no port 22 to open, and every session is logged in CloudTrail.

Don't see AmazonSSMManagedInstanceCore in the search results?

Make sure you are typing the full name AmazonSSMManagedInstanceCore in the filter field on the Add permissions page. The policy is an AWS managed policy, so it should appear for any account.

If you still cannot find it, help me find the AmazonSSMManagedInstanceCore policy in the IAM console.

Launch the EC2 instance with user data

With the IAM role ready, you can now launch your EC2 instance into the secured public subnet. The user data script automates Apache installation so the server is serving traffic the moment it boots.

• Navigate to **EC2** using the search bar at the top of the console.
• Click **Launch instance**.
• Under **Name and tags**, enter architect-web-server for **Name**.
• Under **Application and OS Images (Amazon Machine Image)**, choose **Quick Start**, then select **Amazon Linux**.
• Select the Amazon Linux 2023 AMI that is marked **Free tier eligible**.
• Under **Instance type**, select t2.micro.
• Under **Key pair (login)**, choose **Proceed without a key pair (Not recommended)**.

Why no key pair?

The console warns that proceeding without a key pair is "not recommended" because it prevents SSH access. That is exactly the point. Your architecture uses Session Manager through the IAM role you just created, so SSH is unnecessary and leaving port 22 closed reduces your attack surface.

• Under **Network settings**, click **Edit**.
• For **VPC**, select architect-vpc.
• For **Subnet**, select public-web-subnet.
• For **Auto-assign public IP**, select **Enable**.
• Under **Firewall (security groups)**, choose **Select existing security group**.
• Select web-sg from the dropdown.

• Scroll down and expand the **Advanced details** section.
• For **IAM instance profile**, select web-server-role from the dropdown.
• Scroll down to the **User data** field at the bottom of Advanced details.
• Paste the following script into the User data field:

#!/bin/bash
dnf install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<html><h1>Architect Project - Secure Web Server</h1><p>This instance is running in a custom VPC with defense-in-depth security.</p></html>" > /var/www/html/index.html

What does this user data script do?

• `dnf install -y httpd` installs the Apache web server on Amazon Linux 2023.
• `systemctl start httpd` starts the web server immediately.
• `systemctl enable httpd` ensures Apache restarts automatically if the instance reboots.
• The `echo` command writes a custom HTML page to the Apache document root at /var/www/html/index.html.

User data scripts run as the root user at first boot, so no sudo is needed. This eliminates any manual SSH session to configure the server.

• Click **Launch instance**.

You should see a success banner with the instance ID. Click the instance ID link to go to the Instances page.

Instance immediately goes to terminated?

Check that you selected architect-vpc (not the default VPC) and public-web-subnet in Network settings. Also confirm the instance type is t2.micro since the sandbox restricts available types.

If the issue persists, help me troubleshoot my EC2 instance terminating immediately.

Test the web server

The user data script takes 2-3 minutes to complete after the instance reaches the running state. While you wait, the script is installing Apache and writing your HTML page.

• On the Instances page, wait until the **Instance state** column shows **Running** and the **Status check** column shows **2/2 checks passed**.
• Select the checkbox next to architect-web-server.
• In the details panel below, find the **Public IPv4 address** field and copy the IP address.

Before you paste this into your browser, what do you expect to see? Think about what the user data script wrote to the Apache document root.

• Open a new browser tab and navigate to http:// followed by the Public IPv4 address you just copied.

You should see the heading "Architect Project - Secure Web Server" and the message "This instance is running in a custom VPC with defense-in-depth security."

What is this proving?

This single page load proves your entire architecture is working together. The HTTP request traveled from the internet through the internet gateway, was permitted by the route table, allowed by the NACL at the subnet boundary, and then allowed by the security group at the instance level.

If any single layer was misconfigured, the page would not load. That is defense-in-depth in action.

Page not loading or timing out?

• Make sure you are using http:// and not https:// since the security group only allows port 80.
• Confirm that the instance has a Public IPv4 address in the Details tab. If it does not, Auto-assign public IP was not enabled on public-web-subnet.
• Verify that web-sg allows HTTP (port 80) inbound from 0.0.0.0/0 by checking the Security tab of the instance.
• Wait a full 3 minutes after the instance enters Running state. The user data script needs time to install and start Apache.

If you have checked all of the above, help me debug why my EC2 web server is not responding on port 80.

Secret mission

Multi-AZ High Availability

Your architecture currently runs in a single Availability Zone. If us-east-1a goes down, everything fails. Extend your VPC to span two Availability Zones, launch a second web server, and document the resilience improvements like an AWS Solutions Architect would.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely within an A Cloud Guru sandbox, so there are no ongoing costs. The sandbox auto-deletes all AWS resources after 4 hours.

Resources you used:

• VPC: architect-vpc (10.0.0.0/16) with DNS hostnames enabled.
• Subnets: public-web-subnet, private-data-subnet, public-web-subnet-b, private-data-subnet-b.
• Internet gateway: architect-igw attached to the VPC.
• Route table: public-rt with internet route.
• Security group: web-sg allowing HTTP inbound.
• Network ACL: public-nacl with HTTP and ephemeral port rules.
• IAM role: web-server-role with Session Manager policy.
• EC2 instances: architect-web-server and architect-web-server-b running Apache.
• Local file: your architecture notes (text file on your computer).

Keep everything running

No action needed. Choose this if you are still actively exploring your VPC architecture in the console.

• Your A Cloud Guru sandbox expires after 4 hours and automatically deletes all AWS resources you created.
• Your local architecture notes file stays on your computer for reference.
• If you want to rebuild this architecture later, your notes have all the CIDR blocks, security group rules, and NACL rules you need.

Pause - I'll come back to this later

Save your configuration details before the sandbox expires so you can rebuild quickly in a future session.

• Take screenshots of your VPC configuration, route tables, security group rules, and NACL rules from the AWS console.
• Confirm your local architecture notes file contains all CIDR blocks, subnet names, AZ assignments, and security rules.
• For Project 2 (EC2 + RDS), you will rebuild this VPC in the first 10 minutes using the VPC and more wizard, which creates VPC, subnets, IGW, and route tables in one click. Your notes will guide the configuration.
• The sandbox will auto-delete all AWS resources when it expires. No manual cleanup is needed.

Delete - I don't want to use this again

Remove all project resources. The sandbox handles AWS resource deletion automatically, but you can clean up your local file.

• All AWS resources (VPC, subnets, internet gateway, route tables, security group, NACL, IAM role, EC2 instances) are automatically deleted when your A Cloud Guru sandbox session expires after 4 hours. No manual action is required.
• If you want to end the sandbox early, return to A Cloud Guru and click End Sandbox on the sandbox page.
• Delete your local architecture notes file if you no longer need it.

Nice Work!

Nice Work!

You just designed and deployed a production-grade multi-tier VPC architecture from scratch, the way an AWS Solutions Architect would for a real client engagement.

You've learned how to:

• Built a multi-tier VPC with intentional CIDR planning, public and private subnets, and explicit routing that enforces network segmentation.
• Implemented defense-in-depth security using both security groups (stateful, instance-level) and network ACLs (stateless, subnet-level) so no single misconfiguration exposes your resources.
• Deployed a web server with user data automation and keyless access via IAM roles and Session Manager, eliminating SSH key management entirely.
• Extended the architecture to span multiple Availability Zones for high availability and documented next steps for traffic distribution (Secret Mission).

Ready to quiz yourself?