Introduction

CloudFormation can manage resources that already exist, but it does not “discover and adopt” them automatically during a normal stack update. The supported workflow is resource import: you define the resources in a template, identify the physical resources to import, and execute an import change set.

What Resource Import Actually Does

Resource import lets you bring existing supported AWS resources under CloudFormation management without recreating them. The template must describe the imported resources, and the import operation needs enough identifying information to map each logical resource in the template to a real AWS resource.

Two important constraints come first:

• not every CloudFormation resource type supports import
• each imported resource must have a DeletionPolicy in the template

That second point is easy to miss and is required by the official workflow.

Add the Existing Resource to the Template

Suppose you already have an S3 bucket named existing-demo-bucket. Your template might look like this:

1AWSTemplateFormatVersion: '2010-09-09'
2Resources:
3  ExistingBucket:
4    Type: AWS::S3::Bucket
5    DeletionPolicy: Retain
6    Properties:
7      BucketName: existing-demo-bucket

This template does not create a new bucket during import. Instead, it describes the bucket that CloudFormation should start managing.

Create the Resource Mapping File

For CLI-based import, provide the resource identifiers in JSON:

1[
2  {
3    "ResourceType": "AWS::S3::Bucket",
4    "LogicalResourceId": "ExistingBucket",
5    "ResourceIdentifier": {
6      "BucketName": "existing-demo-bucket"
7    }
8  }
9]

Save that as resources-to-import.json.

Run an Import Change Set

CloudFormation performs the import through a change set whose type is IMPORT:

1aws cloudformation create-change-set \
2  --stack-name demo-stack \
3  --change-set-name import-existing-bucket \
4  --change-set-type IMPORT \
5  --template-body file://template.yaml \
6  --resources-to-import file://resources-to-import.json

Then wait for the change set to finish creating and review it:

aws cloudformation describe-change-set \
  --stack-name demo-stack \
  --change-set-name import-existing-bucket

If it looks correct, execute it:

aws cloudformation execute-change-set \
  --stack-name demo-stack \
  --change-set-name import-existing-bucket

After execution, the bucket is part of the stack.

Validate the Template Before Import

The import will fail if the template does not accurately describe the existing resource or if required properties are missing. Import also does not magically reconcile configuration drift. If the actual resource differs from the template in important ways, the operation may fail or later updates may become dangerous.

A practical workflow is:

1. inspect the existing resource carefully
2. model it in the template as accurately as possible
3. import it
4. run drift detection later to verify ongoing alignment

When Import Is the Wrong Tool

Do not use resource import if you are willing to recreate the resource more simply. Import is useful for stateful or hard-to-replace infrastructure such as databases, buckets, or existing networking resources, but it adds operational care.

Also, not every AWS resource type is importable. If the type is unsupported, the only options are usually to leave it unmanaged by CloudFormation or rebuild it under CloudFormation control.

Common Pitfalls

The most common mistake is trying to add the resource to the template and then running a normal update-stack. That does not perform an import and may instead try to create a conflicting resource.

Another issue is forgetting DeletionPolicy on the imported resource. CloudFormation requires it for the import workflow.

Teams also misread import as drift reconciliation. Import attaches the resource to the stack, but it does not fix every mismatch between the current live configuration and the template.

Finally, always confirm that the resource type supports import before building the workflow around it.

Summary

• Existing AWS resources are brought into CloudFormation with resource import, not a normal stack update.
• The template must define the resource and include DeletionPolicy.
• Use an IMPORT change set plus a resources-to-import mapping file.
• Import only works for supported resource types.
• Model the real resource accurately before import so later stack updates stay safe.