WhatsTheTime.com - Stateless Web App

Overview

This is the first solution architecture case study, and it's designed to show you the iterative journey of a Solutions Architect. We start with the simplest possible application and progressively improve it, adding AWS services one by one to solve real problems.

WhatIsTheTime.com is a stateless web application — it simply tells users what time it is. It sounds trivial, but that's the point: the app is so simple that everyone understands it, and we can focus entirely on the architecture decisions rather than the application logic.

Key constraints:

• No database needed — each server knows the time
• Start small, willing to accept some downtime initially
• App gets more and more popular over time
• Need to scale vertically, then horizontally, then remove downtime entirely

This is pure solution architecture — the kind of thinking the exam tests you on.

Architecture Evolution

Step 1: Single EC2 Instance + Elastic IP

┌──────────┐                    ┌─────────────────────┐
│   User   │───── "What time   │  T2 Micro Instance  │
│          │      is it?" ────▶│  + Elastic IP       │
│          │◀──── "5:30 PM" ───│  (Public)           │
└──────────┘                    └─────────────────────┘

This is our first proof of concept. We have a single public EC2 instance — a tiny T2 Micro — and we attach an Elastic IP to it so it has a static IP address. If something happens and we need to restart the instance, the IP stays the same.

What works: Users can access the app. We're getting great feedback.

What doesn't work: There's zero redundancy. If the instance goes down, the entire application is down. But for a PoC, this is acceptable.

Step 2: Vertical Scaling

┌──────────┐                    ┌─────────────────────┐
│   User   │──────────────────▶│  M5 Large Instance  │
│          │                    │  + Elastic IP       │
│          │                    │  (Public)           │
└──────────┘                    └─────────────────────┘

The app is getting popular. More and more users are asking what time it is, and the T2 Micro can't handle the load. So as a Solutions Architect, we decide to vertically scale — replace the T2 Micro with a bigger M5 Large instance.

The process: stop the instance → change the instance type → start it again. Because we have an Elastic IP, the IP address stays the same, so users can still find us.

The problem: During the upgrade, the instance is stopped. Users experience downtime and they're not happy. They can't access the application while we're upgrading. This works, but it's not great.

Step 3: Horizontal Scaling + Elastic IPs

┌──────────┐    ┌─────────────────────┐
│          │───▶│ M5 Large + EIP 1    │
│  Users   │───▶│ M5 Large + EIP 2    │
│          │───▶│ M5 Large + EIP 3    │
└──────────┘    └─────────────────────┘

Now we're really popular, so it's time to scale horizontally — add more instances instead of making one bigger. We launch three M5 Large instances, each with its own Elastic IP.

The problems are piling up:

• Users need to know all three IP addresses to talk to our instances — that's terrible UX
• We're managing three Elastic IPs, and AWS only gives you 5 Elastic IPs per region by default
• Adding or removing instances means users need to update their IP lists
• This approach simply doesn't scale

Step 4: Route 53 DNS (Remove Elastic IPs)

┌──────────┐    ┌──────────────────┐    ┌─────────────────────┐
│          │    │    Route 53      │    │ M5 Large (x3)       │
│  Users   │───▶│ api.whatisthe    │───▶│ Public instances     │
│          │    │ time.com         │    │ (no Elastic IPs)     │
│          │    │ A Record         │    │                     │
│          │    │ TTL: 1 hour      │    └─────────────────────┘
└──────────┘    └──────────────────┘

Let's get rid of Elastic IPs entirely. Instead, we set up Route 53 with an A Record for api.whatisthetime.com. An A Record returns a list of IP addresses, so Route 53 gives users the IPs of our EC2 instances. We can update Route 53 whenever we add or remove instances.

What works: No more Elastic IPs to manage. Users just remember one domain name.

What breaks: We set the TTL to 1 hour. Now imagine we remove one instance — the users who cached that DNS response will keep trying to connect to the removed instance for up to 1 hour. They think our app is down, and that's really bad.

Step 5: ELB + Private Instances

┌──────────┐   ┌──────────────┐   ┌──────────────┐   ┌─────────────────────┐
│          │   │  Route 53    │   │              │   │  Private EC2 (x3)   │
│  Users   │──▶│  Alias Record│──▶│     ELB      │──▶│  Same AZ            │
│          │   │              │   │ Health Checks│   │  SG: allow from ELB │
└──────────┘   └──────────────┘   └──────────────┘   └─────────────────────┘

This is a major architectural shift. Instead of public instances, we now have private EC2 instances behind a Load Balancer. The ELB is the only public-facing component.

Critical DNS change: We can't use an A Record anymore because the ELB's IP addresses change constantly. Instead, we use an Alias Record in Route 53, which points to the ELB's DNS name and automatically resolves to whatever IPs the ELB currently has.

What we gain:

• Health checks — if an instance is down or not responding, the ELB stops sending traffic to it. Users never see a failure.
• Security group rules — EC2 instances only accept traffic from the ELB's security group. They're not directly accessible from the internet.
• No downtime when adding or removing instances — just register/deregister them with the ELB
• No more TTL problems — the ELB handles routing

Step 6: Auto Scaling Group

┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────────────────────┐
│          │   │ Route 53 │   │          │   │         ASG              │
│  Users   │──▶│  Alias   │──▶│   ELB    │──▶│  ┌─────┐ ┌─────┐      │
│          │   │          │   │          │   │  │ M5  │ │ M5  │ ...  │
└──────────┘   └──────────┘   └──────────┘   │  └─────┘ └─────┘      │
                                              │  Scale in/out on demand│
                                              │  (Single AZ)          │
                                              └──────────────────────────┘

Adding and removing instances manually is tedious. So we wrap our instances in an Auto Scaling Group. The ASG automatically scales based on demand — maybe in the morning nobody cares about the time, but in the evening when people want to leave work, traffic spikes.

What we gain:

• Automatic scaling — instances are added when demand increases, removed when it decreases
• No manual intervention needed
• Cost-efficient — we only pay for what we need at any given moment

What's still wrong: Everything is in a single Availability Zone. If that AZ goes down (earthquake, power failure, network issue), our entire application is down.

Step 7: Multi-AZ (The Final Architecture)

┌──────────┐   ┌──────────┐   ┌───────────────────┐   ┌──────────────────────────────┐
│          │   │ Route 53 │   │    Multi-AZ ELB   │   │           ASG                │
│  Users   │──▶│  Alias   │──▶│  AZ1, AZ2, AZ3   │──▶│  AZ1: M5 x2                 │
│          │   │          │   │  + Health Checks   │   │  AZ2: M5 x2                 │
└──────────┘   └──────────┘   └───────────────────┘   │  AZ3: M5 x1                 │
                                                        └──────────────────────────────┘

Now we make everything Multi-AZ. The ELB spans three Availability Zones (AZ1, AZ2, AZ3) with health checks. The ASG also spans all three AZs, distributing instances across them.

What happens when AZ1 goes down? The ELB detects that instances in AZ1 are unhealthy and stops routing traffic to them. AZ2 and AZ3 continue serving users. The ASG may even launch replacement instances in the healthy AZs. Our users never notice the outage.

This is what it means to be highly available and resilient to failure.

Step 8: Cost Optimization

Now that we have a stable, highly available architecture, let's think about cost. We know that at minimum, we always want at least two instances running (one per AZ for redundancy). These instances run 24/7, 365 days a year.

What We Learned — Solutions Architect Perspective

This case study walked through the complete journey of a Solutions Architect. Here's every concept we touched and why it matters:

Questions & Answers