US cloud act, sovereignty, and why you might need to care

For years, the cloud was presented as a largely technical choice: compare price, reliability, security and features; select AWS, Microsoft Azure or Google Cloud; get on with the work. But increasingly that story is changing in important ways.

Airbus is moving its most critical applications for sensitive workloads from AWS to Scaleway, the French cloud provider. The first tranche comprises 70 applications, with around 900 systems, including ERP, CRM, manufacturing and product-lifecycle-management applications, intended to remain under European control.

This is not Airbus declaring that US cloud is technically inadequate. Nor is it a call for digital autarky. It is a decision about dependency.

Where data sits is not all that matters

It is tempting to believe that data is insulated from foreign legal reach if it sits in a Sydney, Frankfurt or Dublin data centre. Physical location does matter, but it is not the whole answer.

The US CLOUD Act requires certain providers subject to US jurisdiction to comply with valid orders for data in their possession, custody or control, even when that data is held outside the United States. A US-headquartered cloud provider can therefore face legal obligations that do not simply disappear because its customer has selected an Australian or European hosting region.

This does not mean that US providers casually hand over customer information, or that data residency is meaningless. The major hyperscalers have serious security capabilities, publish transparency reports and can contest legal demands.

But it does mean that a local data centre operated by a foreign provider is still local infrastructure embedded in a global corporate and legal system.

That is a governance issue, not just a technical one. And it is a genuine question about national security and data sovereignty.

What Airbus is actually doing

Airbus is not treating every workload as equivalent. A public website, an internal collaboration platform, payroll, aircraft-design data and defence-adjacent manufacturing systems do not carry the same risks if access is interrupted, legal control is contested, or a provider is compelled to comply with a foreign government order.

The question is not whether US cloud is good or bad. That is far too blunt.

The question is whether you have consciously decided which systems can sit inside another country’s legal and corporate sphere of influence, and which cannot.

For an aerospace manufacturer operating across civil aviation, defence, critical supply chains and national-security concerns, this distinction is obvious. But the same question applies, in different forms, to health data, energy systems, financial services, government, research institutions, critical infrastructure, Indigenous data and commercially significant intellectual property.

Cloud sovereignty is not achieved through a data-residency checkbox. It involves the legal jurisdiction of the provider; the parent company that ultimately controls it; who operates the infrastructure; where encryption keys sit; how identity is managed; which subcontractors are involved; and whether you can credibly leave.

The Australian blind spot

Australia often behaves as though data residency resolves sovereignty. It does not.

Choosing an Australian region of a US hyperscaler can be an entirely sensible decision. It can offer strong security, local latency, local support arrangements and mature services. But it is not the same thing as choosing infrastructure outside US corporate ownership and jurisdictional reach. Those are different decisions, with different risk profiles, and we should stop pretending otherwise.

We are starting to see why this distinction has practical consequences. Woolworths is moving some core applications to the network edge because a cloud or connectivity failure can create a large “blast radius”, including disruption to replenishment and the ability to keep products on shelves. Its response is to place selected workloads so they can keep operating when the core network or cloud does not. Woolworths’ edge move is not an argument against cloud. It is an acknowledgement that resilience depends on more than the availability promises of a centralised provider.

The Australian Signals Directorate is making a similarly uncomfortable point to critical-infrastructure operators. Its revised guidance asks them to be able to isolate operational technology and vital enabling systems from external networks, including the internet, for up to three months. The hard part is not simply disconnecting: it is knowing which supposedly ordinary shared services, such as identity, DNS, certificates, storage and time synchronisation, are actually necessary to keep essential operations running. ASD’s three-month isolation guidance is a prompt to design and test for disruption before a crisis makes that choice for you.

This becomes more urgent as generative AI turns cloud platforms into the substrate for ordinary organisational work. We are no longer merely buying compute and storage. We are wiring data platforms, identity systems, productivity suites, software-development tools, copilots, models, agents and operational workflows into a relatively small group of infrastructure providers.

That concentration has consequences. If much of your organisation depends on one or two offshore hyperscalers, the question is bigger than where the data lives. It is about your practical capacity to act if commercial terms change, a provider changes service conditions, access is restricted, a geopolitical dispute escalates, or a foreign legal obligation conflicts with your duties to customers, citizens, partners or regulators.

What we need to do

• Classify by consequence, not fashion. Decide where a workload belongs according to the harm caused by its unavailability, compromise or loss of control, rather than assuming that “cloud first” is an adequate architecture strategy. Woolworths’ focus on replenishment is a useful example: some functions have consequences far beyond an IT outage.
• Know your vital dependencies. Map the systems needed to run essential services, including identity, DNS, certificates, storage, network equipment, remote access, time services and vendor support. The dependencies most likely to defeat an isolation plan are often the quiet shared services rather than the obvious application.
• Design for degraded operation. Identify which services must continue when connectivity, a cloud control plane or a third-party SaaS platform is unavailable. Build local capability, manual fallbacks and suitably current copies of the data and configurations required to operate safely.
• Practice isolation, not just recovery. A disaster-recovery plan that assumes the provider, network and identity service are available is not a plan for a serious disruption. Exercise progressive isolation, including the business decisions about which functions are essential and which can be paused. ASD’s guidance explicitly frames full isolation as a last-resort resilience measure, supported by staged reductions in external connectivity.
• Preserve exit options. Use portable data formats, documented interfaces, exportable configurations and architectures that do not make replacement prohibitively slow or expensive. This does not require immediate multi-cloud duplication of everything; it requires avoiding dependencies that cannot be unwound.
• Separate location from control. Australian data residency may be valuable for latency, assurance and regulatory reasons. It does not, by itself, resolve questions of foreign corporate ownership, extraterritorial legal exposure, strategic leverage or the ability to operate independently during a disruption.
• Treat AI as infrastructure dependency. Do not assess an AI copilot, model API or agent only as a software procurement. Ask what data it can access, which identity and workflow systems it depends on, where inference occurs, what happens when it is unavailable, and whether another model or operating mode can take over.
• Put the question to the board. The useful governance question is not, “Are we in the cloud?” It is: “What critical services can we sustain, for how long, if this provider, network connection or external control plane becomes unavailable?” ASD’s three-month benchmark is deliberately intended to force that conversation.

This is not an argument for building everything on premise, nor for rejecting hyperscalers. It is an argument for strategic optionality: using global platforms where they make sense, while retaining the capacity to keep essential functions running and to change course when circumstances demand it.

A more useful starting point

Most organisations do not need a dramatic program to “exit the US cloud”. They do need a more honest account of their dependencies.

I would start here at a minimum (and this should already be part of your disaster recovery and business continuity planning):

1. Know which systems you could not afford to lose control of.
2. Understand who actually controls them, not merely where the servers are.
3. Ensure that “we could move if needed” is a tested capability, not a sentence in a procurement document.

That will lead to different answers for different workloads. Some may remain appropriately on a global hyperscale platform. Others may need a local, sovereign or privately operated alternative. Some may need stronger controls around encryption keys, identity, backups and portability. The important thing is that these are deliberate choices rather than accidental outcomes of convenience, market power and default settings.

The European Commission’s move to procure sovereign cloud services shows that this is no longer a fringe concern. It is becoming an operational question for major institutions.

Cloud is no longer merely somewhere else’s computer. It is institutional and geopolitical infrastructure, and it is time we treated it accordingly.