Amazon's Own Chips Are a $20B Business With $225B Booked. The Inference Behind Your Claude and OpenAI Calls Increasingly Runs on Trainium. That's a Supply Question.
The number resurfaced this weekend and it's worth staring at: Amazon's custom silicon business is running at roughly a $20 billion annualized rate, growing triple digits year over year, with more than $225 billion in multi-year revenue commitments already booked. Andy Jassy's framing is that Amazon isn't spending $200 billion on AI "on a hunch": the chip business is proof the demand is real.
For a solo operator, the interesting figure isn't the $20 billion. It's the commitments underneath it. Anthropic has committed to as much as five gigawatts of capacity on Amazon silicon; OpenAI, roughly two. Which means the inference behind the API calls your product makes (the Claude and GPT tokens you're reselling inside your app) increasingly runs on Trainium, on capacity your model providers have locked to one chipmaker for years.
You didn't sign that contract. But you inherited its shape.
Your token supply now has a dependency you didn't pick
Think about your actual dependency chain. Your product calls a model API. That API runs on a lab's infrastructure. That infrastructure is, more and more, Amazon's custom accelerators under multi-year take-or-pay-style commitments. Every layer of that chain that concentrates onto a single vendor is a layer where a supply shock, a price change, or a capacity crunch reaches you (a person with no leverage and no account manager) last and hardest.
This isn't a doomsday claim. It's the same lesson every operator eventually learns about any single point of dependency. When your payment processor, your host, or your one big client controls a chokepoint, you're fine right up until you're not, and you find out with the least warning of anyone. Compute is now that kind of chokepoint, sitting two layers below the API you think of as your supplier.
Cheaper inference is the good half of this
I don't want to only sound the alarm, because the same story is genuinely good for you in the near term. Amazon building a $20-billion silicon business exists to do one thing: drive the cost of inference down and the supply up. Trainium is Amazon's play to break Nvidia's pricing power, and there are reports it's in talks to sell those chips outside AWS. More competition at the silicon layer means the token prices you pay keep falling, which is exactly the trend that's made it possible to run a real AI product on a solo budget.
So the honest picture is two-sided. The concentration is a tail risk that shows up rarely and hurts a lot. The cheap inference is a daily benefit you're already spending. You don't get to keep the benefit and wish away the risk: you manage them together.
The hedge costs one config value
Here's the part that matters, and it's almost boring: the mitigation for "my token supply is concentrating behind one chip vendor" is the same mitigation for a dozen other AI-stack risks, and you can implement it this week. Keep at least two model providers wired up, and treat model choice as a configuration value rather than an architectural commitment.
Concretely, that means your product shouldn't call a single vendor's SDK directly from a hundred places in your code. It should call one internal interface (your own, or a router like OpenRouter or LiteLLM) behind which the actual provider is swappable. If Anthropic's capacity gets tight because a gigawatt of Trainium came online late, you route to a provider that isn't on the same squeeze. If OpenAI reprices, you compare and move. The switch is a config change and a re-test, not a rewrite.
If you've been meaning to do this and haven't, the Amazon numbers are your reminder that the reason to do it isn't hypothetical vendor drama: it's structural. The compute market is consolidating in ways you can see in the earnings call, and your one-line insurance policy is to never be architecturally married to a single link in a chain you don't control.
What I'd actually do
Look at your codebase and answer one question honestly: if your primary model provider had a bad week, how many files would you touch to move traffic elsewhere? If the answer is "more than one," that's the whole to-do list. Put your model calls behind a single swappable interface, wire in a second provider you've actually tested against your real prompts, and confirm the fallback works before you need it. That's a Saturday.
What I wouldn't do is panic-diversify your whole stack over a risk that's real but slow-moving. Amazon's silicon dominance isn't going to strand you tomorrow. It's a reason to hold the cheap, obvious insurance, not to rearchitect around a tail event that may never fire.
Author
Lukas
@lukcombinator