What is Terraform Cloud

Terraform Cloud (TFC) is a hosted service developed by HashiCorp (acquired by IBM) that provides a collaborative workspace for teams to use Terraform, an open-source Infrastructure as Code (IaC) software tool.

Using TFC enables teams to manage infrastructure provisioning, compliance, and management across various cloud providers, data centers, and services.

Disclaimer
env0 is a Terraform Cloud competitor.
If you want to see how the two measure up, visit here to see what makes env0 a capable Terraform Cloud alternative.

Importance of Infrastructure as Code

Infrastructure as Code (IaC) is the process of managing and provisioning IT infrastructure through machine-readable definition files, rather than manual processes or interactive configuration tools.

IaC allows teams to build, change, and manage infrastructure in a safe, consistent, and repeatable way. Automating infrastructure provisioning using IaC tools like Terraform Cloud improves productivity, reduces risk, and increases business velocity.

3 Terraform Cloud Benefits

1. Collaboration and Access Control

Infrastructure automation will almost always require teams to collaborate. Terraform Cloud enables teams to work together with role-based access controls and policy enforcement.

2. Remote State Management

Terraform Cloud provides remote state management, which securely stores and manages the state of your infrastructure, enabling collaboration and preventing conflicts. The Terraform state files are encrypted at rest and you can enable certain teams and individuals to read these state files. Terraform state files may contain sensitive information and therefore need to be properly secured.

3. Version Control Integration

You can integrate with version control systems, allowing teams to manage infrastructure code alongside application code and track changes over time. Your version control system becomes your source of truth.

Scalability and Multi-Cloud Infrastructure Provisioning

Terraform Cloud supports multi-cloud provisioning, allowing you to manage infrastructure across various cloud providers, including AWS, Azure, and Google Cloud Platform.

Video Walk-through

Requirements: A GitHub account and free Terraform Cloud account

TL;DR: You can find the main repo for here.

PS. We will also make use of another repo for our Terraform module code.

Key Features of Terraform Cloud

Workspaces and Projects

Terraform Cloud organizes infrastructure into workspaces and projects, providing a consistent environment for managing infrastructure resources.

A Terraform workspace is a logical environment where you can organize and manage your infrastructure configurations and state.

Workspaces serve as isolated containers that hold the configuration files and state files for a specific project, application, or environment. They provide a way to separate and manage different sets of infrastructure resources and configurations within a single Terraform Cloud organization.

Each workspace has its own distinct state, variables, and settings. This isolation allows teams to work concurrently on different infrastructure projects without interference or conflicts. Workspaces also enable version control and collaboration features, facilitating collaboration and code review workflows.

You can then group a number of Terraform workspaces under one Terraform project.

Role-Based Access Control

Terraform Cloud offers role-based access control, allowing you to define and manage user permissions and access to infrastructure resources.

Single Sign-On (SSO)

Single Sign-On (SSO) for Terraform Cloud is a powerful authentication feature that allows your users to access Terraform Cloud using their existing enterprise identity provider credentials.

By integrating Terraform Cloud with an identity provider such as Okta, Azure Active Directory, or Google Workspace, organizations can streamline user management and enhance security.

With SSO, users no longer need to maintain separate credentials for Terraform Cloud, simplifying the authentication process and improving user experience.

Additionally, SSO enables centralized user access control and permissions management, making it easier to enforce consistent security policies across the organization. This is a feature that your security team will likely ask you to have when selecting a vendor.

Policy Enforcement and Governance (Sentinel and OPA)

Terraform Cloud supports policy enforcement and governance through Sentinel and Open Policy Agent (OPA), enabling you to establish guardrails for security, compliance, and cost management.

Secure Variable Storage

Terraform Cloud provides secure variable storage, allowing you to store sensitive data like API keys and passwords securely. The variables are encrypted at rest and are write-only.

Integration with CI/CD pipelines

Terraform Cloud integrates with continuous integration and continuous deployment (CI/CD) pipelines, streamlining the infrastructure provisioning process.

Self-Hosted Agents

Terraform Cloud offers self-hosted agents, which allow you to run Terraform operations within your own infrastructure for enhanced security and control. Say you want to automate infrastructure that lives in VMware on-premises. Instead of opening your corporation's firewall inbound to allow Terraform Cloud to provision infrastructure in vSphere, you would use self-hosted agents that run in vSphere. These agents require port 443 to be opened outbound on your firewalls. This is a more secure solution and one that your security team will have a much better chance of approving.

Drift Detection

The drift detection feature in Terraform Cloud is designed to identify and manage configuration drift in your infrastructure deployments. Configuration drift refers to any changes made to your infrastructure resources that are not managed by Terraform. By periodically scanning and comparing the desired state defined in your Terraform configuration with the actual state of your deployed resources, drift detection helps you identify inconsistencies.

When a drift is detected, Terraform Cloud notifies you and provides a detailed report highlighting the specific resources and attributes that have deviated from the desired state. This feature enables you to quickly identify and address any unauthorized or unintended changes, ensuring the integrity and consistency of your infrastructure over time.

By leveraging drift detection, you can maintain better control and visibility of your infrastructure deployments, helping to prevent configuration drift and its potential impact on your applications and services.

Private Registry

The Terraform Cloud private registry is a feature available to organizations using Terraform Cloud that allows them to share Terraform providers and Terraform modules internally within their organization. It functions similarly to the public Terraform Registry, offering support for versioning and a searchable list of available providers and reusable Terraform modules.

The private registry uses the organization's configured Version Control System (VCS) integrations and defers to the VCS provider for most management tasks, such as releasing new versions.

Private modules and providers are only accessible to members of the organization where they are added, ensuring that sensitive infrastructure code remains secure and accessible only to authorized users.

By utilizing the Terraform Cloud private registry, organizations can streamline their infrastructure management processes and promote collaboration while maintaining control over their infrastructure code.

Understanding TFC Pricing Plans

As of the writing of this post, this is the current Terraform Cloud and Terraform Enterprise pricing plans:

Free and Paid Plans

Terraform Cloud offers a free tier for small teams and paid plans for larger teams with additional collaboration and governance features. The Free and Standard plans are based on the number of managed resources.

A "Managed Resource" refers to a resource within a Terraform Cloud managed state file that meets the following conditions: it is recorded in the state file starting from the initial execution of a [.code]terraform plan[.code] or [.code]terraform apply[.code] command. This definition excludes [.code]Null Resources[.code] and [.code]terraform_data[.code] from being considered Managed Resources.

Differences between Terraform Cloud, Terraform Enterprise, and Terraform OSS

The difference between Terraform Cloud and Terraform Enterprise is that Terraform Enterprise is self-managed, whereas Terraform Cloud is a SaaS offering by HashiCorp. Some organizations may require a Self-managed platform such as Terraform Enterprise for security and compliance purposes. Terraform OSS is the open-source version of Terraform.

Comparison of features and pricing

HashiCorp has recently changed the pricing model for Terraform Cloud. The entry-level tiers used to be based on the number of users. Now HashiCorp is moving more towards consumption-based pricing for all its tiers. For a detailed comparison of features and pricing, refer to the official Terraform pricing page.

Terraform Cloud and Enterprise Support Options

Terraform Cloud and Enterprise offer various support options, including community and premium support. Below is a table taken from their support site for their Enterprise support plans:

Examples: Getting started with Terraform Cloud

To get started with Terraform Cloud, follow the "What is Terraform Cloud - Intro and Sign Up" tutorial provided by HashiCorp

Cloud Infrastructure to Build

Now let's build an EKS cluster in AWS with Terraform. We will make use of an existing terraform module called terraform-aws-modules/eks/aws.

This is a public terraform module. We will create a simplified private terraform module that makes use of this public module.

Some organizations do this to have more control over which modules are allowed to be used in their organization. They can enforce governance and compliance using Sentinel or OPA on what modules to be used.

Repo Structure

Below is our root module directory:

.
├── LICENSE
├── README.md
├── main.tf
├── outputs.tf
└── variables.tf

The [.code]main.tf[.code] file calls our terraform module stored in the Terraform private module in Terraform cloud. To see the module code, take a look at this GitHub repo mentioned at the top of this post.

main.tf

module "eks" {
  source  = "app.terraform.io/TeKanAid/eks/aws"
  version = "0.0.5"

  region = "us-east-1"
  cluster_version      = "1.27"
  cluster_name         = "env0_eks_cluster"
  instance_types       = ["t2.small"]
  vpc_cidr             = "10.0.0.0/16"
  cluster_min_size     = 1
  cluster_max_size     = 3
  cluster_desired_size = 2
}

variables.tf

Here are our variables in the [.code]variables.tf[.code] file:

variable "region" {
  description = "AWS region"
  type        = string
  default     = "us-east-1"
}

variable "cluster_version" {
  description = "Kubernetes cluster version"
  type        = string
  default     = "1.27"
}

variable "cluster_name" {
  description = "EKS cluster name"
  type        = string
  default     = "env0_eks_cluster"
}

variable "instance_types" {
  description = "EC2 instances used for K8s nodes"
  type        = list
  default     = ["t2.small"]
}

variable "vpc_cidr" {
  description = "The CIDR block for the VPC"
  type        = string
  default     = "10.0.0.0/16"
}

variable "cluster_min_size" {
  description = "K8s Cluster minimum size"
  type        = number
  default     = 1
}

variable "cluster_max_size" {
  description = "K8s Cluster maximum size"
  type        = number
  default     = 3
}

variable "cluster_desired_size" {
  description = "K8s Cluster desired size"
  type        = number
  default     = 2
}

outputs.tf

You can check our root module outputs in the [.code]outputs.tf[.code] file below:

output "cluster_endpoint" {
  description = "Endpoint for EKS control plane"
  value       = module.eks.cluster_endpoint
}

output "cluster_security_group_id" {
  description = "Security group ids attached to the cluster control plane"
  value       = module.eks.cluster_security_group_id
}

output "region" {
  description = "AWS region"
  value       = var.region
}

output "cluster_name" {
  description = "Kubernetes Cluster Name"
  value       = module.eks.cluster_name
}

Cloud Resources Provisioned

Below is a list of the cloud resources that will get provisioned:

  • A VPC
  • 3 private subnets
  • 3 public subnets
  • An Internet Gateway
  • A NAT Gateway
  • An EIP
  • Public and private routes and routing tables
  • EKS cluster
  • EKS cluster encryption
  • EKS Node Group
  • A KMS Key
  • EBS CSI EKS Add-on
  • Cloudwatch Log Group
  • OIDC provider
  • Some security groups
  • Some IAM roles and policies

Publishing a Module to the Private Registry

We first need to publish our module to the registry. As shown in the screenshot below, click on the publish button in the Private Registry:

Then select a repository of the format: [.code]terraform-<PROVIDER>-<NAME>[.code]

And finally, click the button to publish the module:

Notice the ability to have multiple versions of the module code:

To use the module, you can just use this snippet shown in the UI:

module "eks" {
  source  = "app.terraform.io/TeKanAid/eks/aws"
  version = "0.0.7"
}

Creating a Project and a Workspace

Now that we have our module uploaded to the private module registry, we can go ahead and create a project and a workspace:

When you create a new workspace, you can choose one of 3 workflows:

  • Version Control Workflow (Store your Terraform configuration in a git repository, and trigger runs based on pull requests and merges)
  • CLI-Driven Workflow (Trigger remote Terraform runs from your local command line)
  • API-Driven Workflow (A more advanced option. Integrate Terraform into a larger pipeline using the Terraform API)

Go ahead and choose the version control workflow:

Then choose your repo from your Version Control System:

Finally, create the workspace:

Add Variables

In your workspace, you can add variables. These variables could be either Terraform variables or environment variables.

In our case, we will add our AWS credentials as environment variables. You could add these variables per workspace or globally via a variable set. I chose to use a variable set so I could easily reuse these across workspaces.

This might not be ideal in your case.

Terraform in Action

Now that everything is in place, we can trigger our first run from the UI.

Here is our plan:

and here is the output after our [.code]terraform apply[.code] succeeded:

Now run the following command to update your [.code]kubeconfig[.code] and access the new EKS cluster:

aws eks --region  update-kubeconfig \
    --name 

You can now interact with the EKS cluster using [.code]kubectl[.code].

$ kubectl get nodes
NAME                         STATUS   ROLES    AGE   VERSION
ip-10-0-1-198.ec2.internal   Ready       16h   v1.27.1-eks-2f008fe
ip-10-0-2-230.ec2.internal   Ready       16h   v1.27.1-eks-2f008fe
$ kubectl get namespaces
NAME              STATUS   AGE
default           Active   16h
kube-node-lease   Active   16h
kube-public       Active   16h
kube-system       Active   16h

Note: This version control workflow is close to a GitOps model. Whenever you make changes in Git, Terraform cloud will sense that and run a plan.

env0, a cost-effective Terraform Cloud alternative

env0 is a cost-effective alternative to Terraform Cloud that offers a powerful platform for managing Infrastructure as Code (IaC) environments, enforcing governance and policy, optimizing costs, automating deployment workflows, and supporting multi-cloud infrastructure.

The platform provides enhanced collaboration, granular workflows and configurations, and advanced cloud cost measurement. Moreover, env0 supports not only Terraform but also other IaC frameworks such as Terragrunt, CloudFormation, Pulumi, Kubernetes, and Helm.

One of the major benefits of using env0 over Terraform Cloud is its support for self-service and unlimited concurrency, allowing teams to work simultaneously without any bottlenecks.

env0 also offers custom-defined policies and guardrails, ensuring that your infrastructure remains secure and compliant. Instead of relying on webhooks in Terraform Cloud, env0 allows you to integrate any tools you need into its flexible custom flows, using the tooling of your choice.

Check out env0's pricing page where you'll find it an attractive option for organizations looking for a more cost-effective solution to manage their IaC environments.

What is Terraform Cloud

Terraform Cloud (TFC) is a hosted service developed by HashiCorp (acquired by IBM) that provides a collaborative workspace for teams to use Terraform, an open-source Infrastructure as Code (IaC) software tool.

Using TFC enables teams to manage infrastructure provisioning, compliance, and management across various cloud providers, data centers, and services.

Disclaimer
env0 is a Terraform Cloud competitor.
If you want to see how the two measure up, visit here to see what makes env0 a capable Terraform Cloud alternative.

Importance of Infrastructure as Code

Infrastructure as Code (IaC) is the process of managing and provisioning IT infrastructure through machine-readable definition files, rather than manual processes or interactive configuration tools.

IaC allows teams to build, change, and manage infrastructure in a safe, consistent, and repeatable way. Automating infrastructure provisioning using IaC tools like Terraform Cloud improves productivity, reduces risk, and increases business velocity.

3 Terraform Cloud Benefits

1. Collaboration and Access Control

Infrastructure automation will almost always require teams to collaborate. Terraform Cloud enables teams to work together with role-based access controls and policy enforcement.

2. Remote State Management

Terraform Cloud provides remote state management, which securely stores and manages the state of your infrastructure, enabling collaboration and preventing conflicts. The Terraform state files are encrypted at rest and you can enable certain teams and individuals to read these state files. Terraform state files may contain sensitive information and therefore need to be properly secured.

3. Version Control Integration

You can integrate with version control systems, allowing teams to manage infrastructure code alongside application code and track changes over time. Your version control system becomes your source of truth.

Scalability and Multi-Cloud Infrastructure Provisioning

Terraform Cloud supports multi-cloud provisioning, allowing you to manage infrastructure across various cloud providers, including AWS, Azure, and Google Cloud Platform.

Video Walk-through

Requirements: A GitHub account and free Terraform Cloud account

TL;DR: You can find the main repo for here.

PS. We will also make use of another repo for our Terraform module code.

Key Features of Terraform Cloud

Workspaces and Projects

Terraform Cloud organizes infrastructure into workspaces and projects, providing a consistent environment for managing infrastructure resources.

A Terraform workspace is a logical environment where you can organize and manage your infrastructure configurations and state.

Workspaces serve as isolated containers that hold the configuration files and state files for a specific project, application, or environment. They provide a way to separate and manage different sets of infrastructure resources and configurations within a single Terraform Cloud organization.

Each workspace has its own distinct state, variables, and settings. This isolation allows teams to work concurrently on different infrastructure projects without interference or conflicts. Workspaces also enable version control and collaboration features, facilitating collaboration and code review workflows.

You can then group a number of Terraform workspaces under one Terraform project.

Role-Based Access Control

Terraform Cloud offers role-based access control, allowing you to define and manage user permissions and access to infrastructure resources.

Single Sign-On (SSO)

Single Sign-On (SSO) for Terraform Cloud is a powerful authentication feature that allows your users to access Terraform Cloud using their existing enterprise identity provider credentials.

By integrating Terraform Cloud with an identity provider such as Okta, Azure Active Directory, or Google Workspace, organizations can streamline user management and enhance security.

With SSO, users no longer need to maintain separate credentials for Terraform Cloud, simplifying the authentication process and improving user experience.

Additionally, SSO enables centralized user access control and permissions management, making it easier to enforce consistent security policies across the organization. This is a feature that your security team will likely ask you to have when selecting a vendor.

Policy Enforcement and Governance (Sentinel and OPA)

Terraform Cloud supports policy enforcement and governance through Sentinel and Open Policy Agent (OPA), enabling you to establish guardrails for security, compliance, and cost management.

Secure Variable Storage

Terraform Cloud provides secure variable storage, allowing you to store sensitive data like API keys and passwords securely. The variables are encrypted at rest and are write-only.

Integration with CI/CD pipelines

Terraform Cloud integrates with continuous integration and continuous deployment (CI/CD) pipelines, streamlining the infrastructure provisioning process.

Self-Hosted Agents

Terraform Cloud offers self-hosted agents, which allow you to run Terraform operations within your own infrastructure for enhanced security and control. Say you want to automate infrastructure that lives in VMware on-premises. Instead of opening your corporation's firewall inbound to allow Terraform Cloud to provision infrastructure in vSphere, you would use self-hosted agents that run in vSphere. These agents require port 443 to be opened outbound on your firewalls. This is a more secure solution and one that your security team will have a much better chance of approving.

Drift Detection

The drift detection feature in Terraform Cloud is designed to identify and manage configuration drift in your infrastructure deployments. Configuration drift refers to any changes made to your infrastructure resources that are not managed by Terraform. By periodically scanning and comparing the desired state defined in your Terraform configuration with the actual state of your deployed resources, drift detection helps you identify inconsistencies.

When a drift is detected, Terraform Cloud notifies you and provides a detailed report highlighting the specific resources and attributes that have deviated from the desired state. This feature enables you to quickly identify and address any unauthorized or unintended changes, ensuring the integrity and consistency of your infrastructure over time.

By leveraging drift detection, you can maintain better control and visibility of your infrastructure deployments, helping to prevent configuration drift and its potential impact on your applications and services.

Private Registry

The Terraform Cloud private registry is a feature available to organizations using Terraform Cloud that allows them to share Terraform providers and Terraform modules internally within their organization. It functions similarly to the public Terraform Registry, offering support for versioning and a searchable list of available providers and reusable Terraform modules.

The private registry uses the organization's configured Version Control System (VCS) integrations and defers to the VCS provider for most management tasks, such as releasing new versions.

Private modules and providers are only accessible to members of the organization where they are added, ensuring that sensitive infrastructure code remains secure and accessible only to authorized users.

By utilizing the Terraform Cloud private registry, organizations can streamline their infrastructure management processes and promote collaboration while maintaining control over their infrastructure code.

Understanding TFC Pricing Plans

As of the writing of this post, this is the current Terraform Cloud and Terraform Enterprise pricing plans:

Free and Paid Plans

Terraform Cloud offers a free tier for small teams and paid plans for larger teams with additional collaboration and governance features. The Free and Standard plans are based on the number of managed resources.

A "Managed Resource" refers to a resource within a Terraform Cloud managed state file that meets the following conditions: it is recorded in the state file starting from the initial execution of a [.code]terraform plan[.code] or [.code]terraform apply[.code] command. This definition excludes [.code]Null Resources[.code] and [.code]terraform_data[.code] from being considered Managed Resources.

Differences between Terraform Cloud, Terraform Enterprise, and Terraform OSS

The difference between Terraform Cloud and Terraform Enterprise is that Terraform Enterprise is self-managed, whereas Terraform Cloud is a SaaS offering by HashiCorp. Some organizations may require a Self-managed platform such as Terraform Enterprise for security and compliance purposes. Terraform OSS is the open-source version of Terraform.

Comparison of features and pricing

HashiCorp has recently changed the pricing model for Terraform Cloud. The entry-level tiers used to be based on the number of users. Now HashiCorp is moving more towards consumption-based pricing for all its tiers. For a detailed comparison of features and pricing, refer to the official Terraform pricing page.

Terraform Cloud and Enterprise Support Options

Terraform Cloud and Enterprise offer various support options, including community and premium support. Below is a table taken from their support site for their Enterprise support plans:

Examples: Getting started with Terraform Cloud

To get started with Terraform Cloud, follow the "What is Terraform Cloud - Intro and Sign Up" tutorial provided by HashiCorp

Cloud Infrastructure to Build

Now let's build an EKS cluster in AWS with Terraform. We will make use of an existing terraform module called terraform-aws-modules/eks/aws.

This is a public terraform module. We will create a simplified private terraform module that makes use of this public module.

Some organizations do this to have more control over which modules are allowed to be used in their organization. They can enforce governance and compliance using Sentinel or OPA on what modules to be used.

Repo Structure

Below is our root module directory:

.
├── LICENSE
├── README.md
├── main.tf
├── outputs.tf
└── variables.tf

The [.code]main.tf[.code] file calls our terraform module stored in the Terraform private module in Terraform cloud. To see the module code, take a look at this GitHub repo mentioned at the top of this post.

main.tf

module "eks" {
  source  = "app.terraform.io/TeKanAid/eks/aws"
  version = "0.0.5"

  region = "us-east-1"
  cluster_version      = "1.27"
  cluster_name         = "env0_eks_cluster"
  instance_types       = ["t2.small"]
  vpc_cidr             = "10.0.0.0/16"
  cluster_min_size     = 1
  cluster_max_size     = 3
  cluster_desired_size = 2
}

variables.tf

Here are our variables in the [.code]variables.tf[.code] file:

variable "region" {
  description = "AWS region"
  type        = string
  default     = "us-east-1"
}

variable "cluster_version" {
  description = "Kubernetes cluster version"
  type        = string
  default     = "1.27"
}

variable "cluster_name" {
  description = "EKS cluster name"
  type        = string
  default     = "env0_eks_cluster"
}

variable "instance_types" {
  description = "EC2 instances used for K8s nodes"
  type        = list
  default     = ["t2.small"]
}

variable "vpc_cidr" {
  description = "The CIDR block for the VPC"
  type        = string
  default     = "10.0.0.0/16"
}

variable "cluster_min_size" {
  description = "K8s Cluster minimum size"
  type        = number
  default     = 1
}

variable "cluster_max_size" {
  description = "K8s Cluster maximum size"
  type        = number
  default     = 3
}

variable "cluster_desired_size" {
  description = "K8s Cluster desired size"
  type        = number
  default     = 2
}

outputs.tf

You can check our root module outputs in the [.code]outputs.tf[.code] file below:

output "cluster_endpoint" {
  description = "Endpoint for EKS control plane"
  value       = module.eks.cluster_endpoint
}

output "cluster_security_group_id" {
  description = "Security group ids attached to the cluster control plane"
  value       = module.eks.cluster_security_group_id
}

output "region" {
  description = "AWS region"
  value       = var.region
}

output "cluster_name" {
  description = "Kubernetes Cluster Name"
  value       = module.eks.cluster_name
}

Cloud Resources Provisioned

Below is a list of the cloud resources that will get provisioned:

  • A VPC
  • 3 private subnets
  • 3 public subnets
  • An Internet Gateway
  • A NAT Gateway
  • An EIP
  • Public and private routes and routing tables
  • EKS cluster
  • EKS cluster encryption
  • EKS Node Group
  • A KMS Key
  • EBS CSI EKS Add-on
  • Cloudwatch Log Group
  • OIDC provider
  • Some security groups
  • Some IAM roles and policies

Publishing a Module to the Private Registry

We first need to publish our module to the registry. As shown in the screenshot below, click on the publish button in the Private Registry:

Then select a repository of the format: [.code]terraform-<PROVIDER>-<NAME>[.code]

And finally, click the button to publish the module:

Notice the ability to have multiple versions of the module code:

To use the module, you can just use this snippet shown in the UI:

module "eks" {
  source  = "app.terraform.io/TeKanAid/eks/aws"
  version = "0.0.7"
}

Creating a Project and a Workspace

Now that we have our module uploaded to the private module registry, we can go ahead and create a project and a workspace:

When you create a new workspace, you can choose one of 3 workflows:

  • Version Control Workflow (Store your Terraform configuration in a git repository, and trigger runs based on pull requests and merges)
  • CLI-Driven Workflow (Trigger remote Terraform runs from your local command line)
  • API-Driven Workflow (A more advanced option. Integrate Terraform into a larger pipeline using the Terraform API)

Go ahead and choose the version control workflow:

Then choose your repo from your Version Control System:

Finally, create the workspace:

Add Variables

In your workspace, you can add variables. These variables could be either Terraform variables or environment variables.

In our case, we will add our AWS credentials as environment variables. You could add these variables per workspace or globally via a variable set. I chose to use a variable set so I could easily reuse these across workspaces.

This might not be ideal in your case.

Terraform in Action

Now that everything is in place, we can trigger our first run from the UI.

Here is our plan:

and here is the output after our [.code]terraform apply[.code] succeeded:

Now run the following command to update your [.code]kubeconfig[.code] and access the new EKS cluster:

aws eks --region  update-kubeconfig \
    --name 

You can now interact with the EKS cluster using [.code]kubectl[.code].

$ kubectl get nodes
NAME                         STATUS   ROLES    AGE   VERSION
ip-10-0-1-198.ec2.internal   Ready       16h   v1.27.1-eks-2f008fe
ip-10-0-2-230.ec2.internal   Ready       16h   v1.27.1-eks-2f008fe
$ kubectl get namespaces
NAME              STATUS   AGE
default           Active   16h
kube-node-lease   Active   16h
kube-public       Active   16h
kube-system       Active   16h

Note: This version control workflow is close to a GitOps model. Whenever you make changes in Git, Terraform cloud will sense that and run a plan.

env0, a cost-effective Terraform Cloud alternative

env0 is a cost-effective alternative to Terraform Cloud that offers a powerful platform for managing Infrastructure as Code (IaC) environments, enforcing governance and policy, optimizing costs, automating deployment workflows, and supporting multi-cloud infrastructure.

The platform provides enhanced collaboration, granular workflows and configurations, and advanced cloud cost measurement. Moreover, env0 supports not only Terraform but also other IaC frameworks such as Terragrunt, CloudFormation, Pulumi, Kubernetes, and Helm.

One of the major benefits of using env0 over Terraform Cloud is its support for self-service and unlimited concurrency, allowing teams to work simultaneously without any bottlenecks.

env0 also offers custom-defined policies and guardrails, ensuring that your infrastructure remains secure and compliant. Instead of relying on webhooks in Terraform Cloud, env0 allows you to integrate any tools you need into its flexible custom flows, using the tooling of your choice.

Check out env0's pricing page where you'll find it an attractive option for organizations looking for a more cost-effective solution to manage their IaC environments.

Logo Podcast
With special guest
John Willis

Schedule a technical demo. See env0 in action.

Footer Illustration