In the ever-evolving landscape of cloud computing, Terraform has emerged as a pivotal tool for managing cloud infrastructure. Developed by HashiCorp, Terraform enables developers to define and provision data center infrastructure using a high-level configuration language, all in a declarative manner. Of particular interest to users of Amazon Web Services (AWS) are two specific Terraform providers: the AWS provider and the AWS Cloud Control API (AWSCC) provider. Each serves unique purposes and possesses distinct characteristics, raising the question of how they compare and why both exist. This article aims to unravel these differences and explore the benefits of using them together.
Understanding the AWS Provider
The Terraform AWS provider is a cornerstone for integrating AWS services within Terraform configurations. Officially recognized as the first provider for AWS, it has reached a milestone of over three billion downloads by 2024. Built on the AWS Software Development Kit (SDK), the AWS provider encompasses a wide array of resources corresponding to various AWS services. Each resource is meticulously handcrafted in the Go programming language, ensuring robust test coverage and reliability.
For instance, when Terraform is tasked with creating an Amazon S3 bucket, the AWS provider engages the S3 CreateBucket API to accomplish this task. This approach, while effective, presents challenges, particularly in supporting new AWS services as they are launched. The manual effort and prioritization required to incorporate these services into the provider can delay day-one support for new AWS features.
Introducing the AWS Cloud Control API
AWS’s Cloud Control API offers a different approach. This service provides developers with programmatic access to the vast array of AWS features and services, often on the day they are released. By standardizing the Create, Read, Update, Delete, and List (CRUDL) operations, the Cloud Control API simplifies the process of managing AWS services. Developers only need to integrate their solutions with the Cloud Control API once, and they automatically gain access to new AWS resources and features as they become available.
The AWSCC Provider: A New Frontier
The introduction of the AWSCC provider in May 2024 marked a significant advancement in Terraform’s AWS integration capabilities. This provider leverages the consistency and automation of the Cloud Control API to automatically generate new resources based on predefined rules as soon as AWS releases new schemas. Like the AWS provider, the AWSCC provider interacts with AWS APIs, but it exclusively communicates with the Cloud Control API during resource creation.
Each AWSCC resource can perform the full spectrum of CRUDL operations through the Cloud Control API, offering a streamlined approach to infrastructure management. This uniformity reduces the number of interface endpoints needed, particularly in environments with restricted internet access, known as air-gapped environments.
Complementary Strengths: AWS and AWSCC Providers Together
While the AWSCC provider excels in offering immediate support for new AWS services, the AWS provider remains the preferred choice for a comprehensive range of established AWS resources. With over 1,300 resource types across nearly 200 services, the AWS provider provides an unparalleled user experience and performance. By combining the strengths of both providers, developers gain access to a vast catalog of resources, encompassing both well-established and emerging AWS services.
Practical Implementation: Using the AWSCC Provider
Implementing the AWSCC provider in Terraform is straightforward. For example, deploying a Virtual Private Cloud (VPC) using the AWSCC provider involves a configuration that closely resembles the standard AWS provider, albeit with slight variations in naming conventions.
hcl<br /> provider "awscc" {<br /> region = "us-east-1"<br /> }<br /> <br /> resource "awscc_ec2_vpc" "this" {<br /> cidr_block = "10.0.0.0/16"<br /> }<br />
Harnessing Both Providers Together
To illustrate the synergy between the AWS and AWSCC providers, consider a scenario where the AWS provider is used to create a VPC, while the AWSCC provider handles the creation of a subnet within that VPC. This dual-provider approach maximizes flexibility and access to AWS services.
hcl<br /> provider "aws" {<br /> region = "us-east-1"<br /> }<br /> <br /> provider "awscc" {<br /> region = "us-east-1"<br /> }<br /> <br /> resource "awscc_ec2_vpc" "this" {<br /> cidr_block = "10.0.0.0/16"<br /> }<br /> <br /> resource "aws_subnet" "this" {<br /> vpc_id = awscc_ec2_vpc.this.id<br /> cidr_block = "10.0.1.0/24"<br /> }<br />
Migrating Resources Between Providers
Migrating resources between the AWS and AWSCC providers is a valuable technique for optimizing infrastructure management. To move a VPC from the AWSCC provider to the AWS provider, follow these steps:
- Initial Setup: Create a VPC using the AWSCC provider and a subnet using the AWS provider.
hcl<br /> provider "aws" {<br /> region = "us-east-1"<br /> }<br /> <br /> provider "awscc" {<br /> region = "us-east-1"<br /> }<br /> <br /> resource "awscc_ec2_vpc" "this" {<br /> cidr_block = "10.0.0.0/16"<br /> }<br /> <br /> resource "aws_subnet" "this" {<br /> vpc_id = awscc_ec2_vpc.this.id<br /> cidr_block = "10.0.1.0/24"<br /> }<br /> - Migration Process: Replace the existing configuration with the code below, substituting
vpc-exampleIDwith the actual VPC ID.hcl<br /> provider "aws" {<br /> region = "us-east-1"<br /> }<br /> <br /> provider "awscc" {<br /> region = "us-east-1"<br /> }<br /> <br /> import {<br /> to = aws_vpc.this<br /> id = "vpc-exampleID"<br /> }<br /> <br /> removed {<br /> from = awscc_ec2_vpc.this<br /> lifecycle {<br /> destroy = false<br /> }<br /> }<br /> <br /> resource "aws_vpc" "this" {<br /> cidr_block = "10.0.0.0/16"<br /> }<br /> <br /> resource "aws_subnet" "this" {<br /> vpc_id = aws_vpc.this.id<br /> cidr_block = "10.0.1.0/24"<br /> }<br /> - Execution: Run
terraform apply --auto-approveto effect the migration.Migrating from AWS to AWSCC Provider
Conversely, to migrate a subnet from the AWS provider to the AWSCC provider, follow these steps:
- Initial Setup: Create a VPC using the AWSCC provider and a subnet using the AWS provider.
hcl<br /> provider "aws" {<br /> region = "us-east-1"<br /> }<br /> <br /> provider "awscc" {<br /> region = "us-east-1"<br /> }<br /> <br /> resource "awscc_ec2_vpc" "this" {<br /> cidr_block = "10.0.0.0/16"<br /> }<br /> <br /> resource "aws_subnet" "this" {<br /> vpc_id = awscc_ec2_vpc.this.id<br /> cidr_block = "10.0.1.0/24"<br /> }<br /> - Migration Process: Update the configuration as follows, replacing
subnet-exampleIDwith the actual subnet ID.hcl<br /> provider "aws" {<br /> region = "us-east-1"<br /> }<br /> <br /> provider "awscc" {<br /> region = "us-east-1"<br /> }<br /> <br /> import {<br /> to = awscc_ec2_subnet.this<br /> id = "subnet-exampleID"<br /> }<br /> <br /> removed {<br /> from = aws_subnet.this<br /> lifecycle {<br /> destroy = false<br /> }<br /> }<br /> <br /> resource "awscc_ec2_vpc" "this" {<br /> cidr_block = "10.0.0.0/16"<br /> }<br /> <br /> resource "awscc_ec2_subnet" "this" {<br /> vpc_id = awscc_ec2_vpc.this.id<br /> cidr_block = "10.0.1.0/24"<br /> }<br /> - Execution: Execute
terraform apply --auto-approveto finalize the migration.Further Exploration
For those interested in delving deeper into the integration of the AWS and AWSCC providers, the AWS Workshop for managing cloud resources with Terraform offers a wealth of resources. Additionally, the HashiTalk on migrating state between providers provides valuable insights and examples of state migration.
In conclusion, the AWS and AWSCC providers serve distinct yet complementary roles in managing AWS resources with Terraform. By understanding their unique attributes and leveraging their combined strengths, developers can optimize their cloud infrastructure management strategies, ensuring both stability and access to cutting-edge AWS features.
For more Information, Refer to this article.
