Terraform Fundamentals: Compute Optimizer

Optimizing Cloud Spend with Terraform and Compute Optimizer

Infrastructure teams face a constant battle: balancing performance needs with cost efficiency. Over-provisioned resources are a common symptom, especially in rapidly scaling environments. Manual rightsizing is tedious, error-prone, and doesn’t scale. Compute Optimizer, when integrated into a Terraform workflow, automates this process, providing recommendations for optimal instance types based on observed utilization. This isn’t a standalone solution; it’s a critical component of a modern IaC pipeline, fitting neatly between provisioning and ongoing management, and is a core element of a platform engineering approach to self-service infrastructure. It’s about shifting from reactive cost management to proactive optimization.

What is "Compute Optimizer" in Terraform Context?

Currently, Compute Optimizer functionality is primarily exposed through cloud provider APIs (AWS, Azure, GCP). There isn’t a dedicated “Terraform Compute Optimizer” provider in the same way there is for AWS or Azure. Instead, integration is achieved through data sources and resources provided by the respective cloud providers. These resources allow you to retrieve recommendations and, crucially, apply those recommendations via Terraform.

For example, on AWS, the aws_compute_optimizer_instance_recommendation data source retrieves recommendations for EC2 instances. The aws_ec2_instance resource then allows you to modify the instance type based on those recommendations. Azure offers similar functionality through azurerm_virtual_machine_scale_set_vm_instance_view and subsequent updates to the azurerm_virtual_machine_scale_set resource. GCP leverages the google_compute_instance resource and the Compute Engine API.

A key caveat is that Compute Optimizer recommendations are not immediate. There’s a delay between data collection and recommendation generation. Terraform’s declarative nature means you’re applying a snapshot of the recommendations at a given time. Therefore, frequent runs (e.g., daily or weekly) are essential to stay current. Lifecycle management is critical; avoid applying recommendations blindly. Always review and validate before applying changes to production.

Use Cases and When to Use

Compute Optimizer isn’t a silver bullet, but it excels in specific scenarios:

1. Dynamic Workloads: Applications with fluctuating demand (e.g., batch processing, CI/CD pipelines) benefit significantly. Compute Optimizer identifies instances that are consistently underutilized during off-peak hours.
2. Dev/Test Environments: These environments are often over-provisioned for convenience. Compute Optimizer can drastically reduce costs by rightsizing instances without impacting developer productivity.
3. Large-Scale Deployments: Managing hundreds or thousands of instances manually is impractical. Compute Optimizer automates the process, providing a scalable solution.
4. Cost Optimization Initiatives: As part of a broader FinOps strategy, Compute Optimizer provides data-driven insights for reducing cloud spend. SREs can use this data to establish baseline costs and track optimization efforts.
5. Platform Engineering Self-Service: Integrate Compute Optimizer into a self-service infrastructure platform. Developers request resources, and the platform automatically rightsizes them based on recommendations, reducing operational overhead.

Key Terraform Resources

Here are essential Terraform resources for integrating Compute Optimizer:

1. aws_compute_optimizer_instance_recommendation (AWS): Retrieves instance recommendations.

   data "aws_compute_optimizer_instance_recommendation" "example" {
     instance_arn = aws_ec2_instance.example.arn
   }

1. azurerm_virtual_machine_scale_set_vm_instance_view (Azure): Provides instance view data for VMSS.

   data "azurerm_virtual_machine_scale_set_vm_instance_view" "example" {
     name                = azurerm_virtual_machine_scale_set.example.name
     resource_group_name = azurerm_resource_group.example.name
   }

1. google_compute_instance (GCP): Used to update instance types.

   resource "google_compute_instance" "example" {
     name         = "example-instance"
     machine_type = data.google_compute_instance.example.machine_type
     # ... other configuration ...

   }

1. aws_ec2_instance (AWS): Used to modify instance types.

   resource "aws_ec2_instance" "example" {
     ami           = "ami-0c55b999999999999"
     instance_type = data.aws_compute_optimizer_instance_recommendation.example.recommended_instance_type
     # ... other configuration ...

   }

1. azurerm_virtual_machine_scale_set (Azure): Used to update VMSS instance types.

   resource "azurerm_virtual_machine_scale_set" "example" {
     name                = "example-vmss"
     location            = "eastus"
     sku                 = data.azurerm_virtual_machine_scale_set_vm_instance_view.example.sku
     # ... other configuration ...

   }

1. data.aws_availability_zones (AWS): Useful for ensuring recommendations are within available zones.

   data "aws_availability_zones" "available" {}

1. aws_iam_policy (AWS): For granting Compute Optimizer access to instance data.

   resource "aws_iam_policy" "compute_optimizer_policy" {
     name        = "ComputeOptimizerPolicy"
     description = "Policy for Compute Optimizer"
     policy      = jsonencode({
       Version = "2012-10-17",
       Statement = [
         {
           Action = [
             "ec2:DescribeInstances",
             "ec2:DescribeInstanceTypes"
           ],
           Resource = "*",
           Effect   = "Allow"
         },
       ]
     })
   }

1. azurerm_role_assignment (Azure): For granting Compute Optimizer access to VM data.

   resource "azurerm_role_assignment" "compute_optimizer_role" {
     scope              = data.azurerm_subscription.current.id
     role_definition_name = "Contributor"
     principal_id        = "YOUR_SERVICE_PRINCIPAL_ID"
   }

Common Patterns & Modules

Using for_each with the aws_compute_optimizer_instance_recommendation data source allows you to process recommendations for multiple instances in a single Terraform run. Dynamic blocks can handle varying recommendation structures.

A monorepo structure is ideal for managing Compute Optimizer integration alongside other infrastructure components. Layered modules (e.g., a core module for Compute Optimizer data retrieval and a higher-level module for applying recommendations) promote reusability. Environment-based modules allow for customization based on specific needs (e.g., different thresholds for cost savings).

While dedicated public modules are limited, searching the Terraform Registry for "compute optimizer" or "instance rightsizing" can yield useful starting points.

Hands-On Tutorial

This example demonstrates retrieving and applying an AWS Compute Optimizer recommendation.

Provider Setup:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

Resource Configuration:

resource "aws_ec2_instance" "example" {
  ami           = "ami-0c55b999999999999"
  instance_type = "t3.medium"
  tags = {
    Name = "ComputeOptimizerExample"
  }
}

data "aws_compute_optimizer_instance_recommendation" "example" {
  instance_arn = aws_ec2_instance.example.arn
}

resource "aws_ec2_instance" "optimized" {
  ami           = aws_ec2_instance.example.ami
  instance_type = data.aws_compute_optimizer_instance_recommendation.example.recommended_instance_type
  tags = {
    Name = "ComputeOptimizerExampleOptimized"
  }

  depends_on = [data.aws_compute_optimizer_instance_recommendation.example]
}

Apply & Destroy Output:

terraform plan will show the proposed instance type change. terraform apply will modify the instance. terraform destroy will remove the optimized instance.

This example is simplified. In a real-world scenario, you’d integrate this into a CI/CD pipeline, potentially using Terraform Cloud for remote execution and state management.

Enterprise Considerations

Large organizations leverage Terraform Cloud/Enterprise for centralized state management, remote execution, and policy enforcement. Sentinel or Open Policy Agent (OPA) can be used to validate Compute Optimizer recommendations before applying them, ensuring compliance with cost and performance standards.

IAM design is crucial. Grant Compute Optimizer the least privilege necessary to access instance data. State locking prevents concurrent modifications. Secure workspaces isolate environments.

Costs are primarily driven by the cloud provider’s Compute Optimizer service itself (if any) and the increased API calls from Terraform. Scaling requires careful consideration of API rate limits. Multi-region deployments necessitate configuring providers for each region and managing recommendations independently.

Security and Compliance

Enforce least privilege using IAM policies (e.g., aws_iam_policy, azurerm_role_assignment). Implement RBAC to control access to Terraform workspaces. Policy-as-Code (e.g., Sentinel, OPA) can enforce constraints on recommended instance types (e.g., prohibiting certain families or sizes).

Drift detection (using terraform plan) identifies unintended changes. Tagging policies ensure consistent metadata. Audit logs provide a record of all changes.

Integration with Other Services

Compute Optimizer doesn’t operate in isolation.

1. CloudWatch/Azure Monitor/Google Cloud Monitoring: Provides the utilization data that Compute Optimizer analyzes.
2. Cost Explorer/Azure Cost Management/Cloud Billing: Used to track cost savings resulting from Compute Optimizer recommendations.
3. Auto Scaling Groups/Virtual Machine Scale Sets: Compute Optimizer can inform scaling policies.
4. Configuration Management (Ansible, Chef, Puppet): Used to configure instances after rightsizing.
5. Alerting (PagerDuty, Slack): Alerts can be triggered when Compute Optimizer identifies significant optimization opportunities.

graph LR
    A[Compute Optimizer] --> B(CloudWatch/Azure Monitor/GCP Monitoring);
    A --> C(Cost Explorer/Azure Cost Management/Cloud Billing);
    A --> D(Auto Scaling Groups/VMSS);
    A --> E(Configuration Management);
    A --> F(Alerting);

Module Design Best Practices

Abstract Compute Optimizer functionality into reusable modules. Input variables should include instance ARNs/IDs, recommendation thresholds, and approval requirements. Output variables should include recommended instance types and cost savings estimates. Use locals to simplify complex logic. Document modules thoroughly with examples and usage instructions. Use a remote backend (e.g., Terraform Cloud, S3) for state storage.

CI/CD Automation

Here’s a GitHub Actions snippet:

jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: hashicorp/setup-terraform@v2
      - run: terraform fmt
      - run: terraform validate
      - run: terraform plan -out=tfplan
      - run: terraform apply tfplan

Integrate this into a pipeline that triggers on a schedule (e.g., daily) or when instance utilization metrics change. Terraform Cloud provides a more robust and scalable solution for remote execution and collaboration.

Pitfalls & Troubleshooting

1. Insufficient Data: Compute Optimizer needs sufficient historical data to generate accurate recommendations.
2. API Rate Limits: Excessive API calls can lead to throttling. Implement retry logic and consider caching.
3. Incorrect IAM Permissions: Compute Optimizer requires appropriate permissions to access instance data.
4. Conflicting Configurations: Manual instance type overrides can conflict with Compute Optimizer recommendations.
5. Delayed Recommendations: Recommendations are not immediate. Frequent runs are necessary.
6. Unsuitable Recommendations: Recommendations may not always be optimal for all workloads. Always review and validate.
7. State Drift: Changes made outside of Terraform can cause state drift, leading to unexpected behavior.

Pros and Cons

Pros:

• Automated rightsizing reduces cloud spend.
• Scalable solution for managing large deployments.
• Data-driven insights improve cost optimization efforts.
• Integrates seamlessly with existing Terraform workflows.

Cons:

• Recommendations are not immediate.
• Requires careful IAM configuration.
• Potential for API rate limiting.
• Recommendations may not always be optimal.

Conclusion

Compute Optimizer, when strategically integrated into a Terraform-based infrastructure, is a powerful tool for optimizing cloud spend and improving resource utilization. It’s not a set-and-forget solution; it requires ongoing monitoring, validation, and refinement. Start with a proof-of-concept, evaluate existing modules, set up a CI/CD pipeline, and embrace a data-driven approach to infrastructure management. The long-term benefits – reduced costs, improved performance, and increased efficiency – are well worth the effort.