歴史を学ぶ意味は「過去を知ること」だけではありません。流れを理解することで、未来の変化を先読みできるようになります。

2020年代のAWSは「AI」へ大きく舵を切った

クラウドの「次」はAIです。AWSは今、AIをすべてのサービスの中心に据えています。

2023年、AWSはAmazon Bedrock（アマゾン ベドロック）をリリースしました。これは、Claude（クロード）・Llama（ラマ）などの大型AIモデルを、AWSのインフラ上で手軽に使えるようにしたサービスです。

わかりやすく言うと、「AIを自社のシステムに組み込むための部品箱」です。従来はAIを使うためにデータサイエンティストやAIエンジニアが必要でしたが、Bedrockを使えばAWSの操作ができるエンジニアがAIを活用したサービスを作れるようになりました。

「AIエージェント」が変えるシステムの姿

「AIが自律的に動いて仕事をする」時代が、すでに始まっています。

2025〜2026年、AWSはAIエージェント（自律的に判断・行動するAI）に関するサービスを次々と提供し始めました。前回の週間ニュースで紹介した「Bedrock AgentCore Payments」もその一例です。

AIエージェントとは、人間から「〇〇をして」と指示を受けたAIが、必要な情報を収集し、判断し、外部サービスを呼び出し、結果を返す——という一連の作業を自律的に行う仕組みです。

たとえば「来月の社内研修の候補日程を3つ出して、参加者に確認メールを送って」という指示をAIに出すと、カレンダーを参照し、メールを作成し、送信まで自動でやってくれる——そんな世界が現実になりつつあります。

AWSの歴史から見えてくる「変わらない原則」

20年のAWSの歴史を振り返ると、変わらない原則が見えてきます。

第1回から振り返ってみましょう。

• 第1回：Amazonは「自社の困りごと」を解決する仕組みを作り、それを外部に開放した
• 第2回：S3・EC2は「初期費用ゼロ・使った分だけ」という新しいコスト概念を生んだ
• 第3回：先行・値下げ・エコシステムで競合を圧倒した
• 第4回：災害という危機が、クラウドへの「信頼」を生んだ

すべてに共通するのは「現実の問題を解決することで、価値を生み出してきた」という姿勢です。AIも同じです。「便利そうだから」ではなく「現場の課題を解決できるから」使われていく——AWSはその流れを作り続けています。

これからの情シス担当者に求められること

情シスの役割は「なくなる」のではなく「進化する」のです。

よく「AIが普及すると情シスの仕事はなくなるのでは？」という声を聞きます。私はそう思いません。むしろ、情シス担当者の重要性は高まると考えています。

理由は3つあります。

• AIを「使わせる側」の判断は人間が行う：どのAIツールを社内に導入するか、セキュリティポリシーをどう設定するか——これは人間の判断が必要です
• 「AIが間違えたとき」に気づける人が必要：AIは完璧ではありません。出力を評価・修正できる知識を持った人が社内に必要です
• コスト管理はますます複雑になる：AIサービスの利用コストはわかりにくく、適切に管理できる人材が求められます

私自身がAWS SAAの勉強を続けているのも、「クラウドとAIが組み合わさった時代に、判断できる情シス担当者でいたい」という気持ちからです。

今日からできること

1. Amazon Bedrockのドキュメントを一度読んでみる：難しくても「こんなものがある」と知るだけで十分です
2. 「社内でAIをどう使うか」を考え始める：情シスとして先手を打てます
3. AWS認定資格（Cloud Practitionerから）を検討する：歴史・仕組みを体系的に学べます

連載のまとめ：AWSの歴史は「変化に適応した歴史」

5回にわたってAWSの歴史を振り返りました。最後に整理します。

歴史を知ることは、現在地を知ることです。そして現在地がわかれば、次の一手が見えてきます。

この連載が、AWSを「なんとなく使うもの」から「なぜ使うのかがわかるもの」に変えるきっかけになれば幸いです。ぜひSAAの勉強も一緒に進めていきましょう。

前の記事：【AWS歴史 第4回】東日本大震災が変えた日本のIT｜AWS普及の転換点
関連記事：AWS SAA試験の勉強法【情シス担当者が実践する3つの方法】

「自社のサーバーが止まった」「データセンターへの道が寸断された」「バックアップが同じ建物にあって使えない」——。

私自身はまだ社会人になっていない時期でしたが、後に情シス部門へ配属されてから、あの震災が日本のIT業界をいかに変えたかを先輩から繰り返し聞きました。日本のクラウド移行を一気に加速させた「転換点」として、今でも語り継がれています。

震災前の日本企業：「オンプレミス」が当たり前だった

2011年以前の日本企業のほとんどは、自社内や契約したデータセンターにサーバーを置いていました。

「オンプレミス（On-Premises）」と呼ばれるこの方式は、「自社でサーバーを所有・管理する」形態です。メリットは「すべてを自分でコントロールできる」こと。デメリットは「何か起きたとき、すべて自分で対応しなければならない」ことです。

震災前の日本では「クラウドは便利かもしれないが、セキュリティが心配」「重要なデータを外部に預けるのは怖い」という保守的な意見が主流でした。大企業ほど、その傾向は強くありました。

震災が暴いた「オンプレミスの弱点」3つ

自然災害の前では、物理的なサーバーはあまりにも脆弱でした。

弱点① 物理的な被害に無力

建物が損壊すれば、中のサーバーも終わりです。停電になればシステムは止まります。地震・津波・火災。物理的なインフラはすべての自然災害に対して根本的な弱点を持っていました。

弱点② BCP（事業継続計画）の実態が追いついていなかった

BCP（Business Continuity Plan：事業継続計画）とは、災害や障害が起きても事業を続けられるよう事前に備えておく計画のことです。多くの企業がBCPを「策定していた」ものの、実際にはバックアップのサーバーも被災地の同じエリアにあったり、復旧手順が現実的でなかったりと、機能しないケースが続出しました。

弱点③ リモートワークができなかった

社内のサーバーにしかアクセスできない環境では、オフィスに来られない状況でまったく仕事ができません。震災後の計画停電・交通機関の混乱・避難勧告……。「会社に来ないと仕事ができないIT環境」の脆さが浮き彫りになりました。

震災後の変化：クラウドへの「信頼」が一気に高まった

震災後、「クラウドは危ない」という意見は「クラウドの方が安全かもしれない」に変わっていきました。

被災地から離れたデータセンター（AWSの場合、日本リージョン以外にもシンガポールや米国にサーバーがある）にデータを預けていれば、地元の災害でデータは守られます。インターネットさえつながれば、どこからでもアクセスできます。

AWSは2011年3月に東京リージョン（ap-northeast-1）を開設しました。震災の直後というタイミングでの東京リージョン開設は、日本企業のAWS移行を象徴する出来事でした。

また、2013年には政府が「政府情報システムのクラウド化方針」を策定。行政のシステムにもクラウドを使う方向性が打ち出され、企業における「クラウドは信頼できる」という認識が加速していきました。

情シスの仕事が変わった：「守る人」から「設計する人」へ

クラウド移行は、情シス担当者の役割そのものを変えました。

オンプレミス時代の情シスは「サーバーを守る」仕事が中心でした。ハードウェアの交換、OSのアップデート、バックアップの確認……。しかしクラウドに移行すると、これらの多くはクラウドベンダーが担ってくれます。

代わりに求められるようになったのは「どのクラウドサービスをどう組み合わせるか」「セキュリティ設定をどう設計するか」「コストをどう最適化するか」という設計・判断の仕事です。私自身、この変化を感じているからこそAWSの勉強を続けています。

今日からできること

1. 自社のBCPを確認する：クラウドをどう位置づけているか把握しておきましょう
2. 「なぜクラウドを使っているか」を説明できるようにする：上司や経営層への説明に、震災の教訓は説得力があります
3. 次回（第5回・最終回）へ進む：AIとクラウドが変える「これからの情シスの仕事」を解説します

まとめ

• 東日本大震災は「オンプレミスの弱点」を一気に顕在化させた
• AWS東京リージョンの開設（2011年）が日本のクラウド移行を後押しした
• 情シスの役割は「サーバーを守る」から「クラウドを設計・判断する」へ変化した

災害という悲しい出来事が、日本のITを一段階進化させました。その流れの上に、私たちは今立っています。次回は、AWSの現在とこれからを解説します。

前の記事：【AWS歴史 第3回】なぜAWSはGoogleに勝ったのか？クラウド覇権の理由
次の記事：【AWS歴史 第5回】AIとクラウドが変える情シスの仕事｜AWSの現在と未来

Google（グーグル）はAmazonよりずっと前からデータセンターを持ち、大規模なシステムを運用していました。Microsoft（マイクロソフト）はWindowsで企業のIT基盤を押さえていました。なのになぜ、後発のAmazonがクラウド市場のトップに立てたのでしょうか。

今回は、AWSが覇権を握った3つの理由を解説します。

理由①「先に始めた」という絶大な優位性

クラウド市場では「先に始めた者」が、ほぼ永続的な優位性を持ちます。

AWSがS3・EC2を提供し始めた2006年当時、GoogleもMicrosoftもまだクラウドサービスを一般企業向けに提供していませんでした。Google Cloud（グーグル クラウド）の一般提供は2011年、Microsoft Azure（マイクロソフト アジュール）の一般提供は2010年です。

AWSには4〜5年のリードがありました。この間にAWSは何をしていたか。サービスをどんどん増やし、使いやすくし、価格を下げ続けていました。

2006年から2010年の間、AWSはサービス数を2つから約30に増やし、料金を複数回にわたって引き下げました。「まずAWSで始めてみる」という文化がエンジニアの間に根付いた頃、GoogleとMicrosoftがようやく市場に参入してきたわけです。

理由②「値下げ」を武器にした価格戦略

AWSは「値下げ」を競争優位の武器として積極的に使いました。

2006年のサービス開始から2014年までの間に、AWSはなんと40回以上の値下げを実施しています。競合他社が追いついてくると値下げし、さらにシェアを広げる——このサイクルを繰り返しました。

この戦略が機能した背景には「規模の経済」があります。ユーザーが増えるほど、データセンターの設備費・運用費を多くの顧客で分担できます。つまり「使う人が増えるほど、一人あたりのコストが下がる」仕組みです。

スーパーの「大量仕入れで安く売る」と同じ原理です。先行してシェアを取ったAWSは、この規模の経済で競合を引き離していきました。

理由③「エコシステム」という参入障壁

AWSを使いこなすための「周辺環境」が整いすぎて、他に移れなくなっていきました。

2010年代に入ると、AWSを前提とした様々な製品・サービス・書籍・資格が生まれてきます。「AWS認定資格（AWS Certified）」もその一つです。

企業がAWSを使い始めると、社内のエンジニアはAWSの使い方を覚えます。システムもAWSの機能を前提に設計されます。取引先との連携もAWS経由になっていく。こうして「AWSから他のクラウドに移るのは、コストと手間がかかりすぎる」という状態が生まれます。これを「ベンダーロックイン（乗り換えが難しくなること）」と言います。

悪い意味ではなく、AWSが「使い続けたくなる理由」を積み重ねてきた結果とも言えます。

Netflixの事例：大企業がAWSに移行した理由

「大企業もクラウドに移る」流れを決定づけたのがNetflixの決断でした。

世界最大の動画配信サービスNetflix（ネットフリックス）は、2008年にデータセンターで大規模な障害が発生し、DVDの発送が3日間停止するという事件を経験します。これを機に「自社でサーバーを持つのはリスクが高い」と判断し、AWSへの全面移行を決断しました。

2016年に移行が完了したNetflixは、世界190か国のユーザーを、AWSだけで支えるようになりました。この事例が世界中の大企業に「クラウド移行は現実的だ」という確信を与えました。

今日からできること

1. 自社が使っているクラウドを確認する：AWS・Azure・GCPのどれかわかると、現在のシェア状況がリアルに理解できます
2. 「乗り換えコスト」を意識してみる：ベンダーロックインは自社のシステムにも起きていないか考えてみましょう
3. 次回（第4回）へ進む：日本でAWSが普及するきっかけになった「東日本大震災」との関係を解説します

まとめ

• AWSは4〜5年の先行優位で市場を確保した
• 40回以上の値下げで「使うほど安くなる」サイクルを作った
• エコシステムの充実で「AWSから離れにくい」状態を築いた

AWSの強さは「最初に走り出した」こと、そして「走り続けた」ことにあります。次回は、日本でAWSが爆発的に普及するきっかけとなった出来事を振り返ります。

前の記事：【AWS歴史 第2回】「サーバーを買わなくていい」革命｜S3・EC2が変えた世界
次の記事：【AWS歴史 第4回】東日本大震災が変えた日本のIT｜AWS普及の転換点

今では当たり前になったクラウドですが、2006年以前のIT業界では「システムを動かすにはサーバーを買う」のが常識でした。その常識を根本から壊したのが、AWSが2006年にリリースした2つのサービスです。

今回は、Amazon S3（Simple Storage Service）とAmazon EC2（Elastic Compute Cloud）の登場が、IT業界にどんな衝撃を与えたかを解説します。

2006年以前：「サーバーを持つ」のが当たり前だった時代

当時のIT担当者にとって、サーバーは「買うもの」でも「借りるもの」でもなく、「管理するもの」でした。

Webサービスやシステムを作りたい企業は、まず高額なサーバー機器を購入するところから始めます。それをデータセンターや自社のサーバー室に設置し、OSをインストールし、ネットワークを設定し……と、サービスが動くまでに数週間〜数ヶ月かかることも珍しくありませんでした。

情シス担当者の仕事の大部分は「このサーバーをどう維持するか」でした。停電対策、冷却設備、ハードウェア故障への対応……。「システムを動かす」ことより「サーバーを守る」ことに時間を取られていたのです。

S3の衝撃：「ファイル置き場」がクラウドに移った日

S3の登場は「データの保管場所」という概念を根本から変えました。

2006年3月にリリースされたAmazon S3（Amazon Simple Storage Service）は、インターネット上に大量のデータを保存・取り出しできるサービスです。わかりやすく言うと、「インターネット上にある巨大な引き出し」です。

それまで企業は、画像・動画・ログデータなどを保存するために専用のストレージ（保存装置）を購入していました。S3はそれを「必要な分だけ、使った分だけ課金」で提供しました。

料金は当初1GBあたり月0.15ドル（約17円）。初期費用ゼロ、容量無制限。この衝撃は、IT業界の人々には「ありえない」と感じられるほどのものでした。

EC2の衝撃：「コンピューターを借りる」という発想

EC2は「コンピューターは買うもの」という20年来の常識を壊しました。

2006年8月にベータ版がリリースされたAmazon EC2（Elastic Compute Cloud）は、仮想サーバー（仮想コンピューター）をインターネット越しに借りられるサービスです。

「仮想サーバー」というのは、1台の物理的なサーバーの中に、複数のサーバーが動いているような状態です。レンタルオフィスをイメージするとわかりやすいでしょう。大きなビルの中に、複数のテナントが独立したオフィスを構えているイメージです。

EC2の革命的だった点は3つあります。

• 数分で使い始められる：従来は数週間かかっていたサーバー調達が、数分で完了
• 必要なときだけ使える：繁忙期だけサーバーを増やし、終わったら削除。無駄なコストゼロ
• 世界中から使える：地理的な制約なし。日本にいながら米国のサーバーを使える

誰が最初に飛びついたか？スタートアップ企業の革命

S3とEC2が最初に普及したのは、大企業ではなくスタートアップ（新興企業）でした。

理由は単純です。スタートアップは資金が少ない。でも大きなサービスを作りたい。そこに「初期費用ゼロ、使った分だけ払えばいい」というAWSが登場したのです。

たとえば、写真共有サービスのSmugmug（スマグマグ）は、S3リリース直後に採用し「ストレージコストが大幅削減できた」と公言しました。また、現在では世界最大の動画配信サービスであるNetflix（ネットフリックス）も、2008年ごろからAWSへの移行を始めます。

「大きなサービスを立ち上げるのに、もはや多額の設備投資は必要ない」——この事実が、世界中の起業家に希望を与えました。

情シス担当者として今日できること

1. 自社でS3かEC2を使っているか確認する：多くの企業でこの2つが基盤になっています
2. 「オンプレミスとクラウドの違い」を整理してみる：S3・EC2の登場前後で何が変わったかを考えると理解が深まります
3. 次回（第3回）へ進む：AWSがGoogle・Microsoftを抑えてシェアトップになった理由を解説します

まとめ

• S3は「データの保管場所」をクラウドへ移した。容量無制限・使った分だけ課金という革命的なサービス
• EC2は「コンピューターは買うもの」という常識を壊した。数分で使い始められる仮想サーバー
• 最初に飛びついたのはスタートアップ企業。初期費用ゼロが、新しいビジネスの可能性を大きく広げた

S3とEC2の登場は、「大企業だけがITに投資できる時代」の終わりを告げました。次回は、なぜAWSがGoogleやMicrosoftを抑えてトップシェアを獲得できたのかを解説します。

前の記事：【AWS歴史 第1回】AWSはなぜAmazonが作った？誕生の秘密
次の記事：【AWS歴史 第3回】なぜAWSはGoogleに勝ったのか？クラウド覇権の理由

同じように感じている方は多いのではないでしょうか。この連載では、AWSがどのように生まれ、なぜここまで普及したのかを5回にわたって解説します。歴史の流れを知ると「なるほど、だからこういう仕組みになっているのか」と腑に落ちる瞬間がたくさんあります。

AWSは「Amazonが自分たちのために作ったもの」だった

AWSの誕生は、Amazonが自社のIT問題に悩み抜いた結果でした。

2000年代初頭、Amazonはネット通販として急成長していました。毎年倍々で増えるユーザー、商品数、注文数。それを支えるサーバーやシステムも、どんどん増設する必要がありました。そこで3つの深刻な問題が起きます。

問題① 新機能を作るたびに「インフラ整備」から始めなければならない

Amazonは当時、おすすめ機能・レビュー機能・ショッピングカートなど次々と新機能を開発していました。しかし開発チームが「新機能を作りたい」と思うたびに、まずサーバーを用意し、ネットワークを設定し、ストレージを確保する……という作業が必要でした。

たとえるなら、「料理を作りたいのに、毎回ゼロからキッチンを建設しなければならない」ような状態です。

問題② サーバーの「もったいない問題」

ECサイトには年末年始・セール期間など、アクセスが集中する時期があります。この繁忙期に合わせてサーバーを用意すると、普段はサーバーの大半が「遊んでいる」状態になります。多い時期に合わせて用意したサーバーが、閑散期はほとんど使われない。でも電気代や維持費はかかり続ける。非常に非効率な状態でした。

問題③ チームごとにバラバラなシステムが乱立

急成長に伴い、開発チームの数も増えました。チームごとに「自分たちのやり方」でシステムを作ると、同じような機能をチームAとチームBがそれぞれ作ってしまう「二重投資」が発生。全体の整合性が取れなくなっていきました。

解決策：「社内共通インフラ」を作り、みんなで使い回す

Amazonが出した答えは「共通インフラを作って社内全体で使い回す」でした。

2002年ごろ、創業者ジェフ・ベゾスは社内に有名な「API Mandate（エーピーアイ マンデート）」という命令を出します。要約すると「すべてのチームは、自分たちのデータや機能を、外部から呼び出せる形式で公開せよ」というものです。

これにより、Amazonの社内は「サービスをモジュール（部品）として組み合わせる」仕組みへと変わっていきました。そしてこの共通インフラを整備する中で、Amazonの技術者たちはあることに気づきます。

「これ、Amazon以外の会社にも売れるんじゃないか？」

自社の悩みを解決した仕組みが、他社にとっても価値があると気づいた瞬間でした。

2006年、AWSが世界へ

「自分たちの悩みを解決した仕組み」が、世界を変えるサービスになりました。

2004年に社内向け実験を始め、2006年、ついに外部向けサービスとして「Amazon Web Services（AWS）」を正式提供開始。最初にリリースされたのは主に2つのサービスです。

• Amazon S3（Simple Storage Service）：インターネット上にファイルを保存・取り出しできるサービス。「クラウド上の引き出し」です
• Amazon EC2（Elastic Compute Cloud）：インターネット上でコンピューターを自由に借りられるサービス

「サーバーを自分で買わなくていい」「使った分だけ料金を払えばいい」という革命的な発想が、ここから始まりました。

今日からできること

1. 自社のシステムがどこで動いているか確認してみる：クラウドを使っているなら、そのメリットが歴史から見えてきます
2. 「AWSがなければ何が困るか」を想像してみる：インフラの重要性を実感できます
3. 次回（第2回）へ進む：S3とEC2が実際にどんな衝撃を業界に与えたかを解説します

まとめ

• AWSは、AmazonがECサイト運営の「IT問題」を解決するために作ったシステムが起源
• 「インフラ整備の非効率」「サーバーのムダ」「チームの乱立」という3つの問題がAWSを生んだ
• 2006年にS3とEC2を外部提供開始。クラウドの時代が幕を開けた

「なぜAmazonがクラウドを作ったのか」がわかると、AWSの設計思想がすべて腑に落ちてきます。次回は、S3とEC2の登場が世界にどんな衝撃を与えたかを解説します。

関連記事：AWS SAA試験の勉強法【情シス担当者が実践する3つの方法】
次の記事：【AWS歴史 第2回】「サーバーを買わなくていい」革命｜S3・EC2の衝撃

私自身も、AWSの勉強をしながら現場の業務をこなしていると、最新情報を追いかける時間がなかなか取れません。

そこで今回は、2026年5月第2週のAWSニュースの中から「情シス担当者として知っておきたい3本」を選んで、わかりやすく解説します。今週はとくに「AIがお金を払う」という、ちょっと衝撃的なニュースが出ました。一緒に確認していきましょう。

今週いちばんの衝撃：AIエージェントが「自分でお金を払う」

AIはもはや「使う道具」ではなく、「動く社員」になりつつある。

まず今週の最大トピックから。AWSが「Amazon Bedrock AgentCore Payments（ベドロック エージェントコア ペイメント）」というサービスのプレビューを発表しました。

一言で言うと、AIエージェント（自律的に動くAIプログラム）が、人間の指示なしにお金を払って外部サービスを利用できるようになった、というものです。

どういうこと？具体的に説明します

たとえば、こんな場面を想像してください。

「AWS上で動いているAIに『競合他社の最新情報をまとめて』と頼む。AIは外部の有料データAPIに自動でアクセスし、料金を支払い、結果だけを報告してくる。」

従来は「外部のAPIを使う → 請求が発生する → 人間が承認する」という流れが必要でした。それが今後はAIが自律的にセッション単位で予算を管理しながら決済まで完了できるようになります。

決済はCoinbaseとStripeが担当

支払いの仕組みは、Coinbase（コインベース）とStripe（ストライプ）という2社が担当しています。

• Coinbase連携：USDCというステーブルコイン（価格が安定した暗号通貨）で決済
• Stripe連携：クレジットカードや銀行口座から普通の法定通貨で決済

どちらも「セッションごとに使える上限金額を設定できる」ので、AIが勝手に無制限に使うわけではありません。

情シス担当者として気になること

「それって、セキュリティ大丈夫なの？」と思った方、鋭いです。現時点ではプレビュー（試験運用）段階です。利用前にエンドユーザーが明示的に承認する仕組みになっており、いきなり財布の中身が全部使われるような設計にはなっていません。

ただ、将来的にはホテル予約や出張手配までAIが行えるようにする計画がAWSにはあるようです。経費精算の承認フローや稟議プロセスが根本から変わる可能性があり、情シスとしては「社内のルール整備」を今から考えておく必要があるかもしれません。

2本目：AIがAWSを「操作」するツールが登場

「AIにシステム構築を任せる」時代が静かに始まっている。

次のニュースは「Agent Toolkit for AWS（エージェント ツールキット フォー エーダブリューエス）」の発表です。これはひとことで言うと、AIコーディングエージェント（コードを自動で書くAI）がAWSのサービスを使いこなすための道具箱です。

具体的には何ができる？

• AIがAWS公式ドキュメントを参照しながらコードを書く
• AWSのサービス（S3やLambdaなど）に自動でアクセスして設定を確認する
• エラーが出たら、AIが自分でAWSのログを調べて対応策を提案する

これは「AWS MCP Server（エムシーピー サーバー）」という技術をベースにしていて、AIツールとAWSサービスをつなぐ”橋”の役割を果たしています。

情シス目線での読み解き

エンジニアがいない情シス部門にとっては、少し遠い話に聞こえるかもしれません。ただ、「AIにAWSの構築を任せる」という流れが公式化されたという点は注目です。今後、「AIが書いたコードをレビューする」「AIが提案した設定変更の可否を判断する」という役割が、情シス担当者に求められるようになっていく可能性があります。

3本目：Amazon Q Developerに動き、知っておくべき変更点

便利なツールにも「使える期限」がある。今のうちに確認しておこう。

最後は、コード補完AIツール「Amazon Q Developer（アマゾン キュー デベロッパー）」に関する変更情報です。

もし社内のエンジニアやシステム部門がこれを使っていた場合、移行計画の検討が必要になります。

情シスとしてやるべきこと

1. 社内でAmazon Q Developerを使っている人・部署を把握する
2. 2027年4月のサポート終了に向けた代替手段（GitHub CopilotやClaude Codeなど）を検討する
3. ベンダーやシステム担当者に確認する

「使えなくなってから慌てる」のが一番コストがかかります。今のうちに棚卸しをしておきましょう。

今週のAWSニュース、情シスとして今日できるアクション

「知っている」と「動いている」には、大きな差がある。

✅ すぐにできること（今日〜今週）

• Amazon Q Developerの社内利用状況を確認する（使っている人がいれば移行を検討）
• Bedrock AgentCore Paymentsのニュースを上司や関連部署に共有する（セキュリティポリシーの議論のきっかけに）

✅ 少し先を見据えてやること（今月〜来月）

• 「AIエージェントが社内システムにアクセスするルール」を考え始める
• AWSのセキュリティ設定（IAM（AWSのアクセス管理サービス）ポリシーなど）の定期見直しをスケジュールに入れる

まとめ：今週のAWSは「AIが動き出した」週だった

「AIが動く」時代において、情シス担当者の役割はなくなるのではなく、「AIを管理・判断する人」として変化していきます。

毎週のAWSニュースを追いかけるのは大変ですが、こうして要点を押さえておくだけで、会議での一言や上司への報告がぐっと変わります。来週も一緒にキャッチアップしていきましょう。

関連記事：AWS Secrets Managerの使い方｜パスワード自動ローテーションの設定方法を解説
関連記事：AWS SAA試験の勉強法【情シス担当者が実践する3つの方法】

こうした物理的な壁を突破するのが、頑強な専用デバイスAWS Snowファミリーです。かつては巨大なトラック（Snowmobile）が話題をさらいましたが、現在は「高性能なデバイスを賢く使い回す」のが最新のベストプラクティスです。

今回は、最新のラインナップと試験で狙われるポイントを徹底解説します！

Snowファミリー3つの主要デバイス

試験では、移行したい「データの規模」と「計算が必要か」によってデバイスを選びます。

①AWS Snowcone（最小・最軽量）

• 容量：8TB/14TB程度
• 特徴：非常に小さく、バックパックに入れて持ち運べるサイズ。
• 用途：小規模なデータ移行や、スペースの限られた場所でのデータ収集。

② AWS Snowball Edge（主力・万能型）

• 容量：80TB/100TB程度
• タイプ
  ・Storage Optimized（ストレージ最適化）： 大規模なデータ移行に。
  ・Compute Optimized（コンピューティング最適化）： 強力なCPU/GPUを搭載し、現地で機械学習などの解析が可能。
• 用途
  SAA試験でも頻出。テラバイト級の移行や、工場・船舶でのエッジ処理に。

【重要】Snowmobileはどこへ行った？

かつて「最大100PB」を運んだ巨大トラックAWS Snowmobileは、2024年にサービスを終了（廃止）しました。

現在は、たとえ数ペタバイトのデータ移行であっても、「複数台のSnowball Edgeを並列で使用する」構成が推奨されています。試験で「超大容量だからトラック！」と選ばないよう、知識を上書きしておきましょう。

物理で運ぶだけじゃない！「エッジコンピューティング」

最近のSnowファミリー（特にSnowball Edge）は、単なる「運び屋」ではありません。

• 現地での実行
  デバイス上でEC2インスタンスやLamda関数を動かせます。
• オフライン処理
  インターネットが無い環境でデータを収集・解析・フィルタリングし、必要でデータだけをデバイスに詰め込んでAWSへ送り返す、という使い方ができます。

【比較表】Snowcone vs Snowball Edge

試験で役立つ！キーワード判別法

問題文に以下のフレーズがあれば、AWS Snowファミリーが正解です。

• 「数百TB以上のデータを迅速に移行したい」
• 「ネットワーク帯域が制限されている、または不安定」
• 「インターネット接続がない場所でのデータ処理が必要」
• 「オフライン環境でEC2やLamdaを実行したい」

今回の学び：攻略の格言

「トラックは引退、これからはSnowballの複数使い！大容量もエッジ処理も、頑丈な箱（Snow）に詰め込んで物理で解決！」

あとがき：一歩ずつ、合格へ

最後まで読んでいただき、ありがとうございました！

「Snowmobileはもういない」という事実は、AWSがいかに進化し、既存のデバイス（Snowball）の効率やオンライン移行ツールの性能が上がったかを物語っています。最新のトレンドを追うことは、SAA合格だけでなく、実務で「生きた提案」をするためにも欠かせませんね。

それでは、次回の記事でお会いしましょう！

そんな「現場の切実な悩み」を解決するのが、AWS Storage Gatewayです。

私は模擬試験で「オンプレミスのアプリケーションを改修せずに、データをS3に保存するには？」という問題に出会い、このサービスの柔軟性に驚きました。用途に合わせて3つのモードがあるのですが、その使い分けが試験突破の大きな鍵になります！

Storage Gatewayは「3つの顔」を持つ

Storage Gatewayは、オンプレミスに設置する「仮想ゲートウェイ」を通じて、AWSのストレージを利用可能にします。試験で問われるのは、主に以下の3タイプです。

①S3ファイルゲートウェイ（一番人気！）

• 特徴
  S3をオンプレミスから「普通のフォルダ（NFS/SMB）」としてマウントできます。
• 用途
  既存のファイルサーバーの延長としてS3を使いたい場合や、ログの転送に最適。

②ボリュームゲートウェイ（ディスクとして使う）

• 特徴
  iSCSIブロックストレージとして、サーバーに「ハードディスク」として認識させます。
• モード
  ・保管型（Stored）：全データを手元に置き、バックアップをAWSへ。
  ・キャッシュ型（Cached）：頻繁に使うデータだけ手元に置き、残りはAWSへ。

③テープゲートウェイ

• 特徴
  物理的なテープドライブを「仮想テープ」に置き換えます。
• 用途
  磁気テープ（LTO）によるバックアップ運用を、そのままクラウドへ移行したい場合

なぜStorage Gatewayを使うのか？（メリット）

• 低遅延アクセス
  キャッシュ機能により、頻繁に使うデータはインターネット経由の遅延を感じさせません。
• 無限の容量
  実態はS3なので、オンプレミスのディスク容量不足に悩まされることがなくなります。
• 高耐久なバックアップ
  大切なデータは自動的に99.99.999999999%の耐久性を誇るS3に保存されます。

【比較表】どのゲートウェイを選ぶべき？

試験で役立つ！キーワード判別法

問題文に以下のキーワードがあればAWS Storage Gatewayを疑いましょう！

• 「既存のオンプレミスアプリケーションを変更せずにS3を使いたい」
• 「低遅延なローカルキャッシュが必要」
• 「NFSまたは SMB経由でS3にアクセスしたい」
• 「物理テープバックアップを廃止してクラウドへ移行したい」

今回の学び：攻略の格言

「ファイル共有ならファイルゲートウェイ！物理テープを捨てるならテープゲートウェイ！ローカルにキャッシュを置いてS3へ繋げ！」

あとがき：一歩ずつ、合格へ

最後まで読んでいただき、ありがとうございました！

「全部クラウドに移行する」のは理想ですが、現実の現場ではオンプレミスとの共存期間が必ずあります。その橋渡しをスマートに行えるStorage Gatewayは、インフラエンジニアにとって非常に頼もしい味方ですね。

それでは、次回の記事でお会いしましょう！

規模が大きくなるにつれて必ず直面するこの課題を、一気に解決するのがAWS Organizationsです。

私は模擬試験で「複数のアカウントの請求を一つにまとめ、かつ全アカウントに共通の禁止ルールを適用するには？」という問いに出会い、正解がこのサービスであることを学びました。単なる「まとめ役」以上の、強力な統制力に驚きました！

Organizationsができる「3つのすごいこと」

AWS Organizationsは、複数のAWSアカウントを中央から一元管理するためのサービスです。

• 一括請求（Consolidated Billing））
  全てのアカウントの料金を一つの支払アカウントにまとめられます。これにより、ボリュームディスカウント（使えば使うほど安くなる特典）を組織全体で共有でき、コスト削減に繋がります。
• アカウントのグループ化（OU）
  「開発部門」「営業部門」のように組織単位（OU）でアカウントをグループ分けして、管理しやすくできます。
• サービスコントロールポリシー（SCP）
  「このグループのアカウントでは、絶対に高額なインスタンスを使わせない」といった強力な制限を、ルートから一斉に適用できます。

最強のガードレール「SCP」の正体

試験で最も狙われるのが、このSCP（Service Control Policy）です。

• 最強の権限
  たとえ個別のアカウント内で「管理者（Administrator）」権限を持っていても、SCPで禁止された操作は絶対にできません。
• ガードレールの役割
  開発者がうっかりセキュリティ設定を外したり、許可されていないリージョンを使ったりするのを、システム的に未然に防ぎます。

【重要】Organizationsとタグの活用

実務や試験でよく出るのが「コストの割り振り」です。
一括請求で支払いはまとまりますが、「どの部門がいくら使ったか」を把握するために、各リソースにタグを付けておき、Organizationsのコスト管理機能と組み合わせるのが定石です。

試験で役立つ！キーワード判別法

管理や統制の問題で、以下の言葉があればAWS Organizationsが正解の鍵です！

• 「複数アカウントの請求を統合（一括請求）」
• 「ボリュームディスカウントの適用」
• 「組織全体に共通の制限をかける（SCP）」
• 「新しいアカウントの作成を自動化・簡素化」

今回の学び：攻略の格言

「バラバラのアカウント、Organizationsで束ねろ！支払は一括で安く、ルール（SCP）は中央から厳格に！

あとがき：一歩ずつ、合格へ

最後まで読んでいただき、ありがとうございました！

一人で学習しているうちは、なかなか複数アカウントを管理する機会はありませんが、企業での実務では「アカウントの乱立」は日常茶飯事です。Organizationsを知っておくことで、単なる「エンジニア」から「IT資産を管理できるアーキテクト」へと視座が一段上がりますね。

それでは、次回の記事でお会いしましょう！

前回紹介した「AWS WAF」が通信の中身を見る「荷物検査」なら、今回紹介するAWS Shieldは、押し寄せる暴徒から建物を守る「頑丈な外壁」のような存在です。

実は、AWSを使っているだけで私たちはすでに守られている⋯⋯？そんな驚きの仕組みを整理しましょう。

全ユーザー標準装備の「Shield Standard」

驚くべきことに、AWSを利用しているすべてのユーザーは、追加料金なしでAWS Shield Standardによって守られています。

• 自動防御
  一般的なネットワーク層（レイヤー3）やトランスポート層（レイヤー4）のDDoS攻撃を、常時自動で検知・遮断してくれます。
• 設定不要
  私たちが「有効化」のボタンを押す必要すらありません。いわば、AWSという街が標準で備えている「防犯カメラとパトロール」のようなものです。

プロ向けの鉄壁ガード「Shield Advanced」

「Standard」でも十分強力ですが、より重要度の高いビジネスシステムのために用意されているのが、AWS Shield Advancedです。

こちらは有料のサブスクリプションですが、その分サービスが手厚くなります。

• 24時間365日の専任チーム（SRT）
  攻撃を受けている際、AWSのDDoS対策専門チームが直接サポートしてくれます。
• WAFの無料利用
  Advancedを契約すると、AWS WAFの料金が基本パッケージに含まれます。
• コスト保護
  DDoS攻撃によって急増したスケーリング費用（EC2やALBの追加料金など）を補填してくれる、保険のような機能があります。

【比較表】Standard vs Advanced

試験で問われる「差分」を一覧表にしました。

試験で役立つ！キーワード判別法

セキュリティ対策の問題で、以下の言葉があればAWS Shieldを検討しましょう。

• 「DDoS攻撃からの保護」
• 「追加コスト無しで自動的に適用されている防御」→ Standard
• 「専門チームによるサポートやコスト保護が必要」→ Advanced
• 「CloudFrontやRoute 53の可用性を高めたい」

今回の学び：攻略の格言

「デフォルトで守るStandard、プロの安心Advanced。DDoS（物量攻撃）にはシールドを構えろ！」

あとがき：一歩ずつ、合格へ

最後まで読んでいただき、ありがとうございました！

「知らないうちに守られている」というのは、マネージドサービスであるAWSを使う大きなメリットの一つですね。WAFで「技」を防ぎ、Shieldで「力」を防ぐ。この二段構えを理解しておけば、SAA試験のセキュリティ問題はもう怖くありません。

インフラを守る知識は、そのままユーザーの安心に繋がります。一歩ずつ、信頼されるアーキテクトに近づいていきましょう。

それでは、次回の記事でお会いしましょう！