A company is running a two-tier web-based application in an on-premises data center.

The application is described as stateful, which means user sessions or state are likely stored in memory on the application server. When migrating to an Auto Scaling group behind a load balancer, a consistent user experience typically requires session stickiness, so a user’s subsequent requests continue to be routed to the same backend instance that holds their session state (unless the application is refactored to externalize session state, which is not stated here). For HTTP/HTTPS web applications, an Application Load Balancer (ALB) is the correct Elastic Load Balancing choice because it operates at Layer 7 and provides built-in support for cookie-based sticky sessions.

On the database side, Aurora PostgreSQL supports scaling read capacity by adding Aurora Replicas, and Aurora Auto Scaling can automatically adjust the number of replicas based on demand. This is the intended mechanism to scale the database tier for growing read traffic while preserving write consistency through a single writer. “Aurora writers” do not scale horizontally the same way; Aurora provides one writer endpoint at a time (with fast failover), so auto-scaling “writers” is not the right construct for demand-based scaling.

Option C combines the correct load balancer type (ALB) with stickiness and the correct database scaling mechanism (Aurora Replicas with auto scaling). Option A uses an NLB, which is Layer 4 and does not provide the same Layer 7 sticky session behavior expected for a web application pattern. Options B and D incorrectly focus on scaling Aurora writers, which does not address scaling demand patterns as effectively as scaling read replicas.

Therefore, C provides the most consistent user experience for a stateful web tier and enables the database tier to scale using Aurora Replica auto scaling.