- Excited about this session. I actually did this session, or an older version of it, in 2019, 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? Okay, several of you. This is really exciting. How many y'all are exploring it? Okay, yeah, and using and exploring? We'll check that out, okay, very cool. Well, first of all, lemme tell you a little bit about who I am. My name is Eric Johnson. I'm a Principal DA for Serverless at AWS. I live, eat, and breathe Serverless, and it's interesting, when
I came to work for AWS, this is five years ago, I
just passed my five-year mark, 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, and, you know, I'm
having the reinvent flu, I guess is what we call it. That's what my wife calls it. It's just cold, whatever, but when I came in, they
asked me, they said, "What's the most challenging
service for you?' And I mean, it didn't even take a moment. I was like, "API Gateway. That's hard, it's hard stuff." So they said, "Great,
learn it and teach it." So that's what I've been doing. I learned API Gateway. If you've ever seen it,
I have two series out called "Happy Little APIs". At one point, I even
wore the Bob Ross wig. "Happy Little APIs", so we
had a lot of fun with that, but I love it. 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. I am a father of five. That is not a typo, and I am a drummer, that
used to say musician, but people are like, "Really? Drummer musician, maybe not." So, now, it says drummer,
and, finally, I'm a foodie. How many of y'all have
heard me speak before? Okay, a couple of you. All right, well, I'm sorry. You have to hear the rules again, okay? There are some rules when I talk, because, rules is probably a strong term, but these are guidelines for you, okay? So when I'm talking,
the first rule is this. This is any number I want it to be. Okay, 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. You know, this always gets
me in trouble 'cause 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," okay?
(audience laughs) 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. (audience laughs) Okay, so we're not gonna do that. All right, the second is these are quotes, not apostrophes, and I know that, okay? But this looks better than this. (audience laughs) Okay, 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 rule is these are thumbs 'cause this will get you beat up. (audience laughs)
Okay? 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... No, lemme 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. (audience laughs) So either way, I'm good,
but I appreciate you caring. So, all right, let's get started. We're actually gonna cover quite a bit, and, today, what this is, the literal title of the session says, "I Didn't Know API Gateway Did That," and it's going to be a laundry list of things that you kinda go, "Oh, 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, talk about some of the
integration patterns, 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. (coughs) 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 you're exploring this. 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 kinda 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 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. There's a lot of logic there," and maintaining multiple versions of services can be complex, and, come on, we don't
really do this anymore, but, sometimes, I see it. It's like, "Well, 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
programming interface. It isolates the underlying implementation. It abstracts the contract into this layer. It reduces exposure to your services, and it simplifies the interface, right? So it's very common for us to have an API when we're talking, 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 routing here comes through, and you hit your API, and then your 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 your client doesn't care. It just hits this one endpoint with maybe some pathing
in it, and it says, and you may point that to a
whole different organization, but the API gives you this ability to say, "Hey, I'm gonna split that
up," 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, right? You know, protocols, it's what
do they use to communicate. We have GraphQL. Anybody using GraphQL now? Okay, very cool. We have REST. REST is still the most popular
protocol on the internet. We have WebSockets. That's gaining a lot of ground. We have SOAP. That's actually an older, an older one. Anybody still uses SOAP? All right, I just wanna apologize to you. (audience laughs) No, I'm not apologizing. I didn't do it to you. I wanna feel sorry for you together. So, yeah, it's rough, right, and then we have RPC, and we have gRPC. With API Gateway, okay, as we climb in and talk about API Gateway,
we kind of limit those, but we'll talk about some
other things that handle those. So API Gateway, if you're
not familiar with it, like I said, most of you raise your hands, but just so you know, API Gateway is our managed
API Gateway service. It is a front door, right,
and we have several options when you work with... When you want to build a
front door, you can do ALB, you can do AppSync,
different things like that. API Gateway has a very specific
service or purpose, right, and for us, API Gateway is built to handle REST and WebSockets. Those are the two
protocols, and if you know, according to 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 wanna be able to handle this. It's a very common pattern. (coughs) Excuse me, however, if you are looking to use
some of these other protocols, we've got you covered. You can see AppSync, we'll do GraphQL, AWS IoT Core can handle
WebSockets as well as API Gateway, and I have some thoughts on that. If you're looking to kind of
figure out how you wanna do it, your WebSockets, talk to me, but it basically comes down to this. I'm gonna give you in a nutshell. API Gateway's WebSocket is all
the tools are there for you to build your own implementation. You can get really
customized with it, okay? So a lot of our companies are building like SaaS
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 the two different purposes, one's to just kind of have
out-of-the-box ready IoT or WebSockets 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 if you look at Serverless
Land or Serverless Video, the two products that our
team has built to kind of show event-driven architecture,
we use WebSockets 'cause it has everything
we need outta the box. I'm sorry, I didn't mean WebSockets. I meant IoT Core for our WebSockets, and, finally, if you wanna look at it, you still need to handle
SOAP, RPC, or gRPC, you can go to an Elastic Load Balancer. All right, 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, okay, 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. (audience laughs)
Everybody with me? And it uses the HTTP API. Now, really, if you think about these, the REST API is more of
a full-featured service. So they're a little different, but both are HTTP-based APIs, and I know this is can
be a little confusing, but they're both HTTP-based. We just call 'em 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 supported 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 I'll usually refer to
it, but if you don't see it, you can look up on the top right, and it'll tell you which
service supports this. Every once in a while,
you'll see an asterisk, and I'll call that out. All right, so continue to
talk about 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, okay? They are spun up in a specific region. This API is in US West
2, EU West 1, whatever. All APIs are regional,
that's how we do it, okay, but we'll talk about, and we also have a thing you can see here. This is, like I said,
this is a regional API. This allows you to... I mean, you can have... So this shows here, it says this is applications
and services in the same region can hit this endpoint, but
it's not limited to that. I wanna 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 this is a US West 2 region, and you're calling from
Frankfurt, Germany, it's a little bit longer of a call, right? So you kind of wanna 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 wanna
take a moment and explain. Now, this is in REST API only. Now, what this does is it creates a CloudFront distribution
network for you, okay, and you're like, "Wow, it's great." It is great, okay, but here's the thing. What it's doing is it's
bringing what we call POPs or point of presence
closer to your client. So if I'm using an Edge-optimized, it'll be on top of a regional API. So my API endpoint might be in US West 2, but if I'm in Frankfurt, Germany, it will call that closer
point of presence, then it'll route through
the Amazon backbone, okay? 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 wanna point out is this. Again, this is API Gateway
managed 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. and we'll see it in a minute. You can do API Gateway managed caching, but that's regional, okay? It's not at CloudFront. If you want CloudFront
caching at the Edge, and most likely you do, okay, then you wanna do your
own CloudFront, okay? It's not too terribly hard to set up, and I've got some examples of it, but what you do is you set
up a regional API endpoint, and you say, you know, "I want
this regional API endpoint, 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, "Okay, 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, "Well, why are you even
telling us about this, Eric?" Where this comes in really
handy is if I need an API that I can't cache, the
data's too hot, right, I can't cache that data because
it's constantly changing, but I need to get them on the network and get 'em to this as fast as possible, and I don't want to sink
that data all over the world, this comes in really handy, right? So it doesn't cache it, but it does get you quicker
access to the endpoint. So, hopefully, that
makes good sense there. All right, the next 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 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 inside the VPC, and so this is what a lot
of companies use internally to talk to each other
and to pass data around. (coughs) Again, not to be confused with a 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... (laughs) 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. Hopefully, I'm gonna clarify it. Okay, when we talk about,
and we'll talk about burst and caching and things like
that a little bit later, but I wanna do this early to kinda make sure we
understand it as it applies to some of the features and
things we're talking about. When you use API Gateway, REST or HTTP, you get a cache and a burst. I'm sorry. (laughs) Now, I'm just making up things. You get an RPS, which
means request per second, and you get a burst, right, and so these are two different things. And the hard codes,
let's bring this in here. The burst is number of concurrent starts API Gateway supports, right, and it has a hard maximum of 5,000. Now, it's important to
understand that this maximum is for all API endpoints within a region, within an account, not
for one API endpoint. So if I've got 33 production
business API endpoints in one account, I'm throttling
myself pretty hard, okay, and if you wanna talk
to me outside sometime, we can talk about how one
production per one account is a really good idea, okay, but so burst is how many concurrent, and, again, I wanna
stress this as concurrent. That means if all these requests came in at the exact same millisecond,
we can handle 5,000, boom, right off the bat, okay? Now, the next part of this is
what we call the RPS, okay? I drew this pipe myself. I'm pretty proud of it, okay? The RPS is the speed API Gateway
refills the bucket, okay, and it has a soft max of 10,000, okay? So what happens is, back to our scenario, if we have 5,000 requests
come in immediately, then, boom, those are gone,
then API Gateway was going, "Okay, fill more in, fill more in," and it could do up to 10,000 in that. That includes the original 5,000, okay? So over a second, you can
only do 10,000 per second, but you can handle 5,000
at the exact same time. A lot of times, I see
people configure this so that they say, "Okay,
we're going to set our max, our RPS at 5,000 and our burst at 10." Well, that doesn't make any sense because why we may be able to handle 5,000 at the same moment
or why we said our burst, first of all, that's over our max, right? Your burst should always be
less than your RPS, okay? 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. 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." I said, "Okay, 'cause
I've got it wrong a lot." So you're getting it
right until next year, and I go, "Yeah, I had it wrong." No, I'm saying this is right. So, okay, so that's
important to understand as we start walking through things. All right, so we're actually gonna, as we're talking about its
still part of API Gateway, what we talk about
integration types, all right, so these integration types in API Gateway, 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 it's really funny, you're like, "Okay, I have a Lambda function, and I have an AWS service, but hold on. Wait a minute, Eric. Lambda is an AWS service." So I know. 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'll give them the event, which is all the pertinent data
that came in on the request, and we'll give 'em 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 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 or the HTTP APIs, but HTTP
has a little asterisk there. So with HTTP, stay with me. HTTP has the ability to do a second pay. We have two types of payloads. One's 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 API will handle that for
you, 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 would I try
to change the body?" Well, we'll get into that in a little bit 'cause you can do some
fun things with REST and with HTTP or API Gateways. All right, so that's the proxy. So if you go in here, so this is the API HTTP 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, "Okay, well, this is the status code 200 'cause I got a 200 from the Lambda. I'm gonna go ahead and wrap the body and, you know, take care of that for you. I'll pass any headers." You know it takes care
of all that for you. So it's really cool. So if you're just building a simple API, HTTP API is probably the way to go. In fact, my general advice is, and I wanna be real careful with 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. (coughs) 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. So you can see the transform
request looks much different, then it goes to the integration
in the Lambda function. The Lambda function kicks out a response, and we can change that as well, okay? We can add to it, change
it, 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. Can do all kinds of things. So that's a direct integration. However, you know, it takes
a little configuration. VTL, I'm not gonna lie, it's not necessarily
for the faint of heart. It can be... Anybody doing VTL now? Okay, do you love it?
- No. - Okay, no, I heard a
strong no down here, okay. Yeah, yeah, yeah. The thing about it is... We'll talk more about it a little bit. Yeah, it's interesting. All right, so that's a proxy. So here's what a VTL
transformation looks like though just so you can see it. You say, okay, your first name's 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 'cause pineapple should
never be on pizza, right? So that comes in, so what
we're gonna do is in, oops, in our transformation, we'll go ahead, and you'll combine the name, 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, okay? 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, okay? You can apply this to AWS services, and DynamoDB is a really good example. DynamoDB is an API endpoint, right, and API Gateway 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
Serverless Video or seen that yet? Okay, a couple of you? All right, so Serverless Video, if you wanna grab this QR code,
it's also at s12d.com/video, we do a lot of this, and this
is a new pro project we built to kind of show how
event-driven architecture works, and so we're using Serverless Video, and so I'm gonna show you some examples. Now, the VTL might be kind of small, but I've got 'em blown up after. I'ma show you the whole thing. So first of all, this is an
example of a request coming in for maybe a video, okay? So you can see here where
I've got, using VTL, I've got some power to, you
know, I can do some looping, I can do some if-thens, I
can do all kinds of things to change the request, and
this is the response itself, and I'll blow that up just a bit. You can see here, if the root
has a last evaluation key, in this particular example, I'm adding, this is pagination from DynamoDB. I'm looking to see if it has a last key, and if it does, we'll pass it through, and then I'm also doing
some looping to say, "Okay, however many of
these you send back to me, I'm gonna loop through and structure my data
accordingly," all 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 if you remember, just
a moment ago, I said s12d. That's a URL shortener that
we use in our Serverless team and, actually, all over Amazon. Now, you probably saw it in
some other 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 tell you
something, the most liable, frail part of an application
is Eric Johnson's code, okay? My card, business card, says
Principal Developer Advocate, but that's because they said that's 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, and I built that, the whole s12d, I built that as a proof of concept. Hey, can it be done? Yeah, it can be done. 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, okay? All right, so this is REST. HTTP also has the ability
to do some integrations. These are custom built into HTTP, and it's just these five services, but you can directly connect
to the AWS AppConfig, to Amazon EventBridge, you wanna drop stuff on
EventBridge, simple queue. One of my favorites is the Step Functions. I can connect API Gateway
directly to a Step Function, and I can do a sync or async
launch of that Step Functions, and I can do a lot. I love Step Functions. That's my go-to. Before I even use a
Lambda, a Lambda function, I use a Step Function. If I need a Lambda function, I had the Step Functions
invoke it, and then, of course, Amazon Kinesis if you're
doing a front end on that, and with HTTP API, you get
some power for transformations. It's actually done in both. You can do parameter mapping where you can actually take
and override existing values. It's 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. Okay, 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 or HTTP, in front
of anything out in the wild. This is kind of cool because
before I was working at AWS, I had a company that needed
to hit Google location, right, but we needed to kind of... Basically, we needed to
stay within the parameters of what Google wanted to stay in, and so we needed a proxy to it. So we used API Gateway, and so my folks put, you know, it was like navigation.mycompany.com, and then it added any security
headers I needed to it, and then it sent it, and
using throttling and caching and different things like that, and API keys, I could minimize. I could stay within all the licensing that we needed to stay in. So this was a proxy, and you could proxy all kinds of things with this, We're doing something really cool. So this video where we
are calling out to 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 wanna keep that internal. We don't need everybody
knowing our endpoints. So it's a good way to do that. All right, mock integrations is the last integration
we're gonna talk about. The mock integration is super cool. This is just, literally... And this is supported just by REST. Well, we'll get to HTTP in a moment, and this allows, you
don't need an integration. This is great for pre-flight
if you're using... You know, you need to
do an options response, you can do this, and we have some checks and buttons in API Gateway that will actually
automatically do this for you. It'll set up the mock integration, but it means you don't
have to do anything to it. 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, this, you know, to allow, and then, you know, to,
basically, take care of cores." So lemme 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 cores had a face, I'd
punch it in the nose. (audience laughs) I'm dead serious. Raise your hand if you love cores. Yeah, a bunch of him. "Oh, no, no." No, I'm like, "There he is. He loves cores." Cores is hard, and that's... You know, we wanna blame API Gateway, we wanna blame our API stuff, but it's a browser thing, right? It's enforced at the
browser, and it's hard. So we do our best to try to help you. If you struggle with cores,
I built a tool a while back, it's a shameless plug, but it's called cores.servelessland.com, and you tell it your cores' needs, and it'll generate all the same for you for your deployments to
do your cores for that, because, yeah, cores is just, bleh. I'd rather go to the dentist
than configure your cores. All right, so mock integrations
helps you with that. The same thing in HTTP API,
we have a mock pre-flight, and what this does is
base, it kind of evaluates based on what your
Lambda function is doing and things like that. It will create the... 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, okay, and what this allows you to do is like 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 to connect to it, and so your API Gateway,
through a VPC link, connects to a network load balancer, and then you can connect to
ECS or EC2, anything in there, even including direct
connections to your on-premises, and this is really handy because you can keep your
stuff in a private subnet in your API or in your VPC. You can tell I do Serverless. I can't even spell VPC. I rarely have to work
with them, but, sometimes, and so when you have to do that, your API Gateway can connect to that. What's really cool is with HTTP
API, we did the same thing. Yeah, we're gonna let you do that, but 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, which is really handy if you're trying to connect
to container instances. Behind there, you can do some filtering. There's a lot of power built into that. Okay, 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. (coughs) Excuse me, and
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, okay, 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. Okay, this is pretty simple. Hopefully, all of y'all
are doing authorization. What we see a lot is we see pass-throughs that the people are handing authorization at their actual servers
or at the integration, and it'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 the type of
not authorizing, right? You have IAM permissions. That's usually a service to service. If you're passing it assigned, you can do it from a client,
too, assigned signature, signed signature, assigned certificate. Amazon Cognito authorizer, this is not the same as a JWT, okay? This is kind of a custom-built thing. It's Amazon 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 thing, I can do that. If I wanna 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 open, which means anytime you're in an API Gateway, you don't have to authorize, but I wanted to show that so you have it. IAM permissions, same thing, but, here, we do a
legitimate JWT authorizer. So we can do that. You can have your known endpoint. You can have your... You know, you pass your JOT token. We'll decipher it for you, and you can set your scopes, and use that at the API endpoint so you're pretty granular with that. It's really slick, 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. Okay, almost the entire
room, you're all guilty. Developers are 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, okay? So in the difference there, I'm sure you all know
this, but I'm gonna say it, authentication means are
you who you say you are? Right, so that's, you know,
you're authenticated through AWS or there's a lot of different things. Authorization says you are who you are, but you have access to this,
right, and so you wanna... Use the system or use the built-in stuff. Don't try to write it on yourself. There's really no need to. I'm guarantee you, it's
experts that have written this. 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. Amazon API Gateway actually has its own caching built in, right, and where this gets really handy is it's effective for quick responses within a region, right? You say, "Look, I wanna cache
some stuff within a region," and I guess where this
really becomes handy is API Gateway manages the whole thing. In my opinion, if you
don't wanna 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 cache objects, and, yeah, it's perfectly helpful, and it handles that all for you. You want it out-of-the-box,
that's a way to go, but there is an hour cost based
on the caching 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's fun. Okay, anybody... All right, bunch of you
working with API Gateway, now, have you set up your throttling? Okay, all right, good, you can leave. You know everything we need to know. No, I'm just kidding. Okay, throttling, this is... I'm kind of glad to see not a
lot of people raise your hand. When we get outta this
session, go right to your hotel and fix your throttling, okay? That's how important it is, all right? Throttling's a really
interesting thing, all right? So I alluded to this earlier. I actually said, by alluding,
I mean, I actually said it. You have a 10,000 RPS soft limit, okay, and that works for most people. If you need more than 10,000,
I'd be interested to see what your patterns are and
stuff, and it may happen. I mean, if you're like,
"Look, I run Netflix." You probably need more than 10,000, right, but you're like, "I run my mom's blog." Maybe you architected
that wrong, you know, but, yeah, so 10,000 per
second, that's a soft limit. That can be raised. 5,000 is a hard limit. It's shared among all, like I said, it's shared 'em among all endpoints. I wanted to put that up
here so you could see it, but this is a customizable thing, okay? 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 to a method. It can get very, very granular, right? So what we might do is we might
say, "Look, I'm gonna give, you know, 8,000 RPS of 4,000
to my Gits in my order, okay, to orders, but I'm
gonna give full 10,000 with a 5k burst to the post of that 'cause I want people to
be able to make orders. I don't care that myself,
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 Gits 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 800 and 800, 1k and 1k. So, remember, I'm not going over, but I'm matching my
burst 'cause it's so low. I'm matching my burst to
my request per seconds, but my people who are
paying, they get priority. So I'm gonna throttle my free group in favor of my subscription group," okay? So by doing this, remember, I said go home
and fix your throttle, 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, you know, we wanna
make sure we throttle a reports API that just
ourselves people hit. We're gonna throttle that
down to make sure that a point of sale API has just
all kinds of room," right, and by doing that, you're able to, probably, you make better use of that 10,000 RPS and your 5,000 burst. So throttling is a fun game,
and you may not get it right. The other thing I really encourage you, and we'll talk about metrics
and stuff in a little bit, is metrics. Get your alarm set up. Know when you're throttling, right? Set that up. Okay, so next thing we're
gonna talk about is stages. Anybody using stages in API Gateway? Okay, all righty, do you love 'em? Okay, you do, okay, all righty. I'm not a big fan of 'em. I'll be really honest, I don't. Now, with some of the things, and I'll explain it in just a minute, but lemme tell you what
it does first, okay? 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 v1,
v2, these are great ways of maintaining multiple versions
of the same API, all right? So you can just, excuse me, (coughs) and you can point 'em to
different integrations on the back side based on
stage variables, actually, and that looks kinda 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 kind
of another story on that. My opinion is don't use
stage or stage variables if you don't have to, okay? There's a very good reason for 'em,, and we use 'em under the hood
for some different things, but if you don't have to, don't use 'em 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 in one
account, I'm gonna break it into, I have developer accounts,
especially with Serverless, it's all ephemeral services, right, unless you're using a database
that you can share an order, something like that, then I'm
gonna have a alpha account, a 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, and they're the people that can deploy it. So not everybody has
access to these accounts. So it helps lock that down, right? Okay, 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, okay? So how this works is I can say, 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 v1, a v2, a prod, a
beta, however you want to do, but 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 takes away a lot of
management headache, okay, and we've built this in,
we have custom domains, and we have multi-level
based path mapping, which allows you to
just really dig that in. All right. So, earlier, I talked about,
and you know what, somehow, I think some of my slides got reversed. So I want to go here next,
just looking at this, okay? So this is the base path
mapping that goes with logging, or, I'm sorry, how you doing, that goes with custom domains. So you can see here, I can
point 'em to like root v1, root V2, reports,
different things like that. So I may have different
places I wanna point them, and they can be different
endpoints on the back side, 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 me, 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 did this here at AWS, I was a Solutions Architect for Rackspace, and we would go in and we'd
sit down with huge companies, we'd talk about 'em, "Okay, great," 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 log everything." "Well, okay, that's great. What do you do with it?" "We log it. We log it." "Okay, what do you do with the data?" "We save it. Drop it in an S3 bucket." "Oh, that's great, what
do you do with that?" "Well, we take it to cold
storage after a while." "Okay, what do you do with that?" You see 'em 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
peaking out repeatedly," or, "Hey, I'm dropping requests. I'm getting a lot of 429s." Why is that happening, right? So by setting up these logins 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 the, you can see here,
the custom log formats. There's just a lot of of ways you can log, but just, I encourage
you, if nothing else, CloudWatch your metrics,
and then build up on that. All right, so we're gonna
jump ahead a little bit here. So the next thing we're gonna
talk about is canary releases. Anybody use canary releases so far? All 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 five, 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, okay? Because what happens is
this really is freebie. For code, there are some blue-green things you can do with Lambda
that actually happen at the Lambda function level, right? You can use this for code, but there are some other ways of doing 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, but it does require a manual promotion. So you can watch your metrics, you get a manual promotion, off you go. So that's a canary 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. You have Amazon Cloud's
like we talked about, Amazon or AWS X-Ray, especially in Serverless with
distributed applications. You need the story of not
just what happened here, but what happened to the
same request going through. CloudTrail and AWS Config,
I'll help with that. 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. All right, resource policies, so a resource policy, this
is something a lot of people don't realize 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 kinda do private APIs. 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:00 am to whatever," and so you have these kind
of conditions you can set that you can do this. So you see some examples up here where we lock it down
to a specific account. We can lock it down to a specific IP. There's a lot of power. In a little bit, we'll see WAF. Actually, I'm gonna go to that next. (Eric coughs) These are in this order
for this specific reason. A resource policy is
built into API Gateway. It's part of the charge. I do that first. If I don't get what I
need, like an allow list or a 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
infrastructure codes as well, you create a firewall with whatever kind of limitations and monitoring
or whatever you need, and 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 WAF before it hits your endpoint. Now, this is REST only, but this is, especially for, you know, the financial, you know, different things
like that, super secure. So this is a great way to use WAF. Try your resource policies first, but then you can use WAF
as needed in the WAF rules. All right, so a new one we have, actually, is we have client certificates
now that we can generate client side SSL certificates
using the API Gateway. This allows the backend to verify. So you have a backend service. You wanna be very careful. I mean, we say, "Hey,
it's on the internet. It's on the AWS network,
it's gonna be fine." You're like, (laughs) "I wanna make sure." So you can generate a certificate, and you can verify that
certificate on the backend. We've done a couple
other things around this. This is something we came
out with in the last year, and that's mutual TLS. Anybody using or require mutual TLS? Okay, a couple of you. All right, so what this means is... But, you know, normally,
we say, okay, as a client, when I call a server, I'm
gonna verify that server through their certificate, right? That's a normal thing, that's HTTPS. I don't even know if there are
any non-HTTPS routes anymore. It used to be we didn't do it 'cause it's very expensive
time-wise to call HTTPS, and we would use HTTPS sometimes. Now, everything goes to SSL, right? But, now, if you need to verify
the client, the server goes, "Ah, hold on, I wanna 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 an X.509 cert to verify their identity. 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 nor someone else to,
you know, hijack that. They have to send a cert, and
that's how you can do that. So mutual TLS, meaning both
of you have to provide that. All right, so this next one,
we got just a couple more here. This is really cool. This is one... People ask me all the time,
"How do you build API Gateway?" I use OpenAPI. Anybody familiar with OpenAPI or Swagger? Good, a lot of you. That's where I live. I don't build in Sam. I don't build my routes
in cloud information. I use OpenAPI for everything. In Sam, I 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 build it in OpenAPI
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 OpenAPI spec is gonna 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 OpenAPI, and I export that. So this is really cool because, now, I'm able to convert Swagger
to OpenAPI or back and forth. I can import OpenAPI or Swagger. I can export open the API or Swagger. It's like this conversion thing. It's a great way to migrate, too. I can migrate from another provider, and I can import to API Gateway, and so it's just really cool way. You can also do JSON. You can do the Postman extensions. When you export it, make sure you have your
API Gateway extensions, which includes security,
auth, 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 'em?" I build it in the console. I export the OpenAPI. So it's really easy. No, I don't have OpenAPI spec
memorized, but guess what? The console does, so becomes really handy. All right, well the
last thing we have here is identity-based policies,
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. You can say, "Hey, you
can create an endpoint, but that endpoint has to be HTTPS. You can create an endpoint, but it has to be private. It has to be whatever." So this is more for internal,
for monitoring your developers to make sure they're building
the right type of APIs to keep 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." One of the things that
I also throw out here that I don't have on here
is we have validation. Anybody use a validation API Gateway? Okay, did you know? Okay, one person, all right. So here's what I'll tell you. Validation can... API Gateway, at the endpoint,
can validate your API, the incoming body schema. It can look at the schema,
and it can require parameters. It can require parameters
that meet a certain condition. It's very powerful. So why does this matter? Well, let's say I'm
running an integration, a simple integration where
a request is being called, and then a Lambda function
is being invoked, okay? Lambda has a great free tier. You get a million invocations a month. So it's like, okay, but
if you're doing five, six, you know, seven million
invocations a month, that can, you know, price that 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
against this JSON schema. If it's bad, kick it out, and don't ever invoke the Lambda function or the backend integration. A super powerful tool 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 VTL, when I'm doing my templating or whatever, I won't pass it through
if it doesn't match so it can't be bypassed. and so it's super powerful to do that. All right, so like I said,
I've thrown a lot at you. I put a lot of this in
this resource, the QR code. I should've warned you before so you don't have to take
pictures of everything, but a lot of this is in this
link that you can go to, and with that, (coughs) excuse me, I'm gonna keep clearing my throat. The other thing is these
links go to Serverless Land, the QR code you had. If you haven't checked
out Serverless Land, if you're looking for patterns,
API Gateway to something, Lambda, DynamoDB, whatever,
we actually have Sam, CDK, Terraform, Pulumi, 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 Serverless, you know, we have a lot that
you can do to get certified. You can get your Serverless badge and with that, I'm gonna
say thank you very much. I appreciate that you
came to my session here. Thank you.
(audience claps)
