WordPress Network and Database on AWS

Build a Multi-AZ VPC and RDS MySQL database tier for WordPress on AWS.

Introduction

30 Second Summary

When a company's website goes down, every minute costs money and customer trust. The difference between an amateur setup and a production-grade architecture is how it handles failure.

In this project, you will build the network foundation and database tier for AnyCompany's WordPress hosting platform on AWS. You'll create an isolated network spanning two Availability Zones and deploy a highly available MySQL database protected by layered security groups.

What You'll Build

When you're done, you'll open the AWS Resource Map and see traffic flowing across two Availability Zones through four subnets, four chained security groups, and a database that can survive an entire data center going offline.

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

  • A live VPC you can open in the Resource Map and trace traffic flowing from the internet through public subnets, through a NAT Gateway, down to private subnets across 2 Availability Zones.
  • Four security groups forming a visible chain in the console, where each tier only accepts traffic from the tier directly above it. Zero 0.0.0.0/0 rules anywhere.
  • A Multi-AZ RDS MySQL database that automatically fails over to a standby in a different Availability Zone, protected by a CloudWatch billing alarm that emails you before costs exceed $10.
  • Secret Mission: Create a Read Replica and force a manual failover to prove your architecture survives AZ failure.

Are there any prerequisites?

You'll need an AWS account with admin access and the AWS CLI installed and configured. This project uses paid resources (NAT Gateway and RDS Multi-AZ) that cost approximately $2-4 if you delete everything within a few hours.

Before We Start

Before diving into the AWS console, let's clarify what you're building and why AnyCompany needs it. This is your moment to commit to the architecture goal before any hands-on work begins.

Protect Your Account with a Billing Alarm

The resources you are about to deploy cost real money on a personal AWS account. A NAT Gateway costs $0.045 per hour, and a Multi-AZ RDS instance adds another ~$0.034 per hour.

Before you touch any paid infrastructure, you need a safety net. In this step you will create a CloudWatch billing alarm that emails you the moment your account charges exceed $10.

In this step, get ready to:
  • Enable CloudWatch billing alerts and create a $10 threshold alarm.
  • Verify your AWS CLI configuration.
  • Note your public IP address for security group rules.
Enable billing alerts and create a CloudWatch alarm

AWS stores billing metric data exclusively in the US East (N. Virginia) region. You must enable billing alerts in the Billing console first, then switch to that region to create the alarm.

  • Open the AWS Billing and Cost Management console at https://console.aws.amazon.com/costmanagement/.
  • In the navigation pane, choose Billing Preferences.
  • Next to Alert preferences, choose Edit.
  • Select Receive CloudWatch Billing Alerts.
  • Choose Save preferences.

Why enable this separately?

CloudWatch cannot access billing metrics until you explicitly opt in here. This preference cannot be deactivated once enabled, but you can always delete individual alarms later.

Now you will switch regions and create the alarm itself.

  • In the top-right corner of the console, click the Region selector dropdown.
  • Select US East (N. Virginia) (us-east-1).
  • Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
  • In the navigation pane, choose Alarms, then choose All alarms.
  • Choose Create alarm.

The alarm creation wizard opens. First you will select the billing metric.

  • Choose Select metric.
  • In Browse, choose Billing, then choose Total Estimated Charge.
  • Select the checkbox for the EstimatedCharges metric.
  • Choose Select metric.

Don't see the Billing metric?

If Billing does not appear in the metric list, confirm two things: you enabled Receive CloudWatch Billing Alerts in Billing Preferences (above), and your region is set to US East (N. Virginia). Billing metrics only appear in this region.

help me find the Billing metric in CloudWatch

Next, configure the threshold and period.

  • For Statistic, choose Maximum.
  • For Period, choose 6 hours.
  • For Threshold type, choose Static.
  • For Whenever EstimatedCharges is..., choose Greater.
  • For than..., enter 10 (USD).
  • Choose Next.

Now you will set up the notification so the alarm emails you.

  • Under Notification, confirm In alarm is selected.
  • Choose Create new topic.
  • Enter the topic name AnyCompany-Billing-Alert.
  • Enter your email address in the Email endpoints field.
  • Choose Create topic.
  • Choose Next.

Finally, name the alarm and create it.

  • Under Name and description, enter a name such as AnyCompany-Billing-Alert.
  • Choose Next.
  • Review your settings under Preview and create.
  • Choose Create alarm.

What does this alarm do?

Every 6 hours, CloudWatch checks whether your total estimated charges exceed $10 USD. If they do, the alarm enters the ALARM state and the SNS topic sends you an email notification.

This metric represents your worldwide charges regardless of which region your resources run in. That is why billing alarms must be created in US East (N. Virginia).

Before the alarm can email you, you must confirm the SNS subscription.

  • Open your email inbox and look for a message from AWS Notifications.
  • Click the Confirm subscription link in the email.
  • Return to the CloudWatch console Alarms page.

You should see your alarm listed with a State of OK. This confirms the alarm is active and monitoring your charges.

Alarm shows INSUFFICIENT_DATA?

This is normal if your account has never generated billing data before. The alarm may take up to 6 hours to receive its first data point and switch to OK. You can continue with the project.

help me understand my alarm state

Verify AWS CLI and set your working region

Your AWS CLI is already installed and configured. A quick identity check confirms that your credentials are working and shows you which account is active.

  • Open a terminal on your machine.

Before you run the next command, what do you expect to see? You should predict an output showing your AWS account ID and your IAM user or role.

  • Verify your identity by running this command:
aws sts get-caller-identity

You should see JSON output containing your Account, UserId, and Arn. This confirms your credentials are valid.

  • Confirm your default region by running:
aws configure get region

The output should show us-east-1. If it shows a different region, that is fine for now. The console region selector overrides this for GUI work, and you will use us-east-1 throughout this project.

Seeing 'Unable to locate credentials'?

This means your CLI is not configured. Run aws configure and enter your Access Key ID, Secret Access Key, default region (us-east-1), and output format (json).

help me configure the AWS CLI

Find your public IP address for security group rules

Later in this project you will lock every security group to your personal IP address instead of allowing traffic from anywhere. You need to know your current public IP to use as a /32 CIDR in those rules.

The page displays a single line of text: your public IPv4 address (for example, 203.0.113.45).

  • Write down your IP address. You will use it throughout this project in the format x.x.x.x/32 (replacing x.x.x.x with your actual IP).

Why /32?

The /32 suffix means "this exact single IP address." It is the most restrictive CIDR range possible. Using your personal IP instead of 0.0.0.0/0 (which means "the entire internet") ensures only you can reach your resources during development.

Your IP may change

If you are on a home network, your ISP may assign a new IP address periodically. If you lose connectivity to your resources later, revisit checkip.amazonaws.com and update your security group rules with the new IP.

Your account is now protected with a billing alarm, your CLI is verified, and you have your IP address ready for locking down security groups. Next up, you will build the VPC network that gives AnyCompany's architecture a home across two Availability Zones.

Build the Multi-AZ VPC Network

Your account is now protected with a billing alarm, and you have your public IP ready for security group rules. Time to build the actual infrastructure that AnyCompany's WordPress platform will live on.

AnyCompany needs isolated network infrastructure spanning 2 Availability Zones before any compute or database resources can be deployed. Without this foundation, nothing else in the architecture has a home. In this step, you will create a complete VPC with public and private subnets, routing, and a NAT Gateway using a single AWS wizard.

In this step, get ready to:
  • Create a VPC with 4 subnets (2 public, 2 private) across 2 Availability Zones.
  • Configure routing with an Internet Gateway and NAT Gateway.
  • Verify the full network layout in the VPC Resource Map.
Create the VPC using the "VPC and more" wizard

AWS provides a wizard that creates an entire network stack in one pass. You will use the "VPC and more" option to generate subnets, route tables, gateways, and a VPC endpoint all at once.

  • In the AWS Console, type VPC in the top search bar and select VPC from the results.
  • Click Create VPC.
  • Under Resources to create, select VPC and more.

Why "VPC and more"?

Selecting "VPC and more" tells AWS to auto-create the subnets, route tables, Internet Gateway, and NAT Gateway in a single action. If you selected "VPC only", you would need to create each of these resources manually one by one.

Now configure the wizard with AnyCompany's network requirements:

  • In the Name tag auto-generation field, enter AnyCompany.
  • Set the IPv4 CIDR block to 10.0.0.0/16.
  • Set Number of Availability Zones to 2.
  • Set Number of public subnets to 2.
  • Set Number of private subnets to 2.
  • Under NAT gateways, select In 1 AZ.
  • Under VPC endpoints, select S3 Gateway.
  • Under DNS options, confirm both Enable DNS hostnames and Enable DNS resolution are selected.
  • Click Create VPC.

AWS will now create all your network resources. Wait for every item in the creation workflow to show a green "Create complete" status before proceeding.

What is a CIDR block?

A CIDR block defines the range of IP addresses available inside your VPC. The block 10.0.0.0/16 gives you 65,536 addresses to divide among your subnets. The wizard automatically carves this into smaller /20 blocks for each subnet.

Why NAT Gateway in only 1 AZ?

Production best practice is 1 NAT Gateway per AZ, so that if one AZ fails, private instances in the other AZ still have internet access. For this project, using 1 NAT Gateway saves cost (~$0.045/hour per gateway).

This is a deliberate trade-off you can explain to your panel: you built the budget version but can whiteboard the production-ideal design with 1 NAT per AZ.

Seeing an error during creation?

If you see a permissions error, confirm your IAM user has admin access. If the wizard fails to allocate an Elastic IP for the NAT Gateway, check that your account has not reached the Elastic IP limit (default is 5 per region).

Help me troubleshoot VPC creation errors in AWS

Review the Resource Map and understand routing

The VPC console provides a visual Resource Map that shows how all your network components connect. This is the same view you would use to explain the architecture to your panel.

Before you look at the map, predict what you expect to see. How many subnets should appear? What connects the public subnets to the internet versus the private subnets?

  • In the left sidebar, click Your VPCs.
  • Select AnyCompany-vpc from the list.
  • Click the Resource map tab.

You should see a full diagram of your VPC showing 4 subnets (2 public, 2 private) across 2 AZs, an Internet Gateway, a NAT Gateway, and route table associations connecting everything.

Trace the traffic paths in the map:

  • Public subnets route 0.0.0.0/0 to the Internet Gateway (direct internet access).
  • Private subnets route 0.0.0.0/0 to the NAT Gateway (outbound internet only, no inbound).
  • The wizard auto-created 3 route tables: 1 public table shared by both public subnets, and 2 private tables (one per AZ).

Why 2 Availability Zones minimum?

Each AZ is a physically separate data center with independent power, cooling, and networking. If one AZ fails, your application keeps running in the other.

This is the foundation of high availability on AWS. Every production workload should span at least 2 AZs.

Verify subnet CIDR allocations

The Resource Map confirms the overall structure. Now verify that each subnet is in the correct AZ with a proper CIDR allocation.

  • In the left sidebar, click Subnets.
  • In the filter bar, select your AnyCompany-vpc to show only its subnets.

You should see 4 subnets listed:

  • AnyCompany-subnet-public1-us-east-1a in us-east-1a.
  • AnyCompany-subnet-public2-us-east-1b in us-east-1b.
  • AnyCompany-subnet-private1-us-east-1a in us-east-1a.
  • AnyCompany-subnet-private2-us-east-1b in us-east-1b.
  • Confirm that each subnet has a /20 CIDR block assigned (the wizard auto-allocates from your /16 range).
  • Confirm that each pair of subnets (public and private) is distributed across both us-east-1a and us-east-1b.

What are public vs private subnets?

A public subnet has a route to an Internet Gateway, so resources inside it can receive traffic from the internet. A private subnet routes outbound traffic through a NAT Gateway instead, which means resources inside can reach the internet (for updates and patches) but nothing on the internet can initiate a connection to them.

Your database will live in the private subnets. Only the load balancer (built in a later project) will live in the public subnets.

Only seeing 2 subnets or missing the NAT Gateway?

Make sure you selected your AnyCompany VPC in the filter and not the default VPC. If subnets are missing, the wizard may have failed partway through. Delete the partially created VPC and re-run the wizard with all settings double-checked.

Help me fix my VPC that has missing subnets or gateways

Your network foundation is complete. You now have a production-grade VPC spanning 2 Availability Zones with proper isolation between public and private resources. Next up, you will create the security groups that control exactly which traffic can flow between each tier of the architecture.

Create Tiered Security Groups

Your VPC has subnets and routing in place, but nothing controls which resources can talk to each other inside it. Right now, any instance you launch could potentially reach any other instance on any port.

In a production architecture, each tier should only accept traffic from the tier directly above it. This enforces least-privilege network access. A compromised web server cannot directly reach the database because the security group chain blocks that path.

In this step, get ready to:
  • Create four security groups in your AnyCompany VPC.
  • Add inbound rules that chain the groups together: Your IP to ALB to Web to App to Database.
  • Verify the chain with a CLI command that lists all security groups.
Create all four security groups

You will create four empty security groups first, then add rules in the next substep. Creating them all upfront lets you reference one group's ID inside another group's rules.

  • In the VPC console left navigation pane, click Security Groups.
  • Click Create security group.
  • Enter the Security group name: AnyCompany-ALB-SG.
  • Enter the Description: Allows HTTP/HTTPS from admin IP only.
  • For VPC, remove the default VPC and select AnyCompany-vpc.
  • Leave the Inbound rules section empty for now.
  • Click Create security group.

You should see a green success banner and your new security group listed.

  • Return to the Security Groups list by clicking Security Groups in the left navigation.
  • Click Create security group and repeat the same process for these three groups, selecting AnyCompany-vpc each time and leaving inbound rules empty:
  • Name: AnyCompany-Web-SG with Description: Allows HTTP from ALB only.
  • Name: AnyCompany-App-SG with Description: Allows traffic from Web tier only.
  • Name: AnyCompany-DB-SG with Description: Allows MySQL from App tier only.
  • Return to the Security Groups list.
  • Filter by your VPC using the search bar (type AnyCompany).
  • Confirm you see all four groups: AnyCompany-ALB-SG, AnyCompany-Web-SG, AnyCompany-App-SG, and AnyCompany-DB-SG.

Don't see all four groups?

Make sure you selected AnyCompany-vpc (not the default VPC) when creating each group.

If one is missing, you may have accidentally created it in the wrong VPC. Delete it and recreate it in the correct VPC.

help me find my security groups in the VPC console

Add inbound rules to each security group forming the chain

Now you will wire the groups together with inbound rules. Each group only accepts traffic from the tier directly above it in the chain.

  • Select AnyCompany-ALB-SG from the list by clicking its checkbox.
  • Click the Inbound rules tab below.
  • Click Edit inbound rules.
  • Click Add rule. Set Type to HTTP and Source to My IP.
  • Click Add rule again. Set Type to HTTPS and Source to My IP.
  • Click Save rules.

You should see two inbound rules listed, both with your IP address as the source.

  • Return to the Security Groups list.
  • Select AnyCompany-Web-SG.
  • Click the Inbound rules tab, then Edit inbound rules.
  • Click Add rule. Set Type to HTTP. For Source, choose Custom and type the security group ID of AnyCompany-ALB-SG (start typing sg- or the group name to find it).
  • Click Add rule. Set Type to SSH and Source to My IP.
  • Click Save rules.

What does referencing a security group as a source mean?

When you enter a security group ID as the source, the rule allows traffic from any resource associated with that security group, regardless of its IP address.

This is critical for Auto Scaling. EC2 instances get new private IPs when replaced, but their security group association stays the same. The rules keep working without updates.

  • Return to the Security Groups list.
  • Select AnyCompany-App-SG.
  • Click the Inbound rules tab, then Edit inbound rules.
  • Click Add rule. Set Type to Custom TCP, Port range to 80, and Source to Custom with the security group ID of AnyCompany-Web-SG.
  • Click Add rule. Set Type to SSH and Source to My IP.
  • Click Save rules.

One more group to go. The database only needs one inbound rule.

  • Return to the Security Groups list.
  • Select AnyCompany-DB-SG.
  • Click the Inbound rules tab, then Edit inbound rules.
  • Click Add rule. Set Type to MYSQL/Aurora (port 3306). For Source, choose Custom and enter the security group ID of AnyCompany-App-SG.
  • Click Save rules.

Why no direct database access from your IP?

Defense in depth. Even as admin, you access the database by SSHing into an App tier instance first, then connecting to MySQL from there.

This mimics production access patterns where no human directly touches the database from the public internet.

Verify the security group chain

Before you run the verification, think about what you expect to see. How many custom security groups should appear for your VPC?

  • Review each security group's inbound rules by clicking through them in the console.
  • Confirm that no rule anywhere uses 0.0.0.0/0 as a source.
  • Click on AnyCompany-DB-SG and look at its Inbound rules tab.
  • Confirm the source column shows a security group ID (sg-...) referencing AnyCompany-App-SG, not an IP address.
  • Run this CLI command to list all your custom security groups in a table:
aws ec2 describe-security-groups --filters "Name=vpc-id,Values=[[VPC_ID="your AnyCompany VPC ID"]]" --query "SecurityGroups[].{Name:GroupName,ID:GroupId}" --output table

You should see a table listing at least 5 security groups: the 4 you created plus the default VPC security group.

Where do I find my VPC ID?

In the VPC console, click Your VPCs in the left navigation. The VPC ID for AnyCompany-vpc is in the VPC ID column (it starts with vpc-).

Seeing fewer than 4 custom groups?

Double-check that you pasted the correct VPC ID in the command. If you used the wrong VPC ID, the filter will not find your groups.

Also confirm your CLI region matches the region where you created the VPC (us-east-1).

help me troubleshoot my security group CLI query

Why reference security groups instead of IP addresses?

EC2 instances get new private IPs when replaced by Auto Scaling. Security group referencing means any instance associated with Web-SG can reach App-SG regardless of its current IP.

This makes the rules Auto Scaling-friendly. You never need to update rules when instances scale in or out.

Your security groups now form a complete chain: your IP flows to the ALB, the ALB forwards to Web, Web passes to App, and only App can reach the Database. Next up, you will deploy an RDS MySQL instance into those private subnets, protected by the DB-SG you just created.

Deploy RDS MySQL with Multi-AZ

Your security groups form a complete chain from the ALB tier all the way down to the database. Every rule references the group directly above it, and no 0.0.0.0/0 exists anywhere. Now it's time to deploy the database that sits behind that final link.

AnyCompany's WordPress database must survive an entire Availability Zone failure without data loss or manual intervention. RDS Multi-AZ solves this by maintaining a synchronous standby copy of your database in a second AZ. If the primary fails, RDS automatically updates the DNS endpoint to point at the standby within 60-120 seconds.

In this step, get ready to:
  • Create a DB subnet group pointing RDS to your private subnets.
  • Deploy an RDS MySQL instance with Multi-AZ replication enabled.
  • Verify the database is available with primary and standby in different AZs.
Create a DB subnet group

Before RDS can deploy a database into your VPC, it needs to know which subnets to use. A DB subnet group tells RDS exactly which private subnets are available for database placement.

  • Open the RDS console at https://console.aws.amazon.com/rds/.
  • In the left navigation pane, click Subnet groups.
  • Click Create DB Subnet Group.
  • For Name, enter anycompany-db-subnet-group.
  • For Description, enter Private subnets for AnyCompany database tier.
  • For VPC, select your AnyCompany VPC.
  • In the Add subnets section, select both Availability Zones (us-east-1a and us-east-1b).
  • Under Subnets, select only the 2 private subnets. Confirm by checking the CIDR blocks match your private subnets (roughly 10.0.128.0/20 and 10.0.144.0/20). Do not select the public subnets.
  • Click Create.

Your new DB subnet group appears in the subnet groups list. Click on it to confirm it shows both private subnets across 2 Availability Zones.

Why does RDS need subnets in 2 AZs?

A DB subnet group must contain subnets in at least 2 Availability Zones. This is a hard requirement for Multi-AZ deployments because RDS places the primary in one AZ and the standby in another. Without subnets in 2 AZs, RDS cannot create a Multi-AZ instance.

Only seeing public subnets in the dropdown?

Make sure you selected the correct VPC (AnyCompany, not the default VPC). The subnet list only shows subnets belonging to the selected VPC. If you still don't see 4 subnets, return to the VPC console and verify all 4 subnets were created in Step 2.

Help me figure out why my subnets aren't appearing in the DB subnet group creation page.

Create the RDS MySQL Multi-AZ instance

With the subnet group ready, you can now deploy the MySQL database. You must use Standard create (not Easy create) because Easy create does not expose the Multi-AZ configuration option.

  • In the RDS console left navigation, click Databases.
  • Click Create database.
  • Under creation method, select Standard create.
  • For Engine type, select MySQL.
  • Under Templates, select Dev/Test.
  • Under Availability & durability, select Multi-AZ DB instance.

Why Dev/Test instead of Free Tier?

The Free Tier template does not expose the Multi-AZ option. Dev/Test gives you access to configure Multi-AZ while keeping instance sizes small. This does mean the database will cost approximately $0.034/hour, which is why you set up the billing alarm in Step 1.

  • In the Settings section, enter anycompany-wordpress-db as the DB instance identifier.
  • Change the Master username from the default admin to a personalised username following the pattern yourname_admin (replace yourname with your actual name).
  • Enter a strong password in the Master password field and confirm it. Save this password securely. You will need it in Project 2.
  • Under Instance configuration, select db.t3.micro.
  • Under Storage, set Allocated storage to 20 GiB.
  • Select gp3 as the storage type.
  • Uncheck Enable storage autoscaling to control costs.

Why disable autoscaling and backups?

This is a demo environment on your personal account. Disabling storage autoscaling and automated backups keeps costs predictable. In a production environment for AnyCompany, you would enable both. This is a great talking point for your panel.

  • In the Connectivity section, for Virtual Private Cloud (VPC), select your AnyCompany VPC.
  • For DB subnet group, select anycompany-db-subnet-group.
  • Set Public access to No.
  • Under VPC security group, select Choose existing, then select AnyCompany-DB-SG.
  • Remove the default security group so only AnyCompany-DB-SG remains.
  • Expand Additional configuration.
  • Enter wordpress as the Initial database name.
  • Uncheck Enable automated backups.
  • Click Create database.

The database status shows Creating. This process takes 10-15 minutes because RDS is provisioning two instances (primary and standby) across different Availability Zones.

Use the wait productively

While waiting for the database, review the security group chain you built in Step 3. Trace the path: your IP reaches the ALB-SG, ALB-SG reaches Web-SG, Web-SG reaches App-SG, and only App-SG reaches DB-SG on port 3306. This is the story you will tell your panel.

Verify Multi-AZ deployment

Once the status changes to Available, you can confirm the Multi-AZ setup and note the endpoint for future use.

  • Wait for the Status column to change from Creating to Available. Refresh the page if needed.
  • Click on your DB instance name anycompany-wordpress-db to open its details.
  • Click the Configuration tab.

Before you check the configuration, predict: what value should Multi-AZ show if your deployment succeeded?

  • Confirm that Multi-AZ shows Yes.
  • Note the instance class (db.t3.micro) and engine version displayed.
  • Click the Connectivity & security tab.
  • Note the Endpoint value. This is the DNS name your WordPress application will use in Project 2.
  • Confirm the port shows 3306.
  • Verify the VPC shows your AnyCompany VPC and the security group shows AnyCompany-DB-SG.

The Configuration tab shows Multi-AZ: Yes, confirming that RDS created a synchronous standby in a different AZ. The Connectivity tab shows your endpoint on port 3306, deployed in your private subnets with only AnyCompany-DB-SG attached.

How does Multi-AZ failover work?

RDS maintains a synchronous standby replica in a different AZ. If the primary fails, RDS automatically updates the DNS endpoint to point to the standby. Failover typically completes in 60-120 seconds. Your application reconnects using the same endpoint with no code changes required.

The key word is synchronous. Every write to the primary is confirmed on the standby before RDS acknowledges it to your application. This means zero data loss during failover, unlike asynchronous replication where recent writes could be lost.

Multi-AZ vs Read Replica

Multi-AZ is for high availability. The standby cannot serve read traffic. It exists solely to take over if the primary fails.

Read Replicas are for read scaling. They use asynchronous replication, can serve read queries, but do not provide automatic failover. You will explore Read Replicas in the Secret Mission.

Status stuck on Creating for more than 20 minutes?

Multi-AZ instances take longer to provision than single-AZ because RDS creates two instances and synchronises them. If it has been more than 25 minutes, check the Events tab in the RDS console for error messages. Common causes include the DB subnet group not covering 2 AZs, or the security group not existing in the selected VPC.

Help me troubleshoot why my RDS Multi-AZ instance is stuck in Creating status.

Secret mission

Create a Read Replica and Prove Failover

Your Multi-AZ database has a synchronous standby ready to take over. But can you prove it actually works? Create an asynchronous Read Replica for read scaling, then force a manual failover and watch your primary switch Availability Zones while the replica keeps replicating from the new primary.

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 uses paid AWS resources that incur ongoing hourly charges.

Cost warning

Your NAT Gateway costs $0.045/hour (~$1.08/day). Your RDS Multi-AZ instance costs ~$0.034/hour (~$0.82/day). If you completed the Secret Mission, the Read Replica adds ~$0.017/hour (~$0.41/day). Left running, these resources cost approximately $3-4/day total.

Delete all resources immediately after you finish preparing for your panel to avoid surprise charges.

Resources you used:

  • NAT Gateway with associated Elastic IP (in AnyCompany-subnet-public1-us-east-1a).
  • RDS MySQL Multi-AZ instance (anycompany-wordpress-db).
  • RDS Read Replica (anycompany-wordpress-db-read) if you completed the Secret Mission.
  • DB subnet group (anycompany-db-subnet-group).
  • VPC (AnyCompany-vpc) with 4 subnets, Internet Gateway, route tables, S3 Gateway endpoint, and 4 security groups.
  • CloudWatch billing alarm and SNS topic (AnyCompany-Billing-Alert).

Keep everything running

No action needed. Choose this if you are still actively preparing for your panel and want to demo the architecture in the console.

  • Budget approximately $3-4 per day while all resources remain running.
  • Delete everything within 1-2 days of completing your panel presentation.
  • Your CloudWatch billing alarm will email you if estimated charges exceed $10.

Pause - I'll come back to this later

Shut down the most expensive resources while keeping your configuration recoverable. You cannot stop a NAT Gateway or an RDS Multi-AZ instance. You must delete them and recreate later.

  • In the RDS console, select anycompany-wordpress-db, choose Actions, then Take snapshot. Name it something memorable.
  • If you have the Read Replica, delete it first: select anycompany-wordpress-db-read, choose Actions, Delete. Enter delete me to confirm.
  • Delete the primary RDS instance: select anycompany-wordpress-db, choose Actions, Delete. Select Create final snapshot? if you want a backup. Enter delete me and choose Delete.
  • In the VPC console, choose NAT gateways. Select your NAT Gateway, choose Actions, Delete NAT gateway. Type delete to confirm.
  • Release the Elastic IP: in the VPC console, choose Elastic IPs. Select the disassociated Elastic IP, choose Actions, Release Elastic IP addresses. Choose Release.
  • Keep the VPC, subnets, security groups, and DB subnet group. They are free while idle. Recreate the NAT Gateway and RDS from your snapshot when you return.

Delete - I don't want to use this again

Remove all project resources completely. Follow this order to avoid dependency errors.

  • Delete the Read Replica first (if it exists): in the RDS console, select anycompany-wordpress-db-read, choose Actions, Delete. Enter delete me to confirm. Wait for the deletion to complete.
  • Delete the primary RDS instance: select anycompany-wordpress-db, choose Actions, Delete. Clear Create final snapshot? and Retain automated backups. Enter delete me and choose Delete. Wait for the deletion to complete.
  • Delete the DB subnet group: in the RDS console, choose Subnet groups. Select anycompany-db-subnet-group, choose Delete, and confirm.
  • Delete the NAT Gateway: in the VPC console, choose NAT gateways. Select your NAT Gateway, choose Actions, Delete NAT gateway. Type delete to confirm. Wait about a minute for it to show as deleted.
  • Release the Elastic IP: in the VPC console, choose Elastic IPs. Select the Elastic IP that was associated with the NAT Gateway, choose Actions, Release Elastic IP addresses. Choose Release.
  • Delete the security groups: in the VPC console, choose Security groups. Select all four AnyCompany security groups (ALB-SG, Web-SG, App-SG, DB-SG). Choose Actions, Delete security groups. Enter Delete to confirm.
  • Delete the VPC: in the VPC console, choose Your VPCs. Select AnyCompany-vpc, choose Actions, Delete VPC. The console will list the components it will delete (subnets, route tables, Internet Gateway, gateway endpoints, network ACLs). Enter delete and choose Delete.
  • Delete the CloudWatch alarm: switch to US East (N. Virginia) region. Open the CloudWatch console, choose Alarms, select your billing alarm, choose Actions, Delete.
  • Delete the SNS topic: open the SNS console, choose Topics. Select AnyCompany-Billing-Alert, choose Delete. Type delete me to confirm.

Nice Work!

Nice Work!

Nice work! You've just built the complete network foundation and database tier for AnyCompany's WordPress hosting platform on AWS.

You've learned how to:

  • Build a production-grade VPC spanning 2 Availability Zones with public and private subnets, proper routing through an Internet Gateway and NAT Gateway.
  • Create four tiered security groups enforcing least-privilege access through security group referencing with zero 0.0.0.0/0 rules anywhere in the chain.
  • Deploy an RDS MySQL Multi-AZ instance in private subnets, proving high availability with synchronous replication and automatic failover.
  • Secret Mission: Created a Read Replica for read scaling and proved failover works by forcing the primary to switch AZs.

Ready to quiz yourself?