Cloud Service Providers
AWS, Azure or Google Cloud? Compare providers against your systems and compliance needs. Talk to our team.
Quick answer: Choosing a cloud provider should follow workload fit, existing tooling and Privacy Act data-residency obligations, not a feature comparison between AWS, Azure and Google Cloud.
- Cloud Engineering
- Platform Engineering
- Application Modernisation
- System Integration
Quick answer
Which cloud service provider should a growing Australian business choose?
The right provider depends on existing tooling, integration needs and data-residency obligations, not published compute pricing. AWS, Azure and Google Cloud suit different existing stacks.
Additional Context
Commodity compute and storage are similar across the big three hyperscalers; the decision that matters is workload fit, licensing overlap and compliance obligations under the Privacy Act.
Sources
- OAIC - Australian Privacy Principles guidelines, APP 8 (cross-border disclosure)
Sets out when disclosing personal information to an overseas recipient, including via cloud storage, triggers obligations under Australian Privacy Principle 8.
- Australian Cyber Security Centre - Cloud Computing Security Guidance
Describes the shared responsibility model between cloud providers and tenants for securing cloud-hosted systems.
Provider Selection
What Actually Differs Between AWS, Azure and Google Cloud
At the compute and storage layer, AWS, Microsoft Azure and Google Cloud are close to interchangeable. Virtual machines, object storage and managed databases from any of the three will run a typical mid-sized business's workloads without a meaningful performance gap. The differentiation that actually matters sits one layer up: depth of managed services, how well a provider's identity and licensing model matches what the business already runs, and where data physically sits.
A business already standardised on Microsoft 365 and Azure Active Directory carries a genuine integration advantage toward Azure that a feature-by-feature comparison won't surface. A business built on open-source tooling and Kubernetes has less reason to prefer any one hyperscaler and more reason to weight support quality and hybrid cloud integration capability instead. Neither is a wrong starting point, but choosing before mapping what's already in place usually means re-litigating the decision within a year.
The Decision That Usually Matters More Than the Provider
Teams shortlisting a hyperscaler off a migration assessment supplied by that provider's own partner network often receive an architecture that assumes a clean, greenfield build. The actual constraint is rarely the provider itself - it's three or four internal systems held together by manual CSV exports and a handful of scheduled scripts nobody has documented. Fixing that cloud infrastructure operations layer changes the shape of the migration far more than which provider's logo sits on the invoice.
The practical approach is to map dependencies and data flows first, using that map to test each shortlisted provider against real workloads rather than a slide deck of comparable services.
Provider Selection
Cloud Provider Selection Without a Costly Re-Platform
Problem
Businesses shortlist AWS, Azure and Google Cloud on feature lists and pricing calculators, then discover the real constraints - data residency, egress cost and integration with systems already in place - only after migration is underway.
Common Pain Points:
- Feature-list paralysis Comparing AWS, Azure and Google Cloud on checklists that are now functionally equivalent for most commodity workloads.
- Unplanned egress costs Data transfer and managed-service tiers that don't show up until several invoice cycles after migration.
- Compliance blind spots Data residency and cross-border disclosure obligations overlooked until a customer or regulator asks where data is stored.
- Lock-in via managed services Provider-specific managed services adopted for convenience that make a future provider change disproportionately costly.
Business Impact:
Time Wasted: Weeks spent comparing feature lists that are functionally near-identical across the major providers
Cost Implication: Cost surprises concentrated in data egress and managed-service tiers rather than in the headline compute pricing compared at selection time
Opportunity Cost: Time spent on provider comparison instead of building the integration layer between systems already in use
Solution
A structured evaluation of workload fit, existing tooling, compliance obligations and integration needs, followed by a pilot migration on one workload before any platform-wide commitment.
Our Approach:
- Workload and Dependency Mapping(Typically 1-2 weeks)
Cataloguing which systems, APIs and data flows an existing platform depends on before any provider is shortlisted.
- Provider Fit and Compliance Review(Typically 2-3 weeks)
Assessing data residency, shared-responsibility obligations under the Privacy Act, and existing licensing such as Microsoft 365 tenancy against each shortlisted provider.
- Pilot Migration on a Single Workload(Typically 4-8 weeks)
Moving one well-understood workload first to surface real integration gaps and cost patterns before committing the wider estate.
Expected Outcome: A provider decision grounded in actual workload and integration needs, tested through a pilot migration before wider commitment.
Key Takeaways
What Matters More Than Which Hyperscaler You Pick
- Commodity compute and storage are now near-identical across AWS, Azure and Google CloudImportant
Differentiation has shifted to managed-service depth, existing tooling relationships and support model, not raw infrastructure pricing.
- Existing tooling often decides the shortlist before features doImportant
A business already running Microsoft 365 and Azure AD carries integration and licensing advantages toward Azure that a feature comparison won't capture.
- Data residency and the Privacy Act shape provider and region choiceCritical
Cross-border disclosure of personal information under Australian Privacy Principle 8 turns provider region selection into a compliance decision as much as a technical one.
- Egress and managed-service charges are the real cost riskImportant
Headline compute pricing rarely reflects total cost; data transfer and managed database or analytics tiers scale with usage and are easy to underestimate at selection time.
- A pilot migration beats a platform-wide commitment on day oneImportant
Moving one workload first surfaces integration gaps and cost patterns before the business is contractually and architecturally locked into a single provider.
Provider choice hinges on workload fit, compliance obligations and the integration layer connecting existing systems; feature lists matter far less than that groundwork.
Cloud Provider Selection: What the Compliance Guidance Says
Choosing where workloads and data sit is as much a compliance decision as a technical one for Australian businesses handling personal information, particularly once data crosses into an overseas cloud region.
APP 8
Cross-border disclosure
Significance: highStoring personal information with an overseas cloud region can trigger Australian Privacy Principle 8 obligations on cross-border disclosure, regardless of provider size.
Source: OAIC, Australian Privacy Principles quick reference
Tenant retains security duties
Shared responsibility model
Significance: highCloud providers secure the underlying infrastructure, but configuration, identity and data protection inside the tenancy remain the customer's responsibility.
Source: Australian Cyber Security Centre - Cloud Computing Security Guidance
Applies to cloud-hosted systems
Essential Eight scope
Significance: mediumThe Essential Eight mitigation strategies extend to cloud-hosted workloads, meaning patching, MFA and backup controls must be configured by the tenant, not assumed from the provider.
Source: Australian Cyber Security Centre - Essential Eight Maturity Model
Methodology
Drawn from published Australian privacy and cyber security guidance on cloud data handling and shared responsibility, not vendor marketing claims about any specific provider.
Migration Approach
Matching Provider Strengths to What's Already Running
Cost predictability is the criterion most consistently underestimated at selection time. Headline compute and storage pricing looks similar across providers; the divergence shows up later, in data egress charges and in managed database or analytics tiers that scale with usage rather than with the instance size originally quoted. A provider decision made purely on a pricing calculator, without modelling the data that will actually move in and out of the environment, tends to produce a second, unplanned conversation about cost around the third or fourth invoice cycle.
Not every workload needs to move at all. Some public-facing or low-change systems are better served by a lighter approach than a full cloud application stack - the zero dependency build behind National Digital's FreeCamps project is one example of matching infrastructure to what a workload actually needs.
A Staged Path From Provider Choice to Working Migration
Where systems genuinely need cloud migration strategy work, the more reliable sequence starts with one workload before extending to the rest of the estate. Migrating a single, well-understood system first surfaces integration gaps, licensing surprises and real cost patterns while the blast radius of getting something wrong is still small. That pilot then informs whether the remaining estate follows the same provider, a different one, or a mixed approach, and whether legacy components need staged modernisation before they're worth moving at all.
Businesses handling personal information should treat data residency as part of the provider decision, resolved before migration rather than after. Storing data in an overseas region can trigger obligations under Australian Privacy Principle 8, and that's a compliance question a feature comparison will never answer.
Cloud Service Provider Questions, Answered Plainly
What's the real difference between AWS, Azure and Google Cloud for a business this size?
Commodity compute and storage are close to identical across the three. The differences that matter are managed-service depth, how well identity and licensing align with tools already in use - Microsoft 365 and Azure Active Directory point toward Azure, for example - and where each provider's regions sit against your data residency obligations.
Is cloud computing the same thing as cloud engineering?
No. Cloud computing describes consuming infrastructure or software as a service: storage, compute, SaaS applications. Cloud engineering is the discipline of designing, building and operating the systems that run on that infrastructure, including architecture, automation, security configuration and the integration layer connecting it to existing business systems.
How does cloud engineering differ from DevOps?
DevOps is a set of practices for shipping software changes reliably and often, spanning development and operations. Cloud engineering is the underlying discipline of designing and running the cloud infrastructure those practices operate on. In most growing businesses the two overlap heavily, with the same small team covering both.
Does the choice of cloud provider affect Privacy Act compliance?
It can. Where personal information is stored or processed in an overseas region, Australian Privacy Principle 8 imposes obligations on the business disclosing that data, regardless of which provider or region was chosen. Provider and region selection should be checked against these obligations before a migration goes ahead, not after.
Should a business already running Microsoft 365 automatically choose Azure?
It's a strong starting point in most cases: existing Azure Active Directory identities, licensing bundles and Microsoft tooling reduce integration work specifically on Azure. But if the actual workloads are open-source, container-based, or already running well elsewhere, that licensing advantage may not outweigh the cost of moving everything to match it.
What's the most common mistake businesses make when choosing a cloud provider?
Comparing providers on published pricing and feature lists before mapping what already exists: the systems, integrations and data flows a migration has to accommodate. That comparison is usually inconclusive, since the big three are functionally similar at that level, and the real cost and complexity surface later, in egress charges and unplanned integration work.
