Webサービスやモバイルアプリを運営する中で、開発パートナーから「AWS構成図」を受け取ったものの、何が書いてあるのかさっぱり分からない——そんな経験はないでしょうか。
インフラは専門的に見えますが、基本的な要素と役割を理解すれば、構成図から「どんなシステムなのか」「どこにコストがかかるのか」「障害時のリスクはどこにあるのか」といった重要な情報を読み取れるようになるでしょう。
本記事では、非エンジニアの運営担当者でも構成図が読めるようになることを目指し、AWSインフラの基礎知識をわかりやすく解説していきます。
AWSインフラとは？まず押さえておきたい基本概念
まずは「インフラ」「クラウド」「AWS」という基本的な用語から整理していきましょう。
インフラとは「システムの土台」
インフラとは、サーバー、ネットワーク、データベースなど、システムを動かすための基盤のことです。アプリケーション（プログラム）が動くための土台であり、ユーザーの目には見えませんが、システムを支える重要な要素です。
クラウドとオンプレミスの違い
インフラを用意する方法には、大きく分けて2つあります。
オンプレミスは、自社で物理サーバーを購入・設置・管理する方法です。自社のオフィスやデータセンターにサーバーを置き、自分たちで保守運用を行います。
一方、クラウドは、インターネット経由で必要な時に必要なだけサーバーを借りる方法です。物理的な機器の購入や設置は不要で、クラウド事業者が用意したインフラを利用します。
クラウドのメリットは以下の通りです：
- 初期投資が少ない（サーバー購入不要）
- 柔軟にスケール可能（アクセス増加に応じて即座に拡張できる）
- 保守管理の負担軽減（ハードウェアの故障対応などはクラウド事業者が担当）
AWSとは
AWS（Amazon Web Services）は、Amazon社が提供するクラウドサービスです。世界中で最も利用されているクラウドプラットフォームの一つで、200種類以上のサービスを提供しています。
AWSを利用すれば、数クリックで仮想サーバーを立ち上げたり、データベースを構築したり、ファイルを保存したりできます。従来は数週間かかっていたインフラ構築が、数分〜数時間で完了するようになりました。
国内外の多くの企業がAWSを採用しており、スタートアップから大企業まで幅広く利用されています。オプスインでも、お客様のWebアプリやモバイルアプリの開発において、AWSを活用した構成を数多く提案・構築してきました。
AWS構成図を読み解くための要素
構成図に出てくる主な要素
AWS構成図には、いくつかの基本的な要素が登場します。まずはこれらを押さえておきましょう。
リージョン
リージョンは、AWSのサービス提供拠点のことです。東京、大阪、アメリカ、ヨーロッパなど、世界各地に設置されています。
リージョンを選ぶ際の基準は主に2つです。
1つ目は応答速度（レイテンシー）です。ユーザーに近い場所を選ぶほど応答が速くなります。日本のユーザー向けサービスなら東京リージョンや大阪リージョンが適しています。
2つ目はデータ保存場所の法規制です。個人情報保護法や業界特有の規制により、データを国外に出せない場合があります。その場合は国内リージョン（東京または大阪）を選択する必要があります。
VPC（Virtual Private Cloud）
VPCは、AWS内の「自分専用のネットワーク空間」です。マンション全体の中で自分が借りている一室をイメージすると分かりやすいでしょう。
VPCを作ることで、他の利用者から隔離された、安全なネットワーク環境を構築できます。
サブネット
サブネットは、VPC内をさらに区切った「エリア」です。用途に応じて2種類に分けられます。
パブリックサブネットは、インターネットから直接アクセスできる場所です。Webサーバーなど、外部からのアクセスを受け付けるシステムを配置します。
プライベートサブネットは、インターネットから直接アクセスできない場所です。データベースなど、外部に直接公開したくないシステムを配置します。
これを住宅に例えるなら、パブリックサブネットは玄関・リビング（来客を受け入れる場所）、プライベートサブネットは寝室・倉庫（来客を入れない場所）のようなものです。
構成図の「流れ」を追う
構成図は、上から下、または左から右へ情報が流れる形で描かれることが多くなっています。
基本的な流れは、ユーザー → インターネット → AWS → データベースという順序です。矢印や線は「データの通り道」を示しています。
構成図を見る際は、この流れを意識しながら「ユーザーのリクエストがどこを通って、どこで処理され、どこにデータが保存されるのか」を追っていくと理解しやすくなります。
構成図に頻出するAWSサービスの役割
構成図によく登場する主要サービスの役割を解説します。各サービスがどんな役割を持っているのかを知れば、構成図が読みやすくなります。
サーバー関連
EC2（Elastic Compute Cloud）
EC2は、仮想サーバーのことです。アプリケーションを動かすための基本的な場所で、スペック（CPU、メモリ）を自由に選べます。
物理的なサーバーを購入・設置する代わりに、クラウド上で仮想的なサーバーを借りて利用するイメージです。必要に応じてスペックを変更したり、台数を増やしたりできる柔軟性があります。
Lambda
Lambdaは、サーバーレスでプログラムを実行できるサービスです。
「サーバーレス」という名前から「サーバーが不要」と誤解されることがありますが、実際にはサーバーは存在します。ただし、サーバーの管理（OSのアップデート、セキュリティパッチ適用など）をすべてAWSが担当してくれるため、利用者はサーバーを意識せずにプログラムを実行できる、という意味です。
Lambdaは、サーバーを常時稼働させず、必要な時だけプログラムを実行します。実行した分だけ課金されるため、小規模サービスやアクセス頻度が低いサービスに向いています。
データベース関連
RDS（Relational Database Service）
RDSは、マネージド型データベースサービスです。顧客情報や商品情報などを整理して保管する場所と考えてください。
「マネージド型」とは、バックアップや保守、セキュリティパッチの適用などをAWSが代行してくれるという意味です。データベースの運用負荷を大幅に軽減できます。
ストレージ関連
S3（Simple Storage Service）
S3は、容量無制限のオブジェクトストレージサービスです。画像、動画、ログファイルなど、静的なファイルの保存に最適です。
容量を気にせず大量のデータを保管でき、保存したデータに対して高い耐久性（データが失われにくい）を提供します。
ネットワーク・配信関連
ELB（Elastic Load Balancing）
ELBは、負荷分散装置です。受付カウンターで空いている窓口に案内する係をイメージすると分かりやすいでしょう。
アクセスが集中しても、複数のサーバーに振り分けて処理することで、システム全体の安定性を保ちます。
CloudFront
CloudFrontは、コンテンツ配信ネットワーク（CDN）サービスです。世界中のユーザーに高速でコンテンツを配信します。
ユーザーに近い拠点からデータを配信することで、表示速度を向上させます。画像や動画など、容量の大きいコンテンツを扱うサービスでは重要な役割を果たします。
Route 53
Route 53は、DNS（ドメイン名管理）サービスです。ドメイン名（example.com）をIPアドレスに変換する役割を担います。
ユーザーがブラウザにURLを入力すると、Route 53が該当するサーバーのIPアドレスを教えてくれる仕組みです。
セキュリティ・接続関連
インターネットゲートウェイ
インターネットゲートウェイは、VPCとインターネットをつなぐ「出入り口」です。パブリックサブネットに配置されたサーバーが外部と通信するために必要な要素です。
NATゲートウェイ
NATゲートウェイは、プライベートサブネットから外部への通信を可能にするサービスです。
インターネットゲートウェイを正面玄関に例えるなら、NATゲートウェイは裏口のようなものです。プライベートサブネットにあるデータベースなどが、外部からのアクセスは受け付けないが、自分からはソフトウェアのアップデートなどで外部へアクセスする、といった場合に使用します。
セキュリティグループ
セキュリティグループは、アクセス制御のルールを定義するものです。マンションの入館ルール（この人は入れる、この人は入れない）をイメージすると分かりやすいでしょう。
「このIPアドレスからのアクセスは許可」「このポートへのアクセスは拒否」といった細かいルールを設定できます。
実際の構成図を読んでみる｜代表的な3つのパターン
Webアプリやモバイルアプリでよく使われる構成パターンを3つ紹介します。それぞれの特徴と向いているケースを理解しておくと、開発パートナーからの提案内容を判断しやすくなります。
パターン①：Lambda + API Gateway（サーバーレス構成）
構成の特徴
この構成では、サーバーの管理が不要で、実行数に応じた課金となります。
Lambda（前述の通り、実際にはサーバーは存在しますがAWSが管理）でプログラムを実行し、API Gatewayを通じて外部からアクセスできるようにします。データベースにはDynamoDBやRDSを組み合わせることが一般的です。
向いているケース
- 小〜中規模のAPI
- バックエンド処理
- スタートアップや新規サービスの立ち上げ
アクセス頻度が低い場合や、アクセス数が予測しにくい初期段階のサービスに適しています。
注意点
Lambdaには実行時間の制限（最大15分）があります。また、初回実行時に起動に時間がかかる「コールドスタート」という現象が発生することがあります。
スタートアップ企業様向けのMVP開発や、既存サービスの一部機能追加などで、このサーバーレス構成を採用することがあります。
パターン②：ECS/Fargate + ELB（コンテナ構成）
構成の特徴
この構成では、コンテナと呼ばれる技術を使います。
コンテナとは、アプリケーションとその実行環境（必要なライブラリやミドルウェア）を1つのパッケージにまとめたものです。従来のサーバー構成では、サーバーを立ち上げてからOS、ミドルウェア、アプリケーションを順番にインストールする必要がありましたが、コンテナを使えばこれらがまとめて用意されているため、どこでも同じように動かせます。
引っ越しに例えるなら、従来は「新居に家具を1つずつ運んで配置する」のに対し、コンテナは「家具一式が入った箱ごと運ぶ」ようなイメージです。
ECS（Elastic Container Service）とFargateは、このコンテナを管理・実行するためのAWSサービスです。ELBと組み合わせることで、負荷分散や柔軟なスケーリングが可能になります。
向いているケース
- 中〜大規模Webアプリ
- モバイルアプリのバックエンド
- 継続的にアップデートが必要なサービス
開発環境と本番環境を同じコンテナで動かせるため、「開発では動いたのに本番で動かない」といったトラブルを減らせます。
注意点
適切なスケーリング設定が重要です。また、コストはEC2より高めになる傾向があります。
パターン③：EC2 + ELB（従来型サーバー構成）
構成の特徴
EC2（仮想サーバー）を直接使用し、ELBで負荷分散を行う構成です。従来のサーバー運用と同じ感覚で扱えます。
向いているケース
- レガシーシステムの移行
- 高度なカスタマイズが必要なケース
- 既存のオンプレミス環境をそのままクラウドに移したい場合
自由度が高く、サーバー内部を細かく調整できる点が特徴です。
注意点
OS・ミドルウェアの管理（セキュリティパッチ適用、アップデートなど）が必要で、運用負荷が高くなります。
構成図から読み取れる「コストのポイント」
構成図を見れば、どこにコストがかかるのかが分かります。運営担当者として押さえておきたいコスト構造を解説します。
主なコスト要素
AWSの料金は、使った分だけ支払う従量課金制が基本です。主なコスト要素は以下の通りです。
サーバー（EC2/ECS/Lambda）
- EC2/ECS：稼働時間で課金されます。サーバーを起動している時間が長いほどコストがかかります。
- Lambda：実行回数と実行時間で課金されます。使わない時間はコストがかからないため、アクセスが少ないサービスではコストを抑えられます。
データベース（RDS）
インスタンスサイズ（スペック）とストレージ容量で課金されます。必要以上に大きなインスタンスを選ぶと無駄なコストが発生します。
ストレージ（S3）
保存容量とデータ転送量で課金されます。大量の画像や動画を保存する場合は、ストレージコストが大きくなる傾向があります。
ネットワーク（データ転送）
外部への送信データ量で課金されます（受信は無料）。動画配信サービスなど、大量のデータを送信するサービスでは注意が必要です。
ロードバランサー（ELB）
稼働時間と処理データ量で課金されます。
コストを抑えるための視点
構成図を見る際、以下の視点でコスト最適化の余地がないか確認できます。
適切なインスタンスサイズの選択
過剰スペックのサーバーを使っていないか確認しましょう。実際の負荷に合わせて、適切なサイズを選ぶことが重要です。
不要なリソースの削除
テスト環境を立ち上げたまま放置していないか、使っていないストレージが残っていないか、定期的にチェックする習慣をつけましょう。
Reserved Instances（長期契約割引）の活用
1年〜3年の長期利用が確実な場合、Reserved Instancesを購入することで、通常料金の最大72%割引を受けられます。
S3のライフサイクル管理
古いデータは、安価なストレージクラス（Glacier等）へ自動的に移動させることで、ストレージコストを削減できます。
構成図から読み取る「障害対策」の考え方
システムの信頼性を確保するため、構成図には障害対策が組み込まれています。どこを見ればよいかを解説します。
アベイラビリティゾーン（AZ）の分散配置
アベイラビリティゾーン（AZ）は、同じリージョン内の物理的に離れたデータセンターのことです。同じ都市内に複数の支店を持つイメージです。
マルチAZ構成とは、複数のAZにシステムを分散配置することです。1つのAZが障害で停止しても、別のAZでサービスを継続できます。
構成図を見る際は、「AZ-1a」「AZ-1c」のように複数のAZにまたがって配置されているかを確認しましょう。マルチAZ構成になっていれば、基本的な冗長性が確保されていると判断できます。
データベースのバックアップとレプリケーション
RDSには自動バックアップ機能があり、指定した期間のデータを復元できます。
さらに、マルチAZ構成でRDSを設定すると、マスター（主）とスタンバイ（副）のデータベースが別々のAZに配置されます。マスターに障害が発生すると、自動的にスタンバイに切り替わる「フェイルオーバー」が行われます。
構成図でRDSが複数AZに配置されているかを確認すれば、データベースの冗長性が確保されているかが分かります。
リージョンをまたいだ災害対策（BCP）
より高いレベルの可用性(システムやサービスが停止することなく継続して稼働し、「必要な時にいつでも問題なく利用できる能力」のこと)を求める場合は、東京リージョンが災害で停止した場合に備え、大阪リージョンも活用する構成が考えられます。
パイロットライト構成は、平時は最小限のリソースで大阪リージョンを待機させておき、障害時に即座にスケールアップする方式です。コストと可用性のバランスを取った現実的な選択肢と言えます。
ただし、複数リージョンを使う構成はコストも高くなるため、サービスの重要度や事業継続の必要性を考慮して判断する必要があります。
インフラの基礎を押さえて、ビジネス判断の精度を高める
インフラ構成図は「専門家だけのもの」ではなく、運営担当者も読めるようになるべき情報と考えています。
リージョン、VPC、サブネット、そして主要サービス（EC2、Lambda、RDS、S3、ELBなど）の役割を理解すれば、構成図という「地図」が読めるようになります。
Lambda/ECS/EC2という代表的なパターンを知っておけば、開発パートナーからの提案内容の妥当性を判断できるようになります。
コストや障害対策の視点を持つことで、開発パートナーと対等な議論ができるようになり、「なぜこの構成なのか」「コストを抑える余地はないか」「障害時のリスクはどこにあるのか」といった重要な質問ができるようになります。
構成図が読めると、サービスのリスク把握やコスト最適化にも役立ちます。本記事で学んだ知識を活かして、ぜひ開発パートナーと建設的な対話を進めてください。
AWSインフラ構築でお困りの際は、オプスインにご相談ください。お客様のビジネスに最適な構成をご提案いたします。
