> Have you ever used AWS? There's a whole suite of tools they provide around pricing and budgeting.

They don't work. To elaborate, they fail to provide the user with information with enough clarity to allow him to form accurate mental models of what is being used,what it costs, and what is the implication in cost of applying some change.

Heck, at any given moment it's unexplainably hard to tell exactly which AWS services are you actually using, and being billed for.

The only reliable info on cost it the invoice you receive at the end of the month. Even then, the AWS guys felt the need to develop a full blown machine learning service to help customers predict what their next invoice will be.

> Heck, at any given moment it's unexplainably hard to tell exactly which AWS services are you actually using, and being billed for.

Did you actually look at the billing page? Here's a screenshot of my billing page:

https://imgur.com/a/DQAxgRY

It meticulously breaks out per-service costs across whatever dimension you want. "EC2-Other" is rolled up in the chart, but it's broken out by each individual item further down in the list.

Isn’t that exactly what the person you replied to said? You’re showing what you’ve been charged for previously. That part works, at a certain level of detail.

That doesn’t show what you are being charged for right now, nor does it help you predict what your total costs will be at the end of the month.

You bring up a good point - it would be a good idea for AWS to set some sensible max budget defaults for new accounts to prevent surprises.

Since they don't, if you are literally so concerned with your current costs for this month, you can set a budget and alerts for whatever you want, so that you don't exceed some cost. Also, they show you your current cost for this month, up until the moment, as well as a daily breakdown of your costs.

> sensible max budget defaults for new accounts to prevent surprises.

Amazon, in my experience, has issued organizations a one-time credit in cases of surprise bills.

The bigger crux of the issue, is Amazon has democratized CapEx into OpEx, and it's too easy to be ignorant of the details of infrastructure planning, which is rolled into AWS pricing.

Before AWS, IT teams had to plan for and estimate costs prior to procuring hardware. This is no longer needed with ondemand, programmatic infrastructure.

Engineers, who (reductively) focus on solving business problems with code, aren't necessarily thinking about the costs of deploying their solutions, the way Ops and IT would be.

The couple of AWS acquaintances I asked about this said that this kind of feature doesn't exist because:

- There's almost no demand for it from the majority of their customers.

- Billing code is a big, scary, tangled mess and also happens to be the one area where you really can't afford to introduce bugs and make mistakes, so meaningful change is already exceptionally difficult.

I started using my new account yesterday.

I already got a surprise, because in one place it says t2.micro and t3.micro instances are free for twelve months.

But, if the instance runs Windows, or the zone is this or that, or something else I don't know, the only free tier instance is actually the t2.micro.

And then there's the Unlimited option, and CPU credits, where if your CPU use goes over 25% for some time, it will either: Be throttled so slow as to be useless, or, not being free and you still have to pay for each hour of use.

And that's just the beginning!

Or if that’s all you need you could run Lightsail for simple billing....

I don't need simple billing. Lightsail seems to "suggest" way more expensive options than what I am using right now.

What I need is clear and upfront documentation about pricing, before the bill comes.

> You bring up a good point - it would be a good idea for AWS to set some sensible max budget defaults for new accounts to prevent surprises.

I didn’t say anything about this at all. It would certainly be a nice feature, and one people have asked for since the very beginning of AWS.

> Since they don't, if you are literally so concerned with your current costs for this month, you can set a budget and alerts for whatever you want, so that you don't exceed some cost.

Again, this is a strawman. This isn’t a response to anything I said.

If you’re trying to understand how much a new deployment on AWS is costing you, and find ways to optimize that, you don’t care about the total budget of the account, or having some auto shutoff. You need detailed, real-time information from Amazon, which I’ve never seen in the console.

It’s been several years since I’ve had to be digging around in the billing console, so I have no stake in this discussion and things might have changed. Based on other comments being made around here, I really doubt anything significant has changed.

I was just trying to clarify a comment you completely misunderstood.

> If you’re trying to understand how much a new deployment on AWS is costing you, and find ways to optimize that, you don’t care about the total budget of the account, or having some auto shutoff. You need detailed, real-time information from Amazon, which I’ve never seen in the console.

No one who is working on this cares about real-time by the second data - the daily cost is enough.

> Again, this is a strawman. This isn’t a response to anything I said.

OK, what are you trying to say? If my response above did not answer the question, can you give me a one sentence summary of the point?

> can you give me a one sentence summary of the point?

>> I was just trying to clarify a comment you completely misunderstood.

Alternatively,

“The billing UI and billing infrastructure is a major weakness of AWS when it comes to helping people understand what their usage will cost.” You can clearly see this is true by the large number of people who complain about it.

If you're working with, say ML workloads, daily billing is laughably broad. Some workloads run for an hour or two, and cost a ton.

You can opt in for detailed billing report, and get detailed daily reports on what you are being charged on. You can load it in any db of your choice and ask all the questions that you want.

If you set up your infrastructure with CloudFormation (as you should), you can get a cost estimation of how much your solution would cost.

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

This is really terrible blanket advice, CF is one of AWS' worst products in my extensive experience with it (My team manages a ~$4 million monthly bill and locked into CF well before I joined). It has a number of significant limitations that aren't applied to terraform, it's pretty important to understand those tradeoffs if you're buying in.

Given that AWS supports terraform, it's really on them to provide a calculator for it as well. We're large enough that we just spent an obscene amount of money on employee time and effort to track our billing (lots of automated tagging), but until we did that it wasn't uncommon for a couple hundred thousand dollars of unnecessary charges to hit our bill every month.

How is Terraform better than CF for AWS? What are these significant limitations? I also know of plenty of large enterprises that use CF.

> CloudFormation (as you should)

A lot of people use Terraform (my shop does) and I've found a good terraform setup way better than CF templates. You can do tags in Terraform too. You should be forced to use their already bad tooling just to get correct cost estimates.

Yet another reason to use native tooling. If you want to take advantage of AWS features - you have to use AWS features.

Blame Hashicorp if they don’t have a similar feature.

I'm training on AWS and part of an AWS infra team - but we use Terraform partially because we intend to have production support at our company for all three big US clouds, and want the IaC layer to be uniform.

I get that there are times to dive all the way in, but there is still a part of me that says "Is this what the Internet is now?"

You have looked at the provisioners for the different providers haven’t you?

Terraform in no way provides you an abstraction layer over the different cloud providers.

That is correct; I've always found it a missed opportunity in Terraform. I still like it a lot as a tool.

A unified abstraction layer would certainly work for a subset of cloud offerings. Think the more basic stuff like EC2, VPCs, etc. Platform specific extensions could be handled as optional arguments to the unified objects.

That said, even though you need custom Terraform definitions for each cloud vendor, using one IaC tool still beats having to use a cloud-specific one for each of your deployments. The parent's point stands.

Learning terraform for the various providers = learning the different syntaxes and design philosophies of different python libraries.

Learning the different IaC tools for each provider = Learning Python, Javascript, and PHP.

Also, Terraform does state management and can be used to package deployments of apps to different platforms. Our IaC pipeline uses Terraform to deploy resources to AWS and several other cloud toolsets, all in one language.

The provisioners are the easy part - understanding the ecosystem and how the different parts of the cloud providers relate is the harder part. I routinely go back and forth between C#, Python and JavaScript using the official AWS SDKs and I understand how to accomplish what I need in either language. Using those same languages, I wouldn’t know where to start with Azure or GCP.

Using Terraform vs CF is easy compared to using AWS vs Azure.

Moving from Terraform to CloudForm is as pleasant as chewing glass, and the last thing we need is more AWS lock-in unless you're running an AWS consultancy.

If you are using Terraform you are still “locked into” AWS since all of their provisioners are cloud specific.

Also if you are at any type of scale, your IAAC choice is the least of your problems.

Have you actually done a realistic project plan and estimated how much it would cost to migrate infrastructure from one provider to another once you reach any scale - including regression testing, auditing, training, etc? Do you really just use your cloud provider to host a bunch of VMs? Even then it’s not that easy at scale.

Sigh, I should've gone ahead with the longer version of my previous comment that I deleted because I felt that pre-emptively responding to this would be unnecessary by now.

Yes I've dealt with this issue (to be more precise multi-cloud rather than migration, also used other TF providers in tandem like the Kubernetes one), and yes your TF resources are provider-specific, but being able to handle it all with the same tool instead of having to deal with an awful vendor-specific tool (to be charitable, because the reality is having to deal with mutiple ones and having them inter-operate through bash glue) vastly helps in reducing and controlling lock-in, and I would argue it's the baseline step you have to take if you don't want to risk your whole business on a single cloud provider not going to the gutter either because they've grown too big for their own good or because they're being squashed.

CloudFormation means jumping into the pit of lock-in and you can only climb back out by digging your fingers into the dirt wall, Terraform means you have climbing gear to rappel down and if you have to, get back up without as much hardship. Sure you have to put the gear on but your descent is controlled and then you can climb back up at your own leisure.

Is the only thing you are doing with your cloud vendor is using VMs? Not S3? Not IAM? Not SQS? SNS? You don’t have to go through security audits? Hybrid networks via VPNs/Direct Connect? You don’t have a massive amount of data that has to be transferred? Your DNS entries? Your build pipelines?

No longer at that gig, but in order: Kubernetes applications using Kubernetes abstractions, S3 API abstracted away at the library level, RBAC done through Kubernetes (which includes IAM integration), we did use SQS and SNS but those were easy to replace given our abstractions. No security audits (third party ones at least, we did have scripts and checklists for deps and GDPR compliance). No hybrid networks, we either had an internal API/frontend for our services or we used bastion servers for SSH proxying. Wherever data transfer was a major issue we stayed within AWS, but that's our fault for going with AWS in the first place, which doesn't belong to the bandwidth alliance; a hard migration had been discussed and informally planned for but punted for later. DNS can be handled cross-vendor easily with Terraform since it's easy to set a module's outputs to another's parameters. Pipelines we ran with CodeBuild and hosted in ECR, but running a single command and docker pushing to a repo is not something I would even consider as a migration pain.

Everything seems easy until you actually get your project management organization involved, and your IT staff, your QA, your business analysts, your compliance department, start allocating cost for your staff etc....

Well that's because you're locked-in :). If you're already locked in, you're screwed and have to work your way out or live with it and the consequences that come either now or later.

If I get to make the call and I care one bit about the business beyond next quarter, I would always have a clear way out to heavily reduce risks to a situation that we have seen play out many times before with the Oracles and IBMs of the world.

The same happened when moving from a colo to AWS...

You can’t imagine the red tape moving from Workday and their homespun EMR (Healthcare) written 20 years ago using Powerbuilder.

I'm not sure why that would be terribly important though? A month of delay in optimizing your services isn't going to make or break an average company.

You're absolutely right, and also absolutely missing his point. As a massive user of AWS for a long time, yes you can know exactly to the sub-detail line what you pay for, no you can absolutely not have an overview or good estimation of mapping what a change in your software stack / setup will cost or save you. Unless we're talking "remove an entire service" and then duh, yeah.

How is that different from if you ran all this stuff on prem?

First, the obvious that if a massive surge happens (attack, bug, ...) on prem stop serving, aws surprise-drain your bank account. Yes it's possible to have fail safe to avoid it, it's also very common to not have them or that they're not tested or working.

Second, the "in-between" costslike bandwidth from service to service, iops on your disk, ... They mostly don't exist on prem, you either have enough of it and it works or you don't and it doesn't work and you need to go buy a bigger pipe. They're one of the biggest source of surprise cost on AWS.

Eg take a basic data storing application, the cpu and storage space are easy to estimate and are the same as on prem, but suddenly you also need to estimate your iops, and you realize you have no idea about it. Do you have an on-prem database running somewhere ? How many iops does it need ? Unless you've had to figure it out, you have no idea and will never know on prem.

If the AWS tools fail to provide you this information than you can just tag everything (we use scope, stage, service, region, owner tags, example: global, dev, hadoop, eu-west-1, data-engineering) and it is trivial to generate a cost report where you can drill down by environments, teams, services, etc.

Exactly,

I’m often fielding questions over on r/aws about how to do X on AWS where X is something simple. I then ask are they trying to solve problem X or are they trying to learn AWS. If it is the former, just use LightSail. Outside of serverless applications, I wouldn’t want the complications of full fledge AWS for a small project and I get paid to know the ins and outs of it.

AWS (or GCP or Azure or ...) value proposition depends on you.

For a small/startup, the ability to execute quickly without sinking capital into a product that will likely pivot anyway is a superpower.

When you get bigger, stuff gets dicey. Paying a premium for a "X as a Service" made sense when you had no people, but at some point the cost structure may not make sense or your needs are at odds with how the service delivery works.

When you work for a big company or government agency, things change again -- you don't hire a database guy for a project, you have a project team that builds stuff, and an ops team that exerts the minimum viable effort to keep your stuff running or an outsourced ops team that does the same, but worse. At that point, you start looking at how much it costs to pay AWS to provide and SLA vs hiring more competent (ie. more $$$) ops people to keep it running.

The long and short of it is that AWS is in a position to rake in cash up and down the spectrum -- all they need to do is be competent, which they are very good at.

> There's a whole suite of tools they provide around pricing and budgeting.

It could be there are such tools. But they are impossible to find, setup or understand for someone who is not already an AWS expert. I recently got a $500 bill from AWS. It was impossible for me to find out which S3 buckets (or even specific files) caused these costs. I looked at this for half an hour and have used AWS before. They just don't tell you how to obtain this information. Or maybe they do, and it is so well hidden that it might as well not exist. This was a horrible user experience. As a customer, I want to know what I'm being charged for. The fact that AWS make it so difficult make me never want to use them again.

You can get cost breakdown on a more granular level by taking advantage of tagging. You can tag your resources logically and get a break down by tag.

The biggest mistake I see is that people jump into AWS whole hog without doing the research or if they are large enough, hiring someone who knows what they are doing.

https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2...

I don't understand why I even need to do manual things such as "tagging" (besides learning what that even means in AWS) to find out something as simple as why I'm being charged as much as I'm being charged. I'm sorry. It's inexcusable.

And large organizations would complain about why they couldn’t group their resources like they want to. Having individual bucket costs would be of very little use for cost allocation and to tie back to something like a department. For instance, we tag every resource created with the same CloudFormation template with the same tag. We can get billing based on an “application” and all of its related resources.

Just like AWS is not understandable to someone new, I feel the modern front end ecosystem is royal cluster but yet and still thousands of people understand it after a 12 week boot camp.

You could have both. Let advanced users tag. But give less sophisticated users insight into what they're being charged for - without having to go through a 12 week boot camp.

Well, was most of that $500 for storage costs, or for network? Surely you don't expect the monthly bill to include details about particular files or bucket sizes? Have you enabled CloudTrail logging and/or VPC flow logs?

It's not my intention to victim-blame here, yet do bear in mind that there are many, many ways to use the services and to expose resources to the bottomless appetite of the internet. Maybe Digital Ocean or Linode or the like would be a better option for starting out.

It's literally called "Billing" and the "Cost Explorer" is the first item in the navigation when you go to the page. I've attached a screenshot and highlighted it for you. FYI, this month is the first time I've opened the AWS GUI in 4-5 months, and it took me about a minute to find the billing page and drill into our AWS costs. I've provided an image that shows how to get to the cost explorer from "Billing" (you can use the search box available on the AWS account landing page to type in "Billing" in order to access the billing page of AWS).

EDIT: sorry, I forgot to include the screenshot link - https://imgur.com/a/tVFoocr

This does not show the costs per bucket. Specifically, I was interested in the costs for data transfer for each of my buckets. As I said, after half an hour of looking into the "Billing" in AWS, the Cost Explorer and googling around I simply could not find a way to obtain this information.

You're right, it's shitty of them to not provide that out of the box. However, if it's such a big problem for you, as others have pointed out, it's easy to solve. If you are paying $500/month for S3, you must be processing quite a large amount of data - as another poster pointed out, there's an easy to fix it. If you weren't going to use S3 for this, what would you use instead for this use-case?

I literally just search on Google “How do I find the price per s3 bucket” and the first link is this.

https://aws.amazon.com/premiumsupport/knowledge-center/s3-fi...

Why do people think that they can give Amazon a credit card number and expect everything to be easy enough for them and suitable for a large enterprise? AWS offers something for beginners - Lightsail. When that outgrows their needs, they can peer their behind the scenes LightSail VPC to a full fledge VPC.

I look forward to migrating to Linode's S3-compatible object storage. I appreciate that you are agreeing that it's shitty of AWS. But I disagree that it's "easy to solve". Like I said, I already spent quite some time looking into how to solve it. And having to set up logging for a bucket (and learning how to do this in AWS's complex interface), and if I understand correctly creating another bucket to receive those logs, and learning how to then obtain and interpret the results? Maybe you're above my paygrade but I do not consider this easy.

What drew you to using S3 in the first place while also discounting the risk that it might get a lot of use, and thus a lot of cost? Like, if a 100MB file in a public bucket got a bazillion downloads, did you not want that to happen?

If this is an ongoing issue and you can’t get the information from something that is in front of S3 (cloudfront/your application etc) then you can enable bucket logging in the settings (which costs!)

> Have you ever used AWS? There's a whole suite of tools they provide around pricing and budgeting.

Yes, I use it extensively.

> Is applying separation of concerns to web services really that bad? Look, if you're a small company with a simple product, you can just put your stuff on a few EC2 boxes and pay the monthly bill for that. At that size, your infra costs are going to be dwarfed by your other costs of doing business anyway. If you're a big business, you can literally pay people to keep track of this stuff. You've got the extra money, because now you don't employ data center architects, server engineers, etc. AWS is able to "print money" because it brings a lot of value to many businesses.

It's not bad per se. The real problem I often see is that many people within the typical org aren't aware of how these costs can accumulate, especially when you have multiple DTAP environments, microservices, and so on.

Another problem is the days of "put your stuff on a few EC2 boxes" seem to have been overtaken by the cloud native, microservices, k8s trends of the last few years. Personally I 100% agree this is the way to go for many (if not most) people -- and for this purpose Digital Ocean is just as good -- but what I see more often is people diving straight into the deep end, because "Is applying separation of concerns to web services really that bad?"

I also think even big businesses underestimate the total costs of these all-in cloud infrastructures. You indeed need to pay people to keep track of this stuff -- multiple people. Your cloud costs + your devops/platform personnel costs can get to be a significant % of your total IT costs. Is it really necessary?

Just because your business has a big market cap or significant revenue from digital doesn't necessarily mean it needs any of that stuff. Chances are you can run it all on the same couple of EC2 boxes you ran it on when you were still a small company.

I think we are probably 90% in agreement on things, just talking about it in different terms. I think AWS/GCP have both gotten overwhelming in terms of how many different services they provide. Many people fall for it and end up playing AWS service golf (https://news.ycombinator.com/item?id=23274668).

Maybe a good analogy is to think of AWS as C. It's flexible and powerful, but it's easy to shoot yourself in the foot. That would explain why a lot of these "> magical-tool deploy" services have emerged, promising to abstract away AWS.

Yeah indeed. And I think often the perception of AWS is that it's more like Ruby. "It's what everyone uses, so it's a no brainer right?"

>> Another problem is the days of "put your stuff on a few EC2 boxes" seem to have been overtaken by the cloud-native, microservices, k8s trends of the last few years.

I am not sure where you get the notion that any serious user goes with the "put your stuff on a few EC2 boxes" approach. Every single AWS project I worked on had a cost calculation phase when we investigated what combination of services could be the most cost-efficient for a certain problem.

>> cloud-native, microservices, k8s trends

It is kind of funny that you try to put on one end AWS the company that made cloud computing popular (and microservices with it) and the biggest player in the segment and "cloud-native, microservices, k8s" on the other. Trends come and go, AWS is here for the long run.

They’re literally entire companies of 100+ employees selling a product that helps you figure out how much money you’re spending on AWS https://www.cloudability.com/

From where I stand as someone who isn't using Amazon figuring out what my costs will be is difficult, impossible and would require wasting money on various tests.

With something like digitalocean my costs are fixed. I might have misjudged how much I need but can scale up easily or down (with effort).

Will Amazon offer fixed pricing? Does Amazom offer fixed pricing?

Aws is definitely not for hobbyists, or small applications, its a replacement to a datacenter with a lot of variables, not a VM. Your better comparison would be DigitalOcean vs Lightsail (AWS). So yes.

Yes.

https://aws.amazon.com/lightsail/

They are awful. I have tried and tried to list the cost by resource (like you can in Azure) and I just can't figure it out. I think I might need to enable some special pricing tools (coincidentally not free) that Cost Explorer don't expose.