Edge or origin? Where Australian devs should actually deploy
A decision framework for choosing Cloudflare's edge over a single ap-southeast-2 origin when your users are in Sydney, Perth, and everywhere between.
The continent breaks the usual edge pitch
Most edge-vs-origin arguments are written for the US or Europe, where “closer to the user” means shaving a hop across a dense mesh of metros. Australia is a different shape. The population sits in five coastal cities separated by some of the longest terrestrial links in any developed economy, and almost every managed cloud puts its primary presence in one place: AWS ap-southeast-2 in Sydney. Brisbane and Auckland traffic is homed to that region; Perth is roughly a continent away.
So the question for an Australian audience isn’t “is the edge faster.” It’s narrower: does pushing compute to Cloudflare’s Australian points of presence actually win against a well-run Sydney origin, and what do you give up to get there?
The problem: distance is real, but it’s not where you think
Start with the physics. A Sydney user hitting a Sydney origin is already fast — single-digit to low-double-digit milliseconds. The pain shows up on the other coast. Terrestrial fibre from Perth to Sydney lands around 48 ms one way on FTTP; the INDIGO Central subsea cable does it in roughly 47 ms. Melbourne to Sydney is far gentler, around 12–15 ms. None of that is fixable with code. It’s the speed of light through glass across 3,300 km.
Here’s the trap: that one-way number gets paid per round trip. A cold HTTPS connection from Perth to a Sydney origin costs a TCP handshake plus a TLS handshake — three to four round trips — before a single byte moves. At ~48 ms each, you’ve burned 150–190 ms on setup alone. That is the latency the edge attacks, and it’s why “the edge is faster” is true for the connection, not necessarily for your logic.
Cloudflare terminates TLS in Sydney, Melbourne, Perth, Brisbane, Canberra, and Hobart. A Perth user handshakes against Perth, not Sydney. The expensive setup round trips collapse to local latency. If your origin still lives in Sydney, the long-haul hop happens once, over a warm pooled connection Cloudflare already holds open — not on every cold client request.
That reframes the decision. The edge’s first job in Australia is connection termination and caching close to non-Sydney users, not necessarily running your whole app there.
Technical deep dive: what you actually run at the edge
Cloudflare Workers run JavaScript and WASM in V8 isolates, not containers. That distinction drives the real tradeoffs.
Cold starts. Isolates start in well under a millisecond. There’s no container to spin, no VM to thaw. Compare that to a Lambda behind API Gateway in ap-southeast-2, where a cold invocation can add hundreds of milliseconds. For spiky, latency-sensitive endpoints, this is the edge’s strongest structural advantage — and it has nothing to do with geography.
Runtime constraints. This is where teams get burned. There is no traditional filesystem at the edge — a single request can be served by any of thousands of machines, so there’s nothing local to write to. Node.js compatibility exists but is opt-in and partial: you need the nodejs_compat flag and a compatibility date of 2024-09-23 or later, and even then some APIs are stubs that import but don’t run. Libraries that assume a real OS, native bindings, or a long-lived process won’t port cleanly.
CPU limits. Workers default to 30 seconds of CPU time per request and can be raised to 5 minutes (300,000 ms) via cpu_ms in Wrangler. Crucially, time spent waiting on fetch(), KV, or D1 doesn’t count as CPU time. So I/O-bound work is fine; CPU-bound work (image transforms, crypto, heavy parsing) is what you meter.
// wrangler.jsonc — opt into Node APIs and raise CPU ceiling
{
"compatibility_date": "2024-09-23",
"compatibility_flags": ["nodejs_compat"],
"limits": { "cpu_ms": 120000 } // up to 300000 (5 min)
}If your handler is “validate a token, read from KV, return JSON,” the edge is a near-perfect fit. If it’s “open a connection to a stateful Postgres, run a transaction, call three internal services on a VPC,” you’re fighting the model, and a Sydney origin is the saner home.
Data residency: the constraint that overrides latency
For Australian apps this is often the deciding factor, not performance. The Privacy and Other Legislation Amendment Act 2024 tightened cross-border obligations, with most provisions live through 2025 and more reform flagged for 2026. APP 8 makes you accountable for personal information disclosed overseas, and sector rules go further: health records under the My Health Records Act must not leave Australia, and SOCI-covered critical infrastructure carries its own risk obligations.
The practical issue with a global edge is that it’s global by design. A naive Worker might execute or cache personal data in a PoP outside Australia depending on where the request routes. If you’re handling regulated personal information, pin processing and storage to Australian infrastructure — usually the edge does TLS termination, caching of non-personal assets, and routing, while regulated reads and writes hit a Sydney-region origin and an Australian datastore. Cloudflare’s regional controls plus an ap-southeast-2-pinned backend give you that split. Don’t let a latency optimisation quietly become a compliance incident. I dug into this division of labour in the data-sovereignty case studies.
The cost angle, in AUD
Two line items dominate and they pull in opposite directions.
| Item | Cloudflare Workers | AWS ap-southeast-2 origin |
|---|---|---|
| Entry cost | Free tier: 100k req/day; Paid plan US$5/mo (~A$7.70) | EC2/Lambda + ALB; no free always-on compute |
| Included usage (paid) | 10M requests + 30M CPU-ms | Pay per instance-hour / invocation |
| Request overage | US$0.50 per million requests | Per invocation + compute |
| CPU overage | US$0.02 per million CPU-ms | Per GB-second |
| Egress to internet | No bandwidth fees | ~US$0.09/GB (first 100 GB/mo free; Sydney runs at the higher end of AWS egress) |
Egress is the quiet budget killer. A content-heavy app served from a Sydney origin pays AWS per gigabyte out. The same traffic fronted by Cloudflare, with assets cached at the edge, carries no Cloudflare bandwidth charge and slashes origin egress because the origin is hit far less often. For read-heavy workloads the edge can pay for itself on bandwidth alone. For low-traffic internal tools, a small always-on box — a Fly.io syd machine runs ~US$1.94/mo for a 256 MB shared instance — may be cheaper than re-architecting around isolates.
Real-world impact: a decision framework
Skip the religion. Route by workload:
- Static and cacheable, national audience → edge wins outright. Caching in Perth/Melbourne/Brisbane PoPs erases the long-haul penalty and zeroes egress.
- Auth, redirects, A/B, personalisation at the edge of a cached site → edge. Tiny CPU, I/O-bound, benefits from sub-ms cold starts.
- Stateful, transactional, VPC-bound, or regulated personal data → Sydney origin. Keep it in
ap-southeast-2, let the edge terminate TLS and route. - Mostly Sydney/Melbourne users, modest traffic → a single Sydney origin is already fast; an edge layer is optional polish, not a fix.
- Perth/WA-heavy traffic → put something at the edge, even just termination and caching. That 48 ms one-way hop is the clearest case for moving work west.
The pattern that holds up: edge for the connection and the cache, origin for the state and the compliance. It’s rarely all-or-nothing.
Why it matters
The Australian deployment question is shaped by geography the rest of the world doesn’t share: one dominant cloud region, a handful of distant cities, and tightening data laws. “Just use the edge” and “just run a Sydney box” are both wrong as blanket advice. The win comes from splitting responsibilities — terminate and cache at Cloudflare’s Australian PoPs, keep state and regulated data pinned to a Sydney origin — and from measuring CPU time and egress in AUD before you commit. If you want the deeper architectural reasoning behind that split, it’s the backbone of the deployment chapter.
Next I’m benchmarking real Perth-to-edge versus Perth-to-Sydney-origin numbers on a live D1-backed Worker, and I’ll publish the percentiles — handshakes included — rather than the marketing round-trip figures.