In this video, Jeff Winesett introduces Amazon API Gateway as one of the services AWS provides to help achieve serverless architectures.
- [Instructor] When talking about performance efficiency, things like decreasing latency and increasing throughput are often mentioned. Making systems do more and go faster. These are, of course, incredibly important, but there is efficiency that is realized by designing systems with minimal overhead. An application can be built in the cloud on size optimized, auto scaled, load balanced EC2 instances across multiple availability zones, and this would certainly be following prescribed good optimization practices.
But what if the designing, building and maintaining of those servers could be entirely eliminated? If all of this could be off-loaded to AWS, that could greatly minimize administrative and maintenance overhead. Doing so could reduce load on the development team, lessening responsibilities, perhaps even reducing operational expenses. This is becoming more and more common due to the availability of managed services on AWS such as Amazon API Gateway and AWS Lambda.
Amazon API Gateway is a service that provides immediate solutions to some of the administrative and design challenges faced when building APIs. APIs are everywhere now, and most applications built today expose an API to allow ease of integration with other systems, and allow other developers to build upon an application. Having a well documented, developer-friendly API can make all the difference in the successful adoption and popularity of a product.
The API Gateway service can help and provides many nice features, such as versioning, caching, throttling, scaling, security, authentication and authorization, and monitoring. Amazon API Gateway is also one of the AWS services that is fully managed. This means that customers simply use the service, and are not responsible for any of the infrastructure used in supporting the gateway.
Amazon API Gateway adds an access layer between application users and application code. Requests are made through the internet, come into the API gateway, and are then handled in a variety of ways, depending on the request and the circumstances. In typical cases, the gateway responds to that request by executing custom application code residing on an EC2 instance, or in Lambda functions, or in any other publicly accessible endpoint.
But it could also return a response from a caching layer, or deny the request all together. For example, if the request was not authorized, or if that user has already hit their usage limit, or if the request is thought to be part of some denial of service attack. Amazon API Gateway provides tools and options to allow the control of traffic to the back-end application system. The API gateway uses a REST architecture, and for each HTTP method supported in the API, throttling rules can be set based on the number of requests per second.
Throttling limits can also be set on specific users of the API to set up usage limit plans. As another traffic control mechanism, the API gateway allows a cache to be configured from which requests will be served if matches are found. If taking advantage of these features, here is what happens when a request comes into the gateway. First, it checks against the AWS account limit for the maximum requests per second. There is a maximum request per second limit on each AWS account, which can be increased by submitting a request to Amazon.
If the traffic is below this account limit, it will then proceed to check against any explicitly configured throttling limits that might be in place. If any of the throttling limits for this request apply and have been reached, then the gateway responds with a 429 HTTP response. Otherwise, the request proceeds. At this point, if caching is enabled, it will return a cached response if available. Otherwise, the request will be sent on to the configured backend for processing.
And once an API is up and in use, Amazon Gateway provides a dashboard to monitor all the requests, and uses CloudWatch to record this monitoring information. This allows custom CloudWatch alarms to be set on API endpoints. Any error occurring during an API execution can be send to CloudWatch logs to help with debugging. It could take a long time to build a custom API with all of the the features Amazon API Gateway provides.
And eliminating the need to configure, run, and maintain API servers is certainly an added bonus. Optimizing for Performance: Lesson #4. When an API is a requirement in an application architecture, consider using the Amazon API Gateway to offload the design, implementation, and maintenance of this API layer.
- Benefits of cloud services
- Making architectures scalable
- Examining cloud constraints
- Virtual servers, EC2, and Elastic IP
- Using the Amazon machine image
- Elastic load balancing
- Using CloudWatch for monitoring
- Security Models
- Elastic block storage
- S3, CloudFront, and Elastic Beanstalk
- Handling queues, workflows, and notifications
- Caching options and services
- Identity and access management
- Creating a custom server image
- Application deployment strategies
- Serverless architectures