Terraform AWS Provider: 最頻出プロバイダの勘所（Associate向け）

Terraformで最も使われるのがAWS Provider。試験でも実務でも、認証の優先順位やassume_role、aliasでのリージョン分割などは確実に押さえたいポイントです。

本稿はHashiCorp公式ドキュメントの挙動に沿いながら、Associateレベルで頻出の論点を最小限のコードと具体例でまとめます。

AWS Providerの基本構成とバージョン固定

Terraformではrequired_providersでAWS Providerを明示し、プロジェクト単位でバージョンを固定します。メジャーアップグレードは破壊的変更が入る可能性があるため、~>演算子で安全に追従するのが定石です。

regionはprovider引数、環境変数（AWS_REGION / AWS_DEFAULT_REGION）、共有設定ファイル（~/.aws/config）の順で解決されます。明示的にproviderで指定するとブレません。default_tagsはv5系で安定しており、全リソースに共通タグを付ける運用に有効です（リソース側のtagsが同じキーを持つ場合はリソース側が優先）。

• バージョンは~>で固定（例: ~> 5.0）。.terraform.lock.hclもVCSで管理
• regionはprovider引数が最優先。迷ったらproviderで固定
• default_tagsは全体ポリシーのベースとして使い、例外はプロバイダを分けて表現

最小構成（バージョン固定と共通タグ）

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

provider "aws" {
  region = "ap-northeast-1"

  default_tags {
    tags = {
      Project     = "nicheelab"
      Environment = "dev"
    }
  }
}

認証方式と優先順位（試験で落ちやすいポイント）

AWS ProviderはAWS SDKのデフォルトクレデンシャルチェーンに従って資格情報を解決します。複数の方法を同時に設定した場合、明示的なprovider設定が最優先で、その後に環境変数、共有プロファイル、実行環境ロール（EC2/ECS）の順で評価されます。Web Identity（OIDC）環境変数がある場合は環境変数として優先的に使われます。

試験では「どれが使われるか」の優先順位問題が頻出です。特に、providerにprofileを指定していても、CIで環境変数がセットされていると環境変数が優先される点に注意してください。

• 明示的な静的クレデンシャルは最優先だが実務では非推奨
• 環境変数はCI/CDで扱いやすく、優先度も高い
• profileは人手実行やSSOと相性が良い。aws sso login後に有効
• ロールを使う実行環境（EC2/ECS）は最後の砦として自動解決

環境変数とプロファイルの例

# 環境変数で認証（推奨: CI/CD）
# export AWS_ACCESS_KEY_ID=AKIA...
# export AWS_SECRET_ACCESS_KEY=...
# export AWS_REGION=ap-northeast-1
provider "aws" {}

# 共有プロファイルで認証（ローカル/SSO）
provider "aws" {
  profile = "sandbox"
  region  = "ap-northeast-1"
}

複数アカウント/ロールの引き受け（assume_role）

マルチアカウント構成では、ソース資格情報（profileや環境変数）からターゲットアカウントのロールをassume_roleで引き受けるのが定石です。external_idやsession_nameは監査・連携先要件に合わせて設定します。

assume_roleはprovider内のブロックで指定します。チェインが深くなるほどトラブルシュートが難しくなるため、1ホップを基本にし、権限委譲ポリシー（信頼ポリシー）と必要権限の最小化を明確にしておきます。

• source側は長期資格情報かSSO、target側は最小権限のロール
• external_idの取り扱いはセキュリティ要件に準拠
• セッションは必要最小のdurationで運用

assume_roleの典型フロー（クロスアカウント）

providerでのassume_role設定

provider "aws" {
  profile = "platform"   # source資格情報（共有プロファイル）
  region  = "ap-northeast-1"

  assume_role {
    role_arn     = "arn:aws:iam::222222222222:role/TerraformRole"
    session_name = "tf-apply"
    external_id  = "nicheelab-ci"
    duration     = "3600s"
  }
}

# 以降のリソースは上記ロール経由で作成される

複数プロバイダとエイリアス、リージョンを分ける

AWSは多くのサービスがリージョン単位です。Terraformではproviderにaliasを付け、リージョンやアカウントごとに明示的に分けると計画の可読性と安全性が上がります。リソースごとにproviderを指定して誤作成を防ぎます。

IAMやRoute53（一部）はグローバル扱いで、リージョン指定の影響を受けにくいリソースもあります。計画と適用の差分に惑わされないよう、ドキュメントで対象リージョン/パーティションを確認しておきましょう。

• aliasはリージョン/アカウントの切り替えスイッチ
• resource側のprovider参照で誤リージョン作成を回避
• 同一Stateに複数アカウントを混在させない設計が安全

リージョン別のalias利用例

provider "aws" {
  alias   = "tokyo"
  region  = "ap-northeast-1"
  profile = "prod"
}

provider "aws" {
  alias   = "virginia"
  region  = "us-east-1"
  profile = "prod"
}

resource "aws_s3_bucket" "logs_tokyo" {
  provider = aws.tokyo
  bucket   = "nicheelab-logs-apne1"
}

resource "aws_s3_bucket" "logs_virginia" {
  provider = aws.virginia
  bucket   = "nicheelab-logs-use1"
}

よく使うAWSデータソースとポリシー生成

aws_caller_identityやaws_partitionはアカウントIDやパーティション（aws / aws-cn / aws-us-gov）を動的に取得でき、環境差を埋めるのに有効です。EKSやS3のARNを環境非依存に記述できます。

aws_iam_policy_documentはローカルでJSONポリシーを組み立てるためのデータソースで、API呼び出しを伴いません。差分が明確になり、手書きJSONのミスを防げます。

• data.aws_caller_identity.current.account_idでアカウントを参照
• data.aws_partition.current.partitionでARNのパーティション差異を吸収
• aws_iam_policy_documentでポリシーJSONを安全に生成

データソースでIAMポリシーを生成

data "aws_caller_identity" "current" {}

data "aws_partition" "current" {}

data "aws_iam_policy_document" "s3_readonly" {
  statement {
    actions   = ["s3:GetObject", "s3:ListBucket"]
    resources = [
      "arn:${data.aws_partition.current.partition}:s3:::nicheelab-data",
      "arn:${data.aws_partition.current.partition}:s3:::nicheelab-data/*"
    ]
  }
}

resource "aws_iam_policy" "s3_readonly" {
  name   = "S3ReadOnly"
  policy = data.aws_iam_policy_document.s3_readonly.json
}

実務と試験で効くベストプラクティス

資格情報はコードに書かず、環境変数や共有プロファイル、assume_roleで扱います。Stateはアカウント/リージョンの境界で分離し、aliasで明示的に切り替えます。

依存の再現性を高めるため、Providerのバージョン固定と.terraform.lock.hclの管理は必須です。アップグレードは計画的に行い、破壊的変更ノートを確認してからterraform init -upgradeを実行しましょう。

• 資格情報はenv/profile/SSO＋assume_role。静的キー直書きは回避
• Stateは境界ごとに分ける。workspaceは境界分離の代替ではない
• default_tagsで共通タグ、例外はプロバイダ分割で表現
• ProviderのバージョンとlockファイルをVCSで管理

プロバイダのバージョン固定とロック運用

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

# 初回: terraform init
# アップグレード時: terraform init -upgrade
# .terraform.lock.hcl はVCSで管理する

問題で確認

よくある質問