‫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.