はじめに
この記事は、組織内で Terraform を使える人を増やすために、会社の AWS アカウントを使ってハンズオン（実践的な勉強会）を実施したいと考えている方を対象としています。
私たちのチームでは、インフラ構成を Terraform でコード化したことにより、大きなメリットを享受してきました。例えば、あるプロジェクトではインフラコストを6割削減する際に、Terraformによるコード化が大きな役割を果たしました。
これは、インフラ構築の再現性やデプロイ速度の向上、さらには俗に言う「秘伝のタレ」化した手作業による設定からの脱却により、チーム全体の生産性が大きく引き上げられたためです。
しかし、その強力さとは裏腹に、現状では Terraform を扱えるメンバーは限られており、特定の担当者に負荷が集中する「属人化」が課題となっています。この状況を解消し、チーム全体の技術力を底上げするために、HashiCorp が提供する公式チュートリアルを活用したハンズオンを企画しました。
ただ、この公式チュートリアルは個人の学習環境で実施することが想定されています。そのため、組織の AWS アカウントでそのまま実施しようとすると、思わぬ事故に繋がるリスクがあるなど、組織特有の運用上の課題に直面します。
この記事では、私たちが実際に Terraform ハンズオンを運営する中で直面した課題と、それらを解決するための具体的なノウハウを、理由や背景と共にご紹介します。
【最重要】安全を確保するための必須事項
何よりも優先すべきは、誤って本番環境などの重要なリソースに影響を与えないようにすることです。ここでは、安全なハンズオン環境を構築するための必須項目を3つ紹介します。
1. ハンズオン専用の AWS アカウントを用意する
最も確実な方法は、ハンズオン専用のAWSアカウントを、本番環境や開発環境とは別に作成することです。これにより、万が一の操作ミスが起きても、その影響範囲をハンズオン用アカウント内に完全に閉じ込めることができ、強い安全性が担保されます。IAM ポリシーだけで権限を制御する方法もありますが、多くの初心者が同時に操作するハンズオン環境では、意図しない権限の穴が生まれがちです。アカウントレベルでの分離は運用に載せるまでやや大変ですが、そうしたリスクを根本から断ち切るシンプルで強力な対策です。
2. Terraform のコードで操作対象アカウントを制限する
参加者の PC には、他のプロジェクトや個人の AWS プロファイルが設定されている可能性があります。万が一、参加者が誤ったプロファイルを指定してしまっても操作が実行されないよう、Terraform のコード側でも保護をかけることが極めて重要です。
AWS Provider の設定に allowed_account_ids を明記することで、意図しない AWS アカウントへの terraform apply を Terraform 自身がブロックしてくれます。これは、ヒューマンエラーに対する最後の砦として機能します。
allowed_account_ids のドキュメント
provider "aws" {
region = "ap-northeast-1"
profile = "handson-user" # ハンズオン用のプロファイル
# この設定で、指定したアカウントID以外への適用を禁止する
allowed_account_ids = ["123456789012"] # ハンズオン専用のアカウントIDをここに記載
}
3. ハンズオン後のリソース削除を徹底する
ハンズオンで作成したリソースは、必ず最後に terraform destroy で削除してもらうよう徹底しましょう。しかし、参加者が削除を忘れてしまうケースも考えられます。運営者側で、特定のタグが付いたリソースを定期的に棚卸しし、一括で削除するAWS CLIを用いたスクリプトを用意しておくと、消し忘れを防止できてさらに安心です。
現状では、それらの削除スクリプトは ChatGPT などと対話することでかなりうまくいくものを短時間で出すことができます。また、上記のようにアカウントレベルで分離がされていれば、間違って本番環境のものを削除してしまう心配がないので安心です。
【推奨】スムーズな運営のための便利設定
次に、ハンズオンの進行をスムーズにし、参加者の混乱やモチベーション低下を防ぐための工夫を紹介します。
1. リソースの所有者をタグで明記する
複数人が同じアカウントで同じようなハンズオンを回すと、「この EC2 インスタンスは誰が作ったものだっけ？」といった問題が必ず発生します。AWS Providerの default_tags を設定し、作成者やハンズオン名が自動で付与されるようにしましょう。これにより、 AWS コンソール上でのリソースの識別が容易になります。これはハンズオン中のデバッグだけでなく、消し忘れリソースの所有者を特定したりする際にも非常に役立ちます。（CloudTrailで追跡する こともできますが、コンソールで所有者が見えるほうがかなり楽です。）
default_tagsのドキュメント
provider "aws" {
# ... (他の設定) ...
default_tags {
tags = {
Owner = "your-name"
Seminar = "terraform-handson-202407"
}
}
}
2. AWS SSO 利用時の認証エラー対策を案内する
組織環境で AWS を利用している場合、SSO を用いて認証しているケースがあると思いますが、HashiCorp のハンズオンではこれが問題になるケースが多発します。
一部の Terraform ハンズオンでは、普通に aws sso login しても認証が通らない場合があります。これは Terraform が提供しているハンズオンで使われている AWS Provider のバージョンが古く、おおよそ2年前で止まっているものが多いことに起因します。現在のバージョンでは解決している問題がまだ残っているのです。
ほかのハンズオンでも時折このような AWS Provider のバージョンが古いために進行不能になる問題に遭遇しますが、一番発生率が高いものがこの認証関連の問題でした。
これに関しては当時の以下の記事を参考にワークアラウンドを行うことを案内することで対応できます。頭にいれておくとよいでしょう。
基本的にはこの記事にあるように、awsの認証configを手動で書き換えるという対応をすると通ることが多いです。
3. 権限不足で進められない場合のフローを整備する
ハンズオンでは、事前に用意した IAM 権限では足りず、エラーで進行が止まってしまうことが時々あります。参加者のモチベーションを削がないためには、この問題に迅速に対応できる体制が不可欠です。
「Slack の特定チャンネルでメンターにメンションすれば、その場で IAM ポリシーを修正・適用してもらえる」といった、リアルタイムで対応できる体制を整えておきましょう。これにより、参加者は数分で作業を再開でき、学習体験の質を高く保つことができます。
サポートが大変などでリアルタイムに修正できない場合は代替のフロー、たとえば「いったん案内が来るまで別のハンズオンを進めてもらう」などもよいでしょう。
今後の展望
ハンズオンをさらに快適にするためのアイデアとして、ハンズオン用の IAM ポリシーをコード化することも考えられます。
各チュートリアルに必要な最小権限の IAM ポリシーを Terraform で定義し、リポジトリで管理する方法です。これにより、参加者に必要以上の権限を与えずに済み、セキュリティをさらに高めることができます。このアプローチは、ハンズオンの運営自体が「最小権限の原則」や DevSecOps のプラクティスを学ぶ良い機会にもなります。ただし、公式チュートリアルの数が多く、全てを追従・メンテナンスするのは相応の労力がかかるため、まずは主要なものから整備していくのが現実的かもしれません。
私たちはほかの AWS 関連の勉強会でも用いているアカウントを Terraform ハンズオンでも利用しており、参加者はすでにある程度の権限を持っていたのであまり付与する手間がありませんでしたが、ゼロから権限を構築するのはなかなか大変だと思います。最も楽に付与したい場合は、S3, EC2, VPC, RDS のフルアクセスを付与することで大体のハンズオンを通すことができるようになるでしょう。（もちろん、これらの権限はアカウントレベルでリソースが分離されている前提で付与してください。）
また、ハンズオンのコードのほとんどは GitHub のリポジトリで公開されているため、静的解析を実行して必要な権限を見積もることができます。具体的には以下の OSS を用いるとよいでしょう。一方で、この解析では「ハンズオンで新たに書き加えられた Terraform に対応する権限」や「AWS Provider のバージョンが古いことによるエラー（特に、AWS自体の破壊的変更）」は検知できません。最も確実なのはやはり、自分でハンズオンを事前にすべて回すことです。（とても重い作業ですが）
おわりに
この記事では、組織で Terraform ハンズオンを安全かつ円滑に進めるための具体的な方法を紹介しました。少しの事前準備と工夫が、安全性を担保し、参加者にとって価値ある学習体験を生み出します。この記事が、皆さんの組織で Terraform の活用を広める一助となれば幸いです。
Discussion