Why AWS Needs an Old Navy
Why AWS Needs an Old Navy
Self-Cannibalize or Be Cannibalized.
Enterprises won’t migrate off AWS. They never do. Not for elegance. They migrate for regulatory mandate, catastrophic failure, or economic inevitability.
But enterprise cloud revenue is not just maintenance revenue. It’s new product launches, new internal platforms, new AI initiatives, regional expansions, and M&A integrations. Net-new projects are the growth engine. Whoever wins them controls the next decade.
Greenfield starts as developer preference. Developer preference becomes internal platform choice. Internal platform choice becomes procurement pattern. By the time purchasing gets involved, the decision was made two years ago by an engineer who typed railway up instead of writing a CloudFormation template.
If AWS loses greenfield developer mindshare for five consecutive years, enterprise lock-in will not save it from margin compression. Wall Street won’t notice at first. By the time it does, the compounding will be irreversible.
The Interface Layer Is Migrating
AWS’s dominance was never really about the data centers or the 200+ services. It was about the fact that developers interacted with AWS directly. They wrote CloudFormation templates. They configured IAM policies. They understood VPC networking. They owned the interface between the developer and the machine.
That interface is migrating upward. Platforms like Fly.io, Railway, and Render have built deployment experiences that make AWS feel like filing taxes. railway up. That’s the entire deployment process.
Once the interface layer migrates up the stack, hyperscalers reduce to interchangeable infrastructure vendors competing on price and geography. This is an existential problem, not a product one.
The Four-Sided Squeeze
Regulatory pressure is dismantling the financial lock-in. AWS lock-in runs deep: data gravity, service entanglement across RDS, DynamoDB, Kinesis, and IAM, contractual commitments, and the sheer risk of migration downtime. Egress pricing is not the moat itself, but it is the visible tax layered on top of all of it. Roughly 9 cents per gigabyte while wholesale bandwidth costs have fallen 93% over the past decade, with zero movement in North America and Europe since 2018. The EU Data Act will prohibit cloud switching fees entirely from January 2027. The financial friction that amplified every other lock-in is being legislated away.
Abstraction layers are capturing the developer interface. Platforms like Railway and Render collapse networking, identity, and secrets management into opinionated defaults you never see. New developers are learning to deploy on these platforms, not writing CloudFormation templates. In ten years, the people making infrastructure decisions won’t have AWS muscle memory. Provisioning a production workload on AWS often requires reasoning across IAM, networking, security groups, load balancers, logging, and service-specific configuration. On higher abstraction platforms, the same workload collapses into a single deploy primitive.
AI is turning complexity into a strategic liability. AI agents don’t struggle with complexity the way humans do. They struggle with branching factor, inconsistent abstractions, and massive control plane surface area. AWS maximizes all three: 200+ services with non-uniform APIs, verbose CloudFormation templates, and IAM policies that require reasoning across trust boundaries. When infrastructure becomes AI-mediated, the provider with the cleanest, shortest control plane becomes the default target. AI won’t optimize for “most powerful.” It optimizes for “most legible.” AWS was optimized for power and flexibility, not legibility.
Foundational architecture cannot be reset without revenue trauma. Amazon can’t rip out IAM without breaking every existing customer’s infrastructure, so every new service bolts onto legacy IAM, legacy VPC networking, legacy everything. Attempts to paper over this, App Runner, Amplify, Lightsail, Copilot, ECS Service Connect, break the moment you hit an edge case. AWS can attempt to climb the abstraction ladder from the existing platform. But these layers can never fully hide the control plane underneath because they must remain compatible with it. Every exception, every edge case, every compliance requirement punches through the abstraction and exposes the legacy primitives. This isn’t a quality problem. It’s a structural one. Clean abstractions require clean foundations, and AWS’s foundation is twenty years of accumulated backwards compatibility.
These four forces converge into a squeeze no single initiative can address. Regulatory pressure removes the financial lock-in. Abstraction layers remove the interface lock-in. AI removes the expertise lock-in. Architectural debt prevents AWS from responding without destabilizing the $129 billion revenue engine.
The Old Navy Model
The cannibalization that Amazon fears is already happening. They’re just not participating in it. Every startup on an abstraction platform is a customer relationship Amazon doesn’t own. Every developer who learns on Render is one more person who’ll default to something other than AWS when they become an engineering director. The real choice isn’t “cannibalize or don’t.” It’s self-cannibalize with margin control, or be cannibalized with margin collapse.
In 1994, Gap Inc. launched Old Navy as a completely separate entity. Different stores, different teams, different price points, all sitting on Gap’s supply chain. Old Navy didn’t just target different customers. It targeted a different decision calculus.
Amazon needs to do the same thing with cloud. Call it Ziroh. Zero configuration, zero friction, zero legacy. Amazon’s second cloud. Not cheaper AWS, but a different category of cloud.
Ziroh is not just simplicity. Ziroh is Amazon attempting to re-own the deployment surface before abstraction eats them. It would be organizationally radioactive: fractured incentives, eroded internal power structures, channel conflict with AWS sales orgs, and revenue displacement Wall Street would initially punish. That’s the cost. The alternative is someone else owning the interface permanently.
What Ziroh Actually Looks Like
Ziroh is a completely independent cloud provider. Separate brand, separate engineering team, separate culture. It piggybacks on Amazon’s physical infrastructure but inherits zero architectural debt from AWS.
The details matter less than the constraint: Ziroh must be simple enough that an AI agent can provision a production workload without human intervention, and opinionated enough that there’s no configuration surface to reason about. Identity-scoped networking, not user-managed graphs. Declared intent, not security group rules. Deployment in seconds, not YAML files.
Ziroh would deliberately remove whole categories of configuration surface. No user-managed networking graphs. No cross-service IAM policy authoring. No public load balancer primitives. If a workload cannot fit within the opinionated model, it does not belong on Ziroh. That’s the point. These are engineering decisions, not breakthroughs. Amazon has the talent. The constraint is backwards compatibility, which is exactly why Ziroh can’t be built inside AWS.
The One-Way Door
One rule makes or breaks this, and it is non-negotiable: Old Navy is allowed to steal from Gap, but never the other way around.
Ziroh cannibalizes down. AWS Classic never gets to reach down and pull Ziroh back into its orbit. No “integration” initiatives. No shared IAM layer for “consistency.” The moment the legacy organization touches Ziroh, the architectural debt infects it.
This runs against every instinct of a large organization. Product managers want synergies. Engineering directors want to reduce duplication. VPs want portfolio collaboration. Every one of these impulses will kill Ziroh.
Gap learned this the hard way. When Old Navy outperformed, Gap blurred the lines. Share designers, align aesthetics, create “brand coherence.” It diluted both. Separation is the architecture. The wall is load-bearing.
Why Amazon Won’t Do This
No executive will stand on an earnings call and tell Wall Street the $129 billion business needs a parallel replacement. Amazon has every tool it needs to succeed. The cash machine prevents them from using any of it.
Bezos stepped back to Executive Chair in 2021. Jassy became CEO of Amazon. Garman took over AWS in 2024. None of them have incentive to torch short-term margins for long-term structural advantage. That’s a founder’s move, and the founder is busy with Blue Origin.
Ziroh would require new thinking, new teams, and new willingness to let a second brand compete for the same developers. That’s a thought leadership investment, and it’s harder to justify on an earnings call than concrete and silicon. AWS is Amazon’s profit engine. Proposing an independent competitor from within is a career-jeopardizing move, even if it’s the right strategic decision.
The Signal
Watch the money. Capital is flowing toward abstraction platforms. Investors are betting that abstraction, not raw cloud primitives, defines the next era of infrastructure.
Watch Microsoft and Google. If they start acquiring or building opinionated deployment platforms instead of competing on the same 200-service complexity model, it means the hyperscalers themselves have accepted that the interface layer has migrated. AWS would be the last to admit it.
Watch the AI agents. Ask an AI agent to deploy a containerized application and higher-abstraction platforms frequently appear before raw AWS primitives. The default is already shifting.
Split or Be Split
AWS must split its identity before the market splits it for them.
If they refuse, Classic calcifies. Microclouds win developers. AI commoditizes compute. AWS becomes legacy infrastructure with compressing margins. Not death. Maturity.
But maturity without reinvention becomes irrelevance over time. Most executives are rewarded for preserving margin, not redefining eras. The evolutionary move is both strategically correct and culturally improbable.
That tension, between knowing what needs to happen and being structurally incapable of doing it, is the real story. By the time the pain is undeniable, the playbook is always the same: a late-cycle acquisition after the mindshare has already moved on, integrated into the existing platform for “synergies,” and the thing that made it attractive dies on contact with the legacy architecture.
Amazon must decide whether it wants to define the next decade the way it defined the last, or live the tech stalwart life of IBM and Oracle. History says it won’t be able to do both.
boring (adj.): infrastructure so opinionated it deploys itself, so stable it disappears, and so simple that an AI agent never needs to ask a follow-up question.