第2章 AWSの基本構成とIAMの基礎
AWSを安全に運用するための土台となる、リージョン・アベイラビリティーゾーンといった基本構成と、IAM（Identity and Access Management）というアクセス管理の仕組みの基礎を整理します。
リージョンとアベイラビリティーゾーン
リージョンは、東京・大阪・バージニア北部のように、世界各地に存在する独立したデータセンター群の単位です。1つのリージョンの中には、物理的に分離された複数の施設であるアベイラビリティーゾーン（AZ）が複数用意されており、1つのAZで障害が起きても他のAZでサービスを継続できるよう設計するのが基本的な考え方です。リソースを作成する際は、まずどのリージョンで作業しているかを意識する習慣をつけておきましょう。
IAMの3要素：ユーザー・グループ・ロール
IAMユーザーは、個人やシステムに対応する、長期的な認証情報（パスワードやアクセスキー）を持つアカウントです。IAMグループは、複数のIAMユーザーをまとめてポリシーを一括適用するための入れ物で、Linuxのグループの考え方と発想が似ています。IAMロールは、長期的な認証情報を持たず、必要なときだけ一時的に権限を借りる仕組みで、EC2インスタンスなどのAWSリソースに割り当てて使うことが多いのが特徴です。
| 要素 | 認証情報の性質 | 主な用途 |
|---|---|---|
| IAMユーザー | 長期的（パスワード・アクセスキー） | 個人やシステムのログイン |
| IAMグループ | 持たない（権限の入れ物） | 複数ユーザーへの一括権限付与 |
| IAMロール | 一時的（都度発行） | EC2などAWSリソースへの権限付与、他アカウントからの権限借用 |
IAMポリシーという「許可のルール」
IAMポリシーは、Effect（許可か拒否か）・Action（どの操作か）・Resource（どのリソースが対象か）などをJSON形式で記述した、アクセス許可のルールです。対象がファイルではなくAWSのAPI操作である点は異なりますが、「必要な操作だけを許可する」という最小権限の原則の考え方は、Linuxで不要な権限を与えないようにする発想と共通しています。
IAMポリシーの実際の形
IAMポリシーは、次のようなJSON形式で記述します。Effectが許可（Allow）か拒否（Deny）か、Actionがどの操作を対象にするか、Resourceがどのリソースを対象にするかを、それぞれ指定するのが基本の形です。
/* EC2の状態確認（Describe系操作）だけを許可するIAMポリシーの例 */
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*"
}
]
}この例では、ec2:Describe*というワイルドカードにより、EC2の状態を確認する系統の操作（インスタンス一覧の取得など）だけが許可され、起動・停止・削除といった変更を伴う操作は許可されません。Linuxのパーミッションが「読み取り・書き込み・実行」という粒度で権限を分けるのに対し、IAMポリシーはAPI操作の種類ごとに、より細かい粒度で権限を分けられるのが特徴です。
タグによるリソースの整理
AWSでは、EC2インスタンスやEBSボリュームなど、多くのリソースに「キーと値」の組み合わせであるタグを付けられます。Nameタグでサーバーの役割を明示したり、Environmentタグで本番・検証を区別したりするのが典型的な使い方です。台数が増えるほど、どのインスタンスが何のためのものか見分けがつきにくくなるため、タグによる整理はLinuxでいうところのホスト名の付け方以上に重要な運用習慣になります。IAMポリシーの条件にタグを使うことで、「Environment=productionのタグが付いたリソースにしか操作を許可しない」といった、きめ細かいアクセス制御を組むことも可能です。
$ aws ec2 create-tags --resources i-0abcd1234efgh5678 --tags Key=Name,Value=web-server-01 Key=Environment,Value=productionIAMロールを使ったアクセスキー管理の省略
EC2インスタンスからAWS CLIやSDKを使ってAWSの他のサービス（S3やCloudWatchなど）を操作したい場合、アクセスキーとシークレットキーを発行してインスタンス内に設定する方法も技術的には可能ですが、キーの漏えいリスクや失効管理の手間から推奨されません。代わりに、インスタンスにIAMロール（正確にはインスタンスプロファイル）を割り当てておくと、第3章で扱うインスタンスメタデータサービス経由で一時的な認証情報が自動的に払い出され、AWS CLIはそれを自動的に使用します。長期的な認証情報をどこにも保存せずに済むこの仕組みは、AWS運用における基本的なセキュリティプラクティスの一つです。
AWS管理ポリシーとカスタマー管理ポリシー
IAMポリシーには、AWSがあらかじめ用意しているAWS管理ポリシー（AmazonS3ReadOnlyAccessのような、よく使う権限セットをまとめたもの）と、利用者が独自に作成するカスタマー管理ポリシーがあります。学習中や検証環境ではAWS管理ポリシーを使うと手早く動作確認ができますが、多くの場合は必要以上に広い権限を含んでいるため、本番運用では「このロールが本当に必要とする操作だけ」を定義したカスタマー管理ポリシーに絞り込んでいくのが望ましいとされます。最小権限の原則を徹底するほど、意図しない操作や誤操作による被害範囲を小さく抑えられます。
Conditionという要素を追加でき、「特定のIPアドレスからのアクセスのみ許可する」「MFAで認証済みの場合のみ許可する」といった、Effect/Action/Resourceだけでは表現できない細かい条件を付けられます。Linuxのsudoersファイルで、特定の端末や時間帯に限定して権限を付与するのに近い発想です。
この章のまとめ
リージョン・アベイラビリティーゾーンというAWSの基本的な地理的構成と、IAMユーザー・グループ・ロールという3つの要素の役割の違い、ルートユーザーを日常利用しないという基本的な心構え、そしてタグによるリソース整理の考え方を押さえました。次章では、実際にEC2インスタンスへ接続する具体的な方法を扱います。