About 6 months ago they did hire Jeff from BlackLotus. Given that timeline, I'd expect them to announce some sort of DDoS protection offering in the next few quarters.
Edit to be more specific: AWS gets hit with a lot of DDoS attacks. While all of AWS isn't unreachable during an attack, parts of it are. It's so large that you might not notice, but parts are unreachable. AWS/GCE size only makes it less noticeable, but they have no customer facing DDoS protection offerings. Their only offering is to buy more of their services. These providers don't have magical 1000000gbps links. They're regular 100gbps links (or 100gbps LACP channels) that can get overrun in large enough attacks.
It will be very interesting to see how cost effective that protection actually is and what they charge for it. Nice profit center off of FUD.
Sorry, but I'm not buying it.
and
"By using multiple PoPs, Amazon CloudFront has the inherent ability to help mitigate against both infrastructure and some application layer DDoS attacks by dispersing the traffic across multiple locations."
source: https://d0.awsstatic.com/whitepapers/DDoS_White_Paper_June20...
If you're comparing Amazon's offering to Linode, you should really compare to the protection Amazon offers on EC2 and similar VPS-like products.
Normally you wouldn't expose a EC2 instance without putting cloudfront, elbs in front of it and locking down incoming traffic to cloudfront IPs.
I've got no internal knowledge of how AWS operates, but I once went too far when load testing a new AWS machine (in terms of reqs/sec), and the traffic started getting dropped somewhere before reaching the box. Not sure if it was an elastic ip or behind an ELB, but I found it interesting.
At their scale they are basically forced to handle big attacks on regular basis. The fact that they offer this protection in their basic package is what makes them a great host[2].
They don’t get a fraction of the love Cloudflare gets, but they should.
[1] https://www.ovh.com/us/anti-ddos/hoovering-up.xml
[2] https://www.ovh.com/us/news/articles/a1171.protection-anti-d...
For a quick side project I still like DigitalOcean's hourly billing and user interface, but any machine I plan on using for a month or more are all with OVH by default.
Got hit with a DDoS to my DNS servers, I didn't see any external service disruption thanks to OVH's setup. I have several of their cheaper SoYouStart servers, and it's awesome.
> Our system has automatically detected an inbound DDoS against your droplet named xyz with the following IP Address: xx.xx.xx.xx
> As a precautionary measure, we have temporarily disabled network traffic to your droplet to protect our network and other customers. Once the attack subsides, networking will be automatically reestablished to your droplet. The networking restriction is in place for three hours and then removed.
> Please note that we take this measure only as a last resort when other filtering, routing, and network configuration changes have not been effective in routing around the DDoS attack.
> Please let us know if there are any questions, we're happy to help.
This happened mere seconds after the DDoS begun! Therefore they lied about having tried to mitigate the attack.
No amount of contacting support got me un-blackholed before the 3 hour mark, and when I popped back into the network, I was blackholed again for another 3 hours...
I moved to a $3.50/mo OpenVZ VPS at OVH, and OVH's VAC system soaked up the DDoS just fine.
With even the smallest of traffic spikes, DigitalOcean will detect it as a DDoS and immediately cut off your server for 3 hours.
If even a typical (< 100Mbit) broadband-cable connection hits your server with a spike of traffic for less than 5 minutes, your server will be taken offline for 3 hours minimum.
I've used multiple VPS providers and dedicated-server providers and DO is absolutely the worst when it comes to DDoS policy.
It’s “denial of service,” not denial of server and network resources.
Valid requests ≠ clean traffic. That just moves the attack couple of layers up.
In short, if a large amount of the attack traffic originates inside of AWS/GCE, it's better to be off in AWS/GCE.
Between the two, neither have any kind of automated tooling to detect and shutdown rogue attack instances (AFAICT). They still rely on third parties to tell them "Hey, you're sending me 300 gbps of DoS traffic."
However, how many of the people impacted by the current DDoS against Linode are only affected BECAUSE they are using Linode?
This has caused all kinds of pain for us this weekend. We use WPEngine to host some sites, who in turn host everything on Linode.
Honestly WPEngine has some real nerve charging people big bucks for a failover plan that apparently doesn't exist. This is just another of a half-dozen or so Linode failures that took us and loads of other of their customers down completely. We're lucky that we planned for this ahead of time, but we weren't 100% ready to go live on a competing service either. A lot of folks are working on their vacations right now.
I think the two questions I'll be asking every host now and into the future are:
1) Do you host your services on Linode. 2) If you do, do you failover to another provider?
A yes to the first question and a no to the second is a non-starter in my experience.
I guess what I should be really saying is that if you're hosting your platform on these services and offer some kind of redundancy, make that redundancy through another host.
David here from WPE. Are you using our HA solution (Geographic redundancy)? Did that fail? If so, did you open a ticket with support & inquire about an SLA credit?
Keep in mind we have many levels of redundancy with all of our plans, but not every plan includes Geo redundancy. Very few sites anywhere truly use hot/hot geo redundancy because of the complexity of database syncing and the expense of duplicating server environments in different data centers.
In a DDoS attack (which can happen at any data center, backbone provider, etc.) or any other data center wide outage, the only work around is Geo redundancy. Many hosts have different infrastructure providers and offsite redundancy (e.g. all of our customers enjoy offsite backups), which can allow you to recover your site even if the data center burns down, but don't necessarily provide a true hot/hot level of redundancy.
A true hot/hot configuration requires hardware in multiple locations, live database syncing, and geo load balancing. While some of our customers do purchase geo redundancy, it isn't a default part of every account.
Again, if you're an HA customer and that failed, please open a ticket. If you have questions on Geo redundancy, you can ask about it in that ticket as well. If you do move hosts, remember any host can be the victim of a DDoS attack and unless you have true hot/hot or hot/warm geo redundancy with your account, you could still be susceptible to data center wide outages like large-scale DDoS attacks.
-D