Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Site Reliability Engineer.
For SOA-C02 candidates, the confusion often lies in understanding when to use Application Load Balancers (ALBs) versus Network Load Balancers (NLBs). In production, this is about knowing exactly how protocols and latency requirements affect ELB service choice and integration with Auto Scaling and content delivery services. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
TechNova Corp operates an internal application hosted on Amazon EC2 instances in a single AWS Region. The application serves both HTTP-based requests and TCP-based custom protocol traffic. The company needs to ensure that both types of traffic are load balanced efficiently with support for an Auto Scaling group. Additionally, they want to deliver content to end users with minimal network latency using AWS services.
The Requirement #
Design a solution that supports load balancing of both TCP and HTTP traffic, works seamlessly with Auto Scaling, and leverages AWS’s low-latency network acceleration capabilities.
The Options #
- A) Create an Auto Scaling group with an Application Load Balancer (ALB). Configure an Amazon CloudFront distribution with the ALB as the origin.
- B) Create an Auto Scaling group with an Application Load Balancer (ALB). Use AWS Global Accelerator to create an accelerator with the ALB as the endpoint.
- C) Create an Auto Scaling group with a Network Load Balancer (NLB). Configure an Amazon CloudFront distribution with the NLB as the origin.
- D) Create an Auto Scaling group with a Network Load Balancer (NLB). Use AWS Global Accelerator to create an accelerator with the NLB as the endpoint.
Google adsense #
leave a comment:
Correct Answer #
D.
Quick Insight: The SOA-C02 Imperative #
- Correctly handling TCP traffic requires a Network Load Balancer, as ALBs only support HTTP/HTTPS protocols.
- AWS Global Accelerator is designed to accelerate both TCP and UDP traffic by routing over the AWS global network with lower latency than CloudFront for non-HTTP use cases.
- CloudFront cannot use a Network Load Balancer as an origin for TCP traffic (it is optimized for HTTP/HTTPS), so CloudFront is the wrong choice here.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option D
The Winning Logic #
Auto Scaling group integration requires a load balancer that supports both TCP and HTTP protocols. ALB only supports HTTP/S & WebSocket protocols, so it cannot handle the non-HTTP TCP traffic in this scenario. The Network Load Balancer operates at Layer 4 and supports TCP, UDP, and static IP addresses, making it ideal here.
For latency-sensitive global users, AWS Global Accelerator outperforms CloudFront for non-HTTP protocols by routing TCP traffic optimally via the AWS global backbone.
- In CLI or Systems Manager Automation, creating an Auto Scaling group with an NLB is straightforward and common for this use case.
- CloudFront origins must serve HTTP/S traffic, so option C (NLB + CloudFront) is invalid technically.
- Using Global Accelerator with NLB (option D) harnesses both protocol compatibility and latency optimization.
The Trap (Distractor Analysis) #
- Why not A? ALB doesn’t support non-HTTP TCP traffic, and CloudFront cannot accelerate TCP protocols, so it fails requirement.
- Why not B? ALB can’t handle TCP payloads despite AWS Global Accelerator accelerating the HTTP traffic. TCP traffic runs unaccelerated or blocked.
- Why not C? CloudFront does not work natively with NLB as origin for TCP traffic; it only supports HTTP/S protocol caching and distribution for web content.
The Technical Blueprint #
# Register NLB with Auto Scaling group example CLI snippet
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name TechNova-ASG \
--launch-configuration-name TechNova-LaunchConfig \
--min-size 2 --max-size 10 --desired-capacity 4 \
--vpc-zone-identifier subnet-12345abcde,subnet-67890fghij \
--target-group-arns arn:aws:elasticloadbalancing:region:acct-id:targetgroup/tn-nlb-tg/123abc456def
# Create a Global Accelerator and associate Network Load Balancer endpoint
aws globalaccelerator create-accelerator --name TechNovaAccelerator
aws globalaccelerator create-endpoint-group --endpoint-group-region us-east-1 --endpoint-configurations EndpointId=arn:aws:elasticloadbalancing:region:acct-id:loadbalancer/net/tn-nlb/123abc456def
The Comparative Analysis #
| Option | Operational Overhead | Automation Level | Protocol Support | Latency Optimization | Comments |
|---|---|---|---|---|---|
| A | Medium | High | HTTP/S only | CloudFront HTTP-only | Fails TCP support |
| B | Medium | High | HTTP/S only | Global Accelerator HTTP | Fails TCP support |
| C | High | Medium | TCP + HTTP | CloudFront HTTP-only | CloudFront origin incompatible |
| D | Medium | High | TCP + HTTP | Global Accelerator for all protocols | Best fit for TCP + HTTP + low latency |
Real-World Application (Practitioner Insight) #
Exam Rule #
“For the exam, always pick Network Load Balancer with Global Accelerator when you need TCP load balancing and low latency global performance.”
Real World #
“In a real production environment, combining NLB with Global Accelerator is industry best practice for applications serving non-HTTP TCP traffic with global users, ensuring seamless scaling and accelerated connectivity.”
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the SOA-C02 exam.