6 ms·

Not too much, like $4k extra a month i think, noticeable but not the end of the world. I assume a smaller place would just beg AWS for forgiveness and probably

Not too much, like $4k extra a month i think, noticeable but not the end of the world. I assume a smaller place would just beg AWS for forgiveness and probably get it.

HellsMaddy 4y ago
I wonder what the quickest way to rack up the highest bill on AWS is.
- maccard 4y ago
  Lambda functions on a put event on S3 that also put an object _into_ an s3 bucket is so common it's called out on the aws documentation page [0]. [0] https://docs.aws.amazon.com/lambda/latest/operatorguide/recursive-runaway.html https://docs.aws.amazon.com/lambda/latest/operatorguide/recu...
  - h4kor 4y ago
    The Lambda functions should put at least two objects into the bucket, otherwise you don't get that nice exponential growth.
    - david422 4y ago
      Ouch!
- abofh 4y ago
  Private CA + Dedidicated CloudFront IP's are the fastest ways to do it in one line-item, but most commonly massive DB instances. Why create an index when you can double the number of cores? Wait, cores don't help improve queries? But more memory, so better right? Elastic MapReduce with oversized instances used to be pretty common, but RDS is a perpetual winner for most companies I've worked with. But the typical worst case-practices, are the small companies who think avoiding vendor lock-in is a thing that matters at their scale. Look, you're never going to change cloud providers - if you do, that will be a problem you can solve then. You're never going to go multi-cloud. If you do that's a problem you can solve then. Preemptively DIY'ing everything from database copies to security to encryption is going to break you - you're now engineered on a brittle substrate of hacks with no support, all so that one day you could maybe consider saving 10% on your cloud bill by moving to a different provider. The day that migration will save you more than one engineer per month, consider it. Until then, you're just making your own costs worse. /rant
  - Brian_K_White 4y ago
    And in real life I've seen vendor lock-in cause exactly every worst fear and worse. Vendor lock-in is only tolerable when the service is so easily swapped out that it's not actually vendor lock-in. There is no valid argument for not worrying about that before it happens, and bending pretty far to avoid it. No matter how hard you work to stay as portable as possible early and at each daily step along the way, it's 10x or 1000x less than dealing with it later. If you're just talking about a pluggable service, well then by definition that's not really lock-in.
    - abofh 4y ago
      I believe you, I do, but for every company afraid to use the features of a service they pay for because of vendor lock in, I can show you five, six and seven figure bills attributable to DIY. Nothing is drop in if it's value added - if it's not value added, why are you using a vendor at all? Portability is a huge myth that eats engineers hours like a snack every single day and rarely pays off.
      - Brian_K_White 4y ago
        I believe that you believe me, so I'll rest there, since I don't want to speak actual products and timescales and business sizes and buusiness types required to make the claim more solid.
  - solatic 4y ago
    > the small companies who think avoiding vendor lock-in is a thing that matters at their scale This. If AWS ever were to even consider dramatically increasing their prices, there are players whose AWS bills are two or three or more orders of magnitude more expensive than yours who will howl and gnash their teeth and whose potential departure from AWS does far more to protect you than you could ever do to protect yourself. Similar stupidity includes spending engineering time on such issues like how to deal with an S3 outage. If S3 is down, your competitors are down too. Nobody cares.
    - 4y ago
- h4kor 4y ago
  Leak your AWS keys and a nice support team will take care of it by mining cryptocurrencies with your credit card.
  - belter 4y ago
    Plus make sure your contact details are NOT up to date so you miss the AWS warnings...
- jacquesm 4y ago
  A fork bomb that fires off GPU enabled VMs for every instance of the fork?
  - krallja 4y ago
    That will hit provisioning limits nearly instantly
    - jacquesm 4y ago
      That's ok ;)
- belter 4y ago
  A DynamoDB table provisioned at 40,000 RCU/WCU ? You have been warned!
- moondev 4y ago
  For reference launching a single u-12tb1.112xlarge and leaving it up for a month would be around 80k
KronisLV 4y ago
> Not too much, like $4k extra a month i think, noticeable but not the end of the world. It's nice that it's manageable and also a learning experience, but over here that would be like 2 months' take home salary for a software engineer. Kind of why development/test environments shouldn't have autoexpanding or scalable anything, in my experience.
- saagarjha 4y ago
  I assume larger companies can deal with temporary mistakes on the order of one engineer’s salary.
  - martopix 4y ago
    As in, paying for that engineer was a mistake all along?
    - jrockway 4y ago
      No. It doesn't really impact the company's bottom line if your software engineering org is 100 people making $20k a month and someone accidentally wastes $4k of EBS disk. It's nice if you don't waste it, of course, but "oops, filled up the disk with 'y' output" is better than "yeah actually all of those files are pretty important, I think team X is using them" because you can instantly delete it, rather than doing a multi-month project to see if team X really is using the files.
  - KronisLV 4y ago
    Oh, they certainly can, some better than others. Though personally I'd most certainly want to avoid such situations. First, to retain an air of "vaguely knows what they're doing" about me, even though everyone makes mistakes and that should be treated as something that's okay - especially if you can limit the impact of mistakes, like with automated spending limits. Secondly, because I wouldn't want to risk doing something like that in a personal project, given that my wallet is likely to be much thinner than those of organizations.
- seadan83 4y ago

Not too much, like $4k extra a month i think, noticeable but not the end of the world. I assume a smaller place would just beg AWS for forgiveness and probably get it.

HellsMaddy 4y ago

I wonder what the quickest way to rack up the highest bill on AWS is.

maccard 4y ago
Lambda functions on a put event on S3 that also put an object _into_ an s3 bucket is so common it's called out on the aws documentation page [0]. [0] https://docs.aws.amazon.com/lambda/latest/operatorguide/recursive-runaway.html https://docs.aws.amazon.com/lambda/latest/operatorguide/recu...
- h4kor 4y ago
  The Lambda functions should put at least two objects into the bucket, otherwise you don't get that nice exponential growth.
  - david422 4y ago
    Ouch!
abofh 4y ago
Private CA + Dedidicated CloudFront IP's are the fastest ways to do it in one line-item, but most commonly massive DB instances. Why create an index when you can double the number of cores? Wait, cores don't help improve queries? But more memory, so better right? Elastic MapReduce with oversized instances used to be pretty common, but RDS is a perpetual winner for most companies I've worked with. But the typical worst case-practices, are the small companies who think avoiding vendor lock-in is a thing that matters at their scale. Look, you're never going to change cloud providers - if you do, that will be a problem you can solve then. You're never going to go multi-cloud. If you do that's a problem you can solve then. Preemptively DIY'ing everything from database copies to security to encryption is going to break you - you're now engineered on a brittle substrate of hacks with no support, all so that one day you could maybe consider saving 10% on your cloud bill by moving to a different provider. The day that migration will save you more than one engineer per month, consider it. Until then, you're just making your own costs worse. /rant
- Brian_K_White 4y ago
  And in real life I've seen vendor lock-in cause exactly every worst fear and worse. Vendor lock-in is only tolerable when the service is so easily swapped out that it's not actually vendor lock-in. There is no valid argument for not worrying about that before it happens, and bending pretty far to avoid it. No matter how hard you work to stay as portable as possible early and at each daily step along the way, it's 10x or 1000x less than dealing with it later. If you're just talking about a pluggable service, well then by definition that's not really lock-in.
  - abofh 4y ago
    I believe you, I do, but for every company afraid to use the features of a service they pay for because of vendor lock in, I can show you five, six and seven figure bills attributable to DIY. Nothing is drop in if it's value added - if it's not value added, why are you using a vendor at all? Portability is a huge myth that eats engineers hours like a snack every single day and rarely pays off.
    - Brian_K_White 4y ago
      I believe that you believe me, so I'll rest there, since I don't want to speak actual products and timescales and business sizes and buusiness types required to make the claim more solid.
- solatic 4y ago
  > the small companies who think avoiding vendor lock-in is a thing that matters at their scale This. If AWS ever were to even consider dramatically increasing their prices, there are players whose AWS bills are two or three or more orders of magnitude more expensive than yours who will howl and gnash their teeth and whose potential departure from AWS does far more to protect you than you could ever do to protect yourself. Similar stupidity includes spending engineering time on such issues like how to deal with an S3 outage. If S3 is down, your competitors are down too. Nobody cares.
  - 4y ago
h4kor 4y ago
Leak your AWS keys and a nice support team will take care of it by mining cryptocurrencies with your credit card.
- belter 4y ago
  Plus make sure your contact details are NOT up to date so you miss the AWS warnings...
jacquesm 4y ago
A fork bomb that fires off GPU enabled VMs for every instance of the fork?
- krallja 4y ago
  That will hit provisioning limits nearly instantly
  - jacquesm 4y ago
    That's ok ;)
belter 4y ago
A DynamoDB table provisioned at 40,000 RCU/WCU ? You have been warned!
moondev 4y ago
For reference launching a single u-12tb1.112xlarge and leaving it up for a month would be around 80k

KronisLV 4y ago

> Not too much, like $4k extra a month i think, noticeable but not the end of the world. It's nice that it's manageable and also a learning experience, but over here that would be like 2 months' take home salary for a software engineer. Kind of why development/test environments shouldn't have autoexpanding or scalable anything, in my experience.

saagarjha 4y ago
I assume larger companies can deal with temporary mistakes on the order of one engineer’s salary.
- martopix 4y ago
  As in, paying for that engineer was a mistake all along?
  - jrockway 4y ago
    No. It doesn't really impact the company's bottom line if your software engineering org is 100 people making $20k a month and someone accidentally wastes $4k of EBS disk. It's nice if you don't waste it, of course, but "oops, filled up the disk with 'y' output" is better than "yeah actually all of those files are pretty important, I think team X is using them" because you can instantly delete it, rather than doing a multi-month project to see if team X really is using the files.
- KronisLV 4y ago
  Oh, they certainly can, some better than others. Though personally I'd most certainly want to avoid such situations. First, to retain an air of "vaguely knows what they're doing" about me, even though everyone makes mistakes and that should be treated as something that's okay - especially if you can limit the impact of mistakes, like with automated spending limits. Secondly, because I wouldn't want to risk doing something like that in a personal project, given that my wallet is likely to be much thinner than those of organizations.
seadan83 4y ago