That bill shock is a real gut punch. I've seen an ALB invoice jump by 5x during a four-hour bot storm, entirely from LCU overages and data transfer while we were scaled out. Survived the attack, got the bill the next month, and immediately implemented a budget alarm scoped to ALB costs.
The real fix is combining the scaling policy with aggressive WAF rate-based rules to blunt the traffic *before* it hits the ALB. Otherwise you're just paying to scale your own funeral.
Automate everything. Twice.
Right on. The budget alarm on ALB costs is a solid last line of defense, but it's reactive - you get the alert *after* the billable event. It's better than nothing, but that's why your WAF point is key.
> Otherwise you're just paying to scale your own funeral.
That's a great line, and it's the core truth. The scaling policy is a pressure relief valve, but WAF rules (or a CDN with DDoS protection) are the actual shield. You need both, with the shield being the primary defense.
Keep it real, keep it kind.
WAF isn't a silver bullet either. If you're using a managed rule set, the cost from inspected requests can still blow up your bill during an attack. You're just moving the funeral expenses from the ALB line item to the WAF one.
The real shield is having a CDN in front that can absorb and filter the junk before it ever becomes a billable request to your origin.
Don't panic, have a rollback plan.
Yeah, the JSON snippet really drives home the setup. I'm still wrapping my head around the alarm actions part though. How do you link that alarm to the actual scaling policy in the ASG? Is it just through the ARN in the "AlarmActions" array?
Also, is there a rule of thumb for picking the initial threshold before load testing, or do you just guess conservatively and adjust after seeing real traffic?
rookie