fein's personal site

個人サイト制作：サイトマップへ戻る

AWSで学ぶWebアプリ構築の全体像｜インフラからデプロイまでを俯瞰する

このページはまだ制作中です。

AWSのセキュリティ設計──責任分担から暗号化・監査まで

クラウド環境で安全にシステムを運用するためには、「誰が何を守るべきか」を明確にすることが重要です。
AWSでは、セキュリティに関する責任をクラウド提供者と利用者の間で分担する「責任共有モデル」が採用されています。

セキュリティの責任はAWSと利用者で分担される

AWSは、物理的なデータセンターの保護や、ハイパーバイザー、ネットワークインフラなどの基盤部分のセキュリティを担当します。
一方、利用者はその上に構築するシステムやアプリケーション、データの保護を担います。
たとえば、EC2インスタンスのファイアウォール設定や、S3バケットのアクセス制御などは利用者の責任範囲です。

監査には専用のサービスが活用できる

AWSでは、システムの操作履歴や構成変更を記録・分析するための監査向けサービスが複数用意されています。
代表的なものに、CloudTrail（操作履歴の記録）、Config（リソース状態の追跡）、Security Hub（セキュリティ状況の統合表示）などがあります。
これらを組み合わせることで、誰が何をしたか、どの設定が変更されたかを後から確認でき、コンプライアンス対応にも役立ちます。

暗号化は自動と手動の両方がある

AWSでは、保存されるデータを暗号化する仕組みが標準で提供されています。
サービスによっては、暗号化が自動的に行われるものもありますが、利用者が明示的に設定を行う必要があるケースもあります。
たとえば、S3ではバケット単位で暗号化を有効にする設定が必要ですし、RDSではインスタンス作成時に暗号化を選択する必要があります。

この違いを理解しておくことで、意図しない未暗号化の状態を防ぐことができます。

暗号鍵の管理には2つの選択肢がある

データを暗号化する際に使われる鍵の管理には、AWSが提供するマネージドサービスが利用できます。
主な選択肢は「AWS Key Management Service（KMS）」と「AWS CloudHSM」です。
KMSは、AWSが鍵の保管と操作を安全に代行してくれるサービスで、ほとんどのユースケースに対応できます。
一方、CloudHSMは、より厳密なセキュリティ要件に対応するために、専用のハードウェアで鍵を管理する仕組みです。

どちらを選ぶかは、システムの要件やコンプライアンス基準によって変わります。
AWSのセキュリティ設計は、単に「守る」だけでなく、「誰が何を守るか」「どう記録し、どう暗号化するか」といった構造的な理解があると安心ですよね。

AWS CloudWatchの基本機能──モニタリングと運用の可視化を支える仕組み

AWSを使ってインフラを構築すると、リソースの状態や動作を継続的に監視する必要が出てきます。
その中心的な役割を担うのが「Amazon CloudWatch」です。
これは、AWS環境の健全性やパフォーマンスを把握し、必要に応じて自動対応まで可能にする統合モニタリングサービスです。

リソースの動きを自動で収集する

CloudWatchは、EC2やRDSなどのAWSリソースが生成されると、それらの動作状況を自動的に収集し始めます。
CPU使用率やディスクI/Oなど、基本的なメトリクスは標準で取得されるため、特別な設定をしなくてもすぐに監視を始められます。

より詳細なデータはエージェントで取得可能

標準のメトリクスでは足りない場合、CloudWatchエージェントを導入することで、より細かい情報を収集できます。
たとえば、メモリ使用量やプロセスごとの負荷など、OSレベルの詳細なデータも取得可能です。
これはAWS上のインスタンスだけでなく、オンプレミスのサーバーにも対応しているため、ハイブリッド環境でも活用できます。

ログの一元管理とメトリクス化

CloudWatchにはログ管理機能もあり、アプリケーションやシステムのログをサーバー内に保存することなく、クラウド上で一元的に管理できます。
これにより、ログの可視性が高まり、複数の環境にまたがる運用でも効率的な分析が可能になります。

さらに、ログに記録されたメッセージをもとに、独自のメトリクスを作成することもできます。
たとえば、特定のエラーメッセージが何回発生したかをカウントして、それをトリガーにアラームを設定する──といった柔軟な運用が可能です。

アラームと自動対応

CloudWatchでは、収集したメトリクスに対してしきい値を設定し、条件を満たしたときに通知を送ったり、自動的に復旧処理を実行したりすることができます。
これにより、問題の早期検知だけでなく、人的対応を減らす運用の自動化にもつながります。

ダッシュボードで全体を俯瞰する

最後に、CloudWatchにはダッシュボード機能があり、必要なメトリクスやログを1つの画面にまとめて表示できます。
これにより、複数のサービスやインスタンスの状態を一目で把握でき、運用チームの可視性と判断力を高めることができます。

AWSの監査と構成管理──CloudTrailとConfigの役割

AWSを安全かつ安定して運用するには、「誰が何をしたか」を記録する仕組みと、「リソースが正しい状態にあるか」を確認する仕組みの両方が必要です。
AWSにはそれぞれの役割を担うサービスが用意されており、CloudTrailとConfigがその代表格です。

CloudTrail：操作履歴をすべて記録する

まず、CloudTrailはAWS上で行われた操作の履歴を記録するサービスです。
たとえば、誰がいつ、どのサービスに対して、どんなAPIを使って操作を行ったのか──その詳細がすべてログとして残ります。
これにより、意図しない変更や不正なアクセスがあった場合でも、後から「何が起きたのか」を正確に追跡できます。

この仕組みは、セキュリティ監査やトラブルシューティングに欠かせません。
ログはS3に保存され、必要に応じて分析ツールと連携させることもできます。

Config：リソースの状態を監視し、理想とのズレを検出する

一方、AWS Configは、クラウド上のリソースが「あるべき状態」に保たれているかをチェックするためのサービスです。
たとえば、特定のセキュリティ設定が必須である場合、それが守られているかどうかを自動的に監視できます。

もし設定が意図した状態から外れていた場合、Configはそれを検出し、通知したり、必要に応じて自動修復を行うことも可能です。
これにより、コンプライアンス違反や設定ミスを早期に発見し、安定した運用を維持できます。

CloudTrailが「過去の操作を記録するカメラ」だとすれば、Configは「現在の状態を見張るセンサー」のような存在です。
両者を組み合わせることで、AWS環境の安全性と信頼性を高めることができます。

AWSにおける「認証」と「認可」

クラウドサービスを安全に使うためには、「誰がアクセスしているのか」「何が許可されているのか」を明確に管理する必要があります。
AWSではこの仕組みを支える2つの重要な概念があります。
それが「認証」と「認可」です。

認証：アクセスしているのは誰かを確認する

まず「認証」は、AWSにアクセスしようとしている相手が本当にその本人かどうかを確認するプロセスです。
たとえば、IAMユーザーがログインするときに入力するユーザー名やパスワード、MFA（多要素認証）などがこれにあたります。
AWSはこれらの情報をもとに、「このアクセス要求は信頼できる人物（またはサービス）からのものか？」を判断します。

この段階では、まだ「何ができるか」は決まっていません。
あくまで「誰なのか」を確認するのが認証です。

認可：その人に何を許可するかを決める

次に「認可」は、認証された相手に対して「どの操作を許可するか」を決める仕組みです。
AWSでは、IAMポリシーを使って「このユーザーはS3バケットの読み取りはできるが、書き込みはできない」といった細かいルールを設定します。

つまり、認証が「この人は誰か？」を確認するのに対して、認可は「この人に何をさせていいか？」を決めるものです。
両者はセットで使われることが多く、セキュリティ設計の基本となります。
この違いを理解しておくと、IAMポリシーの設計やアクセス制御のトラブルシューティングがぐっと楽になります。

AWSのIAM設計──安全で柔軟なアクセス管理

AWSでは、誰がどのリソースにアクセスできるかを細かく制御するために、IAM（Identity and Access Management）という仕組みが用意されています。
これは、クラウド環境における「ユーザー管理」や「権限設計」の中核となるもので、セキュリティを保ちながら柔軟な運用を可能にします。

ここでは、IAMの基本的な構成要素と、それぞれがどのような役割を果たすのかを順を追って見ていきましょう。

ルートユーザーは最小限に使う

AWSを使い始めると、まず最初に「ルートユーザー」という特別なアカウントが発行されます。
これはAWSアカウント全体を管理するための最上位の権限を持つ存在ですが、実際の運用ではこのアカウントを頻繁に使うべきではありません。
万が一このアカウントが漏洩した場合、取り返しのつかないリスクにつながるため、どうしても必要な設定作業を除いては使用を避けるのが基本です。

IAMユーザーは人にもサービスにも使える

日常的な操作には「IAMユーザー」を使います。
これはAWSにアクセスするための個別のアカウントで、人間の利用者だけでなく、アプリケーションや外部サービスなどもこの枠組みで管理できます。
たとえば、あるアプリがS3バケットにアクセスする必要がある場合、そのアプリ専用のIAMユーザーを作成して、必要な権限だけを与えることができます。

権限はグループ単位で管理する

IAMユーザーごとに個別に権限を設定してしまうと、管理が煩雑になりがちです。
そこで登場するのが「IAMグループ」です。
複数のユーザーをグループにまとめて、そのグループに対して一括で権限を設定することで、管理の効率と一貫性が保てます。
たとえば「開発者グループ」にはEC2の操作権限を、「監査グループ」にはログ閲覧の権限だけを与える、といった運用が可能です。

ポリシーで最小限の権限を与える

権限の設定には「IAMポリシー」という仕組みを使います。
これはJSON形式で記述されたルールセットで、どのサービスに対して、どの操作を許可するかを細かく定義できます。
ポリシーを設計する際には「最小権限の原則」が重要です。
つまり、ユーザーやグループには必要最低限の権限だけを与えることで、万が一の事故や悪用のリスクを減らすことができます。

ロールで一時的な権限を切り替える

さらに、IAMには「ロール」という仕組みもあります。
これは一時的に別の権限を借りるようなイメージで、たとえばあるサービスが別のサービスにアクセスする必要があるときに使われます。
ロールはユーザーに直接紐づくものではなく、状況に応じて柔軟に使い分けることができるため、クロスアカウントアクセスや自動化された処理などにも非常に便利です。

AWSのセキュリティグループとネットワークACL

AWSでは、クラウド上のリソースを守るために複数のセキュリティ機能が用意されています。
その中でもよく登場するのが「セキュリティグループ」と「ネットワークACL（アクセスコントロールリスト）」です。
どちらも外部からのアクセスを制御する役割を持っていますが、動作の仕方には大きな違いがあります。

セキュリティグループは、個々のインスタンス（たとえばEC2）に直接紐づく防御壁のような存在です。
特徴的なのは、通信の「状態」を覚えていること。
たとえば、外部からの接続を許可した場合、その接続に対する応答も自動的に通してくれます。
つまり、一度許可された通信の流れは、戻ってくるときもスムーズに通過できるのです。
このように、通信の履歴をもとに判断する仕組みを「ステートフル（状態を持つ）」と呼びます。

一方、ネットワークACLは、サブネット全体に対して適用されるルールセットです。
こちらは通信の状態を記憶せず、すべてのリクエストに対して毎回ルールを照らし合わせて判断します。
たとえば、外部からの接続を許可していても、戻ってくる通信が別途許可されていなければ通過できません。
このような仕組みは「ステートレス（状態を持たない）」と呼ばれます。

この違いを理解することで、AWSのネットワーク設計やセキュリティ設定がより安心して行えるようになります。
セキュリティグループは細かくインスタンス単位で制御したいときに、ネットワークACLはサブネット全体に対して広くルールを適用したいときに、それぞれ使い分けると効果的です。

AWSはどんな環境でも活用できる

ウェブサービスや業務システムを運用する際、企業や開発者は「どこにシステムを置くか」を選ぶ必要があります。
選択肢には以下のようなものがあります。

クラウド環境

すべてのシステムをインターネット上のサーバーに置く方法。
柔軟でスケーラブル。

オンプレミス環境

自社の建物内にサーバーを設置して運用する方法。
制御性が高く、セキュリティ重視の場面で使われます。

ハイブリッド環境

クラウドとオンプレミスを組み合わせた方法。
既存の資産を活かしつつ、クラウドの利点も取り入れられます。

AWS（Amazon Web Services）は、これらのどの環境でも活用できる柔軟なサービス群を提供しています。
クラウド中心の構成でも、社内サーバーとの連携が必要な場合でも、AWSはそれぞれに合った機能を用意しているため、導入のハードルが低く、拡張性も高いのが特徴です。

AWS CloudFormationで構成を自動化できる

システムを構築する際、毎回手作業で設定を行うのは大変ですし、ミスも起こりやすくなります。
そこで役立つのが AWS CloudFormation というツールです。

これは、システムの構成（どんなサーバーを使うか、どんなネットワークを組むかなど）を「テンプレート」として記述できる仕組みです。
テンプレートを使うことで、同じ構成を何度でも自動的に再現することができ、次のようなメリットがあります。

• 作業時間を大幅に短縮できる
• 人為的なミスを防げる
• チームでの共有や再利用がしやすくなる

初心者の方でも、テンプレートを少しずつ学んでいけば、複雑な構成を簡単に再現できるようになります。
まるで「レシピ通りに料理を作る」ような感覚で、インフラ構築ができるのです。

AWSリージョンの選定における考慮事項

AWSでは、世界中に「リージョン」と呼ばれる拠点が用意されています。
これは、データセンターのまとまりのようなもので、東京やオレゴン、フランクフルトなど、地理的に分散しています。
利用するリージョンの選定にあたっては、複数の要素を踏まえた判断が求められます。

法的・規制面の条件（コンプライアンス）

たとえば、日本国内にデータを保管する必要がある場合は東京リージョンを選ぶなど、法律や業界ルールに合わせた選択が必要です。

地理的な近さ

ユーザーや社内システムとの距離が近いほど、通信が速く安定します。

提供されているサービスの種類

すべてのリージョンが同じサービスを提供しているわけではないため、必要な機能が使えるかも確認ポイントです。

コスト

リージョンによって料金が異なることがあるため、予算に応じた選択も重要です。

アベイラビリティゾーンの構成と役割

1つのリージョンの中には、さらに「アベイラビリティゾーン（AZ）」と呼ばれる複数の施設が存在します。
これは、同じ地域内にある独立したデータセンター群のことです。

最低でも3つ以上のゾーンが用意されている

これは、障害が起きても他のゾーンでサービスを継続できるようにするためです。

地理的にも設備的にも分離されている

たとえば、電源やネットワークが別々になっているので、あるゾーンでトラブルが起きても他のゾーンには影響しません。

エッジロケーションを活用したサービスの概要

AWSでは、ユーザーにできるだけ速く安定したサービスを提供するために、世界各地に「エッジロケーション」と呼ばれる拠点を設けています。
これは、ユーザーの近くに配置された中継地点のようなもので、通信の遅延を抑える役割を果たします。

この考え方をもとに、コンテンツ配信、名前解決、グローバルな通信経路の最適化など、用途に応じた複数のサービスが提供されています。

Amazon CloudFront

画像や動画などの静的コンテンツを、ユーザーの近くから高速で配信するためのコンテンツ配信ネットワーク（CDN）です。

Amazon Route 53

ユーザーのアクセスを最適な場所に誘導するためのDNSサービスで、可用性とルーティングの柔軟性に優れています。

AWS Global Accelerator

世界中のユーザーからの通信を、最短ルートでAWSのサービスに届けることで、応答速度と信頼性を向上させる仕組みです。

低遅延を実現するローカル展開型サービスの特徴

AWSでは、より細かい場所で処理を行うための仕組みも提供されています。
これにより、ユーザーや端末との距離をさらに縮め、リアルタイム性の高いサービスを実現できます。

それぞれのサービスは、設置場所や用途に応じて異なる特徴を持っており、目的に合わせた使い分けが重要です。

AWS Wavelength

5Gネットワークの近くに配置され、モバイルアプリなどに超低遅延での通信を提供します。

AWS Local Zones

都市部に設置された拠点で、クラウドの処理をユーザーの近くで実行できるため、応答性が向上します。

AWS Outposts

AWSのインフラとサービスをそのまま社内に導入できる仕組みで、オンプレミス環境でもクラウドの利点を活かすことができます。

Amazon Machine Image (AMI)

AMIは、EC2（仮想サーバー）を作るための「ひな形」や「設計図」のようなものです。
この中には、OS（例：LinuxやWindows）や必要なソフトウェア、設定などがすでに入っています。
新しいサーバーをすばやく、同じ状態で何台も作りたいときにとても便利です。

EC2インスタンスタイプの選択

EC2には「小型」「中型」「大型」など、いろいろなタイプがあります。
たとえば、軽い作業なら小型で十分ですが、大量のデータ処理や高負荷な作業には大型が必要です。
用途に合ったタイプを選ぶことで、無駄なく効率的に使えます。

t系（例：t3, t4g）

バースト可能な性能を持つ低コストインスタンス。
通常はCPU使用率が低いが、必要なときに一時的に性能を上げられる。
開発環境や軽量なWebアプリに最適。

m系（例：m6i, m7g）

汎用型インスタンスで、バランスの取れたCPU・メモリ構成。
多くの用途に対応可能で、企業の業務アプリや中規模Webサービスに向いている。

c系（例：c7g, c6i）

コンピューティング最適化型。
高いCPU性能が求められる処理（例：バッチ処理、ゲームサーバー、科学計算）に適している。

r系（例：r7g, r6i）

メモリ最適化型。
インメモリデータベース（Redisなど）や大規模キャッシュ処理に向いている。
メモリ容量が多く、データ集約型のアプリに適している。

g系（例：g5）

GPU搭載インスタンス。
機械学習、3Dレンダリング、動画処理など、GPUを活用する用途に特化。
NVIDIA GPUが搭載されており、CUDA対応の処理が可能。

i系（例：i4i）

ストレージ最適化型。
高速なローカルNVMeストレージを持ち、大量の読み書きが発生するワークロードに適している。
例：NoSQLデータベース、ログ処理など。

h系（例：h1）

高いディスク容量を持つインスタンス。
大容量のデータセットを扱うHadoopや分散ファイルシステムに向いている。

f系（例：f1）

FPGA（Field Programmable Gate Array）搭載インスタンス。
ハードウェアレベルでのカスタム処理が可能で、特殊なアルゴリズムや高速処理に利用される。

「バースト可能」という言葉は、EC2インスタンスの中でも特に t系（例：t3, t4g）によく使われる概念です。
初心者にもわかりやすく、少し専門的な背景も交えて説明しますね。

EC2インスタンスのバースト

「バースト可能」とは、平常時は控えめ、必要なときだけ一時的に高性能になる仕組みのことです。
通常は低いCPU性能で動作します（＝省エネモード）。
でも、アクセスが急増したり、重い処理が一時的に必要になったときは、短時間だけCPU性能を引き上げる（バースト）ことができます。
このバーストは「CPUクレジット」という仕組みで管理されていて、使わない時間にクレジットを貯めておき、必要なときに使う感じです。
たとえるなら、普段は省エネで静かに動いているけど、急に仕事が増えたら「よし、今だけ本気出す！」と頑張るタイプのサーバーです。
バースト可能インスタンスが向いている用途として、次のようなものが挙げられるでしょう。

• 軽量なWebサイトやブログ
• 開発・テスト環境
• 時々しか負荷がかからないアプリケーション

料金プランの選択でコスト最適化

EC2には、使った分だけ払う「オンデマンド」や、長期利用で割引される「リザーブド」などの料金プランがあります。
たとえば、短期間だけ使うならオンデマンド、長く使うならリザーブドが向いています。
使い方に合ったプランを選ぶことで、無駄な出費を減らせます。

オンデマンドインスタンス（On-Demand Instances）

必要なときにすぐ使えて、使った分だけ課金される柔軟なプラン。
初期費用なし・契約期間なし。
短期利用や予測が難しいワークロードに最適。

リザーブドインスタンス（Reserved Instances）

1年または3年の契約で、事前にインスタンスの種類とリージョンを固定することで大幅な割引が受けられる。
長期的に安定して使うサービスに向いている。
「スタンダード」と「コンバーティブル」の2種類があり、後者は柔軟な変更が可能。

スポットインスタンス（Spot Instances）

AWSの未使用リソースを割安で利用できるプラン。
最大90%の割引が可能だが、AWSの都合でインスタンスが中断される可能性がある。
中断に強いバッチ処理や分散処理に向いている。

Savings Plans

インスタンスタイプに縛られず、使用量ベースで割引が受けられる柔軟な料金モデル。
「Compute Savings Plan」と「EC2 Instance Savings Plan」があり、用途に応じて選べる。
リザーブドインスタンスよりも柔軟性が高く、長期利用に適している。

Dedicated Hosts

物理サーバーを1台まるごと専有できるプラン。
ライセンス要件やセキュリティポリシーに応じて、他のユーザーと共有しない環境が必要な場合に利用される。
コストは高めだが、コンプライアンス重視の企業に適している。

起動テンプレートの活用

起動テンプレートは、EC2を立ち上げるときの「設定メモ」のようなものです。
インスタンスタイプ、AMI、ネットワーク設定などを事前にまとめておけるので、毎回手動で設定する手間が省けます。
チームで使うときにも、統一された設定でミスを防げます。

Auto Scalingグループの役割

Auto Scalingは、アクセスが増えたときに自動でEC2を増やし、減ったら減らしてくれる仕組みです。
その「増減の管理」をするのがAuto Scalingグループです。
これにより、必要なときだけサーバーを増やして、コストも抑えられます。

スケーリングポリシーの設定

スケーリングポリシーは、「いつ」「どれくらい」EC2を増減させるかを決めるルールです。
たとえばCPU使用率が80％を超えたら1台追加、30％以下なら1台減らす…といった設定ができます。
これにより、サービスの安定性とコストのバランスを保てます。

Elastic Load Balancingの種類：ALB・NLB・GWLB

Elastic Load Balancing（ELB）は、アクセスの「交通整理」をしてくれる仕組みです。
たくさんのユーザーからのリクエストを、複数のサーバー（EC2インスタンス）にうまく振り分けて、サービスがスムーズに動くようにしてくれます。
ELBには、用途に応じて3つの種類があります。

ALB（Application Load Balancer）

Webアプリ向け。
URLやヘッダーなど、リクエストの内容に応じて振り分けができる。
例：/login はログインサーバーへ、/images は画像サーバーへ。

NLB（Network Load Balancer）

高速・高スループットが必要なネットワーク向け。
TCPレベルでの処理に特化していて、ゲームサーバーや金融系システムなどに向いている。

GWLB（Gateway Load Balancer）

セキュリティ機器（ファイアウォールやIDS/IPSなど）をスケーラブルに配置するためのロードバランサー。
ネットワークトラフィックを中継しながら、セキュリティチェックを行う用途に使われる。

Auto Scalingとの連携で負荷分散を自動化

ELBは、Auto Scalingと組み合わせることで、サーバーの数が増えたり減ったりしても、自動で負荷を分散してくれます。
たとえば、
昼間はアクセスが多くてサーバーを増やす → ELBが自動で振り分け。
夜間はアクセスが減ってサーバーを減らす → ELBが残ったサーバーにだけ振り分け。
これにより、サービスの安定性を保ちつつ、コストも最適化できます。
人が手動で調整しなくても、AWSが状況に応じてうまくやってくれるのが魅力です。

Amazon ECS（Elastic Container Service）

Amazon ECSは、Dockerコンテナをまとめて管理・実行するためのサービスです。
Dockerコンテナとは、アプリケーションとその動作に必要な環境をひとまとめにした「小さな箱」のようなもの。
ECSはこの箱を並べて、どのサーバーで動かすか、どう連携させるかを自動で調整してくれます。
たとえるなら、ECSは「コンテナの運行管理者」。どの箱をどこに置くか、どう動かすかを決めてくれる存在です。

Amazon EKS（Elastic Kubernetes Service）

Amazon EKSもDockerコンテナを管理するサービスですが、Kubernetes（クバネティス）という人気のオーケストレーションツールを使っているのが特徴です。
Kubernetesは、世界中で使われているオープンソースの仕組みで、より細かく・柔軟にコンテナを制御できます。
ECSがAWS独自の管理方式なのに対し、EKSは「業界標準のKubernetesをAWS上で使えるようにしたもの」です。

AWS Fargate

AWS Fargateは、ECSやEKSで動かすコンテナを「サーバーなし」で実行できる仕組みです。
通常は、コンテナを動かすためにEC2などのサーバーを用意しますが、Fargateを使えばその準備が不要になります。
AWSが裏側で必要なリソースを自動で用意してくれるので、インフラ管理の手間がぐっと減ります。
つまりFargateは「サーバーのことは気にせず、コンテナだけに集中できる」便利な実行環境です。

この3つは、コンテナを使ったアプリケーション開発や運用において、目的や技術スタイルに応じて選ぶことができます。

ECSが向いているケース

すぐにコンテナ運用を始めたい

AWSに慣れていて、学習コストを抑えたい場合に適しています。

インフラ管理を最小限にしたい

Fargateと組み合わせることで、サーバーの準備や管理が不要になります。

シンプルな構成で十分なアプリケーション

複雑な制御が不要な中小規模のサービスに向いています。

EKSが向いているケース

Kubernetesの知識や運用経験がある

既存のKubernetesスキルを活かしてAWS上で運用できます。

他クラウドやオンプレミスと統一したい

マルチクラウド戦略やハイブリッド環境に適しています。

複雑なワークロードを細かく制御したい

マイクロサービスやCI/CDなど、細かな設定が必要な場合に有効です。

AWS Lambdaのポイント

• サーバーの準備や管理が不要で、コードだけで処理を実行できる。
• イベント（例：ファイルアップロード、API呼び出し）に応じて自動で動く。
• 使った分だけ課金されるので、コストを最適化しやすい。
• 小さな処理を素早く実行するのに向いている。

AWS Batchのポイント

• 大量のジョブを効率よくまとめて処理できる。
• 必要な数のサーバーをAWSが自動で用意してくれる。
• 重い処理や長時間かかる作業に適している。
• 科学技術計算やデータ変換などの用途に強い。

オンプレミスのように使えるAWSネットワーク：VPCの全体像

Amazon Virtual Private Cloud（VPC）は、AWS上に自分専用の仮想ネットワーク空間を構築できるサービスです。
このVPC内では、IPアドレスの範囲やサブネット、ルートテーブル、セキュリティグループなどを自由に設定でき、オンプレミスのネットワークと同じように制御可能です。
つまり、AWS上でプライベートなネットワーク環境を作り、インターネットから隔離された安全な空間でサービスを運用できるのがVPCの役割です。

VPCが必要なサービスと不要なサービスを考える

AWSには、VPC内で動作するサービスと、VPC外で動作するサービスがあります。
VPC内のサービスは、ネットワーク構成やセキュリティ設定が必要なものが中心です。代表例は以下の通りです：

Amazon EC2

仮想サーバー

Amazon RDS

リレーショナルデータベース

ELB

ロードバランサー

Amazon ElastiCache

インメモリキャッシュ

Amazon Redshift

データウェアハウス

これらは、VPC内でIPアドレスを持ち、セキュリティグループやサブネットで通信制御を行う必要があります。
一方、VPC外のサービスは、グローバルに提供されるマネージドサービスで、ネットワーク構成を意識せずに使えるものが多いです：

Amazon S3

オブジェクトストレージ

Amazon DynamoDB

NoSQLデータベース

AWS Lambda

サーバーレス関数

Amazon Route 53

DNSサービス

Amazon CloudFront

CDN

AWS WAF

Webアプリケーションファイアウォール

これらは、VPCに依存せず、AWSが提供する共通インフラ上で動作します。

VPCが必要な理由：制御と自由度のバランス

この違いは、サービスの性質と運用モデルに起因します。
VPC内のサービスは、ユーザーがネットワーク構成やセキュリティを細かく制御する必要があるため、専用の仮想ネットワーク環境（VPC）での運用が求められます。
一方、VPC外のサービスは、AWSが提供するグローバルなインフラ上で動作するマネージドサービスであり、ユーザーがネットワークを構築する必要がありません。

このように分かれることで、必要な自由度と運用負荷のバランスが取れるようになっています。
たとえば、EC2やRDSはVPC内で細かく制御し、S3やLambdaはVPC外で手軽に使う、といった使い分けが可能です。

VPC構成図の基本イメージ

[VPC]
├─ Public Subnet（インターネットアクセス可能）
│ ├─ EC2（Webサーバー）
│ └─ NAT Gateway（Private Subnetの外部通信用）
│
├─ Private Subnet（インターネット非公開）
│ ├─ EC2（アプリケーションサーバー）
│ ├─ RDS（データベース）
│ └─ ElastiCache（キャッシュ）
│
└─ Route Table & Internet Gateway

この構成では、外部公開が必要なリソースはPublic Subnetに、内部処理用のリソースはPrivate Subnetに配置します。セキュリティと可用性のバランスが取れた設計です。

セキュリティグループ設計例

AWSでインフラを構築する際、セキュリティグループはとても重要な役割を担います。
これは、各リソースがどのような通信を許可するかを細かく設定できる“仮想のファイアウォール”のようなものです。
特にVPC内で複数のサービスを連携させる場合、どのサービスがどこからアクセスされるべきかを明確にしておくことで、セキュリティを高めながらもスムーズな通信が可能になります。

以下の表では、代表的なAWSリソースに対して、どのような通信を許可すべきか、そしてその際に使われるポート番号の例を整理しています。
初めてセキュリティグループを設計する方でもイメージしやすいよう、用途ごとに分けて記載しています。

※すべて最小限のIP範囲に制限するのがベストプラクティスです。

ユースケース別サブネット設計例

AWSでネットワーク設計を行う際、どのようにサブネットを分けるかは非常に重要なポイントです。
サブネットの構成によって、サービスの公開範囲やセキュリティレベル、さらには運用の柔軟性まで大きく変わってきます。
ここでは、よくある3つのユースケースに沿って、サブネットの設計パターンをわかりやすく整理しました。

「外部に公開するWebサービス」「社内向けのバッチ処理」「サーバーレス中心の構成」など、それぞれの目的に応じたネットワークの分け方を知ることで、より安全で効率的なインフラ設計が可能になります。
初めてVPCを設計する方にもイメージしやすいよう、構成要素とその役割を簡潔にまとめてみました。

Webアプリケーション構成（公開型）

Public Subnet

EC2（Web）、ALB（ロードバランサー）

Private Subnet

EC2（App）、RDS、ElastiCache

NAT Gateway

Private Subnetからの外部アクセス用

この構成は、外部公開と内部処理を分離することで、セキュリティとスケーラビリティを両立します。

バッチ処理・非公開システム構成（閉鎖型）

Private Subnetのみ

EC2（バッチ）、RDS

VPCエンドポイント

S3やDynamoDBへの安全なアクセス

NAT Gateway（任意）

外部APIとの通信が必要な場合のみ

この構成は、インターネットに一切公開せず、内部処理に特化した設計です。

サーバーレス構成（VPC外中心）

VPC外サービス

Lambda、S3、DynamoDB、CloudFrontなど

VPC内配置（必要時）

LambdaをVPC内に配置し、RDSやElastiCacheにアクセス

この構成は、マネージドサービス中心で構成がシンプル。
ただし、VPC内アクセス時はサブネットとセキュリティグループの設定が必要です。

ユースケース：公開型WebアプリケーションのVPC構成

AWS上でWebサービスを構築する際、どのようにネットワークを設計するかは、セキュリティや可用性、そして将来的な拡張性に大きく関わってきます。
特に、インターネット経由で利用される公開型のWebアプリケーションでは、外部からのアクセスと内部処理をしっかり分離し、安全かつ効率的に運用できる構成が求められます。

ここでは、そうしたユースケースに最適なVPC構成の一例をご紹介します。
各コンポーネントの役割や配置場所を整理しながら、セキュリティ設計や可用性の確保、スケーラビリティへの対応など、実践的な視点で構成のポイントを解説しています。
初めてVPCを設計する方にも、すでに運用中の方にも役立つよう、簡素に書いてみました。

想定シナリオ

企業や開発チームが、インターネット経由で利用されるWebサービス（例：ECサイト、予約システム、SaaSアプリ）をAWS上に構築するケース。

構成概要

セキュリティ設計のポイント

• セキュリティグループで通信を制限（例：Webサーバーは80/443のみ、DBはAppサーバーからの3306のみ許可）
• サブネット分離により、外部公開と内部処理を明確に分離
• IAMロールでEC2やLambdaがS3などに安全にアクセス

拡張性と可用性

• Auto Scaling GroupでWeb/Appサーバーの台数を自動調整
• マルチAZ構成でRDSの可用性を確保
• CloudWatch + SNSで監視と通知を自動化

この構成が向いているケース

• 外部ユーザーがアクセスするWebサービス
• セキュリティを保ちつつ、内部処理を分離したいアプリケーション
• トラフィックの増減に応じて柔軟にスケールしたいサービス

この構成は、セキュリティ・可用性・スケーラビリティの三拍子が揃ったベストプラクティスです。

機械学習や人工知能に関するプロダクト、またデータ分析についてはAWSのプロダクト一覧と対応するAzure・GCPサービスをご覧ください。