# Amazon Web Services クラウドプロバイダ(AWS)。2009 年の [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]] では、Amazon EC2(x86 ISA を Xen VM で仮想化する「薄い」API、1.0GHz スライス $0.10/時間)と Amazon S3(ストレージ $0.12〜0.15/GB・月)が Utility Computing の代表例として分析されている。同論文はAWS を「開発者がカーネルからスタック全体を制御できる、仮想化レベルのスペクトルの低水準端」に位置づけ、Google AppEngine(高水準・完全管理)や Microsoft Azure(中間的)と対比した。75 台の EC2 インスタンスで実測された VM 間の I/O 性能干渉(ディスク書き込み帯域の変動係数 16% 超)は、この論文が挙げる「性能の予測不可能性」という障害の具体的な実証データである。 本 wiki では [[NSync]]([[@2025__arXiv__Automated Cloud Infrastructure-as-Code Reconciliation with AI Agents]])の共同研究機関として登場し、Hui Guan・Victor Nicolet・Brandon Paulsen・Joey Dodds・Daniel Kroening らが [[University of Michigan]] と共同で IaC reconciliation を研究した。 NSync は AWS のサービス群を基盤に動く: API トレースは [[AWS CloudTrail]]、backbone LLM は AWS Bedrock 経由の Claude 3.7 Sonnet、クラウド接続は Boto3。drift 注入シナリオの主な出典も AWS Systems Manager(SSM)Automation runbook。 本 wiki の別文脈として、AIOps/時系列研究の文脈でも登場する。[[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]] の第 3 著者 [[Mononito Goswami]] の所属が AWS(Seattle)。ただし脚注で本研究は Amazon での職務と無関係と明記される。 データベースシステムの文脈では、AWS は [[Aurora Limitless Database]] を開発・運用する組織として登場する。同システムは Amazon Aurora PostgreSQL をルータ/シャード構成の分散 OLTP データベースへ拡張し、Amazon Time Sync Service、Aurora Serverless V2、Aurora 分散ストレージを統合して、PostgreSQL 互換性と強い整合性を維持した水平スケーリングを狙う。([[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]]) 時系列基盤モデルの文脈では、傘下の [[AWS AI Labs]] が Chronos([[@2024__arXiv__Chronos Learning the Language of Time Series]]、TMLR 2024)・汎用時系列予測基盤モデル [[Chronos-2]](arXiv:2510.15821)を開発・公開した。Chronos は時系列値をスケーリング + 均一量子化でトークナイズし T5/GPT-2 そのままで確率的予測基盤モデルを構成するフレームワーク。Chronos-2 は group attention 機構により単変量・多変量・共変量付き予測を単一モデルでゼロショット処理する初の TSFM で、fev-bench・GIFT-Eval・Chronos Benchmark II の 3 ベンチマーク全てで当時の SOTA を達成した。中心的な研究者は [[Abdul Fatir Ansari]]・[[Lorenzo Stella]]・[[Oleksandr Shchur]]・[[Yuyang Wang]] ら。([[@2025__arXiv__Chronos-2 - From Univariate to Universal Forecasting]])Chronos-2 は group attention 機構により単変量・多変量・共変量付き予測を単一モデルでゼロショット処理する初の TSFM で、fev-bench・GIFT-Eval・Chronos Benchmark II の 3 ベンチマーク全てで当時の SOTA を達成した。中心的な研究者は [[Abdul Fatir Ansari]]・[[Oleksandr Shchur]]・[[Yuyang Wang]] ら。([[@2025__arXiv__Chronos-2 - From Univariate to Universal Forecasting]]) Vista の文脈では、Amazon RDS フリートで大規模展開された ML ベース性能トラブルシューティングフレームワークの開発組織として登場する。Vista は [[Vikramank Singh]]・Zhao Song・Balakrishnan (Murali) Narayanaswamy・Kapil Eknath Vaidya および [[Tim Kraska]] (MIT 兼任) により開発。数十万 RDS インスタンスで 2 年以上稼働し、毎日 >10K の偽アラームを防止してきた。Amazon DevOps Guru for RDS の機能として公開されている。([[@2023__Amazon Science__Vista - Machine Learning based Database Performance Troubleshooting Framework in Amazon RDS]]) ストレージノード検証の文脈では、AWS は Amazon S3 の新しいキーバリューストレージノード [[ShardStore]] を軽量形式手法(参照モデル + property-based testing + stateless model checking)で検証した開発組織として登場する。筆頭著者 [[James Bornholt]] ほか AWS 所属の研究者陣が本番投入前に 16 件の不具合を検出し、検証アーティファクトの保守を段階的にエンジニアリングチームへ引き継いだ。([[@2021__SOSP__Using Lightweight Formal Methods to Validate a Key-Value Storage Node in Amazon S3]]) サードパーティのクラウドデータウェアハウスの文脈では、AWS は [[Snowflake Computing]] が [[@2016__SIGMOD__The Snowflake Elastic Data Warehouse]] を稼働させる基盤プラットフォームとして登場する。同論文は AWS 選定理由として「最も成熟したクラウドプラットフォームであること」「最大の潜在ユーザープールを持つこと」の2点を挙げ、ストレージに Amazon S3、鍵管理の root key に AWS CloudHSM を利用する。Snowflake 自身は AWS の関連会社ではなく AWS 上に構築された第三者のクラウドデータウェアハウスであり、AWS が開発する [[Aurora Limitless Database]] とは別の組織・別のアーキテクチャ思想(Aurora はシェアードナッシング寄りのシャーディング拡張、Snowflake はストレージ・コンピュート分離のマルチクラスタ・シェアードデータ)である点に注意。 大規模モデル訓練の耐障害性の文脈では、AWS は [[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]](SOSP '23)の共同研究組織として登場する。同論文は [[Rice University]] の [[Zhuang Wang]]・[[T. S. Eugene Ng]] と AWS 所属の Zhen Jia・Shuai Zheng・Zhen Zhang・Xinwei Fu・Yida Wang による共著で、GPU マシンの CPU メモリへ毎イテレーションチェックポイントすることで障害復旧を 13 倍超高速化する。評価は AWS EC2 の p4d.24xlarge(NVIDIA A100)・p3dn.24xlarge(NVIDIA V100)インスタンス上で行われ、Amazon EC2 Auto Scaling Groups(ASG)を用いた障害マシンの自動置換と連携する。 ネットワーク根本原因分析の文脈では、AWS の Fabien Chraim・Dominik Janzing・John Evans らのチームが 2026-06-11 に同時投稿した2本の姉妹論文が登場する。[[@2026__arXiv__Graphical Causal Reasoning for Root Cause Analysis in Cloud Networks]] は Granger 因果性 + 条件付き独立性検定による因果グラフ構築で(35件評価・完全一致74.3%)、[[@2026__arXiv__NetCause - Counterfactual Learning for Root Cause Analysis in Large-Scale Networks]] は R-GCN + RNN の生成的時空間モデルと反実仮想シミュレーションで(31件評価・完全一致35.5%)、同一チームが同時期に統計的因果発見と学習ベース反実仮想シミュレーションという異なる方法論をクラウドネットワーク RCA に適用した対をなす。 ベクトル検索インデックスの文脈では、AWS は [[Zhiying Xu]] の所属組織として [[@2025__arXiv__LEANN - A Low-Storage Vector Index]] の共著者リストに登場する。同論文は本研究が Amazon での職務と無関係であることを脚注で明記しており、[[University of California, Berkeley]]・[[The Chinese University of Hong Kong]]・[[University of California, Davis]] との共同研究として、ストレージ効率型ベクトルインデックス LEANN(MLSys 2026 Oral)を発表した。 LLM エージェントによる AI アクセラレータカーネル最適化の文脈では、AWS は [[AWS Trainium]]・[[Neuron Kernel Interface (NKI)]] の提供元として、[[Stanford University]] の [[Genghan Zhang]]・[[Anjiang Wei]]・[[Kunle Olukotun]] と共同で AccelOpt を開発した([[@2026__MLSys2026__AccelOpt - A Self-Improving LLM Agentic System for AI Accelerator Kernel Optimization]])。AWS 側の共著者 Shaowei Zhu・Zhenyu Song・Allen Nie・[[Zhen Jia]]・[[Nandita Vijaykumar]]・[[Yida Wang]] のうち、[[Zhen Jia]] と [[Yida Wang]] は [[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]](SOSP '23、[[Rice University]] との共著)にも AWS 所属の共著者として名を連ねており、大規模訓練の耐障害性研究(Gemini)とカーネル最適化研究(AccelOpt)という異なるテーマにまたがって AWS 内の同じ研究者が寄与していることが分かる。 2010年前後の実務者視点では、AWS は『ウェブオペレーション』2章([[Justin Huff]]執筆)が語る[[Picnik]]のハイブリッド構成の一方の柱として登場する。Picnikは2007年5月にクラウドを試用し始め、同年12月からAmazon S3にユーザ生成ファイルを保存、その後Amazon EC2でレンダーサーバ(画像処理)を稼働させた。S3では結果整合性(書き込み直後の読み取り非保証)とパーティションメンテナンスに由来するHTTP 500エラーの局所的爆発に、EC2では[[Xen]]ベースのAMIパッケージングとキュー駆動のオートスケーリング(自家製構成管理システム[[ServerManager]])に、それぞれ直面・対応した実例が記録されている。本章はまた、当時のAWSに欠けていたものとして、EC2のディスクI/O性能の低さ(データベースサーバをクラウド化しない理由)とマネージドロードバランサの不在を明記する(訳注によれば、その後Amazon RDS(2009年10月)・Elastic Load Balancingが提供された)。2009年の[[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]]がEC2・S3を経済モデル・性能実測の観点から分析したのとほぼ同時期に、2章はほぼ同じ2つのサービスを実務者の視点(障害対応・コスト・運用設計)から記録しており、学術的position paperと実務者エッセイという異なる視点が同じ時代のAWSの姿を補完的に描く。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]]) ## クラウド経済性とWSCの規模の経済(『Computer Architecture: A Quantitative Approach』6章) James Hamilton(元Microsoft、AWS VP/Distinguished Engineer)の2006年の比較研究によれば、WSC規模のデータセンターは1000台規模の従来型データセンターに対し、ストレージコストで5.7倍(GBあたり年$4.6 対 $26)・管理者あたりサーバ数で7.1倍(1000台超 対 140台)・ネットワーク帯域コストで7.3倍(Mbit/s/月あたり$13 対 $95)の優位を持つ。この規模の経済がAWSのようなクラウド事業の経済的基盤である。(Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]] §6.5) [[Amazon EC2]]は2006年に$0.10/時間/インスタンスという低価格で開始し、2017年時点でインスタンスタイプは50種類超に拡大した(汎用・コンピュート最適化・GPU・FPGA・メモリ最適化・ストレージ最適化の6区分)。Spot Instance(需給連動の変動価格、オンデマンドの約25%)とReserved Instance(年間契約、オンデマンドの約65%相当)の2つの割引モデルを提供する。2014年にAWSはLambdaを発表し、ユーザーが関数コードを提供するだけでOS保守・容量計画・自動スケーリングをAWS側が担うサーバレスコンピューティングを実現した。課金粒度は100ミリ秒単位でEC2の時間単位より6桁細かい。(Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]] §6.5) 2017年時点でAWSは16の地域(リージョン)・42のアベイラビリティーゾーンを持ち、各ゾーンに1つ以上のWSC(各50,000〜80,000台超)を配置する。Hamilton(2017)は「1リージョンあたり最低3つのWSC」を推奨する——2拠点構成では障害時に各拠点が容量の50%を予備に残す必要があるが、3拠点なら2/3稼働のまま同水準のフェイルオーバー耐性を確保できるためである。2014〜2016年のAWS設備投資からの逆算では、1WSCあたりの建設コストは3.1億〜4.7億ドルと推定される。(Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]] §6.5) AWSは2016年時点で売上122億ドル・営業利益率25%を記録し、Amazonの小売部門(営業利益率3%未満)を大きく上回る収益性を持つ。低価格ゆえに赤字だという当初の懐疑を覆し、Amazonの利益の4分の3をAWSが生み出している。(Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]] §6.8) 本ページ既出の[[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]](2009年)がEC2・S3を「仮想化レベルのスペクトルの低水準端」に位置づけた分析と比較すると、本章(2019年出版・2017年時点データ)はEC2の分析を経済モデルの記述からさらに進め、実際のインスタンスカタログ(50種類超)・Spot/Reserved割引・サーバレスコンピューティングへの発展という8年間の具体的な進化を記録しており、同じAWS EC2という対象を異なる時点の粒度で捉えた相補的な資料になっている。(Source: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]], [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]]) ## 関連 - ソース: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]] - ソース: [[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]] / [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]] / [[@2025__arXiv__Automated Cloud Infrastructure-as-Code Reconciliation with AI Agents]] / [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]] / [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]] / [[@2025__arXiv__Chronos-2 - From Univariate to Universal Forecasting]] / [[@2023__Amazon Science__Vista - Machine Learning based Database Performance Troubleshooting Framework in Amazon RDS]] / [[@2024__SIGMOD__Amazon MemoryDB - A Fast and Durable Memory-First Cloud Database]] / [[@2016__SIGMOD__The Snowflake Elastic Data Warehouse]] / [[@2026__arXiv__Graphical Causal Reasoning for Root Cause Analysis in Cloud Networks]] / [[@2026__arXiv__NetCause - Counterfactual Learning for Root Cause Analysis in Large-Scale Networks]] / [[@2025__arXiv__LEANN - A Low-Storage Vector Index]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]] - 概念: [[Infrastructure as Code]] / [[時系列質問応答]] / [[分散 PostgreSQL]] / [[時系列基盤モデル]] / [[多変量時系列予測]] / [[データベース自律診断]] / [[データベース性能トラブルシューティング]] / [[ストレージ計算分離]] / [[インメモリデータベース]] / [[シェアードナッシング]] / [[ハイブリッドクラウド]] / [[クラウドコンピューティング]] - エンティティ: [[Amazon EC2]] / [[James Hamilton]] / [[NSync]] / [[AWS CloudTrail]] / [[Terraform]] / [[University of Michigan]] / [[Mononito Goswami]] / [[Aurora Limitless Database]] / [[Chronos-2]] / [[Abdul Fatir Ansari]] / [[Oleksandr Shchur]] / [[Yuyang Wang]] / [[Vikramank Singh]] / [[Tim Kraska]] / [[Amazon MemoryDB]] / [[Yacine Taleb]] / [[ShardStore]] / [[James Bornholt]] / [[Snowflake Computing]] / [[Rice University]] / [[Zhuang Wang]] / [[T. S. Eugene Ng]] / [[Picnik]] / [[Justin Huff]] / [[ServerManager]] / [[MogileFS]] / [[Xen]]