Day 26 -Terraform Cloud and Workspace Management
For Day 26 of my AWS Terraform learning journey, I explored HCP Terraform Cloud and workspace management.
Until now, most of my Terraform projects were executed from my local machine. I used local state in the beginning and later moved to an S3 remote backend with state locking. That approach works well, especially for AWS based projects, but Terraform Cloud gives a more centralized way to manage Terraform runs, remote state, variables, logs, and collaboration.
The goal of this project was to understand how Terraform Cloud works in a practical setup.
I created a Terraform Cloud account, created a workspace, connected Terraform CLI to the workspace, and deployed a small AWS environment using Terraform.
Architecture
The architecture for this project is simple.
A developer runs Terraform commands from the local machine. Terraform CLI connects to the Terraform Cloud workspace. Terraform Cloud manages the run, stores state remotely, and provisions AWS resources using the AWS provider.
The AWS side includes a VPC, two public subnets, an internet gateway, route table configuration, and a private S3 bucket.
Terraform Cloud Setup
After creating my HCP Terraform Cloud account, I created a workspace named:
day26-terraform-cloud
The workspace acts as the execution and state boundary for this project. In a real team setup, I would usually create separate workspaces for environments such as dev, test, stage, and prod.
Example:
app-dev
app-stage
app-prod
This keeps state isolated and makes it easier to control deployments.
Terraform CLI Login
To connect my local Terraform CLI with Terraform Cloud, I used:
terraform login
This command opened the browser and generated an authentication token. After login, Terraform CLI was able to communicate with my Terraform Cloud organization.
Terraform Cloud Configuration
Instead of using an S3 backend block, I used the Terraform cloud block.
terraform {
cloud {
organization = "katta"
workspaces {
name = "day26-terraform-cloud"
}
}
}
This tells Terraform to use HCP Terraform Cloud for this configuration.
After that, I ran:
terraform init
Terraform initialized successfully and connected the local code with the Terraform Cloud workspace.
Note:
Infrastructure Created
For testing, I created a small AWS environment.
Resources included:
VPC
Two public subnets
Internet gateway
Public route table
Route table associations
S3 bucket
S3 public access block
The purpose was not to build a complex application. The purpose was to confirm that Terraform Cloud can manage an AWS deployment and store the state remotely.
Terraform Plan
Prerequisites
Before running Terraform plan remotely through HCP Terraform Cloud, I completed the following prerequisites:
- Configured AWS credentials as sensitive environment variables inside the Terraform Cloud workspace
The AWS credentials were required because Terraform Cloud executes plans and applies remotely using HashiCorp managed runners. Even though AWS CLI authentication was already configured on my local machine, those credentials are not automatically shared with Terraform Cloud remote runs.
I added the following workspace environment variables under:
Workspace → Variables
| Variable | Type |
|---|---|
| AWS_ACCESS_KEY_ID | Environment Variable |
| AWS_SECRET_ACCESS_KEY | Environment Variable |
Sensitive = Yes
After adding these variables, the remote Terraform plan executed successfully.
terraform plan
The plan showed the resources Terraform was going to create.
This is useful because the run history is visible inside Terraform Cloud. In a team environment, this gives better visibility compared to running everything only from a laptop.
Terraform Apply
Then I ran:
terraform apply
Terraform created the AWS resources successfully.
One important thing I learned during this exercise was how Terraform Cloud handles AWS authentication during remote execution.
Initially, I added AWS credentials as Terraform variables inside the workspace. The Terraform plan worked partially, but Terraform displayed warnings because those values were being treated as undeclared input variables.
I corrected the issue by removing the credentials from the Terraform Variables section and recreating them under Workspace Environment Variables.
Output from HPC Terraform
I also validated the resources from AWS using AWS CLI commands.
aws ec2 describe-vpcs \
--filters "Name=tag:Name,Values=day26-tf-cloud-vpc" \
--region us-east-1 \
--query "Vpcs[*].[VpcId,CidrBlock,State]" \
--output table
Local State vs Terraform Cloud Remote State
Local state is useful when learning Terraform, but it has limitations.
With local state, the state file is stored on the engineer’s machine. That can create problems when multiple people work on the same infrastructure.
Terraform Cloud improves this by storing state remotely and managing runs through a workspace.
| Area | Local State | Terraform Cloud |
|---|---|---|
| State location | Local machine | Remote workspace |
| Collaboration | Difficult | Better |
| State locking | Manual or backend dependent | Built in |
| Run history | Not centralized | Available |
| Access control | Limited | Managed through workspace |
| Variables | Stored locally or in files | Managed centrally |
| Team workflow | Harder | Cleaner |
Remote State
One of the most important parts of this exercise was remote state.
Terraform state is critical because it maps Terraform configuration to real cloud resources. If state is lost or overwritten, infrastructure management becomes risky.
Terraform Cloud keeps state inside the workspace and tracks state versions.
[Insert Screenshot: Terraform Cloud state version]
This gives better control and visibility.
Benefits of Terraform Cloud
The main benefits I observed are:
Centralized state management
Workspace based isolation
Remote execution
Run history
Variable management
Better collaboration
Cleaner audit trail
For personal projects, Terraform Cloud helps me understand how teams manage Terraform in a more controlled way.
For enterprise teams, it becomes more valuable because infrastructure changes need visibility, approvals, and consistency.
Key Learnings
Terraform Cloud is not only a remote backend. It also provides a workflow layer for Terraform.
Workspaces are useful for separating environments and managing state independently.
Remote execution helps reduce dependency on one engineer’s laptop.
State history gives better visibility into infrastructure changes.
For team based infrastructure management, Terraform Cloud provides a cleaner operating model than local state.
Cleanup
After testing, I destroyed the resources using:
terraform destroy
This removed the AWS resources created for the project.
Final Thoughts
Day 26 helped me understand how Terraform Cloud fits into real infrastructure workflows.
For small local projects, local state may be enough. For team based work, Terraform Cloud provides better state management, run visibility, and collaboration.
This was a useful step in understanding how Terraform can be operated beyond a single developer machine.
Comments
Post a Comment