DDoS Protection Strategies on AWS
Distributed denial-of-service attacks are cheap to launch and expensive to absorb. The defence is architectural as much as it is a matter of enabling a service: an application that scales, caches and exposes little is difficult to take down, and one that does none of those things cannot be rescued by a firewall alone.
For how the attacks themselves work — SYN floods, amplification and reflection, and layer 7 request floods — see DDoS attack mechanics.
Five principles
Section titled “Five principles”1. Minimise the attack surface
Section titled “1. Minimise the attack surface”Every reachable endpoint is a target. Keep application and database tiers in private subnets, expose only what has to be public, and restrict network ACLs and security groups to the traffic that is actually required. Put a load balancer or CloudFront in front of the origin so that the origin’s addresses are never published.
2. Be able to scale
Section titled “2. Be able to scale”Absorbing an attack is a legitimate mitigation if the architecture can do it. Auto Scaling groups, CloudFront for content delivery, static assets served from Amazon S3, and data stores that scale horizontally all convert an outage into a bill. Decide the upper bound in advance — an unbounded scaling policy turns a denial-of-service attack into a denial-of-wallet one.
3. Protect the exposed resources
Section titled “3. Protect the exposed resources”AWS Shield Standard is on by default and mitigates the common layer 3 and 4 attacks at the edge. AWS WAF handles layer 7: rate-based rules, bot control, and the CAPTCHA and Challenge actions. Route 53 provides geographic and latency routing that can shed traffic from regions the application does not serve. AWS Shield Advanced adds automatic application-layer mitigation and cost protection.
4. Know what normal looks like
Section titled “4. Know what normal looks like”Mitigation depends on being able to tell an attack from a launch. Establish CloudWatch baselines for request rate, error rate, latency and connection counts before they are needed, and alarm on departures from them. Amazon GuardDuty raises findings for related activity such as instances participating in a botnet.
5. Have a plan
Section titled “5. Have a plan”Write down who is called, what is switched on first, what may be turned off to shed load, and who talks to customers. Rehearse it. During an attack is the wrong time to discover that nobody can raise a Shield Advanced case because nobody has the support plan.
Principle to service
Section titled “Principle to service”| Principle | AWS services |
|---|---|
| Minimise the attack surface | Network ACLs, security groups, VPC design, private subnets |
| Scale to absorb an attack | Auto Scaling groups, Amazon CloudFront, static content on Amazon S3 |
| Safeguard exposed resources | Amazon Route 53, AWS WAF, AWS Shield |
| Learn normal behaviour | Amazon CloudWatch, Amazon GuardDuty |
| Have a plan | Your incident response process |
A reference architecture
Section titled “A reference architecture”A DDoS-resilient web application on AWS typically looks like this:
What each layer contributes:
- Route 53 answers DNS at the edge and is itself protected by Shield Standard. It can route away from an affected Region or restrict by geography.
- CloudFront serves cached content from edge locations, so most requests never reach the origin, and it terminates connections far from the application.
- AWS WAF, attached to the distribution, inspects each request and applies rate-based and managed rules.
- The load balancer distributes what remains and is the only public entry point into the VPC.
- The Auto Scaling group sits in private subnets and adds capacity under load.
- The data tier scales independently; a managed store such as DynamoDB removes the fixed-capacity database that is otherwise the first thing to fall over.
Administrative access does not belong in this path. Use AWS Systems Manager Session Manager rather than a public bastion host, so there is no SSH endpoint to attack.
Ongoing work
Section titled “Ongoing work”- Review security group and network ACL rules on a schedule; they only ever accumulate.
- Re-baseline CloudWatch alarms after significant traffic changes, or they stop meaning anything.
- Test the response plan, including the escalation path to AWS Support or the Shield Response Team.
- Track AWS security bulletins and service updates, since the mitigation options change.
Phishing is worth mentioning here for one reason: the compromised machines that make up a botnet are usually recruited through it, and the same technique is used to obtain the credentials that turn a denial-of-service incident into a breach. Credential hygiene and DDoS resilience are not separate programmes.