01. プロバイダと認証
AWS を Terraform で扱う最初の一歩は プロバイダ宣言 と 認証。ここを正しく設定すれば、以降の章のリソース定義はすべて動きます。
この章の目次
最小構成
terraform {
required_version = ">= 1.6"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.80"
}
}
}
provider "aws" {
region = "ap-northeast-1"
}
# ここから resource を書ける
resource "aws_s3_bucket" "example" {
bucket = "my-tf-test-bucket-20260510"
}
terraform / required_providers
terraform ブロックは「Terraform 自身に対する設定」です。CLI のバージョン縛り(required_version)と、使う provider の名前・バージョン縛り(required_providers)を書きます。
terraform {
required_version = ">= 1.6" # CLI バージョンの下限
required_providers {
aws = {
source = "hashicorp/aws" # Terraform Registry 上のパス
version = "~> 5.80" # 5.80.x 系(5.81 以上はダメ)
}
random = {
source = "hashicorp/random"
version = "~> 3.6"
}
}
}
バージョン制約の書き方
| 表記 | 意味 |
|---|---|
5.80.0 | このバージョン丁度 |
>= 5.0 | 5.0 以上 |
~> 5.80 | 5.80 以上、6.0 未満 |
~> 5.80.0 | 5.80.0 以上、5.81.0 未満 |
初学者は ~> 5.80 のような「マイナーバージョン固定」が無難。terraform init で .terraform.lock.hcl も自動生成され、こちらで完全固定されます(チームでバージョンを揃えるためにコミットする)。
provider "aws" の引数
provider "aws" {
region = "ap-northeast-1"
profile = "default"
# 全リソースに自動で付くタグ
default_tags {
tags = {
Project = "hcl-guide"
ManagedBy = "Terraform"
}
}
# 別アカウントへの assume_role
assume_role {
role_arn = "arn:aws:iam::222222222222:role/cross-account-deploy"
session_name = "tf-deploy"
}
}
| 引数 | 役割 |
|---|---|
region | 必須。デフォルトリージョン |
profile | ~/.aws/credentials のプロファイル名 |
shared_credentials_files | credentials ファイルのパス(複数可) |
assume_role | 別アカウント/ロールに切り替えて操作 |
default_tags | このプロバイダで作る全リソースに付くタグ |
endpoints | テスト用に LocalStack 等を指す時 |
認証方法(4 通り)
Terraform の AWS provider は、AWS SDK と同じ 認証情報の検索順 に従います。上から順に探して、見つかったら止まります。
- 静的引数:
providerブロックに直接書く(推奨しない。コミットされやすい) - 環境変数:
AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY,AWS_SESSION_TOKEN - 共有認証ファイル:
~/.aws/credentials+~/.aws/config(プロファイル指定) - EC2 / ECS / Lambda のインスタンスメタデータ: AWS で動かす CI ランナーや踏み台で自動取得
ローカル開発で使う形(推奨)
# SSO を使う(一番安全)
aws configure sso --profile myprofile
aws sso login --profile myprofile
# Terraform 側
export AWS_PROFILE=myprofile
terraform plan
CI(GitHub Actions)で使う形(推奨)
OIDC でロール assume → 一時クレデンシャルを環境変数に流す。GitHub 章 06 参照。
アクセスキーをコードに書かない
provider "aws" { access_key = "AKIA..." } は禁止。.tfvars に書くのもダメ。1 度コミットしたら無効化するしかありません。
マルチリージョンと alias
1 つのスタックで複数リージョンを扱う時、provider をエイリアスで複数定義します。
provider "aws" {
region = "ap-northeast-1" # デフォルト
}
provider "aws" {
alias = "us_east_1"
region = "us-east-1"
}
# 普通のリソースはデフォルト provider
resource "aws_s3_bucket" "logs" {
bucket = "my-logs"
}
# CloudFront 用 ACM は us-east-1 必須なので alias を指定
resource "aws_acm_certificate" "site" {
provider = aws.us_east_1
domain_name = "hcl-guide.com"
validation_method = "DNS"
}
このサイト自身も同じ構造(CloudFront = AWS のグローバル CDN は ACM 証明書を必ず us-east-1 から取る必要がある)。AWS 章 08 で実践します。
default_tags ─ 全リソースに自動でタグを付ける
AWS で運用していると「どのチームが・どの環境で・なぜこのリソースを作ったか」をタグで識別したくなります。1 つひとつの resource に書くのは大変なので、provider レベルで 共通タグを 1 か所に 書ける機能。
provider "aws" {
region = "ap-northeast-1"
default_tags {
tags = {
Project = "hcl-guide"
Env = "prd"
Owner = "platform-team"
ManagedBy = "Terraform"
CostCenter = "1234"
}
}
}
# このプロバイダで作る全リソースに上のタグが自動で付く
resource "aws_s3_bucket" "site" {
bucket = "hcl-guide-site"
tags = {
Name = "site" # 個別タグもマージされる
}
}
タグ設計の指針
最低限ほしい:
Project / Env / Owner / ManagedBy / CostCenter。ManagedBy=Terraform は 「これは IaC 管理。マネコンで触るな」のサイン として実用的。