Cloud computing has stopped being an option and become the default infrastructure layer for any organisation that needs to scale without tying up capital in hardware. The reference definition is still the one from NIST (Special Publication 800-145): a model that provides on-demand network access to a shared pool of configurable computing resources (servers, storage, networks, applications) that are provisioned and released with minimal provider involvement. The three major public clouds (Amazon Web Services, Microsoft Azure and Google Cloud Platform) account for most of the global market, but choosing between them (or combining them) requires understanding what each service layer solves and where the real risks lie.
Service models: IaaS, PaaS and SaaS
The classic NIST taxonomy distinguishes three models according to who manages what. In IaaS (infrastructure as a service) the provider delivers virtualised compute, network and storage, and the customer manages the operating system and everything above it: EC2 instances on AWS, Virtual Machines on Azure or Compute Engine on GCP. In PaaS (platform as a service) the provider also abstracts away the operating system and the runtime: AWS Elastic Beanstalk, Azure App Service or Google App Engine let you deploy code without administering the machine. In SaaS (software as a service) you consume the complete application by subscription, such as Microsoft 365 or Google Workspace.
The choice of model determines the boundary of the shared responsibility model, a concept that all three clouds document explicitly and that is the number-one source of security incidents: the provider is responsible for the security of the cloud (hypervisor, hardware, physical network), but the customer is responsible for security in the cloud (IAM configuration, data encryption, OS patching in IaaS, firewall rules). Assuming that the provider protects what is in fact the customer's responsibility is the origin of most data leaks from misconfigured S3 buckets or Azure blobs.
Practical comparison: AWS vs Azure vs Google Cloud
The three platforms cover the same basic needs, but their strengths differ. This table summarises the service equivalences and the selection criteria that matter most in real projects.
| Service / Criterion | AWS | Microsoft Azure | Google Cloud |
|---|---|---|---|
| Virtual compute (IaaS) | EC2 | Virtual Machines | Compute Engine |
| Managed containers (Kubernetes) | EKS | AKS | GKE |
| Serverless functions | Lambda | Functions | Cloud Functions / Cloud Run |
| Object storage | S3 | Blob Storage | Cloud Storage |
| Managed relational database | RDS / Aurora | Azure SQL Database | Cloud SQL / AlloyDB |
| Typical strength | Breadth of catalogue and maturity | Integration with the Microsoft ecosystem and hybrid environments | Data analytics and AI (BigQuery, Vertex AI) |
In practice, a company with a heavy investment in Active Directory and Microsoft licences usually finds less friction with Azure; a data team that lives on large-scale analytics tends to value GCP's BigQuery; and AWS remains the safe bet for breadth and regional availability. Price is rarely the deciding factor: all three apply a pay-as-you-go model with commitment-based discounts (Savings Plans on AWS, Reserved Instances on Azure, Committed Use Discounts on GCP) that can cut the bill by between 30% and 70% compared with the on-demand rate.
Migration strategies: the 6 Rs
Migrating to the cloud is not a single act but a portfolio of decisions made application by application. The 6 Rs framework (popularised by Gartner and AWS) sets out the options: Rehosting (lift and shift, moving the machine as is), Replatforming (small adjustments, for example moving a database to a managed service), Repurchasing (replacing it with an equivalent SaaS), Refactoring (redesigning the application as cloud-native), Retain (keeping on-premises whatever is not worth moving) and Retire (shutting down what no longer adds value). The common mistake is mass rehosting in the hope of immediate savings: moving an inefficient architecture to the cloud usually makes it more expensive, because you pay for under-used resources around the clock.
An orderly migration starts with an inventory of dependencies, defines a landing zone with accounts/subscriptions segregated by environment (production, pre-production, sandbox), establishes cost-tagging policies from day one, and prioritises by business value and technical risk. Spend governance (FinOps) should be built into the project from the outset, not bolted on when the first surprise bill arrives.
Infrastructure as code and cloud-native architectures
The difference between a cheap cloud and an expensive one lies not in the provider but in operational discipline. Infrastructure as code (IaC) with Terraform (multi-cloud), AWS CloudFormation, Azure Bicep or Google Cloud Deployment Manager turns infrastructure into versioned, reviewable and reproducible files: it eliminates irreproducible manual configuration (the so-called snowflake server) and enables identical deployment of environments. On that foundation you build cloud-native practices: containers orchestrated with Kubernetes, serverless functions for event-driven workloads, and decoupled architectures using queues and events that scale each component independently.
On the compliance front, all three clouds maintain ISO/IEC 27001 (information security management) and ISO/IEC 27017 (controls specific to cloud services) certifications, and offer tools to process personal data in line with the GDPR, including the choice of a European region to guarantee data residency and the signing of data processing agreements. The provider's certification, however, does not exempt the customer from correctly configuring their own controls.
FinOps: governing cost as a discipline
The elasticity that makes the cloud attractive is also its biggest financial trap: the ease of provisioning resources turns spend into a variable that spirals out of control if no one watches it. The FinOps practice (cloud financial operations) addresses this challenge with a cultural and operational model based on three iterative phases. The inform phase provides visibility of spend through consistent resource tagging and cost dashboards by team, project and environment. The optimise phase applies concrete actions: right-sizing instances, shutting down test environments outside working hours, buying reserved capacity for stable workloads and taking advantage of spot instances for interruption-tolerant jobs. The operate phase establishes budgets, variance alerts and clear accountability for every euro consumed.
The key change in mindset is that in the cloud cost is an engineering metric, not just a finance one: a developer's decision to choose an instance type or a region has a direct impact on the bill. Mature organisations treat cost as one more software quality attribute, alongside performance and security, and review spend with the same cadence they use to review incidents.
Common mistakes that make the cloud expensive and exposed
- Orphaned resources: disks, elastic IPs and snapshots that no one releases and that are billed month after month.
- Oversizing instances: starting large machines "just in case" instead of measuring and applying auto-scaling.
- Overly broad IAM permissions: granting policies with a wildcard (
*) instead of applying the principle of least privilege. - Not encrypting by default: leaving object-storage buckets with public access or without encryption at rest.
- Forgetting disaster recovery: never testing the restoration of backups or defining RPO/RTO objectives.
Frequently asked questions
Multi-cloud or a single provider?
Multi-cloud reduces the risk of dependence on a single provider and lets you use the best of each platform, but it multiplies operational complexity, the skills required and the cost of transferring data between clouds. For most SMEs, a well-governed primary cloud delivers more than a poorly maintained multi-cloud.
Is the cloud always cheaper than running your own servers?
Not automatically. The cloud turns investment (CapEx) into operating expense (OpEx) and provides elasticity, but stable, predictable 24/7 workloads can end up more expensive in the cloud than reserving capacity or keeping them on-premises. The real saving comes from paying only for what you use and switching off what you do not need.
Where does my data reside and who can access it?
Data resides in the region the customer chooses; to comply with the GDPR it is advisable to select EU regions and sign the provider's data processing agreement. Encryption at rest and in transit, together with rigorous key and identity management, is the customer's responsibility.
What is vendor lock-in and how is it mitigated?
It is the difficulty of switching providers due to the use of proprietary services. It is mitigated by relying on open standards (containers, Kubernetes, portable data formats) and isolating business logic from each cloud's specific APIs, although giving up managed services entirely also carries an opportunity cost.
Conclusion
There is no "best" cloud in the abstract: there is the right cloud for a specific workload, a team with a given set of skills and a particular compliance framework. The relevant technical decision is not AWS versus Azure versus Google Cloud, but how the chosen platform is governed: with infrastructure as code that makes every environment reproducible, with least-privilege identities that close the door to leaks, with a FinOps practice that avoids the surprise bill, and with backups whose restoration is genuinely tested. The cloud rewards those who automate and measure, and penalises those who improvise. At Summum Systems we approach every migration as a portfolio of decisions made application by application (the 6 Rs), not as a mass relocation, because moving disorder to the cloud only produces more expensive disorder.