AWS Core Platform and the Web Request Path

Prerequisites and outcomes

Prerequisites. Read the earlier lessons on Internet Protocol (IP) addressing, Domain Name System (DNS) resolution, Transmission Control Protocol (TCP), Transport Layer Security (TLS), and virtual machines. The networking lesson supplies the distinction between a DNS name, an IP address, and a TCP port. The virtualization lesson explains why a virtual machine can fail while the physical cloud platform continues to operate. A direct-link reader should know that a Hypertext Transfer Protocol (HTTP) request contains a method, a path, headers, and sometimes a body.

After this chapter, you can:

• follow one browser request through a typical Amazon Web Services (AWS) deployment;
• distinguish a Region, an Availability Zone, a virtual private cloud, and a subnet;
• connect DNS, load balancing, compute, a relational database, and object storage to evidence that each product produces;
• calculate a first capacity target with explicit units and headroom; and
• investigate a slow or failed request without treating an architecture diagram as proof of runtime behavior.

Product names and console layouts in this chapter are current as of July 2026. The request stages, fault-isolation reasoning, and measurement methods are durable. Region inventories, default settings, quotas, metric interfaces, and product features are version-sensitive and require a documentation check before a production change.

A purchase during registration week

At 9:02 a.m. on registration Monday, Maya opens the CampusCart university bookstore in a browser from a residence hall. CampusCart serves about 5,000 users on an ordinary day. The application normally completes 80 HTTP requests each second and reaches 400 completed HTTP requests each second during registration peaks. Maya selects a calculus text, chooses Buy, and expects one order row to appear in PostgreSQL while the cover image remains available from object storage.

CampusCart runs in one AWS Region. An Application Load Balancer has network interfaces in two Availability Zones. Stateless application instances run in private subnets in both zones. An Amazon Relational Database Service (Amazon RDS) PostgreSQL database stores orders. An Amazon Simple Storage Service (Amazon S3) bucket stores book images. Amazon Route 53 hosts the public DNS record for shop.campuscart.example.

Maya reports a 6-second pause followed by an HTTP 503 Service Unavailable response. The incident responder needs to locate the wait. A high-level diagram cannot establish whether Maya waited for DNS, TLS, the load balancer, application code, or PostgreSQL. Runtime artifacts can narrow the question because different programs create evidence at different stages.

Evidence before explanation

Maya's browser developer tools produce a network entry when the browser starts and completes the request. Common fields include the URL, HTTP status, transferred bytes, and timing phases such as DNS lookup, connection establishment, TLS negotiation, time to first response byte, and content download. The browser clock supplies the local timestamps. A long “waiting for server response” interval establishes that the browser had sent the request and had not yet received the first response byte. The browser entry alone does not identify which server-side operation consumed the interval.

The Application Load Balancer can produce an access-log line after a request finishes when access logging is enabled. Fields can identify the client address, target address, request line, load-balancer status, target status, bytes, and separate request-processing, target-processing, and response-processing times. The load balancer produces the line, not Maya's browser and not the application. A target-processing time near 5.8 seconds supports an inference that most of the delay occurred after forwarding to an application target. The field does not prove that PostgreSQL caused the delay because application code, an outbound call, or local CPU contention can consume the same interval.

The CampusCart application produces a structured log entry when its request handler runs. A useful entry contains a generated request identifier, route name, selected instance identifier, Availability Zone, database-call duration in milliseconds, outcome, and timestamp. Amazon RDS and PostgreSQL produce database logs and performance observations according to the enabled settings. Amazon CloudWatch receives provider-produced measurements and application-published measurements. A CloudWatch measurement needs a name, unit, timestamp, and identifying dimensions; a statistic such as an average or percentile summarizes observations over a stated period. AWS documentation in July 2026 describes both OpenTelemetry ingestion and the classic CloudWatch metric format. The ingestion interface can change while the need to identify the measurement producer and aggregation remains constant.

Three statements must remain separate:

1. Observation: the load-balancer log reports 5.8 seconds of target processing and an HTTP 503 response.
2. Inference: a target accepted the request but did not produce a successful response promptly.
3. Assumption to test: the target waited for an exhausted PostgreSQL connection pool.

How the request moves

Route 53 answers the browser's DNS query with addresses associated with the Application Load Balancer alias target. A recursive DNS resolver can cache the answer until the DNS time to live expires. The browser then establishes a TCP connection and negotiates TLS with a load-balancer listener configured for HTTPS, commonly TCP port 443.

The listener evaluates ordered rules against request properties such as the host and URL path. A matching rule selects a target group. The target group contains registered instance or IP targets and a health-check configuration. Each load-balancer node sends periodic health-check requests. A target becomes eligible only after registration and a successful initial health check. The node normally forwards application requests only to targets considered healthy.

An application target receives the HTTP request on the target group's configured protocol and port. CampusCart validates Maya's session, checks inventory, begins a PostgreSQL transaction, writes the order, and commits. A later browser request can retrieve the cover image from an S3 URL. S3 is not a mounted disk in this design. S3 accepts operations against object keys through an application programming interface (API), and CampusCart must authorize those operations separately from database access.

The network placement names now have concrete referents. An AWS Region is a geographic area that AWS operates separately from other Regions. An Availability Zone is an isolated location inside a Region; AWS describes zones in a Region as connected by low-latency, high-bandwidth, redundant networking. A virtual private cloud (VPC) is a customer-configured virtual network within AWS. A subnet is an IP-address range tied to one Availability Zone. Each subnet has one associated route table, directly or through the VPC's main route table, and each route names a destination address range and a next target.

A subnet is not “public” because of its name. Public reachability depends on routes, gateways, public addresses, and packet filters on both sides of the traffic path. CampusCart's load balancer uses subnets with routes appropriate for Internet-facing traffic. Application targets use private subnets and receive traffic from the load balancer according to their security-group rules. The database permits PostgreSQL traffic from the application targets rather than from arbitrary Internet addresses.

An Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling group maintains a minimum, desired, and maximum instance count from a launch template. Scaling policies can change desired capacity from measurements or schedules. New capacity requires launch, boot, application initialization, target registration, and successful health checking before the load balancer can use the target. Autoscaling therefore changes future capacity; autoscaling does not make an already queued request finish immediately.

A capacity model with units and assumptions

CampusCart's team load-tests one initialized application instance. With a controlled request mix, one instance completes 45 requests per second while its 95th-percentile response time remains below 300 milliseconds. “Requests per second” means successful, representative CampusCart requests completed by the instance divided by the observed seconds. The registration target is 400 completed requests per second. The team limits planned utilization to 60 percent so that retries, uneven distribution, and short bursts have room.

Let:

• $L$ = forecast arrival load, in requests per second;
• $C$ = measured per-instance capacity, in requests per second;
• $u$ = planned utilization fraction, dimensionless; and
• $N$ = required healthy application instances.

Each instance contributes $C u$ planned requests per second. Therefore the fleet must satisfy $N C u \ge L$, which gives:

Two-zone placement suggests at least 8 instances in one zone and 7 in the other during normal operation. A stricter requirement to survive either zone with the same 60-percent target needs enough remaining instances in one zone to serve all 400 requests per second. The stricter assumption leads to 15 instances per zone, or 30 total. Capacity planning therefore depends on the stated failure requirement, not only on peak traffic.

The calculation assumes the load-test request mix matches registration traffic, PostgreSQL and downstream capacity do not bind first, instances have equal capacity, and new targets are already warm. The calculation omits connection limits, queue growth, zone imbalance, cache behavior, and service quotas. Omitted factors matter when the database saturates, when traffic spikes faster than instance readiness, or when one zone fails.

Make the mechanism visible

Run an empirical test in a nonproduction environment. Hold the application build, instance type, database dataset, object size, region, and request mix constant. Increase offered load in steps of 40 requests per second every two minutes. Preserve the load generator's completed-request count and latency distribution, load-balancer request and target times, healthy target count, application database-wait duration, and PostgreSQL connection count.

Expected evidence shows nearly proportional completed throughput while spare capacity exists. Latency and errors should rise when a limiting resource saturates. A step increase in healthy targets should raise the sustainable completion rate after the boot and health-check delay. Evidence that would reject the application-capacity explanation includes flat application CPU, no queue growth, and a database connection count already at its limit. Alternative explanations include a load-generator limit, network packet loss, an artificial health endpoint that reports success while dependencies fail, or a different request mix during production.

Worked investigation: registration 503 responses

Initial question. Why did 4.1 percent of checkout requests return HTTP 503 between 09:02 and 09:06?

Operating conditions. CampusCart received 390 to 430 requests per second. Eight application instances were healthy across two Availability Zones. A scaling policy requested six more instances after a CPU alarm. Each application instance allowed 20 PostgreSQL connections, and the database accepted at most 160 application connections.

Evidence collected. The browser entry showed a successful connection followed by 6 seconds waiting for a response. Load-balancer logs placed most time in target processing. Load-balancer measurements kept eight healthy targets until 09:05. Application entries with the same request identifiers reported database-pool waits near 5 seconds. PostgreSQL observations reported 160 active or reserved application connections. Auto Scaling activity history reported that six instances launched at 09:03 but did not become healthy until 09:05.

Interpretation. Existing handlers consumed the database pool before replacement capacity became ready. Extra instances could not help before registration. Extra instances also would request more database connections, so compute scaling alone could move the limit to PostgreSQL.

Proposed intervention and prediction. A scheduled scaling action will place 15 warm instances before registration begins. A bounded checkout queue and shorter database transactions will reduce simultaneous connection occupancy. The predicted result is fewer pool waits, provided that measured PostgreSQL capacity supports the resulting transaction volume.

Observed or calculated result. A replay with 15 pre-warmed instances and optimized transaction duration completed 418 requests per second. The 95th-percentile checkout time was 410 milliseconds, and HTTP 5xx responses were 0.2 percent. PostgreSQL connection usage peaked at 142.

Bounded conclusion. Warm application capacity and shorter transactions removed the reproduced connection-pool bottleneck at the tested request mix through 418 completed requests per second.

Remaining uncertainty. The replay did not simulate an Availability Zone failure, an S3 slowdown, a payment-provider slowdown, or traffic above 430 requests per second. Production success still requires alarms, quota checks, and a zonal-failure test.

Normal operation, edge behavior, and qualifications

During normal operation, Route 53 returns the load-balancer alias, TLS terminates at a listener, a listener rule selects the CampusCart target group, and a healthy instance completes the request. The application writes the order to PostgreSQL and returns an HTTP response. Multiple zones reduce dependence on one location only when targets, capacity, and relevant data paths actually use multiple zones.

Several edge cases weaken a simplified diagram:

• Application Load Balancer health checks are periodic samples, not proofs that every application operation works. A shallow /health route can succeed while PostgreSQL access fails.
• AWS documents a fail-open behavior when all registered targets in a target group are unhealthy: the load balancer can route to all targets regardless of health. Practitioners must not assume that “all unhealthy” means “no forwarding.”
• A DNS client can retain an address until its cache entry expires. DNS failover therefore does not move every client at one instant.
• Auto Scaling replaces impaired instances and changes desired count, but readiness consumes time. Scheduled capacity or a higher minimum can be necessary for a known peak.
• An Amazon RDS Multi-AZ deployment improves database availability through standby or multi-instance arrangements described by the selected deployment type. Multi-AZ does not remove application reconnection behavior, failover time, logical corruption, or the need for tested backups.
• AWS Regions isolate regional infrastructure. AWS does not automatically replicate every regional resource to another Region. Cross-Region recovery requires explicit design and testing.

Common reasoning errors

“A private subnet cannot communicate with the Internet.” Subnet labels do not decide reachability. Route tables, gateways, addresses, security groups, network access control lists, and return paths jointly determine packet delivery.

“The load balancer makes the application highly available.” The load balancer selects available targets; the application still needs healthy targets, sufficient capacity, correct zonal placement, and available dependencies.

“Average latency proves users are fast.” An average can hide a slow minority. Preserve a latency distribution and a stated percentile over a stated interval.

“Four hundred requests per second requires ten instances because each instance handled forty.” A division without headroom assumes perfect balancing and no failures. The capacity test must also represent the production request mix and dependency limits.

“CloudWatch caused an API action because a graph changed at the same time.” A metric graph establishes a time relationship. CloudTrail activity, scaling history, and application evidence are needed to support a causal sequence.

Knowledge check

Question. A target reports healthy every 30 seconds, but checkout requests time out while the static home page works. Which evidence should the responder collect next, and why does health status not settle the question?

Answer. Correlate load-balancer access entries, application request entries, database-pool wait measurements, and PostgreSQL observations with a request identifier and time window. The health request may exercise only a simple route. A successful sample proves that the sampled route responded under its health-check conditions; the sample does not prove that checkout's database path had capacity.

Evidence exercises

Check

Draw Maya's request path from browser DNS query through Route 53, the Application Load Balancer, an application target, and PostgreSQL. Label every protocol boundary, port where known, artifact producer, and location scope. Submit the diagram and a four-row table that states one direct observation and one unsupported inference for each artifact.

Practice

Use a local HTTP server and a load generator, or an approved cloud sandbox. Hold payload and code constant. Increase concurrency in at least five steps. Preserve the exact command, start and end timestamps, completed requests per second, error count, and 50th- and 95th-percentile latency. Submit a graph and a causal explanation that identifies the first observed limit. Do not claim an AWS product limit from a local test.

Challenge

Create two capacity calculations for CampusCart at 400 completed requests per second: normal two-zone operation and survival of either zone. Use the measured 45 requests per second per instance and a 60-percent planned utilization. Add one database-capacity constraint of your choice with explicit units. Submit assumptions, equations, rounded instance counts, and a test that could disprove the selected database limit.

Authoritative sources and further reading

Required reading

• AWS Regions and Availability Zones identifies geographic and fault-isolation scopes and warns that regional resources are not automatically replicated.
• Application Load Balancer introduction names listeners, rules, target groups, targets, and health checks used in the request path.
• Amazon VPC subnet route tables establishes the destination-and-target mechanism for subnet routing.

Implementation and version-sensitive documentation

• Application Load Balancer health checks documents current thresholds, target states, and fail-open behavior.
• Amazon EC2 Auto Scaling overview documents minimum, maximum, desired capacity, replacement, and load-balancer registration.
• Amazon CloudWatch metrics documents metric producers and the July 2026 ingestion choices; revisit the page because interfaces and limits change.
• Amazon RDS Multi-AZ DB instance deployments describes current database deployment and failover behavior.

Advanced reference

• AWS Well-Architected Reliability Pillar connects quotas, testing, recovery objectives, and fault isolation to production design.

Transition

CampusCart's request path gives concrete meanings to regional placement, routing, managed load balancing, compute, object storage, and a managed database. The next chapter keeps the same application and request so that provider vocabulary cannot hide architectural differences. Google Cloud and Microsoft Azure offer comparable capabilities, but their resource hierarchies, network scopes, load-balancer choices, and identity attachment points are not interchangeable names.