No, you'd have to build it into the nature of the internet, specifically into all the users of insecure machines and all the builders of core routers. One good thing that could be done is to have an organized response to any DDOS and to make it so easy to trigger this response that victims will lose very little in terms of downtime.
Commercial responses to DDOS (CloudFlare for instance) are useful, but only as a stop-gap measure, essentially the fact that there is a business opportunity here documents a huge flaw in the way the internet currently works.
Remember that hosting providers are as much (or even more) on the receiving end of these (for instance: when a customer of a hosting provider gets DDOS'd all the other customers will suffer too), and signaling they are part of the problem is akin to victim blaming.
It is victim blaming when people tell you it's your fault you're getting DDoSed because you can't afford several thousand dollar DDoS mitigation, it is victim blaming when someone's server simply gets null routed because they're being attacked, and it is victim blaming is when AWS hands Greatfire a crazy bandwidth bill because China attacked them.
Even if it didn't, they're at least trying. That's a much better policy than burying your head in the sand and pretending this doesn't exist like AWS and GCS do. Seriously, try to figure out what their policies are on DDoS, they don't even mention it anywhere.
Their active ignorance on this issue combined with their astronomical egress prices make them dangerous to use for public facing web sites of any serious caliber, as I've stressed multiple times on HN. I'd consider using them for behind-the-scenes stuff, but for front-facing sites? What's going to happen to your site when you get a 100GBit attack? Are you going to get charged for the bandwidth? Is your site going to get null routed? Zero information provided. Good luck.
It's also not something you can disable; it's mandatory, so as to not impact other customers. I (my employer) use AWS pretty heavily, and we've never noticed our ability to access our resources being impaired by a DDOS on other nodes, so... is it not rather obvious that AWS (and in general, the set of "cloud providers without constant outages on their status pages") have basically the same setup - network is rationed, a given resource will only be allowed so much of the pipe, and your service is unavailable until and unless you have the capacity to handle it. It's not as if it could be any other way.
The other danger seems to be in unexpected bills. Does this happen to people? Are there companies going bankrupt because they didn't notice a DDOS for a couple weeks? I've had AWS support reach out to me several times - without ever having had a paid support subscription - when my costs have gone up, just in the course of adding new functionality and expanding capacity. It's not like you set up one instance and can start egressing petabytes.
AWS does monitor their infrastructure. All accounts have limits from the get-go; you can't run up a bankruptcy-inducing bill without your phone ringing. And in all cases, your exposure below that level is rather directly under your control.
If I happen to have a use case that involves a bunch of random hosts sending me a lot of data, I expect to be able to pay the bill for the bandwidth and the capacity I provisioned to handle it. Or, if I didn't, I max out the bandwidth reserved for my resources and I don't end up seeing all the traffic. I don't see why it'd be helpful (or even meaningful) to differentiate between DDOS vs. legitimate traffic. Wouldn't a published policy on any cost or functionality difference when a DDOS is occurring provide a malicious actor with information they would need to avoid triggering that clause, so as to maximize the damage they're able to cause to your business?
I guess I'll likely change my tune if and when I'm targeted and have to deal with a DDOS (and this sentence is why i went to the throwaway, which is a shame; I'd be happy to put my name to the actual content of this post. But fate is not to be tempted.). In the meantime, though, I'm skeptical of the need, and even the desirability, of service-provider policies that have anything to do classifying the "nature" of traffic flows. It just seems completely out-of-scope for them, and in-scope for myself as the person doing the provisioning.
Their site has some details: https://www.ovh.co.uk/anti-ddos/analysis.xml
It's not easy to go after them, but neither is it easy to go after CP peddlers, and yet we still go after them and arrests are made. It's one part of a many-faceted strategy that will be needed to get some control over a problem that is clearly getting worse.
That means building DDoS protection into the nature of the web and all hosting by default (AWS and GCS I'm looking at you), and that means actively prosecuting DDoS attackers.
That also means, if you're a cloud DDoS provider, not helping to protect the sites where these attacks are marketed.