Architecture Review Practice: A Single-AZ AWS Web App
This diagram is deliberately incomplete. Its clean request path makes the risks easy to discuss: one application instance, a Single-AZ database, and no visible recovery or operational controls. Use it as a review exercise before opening the editable version and improving it.
Published August 18, 2026
Reference architecture
Architecture diagram
Open on the canvasAWS architecture review diagram showing an Application Load Balancer, one application server, and a Single-AZ RDS database. The image links to a fully editable BuildPlane starter.
Overview
A visually polished but intentionally incomplete web application for architecture-review practice. The request path is easy to follow, while the single application instance, Single-AZ database, and missing operational controls create concrete review questions.
Components
- Application Load Balancer: Provides a stable public endpoint but currently has only one application target.
- Single Application Server: Runs the whole application in one Availability Zone with no Auto Scaling replacement shown.
- Single-AZ RDS: Stores relational data without the standby failover provided by Multi-AZ deployment.
- Review Boundary: The VPC separates public ingress, private compute, and private data even though resilience controls are incomplete.
Review Flow
- Web users connect to the public Application Load Balancer.
- The load balancer forwards every request to one application server.
- The application server reads and writes the Single-AZ RDS database.
- The reviewer identifies what would fail, what is unobserved, and which controls should be added first.
Customize First
- Add a second Availability Zone and Auto Scaling capacity to remove the compute single point of failure.
- Convert the database to Multi-AZ and define backup and recovery objectives.
- Add authentication, secrets management, and monitoring based on the application’s requirements.
Design rationale
Decisions that shape this architecture
Review the failure path before adding services
The first question is not which AWS product is missing. Ask what user-visible behavior occurs when the application instance or database becomes unavailable.
Separate availability from scalability
A larger instance may handle more traffic but remains one failure point. Auto Scaling across zones addresses replacement and distribution, not only capacity.
Prioritize controls by impact
Multi-AZ compute and data usually come before optional optimizations. Authentication, secrets, monitoring, backups, and cost controls should follow the workload threat and recovery model.
Before production
Operational checks
Document the effect of losing the application instance.
Document database backup, restore, and failover objectives.
Identify where credentials live and how they rotate.
Define the first alarms an operator needs during an incident.
Scope and tradeoffs
What this diagram does not solve
This is intentionally not a production reference
The weaknesses are teaching material. Do not interpret the polished visual as evidence that the architecture is resilient or secure.
A complete review needs workload context
Traffic, data sensitivity, recovery objectives, deployment process, team size, and budget determine which improvements should come first.
Common questions
Frequently asked questions
What is the biggest risk in this Single-AZ design?
Both compute and database availability depend on single resources or one zone. Either failure can interrupt the application.
Should every AWS application be multi-Region?
No. Multi-Region complexity should be justified by recovery objectives and business impact. Multi-AZ is often the first availability step.
How can I use this diagram for practice?
List failure modes and missing controls first, then open the editable diagram and add improvements in priority order while explaining each tradeoff.
Keep exploring
Related AWS architectures
An AWS Application That Survives an Availability Zone Failure
This architecture focuses on one failure question: what happens when an entire Availability Zone becomes unavailable? Healthy application capacity remains in the other zone, the load balancer removes failed targets, and RDS can promote its synchronous standby.
Explore the architecture
Highly Available Three-Tier Web Application on AWS
This starter architecture separates ingress, presentation, application logic, and relational data so each tier can fail and scale independently. It is a practical baseline for teams moving a conventional web application onto AWS without collapsing every responsibility into one server.
Explore the architecture
Production-Grade Highly Available Web Platform on AWS
This reference expands the three-tier baseline with a global edge, separate scaling domains, caching, read scaling, private egress, secrets, backups, and operations. It is intended for teams evaluating a conventional production web platform rather than a minimal learning diagram.
Explore the architectureFrom reference to working draft
Adapt this architecture with your AWS AI Agent
Start from the exact diagram in this guide. Change requirements, challenge a decision, or ask what fails first, while keeping the architecture editable.