I didn’t know Amazon API Gateway did that

Eric Johnson: Excited about this session. I actually did this session or uh an older version of it in 2019. Uh, and we haven't really done anything since then on API Gateway. And so I'm super excited to bring this back. How many of y'all are using API Gateway now? Ok. Ok. Uh, uh, several of you. This is really exciting. How many of y'all are exploring it? Ok. Yeah. And, and using and exploring, check that out. Ok. Very cool.

Well, first of all, let me tell you a little bit about who I am. Uh, my name is Eric Johnson. I'm a Principal DA for CER uh, at AWS. I live, eat and breathe CERVI. And it's interesting when I came to work for AWS. This is five years ago. I just passed my five year mark. Um, and, and, and I wanna apologize right now. I'm gonna cough in the mic. I'm gonna try not to, but it's gonna happen. Sorry group, you know, I'm having the, the re invent flu, I guess is what we call it and that's what my wife calls it. It's just cold, whatever. But, uh, when I came in, they asked me, they said what's the most challenging service for you? And ii, i mean, it didn't take a moment. I was like API Gateway. That's hard, it's hard stuff. So they say great, learn it and teach it. So that's what I've been doing. I learned API Gateway if you, if you've ever seen it, i have two series out called Happy Little APIs. Uh at one point I even wore the bob ross wig. Happy Little APIs. So we had a lot of fun with that, but i, i love it. Um i, i've been a developer for 30 years. I'm a solutions architect for 10 plus years. I am an infrastructures code freak. I love, you know, i've been known to wear the sam squirrel costume. That's how much i love sam and those kinds of things. Uh i am a father of five that is not a typo. Uh and i am a drummer that used to say musician, but people were like really drummer, musician. Maybe not. So now it says drummer and finally i'm a foodie. Uh ho how many of y'all have heard me speak before? Ok, a couple of you. All right. Well, I'm sorry, you have to hear the rules again. Ok.

There are some rules when I talk because it rules is probably a strong term. But these are guidelines for you. Ok? So when I'm talking the first rule is this, this is any number I want it to be. Ok. I'm gonna hold this up and I may say seven, I may say 14. It's what I'm saying, instead of what I'm holding up. Uh, you know, this always gets me in trouble because I do. Everybody holds up and goes, oh, there's five of us. Oh, I'm the only one that can go. Oh, there's 392 of us. Ok. So I go into a restaurant and I'll say, hey, table for seven and I'm alone at the bar. So you gotta hear what I'm saying. I can get to four if I take my shoes off. But it gets weird for everybody. Ok. So we're not gonna do that. All right.

The second is these are quotes, not apostrophes and I know that. Ok? But this looks better than this. Ok? Every time I do this someone says is he doing a bunny? I'm not unless I am. It's contextual, right? And the final, final rule is these are thumbs because this will get you beat up. Ok? So that's what we deal with, right?

So those are the rules that'll help you understand who I am. I was not born. Um no, let me rephrase that I was born this way. I did not wake up this way this morning. That would be odd. That'd be really, you'd be like, man, he's really strong to be here to talk. I wouldn't be here talking to you. I'd be somewhere coping coping. Right. So I was born this way, I'm very comfortable with one finger jokes. However, if that makes you uncomfortable, I'm also comfortable with that. So either way I'm good, but I appreciate you caring.

So, all right. So let's just start, we're actually gonna cover quite a bit. And today, what this is, is this the literal title of the session says I didn't know API Gateway did that and, and, and it's going to be a laundry list of things that you kind of go. Oh, I, I didn't know or hey, did you know? So we're gonna kind of roll through these.

So the first thing we're gonna talk about is what is an API second thing we're gonna do is we're gonna kind of get an API Gateway itself to talk about some of the integration patterns and things like that. And the third is we're gonna get into these features that are beyond the front door when we think about API, excuse me.

All right. So let's get started. So, what is an API, well, a lot of you raised your hand for API Gateway, a lot of your exploits. So you probably know. But I wanna make sure that as we're talking about it that we're kind of talking about the same thing that we understand.

So API what it looks like without an API, it's kind of the best way we can explain it is if you don't have an API, then your client is usually trying to talk to your services directly. You know, SDK from the front end and, and there's some disadvantages to that. What you run into is you have possible overexposure, you're having to handle security at your client, at your services, things like that. All security is at the services. All routing logic is maintained at the client. So what you end up doing is you have to tell your client, oh you know, if you want this, you have to do this, this, this there's a lot of logic there and maintaining multiple versions of services can be complex and, and come on, we don't really do this anymore, but sometimes i see it. It's like why are we not doing that or why are we not doing this? When we throw in an API, this is this abstracted layer called the application program interface. It isolates the underlying implementation. It abstracts the contract uh into this layer. It reduces exposure to your services and it simplifies the interface, right.

So it's very common uh for us to have an API when we're talking and this is, and we call it the front door to our services. This is what protects our services. All right. So when we look at this, you see the the the routing here comes through and, and you hit your API and then the API knows based on the path, usually if it's a standard REST API where to route this to. And the nice thing about this is we can have a lot of different routes behind this and, and your client doesn't care. It just hits this one end point with maybe some, some, uh pathing in it. And it says, and you may point that to, to a whole different organization, but the API gives you this ability to say, hey, i'm gonna split that up and, and this is really handy when you have multiple teams building things. I can point it behind there and my client doesn't have to care. The contract remains between the API and the client.

All right. So when we talk about protocols for APIs, how do they communicate? All right, this is, this is, you know, protocols. It's what do they use to communicate? We have GraphQL, anybody using GraphQL now. Ok. Very cool. We have uh REST, REST is, is still the most popular protocol on the internet. We have web sockets that's gaining a lot of ground. Uh we have SOAP, that's actually an older, an older one. Anybody still uses SOAP. All right. I just want to apologize to you. No, I'm not apologizing. I didn't do it to you. I, I wanna feel sorry for you together. So, yeah, it's, it's rough, right? And then we have RPC and we have gRPC with API Gateway. Ok.

As we climb in and talk about API Gateway, we kind of limit those. Uh but we'll talk about some of the things that, that handle those. So API Gateway, if you're not familiar with it, like I said, most, you raise your hands, but just so, you know, API Gateway uh is, is our managed API gateway service. It is a front door, right? And, and we have several options when you, when you uh work with, when you want to build the front door, you can do a LB, you can do, do a Sync different things like that. API Gateway has a very specific specific service or, or purpose, right? And for us API Gateway is built to handle REST and web sockets. Those are the two protocols. And if you know, according to the the Postman State of the API report in 2023 86% of the internet still uses REST APIs. So it's still in use, right? So we're still using that. So we want to be able to handle this. It's a very common pattern. Excuse me.

However, if you are looking to use some of these other protocols, we've got you covered. Uh you can see AppSync will do GraphQL uh AWS IoT Core can handle web sockets as well as uh API Gateway. And I have some thoughts on that. If you're looking to kind of figure out how you want to do it, uh your your web sockets, talk to me. Uh but it basically comes down to this, I'm gonna give you in a nutshell. API Gateway's web socket is, is, is all the tools are there for you to build your own implementation. You can get really customized with it. Ok? So a lot of our companies are building like SAS and things out of that IoT Core. On the other hand, is like boom, there's a box, here's everything you need, you can use it, right? So there are two different purposes. One is to just kind of have out of the box ready IoT or web sockets that handles your topics and subscriptions and things like that. The other is build it yourself. Here's all the tools you need, right?

So, well, if you look at Serverless Land or Serve Video, the two products that our team has built to kind of show uh event driven architecture. We use web sockets because it has everything we need out of the box. I'm sorry, I didn't mean web sockets. I meant IoT Core for our web sockets. And finally, if you want to look at, you still need to handle SOAP RPC or gRPC, you can go to an Elastic Load Balancer.

So there's two types of Amazon API Gateway APIs and we've had people say flavors versions, different things like that. Now I'm gonna be right up front with you. Sometimes the names are a little confusing. Ok? But here are the names we have our REST API which is a REST API and the protocols are REST and WebSockets, we have our HTTP API, which is a REST API everybody with me and it uses the HTTP API.

Now, really, if you think about these, the, the REST API is more of a full uh feature of service. So they're a little different, but both are HTTP based APIs and this, I know this is, can be a little confusing. Uh so, but they're, they're both HTTP based. Uh we just call them two different names. So as we go through the services, some of your services or some of the features and things like that will be supported by REST, some will be supported by HTTP. Some will be reported by both.

So I've created a little kind of a legend at the top that will show you as we're going through there and, and, and i usually refer to it, but if you don't see it, you can look up on the top uh right, and it'll tell you which service supports this. Uh every once in a while you'll see an asterisk and i'll, and i'll call that out. All right. So continue to talk about a uh a Amazon API Gateway. Let's talk about some of the types of APIs you can build.

Now, I think this is somewhere where people get a little confused. So i'm gonna try to clear this up. So the first thing we have is what's called a regional API and this is supported by both REST and HTTP. And in reality, all APIs are regional. Ok? They are spun up in a specific region. This API is in us west two eu west one, whatever, all APIs are regional. That's how we do it. Ok? But we'll talk about, we also have a thing you can see here. This is the, the like i said, this is the regional API, this allows you to, I mean, you can have.

So, so this shows here, it says this is applications and services in the same region can hit this end point, but it's not limited to that. I want to be clear. It's like, well, I'm sorry, you're outside of the region. You can't talk to me. It just means they have to go further. So if, if this is a us west two region and you're calling from frankfurt, germany, it's a little bit longer of a call, right? So you kind of want to move those APIs closer to your clients, right?

And so for that, we have a thing called the edge based or edge optimized APIs. Now, this one, i really want to take a moment and explain. Now this is an REST API only. Now what this does is it creates a CloudFront distribution network for you. Ok? And you're like, wow, it's great. It is great. Ok? But here's the thing what it's doing is it's, it's bringing what we call POPs or point of presence closer to your client.

So if i using an edge optimized, it'll be on top of a regional API. So my API will be my API end point might be in us west too. But if I'm in frankfurt, germany, it will call that closer point of presence, then it'll route through the amazon backbone. Ok. It doesn't move your API closer. It just gets them on our private network much faster. So they're not going through the network. So hopefully that makes sense.

But what i want to point out is this again, this is API Gateway manage CloudFront. It's edge access to the Amazon network, but it does not include edge based caching. I think this is where some people get confused, right? So the caching, you can add caching, you can and, and we'll see it in a minute. You can do API Gateway manage caching, but that is, that's regional, ok? It's not a CloudFront if you want CloudFront caching at the edge and most likely you do, ok, then you want to do your own CloudFront. Ok? It's not too terribly hard to set up and i've got some examples of it. Um but what you do is you tell you set up a regional API end point and you say i, you know, i want this regional API end point and then i'm gonna do a CloudFront distribution and i'll put that regional as my origin for that. And then i can have and it's kind of transparent because it says, ok, i'll read the caching headers from the API Gateway to set the caching the time to live different things like that in CloudFront. And that way you have number one, you have caching at the edge and number two, you have points of presence at the edge. All right.

So that's really important to understand where this comes in really handy. I mean, you're probably looking at why do you even tell us about this eric, where this comes in really handy is if i need an API that i can't cash, the data is too hot, right? I can't cash that data because it's constantly changing. But i need to get them on the network and get them to this as fast as possible. And i don't wanna sync that data all over the world. This comes in really handy, right? So it it doesn't cash it, but it does get you quicker access to the endpoint. So hopefully that makes good sense there.

All right. The next time type of API we have is a private API. Now, this is not to be confused with the private integration. We'll talk about that in a moment. A private API is specifically to say this API is only available to people in, in a VPC. It locks it down. I can't just go to the internet and hit this API it's locked down with resource policies uh inside the VPC. And so this is what a lot of companies use internally to talk to each other and, and to pass data around again, not, not uh should be confused with the private integration, which is a feature that we'll talk about in a little bit.

All right. So we're gonna pause for a minute and i wanna talk about RPS and burst. This is this. I have seen so many people write documents on this and explain this and 99% of the time, including some of the ones i've done in my past are wrong. This is a hard concept to understand or i'm hopefully i'm gonna clarify it, ok, when we talk about and, and we'll talk about burst and caching and things like that a little bit later. But i want to do this early to kind of make sure we understand it as it applies to some of the features of things we're talking about when you use API Gateway REST or HTTP you use, you get a cash and a burst. I'm sorry. Now, I'm just making up things. You get an RPS which means request per second and you get a burst, right?

And so there's some the, these are two different things. So, and, and the hard coach, let's, let's bring this in here. The burst is the number of concurrent starts. API Gateway supports, right? And it has a hard maximum of 5000. Now, it's important to understand that this maximum is for all API end points within a region within an account, not for one API end point. So if i've got 33 production business, API end points and one in the account, i'm throttling myself pretty hard. Ok.

So, and, and, and if you want to talk to me outside sometime we could talk about how one production per one account is a really good idea. Ok? But so this so burst is how fa how many concurrent. And again, i wanna, i wanna stress this is concurrent. That means if all these requests came in at the exact same millisecond, we can handle 5000. Boom right off the bat. Ok?

Now the next part of this is what we call the RPS. Ok? I drew this pipe myself. I'm pretty proud of it. Ok? The, the RPS is the speed API Gateway refills the bucket. Ok? And it has a soft max of 10,000. Ok. So what happens is back to our scenario. If we have 5000 requests come in immediately, then boom, those are gone. Then API Gate was going, ok. Phil more in phil more in and it can do up to 10,000 in that, that includes the original 5000. Ok. So over a second, you can only do 10,000 per second, but you can handle 5000 at the exact same time.

A lot of times i see people configure this so that they say, ok, we're going to set our max or RPS at 5000 and our burst at 10. Well, that doesn't make any sense because why we may be able to handle 5000 at the same moment we're on or, or why we set our burst. First of all, that's over our max, right? Your burst should always be less than your RPS. Ok.

So, so just keep that in mind. So your burst should be, that's how fast we can handle at the same time. RPS is how fast we can fill it. Hopefully, that makes sense. Uh this is, it was really funny as i was digging through this, i had to go through and get a lot of people opinions like, ah, and i went back to one of the guys who actually built this. I said, is this right? He goes, yeah, that's right. So, ok, because i've got it wrong a lot. So you're getting it right until next year i go, yeah, i had it wrong. No, i'm saying this is right. So, ok, so that's, so that's important to understand as we start walking through things.

All right. So we're actually gonna, as we're talking about, it's still part of API Gateway when we talk about integration types. All right. So the integration types in API Gateway, there's, there's five different kinds, right? You have the Lambda function, you have the mock, you have a VPC link, an AWS service and an HTTP. So let's look at what these look like and, and it's really funny you're like, ok, i have a Lambda function and i have an AWS service. But hold on. Wait a minute. Eric lambda is an AWS services inl. So there's two different ways to connect to a Lambda function. So let's talk about that.

So the first connection we have is a Lambda function, what we call a proxy. And here's how this works when a client makes a request to an API Gateway and it is using a proxy. What we will do is we will take the context or we will take the data in the body, we will wrap some context around it, right? Connection time, connection requests and different things like that that API Gateway throws in there and then we will pass it to the Lambda function and we will give them the event which is all the pertinent data that came in on the request and we will give them the context, right?

So what happens is when we return this? And this is really important to understand is this is sent back and API Gateway doesn't do anything to it. It literally says, hey, here you go. So that means that you have to set the the your headers, your header names, your status code, things like that in the integration in the Lambda function behind the scenes or behind as the integration. So that's important to understand.

However you notice this is supported by REST and HTTP APIs or the HTTP APIs but HTTP has a little asterisk there. So with HTTP, let's let me stay with me HTTP has the ability to do a second payload. We, we have two types of payloads. One is kind of our older version which matches REST and two is our newer version. If you're using payload one, then it's gonna work just like REST API. But if you're using payload two, then it actually uses some, i'll say magic, but some algorithms to figure out your status code, your headers, your things like that HTTP I will handle that for you and, and pass that through, but it still doesn't affect the body. You can't change the body at the API Gateway level and you may be looking at me going Eric, why, why would i try to change the body? Well, we'll get into that in a little bit because you can do some fun things with REST and with HTTP or API Gateways, right? So that's under, so that's the proxy.

Uh so if you go in here, uh so this is the HTTP API like i was saying, if i use payload version two, then if i just kick back the text, this is my response. Hello from Lambda. The HTTP APIs will know. Ok. Well, this is the status code 200 because i got a 200 from the Lambda. I'm gonna go ahead and wrap the body and make, you know, take care of that for you. I'll pass any headers con you know, it takes care of all that for you. So it's really cool. So, so if you're just building a simple API HTTP API is probably the way to go. In fact, my general advice is, and, and, and i want to be real careful this because sometimes migrating can be kind of tough. But if you don't ever think you're gonna need the features we're talking about start with HTTP API. It's cheaper, it's cheaper and it'll work great. Excuse me.

All right. So let's talk about a Lambda function direct integration or as an AWS service. Now this is where we can get really fun and we can do some cool things, right? So what happens is when a request comes in, we can then apply what we call VTL or Velocity Templating Language to the request. That means we can change that. We can transform that request even in the body, the headers, whatever. Now this is REST only.

And then the, so you can see the transformer request looks much different than it goes to the integration in the lambda function. Lambda function kicks out a response and we can change that as well. Ok? We can add to it, change it uh uh modify things. So if we have multiple backends, we need to add a header that always comes out regardless we can throw that header in to do all kinds of things.

So that's a direct integration. However, you know, it, it takes a little configuration. Uh VTL. I'm not gonna lie. It's not necessarily for the faint of heart. It, it can be anybody doing VTL now. Ok. Do you love it? Ok. No, I heard a strong no down here. Ok. Yeah. Yeah. Yeah, it's, it, the thing about it is that we'll talk more about it a little bit. It's, it, it's, yeah, it's interesting.

All right. So that's, that's a proxy. So here's what a VTL transformation looks like though, just so you can see it. Uh you say, ok, your first name is John. This is the request coming in. First name John, last name Doe got a phone number, got a city, got a state and then a favorite pizza, which is actually incorrect because pineapple should never be on pizza, right?

So that comes in. So what we're gonna do is in, oops, in our, in our transformation, we'll go ahead and, and combine the name, we'll, we'll break the address out, fix that up and then we'll correct the answer they gave wrong for the pizza, right? And we'll change that to pepperoni. So you can modify that as it's coming through, through VTL. Ok.

All right. So if you take that same thing now, you probably wouldn't do that with a Lambda function because that's compute, right? And you could do that all in the compute. It's like, ah, you know, why do we do that? But here's where it gets really cool. Ok. You can apply this to AWS services and DynamoDB is a really good example, DynamoDB is an API endpoint, right? And so I can, and, and API Gateway, I will take care of my signing and all the headers and stuff like that to talk to DynamoDB.

So I can transform a request that's coming in. I can write it directly to DynamoDB. I can also read directly from DynamoDB. I can make a request and get data back because VTL lets me take that and transform what that looks like so that can work, right? And so we do this, anybody play around with ServeThisVideo or seen that yet. Ok? A couple of you, all right.

So ServeThisVideo. If you want to grab the QR code, it's also at s12d.com/video. We do a lot of this and this, this is a new project we built to kind of show how event driven architecture works. And so we're using ServeThisVideo. And so I'm gonna show you some examples of these, the, the VTL might be kind of small, but I've got them blown up after I'm gonna show you the whole thing.

So first of all this is an example of a request coming in for maybe a video. Ok? So you can see here where I've gotten using VTL, I've got some power to, to, you know, I can do some looping, I can do some if thens uh I can do all kinds of things to, to change the, the uh request and this is the response itself. Uh and I'll blow that up just a bit. You can see here uh if the root uh has the last evaluation in, in this particular example, I'm adding uh this is pagination from DynamoDB. I'm looking to see if it has the last key and if it does, we'll pass it through. And then I'm also doing some looping to say, ok, however many of these you send back to me, I'm gonna loop through and structure my data accordingly, right?

So now you can kind of see, yeah, VTL may be hard. You're like, ah why would I do that with a Lambda function? But if I had to build something and, and if you remember just a moment ago, I said s12d, that's a URL shortener that we use at uh in our service team. And actually all over Amazon, now you probably saw it in, in some other uh presentations. That particular application is nothing but API Gateway and DynamoDB, we use some, well, that's not true. We use CloudFront and then we use some streaming off CloudFront, there is no compute, we're routing even the authorization, we're handling it all in there and it is wicked fast and it is wildly stable because we don't ever update code.

And let me tell you something, the most liable frail part of an application is Eric Johnson's code. Ok? My, my business card says Principal Developer Advocate, but that's because they said that what they had to call me. Really? I'm an architect. I'm a hack developer. You don't want me, if you have me developing for you, you're pretty desperate, right?

So this idea is I'm able to build this application. I built that the whole s12d I built that as a proof of concept. Hey, can it be done? Yeah, it can be done. Uh so just some things to think about. I'm not saying you should all go out and build everything in VTL now, but just think about the power. Ok.

All right. So this is REST HTTP also has the ability to do some integrations. These are custom built into HTTP, it's just these five services, but you can directly connect to the AWS AppConfig to Amazon EventBridge. You want to drop stuff on EventBridge. Uh Simple Queue one of my favorites is the Step Functions. I can connect API Gateway directly to a Step Function and uh I can do a sync or async uh launch of that Step Functions and I can do a lot. I, I love Step Functions. That's my go to before I even use a Lambda function. I use a Step Function. If I need a Lambda function, I have the Step Functions invoke it. And then of course, Amazon uh Kinesis, if you're doing a front end on that and with HTTP API, you get some power for transformations, it's actually done. Both. You can do parameter mapping where you can actually take and override existing values. Uh it is not as powerful as VTL, but it does give you some of that power to do that. And again, this is also supported in REST or HTTP. Ok.

So the other type of integration that we have is the HTTP integration. What does this mean? This means that basically you put your Amazon API Gateway endpoint, this is REST HTTP in front of anything out in the wild. This is kind of cool because we had, I had, before I was working at AWS, I had a company that needed to hit uh uh Google location, right? But we needed to kind of, we need a base what we need to stay within the parameters of what Google wanted to stay in. Uh and so we needed a proxy to. So we used API Gateway. And so my folks put, you know, like, you know, my comp or you know, it was like navigation.mycompany.com and then it added any security headers I needed to it and they sent to and using throttling and caching and different things like that and, and, and uh API keys I could minimize, I could, I could stay within all the, all the licensing that we need to stay in. So this was a proxy and you can proxy all kinds of things with this.

Um we're doing something really cool with some of this video where we are calling out to, uh we're calling out to uh Adobe to do updates to an image and they're sending it back to us. I think we're actually gonna build and use this as a proxy because we want to keep that internal. We don't need everybody knowing our imports. So it's a good way to do that.

All right, mock integration is the last integration we're gonna talk about. Uh the mock integration is super cool. This is just literally uh and this is supported uh just by REST. Uh well, we'll get to HTTP in a moment and this allows you, you don't need an integration. This is great for preflight if you're using the, you know, you need to do an OPTIONS response. Uh you can do the and a lot of we have some, some checks and buttons in API Gateway that will actually automatically do this for you to set up the mock integration. But it means you don't have to do anything to it. Uh you don't have to have an integration behind it. You can just say, hey, if someone calls for this option, you respond with these headers and, and, and this, you know, to allow and then you know, to basically take care of CORS.

So let me take a pause for a moment. I said this several years ago and it's been well quoted, but I'm gonna say it again today. If CORS had a face, I'd punch it in the nose. I'm dead serious. Raise your hand if you love CORS. Yeah, a bunch of him. Oh, no, no, no. I'm like there it is. He loves CORS. CORS is hard. And that's, you know, we, we wanna blame API Gateway, we wanna blame our, our API stuff, but it's a browser thing, right? It's a force at the browser and it's hard.

Um so we do our best to try to help you. If you struggle with CORS, I built a tool a while back. This is a shameless plug, but it's called cors.cland.com. And you tell it your CORS needs, it'll generate all the same for you for your deployments uh to, to do your CORS for that. Uh because yeah, CORS is just uh I'd rather go to the dentist than configure CORS. So, all right.

So mock integrations helps you with that. The same thing in HTTP API. We have a mock preflight and what this does is based, it kind of evaluates based on what your Lambda function is doing and things like that, it will create that you don't actually see it, but it will create the mock response for you HTTP API kind of just does a lot out of the box for you in that respect.

All right. So I said earlier, we talked about private APIs. This is that private integration. Ok? And what this allows you to do is is things like the things that are in a VPC, you can still connect to using API Gateway. Now, sometimes you need a VPC link and a network load balancer uh to connect to it. And, and so your API Gateway through a VPC link connects to network load balancer and then you can connect to ECS or EC2, anything in there even including direct uh direct connections to your on premises. And this is really handy because you can keep your stuff in a private uh in a private subnet in your, your API or in your uh VPC, you can tell I do service, I, I can't even spell VPC. I rarely have to work with them. But sometimes uh and so when, when you have to do that, your API Gateway can connect to that.

What's really cool is with the HTTP API. We did the same thing. Yeah, we're gonna let you do that but you, you can actually go directly to an application load balancer as well, including a network load balancer or you can use the AWS Cloud Map, uh which is really handy if you're trying to connect to uh container instances uh behind that you can do some filtering. Uh there's a lot of power built into that. Ok.

So that kind of covers the API Gateway, what we're used to the integrations. Now, I wanna climb into API Gateway beyond the front door. Excuse me. And these are, these are features that when I tell people this they go, I had no idea and these are the features that really honestly make API Gateway worth it. I mean it does a lot before that, but these are the ones that you go. Oh ok. I yeah, I should be taking advantage of that. Yeah, you should. Right. So let's jump into these.

All right. So the first one is authorization. Ok. This is pretty simple. Hopefully y'all, y'all, y'all are doing authorization. What we see a lot is we see pass throughs that the people are handing authorization at their, at their actual servers or at the integration and that's really not needed. If you run your authorization at your API endpoint, then you're doing it one time and you're not having to do that at every endpoint. So you want your authorization to happen here.

There's multiple types of authorization obviously open, which is not really a type of authorization. I guess it's a type of not authorizing, right? You have IAM permissions that's usually a service to service. Uh if you're passing a signed, you can, you can do it from a client too. A, a signed signature, signed, signature, a signed uh certificate.

Amazon Cognito authorizer. This is not the same as IAM with OKTA. This is kind of a custom built thing. It's Amazon uh uh Cognito authorizer.

And finally, Lambda authorizers, these are custom authorizers. This means I can really do anything I want in the Lambda function to make sure. So if I have some type of custom uh thing, I can do that if I want to do an LDAP or something like that, I can do it in a custom Lambda authorizer. That's just for REST for HTTP. That changes up a little bit.

We also do OpenAPI, which means anytime you're in API Gateway, you don't have to authorize, but I, I wanted to show that. So you have it.

Um IAM permission, the same thing, but here we do a legitimate JWT authorizer so we can do that. We can, you can have your, your known uh endpoint, you can have you, you know, you pass your JWT token, we'll decipher it for you and, and you can, you can set your scopes and use that at the API endpoint. So you can pretty granular with that. It's really slick.

Um and then of course, Lambda authorizers as well. So I really encourage you if you're writing and I see this all the time and you raise your hand if you're a developer, ok? Almost the entire room you're all guilty. But developers like I can do it better. I'll write my own authorization system. Come on. It's been done. If that's what you're going after. That's great. But don't get lost in that when you're building applications, right? Do your authorization here, let the system handle it for you.

And so, you know, now I'm not saying authentication. Ok. So in the difference there, I it's just, I'm sure you all know this, but I'm gonna say authentication means are you who you say you are? Right? So that's yy, you know your, your authenticate three AWS or a, there's a lot of things, authorization says you are who you are. But do you have access to this? Right?

And so you, you wanna use the system or use the built in stuff? Don't try to write it on yourself. There's, there's really no need to, I guarantee you it's experts that have written this. Uh so they don't let me touch it if that gives you any comfort. All right.

A second thing here. Let's talk about caching. All right. So we already kind of covered this earlier. API Gateway actually has its own caching built in, right? And where this gets really handy is it's effective for quick responses in within a region, right? You say, look, I wanna cache some stuff within a region.

Uh and I guess where this really becomes handy is API Gateway manages the whole thing. In my opinion, if you don't want to manage it, this is the way to go. If you're willing to manage it, go to CloudFront, this will spin up a cluster of, of cache objects and, and uh yeah, and, and it's perfectly helpful and it handles that all for you. You want it out of the box, that's a way to go.

Uh but there is an hour, hour cost based on the cache and cluster size. You can get just as granular in CloudFront, but you can do it at the edge at that point. If you're caching, you may as well do it at the edge. That's my opinion. But it does do caching for you if you need it.

Default throttling, throttling is fun. Ok? Anybody. All right. See bunch of you work with API Gateway. Now, have you set up your throttling? Ok. All right, good. You can leave, you know, everything we need to know. No, I'm just kidding. Ok. Throttling. This is, I'm, I'm kind of glad to see. Not a lot of people raise your hand when we get out of this session, go right to your uh uh hotel and fix your throttling. Ok. That's how important it is. All right.

Throttling is a really interesting thing. All right. So we talk, I, I alluded to this earlier. I actually said by alluding. I mean, I actually said it, you have a 10,000 RPS soft limit. Ok. And that works for most people. If you need more than 10,000, I'd be interested to see what your, what your patterns are and stuff and it may happen. I mean, if you're, if you're like, look, I, I run Netflix, you probably need more than 10,000, right? Um, but you're like, I run my mom's blog. Maybe you pat maybe you architected that wrong, you know.

Um but uh yeah, so 10,000 per second, that's a soft limit. Well, that can be raised. 5000 is a hard limit. It's shared among all, like I said, it's shared among all endpoints. And I want to put that up here so you can see it. But this is a customizable thing. Ok? So let's say we want to apply this, we can apply this to a stage, we can apply it to a resource, we can apply it, apply it to a method, it can get very, very granular, right?

So, what we might do is we might say, look, uh I'm gonna give uh you know, 8000 RPS and 4000 to my gets on my, in my order. Ok? To orders. But I'm gonna give full 10,000 with a 5k burst to my uh uh to the post of that because I want people to be, I want people to be able to make orders. I don't need, I don't care that my sales people can't see the orders. I want people to order. Right.

So you start prioritizing who gets this? Now, this is all under the umbrella of the default limits of 10,000, 5k. You can set 30,000 on your gets or post. It won't go over 10, right? And remember that it's per API so how you start breaking this down is you can get into custom throttling and it can look like this.

You may have a free group and by using API usage plans and an API key, you could say, look, my free group only gets 808 101k 1k. So remember I'm not going over but I'm matching my burst because it's so low. I'm matching my burst to my request for seconds. But my people who are paying, they get priority. So I'm gonna throttle my free group in favor of my subscription group. Ok.

So by doing this, remember I said, go home and fix your throat and maybe you don't have to right now. But this is just good API hygiene, understanding the workload and the access patterns of your application is really critical. And so by understanding that and saying, look, uh you know, we, we want to make sure we throttle aaa reports API that just our sales people hit, we're gonna throttle that down to make sure that a a point of sale API is, has just all kinds of room. Right. And that by doing that you're able to probably make better use of that 10,000, uh, RPS and your 5000 burst.

So, throttling is a fun game. Uh, and, and you may not get it right. The other thing I really encourage you and we'll talk about metrics and stuff a little bit is metrics. Get your alarms set up, know when you're throttling, right? Set that up. Ok?

So next thing we're talking about is stages, anybody using stages in API Gateway? Ok. All righty. Do you love them? Ok. You do? Ok. All righty. I'm not a big fan of them. I'll be really honest. I don't, I now with some of the things and I'll explain it in just a minute.

Um but let me tell you what it does first. Ok? So a stage allows you to, you can have like a prod and a stay and a beta and an alpha or you might have a b one v two. These are great ways of, of maintaining multiple versions of the same API, right?

So you can just excuse me and you can point them to different integrations on the backside based on uh stage variables actually. And that looks kind of like this. So I may have a stage variable that says lambda alias equals prod. So I'll have an alias in lambda function that says prod. So it'll point to that and then the alias in the lambda will point to a specific version.

Now this gets a little complex to be really honest. So I'm gonna give you another kind of another story on that. My opinion is don't use stage or stage variables if you don't have to. Ok. There's a very good reason for them and we use them under the hood for some different things, but if you don't have to don't use them because they become kind of a maintenance nightmare instead one and I said this earlier use accounts per per environment, right?

So instead of me supporting my dev beta and production all of one account, I'm gonna break it into. I have developer accounts, especially with service. It's all ephemeral services, right? Unless you're using a database that you could share in or something like that, then I'm gonna have a, I'm gonna have a alpha account of beta account, whatever.

So number one, I'm getting an extra level of security that's just inherently built into accounts. Only some, only three or four people have access to production account, they're the people that can deploy it. So not everybody has access to these accounts. So it helps lock that down, right? Ok.

Here's the other thing that I would use instead of trying to maintain stages, I would use custom domains with custom base path mapping. Ok? So how this works is I can say I can, you know, I can use i've got my custom domains. I can apply SSL cert to it. And then I can use base path mapping to build out to a v one a v two, a prod a beta. However you want to do, but I, I can point it to different accounts or I can point it at least to different regions or different stacks at the very least. So I'm not maintaining in the same stack, a bunch of different things. This gives you, this takes away a lot of management headache. Ok?

And we built this in, we have custom remains and we have multilevel base path mapping which allows you to, to just really dig that in. All right. So earlier I talked about and you know what, somehow I think. So my slides got reversal. I wanna go here next, just looking at this. Ok. So this is the base path mapping that goes with logging or I'm sorry, how are you doing that goes with custom domains. So you can see here, I can point them to like route v one, route v two, reports, different things like that. So I may have different places. I want to point them and they can be different endpoints on the backside, but still all under the same custom domain. And you can see how that breaks down. You've got your custom domain, your base path map, that's at the domain level, your endpoint map, which that's on the endpoint itself. And you can see how that combines to make a full location.

All right. So let's go back. I'm not sure what happened here, but it's, it's me not the, not the powerpoint people. So let's go back to logging. So here's a really interesting thing when I sit down with companies before I came to, before I did this here at AWS. I was a, I was a solutions architect for Rackspace and we would go in and we sit down with huge companies. We talk about them and I would have the kind of story I'm telling you and I would say, what does your logging story look like? Oh, yeah, we, we log everything. Oh, ok. That's great.

What do you do with it? We like we like it. Ok. What do you do with the data? We save it, drop it in S3 bucket. Oh, it's great. What do you do with that? Well, we take it to cold storage after a while. Ok. What do you do with that? You see him get mad. We save it. I'm like, do you investigate, do you have metrics set up? Are you getting the story from your application?

And this goes back to our throttling and our caching and all the different things we're having to keep a healthy API. You have these metrics that tell you the story - metrics like, hey, I'm peeking out repeatedly or hey, I'm dropping request. I'm getting a lot of 42 nines. Why does that happen? Right.

So by setting up these loggings and using the insights and using the metrics that can send out and notify people. This is really critical. So I encourage you use the logging that's built in use that you can see here the custom log formats. Uh there's just a lot of, of ways you can log, but I just, I encourage you if nothing else cloud watch with metrics and then build up on that.

Alright. So we jump ahead a little bit here. So next thing we're gonna talk about is canary releases. Anybody use canary releases so far, right? This is a really cool thing. A canary release says, hey, I can set this up so that while you're running to prod, I'm gonna create another stage. Remember I said earlier, we do things in the background with staging stuff. There's a purpose to it. I'm gonna create another stage or version that says canary and under the scenes, I'm gonna route 5 10 20 30% of your traffic to that. And according to your metrics, when you like it, you go ahead and say promote. And then what happens is we delete the canary, we promote the latest version to production and you're up and running.

Now. Here's the interesting thing here. You want to use this for API Gateway configuration changes, not necessarily for code. Ok? Because what happens is this is this really is free for code. There are some blue green things you can do with Lambda. Uh that, that actually happen at the Lambda function level, right? You can use this for code, but there are some other ways to do it. But if you're making API Gateway configuration changes, you're adding domains, you're adding search, you're adding whatever you can do that using a canary. Uh but it does, it does require a manual promotion so you can watch your metrics. You get a manual promotion off, you go. So that's a car and a release.

Like I said, once everything goes, it pops over and then the canary itself is deleted. This is the monitoring metrics we talked about, here's some other ways of doing that. Uh you have uh Amazon Clubs are like we talked about Amazon or a DS X ray, especially in service with distributed applications. You need the story of not just what happened here but what happened to the same request going through uh CloudTrail and AWS Config I help with that.

Um I'm gonna tell you honestly, we saw this already. I don't know what's happened to my deck, but we're gonna just keep moving on. Here's logging again. So here we go. There we go. Alright, resource policies. So a resource policy, this is something a lot of people don't, don't realize uh they have access to a resource policy can say, hey, only allow access to this API or this route based on specific conditions. It has to be from this API, that's how we kind of do private API s. It has to be from this region. It has to be during this time. One of the great uses of this is, hey, we're gonna do a special sale where this API is only open for 30 days. And you can literally say make it available from February 1st to February 28th 8 a.m. to whatever. And so you have these kind of conditions, you can set that, that you can do that. So you see some examples up here where we, where we locked it down to a specific account, we can lock it down to a specific ip there's a lot of power. I go in a little bit, we'll see.

Wf actually, I'm gonna go to that next. These are in this order for this specific reason, our resource policy is built into API Gateway. It's part of the chart. I do that first. If I don't get what I need like an allow list or disallow list or something like that, I do that first. If I don't get what I need, then I move to an AWS Web Application Firewall, right? And the cool thing about this is you go into the WAF console, you can create one, you can do this all through, through infrastructures code as well. You create a firewall with whatever kind of limitations and monitoring or whatever you need. And that these are super powerful and then it's just as simple as going into the stage, your production stage on API Gateway and saying apply. And now the traffic is gonna go through that waft before it hits your end point.

Now this is REST only. But this is especially, you know, the financial uh you know, different things like that super secure. So this is a great way to use wf try your resource policies first. But then you can use wf uh as needed and the waf rules.

Alright. So a new one we have actually is we have client certificates now that we can, we can generate, generate clients uh side SSL certificates using the API Gateway. Uh this allows the backend to verify. So you have a backend service, you want to be very careful. I mean, we, we say, hey, it's on the internet, it's on the AWS network. It's gonna be fun. You're like, I wanna make sure. So you can generate a certificate and you can verify that certificate. Uh on the back end, we've done a couple of other things around this. This is something we came out with uh in the last year and that's mutual TLS, anybody using or require mutual TLS. Ok, a couple of you.

Alright. So what this means is, but, but, you know, normally we say, ok, as a client, when i call a server, i'm gonna, i'm gonna verify that server through their certificate. Right. That's a normal thing. That's htp, si, don't even know if there are any non, uh, htps routes anymore. It used to be, we didn't do it because it's very expensive time wise to, to call hps. And we would use htp. Sometimes now everything goes through the l. Right. But now if you need to verify the client, the server goes, ah, hold on, i want to know who you are as a client. I require that you have a certificate as well. And so you can do the, you see here, the client required to send the next 509 cert to verify their identity. Uh this is real common for internet of things. If you've got devices you don't want. So these are things running without you being there. You don't want them to do that or someone else to, you know, hijack that they have to send a cert and that's how you can do that. So mu tls, meaning both of you have to provide that.

Alright. So this next one we got just a couple more here. This is really cool. This is one and people ask me all the time, how do you build API Gateway? I use open API anybody familiar with open API or swagger? Good. A lot of you. I i that's where i live. I i don't build in s ami don't build my routes in cloud formation. I use open API for everything in s ami can point to an external file. In fact, in the app composer, if you're not familiar with the new app composer, you drag things in, you can say, hey, drop this API and, and build it in open API in a separate file. And what that allows me to do is build that out.

So where this comes in really handy is sometimes i'm not sure what that open api specs can look like. So i'll go into the API Gateway and i will build everything i need click, click, point, point, point, click, click, click, click, then i will go in and API Gateway can export swagger or open API and i export that. So this is really cool because now i'm able to convert swagger to open API or back and forth. I can import open API or swagger. I can export open API or swagger. It's like this conversion thing. It's a great way to migrate too. I can migrate from uh from one of the uh a another provider and i can import to API Gateway. Uh and so it's, it's just really cool way. You can also do json, you can do the postman extensions. Uh when you export it, make sure you have your API Gateway extensions, which which includes security off integrations, different things like that. So super powerful tool that a lot of people don't know about. So they ask me how do you build them? I build it in the console, i export the open API. So it's really easy. No, i don't have open API spec memorized, but guess what the console does so becomes really handy.

Alright. Well, the last thing we have here is identity based policies uh and identity based policies can determine this is more for who's building. So you can actually do based on identities. You can allow folks you can get really granular to say, hey, you can create an endpoint but that end point has to be htps, you can create an endpoint but it has to be private, it has to be whatever. So you, this is, this is more for internal, for monitoring your developers to make sure they're building the right type of API s to keep your, to keep your, your application safe.

Now, i just threw a ton of information at you. Hopefully, you learned something that oh i didn't know API Gateway did that. Um one of the things that, that i also throw out here uh that i don't have on here uh is we have validation, anybody use a validation of API Gateway? Ok. Did you know? Ok. One person. Alright. So here's what i'll tell you, validation can uh uh API Gateway at the end point can validate your API the the incoming body schema. It can look at the schema and it can require parameters, it can require parameters that meet, meet a certain condition is very powerful. So why does this matter? Well, let's say i'm running an integration, simple integration where, where a request is being called and then a lambda function uh is being invoked. Ok. Lambda has a great free tier. You get a million invocations a month. Uh so it's like ok, but if you're doing 567 h you know, 7 million invocations a month that can, that can, you know, price, price adds up, it's a fair price but it can add up. But what if you don't have to invoke a lambda when the incoming structure is bad? So at the API Gateway, you can say for every payload that comes in, i want you to evaluate it against this json schema if it's bad, check it out and don't ever invoke the lame to function or the back end in uh integration uh super powerful tool uh that, that i really encourage you to check out. I use it all the time and then i make sure that when i'm doing my bt l, when i'm doing my template and whatever i won't pass it through if it doesn't match, so it can't be bypassed. Uh and so it's super powerful to, to do that.

Alright. So like i said, i had thrown a lot at you. I put a lot of this in this resource, the qr code i should have warned you before. So you have to take pictures of everything but there a lot of this is in this uh link that you can go to. Uh and with that, excuse me, i'm gonna keep clear my throat. The other thing is these links go to service land, the qr code you had. If you haven't checked out service land, if you're looking for patterns, API Gateway to something, lambda, dynamo, db, whatever we actually have s a cd k terraform uh ploi templates that help you get started with a lot of the stuff at this deck or at this site. If you're looking to learn more about c this is, uh you know, we, we have a lot uh that you can do to, to get certified, you can get your service badge. Uh and with that, i'm gonna say, thank you very much. I appreciate that you came to my, my session here. Thank you.