Every AI strategy eventually hits the same constraint: infrastructure. The choice of AI infrastructure partner shapes what you can build, how fast you can scale, and whether your data practices will hold up under regulatory scrutiny.
Australian businesses face decisions that buyers in the US or Europe do not. The local hyperscaler market is real but dominated by foreign-controlled infrastructure. Sovereign options exist, but vary significantly in capability, compliance posture, and support quality. Buying on price or brand name alone leaves regulated businesses exposed.
This guide gives you a practical evaluation framework. Not a product list. A set of criteria and questions that separate capable partners from capable-looking ones.
Compute capability: GPUs, servers and scalability
The first thing to evaluate is the actual hardware, not the marketing deck.
Ask which GPU models are available. NVIDIA H100 and A100 clusters are the current standard for large-scale AI training and inference. Providers running older V100 hardware or consumer-grade cards may look cost-competitive on paper but will fall short on throughput for serious workloads. Ask for benchmarks relevant to your specific task type: training runs, batch inference, and real-time API calls each stress the hardware differently.
Allocation model matters just as much as hardware generation. Dedicated GPU allocations guarantee consistent, predictable performance. Shared pools can queue-burst, meaning your training job stalls while another tenant’s workload runs. For time-sensitive inference or production applications, queuing is a design failure, not an acceptable trade-off.
Burst capacity is equally important. AI workloads are not steady-state. They spike at training milestones and inference peaks. A provider that can scale horizontally inside the same facility, without forcing you onto a waitlist or a different region, is worth the additional evaluation effort.
Finally, confirm physical server specs beyond the GPU model itself. Memory bandwidth, NVLink interconnects between GPUs, and storage throughput all affect AI job completion times. A provider that cannot answer these questions in detail is likely reselling someone else’s infrastructure and has limited visibility into the actual hardware stack.
Data sovereignty and compliance credentials
This is where Australian buyers most commonly underestimate risk.
A “Sydney region” hosted by a US-owned hyperscaler still has its control plane, billing, and legal jurisdiction anchored offshore. The US CLOUD Act allows US law enforcement to compel access to data held by American companies, regardless of where the physical servers sit. For financial services, healthcare, and government buyers, that exposure is not theoretical. It is a compliance gap.
A genuinely sovereign provider keeps data in Australia, operates under Australian law, and has no foreign parent entity with CLOUD Act obligations.
Before signing any contract, verify the following:
Data residency. Is your data stored exclusively on Australian soil? Is residency contractually guaranteed, not just assumed from geography?
Control plane location. Where does the management layer live? A Sydney compute node managed from a US control plane is not sovereign infrastructure.
Certifications. Does the provider hold ISO 27001? Are their data centres Tier 3+ certified?
Legal exposure. Is the provider or its ultimate parent subject to the US CLOUD Act or equivalent foreign legislation that could affect access to your data?
Amaze operates from Australian facilities, including NEXTDC and Equinix infrastructure across ap-syd-2 and ap-mel-1 regions, with ISO 27001 certification and contractually guaranteed data residency. No CLOUD Act exposure.
APRA-regulated buyers should also check alignment with CPS 230 operational risk requirements. Providers that cannot supply a supply chain register or evidence of third-party controls are not ready for regulated workloads.
Network performance and latency
Inference latency is the forgotten factor in most infrastructure procurement processes.
The round-trip time between your application servers and your AI compute determines how fast your product can respond. For real-time inference, medical imaging analysis, or financial risk scoring, latency accumulates quickly across thousands of API calls per hour. Twenty milliseconds sounds trivial in isolation. At scale, across a production workload, it becomes a measurable product quality issue.
Proximity matters. Compute located in the same Australian data centre or interconnected campus as your application eliminates the Pacific crossing entirely. Australian-based compute also removes the egress fees that make hyperscaler architectures expensive at scale, particularly when processing large datasets or running high-frequency inference requests against large models.
Ask providers for interconnection options. Private network paths, dedicated fibre links, and on-net peering all reduce latency variability. Public internet routing introduces jitter that is difficult to engineer around in production.
Check whether the provider operates their own network or resells capacity from a third party. Owned and operated networks give the provider direct control over routing, peering, and fault response. Resold capacity adds a dependency that may not appear in SLAs but will surface during incidents when it matters most.
Support, SLAs and scalability
Support quality is often invisible until something breaks at 2am on a Monday.
Ask where the support team is physically located. Offshore Tier 1 support may handle routine queries, but complex AI infrastructure incidents require engineers who understand the specific hardware and software stack in use. The ability to escalate to someone who works directly with the same NVIDIA clusters your workload runs on is meaningfully different from escalating to a general cloud support queue.
SLA terms require careful reading. Uptime guarantees mean little without defined response and resolution times attached to them. A 99.9% uptime SLA equates to roughly 8.7 hours of allowable downtime per year. If your workload is revenue-critical or patient-critical, that ceiling may not be acceptable.
Scalability commitments should be explicit and contractual. Ask what the process is for increasing GPU allocation as your workloads grow. Can capacity be added within 24 hours? Is there a commercial pathway to reserving capacity before you need it, rather than competing for it during a supply crunch?
Finally, check the escalation structure. Does your account team have authority to resolve infrastructure issues directly, or do they escalate to a central operations team with no contractual obligation to your business?
Questions to ask potential partners
Use this checklist as a starting point for any provider evaluation.
| Criterion | What to check | Red flag |
|---|---|---|
| Compute | GPU models, dedicated vs shared pool, scaling process, benchmark results, memory bandwidth and interconnect specs | Vendor won’t commit to dedicated capacity or share benchmark data |
| Sovereignty and compliance | Physical data location under contract, control plane location, CLOUD Act exposure, current certifications | Location claims aren’t backed by contract terms |
| Network | Owned vs resold network, interconnection options, round-trip latency to major Australian application environments | No visibility into who actually owns the network |
| Support and SLAs | Support team location, response and resolution commitments by severity, escalation path for critical incidents | Support is offshore with no defined SLA |
| Commercial | AUD-denominated pricing, egress fee structure and caps, mechanism for reserving capacity ahead of demand | Pricing in USD with uncapped egress fees |
The right AI infrastructure partner is not the cheapest or the most recognisable name. It is the one that can match your compute requirements, compliance obligations, and growth trajectory, while keeping your data where Australian law and your industry regulators require it to stay.
Related reading: Inside an AI-ready data centre: what makes it different and Why Australia needs sovereign AI infrastructure.
Frequently asked questions
Is a provider’s headline GPU spec a reliable indicator of real-world performance? Not on its own. Allocation model matters as much as hardware generation. A dedicated H100 allocation will consistently outperform a shared pool of the same GPUs under load, because shared pools can queue-burst and stall your job while another tenant’s workload runs.
Does an Australian data centre address guarantee data sovereignty? No. A “Sydney region” operated by a US-owned hyperscaler still has its control plane, billing, and legal jurisdiction anchored offshore, which means CLOUD Act exposure remains regardless of where the physical servers sit.
What does a 99.9% uptime SLA actually mean in practice? Roughly 8.7 hours of allowable downtime per year. For revenue-critical or patient-critical workloads, that ceiling may not be acceptable, and the SLA is only as strong as the defined response and resolution times attached to it.
What’s the most commonly overlooked evaluation criterion? Whether the provider operates their own network or resells third-party capacity. Owned and operated networks give direct control over routing, peering, and fault response. Resold capacity adds a dependency that may not appear in the SLA but surfaces during incidents.
