Open6

2025/2/25 Infrastructure as Code 談義 ~ これってやりすぎ?やらなすぎ ? ~ AWS Developer Live Show

issyissy

Q1. IaCを書き始めるタイミングは?

  • 判断するタイミングやシチュエーションはいろいろある
  • やらなすぎ
    • アプリ完成後、運用フェーズでIaC化
      • すでに出来上がったものをIaC化は大変、環境を壊してしまうリスクもある
  • ちょうどいい
    • IaCは開発段階から始めるのがいいか
    • 生成AI前提なら初手IaC
    • 同じ構成を作らないならIaCは不要か?
      • 簡単なものならIaCにしないというケースもある。
      • パラメータチェックや、環境レビューにIaCはメリットあるのでセキュリティ面でチェックしたいならIaCはよい
  • やりすぎ
    • 新しいAWSサービス
      • IaC対応が遅いものは、まずはマネジメントコンソールで検証後にIaC化
    • いつでも最初からIaC
      • 最終的にIaC化はマスト。検証など一時的なものなら手作業でもいい。
      • 本番で使う予定であるなら最初からIaC
      • IaCの利用度によっては手元にノウハウがあって、ベースとして使えるなら検証でも使うのはあり。
issyissy

Q2. IaCは運用のどこまでをカバーすべき?

  • やらなすぎ
    • 最初だけIaC、ドリフト当たり前
      • IaCの管理メリットがないので、スタック管理から除外してしまうとか。
  • ちょうどいい
    • DBを入れるかいれないか
      • DBの数などにもよる
      • 限界までIaC
      • 意見いろいろ
    • ライフサイクルが長いものはIaC管理から外す
    • PRでレビューしたらCI/CDで反映されるので楽
  • やりすぎ
    • 手動操作は絶対に許さない
      • ”絶対”は厳しい。緊急時はOKなど
issyissy

Q3. IaCでどのくらいドキュメント書く?

  • やらなすぎ
    • デプロイコマンドだけ
  • ちょうどいい
  • やりすぎ