All Posts

Interactive Reference Architecture

Click on the components or numbered steps below to explore how this architecture works.

The Storage First pattern is useful when your application doesn’t require a lot of data transformation on incoming API requests. Rather than attaching API Gateway to a Lambda function that has to parse, process, transform, and save data, we can bypass the Lambda function by using a “service integration” that will send the data directly to an AWS service, like SQS. This reduces the latency of our API calls, saves money by removing the need to run a processing Lambda function, and makes our application more reliable because we are not introducing additional code.

In our example above, we’re using an SQS queue and then processing data off of that using a Lambda function subscription. There are plenty of other services that can be written to directly including DynamoDB, Kinesis, and EventBridge. To the best of my knowledge, Eric Johnson from AWS coined the term “Storage First” to indicate that we want to ensure that we save a user’s raw data before we attempt to run any processing on it. That way, if downstream services or processing fails, we always have a copy of the original request. He explains the process in his post Building a serverless URL shortener app without AWS Lambda.

The incoming data can be transformed and verified using VTL templates, but the more complexity you introduce, the more likely you are to create issues with edge cases. This is an incredibly useful pattern for high velocity workloads like webhooks and clickstream data because it provides low latency and high reliability. Additional processing can be done asynchronously, allowing you to add resiliency to your application if downstream systems are unavailable.

Deploy this Pattern

Below are the basic configurations for deploying this pattern using different frameworks and platforms. Additional configuration for your environment will be necessary. The source files and additional examples are available in the GitHub repo.

• SAM
• Stackery
• Serverless Framework
  TO IMPLEMENT

Interactive Reference Architecture

Click on the components or numbered steps below to explore how this architecture works.

The Circuit Breaker pattern keeps track of the number of failed (or slow) API calls by using a cache to share the status across multiple Lambda functions. In this example, we’re using a DynamoDB table so that we can avoid using a VPC. If you were in a VPC already, ElastiCache would be a good alternative.

Here’s how it works. When the number of failures reaches a certain threshold, we “open” the circuit and send errors back to the calling client immediately without even trying to call the API. After a short period of time, we “half open” the circuit, sending just a few requests through to see if the API is finally responding correctly. All other requests receive an error. If the sample requests are successful, we “close” the circuit and start letting all traffic through. However, if some or all of those requests fail, the circuit stays “open”, and the process repeats with some algorithm for increasing the timeout between “half open” retry attempts.

This is an incredibly powerful (and cost saving) pattern for any type of synchronous request to an API or downstream system. You are accumulating charges whenever a Lambda function is running and waiting for another task to complete. Allowing your systems to self-identify issues like this, provide incremental backoff, and then self-heal when the service comes back online, adds a tremendous amount of resiliency to your applications.

Deploy this Pattern

Below are the basic configurations for deploying this pattern using different frameworks and platforms. Additional configuration for your environment will be necessary. The source files and additional examples are available in the GitHub repo.

• • SAM
  • Stackery
  • Serverless Framework
    service: simple-web-service provider: name: aws runtime: nodejs12.x stage: ${opt:stage,'dev'} region: us-east-1 stackName: ${self:service}-${self:provider.stage} stackTags: SERVICE: ${self:service} httpApi: payload: '2.0' cors: true functions: GetUser: handler: index.handler memorySize: 1024 timeout: 6 tracing: Active environment: TABLE_NAME: !Ref Users TABLE_ARN: !GetAtt Users.Arn iamRoleStatementsName: ${self:service}-${self:provider.stage}-getuser-role iamRoleStatements: - Effect: Allow Action: - dynamodb:getItem - dynamodb:putItem - dynamodb:updateItem - dynamodb:deleteItem Resource: - !Join [ '/', [ !GetAtt Users.Arn, '*' ] ] - !GetAtt Users.Arn - Effect: Allow Action: - xray:PutTraceSegments - xray:PutTelemetryRecords Resource: "*" events: - httpApi: path: /user/{id} method: get plugins: - serverless-iam-roles-per-function resources: Resources: Users: Type: AWS::DynamoDB::Table Properties: AttributeDefinitions: - AttributeName: id AttributeType: S BillingMode: PAY_PER_REQUEST KeySchema: - AttributeName: id KeyType: HASH StreamSpecification: StreamViewType: NEW_AND_OLD_IMAGES

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

    service: simple-web-service provider:   name: aws   runtime: nodejs12.x   stage: ${opt:stage,'dev'}   region: us-east-1   stackName: ${self:service}-${self:provider.stage}   stackTags:     SERVICE: ${self:service}   httpApi:     payload: '2.0'     cors: true   functions:   GetUser:     handler: index.handler     memorySize: 1024     timeout: 6     tracing: Active     environment:       TABLE_NAME: !Ref Users       TABLE_ARN: !GetAtt Users.Arn     iamRoleStatementsName: ${self:service}-${self:provider.stage}-getuser-role     iamRoleStatements:       - Effect: Allow         Action:           - dynamodb:getItem           - dynamodb:putItem           - dynamodb:updateItem           - dynamodb:deleteItem         Resource:           - !Join [ '/', [ !GetAtt Users.Arn, '*' ] ]           - !GetAtt Users.Arn       - Effect: Allow         Action:           - xray:PutTraceSegments           - xray:PutTelemetryRecords         Resource: "*"     events:       - httpApi:           path: /user/{id}           method: get   plugins:   - serverless-iam-roles-per-function   resources:   Resources:     Users:       Type: AWS::DynamoDB::Table       Properties:         AttributeDefinitions:           - AttributeName: id             AttributeType: S         BillingMode: PAY_PER_REQUEST         KeySchema:           - AttributeName: id             KeyType: HASH         StreamSpecification:           StreamViewType: NEW_AND_OLD_IMAGES

Interactive Reference Architecture

Click on the components or numbered steps below to explore how this architecture works.

This is the most basic of patterns you’re likely to see with serverless applications. The Simple Web Service fronts a Lambda function with an API Gateway. I’ve shown DynamoDB as the database here because it scales nicely with the high concurrency capabilities of Lambda.

Deploy this Pattern

Below are the basic configurations for deploying this pattern using different frameworks and platforms. Additional configuration for your environment will be necessary. The source files and additional examples are available in the GitHub repo.

• SAM
• Stackery
• Serverless Framework
  service: simple-web-service provider: name: aws runtime: nodejs12.x stage: ${opt:stage,'dev'} region: us-east-1 stackName: ${self:service}-${self:provider.stage} stackTags: SERVICE: ${self:service} httpApi: payload: '2.0' cors: true functions: GetUser: handler: index.handler memorySize: 1024 timeout: 6 tracing: Active environment: TABLE_NAME: !Ref Users TABLE_ARN: !GetAtt Users.Arn iamRoleStatementsName: ${self:service}-${self:provider.stage}-getuser-role iamRoleStatements: - Effect: Allow Action: - dynamodb:getItem - dynamodb:putItem - dynamodb:updateItem - dynamodb:deleteItem Resource: - !Join [ '/', [ !GetAtt Users.Arn, '*' ] ] - !GetAtt Users.Arn - Effect: Allow Action: - xray:PutTraceSegments - xray:PutTelemetryRecords Resource: "*" events: - httpApi: path: /user/{id} method: get plugins: - serverless-iam-roles-per-function resources: Resources: Users: Type: AWS::DynamoDB::Table Properties: AttributeDefinitions: - AttributeName: id AttributeType: S BillingMode: PAY_PER_REQUEST KeySchema: - AttributeName: id KeyType: HASH StreamSpecification: StreamViewType: NEW_AND_OLD_IMAGES

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

  service: simple-web-service provider:   name: aws   runtime: nodejs12.x   stage: ${opt:stage,'dev'}   region: us-east-1   stackName: ${self:service}-${self:provider.stage}   stackTags:     SERVICE: ${self:service}   httpApi:     payload: '2.0'     cors: true   functions:   GetUser:     handler: index.handler     memorySize: 1024     timeout: 6     tracing: Active     environment:       TABLE_NAME: !Ref Users       TABLE_ARN: !GetAtt Users.Arn     iamRoleStatementsName: ${self:service}-${self:provider.stage}-getuser-role     iamRoleStatements:       - Effect: Allow         Action:           - dynamodb:getItem           - dynamodb:putItem           - dynamodb:updateItem           - dynamodb:deleteItem         Resource:           - !Join [ '/', [ !GetAtt Users.Arn, '*' ] ]           - !GetAtt Users.Arn       - Effect: Allow         Action:           - xray:PutTraceSegments           - xray:PutTelemetryRecords         Resource: "*"     events:       - httpApi:           path: /user/{id}           method: get   plugins:   - serverless-iam-roles-per-function   resources:   Resources:     Users:       Type: AWS::DynamoDB::Table       Properties:         AttributeDefinitions:           - AttributeName: id             AttributeType: S         BillingMode: PAY_PER_REQUEST         KeySchema:           - AttributeName: id             KeyType: HASH         StreamSpecification:           StreamViewType: NEW_AND_OLD_IMAGES

• Pulumi
  // Full example: https://github.com/jeremydaly/reference-architectures/tree/master/simple-web-service/pulumi import * as aws from "@pulumi/aws"; import * as awsx from "@pulumi/awsx"; // Provision a DynamoDB Table. const users = new aws.dynamodb.Table("users", { attributes: [{ name: "id", type: "S", }], hashKey: "id", billingMode: "PAY_PER_REQUEST", streamViewType: "NEW_AND_OLD_IMAGES", }); // Create an API Gateway with a single /user/{id} route that uses the Table. // This uses the default Lambda, IAM, and name settings; for full control over // them, see the aws.lambda.CallbackFunction class, which can be allocated // separately and passed instead of the inline eventHandler below. const api = new awsx.apigateway.API("api", { routes: [{ path: "/user/{id}", method: "GET", eventHandler: async (event, context) => { const tableName = users.name.get(); const tableArn = users.arn.get(); return { statusCode: 200, body: JSON.stringify(event) }; }, }] }); // Export the resulting API Gateway URL: export const url = api.url;

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

  // Full example: https://github.com/jeremydaly/reference-architectures/tree/master/simple-web-service/pulumi   import * as aws from "@pulumi/aws"; import * as awsx from "@pulumi/awsx";   // Provision a DynamoDB Table. const users = new aws.dynamodb.Table("users", {     attributes: [{         name: "id",         type: "S",     }],     hashKey: "id",     billingMode: "PAY_PER_REQUEST",     streamViewType: "NEW_AND_OLD_IMAGES", });   // Create an API Gateway with a single /user/{id} route that uses the Table. // This uses the default Lambda, IAM, and name settings; for full control over // them, see the aws.lambda.CallbackFunction class, which can be allocated // separately and passed instead of the inline eventHandler below. const api = new awsx.apigateway.API("api", {     routes: [{         path: "/user/{id}",         method: "GET",         eventHandler: async (event, context) => {             const tableName = users.name.get();             const tableArn = users.arn.get();             return { statusCode: 200, body: JSON.stringify(event) };         },     }] });   // Export the resulting API Gateway URL: export const url = api.url;

• CDK
  Are you a CDK Guru?
  Would you like to contribute patterns to the community?
  Check out the Github repo!

Interactive Reference Architecture

Click on the components or numbered steps below to explore how this architecture works.

If you’re building a webhook, the traffic can often be unpredictable. This is fine for Lambda, but if you’re using a “less-scalable” backend like RDS, you might just run into some bottlenecks. There are ways to manage this, but because Lambda supports SQS triggers, we can throttle our workloads by queuing the requests and then using a throttled (low concurrency) Lambda function to work through our queue. Under most circumstances, your throughput should be near real-time. If there is some heavy load for a period of time, you might experience some small delays as the throttled Lambda chews through the messages.

You’ll also want to handle failed messages using a Dead Letter Queues (DLQ). The SQS Poller will adjust its polling frequency based on your Lambda function’s concurrency. You’ll need to configure your redrive policies to appropriately handle failed messages.

Deploy this Pattern

Below are the basic configurations for deploying this pattern using different frameworks and platforms. Additional configuration for your environment will be necessary. The source files and additional examples are available in the GitHub repo.

• SAM
• Stackery
• Serverless Framework
  # Code sample coming soon

  1	# Code sample coming soon

• CDK
  Are you a CDK Guru?
  Would you like to contribute patterns to the community?
  Check out the Github repo!

Interactive Reference Architecture

Click on the components or numbered steps below to explore how this architecture works.

The Strangler is another popular pattern that lets you incrementally replace pieces of an application with new or updated services. Typically you would create some sort of a “Strangler Facade” to route your requests, but API Gateway can actually do this for us using “AWS Service Integrations” and “HTTP Integrations”. For example, an existing API (front-ended by an Elastic Load Balancer) can be routed through API Gateway using an “HTTP” integration. You can have all requests default to your legacy API, and then direct specific routes to new serverless service as you add them.

Deploy this Pattern

Below are the basic configurations for deploying this pattern using different frameworks and platforms. Additional configuration for your environment will be necessary. The source files and additional examples are available in the GitHub repo.

• SAM
• Stackery
• Serverless Framework
  # Code sample coming soon

  1	# Code sample coming soon

• CDK
  Are you a CDK Guru?
  Would you like to contribute patterns to the community?
  Check out the Github repo!