AWS認定資格 WEB問題集＆徹底解説
CloudOpsエンジニア -アソシエイト
問題文と選択肢
この問題の原因は何ですか。
- EFS マウントターゲットがプライベートサブネット内に作成されている。
- EC2 インスタンスに関連付けられている IAM ロールにおいて、efs:MountFileSystem アクションが許可されていない。
- この別のアベイラビリティーゾーン内の Amazon EFS 用 VPC エンドポイントにトラフィックをルーティングするよう、ルーティングテーブルが構成されていない。
- マウントターゲットに対するセキュリティグループにおいて、EC2 インスタンスによって使用されているセキュリティグループからの受信 NFS 接続が許可されていない。
A. EFS マウントターゲットがプライベートサブネット内に作成されている。
マウントターゲットをプライベートサブネットに置くことはまったく問題なく、むしろ推奨構成です。
EFS は VPC 内の ENI（マウントターゲット）経由でアクセスするため、インターネットからの到達性は不要です。同じ VPC 内の EC2 インスタンスであれば、プライベートサブネット上のマウントターゲットへ問題なく接続できます。マウント失敗の原因にはなりません。
B. EC2 インスタンスに関連付けられている IAM ロールにおいて、efs:MountFileSystem アクションが許可されていない。
EFS のマウントに efs:MountFileSystem というアクションは存在しません（IAM 認可を使う場合の実際のアクションは elasticfilesystem:ClientMount 等です）。
さらに EFS の IAM 認可はファイルシステムポリシーとマウントヘルパーの IAM オプションを使うときだけ効くもので、既定では IAM 権限なしに同一 VPC からマウントできます。今回は既存 AZ では正常にマウントできているため、IAM が原因とは考えにくく、不適切です。
C. この別のアベイラビリティーゾーン内の Amazon EFS 用 VPC エンドポイントにトラフィックをルーティングするよう、ルーティングテーブルが構成されていない。
Amazon EFS は VPC エンドポイントを使わずに、VPC 内のマウントターゲット（ENI）へ直接 NFS 接続します。
EFS へのアクセスにゲートウェイ型エンドポイントやルートテーブルの追加設定は不要で、「EFS 用 VPC エンドポイント」という発想自体が誤りです（VPC エンドポイントが要るのは、S3 や API 呼び出しなど別の文脈です）。したがって原因になりません。
D. マウントターゲットに対するセキュリティグループにおいて、EC2 インスタンスによって使用されているセキュリティグループからの受信 NFS 接続が許可されていない。
これが正解です。EFS をマウントするには、マウントターゲットのセキュリティグループの受信ルールで、EC2 インスタンスのセキュリティグループ（または CIDR）からの TCP 2049（NFS）を許可する必要があります。
この許可が無いとクライアントからの NFS 接続がブロックされ、mount コマンドが失敗またはハングします。新しい AZ にサブネットとマウントターゲットを作っただけでセキュリティグループの許可を入れ忘れた、という今回の症状に完全に合致します。
EFS がマウントできない＝まず SG の TCP 2049。マウントターゲット側の受信で EC2 の SG を許可する。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| 既存 AZ ではマウントできていた（EFS 自体は正常） | ファイルシステムや IAM の設定ではなく、新しい AZ 側で足りていない設定を探す →選択肢（B）を消す |
| 新しい AZ にサブネットとマウントターゲットは作成済み | 残る必須設定はマウントターゲットのセキュリティグループ。ここで NFS を許可しないと通信できない →選択肢（D）が正解 |
| EFS のアクセス経路は VPC 内の ENI（マウントターゲット） | VPC エンドポイントもルートテーブル設定も不要。EFS はエンドポイント経由のサービスではない →選択肢（C）を消す |
| マウントターゲットの配置場所 | プライベートサブネットは推奨構成であり、マウント失敗の原因にならない →選択肢（A）を消す |
ひっかけポイント
- 「プライベートサブネットにあるから通信できないのでは」と考えたくなるが、EFS は同一 VPC 内からの接続が前提で、プライベートサブネット配置こそ推奨。パブリック/プライベートの話に引きずられない
- efs:MountFileSystem はもっともらしいが実在しないアクション名。EFS の IAM 認可は elasticfilesystem:ClientMount 等で、しかも既定では必須ではない
- 「別 AZ だから VPC エンドポイントやルーティングが必要」は誤り。マウントターゲットは AZ ごとに 1 つ作るだけで、同一 VPC 内はルートテーブルの追加なしに到達できる
- セキュリティグループはマウントターゲット側の受信を見る。EC2 側の送信（アウトバウンド）は既定で全許可のため、見落としやすいのは常にマウントターゲット側
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「オンプレミスから Direct Connect 経由でマウントできない」 | SG の 2049 許可に加え、ルーティングとオンプレ側ファイアウォールの 2049が論点に。 |
| 「特定のインスタンスにだけ読み取り専用でマウントさせたい」 | EFS アクセスポイント＋ファイルシステムポリシー（IAM 認可）が正解軸に。 |
| 「別 VPC / 別アカウントの EC2 から EFS を使いたい」 | VPC ピアリング / Transit Gateway（＋SG の相互許可）や EFS のクロスアカウントマウントが論点に。 |
| 「マウントはできるが転送中の暗号化を必須にしたい」 | マウントヘルパーの -o tls とファイルシステムポリシーでの aws:SecureTransport 強制が正解軸に。 |
リファレンス
この問題を解くために必要な知識を扱う公式ドキュメントです。| 知識項目 | 公式ドキュメント |
|---|---|
| EFS マウントターゲットのセキュリティグループ要件（NFS 2049） | NFS クライアントのネットワークアクセスの制御 - Amazon Elastic File System |
この問題の原因は何ですか。
- EFS マウントターゲットがプライベートサブネット内に作成されている。
- EC2 インスタンスに関連付けられている IAM ロールにおいて、efs:MountFileSystem アクションが許可されていない。
- この別のアベイラビリティーゾーン内の Amazon EFS 用 VPC エンドポイントにトラフィックをルーティングするよう、ルーティングテーブルが構成されていない。
- マウントターゲットに対するセキュリティグループにおいて、EC2 インスタンスによって使用されているセキュリティグループからの受信 NFS 接続が許可されていない。