Amazon API Gateway

Editor's Notes

• #3: The ability to create and run multiple version of an API simultaneously. We have also built Stages. These enable developers to deploy multiple stages of each version simultaneously. For example, dev stage, prod stage, or beta stage. API Gateway helps developers create, monitor, and manage API Keys that they can distribute to 3rd party developers Developers who already own an authentication and authorization system can leverage their own infrastructure. For developers who are starting from scratch we have introduced the ability to leverage AWS’ own authorization mechanisms such as Signature V4 on Requests and IAM access policies for fine-grained access control At AWS we already run a very large, reliable network. API Gateway helps developers leverage all the work we have done over the years and allows developers to throttle incoming requests and use CloudWatch to monitor the status and latency of their APIs and set Alarms. Customers will be able to provision and configure a dedicated cache for their APIs, we will serve responses from the cache without hitting a customer’s backend whenever possible API Gateway can automatically generate client SDKs based on our customer’s API definition. This allows developers to take their APIs from concept to integration test in a client app in a matter of hours, not weeks Many of our customers use Swagger to define their APIs. API Gateway can import Swagger definitions. We have also built an open source Swagger import tool that our customers can use as part of their development workflow. This way they can keep working with Swagger in their local repository, then import and deploy their APIs into API Gateway at build time We have also integrated with the Apache Velocity templating engine, this allows our customers to transform the shape of requests and responses as they flow through the API Gateway. This gives customers the ability to expose legacy endpoints as modern, RESTful APIs among many other things.
• #5: The first thing we want to look at is the standard flow of an API call, including all components in the system First, a request comes in from a client, this could be a mobile device, a web application or a backend service The requests arrives at one of our CloudFront PoP locations, it’s accepted and routed through to the API Gateway in the customer’s region The API Gateway receives the request, then checks for records in the dedicated cache (if it is configured). If there are no cached records available then it will forward the request to the backend for processing The backend can be a Lambda function, a web service running on Amazon EC2, or any other publicly accessible web service Once the backend has processed the request the API call metrics are logged in Amazon CloudWatch and the content is returned to the client
• #6: Let’s look at what is an API, how you build, and how you deploy an API The first step is to create a new API, and declare its resources and methods. Once an API is declared it can be tested from the Console or the API Gateway APIs, but it is not yet accessible on the internet To make the API available it needs to be deployed to a Stage. Stages help you manage your development, beta, production environments etc. Customers can create as many stages as they want, similar to tagging. Each stage can be configured with its own logging, throttling, monitoring and caching settings At any time you can clone the state of an existing API into a new one, this allows you to start working on v2 of your APIs while v1 is still being developed/fixed. API Gateway saves a history of the last 300 deployments to each stage, at any time you can point a Stage (for example production) to a different deployment
• #7: Let’s look in details at the hierarchical structure of an API The top level element is the API itself, we call it a REST API. A rest API can contain many resources, resources are typed objects that are part of your API’s domain. They also represent the path through which the objects will be accessible You can nest resources, in our example the /pet/{petId} represents an individual pet and is a nested resource of the /pets/ resource. Each resource can declare methods. Methods are the combination of a resource + an HTTP Verb. We support 7 standard HTTP Verbs, For example, a method is the POST to the /pets/{petId} resources – this would be used to create a new pet
• #8: Now that we have declared an API with its resources and methods, we can deploy it to make it accessible to 3rd party developers APIs are deployed to a Stage Stages represent environments, for example development of production In API Gateway Stages are like tags, and developers can create as many stages as they want. A stage is just an alphanumeric string Stages are part of the path that will be used to reach sources and methods, for example the prod stage will be available at execute-api.apigateway.com/stage/resource
• #9: This is a visual representation of how versions and stages are managed by the API Gateway, and how customers can leverage these features for their APIs * The first thing we’ll do is declared a V1 API and start configuring its resources and methods * The next step is to deploy the API to a development stage, we’ll keep deploying to development as we evolve our API * At a certain point, when we are ready for 3rd party developers to access this API, we will publish it to a production stage and distribute API Keys and generated SDKs * All along we will keep deploying APIs to both dev and prod including new features and bug fixed * Eventually we’ll want to make some breaking changes, and work on a much improved v2 API. However, we cannot make breaking changes to the API in production because we have thousands of developers using it. * To manage this situation we’ll simply clone the current state of the v1 API into a new API called v2, and begin development of the new version * By cloning we can keep publishing bug fixes to the first release and supporting users that are calling it with a gentle, gradual deprecation “… developers feel like they can deliver what they want, when they want to – and that makes for an extremely valuable tool …”
• #10: Customers can configure the API Gateway to use a custom domain name they provide instead of the standard AWS domain. We expect customers to bring their own signed certificate for the HTTPS endpoints Domain names can be configured to point to an API, our top level item, or directly to a specific stage within an API. Pointing a custom domain name to an API requires the stage to be included in the path If the domain name is pointed directly at a stage there is no need for the path variable, resources can be accessed directly form the API root “/”
• #12: API Keys are a great tool to manage the community of 3rd party developers interacting with the APIs API Gateway allows customers to create API Keys through a console interface or through an API for programmatic creation. Customers can set permissions on API Keys and allow access only to a set of APIs, or stages within an API Calls made by an API Key are logged in CloudWatch so that customers can always track utilization by 3rd party developers
• #13: We always get asked whether API Keys are the authorization mechanism for APIs, so we’ll just be upfront: NO, at least we don’t recommend it We strongly encourage customers to use a temporary tokens based on a successful user authentication, either by leveraging AWS temporary credentials through API Signature Version 4, or their own Oauth mechanism
• #14: AWS gives customers the ability to retrieve temporary, limited privilege credentials that are tied to an IAM role within their AWS account through services like Cognito and STS. Based on these credentials developers can sign calls to the APIs, the generated client SDKs automatically know how to handle these credentials In the next slide we’ll go through a real-world use-case for this Alternatively customers can setup the API Gateway to forward their existing headers to keep using their current OAuth authorization schema
• #15: We’ll go through a use case that leverage AWS Lambda and Amazon Cognito to retrieve temporary credentials for a particular end user and authorize access to the APIs As discussed before the API Gateway helps customers leverage AWS Sigv4 – only one open API is required and then we can verify signatures on all other calls.
• #17: API Gateway uses throttling to help protect customer backends and send only request that they can handle To implement throttling we use the token bucket algorithm Customers can set the number of RPS calls they know their backend can handle, and a rate at which the bucket is refilled
• #18: API Gateway uses throttling to help protect customer backends and send only request that they can handle To implement throttling we use the token bucket algorithm Customers can set the number of RPS calls they know their backend can handle, and a rate at which the bucket is refilled
• #19: Let’s put the two together and look at the execution path of an API call First, when we receive a request, we will check the dedicated cache (if it’s been configured) If we have an item in the cache then we can handle the request regardless of the throttling configuration, it will have no effect on our customer’s backend Next, if we don’t have a cache, we check the throttling configuration and the current throttling state (our bucket) If we are above the limit we will return a 429 response Otherwise we will execute the backend call and return the result As we mentioned our generated SDKs automatically know how to handle throttling responses, and they will perform an exponential backoff while retrying the call
• #21: API Gateway can generate client SDKs based on a customer’s API definition. Simply select the deployment the SDK should target, the platform, and setup a couple of parameters and the API Gateway generates an SDK and makes it available to download through an API or the management console SDK are model-aware and also come with the built-in AWS core that allows them to handle throttling responses and sign requests using AWS Credentials
• #25: Today! Initially available in: US East (N. Virginia) US West (Oregon) EU West (Dublin) Other regions soon
• #26: Build, Deploy & Manage your APIs Request & Response Transform support Secure access using Sigv4 or OAuth Protect your backend with Throttling & Caching Simplified Client access via SDK Generation Usage-based pricing