🚚 Central management for API Endpoints GA + Regional Services Expansion

Hi everyone, my name is Achiel. I'm here together with Reid. We're both on the product team and we have some super, super exciting announcements that we put out this week that we'd love to share with you.

So kind of maybe for a starters, Reid, I heard you launched something around APIs.

Before we kind of get into what you've launched, for those people that don't know, like what is an API?

Like if I had to explain to my five-year-olds or maybe seven-year-olds.

Yeah, so I work on the product team for our API security product and at a really high level an API is like a format that computers use to talk to each other.

And so one common example I like to use is if an end user is kind of like a customer in a restaurant and the application is like the chef and then the API is the waiter.

It's in between the API takes the message from the end consumer, gives it to the chef, in this case it's your application, whether it's food delivery app or any other type of app.

And then the API takes that information, returns whatever information they should return to the customer.

And actually today, now about 56% of all traffic flowing through Cloudflare's network is API traffic.

And if you look- Sorry, we have more like API traffic on Cloudflare than people actually visiting websites?

That's incredible. Correct. If you look like a year and a half ago, that was around 30%.

And one of the big reasons is that you might commonly think of an API as a way to communicate with a mobile app, but websites also use APIs to dynamically generate content.

So when I go and hit Cloudflare.com, instead of simply showing me a static page, the web page will be designed to look at who I am and then use an API to go back and fetch some content and give me a personalized experience.

And so yeah, now more than half the traffic flowing through Cloudflare is going through APIs.

Fascinating. So suffice to say that that traffic is probably pretty important as it actually powers your core infrastructure and offers you to offer a lot of business value.

What are the challenges that people run into when they put APIs into production, when they run them?

What are the things that people struggle with?

Yeah, I think there's two big challenges. So one is that an API is designed to take a request and return information.

And that means that it's, they're really high target for hackers because every API is going to return information.

It's a really simple and really fast way for a hacker to get whatever information they're looking for.

So like a login API would be ripe for abuse.

The really big challenge with APIs though, is they are designed to be accessed programmatically by machines.

So if you think of a website and you're trying to protect that website from an automated attack from a bot, you can do things to look at the request and say, is this request coming from an actual human user on a browser versus a bot?

In the case of APIs, there's no such thing as a human user connecting to the API.

It's always a machine. And so the ability of detecting what is a good machine trying to connect to your API versus what is a bad machine makes it really, really tricky.

Got it.

So I've heard some rumblings and I'll be honest, I'm also sometimes confused.

We have this product called API Shield and then there's API Gateway, which both kind of seem like they're doing API things.

But can you talk a little bit, what's the difference between the two?

Yeah. So we initially launched with API Shield, which you can just think of as API security.

And so if you look at Cloudflare, we have a lot of other security products.

This evolved out of customers using our bot management tool in front of APIs.

And for that reason, I just talked about earlier that APIs are designed to be automated.

Our bot management tool isn't perfect in front of an API.

So we built a specific tool that's designed for security on APIs called API Shield.

We launched that about six months ago.

And then right away, customers started saying, well, I also use an API gateway to manage my APIs.

So control who has access to my API, identify my API endpoints, maybe open and delete them, and then do routing on those endpoints.

And so we have started releasing features that allow you to API gateway type of things.

We don't have all of the functionality of a gateway quite yet.

So for some customers, if they say, I'm looking to replace my API gateway completely, we are not quite there.

But if you're looking for API management functionality, we have a lot of that.

And we do have hundreds of customers right now that are using our API management tools.

So what's the primary use case if people are coming to you now, right now?

You said you don't necessarily support everything that a normal full -fledged API gateway would be.

What are the main features right now? Yeah, so by far, the number one feature is we're in this unique position where if you're a Cloudflare customer, your traffic is already flowing through Cloudflare.

And that means we can really easily discover API endpoints that you didn't know even existed.

So if you're like a security team, you're trying to manage all of the API endpoints that are open to the world, what happens is your developers are trying to move really quickly and build things for your end customers.

And so sometimes developers just create an endpoint and they expose it to the world.

And maybe they think it's secure, but you don't know about it.

And so one example, we have a customer who's, all of their customers, the only way they interact with them is through APIs.

And we had initial call with them. They identified 25 APIs that they wanted to protect.

And then I had a follow -up call with them a few weeks later, and there was one person that was on vacation.

She joined the call and she said, oh, actually you forgot about six of our partner APIs.

So they forgot about a handful of APIs that were open just by one person being on vacation.

And so then we ran our tool, which is called API discovery.

We looked at all of the traffic flowing through, and we said, which of the endpoints look like APIs to us?

And we identified another 36, I think, endpoints that they didn't even know existed.

And this is a really- You're saying they only knew about half of the APIs that they were exposing.

Correct. That's crazy. If I'm a security engineer at one of these companies and I hear that we don't even know about half of the APIs that are open there, my head would explode.

Yeah. And we've had a few examples of that here with our specific customers.

But if you look at the industry analysts like a Gartner and a Forrester, there's a common term called shadow APIs.

And so this scenario happens really frequently where developers moving quickly expose an API and you don't know about it as a central security team and you call it the shadow API.

So that's by far the number one use case that customers use us for.

The second one is that when you find those APIs that are open, you want to be able to enforce a schema against that endpoint.

So what that means is you will only allow calls to your endpoint that meet really specific criteria.

And that protects you from a lot of instances of hackers saying, I'm going to write a script to blanket call every API endpoint I can find and see what I can pull information from.

And doing that through Cloudflare means that you can protect those endpoints at the edge, even if you're using another API gateway, and you can reduce the number of calls that end up hitting that gateway.

That's pretty great. That sounds very cool. So what is the big announcement?

What exactly did you launch this week? Or even better, can you show us?

Yes, I can. So let me share my screen. Can you see this window? Yeah. Okay, cool.

So what we just talked about, I said the two big features customer use our API discovery, which existed, this would give you a list of all the endpoints we found on your traffic flowing through Cloudflare.

And then the schema validation tab, which allows you to only let requests that match a specific schema go through.

What we launched today is a brand new tab called endpoint management.

And so this allows you to not only discover APIs and enforce a schema, but when we find those APIs, you can save all of them, go to this endpoint tab, and we allow you to do a whole bunch of different things.

So right off the bat, you can see for, we give you a list of endpoints.

And for each endpoint, we give you kind of high level metrics here.

So we'll tell you, we'll look at the amount of request traffic into your endpoint, and we will recommend a precise rate limit.

And so you can see here, I've got a list of 10 APIs, and each API endpoint has a different recommended rate limit, based on the usage we see for that endpoint.

What you can do is click this create rule button right here.

This automatically takes you to the WAF, which is a pre-populated rate limit that you can deploy.

And so you can make changes if you want, but if you don't want to, you can just click deploy, and then boom, you have a custom rate limit for that endpoint that's deployed and enforceable.

The other thing we give you is latency and error rate are two things that customers have said, I want to know if my APIs are healthy.

And the main thing I look at to determine if they're healthy is what's the error rate and what's the latency.

And so we give you right off the bat a step for all of your endpoints, and you can scroll this and see, do I see endpoints with really high latency or high error rates?

I don't have any here that are red here, but one thing we'll do is we use anomaly detection to tell you if we see a jump, a spike, either higher or lower in latency, or an error rate, this will turn red, and we'll actually give you an alert that says, we think you should look at this, we've noticed a change in one of the metrics we track.

So you basically kind of created an ecosystem here, where you just put Cloudflare in front of your APIs, you don't even know what needs to, well, you don't even need to be a developer, in essence, and we start just like monitoring which API endpoints exist, and you have this really cool feedback loop kind of where you can see like, hey, are things, everything is normal, but you can also jump in and increase your security posture by creating rules, but that's an amazing tool for security engineers.

Yeah, and if you look here, the main reason that we released this endpoint management tab is that here I've got 40 endpoints that I discovered, and customers would really often say, well, how do I know which endpoint I should look at first?

And that's where you can come in and you can filter on error rate or filter on latency, and it helps you prioritize what order you should look at the endpoints that you're monitoring.

And for each of these, you can also dive in and get even more metrics.

So at a high level, we will tell you our recommended rate limit for 10 minutes is 226 requests.

If you click in here, we will tell you how we got to that.

So you can see the P99 for this endpoint was 98 requests, P90 and P50.

And then we're also going to allow you to look at your request metric, your request patterns over time.

And so you can see, okay, do I have a really consistent request rate or does it fluctuate a lot?

And right now I'm looking at 24 hours, but you can change it to be seven days as well.

Same thing for error rate.

In this case, I don't have any errors on my endpoint. Same thing for latency.

The other additional metric we track that we don't give you at the high level is response size.

And so looking at the response size is also one way to tell, hey, if I have something that's got like a 500 kilobyte response, that's a lot of data for an endpoint to be sending back.

That seems suspicious to me. It might be something I want to look at to make sure that it's as expected.

And so our goal is that the end use of all of this is now you can go and look at APIs that are exposed via Cloudflare network.

You can really easily discover those automatically and then go and have one pane of glass to look at and see, are those metrics, are those API endpoints healthy?

And then once you find one that maybe isn't healthy or that you want to dive into more, then you can add our security features on top of that.

You can add alerting around latency and error rates.

And this should make it really easy to just look at the landscape of APIs that you've got exposed and then see which ones are more likely to need some help.

Very cool. Very cool. So what type of typical customer do you have?

Is there a particular industry or a size of company that this would be especially beneficial for?

So generally we see two big buckets of customer types.

The first one, I gave an example earlier where there are some companies that their customers pay them per API request.

And so let's say you're a data provider and so that your whole business is exposing information via an API.

Those kind of API whales are the vast majority of customers using APIs today.

That's where we started. But what I'm starting to see right now is customers who are a little bit newer to the API space and their APIs are not core to their business, but they're starting to expose information via APIs.

So think of a bank, think of anyone selling an e-commerce site selling a product.

Those are the two big categories I look at.

And I think the customers that Cloudflare tends to be helping more right now are in that secondary bucket where you maybe don't know which APIs you have exposed.

You don't maybe have an existing gateway. You're not managing APIs frequently.

And this is a really good way for you to dip your toe in and start understanding what APIs you have available and where you need to invest your time.

So I've been rambling here for like 15 minutes.

I know that you released something as well.

Yeah, but before we get into that, actually I need two small questions though for the audience.

One, let's say I'm a customer, I'm listening here right now and I'm super psyched about this.

How do I get started? How can I get my hands on it?

That is a great question. I'm glad you asked it. So log into the Cloudflare dashboard.

Under security, click on API Shield. And if you go here, anyone can go and then click and configure.

So if you're using API Shield today, you used to see three tabs.

You'll see this new tab right now. If you're not using API Shield today, again, navigate here in the dash, and then you can turn it on yourself.

Great. So this is GA today right now. What's next? Any sneak preview of things that are coming in the next couple of months?

Yeah. So you asked that question earlier about API Shield versus API Gateway.

And over the next several months, we're focusing on releasing more core API Gateway functionality that's in beta right now.

So things like token authentication, token authorization, and API routing.

Those are the things that are going to be coming up in the near future. Very cool.

Very cool. Looking forward to seeing those things. Awesome.

So thanks for asking me a bunch of really valuable questions. And so if we move over, I know that you are launching something related to regional services.

We'd love to hear about that.

But I know the first thing that popped into my head when I heard regional services is, is this like an AWS region?

Are we launching kind of a segmented big data center in one particular region?

Yeah. Really great question.

Before I get into what we launched, I need to back up just a second and kind of explain how Cloudflare works for the people that aren't too familiar.

So normally, when people think about computes, they just think about like, oh, you have a data center, and you have all sorts of machines there, and they have their own unique IPs.

So you have like AWS, you have a Virginia region, and there are machines there.

And if you want to route traffic to AWS, you have to actually route it to a specific region, because they have their own unique IP address.

With the Cloudflare, we operate on any CAS network.

And what that means is every single data center inside of our network, so all I think it's 270 plus cities right now where we're active, they all share the exact same IPs.

And inside those data centers, we run the same hardware, and every single box runs the same software.

And this is really great normally, because you want all of our capacity available to you, you want users to just always reach the closest data center, and get super quick service.

So that's been like fantastic. And many people love us for it. Increasingly, what we're seeing is that people can't always use that model.

So GDPR has been talked about a lot, and increasingly, we're seeing a lot of folks very kind of concerned about like, well, I kind of want to be put back in control over where data is serviced and processed.

So that's what regional services aims to do.

Basically, what we've done is we've created a product, we can still leverage our global network for DDoS protection, because everyone loves the fact that we have so much capacity.

So we can fend off those really, really large DDoS attacks that send gazillions of packets towards us.

We still use that, but we very strictly limit like where we decrypt your traffic.

So take WAF, or API Shield, or any of these cool products, they require Cloudflare to decrypt.

And that's very central, because when you talk to a lot of these people that are concerned about this, a lot of it comes down to like, well, the main thing I'm afraid of is a machine outside of my country seeing a decrypted payload.

So in layman's terms, and the way I always like to quote a German bank that we were talking to when we launched this was, as we can slice and dice and talk about all these rules and stuff all you want, as long as you can promise me that no machine outside of, in his case it was EU, will ever see a decrypted bank account belonging to one of my customers, I'm happy.

That's the only thing I really care about. I just want the data to only be inspected inside those machines.

So that's what regional services does.

It limits to a particular region where we actually decrypt and kind of apply all of these, what we refer to as Layer 7 or HTTP services.

That was something we launched in 2020, I believe, two years ago.

We launched initially for EU and US, because those are sort of like the two key areas where people were asking about this and had concerns.

But over time, we're increasingly seeing like the whole world kind of like waking up, like, I'm also kind of nervous about this and I want to create my own rules or own opinions over one of these things.

So over time, we've kind of started adding more regions.

And the way we prioritize is purely based off customer feedback.

If you have like an idea for a region or you're concerned about something, please just like come to us and we're happy to discuss adding more things.

The really exciting thing that I'm happy to announce that we're GAing today is support for India, Japan, and Australia, which are like the three most requested regions.

Those are where we see like customers, big and small, kind of asking like, hey, I'm happy with Cloudflare.

I just want you to only use data centers inside of my own country.

That was kind of a mouthful, but that's the long and short of regional services.

Yeah. Can I ask a couple of clarifying questions there?

So one is, if you compare to AWS, one of the benefits of Cloudflare is you don't have to go in and choose my code will run in these different regions.

We just automatically run everywhere.

Regional services, that still applies, right?

You don't have to choose to deploy in APAC. You don't have to choose to deploy in Europe.

What we're saying is that for customers who want to ensure that their data never leaves a particular region, regional services ensures that the data doesn't leave, but there's no additional configuration that customers have to do to say, I want to pick which spots my compute runs in.

Is that correct? Yeah.

We allow you to just specify on a per host name basis. You don't have to select individual data centers, none of that stuff.

You just kind of need to select which host names, which domains you want to regionalize.

So you can mix and match.

What we hear often is, for instance, that the marketing team doesn't really care because those are just like PDFs in general.

Collateral, that doesn't contain any sense of data, but then they want their APIs or the actual transactional data that belongs to the bank or the company, they want that localized.

So they can choose on a per domain or subdomain level, which one they want to regionalize and to which region.

And within the region, we just allow you to blanket select that one.

So EU would just get you all EU member states. If you want India, we would just like any point of presence or any data center belongs to popular inside India.

We would just use only those to decrypt and service your traffic.

And can I clarify? I know you said we launched some regions a couple of years ago.

We're launching a new region today. Which specific regions do we have? And then which are the ones we launched today again?

Yeah, great. Great question. So we originally launched in EU and US and then quickly added on Canada as we were seeing a lot of requests there.

And then this most recent additional region is Asia focused.

So like India is a really big one.

We're seeing a lot of interest there with the increased scrutiny from all over the place, Japan and Australia being the third one.

And then to clarify, if you're a customer in India, Japan or Australia, you can choose to ensure that data doesn't leave that particular country?

Or do we have one kind of region that encompasses all of those?

Oh, good question that I should be clear on.

Yeah, you can localize it to any one of those three. So if you're a customer in India, you want it to only get decrypted and serviced in India, we would do it in that country only and not in Japan or Australia or anything.

Awesome.

And I think you touched on this earlier, but why do customers care? I think the two things for me that come to mind is one, there might be regulation where you're not allowed to let data leave a specific country.

Is that true? And then I'm curious if there are any other ones that come up.

That's a really good question.

And when we started digging into this, we actually heard a lot of really interesting things.

So you would generally think that this is strictly just regulatory.

We've noticed that there are two other kind of buckets of customers that come to us.

The first, which was really interesting to me, is a lot of these people that care about this happen to like not care about regulations at all, but their customers do.

So they get contract language written into a certain contract that says like, we are only allowed to like service traffic and work with vendors if traffic stays within our country.

So they don't even care about any government or anything.

They just happen to have an agreement with another party, which was like a contract that was signed like 10, 20 years ago, whatever.

But they're stuck with the contract and they really want to use Cloudflare.

They love us for everything else, but they're just, they have this customer set of customers.

That's one.

The other thing that we see a little bit less frequently is people just not feeling happy about traffic leaving their country.

That one's a little bit more nebulous, but some people just like love that reassurance of knowing that the traffic will never get decrypted by a machine outside of, for instance, India.

So those are kind of the three reasons.

And it's not all like clear cuts where we just say like, well, this regulation or whatever, it's very much up for interpretation.

That's really interesting. I find the partner case fascinating. It's really frequent that we build some new technology and then we don't often consider a 10-year-old written contract to be a barrier to that adoption.

So that's super fascinating to me.

So then the next question then is what does it mean to use regional services?

Like what do you enable? Does it change anything from what I hear?

I think it's only a data thing, a data service, but yeah, what does it change if you're a Cloudflare customer today, not using regional services, both how do you turn it on?

And then what's the impact? Yeah. So this enterprise only feature, we might enable it on other plans in the future, but that's where we kind of see most of the interest with the large enterprises that conform to whatever.

If you are interested, please pick up the phone and talk to your account team.

We're happy to get you set up.

You can just easily on a per host name basis select like, hey, I want to regionalize this host name.

The kind of funny part here is that a lot of people would then think like, well, I'm going to lose a lot of performance benefits because all of a sudden I can't use all of Cloudflare's network to services traffic.

In practice, what we see is that for folks that care about this, all of their eyeballs, their visitors are already inside their country.

So like take the German bank I was talking about.

They don't necessarily care about the potential performance loss for someone sitting in the US because all their customers, their visitors are already in Germany.

So they're just happy. They just need that guarantee that the traffic will only get surfaced within their region.

Cool.

And then, so it sounds like it's literally just go in the dash, select a host name, say enable regional services, and then choose a region.

Yeah, that's it. And then if customers do that, is there any impact to them?

So the one thought I have is, you know, we go back to AWS regions and I know some AWS products only work in specific regions.

Does this work? Do regional services work with all Cloudflare products today or are only specific ones?

Regional services covers the vast, vast majority of all HCP-based services.

So I think I mentioned like bot management, WAF, like workers is also totally covered.

API shield and gateway are covered.

Where we don't have full coverage yet right now is kind of our zero trust product suite, which is something we're looking to do in the future.

But basically any like straight up HCP product will be covered.

And if you are interested in the exact list in the Cloudflare support portal, so support.Cloudflare.com, you can search for data localization suite and you'll get like a nice overview of exactly like the regions, products covered, et cetera.

Awesome. So if you're using Cloudflare for any HTTP networking, you can consider everything you're using today still going to work.

If for whatever reason you don't feel comfortable or you're under pressure from your lawyer or whoever to like not use Cloudflare unless you can regionalize, yeah, for sure.

Awesome. And I know we've only got a minute or so left really quick.

I assume we're planning other regions. Can you talk about like maybe what's next or what a schedule might be?

How Yeah, for sure. We'd love, our goal here is very much to have where data is processed, never to be a blocker for usage.

So we will happily like look into supporting and adding any region if there's like, if there are customers asking for it.

So if you do have a bigger region that we don't have covered yet, please do reach out to us.

We're happy to talk and add anything that you want.

And we have a lot more planned over the next three to six months.

Cool. And so it sounds like you're a customer, you want a region we don't have, contact your sales rep and that directly feeds into which regions we decide to build, right?

That's it. We're a customer focused company, so we love listening to feedback.

Awesome. Thanks so much, Akil. I think we're going to be gone in maybe like three seconds.

So yeah, thanks everyone for watching. Take care.

Great. Thanks everyone.