Reading Cloud Infrastructure Architecture Documents

Multi-AZ = synchronous standby in a second AZ for automatic failover:

The passage states: "AWS maintains a synchronous standby replica in a second AZ. If the primary instance or its AZ becomes unavailable, RDS automatically fails over to the standby — typically completing within 60–120 seconds — with no manual intervention required."

Key concepts unpacked:

• Availability Zone (AZ) → a physically separate data centre within an AWS Region. An AZ can fail (power, networking) without affecting other AZs.
• Synchronous replication → every write to the primary is simultaneously written to the standby before the write is acknowledged. This means zero data loss on failover.
• Automatic failover → AWS detects the failure and promotes the standby to primary without a human pressing a button.

Multi-AZ vs. Read Replicas:
These are often confused. Multi-AZ is for availability (survive failures). Read Replicas are for read scalability (distribute SELECT queries). Multi-AZ standby does NOT serve read traffic — it only exists to take over in a failure.

Infrastructure vocabulary:

• failover → the process of switching from a failed component to a standby
• high availability (HA) → system design that minimises downtime
• no manual intervention → automated operations, no on-call engineer needed for recovery

ElastiCache is an in-memory cache — it absorbs read traffic so the database doesn't have to:

The passage says: "Frequently read data (product catalogue, session tokens, homepage content) is cached with a TTL of 5 minutes. This reduces the number of SQL queries hitting the RDS instance and significantly lowers average response latency."

Why caching matters for performance:

• A Redis cache lookup: ~0.1–1ms
• A PostgreSQL query (with disk I/O): ~5–100ms
• For a homepage loaded by thousands of users per minute, serving from cache vs. database is an order-of-magnitude difference

TTL (Time To Live) of 5 minutes:
Cached data is automatically expired after 5 minutes. This prevents stale data from being served indefinitely. The trade-off: data can be up to 5 minutes out of date. For a product catalogue, this is usually acceptable.

What gets cached (from the passage):

• Product catalogue — read-heavy, infrequently updated
• Session tokens — needed on every authenticated request
• Homepage content — the single most requested page

Infrastructure vocabulary:

• in-memory cache → data stored in RAM, much faster than disk
• TTL (Time To Live) → how long a cached value is considered valid
• cache hit → the requested data was found in the cache (fast path)
• cache miss → the data was not in cache, must query the database (slow path)

Auto Scaling adds more instances horizontally — scaling out, not up:

The passage states: "The ASG maintains a minimum of 2 instances and scales up to 12 based on average CPU utilisation (target: 60%). When a traffic spike occurs, the ASG launches additional instances within approximately 90 seconds."

Horizontal vs. vertical scaling:

• Horizontal scaling (scale out) → add more instances of the same size. Auto Scaling does this.
• Vertical scaling (scale up) → replace an instance with a bigger one. Requires downtime; Auto Scaling does NOT do this automatically.

How the scaling trigger works:
The target CPU utilisation is 60%. When the average CPU across all instances exceeds 60%, the ASG detects this and launches new instances. As new instances come online and absorb traffic, average CPU drops back toward 60%.

The 90-second lag is important:
It takes ~90 seconds to launch, configure, and pass health checks before a new instance receives traffic. During sudden spikes, existing instances must absorb the load until new ones are ready — this is why a minimum of 2 instances is always maintained rather than scaling from zero.

Infrastructure vocabulary:

• Auto Scaling Group (ASG) → a managed fleet of EC2 instances that scales based on policies
• scale out / scale in → add / remove instances
• target tracking policy → ASG keeps a metric (e.g. CPU) near a target value by adding or removing instances

CloudFront = a CDN that caches assets close to the user geographically:

The passage says: "CloudFront caches assets at the edge closest to the user, reducing both latency and origin bandwidth costs." with 47 global edge locations.

Why proximity to the user matters:
Network latency is largely determined by physical distance. A user in Tokyo fetching a 500KB image from a server in eu-west-1 (Ireland) incurs ~240ms of round-trip time just for the network. If CloudFront has cached that image at its Tokyo edge location, the same request takes ~5ms.

Two benefits the passage identifies:

• Lower latency → assets served from nearby edge, not from the origin region
• Lower origin bandwidth costs → if CloudFront serves the file from its cache, the request never reaches S3. Fewer requests to origin = lower S3 data transfer costs.

What CloudFront does NOT do (common misconception):
CloudFront caches static assets (images, CSS, JS). It does not cache dynamic API responses with user-specific data. Those still go to the origin servers.

Infrastructure vocabulary:

• CDN (Content Delivery Network) → a geographically distributed network of servers that cache content closer to users
• edge location → a CDN point-of-presence (PoP) in a city near end users
• origin → the source of truth (here: S3) that the CDN fetches from on a cache miss
• cache-hit ratio → percentage of requests served from the cache vs. forwarded to origin

Stateless = no local session data, so any instance can serve any request:

The passage states: "Web tier instances are stateless: they hold no session or user data locally, which allows any instance to handle any request without affinity."

Why statefulness would break Auto Scaling:
Imagine a stateful server: when a user logs in, their session is stored in the server's memory. If the ALB routes that user's next request to a different server (which happens under Auto Scaling as instances are added/removed), the second server has no session data → the user is logged out. This is called "sticky sessions" and it creates server affinity — a user is "stuck" to one instance.

How the architecture avoids this:
Session tokens are stored in ElastiCache (Redis), which all instances share. When any EC2 instance receives a request with a session token, it looks it up in Redis. The instance itself holds nothing user-specific. This means:

• Any instance can handle any request ✅
• Auto Scaling can add instances freely — new instances immediately serve all users ✅
• Auto Scaling can remove instances freely — no session data is lost ✅

Infrastructure vocabulary:

• stateless → a service that keeps no user-specific state between requests
• stateful → a service that stores user state locally (sessions in memory, files on disk)
• horizontal scalability → the ability to add more instances; requires statelessness
• affinity / sticky sessions → routing a specific user to the same server every time (workaround for stateful apps)