Terraform AWS Provider

The Terraform AWS Provider includes support for the CloudWatch Observability Access Manager (OAM) package. This service allows for unified cross-account monitoring and observability within AWS.

For detailed information on how to use the service itself, refer to the AWS Service User Guide. For technical details regarding the underlying service interfaces, refer to the AWS Service API Guide.

The aws_ami resource allows you to create and manage custom Amazon Machine Images.

Note on alternatives:

• To duplicate an existing AMI (e.g., to another region), use aws_ami_copy instead.
• To share an existing AMI with another AWS account, use aws_ami_launch_permission instead.

# Create an AMI that will start a machine whose root device is backed by
# an EBS volume populated from a snapshot. We assume that such a snapshot
# already exists with the id "snap-xxxxxxxx".
resource "aws_ami" "example" {
  name                = "terraform-example"
  virtualization_type = "hvm"
  root_device_name    = "/dev/xvda"
  imds_support        = "v2.0" # Enforce usage of IMDSv2. You can safely remove this line if your application explicitly doesn't support it.
  ebs_block_device {
    device_name = "/dev/xvda"
    snapshot_id = "snap-xxxxxxxx"
    volume_size = 8
  }
}

The Terraform AWS Provider Makefile uses different types of phony targets to organize tasks:

• Meta Targets (M): Targets that only run other targets to aggregate functionality (e.g., ci, clean, misspell).
• Dependent Targets (D): Targets that run other targets first before executing their own specific functionality (e.g., deps-check, gen-check, semgrep-code-quality).

Note that if a meta or dependent target runs other targets, all underlying targets must complete successfully for the primary target to succeed.

The Terraform AWS Provider uses Changie for managing CHANGELOG fragments. Fragments are stored in a .changes/ directory organized by major version.

Directory Layout:

• .changes/footer.md: Appended to the main CHANGELOG.md after merges.
• .changes/<major_version>/unreleased/: Contains new entries created by Changie.
• .changes/<major_version>/beta/: Change fragments from beta releases on release branches.
• .changes/<major_version>/ga/: Change fragments from GA releases on release branches.
• .changes/<major_version>/<version>.md: Per-version CHANGELOG files (e.g., 6.0.0.md).

The aws_api_gateway_deployment resource manages a snapshot of a REST API configuration. Once a deployment is created, it can be published to callable endpoints using the aws_api_gateway_stage resource.

To ensure that the deployment is recreated whenever the underlying API configuration changes (such as changes to resources, methods, or integrations), you must use the triggers argument. Using triggers is preferred over the depends_on meta-argument because triggers will force a redeployment, whereas depends_on only manages ordering.

Critical Requirement: Always include the lifecycle { create_before_destroy = true } block in your aws_api_gateway_deployment configuration. This prevents errors like BadRequestException: Active stages pointing to this deployment must be moved or deleted during redeployments.

Use the aws_cognito_managed_user_pool_client resource to assume management of a Cognito User Pool Client that is automatically created by another AWS service (e.g., OpenSearch).

Important: This resource does not create or delete the client; it only manages an existing one. For standard use cases where you want to create and manage your own clients, use the aws_cognito_user_pool_client resource instead. This resource is considered advanced and requires careful configuration of name_prefix or name_pattern to identify the existing client.

The aws_pipes_pipe resource allows you to manage an AWS EventBridge Pipes Pipe. EventBridge Pipes connect sources (like SQS) to targets (like other SQS queues or API destinations) with optional enrichment and filtering.

Note: EventBridge was formerly known as CloudWatch Events, but the functionality is identical.