AWS vs Azure vs Google Cloud for AI in Australia

Hyperscaler choice in 2026 is not a feature comparison

If you start a hyperscaler-for-AI evaluation by listing features, you will reach the wrong shortlist. AWS Bedrock, Azure AI Foundry, and Google Vertex AI all publish broadly similar capability matrices on their marketing sites: foundation models, agents, vector search, retrieval, fine-tuning, guardrails, evaluation, content safety. On a glossy slide, all three look comparable.

The shortlist for an Australian business shrinks fast once you check five things that the glossy slides skip:

1. Which services are actually available in the Sydney or Melbourne region as of the date you sign
2. Which of those services are IRAP-assessed and at what level
3. Where prompts, completions, embeddings, and logs physically reside and travel
4. What your existing enterprise agreement actually discounts
5. Whether your data plane already lives in one of these three providers

That filter usually removes one provider from contention before you write a line of architecture. The point of this article is to give you a vendor-neutral framework so you reach that conclusion deliberately rather than by accident.

If you have not already chosen a model, our companion piece AI model selection for Australian business covers Claude, GPT, Gemini, Llama, and on-premise options. This piece assumes you have a working hypothesis on model and now need to choose where to host. If you are still framing the broader question, why DIY without understanding fails and the questions to ask any AI vendor are upstream of this decision.

Part 1: The five evaluation dimensions

These are the dimensions that decide a hyperscaler-for-AI shortlist for an Australian business in 2026. Feature parity is assumed; differentiation is in the items below.

Dimension 1: AU regional catalogue

A vendor service exists for your project only if it is generally available in the region where your data must reside. All three providers list "available in 30+ regions worldwide" for their flagship AI platforms. What decides your shortlist is which models, which features, and which integrations are live in Sydney or Melbourne specifically.

A common pattern across the three platforms in 2026: a foundation model is announced and made available in US regions first, then EU, then Asia-Pacific (Tokyo and Singapore), then Australia. Some models reach Australia within weeks. Some take quarters. Some never arrive. Verify against each provider's current region availability matrix as of your project kick-off.

Dimension 2: IRAP assessment scope

The Information Security Registered Assessors Program is administered by the Australian Signals Directorate. The published register at the ASD website lists which cloud services have been IRAP-assessed and at which security classification (OFFICIAL, OFFICIAL: Sensitive, PROTECTED).

In practice, each provider has had certain AI services assessed and certain ones not assessed. The set changes. A foundation model API may be assessed at OFFICIAL: Sensitive in one quarter and PROTECTED in the next, or the reverse. For a business not handling national security data, this only matters if you are pursuing a government contract or are a regulated entity. But if it matters, it usually decides the platform alone.

For the deeper compliance picture for federal work see AI compliance for government contracts.

Dimension 3: Data residency path

"Australia East" or "australia-southeast1" does not automatically mean every byte stays in Australia. The provider's data-handling documentation for each specific AI service describes exactly what is stored where, what is processed where, and what transits where (for telemetry, abuse monitoring, fine-tuning data, and so on).

We cover the architecture of this in detail in our data sovereignty in Australia guide. The short version: read the per-service data residency commitment, do not infer from the region name.

Dimension 4: Enterprise agreement leverage

A business already running on Microsoft 365 E5 has a different cost curve on Azure than one starting from scratch. AWS Enterprise Discount Programs, Microsoft Enterprise Agreements with Azure commitments, and Google Cloud committed-use discounts can move a multi-year TCO by twenty to forty percent. We see this often enough that we treat the existing EA as a primary input rather than a tiebreaker at the end.

Dimension 5: Stack fit

If your data warehouse is BigQuery, Vertex AI integration is a developer hour, not a sprint. If your collaboration platform is Microsoft 365 and you want to surface AI inside Outlook, Teams, and SharePoint, Microsoft has a path that the other two do not. If your operational stack is already on AWS, putting Bedrock next to your existing VPC and IAM is the lowest-friction option.

This dimension is the one most often underweighted. Engineering teams pick the platform with the most interesting models. Operations and finance later discover they are paying for cross-cloud egress and duplicate identity infrastructure. The production reality of operating agents covers what this looks like once you are in flight.

Part 2: AWS Bedrock and SageMaker in Australia

AWS operates the Asia Pacific (Sydney) region (ap-southeast-2) with three availability zones and Asia Pacific (Melbourne) (ap-southeast-4). For AI workloads, the relevant services are Amazon Bedrock (the foundation-model service), Amazon SageMaker (for custom ML), and the higher-level applied AI services (Q for Business, Q for Developer, Comprehend, Textract, Transcribe, Polly, Rekognition).

What is generally true about Bedrock in Sydney

Bedrock is generally available in ap-southeast-2 as of mid-2026. The set of foundation models offered inside the Sydney region is a subset of the full global catalogue; AWS publishes this matrix and updates it as models become available regionally. Common families that have been available in Sydney include Anthropic Claude, Meta Llama, Amazon Titan, and others, but you should verify the current list against the official Bedrock region documentation at the time of your evaluation.

Around Bedrock, AWS provides Knowledge Bases (managed retrieval), Agents (a tool-calling and orchestration construct), Guardrails (content and topic filtering), and Model Evaluation. These are configured per-region and inherit residency from the Bedrock region you select.

IRAP scope to verify

AWS publicly maintains the list of services assessed under IRAP. Bedrock has been assessed at certain levels; SageMaker and many lower-level services have been assessed historically at PROTECTED. The specific assessment level of Bedrock at any point in time should be checked against the ASD register and the AWS Australia compliance page rather than assumed.

Pricing posture

Bedrock offers on-demand (per-token), provisioned throughput (for sustained workloads requiring predictable latency), and batch inference (lower cost, asynchronous). Provisioned throughput on the highest-end models can be expensive for low-utilisation use cases; on-demand is usually the right starting point.

Integration touchpoints

Native AWS integration is the strongest argument for Bedrock if your data plane is already AWS. SageMaker for custom training and hosting, Lambda for tool implementations, API Gateway for fronting agents, OpenSearch or Aurora pgvector for retrieval, IAM for identity. CloudWatch and CloudTrail give you the observability and audit trail required by our 50-point AI security checklist.

Part 3: Microsoft Azure AI in Australia

Microsoft operates Australia East (Sydney) and Australia Southeast (Melbourne) regions, plus Australia Central (Canberra) regions that are positioned for government workloads. Azure's AI surface has two related but distinct identities: Azure OpenAI Service (the OpenAI model family hosted on Azure infrastructure) and Azure AI Foundry (formerly Azure AI Studio, the broader development and deployment platform that includes Azure OpenAI plus open-weight models, agents, evaluation, and content safety).

Azure OpenAI versus Azure AI Foundry positioning

For most teams, Azure AI Foundry is the surface to evaluate. It includes Azure OpenAI Service as one of many model providers, plus open-weight models, plus the development environment, evaluation tooling, and the Agents framework. Azure OpenAI Service in isolation is a model-API service with Microsoft's commercial and data-handling terms over the top of OpenAI's models.

Verify the set of models currently available in Australia East and Australia Southeast against the Azure OpenAI region availability documentation. As with Bedrock, the catalogue is a subset of the global catalogue, and new models reach Australia on a delay.

Microsoft 365 Copilot residency claims

Microsoft 365 Copilot is a related but separate product from the developer-facing Azure AI services. The data-handling story for Copilot is described in Microsoft's published documentation and is nuanced: customer data used to ground responses is processed under the Microsoft 365 commercial terms, but the underlying inference may occur outside Australia depending on configuration and the specific feature. This is a frequent source of confusion in procurement. Read the M365 Copilot data residency commitments directly and do not generalise from "Azure has Australian regions."

IRAP scope to verify

Microsoft maintains an Australian compliance page that lists IRAP-assessed Azure services and their assessment levels. Azure OpenAI Service, Azure AI services, and the broader Azure platform have been progressively assessed. As with AWS, the current state should be checked against the ASD register at the time of evaluation rather than inferred.

Enterprise agreement leverage

This is where Azure most often wins on TCO for businesses already running Microsoft 365. An existing Microsoft EA with Azure commit can be redirected to Azure AI Foundry consumption. Hybrid benefits and prepaid commitments often reduce the effective rate by 15 to 30 percent depending on the agreement.

Integration touchpoints

Azure's distinctive integration story is into Microsoft 365 (Outlook, Teams, SharePoint, Power Platform), Microsoft Fabric (the data analytics platform), Dynamics 365, and Microsoft Defender for Cloud for security posture. If your business runs on Microsoft, this is the lowest-friction surface.

Part 4: Google Cloud Vertex AI in Australia

Google Cloud operates australia-southeast1 (Sydney) and australia-southeast2 (Melbourne). Vertex AI is the unified ML and generative AI platform. Model Garden inside Vertex AI exposes Google's own models (the Gemini family, plus older models for specific tasks), open-weight models (Llama, Mistral, others), and partner models.

What is generally true about Vertex AI in Sydney

Vertex AI is generally available in australia-southeast1, and Gemini models are accessible from the Sydney region with the data residency characteristics described in Google's published documentation. As with the other two providers, the exact list of models available in the AU regions versus globally should be verified at the time of evaluation against the Vertex AI region availability documentation.

IRAP scope to verify

Google Cloud's Australian compliance page lists services assessed under IRAP and at what level. Historically Google's IRAP-assessed surface has been narrower than AWS or Azure but has expanded. Vertex AI and the Gemini API have been progressively included. Verify against the ASD register rather than relying on third-party summaries.

Pricing posture

Vertex AI uses per-character or per-token pricing on Gemini, per-second pricing on custom training, and node-hour pricing on Vertex endpoints for hosted predictions. Sustained-use discounts apply automatically to certain Compute Engine resources. Committed-use discounts apply on commitments of one or three years.

Integration touchpoints

The strongest argument for Vertex AI is the connection to BigQuery. If your data warehouse is already BigQuery, you can run Vertex AI predictions and embeddings against your warehouse data with minimal pipeline engineering. Vertex AI also integrates with Cloud Run for serverless tool hosting, Document AI for structured-document extraction, and the broader Google Workspace surface for productivity integration. For organisations on Google Workspace, the AI-in-Workspace story is the most direct of the three providers.

Part 5: Vendor-neutral comparison

The table below is deliberately at the strategy level. Service-level feature comparison is published by each vendor and changes monthly; the items below are durable.

Part 6: The data residency reality

"My data stays in Australia" is the question, but the answer has at least five sub-questions. The diagram below walks through what happens to a single prompt.

Each provider publishes a per-service data-handling document. The shared structure is:

• Customer content (prompts, completions, fine-tuning data, retrieval documents) is not used to train the foundation models offered by the platform
• Customer content is stored in the region selected
• Operational telemetry (request volumes, error rates, abuse signals) may be processed outside the region
• Some content-safety pipelines may use global infrastructure depending on configuration

The actionable position: read the per-service data-handling document for the specific AI service you will use, not the generic "Azure data residency" or "AWS data residency" overview. Then have your security or legal team confirm whether the residual cross-region telemetry is acceptable under your obligations (under APP 8 for personal information, under APRA CPS 230 and CPS 234 for finserv, and under the Privacy Act in general; see our GDPR versus Privacy Act comparison for the cross-border context).

Part 7: When to pick which

The decision tree below produces a starting recommendation. It is not a final architecture; treat it as the input to a one-to-two-week paid POC against the top two contenders.

The single most common pattern we see in AU businesses is a primary hyperscaler that matches the existing productivity and data stack, plus a secondary AI vendor used directly (via API rather than via the hyperscaler) for one or two specific use cases where the model in question is not yet available on the primary platform's regional catalogue.

For the broader question of how to staff and operate any of these, see the staffing gap for midsize AU businesses. For the upstream procurement question, the vendor selection question list applies to hyperscaler RFPs as well as to point solutions.

Part 8: The realistic multi-cloud and multi-vendor pattern

Single-cloud is fine for most businesses. It reduces operational surface, identity sprawl, and the cost of cross-cloud egress. It is the right default unless there is a specific reason to add a second cloud.

The specific reasons we see in practice:

1. A model on a different provider is materially better for a specific use case and is not available on the primary platform's AU regional catalogue
2. A specific compliance posture (sovereign cloud, defence-specific) is required for a subset of workloads
3. The primary provider has had repeated AU region availability issues for the AI service in question and a fallback is operationally required
4. The vendor enterprise agreement on the secondary cloud is much more favourable for AI consumption specifically

Counter-arguments:

1. Multi-cloud doubles the operational surface, the identity sprawl, the network configuration, and the security review burden
2. Egress costs between AU regions and between clouds are non-trivial at agent-scale token volumes
3. Skills are duplicated; very few engineers are deep on more than one hyperscaler's IAM and networking model

Pragmatic posture: pick one primary hyperscaler. Architect the agent stack so that the model API is swappable (OpenAI-compatible interfaces where possible, abstractions over Bedrock / Foundry / Vertex Model Garden in your application layer). Add a second cloud only when the cost of not having it exceeds the cost of running it. The same logic applies to model vendors as to hyperscalers.

Part 9: 10-question pre-selection checklist for the platform team

Before signing anything, the platform team should be able to answer all of these in writing. If the answer is "we will verify", that is fine; if the answer is silence, the procurement is not ready.

1. Which specific AI services from the candidate platform are GA in Sydney or Melbourne today, and which are on the regional roadmap?
2. Which of those specific services are currently IRAP-assessed, and at what level, per the ASD register?
3. For the AI service we plan to use first, where do prompts, completions, embeddings, and operational logs physically reside?
4. What is the documented data-handling commitment for customer content, training, and abuse monitoring on that specific service?
5. What is our realistic monthly token volume on the primary use case, and what is the on-demand vs provisioned vs batch break-even point?
6. What does our existing enterprise agreement actually discount on this platform, and what does the procurement team need to renegotiate?
7. What does the failure and cross-region failover behaviour look like for the AI service, and can we opt out of cross-region failover if required?
8. What is the exit plan at twelve, twenty-four, and thirty-six months if we change models or platforms?
9. What identity, network, and audit-log integration does this require, and is it consistent with our 50-point security checklist?
10. What does the operating cost look like at one, ten, and one hundred times the initial workload?

If your team can answer these, you are ready to run a paid POC against the top two contenders. If they cannot, the answer is to do the homework before the procurement, not after.

A realistic 8-week evaluation timeline

For a business choosing a hyperscaler for a specific AI workload, an eight-week evaluation is sufficient. Longer is usually procurement theatre; shorter is usually skipping the residency and IRAP verification.

Where this fits in the broader picture

Hyperscaler choice is one decision inside a larger set. If you have not already framed the strategy, our AI strategy services cover the upstream decisions. If you have chosen a model and platform and are now in operate mode, our managed AI services cover the operational layer.

For real-world examples of how the same architectural decisions play out on different platforms, see our case studies on Carbonly.ai (the multi-agent ESG platform) and RootCauseAI (the on-premise investigation tool). The platform choice was different in each because the data residency, compliance, and integration constraints were different.

Want to walk through your specific evaluation?

If you are sitting on a shortlist of two hyperscalers and need a second opinion on the residency, IRAP, or TCO assumptions before you sign, we run vendor-neutral hyperscaler-for-AI evaluations. We do not resell platforms and we do not take vendor incentives, so the recommendation is based on what fits your stack rather than what pays a margin.

Book a 30-minute consultative call to discuss your evaluation.

Related Reading:

• AI Model Selection Guide for Australian Business - The companion piece on choosing Claude, GPT, Gemini, Llama, or on-premise before you choose where to host
• AI Vendor Selection Questions for Australian Business - The upstream procurement question list that applies to hyperscaler RFPs
• Operating AI Agents in Production: The Reality for Australian Business - What changes once you are past procurement and running on your chosen platform
• AI Security Checklist: 50 Points for Australian Businesses - The security posture you need on whichever platform you choose
• Data Sovereignty in Australia: A Practical Guide - The deeper residency and compliance framework that underpins this comparison

Sources:

Vendor documentation referenced throughout: AWS Bedrock and SageMaker region availability and IRAP compliance pages; Microsoft Azure OpenAI Service and Azure AI Foundry region availability and Australian compliance documentation; Google Cloud Vertex AI and Gemini API region availability documentation. Government sources: ASD IRAP register, OAIC guidance on APP 8 cross-border disclosure, APRA CPS 230 and CPS 234, DTA cloud and AI policy publications. All references should be verified against current vendor and government documentation as of your project evaluation date, as platform catalogues, IRAP assessment scope, and pricing structures change frequently.