Hosting on AWS, Azure or Google Cloud: how we choose

By Marco Lopes · December 25, 2025 · Cloud & DevOps

Choosing a cloud provider can look like a feature comparison. In practice, we find it is a decision about constraints: what we are building, where the data belongs, who will operate it, and what happens when something breaks.

At Kordspace, we are a remote collaborative software, AI, Web3, hardware and design studio. Google Cloud is our preferred starting point, but we also work with AWS and Azure. That preference is not a rule that overrides a project's needs.

We want infrastructure that supports the product without becoming a second product to maintain. Here is how we approach that choice as we close out 2025.

Start with the workload, not the provider

Before comparing services, we write down the shape of the system. A marketing website, an AI-assisted business application, a blockchain indexer and a connected-device backend have different hosting requirements.

We ask about request patterns, background jobs, storage growth, latency, geographic reach and external dependencies. We also identify anything unusual: GPU workloads, persistent connections, device protocols, long-running processes or sensitive information.

Then we separate hard constraints from preferences. A contractual hosting region is a constraint. Familiarity with a dashboard is a preference. An existing identity platform may be either, depending on how deeply it is embedded.

This short discovery step often eliminates unsuitable architectures before we spend time comparing prices.

Why Google Cloud is our default

We tend to start with Google Cloud because its managed application, data and AI services fit many of the products we build. For a typical web application, Cloud Run, Cloud SQL, Cloud Storage and managed messaging can provide a straightforward foundation.

Cloud Run is especially useful when we want to deploy a container without managing a cluster. BigQuery is worth considering when analytical workloads need to stay separate from transactional databases. Vertex AI can support projects that benefit from managed model access and tooling.

We still check service-specific limits, regional availability and the billing model. Autoscaling does not remove database connection limits, and managed infrastructure does not make application architecture someone else's responsibility.

Our preference is really for a clear operating model. When Google Cloud provides that with fewer moving parts, we choose it.

When AWS is the better fit

AWS becomes a strong candidate when the organisation already operates there, the team has established AWS expertise, or the workload benefits from a particular service or ecosystem integration.

We might compare ECS with Fargate against a Kubernetes deployment, or use Lambda for event-driven work that fits its execution model. S3 and managed database services are common building blocks; specialised requirements determine the rest.

The breadth of AWS can be valuable, but it also creates choices that need discipline. We avoid assembling a long list of services simply because each one solves a small piece elegantly.

If existing accounts, networking, security controls and operational knowledge already work well, moving away needs a clear business justification. Provider preference alone is not enough.

When Azure is the better fit

Azure often deserves the first serious look when an organisation relies on Microsoft identity, enterprise agreements and established Azure governance. Integrating with Microsoft Entra ID and existing operational processes can matter more than small differences in compute pricing.

For application hosting, we consider services such as Azure App Service, Azure Container Apps and Azure Kubernetes Service according to the workload and the team's capacity to operate it.

We also check how the project fits existing network boundaries, procurement processes and data policies. An isolated technical comparison can miss these organisational costs.

We do not assume that using Microsoft software automatically means Azure is best. We test whether those integrations create practical advantages for this particular system.

Choose the simplest hosting model that fits

Across all three providers, our usual question is whether a managed application platform can do the job. If it can, we need a reason to introduce more infrastructure.

Containers give us a consistent packaging format. They do not require Kubernetes. A small application with an API, scheduled tasks and a database may be easier to run on a managed container service.

Kubernetes makes sense when its orchestration capabilities solve real requirements and someone can own upgrades, access controls, networking and incident response. Virtual machines remain useful for specialised software, operating-system requirements or workloads that do not fit managed runtimes.

We choose the operating model before debating individual instance sizes. Reducing operational complexity is often the more durable saving.

Compare the whole bill

We build cost estimates around expected behaviour, not a single compute price. The model includes databases, storage, load balancing, observability, backups, support and network traffic.

Network charges deserve particular attention. Internet egress, traffic between regions, some cross-zone paths and managed network components can change the economics of an otherwise inexpensive design. We map the important data flows and check the relevant pricing rather than assuming internal traffic is free.

We estimate a quiet month, an expected month and a busy month. For AI products, we add model usage, retries and evaluation runs. For data-heavy products, we include retention and query patterns.

Budgets and alerts help us notice spending; they generally should not be treated as hard spending caps. Quotas, application limits and usage controls need separate attention.

We consider commitments only after usage is stable enough to justify them.

Let data location shape the architecture

Data is usually harder to move than application code. We therefore make database and storage decisions early, including where information enters the system, where it is processed and where copies are retained.

For many transactional applications, managed PostgreSQL is a sensible starting point. We still verify supported extensions, connection behaviour, upgrade options and recovery features. The same database engine does not guarantee identical managed-service capabilities.

We also distinguish residency from compliance. Selecting a region is only one part of meeting legal or contractual obligations; access, subprocessors, retention and support arrangements may also matter.

Where requirements are sensitive, we involve the appropriate legal or compliance specialists rather than presenting a hosting choice as a compliance certificate.

Design reliability around recovery

We start reliability planning with two questions: how much interruption can the product tolerate, and how much recent data could it afford to lose? Those answers guide availability, backups and disaster recovery.

Multi-zone deployment can address some infrastructure failures. It does not protect against every bad deployment, deleted record or compromised credential. Backups need suitable isolation, retention and tested restoration procedures.

We define health checks, actionable alerts and a rollback path. We also document dependencies whose failure could stop the product even while its own servers remain healthy.

Multi-region architecture is appropriate when recovery requirements justify its complexity. We do not add it as a badge of seriousness. A simpler system with tested recovery may serve a project better than an elaborate system nobody can confidently restore.

Make security part of the delivery path

We establish separate environments, least-privilege access and managed secrets before production becomes busy. Human access should use strong authentication, while automated deployments should avoid long-lived credentials wherever practical.

For a remote collaborative studio, clear access boundaries matter. We want contributors to have the permissions they need without sharing accounts or passing secrets through chat.

Infrastructure changes should be reviewable. We use infrastructure as code where appropriate, retain useful audit records and make ownership explicit. Logging must also avoid leaking tokens, personal information or confidential prompts.

Cloud providers secure parts of the platform; we remain responsible for our application's configuration, dependencies and data handling. Managed services change that responsibility boundary rather than removing it.

Account for AI, Web3 and hardware workloads

AI hosting starts with the inference pattern. We compare managed model APIs with self-hosted models based on quality, latency, privacy requirements and expected utilisation. GPU availability and quota must be checked in the intended region, not inferred from a product page.

For Web3 systems, we separate application hosting from blockchain access. Running a node, maintaining an indexer and calling a managed RPC endpoint have different storage, recovery and operational needs. Signing keys require controls beyond ordinary application configuration.

Hardware-connected systems introduce another set of questions: device identity, intermittent connectivity, ingestion protocols and safe update delivery. We plan for retries and duplicate messages rather than assuming a reliable connection.

These workloads may change our provider choice, but they do not excuse unnecessary complexity. We isolate specialised components so the rest of the product can remain straightforward.

Build a delivery process the team can use

A hosting decision is incomplete without a deployment workflow. We want automated builds, relevant tests, dependency checks and a controlled route from development to production.

Preview environments can help design and engineering collaborate remotely, provided they have sensible access controls and cleanup rules. Staging should reproduce the behaviours that matter without automatically duplicating every production expense.

We also agree on release ownership, database migration procedures and incident communication. A rollback button is not enough if a schema change has made the previous application version incompatible.

The best platform is one the team can operate confidently. Documentation, useful dashboards and short runbooks are part of the infrastructure, not optional handover extras.

Keep an exit path without building three clouds

We favour portability where it is inexpensive and useful: standard containers, clear service interfaces, exportable data and documented infrastructure. We also record where a managed service creates a provider-specific dependency.

That does not mean avoiding every proprietary feature. A managed service can save substantial engineering effort. We weigh that benefit against migration difficulty and the importance of the affected component.

For most projects, we would rather operate one cloud well than spread a small system across three. Multi-cloud needs a concrete justification, such as contractual requirements or a specific resilience strategy.

An exit plan starts with data export and a credible migration sequence, not identical deployments everywhere.

Our short cloud-selection checklist

Before we commit, we check:

• Workload: Does the hosting model fit runtime, scaling and connection needs?
• Data: Are region, retention, backup and export requirements covered?
• Cost: Have we included networking, observability and operational effort?
• Security: Are identity, secrets and environment boundaries defined?
• Recovery: Can we restore data and recover within agreed limits?
• Ownership: Does the team know how to deploy, monitor and respond?

We capture the decision and its assumptions in a short architecture record. If those assumptions change, we revisit the choice rather than defending it out of habit.

Choose for the product you need to run

Our default may be Google Cloud, but our recommendation follows the workload, the organisation and the people responsible for operating it. AWS or Azure can be the stronger choice when their capabilities or existing foundations reduce risk and effort.

If you are choosing a hosting platform, planning a migration or simplifying an existing setup, we would be glad to work through the trade-offs together. Start a project, or explore our related services pages to see how we can support your software, AI and Cloud & DevOps work.