Author title

Simplify infrastructure self-service with Blueprints

Title category

Get all the latest content on Infrastructure as Code, DevOps, Spacelift features & news directly to your inbox!

Level up your IaC knowledge. Stay up to date with educational devops guides & news in infrastructure as code, cloud & more!

Managing Infrastructure at Scale | Spacelift Blog

Transform your IaC management to scale
securely, efficiently, and productively
into the future.

Blog

What Are Terraform Modules and How to Use Them: Tutorial

Terraform Functions, Expressions, Loops (Examples)

Managing Terraform State - Best Practices & Examples

Terraform For Loop - Expression Overview with Examples

What is Terraform? What is it Used For, How it Works

44 Ansible Best Practices to Follow [Tips & Tricks]

How to Stop and Remove Docker Containers

How to Create a CI/CD Pipeline with Docker [Tutorial]

CI/CD Pipeline : Everything You Need To Know

Kubernetes CI/CD Pipelines - 7 Best Practices and Tools

How to Deploy Infrastructure in CI/CD Using Terraform (Pipeline)

Terraform with Azure DevOps CI/CD Pipelines - Tutorial

Terragrunt Tutorial - Getting Started & Examples

Pulumi Pricing – Editions Overview 2024

73 Most Useful DevOps Tools to Use in 2024

Top 10 Terraform Enterprise Alternatives for 2024

Terraform Cloud/Enterprise Pricing - Tiers Overview 2024

16 Most Useful Infrastructure as Code (IaC) Tools for 2024

Terraform Cheat Sheet - 23 Terraform CLI Commands & Examples

ebook-global-banner

ebook global banner

Using generic CI/CD tools for your IaC automation? 🤖⚙️

Why Spacelift

How it works

Integrations

Product

Solutions

Scale your infrastructure safely and efficiently with an end-to-end workflow

productivity

Productivity

productivity-2

IaC at Scale

Standardize and control infrastructure provisioning and configuration

cicd

CICD

cicd-2

Infrastructure Governance

Implement and automate secure, collaborative workflows

team

Team

team-2

Collaboration

Make it easy for developers to provision and configure with a single workflow

speed-2

Speed

speed-3

Developer Velocity

By Initiative

CI/CD for Infrastructure

Drift Detection

Achieve Terraform at Scale

OpenTofu Migration

By Use Case

Request a meeting

Enjoy an action-packed day at AWS Summit London 2024, where the latest in cloud innovation comes to life.

ebook-pic

Practitioner’s Guide to Scaling IaC

Check out the Practitioner's Guide to Scaling IaC

Docs

Pricing

Resources

Learn more about Spacelift and infrastructure best practices

blog

blog-2

partners

Partners

partners-2

events

Events

events-2

Insights and quick guides to get you started

cheatsheets

Cheatsheets

cheatsheets-3

Ebooks & Cheatsheets

users

Users

users-2

Case studies

33-what-makes-spacelift-secure

What Makes Spacelift Secure

About Us

Contact Us

About

cheatsheets-2

Test

See more

Test webinar name

applepodcasts

spotify

missionctrl

Welcome to missionCTRL, a show dedicated to exploring the frontiers of modern DevOps. Listen (or watch) as we sit down with the practitioners who are pushing the boundaries of development

Importing existing infrastructure into terraform

Want to level up your Terraform knowledge? Explore our tutorials and step-by-step guides written by Terraform experts. Learn Terraform best practices and solutions to the most difficult problems.

Terraform Guides and Tutorials | Spacelift Blog

Terraform

Sumeet Ninawe

Flavius Dinu

In this tutorial, you will learn ways to import pre-existing cloud resources before you continue to develop the IaC in Terraform. This guide will provide you with an IaC import scenario, which is often faced by teams starting to adopt Terraform for their operations.
What we will cover:
<ol>
<li style="font-weight: 400;" aria-level="1"><a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform#what-is-terraform-import-command">What is Terraform import command?</a></li>
<li><a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform#why-use-the-import-command">Why use the import command?</a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform#terraform-import-use-cases">Terraform import use cases</a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform#how-to-use-terraform-import-for-resources">How to use Terraform import for resources?</a></li>
<li aria-level="1"><a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform#how-to-import-terraform-modules">How to import Terraform modules?</a></li>
<li aria-level="1"><a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform#terraform-import-example--importing-a-file">Terraform import example &#8211; importing a file</a></li>
<li aria-level="1"><a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform#importing-iam-roles-using-terraform-foreach">Importing IAM roles using Terraform for_each</a></li>
<li aria-level="1"><a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform#how-to-use-the-terraform-import-block-terraform-15-import">How to use the Terraform import block [Terraform 1.5 import]</a></li>
<li aria-level="1"><a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform#how-to-import-multiple-resources-in-terraform">How to import multiple resources in Terraform?</a></li>
<li aria-level="1"><a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform#common-questions-about-importing-terraform-resources">Common questions about importing Terraform resources</a></li>
<li aria-level="1"><a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform#best-practices-for-terraform-import">Best practices for Terraform import</a></li>
</ol>

<code>Terraform import</code> is a Terraform CLI command used to read real-world infrastructure and update its state so that future updates to the same set of infrastructure can be applied via Infrastructure as Code (IaC). It imports the pre-existing cloud resources into the Terraform state.
The import functionality helps update the state locally but does not automatically create the corresponding configuration. However, the Terraform team is working hard to improve this function in upcoming releases.
<h3>Terraform import syntax and parameters</h3>
The <code>terraform import</code> command takes the following arguments:
<ul>
<li style="font-weight: 400;" aria-level="1">ADDR – the address of the resource in terraform (e.g. aws_instance.instance_name)</li>
</ul>
<ul>
<li style="font-weight: 400;" aria-level="1">ID – the resource ID in the cloud provider/k8s/database service/vcs service/etc</li>
</ul>
An example <code>terraform import</code> would look like this:

Terraform is a relatively new technology, and adopting it to manage an organization’s cloud resources might take some time and effort. The lack of human resources and the steep learning curve involved in using Terraform effectively causes teams to start using cloud infrastructure directly via their respective web consoles.
For that matter, any kind of IaC method (CloudFormation, Azure ARM templates, Pulumi, etc.) requires some training and real-time scenario handling experience. Things get especially complicated when dealing with concepts like states and remote backends. In a worst-case scenario, you can lose the <a href="https://spacelift.io/blog/terraform-state" target="_blank" rel="noopener"><code>terraform.tfstate</code> file</a>. Luckily, you can use the import functionality to rebuild it.

Terraform import is used to add existing infrastructure components into Terraform management. Here are a couple of use cases in which <code>terraform import</code> can be a lifesaver:
<ul>
<li style="font-weight: 400;" aria-level="1">Bringing unmanaged resources under Terraform management – your company may have started its infrastructure adventure by doing ClickOps or by using some custom scripts. Now, to bring everything under Terraform, terraform import will be the solution.</li>
</ul>
<ul>
<li aria-level="1">Migrating between Terraform states – <code>terraform import</code> can help a lot if you want to split up your state file into multiple files, as managing a lot of things under a single file can be cumbersome.</li>
</ul>
<ul>
<li aria-level="1">Disaster recovery – if your state file gets corrupted or you don’t have access to it anymore for whatever reason, you can use <code>terraform import</code> to rebuild it.</li>
</ul>
<ul>
<li aria-level="1">Adopting Terraform in phases – with <code>terraform import</code> you can start by importing a couple of resources, helping you start small with Terraform.</li>
</ul>

Now that we understand why we need to import cloud resources into the Terraform state, let&#8217;s begin by importing a simple resource &#8211; an EC2 instance in AWS. 
We assume the Terraform installation and configuration of AWS credentials in AWS CLI is already done locally. We will not go into the details of that in this tutorial. 
To import a simple resource into Terraform, follow the step-by-step guide below.

<h3>1. Prepare the EC2 instance</h3>
Assuming the Terraform installation and configuration of AWS credentials in AWS CLI is already done locally, begin by importing a simple resource — EC2 instance in AWS. For the sake of this tutorial, we will create an EC2 resource manually to be imported. This could be optional if you already have a target resource to be imported.
<h4>Terraform: Create EC2 instance in the existing VPC</h4>
Go ahead and provision an EC2 instance in your AWS account. Here are the example details of the EC2 instance thus created:
Name: MyVM 
Instance ID: i-0b9be609418aa0609 
Type: t2.micro 
VPC ID: vpc-1827ff72 
&#8230;

<h3>2. Create main.tf and set provider configuration</h3>
The aim of this step is to import this EC2 instance into our Terraform configuration. Create <code>main.tf</code> in your desired path and configure the <a href="https://spacelift.io/blog/terraform-aws-provider" target="_blank" rel="noopener">AWS provider</a>. The file should look like below.
<h4>Importing EC2 instance into Terraform configuration: Example</h4>

Run <code>terraform init</code> to initialize the <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Terraform modules</a>. Below is the output of a successful initialization.

<h3>3. Write config for the resource to be imported</h3>
As discussed earlier, Terraform import does not generate the configuration files by itself. Thus, you need to create the corresponding configuration for the EC2 instance manually. This doesn’t need many arguments, as we will have to add or modify them when we import the EC2 instance into our state file.
However, if you don’t mind not seeing colorful output on CLI, you can begin adding all the arguments you know. But this is not a foolproof approach because normally, the infrastructure you may have to import will not have been created by you. So, it is best to skip a few arguments anyway.
In a moment, we will take a look at how to adjust our configuration to reflect the exact resource. For now, append the <code>main.tf</code> file with EC2 config. For example, we have used the below config. The only reason I have included <code>ami</code> and <code>instance_type</code> attribute, is that they are the required arguments for <code>aws_instance</code> resource block.

<h3>4. Run the import command</h3>
Think of it as if the cloud resource (EC2 instance) and its corresponding configuration were available in our files. All that’s left to do is to map the two into our state file. We do that by running the import command as follows.

A successful output should look like this:

The above command maps the <code>aws_instance.myvm</code> configuration to the EC2 instance using the ID. By mapping, we mean that the state file now “knows” the existence of the EC2 instance with the given ID. The state file also contains information about each attribute of this EC2 instance, as it has fetched the same using the import command.

<h3>5. Observe state files and plan output</h3>
Please note that the directory now also contains the <code>terraform.tfstate</code> file. This file was generated after the import command was successfully run. Take a moment to review its contents.
Right now our configuration does not reflect all the attributes. Any attempt to <code>plan</code>/<code>apply</code> this configuration will fail because we have not adjusted the values of its attributes. To close the gap between configuration and state files, run the <code>terraform plan</code> and observe the output.

The plan indicates that it would attempt to replace the EC2 instance. But this goes completely against our purpose. We could do it anyway by simply not caring about the existing resources, and creating new resources using configuration.
The good news is that Terraform has noted the existence of an EC2 instance associated with its state.

<h3>6. Improve config to avoid replacement</h3>
At this point, it is important to understand that the <code>terraform.tfstate</code> file is a vital piece of reference for Terraform. All of its future operations are performed with consideration for this state file. You need to investigate the state file and update your configuration accordingly so there is a minimum difference between them.
The use of the word “minimum” is intentional here. Right now, you need to focus on not replacing the given EC2 instance but rather aligning the configuration so that the replacement can be avoided. Eventually, you would achieve a state of 0 difference.
Observe the plan output and find all those attributes that cause the replacement. The plan output will highlight the same. In our example, the only attribute that causes replacement is the AMI ID. Closing this gap should avoid the replacement of the EC2 instance.
Change the value of <code>ami</code> from “unknown” to what is highlighted in the plan output, and run <code>terraform plan</code> again. Notice the output.

This time, the plan does not indicate the replacement of the EC2 instance. If you get the same output, you are successful in partially importing our cloud resource. You are currently in a state of lowered risk—if we apply the configuration now, the resource will not be replaced, but a few attributes would change.

<h3>7. Improve config to avoid changes</h3>
If we want to achieve a state of 0 difference, you need to align your resource block even more. The plan output highlights the attribute changes using <code>~</code> sign. It also indicates the difference in the values. For example, it highlights the change in the instance_type value from “t2.micro” to “unknown”.
In other words, if the value of <code>instance_type</code> had been “t2.micro”, Terraform would NOT have asked for a change. Similarly, you can see there are changes to the tags highlighted as well. Let’s change the configuration accordingly so that we can close these gaps. The final <code>aws_instance</code> resource block should look as follows:

Run <code>terraform plan</code> again, and observe the output.

If you have the same output, congratulations, as you have successfully imported a cloud resource into your Terraform config. It is now possible to manage this configuration directly via Terraform, without any surprises.

<ul>
<li><a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">5 Ways to Manage Terraform at Scale</a></li>
<li><a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">How to Automate Terraform Deployments and Infrastructure Provisioning</a></li>
<li><a href="https://spacelift.io/blog/terraform-environments" target="_blank" rel="noopener">How to Manage Multiple Terraform Environments Efficiently</a></li>
</ul>

Importing an existing resource into a module instance is not very different from importing an existing resource into a Terraform resource. The only difference is related to the address of the resource in Terraform, as it will be prefixed with the “module.module_instance_name”. 
This means that an example import for a Terraform module will look like this:

<h3>Terraform Import AWS VPC module example</h3>
In this section, you will learn how to import resources into the modules. For reference, we use the AWS VPC module (version 3.2.0) that creates 29 resources. Move the <code>terraform.tfstate</code> file to another location so that Terraform becomes unaware of the existing resources.
This poses the challenge of importing the AWS VPC module into your configuration. Modules wrap multiple AWS resources into a single package that can be reused in various projects. You should expect a large codebase and many resources to be part of the module.
The process of importing resources created using a module is very similar to what we have discussed thus far, with a little difference in running the command. Go through the <code>.tf</code> files included in the module’s source, and identify the resources to be imported.
For example, the AWS VPC module creates a VPC resource. To import this resource, run the command as below.
This command imports the target VPC resource in AWS to our module’s configuration.

Running the <code>plan</code> command indicates how many resources will be created. In other words, how many resources are yet to be imported.

The above output indicates 28 more resources to be imported to (re)build a perfectly consistent <code>terraform.tfstate</code> file. One less as we have successfully imported the VPC resource. Referring to the plan output, identify the resources in AWS and repeat the process for import.

Suppose you want to manage the lifecycle of a file using Terraform. The problem is that you decided to do this after the file was created. To solve this issue, we will need to import it.
We have defined a file called my_file with this content:

Now, let’s define the Terraform configuration for it:

Next, import the file:

As you can see, running import doesn’t help us because this resource does not support import. What we can do, however, is read the content directly from our file and recreate it like this:

The only issue with this is the fact that if you are using the file function, the old file must exist for reading the content. This can be overcome by adding the content directly in the content parameter.

Suppose you want to manage multiple <a href="https://spacelift.io/blog/terraform-iam-role" target="_blank" rel="noopener">IAM roles with Terraform</a> that already exist. In this example, I created two roles in my AWS account that I want to import using for_each.

terraform-import-module

Terraform Import Module

Now, let’s define the Terraform configuration for the roles:

We have to ensure we use the same role policy we have used inside our AWS account and the same description. 
Now that we have the configuration in place, let’s run a plan first to see that resources are not yet in the state:

Now we can import the resources:

Ensure you escape the quotation marks when you specify the role key while doing the import.
Now, let’s run another plan:

As you can see, the resources have been imported successfully.

In Terraform 1.5, a new import mechanism is available. A new top-level import block can be defined in your code to allow import operations. As this Terraform import block is added in the code, importing will not be a state operation. From now on, as for every other resource, it becomes a plannable operation.
<h3>Example: Terraform import S3 bucket</h3>
Let’s use a concrete example to see the new import in action.
<h4>1. Create the import block</h4>
For this, we have created two s3 buckets manually, and we want to import them in our state:
<ul>
<li style="font-weight: 400;" aria-level="1">import-bucket-tf15</li>
<li style="font-weight: 400;" aria-level="1">import-bucket-tf15-2</li>
</ul>

The Terraform import block, as you can see above, takes two parameters:
<ul>
<li style="font-weight: 400;" aria-level="1">id → The id of the resource used in your cloud provider</li>
<li style="font-weight: 400;" aria-level="1">to → The resource address that will be used in Terraform</li>
</ul>
<h4>2. Generate the configuration</h4>
Next, if you want to generate the configuration automatically, you can run the following command:

This will result in:

As you can see, config generation is still experimental at the moment of writing this article, so you should review it carefully before making any changes to your Terraform configuration.
<h4>3. Review the output</h4>
The resulting file will be similar to this:

<h4>4. Run <code>terraform plan</code></h4>
Now, if you run the <code>terraform plan</code>, this is the output you are going to see:

<h4>5. Run <code>terraform apply</code></h4>
After you are done with all the changes, you can simply run the <code>terraform apply</code> to add these resources to the state:

As you can see, the process of importing simple resources is pretty straightforward. The key here is to understand how Terraform state works. However, things can get quite tedious when importing complex deployments.
In the case of complex deployments, the team should clearly identify the resources they want to manage using Terraform. A diagram representing the entire landscape helps plan and get the parts of the deployment under Terraform’s management.
Planning output is key. If it is well-formatted, you will build a perfectly consistent state file. Prioritize and mitigate configurations that replace target resources, followed by configurations that cause changes. Import the resources as they are to satisfy the state file until there are no gaps. Once you achieve 0 gaps, any enhancement or code restructuring can be focused on and implemented.
<h3>The difference between Terraform import and Terraform state mv</h3>
With <code>terraform import</code> you are importing existing infrastructure resources inside of your state to manage them with Terraform. However, if you want to keep an object created with Terraform and manage it as a different resource (having a different name or moving it under a different module inside your configuration), you will need to use <code>terraform state mv</code>.

Now, we will answer some of your questions about this command.
<h3>Does running <code>terraform import</code> change anything?</h3>
Running <code>terraform import</code> won’t make any actual changes to your infrastructure; rather, it will just import that infrastructure resource to your Terraform state. Of course, if you then run an apply without defining the configuration for the imported resource, Terraform will have to destroy that resource because its configuration is not present.
<h3>Does <code>terraform import</code> generate code?</h3>
No, <code>terraform import</code> does not generate code. This falls under the engineer’s responsibility.
<h3>What are the disadvantages of running Terraform import?</h3>
Terraform import is a powerful tool that solves many issues related to manually created infrastructure. There are, however, some slight disadvantages when you are using it:
<ul>
<li style="font-weight: 400;" aria-level="1">You need to write the resource code after you import it.</li>
<li style="font-weight: 400;" aria-level="1">Without defining the exact configuration of the resource as the one you have done when creating it manually will result in <a href="https://spacelift.io/blog/drift-detection" target="_blank" rel="noopener">infrastructure drift</a>.</li>
<li style="font-weight: 400;" aria-level="1">In older versions of Terraform, you had to import resources one by one (now this can be done using the import block).</li>
</ul>
<h3>What is the difference between using Terraform data sources and importing a resource?</h3>
Terraform data sources are used to list details about existing resources. You can’t make changes to an existing resource with a data source. By importing it to Terraform, you can handle its entire lifecycle.
<h3>What is the difference between using <code>terraform import</code> and Terraformer?</h3>
<code>Terraform import</code> will import only one resource that you will have to specify explicitly. Terraformer can import multiple types of resources with a single command and also generate code for these resources.
<h3>Can only pre-existing objects be imported into Terraform?</h3>
Yes, only pre-existing objects can be imported into Terraform.

There are a couple of things you should consider before using <code>terraform import</code>:
<ul>
<li style="font-weight: 400;" aria-level="1">Understand your existing infrastructure and see how it would fit your Terraform configuration.</li>
<li style="font-weight: 400;" aria-level="1">Create your Terraform configuration first – before importing your resources, it will be really helpful to create your HCL code and ensure it actually reflects the settings and properties that have been set up for your IaC resources.</li>
<li style="font-weight: 400;" aria-level="1">Use version control – before doing imports, ensure your state file is managed remotely and also that you have versioning enabled for it. This also applies to your code configuration as well.</li>
<li style="font-weight: 400;" aria-level="1">Run a plan after import – it is very important to understand if the import worked properly and if the code configuration you’ve built really reflects the resource you have imported.</li>
</ul>

Although this article provides a comprehensive overview of possible approaches towards importing resources into Terraform, there is always room for some particular and unusual scenarios. If you have any questions or would like to share your common practices, feel free to tell us by leaving a comment below!
We encourage you also to explore <a href="https://docs.spacelift.io/" target="_blank" rel="noopener">how Spacelift makes it easy to work with Terraform</a>. If you need any help managing your Terraform infrastructure, building more complex workflows based on Terraform, and managing AWS credentials per run, instead of using a static pair on your local machine, Spacelift is a fantastic tool for this. It supports Git workflows, policy as code, programmatic configuration, context sharing, drift detection, and many more great <a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">features right out of the box</a>. You can check it for free by <a href="https://spacelift.io" target="_blank" rel="noopener">creating a trial account</a> or <a href="https://spacelift.io/schedule-demo" target="_blank" rel="noopener">booking a demo with one of our engineers</a>.
Note: New versions of Terraform are placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that expands on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6.

&#8211; Manage Terraform state and complex workflows effectively.
&#8211; Identify and remediate drift.
&#8211; Collaborate efficiently with context sharing, policy as code, programmatic configuration, resource visualization, and lots more.

Initialize/ plan/ apply your IaC, manage modules, state, and more. 

frame-8479

Frame 8479

Transform your IaC management to scale securely, efficiently, and productively into the future.

ebook-sidebanner

ebook bottom overlay

20 Terraform Best Practices to Improve your TF workflow

24 Most Useful Terraform Tools to Use in 2024

Terraform import example and tutorial. Learn how to use the command to import a module, resource, and EC2 instance. Terraform import block explained.

9-terraform-import

Importing Existing Infrastructure into Terraform - Step by Step

Jacob Martin

Occasionally you might want to rename an AWS S3 bucket you are managing with Terraform. However, names of S3 buckets are immutable, which means you can’t change them directly. If you tried, Terraform would destroy the old one and then create a new one, resulting in data loss.
To avoid this, you need to create a new bucket with the desired name, move the data over to it, make the relevant Terraform state replacements, and finally delete the old bucket.
In this post you will learn how to rename an AWS S3 bucket in <a href="https://spacelift.io/blog/what-is-terraform" target="_blank" rel="noopener">Terraform</a>. First things first &#8211; let’s say you have a bucket definition in your Terraform code:

and you want to change the name of the bucket to <code>new-name</code>.

Firstly, we’ll need to <a href="https://spacelift.io/blog/terraform-aws-s3-bucket" target="_blank" rel="noopener">create a new bucket</a>. You can do this using the AWS CLI or the <a href="https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/console-help-gsg.pdf" target="_blank" rel="nofollow noopener">AWS console</a>. Just make sure to properly replicate the old settings, especially the ACL (so that your data doesn’t accidentally become public).
Now, we can copy all the files from the old to the new bucket:

Now that we have our new bucket, we need to remove the old one from our Terraform state and <a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform" target="_blank" rel="noopener">import</a> the new one in its place:

If you tried to run Terraform now, it would show you that there’s drift—and yes, there would be! We’ve just imported a bucket into a resource which still has <code>old-name</code> in the config.

That’s why we now have to finally change the name of the bucket in our Terraform config:

If you run Terraform now, you’ll see that there are no changes to be made.

<ul>
<li><a href="https://spacelift.io/blog/terraform-best-practices" target="_blank" rel="noopener">20 Best Practices for Using Terraform</a></li>
<li><a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">How to Automate Terraform Deployments and Infrastructure Provisioning</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">How to Improve Your Infrastructure as Code using Terraform</a></li>
</ul>

If you want to, you can now delete your old bucket using:

Make sure all the data has successfully been copied over to the new bucket.

If you’re using Spacelift then you can use <a href="https://docs.spacelift.io/concepts/run/task" target="_blank" rel="noopener">tasks</a> to run the above arbitrary AWS CLI commands. The default runner image already contains the AWS CLI, so no changes are necessary there.
One additional thing you can do is <a href="https://docs.spacelift.io/concepts/stack/stack-locking" target="_blank" rel="noopener">lock the Stack</a> while you’re running the migration, this way nobody will accidentally run Terraform or make any other changes while you’re moving the data.
And that’s it! If you have any questions about how to rename an AWS S3 bucket, drop me a line in the comments and I’ll get back to you straight away.
Note: New versions of Terraform are placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that expands on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6.

If you are struggling with Terraform automation and management, check out Spacelift. It helps you manage Terraform state, build more complex workflows, and adds several must-have capabilities for end-to-end infrastructure management.

Provisioning AWS EKS Cluster with Terraform - Tutorial

Terraform Taint, Untaint, Replace - How to Use It (Examples)

Bootstrap Complete Amazon EKS Clusters with EKS Blueprints for Terraform

Learn how to rename an AWS S3 bucket in Terraform. See renaming process of Amazon s3 bucket in a few simple steps.

8-rename-aws-s3-bucket

How to rename aws s3 bucket

How to Rename an AWS S3 Bucket in Terraform - Step by Step

Learn more about new features, updates, and Spacelift product announcements.

Product Features and Updates | Spacelift Blog

Marcin Wyszynski

Atlantis is an old and battle-tested self-hosted tool that provides a layer of automation and collaboration for Terraform. Lacking a user interface other than server <a href="https://www.runatlantis.io/docs/server-configuration.html#flags" target="_blank" rel="nofollow noopener">flags</a> and <a href="https://www.runatlantis.io/docs/server-side-repo-config.html#do-i-need-a-server-side-repo-config-file" target="_blank" rel="nofollow noopener">YAML configuration files</a>, Atlantis uses your VCS as one, listening for pull request notifications and posting feedback as comments.
Using Atlantis has two major benefits over running Terraform in a “generic” CI system. First, it strikes the right balance between specialized and flexible: <a href="https://www.runatlantis.io/docs/custom-workflows.html" target="_blank" rel="nofollow noopener">custom workflows</a> give you a level of control that’s not possible within a tool like <a href="https://spacelift.io/blog/what-is-terraform-cloud" target="_blank" rel="noopener">Terraform Cloud</a>. Second, it runs on your infrastructure, which allows it to access resources inside a VPC or use cloud-specific dynamic credentials.
<a href="https://spacelift.io/atlantis-alternative" rel="">Spacelift</a> embraces all those characteristics of Atlantis but offers them in a modern and sophisticated SaaS product that provides:
<ul>
<li style="font-weight: 400;" aria-level="1">a more intuitive, <a href="https://docs.spacelift.io/concepts/policy/git-push-policy" target="_blank" rel="noopener">versatile</a>, and <a href="https://docs.spacelift.io/concepts/run/#run-state-machine" target="_blank" rel="noopener">robust</a> workflow;</li>
<li style="font-weight: 400;" aria-level="1">extremely granular access controls on <a href="https://docs.spacelift.io/concepts/policy/login-policy" target="_blank" rel="noopener">account</a> and <a href="https://docs.spacelift.io/concepts/policy/stack-access-policy" target="_blank" rel="noopener">project</a> level that works well with an <a href="https://docs.spacelift.io/integrations/single-sign-on/" target="_blank" rel="noopener">identity provider of your choice</a> (SSO);</li>
<li style="font-weight: 400;" aria-level="1">an <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">automated code review</a> and <a href="https://docs.spacelift.io/concepts/policy/task-run-policy" target="_blank" rel="noopener">threat detection</a> using a consistent open-source <a href="https://www.openpolicyagent.org/" target="_blank" rel="nofollow noopener">policy-as-code framework</a>;</li>
<li style="font-weight: 400;" aria-level="1">the ability to <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">declare complex workflows</a> between projects across multiple repositories;</li>
<li style="font-weight: 400;" aria-level="1">a <a href="https://docs.spacelift.io/vendors/terraform/module-registry" target="_blank" rel="noopener">built-in private module registry</a> with a full CI system for modules;</li>
<li style="font-weight: 400;" aria-level="1">effortless setup and customization with <a href="https://docs.spacelift.io/concepts/configuration/environment" target="_blank" rel="noopener">per-project environment management</a> and <a href="https://docs.spacelift.io/integrations/docker" target="_blank" rel="noopener">Docker integration</a>;</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://docs.spacelift.io/vendors/terraform/terraform-provider" target="_blank" rel="noopener">programmatic configuration</a> using Terraform;</li>
<li aria-level="1"><a href="https://docs.spacelift.io/concepts/stack/drift-detection" target="_blank" rel="noopener">drift detection;</a></li>
<li style="font-weight: 400;" aria-level="1">… and a myriad of creature comforts like <a href="https://docs.spacelift.io/concepts/configuration/context" target="_blank" rel="noopener">contexts</a>, <a href="https://docs.spacelift.io/concepts/run/task" target="_blank" rel="noopener">tasks</a>, or <a href="https://docs.spacelift.io/concepts/stack/#stack-locking" target="_blank" rel="noopener">stack locking</a>;</li>
</ul>
Let’s talk through each of these features one by one.

One of most frequent challenges while using Atlantis in practice is a non-intuitive workflow driven by its reliance on pull requests. Not only is it a lot of work to set up multiple <a href="https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#supporting-terraform-workspaces" target="_blank" rel="nofollow noopener">workspaces</a> pointing to the same Git repository but the result is fragile and nondeterministic. Since there’s no concept of mapping projects to branches or tags, anyone that can comment on an approved pull request can deploy arbitrary code to production, even if the approval was meant for a short-lived experimental environment.
Spacelift does not depend on pull requests. Sure, it will post beautiful comments there for your convenience, but it’s mostly driven by push and tag events, so it’s easy to build a sophisticated Git flow. Spacelift will report the outcome of its jobs as commit status checks, which then allows you to block merging the code on a failing Spacelift check. There are <a href="https://docs.spacelift.io/concepts/run/#where-do-runs-come-from" target="_blank" rel="noopener">two main types of runs</a> &#8211; proposed and tracked. By default, each project points at a particular branch (and optionally also a path) &#8211; pushing to that branch will trigger a tracked run &#8211; one that can be applied. This behavior can be customized using <a href="https://docs.spacelift.io/concepts/policy/push-policy/" target="_blank" rel="noopener">Git push policies</a>. Thanks to that, Spacelift can provide the same level of comfort and security to teams using one project per repository and those using monorepos with hundreds of interdependent projects. You can read more about our approach to VCS integration <a href="https://docs.spacelift.io/integrations/source-control/github#tracked-branches" target="_blank" rel="noopener">here</a>.

Another pain point when using Atlantis at scale is its access control model. By relying on comments on pull requests to drive infrastructure deployments, Atlantis effectively yields control over your infrastructure to the VCS provider. While this is usually fine when a single repository drives a single Terraform project, this becomes a huge liability for more complex scenarios.
Spacelift ships with a sophisticated mechanism allowing administrators to declare <a href="https://docs.spacelift.io/concepts/policy/login-policy" target="_blank" rel="noopener">who can log in</a> (and under what circumstances) and <a href="https://docs.spacelift.io/concepts/policy/stack-access-policy" target="_blank" rel="noopener">what should be their level of access</a> to each of the managed projects. Since it’s 2020, Spacelift ships with SSO out of the box, supporting every identity provider that speaks SAML 2.0 protocol. Even our <a href="https://docs.spacelift.io/integrations/chatops/slack" target="_blank" rel="noopener">Slack integration</a> can be subject to policy controls, allowing an admin to grant access to a project <a href="https://docs.spacelift.io/integrations/chatops/slack#managing-access-to-stacks-with-policies" target="_blank" rel="noopener">based on Slack-specific data</a> (think team, channel, user etc.). For extra protection, powerful features like Tasks have their own independent policy controls.

Both Spacelift and Atlantis let you use <a href="https://www.openpolicyagent.org/" target="_blank" rel="nofollow noopener">Open Policy Agent</a> &#8211; an open-source solution endorsed by <a href="https://www.cncf.io/" target="_blank" rel="nofollow noopener">Cloud Native Computing Foundation</a> &#8211; to ensure that your infrastructure is compliant with industry best practices and your company policies. Atlantis integrates with <a href="https://www.runatlantis.io/docs/policy-checking.html#how-it-works" target="_blank" rel="nofollow noopener">conftest</a> to achieve that and lets you verify each Terraform plan using OPA policies.
Spacelift goes a few steps further though and puts policy-as-code in the center of its value proposition and builds a consistent, <a href="https://docs.spacelift.io/concepts/policy/" target="_blank" rel="noopener">robust policy framework</a>. Apart from providing a comprehensive automated change review and ensuring compliance of your <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">Terraform changes</a>, Spacelift uses the same approach to allow you to declare rules around <a href="https://docs.spacelift.io/concepts/policy/login-policy" target="_blank" rel="noopener">account</a> and <a href="https://docs.spacelift.io/concepts/policy/stack-access-policy" target="_blank" rel="noopener">project access</a>, <a href="https://docs.spacelift.io/concepts/policy/push-policy/" target="_blank" rel="noopener">handling push notifications</a>, <a href="https://docs.spacelift.io/concepts/policy/run-initialization-policy" target="_blank" rel="noopener">starting runs</a> and <a href="https://docs.spacelift.io/concepts/policy/task-run-policy" target="_blank" rel="noopener">triggering tasks</a>, and creating <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">relationships between projects</a>. It also provides the Policy Workbench, which lets you view past executions of your policy &#8211; including the inputs and decisions that have been made &#8211; and lets you interactively edit your policy, while simulating its execution on these previous inputs. You can use our <a href="https://github.com/spacelift-io/terraform-starter" target="_blank" rel="nofollow noopener">starter repo</a> to quickly provision a bunch of policies and get a feel for how you can work with them in Spacelift.

Handling interdependencies between projects has always been Terraform’s Achilles&#8217; heel and Atlantis is no different in that regard. The usual approach to this problem is adding another layer of abstraction in the form of a Terraform wrapper like <a href="https://terragrunt.gruntwork.io/" target="_blank" rel="nofollow noopener">Terragrunt</a>. While this breaks the problem into smaller chunks, it’s only a partial solution achieved at a cost of locking yourself into another dependency.
<a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">Spacelift’s trigger policies</a> on the other hand provide a smart, declarative automation layer on top of vanilla Terraform. These allow you to plug into state changes of individual projects and declare dependencies that should be resolved following the changes that have just been applied. In fact, this is just a subset of all use cases covered by trigger policies. <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">Read more</a> to discover other exciting possibilities.

<ul>
<li><a href="https://spacelift.io/blog/atlantis-terraform" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Atlantis vs. Terraform Cloud vs. Terraform Enterprise&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Atlantis vs. Terraform Cloud vs. Terraform Enterprise</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to Improve Your Infrastructure as Code using Terraform&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">How to Improve Your Infrastructure as Code using Terraform</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Common Infrastructure Challenges and How to Solve Them&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Common Infrastructure Challenges and How to Solve Them</a></li>
</ul>

Another problem that one needs to solve externally when using Atlantis is authoring and maintaining reusable Terraform modules for your organization. Terraform is flexible in allowing modules to come from <a href="https://www.terraform.io/docs/modules/sources.html" target="_blank" rel="nofollow noopener">various sources</a> but ensuring confidential access as well as testing and versioning are left to you, the user.
Until now, the golden standard in that regard has been the <a href="https://www.terraform.io/docs/cloud/registry/index.html" target="_blank" rel="nofollow noopener">private module registry from HashiCorp</a>. But Spacelift offers that, and much more. Far from being just a glorified package manager, Spacelift adds a <a href="https://docs.spacelift.io/vendors/terraform/module-registry" target="_blank" rel="noopener">full CI solution for Terraform modules</a>, out of the box and free of charge. You can thus ensure that your private modules are healthy before you distribute them to the rest of your organization.

If you manage a single or a handful of rarely changing projects using Atlantis, it’s likely that you just set it up once and forget about it. But in a more dynamic environment, where microservices come and go, new environments proliferate and new product teams require their own <a href="https://spacelift.io/blog/terraform-workspaces" target="_blank" rel="noopener">Terraform workspaces</a>, the need to configure Atlantis each and every time becomes a major nuisance putting a lot of pressure on your DevOps team.
Enter Spacelift. In Spacelift, much of the configuration can be handled by the project owners themselves &#8211; you can add Terraform and/or <a href="https://docs.spacelift.io/concepts/configuration/environment" target="_blank" rel="noopener">environment variables</a> and mount files (even inject Terraform code!) programmatically or through the GUI without the need for administrative privileges or changing the central server configuration. For administrators, adding new projects requires minimal hassle since there’s no need to set up webhooks or change any YAML. And it can all be done programmatically, using Terraform.

What comes as a pleasant surprise to long-time Atlantis users, Spacelift entities like stacks, contexts, modules or policies as well as their configuration can be managed in a declarative way using your favorite infra-as-code tool. Yes, that’s right &#8211; <a href="https://docs.spacelift.io/vendors/terraform/terraform-provider" target="_blank" rel="noopener">Spacelift offers a Terraform provider</a> that allows you to manage the lifecycle of its own resources programmatically.
 Administrative stacks get credential-less access to the subset of our <a href="https://docs.spacelift.io/integrations/api" target="_blank" rel="noopener">GraphQL API</a> that does not involve managing the actual infrastructure. For more sophisticated use cases, Spacelift allows you to generate API keys that are subject to the same access controls as normal users are, allowing you to create single-purpose tokens for restricted use by your internal scripts.

<a href="https://www.hashicorp.com/blog/detecting-and-managing-drift-with-terraform" target="_blank" rel="nofollow noopener">Infrastructure drift happens.</a> Either somebody will make manual changes while debugging and then forget about them, or you might have data sources whose outputs change periodically. Normally, you would notice these changes only after you execute your next plan or apply.
Spacelift has got you covered here. You can configure periodic <a href="https://docs.spacelift.io/concepts/stack/drift-detection" target="_blank" rel="noopener">drift detection</a> to be notified whenever drift happens and take immediate action. You can go a step further too with optional automatic <a href="https://docs.spacelift.io/concepts/stack/drift-detection#to-reconcile-or-not-to-reconcile" target="_blank" rel="noopener">reconciliation</a>, ensuring your infrastructure always resembles your Terraform configuration.

Last but not least, Spacelift puts an emphasis on great user experience, offering a myriad of creature comforts. <a href="https://docs.spacelift.io/concepts/configuration/context" target="_blank" rel="noopener">Contexts</a> for example allow you to attach entire collections of configuration to individual stacks and modules. <a href="https://docs.spacelift.io/concepts/run/task" target="_blank" rel="noopener">Tasks</a> provide a powerful audited way of running one-off administrative commands on an initialized Terraform environment &#8211; subject to <a href="https://docs.spacelift.io/concepts/run/task" target="_blank" rel="noopener">their own policy constraints</a>. <a href="https://docs.spacelift.io/concepts/stack/#stack-locking" target="_blank" rel="noopener">Stack locking</a> allows a single individual to take exclusive control over a stack to ensure that nobody is able to modify its state while crucial changes are being made. The <a href="https://docs.spacelift.io/concepts/resources" target="_blank" rel="noopener">resources visualization</a> shows you all the resources you’re managing in your account, when and how they’ve last been updated, and lets you slice and dice them using a plethora of views, filters and groupings.

Spacelift is an Atlantis alternative that embraces all of its features, offering them in a modern and sophisticated SaaS product that provides a more intuitive, versatile, and robust workflow, granular access control, drift detection, and many more.

Importing Existing Infrastructure Into Terraform - Step by Step

Spacelift is an Atlantis alternative that embraces all the characteristics of Atlantis but offers them in as a modern and sophisticated SaaS product.

Importing Existing Infrastructure Into Terraform – Step by Step

Get the newsletter

Recent posts

Importing Existing Infrastructure Into Terraform – Step by Step

How to Rename an AWS S3 Bucket in Terraform – Step by Step

Alternative to Atlantis – Spacelift

What is Terraform? What is it Used For, How it Works

Share your data and download the guide