Terraform with AWS has become the dominant approach for teams that want automation, repeatability, speed, security, and cost control instead of manual console clicks. AWS makes it easy to build and scale in the cloud without managing physical infrastructure. Terraform takes that a step further by letting you define AWS infrastructure as code, so you can provision, change, and version resources safely and repeatably.
The core workflow remains the same across projects: Initialize, Plan, Apply. Initialize installs the plugins Terraform needs to manage the infrastructure. Plan previews the changes Terraform will make to match your configuration. Apply makes the planned changes. This three-step model forms the foundation for reliable, team-friendly deployments at scale.
What Terraform Is and How It Works on AWS
Terraform is an infrastructure as code tool that allows you to manage your infrastructure with configuration files rather than through a graphical user interface. The configuration files are plain text having the .tf extension or JSON based having the extension .tf.json. Terraform uses the HCL language to provision resources from different infrastructure providers.
Terraform is declarative. You tell Terraform what you want, it figures out how to build it. Terraform is idempotent. Running the same code always produces the same result. Terraform is cloud-agnostic. AWS, Azure, GCP, Kubernetes, and more are supported. Terraform is reusable. Modules let you scale infrastructure like software.
In practice, Terraform can be used in AWS to automate the provisioning and management of a wide range of cloud infrastructure resources. The tool does not require any software to be installed on the managed infrastructure. It is agentless.
A typical Terraform workflow on AWS follows these steps:
- Initialize - terraform init
- Plan - terraform plan
- Apply - terraform apply
The diagram below shows a typical Terraform workflow.
Getting Started with the AWS Provider
Before we begin working on AWS, ensure that the Terraform CLI is installed and your AWS credentials are configured. If you haven’t done this yet, follow these steps.
Create Terraform configuration files. To get started with Terraform, the first step is to tell Terraform that you will be deploying your infrastructure on AWS. We can do this by configuring the AWS cloud provider plugin.
Add the block with its name as aws in the main.tf file. Once you initialize the plugin, Terraform will use this information to take care of the rest and set up everything it needs to deploy your resources on AWS.
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
Initialize your configuration. Let’s run the terraform init command to start initializing provider plugins and set up the configuration. We successfully initialized our configuration.
Do I need the AWS CLI to use Terraform with AWS? No. Terraform can authenticate without the AWS CLI. But the AWS CLI is a convenient way to set up profiles, SSO, and validate credentials quickly.
Authentication Patterns for AWS
Terraform authenticates to AWS via the AWS provider, which uses the same credential resolution chain as the AWS SDK. In practice, you typically use one of three patterns:
- AWS SSO/Identity Center
- Short lived role assumption
- Standard access keys
You should prefer ephemeral credentials over long lived keys.
The credential resolution is handled by the provider, so no AWS CLI is required for Terraform to run. The AWS CLI remains useful for initial profile setup and quick validation.
| Authentication pattern | Description |
| AWS SSO/Identity Center | Centralized identity with temporary tokens |
| Short lived role assumption | Assume role with limited duration |
| Standard access keys | Long lived keys, discouraged for production |
State Management and Team Workflows
What’s the recommended way to manage Terraform state on AWS? Use a remote backend commonly S3 so teams/CI share one source of truth. Enable bucket versioning and encryption, and avoid keeping state only on a developer laptop.
Remote state enables collaboration and protects against loss. S3 with versioning provides durability and auditability. State locking prevents concurrent applies that can corrupt state.
Modules are a powerful way to reuse code and stick to the Don't Repeat Yourself principle. For example, you might have a specific configuration for an application which contains an Amazon Elastic Compute Cloud instance, Amazon Elastic Block Store volumes, and other resources that are logically grouped. If you need to create multiple copies of this configuration or application, you can package the resources into a Terraform module and create multiple instances of the module rather than copying the entire code multiple times. These modules can help you to organize, encapsulate, and reuse configurations.
Terraform vs AWS-Native Tools
How does Terraform compare to other AWS infrastructure management tools? Terraform offers cloud-agnostic infrastructure as code, making it well-suited for managing multi-cloud or hybrid environments. Compared to AWS-native tools like CloudFormation, Terraform provides a more flexible syntax, HCL, a larger provider ecosystem, and a consistent workflow across platforms. CloudFormation integrates more deeply with AWS features, including drift detection and stack policies, but is limited to AWS and has a steeper learning curve for complex stacks.
If your experience with provisioning cloud resources exclusively lies within the realm of AWS, you might have limited experience with infrastructure as code tools beyond the AWS Cloud Development Kit and AWS CloudFormation. In fact, similar tools, such as Hashicorp Terraform, might be completely unfamiliar to you. However, the deeper you get into your cloud journey, the more inevitable it becomes that you'll encounter Terraform. It will be decidedly to your advantage to be familiar with its core concepts.
While Terraform, the AWS CDK, and CloudFormation achieve similar goals and share many core concepts, there are quite a few differences. You might not be prepared for these differences if you're approaching Terraform for the first time. After all, AWS CDK and CloudFormation stacks are all based within AWS accounts, so in that way, they have a direct relationship with most of the resources that they maintain. Terraform is not based within any single cloud provider's environment. This gives it the flexibility to support various different providers, but it must maintain resources from what amounts to a remote location.
This guide helps demystify the core concepts behind Terraform to help you handle any IaC challenge that comes your way.
| Feature | Terraform | AWS CloudFormation |
| Cloud scope | Platform agnostic, multi-cloud support | Limited to AWS |
| Syntax | HCL, larger provider ecosystem | JSON/YAML, AWS native |
| Workflow consistency | Consistent across platforms | AWS specific |
| Deep AWS integration | Less deep than native | Drift detection, stack policies |
| Learning curve | Flexible for complex stacks | Steeper for complex stacks |
Advantages of using Terraform:
- Terraform is platform agnostic. You can use it with any cloud services provider. You can configure, test, and deploy infrastructure across AWS and many other cloud providers. If your organization uses multiple cloud providers, Terraform can be a single, unified, consistent solution to manage cloud infrastructure.
- Terraform is agentless. It doesn't require any software to be installed on the managed infrastructure.
- Terraform modules are a powerful way to reuse code and stick to the Don't Repeat Yourself principle.
Licensing and Cost Considerations
Is Terraform free to use with AWS? Terraform CLI is source-available under the Business Source License 1.1 for recent versions. There is no extra fee for using the AWS provider, but you pay AWS for provisioned resources. Terraform Cloud or Enterprise can add costs.
OpenTofu 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.
Manage Terraform better with Spacelift. Orchestrate Terraform workflows with policy as code, programmatic configuration, context sharing, drift detection, resource visualization, and more.
Why Terraform on AWS Remains Popular in 2026
Infrastructure in 2026 is no longer about clicking buttons in the AWS console. Companies want automation, repeatability, speed, security, and cost control and this is exactly why Terraform on AWS has become the gold standard for Infrastructure as Code.
If you're a beginner who wants the clearest, most complete, and simplest explanation of Terraform on AWS, you’re in the right place. This guide goes from zero to fully working Terraform project with explanations simple enough for beginners and deep enough for professionals.
AWS is the world’s most widely used cloud platform. Terraform provides a declarative, idempotent, cloud-agnostic, and reusable way to manage it.
Conclusion
Terraform with AWS delivers a remote, provider-agnostic control plane that can describe, preview, and apply infrastructure changes from outside any single cloud account. The AWS provider configuration establishes the connection, the init plan apply cycle provides safe change management, and remote S3 state with versioning and encryption provides team safety.
Authentication does not require the AWS CLI, though the CLI remains useful for profile and SSO setup. Ephemeral credentials via AWS SSO or role assumption are preferred over long lived access keys. Modules enable reuse and DRY principles across teams and environments.
Compared with CloudFormation and AWS CDK, Terraform trades deep native AWS integration for portability, a larger ecosystem, and a consistent workflow across clouds. CloudFormation integrates more deeply with AWS features, including drift detection and stack policies, but is limited to AWS.
For organizations that need multi-cloud or hybrid strategies, or that want a single workflow for AWS and other providers, Terraform on AWS remains the gold standard for infrastructure as code in 2026. The combination of HCL configuration, provider plugins, remote state, and module reuse gives teams automation, repeatability, and governance without sacrificing flexibility.