6 ms·

This really underscores Amazon's glaring omission of a billing cutoff on Amazon web services. How hard would it be for them to let me say, cut off my services

This really underscores Amazon's glaring omission of a billing cutoff on Amazon web services. How hard would it be for them to let me say, cut off my services at $100/month? This is the main reason I'd never use AWS to host anything public.

deleted 15y ago
[deleted]
deleted 15y ago
[deleted]
eli 15y ago
I guess that would be a nice feature to offer as an option, but most people would not want their web service cut off if they get a spike in traffic.
- adgar 15y ago
  > most people would not want their web service cut off if they get a spike in traffic. Only if they are sure enough about their finances and their web service to be confident that the spike will be profitable.
- scott_w 15y ago
  That's where the "option" part comes in. People who aren't worried about the cost simply don't turn it on. Those of us who can't afford an extra £1000/month (or more if it's a dedicated attack) would love to be able to just turn it off when a threshold is hit. Users may lose access, but at least you don't go bankrupt in the process.
tybris 15y ago
End of the article: "PS: Amazon was nice enough to refund the bandwidth charges, as they considered this activity accidental and not intentional. Thanks TK!"
- pavel_lishin 15y ago
  Would they have refunded him if someone did this to him maliciously, as he points out is possible at the end of his post?
  - tantalor 15y ago
    That might also qualify as an "accident".
jonknee 15y ago
Or perhaps an email saying "We're past the limit you set, approve the overage in the next X hours by clicking this link". That way you don't cut off accidentally during a spike you want, but know about it.
- deleted 15y ago
  [deleted]
rramsden 15y ago
quite sad that Amazon still hasn't implemented bill capping yet. A lot of users want this... its been on their TODO list since 2006 https://forums.aws.amazon.com/thread.jspa?threadID=58127&start=0&tstart=75 https://forums.aws.amazon.com/thread.jspa?threadID=58127&#38...
- dredmorbius 15y ago
  The argument in favor of bill-capping: it puts the onus on Amazon (or whatever other service provider) to have the tools to identify what's causing cap-busting behavior, as they're going to eat the costs. I killed my EVDO wireless service based on a similar experience with my cell provider, after requesting multiple times that they provide me capped service. It simply wasn't worth the downside cost risk.
raverbashing 15y ago
A cutoff is good, but a triggered alarm would go a long way. For example in Linode you can configure trigger conditions for CPU (triggers in x% cpu for y time) and Network usage (there are other conditions as well) Very useful for flagging suspicious activity (or just plain accidents)
- guelo 15y ago
  Amazon did send him a warning email.
- mryan 15y ago
  You can set this up with CloudWatch - add your EC2 costs as a metric, then you can create alarms based on your desired threshold (although I'm not sure how frequently this data is updated).
  - mryan 15y ago
    I have just discovered www.cloudability.com - they generate reports to give you insights in to your AWS bill, and you can configure budget notifications. I am trying the beta now and am very impressed so far.
dredmorbius 15y ago
It's not that simple. First, the problem isn't inherent to virtual hosting services, you could just as easily get hit by this on a bare-metal site, though the interplay of S3 and Google Docs is an added dimension. Cutting off all services opens the door for a class of DoS attacks. Simply direct enough traffic at a single account's assets, and you'll knock them offline for a given billing cycle. If the attack is cheap to launch (botnet, URL referral network, etc.) it's a cheap attack. Different entities would have different cut-off and degradation policies. Better would be to identify the parameters of a specific anomalous traffic pattern, but this can be hard. A more general solution is to set asset (server side) and client (remote side) caps in tiers. You'd want generous (but not unlimited) rates for legitimate crawlers, your own infrastructure, and major clients. The rest of the Net generally gets a lower service level. Such rules are not trivial to set up, and assistance through AWS or other cloud hosting providers would be very useful.
- mikeryan 15y ago
  Cutting off all services opens the door for a class of DoS attacks. Simply direct enough traffic at a single account's assets, and you'll knock them offline for a given billing cycle. I dont' see this as a real issue (the potential DOS is there, but not a real problem with having a bandwidth metric kill switch). I'd assume this would be a configurable setting and would have to be enabled by choice. In the author's case I'm sure he'd prefer to have is service cut off prior to running up a 1k bill. If one of my test instances started bleeding bandwidth I'd prefer for it to just get killed then to rack up an ungainly bill. If its your production service then don't configure a cutoff.
- nknight 15y ago
  > you'll knock them offline for a given billing cycle Er... Because caps can never be raised mid-cycle?
  - dredmorbius 15y ago
    Sure, they could be, but it's still a pretty blunt alerting system. Depending on the organization, though, you'd have to get purchase approval on the overage, etc. That will depend on specifics. Makes for sticky questions to answer there as well, which is another argument for putting better management tools at the cloud level.
jeffbarr 15y ago
We are already testing a billing charges monitor that works through CloudWatch. Here's some more info: http://blog.bitnami.org/2011/12/monitor-your-estimated-aws-charges-with.html http://blog.bitnami.org/2011/12/monitor-your-estimated-aws-c...
- sgrytoyr 15y ago
  Looks great! Any chance that this will become available to accounts without Premium support in the future?

deleted 15y ago

[deleted]

deleted 15y ago

[deleted]

eli 15y ago

I guess that would be a nice feature to offer as an option, but most people would not want their web service cut off if they get a spike in traffic.

adgar 15y ago
> most people would not want their web service cut off if they get a spike in traffic. Only if they are sure enough about their finances and their web service to be confident that the spike will be profitable.
scott_w 15y ago
That's where the "option" part comes in. People who aren't worried about the cost simply don't turn it on. Those of us who can't afford an extra £1000/month (or more if it's a dedicated attack) would love to be able to just turn it off when a threshold is hit. Users may lose access, but at least you don't go bankrupt in the process.

tybris 15y ago

End of the article: "PS: Amazon was nice enough to refund the bandwidth charges, as they considered this activity accidental and not intentional. Thanks TK!"

pavel_lishin 15y ago
Would they have refunded him if someone did this to him maliciously, as he points out is possible at the end of his post?
- tantalor 15y ago
  That might also qualify as an "accident".

jonknee 15y ago

Or perhaps an email saying "We're past the limit you set, approve the overage in the next X hours by clicking this link". That way you don't cut off accidentally during a spike you want, but know about it.

deleted 15y ago
[deleted]

rramsden 15y ago

quite sad that Amazon still hasn't implemented bill capping yet. A lot of users want this... its been on their TODO list since 2006 https://forums.aws.amazon.com/thread.jspa?threadID=58127&start=0&tstart=75 https://forums.aws.amazon.com/thread.jspa?threadID=58127&#38...

dredmorbius 15y ago
The argument in favor of bill-capping: it puts the onus on Amazon (or whatever other service provider) to have the tools to identify what's causing cap-busting behavior, as they're going to eat the costs. I killed my EVDO wireless service based on a similar experience with my cell provider, after requesting multiple times that they provide me capped service. It simply wasn't worth the downside cost risk.

raverbashing 15y ago

A cutoff is good, but a triggered alarm would go a long way. For example in Linode you can configure trigger conditions for CPU (triggers in x% cpu for y time) and Network usage (there are other conditions as well) Very useful for flagging suspicious activity (or just plain accidents)

guelo 15y ago
Amazon did send him a warning email.
mryan 15y ago
You can set this up with CloudWatch - add your EC2 costs as a metric, then you can create alarms based on your desired threshold (although I'm not sure how frequently this data is updated).
- mryan 15y ago
  I have just discovered www.cloudability.com - they generate reports to give you insights in to your AWS bill, and you can configure budget notifications. I am trying the beta now and am very impressed so far.

dredmorbius 15y ago

It's not that simple. First, the problem isn't inherent to virtual hosting services, you could just as easily get hit by this on a bare-metal site, though the interplay of S3 and Google Docs is an added dimension. Cutting off all services opens the door for a class of DoS attacks. Simply direct enough traffic at a single account's assets, and you'll knock them offline for a given billing cycle. If the attack is cheap to launch (botnet, URL referral network, etc.) it's a cheap attack. Different entities would have different cut-off and degradation policies. Better would be to identify the parameters of a specific anomalous traffic pattern, but this can be hard. A more general solution is to set asset (server side) and client (remote side) caps in tiers. You'd want generous (but not unlimited) rates for legitimate crawlers, your own infrastructure, and major clients. The rest of the Net generally gets a lower service level. Such rules are not trivial to set up, and assistance through AWS or other cloud hosting providers would be very useful.

mikeryan 15y ago
Cutting off all services opens the door for a class of DoS attacks. Simply direct enough traffic at a single account's assets, and you'll knock them offline for a given billing cycle. I dont' see this as a real issue (the potential DOS is there, but not a real problem with having a bandwidth metric kill switch). I'd assume this would be a configurable setting and would have to be enabled by choice. In the author's case I'm sure he'd prefer to have is service cut off prior to running up a 1k bill. If one of my test instances started bleeding bandwidth I'd prefer for it to just get killed then to rack up an ungainly bill. If its your production service then don't configure a cutoff.
nknight 15y ago
> you'll knock them offline for a given billing cycle Er... Because caps can never be raised mid-cycle?
- dredmorbius 15y ago
  Sure, they could be, but it's still a pretty blunt alerting system. Depending on the organization, though, you'd have to get purchase approval on the overage, etc. That will depend on specifics. Makes for sticky questions to answer there as well, which is another argument for putting better management tools at the cloud level.

jeffbarr 15y ago

We are already testing a billing charges monitor that works through CloudWatch. Here's some more info: http://blog.bitnami.org/2011/12/monitor-your-estimated-aws-charges-with.html http://blog.bitnami.org/2011/12/monitor-your-estimated-aws-c...

sgrytoyr 15y ago
Looks great! Any chance that this will become available to accounts without Premium support in the future?