Build brief · AWS
Translate “high availability” into a testable two-AZ web architecture with health checks, scaling behavior and a recovery record.
Start with the business or technical outcome
An architecture diagram is not proof that an application survives a failure. This field lab turns the topic into a small deliverable that can be built, checked and explained. A small web service must continue serving users when one instance becomes unhealthy and should avoid exposing its database to the public internet.
Treat availability as a measurable requirement: define what must remain usable, how quickly traffic should recover and which dependencies could still fail. A load balancer cannot compensate for a single-AZ database or broken deployment artifact.
Use a temporary learning account with budgets and least-privilege access. Keep sample data non-sensitive. The project is complete only after resources are removed or intentionally retained with cost ownership.
What to understand before opening the tool
Understand public and private subnets, route behavior, security-group references, target groups, health checks, launch templates and the difference between scaling and recovery. Each component solves a distinct failure or exposure problem.
Multi-AZ improves resilience for supported database configurations, but it does not remove the need for backups, monitoring, application retries and recovery planning. State assumptions rather than calling the lab “disaster-proof.”
VPC and Subnets
Use it for: place internet-facing and private components across two Availability Zones Keep as evidence: network diagram and route review
Application Load Balancer
Use it for: distribute HTTP traffic and evaluate target health Keep as evidence: listener and healthy-target evidence
Auto Scaling Group
Use it for: maintain desired capacity and replace unhealthy instances Keep as evidence: activity history
Amazon RDS
Use it for: provide a managed relational data tier with private connectivity Keep as evidence: configuration summary without secrets
The practical outcome is a two-Availability-Zone architecture diagram, deployed lab, health-check evidence, controlled failure test and cleanup record. Build it with fictional, public or explicitly authorised data. Record the starting state before making changes, because a screenshot of the final screen cannot explain how the result was produced. The strongest evidence is a short chain: requirement, action, validation and one reflection on what you would improve.
Build the workflow in six controlled moves
Deploy from the network boundary inward, validating each dependency before adding the next.
- Set guardrailsCreate a cost budget, naming tags, approved Region and cleanup list before provisioning.Checkpoint: Budget alert and resource inventory.
- Build the networkCreate two public and two private subnets across Availability Zones with explicit routes.Checkpoint: Subnet and route-table diagram.
- Prepare repeatable computeUse a launch template and tested bootstrap process so replacement instances are consistent.Checkpoint: Versioned template and application response.
- Add load balancingConfigure listener, target group and meaningful health endpoint, then verify both targets.Checkpoint: Healthy-target and request evidence.
- Connect the data tierPlace RDS privately, restrict access to the application security group and test a safe query.Checkpoint: Connectivity result and rule review.
- Run a failure exerciseRemove or stop one application target, observe traffic and replacement, then record recovery behavior.Checkpoint: Timestamped test log and lessons.
Do not rush through the successful path. Repeat one step with a controlled variation and compare the evidence. That second run reveals which inputs are important and gives you a concrete troubleshooting story for interviews.
Tools, decisions and proof
Every component should map to a failure it addresses and a validation that proves the behavior.
| Decision or signal | Action to take | Evidence to retain |
|---|---|---|
| One instance fails | ALB health check plus Auto Scaling replacement | Requests continue and activity history shows replacement |
| One AZ is impaired | Distribute application capacity and supported data configuration | Targets and subnets span two AZs |
| Database is exposed | Private subnets and narrow security-group source | No public endpoint; app-only access test |
| Bootstrap is inconsistent | Versioned launch template and idempotent setup | Replacement returns the same health response |
| Traffic increases | Measured scaling policy and cooldown understanding | Metric graph and scaling activity |
Failure tests that improve the project
Test failures deliberately and safely; do not infer resilience from green icons.
- Calling two instances highly available: If both share one Availability Zone or dependency, the same event can affect them.
- Opening database access broadly: Reference the application security group instead of allowing public CIDR ranges.
- Using the home page as a shallow health check: Create an endpoint that verifies the minimum dependency needed to serve safely.
- Skipping deployment repeatability: A manually repaired server cannot be reliably replaced by Auto Scaling.
- Leaving the lab running: Delete idle resources and confirm billing or cost views after practice.
Turn the exercise into credible portfolio evidence
Publish the diagram, a redacted configuration table and a failure-test narrative. Show the request behavior before, during and after one target fails. Include the recovery limitation you did not test, such as regional disaster recovery.
Never publish account IDs, endpoints that should remain private, credentials or unredacted console screenshots. A concise architecture decision record is stronger than a large screenshot gallery.
Explain it clearly in an interview
Explain the difference between load distribution, instance replacement, Multi-AZ database availability and backup recovery. Use the failure-test evidence to avoid vague claims.
Peer review before calling the work complete
Ask another learner to inspect the result without watching you build it. Give them the original scenario—a small web service must continue serving users when one instance becomes unhealthy and should avoid exposing its database to the public internet.—and the evidence pack, but not your intended conclusion. They should be able to trace the input, identify the main decision and locate the proof of the output. If they cannot, improve the labels, timestamps or explanation instead of adding decorative screenshots.
Use this acceptance condition during the review: The diagram matches deployed resources, targets span Availability Zones, the data tier is private, a failure test has timestamps, and all cost-bearing resources are accounted for. Record one question the reviewer raised and the change you made in response. That small feedback loop makes the highly available web application on AWS exercise more credible, easier to maintain and easier to explain under interview questioning.
Questions learners ask
Does an Auto Scaling group make every application highly available?
No. Availability also depends on network placement, load balancing, state, database design, deployment repeatability and other dependencies.
Should application instances be in public subnets?
A common design places internet-facing load balancers in public subnets and application targets privately, subject to the workload’s requirements.
What should a health check test?
It should be lightweight yet meaningful enough to identify whether the target can safely serve the intended request.
Is Multi-AZ the same as a backup?
No. Availability configuration and point-in-time or retained backups address different failure and recovery needs.
Use current product guidance
Menus, fields, permissions and service behavior can change between product versions or tenant configurations. Check the AWS Well-Architected Framework before applying version-sensitive steps in a live environment.
Build the complete skill path
Build cloud foundations, networking, identity, compute, storage, databases, observability and cost awareness through connected AWS labs.
Final perspective
The real value of highly available web application on AWS is the ability to complete a controlled task and defend the result with evidence. A learner who can show the input, explain the decision, verify the output and describe one realistic exception demonstrates far more than someone who has only memorised a menu path or definition.