【AWS】Terraform × Aurora:AZ指定で​再作成が​走る​理由と​回避策

はじめに

TerraformでAurora DB クラスターを構築する際、Availability Zone（AZ）の指定に関して思わぬ落とし穴に遭遇しました。インスタンスを「AZ-AとAZ-Cだけで構成したい」と思って設定したところ、次回のterraform applyでリソースの再作成が走るという予期せぬ挙動に陥ってしまいました。

この記事では、その原因と回避方法について、実体験をもとに解説します。

背景：Terraformと​Auroraの​AZ仕様

Terraformのaws_rds_clusterリソースには、以下のようなオプションがあります。

resource "aws_rds_cluster" "example" {
  availability_zones = ["ap-northeast-1a", "ap-northeast-1c"]
  # ... その他の設定
} 

availability_zonesパラメータは、DBインスタンス（プライマリやリーダー）を配置するAZを指定するものです。
一方、Auroraのストレージは常に3つのAZに自動分散されます。 2つのAZしか指定しない場合、AWS側がストレージ配置のために、3つ目のAZを自動選択し、それがAurora DB クラスターの属性として記録されるため、Terraformが差分を検出してしまいます。

Terraform公式ドキュメントにも以下の注意書きがあります。

つまり、Terraformが2つのAZしか認識していないのに、AWS側では3つ目のAZが自動追加され、次回のterraform planで差分が検出されてしまいます。

実際に​起きた​こと

• 初回のterraform applyでは問題なくAurora DB クラスターが作成された。
• しかし、次回のterraform planで「AZが変更された」としてリソースの再作成が提案された。
• これはTerraformの状態とAWSの実際の状態にズレが生じたため。

# terraform plan の出力例
~ availability_zones = [              
  - "ap-northeast-1a",
  - "ap-northeast-1c",
  + "ap-northeast-1a", 
  + "ap-northeast-1c",
  + "ap-northeast-1d",
] 

解決方​法

lifecycleブロックでignore_changesを使う

resource "aws_rds_cluster" "example" {
# ... other settings ...
  lifecycle {
    ignore_changes = [ availability_zones ]
  }
}  

Terraformに「AZの変更は無視していいよ」と伝えることで、再作成を防ぐことができます。

ベストプラクティスと​注意点

• AZ指定は必須ではない
  AuroraはAWS側で自動的にAZを選択します。指定しない方が差分問題を回避できます。
• 指定するなら3AZを明示
  例：["ap-northeast-1a", "ap-northeast-1c", "ap-northeast-1d"]
  AWS仕様に合わせることで、TerraformとAWSの状態ズレを防げます。
• ignore_changesは応急処置
  将来的な構成ドリフトを招く可能性があるため、恒久的にはAWS仕様に合わせた定義が望ましい。

まとめ

TerraformでAurora DB クラスターを構築する際、Availability Zoneの指定には注意が必要です。
私自身、「AZ-AとAZ-Cだけで十分だろう」と思って構築した結果、次回のterraform applyでリソースの再作成が走るという予期せぬ事態に直面しました。
この経験から学んだのは、TerraformとAWSの仕様の違いを事前に理解しておくことの重要性です。
特に、Terraformは状態管理に厳密なツールであるため、AWS側の自動挙動が差分として検出されることがあります。
今後は、こうした仕様をしっかり確認しながら設計・構築を進めていきたいと思います。

以上です。

参考：HashiCorp, Inc.／Terraform Registry