28 ms·

AWS costs every programmer should know

382 points by dizzih 7y ago

TruffleMuffin 7y ago
Useful to have also the 'network' costs from an edge location to a user. That one just bit me so its close in my mind right now.
Hamuko 7y ago
Every programmer? In our team, only like two, maybe three programmers are concerned about our AWS architecture at all. I don't really know why everyone in the team should know how much the individual components of AWS cost. They should just know how to not write performance-destroying code that mandates scaling instances up.
- growtofill 7y ago
  The title is a mock of “Latency Numbers Every Programmer Should Know”[0], although these are (a) limited to a popular, yet not exclusive platform, (b) subjective to change at any moment. [0]: https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html https://people.eecs.berkeley.edu/~rcs/research/interactive_l...
- bpicolo 7y ago
  Eagerly await the follow up: Falsehoods programmers believe about AWS costs
  - jraph 7y ago
    And then: - 10 reasons why AWS costs so much. #7 is mind-boggling. - AWS costs considered harmful
    - jsty 7y ago
      Don't forget: - "Developer uses one weird trick to reduce cloud bills by 97%. AWS hates him!"
      - deleted 7y ago
        [deleted]
    - c3534l 7y ago
      10 Falsehoods Every Programmer Should Know (Number 3 will SHOCK you!)
- chrisseaton 7y ago
  It's a pattern title. It's not meant to be taken literally and most reasonable people wouldn't read it that way.
- mjlee 7y ago
  I don't think that every programmer should know it off by heart. I do think it should be a reasonably common skill to make common tradeoffs without too much investigation. Besides, the title is an homage to the Latency Numbers article which follows a similar concept. You don't need to memorise numbers, but you probably should be able to reason about them in very vague terms.
- katzgrau 7y ago
  It's not just code, and it's not always obvious. AWS' tools (as robust as they seem at first) may not give you the low-level insight that you need to understand where you can really cut down on expenses. I just reduced my AWS bill from about $5.5k/mo to $3k/mo. The rise in price was only slightly outpacing the app growth for a while, and it was very gradual. When the forecasted bill was $6k it became a major priority.
matwood 7y ago
I find it easier to use this tool for quick estimations, and it is more encompassing: https://calculator.s3.amazonaws.com/index.html https://calculator.s3.amazonaws.com/index.html
koolba 7y ago
Any analysis of AWS costs that doesn't start off talking about outbound data transfer pricing, let alone mention it at all, is useless for anything beyond pure-CPU workloads.
- privateSFacct 7y ago
  Agreed.
oldjokes 7y ago
I have worked at two startups now where we made the fatal mistake of being profitable. If you make this mistake then the investors will swoop in and demand you spend more on marketing and AWS infrastructure, because we're scaling up to 5 billion users of course. Of course we started spending all the money on new people and AWS, and soon there was no money. At one point we were dumping like $15K a month on AWS for a dozen unnecessary over-engineered toys that nobody was using. This is the real cost of AWS. I'd love to see Amazon's data on money invested vs actual user traffic for small startups, that's got to be some of the most interesting and valuable data on earth. Forget companies, I'll bet Jeff is sitting around predicting when entire industries rise and fall weeks before anyone else based just on this data.
- grogenaut 7y ago
  How is Amazon supposed to know actual user numbers? That's app specific.
  - deleted 7y ago
    [deleted]
  - fouc 7y ago
    They probably meant page views and such.
  - biesnecker 7y ago
    You can't get exact numbers, but for consumer-facing products you can estimate it via unique IPs hitting the load balancers, etc.
    - grogenaut 7y ago
      That would require amazon gathering customer information and possibly GDPR data on the usage of all of it's customers, which is a thing amazon doesn't do, and you don't want your cloud providers doing.
- tyingq 7y ago
kakkksaknmdm 7y ago
Any AWS metric that doesnt have the network costs is useless. If anyone wants a dedicated unmetered server up to 20gbps i'd recommend datapacket.com.
- corrigible 7y ago
  Agreed. The cloud is great if your workload is low-egress... AWS/GCP bandwidth pricing is predatory at times.
danpalmer 7y ago
I’d add to this, numbers every SaaS sales person should know with the resources used by their services, or roughly what the marginal cost of a new customer is. Most SaaS services have very high markup, but get a few bits of infra wrong, over promise on a few things, and use expensive AWS services, and suddenly you’re selling $500 a month of AWS services for $99 a month. This is an easy mistake to make, I’ve seen it happen with these figures, and it only takes a few wrong assumptions across the engineering and sales teams.
zawerf 7y ago
For certain apps, bandwidth cost is stupid expensive on AWS. For example I've been following the development of an online manga reading site (mangadex.org) that is now pushing over 1PB/month of images. If they had built it on aws, even at the lowest rate of $0.02/GB with cloudfront/S3, it would be $20,000 per month. But they ended up paying nothing by using cloudflare who gave them unmetered bandwidth. (well, until they got throttled earlier this year but they got out of that by upgrading to a measly $200/month plan)
- kasey_junk 7y ago
  I thought most of the clouds offered free ingress?
  - dharmab 7y ago
    MangaDex serves very high resolution scans of comic pages (egress)
    - kasey_junk 7y ago
      Ah. I misunderstood the “push” part of the comment.
  - contras1970 7y ago
    yes, but the topic is the price of egress. i thought this was obvious to everybody: public clouds want to lock you in, so they make it very cheap and easy to get data in, but charge stupendous amounts for getting your data out.
- stingraycharles 7y ago
  Bandwidth is insanely expensive on all clouds. If you’re a large consumer, however, you can usually negotiate a much better rate.
  - krn 7y ago
    > Bandwidth is insanely expensive on all clouds. OVH Public Cloud[1] offers unmetered bandwidth (250-500 Mbps) in all regions, apart from Asia-Pacific. Hetzner Cloud[2] offers 20 TB (1 Gbps) for each cloud instance, but has locations only in Europe. Both of them offer dedicated servers with up to 1-3 Gbps unmetered bandwidth that could be used as exit nodes. [1] https://www.ovh.com/world/public-cloud/instances/prices/ https://www.ovh.com/world/public-cloud/instances/prices/ [2] https://www.hetzner.com/cloud https://www.hetzner.com/cloud
fulafel 7y ago
The #1 cost is increased complexity and opportunity cost of converting your simple app to an interesting serverless/nosql/microservices/etc distributed system. Of course the financial savings can be heroic and justify the effort because everything is very expensive on AWS.
- throwayEngineer 7y ago
  I'm not sure when AWS became the standard, but the programming communities have lots of young kids learning their first backends on AWS. Im not sure this is a good thing, having a generation of developers dependent on a single companies tools seems like the future will be painful.
  - quicksilver03 7y ago
    It's not a good thing, but no worse than having developers depend on Docker without a basic understanding of the underlying OS.
    - serf 7y ago
      i'd contend that it's much worse. One (Docker) is a piece of software, one (Amazon) is a corporation with a motivated will. They are two different problems. One is basically the problem of copy-paste/stackoverflow developers, the other is a walled garden problem that'll make itself worse over time.
      - nmca 7y ago
        Docker is written by a corporation, and so in many senses it is an expression of their will.
  - freehunter 7y ago
    I don't know if these fears ever actually pan out. In the 90s we had a world full of kids learning on Windows, and many of them later in their career switched to Linux or Mac. In the 2000s we had a world of kids learning Rails and plenty of them moved on to Javascript or Clojure or Python. The world was no worse for their first experience, and alternative tools did not cease to exist. The people who learn on AWS and have an actual desire to continue their knowledge will always find ways to continue their knowledge. Learning on AWS first is not going to stop that.
JackC 7y ago
I'm not sure AWS costs are something you can do by remembering a few guidelines, rather than actually assigning an order-of-magnitude estimate to every billable thing and adding it all up. Like the one that bit me recently was a $0.05/1000 cost per thing, which is easy to translate to $0.00005/thing and then mentally round to $0. That one added up to real money at 10^8 things, and would have been a big problem at 10^9. The cool thing about horizontal scaling is that doing something 10^6 times or 10^9 times is going to feel pretty similar when you do it -- the only difference is the order of magnitude of the bill.
INTPenis 7y ago
I just got into AWS last year and this article does not mention my big mistake that I made. Using RDS for a small scale project instead of EC2. RDS is super expensive and while you're gaining traction and users you might as well use an EC2 instance. ElasticBeanstalk seemed like an easy intro to AWS but it steered me into RDS. Of course I've abandoned the whole of ElasticBeanstalk for serverless development lately. My first intro to AWS was ElasticBeanstalk and serverless seemed too daunting. But now I've been smitten and can't stop thinking serverless.
- mark242 7y ago
  Have you considered using Aurora Serverless? If you're trying to prove market fit, it can be an order of magnitude cheaper than RDS and you don't have to worry about management in EC2.
  - iends 7y ago
    AWS doesn't recommend Aurora Serverless for production, yet.
    - james_s_tayler 7y ago
      Yeah, great for an internal facing app on your company intranet that only needs infrequent access but requires a relational database.
- iends 7y ago
  I feel like serverless in a lot of cases is more expensive than just running a monolith, once you get past the toy example or past the MVP stage. This is especially true once you factor in all the development overhead, which can ultimately be very expensive to do things correctly with serverless.
  - GordonS 7y ago
    Azure have open sourced their serverless engine, so you even have the option of building out your own private serverless infrastructure.
vbsteven 7y ago
I would like to see a post like this comparing services like RDS or Mongodb Atlas on different instance sizes. For example: what is a typical writes|reads/second I can achieve on a Postgres RDS db.m4.large instance.
amedvednikov 7y ago
I never understood the benefits of the cloud for 99% of the projects. I just moved https://vlang.io https://vlang.io from Google Cloud (my free credit expired) to an Amazon Lightsail VPS (any VPS will do), and my spending went from ~$70 to $3.5/month. And the performance actually improved a bit.
- deleted 7y ago
  [deleted]
- A2017U1 7y ago
  I'm confused, is that not still "the cloud" you are using? There's certainly a huge range of pricing for the exact same services (sometimes worse services cough OVH dedi servers cough)
  - GordonS 7y ago
    I have a feeling you know this, but "the cloud" is nowadays generally taken to mean providers (such as AWS and Azure) that have IaaS, PaaS and SaaS offerings, with a focus on the latter two.
  - sheeshkebab 7y ago
    If you are not using load balancers, lambdas, provisioned iops, internet scale databases, pipelines, streams, cdns, data object storage, machine learning apis - you are not using “cloud”.
  - freehunter 7y ago
    It's a server in "the cloud" but it's not cloud services. If you're running an OS on bare metal or a blank VM, you're basically just co-locating in someone else's datacenter which is a very traditional model.
- dRaBoQ 7y ago
  That. I see tons of posts of under/fresh grads trying to use microservices, k8s and TerraForm for their tiny < 100 qps apps. A properly designed monolith on a dedicated server/VM can easily serve tens of thousands of users just fine and will be far easier to maintain than this mess (plus way cheaper as well). The main advantage of those tools is when you have a number of distributed teams and you want to scale to millions of users. For nearly anything else, a far smaller setup is what you want.
Const-me 7y ago
GPU prices are ridiculous. You can often purchase an equally performing PC, with a GeForce GPU, for the cost of just 1-2 months of cloud rent. Also many of them bundle VGPUs with large amount of CPU and RAM, as far as I remember only Google allows custom specs, both MS and Amazon don't have custom machines for users who only need GPUs.
- dRaBoQ 7y ago
  Its pretty useful for students or those who want to play with the tech and not sure if they will be committed to it long term. Thats a pretty big marker with all the deep learning hype.
  - xodast 7y ago
    Also you can get a couple of hundred bucks of credit from multiple providers. It was enough for me to learn and move on to getting my own gpu. Often understated is how difficult it is to set up your local gpu for machine learning. Still haven't figured out how to connect my 8 gpus in a functional way.
- GordonS 7y ago
  I do agree, but the value proposition is more than simply the cost - being able to spin up GPUs on demand is extremely beneficial for a lot of projects. Of course, once you have something in production, it might be worth considering buying your own GPUs, but really is all depends.
- sokoloff 7y ago
  I think this is more nVidia’s fault due to their Datacenter specific pricing that AWS has to abide (and then mark up). Your GPU is not licensed in a way that allows AWS to use it.
tbrock 7y ago
I was surprised this is all about physical costs and doesn’t include digital costs that folks should be aware of. I was expecting to see the latency between AZs in a region and between regions for example.
gtirloni 7y ago
There are various "AWS Costs Cheatsheet" posts but I couldn't find a comprehensive _and_ updated one. Any suggestions?
- EForEndeavour 7y ago
  Not a cheat sheet, but a comprehensive list of specs and pricing for every EC2 instance, in a really nice UI far more useful than mentally joining Amazon's various tables: https://www.ec2instances.info/ https://www.ec2instances.info/
OisinMoran 7y ago
This is an interesting idea. Could be handy to have a little tool to estimate and compare costs across providers, maybe with pros and cons, constraints, and even customer reviews. E.g. I only need 99% uptime, I will be serving images, most of them will be the same etc. I must say though, the graphs in this could be a good bit better. There is no reason to use a line here, it makes it look like a time series plot. Each instance type should have its own bar and they should be ordered in some manner, either grouping by types or sorting by price.
- wazoox 7y ago
  Trackit.io does exactly this. It's available on GitHub.
  - mdaniel 7y ago
    Since it wasn't obvious from their website (no GitHub icon in their "social media tray"): https://github.com/trackit/trackit-server#readme https://github.com/trackit/trackit-server#readme
    - wazoox 7y ago
      Sorry, I posted from my phone and hadn't much time :)
meuk 7y ago
These 'every programmer should know' things should stop -- surely a web developer isn't supposed to know latency figures (or 114 pages about the details of RAM, see [1]). Likewise, most programmers don't care about AWS costs. [1] https://people.freebsd.org/~lstewart/articles/cpumemory.pdf https://people.freebsd.org/~lstewart/articles/cpumemory.pdf
- Kalium 7y ago
  I've found it very helpful to know about the differences in latency between data in RAM on the client and data in a database connected to a remote webserver. It pushed me to reduce the number of API requests and think about what data is needed when. These are things developers definitely should know.
  - meuk 7y ago
    If that's your job, then you should, but not every programmer. At least make the title of your post "every web programmer" or "every programmer using AWS". It makes the post a lot less clickbaity.
- mbrameld 7y ago
  You shouldn't read headlines like that literally or you're destined to be disappointed. They're hyperbolic in order to attract more clicks. The way it should be parsed is, "things that are useful to know if you're working on things where stuff like this is important." It should be obvious that if you're not working with AWS or plan on doing so in the future then you just skip articles about AWS, right?
- buster 7y ago
  Surely every programmer worth his salaray should know latency figures, especially if he is working on a website! At least have a basic understanding of costs of HTTPS and latency of mobile connections.
- serf 7y ago
  I disagree that a web developer shouldn't know latency figures. It's pretty developer/project dependent. I do agree that "EVERY programmer should know.." with regards to some specific software package or service is silly. Given that there are a million ways to provide services similar to AWS, and AWS is really only a means to an end -- I don't get why every programmer should be aware of the specifics. Latency is one those things that hits almost all of CS. AWS isn't. "Things all programmers should know about AWS.." is , in my opinion, similar to saying something like "Things every programmer should know about the Python GIL." , it includes exactly the reason WHY every programmer needs not know it. Not a amazon service user? Forget about AWS. Not a python user? Who cares about the GIL. I also agree that your linked PDF is overboard -- but it's one of those things that looks overboard now, but that kind of innate cpu/memory knowledge would have been a lot more useful when lower level languages were more widely used. Touching memory is just one of those things that seems to be on its' way out, and I, for one, am thankful for that.
normalperson 7y ago
Uh... no mention of RDS?
CherryJimbo 7y ago
As others have said, bandwidth costs can be absolutely insane with AWS. This was actually the primary reason we moved from S3 to Backblaze B2 as documented at https://news.ycombinator.com/item?id=19648607 https://news.ycombinator.com/item?id=19648607, and saved ourselves thousands of dollars per month, especially in conjuncture with Cloudflare's Bandwidth alliance. https://www.cloudflare.com/webinars/cloud-jitsu-migrating-23tb-from-aws-s3-to-backblaze-b2-in-7-hours/ https://www.cloudflare.com/webinars/cloud-jitsu-migrating-23... We still use AWS for a few things and still have a small bill with them every month, but we're very careful about putting anything there that's going to push a lot of traffic.
- vidarh 7y ago
  People really should be aware of this, yes. Even if your client /management absolutely insists on S3 for reputed durability etc., if bandwidth costs are high, you can often get 'free' extensive compute resources by hiring servers elsewhere to proxy and cache S3 access to cut bandwidth bills and run other things next to the largely network bound load. In general I find the big problem with AWS is that cost is handled 'in reverse': developers often get near free reign, and cost only gets handled when someone balks at the size of the AWS bill. Often it turns out to be trivial to cut by changing instance types or renting a server somewhere to act as a cache. At that point people have often spent tens of thousands in unnecessary fees. There's an underserved niche for people to do AWS cost optimization on a 'no-win no-fee' basis. I used to help clients with cutting costs on AWS and if people were in doubt I'd often offer that. And the savings were often staggering (e.g halving hosting costs was common; once we cut costs 90 percent by moving to Hetzner for a bandwidth intensive app even though long-term storage remained on S3). The biggest challenge in serving that niche is getting people to realise they may be throwing money out the window as surprisingly many people still assume AWS is cheap, and offering to do an initial review for free and not charge if I couldn't achieve the promised savings made it a lot easier. Someone who likes the sales side more could make a killing doing that.
  - secabeen 7y ago
    This why the "Netflix uses AWS!" rhetoric is misleading. Yes, they use AWS extensively for front-end, analytics, transcoding, billing (now), etc. The one thing they don't use AWS for much at all is Content Delivery (AKA big bandwidth). That uses the Netflix Open Connect CDN which is entirely developed and run in-house.
DonHopkins 7y ago
Maybe I'm dense and there is some obvious source of data on the AWS admin pages that I haven't been able to find by clicking around, searching the documentation, and googling, but I still have this question: Why is the cost and size of snapshots so opaque? Is there a way to see how big each one is, and how much it will cost to keep it around for a month? I understand that snapshots are differential, and deleting one snapshot in a series may move blocks to other undeleted snapshots, of course. I just want to know how much storage each snapshot requires right now, and to be able to accurately predict how much each one of them will cost at the end of the month, so I can decide how often to make snapshots and how long to keep them. And is there an easy "serverless" way to automatically archive a snapshot in glacier storage or simply download it, without manually making it into a new volume and using "dd" or "tar" or "dump" or whatever? I understand they're stored in S3. So why can't I see a list of them in the S3 interface, see how big they all are, and tell how much each of them is going to cost at the end of the month? It's my data. I'm paying for it. I think I deserve to be able to see it and know how much it will cost. I get the feeling I'm missing something really obvious (probably a big blinking green button on the main page that my brain is filtering out). Surely many other customers must want these features?
- res0nat0r 7y ago
  Unfortunately there isn't currently any way to tell how much data each snapshot actually contains. There isn't any way also to archive these to glacier, but the somewhat new lifecycle management tool might help you save some money with little effort: https://aws.amazon.com/blogs/aws/new-lifecycle-management-for-amazon-ebs-snapshots/ https://aws.amazon.com/blogs/aws/new-lifecycle-management-fo...
dantillberg 7y ago
Similar numbers for Google Cloud in the less-expensive regions: 1 vCPU: $17/mo for sustained usage, $10.5/mo for 3yr commit, $5/mo for preemptible (similar to spot) 1 GB RAM: $2.2/mo for sustained usage, $1.4/mo for 3yr commit, $0.7/mo for preemptible Google Cloud also lets you choose exactly how much CPU and RAM you want, within reasonable limits (you have to allocate 0.9GB RAM per vCPU and you pay a little more for RAM above 6.5GB per vCPU). So these numbers aren't medians/derived values for Google Cloud but numbers that you can find in the docs at https://cloud.google.com/compute/pricing https://cloud.google.com/compute/pricing. (I don't work for Google, I'm just a fan of Google Cloud)
tus87 7y ago
coughDynamoDBcough
ausjke 7y ago
unless you're a big company, why not just run linode/digitalocean/etc, those are much more user friendly and AWS feels like a maze to me.
- scarface74 7y ago
  I wouldn’t trust any of those to run a business on.
  - freehunter 7y ago
    Seems there are plenty of companies who do trust DO and Linode enough to run a business on. [1] https://www.digitalocean.com/customers/ https://www.digitalocean.com/customers/ [2] https://www.linode.com/case-studies https://www.linode.com/case-studies
    - scarface74 7y ago
      The best non technical/political reason is that if AWS or Azure goes down or you have an issue with them none of your higher ups or investors are going to ask you, why did you choose AWS. It’s the old “no one ever got fired for buying IBM”. Besides, you can never go wrong politically by saying I chose the vendor in the upper right corner of Gartner’s Magic Quadrant. The technical reason is that if I want my hosting service to do more of the “undifferentiated heavy lifting” and provide managed services. I won’t get as much of an offering from Linode/DO. The last reason is that AWS Business Support is excellent. They’ve helped me out with some head scratchers and when I just didn’t want to figure something complex out myself. Their live chat is awesome.
013a 7y ago
Just looking at the quote of "$58/mo for a vCPU", they're clearly taking the median cost of a vCPU across all instance types, which includes hyper-expensive instances with value-adds like GPUs or tons of memory. The real, distinct cost of a vCPU is probably closer to $25/mo. You can look at a m5.large instance, their "general purpose" instance, 2vCPU+8gb @ $70/mo, which would put 1vCPU+4gb at $35/mo. Google Cloud specifically lists the distinct price of a vCPU in custom instances as $24/mo, and AWS feels close to that when you consider the cost of memory in that $35/mo. The lack of networking cost also seems like a big oversight; if I could force every engineer to know a single "AWS Cost" that affects every vertical of development, from frontend to backend, I want them to know how crazy expensive DC egress is.
jammygit 7y ago
I was deciding between cloud hosts yesterday for a tiny project and got reminded how frustrating it is to predict costs on aws. Even to get a monthly ec2 price you need a calculator out, not including other costs. Their billing reports are also very unclear to me. I’m planning on digital ocean because of this: their costs are straightforward and their interface is simple. Edit: can anyone recommend an easy way to create different-provider backups of a DO server?
- scarface74 7y ago
  Look at AWS Lightsail. It’s a simple VPS provider without all of the complexity of AWS.
- freehunter 7y ago
  I use DigitalOcean because they're cheap and their costs are predictable over AWS. I don't do full server backups since I can just 'git pull' and for the most part have my server re-populated, but I do full backups of my Postgres database every night. I use pg_backup and the AWS CLI tools to push the backup to S3. I also keep a week of backups stored locally on the server in case I blow up the database but not the server, I can restore without having to bring it back from S3 (or in case S3 fails).
arithma 7y ago
A bit OT, but I wait for the day where bandwidth isn't a limiting factor and we can host machines doing computations anywhere, instead of having to rent out economies of scale. With Kubernetes and other private-cloud-like solutions, wouldn't it eventually be meaningless to depend on centralized cloud clusters and instead host your own and tap into an equal-footing infrastructure. Projects like vast.ai (no affiliation) are examples of the ideal I hope for.
sonnyblarney 7y ago
Egress fees are a big 'hidden' cost.
skydv 7y ago
AWS is 20 times more expensive than a dedicated server

382 points by dizzih 7y ago

Useful to have also the 'network' costs from an edge location to a user. That one just bit me so its close in my mind right now.

Hamuko 7y ago

Every programmer? In our team, only like two, maybe three programmers are concerned about our AWS architecture at all. I don't really know why everyone in the team should know how much the individual components of AWS cost. They should just know how to not write performance-destroying code that mandates scaling instances up.

growtofill 7y ago
The title is a mock of “Latency Numbers Every Programmer Should Know”[0], although these are (a) limited to a popular, yet not exclusive platform, (b) subjective to change at any moment. [0]: https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html https://people.eecs.berkeley.edu/~rcs/research/interactive_l...
bpicolo 7y ago
Eagerly await the follow up: Falsehoods programmers believe about AWS costs
- jraph 7y ago
  And then: - 10 reasons why AWS costs so much. #7 is mind-boggling. - AWS costs considered harmful
  - jsty 7y ago
    Don't forget: - "Developer uses one weird trick to reduce cloud bills by 97%. AWS hates him!"
    - deleted 7y ago
      [deleted]
  - c3534l 7y ago
    10 Falsehoods Every Programmer Should Know (Number 3 will SHOCK you!)
chrisseaton 7y ago
It's a pattern title. It's not meant to be taken literally and most reasonable people wouldn't read it that way.
mjlee 7y ago
I don't think that every programmer should know it off by heart. I do think it should be a reasonably common skill to make common tradeoffs without too much investigation. Besides, the title is an homage to the Latency Numbers article which follows a similar concept. You don't need to memorise numbers, but you probably should be able to reason about them in very vague terms.
katzgrau 7y ago
It's not just code, and it's not always obvious. AWS' tools (as robust as they seem at first) may not give you the low-level insight that you need to understand where you can really cut down on expenses. I just reduced my AWS bill from about $5.5k/mo to $3k/mo. The rise in price was only slightly outpacing the app growth for a while, and it was very gradual. When the forecasted bill was $6k it became a major priority.

matwood 7y ago

I find it easier to use this tool for quick estimations, and it is more encompassing: https://calculator.s3.amazonaws.com/index.html https://calculator.s3.amazonaws.com/index.html

koolba 7y ago

Any analysis of AWS costs that doesn't start off talking about outbound data transfer pricing, let alone mention it at all, is useless for anything beyond pure-CPU workloads.

privateSFacct 7y ago
Agreed.

oldjokes 7y ago

I have worked at two startups now where we made the fatal mistake of being profitable. If you make this mistake then the investors will swoop in and demand you spend more on marketing and AWS infrastructure, because we're scaling up to 5 billion users of course. Of course we started spending all the money on new people and AWS, and soon there was no money. At one point we were dumping like $15K a month on AWS for a dozen unnecessary over-engineered toys that nobody was using. This is the real cost of AWS. I'd love to see Amazon's data on money invested vs actual user traffic for small startups, that's got to be some of the most interesting and valuable data on earth. Forget companies, I'll bet Jeff is sitting around predicting when entire industries rise and fall weeks before anyone else based just on this data.

grogenaut 7y ago
How is Amazon supposed to know actual user numbers? That's app specific.
- deleted 7y ago
  [deleted]
- fouc 7y ago
  They probably meant page views and such.
- biesnecker 7y ago
  You can't get exact numbers, but for consumer-facing products you can estimate it via unique IPs hitting the load balancers, etc.
  - grogenaut 7y ago
    That would require amazon gathering customer information and possibly GDPR data on the usage of all of it's customers, which is a thing amazon doesn't do, and you don't want your cloud providers doing.
tyingq 7y ago

kakkksaknmdm 7y ago

Any AWS metric that doesnt have the network costs is useless. If anyone wants a dedicated unmetered server up to 20gbps i'd recommend datapacket.com.

corrigible 7y ago
Agreed. The cloud is great if your workload is low-egress... AWS/GCP bandwidth pricing is predatory at times.

danpalmer 7y ago

I’d add to this, numbers every SaaS sales person should know with the resources used by their services, or roughly what the marginal cost of a new customer is. Most SaaS services have very high markup, but get a few bits of infra wrong, over promise on a few things, and use expensive AWS services, and suddenly you’re selling $500 a month of AWS services for $99 a month. This is an easy mistake to make, I’ve seen it happen with these figures, and it only takes a few wrong assumptions across the engineering and sales teams.

zawerf 7y ago

For certain apps, bandwidth cost is stupid expensive on AWS. For example I've been following the development of an online manga reading site (mangadex.org) that is now pushing over 1PB/month of images. If they had built it on aws, even at the lowest rate of $0.02/GB with cloudfront/S3, it would be $20,000 per month. But they ended up paying nothing by using cloudflare who gave them unmetered bandwidth. (well, until they got throttled earlier this year but they got out of that by upgrading to a measly $200/month plan)

kasey_junk 7y ago
I thought most of the clouds offered free ingress?
- dharmab 7y ago
  MangaDex serves very high resolution scans of comic pages (egress)
  - kasey_junk 7y ago
    Ah. I misunderstood the “push” part of the comment.
- contras1970 7y ago
  yes, but the topic is the price of egress. i thought this was obvious to everybody: public clouds want to lock you in, so they make it very cheap and easy to get data in, but charge stupendous amounts for getting your data out.
stingraycharles 7y ago
Bandwidth is insanely expensive on all clouds. If you’re a large consumer, however, you can usually negotiate a much better rate.
- krn 7y ago
  > Bandwidth is insanely expensive on all clouds. OVH Public Cloud[1] offers unmetered bandwidth (250-500 Mbps) in all regions, apart from Asia-Pacific. Hetzner Cloud[2] offers 20 TB (1 Gbps) for each cloud instance, but has locations only in Europe. Both of them offer dedicated servers with up to 1-3 Gbps unmetered bandwidth that could be used as exit nodes. [1] https://www.ovh.com/world/public-cloud/instances/prices/ https://www.ovh.com/world/public-cloud/instances/prices/ [2] https://www.hetzner.com/cloud https://www.hetzner.com/cloud

fulafel 7y ago

The #1 cost is increased complexity and opportunity cost of converting your simple app to an interesting serverless/nosql/microservices/etc distributed system. Of course the financial savings can be heroic and justify the effort because everything is very expensive on AWS.

throwayEngineer 7y ago
I'm not sure when AWS became the standard, but the programming communities have lots of young kids learning their first backends on AWS. Im not sure this is a good thing, having a generation of developers dependent on a single companies tools seems like the future will be painful.
- quicksilver03 7y ago
  It's not a good thing, but no worse than having developers depend on Docker without a basic understanding of the underlying OS.
  - serf 7y ago
    i'd contend that it's much worse. One (Docker) is a piece of software, one (Amazon) is a corporation with a motivated will. They are two different problems. One is basically the problem of copy-paste/stackoverflow developers, the other is a walled garden problem that'll make itself worse over time.
    - nmca 7y ago
      Docker is written by a corporation, and so in many senses it is an expression of their will.
- freehunter 7y ago
  I don't know if these fears ever actually pan out. In the 90s we had a world full of kids learning on Windows, and many of them later in their career switched to Linux or Mac. In the 2000s we had a world of kids learning Rails and plenty of them moved on to Javascript or Clojure or Python. The world was no worse for their first experience, and alternative tools did not cease to exist. The people who learn on AWS and have an actual desire to continue their knowledge will always find ways to continue their knowledge. Learning on AWS first is not going to stop that.

JackC 7y ago

I'm not sure AWS costs are something you can do by remembering a few guidelines, rather than actually assigning an order-of-magnitude estimate to every billable thing and adding it all up. Like the one that bit me recently was a $0.05/1000 cost per thing, which is easy to translate to $0.00005/thing and then mentally round to $0. That one added up to real money at 10^8 things, and would have been a big problem at 10^9. The cool thing about horizontal scaling is that doing something 10^6 times or 10^9 times is going to feel pretty similar when you do it -- the only difference is the order of magnitude of the bill.

INTPenis 7y ago

I just got into AWS last year and this article does not mention my big mistake that I made. Using RDS for a small scale project instead of EC2. RDS is super expensive and while you're gaining traction and users you might as well use an EC2 instance. ElasticBeanstalk seemed like an easy intro to AWS but it steered me into RDS. Of course I've abandoned the whole of ElasticBeanstalk for serverless development lately. My first intro to AWS was ElasticBeanstalk and serverless seemed too daunting. But now I've been smitten and can't stop thinking serverless.

mark242 7y ago
Have you considered using Aurora Serverless? If you're trying to prove market fit, it can be an order of magnitude cheaper than RDS and you don't have to worry about management in EC2.
- iends 7y ago
  AWS doesn't recommend Aurora Serverless for production, yet.
  - james_s_tayler 7y ago
    Yeah, great for an internal facing app on your company intranet that only needs infrequent access but requires a relational database.
iends 7y ago
I feel like serverless in a lot of cases is more expensive than just running a monolith, once you get past the toy example or past the MVP stage. This is especially true once you factor in all the development overhead, which can ultimately be very expensive to do things correctly with serverless.
- GordonS 7y ago
  Azure have open sourced their serverless engine, so you even have the option of building out your own private serverless infrastructure.

vbsteven 7y ago

I would like to see a post like this comparing services like RDS or Mongodb Atlas on different instance sizes. For example: what is a typical writes|reads/second I can achieve on a Postgres RDS db.m4.large instance.

amedvednikov 7y ago

I never understood the benefits of the cloud for 99% of the projects. I just moved https://vlang.io https://vlang.io from Google Cloud (my free credit expired) to an Amazon Lightsail VPS (any VPS will do), and my spending went from ~$70 to $3.5/month. And the performance actually improved a bit.

deleted 7y ago
[deleted]
A2017U1 7y ago
I'm confused, is that not still "the cloud" you are using? There's certainly a huge range of pricing for the exact same services (sometimes worse services cough OVH dedi servers cough)
- GordonS 7y ago
  I have a feeling you know this, but "the cloud" is nowadays generally taken to mean providers (such as AWS and Azure) that have IaaS, PaaS and SaaS offerings, with a focus on the latter two.
- sheeshkebab 7y ago
  If you are not using load balancers, lambdas, provisioned iops, internet scale databases, pipelines, streams, cdns, data object storage, machine learning apis - you are not using “cloud”.
- freehunter 7y ago
  It's a server in "the cloud" but it's not cloud services. If you're running an OS on bare metal or a blank VM, you're basically just co-locating in someone else's datacenter which is a very traditional model.
dRaBoQ 7y ago
That. I see tons of posts of under/fresh grads trying to use microservices, k8s and TerraForm for their tiny < 100 qps apps. A properly designed monolith on a dedicated server/VM can easily serve tens of thousands of users just fine and will be far easier to maintain than this mess (plus way cheaper as well). The main advantage of those tools is when you have a number of distributed teams and you want to scale to millions of users. For nearly anything else, a far smaller setup is what you want.

Const-me 7y ago

GPU prices are ridiculous. You can often purchase an equally performing PC, with a GeForce GPU, for the cost of just 1-2 months of cloud rent. Also many of them bundle VGPUs with large amount of CPU and RAM, as far as I remember only Google allows custom specs, both MS and Amazon don't have custom machines for users who only need GPUs.

dRaBoQ 7y ago
Its pretty useful for students or those who want to play with the tech and not sure if they will be committed to it long term. Thats a pretty big marker with all the deep learning hype.
- xodast 7y ago
  Also you can get a couple of hundred bucks of credit from multiple providers. It was enough for me to learn and move on to getting my own gpu. Often understated is how difficult it is to set up your local gpu for machine learning. Still haven't figured out how to connect my 8 gpus in a functional way.
GordonS 7y ago
I do agree, but the value proposition is more than simply the cost - being able to spin up GPUs on demand is extremely beneficial for a lot of projects. Of course, once you have something in production, it might be worth considering buying your own GPUs, but really is all depends.
sokoloff 7y ago
I think this is more nVidia’s fault due to their Datacenter specific pricing that AWS has to abide (and then mark up). Your GPU is not licensed in a way that allows AWS to use it.

tbrock 7y ago

I was surprised this is all about physical costs and doesn’t include digital costs that folks should be aware of. I was expecting to see the latency between AZs in a region and between regions for example.

gtirloni 7y ago

There are various "AWS Costs Cheatsheet" posts but I couldn't find a comprehensive _and_ updated one. Any suggestions?

EForEndeavour 7y ago
Not a cheat sheet, but a comprehensive list of specs and pricing for every EC2 instance, in a really nice UI far more useful than mentally joining Amazon's various tables: https://www.ec2instances.info/ https://www.ec2instances.info/

OisinMoran 7y ago

This is an interesting idea. Could be handy to have a little tool to estimate and compare costs across providers, maybe with pros and cons, constraints, and even customer reviews. E.g. I only need 99% uptime, I will be serving images, most of them will be the same etc. I must say though, the graphs in this could be a good bit better. There is no reason to use a line here, it makes it look like a time series plot. Each instance type should have its own bar and they should be ordered in some manner, either grouping by types or sorting by price.

wazoox 7y ago
Trackit.io does exactly this. It's available on GitHub.
- mdaniel 7y ago
  Since it wasn't obvious from their website (no GitHub icon in their "social media tray"): https://github.com/trackit/trackit-server#readme https://github.com/trackit/trackit-server#readme
  - wazoox 7y ago
    Sorry, I posted from my phone and hadn't much time :)

meuk 7y ago

These 'every programmer should know' things should stop -- surely a web developer isn't supposed to know latency figures (or 114 pages about the details of RAM, see [1]). Likewise, most programmers don't care about AWS costs. [1] https://people.freebsd.org/~lstewart/articles/cpumemory.pdf https://people.freebsd.org/~lstewart/articles/cpumemory.pdf

Kalium 7y ago
I've found it very helpful to know about the differences in latency between data in RAM on the client and data in a database connected to a remote webserver. It pushed me to reduce the number of API requests and think about what data is needed when. These are things developers definitely should know.
- meuk 7y ago
  If that's your job, then you should, but not every programmer. At least make the title of your post "every web programmer" or "every programmer using AWS". It makes the post a lot less clickbaity.
mbrameld 7y ago
You shouldn't read headlines like that literally or you're destined to be disappointed. They're hyperbolic in order to attract more clicks. The way it should be parsed is, "things that are useful to know if you're working on things where stuff like this is important." It should be obvious that if you're not working with AWS or plan on doing so in the future then you just skip articles about AWS, right?
buster 7y ago
Surely every programmer worth his salaray should know latency figures, especially if he is working on a website! At least have a basic understanding of costs of HTTPS and latency of mobile connections.
serf 7y ago
I disagree that a web developer shouldn't know latency figures. It's pretty developer/project dependent. I do agree that "EVERY programmer should know.." with regards to some specific software package or service is silly. Given that there are a million ways to provide services similar to AWS, and AWS is really only a means to an end -- I don't get why every programmer should be aware of the specifics. Latency is one those things that hits almost all of CS. AWS isn't. "Things all programmers should know about AWS.." is , in my opinion, similar to saying something like "Things every programmer should know about the Python GIL." , it includes exactly the reason WHY every programmer needs not know it. Not a amazon service user? Forget about AWS. Not a python user? Who cares about the GIL. I also agree that your linked PDF is overboard -- but it's one of those things that looks overboard now, but that kind of innate cpu/memory knowledge would have been a lot more useful when lower level languages were more widely used. Touching memory is just one of those things that seems to be on its' way out, and I, for one, am thankful for that.

normalperson 7y ago

Uh... no mention of RDS?

CherryJimbo 7y ago

As others have said, bandwidth costs can be absolutely insane with AWS. This was actually the primary reason we moved from S3 to Backblaze B2 as documented at https://news.ycombinator.com/item?id=19648607 https://news.ycombinator.com/item?id=19648607, and saved ourselves thousands of dollars per month, especially in conjuncture with Cloudflare's Bandwidth alliance. https://www.cloudflare.com/webinars/cloud-jitsu-migrating-23tb-from-aws-s3-to-backblaze-b2-in-7-hours/ https://www.cloudflare.com/webinars/cloud-jitsu-migrating-23... We still use AWS for a few things and still have a small bill with them every month, but we're very careful about putting anything there that's going to push a lot of traffic.

vidarh 7y ago
People really should be aware of this, yes. Even if your client /management absolutely insists on S3 for reputed durability etc., if bandwidth costs are high, you can often get 'free' extensive compute resources by hiring servers elsewhere to proxy and cache S3 access to cut bandwidth bills and run other things next to the largely network bound load. In general I find the big problem with AWS is that cost is handled 'in reverse': developers often get near free reign, and cost only gets handled when someone balks at the size of the AWS bill. Often it turns out to be trivial to cut by changing instance types or renting a server somewhere to act as a cache. At that point people have often spent tens of thousands in unnecessary fees. There's an underserved niche for people to do AWS cost optimization on a 'no-win no-fee' basis. I used to help clients with cutting costs on AWS and if people were in doubt I'd often offer that. And the savings were often staggering (e.g halving hosting costs was common; once we cut costs 90 percent by moving to Hetzner for a bandwidth intensive app even though long-term storage remained on S3). The biggest challenge in serving that niche is getting people to realise they may be throwing money out the window as surprisingly many people still assume AWS is cheap, and offering to do an initial review for free and not charge if I couldn't achieve the promised savings made it a lot easier. Someone who likes the sales side more could make a killing doing that.
- secabeen 7y ago
  This why the "Netflix uses AWS!" rhetoric is misleading. Yes, they use AWS extensively for front-end, analytics, transcoding, billing (now), etc. The one thing they don't use AWS for much at all is Content Delivery (AKA big bandwidth). That uses the Netflix Open Connect CDN which is entirely developed and run in-house.

DonHopkins 7y ago

Maybe I'm dense and there is some obvious source of data on the AWS admin pages that I haven't been able to find by clicking around, searching the documentation, and googling, but I still have this question: Why is the cost and size of snapshots so opaque? Is there a way to see how big each one is, and how much it will cost to keep it around for a month? I understand that snapshots are differential, and deleting one snapshot in a series may move blocks to other undeleted snapshots, of course. I just want to know how much storage each snapshot requires right now, and to be able to accurately predict how much each one of them will cost at the end of the month, so I can decide how often to make snapshots and how long to keep them. And is there an easy "serverless" way to automatically archive a snapshot in glacier storage or simply download it, without manually making it into a new volume and using "dd" or "tar" or "dump" or whatever? I understand they're stored in S3. So why can't I see a list of them in the S3 interface, see how big they all are, and tell how much each of them is going to cost at the end of the month? It's my data. I'm paying for it. I think I deserve to be able to see it and know how much it will cost. I get the feeling I'm missing something really obvious (probably a big blinking green button on the main page that my brain is filtering out). Surely many other customers must want these features?

res0nat0r 7y ago
Unfortunately there isn't currently any way to tell how much data each snapshot actually contains. There isn't any way also to archive these to glacier, but the somewhat new lifecycle management tool might help you save some money with little effort: https://aws.amazon.com/blogs/aws/new-lifecycle-management-for-amazon-ebs-snapshots/ https://aws.amazon.com/blogs/aws/new-lifecycle-management-fo...

dantillberg 7y ago

Similar numbers for Google Cloud in the less-expensive regions: 1 vCPU: $17/mo for sustained usage, $10.5/mo for 3yr commit, $5/mo for preemptible (similar to spot) 1 GB RAM: $2.2/mo for sustained usage, $1.4/mo for 3yr commit, $0.7/mo for preemptible Google Cloud also lets you choose exactly how much CPU and RAM you want, within reasonable limits (you have to allocate 0.9GB RAM per vCPU and you pay a little more for RAM above 6.5GB per vCPU). So these numbers aren't medians/derived values for Google Cloud but numbers that you can find in the docs at https://cloud.google.com/compute/pricing https://cloud.google.com/compute/pricing. (I don't work for Google, I'm just a fan of Google Cloud)

tus87 7y ago

coughDynamoDBcough

ausjke 7y ago

unless you're a big company, why not just run linode/digitalocean/etc, those are much more user friendly and AWS feels like a maze to me.

scarface74 7y ago
I wouldn’t trust any of those to run a business on.
- freehunter 7y ago
  Seems there are plenty of companies who do trust DO and Linode enough to run a business on. [1] https://www.digitalocean.com/customers/ https://www.digitalocean.com/customers/ [2] https://www.linode.com/case-studies https://www.linode.com/case-studies
  - scarface74 7y ago
    The best non technical/political reason is that if AWS or Azure goes down or you have an issue with them none of your higher ups or investors are going to ask you, why did you choose AWS. It’s the old “no one ever got fired for buying IBM”. Besides, you can never go wrong politically by saying I chose the vendor in the upper right corner of Gartner’s Magic Quadrant. The technical reason is that if I want my hosting service to do more of the “undifferentiated heavy lifting” and provide managed services. I won’t get as much of an offering from Linode/DO. The last reason is that AWS Business Support is excellent. They’ve helped me out with some head scratchers and when I just didn’t want to figure something complex out myself. Their live chat is awesome.

013a 7y ago

Just looking at the quote of "$58/mo for a vCPU", they're clearly taking the median cost of a vCPU across all instance types, which includes hyper-expensive instances with value-adds like GPUs or tons of memory. The real, distinct cost of a vCPU is probably closer to $25/mo. You can look at a m5.large instance, their "general purpose" instance, 2vCPU+8gb @ $70/mo, which would put 1vCPU+4gb at $35/mo. Google Cloud specifically lists the distinct price of a vCPU in custom instances as $24/mo, and AWS feels close to that when you consider the cost of memory in that $35/mo. The lack of networking cost also seems like a big oversight; if I could force every engineer to know a single "AWS Cost" that affects every vertical of development, from frontend to backend, I want them to know how crazy expensive DC egress is.

jammygit 7y ago

I was deciding between cloud hosts yesterday for a tiny project and got reminded how frustrating it is to predict costs on aws. Even to get a monthly ec2 price you need a calculator out, not including other costs. Their billing reports are also very unclear to me. I’m planning on digital ocean because of this: their costs are straightforward and their interface is simple. Edit: can anyone recommend an easy way to create different-provider backups of a DO server?

scarface74 7y ago
Look at AWS Lightsail. It’s a simple VPS provider without all of the complexity of AWS.
freehunter 7y ago
I use DigitalOcean because they're cheap and their costs are predictable over AWS. I don't do full server backups since I can just 'git pull' and for the most part have my server re-populated, but I do full backups of my Postgres database every night. I use pg_backup and the AWS CLI tools to push the backup to S3. I also keep a week of backups stored locally on the server in case I blow up the database but not the server, I can restore without having to bring it back from S3 (or in case S3 fails).

arithma 7y ago

A bit OT, but I wait for the day where bandwidth isn't a limiting factor and we can host machines doing computations anywhere, instead of having to rent out economies of scale. With Kubernetes and other private-cloud-like solutions, wouldn't it eventually be meaningless to depend on centralized cloud clusters and instead host your own and tap into an equal-footing infrastructure. Projects like vast.ai (no affiliation) are examples of the ideal I hope for.

sonnyblarney 7y ago

Egress fees are a big 'hidden' cost.

skydv 7y ago

AWS is 20 times more expensive than a dedicated server