The obvious solution is to migrate your applications to v3. However, migrating to another component isn't always as straightforward as we'd like, especially when there's a deep dependence on that component. This dependence can leave developers unable to upgrade to the latest version.
One reason developers avoid upgrading such components is the risk of introducing unintended bugs. I mean, if it's not broken, why fix it? Another reason could be that the team doesn't have the capacity to take on such a complex change due to other pressing priorities.

In this article, we'll discuss how you can safely and gradually migrate to AWS SDK for javascript v3.

Before we go further, let's gets some terms clarified.

• aws-sdk: this is v2 of the sdk.

• @aws-sdk: this is v3 of the sdk.

One way to make aws-sdk available on Lambda running on Node.js 18+ is by bundling the SDK with your application. However, this is not recommended as it increases bundle size and leads to longer cold start times.

To safely migrate to @aws-sdk, we'll split the process into two phases:

• Lift & Shift

• Refactor application code

Phase 1: Lift & Shift

This phase involves creating a Lambda layer that includes the aws-sdk package. The layer is then attached to your Lambda function, similar to how AWS makes the SDK available in earlier Node.js runtimes. This can be implemented by:

Creating a zipped file with the SDK

#!/bin/bash

echo \
'{
  "name": "aws-sdk-v2",
  "version": "1.0.0",
  "description": "A module containing aws-sdk v2",
  "dependencies": {
    "aws-sdk": "^2.1691.0"
  }
}' >> package.json

npm install
mkdir nodejs
mv node_modules nodejs
zip -rqm aws-sdk-v2.zip nodejs
rm package.json package-lock.json

Bundling the zipped as a Lambda layer

# Terraform

resource "aws_lambda_layer_version" "aws_sdk_v2" {
  compatible_runtimes  = ["nodejs18.x", "nodejs20.x"]
  description          = "Layer container aws-sdk v2"
  filename             = "./aws-sdk-v2.zip"
  layer_name           = "aws-sdk-v2"
  source_code_hash     = filebase64sha256("./aws-sdk-v2.zip")
}

Using the layer in a Lambda function

# Terraform

resource "aws_lambda_function" "function_with_aws_sdk_v2" {
  ...
  layers = [aws_lambda_layer_version.aws_sdk_v2.arn]
}

The full project is on my github repository.

If, like me, you get annoyed by the EOL message the package emits, you can disable it by setting the following environment variable: AWS_SDK_JS_SUPPRESS_MAINTENANCE_MODE_MESSAGE=1.

This solution offers several benefits. One of them is that no changes are needed in the application code; everything continues to work as it is. Another benefit is that it gives developers enough time to move on to the next phase while running on newer versions of Nodejs runtime.

Phase 2: Refactor Application Code

With enough time and Lambda running on the latest Node.js runtime, we can gradually update our application code to v3 of the SDK.

@aws-sdk offers many benefits, including a smaller bundle size, S3 multipart upload, and TypeScript support, among other things. For example, to download a file from S3 using v2, you'd need to import the entire SDK, resulting in a large file size.

const AWS = require('aws-sdk');
const s3Client = new AWS.S3({ region: "REGION" });

let objectData;

s3Client.getObject({
  Bucket: 'website-bucket',
  Key: 'static-file.pdf'
}, (err, data) => {
  objectData = data.Body.toString('utf-8');
});

With v3, the client for each AWS service is released as its own npm package. For instance, the S3 client is @aws-sdk/s3-client.

const { S3Client, CopyObjectCommand } = require('@aws-sdk/client-s3');
const s3Client = new S3Client({ region: "REGION" });

const command = new CopyObjectCommand({
  Bucket: 'website-bucket',
  Key: 'static-file.pdf'
});

const response = await s3Client.send(command);

This strategy of making each client its own package not only results in a smaller bundle size but also faster load times since we're importing only the service we need.

Updating your code base can be a daunting task, but it doesn't have to be. AWS provides a utility that developers can use to automatically convert code written in v2 to v3. This tool is an npm package named aws-sdk-js-codemod, and you can read all about it here.
It's important to understand that this is just a tool to speed up the process. As developers, it's our responsibility to ensure the code generated by this tool is correct, bug-free, and well tested.

Conclusion

As AWS draws the curtain on version 2 of the SDK, we need to be ready to transition to the new version, especially if we want to use the latest features or runtimes released by AWS.

References

• https://aws.amazon.com/blogs/developer/announcing-end-of-support-for-aws-sdk-for-javascript-v2/

• https://github.com/aws/aws-sdk-js-codemod

• https://github.com/ben-x/cloudpedia/tree/master/content/lambda-layer-with-aws-sdk-v2

PS: If you like content like this, please hit the like button.

This is a challenge faced by many enterprise that need private connection to SaaS vendors. Often, they have no choice but to transfer sensitive data over the internet. When I spoke to some vendors, they explained that supporting every region is expensive because there aren't enough customers in those region to justify the cost.

To address this challenge, I want to share a solution where SaaS providers can offer their services to customers in multiple regions using a single workload.
For example, say you have customers in Europe but your applications and workloads are deployed in Canada, or if you want to expand to multiple regions without dealing with the complexity and cost of managing servers and databases across different regions, you can solve this using simple networking and load balancers.

How Does The Solution Work?

Suppose your applications are deployed in the Canada region, which is your main base of operations. We'll call this the ca-west-1 region. Now, let's assume you have enterprise partners and end users in the Europe region, which we'll call eu-central-1. Here's how you can serve your European customers:

• Establish a link between ca-west-1 and eu-central-1 regions through a VPC peering connection or transit gateway peering.

• Setup application and network load balancers in eu-central-1 that target your workloads in ca-west-1.

• Provision a VPC endpoint service connected to the network load balancer. This will provide PrivateLink connection to enterprise customers.

• Provision a domain for the application load balancer. This will provide service to general customers.

Take a look at the architecture below to see how it all comes together.

In the diagram above, there are two VPCs connected by a VPC peering connection between the Europe and Canada regions. Target groups are created to help load balancers find applications easily. These load balancers are exposed to customers through Route 53 and securely to partners via AWS PrivateLink.

When an instance is added or removed from the autoscaling fleet in the Canada region, an event is published. This event is enriched with the instance's IP and port by a Lambda function before being sent to other regions through EventBridge. Once the event reaches the destination region, a Lambda function picks it up and updates the target groups with the new target.

Implementation

To implement this setup, we'll use Terraform, a popular vendor-agnostic Infrastructure as Code (IaC) tool used by modern engineers.

The full project is available on my GitHub repo.

Requirements

• An AWS account

• AWS CLI installed and configured with credentials that have sufficient permissions

• Terraform v1.7 or later

Step 1: Setup Workload in Base Region (Canada)

Step 2: Setup VPC in Secondary Region (Europe)

Step 3: Peer Europe & Canada Regions

Step 4: Setup Load Balancers & Target Groups in Europe

Step 5: Lambda Publish Instance Launch Event

import { getInstanceIpAddress, publishEvent, completeLifecycleAction } from './utils.js';

async function handleInstanceLaunch(event) {
  const port = process.env.APP_PORT;
  const availabilityZone = process.env.AVAILABILITY_ZONE || 'all';
  const { detail } = event;

  if(!detail.EC2InstanceId) {
    throw new Error('Details contains no instance ID');
  }

  const ipAddress = await getInstanceIpAddress(detail.EC2InstanceId);

  await publishEvent('INSTANCE_IS_LAUNCHING', {
    instanceId: detail.EC2InstanceId,
    ipAddress,
    port,
    availabilityZone
  });

  await completeLifecycleAction({
    asgName: detail.AutoScalingGroupName,
    instanceId: detail.EC2InstanceId,
    lifecycleHookName: detail.LifecycleHookName,
    lifecycleActionToken: detail.LifecycleActionToken
  });
}

export { handleInstanceLaunch };

Step 6: Lambda Capture Event & Update Target Groups

import { ElasticLoadBalancingV2Client, RegisterTargetsCommand } from '@aws-sdk/client-elastic-load-balancing-v2';

const elasticLoadBalancingV2Client = new ElasticLoadBalancingV2Client();

async function registerTarget (event) {
  const targetGroupArns = JSON.parse(process.env.TARGET_GROUP_ARNS);
  const { detail } = event;

  for (const targetGroupArn of targetGroupArns) {
    const registerTargetsCommand = new RegisterTargetsCommand({
      TargetGroupArn: targetGroupArn,
      Targets: [{
        Id: detail.ipAddress,
        Port: detail.port,
        AvailabilityZone: detail.availabilityZone
      }]
    });

    await elasticLoadBalancingV2Client.send(registerTargetsCommand);
  }
}

export { registerTarget };

The full project is available on my GitHub repo.

Speed Analysis

We'll make requests to each region to see how fast the service responds. We'll monitor the speed using the network analyzer in Google Chrome.

Calgary to Calgary

The image below shows a request made by a user in Canada to the service endpoint in Calgary. As expected, the latency is very low. It takes 21 milliseconds to receive a response for users in Calgary.

Berlin, Germany to Calgary, Canada (~7,500km apart)

The image below shows a request made by a user in Berlin to the service endpoint in Germany. Excluding the time for Queueing and Stalled, the request took about 400 milliseconds. This is more than sufficient for most applications.

Cost Analysis

For cost analysis, since the cost of the primary region is fixed, we'll only consider the cost of running the secondary region.

For an additional $113 each month, you can have another region running and serving requests. This is much cheaper than setting up compute and database resources in another region.

These costs were calculated using the pricing provided in the AWS documentation.

Benefits

• Wider product reach: easily serve customers in multiple region

• Reduced cost: as seen from the cost analysis

• Reduced complexity: simplifies multi-region resource management

Limitations

• Reduced resiliency: failure of the primary region cripples all secondary region

• Increased latency: not suitable for applications needing very fast response times

• Data sovereignty: not suitable for customers who want their data to stay in their own country/region

• vpc-peering connection limitations (Can be resolved by replacing with transit gateway)

Conclusion

Sometimes, as service providers, we have customers in regions we don't currently support. This shouldn't be a reason to miss out on revenue or fail to offer them the best experience. With a bit of setup, you can provide them with something secure, private, and better than using the internet. Plus, when you eventually move workloads to those regions, your customers won't need to change anything on their end.

In this article, we explored a multi-region solution for serving customers using AWS services. By deploying a load balancer and leveraging AWS PrivateLink, you can securely and efficiently serve customers in different regions without managing servers across multiple locations. We covered the architecture, implementation using Terraform, speed analysis, cost analysis, and the benefits and limitations of this approach.

References

https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer

https://aws.amazon.com/elasticloadbalancing/pricing/

https://aws.amazon.com/lambda/pricing/