So, so far in our serverless journey,
we've seen how to create Lambda functions
and we've seen how to use DynamoDB.
And so the functions can use DynamoDB
as a database for our API, and we can do create, read,
update, delete on our tables,
but we'd like our clients to be able to invoke
this Lambda function in some way.
So there are multiple of doing it.
We can have the client directly invoke the Lambda function,
but that means that the client would need IAM permissions,
or we've seen we can use an application load balancer
to have it in between the client and the Lambda function
and that would expose our Lambda function
as an HTTP endpoint.
There's one last thing we can use.
It's called the API Gateway.
And this is a serverless offering from AWS
which allows us to create REST APIs
that are going to be public and accessible for our clients.
So the client will talk to the API Gateway
and the beautiful things that the API Gateway
will then proxy the request to our Lambda functions.
So it would use an API Gateway
because it provides us more than just an HTTP endpoint.
It will provide us a lot of features
as we'll see in this section,
such as authentication, such as usage plans,
development stages and all that kind of things.
So the API Gateway has a lot of features
and this is just an overview,
but we can integrate the API Gateway and Lambda
and that gives us a full serverless application.
So no infrastructure to manage.
We have support for the WebSocket Protocol
so we can do real-time streaming
through the API Gateway in two different ways.
The API Gateway handle API versioning.
So we can go from version one to version two
and version three and not break our clients.
We can handle multiple environments
that includes a dev, a test and the prod environment.
There is a whole thing about API Gateway and security.
So there's a tons of way to enable security
on your API Gateway
for both authentication and authorization.
We have the ability to create API keys,
do request throttling in case some clients
are doing too many requests on our API Gateway,
and we can also use some common standards
such as Swagger or Open API 3.0
to import quickly defined APIs,
and also we can export them as Swagger and Open API.
We can transform and validate request and response
in the API Gateway level
to ensure that the invocation are correct,
and we can generate SDK and API specifications
and cache API responses.
So lots of features that come with the API Gateway
that are not necessarily included
when you use something as simple
as an application load balancer.
So what is the API Gateway integrate with?
Well, there is a Lambda function
and we've seen this from the previous diagram,
so it can invoke a Lambda function.
And with this integration, it is the most common way
and a very easy way to expose REST a API
backed by a Lambda function
to do a full serverless application.
But also HTTP.
So we can expose any HTTP endpoints in the backend.
So it could be, for example,
an HTTP API you have on premises,
or it could be an application load balancer
you have on your cloud environment.
And why would you do this?
Well, you would use an API Gateway
to leverage the rate limiting features, the caching,
the user authentication, the API keys, et cetera.
So it's definitely used full to have a layer
of API Gateway on top of your HTTP endpoint.
And finally, we can use an evidence service
so we can expose any AWS API through the API Gateway.
So which ones, for example,
where we can start a Step Function workflow,
we can post a message to SQS
directly from an API Gateway API.
Why would you do this?
Well, because maybe you want to add authentication,
deploy some APIs publicly
or do some rate control on some AWS services.
So here is an example of the API Gateway
used with an AWS service.
So example, Kinesis Data Streams.
So we want to have people send data
into a Kinesis Data Streams
but in a secure way,
without giving them access to AWS credentials.
So what we do is that's in between our clients
and our Kinesis Data Streams,
we're going to have the API Gateway.
And the clients will send HTTP request
into the API Gateway.
And it's been configured to then send the messages
into a Kinesis Data Streams.
And as you see in this setting, we don't manage any servers.
Then Kinesis Data Stream from there,
we can, for example, send the records
into a Kinesis Data Firehose
and eventually put them into an Amazon S3 bucket
in the JSON format.
So you start to see the power of API Gateway.
You can actually expose any AWS service
to the outside through an API Gateway.
There are three ways to deploy your API Gateway.
This is called endpoint types.
So the first type, which is the default one
is called Edge-Optimized.
This is for your global clients.
So that means that your API Gateway
is going to be accessible from anywhere in the world.
And to be efficient,
the request are going to be routed
through all the CloudFront Edge locations,
which will improve the latency.
Your API Gateway is still only in one region
where you created it, but it's accessible efficiently
from every CloudFormation Edge location.
Then there's a regional deployment.
So this is when we don't want to use
CloudFront Edge locations.
So it's when we expect all our users
to be within the same region
where we created our API Gateway.
And if you wanted to,
you could create your own platform distribution,
and this will give you the same result
as an Edge-Optimized distribution,
but this time you have more control over location strategies
and the platform settings themselves.
And then finally, the last kind of API Gateway you can do
is a private API Gateway.
So this time it's not public.
So a private API Gateway can only be accessed
from within your VPC.
And it will use interface VPC endpoints for your ENIs.
And to define access to your API Gateway,
you can use a resource policy.
Now, a few comments about the security
on top of the API Gateway.
So you can identify users on the API Gateway
in multiple ways.
The first way is through IAM roles.
So this is very helpful if you have internal applications,
for example, running on EC2 instances,
and they want to access an API on API Gateway,
they can just use IAM roles.
If you wanted to have external users,
for example, for mobile applications or web applications,
then you would use something called Amazon Cognito.
Or if you wanted to implement your own logic,
you could do do so with a custom authorizer.
This is a Lambda function.
Also, you can have HTTPS security
through your own custom domain name
by integration with a service called
the AWS Certificate Manager or ACM.
And so that certificate, if you're using
an Edge-Optimized endpoint must be in us-east-1
but if you're using a regional endpoint
then that certificate may be in the same region
as the API Gateway stage.
Finally, you must set up, of course, a CNAME
or an A-alias record in Route 53
to point to your domain and API Gateway.
So that's it for this lecture.
I hope you liked it.
And I will see you in the next lecture.