DEV Community: Serverless By Theodo

Avoiding API Gateway’s integrations hard limit: scaling serverless architectures efficiently

Anaïs Schlienger — Tue, 26 Nov 2024 07:00:00 +0000

Avoid AWS API Gateway’s integration limit with efficient multi-API Gateway setups. Learn how to scale serverless projects!

Last week, I was coding a new feature. It was looking good, until I had to deploy. AWS cli yelled at me and refused to deploy my stack. I got the following error : CREATE_FAILED: HttpApiIntegration (AWS::ApiGatewayV2::Integration) Maximum number of Integrations for this API has been reached. Did this ever happen to you? If it did not, and you are using AWS, then it might be worth to run a quick sanity check on your architecture.

AWS combined with API Gateway is widely used for scale-up apps. If API Gateway can handle a lot of routes (there is a 300 quota that can be increased), it has however a lesser-known but critical limitation of 300 integrations per API Gateway instance.

An API Gateway integration is a connection between an API Gateway and a backend service, such as a Lambda function, an HTTP endpoint, or an AWS service, allowing the API Gateway to route incoming requests to the appropriate service for processing and return responses to the client. An endpoint can have only one integration. Here is a great article about integrations.

In a non-monolithic serverless architecture, where every Lambda function represents a different endpoint, it’s easy to hit this limit once your app grows. This was exactly what happened to me in a large-scale serverless project using the Serverless Framework.

The challenge: reaching API Gateway’s 300 integration limit

Let’s represent my project as an online library, where users can read, buy, lend and comment on books. The backend is split into two services, users and books, representing the core features.

Our architecture, typical of many non-monolithic setups, follows a one Lambda per endpoint model. When you have multiple services each exposing dozens of endpoints, it doesn’t take long to bump against the 300 integration per API limit (in this simplified example with only 2 services, it might take a long time I agree). This bottleneck emerged (I was not aware of it before!) when our API maxed out its available integrations and simply refused to deploy.

Evaluating the options: lambda-lith vs micro-APIs

With an architecture with all services living behind the same API Gateway, we faced two clear paths forward:

Split the API into smaller chunks (micro-APIs).
Shift to a more monolithic Lambda setup, where multiple endpoints share a Lambda.

Going down the monolith route would have required significant changes to our architecture, a large refactor, and a fair amount of coordination with the front-end. This wasn't ideal for us since we wanted minimal disruption to our existing setup and quick implementation. So we opted for the second option: splitting the API into smaller chunks by creating a new API Gateway for each service.

This approach allowed us to break our system into manageable micro-services while keeping our frontend mostly unchanged.

The solution: multi-API Gateways behind CloudFront

The architecture change was made easier by the fact that we had CloudFront in front of our API Gateway. Our frontend communicates with CloudFront, and CloudFront handles routing requests to our API.

This setup meant that adding new API Gateways could be done without any drastic changes to the frontend. All we needed to do was redirect calls to the appropriate API Gateway, based on the service prefix.

Here’s how we did it step-by-step:

Step 1: create a new API Gateway for the `user` service

We began by creating a new API Gateway for the user service. Since this was essentially a new API, we also had to configure a new Cognito authorizer to handle authentication for this service.

const serverlessConfiguration: AwsConfig.Serverless  = {
    servcice: 'user',
    ...
    providers: {
        httpApi: {
          cors: {
            allowedOrigins: ['http://localhost:3000',],
          allowedHeaders: ['Content-Type', 'Authorization', 'Origin'],
          allowedMethods: ['GET', 'POST', 'PATCH', 'DELETE', 'PUT', 'OPTIONS'],
          exposedResponseHeaders: ['apigw-requestid'],
        },
            authorizers: {
              httpUserApiAuthorizer: {
              identitySource: '$request.header.Authorization',
            audience: ['${self:custom.cognitoUserPoolClientId}'],
            issuerUrl: '${self:custom.issuerUrl}',
          },
          },
    },
    },
    custom: {
    cognitoUserPoolClientId: 'CognitoUserPoolClientId-${sls:stage}',
    issuerUrl: 'CognitoUserPoolIssuerUrl-${sls:stage}',
  },
};

The goal here is not to explain how to set-up a Cognito authorization, if you want to learn about it you can read this article.

Step 2: Link service lambdas to the new API gateway

The next step involved linking all of the Lambdas in the user service to this new API Gateway. Serverless Framework does it for us when we declare the API in the configuration (step 1). However, we still need to set the new authorizer on our lambdas.

export const createUser = {
  handler: 'handler.main',
  events: [
    {
      httpApi: {
        method: 'post',
        path: '/api/user/create',
        // authorizer: { name: 'httpApiAuthorizer' }, < previous authorizer
        **authorizer: { name: 'httpUserApiAuthorizer' },**
      },
    },
  ],
};

Step 3: Update API routes

We then prefixed all API routes for the user service with a specific route : /user. This allowed our CloudFront distribution to easily differentiate between services based on the URL.

export const createUser = {
  handler: 'handler.main',
  events: [
    {
      httpApi: {
        method: 'post',
        **path: '/api/user/create'**, // make sure all user routes are prefixed
        authorizer: { name: 'httpUserApiAuthorizer' },
      },
    },
  ],
};

Step 4: Update frontend API calls

On the frontend, we updated all API calls related to the users service by adding the /users prefix. This ensured that requests were routed to the correct API Gateway without any confusion.

const userList = await client.request('get', '/users/list');

Step 5: Redirect Service Requests via CloudFront

Finally, we set up a redirection rule in CloudFront. Any requests starting with /service2 were routed to the new API Gateway.

export const CloudFrontApiDistribution: AwsConfig.CloudFormationResource = {
  Type: 'AWS::CloudFront::Distribution',
  Properties: {
    DistributionConfig: {
      Enabled: true,
      HttpVersion: 'http2',
      Origins: [
        {
          DomainName: {
            'Fn::Join': [
              '',
              [
                '${self:custom.httpBooksApiId}',
                '.execute-api.',
                '${self:provider.region}',
                '.amazonaws.com',
              ],
            ],
          },
          // Id: 'BackendAPI', <- previous global API name
          **Id: 'BooksAPI',**
          OriginPath: '/api',
          CustomOriginConfig: {
            OriginProtocolPolicy: 'https-only',
          },
        },
        **{
          DomainName: {
            'Fn::Join': [
              '',
              [
                '${self:custom.httpUsersApiId}',
                '.execute-api.',
                '${self:provider.region}',
                '.amazonaws.com',
              ],
            ],
          },
          Id: 'UsersAPI',
          OriginPath: '/api',
          CustomOriginConfig: {
            OriginProtocolPolicy: 'https-only',
          },
        },**
      ],
      PriceClass: 'PriceClass_All',
      ViewerCertificate: {
        CloudFrontDefaultCertificate: true
      },
      DefaultCacheBehavior: {
        // TargetOriginId: 'BooksAPI', <- previous global API name
        TargetOriginId: 'BooksAPI',
      },
      **CacheBehaviors: [
        {
          PathPattern: '/users/*',
          TargetOriginId: 'UsersAPI',
        },
      ],**
    },
  },
};

The default cache behaviors redirects all other routes to the original API, which is a keep-safe for all our other routes, because we don’t need to take care of them as they are already routed.

The benefits of this approach

By splitting the API and allocating different services to their own API Gateways, we gained several benefits:

Modular growth: Each service can now grow independently, with its own API Gateway, reducing the risk of hitting the 300 integration limit again.
Minimal frontend changes: Thanks to CloudFront, the frontend barely needed any modifications. The redirection was handled transparently.
Service isolation: Each service can now be managed and deployed independently, allowing for greater flexibility and scalability.

Conclusion

The AWS API Gateway limit of 300 integrations per API can be a hidden bottleneck, especially in fast-growing projects when you are unaware of its existence. In order to spot in before it arrives, I am adding a new rule on the sls-mentor tool, in order to be warned when you reach 250 integrations.

While initially daunting, addressing it through a multi-API Gateway approach can keep your architecture flexible, scalable, and modular. This experience reinforced the importance of periodically reviewing architectural decisions and splitting services when they become too large. From now on, when I have an architecture with micro services, I will be creating a micro API for each service.

For teams scaling on AWS, this approach ensures that when your services grow to the point of hitting such limits, you have a clear path forward without drastic changes to the frontend or overall application flow.

References

sls-mentor and how to use it
Cover photo : by Arthur Mazi on Unsplash

Top 10 common errors I wish I hadn’t made using SQS

Corentin Doue — Thu, 13 Jun 2024 11:56:11 +0000

Amazon SQS is a powerful service for messaging in traditional or Serverless applications, but it comes with its own set of challenges. I've compiled a list of common mistakes and best practices to help you navigate SQS more effectively. I also released the Swarmion SQS contract that helps you avoid these pitfalls and focus on your business logic.

TL;DR;

Configuration

❌ Don’t expect SQS messages to be consumed in the order they are sent
❌ Don’t set a too small Retention Period
❌ Don’t set a too small Visibility Timeout
❌ Don’t use Lambda reserved concurrency to control throughput

Producer

❌ Don’t send messages that the consumer can’t process
❌ Don’t send messages individually
❌ Don’t send too many messages to SendMessageBatchCommand or batch too big messages
❌ Don’t forget to handle SendMessageBatchCommand results
❌ Don’t send too many messages to SQS FIFO queues
❌ Don’t forget to use MessageGroupeId for SQS FIFO Queues
❌ Don’t use uuid() as MessageDeduplicationId

Consumer

❌ Don’t throw errors while processing a batch of SQS messages

🤔 Yeah, there are 12. But a top 10 title sounded better

SQS Configuration

🙅 Error: Expecting messages to be consumed in the order they are sent

💥 Impact: 🐛 Stability. Messages are processed in an unpredictable order.

✅ Solution: Use SQS FIFO if you need to process messages in a precise order

🙅 Error: Setting a too small Retention Period

💥 Impact: 🐛 Stability. Messages can be deleted before they are processed, especially with delays or multiple retries. This can be a debugging nightmare.

✅ Solution: Set a generous retention period if you plan to use delays or retries. Retention is not billed.

🙅 Error: Setting a too small Visibility Timeout

💥 Impact: 🐛 Stability. Messages can be processed several times if their visibility timeout expires before their first processor delete them.

✅ Solution: AWS recommends setting a visibility timeout three time longer than the expected message processing duration.

🙅 Error: Using Lambda reserved concurrency to control throughput

💥 Impact: 🐛 Stability. Messages can be lost due to throttle errors returned by the Lambda service, which can result in them being sent to the DLQ without being processed.

✅ Solution: Use the MaxConcurency parameter of the event source mapping instead of Lambda reserved concurrency.

Producer

🙅 Error: Sending messages that the consumer can’t process

💥 Impact: 🐛 Stability. Consumers will throw errors, causing messages to be lost or behave unpredictably.

✅ Solution: Enforce a strong interface between your producers and consumers.

💡You can use Swarmion contracts to create and enforce interfaces between your lambdas and the services that use them.

🙅 Error: Sending messages individually

💥 Impact: ⚡💰 Performance and cost. Each message is sent as an HTTP request, increasing both time and cost.

✅ Solution: Use SendMessageBatchCommand to batch messages up to 10. One batch request is billed as one request.

💡You can use the sendMessages utility of Swarmion SQS contract to send multiple messages without bothering with technical aspects

🙅 Error: Sending too many messages to `SendMessageBatchCommand` or batch too large messages

💥 Impact: 🐛 Stability. SendMessageBatchCommand can batch up to 10 messages with a total size below 256Kb. Exceeding these limits will cause the batch to be rejected, potentially losing messages.

✅ Solution: Batch messages up to 10, ensuring the total size is within limits.

💡 The sendMessages utility of Swarmion SQS contract provides automatic batching that follow these rules. Just pass an array of messages and it handles the rest.

🙅 Error: Forgetting to handle `SendMessageBatchCommand` results

💥 Impact: 🐛 Stability. SendMessageBatchCommand doesn’t throw if messages are throttled, they are returned in the response.

✅ Solution: Handle failed batch items returned by SendMessageBatchCommand and retry them.

💡The sendMessages utility of Swarmion SQS contract automatically retries throttled messages and throws errors by default to avoid silent bugs.

🙅 Error: Sending too many messages to SQS FIFO queues

💥 Impact: 🐛 Stability. FIFO queues are throttled at 300 requests per second, causing some messages to be lost if not handled.

✅ Solution: Use high throughput FIFO queues or/and control the throughput rate of your sender.

💡The sendMessages utility of Swarmion SQS contract provides a throughputCallsPerSecond parameter to precisely control throughput.

🙅 Error: Forgetting to use `MessageGroupeId` for SQS FIFO Queues

💥 Impact: ⚡Performance. All messages will be processed one at the time.

✅ Solution: use MessageGroupeId to enable parallel processing of message groups. Group messages by related usage to allow unrelated messages to be processed in parallel.

🙅 Error: Using `uuid()` as `MessageDeduplicationId`

💥 Impact: 🐛 Stability. Messages can be processed multiple times.

✅ Solution: MessageDeduplicationId must be a hash of your message content

Consumer

🙅 Error: Throwing errors while processing a batch of SQS messages

💥 Impact: ⚡🐛 Performance and stability. The entire batch will be retried after the visibility timeout is reached. Some messages will be processed or partially processed multiple times. As no message is deleted, this jam the queue.

✅ Solution: Catch errors individually and delete successfully processed messages. With lambda event source mapping, use ReportBatchItemFailures function response type and send back the unprocessed messageIds.

💡You can use the getHandler utility of Swarmion SQS contract to generate a wrapper around your handler to process messages individually, catch errors and report failed messages to SQS.

Conclusion

I hope these insights help you avoid the common mistakes I’ve encountered while working with SQS. Please share your experiences and any other tips you have for using SQS effectively.

Your AWS app in depth like never before with sls-mentor

Pierre Chollet — Tue, 11 Jun 2024 15:00:36 +0000

Your serverless app like you've never seen it before with sls-mentor

Ever dreamed of being able to visualize and analyze your entire AWS application at a glance? With the new 3.0 (alpha) of sls-mentor, it is now possible!

// Detect dark theme var iframe = document.getElementById('tweet-1754504552861024582-725'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1754504552861024582&theme=dark" }

sls-mentor is a free and open-source tool that generates an interactive graph of your AWS application. This graph contains all the interactions between components of your app (Lambda functions, DynamoDB tables, S3 buckets...).

sls-mentor also has a brand new feature: Dashboards. With dashboards, you have access to stats about your app such as :

Lambda Cold start duration 🏎
Lambda Bundle size 📦
S3 bucket size 🪣
DynamoDB table size 📊
And more to come! ✨

How to run sls-mentor?

You only need your CLI to run the new 3.0 of sls-mentor, simply use:

npx sls-mentor@alpha -p <AWS_CLI_PROFILE> -r <AWS_REGION>

Star sls-mentor on Github ⭐️

sls-mentor will perform its analysis live, on the AWS Account associated with the CLI profile.

There are also filtering options: -c to specify cloudformation stacks, -t for tags

We need you!

If you enjoyed trying sls-mentor 3.0, your feedback is valuable! Feel free to comment or to contact me on twitter

Contact me on twitter 🚀

We are also open to contributions!

Contribute on Github ⭐️

Free dynDNS for your NAS: auto-update DNS with your latest IP

Guillaume Égée — Tue, 12 Mar 2024 12:38:00 +0000

🎉 No more use a costly dynDNS service to update DNS A record when your IP changes!

I've just set up a NAS at home and linked a domain name to my router IP. But one day I could no more access to it, because the router IP changed without any notice!
Fortunately, a lot of dynDNS tools exist, but they are often paid services (even if quite cheap, I acknowledge). Why not building your own free dynDNS?

I created a repository which rely on an AWS CDK stack to update your A record in Amazon Route 53 with an API endpoint. This endpoint can be called by a script whenever your IP changes.

Suppose you host your own NAS server and want to access it at my-server.com you have bought on AWS. You need to add a A record to make my-server.com point to your server public IP. In general, if you rely on an Internet provider to get an IP, you are not guaranteed to have a one static, even if in practice they don't often change (at router reboot for instance). If you want to keep your A record up-to-date when your dynamic IP changes, this project is made for you!

... and it is (almost) free!

Set up the stack

Just follow the installation steps!
You'll need Node.js, an AWS account and a domain name of course!

How it works?

The script installed on your NAS will first call an API to retrieve its current IP, on a frequency defined with a cron job.
If this IP has changed, it will call another API endpoint (protected with an API key this time). An express step functions will then update the record in Route53 if the requested IP is the same as the source IP (the actual IP of the server calling the endpoint).
That's all!

🤑 Estimated cost

The deployed stack uses AWS resources at really low cost, supposing the script is run every hour and the IP changes every day:

Check the IP (every hour)

API Gateway V2: ~ $0.00083 = 31 days x 24h x 1.11/million requests. NB: free tier the first year
Lambda: ~ $0.00126 / month = 31 days x 24h x 1000 milliseconds x $0.0000000017 (architecture ARM, memory: 128 MB, region eu-west-1, Jan. 2024)

Update the IP (every day)

Step Functions: ~ $0.033 / month = 31 days x ($0.000001 (price per request, Jan. 2024) + 1000 milliseconds x 64 MB x \$0.00001667 )
CloudWatch: Free tier = 6 months x 31 days x (2 kB (Step Functions) + 500 B (Lambda)) = 0.5 MB < 5 GB of free tier
API Gateway V1: ~ $0.00003 = 31 x 3.50/million requests. NB: free tier the first year
Route 53 : ~ $0.00001 / month = 31 queries x $0.40 per million queries
CloudFormation : free
IAM: free

TOTAL COST: < $0.5 per year!

NB: you need to add the domain name cost (~$12 per year (depending on the name chosen) + $0.50 per hosted zone per month).

Visualize your AWS app like never before with sls-mentor

Pierre Chollet — Wed, 14 Feb 2024 12:33:19 +0000

Your serverless app like you've never seen it before with sls-mentor

Ever dreamed of being able to visualise your entire AWS application at a glance? With the new 3.0 (alpha) of sls-mentor, it is now possible!

// Detect dark theme var iframe = document.getElementById('tweet-1754504552861024582-83'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1754504552861024582&theme=dark" }

The end-game of sls-mentor is to allow developers and tech-leads to be able to take informed decisions relative to the architecture of their AWS App, by providing them with user-friendly data and best-practices compatible with their situation.

How to run sls-mentor?

You only need your CLI to run the new 3.0 of sls-mentor, simply use:

npx sls-mentor@alpha -p <AWS_CLI_PROFILE> -r <AWS_REGION>

Star sls-mentor on Github ⭐️

sls-mentor will perform its analysis live, on the AWS Account associated with the CLI profile.

There are also filtering options: -c to specify cloudformation stacks, -t for tags

What can sls-mentor do?

sls-mentor 3.0 is still in alpha, but it is already quite capable!

Visualize a graph snapshot of your AWS app

Some resources or interactions are not yet supported yet, we are working on them!

Rank Lambdas/DynamoDBs by stats (duration, size...)

More options coming soon!

Edit the graph

Have fun by moving around the components of your app, or pin them (by pressing SPACE) to make it clearer.

Short-term roadmap

We are currently working hard on making the alpha better!

// Detect dark theme var iframe = document.getElementById('tweet-1757058192696086817-228'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1757058192696086817&theme=dark" }

Here are some of the features we want to implement during the following weeks:

AppSync APIs and integrations
Clustering (By Cloudformation stack, by tags...)
Filtering options (By Cloudformation stack, by tags...)
More stats (S3 buckets...)
First best-practices

We need you!

If you enjoyed trying sls-mentor 3.0, your feedback is valuable! Feel free to comment or to contact me on twitter

Contact me on twitter 🚀

We are also open to contributions!

Contribute on Github ⭐️

Migrating from API Gateway V2 to V1 to get REST API features

Guillaume Égée — Tue, 13 Feb 2024 17:04:31 +0000

This guide aims to help you migrate a serverless or CloudFormation stack with API Gateway v2 (HTTP API) integrated with lambdas to the same stack using API Gateway v1 (REST API), with a focus on:

Handling API paths constraints
Input and Output serialization (and in particular these breaking changes: JWT authentication, CORS)

AWS REST API has a lot of features that HTTP API do not benefit from: cache at edge, WAF integration, API keys. Even if some features can be circumvented, like using CloudFront for cache at edge, some are not and a migration can be necessary. For a detailed comparison between the two versions, see this guide: https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vs-rest.html

💡 TLDR: have a look to this repo for Typescript types, helpers to format API responses and a serverless template with the use of both API versions.

🗜️ API path constraints are different

In REST API, each part of an API path is a resource

In REST API, paths must be defined once, because each path part is a resource. This is not an issue with HTTP API.

If you need to deploy /actions/list and /actions/toggle, you need to deploy 3 ApiGateway Resource, /action, /list and /toggle, one for each path.
If you define /action twice, you will get 409 Conflict "Another resource with the same parent already has this name: actions"

With Serverless framework, it is done for you, except if you deploy different services with a path in common: in this case, you have no choice but to rename it.

Variables in paths are managed differently

Let’s say you have defined two routes /network/{networkId}/actions/list and /network/{userId}/profile in the HTTP API. Even if we can challenge this api path structure, it is possible with HTTP API… but not with REST API, because only one variable path part name is allowed.

In CloudFormation, you should encounter this error: "A sibling ({networkId}) of this resource already has a variable path part -- only one is allowed".

Two options: either rename userId to networkId (if it makes sense 🤔) or change the path!

➡️ Input is different

There are two versions of the input payload, Payload 1.0 and Payload 2.0. For Typescript users, I wrote the payload types, as they are not exposed in AWS SDK.

Handling headers and query strings with multiple values

With API Gateway v2, query strings and headers can have multiple values for the same key. In this case, values are comma-separated in the input object headers or queryStringParameters.

// Payload 1.0 (REST API)
{ 
  ...
  "headers": { "singleValueParam": "value1" },
  "multiValueHeaders": { "multiValueParam": ["value1", "value2"] }
}

// Payload 2.0 (HTTP API)
{ 
  ...
  "headers": { "singleValueParam": "value1", "multiValueParam": "value1,value2" }
}

Authentication is different... and Cognito groups are formatted differently!

If you use a Cognito authorizer, you can find similar keys in both payloads... but they are not the same!

For instance for a user in Cognito groups "group1" and "group2":

// Payload 1.0 (REST API)
{ 
  ...
  "requestContext": { 
    "authorizer": {
      "claims": {
        "cognito:groups": "group1,group2",
        "cognito:username": "bob@example.com",
        "email": "bob@example.com"
      }
    }
   }
}

// Payload 2.0 (HTTP API)
{ 
  ...
  "requestContext": { 
    "authorizer": {
      "jwt": {
        "claims": {
          "cognito:groups": "[group1 group2]",
          "cognito:username": "bob@example.com",
          "email": "bob@example.com"
        }
      }
    }
   }
}

Therefore, Cognito groups must be parsed differently!

Other parameters are not at the same place...

.. but I won't go through other differences, but they are a lot that can be easily found in these types.

🔀 In REST API, CORS are handled at method level

In HTTP API, a global configuration can be set ; in REST API it is at method level.
So when moving to REST API, you need to edit every method to add CORS for preflight requests. And for other requests, you need to update the output of the lambda manually (see next section).

⬇️ Output is different, even if a Lambda integration is chosen

With HTTP API, if no statusCode key is defined, the output payload is automatically stringified to a response body in a HTTP response with status 200 (see documentation)
. This is not the case in REST API, so you need to format your output manually. For an easier migration, you can set up a middleware based on this code, or if you use @middy middleware, based on this code.
These helpers also add CORS headers, as this is not handled by REST API.

Finally, should I move to REST API?

In short, the REST API comes with more features, but is more complex whereas HTTP API is a three-times cheaper and turnkey solution, especially if you use a JWT authentication and need CORS headers. Moving from one API to another is clearly possible, but painful for a big application with multiple services sharing the same API Gateway.

Learn serverless on AWS step-by-step - Schedule tasks with EventBridge Scheduler

Pierre Chollet — Tue, 16 Jan 2024 14:12:20 +0000

TL;DR

In this series, I try to explain the basics of serverless on AWS, to enable you to build your own serverless applications. With last article, we discovered how to Lambda function destinations to avoid losing data when an asynchronous Lambda function fails. In this article, we will discover how to schedule tasks with EventBridge Scheduler.

What will we do today?

Create a small memo application, where we can create a memo, and execute it at a specific date and time
Create a Lambda function that creates a memo
Create a Lambda function that is triggered at a specific date and time, and executes the memo

The architecture of our application will look like this:

⬇️ I post serverless content very regularly, if you want more ⬇️

Follow me on twitter 🚀

Quick announcement: I also work on a library called 🛡 sls-mentor 🛡. It is a compilation of 40 serverless best-practices, that are automatically checked on your AWS serverless projects (no matter the framework). It is free and open source, feel free to check it out!

Find sls-mentor on Github ⭐️

How to schedule tasks with AWS EventBridge Scheduler?

AWS EventBridge Scheduler is a service that allows you to schedule tasks in the future. It can be compared to AWS EventBridge Rules: while rules allow you to trigger tasks based on rates or cron expressions, scheduler allows you to trigger tasks at a specific date and time (they also support cron expressions and rates btw...).

Using the AWS EventBridge Scheduler programmatically to trigger a Lambda function has an easy and a not-so-easy step:

😁 The easy step is to specify a target, this can easily be done using the ARN of the Lambda function you want to trigger
🥵 The not-so-easy step is to give the permission to the scheduler to invoke your Lambda function. This is done by:
- Creating a role with a scheduler.amazonaws.com service principal (assumed by the scheduler)
- Giving the permission to the scheduler to invoke your Lambda function lambda:InvokeFunction
- Giving the permission to your input Lambda function (addMemo) to pass the role to the scheduler iam:PassRole

This can be summarized in the following diagram:

Now, let's see how this works in practice, with a real code example!

Create a small memo application using AWS EventBridge Scheduler

To create our app, we will use the AWS CDK. If you are not familiar with it, I invite you to read the first article of this series where I explain properly how to setup a CDK project.

npx cdk init app --language typescript
npm i @aws-sdk/client-scheduler
npm i uuid # always useful to generate unique ids
npm i -D esbuild # Needed to bundle our Lambdas!

First, let's create the Infrastructure as Code (IAC) of the application. This is done by updating the CDK stack:

// stack.ts - Infrastructure as code
import { Stack, StackProps } from 'aws-cdk-lib';
import { Construct } from 'constructs';

import * as cdk from 'aws-cdk-lib';
import { join } from 'path';

export class Part17SchedulerStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    // Lambda function triggered by scheduler
    const executeMemo = new cdk.aws_lambda_nodejs.NodejsFunction(this, 'ExecuteMemo', {
      entry: join(__dirname, 'executeMemo.ts'),
      handler: 'handler',
      runtime: cdk.aws_lambda.Runtime.NODEJS_18_X,
      bundling: {
        externalModules: ['@aws-sdk'],
      },
    });

    // Create role for scheduler to invoke executeMemo
    const invokeExecuteMemoRole = new cdk.aws_iam.Role(this, 'InvokeMemoRole', {
      assumedBy: new cdk.aws_iam.ServicePrincipal('scheduler.amazonaws.com'),
    });
    invokeExecuteMemoRole.addToPolicy(
      new cdk.aws_iam.PolicyStatement({
        actions: ['lambda:InvokeFunction'],
        resources: [executeMemo.functionArn],
      }),
    );

    // Lambda function that schedules executeMemo
    const addMemo = new cdk.aws_lambda_nodejs.NodejsFunction(this, 'AddMemo', {
      entry: join(__dirname, 'addMemo.ts'),
      handler: 'handler',
      runtime: cdk.aws_lambda.Runtime.NODEJS_18_X,
      bundling: {
        externalModules: ['@aws-sdk'],
      },
      environment: {
        SCHEDULE_TARGET_ARN: executeMemo.functionArn,
        SCHEDULE_ROLE_ARN: invokeExecuteMemoRole.roleArn,
      },
    });

    // Allow addMemo to create a scheduler
    addMemo.addToRolePolicy(
      new cdk.aws_iam.PolicyStatement({
        actions: ['scheduler:CreateSchedule'],
        resources: ['*'],
      }),
    );

    // Allow addMemo to pass the invokeExecuteMemoRole to the scheduler
    addMemo.addToRolePolicy(
      new cdk.aws_iam.PolicyStatement({
        actions: ['iam:PassRole'],
        resources: [invokeExecuteMemoRole.roleArn],
      }),
    );

    // Trigger addMemo via API Gateway
    const api = new cdk.aws_apigateway.RestApi(this, 'Api', {
      restApiName: 'Part17Service',
    });
    api.root.addResource('addMemo').addMethod('POST', new cdk.aws_apigateway.LambdaIntegration(addMemo));
  }
}

What is happening here?

1️⃣ We create the executeMemo Lambda function, that will be triggered by the scheduler
2️⃣ We create a role that will be assumed by the scheduler, and that will allow it to invoke the executeMemo Lambda function (see intro diagram)
3️⃣ We create the addMemo Lambda function, that will create a scheduler
4️⃣ We allow the addMemo Lambda function to create a scheduler by adding the scheduler:CreateSchedule permission and the iam:PassRole (see intro diagram) permission to the addMemo role
5️⃣ We create an API Gateway endpoint that will trigger the addMemo Lambda function, and a POST method to trigger it

Now, let's create the Lambda functions that will be triggered by the API Gateway endpoint. First, let's create the addMemo Lambda function, that will create a schedule:

// addMemo.ts - Lambda function that creates a scheduler
import {
  ActionAfterCompletion,
  CreateScheduleCommand,
  FlexibleTimeWindowMode,
  SchedulerClient,
} from '@aws-sdk/client-scheduler';

import { v4 as uuidv4 } from 'uuid';

const client = new SchedulerClient({});
const scheduleTargetArn = process.env.SCHEDULE_TARGET_ARN as string;
const scheduleRoleArn = process.env.SCHEDULE_ROLE_ARN as string;

if (scheduleTargetArn === undefined || scheduleRoleArn === undefined) {
  throw new Error('Missing environment variables');
}

export const handler = async ({
  body,
}: {
  body: string;
}): Promise<{
  statusCode: number;
  body: string;
}> => {
  const {
    memo,
    date,
    time,
    timezone = 'Europe/Paris',
  } = JSON.parse(body) as { memo?: string; date?: string; timezone?: string; time?: string };

  if (memo === undefined || date === undefined) {
    return {
      statusCode: 400,
      body: 'Bad Request',
    };
  }

  await client.send(
    new CreateScheduleCommand({
      Name: uuidv4(),
      Target: {
        Arn: scheduleTargetArn,
        RoleArn: scheduleRoleArn,
        Input: JSON.stringify({ memo }),
      },
      ScheduleExpressionTimezone: timezone,
      ScheduleExpression: `at(${date}T${time})`,
      FlexibleTimeWindow: {
        Mode: FlexibleTimeWindowMode.OFF,
      },
      ActionAfterCompletion: ActionAfterCompletion.DELETE,
    }),
  );

  return {
    statusCode: 200,
    body: 'Memo scheduled',
  };
};

What is happening here?

1️⃣ We setup a client and parse environment variables (see IAC where we set them)
2️⃣ We parse the body of the request, and extract the memo, date, time and timezone (default to Europe/Paris (where I live 😅))
3️⃣ We create a schedule using the AWS SDK for Javascript
- 🅰️ We set the target, using the scheduleTargetArn and scheduleRoleArn environment variables
- 🅱️ We set the schedule expression, using the date and time provided in the request, along with the timezone, and we set the schedule to be automatically deleted after execution

Finally, let's create the executeMemo Lambda function, that will be triggered by the scheduler. This function will simply log the memo to the console:

// executeMemo.ts - Lambda function that executes a memo
export const handler = async ({ memo }: { memo: string }): Promise<void> => {
  console.log(memo);

  return Promise.resolve();
};

Very easy! Notice that the lambda input is the same as the input field specified in the CreateScheduleCommand of the addMemo Lambda function.

Test our app

We are done! Time to deploy and to test our API route /addMemo

npm run cdk bootstrap
npm run cdk deploy

I live in Paris 🇫🇷, so I used my default Europe/Paris timezone, but you can specify the timezone of your choice. I specified a time of 22:37, and it is 22:36, if I head to Cloudwatch, I should see my executeMemo Lambda function being triggered in 1 minute.

It worked! I can also see the payload of the event, and it contains the memo I created.

Going further

What could be improved in this app?

We could go further and add a /getMemos route, that would return all the memos that are not executed yet
We could also add a /executeMemo route, that would execute a memo immediately, and cancel the corresponding schedule
As always, implementing authentication would be a good idea 😅

Conclusion

This article was a basic introduction to AWS EventBridge Scheduler. We discovered how to create a scheduled task, and how to execute it. We also discovered how to use the AWS CDK to provision our infrastructure. I hope you enjoyed this article, and that you learned something new!

I plan to continue this series of articles on a bi-monthly basis. You can follow this progress on my repository! I will cover new topics in the future, if you have any suggestions, do not hesitate to contact me!

I would really appreciate if you could react and share this article with your friends and colleagues. It will help me a lot to grow my audience. Also, don't forget to subscribe to be updated when the next article comes out!

I you want to stay in touch here is my twitter account. I often post or re-post interesting stuff about AWS and serverless, feel free to follow me!

Follow me on twitter 🚀

🚀 Lambda Test Revolution: Master Mocking & Slash Costs with HTTP-Interceptor!

Maxime Vivier — Fri, 15 Dec 2023 12:47:11 +0000

TL;DR 📰

Learn how to perform integration tests iso prod with aws serverless services. Using lambda-http-interceptor you can easily intercept and mock http calls coming from your deployed lambda functions.

Why should you use it:

You want to test your lambda functions in a iso-prod environment 🧪
You want to save money while running integration tests by not triggering costly third party APIs 💸
You want to control the behavior of third party APIs to test edge cases 🎯
You don't want to change your lambda code to make it testable 👷

And maybe you can use it for all theses reasons at the same time!

Try lambda-http-interceptor here 😉

Intercept http calls in lambda functions 🪝

The lib is made of a CDK Construct to instantiate in your stack.

The HttpInterceptor construct needs to be instantiated in the stack, or inside another Construct. And then the interceptor needs to be applied to the lambda function http calls need to be intercepted from.

The applyHttpInterceptor uses Aspects in order to apply it on each NodeLambdaFunction it finds, thus applyHttpInterceptor takes any Construct as input.

import { Stack, StackProps } from "aws-cdk-lib";

import { Construct } from "constructs";
import { HttpInterceptor, applyHttpInterceptor } from "lambda-http-interceptor";
import { NodejsFunction } from "aws-cdk-lib/aws-lambda-nodejs";
import { Runtime } from "aws-cdk-lib/aws-lambda";

export class MyStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    const interceptor = new HttpInterceptor(this, "HttpInterceptor");

    const myLambdaFunctionThatMakesExternalCalls = new NodejsFunction(
      this,
      "MakeExternalCalls",
      {
        runtime: Runtime.NODEJS_18_X,
        handler: "index.handler",
        entry: './handler.ts',
      },
    );

    applyHttpInterceptor(myLambdaFunctionThatDoesExternalCalls, interceptor);
  }
}

After deploying, everything is setup on the stack to then perform integration tests.

The second part of the lib is a set of tools to perform integration tests. They are gathered in the HttpLambdaInterceptorClient class.

import fetch from "node-fetch";
import { expect, describe, it } from "vitest";

process.env.HTTP_INTERCEPTOR_TABLE_NAME = '<table-name-from-construct>'

import { HttpLambdaInterceptorClient } from "lambda-http-interceptor";

import { triggerMyLambdaFunctionThatMakesExternalCalls } from './utils';

describe("my test", () => {
  const interceptorClient = new HttpLambdaInterceptorClient(
    '<myLambdaFunctionThatMakesExternalCalls-name>',
  );
  it("tests my lambda function", async () => {
    await interceptorClient.createConfigs([
        {
          url: "https://api-1/*",
          response: {
            status: 404,
            body: JSON.stringify({
              errorMessage: "Not found",
            }),
          },
        },
        {
          url: "https://api-2/path",
          response: {
            passThrough: true,
          },
        },
      ]);
    await triggerMyLambdaFunctionThatMakesExternalCalls();
    const interceptedCalls = await interceptorClient.pollInterceptedCalls({
      numberOfCallsToExpect: 2,
      timeout: 5000,
    });
    expect(resp.interceptedCalls).toBe(2);
  });
});

How does it work? 📚

lambda-http-interceptor stores the configurations and the call made in DynamoDB table 🏪

The HttpInterceptor instantiates a DynamoDB table in the stack. The table is used to store the configurations of the http calls to intercept. When performing integration tests, filling up the table with configuration is done using the createConfigs method of the HttpLambdaInterceptorClient class.

Then assertions can be made on the calls made by the lambda after they are fetched using the pollInterceptedCalls method of the HttpLambdaInterceptorClient class.

💡 Don't forget to give the user you're using to perform the integration tests the right to read in the table. In general, we use AdministratorAccess role for the user performing these tasks.

lambda-http-interceptor uses an internal extension to intercept http calls in lambda functions 📡

The internal extension that the interceptor deploys on the lambda functions overrides the http module of nodejs that is used to make http calls.

For each call made by the lambda, it fetches the http calls configuration stored in DynamoDB and either passes through the call or returns the response value configured at the start.

It keeps track of the http calls listed that are listed in the configuration. If the response of a call doesn't need to be changed but it still needs to be tracked in order to make assertions on it, the configuration of the call doesn't change and the response only contains passthrough: true.

If you want to deep dive the functioning of the interceptor, you can check out this article that presents extensions really clearly using a simple example.

lambda-http-interceptor has everything built in 💪

The setup is fairly easy and it can be used to make assertions on the calls made by your deployed lambda functions. And you don't edit the code of your lambda handler.

The documentation on github is far more exhaustive to get you started.

Try lambda-http-interceptor here 😉

Don't hesitate to star it ⭐️

6 guidelines for risk-less data migrations

Guillaume Égée — Wed, 13 Dec 2023 13:25:19 +0000

“The majority of project issues I have seen come from databases, whatever is the technology” said one day one my experienced engineering manager...

This is why I have built 6 guidelines I try to follow when modifying data on tech projects. They are especially helpful when working with databases like DynamoDB with few tooling (no ORM, etc.).

Data is key in business… and it is where it often fails.

Almost every app has a database with more or less structured data. These data items may evolve during app development, with the addition of new fields, changes to field structure, data updates, or removal of fields. These evolutions, often referred to as migrations, are critical as they enable the app to evolve but can also introduce bugs if not executed properly.
A data migration plan is a perfect tool to mitigate the risks of these operations, as it avoids common pitfalls and ensures reliability.

📋️ First thing: have a migration protocol defined

Define a protocol to follow in advance

Define who is responsible of what. You can use a responsibility matrix (RACI)
Define when the migration should be planned
Define what should be done in precise steps (manually deploy a function, trigger a Continuous Deployment workflow, etc.) ?

Follow the protocol

A simple advice... to avoid acting in panic if something goes wrong…

Upgrade the protocol with your learnings

There are often recurring patterns in migrations: making a field non nullable, updating a data type, etc. To capitalize on them, build a list of common migrations with explanations of the best implementation strategy based on past experiences.

↔️ Have a strategy to handle the transition state

Estimate the duration and load (scalability) of the migration process, in all environments

What specific cases should be anticipated in production?
- What differences should be taken into account when estimating the migration sizing (database size, environment configuration)?
- Are there API/database quotas that you should plan for?
Apply a margin for the manual parts (launching the migration, etc.)

Migration strategies

Given that estimation and business concerns, choose between these 2 main strategies:

💥 “Big Bang” Migration

Only one version of a migration set (pieces of data to modify) can exist at application uptime.

Plan a service interruption when data will be unavailable.

✍️ Example of a user-friendly service interruption: during the migration process, the frontend application displays a "maintenance banner", and the backend is programmatically locked, to ensure no side-effect can corrupt data.

✳️ Pros: quicker method, advised when building a project with low risks if some data is lost/corrupted
⚠️ Risks:
- possibly long downtime,
- risk of database throttling (in case of naive parallel read/write implementation for instance)
- more difficult to write migrations with a reliable rollback

🌊 Migration in two (or more) steps

Handle old and new versions inside the migration set.

Data migration and new code deployment must be uncoupled and done in the proper order.
Examples :
- if you remove a column (or a table, etc.), remove the code using this column and then migrate the data
- if you add a column, migrate the data first and then deploy the code using it
- if you update a column, add a new column and, after it has been fulfilled progressively, remove the old column
💡 You can run integration tests with both versions to ensure the application works in both cases
✳️ Pros: reliable method, that is error proof (if the migration fails, the system can continue running without interruption)
⚠️ Risks:
- more complex to develop
- longer to fulfill completely
- risk of maintaining multiple versions over a long period of time.

🔂 Make a plan reproducible in multiple environments

Write idempotent migrations (i.e. a migration can be applied multiple times with the same result)

There are many reasons for needing to re-apply a migration: migration partially completed, stopped or failed, etc.
The migration script should work without any state-full input

✍️ Simple example of idempotent migrations

❌ Bad: if you run the migration twice, the data will be corrupted.

  def perform_migration(item):
      item.count += 1

  def not_idem_potent_migration(new_version):
          perform_migration(item)
          item.version = new_version

✅ Good: even if the migration itself (incrementation) is not idem-potent, it is not possible to run it twice with this migration.

  def idem_potent_migration(new_version: int):
      if (item.version >= new_version):
          return
      else:
          perform_migration(item)
          item.version = new_version

Save the migration scripts

Committing migration scripts ensures the same process can be applied to another environment easily and with known and reproducible steps.
In case of error, it will help understanding what happened.

Test your scenario

Test the migration script (with unit tests) to verify its functionality.
- Check that data items of the migration set are correctly selected
- Check all edge cases
Use dedicated environments to test the migration plan
- Non-production environments can help to find bugs, all the more if data is ISO-prod.
- If it is not possible to test a scenario with production data, you can at least run scripts to check for errors, or run migrations in dry-run

📆 The plan includes communication with stakeholders

Running a migration can have impacts on the underlying business, so it should not remain in the technical sphere, but be shared to stakeholders.

Communicate to business owners and stakeholders

Explicit the risks of the migration and consider their concerns

Stakeholders should be involved in the decision to migrate data, as they know the system and are responsible of it.
They may help find edge cases in the migration, like dependencies to other teams, a specific business case not handled, etc.
✍️❌ Common pitfall: Delete a deprecated column that is still used by another team
✍️✅ Good practice: Continue supporting legacy versions until they are no longer in use, and establish a deadline to cease support.

Choose the right moment to run the migration

✍️❌ Common pitfall: Run a resource-consuming migration during peak hours (example: adding a non-nullable column of a table in PostgreSQL that will lock it).
✍️✅ Good practice: Run a “big bang” migration just after the deployment to reduce the service interruption lead time. Run it during off-peak hours and when a development team is available in case of error.

↩️ A rollback strategy is defined

Backup your data and practice restoring it

If anything goes wrong, you should be able to restore your database to a correct state.

Cloud providers have services dedicated to backups (e.g. AWS Backup if you are using AWS, Actifio on GCP, etc.) and database systems often come with their own backup solution.
Practice restoring your data
Be pragmatic. Can you afford to restore your data?
- Some data items might have been updated during the process
- Is it worth to rollback, if only a few items have an issue?
- What is the risk of a data loss?

Write a “down” migration, as well as the “up” migration… or at least a Plan B

How many times I've heard (or said) "It won't fail, no need of plan B"... and it finally failed ?
I won't go through implementation details here (and a lot of ORMs have dedicated tools for this), the main point is "Don't be overconfident"!

🧱 The plan includes a check that everything is ok in the end

Keep track of migration states with versioning

If possible, save the changes and the version of items during the migration process.
Keep track of migration applications in each environment.
The versions must be strictly increasing (in a specific order relationship) and deterministic to be able to compare versions. For instance, with an incremented integer or a timestamp and a reference to the previous version.

Remove data after complete validation only

Although, this does not guarantee that you will end up with a successful migration after the removal operation, this allows you to detect potential issues you have not forecast and facilitate reverting the changes.

✍️ E.g. only remove ‘address’ after you have correctly added ‘street_name’, ‘city’, ‘postcode’.

Check that everything is ok after the migration

Audit the database after migration
- Use a monitoring system to keep track of new errors.
Not seeing code or monitoring issue do not mean there is no issue ! Check it with business owners.
You can set-up end-to-end tests to avoid regressions.

🌟 What to remember?

These 6 guidelines are just an attempt to sum-up what to care about when applying data migrations. They can also apply to application deployments or whatever operation that introduces a breaking change. But the main learning could also be capitalize on knowledge to avoid reproducing the same mistakes !

Want to share your own tips or tech convictions? Don't hesitate to comment on this post 😉

Override the 500 resource limit of AWS CloudFormation templates with Serverless Framework

Anaïs Schlienger — Fri, 08 Dec 2023 14:47:45 +0000

AWS provides a robust infrastructure for deploying serverless applications using AWS CloudFormation. However, it's not uncommon to encounter resource limits when working on large serverless projects. One way to tackle this challenge is by splitting your CloudFormation stacks into smaller, more manageable units. AWS suggests themselves to use nested stacks to overcome the 500-resource limit. In this article, we'll explore how to achieve this using the Serverless Framework and a plugin called serverless-plugin-split-stacks. We'll also discuss some tips and tricks to make the process smoother.

Nested stacks are a safe way to address the resource limit wall whilst keeping the benefits of a single stack. The main benefit of a single stack is that you can deploy and rollback all resources at once. As nested stacks have a dependency to their parent stack, so if one of the nested stacks fails to deploy, the parent stack will roll back to its previous state. The nested stacks also share the output variables (such as ids or arn). We keep an atomic behavior of our stack.

Prerequisites

Before we dive into the details, make sure you have the following in place:

AWS Account
Node.js and npm installed
Serverless Framework installed (npm install -g serverless)
A Serverless Framework project set up

Splitting Stacks with serverless-plugin-split-stacks

Installation

First, you need to install the serverless-plugin-split-stacks plugin. Navigate to your Serverless project directory and run the following command:

npm install serverless-plugin-split-stacks --save-dev

Configuration

In your serverless.ts (or serverless.yml) file, add the plugin to the plugins section:

 plugins: ['serverless-plugin-split-stacks'],

and configure it under the custom section:

custom: {
  // ...
  splitStacks: {
    perFunction: false,
    perType: false,
    perGroupFunction: true,
    nestedStackCount: 10,
  },
}

perFunction: Setting this to true would split the stack for each AWS Lambda function. Setting it to false keeps your structure manageable.
perType: If you want to split stacks based on resource types (e.g., DynamoDB tables, S3 buckets), set this to true.
perGroupFunction: This option is set to true, which splits stacks equally based groupings of functions (the lambda and all its associated ressources, eg. IAM roles).
nestedStackCount: disabled if not specified ; it controls how many resources are deployed in parallel.
stackConcurrency: number: disabled if not specified ; it controls how many stacks are deployed in parallel.

Renaming Existing Lambdas

Here is the tricky part. The plugin doesn't work with existing resources. You can force the migration of an existing resource to a new stack if you use a custom migration with force: true but it will delete the resource and recreate it. It might create conflicts in CloudFormation or issues with IAM. This is not a good idea for production environments.

No worries, there is a workaround.

If you have existing Lambdas, you need to rename them to follow the new structure. The easiest way is to suffix their names with an underscore _. For example, if you had a Lambda named myFunction, you can rename it to myFunction_. You use any other suffix you like honestly, but the underscore is a good convention as it is easy to read and less bulky visually.

Just like that, without being deleted, your lambdas are moved to the new stack.

Deploying the Stacks

When deploying your Serverless project for the first time with these changes, ensure you set the disableRollback parameter to false. This way, if something goes wrong during deployment, AWS will not automatically roll back the changes. Here's how you can set it:

sls deploy --disableRollback false

After the initial deployment, it's recommended to set disableRollback back to true for safety reasons. This ensures that the stack rolls back to its previous state in case of deployment failures.

Example

Let's illustrate these steps with a simple example. Consider a Serverless service with three functions: userFunction, orderFunction, and paymentFunction.

Install the serverless-plugin-split-stacks plugin.
Configure your serverless.ts file:

service: my-serverless-app

frameworkVersion: '>=2.50.0'
plugins:
  - serverless-plugin-split-stacks

provider:
  name: aws
  runtime: nodejs18.x

custom:
  splitStacks:
    perFunction: false
    perType: false
    perGroupFunction: true
    nestedStackCount: 10

functions:
  userFunction:
    handler: userFunction.handler
  orderFunction:
    handler: orderFunction.handler
  paymentFunction:
    handler: paymentFunction.handler

Rename existing Lambdas if necessary.
Deploy the stacks as explained above.

💭 Limitations

Hitting the resource limit may be a sign that your application is becoming too complex. It's a good idea to review your architecture and see if you can simplify it or re-organize it. Having smaller services is easier to maintain and manage.

🧠 Conclusion

By splitting your AWS CloudFormation stacks using the serverless-plugin-split-stacks, you can overcome the 500-resource limit and manage your serverless applications more effectively. This approach not only makes your infrastructure more scalable but also eases the maintenance of your serverless projects as they grow.

However, sub-stacks have their limits too and it does not mean you can grow them out indefinitely. They have the same resource limit as the main stack, and the more nested stacks you have, the longer your stack takes to deploy.

Having to split your stacks is a sign that your application is becoming too complex and you should review your architecture. One way to change the way you split your stacks is to have a stack for each decoupled business entity. Or maybe a micro-service architecture is maybe not the good fit for your use case: you can look into hexagonal architectures for example.

References

Learn Security Best Practices with Sls-mentor latest Security Package

Vincent Zanetta — Fri, 08 Dec 2023 13:48:31 +0000

In the realm of cloud computing, serverless has emerged as a popular paradigm, offering a pay-as-you-go model and the ability to scale applications dynamically. However, with such flexibility comes the potential for security vulnerabilities. To address this need, sls-mentor, an open-source tool, has been developed to audit and improve the security of your AWS Serverless applications.

New Security Rules for Enhanced Protection

We are excited to announce the release of new security rules for sls-mentor to further enhance the security of your serverless applications. These rules cover IAM role policies, SQS queues, and RDS instances.

IAM Role Policies:

No IAM Role Policy with wildcard Resource: Using wildcards in IAM role policies can grant excessive access to resources, making it easier for attackers to exploit. To mitigate this risk, we recommend using specific resources in IAM policies instead of wildcards.

SQS Queues:

Encrypt your SQS queues: SQS queues store messages, making them potential targets for unauthorized access. To safeguard your message data, encrypt your SQS queues. SQS supports server-side encryption, ensuring that the data is encrypted on the server before it is stored in the queue.

RDS Instances:

Encrypt your RDS instances: RDS databases manage sensitive data, and encrypting them is crucial for protecting this information. sls-mentor checks for unencrypted RDS instances and provides instructions on how to enable encryption.

Using sls-mentor to Enhance Security

In addition to the newly introduced security rules, sls-mentor already includes a comprehensive set of security checks that cover various aspects of AWS Serverless applications. These include checks for insecure IAM role permissions, vulnerable Lambda function configurations, and unencrypted CloudWatch logs. By leveraging these existing checks and the newly added ones, developers can thoroughly assess and strengthen the security posture of their serverless applications.

To utilize sls-mentor and benefit from its security enhancement capabilities, follow these simple steps:

Run sls-mentor: With your AWS credentials configured, run the following command to initiate the security analysis:

  npx sls-mentor@latest --report

Review the security report: The sls-mentor tool will generate a comprehensive report in your current directory, named .sls-mentor/index.html. This report provides insights into the security posture of your serverless applications, highlighting areas for improvement and offering actionable recommendations. Join the Community and Contribute We are always striving to enhance sls-mentor’s capabilities and welcome contributions from the community. If you have serverless or serverful knowledge to share, feel free to join our GitHub repository and contribute to our ongoing development efforts. Your contributions will directly impact the security of serverless applications worldwide.

Conclusion By incorporating sls-mentor into your serverless development workflow, you can proactively identify and address potential security vulnerabilities, ensuring the safety and integrity of your applications in the cloud. Join us in strengthening the security posture of serverless deployments and make your cloud infrastructure more resilient to attacks.

5 Serverless Best Practices to Become a Skilled Cloud Architect

Pierre Chollet — Wed, 06 Dec 2023 13:58:11 +0000

Discover serverless best practices with sls-mentor

In this article, I will go through 5 low cost, high impact serverless best practices that will help you build faster, cheaper, greener, more secure and stable applications on AWS.

Each best practice is illustrated with an infographic, to make it easy to understand and share with your colleagues. I hope you will enjoy it!

This compilation is based on 🛡 sls-mentor 🛡, my free open-source tool that automatically checks 30 serverless best practices on your AWS serverless projects (no matter the framework). Feel free to check it out!

Find sls-mentor on Github ⭐️

Let's connect!

I you want to stay in touch here is my twitter account. I often post or re-post interesting stuff about AWS and serverless, feel free to follow me!

Follow me on twitter 🚀

1 - When deploying a Lambda function, use a ARM64 architecture instead of a x86_64 architecture

Two Lambda function processors are available, how to choose wisely? 🤔

Basically, you should always go with ARM64 if your code is compatible! 🚀

🛡 sls-mentor has a rule that enforces the usage of ARM64 in your Lambda functions so that you never forget 🧠

2 - Use intelligent tiering on S3 Buckets to reduce storage costs

Which storage class fits the best for my #AWS app?

The choice is easy: use Intelligent Tiering! It automatically moves files between classes based on their usage.

🛡 sls-mentor automatically check that your buckets have Intelligent Tiering enabled, so that you never forget🧠

3 - Deploy fast Lambda functions with bundles smaller than 5MB

My Lambda function has insane cold starts, what should I do? 😿

Short answer: make its bundle smaller! On a given runtime, bundle size is the n°1 cause of long cold starts 🐢

🛡 sls-mentor lists every Lambda function with a bundle larger than 5MB, try it on your @awscloud account!

4 - Do not keep your CloudWatch logs forever to reduce storage costs

CloudWatch by @awscloud is known to be expensive 💸

There is a simple trick to reduce costs: 🚨Do not keep your logs forever🚨

Storage is cheap, but accumulating it over years quickly gets out of hands 📈

🛡 sls-mentor can list Log Groups with infinite retention, try it out 🚀

5 - Use an Authorizer on all your API Gateway endpoints to secure your API

When deploying an API, anyone with its URL can access your resources by default 😱

Authorizers allow you to secure your API, by relying on Cognito, IAM, or any custom integration.

🛡 sls-mentor can list all API Gateway endpoints without an Authorizer, try it out 🚀

Many more best practices to discover and automate!

🛡 sls-mentor is a compilation of 30 serverless best-practices, that are automatically checked on your AWS serverless projects (no matter the framework). It is free and open source, feel free to check it out!

Find sls-mentor on Github ⭐️

Let's connect!

I you want to stay in touch here is my twitter account. I often post or re-post interesting stuff about AWS and serverless, feel free to follow me!

Follow me on twitter 🚀

DEV Community: Serverless By Theodo

Avoiding API Gateway’s integrations hard limit: scaling serverless architectures efficiently

The challenge: reaching API Gateway’s 300 integration limit

Evaluating the options: lambda-lith vs micro-APIs

The solution: multi-API Gateways behind CloudFront

Step 1: create a new API Gateway for the user service

Step 2: Link service lambdas to the new API gateway

Step 3: Update API routes

Step 4: Update frontend API calls

Step 5: Redirect Service Requests via CloudFront

The benefits of this approach

Conclusion

References

Top 10 common errors I wish I hadn’t made using SQS

TL;DR;

SQS Configuration

🙅 Error: Expecting messages to be consumed in the order they are sent

🙅 Error: Setting a too small Retention Period

🙅 Error: Setting a too small Visibility Timeout

🙅 Error: Using Lambda reserved concurrency to control throughput

Producer

🙅 Error: Sending messages that the consumer can’t process

🙅 Error: Sending messages individually

🙅 Error: Sending too many messages to SendMessageBatchCommand or batch too large messages

🙅 Error: Forgetting to handle SendMessageBatchCommand results

🙅 Error: Sending too many messages to SQS FIFO queues

🙅 Error: Forgetting to use MessageGroupeId for SQS FIFO Queues

🙅 Error: Using uuid() as MessageDeduplicationId

Consumer

🙅 Error: Throwing errors while processing a batch of SQS messages

Conclusion

Your AWS app in depth like never before with sls-mentor

Your serverless app like you've never seen it before with sls-mentor

How to run sls-mentor?

We need you!

Free dynDNS for your NAS: auto-update DNS with your latest IP

Set up the stack

How it works?

🤑 Estimated cost

Visualize your AWS app like never before with sls-mentor

Your serverless app like you've never seen it before with sls-mentor

How to run sls-mentor?

What can sls-mentor do?

Visualize a graph snapshot of your AWS app

Rank Lambdas/DynamoDBs by stats (duration, size...)

Edit the graph

Short-term roadmap

We need you!

Migrating from API Gateway V2 to V1 to get REST API features

🗜️ API path constraints are different

In REST API, each part of an API path is a resource

Variables in paths are managed differently

➡️ Input is different

Handling headers and query strings with multiple values

Authentication is different... and Cognito groups are formatted differently!

Other parameters are not at the same place...

🔀 In REST API, CORS are handled at method level

⬇️ Output is different, even if a Lambda integration is chosen

Finally, should I move to REST API?

Learn serverless on AWS step-by-step - Schedule tasks with EventBridge Scheduler

TL;DR

How to schedule tasks with AWS EventBridge Scheduler?

Create a small memo application using AWS EventBridge Scheduler

Test our app

Going further

Conclusion

🚀 Lambda Test Revolution: Master Mocking & Slash Costs with HTTP-Interceptor!

TL;DR 📰

Intercept http calls in lambda functions 🪝

How does it work? 📚

lambda-http-interceptor stores the configurations and the call made in DynamoDB table 🏪

lambda-http-interceptor uses an internal extension to intercept http calls in lambda functions 📡

lambda-http-interceptor has everything built in 💪

6 guidelines for risk-less data migrations

📋️ First thing: have a migration protocol defined

Define a protocol to follow in advance

Follow the protocol

Upgrade the protocol with your learnings

↔️ Have a strategy to handle the transition state

Estimate the duration and load (scalability) of the migration process, in all environments

Step 1: create a new API Gateway for the `user` service

🙅 Error: Sending too many messages to `SendMessageBatchCommand` or batch too large messages

🙅 Error: Forgetting to handle `SendMessageBatchCommand` results

🙅 Error: Forgetting to use `MessageGroupeId` for SQS FIFO Queues

🙅 Error: Using `uuid()` as `MessageDeduplicationId`