9 ms·

I don't get why you're so stressed out by AWS billing. From my experience, once you've worked a bit seriously with AWS, billing is not a blackbox anymore and y

I don't get why you're so stressed out by AWS billing. From my experience, once you've worked a bit seriously with AWS, billing is not a blackbox anymore and you're able to plan ahead without too much surprise. If you're still worried, there's also the option of settings alerts on budget spent and forecast of budget, which should settle the debate. (these are also part of the API, so you can deploy and configure these alerts through terraform)

danjac 5y ago
> once you've worked a bit seriously with AWS Kind of a chicken-and-egg situation, no? Unless you're on the company dime, learning to work with AWS entails that risk. A beginner simply won't know how to configure all of these things.
- RobRivera 5y ago
  the risk is minimalized by reading the docs and proper planning. EDIT: got to love the holy downvoters
  - danjac 5y ago
    That's the point though. A beginner is going to make mistakes and should be able to learn in a safe environment. Think of a student on a tight budget at college or in a bootcamp, who has to learn AWS because it's on the curriculum.
    - fleaaaa 5y ago
      Exactly, it's pretty common for them to shoot their own foot with a couple of hundred dollar bill, just for one tiny instance with additional options that 'you have to do'. IMO AWS is deliberately make these things happen and reimburse it later with excuses. It's rather a strategy at this point it seems like.
      - danjac 5y ago
        I don't think it's so much a money-grabbing strategy as the problem that AWS is less a suite of unified services and more a litter of puppies fighting in a sack. With that kind of org chart it's difficult to have a unified, simple billing experience with good beginner training-wheels and on-ramps.
        geoduck14 5y ago
        >AWS is less a suite of unified services and more a litter of puppies fighting in a sack Can I quote you on this? I'm going to quote you.
    - _wldu 5y ago
      Doesn't the free tier cover a lot of what a student may want to do?
      - lmz 5y ago
        The free tier is just that, a tier (not a hard limit), and will not cover any use above the tier.
    - tenaciousDaniel 5y ago
      Yep. I'm a novice at AWS. Last year I heard about RDS, and tried playing around with it. I thought I had shut it down because I clicked some button that looked like it was the turn-off button. I let it go on for a few months, only to discover that I had been charged $1,500. The one thing that really pissed me off was how easy it was to set up vs how hard it was to take it back down. I can't remember the details, but basically you cannot simply turn off an RDS instance only in the UI (even though you can turn it on in the UI). You have to install the SDK and perform some (seemingly complex) commands. I tried explaining that I was a beginner, and that I made this mistake by accident, and that they could easily see that I had not actually used this instance at all or even put any data into the DB. But they wanted this huge list of things from me in order to refund it, like a super in-depth explanation of how it happened. Really shitty experience overall. So I canceled my AWS account and likely won't go back until I have a job that pays me to learn and use it.
      - scrose 5y ago
        You can ‘Stop’ a DB and ‘Terminate’ a DB through the UI. If you have deletion protection turned on, you can only stop the DB until it’s turned off, which can also be done through the UI. You most likely stopped the DB, but the problem there is that AWS will automatically turn on the DB after 7 days. You also still get charged for storage for the time your DB is off. Sorry to hear that though. I know it’s a really sucky situation to be in.
        tenaciousDaniel 5y ago
        Ah yeah, I remember now. You could turn off the DB, but there was some other kind of scaffolding thing that I was still getting charged for. It seemed like an RDS-specific thing. They had to point me to a tutorial for turning that piece off.
        geoduck14 5y ago
        >You could turn off the DB, but there was some other kind of scaffolding thing that I was still getting charged for. It is a feature! /s
  - triska 5y ago
    I did not downvote this, but I have a comment: The risk is not "minimalized by reading the docs and proper planning". To minimize something means to reduce it to the smallest possible amount, and I do not like to take any chances whatsoever when a huge excess bill is a possible outcome of a single misconfigured setting that can only be ruled out by reading hundreds if not thousands of pages of documentation and then following the documentation without mistake to the letter. There is a clear possible solution for reliably preventing any amount of unintended overpayment, and that would be to configure a hard billing limit that can never be exceeded, no matter what else is being configured. All services that generate additional costs would simply have to stop or be removed if the configured limit is exceeded. That would truly minimize the risk, because any configuration error I make will then not lead to excess payment if I configure such a limit and the cloud provider respects it.
  - yjftsjthsd-h 5y ago
    You're getting downvoted because you're victim blaming; a newbie shouldn't have to master anything to avoid a surprise bill.
pastage 5y ago
I do not have the time for alerts in my personal life, billing PTSD is not fun.
GordonS 5y ago
A bad actor could hammer any publicity available services, and you could be hit with an enormous egress bandwidth bill. Spend alerts can help with this, but spend is only calculated every 24h or so, so it's far from a panacea.
- gonzo41 5y ago
  Not if you're doing simple and sensible things like using Cloud Front, and setting limits with API Gateway.
  - arriu 5y ago
    What if you're using something like grpc?
- triska 5y ago
  This is also one of the things I fear most when running a service in the cloud: A huge bill due to excessive network usage triggered for example by a search engine, web scraper etc. I consider it very unfortunate that "capped cost" has gone somewhat out of fashion, and nowadays many major cloud providers bill excess usage rather than cutting off or slowing down traffic etc. Here is a simple Bash script that monitors outgoing eth0 traffic (once per second) and automatically shuts down the instance once it is greater than 1 TB: #!/bin/bash # shut down instance if outgoing traffic > 1 TB # 1 MB limit=$((10**6)) # 10 MB limit=$((10**7)) # 1 GB limit=$((10**9)) # 1 TB limit=$((10**12)) while true do date tx=$(< /sys/class/net/eth0/statistics/tx_bytes) echo "$tx (limit: $limit)" if (( tx > limit )) then echo cutting systemctl poweroff fi sleep 1 done If you save it as cutnetwork.sh in /home/admin/cutnetwork.sh, you can run it as a systemd service: [Unit] Description=Cut Network [Service] UMask=022 Environment=LANG=en_US.utf8 Restart=on-abort StartLimitInterval=60 StartLimitBurst=5 WorkingDirectory=/home/admin ExecStart=bash cutnetwork.sh [Install] WantedBy=multi-user.target This simplistic approach may require adjustments depending on network settings and operating environment, and will not work for example if the instance is rebooted during the billing period, since that resets the counter. I would much prefer a hard-coded setting that reliable works on the instance itself, or a reliable hard billing limit that reliably turns off the service if the accumulated cost exceeds the set amount.
ghaff 5y ago
I know experienced people who have woken up to several thousand dollar AWS bill they didn’t expect. And the large cloud providers have clearly indicated by their actions that they’re simply not interested in implementing hard cost circuit breakers. I use AWS very lightly but I totally understand why someone wouldn’t.
- user3939382 5y ago
  > the large cloud providers have clearly indicated by their actions that they’re simply not interested in implementing hard cost circuit breakers. I agree, my term for this is “bad faith”. I recently had a free $200 credit for Azure. I setup their default MariaDB instance for a side project, figuring I’d get my feet wet with Azure. I didn’t spend time evaluating the cost bc I figured, how much could the default be if I haven’t cranked up the instance resources at all? Turns out the answer is more than $10/day which I discovered when authentication failed to my test DB. Back to Digital Ocean.
  - ghaff 5y ago
    My term for it is “you’re not their use case.” For better or worse, they’ve prioritized usages that would much rather have an unexpected few thousand dollar bill than have services paused or shutdown unexpectedly.
    - civilized 5y ago
      But computers can behave differently based on user choice. Right? So there could be a user option to cut service beyond a fixed spend. It wouldn't be hard to implement, and tons of people would use it. They don't do it. It's not a tragic case of priority and limited engineering resources. They like surprise bills, just like hospitals do. Businesspeople love it when you come to their service and click through their Russian novel of a service agreement that would take a team of lawyers to parse. Once you do that, your money belongs to them! It's their court, their rules! They love it!
      - 5y ago
Tenoke 5y ago
>I don't get why you're so stressed out by AWS billing. Presumably because if you haven't used it and are digging deeper there's so many services with different types of billing that it can be hard to keep track. And who among us has not left something running way after it should've been shut down accidentally..
- genewitch 5y ago
  I never have left something running like that, but someone else in the org had made a service that would spin a t1.micro for end users to experiment with one of our saas offerings. Iirc the instance would run for 24 hours maybe, and then shut down and delete itself. It didn't delete the ebs volume, though. So about 6-9 months after I left I get an email, please delete these, I'm too busy to use the UI to delete these 8000 ebs volumes. I don't know how much that cost, even for the final bill month, but it took me an hour and a half to write and test the script, hour and a half to run it, and an hour for my time to get reqs and prepare an invoice. I've managed AWS for corps that Have spends in the millions of dollars per year (and knowing how split brain org charts are, possibly millions per month) on AWS and other platforms. Actually I know it was in the millions per month range, two transcoder services were costing $250k/m. Obnoxious.
igetspam 5y ago
Until you're into EC2-Other and then you have to follow various guides to figure out most of what that means. Even then, it's black box billing that Teams even struggle to explain. I spend a ridiculous amount on egress that's nearly impossible to track.
the_jeremy 5y ago
If I'm using my own money on a personal project, I do not want "alerts". I want a maximum budget spend per X, where X is a small increment of time, like an hour or day. Supporting hobbyist projects would absolutely lead to higher AWS adoption, at least in smaller companies.

danjac 5y ago

> once you've worked a bit seriously with AWS Kind of a chicken-and-egg situation, no? Unless you're on the company dime, learning to work with AWS entails that risk. A beginner simply won't know how to configure all of these things.

RobRivera 5y ago
the risk is minimalized by reading the docs and proper planning. EDIT: got to love the holy downvoters
- danjac 5y ago
  That's the point though. A beginner is going to make mistakes and should be able to learn in a safe environment. Think of a student on a tight budget at college or in a bootcamp, who has to learn AWS because it's on the curriculum.
  - fleaaaa 5y ago
    Exactly, it's pretty common for them to shoot their own foot with a couple of hundred dollar bill, just for one tiny instance with additional options that 'you have to do'. IMO AWS is deliberately make these things happen and reimburse it later with excuses. It's rather a strategy at this point it seems like.
    - danjac 5y ago
      I don't think it's so much a money-grabbing strategy as the problem that AWS is less a suite of unified services and more a litter of puppies fighting in a sack. With that kind of org chart it's difficult to have a unified, simple billing experience with good beginner training-wheels and on-ramps.
      - geoduck14 5y ago
        >AWS is less a suite of unified services and more a litter of puppies fighting in a sack Can I quote you on this? I'm going to quote you.
  - _wldu 5y ago
    Doesn't the free tier cover a lot of what a student may want to do?
    - lmz 5y ago
      The free tier is just that, a tier (not a hard limit), and will not cover any use above the tier.
  - tenaciousDaniel 5y ago
    Yep. I'm a novice at AWS. Last year I heard about RDS, and tried playing around with it. I thought I had shut it down because I clicked some button that looked like it was the turn-off button. I let it go on for a few months, only to discover that I had been charged $1,500. The one thing that really pissed me off was how easy it was to set up vs how hard it was to take it back down. I can't remember the details, but basically you cannot simply turn off an RDS instance only in the UI (even though you can turn it on in the UI). You have to install the SDK and perform some (seemingly complex) commands. I tried explaining that I was a beginner, and that I made this mistake by accident, and that they could easily see that I had not actually used this instance at all or even put any data into the DB. But they wanted this huge list of things from me in order to refund it, like a super in-depth explanation of how it happened. Really shitty experience overall. So I canceled my AWS account and likely won't go back until I have a job that pays me to learn and use it.
    - scrose 5y ago
      You can ‘Stop’ a DB and ‘Terminate’ a DB through the UI. If you have deletion protection turned on, you can only stop the DB until it’s turned off, which can also be done through the UI. You most likely stopped the DB, but the problem there is that AWS will automatically turn on the DB after 7 days. You also still get charged for storage for the time your DB is off. Sorry to hear that though. I know it’s a really sucky situation to be in.
      - tenaciousDaniel 5y ago
        Ah yeah, I remember now. You could turn off the DB, but there was some other kind of scaffolding thing that I was still getting charged for. It seemed like an RDS-specific thing. They had to point me to a tutorial for turning that piece off.
        geoduck14 5y ago
        >You could turn off the DB, but there was some other kind of scaffolding thing that I was still getting charged for. It is a feature! /s
- triska 5y ago
  I did not downvote this, but I have a comment: The risk is not "minimalized by reading the docs and proper planning". To minimize something means to reduce it to the smallest possible amount, and I do not like to take any chances whatsoever when a huge excess bill is a possible outcome of a single misconfigured setting that can only be ruled out by reading hundreds if not thousands of pages of documentation and then following the documentation without mistake to the letter. There is a clear possible solution for reliably preventing any amount of unintended overpayment, and that would be to configure a hard billing limit that can never be exceeded, no matter what else is being configured. All services that generate additional costs would simply have to stop or be removed if the configured limit is exceeded. That would truly minimize the risk, because any configuration error I make will then not lead to excess payment if I configure such a limit and the cloud provider respects it.
- yjftsjthsd-h 5y ago
  You're getting downvoted because you're victim blaming; a newbie shouldn't have to master anything to avoid a surprise bill.

pastage 5y ago

I do not have the time for alerts in my personal life, billing PTSD is not fun.

GordonS 5y ago

A bad actor could hammer any publicity available services, and you could be hit with an enormous egress bandwidth bill. Spend alerts can help with this, but spend is only calculated every 24h or so, so it's far from a panacea.

gonzo41 5y ago
Not if you're doing simple and sensible things like using Cloud Front, and setting limits with API Gateway.
- arriu 5y ago
  What if you're using something like grpc?
triska 5y ago
This is also one of the things I fear most when running a service in the cloud: A huge bill due to excessive network usage triggered for example by a search engine, web scraper etc. I consider it very unfortunate that "capped cost" has gone somewhat out of fashion, and nowadays many major cloud providers bill excess usage rather than cutting off or slowing down traffic etc. Here is a simple Bash script that monitors outgoing eth0 traffic (once per second) and automatically shuts down the instance once it is greater than 1 TB: #!/bin/bash # shut down instance if outgoing traffic > 1 TB # 1 MB limit=$((10**6)) # 10 MB limit=$((10**7)) # 1 GB limit=$((10**9)) # 1 TB limit=$((10**12)) while true do date tx=$(< /sys/class/net/eth0/statistics/tx_bytes) echo "$tx (limit: $limit)" if (( tx > limit )) then echo cutting systemctl poweroff fi sleep 1 done If you save it as cutnetwork.sh in /home/admin/cutnetwork.sh, you can run it as a systemd service: [Unit] Description=Cut Network [Service] UMask=022 Environment=LANG=en_US.utf8 Restart=on-abort StartLimitInterval=60 StartLimitBurst=5 WorkingDirectory=/home/admin ExecStart=bash cutnetwork.sh [Install] WantedBy=multi-user.target This simplistic approach may require adjustments depending on network settings and operating environment, and will not work for example if the instance is rebooted during the billing period, since that resets the counter. I would much prefer a hard-coded setting that reliable works on the instance itself, or a reliable hard billing limit that reliably turns off the service if the accumulated cost exceeds the set amount.

ghaff 5y ago

I know experienced people who have woken up to several thousand dollar AWS bill they didn’t expect. And the large cloud providers have clearly indicated by their actions that they’re simply not interested in implementing hard cost circuit breakers. I use AWS very lightly but I totally understand why someone wouldn’t.

user3939382 5y ago
> the large cloud providers have clearly indicated by their actions that they’re simply not interested in implementing hard cost circuit breakers. I agree, my term for this is “bad faith”. I recently had a free $200 credit for Azure. I setup their default MariaDB instance for a side project, figuring I’d get my feet wet with Azure. I didn’t spend time evaluating the cost bc I figured, how much could the default be if I haven’t cranked up the instance resources at all? Turns out the answer is more than $10/day which I discovered when authentication failed to my test DB. Back to Digital Ocean.
- ghaff 5y ago
  My term for it is “you’re not their use case.” For better or worse, they’ve prioritized usages that would much rather have an unexpected few thousand dollar bill than have services paused or shutdown unexpectedly.
  - civilized 5y ago
    But computers can behave differently based on user choice. Right? So there could be a user option to cut service beyond a fixed spend. It wouldn't be hard to implement, and tons of people would use it. They don't do it. It's not a tragic case of priority and limited engineering resources. They like surprise bills, just like hospitals do. Businesspeople love it when you come to their service and click through their Russian novel of a service agreement that would take a team of lawyers to parse. Once you do that, your money belongs to them! It's their court, their rules! They love it!
    - 5y ago

Tenoke 5y ago

>I don't get why you're so stressed out by AWS billing. Presumably because if you haven't used it and are digging deeper there's so many services with different types of billing that it can be hard to keep track. And who among us has not left something running way after it should've been shut down accidentally..

genewitch 5y ago
I never have left something running like that, but someone else in the org had made a service that would spin a t1.micro for end users to experiment with one of our saas offerings. Iirc the instance would run for 24 hours maybe, and then shut down and delete itself. It didn't delete the ebs volume, though. So about 6-9 months after I left I get an email, please delete these, I'm too busy to use the UI to delete these 8000 ebs volumes. I don't know how much that cost, even for the final bill month, but it took me an hour and a half to write and test the script, hour and a half to run it, and an hour for my time to get reqs and prepare an invoice. I've managed AWS for corps that Have spends in the millions of dollars per year (and knowing how split brain org charts are, possibly millions per month) on AWS and other platforms. Actually I know it was in the millions per month range, two transcoder services were costing $250k/m. Obnoxious.

igetspam 5y ago

Until you're into EC2-Other and then you have to follow various guides to figure out most of what that means. Even then, it's black box billing that Teams even struggle to explain. I spend a ridiculous amount on egress that's nearly impossible to track.

the_jeremy 5y ago

If I'm using my own money on a personal project, I do not want "alerts". I want a maximum budget spend per X, where X is a small increment of time, like an hour or day. Supporting hobbyist projects would absolutely lead to higher AWS adoption, at least in smaller companies.