SW BBANG J

新しい開発者が入社するたびに、IAM ユーザーを作成してポリシーを一枚一枚アタッチしていた運用が、ある日突然破綻する。10人のユーザーに同じポリシーを直接アタッチしていた環境で権限変更が必要になったとき、10回の手作業が発生する。IAM グループはこの問題を構造的に解決するための仕組みだ。 TL;DR：IAM グループ vs. ユーザーへの直接アタッチ 観点 ユーザーへの直接アタッチ IAM グループ経由 権限変更のコスト 対象ユーザー数分の操作が必要 グループポリシーを1回変更するだけ 新規ユーザーへの権限付与 毎回ポリシーを手動アタッチ グループに追加するだけ 権限の一貫性 ユーザーごとにズレが生じやすい グループ単位で統一される 監査・レビューのしやすさ ユーザーごとに確認が必要 グループのポリシーを見れば全体像が分かる IAM ポリシー上限への影響 ユーザーあたりのアタッチ上限を消費 グループ側で集約できる IAM グループの仕組みを理解する IAM グループはユーザーの集合体であり、それ自体がプリンシパルとして AWS リソースにアクセスするわけではない。グループにアタッチされたポリシーは、そのグループに所属するすべての IAM ユーザーに対して有効になる。ユーザーが複数のグループに所属している場合、各グループのポリシーはすべて評価される。 重要な点として、IAM グループは IAM ロールとは異なり、フェデレーションユーザーや AWS サービスに対してアタッチすることはできない。また、グループをネストする（グループの中にグループを入れる）ことも IAM ではサポートされていない。 graph TD GroupDev["IAM グループ: Developers"] GroupOps["IAM グループ: Operators"] PolicyS3["ポリシー: S3ReadOnly"] PolicyEC2["ポリシー: EC2FullAccess"] ...

IAM ポリシーの JSON を初めて読んだとき、 Effect ・ Action ・ Resource ・ Condition の四つの要素が何を制御しているのか、それぞれの境界がどこにあるのかが掴みにくい。本記事では、IAM ポリシーの基本構造を実際の運用経験をもとに解説し、よくある誤解と正しいモデルを整理する。 TL;DR：IAM ポリシー基本構造の早見表 要素 役割 必須 典型的な値の例 Effect 許可か拒否かを決定する ✅ Allow / Deny Action 対象の API アクションを指定する ✅ s3:GetObject Resource アクションを適用するリソースを限定する ✅ arn:aws:s3:::my-bucket/* Condition 追加の条件が満たされた場合のみ Statement を有効化する ❌ aws:SourceIp など IAM ポリシーの仕組み：評価モデルを理解する IAM ポリシーは、AWS がリクエストを受け取ったときに評価される一連のルールセットだ。ポリシーは一つ以上の Statement で構成され、各 Statement が「誰が・何を・どのリソースに・どんな条件で・許可または拒否するか」を定義する。AWS はリクエストを評価する際、すべての適用可能なポリシーを収集し、以下の優先順位で判定する。 graph TD A["リクエスト受信"] --> B{"明示的 Deny （いずれかのポリシー）"} B -- "あり" --> C["拒否 (Explicit Deny)"] B -- "なし" --> D{"明示的 Allow （いずれかのポリシー）"} D -- "あり" --> E["許可"] D -- "なし" --> F["拒否 (Implicit De...

ALBをデプロイしてドメインを向けようとしたとき、多くのエンジニアが最初にCNAMEレコードを設定しようとする。しかし example.com のようなゾーンの頂点（Zone Apex）でCNAMEを設定しようとすると、Route 53のコンソールがそれを拒否する。これはDNS仕様の制約であり、Route 53の Aliasレコード がその解決策として設計されている。 TL;DR — AliasとCNAMEの比較 比較軸 CNAMEレコード Route 53 Aliasレコード ゾーンの頂点（example.com）での使用 ❌ 不可（RFC 1034制約） ✅ 可能 DNSクエリ料金 通常のクエリ料金が発生 Route 53リソースへのクエリは無料 TTL制御 任意に設定可能 Route 53が自動管理（設定不可） ヘルスチェック統合 制限あり ターゲットリソースのヘルスチェックと統合可能 IPアドレスの自動追従 不可（CNAMEが指すホスト名のAレコードに依存） ALBのIPが変わっても自動的に追従 対応ターゲット 任意のホスト名 ALB、CloudFront、S3、API Gatewayなど特定AWSリソース Route 53 AliasレコードとCNAMEレコードの仕組み CNAMEレコードはDNSの標準機能で、あるホスト名を別のホスト名に対応付ける。クライアントがCNAMEを解決するとき、DNSリゾルバーは最終的なAレコード（IPアドレス）に到達するまで複数回のクエリを実行する。この仕組み自体は問題ないが、RFC 1034の規定により、ゾーンの頂点（ネイキッドドメイン）にはCNAMEを設定できない。ゾーンの頂点にはSOAレコードとNSレコードが必ず存在しなければならず、CNAMEは他のレコードと共存できないためだ。 Route 53のAliasレコードはAWSが独自に実装したDNS拡張機能で、外部から見るとAレコード（またはAAAAレコード）として振る舞う。Route 53の権威DNSサーバーがAliasを解決するとき、ターゲットリソース（ALBなど）の現在...