Build a Secure Multi-Tier Architecture

Deploy a VPC with public and private subnets, EC2, and RDS on AWS.

Introduction

30 Second Summary

Every time you log into a banking app or shop online, there's a database storing your sensitive information. That database is never directly reachable from the internet.

In this project, you will build a secure multi-tier architecture on AWS from scratch. You'll create a custom network with public and private layers, deploy a web server and database, and configure security rules so that only the web server can talk to the database.

What You'll Build

A production-style network architecture on AWS with a web server in a public subnet and a MySQL database isolated in a private subnet.

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

  • A custom VPC with public and private subnets spanning two Availability Zones.
  • A running EC2 web server securely connected to an RDS MySQL database.
  • Manually configured security groups enforcing the principle of least privilege, proving the database is unreachable from the internet.
  • Secret Mission: Add a Network ACL for defense in depth and verify it blocks unauthorized traffic.

Are there any prerequisites?

You need an AWS account with Free Tier credits. This project is designed for accounts created after July 15, 2025.

All work is done in the AWS Management Console and your macOS Terminal. No additional tools or installations are required.

Create Your Custom VPC

Every AWS account comes with a default VPC in each region. The default VPC is convenient for quick tests, but production architectures need custom VPCs where you control the network boundaries, IP ranges, and access rules.

In this step, you will create a custom VPC from scratch using the AWS Console wizard. The wizard builds your VPC, subnets, route tables, and an Internet Gateway in a single action.

In this step, get ready to:
  • Create a custom VPC with public and private subnets across two Availability Zones.
  • Verify that four subnets were created in the correct Availability Zones.
  • Confirm that route tables direct public traffic to the Internet Gateway and keep private subnets isolated.
Create the VPC using the wizard

The VPC and more option in the Create VPC wizard builds your entire network foundation in one step. It creates the VPC, subnets, route tables, and Internet Gateway together.

  • Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
  • On the VPC dashboard, choose Create VPC.
  • For Resources to create, choose VPC and more.
  • Under Name tag auto-generation, enter secure-arch.
  • For IPv4 CIDR block, enter 10.0.0.0/16.
  • Leave IPv6 CIDR block set to No IPv6 CIDR block.
  • Set Tenancy to Default.
  • Set Number of Availability Zones (AZs) to 2.
  • Set Number of public subnets to 2.
  • Set Number of private subnets to 2.
  • Set NAT gateways to None.
  • Set VPC endpoints to None.
  • Keep the default DNS options unchanged.
  • Choose Create VPC.

AWS displays a success page showing all the resources it created. Wait for all items to show a green checkmark before continuing.

What did this wizard create?

The VPC and more wizard created seven resources in one action: a VPC with the CIDR block 10.0.0.0/16, four subnets (two public, two private), an Internet Gateway attached to the VPC, and route tables that wire everything together.

The secure-arch name tag prefix means all resources follow the naming pattern secure-arch-vpc, secure-arch-subnet-public1, and so on. This keeps your resources easy to identify.

Why no NAT Gateway?

NAT Gateways let private subnets reach the internet for outbound traffic. They cost approximately $0.045 per hour plus data processing charges.

Your private subnet only hosts an RDS database, which does not need internet access. Skipping the NAT Gateway keeps this project at $0 cost.

Not seeing the Create VPC button?

Make sure you are on the VPC dashboard, not inside an existing VPC. If you see a list of VPCs, click VPC Dashboard in the left navigation pane first.

Help me find the Create VPC button

Verify subnets across two Availability Zones

Now confirm the wizard created all four subnets in the correct Availability Zones.

  • In the VPC console navigation pane on the left, choose Subnets.
  • Confirm you see four subnets: secure-arch-subnet-public1, secure-arch-subnet-public2, secure-arch-subnet-private1, and secure-arch-subnet-private2.
  • Check the Availability Zone column. The public1/private1 pair should be in one AZ, and public2/private2 in a different AZ.

Why two Availability Zones?

Availability Zones are physically separate data centers within an AWS Region. Spreading subnets across two AZs means your architecture survives the failure of an entire data center.

RDS also requires a DB subnet group with subnets in at least two AZs. You are setting that up now so the database step goes smoothly.

Only seeing subnets from a different VPC?

Your account's default VPC also has subnets. Use the search bar at the top of the Subnets page and filter by VPC ID. Choose the VPC named secure-arch-vpc to show only your new subnets.

Help me filter for my secure-arch subnets

Verify routing for public and private subnets

The critical difference between a public and private subnet is the route table. A public subnet has a route sending 0.0.0.0/0 (all internet-bound traffic) to the Internet Gateway. A private subnet has no such route.

  • In the navigation pane, choose Route tables.
  • Find a route table associated with a public subnet (look for one with secure-arch in the name that is linked to secure-arch-subnet-public1 or secure-arch-subnet-public2).
  • Click the route table name, then choose the Routes tab.
  • Confirm it has a route with Destination 0.0.0.0/0 and Target pointing to an Internet Gateway (igw- prefix).
  • Go back to Route tables and find the route table associated with a private subnet.
  • Click the route table name and choose the Routes tab.
  • Confirm it only has the local route 10.0.0.0/16 with target local. There should be no route to an Internet Gateway.

What does this routing prove?

The public route table sends all internet traffic (0.0.0.0/0) to the Internet Gateway. Any resource in a public subnet can be reached from the internet if its security group allows it.

The private route table only knows about 10.0.0.0/16 (your VPC's internal range). Resources in private subnets cannot send or receive traffic from the internet. This is exactly where you will place your database.

Can't tell which route table belongs to which subnet?

Click a route table, then choose the Subnet associations tab. This shows which subnets are explicitly associated with that route table.

Help me identify my public and private route tables

Your network foundation is ready. Next up, you will create security groups that control exactly which traffic is allowed between your resources.

Configure Security Groups

Your custom VPC is live with public and private subnets spanning two Availability Zones. But right now, nothing controls who can send traffic to your future web server or database.

Security groups act as virtual firewalls for individual AWS resources. In this step, you'll create two security groups that enforce the principle of least privilege: one for your web server (allowing SSH and HTTP in) and one for your database (allowing only the web server to connect on port 3306).

In this step, get ready to:
  • Create a security group for the web server that allows SSH and HTTP access.
  • Create a security group for the database that only accepts connections from the web server.
  • Understand how security group references enforce least-privilege access.
Create the web server security group

The web server needs to accept two types of inbound traffic: SSH connections from your laptop (so you can manage it) and HTTP requests from the public internet (so users can visit it).

  • In the VPC console, choose Security Groups in the left navigation pane under the Security section.
  • Choose Create security group.
  • In the Security group name field, enter web-server-sg.
  • In the Description field, enter Allow SSH and HTTP to web server.
  • In the VPC dropdown, remove the default VPC and select secure-arch-vpc.

Now add the inbound rules that define what traffic is allowed in.

  • Under Inbound rules, choose Add rule.
  • Set Type to SSH.
  • Set Source to My IP.
  • Choose Add rule again to add a second rule.
  • Set Type to HTTP.
  • Set Source to Anywhere-IPv4 (0.0.0.0/0).
  • Choose Create security group.

What does My IP do?

When you select My IP as the source, AWS automatically detects your current public IP address and restricts SSH access to only that address. This means only your laptop can SSH into the web server.

If your IP address changes (for example, you switch Wi-Fi networks), you'll need to update this rule later.

Don't see secure-arch-vpc in the VPC dropdown?

Make sure you're working in the same AWS Region where you created your VPC in Step 1. Check the Region selector in the top-right corner of the console.

help me find my VPC in the security group settings

Create the database security group

The database should only accept connections from the web server. Instead of using an IP address as the source, you'll reference the web server's security group directly. This is a key AWS pattern tested on the SAA-C03 exam.

  • In the left navigation pane, choose Security Groups again.
  • Choose Create security group.
  • In the Security group name field, enter database-sg.
  • In the Description field, enter Allow MySQL from web server only.
  • In the VPC dropdown, remove the default VPC and select secure-arch-vpc.
  • Under Inbound rules, choose Add rule.
  • Set Type to MySQL/Aurora (this automatically sets port 3306).
  • In the Source field, start typing web-server-sg and select the web-server-sg security group from the dropdown.
  • Choose Create security group.

Why reference a security group instead of an IP address?

When you use a security group as the source, AWS allows traffic from any instance that has that security group attached. This means if you later replace the web server (and its IP changes), the rule still works because it's tied to the group membership, not a specific address.

This pattern is heavily tested on the SAA-C03 exam. It's the foundation of how AWS recommends connecting application tiers.

Can't find web-server-sg in the Source field?

Make sure you selected secure-arch-vpc as the VPC first. The Source dropdown only shows security groups that belong to the same VPC. If the VPC field still shows the default VPC, the web-server-sg option will not appear.

help me reference web-server-sg in my database security group

Understand what you just built

You now have two security groups working together to enforce a strict access model.

How do these security groups protect the database?

The database-sg only allows inbound traffic on port 3306 from instances that have web-server-sg attached. This means ONLY your web server can talk to the database.

Nothing on the internet can reach the database directly. No other instance in your VPC can reach it either, unless you explicitly attach web-server-sg to that instance. This is the principle of least privilege in action.

Both security groups also allow all outbound traffic by default. This means your web server can respond to HTTP requests, and your database can send query results back to the web server.

Your firewall rules are locked down. Next up, you'll launch an EC2 web server in the public subnet and attach the web-server-sg security group to it.

Launch Your EC2 Web Server

Your network is built and your security groups are locked down. Now you need something to actually run inside that network.

EC2 (Elastic Compute Cloud) gives you a virtual server in the cloud. You will launch one in the public subnet so it can receive traffic from the internet, then verify you can connect to it over SSH.

In this step, get ready to:
  • Launch an EC2 instance in the public subnet with a key pair for SSH access.
  • Configure the instance to use your custom VPC and security group.
  • Verify SSH connectivity from your local machine to the instance.
Configure instance settings and create a key pair

A key pair lets you prove your identity when connecting to the instance over SSH. AWS keeps the public key and you download the private key. Without it, you cannot log in.

  • Open the EC2 console at https://console.aws.amazon.com/ec2/.
  • Choose Launch instance.
  • Under Name and tags, enter web-server as the name.
  • Under Application and OS Images (Amazon Machine Image), select Amazon Linux 2023 AMI. This should already be selected by default.
  • Under Instance type, select t3.micro.
  • Under Key pair (login), choose Create new key pair.
  • Enter secure-arch-key as the key pair name.
  • Set Key pair type to RSA.
  • Set Private key file format to .pem.
  • Choose Create key pair. The secure-arch-key.pem file downloads automatically to your Downloads folder.

Save this file carefully

AWS only lets you download the private key ONCE. If you lose this file, you will not be able to SSH into your instance and will need to create a new key pair.

Configure network settings and launch the instance

By default, the launch wizard uses the default VPC. You need to switch it to your custom VPC and attach the security group you created earlier.

  • Under Network settings, choose Edit.
  • For VPC, select secure-arch-vpc.
  • For Subnet, select secure-arch-subnet-public1 (the first public subnet).
  • For Auto-assign public IP, select Enable.
  • Under Firewall (security groups), choose Select existing security group.
  • From the dropdown, select web-server-sg.
  • Leave all other settings at their defaults.
  • Choose Launch instance.

Why enable Auto-assign public IP?

Nondefault subnets (like yours) do not assign public IPs by default. You must explicitly enable it so your instance gets a public address you can SSH into from the internet.

Without a public IP, the instance would be isolated inside the VPC with no way to reach it from your laptop.

  • Wait for the instance to reach the Running state. Choose View all instances to see the Instances list.
  • Click the instance ID for web-server to open its details.
  • On the Details tab, find the Public IPv4 address field. Copy this address. You will need it to SSH in.

Don't see a public IPv4 address?

If the Public IPv4 address field is empty, you likely missed the Auto-assign public IP setting. Terminate this instance, then launch a new one with that setting set to Enable.

Also confirm you selected secure-arch-subnet-public1 (a public subnet) and not one of the private subnets.

Help me figure out why my EC2 instance has no public IP address.

Test SSH access from your Terminal

SSH (Secure Shell) lets you log into the instance remotely. Your security group only allows SSH from your IP, so this connection proves the security rules are working.

  • Press Cmd+Space to open Spotlight search.
  • Type Terminal and press Enter to open it.
  • Restrict the key file permissions by running this command:
chmod 400 ~/Downloads/secure-arch-key.pem

What does chmod 400 do?

This sets the file to read-only for your user and no access for anyone else. SSH refuses to use a key file with open permissions because other users on the machine could read your private key.

  • Connect to your EC2 instance by running this command:
ssh -i ~/Downloads/secure-arch-key.pem ec2-user@[[EC2_PUBLIC_IP="your EC2 instance Public IPv4 address"]]
  • When prompted with "Are you sure you want to continue connecting?", type yes and press Enter.

You should see a command prompt that starts with ec2-user@. This confirms you are logged into the instance.

Connection timed out or refused?

If your SSH connection times out, check these common causes:

  • Make sure you replaced the placeholder with the actual Public IPv4 address from your instance details.
  • Confirm web-server-sg allows SSH from your current IP. If your IP changed since you created the rule, update the inbound rule in the security group.
  • Verify the instance is in the Running state and shows 2/2 status checks passed.

Help me debug my SSH connection to EC2.

What just happened?

Your SSH traffic flowed through the Internet Gateway, into the public subnet, and reached your instance because the security group allows SSH from your IP. The same security group blocks everyone else. Your private key proved your identity to the instance.

Your web server is live and reachable. Next up, you will create the database in the private subnet and prove that only the web server can talk to it.

Create the RDS Database in the Private Subnet

Your web server is live and accessible via SSH. Now it needs a database to talk to.

In this step, you will deploy a MySQL database using Amazon RDS and place it inside your private subnets where nothing on the internet can reach it directly.

In this step, get ready to:
  • Create a DB subnet group that tells RDS which private subnets to use.
  • Launch an RDS MySQL instance in the private subnet with no public access.
  • Note the database endpoint for connecting from your web server.
Create a DB subnet group

Before you can launch a database, RDS needs to know which subnets it is allowed to use. A DB subnet group is a collection of subnets that RDS can place your database instance into.

  • Open the RDS console by navigating to https://console.aws.amazon.com/rds/ in your browser.
  • In the left navigation pane, choose Subnet groups.
  • Choose Create DB subnet group.
  • Enter secure-arch-db-subnet-group in the Name field.
  • Enter Private subnets for database in the Description field.
  • Select secure-arch-vpc from the VPC dropdown.
  • Under Add subnets, select both Availability Zones listed.
  • Choose ONLY the two private subnets: secure-arch-subnet-private1 and secure-arch-subnet-private2.
  • Choose Create.

Why does RDS need a subnet group?

Each DB subnet group must have at least one subnet in at least two Availability Zones. This gives RDS the flexibility to place or failover your database across zones, even for a single-instance deployment.

By selecting only your private subnets, you guarantee the database can never be placed somewhere with a direct internet route.

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

Don't see your private subnets in the list?

Make sure you selected secure-arch-vpc in the VPC dropdown first. The subnet list only populates after a VPC is chosen.

If you see subnets but are unsure which are private, check the subnet names. The ones ending in private1 and private2 are the ones you want.

Help me create my DB subnet group.

Create the RDS instance

With the subnet group ready, you can now launch the MySQL database itself. You will use the Free Tier template to keep costs at zero.

  • In the RDS console navigation pane, choose Databases.
  • Choose Create database.
  • Select Standard create for the creation method.
  • Under Engine options, select MySQL.
  • Under Templates, select Free tier.
  • Under Settings, enter secure-arch-db in the DB instance identifier field.
  • Set the Master username to admin.
  • Enter a Master password of your choice and confirm it. Remember this password because you will need it to connect later.
  • Under Instance configuration, confirm the instance class is set to db.t3.micro.

Why db.t3.micro?

The Free Tier template automatically selects db.t3.micro for you. This instance size is covered by your AWS Free Tier credits, so it costs nothing for this project.

  • Scroll down to the Connectivity section.
  • Select secure-arch-vpc for the VPC field.
  • Select secure-arch-db-subnet-group for the DB subnet group.
  • Set Public access to No.
  • Under VPC security group, select Choose existing.
  • Select database-sg from the list.
  • Remove the default security group if it is still attached.
  • Leave all other settings at their defaults.
  • Scroll to the bottom of the page and choose Create database.

Why set Public access to No?

Setting Public access to No means RDS will not assign a public IP address to this database instance. Combined with the private subnet (which has no route to an Internet Gateway), the database becomes completely unreachable from the internet.

The only way to reach it is from within the VPC, and your database-sg security group restricts that further to only your web server.

The database takes a few minutes

RDS takes 5-10 minutes to provision the instance. You will see the status change from Creating to Available. Wait for it to show Available before continuing.

Seeing an error when creating the database?

If you see an error about the subnet group, confirm that secure-arch-db-subnet-group is selected and that it contains subnets in two different Availability Zones.

If the database-sg security group does not appear in the dropdown, make sure you selected secure-arch-vpc as the VPC. Security groups are VPC-specific.

Help me fix my RDS creation error.

Note the database endpoint

Once your database status shows Available, you need to grab its endpoint address. This is the hostname your web server will use to connect.

  • In the RDS console, choose Databases in the left navigation pane.
  • Click the database name secure-arch-db to open its details.
  • Select the Connectivity & security tab.
  • Find the Endpoint value and copy it. It looks something like secure-arch-db.xxxxxxx.us-east-1.rds.amazonaws.com.
  • Save this endpoint somewhere you can easily access it. You will use it in the next step to connect from your EC2 instance.

What is this endpoint?

The endpoint is a DNS name that resolves to the private IP address of your RDS instance inside the VPC. Because the database has no public IP and sits in a private subnet, this DNS name only resolves to a reachable address from within the VPC itself.

Your database is running and locked away in the private subnet. Next up, you will connect to it from your web server and prove that the security model works exactly as designed.

Connect and Verify Security

Your database is sitting in a private subnet with no route to the internet, and your security groups are configured to only allow traffic from the web server. But how do you know it actually works?

In this step, you'll prove your security model by connecting to the database from the EC2 web server (the allowed path) and then attempting a connection from the public internet (the blocked path). If the architecture is correct, one succeeds and one fails.

In this step, get ready to:
  • Install the MySQL client on your EC2 instance.
  • Connect to the RDS database from EC2 and run a test query.
  • Verify the database is unreachable from the public internet.
Install the MySQL client on EC2

To test the database connection, you need a MySQL client installed on your EC2 instance. Amazon Linux 2023 doesn't include one by default, so you'll install the mariadb105 package (a MySQL-compatible client).

  • SSH back into your EC2 instance by running this command in Terminal:
ssh -i ~/Downloads/secure-arch-key.pem ec2-user@[[EC2_PUBLIC_IP="your EC2 instance public IPv4 address"]]

Where do I find my public IP?

Return to the EC2 console. Click on your web-server instance. The Public IPv4 address is shown in the instance details panel.

  • Install the MySQL-compatible client by running:
sudo dnf install mariadb105 -y

What does this command do?

sudo runs the command with administrator privileges. dnf is the package manager on Amazon Linux 2023. The mariadb105 package provides the mysql command-line tool that's compatible with MySQL databases.

  • Confirm the installation succeeded. You should see Complete! at the end of the output.

Seeing 'No match for argument: mariadb105'?

Make sure you're running this command on your EC2 instance (you should see ec2-user@ in your prompt), not on your local machine. The mariadb105 package is only available in the Amazon Linux 2023 repositories.

help me install the MySQL client on Amazon Linux 2023

Connect to RDS from EC2

Now for the moment of truth. Your database-sg security group allows inbound MySQL traffic (port 3306) only from instances with web-server-sg attached. Since your EC2 instance has web-server-sg, this connection should work.

  • Connect to your RDS database by running this command (still on your EC2 instance):
mysql -h [[RDS_ENDPOINT="your RDS endpoint e.g. secure-arch-db.xxxxxxx.us-east-1.rds.amazonaws.com"]] -u admin -p
  • Enter your master password when prompted and press Enter.

You should see the MySQL prompt appear, which looks like MySQL [(none)]>.

  • Run a test query to confirm the connection works:
SHOW DATABASES;

You should see a list of default MySQL databases including information_schema, mysql, and performance_schema.

What does this prove?

Traffic flowed from your EC2 instance (in the public subnet) through port 3306 to your RDS instance (in the private subnet). This worked because database-sg allows inbound traffic from web-server-sg.

This is the security group reference pattern. Instead of allowing a specific IP address, you allow an entire security group. Any instance with that group attached gets access, regardless of IP changes.

  • Type exit to disconnect from MySQL.

Connection timed out or was refused?

Double-check that you copied the full RDS endpoint from the Connectivity & security tab in the RDS console. The endpoint ends with .rds.amazonaws.com.

Also confirm your database-sg inbound rule has Source set to the web-server-sg security group (not an IP address).

help me troubleshoot my EC2 to RDS MySQL connection

Verify the database is unreachable from the internet

You've proven the allowed path works. Now prove the blocked path fails. You'll attempt to reach the database directly from your local machine (outside the VPC), which should be impossible.

  • Type exit to disconnect from the EC2 instance and return to your local Terminal prompt.
  • From your local machine, attempt to connect to the RDS endpoint by running:
nc -vz -G 5 [[RDS_ENDPOINT="your RDS endpoint e.g. secure-arch-db.xxxxxxx.us-east-1.rds.amazonaws.com"]] 3306

What is this command doing?

nc (netcat) attempts a raw TCP connection to the specified host and port. The -G 5 flag sets a 5-second connection timeout so you don't wait forever. If the connection fails, you'll see a timeout message.

After about 5 seconds, the connection should fail with a timeout message. This is the expected result.

Why does this fail?

Two layers of protection block this connection:

  • The RDS instance has no public IP address (you set Public access to No when creating it).
  • The database-sg Security Group only allows inbound traffic from web-server-sg. Your local machine doesn't have that security group, so it's rejected.
  • The private subnet's route table has no route to an Internet Gateway. Even if traffic somehow reached the subnet, there's no return path.

This is the principle of least privilege in action. Only the minimum required access is allowed.

If you have mysql installed locally

You can also try mysql -h <your-rds-endpoint> -u admin -p from your local machine. It will eventually timeout with the same result, but takes longer than the nc approach above.

Secret mission

Add a Network ACL for Defense in Depth

Your architecture already has security groups protecting the database. But what if you could add a second independent layer of defense at the subnet level? Network ACLs give you exactly that, and understanding the difference between stateful and stateless firewalls is one of the most tested concepts on the SAA-C03 exam.

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. Your EC2 and RDS instances are covered by your AWS Free Tier credits, so there are no ongoing costs while your credits remain active.

Cost warning

Your Free Tier credits last 6 months or until exhausted. If you leave these resources running after your credits expire, you will incur charges for the EC2 and RDS instances.

Monitor your remaining credits in the AWS Billing console under Free Tier.

Resources you used:

  • EC2 instance: web-server (t3.micro).
  • RDS instance: secure-arch-db (db.t3.micro, MySQL).
  • DB subnet group: secure-arch-db-subnet-group.
  • VPC: secure-arch-vpc (includes subnets, route tables, internet gateway, security groups, and network ACLs).
  • Local key pair file: ~/Downloads/secure-arch-key.pem.

Keep everything running

No action needed. Choose this if you are still actively building or want to revisit the architecture later.

  • Your Free Tier credits cover the EC2 and RDS instances while they remain active.
  • Monitor your credit usage in the AWS Billing console by choosing Free Tier in the navigation pane.
  • The VPC, subnets, security groups, route tables, and internet gateway are free and do not consume credits.

Pause - I'll come back to this later

Shut down running compute to free up credits while keeping your configuration intact.

  • Stop the EC2 instance: Open the EC2 console, choose Instances, select web-server, choose Instance state, then Stop instance. Confirm by choosing Stop.
  • Stop the RDS instance: Open the RDS console, choose Databases, select secure-arch-db, choose Actions, then Stop temporarily. Acknowledge that the instance will restart automatically after 7 days, then choose Stop temporarily.
  • RDS automatically restarts a stopped instance after 7 consecutive days. If you need it stopped for longer, you must stop it again manually each week.

Delete - I don't want to use this again

Remove all project resources permanently. This cannot be undone.

  • Terminate the EC2 instance: Open the EC2 console, choose Instances, select web-server, choose Instance state, then Terminate (delete) instance. Choose Terminate (delete) when prompted.
  • Delete the RDS database: Open the RDS console, choose Databases, select secure-arch-db, choose Actions, then Delete. Uncheck Create final snapshot?, uncheck Retain automated backups, type delete me in the confirmation box, and choose Delete. Wait for the database to finish deleting before proceeding.
  • Delete the DB subnet group: In the RDS console navigation pane, choose Subnet groups, select secure-arch-db-subnet-group, and choose Delete. Confirm the deletion.
  • Delete the VPC: Open the VPC console, choose Your VPCs in the navigation pane, select secure-arch-vpc, choose Actions, then Delete VPC. Review the listed resources (subnets, route tables, internet gateway, security groups, and network ACLs will be removed automatically). Type delete and choose Delete.
  • Delete the local key pair file by running this command in Terminal:
rm ~/Downloads/secure-arch-key.pem

That's a Wrap!

That's a Wrap!

Congratulations! You just built a production-style secure multi-tier architecture on AWS.

This is the same public/private subnet pattern that companies use to protect their databases in production. You now have hands-on proof that you understand VPC networking, security groups, and the core isolation concepts that form the foundation of the SAA-C03 exam.

What you learned:

  • Created a custom VPC with public and private subnets across two Availability Zones, and configured route tables so only public subnets can reach the internet.
  • Configured security groups implementing the principle of least privilege, referencing one security group from another so only your web server can talk to the database.
  • Deployed an EC2 web server in the public subnet and an RDS MySQL database in the private subnet, then verified the database is completely unreachable from the internet.
  • Added a Network ACL for defense in depth, understanding the difference between stateful security groups and stateless NACLs.

Ready to quiz yourself?