I was building a feature to redirect traffic coming from Australia to an Australian partner that given the original URL would serve different content. For example if somebody in Sydney visits http://myapp.com/wedding-cakes I need to redirect to http://anotherapp.com.au/redirct-myapp?path=%2fwedding-cakes.

In order to do that I relied on our CDN geolocation to set a HTTP_CF_IPCOUNTRY header with the request country of origin. This was done to avoid including a geolocation library in all the verticals serving portions of http://myapp.com.

I suggested the best and most reliable way to test this was to fly me to Australia but management did not approve – so after TDD the feature I deployed it and tested it on a qa server trough my personal VPN in Australia, it all worked fine until somebody reported it was not working. Someone in the office suggested to test with an EC2 instance in the Sydney region, I was very skeptical that would be a better test then my VPN (that I use to stream ABC news while I am living in NYC). After a few minutes I had the EC2 instance with Ubuntu – I hit a headers test page curl http://myapp.com/__test_headers and it returned HTTP_CF_IPCOUNTRY set to US – somebody might think the feauture wasn’t working.

Using whois I found the EC2 instance in Sydney uses an IP registered by Amazon in Seattle:

[...]
OrgName:        Amazon Technologies Inc.
OrgId:          AT-88-Z
Address:        410 Terry Ave N.
City:           Seattle
StateProv:      WA
PostalCode:     98109
Country:        US
RegDate:        2011-12-08
Updated:        2014-10-20
[...]

I tested the IP of that Sydney region instance on an online IP geolocation http://www.iplocation.net/ and different services returned different countries: US, France, Australia.

Geo IP location is fragile that can’t be trusted to determine locations of servers in the cloud. This is a very good explanation on how geo IP works.