Choosing a Cloud for AI Development

Start with the workload, not the logo

"Which cloud is best for AI" has no answer, because the question skips the only variable that matters. A team calling a hosted model a few thousand times a day and a team fine tuning open weight models on multi node clusters need almost nothing in common from a provider.

So before comparing anything, write down four things: what you are actually building, whether you will train or only serve, where your data already lives, and how much operational work your team wants to own.

Those four answers eliminate most of the market immediately. What follows is a way to read the remainder.

Three paths, three different shopping lists

Almost every AI project sits on one of three routes, and each one values completely different provider attributes.

Call a managed model API. You send text and receive text. There is no infrastructure. What matters is the model catalog, regional availability, quota generosity and whether the surrounding governance satisfies your compliance people. Most products belong here and stay here.

Use a managed machine learning platform. You bring data and models, the provider runs training jobs, registries, pipelines and endpoints. What matters is the depth of the platform and how well it integrates with where your data already sits.

Rent accelerators and run everything yourself. You get machines with GPUs and full responsibility for the stack. What matters is hardware availability, price per hour, network and storage performance, and how quickly you can actually get capacity.

Mixing routes is normal and often sensible. A product can call a managed API for general tasks while self hosting one specialized model, which spreads the operational burden rather than concentrating it.

What the three large platforms actually offer

All three cover all three routes. They differ in emphasis, in the shape of their tooling and in what they assume you already have.

AWS has the broadest accelerated instance catalog, its own training and inference silicon, and the deepest surrounding infrastructure. Its managed model layer is described in the Amazon Bedrock overview, and SageMaker covers the platform route. The breadth is real and so is the learning curve.

Azure is the natural choice where the organization already runs on Microsoft identity and tooling, because Entra ID, policy and networking carry over without new concepts. Its model service and the deployment and quota model it uses are covered in the Azure OpenAI Service overview.

Google Cloud integrates most tightly with its own data stack, so teams whose data already lives in BigQuery find the shortest path here. The platform route is unusually complete, as set out in the Vertex AI overview, and it is the only one of the three offering a custom training accelerator to general customers.

A blunt observation: for the managed API route, the differences between the three are smaller than the differences between where your data and identity already live. Existing gravity usually decides this correctly.

Where the smaller providers fit

Developer focused clouds do not compete on platform breadth, and for the third route they do not need to. What they offer is a short list of accelerator plans, hourly billing, and a console you can understand in an afternoon.

Vultr offers dedicated and fractional GPU plans across its locations. Scaleway offers GPU instances aimed at both training and inference within a European footprint. OVHcloud provides GPU instances alongside managed AI services, also with a European base. Oracle Cloud sits between the categories, offering bare metal GPU shapes with cluster networking and a distinctly different commercial posture from the other large platforms.

The trade off is honest. You give up the managed platform layer, the enormous service catalog and the deep compliance portfolio. You gain simplicity, and often a clearer relationship between what you rent and what you pay. The general shape of this choice is covered in hyperscalers versus developer clouds.

These are also a reasonable place to start experimenting, because a single accelerator on an hourly plan is a small commitment. A Vultr account or a Scaleway account gets you to a running machine quickly, and the OVHcloud and Scaleway comparison is useful if the European footprint is what you are weighing.

The criteria that actually separate providers

Once the route is chosen, these are the questions that produce different answers from different providers. Marketing material rarely addresses them directly.

Region and quota deserve particular attention because they are the two that block people at the worst moment. Both are covered in vCPU limits and service quotas, and both should be verified before a design is finalized rather than after.

Keeping the door open

Every route above creates some attachment to a provider, and the amount varies enormously. Raw accelerator rental is the most portable position available: a container that runs on one provider's GPU machine runs on another's with little change.

Managed platforms bind harder, because pipelines, registries and feature stores are provider specific by design. Managed model APIs sit in between; the concepts transfer, but the request formats, tuning artifacts and safety configuration do not.

A few practices keep the cost of moving reasonable. Keep prompts, evaluation sets and retrieval logic in your own repository rather than only in a provider console. Put a thin interface between your application and whichever model API it calls. Store embeddings and source documents somewhere you control, so a change of vector store is a reload rather than a rebuild, as discussed in vector databases in the cloud.

None of that means avoiding useful managed services. It means knowing which parts would be painful to move, and choosing those deliberately. The wider argument is in cloud vendor lock-in.

A sequence that avoids expensive mistakes

1. Prototype against a managed model API. It is the fastest way to discover whether the product idea works at all, and it costs nothing in infrastructure.
2. Measure real usage for a few weeks. Volume, prompt length, traffic shape and latency tolerance are all unknowable in advance and all decide what comes next.
3. Only then consider self hosting, and only if the measurements support it. Compare against your actual traffic pattern using the method in the cost of AI workloads in the cloud.
4. Request quota in the specific region you intend to use, well before you need it.
5. Separate experimentation from production into different accounts or projects, so neither can consume the other's capacity.

Whichever provider the measurements point to, the starting point is an account with the services enabled. The widest catalog comes with an AWS account, and the AWS and Google Cloud comparison covers the two platforms most often shortlisted for this work. For hardware availability, the GPU platforms documentation and the EC2 accelerated computing guide are the references to check before committing to a region.

Key takeaways

• Identify your route first: managed model API, managed platform, or raw accelerators. Each values different provider attributes.
• For the managed API route, where your data and identity already live usually decides correctly.
• Developer clouds are a strong fit for straightforward accelerator rental and a poor fit for platform breadth.
• Regional availability and starting quotas block more projects than pricing does.
• Prototype on a managed API, measure, and only then decide whether to own the infrastructure.