re:Invent 2025: Amazon CloudWatchでセキュリティと可観測性データを統合する新機能
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Observability & Security unite: Unify your data in Amazon CloudWatch (COP361)
この動画では、AWS re:InventでCloudWatchの新機能が発表され、セキュリティと可観測性のデータを統一する方法が紹介されています。企業が直面するデータの断片化問題、特にセキュリティチーム、可観測性チーム、監査コンプライアンスチームがそれぞれ独自のツールとデータストアを持つことで生じる課題が説明されます。CloudWatchは統合ストアとして、65以上のAWSサービスからのログ収集、CrowdStrikeやOktaなどのサードパーティコネクタ、クロスアカウント・クロスリージョン集約、S3 Tablesとの統合、Facetsによる高速分析などの機能を提供します。S&P Globalの導入事例では、設計の簡素化と20～25%のコスト削減が実現されました。デモでは、Facetsを使った迅速なトラブルシューティングとSageMaker Unified Studioでの分析が実演され、データソースベースの管理エクスペリエンスが紹介されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
セッション概要：CloudWatchの新機能とセキュリティ・可観測性データの統一管理
皆さん、本日はご参加いただきありがとうございます。re:Invent の調子はいかがでしょうか。私は Nikhil Kapoor で、CloudWatch のプリンシパルプロダクトマネージャーをしています。このセッションは COP 361 で、本日午前のキーノートで発表された CloudWatch の新しいローンチについてお話しします。具体的には、AWS 内でセキュリティと可観測性のデータを統一し、シンプルな方法で管理するのをどのようにサポートしているかについてです。本日は、CloudWatch のエンジニアリング責任者である Avinav Jami、そして S&P Global のクラウドソリューションエンジニアリング責任者である Chandra が一緒にいます。Chandra はこのソリューションの早期導入者として、彼らの事例をお話しします。
では始める前に、このセッションで取り上げる目標をおさらいして、レベルを合わせておきましょう。まず、大企業やエンタープライズが直面する一般的な課題についてざっと説明します。セキュリティ分析と可観測性の両方に関して、彼らが対処しなければならないデータの膨大な量についてです。データの膨大な量について話すとき、それはほとんどログです。ログとは愛と憎しみの関係にあります。お客様から聞く課題の一部をお話しし、その後、これらの課題に対応するために本日発表した改善についてお話しします。
最後に、このソリューションの使い方だけでなく、組織としてのデータ管理の取り組みをどのように考えるか、そしてデータの断片化に関する課題についても、実践的なヒントをお伝えしたいと思います。では、本日のアジェンダを簡単にまとめます。課題について説明し、ソリューションについて話し、S&P Global の導入事例についてお話しし、最後に重要なポイントと参考になるリソースをまとめます。
企業が直面するデータ断片化の課題：チーム間の分断とログ管理の複雑性
では、課題についてです。簡単に手を挙げていただきたいのですが、皆さんの組織にセキュリティチーム、可観測性チーム、場合によっては監査コンプライアンスチームのような構成がありますか？いいですね。そう予想していました。課題を見た後は「いい」とは言わないかもしれませんが、説明していきましょう。通常、私たちが見るのはこのような構成です。正当な理由から、皆さんの会社、顧客、そしてそのデータが保護されていることを確認するのが仕事の専任セキュリティチームがいて、彼らはそのソリューション向けに特別に設計された専用ツールセットを使用しています。これは理にかなっています。
同様に、可観測性チームは独自のツールセットを持っており、多くの場合複数のツールを使用して、システムの運用上の健全性とパフォーマンスを可視化しています。最後に、組織によっては、すべてのデータが 1 か所に、手を加えられずに到着する必要がある専任の監査およびコンプライアンスフレームワークがあり、彼らは独自のツールセットを持っています。これは素晴らしいことです。これらは特定のニーズに対応しています。これらは自分たちが何をしているかを知っているスペシャリストなので、その特定の仕事をうまくこなせる必要があります。ですから、それについて何も問題はありません。
ただし、スタックを下っていくと、ここにトレンドが見えてきます。ツールと人材がそれに特化しているだけでなく、基礎となるデータもそのツールに紐付けられていることが多いんです。そしてその結果として、こういった状況が生まれるわけです。問題が複数のドメインにまたがっているとき、セキュリティチームの誰かが DevOps チームや SRE の誰かに電話をかけて、「ねえ、何が起きたの？なんで君たちこれを直してないの？」と聞くんです。そうすると相手は朝の3時に起きて、「何の話をしてるんだ？俺は何も知らないぞ」と言うわけです。つまり、手動でのコミュニケーションが洞察を遅くし、結果を遅くしてしまうという問題に直面するんです。
では、さらに一層剥いていきましょう。なぜそんなことが起きているのか？なぜこれらの個人が同じ景観を見ることができず、問題をより速く、より簡単に理解できないのか？多くの場合、それはツールに遡ります。ツールは、そのツールが設計された、あるいはセットアップされた特定のことに限定された洞察を与えているんです。ツールに反応する人間は、自分が見えるものにしか反応できません。さらに一歩進めて考えると、なぜツールは同じ洞察を得ることができないのか？
例を挙げてみましょう。セキュリティチームが突然、ファイアウォール経由で大量の拒否を見ているとします。同時に、アプリケーションチームは大量のトラフィックスパイクを見ていて、どうしたらいいかわかりません。セキュリティチームは DDoS 攻撃の可能性があることを知っています。アプリケーションチームは知りません。彼らはインフラをスケールアップしようとしていて、大量の顧客がいると思っているんです。もし彼らが全員、インフラをスケールアップしようとするのではなく、セキュリティ DDoS 攻撃の試みが起きていることを見ることができたら、素晴らしくないですか？彼らは特定の IP サブネットなり何なりを隔離する必要があります。つまり、これは人とそれが使用しているツールが共通の情報セットで機能していないという問題に遡るわけです。
このレイヤーの最後の部分が、実は最も興味深いんです。
これを調べたとき、このデータソースがどのように機能するのかを聞いたんですが、基礎となるデータが大部分において同じであることに気づくと、データソースは大部分において同じなんです。AWS サービスログがあり、CloudTrail があり、アプリケーションログがあり、CrowdStrike や Okta のようなサードパーティツールがあります。これらのログソースはすべて大部分において同じです。同じデータが異なる場所に送られているんです。 ここにいる誰かで、これらのデータパイプラインを管理している開発者がいたら、私は同情します。私たちが複数の顧客を調べたとき、彼らは「同じログを持っている。クラウドログはここに行く必要があり、あそこにも行く必要がある」と言いました。多くの場合、このデータはある場所から別の場所にコピーされ、これらの ETL パイプラインのクモの巣のような情報が、あちこちから行ったり来たりしているんです。これは管理するのが悪夢で、新しいワークロードや新しいリージョンをオンボードする必要があるたびに、同じことが起きます。ただ複雑さが増すだけなんです。
これが私たちがここで議論しようとしていることです。これらが私たちが対処する必要がある高レベルの課題です。どうすればチームにより早く包括的な洞察を提供できるのか。DDoS 攻撃の例で述べたような問題を検出して対応する能力をどう高めるのか。このクモの巣のようなデータパイプラインの運用オーバーヘッドをどう削減するのか。新しいワークロードをどのくらい迅速に有効にできるのか。そして最後に、決して重要ではないわけではありませんが、コストです。3つの異なるストア、5つの異なるストアにわたるこのすべてのデータ重複、同じデータ、さらには同じ VPC Flow Logs、同じ CloudWatch ログが複数の場所で複製されています。これが私たちがこの旅を始めたときに自分たちに設定した目標です。
CloudWatchによる統合ストアソリューション：収集からキュレーション、分析まで
では、どのようにお手伝いできるのでしょうか。これについてご説明するために、Avinav をステージに招待します。ソリューションについてご説明し、どのようにお手伝いできるかをお話しします。ありがとうございます、Nick。特に前のスライドで運用オーバーヘッドについて話したとき、それは私たちが直接経験してきたことです。独自の ETL パイプラインを管理し、データをロードし、バージョンを管理し、データロードが停止するたびに、バックフィルをどのように行うかを把握することは、より多くのコストを導入するなど、他のすべての側面に加わります。私たちは、顧客向けのソリューションを考え出す方法を再考することから始めました。これはこのプロセスを簡素化するものです。
私たちは、observability、security、audit の領域の境界線をどのようにぼかすかについて考えました。ここで境界線をぼかすことは、すべての異なるペルソナに対して単一のツールを使用することを意味するわけではなく、異なるビジネス上の問題に対して同じエンジニアのセットが操作することを意味するわけでもありません。しかし、私たちは問題が本当にどこに存在するのかについてより深く考えました。問題は実際には基盤となるデータストア層に存在することに気付きました。これは、包括的で一貫性のあるデータストアを作成しようとするときに、多くのインフラストラクチャの重い作業が発生する場所です。すべての基盤となるログデータとテレメトリデータを備えており、ツールを使用する段階に到達できるまでです。私たちはそのデータストア空間で境界線をぼかすことについて考え、統一されたストアを作成するのを支援し、CloudWatch に新しい機能と新しい機能を組み込む方法を考え出し、統一されたストアを構築できるようにしました。
さらに一歩進めると、統一されたストアを構築したい場合、それを行うために必要なすべてのステップが何であるかについて考え始める必要があります。ここでの最初のステップは、すべてのデータの収集を開始することです。収集フェーズは通常、AWS サービス、アプリケーション、すべてのサードパーティソースからのログを単一の場所に持ち込むことを含みます。これは単にデータを正しい方法で取得することだけではなく、一貫して正しい方法で到着することを確認することでもあります。次はキュレーションです。キュレーションフェーズでは、分析ニーズに合わせてデータを形成しようとしています。つまり、どのフィールドが本当に価値があるのか、どのようなダッシュボードを最終的に配置するのか、どのようなクエリを最終的に実行するのか、それを効果的にするためにどのような情報が必要なのかについて考えています。
ログをどのようにエンリッチできますか。正しいフィールドが正しい形式で存在することをどのように確認できますか。そして、それに対して発生する必要がある変換は何ですか。また、高速ダッシュボードを構築したり、正しい情報をすばやく取得するクエリをスピードアップするのに役立つインデックスを作成することも意味します。これらすべては、柔軟なストレージレイヤーによってサポートされる必要があります。ストレージは、通常、顧客にとって多くのコストが発生する場所です。顧客が長期間保持したいデータセットがあります。特にセキュリティ目的のためのデータセットがあり、より運用的な性質のデータセットもあります。2つのデータセットを異なる方法で変換できるようにしたいと同時に、本質的に単一のコピーを保持しています。最後に、そのストアから強力な分析と洞察を得たいと思います。リアルタイムログをすばやく確認し、複数のクエリ実行を必要とする深い掘り下げを行うことができるようにしたいと思います。
では、CloudWatch を統合ストアとして紹介します。CloudWatch を単一のセキュリティおよび可観測性データのストアにする多くの機能があります 。収集の最初のステップとして、CloudWatch は現在すでに 65 以上のサービス全体で利用可能です。30 の新しいサービスを導入しており、これでログが CloudWatch 内でアクセス可能になります。これら 30 のサービスには、Network Load Balancers、CloudFront、Petrock Agent コアログなどのサービスが含まれます。また、マネージドコネクタアプローチを通じてサードパーティログも導入しており、これはサードパーティソースからログを取得するためにコードを書く必要がないということです。ローンチ時には 10 のコネクタがあり、CrowdStrike と Okta が含まれており、年間を通じてさらに多くのサードパーティコネクタを追加し続けます。
また、お客様は組織レベルでのセキュリティおよびガバナンスコントロールを求めています。つまり、組織レベルで CloudTrail または VPC のログをオンにできるということです。今年は CloudTrail、VPC、NLB などの組織レベルの有効化サポートを開始します。キュレーションフェーズでは、お客様はしばしば分析ツールが活用する方法でデータを形成する必要があります。OCSF および OEL データ用のすぐに使えるトランスフォーマーを導入しています。お客様はまた、パイプラインを使用して必要に応じてデータを形成できます。Grok プロセッサを使用してカスタム解析、フィールドレベルの操作、文字列操作を行うことができます。
すでに認識しているソースおよびタイプ情報を識別し、それをログ全体に渡す機能を追加します。これはソースおよびタイプ情報がベンダーテレメトリ内で利用可能になり、カスタムログに追加することもできるということです。タグを使用してソースおよびタイプ情報を追加できるため、リソース、ロググループなどについて考えるのではなく、より応用レベルで操作できるようになります。 ストレージレベルでは、お客様が最も望む柔軟性は、データがどのくらいの期間保持されるか、データがどのように構造化されるか、そして異なる場所に存在するかどうかを制御するのに役立つことです。
特に可観測性の分野の多くのお客様は、データを可観測性アカウントに保持したいのですが、セキュリティまたは中央オペレーションに関しては、データを単一のスペースに保持したいと考えています。新しいクロスアカウント、クロスリージョン集約機能を導入しており、これはルールの助けを借りてログテレメトリを単一の場所に集約します。また、個別の保持ポリシーを作成することもできます。ログを取得する際に変換することができます。私が説明したすべてのエンリッチメント機能は、ソースストアとは異なる集約ストアに適用できます。つまり、セキュリティまたは可観測性のニーズに最適なデータのバージョンを作成できます。
最後に、統合データストアは多くの強力な分析機能を提供する必要があります。CloudWatch は現在すでに Insights、ライブテーリング、トップエンド分析などの強力な機能をサポートしています。 これで非常にエキサイティングな 2 つの機能を導入しています。1 つ目は S3 Tables を作成できることで、本質的には選択した任意の分析エンジンに接続できるようになります。2 つ目は Facets です。Facets は、Insights のクエリエクスプローラーページに移動するときに、異なるフィールドに対してすぐに使える体験を得られるインデックス機能の次世代です。
これにより、クエリをどこから始めたらいいかわからない場合でも、最初の深掘りを始めることができます。Insights ページに行くと、クエリを書くためのフィールドが表示されます。しかし Facets を有効にすると、フィールド値を確認することができるようになります。エラーレベルの Facets は、エラーが正確にどこで発生しているのかを特定するのに役立ちます。その後、さらに深掘りして、次に service-level の facets を確認する必要があることに気づくかもしれません。これらの facets をクリックして進むと、クエリを書く必要なく、ページが自動的に更新され続けます。私たちの経験では、最初の深掘りの多くが今ではより簡単になっています。なぜなら、始める場所があるからです。
より複雑なクエリが必要になる時点では、query gen のような機能を使用して、プロンプトを素早く入力し、新しいクエリを作成することができます。機能のリストをまとめるために、私たちは CloudWatch store について考えました。私たちはそれを再構想し、ユーザーのニーズに対してはるかに柔軟で互換性のあるものにする機会を見つけました。
データサイロとして考えるのではなく、収集フェーズを通じて、組織全体の有効化とニュースソースの追加サポートを含む、多くの機能を追加しました。ログを変換および充実させるための機能として、パイプラインを利用可能にしました。ストレージレベルで運用し、集中管理されたストアを作成し、S3 テーブルを通じてオープンアクセスを提供しました。最後に、S3 テーブルに接続できる強力な Insights を提供しました。ここで、Chandra を紹介したいと思います。彼は、彼のチームが CloudWatch をどのように使用しているかについて説明します。
S&P Globalの事例：グローバル企業のログ統合要件
ありがとうございます。皆さん、こんにちは。この午後 4 時のセッションにご参加いただきありがとうございます。満席になっているのに本当に驚いています。簡単な質問から始めさせてください。ここにいる人の中で、S&P Global について、そして私たちが何をしているかを知っている人は何人いますか？1 人だけですか？わかりました。では、すべての株式とすべての企業のポートフォリオをランク付けして、それらが出入りするときにランク付けするわけですね。良い、非常に近いです。S&P 500 インデックスについて知っている人は何人いますか？ほぼ全員ですね。それは予想通りです。なぜなら、直接的または間接的に、この部屋にいるほとんどの人が S&P 500 インデックスの恩恵を受けているからです。
私の名前は Chandra で、S&P Global の企業部門からクラウドソリューションエンジニアリングを率いています。数ヶ月前に行ったログ統合の旅についてのいくつかの経験をお話しするために、ここにいます。これが皆さんの中で同じ道を歩みたいと思う人たちの役に立つことを願っています。S&P Global は、以前は McGraw Hill Financial として知られていたグローバル企業です。1800 年に設立され、世界中の金融市場向けのベンチマーク、データ、ソリューションの大手プロバイダーです。100 年以上信頼されている強いブランドを持っています。現在、世界中のクライアントにサービスを提供する約 40,000 人の従業員がいます。世界中に 50 のオフィスと 10 のデータセンターがあります。これら 10 のデータセンターは、主にネットワークギアと接続性に使用されています。
クラウドスケールの話に移りますが、ロギングについて話すときは、まず S&P Global がグローバルにどの程度の規模なのかを理解する必要があります。 私たちは戦略的な AWS リージョンを クライアントに近い場所でサービスを提供するために配置しています。これは多数のアカウント、 広範な VPC とクラウドリソースに相当します。これにより、膨大な量のログデータが生成されます。これが今回の議論と私たちが取り組んだ課題の焦点です。
既存のログパイプラインを見直す作業をしていたとき、ステークホルダーから多くの要件が出ました。 1 つの要件は、専用のログアーカイブアカウント、つまり中央アカウントと呼ばれることもありますが、そこに生ログを保存することです。これは法務とコンプライアンスチームからの要件で、法的目的のために改ざんされていない不変のログを見たいということです。 次に、別の専用セキュリティツーリングアカウントにキュレーションされたログが必要です。これはクラウドセキュリティと情報セキュリティチームからの要件です。彼らはクラウドセキュリティの可視性、どのログを収集しているか、誰が何にアクセスしているかを把握する必要があります。 もう 1 つの要件は、ローカルにアクセスログを持つことです。これはビジネスユニットからよく聞く要件です。ログを中央の場所に送っている一方で、トラブルシューティングのためにログをローカルで検索してアクセスできるようにする必要もあります。
その次に Security Operations Center チームがあります。彼らは特に脅威インテリジェンスとインシデント対応用にキュレーションされたログが必要です。 そしてもちろん、ログクエリです。これは誰もが必要とするものですよね。 必要なときに簡単にクエリを実行してログアクセスを取得できるようにする必要があります。そして最後に SIEM、Security Information and Event Management の最適化です。これは非常に重要です。なぜなら、これだけ多くのクラウドアカウントとクラウドリソースがあると、データが膨大になるからです。S&P Global では実は サードパーティの SIEM を使用しています。すべてを SIEM に取り込むことはできません。SIEM のコストが急増するからです。ですから、必要なログ、本当に必要なログをキュレーションして取り込む必要があります。
アーキテクチャの簡素化とコスト削減：AWSチームとのパートナーシップによる成果
これらすべての要件が設計の複雑さを増します。これは AWS チームが新しい要件に取り組んでいることを知る前に私たちが取り組んでいた設計です。その時点で設計を検討していたとき、CloudWatch の新しい機能について AWS チームが何か取り組んでいないか聞いてみようと思いました。そうしたら、彼らが実際に取り組んでいることがわかり、私たちは非常に興奮して AWS チームとパートナーシップを組みました。彼らはいつでも対応してくれます。電話をかけることもできます。彼らは私たちと一緒にパートナーシップを組んで、実際にこのアーキテクチャを見直すのを手伝ってくれて、複雑さを軽減してくれました。
複雑さについて言うと、ここを見てください 。複数の CloudWatch サブスクリプションがあります。Firehose を使用してログをディビジョナルアカウントから中央アカウントに移動する必要がありました。また、ログをセキュリティアカウントと複数の他のアカウントに送信する必要もありました。これがセキュリティツーリングアカウントで、これが中央アカウントで、このような複雑さがありました。設計のもう 1 つの複雑さは、管理する必要がある S3 バケットが多数あったことです。AWS チームとパートナーシップを組んだとき、彼らはこれを改善できると言いました。今はこのようになっています 。コンポーネントが少なく、CloudWatch ネイティブではるかにシンプルです。興味深い点は、内部の配線が処理されており、コストがかからないということです。
では、この取り組みの結果は何かというと、を簡潔にして、コストを削減しながら設計をシンプルにすることができました。さらに、ログのストレージ、キュレーション、処理のフェデレーテッドモデルを実現することができました。これにより基本的にはスケーラビリティが得られ、すべてのステークホルダーの要件も満たすことができました。そして最も重要なのはコストです。先ほど申し上げたように、現在の設計から少なくとも20～25パーセントのコスト削減を期待しています。
計画と開発フェーズを通じたこの取り組みの中で学んだ貴重な教訓があります。1つ目は、計画を立てて集約するということです。基本的には、単にログを収集するのではなく、ストレージ、キュレーション、アクセスに関する明確な戦略を持つことです。ログを徹底的に集約し、できるだけシンプルに保つことに注力してください。ユースケースに応じてログを収集・集約してください。これは非常に重要です。セキュリティを確保し、セキュリティ要件を満たすために、専用のアカウントでこれを行ってください。
2番目の教訓は、チームがいるところで対応するということです。ここがパートナーシップが活躍する場面です。なぜなら、多くの要件があり、誰もがログデータを自分たちのやり方で欲しいからです。チームがいるところで対応し、既存のワークフローに合わせてソリューションを適応させてください。万能なアプローチを強制しないでください。ステークホルダーと協力し、彼らのニーズが何かを理解してから、それをあなたのアプローチに組み込んでください。3番目の教訓は反復的ということで、私たちが実行するほとんどのプロジェクトはアジャイルで反復的です。私たちが学んだのは、小さく始めて、学んで、スケールしなければならないということです。このアプローチはリスクを軽減し、採用を改善します。ただし、チームが十分なログを持っていることを確認してください。
デプロイメントモデルと実践デモ：料金体系から具体的な使用方法まで
設計に見られるいくつかのことと、デプロイメントモデルについて話しますが、それらは S&P がどのように採用しようとしていたのか、そしてどのような要素を考慮すべきかを見た方法から生まれました。顧客や状態がどうなるかだけでなく、段階的なジャーニーは何かということです。では、これまでに見てきたいくつかのデプロイメントモデル、私たちが話してきた他の顧客がどのように採用しているか、そしてそれがあなたのジャーニーを始めるのにどのように役立つかについて話しましょう。
デプロイメントモデルに進む前に、コストについて話しましょう。これらすべてのマネージドパイプライン、すべてのレプリケーション、一元化について、どのくらいのコストがかかるのか疑問に思っている方もいるでしょう。そこで、これを私が言及したいくつかのコア機能に分解しました。Facets は、クエリを実行することなく、あなたが利用できる値の既製の分布です。分析を迅速化するだけでなく、どこを見るべきかさえわからないときに実行しているすべてのデータスキャンを節約できます。これらは無料で、standard class では追加料金なしで利用できます。
CloudWatch について詳しくない方のために背景をお話しすると、CloudWatch には 3 つの高レベルな料金体系があり、これを基本的な料金体系と呼んでいます。それは取り込み、ストレージ、そしてクエリまたはデータスキャンです。これらのコストに変更はありません。以前の価格のままで、何も値上げしていません。そのままです。さらに、取り込みの中には標準クラスと低頻度アクセスクラスがあり、その違いは本当に、どのような機能や処理時間の機能が利用できるかという点です。標準クラスは、リアルタイムの運用トラブルシューティング向けに構築されており、インデックスを持つことができ、より高速なリアルタイムクエリ体験ができ、アラームなども設定できます。
低頻度アクセスは、例えばコンプライアンスのユースケースのようなログ向けです。クエリする必要はありますが、朝の 2 時にリアルタイム分析が必要ではありません。ですから、低頻度アクセスを標準クラスの半分のコストで提供することで、柔軟性を持たせようとしています。これにより、どのクラスがそのログに最適かを選択する柔軟性が得られます。両方についてお話ししますが、まずこのコンテキストを設定したかったのです。
Facet は標準クラスでは無料で含まれています。低頻度アクセスについては、先ほど述べたようにそのユースケースと一致していないため、低頻度アクセスではサポートされていません。S3 Tables の統合は興味深いものです。この結果について考えていたとき、エンドユーザーがこのデータストアを使用するために、自分たちの好みのツールを手放す必要がないようにしたかったのです。それが私たちの目標の 1 つでした。つまり、それを取り除いて、セキュリティチームに「統一されたストアを作成しますが、使用しているものを手放す必要があります」と言うようなものではありません。それは機能しません。
代わりに、私たちが取った方法は、S3 Tables チームと提携して、ネイティブな Apache Iceberg サポートを実現することでした。つまり、Athena、Redshift、EMR などの AWS 分析ツールであろうと、他の Iceberg 互換ツールであろうと、どのクエリツールでも、このデータをその場でクエリできます。S3 Tables の統合、レプリケーション、ストレージ、テーブルメンテナンスを含めて、追加料金はありません。CloudWatch の料金に含まれています。S3 Tables で実行するクエリに対してのみ料金を支払います。読み取りは、追加コストなしで通常のクエリコストが適用されます。これは低頻度アクセスでもサポートされており、標準と同じモデルで、追加コストはありません。
ログの一元化は約 1 ヶ月前にリリースされました。「ローカルチームと部門チームが自分たちのデータにアクセスできるという素晴らしいことがあるのに、今は 1 つの場所に一元化し、セキュリティのためにもう 1 つの場所に再び一元化する。これはすべて取り込みと重複だ。誰がこれに対して料金を支払うのか」と疑問に思うかもしれません。取り込みとレプリケーションの観点から、最初のコピーに対する追加料金はありません。最初の集約されたコピーは無料です。2 番目のコピーについては、基本的にデータ転送コストで 5 セント支払うだけで、追加の取り込みコストはありません。
ただし、中央アカウントでそれらのログを再取り込みして再処理する完全な柔軟性があることに注意してください。ただし、最初のコピーには追加コストはなく、2番目のコピーには5セントかかります。その時点で複製されたデータを持っていて、保持期間を独立して管理しているため、ストレージ料金は別途適用されます。これは注意すべき重要なポイントです。集約化するときは、3つのコピー全体で5年の保持期間を持ちたくないですよね。Chandraが言及したように、中央アーカイブアカウントが何であるかを選択してください。長期ストレージを保持したい場所であれば、そこが実際の保持期間を保つ場所です。開発者、テスト、Lambda用のローカルアカウントでは、7年分のログは必要ありません。ライブテイルが数日間機能するだけで十分ですよね。ですから、ローカルアカウントの保持期間を下げてください。
変換とエンリッチメント用のパイプラインは追加コストなしで含まれています。組織レベルのログ有効化には追加コストがありません。既に CloudWatch 料金に含まれていた同じログ取り込みとストレージに対してのみ支払います。これは infrequent access でもサポートされています。私が「コスト無料」についてコメントしていたことについて、どのような状況かを説明しようとしています。これは、顧客が簡単に試して、見て、反復処理できるように構築したかった機能がすべてここにあります。「あ、この機能を有効にしたら何が起こるんだろう」と考えずに済むようにしたかったんです。そういうことはしたくないんです。これがコストです。
では、どのように始めるのでしょうか。顧客が使用しているのを見かけたいくつかのデプロイメントモデルについて説明します。1つは、私が「分散集約化」と呼んでいるものです。これは一般的な例です。下部には、既に CloudWatch に送信されているすべてのログソースが表示されています。例えば、個別のアカウント、500個のアカウント全体の VPC フローログがそれらのアカウントに送信されています。これらのチームもそれらが必要だからです。CloudTrail でも同じことが当てはまります。ローカルチームも CloudTrail ログが必要で、中央チームもそれが必要な場合があります。
ですから、これらのログを有効にします。ローカルアカウントで利用可能になります。さらに、バックグラウンドで完全に管理された方法で observability アカウントに複製されます。必要なログはどれでも、セキュリティアカウントにも送信することを選択できます。これらのログはセキュリティにのみ関連し、そこにのみ送信されると決定できます。この時点で、3つのチームがそれぞれ必要な方法でそれらのログを使用しており、妥協がありません。互いのワークフローを妨げることなく、独立して変換とエンリッチメントを行うことができ、CloudWatch、Athena、Redshift、その他のツール、または Apache Iceberg 互換ツールなど、選択したツールを使用できます。それらは、以前に構築する必要があった複雑な配管をすべて構築することなく、ワークフローを実行できます。
これが1つのモデルです。2番目のモデルは、S&P Global が開始したものと似ており、「集約化して配布」というものです。これは、すべてを1つの中央アカウントに取り込むモデルで、コンプライアンスの単一の情報源として機能しますが、どのデータがどこに送信される必要があるかを分岐させるための単一の場所としても機能します。200個のアカウントでここに配管を引いたり、あそこに配管を引いたりする代わりに、1つの場所です。ちなみに、アカウント全体だけでなく、リージョン全体でも可能です。ディザスタリカバリーなどのために23の異なるリージョン全体で運用している場合、すべてを1つの場所で行うことができます。集約化はバックアップリージョンも提供します。
リージョン全体で一元化すると、アクティブ・アクティブバックアップを作成するオプションがあります。つまり、あるリージョンで何か問題が発生した場合でも、データへのアクセスは維持できるということです。この一元化・分散モデルでは、すべてが一箇所にあり、その後、データをどこに送るかを決めます。ログを同じソリューションに送りたい場合は、必要なものをフィルタリングして、不要なものは送らないようにできます。これらは、お客様が使用しているのを見かけた2つの異なるデプロイメントモデルです。
では、この時点で簡単なデモをやってみましょう。たくさんのスライドをカバーしてきたので、デモに切り替えましょう。 私のセットアップでは、ほとんどの本番グレードのアプリケーションが持つと予想されるものを表現しようとしているデモがあります。 PayStream という決済会社があり、大量の顧客向けに決済を処理しています。複数のアカウントとリージョンで運用して、エンドカスタマーにより近い場所にいます。決済を実行したところ、いくつかのエラーが見えています。つまり、いくつかの決済が失敗しています。
では、この状態で私は何をするでしょうか？開発者、SRE、またはサポート担当者として、決済が失敗しているという連絡を受けた場合、その時点での最初の質問は、どこから始めるかということです。そこで CloudWatch に行き、このページ、Logs Insights ページに着きます。どのリージョンとアカウントに行くべきかをマッピングしようとして、15個の異なるタブを開いてその結果に到達することもできます。しかし、この場合、私がやっているのは、私たちが示していた facets を使用することです。 少しズームインして見やすくしましょう。この facet にログインすると、クエリを実行することなく、2つのことができます。まず、エラーが発生しているかどうかを確認できます。通知の失敗、決済処理の問題、検証の失敗が見えています。ここで確実にいくつかのエラーが発生しているのが見えます。
では、どのサービスをトラブルシューティングすべきかについて、payment process をサービスとして選択します。すべての異なるイベントを見る前に、範囲を絞り込みます。 それを選択すると、クエリを実行することなく、私が関心を持っていた他のものがリアルタイムで更新されました。 確実にエラーがあります。これは、私がこれまでここで示したことを確認するために、2つか3つの異なるクエリで行ったであろうことの例です。これを収集するだけで、これが私が関心を持つサービスであることが見えます。リアルタイムで、過去1時間に690件の決済が失敗したことが示されました。まあ、それは良いことです。つまり、決済の失敗があったことを確認しました。
では、失敗がどこで発生しているかを検証できます。 今からやろうとしていることは、クエリを実行することですが、今は私のスコープをズームインしています。ログのすべてにわたってクエリを実行する方法がわかりません。何が起こっているのかを理解しようとするだけです。 ここに事前に構築されたクエリがあります。 このクエリを実行するために facets を選択します。
Payment process service を選択します 。それから、興味のあるイベントタイプを選択します。成功しているケースがどこで起きているのかも見たいので 、success と validation failed の両方を選択しましょう。では、このクエリを実行してみます 。どのような結果が得られるか見てみましょう。これを大きくしてみます。では、ここから見えることは、左側に異なるリージョンにある異なるアカウントがあり、私の全体的なリソースにまたがっているということです。ログを 一箇所に集約することで、タブを開かずに一箇所で分析できるだけでなく、すべてのエラーをすばやく特定でき、この無効な支払い失敗の理由を特定し、このリージョンのこのアカウントを特定することができました。これでなぜこのようなことが起きたのかを理解するために、次のクエリに進むことができます。
次に行うことは、CloudTrail ログをクエリすることです 。ここで CloudTrail を選択します。Avina が言及した、もう一つ導入したものは data source です。つまり、ロググループやリソースについて考えるのではなく、CloudTrail ログを見たいということを知っています 。CloudTrail と言うだけで、CloudTrail を選択します。どこにあるかについて考える必要はありません。AWS がすでにそれをマッピングしてくれています 。このクエリを実行すると、この Lambda 関数に何が起きたかが表示されます。誰かが意図しない変更を加えたに違いありません。何が起きたのか見てみましょう。 ああ、誰かが変更を加えました。パラメータを 128 から変更しました。そして見てください、Cole Pritt という名前の誰かが変更しました。 これが簡略化されたアナリティクスの例です。お気づきかもしれませんが、クエリ機能は facets を除いて劇的に異なるわけではありませんが、データを一箇所に集約し、私たちが行えた方法でデータをキュレーションすることで、これらのより速く、より良いインサイトが得られるようになります。
では、これが CloudWatch の内部の部分でした。では、私たちが言及したこのもう一つのツールはどうでしょうか？SageMaker Unified Studio に切り替えます。SageMaker Unified Studio に詳しい人はどのくらいいますか？ 何人かいますね。では、説明します。SageMaker Unified Studio は AWS のネイティブアナリティクスツールです。Jupyter notebooks と Athena クエリで高度なアナリティクスとデータを実行する機能を提供し、S3 Tables はカタログにネイティブに統合されています。SageMaker Unified Studio に移動すると、カスタムカタログと S3 テーブルカタログの両方を見ることができます。
CloudWatch で S3 Tables 統合をセットアップすることで、このアカウントに関連付けられているすべての CloudWatch ログが、このマネージド S3 バケット AWS CloudWatch の下に表示され、関連付けたすべてのログソースがすでにここにあります。では、デモのシナリオに戻ります。支払い処理を示していたシナリオですが、Lambda で誰かが変更を加えて問題を引き起こしたことを特定しました。同時に、私のような製品チームの人々は、エンジニアに対して、どの顧客が影響を受けているのかを知る必要があり、彼らに連絡して影響を把握できるようにしてほしいと言っています。今すぐ必要です。実際の問題を修正しようとしている一方で、自分たちの仕事をしようとしているこれらの人々に対応しなければなりません。
しかし、過去には、ライブデータをエクスポートして彼らに渡し、彼らがブロックされずに自分たちのことができるようにしなければなりませんでした。今はそうする必要がありません。ログが SageMaker で利用可能だと言うだけで、どの顧客が影響を受けているかを見つけてもらい、彼らは Athena や Redshift の他の S3 テーブルや S3 バケットでビジネスデータと分析を接続し、顧客の使用パターンや誰が影響を受けているかを自分たちで見つけることができます。異なるペルソナ、同じログ、インサイトを得ることができます。
では、デモで最後にお見せしたいことが1つあります。スケール時の管理の簡素化という観点から、もう1つやったことがあります。単一のアカウント内で運用している場合、ロググループとリソースは意味がありますが、数百のアカウントと数百のリージョンにわたって運用することを考えると、かなり煩雑になる可能性があります。より大きな視点、より高いレベルでのデータの全体像が必要になります。そこで CloudWatch に、この新しいログ管理エクスペリエンスを導入しました。ユーザーがすでに慣れ親しんでいるロググループに加えて、すべてのデータの高レベルなサマリーが表示されるので、何が、どこに取り込まれたのか、そして誰がスペースを占有しているのかを確認できます。もし何かが急激に増加した場合、ここで素早く特定できます。最近実行されたクエリ、設定されている構成、そしてどのデータ保護ポリシーが有効になっているか無効になっているかを確認できます。つまり、CloudWatch 内でネイティブに、純粋なデータ管理の観点から、何が機能しているか、していないかのトップレベルビューが得られるわけです。では、異なるデータソースを分析する観点から、このプレゼンテーション全体を通じてデータソースについて言及した頻度から、データソースという概念がいかに重要かがわかるはずです。私たちは皆、CrowdStrike データ、VPC Flow Logs、CloudTrail ログなどのソースを扱っていますので、それらを粘り強く、簡単に識別できるようにしたいと考えました。データソースベースのエクスペリエンスを追加しました。ほとんどの AWS ソースは自動的にマップされます。有効にしていれば、何もする必要はありません。このページにアクセスすると、すでにそこに表示されています。それだけでなく、スキーマが利用可能な場合は、デフォルトでスキーマ化されています。何かを分析しようとするとき、どのようなフィールドが利用可能か、利用不可かを確認できます。
この場合、Bedrock runtime はデフォルトでこれら4つのフィールドを送信しています。それらが何であるかについて考える必要はありません。利用可能です。これが重要なのは、Iceberg エクスペリエンスでは、これらのカラムとフィールドをできるだけアクセスしやすくしたいからです。その上に、この全体的なスキーマ検出エクスペリエンスを構築しました。ここから戻ると、S3 Tables 統合がアクティブになっていることが確認できます。では戻ると、1つのデータソースに対してこの S3 Tables 統合を有効にすることができます。その製品マネージャーが何をしたいのか分からないので、何を公開するかについて選別したい場合です。あるいは、すべてを公開したいというユースケースがある場合、統合を管理して、複数選択の方法ですべてのデータソースを公開することもできます。
まとめ：ビルディングブロック方式による段階的な導入アプローチ
これは1回限りの操作です。この統合を有効にすると、これらのデータソースの将来のデータはすべて自動的にミラーリングされ、選択したツールで利用可能になります。これでデモの部分は終わりです。では戻って、ここまで話したことすべての簡単なまとめをしましょう。主なポイントは以下の通りです。まず、データフラグメンテーションが問題であることに、皆さんも同意していただけると思います。データフラグメンテーションは複雑ですが、私たちにとって解決することが重要です。データフラグメンテーションが企業内、AWS 内のアカウントとリージョン内、そしてユースケース内でどのような課題と問題を生じさせるかについて説明しました。データフラグメンテーションにはさまざまなレベルがあり、私たちの目標はできるだけ多くを排除するのを支援することです。
2番目のポイント、そしてこれも重要なポイントですが、チームとユーザーが現在いる場所で彼らに対応することは、企業とチームが成功するためのこの旅の重要な部分です。彼らが慣れ親しんでいるものとワークフローから引き離すことは破壊的なので、データの重複とフラグメンテーションを制限しようとしながらも、できるだけそれを最小化したいと考えました。最後に、これが S&P Global のジャーニーと他のいくつかのデプロイメントモデルについて話したかった理由です。私たちはこの機能またはこの機能セットを、単なる「統合ストアを有効にしたら動作する」というアプローチではなく、ビルディングブロック方式で構築しました。顧客と話をしていく中で、異なる顧客が異なる方法で異なるものを消費したいということに気づいたからです。
万能なソリューションを一方的に提供するのではなく、私たちはビルディングブロックを提供して、どの機能や能力があなたのニーズに合っているのか、どの段階で必要なのかを評価することをお勧めしています。もしかしたら今日の時点では、ログの一元化だけが必要で、パイプラインやキュレーション、サードパーティのソースは必要ないかもしれません。それで大丈夫です。それは良いスタートです。6ヶ月後には、サードパーティからの追加のデータソースを取り込むことができることに気づくかもしれません。そこから始めることができます。重要なのは、あなたが今どこにいて、どこに行きたいのかを把握して、正しいスタートポイントを見つけ、反復的にそこに到達することです。
かなり話しましたね。 ここにいくつかの QR コードがあります。これらが役に立つかもしれません。1つは、多くの機能と始め方について説明しているニュースブログで、始めるための様々なリソースへのリンクが含まれています。右側には、より広い AWS observability のリソースガイドがあります。AWS observability に関するこれらすべてのリソースがあり、ここでカバーしなかった多くのことが利用可能です。これらを確認することをお勧めします。それでは、来ていただきありがとうございました。お時間をいただき、ありがとうございます。これが役に立つと幸いです。ぜひフィードバックをください。フィードバックは私たちが学び、改善するのに役立ちます。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion