Beyond US Big Tech: Distributed DNS and Onshore Hosting for Small Businesses

Moving from Microsoft 365 to Google Workspace changes your software supplier. It does little to reduce your dependence on US technology giants.

On 16 September 2026, TechRadar reported an analyst's comparison of Microsoft 365 and Google Workspace, questioning the savings once bundled services, migration and retraining were considered. The comparison focused on enterprise requirements. It does not establish that every small business faces the same costs, or that everyone is migrating.

But licence cost is only one reason to reconsider a supplier. I would also ask what the business can control, what happens during a failure, and how difficult it would be to leave.

For small businesses in Australia and the United Kingdom, those questions extend well beyond email and office applications. They reach into website hosting, DNS, login systems and the services embedded in everyday business software.

I advocate reducing reliance on US big tech where there is a workable independent alternative. I have built infrastructure around that choice. The useful conversation starts with understanding what your business actually depends on.

The infrastructure beneath the brands

A website can involve several suppliers before a customer reaches its first page:

• The website host runs the server that stores and serves the site, and potentially its application and database.
• Authoritative DNS publishes the records that tell other systems where to find your domain's website, email and other services.
• A content delivery network or security proxy sits in front of the website, delivering content and filtering traffic. Customers may depend on it even when the underlying server is healthy.
• A login provider checks identities before people can enter an application. Its failure can block access to an otherwise working system.

AWS, Microsoft Azure and Google Cloud are cloud platforms. Cloudflare provides edge, DNS and security services, among other products and its position in the request path matters as much as where a website's server sits.

Buying applications from different brands does not necessarily create independent infrastructure. Several suppliers may depend on the same cloud platform or authentication service. You need to ask what sits underneath the invoice and what happens when one link in that chain fails.

That also explains why a green server-status light is not enough. Customers still need to find the server, pass any required security challenge and complete the transaction.

Four recent big-tech global outages that made those dependencies visible

These incidents happened in 2025. They illustrate different failure paths, rather than a single explanation for every outage.

AWS: 19–20 October 2025

An automated DNS management defect disrupted DynamoDB in Northern Virginia and affected dependent services. Customers experienced application errors and failed launches of new servers. Amazon Connect calls and chats were also affected: callers encountered busy tones, failed connections and routing problems. Existing EC2 instances remained healthy. The dates here follow AWS's Pacific-time account. See the AWS post-event summary.

The business lesson is that an apparently distant database dependency can reach a customer-facing telephone workflow, mo matter where your business is located.

Google Cloud: 12 June 2025

A global service-control incident disrupted access to multiple Google Cloud and Workspace products worldwide. The main incident lasted about three hours, with some products taking longer to recover. Intermittent API and interface failures interrupted dependent workflows but this was not every Google service or every running server going offline. See the Google Cloud incident report.

An API is the interface software uses to communicate with another service. If that connection fails, a business process can stop even when its own application is running.

Azure Front Door: 29–30 October 2025

Configuration metadata exposed a defect that caused failures across Azure Front Door's edge network. Microsoft's overall incident window exceeded eight hours, measured in UTC. Think about that timeline for a second. That's an entire work day. The effects included connection timeouts, DNS resolution problems, disruption to Microsoft services and difficulty opening support cases. Individual customers experienced different levels of impact. See the Azure Front Door post-incident review.

Recovery arrangements need to include how you obtain help when the usual support route is affected too.

Cloudflare: 18 November 2025

A faulty Bot Management feature file caused failures in Cloudflare's traffic-handling systems. Customers saw error pages, Turnstile failed to load, and dependent services experienced errors. Authentication failures could prevent users reaching their target applications. See the Cloudflare postmortem.

A working business website can become inaccessible because the service in front of it fails.

None of these incidents proves that a provider's nationality caused its outage. Independent and non-US providers can fail too. My conclusion is that concentrating critical dependencies deserves deliberate scrutiny, whatever the supplier promises about scale. Every business needs a practical backup plan for when a service it relies on becomes unavailable. That means deciding which functions must continue, how customers will receive updates, who will take responsibility for recovery, and where the necessary backups, credentials and instructions can be accessed if the main provider is offline. Keeping a backup is only part of that preparation: because you also need to know that it can be restored and how long the business can manage while that happens. The plan should be proportionate to the business and tested before an outage forces people to improvise under pressure.

Europe's sovereignty debate has a practical lesson

Schleswig-Holstein provides a specific example of an organisation reconsidering its dependence. The German state's move towards LibreOffice and open-source systems puts control over public-sector IT alongside licensing considerations. The Document Foundation's March 2025 update describes that direction and the state's emphasis on digital sovereignty.

This is a German state initiative, not an EU-wide instruction to abandon Microsoft. It does not mean Europe has stopped using US technology.

The useful lesson for an Australian business or a UK firm is that supplier independence can be an explicit objective. You do not need to wait for a government migration programme to assess your own dependencies. The UK is outside the EU, but questions about access, ownership and the ability to change suppliers remain relevant on both sides of the Channel.

Onshore hosting, control and resilience are different things

These terms need separate answers when you buy a service:

Data residency describes where specified data is physically stored or processed. For an Australian business requiring Australian hosting, onshore means Australia. For a UK business requiring UK hosting, it means the UK. One does not substitute for the other.

Sovereignty and control concern applicable jurisdictions, supplier ownership, administrative access, subcontractors, and who controls keys and systems. A local region operated by a US provider is a location choice, but it does not make you independent of that provider.

Operational resilience is the ability to withstand failure and restore an agreed level of service. Local hosting alone does not provide that. You still need recovery arrangements, people with access and a realistic understanding of dependencies.

Ask specific questions rather than accepting a sovereignty label. Where is the website physicaslly hosted? Where are its database and backups? Who can administer them? What can you export? Who can restore a service if the main account becomes unavailable?

A website hosted in the UK does not establish that every log, backup, email message or support interaction stays there. The same qualification applies to Australian hosting. Those requirements must be agreed and assessed separately.

The independent infrastructure I have built

I have built a systematic, distributed network and distributed DNS systems alongside onshore website hosting servers in Australia and the UK. I use Australian servers for Australian hosting requirements and UK servers for UK hosting requirements. Avoiding reliance on US big tech services for this web-hosting and DNS infrastructure is a deliberate part of the design.

This is infrastructure I design, configure and manage. Small businesses can use these services through Solway Web Consulting. I can also design and set up a comparable independent arrangement for a business that wants its own infrastructure, with responsibilities agreed around its requirements.

Separating DNS from a single hosting location is an intentional choice. Distributed authoritative DNS can improve the availability of the answers that direct visitors to a website. It does not replicate that website or bring a failed origin server back online. The origin is the server supplying the site's content; keeping it available requires its own design.

My article on the INDIGO cable faults and Australian website resilience explains another practical reason for this approach. For Australian visitors accessing a website or service on my Australian platform, keeping the website and reachable authoritative DNS infrastructure onshore can largely insulate access from faults on international submarine cables, provided the traffic follows working domestic routes and essential website functions do not depend on affected overseas services. Under those conditions, the visit does not need to cross the damaged international link. That is a useful resilience advantage, although an overseas login, payment service or other required integration can still introduce exposure.

Geographic spread also needs careful interpretation. Servers in different places may still share a provider, network or control system. Those are dependencies to assess, rather than properties to assume from a map.

Public DNS records are different from private website content and databases. Distributing DNS does not mean copying private site data internationally. Equally, I would not infer that DNS logs and every associated piece of metadata stay onshore without checking the relevant arrangement.

My role is to connect these technical decisions to what your business needs, deciding together where the website lives, what it relies on, who can maintain it and how you can move or recover it. For businesses considering a website move, my website security and migration service explains the planning involved. The aim is useful control with understood responsibilities, not an absolute claim about every internet transit network or third-party integration.

A proportionate plan for your business

You do not need to rebuild every business system at once. Start with a manageable scope and decisions you can verify.

1. Map the dependencies. Record where hosting, DNS, email, authentication, payments, backups and key integrations actually run. Include account ownership and the person responsible for each service. Ask application suppliers about underlying providers where those dependencies matter.

2. Decide what must continue. Identify the functions customers and staff need during an outage. Agree tolerable downtime and data loss. A public information site and a live ordering system have different recovery needs so your resiliance budget should reflect that difference.

3. Assess independent options. Compare onshore website hosting and distributed DNS against those requirements and your support capacity. An Australian practice might require its website and specified data in Australia however, a UK consultancy might need the equivalent in the UK. Check each service's scope rather than relying on the supplier's address.

4. Keep independently accessible backups. Make sure you can retrieve backups if the main hosting account is unavailable, and prove that they restore into a usable service. A backup is a recovery resource, not live failover. Document the work needed between retrieving it and serving customers again.

5. Protect recovery access. Keep credentials, recovery keys and operating instructions securely accessible during a primary-provider outage. Avoid a circular dependency where you must sign into the failed service to obtain the information needed to fix it. Decide who is authorised to use emergency access.

6. Plan a secure fallback. Where justified, provide a separate way to publish customer updates or maintain essential website functions. Agree how it will be activated and protected. Bypassing a security proxy by exposing an unprotected server is not a sound continuity plan.

7. Test the migration in stages. Check DNS records, certificates, email dependencies, forms and other functionality before switching traffic. Plan rollback, account for live data changes, and monitor after the move. A successful page load alone does not prove that enquiries or orders reach the business.

More suppliers bring more accounts, maintenance and coordination. Running your own systems brings patching, monitoring and backup responsibilities. Independence needs competent support and a budget for ongoing work.

For some businesses, the sensible first step is a recoverable public website with fewer external dependencies. For others, it is better account ownership and tested restoration. I would choose that scope before discussing complex infrastructure across several providers.

Use my services, or have your own arrangement built

There are two ways I can help.

Use the infrastructure operated by Solway Web Consulting. We can discuss suitable website hosting in Australia, New Zealand or the UK and the distributed DNS services I operate, with requirements and support scope agreed for your business.

Have your own independent arrangement built. I can assess dependencies, design and configure the infrastructure, plan migration and document its operation. Provider selection, account ownership and ongoing management responsibilities form part of that engagement.

Whether you want to use my existing services or have an arrangement built for your own business, I can help you assess the options and plan the move.