Cloud Hosting for Australian Businesses

Region choice is a user experience decision before it is a compliance one

Australia sits a long way from the infrastructure most default configurations point at. A site served from Singapore, the US west coast or Europe is not merely a little slower for Australian users; the round trip is long enough that every dependent request compounds it, and an application that makes several sequential calls to render a page turns a network distance into a visible delay.

The fix is unglamorous and effective: run in an Australian region. Both Sydney and Melbourne are available from the major providers, and for the overwhelming majority of Australian workloads the right answer is one of them with a CDN in front for static assets. That combination removes the class of performance problem that no amount of front-end optimisation can fix, because you cannot optimise your way out of the speed of light.

Internal geography then becomes the second-order problem. Perth is far enough from the eastern seaboard that a Sydney-hosted interactive application is noticeably less responsive there, and the same is true for New Zealand users often served by the same deployment. For a content site the CDN handles it. For an application where every interaction hits the origin, it is worth deciding explicitly whether the western market matters enough to change the architecture, rather than discovering the answer from complaints.

Breach notification is an operational capability, not a policy document

The notifiable data breaches scheme requires that where there are reasonable grounds to suspect an eligible breach, the organisation assesses it expeditiously and, if it is eligible, notifies affected individuals and the regulator. The word doing the work there is assesses. You cannot assess what you cannot see, and the assessment clock does not pause while you build the logging you should already have had.

In practice that means several things have to exist before anything goes wrong. Access logs retained long enough to reconstruct what was reached and by whom. Application logs that record which records an authenticated session touched, not merely that a request occurred. Database audit trails on the tables holding personal information. Immutable retention, so an attacker with production access cannot quietly remove the evidence of what they took.

It also means a named owner and a written first hour. Who is called, who can take the system offline, who talks to customers, where credentials are rotated, how the affected record set gets enumerated. We set this up as part of the build rather than as a document produced afterwards, because the difference between a contained incident and a disclosed one is almost always whether these things existed before they were needed.

Backups you have restored, and the daylight saving trap

A backup that has never been restored is a belief rather than a capability. The failures are consistent and boring: the schedule silently stopped months ago, the dump completes but the file is truncated, the database is captured and the uploaded files are not, the restore procedure exists but takes eleven hours nobody had budgeted for, or the backups sit in the same account an attacker just compromised. Each of these is only discovered at the moment it matters unless someone has tested it.

So we treat restoration rather than backup as the deliverable: a documented and timed restore into a clean environment, run periodically and recorded, with backups held in a separate account or provider so a compromise of production does not take the recovery path with it. And where data residency matters, the backup destination is checked too, because a database in Sydney with snapshots replicated to another hemisphere is an offshore disclosure nobody decided to make.

The scheduling detail that specifically catches Australian deployments is daylight saving. Some states observe it and some do not, so the country runs on multiple offsets for part of the year. Any job scheduled in local time either shifts by an hour twice a year or runs twice or not at all on the changeover, and reports that aggregate by local day will double-count or skip. We schedule infrastructure jobs in UTC and convert for display, which removes the entire class of problem rather than patching it each October.

Questions worth asking any vendor

These apply to us as much as to anyone else bidding for your work.

• Ask which region the application runs in, then ask the same question about backups, logs, error tracking and analytics. Those are usually where data leaves the country unnoticed.
• Ask when a restore was last performed end to end and how long it took. An untested backup is a belief, and the timing is the number your business continuity plan depends on.
• Ask what logs exist that would let you determine which records were accessed in an incident. Without them you cannot assess a suspected breach within the time the scheme allows.
• Ask for a monthly cost estimate in AUD including egress at your real traffic, and ask what the figure does if the exchange rate moves, because the invoice is in USD.
• Ask whether scheduled jobs run in UTC. Local-time scheduling in a country with split daylight saving produces jobs that run twice, or not at all, twice a year.