This whitepaper is for historical reference only. Some content might be outdated and some links might not be available.

# Sample architecture patterns
<a name="sample-architecture-patterns"></a>

 You can implement popular architecture patterns using API Gateway and AWS Lambda as your logic tier. This whitepaper includes the most popular architecture patterns that leverage AWS Lambda-based logic tiers: 
+  **Mobile backend -** A mobile application communicates with API Gateway and Lambda to access application data. This pattern can be extended to generic HTTPS clients that don't use serverless AWS resources to host presentation tier resources (such as desktop clients, web server running on EC2, and so forth). 
+  **Single page application **- A single page application hosted in Amazon S3 and CloudFront communicates with API Gateway and AWS Lambda to access application data. 
+  **Web application ** – The web application is a general-purpose, event-driven, web application back-end that uses AWS Lambda with API Gateway for its business logic. It also uses DynamoDB as its database and Amazon Cognito for user management. All static content is hosted using Amplify. 

 In addition to these two patterns, this whitepaper discusses the applicability of Lambda and API Gateway to a general microservice architecture. A microservice architecture is a popular pattern that, although not a standard three-tier architecture, involves decoupling application components and deploying them as stateless, individual units of functionality that communicate with each other. 

# Mobile backend
<a name="mobile-backend"></a>

![\[Architectural pattern for serverless mobile backend\]](http://docs.aws.amazon.com/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/arch-pattern-serverless-mobile-backend.png)


* Architectural pattern for serverless mobile backend *

* Table 1 - Mobile backend tier components *


|  Tier  |  Components  | 
| --- | --- | 
|  Presentation  |  Mobile application running on a user device.  | 
|  Logic  |   Amazon API Gateway with AWS Lambda.   This architecture shows three exposed services (`/tickets`, `/shows`, and `/info`). API Gateway endpoints are secured by [Amazon Cognito user pools](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html) In this method, users sign in to Amazon Cognito user pools (using a federated third-party if necessary), and receive access and ID tokens that are used to authorize API Gateway calls.   Each Lambda function is assigned its own Identity and Access Management (IAM) role to provide access to the appropriate data source.   | 
|  Data  |   DynamoDB is used for the `/tickets` and `/shows` services.   Amazon RDS is used for the `/info` service. This Lambda function retrieves Amazon RDS credentials from AWS Secrets Manager and uses an elastic network interface to access the private subnet.   | 

# Single-page application
<a name="single-page-application"></a>

![\[AWS architecture diagram showing interactions between services like CloudFront, S3, Lambda, and DynamoDB.\]](http://docs.aws.amazon.com/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/single-page-application.png)


* Architectural pattern for serverless single-page application *

* Table 2 - Single-page application components *


|  Tier  |  Components  | 
| --- | --- | 
|  Presentation  |   Static website content hosted in Amazon S3, distributed by CloudFront.   AWS Certificate Manager allows a custom SSL/TLS certificate to be used.   | 
|  Logic  |   API Gateway with AWS Lambda.   This architecture shows three exposed services (`/tickets`, `/shows`, and `/info`). API Gateway endpoints are secured by a Lambda authorizer. In this method, users sign in through a third-party identity provider and obtain access and ID tokens. These tokens are included in API Gateway calls, and the Lambda authorizer validates these tokens and generates an IAM policy containing API initiation permissions.   Each Lambda function is assigned its own IAM role to provide access to the appropriate data source.   | 
|  Data  |   Amazon DynamoDB is used for the `/tickets` and `/shows` services.   Amazon ElastiCache is used by the `/shows` service to improve database performance. Cache misses are sent to DynamoDB.   Amazon S3 is used to host static content used by the `/info service`.   | 

# Web application
<a name="web-application"></a>

![\[AWS Cloud architecture diagram showing client interaction with various AWS services.\]](http://docs.aws.amazon.com/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/web-application.png)


* Architectural pattern for web application *

* Table 3 - Web application components *


|  Tier  |  Components  | 
| --- | --- | 
|  Presentation  |   The front-end application is all static content (HTML, CSS, JavaScript and images) which are generated by React utilities like create-react-app. Amazon CloudFront hosts all these objects. The web application, when used, downloads all the resources to the browser and starts to run from there. The web application connects to the backend calling the APIs.   | 
|  Logic  |   Logic layer is built using Lambda functions fronted by API Gateway REST APIs.   This architecture shows multiple exposed services. There are multiple different Lambda functions each handling a different aspect of the application. The Lambda functions are behind API Gateway and accessible using API URL paths.  The user authentication is handled using Amazon Cognito user pools or federated user providers. API Gateway uses out of box integration with Amazon Cognito. Only after a user is authenticated, the client will receive a JSON Web Token (JWT) token which it should then use when making the API calls. Each Lambda function is assigned its own IAM role to provide access to the appropriate data source.  | 
|  Data  |   In this particular example, DynamoDB is used for the data storage but other purpose-built Amazon database or storage services can be used depending on the use case and usage scenario.   | 

# Microservices with Lambda
<a name="microservices-with-lambda"></a>

![\[AWS Cloud architecture with API Gateways and Lambda functions across two accounts.\]](http://docs.aws.amazon.com/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/microservices-with-lambda.png)


* Architectural pattern for microservices with Lambda *

 The microservice architecture pattern is not bound to the typical three-tier architecture; however, this popular pattern can realize significant benefits from the use of serverless resources. 

 In this architecture, each of the application components are decoupled and independently deployed and operated. An API created with Amazon API Gateway, and functions subsequently launched by AWS Lambda, is all that you need to build a microservice. Your team can use these services to decouple and fragment your environment to the level of granularity desired. 

 In general, a microservices environment can introduce the following difficulties: repeated overhead for creating each new microservice, issues with optimizing server density and utilization, complexity of running multiple versions of multiple microservices simultaneously, and proliferation of client-side code requirements to integrate with many separate services. 

 When you create microservices using serverless resources, these problems become less difficult to solve and, in some cases, simply disappear. The serverless microservices pattern lowers the barrier for the creation of each subsequent microservice (API Gateway even allows for the cloning of existing APIs, and usage of Lambda functions in other accounts). Optimizing server utilization is no longer relevant with this pattern. Finally, Amazon API Gateway provides programmatically generated client SDKs in a number of popular languages to reduce integration overhead.