DDoS Readiness Checklist for AWS-Hosted Applications

Retrospective: this article looks back at events from December 2016, written in 2026 with the benefit of hindsight.

Use this checklist to check whether an AWS-hosted application is ready for a denial-of-service attack. Each "no" is a gap to plan for.

Architecture

• Public traffic enters through CloudFront, an Application Load Balancer or API Gateway — not directly to instances.
• The origin only accepts traffic from your CDN or load balancer.
• Static content is cached at the edge to absorb load.
• Auto Scaling is configured with sensible maximums (and a budget alarm).
• DNS is hosted on Route 53 or another resilient provider; registrar lock is on.

Protection

• AWS WAF is attached with managed rule groups enabled.
• Rate-based rules exist for the whole site and for login and API paths.
• Shield Advanced has been evaluated for revenue-critical applications.
• Geo-restrictions are ready to apply if your customer base is regional.

Monitoring

• CloudWatch alarms fire on traffic spikes, error rates and WAF blocks.
• Alarms reach a person who can act at any hour.
• WAF and load balancer logs are retained and searchable.

Response

• A written runbook covers who declares the incident and which mitigations to apply.
• Contacts for AWS Support (and the Shield Response Team, if subscribed) are documented.
• Customer communication templates are ready for a status page.
• The runbook has been rehearsed in the last 12 months.

After an event

• Hold a short review: what was hit, how fast you noticed, what you would change.
• Update thresholds and the runbook.

If more than a third of these are unchecked, start with the architecture items. Putting a CDN and WAF in front of an application closes the largest gaps for the least effort.