Document Your 3-Tier AWS Architecture

Create C4 diagrams and incident runbooks for a 3-tier AWS app.

Introduction

30 Second Summary

When a system breaks at 2 AM, the first thing everyone reaches for is the documentation. If it doesn't exist, the only person who can fix anything is the person who built it.

In this project, you will create professional architecture diagrams and an incident runbook for a 3-tier AWS application using draw.io and Markdown.

What You'll Build

Show your finished diagrams to any engineer and they understand your entire system in 30 seconds. Hand them your runbook and they can resolve an outage without asking you a single question.

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

A multi-page architecture diagram in draw.io documenting an ALB + EC2 + RDS application using the C4 model, with proper AWS icons, color-coded boundaries, and labeled data flows with protocols and port numbers.
A structured incident runbook in Markdown that walks any team member through diagnosing and resolving a web server outage, complete with AWS Console navigation paths and a decision table.
A repeatable documentation process you can apply immediately to document real projects at work.
Secret Mission: Write a second runbook for database connection failures and add clickable cross-page navigation between your diagram levels.

Are there any prerequisites?

None. This project includes setup for all tools. Familiarity with what a 3-tier web app does (web server, application code, database) is helpful but not required.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

Set Up draw.io and Enable AWS Shape Libraries

Before you can draw any architecture diagrams, you need a diagramming tool loaded with the correct shape libraries. Without the right shapes enabled, you will waste time searching for components or resort to generic boxes that no one recognizes.

In this step, you will open draw.io in your browser and enable two shape libraries: AWS service icons (for your ALB, EC2, and RDS shapes) and C4 model shapes (for structuring your diagrams into proper abstraction levels).

In this step, get ready to:

Open draw.io and create a new diagram file saved to your local machine.
Enable the AWS19 shape library for official AWS service icons.
Enable the C4 shape library for architecture documentation shapes.

Open draw.io and create your diagram file

draw.io is a free, browser-based diagramming tool that requires no account or installation. You will save your work directly to your Linux machine.

Open your browser and navigate to app.diagrams.net.
A storage selection dialog appears asking where to save your files. Click Device.

Why Device storage?

Selecting Device saves your diagram files directly to your local machine. No cloud account or sign-in is needed.

A Create New Diagram dialog appears with a filename field at the top and template options below.
Type 3-tier-architecture in the filename field (the .drawio extension is added automatically).
Make sure Blank Diagram is selected as the template.
Click Create.

You now see a blank canvas with a grid. The left panel shows a default set of basic shapes, and the bottom of the canvas shows a single page tab.

Don't see the storage dialog?

If you have visited draw.io before, it may remember your previous storage choice. Look for a small gear icon or Change storage link in the bottom-left corner of the editor to switch to Device.

help me switch my draw.io storage to Device

Enable the AWS19 shape library

The default shape panel only has generic shapes like rectangles and arrows. You need official AWS service icons so your diagrams are instantly recognizable to anyone who works with AWS.

In the left panel, click + More Shapes at the bottom.
A dialog opens showing shape library categories. Scroll down to the Networking section.
Check the box next to AWS19.
Click Apply.

The left panel now shows AWS19 sub-categories. Expand Compute to see EC2 icons, expand Database to see RDS icons, and expand Networking and Content Delivery to see load balancer icons.

Why AWS19 and not a newer library?

draw.io offers multiple AWS shape sets sorted by year. AWS19 is the most established library with clearly categorized sub-categories and contains all the core service icons (EC2, RDS, Elastic Load Balancing) you need for this project.

Don't see AWS sub-categories in the left panel?

Make sure you clicked Apply after checking the AWS19 box. If you closed the dialog without applying, the library will not load. Click + More Shapes again and repeat the steps.

help me enable AWS shape libraries in draw.io

Enable the C4 shape library

The C4 model provides a standard set of shapes for architecture documentation: Person, Software System, Container, and Component. These shapes carry built-in metadata fields that make your diagrams self-documenting.

Click + More Shapes at the bottom of the left panel again.
Scroll to the Software section.
Check the box next to C4.
Click Apply.

The left panel now also shows a C4 section with shapes labeled Person, Software System, Container, and Component.

What are these C4 shapes for?

Each shape represents a different zoom level of your architecture. Person is an actor who uses your system. Software System is the highest-level box (your entire application). Container is a deployable unit inside the system (a server, a database). Component is a module inside a container.

You will use Person, Software System, and Container in this project.

Verify your shape libraries loaded correctly

Before moving on, confirm that both libraries are working. What do you expect to see if you drag a shape onto the canvas?

In the left panel, expand the AWS19 section, then expand Compute.
Drag any EC2 icon onto the canvas. You should see the official orange EC2 icon appear on your grid.
Now scroll to the C4 section in the left panel.
Drag a Person shape onto the canvas. You should see a stick-figure shape with a label field.
Select both shapes and press Delete or Backspace to clear the canvas for the next step.

Your canvas is blank again, but your left panel shows both AWS19 sub-categories and C4 shapes ready to use.

Shapes appear as blank rectangles?

This can happen if your browser cache is stale. Try a hard refresh: press Ctrl+Shift+R to reload without cache. Your diagram file and enabled libraries will persist.

help me fix blank shapes in draw.io

Your diagramming workspace is ready. Next up, you will draw your first architecture diagram and see firsthand why putting everything on one page creates a problem.

Draw Your First Architecture Diagram (The Naive Version)

Your diagramming workspace is ready with AWS and C4 shapes loaded. Now it's time to get the architecture out of your head and onto the canvas.

Your instinct will be to draw everything on one diagram. In this step, you'll follow that instinct on purpose and discover firsthand why it falls short.

In this step, get ready to:

Place AWS service icons (ALB, EC2, RDS) on the canvas and connect them with labeled arrows.
Add VPC and subnet boundaries with security details.
Evaluate whether your single-page diagram works for different audiences.

Place your core AWS components and connect them

A 3-tier architecture has three layers: a load balancer that receives user traffic, an application server that processes requests, and a database that stores data. You'll place an icon for each layer plus an actor representing the end user.

In the left panel, expand the AWS19 section and click Networking and Content Delivery.
Search for Elastic Load Balancing in that sub-category and drag the ALB icon onto the canvas.
Expand the Compute sub-category and drag an EC2 icon onto the canvas to the right of the ALB.
Expand the Database sub-category and drag an RDS icon onto the canvas to the right of EC2.
Add an End User actor. You can use a rectangle or drag a stick-figure shape from the General shapes at the top of the left panel. Place it to the far left of the canvas.

You should now see four shapes on the canvas arranged left to right: End User, ALB, EC2, and RDS.

Draw a connector from End User to the ALB. Hover over the End User shape until you see blue connection points appear, then click and drag from a blue point to the ALB.
Double-click the connector line and type HTTPS to label it.
Draw a connector from ALB to EC2 and label it HTTP.
Draw a connector from EC2 to RDS and label it MySQL TCP :3306.

Your canvas now shows the full traffic flow: End User connects via HTTPS to the ALB, the ALB forwards via HTTP to EC2, and EC2 queries RDS over MySQL.

Connector not attaching to the shape?

Make sure you start the drag from one of the blue connection points on the source shape's edge. If you start from the middle of the shape, draw.io may move the shape instead of drawing a connector.

Help me connect shapes with arrows in draw.io

Add infrastructure boundaries and network details

The shapes alone don't show where these services live in the network. A VPC boundary with subnets tells an engineer which components are publicly accessible and which are isolated. You'll add these boundaries now.

From the General shapes at the top of the left panel, drag a large rectangle onto the canvas. Resize it to surround the ALB, EC2, and RDS shapes (but not the End User).
Double-click the rectangle and label it VPC.
Drag a smaller rectangle inside the VPC. Position it around the ALB and EC2 shapes. Label it Public Subnet.
Drag another rectangle inside the VPC around the RDS shape. Label it Private Subnet.

Your diagram now shows the network topology. The ALB and EC2 sit in the public subnet (internet-accessible) while RDS is isolated in the private subnet.

Add more details to make the diagram comprehensive. Add text labels or small rectangles for: security groups on each service, an Internet Gateway at the VPC edge, and route tables.
Add port numbers to each service. Double-click the ALB shape and add :443 in its label. Add :80 to EC2 and :3306 to RDS.
Press Ctrl+S to save your diagram.

Shapes hiding behind rectangles?

If your boundary rectangles cover your AWS icons, right-click the rectangle and select Edit Style. Add fillColor=none to make it transparent. You can also right-click and select To Back to send the rectangle behind your icons.

Evaluate your diagram for clarity

Your diagram is technically complete. Every component, boundary, protocol, and port number is documented on a single page. Now ask yourself a question before reading further.

If a new team member saw this diagram with zero context, could they tell in 5 seconds what this system does at a high level? Could your CTO use this same diagram to understand the business value?

The answer is no. Your diagram is accurate, but it tries to serve two completely different audiences on one page. A manager wants to know "what does this system do and who uses it." A developer wants to know "what ports, what protocols, what subnets." One page cannot serve both without overwhelming one audience or under-serving the other.

Why does one diagram fail?

This is the exact problem the C4 model was designed to solve. Instead of cramming everything onto one page, C4 separates documentation into levels of detail. Each level answers a different question for a different audience.

Level 1 (System Context) answers: "What does this system do and who uses it?" Level 2 (Container) answers: "How is it built internally?" Your next two steps will create one diagram for each level.

You've proven the point: a technically correct diagram can still fail at its job if it tries to serve everyone at once. In the next step, you'll create a proper System Context diagram that answers the high-level question cleanly.

Create a Proper System Context Diagram (C4 Level 1)

You now have a diagram with every component on one page. It is technically correct, but it tries to answer two different questions for two different audiences at once.

The C4 model fixes this by separating levels of detail onto different pages. The System Context diagram is the highest level: it shows your system as a single box and focuses on who uses it and what external systems it depends on. This is the diagram your manager or a new hire sees first.

In this step, get ready to:

Add a new page to your diagram and place C4 Person and Software System shapes.
Connect shapes with labeled arrows and add an external system (AWS CloudWatch).
Add a legend and title to make the diagram self-explanatory.

Add a new page and place the core shapes

The System Context diagram keeps things at the highest possible altitude. It shows who uses your system, your system as one box, and what it depends on. No internal details.

Click the + tab at the bottom of the canvas to add a new page.
Double-click the new page tab to rename it.
Type System Context and press Enter.
In the left panel, expand the C4 section.
Drag a Person shape onto the canvas.
Double-click it and set the label to End User with the description Accesses the application via web browser.
Drag a Software System shape onto the canvas to the right of or below the Person.
Double-click it and set the label to 3-Tier Web Application with the description Serves web content, processes requests, stores data. Hosted on AWS.

You should now see two shapes on the canvas: a stick-figure Person and a blue box representing your entire system.

Why is the system just one box?

The System Context diagram deliberately hides all internal details. Its job is to answer "what does this system do and who interacts with it?" in 10 seconds flat.

The ALB, EC2, and RDS details you drew in Step 2 will reappear in the Container diagram on the next page. Separating levels of detail means each page serves exactly one audience.

Connect shapes and add the external system

Arrows show how data flows between actors and systems. You also need to show external dependencies. In C4 convention, anything outside your scope gets a grey fill.

Hover over the edge of the End User shape until you see a blue arrow appear, then drag it to the 3-Tier Web Application shape to create a connector.
Double-click the connector and label it Visits website [HTTPS].
Drag another Software System shape from the C4 section onto the canvas, positioned below or to the right of your web application.
Double-click it and set the label to AWS CloudWatch with description Monitoring and alerting.
Select the AWS CloudWatch shape. In the Style tab on the right panel, change the fill color to grey.

What does the grey fill mean?

In C4 convention, grey marks a system as out-of-scope. It exists and your system talks to it, but it is not something you build or own. This visual cue tells readers immediately which boxes are yours to worry about.

Draw a connector from the 3-Tier Web Application shape to the AWS CloudWatch shape.
Select the new connector. In the Style tab on the right panel, change the line style to dashed.
Double-click the dashed connector and label it Sends metrics and logs.

Your canvas now has three shapes and two connectors. One solid arrow shows user requests. One dashed arrow shows data flowing out to a monitoring service.

Connector keeps snapping to the wrong shape?

Zoom in before dragging. Make sure you start the drag from the edge of the source shape (a blue arrow icon appears) and release on the target shape. If it connects to the wrong shape, click the connector, then drag its endpoint to the correct shape.

help me fix my connector in draw.io

Add a legend and title

A diagram without a legend forces readers to guess what colors and line styles mean. A legend makes your diagram self-explanatory to anyone who opens it.

Drag a plain rectangle shape from the General shapes section into the bottom-right corner of the canvas.
Double-click the rectangle and type the following legend text:

Blue = your system
Grey = external system
Solid arrow = user request
Dashed arrow = data flow

Resize the rectangle so all four lines are visible without clipping.
Add a text label at the top of the canvas. Double-click an empty area at the top, then type System Context: 3-Tier Web Application.
Below the title, add a second text label with today's date (e.g. 2026-08-09).
Press Ctrl+S to save your diagram.

Why add a date stamp?

Architecture changes over time. A date stamp tells future readers whether this diagram reflects the current system or an older version. It is a small habit that separates professional documentation from one-off sketches.

Before you look at your finished page, predict: could a non-technical person read this diagram in 10 seconds and explain what the system does?

Step back and look at your System Context page. You should see exactly 3 shapes: End User, your system, and AWS CloudWatch. A non-technical person can read it and understand: users access a web application that sends data to CloudWatch. No AWS service details, no subnets, no ports.

Now click the first page tab at the bottom to compare your naive diagram side-by-side with the System Context. The difference in clarity is the entire point of the C4 model.

Page looks cluttered or hard to read?

If you have more than 3 shapes (plus the legend), you have added too much detail. Remove any AWS service icons, subnet rectangles, or port numbers. Those belong on the Container diagram page you will create next.

help me simplify my C4 System Context diagram

Your System Context page answers the "what" question for managers and new hires. Next, you will zoom into that blue box and reveal the internal architecture for developers and ops engineers.

Create the Container Diagram (C4 Level 2)

Your System Context diagram answers the question "what does this system do?" for managers and new hires. But a developer or ops engineer joining your team needs more detail. They need to see which AWS services run, how they connect over the network, and where the security boundaries sit.

The Container diagram zooms into the blue "3-Tier Web Application" box from your System Context and reveals the moving parts inside. You will build this on a new page, keeping the separation of abstraction levels that makes the C4 model powerful.

In this step, get ready to:

Draw VPC and subnet boundaries with color-coded fills.
Place AWS service icons (ALB, EC2, RDS) and connect them with labeled data flows.
Add professional polish: a legend, title, date stamp, and metadata on shapes.

Add a new page and draw the network boundaries

The Container diagram lives on its own page, just like the System Context. The first thing to draw is the network infrastructure that everything else sits inside.

Click the + tab at the bottom of the canvas to add a new page.
Double-click the new page tab to rename it Container Diagram.
Drag a large rectangle from the General shapes in the left panel onto the center of the canvas.
With the rectangle selected, find the Style tab in the right panel and check Dashed to set the border to a dashed line.
Double-click the rectangle and type VPC (10.0.0.0/16) as the label.
Drag a smaller rectangle inside the VPC boundary.
Set its fill color to light blue using the fill color picker in the Style tab.
Double-click it and type Public Subnet (10.0.1.0/24).

Your VPC boundary and public subnet are now visible on the canvas. Two more shapes complete the boundaries.

Drag another rectangle inside the VPC, positioned next to the public subnet.
Set its fill color to light orange using the same fill color picker.
Label it Private Subnet (10.0.2.0/24).
From the C4 section in the left panel, drag a Person shape and place it outside the VPC boundary to the left.
Label it End User.

Your canvas now shows the VPC as a dashed boundary containing a light-blue public subnet and a light-orange private subnet, with End User sitting outside.

Why dashed boundaries and colored fills?

The dashed line signals that the VPC is a logical grouping, not a physical component. Color-coding subnets lets a reader instantly tell public-facing from private infrastructure without reading every label.

Place AWS service icons and connect the data flow

With boundaries drawn, you can now populate each subnet with the actual AWS services and show how traffic flows between them.

In the left panel, expand the AWS19 section and find Networking and Content Delivery.
Search for or scroll to the Elastic Load Balancing icon (the ALB icon) and drag it inside the Public Subnet.
Label it Application Load Balancer.
Expand Compute under AWS19 and drag the EC2 icon inside the Public Subnet, to the right of the ALB.
Label it EC2 Instance - Web/App Server (Node.js).
Expand Database under AWS19 and drag the RDS icon inside the Private Subnet.
Label it RDS - PostgreSQL Database.

All three services are now placed in the correct subnets. Next, connect them with labeled arrows showing the data flow.

Draw a connector from the End User shape to the Application Load Balancer.
Double-click the connector and label it HTTPS :443.
Draw a connector from the ALB to the EC2 instance.
Label it HTTP :80.
Draw a connector from the EC2 instance to the RDS database.
Label it PostgreSQL :5432.

Your diagram now shows the full traffic path from user to database, with protocol and port on every connection.

Why label arrows with protocols and ports?

When an incident happens at 2 AM, the on-call engineer needs to know instantly which ports to check in security group rules. Labeled arrows eliminate guesswork and make your diagram actionable, not just decorative.

Connector won't attach to a shape?

Make sure you drag from the edge of the source shape (a blue arrow appears when you hover) to the edge of the target shape. If the connector floats freely, it is not anchored to either shape. Delete it and try again, waiting for the blue connection point to appear before releasing.

Help me fix connector issues in draw.io

Add professional polish with a legend, title, and metadata

A polished diagram communicates not just the architecture but also the notation conventions you are using. A legend, title, and date stamp turn a personal sketch into a team-ready document.

Draw a small rectangle in the bottom-right corner of the canvas.
Inside it, type a legend explaining your notation: "Light blue = Public Subnet, Light orange = Private Subnet, Dashed border = VPC boundary, Solid arrow = data flow with protocol."
Add a text label at the top of the canvas with the title Container Diagram: 3-Tier Web Application.
Below the title, add a date stamp with today's date.

Now add metadata to the EC2 shape. Metadata lets shapes carry machine-readable information that appears as a tooltip on hover.

Right-click the EC2 Instance shape.
Select Edit Data from the context menu.
In the dialog, type Instance Type in the property name field.
Click Add Property.
In the value field next to Instance Type, type t3.micro.
Click Apply to save the metadata.

What does metadata on a shape do?

When you hover over the EC2 shape, a tooltip displays the metadata you just added. This demonstrates that diagrams can carry structured data beyond labels.

In production, teams use metadata for instance sizes, cost centers, team ownership, and more.

Hover over the EC2 shape to confirm the tooltip shows Instance Type: t3.micro.

Tooltip not showing on hover?

If the shape already has a tooltip property defined, draw.io shows only that tooltip text and hides other metadata. Right-click the EC2 shape, select Edit Data again, and delete any pre-existing tooltip property by clicking the cross next to it.

Help me fix the metadata tooltip in draw.io

Before you move on, take a moment. What do you think you will notice if you switch between your naive diagram from Step 2 and this Container Diagram?

Click on your first page tab (the naive diagram) and compare. The same architectural information is present, but your Container Diagram is clearly scoped to one audience (developers and ops), color-coded by network zone, and labeled with actionable port numbers. A new team member can parse it in seconds instead of squinting at a cluttered single page.

Your diagram file now has three pages, each serving a different purpose and audience. Next up, you will write a structured incident runbook that connects directly to these diagrams.

Write the Incident Runbook

Your diagrams show what the system looks like, but they do not tell anyone what to DO when the system breaks at 2 AM.

A runbook is the instruction manual for incidents. Without one, only the person who built the system can fix it. That single-point-of-failure risk is exactly what companies hire documentation skills to eliminate. In this step, you will write a structured runbook in Markdown that any teammate could follow to resolve a web server outage without waking you up.

In this step, get ready to:

Create a Markdown runbook file with a clear title and symptom description.
Write diagnosis steps with specific AWS Console navigation paths.
Build a resolution decision table and an escalation procedure.

Create the runbook file and symptom section

Every runbook starts with metadata (who wrote it, when, which system it covers) and a symptom section that tells the on-call engineer exactly what triggers this runbook.

Open your text editor (any editor works: VS Code, nano, gedit, or your preferred choice).
Create a new file and save it as runbook-web-server-down.md on your Desktop.
Add the following header and symptom section to your file:

# Runbook: Web Server Unreachable

Last updated: 2026-08-09
Author: [Your Name]
Related architecture: 3-tier-architecture.drawio (Container Diagram page)

## Symptom

Users report the site is unreachable or returning 502/503 errors.
The ALB health checks are failing for one or more EC2 targets.

What does this section do?

The title names the specific failure scenario. The metadata (date, author, related architecture) connects this runbook to your diagram so engineers can cross-reference.

The Symptom section answers: "How do I know this runbook applies to my current incident?" It describes observable signals (error codes, health check failures) rather than root causes.

Save runbook-web-server-down.md.
Confirm the file has a level-1 heading, three metadata lines, and a Symptom section with two lines describing the observable problem.

File not saving as Markdown?

Make sure the filename ends in .md and not .md.txt. Some editors append .txt by default. If using a graphical editor, look for a "Save as type" dropdown and select "All Files" before saving.

help me save a Markdown file correctly on Linux

Write the diagnosis, resolution, and escalation sections

The operational core of a runbook is a step-by-step diagnosis that tells the engineer exactly where to look in the AWS Console, followed by a decision table that maps each finding to an action.

Below your Symptom section in runbook-web-server-down.md, add the following Diagnosis Steps, Resolution table, and Escalation sections:

## Diagnosis Steps

1. Open AWS Console > EC2 > Target Groups. Select your target group. Click the Targets tab. Check if the EC2 instance is marked "unhealthy."
2. If unhealthy: Open EC2 > Instances. Check the instance State (running/stopped/terminated).
3. If running but unhealthy: SSH into the instance and check if the application process is running (`systemctl status your-app` or `ps aux | grep node`).
4. Check CloudWatch metrics for the instance: CPU utilization > 90% or StatusCheckFailed = 1 indicates a resource or hardware issue.

## Resolution

| Scenario | Action |
|----------|--------|
| Instance stopped | Start the instance: EC2 Console > select instance > Actions > Start Instance |
| Instance running, app crashed | SSH in and restart: `sudo systemctl restart your-app` |
| Instance unresponsive (StatusCheckFailed) | Terminate the instance. If Auto Scaling is configured, a replacement launches automatically. If not, launch a new instance from your AMI. |
| All instances healthy but site still down | Check ALB listener rules and security group inbound rules (port 443 must be open to 0.0.0.0/0) |

## Escalation

If unresolved after 15 minutes, escalate to the on-call senior engineer.
Include in your escalation message:
- Which diagnosis steps you completed
- What you observed at each step
- Any changes made

What does each section do?

The Diagnosis Steps use numbered items with specific AWS Console navigation paths. Each step tells the engineer exactly where to click, not just "check the instance."

The Resolution section is a decision table. An engineer matches their finding in the left column and reads the action in the right column. No guesswork needed.

The Escalation section sets a time boundary (15 minutes) and requires a structured handoff message. This prevents vague escalations that waste the next responder's time.

Save runbook-web-server-down.md.
Scroll through the file from top to bottom. You should see four distinct sections: Symptom, Diagnosis Steps, Resolution (as a table), and Escalation.

Table not rendering properly?

Markdown tables require the header separator row (|----------|--------|) immediately after the header row. Make sure there is no blank line between them. Each row must have the same number of | characters.

help me fix my Markdown table formatting

✔️ Awesome, I've got everything!

Great. Double check you have saved your file and all four sections are present in order.

ⓧ I'd like to double check the full code

Your complete runbook-web-server-down.md should contain these sections in order. Scroll through your file and confirm each one is present:

Level-1 heading "Runbook: Web Server Unreachable" followed by Last updated, Author, and Related architecture metadata lines.
"## Symptom" section with two lines describing 502/503 errors and ALB health check failures.
"## Diagnosis Steps" section with 4 numbered steps including AWS Console paths.
"## Resolution" section with a 4-row Markdown table mapping scenarios to actions.
"## Escalation" section with a 15-minute threshold and a 3-item escalation message template.

Apply the 2 AM test to your runbook

The real quality bar for any runbook is this: could a teammate who has never seen this system before follow it at 2 AM, half-awake, and resolve the issue without asking anyone a question?

Read your runbook from top to bottom as if you are that teammate.
At each diagnosis step, ask yourself: do I know exactly where to click in the AWS Console? Is the path specific enough?
At each resolution row, ask: could I perform this action with no other context?
Check that the "Related architecture" line references your 3-tier-architecture.drawio file by name. This connects both documentation artifacts so the engineer can look at the diagram while following the runbook.

Why the 2 AM test matters

A runbook that says "check the thing" fails the test. A runbook that says "Open AWS Console > EC2 > Target Groups, select your target group, click the Targets tab" passes it. Specificity is the difference between a document that gets used and one that gathers dust.

Before you look at the result, do you think your runbook passes the 2 AM test? Is there any step where a sleep-deprived engineer would have to guess what to do?

Your runbook passes the test if every diagnosis step names a specific AWS Console path (not just "check the instance") and every resolution action is a concrete command or click sequence.

You now have two documentation artifacts that work together: diagrams showing what exists, and a runbook explaining what to do when it breaks. In the Secret Mission, you will write a second runbook and add clickable cross-page links to turn your diagram into an interactive documentation hub.

Secret mission

Database Failure Runbook and Diagram Cross-Links

You have one runbook and a multi-page diagram. Real documentation packages cover more than one failure scenario, and professional diagrams let viewers click through levels without hunting for pages. In this secret mission, write a second runbook for database connection failures and turn your draw.io file into a clickable, navigable documentation hub.

Clean Up Your Resources

This project runs entirely locally, so there are no ongoing costs. Decide whether to keep your documentation files for your portfolio or delete them.

Resources you used:

3-tier-architecture.drawio file saved locally (three diagram pages).
3-tier-architecture.png export saved locally.
runbook-web-server-down.md saved locally.
runbook-database-connection-failure.md saved locally (Secret Mission).

Keep everything running

No action needed. Choose this if you want to keep your documentation artifacts for your portfolio or reference them in future projects.

These files have zero ongoing cost. They sit on your local machine and take up negligible disk space.
Consider storing them in a Git repository to demonstrate your documentation skills to employers.
The .drawio file is editable any time you revisit app.diagrams.net.

Pause - I'll come back to this later

No action needed. Since everything is local files with no running processes, there is nothing to pause or shut down.

Your files remain on disk exactly where you saved them.
Close the browser tab with app.diagrams.net. Next time you want to edit, reopen the site and use File > Open from > Device to load your 3-tier-architecture.drawio file.

Delete - I don't want to use this again

Remove all project files from your machine. This is permanent.

Delete the diagram and export files by running:

rm 3-tier-architecture.drawio 3-tier-architecture.png

Delete the runbook files by running:

rm runbook-web-server-down.md runbook-database-connection-failure.md

Confirm the files are gone by running:

ls

You should no longer see any of the four files in the output.
No accounts were created for this project. draw.io runs in the browser with no login required.

Nice Work!

Nice work! You just created a complete architecture documentation package for a 3-tier AWS application. You now have professional diagrams and a runbook that any engineer could use to understand your system and respond to incidents.

You've learned how to:

Document a 3-tier AWS architecture using the C4 model, producing both a System Context and Container diagram in draw.io with proper AWS icons, color-coded boundaries, legends, and labeled data flows with protocols and port numbers.
Experience firsthand why a single-page diagram fails and separate levels of abstraction for different audiences, from managers who need the big picture to engineers who need subnet-level detail.
Write a structured incident runbook in Markdown with actionable diagnosis steps, a decision-table resolution, and an escalation procedure that any team member could follow at 2 AM without prior system knowledge.
Secret Mission: Write a second runbook for database connection failures and add clickable cross-page navigation between your diagram levels, turning your draw.io file into an interactive documentation hub.

Ready to quiz yourself?