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 I need to redirect to

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

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 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 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.

comments powered by Disqus

Enrico Teotti

developer and agile mentor with over 15 years of experience in the IT industry across Europe, Australia and the US.

Back to Overview