AWSとは？基礎知識から主要サービス・設計原則まで4つの視点で解説
はじめに
AWSは、企業のWebシステムや業務システム、データ活用基盤など、さまざまな場面で利用されている代表的なクラウドサービスです。一方で、これからAWSを学び始める方にとっては、リージョンやAZ、主要サービス、共有責任モデルなど、最初に理解すべき用語や考え方が多く、全体像をつかみにくいと感じることも少なくありません。
そこで本記事では、AWSを理解するうえで押さえておきたい4つの基礎知識として、グローバルインフラの考え方、共有責任モデル、主要サービスの全体像、そしてWell-Architected Frameworkの基本を整理して解説します。これからAWSを学ぶ方はもちろん、あらためて基礎を整理したい方にも役立つ内容です。
AWSのグローバルインフラ
AWSは、ユーザーに対して高可用性、最適なパフォーマンス、法規制順守の要件への対応を確保するため、世界中に自社のインフラを展開しています。この構造には、リージョン、アベイラビリティーゾーン（AZ）、およびエッジロケーションが含まれます。
リージョン（Region）とは
リージョンとは、AWSが自社のインフラを配置している、独立した物理的な地理的区域です。
主な特徴
- 完全な独立性: 各リージョンは互いに物理的に隔離されています。これにより、障害の独立性が確保されます。あるリージョンで発生した障害は、データ、サービス、または可用性の面で他のリージョンに影響を与えません。
- AZの集合: 各リージョンは、アベイラビリティーゾーン（AZ）の集合で構成されています。
- 識別コード: 各リージョンには一意の識別コードがあります（例: 北バージニアの us-east-1、シンガポールの ap-southeast-1）。
リージョンを選択する際の重要な考慮事項
AWS リソースを展開する際、リージョンの選択は最初の、そして最も重要なステップです。次の要素を考慮する必要があります:
- レイテンシー (Latency): アクセス時のレイテンシーを低減するため、エンドユーザーに最も近いリージョンを選択します（低レイテンシー = 高速な応答）。
- 法令順守 (Regulatory Compliance): 一部の法規制（例: EU の GDPR）では、データを特定の地理的な場所に保存することが求められます。
- サービスコスト: 同じ AWS サービスでも、リージョンによって料金が異なる場合があります。
AWS Cloud には現在、世界 33 の地理的リージョン (Regions) にまたがって 100+ の Availability Zones があります。
アベイラビリティーゾーン（Availability Zone）とは
アベイラビリティーゾーンとは、リージョン内にある 1 つ以上の独立したデータセンター (Data Center) です。1 つのリージョンには複数の AZ を含めることができます。
主な特徴
- 物理的な分離: AZ は互いに物理的に分離されており、通常は数マイル離れていますが、それでも同じリージョン内にあります。
- 独立したインフラストラクチャ: 各 AZ には独自の電源、ネットワーク、冷却設備があり、他の AZ における潜在的な障害（停電、洪水、火災など）から分離されています。
- 高速接続: 同一リージョン内の AZ は、高速で低レイテンシーの高耐障害性を持つ内部ネットワークで相互接続されています。
- 識別コード: AZはRegionコードに1文字を付けて識別されます（例: us-east-1a、us-east-1b、ap-southeast-1a）。
高可用性 (High Availability) の向上
ベストプラクティス: 高可用性 (High Availability) と災害復旧 (Disaster Recovery) を実現するには、重要なリソース（EC2サーバー、データベースなど）を、同一Region内の少なくとも2つのAZに必ず配置することを推奨します。
エッジロケーション（Edge Locations）の役割
Edge Locationsは、世界中に広く分散された小規模なデータセンターであり、その数はRegionやAZよりもはるかに多くなっています。
主な目的
- レイテンシーの削減: Edge Locationsは、可能な限りエンドユーザーに最も近い場所に配置されます。主な目的は、コンテンツやネットワークサービスをユーザーにより近づけることでレイテンシーを削減することです。
- アプリケーションの展開には使用しない: Region/AZとは異なり、Edge Locations上にアプリケーションや仮想マシン（EC2）を直接展開することはできません。
Edge Locationsを利用するサービス
Edge Locationsは主に次のサービスで使用されます:
| サービス | Edge Location における主な役割 |
|---|---|
| Amazon CloudFront | コンテンツ配信ネットワーク（CDN）。静的および動的コンテンツのキャッシュ保存に使用され、コンテンツの配信を高速化します。 |
| Route 53 | DNS サービス。ユーザーに最も近い場所で DNS 要求（IP アドレスの検索）を処理します。 |
| AWS Global Accelerator | AWS のバックボーンネットワークを使用してパフォーマンスを向上させ、トラフィックをアプリケーションへ最適にルーティングします。 |
CloudFront の例
- ハノイのユーザーが ap-southeast-1（シンガポール）に配置されたサーバーを持つウェブサイトにアクセスし、CloudFront を使用する場合、静的データ（画像、CSS）はハノイまたはホーチミン市の Edge Location にキャッシュされます。
- 次回のアクセス時には、コンテンツはこの Edge Location から直接配信されるため、シンガポールまで直接取りに行く必要がなく、レイテンシーが大幅に低減されます。
レイテンシー（Latency）
レイテンシーとは、リクエスト（request）を送信してから対応するレスポンス（response）を受け取るまでに必要な時間（通常はミリ秒 - ms で測定）です。
- 黄金原則: 低いレイテンシーは、より速いユーザー体験とより高いアプリケーション性能を意味するため、常に高いレイテンシーよりも優れています。
- AWS の戦略: Region/AZ と Edge Locations の構成は、レイテンシーを最小化し、ユーザーが AWS サービスへ迅速にアクセスできるように設計されています。
AWSの共有責任モデルとは
共有責任モデルは、AWS におけるセキュリティとコンプライアンス（security and compliance）の基本原則です。これは、Amazon Web Services (AWS) と顧客の間で、クラウドサービス利用時のセキュリティ責任を明確に分担するものです。
AWSが担う「Security of the Cloud」
AWSは、クラウドサービスを稼働させる基盤インフラストラクチャのセキュリティ確保と維持を担当します。これには以下が含まれます:
物理セキュリティ:
- 各リージョン（Regions）、アベイラビリティーゾーン（Availability Zones - AZs）、およびエッジロケーション（Edge Locations）。
- データセンター（data centers）、サーバー（servers）、ストレージ（storage）、ネットワーク機器（networking hardware）などの物理インフラストラクチャ。
- 電源、空調、および防火設備。
インフラストラクチャのセキュリティ:
- AWSサービスを稼働させるハードウェア、ソフトウェア、ネットワーク、およびインフラストラクチャ。
- サービスの高可用性（High Availability）と耐障害性を確保します。
- AWSのホストサーバー（基盤）システムのパッチ適用（Patching）と修正。
コンプライアンス（Compliance）：
- AWSは、世界中でコンプライアンスプログラムを維持しています（例：ISO 27001、SOC、PCI-DSS Level 1、HIPAA）。
利用者が担う「Security in the Cloud」
顧客は、AWSプラットフォーム上に配置、展開、設定するあらゆるもののセキュリティに責任を負います。
これは顧客が制御できる部分であり、ほとんどの潜在的なセキュリティリスクが発生する場所です:
データ管理：
- データ暗号化（Data Encryption） – 保存時のデータ（at rest）と転送中のデータ（in transit）の両方。
- データのバックアップ（Backup）。
- データ分類（例：公開、非公開、機密）。
アイデンティティとアクセス管理（IAM）：
- ユーザー（Users）、グループ（Groups）、ロール（Roles）、およびポリシー（Policies）の管理。
- 高い権限を持つユーザーに対して多要素認証（MFA）の使用を必須にする。
オペレーティングシステム（OS）およびアプリケーション：（特にEC2などのIaaSの場合）
- ゲストOS（Guest OS）の更新（Update）とパッチ適用（patch）。
- ウイルス対策ソフトウェア／マルウェア対策ソフトウェアをインストールする。
- アプリケーションおよびWebサーバーのファイアウォールを管理する。
ネットワーク構成：
- セキュリティグループ（仮想ファイアウォール）およびネットワークアクセスコントロールリスト（NACLs）を管理する。
- VPNを設定し、仮想プライベートクラウドVPC（Virtual Private Cloud）を構成する。
アプリケーションおよびコードのセキュリティ：
- アプリケーションコードに脆弱性がないようにする。
サービスによって責任範囲はどう変わるのか
責任分担の程度は、使用される AWS サービスの性質（IaaS、PaaS、SaaS）によって異なります。
| サービスの種類 | 例 | AWS の責任（より多い） | 顧客の責任（より多い） |
|---|---|---|---|
| IaaS | EC2、S3、VPC | ハードウェア、インフラストラクチャ | オペレーティングシステム、アプリケーション、データ、IAM、ネットワーク設定（SG/NACL）。 |
| PaaS | RDS、EKS、Elastic Beanstalk | OS、データベース管理、ホストシステムのパッチ適用 | データ、IAM、アプリケーション設定、データベース（RDS）の最適化。 |
| SaaS | S3、DynamoDB、Lambda | ほぼすべてのインフラ、OS、プラットフォーム | データ、アクセス権限（IAM）、サービスのセキュア設定。 |
重要な注意
- EC2 (IaaS): 顧客が最も多くの責任を負います。OSのパッチ適用とアプリケーションのインストールは自分で行う必要があります。
- RDS (PaaS): AWSがOSとデータベースのパッチ適用を管理します。顧客はデータ、DBパラメータ、最適化に集中できます。
- S3 (IaaS/SaaS): AWSが物理的なストレージ容量を管理する一方で、顧客はS3バケット上のアクセス権限（Bucket Policy/ACL）とデータの暗号化について完全に責任を負います。S3バケットを公開状態のままにすることは、典型的な顧客側のミスです。
AWSの主要サービス
AWSサービスに関するテーマは、柔軟で強力なクラウドコンピューティングの世界への入り口です。AWSは、コンピュート（EC2、Lambda）、ストレージ（S3、EBS）、データベース（RDS、DynamoDB）、ネットワーク（VPC、Route 53）といった主要カテゴリに分かれた包括的なツール群を提供しています。各サービス、ユースケース、そしてそれらの違いを正しく理解することが、最適でコスト効率が高く、拡張性のあるクラウドアーキテクチャを構築する鍵です。
Computeサービス
| サービス | 主なユースケース（アプリケーション） | 根本的な違い |
|---|---|---|
| EC2（Elastic Compute Cloud） | OS（オペレーティングシステム）、仮想マシン（VM）、またはサーバーレスとして実行できないワークロード（例: レガシーアプリケーション、非常に具体的なハードウェア/ソフトウェア構成が必要なもの）を完全に制御する必要があるアプリケーションを実行します。 | IaaS（Infrastructure as a Service）。OS、ランタイム、およびその上のすべてを管理します。サーバー管理（プロビジョニング、パッチ適用、スケーリング）が必要です。 |
| Lambda | 短時間のコード関数（15分未満）を実行し、イベントに反応します（例: S3へのアップロード直後に画像を処理する、シンプルなAPIのバックエンド）。 | FaaS（Function as a Service）/サーバーレス。必要なのはコードだけです。AWSがサーバー、OS、スケーリングに関するすべてを管理します。実際にコードが実行された時間（ミリ秒単位）に応じて課金されます。 |
| Elastic Beanstalk | 手動設定なしで、Java、Python、Node.js などのフルパッケージのWebアプリケーションを迅速にデプロイします。従来型のWebアプリケーションに最適です。 | PaaS（Platform as a Service）。必要なのはコード/設定の提供だけです。AWSがEC2、ロードバランサー、Auto Scalingを自動的に管理しますが、その下には依然として隠れたEC2サーバーがあります。 |
Storageサービス
| サービス | 主なユースケース（アプリケーション） | 根本的な違い |
|---|---|---|
| S3 (Simple Storage Service) | オブジェクトストレージ（Object storage）：画像、動画、バックアップ、データレイク。保存後に頻繁な変更を必要としないデータに適しています。 | オブジェクトストレージ：データはメタデータ付きのオブジェクトとして保存され、API（HTTP/HTTPS）経由でアクセスします。通常のディスクのようにOSにマウントすることはできません。最高レベルの耐久性（99.999999999%）を備えています。 |
| EBS (Elastic Block Store) | ブロックストレージ（Block storage）：EC2インスタンス向けのシステムディスク（Boot drive）およびデータディスク。 | ブロックストレージ：一度に1つのEC2インスタンスにのみ接続される物理ハードディスクのように動作します。OSやデータベースに最適です。 |
| EFS（Elastic File System） | ファイルストレージ（File storage）：複数のEC2インスタンス間で同時にファイルデータを共有する必要がある場合に使用します（例：Webサーバーのコンテンツ、共有の開発/テスト環境）。 | ファイルストレージ（NFS）：NFSプロトコルをサポートし、複数のEC2インスタンスが同時にマウントしてファイルの読み書きにアクセスできます。通常、Linux環境で使用されます。 |
| FSx | 特殊ファイルストレージ: 特定のワークロード向けにあらかじめ最適化された高性能ファイルシステムを提供します（例: FSx for Windows File Server、FSx for Lustre）。 | Managed File Storage: 特定の要件向けによく使われる、専用の高性能ファイルシステムです（例: Windows AD 互換、High-Performance Computing）。 |
| Storage Gateway | オンプレミスのデータセンターからAWS S3/EBSへデータをバックアップするためのキャッシュ、またはブリッジとして使用します。 | Hybrid Cloud: オンプレミス環境とAWSクラウド間でデータを接続し、移動するために使用します。 |
Databaseサービス
| サービス | 主なユースケース（アプリケーション） | 根本的な違い |
|---|---|---|
| RDS (Relational Database Service) | データの整合性（ACID）、複雑なリレーションシップ、リレーショナルデータベースを必要とする業務アプリケーション（例: ECサイト、在庫管理システム）。 | Managed Relational Database: AWSがパッチ適用、バックアップ、レプリケーションを管理します。サーバー上（EC2は隠蔽）に基づいていますが、OSは管理しません。 |
| DynamoDB | アプリケーションは、極めて高い速度、低レイテンシー、無限のスケーラビリティを必要とし、複雑なリレーショナルモデルは不要です（例: カート、ゲームのランキング、セッションの保存）。 | サーバーレスNoSQL（キー・バリュー/ドキュメント）: 自動スケール、高性能、サーバー管理不要、ストレージ容量と読み取り/書き込み回数に応じた従量課金。 |
| Redshift | 大量のデータ（テラバイトからペタバイト）を保存・分析するためのデータウェアハウス（データ倉庫）。BI（Business Intelligence）や複雑なレポートに使用します。 | カラムナーストレージ: 複雑な分析クエリ（OLAP）に最適化されており、データ列に対して高速です（日々のトランザクションではありません）。 |
Networkingサービス
| サービス | 主なユースケース（アプリケーション） | 根本的な違い |
|---|---|---|
| VPC (Virtual Private Cloud) | EC2、RDS などの AWS リソースを分離し、保護し、接続するための基本的なネットワーク基盤です。 | ネットワーク分離: 独自の仮想プライベートネットワークを作成し、IP 範囲、サブネット、および独自のセキュリティルール（Security Groups、ACLs）を定義します。 |
| Direct Connect | 高帯域幅で安定した、オフィス/data centerとAWS間の接続が必要です。公共のインターネットを迂回します。 | 専用物理リンク: 専用の物理接続で、Internet経由のVPNよりも低レイテンシーで、より一貫した帯域幅を提供します。 |
| Route 53 | ドメイン名システム（Domain Name System - DNS）の管理。トラフィックをAWSのリソースまたはAWS外のリソースへルーティングします。 | Managed DNS: グローバルDNSサービスで、スマートなルーティング機能（Latency-based routing、Failover、Geolocation）を提供します。 |
| API Gateway | バックエンドアプリケーション（EC2、Lambda）向けのAPI（REST/WebSocket）を作成、公開、保護、管理します。 | Managed API Layer: レート制限（throttling）、認証（authentication）、キャッシュなどの機能をAPIに提供し、通常はServerlessです。 |
| Global Accelerator | AWSのエッジロケーションネットワークを利用して、世界中のエンドユーザーのアクセスを高速化します。 | ネットワークパフォーマンス最適化: 静的IPアドレスとAWSのバックボーンネットワークを使用して、トラフィックを最も近い/最適なエンドポイントへルーティングします。CloudFront（コンテンツのみをキャッシュ）とは異なります。 |
AWS Well-Architected Frameworkの基本
AWS Whitepapersを押さえる重要性
AWSホワイトペーパーおよびReference Architectures（参考アーキテクチャ）は、Amazon Web Servicesによる正式で不可欠な資料です。ここでは、実証済みのガイダンスとベストプラクティスを見つけることができます。
ホワイトペーパーの重要性:
- クラウドシステム設計の原則: AWSクラウド上でシステムを構築するための基本原則について、深い洞察を提供します。
- 経験から得られた教訓: AWSおよび世界中の数百万の顧客からの実践的な経験をまとめています。
- Best Practices（ベストプラクティス）: AWSサービスを安全かつ効率的に、そしてコスト最適化して導入する方法を詳しく解説します。
AWS認定試験対策の重要ポイント:
特にSolutions ArchitectやCloud Practitionerなどの認定試験を学習する際は、以下の中核資料を優先して丁寧に読むべきです:
- AWS Well-Architected Frameworkホワイトペーパー: AWS上のあらゆるシステム設計の基盤となる資料。
- AWS セキュリティベストプラクティス: クラウド上のリソースとデータを保護する方法に関する重点資料。
AWS Well-Architected Frameworkとは
AWS Well-Architected Framework は、AWS 上で安全性、高パフォーマンス、耐障害性、効率性の高いシステムを構築するために設計された設計原則の集合です。
このフレームワークは、AWS 上のあらゆる workload（ワークロード）を設計・運用する際の評価基準として機能する 6 つの主要な柱（Six Pillars）で構成されています。
| 柱 | 主な定義 | 主なユースケース／関連 AWS サービス |
|---|---|---|
| 1. Operational Excellence（運用上の卓越性） | ビジネス価値を提供するためにシステムを実行および監視し、サポートするプロセスと手順を継続的に改善する能力。 | 自動化（Automation）、Amazon CloudWatch による監視（メトリクスとログを追跡するため）、AWS CloudTrail（API アクションを記録するため）、および失敗から学ぶ（Learning from Failure）。 |
| 2. セキュリティ | リスクと緩和戦略を評価することで、情報、システム、および資産を保護する能力。 | AWS IAM (Identity and Access Management) による最小権限 (Least Privilege) のアクセス権限付与。AWS KMS (Key Management Service) を使用して、保存データ (Data Protection) をデータ暗号化 (Encryption) することで、保存データを保護 (例: S3, RDS)。 |
| 3. 信頼性 | workload が意図した機能を正しく実行し、障害 (failure) から迅速に復旧する能力。 | Amazon RDS などのサービス向けに、Multi-AZ の高可用性システムを設計して自動フェイルオーバーを行うか、Auto Scaling Group を使用して必要なインスタンス数を維持します。 |
| 4. パフォーマンス効率 | システムの要求に対し、需要の変化に応じて電算資源を効率的に使用する能力。 | workload に最適な EC2 インスタンスタイプを選ぶなど、適切なリソース選択 (Right-sizing) を行う (例: ARM アーキテクチャベースの Graviton を使用して、コスト削減と一部 workload のパフォーマンス向上を図る)。 |
| 5. コスト最適化 | 不要な無駄な支出を避け、最も低いコストで最大のビジネス価値を実現する能力。 | 柔軟な料金モデルを使用します: Auto Scaling（負荷が少ないときにインスタンスを停止/削減するため）、Reserved Instances（RI）または Savings Plans（安定したワークロードに対して節約するため）、および Amazon S3 Intelligent-Tiering（ストレージ階層を自動的に切り替える）。 |
| 6. サステナビリティ | クラウド上での運用が環境に与える影響を最小限に抑えることに重点を置きます。 | より少ないリソースでシステムを設計する（例: 使用していないリソースを停止する、AWS Lambda のようなエネルギー効率の高いマネージドサービスを使用する）とともに、AWS インフラストラクチャのエネルギー効率を活用します（例: AWS データセンターが再生可能エネルギーを使用していること）。 |
重要な警告:
- 各柱には、しばしば相互にトレードオフがあります。たとえば、セキュリティの強化（例: 認証手順を増やすこと）は、パフォーマンスや運用上の優秀性に影響を及ぼす可能性があります（例: デプロイプロセスを複雑化させること）。
目標は、具体的なビジネス要件に基づいて、6つの柱の間で最適なバランスを見つけることです。
まとめ
AWSを理解するためには、個別のサービス名だけを覚えるのではなく、まずは全体の構造と基本的な考え方を押さえることが大切です。リージョンやAZ、エッジロケーションといったグローバルインフラの仕組みを理解することで、可用性やレイテンシーの考え方が見えやすくなります。また、共有責任モデルを知ることで、AWSと利用者の役割分担を正しく理解し、より安全にクラウドを活用しやすくなります。
さらに、Compute、Storage、Database、Networkingといった主要サービスの違いを把握すれば、要件に応じたサービス選定がしやすくなります。加えて、Well-Architected Frameworkの視点を持つことで、安全性、信頼性、性能、コストなどをバランスよく考えた設計につなげやすくなります。AWSはサービス数が多く一見複雑に見えますが、基礎を整理して理解すれば、クラウド活用の判断もしやすくなります。まずは今回紹介した4つのポイントを起点に、AWSの理解を広げていきましょう。
関連記事
AWSについてさらに理解を深めたい方は、以下の記事も参考にしてください。