Document AWS Three-Tier Architecture

Create a professional AWS architecture diagram and GitHub README.

Introduction

30 Second Summary

Every cloud engineering team needs to communicate how their infrastructure works. Whether you're onboarding a new teammate or presenting a design to stakeholders, clear documentation with professional diagrams makes all the difference.

In this project, you will create professional technical documentation for an AWS three-tier architecture. You'll build an architecture diagram using official AWS icons and write a structured README that explains the full design.

What You'll Build

A public GitHub repository containing a polished README.md that documents a three-tier architecture on AWS, complete with an architecture diagram built using official AWS icons in draw.io.

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

A README.md file with structured documentation covering the full architecture, networking, and security design.
A professional architecture diagram created in draw.io using official AWS19 icons.
A public GitHub repository with your documentation ready to share via link.
Secret Mission: Add a cost estimation section and a data flow diagram for extra depth.

Are there any prerequisites?

This project assumes a basic understanding of AWS services like VPC, EC2, RDS, and ALB. No software installation is required. draw.io runs entirely in your browser.

Set Up Your Documentation Structure

Every well-organized project starts with a clean folder structure. You need a dedicated place for your documentation files and architecture diagrams before you start building them.

In this step, you'll create a project folder on your Desktop with a subfolder for images and an empty Markdown file. This file will become the home for all your architecture documentation.

In this step, get ready to:

Create the aws-three-tier-architecture project folder on your Desktop.
Set up an images subfolder for your architecture diagram.
Create an empty README.md file for your documentation.

Create the project folder and files

Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Terminal (macOS) or PowerShell (Windows) and press Enter to open it.

Move to your Desktop by running this command:

cd ~/Desktop

Create the project folder, images subfolder, and an empty README.md file by running these commands:

macOS

mkdir -p aws-three-tier-architecture/images
touch aws-three-tier-architecture/README.md

Windows

mkdir aws-three-tier-architecture\images
New-Item aws-three-tier-architecture\README.md -ItemType File

What is a README.md file?

A README.md file is the front page of any GitHub repository. When you push this project to GitHub, it automatically renders the README as the first thing visitors see.

The .md extension stands for Markdown. It is a lightweight formatting language for creating structured documents with headings, lists, and images.

Confirm your files were created by running:

ls aws-three-tier-architecture

You should see images and README.md listed in the output.

Don't see both items?

Make sure you ran cd ~/Desktop before creating the folder. Without it, your folder may have been created in a different location.
On Windows, make sure you are using PowerShell and not Command Prompt. The New-Item command does not work in Command Prompt.

Help me find or create my aws-three-tier-architecture project folder.

Your project structure is ready. Next up, you'll open draw.io and start building a professional architecture diagram with official AWS icons.

Build the Architecture Diagram in draw.io

Your project folder is ready with README.md and an images/ directory waiting for content. The next piece of your documentation is the architecture diagram itself.

Diagrams are often the first thing readers look at when reviewing technical documentation. You'll use draw.io, a free browser-based diagramming tool, to build your three-tier architecture diagram with official AWS icons.

In this step, get ready to:

Open draw.io in your browser.
Create a new blank diagram saved to your device.
Enable the AWS19 shape library for official AWS icons.

Open draw.io in your browser

Open your browser and go to app.diagrams.net.

The draw.io interface loads with a dialog asking where you'd like to save your work.

What is draw.io?

draw.io (also known as diagrams.net) is a free, browser-based diagramming tool. It includes built-in shape libraries for AWS, GCP, Azure, and other platforms.

No account or installation is required. Everything runs directly in your browser.

Create a new blank diagram

draw.io can save diagrams to cloud services like Google Drive or OneDrive. For this project, you'll save locally to your computer so you can add the exported file to your project folder later.

In the storage dialog, click Device.
Click Create New Diagram.
If prompted for a template, select Blank Diagram and click Create.

You should see an empty white canvas with a toolbar along the top and a shapes panel on the left.

Why save to Device?

Saving to Device stores your diagram files directly on your computer. This keeps things simple since you'll export the finished diagram as a PNG and add it to your Git repository yourself.

Enable the AWS19 shape library

draw.io includes official AWS icon sets, but they aren't enabled by default. You need to turn on the AWS19 library to access the shapes for your architecture diagram.

Click + More Shapes at the bottom of the left panel.
Scroll down to the Networking section.
Check the box next to AWS19.
Click Apply.

You should see new AWS shape categories appear in the left panel, including groups like Compute, Database, Networking, and Groups.

What is AWS19?

AWS19 is draw.io's library of official AWS architecture icons. The shapes are organized into categories like Compute, Database, Networking, and Storage.

These are the same icons AWS uses in their own architecture documentation. Using them makes your diagrams instantly recognizable to anyone who works with AWS.

Don't see AWS shapes in the left panel?

Make sure you scrolled to the Networking section in the More Shapes dialog. AWS19 is listed there, not under a separate AWS heading.

Double check that the AWS19 checkbox is checked and you clicked Apply to confirm your selection.

help me find and enable the AWS19 shape library in draw.io

Your canvas is set up with official AWS icons ready to use. Next, you'll arrange these shapes to build the three-tier architecture diagram layer by layer.

Design the Three-Tier Diagram

Your draw.io canvas is ready with AWS19 shapes loaded. Now it's time to build the actual architecture diagram that will anchor your documentation.

A well-designed diagram communicates how components interact at a glance. You'll build this one layer by layer, starting from the outermost boundary and working inward through each tier.

In this step, get ready to:

Set up the AWS Cloud and VPC boundary shapes.
Place components for the Web, Application, and Database Tiers.
Connect all components with directional arrows and label every subnet.

Set up the AWS Cloud and VPC boundaries

Every AWS architecture diagram starts with two boundaries. The AWS Cloud shape represents everything running on Amazon's infrastructure. The VPC shape inside it represents your isolated network where all three tiers live.

In the left panel of draw.io, expand the AWS19 / Groups section.
Drag the AWS Cloud shape onto the center of your canvas.
Resize it so it covers most of your canvas. This needs to be large enough to hold all your architecture components.
Drag a VPC shape from the same Groups section and place it inside the AWS Cloud boundary.
Resize the VPC shape so it fills most of the AWS Cloud shape, leaving a small margin around the edges.

What are group shapes?

Group shapes in draw.io act as containers. When you place other shapes inside a group, they move together when you reposition the group.

The AWS Cloud and VPC shapes are designed to represent these logical boundaries in your architecture. Everything you build next goes inside the VPC.

You should see two nested rectangles on your canvas. The outer one is labeled "AWS Cloud" and the inner one is labeled "VPC."

Shapes appearing outside the boundary?

If the VPC shape landed outside the AWS Cloud boundary, drag it slowly over the AWS Cloud shape until you see a blue highlight around the container. Then release. The blue highlight confirms the shape will be nested inside the group.

Help me nest shapes inside groups in draw.io.

Add components for each tier

With the boundaries in place, you'll now add the actual AWS service components. You'll build from top to bottom: Web Tier at the top, Application Tier in the middle, Database Tier at the bottom.

Start with the Web Tier in the upper portion of your VPC. This tier sits in public subnets and is the only layer exposed to the internet.

From the AWS19 / Groups section, drag two subnet shapes into the upper portion of the VPC. Place them side by side. These represent your public subnets across two Availability Zones.
Expand the AWS19 / Networking section in the left panel.
Drag an Internet Gateway icon and place it at the very top of the VPC, above the two public subnets.
Drag an Application Load Balancer (ALB) icon from the same Networking section. Place it just below the Internet Gateway.
Expand the AWS19 / Compute section.
Drag two EC2 instance icons (or an Auto Scaling Group icon) and place one inside each public subnet.

Next, build the Application Tier in the middle portion of your VPC. This tier sits in private subnets with no direct internet exposure.

Drag two more subnet shapes from AWS19 / Groups and place them below the Web Tier subnets. These represent your private subnets across two Availability Zones.
Drag a second Application Load Balancer icon from AWS19 / Networking and place it between the Web Tier and the Application Tier subnets. This is your Internal ALB.
Drag two EC2 instance icons from AWS19 / Compute and place one inside each private subnet.
Drag a NAT Gateway icon from AWS19 / Networking and place it in one of the public subnets at the top. The NAT Gateway lets the Application Tier reach the internet for software updates without being directly exposed.

Finally, build the Database Tier at the bottom of your VPC. This tier sits in isolated private subnets that only the Application Tier can reach.

Drag two more subnet shapes from AWS19 / Groups and place them at the bottom of the VPC. These represent your isolated private subnets.
Expand the AWS19 / Database section in the left panel.
Drag an Amazon RDS icon and place it in the first isolated subnet. This is your primary database instance.
Drag a second RDS icon and place it in the other isolated subnet. This represents the standby instance for Multi-AZ failover.

Why two of everything?

Each tier has components in two Availability Zones. If one AZ goes down, the other keeps your application running. This is the foundation of high availability on AWS.

Your canvas should now show three distinct layers of components inside the VPC. The Web Tier sits at the top with EC2 instances in public subnets. The Application Tier is in the middle with EC2 instances in private subnets. The Database Tier is at the bottom with two RDS icons in isolated subnets.

Can't find a specific shape?

If a shape isn't visible in the expected sub-library, try the search bar at the top of the left panel. Type the name of the service (e.g., "RDS" or "NAT Gateway") to search across all enabled libraries.

Make sure the AWS19 library is still enabled. Click More Shapes at the bottom of the left panel and confirm the AWS19 checkbox is checked under Networking.

Help me find AWS shapes in draw.io.

Connect components and add labels

Your components are placed, but without arrows and labels, nobody can tell how traffic flows through the architecture. Connections make the diagram useful.

Hover over the Internet Gateway shape until you see small blue arrows on its edges.
Click and drag from a blue arrow to the External ALB to create a directional arrow.
Draw arrows from the External ALB to each Web Tier EC2 instance.
Draw arrows from the Web Tier EC2 instances to the Internal ALB.
Draw arrows from the Internal ALB to each Application Tier EC2 instance.
Draw arrows from the Application Tier EC2 instances to the RDS Primary icon.
Draw an arrow between the RDS Primary and RDS Standby icons to show the replication link.

Add a "Users" label

Double-click on an empty area above the AWS Cloud boundary to add a text label. Type "Users" and draw an arrow from it down to the Internet Gateway. This makes the starting point of the traffic flow crystal clear.

Now label every group and subnet so the diagram reads clearly without needing any external context.

Double-click on the first public subnet shape and type Public Subnet - AZ1.
Double-click on the second public subnet shape and type Public Subnet - AZ2.
Label the Application Tier subnets as Private Subnet - AZ1 and Private Subnet - AZ2.
Label the Database Tier subnets as Isolated Subnet - AZ1 and Isolated Subnet - AZ2.
Label the External ALB as External ALB and the Internal ALB as Internal ALB.
Label the RDS icons as RDS Primary and RDS Standby.

Your diagram should now show a clear flow from Users down through the Internet Gateway, External ALB, Web Tier, Internal ALB, Application Tier, and into the RDS database. Every subnet and component has a label.

Arrows pointing the wrong direction?

If an arrow points backwards, click on it to select it. Then right-click and choose Edit Style or simply delete the arrow and redraw it in the correct direction. The direction depends on which shape you start the drag from.

Help me fix arrow directions in draw.io.

Your three-tier architecture diagram is complete on the canvas. Next, you'll export it as a crisp PNG image and save the source file for future editing.

Export the Diagram

Your three-tier architecture diagram is complete with all the AWS components, subnets, and traffic flow arrows in place.

Before you can embed the diagram in your documentation, you need to export it as an image file. You'll also save the editable source file so you can update the diagram later.

In this step, get ready to:

Export your diagram as a high-resolution PNG image.
Save the draw.io source file for future editing.

Export the diagram as a PNG

PNG is the best format for diagrams on GitHub because it renders inline in your README and keeps file sizes small. draw.io also lets you embed the diagram's source data inside the PNG, so the image doubles as an editable file.

In draw.io, click File in the top menu bar.
Click Export as.
Select PNG.

An export settings dialog appears. This is where you configure the image quality and embed options.

Set Zoom to 200% for a crisp, high-resolution image.
Keep the Border at 10 pixels.
Check the Include a copy of my diagram checkbox.
Click Export.

Your browser downloads the PNG file.

If your browser prompts you for a save location, navigate to the images folder inside aws-three-tier-architecture and save it as three-tier-architecture.png.
If the file downloaded automatically, locate it in your Downloads folder and move it to aws-three-tier-architecture/images/.
Rename the file to three-tier-architecture.png if it has a different name.

What does 'Include a copy of my diagram' do?

This option embeds the draw.io source XML directly inside the PNG file. It means you can drag the PNG back into draw.io later and edit the full diagram, even without a separate source file.

The trade-off is a slightly larger file size, but it's worth it for the convenience of always having an editable copy.

Open the images folder inside aws-three-tier-architecture in Finder (macOS) or File Explorer (Windows).
You should see three-tier-architecture.png listed inside the folder.

Don't see the PNG in your images folder?

Check your Downloads folder. Most browsers save files there by default. Move the file to aws-three-tier-architecture/images/ if you find it there.
Make sure the file is named exactly three-tier-architecture.png. Some browsers add a suffix like (1) if a file with that name already exists.
If you accidentally exported as a different format, go back to draw.io and repeat the export steps above.

Still stuck? Ask for help here.

Save the source file for version control

The embedded source in the PNG is a great backup. However, keeping a dedicated .drawio file in your project makes it obvious to collaborators that the diagram is editable.

Back in draw.io, click File in the top menu bar.
Click Save as.
Name the file three-tier-architecture.drawio.
Save it to the root of your aws-three-tier-architecture folder (not inside images).
If the file downloads to your Downloads folder, move it to the root of aws-three-tier-architecture.

Why save a separate source file?

The .drawio file is a lightweight XML file that draw.io can open directly. Storing it alongside your documentation means anyone who clones the repository can update the diagram without hunting for the original.

Open the aws-three-tier-architecture folder in Finder (macOS) or File Explorer (Windows).
You should see three-tier-architecture.drawio alongside README.md and the images folder.

Can't find the .drawio file?

Check your Downloads folder. If the file ended up there, drag it into the aws-three-tier-architecture folder.
Make sure you saved it in the root of the project folder, not inside the images subfolder.

Need a hand? Ask for help here.

Your diagram is exported and your source file is saved. Next up, you'll start writing the documentation that brings this architecture to life.

Write the Documentation - Introduction and Overview

Your diagram is exported, saved, and ready to embed. Now comes the part where you turn that visual into a full documentation page.

You'll write your README using Markdown, the lightweight formatting language that GitHub renders automatically. By the end of this step, your README will have a professional structure with a title, table of contents, introduction, and your diagram front and center.

In this step, get ready to:

Add a title and table of contents to your README.
Write an introduction explaining three-tier architecture.
Embed your architecture diagram and write an overview of the design.

Add the title, table of contents, and introduction

A well-structured README starts with a clear title and a table of contents so readers can jump to any section. The table of contents uses Markdown anchor links that match the heading names you'll create throughout the document.

Open README.md in your text editor.
Paste the following title and table of contents into the empty file:

# AWS Three-Tier Architecture

## Table of Contents

- [Introduction](#introduction)
- [Architecture Diagram](#architecture-diagram)
- [Architecture Overview](#architecture-overview)
- [Web Tier (Presentation Layer)](#web-tier-presentation-layer)
- [Application Tier (Logic Layer)](#application-tier-logic-layer)
- [Database Tier (Data Layer)](#database-tier-data-layer)
- [Network Design](#network-design)
- [Security](#security)
- [Benefits](#benefits)
- [Technologies Used](#technologies-used)

What does this code do?

The # creates a top-level heading for the document title. ## creates a second-level heading for the Table of Contents section.

Each list item links to a section heading using the format [Display Text](#anchor). The anchor is the heading text in lowercase with spaces replaced by hyphens. You'll write each of these sections across this step and the next two steps.

You won't see a rendered preview yet. The next section adds the introduction content below this.

Below the Table of Contents, add the Introduction section by pasting the following:

## Introduction

Three-tier architecture is a software design pattern that separates an application into three logical layers: the presentation tier, the application tier, and the data tier. Each tier runs on its own infrastructure and can be developed, scaled, and maintained independently.

This document describes a three-tier architecture implemented on Amazon Web Services (AWS), designed for high availability, security, and scalability.

What does this section explain?

The Introduction tells the reader what three-tier architecture is and why it matters. The first paragraph defines the pattern. The second paragraph scopes the document to an AWS implementation.

This structure mirrors how professional architecture documents are written. Lead with the concept, then narrow to the specific implementation.

Save README.md.
Scroll through the file and confirm you see the # AWS Three-Tier Architecture title at the top, the Table of Contents list, and the ## Introduction heading with two paragraphs beneath it.

Headings not showing up correctly?

Make sure there is a space between the # symbols and the heading text. #Title will not render as a heading. # Title will.

Also check that each blank line between sections is truly empty. Some editors insert invisible whitespace that can break Markdown formatting.

Help me fix my Markdown headings in README.md

Embed the architecture diagram

Markdown lets you embed images using a specific syntax that points to a file path. Since you saved your diagram in the images/ folder, you can reference it with a relative path.

Below the Introduction section, add the Architecture Diagram section by pasting the following:

## Architecture Diagram

![AWS Three-Tier Architecture](./images/three-tier-architecture.png)

*Figure 1: AWS Three-Tier Architecture showing web, application, and database tiers deployed across multiple Availability Zones within a VPC.*

How does the image syntax work?

The ![alt text](path) syntax embeds an image. The text inside the square brackets is the alt text that displays if the image fails to load. The path in parentheses is the relative location of your PNG file.

The italic line below it (*Figure 1: ...*) is a caption. Wrapping text in single asterisks makes it italic in Markdown, which is the standard convention for figure captions.

Save README.md.
If your text editor has a Markdown preview feature, open it now. You should see your diagram image displayed between the Introduction and the italic caption underneath it.

Image not showing in preview?

Check that your image file is named exactly three-tier-architecture.png and is inside the images/ folder. The path ./images/three-tier-architecture.png is case-sensitive, so the file name must match exactly.

If your editor does not have a Markdown preview, that is fine. The image will render when you push the file to GitHub later.

Help me fix my image embed in README.md

Write the architecture overview

The overview section gives readers a high-level summary of the entire design before they dive into the details of each tier. It names all three tiers and describes how traffic flows between them.

Below the Architecture Diagram section, add the Architecture Overview by pasting the following:

## Architecture Overview

The architecture consists of three distinct tiers deployed within a single AWS VPC:

1. **Web Tier (Presentation Layer)** - Handles incoming user requests and serves the frontend. Deployed in public subnets.
2. **Application Tier (Logic Layer)** - Processes business logic and API requests. Deployed in private subnets.
3. **Database Tier (Data Layer)** - Stores and manages persistent data. Deployed in isolated private subnets.

Traffic flows from users through an Internet Gateway to the Web Tier via an Application Load Balancer. The Web Tier forwards API requests to the Application Tier through an Internal Load Balancer. The Application Tier reads and writes data to the Database Tier. Each tier communicates only with its adjacent tiers, enforced by security groups.

What does this section cover?

The numbered list names each tier, its responsibility, and where it sits in the network. Public subnets are internet-facing. Private subnets have no direct internet access. Isolated private subnets have no internet route at all.

The final paragraph describes the traffic flow from end to end. This is the same flow your diagram visualizes. Each tier only talks to its immediate neighbor, which is enforced by security groups. You'll document those security rules in a later step.

Save README.md.
Scroll through your file from top to bottom. You should see five distinct sections: the title, Table of Contents, Introduction, Architecture Diagram, and Architecture Overview.

Numbered list not rendering correctly?

Make sure there is a blank line before the 1. item. Markdown needs a blank line between a paragraph and a list for the list to render properly.

Also check that the bold markers ** are placed directly around the tier names with no extra spaces inside them.

Help me fix my Markdown list formatting in README.md

✔️ Awesome, I've got everything!

Great. Double check you've saved your file before moving on.

ⓧ I'd like to double check the full code

Here is the complete README.md so far. Compare it with your file and fix any differences.

# AWS Three-Tier Architecture

## Table of Contents

- [Introduction](#introduction)
- [Architecture Diagram](#architecture-diagram)
- [Architecture Overview](#architecture-overview)
- [Web Tier (Presentation Layer)](#web-tier-presentation-layer)
- [Application Tier (Logic Layer)](#application-tier-logic-layer)
- [Database Tier (Data Layer)](#database-tier-data-layer)
- [Network Design](#network-design)
- [Security](#security)
- [Benefits](#benefits)
- [Technologies Used](#technologies-used)

## Introduction

Three-tier architecture is a software design pattern that separates an application into three logical layers: the presentation tier, the application tier, and the data tier. Each tier runs on its own infrastructure and can be developed, scaled, and maintained independently.

This document describes a three-tier architecture implemented on Amazon Web Services (AWS), designed for high availability, security, and scalability.

## Architecture Diagram

![AWS Three-Tier Architecture](./images/three-tier-architecture.png)

*Figure 1: AWS Three-Tier Architecture showing web, application, and database tiers deployed across multiple Availability Zones within a VPC.*

## Architecture Overview

The architecture consists of three distinct tiers deployed within a single AWS VPC:

1. **Web Tier (Presentation Layer)** - Handles incoming user requests and serves the frontend. Deployed in public subnets.
2. **Application Tier (Logic Layer)** - Processes business logic and API requests. Deployed in private subnets.
3. **Database Tier (Data Layer)** - Stores and manages persistent data. Deployed in isolated private subnets.

Traffic flows from users through an Internet Gateway to the Web Tier via an Application Load Balancer. The Web Tier forwards API requests to the Application Tier through an Internal Load Balancer. The Application Tier reads and writes data to the Database Tier. Each tier communicates only with its adjacent tiers, enforced by security groups.

Your documentation already has a solid foundation with the title, table of contents, introduction, diagram, and overview. Next up, you'll write the detailed breakdown of each individual tier.

Write the Documentation - Tier Breakdown

Your README.md already has a solid foundation with the introduction, architecture diagram, and overview. Now it's time to zoom into each individual tier.

In this step, you'll write detailed sections for all three tiers of the architecture: Web, Application, and Database. Each section lists the specific AWS components used and explains what that tier is responsible for.

In this step, get ready to:

Document the Web Tier with its AWS components and responsibilities.
Document the Application Tier with its AWS components and responsibilities.
Document the Database Tier with its AWS components and responsibilities.

Document the Web Tier

The Web Tier is the front door of the architecture. It's the only layer that users interact with directly, so it needs to clearly explain how traffic enters the system.

In README.md, add the following markdown below the Architecture Overview section:

## Web Tier (Presentation Layer)

The Web Tier is the only layer directly accessible from the internet. It receives user requests and serves frontend content.

**AWS Components:**

- **Internet Gateway** - Provides internet access to the VPC
- **Application Load Balancer (ALB)** - Distributes incoming HTTP/HTTPS traffic across web servers
- **EC2 Instances (Auto Scaling Group)** - Hosts web servers (e.g., Nginx serving a React or static site) in public subnets across two Availability Zones
- **NAT Gateway** - Not required for this tier (instances have public IPs via the Internet Gateway)

**Responsibilities:**

- Accept and terminate HTTPS connections
- Serve static frontend content
- Forward API calls to the Application Tier via the Internal Load Balancer

Why list components and responsibilities separately?

Separating "what's in this tier" from "what this tier does" makes the documentation easier to scan. A reader can quickly find the AWS services involved, then understand the tier's role without re-reading the component list.

Notice that the NAT Gateway is explicitly listed as "not required" here. Calling out what is not needed prevents confusion for readers who might expect it in every tier.

Save README.md.
You should see the ## Web Tier (Presentation Layer) heading followed by four AWS components and three responsibilities.

Markdown list not rendering correctly?

Make sure there is a blank line before each list. Markdown requires an empty line between a paragraph (like **AWS Components:**) and the first - list item. Without it, the list renders as plain text.

Help me fix my markdown formatting in README.md

Document the Application Tier

The Application Tier is where the backend logic lives. Unlike the Web Tier, it has no direct internet exposure. This isolation is one of the biggest security benefits of three-tier architecture.

Below the Web Tier section you just added, add the Application Tier section:

## Application Tier (Logic Layer)

The Application Tier contains the backend business logic. It runs in private subnets with no direct internet access.

**AWS Components:**

- **Internal Application Load Balancer** - Routes requests from the Web Tier to application servers
- **EC2 Instances (Auto Scaling Group)** - Hosts backend application code (e.g., Node.js, Python, Java) in private subnets across two Availability Zones
- **NAT Gateway** - Allows outbound internet access for software updates and external API calls

**Responsibilities:**

- Process business logic and validate data
- Handle authentication and authorization
- Communicate with the Database Tier for data persistence
- Call external APIs when needed (via NAT Gateway)

What does the NAT Gateway do here?

The Application Tier runs in private subnets, so its EC2 instances have no public IP addresses. The NAT Gateway gives them a one-way path to the internet for things like downloading software updates or calling external APIs.

Traffic can flow out through the NAT Gateway, but nothing from the internet can initiate a connection back in. This keeps the tier protected.

Save README.md.
You should see the ## Application Tier (Logic Layer) heading followed by three AWS components and four responsibilities.

Sections looking jumbled together?

Check that there is a blank line between the end of the Web Tier section and the ## Application Tier heading. Markdown headings need a blank line above them to render properly.

Help me fix the spacing between my markdown sections

Document the Database Tier

The Database Tier is the most isolated layer in the architecture. It sits in private subnets that have no internet route at all, and only accepts connections from the Application Tier.

Below the Application Tier section, add the Database Tier section:

## Database Tier (Data Layer)

The Database Tier stores all persistent application data. It runs in isolated private subnets accessible only from the Application Tier.

**AWS Components:**

- **Amazon RDS (MySQL or PostgreSQL)** - Managed relational database service
- **Multi-AZ Deployment** - Automatic failover to a standby instance in a different Availability Zone
- **DB Subnet Group** - Ensures the database is placed in designated private subnets

**Responsibilities:**

- Store and manage application data
- Handle read/write queries from the Application Tier
- Provide automatic backups and point-in-time recovery
- Ensure high availability through Multi-AZ failover

What is Multi-AZ deployment?

Amazon RDS with Multi-AZ keeps a standby copy of your database in a different Availability Zone. If the primary instance fails, RDS automatically switches to the standby with minimal downtime.

The DB Subnet Group tells RDS which subnets it can place the primary and standby instances in. This ensures the database stays in your designated isolated private subnets.

Save README.md.
You should see the ## Database Tier (Data Layer) heading followed by three AWS components and four responsibilities.

Don't see all three tier sections?

Scroll through your README.md and confirm you have three ## headings: Web Tier, Application Tier, and Database Tier. Each should have both an "AWS Components" list and a "Responsibilities" list.

Help me check my tier documentation is structured correctly

All three tier sections are now in your README. Double check the full file matches what you expect.

✔️ Awesome, I've got everything!

Great. Double check you've saved your file before moving on.

ⓧ I'd like to double check the full code

Here is the complete README.md as it should look at this point. Compare it with yours and fix any differences.

# AWS Three-Tier Architecture

## Table of Contents

- [Introduction](#introduction)
- [Architecture Diagram](#architecture-diagram)
- [Architecture Overview](#architecture-overview)
- [Web Tier (Presentation Layer)](#web-tier-presentation-layer)
- [Application Tier (Logic Layer)](#application-tier-logic-layer)
- [Database Tier (Data Layer)](#database-tier-data-layer)
- [Network Design](#network-design)
- [Security](#security)
- [Benefits](#benefits)
- [Technologies Used](#technologies-used)

## Introduction

Three-tier architecture is a software design pattern that separates an application into three logical layers: the presentation tier, the application tier, and the data tier. Each tier runs on its own infrastructure and can be developed, scaled, and maintained independently.

This document describes a three-tier architecture implemented on Amazon Web Services (AWS), designed for high availability, security, and scalability.

## Architecture Diagram

![AWS Three-Tier Architecture](./images/three-tier-architecture.png)

*Figure 1: AWS Three-Tier Architecture showing web, application, and database tiers deployed across multiple Availability Zones within a VPC.*

## Architecture Overview

The architecture consists of three distinct tiers deployed within a single AWS VPC:

1. **Web Tier (Presentation Layer)** - Handles incoming user requests and serves the frontend. Deployed in public subnets.
2. **Application Tier (Logic Layer)** - Processes business logic and API requests. Deployed in private subnets.
3. **Database Tier (Data Layer)** - Stores and manages persistent data. Deployed in isolated private subnets.

Traffic flows from users through an Internet Gateway to the Web Tier via an Application Load Balancer. The Web Tier forwards API requests to the Application Tier through an Internal Load Balancer. The Application Tier reads and writes data to the Database Tier. Each tier communicates only with its adjacent tiers, enforced by security groups.

## Web Tier (Presentation Layer)

The Web Tier is the only layer directly accessible from the internet. It receives user requests and serves frontend content.

**AWS Components:**

- **Internet Gateway** - Provides internet access to the VPC
- **Application Load Balancer (ALB)** - Distributes incoming HTTP/HTTPS traffic across web servers
- **EC2 Instances (Auto Scaling Group)** - Hosts web servers (e.g., Nginx serving a React or static site) in public subnets across two Availability Zones
- **NAT Gateway** - Not required for this tier (instances have public IPs via the Internet Gateway)

**Responsibilities:**

- Accept and terminate HTTPS connections
- Serve static frontend content
- Forward API calls to the Application Tier via the Internal Load Balancer

## Application Tier (Logic Layer)

The Application Tier contains the backend business logic. It runs in private subnets with no direct internet access.

**AWS Components:**

- **Internal Application Load Balancer** - Routes requests from the Web Tier to application servers
- **EC2 Instances (Auto Scaling Group)** - Hosts backend application code (e.g., Node.js, Python, Java) in private subnets across two Availability Zones
- **NAT Gateway** - Allows outbound internet access for software updates and external API calls

**Responsibilities:**

- Process business logic and validate data
- Handle authentication and authorization
- Communicate with the Database Tier for data persistence
- Call external APIs when needed (via NAT Gateway)

## Database Tier (Data Layer)

The Database Tier stores all persistent application data. It runs in isolated private subnets accessible only from the Application Tier.

**AWS Components:**

- **Amazon RDS (MySQL or PostgreSQL)** - Managed relational database service
- **Multi-AZ Deployment** - Automatic failover to a standby instance in a different Availability Zone
- **DB Subnet Group** - Ensures the database is placed in designated private subnets

**Responsibilities:**

- Store and manage application data
- Handle read/write queries from the Application Tier
- Provide automatic backups and point-in-time recovery
- Ensure high availability through Multi-AZ failover

You now have detailed documentation for each tier of the architecture. Next up, you'll add the networking design, security rules, and benefits sections to tie everything together.

Write the Documentation - Networking, Security, and Benefits

Your tier-by-tier breakdown is complete. Readers now understand what each layer does and which AWS components power it.

In this step, you will tie everything together with the infrastructure details that make three-tier architecture work. You will document how the network is structured, how security groups enforce isolation between tiers, and why this pattern is worth using.

In this step, get ready to:

Write the Network Design section covering VPC, subnets, and routing.
Write the Security section documenting the security group chain.
Write the Benefits and Technologies Used sections to complete the README.

Write the Network Design section

The network design section explains how the VPC is divided into subnets and how traffic is routed between them. This is the backbone that keeps each tier isolated from the others.

In README.md, scroll to the bottom of the file (below the Database Tier section).
Add the following Network Design section:

## Network Design

The entire architecture is deployed within a single VPC with a CIDR block (e.g., 10.0.0.0/16).

**Subnet Layout:**

- **Public Subnets** (2x, one per AZ) - Host the Web Tier, Internet Gateway routes, and NAT Gateways
- **Private Subnets** (2x, one per AZ) - Host the Application Tier with route to NAT Gateway for outbound traffic
- **Isolated Private Subnets** (2x, one per AZ) - Host the Database Tier with no internet route

**Routing:**

- Public subnets route 0.0.0.0/0 traffic to the Internet Gateway
- Private subnets route 0.0.0.0/0 traffic to the NAT Gateway
- Isolated subnets have no route to the internet

What does this section cover?

This section documents the VPC's CIDR block (10.0.0.0/16) and three types of subnets. Public subnets have a route to the Internet Gateway for inbound traffic. Private subnets route outbound traffic through a NAT Gateway. Isolated subnets have no internet route at all, which is what makes the database tier truly private.

Save README.md.

You will not see a visual change yet. The next section builds on this by documenting the security rules that enforce this isolation.

Write the Security section

Network isolation only works if traffic rules enforce it. Security groups act as virtual firewalls for each tier, controlling exactly which ports and sources can communicate.

Below the Network Design section you just added, add the following Security section:

## Security

Security is enforced through a layered security group strategy following the principle of least privilege.

**Security Group Rules:**

- **Web Tier SG** - Inbound: Allow HTTP (80) and HTTPS (443) from 0.0.0.0/0. Outbound: Allow traffic to App Tier SG.
- **App Tier SG** - Inbound: Allow traffic on the application port (e.g., 3000 or 8080) from Web Tier SG only. Outbound: Allow traffic to DB Tier SG and to 0.0.0.0/0 via NAT Gateway.
- **Database Tier SG** - Inbound: Allow MySQL (3306) or PostgreSQL (5432) from App Tier SG only. Outbound: None required.

This chain ensures that the database is never directly accessible from the internet or even from the web tier. Each layer can only communicate with its immediate neighbor.

Why is the security group chain important?

Each security group only allows traffic from the tier directly above it. The Web Tier SG accepts HTTP/HTTPS from the public internet. The App Tier SG only accepts traffic from the Web Tier SG. The Database Tier SG only accepts traffic from the App Tier SG on port 3306 (MySQL) or 5432 (PostgreSQL).

This means even if someone compromises the web tier, they cannot reach the database directly. They would also need to breach the application tier first.

Save README.md.

Write the Benefits and Technologies Used sections

The final two sections summarize why three-tier architecture is worth using and list every AWS service referenced in the documentation.

Below the Security section, add the following Benefits section:

## Benefits

- **Scalability** - Each tier can be scaled independently based on its specific load. The web tier can scale separately from the application tier.
- **Security** - Network isolation ensures that a compromise in one tier does not automatically grant access to other tiers.
- **High Availability** - Multi-AZ deployment across all tiers protects against single Availability Zone failures.
- **Maintainability** - Separation of concerns allows teams to update one tier without affecting others.
- **Fault Isolation** - Issues in the application logic do not directly impact the database or frontend.

What do these benefits mean in practice?

Scalability means you can add more web servers during a traffic spike without touching the database. High availability through Multi-AZ means a single Availability Zone failure does not take down the whole application.

Fault isolation means a bug in the application tier does not corrupt your database or crash the frontend. Each tier fails independently.

Below the Benefits section, add the final Technologies Used section:

## Technologies Used

- Amazon VPC
- Internet Gateway
- NAT Gateway
- Application Load Balancer (ALB)
- Amazon EC2 with Auto Scaling Groups
- Amazon RDS (MySQL/PostgreSQL)
- Security Groups
- Multiple Availability Zones

Why include a Technologies Used section?

This gives readers a quick reference of every AWS service covered in the documentation. It is especially helpful for reviewers or hiring managers skimming your repository to see what you have worked with.

Save README.md.
Scroll through the entire file from top to bottom. You should see all ten sections in order: Title, Table of Contents, Introduction, Architecture Diagram, Architecture Overview, Web Tier, Application Tier, Database Tier, Network Design, Security, Benefits, and Technologies Used.

Sections look out of order?

Make sure each section starts with a ## Heading (two hashes followed by a space). A missing hash or extra space can break the heading hierarchy.

Check that the Table of Contents anchor links match the heading text exactly. For example, [Network Design](#network-design) must match ## Network Design.

Help me troubleshoot my README formatting

✔️ Awesome, I've got everything!

Great. Double check you have saved README.md. Your documentation is complete and ready to push to GitHub.

ⓧ I'd like to double check the full code

Here is the complete README.md file. Compare it against yours to make sure nothing is missing.

# AWS Three-Tier Architecture

## Table of Contents

- [Introduction](#introduction)
- [Architecture Diagram](#architecture-diagram)
- [Architecture Overview](#architecture-overview)
- [Web Tier (Presentation Layer)](#web-tier-presentation-layer)
- [Application Tier (Logic Layer)](#application-tier-logic-layer)
- [Database Tier (Data Layer)](#database-tier-data-layer)
- [Network Design](#network-design)
- [Security](#security)
- [Benefits](#benefits)
- [Technologies Used](#technologies-used)

## Introduction

Three-tier architecture is a software design pattern that separates an application into three logical layers: the presentation tier, the application tier, and the data tier. Each tier runs on its own infrastructure and can be developed, scaled, and maintained independently.

This document describes a three-tier architecture implemented on Amazon Web Services (AWS), designed for high availability, security, and scalability.

## Architecture Diagram

![AWS Three-Tier Architecture](./images/three-tier-architecture.png)

*Figure 1: AWS Three-Tier Architecture showing web, application, and database tiers deployed across multiple Availability Zones within a VPC.*

## Architecture Overview

The architecture consists of three distinct tiers deployed within a single AWS VPC:

1. **Web Tier (Presentation Layer)** - Handles incoming user requests and serves the frontend. Deployed in public subnets.
2. **Application Tier (Logic Layer)** - Processes business logic and API requests. Deployed in private subnets.
3. **Database Tier (Data Layer)** - Stores and manages persistent data. Deployed in isolated private subnets.

Traffic flows from users through an Internet Gateway to the Web Tier via an Application Load Balancer. The Web Tier forwards API requests to the Application Tier through an Internal Load Balancer. The Application Tier reads and writes data to the Database Tier. Each tier communicates only with its adjacent tiers, enforced by security groups.

## Web Tier (Presentation Layer)

The Web Tier is the only layer directly accessible from the internet. It receives user requests and serves frontend content.

**AWS Components:**

- **Internet Gateway** - Provides internet access to the VPC
- **Application Load Balancer (ALB)** - Distributes incoming HTTP/HTTPS traffic across web servers
- **EC2 Instances (Auto Scaling Group)** - Hosts web servers (e.g., Nginx serving a React or static site) in public subnets across two Availability Zones
- **NAT Gateway** - Not required for this tier (instances have public IPs via the Internet Gateway)

**Responsibilities:**

- Accept and terminate HTTPS connections
- Serve static frontend content
- Forward API calls to the Application Tier via the Internal Load Balancer

## Application Tier (Logic Layer)

The Application Tier contains the backend business logic. It runs in private subnets with no direct internet access.

**AWS Components:**

- **Internal Application Load Balancer** - Routes requests from the Web Tier to application servers
- **EC2 Instances (Auto Scaling Group)** - Hosts backend application code (e.g., Node.js, Python, Java) in private subnets across two Availability Zones
- **NAT Gateway** - Allows outbound internet access for software updates and external API calls

**Responsibilities:**

- Process business logic and validate data
- Handle authentication and authorization
- Communicate with the Database Tier for data persistence
- Call external APIs when needed (via NAT Gateway)

## Database Tier (Data Layer)

The Database Tier stores all persistent application data. It runs in isolated private subnets accessible only from the Application Tier.

**AWS Components:**

- **Amazon RDS (MySQL or PostgreSQL)** - Managed relational database service
- **Multi-AZ Deployment** - Automatic failover to a standby instance in a different Availability Zone
- **DB Subnet Group** - Ensures the database is placed in designated private subnets

**Responsibilities:**

- Store and manage application data
- Handle read/write queries from the Application Tier
- Provide automatic backups and point-in-time recovery
- Ensure high availability through Multi-AZ failover

## Network Design

The entire architecture is deployed within a single VPC with a CIDR block (e.g., 10.0.0.0/16).

**Subnet Layout:**

- **Public Subnets** (2x, one per AZ) - Host the Web Tier, Internet Gateway routes, and NAT Gateways
- **Private Subnets** (2x, one per AZ) - Host the Application Tier with route to NAT Gateway for outbound traffic
- **Isolated Private Subnets** (2x, one per AZ) - Host the Database Tier with no internet route

**Routing:**

- Public subnets route 0.0.0.0/0 traffic to the Internet Gateway
- Private subnets route 0.0.0.0/0 traffic to the NAT Gateway
- Isolated subnets have no route to the internet

## Security

Security is enforced through a layered security group strategy following the principle of least privilege.

**Security Group Rules:**

- **Web Tier SG** - Inbound: Allow HTTP (80) and HTTPS (443) from 0.0.0.0/0. Outbound: Allow traffic to App Tier SG.
- **App Tier SG** - Inbound: Allow traffic on the application port (e.g., 3000 or 8080) from Web Tier SG only. Outbound: Allow traffic to DB Tier SG and to 0.0.0.0/0 via NAT Gateway.
- **Database Tier SG** - Inbound: Allow MySQL (3306) or PostgreSQL (5432) from App Tier SG only. Outbound: None required.

This chain ensures that the database is never directly accessible from the internet or even from the web tier. Each layer can only communicate with its immediate neighbor.

## Benefits

- **Scalability** - Each tier can be scaled independently based on its specific load. The web tier can scale separately from the application tier.
- **Security** - Network isolation ensures that a compromise in one tier does not automatically grant access to other tiers.
- **High Availability** - Multi-AZ deployment across all tiers protects against single Availability Zone failures.
- **Maintainability** - Separation of concerns allows teams to update one tier without affecting others.
- **Fault Isolation** - Issues in the application logic do not directly impact the database or frontend.

## Technologies Used

- Amazon VPC
- Internet Gateway
- NAT Gateway
- Application Load Balancer (ALB)
- Amazon EC2 with Auto Scaling Groups
- Amazon RDS (MySQL/PostgreSQL)
- Security Groups
- Multiple Availability Zones

Your README.md is now complete with all ten sections. You have a professional architecture document covering components, networking, security, and benefits. Go ahead and push it to a public GitHub repository so you can share it with a link.

Publish to GitHub

Your documentation is complete and your diagram is ready. The final step is publishing everything to GitHub so others can access it through a simple link.

GitHub renders README.md files directly on a repository's homepage. By uploading your project to a public repository, your documentation becomes a shareable web page with the embedded diagram displayed inline.

In this step, get ready to:

Create a public GitHub repository.
Upload your project files to the repository.
Verify the README renders with the embedded architecture diagram.

Create a public repository on GitHub

You need a public repository to host your files. Anyone with the repository link will be able to read your documentation and view the diagram.

Open your browser and go to github.com.
Click the + icon in the top-right corner of the page.
Click New repository.
Enter aws-three-tier-architecture in the Repository name field.
Select Public for the repository visibility.
Leave all initialization checkboxes unchecked. Do not check Add a README file since you already have your own.
Click Create repository.

GitHub shows you an empty repository page with setup instructions. You will use this page in the next substep.

Why make it public?

A public repository lets anyone view your documentation through a direct link. This is ideal for sharing your architecture design with teammates, interviewers, or the broader community.

Upload your project files

The empty repository page includes a link to upload files directly through the browser. This avoids needing to install any additional tools.

On the empty repository page, find the line that says "Get started by creating a new file or uploading an existing file."
Click the uploading an existing file link.
Open Finder (macOS) or File Explorer (Windows) and navigate to the aws-three-tier-architecture folder on your Desktop.
Drag and drop the following three items into the GitHub upload area:

Why upload the .drawio file?

The .drawio source file lets you or a teammate reopen the diagram in draw.io and edit it later. Keeping it in the repository means the diagram source is version-controlled alongside the documentation.

Confirm the upload area shows all three items: README.md, three-tier-architecture.drawio, and images/three-tier-architecture.png.
Scroll down to the Commit changes section at the bottom of the page.
Enter Add three-tier architecture documentation in the commit message field.
Click Commit changes.

GitHub redirects you to the repository homepage. Scroll down past the file list to see your rendered README.

Verify the README renders correctly

Your repository homepage should now display the full documentation with the architecture diagram embedded.

Scroll through the rendered README and confirm that all sections are visible: Introduction, Architecture Diagram, Architecture Overview, the three tier breakdowns, Network Design, Security, Benefits, and Technologies Used.
Check that the architecture diagram image displays in the Architecture Diagram section. You should see your full three-tier diagram rendered inline.
Click the images folder in the file list at the top to confirm three-tier-architecture.png is inside it.
Copy the URL from your browser's address bar. This is your shareable link.

Diagram image not showing?

Click the images folder in the file list to make sure three-tier-architecture.png is inside it. If the PNG was uploaded to the root instead of inside images/, the image path in your README won't match.

The image path in your README.md is ./images/three-tier-architecture.png. Make sure the folder name and file name match exactly, including capitalization.

If the file ended up in the wrong location, delete it from the repository and re-upload the images folder by dragging it into the upload area again.

Why isn't my diagram image showing in my GitHub README?

What about the Table of Contents?

GitHub automatically generates a clickable table of contents from your Markdown headings. Look for the small outline icon (three horizontal lines) near the top of the rendered README. Clicking it shows a navigation sidebar built from your heading structure.

Your documentation is live and shareable. Anyone with that link can now read your architecture documentation and view the diagram. Next, take on the Secret Mission to add cost estimation and a data flow diagram for extra depth.

Secret mission

Add Cost Estimation and Data Flow Diagram

Your documentation covers the architecture design, but real-world stakeholders want to know more. How much will this actually cost to run? And how does a single user request travel through the entire system? Add cost breakdowns, a data flow diagram, and improvement recommendations to make your documentation production-ready.

Before you go

Clean Up Your Resources

This project runs entirely on your local machine and uses free browser-based tools, so there are no ongoing costs. Decide whether to keep your resources as they are, or delete them if you no longer need them.

Resources you used:

Local aws-three-tier-architecture folder containing README.md, images/ subfolder, and .drawio source file.
Exported three-tier-architecture.png diagram in the images/ folder.
Public GitHub repository hosting the documentation.
draw.io diagram saved in browser storage (if you chose "Browser" storage) or on your device.

Keep everything running

No action needed. Choose this if you want to keep your documentation available on GitHub and your local files intact for future updates.

Your GitHub repository stays public and shareable.
Your local files remain in the aws-three-tier-architecture folder on your Desktop.
The .drawio source file stays editable if you want to update your diagram later.

Pause - I'll come back to this later

Since this project uses only local files and a free GitHub repository, there is nothing to pause. Your resources are already idle and cost nothing.

If you want to hide the repository temporarily, go to your repository on GitHub, click Settings, scroll to the Danger Zone section, and click Change visibility to make it private.
Your local files stay on your machine and take up minimal disk space.

Delete - I don't want to use this again

Remove all project resources from your machine and GitHub.

Delete the aws-three-tier-architecture folder from your Desktop.
On GitHub, go to your repository, click Settings, scroll to the Danger Zone section, and click Delete this repository.
If you saved a diagram in draw.io's browser storage, open app.diagrams.net and delete any saved diagrams from your browser.

Mission accomplished

You Did It!

Nice work! You have created professional cloud architecture documentation from scratch.

You've learned how to:

Build a three-tier architecture diagram using official AWS icons in draw.io.
Write structured Markdown documentation covering all three tiers, networking, and security design.
Publish your documentation to a public GitHub repository with a shareable link.
Secret Mission: Add a cost estimation section and a data flow diagram for extra depth.

Ready to quiz yourself?