API Gateway case study

Deliverables:
1. Amazon API Gateway self-assessment
2. Best practices
3. Microsite URL
4. Case Studies: Kauffman diagrams, Kauffman account ID
Amazon API Gateway AWS Service Delivery Validation Checklist
2.1 Customer Case Studies
● Problem statement/definition
○ Customer has multiple backend applications which serve HTTP web requests.
○ Need to develop a unified layer (API Gateway) to serve API requests for Web
and Mobile applications and third-party developers with the following
characteristics:
■ unified authentication mechanism
■ Support multiple environments
■ Easy deployment and drift management
■ Support swagger-based documentation/code
■ Ability to throttle requests based on usage plan
■ Secure traffic between API Gateway and backend endpoints
● What you proposed
○ Implement AWS API Gateway with ElasticBeanstalk backend, CloudWatch
monitoring and Custom Lambda Authorizer
● How AWS services were used as part of the solution
○ VPC/Subnets – provide virtual network configuration
○ AWS Gateway API to serve all REST API requests
○ Lambda custom authorizer to process authentication requests
○ CloudWatch for monitoring and alarming
○ ElasticBeanstalk to process REST requests
○ RDS to operate MySql in cost-efficient and scalable way
○ AWS ElasticSearch to manage and operate Elasticsearch cluster
○ Route 53
● Third party applications solutions used
○
● Start and end dates of project
○
● Outcomes/results
○
● Lesson Learned
2.2 architecture Diagrams(need to change icons, good to have links to cloudwatch, HTTPs?,
cloudfront – 3 origins?, elastic beanstalk not in diagram, )
● Architecture diagrams must detail how the solution interacts with the AWS Cloud;
specifically, what AWS tools and services are used in the solution Diagrams must also
include evidence of AWS best practices for architecture and security
3.0 Self-Assessment
● Type of API Gateway solution being delivered
○ Use API Gateway to REST APIs to leverage HTTP requests
○ call HTTP endpoints hosted on AWS Elastic Beanstalk
● Number of expected RPS
○ 20-30 RPS
● Details on guidance that was provided to the customer in order to enable them to setup
an effective monitoring solution for their API and should include the basic metrics
provided by Amazon CloudWatch.(mb RPS + some alarms, authorizations
attempts(failed and passed)
○ API Calls
○ Latency
○ INtegration Latency
○ 4xx Error
○ 5x Error
● Recommended to and external monitoring service (e.g. Pingdom/PagerDuty)
● ……..
● Details on API design deployed in Amazon API Gateway, including implementation
details, specific API Gateway features implemented, API structure/complexity, etc.
○ Leverage an existing backend: AWS Elastic Beanstalk applications
○ Dockerize all backend applications
○ Support multiple environment by levering API Stages
○ Use Authorizer Lambda
○ Enabled authorization caching
○ Use API Keys for Third-Party Developers to provide fine-grained access
permissions
○ Use swagger for API deployment and maintenance (ADD link to API docs)
○ Use client-side SSL certificates for HTTP backend authentication within AWS API
Gateway
○ Use APIs created with Amazon API Gateway have AWS CloudWatch logging
enabled
○ Use detailed CloudWatch metrics are enabled for Amazon API Gateway APIs
stages.
○ Ensure APIs created with Amazon API Gateway have active tracing support for
AWS X-Ray enabled
○ Use stage variables to manage different environments
○ Certificate Manager
○ System Manager (Parameter Store)
● Details of how the partner identified the performance requirements of the customer’s
application and implemented the correct mitigations to protect the backend
infrastructure, including, at a minimum, one of the following: Usage plans Throttling
Caching (Native or Amazon CloudFront) Details on how the deployment was managed
to create repeatable and versioned deployments that result in zero downtime through the
use of the at least one of following capabilities across all case studies: Stages Canary
Release Deployments Supporting Versioning of APIs Details on automating the creation
or updating Amazon API Gateway resources using: AWS CloudFormation Serverless
Application Model (SAM) Swagger Or other Infrastructure as Code tooling
○ Chose API Gateway for list functionalities:
■ Throttling
■ API documentation
■ Use of swagger to manage apis
■ …
○ Performance? May be investigate the current solution and its performance
metrics to select API Gateway. Why don’t we use EC2 as a API gateway? –
scaling, cost, some in-build features like caching, API keys, stages/versions. etc.
○ CI/CD
■ Use GitLab as code repo and CI/CD pipeline
■ Use gitflow workflow to manage branches/releases
■ API gateway and backend applications were deployed in a single process
to make sure the entire infrastructure/stage apps are in sync
■ API Gateway deploy code snippets:
aws apigateway put-rest-api –rest-api-id $AWS_PROD_GATEWAY_ID –mode overwrite –body
‘file://$GATEWAY_SWAGGER_FILE’ –region $AWS_REGION
aws apigateway update-rest-api –rest-api-id $AWS_PROD_GATEWAY_ID –patch-operations
op=replace,path=/apiKeySource,value=AUTHORIZER –region $AWS_REGION
aws apigateway create-deployment –rest-api-id $AWS_PROD_GATEWAY_ID –stage-name prod
–description $TAG –region $AWS_REGION
aws elasticbeanstalk update-environment –environment-name
$AWS_APPLICATION_ENVIRONMENT_NAME –version-label $TAG –region $AWS_REGION
● Across all submitted case studies should demonstrate proficiency in at least two of the
following areas, as well why each implementation was used: AWS Service Proxy
Integrations HTTP Proxy Integrations Using Custom Domains and AWS Certificate
Manager integration Edge Optimized, Regional, or Private endpoints
○ As client’s customers are world wide distributed
3.2.1 Solution Characteristics: Submitted case studies must include at least one of the following
use cases: Framework for Data Ingestion Framework for Data Processing Framework for Data
Transformation Framework for Data Storage Framework for Data Delivery and Display (BI)