この記事は、”Taking a comprehensive perspective to mainframe application modernization with a disposition strategy” を翻訳したものです。 はじめに メインフレームのお客様は、モダナイゼーションの選択肢が無数にあります。現在、多くの組織は、人材不足や、高額なコストとその上昇、レガシー環境ではビジネスアジリティに制限が掛かることで、モダナイゼーションが急務となっています。また、お客様自身も、モダナイゼーションの複数のパターン、ツール、戦略を自ずと模索しています。 配置戦略 (disposition strategy) には、メインフレームの複雑なモノリシックアプリケーションや大規模なコードベースへの対処に役立つ指針が含まれます。お客様は、レガシーアプリケーションを管理しやすい部分に分解し、ターゲットとなる移行パターンを開発し、移行の順序付けを行い、メインフレームに残るワークロードとの連携機能を構築します。この作業は、アプリケーションが密結合な状態から完全に切り離されるまで繰り返されます。 配置戦略とは、メインフレームモダナイゼーションに対する複数のパターンを複合的に組み合わせるアプローチです。ビジネス目標と IT 目標の優先順位とワークロードの特性に基づいて、個々のワークロードに適した適切なパターンが選択されます。配置戦略は、メインフレームモダナイゼーションを個々のプロジェクトとばらばらの移行フェーズの集まりと見なすのではなく、全体を包括的に見る視点を持つことを推奨します。これには、メインフレームからクラウドネイティブに至る長い道のりの最初から最後までの全行程を定義したロードマップが含まれます。このアプローチは、移行を加速し、リスクを軽減し、お客様が許容できる期間内にビジネス目標と技術目標を達成できるよう支援するのに役立ちます。 指針として目指す北極星を定義する メインフレーム資産は、地域、業界、顧客によってさまざまであり、まったく同じメインフレームアプリケーションは 2 つとありません。レガシーテクノロジー、ビジネス目標、将来の要件、リスクへの関心は、お客様によって非常に多様です。多くの大企業では、複数の事業部門がメインフレーム上で稼働するアプリケーションによってサポートされています。また、これらの事業部門には、メインフレーム処理に依存する多数のビジネスリーダー、アプリケーションオーナー、およびステークホルダーが組織全体に存在しています。このダイナミクスにより、組織がメインフレームの将来の状態に関する明確な戦略を欠いているというシナリオがしばしば生じます。モダナイゼーションの初期段階では、メインフレームのさまざまなステークホルダーが独自に活動し、それぞれ別個に戦略を導入または計画しているお客様をよく見かけます。その結果、モダナイゼーションへのアプローチがばらばらになります。このようなときのモダナイゼーションには、組織のモダナイゼーションの道しるべとなる北極星のようなビジョンが明確になっていない可能性があります。 メインフレームモダナイゼーションプログラム (※1) を成功させるための第一歩は、北極星 (North Star: 目指すべき指針) を定義することです。この北極星は、経営幹部、そして多くの場合、組織の取締役会にも共有されます。お客様は、メインフレームを使い続けることで増大するリスク、コスト、競争上の不利益を認識しています。レガシーアプリケーションのモダナイゼーションを経営幹部が指示することで、より迅速かつ緊急に職務を遂行し、成果を上げているお客様を我々は目にして来ました。明確なミッションが無いため、一連のばらばらで戦術的なモダナイゼーションプログラムに参加することになったお客様も見て来ました。ばらばらなプログラムでは、メインフレームプラットフォームのワークロードの移行には成功しても、モダナイゼーションのメリットを最大限に引き出すには苦労するかもしれません。場合によっては、メインフレームに課せられた制約が原因で MIPS の使用量が増加することさえあります。このような状況を避けるため、お客様には主に 3 つの質問に答えて北極星を定義することをおすすめします。 なぜ私たちはモダナイゼーションを進めているのか? 私たちはどこに向かっているのか? それはいつ実現するのか? これらの質問に答えることで、メインフレーム移行プログラムを成功させるための基礎を確立し、組織が共有する共通のビジネス目標と技術目標を定義しやすくなります。 (※1) 訳注: ここでのプログラムは、共通の戦略的目標を持つ複数の関連プロジェクトを統合・管理することにより、単独プロジェクトの成功を目指す部分最適では無く、全体最適による価値を創出する手法としてのプログラムマネジメントの文脈で使われています。レガシーコードのプログラムを指すものではありません。 モダナイゼーションのビジネス基準: ビジネス要件と技術的現実のバランス ビジネス目標は、組織内の部門によって大きく異なる場合があります。ビジネスユニットによっては、レガシーアプリケーションの機能を早急に変更しなければならない場合もあれば、確立されたプロセスやユーザーエクスペリエンスの変更に抵抗しているビジネスユニットもあります。大まかに言うと、ビジネスの優先事項は次の 2 つのカテゴリに分類されます。 カテゴリー 1: ビジネス機能は変わらないが、ビジネスの俊敏性にはテクノロジーのモダナイゼーションが不可欠 機能的な変化が望まれていない場合。 このシナリオでは、レガシーアプリケーションがサポートする既存のビジネス機能に、ビジネスユーザーはとても満足しています。現行のビジネス機能やワークフローは変更する必要がなく、ビジネスユーザーは機能変更という考えに反対しています。これは、ユーザーが端末エミュレーターの黒画面を操作しているお客様にも当てはまる可能性があります。端末エミュレーターを長年使い続けているユーザーは、操作に熟練しているので作業効率が非常に高く、最新の UX に置き換えると生産性が低下する可能性があります。 お客様はメインフレームワークロードの大部分が一般にこのカテゴリに入ると想定する必要があります。メインフレームアプリケーションは何十年も組織で使われてきました。これらのアプリケーションは、個別のビジネスロジックが何年にもわたって使われてきたビジネスに適しているかもしれません。大企業と各業界で差別化されたビジネスのやり方に合わせてカスタマイズされている可能性があります。すべてのアプリケーションに機能的なトランスフォーメーションが必要なわけではありません。安定性と予測可能性が最優先されるシステムの場合は、以下の選択肢を考慮することが重要です。 リファクタリング (Refactor) : レガシーアプリケーションを最新のプログラミング言語とリレーショナルデータベースに変換します。たとえば、 AWS Transform for mainframe を使うと、お客様は AWS の専門的な AI エージェントを使用して COBOL アプリケーションを AWS 上の Java にリファクタリングできます。 リプラットフォーム (Replatform) : 既存の機能を維持し、レガシーテクノロジースタックを維持しながら、よりモダンなインフラストラクチャに移行します。たとえば、AWS Mainframe Modernization には、クラウド内のメインフレーム互換ランタイムにリプラットフォームするためのオプションが用意されています。 これらのアプリケーションのモダナイゼーションでは、機能以外のモダナイゼーションのメリット (耐障害性、影響範囲の縮小、可用性、俊敏性) にフォーカスしてコミュニケーションします。 カテゴリー 2: 技術的な負債を取り除いたり、新しい機能を追加したり、モノリスを分解してプロダクトを調整したりするには、ビジネス機能の変更が必要 機能強化の要件がある場合。 ビジネス部門がアプリケーションの機能を強化する必要があるのはこの場合です。一般に、お客様はメインフレームワークロードの一部だけがこのカテゴリに該当すると予想しています。このような状況では、企業はモダンな UI、リアルタイム機能、またはより高速なバッチ処理を望んでいる可能性があります。また、お客様は、モノリス化した現行アプリケーションをプロダクトに合わせたビジネス機能に分割したいという目標を持っているかもしれません。このアプローチにより、マイクロサービスアーキテクチャを構築し、疎結合化することによってアジリティとイノベーションを促進されます。 ニアリアルタイムの機能に対するエンドカスタマーの期待の高まりに直面するお客様が増えています。メインフレーム上のモノリス化したアプリケーションにこのような機能を導入するのは困難です。さらに、新しい市場や業界への進出、あるいは顧客基盤の拡大を目指すお客様にも会うことがあります。成長目標を積極的に掲げているお客様は、メインフレームアプリケーションを維持することが、成長や新規ビジネスの獲得を阻害していると気付くことがよくあります。 成長の可能性 : モダナイズすることで、新しい収益源を開拓したり、事業拡大を支援したりできるアプリケーションはどれか? カスタマーエクスペリエンスへの影響 : 顧客とのやり取りや顧客満足度に直接影響するアプリケーションはどれか? 市場への対応力 : 現在、市場の変化への対応能力を制限しているのはどのシステムか? イノベーションの可能性 : 最新の開発手法や最先端技術との連携から最も恩恵を受けるのはどのアプリケーションか? 一般的に、強化すべき機能要件が明確に示されているビジネスユニットは、より優先されるはずです。新機能、ユーザーエクスペリエンスの向上、連携機能など、個々のニーズが具体的な目標を提示し、それによってモダナイゼーションの取り組みが推進され、目に見える価値が示されます。 Reimagine パターン とは、メインフレームアプリケーションのアーキテクチャを最新のテクノロジースタックに合わせて設計し直し、コードを書き直すことと定義されています。このモダナイゼーションの目標は、アプリケーションに機能的な変更を導入することです。ビジネスが新しい機能を必要とする場合、reimagine パターンが望ましいアプローチです。 モダナイゼーションのための技術的基準 メインフレームモダナイゼーションの配置戦略には、組織レベルとアプリケーションレベルの両方で評価された技術的基準も組み込む必要があります。 組織レベルでの技術的考慮事項の評価: データセンターから出て行くための戦略や緊急性が高い移行期限 データセンターの撤退を迫られている組織は、移行の期限が迫っているため、スピードとリスクの軽減を優先する必要があります。コードを変更せずにメインフレームのワークロードをパートナーが管理するデータセンターに移動することを意味するリホスト (rehost) パターンは、実践的な第一歩となる可能性があります。多くの場合、リホストアプローチは、他の移行パターンのように長いサイクルを通ることなく、数ヶ月で完了できます。リホストは事業継続につながります。また、将来のモダナイゼーションの基礎を築き、組織がより高度なパターンを徐々に適用するのにも役立ちます。これらのパターンは、時間とリソースの制約の中で、リファクタリングや reimagine などのモダナイゼーションのニーズに対応できます。 ニッチなメインフレーム技術: プログラミング言語、トランザクションモニター、データベース 既存のメインフレームアプリケーションで使用されている特定のプログラミング言語、トランザクションモニター、データベーステクノロジーは、モダナイゼーションの取り組みの実現可能性と複雑さに大きな影響を与えることがあります。これは、メインフレームモダナイゼーションの配置戦略を検討する際に、重要な技術的考慮事項です。 Natural/Adabas、IDMS などの特定のメインフレームテクノロジーは、リプラットフォームやリファクタリングなどの一部のモダナイゼーションパターンでは直接サポートされていなかったり、完全にはサポートされていない場合があります。これらのレガシーメインフレームテクノロジーの可用性と保守性のスキルも、考慮点の 1 つです。これにより、利用できるモダナイゼーションの選択肢が制限される可能性があり、実行可能な選択肢はリプレース (replace) (※2) や reimagine などのパターンだけかもしれません。 組織は、使用されているメインフレームのテクノロジースタックと、それがさまざまなモダナイゼーションアプローチの実現可能性や複雑さにどの程度合致するかを注意深く評価する必要があります。この技術的評価は、適切な配置戦略を決定するうえで重要なインプットとなります。 (※2) 訳注: 本ブログ内のリプレース (replace) は、パッケージソフトウェア製品の購入や SaaS のサブスクリプション契約等を指すリパーチェス (repurchase) と同義で使われています ベンダーによる更新のタイムライン メインフレームモダナイゼーションの配置戦略を評価する際、ベンダーの更新スケジュールは重要な技術的検討事項になり得ます。組織には、ソフトウェアライセンス契約が異なるさまざまなメインフレームベンダーが存在することがよくあります。契約条件の評価にあたっては、更新時期が迫ることでリスクが高まります。この場合、中には、それらのベンダーのテクノロジーからできるだけ早く撤退することが最も価値ある結果になると判断するお客様もいます。このタイムラインの速さは、選択するモダナイゼーションアプローチにも影響します。 たとえば、ライセンス契約の終了期限が迫っている場合は、リプレースアプローチや reimagine アプローチよりも、リファクタリングパターンの方が適している場合があります。リファクタリングは、コア機能を維持しながらアプリケーションをモダナイズするのに役立ちます。多くの場合、全面的な書き直し (full rewrite) や再実装 (reimplementation) よりも短時間で完了できます。 ただし、すべてのリファクタリングソリューションがすべてのメインフレームテクノロジーをサポートしているわけではない点に注意することが重要です。使用中の特定のテクノロジーに適したリファクタリングソリューションの評価を完了する必要があります。場合によっては、明白なリファクタリングソリューションや実証済のリファクタリングソリューションがないこともあります。必要な期限までにベンダーのテクノロジーから撤退するには、reimagine またはリプレースのアプローチしか実行できない場合があります。 最良のモダナイゼーション戦略を決定する際には、全体的な技術評価の一環として、メインフレームベンダーの契約と更新スケジュールを評価することが重要です。これにより、選択したアプローチを、特定のベンダーのテクノロジーから撤退する緊急性に合わせることができます。 動員可能なメインフレームスキルセット メインフレームのスキルセットに制約があるために企業が人材リスクに直面している場合、そのスキルへの依存度が低いメインフレームモダナイゼーションの選択肢を選ぶことが重要です。このような場合、メインフレームアプリケーションのリファクタリングや reimagine などの戦略が効果的なアプローチになり得ます。 逆に、組織内に有能なメインフレーム人材プールがある場合は、リプラットフォームアプローチがモダナイゼーションに適した戦略となり得ます。既存の専門知識を活用して、ワークロードをよりモダンなプラットフォームに移行することができます。 アプリケーション/ワークロードの技術的な複雑さと依存関係の評価 適切なパターンの選択は、ビジネス上の考慮事項と技術的要件の両方に基づいて行う必要があります。各ワークロードまたはアプリケーションの特定の特性を考慮する必要があります。 さまざまなアプリケーションやワークロードを徹底的に技術評価して、それぞれに最適なモダナイゼーションアプローチを決定することが重要です。この評価フェーズでは、以下の要素を考慮します。 移行元のテクノロジー : プログラミング言語と既存のソースコードの量を評価します。一部の言語とフレームワークは、他の言語とフレームワークよりも自動化されたトランスフォーメーションとモダナイゼーションに適しています。これは、特定のモダナイゼーションパターンの実現可能性と複雑さに影響する可能性があります。 データに関する考慮事項 : メインフレームで使われているデータストア技術 (Db2、IMS/DB、VSAM など) を評価します。データ量、データ構造の複雑さ、データエンティティ間の関係を評価します。データの性質と複雑さが、適切なモダナイゼーションアプローチに影響する可能性があります。 結合度 : さまざまなアプリケーションとワークロード間の結合レベルを特定します。たとえば、トランザクションコンテキストの伝播を含むアプリケーションは、密結合されている可能性があります。この場合、疎結合の場合やサービス境界が明確な場合よりも、モダナイゼーションの課題が大きくなります。モダナイゼーションの過程において、密結合された機能の相互依存関係に順次対処し、具体的に管理する必要があるためです。 連携の複雑さと依存関係 : アプリケーションとワークロードの間のさまざまな連携ポイントを評価します。共有リソース、データ依存関係、全体的な連携の複雑さを特定します。これにより、既存の連携を維持できる適切なモダナイゼーションパターンを判断したり、リスクを抑えて移行を行ったりするのに役立ちます。 外部インターフェース : 選択したモダナイゼーションパターンによっては、外部インターフェースを介してメインフレームにアクセスするメインフレームの外部のクライアントアプリケーションの一部が変更されることがあります。選択したパターンが、すべての外部接続ポイント、API 操作、および外部システムとのデータ交換メカニズムに必要なインターフェースをサポートしていることを確認します。 この詳細な技術評価では、次のような要素を考慮する必要があります。 読み取り/書き込みモードで同じデータにアクセスするアプリケーションをグループ化し、それらのグループに同じ移行パターンを選択する 結合度が高いワークロードには同じ移行パターンを選択する 移行元のプログラミング言語がさまざまな移行パターンの実現可能性に与える影響を考慮する 外部インターフェースや連携への変更を可能な限り最小限に抑える移行パターンを選択する アプリケーションとワークロードの分析は、全体的な配置戦略の重要なインプットです。ワークロード固有の技術的特徴と依存関係に基づいて、ワークロードに適したモダナイゼーションパターンとソリューションを追加できます。 移行戦略の策定 ビジネス成果駆動型プログラムの構築 モダナイゼーションを純粋に技術的な課題として扱うのではなく、次のようなプログラムを確立します。 組織の北極星から逆算して考える : 冒頭で述べたように、お客様はメインフレーム資産に関する組織的な戦略とアプローチを必要としています。成功するメインフレーム移行プロジェクトは、経営陣が設定した変動要素(予算や期間、体制等)の枠組みの中で実施されます。なぜモダナイゼーションを行っているのか、どこに向かっているのか、いつモダナイゼーションを実現するのか、といった点を見失わないようにします。 戦略的ビジネス目標との連動 : モダナイゼーションは、俊敏性の向上、カスタマーエクスペリエンスの向上、新しい機能など、特定のビジネス成果をサポートするものでなければなりません。 ポートフォリオ全体を最初から検討する : モダナイゼーションが段階的なアプローチとして定義されている場合でも、新しいテクノロジーのサイロ化を避けるため、計画はアプリケーション全体を対象とする必要があります。 戦術的な成果と戦略的目標のバランスを取る : 包括的なモダナイゼーションに向けて取り組みながら、段階的な価値をもたらすプログラムを設計します。 成功の明確な指標を確立する : ビジネス面と技術面の両方で、進捗状況をどのように測定するか定義します。 経営幹部レベルで戦略が設定されていないと、個々のチームが異なるアプローチを採用したり、「様子を見る」という考えに陥ったりする可能性があります。これにより、モダナイゼーションが遅れ、複雑さが増す可能性があります。 「すべてを再構築」という落とし穴の回避 私たちの経験から、80:20 の原則はメインフレーム資産にも一般的に当てはまることがわかっています。メインフレームアプリケーションの約 80% は機能変更を必要とせず、約 20% のアプリケーションでは reimagine が必要です。 お客様には、大幅な脱メインフレームを含むモダナイゼーションのアプローチを検討することをお勧めします。Transamerica や Goldman Sachs などのお客様は、リファクタリングやリプラットフォームパターンを利用して、ミッションクリティカルなメインフレームワークロードを AWS に移行することに成功しています。アプリケーションごとに個別のアプローチを取るだけだと時間がかかり過ぎて、ビジネス上の必要性を満たせない場合があります。ビジネス目標と技術目標に基づいて、複数のモダナイゼーションパターンを組み込むことを検討します。 大規模なリファクタリング : AWS Transform for mainframe には、レガシーアプリケーションをモダンな Java フレームワークにモダナイズするのに役立つリファクタリング機能が備わっています。このパターンは、決定論的ツールによってもたらされる移行スケジュールの短縮の恩恵を受けながら、レガシーテクノロジーへの依存を減らしたい場合に使用できます。 リプラットフォーム : リプラットフォームでは、エミュレーションテクノロジーを使用して、メインフレームアプリケーションをそのまま移行します。これはしばしば「COBOL から COBOL への移行」と呼ばれます。この場合、リプラットフォームパターンにより、COBOL の人材不足の状況に対処し、脱メインフレームを加速させることができます。 大規模なモダナイゼーションアプローチと戦略的な reimagine を組み合わせることで、お客様はプラットフォームからの撤退に向けて前進しながら、技術的成果とビジネス上の成果を一致させる機会を得ることができます。複数のパターンを社内の戦略で検討しているお客様は、組織内のより多様な目標に取り組むことができます。これは、同じ期間内に運用コスト削減目標を達成しながら行われます。 まとめ: 今こそ行動の時です 今日、メインフレームアプリケーションのモダナイゼーションが強く求められています。人材不足、ソフトウェアコストの上昇、組織の非効率性といったよく挙げられる課題のほかに、新たな要因が浮かび上がってきました。それは、生成 AI がソフトウェア開発に与える影響の増大です。生成 AI コーディングアシスタントがモダンな言語の生産性に革命をもたらすにつれ、モダンテクノロジーとメインフレームテクノロジーの間の開発スピードと生産性のギャップはさらに悪化するでしょう。COBOL や Assembler、PL/I 言語のアプリケーションを使用する組織は、価値創出のスピードという点で競争上の不利な点に直面するケースが増えています。同業他社が運用する基幹システムは、開発スピードがますます速くなるモダンなテクノロジーで書かれた基幹システムを運用しているかも知れません。 メインフレームモダナイゼーションに「特効薬」はありません。成功するには、具体的な成果に基づいて IT 目標とビジネス目標を一致させる、ビジネス駆動型のマルチパターンアプローチが必要です。自動化を行い、段階的に反復することで、コスト削減以外の価値に集中できます。 配置戦略は、各アプリケーションポートフォリオの微妙な違いを認識した、このジャーニーの枠組みとなります。このアプローチでメインフレームアプリケーションをモダナイズすることで、組織は数十年にわたって構築された貴重なビジネスロジックを維持しながら、将来のイノベーション需要に備えることができます。 Tim Gray Tim は AWS の Worldwide Go-to-market Specialist で、AWS Transform for mainframe のリードを担当しています。 Tim は、お客様が AWS Transform を活用して基幹システムを reimagine し、モダナイズすることによる AWS への移行を支援するべく、市場開拓戦略に注力しています。現在、Tim は、大規模なモダナイゼーションプログラムをこれまでにない時間枠で加速させる生成 AI およびエージェンティック AI サービスをデプロイするための再現可能なパターンの構築に注力しています。 Sunil Divvela Sunil Divvela は、AWS の Mainframe Modernization 担当 Worldwide Specialist Solutions Architect です。お客様やパートナーと緊密に連携して、生成 AI やエージェンティック AI を活用したポートフォリオ評価から移行後のサポートに至るまで、メインフレームモダナイゼーションの取り組みを革新し加速させています。AWS 入社前、Sunil は Infosys の Senior Technology Architect として、複数のメインフレームトランスフォーメーションプロジェクトをリードしていました。 Yann Kindelberger Yann Kindelberger は、Amazon Web Services の Principal Solution Architect です。Yann は 23 年以上メインフレームに携わり、IBM で 20 年以上メインフレームアーキテクトとして勤務しました。彼はメインフレームの AWS クラウドへの移行とモダナイゼーションに取り組んでいるワールドワイドなチームの一員です。彼は 2021 年に AWS に入社し、ソリューションアーキテクトとして、お客様のメインフレームの移行とモダナイゼーションを支援し、助言し、サポートしています。 この投稿の翻訳は Mainframe Modernization Specialist Solutions Architect の皆川が担当致しました。原文記事は こちら です。

本記事は 2026 年 1 月 12 日 に公開された「 Navigating architectural choices for a lakehouse using Amazon SageMaker 」を翻訳したものです。 組織がデータを活用して意思決定やイノベーションを推進する動きは加速しています。ペタバイト規模の情報を扱う中で、従来はデータレイクとデータウェアハウスという 2 つの異なるパラダイムに分かれてきました。それぞれ特定のユースケースに強みがある一方、データ資産間に意図しない障壁を生むことがあります。 データレイクは Amazon Simple Storage Service (Amazon S3) などのオブジェクトストレージ上に構築されることが多く、多様なデータ形式とスキーマ・オン・リード機能をサポートする柔軟性を提供します。そのため、 Apache Spark 、 Trino 、 Presto などの様々な処理フレームワークが同じデータにクエリできる マルチエンジンアクセス が可能になります。一方、データウェアハウス ( Amazon Redshift など) は、ACID (原子性、一貫性、分離性、耐久性) 準拠、パフォーマンス最適化、簡単なデプロイメントに優れており、構造化された複雑なクエリに適しています。データ量の増加と分析ニーズの複雑化に伴い、組織はデータレイクとデータウェアハウスのサイロを橋渡しし、両方のパラダイムの強みを活用しようとしています。レイクハウスアーキテクチャはデータ管理と分析を統合的に扱うアプローチとして注目されています。 時間の経過とともに、いくつかの異なるレイクハウスアプローチが登場しました。本記事では、ニーズに合った適切なレイクハウスパターンの評価と選択方法を紹介します。 データレイク中心のレイクハウス アプローチは、オブジェクトストレージ上に構築された従来のデータレイクのスケーラビリティ、コスト効率、柔軟性から始まります。目標は、主にオープンテーブルフォーマット ( Apache Hudi 、 Delta Lake 、 Apache Iceberg ) を通じて、従来データベースにあったトランザクション機能とデータ管理レイヤーを追加することです。オープンテーブルフォーマットはデータレイクの単一テーブル操作に ACID 保証を導入する点で大きく進歩しましたが、複雑な参照整合性制約やジョインを伴うマルチテーブルトランザクションの実装は依然として困難です。オブジェクトストレージ上のペタバイト規模のファイルに対するクエリは、分散クエリエンジンを介することが多く、高度に最適化・インデックス化・マテリアライズ化されたデータウェアハウスと比較すると、高い同時実行性でのインタラクティブクエリが遅くなる可能性があります。オープンテーブルフォーマットはコンパクションとインデックスを導入していますが、成熟した独自仕様のデータウェアハウスに見られる高度なストレージ最適化機能は、データレイク中心のアーキテクチャではまだ発展途上です。 データウェアハウス中心のレイクハウス アプローチは充実した分析機能を提供しますが、相互運用性に大きな課題があります。データウェアハウスは外部アクセス用に JDBC および ODBC ドライバーを提供していますが、基盤となるデータは独自仕様の形式のままであり、複雑な ETL や API レイヤーなしでは外部ツールやサービスが直接アクセスすることが困難です。データの重複とレイテンシーにつながる可能性があります。データウェアハウスアーキテクチャはオープンテーブルフォーマットの読み取りをサポートする場合がありますが、書き込みやトランザクションレイヤーへの参加能力は限定的です。真の相互運用性が制限され、意図しないデータサイロが生まれる可能性があります。 AWS では、データウェアハウスとデータレイクの両方への統合アクセスを実現する モダンでオープンなレイクハウスアーキテクチャ を構築できます。このアプローチにより、データの単一の信頼できるソースを維持しながら、高度な分析、機械学習 (ML)、生成 AI アプリケーションを構築できます。データレイクかデータウェアハウスかを選ぶ必要はありません。既存の投資を活用し、両方のパラダイムの強みを維持しつつ、それぞれの弱点を解消できます。AWS のレイクハウスアーキテクチャは、Apache Hudi、Delta Lake、Apache Iceberg などのオープンテーブルフォーマットを採用しています。 次世代の Amazon SageMaker でレイクハウスの導入を加速できます。SageMaker はデータへの統合アクセスを備えた分析と AI の統合エクスペリエンスを提供します。SageMaker は Apache Iceberg と完全互換のオープンレイクハウスアーキテクチャ上に構築されています。Apache Iceberg REST API のサポートを拡張することで、SageMaker は様々な Apache Iceberg 互換クエリエンジンやツール間の相互運用性とアクセシビリティを大幅に向上させています。このアーキテクチャの中核には、 AWS Glue Data Catalog と AWS Lake Formation 上に構築されたメタデータ管理レイヤーがあり、統合ガバナンスと一元的なアクセス制御を提供します。 Amazon SageMaker レイクハウスアーキテクチャの基盤 Amazon SageMaker のレイクハウスアーキテクチャには、統合データプラットフォームを構成する 4 つの主要コンポーネントがあります。 ワークロードパターンと要件に適応する柔軟なストレージ すべてのメタデータの単一の信頼できるソースとなるテクニカルカタログ すべてのデータ資産にわたるきめ細かなアクセス制御を備えた統合権限管理 Apache Iceberg REST API 上に構築された、ユニバーサル互換性のためのオープンアクセスフレームワーク カタログと権限 オープンレイクハウスを構築する際、メタデータの中央リポジトリであるカタログは、データ検出とガバナンスの重要なコンポーネントです。Amazon SageMaker のレイクハウスアーキテクチャには、マネージドカタログとフェデレーテッドカタログの 2 種類のカタログがあります。 マネージドカタログは、レイクハウスがメタデータを管理し、データを汎用 S3 バケットに保存する形態です。 フェデレーテッドカタログは、外部や既存のデータソースをマウント・接続し、データを移動せずに Amazon Redshift 、Snowflake、 Amazon DynamoDB などのデータソースに直接クエリできる形態です。詳細は「 Data connections in the lakehouse architecture of Amazon SageMaker 」を参照してください。 AWS Glue クローラー を使用して、 Data Catalog にメタデータを自動的に検出・登録できます。Data Catalog はデータ資産のスキーマとテーブルメタデータを保存し、ファイルを論理テーブルに変換します。データがカタログ化されたら、次の課題はアクセス制御です。フォルダごとに複雑な S3 バケットポリシーを使用することもできますが、管理とスケーリングが困難です。 Lake Formation は Data Catalog 上にデータベーススタイルの一元的な権限モデルを提供し、個々のユーザーやロールに対して行、列、セルレベルのきめ細かなアクセスを付与または取り消す柔軟性を備えています。 Apache Iceberg REST API によるオープンアクセス 前述のレイクハウスアーキテクチャ (以下の図の) は、サービスエンドポイントを通じて AWS Glue Iceberg REST カタログ も使用しています。OSS 互換性を提供し、Spark やその他のオープンソース分析エンジン間で Iceberg テーブルメタデータを管理するための相互運用性を向上させます。テーブルフォーマットとユースケースの要件に基づいて適切な API を選択できます。 本記事では、データレイクとデータウェアハウスを最適に活用してスケーラブルで高パフォーマンスなデータソリューションを構築する方法に焦点を当て、様々なレイクハウスアーキテクチャパターンを探ります。 AWS でレイクハウスにデータを取り込む レイクハウスアーキテクチャを構築する際、データのアクセスと統合には 3 つの異なるパターンから選択でき、それぞれ異なるユースケースに固有の利点を提供します。 従来の ETL は、データを抽出し、変換してレイクハウスにロードする従来の方法です。 使用すべきケース: 複雑な変換が必要で、パフォーマンス向上のためにダウンストリームアプリケーション向けに高度にキュレーションされ最適化されたデータセットが必要な場合 過去データの移行が必要な場合 大規模なデータ品質の適用と標準化が必要な場合 レイクハウスに高度にガバナンスされたキュレーション済みデータが必要な場合 Zero-ETL は、ソースシステムからレイクハウスへデータを最小限の手動介入やカスタムコードで自動的かつ継続的にレプリケートするモダンなアーキテクチャパターンです。内部的には、変更データキャプチャ (CDC) を使用して、ソースからターゲットへのすべての新規挿入、更新、削除を自動的にストリーミングします。このアーキテクチャパターンは、ソースシステムが高いデータクリーンネスと構造を維持しており、ロード前の重い変換の必要性が最小限の場合、またはデータの精製と集約がレイクハウス内のターゲット側で行える場合に効果的です。Zero-ETL は最小限の遅延でデータをレプリケートし、変換ロジックはインサイトが生成される場所に近いターゲット側で、より効率的なロード後フェーズとして実行されます。 使用すべきケース: 運用の複雑さを軽減し、準リアルタイムとバッチの両方のユースケースでデータレプリケーションを柔軟に制御する必要がある場合 カスタマイズが限定的で十分な場合。Zero-ETL は最小限の作業を意味しますが、レプリケートされたデータに軽い変換が必要な場合もあります 専門的な ETL の専門知識の必要性を最小限に抑えたい場合 処理遅延なしでデータの鮮度を維持し、データの不整合リスクを軽減する必要がある場合。Zero-ETL はインサイトまでの時間を短縮します データフェデレーション (データ移動なしのアプローチ) は、データを単一の集中場所に物理的に移動またはコピーせずに、複数の異なるソースからデータをクエリ・結合できる方法です。この クエリインプレース アプローチにより、クエリエンジンが外部ソースシステムに直接接続し、クエリを委任・実行し、結果をオンザフライで結合してユーザーに提示できます。このアーキテクチャパターンの効果は、システム間のネットワークレイテンシー、ソースシステムのパフォーマンス能力、クエリエンジンの述語のプッシュダウン能力の 3 つの要因に依存します。このデータ移動なしのアプローチにより、ソースデータへのリアルタイムアクセスを提供しながら、データの重複とストレージコストを大幅に削減できます。 使用すべきケース: オペレーショナル分析のためにソースシステムに直接クエリする必要がある場合 レイクハウス内のストレージスペースと関連コストを節約するためにデータを複製したくない場合 即時のデータ可用性とライブデータの一回限りの分析のために、クエリパフォーマンスとガバナンスの一部をトレードオフしてもよい場合 データを頻繁にクエリする必要がない場合 AWS でのレイクハウスのストレージレイヤーを理解する レイクハウスにデータを取り込む様々な方法を確認したところで、次の問題はデータの保存先です。以下の図のように、AWS ではデータレイク (Amazon S3 または Amazon S3 Tables ) またはデータウェアハウス ( Redshift Managed Storage ) にデータを保存してモダンなオープンレイクハウスを構築でき、ワークロード要件に基づいて柔軟性とパフォーマンスの両方を最適化できます。 モダンなレイクハウスは単一のストレージ技術ではなく、それらの戦略的な組み合わせです。データの保存場所と方法は、ダッシュボードの応答速度から ML モデルの効率まで幅広く影響します。ストレージの初期コストだけでなく、データ取得の長期コスト、ユーザーが求めるレイテンシー、単一の信頼できるソースを維持するためのガバナンスも考慮が必要です。このセクションでは、データレイクとデータウェアハウスのアーキテクチャパターンを掘り下げ、各ストレージパターンをいつ使用すべきかの明確なフレームワークを提供します。かつては競合するアーキテクチャと見なされていましたが、モダンでオープンなレイクハウスアプローチは両方を活用して単一の強力なデータプラットフォームを構築します。 汎用 S3 Amazon S3 の 汎用 S3 バケット は、オブジェクトの保存に使用される標準的な基本バケットタイプです。厳格な事前スキーマなしでネイティブ形式のデータを保存できる柔軟性を提供します。S3 バケットはストレージとコンピューティングを分離できるため、高度にスケーラブルな場所にデータを保存しながら、様々なクエリエンジンが独立してアクセス・処理できます。データの移動や複製なしに、ジョブに適したツールを選択できます。ストレージ容量のプロビジョニングや管理なしでペタバイト規模のデータを保存でき、 階層型ストレージクラス により、アクセス頻度の低いデータをより手頃なストレージに自動的に移動して大幅なコスト削減を実現します。 既存の Data Catalog はマネージドカタログとして機能します。AWS アカウント番号で識別されるため、既存の Data Catalog の移行は不要で、レイクハウスですでに利用可能であり、以下の図のように新しいデータのデフォルトカタログになります。 汎用 S3 上の基本的なデータレイクは、追記専用ワークロードに非常に効率的です。ただし、ファイルベースの性質上、従来のデータベースのトランザクション保証が欠けています。Apache Hudi、Delta Lake、Apache Iceberg などのオープンソースのトランザクショナルテーブルフォーマットを活用すると、この課題を解決できます。テーブルフォーマットによりマルチバージョン同時実行制御（MVCC）を実装でき、複数のリーダーとライターが競合なく同時に操作できます。スナップショット分離を提供するため、書き込み操作中でもリーダーはデータの一貫したビューを参照できます。以下の図は Apache Iceberg を使用した典型的なメダリオンアーキテクチャパターンを示しています。AWS で Apache Iceberg を使用してレイクハウスを構築する場合、Amazon S3 上のデータ保存には、セルフマネージド Iceberg を使用した汎用 S3 バケットと、フルマネージドの S3 Tables の 2 つの主要なアプローチから選択できます。それぞれに明確な利点があり、制御、パフォーマンス、運用負荷に対する具体的なニーズによって適切な選択が異なります。 セルフマネージド Iceberg を使用した汎用 S3 セルフマネージド Iceberg を使用した汎用 S3 バケットは、データと Iceberg メタデータファイルの両方を標準 S3 バケットに保存する従来のアプローチです。このオプションでは完全な制御を維持しますが、コンパクションやガベージコレクションなどの必須メンテナンスタスクを含む、Iceberg テーブルのライフサイクル全体を自分で管理する必要があります。 使用すべきケース: 最大限の制御: データライフサイクル全体を完全に制御できます。コンパクションのスケジュールや戦略の定義など、テーブルメンテナンスのあらゆる側面を微調整でき、特定の高パフォーマンスワークロードやコスト最適化に重要です。 柔軟性とカスタマイズ: 強力な社内データエンジニアリング専門知識を持ち、より幅広いオープンソースツールやカスタムスクリプトとの統合が必要な組織に最適です。 Amazon EMR や Apache Spark を使用してテーブル操作を管理できます。 初期コストの低さ: Amazon S3 ストレージ、API リクエスト、メンテナンス用コンピューティングリソースの料金のみ発生します。継続的な自動最適化が不要な小規模または低頻度のワークロードでは、よりコスト効率が高くなる可能性があります。 注意: クエリパフォーマンスは最適化戦略に完全に依存します。コンパクションの継続的なスケジュールジョブがないと、データの断片化に伴いパフォーマンスが低下する可能性があります。効率的なクエリを確保するために、コンパクションジョブを監視する必要があります。 S3 Tables S3 Tables は、分析ワークロードに最適化された S3 ストレージを提供し、大規模な表形式データを保存するための Apache Iceberg 互換性を備えています。S3 テーブルバケットとテーブルを Data Catalog と統合し、Lake Formation コンソールまたはサービス API で Lake Formation データロケーションとしてカタログを登録できます (以下の図の)。このカタログはフェデレーテッドレイクハウスカタログとして登録・マウントされます。 使用すべきケース: 運用の簡素化: S3 Tables はコンパクション、スナップショット管理、孤立ファイルのクリーンアップなどのテーブルメンテナンスタスクをバックグラウンドで自動的に処理します。カスタムメンテナンスジョブの構築・管理が不要になり、運用負荷を大幅に軽減できます。 自動最適化: S3 Tables はクエリパフォーマンスを向上させる組み込みの自動最適化を提供します。スモールファイル問題に対処するファイルコンパクションや、表形式データに特化したデータレイアウト最適化などのバックグラウンドプロセスが含まれます。ただし、自動化と柔軟性はトレードオフの関係にあります。コンパクション操作のタイミングや方法を制御できないため、特定のパフォーマンス要件を持つワークロードではクエリパフォーマンスにばらつきが生じる可能性があります。 データ活用への集中: S3 Tables はエンジニアリングの負荷を軽減し、データの消費、データガバナンス、価値創造に焦点を移します。 オープンテーブルフォーマットへの簡単な導入: Apache Iceberg の概念は初めてだが、データレイクでトランザクション機能を活用したいチームに適しています。 外部カタログ不要: 外部カタログを管理したくない小規模チームに適しています。 Redshift Managed Storage データレイクはすべてのデータの中央の信頼できるソースとして機能しますが、すべてのジョブに最適なデータストアではありません。最も要求の厳しいビジネスインテリジェンスとレポーティングワークロードでは、データレイクのオープンで柔軟な性質がパフォーマンスの予測不可能性をもたらす可能性があります。望ましいパフォーマンスを確保するために、以下の理由でデータレイクからデータウェアハウスへキュレーション済みデータのサブセットを移行することを検討してください: 高同時実行 BI とレポーティング: 数百のビジネスユーザーがライブダッシュボードで複雑なクエリを同時に実行する場合、データウェアハウスは予測可能なサブ秒のクエリレイテンシーで高同時実行ワークロードを処理するよう特別に最適化されています。 予測可能なパフォーマンス SLA: 財務レポートや日次売上分析など、保証された速度でデータを配信する必要がある重要なビジネスプロセスでは、データウェアハウスが一貫したパフォーマンスを提供します。 複雑な SQL ワークロード: データレイクは強力ですが、多数のジョインや大規模な集約を伴う非常に複雑なクエリでは苦戦する可能性があります。データウェアハウスは複雑なリレーショナルワークロードを効率的に実行するために構築されています。 AWS のレイクハウスアーキテクチャは Redshift Managed Storage (RMS) をサポートしています。RMS は、Amazon Redshift が提供するフルマネージドのストレージオプションです。RMS ストレージは、データウェアハウジングワークロード向けの組み込みクエリ最適化、 自動マテリアライズドビュー 、頻繁に実行されるワークロード向けの AI 駆動の最適化とスケーリング など、Amazon Redshift が提供する 自動テーブル最適化 をサポートしています。 フェデレーテッド RMS カタログ: 既存の Amazon Redshift データウェアハウスをレイクハウスにオンボード 既存の Amazon Redshift データウェアハウスでフェデレーテッドカタログを実装すると、データ移動を必要としないメタデータのみの統合が作成されます。このアプローチにより、既存のワークフローとの互換性を維持しながら、確立された Amazon Redshift への投資をモダンなオープンレイクハウスフレームワークに拡張できます。Amazon Redshift は階層的なデータ組織構造を使用しています: クラスターレベル : 名前空間から始まる データベースレベル : 複数のデータベースを含む スキーマレベル : データベース内のテーブルを整理する 既存の Amazon Redshift プロビジョンドまたはサーバーレスの名前空間を Data Catalog のフェデレーテッドカタログとして登録すると、この階層がレイクハウスのメタデータレイヤーに直接マッピングされます。AWS のレイクハウス実装は、基盤となるストレージメタデータを整理・マッピングする動的階層を使用して複数のカタログをサポートしています。 名前空間を登録すると、フェデレーテッドカタログは AWS リージョンとアカウント内のすべての Amazon Redshift データウェアハウスに自動的にマウントされます。登録プロセス中、Amazon Redshift はデータ共有に対応する外部データベースを内部的に作成します。エンドユーザーからはこの仕組みは完全に隠蔽されています。フェデレーテッドカタログを使用することで、データエコシステム全体にわたる即時の可視性とアクセシビリティを実現できます。 フェデレーテッドカタログの権限 は、同一アカウントとクロスアカウントアクセスの両方で Lake Formation によって管理できます。 フェデレーテッドカタログが特に効果を発揮するのは、 Amazon Athena 、 Amazon EMR 、オープンソース Spark などの外部 AWS エンジンから Amazon Redshift マネージドストレージにアクセスする場面です。Amazon Redshift は Amazon Redshift エンジンのみがネイティブに読み取れる独自仕様のブロックベースストレージを使用しているため、AWS はバックグラウンドでサービスマネージドの Amazon Redshift Serverless インスタンスを自動的にプロビジョニングします。このサービスマネージドインスタンスは、外部エンジンと Amazon Redshift マネージドストレージ間の変換レイヤーとして機能します。AWS は、登録されたフェデレーテッドカタログとサービスマネージドの Amazon Redshift Serverless インスタンス間に自動データ共有を確立し、安全で効率的なデータアクセスを実現します。AWS はデータ転送用のサービスマネージド Amazon S3 バケットもバックグラウンドで作成します。 Athena などの外部エンジンが Amazon Redshift フェデレーテッドカタログに対してクエリを送信すると、Lake Formation がリクエストサービスに一時的な認証情報を提供してクレデンシャルベンディングを処理します。クエリはサービスマネージドの Amazon Redshift Serverless を通じて実行され、自動的に確立されたデータ共有を通じてデータにアクセスし、結果を処理してサービスマネージドの Amazon S3 ステージングエリアにオフロードし、元のリクエストエンジンに結果を返します。 既存の Amazon Redshift ウェアハウスのフェデレーテッドカタログのコンピューティングコストを追跡するには、以下のタグを使用します。 aws:redshift-serverless:LakehouseManagedWorkgroup value: "True" 請求インサイトのために AWS 生成コスト配分タグを有効にするには、 有効化手順 に従ってください。 AWS Billing でリソースのコンピューティングコストも確認できます。 使用すべきケース: 既存の Amazon Redshift への投資: フェデレーテッドカタログは、既存の Amazon Redshift デプロイメントを持ち、移行なしで複数のサービス間でデータを活用したい組織向けに設計されています。 クロスサービスデータ共有: チームが既存の Amazon Redshift データウェアハウスのデータを異なるウェアハウス間で共有し、権限を一元管理できるように実装します。 エンタープライズ統合要件: 確立されたデータガバナンスとの統合が必要な組織に適しています。レイクハウス機能を追加しながら、現在のワークフローとの互換性を維持します。 インフラストラクチャの制御と料金: 予測可能なワークロードに対して既存のウェアハウスのコンピューティング容量を完全に制御できます。コンピューティング容量の最適化、オンデマンドとリザーブドキャパシティの料金の選択、パフォーマンスパラメータの微調整が可能です。一貫したワークロードに対してコストの予測可能性とパフォーマンス制御を提供します。 複数のカタログタイプを使用してレイクハウスアーキテクチャを実装する場合、パフォーマンスとコスト最適化の両方にとって適切なクエリエンジンの選択が重要です。本記事ではレイクハウスのストレージ基盤に焦点を当てていますが、Amazon Redshift データ操作を多用する重要なワークロードでは、可能な限り Amazon Redshift 内でクエリを実行するか、Spark を使用することを検討してください。複数の Amazon Redshift テーブルにまたがる複雑なジョインを外部エンジンで実行すると、エンジンが完全な述語のプッシュダウンをサポートしていない場合、コンピューティングコストが高くなる可能性があります。 その他のユースケース マルチウェアハウスアーキテクチャの構築 Amazon Redshift は データ共有 をサポートしており、ソースとターゲットの Amazon Redshift クラスター間でライブデータを共有できます。データ共有を使用すると、コピーの作成やデータの移動なしでライブデータを共有でき、ワークロード分離 (ハブアンドスポークアーキテクチャ) やクロスグループコラボレーション (データメッシュアーキテクチャ) などのユースケースが可能になります。レイクハウスアーキテクチャがない場合、ソースとターゲットの Amazon Redshift クラスター間に明示的なデータ共有を作成する必要があります。小規模なデプロイメントではデータ共有の管理は比較的簡単ですが、データメッシュアーキテクチャでは複雑になります。 レイクハウスアーキテクチャはこの課題に対応し、既存の Amazon Redshift ウェアハウスをフェデレーテッドカタログとして公開できます。フェデレーテッドカタログは、同一アカウントとリージョン内の他のコンシューマー Amazon Redshift ウェアハウスに外部データベースとして自動的にマウントされ、利用可能になります。データの単一コピーを維持しながら複数のデータウェアハウスからクエリでき、複数のデータ共有の作成と管理が不要になり、ワークロード分離でスケールできます。権限管理は Lake Formation を通じて一元化され、マルチウェアハウス環境全体のガバナンスが効率化されます。 パイプライン管理不要のペタバイト規模トランザクションデータの準リアルタイム分析: Zero-ETL 統合は、OLTP データソースから Amazon Redshift、汎用 S3 (セルフマネージド Iceberg)、または S3 Tables へトランザクションデータをシームレスにレプリケートします。ETL パイプラインの維持が不要になり、データアーキテクチャの可動部品と潜在的な障害ポイントが削減されます。ビジネスユーザーは、前回の ETL 実行からの古いデータではなく、新鮮な運用データをすぐに分析できます。 Amazon Redshift ウェアハウスにレプリケートできる OLTP データソースの一覧は「 Aurora zero-ETL integrations 」を参照してください。 既存の Amazon Redshift ウェアハウス、セルフマネージド Iceberg を使用した汎用 S3、S3 Tables にレプリケートできるその他のサポートされるデータソースについては「 Zero-ETL integrations 」を参照してください。 まとめ レイクハウスアーキテクチャは、データレイクとデータウェアハウスのどちらかを選ぶものではありません。両方のフレームワークが統合データアーキテクチャ内で共存し、異なる目的を果たす相互運用性のアプローチです。基本的なストレージパターンを理解し、効果的なカタログ戦略を実装し、ネイティブストレージ機能を活用することで、現在の分析ニーズと将来のイノベーションの両方をサポートする、スケーラブルで高パフォーマンスなデータアーキテクチャを構築できます。詳細は「 The lakehouse architecture of Amazon SageMaker 」を参照してください。 著者について Lakshmi Nair Lakshmi は、AWS のシニアアナリティクススペシャリストソリューションアーキテクトです。業界横断で高度な分析システムの設計を専門としています。クラウドベースのデータプラットフォームの構築、リアルタイムストリーミング、ビッグデータ処理、堅牢なデータガバナンスの実現に注力しています。 Saman Irfan Saman は、ドイツのベルリンを拠点とする Amazon Web Services のシニアスペシャリストソリューションアーキテクトです。組織のデータアーキテクチャのモダナイゼーションとデータの潜在能力を最大限に引き出し、イノベーションとビジネス変革を推進することに情熱を注いでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Woosuk Choi がレビューしました。

本記事は 2026 年 1 月 26 日 に公開された「 Top 10 best practices for Amazon EMR Serverless 」を翻訳したものです。 Amazon EMR Serverless は Amazon EMR のデプロイオプションの 1 つで、 Apache Spark や Apache Hive などのオープンソースビッグデータ分析フレームワークを、クラスターやサーバーの設定・管理・スケーリングなしで実行できます。EMR Serverless は、データストレージ、ストリーミング、オーケストレーション、モニタリング、ガバナンスにわたる Amazon Web Services (AWS) サービスと統合し、サーバーレス分析ソリューションを実現します。 本記事では、EMR Serverless ワークロードのパフォーマンス、コスト、スケーラビリティを最適化するためのベストプラクティス 10 選を紹介します。EMR Serverless を使い始めたばかりの方も、既存の本番ワークロードを改善したい方も、効率的でコスト効率の高いデータ処理パイプラインの構築に役立つ内容です。以下の図は、EMR Serverless のエンドツーエンドアーキテクチャを示しており、分析パイプラインへの統合方法を表しています。 1. アプリケーションは一度定義して繰り返し使う EMR Serverless アプリケーション はクラスターテンプレートに相当し、ジョブ送信時にインスタンス化され、再作成せずに複数のジョブを処理できます。アプリケーションを再利用することで起動レイテンシーを削減し、運用管理を簡素化できます。 EMR on EC2 一時クラスターの一般的なワークフロー: EMR Serverless の一般的なワークフロー: アプリケーションは自己管理型のライフサイクルを備えており、必要なときに手動操作なしでリソースをプロビジョニングします。ジョブが送信されると自動的にキャパシティをプロビジョニングします。事前初期化キャパシティのないアプリケーションでは、ジョブ完了後すぐにリソースが解放されます。事前初期化キャパシティが設定されている場合、設定されたアイドルタイムアウト (デフォルト 15 分) を超えるとワーカーが停止します。このタイムアウトは、 CreateApplication または UpdateApplication API の AutoStopConfig でアプリケーションレベルで調整できます。たとえば、ジョブが 30 分ごとに実行される場合、アイドルタイムアウトを延長すると実行間の起動遅延を解消できます。 ほとんどのワークロードには、オンデマンドキャパシティが適しています。ジョブの要件に基づいてリソースを自動スケーリングし、アイドル時には課金されません。ETL ワークロード、バッチ処理ジョブ、最大限のジョブ回復力が必要なシナリオなど、一般的なユースケースに適したコスト効率の高いアプローチです。 即時起動が厳密に求められるワークロードには、オプションで 事前初期化キャパシティ を設定できます。事前初期化キャパシティは、数秒以内にジョブを実行できるドライバーとエグゼキューターのウォームプールを作成します。ただし、パフォーマンスが向上する分、コストは高くなります。事前初期化ワーカーはアプリケーションが停止状態になるまでアイドル中も継続的に課金されます。また、事前初期化キャパシティはジョブを単一のアベイラビリティゾーンに制限するため、回復力が低下します。 事前初期化キャパシティを検討すべきケース: 起動レイテンシーが許容できない、サブ秒の SLA 要件がある時間的制約の厳しいジョブ ユーザー体験が即時応答に依存するインタラクティブ分析 数分ごとに実行される高頻度の本番パイプライン それ以外のほとんどのケースでは、オンデマンドキャパシティがコスト、パフォーマンス、回復力のバランスに優れています。 リソースの最適化に加えて、ワークロード全体でのアプリケーションの整理方法も検討してください。本番ワークロードでは、ビジネスドメインやデータの機密レベルごとに別々のアプリケーションを使用しましょう。アプリケーションを分離することでガバナンスが向上し、重要なジョブと重要でないジョブ間のリソース競合を防げます。 2. AWS Graviton プロセッサ で価格性能比を向上 適切なプロセッサアーキテクチャの選択は、パフォーマンスとコストの両方に大きく影響します。 Graviton ARM ベースプロセッサは、x86_64 と比較して優れた価格性能比を実現します。 EMR Serverless は最新のインスタンス世代が利用可能になると自動的に更新されるため、追加設定なしで最新のハードウェア改善の恩恵を受けられます。 EMR Serverless で Graviton を使用するには、 CreateApplication でアプリケーション作成時に architecture パラメータで ARM64 を指定するか、既存のアプリケーションには UpdateApplication API を使用します: aws emr-serverless create-application \   --name my-spark-app \   -- SPARK \   --architecture ARM64 \   --release-label emr-7.12.0 Graviton 使用時の考慮事項: リソースの可用性 – 大規模ワークロードの場合、Graviton ワーカーのキャパシティプランニングについて AWS アカウントチームに相談することを検討してください。 互換性 – 一般的に使用される標準ライブラリの多くは Graviton (arm64) アーキテクチャと互換性がありますが、使用しているサードパーティパッケージやライブラリの互換性を検証する必要があります。 移行計画 – Graviton の導入には戦略的なアプローチを取りましょう。新しいアプリケーションはデフォルトで ARM64 アーキテクチャで構築し、既存のワークロードは中断を最小限に抑える段階的な移行計画で 移行 します。段階的に移行することで、信頼性を損なわずにコストとパフォーマンスを最適化できます。 ベンチマークの実施 – 正確な価格性能比はワークロードによって異なります。ワークロード固有の結果を把握するために、独自のベンチマークを実施することを推奨します。詳細は「 Achieve up to 27% better price-performance for Spark workloads with AWS Graviton2 on Amazon EMR Serverless 」を参照してください。 3. デフォルトを活用し、必要に応じてワーカーを適正化 ワーカー はワークロードのタスクを実行するために使用されます。EMR Serverless のデフォルト設定はほとんどのユースケースに最適化されていますが、処理時間の改善やコスト効率の最適化のためにワーカーのサイズを適正化する必要がある場合があります。EMR Serverless ジョブを送信する際は、メモリサイズ (GB) やコア数などのワーカー設定を Spark プロパティで定義することを推奨します。 EMR Serverless のデフォルトワーカーサイズは 4 vCPU、16 GB メモリ、20 GB ディスクです。一般的にほとんどのジョブにバランスの取れた構成ですが、パフォーマンス要件に応じてサイズを調整することもできます。事前初期化ワーカーに特定のサイズを設定している場合でも、ジョブ送信時に必ず Spark プロパティを設定してください。事前初期化キャパシティを超えてスケールする際に、デフォルトプロパティではなく指定したワーカーサイズが使用されます。Spark ワークロードの適正化では、ジョブの vCPU:メモリ比率が重要です。エグゼキューターの仮想 CPU コアあたりに割り当てるメモリ量は、この比率で決まります。Spark エグゼキューターはデータを効果的に処理するために CPU とメモリの両方が必要で、最適な比率はワークロードの特性によって異なります。 まずは以下のガイダンスを参考にし、ワークロード固有の要件に基づいて設定を調整してください。 エグゼキューター設定 以下の表は、一般的なワークロードパターンに基づく推奨エグゼキューター設定です: ワークロードタイプ 比率 CPU メモリ 設定 コンピューティング集約型 1:2 16 vCPU 32 GB spark.emr-serverless.executor.cores=16spark.emr-serverless.executor.memory=32G 汎用 1:4 16 vCPU 64 GB spark.emr-serverless.executor.cores=16spark.emr-serverless.executor.memory=64G メモリ集約型 1:8 16 vCPU 108 GB spark.emr-serverless.executor.cores=16spark.emr-serverless.executor.memory=108G ドライバー設定 以下の表は、一般的なワークロードパターンに基づく推奨ドライバー設定です: ワークロードタイプ 比率 CPU メモリ 設定 汎用 1:4 4 vCPU 16 GB spark.emr-serverless.driver.cores=4spark.emr-serverless.driver.memory=16G Apache Iceberg ワークロード 1:8 (メタデータルックアップ用の大きなドライバー) 8 vCPU 60 GB spark.emr-serverless.driver.cores=8spark.emr-serverless.driver.memory=60G 設定をさらにモニタリングおよびチューニングするには、 Amazon CloudWatch ジョブワーカーレベルメトリクス でワークロードのリソース消費を監視し、ボトルネックを特定します。CPU 使用率、メモリ使用量、ディスク使用率のメトリクスを追跡し、以下の表を参考に設定を調整してください。 観測されたメトリクス ワークロードタイプ 推奨アクション 1 高メモリ (>90%)、低 CPU (<50%) メモリバウンドワークロード vCPU:メモリ比率を増加 2 高 CPU (>85%)、低メモリ (<60%) CPU バウンドワークロード vCPU 数を増加し、1:4 比率を維持 (例: 8 vCPU 使用時は 32 GB メモリ) 3 高ストレージ I/O、通常の CPU/メモリ、長いシャッフル操作 シャッフル集約型 サーバーレスストレージ または シャッフル最適化ディスク を有効化 4 全メトリクスで低使用率 過剰プロビジョニング ワーカーサイズまたは数を削減 5 一貫して高使用率 (>90%) 過少プロビジョニング ワーカー仕様をスケールアップ 6 頻繁な GC 一時停止** メモリ圧迫 メモリオーバーヘッドを増加 (10〜15%) **頻繁なガベージコレクション (GC) の一時停止は、Spark UI の Executors タブで確認できます。GC time 列があり、一般的にタスク時間の 10% 未満であるべきです。また、ドライバーログに GC (Allocation Failure)] メッセージが頻繁に含まれている場合もあります。 4. T シャツサイジングでスケーリング境界を制御 デフォルトでは、EMR Serverless は 動的リソース割り当て (DRA) を使用し、ワークロードの需要に基づいてリソースを自動スケーリングします。EMR Serverless はジョブのメトリクスを継続的に評価してコストと速度を最適化するため、必要なワーカー数を見積もる必要がありません。 コスト最適化と予測可能なパフォーマンスのために、以下のいずれかのアプローチでスケーリングの上限を設定できます: ジョブレベルで spark.dynamicAllocation.maxExecutors パラメータを設定 アプリケーションレベルの最大キャパシティ を設定 各ジョブの spark.dynamicAllocation.maxExecutors を個別に細かく調整するのではなく、ワークロードプロファイルを表す T シャツサイズとして設定を考えることができます: ワークロードサイズ ユースケース spark.dynamicAllocation.maxExecutors Small 探索的クエリ、開発 50 Medium 定期的な ETL ジョブ、レポート 200 Large 複雑な変換、大規模処理 500 この T シャツサイジングアプローチにより、キャパシティプランニングが簡素化され、個々のジョブを最適化するのではなく、ワークロードカテゴリに基づいてパフォーマンスとコスト効率のバランスを取れます。 EMR Serverless リリース 6.10 以降では、 spark.dynamicAllocation.maxExecutors のデフォルト値は無制限ですが、それ以前のリリースでは 100 です。 EMR Serverless はジョブの各ステージで必要なワークロードと並列性に基づいて、ワーカーを自動的にスケールアップまたはスケールダウンします。ジョブのメトリクスを継続的に評価してコストと速度を最適化するため、ワーカー数を見積もる必要がありません。 ただし、予測可能なワークロードの場合、エグゼキューター数を静的に設定したい場合があります。その場合は DRA を無効にしてエグゼキューター数を手動で指定します: spark.dynamicAllocation.enabled=false spark.executor.instances=10 5. EMR Serverless ジョブに適切なストレージをプロビジョニング ストレージオプションを理解し、適切にサイジングすることで、ジョブの失敗を防ぎ、実行時間を最適化できます。EMR Serverless は、ジョブ実行中の中間データを処理するストレージオプションが複数あります。選択するストレージオプションは EMR リリースとユースケースによって異なります。EMR Serverless で利用可能なストレージオプションは以下のとおりです: ストレージタイプ EMR リリース ディスクサイズ範囲 ユースケース メリット サーバーレスストレージ (推奨) 7.12+ N/A (自動スケーリング) ほとんどの Spark ワークロード、特にデータ集約型ワークロード ストレージコストなし 自動スケーリング ディスク障害の削減 最大 20% のコスト削減 標準ディスク 7.11 以前 ワーカーあたり 20〜200 GB 10 TB 未満のデータセットを処理する小〜中規模ワークロード シンプルな設定 デフォルト 20 GB でほとんどのワークロードに対応 最適なスループットには最大 200 GB シャッフル最適化ディスク 7.1.0+ ワーカーあたり 20〜2,000 GB マルチ TB を処理する大規模 ETL ワークロード 高 IOPS とスループット ワーカーあたり最大 2 TB のキャパシティ ストレージ設定をワークロードの特性に合わせることで、EMR Serverless ジョブを大規模でも効率的かつ安定的に実行できます。 6. マルチ AZ がデフォルトで組み込みの回復力を提供 EMR Serverless アプリケーションは、事前初期化キャパシティが有効でない場合、最初からマルチ AZ です。フェイルオーバーが組み込まれているため、手動操作なしで AZ 障害に対応できます。単一のジョブは単一のアベイラビリティゾーン内で動作し、クロス AZ データ転送コストを防ぎます。後続のジョブは複数の AZ に適切に分散されます。EMR Serverless が AZ の障害を検出すると、新しいジョブを正常な AZ に送信し、AZ 障害にもかかわらずワークロードの実行を継続できます。 EMR Serverless のマルチ AZ 機能を最大限に活用するには、以下を確認してください: 複数のアベイラビリティゾーンにまたがるサブネットを選択して VPC へのネットワーク接続 を設定 アプリケーションを単一の AZ に制限する事前初期化キャパシティを避ける ワーカーのスケーリングをサポートするために各サブネットに十分な IP アドレスがあることを確認 マルチ AZ に加えて、Amazon EMR 7.1 以降では ジョブの回復力 を有効にでき、エラーが発生した場合にジョブを自動的にリトライできます。複数のアベイラビリティゾーンが設定されている場合、別の AZ でもリトライされます。この機能は バッチ ジョブと ストリーミング ジョブの両方で有効にできますが、リトライ動作は両者で異なります。 最大リトライ回数を定義するリトライポリシーを指定してジョブの回復力を設定します。バッチジョブのデフォルトは自動リトライなし (maxAttempts=1) です。ストリーミングジョブでは、EMR Serverless は無制限にリトライし、1 時間以内に 5 回失敗するとリトライを停止するスラッシング防止機能が組み込まれています。このしきい値は 1〜10 回の間で設定できます。詳細は「 Job resiliency 」を参照してください。 ジョブをキャンセルする必要がある場合、デフォルトの即時終了ではなく、ジョブをクリーンにシャットダウンするための 猶予期間 を指定できます。カスタムクリーンアップアクションを実行する必要がある場合は、カスタムシャットダウンフックも含められます。 マルチ AZ サポート、自動ジョブリトライ、グレースフルシャットダウン期間を組み合わせることで、中断に耐え、手動操作なしでデータの整合性を維持できる EMR Serverless ワークロードを構築できます。 7. VPC 統合でセキュリティと接続性を拡張 デフォルトでは、EMR Serverless は Amazon Simple Storage Service (Amazon S3)、 AWS Glue 、 Amazon CloudWatch Logs 、 AWS Key Management Service (AWS KMS)、 AWS Security Token Service (AWS STS)、 Amazon DynamoDB 、 AWS Secrets Manager などの AWS サービスにアクセスできます。 Amazon Redshift や Amazon Relational Database Service (Amazon RDS) など VPC 内のデータストアに接続するには、EMR Serverless アプリケーションの VPC アクセスを設定する必要があります。 EMR Serverless アプリケーションの VPC アクセスを設定する際は、最適なパフォーマンスとコスト効率のために以下の考慮事項に留意してください: 十分な IP アドレスを計画 – 各ワーカーはサブネット内で 1 つの IP アドレスを使用します。ジョブのスケールアウト時に起動されるワーカーも含まれます。IP アドレスが不足すると、ジョブがスケールできず、ジョブの失敗につながる可能性があります。最適なパフォーマンスのために サブネットプランニングのベストプラクティス に従っていることを確認してください。 プライベートサブネットのアプリケーションには Amazon S3 用ゲートウェイエンドポイント を設定 – VPC エンドポイントなしでプライベートサブネットで EMR Serverless を実行すると、Amazon S3 トラフィックが NAT ゲートウェイ経由でルーティングされ、追加のデータ転送料金が発生します。S3 用 VPC エンドポイントにより、トラフィックを VPC 内に保持し、コストを削減して Amazon S3 操作のパフォーマンスを向上できます。 ネットワークインターフェースの AWS Config コストを管理 – EMR Serverless は各ワーカーに対して AWS Config にエラスティックネットワークインターフェースレコードを生成し、ワークロードのスケールに伴いコストが蓄積される可能性があります。EMR Serverless ネットワークインターフェースの AWS Config 追跡が不要な場合は、リソースベースの除外やタグ付け戦略を使用してフィルタリングし、他のリソースの AWS Config カバレッジは維持することを検討してください。 詳細は「 Configuring VPC access for EMR Serverless applications 」を参照してください。 8. ジョブ送信と依存関係管理を簡素化 EMR Serverless は StartJobRun API による柔軟なジョブ送信をサポートしており、完全な spark-submit 構文を受け付けます。ランタイム環境の設定には、 spark.emr-serverless.driverEnv と spark.executorEnv プレフィックスを使用して、ドライバーとエグゼキュータープロセスの環境変数を設定します。機密設定やランタイム固有の設定を渡す際に特に便利です。 Python アプリケーションの場合、venv を作成し、tar.gz アーカイブとしてパッケージ化するか、 spark.archives を使用して Amazon S3 にアップロードし、適切な PYSPARK_PYTHON 環境変数を設定して、仮想環境で依存関係をパッケージ化すると、ドライバーとエグゼキューターワーカー全体で Python の依存関係を利用できます。 高負荷時の制御を向上させるには、 ジョブの同時実行とキューイング (EMR 7.0.0+ で利用可能) を有効にして、同時に実行できるジョブ数を制限します。この機能により、同時実行制限を超えて送信されたジョブは、リソースが利用可能になるまでキューに入れられます。 ジョブの同時実行とキュー設定は、 CreateApplication または UpdateApplication API の SchedulerConfiguration プロパティで設定できます。 --scheduler-configuration '{"maxConcurrentRuns": 5, "queueTimeoutMinutes": 30}' 9. EMR Serverless の設定で制限を適用 EMR Serverless はワークロードの需要に基づいてリソースを自動スケーリングし、ほとんどのユースケースで Spark 設定のチューニングなしで機能する最適化されたデフォルトが用意されています。コスト管理のために、予算とパフォーマンス要件に合ったリソース制限を設定できます。高度なユースケースでは、リソース消費を細かく調整し、クラスターベースのデプロイメントと同等の効率を実現する設定オプションも提供しています。制限を適切に設定することで、パフォーマンスとコスト効率のバランスを取れます。 制限タイプ 目的 設定方法 ジョブレベル 個々のジョブのリソースを制御 spark.dynamicAllocation.maxExecutors または spark.executor.instances アプリケーションレベル アプリケーションまたはビジネスドメインごとのリソースを制限 アプリケーション作成時または更新時に最大キャパシティを設定 アカウントレベル 全アプリケーションにわたる異常なリソーススパイクを防止 自動調整可能なサービスクォータ「 Max concurrent vCPUs per account 」。 Service Quotas コンソール から引き上げをリクエスト これら 3 つのレイヤーの制限が連携して、異なるスコープで柔軟にリソースを管理できます。ほとんどのユースケースでは、T シャツサイジングアプローチによるジョブレベルの制限設定で十分であり、アプリケーションレベルとアカウントレベルの制限はコスト管理の追加的なガードレールになります。 10. CloudWatch、Prometheus、Grafana でモニタリング EMR Serverless ワークロードのモニタリングにより、デバッグ、コスト最適化、パフォーマンス追跡が容易になります。EMR Serverless は連携する 3 つのモニタリング階層があります: Amazon CloudWatch、 Amazon Managed Service for Prometheus 、 Amazon Managed Grafana です。 Amazon CloudWatch – CloudWatch 統合 はデフォルトで有効になっており、AWS/EMRServerless 名前空間にメトリクスを発行します。EMR Serverless はアプリケーションレベル、ジョブ、ワーカータイプ、キャパシティ割り当てタイプレベルで毎分 CloudWatch にメトリクスを送信します。CloudWatch を使用して、ワークロードの可観測性を高める ダッシュボード を設定したり、ジョブの失敗、スケーリングの異常、SLA 違反に対する アラーム を設定できます。CloudWatch と EMR Serverless を使用することで、ユーザーに影響が出る前に問題を検知できます。 Amazon Managed Service for Prometheus – EMR Serverless リリース 7.1+ では、Prometheus を有効にして詳細な Spark エンジンメトリクス を Amazon Managed Service for Prometheus にプッシュでき、メモリ使用量、シャッフルボリューム、GC 圧力などエグゼキューターレベルで可視化できます。メモリ制約のあるエグゼキューターの特定、シャッフルが多いステージの検出、データスキューの発見に活用できます。 Amazon Managed Grafana – Grafana は CloudWatch と Prometheus の両方のデータソースに接続し、可観測性と相関分析を統合した単一画面として利用できます。3 つの階層を組み合わせることで、インフラストラクチャの問題とアプリケーションレベルのパフォーマンス問題を関連付けられます。 追跡すべき主要メトリクス: ジョブの完了時間と成功率 ワーカーの使用率とスケーリングイベント シャッフルの読み取り/書き込みボリューム メモリ使用パターン 詳細は「 Monitor Amazon EMR Serverless workers in near real time using Amazon CloudWatch 」を参照してください。 まとめ 本記事では、パフォーマンスの最適化、コスト管理、大規模での安定した運用を実現するための Amazon EMR Serverless のベストプラクティス 10 選を紹介しました。アプリケーション設計、ワークロードの適正化、アーキテクチャの選択に注力することで、効率的で回復力のあるデータ処理パイプラインを構築できます。 詳細は「 Getting started with EMR Serverless 」ガイドを参照してください。 著者について Karthik Prabhakar Karthik は、Amazon Web Services (AWS) の Amazon EMR データ処理エンジンアーキテクトです。分散システムアーキテクチャとクエリ最適化を専門とし、大規模データ処理ワークロードにおける複雑なパフォーマンス課題の解決をお客様と共に取り組んでいます。エンジン内部、コスト最適化戦略、ペタバイト規模の分析を効率的に実行するためのアーキテクチャパターンに注力しています。 Neil Mukerje Neil は、Amazon Web Services のプリンシパルプロダクトマネージャーです。 Amber Runnels Amber は、Amazon Web Services (AWS) のシニアアナリティクススペシャリストソリューションアーキテクトで、ビッグデータと分散システムを専門としています。AWS のデータサービスでワークロードを最適化し、スケーラブルで高パフォーマンス、コスト効率の高いアーキテクチャの実現をお客様に支援しています。 Parul Saxena Parul は、Amazon Web Services (AWS) のシニアビッグデータスペシャリストソリューションアーキテクトです。高度に最適化されたスケーラブルでセキュアなソリューションの構築をお客様やパートナーに支援しています。Amazon EMR、Amazon Athena、AWS Lake Formation を専門とし、複雑なビッグデータワークロードのアーキテクチャガイダンスや、組織のアーキテクチャモダナイゼーションと分析ワークロードの AWS への移行を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Woosuk Choi がレビューしました。

本記事は 2026 年 3 月 6 日に公開された “ AWS Load Balancer Controller adds general availability support for Kubernetes Gateway API ” を翻訳したものです。 AWS は最近、 Amazon Web Services (AWS) Load Balancer Controller による Kubernetes Gateway API サポートの一般提供を発表しました。これまで、AWS Load Balancer Controller は Kubernetes Ingress と Service リソースの要件を満たすため、それぞれ Application Load Balancer (ALB) と Network Load Balancer (NLB) をプロビジョニングしていました。この新機能により、標準の Kubernetes Gateway API を使用してAWSロードバランシング機能を定義できるようになりました。この投稿では、AWS Load Balancer Controller の Kubernetes Gateway API サポートをご紹介します。Gateway API 統合の構成ベストプラクティス、機能、ユースケースを共有し、AWS 上での Kubernetes デプロイメントのモダナイゼーションと合理化を支援します。 前提条件 Kubernetes API、コントローラー、Deployments、Services、カスタムリソースなどのリソースタイプを含む Kubernetes の概念に精通していることを前提としています。また、 Amazon Elastic Kubernetes Service (Amazon EKS) と AWS ロードバランシングサービスについての基本的な理解も必要です。これらの概念を復習する必要がある場合は、Kubernetes ドキュメントと Amazon EKS ユーザーガイドから始めることをお勧めします。 Gateway API 概要 Gateway API は、Kubernetes クラスターで L4 (TCP/UDP) および L7 (HTTP/gRPC) トラフィックルーティングを管理するための次世代フレームワークです。従来の Ingress API よりも柔軟で表現力豊かなロール指向のアプローチを提供し、Ingress における以前の制限に対処しています。流入トラフィック (north-south トラフィック) やサービス間接続 (east-west トラフィック) を含む、幅広いトラフィック管理ニーズに対応する標準化された、ポータブルで拡張可能な仕様を提供します。 Ingress API は長年にわたって Kubernetes ユーザーによく貢献してきましたが、Gateway API が対処するいくつかの制限があります。Ingress は高度な機能に対してベンダー固有のアノテーションに依存しており、異なる実装間での構成の移植性を低下させています。さらに、ロールベースのリソース管理のネイティブサポートが不足しており、これはクラスター運用者とアプリケーション開発者が同じ構成面を共有することを意味します。Gateway API は、インフラストラクチャプロバイダー (GatewayClass)、クラスター運用者 (Gateway)、アプリケーション開発者 (Routes) に対して異なるリソースを持つロール指向設計を導入しています。この分離により、より良い組織ポリシーとセキュリティ境界が可能になります。さらに、Gateway API は、クロス名前空間ルーティング、重み付きトラフィック分割、ヘッダーベースルーティング、L4 と L7 の両方のプロトコルに対するネイティブサポートを提供します。これらの機能は以前は複雑な回避策が必要であったか、Ingress だけでは不可能でした。これらの改善により、Gateway API はより表現力豊かで拡張可能であり、現代のクラウドアーキテクチャに適したものになります。 AWS のフルマネージドアプリケーションネットワーキングサービスである Amazon VPC Lattice は、 Amazon VPC Lattice Gateway API Controller を通じて Kubernetes Gateway API のサポートを既に提供しています。これは、VPC とアカウント内の EKS クラスター間でサービス間接続を可能にする別のコントローラーです。AWS Load Balancer コントローラーも Gateway API 仕様をサポートすることで、ALB と NLB による流入 (north-south）トラフィック管理と、east-west サービスメッシュ機能に VPC Lattice を使用する柔軟性の両方について包括的なカバレッジを得ることができます。そして、これらはすべて同じ標準化された Gateway API リソースを使用して実現されます。 Gateway API コンポーネント Gateway API は、Kubernetes クラスターへのトラフィックの流入と通過の方法を定義するために連携する 3 つのコアリソースを導入します。これらのコンポーネントとそれらが AWS インフラストラクチャにどのようにマッピングされるかを理解することで効果的なトラフィック管理戦略を設計できます。図 1 は Gateway API 仕様のコンポーネントを示しています: 図 1 : Gateway API コントローラーコンポーネント [ 出典 ] GatewayClass GatewayClass は、共通の構成と動作を持つ Gateway を作成するためのテンプレートを定義します。プラットフォームチームは GatewayClass を使用して組織ポリシーとインフラストラクチャテンプレートを確立します。例えば、GatewayClass はどのコントローラーが Gateway を管理するか (AWS Load Balancer Controller など) と、どのタイプのロードバランサーをプロビジョニングするか (ALB または NLB) を指定します。 以下は、ALB をプロビジョニングする GatewayClass の例です: apiVersion: gateway.networking.k8s.io/v1 kind: GatewayClass metadata: name: aws-alb spec: controllerName: gateway.k8s.aws/alb Gateway Gateway はロードバランサーをインスタンス化し、トラフィックがクラスターにどのように入るかを定義します。クラスター運用者は、リスナー (プロトコルとポートの組み合わせ)、ホスト名、TLS 設定を指定するように Gateway を構成します。Gateway を作成すると、AWS Load Balancer Controller は指定されたリスナーで対応する AWS ロードバランサーをプロビジョニングします。 以下は、HTTP と HTTPS リスナーを持つ ALB を作成する Gateway の例です: apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: my-gateway namespace: default spec: gatewayClassName: aws-alb listeners: - name: http protocol: HTTP port: 80 - name: https protocol: HTTPS port: 443 hostname: example.com Routes Routes は、リスナーをバックエンド Kubernetes サービスにマッピングするルーティングルールを定義します。アプリケーション開発者は、パス、ヘッダー、ホスト名などのリクエスト属性に基づいてトラフィックがサービスにどのように分散されるかを制御するために Routes (HTTPRoute、GRPCRoute、TCPRoute、UDPRoute、TLSRoute) を作成します。 以下は、Gateway の HTTP リスナーから Kubernetes サービスにトラフィックをルーティングする HTTPRoute の例です: apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: my-route namespace: default spec: parentRefs: - name: my-gateway sectionName: http rules: - matches: - path: type: PathPrefix value: /app backendRefs: - name: my-service port: 8080 AWS Load Balancer Controller は Kubernetes Gateway API オブジェクトの調整をサポートしています。以下を満たします: TCPRoute や UDPRoute などの L4 ルートを AWS NLB で HTTPRoute や GRPCRoute などの L7 ルートを AWS ALB で 動作の仕組み AWS Load Balancer Controller が Gateway API リソースを AWS インフラストラクチャにどのように変換するかを理解することで、より信頼性の高いアプリケーションを設計し、問題をより迅速にトラブルシューティングできます。コントローラーの調整モデルにより、Kubernetes の定義が AWS ロードバランサーと同期された状態を保ち、継続的な検証とリアルタイムステータスフィードバックを提供します。 高レベルでは、以下のステップが調整ループの動作を示しています: API 監視 : Gateway API リソースの作成、変更、削除について、Kubernetes API が継続的に監視されます。 キューイング : コントローラーは特定されたリソースを処理のための内部キューに追加します。 処理 : 内部キューの各アイテムに対して: コントローラーは関連する GatewayClass をチェックして、ユーザーが AWS ロードバランサーを要求しているかどうかを確認します。 yes の場合、対応する Gateway リソースの Gateway API 定義が、NLB/ALB、リスナー、リスナールール、ターゲットグループ、またはアドオンなどの AWS リソースにマッピングされます。 これらのマッピングされたリソースは、AWS の実際の状態と比較されます。差分があると、コントローラーは AWS の状態を Gateway オブジェクトによって設定された望ましい状態と一致させます。 ステータス更新 : 調整後、AWS Load Balancer Controller は対応する Gateway および Route リソースのステータスフィールドを更新します。これにより、ALB の DNS 名や Amazon Resource Name (ARN) などのプロビジョニングされた AWS リソース、およびデバッグを支援するエラー詳細について、リアルタイムフィードバックが提供されます。例えば、HTTPRoute を作成すると、ステータスフィールドにはルートが受け入れられたかどうか、それが接続されている Gateway、およびプロビジョニング時にトラフィックルーティングに使用する ALB の DNS 名がすぐに表示されます。無効な証明書 ARN などの構成エラーがある場合、ステータスフィールドは実用的なエラーメッセージを提供します。 図 2 は、この調整フローを詳細に示しています。コントローラーは Gateway API リソースに対するウォッチを確立し、内部キューを通じて変更を処理し、望ましい状態の中間表現を構築し、対応する AWS リソースを実現します。このプロセス全体を通じて、プロビジョニングの進行状況と発生したエラーを反映するためにステータス条件が更新されます。 図 2 : Gateway API コントローラー調整フロー この宣言的アプローチは、望ましいロードバランシング構成を一度定義すると、コントローラーが AWS がその意図と一致することを継続的に保証することを意味します。これにより、ドリフトと構成変更が自動的に処理されます。 主要機能 このセクションでは、Load Balancer Controller Gateway API サポートの主要機能について説明します: 強化されたカスタマイズ AWS Load Balancer Controller は、適切に定義された Kubernetes Custom Resource Definitions (CRD) を採用し、アノテーションベースの構成を廃止します。この変更により、検証や IDE サポートが不足しているアノテーション文字列に複雑なデータ構造を埋め込むという制限に対処します。例えば: Before (アノテーションベースアプローチ): apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress annotations: alb.ingress.kubernetes.io/target-group-attributes: | deregistration_delay.timeout_seconds=30, stickiness.enabled=true, stickiness.type=lb_cookie After (CRDベースアプローチ): apiVersion: gateway.k8s.aws/v1beta1 kind: TargetGroupConfiguration metadata: name: my-app-tg-config namespace: my-app spec: targetReference: name: my-service defaultConfiguration: targetGroupAttributes: - key: deregistration_delay.timeout_seconds value: "30" - key: stickiness.enabled value: "true" - key: stickiness.type value: lb_cookie healthCheckConfig: healthyThresholdCount: 5 healthCheckInterval: 30 healthCheckPath: /health healthCheckPort: "8080" healthCheckProtocol: HTTP healthCheckTimeout: 5 unhealthyThresholdCount: 2 AWS Load Balancer Controller は Gateway API カスタマイズのために 3 つの CRD を導入しています： TargetGroupConfiguration : サービスレベルでヘルスチェック、登録解除遅延、スティッキネス設定を含むターゲットグループプロパティを構成 LoadBalancerConfiguration : Gateway または GatewayClass レベルでサブネット配置、セキュリティグループ、アクセスログなどのリスナーおよびロードバランサープロパティを定義 ListenerRuleConfiguration : Amazon Cognito または OIDC プロバイダーを通じた認証を含む AWS 固有のルーティング動作で HTTPRoute および GRPCRoute リソースを拡張 これらの CRD は、スキーマ検証、タイプセーフティ、GitOps ワークフローとのネイティブ統合を提供します。構成エラーは実行時ではなく適用時に表面化し、運用オーバーヘッドを削減し、インフラストラクチャの信頼性を向上させます。 Cross-Namespace トラフィックルーティング Gateway API は、Cross-Namespace ルーティングを通じてインフラストラクチャ運用者とアプリケーション開発者の間の関心の分離を可能にします。プラットフォームチームは共有 Gateway リソースをプロビジョニングし、アプリケーションチームはクラスターレベルの権限を必要とせずに独自の Rout を管理します。 このモデルでは、プラットフォームチームがアクセス制御された専用の名前空間に Gateway をデプロイします。別々の名前空間のアプリケーションチームは、共有 Gateway を参照する Route リソースを作成します。コントローラーは、これらの分散された定義に基づいてトラフィックをルーティングするようにロードバランサーを自動的に構成します。 このアーキテクチャは、Kubernetes API レベルで RBAC 境界を強制します。アプリケーションチームは、サブネット配置やセキュリティグループ割り当てなどのインフラストラクチャレベルの構成にアクセスすることなく、サービスのルーティングロジックを管理します。 自動 TLS 証明書検出 AWS Load Balancer Controller は、L4 と L7 の両方のプロトコルについて、Ingress API から Gateway API リスナーへの証明書検出を拡張します。Gateway リスナーまたは Route ホスト名でホスト名が指定されると、コントローラーは AWS Certificate Manager (ACM) にクエリを実行して、ホスト名マッチングに基づいて一致する証明書を見つけて添付します。 コントローラーは証明書の更新について ACM を監視し、ロードバランサー構成に変更を自動的に適用します。これにより、手動での証明書 ARN 管理が不要になり、複数の環境間での証明書ローテーションの運用複雑性が軽減されます。 これらの機能により運用オーバーヘッドを削減し、関心の分離を改善した本格的な AWS 上の Kubernetes ネットワーキングが可能になります。型安全な CRD、Cross-Namespace ルーティング、自動証明書管理の組み合わせにより、チームはインフラストラクチャ構成ではなくアプリケーション配信に集中できます。 始め方 初回ユーザーの場合は、インストールガイドに従ってください。このガイドでは、必要な AWS Identity and Access Management (IAM) 権限を設定し、AWS Load Balancer Controller を Kubernetes クラスターにデプロイします。 AWS Load Balancer Controller で Gateway API サポートを有効にするには、まず 前提条件 が満たされていることを確認してください。その後、Gateway API サポートを有効にするには、 こちら で説明されているように機能フラグを有効にする必要があります。 構成例 この例では、AWS Load Balancer Controller Gateway API 統合の 3 つの主要機能を実証します : HTTP ルーティング、自動証明書検出を使用した HTTPS ルーティング、ListenerRuleConfiguration を使用したカスタムルーティングルール。デプロイメント手順と検証コマンドを含む完全なウォークスルーについては、AWS Load Balancer Controller Gateway API の例を参照してください。 この例では、以下のアーキテクチャでALBをプロビジョニングします： ポート 80 の HTTP リスナーが blue デプロイメントにルーティング ポート 443 の HTTPS リスナーが自動証明書検出により orange デプロイメントにルーティング HTTP リスナー上の /alb-response パスに対して固定レスポンスを返すカスタムルーティングルール 構成概要 構成には以下が含まれます: AWS Load Balancer Controller を実装として定義する GatewayClass : # alb-gatewayclass.yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: GatewayClass metadata: name: aws-alb-gateway-class spec: controllerName: gateway.k8s.aws/alb HTTP および HTTPS リスナーを持つ Gateway : # my-alb-gateway.yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: Gateway metadata: name: my-alb-gateway namespace: example-ns spec: gatewayClassName: aws-alb-gateway-class infrastructure: parametersRef: kind: LoadBalancerConfiguration name: lbconfig-gateway group: gateway.k8s.aws listeners: - name: http protocol: HTTP port: 80 allowedRoutes: namespaces: from: Same - name: https hostname: "sample.com" protocol: HTTPS port: 443 allowedRoutes: namespaces: from: Same スキームまたはその他のゲートウェイ構成パラメータ用の LoadBalancerConfiguration : # lb-config-gateway.yaml apiVersion: gateway.k8s.aws/v1beta1 kind: LoadBalancerConfiguration metadata: name: lbconfig-gateway namespace: example-ns spec: loadBalancerName: "my-example-gateway-alb" scheme: internet-facing カスタムルーティング動作用の ListenerRuleConfiguration : # listener-rule-config-blue.yaml apiVersion: gateway.k8s.aws/v1beta1 kind: ListenerRuleConfiguration metadata: name: blue-lrc-config namespace: example-ns spec: actions: - type: "fixed-response" fixedResponseConfig: statusCode: 404 contentType: "text/plain" messageBody: "customized text" リスナーをバックエンドサービスにマッピングする HTTPRoutes : # httproute-blue.yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: http-route-blue namespace: example-ns spec: parentRefs: - group: gateway.networking.k8s.io kind: Gateway name: my-alb-gateway sectionName: http rules: - matches: - path: value: "/alb-response" filters: - type: ExtensionRef extensionRef: group: "gateway.k8s.aws" kind: "ListenerRuleConfiguration" name: "blue-lrc-config" - backendRefs: - name: service-blue port: 80 # httproute-orange.yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: http-route-orange namespace: example-ns spec: parentRefs: - group: gateway.networking.k8s.io kind: Gateway name: my-alb-gateway sectionName: https rules: - backendRefs: - name: service-orange port: 80 デプロイとテスト この例をデプロイするには、バックエンドの DeploymentsとServices が必要です。以下のリソースを作成してください: # deployment-orange.yaml apiVersion: apps/v1 kind: Deployment metadata: name: deployment-orange namespace: example-ns spec: selector: matchLabels: app: orange-app replicas: 1 template: metadata: labels: app: orange-app spec: containers: - image: k8s.gcr.io/e2e-test-images/echoserver:2.5 imagePullPolicy: Always name: echoserver ports: - containerPort: 8080 --- # deployment-blue.yaml apiVersion: apps/v1 kind: Deployment metadata: name: deployment-blue namespace: example-ns spec: selector: matchLabels: app: blue-app replicas: 1 template: metadata: labels: app: blue-app spec: containers: - image: k8s.gcr.io/e2e-test-images/echoserver:2.5 imagePullPolicy: Always name: echoserver ports: - containerPort: 8080 --- # service-orange.yaml apiVersion: v1 kind: Service metadata: name: service-orange namespace: example-ns spec: ports: - port: 80 targetPort: 8080 protocol: TCP type: NodePort selector: app: orange-app --- # service-blue.yaml apiVersion: v1 kind: Service metadata: name: service-blue namespace: example-ns spec: ports: - port: 80 targetPort: 8080 protocol: TCP type: ClusterIP selector: app: blue-app Gateway がプロビジョニングされるまで待機します: kubectl wait --for=condition=Programmed gateway/my-alb-gateway -n example-ns デプロイメントの検証 blue デプロイメントへの HTTP ルーティングをテストします: # ALB ホスト名を取得 ALB_HOSTNAME=$(kubectl get gateway my-alb-gateway \ -n example-ns \ -o jsonpath='{.status.addresses[0].value}') # HTTP エンドポイントをテスト curl http://$ALB_HOSTNAME orange デプロイメントへの証明書検出を使用した HTTPS ルーティングをテストします: curl -k https://$ALB_HOSTNAME -H "Host: sample.com" カスタムルーティングルールをテストします: curl http://$ALB_HOSTNAME/alb-response NLB 構成、Cross-Namespace ルーティング、高度なカスタマイゼーションシナリオを含むその他の例については、AWS Load Balancer Controller ドキュメントを参照してください。 考慮事項 GatewayClass によるポリシー強制 : プラットフォームチームは、サブネット配置、セキュリティグループ割り当て、アクセスログを制御する LoadBalancerConfiguration 設定を持つ GatewayClass リソースを定義します。アプリケーションチームは、インフラストラクチャ変更権限なしに承認された GatewayClass オプションから選択します。これにより、 Kubernetes RBAC を通じて内部ワークロードをインターネット向けロードバランサーから分離するなどの組織ポリシーが強制されます。 標準ベースの移植性 : Gateway、GatewayClass、Route リソースは Kubernetes Gateway API 仕様に従います。コアルーティングロジックは実装間で一貫性を保ちます。AWS 固有の CRD (LoadBalancerConfiguration、TargetGroupConfiguration、ListenerRuleConfiguration) はオプションのままで、コアルーティング定義から分離されています。これにより、必要に応じてAWS固有の機能を持つポータブルなアプリケーション構成が可能になります。 運用可視性 : コントローラーは、リアルタイムプロビジョニング進行状況、リソース識別子 (ロードバランサー ARN と DNS 名)、エラーメッセージで Gateway API ステータスフィールドを更新します。これにより、トラブルシューティング時間が短縮され、リソース状態を確認するための直接的な AWS API クエリが不要になります。 AWS サービス統合 : この実装は、自動証明書検出のための ACM、アプリケーション保護のための AWS WAF 、DDoS 保護のための AWS Shield Advanced と統合されます。ターゲットグループ構成、ヘルスチェック、アクセスログは Amazon S3 および Amazon CloudWatch と統合されます。 GitOps 互換性 : スキーマ検証を持つ型安全な CRDは、デプロイ前検証中に構成エラーを表面化します。Infrastructure as Code (IaC) ツールである Flux 、 ArgoCD 、Kubernetes 用 AWS Cloud Development Kit (AWS CDK) は、自動ドリフト検出を伴う宣言的インフラストラクチャ管理のための Gateway API サポートを提供します。 まとめ AWS Load Balancer Controller の Gateway API サポートは、AWS 上での Kubernetes トラフィック管理に対する標準ベースのアプローチを提供します。Gateway API 仕様を採用することで、Kubernetes 環境間での移植性を維持しながら、ロール指向のリソース管理、Cross-Namespace ルーティング機能、型安全な CRD による拡張されたカスタマイゼーションを得ることができます。プラットフォームチームが Ingress ベースの構成から移行する場合でも、新しい Kubernetes デプロイメントを構築する場合でも、Gateway API 統合によってアプリケーションチームにセルフサービスルーティング機能を提供しながら組織ポリシーを強制することができます。この実装は、証明書管理、セキュリティ、可観測性のためのネイティブ AWS 統合と組み合わせることで運用ワークフローを合理化し、構成の複雑性を軽減します。AWS Load Balancer Controller デプロイメントで Gateway API サポートを有効にして、今すぐ始めましょう。詳細な構成例とベストプラクティスについては、AWS Load Balancer Controller ドキュメントを参照してください。

本記事は 2026/2/24に投稿された Well-Architected design for resiliency with Oracle Database@AWS を翻訳した記事です。 Oracle Database@AWS は、Amazon Web Services（AWS）データセンター内で Oracle Cloud Infrastructure（OCI）によって管理される Oracle Exadata インフラストラクチャを使用する データベースサービス を通じて、エンタープライズグレードのデータベース機能を提供します。Oracle Database@AWS を使用して、オンプレミスの Oracle Exadata と同じパフォーマンスと機能を維持しながら、Oracle Exadata ワークロードを AWS に移行できます。Oracle Exadata と AWS 上で実行されているアプリケーション間で低遅延接続を確立することで、アプリケーション遅延の削減という恩恵を受けることができます。さらに、観測可能性、分析、人工知能と機械学習（AI/ML）、生成 AI アプリケーションの構築など、様々な機能のために Oracle Database@AWS を他のAWS サービスと統合できます。複数のアベイラビリティーゾーンにわたって自動管理、最適化されたパフォーマンス、および組み込みセキュリティ機能を提供することで、Oracle Database@AWS は最高レベルのデータベース信頼性とパフォーマンスを維持しながら運用オーバーヘッドの削減に役立ちます。 高可用性（HA）と災害復旧（DR）オプションは、Oracle Database@AWS で重要なデータベースを移行または展開する際に考慮すべき重要な側面であり、アーキテクチャがアプリケーションのサービスレベルアグリーメント（SLA）を満たせるようにするためにも役立ちます。ハードウェア障害、リージョン障害、またはその他の中断によってデータベースにダウンタイムが発生すると、重大な収益損失、顧客関係の悪化、および潜在的なコンプライアンス違反に直面する可能性があり、堅牢な可用性ソリューションがビジネスにとって必要不可欠です。これらの課題に対処するために、Oracle Database@AWS の多層的なアプローチを使用して、包括的な保護戦略を実装できます。高可用性のためのクロス AZ 構成と災害復旧のためのクロスリージョン設定の両方で Oracle Data Guard を使用することにより、ローカルハードウェア障害から AWS リージョン全体の障害まで及ぶ多層防御保護を構築できます。 この投稿は、Oracle の Maximum Availability Architecture（MAA） のベストプラクティスと AWS の Well-Architected フレームワーク に従った Data Guard 構成の実装と維持に役立ちます。適切なネットワークアーキテクチャの選択方法と、クロス AZ とクロスリージョンの両方に Data Guard アソシエーションを構成する方法を示します。これにより、ロール移行中にアプリケーションがシームレスな接続を維持できるようにします。 Data Guard を使用した Oracle Database@AWS での HA とDR Oracle Database@AWS で提供される Exadata Database Service on Dedicated Infrastructure（ExaDB-D）と Autonomous Database Dedicated（ADB-D）サービスは、Data Guard 構成を作成および維持するためのマネージド体験を提供します。プライマリとスタンバイの仮想マシン（VM）クラスター間で必要な接続が確立された後、OCI コンソールまたはコマンドラインインターフェース（CLI）を使用してプライマリサイトとスタンバイサイト間の Data Guard 構成を構築できます。次の図は、同一リージョン内の2つの AZ 間およびリージョン間で Data Guard アソシエーションを使用した ExaDB-D の HA/DR 構成のリファレンスアーキテクチャを示しています。 次の表は、ExaDB-D と ADB-D サービスで利用可能な Data Guard アソシエーション機能の比較を示しています。 機能 ExaDB-D ADB-D Data Guardの作成と管理のマネージド体験 はい はい クロス AZ 構成の自動フェイルオーバー はい：顧客管理の Data Guard Observer（FSFO） はい クロスリージョン構成の自動フェイルオーバー はい：顧客管理の Data Guard Observer（FSFO） はい サポートされるスタンバイデータベース数（ローカルとリモートを含む） 6 2 推奨構成 クロス AZ では最大可用性(Maximum availability)、クロスリージョンでは最大パフォーマンス(Maximum performance) クロス AZ では最大可用性(Maximum availability)、クロスリージョンでは最大パフォーマンス(Maximum performance) Data Guard アソシエーションのネットワーク接続を確立するには、2つのオプションから選択できます： AWS Transit Gateway を使用して、2つの AZ または2つのリージョンにある2つのODBネットワークを接続する。 クロス AZ 構成ではローカルピアリングゲートウェイを使用し、クロスリージョンでの Data Guard 構成の場合はリモート VCN ピアリングと 動的ルーティングゲートウェイ （DRG）を使用して、OCI Virtual Cloud Network（VCN） レベルでピアリングを確立する。 次のセクションでは、Oracle Database@AWS の Data Guard アソシエーションにおける様々な接続オプションのネットワーク詳細、利点、およびコストへの影響について詳しく説明します。 同一リージョン内のクロス AZ デプロイメント AWS 上のレジリエンシーのあるデータベースアーキテクチャの基盤は、プライマリ AZ の障害から重要なデータベースを保護することから始まります。ExaDB-D と ADB-D の両方のサービスで利用可能なクロス AZ Data Guard 構成のネットワークオプションを見ていきましょう。 Data Guard 接続に2つの ODB ネットワークを接続するための Transit Gateway を使用する Transit Gateway を使用して、リージョン内の2つの AZ にある2つの ODB ネットワーク 間のトラフィックを AWS ネットワーク内でルーティングできます。次の図は、2つの AZ （ az1 と az2 ）でホストされている2つの Exadata VM クラスターと ODB ネットワーク間の構成の詳細を示しており、各 ODB ネットワークとピアリングされたトランジット仮想プライベートクラウド（VPC）を経由してルーティングされる接続を持つ Transit Gateway を使用しています。 この例では、b.b.b.b/b は az1 の ODB ネットワークのクライアントサブネット CIDR 範囲、a.a.a.a/a は az1 の ODB ネットワークとピアリングされた Transit VPCの CIDR 範囲、y.y.y.y/y は az2 の ODB ネットワークのクライアントサブネット CIDR 範囲、x.x.x.x/x は az2 の ODB ネットワークと ODB ピアリングされた Transit VPC の CIDR 範囲です。 ネットワーク CIDR プライマリ Transit VPC a.a.a.a/a プライマリ ODB ネットワーククライアントサブネット b.b.b.b/b スタンバイ Transit VPC x.x.x.x/x スタンバイ ODB ネットワーククライアントサブネット y.y.y.y/y Oracle Database@AWS のネットワークアーキテクチャと ODB ピアリングの概念について学ぶには、 ODB ピアリング を参照してください。 次の図は、リージョン内の2つの AZ 間で Transit Gateway を使用して Data Guard トラフィックの接続を設定する方法を示しています。 このアーキテクチャを実装するには、次の手順に従う必要があります： ODB ピアリング方法 を使用して、Transit VPC1（CIDR a.a.a.a/a）を ODBNetwork-az1 （クライアント CIDR b.b.b.b/b）とピアリングし、Transit VPC2（CIDR x.x.x.x/x）を ODBNetwork-az2 （クライアント CIDR y.y.y.y/y）とピアリングします。 Transit Gateway をプロビジョニングするか既存の Transit Gateway を使用し、ODB ネットワークがデプロイされている AZ にマッピングされたサブネットに対して、Transit VPC1 と Transit VPC2の両方にアタッチします。Transit VPCへの Transit Gateway アタッチメントは、ODB ネットワークがプロビジョニングされている AZ にマッピングされたサブネットのみをカバーする必要があります。 Transit VPC1 のルートテーブル（Transit Gateway アタッチメント用のサブネットで使用される）を変更して、Transit VPC2 CIDR（x.x.x.x/x）と ODBNetwork-az2 CIDR（y.y.y.y/y）を対象とするトラフィックを Transit Gateway アタッチメント経由でルーティングします。 Transit VPC2 のルートテーブル（Transit Gatewayアタッチメント用のサブネットで使用される）を変更して、Transit VPC1 CIDR（a.a.a.a/a）と ODBNetwork-az1 CIDR（b.b.b.b/b）を対象とするトラフィックを Transit Gateway アタッチメント経由でルーティングします。 これらのサブネットにアタッチされたルートテーブルからのルートは、Transit Gateway のルートテーブルに自動的に入力されます。 Transit Gateway に直接接続されていない両方の AZ の ODB ネットワーククライアント CIDR に対して、Transit Gateway 上に2つの静的ルートを追加します。CIDR b.b.b.b/b とy.y.y.y/y の静的ルートは、Transit VPC の対応する Transit Gateway アタッチメントを指す必要があります。 ODB ピアリング接続を変更して、他の ODB ネットワークとその Transit VPC のピアリング CIDR 範囲を追加します： ODBNetwork-az1 の ODB ピアリング接続を変更して、x.x.x.x/x と y.y.y.y/y をそのピアリング CIDR リストに追加します。 ODBNetwork-az2 の ODB ピアリング接続を変更して、a.a.a.a/a と b.b.b.b/b をそのピアリング CIDR リストに追加します。 ODB ピアリング接続のピアリング CIDR リストを変更することで、対応する OCI VCN のネットワークセキュリティグループが自動的に更新されて必要なトラフィックが許可されます。データベースリスナーポート、SSH（22）、および ICMP での接続を確認するために、ネットワークセキュリティグループルールを確認できます。 接続をテストして、ソリューションが適切に実装されていることを確認します。 グローバル接続を管理するために AWS Cloud WAN を使用している場合は、 Connecting AWS Cloud WAN to Oracle Database@AWS (ODB@AWS) で説明されているように、Data Guard トラフィックに同じものを使用できます。 Data Guard 接続に OCI VCN でローカルピアリングゲートウェイを使用する VM クラスター間の接続を確立する2番目のオプションは、ローカルピアリングゲートウェイを使用して ODB ネットワークに関連付けられた2つの OCI VCN 間でトラフィックをルーティングすることです。 次の図では、 ODBNetwork-az1 はクライアント CIDR b.b.b.b/b を持つ AZ1 の ODB ネットワークの名前であり、 ODBNetwork-az2 はクライアント CIDR y.y.y.y/y を持つ AZ2 の ODB ネットワークの名前です。 OCI VCN をピアリングして接続を実装するには、次の手順に従う必要があります： OCI コンソールから ODB ネットワークに関連付けられた OCI VCN を特定し、クライアントネットワークの CIDR 範囲を記録します。 各 VCN に1つのローカルピアリングゲートウェイを追加します。 2つのローカルピアリングゲートウェイをピアリングします。 ODBNetwork-az1 に対応する OCI VCN のデフォルトルートテーブルを変更して、 ODBNetwork-az2 の CIDR のトラフィックをローカルピアリングゲートウェイ経由でルーティングします。 ODBNetwork-az2 に対応する OCI VCN のデフォルトルートテーブルを変更して、 ODBNetwork-az1 の CIDR のトラフィックをローカルピアリングゲートウェイ経由でルーティングします。 各 OCI VCN のネットワークセキュリティグループ（名前が調整可能なもの）を変更して、他の ODB ネットワーククライアント CIDR からのトラフィックを許可します。 接続をテストして、ソリューションが適切に実装されていることを確認します。 この構成の詳細については、 Oracle Database@AWS でのクロスゾーン Data Guard を使用したディザスタ・リカバリの実装について を参照してください。 クロス AZ Data Guard アソシエーションの接続オプションの比較 次の表は、Transit Gateway と OCI VCN ピアリングを使用して AZ 間で Data Guard トラフィックをルーティングする2つのオプションを比較しています。 機能 Transit Gateway OCI VCN ピアリング トラフィック分離 AWS ネットワーク OCI ネットワーク レイテンシー 1桁台前半のミリ秒 1桁台前半のミリ秒 コスト Transit Gateway と クロス AZ 料金 データ転送料金なし データ常駐とコンプライアンス要件 トラフィックが AWS ネットワーク内に留まる必要がある場合は要件を満たす データは物理的に AWS に保存されているが Data Guard トラフィックが OCI ネットワーク経由でルーティングされるため、データ常駐要件を満たさない トラブルシューティングの責任 AWS OCI ExaDB-D は Data Guard アソシエーションを追加する際、自動フェイルオーバー用の Data Guard Observer を自動的に構成しません。ただし、Observer 構成を手動で構築することができます。アプリケーションとデータベース間の接続が影響を受けた際にフェイルオーバーをトリガーするために、アプリケーションスタックが主に配置されている AWS ネットワーク上に Data Guard Observer インスタンスをホストすることが推奨されます。次の図は、Fast-Start Failover（FSFO）用に3番目の AZ に展開された Observer 構成を持つ、2つの AZ にわたる Data Guard アソシエーションのリファレンスアーキテクチャを示しています。ADB-D の場合、Observer プロセスを手動で構成することなく、クロス AZ 構成の自動フェイルオーバーを有効にできます。 Data Guardアソシエーションを使用したクロスリージョンディザスタリカバリー AZ 間で HA 構成を確立した後、次のステップは DR 保護を実装することです。DR 要件がクロス AZ 構成で提供できる範囲を超える場合は、リージョン間で Data Guard を実装します。クロスリージョン Data Guard 構成で利用可能な接続オプションを検討し、その効果を比較してみましょう。 リージョン間での2つの ODB ネットワークを接続するために Transit Gateway を使用する 次の図に示すように、Transit Gateway 構成を使用して、AWS ネットワーク内の2つのリージョンにある2つの ODB ネットワーク間でトラフィックをルーティングできます。 この構成の高レベルの手順には以下が含まれます： 各リージョンに1つずつ、2つの Transit Gatway をプロビジョニングします。既存の Transit Gateway を使用することもできます。 各リージョンの ODB ピアリングVPCに、ODB ネットワークが存在する AZ にマッピングされたサブネットへ Trasnit Gateway をアタッチします。 AWS Transit Gateway の Transit Gateway ピアリングアタッチメント で説明されているように、ピアリングアタッチメントを作成し、ピアリングリクエストを受け入れて、Transit Gateway 間の接続を確立します。 クロス AZ トラフィック用の Transit Gatway 構成について前述した手順に従って、ルーティングルールを更新します。 ODB ネットワーク構成を変更して、リモート ODB ネットワークからのトラフィックを許可するように ODB ネットワークのピアリング CIDR リストを更新します。 接続をテストして、ソリューションが適切に実装されていることを確認します。 グローバル接続を管理するために Cloud WAN を使用している場合は、 Connecting AWS Cloud WAN to Oracle Database@AWS (ODB@AWS) で説明されているように、Data Guard トラフィックに同じ手順を使用できます。 OCI VCN とのリモート VCN ピアリングを使用する クロスリージョンの Data Guard 構成のための接続を確立するためにバックエンドの OCI VCN をピアリングする2番目のオプションでは、各側に追加の HUB VCN を構成する必要があります。これは、OCI VCN は1つの DRG にのみアタッチできるためであり、ODB ネットワークにマッピングされた VCN はすでに AWS-OCI ネットワーク統合のために DRG にアタッチされているためです。そのため、HUB VCN を導入し、ODB ネットワークの OCI VCN と HUB VCN 間でローカルピアリングゲートウェイ接続を確立します。その後、次の図に示すようにクロスリージョン接続のために DRG にアタッチできます。 詳細な構成手順については、 Oracle Database@AWS 上のリージョン間 Active Data Guard によるディザスタ・リカバリの実装 を参照してください。 クロスリージョン Data Guard アソシエーションの接続オプションの比較 次の表は、Transit Gateway と OCI VCN ピアリングを使用してリージョン間でData Guardトラフィックを行う接続オプションを比較しています。 機能 Transit Gateway OCI VCN ピアリング トラフィック分離 AWS ネットワーク OCI ネットワーク レイテンシー ミリ秒 ミリ秒 コスト Transit Gateway 料金 と クロスリージョンデータ転送料金 クロスリージョンデータ転送料金 データ常駐とコンプライアンス要件 トラフィックが AWS ネットワーク内に留まる必要がある場合は要件を満たす データは物理的に AWS に保存されているが Data Guard トラフィックが OCI ネットワーク経由でルーティングされるため、データ常駐要件を満たさない トラブルシューティングの責任 AWS OCI ExaDB-D と ADB-D の Data Guard アソシエーションの構成 ExaDB-D と ADB-D は両方とも、バックアップ、リストア、および Data Guard 構成の手順を手動で実行することなく、コンソールまたは API と CLI を使用して Data Guard アソシエーションを設定するためのマネージド体験を提供します。ExaDB-D の場合は、次の手順を実行します： OCI コンソールを使用して OCI テナンシーにログインします。 Oracle AI Database セクションで Oracle Exadata Database Service on Dedicated Infrastructure を選択します。 プライマリデータベース用の VMC を選択します。 プライマリデータベースを選択します。 Data Guard associations を選択します。 スタンバイインスタンスに適切なターゲット AD、インフラストラクチャ、および VMC を選択して、スタンバイ追加オプションを使用して構成します。 構築完了後にスイッチオーバーをテストします。 ADB-D の場合は、次の手順を実行します： OCI コンソールを使用して OCI テナンシーにログインします。 Oracle AI Database セクションで Autonomous Database on Dedicated Infrastructure を選択します。 Autonomous Container Database（ACD）を選択します。 Data guard associations を選択します。 スタンバイに適切なターゲット AD、インフラストラクチャ、および AVMC を選択して、スタンバイ追加オプションを使用して構成します。 構築完了後にスイッチオーバーをテストします。 クロス AZ Data Guard フェイルオーバーとスイッチオーバーのアプリケーション接続 データベースへのアプリケーション接続は、ADB-D と ExaDB-D の両方で Data Guard のスイッチオーバーとフェイルオーバーのシナリオを計画する際に慎重な検討が必要です。このセクションでは、適切な TNS 構成を使用することで、アプリケーションが再構成なしにロール移行シナリオ全体でデータベースへの接続を透過的に確立できるようにする、アプリケーションスタックからデータベースへの接続のための Well-Architected で推奨されるモデルについて説明します。 ほとんどの場合、顧客は高可用性のために異なる AZ にマッピングされたサブネットにまたがる VPC 内にアプリケーションスタックをデプロイします。VPC はプライマリ AZ とスタンバイ AZ の ODB ネットワークと同時にピアリングできるため、その VPC で実行されているアプリケーションは、次の図に示すように Data Guard のスイッチオーバーとフェイルオーバーのシナリオ全体でデータベースへの透過的な接続を促進できます。 Transit Gateway を介して ODB ネットワーク内のデータベースにアプリケーションが接続されている場合、プライマリおよびスタンバイ AZ の ODB ネットワークとピアリングされた Transit VPC を Transit Gatway にアタッチすることで、スイッチオーバーとフェイルオーバーのシナリオ全体で透過的な接続を確立できます。次の図に示すように、アプリケーションは Transit Gateway を介して ODB ネットワークに接続し、ODB ピアリング VPC は単にトランジットパスとして機能します。 このアーキテクチャでは、Transit VPC はアプリケーションコンポーネントをホストせず、アプリケーションは Transit Gateway を使用してデータベース層に接続します。 まとめ この投稿では、Oracle Database@AWS で実行されている重要なデータベースの HA と DR 要件を満たすために Data Guard を使用する方法を示しました。また、Data Guard トラフィックをルーティングするための接続オプションについて説明し、データベースへのアプリケーション接続のベストプラクティスを共有しました。Oracle RAC (Real Application Clusters) が提供するサーバーラックレベルのレジリエンシー、Data Guard マルチ AZ レプリケーション、クロスリージョンディザスタリカバリなど、複数の保護層を慎重に実装することで、Oracle Database@AWS にデプロイされたデータベースに対して望ましい保護レベルと可用性を実現できます。現在の可用性要件を評価し、適切な Data Guard 構成を選択し、ビジネスニーズに最適なネットワークアーキテクチャを実装することで、包括的なデータベースレジリエンシーへの取り組みを今日から始めましょう。この投稿の詳細な構成手順とアーキテクチャパターンは、アプリケーションのビジネス継続性を提供する堅牢な Oracle Database@AWS 環境の構築と維持に役立ちます。 Oracle Database@AWS の機能と構成について詳しく学ぶには、 Oracle Database@AWS ユーザーガイド を参照してください。 著者について Jobin Joseph Jobin は、トロントを拠点とするシニアデータベーススペシャリストソリューションアーキテクトです。リレーショナルデータベースエンジンに焦点を当て、顧客のデータベースワークロードの AWS への移行とモダナイズを支援しています。25年以上の Oracle Database 経験を持つ Oracle 認定マスターです。 Julien Silverston Julien は、25年の経験を持つ Oracle Cloud Infrastructure マルチクラウドチームのプリンシパルソリューションアーキテクトです。Julien は、マルチクラウド、ハイブリッドクラウド、およびクラウドベースのソリューションに精通しています。Oracle Cloud Infrastructure 認定ソリューションアーキテクトです。 Jeremy Shearer Jeremy は、ヒューストンを拠点とし、Oracle Alliance に専念する AWS のプリンシパルパートナーソリューションアーキテクトです。約30年の Oracle 経験を持ち、特に JD Edwards などの Oracle エンタープライズ ERP システムのインストール、構成、管理、および移行を専門としています。 翻訳はソリューションアーキテクトの 永末 健太 が担当しました。原文は こちら です。

本日、AWS Console for SAP Applications の提供開始を発表します。これは、AWS 上で稼働する SAP HANA ベースのアプリケーションを登録・管理するための、アプリケーション中心のビューを SAP のお客様に提供する新しい一元管理エクスペリエンスです。このコンソールは、登録済みの SAP アプリケーションの表示、ランディングゾーンのセットアップ状況の把握、SAP ワークロードが使用するリソースの可視化を行うための統合ダッシュボードを提供します。アプリケーション詳細ページでは、アプリケーショントポロジーや関連リソースの表示に加え、アプリケーションを考慮した起動/停止、SAP ワークロード構成の自動検証、スケジュールされたオペレーションなどの管理操作を実行できます。 また、このコンソールでは、ドキュメント、SAP 固有の AWS サービス、および AWS Well-Architected Framework の SAP Lens に基づくベストプラクティスへの便利なアクセスも提供します。 コンソールの概要 SAP アプリケーションは、財務からサプライチェーンまでのコアビジネスプロセスを管理するために不可欠であり、AWS はこれらのアプリケーションを実行するための堅牢な基盤を提供しています。以前は、AWS 上の SAP ワークロードを管理するために、SAP 管理者はプログラムによる API 呼び出しを使用するか、幅広いエンタープライズアプリケーションに対応する汎用的な AWS マネジメントコンソールを操作する必要がありました。これらのオプションは必要な機能をすべて提供していましたが、SAP ランドスケープの統合ビューの取得など、SAP 環境固有のワークフローや運用パターンに最適化されたユーザーエクスペリエンスではありませんでした。 AWS Console for SAP Applications は、SAP 専用に構築されたネイティブな管理エクスペリエンスを提供することで、この課題に対応します。SAP ランドスケープの直感的なダッシュボードビュー、SAP チームが日常的にシステムを捉える視点に沿ったアプリケーションを考慮したナビゲーション、そして API 構文を覚えたり複数のコンソールを行き来したりすることなく、一般的な SAP 管理操作を実行するための効率的なインターフェースを提供します。 主要機能 AWS Console for SAP Applications は、3つの主要な領域で構成されています：AWS の SAP 機能へのエントリーポイントとなるランディングページ、SAP 環境のランドスケープ概要を提供する一元化されたダッシュボード、そして個々の SAP アプリケーションを管理するアプリケーション詳細ページです。それぞれについて見ていきましょう。 ランディングページ ランディングページは、AWS Console for SAP Applications へのエントリーポイントとして機能し、SAP アプリケーションを登録するためのクイックパスと、AWS 上で SAP ワークロードを実行するためのすべての専用 AWS サービスおよび一般的なユースケースの一元的なビューを提供します。 一元化されたダッシュボード AWS Console for SAP Applications のダッシュボードは、すべての SAP アプリケーションとリソースのランドスケープ概要を一目で提供します。ダッシュボードからは、以下の情報をすぐに確認できます： 登録/検出ステータス： リージョン内の AWS Systems Manager for SAP に登録されたすべてのアプリケーションの視覚的なサマリー。登録状態（Success、Registering、Registration failed、Refresh failed、Deleting）を含みます。 実行中のアプリケーション： SAP アプリケーション群のリアルタイムビュー。SAP ABAP および SAP HANA アプリケーションの実行中、停止中、ロード中、失敗、不明の各状態の数を表示します。 アプリケーションの登録または新規起動： 既存の SAP アプリケーションの登録、または AWS Launch Wizard for SAP を使用した新規アプリケーションの起動へのクイックアクセスエントリーポイントです。 SAP アプリケーションの概要とトポロジー： SAP アプリケーションの概要は、ダッシュボードのもう一つの強力な機能です。SAP アプリケーションとその関連リソース間の関係を、直感的なトポロジービューで可視化します。このトポロジービューにより、SAP 管理者はアプリケーションを支えるリソースのフルスタックを素早く把握できます。 アベイラビリティーゾーン別の AWS リソース： ダッシュボードは、アベイラビリティーゾーン全体にわたる SAP アプリケーション用の Amazon リソースの詳細な内訳を提供します。 オペレーションサマリー： ダッシュボードでは、登録済みアプリケーションに対して実行された最近のオペレーションを一覧表示するオペレーションサマリーも提供します。 アプリケーション管理 Applications ページには、登録済みのすべての SAP アプリケーションが主要な詳細情報とともに一覧表示され、SAP 管理者は SAP ランドスケープの概要を素早く把握できます。 個々のアプリケーションを選択すると、アプリケーション詳細ページが開き、SAP アプリケーションに関する包括的な情報が直感的なタブ（SAP Topology、Resources、AWS Backup、Tags、SAP Configuration Checks、Operations、Cost）で整理されて表示されます。これらのタブを合わせることで、アプリケーションのコンポーネント、基盤となるインフラストラクチャ、データ保護の状態、構成の状況、運用履歴、コストの全体像を一か所で把握できます。 Actions メニューから、管理者はコンソールから直接、主要な管理操作を実行できます： オンデマンド検出の実行： AWS Console for SAP Applications は、登録後に1時間ごとにアプリケーションメタデータを自動的に更新します。ただし、ノードの追加や削除などアプリケーションに変更を加えた場合は、このアクションを使用して、次のスケジュールされた更新を待たずに最新のアプリケーション情報を即座に取得できます。 アプリケーションの起動/停止： SAP アプリケーションコンポーネントを正しい順序で安全に処理する、アプリケーションを考慮した起動および停止操作です。 認証情報の更新： モニタリングに使用される SAP アプリケーションの認証情報を更新します。 アプリケーションの登録解除： AWS Systems Manager (SSM) for SAP の管理からアプリケーションを削除します。 SAP オペレーションのスケジュール： Amazon EventBridge を使用して定期的な運用タスクを設定し、SAP アプリケーションのスケジュールされた起動/停止などの日常的な操作を自動化できます。 開始方法 AWS Console for SAP Applications を使い始めるための簡単な手順は以下のとおりです： コンソールに移動する： AWS マネジメントコンソールを開き、「AWS for SAP」を検索します。 SAP アプリケーションを登録する： 「Register application」をクリックして、既存の SAP HANA/ABAP アプリケーションを AWS Systems Manager for SAP に登録します。AWS Systems Manager for SAP API を使用してプログラムでアプリケーションを登録することもできます。 ダッシュボードを確認する： 登録が完了すると、アプリケーションが登録および検出ステータスとともにダッシュボードに表示されます。ダッシュボードは、AWS 上の SAP ランドスケープ全体を一目で把握できるビューを提供します。 アプリケーションを管理する： 登録済みのアプリケーションを選択して、トポロジー、リソース、バックアップステータス、構成チェック、オペレーション、コストを表示します。Actions メニューを使用して、起動、停止、オンデマンド検出などのアプリケーションを考慮した操作を実行します。 構成チェックを実行する： SAP Configuration Checks タブに移動し、チェックを実行して、AWS Well-Architected Framework の SAP Lens に対して SAP ワークロードを検証します。 バックアップログを表示する： AWS Backup タブを使用して、SAP HANA データベースのバックアップとリカバリポイントを監視します。 お客様は、AWS Systems Manager for SAP API を使用して、プログラムでアプリケーションの登録やすべての管理操作を実行することもでき、既存の自動化ワークフローや CI/CD パイプラインとの統合が可能です。 利用可能なリージョンと料金 AWS Console for SAP Applications は、AWS Systems Manager for SAP がサポートされているすべての AWS リージョンで利用可能です。コンソール自体の使用に追加料金はかかりません。 まとめ AWS Console for SAP Applications は、SAP 専用に構築されたネイティブな管理エクスペリエンスであり、ランドスケープの可視化、アプリケーション管理、バックアップ監視、構成検証、運用自動化を一か所に統合します。このコンソールにより、SAP 管理者は断片化されたツールから脱却し、SAP HANA ベースのアプリケーションをインフラストラクチャとしてではなく、アプリケーションとして管理できるようになります。 今すぐ AWS Console for SAP Applications で SAP アプリケーションを登録して始めましょう。詳細なガイダンスについては、 AWS Systems Manager for SAP のドキュメント および API リファレンスガイド をご覧ください。 本ブログはAmazon Bedrockを用いた翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

イベント概要 自動車・製造業を中心にCAEワークロードを実行されているお客様向けに、本年2月（東京リージョンは3月）に一般提供開始した Hpc8aインスタンス をはじめとしたAWSの最新ソリューション、並びにその基盤となるアーキテクチャを提供するAMD様、業界内で強力なリーダーシップを有するSIパートナー様や主要なアプリケーションベンダーの皆様から最新情報をお届けする集中イベントを、4月20日週に東京・大阪・名古屋 3か所のロードショーの形で実施いたします。AWSでグローバルにCAEワークロード責任者を務める Sandeep Sovani も来場します。是非お近くの会場にてご参加ください。 開催日程 東京: 　　4月20日(月) @AWS目黒オフィス　13:15 ～ 17:15 （受付: 12:45～） 大阪: 　　4月22日(水) @AWS大阪オフィス　13:15 ～ 17:15 （受付: 12:45～） 名古屋: 　4月23日(木) @ウインクあいち　13:15 ～ 17:15 （受付: 12:45～） （※セミナー終了後、ネットワーキングセッションを実施いたします。こちらも奮ってご参加ください。） イベントプログラム 時間 内容（※一部リモート・録画投影にて実施予定） 13:15 – 13:30 オープニング 13:30 – 14:00 AWSセッション 14:00 – 14:30 AMD様セッション 14:30 – 15:00 CAE SIer様セッション 15:00 – 17:00 CAEアプリケーションベンダー様セッション（調整中） 17:00 – 17:15 Q&A / クロージング 17:15 – 19:00 ネットワーキングセッション（※ご参加可能な方） 軽食・飲み物をご用意しております ※当日迄にセッション時間内訳等変更となる可能性がございます。 ※一部のセッションは英語での提供となりますが、通訳を手配する予定です。 セミナー参加情報 開催形式 : 　会場参加型セミナー（オンライン配信はありません） 東京会場(4/20)            〒 141-0021東京都品川区上大崎3-1-1 目黒セントラルスクエア21階　AWS目黒オフィス内セミナールーム 大阪会場(4/22)            〒 530-0005 大阪市北区中之島 3-3-3 中之島三井ビルディング26F　AWS大阪オフィス内セミナールーム 名古屋会場（4/23)      〒 450-0002 愛知県名古屋市中村区名駅4丁目4-38 ウインクあいち 1307会議室 参加費用 無料 参加対象者 CAEワークロードを持つ自動車・製造業等のお客様、エンジニア、事業部門、意思決定者の方まで多くの方にご参加いただけます。 定員 各回30名 ※定員に達した場合は申込を締め切らせていただきます。 お問い合わせ アマゾンウェブサービスジャパン セミナー事務局 Email : aws-jp-hpc@amazon.com お申込サイト https://bit.ly/4uzniiM ※開催日が近くなりましたらお申込みいただいた方のご連絡先に 入館証他詳細をご連絡させていただきます。

本ブログは 2026 年 3 月 17 日に公開された AWS Blog、” Essential security controls to prevent unauthorized account removal in AWS Organizations ” を翻訳したものです。 AWS メンバーアカウントが侵害された場合、攻撃者はアカウントを組織から離脱させ、すべてのガバナンスコントロールを無効化する可能性があります。本記事では、サービスコントロールポリシー (SCP)、安全なアカウント移行、一元化されたルートアクセス管理などの多層的なセキュリティコントロールを使用して、AWS 環境をアカウント侵害から保護する方法を解説します。 AWS はクラウドを実行するインフラストラクチャのセキュリティを担い、お客様はクラウド内のワークロードとデータのセキュリティを担います。そのために、AWS Organizations には不正なアカウント離脱を防止し、アカウント全体のガバナンスを維持するセキュリティコントロールが含まれています。 本記事では、4 つのコントロールについて説明します。サービスコントロールポリシー (SCP) による不正なアカウント離脱の防止、正当な移行のためのブレークグラス手順の確立、組織間でのアカウントの直接移行、およびメンバーアカウントのルートアクセスの無効化です。 前提条件 本記事では、 AWS Organizations と マルチアカウント戦略の概念 に精通している必要があります。以下の権限を持つ AWS Organizations 管理アカウントへのアクセスが必要です。 サービスコントロールポリシーの作成とアタッチ — organizations:CreatePolicy 、 organizations:AttachPolicy 組織単位の管理 — organizations:CreateOrganizationalUnit 、 organizations:MoveAccount 一元化されたルートアクセス管理の有効化 — iam:EnableOrganizationsRootCredentialsManagement セキュリティと柔軟性を両立する組織単位 (OU) 構造の設計 マネージドサービスプロバイダー、リセラー、アカウントの入れ替わりが多い組織など、メンバーアカウントが定期的に組織を離脱することを許可する必要があるビジネスモデルの場合、最初からこのワークフローを考慮して OU 構造を設計する必要があります。 アカウントのライフサイクルステージ (オンボーディング、アクティブ、オフボーディング) ごとに専用の OU を作成し、長期的なガバナンス下に置くべきアカウントを含む OU にのみ DenyLeaveOrganization SCP を適用することを検討してください。このアプローチにより、コアインフラストラクチャを保護しつつ、短期間のアカウントの移行を簡素化できます。 セキュリティコントロールと運用の柔軟性のバランスを取る 階層的な OU 構造を作成 してください。本番環境と開発環境の OU に DenyLeaveOrganization SCP を適用して重要なワークロードを保護し、制御されたアカウント移行のためにこの制限のない別の移行用 OU を維持します。 推奨される OU アーキテクチャ 本番 OU: DenyLeaveOrganization SCP を適用して、本番ワークロードを実行するアカウントが組織を離脱することを防止します 開発 OU: 同じ SCP を適用して、開発およびテスト環境のガバナンスを維持します 移行 OU: DenyLeaveOrganization SCP を適用せず、組織を離脱する準備をしているアカウントの制御されたステージングエリアとして機能させます 正当なビジネス上の理由でアカウントが組織を離脱する必要がある場合、管理アカウントはそのアカウントを移行 OU に移動でき、メンバーアカウントの離脱操作が可能になります。これにより、明確な承認ワークフローが作成され、移行プロセス全体の可視性が維持されます。 管理アカウントは組織からメンバーアカウントを離脱させることができるため、メンバーアカウントが自ら離脱する正当な必要性がない場合は、離脱アカウント用の移行 OU アプローチを実装する必要はありません。 OU 構造の整理と管理に関する詳細なガイダンスについては、 AWS Organizations での組織単位の管理に関する AWS ベストプラクティス を参照してください。 組織離脱アクションを拒否するサービスコントロールポリシーの実装 メンバーアカウントが組織を離脱することを防止するには、メンバーアカウントに対して organizations:LeaveOrganization アクションを拒否する SCP を実装します。この予防的コントロールにより、アカウントがガバナンスフレームワーク内に留まり、セキュリティコントロールと組織ポリシーが維持されます。 AWS マネジメントコンソールを使用した SCP の作成 管理アカウントで AWS Organizations コンソールにサインインします。 ナビゲーションペインで ポリシー を選択します。 サービスコントロールポリシーを有効化 します。 ポリシーの作成 を選択します。 ポリシー名を入力します (例: “DenyLeaveOrganization” )。 ポリシーエディタに以下の JSON を入力します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "organizations:LeaveOrganization", "Resource": "*" } ] } ポリシーの作成 をクリックします。 AWS CLI を使用した SCP の作成 以下のコマンドを実行してポリシーを作成します。 aws organizations create-policy \ --name DenyLeaveOrganization \ --type SERVICE_CONTROL_POLICY \ --description "Prevents member accounts from leaving the organization" \ --content '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"organizations:LeaveOrganization","Resource":"*"}]}' 次のステップで使用するため、出力からポリシー ID を記録してください。 ポリシーを作成したら、 移行 OU を制限なしのまま維持しつつ、 本番 OU と 開発 OU に DenyLeaveOrganization SCP を適用します。 AWS マネジメントコンソールを使用した OU への SCP のアタッチ AWS Organizations に移動します。 対象の OU ( 本番 または 開発 ) を選択します。 ポリシー タブを選択します。 アタッチ を選択し、「DenyLeaveOrganization」ポリシーを選択します。 ポリシーが必要な各 OU に対して繰り返します。 AWS CLI を使用した OU への SCP のアタッチ 作成ステップで取得したポリシー ID を使用して、対象の OU にポリシーをアタッチします。 aws organizations attach-policy --policy-id p-xxxxxxxx --target-id r-xxxx ポリシーのアタッチを確認します。 aws organizations list-targets-for-policy --policy-id p-xxxxxxxx ポリシーが必要な各 OU に対して繰り返します。 このコントロールは、コンソール、CLI、SDK を通じた API レベルでの離脱の試みをブロックします。管理アカウントの保護に関するベストプラクティスについては、 ドキュメント を参照してください。 SCP は管理アカウントには適用されず、組織内のメンバーアカウントにのみ影響することに注意してください。そのため、管理アカウントを MFA、アクセス制限、一時的な認証情報のみの使用、包括的なモニタリングなど、可能な限り強力なセキュリティコントロールで保護することが不可欠です。 ブレークグラス手順の文書化 アカウントの移行、合併、買収、事業売却の際に特定のアカウントが組織を離脱することを許可する必要がある場合は、文書化された承認ワークフローと技術的メカニズムを備えた正式なプロセスを確立してください。 シナリオに適したブレークグラスメカニズムを選択してください。アカウントが組織を離脱する必要がある場合、標準的な変更管理プロセスを通じて、現在の OU から移行 OU に移動します。移行 OU に移動すると、DenyLeaveOrganization SCP の制限なしに離脱操作を実行できます。このアプローチにより、組織ルート全体から SCP を一時的に削除することなく、すべてのアクティブなアカウントのセキュリティコントロールが維持されます。 メンバーアカウント離脱の文書化された例外プロセスの確立 安全な招待ベースの移行プロセスの外で、メンバーアカウントが独自に組織を離脱する場合は、正式な承認を必要とする例外として扱う必要があります。各例外リクエストには、標準的な組織間移行プロセスを使用できない理由を説明する明確なビジネス上の正当性と、セキュリティおよびガバナンスポリシー要件との整合性を検証するためのセキュリティおよび IT 管理チームによるレビューと承認が含まれている必要があります。 この例外をセキュリティベースラインに文書化し、移行 OU は標準的な招待ベースの移行を使用できない承認済みの移行中の一時的なアカウントステージングのためにのみ存在することを明示的に記載してください。この文書化により、説明責任が確立され、コンプライアンスレビューのための監査証跡が作成され、セキュリティコントロールの例外が意図的で、正当化され、期限付きであることが保証されます。 合併・買収時のアカウントの安全な移行 合併、買収、または組織統合の際、AWS Organizations は組織間の安全な直接アカウント移行をサポートし、アカウントがスタンドアロンになることを防止します。移行先の組織の管理アカウントが移行するアカウントに招待を送信します。承認されると、アカウントは組織のガバナンスの外で運用されることなく、移行元から移行先の組織にシームレスに移行します。サービスコントロールポリシー (SCP)、ログ記録、モニタリングは移行中も継続的に適用され、セキュリティ体制が維持され、 AWS CloudTrail を通じた完全な監査証跡が作成されます。 この招待ベースのアプローチは、アカウントが独立して運用される際に発生するセキュリティギャップを防止しながら、ほとんどの正当な移行ユースケースに対応します。管理アカウントがメンバーアカウントを手動で離脱させる必要はなく、招待プロセスが移行を自動的に処理します。移行後は、適切なポリシーが適用されていることを確認し、正しい組織 ID で IAM ポリシーを更新し、請求設定、税金設定、リザーブドインスタンスの移行を確認してください。詳細なガイダンスについては、 AWS Organizations ユーザーガイドのアカウント移行 を参照してください。 メンバーアカウントのルートアクセスの脆弱性の排除 メンバーアカウントのルートユーザー認証情報は、AWS 環境における最高レベルの特権アクセスであり、AWS Identity and Access Management (IAM) ポリシーやサービスコントロールポリシーをバイパスできます。2025 年の AWS 一元化されたルートアクセス管理の開始以降、新しく作成されたメンバーアカウントにはデフォルトでルートユーザー認証情報がなくなりました。これは、組織内のすべての新しいアカウントの標準的な動作です。新しく作成されたメンバーアカウントはルートユーザー認証情報なしで自動的にプロビジョニングされるため、多要素認証の設定などのプロビジョニング後のセキュリティ対策が不要になります。 このデフォルトが有効になる前に作成された既存のアカウントについては、長期間有効なルートユーザー認証情報の削除は迅速かつ簡単です。AWS 一元化されたルートアクセス管理を使用すると、パスワード、アクセスキー、署名証明書、MFA デバイスなどのルートユーザー認証情報を、管理アカウントから組織全体にわたって直接削除できます。各メンバーアカウントに個別にサインインする必要はありません。 この一元化されたアプローチにより、メンバーアカウント全体で一貫したセキュリティが維持されます。また、アカウント作成とセキュリティ設定の間の脆弱性ギャップを排除することで、運用オーバーヘッドが削減されます。一元化されたルートアクセス管理の実装に関する詳細なガイダンスについては、 メンバーアカウントのルートアクセスの一元管理 を参照してください。 AWS マネジメントコンソールを使用したルートユーザー認証情報の削除 管理アカウントを使用して IAM コンソールを開きます。 ナビゲーションペインの アクセス管理 で、 ルートアクセス管理 を選択します。 一元化されたルートアクセス管理がまだ有効になっていない場合、ページの上部にバナーまたはプロンプトが表示されます。 有効化 を選択してアクティブにします。プロンプトが表示されない場合、この機能は組織で既に有効になっています。有効化すると、ページにメンバーアカウントを含む組織構造が表示されます。 アカウントを選択し、右側のルートユーザー認証情報パネルを確認します。アクティブなルートユーザー認証情報がまだあるアカウントについては、 ルートユーザー認証情報の削除 を選択して削除します。 図 1: ルートアクセス管理 AWS CLI を使用した一元化されたルートアクセス管理の有効化 以下のコマンドを実行して、一元化されたルートアクセス管理を有効化します (既に有効な場合でも安全に実行でき、現在の機能の状態が返されます)。 aws iam enable-organizations-root-credentials-management 有効化された機能を確認して設定を検証します。 aws iam list-organizations-features 出力を確認して、有効化が成功したことを確認します。機能が有効化されている場合、以下のように表示されます。 { "OrganizationId": "o-xxxxxxxxxxxx", "EnabledFeatures": [ "RootSessions", "RootCredentialsManagement" ] } 機能がまだ有効化されていない場合、 aws iam list-organizations-features は以下のように空の EnabledFeatures 配列を返します。 { "OrganizationId": "o-xxxxxxxxxxxx", "EnabledFeatures": [] } まとめ AWS Organizations をアカウント侵害から保護するには、保護と運用の柔軟性のバランスを取る多層的なセキュリティコントロールが必要です。DenyLeaveOrganization サービスコントロールポリシーは、不正なアカウント離脱をブロックし、継続的なガバナンスの監視を維持します。組織間の招待ベースのアカウント移行機能は、セキュリティギャップを作ることなく、合併、買収、統合などの正当なビジネスニーズをサポートします。AWS 一元化されたルートアクセス管理によるルートアクセスの排除は、セキュリティコントロールをバイパスできる最高特権の経路を削除します。 これらのコントロールにより、侵害された認証情報を使ったアカウントの組織からの離脱を防止し、移行中もサービスコントロールポリシーとログ記録をアクティブに保ち、セキュリティインシデントをガバナンスフレームワーク内に封じ込めることで、問題の検出、対応、修復をより迅速に行えるようになります。 まず OU 構造を設計し、ブレークグラス手順を文書化してから、DenyLeaveOrganization SCP を適用し、AWS 一元化されたルートアクセス管理を有効化してください。OU 構造を定期的にレビューし、例外リクエストを監査し、AWS CloudTrail を通じて不正アクセスの試みを監視してください。アカウントガバナンスを重要なセキュリティコントロールとして扱い、AWS 環境を安全でコンプライアンスに準拠し、ビジネス目標に沿った状態に保ちましょう。サービスコントロールポリシーの例とテンプレートについては、 AWS SCP Examples GitHub リポジトリ をご覧ください。 著者について Nivedita Tripathi Nivedita Tripathi は AWS Organizations のシニアプロダクトマネージャーです。セキュリティとガバナンスのベストプラクティスを活用し、組織が設定したコンプライアンス境界内で、お客様が複数のアカウントにわたるクラウドインフラストラクチャを構築・拡張できるよう支援することに注力しています。テクノロジーへの情熱に加え、音楽、世界旅行、家族との時間を楽しんでいます。 Ryan Bates Ryan は AWS のテクニカルアカウントマネージャーです。学ぶことと、学んだことで人々を助けることが大好きです。IT 業界で 20 年以上の経験があり、エンドユーザーサポート、インフラストラクチャサポート、IT 部門の構築を担当してきました。お客様のことに没頭していない時は、家族との時間、ワインテイスティング、ディズニーランドへの訪問を楽しんでいます。 Samir Behara Samir Behara は AWS プロフェッショナルサービスのシニアクラウドインフラストラクチャアーキテクトです。クラウド導入戦略を通じて、お客様の IT モダナイゼーションの加速を支援することに情熱を注いでいます。豊富なソフトウェアエンジニアリングのバックグラウンドを持ち、パフォーマンス、運用効率、イノベーションのスピード向上を推進するために、アプリケーションアーキテクチャと開発プロセスを深く掘り下げることを好みます。 翻訳は Security Solutions Architect の 松崎 博昭 が担当しました。

本ブログは 2026 年 3 月 18 日に公開された AWS Blog “ Amazon threat intelligence teams identify Interlock ransomware campaign targeting enterprise firewalls ” を翻訳したものです。 Amazon Threat Intelligence は、Cisco Secure Firewall Management Center (FMC) Software の重大な脆弱性 CVE-2026-20131 を悪用する Interlock ランサムウェアのアクティブなキャンペーンを確認しました。この脆弱性は、認証を必要とせずにリモートの攻撃者が対象デバイス上で root 権限により任意の Java コードを実行できるというもので、2026 年 3 月 4 日に Cisco が公開しました。 Cisco による 脆弱性の公開 を受け、Amazon Threat Intelligence は Amazon MadPot のグローバルセンサーネットワークを使用して、この脆弱性の調査を開始しました。Amazon MadPot は、サイバー犯罪者のアクティビティをおびき寄せて監視するハニーポットサーバーのシステムです。過去から現在にかけてのエクスプロイトを調査した結果、Interlock が脆弱性公開の 36 日前にあたる 2026 年 1 月 26 日から悪用を開始していたことが判明しました。これは単なる脆弱性の悪用ではありませんでした。Interlock はゼロデイを手にしており、防御側がこの脆弱性の存在を認識するよりも前に、組織を侵害するための数週間の猶予を得ていたのです。この発見を受けて、AWS は Cisco の調査を支援するとともにお客様を保護するため、調査結果を Cisco と共有しました。 設定に誤りのあったインフラストラクチャサーバー、つまり攻撃者が使用していたセキュリティが不十分なステージング領域から、Interlock の攻撃ツールキットの全容が明らかになりました。このまれな設定ミスにより、Amazon のセキュリティチームは、ランサムウェアグループの多段階攻撃チェーン、カスタムのリモートアクセス型トロイの木馬 (RAT、攻撃者が侵害したシステムをリモート制御するためのバックドアプログラム)、偵察スクリプト (被害者のネットワークをマッピングする自動化ツール)、および回避テクニックの全容を把握することができました。 今回のキャンペーンにおいて、AWS インフラストラクチャや AWS 上のお客様のワークロードが影響を受けた事実は確認されていません。本アドバイザリでは、潜在的な侵害の特定と Interlock の活動からの防御に役立てていただけるよう、包括的な技術分析と侵害インジケータ (IoC) を共有します。Cisco Secure Firewall Management Center を使用している組織は、Cisco のセキュリティパッチを直ちに適用し、以下に示す IoC を確認してください。 発見と調査のタイムライン Amazon Threat Intelligence は、CVE-2026-20131 に関連する可能性のある脅威アクティビティが、脆弱性の公開に先立つ 2026 年 1 月 26 日から発生していたことを特定しました。確認されたアクティビティには、影響を受けるソフトウェアの特定のパスに対する HTTP リクエストが含まれていました。リクエスト本文には、Java コードの実行を試みるコードと 2 つの埋め込み URL が含まれていました。1 つはエクスプロイトに必要な設定データの配信用で、もう 1 つは脆弱なターゲットから HTTP PUT リクエストで生成ファイルをアップロードさせ、悪用の成功を確認するためのものでした。複数のエクスプロイト試行を通じて、これらの URL にさまざまなバリエーションが確認されました。 調査をさらに進め、脅威インテリジェンスを得るため、AWS は想定されるファイル内容を含む HTTP PUT リクエストを送信し、侵害に成功したシステムを装いました。これにより Interlock は攻撃の次のステージに進み、リモートサーバーから悪意のある ELF バイナリ (Linux 実行ファイル) をダウンロードして実行するコマンドを送信してきました。 アナリストがこのバイナリを取得したところ、同一のホスト (攻撃者が制御するサーバー) が Interlock の攻撃ツールキット全体の配布にも使用されていることが判明しました。この外部に露出していたインフラストラクチャでは、アーティファクトが標的ごとに個別のパスで整理されており、侵害したホストへのツールのダウンロードとステージングサーバーへのアーティファクトのアップロードの両方に同じパスが使用されていました。 Interlock ランサムウェアへのアトリビューション ELF バイナリと関連アーティファクトは、技術的および運用面の指標の一致から、Interlock ランサムウェアファミリーによるものと判断されます。埋め込まれたランサムノートと TOR 上の身代金交渉ポータルは、Interlock が従来使用してきた特徴的な手口やインフラストラクチャと合致しています。ランサムノートで複数のデータ保護規制に言及していることは、規制上のリスクを指摘して被害者に圧力をかけるという Interlock の既知の手法を反映しています。データの暗号化だけでなく、規制上の罰金やコンプライアンス違反をも利用して組織を脅迫する手口です。ランサムノートに埋め込まれたキャンペーン固有の組織識別子も、Interlock が被害者ごとに追跡を行うモデルと一致しています。 Interlock はこれまで、業務の中断が身代金支払いへの大きな圧力となる特定のセクターを標的としてきました。標的として最も多いのは教育セクターで、次いでエンジニアリング・建築・建設企業、製造・産業組織、医療機関、政府・公共セクターの順となっています。 観測された脅威アクティビティのタイムスタンプ、設定に誤りのあったインフラストラクチャサーバー上のアーティファクト、および取得した脅威アーティファクトに埋め込まれたメタデータの時間分析から、この脅威アクターは 75～80% の確度で UTC+3 タイムゾーンにおいて活動していると推定されます。すべての UTC オフセットを対象とした体系的な分析の結果、UTC+3 が最も一致しました。アクティビティの開始は 08:30 頃、ピークは 12:00～18:00、推定される非活動時間帯は 00:30～08:30 でした。 図 1: Interlock ランサムウェアの身代金交渉ポータル。被害者が組織 ID とメールアドレスを入力し、認証トークンを受け取って交渉チャットセッションを開始する 技術分析: Interlock の攻撃ツールキット 侵害後の偵察スクリプト Interlock は初期アクセスを獲得した後、さまざまなツールを使用して攻撃を展開します。Amazon Threat Intelligence チームは、Windows 環境を体系的に列挙する (被害者のネットワーク情報を自動収集する) PowerShell スクリプトを取得しました。このスクリプトは、オペレーティングシステムとハードウェアの詳細、実行中のサービス、インストール済みソフトウェア、ストレージ構成、Hyper-V 仮想マシンインベントリ、デスクトップ・ドキュメント・ダウンロードの各ディレクトリにわたるユーザーファイル一覧、Chrome、Edge、Firefox、Internet Explorer、360 ブラウザからのブラウザアーティファクト (履歴、ブックマーク、保存された認証情報、拡張機能を含む)、プロセスに関連付けられたアクティブなネットワーク接続、ARP テーブル、iSCSI セッションデータ、および Windows イベントログからの RDP 認証イベントを収集します。 このスクリプトは、各システムの完全修飾ホスト名に基づいて専用ディレクトリを作成し、結果を集約用ネットワーク共有 (\JK-DC2\Temp) にステージングします。つまり、侵害した各コンピュータにフォルダが作成されます。収集が完了すると、データはホスト名に基づく名前の ZIP アーカイブに圧縮され、元の生データは削除されます。このようなホスト単位の構造化された出力形式は、スクリプトがネットワーク内の複数マシンにまたがって実行されていることを示しており、組織全体の暗号化に向けた準備を行うランサムウェア侵入チェーンの典型的な特徴です。 カスタムリモートアクセス型トロイの木馬 リモートアクセス型トロイの木馬 (RAT) とは、攻撃者が侵害したシステムへの持続的な制御を可能にする悪意のあるプログラムであり、不正なリモートデスクトップソフトウェアのように機能します。 JavaScript インプラント: Amazon Threat Intelligence は、難読化された JavaScript ベースの RAT を取得しました。この RAT はブラウザコンソールのメソッドをオーバーライドしてデバッグ出力を抑制し、基本的な検出ツールからアクティビティを隠蔽します。実行時には、PowerShell と Windows Management Instrumentation (WMI) を使用して感染ホストのプロファイリングを行い、システム ID、ドメインメンバーシップ、ユーザー名、OS バージョン、権限コンテキストを収集した上で、暗号化された初期化ハンドシェイクでこれらのデータを送信します。 コマンドアンドコントロール (C2) 通信には永続的な WebSocket 接続が使用され、メッセージごとにパケットヘッダーに埋め込まれた 16 バイトのランダムキーによる RC4 暗号化が適用されます。各メッセージが異なる暗号化キーを使用するため、傍受がより困難になる仕組みです。インプラントは、オペレーターが制御する複数のホスト名と IP アドレスをランダムな順序で巡回し、再接続試行間にはエクスポネンシャルバックオフを適用します。 このインプラントは、インタラクティブなシェルアクセス、任意のコマンド実行、双方向ファイル転送、TCP トラフィックのトンネリングに対応する SOCKS5 プロキシ機能 (悪意のあるトラフィックを他のシステム経由でルーティングして発信元を隠蔽) といった機能を備えています。また、自己更新および自己削除の機能もあり、オペレーターは再感染を伴わずにインプラントを置換または削除でき、フォレンジック調査を妨害する痕跡消去にも対応します。 Java インプラント: Java で実装された機能的に同等のクライアントも存在し、同一の C2 機能を提供します。GlassFish エコシステムライブラリ上に構築されており、ノンブロッキング I/O トランスポートには Grizzly を、WebSocket プロトコル通信には Tyrus を使用しています。つまり Interlock は、同じバックドアを 2 つの異なるプログラミング言語で構築することで、防御側が一方のバージョンを検出した場合でもアクセスを確実に維持できるようにしているのです。 インフラストラクチャロンダリングスクリプト 高度な脅威アクターは自身のインフラストラクチャから直接攻撃を仕掛けるのではなく、使い捨ての中継ネットワークを構築して痕跡を隠蔽します。Amazon Threat Intelligence チームは、Linux サーバーを HTTP リバースプロキシ (攻撃者の実際の所在地を隠すためにトラフィックを転送する中間サーバー) として構成する Bash スクリプトを特定しました。このスクリプトは、システムアップデートの実行、SSH ブルートフォース保護機能を持つ fail2ban のインストール、HAProxy 3.1.2 のソースからのコンパイルを行います。構成された HAProxy インスタンスはポート 80 でリッスンし、すべてのインバウンド HTTP トラフィックをハードコードされたターゲット IP に転送します。また、systemd によりシステム再起動後も持続性が確保されます。 特に注目すべきコンポーネントが、5 分ごとに cron ジョブとして実行されるログ消去ルーチンです。このルーチンは /var/log 配下のすべての *.log ファイルを切り詰め、HISTFILE 変数をアンセットしてシェル履歴を抑制します。5 分間隔でログを消去するこの積極的な証拠破壊は、専用に構築された HTTP 転送プロキシと組み合わせて考えると、このスクリプトが使い捨てのトラフィックロンダリング用中継ノードの構築を目的としていることを示しています。これらのノードは、エクスプロイトトラフィックの発信元隠蔽、C2 通信の中継、データ窃取のプロキシとして機能し、攻撃の発信源への追跡をほぼ不可能にします。 メモリ常駐型 Web シェル Amazon Threat Intelligence チームは、ELF バイナリの投下に代わる手段として配信される Java クラスファイルを確認しました。Java Virtual Machine (JVM) によってロードされると、静的イニシャライザが、サーバーの StandardContext に ServletRequestListener を登録し、ディスクへのファイル書き込みを一切行わずに HTTP リクエストを傍受する永続的なメモリ常駐型バックドアをインストールします。この「ファイルレス」アプローチにより、悪意のあるファイルを探索する従来のウイルス対策スキャンを回避することが可能になります。 リスナーは受信リクエストを検査し、暗号化されたコマンドペイロードを含む特殊なパラメータの有無を確認します。ペイロードは、ハードコードされたシード値 “geckoformboundary99fec155ea301140cbe26faf55ed2f40” の MD5 ハッシュから導出されたキー (先頭 16 文字の 09b1a8422e8faed0 を使用) による AES-128 で復号されます。復号されたペイロードはコンパイル済みの Java バイトコードとして扱われ、JVM に動的にロードされて実行されます。これは、悪意のあるコードを完全にメモリ内で実行することで、ファイルベースの検出を回避するために設計されたテクニックです。 接続確認ツール Amazon Threat Intelligence チームは、ポート 45588 でリッスンする基本的な TCP サーバーを実装した Java クラスファイルを取得しました (ポート番号は静的分析による特定を困難にするため、Unicode 文字 넔 としてエンコードされていました)。サーバーは接続を受け入れると、接続元の IP アドレスをログに記録し、挨拶メッセージを送信した後、即座に接続を切断します。この動作パターンは、初期エクスプロイト実行後のコード実行成功確認やネットワークポートへの到達性確認に使用される軽量なネットワークビーコン (いわゆる「フォンホーム」ツール) の特徴と一致しています。 正規ツールの悪用 Interlock はカスタムインプラントと並行して、正規の商用リモートデスクトップツールである ConnectWise ScreenConnect もデプロイしていました。ランサムウェアオペレーターが正規のリモートアクセスツールをカスタムマルウェアと併用するのは、いわば保険をかけているようなものです。防御側が 1 つのバックドアを発見して除去しても、別の侵入経路が残ります。これは冗長なリモートアクセス手段を複数確保するパターンであり、個々の足場が除去されてもアクセスを維持しようとするランサムウェアオペレーターの典型的な手法と一致しています。正規ツールならではのネットワークフットプリントにより、許可されたリモート管理トラフィックに紛れ込むことができ、検出がさらに困難になります。 Amazon Threat Intelligence チームは、インシデントレスポンダーが広く使用するオープンソースのメモリフォレンジックフレームワークである Volatility も取得しました (防御側が攻撃調査に使用するのと同じツールです)。自動化された使用を示すアーティファクトは確認されなかったものの、カスタムインプラントや偵察スクリプトとともに配置されていたことは、高度な脅威オペレーションの特徴と合致しています。ランサムウェアグループと国家支援型アクターの双方が、侵入時に Volatility をデプロイしていることが確認されています。メモリダンプの解析に特化したこのツールは、RAM に保存された認証情報などの機密データへのアクセスを可能にし、ラテラルムーブメント (ネットワーク内の横展開) やより深い環境侵害を通じてランサムウェアオペレーションやスパイ活動を支援します。 さらに Interlock は、Active Directory Certificate Services (AD CS) の設定ミスを悪用するためのオープンソースの攻撃的セキュリティツールである Certify も使用していました。ランサムウェアオペレーターにとって、Certify は脆弱な証明書テンプレートや、認証用証明書の要求を許可する登録権限を特定する手段となります。取得した証明書は、ユーザーのなりすまし、権限の昇格、永続的なアクセスの維持に悪用できます。これらの機能は、ランサムウェアオペレーションにおける初期侵害と長期的な永続化の双方を直接支援するものです。 侵害インジケータ (IoC) 以下のインジケータは、影響を受けた可能性のある組織での防御に役立てることができます。Interlock はコンテンツバリエーション技法を使用しているため、ほとんどのファイルハッシュは信頼性の高いインジケータとしては掲載していません。脅威アクターは、異なるターゲットに配信するスクリプトやバイナリなどのアーティファクトに逐次変更を加えており、機能的には同一のツールであってもファイルハッシュが異なるものとなっていました。このカスタマイズにより、ファイルの完全一致に依存するシグネチャベースの検出が回避されていました。 206.251.239[.]164 エクスプロイトソース IP 2026 年 1 月に活動確認 199.217.98[.]153 エクスプロイトソース IP 2026 年 3 月に活動確認 89.46.237[.]33 エクスプロイトソース IP 2026 年 3 月に活動確認 Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0 エクスプロイト HTTP User-Agent 2026 年 1 月および 3 月に観測 b885946e72ad51dca6c70abc2f773506 エクスプロイト TLS JA3 2026 年 1 月および 3 月に観測 f80d3d09f61892c5846c854dd84ac403 エクスプロイト TLS JA3 2026 年 3 月に観測 t13i1811h1_85036bcba153_b26ce05bbdd6 エクスプロイト TLS JA4 2026 年 1 月および 3 月に観測 t13i4311h1_c7886603b240_b26ce05bbdd6 エクスプロイト TLS JA4 2026 年 3 月に観測 144.172.94[.]59 C2 フォールバック IP 2026 年 3 月に活動確認 199.217.99[.]121 C2 フォールバック IP 2026 年 3 月に活動確認 188.245.41[.]78 C2 フォールバック IP 2026 年 3 月に活動確認 144.172.110[.]106 バックエンド C2 IP 2026 年 3 月に活動確認 95.217.22[.]175 バックエンド C2 IP 2026 年 3 月に活動確認 37.27.244[.]222 ステージングホスト IP 2026 年 3 月に活動確認 hxxp://ebhmkoohccl45qesdbvrjqtyro2hmhkmh6vkyfyjjzfllm3ix72aqaid[.]onion/chat.php 身代金交渉ポータル 2026 年 3 月に活動確認 cherryberry[.]click エクスプロイトサポートドメイン 2026 年 1 月に活動確認 ms-server-default[.]com エクスプロイトサポートドメイン 2026 年 3 月に活動確認 initialize-configs[.]com エクスプロイトサポートドメイン 2026 年 3 月に活動確認 ms-global.first-update-server[.]com エクスプロイトサポートドメイン 2026 年 3 月に活動確認 ms-sql-auth[.]com エクスプロイトサポートドメイン 2026 年 3 月に活動確認 kolonialeru[.]com エクスプロイトサポートドメイン 2026 年 3 月に活動確認 sclair.it[.]com エクスプロイトサポートドメイン 2026 年 3 月に活動確認 browser-updater[.]com C2 ドメイン 2026 年 3 月に活動確認 browser-updater[.]live C2 ドメイン 2026 年 3 月に活動確認 os-update-server[.]com C2 ドメイン 2026 年 3 月に活動確認 os-update-server[.]org C2 ドメイン 2026 年 3 月に活動確認 os-update-server[.]live C2 ドメイン 2026 年 3 月に活動確認 os-update-server[.]top C2 ドメイン 2026 年 3 月に活動確認 d1caa376cb45b6a1eb3a45c5633c5ef75f7466b8601ed72c8022a8b3f6c1f3be 攻撃的セキュリティツール (Certify) 2026 年 3 月に観測 6c8efbcef3af80a574cb2aa2224c145bb2e37c2f3d3f091571708288ceb22d5f スクリーンロッカー 2026 年 3 月に観測 防御に関する推奨事項 Interlock ランサムウェアの脅威から組織を守るために、以下の対策を実施してください。 直ちに実施すべきアクション: Cisco Secure Firewall Management Center に対する Cisco のセキュリティパッチを適用する 上記の IoC についてログを確認する 侵害の兆候がないかセキュリティ評価を実施する ScreenConnect の不正なインストールがないか確認する 検出のポイント: ネットワーク共有にホスト名ベースのディレクトリ構造でデータをステージングする PowerShell スクリプトを監視する Web アプリケーションコンテキストでの Java ServletRequestListener の登録 (Java Web アプリケーションへの通常とは異なる変更) を検出する 積極的なログ消去用 cron ジョブを伴う HAProxy のインストール (5 分間隔で自身のログを消去するプロキシサーバー) を特定する 通常とは異なる高番号ポート (例: 45588) への TCP 接続を監視する 長期的な対策: 複数のセキュリティ制御レイヤーによる多層防御戦略を実装する 継続的な脅威監視とスレットハンティングの能力を維持する 侵害を受ける可能性のあるシステムとは分離した、安全で一元化されたログストレージによる包括的なログ収集を確保する ランサムウェアシナリオに対するインシデントレスポンス手順を定期的にテストする Interlock の戦術、テクニック、手順についてセキュリティチームを教育する ここで本当に重要なのは、これが特定の脆弱性や特定のランサムウェアグループだけの問題ではないということです。ゼロデイエクスプロイトがあらゆるセキュリティモデルに突きつける根本的な課題なのです。パッチが存在しない段階で攻撃者に脆弱性を悪用されてしまえば、どれほど徹底したパッチ管理を行っていても、その重要な期間中は防御できません。だからこそ多層防御が不可欠なのです。複数のセキュリティ制御を重ねることで、いずれかの対策が機能しない場合や、まだ導入されていない場合でも保護を維持できます。迅速なパッチ適用は脆弱性管理の基盤であり続けますが、多層防御は、エクスプロイトが確認されてからパッチが提供されるまでの空白期間に、組織が無防備にならないための重要な手段です。 Amazon Threat Intelligence チームは Interlock ランサムウェアの活動を引き続き監視しており、新たな情報が判明し次第アップデートを提供します。今回のキャンペーンから収集したインテリジェンスは、お客様をプロアクティブに保護するため、AWS のセキュリティサービスに統合されています。 この記事に関するご質問は、 AWS サポート までお問い合わせください。 CJ Moses CJ Moses は Amazon Integrated Security の CISO です。Amazon 全体のセキュリティエンジニアリングとオペレーションを統括しており、セキュリティの実践が最も自然で簡単な選択肢となるようにすることで Amazon のビジネスを支えることを使命としています。2007 年 12 月に Amazon に入社し、Consumer CISO、直近では AWS CISO を含むさまざまな役職を歴任した後、2023 年 9 月に現職に就任しました。 Amazon 入社以前は、連邦捜査局 (FBI) サイバー部門でコンピュータおよびネットワーク侵入に関する技術分析を率いていました。また、空軍特別捜査局 (AFOSI) の特別捜査官も務めました。現在のセキュリティ業界の基盤を築いたとされる、複数のコンピュータ侵入捜査を指揮しました。 CJ はコンピュータサイエンスと刑事司法の学位を取得しており、SRO GT America GT2 のレースカードライバーとしても活躍しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

Amazon S3 の一般提供が開始されたのは、20 年前の先週にあたる 2006 年 3 月 14 日でした。 Amazon Simple Storage Service は、クラウドインフラストラクチャを定義した基礎的なストレージサービスだと考えられがちですが、シンプルなオブジェクトストレージサービスとして始まった S3 は、今でははるかに広い範囲と規模を備えたサービスへと成長を遂げました。 2026 年 3 月現在、S3 には 500 兆を超えるオブジェクトが格納されており、何百エクサバイトものデータ全体で 1 秒あたり 2 億件を超えるリクエストをグローバルに処理しています。料金は 1 ギガバイトあたり 2 セントを少し超える程度まで下がっており、リリース時から約 85% 削減されたことになります。私の同僚である Sébastien Stormacq が、「 Amazon S3 の 20 年を振り返り、未来を築く 」でエンジニアリングと今後の展望に関する詳しい記事を書きました。AWS の最初のお客様と、これらのお客様が現在の AWS をどのように形作ったかに関心がある場合は、「 How three startups helped Amazon invent cloud computing and paved the way for AI 」をぜひお読みください。20 年。これは立ち止まって祝うに値する年月です。 S3 の 20 周年記念に伴い、今週は Channy Yun も S3 の新機能、Amazon S3 汎用バケットのアカウントリージョナル名前空間に関する記事を書きました。この機能を使用すると、リクエストするバケット名にアカウント固有のサフィックスを追加することで、ユーザー独自のアカウントリージョナル名前空間内に汎用バケットを作成できるため、使用したい名前がユーザーのアカウント専用に常時予約されるようになります。新しい s3:x-amz-bucket-namespace 条件キーを用いた AWS IAM ポリシーと AWS Organizations サービスコントロールポリシーを使用して、組織全体での導入を強制できます。 Amazon S3 汎用バケットのアカウントリージョナル名前空間の詳細については、 Channy の記事 をお読みください。 2026 年 3 月 16 日週に行われた注目のリリースは、 Amazon Route 53 Global Resolver の一般提供 です。このサービスは、私自身との個人的なつながりがあるものです。昨年の re:Invent 2025 でのこの機能の プレビュー に関する記事を書いたのですが、とても楽しく取り組めた記事だったので、一般提供が開始されたと聞いて本当に嬉しく思っています。 インターネット経由でアクセスできるエニーキャスト DNS リゾルバーである Amazon Route 53 Global Resolver は、どこからでも承認済みクライアントに DNS 解決を提供できます。30 の AWS リージョンで一般提供が開始されており、IPv4 と IPv6 両方の DNS クエリトラフィックをサポートします。Route 53 Global Resolver は、組織内の認証済みクライアントに対し、Route 53 プライベートホストゾーンに関連付けられたパブリックインターネットドメインとプライベートドメインのエニーキャスト DNS 解決を、特定の VPC やリージョン内だけでなく、どこからでも提供します。また、悪意があると考えられるドメイン、職場に不適切なドメイン、および DNS トンネリングやドメイン生成アルゴリズム (DGA) などの高度な DNS 脅威に関連するドメインをブロックするための DNS クエリフィルタリング機能も提供されており、一元化されたクエリのログ記録機能も含まれています。一般提供された Global Resolver は、辞書ベースの DGA 脅威に対する保護を強化します。 2026 年 3 月 9 日週のリリース 以下は、2026 年 3 月 9 日週に行われたその他の発表の一部です。 Amazon Bedrock AgentCore Runtime がステートフル MCP サーバー機能のサポートを開始 – Amazon Bedrock AgentCore Runtime が、ステートフルモデルコンテキストプロトコル (MCP) サーバー機能のサポートを開始しました。開発者はこの機能を使用して、リソース、プロンプト、およびツールに対する既存のサポートとともに、エリシテーション (情報の引き出し)、サンプリング、および進捗通知を使用する MCP サーバーを構築できます。ステートフル MCP セッションでは、分離されたリソースを用いる専用の MicroVM で各ユーザーセッションが実行され、サーバーは Mcp-Session-Id ヘッダーを使用して複数のやり取りにおけるセッションコンテキストを維持します。エリシテーションは、サーバーが開始するマルチターンの会話を行って、ツールの実行中に構造化された入力をユーザーから収集できるようにします。サンプリングは、パーソナライズされた推奨事項などのタスクのために、サーバーがクライアントに LLM 生成コンテンツをリクエストすることを可能にします。進捗通知は、長時間に及ぶ操作中でも、クライアントが情報を常に把握しておけるようにします。詳細については、 Amazon Bedrock AgentCore ドキュメントを参照してください。 Amazon WorkSpaces が Microsoft Windows Server 2025 のサポートを開始 – Amazon WorkSpaces Personal と Amazon WorkSpaces Core で Microsoft Windows Server 2025 を活用する新しいバンドルを利用できるようになりました。これらのバンドルには、Trusted Platform Module 2.0 (TPM 2.0)、Unified Extensible Firmware Interface (UEFI) Secure Boot、セキュアコアサーバー、Credential Guard、Hypervisor-protected Code Integrity (HVCI)、DNS-over-HTTPS などのセキュリティ機能が含まれています。既存の Windows Server 2016、2019、および 2022 のバンドルも引き続きご利用いただけます。マネージド Windows Server 2025 バンドルを使用することも、カスタムのバンドルとイメージを作成することも可能です。このサポートは、Amazon WorkSpaces が提供されているすべての AWS リージョンでご利用いただけます。詳細については、「 Amazon WorkSpaces のよくある質問 」をご覧ください。 AWS ビルダー ID が GitHub と Amazon を用いたサインインのサポートを開始 – AWS ビルダー ID でサポートされるソーシャルログインオプションに、GitHub と Amazon の 2 つのオプションが追加されました。これらのオプションは、既存の Google と Apple のサインイン機能に新たに追加されるものです。この更新により、開発者は一連の認証情報を個別に管理しなくても、既存の GitHub または Amazon のアカウント認証情報を使用して AWS ビルダー ID プロファイル (および AWS Builder Center、AWS トレーニングと認定、Kiro などのサービス) にアクセスできるようになります。詳細を確認して使用を開始するには、 AWS ビルダー ID ドキュメントをご覧ください。 Amazon Redshift に COPY 操作用の再利用可能なテンプレートを導入 – 頻繁に使用される COPY パラメータを保存して再利用できる COPY コマンド用のテンプレートが Amazon Redshift でサポートされるようになりました。テンプレートは、データインジェスト操作全体で一貫性を維持するために役立ち、COPY コマンドの実行に必要な労力を軽減して、将来の使用のすべてにテンプレート更新を自動適用することでメンテナンスを簡素化します。COPY テンプレートのサポートは、Amazon Redshift が提供されているすべての AWS リージョン (AWS GovCloud (米国) リージョンを含む) でご利用いただけます。使用を開始するには、こちらの ドキュメント を参照するか、ブログ記事「 Standardize Amazon Redshift operations using Templates 」をお読みください。 AWS のお知らせに関する詳しいリストについては、 ニュースブログ チャネルである「 AWS の最新情報 」ページをご覧ください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – 2026 年の AWS Summit に参加しましょう。AWS Summit は、クラウドおよび AI 関連の新興テクノロジーを探求し、ベストプラクティスについて学び、業界の同業者や専門家とつながることができる無料の対面イベントです。次回の Summit は、 パリ (4 月 1 日)、 ロンドン (4 月 22 日)、 バンガロール (4 月 23〜24 日) で開催される予定です。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供し、テクニカルディスカッション、ワークショップ、ハンズオンラボが行われるコミュニティ主導のカンファレンスです。今後のイベントには、 プネー (3 月 21 日)、 サンフランシスコ (4 月 10 日)、 ルーマニア (4 月 23～24 日) などがあります。 AWS at NVIDIA GTC 2026 – 2026 年 3 月 16～19 日に米国サンノゼで開催される NVIDIA GTC 2026 で、AWS のセッション、ブース、デモ、付帯イベントに参加しましょう。AWS 経由でイベントパスの 20% 割引を受け、GTC での 1 対 1 ミーティングをリクエストできます。 AWS Community GameDay Europe – 2026 年 3 月 17 日に行われる AWS Community GameDay Europe は、ヨーロッパの 50 を超える都市で同時開催される、チームベースのハンズオン AWS チャレンジイベントです。参加チームは、壊れた AWS 環境内 (誤設定されたサービス、欠陥のあるアーキテクチャ、セキュリティギャップ) に配置され、2 時間の制限時間内で環境を可能な限り修正する必要があります。最寄りの開催都市を見つけて、 awsgameday.eu でサインアップしてください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。こちらのリンクから、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と デベロッパー向けのイベント をご覧いただけます。 2026 年 3 月 16 日週のニュースは以上です。2026 年 3 月 23 日週の Weekly Roundup もお楽しみに! – Esra この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

本ブログは 2026 年 3 月 10 日に公開された AWS Blog、” AWS Security Hub is expanding to unify security operations across multicloud environments ” を翻訳したものです。 多くのお客様と話をして、1 つ明確なことがあります。それは、セキュリティの課題は容易になっていないということです。今日の企業は、オンプレミスインフラストラクチャ、プライベートデータセンター、複数のクラウドなど、複雑に混在する環境で運用しており、多くの場合、連携を前提に設計されていないツールを使用しています。その結果、企業のセキュリティチームは、リスク管理よりもツール管理に多くの時間を費やすことになり、ますます複雑化する環境全体で脅威に先回りすることが困難になっています。 Amazon Web Service (AWS) では、セキュリティはシンプルで、統合され、企業が実際に運用する方法に合わせて構築されるべきだと考えています。この信念が、 AWS Security Hub を再構築し、単一のエクスペリエンスを通じてフルスタックセキュリティを提供する原動力となり、このビジョンが私たちの次の展開を推し進めています。 統合セキュリティの基盤の上に 私たちは Security Hub を、 統合セキュリティオペレーションソリューション に変革しました。これは、 Amazon GuardDuty 、 Amazon Inspector 、 AWS Security Hub Cloud Security Posture Management (Security Hub CSPM) 、 Amazon Macie を含む AWS セキュリティサービスを統合し、脅威、脆弱性、設定ミス、機密データに関するセキュリティシグナルを自動的かつ継続的に分析する単一のエクスペリエンスを実現しています。Security Hub は共通の基盤を提供し、AWS 環境全体からの検出結果を統合することで、セキュリティチームがシグナルの解釈に費やす時間を減らし、対応により多くの時間を割けるようにします。この基盤の上に構築された統合オペレーションレイヤーは、セキュリティチームにニアリアルタイムのリスク分析、自動化された分析、優先順位付けされたインサイトを提供し、大規模に最も重要なことに集中できるよう支援します。 また、企業がエンドポイント、ID、メール、ネットワーク、データ、ブラウザ、クラウド、AI、セキュリティオペレーション全体にわたるフルスタックセキュリティソリューションを調達、デプロイ、統合する方法を簡素化する新機能 ( the Extended plan ) を導入しました。現在、お客様は Security Hub を使用して、厳選された AWS パートナーソリューション (ローンチ時: 7AI、Britive、CrowdStrike、Cyera、Island、Noma、Okta、Oligo、Opti、Proofpoint、SailPoint、Splunk (Cisco 傘下)、Upwind、Zscaler) を通じて、すべて 1 つの統一されたエクスペリエンスでセキュリティポートフォリオを拡張できます。AWS が販売元となるため、従量制料金の料金体系、単一の請求書、長期契約なしというメリットを享受できます。私たちのゴールはシンプルです。企業が運営するあらゆる場所で、統一されたセキュリティを提供することです。 ワークロードがどこにあっても、自由にイノベーションを AWS では、相互運用性とは、お客様のニーズに最適なソリューションを自由に選択でき、ワークロードが実行される場所でそれらを使用できることを意味します。しかし、マルチクラウド環境全体で自由にイノベーションを起こすということは、運用の複雑さを増すことなく、一貫してそれらを保護することが重要であることも意味します。 Security Hub の今後の展開 今後数か月間で、AWS を超えた統合セキュリティオペレーションを拡張する新しいマルチクラウド機能を Security Hub に追加します。この拡張の基盤となるのは、ワークロードがどこで実行されていても、セキュリティシグナルを統合する共通データレイヤーです。その上に、統合されたポリシーとオペレーションレイヤーが、一貫したポスチャ管理、エクスポージャー分析、リスクの優先順位付けを提供するため、セキュリティチームは断片化されたコンソールの集合ではなく、単一のリスクビューから運用できます。 Security Hub は、マルチクラウド環境全体にわたる重要なリスクを明らかにする統合リスク分析を提供します。一貫したセキュリティポスチャの可視性を提供する Security Hub CSPM チェックを使用してクラウドセキュリティポスチャを管理でき、仮想マシンスキャン、コンテナイメージスキャン、サーバーレススキャンを含む拡張された Amazon Inspector 機能により、脆弱性管理を拡張できます。また、Security Hub は、外部ネットワークスキャンにより、AWS 以外で実行されているリソースを含むマルチクラウド環境全体のインターネット公開状態に関するコンテキストでセキュリティ検出結果をエンリッチします。 その結果、企業全体でより包括的なリスクカバレッジが実現されます。これは、セキュリティチームに対して、どこで運用していても、リスクを検出して対応するための単一の統一されたエクスペリエンスを提供することを目的としています。 ビジネスを加速するセキュリティ 私が話をするセキュリティリーダーたちは、単により良いツールを求めているわけではありません。求めているのは、リスクを管理するだけでなく、リスクに先回りする方法です。ビジネスのペースについていくセキュリティを求めており、ビジネスを遅らせるセキュリティではありません。 これが AWS Security Hub のビジョンです。共通のデータ基盤上に構築され、インテリジェントな分析によって強化され、一貫した運用レイヤーを通じて提供される、単一の統合されたセキュリティ運用体験による統一されたセキュリティです。これにより、セキュリティリスクの軽減、チームの生産性向上、AWS 全体およびそれ以外でのセキュリティ運用の強化を支援します。 マルチクラウドへの拡大は進行中であり、まだ始まったばかりです。 詳細については、 aws.amazon.com/security-hub をご覧いただくか、3 月 23 日から 26 日にサンフランシスコで開催される RSA Conference の AWS ブース (S-0466) にお越しください。 Gee Rittenhouse Gee は AWS のセキュリティサービス担当バイスプレジデントで、Security Hub、GuardDuty、Inspector などの主要サービスを統括しています。MIT で博士号を取得し、エンタープライズセキュリティとクラウド分野で豊富なリーダーシップ経験を持っています。以前は Skyhigh Security の CEO および Cisco セキュリティビジネスグループの SVP 兼 GM を務めていました。 翻訳は Security Solutions Architect の 松崎 博昭 が担当しました。

AWS 認定とは AWS 認定 は、AWS が提供するクラウドサービスに関する公式の認定資格制度です。AWS のサービスやクラウドの知識・スキルを証明するもので、エンジニアだけでなく、クラウドに関わるビジネス担当者や IT 職種全般のスキルの証明に活用されています。認定は 4 つのレベルに分かれており、計 12 種類の認定があります（2026 年 3 月時点/ベータ版を除く）。12 種類の認定は「 認定の取得パス 」として、8 つの系統（アーキテクチャや DevOps、AI/ML など）、それに紐づく16のロール（Solutions Architect、Cloud DevOps Engineer、Data scientist など）をカバーできるようになっています。 — AWS 認定の全冠とは 全冠は現在受験が可能な認定を全て保持していることを意味します。2026 年 3 月時点では、12 種類の認定に合格しなければなりません。日本では AWS Partner Network (APN) に参加している企業限定で、「 Japan All AWS Certifications Engineers 」という全冠表彰が行われています。毎年、年度末時点で条件を満たす方が対象となり、2025 年度の全冠は 1,633 名と限られた存在であることが言えます。AWS 認定は知識を問う Foundational にはじまり、Associate/Professional/Specialty では知識だけでなくスキルを問う内容となっており、受験勉強のみならず AWS を実際に利用できることが前提となってきます。1 つの認定取得でも数ヶ月の準備が必要となり、全冠を達成するには高いモチベーションを維持し続けること、そして準備のための時間の確保・調整が不可欠です。また、全冠達成後もそれを維持することは容易ではありません。AWS 認定の有効期間は 3 年間、全冠を維持するには達成後も定期的に複数の認定の更新受験が必要になります。そのため、継続的な知識・スキルのキャッチアップが求められます。 知識とスキルの対応可能な範囲という意味では、「 認定の取得パス 」が 1 つの指標となります。1 つのロールを担うにあたり、5 つ前後の認定が必要となります。全冠の方は 16 のロールを一人で網羅することも可能であり、それだけの知識とスキルを有している特別かつ希少な人材と言えます。 今回のインタビューでお二人に着ていただいた眩しいばかりの金色のジャケット（通称：ゴールデンジャケット）は、全冠の方だけが手に入れることができる特別な特典です。これはワールドワイドの取り組みで、AWS 認定の界隈では日本のみならず、世界中の方がこれを着ていれば一目でその方が全冠だと分かるアイテムです。世界レベルでも全冠は希少な人材であり、昨年の re:Invent では全冠限定、ドレスコードはゴールデンジャケット着用という特別な式典も開催されるなど、AWS としてもその功績を称えています。 — エンドユーザー企業で全冠を達成したお二人にインタビュー 日本では多くのエンドユーザー企業がシステム開発を専門家である SIer に依頼しています。そのため、エンジニアが在籍する割合も SIer が高く、結果として全冠の方の多くが SIer に所属しています。本インタビューでは、その全冠を「システムを作る側」の SIer ではなく、「業務としてシステムを利用し、意思決定を行う立場」であるエンドユーザー企業の住友商事に所属するお二人に、エンドユーザー企業で AWS 認定の全冠を目指した理由、そして AWS 認定取得後の変化、AWS 認定への今後の期待についてお聞きしました。 ① 種岡 寛人氏 住友商事（フィナンシャル企画業務部 部長代理 次期基幹システム導入チーム） データドリブン経営を目的とした全社経営基盤の構築プロジェクトに参画したことをきっかけに、SIer とのテクニカルな議論についていくことを目的として AWS について学び始める。週末用の勉強スペースを自宅外で借りるなど、集中して学習できる環境面を整備して受験に挑む。 ＜取得履歴＞ 2024 年 7 月 AWS Certified Cloud Practitioner 11 月 AWS Certified Solutions Architect – Associate 2025 年 1 月 AWS Certified Data Engineer – Associate AWS Certified AI Practitioner 2 月 AWS Certified Machine Learning Engineer – Associate 4 月 AWS Certified Developer – Associate 5 月 AWS Certified SysOps Administrator – Associate 6 月 AWS Certified Machine Learning – Specialty 8 月 AWS Certified Security – Specialty 9 月 AWS Certified Advanced Networking – Specialty 11 月 AWS Certified DevOps Engineer – Professional 12 月 AWS Certified Solutions Architect – Professional ② 池田 謙斗氏 住友商事（IT 企画推進室 IT 統制・セキュリティチーム 情報セキュリティライン） IT バックボーンは持っており感覚的に理解していた部分を、体系的に学び直し始める。住友商事が AI 活用を推し進めていることもあり、AI/ML に関するベストプラクティスを学ぶ機会としても AWS 認定を活用。受験準備の間は出社前に 2 時間勉強することをルーティーンに。 ＜取得履歴＞ 2020 年 8 月 AWS Certified Cloud Practitioner 2025 年 2 月 AWS Certified Solutions Architect – Associate 3 月 AWS Certified Data Engineer – Associate AWS Certified SysOps Administrator – Associate AWS Certified AI Practitioner 4 月 AWS Certified Machine Learning Engineer – Associate AWS Certified Developer – Associate AWS Certified DevOps Engineer – Professional AWS Certified Machine Learning – Specialty 5 月 AWS Certified Solutions Architect – Professional AWS Certified Security – Specialty AWS Certified Advanced Networking – Specialty — 全冠を目指したきっかけ AWS Certified Cloud Practitioner (CLF) の取得を通して、AWS 認定は実務と直結した形で知識を整理できる最適な学習方法と感じ、その体験から他の AWS 認定にも挑戦したいという思いが芽生えた種岡氏。CLF 取得後、米国ラスベガスで開催されている AWS のイベント “re:Invent” に参加できる機会があり、そこで全冠ホルダーと初めて出会う。全冠ホルダーと会話したことで、全冠というゴールがあることを知る。加えて AWS Jam への参加を通して様々な国の参加者がいても、 AWS 認定が国や職種を超える1つの共通言語であることを体感。そのような体験を通して、より深く AWS を理解してみたいと思い全冠を目指す。 アーキテクチャ、ベストプラクティスに一定の知識と理解はあるが、感覚的に対応している部分があると感じ、改めて体系的に学び直したいと考えた池田氏。学び直しの手段として AWS 認定を活用。学び直しを進める中でゴールをどこに置くのかと考え、 AWS の知識・スキルに関して社内で No.1 を目指すことが自分を高める方法であり、会社のミッションにもそれが合致すると考え、No.1 の指標として全冠を目指す。 全冠達成のためには、インフラ、アプリケーション、セキュリティ、AI/ML など、クラウドに関わる全ての領域にわたる理解とスキルが求められます。特定分野に特化したエンジニアであっても全冠の達成は容易ではなく、業務を主軸とするエンドユーザー企業で全冠を達成することはレアケースと言えます。お二人は日常業務を担いながらも、AWS を「発注する・利用する側」として知識とスキルの習得に挑み、全冠を達成しました。その背景には、住友商事のシステムをブラックボックスにしないという強い課題意識がありました。 — AWS 認定を取得して良かったこと システムを作るではなく開発を依頼する側であっても AWS 認定の取得は効果を発揮します。AWS 認定の取得を通して AWS ならびにクラウドへの一定の知識とスキルを得ることで、共通言語や共通ルール、ベストプラクティスや優先順位という議論の軸が生まれ、共通のイメージが持ちやすくなります。住友商事においても、SI パートナーと技術的な共通言語を持つことで、プロジェクトにおける要件定義から実装まで共通認識を持つことが可能になり、プロジェクトの品質向上・コスト最適化・スピードアップが可能になりました。依頼者が AWS を理解しているからこそパートナーから最適な提案がされ、理解してもらえるからこそ十分な説明が期待できます。利用する側であっても「できること」「できないこと」が明確になり、効果的な AWS の活用が可能になります。 — 全冠になって良かったこと エンドユーザー企業では AWS 認定といっても取得の大変さがわかってもらえない部分がありましたが、AWS 認定を全て保持していることは社内でも AWS のエキスパートであると認知がされるようになりました。実際の現場ではエンドユーザーに求められる知識が、利用できる選択肢が増えたことでプロフェッショナル寄りにシフトしているところがあり、最適な選択肢を選ぶうえでも全冠で得た知識とスキルは活用できていると感じます。 また今回のインタビューを含め、LinkedIn など、全冠だからこそ社外への認知や繋がりを高めることもできました。全冠の価値は認定を全て保有しているという事実と、その過程で身につけた「全体を構造として捉える力」にあります。業務側であってもクラウドの前提や制約、設計思想を理解していることで、自らも主体的に建設的な議論が可能になります。全冠はエンジニアリングの証明であると同時に、 “業務と IT を橋渡しできる人材であることの1つの到達点” でもあります。 — AWS 認定に期待すること AWS 認定を持っているからこそ、AWS 認定の価値と認知度を引き続き高めてほしい。そして、全冠をより明確に示すために「全冠」というカテゴリーを設けてデジタルバッジで一目瞭然で分かるようにしてほしい。また、全冠の維持という点で、受験以外の方法があればうれしい。スキルという部分では Microcredential によって特定スキルの深い部分の測定が可能になっていくと思うが、AWS を利用する側の目線やマルチクラウドに対応するなど現況にフィットした形で認定を進化させていってほしいという意見をいただきました。 — インタビューをさせていただいて 全冠という長い道のりを苦しかったけど楽しかったと語られているのが印象的でした。エンドユーザー企業で全冠を目指すことの大変さ（サポートやご家族の理解など）を知るとともに、AWS 認定への貴重な意見をいただく大変すばらしい機会となりました。住友商事のお二人のことを自分のことのように熱量を持って語ってくれた AWS の中村氏/林氏からは、担当という域を超えた繋がりを感じることもできました。種岡氏からも「受験中は合格報告を行えることがモチベーションになり、技術的な相談だけでなく、業務や組織の背景を踏まえた視点で伴走いただけていると感じている」と大変ありがたいコメントをいただきました。 — 最後に 総合商社では、ビジネスの幅広さゆえに AWS 以外にも多くの領域への対応が求められます。また、SIer をはじめとするパートナーとの協業体制の中では、必ずしも自らが深い技術的知識を持たなくても業務を推進できるケースもあります。活用を追及し自ら積極的に技術を学び続けるお二人の姿勢が際立ちました。AWS 認定はエンジニアのための認定という側面がありますが、もう一方ではシステムを利用する方のための認定でもあります。AWS 認定を通して AWS を理解していただき、より効果的に活用いただければと思います。 左から、林氏（AWS）、種岡氏（住友商事）、池田氏（住友商事）、中村氏（AWS） — 林 隆太郎氏 | AWS（総合商社・エネルギー業界担当 ソリューションアーキテクト） 大手ガス会社にてガススマートメーター・電力トレーディングのシステム開発を経験した後、総合商社にて全社の IT/DX 推進と国内外のエネルギー領域での事業投資・新規事業開発を担当。現在は AWS 総合商社・エネルギー業界のソリューションアーキテクトとして、業界知識を活かした AWS 活用に携わる。 — 中村 真太朗氏 | AWS（住友商事グループ 担当営業） 大手SIerにて製造業・小売業界を中心としたエンタープライズセールスとして基幹システム、BI・データプラットフォーム、大規模共通インフラ基盤など様々なシステムに関する提案や構築の伴走を担当。現在は、住友商事グループ担当として、グループ横断でのDX推進に携わる。 — インタビュー担当：トレーニングサービス本部　  T&C Certification BDM 両角貴寿（Moro）

本稿は、2026 年 2 月 23 日に公開された “ Adding HTTP security headers using Amazon CloudFront ” を翻訳したものです。 この投稿は、複雑な実装を行うことなくアプリケーションのセキュリティ水準を強化したいと考えている Web デベロッパー、DevOps エンジニア、およびセキュリティプロフェッショナルを対象として書かれています。HTTP セキュリティヘッダーは、クロスサイトスクリプティング（XSS）、クリックジャッキング、中間者攻撃といった一般的な Web 脆弱性からユーザーを保護することができる、重要でありながらも見落とされがちな防御レイヤーです。これらのヘッダーは、閲覧者とコンテンツプロバイダーの双方のセキュリティとプライバシーを向上させることを目的とした、特定のレスポンスヘッダー群を追加することで実装されます。この投稿では、Web サイトおよび Web アプリケーションのオーナーが、 Amazon CloudFront を使用してこれらのヘッダーの実装を効率化する方法について説明します。 これらのヘッダーをサーバーではなく CloudFront で追加することには、複数のメリットがあります。 オリジンサーバーのコードを変更できない場合 オリジンサーバー上のアプリケーションは、リクエストされたコンテンツの提供に専念でき、ヘッダーの追加処理にリソースを割くことが不要 ヘッダー追加の処理を CloudFront に委ねることで、CloudFront とオリジンサーバー間の帯域幅を節約でき、サーバーの負荷も軽減 オリジンサーバーで直接変更する場合と比べて、CloudFront でセキュリティヘッダーを柔軟に変更可能 セキュリティヘッダーとは何ですか？ セキュリティヘッダーとは、サーバーからの HTTP レスポンスに含まれるヘッダーの集合であり、ブラウザがサイトのコンテンツを処理する際の動作を理解するのに役立ちます。例えば、 X-XSS-Protection は、XSS 攻撃を検知した際にページの読み込みを停止するよう Internet Explorer および Chrome ブラウザが従うヘッダーです。以下は、CloudFront を使用してレスポンスに追加する各ヘッダーの一覧です。 Strict Transport Security Content-Security-Policy X-Content-Type-Options X-Frame-Options X-XSS-Protection Referrer-Policy これらのヘッダーの詳細については、 Mozilla の Web セキュリティガイド をご参照ください。 HTTP セキュリティヘッダーは、Web アプリケーションを一般的な脆弱性から保護するのに役立ちます。以下のシナリオでは、CloudFront を使用してこれらのヘッダーを実装し、Web サイトのセキュリティを強化する方法を紹介します。 あるオンライン小売業者が、チェックアウトプロセスのセキュリティを強化したいと考えているとします。この業者は、悪意のある第三者が他の Web サイトの iframe にチェックアウトページを埋め込もうとするクリックジャッキング攻撃を懸念しているかもしれません。この業者は、CloudFront を使用して X-Frame-Options  や Content-Security-Policy などの HTTP セキュリティヘッダーを実装することで、自社のページが不正なサイトに表示されるのを防ぐことができます。このアプローチにより、オリジンサーバーへの変更を必要とせずに顧客保護を強化できるため、サードパーティの EC プラットフォームを利用している企業にとって特に有効です。 次に、規制遵守とデータ保護のために患者ポータルのセキュリティを強化したいと考えている医療機関を想定してみましょう。この機関は、CloudFront を使用して、HTTPS 接続を強制するための Strict-Transport-Security （HSTS）や、不正なデータアクセスを防ぐための Content-Security-Policy などのセキュリティヘッダーを実装することができます。CloudFront を活用することで、各バックエンドアプリケーションを変更することなく、複数のサブドメインにわたってこれらのセキュリティ対策を適用できます。このアプローチは、患者データの保護を強化しながら、セキュリティ監査の結果を改善するのに役立つ可能性があります。 この記事では、CloudFront レスポンスヘッダーポリシー、CloudFront Functions、および Lambda@Edge を使用して、CloudFront でセキュリティヘッダーを実装する 3 つの方法を紹介します。 まず、CloudFront レスポンスヘッダーポリシーについて見ていきましょう。 CloudFront レスポンスヘッダーポリシー CloudFront レスポンスヘッダーポリシーは、CloudFront が実行するヘッダーの変更を定義する際に、より細かい制御を可能にします。CloudFront レスポンスヘッダーポリシーを使用することで、カスタムコーディングや追加コストをかけずに、レスポンスがクライアントに送信される直前にヘッダーを直接追加することができます。 CloudFront レスポンスヘッダーポリシーは、マネージドポリシーまたはカスタムポリシーを使用して設定することができます。マネージドポリシーには、一般的なユースケース向けに  Amazon Web Services (AWS)  が管理する定義済みの HTTP レスポンスヘッダーのセットが含まれており、カスタムポリシーではヘッダーの値を細かく調整することができます。カスタムレスポンスヘッダーポリシーを作成する前に、マネージドレスポンスヘッダーポリシーのいずれかがご自身のユースケースに適合するかどうかを確認することをお勧めします。適合するものがあれば、それをキャッシュビヘイビアにアタッチすることができます。これにより、独自のレスポンスヘッダーポリシーを作成・管理する必要がなくなります。このセクションでは、CloudFront レスポンスヘッダーポリシーを使用して HTTP セキュリティヘッダーを追加する方法を説明します。 CloudFront レスポンスヘッダーポリシーのメニューにアクセスするには、CloudFront コンソールに移動し、左側のナビゲーションメニューから「 ポリシー 」を選択します。図 1 に示すように、「 レスポンスヘッダー 」を選択します。 図 1：CloudFront レスポンスヘッダーポリシー この画面では、 マネージドポリシー のセクションに既に SecurityHeadersPolicy が事前定義されています。図 2 に示すように、ポリシー名を選択することでポリシーの詳細を確認することができます。 図 2：マネージド SecurityHeaders ポリシーを表示している CloudFront レスポンスヘッダーポリシー このマネージドポリシーには、一般的なセキュリティヘッダーと値の定義済みセットが含まれています。定義済みのレスポンスヘッダーと値がご自身のユースケースに適合する場合は、このポリシーを CloudFront キャッシュビヘイビアにアタッチすることで、CloudFront が提供するレスポンスにこれらのヘッダーを追加することができます。マネージドレスポンスヘッダーポリシーを使用することで、独自のポリシーを作成・管理する必要がなくなります。 セキュリティヘッダーの設定を変更したり、他の目的でレスポンスヘッダーをさらに変更する必要がある場合は、他のマネージドポリシーが要件を満たしているかどうかを確認してください。どのマネージドポリシーもユースケースに適合しない場合は、図 1 に示すように右下の「 レスポンスヘッダーポリシーを作成 」ボタンをクリックしてカスタムレスポンスヘッダーポリシーを作成し、ポリシーの名前と説明を入力してください。図 3 に示すように、必要に応じて適切なセキュリティヘッダーを選択してください。 図 3：レスポンスヘッダーポリシーの作成 レスポンスヘッダーポリシーの設定が完了したら、このポリシーを使用する CloudFront ディストリビューションに移動し、図 4 に示すように該当するビヘイビアの「 編集 」を選択します。 図 4：レスポンスヘッダーポリシーを有効にするビヘイビアの選択 次の画面で、図 5 に示すように「 レスポンスヘッダーポリシー 」セクションが見つかるまで画面下部にスクロールします。前の手順で作成したマネージドセキュリティヘッダーポリシーまたはカスタムポリシーを選択し、画面下部の「 Save changes 」を選択します。 図 5：レスポンスヘッダーポリシーセクションへの SecurityHeaderPolicy の追加 新しい変更がデプロイされると、Web サイトを閲覧した際にレスポンスヘッダーにセキュリティヘッダーが表示されるようになります。 https://www.example.com/ HTTP/1.1 200 OK Connection: keep-alive Content-Type: text/html; charset=UTF-8 Date: Fri, 23 Aug 2024 03:12:49 GMT ETag: W/"773-6027e43eccd62" Last-Modified: Wed, 09 Aug 2023 14:26:28 GMT Referrer-Policy: strict-origin-when-cross-origin Server: Apache/2.4.58 (Amazon Linux) Strict-Transport-Security:max-age=31536000 Transfer-Encoding: chunked Via: 1.1 ec09137e1a146c0a7d4ba39d013ba29c.cloudfront.net (CloudFront) X-Amz-Cf-Pop: ATL58-P3 X-Cache: Miss from cloudfront X-Content-Type-Options: nosniff X-Frame-Options: SAMEORIGIN X-XSS-Protection: 1; mode=block content-encoding: gzip vary: accept-encoding これで、CloudFront レスポンスヘッダーポリシーを使用して、Web サイトにセキュリティヘッダーを問題なく設定することができました。 エッジ関数を使用したセキュリティヘッダーの追加 特定のリクエストヘッダーや Cookie が存在する場合、またはクエリ文字列に特定の値が含まれる場合など、特定の条件下でのみセキュリティヘッダーの値を動的に追加または変更する必要がある場合は、CloudFront Functions または Lambda@Edge を使用したエッジでのカスタム関数を利用することができます。CloudFront Functions と Lambda@Edge の違いおよび推奨されるユースケースについては、この デベロッパーガイド をご覧ください。 CloudFront Functions は、CloudFront エッジロケーションで軽量な JavaScript 関数をデプロイして実行するための機能です。CloudFront Functions を使用してセキュリティヘッダーを追加するには、図 6 に示すように CloudFront コンソールで「関数の作成」を選択して関数を作成する必要があります。 図 6：新しい CloudFront Functions の作成 図 7 に示すように、関数の名前と説明を入力し、ランタイムを選択します。 図 7：関数の名前と説明を入力し、ランタイムを選択する セキュリティヘッダーを追加するサンプルコードは、 aws-samples の GitHub リポジトリで見つけることができます。本番環境にデプロイする前に、 関数をテスト してください。 関数のデプロイには数秒かかります。デプロイが完了したら、 関数の関連付け手順 に従ってください。これで、CloudFront Functions を使用してセキュリティヘッダーを設定することができました。 Lambda@Edge の使用 状況によっては、CloudFront FunctionsよりもLambda@Edgeの方が適している場合があります。例えば、ビューワーレスポンストリガーにおける別の要件の実装で、Lambda@Edge でのみ利用可能な機能が必要になる場合があります。これには、ネットワーク呼び出し、サードパーティライブラリ、リクエストボディへのアクセスなどが含まれ、CloudFront Functions の使用が制限される可能性があります。 Lambda@Edge 関数を CloudFront に追加するには、この ガイドの手順 に従ってください。また、Lambda@Edge 関数は Node.js または Python を使用して記述することができます。 以下の Node.js で記述されたサンプルコードは、Lambda@Edge を使用してレスポンスに Strict-Transport-Security 、 Content-Security-Policy 、 X-Content-Type-Options 、 X-Frame-Options 、 X-XSS-Protection 、および Referrer-Policy などのセキュリティヘッダーを追加する方法を示しています。 export const handler = async (event) => { // Get contents of response const response = event.Records[0].cf.response; const headers = response.headers; // Set new headers headers['strict-transport-security'] = [{key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubdomains; preload'}]; headers['content-security-policy'] = [{key: 'Content-Security-Policy', value: "default-src 'none'; img-src 'self'; script-src 'self'; style-src 'self'; object-src 'none'"}]; headers['x-content-type-options'] = [{key: 'X-Content-Type-Options', value: 'nosniff'}]; headers['x-frame-options'] = [{key: 'X-Frame-Options', value: 'DENY'}]; headers['x-xss-protection'] = [{key: 'X-XSS-Protection', value: '1; mode=block'}]; headers['referrer-policy'] = [{key: 'Referrer-Policy', value: 'same-origin'}]; return response; }; セキュリティヘッダーによるセキュリティ強化の効果を検証する セキュリティヘッダーを追加する前後に Mozilla Observatory を使用することができます。図 8、9、10、11 に示すように、セキュリティヘッダーを追加した後はスキャンの評価が向上します。 セキュリティヘッダー追加前 図 8：セキュリティヘッダー追加前の Mozilla Observatory の評価 図 9：セキュリティヘッダー追加前の Mozilla Observatory のテストスコア また、図 10 と図 11 はセキュリティヘッダー追加後の結果を示しています。 図 10：セキュリティヘッダー追加後の Mozilla Observatory の評価 図 11：セキュリティヘッダー追加後の Mozilla Observatory のテストスコア クリーンアップ この記事の手順に従うことで、レスポンスヘッダーポリシー、CloudFront Functions、Lambda@Edge 関数、および CloudFront ディストリビューションを作成した可能性があります。これらのリソースが不要になった場合は、必ず削除するようにしてください。 まとめ この記事では、HTTP セキュリティヘッダーとは何か、そして CloudFront レスポンスヘッダーポリシー 、 CloudFront Functions 、および Lambda@Edge を使用してこれらのヘッダーを追加する方法について説明しました。この記事で説明したプロセスに従い、ユースケースに適した方法を選択することで、Web サイトのプライバシーとセキュリティを強化することができます。まず Content-Security-Policy 、 X-Frame-Options 、 Strict-Transport-Security  などの基本的なヘッダーから始め、アプリケーションの具体的なニーズに応じて段階的に保護を強化していきましょう。開発環境で十分にテストを行い、デプロイ後は互換性の問題が発生していないか監視することを忘れないようにしてください。 セキュリティは継続的なプロセスです。定期的にヘッダーを監査し、新しいセキュリティに関する推奨事項を常に把握しながら、アプリケーションの進化に合わせてポリシーを適宜見直していきましょう。 この記事に記載されているリンクから、上記の機能に関する詳細情報を確認することができます。CloudFront を初めて使用する場合は、こちらの リンク から CloudFront の詳細を確認し、使い始めることができます。 著者について Karthic Chinnannasamy Karthic Chinnannasamy は AWS のシニアエッジスペシャリストソリューションアーキテクトであり、重要な Web インフラストラクチャとセキュリティソリューションの設計においてお客様をサポートしています。境界防御と Web 高速化の専門知識を活かし、大手小売業者がセキュアで堅牢かつコスト効率の高い Web アーキテクチャを構築できるよう支援しています。 Jason Bradley Jason Bradley は、ナッシュビルを拠点とする AWS のシニアソリューションアーキテクトで、高等教育を専門としています。お客様が AWS 上でアプリケーションを効果的に設計・構築できるよう支援しています。Jason は IT および高等教育分野で 20 年以上の経験を持ち、読書や映画鑑賞、そして息子との時間を大切にしています。 翻訳は Solutions Architect の長谷川 純也が担当しました。

本記事は 2026 年 3 月 2 日 に公開された「 Standardize Amazon Redshift operations using Templates 」を翻訳したものです。 この 1 年間で Amazon Redshift は運用の簡素化と生産性向上に役立つ機能を多数リリースしてきました。今回は、データエンジニアが日々直面する運用課題の一つ、複数のデータソースに対し、似たパラメータで繰り返し実行するデータロード操作の管理に取り組みます。本記事では、 COPY コマンド の再利用可能なパラメータパターンを作成できる新機能、 Redshift Templates を紹介します。冗長な記述を減らし、データ操作全体の一貫性を高めることができます。 課題: 大量のデータ操作における繰り返し作業 架空のデータアグリゲーション企業 AnyCompany は、50 社以上の小売クライアントから顧客取引データを処理しています。各クライアントは、以下のような類似構造の区切りテキストファイルを毎日送信します。 customer transactions | product catalogs | inventory updates データ形式はクライアント間でほぼ統一されていますが (パイプ区切り、ヘッダー付き、UTF-8 エンコーディング)、データロードに必要な COPY コマンドの量が開発・保守の負担になっています。 データエンジニアリングチームが抱える課題は次のとおりです。 パラメータの繰り返し指定 : 各 COPY コマンドで区切り文字、エンコーディング、エラー処理、圧縮設定を毎回指定する必要がある 不整合のリスク : 複数のチームメンバーが COPY コマンドを記述するため、パラメータのわずかな違いがデータ取り込みの失敗につながる 保守の負担 : エラー閾値やエンコーディング設定を変更する際、ETL パイプライン全体で数百の COPY コマンドを個別に更新する必要がある オンボーディングの複雑さ : 新しいチームメンバーが必要なパラメータとその最適値をすべて把握するのが難しい さらに、一部のクライアントはやや異なる形式でデータを送信します。パイプの代わりにカンマ区切りを使用したり、ヘッダー構成が異なったりします。チームはデータロードロジックを全面的に書き換えることなく、こうした例外に柔軟に対応する必要があります。 Redshift Templates の紹介 Redshift Templates を使えば、COPY コマンドでよく使うパラメータを再利用可能なデータベースオブジェクトとして保存できます。テンプレートはデータ操作の設計図のようなもので、パラメータを一度定義すれば、複数の COPY コマンドから参照できます。 テンプレート管理のベストプラクティス 実装シナリオを見る前に、テンプレートの保守性とセキュリティに関するベストプラクティスを確認しましょう。 用途がわかる名前を付ける: CREATE TEMPLATE analytics.csv_client_data_load; CREATE TEMPLATE analytics.json_retail_data_load; 最小権限の原則を適用する: -- ロールに適切な権限を付与する GRANT USAGE FOR TEMPLATES IN SCHEMA analytics TO ROLE data_engineers; GRANT ALTER FOR TEMPLATES IN SCHEMA reporting TO ROLE senior_analysts; -- 不要なパーミッションを剥奪する REVOKE ALL ON TEMPLATE analytics.csv_load FROM PUBLIC; システムビューでテンプレートの使用状況を追跡する: SELECT database_name, schema_name, template_name, create_time, last_modified_time FROM sys_redshift_template; 各テンプレートについて以下を文書化する: 目的とユースケース パラメータの説明 所有者と連絡先 変更履歴 ソリューション概要 AnyCompany が Redshift Templates を使ってデータロード操作を効率化する方法を見ていきましょう。 シナリオ 1: クライアントデータ取り込みの標準化 AnyCompany は複数の小売クライアントから統一フォーマットの取引ファイルを受け取っています。標準的なロードパラメータをまとめたテンプレートを作成します。 -- Create a reusable template for standard client data loads CREATE TEMPLATE data_ingestion.standard_client_load FOR COPY AS DELIMITER '|' IGNOREHEADER 1 ENCODING UTF8 MAXERROR 100 COMPUPDATE OFF STATUPDATE ON ACCEPTINVCHARS TRUNCATECOLUMNS; テンプレートで定義しているパラメータは次のとおりです。 DELIMITER '|' はパイプ区切りファイルを指定 IGNOREHEADER 1 はヘッダー行をスキップ ENCODING UTF8 は文字エンコーディングを設定 MAXERROR 100 は最大 100 件のエラーを許容し、軽微なデータ品質問題への耐性を確保 COMPUPDATE OFF はロード中の自動圧縮分析を無効にしてパフォーマンスを向上 STATUPDATE ON はクエリ最適化のためにテーブル統計を最新に維持 ACCEPTINVCHARS は無効な UTF-8 文字をエラーにせず置換 TRUNCATECOLUMNS は列幅を超えるデータをエラーにせず切り詰め 標準的なクライアントからのデータロードはシンプルになります。 -- Load transaction data from Client A COPY transactions_client_a FROM 's3://amzn-s3-demo-bucket/client-a/transactions/' IAM_ROLE default USING TEMPLATE data_ingestion.standard_client_load; -- Load transaction data from Client B COPY transactions_client_b FROM 's3://amzn-s3-demo-bucket/client-b/transactions/' IAM_ROLE default USING TEMPLATE data_ingestion.standard_client_load; -- Load product catalog from Client C COPY products_client_c FROM 's3:// amzn-s3-demo-bucket/client-c/products/' IAM_ROLE default USING TEMPLATE data_ingestion.standard_client_load; 各 COPY ステートメントで指定するのは以下の 4 つだけです。 ターゲットテーブル Amazon Simple Storage Service (Amazon S3) の格納場所 認証用の デフォルト AWS Identity and Access Management (IAM) ロール テンプレートの参照 フォーマットやエラー処理のパラメータはテンプレートにまとめられているため、データロード全体で一貫性を保てます。 シナリオ 2: パラメータオーバーライドによるクライアント固有の差異への対応 AnyCompany には、パイプ区切りではなくカンマ区切りのファイルを送信するクライアント (Client D と E) がいます。テンプレートを一から作り直す代わりに、既存の設定を活かしつつ特定のパラメータだけをオーバーライドできます。 -- Load data from Client D with comma delimiter (overriding template) COPY transactions_client_d FROM 's3://amzn-s3-demo-bucket/client-d/transactions/' IAM_ROLE default DELIMITER ',' -- デリミターをオーバーライド USING TEMPLATE data_ingestion.standard_client_load; -- Load data from Client E with comma delimiter and no header COPY transactions_client_e FROM 's3://amzn-s3-demo-bucket/client-e/transactions/' IAM_ROLE default DELIMITER ',' -- デリミターをオーバーライド IGNOREHEADER 0 -- ヘッダー文字列をオーバーライド USING TEMPLATE data_ingestion.standard_client_load; Redshift Templates のパラメータ優先順位は次の順とおりです。 コマンド固有のパラメータ (最も優先される) : COPY コマンドで明示的に指定したパラメータが最優先 テンプレートパラメータ (次に優先される) : オーバーライドされていない場合、テンプレートで定義されたパラメータを使用 Amazon Redshift のデフォルトパラメータ : コマンドにもテンプレートにも指定がない場合、デフォルト値を適用 3 層の優先順位により、標準化と柔軟性を両立できます。重要な部分では一貫性を維持しつつ、例外にも適切に対応できます。 シナリオ 3: テンプレート保守の簡素化 テンプレート導入から 6 か月後、AnyCompany のデータ品質チームは、上流システムからのデータ品質の問題に対応するため、エラー閾値を 100 から 500 に引き上げることを推奨しました。テンプレートを使えば、変更は簡単です。 -- Update the template to increase error tolerance ALTER TEMPLATE data_ingestion.standard_client_load SET MAXERROR TO 500; コマンド 1 つで、テンプレートを使用する今後のすべての COPY 操作のエラー処理動作が即座に更新されます。数百の ETL スクリプトを調べたり、一部のパイプラインで更新漏れが発生するリスクもありません。要件の変化に応じて新しいパラメータを追加することもできます。 -- Add compression parameter to improve load performance ALTER TEMPLATE data_ingestion.standard_client_load ADD GZIP; 不要になったテンプレートを削除するには次のようにします。 DROP TEMPLATE data_ingestion.standard_client_load; シナリオ 4: 開発環境と本番環境で異なるテンプレート AnyCompany は開発環境と本番環境でエラー許容度の異なるテンプレートを使い分けています。 -- Development template with lenient error handling CREATE TEMPLATE data_ingestion.dev_client_load FOR COPY AS DELIMITER '|' IGNOREHEADER 1 ENCODING UTF8 MAXERROR 1000 -- More lenient for testing COMPUPDATE OFF STATUPDATE OFF; -- Skip stats updates in dev -- Production template with strict error handling CREATE TEMPLATE data_ingestion.prod_client_load FOR COPY AS DELIMITER '|' IGNOREHEADER 1 ENCODING UTF8 MAXERROR 50 -- Stricter for production COMPUPDATE OFF STATUPDATE ON; -- Keep stats current in prod 開発環境と本番環境でテンプレートを分けることで、本番ではデータ品質の問題を早期に検出しつつ、開発・テスト時には柔軟に対応できます。 主なメリット テンプレートの主なメリットは次のとおりです。 一貫性と標準化 : テンプレートにより、同じパラメータと設定が毎回使用されるため、操作間の一貫性を維持できます。複数のユーザーが同じデータパイプラインを扱う大規模な組織で特に有効です。 使いやすさと時間の節約 : 毎回パラメータを手動で指定する代わりに、定義済みのテンプレートを参照するだけで済みます。手入力によるミスも減らせます。 パラメータオーバーライドによる柔軟性 : テンプレートで標準化しつつも、例外や特殊なケースでは COPY コマンドでパラメータを直接オーバーライドできます。 保守の簡素化 : パラメータや設定の変更が必要な場合、テンプレートを更新するだけで、すべての利用箇所に変更が反映されます。個々のコマンドを手動で更新する場合と比べて、保守の手間を大幅に削減できます。 コラボレーションとナレッジ共有 : テンプレートはナレッジベースとして機能し、経験豊富なユーザーが開発したベストプラクティスや最適な設定を蓄積できます。新メンバーのオンボーディングを促進し、学習コストを下げつつ実績ある設定を一貫して利用できます。 業界別のユースケース テンプレートはさまざまな業界で活用できます。 金融サービス: 規制データロードの標準化 金融機関が複数の支店から統一フォーマットの取引データをロードする場合の例です。 -- Create template for branch transaction loads CREATE TEMPLATE compliance.branch_transaction_load FOR COPY AS FORMAT CSV DELIMITER ',' IGNOREHEADER 1 ENCODING UTF8 DATEFORMAT 'YYYY-MM-DD' TIMEFORMAT 'YYYY-MM-DD HH:MI:SS' MAXERROR 0 -- Zero tolerance for compliance data COMPUPDATE OFF; -- Load data from different branches COPY branch_transactions_east FROM 's3://amzn-s3-demo-source-bucket/east-branch/transactions/' IAM_ROLE default USING TEMPLATE compliance.branch_transaction_load; COPY branch_transactions_west FROM 's3://amzn-s3-demo-source-bucket/west-branch/transactions/' IAM_ROLE default USING TEMPLATE compliance.branch_transaction_load; ヘルスケア: 厳格な基準に基づく患者データのロード ヘルスケア分析企業が複数の病院システムからの患者データ取り込みを標準化する例です。 -- Create template for HIPAA-compliant data loads CREATE TEMPLATE healthcare.patient_data_load FOR COPY AS FORMAT CSV DELIMITER '|' IGNOREHEADER 1 ENCODING UTF8 ACCEPTINVCHARS TRUNCATECOLUMNS MAXERROR 10 COMPUPDATE OFF; -- Apply to different hospital systems COPY hospital_a_patients FROM 's3://amzn-s3-demo-destination-bucket/hospital-a/patients/' IAM_ROLE default USING TEMPLATE healthcare.patient_data_load; COPY hospital_b_patients FROM 's3://amzn-s3-demo-destination-bucket/hospital-b/patients/' IAM_ROLE default USING TEMPLATE healthcare.patient_data_load; 小売: JSON データロードの標準化 小売企業がさまざまなサプライヤーから JSON 形式の商品カタログを処理する例です。 -- Create template for JSON product data CREATE TEMPLATE retail.json_product_load FOR COPY AS FORMAT JSON 'auto' TIMEFORMAT 'auto' ENCODING UTF8 MAXERROR 100 COMPUPDATE OFF; -- Load from different suppliers COPY products_supplier_a FROM 's3://amzn-s3-demo-logging-bucket/supplier-a/products/' IAM_ROLE default USING TEMPLATE retail.json_product_load; COPY products_supplier_b FROM 's3://amzn-s3-demo-logging-bucket/supplier-b/products/' IAM_ROLE default USING TEMPLATE retail.json_product_load; まとめ 本記事では、Redshift Templates を紹介し、さまざまなシナリオでデータロード操作を標準化・簡素化する方法を示しました。よく使う COPY コマンドのパラメータを再利用可能なデータベースオブジェクトにまとめることで、繰り返しのパラメータ指定をなくし、チーム間の一貫性を確保し、保守を一元化できます。要件が変わった場合も、テンプレートを 1 回更新するだけで変更がすべての操作に反映されるため、運用負荷を抑えつつパラメータオーバーライドによる柔軟性も維持できます。 Redshift Templates を使ってデータ取り込みワークフローを改善しましょう。まずは最もよく使うデータロードパターンでテンプレートを作成し、徐々にパイプライン全体に適用範囲を広げてください。コードの見通しが良くなり、オンボーディングが速くなり、保守が楽になります。Redshift Templates の詳細や追加の設定オプションについては、 Amazon Redshift のドキュメント を参照してください。 著者について Nidhi Nayak Nidhi は、AWS のシニアテクニカルアカウントマネージャー兼データ分析スペシャリストです。分析およびデータサービスに関する深い専門知識を持ち、パフォーマンス、スケーラビリティ、コスト効率に優れたクラウドアーキテクチャの最適化を支援しています。 Raza Hafeez Raza は、Amazon Redshift のシニアプロダクトマネージャーです。エンタープライズデータウェアハウスの構築と最適化に 13 年以上の経験を持ち、お客様がデータの力を最大限に活用できるよう支援しています。エンタープライズデータウェアハウスの AWS Modern Data Architecture への移行を専門としています。 Raks Khare Raks は、ペンシルベニア州を拠点とする AWS のシニアアナリティクススペシャリストソリューションアーキテクトです。さまざまな業界や地域のお客様が AWS プラットフォーム上で大規模なデータ分析ソリューションを構築するのを支援しています。仕事以外では、新しい旅行先やグルメスポットの開拓、家族との時間を楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Akira Shimosako がレビューしました。

この記事は、Amplify Japan User Group の池田 健人 氏 ( @ikenyal ) に寄稿いただきました。 こんにちは、AWS Community Builder 兼 AWS User Group Leaders、そしてAmplify Japan User Groupの運営メンバーであり「AWS Amplify Conference 2026 by Amplify Japan User Group」の実行委員長の池田（ @ikenyal ）です。 2026年1月20日（火）、Amplify Japan User Groupは日本で初となるAWS Amplifyの年次カンファレンス「AWS Amplify Conference 2026 by Amplify Japan User Group」を目黒セントラルスクエアにて開催しました。どうやら、日本初だけでなく、世界でもAWS Amplifyの年次カンファレンスは初のようです。 構想から準備まで、運営チーム一丸となって走り抜けたこのイベント。当日は多くの方にご来場いただき、まさに「Amplifyの熱量」が凝縮された1日となりました。 今回は、初開催となった「AWS Amplify Conference 2026 by Amplify Japan User Group」の目的と当日の様子をお伝えします。 開会挨拶（Amplify Japan User Group・カンファレンス実行委員長 池田 健人・アマゾン ウェブ サービス ジャパン合同会社 常務執行役員 技術統括本部長 巨勢 泰宏） イベント当日の開会挨拶にて、本カンファレンスの目的をお伝えしました。 開催日時：2026年1月20日(火) 10:00–17:00・懇親会 17:30–19:30 会場：目黒セントラルスクエア 21F セミナールーム 主催：Amplify Japan User Group Amplify Japan User Group主催となる初のAmplifyの年次カンファレンスが始動し、今回がその初回です。 「AWS Amplify Conference 2026 by Amplify Japan User Group」では「新規事業を加速させるAmplifyの魅力を探る」というテーマを掲げています。 Amplifyは「スタートアップでリソースが少ない環境でもアプリケーションを作れるもの」と思われることも多いですが、エンタープライズ企業・大企業においても、社内の新規事業の立ち上げや効果検証を高速に実施する武器としても大いに役立ちます。 今回のカンファレンスでは、是非そのような大企業の方々にもAmplifyの良さ・有用性を感じ取っていただき、このAmplifyのユーザーコミュニティをスタートアップ・エンタープライズの垣根なく拡大させて盛り上げていきたい思いもこめたテーマです。 なお、スライドでも利用しているカンファレンスのロゴですが、海外からも「日本のAmplifyカンファレンス行きたい」と思ってもらえるよう、「日本らしさ」を意識し、カタカナや富士山をあしらい、Amplifyのモチーフのロケットを添えたデザインになっています。 カンファレンスは1日かけてAmplifyの理解を深め、明日からの活用イメージを持っていただけるよう、様々なコンテンツをご用意しました。 午前のハンズオンでまずは体験していただき、午後には米国からAmplifyの開発を行っているプロダクトチームによる登壇や、実際にAmplifyを活用している企業の事例・ノウハウを学べる時間をご用意しました。また、最後には懇親会も開催しました。 ※当日は都合により一部登壇者・登壇内容に変更がありました そして、開会挨拶の締め括りとして、アマゾン ウェブ サービス ジャパン合同会社 常務執行役員 技術統括本部長の巨勢さんからご挨拶・メッセージをいただきました。ご挨拶の後、ハンズオンの様子もご覧になったり、本カンファレンスに強い関心を抱いていただいていたのが印象的であり、実行委員長として感慨深い光景でした。 ハンズオン（講師：Amplify Japan User Group 足立 優司） 午前中のコンテンツはハンズオン。 Amplify Japan User Group運営の足立が講師を務めました。この日のために足立が中心となり、ハンズオンの内容を作成しました。 この「AWS Amplify Gen2 ハンズオン ― Dev ToolとAIが変える、次世代アプリケーション開発体験 ―」というハンズオンでは、AWS Amplify Gen2を用いて、ログイン機能付きのTodoアプリケーションを実装しながら、フロントエンドからバックエンド、デプロイまでの一連の開発フローを体験できるよう設計されています。 ハンズオン資料は公開されていますので、是非体験してきてください。 https://github.com/ototrip-lab/amplify-gen2-workshop 本ハンズオンのポイントは大きく三つあります。 1. Amplify Gen2を「実装レベル」で習得 宣言的なバックエンド定義、フロントエンドとの連携、開発フロー全体を実際に手を動かしながら学べます。 Qiitaなどで公開されているAmplify Gen2の最新記事を読んで「何をしているのか」「なぜこう書くのか」が理解できる状態を目指します。 2. Dev Tool開発体験（Kiro × AWS MCP サーバー） Kiro CLIとAWS MCPサーバーを組み合わせた、AI支援を前提とした最新のdev toolチェーンを実プロジェクト形式で体験できます。 AIによるガイド付き実装 Amplify Gen2の設計・実装を考えながら進める開発体験 単なるコード生成に留まらない、実務を意識したAI活用 「AIをどう開発に組み込むか」を具体的に掴める内容です。 3. 事前準備はアカウント登録だけ 参加前に必要なのは、以下の三つのアカウントを用意するだけです。 AWSアカウント AWS Builder ID GitHubアカウント GitHub Codespacesを利用するため、ローカル環境構築や複雑なセットアップは不要です。 すぐにハンズオンに集中できます。 特に、三つ目に挙げた事前準備の簡略化はワークショップ形式のハンズオンでは非常に重要なポイントです。当日は実際に手を動かす時間が一番大切なため、可能な限り準備に困らないよう意識したハンズオン設計になっています。 Amplifyセッション 午後のセッションは「Amplifyセッション」と「事例紹介セッション」の二部構成です。最初に「Amplifyセッション」としてAmplifyに関する知識を習得したうえで、後半の「事例紹介セッション」でより具体的なイメージを掴められるよう構成しています。 Amplify入門（アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 稲田 大陸） SA 稲田さんからは「AWS Amplify入門 仕様からリリースまで一気通貫 生成AI時代のフルスタック開発」というテーマでAmplifyを用いたモダンな開発の流れを伝える内容でした。 Kiroの由来が「岐路」だという話は聞いたことありましたが、それはプロジェクトのコードネームがそのままプロダクト名になったこと。Kiroのお化けキャラクターは開発中に社内でも極秘開発されていた際に「バレないようにお化け」にしていたものが、これもそのまま公式のキャラクターになったこと。Kiroが「AWS Kiro」でも「Amazon Kiro」でもないのは、AWSに関係なく幅広く使えるツールであることを示すために何も頭につかない「Kiro」になったこと。公式ドキュメントからは知ることのできない、たくさんのKiroトリビアも披露していただきました。 https://speakerdeck.com/inariku/aws-amplify-conference-2026-shi-yang-kararirisumade-qi-tong-guan-sheng-cheng-ai-shi-dai-nohurusutatukukai-fa コミュニティ紹介（Amplify Japan User Group・カンファレンス実行委員長 池田 健人） 本カンファレンスを主催するコミュニティ「Amplify Japan User Group」の紹介をしました。 「Amplify Japan User Group」はAWS Amplifyの利用者・開発者が主体となり、相互にAWS Amplifyの利用・開発をサポートするために、主に日本国内で活動するグループです。 2020年にコミュニティSlackがAWS主導で開設され、2021年にコミュニティのWebサイトが開設されました。 そして、このコミュニティは日本で三つしかないAWS公認コミュニティの一つだというのも特徴です。 JAWS-UG Amplify Japan User Group AWS Startup Community コミュニティでは主に三つの領域の活動をしています。 一つ目が「交流の場の提供」です。 Amplify利用者、なかにはコントリビュータの人もいたりしますが、その参加者が交流、質問、相談をできる場として用意しています。 コミュニティの初期の頃はSlackで提供していましたが、運用上Slackも無料プランを使わざるを得ない状況だと過去ログが見えなくなる点が懸念として上がり、今も継続しているDiscordに移行しました。 イベント情報もDiscordでご案内しますので、是非Discordにご参加ください。 https://discord.gg/2wVQ2D53Na 二つ目は「情報の提供」です。 Webサイトを公開しており、イベント情報、イベントレポート、学習リソースなどの情報をまとめています。 なお、このサイトは管理者が一方的に情報提供をするものではなく、コミュニティ全体で作り上げていくものなので、是非コンテンツ追加のPull Requestをお願いします。 そのようなPull Requestも立派なコミュニティ参加ですので、お気軽にトライしてみてください。 https://aws-amplify-jp.github.io/ そして三つ目が「ミートアップ・カンファレンスの開催」です。 年に数回のオンラインミートアップの開催と、年に1度のオフラインカンファレンスを提供しています。 ミートアップに関しては登壇者を募集する形式なので、Amplifyを使ってみて得られた知見やノウハウを是非発表してみてください。 ここまででご紹介したDiscord、イベント、登壇に関するリンクはこちらの通りですので、是非コミュニティ活動にご参加ください。 Discord https://discord.gg/2wVQ2D53Na Amplify Boost Up ・カンファレンスへの参加 https://aws-amplify-jp.connpass.com/ Amplify Boost Up での登壇 https://github.com/aws-amplify-jp/amplify-meetup-cfp そして、これらを支えるのがコミュニティの運営です。 本カンファレンスの開催も含め、全員ボランティアで運営をしています。 以前にこの運営体制の記事を出したので是非ご興味ありましたらご覧いただければと思います。 https://zenn.dev/ikenyal/articles/75637f3d3ce52a また、本カンファレンスですが、ここに掲載している運営メンバーを中心にAWSの社員の方々にもご支援・ご協力いただいて開催できております。改めて関係者の皆さま、そして参加者の皆さまに感謝の意を表します。 The Future of Amplify Gen2 And How We’re Bringing Everyone Along（AWS Amplify Product Team, Senior Product Manager Praneeta Prakash・Software Development Manager Joey Wang） 米国から来日中のAmplifyプロダクトチームのPraneetaさんとJoeyさんによる講演です。 英語による講演でしたが、Zoomのリアルタイム翻訳とDiscordによる要約による言語サポートを実施しました。 Joeyさんからは、まだまだAmplify利用者としてもGen1利用者が多いなか、Gen2の特徴を改めて伝えるものでした。 そして、まだ公開された間もないGen1からGen2へのマイグレーションツールの紹介もありました。 https://github.com/aws-amplify/amplify-cli/blob/gen2-migration/GEN2_MIGRATION_GUIDE.md Praneetaさんからは、Amplifyのロードマップに関するメッセージがありました。 生成AIの進歩によってAmplifyはどう変化していくのか。AmplifyはGen2ではAWS CDKをネイティブサポートしています。それによって、AIがより読みやすくなり、AIからの利用が容易になっています。 CDKとAmplifyは距離の近い隣のチームで開発されています。CDKを初日で分かる人は少ないかもしれませんが、AmplifyはAWSを知らなくても使えるようにしていくことを引き続き目指していきます。 事例紹介セッション 午後の後半は「事例紹介セッション」として、実際にAmplifyを利用している企業・プロダクトの事例紹介を行いました。 サイトの本番公開までにあと2ヶ月しかなかった時（株式会社すかいらーくホールディングス 福田 誠） すかいらーくホールディングス 福田さんからは、リリースまでに2ヶ月という期間しかない状況において、Amplifyによってそれをどう実現したかというお話でした。 そして、福田さんは午前のハンズオンに参加され、その時間に開発したルーレットで会場参加者向けにプレゼント企画も実施していただきました。 ADRで「なぜ」を残す開発：AWS Amplifyで実現した薬局のWEB問診票（株式会社エムティーアイ Leinikka Marko Kristian） エムティーアイのLeinikkaさんの発表です。 ADRを残す大切さや、Nuxtのサポートやプレビュー環境の自動構築等のAmplifyを選定した理由を、許容したポイントも添えて紹介いただきました。 クラウド知識ゼロからAmplifyで始める新規事業サービス開発（三菱電機株式会社 的場 祐弥） 三菱電機の的場さんからは、AWSもクラウドもReactも、何も知らない状態からAmplifyで新規事業へ挑戦してリリースまで果たし、そこからより深いAWSの理解や継続開発につなげていったお話をいただきました。 初めてのモバイルアプリ内製化：Amplifyを用いたバックエンド開発の道のり（シチズン時計株式会社 Rudolf Yoga Hutama・シチズン・システムズ株式会社 浅原 一葉） シチズン時計のRudolfさんとシチズン・システムズの浅原さんによる発表です。 外部委託していたアプリを内製化する際に、育成のためにフロントエンド開発とバックエンド開発の期間を分けて開発する計画を策定。結果としては1ヶ月の開発期間の短縮に成功し、その短縮できた期間でスコープ外にしていたログイン機能を追加開発を実現させました。 質疑応答 当初予定していたピュアポムメディアラボ 青木さんが都合により来場が間に合わなくなり、質疑応答の時間を設けました。 予定していなかった質疑応答コーナーですが、会場からは続々と質問をいただき盛り上がりました。笑顔もあふれる質疑応答の時間になりました。 懇親会 イベントの最後は懇親会も開催。参加者・登壇者・運営が一緒になって会話や食事を楽しみました。 おわりに 今回は年次カンファレンスの立ち上げという貴重な体験をすることができました。結果として、多くの皆さまに参加いただき、楽しんでいただけて一安心しております。参加者アンケートでも、5段階のうち、すべての回答が4以上の評価でした。さらには7割の方に5点満点評価をいただきました。 これも、参加いただいた参加者の皆さま、登壇者の皆さま、そして運営メンバーだけでなくご支援・ご協力いただいたAWSの皆さまのおかげです。 来年はさらにパワーアップしたカンファレンスになるよう頑張りたいと思います！ 著者について 池田 健人（Ikeda, Kento） AWS Community Builder、AWS User Group Leaders。Amplify Japan User Group 運営メンバー、AWS Amplify Conference 2026 実行委員長。 和智 大二郎（Wachi, Daijiro） アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト

本記事は、2026年1月12日に公開された ” Building Intelligent Network Operations Agent with Amazon Bedrock AgentCore ” を翻訳したものです。 深夜2時、バージニア北部 リージョン にてお客様のトランザクション処理が失敗したというアラートが、あなたのスマートフォンに届きました。Amazon Web Services (AWS)上で画像処理プラットフォームを管理するネットワーク運用者のあなたは、複雑なアーキテクチャのトラブルシューティングを迫られます。このネットワークは、複数の Amazon Virtual Private Cloud (Amazon VPC) が AWS Transit Gateway で相互接続されており、その上で多数のマイクロサービスが実行されています。根本原因の可能性は多岐にわたり、セキュリティグループの設定ミスからNetwork Access Control List (NACL) の問題、 AWS Network Firewall ルールが正当なトラフィックをブロックしているかもしれません。このようなシナリオは現在のクラウド環境においてますます一般的になっており、複雑なネットワークトポロジが復旧時間を長引かせる要因となっています。 今日のAWSユーザーが運用する環境は、複数のAWSリージョンにわたる数百ものVPCを含むことが珍しくありません。それぞれのVPCには独自のセキュリティ設定、Network Firewallポリシー、Transit Gatewayを介した複雑なルーティングが組み込まれています。接続障害が発生すると、運用チームは通常、 VPCフローログ 、 Amazon CloudWatch メトリクス、 AWS Reachability Analyzer の検出結果、アプリケーションログなど、膨大なデータソースを横断して調査しなければなりません。その結果、トラブルシューティングが長期化し、解決に向けたアプローチも担当者によってばらつきがちです。本記事では、 Amazon Bedrock AgentCore のAI機能をAWSのネットワーキングサービスと統合し、高度なネットワーク運用エージェントを構築する方法を解説します。セキュリティや運用水準を満たしながら、診断と修復を自動化する手法を探ります。 エージェントの構成要素 レゴブロックを組み合わせて複雑な構造を作るのと同様に、エージェントベースのソリューションも複数のモジュール化されたコンポーネントを組み合わせて構築されます。各モジュールには特定の役割があり、それらを適切に組み合わせることで、組織のニーズに合わせて適応・拡張できる、堅牢で柔軟なネットワーク運用システムが構築されます。図1に、このようなエージェントに必要な構成要素を示します。 図1: ネットワーク運用エージェントの構成要素 Interface＆Integration ブロックは、ユーザーとシステムを繋ぐ主要な接点として機能します。自然言語処理やマルチモーダル入力をサポートすると同時に、AWSサービスとのシームレスな連携を可能にします。具体的には、自然言語のクエリを構造化コマンドに変換し、 AWS SDKによる直接的なAPI連携 、 AWS Lambda 統合、 モデルコンテキストプロトコル(MCP)サーバーベースの統合 機能を介してサービス間接続を管理します。 Security＆Operations ブロックは、 Amazon Bedrock AgentCore Identity 、 AWS Identity and Access Management (IAM) ロール、 Prompt Engineering 、 Amazon Bedrock AgentCore Policies を用いて包括的な保護を実装します。同時に、 Amazon CloudWatch を通じて、モニタリング、アラート、自動修復を管理します。このブロックは、安全な運用とプロアクティブな問題検出を保証します。認証と認可からコンテンツフィルタリング、監査ログに至るまで、多層的なセキュリティコントロールを実装することで機能します。 Intelligence ブロックは、 Amazon Nova 、 Claude Sonnet 4 、 Llama などの 基盤モデル(FM) を利用した認知エンジンとして機能します。これには、高度なChain-of-Thought(思考の連鎖)プロンプティングと ReAct(Reason+Act)機能が組み込まれています。このブロックは、複雑なネットワーク運用に求められる、中核となる推論や意思決定能力を提供するために必要です。大規模言語モデル(LLM)機能とプランニング・コンポーネントを組み合わせ、短期的な運用のコンテキストと長期的に学習されたパターンの両方を維持しながら、複雑なタスクを管理可能なステップにまで細分化することができます。 Orchestration ブロックは、 Strands 、 LangGraph 、 CrewAI などのフレームワークを用いて、ワークフロー実行を調整し、異なるコンポーネント間の相互接続を管理します。このコンポーネントにより、複雑な多段ステップの処理を可能にしながら、様々なコンポーネント間をスムーズに連携できます。複数のエージェントが連携する必要がある場合は、タスクの分解、並列処理、エージェント間通信を管理することで実現します。 Memory ブロックは、エージェントの作業メモリとして機能し、短期的なセッションのコンテキストと、長期的に学習されたパターンの両方を保持します。これは、パーソナライズされ、かつ状況をくみ取った対話を実現するために必要です。 Agent Core Memory を利用した短期的・長期的なメモリ戦略を使い分けることで、複数のセッションにわたって関連する文脈を維持しながら、会話履歴やユーザーの好みを保存できます。これらの機能は、十分な情報に基づいた意思決定と、個々のユーザーに最適化された対話を行うために極めて重要です。 Deployment ブロックは、AgentCoreランタイムを介することで、組織のニーズに最適な実装アプローチを選択できます。フルマネージド型のインフラストラクチャや、カスタム実装ができる柔軟な基盤を提供します。 Evaluation ブロックは、パフォーマンスを評価するためのAI駆動型テスト フレームワーク を提供します。このブロックは内部的にLLMエージェント( evaluator) を実装しており、独自のエージェント( target) との会話をオーケストレーションして会話中の応答を評価します。このブロックは、様々なシナリオをシミュレートし、エージェントの応答を期待値と比較することで、品質を維持し、一貫した動作を保証します。 これらのビルティングブロックは、それぞれが独立しながらも、相互に連携できるように設計されています。まずは基本のブロックから始めて不可欠な機能を構築し、ニーズの拡大に合わせてより高度な要素を追加していくことが可能です。実装を成功させる鍵は、単に適切なブロックを揃えることだけではなく、それらをいかに組み合わせるかにあります。モジュールを選択・統合する際は、組織固有のニーズ、技術力、そして将来の成長計画を考慮して下さい。まずは最も差し迫った課題を解決するために必要最小限の要素から着手し、チームがシステムに慣れるにつれて、段階的に高度なモジュールを追加していくのが良いでしょう。重要なのは、各モジュール間のインターフェースをクリーンに保ちつつ、それらがシームレスに連携できるようにすることです。 ネットワーク運用エージェントの実装：理論から実践へ 本セクションでは、これまで述べてきた理論上の構成要素が、実際のシナリオを通じてどのように具体的な実装へ落とし込まれるかを説明します。対象シナリオは、図2に示す通り、バージニア北部リージョンでホストされている画像処理アプリケーションに影響を及ぼす、重大なネットワーク接続障害のトラブルシューティングです。 ExampleCorp の画像処理アプリケーション 図2: ExampleCorpの画像処理アプリケーション Amazon Route 53がDNSリクエストを処理します。画像処理アプリケーションのフロントエンドには、Application Load Balancer(ALB)を介してアクセスします。ALBは、バックエンドアプリケーションとして機能するサーバーレスのLambda関数にトラフィックを分散します。 Lambda関数は、ユーザーのリクエストに基づいてS3バケットから画像を取得し、レンダリングを行います。サーバーレスなアーキテクチャのため、手動によるスケーリングなしで、並列の画像レンダリング処理が可能です。 専用のDBサブネットに配置されたAmazon RDSには、利用データやプラットフォーム分析結果が保存されます。このデータベースは、プラットフォーム全体で画像がどのようにアクセスされ、利用されているかを追跡します。 レポートサーバーは、利用レポートやパフォーマンスメトリクスを生成します。適切なサブネットを経由したルーティングによりRDS内データに安全にアクセスし、基幹業務に影響を与えることなくプラットフォーム分析を行います。 ネットワーク構成にはVPC による分離を採用し、アプリケーションコンポーネントとレポートコンポーネントを切り離しています。AWS Transit GatewayがVPC 間のセキュアな通信を可能にし、専用サブネット(App、Reporting、DB)によって各サービス間に明確なセキュリティ境界を確立しています。 Amazon Bedrock AgentCore Runtimeによるトラブルシューティングの自動化 ワークフローは、図3に示す以下のステップに従います。 図3: Amazon Bedrock AgentCoreベースのアプローチ チャットクライアントはAmazon Cognito を介して認証され、ユーザーはJWTトークンを添えて質問を送信します。 AgentCoreランタイムはトークンを検証し、Claude 4.0 Sonnetモデルを活用して会話を処理します。 AgentCore Gatewayは、MCPプロトコルを通じてツールへの安全なアクセスを提供します。 AWS Lambda Targetは、適切な認証のもとでAWSサービスの操作を実行します。 AgentCore Identityは、ワークロードの認証とトークン交換を担います。 AgentCore Observabilityは、包括的なモニタリング、メトリクス、およびログ記録機能を提供します。 Amazon AgentCoreを使用したネットワーク接続トラブルシューティングのユースケースを実装するための詳細なデプロイ手順は、 sample-building-network-ops-agent-with-amazon-bedrock-agentcore にて公開されています。 まとめ Amazon Bedrockを搭載したインテリジェントなネットワーク運用エージェントの導入は、クラウドインフラストラクチャ管理への革新的なアプローチであり、大きなビジネス価値をもたらします。平均復旧時間 (MTTR)を数時間から数分に短縮し、24時間365日体制の自律診断を可能にすることで、運用コストを抑えつつビジネスを継続できます。 モジュール式のビルディングブロックを実装することで、組織がいかにAIを活用してネットワーク運用とインシデント解決を効率化できるかを示しました。これらのエージェントはAWSサービスと統合されており、Claude Sonnet 4などのFMを使用して複雑なネットワークシナリオを理解して診断を自動化し、堅牢なセキュリティ制御を維持しつつ状況に応じた推奨事項を提供します。 しかし、AIエージェントが常に最適なソリューションであるとは限りません。AIエージェントは、文脈の理解や自然言語での対話を必要とするような、複雑で多段階な操作には優れていますが、より日常的な運用タスクには従来のサーバーレスAPIベースのシステムの方が適している場合があります。例えば、セキュリティグループの定期的な更新や明確な入出力を持つスケジュールされたバックアップ操作は、直接のAPI呼び出しにより効率的に処理できるため、エージェントインフラストラクチャを使う場合のオーバーヘッドを回避できます。高度なトラブルシューティングシナリオにはエージェントを使用し、日常的な運用にはサーバーレス機能を維持するといったハイブリッドアプローチを採用することが、多くの組織の成功に繋がっています。 AIの機能は進化を続けていますが、導入を成功させるためには現実の状況に合わせる必要があります。まずはエージェントの機能が真に活かせる、具体的で価値の高いユースケースから始め、運用ニーズや複雑さに応じて段階的に拡張して下さい。このようなバランスの取れたアプローチを取ることで、組織はより回復力のある効率的なネットワーク運用を構築でき、チームはビジネス価値を高める戦略的な取り組みに集中できるようになります。 準備はいいですか？ 次にできることは以下の通りです： Amazon Bedrock AgentCore のドキュメント を確認する AWS GitHub リポジトリ でユースケースをチェックする Amazon Bedrock AgentCore や Strands Agents のワークショップで実践的に学ぶ （訳者注：リンク先システムの仕様が変更されています。 Builder Center のWorkshopsメニューより、キーワード検索にてご利用ください） 翻訳はSolutions Architectの田中が担当しました。原文は こちら です。

プロスポーツの世界では、わずかな差が勝敗を分けることが多いです。世界中のチームが、選手のパフォーマンス最適化、怪我の軽減、競争優位性の獲得のために、データを利用したインサイトに注目しています。 Catapult Sports は、プロチームがデータに基づいた意思決定を行えるよう支援するスポーツテクノロジー企業です。 AWS IoT サービスを活用することで、Catapult はチームがデータを収集・分析・活用する方法を変革しています。 Catapult は、プロチームが選手の健康を最適化し、怪我を減らし、人間運動科学に流用するために必要なデータ駆動型インサイトを提供しています。世界 24 拠点に 500 名以上のスタッフを擁し、 128 カ国 40 以上のスポーツにおいて 5,000 以上のプロチームにサービスを提供しています。これには NFL 、NHL 、イングランドプレミアリーグのトップフランチャイズも含まれます。 挑戦：エリートスポーツの要求に応える プロスポーツチームは高いプレッシャーの中で活動しています。試合や練習中にリアルタイムのインサイトを生成する選手モニタリング技術を利用しており、選手やコーチにパフォーマンス向上のための貴重な情報を提供しています。この技術を導入するにあたり、チームとしては、即座に導入できること、円滑なアップデート、国をまたいだリモート管理、そして重要な場面でのデバイス障害や設定ミスに対するゼロトレランス( 許容ゼロ ) つまり、重要な局面では必ず利用ができることを期待し導入します。 スポーツアナリティクスがますます高度化する中、チームは競争優位性をもたらす新機能、強化されたアルゴリズム、改善機能へのより迅速な利用も求められています。スポーツテクノロジープロバイダーにとっての課題は、迅速に革新するための俊敏性を維持しながら、エンタープライズグレードの信頼性を提供することです。 ソリューション：AWS IoT を基盤とした Vector 8 これらの厳しい要件を満たすために、Catapult は AWS IoT サービスを利用した次世代選手モニタリングソリューション「 Vector 8 」を開発しました。Vector 8 スイートは4つの主要コンポーネントで構成されています。 Vector 8 Tag : 選手がトレーニングや試合中に装着するコンパクトで頑丈なウェアラブルデバイスです。屋内外での精密な位置追跡、選手の動きやスポーツ固有のイベントのキャプチャ、サードパーティ Bluetooth センサーとの統合、超広帯域（UWB）通信をサポートします。バッテリー駆動時間は最大6時間です。 Vector 8 Dock : Vector 8 Tag を充電しデータを同期するために使用します。高速 Wi-Fi ダウンロードとクラウドへの直接データ同期を可能にし、30個の Vector 8 Tag の容量と並列アップロード機能により、データ取得までの時間を大幅に短縮します。 Vector 8 Receiver : Wi-Fi および Ethernet を通じて接続し、試合や練習セッション中のリアルタイム分析のためにデータをクラウドにストリーミングします。オンラインとオフラインの両方のワークフローをサポートし、パフォーマンス監視とトラブルシューティングのためのリアルタイム診断も提供します。 Vector 8 Relay : 400メートル範囲となる大規模施設にも適用範囲を広げ、複数の受信機が不要になります。そのため、展開を効率的かつコスト効果高くスケーラブルに実現できます。 リアルタイムパフォーマンスインサイト Vector 8 はコーチやスポーツサイエンティストに3種類のデータを提供します。 デバイスヘルスデータ – バッテリー状態や受信信号強度表示（RSSI）を含むライブテレメトリ、およびファームウェアバージョンなどのデバイス設定です。リアルタイムで送信され、重要な場面におけるデバイス故障前対応を可能にします。 ホットデータ – 10Hz でサンプリングされた試合中・練習中のライブデータです。加速度、速度、選手のポジショニング、心拍数モニタリングを含みます。コーチは iOS アプリで即座に可視化を確認でき、疲労した選手の交代や動きのパターンに基づく戦術調整など、その場での介入が可能です。 コールドデータ – 試合後の 100Hz でサンプリングされた生の慣性データです。ジャンプ、タックル、スローなどスポーツ固有の動きを自動検出するための機械学習（ML）推論に使用されます。 Catapult の AI 駆動アナリティクスは、1試合あたり選手1人につき 600 の特徴的な指標を生成でき、選手のパフォーマンス、ワークロード管理、怪我予防に関する深いインサイトを提供します。 Catapultのビデオ分析ソリューション との統合により、コーチは身体的出力データと実際の試合映像を連携させ、チームの分析・改善方法を変革できます。 AWS IoT アーキテクチャ Vector 8 の接続性の中核にあるのが AWS IoT Core です。AWS IoT Core は、認証、認可、転送中の暗号化、大規模なデバイス管理のためのスケーラブルで高可用性のクラウドエンドポイントを提供します。AWS IoT Core ルールエンジン は、高帯域幅・低遅延・堅牢なネットワークインフラストラクチャ上で、数千のデバイスからのデータを適切な AWS サービスにルーティングする統合ポイントとして機能します。 AWS IoT Greengrass は、Vector 8 のドックおよびVector 8 Receiver ソフトウェアアーキテクチャの基盤です。AWS IoT Greengrass は、Catapult が大規模なマルチプロセス IoT アプリケーションを構築、デプロイ、管理するのに役立つエッジランタイムとクラウドサービスの両方を提供します。 オープンソースのエッジランタイム は、コンポーネントのバージョニング、 依存関係の解決 、 ロギング 、 プロセス間通信 を処理しながら、Catapult の カスタムコンポーネント を AWS提供のコンポーネント 　と並行して管理します。 図1：Catapult Receiver によるデバイスヘルスデータとホットデータの取り込み Catapult は、リアルタイムデータストリーミングには Amazon Managed Streaming for Apache Kafka (Amazon MSK) を使用して、デバイスヘルステレメトリとライブ選手パフォーマンスデータをバッファリングおよび処理しています。 Amazon Elastic Container Service (Amazon ECS) では、バッテリーレベル、ファームウェアバージョン、その他の診断情報をリアルタイムで処理するコンテナ化されたアナリティクスサービスを実行します。 結果は Amazon API Gateway を通じて公開され、Catapult のウェブインターフェースやモバイルアプリに配信され、コーチや機器管理者がデバイスの状態を監視します。 図2：Catapult Dock によるコールドデータの取り込み 試合後のデータは Amazon Simple Storage Service (Amazon S3) に送信され、100Hz の Raw データが機械学習推論のために保存されます。30人の選手による2時間のセッションは30秒未満で Amazon S3 にアップロードできます。このデータ量は、典型的な NHL の試合における3,600万データポイントに相当します。 AWS IoT による主な利点と成果 シームレスなオンボーディング体験 Vector 8 は、チームが数分で稼働できるすぐに使える体験を提供します。Catapult のプリンシパルプロダクトマネージャーである Mike Lee は次のように説明いただきました。 「Vector 8 では、お客様は Catapult Vector iOS アプリをダウンロードし、ハードウェアを開封し、アプリ内のガイド付き登録フローに従うだけです。それだけで完了です。システム全体が10分以内に接続、設定、更新されます。」 この合理化されたセルフサービスのオンボーディング体験により、チームは機器を受け取ってから数分以内に選手の追跡を開始できます。技術サポートや複雑なセットアップは不要です。自動化されたプロセスがデバイスを正しく設定し、最新のファームウェアを即座に実行します。 高速なデバイスアップデート AWS IoT Greengrass デプロイメント による Over-the-Air（OTA）アップデートは、Catapult が顧客に新機能を提供する方法を変革しました。Mike Lee はこの改善事項を以下のように説明いただきました。 「Vector 8 における最大のゲームチェンジャーの一つは、アップデートの処理方法です。AWS IoT Greengrass による自動 OTA アップデートに移行することで、前世代と比較して最大32倍高速にデバイスを更新でき、お客様の時間と運用上の手間を大幅に節約しています。」 AWS IoT Greengrass デプロイメントを利用した自動アップデートに移行することで、Catapult は前世代では不可能だったフリート全体の一貫性を達成しました。また、Mike Lee はこの変化の重要性を以下のように説明いただきました。 「ウェアラブルデバイスフリートのほぼ全体が最新のファームウェアで稼働している状況は、これまでにありませんでした。これにより、数百件のサポートチケットを回避できるでしょう。」 このウェアラブルデバイスフリートの自動最新化手法は、すべての顧客が手動介入なしに、最新の機能、パフォーマンス改善、バグ修正の恩恵を自動的に受けられることを意味します。 迅速なイノベーションの実現 信頼性が高く高性能な Over-the-Air アップデート機能は、Catapult のファームウェアチームの運用方法を根本的に変えました。Mike Lee はこの変革を次のように説明いただきました。 「初めて、準備ができ次第、安全にデバイスに変更をプッシュできるようになりました。以前は顧客に届くまで数ヶ月かかっていたものが、数週間、あるいは数日で提供できるようになりました。特に新機能の反復やベータプログラムの実行時に顕著です。」 この加速により、Catapult は顧客のフィードバックに基づいて新機能を迅速に反復し、より速く価値を提供し、競合他社に先んじることができます。数ヶ月のリリースサイクルから週次、さらには日次のリリースへの移行は、同社のイノベーション方法における根本的な変化を表しています。 プロアクティブなデバイス管理と診断 AWS IoT セキュアトンネリング と AWS IoT Greengrass セキュアトンネリングコンポーネント の組み合わせにより、Catapult のサポートチームはワールドクラスのサービスを提供できます。サポートエンジニアは、利用顧客に同意いただければ、オンデマンドで Vector 8 Dock や Vector 8 Receiver への SSH セッションを確立できます。 AWS IoT Greengrass ログマネージャーコンポーネント により、デバイスログはほぼリアルタイムで Amazon CloudWatch に自動的に流れ、顧客が問題に気づく前にプロアクティブな問題の特定と解決を可能にします。 このリモートアクセス機能は、サポート業務をリアクティブなトラブルシューティングからプロアクティブなモニタリングへと変革します。以前は顧客とのアポイントメントのスケジューリングや複雑なファイル転送が必要だった問題が、数分で診断・解決できるようになりました。 インテリジェントな設定管理 AWS IoT Device Shadows により、Catapult は物理的な接続を必要とせずにクラウドからデバイス設定を管理できます。コーチが Catapult のモバイルアプリを通じて選手をデバイスに割り当てたり、パフォーマンスの閾値を更新したりすると、それらの設定変更は自動的にクラウドに同期され、登録されたすべてのVector 8 Dock に伝播されます。Vector 8 Tag いずれかのVector 8 Dock に置かれると、最新の設定を受信し、デバイスフリート全体の一貫性が確保されます。 この機能により、数千の手動デバイスステージング作業が不要になりました。交換デバイスは最初の接続時に正しい顧客設定を自動的に受信し、ハードウェアが交換された場合でもチームの運用を維持する真のホットスワップ機能を実現しています。 今後の展望 クラウド接続と自動デバイス管理の基盤が整ったことで、Catapult はいくつかの将来のイノベーションを検討しています。 クラウドへのライブデータストリーミング – 現在、10Hz のライブデータはサイドラインの iOS アプリにのみストリーミングされています。このデータをクラウドにストリーミングすることで、より多くの試合中アナリティクスが可能になり、コーチやスポーツサイエンティストのリモートアクセスが実現します。 エッジ機械学習推論 – 現在、ほとんどの ML 推論は試合後にクラウドで行われています。Catapult は、試合や練習セッション中により多くのリアルタイムインサイトを提供するために、Vector 8 Receiver や Vector 8 Tag 上でのエッジへの推論のシフトを調査しています。堅牢な OTA アップデートメカニズムにより、デプロイされたモデルのほぼ継続的な反復と強化が可能です。 AI 駆動のチームアナリティクス – チーム全体の Vector 8 Tag データを分析し、高度な AI モデルを使用してチームの動き、グループダイナミクス、戦術パターンを理解します。 自然言語ビデオ検索 – マルチモーダル埋め込みモデルなどの AI を使用して、 ビデオコンテンツの自然言語検索と理解 を可能にします。これにより、コーチが特定のプレーや状況を見つけるのに役立ちます。 まとめ Catapult の Vector 8 プラットフォームは、AWS IoT サービスがスポーツテクノロジー企業にエンタープライズグレードのソリューションをコンシューマーグレードのシンプルさで提供することを可能にする方法を実証しています。10分でのオンボーディング、32倍高速なアップデート、フリートの97%が最新ファームウェアで稼働という成果により、Catapult は選手モニタリング技術の新たな基準を打ち立てました。 これらの強化により、Catapult はトラブルシューティングを超えて戦略的な前進に向かうことができます。エンジニアリングチームは迅速に反復でき、サポートチームはより迅速に問題を解決でき、顧客は最も重要なこと、つまり選手のパフォーマンスの最適化と試合での勝利に集中できます。 プロスポーツがますますデータ駆動型になる中、Catapult の AWS IoT 搭載プラットフォームは、チームがトレーニング、競技、成功する方法の変革をリードし続けるための位置づけを確立しています。 詳細情報 AWS IoT サービスとそれがコネクテッドデバイスビジネスをどのように変革できるかについて詳しくは、 aws.amazon.com/iot .をご覧ください。Catapult について詳しくは、 catapult.com をご覧ください。 このユースケースをさらに深く知るには、「 AWS re:Invent 2025 – Peak Performance: IoT Innovation in Professional Sports (SPF301) 」の録画をご覧ください。 この記事は Greg Breen, Mike Garbuz, and Farzad Khodadadi, Mike Lee によって書かれた The data behind the win: How Catapult and AWS IoT are transforming pro sports の日本語訳です。この記事は ソリューションアーキテクトの川﨑が翻訳しました。 著者について Greg Breen Greg Breen Amazon Web Services のシニアIoTスペシャリストソリューションアーキテクト。オーストラリアを拠点に、アジア太平洋地域の顧客が IoT ソリューションを構築するのを支援しています。組み込みシステムの豊富な経験を持ち、製品開発チームがデバイスを市場に投入するのを支援することに特に関心があります。 Mike Garbuz Mike Garbuz Amazon Web Services のスポーツソリューションアーキテクト。オーストラリアを拠点に、オーストラリア全土のスポーツ顧客が AWS サービスを最大限に活用できるよう支援しています。機械学習およびデータ＆アナリティクスの経験を持ち、AWS サービスの活用を通じて顧客がデータを最大限に活用できるよう導いています。 Farzad Khodadadi Farzad Khodadadi Catapult のリードプリンシパルソフトウェアエンジニア。15年以上にわたりエンタープライズスケールのクラウドネイティブ技術ソリューションの提供と長期的なエンジニアリング戦略の策定に携わっています。入社以来、Catapult の IoT プラットフォームの設計と提供に技術的リーダーシップを発揮し、ビジョンをスケーラブルでビジネスに即した機能へと転換しています。IoT への情熱により、複数の製品やチームにわたる IoT の採用を加速させ、Catapult のより広範なデジタルおよび製品戦略を支えながら新たな価値の流れを実現しています。 Mike Lee Mike Lee Catapult のプリンシパルプロダクトマネージャー。オーストラリア・メルボルンを拠点としています。スポーツテクノロジーで14年以上、プロスポーツでスポーツサイエンティストとして5年間の直接的な経験を持ち、深いドメイン知識と製品リーダーシップを組み合わせて、チーム、選手、パフォーマンススタッフに実世界の価値を提供する技術を構築しています。 <!-- '"` -->

今から 20 年前の 2006 年 3 月 14 日、 Amazon Simple Storage Service (Amazon S3) は、 「新着」 ページに掲載されたわずか 1 段落のシンプルな発表とともにひっそりとリリースされました: Amazon S3 はインターネットのためのストレージです。デベロッパーがウェブスケールコンピューティングをより簡単に利用できるように設計されています。Amazon S3 は、ウェブ上のどこからでも、いつでも、どのような量のデータでも保存および取得するために使用できるシンプルなウェブサービスインターフェイスを提供します。Amazon が自社のウェブサイトのグローバルなネットワークを運営するために使用している、スケーラビリティ、信頼性、高速性に優れた低コストのデータストレージインフラストラクチャを、すべてのデベロッパーが利用できるようにします。 Jeff Barr 氏のブログ記事 もわずか数段落で、カリフォルニアで開催されるデベロッパー向けイベントに向かう飛行機に乗る前に書かれたものでした。コード例はありませんでした。デモもありませんでした。大々的な宣伝もありませんでした。当時、このリリースが私たちの業界全体を形づくることになろうとは、誰も想像していませんでした。 初期段階: ただ機能するビルディングブロック S3 の中核には、オブジェクトを保存する PUT と、後でそれを取得する GET という、2 つのシンプルなプリミティブがあります。しかし、真のイノベーションは、その背後にある哲学にありました。すなわち、差別化につながらない手間のかかる作業を処理するビルディングブロックを作成することで、デベロッパーがより高度な作業に注力できるようにするということです。 S3 は、サービス開始当初から、今日でも変わっていない 5 つの基本原則をガイドとしてきました。 セキュリティ は、お客様のデータがデフォルトで保護されていることを意味します。 耐久性 は、イレブンナイン (99.999999999%) の可用性を実現するように設計されており、当社はロスレスになるように S3 を運営しています。 可用性 は、障害は常に存在しており、対処される必要があるという前提に基づき、あらゆるレイヤーに組み込まれるように設計されています。 パフォーマンス は、事実上あらゆる量のデータを劣化なく保存するために最適化されています。 伸縮性 とは、データの追加や削除に応じてシステムが自動的に拡張および縮小し、手動での介入が不要であることを意味します。 これらの原則が適切に機能することで、サービスは非常にわかりやすいものとなり、ほとんどのお客様はこれらの概念の複雑さについて考える必要はありません。 今日の S3: 想像を超えた成長 S3 は 20 年間にわたって、想像を絶する規模に成長を遂げながらも、その核となる基本理念を堅持してきました。 S3 が最初にリリースされたとき、3 つのデータセンターにまたがる 15 のラック内の約 400 のストレージノードで、合計約 1 ペタバイトのストレージ容量と合計 15 Gbps の帯域幅を提供していました。当社は、最大オブジェクトサイズを 5 GB として、数百億個のオブジェクトを保存できるようにこのシステムを設計しました。当初の料金は 1 ギガバイトあたり 15 セントでした。 S3 は現在、数百エクサバイト規模のデータを対象として、39 の AWS リージョン内の 123 のアベイラビリティゾーンで、数百万のお客様のために、500 兆個超のオブジェクトを保存し、世界中で毎秒 2 億件超のリクエストを処理しています。 最大オブジェクトサイズは 5 GB から 50 TB へと、1 万倍に増加しました。数千万台すべての S3 ハードドライブを積み重ねると、国際宇宙ステーションまで届き、ほぼ往復できるほどの高さになります。 S3 はこのような驚異的な規模を支えるまでに成長しましたが、お客様が支払う料金は低額になりました。今日、AWS が課金しているのは、 1 ギガバイトあたり 2 セント をわずかに上回る料金です。これは、2006 年のリリースから見ると、約 85% 低い料金です。同時に、ストレージ階層を使用してストレージにかかる支出をさらに最適化する方法も継続的に導入しています。例えば、 Amazon S3 Intelligent-Tiering を利用することで、 Amazon S3 Standard と比較して、お客様全体で合計 60 億 USD 超のストレージコストを削減しています。 過去 20 年間にわたって、 S3 API はストレージ業界全体で採用され、基準点として利用されてきました。現在、複数のベンダーが S3 互換のストレージツールとシステムを提供しており、同じ API パターンと慣例を実装しています。これは、S3 向けに開発されたスキルやツールが他のストレージシステムにも応用できることが多く、より広範なストレージ環境へのアクセスが容易になることを意味します。 このような成長や業界での普及にもかかわらず、おそらく最も注目すべき成果は、2006 年に S3 向けに作成したコードが、現在も変更されることなく機能していることです。お客様のデータは 20 年間のイノベーションと技術的な進歩を経てきました。当社は、複数世代のディスクとストレージシステムにわたって、インフラストラクチャを移行してきました。リクエストを処理するためのコードはすべて書き直されています。しかし、お客様が 20 年前に保存したデータは今日でも利用可能であり、当社は API の完全な後方互換性を維持しています。これは、常に「問題なく機能する」サービスを提供するという当社のコミットメントです。 規模を支えるエンジニアリング S3 をこれほど大規模に実現できるのはなぜでしょうか? その答えは、エンジニアリングにおける継続的なイノベーションです。 以下の内容のほとんどは、AWS の VP of Data and Analytics である Mai-Lan Tomsen Bukovec と、 The Pragmatic Engineer である Gergely Orosz 氏との対談に基づいています。 詳細なインタビュー では、より深く理解したい方のために、技術的な詳細をさらに掘り下げています。以下の段落では、いくつかの例をご紹介します: S3 の耐久性の中心にあるのは、フリート全体ですべてのバイトを継続的に検査するマイクロサービスのシステムです。これらの監査サービスはデータを監視し、劣化の兆候を検出した瞬間に修復システムを自動的にトリガーします。S3 はロスレスになるように設計されています。イレブンナインという設計目標は、レプリケーション係数と再レプリケーションフリートの規模を反映したものですが、システムはオブジェクトが失われないように構築されています。 S3 のエンジニアは、本番において 形式手法と自動推論 を用いて、数学的に正確性を証明しています。エンジニアがインデックスサブシステムにコードをチェックインすると、自動証明によって一貫性が損なわれていないことが検証されます。この同じアプローチは、 リージョン間レプリケーション や アクセスポリシー の正確性を証明します。 AWS は過去 8 年間にわたって、S3 リクエストパスのパフォーマンスクリティカルなコードを Rust で段階的に書き換えてきました。Blob の移動とディスクストレージは書き換えられ、現在は他のコンポーネントで作業が積極的に進められています。生のパフォーマンスだけでなく、Rust の型システムとメモリ安全性の保証により、コンパイル時にバグのクラス全体を排除できます。これは、S3 の規模と高い正確性の要件を満たす必要がある運用において不可欠な特性です。 S3 は「スケールはメリットである」という設計哲学に基づいて構築されています。 エンジニアは、スケールが拡大することで、すべてのユーザーにとって性能が向上するようにシステムを設計します。S3 の規模が大きくなるほど、ワークロード間の相関性が低下し、すべてのユーザーにとって信頼性が高まります。 今後の展望 S3 のビジョンは、単なるストレージサービスを超え、すべてのデータおよび AI ワークロードの普遍的な基盤となることです。当社のビジョンはシンプルです。すなわち、あらゆる種類のデータを S3 に一度保存すれば、専用システム間でデータを移動させることなく、直接そのデータを利用できる、というものです。このアプローチにより、コストが削減され、複雑さが解消され、同じデータの複数のコピーを作成する必要がなくなります。 近年の注目すべきリリースをいくつかご紹介します: S3 Tables – 時間が経過する中で、クエリ効率を最適化し、ストレージコストを削減する、自動メンテナンスを備えたフルマネージド Apache Iceberg テーブル。 S3 Vectors – セマンティック検索と RAG のためのネイティブベクトルストレージ。インデックスあたり最大 20 億のベクトルをサポートし、クエリレイテンシーは 100 ミリ秒未満です。わずか 5 か月間 (2025 年 7 月～12 月) で、25 万を超えるインデックスを作成し、400 億を超えるベクトルを取り込み、10 億件を超えるクエリを実行しました。 S3 Metadata – データの即時検出のための一元化されたメタデータ。カタログ化のために大規模なバケットを再帰的にリストする必要がなくなり、大規模データレイクに関するインサイトの取得までの時間を大幅に短縮します。 これらの各機能は S3 のコスト構造で利用できます。従来は高コストのデータベースや専用システムが必要だった複数のデータタイプを、大規模かつ経済的に処理できます。 1 ペタバイトから数百エクサバイトに。1 ギガバイトあたり 15 セントから 2 セントに。シンプルなオブジェクトストレージから、AI と分析の基盤へ。このような変化の中にあっても、当社の 5 つの基本原則、すなわち、セキュリティ、耐久性、可用性、パフォーマンス、伸縮性は変わっていません。そして、2006 年に書かれたお客様のコードは、今日も機能します。 Amazon S3 における次の 20 年間のイノベーションに祝意を表したいと思います。 – seb 原文は こちら です。

本記事は 2026 年 3 月 16 日 に公開された「 Securely connect Kafka clients running outside AWS to Amazon MSK with IAM Roles Anywhere 」を翻訳したものです。 AWS 外 (オンプレミス環境や他のクラウド) で動作する Kafka クライアントは、コードベースやサーバー設定に長期 IAM ユーザーのアクセスキーを含める必要があります。長期認証情報が漏洩すると、AWS アカウントへの不正アクセスにつながるリスクがあります。 本記事では、 AWS IAM Roles Anywhere を使用して、X.509 証明書によるクライアントアプリケーションの一時的な AWS セキュリティ認証情報を取得し、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) クラスターとセキュアに通信する方法を紹介します。本記事のソリューションは、Amazon MSK Provisioned と Serverless の両方のクラスターに対応しています。 AWS IAM Roles Anywhere の概要 AWS Identity and Access Management (IAM) Roles Anywhere を使用すると、サーバー、コンテナ、アプリケーションなど AWS 外で動作するワークロードに対して、IAM の一時的なセキュリティ認証情報を取得できます。 IAM Roles Anywhere を使用すると、AWS アプリケーションと同じ IAM ポリシーとロールを AWS 外のワークロードでも利用できます。AWS 外で動作する Kafka クライアントの長期認証情報を管理する必要がなくなります。プロファイルに 1 つ以上のロールを関連付け、IAM Roles Anywhere でそのロールを引き受けられるようにすると、認証局 (CA) が発行したクライアント証明書で AWS へのリクエストを安全に開始できます。アプリケーションは一時的な認証情報を取得し、AWS 環境にアクセスできるようになります。 Amazon MSK の IAM アクセスコントロールを使用すると、追加コストなしで Amazon MSK クラスターの認証と認可の両方を管理できます。認証と認可に別々のメカニズムを使用する必要がなくなります。mutual TLS や SASL/SCRAM 認証/認可を使用する特別な要件がない限り、Amazon MSK では IAM アクセスコントロールの使用をお勧めします。 以降では、AWS IAM Roles Anywhere で MSK クラスターに接続するセキュアな Kafka クライアントマシンの実装手順を説明します。 ソリューションの概要 ソリューションのアーキテクチャを次の図に示します。 アーキテクチャのフローは次のとおりです。 クライアントマシンが X.509 証明書を使用して AWS IAM Roles Anywhere エンドポイントにセッショントークンをリクエストします。 IAM Roles Anywhere が証明書を検証し、STS から一時的なセッショントークンを取得してクライアントマシンに返します。 Amazon MSK Provisioned の場合、MSK クライアントマシンは AWS VPN または AWS Direct Connect 経由で VPC 内の AWS Transit Gateway または AWS Network Load Balancer に接続します。詳細については、 Amazon MSK へのセキュアな接続パターン を参照してください。 Amazon MSK Serverless の場合、MSK クライアントマシンは AWS VPN または AWS Direct Connect 経由で VPC 内の インターフェイス VPC エンドポイント に接続します。詳細については、 オンプレミスネットワークから Amazon MSK Serverless に接続する を参照してください。 Amazon MSK Serverless では、インターフェイスエンドポイントはアカウント内のプライベート IP アドレスを持つ 1 つ以上の Elastic Network Interface の集合です。MSK Serverless サービスへのトラフィックのエントリポイントです。 前提条件 本記事では、MSK Serverless クラスターとクライアントマシンの作成に慣れていることを前提としています。以下のタスクが完了していることを想定しています。 Amazon MSK Serverless クラスターの作成 または Amazon MSK Provisioned クラスターの作成 オンプレミスのデータセンターまたは別の AWS アカウントの VPC に MSK クライアントマシンを作成 オンプレミスと Amazon MSK Serverless クラスター間のネットワーク接続の確立 、または オンプレミスと Amazon MSK Provisioned クラスター間のネットワーク接続の確立 AWS IAM Roles Anywhere の設定 オンプレミスの Kafka クライアントマシンで IAM Roles Anywhere を有効にするには、トラストアンカーとプロファイルの 2 つを設定する必要があります。トラストアンカーは、Roles Anywhere と認証局間の信頼関係を確立します。証明書認証で IAM ロールの認証情報を取得する際に使用されます。プロファイルは、Roles Anywhere での認証成功後に適用される権限セットです。 ステップ 1: CA の生成 X.509 証明書は、クライアントマシンと Roles Anywhere 間の通信に不可欠です。任意の公開鍵基盤 (PKI) プラットフォームで認証局 (CA) を構築できます。 独自の X.509 クライアント証明書を生成する場合は、 外部認証局を使用した IAM Roles Anywhere の手順を参照してください。 この例では、簡略化のため AWS Private CA を使用します。 AWS Private CA コンソール に移動します。 ルート CA の作成 CA タイプ オプションで Root を選択し、組織名と組織単位名を入力します。 キーアルゴリズムに デフォルトの RSA 2048 を選択します。 Create CA ボタンを選択してプライベート CA を生成し、証明書をインストールします。 下位 CA の作成 CA タイプオプションで Subordinate を選択します。 キーアルゴリズムに デフォルトの RSA 2048 を選択します。 Create CA ボタンを選択します。 下位 CA から CSR を取得し、ルート CA で署名します。 この CA は、IAM Roles Anywhere への証明書発行に使用します。 よりセキュアで自動更新される AWS Private CA の生成については、 CA の作成手順 と CA 階層の構築方法 を参照してください。 ステップ 2: アンカーの設定 Roles Anywhere コンソールに移動し、 Create a trust anchor ページを開きます。 トラストアンカーの名前を入力し、ステップ 1 で作成した プライベート CA を選択します。独自の外部 CA を使用する場合は、 External certificate bundle オプションを選択し、必要な証明書バンドルを指定します。 create a trust anchor ボタンを選択してプロセスを完了します。 ステップ 3: IAM Roles Anywhere を信頼するロールの作成と設定 IAM Roles Anywhere での認証後にオンプレミスの Kafka クライアントマシンが引き受けるロールを作成します。 ロールの信頼ポリシーには以下を含める必要があります。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "rolesanywhere.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity", "sts:TagSession" ], "Condition": { "StringEquals": { "aws:PrincipalTag/x509Subject/CN": "specific-certificate-common-name" } } } ] } このデモでは、以下のポリシーを作成してロールにアタッチします。 { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kafka-cluster:Connect", "kafka-cluster:AlterCluster", "kafka-cluster:DescribeCluster" ], "Resource": [ "arn:aws:kafka:&lt;Region&gt;:&lt;Account-ID&gt;:cluster/&lt;Cluster-name&gt;/&lt;Cluster-identifier&gt;" ] }, { "Effect": "Allow", "Action": [ "kafka-cluster:CreateTopic", "kafka-cluster:DescribeTopic", "kafka-cluster:WriteData", "kafka-cluster:ReadData", "kafka-cluster:AlterGroup", "kafka-cluster:DescribeGroup" ], "Resource": [ "arn:aws:kafka:&lt;Region&gt;:&lt;Account-ID&gt;:cluster/ &lt;Cluster-Name&gt;/&lt;Cluster-identifier&gt;", "arn:aws:kafka:&lt;Region&gt;:&lt;Account-ID&gt;:topic/msk-&lt;Cluster-Name&gt;/&lt;Cluster-Identifier&gt;/&lt;Topic-Name&gt; ", "arn:aws:kafka:&lt;Region&gt;:&lt;Account-ID&gt;:group/&lt;Cluster-Name&gt;/&lt;Cluster-Identifier&gt;/&lt;Group-Name&gt;" ] } ] } ステップ 4: プロファイルの設定 Roles Anywhere コンソール に戻ります。 Profiles で Create a profile を選択します。 プロファイルの名前を入力します。 ステップ 3 で作成したロールを選択し、Roles Anywhere プロファイルを作成します。 ステップ 5: クライアントマシンのテスト トラストアンカーとプロファイルを作成して Roles Anywhere のセットアップが完了したので、次はクライアントマシンと Roles Anywhere の通信をテストします。セッショントークンを取得し、MSK ブローカーとの通信を確立します。 ステップ 1 で作成した CA から プライベート証明書をリクエスト し、クライアントマシンで使用する クライアント証明書をエクスポート します。 .pem ファイルを作成し、すべての証明書の内容をファイル (例: private_key.pem) にコピーして、以下のコマンドで復号化した証明書を生成します。 openssl rsa -in private_key.pem -out decrypted_private_key.pem 認証情報ヘルパーをダウンロード し、署名ヘルパーツールでクライアントマシンからの動作を確認します。Roles Anywhere のトラストアンカーとプロファイルの ARN、および IAM で作成したロールの ARN を指定します。 ./aws_signing_helper credential-process \ --certificate /path/to/certificate.pem \ --private-key /path/to/decrypted_private_key.pem \ --trust-anchor-arn &lt;TA_ARN&gt; \ --profile-arn &lt;PROFILE_ARN&gt; \ --role-arn &lt;Roles_ARN&gt; \ --region &lt;Region&gt; IAM Roles Anywhere からセッション認証情報を正常に取得できるはずです。 セットアップの成功を確認したら、 ~/.aws/config ファイルを更新または作成します。オンプレミスサーバーの無人アクセスを有効にするため、署名ヘルパーを credential_process として追加します。 [default] credential_process = ./aws_signing_helper credential-process --certificate /path/to/certificate.pem --private-key /path/to/decrypted_private_key.pem --trust-anchor-arn &lt;TA_ARN&gt; --profile-arn &lt;PROFILE_ARN&gt; --role-arn &lt;Roles_ARN&gt; --region &lt;Region&gt; すべてのステップが完了すると、Kafka クライアントが MSK ブローカーと通信できるようになります。 ./kafka-topics.sh --create \ --bootstrap-server &lt;BOOTSTRAP_SERVER&gt; \ --command-config &lt;Command Config File&gt; \ --replication-factor &lt;Replication Factor&gt; \ --partitions &lt;Number of Partitions&gt; \ --topic &lt;Topic Name&gt; クリーンアップ 不要なコストを避けるには、IAM ロール、プロファイル、トラストアンカー、ポリシー、ACM でリクエストした証明書、AWS Private CA で作成した証明書を削除してください。 aws delete-role --role-name &lt;value&gt; aws delete-profile --profile-id &lt;value&gt; aws delete-trust-anchor --trust-anchor-id &lt;value&gt; aws acm delete-certificate --certificate-arn &lt;value&gt; aws acm-pca revoke-certificate --certificate-authority-arn &lt;value&gt; --certificate-serial &lt;value&gt; --revocation-reason &lt;value&gt; aws acm-pca delete-certificate --certificate-authority-arn &lt;value&gt; --certificate-serial &lt;value&gt; まとめ 本記事では、AWS IAM Roles Anywhere を使用して、AWS 外のクライアントマシンから MSK ブローカーにアクセスするための一時的なセッショントークンを生成する方法を紹介しました。IAM Roles Anywhere の導入により、AWS 外から MSK に接続する Kafka クライアントのセキュリティ体制が強化され、厳格なセキュリティ要件があるお客様も安心して MSK を導入できます。 ご質問は、 AWS re:Post で新しいスレッドを作成するか、 AWS サポート にお問い合わせください。 著者について Ankit Mishra Ankit は、Amazon Web Services のシニアソリューションアーキテクトです。セキュアでスケーラブル、信頼性が高く、コスト効率の良いクラウドソリューションの設計と構築を支援しています。仕事以外では、妻と幼い娘と過ごす時間を楽しんでいます。 Tony Anastasio Tony は、AWS の Global Healthcare チームのシニアソリューションアーキテクトマネージャーです。データの相互運用性、AI ソリューション、セキュアなクラウド基盤にわたるイノベーションを推進するアーキテクトチームをリードし、業界最大級のヘルスケア組織を支援しています。余暇には、妻と 2 人の子供と過ごす時間を楽しんでいます。 Kalyan Janaki Kalyan は、Amazon Web Services のシニアビッグデータ &amp; アナリティクススペシャリストです。高いスケーラビリティ、パフォーマンス、セキュリティを備えたクラウドベースのソリューションの設計と構築を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。直前のご案内になりますが、3 月 25 日（水）に「 AWS での Claude Code の買い方・使い方 」という Claude Code を AWS 上で活用する手段や買い方をご紹介するイベントが開催されます。また翌日の 3 月 26 日（木）には「 Amazon Quick で変わる業務の現場 — 活用企業・AWS社員による事例紹介 」が開催されます。ご興味がある方はぜひご参加ください！ 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは 3月 9 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI事例ブログ「 寄稿： 三菱電機が挑む製造業の商談変革 – AWS で実現した商談支援サービス「Memory Tech」 」 三菱電機 名古屋製作所が、製造業の商談現場で発生する口頭コミュニケーションの認識齟齬という課題を解決するために、AI を活用した商談支援サービス「Memory Tech」を AWS 上で開発した事例が紹介されています。Memory Tech は Web ブラウザやスマートフォンで商談の音声を録音するだけで、Amazon Bedrock の生成 AI が 2 分以内に構造化された議事録を自動生成するサービスで、AWS Amplify Gen 2 を中核としたサーバーレスアーキテクチャにより、少人数のチームでも迅速な開発と 1,000 名超のユーザーに対応する安定運用を実現しています。生成 AI を活用するユーザーにとっては、Amazon Bedrock 上で Anthropic Claude と Amazon Nova を用途に応じて使い分けることでコスト最適化と応答速度を両立しており、現場の業務習慣を変えずに AI の力で業務改善を図る実践的な活用事例として参考になります。 AWS生成AI事例ブログ「 【寄稿】「12時間で PoC が完成」― サミット株式会社の情報システム部門が AI コーディングアシスタント Kiro で実現した、圧倒的スピードの内製開発 」 スーパーマーケットチェーンのサミット株式会社が、AI コーディングアシスタント「Kiro」を活用して情報システム部門による内製開発を加速させた事例が紹介されています。従来であれば外部委託で 3 か月・数百万円規模のコストがかかる店舗データ分析ダッシュボードの PoC を、Kiro の Spec-driven Development 機能を活用して一人の担当者がわずか 12 時間で完成させるなど、開発スピードの大幅な向上を実現しました。生成 AI を活用した開発に取り組むユーザーにとっては、セッション情報の管理やステアリングの設定といった Kiro を効果的に使いこなすための実践的なノウハウに加え、レガシーシステムのリバースエンジニアリングやパートナーとの協業モデルの変革など、AI コーディングアシスタントの活用範囲を広げるヒントが得られる内容です。 ブログ記事「 「フィジカル AI 開発支援プログラム by AWS ジャパン」キックオフイベントを開催しました 」 AWS ジャパンが、フィジカル AI の開発を支援する約 6 ヶ月間のプログラムのキックオフイベントを開催し、採択企業によるピッチや Amazon Robotics の事例紹介が行われた様子を報告しています。このプログラムでは、ソリューションアーキテクトによる技術支援、AWS クレジットの提供に加え、プロトタイピングを専門とする Prototyping &amp; Cloud Engineering（PACE）チームが開発する Physical AI Scaffolding Kit（PASK）によるトレーニング環境のサンプル提供など、データ収集からモデル学習・実機デプロイまでの一連のパイプライン構築を包括的にサポートします。生成 AI を活用するユーザーにとっては、Vision-Language-Action（VLA）モデルなどのロボット基盤モデル開発を Amazon SageMaker HyperPod 上で実行する具体的なアプローチや、日本のものづくりの強みと生成 AI を融合させるフィジカル AI エコシステムの最新動向を知ることができる内容です。 ブログ記事「 月刊 AWS 製造 2026年3月号 」 今月の月刊 AWS 製造では「Agentic AI × 製造業」を特集しており、BMW Group が Amazon Bedrock AgentCore と Strands Agents を活用してペタバイト規模のデータからインサイトを抽出する品質管理の事例や、Amazon Bedrock AgentCore による調達ワークフローの自動化、メック株式会社が Amazon Bedrock AgentCore Runtime と Amazon S3 Vectors で研究業務を効率化した事例など、製造業の各領域で Agentic AI を実践的に活用するコンテンツが充実しています。さらに、Toyota Motor Europe が Amazon Bedrock でレガシーメインフレームのドキュメント自動生成に取り組んだ事例や、三菱電機が Kiro と GitLab で開発ワークフローを標準化した事例など、生成 AI を活用した製造業の業務改善事例も多数紹介されています。製造業に関わる方にとって、生成 AI の具体的な活用パターンをまとめて把握できる内容ですので、ぜひご覧ください。 ブログ記事「 エンタープライズガバナンス：MCP サーバーとモデルの制御 」 AI コーディングアシスタント「Kiro」に、エンタープライズ向けの 2 つの新しいガバナンス機能がリリースされました。1 つ目は MCP サーバーレジストリで、管理者が承認済みの MCP サーバーを JSON 形式の許可リストとして定義し、開発者が接続できるサーバーを一元管理できるようになります。2 つ目はモデルガバナンス機能で、組織内の開発者が利用できる AI モデルを管理者が制御でき、特にデータレジデンシー要件がある場合にグローバルクロスリージョン推論を使用する実験的モデルを無効化するといった対応が可能になります。生成 AI を活用した開発を組織的に推進するユーザーにとっては、セキュリティ・コンプライアンス要件を満たしながら AI コーディングツールの導入を拡大するための具体的なアプローチとして参考になる内容です。 サービスアップデート Kiro IDE 0.11 のリリース Kiro IDE 0.11 がリリースされました。エンタープライズチーム向けに MCP サーバーアクセスとモデル利用のガバナンス機能が追加され、管理者が承認済みの MCP サーバーや利用可能な AI モデルを一元管理できるようになりました。また、チャットにドキュメント添付機能が追加され、PDF、CSV、DOC、XLSX、HTML、Markdown など多様なフォーマットのファイルをチャット入力にドラッグ＆ペーストして、1 メッセージあたり最大 5 ファイルまでテキストや画像と組み合わせて AI に読み込ませることができます。生成 AI を活用した開発に取り組むユーザーにとっては、ドキュメントを直接チャットに渡して内容を推論させられるようになったことで、仕様書やデータファイルを参照しながらのコーディング作業がより効率的になるアップデートです。 AI アシスタントによる構成管理を実現する新しい LZA MCP サーバー Landing Zone Accelerator on AWS（LZA）の構成管理を AI アシスタントとの自然言語の対話で行える MCP サーバーがオープンソースとして公開されました。この LZA MCP サーバーは 20 種類の専用ツールを備えており、複数の LZA バージョンにまたがるドキュメント検索、構成管理、パイプライン監視、デプロイ失敗時の原因分析といった、これまで手作業で時間のかかっていた作業を効率化できます。Kiro、Amazon Q Developer、Claude Code などの IDE と互換性のあるコンテナ化された MCP エンドポイントとして動作するため、生成 AI を活用した開発環境を構築しているユーザーにとっては、マルチアカウント環境のガバナンス設定を自然言語で対話しながら管理できる実用的なツールとして活用が期待できます。 Amazon Bedrock AgentCore Memory が長期メモリのストリーミング通知をサポート Amazon Bedrock AgentCore Memory に、長期メモリのストリーミング通知機能が追加されました。長期メモリはエージェントとのやり取りからインサイトを抽出し、次回以降のインタラクションでパーソナライズされた体験を提供する機能ですが、これまでメモリの変更を検知するにはポーリング処理を自前で実装する必要がありました。今回のアップデートにより、メモリレコードの作成・変更時に Amazon Kinesis へプッシュ通知がストリーミングされるようになり、後続のワークフロー起動やアプリケーション状態の更新、メモリ変更の監査を自動化できるようになります。生成 AI エージェントを開発するユーザーにとっては、ポーリングロジックの実装が不要になることでアーキテクチャが簡素化され、よりリアルタイム性の高いパーソナライズ体験の構築が可能になるアップデートです。本機能は東京リージョンを含む 15 の AWS リージョンで利用可能です。 Amazon Bedrock が初回トークンレイテンシーとクォータ消費のオブザーバビリティをサポート Amazon Bedrock に 2 つの新しい Amazon CloudWatch メトリクスが追加されました。TimeToFirstToken はストリーミング API でリクエスト送信から最初のトークン受信までのレイテンシーを測定するメトリクスで、クライアント側の実装なしにレイテンシー劣化の監視や SLA ベースラインの設定が可能になります。EstimatedTPMQuotaUsage はキャッシュ書き込みトークンや出力バーンダウン乗数を含む Tokens Per Minute（TPM）のクォータ消費量を追跡するメトリクスで、クォータ上限に達する前にアラームを設定してレート制限を事前に回避できます。生成 AI アプリケーションを運用するユーザーにとっては、追加費用や API 変更なしに Amazon CloudWatch で推論パフォーマンスとクォータ使用状況を可視化できるようになり、本番環境の安定運用に役立つアップデートです。 Amazon Connect が AI を活用したマネージャーアシスタント機能を発表（プレビュー） Amazon Connect に、コンタクトセンターのマネージャーが自然言語で業務に関する質問をすると即座に回答を得られる、AI を活用したアシスタント機能がプレビューとして発表されました。エージェントのスケジューリング、セルフサービス体験、パフォーマンス評価を含む 150 以上の Amazon Connect メトリクスに対して自然言語でクエリでき、これまで手作業で数時間かかっていたデータ収集を数秒で完了できるようになります。さらに、サービスレベル目標の達成が危ぶまれるキューの特定や具体的な改善アクションの提案など、根本原因の診断も行えるため、生成 AI を活用してカスタマーサービスの品質向上に取り組むユーザーにとって、運用の意思決定を加速させる実用的なアップデートです。 Amazon Quick Suite がチャットパーソナライゼーションのためのユーザー設定機能をリリース Amazon Quick Suite に、チャット体験をユーザーごとにカスタマイズできるユーザー設定（User Preferences）機能が追加されました。チャットパネルのレイアウト設定、デフォルトのチャットエージェントやナレッジスコープの事前選択に加え、自分の呼び名や業務の注力領域を登録することで、AI がその情報をもとにレスポンスをパーソナライズしてくれるようになります。これまでセッションをまたいでチャット設定やエージェント選択、個人のコンテキストを保持する手段がなかったため、生成 AI を業務で日常的に活用するユーザーにとっては、毎回の設定の手間が省かれ、最初のやり取りからパーソナライズされた体験が得られるようになる便利なアップデートです。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近天ぷらを(食べるのではなく)揚げるほうにハマってます。