AWS provider 6.x アップグレード — breaking change の診断と安全な移行順序
Terraform の運用で CLI バージョンより気をつけるべきなのが provider のメジャーアップグレードです。結論を先に書くと、provider のメジャーはリソースのスキーマ自体が変わるため、コードを修正していなくても plan に差分が出ることがあり、標準手順は「最新 5.x 経由 → 公式アップグレードガイドとの照合 → no-op または説明可能な差分の確認 → スタックごとの段階適用」です。 CLI アップグレードの一般手順は前の記事で扱ったので、この記事は AWS provider 6.x を題材にメジャー特有のリスクを扱います。変更内容は 2026-08 時点の検証基準で、適用時点で公式ガイドを再確認します。
provider のメジャーが CLI より重い理由 #
CLI のマイナーアップグレードは互換性の約束に守られていますが、provider のメジャーはその反対で、互換を壊すために存在するリリースです。 リソースの引数が削除され、デフォルトが変わり、リソースタイプ自体が消えます。スキーマが変わると、コードとインフラがそのままでも plan に差分が現れ、その一部はリソースの置き換え(destroy 後の再作成)を意味します。DB のような状態を持つリソースが置き換え判定になったら、それは差分ではなく事故の予告です。
だからメジャーアップグレードは「バージョンの数字を変えて plan を 1 回」ではなく、plan 出力を全数で読み解く作業です。読み方の基準は後で整理します。
6.0 の主要変更 — 何が壊れるのか #
公式アップグレードガイド基準で、実務に引っかかりやすい変更はこうです。
| 変更 | 内容 | 引っかかるコード |
|---|---|---|
| リソース単位の region 引数 | 大部分のリソースに region 引数を追加、provider alias なしでマルチリージョン構成が可能 | 既存の alias パターンは維持可能、新規設計の選択肢が拡大 |
| OpsWorks の全面削除 | リソース 17 種を削除 | OpsWorks 使用スタックはアップグレード前に移行が必要 |
| SimpleDB の削除 | aws_simpledb_domain を削除 | 該当リソースの使用コード |
| aws_eip の vpc 引数削除 | domain 引数で代替 | 古い EIP コード |
| ブーリアンの厳格化 | “1”、“0” の文字列をブーリアンと認めない | 初期に書かれたレガシーコード |
| Redshift デフォルトの反転 | publicly_accessible デフォルト false、encrypted デフォルト true | 引数を省略した Redshift コードに差分が発生 |
最も大きい構造変化はリソース単位の region です。これまでマルチリージョンはリージョンごとに provider alias を作ってリソースに付ける方式で(実践 #10 の ACM・CloudFront 構成がそのパターンです)、6.x からはリソースに region を直接指定できます。既存の alias コードはそのまま動くのでアップグレードを妨げませんが、新しく設計するスタックでは alias の数を減らせる選択肢が生まれました。
デフォルト反転の類型は静かなぶん危険です。Redshift のように引数を省略していたコードは、6.x で新しいデフォルトとの差が差分として現れます。これは「コードに意図を明示せよ」という合図として読み、引数を明示的に書いて差分を消すのが定石です。
移行順序 — 5.x 最新経由が標準です #
- 現在の 5.x の最新マイナーへ先に上げます: メジャー直前のバージョンは、次のメジャーで削除される機能に deprecation 警告を出します。この警告を先に消化すれば、6.0 移行でぶつかる破壊の大部分が事前に見つかります。
- アップグレードガイドを自分のコードと照合します: 上の表のような変更リストを自分のリポジトリに
grepで当て、引っかかるリソース・引数を事前に修正します。 - バージョン制約とロックファイルを更新します: required_providers を
~> 6.0に変え、terraform init -upgradeでロックファイルを更新します。この変更は CLI アップグレードと分離した単独の PR にします。 - plan を全数で読み解きます: 合格基準は no-op が理想ですが、メジャーでは「説明可能な差分」までが許容ラインです。スキーマ整理による in-place の変更(~ 表示)はおおむね無害で、forces replacement が付いた項目はすべて原因を解明するまで apply しません。 特にデータ層リソースの置き換え判定は中断の条件です。
- スタックごとに段階適用します: 開発スタックで apply まで完走して実物への影響を確認してから本番に進みます。全スタックが一度に渡る必要はありませんが、新旧バージョンの混在期間は短く切ります。
共有モジュールの下限 — 足を引っ張る側 #
複数のスタックが共有する社内モジュールやレジストリのモジュールがあると、変数がもう 1 つ増えます。モジュールの required_providers が >= 5.0, < 6.0 のように上限を掛けていたら、ルートが 6.x に行きたくてもモジュールが妨げます。逆にモジュールが 6.x 専用の文法(リソースの region など)を使い始めると、5.x に残ったスタックがそのモジュールを使えません。
順序はモジュールが先です。モジュールの provider 制約を 6.x 互換に広げ(可能なら >= 5.x, < 7.0 のように移行期は両対応)、ルートのスタックが順に渡った後、移行が終わったらモジュールの下限を 6.x に上げて締めます。サードパーティのモジュールが 5.x に固定されているなら、そのモジュールのアップストリーム対応の有無がアップグレード日程全体の制約になるため、照合の段階で最初に確認する項目です。
まとめ #
- provider のメジャーはスキーマを壊すリリースです。コードを変えなくても差分が出て、その中に置き換え判定が混ざりうるため、plan の全数読解が必須です。
- 標準手順は 5.x 最新経由です。deprecation 警告を先に消化すれば、6.0 でぶつかる破壊が事前に見つかります。
- 6.0 の核心変更はリソース単位の region、OpsWorks・SimpleDB の削除、ブーリアンの厳格化、Redshift デフォルトの反転です。デフォルト反転は引数の明示で差分を消します。
- 読み方の基準: in-place の変更はおおむね無害、forces replacement は全件解明まで apply 禁止、データ層の置き換え判定は中断の条件です。
- 共有モジュールの provider 制約が日程のボトルネックです。モジュールの互換を先に広げ、ルートを移してから下限を締める順序で進みます。