Handism's Tech Blog
学習ガイド一覧へ戻る

クラウド基礎とAWSアーキテクチャ

AWSをベースに、VPCの設計、コンピュート/ストレージサービス、IAMによる権限管理、サーバーレス構成設計などの基礎を学びます。

学習をスタートする

ロードマップ

1

クラウドの基本概念とVPCネットワーク設計

現代のWebアプリケーション開発において、物理的なサーバーを用意してデータセンターに設置する「オンプレミス」から、必要な時に必要なだけサーバーを調達できる「クラウド」への移行はほぼ標準となっています。その代表格である AWS (Amazon Web Services) の設計を理解することはエンジニアの必須スキルです。 第1章では、クラウドコンピューティングの基本コンセプトと、インフラの基盤となる仮想ネットワーク 「VPC (Virtual Private Cloud)」 の設計について学びます。 1. オンプレミスからクラウドへ オンプレミス（自社所有の設備）と比較したクラウドの主なメリットは以下の通りです。 * 俊敏性 (Agility): サーバーが必要になったら数クリック・数分で立ち上げられ、不要になれば即座に削除できます。 * 初期費用ゼロと従量課金: 高価なハードウェアを事前に購入する必要がなく、使った分だけ支払う変動費モデルです。 * グローバル展開: 世界中にあるデータセンター群を使い、数クリックで数秒のうちに世界中にアプリをデプロイできます。 共有責任モデル (Shared Responsibility Model) パブリッククラウドを利用する上で最も重要なセキュリティの原則が「共有責任モデル」です。 * AWSの責任（クラウド「の」セキュリティ）: 物理データセンター、物理サーバー、ハイパーバイザ、ネットワーク回線などの物理的・インフラ的な保護。 * 利用者の責任（クラウド「内」のセキュリティ）: ゲストOSのセキュリティパッチ適用、アプリケーションコードの脆弱性対策、データの暗号化、IAMポリシーの設定など。 2. リージョンとアベイラビリティゾーン (AZ) AWSのグローバルインフラは、地理的に分かれた「リージョン」と、その内部にある「アベイラビリティゾーン（AZ）」という階層構造を持っています。 * リージョン (Region): 東京、バージニア北部、アイルランドなど、世界各地の物理的な拠点の集まり。それぞれ完全に独立しています。 * アベイラビリティゾーン (AZ): 1つのリージョン内に存在する、物理的に隔離された1つ以上のデータセンターの集合体。超高速かつ低遅延な光ファイバーネットワークで相互接続されています。 * 可用性の設計: 地震や停電などの大規模災害によって1つのAZが壊れてもシステムが動き続けられるよう、「マルチAZ（複数のAZにサーバーやDBを分散配置する）」 設計を行うのが基本です。 3. VPC (Virtual Private Cloud) のネットワーク設計 VPCは、AWSアカウント専用の論理的に隔離された仮想ネットワーク空間です。この中にIPアドレスの範囲（CIDRブロック）を設定し、さらに細かく分割した 「サブネット（Subnet）」 を作成してリソースを配置します。 ① パブリックサブネット (Public Subnet) インターネットと直接双方向で通信ができるサブネットです。 * 仕組み: インターネットゲートウェイ（IGW） へのルートテーブルが設定されており、配置されるリソースにはパブリックIPが割り当てられます。 * 配置するもの: ロードバランサ（ALB）や、外部からの接続を受け入れる踏み台サーバー（Bastion）など。 ② プライベートサブネット (Private Subnet) インターネットから直接アクセスできない安全なサブネットです。 * 仕組み: インターネットへの直接のルートを持たず、プライベートIPのみが割り当てられます。 * 配置するもの: Webアプリケーションサーバー（Node.js, Goなど）や、データベース（RDS）。 * アウトバウンド通信（NAT Gateway）: アプリケーションサーバーがライブラリの更新や外部APIの呼び出しのためにインターネットと通信したい場合、パブリックサブネットに配置した NATゲートウェイ（Network Address Translation） を経由して、送信元IPを変換してアウバウンド通信のみを許可します。 まとめ * クラウドはオンプレミスに比べ、俊敏性やコスト効率、マルチAZによる高可用性設計が容易である。 * 共有責任モデルに基づき、利用者はデータやOS、設定（セキュリティグループなど）の保護に責任を持つ。 * VPCの設計では、インターネットに露出するパブリックサブネットと、内部に隠蔽するプライベートサブネットを適切に使い分け、NATゲートウェイで安全なアウトバウンド通信を確保する。

2

主要なAWSサービスとWeb3層アーキテクチャ設計

AWSには数多くのサービスが存在しますが、実際にWebシステムを構築する際に中核となるサービスは限定されています。 第2章では、コンピュート、ストレージ、データベース、および認証認可を管理する主要なAWSサービスの特徴と、それらを組み合わせた安全な 「Web3層アーキテクチャ」 の設計パターンについて学びます。 1. Webインフラを支える4大AWSサービス ① Amazon EC2 (Elastic Compute Cloud) クラウド上の仮想サーバーです。 * 特徴: 数秒でインスタンス（サーバー）を起動でき、CPUやメモリの構成（インスタンスタイプ）を自由に変更できます。 * セキュリティグループ (Security Group): インスタンスレベルで動作する仮想ファイアウォールです。デフォルトはすべてのアウトバウンド（送信）を許可し、すべてのインバウンド（受信）を拒否します。「どのIPアドレスやプロトコル、あるいは別のセキュリティグループからの通信を許可するか」をホワイトリスト形式で厳密に設定します。 ② Amazon S3 (Simple Storage Service) 容量無制限で使える、極めて堅牢なオブジェクトストレージです。 * 特徴: データを「バケット」と呼ばれるコンテナ内に「オブジェクト（ファイル）」として保存します。 * 堅牢性: 年間のデータ耐久性は 99.999999999%（イレブンナイン） を誇り、データは自動的に3つ以上のAZに複製して保管されます。静的ウェブサイトのホスティングや、ユーザー画像・動画アセットの保管場所として多用されます。 ③ Amazon RDS (Relational Database Service) セットアップやバックアップが自動化された、マネージドなリレーショナルデータベースサービスです。 * 特徴: MySQL, PostgreSQL, Oracleなどをサポート。OSのパッチ適用や定期バックアップをAWSが代行します。 * マルチAZ配置: プライマリー（書き込み用）DBのデータを別AZのセカンダリーDBへ同期レプリケーションします。プライマリーが故障した際は、DNSの切り替えにより数分以内に 自動フェイルオーバー（切り替え） が発生し、システムが継続稼働します。 ④ AWS IAM (Identity and Access Management) AWSリソースへのアクセスを安全に制御するための認証・認可システムです。 * 基本コンポーネント: * IAMユーザー: 個々のユーザー（人やアプリケーション）。 * IAMグループ: 複数のユーザーをまとめ、共通の権限を与えるコンテナ。 * IAMポリシー: JSON形式で記述された「どのアクションをどのリソースに対して許可/拒否するか」の定義ドキュメント。 * IAMロール: ユーザーではなく「EC2インスタンス」や「Lambda関数」などのリソースに一時的なアクセス権を与えるための仕組み。 * ベストプラクティス: 必要最低限のアクセス権限のみを付与する 「最小権限の原則（Least Privilege）」 を徹底します。 2. 伝統的かつ堅牢な「Web3層アーキテクチャ」 これまでの技術を組み合わせた、AWSにおける最も標準的なWeb3層アーキテクチャの設計です。 設計のポイント 1. プレゼンテーション層 (ALB): パブリックサブネットに配置され、SSL終端（証明書の管理）を行い、バックエンドのWebサーバーへ負荷分散します。 2. アプリケーション層 (EC2): プライベートサブネットにマルチAZで配置され、インターネットから直接アクセスできない安全な状態にします。 3. データレイヤー層 (RDS): 最も保護すべきデータストアとして、プライベートサブネットのさらに奥深くに配置し、マルチAZで自動バックアップと冗長化を確保します。 まとめ * EC2は仮想サーバーであり、セキュリティグループを用いて不要なポートへの通信を遮断する。 * S3は非常に高い耐久性を持ち、静的コンテンツのホスティングやファイル保管に適している。 * RDSのマルチAZ機能は、データ複製と自動フェイルオーバーによってデータベースの可用性を劇的に向上させる。 * IAMでは最小権限の原則を維持し、リソースに対してはIAMロールを適用してアクセスキーの漏洩を防ぐ。

3

サーバーレスアーキテクチャの基本設計

仮想サーバー（EC2）を利用したWeb3層アーキテクチャは柔軟ですが、OSのパッチ適用、スケールアウトのしきい値設定、アイドル時（アクセスがない時間帯）もサーバーの起動コストが発生し続けるといった運用管理コストが伴います。これらを解消するのが 「サーバーレス（Serverless）」 設計です。 第3章では、サーバーレスの基礎概念、AWSの主要サービス（API Gateway, Lambda, DynamoDB）、および従来システムとの特性比較について学びます。 1. サーバーレスコンピューティングの本質 「サーバーレス」とは、物理的なサーバーが存在しないという意味ではありません。「開発者がサーバーのプロビジョニング、管理、スケーリング、パッチ適用について一切考える必要がないモデル」 を指します。 サーバーレスの4大特徴 1. サーバー管理が不要: OSの管理やハードウェアの保守はすべてクラウドプロバイダーが担当します。 2. 自動で柔軟にスケーリング: リクエストの増加に応じて、システムが自動的かつ瞬時にスケールアウト（並列実行）します。 3. 高い可用性の内包: サーバーレスサービスは、デフォルトで複数のAZにまたがって動作するよう設計されており、ユーザーが冗長化を組む必要がありません。 4. アイドル時のコストはゼロ: サーバーを「起動している時間」ではなく、「リクエストが実行された回数と時間」に対してのみ課金されます。アクセスが全くない時間帯のコストは完全に $0$ になります。 2. サーバーレスWeb APIを構成する主要サービス 最も代表的な「API Gateway $\rightarrow$ Lambda $\rightarrow$ DynamoDB」の三種の神器によるサーバーレスWeb API構成です。 ① Amazon API Gateway 外部からのHTTP/HTTPSリクエストを受け取るフルマネージドなAPIフロントエンドです。 * 機能: ルーティング、CORS設定、APIキー検証、アクセス制限（レート制限/スロットリング）、リクエストデータのバリデーションなどを担当し、後続のLambda関数にリクエストをイベントとして渡します。 ② AWS Lambda イベント駆動型でコードを実行するサーバーレスコンピュートサービス（FaaS）です。 * 仕組み: API GatewayやS3などの「イベント（トリガー）」が発生した瞬間にのみコンテナが立ち上がり、ユーザーが書いたコード（Node.js, Python, Goなど）を実行してレスポンスを返します。処理が終われば自動で消滅します。 ③ Amazon DynamoDB フルマネージドなNoSQLデータベースサービスです。 * 特徴: キーバリュー型データベースとして機能し、アクセス規模がどれだけ大きくなっても「一桁ミリ秒台」の超高速な応答性能を維持します。テーブル定義のスキーマが不要（スキーマレス）で、自動スケーリングによって書き込み・読み込み容量を調節します。 3. EC2（仮想サーバー） vs Lambda（サーバーレス）の比較 比較項目 EC2ベース (仮想サーバー) Lambdaベース (サーバーレス) 起動時間 数分（OS起動・初期化が必要） 数ミリ秒〜数百ミリ秒（コンテナ起動） 課金モデル 起動時間（秒/時間）に対する定額 リクエスト回数 ＋ 実行時間（ミリ秒単位） スケーリング オートスケーリング設定が必要（緩慢） リクエスト数に応じてミリ秒単位で即座に並列スケール コールドスタート なし（常時起動しているため） あり（初回起動時やスケールアウト時のコンテナ作成で遅延が発生） 運用の負担 高い（OSアップデート、監視、パッチ） 極めて低い（コードのデプロイと権限設定のみ） [!WARNING] コールドスタート（Cold Start） しばらくアクセスがない状態からLambda関数を呼び出すと、AWS側で実行環境（コンテナ）を起動し、ランタイムやコードをロードするための待機時間（数百ミリ秒〜数秒）が発生します。これを「コールドスタート」と呼びます。対策として、JavaやC#などの重いランタイムを避け、Node.jsやPython、Goを使用することや、あらかじめ環境を温めておく「プロビジョニングされた並列性（Provisioned Concurrency）」機能を使用することが推奨されます。 まとめ * サーバーレスは、インフラのプロビジョニングやパッチ適用、スケーリングをAWSが完全に自動化する仕組みである。 * API Gateway - Lambda - DynamoDB は、サーバーレスAPI構築における最も標準的な構成である。 * アイドル時コストゼロのため、アクセス頻度が低い、または不定期なAPIでは抜群のコストパフォーマンスを発揮するが、コールドスタートによる初回アクセス遅延の可能性を理解しておく必要がある。

4

IAMとVPCによるセキュアなインフラ構築

クラウドサービスを利用する最大のメリットの一つは俊敏性ですが、適切なセキュリティ設定が行われていなければ、情報漏洩や不正アクセスの甚大なリスクに直面します。 AWSにおけるセキュリティの基本は、「誰がどのリソースにアクセスできるか（ID管理）」 と 「どのようにネットワークへの経路を制限するか（ネットワーク制御）」 の2つの軸に集約されます。 第4章では、ID・アクセス権限を管理する IAM と、安全な仮想ネットワーク空間を構築する VPC の基本と設計アプローチを学びます。 1. AWSのセキュリティ基本理念 AWSでインフラを設計する際、まず理解しなければならないのが 「責任共有モデル (Shared Responsibility Model)」 です。 * AWSの責任（クラウド「の」セキュリティ）: 物理データセンターのセキュリティ、ハードウェア、仮想化ハイパーバイザー、グローバルインフラ（リージョンやアベイラビリティゾーン）の維持・管理。 * 利用者の責任（クラウド「内」のセキュリティ）: ゲストOS、ネットワークトラフィックの制御（セキュリティグループ）、アプリケーションコード、IDおよびアクセス管理（IAM）、データの暗号化など。 AWSが安全なインフラを提供しても、利用者がアクセス権限やネットワークの口を開放したままにしておけばシステムは簡単に突破されてしまいます。 2. IAM（Identity and Access Management） IAMは、AWSリソースへのアクセスを安全に制御するためのサービスです。「認証（誰が）」 と 「認可（何をしてもよいか）」 を一元的に管理します。 IAMの4つの主要要素 1. IAMユーザー (User): AWSとやり取りする特定の個人やアプリケーションを表す実体。ログイン用のパスワードや、API呼び出し用のアクセスキーを保持します。 2. IAMユーザーグループ (Group): 複数のIAMユーザーの集合。同じ職能（例: Developers, SystemAdmins）のメンバーに対して、一括でアクセス権限を付与するために使用します。 3. IAMロール (Role): 特定の個人ではなく、AWSリソース（EC2インスタンスやLambda関数など）や一時的にアクセスを許可したい外部のアイデンティティに権限を貸し出すための仕組み。永続的なキーを持たず、一時的なセキュリティ認証情報を発行します。 4. IAMポリシー (Policy): 許可または拒否するアクションを定義したJSON形式のドキュメント。これをユーザー、グループ、ロールに「アタッチ（紐付け）」することで権限を決定します。 JSONポリシーの例（S3への読み込み専用許可） [!IMPORTANT] 最小権限の原則 (Principle of Least Privilege) セキュリティ上のベストプラクティスとして、ユーザーやリソースには「業務を遂行する上で必要最低限の権限」のみを付与します。過剰な権限（特に管理者権限 AdministratorAccess や、リソース * に対する全アクションの許可）の常用は避けてください。 3. VPC（Virtual Private Cloud） VPCは、AWS上に構築する論理的に隔離されたプライベートな仮想ネットワークです。オンプレミスの物理的なデータセンターのネットワーク構成に酷似した環境をクラウド上で再現できます。 VPCの構成要素 * CIDRブロック (Classless Inter-Domain Routing): VPC全体のIPアドレス範囲（例: 10.0.0.0/16）。 * サブネット (Subnet): VPCを細分化したIPアドレスの範囲（例: 10.0.1.0/24）。 * パブリックサブネット: インターネットゲートウェイへのルートが存在し、インターネットから直接アクセス可能なサブネット（Webサーバーなどを配置）。 * プライベートサブネット: インターネットから直接アクセスできず、隔離された安全なサブネット（データベースやバックエンド処理サーバーを配置）。 * インターネットゲートウェイ (IGW): VPCとインターネットの間で双方向通信を行うためのコンポーネント。 * ルートテーブル (Route Table): サブネットまたはゲートウェイからのネットワークトラフィックの送信先を決定するためのルーティングルールのセット。 * NATゲートウェイ (Network Address Translation): プライベートサブネットにあるリソースが、インターネット上のサービス（OSのパッチ適用や外部APIの呼び出しなど）と通信できるようにする一方、インターネットからそれらのリソースへの着信接続はブロックするデバイス。 4. ネットワークの保護：セキュリティグループ vs ネットワークACL VPC内のリソースをトラフィックの脅威から守るため、AWSでは2つの異なるファイアウォール機能を提供しています。 項目 セキュリティグループ (Security Group) ネットワークACL (Network ACL) 適用範囲 インスタンスレベル (EC2, RDS などに直接付与) サブネットレベル (サブネット全体のバリア) 評価対象 許可ルールのみ（すべてデフォルト拒否） 許可ルールと拒否ルールの両方 評価順序 すべてのルールを評価して適用 ルール番号順に順次評価（マッチしたら終了） 状態管理 ステートフル (戻りトラフィックは自動許可) ステートレス (戻りトラフィックも明示的に許可が必要) [!TIP] ステートフルとステートレスの違い セキュリティグループ（ステートフル）では、Webサーバーへのポート80 (HTTP) インバウンド接続を許可すれば、それに対するアウトバウンドのレスポンス（戻りのパケット）は自動的に許可されます。一方、ネットワークACL（ステートレス）では、インバウンドを許可しただけではレスポンスは通らず、アウトバウンドルール（エフェメラルポートなど）も明示的に設定する必要があります。 まとめ * 責任共有モデルに基づき、利用者はデータの保護、アクセス権限の設定、OSやアプリケーションレイヤーのネットワークセキュリティを担保する。 * IAMでIDと権限を管理し、最小権限の原則に則り不要なアクションの実行を防ぐ。 * VPCを用いて仮想ネットワークを構築し、Webサーバー（パブリック）とDBサーバー（プライベート）を適切に分離して設計する。 * セキュリティグループ（インスタンス単位・ステートフル）とネットワークACL（サブネット単位・ステートレス）を組み合わせて多層防御を構築する。

5

AWSにおける監視とオブザーバビリティ

アプリケーションが稼働し始めると、システムが正常に動作しているか、パフォーマンスに問題がないかをリアルタイムで監視する必要があります。 第5章では、AWSにおけるシステム監視の基本となる Amazon CloudWatch と、トラブルシューティングを強力に支援する AWS X-Ray によるオブザーバビリティ（可観測性）について学びます。 1. オブザーバビリティと3大要素 従来の「監視」は、サーバーがダウンしたかなどの死活監視が主でした。対して 「オブザーバビリティ（可観測性）」 は、「システムの内部状態を、外部から出力される情報に基づいてどれだけ詳細に推測できるか」という概念です。 オブザーバビリティは、以下の 3つの柱（Telemetry Data） で構成されます。 2. Amazon CloudWatch Amazon CloudWatch は、AWS リソースと AWS 上で実行するアプリケーションの監視・管理サービスです。 * CloudWatch Metrics (メトリクス): AWSリソース（EC2やRDSなど）から1分〜5分間隔で自動収集される数値データ。CPU使用率、ネットワーク流量、ディスクI/Oなど。 * CloudWatch Logs (ログの統合): アプリケーションログやシステムログをエージェント経由で収集・集約し、検索やフィルタリング（CloudWatch Logs Insights）を可能にします。 * CloudWatch Alarms (アラーム): メトリクスが閾値を超えた場合に、自動的に管理者にメール通知（Amazon SNS経由）したり、EC2のAuto Scalingを発火させてインスタンスを自動増減したりします。 3. 分散トレーシングと AWS X-Ray マイクロサービスアーキテクチャやサーバーレス設計（API Gateway -> Lambda -> DynamoDB）では、1つのユーザーリクエストが多数のサービスを経由するため、「どの処理のせいでレスポンスが遅くなっているのか」 を見つけるのが困難です。 これを追跡するのが AWS X-Ray です。 AWS X-Rayは、最初のリクエストに一意の 「Trace ID」 を付与し、各サービス間でこのIDを伝播させることで、サービスマップ（トポロジー図）を描画し、どのコンポーネントで遅延やエラーが発生したかを一目瞭然にします。 まとめ * CloudWatch を使うことで、システムの統計データ（メトリクス）や詳細な履歴（ログ）を一元管理し、アラームによる自動復旧を設定できる。 * AWS X-Ray による分散トレーシングは、サービス間を跨ぐリクエストのパフォーマンスを可視化し、ボトルネックの特定を迅速化する。 * これらを組み合わせることで、複雑なクラウドネイティブアプリの オブザーバビリティ（可観測性） を高めることができる。