He's overly simplifying the contribution to profit by not understanding the contribution to expenses. It's not his fault because Amazon doesn't break it out that way. They don't allocate certain expenses to AWS and other expenses to other branches.
While there's no doubt that AWS is very profitable, to say it contributes a certain percentage to overall profits probably misses the mark tremendously.
It's probably and most likely very difficult to extricate costs of server farms that support the retail operation from server farms that host client services from overall operating costs. You'd need far more detail on gross margins and tight definitions for contribution of revenue. For example, do people who order things on Alexa get revenue counted for non-AWS while the Alexa infrastructure is counted as AWS expense? These are not easy questions. This is why it's not broken out as you'd like.
I'd wager that the contribution to profits is not as suggested here, but it's hard to know just how far off the calculation is. And it might not matter.
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:
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
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.
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.
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].
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.
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.
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.
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.
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.
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"
Profit can be a really weird number, especially when it comes to data centers. So looking at pure earning statements numbers is likely going to be misleading no matter how you try to look at (unless you actually look at bank statements, you can create as many interpretations as you want).
First, data centers require A LOT of upfront capital. This capital is then capitalized over years, which is how it ultimately affects "profit". So depending on the capitalization schedule, how much they are investing in future growth, etc. will all affect this number. It's why, in short, Bezo's doesn't ever look at these numbers, but instead free cash flow (FCF).
“Percentage margins are not one of the things we are seeking to optimize. It’s the absolute dollar free cash flow per share that you want to maximize, and if you can do that by lowering margins, we would do that. So if you could take the free cash flow, that’s something that investors can spend. Investors can’t spend percentage margins.”[0]
So, the real metric to look at is the FCF/DCF generated by AWS. If we had that number, I think you could basically conclude that it's "printing money".
There are so few clouds, that it doesn’t work like this. When I saw it first hand the way it was done is prices were set to match competition. Occasionally somebody would reduce the prices, and others would match it. Since offerings are not exactly the same, there are variations, but overall for basic services like VMs and storage neither cloud will give you significant advantage in price.
Even if Google’s prices were half that of Amazon’s, it’s really hard to quantify the savings since the platform offerings are not identical, plus engineering switching costs could easily outstrip a company’s yearly cloud costs.
Which is then fueled by cheap credit and already existing high levels of free cash flow. It's not a problem until demand dries up, which as you are probably aware, does not look like its slowing down anytime soon.
There is no need to put profits in scare quotes. There are GAAP standards for publishing profits and anyone with an accounting background understands what profits mean.
Is looking only at FCF valid for startups/investments too? Or is higher profit % still important? I think Amazon might be a special case with its size and stage.
I'm not sure if this helps or hurts Tim's assertions (not mentioned in this piece, but from context he wants AWS to be spun off into a separate company). if AWS' share is so high, would AMZN shareholders approve a spinoff? does it matter since they get ownership of new-AWS anyway? unclear
whatever it is I think Tim has a research agenda here and we shouldn't be surprised to see him come up with a more forceful blogpost on the topic soon.
(I'm an engineer at Amazon, but I don't speak on behalf of the company, I'm just sharing my experience)
Here are a few different ways that AWS and Retail interact:
1. The obvious that everyone knows: Retail uses AWS's products, providing feedback and ideas for new services and features.
2. Employee transfers: it's quite common for people to move between Retail and AWS and vice versa, and they bring what they learned in one org to their new org, helping to spread information about best practices.
3. Other employee knowledge transfers: I've personally benefited from engineers in AWS sharing their knowledge about general engineering topics on internal interest mailing lists or through tech talks.
4. Best practices: there are some differences, but AWS and Retail operate similarly in many ways: use of 6-pagers for sharing ideas (https://www.linkedin.com/pulse/beauty-amazons-6-pager-brad-p...), weekly review of metrics, hiring tools and practices being just a few examples.
This is all a Devils Advocate post. I have no reason to complain about my (future) compensation. Working in the consulting division allowed me to make $BigTech money as an “Enterprise Developer” without studying a single algorithm, and being able to work completely remote from a low cost of living area....
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.
In general, investors would prefer two companies because those looking to invest in retail wouldn’t have to expose themselves to cloud & vice versa. That increase in demand for each component (investors who formerly ignored the stock owing to the above) would make the share price go up, all else constant.
Amazon stock performs well because a lot of investors want access to both, so it’s not that big of a deal. Also Jeff Bezos holds a disproportionate amount of voting power (part of why he’s the richest person is because he held on to an unusually high percent of an unusually valuable company).
Ultimately they won’t split until one of them stops being a world-eating monster because no one will have leverage to force it on Jeff. It may never happen as long as amazon exists. But I guarantee the day amazon cloud stops growing at insane rates, people will call for a breakup.
> Ultimately they won’t split until one of them stops being a world-eating monster because no one will have leverage to force it on Jeff. It may never happen as long as amazon exists. But I guarantee the day amazon cloud stops growing at insane rates, people will call for a breakup.
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.
It is important to consider that Amazon probably still considers its retail business a growth business, and that it has not captured enough of the market yet to start raising prices.
I am pretty sure Amazon's retail business is going to completely dwarf AWS in the long term, because they are currently willing to break even on it (and possibly lose money) just to outdo the competition.
Competing on price never pays off imho. You’ll race to the bottom. Amazon already has a massive monopoly on retail, and they wouldn’t dare mess with the prices.
My experience:
I once tried to corner the market on WoW gems by buying out the undercutters and setting my desired price. My money wasn’t long enough.
I really don’t think anyone’s money is long enough :p
1. Amazon already has your payment information. I was on my phone looking to order something. The first link that came up was Walmart. I went and searched on Amazon because I could just press “Order Now” and not have to create a new account and dig up my credit card.
2. I’m already paying for Amazon Prime. Why not get full use out of it for shipping?
3. Amazon marketplace has network effects. Third party sellers use it because the buyers are there.
4. I wanted to rent a movie on my Roku TV. Again, Amazon already has my payment information and I’m already signed in to Prime Video.
5. I get 3% discounts on my Amazon card when ordering from Amazon.
I’ve been downvoted to oblivion plenty of times about being against the government interfering in $BigTech whether it be Google, Amazon, or Apple so I’m definitely not proposing they should be broken up because of a “monopoly”.
A monopoly would indicate there exists a lack of options for buyers or control of prices from a very large seller.
As it stands now, Amazon is a glorified Alibaba that sided with buyers in disputes.
You can find the same things on Amazon on Alibaba, Newegg, bestbuy, Walmart, iTunes, Google Play, the Amazon sellers own websites, etc. the buyer is in no way required or affected negatively by not interacting with Amazon.
So I’m struggling to see the point of labeling Amazon a monopoly when it doesn’t convey any useful information.
They're not competing on price — they're competing on logistics, primarily. They're losing money to offer consumers an experience they can't get on any other platform. Way more defensible than price competition.
I think they're viewing it instead as continuing to reinvest profits until they're a cyberpunk level corporate power. It's not that they're cutting prices, it's that they're using the excess to buy companies like Whole Foods and vertically integrate them rather than paying out to shareholders, or building a bigger war chest in an index fund.
"Amazon's retail business is going to completely dwarf AWS in the long term"
It will in revenues but not in profits.
Right now, Wallmart, Exxon, GM etc. 'dwarf' most tech businesses in terms of revenues and the size of their businesses, but the profits are smaller, so tech companies have a higher valuation.
Hmm.. they might want to look at Sears or Walmart.
Sears is more or less dead. Walmart is struggling to keep market share with amz. With groceries their only saving grace
If price is their long term plan with retail that is a loosing proposal. Once they dominant they might be able to sqeeze the market for a few years maybe a decade but them something else will topple them
Sears was started over 115 years ago and was a dominating force for most of those years.
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.
Which Amazon has thanked almost everyone and their grocery stores for jumping on their bandwagon and spending nearly all their VC money on these services.
Those without any significant revenues will have a hard-time paying up that huge AWS bill if they dared to use K8s or auto-scaling features. I would not want to look at the balance sheet of a companies accounts or quarterly earnings if they cannot generate lots of revenue to pay that AWS bill.
Do you remember the days when everyone had their own data center and setting up a server involving drawing up specs then putting in a PO then waiting for it to get delivered on a truck to be racked and formatted? AWS is magic and the price is entirely justified.
Yes and also i clearly remember in 2007 trying ec2 for first time and asking, is it production ready? Could we actually use this vs. building out a cage. And in 2007 the answer was no. Something about no external IP addresses or no load balancer possible. But yes that cage was expensive and the last cage I ever got. AWS is magic and amazing.
did you read what I wrote? It was just a nice little story about trying aws for the first time in 2007 and then never getting a cage again. It was PRO-aws.
Under these circumstances, how is AWS lock-in and cost escalation any different from Oracle of the past?
Why would any startup shackle themselves to AWS or any cloud when it's not portable?
Lambdas, in particular, seem like the worst idea in the history of ideas. Once your org adopts them, how do you keep track of these mysterious, business-critical pieces of functionality? How do you ever plan to port them to something else? It seems like you become an Amazon customer forever.
I am incredibly skeptical of cloud at this point. If the other infrastructure and platform concerns of OS upgrades, patches, etc. were handled in an automated way, I'd strongly consider running Kubernetes on bare metal. Data centers and colocation all the way.
I'm eager for self-management of k8s, DBs, Redis, etc. to be automated with tooling. On-prem, but easy to maintain.
edit: wow, from +3 to 0 after an hour. I maintain that I articulated my opinion well in an unbiased way.
Lambdas, at least the JS ones, are Node.js based and not hard at all to migrate to an alternative cloud service. You can even use a framework that handles all the cloud-specific functionality for you and works across AWS, Azure, GCloud, etc: https://www.serverless.com/
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.
I agree and just want to add IAM to the list of AWS Lock In services. We provisions environments almost entirely using Config-as-code tools (packer, ansible, terraform) and generally have a good blueprint for what an environment looks like and the parts I’ve had the hardest time thinking about migrating to another cloud provider is all the IAM rules that magically give hosts/services the ability to talk to other services.
I'm not sure about GCP, but Azure does offer role-based access[1] which gives you similar resource authentication magic to what IAM provides. The definition formats[2] even look fairly close to their IAM equivalents.
It's used in combination with Azure Active Directory, so the modality isn't 1:1 with AWS. But Managed Identities[3] is a feature that's rolling out across Azure which simplifies the model a bit, since it negates the need to create service principles in AAD beforehand.
IAM is simply one of AWS's killer features. It's just a service that's so good it differentiates itself from the competition. Lock-in based on quality is not the sort of lock-in that I'm most worried about, because it's very clear what I'm getting in return for it. The alternative to using IAM to begin with would be to commit to work comparable in scope to that required to migrate away from it in the future.
> Why would any startup shackle themselves to AWS or any cloud when it's not portable?
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.
Only servers used for client requests. Dev and integration environments but esp data crunching can be a lot more expensive than serving web requests. And they're hard to keep cheap if you scaling is easy.
What's your alternative? Go on prem or build your own competing cloud provider? Probably not. The open markets have set the prices for cloud compute and storage resources.
I'd argue that the existence of cloud providers have only accelerated the growth of the tech industry and has in fact put more money in the pockets of tech workers and VCs than there would have been without the existence of an AWS/Azure/GCP/etc
I hear this a lot, but I rarely see any data or evidence to back this up.
The company I work for used to have most of its revenue come from VC-backed startups. Over time that changed as we courted more well-capitalized enterprises. If our VC-backed-startup customers all went bankrupt tomorrow, it would certainly hurt, but it wouldn't kill us, not by a long shot.
I would expect that to be even more true for a product like AWS, not less.
After working for a company that spends millions of VC money on AWS per year I can also say that infinite cloud scaling is a myth. We had all kinds of downtimes due to AWS over the years.
> We had all kinds of downtimes due to AWS over the years.
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.
I am not "foisting responsibility". There are fallbacks and fail safes in place to mitigate such issues but that's not my point. My point is that they sell us a dream of infinite scaling, all managed and no more problems, which just isn't the case. I know, it's naive to believe that in the first place but the marketing certainly goes into that direction and some proponents spin this story all the time. Would the alternative be better? Most certainly not, but it's still a question worth asking from time to time considering the extra money spent.
I think you're maybe mixing up different things? "Infinite scaling" doesn't mean your app is failure-free and constantly available. In my experience AWS's scaling features work pretty well, as does their on-demand provisioning. But they have very little to do with tolerating infrastructure failures. That's up to you, regardless of whether you're developing on AWS or on hardware you own.
Let me provide an example. When we recreated a big Elasticsearch cluster, AWS ran out of available instance types in that AZ resulting in the cluster never going into a green state because a node was missing. This is not something you typically worry about when you choose a cloud provider. Your tone is a bit condescending tbh, you don't need to lecture me about the importance of a fault tolerant distributed system.
yeah, kayoone response was to the argument “AWS is more expensive but it scales”. In fact it’s not magic and you still have to manage it so worth looking at alternatives such as bare metal, especially at scale.
That makes sense honestly, B2B SaaS is lucrative, steady, and honestly probably moreso than a B2C business could be. Many of the big software players most people have never heard of.
As a consumer, you're almost certainly in a Salesforce system somewhere, but most people have no idea what Salesforce is.
The steel production and raw materials industry is a whole different world. I am not knowledgable in the area at all but a recent linkedin post by a friend was listing the biggest steel producers by country, I did not recognise any names except Tata from India and Thyssenkrupp from Germany.
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.
That is a lot of Chinese steel, at what looks to be about 25% of the total worldwide production, just by the companies listed in the top 41. It looks like possibly a majority of worldwide production isn't in this list (which seems to gut off at less than 10 million tonnes), so it's possible it's even higher, if there's a lot of small steel companies based in China as well.
This is actually pretty amazing. I predicted that the top few would be US based companies but I hadn't heard of them because they are rounding errors. I was wrong about that but the first US based steel company on the list is in my neighborhood. I ride up to their plant on my daily bike ride.
I am always amazed when I listen to my rancher buddy talk about cattle prices on weekly calls. There are so many industries I'm completely oblivious to.
I actually have agriculture experience. That's how I paid for college. You're absolutely right but I bet there's more than one AWS.
I think many people have heard of John Deere and Monsanto but what about McGregor? They may not be as big as AWS but even with Ag experience I bet there are bigger similar organizations.
I bet there are big custom harvest operations too. We had a two man operation on the Palouse but I heard stories about huge operations out of Texas that migrated through the midwest following harvest cycles.
Amazon's online store was basically an incubator that allowed the company to pivot to its real profit center: virtualized online services for startups and companies seeking to move to the cloud.
Or that AWS reduced the cost of its retail operations (no store, no real estate, no staff, etc.) so dramatically that it drove out nearly all its competitors that it became the universal intermediary between buyers and sellers. The profits from its retail operations allowed it to reinvest in its data centers that it achieved ever greater economies of scale. The two arms of Amazon were synergistic.
To anyone who wants to learn more I highly recommend https://www.profgalloway.com - Basically a bunch of idealogy around why the big four need to be broken up.
This drives me mad. I have no idea why Amazon even bothers with the retail side. It barely pays for itself, they are already the biggest player by a mile, and there is no horizon in which economies of scale start paying off (the uptick of demand from Covid probably lost them money!)
The only thing that makes sense to me is some political long play. The Amazon retail operation employs a lot more people in a lot more places than just the coast. I think leadership has realized they need to be seen as a job creator by politicians in order to join the "big boy industry" club. Which is why Amazon doesn't mind paying their warehouse workers more than all the other guys.
To that end, the Amazon.com is just a giant, self-funded employment program designed to make Amazon a bigger company.
It’s speculative to say that “Amazon can start turning on major retail profits at any time it chooses.” Amazon has not done it yet, so there’s really no proof that it would be so easy, or even possible.
I know the party line, which is that Amazon chooses not to take retail profits because they would rather invest in growth.
But invert that statement to understand it a different way: it implies that when they choose to take retail profits, their growth will slow. (If they could take profits and keep growing they would already be doing that.) How will investors like an Amazon that’s not growing anymore?
Personally I think that the way Amazon’s retail side runs today is the only way it knows how to run, and is how it will always run. The expectation of massive retail profits will always dangle out there in the future like a carrot for investors to chase.
Just look at how much money Amazon is spending on Prime shipping. It's insane. They're never going to turn a profit, because as soon as they stop subsidizing shipping customers will go elsewhere. There is no reason to expect Amazon's retail arm to ever be more profitable than Walmart is.
Isn't the idea behind prime shipping that with enough volume, any product in demand should already be stored close to the customer? Their expanding fleet of aircrafts make me doubt that it works that well but who knows, maybe their air cargo as a percentage of all shipping is decreasing drastically.
In the end, online stores aren't that hard to build and local stores can become competitive if Amazon really decides to cash out. Amazon is growing so fast because they don't really turn a profit, not because they pushed everyone else out of the market.
"Constantly reinvesting for even bigger economies of scale."
This may have made sense 5 years ago, but this doesn't make sense when their margins have only gotten lower and their number one expense is employees, which is a marginal cost. They are well into the "diseconomies of scale" territory. And there are more competitors now then when they started!
> You don't seem to actually understand Amazon's business model at all
Source: I have worked in and out of the Amazon ecosystem for 5 years.
Perhaps Amazon is trying to be the major fulfillment provider as automation of order picking becomes more productive, and those employees are made redundant; a sort of "Netflix for warehouses" model (where Netflix went from mail fulfillment to online).
Yeah, Amazon's operating income margin is about 15-20% before R&D expenses.
To GP's point though, there is only so much market capacity for Amazon's growth so there will be a point that investors think that Amazon would best be using it's cash somewhere else, including dividends. It happened to Apple and it can happen to Amazon.
> Because they're constantly reinvesting for even bigger economies of scale.
Not exactly.
To avoid paying taxes, any extra net income is reinvested. It's like a religion in senior management to avoid taxes. And to lobby for employee non-competes, too.
Also, margins on retail are not the same as pure tech companies, like Google or Microsoft. US grocery stores, like Safeway, have net income in the 1% of total revenue range, so if Amazon can make 10-15% on retail, that's impressive.
Disclaimer: I work at Amazon and own AMZN, but I have no inside knowledge about this and my opinion is my own.
If investments into efficiency and scale can produce AWS, and create an entirely new market segment; couldn't continued investments into efficiency and scale produce the next-AWS?
It could, and finding the next big thing is extremely profitable. But few companies are able to repeat that process. However, with enough money AMZN could become like Microsoft and successfully build their own products if others have shown that it's worth it. Microsoft also uses profits from some business lines to pay for losses in a lot of ventures of which only very few work out.
Great point. Although I am not convinced that in a perfect political vacuum the two companies would not be better off as two separate companies with some joint agreement.
<quote>(the uptick of demand from Covid probably lost them money!)</quote>
I would frequently get deliveries from Whole Foods Market or get stuff off amazon a couple times a week. Due to covid just making deliveries impossible I've cancelled my Prime Subscription and haven't bought anything from Amazon in months. It wouldn't surprise me to see their revenue go down from Prime memberships.
While there's no doubt that AWS is very profitable, to say it contributes a certain percentage to overall profits probably misses the mark tremendously.
It's probably and most likely very difficult to extricate costs of server farms that support the retail operation from server farms that host client services from overall operating costs. You'd need far more detail on gross margins and tight definitions for contribution of revenue. For example, do people who order things on Alexa get revenue counted for non-AWS while the Alexa infrastructure is counted as AWS expense? These are not easy questions. This is why it's not broken out as you'd like.
I'd wager that the contribution to profits is not as suggested here, but it's hard to know just how far off the calculation is. And it might not matter.