Things to Consider When You Build REST APIs with Amazon API Gateway
AWS Architecture BlogThings to Consider When You Build REST APIs with Amazon API Gatewayby George Mao | on13 AUG 2019| inAdvanced (300),Amazon API Gateway,Amazon RDS,Amazon Simple Queue Service (SQS),Architecture,AWS Lambda,Intermediate (200)|Permalink|ShareA few weeks ago, we kicked off this series with a discussion onREST vs GraphQL APIs. This post will dive deeper into the things an API architect or developer should consider when building REST APIs withAmazon API Gateway.Request Rate (a.k.a. “TPS”)Request rate is the first thing you should consider when designing REST APIs. By default, API Gateway allows for up to 10,000 requests per second. You should use the built inAmazon CloudWatchmetrics to review how your API is being used. TheCountmetric in particular can help you review the total number of API requests in a given period.It’s important to understand the actual request rate that your architecture is capable of supporting. For example, consider this architecture:This API accepts GET requests to retrieve a user’s cart by using a Lambda function to perform SQL queries against a relational database managed in RDS.  If you receive a large burst of traffic, both API Gateway and Lambda will scale in response to the traffic. However, relational databases typically have limited memory/cpu capacity and will quickly exhaust the total number of connections.As an API architect, you should design your APIs to protect your down stream applications.  You can start by definingAPI Keysand requiring your clients to deliver a key with incoming requests. This lets you track each application or client who is consuming your API.  This also lets you createUsage Plansand throttle your clients according to the plan you define.  For example, you if you know your architecture is capable of of sustaining 200 requests per second, you should define a Usage plan that sets a rate of 200 RPS and optionally configure a quota to allow a certain number of requests by day, week, or month.Additionally, API Gateway lets you define throttling settings for the whole stage or per method. If you know that a GET operation is less resource intensive than a POST operation you can override the stage settings and set different throttling settings for each resource.Integrations and Design patternsThe example above describes a synchronous, tightly coupled architecture where the request must wait for a response from the backend integration (RDS in this case). This results in system scaling characteristics that are the lowest common denominator of all components. Instead, you should look for opportunities to design an asynchronous, loosely coupled architecture. A decoupled architecture separates the data ingestion from the data processing and allows you to scale each system separately. Consider this new architecture:This architecture enables ingestion of orders directly into a highly scalable and durable data store such asAmazon Simple Queue Service(SQS).  Your backend can process these orders at any speed that is suitable for your business requirements and system ability.  Most importantly,  the health of the backend processing system does not impact your ability to continue accepting orders.SecuritySecurity with API Gateway falls into three major buckets, and I’ll outline them below. Remember, you should enable all three options to combine multiple layers of security.Option 1 (Application Firewall)You can enableAWS Web Application Firewall(WAF) for your entire API. WAF will inspect all incoming requests and block requests that fail your inspection rules. For example, WAF can inspect requests for SQL Injection, Cross Site Scripting, or whitelisted IP addresses.Option 2 (Resource Policy)You can apply aResource Policythat protects your entire API. This is an IAM policy that is applied to your API and you can use this to white/black list client IP ranges or allow AWS accounts and AWS principals to access your API.Option 3 (AuthZ)IAM:This AuthZ option requires clients to sign requests with theAWS v4 signing process. The associated IAM role or user must have permissions to perform theexecute-api:Invokeaction against the API.Cognito: This AuthZ option requires clients to login into Cognito and then pass the returned ID or Access JWT token in theAuthenticationheader.LambdaAuth: This AuthZ option is the most flexible and lets you execute a Lambda function to perform any custom auth strategy needed. A common use case for this is OpenID Connect.A Couple of TipsTip #1: Use Stage variables to avoid hard coding your backend Lambda and HTTP integrations. For example, you probably have multiple stages such as “QA” and “PROD” or “V1” and “V2.” You can define the same variable in each stage and specify different values. For example, you might an API that executes a Lambda function. In each stage, define the same variable calledfunctionArn. You can reference this variable as your Lambda ARN during your integration configuration using this notation:${stageVariables.functionArn}. API Gateway will inject the corresponding value for the stage dynamically at runtime, allowing you to execute different Lambda functions by stage.Tip #2: Use Path and Query variables to inject dynamic values into your HTTP integrations. For example, your cart API may define auserId Pathvariable that is used to lookup a user’s cart:/cart/profile/{userId}. You can inject this variable directly into your backend HTTP integration URL settings like this:http://myapi.someds.com/cart/profile/{userId}SummaryThis post covered strategies you should use to ensure your REST API architectures are scalable and easy to maintain.  I hope you’ve enjoyed this post and our next post will cover GraphQL API architectures withAWS AppSync.TAGS:REST APIs,serverless architecturesGeorge MaoGeorge Mao is a Specialist Solutions Architect at Amazon Web Services, focused on the Serverless platform. George is responsible for helping customers design and operate Serverless applications using services like Lambda, API Gateway, Cognito, and DynamoDB. He is a regular speaker at AWS Summits, re:Invent, and various tech events. George is a software engineer and enjoys contributing to open source projects, delivering technical presentations at technology events, and working with customers to design their applications in the Cloud. George holds a Bachelor of Computer Science and Masters of IT from Virginia Tech.
A few weeks ago, we kicked off this series with a discussion on REST vs GraphQL APIs. This post will dive deeper into the things an API architect or developer should consider when building REST APIs with Amazon API Gateway. Request Rate (a.k.a. “TPS”) Request rate is the first thing you should consider when designing REST APIs. […]
George Mao
Advanced (300) Amazon API Gateway Amazon RDS Amazon Simple Queue Service (SQS) Architecture AWS Lambda Intermediate (200)