How to Import Existing AWS Resources into the Serverless Framework (Using CloudFormation Import)

Introduction

While working on a project to fully transition an application into Infrastructure as Code (IaC), I encountered a challenge that proved more difficult than I expected: importing existing AWS resources into the Serverless Framework.

The application already had several AWS resources created manually over time, including multiple SQS queues used by different services. Since our goal was to have all infrastructure managed through IaC, we needed those existing resources to be managed directly inside our serverless.yml.

At first thought, this seemed straightforward. However, I discovered that Serverless Framework does not provide a direct way to import existing resources into a stack.

Since Serverless deployments are built on top of AWS CloudFormation, the only reliable way to achieve this is by using CloudFormation’s resource import functionality. Even then, the process can be tricky, and if done incorrectly, it can cause stack drift or even delete existing resources.

Because I couldn't find a clear, practical guide that walks through this process from start to finish, I decided to document the approach that worked for us.

Understanding The Challenge

The Serverless Framework uses AWS CloudFormation under the hood to create and manage infrastructure. When you deploy a Serverless application, the resources defined in serverless.yml are translated into a CloudFormation template and applied to a stack.

This workflow works well when CloudFormation is responsible for creating the resources from the beginning. However, the situation becomes more complicated when the resources already exist.

In many real-world projects, infrastructure evolves. Some resources may have been created manually through the AWS console, while others may have been created by different deployment tools. As a result, these resources exist outside of the CloudFormation stack managed by Serverless.

Serverless Framework cannot manage these resources because CloudFormation isn't aware of them.

To bring these resources under IaC management, they must first be imported into the CloudFormation stack that Serverless controls.

CloudFormation does provide a resource import feature, but it has strict requirements:

• The resource configuration in the template must match the existing resource

• A valid resource identifier must be provided

• No unrelated stack changes can occur during the import

In our case, the goal was to import several existing SQS queues into our Serverless stack so they could be fully managed through serverless.yml without recreating or disrupting the existing resources.

The Approach that Worked

After experimenting with different options, the most reliable approach we found was to use AWS CloudFormation’s Infrastructure as Code (IaC) Generator to scan existing resources and generate a template that could be safely imported into our Serverless stack.

This allowed us to import the resources without recreating them, while ensuring the generated template accurately reflected the existing configuration.

The process involved four main steps.

Existing AWS Resources
        ↓
IaC Generator Scan
        ↓
Template Generation
        ↓
CloudFormation Import
        ↓
Managed in Serverless

Step 1: Scan The Existing Resources

The first step is to scan the AWS account for the resources you want to import.

In the CloudFormation console, navigate to IaC Generator and click Scan.

You’ll be presented with two options:

• Scan all resources

• Scan specific resources

Since we only needed to import SQS queues, we selected Scan specific resources and chose the resource type:

AWS::SQS::Queue

CloudFormation then scans the account and identifies all SQS queues that exist in the account.

This scan allows AWS to capture the configuration of those resources so they can be represented in a CloudFormation template.

Selecting AWS::SQS::Queue when scanning resources using the CloudFormation IaC Generator.

Step 2: Generate a Template for the Existing Stack

Once the scan is completed, CloudFormation displays a success message and prompts you to create a template from the scanned resources.

Click Create Template, and you will be given two options:

• Start a new template

• Update a template for an existing stack

Since we wanted the resources to be managed by our existing Serverless stack, we selected:

Update a template for an existing stack

Next, you’ll be asked to choose the stack you want to update. In our case, this was the stack created by our Serverless deployment.

After selecting the stack, CloudFormation asks for a few template details:

Template Name

A name for the generated template.

Deletion Policy

Defines what happens to the resource if it is removed from the stack.

For example:

DeletionPolicy: Retain

This ensures the resource is not deleted if it is later removed from the CloudFormation stack.

Update Replace Policy

Defines what happens if CloudFormation needs to replace the resource during an update.

Using Retain here also helps prevent accidental deletion.

After providing these details, CloudFormation shows the list of resources that were discovered during the scan.

At this stage:

• Resources already managed by a stack cannot be selected.

• Resources not yet managed by any stack can be selected for import.

You can then choose the specific resources you want to add to the existing stack.

In the next step, CloudFormation checks if the selected resources require related resources. Some AWS services require dependent resources to be imported together, but in the case of SQS queues, there were no additional dependencies required.

Finally, you are given a chance to review the generated template before creating it.

Choosing to update the template for an existing stack.

Selecting the SQS queues to add to the existing stack.

Step 3: Import the Resources

After the template is created, CloudFormation allows you to import the resources directly into the selected stack.

Because the template was generated from the scanned resources and tied to the existing stack, the import process becomes much smoother.

There is no need to manually create a change set or define logical resource IDs. The IaC Generator already handles this as part of the template generation process.

Once the import is executed successfully, the resources appear inside the CloudFormation Resources tab for the stack.

At this point, the imported resources become fully managed by the stack, which means future deployments can safely reference them from serverless.yml.

The imported SQS queue now appears as a managed resource in the CloudFormation stack.

Step 4: Define the Resources in serverless.yml

Once the resources are imported successfully, the next step is to define them inside serverless.yml so that future deployments continue to manage them correctly.

For example:

resources:
  Resources:
    SQSQueueDemoimportqueue:
      Type: AWS::SQS::Queue
      Properties:
        QueueName: demo-import-queue

To keep the configuration clean and reusable across environments, we defined queue names inside the custom block:

custom:
  queue_suffix:
    dev: ""
    staging: "_staging"
    prod: "_prod"

  queues:
    email_queue:
      name: demo-queue${self:custom.queue_suffix.${sls:stage}}

This approach allows the same resource definition to work across multiple environments while keeping naming consistent.

Things to Watch Out For When Importing Resources

While the import process is fairly straightforward when using the IaC Generator, there are a few things to keep in mind.

Resources Already Managed by Another Stack

If a resource is already associated with a CloudFormation stack, it cannot be imported into another stack. During the template creation step, CloudFormation will indicate which resources are already managed and prevent them from being selected.

If you need to move a resource between stacks, ensure the original stack removes the resource safely before attempting the import.

Use a Safe Deletion Policy

When generating the template, it is recommended to set:

DeletionPolicy: Retain

This prevents the resource from being deleted if it is later removed from the stack.

For stateful resources like SQS queues, this provides an additional safety layer.

Ensure the Resource Configuration Matches

CloudFormation imports require the template configuration to match the existing resource configuration.

Using the IaC Generator helps avoid this issue since it generates the template directly from the existing resources.

Conclusion

Importing existing AWS resources into the Serverless Framework isn’t always straightforward because Serverless relies on CloudFormation to manage infrastructure. This means that existing resources must first be imported into the underlying CloudFormation stack before they can be managed through serverless.yml.

By using the IaC Generator to scan resources and generate a template for an existing stack, we were able to safely import our SQS queues without recreating them. Once imported, defining them in serverless.yml allows Serverless to manage them as part of future deployments.

Although the process requires a few careful steps, it provides a reliable way to bring existing infrastructure under Infrastructure as Code.