I’ve recently joined Cloudflare as Head of Australia and New Zealand (ANZ). This is an important time for the company as we continue to grow our presence locally to address the demand in ANZ, recruit local talent, and build on the successes we’ve had in our other offices around the globe. In this new role, I’m eager to grow our brand recognition in ANZ and optimise our reach to customers by building up my team and channel presence.

I’m a Melburnian born and bred (most livable city in the world!) with more than 20 years of experience in our market. From guiding strategy and architecture of the region’s largest resources company, BHP, to building and running teams and channels, and helping customers solve the technical challenges of their time, I have been in, or led, businesses in the ANZ Enterprise market, with a focus on network and security for the last six years.

I joined Cloudflare because I strongly believe in its mission to help build a better Internet, and believe this mission, paired with its massive global network, will enable the company to continue to deliver incredibly innovative solutions to customers of all segments.

Four years ago, I was lucky to build and lead the VMware Network & Security business, working with some of Cloudflare’s biggest ANZ customers. I was confronted with the full extent of the security challenges that ANZ businesses face. I recognized that there must be a better way to help customers secure their local and multi-cloud environments. That's how I found Cloudflare. With Cloudflare's Global Cloud Platform, businesses have an integrated solution that offers the best in security, performance and reliability.

Second, something that’s personally important for me as the son of Italian migrants, and now a dad of two gorgeous daughters, is that Cloudflare is serious about culture and diversity. When I was considering joining Cloudflare, I watched videos from the Internet Summit, an annual event that Cloudflare hosts in its San Francisco office. One thing that really stood out to me was that the speakers came from so many different backgrounds.

I’m extremely passionate about encouraging those from all walks of life to pursue opportunities in business and tech, so seeing the diversity of people giving insightful talks made me realise that this was a company I wanted to work for, and hopefully perhaps my girls as well (no pressure).

I strongly believe that Cloudflare’s mission, paired with its massive global network, will enable customers of all sizes in segments in Australia and New Zealand to leverage Cloudflare’s security, performance and reliability solutions.

For example, VicRoads is 85 percent faster now that they are using Argo Smart Routing, Ansarada uses Cloudflare’s WAF to protect against malicious activity, and MyAffiliates harnesses Cloudflare’s global network, which spans more than 180 cities in 80 countries, to ensure an interruption-free service for its customers.

Making security and speed, which are necessary for any strong business, available to anyone with an Internet property is truly a noble goal. That’s another one of the reasons I’m most excited to work at Cloudflare.

Australians and Kiwis alike have always been great innovators and users of technology. However, being so physically isolated (Perth is the most isolated city in the world and ANZ are far from pretty much everywhere else in the world) has limited our ability to have the diversity of choice and competition. Our isolation from said choice and competition fueled innovation, but at the price of complexity, cost, and ease. This makes having local servers absolutely vital for good performance. With Cloudflare’s expansive network, 98 percent of the Internet-connected developed world is located within 100 milliseconds of our network. In fact, Cloudflare already has data centers in Auckland, Brisbane, Melbourne, Perth, and Sydney, ensuring that customers in ANZ have access to a secure, fast, and reliable Internet.

I’m truly looking forward to helping Cloudflare grow its reach over the next five years. If you are a business in Australia and New Zealand and have a cyber-security, performance or reliability need, get in touch with us (1300 748 959). We’d love to explore how we can help.

If you’re interested in exploring careers at Cloudflare, we are hiring globally. Our team in Australia is small today, about a dozen, and we are growing quickly. We have open roles in Solutions Engineering and Business Development Representatives. Check out our careers page to learn more, or send me a note.

Each birthday has given us the opportunity to thank our customers with new announcements, from our automatic IPv6 Gateway to making SSL free and easy for all to unveiling our China network. Launching 14 new data center locations is one of many gifts to our users we’ll reveal this week.

Cloudflare global network (orange: new data center, purple: existing data center)

Six years ago, within weeks of Cloudflare launching, we passed a major milestone: serving one billion web requests across our network every month. Since then, our traffic has grown 10,000x, and we now see over a billion web requests every month just from the country of Angola — located on the western coast of southern Africa and three times the geographic size of California. This led us on a journey to deploy our newest data center in Luanda, the capital city, shaving 150ms in latency off every request and joining our existing Africa data centers in Cairo, Mombasa and Johannesburg.

Latency (ms) decreases 10x for an Internet user in Luanda to Cloudflare. Source: Cedexis

Angola has seen a 280x increase in Internet users over the past 15 years, growing to 6 million Internet people. This figure is already higher than Denmark, and growing ten times as fast. That said, even today, fewer than one in four Angolans are online so there’s huge potential for more growth ahead. We’re committed to building infrastructure across Africa and to supporting the next billion people coming online.

In the United States, where Internet penetration is significantly higher (~90%), our expansion continues as we announce the launch of seven data centers at one go: Boston, Las Vegas, Nashville, Omaha, Philadelphia, St Louis, and Tampa. Many of our customers are businesses and blogs alike serving visitors in these markets in US states with a combined population of over 50 million people. Our newest US data centers not only reduce latency for millions of websites, but also provide additional redundancy to each other and to our existing North America data centers in Ashburn, Atlanta, Chicago, Dallas, Denver, Los Angeles, Miami, Minneapolis, Montréal, Newark, Phoenix, San Jose, Seattle, Toronto, and Vancouver.

Cloudflare began as winners of the Harvard Business Plan competition in Boston, and the admission programs at both Harvard and MIT — two great Boston-based universities — are proud Cloudflare customers. We are very proud to now operate a data center in Boston. Since our last birthday, we have doubled both the number of data centers, and our aggregate edge capacity in North America.

Iberian peninsula (including Lisbon, Portugal) courtesy of NASA Earth Observatory

Our newest European data centers in Athens, Lisbon and Helsinki truly represent the breadth of the 750 million person continent, and join our existing datacenters in Amsterdam, Berlin, Brussels, Bucharest, Copenhagen, Dublin, Düsseldorf, Frankfurt, Hamburg, Kiev, London, Madrid, Manchester, Marseille, Milan, Moscow, Oslo, Paris, Prague, Sofia, Stockholm, Vienna, Warsaw, and Zürich. (To close observers of the Iberian peninsula photo, there is another major city displayed which is days away from having a live Cloudflare data center).

While our Buenos Aires, Argentina data center has held the record for being our southernmost deployment (34° S), Helsinki now takes the prize for our northernmost deployment (60° N), and becomes our third PoP within 500 miles (800 km) of the Arctic Circle.

Over 9,000 miles away (14,500 km), one of the farthest cities from Helsinki is the sunny city of Brisbane, Australia, also home to a new Cloudflare data center. This is our fifth data center in the region, joining Auckland, Melbourne, Perth and Sydney.

There is no excuse now for Telstra and Optus not to peer with us as we have physical presence in the four largest population centers in Australia.

Manila, Philippines. Source: Jensen Ching (Flickr)

New data centers in Manila and Shanghai further grow our Asia network to 37 unique cities, joining Bangkok, Chengdu, Chennai, Doha, Dongguan, Dubai, Foshan, Fuzhou, Guangzhou, Hangzhou, Hengyang, Jinan, Hong Kong, Kuala Lumpur, Kuwait City, Langfang, Luoyang, Mumbai, Muscat, Nanning, New Delhi, Osaka, Qingdao, Seoul, Shenyang, Shijiazhuang, Singapore, Suzhou, Taipei, Tokyo, Wuhan, Wuxi, Xi’an, Zhengzhou, and Zhuzhou.

Our global expansion is by no means done with these fourteen freshly deployed data centers, as we have twice as many additional cities in the works right now.

While new cities make for especially fun announcements, under the hood, we’ve been making a series of upgrades to prepare for the demands of the next generation of Internet-facing applications. These include:

• achieving high security and compliance standards

• deploying our newest generation of servers and networking gear

• growing our interconnection through both private peering and at more public internet exchanges than any other company, while doubling our network capacity to 10 Tbps (more than the publicly announced DDoS scrubbing capacity of all our competitors combined)

• increasing our availability by solving gnarly edge cases and deploying greater automation

Every Cloudflare server globally can perform all our features such as DDoS mitigation, DNS, HTTP2 support, SSL and our newest offerings to be announced later this week. We’re grateful for our customers’ support on our journey to these first 100 data centers, and look forward to the next 100.

－ The Cloudflare Team

CC BY-SA 2.0 image by Quinn Dombrowski

Two years ago, we previewed the relative cost of bandwidth that we see in different parts of the world. Bandwidth is the largest recurring cost of providing our service. Compared with Europe and North America, there were considerably higher Internet costs in Australia, Asia and Latin America. Even while bandwidth costs tend to trend down over time, driven by competition and decreases in the costs of underlying hardware, we thought it might be interesting to provide an update.

Since August 2014, we have tripled the number of our data centers from 28 to 86, with more to come. CloudFlare hardware is also deployed in new regions such as the Middle East and Africa. Our network spans multiple countries in each continent, and, sometimes, multiple cities in each country.

Traffic across 86 data centers in the CloudFlare network

There are approximately thirteen networks called “Tier 1 networks” (e.g., Telia, GTT, Tata, Cogent) who sell “transit” to access any of thousands of other networks on the Internet using their global backbones, including networks who are not their customers. We connect to networks by either purchasing transit from a global "Tier 1 network" (or major regional network), or by exchanging traffic directly with a carrier or ISP using “peering”. Typically, peered traffic is exchanged without settlement between the peered parties.

We try to make it as easy as possible for networks to interconnect with us. CloudFlare has an “open peering” policy, and participates at nearly 150 internet exchanges, more than any other company.

As a benchmark, let's assume the cost of transit in Europe and North America is 10 units (per Mbps). With that benchmark in place, without disclosing exact pricing, we can compare regions by transit cost, percentage of peering, and their effective blended cost (transit + peering).

Europe Transit vs Peering (Last 30 Days)

Based on our benchmark, the transit cost is 10 units. The region has a large number of Internet exchanges, typically non-profit, where we peer around 60% of our traffic. This makes for an effective regional cost of 4 units.

With perhaps the notable exception of the incumbent in Germany, many networks are supportive of open interconnection. CloudFlare already participates at 40 European internet exchanges, and is in the process of joining at least five more.

North America Transit vs Peering (Last 30 Days)

The cost of transit in North America is equal to the cost in Europe, or 10 units. We peer around 40% of our traffic, resulting in an effective regional cost of 6 units.

The level of peering in North America is less than in Europe, but a significant improvement over two years ago. The share of peered traffic is expected to grow. Some material changes have occurred and are occurring in the North American market, such as Frontier acquiring Verizon FiOS customers in three U.S. States and Charter preparing to merge with Time Warner Cable. We can see these changes making an impact to the regional interconnection landscape.

Notably, our peering has particularly grown in smaller regional locations, closer to the end visitor, leading to an improvement in performance. This could be through private peering, or via an interconnection point such as the Midwest Internet Cooperative Exchange (MICE) in Minneapolis.

Africa Transit vs Peering (Last 30 Days)

Transit prices in Africa are amongst the highest in the world at 14 times the benchmark or 140 units, with notable variance across the continent, from Cairo to Mombasa to Johannesburg. Fortunately, of the traffic that we are currently able to serve locally in Africa, we manage to peer about 90% (with a mix of carriers and ISPs), making for an effective cost of 14 units.

Our African deployments help us avoid the significant latency of serving websites from London, Paris or Marseille. A particularly promising but challenging region where we hope to deploy a CloudFlare data center is West Africa - specifically Nigeria, which is already at just under 100 million Internet users.

Middle East Transit vs Peering (Last 30 Days)

CloudFlare currently has four data centers in the Middle East, each of which are cache deployments with strategic ISP partners to serve their respective customers. We are able to peer all the traffic currently served from these data centers. While these collectively provide significant coverage, there is additional traffic (reaching Europe) that we would like to localize in the region. We hope that the remaining ISPs, such as Saudi Telecom Company, deploy similar caches, and enhance the performance of their customers.

Because we can peer 100% of our traffic in the Middle East, our effective pricing for bandwidth in the region is 0 units. There are, of course, other costs to delivering our service beyond bandwidth. However, by driving up peering rates in the Middle East we’ve been able to make our service in the Middle East extremely cost competitive.

Asia Transit vs Peering (Last 30 Days)

In Asia (excluding the Middle East), transit costs 7 times times the benchmark, or 70 units. However, we peer about 60% of our traffic, resulting in an effective cost of 28 units.

Beyond the major meeting points in Hong Kong, Singapore and Tokyo, a significant portion of our interconnection is localized to take place closer to visitors in cities such as Bangkok, Chennai, Kuala Lumpur, Mumbai, Osaka, New Delhi, Seoul, and Taipei. These statistics do not include our network of strategically located data centers inside of mainland China, where the dynamics of interconnection are entirely unique.

Two Asian locations stand out as being especially expensive: Seoul and Taipei. In these markets, with powerful incumbents (Korea Telecom and HiNet), transit costs 15x as much as in Europe or North America, or 150 units.

South Korea is perhaps the only country in the world where bandwidth costs are going up. This may be driven by new regulations from the Ministry of Science, ICT and Future Planning, which mandate the commercial terms of domestic interconnection, based on predetermined “Tiers” of participating networks. This is contrary to the model in most parts of the world, where networks self-regulate, and often peer without settlement. The government even prescribes the rate at which prices should decrease per year (-7.5%), which is significantly slower than the annual drop in unit bandwidth costs elsewhere in the world. We are only able to peer 2% of our traffic in South Korea.

If you include HiNet and Korea Telecom in our blended bandwidth pricing, and take into account peering, our effective price is 28 units. If you exclude HiNet and Korea Telecom, our effective price is 14 units.

South America Transit vs Peering (Last 30 Days)

Transit prices in South America are very high, costing 17 times the benchmark, or 170 units. We peer about 60% of traffic in South America, making for an effective cost of 68 units.

One of the reasons that transit prices are high is that the Tier 1 networks which are newer entrants to this region have yet to pick up significant market share. While markets such as Brazil are less expensive and have greater peering, costs are highest in countries such as Peru and Argentina where, in each, a single incumbent provider, respectively Telefonica and Telecom Argentina, controls access for the last mile delivery of content to the majority of Internet users.

As we try to increase our share of peered traffic, one of the challenges we face is that many Internet exchanges (e.g., NAP Colombia) only permit domestically incorporated and licensed networks to publicly peer, or in another case, require a unanimous vote of all members on an IX to permit a new participant, effectively creating a separation between “international content” and “domestic content”.

If you include Telecom Argentina and Telefonica, our blended cost of bandwidth in South America is 68 units. If you exclude these two providers then our blended cost is 17 units.

Oceania Transit vs Peering (Last 30 Days)

Transit prices in Oceania (Australia and New Zealand) are lower than they used to be, but continue to be extremely high in relative terms, costing 17 times the benchmark from Europe, or 170 units. We peer 50% of our traffic, resulting in an effective cost of 85 units.

If you exclude Optus and Telstra, then the price falls to 17 units — because we peer with nearly everyone else.

Relative Cost of Bandwidth

CloudFlare has always optimized where we serve customers to take into account our effective costs. If you are a free customer using an excessive amount of expensive transit, we would serve you from fewer regions. The good news is that, over the last five years, we’ve been able to negotiate reasonable transit pricing or settlement-free peering with the vast majority of the world’s networks. That allows us to continue to provide the free version of our service as well as to keep prices low for all our paid services.

Today, however, there are six expensive networks (HiNet, Korea Telecom, Optus, Telecom Argentina, Telefonica, Telstra) that are more than an order of magnitude more expensive than other bandwidth providers around the globe and refuse to discuss local peering relationships. To give you a sense, these six networks represent less than 6% of the traffic but nearly 50% of our bandwidth costs.

While we’ve tried to engage all these providers to reduce their extremely high costs and ensure that even our Free customers can be served across their networks, we’ve hit an impasse. To that end, unfortunately, we’ve made the decision that the only thing that will change these providers’ pricing is to make it clear how out of step they are with the rest of the world. To demonstrate this, we’ve moved our Free customers off these six transit providers. Free customers will still be accessible across our network and served from another regional cache with more reasonable bandwidth pricing.

Ironically, this actually increases the cost to several of these providers because they now need to backhaul traffic to another CloudFlare data center and pay more in the process. For instance, if Telstra were to peer with CloudFlare then they would only have to move traffic over about 30 meters of fiber optic cable between our adjoining cages in the same data center. Now Telstra will need to backhaul traffic to Free customers to Los Angeles or Singapore over expensive undersea cables. Their behavior is irrational in any competitive market and so it is not a surprise that each of these providers is a relative monopolist in their home market.

If you’re a Free CloudFlare customer who cares about optimizing the best possible performance from one of these six providers then we encourage you to reach out to them and encourage them to follow a core principle of a free and open Internet and not abuse their monopoly position. We are committed to serving all our customers across every network that peers with us. To that end, help us convince these six networks to be on the right side of a free and open Internet by reaching out to your ISP.

• Ask HiNet to peer with CloudFlare in Taipei

• Ask Korea Telecom to peer with CloudFlare in Seoul

• Ask Optus to peer with CloudFlare across Australia

• Ask Telecom Argentina to peer with CloudFlare in Buenos Aires

• Ask Telefonica to peer with CloudFlare across South America

• Ask Telstra to peer with CloudFlare across Australia

We’ll post updates as we negotiate with these six networks and are hopeful that we’ll soon be able to serve all our customers across all the networks we interconnect with.

CloudFlare is excited to announce the launch of our newest data center in Perth, Australia. This expands the breadth of our global network to span 80 unique cities across 41 countries, and is our fourth data center in the Oceania region, joining existing data centers in Sydney, Melbourne and Auckland.

Perth is in a fascinating location. Home to sunny beaches and the highest number of self-made millionaires in the world, it is actually geographically closer to Singapore than to Sydney (though closer to Sydney in a “networking” sense, as determined by BGP routing).

Visitors to millions of websites across Western Australia served locally can now experience a faster and safer Internet - and ISPs can reach us at the Western Australia Internet Exchange (WA-IX), one of 119 internet exchanges that we openly peer at.

Latency in milliseconds from end user (Perth) to CloudFlare. Source: Cedexis

Helping build CloudFlare’s network provides our team members with the opportunity to not just speed up the Internet, but also improve our sense of geography. Visitors to our offices in San Francisco, London and Singapore can get a sneak peek at our fast-changing map (with live and upcoming dots). Perth is now “green” (live).

Network Map at CloudFlare office in San Francisco

CloudFlare now has data centers in cities beginning with most letters:A: Amsterdam, Ashburn, Atlanta, AucklandB: Bangkok, Berlin, Bucharest, Buenos AiresC: Cairo, Chengdu, Chennai, Chicago, CopenhagenD: Dallas, Doha, Dongguan, Dubai, Dublin, DusseldorfF: Frankfurt, Foshan, FuzhouG: GuangzhouH: Hamburg, Hangzhou, Hengyang, Hong KongJ: Jiaxing, JohannesburgK: Kiev, Kuala Lumpur, Kuwait CityL: Langfang, Lima, London, Luoyang, Los AngelesM: Madrid, Manchester, Marseille, Medellin, Melbourne, Miami, Milan, Minneapolis, Mombasa, Montreal, Mumbai, MuscatN: Nanning, New Delhi, NewarkO: Osaka, OsloP: Paris, Perth, Phoenix, PragueQ: QingdaoS: San Jose, Sao Paulo, Seattle, Seoul, Shenyang, Shijiazhuang, Singapore, Sofia, Stockholm, SydneyT: Taipei, Tianjin, Tokyo, TorontoV: Valparaiso, Vancouver, ViennaW: WarsawX: Xi’anZ: Zhengzhou, ZurichIf you know of a city beginning with any of the missing letters that could benefit from a faster Internet, please let our team know!

Photo sources: Daniel Lee (Flickr) and Cedexis

The genesis of our 33rd and 34th data centers in Auckland and Melbourne started a short hop away in nearby Sydney. Prior to these deployments traffic from all of New Zealand and Australia's collective 23 million Internet users was routed through CloudFlare's Sydney data center. Even for those in faraway Perth, the time necessary to reach our Sydney PoP was a mere 55ms of round trip time (RTT). By comparison, the blink of an eye takes 300-400ms. In other words, latency wasn't exactly the pressing concern. The real concern was a failure scenario in our Sydney data center.

Fortunately, our entire architecture starts with an assumption: failure is going to happen. As a result, we plan for failure at every level and have designed a system to gracefully handle it when it occurs. Even though we now maintain multiple layers of redundancy—from power supplies and power circuits to line cards, routing engines and network providers—our ultimate level of redundancy is in the ability to fail out an entire data center in favor of another. In the past we've even written about how this might even play out in the case of a global thermonuclear war. In this instance, the challenge we set out to solve was not how to fail gracefully, but how to fail gracefully without materially increasing latency for the millions of applications that depend on our network in the Oceania region.

Prior to our Auckland and Melbourne data centers, a failure in Sydney meant a shift in traffic to the West Coast of the US or Southeast Asia adding significant, and noticeable, latency to our users' applications (spoiler: it now fails over to Auckland and Melbourne with minimal latency!). But before we get to how the Kiwi's and Australia's "second city" saved the day, it is important to understand how the Internet "works" in Oceania. As we set out to create resiliency in-region, we considered several options:

At first blush a second facility in Sydney would seem to solve most imaginable failure scenarios (perhaps save a nuclear one). However, when it comes to the Internet, things are rarely intuitive. Australia, at least in the context of the Internet, is very Sydney-centric. The vast majority of traffic from Australia to the rest of the Internet passes through a single data center (which just so happens to be the same exact facility in which we are currently located). Even if we were to make a redundant deployment in a completely separate facility, traffic to that facility would still have to pass through the same potential point of failure: our current facility. Not to mention, a second facility in Sydney would neither reduce latency and improve performance for a larger subset of Internet users in the region nor localize our traffic any further than it already was. It also wouldn't have opened up any new peering opportunities which, as we've explained in a prior blog post, is of immense importance to the performance and overall health of our network.

Not enough redundancy. No performance gain from status quo.

Out of left pitch came Auckland. Although not an obvious choice, Auckland is rather uniquely situated to provide redundancy in-region as a result of how many operators have constructed their networks: by building or buying a 3 drop ring between New Zealand-Australia, Australia-USA, and USA-New Zealand.

Because traffic is only heavily utilized in one direction, towards New Zealand, this leaves a lot of free capacity between New Zealand-Australia (i.e. from New Zealand). After working with various providers, we've structured a solution that allows us to reduce latency and further localize traffic for Internet users in New Zealand while also allowing for full redundancy between both Auckland, Sydney and the rest of Oceania. Not to mention, CloudFlare is now a member of New Zealand's largest peering exchange, APE-IX.

Redundancy and performance gains versus the status quo.

But why stop there?

Despite achieving the desired level of redundancy and performance gains in New Zealand through our own version of the Trans-Tasman arrangement, we figured that both Kiwi’s and Aussies would prefer not to have the others' redundancy deposited at their doorstep. So, along came Melbourne as a complement to Auckland. Our Melbourne data center offers the same benefits of content localization and performance improvement for Internet users south of the border, as well as domestic redundancy in the case of a data center failure.

Latency improvement and additional redundancy.

Problem solved, right? Almost...

The Auckland fiber situation is an interesting one. Auckland is situated around a harbour. Over this harbour is a bridge which most of the fiber in the city runs across, with a small amount running via a much longer path around the harbour (think 30km longer fiber runs). Purchasing fiber between the areas of the city separated by the harbour costs more than a Kim Dotcom political party (i.e. a lot of money).

The bulk of the country's Internet providers (particularly the smaller ones) exist only south of the harbour bridge. The cable landing stations and many of the data centers, on the other hand, only exist north of the harbour bridge. If you are as performance obsessed as we are, you want to be south of the bridge so that you can peer with all networks in as inexpensive, resilient and easy manner as possible. But for us, the vetting process didn't stop there. The specific site we selected is the core node for most major New Zealand transit providers, allows us to interconnect with nearly every provider from within the same facility, and hosts a core node of the local peering exchange.

Now that our Auckland DC is live, some users in New Zealand may notice that their ISPs continue to route to CloudFlare in Sydney. That makes no sense you say!? We agree! Despite our best efforts, it takes two to tango. Should this be the case with your ISP, let them know...hopefully that will spark a conversation.

In the coming weeks, connectivity to CloudFlare in Australia is going to a new level. As part of CloudFlare’s ongoing upgrades program, we established connections to three new Internet exchanges: the Megaport Internet exchanges in Sydney, Brisbane, and Melbourne. These connections doubled the number of Australian Internet exchanges we reach and marked the first exchanges outside of Sydney that Cloudflare participates in.

When two ISPs peer, they agree to exchange traffic directly between each other rather than sending it a third party. By doing this, both partners avoid congested paths between transit providers, and they avoid paying to ship traffic—it's win-win!

What peering exchanges mean for CloudFlare is that we can significantly increase our service performance to users on ISPs that peer with us. Take Australia for example, for users who are currently on ISPs peering at Megaport, instead of CloudFlare sending traffic to the transit providers of those ISPs, we can now route the traffic directly to them. The result is lower latency, and traffic taking paths that are often less congested.

Low latency is crucial for internet speed due to the nature of TCP, the fundamental protocol on which the internet is built. TCP operates in such a way that any packet loss from a congested transit link will significantly slow a connection, and, conversely, connections with reduced latency will hugely amplify performance for end users. Therefore, by moving traffic to less congested, more direct "pipes" on the internet, CloudFlare is creating a faster web.

CloudFlare understands the importance of peering, and our team has put considerable time and effort into finding peering partners as our network expands. We peer as much as possible, both by participating at internet exchanges, and by establishing direct interconnects with ISPs.

As I write, we’re in the process of deploying equipment to many new data centers around the globe, and extending our network to reach more peering exchanges. In addition to the twenty-eight plus internet exchanges where CloudFlare already peers, we will soon be participating at: Terremark São Paulo, PTT-SP (São Paulo Brazil), EspanIX, FranceIX, MIX, NetNod, JPNAP, and, of course, Megaport. We’re also constantly commissioning new private interconnects with a range of eyeball networks.

CloudFlare is building a better web, and part of that project includes reducing the distance packets travel between you and your ISP. As the months go by, our network is expanding around the globe, and more of our traffic is sent through peering partners. The result? Faster and more reliable content delivery to our users.

CloudFlare's commitment to finding the most direct path over the internet to deliver your traffic, and, as the reach of our network expands, you can expect that our service will only get better.

CloudFlare maintains an open peering policy. Our peering details can be found here. Please contact us if you are an ISP on any of the IXs we participate in and would like to peer.

Over the next few weeks, CloudFlare will be significantly expanding our global network. In total, we'll be adding 9 new data centers and doubling the size of our existing facility in London. When we're done we'll have 23 global data centers and nearly 70% more network capacity. I'm excited to announce the first of these 9 new facilities just came online: Sydney, Australia.

We choose the locations of our data centers in large part based on where we can most improve network performance. Australia has been one of the problematic regions for network providers. In CloudFlare's case, traffic from Australia has been served from our Singapore or Los Angeles facilities. In either case, ping times were over 160 milliseconds. With our new Sydney facility, ping times from Australia and New Zealand are now averaging under 40 milliseconds.

The challenge of opening a facility in Australia has been the cost. Bandwidth is in the region is notoriously expensive. We talked with bandwidth providers for almost a year without much luck. Finally, Tom, a CloudFlare network engineer who happens to be Australian, suggested we watch the movie The Castle. After that, whenever we'd get a call from a bandwidth provider in the region, Tom would ask them, "How much?" He'd relay the price to me and I'd simply say, "Tell 'em they're dreamin'."

Anyway, the rest played out pretty much just like in The Castle. We eventually wore down the big, bad bandwidth providers. And, without having to kick anyone out of their home, we now have found one of our own down under.

The new routes are propagating now and all Australia and New Zealand traffic should be hitting Sydney within the next 24 hours. If you're in the region and the Internet starts feeling faster, now you'll know why. Stay tuned here for updates as we turn on the rest of the 9 new data centers over the next few weeks.