AWS — 基礎から設計・運用へ

前提: クラウド全般。SAA取得済みなら各節の課題を先に解き、不明点を復習する。

到達目標と学習順序

AWS学習コース総合案内に、全8経路の講座・実習・参考リンクを掲載しています。このページで基礎を確認してから、基礎育成コースのSTEP順に進んでください。

IAM → VPCと通信 → EC2・ストレージ・DB → 可用性 → 監視・コスト → 自動化の順に、学習ポータルを具体化する。

A1. アカウントとIAM — 誰が操作するか

AWSアカウントは資源・権限・請求を整理する重要な境界。Organizationsは複数アカウントの統制を扱う。 学習環境と本番環境を分け、アカウントIDとリージョンを確認してから操作する習慣をつける。

IAMポリシーはAction、Resource、Conditionなどで許可を表す。 IAMロールは、人やサービスが引き受けて一時的な認証情報で操作するために使う。 信頼ポリシーは誰がロールを引き受けられるか、権限ポリシーは引き受けた後に何をできるかを定める。 人のアクセスはフェデレーションやIAM Identity Center、アプリのアクセスは実行基盤に付与したロールを基本候補にする。

利用者のポータルへのログインは、AWS管理コンソールへのログインと別の認証経路。 組織のIDプロバイダーとの連携を設計し、利用者全員にAWS管理権限を与える構成にしない。

課題: 「運用担当」「アプリ」「利用者」の権限表を書く。 解答例: 運用担当は対象環境のデプロイとログ閲覧、アプリは教材の読取と進捗DBへの接続、利用者はアプリ経由の自分の進捗操作。 アプリにS3読取権限があっても、DBの認証・ネットワーク許可が自動で揃うわけではない。

A2. VPC — パケットがどこを通るか

VPCはリージョンに属し、サブネットは一つのAZに属する。二つのAZへ配置するならサブネットもAZごとに設計する。 インターネットゲートウェイへの経路があるサブネットでも、個々の資源のIP・通信許可・サービス設定が適切でなければ通信できない。

利用者 → HTTPS / 認証 → ALB
                       ├→ AZ-a: アプリ
                       └→ AZ-b: アプリ
                                ├→ RDS（非公開接続）
                                └→ S3（権限を限定）

Security Groupは対象に関連付けるステートフルな通信制御。Network ACLはサブネット境界のステートレスな制御で、戻り通信も考える。 経路と権限は別なので、Security Groupを開けるだけで通信できるとは限らない。 インターネットへの送信が必要な場合のNAT、AWSサービスへ接続するVPCエンドポイントも、必要な経路・費用・対応サービスから選ぶ。 管理接続はSystems Managerなどを候補にし、到達性と実行ロールを設計する。

課題: ALB→アプリ、アプリ→DB、アプリ→教材の通信表に、送信元、宛先、ポート、許可理由を書く。 解答例: DBはアプリから必要なDBポートへの接続を許し、利用者端末からの直接接続を許さない。

A3. EC2・S3・RDS — 最小構成を理解する

EC2ではイメージ、インスタンスタイプ、EBS、実行ロール、Security Group、更新・再作成方法を決める。 アプリの成果物から再作成できるようにし、一台のローカルディスクだけに教材や進捗を置かない。

S3はオブジェクトストレージ。バケット・オブジェクトへの権限、公開制御、暗号化、バージョン管理、ライフサイクルを決める。 利用者限定の教材を置く場合、バケットを公開する代わりにアプリ経由配信や期限付きアクセスなどを要件に合わせて選ぶ。 EBSはVMのディスク、EFSは共有ファイルアクセスが必要な場合の候補で、S3をそのまま一般的な共有ディスクと考えない。

RDSはマネージドRDB。エンジン、容量、接続方式、認証、バックアップ、復元、メンテナンスを設計する。 AuroraもRDSの選択肢に含まれるため「RDSかAuroraか」は具体的なエンジンと配置方式に分けて比較する。 DynamoDBはアクセスパターンに合うキー設計が中心。SQLを後から自由に書く感覚で置き換えない。

課題: 進捗テーブルを 利用者ID・教材ID・状態・更新日時 で考え、教材PDFを別の保存先へ分ける理由を書く。 解答例: 更新と集計をDBで扱い、PDF配信・保持をオブジェクトストレージに任せる。DBに教材の識別子を保存し整合性を確認する。

A4. 可用性・コンテナ・サーバーレス

ALBとAuto Scalingを使う場合も、複数AZへの配置、ヘルスチェック、アプリの状態分離が必要。 アプリが二台あっても、DBや認証が単一障害点ならシステム全体は停止し得る。 RDSのMulti-AZは配置方式により構成が異なる。待機系、読取先、障害切替、アプリの再接続動作を確認する。

EC2で管理責任を理解したら、ECS/Fargateでコンテナの運用をどう減らせるか検討する。 EKSはKubernetesの機能・標準化が必要なときの候補。クラスター更新、周辺コンポーネント、アクセス権、監視の運用まで比較する。 Lambdaはイベント単位の実行に向く。同期APIと非同期処理で再試行の仕組みが違うため、冪等性、タイムアウト、失敗時の保管先を考える。

課題: 「教材更新時のサムネイル生成」をAPIの応答中に行う案と、イベントから非同期に行う案を比較する。 解答例: 非同期化で応答を短くできるが、生成待ち表示・重複処理対策・失敗通知が必要になる。

A5. 監視・セキュリティ・復旧・コスト

監視は「教材取得失敗が続いたら、どのログを見て誰が対処するか」まで定める。 復旧はRDSの復元先を用意し、接続先変更とポータルからの読取・更新確認まで手順にする。 バックアップジョブの成功、復元可能性、RTO/RPOを別々に確認する。

AWS Well-Architectedの六つの柱（運用、セキュリティ、信頼性、性能、コスト、持続可能性）を設計レビューに使う。 たとえば冗長化の増額を「無駄」と即断せず、可用性要件と合わせて判断する。公式フレームワーク

A6. 自動化と演習の進め方

構成が説明できたらCloudFormationやTerraform教材で再現方法を学ぶ。 IaCでは構成だけでなく、秘密情報の扱い、変更差分の確認、状態の管理、削除時に保持するデータも決める。

今回は設計演習まで。実環境の作成・障害注入・削除は実施していない。 実習後はVM停止だけで完了とせず、ディスク、IP、LB、NAT、DB、ログ、スナップショットなど残る資源を台帳と照合する。

理解度チェック

1. ロールの信頼ポリシーと権限ポリシーは何が違うか。
2. DB接続がタイムアウトする場合と、認証失敗を返す場合で何を調べるか。
3. Multi-AZでも誤削除に備える必要があるのはなぜか。
4. CloudWatchとCloudTrailをどう使い分けるか。
5. EC2をFargateへ移すと、どの仕事が減り、何が残るか。

解答の要点: 1は引受主体と操作権限、2は経路・通信制御とDB認証の切り分け、3は誤削除も複製され得るため。 4は稼働状態の観測とAPI操作の監査、5はホスト管理の負担が減る一方、イメージ更新・アプリ・権限・データ・監視の責任が残る。

既存応用教材を読む際の補足

既存4本は応用の題材として利用するが、次の断定は採用前に見直す。

• FargateとEC2の費用に固定倍率はない。構成・稼働率・契約・運用工数を揃えて比較する。
• Multi-AZ全般に一つのSLAや切替時間を当てはめない。サービス、配置、契約条件ごとに確認する。
• リージョン制限のSCPはグローバルサービスへの影響を確認する。既存のサンプルを組織へそのまま適用しない。
• データ移行手段は容量だけで決めない。転送可能時間、実効帯域、停止許容、提供状況を確認する。
• Blue/GreenはDBスキーマやデータの互換性が崩れると、トラフィックを戻すだけでは復旧できない。

公式の確認先: IAM、VPC、RDS。

次: AWS応用4本を必要に応じて深めた後、Azureへ。