Download to read offline
![© 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Now, the code we write…
API Gateway CreateUser model:
...
UserModel:
Type: AWS::ApiGateway::Model,
Properties:
Name: User,
Schema:
title: User,
properties: {
userId:
type: string
name:
type: string
required: ["userId", "name"]
New business logic
// create User function
exports.handler ((event) => {
const params = {
TableName: USERS_TABLE,
Item: {
userId: event.params.userId,
name: event.name,
},
}
// Write to database, return ID
const result = await DynamoDB.put(params).promise()
return result
)}](https://image.slidesharecdn.com/2019-09-jbeswick-apiworld-apisandyou-public-191011024242/85/Serverless-APIs-and-you-24-320.jpg)
Uploaded byJames Beswick
Serverless APIs and you
The document is a presentation by James Beswick on serverless APIs and AWS API Gateway, addressing modern development challenges such as agility, scaling, and security. It outlines API Gateway features, serverless architecture, integration, security practices, and best practices for building serverless applications. Additionally, it discusses techniques for managing API stages, payloads, and asynchronous operations.
More Related Content
Serverless APIs and you
- 1. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. James Beswick, AWS Serverless October 10, 2019 Serverless APIs andYou APIWorld, 2019
- 2. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. About me • James Beswick • Email: jbeswick@amazon.com • Twitter: @jbesw • Senior Developer Advocate – AWS Serverless • Self-confessed serverless geek • Software developer and Product Manager • Previously: • Multiple start-up tech guy • Rackspace, USAA, Morgan Stanley, J P Morgan • Enjoys comedy, travel, coffee and theme parks…
- 3. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Topics for today Advanced features of API Gateway Modern development environment Building serverless applications
- 4. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Modern development challenges Agility Scaling Security Complexity
- 5. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Modern development challenges Agility Scaling Security Complexity
- 6. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Amazon API Gateway features Fully managed Performance at scale Easy configuration Simple monitoring Robust security options Support agile development
- 7. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Amazon API Gateway features Fully managed Performance at scale Easy configuration Simple monitoring Robust security options Support agile development
- 8. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Application Programming Interface (API) Client API Web Server Database Request Response https://en.wikipedia.org/wiki/Application_programming_interface Web Services offer APIs for developers to use, e.g.: • Social Networks – Facebook, Twitter, etc. • Payment Processing – Amazon Pay, PayPal, etc.
- 9. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Serverless API Architecture Websites Services Amazon API Gateway API Gateway Cache Public Endpoints on Amazon EC2 Amazon CloudWatch Monitoring All publicly accessible endpoints Lambda Functions Endpoints in VPC Applications & Services in VPC Other AWS service Fully-managed CloudFront Distribution Edge-OptimizedRegionalPrivate Applications & Services in the same AWS Region AWS Direct Connect On-premises HTTPS Customer-managed CloudFront Distribution
- 10. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Type of APIs available Edge-Optimized • UtilizesCloudFront to reduce TLS connection overhead (reduces roundtrip time) • Designed for a globally distributed set of clients Regional • RecommendedAPI type for general use cases • Designed for building APIs for clients in the same region Private • Only accessible from withinVPC (and networks connected to VPC) • Designed for buildingAPIs used internally or by private microservices Amazon API Gateway API Gateway Cache Amazon CloudWatch Monitoring Fully-managed CloudFront Distribution Edge-OptimizedRegionalPrivate
- 11. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Set up your API via the Management Console…
- 12. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. … or with CloudFormation Create a REST API Proxy integration with Lambda POST method Stage name (Prod, Dev, etc)
- 13. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Building serverless applications
- 14. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Key attributes of serverless Automatically scales with demand Measurable, attributable No infrastructure to manage Granular permissions via IAM http requests, S3 PUTs, scheduled tasks, etc.
- 15. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Serverless is an ecosystem of services Amazon SNS AWS Step Functions Amazon EventBridge Amazon DynamoDB Amazon API Gateway Amazon S3AWS Lambda
- 16. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Application services Machine Learning Internet ofThings Analytics Web/Mobile/DigitalMedia
- 17. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Common serverless application types Web applications Backends Data processing Chatbots Amazon Alexa IT Automation
- 18. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. The coming wave of serverless web applications API Gateway handles all your application routing. It can handle authentication and authorization, throttling, DDOS protection, and more. Lambda runs all the logic behind your website and interfaces with databases, other backend services, or anything else your site needs. Amazon Simple Storage Service (Amazon S3) stores all of your static content:CSS, JS, images, and more. You would typically front this with a CDN such as CloudFront. Amazon S3 Amazon API Gateway AWS LambdaAmazon CloudFront
- 19. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Getting more out of API Gateway
- 20. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. How can I reduce boilerplate in my business logic?
- 21. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Many API Gateway integrations look like this… API Gateway configuration: Resources: MyFunction: Type: AWS::Serverless::Fn Properties: ... Events: ProxyApi: Type: Api Properties: Path: /{proxy+} Method: ANY Business logic const bodyParser = require('body-parser') const express = require('express') app.get('/', (req, res) => res.send('Hello World!')) app.get('/users/:userId', (req, res) => // DB lookup ) // create User endpoint app.post('/users', (req, res) => { const { userId, name } = req.body; if (typeof userId !== 'string') { res.status(400).json({ error: '"userId" must be a string' }) } else if (typeof name !== 'string') { res.status(400).json({ error: '"name" must be a string' })
- 22. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. First, have API Gateway handle the routing… Business logic const bodyParser = require('body-parser') const express = require('express') app.get('/', (req, res) => res.send('Hello World!')) app.get('/users/:userId', (req, res) => // DB lookup ) // create User endpoint app.post('/users', (req, res) => { const { userId, name } = req.body; if (typeof userId !== 'string') { res.status(400).json({ error: '"userId" must be a string' }) } else if (typeof name !== 'string') { res.status(400).json({ error: '"name" must be a string' }) API Gateway configuration: ... Events: HelloWorldAPI: Properties: Path: / Method: GET GetUserAPI: Properties: Path: /users/:userId Method: GET CreateUserAPI: Properties: Path: /users/ Method: POST
- 23. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Next, request validation… API Gateway CreateUser model: ... UserModel: Type: AWS::ApiGateway::Model, Properties: Name: User, Schema: title: User, properties: userId: type: string name: type: string required: - userId - name Business logic const bodyParser = require('body-parser') const express = require('express') app.get('/', (req, res) => res.send('Hello World!')) app.get('/users/:userId', (req, res) => // DB lookup ) // create User endpoint app.post('/users', (req, res) => { const { userId, name } = req.body; if (typeof userId !== 'string') { res.status(400).json({ error: '"userId" must be a string' }) } else if (typeof name !== 'string') { res.status(400).json({ error: '"name" must be a string' })
- 24. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Now, the code we write… API Gateway CreateUser model: ... UserModel: Type: AWS::ApiGateway::Model, Properties: Name: User, Schema: title: User, properties: { userId: type: string name: type: string required: ["userId", "name"] New business logic // create User function exports.handler ((event) => { const params = { TableName: USERS_TABLE, Item: { userId: event.params.userId, name: event.name, }, } // Write to database, return ID const result = await DynamoDB.put(params).promise() return result )}
- 25. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Payload modelling Websites Method Request • Modeling • Validation • Transformation Integration Request Amazon DynamoDB AWS Lambda Amazon S3 Integration Response Amazon DynamoDB AWS Lambda Amazon S3 Method Response • Transformation • Custom Errors Request Response Other AWS & On Premise Services Other AWS & On Premise Services
- 26. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Why use payload modelling? • Use native capabilities of API Gateway • Input validation – still in OWASP top 10 • Parameter type checking • Reduce boiler plate, focus your code on business logic • Reduce costs … how?
- 27. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. API Setup AWS Cloud Amazon API Gateway Weather Service Weather Table /(get) /premium (get)
- 28. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. API Setup AWS Cloud Amazon API Gateway Weather Service Weather Table /(get) /premium (get) Proxy “Lambda functions should transform not transport” - Ajay Nair Director, Product Management - Serverless
- 29. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. API Setup AWS Cloud Amazon API Gateway Weather Service Weather Table /(get) /premium (get) Proxy
- 30. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. No Compute AWS Cloud Amazon API Gateway Weather Service Weather Table /(get) /premium (get) Proxy Integration
- 31. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. The Integration Request {Request} {Request} VTL
- 32. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. The Integration Response {Response}{Response} VTL
- 33. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Direct service integration • Let API Gateway integrate directly with the downstream service • “Transform, don’t transport data”. • Saves on Lambda invocations ( = $) • Reduces code – and maintenance • Reduces latency by eliminating steps • Can improve scalability
- 34. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. How do I handle long-running synchronous requests?
- 35. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. API Gateway Integration timeout: 30 seconds Approaches: • Convert to asynchronous work • … with polling • … with webhooks • … withWebSockets • !API Gateway (IoT Core, ALB)
- 36. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. API Gateway Asynchronous: Polling Flow: 1. Client submits request and receives requestID 2. Backing service does work asynchronously, updating job status 3. Client polls for status of request 4. Client fetches results when work is complete API Gateway S3API Gateway Step Functions 1. /doWork 2 3. /status 4. /getResults
- 37. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. SNS API Gateway SQS Lambda Asynchronous: Webhooks Flow: 0. (optional)Trusted client setup with service. 1. Client submits request. API Gateway returns once request is stored. 2. Backing service does work asynchronously. 3. Backing service calls back to client when complete. 1 3 2
- 38. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. HTTP (REST) WebSocket Client Client • Request / Response • HTTP methods (e.g. GET, POST, etc.) • Short lived communication • Stateless • ServerlessWebSocket • 2 way communication channel • Long lived communication • Stateful Asynchronous: WebSockets
- 39. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Asynchronous: WebSockets - Implementation Flow: 1. Client submits request and receives SFn execution ARN, SFn task token, and WebSocket endpoint 2. Client opens connection toWebSocket endpoint with SFnARN and task token. Lambda completes OpenConn task 3. When DoWork is done, SFn parallel state completes, and we send callback 4. Client receives update over WebSockets API Gateway (websockets) Step Functions1 2 3 4 Lambda SFn Workflow API Gateway (REST) OpenConnDoWork Callback onConnect http://bit.ly/aws-poll-to-push
- 40. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. How can I handle larger payloads?
- 41. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Payload limits across services Amazon SNS 256 KB (SMS 1600b) AWS Lambda Sync: 6MB / Async: 256KB Amazon API Gateway HTTP: 10MB Amazon SQS 256KB AWS Step Functions 32 KB Amazon Kinesis 1MB
- 42. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Possible solutions • S3 • Pass the S3 key through the application • SQS – Java Extended Client Library – up to 2GB objects • Binary Payload Support • API Gateway • (Also available in SQS/SNS/DynamoDB)
- 43. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Can I manage multiple stages for my APIs?
- 44. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Staging Prod stage lambdaAlias = prod Dev stage lambdaAlias = dev Beta stage lambdaAlias = beta Stages Stage variable = lambdaAlias API Gateway
- 45. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Staging v0.0.1 v0.0.2 v0.0.3 v0.0.4 v0.0.5 v0.0.6 v0.0.7 v0.0.8 v0.0.9 prod beta dev aliases Prod stage lambdaAlias = prod Dev stage lambdaAlias = dev Beta stage lambdaAlias = beta Stages Stage variable = lambdaAlias API Gateway Lambda function
- 46. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Canary Releases My API Canary (Prod+1) Amazon CloudWatch Prod My API CanaryProd+1 Amazon CloudWatch
- 47. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Best Practices AWS Cloud Amazon API Gateway Lambda function Table AWS Secrets Manager AWS Cloud Amazon API Gateway Lambda function Table AWS Secrets Manager AWS Cloud Amazon API Gateway Lambda function Table AWS Secrets Manager Dev Account(s) Beta Account(s) Prod Account(s) SAM Template
- 48. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. How can I secure my API?
- 49. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. What does API security include? • Authentication and authorization • Access control: • CORS • Client-side SSL certificates • AWSWAF • Tracking and limiting access • Usage plans – API keys • Throttling
- 50. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Sample Weather Application AWS Cloud Mobile client Client Amazon API Gateway Lambda function Amazon DynamoDB AWS X-Ray Amazon CloudWatch
- 51. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. SecureWeather Application AWS Cloud AWS Cloud Amazon API Gateway Weather Service Weather Table Weather Update Service Event (time-based)Clients Amazon Cognito Host Bucket AWS WAFAWS IAM AccountTwoAccountOne AWS X-Ray Amazon CloudWatch CORS
- 52. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. SecureWeather Application AWS Cloud Amazon API Gateway Clients Amazon Cognito Cognito Authorizer • User authenticates via Cognito user pool • API Gateway authorizes via Cognito Authorizer
- 53. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. SecureWeather Application AWS Cloud AWS Cloud Amazon API Gateway Weather Update Service AWS IAM IAM Authorizer Cross Account authorization via resource policies and IAM authorizer AccountTwoAccountOne
- 54. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. SecureWeather Application AWS Cloud AWS Cloud Amazon API Gateway Weather Update ServiceClients Custom Authorizer (Custom Options) Custom Authorizer Clients and Services are authorized based on custom logic. AccountTwoAccountOne Corporate data center External Web Based Services Custom AWS Hosted Services
- 55. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. SecureWeather Application AWS Cloud AWS Cloud Amazon API Gateway Weather Update ServiceClients AWS WAF AWSWAF • Web Application Firewall • Blacklist/Whitelist • IP/IP range based • Logic based AccountTwoAccountOne
- 56. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. SecureWeather Application AWS Cloud Amazon API Gateway Clients CORS CORS • Cross Origin Resource Sharing • What API Gateway is responsible for • What application is responsible for
- 57. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Throttling Websites Service Public Endpoints on Amazon EC2 Authorized Mobile client Lambda Functions Any other AWS service All publicly accessible endpoints Mobile client Partner Websites Users Usage Plan Services Usage Plan Partner Usage Plan Per client Per client & per method Per method Per account
- 58. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Serverless APIs andYou Agility Scaling Security Complexity
- 59. © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Thank you! jbeswick@amazon.com
Editor's Notes
- #6 Comparing today’s IT landscape to 10 or 15 years ago, much has changed…
- #7 If you these together, we’re doing a lot more, much more quickly, but often with a huge operational burden.
- #13 After deployment, you get an https endpoint. You can also use a custom domain name with a managed SSL certificate if you prefer.
- #14 You can also use CloudFormation to achieve the same goal – walk through this screen. In addition to CF, we also offering SAM, a more serverless-specific deployment tool.
- #15 Having a serverless API is great but you can also leverage other services to build entirely serverless applications. This can help extend the benefits I talked about API Gateway having, throughout your stack.
- #16 Many people think Lambda is the same thing as serverless but that’s just the compute (FaaS) part. More broadly, serverless represents a number of services that share these attributes…
- #17 API Gateway is a serverless, web-scale service that is the “public doorway” for many serverless applications. Applications consist of several other services… Using a combination of these services, you can built low-code, highly-scalable, low-maintenance applications.
- #18 Combined with a range of application services, you can bring complex functionality into your apps. Using machine learning to bring image recognition, sentiment analysis or language translation with minimal coding Connect with the Internet of Things Deploy mobile apps to hundreds of thousands of customers with no infrastructure
- #20 Web apps are an interesting case thanks to some of the technology happening on the frontend. This is a very simple pattern that can give you: Global scale, high availability Removes dependence on a single webserver or cluster Delineates front-end and backend compute
- #23 The Gateway set up an ANY path and proxies everything to the target. The target business logic is now doing… Web server router middleware Body parsers Route management Request validation Where is the actual business logic in the handler?
- #24 In this first step, API Gateway now handles the routing (explain example). This is pseudocode so it fits on a slide… Three defined routes Include dynamic parameters, GET/POST, etc. Any routes not matching this are rejected by the gateway without calling your function
- #25 Now, let’s make API Gateway do the validation by using a model. Have the gateway check for the presence of the required parameters Also check their types
- #26 Now the function we write to handle the create user function does exactly that – it creates the user. The code no longer needs to check the presence of parameters or ensure type. This is part of a broader idea called payload modelling
- #29 Simple weather example: Two endpoints: one unauthenticated for basic data, another for premium info (using custom authorizer)
- #30 In this case where the API call is return items from a DynamoDB table, you don’t need the Lambda function.
- #31 Connect API Gateway directly to DDB
- #32 As an integration No compute required Faster API roundtrip Potentially more scalable, depending on how this was setup How can you convert the DDB items to an API response without the compute layer?
- #33 Request can be modified at API GW level using Velocity Template Language Velocity is a Java-based template engine, open sourced by Apache Ensures clean separation between the presentation tier and business tiers in a Web application (MVC model)
- #34 Response can be modified at API GW level using VTL
- #37 Is the API Gateway HTTP integration timeout of 30 seconds too short for you? Some developers have an existing, synchronous web service that can take longer than 30sec to respond. There are three common patterns to convert a synchronous API call to asynchronous ...
- #38 Response payload: - < 10 MB (APIGW payload limit) – Return the caller of /getResults the actual result of the work - > 10MB – Return the caller of /getResults an S3 presigned download URL
- #39 Execution time (similar considerations to the polling pattern): <15 mins – SQS to Lambda >= 15 minutes – Step Functions or AWS Batch Response payload (similar to the polling pattern, but now with SNS’ payload limits): <= 256kb – SNS > 256kb – SNS + S3 presigned URL
- #41 Why not just open the WebSocket API for the request? - RESTful APIs have strong controls to ensure user requests are validated – provides guardrails for the intended query purpose. Helps prevent rogue requests (especially when exposed to a large number of users). - REST validation framework can detect header info on browser compatibility - request layer can pass this browser metadata and determine whether a WebSocket API can be opened. - If low-latency request/response are critical, and there aren’t any browser-compatibility risks, use a WebSocket API with JSON model selection expressions to protect your backend with a schema. - Best practice: use a REST API for the request layer and a WebSocket API to listen for the result.
- #43 As you start to stitch together Serverless services, you may hit payload sizes as your data flows through them.
- #46 Stages can help deploy different versions of the same API to different audiences. Always 1 stage in every deployment. Map stages to anywhere but you can automate the reference to a Lamdba version using Stage variables. Stage vars: - These are associated w/ a deployment stage of a REST API. - They act like environment variables and can be used in your API setup/mapping templates. - You can map a stage for a given API to different integrations based upon stages.
- #47 Lambda function versions are immutable when published. You can define aliases for Lambda versions. Then ref this Lambda alias. When you change the Lambda version an alias point to, the API Gateway stage is automatically updated.
- #49 Stages are a good feature but for larger apps and projects there is a better way. Why? For larger teams, use multiple AWS accounts. 10-12 devs = 10-12 accounts. One beta, gamma, alpha – one prod. Also – AWS secrets manager.
- #51 There are a number of things to consider around API security, especially as API Gateway is your application’s “front door”
- #52 Let’s look at a simple, unsecured weather app as an example… Structurally makes sense – explain flow… Not secured: Unauthenticated access to API No usage limits
- #53 Now let’s compare with a secure version of the same app. This is the same app implemented securely. Adds another AWS account for a “weather update” service so we can talk about some a/c to a/c security.
- #54 First, it uses a Cognito authorizer to authenticate calls from users. Allows simple username/password login, passing a token to the gateway to authenticate the user. Can also support social login via Google, Facebook or use OpenID or SAML identity providers Can federate through third party identity provider (IdP). This can include MFA checks for compromised credentials, account takeover protection, and phone and email verification API Gateway: You can use groups in a user pool to control permissions with API Gateway by mapping group membership to IAM roles. The groups that a user is a member of are included in the ID token provided by a user pool when your app user signs in. More Cognito info: User pools are user directories that provide sign-up and sign-in options for your web and mobile app users. - The user pool manages the overhead of handling the tokens that are returned from social sign-in, and from OpenID Connect (OIDC) and SAML IdPs Identity pools provide AWS credentials to grant your users access to other AWS services. - Identity pools support anonymous guest users, as well as federation through third-party IdPs.
- #55 In the case of this weather app, there is a second Lambda in another account that can call the API Gateway. The best practice here is to use the IAM authorizer – the caller is authenticated based upon IAM permissions and there are no passwords or secrets to manage. This IAM approach is designed specifically for account-to-account access (or private API access). In both approaches: All managed through configuration No code
- #56 Now if it were necessary to use some custom identity setup, this is where a custom authorizer is useful. This involves writing your own solution as a Lambda function. The Gateway will call this function to authorize access and you can use any authorization logic you prefer. Suited for: Non-AWS auth (like Auth0, JWTs for another service) Corporate data center – LDAP, SAML External services dependent on this service Your function must return a valid IAM policy. Benefits: Centralize your auth logic in a single function rather than packaging it up as a library into each of your functions. If your auth logic changes in the future, you can simply redeploy a single fn. Cache responses. usually your auth logic will need to make a remote call. This can add unneeded latency if you’re running this check within every function. By isolating the remote call in your custom authorizer, you will only need to pay the price once. Cache the value for up to 1hr.
- #57 Ensure that AWS Web Application Firewall (WAF) is integrated with Amazon API Gateway to protect your APIs from common web exploits: such as SQL injection attacks, cross-site scripting (XSS) attacks and Cross-Site Request Forgery (CSRF) attacks … that could affect API availability and performance, compromise API data security or consume excessive resources. AWS WAF protects web applications from attacks by filtering traffic based on rules that you create. For example, you can filter web requests based on IP addresses, HTTP headers, HTTP body, or URI strings,
- #58 CORS: What is it? - Cross-origin resource sharing is a mechanism that allows restricted resources on a web page to be requested from another domain outside the domain from which the first resource was served - mechanism that uses additional HTTP headers to tell browsers to give a web application running at one origin, access to selected resources from a different origin - Can be complex and frustrating for developers Key - “If your REST API's resources receive non-simple cross-origin HTTP requests, you need to enable CORS support.” Enabling CORS Support for Lambda or HTTP Non-Proxy Integrations and AWS Service Integrations For a Lambda custom integration, HTTP custom (non-proxy) integration, or AWS service integration, you can set up the required headers by using API Gateway method response and integration response settings. API Gateway will create an OPTIONS method and attempt to add the Access-Control-Allow-Origin header to your existing method integration responses. Enabling CORS Support for Lambda or HTTP Proxy Integrations For a Lambda proxy integration or HTTP proxy integration, you can still set up the required OPTIONS response headers in API Gateway. However, your backend is responsible for returning theheaders, because a proxy integration doesn't return an integration response.
- #59 Amazon API Gateway provides two basic types of throttling-related settings: - Server-side throttling limits are applied across all clients. These limit settings exist to prevent your API— and your account — from being overwhelmed by too many requests. Per-client throttling limits are applied to clients that use API keys associated with your usage policy as client identifier. API Gateway throttling-related settings are applied in the following order: Per-client per-method throttling limits that you set for an API stage in a usage plan Per-client throttling limits that you set in a usage plan Default per-method limits and individual per-method limits that you set in API stage settings Account-level throttling Account-level throttling – soft limit / 10k/sec (burst of 5k) A usage plan specifies who can access one or more deployed API stages and methods — and also how much and how fast they can access them. The plan uses API keys to identify API clients and meters access to the associated API stages for each key. It also lets you configure throttling limits and quota limits that are enforced on individual client API keys. - A throttling limit is a request rate limit that is applied to each API key that you add to the usage plan. You can also set a default method-level throttling limit for an API or set throttling limits for individual API methods. A quota limit is the maximum number of requests with a given API key that can be submitted within a specified time interval. You can configure individual API methods to require API key authorization based on usage plan configuration