I Wouldn’t Build AWS in 2027: How I Would Enter the Compute Business from One Server

If I were starting a compute business in 2027, I would not try to build a smaller AWS.

I would start with the smallest useful abstraction I could actually sell, learn what customers pay for, and then move upward through the stack only when demand justified the next layer.

The core idea is simple:

the physical computer is inventory; the product is the abstraction sold above it.

That changes how I would think about infrastructure, software, pricing, and marketing from day one.

For a long time, compute businesses were easy to categorize.

A hosting company sold hosting. A colocation provider sold rack space, power, and connectivity. A cloud provider sold virtual machines. A company with specialized requirements bought or leased its own servers.

Those categories still exist, but modern data centers increasingly contain many different economic models behind similar racks: enterprise systems, cloud capacity, storage, CDN nodes, bare metal, HPC, GPU clusters, training infrastructure, and inference.

The more important change is that one physical server can now support several different commercial products.

A four-GPU server can be sold as:

The hardware can stay exactly the same while the customer, margin structure, software layer, and marketing proposition all change.

I increasingly think about compute as a ladder.

At the bottom is space and power.

Above that is the physical server.

Then virtual compute.

Then accelerated compute.

Then managed infrastructure.

Then inference.

And eventually the business outcome itself.

Every step upward hides more infrastructure from the customer.

A colocation customer may care about rack dimensions, kilowatts, cross-connects, power feeds, and carrier access.

A bare-metal customer cares about CPU, memory, storage, and networking.

A GPU-cloud customer cares about accelerator type, VRAM, throughput, and GPU-hours.

An inference customer may care primarily about model availability, tokens per second, latency, reliability, and price.

A business customer may care about none of those details.

The business customer may simply ask:

At that point, the exact GPU model becomes an implementation detail.

That is not only a technical transition. It is a marketing transition.

A new provider that launches with this message:

immediately faces a difficult question:

For a small new provider, trying to compete horizontally against hyperscalers is a weak starting position.

They already have global regions, mature APIs, huge capacity, established billing systems, identity platforms, managed databases, observability stacks, and hundreds of services.

But there is another strategy.

Do not compete horizontally.

Compete vertically.

Instead of saying:

say:

Or:

Or:

Or:

Now the customer does not need to ask whether you are better than AWS at everything.

The customer only needs to ask:

That is a much more realistic competitive surface for a small provider.

This is one reason the rise of neoclouds matters.

The important lesson is not simply that demand for GPUs became enormous. The deeper lesson is that specialized compute can compete with generalized cloud.

Neocloud providers concentrated on workloads where specialization matters: accelerators, high-speed networking, large clusters, AI training, inference, scheduling, and AI-native operations.

Synergy Research Group reported that neocloud revenue exceeded $25 billion in 2025 and forecast that the market could approach $400 billion by 2031.

Gartner’s August 2026 forecast projected AI-optimized IaaS spending at about $66 billion in 2027, up 56.5% year over year. It also projected inference to represent 59% of AI-optimized IaaS spending in 2027.

These numbers do not mean every new provider should become a neocloud.

They mean the market has already demonstrated that a specialized infrastructure proposition can become large enough to stand on its own.

Owning GPUs is not a durable differentiator by itself.

Hardware ages. New accelerator generations appear. Supply changes. Prices compress. Customers become better at comparing providers.

Eventually, saying:

becomes similar to saying:

The durable value moves upward into:

That is why I would design the business to move upward from the beginning, even if the first product is extremely simple.

I would start as low as necessary.

If I had only one useful server, I would not wait until I had a full cloud platform.

I would sell the server.

The first product could simply be:

This is close to commodity infrastructure, but it has several advantages for an early-stage operator:

At this stage, the goal is not to build an infrastructure empire.

The goal is to discover whether somebody will pay.

Once demand exists, I would start hiding the physical server.

Instead of selling the entire machine, I could sell normalized products such as:

or:

Now the customer buys a SKU rather than a serial-numbered server.

This is where a scheduler, provisioning API, basic metering, and resource catalog begin to matter.

But I still would not build a giant commercial platform.

The compute control plane and usage ledger matter first. Complex CRM and billing can remain external or minimal until the business needs them.

The next step is more interesting.

Instead of giving the customer a GPU and asking them to install everything themselves, I would operate the inference runtime.

The product changes from:

to:

The provider handles CUDA, drivers, containers, model runtimes, health checks, monitoring, and updates.

The customer sees something like:

The same physical GPU can now generate revenue at a higher abstraction layer.

At this point, usage can be measured in requests, tokens, reserved throughput, or dedicated capacity rather than only GPU-hours.

The next product is not a shared endpoint but a dedicated environment.

For example:

Now the offer can include:

This changes the buyer again.

A developer may buy hourly GPU access.

A business may buy predictable private capacity.

Eventually I would stop selling inference as the main story.

The product can become:

The customer no longer needs to know how many containers are running or which inference engine is deployed.

The package can include:

At this level, the business is selling controlled AI capability rather than raw infrastructure.

The final step is to hide almost all of the infrastructure.

Instead of:

the product becomes:

Or:

Or:

The compute remains underneath everything, but it is no longer the marketing object.

It becomes production capacity.

That is the direction in which I would want the architecture to evolve.

This is what makes the ladder attractive to me.

A single server can start life as:

Later the same type of capacity can become:

Then:

Then:

Then:

The physical asset continues producing value while the abstraction above it improves.

This makes the entry path less risky.

I do not need to predict the final business model before buying the first machine.

I can build the next layer only after the previous layer demonstrates demand.

Training created the first massive wave of AI infrastructure demand, but inference has a different economic character.

Training is often episodic.

Inference is continuous.

Every AI search, agent action, copilot interaction, generated document, voice request, recommendation, vision request, and automated workflow creates inference demand.

Gartner now expects inference-focused spending to surpass training-focused spending in AI-optimized IaaS and continue increasing its share through 2027.

JLL’s 2026 data-center outlook makes a related point: inference demand is expected to become geographically distributed because latency and user proximity matter more for serving applications than for many training workloads.

For a small provider, that matters.

Participating in AI infrastructure does not necessarily require building a frontier-model training cluster.

A useful entry point can be much smaller.

Cloud computing made infrastructure feel geographically abstract.

AI may partially reverse that.

Latency matters. Data locality matters. Privacy matters. Support matters. Network proximity matters. Regulation can matter.

That creates room for propositions such as:

or:

This is not an attempt to reproduce an AWS region.

It is specialization plus geography.

A regional provider does not need to beat AWS globally.

It needs to solve a narrow problem better for a particular group of customers.

This is the principle I would carry into the architecture.

Inside the infrastructure I may eventually have:

Customers should not need to understand that inventory.

They should see normalized products:

The underlying hardware can evolve without forcing the commercial model to be rebuilt every time a server is replaced.

I would not start with generic VPS hosting.

I would not try to build another AWS.

I would not treat raw GPU rental as the final destination either.

I would move roughly like this:

The starting point would depend on what I actually had.

One server? Sell the server.

Several GPUs? Expose GPU capacity.

Stable model serving? Sell an endpoint.

A company asking for privacy and predictable capacity? Build a dedicated environment.

The next layer should appear because the previous layer has customers, not because an architecture diagram says it should exist.

The last fifteen years of cloud computing were largely about turning physical servers into infrastructure services.

The next phase may increasingly be about turning infrastructure services into intelligence services.

That changes the question for a new compute business.

The question is not:

It is:

That is the compute business I would start building in 2027.

And I would start from the minimum viable layer, then move upward only as real demand justified it.