Upgrade to Pro — share decks privately, control downloads, hide ads and more …

昔話で振り返るAWSの歩み ~S3誕生から20年、クラウドはどう進化したのか~

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers.

昔話で振り返るAWSの歩み ~S3誕生から20年、クラウドはどう進化したのか~

Avatar for NRI Netcom

NRI Netcom PRO

March 25, 2026
Tweet

More Decks by NRI Netcom

Other Decks in Technology

Transcript

  1. 1 Copyright(C) NRI Netcom, Ltd. All rights reserved. 自己紹介 ◼

    2000年 4月 NRIネットコム株式会社入社 ◼ 現在 執行役員 デジタルソリューション事業本部長 クラウドテクニカルセンター センター長 佐々木拓郎 ◼ 執筆
  2. 2 Copyright(C) NRI Netcom, Ltd. All rights reserved. NRIネットコムのAWSへの取り組み APNアドバンスド

    コンサルティングパートナー 複数のAWS Award受賞者と 多数のAWS認定資格者 書籍&ブログ執筆 ハッシュタグ #nncstudy
  3. 3 Copyright(C) NRI Netcom, Ltd. All rights reserved. 関連書籍の紹介 S3とクラウドの歴史に迫る2冊

    S3を使う上で知っておくべきことを まとめた本(2025年執筆) AWSの発展を横からみてきた 感想のまとめ ハッシュタグ #nncstudy
  4. 4 Copyright(C) NRI Netcom, Ltd. All rights reserved. 最初に ハッシュタグ

    #nncstudy 本日の話は、 AWSを外から見続けてきた個人の視点です。 公式情報や開発者のブログ等を参考にしていますが、 AWSの公式見解でも、 NRIネットコムとしての公式見解でもありません
  5. 5 Copyright(C) NRI Netcom, Ltd. All rights reserved. 1. S3

    20周年 クラウドの「当たり前」を疑う
  6. 6 Copyright(C) NRI Netcom, Ltd. All rights reserved. 2026年3月14日は何の日でしょう? 2026年3月14日は何の日でしょう?

    答え Amazon S3 誕生から 20周年 2006年3月14日 Amazon S3 General Availability(正式サービス開始) 500兆+ 保管オブジェクト数 数億/秒 処理リクエスト数 数百EB 保管データ量 ハッシュタグ #nncstudy
  7. 7 Copyright(C) NRI Netcom, Ltd. All rights reserved. クラウドは「当たり前」になった ①

    サーバーを持たずに システムを作る ② 容量を気にせずに データを保存する ③ インフラをコードで 定義・構築する(IaC) でも、これは 最初から「当たり前」ではなかった ハッシュタグ #nncstudy
  8. 8 Copyright(C) NRI Netcom, Ltd. All rights reserved. 今日のゴール AWSの設計思想の「なぜ」を理解する

    昔の設計の話が、今の設計に直結していることを実感する 初心者の方 クラウド設計思想を理解するヒントを持ち帰る ベテランの方 懐かしい昔話に浸りながら、今と比較してみる ハッシュタグ #nncstudy
  9. 9 Copyright(C) NRI Netcom, Ltd. All rights reserved. 2. AWSの原点

    なぜAmazonはクラウドを作ったのか
  10. 10 Copyright(C) NRI Netcom, Ltd. All rights reserved. The Bezos

    Mandate(2002年ごろ)― すべてはここから始まった ⚫ すべてのチームはサービスインターフェース(API)を通じてデータと機能を公開せよ ⚫ チームはAPIを介してのみ通信せよ ⚫ 直接リンク・データストアの直接読み込み・共有メモリ・バックドアは一切禁止 ⚫ 使う技術は何でもよい(HTTP / Corba / 独自プロトコル — 何でも可) ⚫ すべてのAPIは外部公開可能な設計にせよ ⚫ これをしない者はクビになります ⚫ ありがとう、良い一日を ハッシュタグ #nncstudy 元Amazonエンジニア Steve Yegge氏による回想
  11. 11 Copyright(C) NRI Netcom, Ltd. All rights reserved. ベゾスの指令 ―

    「インターネットのmallocを作れ」 "Jeff Bezos' original spec for S3 was very succinct – he wanted malloc (a key memory allocation function for C programs) for the Internet." — Jeff Barr のブログより mallocとは ma llo c C言語でメモリ領域を確保する最もプリミティブな関数 使う前に何GBか考えなくていい、必要なだけ確保できる ベゾスのビジョン S3 = インターネットにおける プリミティブなストレージ 「どのサービスからでも、必要なだけ使えるストレージ」 S3 = インターネットの malloc ほぼすべてのAWSサービスの基盤にS3が存在する ― 20年後に現実になった ハッシュタグ #nncstudy
  12. 12 Copyright(C) NRI Netcom, Ltd. All rights reserved. 2006年3月14日、S3登場 ―

    当時の衝撃 2006年(当時) 2026年(現在) ストレージ料金 $0.15 / GB / 月 $0.023 / GB / 月 転送料金(IN) $0.20 / GB(課金あり) 無料 転送料金(OUT) $0.20 / GB $0.09 / GB〜 物価水準 基準 +60%上昇 (米国 CPI ベースでは)物価が6割上がっても、料金は 6分の1以下 「容量を気にせず、APIでストレージが使える」 「オンラインで契約して、すぐ使い始められる」 「AmazonがITインフラを売り始めた…?」 ハッシュタグ #nncstudy
  13. 13 Copyright(C) NRI Netcom, Ltd. All rights reserved. なぜストレージサービスが、コンピューティングより先に出たのか 理由①

    Amazonのeコマース自身が必要としていた • 商品画像・動画など大量のオブジェクトデータを低コスト・高信頼で保存し たかった • 既存のオブジェクトストレージはAmazonのスケールに対応できなかった → 自前で作ることにした 理由② Amazonにとって、EC2より優先度が高かった(模様) • EC2(仮想サーバー)よりもS3(分散オブジェクトストレージ)の方が技術 的難易度が高い • 先に完成させたことが、その後のAWS全サービスの基盤になった S3 → EC2 という順序が、 クラウドの設計思想の形を決めた ハッシュタグ #nncstudy
  14. 14 Copyright(C) NRI Netcom, Ltd. All rights reserved. S3のコンセプト ―

    オブジェクトストレージとは ブロックストレージ(EBS) ファイルストレージ(EFS) オブジェクトストレージ(S3) 単位 ブロック ファイル オブジェクト(データ+メタデータ+ID) 構造 物理ディスクに近い 階層ツリー フラット(擬似階層) 更新 部分書き込み可 部分書き込み可 オブジェクト全体の置き換え 主な用途 OS・DB 共有ファイル 画像・動画・ログ・バックアップ バケット名(グローバル一意) └── キー(プレフィックス + オブジェクト名) └── オブジェクト(データ本体+メタデータ+ID) 「Simple」に込められた意味 多機能でも、設計の根幹はキーバリューストアのシンプルさを崩さない ハッシュタグ #nncstudy
  15. 15 Copyright(C) NRI Netcom, Ltd. All rights reserved. S3が持っていた5つの設計原則 ―

    20年後も変わっていない ① スケーラブル 容量を事前に決めない。 必要な分だけ使う ② 信頼性が高い 99.999999999% (11個の9)の耐久性 ③ 高速 APIレスポンスの スループット重視 ④ 安価 20年で料金1/6以下に ⑤ シンプル プリミティブな操作に徹する 2006年に定められたこの5原則は、 2026年も S3 の設計思想の中心にある ハッシュタグ #nncstudy
  16. 16 Copyright(C) NRI Netcom, Ltd. All rights reserved. (小咄)「AWS」という名前は、もともと別のサービスのものだった トリビア①

    AWS(単数形)は別サービスで存在していた Amazon Web Service(単数) Amazon Product Advertising API(現在の名称) Amazonの商品データをAPIで取得するサービス もう一つのAlexa Alexa Web Information Service (Webトラフィック情報をAPI提供) 2022年5月1日終了 トリビア② ハッシュタグ #nncstudy
  17. 18 Copyright(C) NRI Netcom, Ltd. All rights reserved. EBS登場(2008年8月)が変えたもの 2006.08

    EC2 β公開 ― インスタンスストアのみ・VPCなし 2008.08 EBS登場 ― EC2に永続ブロックストレージが付いた 2008.10 EC2 GA(正式リリース)― EBSがあってこそ 2009.05 ELB + Auto Scaling 登場 2009.08 VPC登場 ― ネットワーク分離が可能に ハッシュタグ #nncstudy
  18. 19 Copyright(C) NRI Netcom, Ltd. All rights reserved. 2011年US-EAST-1大規模障害 この障害がAWSのみならず、利用者にとっても、クラウドを安全

    に使うにはどう設計すべきかを考える契機になった 何が起きたか • 2011年4月21日 深夜に発生 • ヒューマンエラーがトリガー • EBSのネットワーク再構成処理が連鎖障害に • RDS・EC2・Beanstalkなど多数が影響 • 大手サービス(Reddit・Foursquare等)がダウン AWSの対応・透明性 詳細なポストモーテムを公開 障害の根本原因を包み隠さず説明 EBSの内部構造(SDS)が垣間見えた 「透明性がクラウド信頼の礎」 ハッシュタグ #nncstudy
  19. 20 Copyright(C) NRI Netcom, Ltd. All rights reserved. (小咄)s3fs ―

    ユーザー主体の当時の試行錯誤 「S3をファイルシステムとしてマウントしたい」― その夢を叶えようとしたツール s3fs s3fsとは • FUSE(Filesystem in Userspace)を使いS3をマウント • 「ls」「cp」「vi」でS3を操作できるように • ただし……パフォーマンスは壊滅的に遅い • ランダムアクセス・append書き込みは不得意 • AWS公式のサービスではなく、オープンソースプロジェクト なぜうまくいかないのか オブジェクトストレージ≠ファイルシステム 上書き = オブジェクト全体の再アップロード ディレクトリ概念がない(プレフィックス) 整合性モデルが異なる その後の答え: EFS・FSx • EFS(2015年): フルマネージドNFSとして登場 • FSx for Lustre(2018年): HPC向け高速ファイルシステム • 「正しい道具を使う」文化への布石となった ハッシュタグ #nncstudy
  20. 22 Copyright(C) NRI Netcom, Ltd. All rights reserved. S3 20年年表(2006-2026)

    2006 S3 GA・EC2 β ― クラウドの夜明け 2008 EBS登場・EC2 GA ― 永続ストレージ実現 2009 ELB/AutoScaling・VPC ― 本格的なクラウドインフラへ 2010 IAM登場 ― マルチユーザー管理が可能に 2013 CloudTrail ― 企業採用の転換点 2015 S3の書き込み後読み込み整合性(us-east-1以外) 2018 S3 Intelligent-Tiering・FSx 2020 S3 強整合性(Strong Consistency)完全対応 2023 S3 ACL非推奨 ― アクセス制御をシンプルに 2024 S3 Tables(Apache Iceberg統合) 2025 S3 Vectors(AI時代の新ストレージ) ハッシュタグ #nncstudy
  21. 23 Copyright(C) NRI Netcom, Ltd. All rights reserved. S3の整合性の20年進化 2006

    結果整合性(Eventual Consistency)― 書いても即読めない 2009 書き込み後の読み込み整合性(新規PUTのみ・us-east-1以外) 2015 us-east-1でも書き込み後読み込み整合性が適用 2020 強整合性(Strong Consistency)― すべての操作で即座に最新値 • 結果整合性時代のコード: リトライ・遅延読み込みが必須だった • 強整合性移行後: シンプルなコードで正確な動作が保証 • 「マネージドサービスの進化がアプリコードをシンプルにする」 ハッシュタグ #nncstudy
  22. 24 Copyright(C) NRI Netcom, Ltd. All rights reserved. ストレージクラスの進化 クラス

    登場年 用途 目安コスト Standard 2006 汎用・高頻度アクセス $0.023/GB RRS (非推奨) 2010 冗長性を下げた低コスト版 利用は既に非推奨 Standard-IA 2015 低頻度アクセス向け $0.0125/GB Glacier 2012 アーカイブ・数分〜数時間で取り出し $0.004/GB One Zone-IA 2018 単一AZ・低頻度アクセス $0.01/GB Intelligent-Tiering 2018 自動階層移動・最適コスト 自動 Glacier Deep Archive 2019 長期保管(数時間〜) ~$0.00099/GB Glacier IR 2021 即時取り出しアーカイブ $0.004/GB Express One Zone 2023 超低レイテンシ・高TPS 高速特化 「用途に合わせて選ぶ」思想の具現化 20年で9クラスまで拡張 ハッシュタグ #nncstudy
  23. 25 Copyright(C) NRI Netcom, Ltd. All rights reserved. アクセス制御の進化 2006

    ACL中心 ― XML形式で権限管理(複雑・わかりにくい) 2010 IAM登場 ― ユーザー・グループ・ロールで権限管理 2010 バケットポリシー ― JSON形式でバケット単位の制御 2018 Block Public Access ― 公開設定ミスを防ぐ安全装置 2023 ACL非推奨 ― 「シンプルから複雑へ、そして再びシンプルへ」 現在の推奨構成 IAMポリシー + バケットポリシー Block Public Accessを有効化 ACLは使わない 必要に応じてKMSでの暗号化 IAMとバケットポリシーの関係 • IAMポリシー: 誰が(ユーザー・ロール)何を操作できるか • バケットポリシー: どのバケットに誰がアクセスできるか • 同一アカウントでは和集合、クロスアカウントでは両側の許可が必要 ハッシュタグ #nncstudy
  24. 27 Copyright(C) NRI Netcom, Ltd. All rights reserved. re:Invent 2025

    S3 ― 35の発表 What's new with Amazon S3(STG206): 多数の新機能発表 ― S3の勢いは衰えない セキュリティ強化 タグベース制御・PQ TLS・ デフォルト暗号化強化 耐久性 Cross-Region Replication の大幅強化 Express One Zone TPS 2M・コスト85%削減・ Conditional rename API オブジェクトAPI 新APIとメタデータ管理 メタデータ S3 Metadata Tables・Vectors AI時代の新ストレージ基盤 ハッシュタグ #nncstudy
  25. 28 Copyright(C) NRI Netcom, Ltd. All rights reserved. re:Invent 2025

    ― セキュリティ強化(既存分も含む) タグベース アクセス制御 • 「S3 汎用バケットのタグを使った ABAC (属性ベースのアクセス制御) • 大規模環境でのポリシー簡略化 • 「環境=prod」タグで自動適用 ポスト量子暗号化 (PQ TLS) • データ転送を量子コンピュータ攻撃から 保護 • TLS 1.3 + 耐量子鍵交換アルゴリズム • 将来への予防的なセキュリティ強化 デフォルト暗号化 強化 • SSE-S3 / SSE-KMS をバケット単位で 標準化・強制できる設定追加 • ベストプラクティスがデフォルト動作に • 「設定を忘れる」リスクをゼロに ハッシュタグ #nncstudy
  26. 29 Copyright(C) NRI Netcom, Ltd. All rights reserved. S3 Express

    One Zone 大幅アップデート re:Invent 2025: S3 Express One Zone がさらに進化 ― 高速・高スループット・低コスト 主要アップデート • コスト: GET リクエスト料金を最大85%削減 • TPS上限: 2,000,000 read/秒 に引き上げ • アクセスポイントサポート追加 • 同一AZ内での超低レイテンシアクセス RenameObject API(条件付きヘッダー対応) オブジェクト名のアトミックな変更 競合なく安全にリネーム操作 分散システムでの整合性確保に有用 ワークフロー処理の安定性が向上 ハッシュタグ #nncstudy
  27. 30 Copyright(C) NRI Netcom, Ltd. All rights reserved. S3 Tables

    ― Apache Icebergのフルマネージド化 S3 Tables: S3上でApache Icebergテーブルをフルマネージドで利用可能に S3 Tables とは • Apache Iceberg: 大規模データレイク向けオープンテーブル形式 • スキーマ進化・タイムトラベル・ACID トランザクション • Spark・Flink・Athena等と連携 • S3 Tables でそれをフルマネージドで実現 主な効果 圧縮コストを最大90%削減 テーブル管理の運用負荷ゼロ AWS Glue・Athena・EMRと統合 「S3がデータレイクのテーブル管理まで担う」 S3はファイルを置く場所から データレイク基盤へと進化した ハッシュタグ #nncstudy
  28. 31 Copyright(C) NRI Netcom, Ltd. All rights reserved. S3 Vectors

    ― AI時代の新ストレージ S3 Vectors: ベクトルデータをS3スケールで管理 ― AIエージェント・RAGの基盤ストレージへ S3 Vectors とは • ベクトル = AIが「意味」を理解するための数学的表現 • 類似検索(Nearest Neighbor Search)に特化 • 20億ベクトル / インデックスをS3スケールで管理 • シンプルAPI: Put / Get / List / Delete / Query コストと統合 アップロード・保存・クエリの総コストを最大90%削減 Amazon Bedrock と統合 OpenSearch との連携 RAG・AIエージェント構築が容易に S3 = AI の知識基盤へ ベゾスの「インターネットのmalloc」ビジョンは今も進化し続けている ハッシュタグ #nncstudy
  29. 33 Copyright(C) NRI Netcom, Ltd. All rights reserved. クラウド運用の困りごとを解決するウェビナー 既存システムの改修なし!AWS契約の移行でコスト削減を実現

    【概要】 AWS Organizationsの利用制限や既存システムの変更・改修なく、 AWS請求代行サービス導入した事例 をご紹介します。 みなさまの企業でのAWS活用でよくある課題を挙げつつ、いかに解決できるのかをご説明し ます。 企業において、クラウドインフラの効率化、コスト削減は今や重要な経営課題です。 【こんな方におススメです】 ・企業でAWSアカウントの管理を任されている方 ・AWSのセキュリティやガバナンスの対策を検討中の方 ・AWSの利用料が増えて困っている方 ・AWS利用の効率化、コスト削減について情報収集をしたい方 https://nrinetcom.connpass.com/event/387580/ 3月25日(水) 12:00~13:00