クラウドエンジニア面接：権限・ネットワーク・復旧を構成図で説明する
Quick Overview
プライベートサブネットからS3を読む構成で、経路・IAM・endpoint policy・bucket policyを分け、範囲を広げない復旧と対照試験を練習します。
「IAM に Allow があるのに S3 のレポートを読めない」。クラウドエンジニア面接でこの状況を渡されたら、権限を広げる前に、誰が・どの操作を・どの経路から実行しているかを構成図へ書き込みましょう。経路を直したあとに、別の拒否条件が表に出ることもあります。
この記事では、プライベートサブネットのワークロードが S3 のレポートを読み取るケースを、経路、IAM、エンドポイントポリシー、バケットポリシーに分けます。Explain AWS access control and frontend typing の AWS 権限部分と組み合わせ、許可・拒否の根拠を説明する練習に使えます。
公式事実は AWS の文書、観測結果は CPython 3.12.14 で動かした限定的な学習モデル、調査と復旧の提案は編集上の判断です。実際の AWS アカウント、SDK、DNS、TCP、TLS、HTTP、CloudTrail は使用していません。以下の model_status の200・403・nullはすべてモデル内の値で、通信試験やAWSのHTTP応答の記録ではありません。候補者の体験談や企業別の出題頻度も扱いません。
構成図には、送信元だけでなく要求を書き込む
練習のワークロードは report-reader、対象は case-reports バケットの reports/2026-10/summary.json、操作は s3:GetObject です。同一アカウント内の役割を想定し、読み取りの権限はアイデンティティポリシーから与える設計に限定します。バケット側から別途 Allow を与える経路は、モデルに含めません。
構成は、プライベートサブネットのワークロードから、関連付いたルートテーブルを通り、S3 の gateway endpoint E2 に向かう形です。E1 と E2 は説明用の記号で、実際の VPC endpoint ID ではありません。対象リージョンの IPv4 経路を仮定し、NAT を使う代替経路は置いていません。
要求には、主体、操作、リソース、通過するエンドポイントを添えます。「S3 にアクセスする権限」だけでは、バケットを一覧する権限とオブジェクトを読む権限、別 prefix を読む権限、書き込む権限が混ざります。今回は reports/ 配下の読み取りだけが必要です。
実障害なら、対象コンテナーやインスタンスで使われた資格情報の主体を確認します。開発者の手元から成功したことは、そのワークロードの権限と経路の証拠にはなりません。アカウント、リージョン、オブジェクトのキー、操作、時刻をそろえ、正常な比較対象との差を取りましょう。
本稿はクラウドのアクセス復旧を扱い、削除データの復元やバックアップからのリストアを実演するものではありません。構成図で復旧の対象まで明確にしておくと、RPO やデータ再生成の話へ不用意に広げずに説明できます。
S3 の gateway endpoint を、interface endpoint と混同しない
公式事実： AWS の gateway endpoint 文書は、S3 や DynamoDB へインターネットゲートウェイや NAT を必要とせず接続できる経路を説明しています。gateway endpoint は AWS PrivateLink を使う interface endpoint と同じ仕組みではありません。
S3 gateway endpoint の経路は、サービスの prefix list を宛先に、endpoint をターゲットとしてルートテーブルへ関連付けられます。対象サブネットが使うルートテーブルに関連付いているかを確認することが重要です。「エンドポイントを作った」だけでは、そのワークロードの経路に使われているとは言えません。
今回の図では、ワークロード側の送信 TCP 443 と戻りの通信も確認対象です。公式文書はセキュリティグループやネットワーク ACL が通信を許可する必要も示しています。gateway endpoint 自体に interface endpoint の ENI と同じ箱を描いて、そこへセキュリティグループを付ける説明にはしません。
調査の提案： サブネットと実際のルートテーブルの関連付け、S3 のリージョン、宛先 prefix list、endpoint の対応をひとつずつ照合します。IPv6 や別リージョンを使う要求なら、今回の IPv4・同一リージョンの図をそのまま正解にせず、実際に選ばれたアドレスと経路を確認します。
モデルではこれらを真偽値と endpoint 記号へ縮約しています。したがって route という失敗理由が出ても、実パケットの破棄地点やルート選択アルゴリズムを測定した証拠ではありません。クラウド上の構成情報と通信の観測を、別途取得する必要があります。
Allow 一つで、すべての拒否を打ち消せるわけではない
公式事実： IAM のポリシー評価では、適用される明示的な Deny は Allow より優先します。同一アカウントでのアイデンティティベースとリソースベースの許可には和として評価される場合があり、あらゆるポリシーを単純な AND と説明するのも不正確です。
今回の限定設計では、アイデンティティ側の読み取り Allow を与え、endpoint 側で主体・操作・リソースを制限し、バケット側では通過 endpoint が期待値と異なる場合の Deny を考えます。これらの条件をすべて満たすことをモデルの成功条件にしていますが、AWS IAM 全体の評価器を実装したわけではありません。
公式事実： エンドポイントポリシーの文書は、endpoint policy が identity policy や resource policy を置き換えないことを説明しています。endpoint に Full Access を設定しても、IAM やバケット側の拒否が消えるわけではありません。
gateway endpoint のポリシーで主体を限定する場合、公式文書では Principal を * とし、aws:PrincipalArn 条件で限定する方法が示されています。Principal: "*" の一箇所だけを見て、最終的に誰でも読めると結論づけないでください。Effect、Action、Resource、Condition と他の適用ポリシーを合わせて読みます。
実環境には permissions boundary、session policy、SCP、RCP、暗号鍵の権限、オブジェクト所有者などの追加条件があります。今回のモデルはそれらを省略しています。質問で追加された条件は図へ足し、まだ評価していないものを明示しましょう。
経路を直すと、隠れていた バケットの拒否が見える
初期モデルは二つの不整合を持ちます。ワークロードのルートは E2 に関連付いておらず、バケットの通過 endpoint の期待値は旧 E1 のままです。IAM と endpoint の読み取り許可はありますが、まず経路条件に失敗するため、その先の判定へ進みません。
ローカルモデルの返り値は次のとおりでした。null は HTTP 応答をモデル化する段階へ進んでいないことを意味し、実際のタイムアウト時間を表しません。
{
"phase": "path",
"model_status": null,
"accepted": false,
"reasons": ["route"]
}
次に、route の値だけを E2 へ直しました。モデルは認可段階へ進みますが、バケットの期待値 E1 と異なるため、model_status: 403、理由 bucket_source_explicit_deny、accepted: false となりました。経路の修正により認可の段階へ進み、次に直すべき不整合が見えるようになりました。
公式事実： AWS の endpoint によるバケット制限の例は、aws:SourceVpce と StringNotEquals を使い、指定 endpoint 以外を拒否する方針を説明しています。その Deny は、対象 endpoint からのアクセスを積極的に Allow するものではありません。
本例からの推論： route だけの修正で認可が成立しないため、バケット側の期待値と承認済み経路の対応を確認する必要があります。「IAM に Allow を足す」とだけ答えても、この例の明示的 Deny は解消しません。どの前提が一致していないかを示して、変更範囲を決めます。
403 の理由を、一つの文字列だけで決めない
公式事実： S3 の403調査文書は、適用する Allow がない暗黙の拒否と、Deny による明示的な拒否の両方を扱っています。403 だけから「ロールがない」「endpoint policy が原因」と特定することはできません。
同じ文書は、追加の拒否理由が返る条件と例外も説明しています。VPC endpoint policy による拒否では拡張メッセージが返らない場合があり、複数の拒否理由があってもメッセージはその全部を列挙するとは限りません。モデルの reasons 配列は学習用の内部情報で、AWS が常に同じ配列を返すという意味ではありません。
実環境で残したい証拠は、要求した主体・操作・リソース、応答を返したサービス、時刻、request ID、適用ポリシーの版と条件です。CloudTrail などの記録を使うなら、対象のイベントが取得される設定と期間かを確かめます。「ログが見つからない」ことだけで要求が一度も到達していないと断定しません。
| 手元にある観測 | 次に照合する対象 | その観測だけでは言えないこと |
|---|---|---|
| 実クライアントで HTTP 応答を得られない | DNS、実際の宛先、経路、送信と戻り | IAM の Allow が不足している |
| S3 の403を確認 | 主体・操作・リソースと適用ポリシー | すべての拒否原因を特定できた |
| 管理者の端末では読める | ワークロードとの差、endpoint 条件 | 本番ワークロードが復旧した |
| モデルの reasons に二つの拒否 | モデルに入れた二条件 | AWS の応答にも二理由が出る |
調査途中の説明は、「S3 の応答まで確認できたので、この要求について認可の条件を照合します。全ワークロードのネットワークが正常とはまだ言えません」のように、確認できた範囲へ絞ります。通信経路と認可の両方を一回の成功で一般化しないことが大切です。
復旧案は、読める範囲を保ったまま具体化する
この練習で承認済みの経路を E2 と定めたうえで、バケットの期待値を E2 にそろえました。IAM と endpoint の許可範囲は、同じ report-reader、s3:GetObject、case-reports の reports/ 配下に保ちます。endpoint の制限を丸ごと削除したり、書き込みを追加したりする変更は行いません。
AWS 上で実施する場合は、現在のポリシーと変更差分を保存し、対象 ID・影響範囲・戻す条件をレビューしてから適用する、という手順を提案します。本稿で実行したのは Python の不変な設定値を差し替える操作だけで、実アカウントのアクセス権やネットワーク設定は変更していません。
ローカルで使った三つの設定の生成箇所は次です。replace は dataclass の値を元に新しい設定を作ります。route_endpoint と expected_source_endpoint はモデル専用の属性名で、AWS CLI のオプションではありません。
INITIAL = Config()
ROUTE_ONLY = replace(INITIAL, route_endpoint="E2")
RESTORED = replace(ROUTE_ONLY, expected_source_endpoint="E2")
修正後のモデルはレポート R41、行数12という固定データを評価し、model_status: 200、accepted: true を返しました。ここで初めて、経路と認可に加えて、本稿のレポート契約まで満たしたと判断しています。実際のクラウドで同じ結果が出ることは別途確認が必要です。
公式事実： エンドポイントポリシーの更新は、公式文書で反映に時間がかかる場合が示されています。ローカルモデルの即時切り替えを、AWS の反映時間や復旧所要時間の測定として使わないようにします。
許可する要求と、拒否し続ける要求を対にする
report-reader の読み取りが成功したあとも、別ロール・別prefix・書き込みを拒否する条件を維持できたか確認します。モデルでは修正後にも、別のロール、別バケット、private/ 配下、reports-old/ 配下、s3:PutObject、s3:DeleteObject を拒否することを確認しました。
reports/ と reports-old/ は似て見えますが、今回の prefix はスラッシュを含む reports/ です。文字列の前方一致を使う小さなモデルでも、どこまでを対象にするかを曖昧にすると、許可したつもりの範囲を説明できません。ただし、この文字列比較が IAM の Resource や Condition の完全な実装という意味ではありません。
レポートの内容も対照にしています。{"report_id": "R41", "rows": "12"} は行数が文字列のため、model_status は200でも accepted は false でした。レポート ID の違い、行数11、真偽値、必須項目の不足、余分な項目も拒否しています。今回は「R41・整数12・二項目」という小さな契約です。
本番のレポートなら、スキーマだけでなく対象期間、鮮度、件数、必要な整合性も利用者と決めます。本稿の12行という値から、実業務の正確性や最新性を証明することはできません。必要な読み取りが可能になったことと、利用者が必要なデータが正しいことを分けて説明します。
戻し方も、単に初期設定へ戻すだけでは十分ではありません。今回の初期状態へ戻すと、モデルの読み取りは再び失敗しました。障害を含む旧設定なのか、正常だった基準設定なのかを区別して、rollback の対象を定義しましょう。
28 テストを、実クラウドでの追加確認につなげる
CPython 3.12.14 の unittest で28テストが通りました。経路なし、経路修正後の bucket Deny、期待値修正後の読み取り、許可の欠落、明示的 Deny、範囲外の要求、DNS・送信・戻りを表す失敗条件、レポート契約の不一致などを確認しています。
モデルは最初に経路条件を見て、そのあと認可条件を集める設計です。この順番はプログラムを説明するためのもので、AWS の内部評価順序やエラーメッセージ生成を再現したものではありません。複数の拒否を同時に返すケースも、原因を比較する学習用です。
実環境へ持ち込む場合は、実際の資格情報、ルート関連付け、リージョン、SG・NACL、適用ポリシー、サービスの応答、レポートの利用結果を確認する必要があります。KMS、cross-account、SCP、IPv6 などがあるなら、モデルの対象外として放置せず、新しい条件として調査へ加えます。
面接では、「この28テストは狭いモデルの条件分岐を確認した証拠です。AWS の疎通、ポリシーの完全性、反映時間を実測した証拠ではありません」と言えれば、検証の限界まで共有できます。そのうえで、次に取得する構成情報と要求記録を具体的に挙げます。
五つの問題で、構成と権限の説明を広げる
次の問題は PracHub で確認した公開タイトルです。本稿と同じ構成がその企業の面接で出る保証ではありません。基礎や ML 基盤を扱う問題も含むため、今回は identity、サービス接続、ネットワーク境界の部分へ目的を絞って使います。
| PracHub の問題 | 練習する観点 | 自分の回答で確認すること |
|---|---|---|
| Design an IAM system for services and users | 主体・操作・リソースと権限の境界 | 認証と認可を区別して説明したか |
| Explain AWS access control and frontend typing | AWS の権限を読み解く | フロントエンドの型の話と混ぜず、AWS 部分を説明したか |
| Design secure multi-tier cloud infrastructure | 階層と経路を図にする | ネットワークで届くことを権限の許可と同一視していないか |
| Explain cloud computing fundamentals | クラウドの基礎と責任の分担 | 構成の前提と省略した条件を示したか |
| Design an AWS fine-tuning platform for LLMs | 基盤から保存データへのアクセスを設計する | ML 全体の正しさまで、このアクセス練習で検証したと言っていないか |
次は Explain AWS access control and frontend typing の AWS 部分を使い、主体・操作・リソース・経路・拒否条件を一枚にまとめてください。必要な読み取りの成功と、不要な読み書きの拒否を対にして説明すると、復旧後も必要なアクセス範囲を守れているか、相手と確認しやすくなります。
Sources and Further Reading
- AWS VPC — Gateway endpoints：S3 の経路、ルート関連付け、SG・NACL の観点。
- AWS IAM — Policy evaluation logic：Allow と明示的 Deny、ポリシー種別による評価の違い。
- AWS VPC — Control access using endpoint policies：endpoint policy の位置付け、gateway の主体条件、反映時間。
- Amazon S3 — Controlling access from VPC endpoints：SourceVpce 条件を使うバケット側の制限。
- Amazon S3 — Troubleshoot access denied errors：暗黙・明示的な拒否と、拒否理由メッセージの限界。
Comments (0)