The most effective protection against DDoS attacks for a normal website is layered and boring: put a CDN proxy in front of the origin, firewall the origin so it only trusts that proxy, add rate limiting on the expensive endpoints, and make sure the application scales rather than falling over. You do not need an enterprise contract to do most of this - you need to do the steps in the right order.
Half the advice online is “buy a big DDoS product.” The other half is a list of 30 things with no priority. Here is the priority.
Table of contents
- Step one: never expose the origin directly
- Step two: rate limit the expensive endpoints
- Step three: make the application survivable
- Step four: plan for the scale you cannot predict
- Where RunxBuild fits
- FAQ
Step one: never expose the origin directly
A DDoS attack works by sending more traffic than your server can handle. The first and cheapest defence is to make sure attackers cannot reach the server at all - they should only ever reach a proxy network large enough to absorb the flood.
Route DNS through a CDN or proxy that offers DDoS mitigation. Then firewall your origin so it accepts connections only from that provider’s IP ranges. If your public IP answers anyone who asks, every other layer is decoration.
This one step defeats the most common amateur attacks outright, because they target the IP they can find, and once you are proxied, the IP they find is not yours.
Step two: rate limit the expensive endpoints
Not every request costs the same. A static image is cheap. A search query, a login attempt, a password reset, a cart calculation - these hit the database or spin up work.
Application-layer attacks target exactly those endpoints because a small number of requests ties up a large amount of server resource. Rate limiting by IP, by token, or by fingerprint on those routes turns a cheap attack into an expensive one for the attacker.
Start with the login and any unauthenticated endpoint that writes to a database or sends email. Those are the ones that turn into outages and bills.
Step three: make the application survivable
Edge protection is probabilistic - some junk always gets through. The question is what your app does when it does.
An application that holds a database connection open per request, loads everything into memory, or has no timeout on slow clients will fall over at a fraction of the traffic a lean one handles. Connection pooling, request timeouts, and caching the hot paths are DDoS defences even though nobody files them under security.
The goal is graceful degradation: slower under load, not dead under load.
Step four: plan for the scale you cannot predict
A fixed-capacity server has a hard ceiling, and an attack is designed to find it. Autoscaling raises the ceiling automatically when load climbs and lowers it again when the spike passes, so a surge costs you money for an hour instead of costing you the site for a day.
It is not a complete DDoS answer on its own - scaling to meet a genuine flood can get expensive - which is why it sits last, after you have proxied, firewalled, and rate limited. But as the final layer it converts many would-be outages into a brief bill.
Where RunxBuild fits
RunxBuild handles the application side of that list. You deploy a service from a GitHub repo and get autoscaling between a floor plan and a ceiling plan you choose - it scales up around 80% CPU and back down at 20% - plus runtime logs and metrics in one place so you can see a traffic spike as it happens.
Put a CDN proxy in front for the edge mitigation, keep the origin firewalled to the proxy, and let the platform handle the part where the application has to not collapse. That division of labour is the whole strategy.
How this fits the rest of the stack
The cost of a project is the sum of its line items, not the headline number, and the RunxBuild hosting calculator is the right place to add them up: the service, the database, the storage, the bandwidth, each a separate figure. Model it before committing, not after the first invoice. The RunxBuild dashboard is where the running project shows its real usage in one place.
Useful related references:
- Cloudflare DDoS mitigation
- DDoS protection with a CDN
- WAF policy explained
- Autoscaling
- Services introduction
FAQ
Can a small website be the target of a DDoS attack?
Yes. Many attacks are automated, opportunistic, or aimed at whoever is sharing an IP range, and some are extortion attempts against businesses of any size. Small sites are also easier to knock over because they usually run on fixed, modest capacity, which is exactly what an attack is designed to exhaust.
Is a CDN enough on its own?
A CDN proxy handles the volumetric, network-layer attacks well, but only if your origin is firewalled so it cannot be reached directly. For application-layer floods you also need rate limiting and an application that scales or degrades gracefully. The CDN is the first layer, not the only one.
What is the difference between DDoS and high traffic?
Technically little at the packet level - both are a lot of requests. The difference is intent and shape: legitimate traffic correlates with something real and usually spreads across your pages, while an attack concentrates on a cheap-to-send, expensive-to-serve pattern. Mitigation tools look for that shape.
Does autoscaling protect against DDoS?
Partially. It keeps the application alive through a surge by adding capacity, which handles many smaller floods, but scaling to absorb a large deliberate attack gets expensive. Use it as the last layer after proxying, firewalling, and rate limiting, not as the first line.
Do I need a paid security product?
Not to start. Proxying through a CDN with free DDoS mitigation, firewalling the origin, and adding rate limiting covers the majority of real-world attacks on a normal site. Paid products add application-layer intelligence and analytics that matter more as the target gets larger.