AWS テクニカルインストラクターの杉本圭太です。 このブログは 2024 年 4 月に投稿した AWS 初学者向けの勉強方法 6 ステップ！2024 年版！ を 2 年ぶりにアップデートした内容です。この 2 年間で公開された新しい情報の追記や、変更のあったリンクの最新化を行いました。 みなさんは「AWS を勉強したいんだけど何から勉強すればよいだろう。どこかに勉強方法がまとまってないかな ?」「同僚や部下に AWS の勉強を促しているけど、ちょうど良い教材とか無いかな ?」と思ったことはありますか ? もしくはみなさんの周りでそういう悩みを抱えている方はいませんか ? このブログはそういった AWS を勉強する際の悩みを抱えた AWS 初学者の方や、AWS 初学者を育成する立場にある方を対象にしています。 どのような段取りで知識を深めていけばよいのか、この勉強方法がなぜおすすめなのか、疑問点やハマりどころに直面した際にどこのサイトをチェックすればいいのかなど、納得しながら勉強を進められるように具体的な情報を含めながら 7 ステップで紹介していきます。 ステップ 1. クラウドや AWS の概要を知るには ? ステップ 2. お客様の AWS 活用事例を知るには ? ステップ 3. AWS が提供するサービスの全体像を掴むには ? ステップ 4. AWS の各サービスに詳しくなるには ? ステップ 5. 実践的なスキルを身につけるには ? ステップ 6. 最新情報をキャッチアップするには ? ステップ 7. さらにレベルアップするには ? 紹介するサイトの量は多いですが 全てを順番に完了させる必要はありません 。自分に足りないところや興味あるところを確認すれば大丈夫です。また、 新しいことを学ぶときに一度で完璧に覚えられる方はほとんどいません 。そのため、 何度もくり返しこのブログを見直していただく のがおすすめです。 それでも量が多いと感じる方は、各ステップの「★杉本イチオシ」の目印をつけている部分からまず目を通してみてください ! ステップ 1. クラウドや AWS の概要を知るには ? 最初は AWS とは何か、そしてなぜ利用されていて、ビジネスでどのような効果をもたらしているかを確認してみましょう。メリットを知ることで、「自分も AWS を使いこなせるようになるために勉強してみよう !」と感じやすいかと思います。 AWS の用語やサービスの詳細を学ぶための資料は後のステップで紹介していきますので 、このステップでは概要を把握するだけでも大丈夫です。 1-1. クラウドとは – AWS システム開発をするために必要なサーバーやネットワーク機器などを自社で保有して運用する形態をオンプレミスと呼びます。それに対して AWS はクラウドと呼ばれるサービスを提供しています。これはシステム開発者が自社でサーバーやネットワーク機器を保有せずに、必要に応じてクラウドサービス提供者の データセンター から、インターネットを経由してサーバーリソースなどを利用できるサービスです。 そもそもクラウドのメリットは何かを知りたい方 はこちらを確認してみましょう。また AWS とは のページの中段では、AWS のデータセンターがどの地域にあるかを地球儀を回しながら確認できます。 1-2. AWS のクラウドが選ばれる 10 の理由 ★杉本イチオシ AWS がお客様に選ばれる理由に関して、図や表を用いて読みやすい形式で説明されています。「必要な時に、必要な分だけ、低価格で IT リソースを調達可能」「サービスを開始してから〇〇回以上の値下げを実施」など AWS のポイントがシンプルな言葉で説明されていて、分量もちょうど良いです。 ステップ 2. お客様の AWS 活用事例を知るには ? 事例を見ると、みなさんが普段使っている様々な企業のサービスが実は AWS を利用していることを知れて単純に面白いですし、自分たちがどのように AWS を使えるかの参考にもなります。 事例は量も多いので、まずは興味があるものがあれば目を通すだけでも良いです。 ただし AWS の知識がついた後にあらためてお客様事例を見るとさらに理解が深まりやすいので、この後の学習中にも適宜確認してみてください。 2-1. お客様のクラウド導入事例 ★杉本イチオシ 多種多様な業種や企業規模のお客様がどのようにクラウドを活用いただいているのかが網羅的にまとまっています。フィルター条件を適用することで、 エンタープライズなどのセグメント別、金融サービスなどの業種別、クラウド移行やサーバーレスなどのユースケース別で見ることもできます。 2-2. AWS Summit Japan セッション動画 AWS Summit とは AWS について学んだり、新しいつながりを築くために世界中で開催されている無料のイベントです。日本でも毎年行われていて、AWS やお客様によるセッション、ワークショップなど様々なコンテンツが用意されています。多くのセッションは動画でも公開されております。特にお客様事例セッションは、お客様のシステムにかける “熱意” が伝わってきますし、ビジネス上の課題を AWS でどのように解決していくのかのストーリーが分かりやすいです。 YouTube の再生リストとして公開されているものをいくつか挙げておきます。 AWS Summit Japan 2025 のアーカイブ – YouTube 再生リスト AWS Summit Japan 2024 のアーカイブ – YouTube 再生リスト ステップ 3. AWS が提供するサービスの全体像を掴むには ? ここまでのステップで資料に目を通して、AWS が提供するサービス数の多さに驚いた方も多いかと思います。 AWS のクラウドが選ばれる 10 の理由 でも記載されている通り、AWS はお客様の満足度を何よりも大事にしています。そのため AWS では 200 を超えるサービスを提供しておりますが、その 90% 以上のサービスや機能は全世界のお客様からのリクエストをもとに実装されています。 とはいえサービスが多いと初学者の方は何から始めれば良いかわからずに難しいと感じやすいはずです。そのためまずは AWS のサービス群の全体を俯瞰しながら理解していき、その後にそれぞれの詳細を調べていくのが有効です。そこでこのステップでは、 AWS Skill Builder で無料で視聴できる全体像の把握に役立つデジタルトレーニングなどを紹介します。 AWS Skill Builder とは ? AWS Skill Builder は、AWS の様々な学習コンテンツがまとまっているサービスです。無料で作成できる AWS Builder ID を用意すれば、多くの無料コンテンツを利用できます。さらに有償のプランを選択すれば、AWS 認定の模擬試験、 実践的な AWS スキルを身につける様々な体験型の学習コンテンツ などが利用できます。この後のステップにも AWS Skill Builder に含まれるコンテンツを紹介しています。AWS Skill Builder の概要を知りたい方は こちらのページ 、有償のプランについて知りたい方は こちらのページ を確認してみてください。 3-1. Cloud for Beginners (日本語実写版) AWS について理解するには IT の基本的な知識も必要です。そのため基本用語などを知りたい場合はこちらのデジタルコースがおすすめです。このコースではキャパシティプランニングや CIDR といった IT に関する専門用語について適宜解説しながら進行しますので、AWS に関心がある非 IT 領域の方や学生の方におすすめです。ウェブサービスや AWS クラウドがどういうものなのかといった、AWS の学習をはじめる際に前提となる知識を効率よく学ぶことができます。また、コースの後半ではいくつかの代表的な AWS サービスについてとりあげ、その概要について紹介します。もしこのコースが難しい場合は、Skill Builder の IT 基礎 (日本語実写版) コースや、 IT パスポート試験 、 基本情報技術者試験 の範囲などを併せて勉強してみてください。 3-2. AWS Cloud Practitioner Essentials (日本語実写版) ★杉本イチオシ このコースは AWS を全体的に理解したい方を対象としている基礎レベルの内容です。日本の AWS 認定インストラクターが英語版の内容を日本語で収録しております。技術職の方に限らず、AWS に関わる営業職の方などにも把握していただくのがおすすめの内容です。 3-3. 目的別クラウド構成と料金試算例 代表的な構成とその試算例が幅広く紹介されていますので、自分たちが実現したいシステムではどのような AWS サービスを使えば良いのか、そしてどれくらいの金額になるのかの参考になります。 料金の見積りは、 AWS 料金見積りツール も知っておくと役に立ちます。アクセスした後に画面の右上で言語を変更し、「見積りの作成」ボタンを押すと AWS アカウントがなくても無料でサービスとリージョンを指定した見積りが可能です。 ステップ 4. AWS の各サービスに詳しくなるには ? これまでのステップでは、AWS 全体に関する説明をしてきました。おそらく、各サービスの概要を知るにつれ、知りたいことや疑問点などが出てくると思います。例えば、「サービス A とサービス B は似ているように見えるが違いは何なのか」「サービス C の料金体系はどうなっているのか」「サービス D の設計時の制限値などは無いのか」などが気になった場合はどうすれば良いでしょうか ? そこで AWS の各サービスを深掘りしていくための資料がこちらです。最初から全て読むのは大変なので、 必要な時に都度確認する ような使い方でも大丈夫です。 4-1. AWS サービス別資料 (AWS Black Belt オンラインセミナー) ★杉本イチオシ 真っ先におすすめするのが、「AWS サービス別資料」です。サービスや機能ごとに用意されていて、要点をギュッと凝縮しつつサービス設計時の勘所が押さえられています。難しい専門用語も比喩表現を交えて分かりやすく解説されているため、気になるサービスがある場合はこちらから探して目を通してみましょう。資料の前半が基本の説明になっていることが多いので、初めのうちは前半を確認するだけでも良いかもしれません。 4-2. AWS 用語集 AWS の勉強をしていると知らない単語がどんどん出てくることもあると思います。そんな場合この用語集があることを知っていると、辞書を引くような感覚でその単語の概要を把握できるので便利です。 4-3. AWS ドキュメント 「サービス別資料」でサービスの概要を理解した後に、より詳細にサービスの仕様などを理解したい場合は「AWS ドキュメント」を参照しましょう。HTML 形式で見やすい目次が画面左に表示されるので、知りたい情報に簡単にアクセスできます。 例えば Amazon EC2 ユーザーガイド 、 Amazon S3 ユーザーガイド のようなサービスごとのユーザーガイドや、開発者ガイド、API リファレンス、そしてチュートリアルなどもドキュメントとして用意されています。他にも サービスエンドポイントとクォータ に、サービスの使用制限などが記載されています。しかし専門的で詳細な記述も多いため、いきなりこれをスラスラと読むのは難しいかもしれません。このブログで紹介している他の情報も併せながら、徐々にこのドキュメントを元に仕様の確認や設計判断ができるように目指していただくと良いです。 4-4. よくある質問 各サービスを勉強していて疑問が出た時に最初にアクセスすると良いサイトで、多くの方が気になる質問とその回答の一覧が各サービスごとに用意されています。記載内容にはサービスの特徴などの基本的なことから使用できるオプションなどの詳細まで網羅的に含まれています。 4-5. クラウドコンピューティングコンセプトのハブ クラウドコンピューティングコンセプトのハブでは、クラウドコンピューティング関連の用語に関して深く分かりやすく説明された記事を閲覧して検索できる場所です。例えば ゼロ ETL とは何ですか ? の記事では、ゼロ ETL の概要説明だけでなく、解決する課題やメリット、そしてユースケースまで網羅的に説明されています。他にも、機械学習とは ? DevOps とは ? など、改めて正しく深く理解したい用語が出てきた際にチェックしてみましょう。 生成 AI とは何ですか ? のような新しい用語の解説記事もあります。 4-6. AWS re:Post AWS re:Post は AWS コミュニティの方々向けの Q&A サービスです。AWS に関する技術的な Q&A を検索したり、専門領域ごとのコミュニティグループに参加することができます。中でもおすすめは AWS 情報センター です。AWS 情報センターでは「〇〇というエラーを解決する方法を教えて下さい」「〇〇を設定する方法を教えて下さい」などの実装に関する Q&A が豊富に記載されていますので、サービスを実装してハマりどころに直面した時に参照しましょう。 ステップ 5. 実践的なスキルを身につけるには ? 「習うより慣れろ」という言葉があるように、手を動かすことは学習定着率を高める上で非常に有効な方法です。勉強したサービスをハンズオンなどで実際に触ってみることで、知識と実践を結びつけて理解しながらスキルとして身につけやすいです。「どのサービスが入門に適しているのか分からない」「構築する際の手順書が欲しい」「できれば簡単なものから始めたい」という方に役立つ情報を紹介します。 5-1. AWS の API を理解しよう ! 初級編 ~ API の仕組みと利用方法を理解しよう ★杉本イチオシ AWS のハンズオンをする前にまず知っておいてほしいのが、「AWS は API で操作する」ということです。これを知っておくと、この後のハンズオンでマネジメントコンソールを使ってボタンを押した時に何が起きているのかを把握しやすくなります。また開発者の方であれば AWS CLI や AWS SDK を使う機会も出てくると思いますが、その場合も AWS の API を理解しておくのは重要です。 5-2. AWS Cloud Quest / AWS SimuLearn ★杉本イチオシ AWS Cloud Quest と AWS SimuLearn はどちらも AWS Skill Builder にある 実践的なシナリオで進める学習コンテンツ です。自分で AWS アカウントを用意せずにできる AWS の演習に加えて、ゲームやシミュレーション要素が組み合わさったものです。それぞれ無料で使用できる範囲もあり、その範囲であれば実施できる演習の内容は同じです。 ゲーム要素も含めて学習を楽しみたい方は AWS Cloud Quest から、手軽に演習を試したい場合は AWS SimuLearn から始めてみるのがおすすめ です。 AWS Cloud Quest は 3D ロールプレイングゲームを進めながら AWS を実際に操作するミッションをクリアしていき、コレクション要素もあるため初学者でも楽しく AWS を学べます。ロール毎や課題毎に様々なサービスを利用しながらソリューションを構築していくため、AWS のどのサービスから学習を始めればよいか悩んでいる場合でもおすすめです。 初級である AWS Cloud Quest: Cloud Practitioner と AWS Cloud Quest: 生成 AI プラクティショナー は日本語版が無料で利用可能です。詳細な説明は ゲームベースで学習できる AWS Cloud Quest: Cloud Practitioner が日本語で学習可能になりました の記事をご確認ください。 AWS SimuLearn は演習ごとにコースが独立しているため、AWS Cloud Quest とは違って「この演習だけを試してみたい !」というときに気軽に立ち上げてチャレンジできます。こちらは生成 AI を搭載した仮想顧客とのチャットで課題のヒアリングやソリューション提案のプロセスを体験した後に AWS の演習を行うのが特徴です (現在、AI との対話は英語のみ)。 SimuLearn には数多くのコースが用意されているのですが、初級に位置する合計 20 コースは無料で利用可能です。これらのコースは AWS SimuLearn: Cloud Practitioner (日本語) や AWS SimuLearn: Generative AI Practitioner (日本語版)  という学習プランからまとめて確認ができます。 さらに AWS を触り始めたばかりのときに心配になるのが「この進め方で本当にあってる ?」という部分ではないでしょうか。一人で進めるのが心配という方は [初級] やってみた – クラウドと AWS サービス実践 (解説動画付き) を見ながら SimuLearn を進めてみましょう。「やってみた」シリーズでは、日本人のテクニカルインストラクターによるコンセプトパート、実践パート、DIY パートの解説が含まれており、より AWS サービスの操作や仕組みについて理解を深めることができます。 5-3.  AWS アカウント作成の流れ – AWS AWS Skill Builder の Cloud Quest や SimuLearn、その他の演習は用意された AWS アカウントで進められますが、決められた手順の範囲しか操作できません。もっと自由に AWS を使ってみたいという方は、自分で AWS アカウントを作成してこの後紹介するハンズオンやワークショップを実施できます。AWS 無料利用枠もあるので有効に活用してみてください。こちらの 無料利用枠の紹介記事 の説明にもありますが、2025 年 7 月から始まった新しい無料利用枠では無料アカウントプランというものがあります。これは使用できるサービスに制限はありますが、プランを切り替えるまでは料金は発生しないため、リソースを削除し忘れて課金されてしまうのでは ? という不安がある方も安心して試しやすいかと思います。 AWS アカウントとルートユーザー AWS アカウントを作成した時に設定したメールアドレスとパスワードはルートユーザーと呼び、その AWS アカウントの全ての操作権限を持ちます。そのため AWS アカウントを作成した後、 ルートユーザーに多要素認証 (MFA) を設定 しておきましょう。 またルートユーザーを普段使いすることは非推奨とされており、その代わり AWS アカウント内で必要な権限のみを割り当てて使用できる IAM ロールや IAM ユーザーを作成して使用するようにしましょう。IAM ロールの使用が推奨ではありますが、別の ID 管理の仕組みと連携などが必要になるため、個人の勉強用途であれば AWS Hands-on for Beginners – ハンズオンはじめの一歩: AWS アカウントの作り方 & IAM 基本のキ を見て IAM ユーザーを使うのが始めやすいかもしれません。その場合 IAM ユーザーにも多要素認証 (MFA) を設定 できるので実施しておきましょう。 5-4.  JP Contents Hub JP Contents Hub は AWS に関する日本語のハンズオン・ワークショップ情報を一覧化しているウェブサイトです。このウェブサイトでは 日本語で手順が用意されたハンズオン を限定して掲載していますので、英語の手順だと難しいと感じる方におすすめです。トップページの左側からカテゴリ別にハンズオンを選ぶこともできますし、特定のサービス名やキーワードで検索することもできます。そしてハンズオン一覧は継続的にアップデートされます。JP Contents Hub に関する詳細な説明は AWS 日本語ハンズオンまとめ JP Contents Hub のご紹介 の記事をご確認ください。 ステップ 6. 最新情報をキャッチアップするには ? AWS のサービスは改善のサイクルが非常に早いため、サービスを使用する側も常に知識の鮮度を保つ必要があります。また、最新技術を知ることで設計の幅を広げることもできます。このステップでは各サービスの最新情報のキャッチアップに役立つ情報を紹介しますので、ブックマークしておいて定期的に確認してみてください。 6-1. Amazon Web Services ブログ (日本語) ★杉本イチオシ このブログも掲載している Amazon Web Services ブログです。RSS 登録が可能です。AWS のサービスに関するアップデートを詳しく説明した記事など AWS 関連の様々な情報を掲載していますが、特に 週刊 AWS は要チェックです ! 前の週に公開された主要なアップデートや、日本のお客様に興味を持っていただけそうなものをピックアップして紹介しているので、「ちょっと先週は忙しくて AWS の最新情報を追いきれてない…」という方の助け舟になりますし、ダイジェスト版として重宝いただけると思います。最近はアップデート量が多い生成 AI 関連の情報をまとめた「週刊生成 AI with AWS」もあります。また、関連するブログとして AWS Startup ブログ と AWS JAPAN APN ブログ もありますので合わせてチェックしてみてください。 英語ではありますが AWS Blogs には、より多くの情報がありますので興味あればこちらもどうぞ。 6-2. AWS の最新情報 (日本語) AWS の各サービスに関して、「〇〇サービスが東京リージョンで利用可能になりました」などの最新のアップデートが掲載されています。機能拡張など設計の改善に役立つ情報もありますのでチェックしましょう。なお、本サイトは RSS 登録が可能ですので、RSS リーダーのスマートフォンアプリを利用することで、更新情報を自動的に取得することもできます。 こちらも英語の What’s new with AWS には、より多くの情報が掲載されております。 6-3. builders.flash ★杉本イチオシ デベロッパー向けのウェブマガジンで、様々なレベルの方に向けてバラエティに富んだ記事構成になっています。 AWS のアーキテクチャ図を描きたい ! でもどうすれば良いの ? などの AWS の設計や開発に関する記事だけでなく、有識者に勉強方法をインタビューする ネットワークの勉強方法を聞いてみた。 といった初学者向けの記事などもあります。メンバー登録することでハンズオン記事をためす際に使える無料クーポンが配布されるなど様々な特典が用意されていますので、ぜひメンバー登録をしましょう。 6-4. SNS ( X / Facebook / YouTube ) オンラインイベントの配信開始などリアルタイム性のある内容に関しては X や Facebook をフォローすると情報を追いやすくなりますし、ブログ更新やセミナーの資料公開などの通知系の内容も投稿されています。また、様々な基調講演の内容なども YouTube で随時アップされますので、こちらもチャンネル登録しておきましょう。 6-5. AWS Builder Center ★杉本イチオシ ビルダー向けのコミュニティや AWS 製品チームへのフィードバックなどができる場をまとめたものとして 2025 年 7 月に公開されました。 Topics で興味あるサービスの記事を探したり、気になる Spaces で情報を受け取ったりできます。 AWS Builder ID があれば自分で情報を発信することや Wishlist で 新機能や改善の要望を直接送れます 。詳細は AWS Builder Center のご紹介: AWS ビルダーコミュニティの新しいホーム にも記載されています。 ステップ 7. さらにレベルアップするには ? これまでに紹介した勉強方法を実践して基礎が固まってきた方、高度な情報にアクセスしたくなった方向けの情報も最後に紹介します。 7-1. AWS Well-Architected Framework ★杉本イチオシ クラウドの設計原則や、ベストプラクティスに沿っているかを理解するための質問、実装のガイダンスなどから構成される必読のドキュメントです。6 つの柱 (優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性) に基づいています。AWS を使用する場合には最初の設計段階、そしてその後も定期的にレビューのため使用していただくことを推奨しております。最初は読むのが大変ですが、これを理解できるようになることを目指すことは良い目標になると思います。 7-2. AWS アーキテクチャセンター エキスパートがまとめた AWS の技術リソース群を一覧できます。 ページ上部の「ライブラリ」タブに含まれる AWS ホワイトペーパーとガイド や AWS Prescriptive Guidance (AWS 規範ガイダンス) にはテクニカルガイドやリファレンスのアーキテクチャなどが記載された技術文書が集まっています。 より多くの構成例を確認したい場合は AWS リファレンスアーキテクチャ図 をご確認ください。200 を超えるアーキテクチャ図が掲載されていてポイントごとに解説もありますし、カテゴリ別・業種別にフィルタリングもできます。なお、お客様とパートナー様が実装したアーキテクチャを解説する動画を視聴できる This is My Architecture もおすすめです。 7-3. AWS ソリューションライブラリ 現時点では英語のみですが、業界ごとや技術ごとなどでソリューションのガイダンスを検索できます。ガイダンスごとにアーキテクチャ図が含まれているものが多いので、自分たちの課題を解決するための参考情報として利用できます。 またソリューションライブラリのページではありませんが、 The Amazon Builders’ Library では Amazon のエンジニアが実際に開発・設計・リリース・運用する方法を説明していて、設計に関する考慮事項などの生の声が記載されていて興味深いです。 7-4. ここまで紹介した以外のハンズオンやワークショップ 初級者向けのハンズオンや日本語で用意されているものをステップ 5 でご紹介しましたが、他にも複数のハンズオンがあります。 AWS Builder Center の Workshop ではレベル、カテゴリ (セキュリティ、IoT など) や AWS サービス名でのフィルタができます。ちなみに、 AWS Samples や Amazon Web Services – Labs では GitHub 上に様々なワークショップのソースコード等を公開していますので、合わせてチェックしてみてください。 他にも AWS Skill Builder で有償のサブスクリプションに申し込んでいただくと、自分で AWS アカウントを用意しなくても AWS Builder Labs  で様々な演習が実施できます。 7-5. AWS 認定 AWS の勉強をされている方の中でも「今すぐ業務で使う訳ではないから目標がないとなかなかやる気が出ない」とか「自分の業務で使うサービス以外を勉強するきっかけが少ない」という声もよく伺います。そこで AWS 認定を目指してみるのはどうでしょうか ? 試験も幅広く用意されており、普段業務で使わない知識を知るきっかけにもなります。広く用語を知っておけば、組織内で他のチームの方と会話する時にも相手のやろうとしてることの理解に役立つと思います。試験に合格することで Credly というサービス上で AWS 認定デジタルバッジ も取得できます。 試験ごとの問題集として無料で試せる Official Practice Question Set がありますし、有償サブスクリプションの方は Official Pretest という本試験と同じ問題数の模擬試験も使えます。どれから受ければ良いかわからない場合はまず AWS Certified Cloud Practitioner 、その後に AWS Certified Solutions Architect – Associate に挑戦していただくと良いです。 AWS 認定試験ガイド にはそれぞれの試験の出題範囲が記載されていますので、どの試験を受けるかの選択時や学習時に役立ててください。 7-6. Microcredentials (マイクロクレデンシャル) マイクロクレデンシャルは、実践的なスキルを証明する新しい手法として 2025 年 11 月より利用が可能になり、2026 年 4 月からは全てのコースが無料で利用できるようになっています。このコンテンツは用意された AWS 環境で発生している実践的な課題を解決することで、特定分野におけるスキルの深さを証明します。基準を満たして合格すれば AWS 認定と同様に Credly のデジタルバッジが付与されます。自分のスキルをアピールしたい方、全試験合格 (全冠) の次の目標が欲しい方は是非チャレンジしてみてください。マイクロクレデンシャルについてもっと詳しく知りたい方は [スキル証明] AWS マイクロクレデンシャル スタートガイド (日本語) をご確認ください。日本人のインストラクターがわかりやすく説明を行っています。 7-7. AWS 関連の GitHub リポジトリ AWS では様々なツールやサンプルコードなどを GitHub で公開しています。その中でもいくつかの AWS に関連するアカウントを紹介します。 Amazon Web Services 色んなツールがあり、 AWS CLI 、 AWS SDK 、 AWS CDK 、 AWS SAM などのリポジトリも含まれている Amazon Web Services – Labs こちらもツールが多く最近作成された MCP や aidlc-workflows などは現時点ではここに含まれている Amazon Web Services – Documentation いくつかのドキュメントがあるが、AWS SDK のサンプルコード ( aws-doc-sdk-examples ) があることを知っていると役に立つ AWS Samples 特定のユースケースやシナリオに対する AWS サービスの実践的な実装を示すサンプルコードなど お知らせ (AWS クラスルームトレーニング) 短期間で体系的に学びたいお客様のために、AWS 認定インストラクターが実施する有償の集合研修をオンサイト、オンラインの両方の形式で提供しております。座学だけでなくハンズオンなども含めた充実した内容となっていますので、ぜひ受講をご検討ください。どのコースを受講するかお悩みの方は AWS 認定インストラクターによる有償トレーニングコースの選び方 の記事を、そして有償トレーニングならではの価値を確認するために AWS 有償トレーニングのメリットってなんだろう の記事を参考にしてください。 まとめ 冒頭にもお伝えしましたが、新しいことを学ぶときに一度で完璧に覚えられる方はほとんどいませんので、何度もくり返すことが重要です。早速今日から AWS の学習を始めてみましょう !

本記事は 2026 年 5 月 28 日 に公開された「 The next generation of Amazon OpenSearch Serverless: Built from the ground up for agents 」を翻訳したものです。 対象読者向けの注記: 本記事は技術的な詳細を掘り下げたローンチ記事です。変更点とその理由を簡潔にまとめた概要は、関連する AWS News Blog の記事をご覧ください。 本日、Amazon OpenSearch Serverless のアーキテクチャをゼロから刷新したことを発表します。新しいアーキテクチャでは、オートスケーリングが従来比で最大 20 倍に高速化し、コンピューティングをゼロまでスケールできるようになりました。ピーク負荷に合わせてクラスターをプロビジョニングする場合と比べてコストは最大 60% 削減できます。Amazon OpenSearch Service は、ベクトル、レキシカル、ハイブリッド、エージェント検索を統合したフルマネージドのオープンソース検索エンジンで、低レイテンシーかつ正確で関連性の高い結果を提供します。Amazon OpenSearch Serverless は、その自動スケーリング型のデプロイオプションです。 最近のワークロードはますます動的で予測しにくくなっています。E コマースプラットフォームでは、フラッシュセール時にトラフィックが 10 倍に急増します。人工知能 (AI) エージェントは、複数ステップのタスクを推論する過程で数百もの同時ベクトルクエリをトリガーし、その後アイドル状態になります。マルチテナント SaaS アプリケーションでは、活動パターンが大きく異なる数十のテナントを処理します。こうしたワークロードには、需要に合わせてスケールアップし、需要が下がればリソースを解放できるインフラが必要です。 そこで、 Amazon OpenSearch Serverless のアーキテクチャをゼロから再構築しました。新しいアーキテクチャでは、コンピューティングとストレージを分離しています。インフラのプロビジョニングは分単位ではなく秒単位で完了し、アプリケーションがアイドル状態のときにはコンピューティングをゼロまでスケールダウンします。本記事では、新しいアーキテクチャの内容、アプリケーションへの影響、ハンズオンチュートリアルでの使い始め方を解説します。 新しいローンチに伴い、Amazon OpenSearch Serverless では 2 つのアーキテクチャに名前が付きました。既存のコレクションは Classic コレクションと呼びます。新しいアーキテクチャは NextGen と呼び、AWS コンソールから新しいコレクションを作成するときのデフォルトになります。API で NextGen アーキテクチャを使用するには、CLI で --generation NEXTGEN を指定します。Classic アーキテクチャを引き続き使用する場合は、CLI で --generation CLASSIC を指定するか、オプションの --generation パラメータを省略します。 アプリケーションへの影響 新しいアーキテクチャは、パフォーマンス、コスト、シンプルなユーザー体験という 3 つの柱で改善をもたらします。 パフォーマンス: 秒単位のオートスケーリング OpenSearch Compute Unit (OCU) は、インデックス作成と検索のワークロードを支えるコンピューティング容量の単位です。Amazon OpenSearch Serverless は、追加の OCU を秒単位でプロビジョニングできるようになりました。トラフィックが到着したときには、ワーカーがすでに高負荷に陥ってから対応するのではなく、需要に合わせて事前にリソースを追加します。同じ仕組みで、トラフィックが下がるとインフラを素早くスケールダウンします。新しいアーキテクチャは、容量のスケール速度が以前のアーキテクチャの 最大 20 倍 に達するため、トラフィックの急増時にも一貫したパフォーマンスをユーザーに提供でき、容量が不要になれば支払いも止まります。 コスト効率: 使った分だけ支払う インデックス作成、検索、ストレージ、ベクトルインデックスの GPU アクセラレーションは、それぞれ独立して計測・課金されるため、ワークロードの各次元を個別に把握し、最適化できます。 コンピューティングとストレージの分離: OpenSearch Serverless ではコンピューティングとストレージが完全に分離されており、コレクションに保存されているデータ量とは無関係に OCU をスケールアップ・スケールダウンできます。これは、インデックス作成 OCU と検索 OCU の両方からアクセスできる新しいストレージ層によって実現されています。複数のインデックスにデータを格納していても、データのインデックス作成や検索を実際に行っていなければ、コンピューティングコストは発生しません。アイドル時間が長いワークロードでは、ピーク容量に合わせて OpenSearch Service ドメインをプロビジョニングする場合と比べて、新しいアーキテクチャによりインフラコストを最大 60% 削減できます。 ゼロまでのスケール: アイドルタイムアウト期間 (10 分) の間にリクエストが到着しないと、サービスはコンピューティングリソースを解放し、OCU の使用量はゼロまでスケールダウンします。トラフィックが再開すると、約 10 秒で容量が復活します。スケールダウン中も、サービスは到着したリクエストをキューに入れ、容量が利用可能になり次第処理するため、リクエストを破棄することはありません。スケジュールされたバッチジョブやマーケティングキャンペーンの前など、トラフィックの急増が予想される場合は、本番トラフィックを送信する前に軽量なクエリ (例: size=1 の match_all ) を送信してコレクションをウォームアップしておけます。これにより、最初の実リクエストでユーザーが体感するレイテンシーを抑えられます。インデックス作成と検索は独立してスケールします。検索リクエストがなければ、検索 OCU はゼロまでスケールしますが、インデックス作成リクエストがあれば OpenSearch Serverless はインデックス作成 OCU を維持します。逆向きでも同じです。 ベクトルワークロード向けの GPU アクセラレーション: 新しいアーキテクチャで作成したベクトルコレクションでは、OpenSearch Serverless が GPU バックエンドのコンピューティングを自動的に使用して、Hierarchical Navigable Small World (HNSW) ベクトルインデックスの構築を加速し、CPU のみで構築する場合と比べてインデックス作成時間を大幅に短縮します。GPU アクセラレーションは、全体のインデックス作成時間とコストを削減できる機会があれば自動的に有効になります。Classic アーキテクチャでは、API を介してコレクションレベルで GPU アクセラレーションのオプトイン・オプトアウトが必要でした。NextGen コレクションで特定のインデックスの GPU アクセラレーションを無効にしたい場合は、 インデックスレベルでリモートインデックスビルド設定をオフ にできます。GPU の使用量は請求書に別の項目として表示されるため、いつアクセラレーションが有効で、いくらかかったかを完全に把握できます。GPU アクセラレーションの仕組みやパフォーマンスベンチマークの詳細は、 Amazon OpenSearch Service の GPU アクセラレーションで 10 億スケールのベクトルデータベースを 1 時間以内に構築する を参照してください。 シンプルな体験: 本番環境までのステップ削減 OpenSearch Serverless を日々運用する体験もシンプルになりました。 新しいアーキテクチャでは、コレクションをプロビジョニングして数秒でリクエストを送信し始められます。容量計画もサイジングの判断もインフラのウォームアップ待ちも不要です。これにより、AI エージェントがオンデマンドでベクトル検索や検索ステップを起動し、遅延なくレスポンスを期待できる、エージェントワークロードに Amazon OpenSearch Serverless が自然と適合します。 使い始めをさらに高速化するため、コンソールに Express Create を導入しました。コレクション名とコレクションタイプを指定し、Express Create を選ぶと、ネットワーク、暗号化、アクセスポリシーの事前設定なしで、コレクションが数秒でアクティブになります。ワークロードに必要であれば、後から追加できます。 コレクショングループとコレクションは、AWS Command Line Interface (AWS CLI) や AWS SDK を使ってプログラムから作成することもできます。AWS CloudFormation のサポートも近日提供予定です。 新しいアーキテクチャでは、 on.aws ドメイン上に 2 つのエンドポイント形式が導入されました。コレクション単位のエンドポイント ( <collectionId>.aoss.<region>.on.aws ) は、コレクション 1 つにつきエンドポイント 1 つという、これまでと同じ動作です。アカウント単位のリージョナルエンドポイント ( <accountId>.aoss.<region>.on.aws ) は新しく、1 つのホスト名で全コレクションを処理し、対象のコレクションは各リクエストで x-amz-aoss-collection-name または x-amz-aoss-collection-id ヘッダーで指定します。コレクション数に関係なく、コネクションプール 1 つ、Transport Layer Security (TLS) セッション 1 つ、管理するエンドポイント 1 つで済みます。テナントごとに独自のコレクションを割り当てるマルチテナントワークロードでは、大きな改善になります。両方のエンドポイントは標準の AWS PrivateLink を使用するため、他の AWS サービスと同様に、VPC コンソールや EC2 API から Virtual Private Cloud (VPC) エンドポイントを作成できます。Private Domain Name System (DNS) は自動で構成されるため、元のアーキテクチャで必要だった Amazon Route 53 プライベートホストゾーン、転送ルール、カスタム DNS インフラが不要になります。クロス VPC、クロスアカウント、オンプレミスからのアクセスは、追加のセットアップなしに標準の vpce-* DNS 名で動作します。 コレクショングループは、コレクションを整理する新しい単位 です。 コレクショングループ を使うと、複数のコレクション間でコンピューティング容量を共有でき、トラフィックパターンが補完的な小規模コレクションのコストを削減できます。同じグループ内のコレクションに異なる AWS Key Management Service (AWS KMS) キーを割り当てることもでき、コスト効率とコレクション単位の暗号化分離の両方を得られます。新しいアーキテクチャでコレクションを作成する場合、コレクショングループは必須です。 バージョンとアップグレードを管理する手間なく、OpenSearch オープンソースリリースの利点も得られます。サービスはアップストリームのリリースを自動的に追跡します。 Amazon OpenSearch Serverless は Vercel Marketplace でも利用可能になっており、開発者は Vercel プロジェクトから検索インフラを直接追加できます。委任アクセスを通じて既存の AWS アカウントをリンクするか、AWS が初めての場合は USD $100 の AWS クレジット付きの Limited Scope Account を通じて使い始められます。 この統合では、適切なデフォルト、ゼロまでのスケール課金、パブリックエンドポイント、AWS マネージド暗号化を備えたコレクションが作成され、接続情報が Vercel プロジェクトの環境変数として自動的に設定されます。フルテキスト検索でも、セマンティックや AI を活用した検索でも、ユースケースに応じて Search または Vector Search のコレクションタイプを選べます。 アーキテクチャの仕組み 新しい Amazon OpenSearch Serverless アーキテクチャは、コンピューティングとストレージを完全に分離します。OCU はステートレスで、インデックス作成 OCU と検索 OCU の両方からアクセス可能な分散共有ストレージ層から読み書きします。ストレージ層は高い耐久性を念頭に設計されており、データを処理するコンピューティングノードとは独立してデータを利用可能に保ちます。 この設計は、実用上 2 つの効果をもたらします。 高速なプロビジョニング。 ブートストラップするローカルディスクがないため、新しい OCU は数秒でリクエストの処理を開始します。OCU は共有ストレージ層をマウントし、すぐに処理を開始します。 効率的なスケールダウン。 データが OCU 上に存在したことがないため、保存されたデータに影響を与えずにアイドル容量を解放できます。トラフィックが下がるとコンピューティングリソースが解放され、それに応じてコストも下がります。 アーキテクチャの比較 次の表で、元のアーキテクチャと新しいアーキテクチャの主な違いをまとめます。 機能 Classic アーキテクチャ NextGen アーキテクチャ 最小容量 2 OCU (常時稼働) 0 OCU (ゼロまでのスケール) スケーリング速度 分単位 秒単位 ストレージ コンピューティングノードごとのローカルストレージ 分散共有ストレージ (分離) コレクションの整理 個別コレクション (デフォルト) コレクショングループ (オプション) コレクショングループ (必須) ゼロからのコールドスタート 該当なし (常時稼働) 約 10 秒 エンドポイント コレクション単位のエンドポイント リージョナルエンドポイント (アカウントごとに静的) OpenSearch Service ドメインに対するコスト ベースライン 最大 60% 低コスト スケーリング速度 (Classic 比) ベースライン ベースラインの最大 20 倍 ウォークスルー: ベクトルコレクションの作成とゼロまでのスケールの観察 このウォークスルーでは、Express Create でベクトル検索コレクションを作成し、埋め込みを持ついくつかのサンプルドキュメントをインデックスし、k-nearest neighbor (k-NN) クエリを実行し、Amazon CloudWatch でコレクションがゼロまでスケールする様子を観察します。全体で約 10 分かかります。 前提条件 Amazon OpenSearch Serverless コレクションを作成する権限を持つ AWS アカウント。 適切な認証情報で構成された AWS Command Line Interface (AWS CLI)。 curl 7.75 以降 (組み込みの --aws-sigv4 サポート用)。 ステップ 1: セキュリティポリシーを構成する 暗号化、ネットワーク、データアクセスポリシーを作成します。コレクションを作成する前にこれらが存在している必要があります。 # Create an encryption policy aws opensearchserverless create-security-policy \ --name product-vectors-encryption \ --type encryption \ --policy '{"Rules":[{"ResourceType":"collection","Resource":["collection/product-vectors"]}],"AWSOwnedKey":true}' \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Create a network policy (public access for this tutorial) aws opensearchserverless create-security-policy \ --name product-vectors-network \ --type network \ --policy '[{"Rules":[{"ResourceType":"collection","Resource":["collection/product-vectors"]},{"ResourceType":"dashboard","Resource":["collection/product-vectors"]}],"AllowFromPublic":true}]' \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Get your principal ARN PRINCIPAL_ARN=$(aws sts get-caller-identity --query 'Arn' --output text) # Create a data access policy aws opensearchserverless create-access-policy \ --name product-vectors-data \ --type data \ --policy "[{\"Rules\":[{\"ResourceType\":\"index\",\"Resource\":[\"index/product-vectors/*\"],\"Permission\":[\"aoss:CreateIndex\",\"aoss:DescribeIndex\",\"aoss:UpdateIndex\",\"aoss:DeleteIndex\",\"aoss:ReadDocument\",\"aoss:WriteDocument\"]}],\"Principal\":[\"\${PRINCIPAL_ARN}\"]}]" \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" 注: AWS コンソールの Express Create ワークフローを使用すると、これらのポリシーは自動的に作成されます。 重要: データアクセスポリシーを作成した後、コレクションへの API 呼び出しを行う前に、ポリシーが伝播するまで約 30〜60 秒待ちます。403 Forbidden エラーが発生した場合は、待ってから再試行してください。 ステップ 2: コレクショングループとコレクションを作成する ゼロまでのスケール容量制限を持つコレクショングループを作成し、その中にベクトル検索コレクションを作成します。 # Create a collection group with scale-to-zero enabled (min OCU = 0) aws opensearchserverless create-collection-group \ --name product-search-cg \ --generation NEXTGEN \ --standby-replicas ENABLED \ --capacity-limits "minIndexingCapacityInOCU=0,maxIndexingCapacityInOCU=4,minSearchCapacityInOCU=0,maxSearchCapacityInOCU=4" \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Create a vector search collection in the group aws opensearchserverless create-collection \ --name product-vectors \ --type VECTORSEARCH \ --collection-group-name product-search-cg \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" コレクションのステータスは数秒で ACTIVE に遷移します。 ステップ 3: ベクトルインデックスを作成する コレクションエンドポイントを取得し、3 次元ベクトルを使った k-NN インデックスを作成します。 ENDPOINT=$(aws opensearchserverless batch-get-collection \ --names product-vectors \ --query 'collectionDetails[0].collectionEndpoint' \ --output text \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2") awscurl --service aoss --region us-east-2 \ -XPUT "${ENDPOINT}/items" \ -H "Content-Type: application/json" \ -d '{ "settings": {"index.knn": true}, "mappings": { "properties": { "description": {"type": "text"}, "embedding": {"type": "knn_vector", "dimension": 3, "method": {"name": "hnsw", "space_type": "cosinesimil", "engine": "faiss"}} } } }' 注: コレクションがゼロまでスケールしている場合、容量がスケールアップする間、最初のリクエストには数秒かかる可能性があります。リクエストがタイムアウトした場合は、10〜15 秒待ってから再試行してください。 ステップ 4: 埋め込みを持つサンプルドキュメントをインデックスする awscurl --service aoss --region us-east-2 \ -XPOST "${ENDPOINT}/items/_bulk" \ -H "Content-Type: application/json" \ -d ' { "index": { "_id": "1" } } { "description": "Wireless noise-cancelling headphones", "embedding": [0.8, 0.2, 0.1] } { "index": { "_id": "2" } } { "description": "Portable Bluetooth speaker", "embedding": [0.7, 0.3, 0.2] } { "index": { "_id": "3" } } { "description": "Over-ear studio monitor headphones", "embedding": [0.9, 0.1, 0.05] } ' ステップ 5: k-NN クエリを実行する クエリベクトルに最も近い 2 つの近傍を検索します。クエリを実行する前に、ベクトルインデックスのビルドのため、インデックス作成後 30 秒待ちます。 awscurl --service aoss --region us-east-2 \ -XGET "${ENDPOINT}/items/_search" \ -H "Content-Type: application/json" \ -d '{ "query": { "knn": { "embedding": { "vector": [0.85, 0.15, 0.08], "k": 2 } } } }' レスポンスでは、最も類似する 2 つのアイテム、つまりクエリベクトルに最も近い埋め込みを持つヘッドフォンのドキュメントが返されます。 このクエリは OpenSearch UI でも実行できます。Amazon OpenSearch Service コンソールでコレクションに移動し、OpenSearch UI Application URL を選択します。次に こちらのブログ の手順に従ってワークスペースを作成します。その後、Dev Tools に移動して、次のクエリを貼り付けて実行します。 GET items/_search { "query": { "knn": { "embedding": { "vector": [0.85, 0.15, 0.08], "k": 2 } } } } ステップ 6: ゼロまでのスケールを観察する 一定期間活動がない (インデックス作成や検索のトラフィックがない) と、コレクショングループは 0 OCU までスケールダウンします。次のコマンドで確認します。 aws opensearchserverless batch-get-collection-group \ --names product-search-cg \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" レスポンスで、コレクションがスケールダウンした後、 currentCapacity.search.capacityInOcu と currentCapacity.indexing.capacityInOcu が 0 と表示されます。 Amazon OpenSearch Service コンソールの コレクショングループ ページに移動することもできます。コレクショングループを選択し、 モニタリング セクションまでスクロールします。 インデックス作成容量 (OCU) と 検索容量 (OCU) という 2 つのチャートを確認できます。10 分間アイドル状態 (インデックス作成や検索リクエストがない状態) が続くと、両方のメトリクスがゼロまで下がり、サービスがコレクションのコンピューティングリソースをすべて解放したことが確認できます。 クリーンアップ 継続的な課金を避けるため、このウォークスルーで作成したリソースは終わったら削除します。最初にコレクションを削除してコレクショングループを空にし、次にグループを削除し、最後にセキュリティポリシーとアクセスポリシーを削除します。 # Look up the collection ID, then delete the collection COLLECTION_ID=$(aws opensearchserverless batch-get-collection \ --names product-vectors \ --query 'collectionDetails[0].id' \ --output text \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2") aws opensearchserverless delete-collection \ --id "${COLLECTION_ID}" \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Look up the collection group ID, then delete the collection group GROUP_ID=$(aws opensearchserverless batch-get-collection-group \ --names product-search-cg \ --query 'collectionGroupDetails[0].id' \ --output text \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2") aws opensearchserverless delete-collection-group \ --id "${GROUP_ID}" \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Delete the security and access policies aws opensearchserverless delete-security-policy \ --name product-vectors-encryption \ --type encryption \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" aws opensearchserverless delete-security-policy \ --name product-vectors-network \ --type network \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" aws opensearchserverless delete-access-policy \ --name product-vectors-data \ --type data \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" 既存のコレクションのアップグレード 新しいアーキテクチャに移行するには、新しいコレクショングループとコレクションを作成し、データを再インデックスします。再インデックスの手順は Amazon OpenSearch Ingestion を使った Amazon OpenSearch Serverless での再インデックスの実行 に詳しく解説しています。クエリとインデックスマッピングは同じままで、変わるのはコレクションエンドポイントだけです。新しい静的リージョナルエンドポイントなら、これは 1 回限りの更新で済みます。 新しいアーキテクチャは SEARCH と VECTORSEARCH のコレクションタイプをサポートします。TIMESERIES はローンチ時にはサポートされません。 まとめ 新しい Amazon OpenSearch Serverless アーキテクチャは本日から利用可能です。Express Create を使えば最初の OpenSearch Serverless コレクションを数秒で作成し、本番トラフィックに対応するようスケールでき、アイドル状態になれば OpenSearch Serverless のコンピューティングコストはゼロまで下がります。 詳細は次を参照してください。 Amazon OpenSearch Service ドキュメント 。 Amazon OpenSearch Service コンソール 。 Amazon OpenSearch Service 料金ページ 。 質問やフィードバックがあれば、サポートケースを開くか、AWS アカウントチームを通じて連絡してください。皆さんが構築するものを楽しみにしています。 著者について Sohaib Katariwala Sohaib は AWS の Senior Specialist Solutions Architect で、イリノイ州シカゴを拠点に Amazon OpenSearch Service を担当しています。データと分析に関するあらゆる事柄に関心があります。特に、お客様がデータ戦略の中で AI を活用し、現代的な課題を解決できるよう支援することを楽しみにしています。 Raj Ramasubbu Raj は AWS の Senior Analytics and AI Specialist Solutions Architect で、ビッグデータ、分析、AI/ML に注力しています。お客様と協力して、高いスケーラビリティ、パフォーマンス、セキュリティを備えたクラウドベースのソリューションを設計・構築しています。 Arjun Nambiar Arjun は Amazon OpenSearch Service の Product Manager です。多種多様なソースから Amazon OpenSearch Service へ大規模にデータを取り込めるようにする取り込み技術に注力しています。Arjun は大規模分散システムやクラウド中心の技術に関心があり、ワシントン州シアトルを拠点としています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

はじめに こんにちは、WEAR開発部SREブロックの木内です。普段は WEAR のSREとして開発、運用に携わっています。 WEARは2013年にサービスを開始し長年オンプレミスで運用されてきましたが、過去にクラウド（AWS）へのシステムリプレイスを実施しています。その際にWebアプリのCDNとして Fastly を採用し、オンプレミスからクラウドへの段階的な移行を実現しました。 採用の決め手は主に以下の点です。 パスベースのルーティングが可能（パスごとにオンプレミスとクラウドのオリジンを切り替えられる） ネイキッドドメインへの対応 設定変更の即時反映による迅速なロールバック リプレイスの詳細については、以下の記事をご参照ください。 techblog.zozo.com Fastlyを用いた構成はサービスを止めずに安全なリプレイスを実現するうえで大きく貢献しました。一方で、リプレイスが完了しFastlyを導入した当初の目的を達成した後も残り続けたことで、運用負荷やコストといった課題が顕在化してきました。 本記事では、過渡期の構成を整理し、CDNをFastlyからAmazon CloudFront（以下、CloudFront）へ移行してAWSに統一した取り組みを紹介します。 目次 はじめに 目次 移行の背景・課題 運用負荷 コスト 移行後の構成 移行方法 1. LP・アセットの切り替え 2. 動的コンテンツ・認証処理の切り替え 3. VCLの処理をCloudFront Functionsへ移行 4. DNS切り替え WAFの移行タイミング 設計のポイント 移行期間中のリクエスト CloudFront Functionsを用いたリダイレクト・リライト カスタムエラーレスポンス 得られた成果 運用のシンプル化 インフラコストの削減 まとめ 移行の背景・課題 移行前の構成は以下の通りです。 Fastlyをフロントに置き、バックエンドにALBとS3が2つずつ、計4つのオリジンを持つ構成です。 ALBは動的コンテンツの配信や認証処理を担っており、S3はLPやアセットなどの静的コンテンツを配信しています。S3の前段にはそれぞれ個別のCloudFrontを使用しています。 また、FastlyではVCL 1 を用いてCDN以外の多くの処理も担っていました。 パスごとのオリジン振り分け 各種ブロック（IP / ASN / リファラ など） Basic認証 メンテナンスモード リダイレクト / リライト 前述の通り、リプレイス時にFastlyを採用したことで安全にリプレイスを進めることができましたが、リプレイス完了後に以下のような課題が残りました。 運用負荷 AWSとFastlyの二重管理が運用負荷に繋がっていました。 WEARの大部分はすでにCloudFrontを使用しており、2つのCDNそれぞれでキャッチアップが必要だった AWSとFastlyそれぞれでユーザーやリソースの管理も必要だった 設定変更をWebチームとSREチームで担っていたため、Fastly専用のインフラリポジトリを別途設けており、CIの整備やレビューフローの維持など、リポジトリが増えることに伴う管理コストが発生していた コスト FastlyをAWSの前段に置く構成であるため、大きく分けて2種類のコストが発生していました。 Fastlyがユーザーへ配信するコスト AWSがFastlyへ配信するコスト また、LPやアセットはすでにCloudFrontを使用していたため、FastlyとCloudFront両方のCDNコストが発生していた点も見過ごせません。 これらの課題を解消するために、CDNをCloudFrontへ移行し、配信基盤をAWSへ統一する方針を取りました。 移行後の構成 移行後の構成は以下の通りです。 移行後は、ALB・S3など全てのバックエンドの前段に1つのCloudFrontを配置しています。 また、FastlyのVCLで実施していた処理はそれぞれ対応するAWSサービスへ移行しました。 処理 Fastly AWS CDN・配信 Fastly CDN CloudFront パスごとのオリジン振り分け VCL CloudFront（Cache Behavior） 各種ブロック（IP / ASN / リファラ など） VCL AWS WAF Basic認証 VCL AWS WAF メンテナンスモード VCL AWS WAF リダイレクト / リライト VCL CloudFront Functions Basic認証・メンテナンスモードはAWS WAF（以下、WAF）の カスタムレスポンス機能 を利用して実装しています。WAFのルールにマッチしたリクエストに対して、任意のHTTPステータスコード・レスポンスヘッダー・レスポンスボディを返せる機能です。 セキュリティ関連の処理をWAFに集約することで一元管理できることに加え、CloudFront Functionsのコードサイズや実行時間の制限 2 を避けられる点も採用の理由です。 リダイレクト・リライトの実装にあたり、Lambda@EdgeとCloudFront Functionsを比較検討しました。Lambda@Edgeは複雑な処理や長時間実行に向いている一方、今回のような軽量なリダイレクト・リライト処理にはCloudFront Functionsが適しています 3 。加えてスケール量・リクエスト料金の面でも有利なため採用しました。 さらに、リダイレクト・リライトはルール数が多いため、jsをビルドしminify化しながらCloudFront Functionsのコードサイズ制限を超過しないよう工夫しています。 CloudFront KeyValueStore を使用したサイズ圧縮も検討しましたが、フロントとインフラ間の依存関係の簡素化や認知負荷の低減を優先したかったからです。 これらの設計を経て、FastlyのVCLに分散していたエッジ処理をAWS WAFとCloudFront Functionsに集約し、CDNレイヤーの機能をすべてAWS上で完結させる構成になりました。 移行方法 今回のCDN切り替えはフェーズを分けて段階的に実施しました。このCDNはPC・SP全体のトラフィックを受けているため、問題が発生すれば多くのユーザーへ影響が出てしまいます。そのため、いかにユーザー影響を出さず安全に移行するかが本プロジェクトの鍵でした。 具体的なフェーズは以下の通りです。Fastlyの後段にCloudFrontを配置し、影響範囲が小さいものから順にCloudFront経由へ切り替えていきました。 1. LP・アセットの切り替え 最初はS3で配信しているLPとアセットの切り替えです。静的コンテンツは影響範囲が限定的で切り戻しもしやすいため、最初の移行対象としました。 切り替えにあたっては全パスを網羅するURLリストを用意してスクリプトで動作確認を行い、移行前後の挙動に差異がないことを確認しながら実施しました。 2. 動的コンテンツ・認証処理の切り替え 次に動的コンテンツの配信や認証処理を担うALBの切り替えです。動的コンテンツの配信や認証処理を担っているため、CDN切り替えによるヘッダーやキャッシュの挙動の変化が配信や認証に影響を与えるリスクがありました。 影響範囲を抑えるためにALBは1台ずつ切り替え、バックエンドチームにも協力してもらい機能リグレッションがないことを確認しながら進めました。 加えて、ダークカナリアリリース（ユーザーには見えない形で一部のトラフィックを新しい構成に流し、本番環境で検証する手法）でCloudFront経由に流し、環境差異による不具合がないかも検証しました。 3. VCLの処理をCloudFront Functionsへ移行 続いてVCLのリダイレクト・リライト処理を移行しました。VCLの処理の中にはリクエスト元の国別判定をした上でリダイレクトをする処理もあり、障害につながりやすい部分であったため、切り戻しやすさを考慮して2段階に分けて対応しました。 動作確認はFastlyで実施していたリダイレクト・リライト処理を網羅的に検証できるスクリプトをWebチームが作成してくれており、そちらを活用し移行前後の挙動に差異がないことを確認しながら進めました。 スクリプトはDenoのテストフレームワークで書かれており、各パスへのリクエストに対してステータスコード・リダイレクト先・レスポンスヘッダーを検証します。さらにHTMLレスポンス内のJS・CSSアセットも正常に取得できるかまで確認しており、移行後の挙動を一通りカバーしています。 また、VCLの移行はオリジンの切り替えと異なり、パスごとに挙動が細かく異なります。そのため追加のスクリプトも作成し、リダイレクト・リライト対象外のパスへの影響がないか、Serverヘッダーでオリジンが意図した経路を通っているかを、1パスずつ地道に確認していきました。 4. DNS切り替え 最後にDNSを切り替えてFastlyからCloudFrontへ完全移行しました。 WEARはDNSに Akamai を使用しています。今回、Akamaiの Change List を活用し、ダウンタイムなしで切り替えを実現しました。 CloudFrontのIPアドレスは固定されていないため、FastlyのIPを登録していたAレコードからCloudFrontのドメインを指定するCNAMEへの変更が必要でした。しかしAレコードとCNAMEは共存できないため、削除と追加を別々に適用すると瞬断のリスクがありました。Change ListはDNSレコードの変更をまとめてアトミックに適用できる機能で、これを活用することでダウンタイムなしでの切り替えを可能にしています。切り替えは有事の際に素早く切り戻せるよう、事前にTTLを60秒に下げた上で実施しました。 また、次のセクションで詳しく説明しますが、ブロックやBasic認証等のWAF切り替えもこのタイミングで同時に実施しています。 WAFの移行タイミング WAFはIP・国・ASNなどの判定を、送信元IPまたはX-Forwarded-For（XFF）ヘッダーのIPアドレスを基に行います。 DNS切り替え前はFastlyがリクエストを受け取るため、AWS WAFから見るとアクセス元のIPがFastlyのIPになります。この状態でWAFを先に切り替えると、ブロックルールがFastlyのIPに対して適用され、意図しないブロックや、本来ブロックすべきリクエストが通過してしまうリスクがありました。 XFFを参照することでクライアントIPに基づく判定も可能ですが、以下の理由から採用しませんでした。 Fastlyの判定ロジックが送信元IPを利用しており、仕様を変えたくなかった DNS切り替え前後でXFFの内容が変わるため、切り替えのタイミングで挙動が変わることを避けたかった そのため、DNS切り替えまでの間はFastly側のブロック設定を残し、WAFの切り替えはDNS切り替えと同時に行いました。 なお、事前の動作確認はCloudFrontのFQDNに直接curlでアクセスして行いました。DNS切り替え前はFastlyがエンドポイントのため、CloudFrontのFQDNに対してアクセスする必要があります。CloudFrontはHTTPS接続時にHostヘッダーの値でSSL証明書を選択するため、Hostヘッダーにドメインを指定することで正しく証明書検証が行えます。 CloudFront FunctionsについてもDNS切り替え前はリクエストがFastlyを経由するため、リクエスト元の国別判定で同様の問題がありました。 こちらはWebチームが解決策を検討・実装してくれました。DNS切り替え前の移行期間中に限り、Fastly側でCloudFrontの仕様に準ずるヘッダーを付与しました。CloudFront Functions側でもそのヘッダーを参照することで、正しく地域判定が行える構成にしています。 設計のポイント ここまで移行の手順を紹介しました。次に、移行にあたって設計上特に考慮が必要だったCloudFrontのビヘイビア設計について紹介します。 CloudFrontでは、リクエストのURIパターンに応じて処理方法を定義する「 Cache Behavior 」という仕組みがあります。今回はオリジンの振り分けをビヘイビアで制御しており、その設計がFunctions実装やエラーハンドリングに直結するため、いくつか考慮する必要がありました。 移行期間中のリクエスト Cache BehaviorはURIパターンで 優先度順に評価 され、先にマッチしたものが適用されます。パターンにはワイルドカード（*）が使えますが、ワイルドカードなしの場合は完全一致での評価になります。 この仕様を踏まえてビヘイビアを設計しました。また、移行期間中はFastly側の既存のロジックでリダイレクトされたパスがCloudFrontに届くケースもあるため、リダイレクト後のパスに対応するBehaviorも明示的に用意しました。 CloudFront Functionsを用いたリダイレクト・リライト CloudFront Functionsを用いたリダイレクト・リライトの実装にあたり、CloudFrontの処理順序を正しく理解することが重要でした。 CloudFrontはリクエストを受信した時点のURIをもとにCache Behaviorを選択します。その後CloudFront Functions内で request.uri を書き換えても 選択済みのBehaviorは変わりません 。そのため、リライト後のパスが意図したオリジンに届くよう、元のURIの段階で適切なBehaviorを選択できる設計にしました。 カスタムエラーレスポンス CloudFrontの カスタムエラーレスポンス は、オリジンが特定のHTTPステータスコードを返した際に指定のパスへフォールバックできる機能です。今回はすべてのオリジンの404をALBオリジンのエラーページにフォールバックするよう設定しています。 カスタムエラーレスポンスは、CloudFront Functionsの挙動と違い フォールバック先に指定したパスでビヘイビアが再評価されます 。そのため、フォールバック先に指定したパスがALBオリジンのビヘイビアに正しくルーティングされるよう設計しました。 また、S3オリジンはデフォルトでオブジェクトが存在しない場合に404ではなく403を返すため、このままではカスタムエラーレスポンスが正しく動作しません。これを解消するために、 OAC（Origin Access Control） のバケットポリシーに s3:ListBucket を追加し、S3がオブジェクトの有無を判断して404を返せるようにしました。 { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Principal ": { " Service ": " cloudfront.amazonaws.com " } , " Action ": [ " s3:GetObject ", " s3:ListBucket " ] , " Resource ": [ " arn:aws:s3:::amzn-s3-demo-bucket/* ", " arn:aws:s3:::amzn-s3-demo-bucket " ] , " Condition ": { " StringEquals ": { " AWS:SourceArn ": " arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID> " } } } ] } 得られた成果 月間数億リクエストを処理するCDNの切り替えは、ユーザーへの影響が出れば大きな障害につながりかねないものでした。段階的なトラフィック移行や入念な動作確認を重ね、一切のダウンタイムなしで移行を完了できたことは、本プロジェクト最大の成果です。 加えて、今回の移行は単なるCDNの切り替えにとどまらず、長年の過渡期構成を整理し、運用・コスト・セキュリティの三面で改善を実現できた取り組みでした。具体的には次のとおりです。 運用のシンプル化 VCLに集約されていた処理がAWS WAFとCloudFront Functionsへ役割ごと分離されたことで、各機能の責任範囲が明確化しました。変更が必要な際も影響箇所を絞り込みやすく、必要な箇所だけ修正できるようになりました。 また、Fastlyのアカウント管理やVCL設定の維持が不要になり、AWSに運用を集約できるようになりました。 さらに、AWSに統一したことで、追加機能の検証や導入の敷居も下がりました。 実際に、移行完了後1か月以内にAWSが提供する WAFマネージドルール の追加導入が完了しています。WAFのCountモードで事前に検証し、誤検知がないこと・不審なリクエストのブロック効果があることを確認した上で導入を判断しました。 今後も既存のルールを拡充し、さらなるセキュリティ強化を進めていく予定です。 インフラコストの削減 コスト削減は今回の移行における主要な目的の1つであり、結果としてCDN関連のインフラコストを 約40％削減 できました。 主な内訳は以下です。 CloudFrontをCDNとすることにより、ALBからのトラフィックコストが大幅に緩和されたこと LPとアセットで発生していた二重の配信コストが解消されたこと この削減は構成変更による恒久的なものであり、継続的なコスト改善として今後も効果が持続します。 まとめ 本記事では、FastlyからCloudFrontへの移行を通じて、CDN構成をAWSに統一した取り組みを紹介しました。 今回の移行は単なるCDNの乗り換えにとどまらず、長年の過渡期構成を整理し、運用・コスト・セキュリティの三面で改善を実現できた取り組みでした。 「当時は最善だった構成が、今となって見直しどきを迎えている」という状況は多くのサービスで共通する課題だと思います。CDNの移行や構成整理を検討している方にとって、本記事が参考になれば幸いです。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com VCL（Varnish Configuration Language）はVarnishというキャッシュサーバー向けの設定言語です。 ↩ CloudFront Functionsはコードサイズが10KB以下、実行時間が1ms以下という制限があります（参考： CloudFront Functions のクォータ ） ↩ CloudFront Functions と Lambda@Edge の違い ↩