AWSで学ぶクラウドの考え方_基礎研修

新卒エンジニア向け 1日研修 AWSで学ぶ 「クラウドの考え方」基礎 Why（なぜ） → What（何か） → How（どう使うか）で理解する うさうさ研修工房

本日のゴールと進め方 今日のゴール 個々のサービスの操作手順を覚えるのではなく、「なぜそうなっているのか」というクラウドの“考え方”を自分の言葉で説明できるようにな る。 各章は、この3つの問いをセットで学びます W Why なぜ必要か W What H それは何か How どう使うか アジェンダ（全10章 + まとめ） ・ 01 クラウドとは何か ・ 06 ネットワーク ・ 02 グローバルインフラ ・ 07 アクセス制御(IAM) ・ 03 責任共有モデル ・ 08 マネージドサービス ・ 04 コンピューティング ・ 09 コスト ・ 05 ストレージ ・ 10 Well-Architected AWSで学ぶ「クラウドの考え方」基礎研修 Introduction

Ch.00 なぜ今、クラウドを学ぶのか 新人エンジニアにとっての職業的な意義 W Why W What H How なぜクラウドを学ぶ必要があるの か 本研修で得られるもの 今日の学び方 ▪ 現在の多くのシステムは、何らかの形でク ラウド基盤の上で動いている ▪ 個別サービスの操作手順ではなく、クラウ ド共通の“考え方” ▪ 各テーマをWhy（なぜ）→What（何か） →How（どう使うか）の順で学ぶ ▪ クラウドの前提知識なしでは、設計や障害 対応の会話についていけない ▪ AWSに限らず、他クラウドを学ぶ際にも応 用できる土台 ▪ 丸暗記ではなく、「なぜそうなっているか」 を自分の言葉で説明してみる ▪ 「習うより慣れよ」だけでは、応用が利く知 識にならない ▪ 先輩やお客様との会話で使える、共通言 語としての基礎知識 ▪ わからないことは、その場で質問してすぐ に解消する AWSで学ぶ「クラウドの考え方」基礎研修 Chapter 00

Ch.01 クラウドとは何か オンプレミスからクラウドへ、発想の転換 W Why W What H How なぜオンプレミスからクラウドへ？ クラウドの正体 AWSへの最初の触れ方 ▪ 自社でサーバーを買うと、納品まで数週 間〜数ヶ月かかる ▪ IT資源（サーバー・保存領域・回線）を、必 要な分だけ借りられるサービス ▪ マネジメントコンソール（Webブラウザ画 面）から資源を確認・操作する ▪ アクセス集中に備えて余裕を持った台数 を買うと、普段は遊ばせることに ▪ 特徴は5つ：①オンデマンド即時利用 ②幅 広いネットワークアクセス ③複数利用者 でのリソース共用 ④迅速な拡張・縮小 ⑤ 使った分だけ課金 ▪ 使い捨てできる検証環境として、まず小さ く触ってみる ▪ ビジネスの変化速度に、ハードウェア調達 が追いつかない ▪ 「買う」ではなく「借りて、使ったらすぐ返せ る」感覚を体で覚える ▪ 「所有」から「利用」へという発想の転換が クラウドの本質 AWSで学ぶ「クラウドの考え方」基礎研修 Chapter 01

Ch.01 図解：オンプレミス と クラウド の発想の違い オンプレミス（自社所有） クラウド（AWS） 調達スピード 発注〜納品に数週間〜数ヶ月 数分でリソースを起動 初期費用 機器購入費が先に発生（固定費） 初期費用なし、使った分だけ（変動費） 拡張・縮小 ピークに合わせた台数を事前確保 需要に応じて即座に増減 運用・保守 電源・空調・故障対応も自前 施設・ハードウェアはAWSが担当 AWSで学ぶ「クラウドの考え方」基礎研修 Chapter 01 / 図解

Ch.02 AWSのグローバルインフラ 世界中に広がる拠点という考え方 W Why W What H How なぜ世界中にデータセンターがあ るのか 3つの拠点単位を区別する 拠点を選ぶときの考え方 ▪ 利用者から近い拠点で処理するほど、応 答が速くなる（低遅延） ▪ リージョン：世界各地に置かれた独立した データセンター群の総称 ▪ 利用者の所在地に近いリージョンを選び、 応答速度を優先する ▪ 1つの拠点が災害等で止まっても、他の拠 点でサービスを継続できる ▪ アベイラビリティゾーン（AZ）：リージョン内 にある、物理的に離れた複数の施設 ▪ 重要なシステムは複数のAZにまたがって 構築し、単一障害点を避ける ▪ 国や業界によって、データの保管場所に 関する法規制が異なる ▪ エッジロケーション：利用者により近い場 所でコンテンツ配信等を行う拠点 ▪ 業界の法規制・社内規程に沿ったリージョ ンかを必ず確認する AWSで学ぶ「クラウドの考え方」基礎研修 Chapter 02

Ch.02 図解：リージョン・AZ・エッジロケーションの階層 リージョン（例：東京リージョン） AZ AZ AZ アベイラビリティゾーン 1 アベイラビリティゾーン 2 アベイラビリティゾーン 3 物理的に離れた データセンター施設 物理的に離れた データセンター施設 物理的に離れた データセンター施設 エッジロケーション（利用者に近い拠点、世界各地に多数配置） AWSで学ぶ「クラウドの考え方」基礎研修 Chapter 02 / 図解

Ch.03 責任共有モデル どこまでがAWSの責任で、どこからが自分の責任か W Why W What H How なぜ「責任の境界線」を意識するの か 責任は上下に分かれている 新人が意識すべきチェックポイント ▪ 設定ミスによる情報漏えい事故の多くは、 利用者側の設定に原因がある ▪ AWSの責任＝「クラウド“の”セキュリティ」 ：施設・ハードウェア・基盤ソフトウェア ▪ 自分が設定した項目（権限・公開範囲）は 必ず見直す習慣を持つ ▪ 「クラウドだから安全」という思い込みが、 事故の引き金になりやすい ▪ 利用者の責任＝「クラウド“内”のセキュリ ティ」：データ・アクセス権限・設定・アプリ ▪ 「これは自分の担当範囲か」を常に自問し ながら作業する ▪ 自分の担当範囲を正しく理解することが、 新人エンジニアの第一歩 ▪ 境界線の位置は、利用するサービスの種 類によって変動する ▪ わからない設定はデフォルトのままにせ ず、意味を調べてから変更する AWSで学ぶ「クラウドの考え方」基礎研修 Chapter 03

Ch.03 図解：責任共有モデル 利用者の責任 ── 「クラウド“の中”のセキュリティ」 ■ データの管理 ■ アクセス権限（IAM）の設定 ■ OS・ミドルウェアの設定 ■ ネットワーク設定（VPC等） ■ アプリケーションの実装 ↑ 利用者が守る範囲 ／ AWSが守る範囲 ↓ AWSの責任 ── 「クラウド“の”セキュリティ」 ■ データセンターの物理的セキュリティ ■ サーバー等のハードウェア ■ ネットワークの基盤設備 ■ 仮想化基盤（ソフトウェア） AWSで学ぶ「クラウドの考え方」基礎研修 Chapter 03 / 図解

Ch.04 コンピューティングの考え方 サーバーを「買う」から「借りて増減する」へ W Why W What H How なぜサーバーを買わずに借りるの か 仮想サーバーという単位 リソースを選ぶ思考プロセス ▪ アクセスが急増するイベント時だけ、一時 的に台数を増やしたい ▪ EC2に代表される「仮想サーバー（インス タンス）」を必要な数だけ起動する ▪ まず小さめの構成で始め、実測データを 見ながら調整する ▪ ピークに合わせて買うと、平常時は無駄な 設備投資になる ▪ インスタンスタイプ（性能の組み合わせ）を 用途に応じて選択する ▪ 常時使うか／一時的に使うかで、起動・停 止の運用方針を分ける ▪ 「必要な時に、必要な分だけ」動かせる俊 敏性が求められている ▪ オートスケーリング：負荷に応じて台数を 自動的に増減させる仕組み ▪ 性能不足は「規模を上げる」か「台数を増 やす」かの両方を検討する AWSで学ぶ「クラウドの考え方」基礎研修 Chapter 04

Ch.04 図解：需要の変動に「追従する」容量という考え方 オンプレミスはピークに合わせた容量を常時確保 → 平常時は無駄。クラウドは需要に追従して増減 → 無駄が少ない。 AWSで学ぶ「クラウドの考え方」基礎研修 Chapter 04 / 図解

Ch.05 ストレージの考え方 ファイルサーバーとは違う保存の思想 W Why W What H How なぜファイルサーバーだけでは足 りないのか 3つの保存方式を区別する 用途に応じた選び方 ▪ 画像・動画・ログなど、増え続ける非構造 化データの置き場所が必要 ▪ ブロックストレージ：ディスクを直接扱う、 OSから見える一区画 ▪ OSやDBを動かす土台にはブロックスト レージを選ぶ ▪ 台数が増えるほど、耐久性・可用性を自 前で担保するのは大変 ▪ ファイルストレージ：フォルダ階層で管理 する、共有ファイルサーバー型 ▪ 複数サーバーで共有するファイル群には ファイルストレージを選ぶ ▪ 「壊れない・消えない・どこからでも使え る」保存先が求められる ▪ オブジェクトストレージ（S3等）：キーと値で データを保存、高い耐久性 ▪ 画像・バックアップ・ログなど大量データに はオブジェクトストレージを選ぶ AWSで学ぶ「クラウドの考え方」基礎研修 Chapter 05

Ch.05 図解：3つのストレージ方式 ブロック ファイル オブジェクト (EBS 等) (EFS 等) (S3 等) ディスクを直接扱う 最小単位の保存領域 フォルダ階層で管理 複数サーバーで共有 キーと値で保存 高い耐久性・無制限に近い容量 主な用途 主な用途 主な用途 ▪ OSの起動ディスク ▪ 共有ファイルサーバー ▪ 画像・動画・ログ ▪ データベースの土台 ▪ 複数台からの同時アクセス ▪ バックアップ・静的ファイル配信 AWSで学ぶ「クラウドの考え方」基礎研修 Chapter 05 / 図解

Ch.06 ネットワークの考え方 論理的に「区切る」ことで安全性を高める W Why W What H How なぜ区画を分ける必要があるのか VPCという自分専用の仮想ネット ワーク シンプルな3層構成の考え方 ▪ 外部に公開してよい部分と、公開してはい けない部分が混在している ▪ VPC：AWS上に構築する、自分専用の論 理的なネットワーク区画 ▪ 利用者が触れるWebサーバーはパブリッ クサブネットに置く ▪ 全てを同じ区画に置くと、一箇所の侵入で 全体に影響が及ぶ ▪ パブリックサブネット：インターネットから到 達できる区画 ▪ 業務処理やデータベースはプライベート サブネットに隠して守る ▪ 「公開する場所」と「守るべき場所」を明確 に分離する必要がある ▪ プライベートサブネット：外部から直接は 到達できない、内部専用の区画 ▪ どの通信を許可し、どの通信を拒否する かを1つずつ設計する AWSで学ぶ「クラウドの考え方」基礎研修 Chapter 06

Ch.06 図解：VPCとサブネットによる区画分け インターネット AWSクラウド VPC（自分専用の仮想ネットワーク） パブリックサブネット プライベートサブネット Webサーバー (EC2) → インターネットからアクセス可 AWSで学ぶ「クラウドの考え方」基礎研修 データベース (RDS) → 外部から直接アクセス不可 Chapter 06 / 図解

Ch.07 アクセス制御（IAM）の考え方 「最小権限の原則」を体で覚える W Why W What H How なぜ最小権限が重要なのか IAMを構成する要素 権限設計の思考プロセス ▪ 必要以上の強い権限は、ミスや不正の被 害範囲を広げてしまう ▪ ユーザー：個人に割り当てるアカウント ▪ 「誰が」「何に対して」「何をする必要があ るか」を最初に洗い出す ▪ 権限を絞ることで「うっかり本番環境を壊 す」事故を未然に防げる ▪ 「まず全部許可」ではなく「必要な分だけ許 可」が安全の基本姿勢 AWSで学ぶ「クラウドの考え方」基礎研修 ▪ グループ：役割ごとにユーザーをまとめた もの ▪ ポリシー：「何をしてよいか」を定義した ルール ▪ ロール：一時的に権限を貸し出す仕組み （人ではなくサービス等に付与） ▪ 個人にではなく、役割（グループ）に権限 を割り当てて管理する ▪ 定期的に権限を棚卸しし、使われていな い強い権限を外す Chapter 07

Ch.07 図解：IAMの構造 ── 誰に・何を許可するか 所属する → 適用される → ユーザー グループ ポリシー 個人に割り当てる アカウント 役割ごとに ユーザーをまとめる 「何をしてよいか」 を定義したルール ロール AWSサービス等 一時的に権限を貸し出す （人ではなくサービス等に付与） 必要な時だけ 権限を借りて動作 最小権限の原則：常に「必要な分だけ」を意識する AWSで学ぶ「クラウドの考え方」基礎研修 Chapter 07 / 図解

Ch.08 マネージドサービスの考え方 自分で運用しない、という選択肢 W Why W What H How なぜ自分でDBサーバーを運用しな いのか マネージドサービスが肩代わりす る範囲 選ぶときの判断基準 ▪ OSパッチ適用・バックアップ・故障対応 は、地味だが重い運用作業 ▪ RDS等のマネージドサービス：DBソフトの 保守・バックアップ・冗長化を代行 ▪ 細かなチューニングまで自分で握りたい か、運用の手離れを優先するか ▪ 運用に時間を取られると、本来注力すべ き開発に時間を割けない ▪ 利用者はデータの中身・アクセス権限・使 い方の設計に集中できる ▪ コストは「自前運用の人件費」と比較して 総合的に判断する ▪ 定型的な運用作業は、任せられるところ は任せた方が価値を生む ▪ 「土台の運用」と「中身の設計」で責任の 分界点が変わる ▪ まずはマネージドサービスを基本の選択 肢として検討する AWSで学ぶ「クラウドの考え方」基礎研修 Chapter 08

Ch.08 図解：自己運用 と マネージドサービス の作業範囲 自己運用（EC2上にDB構築） マネージド（RDS利用） 自分（利用者）の作業範囲 データの中身・活用方法の設計 AWSが代行する作業範囲 データの中身・ 活用方法の設計 バックアップ設定 冗長化・故障対応 OSパッチ適用 バックアップ 冗長化・故障対応 OSパッチ適用 DBソフトの保守 （AWSが代行） DBソフトの保守 AWSで学ぶ「クラウドの考え方」基礎研修 Chapter 08 / 図解

Ch.09 コストという考え方 固定費から変動費へ、意識の切り替え W Why W What H How なぜ「従量課金」で意識が変わる のか 料金モデルの基本 コスト意識を持つ日常習慣 ▪ オンプレミスは購入時点で費用が固定さ れる「固定費」の世界 ▪ オンデマンド：使った分だけ、都度支払う 基本の料金形態 ▪ 使い終わった検証環境は、その日のうち に削除・停止する ▪ クラウドは使った分だけ支払う「変動費」 の世界に変わる ▪ リザーブド：長期利用を約束する代わりに 割引を受ける料金形態 ▪ 定期的に利用状況を見て、使われていな いリソースがないか確認する ▪ 消し忘れたリソースが、そのままコストとし て積み上がっていく ▪ スポット：余っている資源を安く使う、中断 もありうる料金形態 ▪ 「動かしっぱなし」を作らないことが、最大 のコスト対策になる AWSで学ぶ「クラウドの考え方」基礎研修 Chapter 09

Ch.09 図解：固定費 と 変動費 という発想の違い オンプレミス 購入時点で費用が確定 使わない月も同じ費用が発生 クラウド 使った分だけ支払う 消し忘れがそのままコストに AWSで学ぶ「クラウドの考え方」基礎研修 Chapter 09 / 図解

Ch.10 Well-Architected Framework 「良い設計」を判断するための共通のものさし W Why W What H How なぜ設計の「型」が必要なのか 6つの柱で設計を見る 研修内容を6本柱に紐づける ▪ 経験の浅いうちは、何を優先して設計す べきか判断基準を持ちにくい ▪ 運用上の優秀性・セキュリティ・信頼性 ▪ 今日学んだ責任共有モデルやIAMは「セ キュリティ」の柱に対応する ▪ AWSが世界中の設計知見をまとめた「共 通言語」が用意されている ▪ この型を知っておくと、先輩やお客様との 会話が噛み合いやすくなる AWSで学ぶ「クラウドの考え方」基礎研修 ▪ パフォーマンス効率・コスト最適化・持続 可能性 ▪ それぞれの柱ごとに、目指すべき状態と ベストプラクティスが整理されている ▪ AZ分散やマネージドサービスは「信頼性」 の柱に対応する ▪ 従量課金の考え方は「コスト最適化」の柱 に対応する Chapter 10

Ch.10 図解：Well-Architected Framework の6本柱 Well-Architected Framework（良い設計を判断する共通のものさし） 運用上の 優秀性 セキュリティ 信頼性 パフォーマンス 効率 コスト最適化 持続可能性 AWSクラウド基盤 今日学んだ内容は、すべてこの6本柱のどこかに対応している AWSで学ぶ「クラウドの考え方」基礎研修 Chapter 10 / 図解

まとめ：今日学んだWhy-What-Howマップ 01 クラウド 02 インフラ 03 責任共有 04 コンピューティング 05 ストレージ 所有→利用への転換 リージョン/AZ/エッジ 境界線を意識する 借りて増減させる 用途で使い分ける 06 ネットワーク 07 IAM 08 マネージド 09 コスト 10 Well-Architected 論理的に区切る 最小権限の原則 任せて集中する 固定費→変動費 共通のものさし AWSで学ぶ「クラウドの考え方」基礎研修 Summary

ネクストアクション ▪ 実際にAWSマネジメントコンソールを触り、今日出てきた画面を自分の目で確認する ▪ 小さな検証環境を1つ作り、使い終わったら削除するところまでを体験する ▪ わからない用語が出てきたら、Why-What-Howに当てはめて調べ直す習慣をつける Q&A 今日出てきた「なぜ？」を、遠慮なく質問してください。 本日はお疲れさまでした