AWS SOA-C03 Exam Scenarios: Elastic Load Balancing and Auto Scaling

Purpose of This Lesson

This lesson focuses on scenario-based decisions involving Elastic Load Balancing and EC2 Auto Scaling. The key skill is matching a symptom or requirement to the appropriate AWS feature, metric, log source, scaling policy, or diagnostic action.

The scenarios cover:

• Designing a highly available and secure EC2 application
• Investigating unhealthy load-balancer targets and HTTP errors
• Selecting between an Application Load Balancer (ALB) and Network Load Balancer (NLB)
• Using CloudWatch, access logs, VPC Flow Logs, CloudTrail, and Trusted Advisor for diagnosis
• Choosing dynamic, scheduled, or queue-based Auto Scaling
• Using lifecycle hooks and understanding instance warm-up behavior

Key Concepts

Highly Available and Secure EC2 Architecture

A common three-tier arrangement places the load balancer in public subnets while keeping the application web servers and database layer in private subnets. The layers should be distributed across multiple Availability Zones to improve availability.

The public-facing ALB accepts client traffic and routes requests to web servers in private subnets. The database remains in private subnets rather than being directly exposed to the internet.

ALB Health Checks and Healthy Host Count

An ALB continuously evaluates the health of its registered targets. If an EC2 instance exceeds the configured unhealthy threshold through consecutive failed health checks, the ALB continues checking it but removes it from service for request routing.

A decline in the ALB healthy host count—for example, from six healthy hosts to two—should prompt investigation of target health checks and the target instances.

CloudWatch can be used to detect a complete loss of healthy targets. An alarm condition can use the metric:

AWS/ApplicationELB HealthyHostCount <= 0

The exact alarm configuration should use the appropriate load balancer dimensions and target group context.

ALB Logs, VPC Flow Logs, and CloudWatch Metrics

Different symptoms point to different evidence sources:

• ALB access logs: Identify request details, including the client source IP and the instance or target that processed the request. Logs can be stored in Amazon S3 and used to investigate requests even after target instances have been terminated.
• VPC Flow Logs: Help investigate network-level connectivity problems involving the VPC, such as users being unable to connect to a web server or its relevant ports.
• CloudWatch ALB metrics: Help monitor healthy host counts and HTTP error-related metrics. An HTTPCode_ELB_5XX_Count observation indicates errors generated by the load balancer side of the request path. The lesson also associates observed ALB 4XX errors with investigating the target group and request origin through access logs.
• CloudTrail: Can show failed RunInstances requests when an Auto Scaling group does not launch instances.
• Trusted Advisor: Can help identify service-limit problems that prevent Auto Scaling from launching instances.

Logs and metrics should be selected based on whether the problem is request attribution, network connectivity, load-balancer behavior, or failed instance provisioning.

ALB Versus NLB for Source-IP Allowlisting

When clients require specific static public IP addresses to be allowlisted, a Network Load Balancer is the appropriate choice in this scenario. The requirement is driven by predictable public IP addresses rather than by HTTP-layer routing features.

EC2 Auto Scaling Responses

EC2 Auto Scaling can respond to changing demand and improve application performance. It is relevant when:

• EC2 performance is poor under changing load
• HTTP 503 or 504 errors occur while instances show high CPU utilization
• Queue depth increases and application performance declines
• Traffic follows a predictable daily schedule
• A large traffic spike is expected

The correct scaling mechanism depends on the demand pattern:

• Dynamic scaling: Adjusts capacity in response to a changing metric such as CPU utilization, request count, or queue depth.
• Scheduled scaling: Adds or removes capacity at known times, such as the beginning of each business day.
• Queue-depth scaling: Adds capacity when the number of messages waiting in a queue increases, which is useful for worker-based applications such as an Elastic Beanstalk worker environment.

Auto Scaling Lifecycle Hooks

A lifecycle hook can pause an instance termination process. This gives the system time to analyze or perform actions on instances before they are fully terminated.

Warm-Up and Aggregated Metrics

When step scaling is used, newly launched instances may not immediately appear in aggregated metrics because their warm-up period has not expired. This behavior can make the group-level metric temporarily exclude those instances from the expected aggregate.

Exam- or Assessment-Relevant Takeaways

• For a secure, highly available EC2 website, place the ALB in public subnets and the web and database layers in private subnets across Availability Zones.
• A target that exceeds the unhealthy threshold is removed from ALB service, but health checks continue.
• Use ALB access logs to identify the client source IP and the target instance that processed a request.
• Use VPC Flow Logs for VPC-level connection and port troubleshooting.
• Use HealthyHostCount <= 0 as the basis for an alarm when no ALB targets are healthy.
• Use a Network Load Balancer when clients must allowlist specific static public IP addresses.
• Investigate Trusted Advisor and CloudTrail when an Auto Scaling group fails to launch instances despite not reaching maximum capacity.
• Use a lifecycle hook to pause termination while an instance is being analyzed or processed.
• Use scheduled scaling for predictable time-based demand and queue-depth scaling when backlog is the best indicator of required worker capacity.
• For a large expected traffic spike in a memory-heavy application, the lesson identifies request count per target as the scaling metric to consider.
• Newly launched instances may be absent from aggregated step-scaling metrics until the warm-up period expires.

Tool / Feature Decision Guide

Requirement or symptom	Appropriate feature or evidence	Decisive reason
Public entry point with private web and database tiers	ALB in public subnets; web and database in private subnets	Separates internet-facing access from internal application and data layers
Targets become unhealthy	ALB target health checks	Failed consecutive checks can remove a target from service
Need client source IP and processing target	ALB access logs	Request records provide source and target information
Users cannot connect to a server or port	VPC Flow Logs	Provides VPC network-flow evidence
Need an alarm when every target is unhealthy	CloudWatch HealthyHostCount <= 0	Detects zero healthy ALB targets
Need request history after instances were terminated	ALB access logs stored in S3	Logs remain available independently of the instances
Clients require static public IP allowlisting	Network Load Balancer	Fits the static public IP requirement
Load changes unpredictably	EC2 Auto Scaling dynamic scaling	Adjusts capacity based on changing demand
Load increases at a known time each day	Scheduled scaling	Anticipates a predictable schedule
Worker backlog increases	Queue-depth scaling	Queue depth directly indicates pending work
Termination requires pre-termination analysis	Auto Scaling lifecycle hook	Pauses termination for processing
New instances do not yet appear in step-scaling aggregates	Instance warm-up	The warm-up period may not have expired
ASG cannot launch instances despite available group capacity	Trusted Advisor and CloudTrail	Helps distinguish service limits from failed RunInstances calls

Common Traps / Misconceptions

• Assuming an unhealthy target is terminated: The ALB removes the target from request routing; it does not necessarily terminate the EC2 instance.
• Using ALB access logs for every connectivity problem: Access logs are useful when requests reach the load balancer. VPC Flow Logs are more appropriate for VPC-level connection and port investigation.
• Confusing request attribution with network diagnosis: Source IP and processing target are found in ALB access logs, while network-flow behavior is investigated with VPC Flow Logs.
• Choosing an ALB solely because the workload is a website: If the defining requirement is static public IP allowlisting, select an NLB in this scenario.
• Assuming maximum capacity is the only reason instances do not launch: Service limits or failed RunInstances API calls can also prevent launches.
• Using dynamic scaling for a predictable schedule: If demand rises at a known time, scheduled scaling may be more suitable than waiting for a metric to react.
• Treating queue depth like CPU utilization: For worker applications, the backlog of messages can be a more direct scaling signal than compute utilization.
• Interpreting missing new instances in aggregate metrics as an immediate scaling failure: Step scaling may not include newly launched instances until their warm-up period expires.
• Expecting a lifecycle hook to prevent termination permanently: It pauses the termination workflow so required analysis or processing can occur.

Real-World Engineer / Analyst Notes

Start investigations by identifying the layer where the symptom occurs:

1. Architecture and exposure: Confirm that only the intended entry point is public and that web and database resources remain in private subnets.
2. Target health: Review ALB target health checks when the healthy host count falls.
3. Network path: Use VPC Flow Logs when the issue concerns connectivity, rejected flows, or ports.
4. Request behavior: Use ALB access logs to trace request origin and target handling.
5. Capacity provisioning: Use CloudTrail and Trusted Advisor when Auto Scaling cannot launch instances.
6. Scaling signal: Match the policy to the demand pattern—scheduled time, request volume, CPU behavior, or queue backlog.
7. Instance lifecycle: Account for lifecycle hooks and warm-up periods before concluding that scaling behavior is incorrect.

For a single-instance application requiring high availability, the scenario recommends an Auto Scaling group configuration with a minimum size of two, desired capacity of two, and maximum size of two. This maintains two instances rather than relying on a single running instance.

Quick Reference Summary

• Secure HA layout: ALB public; web and database private; distribute layers across Availability Zones.
• Unhealthy target: Failed consecutive health checks can remove it from ALB service.
• All targets unhealthy: Alarm on AWS/ApplicationELB HealthyHostCount <= 0.
• Source IP and target instance: ALB access logs.
• VPC connectivity and ports: VPC Flow Logs.
• Historical requests after termination: ALB access logs in S3.
• Static public IP allowlisting: Network Load Balancer.
• Predictable daily demand: Scheduled scaling.
• Worker backlog: Queue-depth scaling.
• Termination analysis: Auto Scaling lifecycle hook.
• Failed instance launches: Check Trusted Advisor and CloudTrail RunInstances requests.
• Missing new instances in step-scaling aggregates: Check whether warm-up has expired.

Flashcards

Q: A website must expose a load balancer to the internet while keeping EC2 web servers and the database inaccessible from the public internet. How should the tiers be placed?

A: Place the ALB in public subnets and the web and database tiers in private subnets. Distribute the layers across Availability Zones for high availability.

Q: An ALB target fails health checks enough times to exceed the unhealthy threshold. What does the ALB do?

A: The ALB removes the instance from service so it is no longer selected for requests, while health checks continue.

Q: Which evidence source identifies both a request’s client source IP and the target instance that processed it?

A: ALB access logs. They provide request-level information about the originator and the processing target.

Q: Users cannot connect to a web server or its ports behind an ALB. Which diagnostic source should be examined for VPC-level evidence?

A: VPC Flow Logs, because the problem is framed as a network connectivity and port issue.

Q: How can CloudWatch detect that an ALB has no healthy targets?

A: Create an alarm using the Application Load Balancer HealthyHostCount metric with a condition of less than or equal to zero.

Q: A client will only allowlist specific static public IP addresses for the load balancer. Which load-balancer type should be selected in this scenario?

A: A Network Load Balancer, because the requirement is based on static public IP addresses.

Q: An Auto Scaling group does not launch instances during a busy period, although its maximum capacity has not been reached. What should be investigated?

A: Check AWS Trusted Advisor for service-limit issues and CloudTrail for failed RunInstances requests.

Q: When would scheduled scaling be preferable to metric-driven dynamic scaling?

A: Use scheduled scaling when the demand increase occurs at a predictable time, such as the beginning of each day.

Q: An Elastic Beanstalk worker application slows as messages accumulate in its queue. Which scaling signal is most appropriate?

A: Scale based on queue depth, because the backlog directly represents pending worker workload.

Q: What feature pauses an Auto Scaling termination so an instance can be analyzed before it is removed?

A: An Auto Scaling lifecycle hook pauses the termination workflow and allows pre-termination processing.

Q: A memory-heavy application expects a large traffic spike, and scaling must reflect the request load assigned to targets. Which metric does the lesson identify?

A: Request count per target. It measures request load relative to the targets serving it.

Q: Why might newly launched instances not yet appear in aggregated metrics when step scaling is used?

A: Their warm-up period may not have expired. Until then, they may not be included in the expected aggregated metric behavior.

Q: What Auto Scaling group settings are given for a highly available single-instance application scenario?

A: Minimum size two, desired capacity two, and maximum size two, providing two running instances rather than one.

Practice Questions

Question 1

An operations team sees an ALB healthy host count fall from six to two. The remaining four EC2 instances are running, but users intermittently receive errors. What is the best first explanation to investigate?

A. The ALB automatically terminated four EC2 instances
B. The four instances failed consecutive ALB health checks and were removed from service
C. The VPC Flow Logs deleted the target registrations
D. The Auto Scaling group reached its maximum capacity

Correct answer: B

Explanation: Exceeding the unhealthy health-check threshold causes the ALB to take targets out of service. The ALB does not inherently terminate the EC2 instances.

Question 2

A security team requires clients to allowlist specific static public IP addresses for a load balancer. Which choice best matches this requirement?

A. Application Load Balancer
B. Auto Scaling lifecycle hook
C. Network Load Balancer
D. CloudWatch alarm

Correct answer: C

Explanation: The decisive requirement is static public IP allowlisting, which points to a Network Load Balancer in this lesson’s scenario.

Question 3

An Auto Scaling group has not reached maximum capacity, but no new instances appear during a traffic surge. Which investigation is most appropriate?

A. Review Trusted Advisor for service limits and CloudTrail for failed RunInstances requests
B. Replace the ALB with an NLB
C. Disable all target health checks
D. Search only the ALB access logs for database errors

Correct answer: A

Explanation: Instances can fail to launch because of service limits or failed EC2 launch requests even when the group’s configured maximum has not been reached.

Question 4

A worker application processes messages from a queue. Every morning, the backlog grows and the application slows, but it recovers later in the day. Which scaling approach is the best fit for the two stated patterns?

A. Use only ALB access logs for scaling
B. Use queue-depth scaling for the backlog and scheduled scaling for the predictable morning increase
C. Use a lifecycle hook to permanently increase capacity
D. Use VPC Flow Logs as the scaling metric

Correct answer: B

Explanation: Queue depth is appropriate for pending worker workload, while scheduled scaling can prepare capacity for a predictable daily increase.

Question 5

A team uses step scaling and notices that newly launched instances are not yet reflected in aggregated metrics. The instances are otherwise starting normally. What is the most likely explanation from this lesson?

A. The instances have been removed by the ALB
B. The NLB has rejected their static IP addresses
C. Their warm-up period has not expired
D. The database is in a public subnet

Correct answer: C

Explanation: New instances may not appear in the relevant aggregate until the Auto Scaling warm-up period has completed.

WordPress Metadata

Suggested Slug:
aws-soa-c03-elastic-load-balancing-auto-scaling-scenarios

Meta Description:
Study AWS SOA-C03 scenarios covering ALB security, health checks, access logs, CloudWatch metrics, Network Load Balancers, and EC2 Auto Scaling decisions.

Tags:
AWS, SOA-C03, Elastic Load Balancing, Application Load Balancer, Network Load Balancer, EC2 Auto Scaling, CloudWatch, VPC Flow Logs, Auto Scaling lifecycle hooks, Elastic Beanstalk