In Silico

クラウド

AWSとは？できることと仕組み、主要サービスをわかりやすく解説

2026/10/15 シリーズ「AWS 入門」 第1回 / 全2回

🤖 AIを使用して執筆

  • AWS
  • Amazon Web Services
  • AWS のサービス
  • 主要サービス
  • Well-Architected
  • リージョン
  • アベイラビリティーゾーン
  • プリミティブ
  • Lightsail
  • Amazon EC2
  • Amazon S3
  • AWS Lambda
  • Amazon DynamoDB
  • IAM
  • Amazon VPC
  • 東京リージョン
  • 大阪リージョン
  • 設計原則
  • Builders' Library
  • Werner Vogels
  • App Runner
  • クラウド
目次
背景・問い・要点
背景

クラウドの事業者は、計算機、ストレージ、データベース、ネットワークを、必要なときに必要な分だけ貸している。早くから始めた事業者は、貸すものを細かな部品に分け、その数を増やし続けてきた。

部品が多いと、作りたいものに合う組み合わせを選べる。その代わり、初めて使う人は、どこから読めばよいか、どれを選べばよいかが分からなくなりやすい。

問い

AWS とは何か。何ができ、どんな仕組みで動き、なぜ部品のような多くのサービスがあるのか。

要点

AWS は、使い方を一つに決めず、小さな部品（プリミティブ）を数多く提供して、組み合わせ方を利用者に委ねてきた。部品の多さは選ぶ負担にもなるため、AWS は組み立て済みのサービスと、判断の手がかりとなる設計の原則も公開している。

モデル・例示

配達の予約を受け付ける花屋のサイト

※ この節の数値は説明のための仮定で、測定値ではありません。

町の花屋が、花束の配達の予約をウェブで受け付けたいとする。必要なものは四つある。お客さんが見る注文の画面、注文を受けて確かめる処理、注文の記録、花束の写真の保管である。

一つ目の作り方は、仮想のサーバーを 1 台借りて、四つをすべてその中に入れることである。二つ目は、四つを別々の部品に分けることである。画面と写真はファイルを置く部品に、処理は要求が来たときだけ動く部品に、記録はデータベースの部品に置く。

  1. お客さん注文の画面1. 配達の日と花束を選ぶ
  2. 注文の画面注文の処理2. 注文を送る
  3. 注文の処理注文の記録3. 注文を書き込む
  4. 注文の処理注文の画面4. 受付の番号を返す
※概念図（やりとり）：本文の手順を図式化したもの。

二つ目の作り方では、母の日のように注文が増える日に、処理の部品だけを増やせる。その代わり、どの部品を選び、どうつなぐかを花屋が決めなければならない。AWS は、どちらの作り方のためのサービスも用意している。

AWS とは：Amazon が 2006 年に始めたクラウド

AWS（Amazon Web Services）は、Amazon が提供するクラウドである。Amazon の CTO（最高技術責任者）の Werner Vogels は、AWS の始まりを 2006 年 3 月 14 日の Amazon S3 の公開としている1。AWS の概要の文書は、200 を超えるサービスを、必要なときに数秒で使え、使った分だけ払う料金で提供すると説明している2。

使い始めるときは、AWS のアカウントを作る。AWS によれば、利用者の資源とデータはアカウントの中に収められ、アカウントは権限の管理の境界になる3。

日本では、2011 年 3 月に東京リージョンが開設された4。大阪には 2018 年に、災害対策の選択肢として、一つのデータセンターだけからなるローカルリージョンが置かれた。2021 年 3 月に、アベイラビリティーゾーンを三つ持つ通常のリージョンになった5。

AWS でできること：200 を超えるサービスの分類

AWS のサービスは、目的ごとに分類されている。AWS の概要の文書は、分析、アプリケーション統合、コンピューティング、コンテナ、データベース、機械学習と AI、ネットワーキングとコンテンツ配信、セキュリティ、ストレージなど、23 の分類を挙げている6。AWS の製品のページは 19 の分類を使っており、分け方は文書によって少し違う7。

分類のうち、多くの仕組みの土台になるのは次の五つである。主要サービスは、AWS の概要の文書の各分類のページから示す。

分類主要サービス
コンピューティングAmazon EC2（仮想サーバー）、AWS Lambda（要求が来たときだけ動く関数）、Amazon Lightsail8
ストレージAmazon S3（ファイルを置くストレージ）、Amazon EBS（仮想サーバーのディスク）9
データベースAmazon RDS、Amazon Aurora、Amazon DynamoDB10
ネットワーキングとコンテンツ配信Amazon VPC（仮想ネットワーク）、Elastic Load Balancing11
セキュリティ、アイデンティティ、コンプライアンスAWS Identity and Access Management（IAM、権限の管理）12

ウェブで注文を受け付ける仕組みなら、これらの組み合わせで作れる。注文の画面と写真を S3 に、注文の処理を Lambda に、注文の記録を DynamoDB に置き、誰が何を操作できるかを IAM で決める。

AWS の仕組み：リージョンとアベイラビリティーゾーン

AWS の設備は、世界の地域ごとのリージョンに分かれている。AWS によれば、AWS のクラウドは 39 のリージョンにまたがる 124 のアベイラビリティーゾーンからなる13。

アベイラビリティーゾーンは、一つ以上のデータセンターで、電源とネットワークの接続に予備を持っている。各リージョンには、互いに物理的に離れた三つ以上のアベイラビリティーゾーンがあり、ゾーンどうしは 100 km 以内にある13。東京リージョンには四つ、大阪リージョンには三つのアベイラビリティーゾーンがある14。

利用者は、使うリージョンを選び、その中で複数のアベイラビリティーゾーンに部品を分けて置くことで、一つの建物が止まっても動き続ける構成を作る。どの部品をどのゾーンに置くかも、利用者が決める。

AWS の設計の考え方：フレームワークではなくプリミティブ

AWS が部品の形でサービスを出す理由を、Vogels は 2016 年の「AWS の 10 年から学んだ 10 の教訓」に書いている。三つ目の教訓は「フレームワークではなくプリミティブ」である1。プリミティブは、それだけで役に立ち、ほかと組み合わせて使う基本の部品のことである。

Vogels によれば、AWS は早い段階で、顧客がサービスをどう使いたいかはまだ定まっていないと気づいた。データセンターの制約から離れた顧客は、誰も見たことのない使い方でシステムを作り始めたからである1。そこで AWS は、すべてが入った一つのフレームワークを使わせるのではなく、部品と道具を提供し、顧客が自分に合った使い方を選べるようにした1。Vogels は、後の世代の AWS のサービスも、顧客が使い慣れたのと同じ部品のサービスを使っていると書いている1。

部品の考え方は、ほかの教訓にもつながっている。四つ目の教訓「自動化が鍵」で、Vogels は、アプリを基本の部品に分け、それぞれに管理の API を持たせれば、自動化の規則で大きな規模でも安定して動かせると書く1。五つ目の「API は永遠」では、顧客が API の上にシステムを作り始めると、その API はもう変えられないと書いている1。利用者の側から見れば、一度使い始めた部品の使い方は、長く変わらないと期待できる。

部品の多さは、選ぶ負担にもなる

部品が多ければ、同じ目的に使えるサービスも増える。クラウドの費用を扱う会社 Duckbill の Corey Quinn は、2021 年に「AWS でコンテナを動かす 17 の方法」を書いた。17 という数は思いつきだと本人が断ったうえで、少なくとも、この苦しい決定に直面した人に示せる一つの場所ができたと結んでいる15。

AWS 自身も、組み立て済みのサービスを並べて提供している。2016 年に始めた Amazon Lightsail について、AWS のブログは、部品を一つずつ選んで組み立てたいときもあれば、組み立て済みですぐ動く仕組みが欲しいときもあると書いた16。Lightsail は、仮想サーバー、ストレージ、DNS の管理、固定の IP アドレスをまとめ、定額の料金で始められるサービスとして発表された16。

組み立て済みのサービスが、方針を変えることもある。AWS は 2021 年に、インフラの管理を不要にするサービスとして AWS App Runner を発表した17。AWS の文書によれば、App Runner は今は新しい顧客の受け付けをやめ、新しい機能も加えない予定である。既存の利用者はそのまま使え、AWS は別のサービスへの移行を勧めている18。組み立て済みのサービスは入りやすいが、このように方針が変わることもある。

判断の手がかり：Well-Architected の設計原則と Builders’ Library

部品の組み合わせ方を判断するときに、AWS 自身が公開している文書が二つある。

一つは AWS Well-Architected フレームワークで、設計をどう評価するかを示す。運用性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性の 6 本の柱を立てている19。柱とは別に、全体に共通する一般的な設計原則を六つ挙げている20。

  1. 容量ニーズを推測しない
  2. 本番の規模でシステムをテストする
  3. 実験を念頭に置いて自動化する
  4. 発展するアーキテクチャを考える
  5. データに基づいてアーキテクチャを決める
  6. 本番の障害を模した演習（ゲームデー）で改善する

一つ目の原則について、AWS は、必要な分だけ容量を使い、自動で増やしたり減らしたりできると書いている20。注文の多い日に処理の部品だけを増やす作り方は、この原則に沿っている。

もう一つは Amazon Builders’ Library で、Amazon がどのようにソフトウェアを作り、運用しているかを書いた記事を集めている21。たとえば、失敗した要求の再試行の間隔を少しずつずらす方法22や、一部の顧客の問題がほかの顧客に広がらないように分ける方法23、新しいコードを小さな範囲から順に出す方法24が書かれている。自社のサービスの作り方の記録だが、利用者が自分の構成を考えるときの参考にもなる。

部品をどう組み合わせるかは、利用者が決める

AWS は、使い方を決めつけないように部品を数多く提供し、組み合わせ方を利用者に委ねてきた。その結果、サービスは 200 を超え、選ぶ手間も増えた。AWS は、組み立て済みのサービスと、Well-Architected の設計原則や Builders’ Library のような手がかりで、この手間を減らそうとしている。

どの部品を選ぶにしても、部品はどれかのアカウントの中に作られる。誰が何をできるか、費用をどう分けるか、障害の影響をどこで止めるかは、アカウントをどう分けるかから決まり始める。

出典24件

  1. Werner Vogels「10 Lessons from 10 Years of Amazon Web Services」All Things Distributed、2016年3月11日、2026年10月15日取得. https://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html — 「Primitives not frameworks」ほか。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  2. AWS「Introduction」（Overview of Amazon Web Services）2026年6月2日、2026年10月15日取得. https://docs.aws.amazon.com/whitepapers/latest/aws-overview/introduction.html — 200 を超えるサービス。 ↩

  3. AWS「Organizing Your AWS Environment Using Multiple Accounts」2025年4月30日、2026年10月15日取得. https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html — アカウントは権限の管理の境界。 ↩

  4. AWS「Announcing the AWS Asia Pacific (Tokyo) Region」2011年3月2日、2026年10月15日取得. https://aws.amazon.com/about-aws/whats-new/2011/03/02/announcing-asia-pacific-tokyo-region/ ↩

  5. Jeff Barr「AWS Asia Pacific (Osaka) Region Now Open to All, with Three AZs and More Services」AWS News Blog、2021年3月1日、2026年10月15日取得. https://aws.amazon.com/blogs/aws/aws-asia-pacific-osaka-region-now-open-to-all-with-three-azs-more-services/ ↩

  6. AWS「Amazon Web Services の概要」（AWS のサービス）2026年6月2日、2026年10月15日取得. https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-overview/introduction.html — 目次の 23 の分類。 ↩

  7. AWS「クラウド製品」2026年10月15日取得. https://aws.amazon.com/jp/products/ — 製品のページの 19 の分類。 ↩

  8. AWS「コンピューティング」（Amazon Web Services の概要）2026年10月15日取得. https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-overview/compute-services.html ↩

  9. AWS「ストレージ」（Amazon Web Services の概要）2026年10月15日取得. https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-overview/storage-services.html ↩

  10. AWS「データベース」（Amazon Web Services の概要）2026年10月15日取得. https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-overview/database.html ↩

  11. AWS「ネットワーキングとコンテンツ配信」（Amazon Web Services の概要）2026年10月15日取得. https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-overview/networking-services.html ↩

  12. AWS「セキュリティ、アイデンティティ、コンプライアンス」（Amazon Web Services の概要）2026年10月15日取得. https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-overview/security-services.html ↩

  13. AWS「AWS Global Infrastructure」2026年10月15日取得. https://aws.amazon.com/about-aws/global-infrastructure/regions_az/ — リージョンとアベイラビリティーゾーンの数と定義。 ↩ ↩2

  14. AWS「AWS リージョン」（AWS Global Infrastructure ドキュメント）2026年10月15日取得. https://docs.aws.amazon.com/ja_jp/global-infrastructure/latest/regions/aws-regions.html — 東京と大阪のアベイラビリティーゾーンの数。 ↩

  15. Corey Quinn「The 17 Ways to Run Containers on AWS」Last Week in AWS、2021年5月26日、2026年10月15日取得. https://www.lastweekinaws.com/blog/the-17-ways-to-run-containers-on-aws/ ↩

  16. Jeff Barr「Amazon Lightsail – The Power of AWS, the Simplicity of a VPS」AWS News Blog、2016年11月30日、2026年10月15日取得. https://aws.amazon.com/blogs/aws/amazon-lightsail-the-power-of-aws-the-simplicity-of-a-vps/ ↩ ↩2

  17. AWS「AWS announces AWS App Runner」2021年5月18日、2026年10月15日取得. https://aws.amazon.com/about-aws/whats-new/2021/05/aws-announces-aws-app-runner/ ↩

  18. AWS「AWS App Runner availability change」2026年10月15日取得. https://docs.aws.amazon.com/apprunner/latest/dg/apprunner-availability-change.html — 新しい顧客の受け付けの終了（日付の記載なし）。 ↩

  19. AWS「フレームワークの柱」（AWS Well-Architected フレームワーク）2024年11月6日公開、2026年10月15日取得. https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/the-pillars-of-the-framework.html ↩

  20. AWS「一般的な設計原則」（AWS Well-Architected フレームワーク）2024年11月6日公開、2026年10月15日取得. https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/general-design-principles.html — 原則の名前は日本語版の見出しを平易に言い換えた。 ↩ ↩2

  21. AWS「Builders Library」AWS Builder Center、2026年10月15日取得. https://builder.aws.com/learn/topics/builders-library ↩

  22. Marc Brooker「Timeouts, retries, and backoff with jitter」Amazon Builders’ Library、2019年12月5日、2026年10月15日取得. https://builder.aws.com/content/3EumjoZascWd1oZiEgL8ORlv3qE/timeouts-retries-and-backoff-with-jitter ↩

  23. AWS「Workload isolation using shuffle-sharding」Amazon Builders’ Library、2019年12月5日、2026年10月15日取得. https://builder.aws.com/content/3F06NpJ8YeoIGP8VHTw4n81pFn8/workload-isolation-using-shuffle-sharding ↩

  24. Clare Liguori「Automating safe, hands-off deployments」Amazon Builders’ Library、2020年6月18日、2026年10月15日取得. https://builder.aws.com/content/3ErTKQOTKc5NIw031UePBPxTQ6I/automating-safe-hands-off-deployments ↩

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。