2026 年 5 月 22 日、金融庁と日本銀行は 「フロンティア AI による脅威変化を踏まえた金融機関等の短期的な対応」に係る要請 (金総政第 3245 号ほか) を公表し、経営トップを含めた経営層の直接関与の下で、短期的な対応に取り組むよう金融機関等に要請しました。 要請では、いわゆる「フロンティア AI」により、脆弱性の発見・修正等のサイバーセキュリティ性能の急速な向上が見込まれることを踏まえ、これに対応する取組が必要不可欠とされています。フロンティア AI を用いてソフトウェアの脆弱性を発見・修正する取り組みとしては、2026 年 4 月に Anthropic が発表した Project Glasswing と、その中核となる新クラスのモデル Claude Mythos があります。AWS はこの取り組みのローンチパートナーの一社であり、AWS Blog 「AI を活用した大規模なセキュリティ防御の構築 – 脅威が出現する前に」 で自らの取り組みを公開しています。 本記事では、金融庁・日本銀行の要請が求める 9 つの短期的対応のそれぞれについて、AWS のサービスと機能がどう役立つかを整理します。本記事で取り上げるサービスや機能は代表的な例であり、利用可能な選択肢のすべてを網羅するものではありません。また、AWS の利用だけで要請への対応が完了するものではなく、最終的な評価・統制・意思決定は各金融機関が行うものです。実際の対策の選定にあたっては、自組織のリスク特性やシステム構成を踏まえてご検討ください。 要請が指摘する脅威の変化 要請では、フロンティア AI により、従来は発見が困難だった脆弱性が短期間に発見され得ることに加え、脆弱性の発見から攻撃に至るまでの期間が大幅に短縮され得ることが指摘されています。規模の目安として、次の数字があります。2025 年の 1 年間に公開された CVE (共通脆弱性識別子) は 48,185 件 (前年比約 20% 増) でした。一方、Anthropic が公表した 経過報告 (Project Glasswing: An initial update) によれば、Project Glasswing では約 50 のパートナー組織が Claude Mythos Preview を使い、開始から約 1 か月で深刻度 High または Critical の脆弱性を 1 万件超発見しています。さらに Anthropic 自身も 1,000 以上のオープンソースプロジェクトをスキャンし、モデルの推定を含め 23,019 件 (うち High/Critical は推定 6,202 件) の脆弱性候補を発見しました。Anthropic は発足時に、プロジェクトで得られた知見を 90 日以内に公に報告すると表明し、上記の経過報告として公開しました。また、発見された個々の脆弱性は、協調的脆弱性開示 (CVD) ポリシーに沿って、独立した検証とメンテナーへの通知、修正のための開示猶予期間を経て順次公開されています。これらの数字は、公開済みの CVE 件数とは期間・対象・検証状況が異なるため直接比較はできないものの、発見の後に続く検証・開示・修正の工程の処理能力が課題になり得ることを示しています。 ここで課題になるのが、パッチ適用までの時間差です。脆弱性が公表されパッチが公開されても、それを適用し終えるまでは脆弱性が残ります。この、公表から N 日が経過した既知の脆弱性を狙う攻撃は「N デイ攻撃」と呼ばれます (未知の脆弱性を狙うゼロデイ攻撃と対になる用語です)。Amazon の脅威インテリジェンスチームは、攻撃者が公開されたエクスプロイトを開示から数時間～数日で攻撃に転用する状況を観測しています。しかもこの速度は国家支援型のグループに限りません。公開された PoC や生成 AI の活用により、高度な技術を持たない攻撃者にも広がりつつあります。「四半期ごとに」「十分なテストを経てから」パッチを当てるという従来モデルでは、対応が間に合わない可能性があります。金融庁・日本銀行の要請でも、短期的に脆弱性やパッチが集中的に発見・提供される可能性を踏まえ、「経営トップを含めた経営層の直接関与」の下で迅速かつ適切に対応できる態勢の点検・強化が求められています。 一方で、英国 AI Security Institute (AISI) の 評価報告 (Our evaluation of Claude Mythos Preview’s cyber capabilities) では、現時点のフロンティア AI は十分に防御された IT システムに対しては攻撃を達成できるとは言えないとされています。つまり、金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」に基づく基本的な対策を、より迅速かつ確実に実行していくことが、引き続き最も重要な出発点になります。 9 つの短期的対応に AWS サービスがどう役立つか 要請は 9 つの短期的対応を挙げています。これらは IT・サイバーセキュリティ担当部署のみで完結するものではなく、経営トップの正確な理解と危機意識の下で必要なリソース (予算・人員) を確保することが不可欠、というのが要請全体を貫く前提です。以下、各項目について AWS のサービスと機能でできることを整理します。 ① フロンティア AI への対応を経営課題として扱う この脅威は IT・サイバーセキュリティ部門にとどまらず、各業務所管部門・リスク管理・財務部門が横断的に連携すべき全社的な経営課題です。AWS では、サポート階層にかかわらず無料で利用できる Security Health Improvement Program (SHIP) や、 AWS セキュリティ成熟度モデル を通じて、自組織の現状を客観的に把握し、経営として優先順位とリソース配分を判断するための材料を提供しています。セキュリティ成熟度モデルは過去 1 年間で世界の 50,000 を超えるお客様に利用されています。 ② 優先的に対応すべきサービス/IT システムを特定する どのシステムが重要業務を支えているか、その業務影響の評価はお客様自身にしかできない判断です。技術面で支援できるのは、その判断の前提となる資産の把握です。 AWS Config や AWS Systems Manager のインベントリ機能を使うと、AWS 上のリソース構成や導入ソフトウェアを継続的に記録でき、「どこに何があるか」を洗い出す作業を支援します。そのうえで、 Amazon Inspector がワークロードを継続的に監視し、新しい脆弱性が公開されるとニアリアルタイムで再スキャンして、CVSS (共通脆弱性評価システム) のスコアだけでなくネットワーク到達性や悪用可能性を加味したリスクスコアを算出するため、インターネットバンキング等を支える外部公開システムから優先的に対処する、といったリスクベースの絞り込みに役立ちます。さらに、後述する AWS Continuum (限定プレビュー) は、インフラ・アクセス許可・ネットワーク構成に加え、ドキュメントやビジネス上の優先事項といった組織のコンテキストを取り込み、IT 資産の重要度を考慮した対応の優先順位付けを支援します。 ③ 特定した資産の技術負債を解消しておく 優先対象について、ソフトウェア構成・ネットワーク構成を再確認し、脆弱性発見時に即座にパッチ適用対象を特定できる状態を確保します。不要なネットワークポートの閉塞、特権 ID の削除、サポート終了製品のサポート対象バージョンへの更新が重要です。Amazon Inspector は監視対象リソースのソフトウェア部品表 (SBOM) を CycloneDX/SPDX 形式でエクスポート でき、サプライチェーンを含む構成の可視化に役立ちます。また、スタンドアロンツールの Amazon Inspector SBOM Generator を使うと、CI/CD パイプラインの中でコンテナイメージ等の SBOM を生成し、デプロイ前の脆弱性検出に活用できます。加えて、後述のマネージドサービスへの移行そのものが、OS・ミドルウェア層の技術負債を構造的に減らす有効な手段になります。 ④ パッチ適用に係る人的リソースを追加する / ⑤ ベンダーとの維持保守契約を確認する 人的リソースの追加やベンダー契約 (SLA/SLO、夜間・休日対応、責任分担) の確認は、まず組織・契約面の課題です。技術面からは、2 つの時間軸で補完できます。 短期的には、今あるサーバーのパッチ作業自体の自動化です。 AWS Systems Manager Patch Manager は、パッチベースラインとメンテナンスウィンドウを定義して、Amazon EC2 上のサーバーだけでなくオンプレミスのサーバーも含めてパッチの適用状況の確認と適用を自動化できます。手作業の適用・確認に費やしている時間を減らすことは、人的リソースの追加と同じ方向の効果を持ちます。 中長期的には、パッチ適用の対象そのものを減らすという考え方があります。 AWS Lambda 、 Amazon API Gateway 、 AWS Fargate 、 Amazon Aurora Serverless 、 Amazon DynamoDB などのサーバーレス・マネージドサービスを活用すると、責任共有モデルのもとで、基盤となるインフラストラクチャや AWS が管理するランタイムのパッチ適用が AWS の責任範囲となり、お客様はアプリケーションコード、コンテナイメージ、およびそれらの依存関係など、お客様の責任範囲に集中できます。 マネージドサービスへの移行に際して、AWS 側で行われる基盤メンテナンスが業務に影響しないか、気になるかもしれません。この点は、AWS がマネージドサービスをどのような構造で提供しているかという、責任共有モデルの AWS 側の設計から説明できます。 ホワイトペーパー「 AWS 障害分離境界 」が説明するとおり、Amazon DynamoDB や Amazon SQS などのマネージドサービスの多くは「リージョンサービス」として提供されます。リージョンサービスは、AWS が物理的に分離された複数のアベイラビリティーゾーン (AZ) の上に構築したサービスであり、お客様が複数 AZ の活用方法を設計する必要はありません。たとえば Amazon S3 はリクエストとデータを複数の AZ に分散し、1 つの AZ の障害から自動的に回復するように設計されています。この冗長な構造が、基盤の一部を更新しながらサービス全体は稼働を続ける、という運用の土台になっています。各サービスには、月間稼働率のサービスコミットメントと未達時の取り扱いを定めた SLA (サービスレベルアグリーメント) が公開されています。 その更新のプロセスについて、AWS は CSA (Cloud Security Alliance) の Consensus Assessments Initiative Questionnaire (CAIQ) への回答 の中で、本番環境へのすべての変更が「中断を最小化するための実装・ロールバック計画」「非本番環境でのテスト」「ピアレビュー」「承認」を経て、可能な限り手動ステップを排した継続的デプロイのパイプラインで実施されることを説明しています。個別のサービスにもこの設計は表れており、 Amazon DynamoDB はバージョンやメンテナンスウィンドウという概念自体を持たず「アップグレードやダウンタイムを必要とせず、可用性、信頼性、パフォーマンス、セキュリティ、機能を継続的に改善」し、Amazon Aurora の ダウンタイムのないパッチ適用 (ZDP: Zero-Downtime Patching) はエンジンのアップグレード中もクライアント接続の維持を試みます。実例として、Log4Shell (CVE-2021-44228) の際には、 稼働中の JVM にライブでパッチを当てるホットパッチ を AWS が開発してオープンソースとして公開し、AWS Fargate や AWS Lambda などのマネージドサービスの基盤には、お客様のアクションを必要とせず数日で展開しました。なお、要請ではクラウド事業者により提供される IT システムについて、パッチ適用に関する SLA/SLO の内容や適用状況が適切に報告される契約内容となっていることの確認が求められており、上記のホワイトペーパー・CAIQ 回答・SLA は、その確認の際の参考になります。 ⑥ パッチ適用プロセスをリスクベースにする CVSS スコアが高くない脆弱性でも実際の攻撃に使われる実態があり、この傾向はフロンティア AI によりさらに加速する可能性があります。Amazon Inspector は EPSS スコアや CISA の Known Exploited Vulnerabilities カタログ、公開された攻撃コードの有無、推奨パッチ適用期間といった脅威インテリジェンスを取り込み、攻撃が成立する蓋然性を踏まえた優先順位付けを可能にします。アプリケーションのテストとデリバリーについては、 AWS CodePipeline を中心とした CI/CD パイプラインで自動ビルド・自動テスト・段階デプロイ・自動ロールバックを構成することで、テスト不足によるシステム障害リスクを抑えつつパッチ適用期間を短縮できます。 ⑦ パッチ適用以外の対策も強化する 多層防御は、単一の対策の突破を前提に複数の防御層を重ねる、すべてのセキュリティ対策の基本です。パッチ適用も防御層の 1 つであり、適用そのものが困難な場合や適用までに時間を要する場合でも、他の層が攻撃の成立を防ぎ、被害を抑えます。要請では、こうした対策の例として、クラウド型の WAF 等を用いた「仮想パッチ」(個々の脆弱性に対応した侵入防御ルールにより、本来のパッチを早急に適用することが難しい場合に攻撃通信をブロックする暫定的なソリューション) の適用が挙げられています。AWS では、ウェブアプリケーションの層は AWS WAF が WAF 機能を提供し、既知の脆弱性を悪用する通信パターンをブロックするルールをまとめたマネージドルールが AWS により更新・提供されています。ネットワークの経路上では AWS Network Firewall が Suricata 互換の侵入防止システム (IPS) 機能を提供し、脆弱性を悪用する通信をシグネチャで検知・遮断するルールをまとめたマネージドルールグループが AWS により更新・提供されています。いずれも、アプリケーションやサーバーを修正するまでの間の防御層として利用できます。なお要請の脚注にあるとおり、こうした対策は恒久的な対応ではなく、パッチ適用までの暫定措置と位置づけることが重要です。このほか、ネットワーク分離、特権 ID への多要素認証、端末での不正検知・対応 (EDR) などがあります。要請が挙げる内部侵入後の横展開への対策としては、検知の層も必要です。 この多層防御の各層で活用できるのが、AWS の脅威インテリジェンスです。AWS は 1 日あたり 400 兆を超えるネットワークフローを分析し、 ハニーポットシステムの MadPot と、その脅威インテリジェンスをもとに悪意のあるアクティビティを自動的に制限する Sonaris を核とする アクティブディフェンス を運用しています。2025 年だけで Amazon S3 上のファイルへの不正暗号化の試み 3 億件超をブロックしました。この脅威インテリジェンスは AWS 内部の防御にとどまらず、お客様が利用できるサービスにも組み込まれています。 Amazon GuardDuty は AWS とサードパーティーの脅威インテリジェンスを機械学習と組み合わせてアカウントとワークロードのログを継続的に分析し、既知の脅威アクターとの通信や認証情報の悪用など、侵入後の横展開の兆候を検出します。 AWS Network Firewall のアクティブ脅威防御 は、MadPot が追跡するマルウェア URL やボットネットの C&C サーバー等の攻撃インフラを、マネージドルールグループ「AttackInfrastructure」として提供し、これらとの通信を自動的にブロックします。前述の AWS WAF マネージドルールも、この脅威インテリジェンスの還元先の 1 つであり、パッチ適用までの防御層として機能します。実例として、 React2Shell (CVE-2025-55182) では公開から数時間以内に国家支援型グループの悪用試行を MadPot で観測 し、Sonaris・AWS WAF マネージドルール等による多層の自動保護を展開したことをブログで公開しています。 ⑧ 優先サービス/IT システムの停止に備える 各種対策を徹底してもサイバー攻撃を防ぎきれない可能性を前提に、事業継続計画 (BCP) の有効性や緊急時の連絡体制、能動的なサービス停止の判断基準を明確にしておくことが求められます。これは共同運営形態やクラウド事業者が提供する IT システムについても同様です。マネージドサービスを活用している場合、基盤の可用性は AWS の責任範囲に含まれますが、業務要件に応じた構成、復旧目標、依存関係の整理、停止判断はお客様が設計・検証します。業務停止時の顧客対応手順も、引き続きお客様側で整備しておく必要があります。停止後の復旧の備えとしては、 AWS Backup の論理的にエアギャップされたボールトへのバックアップ保管が、ランサムウェア等でデータが侵害された場合の復旧手段の 1 つになります。 ⑨ 外部との連携を維持・強化する フロンティア AI に関する情報は短期間に多数公開されるため、自組織のみでの網羅的な把握は困難です。金融 ISAC や各業界団体・当局からの情報に積極的にアクセスするとともに、AWS からは AWS Security Bulletins や、 Amazon の脅威インテリジェンスチームによる注意喚起ブログ を通じた情報を継続的に提供しています。 AI の活用で脆弱性の発見を早める 要請への対応は「公開されるパッチにいかに追いつくか」が中心です。一方で Anthropic は、 Project Glasswing の拡大発表 の中で、6～12 か月以内に他の多くの AI 企業も Mythos クラスのモデルを持つと予想され、悪用を防ぐセーフガードなしにリリースされる可能性があると述べています。同様の能力が広く利用可能になれば、パッチが存在しない未知の脆弱性を突くゼロデイ攻撃への備えも重要性を増します。その 1 つとして、お客様自身が AI を活用して脆弱性を発見・修正するアプローチがあります。 AWS Security Agent (現在は AWS Continuum の一部) は、一般提供が開始されたオンデマンドペネトレーションテストにより、24 時間 365 日稼働する自律型のテストを手動テストと比べてわずかなコストで提供します。潜在的な脆弱性を特定した後に実際にエクスプロイトを試み、正当なリスクであることを検証したうえで、CVSS スコア・再現手順・修正提案付きでレポートします。設計ドキュメントや設計・ソースコードからの脅威モデリング (STRIDE 形式、プレビュー)、プルリクエストごとの自動スキャンとリポジトリ全体の深い分析の両方に対応するコードレビュー (プレビュー)、数時間で完了するペネトレーションテストと、設計からデプロイまでの開発ライフサイクル全体をカバーします。ペネトレーションテストは、AWS 上の環境だけでなく、他社クラウド上で稼働するシステムやオンプレミス、SaaS 環境にも対応します。新規のお客様は 2 か月間の無料トライアルを利用できます。 さらに、脆弱性を「見つけた後」の工程をマシンスピードで処理するのが AWS Continuum です。フロンティア AI により脆弱性の発見は速く・安価になった一方、どの脆弱性が自社のビジネスにとって重要かを判断し、実際に悪用可能かを検証し、修正までつなげる後工程は、人手による判断と部門間の調整に依存したままでは追いつきません。Anthropic 自身も、Project Glasswing の教訓として「制約は脆弱性を見つける速さではなく、検証・開示・修正の速さに移った」と述べています。Continuum for code vulnerabilities (限定プレビュー) はこの工程を対象とし、発見・優先順位付け・検証・緩和と修復という 4 つのフェーズを、脅威が生まれるのと同じマシンスピードで継続的に実行します。既存ツールの検出結果と独自スキャンを取り込み、インフラ・アクセス許可・ネットワーク構成などのコンテキストからビジネス影響を評価して優先順位付けし、隔離されたサンドボックス内で再現可能なエクスプロイトの構築を試みることで、悪用可能性が確認された問題に絞り込んだうえで、コードパッチやポリシー変更を提案します。これは、発見された脆弱性について「攻撃が成立する蓋然性も踏まえた評価」と「リスクベースの優先順位付け」を求める要請⑥の趣旨に沿ったアプローチです。動作は人間が推奨内容を確認して承認する learn モードから始まり、お客様の判断で自動修復 (enforce モード) へ段階的に引き上げる設計です。なお Continuum for code vulnerabilities は限定プレビューの段階にあり、金融サービス業界のお客様のフィードバックとともに形作られています。 独自のセキュリティワークフローを構築したい組織には、 Amazon Bedrock 上で複数のプロバイダーの最新フロンティアモデルから用途に合ったものを選ぶ選択肢があります。AWS PrivateLink の VPC エンドポイントを介して、インターネットを経由せずお客様の VPC から Bedrock に接続できます。ポリシー適用型のアクセス制御、モデルの検出効果を測る組み込みの評価ツール、お客様が定義したポリシーやドメインルールとの論理的一貫性を形式的手法で検証する自動推論チェック (AWS が公表した評価の範囲で最大 99% の検証精度)、カスタマイズ可能なガードレールを備え、自社のソースコードのスキャンを支援するワークフローの構築に活用できます。Amazon Bedrock は、日本政府のクラウドサービス評価制度である 「政府情報システムのためのセキュリティ評価制度 (ISMAP)」 の対象範囲に含まれています。また、Amazon Bedrock Marketplace を除き、Payment Card Industry Data Security Standard (PCI DSS) の対象範囲にも含まれています。これらの情報は、お客様が自組織のセキュリティ・コンプライアンス要件への適合性を評価する際の参考資料として利用できます。 まとめ – 今すぐ着手すること、中長期で取り組むこと フロンティア AI による脅威変化への対応は、2 つの観点から整理できます。 Project Glasswing 以降のパッチ公開ペースの変化に対しては、 今すぐパッチ適用を日常業務化し、インシデント対応体制を変革すること。中長期では、マネージドサービスを多用した IT システムのモダナイズにより、基盤レイヤーのパッチ運用の一部を AWS に委ね、お客様の運用負荷を軽減していくこと。 フロンティア AI の一般化により攻撃の高度化やゼロデイ攻撃のリスクが高まる可能性に対しては、 今すぐ AI を活用した脆弱性スキャンとセキュリティレビュー (AWS Security Agent、Amazon Bedrock + 最新モデル) で発見を早めること。中長期では、侵害を前提とした多層防御を徹底し、攻撃の影響を最小化すること。 いずれも、金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」に基づく基本的な対策を確実に実行することが土台です。まずは自組織の現状把握から始めることをお勧めします。無料アセスメントプログラムの SHIP と AWS セキュリティ成熟度モデルをご活用いただけますので、担当の AWS アカウントチームにお気軽にお声がけください。 早見表 – 金融庁・日本銀行の要請と AWS サービスの活用 金融庁・日本銀行が求める 9 つの短期的対応について、AWS のサービス・機能がどう役立つかを一覧に整理しました。 # 金融庁・日本銀行の要請 AWS サービスの活用 (主なサービス・機能) ① フロンティア AI への対応を経営課題として扱う SHIP (無料) と AWS セキュリティ成熟度モデルで現状を客観評価し、経営としての優先順位付けとリソース配分の判断材料を提供 ② 優先的に対応すべきサービス/IT システムを特定する AWS Config / Systems Manager インベントリで資産を把握。Amazon Inspector が CVSS・ネットワーク到達性・悪用可能性を相関したリスクスコアを算出し、外部公開システムからの優先対処を支援。AWS Continuum (限定プレビュー) は組織のコンテキストから IT 資産の重要度を考慮した優先順位付けを支援 (業務影響の最終評価はお客様の判断) ③ 特定した資産の技術負債を解消しておく Amazon Inspector の SBOM (CycloneDX/SPDX) エクスポートで構成を可視化。Inspector SBOM Generator で CI/CD 内の SBOM 生成も可能。マネージドサービス移行で OS・ミドルウェア層の技術負債を構造的に削減 ④ パッチ適用に係る人的リソースを追加する 短期: Systems Manager Patch Manager でパッチ作業を自動化 (オンプレミス含む)。中長期: サーバーレス/マネージドサービス (Lambda、Fargate、Aurora Serverless、DynamoDB 等) で、責任共有モデルのもと、基盤インフラと AWS が管理するランタイムのパッチ適用を AWS の責任範囲に (コンテナイメージや依存関係はお客様責任)。マネージドサービスの多くは複数 AZ 上に構築されたリージョンサービスで、月間稼働率のサービスコミットメントを定めた SLA を公開 ⑤ ベンダーとの維持保守契約の内容を確認する AWS 全体の変更管理は CAIQ 回答で公開 (中断最小化・ロールバック計画・継続的デプロイ)。DynamoDB はメンテナンスウィンドウなし、Aurora は ZDP によりエンジン更新時のクライアント接続の維持を試みる (例: Log4Shell の稼働中 JVM ホットパッチ )。SLA/SLO・報告内容の確認の参考に ⑥ パッチ適用プロセスをリスクベースにする Amazon Inspector が EPSS・CISA KEV・攻撃コードの有無を取り込みリスクベースで優先順位付け。AWS Continuum (限定プレビュー) が悪用可能性をサンドボックスで検証し、確認された問題から修正を提案。AWS CodePipeline で自動テスト・段階デプロイ・自動ロールバック ⑦ パッチ適用以外の対策も強化する AWS WAF と AWS Network Firewall (IPS 機能) の各マネージドルールによる脆弱性悪用通信の遮断 (パッチ適用までの暫定措置)、ネットワーク分離、多要素認証、EDR 等の多層防御。脅威インテリジェンスを活用した防御として、Amazon GuardDuty (侵入後の兆候検知)、AWS Network Firewall アクティブ脅威防御 (攻撃インフラとの通信ブロック)。 AWS のアクティブディフェンス (MadPot/Sonaris) が観測した脅威を各サービスにフィードバック ⑧ 優先サービス/IT システムの停止に備える マネージドサービスの基盤の可用性は AWS の責任範囲。業務要件に応じた構成・復旧目標・停止判断の設計と検証、BCP・顧客対応手順の整備はお客様側で実施。AWS Backup の隔離バックアップが復旧手段の 1 つに ⑨ 外部との連携を維持・強化する AWS Security Bulletins と脅威インテリジェンスに基づく情報提供。金融 ISAC 等との連携を補完 加えて、公開されるパッチへの追随の先にある、AI による攻撃の高度化やゼロデイ攻撃への備えとして、 AWS Security Agent (一般提供のペネトレーションテストに加え、脅威モデリングとコードレビューはプレビューで提供)、 AWS Continuum (限定プレビュー。脆弱性の発見から優先順位付け・検証・修復までのライフサイクル全体をマシンスピードで自律処理)、 Amazon Bedrock + 最新フロンティアモデル (ソースコードのセキュリティレビューを支援するワークフローの構築。VPC エンドポイント経由で接続可能) をご活用いただけます。 関連情報 「フロンティア AI による脅威変化を踏まえた金融機関等の短期的な対応」に係る要請について (金融庁) AI を活用した大規模なセキュリティ防御の構築 – 脅威が出現する前に AWS Continuum のご紹介: マシンスピードで実現するセキュリティ AWS Security Agent のオンデマンドペネトレーションテストの一般提供を開始 FISC 安全対策基準・解説書に関する AWS の情報 本記事は、金融庁・日本銀行 「フロンティア AI による脅威変化を踏まえた金融機関等の短期的な対応」に係る要請 (2026 年 5 月 22 日) および AWS の公開情報に基づいて作成しています。本記事で紹介するサービス・機能は代表的な例であり、すべての選択肢を網羅するものではありません。また、特定の対策の実施により被害の防止を保証するものではありません。記載のサービス仕様・提供状況・料金は変更される場合があります。最新情報は各サービスの公式ドキュメントをご確認いただき、具体的な対策の選定は自組織の環境に応じてご判断ください。 著者 能仁 信亮 (Shinryo Nonin) – 金融ソリューション本部 プリンシパルソリューションアーキテクト 中島 章博 (Akihiro Nakajima) – パブリックセクター技術統括本部 シニアセキュリティソリューションアーキテクト

G-gen の松尾です。当記事では、Google Cloud と Amazon Web Services（AWS）をプライベートに接続する Partner Cross-Cloud Interconnect for AWS について解説します。 概要 Partner Cross-Cloud Interconnect for AWS とは 対応リージョン transport リソース Cross-Cloud Interconnect との比較 料金 接続方式 接続方式の違い VPC ネットワークピアリング Network Connectivity Center 2 つの方式の比較 接続の表示・更新・削除 注意点 概要 Partner Cross-Cloud Interconnect for AWS とは Partner Cross-Cloud Interconnect for AWS は、Google Cloud と Amazon Web Services（以下、AWS）の間にプライベートな専用線接続を提供するマネージドサービスです。対応するペアリングロケーションであれば、両クラウドのリソースをインターネットを経由することなくセキュアに相互接続できます。 本サービスの最大の特徴は、ネットワークサービスプロバイダーとの回線契約や、クラウド間のポート申請等の物理回線の手配が不要である点です。Google Cloud と AWS の両社が共同設計したインフラを利用するため、数ステップの操作を行うだけで、わずか数分で専用線の接続ができます。Google Cloud 側では、VPC ネットワークピアリングや Network Connectivity Center スポークといったクラウドリソースとして接続を管理できます。 参考 : AWS 向け Partner Cross-Cloud Interconnect の概要 参考 : 画期的な AWS とのコラボレーションで Google Cloud のクロスクラウド ネットワークを拡大 なお2026年8月現在、Google Cloud および AWS の東京リージョンや大阪リージョンには対応していない点に注意が必要です。 対応リージョン Partner Cross-Cloud Interconnect for AWS では、Google Cloud のリージョンと AWS のリージョンが、あらかじめ決められたペアとして定義されています。2026年8月現在、対応するリージョンペアは以下のとおりです。最新の一覧は以下の公式ドキュメントを参照してください。 Google Cloud リージョン AWS リージョン asia-southeast1（シンガポール） ap-southeast-1（シンガポール） europe-west2（ロンドン） eu-west-2（ロンドン） europe-west3（フランクフルト） eu-central-1（フランクフルト） us-east4（バージニア） us-east-1（バージニア北部） us-west1（オレゴン） us-west-2（オレゴン） us-west2（ロサンゼルス） us-west-1（北カリフォルニア） 参考 : ペアリング ロケーションを選択する transport リソース このサービスの中心となるのが transport リソースです。物理的な相互接続や VLAN アタッチメント、Cloud Router インスタンスをひとまとめに抽象化したマネージドサービスのリソースです。 従来の Cross-Cloud Interconnect では、こうした構成要素を 1 つずつ自分で用意して管理する必要がありました。一方の Partner Cross-Cloud Interconnect for AWS では、Google Cloud 側の transport リソースと AWS 側の Direct Connect ゲートウェイを結びつけるだけで、セキュアなマルチクラウド専用接続の確立が完了します。 Google Cloud と AWS のリソース同士を結びつけるために アクティベーションキー を使用します。起点となるクラウド側でキーを発行し、もう一方がそのキーを登録して自クラウドのリソースを作成する仕組みです。この相互連携により、プロビジョニングをどちらのクラウドからでも開始できます。 参考 : AWS 向け Partner Cross-Cloud Interconnect のプロビジョニングの概要 Cross-Cloud Interconnect との比較 Cross-Cloud Interconnect は、Google Cloud と AWS をはじめとする他社クラウドのネットワークを、専用の物理接続でプライベートに接続するサービスです。Partner Cross-Cloud Interconnect for AWS は Cross-Cloud Interconnect の発展形と位置づけられています。 従来の Cross-Cloud Interconnect では、物理回線を手配し、VLAN アタッチメントなどのネットワークリソースを自分で設定する必要がありました。Partner Cross-Cloud Interconnect for AWS ではこの工程がなくなり、接続が使えるようになるまでの時間は大きく縮まります。冗長性も基盤側にあらかじめ組み込まれているため、利用者が冗長構成を設計したり管理したりする必要はありません。 Cross-Cloud Interconnect についての詳細は、以下の記事を参照してください。 blog.g-gen.co.jp Cross-Cloud Interconnect と Partner Cross-Cloud Interconnect for AWS の主な違いは、以下のとおりです。 項目 Cross-Cloud Interconnect Partner Cross-Cloud Interconnect for AWS 接続先 OCI、AWS、Azure、Alibaba Cloud など AWS 物理的な配線工事 発生する 発生しない 物理ポート申請（LOA の取得・提出） 必要 不要 接続の発注元 Google Cloud から発注 Google Cloud または AWS の双方向 料金 Cloud Interconnect 接続・VLAN アタッチメント・下り（Egress）トラフィックに課金 transport リソースのみに課金 参考 : AWS 向け Partner Cross-Cloud Interconnect の概要 - Cross-Cloud Interconnect との比較 料金 Partner Cross-Cloud Interconnect for AWS の料金は、 transport リソースの時間単位の課金 で構成されます。transport がアクティブな時間に対して、選択した帯域とリージョンに応じた料金が発生します。 特徴は、 データ転送量に対する従量課金がない点 です。従来の Cross-Cloud Interconnect では、接続の時間課金に加えて、Virtual Private Cloud（以下、VPC）ネットワークからの下り（Egress）データ転送にも料金がかかりました。しかし、Partner Cross-Cloud Interconnect for AWS では、上り（Ingress）・下り（Egress）ともにデータ転送料金は発生しません。 なお、後述する 2 つの接続方式である VPC ネットワークピアリングと Network Connectivity Center（NCC）のどちらを選んでも、Partner Cross-Cloud Interconnect for AWS 自体の料金は変わりません。料金はあくまで transport リソースの帯域に対する時間課金で決まるためです。 ただし、料金には注意点が 2 つあります。1 つは、NCC を使用する場合、Partner Cross-Cloud Interconnect for AWS の料金とは別に NCC の利用料金が発生する点です。もう 1 つは、接続先となる AWS 側でも、AWS Interconnect（multicloud オプション）など対象サービスの料金が別途発生する点です。 詳細は以下の公式ドキュメントを参照してください。 参考 : Cloud Interconnect pricing - Partner Cross-Cloud Interconnect 参考 : Network Connectivity pricing 接続方式 接続方式の違い Partner Cross-Cloud Interconnect for AWS では、Google Cloud 側のネットワーク構成として、 VPC ネットワークピアリング を使用する方式と、 Network Connectivity Center （NCC）を使用する方式の 2 つがあります。 前者は単一の VPC ネットワークと AWS を 1 対 1 で接続するシンプルな構成、後者は複数の VPC やハイブリッド接続を集約管理する規模の大きいネットワーク向けの構成です。 参考 : AWS 向け Partner Cross-Cloud Interconnect のプロビジョニングの概要 VPC ネットワークピアリング VPC ネットワークピアリングを使用する方式は、transport リソースを単一の VPC ネットワークに接続する構成です。特定の VPC ネットワークと AWS を 1 対 1 でプライベートに接続したい場合に適しています。 transport リソースを作成すると、中継用のピアリング VPC ネットワークが自動的に生成されます。利用者は、この自動生成されたピアリング VPC ネットワークと、自身のワークロード VPC ネットワークを VPC ネットワークピアリングで接続します。これにより、ワークロード VPC（図最左部）と AWS のリソース（図右部）が、自動的に交換されるルートを通じて通信できます。構成のイメージは以下のとおりです。 VPC ネットワークピアリングを使用する場合 参考 : Google Cloud から開始する接続を作成する - VPC ネットワーク ピアリングを使用する 参考 : AWS から開始する接続を作成する - VPC ネットワーク ピアリングを使用する VPC ネットワークピアリングについての詳細は、以下の公式ドキュメントを参照してください。 参考 : VPC ネットワーク ピアリングの概要 Network Connectivity Center Network Connectivity Center（NCC）を使用する方式は、transport リソースを NCC のハブにスポークとして接続する構成です。NCC は、複数の VPC ネットワークやハイブリッド接続をハブアンドスポークのモデルで集約的に管理するためのサービスです。NCC を使用すると、複数の VPC ネットワークや他の外部接続をまたいでルートを一元的に管理できます。複数の VPC や複数のクラウド接続を統合的に扱いたい、規模の大きいネットワークに適した方式です。 なお NCC を使用する方式は 2026年8月現在、Preview ステージです。Preview ステージの機能には技術サポートや SLA が提供されないこと、また一般公開せずに終了したり、一般提供の際に仕様が変更される可能性がある点に留意してください。Preview 版のサービスや機能を使用する際の注意点は、以下の記事も参照してください。 blog.g-gen.co.jp transport リソースを NCC のハブにスポークとして接続すると、ハブが各スポーク間でルートを伝播します。これにより、ハブに接続した複数の VPC ネットワークやハイブリッド接続（オンプレミスとの接続等）と AWS との間で、ルートを一元的に交換できます。VPC ネットワークピアリング方式が単一の VPC との 1 対 1 接続であるのに対し、NCC 方式は複数のネットワークを 1 つのハブに集約できる点が大きな違いです。構成のイメージは以下のとおりです。 Network Connectivity Center を使用する場合 参考 : Google Cloud から開始する接続を作成する - Network Connectivity Center を使用する 参考 : AWS から開始する接続を作成する - Network Connectivity Center を使用する NCC についての詳細は、以下の記事を参照してください。 blog.g-gen.co.jp 2 つの方式の比較 2 つの方式の違いを以下に整理します。 観点 VPC ネットワークピアリング NCC 提供ステージ 一般公開（GA） Preview Google Cloud 側の接続先 単一の VPC ネットワーク NCC のハブ（スポークとして接続） 適した規模 単一 VPC と AWS の 1 対 1 接続 複数 VPC・複数接続の集約管理 接続の表示・更新・削除 接続の表示、更新、削除は、transport リソースを通じて行います。gcloud CLI、Google Cloud コンソールまたは API を使用します。 当記事では、gcloud CLI を使用した場合の操作を紹介します。 接続を一覧表示するには、 gcloud network-connectivity transports list コマンドを使用します。リージョンを指定すると、transport の名前、プロファイル、帯域、状態（State）が一覧で確認できます。 gcloud network-connectivity transports list \ --region = LOCATION 特定の transport の詳細を確認するには、 gcloud network-connectivity transports describe コマンドを使用します。説明（description）の更新や、広告されるルート（advertisedRoutes）の確認ができます。 transport を削除するには、 gcloud network-connectivity transports delete コマンドを使用します。 gcloud network-connectivity transports delete TRANSPORT_NAME \ --region = LOCATION transport を削除しても AWS 側のリソースは削除されません。接続を完全に解除する際は、Google Cloud 側と AWS 側の両方をクリーンアップする必要がある点に注意してください。 参考 : 接続を管理する 注意点 transport リソースにはプロジェクトごと・リージョンごとのクォータがあり、デフォルトでは各プロジェクトがリージョンあたり 1 つに制限されます。複数必要な場合は、クォータの引き上げを検討してください。 Google Cloud のワークロード VPC と AWS VPC の MTU は揃える必要があります。MTU が一致していないと、パケットのドロップやフラグメンテーションが発生します。その結果、データ損失・スループットの低下・インターコネクト全体での接続切断につながります。 VPC ネットワークピアリング方式を利用して transport リソースを作成する際、 Network MTU 1460B does not match the peer's MTU 8896B といった警告が表示されることがあります。これは、ワークロード VPC と、前述のピアリング VPC ネットワーク（8896 バイト固定）との MTU 差分を検知した警告です。ピアリング VPC ネットワークは最大値で固定されているため、この区間自体がボトルネックになることはありません。一方で、ワークロード VPC と AWS VPC の MTU は前述のとおり一致させる必要があります。この警告が表示されても、両端の MTU が揃っていれば通信に問題はありません。 SLA は、Google と AWS がそれぞれ自社の管理する接続区間に対して提供します。 各項目の詳細は、以下のドキュメントを参照してください。 参考 : Create a connection initiated from AWS with VPC Network Peering 参考 : AWS Interconnect が一般提供され、ラストマイル接続を簡素化する新しいオプションが追加されました 松尾 和哉 (記事一覧) クラウドソリューション部 これまで主にAWSを活用する企業でインフラエンジニアとして従事していました。Google Cloudに魅力を感じてG-genにジョイン。アウトプットを経てコミュニティへの還元や自己研鑽をしたいと思っています。

本記事は 2026 年 7 月 20 日 に公開された「 Introducing KNFSD File Cache: Extending your NFS storage into the clouds 」を翻訳したものです 長年にわたり、 Amazon Web Services (AWS) はコンピューティングインフラをスケールアップ、スケールアウト、そして広域展開する手段を提供してきました。一方、ストレージ面、特に Network File System (NFS) を基盤とし、オンプレミスやハイブリッド環境にデータを持つ組織にとっては、同じペースで進化が進んでいませんでした。コンピューティング負荷の高いワークロードでより高いスループットが必要な場合、並列ジョブ向けに高速な共有アクセスが必要な場合、あるいはデータを複製せずに別の AWS リージョンやアベイラビリティーゾーンにコンピューティングを配置したい場合でも、課題は共通しています。移行やクライアント側の変更なしに、弾力的なコンピューティングに見合ったデータアクセスのスケールを実現することは、依然として難しい問題でした。 KNFSD File Cache (KNFSD) はその課題を解決します。 Amazon Elastic Compute Cloud (Amazon EC2) 上で動作するオープンソースの NFS キャッシングプロキシソリューションで、既存の NFS サーバーを透過的に AWS へ拡張します。クラウドインスタンスのすぐ近くに高性能なキャッシュ層を配置することで、ワークロードの実行場所を問わず、共有データへの高速アクセスを実現します。 本記事では、KNFSD の仕組みと、オンプレミスのファイラー、サードパーティ製品、 Amazon FSx などの AWS サービスを含む NFS 準拠のストレージとの組み合わせ方を説明します。また、単一の Terraform モジュールで本番環境向けのオートスケーリングクラスターをデプロイする方法と、100 Gb/秒の合計スループットを 1 時間あたり 6 ドル未満で実現する方法についても解説します。 「AWS との共同作業で行った初期の KNFSD プロトタイプにより、極めて長距離でも高性能なキャッシングがクラウドレンダリングで実用的であることが証明されました。KNFSD File Cache 向けの新しい AWS Solution Guidance の採用を楽しみにしています。これは、私たちが手作業で構築しなければならなかった機能をまさに製品化したものです。」 – Kimball Thurston、CTO、Wētā FX 対象となるユーザー KNFSD は、クラウド上の NFS データへの高性能かつ読み取り中心のアクセスと、ソースへの書き戻しが必要なあらゆる組織を対象に設計されています。ユースケースには以下が含まれますが、これらに限りません。 読み取り I/O が多いコンピューティング集約型の業界: 既存の NFS インフラに保存された大規模データセットへの高速な共有アクセスを必要とするワークロード全般。メディア & エンターテインメント (レンダーファーム)、ハイパフォーマンスコンピューティング、金融サービス、ヘルスケア & ライフサイエンス、エネルギー、気象 & 気候科学などが含まれます。 ハイブリッドクラウドおよびマルチクラウド: オンプレミスのファイラーや他のクラウドプロバイダーから、データの移行や複製なしに既存の NFS インフラを AWS へ拡張したい組織。 マルチリージョンおよびマルチ AZ : AWS リージョンまたはアベイラビリティーゾーン をまたいでコンピューティングを分散させるスタジオや研究チーム。KNFSD がデータをローカルにキャッシュすることで、中央の NFS ソースへのレイテンシーを解消します。 「KNFSD キャッシングソリューションは期待を上回る結果をもたらしました。開発中に AWS と協力し、本番環境でのスケール運用に必要な重要な内部メトリクスが確実に公開されるようにしたことで、独自ツールの構築が不要になりました。この取り組みのおかげで、不確実な状態から脱却し、複数のプロジェクトにわたって本番環境でこのソリューションを効果的に運用できるという確信を持てるようになりました。」 – Greg Newman、シニアマネージャー、プロダクションエンジニアリング & デジタルリソース、Industrial Light & Magic (ILM) KNFSD File Cache とは KNFSD は、ハイブリッドおよびバーストコンピューティングのユースケース向けに設計された高性能 NFS キャッシングプロキシを提供する、オープンソースの AWS Solution Guidance です。既存のオープンソースプロジェクトをフォークし、AWS との統合機能を加えて拡張しています。AWS 上での動作最適化 ( AWS Graviton を含む)、開発環境および本番環境向けのコンテナサポート、OpenTelemetry と Amazon CloudWatch を活用した包括的なメトリクスダッシュボード、そして Common Vulnerabilities and Exposure (CVE) 対策による強化されたセキュリティを備えています。 KNFSD File Cache は、実績ある Linux カーネル技術を基盤としています。 nfs-kernel-server – NFS マウントの再エクスポートをサポートする Linux カーネルネイティブの NFS サーバーです。プロキシがソースの NFS エクスポートをマウントし、まるで元のファイラーであるかのように下流のクライアントへ提供します。 cachefilesd (FS-Cache) – ネットワークファイルシステムのデータをローカルディスクに永続的にキャッシュする Linux カーネルモジュールです。同じファイルへの再リクエスト時は、ソースから取得するのではなく、キャッシュから直接提供されます。 KNFSD は kernel NFS daemon の略で、ソリューションを支えるカーネル空間コンポーネントへの敬意を込めた名称です。独自エージェント、ベンダー固有のプロトコル、特定のストレージソリューションへの依存は一切ありません。既存のファイラーに対して NFSv3 または NFSv4 で通信できる NFS クライアントであれば、変更なしに KNFSD と連携できます。 2 段階のキャッシュ KNFSD は、各プロキシインスタンスに 2 層のキャッシュ階層を提供します。 レイヤー 技術 媒体 特性 L1 Linux ブロックキャッシュ RAM 超低レイテンシー、インスタンスメモリ量に依存 L2 FS-Cache (cachefilesd) ローカル NVMe 高スループット、再起動後もデータが保持され、テラバイト級の容量 クライアントがファイルをリクエストすると、プロキシはまず L1 (RAM) を確認します。RAM からデータが退避されている場合は、L2 (NVMe ディスク) がローカルストレージの速度で提供します。完全なキャッシュミスが発生した場合のみ、プロキシはソースファイラーからデータを取得します。ファイルの取得後、そのプロキシに接続しているクライアントからの後続の読み取りはキャッシュから提供されます。 “EngineLab では、Barnstorm VFX などのスタジオ向けクラウドバーストレンダリングアーキテクチャの中核として KNFSD を導入しています。オンプレミスのコンピューティングリソースが枯渇した瞬間に AWS 上でレンダリング容量をスケールでき、KNFSD が限られた帯域幅接続でテクスチャなどの共通アセットを効率的にキャッシュします。レンダリング中はコンピューティングの料金のみを支払い、不要な時はゼロにスケールダウンできます。私たちが目指しているのはまさにこれです。インフラの制約を取り除くことで、お客様がクリエイティブな作業に集中し、より野心的なプロジェクトに挑戦でき、レンダーファームの規模によって締め切りが左右されることのない環境を実現することです。” – Sam Reid、CEO/Co-Founder、EngineLab 仕組み アーキテクチャはシンプルです。次の図は、コンピューティングが低レイテンシー・高帯域幅で NFS データにアクセスできるよう、KNFSD を使って再エクスポートされた NFS データへのローカルアクセスを提供するデプロイ構成を示しています。 図 1: KNFSD アーキテクチャ図 この構成には以下の機能が含まれています。 ソースマウント – 各プロキシインスタンスは、オンプレミスのファイラー、NFS 対応の Amazon FSx サービス、別のアベイラビリティーゾーンやリージョン、または他のクラウドプロバイダーなど、ソース NFS デバイスのエクスポートをマウントします。 接続 – KNFSD は、 AWS Site-to-Site VPN 、 AWS Direct Connect 、 AWS Interconnect (マルチクラウド) など、他の AWS インフラと同じ接続方式をサポートし、オンプレミスストレージへの安全で低レイテンシーなアクセスを提供します。 負荷分散 – Amazon EC2 Auto Scaling グループ が複数の KNFSD インスタンスを管理します。クライアントトラフィックは DNS ラウンドロビンまたは Elastic Load Balancing (Network Load Balancer) で分散されます。 クライアントへの透過性 – NFS クライアントは、通常の NFS 共有と同じ方法で KNFSD のエクスポートをマウントできます。特別なドライバー、エージェント、設定は不要です。 利用 – Amazon EC2 インスタンスはワークロードの処理に合わせてスケールし、変更なしに KNFSD 経由でソースデータにアクセスし、必要に応じて結果を書き戻します。また、スループット要件の増加に応じて KNFSD インスタンスのスケールアップを促すシグナルを提供します。 “NFS キャッシュは、長年にわたってお客様から繰り返しご要望いただいてきた機能です。自信を持ってお客様に提案できる AWS サポート付きのソリューションが登場したことを嬉しく思います。” – Paul Judkins、VP Cloud Services、Integrated Media Technologies (IMT) Global KNFSD File Cache の位置づけ AWS は幅広いストレージサービスを提供しています。耐久性の高いオブジェクトストレージと分析向けの Amazon Simple Storage Service (Amazon S3) 、フルマネージドの高性能ファイルシステム向けの Amazon FSx、そして弾力的なサーバーレス NFS 向けの Amazon Elastic File System (Amazon EFS) などがあります。これらはいずれも、対象ワークロードのプライマリストアとして設計されています。 データを移行したりクライアントのマウントパスを変更したりすることなく、既存の NFS ソースからバーストスケールのスループットを必要とするワークロードには、透過的なアクセラレーションレイヤーが必要です。 Amazon File Cache や Amazon FSx for NetApp ONTAP FlexCache などのマネージドオプションはこれらのシナリオの一部に対応していますが、Amazon EC2 上で動作するシンプルで低コストなオープンソースのキャッシュレイヤーが最適なケースも多くあります。特に、チューニングの完全な制御、透過的な NFS 再エクスポートのセマンティクス、そして柔軟なスケールアップ・スケールアウトが必要な場合に適しています。 KNFSD が埋めるのはこのニッチです。リポジトリには、強化された AMI、ルート Terraform モジュール (複数の子モジュールと独立したデータベース・メトリクスモジュールを含む)、組み込みのオブザーバビリティ、ヘルスチェック、オートスケーリング、ファンアウトトポロジーが含まれています。 キャッシュは KNFSD 層に保持されるため、ダウンストリームのコンピューティングインスタンスを Amazon EC2 スポットインスタンス (AWS が短い通知で回収できる、大幅に割引された中断可能なキャパシティ) として実行しても、データ損失や再取得のリスクはありません。スポットインスタンスが回収されて新しいインスタンスに置き換えられた場合も、新しいインスタンスはすぐにウォームキャッシュの恩恵を受けられます。 “『Avatar: The Way of Water』では、オンプレミス設備の 250% の規模のクラウドレンダーファームを運用し、AWS と共同開発した NFS キャッシュがショーのデータへのアクセスをスケールさせる上で不可欠な役割を果たしました。Avatar 後に改善点として挙げていた領域 (弾力的なスケーリング、ロードバランシング、階層型キャッシング) は、まさに AWS が KNFSD File Cache に組み込んだ機能です。ハイブリッドレンダーパイプライン全体への導入と、オープンソースプロジェクトへの貢献を楽しみにしています。” – Andy Wright、Head of Pipeline、Wētā FX 主な機能 KNFSD は、迅速なデプロイ、シンプルな運用、初日からのオブザーバビリティを実現するよう設計されています。このセクションでは、本番環境で特に重要な機能を説明します。 事前構築済み AMI リポジトリには Packer ビルドスクリプトが含まれており、Ubuntu ベースの最適化された Amazon Machine Images (AMI) を生成します。従来の x86 Intel・AMD プロセッサと、AWS Graviton Processors (ARM64) などの ARM ベースプロセッサの両アーキテクチャに対応しています。 Packer ビルドで作成されるイメージには以下が含まれます。 NFS 再エクスポートと FS-Cache を有効化したチューニング済み Linux カーネル CloudWatch と OpenTelemetry を使用したオブザーバビリティ向けの KNFSD メトリクスエージェント ヘルスチェックとステータス確認用の KNFSD HTTP エージェント ビルド検証用のスモークテスト AWS はストレージ最適化された Amazon EC2 インスタンス (L2 層向けのローカル NVMe 搭載) を幅広く提供しており、各パイプラインステージのアクセスパターンに合わせて KNFSD インスタンスを選択できます。数百万件の小さなファイル読み取りが中心のワークロードには、最新の i7ie および i8g ファミリーの低レイテンシー NVMe が適しており、大きなシーケンシャル読み取りには im4gn および i3en ファミリーの高スループットと大容量キャッシュが有利です。 AWS Graviton の優位性は特に注目に値します。NFS 再エクスポートとディスクキャッシングは、高いシングルスレッド性能を必要とせず複数コアに並列化しやすいため、AWS Graviton のアーキテクチャと自然に適合します。im4gn.16xlarge は i3en.24xlarge と同等の毎秒 10〜12 GB のスループットを、オンデマンドの時間単価でおよそ半分のコストで実現します。次の表は比較のための Amazon EC2 インスタンスタイプの一例です。最新のインスタンスタイプとリージョン別料金については、 Amazon EC2 インスタンスタイプ のドキュメントをご参照ください。 インスタンス アーキテクチャ ネットワーク ローカルNVMe $/時間 ** 用途 im4gn.16xlarge ARM 100 Gbps 30 TB $5.82 高スループット、GB/sあたりのコスト効率が最適 i8g.16xlarge ARM 50 Gbps 15 TB $5.49 最新世代NVMe、小規模ファイルのIOPSワークロード i3en.24xlarge x86 100 Gbps 60 TB $10.85 大容量キャッシュ、KNFSDの主力インスタンス i7ie.48xlarge x86 100 Gbps 120 TB $24.95 NVMeレイテンシが65%改善、レイテンシに敏感な読み取り処理 ** 執筆時点の US-East-1 (バージニア北部) の料金 ファンアウトアーキテクチャ 多数のクライアントが同じ大規模データセットを読み取るワークロードに対して、KNFSD はオプションの 2 層ファンアウトデプロイをサポートしています。単一の高メモリプロキシ (Tier 1) がソースファイラーとの通信をすべて処理することで、各ファイルが広域ネットワーク (WAN) を通過するのを 1 回のみに抑え、高レイテンシー・低帯域幅の環境にも対応します。2 つ目の小規模プロキシクラスター (Tier 2) がファンアウトして数百のクライアントを提供します。これにより、キャッシュソリューションは実質的に 2 つの役割に分かれます。プライマリの Tier 1 KNFSD インスタンスによる初回の長距離転送と NFS 再エクスポート、そしてクライアントに直接 NFS を提供するセカンダリ Tier 2 KNFSD インスタンスの仕様と最適化です。この構成により、セカンダリ KNFSD インスタンスはクラウド側のキャッシュ充填を維持しながらスケールアップ・ダウンおよびスケールイン・アウトが可能となり、初回の長距離転送の繰り返しを防ぎ、インフラ変更後も迅速に再キャッシュできます。次の図は基本的なファンアウトアーキテクチャを示しています。 図 2: 2つのティアの例, KNFSD ファンアウトアーキテクチャ この構成には以下の機能が含まれています。 ソースマウント – データのキャッシュ元となり、処理済みデータの書き戻し先となるソース NFS ファイルサーバーです。 長距離転送 – データはプライマリの Tier 1 KNFSD インスタンスにキャッシュされ、低帯域幅・高レイテンシー環境に対応します。 Tier 1 KNFSD インスタンス – このプライマリ層のインスタンスは、長距離トラフィックのキャッシュを一元的に担い、書き込みをソースファイラーに返します。 キャッシュ間転送 – KNFSD の Tier 1 と Tier 2 インスタンス間のデータ転送は、 Amazon Virtual Private Cloud (Amazon VPC) 内で行われます。 Tier 2 KNFSD インスタンス – スループット要件に対応するためにファンアウト構成を取るインスタンスです。ワークロードの性能特性に合わせてインスタンスタイプを選択でき、ローカルの Amazon VPC を活用した高速転送が可能です。 コンピュート・キャッシュ間転送 – コンピュートインスタンスは、同じ低レイテンシー・高帯域幅のローカル Amazon VPC 接続を使用して Tier 2 KNFSD インスタンスにマウントします。 エラスティックコンピュート – Amazon EC2 インスタンスはワークロードの処理に合わせてスケールし、変更なしに Tier 2 KNFSD インスタンス上の依存ソースデータにアクセスします。必要に応じて結果を書き戻し、スループット要件を満たすために Tier 2 のスケールアップを促すシグナルも提供します。 オブザーバビリティとメトリクス 従来の NFS インフラはクローズドなシステムとして運用されることが多く、ストレージが遅いと感じていても、その原因を診断したり、キャパシティに関する適切な判断を下したりするための詳細情報が不足しがちです。KNFSD は、CloudWatch Agent と OpenTelemetry ベースの KNFSD メトリクスエージェントを使用して、70 以上のカスタムメトリクスを CloudWatch に公開します。これらのメトリクスはキャッシュインフラの各層を包括的に可視化し、インフラのパフォーマンスをデータに基づいて深く理解するための基盤を提供します。以下の図は、ダッシュボードに表示されるメトリクスの例を複数示しています。 図 3: KNFSDで利用可能な複数の指標ビュー メトリクスのカテゴリ 公開されているメトリクスは、次の 5 つの主要領域をカバーしています。 NFS 接続数とクライアント数 – クラスターの使用率を追跡し、KNFSD インスタンスのスケールアウトが必要なタイミングを把握できます。 読み取り/書き込みスループットとレイテンシー (RTT および EXE) – クライアントがローカル速度に近いパフォーマンスを得られているかを確認し、劣化を早期に検出できます。 FS-Cache のヒット率/ミス率、LRU (least recently used) アクティビティ、ストレージ使用率 – ソースからデータを取得するのではなく、キャッシュがホットデータをどれだけ効果的に提供できているかを把握できます。 NFS スレッドおよびソケットのキュー深度 – プロキシのリクエスト処理パイプラインの飽和を、クライアントに影響が出る前に検出できます。 マウント別・エクスポート別の内訳 – 負荷の原因となっている特定のエクスポートやソースサーバーを特定し、ピンポイントでチューニングできます。 これらのメトリクスを組み合わせることで、プロキシの健全性、キャッシュの有効性、クライアント側の体感を総合的に把握でき、キャパシティ、パフォーマンスチューニング、コスト最適化に関する適切な判断が可能になります。 「AWS がメトリクスと直接連携し、実際の状況をリアルタイムで把握できるソリューションを提供してくれたことは、非常に大きな意味を持ちます。ダッシュボードは完成度が高く、ほとんどのチームがレンダーファームのデータについて持ち得ないレベルの可視性を提供してくれます。」 – Rob Dueckman、シニアソリューションアーキテクト、Integrated Media Technologies (IMT) Global 構築済み CloudWatch ダッシュボード 標準のインフラストラクチャーアズコードデプロイの一環として、構築済みの CloudWatch ダッシュボードがクラスターと同時にデプロイされます。手動でメトリクスを設定することなく、すぐに可視化を開始できます。ダッシュボードにはキャッシュヒット率、アクティブオブジェクト数、読み取り/書き込み帯域幅、IOPS、プロキシごとのトラフィック分散など、運用上重要なメトリクスが一目で確認できる形で表示されます。 Prometheus および Grafana へのエクスポート メトリクスエージェントは OpenTelemetry ベースのため、必要に応じてテレメトリを Prometheus や Grafana にエクスポートすることも可能です。 インフラのサイジングとコスト管理 最も重要なメトリクスであるキャッシュヒット率は、プロキシがオリジンサーバーへの読み取り負荷をどれだけ効果的に吸収できているかを直接示します。LRU エビクション率やスレッド・ソケットのキュー深度と組み合わせることで、適切な対応策が明確になります。接続が飽和しているがヒット率が良好な場合はスケールアウト (KNFSD インスタンスの追加)、エビクションが増加してヒット率が低下している場合はキャッシュディスクのスケールアップが必要です。 これらのメトリクスはパフォーマンス問題が発生した際の推測作業も不要にします。ネットワークの制約、キャッシュディスクの飽和、プロキシの過負荷を素早く切り分け、やみくもにキャパシティを追加するのではなく、適切な対処を取ることができます。 開発者体験とデプロイ このプロジェクトは、リポジトリのクローンから稼働クラスターまでの手順を最小限の手間で完了できるよう設計されています。リポジトリには Visual Studio Code Dev Container が同梱されており、Terraform、Packer、Go、Python、 AWS Command Line Interface (AWS CLI) 、各種リンティング・テストツールを含む開発環境がすぐに使える状態で提供されます。ローカルへのインストールは不要で、リポジトリを開いてコンテナを起動すれば、すぐに AMI のビルドやクラスターのデプロイを開始できます。 デプロイは単一の Terraform モジュールで完結し、Amazon VPC サブネット、AMI ビルド、ソース NFS エクスポートを指定するだけで開始できます。KNFSD インフラ (Amazon EC2 Auto Scaling グループ、セキュリティグループ、ヘルスチェック、DNS レコード、オプションのロードバランサー、FSID データベースなど) は宣言的に作成・管理されます。リリースタグでバージョンを固定し、標準の Terraform ワークフローで任意のタイミングでアップデートできます。 同じ Dev Container 環境が開発ライフサイクル全体をサポートします。Packer による AMI ビルド、パフォーマンスの実行とプロファイリング、テストクラスターのデプロイ、Terratest 統合によるスモークテストの実行まで対応しています。コントリビューター環境とデプロイ環境に差異はなく、両者は同一の環境です。 オートスケーリング NFS キャッシュのオートスケーリングは、標準的なメトリクスではうまく機能しません。CPU 使用率はプロキシの負荷を適切に反映しないため、NFS 接続が飽和していても CPU 使用率が 40% にとどまるケースがあります。KNFSD では代わりに、インスタンスごとのアクティブ NFS 接続数というカスタム CloudWatch メトリクスを基にスケーリングします。接続数が設定したしきい値を超えると、クラスターは自動的にキャパシティを追加します。スケーリングポリシーはスケールアップのみに設定されています。スケールダウンすると、構築に時間を要したウォームキャッシュデータが失われるだけでなく、より重大な問題として、アクティブな NFS マウントが切断され、クライアントで I/O ストールが発生するためです。ワークロードが落ち着いた後のスケールダウンは、任意のタイミングで手動で行います。 はじめに KNFSD は Apache 2.0 ライセンスのオープンソースプロジェクトとして、 GitHub で公開されています。 リポジトリには以下が含まれています。 開始するための詳細な 前提条件 ソース NFS サーバー、KNFSD プロキシ、NFS クライアントのエンドツーエンドのデプロイ手順を解説したステップバイステップの チュートリアル すべての機能、設定変数、運用上の考慮事項を網羅した包括的な ドキュメント Amazon FSx for NetApp ONTAP、Amazon FSx for OpenZFS、サードパーティの NFS ゲートウェイデバイス向けのすぐに使える サンプル 質問、機能リクエスト、フィードバックは以下からお寄せください。 GitHub Issues メールでのお問い合わせ まとめ NFS インフラはデータセンターの壁で止まるように設計されたものではありません。KNFSD を使えば、その必要もなくなります。 数千コアにわたる計算負荷の高いタスクを実行する場合でも、パイプラインを再設計せずにハイブリッドワークフローを AWS に拡張する場合でも、KNFSD はコンピュートがすでに AWS で享受しているのと同じ弾力性を、透過的かつ高性能に、ストレージのロックインなしでデータにもたらします。 今すぐ KNFSD File Cache から始めましょう。 参考資料 AWS HPC コミュニティによる NFS 再エクスポートの詳細: Accelerating file reads with a storage caching server (AWS HPC Blog) Avatar 2: Way of Water で Wētā FX が NFS 再エクスポートを使用して AWS 上でスケールした方法: How Wētā FX scaled NFS for Avatar: The Way of Water (DigiPro 2023) TAGS: amazon ec2 , Media & Entertainment , storage Andy Hayes Andy は、AWSのVisual Computing担当シニアソリューションアーキテクトです。 DJ Rahming DJ は、AWSのVisual Computing担当シニアソリューションアーキテクトです。 Mike Owen Mike は、AWSのVisual Computing担当プリンシパルソリューションアーキテクトです。 Sean Wallitsch Sean は、AWSのVisual Computing担当シニアソリューションアーキテクトです。   参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先:  awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は Visual Compute SSA 森が担当しました。原文は こちら をご覧ください。