Load balancing for Australian hosting
Most load balancers don't actually balance load. Here's why, and how to fix it for Australian-hosted applications. Contact National Digital.
National Digital designs, builds, hosts and supports the platforms it delivers, with no reseller or integrator between the client and its engineers.
Written by Tara Buckley, COO · Reviewed by Cameron Young, CEO on
- Platform Engineering
- Cloud Engineering
- Scalable Architecture Design
- System Integration
Quick answer:Load balancing on Australian hosting fails when health checks miss real dependency failures, legacy apps keep session state in memory, or failover routes traffic overseas.
Quick answer
What does load balancing need to get right on Australian hosting infrastructure?
Effective load balancing on Australian infrastructure needs real dependency health checks, stateless application tiers, and a clear answer for where failover traffic is allowed to go under privacy rules.
Additional Context
Most outages blamed on a load balancer are actually health check or session-state problems in the application behind it.
Sources
- Hosting Certification Framework
Sets requirements for hosting providers handling Australian government and government-related data.
- APP 8 — Cross-border disclosure of personal information
Explains obligations when personal information may be disclosed overseas, including via failover routing.
Platform Engineering
Why load balancing decisions differ in Australia
A load balancer distributing traffic across three servers in Virginia behaves identically to one distributing traffic across three servers in Sydney. What differs is everything around it: the size of the local market, the regulatory obligations attached to where data physically sits, and the age of the application being put behind the balancer. Most growing Australian businesses aren't deciding whether to load balance from a blank slate. They're retrofitting it onto a platform that was never built with multiple concurrent instances in mind, which is where service separation becomes relevant before the load balancer configuration does.
The practical question is usually simpler than the architecture diagrams suggest: can this application run on two servers at once without corrupting state, and if not, what's the smallest change that makes it possible? That question sits underneath system integration and cloud engineering work generally, and it's the one teams skip when they treat load balancing purely as a networking task, when the real constraint lives in the application's own design.
Choosing the right load balancing mechanism
Layer 4 load balancing routes connections based on IP and port, is fast, and knows nothing about what's inside the request. Layer 7 load balancing reads the HTTP request itself, which means it can route API traffic differently from web traffic, terminate TLS centrally, and make health decisions based on actual application responses. For a business running a public API alongside a customer-facing site, Layer 7 is usually the better fit precisely because it can tell the difference between the two and apply different rules to each.
Platform Engineering
When Load Balancing Doesn't Actually Balance
Problem
Many Australian businesses add a load balancer expecting instant resilience, then find one server still carries most of the traffic, health checks miss real failures, and legacy applications weren't built to run on more than one node at a time.
Common Pain Points
- One node carries most traffic Sticky sessions or shared state mean load balancing exists on paper but not in practice.
- Health checks miss real failures A server can pass its health check while every request it serves times out or errors.
- Legacy app wasn't built for this Session state, file handling, or caching assumptions break the moment a second node joins.
Business Impact
- Time Wasted Recurring after-hours incident response
- Cost Implication Infrastructure sized for peak load but idle most of the week
- Opportunity Cost Engineering effort spent diagnosing outages instead of building features
Solution
A staged approach that fixes health checks first, externalises session state second, and only then expands capacity, so each change is tested against real traffic before the next lands.
Our Approach
- Audit health checks and session handling (Short initial phase)Review what each health check actually tests and confirm whether the application can run statelessly across nodes.
- Externalise state and stage capacity (Longer phase, staged incrementally)Move session data to a shared store, then add nodes behind the balancer incrementally while monitoring real traffic distribution.
Expected Outcome
Traffic genuinely spread across nodes, failures caught before customers notice, and capacity that scales without a rewrite.
Key Takeaways
What Actually Makes Load Balancing Work
- A passing health check doesn't mean a healthy applicationCritical
Health checks that only test port connectivity miss database exhaustion, dependency timeouts, and partial failures that still return a success response.
- Sticky sessions undo the point of adding serversImportant
Pinning users to one server to work around in-memory sessions concentrates load back onto a single node and removes most of the benefit.
- Failover plans carry privacy obligations most teams missImportant
Routing failover traffic overseas can trigger cross-border disclosure obligations under the Australian Privacy Principles if personal data is involved.
- Legacy applications usually need staged changes, not a rewriteImportant
Externalising session state and fixing health checks can make an existing application load-balancer-ready without rebuilding it from scratch.
Load balancing only delivers resilience when health checks test real dependencies, session state sits outside individual servers, and failover paths respect Australian privacy obligations.
Load Balancing Context for Australian Hosting
Figures here cover the regional infrastructure and privacy obligations that shape how load balancing is actually configured for Australian-hosted applications.
Multiple zones
Sydney region availability zones
Significance: mediumAmazon Web Services' Sydney region runs several physically separate availability zones, enough for active-active load balancing without routing traffic overseas.
Source: AWS Global Infrastructure, aws.amazon.com/about-aws/global-infrastructure/regions_az
DTA-certified required
Government hosting certification
Significance: mediumHosting providers serving Australian government or government-related workloads must hold certification under the Digital Transformation Agency's Hosting Certification Framework before failover traffic can legally terminate there.
Source: Digital Transformation Agency, dta.gov.au/help-and-advice/hosting-certification-framework
Notice obligation
Overseas failover disclosure
Significance: highDirecting failover traffic to a data centre outside Australia can trigger the cross-border disclosure requirements in the Australian Privacy Principles if personal information is involved.
Source: Office of the Australian Information Commissioner, oaic.gov.au
Methodology
Drawn from publicly published AWS regional infrastructure data, the Digital Transformation Agency's hosting certification requirements, and OAIC guidance on cross-border data disclosure.
Implementation Reality
The failure mode most teams miss: health checks that lie
A load balancer configured with a basic TCP health check confirms a server is listening on its HTTPS port. It says nothing about whether that server's database connection pool is exhausted, whether a downstream API is timing out, or whether the application is returning errors for every third request. The load balancer keeps sending traffic to a node that looks healthy and isn't, and the outage that follows often gets blamed on the load balancer, when the real fault sits in a health check that was never testing the right thing. A health check that calls a real endpoint, one that touches the database and any critical dependency, catches this before customers do.
Sticky sessions are the other recurring problem. Teams moving a legacy application behind a load balancer often discover the application keeps user sessions in local server memory, so the quickest fix is to pin each user to one server. That removes the benefit of having added a second server in the first place, since one node still carries most of the load. The durable fix is externalising session state, usually to a shared cache or message queue-backed store, so any node can serve any request. That's application modernisation work that happens in the codebase, well before any load balancer setting matters.
Data residency and the question nobody asks early
Most Australian hosting setups run active-active across availability zones within a single region, which keeps failover traffic inside the country without anyone having to think about it. Problems show up when a disaster recovery plan assumes failover to an overseas region, because that can trigger cross-border disclosure obligations under the Australian Privacy Principles for any personal information the failover path touches. Testing this early, including latency benchmarking across regions, avoids finding out during an actual incident that the backup plan has a compliance problem the primary setup didn't.
Get Load Balancing That Actually Distributes Load
If one server is still carrying most of your traffic despite a load balancer in front of it, the fix usually lives in the application layer. Send us what is happening under load and get a staged fix that does not require a rewrite.
Load Balancing Questions, Answered
What's the difference between load balancing and failover?
Load balancing spreads normal traffic across multiple healthy servers at the same time, so no single node carries all the load. Failover is what happens when a server or region goes down entirely and traffic reroutes to a backup. A well-configured setup does both: the load balancer distributes traffic while nodes are healthy, and redirects it entirely when one fails its health check.
Does setting up load balancing count as cloud engineering or platform engineering?
It touches both. Cloud engineering covers provisioning the balancer, availability zones, and network rules on the hosting platform itself. Platform engineering covers the broader system: health checks, session handling, deployment pipelines, and the internal tooling that lets an application behave correctly across multiple nodes. Load balancing rarely succeeds as a pure infrastructure task.
Do Australian privacy rules affect where load balancer traffic can go?
Yes, if personal information is involved. Routing failover or overflow traffic to a server outside Australia can trigger cross-border disclosure obligations under the Australian Privacy Principles, which generally require notifying individuals before their data could be disclosed overseas. This is worth checking early, while finalising a disaster recovery plan, long before any actual incident forces the question.
Is Layer 7 load balancing better than Layer 4 for an API?
For most APIs, yes. Layer 7 load balancing reads the HTTP request itself, so it can route by path or header, apply different rules to API traffic versus web traffic, and make health decisions based on actual application responses. Layer 4 is faster and simpler but blind to anything inside the request, which matters less for a single simple service and more once an API and a website share infrastructure.
Can a legacy on-premise application be load balanced without a full rewrite?
Usually, yes, through staged changes that avoid a full rewrite. The common blockers are in-memory session state and health checks that only confirm the server is running, not that it's working correctly. Externalising sessions to a shared store and rewriting health checks to test real dependencies typically gets an existing application load-balancer-ready without touching its core logic.
What health check mistakes cause the most outages?
The most common mistake is a health check that only confirms a port is open or a basic page loads, without testing the dependencies the application actually relies on. A server can pass that check while its database connection pool is exhausted or a downstream API is timing out, so the load balancer keeps sending it traffic it can't serve. Testing a real endpoint that exercises those dependencies catches this before customers do.