The Latency That Took a Detour Through a Different Country

The Latency That Took a Detour Through a Different Country

The problem usually announces itself slowly. A page load test here, a slightly sluggish dashboard response there. Nothing catastrophic, just a persistent sense that things could be faster. For a growing number of Singapore-based developers and small business owners, the moment of reckoning comes when they run a speed test from a local ISP and see latency numbers that make them wince — 80, 90, sometimes 100 milliseconds for a request that should feel instant.

The culprit, more often than not, is geography. AWS’s Singapore region (ap-southeast-1) is physically located in the city-state, but the routing paths from certain last-mile providers, the shared tenancy on a popular instance type, or the way traffic hops through peering points can introduce delays that feel like they belong a thousand kilometers away, not on the same island. Switching providers is not a decision made lightly — the migration work alone can take a full weekend — but the payoff, when it works, can be dramatic.

“I ran the same test three times because I didn’t believe the first result,” says Renata, a backend developer who moved a production e-commerce application off a t3.medium EC2 instance. “The latency dropped from about 82 milliseconds to 38. That’s not an optimization. That’s a different experience.”

Linode’s Singapore data center, which opened in 2019, sits in a different part of the city’s fiber ecosystem than AWS’s main cluster. The routing, for certain ISPs, is simply shorter. For someone running a latency-sensitive application — a booking engine, a real-time dashboard, a multiplayer game server — those milliseconds compound into something real: fewer timeouts, faster page renders, less jank in interactive elements.

One Developer Tracerouted From Jurong East and Watched the Packet Leave the Island

Before copying a single file, run a proper baseline. Not a ping test from your home connection, which tells you only about your own ISP’s routing. Use a multi-location monitoring service — anything that lets you check response times from at least five different Singapore-based probes. What matters is the median time, not the best-case one.

The most common mistake is misattributing a slow database query or a bloated image asset to network latency. A site that loads slowly from all locations — Singapore, Tokyo, Sydney, London — has a code or asset problem, not a server location problem. A site that loads quickly from Tokyo but slowly from Singapore has the opposite issue.

Check these specifically:

• First byte time from Singapore probes — anything over 60ms from a local probe suggests routing inefficiency
• Packet loss percentage — even 0.5% loss on a TCP-heavy application like an API can feel terrible
• Your own application’s response time — separate server processing time from network transit time using something like the Server-Timing header

One developer, who asked not to be named because their company still uses AWS for other workloads, described the moment they knew they had a routing problem: “I tracerouted from my office in Jurong East and watched the packet hop through a different provider’s infrastructure in another part of Singapore before coming back. It was taking a physical detour for no reason I could understand.” That kind of path inefficiency is invisible from a standard ping test but shows up immediately in a first-byte measurement.

Renata Dropped From a 4GB Plan to a 2GB Plan and Found It was Overkill

Linode’s pricing model is simpler than AWS’s — no separate charges for NAT gateways, no hidden data-transfer costs within the same region, no Elastic IP surcharges. A Nanode 1GB instance costs $5 per month. A 2GB plan runs $10. For a small business running a single web application or a staging environment, those prices are competitive enough that the migration pays for itself in eliminated egress fees.

But the temptation is to replicate the old server exactly — same RAM, same CPU allocation, same storage — which misses the point. AWS instances, especially the burstable t-series, throttle performance under sustained load. Linode’s standard plans do not. A 2GB Linode can outperform a t3.medium under continuous traffic because there’s no credit-bucket system to exhaust.

“I sized down,” says Renata. “I had been paying for a 4GB EC2 instance because the t3.small kept getting throttled at peak hours. On Linode, the 4GB plan was overkill. I dropped to the 2GB and it handled the same load without breaking a sweat.”

The rule: run the application under load on both providers before committing. Spin up a temporary instance on Linode for a weekend, point some test traffic at it, and watch the CPU steal statistics. If the Linode instance runs cooler than the AWS one at the same price point, sizing down is safe.

One Database Dump, 90 Minutes, and a Stored Procedure That Took Ten Times Longer

The actual server configuration is straightforward — Linode offers a standard Ubuntu 22.04 LTS image, and the command-line experience is similar enough that anyone comfortable with SSH will find the terrain familiar. The time-consuming part is the data transfer.

For a small application (under 10GB of assets, a few hundred thousand database rows), a direct rsync over the public internet works fine. For anything larger, Linode offers private networking between instances in the same data center and a 40Gbps uplink to the public internet. A database dump from a 50GB PostgreSQL cluster took one developer about 90 minutes using pg_dump piped through gzip and then rsync — not instant, but within a single working afternoon.

The sequence that worked for several teams who made the switch:

1. Take a full snapshot of the AWS instance (using either AWS’s built-in snapshots or a manual backup script)
2. Provision the Linode instance with the same OS version and software stack
3. Transfer the database first — it’s the most time-sensitive part
4. Transfer application code and static assets while the database restores
5. Update DNS A records to point to the new server’s IP
6. Monitor for 48 hours before decommissioning the old instance

The step most people skip is simulating the traffic shift. A DNS change propagates in minutes for some visitors and hours for others. Running a load test against the new instance while the old one still handles live traffic catches the slow-query-by-query issues that only appear under production conditions. One team discovered that a stored procedure that ran in 200ms on their old MySQL instance took 2.3 seconds on Linode’s managed database service — not because the server was slower, but because the default MySQL configuration used a different query execution plan. That kind of surprise is why the two-week cooldown period exists.

A Colleague on StarHub Saw 80ms While the Singtel User Saw 25

Singapore has a peculiar ISP landscape. Singtel, StarHub, M1, and MyRepublic each route traffic through different peering agreements. A server that performs well for Singtel users might be sluggish for StarHub users, and vice versa. The Linode data center, located at the Equinix SG1 facility, connects to the Singapore Internet Exchange (SGIX), which most major ISPs peer with directly.

A practical check: ask a friend or colleague on a different ISP than yours to run a speed test from their connection. If the latency is consistently under 30ms across all major providers, the server’s routing is healthy. If one ISP shows 80ms while another shows 25ms, a peering issue exists that a standard support ticket — not a server reconfiguration — will usually fix.

Linode’s support team has been described by multiple users as faster to respond than AWS’s, but the comparison is not entirely fair: AWS handles tens of thousands of times more customers. The real advantage is that Linode’s engineers can escalate a routing issue to their network operations team without the customer having to explain what peering means. One developer had a ticket about excessive jitter resolved in 22 minutes on a Sunday afternoon.

The $80 Egress Bill That Became $30 — and Latency Dropped by Half

AWS charges for data transfer out to the internet at rates that start around $0.09 per GB and don’t drop significantly. Linode includes 1TB of transfer on the $5 plan, 2TB on the $10 plan, and 4TB on the $20 plan. For a media-heavy application serving tens of gigabytes per month, the difference adds up quickly.

“We were burning about $80 a month on AWS data transfer alone,” says a technical co-founder whose startup migrated to Linode in early 2024. “On Linode, that same transfer came included with the plan. We went from a $120 monthly bill to $30, and the latency dropped by half. There’s no world where that’s not a win.”

The catch: Linode’s overage costs, if you exceed the included transfer, are higher per GB than AWS’s. A site that serves video or large binary files needs to calculate carefully. For a typical web application — a CMS, an e-commerce site, an API — the included transfer is almost always sufficient. For a streaming service or a file-hosting platform, the math is different and the included transfer may not be enough.

A Ticket Filed at 2pm Singapore Time Gets an Answer the Next Morning

AWS’s documentation is exhaustive and overwhelming. Linode’s documentation is thinner but more focused. The practical difference shows up when something breaks and the documentation doesn’t have the answer.

Linode’s support team handles tickets directly without an AI layer or routing through a first-level triage system. The trade-off is that the team is smaller and the response time can stretch during Asian business hours, which are ten to fourteen hours ahead of the US-based team’s daytime. A ticket filed at 2pm Singapore time might not get a response until the next morning local time. The developers who made the switch report that this is frustrating but manageable — the responses, when they come, tend to be technically precise and solve the problem on the first try rather than cycling through scripted suggestions.

AWS’s support, for basic-tier accounts, is more automated and slower for anything beyond password resets. A ticket about a routing issue to an Enterprise Support customer might get escalated in hours; for a basic account, it can take days. The gap in responsiveness narrows considerably once a problem is correctly diagnosed and asked in the right language.

The CPU Steal Percentage at 35% During a Flash Sale, Then Zero

The numbers from one documented case: a Node.js API behind an Nginx reverse proxy, serving JSON responses averaging 3KB each. Median response time from a Singapore-based ping probe dropped from 68ms to 31ms. The 95th percentile, which had been hovering at 110ms during peak traffic, settled at 48ms. The application’s real-world timeout errors — requests that would fail outright — dropped from an average of 12 per hour to zero over a three-day monitoring period.

Not every migration produces results that dramatic. If the source problem was not routing but an underpowered server, the latency improvement is modest — maybe 10-15ms — but the reliability improvement from not sharing CPU credits is tangible. Pages that used to spike to three-second load times under concurrent traffic smooth out to a consistent 400ms.

The real test comes during a traffic spike. AWS’s burstable instances can slow down unpredictably when the CPU credit balance runs dry. Linode’s non-burstable pricing means the server runs at its rated speed or fails cleanly — no gray zone where performance degrades slowly over an hour. One developer described watching their AWS instance’s CPU steal percentage climb to 35% during a flash sale, then finish the same sale on Linode with 0% steal across the entire event. “It’s the difference between a server that fights for resources and one that doesn’t have to,” they said. “You don’t appreciate it until you’ve seen the bad version.”

The decision to switch is not for everyone. An application that already loads in under 200ms from Singapore with no packet loss has no reason to move. But for anyone running a latency-sensitive service in a market where milliseconds mean revenue, the baseline number — 30ms instead of 60ms — changes how fast the application feels, not just how fast it measures. And for a web application, the difference between those two numbers is the difference between a user who stays and one who opens a competitor’s site in the next tab.