I would presume AWS is so large these days that Amazon retail's infra is only a small fraction of the fleet?

Published data on their scale is thin on the ground, but this post from 2017 guesstimated that they had 4 million physical servers at the time, and AWS certainly hasn't shrunk since then:

https://blog.sqlizer.io/posts/facebook-on-aws/

Amazon retail's total combined capacity usage can on most days fit entirely into the spare capacity that AWS keeps available for spot and burst usage by other customers

This article is about how much profit from Amazon comes from AWS. Not how big of a 'client' Amazon is in AWS itself.

Well, if you read the parent comment here again, I hope you can understand that "how big of a 'client' Amazon is in AWS itself" is _precisely_ about estimating profits for AWS.

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.

Every large corporation has the concept of “Organizational Finance” and cost accounting where they charge internal departments and treat them like customers. Also, not all of Amazon retail’s infrastructure is hosted on AWS.

As an aside, I was listening to an interview by someone at GCP and they said that almost none of Google’s infrastructure is part of GCP besides some internal software.

1) "very difficult to extricate costs of server farms that support the retail operation from server farms that host client services from overall operating costs."

Not only is not not hard to do, they are almost assuredly already doing it.

2) It matters a lot, and the article does not miss the point.

As for 1 - AWS Retail is a 'customer account', and they can track and measure the services used.

They have to do this because that's how 'management accounting' works. 'Accounting' is not just a 'GATT' thing, it's also for measuring how profitable units and businesses are. AWS services used by a product will be charged not only to AWS services but even internally to a product account at Amazon Retail.

As for 2 - it matters a lot because Amazon is dumping on Amazon retail, which may be an anti-competitive practice.

Not only does AWS show x% contribution to profit, but it's also probably much worse: Amazon Retail may be significantly in the red after 25 years of operation, subsidized by AWS.

Given Amazon's size and leverage in retail, it's definitely time to look at breaking them up in order to separate the two businesses.

In normal times, this would be 'good for America' for obvious reasons. But in a 'big global economic fight' - it might be better from a nationalist perspective to let it go on at AWS, G, Oracle, MS etc.

Has anyone noticed all the big, fat successful cloud players are only ever built by companies with zillions to spare? Implying that this is huge competitive advantage of America vis-a-vis other nations (and continents) who can't hope to compete without government intervention.

AWS/Amazon Retail is an anomalous cojoining of businesses, which is fine, but it probably needs to be looked at along with the overlapping of the other cloud providers and their main businesses.

I thought Amazon don't use aws for their main product. Do they use it for alexa?

Amazon runs virtually everything on AWS. There are probably some exceptions for exotic infrastructure, but the vast majority of compute and storage systems at Amazon run on top of AWS. There's probably a team using every single AWS service somewhere in the company.

This doesn't mean that Amazon only uses AWS products, though. Amazon continues to use e.g. Akamai for static content hosting for some use-cases, in addition to using CloudFront for other use-cases, and other products beyond that.

Amazon also uses third-party services. For example, while Amazon has long been using Chime internally for IM, chat, and voice/video calling (Chime being the AWS solution for those things), they recently announced a partnership with Slack [1]. To summarize, Amazon will deploy Slack and use it for chat, while Slack will deploy Chime and use it for voice/video calling. I believe that Slack has been running on AWS since its founding [2]. I would hazard a guess that an undertone of the agreement is that Chime will continue focusing on its strength (which is voice/video calling for organizations) and probably not invest a lot in the chat features where Slack is already strong, and vice versa.

All that being said, certainly not everything runs on AWS across all of Amazon, which is a big company, with a host of acquisitions like Zappos, Twitch, Whole Foods, etc., that come with their own legacy or custom infrastructure.

But bread-and-butter software teams at Amazon all typically run on AWS.

[1] https://www.businesswire.com/news/home/20200604005766/en/AWS...

[2] https://aws.amazon.com/solutions/case-studies/slack/#:~:text....

> Amazon runs virtually everything on AWS.

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...

> Amazon continues to use e.g. Akamai for static content hosting for some use-cases, in addition to using CloudFront for other use-cases

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

I don't actually know the reason. I'll see if I can find out and whether it's appropriate to share. It's possible that it's a redundancy thing (have multiple providers so we stay up if one goes down), a performance thing, or it could be a features thing. I don't know.

I will note that what Akamai is trying to do: serve static content extremely quickly from locations close to all customers, is a bit different from what the typical AWS services and AWS region are trying to do. Akamai probably wants to cache identical content all over the world, in boxes that I would expect to be present within the network of many different ISPs (just like Netflix does to serve its video [1]).

In Oct 2019, CloudFront announced that they had 200 different points of presence (POPS) around the globe [2]. I don't know exactly how to compare Akamai to CloudFront, but Akamai claims to have POPs in over 130 countries and in 1,700 networks [3]. Akamai was founded only four years after Amazon and has been focused on content distribution since then. Just like a company can't snap their fingers and have Amazon's retail logistics presence, AWS can't snap its fingers and have CloudFront POPs in every country/network/ISP where Amazon Retail needs good performance. The answer may be that they're still catching up.

I'm completely I'm speculating though, and don't have any knowledge about this beyond the public research that I linked to.

[1] https://openconnect.netflix.com/en/

[2] https://aws.amazon.com/blogs/aws/200-amazon-cloudfront-point...

[3] https://www.akamai.com/us/en/resources/visualizing-akamai/me...

My guesses: a) Amazon.com/co.uk/etc traffic is too big even for CloudFront. b) They don't want Amazon.com traffic to evict AWS customers' cached items out of CloudFront, the very reason customers buy CloudFront in the first place. c) Legacy, they just didn't move from Akamai yet.

Content distribution is easily commoditized, hence not very interesting for Amazon.

I know a colleague that worked on Alexa stuff and he said they did use AWS infrastructure and part of his job was reducing the cost Alexa paid to AWS...

On the one hand that sounds weird and AWS could just offer any discount, on the other if they can get done the same on less resources, others can rent the freed up resources at a premium

This is called cross-org transfer pricing. It's a common practice in accounting. In fact, imagine a company where this doesn't happen. Retail decides that they can "excessively" use AWS. This contributes to waste and problematic accounting when it comes time to report finances.

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

Indeed half the point of AWS was to facilitate cost accounting. Probably because Bezos thought they had expertise in online marketplaces that would transfer. Jury's still deliberating on whether AWS' incomprehensible billing is a signal of incompetence or sheer brilliance.

> Jury's still deliberating on whether AWS' incomprehensible billing is a signal of incompetence or sheer brilliance.

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

Designing billing for a service can be really challenging. The ideal pricing structure exactly aligns the incentives of the customer with the costs of the service provider.

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.

So why didn't that customer just start sending emails that weren't MIME compatible--and so wouldn't have "attachments"--but still carried a very large amount of base64 encoded data (which is all MIME is doing anyway)?

As I recall, in this customer's use case, they wanted to deliver the data as email attachments that the recipient could download (recipients were regular people). I think they were selling ringtones or MP3s or something of that nature and the email was the method of delivery. It was a pretty cool concept.

> 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

Something like that does exist: https://en.wikipedia.org/wiki/Nationwide_Wireless_Priority_S... Mostly cops only. Fun fact: satellite phones had terrible reliability during Katrina, because so many FEMA people showed up and tried using them at the same time that they saturated the Iridium network.

Thanks jcrites for sharing some details on the genesis of AWS SES pricing plans!

I just added your contribution to my collection of resources on cloud billing: https://github.com/kdeldycke/awesome-billing/commit/df095efa...

I've had to build out my own dashboards using their api to make sense of our AWS envs.

It can also open up a can of worms as companies as big as Amazon can get into trouble with regulators.

When I worked at BT we could not crosssubsidize say our online services and had to give up the short dial for access 618 used to connect you to PRESTEL on any exchange.

Also at one point they where considering not allowing people working for a joint venture to use the same restaurants

That compute isn't free - it comes at the opportunity cost of being sold to a paying customer so it makes sense to price it internally even if it is "virtual"

It's pretty normal to account for use of cross department internal resources in some kind of financial way within corporations.

> On the one hand that sounds weird

It wouldn’t sound weird if one’s goal was reduce the number of servers used by 20%. Excess spend is excess spend.

The retail website uses AWS.

It is complicated.

It is definitely wrong to say retail doesn't use AWS.