1 00:00:00,150 --> 00:00:02,340 ‫So, so far in our serverless journey, 2 00:00:02,340 --> 00:00:04,380 ‫we've seen how to create Lambda functions 3 00:00:04,380 --> 00:00:06,180 ‫and we've seen how to use DynamoDB. 4 00:00:06,180 --> 00:00:08,310 ‫And so the functions can use DynamoDB 5 00:00:08,310 --> 00:00:11,850 ‫as a database for our API, and we can do create, read, 6 00:00:11,850 --> 00:00:14,220 ‫update, delete on our tables, 7 00:00:14,220 --> 00:00:17,340 ‫but we'd like our clients to be able to invoke 8 00:00:17,340 --> 00:00:19,980 ‫this Lambda function in some way. 9 00:00:19,980 --> 00:00:21,180 ‫So there are multiple of doing it. 10 00:00:21,180 --> 00:00:23,940 ‫We can have the client directly invoke the Lambda function, 11 00:00:23,940 --> 00:00:26,610 ‫but that means that the client would need IAM permissions, 12 00:00:26,610 --> 00:00:28,710 ‫or we've seen we can use an application load balancer 13 00:00:28,710 --> 00:00:31,110 ‫to have it in between the client and the Lambda function 14 00:00:31,110 --> 00:00:33,060 ‫and that would expose our Lambda function 15 00:00:33,060 --> 00:00:34,620 ‫as an HTTP endpoint. 16 00:00:34,620 --> 00:00:35,940 ‫There's one last thing we can use. 17 00:00:35,940 --> 00:00:37,320 ‫It's called the API Gateway. 18 00:00:37,320 --> 00:00:39,930 ‫And this is a serverless offering from AWS 19 00:00:39,930 --> 00:00:42,510 ‫which allows us to create REST APIs 20 00:00:42,510 --> 00:00:45,480 ‫that are going to be public and accessible for our clients. 21 00:00:45,480 --> 00:00:47,550 ‫So the client will talk to the API Gateway 22 00:00:47,550 --> 00:00:49,470 ‫and the beautiful things that the API Gateway 23 00:00:49,470 --> 00:00:52,740 ‫will then proxy the request to our Lambda functions. 24 00:00:52,740 --> 00:00:54,120 ‫So it would use an API Gateway 25 00:00:54,120 --> 00:00:57,030 ‫because it provides us more than just an HTTP endpoint. 26 00:00:57,030 --> 00:00:58,200 ‫It will provide us a lot of features 27 00:00:58,200 --> 00:00:59,550 ‫as we'll see in this section, 28 00:00:59,550 --> 00:01:02,490 ‫such as authentication, such as usage plans, 29 00:01:02,490 --> 00:01:04,530 ‫development stages and all that kind of things. 30 00:01:04,530 --> 00:01:07,050 ‫So the API Gateway has a lot of features 31 00:01:07,050 --> 00:01:08,580 ‫and this is just an overview, 32 00:01:08,580 --> 00:01:11,130 ‫but we can integrate the API Gateway and Lambda 33 00:01:11,130 --> 00:01:13,380 ‫and that gives us a full serverless application. 34 00:01:13,380 --> 00:01:15,390 ‫So no infrastructure to manage. 35 00:01:15,390 --> 00:01:17,220 ‫We have support for the WebSocket Protocol 36 00:01:17,220 --> 00:01:18,840 ‫so we can do real-time streaming 37 00:01:18,840 --> 00:01:21,690 ‫through the API Gateway in two different ways. 38 00:01:21,690 --> 00:01:23,280 ‫The API Gateway handle API versioning. 39 00:01:23,280 --> 00:01:25,230 ‫So we can go from version one to version two 40 00:01:25,230 --> 00:01:27,630 ‫and version three and not break our clients. 41 00:01:27,630 --> 00:01:29,520 ‫We can handle multiple environments 42 00:01:29,520 --> 00:01:32,520 ‫that includes a dev, a test and the prod environment. 43 00:01:32,520 --> 00:01:35,310 ‫There is a whole thing about API Gateway and security. 44 00:01:35,310 --> 00:01:37,680 ‫So there's a tons of way to enable security 45 00:01:37,680 --> 00:01:38,880 ‫on your API Gateway 46 00:01:38,880 --> 00:01:41,670 ‫for both authentication and authorization. 47 00:01:41,670 --> 00:01:44,160 ‫We have the ability to create API keys, 48 00:01:44,160 --> 00:01:46,260 ‫do request throttling in case some clients 49 00:01:46,260 --> 00:01:49,050 ‫are doing too many requests on our API Gateway, 50 00:01:49,050 --> 00:01:51,510 ‫and we can also use some common standards 51 00:01:51,510 --> 00:01:53,880 ‫such as Swagger or Open API 3.0 52 00:01:53,880 --> 00:01:57,120 ‫to import quickly defined APIs, 53 00:01:57,120 --> 00:02:00,360 ‫and also we can export them as Swagger and Open API. 54 00:02:00,360 --> 00:02:02,670 ‫We can transform and validate request and response 55 00:02:02,670 --> 00:02:03,960 ‫in the API Gateway level 56 00:02:03,960 --> 00:02:06,240 ‫to ensure that the invocation are correct, 57 00:02:06,240 --> 00:02:09,060 ‫and we can generate SDK and API specifications 58 00:02:09,060 --> 00:02:11,190 ‫and cache API responses. 59 00:02:11,190 --> 00:02:13,653 ‫So lots of features that come with the API Gateway 60 00:02:13,653 --> 00:02:15,360 ‫that are not necessarily included 61 00:02:15,360 --> 00:02:16,770 ‫when you use something as simple 62 00:02:16,770 --> 00:02:18,840 ‫as an application load balancer. 63 00:02:18,840 --> 00:02:21,060 ‫So what is the API Gateway integrate with? 64 00:02:21,060 --> 00:02:22,680 ‫Well, there is a Lambda function 65 00:02:22,680 --> 00:02:24,720 ‫and we've seen this from the previous diagram, 66 00:02:24,720 --> 00:02:26,490 ‫so it can invoke a Lambda function. 67 00:02:26,490 --> 00:02:29,370 ‫And with this integration, it is the most common way 68 00:02:29,370 --> 00:02:32,220 ‫and a very easy way to expose REST a API 69 00:02:32,220 --> 00:02:33,720 ‫backed by a Lambda function 70 00:02:33,720 --> 00:02:36,330 ‫to do a full serverless application. 71 00:02:36,330 --> 00:02:37,830 ‫But also HTTP. 72 00:02:37,830 --> 00:02:40,710 ‫So we can expose any HTTP endpoints in the backend. 73 00:02:40,710 --> 00:02:42,090 ‫So it could be, for example, 74 00:02:42,090 --> 00:02:44,220 ‫an HTTP API you have on premises, 75 00:02:44,220 --> 00:02:45,750 ‫or it could be an application load balancer 76 00:02:45,750 --> 00:02:47,640 ‫you have on your cloud environment. 77 00:02:47,640 --> 00:02:48,660 ‫And why would you do this? 78 00:02:48,660 --> 00:02:50,400 ‫Well, you would use an API Gateway 79 00:02:50,400 --> 00:02:53,340 ‫to leverage the rate limiting features, the caching, 80 00:02:53,340 --> 00:02:55,200 ‫the user authentication, the API keys, et cetera. 81 00:02:55,200 --> 00:02:57,668 ‫So it's definitely used full to have a layer 82 00:02:57,668 --> 00:03:01,230 ‫of API Gateway on top of your HTTP endpoint. 83 00:03:01,230 --> 00:03:04,140 ‫And finally, we can use an evidence service 84 00:03:04,140 --> 00:03:08,070 ‫so we can expose any AWS API through the API Gateway. 85 00:03:08,070 --> 00:03:09,390 ‫So which ones, for example, 86 00:03:09,390 --> 00:03:11,520 ‫where we can start a Step Function workflow, 87 00:03:11,520 --> 00:03:13,830 ‫we can post a message to SQS 88 00:03:13,830 --> 00:03:17,460 ‫directly from an API Gateway API. 89 00:03:17,460 --> 00:03:18,300 ‫Why would you do this? 90 00:03:18,300 --> 00:03:20,370 ‫Well, because maybe you want to add authentication, 91 00:03:20,370 --> 00:03:22,140 ‫deploy some APIs publicly 92 00:03:22,140 --> 00:03:25,770 ‫or do some rate control on some AWS services. 93 00:03:25,770 --> 00:03:28,620 ‫So here is an example of the API Gateway 94 00:03:28,620 --> 00:03:30,870 ‫used with an AWS service. 95 00:03:30,870 --> 00:03:33,000 ‫So example, Kinesis Data Streams. 96 00:03:33,000 --> 00:03:35,220 ‫So we want to have people send data 97 00:03:35,220 --> 00:03:36,900 ‫into a Kinesis Data Streams 98 00:03:36,900 --> 00:03:38,010 ‫but in a secure way, 99 00:03:38,010 --> 00:03:41,520 ‫without giving them access to AWS credentials. 100 00:03:41,520 --> 00:03:44,340 ‫So what we do is that's in between our clients 101 00:03:44,340 --> 00:03:45,870 ‫and our Kinesis Data Streams, 102 00:03:45,870 --> 00:03:48,270 ‫we're going to have the API Gateway. 103 00:03:48,270 --> 00:03:50,640 ‫And the clients will send HTTP request 104 00:03:50,640 --> 00:03:52,230 ‫into the API Gateway. 105 00:03:52,230 --> 00:03:55,140 ‫And it's been configured to then send the messages 106 00:03:55,140 --> 00:03:57,000 ‫into a Kinesis Data Streams. 107 00:03:57,000 --> 00:04:00,450 ‫And as you see in this setting, we don't manage any servers. 108 00:04:00,450 --> 00:04:01,800 ‫Then Kinesis Data Stream from there, 109 00:04:01,800 --> 00:04:03,360 ‫we can, for example, send the records 110 00:04:03,360 --> 00:04:05,160 ‫into a Kinesis Data Firehose 111 00:04:05,160 --> 00:04:08,777 ‫and eventually put them into an Amazon S3 bucket 112 00:04:08,777 --> 00:04:10,680 ‫in the JSON format. 113 00:04:10,680 --> 00:04:12,990 ‫So you start to see the power of API Gateway. 114 00:04:12,990 --> 00:04:16,050 ‫You can actually expose any AWS service 115 00:04:16,050 --> 00:04:18,933 ‫to the outside through an API Gateway. 116 00:04:19,770 --> 00:04:22,560 ‫There are three ways to deploy your API Gateway. 117 00:04:22,560 --> 00:04:24,030 ‫This is called endpoint types. 118 00:04:24,030 --> 00:04:25,830 ‫So the first type, which is the default one 119 00:04:25,830 --> 00:04:27,300 ‫is called Edge-Optimized. 120 00:04:27,300 --> 00:04:28,950 ‫This is for your global clients. 121 00:04:28,950 --> 00:04:30,330 ‫So that means that your API Gateway 122 00:04:30,330 --> 00:04:32,610 ‫is going to be accessible from anywhere in the world. 123 00:04:32,610 --> 00:04:34,020 ‫And to be efficient, 124 00:04:34,020 --> 00:04:35,670 ‫the request are going to be routed 125 00:04:35,670 --> 00:04:37,740 ‫through all the CloudFront Edge locations, 126 00:04:37,740 --> 00:04:39,540 ‫which will improve the latency. 127 00:04:39,540 --> 00:04:41,880 ‫Your API Gateway is still only in one region 128 00:04:41,880 --> 00:04:45,060 ‫where you created it, but it's accessible efficiently 129 00:04:45,060 --> 00:04:47,970 ‫from every CloudFormation Edge location. 130 00:04:47,970 --> 00:04:49,110 ‫Then there's a regional deployment. 131 00:04:49,110 --> 00:04:50,850 ‫So this is when we don't want to use 132 00:04:50,850 --> 00:04:52,290 ‫CloudFront Edge locations. 133 00:04:52,290 --> 00:04:54,630 ‫So it's when we expect all our users 134 00:04:54,630 --> 00:04:55,770 ‫to be within the same region 135 00:04:55,770 --> 00:04:57,810 ‫where we created our API Gateway. 136 00:04:57,810 --> 00:04:58,950 ‫And if you wanted to, 137 00:04:58,950 --> 00:05:01,860 ‫you could create your own platform distribution, 138 00:05:01,860 --> 00:05:03,330 ‫and this will give you the same result 139 00:05:03,330 --> 00:05:05,310 ‫as an Edge-Optimized distribution, 140 00:05:05,310 --> 00:05:08,070 ‫but this time you have more control over location strategies 141 00:05:08,070 --> 00:05:10,050 ‫and the platform settings themselves. 142 00:05:10,050 --> 00:05:12,840 ‫And then finally, the last kind of API Gateway you can do 143 00:05:12,840 --> 00:05:14,070 ‫is a private API Gateway. 144 00:05:14,070 --> 00:05:15,720 ‫So this time it's not public. 145 00:05:15,720 --> 00:05:18,180 ‫So a private API Gateway can only be accessed 146 00:05:18,180 --> 00:05:19,770 ‫from within your VPC. 147 00:05:19,770 --> 00:05:23,160 ‫And it will use interface VPC endpoints for your ENIs. 148 00:05:23,160 --> 00:05:25,500 ‫And to define access to your API Gateway, 149 00:05:25,500 --> 00:05:27,630 ‫you can use a resource policy. 150 00:05:27,630 --> 00:05:29,490 ‫Now, a few comments about the security 151 00:05:29,490 --> 00:05:31,500 ‫on top of the API Gateway. 152 00:05:31,500 --> 00:05:33,900 ‫So you can identify users on the API Gateway 153 00:05:33,900 --> 00:05:35,160 ‫in multiple ways. 154 00:05:35,160 --> 00:05:37,110 ‫The first way is through IAM roles. 155 00:05:37,110 --> 00:05:39,570 ‫So this is very helpful if you have internal applications, 156 00:05:39,570 --> 00:05:41,700 ‫for example, running on EC2 instances, 157 00:05:41,700 --> 00:05:44,220 ‫and they want to access an API on API Gateway, 158 00:05:44,220 --> 00:05:46,320 ‫they can just use IAM roles. 159 00:05:46,320 --> 00:05:48,060 ‫If you wanted to have external users, 160 00:05:48,060 --> 00:05:51,510 ‫for example, for mobile applications or web applications, 161 00:05:51,510 --> 00:05:54,360 ‫then you would use something called Amazon Cognito. 162 00:05:54,360 --> 00:05:56,550 ‫Or if you wanted to implement your own logic, 163 00:05:56,550 --> 00:05:59,100 ‫you could do do so with a custom authorizer. 164 00:05:59,100 --> 00:06:01,470 ‫This is a Lambda function. 165 00:06:01,470 --> 00:06:04,320 ‫Also, you can have HTTPS security 166 00:06:04,320 --> 00:06:06,540 ‫through your own custom domain name 167 00:06:06,540 --> 00:06:08,340 ‫by integration with a service called 168 00:06:08,340 --> 00:06:11,490 ‫the AWS Certificate Manager or ACM. 169 00:06:11,490 --> 00:06:13,260 ‫And so that certificate, if you're using 170 00:06:13,260 --> 00:06:16,800 ‫an Edge-Optimized endpoint must be in us-east-1 171 00:06:16,800 --> 00:06:19,050 ‫but if you're using a regional endpoint 172 00:06:19,050 --> 00:06:21,330 ‫then that certificate may be in the same region 173 00:06:21,330 --> 00:06:23,640 ‫as the API Gateway stage. 174 00:06:23,640 --> 00:06:26,040 ‫Finally, you must set up, of course, a CNAME 175 00:06:26,040 --> 00:06:28,590 ‫or an A-alias record in Route 53 176 00:06:28,590 --> 00:06:32,043 ‫to point to your domain and API Gateway. 177 00:06:33,120 --> 00:06:34,650 ‫So that's it for this lecture. 178 00:06:34,650 --> 00:06:35,550 ‫I hope you liked it. 179 00:06:35,550 --> 00:06:37,500 ‫And I will see you in the next lecture.