あなたの理解度を 3 問でチェック

この問題では、EC2インスタンスへのSSHアクセスを特定IPアドレスからのみ許可するセキュリティグループ設定について聞かれています。

今の状態

• オンデマンドのEC2インスタンスが存在する
• SSH接続でアクセスする必要がある

やりたいこと

• 特定のIPアドレス（110.238.98.71）からのみSSH接続を許可したい
• それ以外のIPアドレスからはアクセスを拒否したい

押さえておきたい制約

• SSH接続（プロトコルとポートが決まっている）
• 単一IPアドレスのみ許可（/32表記）

要するに、「セキュリティグループで正しい方向・プロトコル・ポート・IPを設定できるか」という基本設計の問題です。

---

❌ 選択肢A：アウトバウンドルール、UDP、ポート22、送信先 0.0.0.0/0

なぜ不正解なのか

3つの問題点があります。

1. 方向が逆: 外部からEC2への接続を許可したいので、インバウンドルールが必要です
2. プロトコルが違う: SSHはUDPではなくTCPを使用します
3. IPアドレスが違う: 0.0.0.0/0は「すべてのIP」を意味し、特定IPへの制限になりません

---

❌ 選択肢B：アウトバウンドルール、TCP、ポート22、送信先 110.238.98.71/32

なぜ不正解なのか

プロトコルとポートは正しいですが、方向が逆です。

アウトバウンドルールは「EC2から外部への通信」を制御します。今回は「外部からEC2への通信」を制御したいので、インバウンドルールが必要です。

---

❌ 選択肢C：インバウンドルール、UDP、ポート22、ソース 110.238.98.71/32

なぜ不正解なのか

方向とIPアドレスは正しいですが、プロトコルが違います。

SSHはTCPプロトコルで動作します。UDPを指定しても、SSH接続は確立できません。

---

✅ 選択肢D：インバウンドルール、TCP、ポート22、ソース 110.238.98.71/32（正解）

なぜ正解なのか

すべての要素が正しく設定されています。

設定項目	設定値	理由
方向	インバウンド	外部→EC2への接続だから
プロトコル	TCP	SSHはTCPを使用するから
ポート	22	SSHのデフォルトポートだから
ソース	110.238.98.71/32	単一IPのみ許可するから

Well-Architected観点（セキュリティの柱）: 最小権限の原則に従い、必要なIPアドレスからのみアクセスを許可しています。

---

要件×選択肢マトリクス

要件	A	B	C	D
インバウンド方向	❌	❌	✅	✅
TCPプロトコル	❌	✅	❌	✅
ポート22	✅	✅	✅	✅
特定IP（/32）	❌	✅	✅	✅

差がつくポイント: 「インバウンド」と「TCP」の両方を正しく選べるかどうか

---

パターン名: 単一IP許可のSSHアクセス制御

graph LR
    subgraph Internet[インターネット]
        Client[クライアント<br>110.238.98.71]
        Other[その他のIP]
    end
    
    subgraph VPC[VPC]
        SG[セキュリティグループ<br>インバウンド: TCP/22<br>ソース: 110.238.98.71/32]
        EC2[EC2インスタンス]
    end
    
    Client -->|✅ SSH許可| SG
    SG --> EC2
    Other -->|❌ 拒否| SG

なぜこの設計が最適なのか

ステートフルの恩恵: セキュリティグループはステートフル（状態を記憶する）です。インバウンドルールで許可した通信の「戻りのトラフィック」は、アウトバウンドルールがなくても自動的に許可されます。つまり、SSH接続を確立した後のレスポンス通信は自動で通ります。

---

SSH接続の設定問題では、以下の4つの要素を確認してください。

確認項目	正解パターン
方向	インバウンド（外部→EC2）
プロトコル	TCP（SSHはTCP）
ポート	22（SSHデフォルト）
ソース	/32で単一IP指定

覚え方のコツ

「SSH = TCP 22 イン」（SSH接続は、TCPのポート22でインバウンド）

---

よくある間違い

間違い1: 「SSH = UDP」と思いがち

SSH、HTTP、HTTPSなど、一般的なプロトコルの多くはTCPを使用します。UDPは、DNSの一部やストリーミングなど、信頼性より速度を重視する通信で使われます。

間違い2: 「戻りの通信もルールが必要」と思いがち

セキュリティグループはステートフルなので、許可した通信の戻りトラフィックは自動で許可されます。これがネットワークACL（ステートレス）との大きな違いです。

重要ポイント

1. インバウンド vs アウトバウンドの判断 — 「誰が接続を開始するか」で決まります。外部から来る接続はインバウンド、EC2から出ていく接続はアウトバウンドです

2. CIDR表記の意味 — /32は単一IP、/24は256個（xxx.xxx.xxx.0〜255）、/0は全IPを表します。セキュリティ設計では、可能な限り狭い範囲（/32など）を指定するのがベストプラクティスです

この問題では、RDSマルチAZデプロイメントのフェイルオーバー動作について聞かれています。プライマリDBに障害が発生したとき、RDSが「どのような仕組みで」スタンバイに切り替えるかを理解しているかを確認する問題です。

押さえておきたいポイント

• 今の状態: マルチAZ構成でプライマリとスタンバイの2台が稼働中
• 発生した事象: プライマリDBインスタンスに障害が発生
• 確認したいこと: RDSはどのようにフェイルオーバーを実現するか

要するに、「RDSマルチAZのフェイルオーバーとは何をしているのか」という仕組みを問う定義確認問題です。

---

❌ 選択肢A：プライマリデータベースインスタンスが再起動します

なぜ不正解なのか

障害が発生したプライマリは、そもそも再起動できる状態にないことが多いです。ハードウェア故障やAZ全体の障害では、再起動を待っている余裕はありません。マルチAZの目的は「障害が起きたインスタンスの復旧を待たずに、別のインスタンスで即座にサービスを継続する」ことです。

---

✅ 選択肢B：正規名レコード（CNAME）がプライマリからスタンバイインスタンスに切り替わります（正解）

RDSマルチAZのフェイルオーバーは、DNSレベルでのCNAME切り替えで実現されます。

一言定義: RDSエンドポイント（DNS名）の参照先を、プライマリからスタンバイに変更する仕組み

語源: CNAME = Canonical Name（正規名）= 「本当の名前」を指すDNSレコード

なぜ正解なのか

アプリケーションはRDSの「エンドポイント」（DNS名）に接続しています。フェイルオーバー時、RDSはこのDNS名が指す先をスタンバイのIPアドレスに切り替えます。アプリケーション側の設定変更は不要で、同じエンドポイントに接続し続けるだけで、自動的に新しいプライマリに繋がります。

---

❌ 選択肢C：プライマリDBインスタンスのIPアドレスがスタンバイDBインスタンスに切り替わります

なぜ不正解なのか

IPアドレスはサブネット（AZ）に紐づいているため、異なるAZに「移動」させることはできません。プライマリがAZ-Aにあり、スタンバイがAZ-Bにある場合、それぞれ別のサブネットに属しているため、IPアドレスの切り替えは技術的に不可能です。

---

❌ 選択肢D：スタンバイアベイラビリティゾーンに新しいデータベースインスタンスが作成されます

なぜ不正解なのか

マルチAZ構成では、スタンバイは常に稼働中です。新しく作成する必要はありません。スタンバイはプライマリと同期的にデータをレプリケーションしており、障害発生時に即座に「昇格」してプライマリの役割を引き継ぎます。

---

フェイルオーバー方式の比較

方式	実現可能性	切り替え時間	理由
CNAME切り替え	✅	60〜120秒	DNSレベルの変更のみで高速
IPアドレス切り替え	❌	—	AZをまたぐIP移動は不可能
再起動	❌	—	障害インスタンスは復旧不能な場合が多い
新規作成	△	数十分	既にスタンバイがあるので不要

差がつくポイント: 「マルチAZ」→ 既にスタンバイ稼働中 → DNS切り替えで即座にフェイルオーバー

---

問題文に**「マルチAZ」「フェイルオーバー」「障害時の動作」**があれば、CNAME（DNS）切り替えを選びます。

覚え方のコツ

「住所は変えられないが、看板は掛け替えられる」

• IPアドレス = 住所: 建物の場所（AZ/サブネット）に固定されていて動かせない
• DNS名 = 看板: 「このお店はこちら」と指し示すだけなので、簡単に付け替えられる

RDSエンドポイントは「看板」であり、フェイルオーバー時は看板が指す先を変えるだけです。だから60〜120秒という短時間で切り替えが完了します。

---

よくある間違い

間違い1: 「フェイルオーバーでデータが失われる」と思いがち

マルチAZのスタンバイは同期レプリケーションでデータを受け取っています。プライマリへの書き込みは、スタンバイへの書き込み完了を確認してから成功と見なされます。そのため、フェイルオーバー時のデータ損失はありません。

間違い2: 「リードレプリカと同じ仕組み」と思いがち

リードレプリカは非同期レプリケーションで、読み取り負荷分散が目的です。マルチAZスタンバイは同期レプリケーションで、高可用性が目的です。フェイルオーバー先として使えるのはマルチAZスタンバイのみです。

重要ポイント

1. RDSエンドポイントはDNS名 — アプリケーションは常に同じエンドポイントに接続するだけで、フェイルオーバーを意識する必要がありません

2. マルチAZ = 同期 + 自動フェイルオーバー — 「同期レプリケーション」と「CNAMEによる自動切り替え」のセットで高可用性を実現しています

この問題では、S3 Standard-IA（低頻度アクセス）の特徴について聞かれています。財務レポートの保存先として選んだストレージクラスの特性を正しく理解しているかを問う問題です。

押さえておきたいポイント

• S3 Standard-IAは「低頻度アクセス」だけでなく「即時取り出し」も特徴
• 他のストレージクラス（Glacier、Intelligent-Tiering）との違い
• 「IA = Infrequent Access（低頻度アクセス）」の意味

要するに、「S3 Standard-IAはどんなデータに向いているか」を選ぶ問題です。

---

❌ 選択肢A：データアーカイブに使用するのに理想的です

なぜ不正解なのか

「データアーカイブ」に最適なのはS3 Glacierです。Glacierは非常に低コストですが、取り出しに数分〜数時間かかります。Standard-IAは「すぐに利用可能である必要がある」データ向けなので、アーカイブ用途とは異なります。

---

✅ 選択肢B：アクセス頻度の低いデータ向けに設計されています（正解）

なぜ正解なのか

「IA」は「Infrequent Access（低頻度アクセス）」の略です。問題文にも「頻繁にアクセスされない」と書かれており、まさにこのユースケースに合致します。Standard-IAはストレージ料金が安い代わりに、取り出し料金がかかる設計になっています。

---

❌ 選択肢C：運用上のオーバーヘッドなしに、データを最もコスト効率の高いアクセス層に自動的に移動します

なぜ不正解なのか

これはS3 Intelligent-Tieringの特徴です。Intelligent-Tieringはアクセスパターンを監視し、自動で最適な階層にデータを移動します。Standard-IAには自動移動機能はありません。

---

❌ 選択肢D：高レイテンシーと低スループットのパフォーマンスを提供します

なぜ不正解なのか

完全に逆です。Standard-IAは低レイテンシー・高スループットを提供します。S3 Standardと同等のパフォーマンスを維持しつつ、ストレージコストを下げているのが特徴です。

---

✅ 選択肢E：必要な時に迅速なアクセスを必要とするデータ向けに設計されています（正解）

なぜ正解なのか

問題文に「監査人がレポートを要求した際にはすぐに利用可能である必要がある」とあります。Standard-IAはアクセス頻度は低いが、アクセス時には即座に取り出せる設計です。Glacierのように取り出しに時間がかかるわけではありません。

---

比較表：S3ストレージクラスの違い

項目	Standard-IA	Intelligent-Tiering	Glacier
アクセス頻度	✅ 低頻度向け	不明/変動向け	低頻度向け
取り出し速度	✅ 即時（ミリ秒）	✅ 即時	❌ 数分〜数時間
自動階層移動	❌ なし	✅ 自動	❌ なし
主な用途	バックアップ・DR	パターン不明なデータ	長期アーカイブ

差がつく条件: 「低頻度」＋「即時アクセス必要」→ Standard-IA

---

問題文に**「アクセス頻度が低い」＋「すぐに取り出せる必要がある」**の両方があれば、S3 Standard-IAを選びます。

覚え方のコツ

「IA = 低頻度だけど、Immediate Access（即時アクセス）も可能」

• 低頻度＋即時 → Standard-IA
• 低頻度＋待てる → Glacier
• 頻度不明 → Intelligent-Tiering

---

よくある間違い

間違い1: 「低頻度アクセス＝取り出しが遅い」と思いがち

Standard-IAの「低頻度」はアクセス回数の話です。取り出し速度はS3 Standardと同じ（ミリ秒単位）です。この2つを混同しないようにしましょう。

間違い2: 「自動で階層移動してくれる」と思いがち

自動階層移動はIntelligent-Tiering専用の機能です。Standard-IAにデータを移動するには、ライフサイクルポリシーを自分で設定する必要があります。

重要ポイント

1. Standard-IAは「2つの条件」で選ぶ — 低頻度アクセス＋即時取り出しが必要な場合に最適
2. コスト構造の違いを理解する — Standard-IAはストレージ料金が安い代わりに、取り出し料金がかかる設計