After basic ALB routing, I wanted to explore the really advanced stuff the kind of routing that powers modern SaaS applications and high-performance systems. I built two projects:<\/p>
These projects taught me how production systems handle complex traffic patterns and scale automatically under load.<\/p>
Basic ALB routes by path (\/app1) or host (app1.domain.com). Advanced ALB can route based on:<\/p>
HTTP Header Routing:<\/p>
Mobile app sends: Header: “User-Agent: MyApp\/iOS\/1.0”<\/p>
\u2192 Routes to mobile-optimized backend<\/p>
API client sends: Header: “API-Version: v2”<\/p>
\u2192 Routes to v2 API servers<\/p>
Query String Redirects:<\/p>
Old marketing URL: example.com?campaign=summer-sale<\/p>
\u2192 Redirects to: marketing.example.com\/summer-sale<\/p>
Documentation link: docs.com?topic=kubernetes<\/p>
\u2192 Redirects to: docs.com\/kubernetes\/<\/p>
This is my actual configuration for routing based on custom HTTP headers:<\/p>
rules = {\n # Rule 1: Route App1 based on custom header\n myapp1-rule = {\n actions = [{\n type = \"weighted-forward\"\n target_groups = [\n {\n target_group_key = \"mytg1\"\n weight = 1\n }\n ]\n stickiness = {\n enabled = true\n duration = 3600\n }\n }]\n conditions = [{\n http_header = {\n http_header_name = \"custom-header\"\n values = [\"app-1\", \"app1\", \"my-app-1\"]\n }\n }]\n }<\/code><\/pre>How HTTP header routing works:<\/p>
Request with header:<\/p>
GET \/ HTTP\/1.1\nHost: myapps11.rezaops.com\ncustom-header: app-1<\/code><\/pre>ALB checks:<\/p>
- Does request have custom-header? YES<\/li>
- Is value app-1, app1, or my-app-1? YES<\/li>
- Route to mytg1 (App1 target group)<\/li><\/ol>
Request without header or different value:<\/p>
GET \/ HTTP\/1.1\nHost: myapps11.rezaops.com<\/code><\/pre>\u2192 Falls through to default action (fixed response)<\/p>
Multiple header values:<\/p>
values = [\"app-1\", \"app1\", \"my-app-1\"]<\/code><\/pre>ALB accepts ANY of these values. This is useful for:<\/p>
- Different naming conventions: app-1 vs app1<\/li>
- Legacy compatibility: old clients use my-app-1, new use app1<\/li>
- API versioning: v1, version-1, api-v1<\/li><\/ul>
Testing HTTP header routing:<\/p>
# Route to App1\ncurl -H \"custom-header: app-1\" https:\/\/myapps11.rezaops.com\n\n# Route to App2\ncurl -H \"custom-header: app-2\" https:\/\/myapps11.rezaops.com\n\n# No header - fixed response\ncurl https:\/\/myapps11.rezaops.com<\/code><\/pre>2. Query String Redirect Rule<\/h3>
Redirect based on URL query parameters:<\/p>
my-redirect-query = {\n priority = 3\n actions = [{\n type = \"redirect\"\n status_code = \"HTTP_302\"\n host = \"stacksimplify.com\"\n path = \"\/aws-eks\/\"\n query = \"\" # Clear original query string\n protocol = \"HTTPS\"\n }]\n\n conditions = [{\n query_string = {\n key = \"website\"\n value = \"aws-eks\"\n }\n }]\n}<\/code><\/pre>What happens step by step:<\/p>
User visits: https:\/\/myapps11.rezaops.com?website=aws-eks<\/p>
- ALB receives request<\/li>
- Checks query string: website=aws-eks<\/li>
- Matches condition \u2713<\/li>
- Returns HTTP 302 redirect:<\/li><\/ol>
HTTP\/1.1 302 Found\nLocation: https:\/\/stacksimplify.com\/aws-eks\/<\/code><\/pre>- Browser automatically follows redirect<\/li>
- User ends up at external website<\/li><\/ol>
Why HTTP 302 instead of 301?<\/p>
302 = Temporary Redirect<\/p>
- Browser doesn’t cache<\/li>
- Can change redirect destination later<\/li>
- Analytics track each redirect<\/li>
- Used for: campaigns, tracking, temporary moves<\/li><\/ul>
301 = Permanent Redirect<\/p>
- Browser caches forever<\/li>
- SEO passes page rank<\/li>
- Can’t easily change later<\/li>
- Used for: permanent URL changes<\/li><\/ul>
Clearing query string:<\/p>
query = \"\"<\/code><\/pre>Original URL: myapps11.rezaops.com?website=aws-eks&utm=source Redirect to: stacksimplify.com\/aws-eks\/ (no query string)<\/p>
To keep query string:<\/p>
query = \"#{query_string}\" # Pass through original<\/code><\/pre>3. Host Header Redirect Rule<\/h3>
Redirect entire domains to external URLs:<\/p>
my-redirect-hh = {\n priority = 4\n actions = [{\n type = \"redirect\"\n status_code = \"HTTP_302\"\n host = \"stacksimplify.com\"\n path = \"\/azure-aks\/azure-kubernetes-service-introduction\/\"\n query = \"\"\n protocol = \"HTTPS\"\n }]\n\n conditions = [{\n host_header = {\n values = [\"azure-aks11.rezaops.com\"]\n }\n }]\n}<\/code><\/pre>Use case: Domain migration<\/p>
Old domain: azure-aks11.rezaops.com New domain: stacksimplify.com\/azure-aks\/…<\/p>
Any request to old domain redirects to new location:<\/p>
https:\/\/azure-aks11.rezaops.com<\/p>
\u2192 https:\/\/stacksimplify.com\/azure-aks\/azure-kubernetes-service-introduction\/<\/p>
https:\/\/azure-aks11.rezaops.com\/docs<\/p>
\u2192 https:\/\/stacksimplify.com\/azure-aks\/azure-kubernetes-service-introduction\/<\/p>
https:\/\/azure-aks11.rezaops.com\/anything<\/p>
\u2192 https:\/\/stacksimplify.com\/azure-aks\/azure-kubernetes-service-introduction\/<\/p>
Notice: ALL paths redirect to same destination. To preserve paths:<\/p>
path = \"\/azure-aks#{path}\" # Appends original path<\/code><\/pre>4. Rule Priority and Evaluation Order<\/h3>myapp1-rule = { } # Priority 1 (automatic)\nmyapp2-rule = { } # Priority 2 (automatic)\nmy-redirect-query = {\n priority = 3 # Explicit priority\n}\nmy-redirect-hh = {\n priority = 4\n}<\/code><\/pre>How ALB evaluates rules:<\/p>
- Starts with priority 1<\/li>
- Checks conditions<\/li>
- If match \u2192 Execute action, STOP<\/li>
- If no match \u2192 Try priority 2<\/li>
- Continue until match or reach default action<\/li><\/ol>
Example request flow:<\/p>
Request: GET \/?website=aws-eks HTTP\/1.1<\/p>
- Priority 1 (HTTP header): No custom-header \u2192 SKIP<\/li>
- Priority 2 (HTTP header): No custom-header \u2192 SKIP<\/li>
- Priority 3 (Query string): Has website=aws-eks \u2192 MATCH! Redirect to stacksimplify.com<\/li><\/ul>
Request: GET \/ HTTP\/1.1 with custom-header: app-1<\/p>
- Priority 1 (HTTP header): Has custom-header: app-1 \u2192 MATCH! Forward to App1<\/li>
- (Rules 2, 3, 4 never evaluated)<\/li><\/ul>
5. DNS Configuration for Multiple Domains<\/h3>
I create Route53 records for different routing scenarios:<\/p>
# Main domain for header-based routing\nresource \"aws_route53_record\" \"default_dns\" {\n zone_id = data.aws_route53_zone.mydomain.zone_id\n name = \"myapps11.rezaops.com\"\n type = \"A\"\n \n alias {\n name = module.alb.dns_name\n zone_id = module.alb.zone_id\n evaluate_target_health = true\n }\n}\n\n# Domain for host header redirect\nresource \"aws_route53_record\" \"app1_dns\" {\n zone_id = data.aws_route53_zone.mydomain.zone_id\n name = \"azure-aks11.rezaops.com\"\n type = \"A\"\n \n alias {\n name = module.alb.dns_name\n zone_id = module.alb.zone_id\n evaluate_target_health = true\n }\n}<\/code><\/pre>Both domains point to SAME ALB! The ALB decides what to do based on Host header:<\/p>
myapps11.rezaops.com \u2192 Check for custom headers or query strings<\/p>
azure-aks11.rezaops.com \u2192 Redirect to stacksimplify.com<\/p>
Project 2: Network Load Balancer with Auto Scaling<\/h3>NLB vs ALB – When to Use Each<\/h3>
Application Load Balancer (Layer 7):<\/p>
- HTTP\/HTTPS only<\/li>
- Content-based routing (paths, headers, cookies)<\/li>
- SSL termination<\/li>
- WebSocket support<\/li>
- Slower (parses HTTP)<\/li><\/ul>
Network Load Balancer (Layer 4):<\/p>
- TCP\/UDP\/TLS protocols<\/li>
- Ultra-low latency (~100 microseconds)<\/li>
- Millions of requests per second<\/li>
- Static IP addresses<\/li>
- Preserves source IP<\/li>
- No content inspection<\/li><\/ul>
When I use NLB:<\/p>
- Gaming servers (low latency critical)<\/li>
- IoT applications (millions of devices)<\/li>
- TCP-based protocols (non-HTTP)<\/li>
- Need static IP for whitelisting<\/li>
- Extreme performance requirements<\/li><\/ul>
Technical Implementation – NLB<\/h3>1. NLB Configuration<\/h3>module \"nlb\" {\n source = \"terraform-aws-modules\/alb\/aws\"\n version = \"9.11.0\"\n\n name = \"mynlb\"\n load_balancer_type = \"network\" # KEY DIFFERENCE\n vpc_id = module.vpc.vpc_id\n subnets = module.vpc.public_subnets\n dns_record_client_routing_policy = \"availability_zone_affinity\"\n security_groups = [module.loadbalancer_sg.security_group_id]\n \n enable_deletion_protection = false<\/code><\/pre>Key parameter: dns_record_client_routing_policy<\/p>
dns_record_client_routing_policy = \"availability_zone_affinity\"<\/code><\/pre>This means:<\/p>
Client in us-east-1a \u2192 Connects to NLB node in us-east-1a<\/p>
Client in us-east-1b \u2192 Connects to NLB node in us-east-1b<\/p>
Benefits:<\/p>
- Lower latency (same AZ = faster)<\/li>
- Lower data transfer costs (no cross-AZ charges)<\/li>
- Better performance for latency-sensitive apps<\/li><\/ul>
Alternative value:<\/p>
dns_record_client_routing_policy = \"any_availability_zone\"<\/code><\/pre>Distributes traffic evenly, ignoring client location.<\/p>
2. TCP and TLS Listeners<\/h3>listeners = {\n # Listener 1: Plain TCP\n my-tcp = {\n port = 80\n protocol = \"TCP\"\n forward = {\n target_group_key = \"mytg1\"\n }\n }\n \n # Listener 2: TLS (encrypted TCP)\n my-tls = {\n port = 443\n protocol = \"TLS\"\n certificate_arn = module.acm.acm_certificate_arn\n forward = {\n target_group_key = \"mytg1\"\n }\n }\n}<\/code><\/pre>TCP vs TLS listeners:<\/p>
TCP (port 80):<\/p>
- No encryption<\/li>
- Load balancer passes packets directly<\/li>
- Client connects directly to backend instance<\/li>
- Fastest (no decryption overhead)<\/li><\/ul>
TLS (port 443):<\/p>
- Load balancer terminates SSL\/TLS<\/li>
- Decrypts traffic at NLB<\/li>
- Forwards plain HTTP to backends<\/li>
- Client sees encrypted connection<\/li>
- Backend sees plain HTTP<\/li><\/ul>
Traffic flow comparison:<\/p>
ALB with HTTPS:<\/p>
Client --HTTPS--> ALB --HTTP--> Instance\n (decrypts here)<\/code><\/pre>NLB with TLS:<\/p>
Client --TLS--> NLB --TCP--> Instance\n (decrypts here)<\/code><\/pre>NLB with TCP passthrough:<\/p>
Client --TCP--> NLB --TCP--> Instance\n (no encryption, pure speed)<\/code><\/pre>3. Auto Scaling Group with Launch Template<\/h3>
Launch template defines what instances look like:<\/p>
resource \"aws_launch_template\" \"my_launch_template\" {\n name = \"my_launch_template\"\n description = \"My launch template\"\n image_id = data.aws_ami.amzlinux2.id\n instance_type = var.instance_type\n \n vpc_security_group_ids = [module.public_bastion_sg.security_group_id]\n key_name = var.instance_keypair\n user_data = filebase64(\"${path.module}\/app1-install.sh\")\n \n ebs_optimized = true\n update_default_version = true\n\n block_device_mappings {\n device_name = \"\/dev\/sda1\"\n ebs {\n volume_size = 20\n volume_type = \"gp2\"\n delete_on_termination = true\n }\n }\n \n monitoring {\n enabled = true # Detailed CloudWatch monitoring\n }\n \n tag_specifications {\n resource_type = \"instance\"\n tags = {\n Name = \"myasg\"\n }\n }\n}<\/code><\/pre>ebs_optimized = true<\/p>
- Dedicated bandwidth for EBS operations<\/li>
- Better disk I\/O performance<\/li>
- Recommended for production<\/li><\/ul>
update_default_version = true<\/p>
- New version becomes default automatically<\/li>
- ASG uses latest version for new instances<\/li>
- Old instances keep old version until replaced<\/li><\/ul>
Monitoring enabled:<\/p>
- 1-minute metrics instead of 5-minute<\/li>
- More granular CloudWatch data<\/li>
- Costs extra ($2.10\/instance\/month)<\/li>
- Essential for auto scaling responsiveness<\/li><\/ul>
4. Auto Scaling Group Configuration<\/h3>resource \"aws_autoscaling_group\" \"my_asg\" {\n name_prefix = \"myasg_\"\n desired_capacity = 2\n max_size = 5\n min_size = 2\n vpc_zone_identifier = module.vpc.public_subnets\n\n target_group_arns = [module.nlb.target_groups[\"mytg1\"].arn] \n health_check_type = \"EC2\"\n\n launch_template {\n id = aws_launch_template.my_launch_template.id\n version = aws_launch_template.my_launch_template.latest_version\n }\n \n instance_refresh {\n strategy = \"Rolling\"\n preferences {\n min_healthy_percentage = 50\n }\n triggers = [ \"desired_capacity\" ]\n }\n\n tag {\n key = \"Owners\"\n value = \"Web-Team\"\n propagate_at_launch = true\n }\n}<\/code><\/pre>Instance refresh – Rolling updates:<\/p>
instance_refresh {\n strategy = \"Rolling\"\n preferences {\n min_healthy_percentage = 50\n }\n}<\/code><\/pre>What happens when I update launch template:<\/p>
Without instance refresh:<\/p>
- Old instances keep running<\/li>
- New instances use new template<\/li>
- Mixed versions in ASG<\/li><\/ul>
With instance refresh (rolling):<\/p>
- ASG has 4 instances<\/li>
- Terminates 2 instances (50%)<\/li>
- Launches 2 new instances with new template<\/li>
- Waits for health checks<\/li>
- Terminates remaining 2 old instances<\/li>
- Launches 2 more new instances<\/li>
- All instances now use new template<\/li><\/ol>
min_healthy_percentage = 50:<\/p>
- Always keeps 50% instances running<\/li>
- Lower = faster updates, more risk<\/li>
- Higher = slower updates, safer<\/li><\/ul>
For production:<\/p>
min_healthy_percentage = 90 # Keep 90% healthy<\/code><\/pre>health_check_type = “EC2”<\/p>
Options:<\/p>
- EC2 – Checks if instance is running<\/li>
- ELB – Checks load balancer health checks<\/li><\/ul>
I use EC2 for simplicity. For production, use ELB for better reliability.<\/p>
5. Target Tracking Scaling Policy<\/h3>
This is the magic that makes auto scaling work:<\/p>
resource \"aws_autoscaling_policy\" \"avg_cpu_policy_greater_than_xx\" {\n name = \"avg-cpu-policy-greater-than-xx\"\n policy_type = \"TargetTrackingScaling\"\n autoscaling_group_name = aws_autoscaling_group.my_asg.id \n estimated_instance_warmup = 180 # 3 minutes\n \n target_tracking_configuration {\n predefined_metric_specification {\n predefined_metric_type = \"ASGAverageCPUUtilization\"\n }\n target_value = 50.0 # Keep CPU at 50%\n }\n}<\/code><\/pre>How target tracking works:<\/p>
Current state: 2 instances, average CPU = 30%<\/p>
- Below target (50%)<\/li>
- No action needed<\/li><\/ul>
Traffic increases: 2 instances, average CPU = 70%<\/p>
- Above target!<\/li>
- ASG: “I need more instances to bring average down to 50%”<\/li>
- Launches 1 more instance<\/li>
- Now: 3 instances, average CPU = 47% \u2713<\/li><\/ul>
Traffic increases more: 3 instances, average CPU = 65%<\/p>
- Still above target<\/li>
- Launches 1 more instance<\/li>
- Now: 4 instances, average CPU = 49% \u2713<\/li><\/ul>
Traffic decreases: 4 instances, average CPU = 30%<\/p>
- Below target<\/li>
- ASG: “I have too many instances”<\/li>
- Terminates 1 instance<\/li>
- Now: 3 instances, average CPU = 40% \u2713<\/li><\/ul>
estimated_instance_warmup = 180<\/p>
When new instance launches:<\/p>
- Takes ~60 seconds to boot<\/li>
- Another ~60 seconds to install Apache<\/li>
- Another ~30 seconds to get first traffic<\/li>
- Total: ~150 seconds to be “production ready”<\/li><\/ul>
During warmup period:<\/p>
- Instance doesn’t count toward CPU average<\/li>
- Prevents premature scaling decisions<\/li>
- Avoids scaling thrashing<\/li><\/ul>
Alternative predefined metrics:<\/p>
# Request count per target\npredefined_metric_type = \"ALBRequestCountPerTarget\"\ntarget_value = 1000 # 1000 requests per instance\n\n# Network bytes in\npredefined_metric_type = \"ASGAverageNetworkIn\"\ntarget_value = 10000000 # 10MB\/s\n\n# Network bytes out\npredefined_metric_type = \"ASGAverageNetworkOut\"\ntarget_value = 20000000 # 20MB\/s<\/code><\/pre>6. Scheduled Scaling Actions<\/h3>
Scale based on predictable patterns:<\/p>
# Scale up at 7 AM UTC\nresource \"aws_autoscaling_schedule\" \"increase_capacity_7am\" {\n scheduled_action_name = \"increase-capacity-7am\"\n min_size = 2\n max_size = 10\n desired_capacity = 8\n start_time = \"2030-03-30T11:00:00Z\"\n recurrence = \"00 09 * * *\" # Cron: 9 AM UTC daily\n autoscaling_group_name = aws_autoscaling_group.my_asg.id \n}\n\n# Scale down at 9 PM UTC\nresource \"aws_autoscaling_schedule\" \"decrease_capacity_5pm\" {\n scheduled_action_name = \"decrease-capacity-5pm\"\n min_size = 2\n max_size = 10\n desired_capacity = 2\n start_time = \"2030-03-30T21:00:00Z\"\n recurrence = \"00 21 * * *\" # Cron: 9 PM UTC daily\n autoscaling_group_name = aws_autoscaling_group.my_asg.id\n}<\/code><\/pre>Cron syntax explained:<\/p>
00 09 * * *\n\u2502 \u2502 \u2502 \u2502 \u2502\n\u2502 \u2502 \u2502 \u2502 \u2514\u2500 Day of week (0-7, 0=Sunday)\n\u2502 \u2502 \u2502 \u2514\u2500\u2500\u2500 Month (1-12)\n\u2502 \u2502 \u2514\u2500\u2500\u2500\u2500\u2500 Day of month (1-31)\n\u2502 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 Hour (0-23)\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 Minute (0-59)<\/code><\/pre>Examples:<\/p>
00 09 * * * # Every day at 9 AM\n00 09 * * 1-5 # Weekdays at 9 AM\n00 *\/4 * * * # Every 4 hours\n30 08 1 * * # First day of month at 8:30 AM\n00 18 * * 5 # Every Friday at 6 PM<\/code><\/pre>Real-world scheduling patterns:<\/p>
E-commerce site:<\/p>
# Black Friday preparation\nrecurrence = \"00 06 25 11 *\" # Nov 25 at 6 AM\ndesired_capacity = 20\n\n# Post-Christmas scale down\nrecurrence = \"00 00 27 12 *\" # Dec 27 at midnight\ndesired_capacity = 5<\/code><\/pre>Business hours scaling:<\/p>
# Monday-Friday 8 AM\nrecurrence = \"00 08 * * 1-5\"\ndesired_capacity = 10\n\n# Monday-Friday 6 PM\nrecurrence = \"00 18 * * 1-5\"\ndesired_capacity = 2<\/code><\/pre>scheduled vs target tracking:<\/p>
Both can run simultaneously!<\/p>
- Scheduled: Sets capacity at specific times<\/li>
- Target tracking: Adjusts capacity based on metrics<\/li><\/ul>
Example scenario:<\/p>
7 AM: Scheduled action sets desired=8<\/p>
8 AM: Traffic spike, CPU>50%, target tracking adds 2 more \u2192 10 instances<\/p>
9 AM: Traffic normal, CPU<50%, target tracking removes 2 \u2192 8 instances<\/p>
9 PM: Scheduled action sets desired=2<\/p>
7. SNS Notifications for Scaling Events<\/h3>
Get email alerts when ASG scales:<\/p>
# Create SNS topic\nresource \"aws_sns_topic\" \"myasg_sns_topic\" {\n name = \"myasg-sns-topic-${random_pet.this.id}\"\n}\n\n# Subscribe email\nresource \"aws_sns_topic_subscription\" \"myasg_sns_topic_subscription\" {\n topic_arn = aws_sns_topic.myasg_sns_topic.arn\n protocol = \"email\"\n endpoint = \"rezachegini1994@gmail.com\"\n}\n\n# Configure notifications\nresource \"aws_autoscaling_notification\" \"myasg_notifications\" {\n group_names = [aws_autoscaling_group.my_asg.id]\n notifications = [\n \"autoscaling:EC2_INSTANCE_LAUNCH\",\n \"autoscaling:EC2_INSTANCE_TERMINATE\",\n \"autoscaling:EC2_INSTANCE_LAUNCH_ERROR\",\n \"autoscaling:EC2_INSTANCE_TERMINATE_ERROR\",\n ]\n topic_arn = aws_sns_topic.myasg_sns_topic.arn \n}<\/code><\/pre>Email notifications I receive:<\/p>
Instance launch:<\/p>
Event: autoscaling:EC2_INSTANCE_LAUNCH\nTime: 2025-01-15 10:30:00\nGroup: myasg_20250115\nCause: Target tracking increased capacity\nInstance: i-0abcd1234efgh5678<\/code><\/pre>Instance terminate:<\/p>
Event: autoscaling:EC2_INSTANCE_TERMINATE\nTime: 2025-01-15 22:15:00\nGroup: myasg_20250115\nCause: Scheduled action decreased capacity\nInstance: i-0abcd1234efgh5678<\/code><\/pre>Launch error:<\/p>
Event: autoscaling:EC2_INSTANCE_LAUNCH_ERROR\nTime: 2025-01-15 15:45:00\nGroup: myasg_20250115\nCause: Insufficient capacity in AZ\nStatusMessage: We currently do not have sufficient t2.micro capacity<\/code><\/pre>random_pet for unique names:<\/p>
resource \"random_pet\" \"this\" {\n length = 2\n}\n# Generates: \"mighty-panda\", \"happy-tiger\", etc.<\/code><\/pre>I use this to avoid SNS topic name conflicts when deploying multiple times.<\/p>
Comparing Load Balancer Types<\/h3>Application Load Balancer (ALB)<\/h3>- OSI Layer: Layer 7 (Application)<\/li>
- Protocols: HTTP, HTTPS, WebSocket<\/li>
- Latency: ~10\u201320 ms<\/li>
- Throughput: ~100K requests\/sec<\/li>
- Routing: Path, host header, query string<\/li>
- SSL Termination: Yes<\/li>
- Static IP: No (DNS-based)<\/li>
- Client IP: Lost (forwarded via headers)<\/li>
- Health Checks: HTTP-based<\/li>
- Best for: Web apps, APIs, microservices<\/li><\/ul>
Network Load Balancer (NLB)<\/h3>- OSI Layer: Layer 4 (Transport)<\/li>
- Protocols: TCP, UDP, TLS<\/li>
- Latency: ~100 microseconds<\/li>
- Throughput: Millions of requests\/sec<\/li>
- Routing: IP + Port<\/li>
- SSL Termination: Yes (TLS listeners)<\/li>
- Static IP: Yes (per AZ)<\/li>
- Client IP: Preserved<\/li>
- Health Checks: TCP-based<\/li>
- Best for: Gaming, IoT, real-time & non-HTTP workloads<\/li><\/ul>
Real-World Lessons<\/h3>1. HTTP Header Case Sensitivity<\/h3>
My mistake:<\/p>
http_header_name = \"Custom-Header\"<\/code><\/pre>Tested with:<\/p>
curl -H \"custom-header: app-1\" https:\/\/myapps11.rezaops.com<\/code><\/pre>Result: Didn’t work!<\/p>
Why: HTTP headers are case-insensitive in HTTP spec, but ALB conditions are case-sensitive!<\/p>
Solution:<\/p>
http_header_name = \"custom-header\" # Lowercase<\/code><\/pre>Or configure ALB to normalize headers (not available in Terraform module).<\/p>
2. Query String Encoding<\/h3>
Problem: URL with spaces: https:\/\/myapps11.rezaops.com?website=aws eks<\/p>
Didn’t match:<\/p>
query_string = {\n key = \"website\"\n value = \"aws eks\"\n}<\/code><\/pre>Reason: Browsers URL-encode spaces: aws%20eks<\/p>
Solution:<\/p>
value = \"aws%20eks\" # URL-encoded<\/code><\/pre>Or use wildcards:<\/p>
value = \"aws*\" # Matches \"aws eks\", \"aws-eks\", \"aws_eks\"<\/code><\/pre>3. Auto Scaling Cooldown vs Warmup<\/h3>
I confused these two concepts:<\/p>
Cooldown (old, don’t use):<\/p>
- Wait period after scaling action<\/li>
- Blocks ALL scaling during cooldown<\/li>
- Too rigid for modern applications<\/li><\/ul>
Warmup (modern, use this):<\/p>
estimated_instance_warmup = 180<\/code><\/pre>- Excludes new instances from metrics temporarily<\/li>
- Doesn’t block other scaling actions<\/li>
- Better for dynamic workloads<\/li><\/ul>
Target tracking uses warmup automatically. Only set cooldown for simple scaling policies.<\/p>
4. ASG Instance Refresh Failed<\/h3>
Error:<\/p>
Instance refresh failed: MinHealthyPercentage requirement not met<\/code><\/pre>What happened:<\/p>
- Tried to refresh 4 instances<\/li>
- min_healthy_percentage = 75<\/li>
- Killed 1 instance (3 left = 75%)<\/li>
- New instance took 5 minutes to be healthy<\/li>
- During that time, only 3 healthy (75%)<\/li>
- Tried to kill another \u2192 Would drop to 2 (50%)<\/li>
- Refused!<\/li><\/ul>
Solution:<\/p>
min_healthy_percentage = 50 # More flexible<\/code><\/pre>Or increase instance count before refresh:<\/p>
# Scale up first\naws autoscaling set-desired-capacity --auto-scaling-group-name myasg --desired-capacity 6\n\n# Then refresh\naws autoscaling start-instance-refresh --auto-scaling-group-name myasg<\/code><\/pre>5. NLB Preserves Source IP – Security Group Issues<\/h3>
Problem: Private instance security group:<\/p>
ingress_cidr_blocks = [module.vpc.vpc_cidr_block] # 10.0.0.0\/16<\/code><\/pre>Connections from internet failed health checks!<\/p>
Why: NLB preserves source IP. Client IP is public (not from VPC).<\/p>
Solution for NLB:<\/p>
ingress_cidr_blocks = [\"0.0.0.0\/0\"] # Allow from anywhere<\/code><\/pre>Or use ALB which rewrites source IP to ALB’s IP (inside VPC).<\/p>
6. SNS Email Subscription Requires Confirmation<\/h3>
What happened: Deployed infrastructure, never got emails!<\/p>
Why: SNS requires email confirmation:<\/p>
- Terraform creates subscription<\/li>
- AWS sends confirmation email<\/li>
- Must click “Confirm subscription”<\/li>
- Then emails start working<\/li><\/ol>
Can’t automate this for security.<\/p>
Check spam folder for confirmation email!<\/p>
7. Launch Template Version Management<\/h3>
Problem: Updated launch template, but ASG used old version!<\/p>
Cause:<\/p>
version = \"$Latest\" # Wrong!<\/code><\/pre>This doesn’t auto-update. Terraform doesn’t know to trigger refresh.<\/p>
Solution:<\/p>
version = aws_launch_template.my_launch_template.latest_version<\/code><\/pre>Plus:<\/p>
update_default_version = true # In launch template<\/code><\/pre>Now when template changes, ASG knows to refresh.<\/p>
Cost Comparison<\/h3>Advanced ALB Routing:<\/h3>
Same as basic ALB:<\/p>
- ALB: $22.50\/month<\/li>
- LCU: ~$5-10\/month<\/li>
- ACM: Free<\/li>
- Route53: $0.50\/month<\/li>
- EC2 (4 instances): $28\/month<\/li>
- Total: ~$56-61\/month<\/li><\/ul>
NLB with Auto Scaling:<\/h3>- NLB: $22.50\/month<\/li>
- NLCU: ~$5-15\/month (depends on traffic)<\/li>
- EC2 (2-5 instances): $14-35\/month (dynamic)<\/li>
- CloudWatch: $2\/month (detailed monitoring)<\/li>
- SNS: $0.50\/month<\/li>
- Total: ~$44-75\/month (varies with load)<\/li><\/ul>
Cost optimization for ASG: Set aggressive scale-down:<\/p>
min_size = 1 # Scale to 1 at night\nrecurrence = \"00 22 * * *\" # 10 PM scale down\ndesired_capacity = 1<\/code><\/pre>Deployment Commands<\/h3>Advanced ALB:<\/h3>cd ALB-HTTPHeader-QueryString-Redirects\/terraform-manifests\nterraform init\nterraform apply\n\n# Test HTTP header routing\ncurl -H \"custom-header: app-1\" https:\/\/myapps11.rezaops.com\n\n# Test query string redirect\ncurl -I \"https:\/\/myapps11.rezaops.com?website=aws-eks\"\n\n# Test host header redirect\ncurl -I \"https:\/\/azure-aks11.rezaops.com\"<\/code><\/pre>NLB with Auto Scaling:<\/h3>cd AWS-NLB-Network-Load-Balancer\/terraform-manifests\nterraform init\nterraform apply\n\n# Confirm SNS email subscription\n# Check email and click confirmation link\n\n# Test NLB\ncurl http:\/\/nlb.rezaops.com\ncurl https:\/\/nlb.rezaops.com\n\n# Watch auto scaling\naws autoscaling describe-auto-scaling-groups \\\n --auto-scaling-group-names myasg_xxxxx\n\n# Trigger scaling by generating load\nab -n 100000 -c 100 http:\/\/nlb.rezaops.com\/<\/code><\/pre>What I Learned<\/h3>- ALB routing is incredibly flexible – Can route on almost any HTTP attribute<\/li>
- NLB is for performance – When latency matters more than features<\/li>
- Auto Scaling is not magic – Requires careful tuning of thresholds and warmup times<\/li>
- Scheduled scaling saves money – Scale down during off-hours<\/li>
- Target tracking is powerful – Set target CPU and forget about it<\/li>
- Instance refresh is crucial – For zero-downtime deployments<\/li>
- Monitoring is essential – SNS alerts help catch issues early<\/li><\/ol>","protected":false},"excerpt":{"rendered":"
Why I Built These Projects After basic ALB routing, I wanted to explore the really advanced stuff the kind of routing that…<\/p>\n","protected":false},"author":2,"featured_media":151,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_rezaops_part":"3","_rezaops_linkedin_url":"https:\/\/www.linkedin.com\/pulse\/advanced-load-balancing-aws-http-headers-query-strings-reza-chegini-wv8lc\/","footnotes":""},"categories":[85,10],"tags":[90,60,8,93,87],"series":[86],"class_list":["post-149","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-aws","category-devops","tag-auto-scaling","tag-aws","tag-devops","tag-load-balancer","tag-terraform","series-aws-with-terraform"],"jetpack_featured_media_url":"https:\/\/rezachegini.com\/wp-content\/uploads\/2026\/10\/advanced-load-balancing-aws-cover.png","_links":{"self":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts\/149","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=149"}],"version-history":[{"count":1,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts\/149\/revisions"}],"predecessor-version":[{"id":150,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts\/149\/revisions\/150"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/media\/151"}],"wp:attachment":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=149"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=149"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=149"},{"taxonomy":"series","embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fseries&post=149"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}