The fact that Amazon is self-serving AWS resources is obfuscating profit calculations or estimates as there is no way of determining ROI on assets Amazon consumes itself - most likely in a somewhat shared model together with other, actually paying customers.

As a soon to be employee on the AWS side and speaking very selfishly, I could see it benefiting AWS employees tremendously being separate from the low margin retail side. They would probably have benefits and compensation more in line with the other BigTech companies.

Employees at AWS definitely wouldn’t be as limited in what they can contribute to their 401K because they are considered Highly Compensated Employees and the contribution rate is weighed down by factory workers.

People have been complaining about Amazon's investing policies (like reinvesting every penny instead of paying out dividends) for decades and not gotten anywhere though.

Walmart is responsible for the 7th, 8th and 9th largest fortunes in the world built before modern monetary policy. Further they completely changed retail in America.

Those seem like weird counter examples.

In and out of Amazon or Amazon's eco-system. You should qualify this as they are very different perspectives.

Does sable, the internal nosql database used for practically everything in retail run on AWS nowadays? Cause it didn't back in 2018 which and partially why they couldn't scale up on prime day and got overloaded [0, and have friends who worked in retail].

[0]: https://www.cnet.com/news/report-why-amazon-crashed-on-prime...

I find this pretty surprising. Do you know the reason?

No, you just had downtime, full stop. Failures are inevitable, regardless of whose datacenter you're using. Failure-tolerant architecture design minimizes (or eliminates, if you're lucky) the downtime caused by failures. I'm not saying that's easy or necessarily appropriate depending on the stage of your company, but foisting responsibility onto AWS is missing the point.

By which definition? It’s trivial to switch to a different website to order from, and Target/Walmart/Bestbuy/etc have significant market share.

The lock-in really comes from AWS-specific services. Redis, Mongo, etc will have the same API no matter where you're hosting them, so it's pretty trivial to point your client-side code to a different cloud-hosted Redis instance if you find AWS lacking there.

Depending on the startup, that may make sense if it allows for fast iteration.

If a startup is trying to achieve product market fit, having a huge AWS bill is a good problem to have, since it means the product is actually successful.

You’re always tied into your infrastructure once you have any type of scale. The pain of migration is huge.

I once worked with a company whose entire workflow was integrated with six or seven vendors through APIs.

Have you ever worked in the healthcare industry? The level of lock-in they have to their EMR/EHR would make you cry.

I think "between 50% and 80%" of the profits of the most valuable company in the world settles that.

As a service designer, it is challenging to achieve this and strike the right balance. One naive solution is to account for all of the possible costs that users generate, and surface them with a price in the bill. But this can result in extremely complex pricing structures with many dimensions. If you account for many cost dimensions, then your pricing plan is complex and can be hard to understand, and difficult for users to forecast for.

However, if you over-simplify, and reduce the pricing plan to too few dimensions, then you risk running into other problems, such as failing to charge adequately for user behavior that can cause the service to run at a loss (consider e.g. MoviePass -- which simply charged less for the service than what it cost to operate).

Another common alternative is to charge a fixed price and over-subscribe the underlying infrastructure. This can be a reasonable solution in some situations: it's not very likely for literally every person with a cell phone to make a call at the same time, for example. Many infrastructure providers charge a flat rate and scale for the expected regular (daily or weekly) peak. But if there's a massive natural disaster then a large number of people might make calls, and the network might fail. If you are an e.g. doctor who needs to be called to a hospital, or a first responder who needs to be called to a scene, no matter the situation, then perhaps the right pricing plan and offering for you is something like a guaranteed cell phone line, which comes with the promise that it will not be over-subscribed; but this will come with a cost, since you are paying the infrastructure provider to keep that circuit around and idle. Most retail cell phone users don't want this trade-off, but a few specialized users might. These are the kinds of complications that you encounter when designing business plans and prices.

(I'm making up an example about phones but hopefully it gets the point across.)

I can share a personal anecdote about a challenge in designing the pricing plan for Simple Email Service: we launched the service charging a flat rate of $0.10 per thousand emails (a price substantially lower than other providers at the time). Then one user decided to use us as a data delivery platform, doing nothing but sending maximum-sized emails with attachments. We expected some variation in email size but didn't account for a use-case of constantly sending max-size emails.

What are our options?

1. We could do nothing and potentially take a loss on this customer, subsidizing their usage forever from the revenue from other customers. That's not fair to other customers of the service, and subsidies like this might prevent us from lowering the price of the service in the future.

2. You can tell a customer that you can't support their usage -- essentially kick them off the platform. That's the last resort for all businesses, but it is an option.

3. We could introduce a price per byte of email size, but email size is insignificant for the vast majority of users. Most users want to be charged by the number of emails that they send -- they don't want to have to think about the size of their emails, which are typically not significant. Charging per message is also the industry standard, what users expect, and keeps the pricing plan simple.

Charging per message also has the important property of making it simple for users to forecast what their costs will be for some potential usage, which is an important property of a pricing plan: this is not necessarily true if we charge for the byte-size of emails. Companies can't necessarily forecast the size of all the emails they will send since they can be generated as the result of e.g. personalization or user behavior.

Here's what we actually did:

4. We resolved this particular challenge by introducing a price that only applies if the email has a data attachment. If you send an email with an attachment, then there is an additional price that applies per GB of attachments sent. In this way we kept the price simple for the vast majority of the user base, while accounting for this cost in a way that allowed the user to keep doing what they were doing if they wanted to.

AWS teams invest a lot of thought into getting pricing right. It's a very difficult design challenge, especially when you involve the combination of many services, many potential user behaviors, as well as in what state your infrastructure will be in during yearly peak usage (whenever that might be -- e.g. tax day, Prime Day, Chinese New Year, or whatever is relevant to your service). In designing pricing plans, it is a constant struggle between trying to keep them simple, while trying to allow them to be complex enough to model the important parameters of users behavior.

Here is a list I found from a quick search, try to guess which country the biggest producers is based in or how many of top 5 you expect to have heard of before opening the link.

https://en.wikipedia.org/wiki/List_of_steel_producers