Posted by Mahdi
DDoS Protection for Business Websites: 2026 Guide
A practical DDoS readiness guide for Australian businesses covering CDN and WAF protection, caching, origin security, monitoring and incident response.
DDoS protection has become a business continuity decision, not an edge case for very large organisations. On 11 August 2026, Cloudflare reported a 519% quarter-over-quarter increase in network-layer DDoS attacks above 1 Tbps between the first and second quarters of the year. It mitigated 935 such attacks across the first half, including 805 in Q2.
The size is striking, but the speed matters just as much. Cloudflare also reported that 90.60% of the network-layer attacks it mitigated ended in under ten minutes. By the time someone sees an alert, calls a hosting provider and changes a firewall rule, the event may already have overloaded the origin, filled connection pools or triggered a chain of retries.
For an Australian small or medium business, the relevant question is not whether an attacker will send a terabit of traffic directly at your website. It is whether your website, customer portal, forms, search, APIs or online store can stay available when automated traffic exceeds what the application and hosting plan can absorb.
This guide explains the layers that reduce that risk and how to turn them into a practical readiness plan.
DDoS Attacks Are Too Fast for Manual Defence
Cloudflare's network data shows why protection must already be active at the edge before traffic reaches the application.
quarter-over-quarter growth in attacks above 1 Tbps from Q1 to Q2 2026
519%
network-layer attacks above 1 Tbps mitigated in the first half of 2026
935
attacks above 1 Tbps mitigated during Q2 alone
805
of network-layer attacks ended in under ten minutes
90.60%
What DDoS Protection Actually Needs to Cover
A distributed denial-of-service attack tries to make a website or online service unavailable by exhausting a constrained resource. The constraint could be bandwidth, network connections, firewall state, web-server workers, database connections, CPU, memory or an expensive application function.
That is why a single security control is not enough. Network-layer attacks at layers 3 and 4 try to overwhelm protocols and infrastructure. Application-layer attacks at layer 7 send requests that can look legitimate one at a time but become destructive in aggregate. A web application firewall can help with HTTP floods, bot traffic and abusive request patterns, but it is not a substitute for network capacity. Likewise, large network capacity does not prevent an attacker from repeatedly calling a slow search, login, export or checkout endpoint.
| Attack pressure | Typical target | Useful control layer |
|---|---|---|
| Volumetric network flood | Bandwidth, network devices, public IP | Always-on edge or cloud DDoS mitigation |
| Protocol or connection exhaustion | Connection tables, load balancers, transport stack | Global edge capacity, connection validation and managed mitigation |
| HTTP request flood | Web server, CMS delivery tier, APIs | WAF, adaptive mitigation, rate limits, bot controls and caching |
| Resource-intensive request | Search, reports, forms, login, cart or database | Endpoint-specific limits, queues, caching, validation and application changes |
Good protection therefore starts with an architecture map: public DNS, edge network, WAF, origin, application, database, third-party services and the routes customers rely on most.
Stop Attack Traffic Before It Reaches the Origin
Put globally distributed capacity, caching, WAF controls and rate limits in front of the application. Restrict the origin so attackers cannot bypass the edge, then monitor both layers.
Seven Layers of DDoS Readiness
1. Put authoritative DNS and traffic entry points on resilient infrastructure
If DNS or the public entry point fails, an otherwise healthy application is unreachable. Document which provider hosts DNS, what redundancy is included and which records route users to the website, APIs, portals and mail-related services.
2. Use always-on edge mitigation
Protection that is activated only after an incident creates a timing gap. A CDN or global edge service should absorb common network floods and validate connections before requests travel to the origin. Confirm what is included by default, which resources are covered and whether a separate paid protection tier is required for public IPs.
3. Configure the WAF for the application, not the brochure
A WAF in detection-only mode records traffic but does not stop it. Move to prevention after testing, keep managed rules current and add targeted rules for the routes that matter. Rate limits should reflect normal behaviour for HTML pages, APIs, login, search and transactional endpoints rather than applying one arbitrary threshold everywhere.
4. Cache what can be cached
A cached response is served at the edge instead of consuming origin capacity. AWS notes that caching and request collapsing can make the difference between an impactful and non-impactful request flood. Static assets should normally use long-lived, versioned caching. Public CMS pages may support shorter cache times, stale-if-error behaviour or selective invalidation.
5. Lock down the origin
A protected hostname is not enough if the server's public IP remains directly reachable. Restrict inbound traffic so the origin accepts requests from the approved edge or load-balancing service. Review old DNS records, forgotten subdomains, staging hosts and vendor callbacks that may expose a bypass path.
6. Build application headroom and graceful failure
Autoscaling helps, but uncontrolled scaling can create a large bill without protecting the database or third-party dependencies. Use timeouts, queues, circuit breakers, bounded concurrency, response caching and static fallback pages. Decide which features can degrade temporarily while core information, contact paths and checkout remain available.
7. Monitor and rehearse
Collect edge, WAF, origin and application signals. Know the normal request rate, cache hit ratio, response latency, error rate and expensive routes. Alerts need an owner, an escalation path and enough context to distinguish an attack from a successful campaign or seasonal traffic spike.
Protect the Journeys That Generate Revenue and Trust
Not every route has the same business value or technical cost. Start with the functions customers and staff cannot easily work around.
Enquiries and forms
Rate-limit submissions, validate requests before expensive processing and queue downstream CRM or email work so a spike does not cascade.
Login and customer portals
Combine bot controls, client verification, sensible limits and protected identity services without locking out real customers.
Search and reporting
Cache common results, limit costly filters and exports, bound query execution and separate public search from administrative reporting.
Cart, checkout and APIs
Apply route-specific controls, protect payment and stock integrations, use idempotency and keep customer-facing failure messages useful.
Questions to Ask Your Hosting or Support Provider
Many businesses are told that DDoS protection is included without being shown what that means. Ask for precise, written answers.
- Coverage: Which domains, public IPs, APIs and environments are protected at network and application layers?
- Activation: Is mitigation always on, automatically activated or manually requested?
- Origin security: Can the origin be reached directly, and how is approved edge traffic authenticated or allow-listed?
- WAF state: Is the policy blocking traffic or only logging it? Who tunes managed rules, rate limits and exceptions?
- Capacity: What can scale automatically, what is capped and what happens to databases or third-party services during a surge?
- Visibility: Which dashboards, logs, alerts and post-incident reports are available, and how long is data retained?
- Response: Who is contacted during an attack, what support tier applies and what are the escalation and communication paths?
- Cost: Can attack traffic trigger bandwidth, request, WAF, logging, autoscaling or support charges?
- Testing: When was the configuration last reviewed or safely tested, and what evidence showed it worked?
If those answers are unavailable, the immediate task is an architecture and configuration review rather than buying another dashboard.
What to Do When the Website Is Under Attack
Cloudflare lists three useful warning signs: the site becomes slow or unavailable, request or bandwidth graphs spike unexpectedly, or origin logs show abnormal request patterns. The response should follow a prepared runbook.
- Confirm the impact. Check public availability, latency, error rates, affected routes and whether staff or customers can still complete critical journeys.
- Confirm the traffic path. Verify DNS still points through the expected edge and that the origin has not been exposed or changed.
- Review active mitigation. Check network protection, WAF actions, rate-limit matches, bot controls and cache behaviour before adding emergency rules.
- Identify a durable pattern. Look at requested paths, methods, client distribution, geography, user agents and headers. Avoid broad blocks that may remove legitimate customers.
- Protect the origin. Increase caching, scale within safe limits, disable non-essential expensive functions and confirm direct origin access remains restricted.
- Communicate. Use an external status page or agreed channel if the website itself is unavailable. Give customers factual updates and a workable alternative.
- Preserve evidence and review. Retain logs and provider reports, record decisions, remove temporary rules when safe and update the readiness plan.
The ACSC's small business guidance recommends an emergency plan that names reporting paths, assistance contacts, stakeholder communication and how the business will operate if critical systems are offline. Keep a copy outside the systems that may be affected.
A 30-Day DDoS Readiness Plan for SMEs
Week 1: Map exposure and business impact
- List domains, public IPs, APIs, portals, staging hosts and third-party entry points.
- Rank customer journeys by revenue, safety, contractual or reputational impact.
- Record DNS, CDN, WAF, hosting, application and support owners.
Week 2: Verify the protective layers
- Confirm edge and network-layer coverage.
- Check WAF mode, managed rules, bot controls and route-specific rate limits.
- Measure cache hit ratio and identify safe caching opportunities.
- Test whether the origin is reachable outside the approved edge path.
Week 3: Improve observability and failure behaviour
- Create dashboards for request rate, latency, errors, cache performance and costly endpoints.
- Define alert thresholds and owners.
- Review timeouts, queues, concurrency, database limits and third-party dependencies.
- Prepare a static status or fallback experience.
Week 4: Rehearse and close gaps
- Run a tabletop scenario with business, hosting and technical contacts.
- Test escalation contacts and external communication.
- Review costs, support entitlements, logging retention and post-incident evidence.
- Schedule quarterly checks and reviews after architecture, DNS, hosting or application changes.
VaniTech can help with cloud architecture, ongoing website support and monitoring, API integration resilience and CMS architecture. The goal is not to buy every security product. It is to make the traffic path, ownership and recovery plan explicit enough that protection works when people have no time to improvise.
DDoS Protection FAQ for Business Websites
Practical answers for business owners, operations managers, ecommerce teams and technology decision-makers.
Find the weak point before traffic finds it
VaniTech can review your DNS, CDN, WAF, hosting, origin exposure, application bottlenecks, monitoring and incident response plan, then prioritise the fixes that matter to your business.