本ブログは 2025 年 6 月 16 日に公開された Blog “ How AWS improves active defense to empower customers ” を翻訳したものです。 AWS ではセキュリティが最優先事項であり、本日は AWS をあらゆるワークロードを実行するための最も安全な場所にするという目標に向けた取り組みについてご紹介します。このブログの以前の投稿では、 MadPot (グローバルハニーポット) 、 Mithra (ドメイングラフニューラルネットワーク) 、 Sonaris (ネットワーク脅威緩和) などの内部のアクティブディフェンスシステムの詳細を共有しました。AWS では脅威インテリジェンスと自動対応の効果を高め、攻撃の検出と防止に向けた新たな手法を開発し続けています。今回は、マルウェア、ソフトウェアの脆弱性、AWS リソースの設定ミスに関連するアクティブディフェンスの進歩についてご紹介します。前述のブログ投稿でご紹介したシステムと同様に、これらは、AWS をご利用している全てのお客様に自動的に適用され、常に改善されているセキュリティ機能です。これらのトピックについては、 re:inforce 2025 Innovation Talk SEC302 でより詳しく説明します。 マルウェアの拡散阻止 金銭的な動機を持つ脅威アクターは、ネットワーク化された幅広い資産へのアクセスを獲得しようとします。脅威アクターが制御するリソースが多いほど、隠れる場所が増え、不正な操作から利益を得られる期間が長くなります。そのため、脅威アクターのマルウェアには、新しいターゲットをスキャンし、ネットワーク経由で自身のコードを他のシステムに複製し、感染を拡大させる機能がよく含まれています。このような急速に拡散する動作を放置すると、ネットワークの輻輳、サービスの可用性の喪失、データの破壊につながるリスクがあります。AWS はこのような振る舞いを可能な限り阻止したいと考えています。 AWS が採用している効果的な戦略の一つは、脅威アクターがマルウェアを集中管理している主要インフラを特定することです。多様な技術を使用して、脅威インフラの特定、検証、追跡、妨害を行っています。さまざまなセンサー位置から得られたネットワークトラフィックログ、ハニーポット活動記録、マルウェアの検体を分析して、その情報を活用して、ボットネット、不正プロキシ、マシン間で直接拡散するマルウェアを阻止しています。過去 12 か月間で、AWS は 31.5 万以上の異なる Amazon Elastic Compute Cloud (Amazon EC2) インスタンスへ試みられた 400 万件以上のマルウェア感染を阻止しました。これらのマルウェア感染からワークロードを保護することで、AWS のネットワークとお客様だけでなく、さらなるマルウェアの拡散からインターネット全体も保護しています。 現在、AWS はネットワークルーティングレベルでお客様にアクティブディフェンス対策を適用しています。場合によっては、これらのクラウドネットワークルーティングの変更の規模が正当なお客様ワークロードに影響を与える可能性があるため、対策を講じないことを決定することもあります。このような場合、お客様固有のワークロードに対して AWS Network Firewall によるセキュリティ制御を提供します 。Amazon 脅威インテリジェンスを使用する新しい アクティブ脅威防御マネージドルールグループ により、AWS のグローバルインフラストラクチャ全体で観測された脅威活動から Amazon Virtual Private Cloud (Amazon VPC) ワークロードを保護することができます。有効にすると、マネージドルールの設定、一致するトラフィックの侵害指標の表示、コマンド＆コントロール通信、埋め込み URL、悪意のあるドメインなど、脅威アクターのインフラストラクチャに関連する不審なトラフィックの自動ブロックが可能になります。 脅威ハンティングとソフトウェア脆弱性の緩和における進歩 Amazon では、 バグバウンティ 、 脆弱性開示 、 オープンソース貢献 のプログラムでソフトウェア脆弱性研究をサポートしていることを誇りに思っています。また、Amazon が提供するソフトウェアとサービスの CVE 番号付与機関 (CNA) になることで、CVE プロセスのより積極的な参加者になりました。公開 CVE データベースのおかげで、脆弱性研究は加速しており、報告された CVE は 2013 年以降、前年比 21% 増加し、2024 年には 4 万件以上の CVE が公開されています。脆弱性を発見して解決するこの好循環は、時間の経過とともにサイバーセキュリティを向上させますが、AWS は脅威アクターが未解決の脆弱性を探して無許可でリソースにアクセスしようとしているのを観測しています。 AWS は MadPot と Sonaris を拡張して、より広範囲の悪意のある脆弱性スキャンと攻撃活動の特定・ブロックし、すべての AWS のお客様を脆弱性の露出から保護しています。実際の攻撃を特定するために、MadPot に何百もの新しい検出機能とサービスをエミュレートする機能を追加しました。可視性を拡大するにつれて、AWS は AWS ネットワーク全体で毎日何億もの CVE を悪用する試みをブロックし続けています。 これらのアクティブディフェンスシステムが CVE 悪用の攻撃を阻止する能力を向上させるにつれて、図 1 に示すように、過去 12 か月間で攻撃の総数は 55% 以上減少しました。この観測結果には AWS の制御外の要因も影響していますが、CVE 悪用の攻撃が減少していることを嬉しく思います。この傾向は、2025 年に行った検出、リージョン化、レイテンシー、ガードレールの改善と一致しています。すべてを阻止できるシステムはないため、悪用の試みが少ないということは、幅広いワークロードにわたるリスクが低減されることを意味します。 図 1: グローバルな悪意のある脆弱性悪用試行の減少を示すグラフ 実際の既知の悪用を特定するこの取り組みは、 Amazon Inspector の脆弱性インテリジェンス のユーザーに直接恩恵をもたらします。これにより、セキュリティ強化リソースをどこに投入するかを優先順位付けするための Amazon Inspector スコアがお客様に提供されます。これには、観測された悪用試行の最新日付、攻撃活動に関連する MITRE ATT&CK 手法、標的とされた業界が含まれます。 AWS 上に構築されたアーキテクチャの保護 AWS はお客様のコンピューティングおよびネットワークリソースを積極的に防御しています。また、お客様が依存する AWS ネイティブリソースも防御しています。AWS アクセスキー認証情報は、お客様のアカウントへのアクセスを可能にする重要なリソースです。 AWS Identity and Access Management のベストプラクティス では、お客様が認証情報を悪用から守るための実証済みの手法を共有しています。アクティブディフェンスを通じて、AWS はこれらのベストプラクティスをまだ採用していないお客様をさらに支援しています。 AWS は毎日平均 1 億 6,700 万件の悪意のあるスキャン接続から、意図せず公開された AWS アクセスキーペアを保護しています。アクセスキーが他の手段で発見された場合に備えて、お客様が管理する IAM 認証情報の保護を拡張しました。脅威インテリジェンス分析により、お客様が管理する認証情報が脅威アクターに知られていることが判明した場合、高い権限を持つ操作へのアクセスを制限する対策を講じます。また、認証情報がどのように公開されたかを特定するためのカスタマイズされた通知をお客様に送信します。これらの取り組みは毎日お客様に成果をもたらしています。以下は、定期的に寄せられるお客様からのフィードバックの例です。 これは、数週間前に AWS からの別のアラームに基づいて既にローテーションしたアクセスキーです。新しくローテーションしたアクセスキーが、AWS からの 2 回目のアラームに含まれていたことがわかりました。つまり、アクセスキーにリンクされていたアプリがまだそれを漏洩させていたということです。 そこで月曜日に開発チームと一緒に調査し、アプリがどこからシークレットを漏洩させていたかを見つけ、修正し、公開されていたすべてのシークレット (IAM アクセスキー以外にもありました) をローテーションし、アプリに追加のセキュリティを組み込みました。 これらのアラートに再度感謝します。非常に貴重です。 – AWS のお客様 2024 年 11 月と 12 月の特定の脅威活動の事例では、お客様から Amazon Simple Storage Service (Amazon S3) ストレージ内のオブジェクトに対するランサムウェア活動が報告されました。これらの身代金要求の脅威が、公開されたお客様管理の IAM アクセスキーと高い相関関係があることが判明しました。AWS は公開されたアクセスキーを隔離し、お客様の通常の運用が安全に継続できるよう配慮しました。攻撃のリスクが高まっていたため、公開されている可能性の高いアクセスキーについて、お客様に積極的な通知を再送信しました。この期間中、AWS はお客様と協力して 3 万件以上の公開された認証情報を無効化しました。この脅威活動が始まって以来、AWS は 9 億 4,300 万件以上の悪意のあるお客様の Amazon S3 オブジェクト暗号化の試みを防止してきました。 これらの認証情報公開の検出は Amazon GuardDuty 拡張脅威検出 に取り込まれ、最新のクラウド環境における脅威検出と対応オペレーションを簡素化します。 より良い協力関係 AWS のアクティブディフェンスの取り組みは、システム基盤の各層に複数のセキュリティ対策を配置し、脅威インテリジェンスを積極的に活用することでリスクを減らしています。この多層防御アプローチは、クラウドセキュリティを効果的に強化しています。AWS はサービスに追加コストなしでアクティブディフェンスを組み込むことで、お客様が幅広い脅威から保護されるようにしています。 AWS はお客様の保護を常に改善し続けていますが、お客様のワークロード内部を見ることはないため、私たちの取り組みの一部は本質的に確率的なものです。検出が曖昧な状況では、お客様の本番システムに影響を与える可能性があるため、アクティブディフェンスを適用しません。安全を確保するために、お客様は自身の防御を決して怠るべきではありません。 AWS Identity and Access Management (IAM) 、 AWS Shield Advanced 、 AWS WAF 、 AWS Network Firewall 、 Amazon GuardDuty 、 Amazon Inspector などの AWS セキュリティサービスは、お客様が独自のニーズに合わせて設定できる予防、検出、対応を提供します。良いニュースは、協力することで、私たちは皆にとってインターネットをより安全にしているということです。 Stephen Goodman Amazon アクティブディフェンスのシニアマネージャーとして、Stephen はデータ駆動型のプログラムを主導し、AWS のお客様とインターネットを脅威アクターから保護しています。 Tom Scholl AWS VP および Distinguished Engineer の Tom は、悪意のあるアクターからのトラフィックをその発生源で追跡することで、サイバー攻撃を阻止するために世界中のネットワークと協力しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 6 月 17 日に公開された Blog “ How AWS is simplifying security at scale: Four keys to faster innovation from AWS re:Inforce 2025 ” を翻訳したものです。 私がセキュリティ分野でキャリアを始めた当時は、システムを保護することは生産性を犠牲にするという事実を多くの人が受け入れていました。当時からそうである必要はなく、現在は確実にそうではありません。クラウド、特に AWS クラウドがその大きな理由です。しかし、テクノロジーが進化し、システムがより複雑になるにつれて、大規模な運用にはセキュリティへの新しいアプローチが求められます。私たちはお客様のセキュリティを最優先事項として考え、組織が安心して積極的なイノベーションを推進し、迅速にビジネスを拡大できるようなガードレールを構築しています。 AWS CISO としての新たな役割において、私は日々これが実現されているのを目の当たりにしています。お客様と会うと、生成 AI のようなテクノロジーへの期待と同時に、複雑な環境の保護や新しいタイプのリスク管理に関する質問が寄せられます。彼らはイノベーションに熱心ですが、その意欲的な取り組みをセキュリティ基盤がしっかりと支えられるという安心感を必要としています。セキュリティを損なうことなくビジネスを迅速に前進させたいと考えているのです。 本日 2025 年 6 月 17 日、 re:Inforce で、AWS がこれらのニーズからさかのぼって考え、クラウドでのセキュリティをスケールする方法を根本的に変革する取り組みについて共有しました。すべては 4 つの重要な柱に基づくセキュリティ基盤から始まります。アイデンティティとアクセス管理、データとネットワークセキュリティ、監視とインシデント対応、そしてマイグレーション・モダナイゼーション・パッチ適用の継続的な作業です。これらの柱全体で成熟したセキュリティモデルを持つ組織が、最も速くビジネス変革やイノベーションを実現しています。これらの各領域において、AWS はお客様が新しいテクノロジーを採用し、革新的な取り組みに自信を持って挑戦できるようなセキュリティ機能の提供に注力しています。 クラウドのためのアイデンティティのスケーリング お客様がクラウド運用を急速に拡大する中で、複雑な環境全体でのアイデンティティとアクセスの管理がますます困難になっていると伺っています。彼らは強力なセキュリティを維持しながらビジネスとともに成長できるソリューションを必要としています。アイデンティティとアクセス管理はクラウドセキュリティのあらゆる側面の基盤であり、この分野での成功には厳格な認証コントロールとアクセス権限への包括的な可視性の両方が必要です。 本日、 AWS IAM Access Analyzer の新しい内部アクセス検出結果を発表できることを嬉しく思います。この機能は、組織が大規模に機密データへのアクセスを管理する方法を変革し、お客様が成長するにつれて直面する複雑さに対応します。自動推論のテクノロジーを使用して、多様なポリシータイプにわたる複雑な権限レイヤーを分析し、セキュリティチームに組織内の誰がどのリソースにアクセスできるかについての包括的な可視性を提供します。新しく付与されたアクセスの日次監視と通知により、最も複雑な環境でも自信を持って最小権限アクセスを実装できるよう支援しています。これにより、お客様はクラウドでスケールする際にビジネスが求める俊敏性を維持しながら、重要なリソースのアクセスコントロールを強化するための可視性を得ることができます。 データとネットワークセキュリティを通じた変革の実現 お客様はビジネスを変革することに意欲的ですが、急速なイノベーションに対してセキュリティ対策もしっかりと対応できるという安心感が必要とされています。これは特に大規模なネットワークとデータの保護に関して言えることです。基調講演では、Comcast の CISO である Noopur Davis 氏が、彼女の組織がどのように広大なネットワークと顧客データを保護しながら、急速なイノベーションを可能にしているかを共有しました。何百万人もの顧客が彼らのサービスに依存している中で、Comcast のアプローチ「セキュリティは単に防御するだけでなく、変革を可能にするべき」に私は共感しました。 AWS はこのビジョンを、大規模なセキュリティを簡素化する新機能で実現しています。本日、 AWS Certificate Manager が ACM 発行の公開証明書とその秘密鍵を AWS 内外で使用するためにエクスポートできるようになったことを発表しました。これにより、ワークロードのセキュリティ確保に役立つ柔軟性を備えた自動証明書管理が可能になります。また、 AWS Shield を拡張し、ネットワークセキュリティ分析を実行して構成の問題を特定し、修復の推奨事項を提供する強化されたネットワークおよびアプリケーション保護機能を追加しています。AWS の生成 AI 搭載アシスタント Amazon Q Developer を使用して、シンプルな自然言語で実用的な洞察を得ることもできます。これらのイノベーションにより、チームは環境がより複雑になっても、データを保護し、進化する脅威に先んじることができます。 脅威検出と対応の向上 お客様からは、特にクラウド運用の規模が拡大するにつれて、日々進化するセキュリティ脅威に対応し続けることの難しさが共通の課題として挙げられています。従来の自動化は増大する複雑さを管理するのに役立ちますが、AI はセキュリティ運用を変革するさらに強力な機会を表しています。慎重に実装すると、AI は複雑な攻撃パターンを特定し、誤検知を減らし、大規模な対応を自動化する能力を劇的に向上させます。 本日 re:Inforce で、2 つの重要なセキュリティイノベーションを発表しました。 Amazon GuardDuty 拡張脅威検出の機能拡張と、これらのニーズに直接対応する強化された AWS Security Hub です。これらのサービスを組み合わせることで、大規模なセキュリティの簡素化を支援します。GuardDuty は AWS がトレーニングした AI と機械学習 (AI/ML) モデルを使用して、高度な多段階の脅威を検出し、実用的な洞察を提供します。一方、Security Hub はセキュリティシグナルを自動的に分析して相関付け、明確で優先順位付けされたアクションに変換することで、重要なセキュリティ問題を優先順位付けします。このアプローチにより、チームは AWS 環境全体でセキュリティリスクを効率的に検出・対応できるという安心感を持ちながら、自信を持って運用の規模を拡大することができます。 より良いセキュリティへの道のりの加速 AI や自動化などの高度な機能がセキュリティ運用を強化する一方で、セキュリティは基盤が最も重要です。クラウドへの移行は、オンプレミス環境では実現困難なレベルの、より強固なセキュリティ基盤を構築できる大きな変革のチャンスとなります。AWS に移行することで、物理的なインフラストラクチャセキュリティを管理する必要性が減少し、継続的に更新・維持される組み込みの保護機能を活用することができます。 クラウドの採用を成功させるには、単純なリフト＆シフトを超える必要があります。モダナイゼーションがこれらの利点を実現するための鍵です。 AWS Lambda 、 Amazon Simple Storage Service (Amazon S3) 、または AWS Key Management Service (AWS KMS) などのマネージドサービスを使用するためにスタックの上位にソリューションを移行することで、後付けではなく組み込まれたセキュリティコントロールの恩恵を受けることができます。これらのサービスは AWS によって継続的にパッチが適用され維持されるため、チームはお客様のためのイノベーションに集中できます。結局のところ、より良いセキュリティへの最速の道は、コアとなる保護機能がすでに組み込まれている道なのです。 セキュリティ成功のためのパートナーシップ セキュリティ変革は組織が単独で取り組む必要のある旅ではありません。私はキャリアを通じて、適切なパートナーシップが成功を加速させ、複雑な課題に新しい視点と深い専門知識をもたらすことを目の当たりにしてきました。AWS のセキュリティパートナーは、ID ソリューションの実装からセキュリティ運用の最新化まで、本日ご紹介した 4 つの柱全体にわたってお客様を支援しています。彼らは技術的な複雑さとクラウドでのセキュリティをスケールするビジネス上の現実の両方を理解しており、多くの場合、各業界に特化した専門知識を持っており、これによりお客様は自信を持ってイノベーションをより迅速に加速することができます。 今後の展望 クラウドでの運用をスケールする際、AWS の目標は強力なセキュリティコントロールを維持しながら迅速に進む自信をお客様に提供することです。セキュリティがビジネスと共に自然にスケールすると、チームはインフラストラクチャの管理ではなく、次の構築に集中できます。 AWS が前例のない規模でセキュリティを設計、構築、運用する方法についてさらに詳しく知るために、 re:Inforce でのイノベーショントーク にぜひご参加ください。これらの 1 時間のセッションでは、最新のクラウドセキュリティの主要な柱の、セキュアな基盤、回復力のあるアーキテクチャ、AI を活用したイノベーション、大規模な脅威インテリジェンスについて探求します。 AWS CISO としての役割に就くにあたり、私は今後の機会に活力を感じています。AWS は約 20 年間、急速に革新しながらも安全に提供できるユニークなセキュリティ文化を維持してきました。生成 AI と急速な技術変化の環境を進む中で、お客様の信頼を獲得するということは、イノベーションのペースに追いつくだけでなく、それをさらに成功させるお手伝いをすることを意味します。この使命を前進させることに、これ以上ないほどの興奮を感じています。 Amy Herzog Amy は AWS の副社長兼最高情報セキュリティ責任者 (CISO) であり、セキュリティが最優先事項である企業において、クラウドセキュリティの専門家からなるグローバル組織を率いています。AWS に入社する前は、Amazon のデバイスとサービス、メディアとエンターテイメント、広告事業の CISO を務め、Alexa+ や Ring などの消費者向けテクノロジー製品のセキュリティを監督し、低軌道衛星を通じて世界中の顧客とコミュニティに高速で信頼性の高いブロードバンドを提供する Amazon のイニシアチブである Project Kuiper の安全な開発において重要な役割を果たしました。Amy のキャリアは、サイバーセキュリティ、イノベーション、企業変革の交差点で 20 年以上にわたります。彼女は MITRE Corporation で 15 年間を過ごし、政府と産業界にまたがる複雑なセキュリティ課題に対する最先端のソリューションを開発しました。また、Pivotal Software、VMware、Travelers Insurance でリーダーシップの役割を担い、テクノロジー主導のビジネス変革に焦点を当てた 2 つのスタートアップを共同設立しました。Amy は Pomona College で数学の学士号を、MIT の Sloan School of Management で MBA を取得しています。また、複数の出版物の著者であり、2 つの特許を保有しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

Amazon Redshift は、クラウドで提供される完全マネージド型のペタバイト規模のデータウェアハウスサービスです。MPP (Massively Parallel Processing) アーキテクチャにより、クエリをコンピュートノード全体に分散してデータを処理します。各ノードは、割り当てられたデータに対して同一のクエリコードを実行し、並列処理を実現します。 Amazon Redshift は、データベーステーブルにカラムナーストレージを採用し、全体的なディスク I/O の必要量を削減しています。このストレージ方式は、クエリ時のデータ読み取りを最小限に抑えることで、分析クエリのパフォーマンスを大幅に向上させます。データは多くの組織にとって最も価値のある資産となり、データウェアハウスでのリアルタイムまたはニアリアルタイムの分析への需要を増加させています。この需要に応えるには、クエリのパフォーマンスを維持しながら、同時にデータをロードできるシステムが必要です。この投稿では、Amazon Redshift の同時データ取り込みオペレーションにおける主要な改善点をご紹介します。 書き込みワークロードにおける課題と問題点 データウェアハウス環境では、データへの同時アクセスの管理が重要でありながら、課題となっています。Amazon Redshift を使用するお客様は、さまざまなアプローチでデータを取り込んでいます。例えば、一般的に INSERT や COPY ステートメントを使用してテーブルにデータを読み込む方法があり、これらは 純粋な書き込み オペレーションとも呼ばれます。データの鮮度を最大化するために、低レイテンシーでの取り込みが要件となることがあります。これを実現するために、同じテーブルに対して同時にクエリを実行することができます。これを可能にするため、Amazon Redshift はデフォルトで スナップショット分離 を実装しています。スナップショット分離は、複数のトランザクションが同時に実行されている場合のデータ整合性を提供します。スナップショット分離は、各トランザクションがトランザクション開始時点のデータベースの一貫したスナップショットを参照することを保証し、データの整合性を損なう可能性のある読み取りと書き込みの競合を防ぎます。スナップショット分離により、読み取りクエリを並列に実行できるため、データウェアハウスが提供する完全なパフォーマンスを活用できます。 しかし、純粋な書き込みオペレーションは順次実行されます。具体的には、純粋な書き込みオペレーションはトランザクション全体で排他ロックを取得する必要があります。このロックは、トランザクションがデータをコミットした時点でのみ解放されます。このような場合、純粋な書き込みオペレーションのパフォーマンスは、セッション間での書き込みの直列実行速度によって制限されます。 これをより深く理解するために、純粋な書き込みオペレーションがどのように機能するかを見てみましょう。すべての純粋な書き込みオペレーションには、同じテーブルに対するスキャン、ソート、集計などの取り込み前のタスクが含まれます。取り込み前のタスクが完了すると、データの一貫性を維持しながらテーブルにデータが書き込まれます。純粋な書き込みオペレーションは直列に実行されるため、並列性がないことにより取り込み前のステップも直列に実行されていました。つまり、複数の純粋な書き込みオペレーションが同時に送信された場合、取り込み前のステップでさえ並列化されることなく、1 つずつ順番に処理されます。同一テーブルへの取り込みの並列性を向上させ、取り込みの低レイテンシー要件を満たすため、お客様はしばしばステージングテーブルを使用する回避策を採用しています。具体的には、ステージングテーブルに INSERT ... VALUES(..) ステートメントを送信します。その後、 ALTER TABLE APPEND を使用してターゲットテーブルにデータを追加する前に、ファクトテーブルや ディメンションテーブルなどの他のテーブルとの結合を実行します。このアプローチは、ステージングテーブルを維持する必要があり、 ALTER TABLE APPEND ステートメントの使用によるデータブロックの断片化により、より大きなストレージ容量が必要になる可能性があるため、望ましくありません。 まとめると、INSERT 文と COPY 文の同時実行は、排他的なロック動作のため、Amazon Redshift でのデータ取り込みワークフローのパフォーマンスと効率を最大化する際に課題となります。これらの制限を克服するには、追加の複雑さとオーバーヘッドを伴う回避策を採用する必要があります。次のセクションでは、Amazon Redshift が同時挿入の改善によってこれらの課題にどのように対処したかを説明します。 同時挿入処理とそのメリット Amazon Redshift の パッチ 187 では、同時挿入のサポートによりデータ取り込みの同時実行性が大幅に向上しました。これにより、COPY や INSERT ステートメントなどの純粋な書き込みオペレーションの同時実行が改善され、Amazon Redshift へのデータロードにかかる時間が短縮されます。具体的には、複数の純粋な書き込みオペレーションが同時に進行し、スキャン、ソート、集計などの取り込み前のタスクを並列で実行できるようになりました。 この改善を視覚化するために、異なるトランザクションから同時に実行される 2 つのクエリの例を考えてみましょう。 以下はトランザクション 1 のクエリ 1 です。 INSERT INTO table_a SELECT * FROM table_b WHERE table_b.column_x = 'value_a'; 以下は、トランザクション 2 のクエリ 2 です。 INSERT INTO table_a SELECT * FROM table_c WHERE table_c.column_y = 'value_b' 次の図は、同時挿入機能のない場合の純粋な書き込みオペレーションを簡略化して視覚化したものです。 同時挿入機能がない場合、主要なコンポーネントは以下の通りです。 まず、純粋な書き込みオペレーション (INSERT) は、それぞれ table b と table c からデータを読み取る必要があります。 ピンク色のセグメントはスキャンステップ (データの読み取り) で、緑色のセグメントは書き込みステップ (実際のデータの挿入) です。 「同時挿入前」の状態では、両方のクエリが順次実行されます。具体的には、クエリ 2 のスキャンステップは、クエリ 1 の挿入ステップが完了するのを待ってから開始されます。 たとえば、異なるトランザクションで同じサイズのクエリを 2 つ実行する場合を考えてみましょう。両方のクエリは同じ量のデータをスキャンし、ターゲットテーブルに同じ量のデータを挿入する必要があります。両方のクエリが午前 10 時に発行されたとします。まず、クエリ 1 は午前 10 時から午前 10 時 50 分までデータをスキャンし、午前 10 時 50 分から午前 11 時までデータを挿入します。次に、クエリ 2 はスキャンと挿入の量が同じなので、午前 11 時から午前 11 時 50 分までデータをスキャンし、午前 11 時 50 分から午後 12 時までデータを挿入します。両方のトランザクションは午前 10 時に開始されました。エンドツーエンドの実行時間は 2 時間です（トランザクション 2 は午後 12 時に終了）。 次の図は、前の例と異なり、同時挿入機能が使用できる場合の純粋な書き込みオペレーションを簡略化して示したものです。 同時挿入機能が有効な場合、クエリ 1 とクエリ 2 のスキャンステップを同時に実行できます。いずれかのクエリがデータを挿入する必要がある場合は、順次実行されます。異なるトランザクションで同じサイズの 2 つのクエリを使用した同じ例を考えてみましょう。両方のクエリは同じ量のデータをスキャンし、ターゲットテーブルに同じ量のデータを挿入する必要があります。ここでも、両方のクエリが午前 10 時に発行されたとします。午前 10 時に、クエリ 1 とクエリ 2 が同時に実行を開始します。午前 10 時から午前 10 時 50 分まで、クエリ 1 とクエリ 2 は並行してデータをスキャンできます。午前 10 時 50 分から午前 11 時まで、クエリ 1 がターゲットテーブルにデータを挿入します。次に、午前 11 時から午前 11 時 10 分まで、クエリ 2 がターゲットテーブルにデータを挿入します。両方のトランザクションの合計実行時間は 1 時間 10 分に短縮され、クエリ 2 は午前 11 時 10 分に完了します。このシナリオでは、両方のクエリの取り込み前のステップ (データのスキャン) を同時に実行でき、前の例と同じ時間 (50 分) で完了します。ただし、ターゲットテーブルへの実際のデータ挿入は順次実行され、クエリ 1 が最初に挿入を完了し、その後クエリ 2 が続きます。これは Amazon Redshift の同時挿入機能のパフォーマンス上の利点を示しています。取り込み前のステップを同時に実行できるようにすることで、この機能が導入される前の順次実行と比較して、全体の実行時間が 50 分短縮されます。 同時挿入により、取り込み前のステップを並行して進めることができます。取り込み前のタスクには、スキャン、ソート、集計などの単一または複数の組み合わせがあります。クエリのエンドツーエンドの実行時間において、大幅なパフォーマンス向上が達成されます。 メリット サービスが自動的に同時挿入処理を行うため、追加の設定なしでこれらのパフォーマンス改善の恩恵を受けることができます。同時挿入の改善には複数のメリットがあります。同じテーブルに書き込む際のインジェストワークロードのエンドツーエンドのパフォーマンスが向上します。社内のベンチマークでは、同じテーブルへの同時挿入トランザクションにおいて、エンドツーエンドの実行時間が最大 40% 改善されることが示されています。この機能は、特にスキャン処理の多いクエリ (データの書き込みよりもデータの読み取りに時間を要するクエリ) に効果的です。クエリにおける scan:insert の比率が高いほど、より大きなパフォーマンスの改善が期待できます。 この機能は、 データ共有によるマルチデータウェアハウス書き込み のスループットとパフォーマンスも向上させます。データ共有を通じたマルチウェアハウス書き込みにより、専用の Redshift クラスターまたはサーバーレスワークグループ全体で書き込みワークロードをスケールでき、リソース使用率を最適化し、ETL (抽出、変換、ロード) パイプラインのより予測可能なパフォーマンスを実現できます。具体的には、データ共有を通じたマルチウェアハウス書き込みでは、異なるウェアハウスからのクエリが同じテーブルにデータを書き込むことができます。同時挿入により、リソースの競合を軽減し、クエリを同時に進行させることで、これらのクエリのエンドツーエンドのパフォーマンスが向上します。 次の図は、同時挿入における内部テストのパフォーマンス改善を示しています。オレンジ色のバーはデータ共有を通じたマルチウェアハウス書き込みのパフォーマンス改善を、青色のバーは同一ウェアハウスでの同時挿入のパフォーマンス改善を示しています。グラフが示すように、INSERT オペレーションに対して SCAN オペレーションの割合が高いクエリは、この新機能により最大 40% のパフォーマンス向上が得られます。 同時挿入を使用してインジェストパイプラインを管理することで、さらなるメリットを得ることができます。 ALTER TABLE APPEND ステートメントを使用する回避策ではなく、同時挿入の利点を活用して同じテーブルに直接データを書き込むことで、ストレージ使用量を削減できます。これには 2 つの利点があります。1 つは一時テーブルの排除、もう 1 つは頻繁な ALTER TABLE APPEND ステートメントによるテーブルの断片化の軽減です。さらに、複雑な回避策を管理する運用上のオーバーヘッドを避け、頻繁なバックグラウンドでの自動実行および手動実行の VACUUM DELETE オペレーションにより一時テーブルをターゲットテーブルに追加することによって引き起こされる断片化を軽減できます。 考慮事項 Amazon Redshift の同時挿入機能の強化は大きなメリットをもたらしますが、スナップショット分離環境で発生する可能性のあるデッドロックシナリオに注意することが重要です。具体的には、スナップショット分離環境では、同じテーブルで同時書き込みトランザクションを実行する際に、特定の条件下でデッドロックが発生する可能性があります。スナップショット分離のデッドロックは、同時実行される INSERT 文と COPY 文がロックを共有して処理を進めている際に、別のステートメントが同じテーブルに対して排他ロックを必要とするオペレーション (UPDATE、DELETE、MERGE、または DDL オペレーション) を実行しようとする場合に発生します。 以下のシナリオを考えてみましょう。 トランザクション 1: INSERT/COPY INTO table_A ; トランザクション 2: INSERT/COPY INTO table_A; <UPDATE/DELETE/MERGE/DDL statement> table_A 共有ロックを持つ同じテーブルで INSERT および COPY オペレーションを含む複数のトランザクションが同時に実行され、そのうちの 1 つのトランザクションが純粋な書き込みオペレーションの後に UPDATE、MERGE、DELETE、DDL ステートメントなどの排他ロックを必要とするオペレーションを実行する場合、デッドロックが発生する可能性があります。このような状況でデッドロックを回避するには、排他ロックを必要とするステートメント (UPDATE、MERGE、DELETE、DDL ステートメント) を別のトランザクションに分離することで、INSERT および COPY ステートメントを同時に進行させ、排他ロックを必要とするステートメントをその後に実行することができます。あるいは、同じテーブルに対して INSERT および COPY ステートメントと MERGE、UPDATE、DELETE ステートメントを含むトランザクションの場合、アプリケーションにリトライロジックを組み込むことで、潜在的なデッドロックに対処することができます。デッドロックの詳細については、 単一のテーブルが関連する同時書き込みトランザクションの考えられるデッドロック状況 を参照し、同時実行トランザクションの例については 同時書き込みの例 を参照してください。 まとめ このブログ記事では、Amazon Redshift が単一のテーブルへの同時データ取り込みパフォーマンスの向上という重要な課題にどのように対処したかを説明しました。この機能強化により、最新データへのアクセス時の低レイテンシーとより厳格な SLA の要件を満たすことができます。このアップデートは、お客様のフィードバックに基づいて Amazon Redshift に重要な機能を実装するという私たちのコミットメントを示すものです。 著者について Raghu Kuppala は、データベース、データウェアハウス、分析の分野で経験豊富なアナリティクス スペシャリスト ソリューションアーキテクトです。仕事以外では、様々な料理を試したり、家族や友人と時間を過ごすことを楽しんでいます。 Sumant Nemmani は AWS のシニアテクニカルプロダクトマネージャーです。Amazon Redshift のお客様が、機械学習とインテリジェントなメカニズムを活用した機能を利用できるよう支援することに注力しています。これらの機能により、サービス自身によるチューニングと最適化が可能となり、お客様の利用規模が拡大しても Redshift の価格性能比を維持することができます。 Gagan Goel は AWS のソフトウェア開発マネージャーです。顧客中心のソリューションを提供するためにチームの優先順位付けとガイダンスを行い、顧客のワークロードに対するクエリパフォーマンスの監視と向上を通じて、Amazon Redshift の機能が顧客のニーズを満たすことを確実にしています。 Kshitij Batra は Amazon のソフトウェア開発エンジニアで、レジリエントでスケーラブル、高性能なソフトウェアソリューションの構築を専門としています。 Sanuj Basu は AWS のプリンシパルエンジニアで、Amazon Redshift を次世代のエクサバイトスケールのクラウドデータウェアハウスへと進化させる取り組みを主導しています。Redshift のコアデータプラットフォーム (マネージドストレージ、トランザクション、データ共有を含む) のエンジニアリングをリードし、お客様がシームレスなマルチクラスター分析とモダンなデータメッシュアーキテクチャを実現できるようにしています。Sanuj の取り組みは、Redshift のお客様が限界を突破するのを支援しています。 翻訳はソリューションアーキテクトの小役丸が担当しました。原文は こちら です。

この記事は Improving Amazon ECS deployment consistency with SOCI Index Manifest v2 (記事公開日 : 2025 年 7 月 3 日) の翻訳です。 Seekable OCI (SOCI) は、コンテナイメージ全体をダウンロードする前にコンテナを起動すること (遅延読み込み) で、 Amazon Elastic Container Service (Amazon ECS) タスクの起動時間を短縮します。Amazon ECS では、 ソフトウェアバージョンの一貫性 によって特定の ECS デプロイメント 全体で同一のコンテナイメージが使用されることを保証し、信頼性の高いデプロイメントを実現します。しかし、SOCI を用いて ECS タスクを実行する場合、SOCI インデックスはコンテナイメージとは独立しているため、デプロイメントの途中で SOCI インデックスを変更または削除した場合に「一部のタスクは遅延読み込みされるものの、他のタスクはイメージ全体のダウンロードを必要とする」など、起動時間が予測できなくなる可能性がありました。この問題を解決するために、私たちは新しく SOCI Index Manifest v2 を導入しました。これにより、コンテナイメージと SOCI インデックスの間に明示的な関連付けを構築し、SOCI を用いた場合でも一貫したデプロイメントを実現できるようになります。 背景 SOCI を用いてコンテナイメージを遅延読み込みする場合、コンテナランタイムは SOCI インデックスを使用して「各ファイルがコンテナイメージ内のどこに格納されているか」を特定します。 SOCI の内部動作に関するブログ記事 で説明されているように、SOCI インデックスはコンテナイメージとは独立したアーティファクトであり、イメージレイヤーごとのファイルのインベントリを含みます。以下の図は、SOCI インデックス内の Subject メタデータフィールドを介して、SOCI インデックスとコンテナイメージが関連付けられていることを表しています。この実装を SOCI Index Manifest v1 と呼び、コンテナイメージを変更せずに SOCI インデックスを作成することを可能としていました。 図 1 : コンテナイメージマニフェストと SOCI Index Manifest v1 の関係性 SOCI Index Manifest v1 では、コンテナイメージと SOCI インデックスの関連付けが一方向な設計によるいくつかの制約がありました。まず、 crane や Skopeo などのイメージレプリケーションツールが、リポジトリ間でコンテナイメージを複製する際に SOCI インデックスを見落とすことがよくありました。そのため、SOCI インデックスを個別にプッシュする必要がありました。また、デプロイメントの途中で SOCI インデックスを変更または削除した場合に「一部のタスクは遅延読み込みされるものの、他のタスクはイメージ全体のダウンロードを必要とする」など、デプロイメントの一貫性が損なわれる可能性がありました。 SOCI Index Manifest v2 SOCI Index Manifest v2 では、 イメージインデックス を用いて SOCI インデックスとコンテナイメージを関連付けます。イメージインデックスは、マルチアーキテクチャイメージにおける複数プラットフォーム (amd64 や arm64 など) のコンテナイメージを関連付けたり、メタデータを付与するために使用されます。 以下の図は、SOCI Index Manifest v2 において、SOCI インデックスとコンテナイメージが、イメージインデックスのアノテーションを介して相互に関連付けられていることを表しています。 図 2 : コンテナイメージマニフェストと SOCI Index Manifest v2 の関係性 コンテナイメージと SOCI インデックスの新たな関連付けにより、一貫性のあるコンテナの実行が可能となります。イメージインデックスを削除または更新しない限り、SOCI インデックスを削除・更新することはできません。また、様々なアーキテクチャにおけるコンテナイメージと SOCI インデックスはすべて、イメージインデックス内で関連付けられるため、SOCI インデックスの大規模な管理が可能となります。これにより、削除やレプリケーションといったライフサイクル管理も合理化されます。 ウォークスルー SOCI Index Manifest v2 は、 soci convert コマンドを使用して作成できます。このウォークスルーでは、Linux 環境でコンテナイメージを操作します。ここでは、まず Finch を使用してコンテナイメージをビルドし、SOCI CLI を使用して SOCI インデックスを作成します。その後、2 つのアーティファクトを Amazon Elastic Container Registry (Amazon ECR) にプッシュします。 1. まず、コンテナイメージをビルドするための Dockerfile を作成します。ここでは、Amazon Linux 2023 のベースイメージを使用して、nginx をインストール・実行するように設定します。 cat <<EOF > Dockerfile FROM public.ecr.aws/amazonlinux/amazonlinux:2023-minimal RUN dnf install -y nginx CMD ["nginx", "-g", "daemon off; error_log /dev/stdout info;"] EOF 2. 続いて、コンテナイメージをビルドします。以下の例では Finch を使用していますが、 containerd イメージストア にアーティファクトを保存する任意のコンテナイメージビルダーを使用できます。 export ACCOUNT_ID=$(aws sts get-caller-identity --query "Account" --output text) export AWS_REGION=us-east-1 sudo finch build \ --tag $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/nginx-demo:latest . 3. soci convert コマンドを使用して、SOCI インデックスを作成します。SOCI CLI は SOCI Snapshotter リポジトリ からダウンロードできます ( convert サブコマンドは v0.10.0 以降で利用可能です)。このとき、お使いのコンテナイメージビルダーに合わせて、適切な名前空間を指定する必要がある点に注意してください。例えば Docker を利用する場合は、 containerd イメージストアを利用するように設定 した上で --namespace moby を指定してください。 sudo soci --namespace finch convert \ $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/nginx-demo:latest \ $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/nginx-demo:soci-latest 4. AWS CLI を使用して、Amazon ECR リポジトリを作成します。 aws ecr create-repository \ --repository-name nginx-demo \ --region $AWS_REGION 5. Finch を使用して、コンテナイメージと SOCI インデックスを Amazon ECR リポジトリにプッシュします。 sudo finch image push \ $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/nginx-demo:soci-latest 認証エラーが出る場合は、Amazon ECR にログインしていることを確認してください。 aws ecr get-login-password --region $AWS_REGION | \ sudo finch login \ --username AWS \ --password-stdin $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com 6. Amazon ECR リポジトリのアーティファクトを一覧表示するには、Amazon ECR コンソールまたは AWS CLI を使用できます。 aws ecr describe-images \ --repository-name nginx-demo \ --region $AWS_REGION 上記コマンドの出力から、リポジトリ内に 3 つのアーティファクト (コンテナイメージ、SOCI インデックス、イメージインデックス) が存在することを確認できます。 { "imageDetails": [ { "registryId": "1234567890", "repositoryName": "nginx-demo", "imageDigest": "sha256:2a2d5af449c44f1658005ed6c2f0f9ee1e99d4013eab9ca572713ed7822cf5c3", "imageSizeInBytes": 129069250, "imagePushedAt": "2025-05-30T18:01:06.613000+00:00", "imageManifestMediaType": "application/vnd.oci.image.manifest.v1+json", "artifactMediaType": "application/vnd.oci.image.config.v1+json" }, { "registryId": "1234567890", "repositoryName": "nginx-demo", "imageDigest": "sha256:e9b498d30d84cbb10985a08554a6fff7e6b2bf3edeeaa8bc3a29c35fb6e0fb20", "imageSizeInBytes": 3590218, "imagePushedAt": "2025-05-30T18:01:06.624000+00:00", "imageManifestMediaType": "application/vnd.oci.image.manifest.v1+json", "artifactMediaType": "application/vnd.amazon.soci.index.v2+json" }, { "registryId": "1234567890", "repositoryName": "nginx-demo", "imageDigest": "sha256:98dbde520076de139d3f8e9589364daf2ed246edc686f1fd6e47dd3fbadc45a6", "imageTags": ["soci-latest"], "imageSizeInBytes": 129069250, "imagePushedAt": "2025-05-30T18:01:06.887000+00:00", "imageManifestMediaType": "application/vnd.oci.image.index.v1+json" } ] } 7. イメージインデックスを取得して、コンテナイメージと SOCI インデックスの新しい関係性を確認しましょう。 aws ecr batch-get-image \ --region $AWS_REGION \ --repository-name=nginx-demo \ --image-ids imageTag=soci-latest \ --query 'images[0].imageManifest' \ --output text | jq -r '.' イメージインデックスは SOCI Index Manifest v2 に従い、コンテナイメージと SOCI インデックスがアノテーションを介してお互いを参照していることを確認できます。 { "schemaVersion": 2, "mediaType": "application/vnd.oci.image.index.v1+json", "manifests": [ { "mediaType": "application/vnd.oci.image.manifest.v1+json", "digest": "sha256:2a2d5af449c44f1658005ed6c2f0f9ee1e99d4013eab9ca572713ed7822cf5c3", "size": 699, "annotations": { "com.amazon.soci.index-digest": "sha256:e9b498d30d84cbb10985a08554a6fff7e6b2bf3edeeaa8bc3a29c35fb6e0fb20" }, "platform": { "architecture": "amd64", "os": "linux" } }, { "mediaType": "application/vnd.oci.image.manifest.v1+json", "digest": "sha256:e9b498d30d84cbb10985a08554a6fff7e6b2bf3edeeaa8bc3a29c35fb6e0fb20", "size": 1038, "annotations": { "com.amazon.soci.image-manifest-digest": "sha256:2a2d5af449c44f1658005ed6c2f0f9ee1e99d4013eab9ca572713ed7822cf5c3" }, "platform": { "architecture": "amd64", "os": "linux" }, "artifactType": "application/vnd.amazon.soci.index.v2+json" } ] } これで、 ECS タスク定義 でこのコンテナイメージのタグまたはダイジェストを参照し、 AWS Fargate 上でコンテナイメージを遅延読み込みできるようになりました。SOCI を使用してコンテナイメージを遅延読み込みするために、ECS タスク定義や ECS サービス定義 にフラグやパラメーターを追加する必要はありません。 後片付け 余分なコストの発生を防ぐために、Amazon ECR リポジトリを削除しましょう。 aws ecr delete-repository \ --repository-name nginx-demo \ --region $AWS_REGION \ --force 考慮事項 SOCI Index Manifest v2 のリリースに関して、いくつかの考慮事項があります。 SOCI Index Manifest v2 は、 SOCI Snapshotter v0.10 以降、および AWS Fargate プラットフォームバージョン 1.4.0 でサポートされています。 AWS Fargate で初めて SOCI を使用するお客様は、SOCI Index Manifest v2 のみを使用できます。この場合、AWS Fargate は SOCI Index Manifest v1 に関連付けられたコンテナイメージを遅延読み込みせず、コンテナイメージ全体をダウンロードしてからコンテナを起動します。 過去に AWS Fargate で SOCI を使用したことがあるお客様は、引き続き SOCI Index Manifest v1 を使用できます。ただし、v2 への移行を強く推奨します。この場合、AWS Fargate は SOCI Index Manifest v1 または v2 のいずれかに関連付けられたコンテナイメージを遅延読み込みします。 SOCI Index Manifest v1 から v2 に移行するには、ウォークスルーで説明した手順に従って SOCI インデックスマニフェストを作成、プッシュし直す必要があります。 AWS Fargate が使用する snapshotter (soci または overlayfs) は、 ECS タスクメタデータエンドポイント で公開されます。この値は amilazy init コンテナ を使用してログに出力し、一元的に管理できます。 SOCI Index Manifest v2 を作成すると、SOCI インデックスに関連する アノテーション が追加され、コンテナイメージマニフェストが変更されるため、コンテナイメージダイジェストも再生成されます。このとき、コンテナイメージのイメージレイヤーの内容は変更されません。 コンテナイメージがすでにコンテナイメージリポジトリに保存されている場合、SOCI インデックスを作成後、コンテナイメージをプッシュし直す必要があります。このとき、すでにレポジトリに存在するイメージレイヤーのアップロードはスキップされるため、イメージレイヤー重複によるストレージコストの増加は発生せず、新しいマニフェストファイルのみがアップロードされます。 SOCI インデックス作成の自動化ソリューションである SOCI Index Builder を使用している場合、最新バージョンにアップデートすることで SOCI Index Manifest v2 を利用できます。 最新情報については、 Amazon ECS ドキュメント または SOCI Snapshotter リポジトリ をご確認ください。 まとめ Seekable OCI (SOCI) は、コンテナイメージを遅延読み込みすることで AWS Fargate のタスク起動時間を短縮します。今回導入された SOCI Index Manifest v2 によって、SOCI を使用する際の ECS デプロイメントの一貫性について、より高い信頼性を提供するようになりました。コンテナイメージと SOCI インデックスの明示的な関連付けにより、SOCI インデックスの大規模な管理も容易になります。AWS Fargate 上の ECS タスクにおいて SOCI を利用開始するには、 Amazon ECS 開発者ガイド および SOCI Toolbox をご確認ください。また、SOCI プロジェクトと SOCI Index Manifest v2 の詳細については、 SOCI Snapshotter プロジェクト をご覧ください。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 今年も半分が終わりましたね (焦り)。残りの半年で生成 AI がどんな進化を遂げるのか楽しみです。 2025 年 7 月 31 日 (木) に AWS Builders Online Series というオンラインイベントが開催されます。生成 AI もテーマに含まれていますので、ぜひ登録してみてください。 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、6 月 30 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「ユーザックシステム株式会社様のAWS 生成 AI 活用事例「非定型の受注業務の自動化に生成AI活用」」を公開 ユーザックシステム株式会社様は、企業の業務プロセスの自動化・効率化を支援するビジネスに取り組まれています。一方で、取引先ごとに独自ルールが存在するケースやFAXやメールで注文書のやり取りを行うケースでは、効率化が難しく、新たな方法による生産性向上が求められていました。そこで生成 AI と RPA を組み合わせて非定型の受注業務の完全自動化を目指すソリューション「Knowfa 受注AIエージェント」を Amazon Bedrockを使って開発しました。これまで RPA で対応できなかった受注業務の 80% の自動化に成功したとのことです。AWSのマネージドサービスの活用により、エンジニア 3 名とプロジェクトマネージャー 1 名という少人数体制で、約 4 ヶ月という短期間で β 版開発を実現できました。今後は、対応可能な業務範囲の拡大を目指しています。 【GENIAC】グローバル生成AIモデルプロバイダ訪米記録 2025 年 5 月 12 日 〜 16 日に、経済産業省が推進するプログラム『 Generative AI Accelerator Challenge(GENIAC) 』の採択者と共に、米国ベイエリアおよびシアトルの米大手モデルプロバイダーを訪問し、技術交流セッションを実施しました。本ブログでは、AWS、Anthropic、Meta、Cohere、NVIDIAや現地で挑戦する日本人起業家たちとディスカションした様子をレポートしています。 Amazon Nova 理解モデルにおけるパフォーマンスの最適化 本ブログでは、Amazon Nova 理解モデルのパフォーマンスを最適化する方法について説明しています。最適化のポイントは、明確な指示で構造化されたプロンプトを反復的に改善すること、Tool use において Greedy Decoding を使用する設定を行うことです。記事内にプロンプト例があるので是非参考にしてみてください。 Amazon Q Developer から Claude Sonnet 4 がアクセス可能に 先日、 Amazon Q Developer が CLI で Claude Sonnet 4 のサポートを開始し、追加コストなしで高度なコーディングと推論機能を開発プロセスに導入できるようになりました。本ブログでは、Q Developer CLI で Claude Sonnet 4 をモデルとして選択する方法と簡単なデモを紹介しています。複雑なコードリファクタリングから効率的なドキュメント作成まで便利に使えますので、まだ使ってない方は是非お試しを！ 【開催報告】 消費財業界向け Amazon Q in QuickSight ワークショップ ～生成 AI で加速するインテリジェントデータ分析～ 2025 年 6 月 9 日、AWS 目黒オフィスにて消費財業界向け Amazon Q in QuickSight ワークショップを開催しました。本ブログはそのイベントの開催報告記事です。BI に興味ある方はデータ分析ダッシュボード設計の進め方などぜひ参考にしてみてください。 Amazon Q のコスト最適化 本ブログではAmazon Q Business と Amazon Q Developerそれぞれの料金プランと機能の違いについて説明しています。いづれのサービスの最大の利点の 1 つは、予測可能なコスト構造です。コアビジネスの目標に焦点を当てながら、経費を正確に予測できますので、ご興味ある方はぜひブログを参照ください。 Amazon Nova Canvas update: Virtual try-on とスタイルオプションが一般公開 画像生成を行うモデル Amazon Nova Canvas に、 Virtual try-on 機能機能とスタイルオプションが追加 されました。このブログでは、それぞれの機能の解説・デモ・サンプルコードを紹介しています。Virtual try-on 機能は顧客体験の向上に繋がる可能性がある機能ですので、サンプルコードを参考にお試しください！ サービスアップデート Amazon Q in Connect がプロアクティブな推奨事項機能に対して 7 言語をサポート Amazon Q in Connect の、音声・チャット対応で顧客意図を検出し「プロアクティブな推奨事項を提供する機能」が、英語に加えて、スペイン語、フランス語、ポルトガル語、中国語、日本語、韓国語でも利用可能になりました。多言語対応により、グローバル企業のカスタマーサービス担当者が各国の顧客とより効率的にやり取りできるようになり、問題解決の精度とスピードが向上します。詳細は こちらのドキュメント をご参照ください。 Q-Index がシームレスなアプリケーションレベル認証をサポート Amazon Q-Index の SearchRelevantContent API で、シームレスなアプリレベル認証がサポートされました。従来、サードパーティアプリで Q-Index を使う際、ユーザーは自分のアプリにログイン後、企業コンテンツを取得するために AWS IAM への再認証が必要でした。今回のアップデートにより、Trusted Token Issuer 機能を使って一度のログインだけで企業コンテンツから回答を取得できるようになり、ユーザー体験が大幅に向上します。バージニア北部、オレゴン、アイルランド、シドニーリージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 Amazon Q Business がレスポンスのカスタマイズ機能を開始 Amazon Q Business で新機能「レスポンスカスタマイゼーション」が提供開始されました。従来は AI の回答スタイルが固定でしたが、今回のアップデートで企業の要望に合わせて回答の口調、長さ、詳細度を自由に設定できるようになりました。例えば、カジュアルな表現で短い回答にしたり、フォーマルで詳細な回答にしたりと、組織のコミュニケーションスタイルに統一できます。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock で Claude モデル向けの Citations API と PDF サポートが利用可能に Amazon Bedrock の Claude モデルで Citations API と PDF サポートが追加されました。Citations API により AI 回答に根拠文書の引用が自動付与され、信頼性向上が実現します。PDF サポートでテキスト抽出やチャート分析も可能になり、法的研究や学術執筆での活用が期待されます。詳細は こちらの API ドキュメント をご参照ください。   Amazon Nova Canvas にVirtual try-on 機能とスタイルオプションを追加し、画像生成機能を強化 Amazon Nova Canvas に「Virtual try-on 機能」と「スタイルオプション機能」が追加されました。Virtual try-on 機能では人物画像と商品画像をアップロードするだけで、服を着た姿や家具配置をリアルに生成できます。スタイルオプションでは 8 つのスタイルから選択可能で、プロンプト指定が不要になります。バージニア北部、東京、アイルランドリージョンで利用可能です。詳細は こちらのブログ記事 をご参照ください。 Amazon SageMaker HyperPod トレーニングオペレーターの発表 Amazon SageMaker HyperPod の新しいトレーニングオペレーターが一般提供開始されました。これは Kubernetes 上で大規模な AI モデルトレーニングの耐障害性を向上させる拡張機能です。従来は 1 つのプロセスが失敗すると全ノードで完全再起動が必要でしたが、今回のアップデートにより影響を受けた部分のみを選択的に再起動する「surgical recovery」が可能になりました。詳細は こちらのドキュメント をご参照ください。 AWS Neuron 2.24 の新機能には PyTorch 2.7 と推論機能の強化が含まれます AWS Neuron 2.24 がリリースされ、AI モデルの推論処理が大幅に高速化されます。PyTorch 2.7 に対応し、大規模言語モデルの実行時間短縮を実現する prefix caching や、長い文章処理に適した context parallelism などの新機能を搭載しています。これにより Inferentia や Trainium インスタンスでの AI ワークロードがより効率的になり、コスト削減と性能向上を同時に達成できます。詳細は こちらのドキュメント をご参照ください。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

本ブログは 2025 年 7 月 5 日現在の内容を元に記載しております。記載内容については今後変更される可能性があります。 こんにちは ! テクニカルインストラクターの室橋です。本ブログでは、現在注目を集めている生成 AI について無料で利用できる学習コンテンツ「AWS SimuLearn」についてご紹介いたします。 AWS SimuLearn とは？ AWS SimuLearn は、生成 AI を搭載した仮想顧客とのチャットを通じて実践的な AWS スキルを身につけられる新しい学習プラットフォームです。顧客の課題をヒアリングし、最適なソリューションを提案するプロセスを体験した後、実際の AWS アカウントを使用したハンズオンラボで技術スキルを向上させることができます。 AWS SimuLearn で無料プレイできるラボ一覧 このたび、AWS SimuLearn において生成 AI に関するラボと、クラウドの基礎 (Cloud Practitioner) に関するラボが無料かつ日本語対応で提供開始されました。これにより、コース内から起動可能な AWS アカウントを使用した演習環境をどなたでも利用できます。AWS を活用して生成 AI アプリケーションの開発を学びたい方や、AWS Certified AI Practitioner (AIF) 認定の取得を目指している方にとって、最適な学習機会となるでしょう。 以下に、現在無料で利用可能な SimuLearn の生成 AI 関連コースの一覧をご紹介します。なお、下記の 10 コースは「 AWS SimuLearn: Generative AI Practitioner (日本語) 」という学習プラン (コースをセットにして学習しやすくしたもの) に登録することにより、一覧性のあるページより学習の開始が可能です。 AWS SimuLearn: Generative AI Practitioner コース一覧 課題名 シナリオ 目標 クラウド、はじめの一歩 島の安定化システムは故障しており、システムのコンピューティングモジュールの信頼性と可用性を高める必要があります。 AWS グローバルインフラストラクチャの利点を特定する AWS リージョンとアベイラビリティーゾーンについて説明する Amazon EC2 インスタンスを複数のアベイラビリティーゾーンにデプロイする方法を説明する クラウドコンピューティングの基本 シティのウェブポータルチームは、自社の海岸波サイズ予測ウェブページの信頼性を高めるソリューションを求めています。 AWS クラウドコンピューティング環境の特徴を確認する AWS の製品とサービスを使用する主な利点を確認する AWS クラウドのサービスとオンプレミスのインフラストラクチャを比較し、対比する Amazon S3 を使用して静的ウェブページをホストする方法を説明する 生成 AI を使い始める AnyCompany Software は、生成AIのためのプロンプトエンジニアリング技術をスタッフに学ばせたいと考えています。ソフトウェア開発の速度と品質を向上させることで、同社は競争の激しい技術市場で優位性を保ち、クライアントに優れた製品を提供することを目指しています。 Amazon SageMaker JumpStart を使用して LLM モデルをデプロイする方法を説明する Jupyter ノートブックで Amazon SageMaker Python SDK を使用してモデルをデプロイする方法を示す プロンプトエンジニアリング技術を使用してモデルの応答を改善する方法を説明する AI スマートアシスタントを作成する 人事部門は、毎日 500 件を超える従業員からの情報要求に対応するのに苦労しています。要求の大部分は、ポリシー、福利厚生、手続きに関するものです。また、現在、要求は営業時間内にのみ処理でき、同時に返信できる数も限られています。これには即座対応が必要です。 Amazon Bedrock を使用して自動化された顧客サービスソリューションを作成する方法を決定する Amazon Bedrock エージェントをナレッジベースで設定する方法を決定する Amazon Bedrock エージェントにアクショングループを追加する方法を示す Amazon Q でコードを構築し理解する 子供向け教育出版社は、キャラクター名、テーマ、設定などのユーザー入力に基づいてパーソナライズされた短編ストーリーを生成する自動ストーリー生成システムを作成したいと考えています。 Amazon Bedrock FM を使用してテキストコンテンツを生成する方法を有効化し、使用する方法を示す AWS Lambda 関数を他の AWS サービスと統合して設定およびテストする方法を決定する Amazon Q を使用してコード提案を生成し実装する方法を決定する AWS サービスを使用するサーバーレス AI 駆動のストーリー生成ワークフローの主要コンポーネントを特定する Amazon Bedrock プレイグラウンドを探索する AnyCompany のビジネスチームは、顧客サービスのチャットベースの AI エクスペリエンスに最適な AI モデルを見つける任務を負っていますが、明確な評価方法が欠けています。彼らは、顧客との会話中にテキストと画像の両方をサポートする異なるモデルを徹底的に比較したいと考えています。 Amazon Bedrock プレイグラウンドを使用して AI モデルの評価方法を決定する 安全で管理された環境で異なる基盤モデルをテストし比較する方法を決定する モデルパラメータの調整と最適化の実践経験を積む さまざまな AI モデルからの出力を評価し比較する方法を示す ガードレールによる安全な対話型 AI AnyCompany の人事部門は、従業員の質問に答えるのに役立つチャットベースの AI アシスタントを選択したいと考えています。会社は、機密の人事問題を避け、従業員データのプライバシーを保護し、一貫した福利厚生とポリシーの回答を提供するなど、AI アシスタントが専門的でポリシーに準拠した回答のみを提供することを懸念しています。 Amazon Bedrock Guardrails 機能を説明する ガイドレールの設定とカスタマイズ方法を示す ガードレールをテストして、セーフガードポリシーを検証する方法を示す エンタープライズナレッジアシスタントを作成する 営業部門は過去および現在の販売データへの迅速なアクセスが不足しており、類似の販売問い合わせに対して様々な解釈や回答が生じています。これにより、営業担当者が上級管理職に注力すべき販売製品や人気が高まっている製品を報告するまでの解決時間が長くなっています。 Amazon Bedrock の主な機能と特徴を説明する Amazon Bedrock ナレッジベースの作成と設定方法を決定する テキスト対テキストモデルとテキスト対ベクトルモデルを比較する 検索拡張生成 (RAG) の概念を説明する Amazon SageMaker で AI サービスを利用する グローバルコンサルティング企業は、現在手動プロセスで年間 150 万ドルのコストがかかり、15 パーセントのエラー率を示し、20 人以上のフルタイム従業員が1ドキュメントあたり最大 48 時間かかる 10,000 件以上の多言語クライアントコミュニケーションとドキュメントを毎日処理しています。同社は、運用コストを削減し、精度を向上させ、処理時間を短縮しつつ、グローバルなクライアントサービス提供を強化する包括的な自動化ソリューションを望んでいます。 Amazon SageMaker AI ノートブックインスタンスをドキュメント処理ワークフロー用にセットアップおよび使用する方法を説明する Boto3 SDK を使用して複数の AWS AI サービスを統合する方法を決定する AWS AI サービスを使用して、テキスト抽出、感情分析、言語翻訳、音声サービスの使用方法を示す AWS サービスの統合とデータ処理のためのノートブックセルを順次実行する方法を示す ウェブページのコードを生成する マーケティング部門は、特に外部クライアントとコンテンツを共有するための Amazon EC2 上のウェブサーバーの管理において、ウェブホスティングのニーズに課題を抱えています。チームは、現在過剰な時間とリソースを消費しているウェブコンテンツとコードの更新を効率化するソリューションを求めています。彼らは、生成 AI の機能を活用し、AWS の専門知識が最小限の従業員でもウェブコンテンツの更新を効果的に管理できる、ユーザーフレンドリーなアプローチを実装したいと考えています。 Amazon Bedrock のチャット/テキストプレイグラウンドの使用方法を説明する チャットモードとシングルプロンプトモードの違いを特定する Amazon Bedrock を使用してアプリケーションを構築する方法を決定する Amazon EC2 で実行中のアプリケーションを更新する方法を示す また、SimuLearn では生成 AI 以外にも、無料でクラウドの基礎をハンズオンで学習することができるコースも合計 12 コース提供しております。是非 AWS Skill Builder にアクセスしてコースを検索してみてください。なお、コース検索の際は Skill Builder トップページ上部の検索窓に何もいれずに Enter キーを押すと「フィルタ」の画面に遷移しますので、そこから「学習スタイル」を「没入型ソリューション構築」、「料金」を「無料」にして検索していただくと、無料の SimuLeran コースが検索しやすくなります。 AWS Skill Builder のトップ画面にある「トレーニングカタログを検索」と書かれた検索窓にカーソルを合わせ、何も入れずに検索 フィルタの画面に遷移します。「没入型ソリューション構築」「無料」のフィルタを設定いただくと SimuLearn の無料コースが表示されます。 SimuLearn 学習の流れ 1 : モード選択 ここからは SimuLearn を使用した際の学習の流れについて簡単にご紹介します。 学習開始時には、まずモードの選択を行います。モードは「スクリプトモード」と「自由会話モード」の 2 つから選択できます。「スクリプトモード」では AI との対話はなく、学習者はあらかじめ用意された会話のシナリオに沿って学習目標を確認し、課題に進みます。「自由会話モード」では、対話形式の画面を通じて、生成 AI 搭載の仮想顧客とビジネス課題の解決に向け、学習者自ら内容を考えて会話を行います。学習者は最適なソリューションを構築するため、適切な AWS サービスを提案します。このモードでは、生成 AI が学習者の回答に基づいて、コミュニケーション能力、問題解決力、お客様志向、意思決定能力、技術的な知識戦略的思考を評価します。「自由会話モード」は現在英語のみ対応となっています。どちらを選択しても、会話後のハンズオンパートには影響を及ぼすことはありません。 画像はモード選択画面です。どちらのモードを選択しても後のフェーズの構築で行う内容は変わりません。 現在「スクリプトモード」は日本語で確認いただくことが可能です。こちらは予め用意された会話のやり取りを確認することによって、顧客のニーズと、それに対する回答を読み取り、次のフェーズに進んでいく流れとなります。 スクリプトモードでは「あらかじめ決められた会話内容」より、顧客からのニーズを確認します。 顧客役の生成 AI と適切に会話を行うことにより、学習者のスキルが評価されます。現在は英語のみの対応となります。英語に自信がある方は是非自由会話モードで学習をしてみてください。英語を使うお客様とのやり取りを想定して、翻訳ツールを使用しながらチャレンジしていただくのも面白いかもしれません。 自由会話モード画面です。顧客との会話により満足度を高め、アーキテクチャ図を完成させましょう。 なお、SimuLearn が日本語が表示されない場合は「画面右上にある三本線メニュー」より、言語 (Language) で「Japanese」を選択してください。 画面右上の言語切り替えメニューより言語の変更が可能です。 SimuLearn 学習の流れ 2 : 学習 ～ 実践 ～ DIY のハンズオンパート お客様との会話が終了した後、次のフェーズに進みます。課題は「学習」「実践」「DIY」の 3 つのパートに分かれています。 課題は上記の 3 フェーズで進行します。 まず、学習パートで「この課題の中ではどのようなソリューションが求められているか ?」「どのように構築するのか ?」を理解します。このパートでは概要を説明する動画を確認することも可能です。動画の音声は英語のみサポートされており、日本語は字幕で表示することが可能です。 学習パート内で求められるソリューションやサービスについての学習を行います。 次の実践パートでは、学習セクションで得た知識を実際の AWS 環境で実践できます。ステップバイステップの詳細な解説とスクリーンショットが用意されており、SimuLearn 専用の AWS アカウントを使用することにより、料金発生や環境の削除忘れ、設定ミスなどの心配をすることなく、安心して学習に集中できます。この理論と実践を組み合わせた学習アプローチにより、AWS サービスへの理解を深めながら、実務で活かせる実践的なスキルを効率よく身につけることができます。 実践パートで「実際の AWS アカウント」を使用しながら、ハンズオンでの学習を行います。 「学習パート」及び「実践パート」で学習した事が身についているかを確認するため、DIY パートでは「詳細な手順やスクリーンショットなしで、要件にそった環境が構築できるかどうかの検証」を行います。DIY の目標で示されたソリューションを構築後「検証」ボタンを押し、検証が成功すれば無事に課題は終了となります。 要件に沿った環境を構築した後、検証フォーム内に求められた内容を入力し、検証を行います。 見事検証が成功すると、クリア画面が表示されます！ AWS SimuLearn で生成 AI、クラウドの学習を加速させましょう！ 以上のように、AWS SimuLearn では「生成 AI の基礎」や「クラウドの基礎」を無料で学習可能です。最大の魅力は「実際の AWS アカウントを使用したハンズオン形式の学習が、料金の心配なく行える点」にあります。「AWS アカウントの作成は不安」「予期せぬ料金が発生するのでは」と迷っていた方にとって、SimuLearn は理想的な入門環境となるのではないでしょうか。また、SimuLearn には今回ご紹介した無料コンテンツ以外にも数多くの課題が用意されています。「生成 AI の基礎」が学習可能な 8 コースや「クラウドの基礎」が学習できる 12 コース」で基本を学んだ後、さらに知識を深めたい方は AWS Skill Builder のサブスクリプションへの登録をご検討ください。サブスクリプションに登録することで、より専門的で幅広い課題にチャレンジできるようになり、クラウドスキルを次のレベルへと引き上げることができます。サブスクリプションに関する詳細は こちらのページ をご確認ください。 また、AWS Skill Builder では、SimuLearn 以外にも様々な学習リソースが提供されています。ゲーム感覚で AWS が学べる「AWS Cloud Quest」、実践的なラボ環境に特化した「Builders Lab」、そして多数の無料学習コースなど、学習スタイルや目的に合わせて選べるコンテンツが豊富に揃っています。現在、クラウド技術の習得は多くの業界で求められるスキルとなってきています。AWS Skill Builder を活用して、自分のペースでスキルアップを図り、キャリアの可能性を広げましょう。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 2025年7月31日(木) に AWS Builders Online Series が開催されます。AWS Builders Online Series は、基礎から実践までの実用的な AWS クラウドスキルを身につけることを目的とした初心者向けオンラインイベントです。今回は、「アプリケーション開発」、「既存システムの移行」、 「生成 AI」、 「AWS の実用に向けた基礎知識」の 4 つのテーマにフォーカスし、デモを見ながら業務上のよくある課題の解決法やすぐに実践できる知識を学ぶことが出来ます。ぜひ、ご登録ください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2025年6月30日週の主要なアップデート 6/30(月) Amazon Redshift Serverless now supports 4 RPU Minimum Capacity Option Amazon Redshift Serverless の最小容量設定を4 RPU (Redshift Processing Units) に設定できるようになりました。Amazon Redshift Serverless はデータウェアハウス容量を RPU で測定し、RPU として稼働するワークロードの時間に対して利用料が発生します。以前は Amazon Redshift Serverless を実行するために必要な最小基本容量は 8 RPU でしたが、今回のリリースによって 4 RPU で稼働させることができるようになったことで、 1 時間あたり約 1.98ドルという低価格で利用をはじめることができます。 Amazon Connect now supports instance replication between Asia Pacific (Tokyo) and Asia Pacific (Osaka) Amazon Connect の機能として、Amazon Connect Global Resiliency (ACRR) が一般提供開始となりました。大阪リージョンにレジリエンスインスタンスを設置することで、東京リージョンのインスタンスから、ユーザー、ルーティングプロファイル、フローなどの Amazon Connect 構成をレプリケートし、フェイルオーバーできるようになりました。これにより、データを日本国内に保持しながら、地域的な災害や障害が発生した場合のダウンタイムを最小限に抑えることで、コンタクトセンターの可用性を高めることができます。詳しくは ブログ をご確認ください。 Amazon DynamoDB global tables with multi-Region strong consistency is now generally available Amazon DynamoDB グローバルテーブルはマルチリージョン強整合性をサポートするようになりました。DynamoDB グローバルテーブルは、完全マネージド型のサーバーレスなマルチアクティブデータベースです。今回、マルチリージョンの強整合性を備えたことで、アプリケーションが常に利用可能で、どのリージョンからでも最新のデータを読み取ることができる最高レベルのアプリケーション回復力を提供するとともに、今まで必要であった、強整合性のレプリケーション管理という作業が不要となります。日本において、東京リージョンと大阪リージョンでのマルチリージョン構成で利用可能です。 Citations API and PDF support for Claude models now in Amazon Bedrock Amazon Bedrock は、Anthropic のClaude モデル向けに Citations API (引用)と PDF サポートを提供しました。Citations APIにより、Claude モデルは回答生成に使用された具体的な引用元を提供します。これにより、高い精度と透明性を必要とするアプリケーションにとって、より信頼性の高い出力が可能となります。また、PDFサポートでは PDF ドキュメントからテキストを抽出し、チャート分析や視覚的なコンテンツを理解できるようになったことで、企業が保持する PDF ドキュメントライブラリなどから、より効率的な洞察を得ることが可能です。 7/1(火) Amazon Aurora now supports PostgreSQL 17.5, 16.9, 15.13, 14.18, and 13.21 Amazon Aurora で PostgreSQL 17.5、16.9、15.13、14.18、および 13.21 のバージョン をサポートしました。このアップデートには PostgreSQL コミュニティの改善とバグ修正が含まれているだけでなく、クラスターアップグレード中のダウンタイムを削減するための読み取りレプリカの最適化、 Babelfishの新機能 、セキュリティの改善などの Aurora 固有の機能強化もされています。 Amazon QuickSight launches Trusted Identity Propagation (TIP) for Athena Direct Query Amazon QuickSightは、Amazon Athena に対するダイレクトクエリ向けに、Trusted Identity Propagation（TIP: 信頼できるID伝播）をサポートしました。TIP を使用することで、Author はクエリによって返されるデータの行と列レベルでの制御ができ、同じダッシュボードを顧客や部門間で使用することができます。詳細についてはこちらの ユーザガイド をご確認ください。 Amazon Q in Connect now supports 7 languages for proactive recommendations Amazon Q in Connect で日本語を含む 6 つの言語を新たにサポートするようになりました。Amazon Q in Connect は、カスタマーサービス向けの生成 AI を活用したアシスタントで、コールセンターのオペレーターが問い合わせを迅速かつ正確に解決するための推奨事項を提供します。今まで、言語としては英語のみのサポートとなっていましたが、スペイン語、フランス語、ポルトガル語、中国語、日本語、韓国語での、音声およびチャットのやり取りを検出し、オペレーターへの支援が可能です。 Amazon Aurora MySQL and Amazon RDS for MySQL integration with Amazon SageMaker is now available Amazon Aurora MySQL と Amazon RDS for MySQL が Amazon SageMaker とのゼロETL統合をサポートしました。これにより、MySQL テーブルからデータが自動的に抽出、およびレイクハウスにロードされ、分析ワークロード向けのほぼリアルタイムのデータ可用性が実現できます。また、レイクハウスに同期されたデータは Apache Icebergと互換性があり、SQL、Apache Spark、BI、AI/ML ツールなど、お好みの分析ツールやクエリエンジンを使用できます。 7/2(水) Amazon QuickSight supports 2B row SPICE dataset Amazon QuickSight Enterprise Edition において、最大 20 億行のデータを SPICE (Super-fast Parallel In-memory Calculation Engine) のデータセットに読み込むことができるようになりました。このアップデート前の容量の 10 億行から 2 倍のデータを読み込むことが可能となったことで、取り込み速度やクエリ性能を低下させることなく、より多くのビジネスデータを分析してビジネスインサイトを得ることができます。 Amazon Nova Canvas adds virtual try-on and style options for image generation Amazon Nova Canvas でバーチャル試着とスタイルオプションの機能がリリースされました。バーチャル試着機能により、人物やスペースを示す画像と商品画像の2つをアップロードするだけで、商品を着用した人物の画像や、リビングスペースに配置された商品家具の画像を生成できます。また、スタイルオプションにより、事前に設定した画像スタイル (デザインスケッチ、フォトリアリズムなど) をもとに、一貫した画像を生成することができます。 7/3(木) Amazon Aurora DSQL is now available in additional AWS Regions Amazon Aurora DSQL がソウルリージョンで利用可能になりました。また、今まで北米 (バージニア、オハイオ、オレゴン) のみでサポートされていたAurora DSQL のマルチリージョン構成でしたが、今回のサポートリージョンの拡大に伴い、アジアパシフィック地域として大阪、東京、ソウルでのマルチリージョンクラスターの構成が可能になりました。また、ヨーロッパ地域（アイルランド、ロンドン、パリ）内のマルチリージョンクラスターも同様にサポートされています。 Amazon Aurora PostgreSQL database clusters now support up to 256 TiB of storage volume Amazon Aurora PostgreSQL の最大ストレージ容量が 256 TiB となりました。このアップデート以前の最大容量 128 TiB から倍増し、単一のAuroraデータベースクラスター内でさらに大きなデータセットを保存および管理できるようになりました。今回の拡張されたストレージを利用するためには、クラスターをサポートされているデータベースバージョンにアップグレードする必要があります。サポートされているデータベースのバージョンについては、 こちらのユーザガイド をご確認ください。 7/4(金) この日に発表されたアップデートはありませんでした。 AWS re:Inforce 2025 が先月に開催されました。キーノートをはじめ、セキュリティサービスに関する多数の機能アップデートをキャッチアップできる re:Cap イベントが 7/24(木) に予定されています。ぜひ ご登録 ください！ それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

本記事は 2024年6月11日に公開された ” Simplify global security inspection with AWS Cloud WAN Service Insertion ” を翻訳したものです。 AWS Cloud WAN は、データセンターやブランチオフィス、 Amazon Virtual Private Cloud (Amazon VPC) VPC を接続する広域ネットワーク (WAN) の構築・運用に使用できるマネージド型の WAN サービスです。ネットワークポリシーを使用して、ネットワーク管理とセキュリティタスクを一元的に設定・自動化し、グローバルネットワークの完全な可視性を得ることができます。 サービス開始 以来、グローバルネットワークの作成とリソース間の接続を容易にする機能により、AWS Cloud WAN の認知度は高まっています。しかし、この接続性を重視したことに伴い、AWS ネイティブまたはサードパーティのファイアウォールを使用する際のセキュリティ検査機能の必要性が高まっています。お客様は、ネットワークの検査と保護の方法を求めており、AWS Cloud WAN を使用した安全なグローバルネットワークの設計に関するガイダンスを必要としています。お客様の理解を深めていただくため、AWS Cloud WAN を使用した安全なグローバルネットワークの設計方法について、すでにいくつかの ブログ記事 を公開しています。 従来のセキュリティ検査アプローチにおける課題 既存の検査アーキテクチャパターンには多くの利点がありますが、特に AWS Cloud WAN で大規模に展開する際に、お客様はいくつかの課題に直面してきました。 インスペクションセグメントが共有されているため、Classless Inter-Domain Routing (CIDR) を使用する VPC ルートは、各 VPC アタッチメントをネクストホップとして、インスペクションセグメントのルートテーブルに動的に伝播されます。そのため、それぞれのファイアウォールにトラフィックをルーティングするためには、新しく追加された VPC ごとに、AWS Cloud WAN のインスペクションセグメントルートテーブルに静的ルートを設定する必要がありました。 マルチリージョンネットワークのための AWS Cloud WAN による最適なルーティングの実現 で説明されているような、マルチ AWS リージョンの地域分散型検査アーキテクチャは複雑さを伴います。 1 つのグローバルインスペクションセグメントでは、既存のソリューションで各リージョンのファイアウォールを経由してトラフィックを強制的にルーティングする方法がありませんでした。各 AWS リージョンでトラフィックを検査するという要件を満たし、対称的なルーティングを維持するために、顧客は各リージョンまたはエッジロケーションに固有のグローバル共有インスペクションセグメントを作成する必要がありました。 それぞれの共有インスペクションセグメントは、コアネットワークごとのセグメントの クォータ としてカウントされます。 このブログ記事では、AWS Cloud WAN Service Insertion (Service Insertion) という新機能について説明します。この機能を使用すると、中央ポリシードキュメントを使用して AWS および他社のネットワークおよびセキュリティサービスを AWS Cloud WAN に組み込むことができ、運用の簡素化を実現できます。この機能を使用することで、シンプルなポリシーステートメントを定義するか AWS マネジメントコンソールを使用して、VPC 間、インターネットエグレス、ハイブリッド環境のトラフィックをネットワークまたはセキュリティアプライアンスに容易に振り分けることができます。また、この機能は、East-West (VPC 間) および North-South (インターネットエグレス) のセキュリティ検査のためにインスペクション VPC にデプロイされた AWS Network Firewall や Gateway Load Balancer などの AWS サービスへのポリシーベースのトラフィック誘導もサポートしており、セキュリティインフラストラクチャを AWS Cloud WAN デプロイメントの他の部分とシームレスに統合できます。 Service Insertion のメリット お客様は AWS Cloud WAN を使用して一元化されたセキュリティアーキテクチャをデプロイすることで、セキュリティリソースを統合し、管理の負担を軽減し、セキュリティインフラストラクチャのコストを削減できます。セキュリティ検査機能には、East-West、North-South、またはハイブリッド環境の保護が含まれます。 Network Service Insertion のためのルーティングの簡素化： お客様は、VPC 間、VPC からインターネット、またはオンプレミスへのトラフィックを、ネットワークファイアウォールやロードバランサーなどのネットワークアプライアンスを経由させる必要がよくあります。AWS Cloud WAN Service Insertion により、複雑なルーティング設定を作成・管理したり、サードパーティの自動化ツールを使用したりすることなく、VPC にデプロイされたネットワークやセキュリティアプライアンスに対象のネットワークトラフィックを簡単に転送できます。 マルチリージョンのセキュリティ検査の容易なデプロイ： ほとんどの AWS Cloud WAN のお客様は、リージョン拡張や災害復旧のユースケースに対応するため、マルチリージョンネットワークをデプロイしています。Service Insertion 機能により、マルチリージョンのデプロイが簡素化され、複雑なマルチリージョンネットワーク設定を必要とせずに、リージョン内およびリージョン間のトラフィックをセキュリティインフラストラクチャ経由に振り分けることができます。 主要な概念 このブログ投稿では、 AWS Cloud WAN のコンポーネント であるグローバルネットワーク、コアネットワーク、コアネットワークポリシー、アタッチメント、コアネットワークエッジ、ネットワークセグメントについて理解していることを前提としています。 上記で説明した概念に加えて、このブログ記事で説明するアーキテクチャを理解するためには、AWS Cloud WAN Service Insertion 機能の新しいコンポーネントである Network Function Group (NFG) を理解することが重要です。 Network Function Group (NFG) NFG は、内部的には、NAT、ファイアウォール (AWS Network Firewall や Gateway Load Balancer、またはサードパーティサービス)、侵入検知・防止システム、データ損失防止など、グローバルな AWS Cloud WAN ネットワークの一部として展開される特殊なネットワークやセキュリティ機能を指すコアネットワークアタッチメントの集合で構成される単一のセグメントです。 NFG を使用すると、AWS Cloud WAN に接続された VPC やオンプレミスネットワークにデプロイされたネットワーク機能 (Network Function) を使用して、同一セグメント間または異なるセグメント間のトラフィックを自動的に制御できます。ネットワーク機能が存在するコアネットワークアタッチメント (VPC、Site-to-Site VPN、Connect、Transit Gateway ルートテーブル) のセットを含む NFG を指定できます。さらに、トラフィックをネットワーク機能にリダイレクトする必要があるセグメントまたはセグメントペアを指定できます。AWS Cloud WAN は、それぞれの NFG に対して指定されたコアネットワークアタッチメントを通じて、セグメント間のネットワークトラフィックを自動的にリダイレクトします。このリダイレクトは、コアネットワーク上の同一リージョン (リージョン内) およびクロスリージョン (リージョン間) のトラフィックの両方で機能します。AWS Cloud WAN の コアネットワークポリシードキュメント を使用して、以下のように主要な設定項目を指定できます： 1 つまたは複数のネットワーク機能を表す NFG。 NFG の一部であるコアネットワークアタッチメント。 ネットワーク機能を使用して制御する必要がある、セグメント間またはセグメント内のトラフィックを持つセグメント (シナリオ 2 のアタッチメント)。 Cloud WAN のネットワークセグメントと NFG の主な違いを理解することも重要です。 コアネットワークセグメント コア Network Function Group (NFG) セグメントは独立したルーティングドメインで、セグメント内外のルーティングを完全に制御しながらアタッチメントを関連付けることができます。例えば、セグメント内でルートの追加や削除、セグメント間でのルートの共有が可能です。 NFG は独自のルートテーブルを持ち、これらのルートはポリシードキュメントの Service Insertion 設定に基づいて（ネクストホップの転送先とともに）自動的に伝播されます。これらのルートを確認することはできますが、NFG 内でのルートの追加、削除、共有はできません。 Cloud WAN セグメントにアタッチメントを関連付けると、VPC の CIDR やダイナミックルートが、それぞれのセグメントルートテーブルに伝播されます。 NFG にアタッチメントを関連付けても、VPC の CIDR やダイナミックルートは NFG ルートテーブルに伝播されません。 トラフィックを制御するために、NFG は以下の セグメントアクション を導入します。 ‘ send-via ‘: NFG のアタッチメントを介して、同一セグメントまたは異なるセグメント間のワークロード間のトラフィックを、ネクストホップを上書きして制御します。 ‘single hop’ : 優先されるソースまたはデスティネーションリージョンを使用して、トラフィックは単一の中間アタッチメントを通過します。使用するリージョンのリストを設定でき、優先的に使用するリージョンを設定することもできます。 ‘dual-hop’ : トラフィックは、ソースとデスティネーションの両方のコアネットワークエッジに挿入されたアタッチメントを通過します。このオプションでは、インスペクションアタッチメントは、Service Insertion が有効化された各セグメントのすべてのリージョンに配置される必要があります。 ‘ send-to ‘: NFG のアタッチメントを介して、セグメントに関連付けられたワークロードからのエグレストラフィックを、デフォルトルート (0/0, ::/0) を使用してインターネットまたはハイブリッドに転送するために使用します。 これらの概念の詳細については、 AWS Cloud WAN ドキュメント をご参照ください。 図 1: Service insertion NFG アーキテクチャ ここでは、以下の 3 つのシナリオに焦点を当てます。 リージョン内、セグメント間のインスペクション リージョン間、セグメント間のデュアルインスペクション リージョン間、セグメント間のシングルインスペクション シナリオ 1 – リージョン内、セグメント間のインスペクション 次の図 (図 2) は、シナリオ 1 を示しています。このシナリオでは、同一リージョン内の異なるセグメントにあるアタッチメントが、インスペクションアプライアンスを介してのみ相互に通信する必要がある場合を示しています。たとえば、開発チームが本番環境にエンジニアリング変更をプッシュする必要がある場合です。Prod VPC (10.1.0.0/16) と Dev VPC (10.11.0.0/16) は同じリージョン (リージョン 1) にありますが、それぞれ Prod セグメントと Dev セグメントに関連付けられています。Inspection VPC 1 (100.64.1.0/24) も同じリージョンに存在します。 図 2: リージョン内、セグメント間のインスペクション 同一リージョン内の Prod VPC 1 から Dev VPC 1 へのトラフィックパスに NFG を挿入するために必要なステップを見ていきましょう： Step 1: 以下に示すサンプルポリシーを使用して、InspectionNFG Network Function Group (NFG) を作成します。 "network-function-groups": [ { "name": "InspectionNFG", "require-attachment-acceptance": false } ], Step 2: 以下に示すサンプルの アタッチメントポリシー を使用して、Inspection VPC 1 アタッチメントを InspectionNFG NFG に関連付けます。 "attachment-policies": [ { "rule-number": 100, "condition-logic": "or", "conditions": [ { "type": "tag-exists", "key": "stage" } ], "action": { "association-method": "tag", "tag-value-of-key": "stage" } } ] Step 3: segment-actions を設定してネットワーク機能 (すなわち Inspection VPC 1) をトラフィックパスに組み込む前に、Inspection VPC 1 アタッチメントが作成され、InspectionNFG に関連付けられていることを確認する必要があります。以下に示すサンプルの AWS CLI を使用してアタッチメントを作成できます。 aws networkmanager create-vpc-attachment \ --core-network-id "<core-network-id>" \ --vpc-arn "<vpc-arn>" \ --subnet-arns "<subnet1-arn>" "<subnet2-arn>" \ --tags Key=stage,Value=InspectionNFG Step 4: Inspection VPC 1 アタッチメントを作成し、Inspection NFG に関連付けたので、以下に示すサンプルの segment-actions を使用して、セグメント間トラフィックに InspectionNFG NFG を組み込みます。 "segment-actions": [ { "action": "send-via", "segment": "prod", "mode": "single-hop", "when-sent-to": { "segments": "*" }, "via": { "network-function-groups": [ "InspectionNFG" ] } } ], “when-sent-to ” の配下の “segments”: “*” はすべてのセグメントを意味します。つまり、Prod と他のセグメント (例えば、Dev、Test、Stage、QA など) の間で送信されるすべてのトラフィックが対象となります。”*” は、分離されたセグメントに対してセグメント内でのサービス挿入も提供します。 Inspection VPC 1 ネットワーク機能を通信経路に組み込むと、Prod セグメントと Dev セグメント間 (または、コアネットワークに存在する他のセグメント間) のすべてのトラフィックは、タグキー stage とタグ値 InspectionNFG を持つコアネットワークアタッチメントを使用して、Inspection VPC 1 のファイアウォールを経由して自動的に経路制御されます (図 3)。AWS Cloud WAN は以下の処理を行います: すべてのワークロードセグメントからのルートを、適切なワークロードアタッチメントにリダイレクトするネクストホップとともに、InspectionNFG ルートテーブルに伝播します。同一リージョン内で伝播されるルートは、そのネクストホップがローカルの NFG アタッチメントにリダイレクトされます。 注意： 後述のシナリオで説明するリージョン間ルーティングの場合、異なるリージョンからのルートは、ユーザー設定またはシステムデフォルトで設定された優先リージョンの NFG アタッチメントにネクストホップがリダイレクトされます。 ポリシーで指定されたすべてのセグメントペアについて、対応するワークロードセグメントルートテーブルにルートを伝播し、ネクストホップをローカルの NFG アタッチメントとして設定します。 図 3: リージョン内のセグメント間インスペクショントラフィックフロー Packet walkthrough: 以下のステップでは、同一リージョン内の Prod VPC 1 のリソースが Dev VPC 1 のリソースと通信する際のパケットの流れについて説明します。 (A) Prod VPC 1 のリソースが Dev VPC 1 のリソースへの接続を開始すると、Prod VPC 1 のルートテーブルを参照します。パケットはデフォルトルートエントリにマッチし、ターゲットとしてコアネットワークの Amazon リソースネーム (ARN) が指定されているため、パケットはコアネットワークにルーティングされます。 (B) パケットがコアネットワークに到達すると、Prod VPC 1 は Prod セグメントに関連付けられているため、Region 1 をエッジロケーションとして Prod セグメントのルートテーブルを参照します。パケットは Dev VPC 1 CIDR エントリにマッチし、Inspection VPC 1 アタッチメントがターゲットとなっているため、パケットは Inspection VPC 1 にルーティングされます。 (C) Inspection VPC 1 のファイアウォールが、設定されたセキュリティポリシーに基づいてトラフィックを検査し許可した後、パケットはコアネットワークに戻されます。 (D) パケットがコアネットワークに到達すると、Inspection VPC 1 は InspectionNFG に関連付けられているため、Region 1 をエッジロケーションとして InspectionNFG ルートテーブルを参照します。パケットは Dev VPC 2 CIDR エントリにマッチし、Dev VPC 1 アタッチメントがターゲットとなっているため、パケットは Dev VPC 1 にルーティングされます。 戻りトラフィックは、同じパスを逆方向にたどります。 シナリオ 2 – リージョン間、セグメント間のデュアルインスペクション 次の図 (図 4) はシナリオ 2 を示しています。シナリオ 2 はシナリオ 1 と似ていますが、Prod VPC と Dev VPC が異なるリージョンに配置されている点が異なります。Prod VPC 1 (10.1.0.0/16) はリージョン 1 に配置され、Prod セグメントに関連付けられています。一方、Dev VPC 2 (172.25.0.0/16) はリージョン 2 に配置され、Dev セグメントに関連付けられています。 異なるセグメント間のアタッチメント間を流れるトラフィックを検査する必要性に加えて、各 AWS リージョンを個別の保護された環境として扱う必要がある場合もあります。これを実現するために、各リージョンには独自の Inspection VPC があり、リージョン 1 には Inspection VPC 1 (100.64.1.0/24)、リージョン 2 には Inspection VPC 2 (100.64.2.0/24) があります。シナリオ 1 (Step 1-3) と同様に、InspectionNFG NFG を作成し、両方の Inspection VPC を InspectionNFG に関連付けます。 図 4: リージョン間、セグメント間のデュアルインスペクション 以下に示す segment-actions モードの dual-hop を使用して、リージョン間、セグメント間のトラフィックパスに InspectionNFG NFG を挿入します。これにより、各リージョンの Inspection VPC にトラフィックを振り分けすることが可能になります。 "segment-actions": [ { "action": "send-via", "segment": "prod", "mode": "dual-hop", "when-sent-to": { "segments": "*" }, "via": { "network-function-groups": [ "InspectionNFG" ] } } ], Inspection VPC 1 と Inspection VPC 2 のネットワーク機能を通信経路に挿入すると、Prod セグメントと Dev セグメント間 (または、コアネットワークに存在する他のセグメント間) のすべてのクロスセグメントトラフィックは、タグキー stage とタグ値 InspectionNFG を持つコアネットワークアタッチメントを使用して、それぞれ Inspection VPC 1 と Inspection VPC 2 のファイアウォールを経由して自動的にルーティングされます。これを図 5 で示します。 図 5: リージョン間、セグメント間のデュアルインスペクションのトラフィックフロー Packet walkthrough: 以下のステップは、Prod VPC 1 のリソースが Dev VPC 2 のリソースと通信する際のパケットの流れについて説明します。 (A) Prod VPC 1 のリソースが Dev VPC 2 のリソースへの接続を開始すると、Prod VPC 1 のルートテーブルを参照します。パケットはターゲットとしてコアネットワーク ARN を持つデフォルトルートエントリに一致し、パケットはコアネットワークにルーティングされます。 (B) パケットがコアネットワークに到着すると、Prod VPC 1 が Prod セグメントに関連付けられているため、Region 1 をエッジロケーションとして Prod セグメントのルートテーブルを参照します。パケットは、ターゲットとして Inspection VPC 1 アタッチメントを持つ Dev VPC 2 CIDR エントリに一致し、パケットは Region 1 の Inspection VPC 1 にルーティングされます。 (C) Inspection VPC 1 のファイアウォールが、設定されたセキュリティポリシーに基づいてトラフィックを検査し許可した後、パケットはコアネットワークに戻されます。 (D) パケットがコアネットワークに到着すると、Inspection VPC 1 が InspectionNFG に関連付けられているため、Region 1 をエッジロケーションとして InspectionNFG ルートテーブルを参照します。パケットは、ターゲットとして Inspection VPC 2 アタッチメントを持つ Dev VPC 2 CIDR に一致し、パケットは Region 2 の Inspection VPC 2 にルーティングされます。 (E) Inspection VPC 2 のファイアウォールが、設定されたセキュリティポリシーに基づいてトラフィックを検査し許可した後、パケットはコアネットワークに戻されます。 (F) パケットがコアネットワークに到着すると、Inspection VPC 2 が InspectionNFG に関連付けられているため、Region 2 をエッジロケーションとして InspectionNFG ルートテーブルを参照します。パケットは、ターゲットとして Dev VPC 2 アタッチメントを持つ Dev VPC 2 CIDR エントリに一致し、パケットは Dev VPC 2 にルーティングされます。 戻りトラフィックは、同じパスを逆方向にたどります。 シナリオ 3 – リージョン間、セグメント間のシングルインスペクション リージョンペアの場合、Service Insertion により、セグメント間のトラフィック検査を行うリージョンを選択できます。リージョン間およびセグメント間のトラフィック検査に使用するリージョンを選択するために、デフォルトで 順序付きリスト を使用します。以下に示す segment-actions モードの single-hop を使用して、リージョン間およびセグメント間のトラフィックパスに InspectionNFG NFG を挿入します。 "segment-actions": [ { "action": "send-via", "segment": "prod", "mode": "single-hop", "when-sent-to": { "segments": "*" }, "via": { "network-function-groups": [ "InspectionNFG" ] } } ], 図 6 に示すように、Region 1 と Region 2 のペアにおいて、Region 1 は us-east-1、Region 2 は us-west-2 であり、 順序付きリスト に従って、Region 1 (us-east-1) がインスペクションのデフォルトリージョンとして選択されています。そのため、Prod VPC と Dev VPC 間のすべてのリージョン間トラフィックは、インスペクションのために Region 1 の Inspection VPC 1 を経由してルーティングされます。 図 6: リージョン間、セグメント間のシングルスペクションのトラフィックフロー Packet walkthrough: 以下のステップでは、Prod VPC 1 のリソースがシングルインスペクションを使用して Dev VPC 2 のリソースと通信する際のパケットの流れについて説明します。 ステップ (A) から (C) は、シナリオ 2 で説明したものと同じですが、以下の点が異なります。 (D) パケットがコアネットワークに到着すると、Inspection VPC 1 が InspectionNFG に関連付けられているため、リージョン 1 をエッジロケーションとして InspectionNFG ルートテーブルの検索を行います。パケットは Dev VPC 2 CIDR エントリと一致し、リージョン 2 をエッジロケーションとして InspectionNFG ルートテーブルの検索を実行するように要求します。 (E) リージョン 2 をエッジロケーションとして InspectionNFG ルートテーブルの検索を行います。パケットは、Dev VPC 2 アタッチメントをターゲットとする Dev VPC 2 CIDR エントリに一致し、Inspection VPC 2 ではなく、パケットは Dev VPC 2 にルーティングされます。 戻りトラフィックは、同じパスを逆方向にたどります。 考慮事項 NFG はグローバルな性質を持ち、コアネットワークに属するどの AWS リージョンからでもアタッチメントを追加できます。たとえば、コアネットワークが 3 つの AWS リージョン (us-east-1、eu-west-1、ap-west-1 など) にまたがって運用されている場合、これら 3 つのリージョンのいずれからでも、単一の NFG にインスペクションまたはファイアウォール VPC を追加できます。 NFG は、コアネットワークごとの AWS Cloud WAN セグメントの クォータ から、1 つのグローバルセグメントを消費します。 ワークロードセグメントと NFG の両方で、すべてのアタッチメントタイプ (VPC、VPN、connect、transit gateway) がサポートされています。 このブログ投稿の執筆時点では、動的アタッチメント (VPN、connect、transit gateway peering) を通じて NFG にアドバタイズされた動的ルートは、NFG ルートテーブルにインストールされません。また、Service Insertion を機能させるためには、デフォルトルート (0/0、::/0) を動的アタッチメントを通じて NFG にアドバタイズする必要があります。詳細については、AWS Cloud WAN のドキュメントを参照してください。 コアネットワークごとに複数の NFG がサポートされていますが、セグメントペア内のインサーションごとに単一の NFG のみが許可されます。アタッチメントはセグメントまたは NFG のいずれかに関連付けることができますが、両方に関連付けることはできません。通常、ワークロードアタッチメント (ワークロード VPC) はセグメントに関連付けられ、インスペクション VPC (ファイアウォール、侵入検知システム、侵入防止システムアプライアンスをホスト) は NFG に関連付けられます。 同じコアネットワークで複数の NFG を設定できます。ただし、同じセグメントまたはセグメントペアに複数の NFG を挿入することはできません。 同じセグメントに接続されたリソース間のトラフィックを検査する必要がある場合は、該当するワークロードセグメントの分離モードを有効にします。この設定により、挿入が必要なネットワーク機能をバイパスすることなく、セグメントに関連付けられたアタッチメント間の直接接続を防止します。 AWS Cloud WAN の アプライアンスモード は、Service Insertion とは独立しており、VPC 内のセキュリティインフラストラクチャを通じてステートフルインスペクションを確実に行いたい場合に必要です。特定のネットワークフローの双方向のトラフィックが同じアベイラビリティーゾーンに、そして結果として同じセキュリティアプライアンスにステートフルインスペクションの目的で転送されるようにするには、インスペクション VPC アタッチメントでアプライアンスモードを有効にする必要があります。 AWS Cloud WAN は IPv4 と IPv6 の両方をサポートしています。 通常の AWS Cloud WAN の料金 以外に、Service Insertion の使用に関する追加料金はありません。 業界をリードするパートナー AWS Cloud WAN Service Insertion のローンチにおいて、業界をリードするパートナー企業と協力できたことを嬉しく思います。パートナー企業の素晴らしい取り組みとコメントをご紹介します： Aviatrix ブログ Check Point ブログ Cisco ブログ F5 ブログ Fortinet ブログ Netskope ブログ Palo Alto Networks ブログ 1 ブログ 2 まとめ このブログ記事では、AWS Cloud WAN Service Insertion について説明しました。これは、中央のポリシードキュメントを使用して AWS および他社のネットワークとセキュリティサービスを AWS Cloud WAN にシームレスに挿入できる新機能です。この機能を使用すると、シンプルなポリシーステートメントを定義するか、コンソールを使用することで、VPC 間または VPC とオンプレミス間のトラフィックをネットワークまたはセキュリティアプライアンスを通じて簡単に制御できます。また、この新機能を使用したリージョン内およびリージョン間のインスペクションアーキテクチャについても説明しました。詳細については、 AWS Cloud WAN のドキュメントをご参照ください。 更新情報: 2024 年 6 月 28 日: 図 5 とそれに続くパケットの説明に修正を加えました。 2024 年 11 月 25 日: 業界をリードするパートナーとして Fortinet が追加されました。 著者について Pratik Mankad Pratik は、AWS の Network Solutions Architect です。彼はネットワーク技術に情熱を持ち、お客様の問題解決を支援するためにイノベーションを生み出すことを愛しています。彼はソリューションの設計と技術的なガイダンスの提供を通じて、お客様やパートナーが技術的・ビジネス的な目標を達成できるよう支援することを楽しんでいます。 Shridhar Kulkarni Shridhar は Amazon Virtual Private Cloud（VPC）チームの一員であり、AWS Cloud WAN サービスのプロダクトマネジメントをリードしています。彼は、クラウド、SAAS、モバイル、SD-WAN、仮想化、WAN 最適化、SDN、データネットワーキング（L1-L7）、VoIP、ケーブル、FTTH、x86 ハードウェアプラットフォームに関する専門知識を持つ、強力で多様な技術的バックグラウンドを有しています。また彼は、世界中のクラウド、エンタープライズ、サービスプロバイダー、中小企業の顧客向けに最先端のハイテク製品やサービスを提供してきた実績があり、コンピュータサイエンスの修士号と UCLA アンダーソン経営大学院のMBAを取得しています。 Rizwan Mushtaq Rizwan は AWS の Principal Solutions Architect です。彼はお客様が AWS サービスを使用して革新的で耐障害性が高く、コスト効率のよいソリューションを設計することを支援しており、ウィチタ州立大学で電気工学の修士号を取得しています。 翻訳は Solutions Architect の疋田 洋一が担当しました。原文は こちら です。

商品を購入する前に、新しい服が自分にどのように似合うかをすばやく確認できたらいいのに、と思ったことはありませんか？あるいは、リビングに置いた家具はどう見えるか、気になったことはありませんか？本日、このような商品画像生成の課題に対応する Amazon Nova Canvas の新しい Virtual try-on 機能を紹介できることを嬉しく思います。さらに、スタイルの一貫性を向上させるための 8 つの新しいスタイルオプションが、text-to-image ベースのスタイルプロンプトに追加されました。これらの機能により、Nova Canvas AI を活用した画像生成機能が拡張され、顧客体験を向上させるリアルな製品の視覚化や、定型化された画像の作成作業がこれまでになく簡単になります。 今すぐ使い始める方法を簡単に見てみましょう。 Getting started まず、通常の方法で Nova Canvas モデルにアクセスできることを確認します。 Amazon Bedrock コンソール で [モデルアクセス] を選択し、 アカウントの Amazon Nova Canvas を有効にして 、ワークロードに適したリージョンを選択していることを確認します。モデルアクセスの有効化方法については、ブログ「 Amazon Bedrock のモデルアクセスの有効化や制限値の引き上げができない時の対応方法 」をご覧ください。すでに Nova Canvas にアクセスして使用している場合は、新機能が自動的に利用可能になるので、すぐに使い始めることができます。 Virtual try-on 最初のエキサイティングな新機能は Virtual try-on です。この機能を使用して、2 枚の写真をアップロードして Amazon Nova Canvas に依頼すると、現実的な仕上がりとなるようにそれらの画像が合成されます。これらの画像は、アパレル、アクセサリー、家具、および、多様な衣類を含む、様々な種類のその他の製品の写真が想定されます。たとえば、ソース画像として人物の写真、参照画像として衣服の写真を指定すると、Amazon Nova Canvas が同じ人が衣服を着ている新しい画像が作成されます。これを試してみましょう。 私はまず、2 つの画像を選択することから始めました。服の交換にぴったりだと思うポーズをしている私の写真と、AWS ブランドのパーカーの写真を 1 枚選びました。 Nova Canvas への入力画像は、最大 410 万ピクセル（2,048 x 2,048 に相当）であることに注意してください。(詳細要件は Amazon Nova ユーザーガイド(英語) を参照) 必要に応じて、これらの制限に合わせて画像のサイズを調整してください。また、この記事で取り上げた Python コードを実行したい場合は、Python 3.9 以降と Python パッケージ boto3 と pillow がインストールされていることを確認してください。 このパーカーを私の写真に適用するには、Amazon Bedrock ランタイムの invoke API を使っています。この API のリクエストとレスポンス構造の詳細については、 Amazon Nova ユーザーガイド(英語) をご覧ください。コードは単純で、必要な推論パラメータはごくわずかです。私は "VIRTUAL_TRY_ON" という新しい taskType を使用しました。次に、 virtualTryOnParams オブジェクトを使用して必要なパラメータをいくつか設定し、ソースイメージと参照イメージの両方を含め、必要な設定を指定しました。どちらのイメージも Base64 文字列に変換する必要があることに注意してください。 import base64 def load_image_as_base64(image_path): """Helper function for preparing image data.""" with open(image_path, "rb") as image_file: return base64.b64encode(image_file.read()).decode("utf-8") inference_params = { "taskType": "VIRTUAL_TRY_ON", "virtualTryOnParams": { "sourceImage": load_image_as_base64("person.png"), "referenceImage": load_image_as_base64("aws-hoodie.jpg"), "maskType": "GARMENT", "garmentBasedMask": {"garmentClass": "UPPER_BODY"} } } Nova Canvas はマスキングを使用して画像を操作します。これは、マスキングテープを使用してペイントしたくない領域を保護するのと同様に、AI 画像生成で画像の特定の領域または領域に焦点を合わせながら、他の領域は保存できるようにする手法です。 マスキングには、3 種類のマスキングモードを使用できます。 maskType を適切な値に設定することで選択できます。今回は、日本語で衣料品を示す言葉である "GARMENT" タイプを使っているので、同時に、体のどの部分をマスクしたいかを指定する必要があります。私は "UPPER_BODY" を使用していますが、特に足をターゲットにしたい場合は "LOWER_BODY" や、 "FULL_BODY" 、 "FOOTWEAR" など他のものを使用してもかまいません。オプションの全リストは Amazon Nova ユーザーガイド(英語) を参照してください。 次に invoke API を呼び出し、これらの推論引数を渡して、生成されたイメージをディスクに保存します。 # Note: 上記の inference_params 変数が以下で参照されています。 import base64 import io import json import boto3 from PIL import Image # Create the Bedrock Runtime client. bedrock = boto3.client(service_name="bedrock-runtime", region_name="us-east-1") # Prepare the invocation payload. body_json = json.dumps(inference_params, indent=2) # Invoke Nova Canvas. response = bedrock.invoke_model( body=body_json, modelId="amazon.nova-canvas-v1:0", accept="application/json", contentType="application/json" ) # Extract the images from the response. response_body_json = json.loads(response.get("body").read()) images = response_body_json.get("images", []) # Check for errors. if response_body_json.get("error"): print(response_body_json.get("error")) # Decode each image from Base64 and save as a PNG file. for index, image_base64 in enumerate(images): image_bytes = base64.b64decode(image_base64) image_buffer = io.BytesIO(image_bytes) image = Image.open(image_buffer) image.save(f"image_{index}.png") 非常にエキサイティングな結果を得ました！ このように、私は AWS ブランドのパーカーを着ることができ、誇りに思います！ "GARMENT" mask type に加えて、 "PROMPT" や "IMAGE" マスクも使用することができます。 "PROMPT" では、ソース画像と参照画像も提供する必要がありますが、ソース画像のどの部分を置換するかを自然言語のプロンプトで指定します。これは、Nova Canvas の "INPAINTING" と "OUTPAINTING" タスクの仕組みと似ています。独自のイメージマスクを使用する場合は、 "IMAGE" mask type を使用し、マスクとして使用する白黒画像を指定します。黒はソースイメージで置き換えたいピクセルを示し、白は維持したいピクセルを示します。 この機能は小売業者にとって特に便利です。これを利用して、購入前に商品の見た目を確認することで、顧客がより適切な購入判断を下せるようになります。 Style options アニメのスーパーヒーローになったらどんなふうになるのだろうといつも思っていました。以前は、Nova Canvasを使って自分の画像を操作できましたが、それを適切に行うには、優れたプロンプトエンジニアリングスキルに頼らざるを得ませんでした。 現在、Nova Canvasには事前にトレーニングされたスタイルオプションが付属しており、それを画像に適用して、お好みの芸術的スタイルに沿った高品質の結果を得ることができます。3Dアニメーションファミリーフィルム、デザインスケッチ、フラットベクターイラスト、グラフィックノベル、マキシマリズム、ミッドセンチュリーレトロ、フォトリアリズム、ソフトデジタルペインティングなど、8つのスタイルが用意されています。 それらの適用は、Nova Canvas API に追加のパラメーターを渡すのと同じくらい簡単です。例を試してみましょう。 「3D アニメーションファミリーフィルム」スタイルを使って AWS のスーパーヒーローのイメージを生成したいと思います。そのためには、 "TEXT_IMAGE" という taskType と、 text と style の 2 つのパラメータを含む textToImageParams オブジェクトを指定します。 text パラメータには、作成したい画像を説明するプロンプトが含まれています。今回は「大きな AWS ロゴとケープが付いた黄色い衣装のスーパーヒーロー」と指定しています。 style パラメータは、定義済みのスタイル値の 1 つを指定します。ここでは "3D_ANIMATED_FAMILY_FILM" を使用していますが、全リストは Amazon Nova ユーザーガイド(英語) に記載されています。 inference_params = { "taskType": "TEXT_IMAGE", "textToImageParams": { "text": "a superhero in a yellow outfit with a big AWS logo and a cape.", "style": "3D_ANIMATED_FAMILY_FILM", }, "imageGenerationConfig": { "width": 1280, "height": 720, "seed": 321 } } 次に、前の例と同じように invoke API を呼び出します。(ここでは簡潔にするためにコードを省略しています)。そしてその結果は？さて、皆様ご判断いただければと思いますが、AWS のスーパーヒーローが、私の好きな色を、私が思い描いていた 3D アニメーションのファミリーフィルムのスタイルにあわせて着ています。とても満足していると言わざるを得ません。 本当に素晴らしいのは、コードとプロンプトをまったく同じにしたまま、スタイル属性の値を変更するだけで、まったく異なるスタイルの画像を生成できることです。これを試してみましょう。 style を PHOTOREALISM に設定しました。 inference_params = { "taskType": "TEXT_IMAGE", "textToImageParams": { "text": "a superhero in a yellow outfit with a big AWS logo and a cape.", "style": "PHOTOREALISM", }, "imageGenerationConfig": { "width": 1280, "height": 720, "seed": 7 } } そして、その結果は印象的なものとなりました！私が説明したとおりのフォトリアリスティックなスーパーヒーロー。これは前に生成されたアニメスタイルとは全く異なるものとなり、必要な作業は、1 行のコードを変更することだけでした。 知っておくべきこと 利用可能なリージョン – Virtual try-on とスタイルオプションは、US East (N. Virginia)、Asia Pacific (Tokyo)、 Europe (Ireland) の Amazon Nova Canvas で利用いただけます。Amazon Nova Canvas の既存ユーザーは、新しいモデルに移行しなくてもすぐにこれらの機能を使用できます。 料金 – Amazon Bedrock 料金ページ をご覧ください。 Virtual try-on は簡単に試すことができます。 nova.amazon.com (http://nova.amazon.com/) へアクセスし、人物と衣服の画像をアップロードして、様々な服の着せ替えを楽しんでください！ 始める準備ができたら、Nova Canvas ユーザーガイドを確認するか、AWS コンソールにアクセスしてください。 Matheus Guimaraes | @codingmatheus Matheus Guimaraes Matheus Guimaraes (@codingmatheus) は .NET と microservice のスペシャリストで、インターナショナル キーノートスピーカーです。また、AWS の開発者支援者25 年以上技術に携わってきた彼は、ジュニアゲームプログラマーから CTO、スタートアップの創設者まで、さまざまな役職を歴任してきました。Matheus は、あらゆる規模の企業のシステムの近代化と拡張を支援し、デジタルトランスフォーメーションを主導し、クラウドネイティブアーキテクチャを設計してきました。現在、彼は講演、ブログ、ビデオを通じて専門知識をグローバルに共有し、業界で他の企業の成長を支援することに情熱を注いでいます。テクノロジー以外にも、彼はゲーマー、スイマー、ミュージシャンであり、創造性とコードの強力な融合を信じています。

本稿は、2024年4月15日に AWS Cloud Operations Blog で公開された “ Automate incident reports from AWS Systems Manager Incident Manager ” を翻訳したものです。 システムの信頼性を維持し、予期せぬインシデントに迅速に対応するためには、効果的なインシデント管理が最も重要です。AWS Systems Manager の機能である Incident Manager は、自動対応機能を提供することで、これらのインシデントの緩和と復旧を支援します。以前の Incident Manager に関するブログでは、エスカレーションメカニズムの設定、対応計画の作成、AWS Systems Manager Automation ランブックを使用した修復の自動化について説明しました。詳細については、 AWS Systems Manager Incident Managerで連絡先、エスカレーションプラン、対応プランを作成する をご覧ください。 インシデントライフサイクルの一環として、組織がインシデントの過去データを収集し、振り返って事後分析を行うことが重要です。お客様は AWS SDK を使用して、これらすべてのインシデントに関する情報をプログラムで収集してエクスポートすることができます。お客様からは、このレポート生成プロセスを自動化し、これらのレポートを一元化された場所に定期的にエクスポートする方法についてよく質問を受けます。 このブログでは、スケジュールに従って Incident Manager のレポートを生成し、Amazon Simple Storage Service (Amazon S3) に保存する方法を説明します。これらのレポートは、関係するリソース、頻発する問題、修正に要する時間などに基づいてインシデントを確認し、並べ替えるのに役立ちます。これらは、運用エンジニア、システム管理者、IT マネージャーに重要な気づきを与えます。過去のデータを掘り下げることで、アプリケーションやインフラストラクチャの異常を発見できます。 前提条件 このウォークスルーを行うには、以下の前提条件が必要です AWS アカウント シングルアカウントまたはマルチアカウント、マルチリージョンで設定された Incident Manager ワークフロー このソリューションは、以下のサービスによって実現されています。 AWS CloudFormation Amazon S3 AWS Identity and Access Management (IAM) AWS Systems Manager の機能である Automation AWS Systems Manager の機能である State Manager AWS Systems Manager の機能である Incident Manager 図1: Incident Manager レポート生成ソリューション CloudFormation テンプレートは GitHub リポジトリ にホストされています。CloudFormation は、このソリューションで使用される必要なコンポーネントをデプロイします。これには、S3 バケット、Automation ランブック、State Manager アソシエーション、必要な IAM 権限が含まれます。Automation は Incident Manager API に接続して必要な情報を抽出し、CSV ファイル形式で S3 バケットにアップロードします。 ソリューションを実行するたびに、新しいレポートが生成されます。オプションとして、スケジュールでソリューションを実行することを選択した場合、CloudFormation テンプレートは、CloudFormation スタックの作成時にパラメータとして指定されたスケジュールで実行される State Manager アソシエーションを作成します。 Automation ランブックには、Python スクリプトを実行してレポートを生成および保存する  aws:executeScript アクションが含まれています。Python スクリプトは ListIncidentRecords API を呼び出して、現在のリージョンのすべてのインシデントを取得します。次に、スクリプトはインシデントごとに  ListRelatedItems API を実行して、関連するすべてのアイテムを取得します。収集したインシデントは CSV ファイルに保存され、 IMReport-{Current Date}-{Time in UTC} の形式で名前が付けられます。この CSV ファイルは、ダウンロード用の S3 バケットにアップロードされます。さらに、このソリューションをカスタマイズして、各レポートを S3 へアップロードした時に SNS 通知を送信することができます。詳細については、 Amazon S3 イベント通知 を参照してください。 ソリューションの手順 単一のアカウントまたはマルチアカウントおよびマルチリージョンのインシデント管理では、インシデントはすべてのアカウントとレプリケーションセットリージョンに複製されます。したがって、目的のアカウントとリージョンに CloudFormation テンプレートをデプロイして、インシデントとそれに関連するアイテムを取得できます。 ソリューションのデプロイ CloudFormation テンプレート をダウンロードします。 レポートを生成したい AWS アカウントの CloudFormation コンソール に移動します。 Create Stack で、with new resources (standard) を選択します。 Prepare template で、Choose an existing template を選択し、Template source で Upload a template file を選択します。Choose file をクリックし、ステップ 1 でダウンロードしたテンプレートを選択します。 Next をクリックします。 Stack name に、スタック名 ( 例: incident-manager-reporting ) を入力します。 Parameters エリアで以下の操作を行い、Next をクリックします。 ‘RunOnSchedule’ にて、定期的にレポートを生成する場合は true を選択し、レポートを手動で生成する場合は false を選択します。 false を選択した場合、この CloudFormation テンプレートをデプロイした後、 Generating OnDemand reports セクションを参照して、Automation ランブックを手動で実行する必要があります。 ‘AssociationSchedule’ ( RunOnSchedule が true に設定されている場合のみ必要 ) では、CRON 式を入力します。デフォルトでは、毎週日曜日の 02:00 AM UTC に自動で実行されます。サポートされている CRON 式の詳細については、 リファレンス を参照してください。 Configure stack options ページで I acknowledge that AWS CloudFormation might create IAM resources. を選択し、Next をクリックします。 Review and create ページで、Submit をクリックします。 テンプレートがデプロイされた後、図 2 に示されているように Outputs を選択して以下の値を確認してください。 AWSSystemsManagerAutomationExecutionRole S3Bucket SystemsManagerAutomationDocument 図2：CloudFormation の出力リソース オンデマンドレポートの生成 注意 – CloudFormation テンプレートをデプロイする際に `RunOnSchedule` パラメータを true に設定した場合は、このセクションをスキップして S3 コンソールからレポートをダウンロード のセクションに進んでください。 Systems Manager Automation に移動します。 Execute runbook をクリックします。 Owned by me を選択し、Outputs で確認した SystemsManagerAutomationDocument の Value に表示されていたランブック名 (incident-manager-reporting-SystemsManagerAutomationDocument-*) を選択します。Next をクリックします。 図 3: Automation ランブック Simple execution を選択します。 Input parameters エリアの AutomationAssumeRole には、 図 4 に示されているように CloudFormation スタックから出力された AWSSystemsManagerAutomationRole の Value を入力します。S3BucketName には、CloudFormation スタックから出力された S3Bucket の Value を入力します (これがデフォルト値になります)。 図 4: Automation Assume Role と S3 Bucket の入力 Execute をクリックします。 Automation ランブックがアカウントのすべてのインシデントに関する情報を収集します。図 5 に示されているように、Executed steps で Step ID をクリックし、 OutputPayload の Amazon S3 バケットと CSV ファイル名を確認します。 図 5: Systems Manager Automation の出力 S3 コンソールからレポートをダウンロード S3 console に移動し、バケットを見つけて IM Report CSV をダウンロードします。図 6 に示されるように、ファイル名にはレポートが生成された日時 (UTC) が含まれています。 図 6: レポートファイルの IMReport CSV をダウンロード 図 7: Incident Manager レポートファイルの例 クリーンアップ CloudFormation で作成したリソースをクリーンアップする: S3 バケット内に生成されたオブジェクトを手動で削除 AWS S3 コンソールを開き、CloudFormation で生成された S3 バケットを見つけます。 すべてのオブジェクトを選択し、Delete をクリックします。 削除を確定するには、テキスト入力フィールドに permanently delete と入力します。 ‘Delete objects’ をクリックします。 CloudFormation スタックを削除 Open the AWS CloudFormation コンソール を開き、ナビゲーションペインで Stacks を選択します。 作成した CloudFormation スタックを選択し、 Delete をクリックした後、確認画面で Delete をクリックします。 まとめ このブログ記事では、Incident Manager API と AWS Systems Manager Automation および State Manager Association を使用して、全てのインシデントとそれに関連するアイテムをスケジュールに従って定期的に保存するレポート生成ソリューションについて説明しました。このソリューションでは以下のことができます: レポート生成の自動化: 手作業は不要 – プロセスを合理化し、レポートを Amazon S3 に安全に保存します。 貴重な傾向の発見: 頻繁に発生する問題、脆弱なリソース、解決時間を特定します。 効率と安全性の向上: ボトルネックを事前に解消し、再発を防止し、クラウド環境を最適化して最大限の回復力を実現します。 著者について: Ali Alzand Ali は、Amazon Web Services の Microsoft スペシャリストソリューションアーキテクトです。Ali は、グローバルな顧客と連携し、Microsoft ワークロードの AWS クラウドへの移行、近代化、最適化を支援しています。専門は、AWS Systems Manager、Amazon EC2 Windows、PowerShell です。仕事以外では、バーベキュー、アウトドア活動、さまざまな食べ物に挑戦することを楽しんでいます。 Raviteja Sunkavalli Raviteja Sunkavalli は、Amazon Web Services のシニアクラウドサポートエンジニアです。Ravi は、グローバル顧客のクラウド移行と集中運用の効率化をサポートしています。専門は、AWS Systems Manager と EC2 Windows サービスです。テクノロジー以外では、クリケットをプレーしたり、新しいレシピに挑戦したりすることを楽しんでいます。 翻訳は SA 渡邊が担当しました。 TAGS: AWS Systems Manager , Cloud Operations , Operations Integrations , Systems Manager Automation , Systems Manager Incident Manager

レンゴー株式会社について レンゴーは、たゆまぬ意識改革とイノベーションを通じて、あらゆる産業のすべての包装ニーズに対し、総合的なソリューションでお応えする「GPI=ゼネラル・パッケージング・インダストリー」です。物流と暮らしの豊かさを支え、より良い社会、持続可能な社会の実現を目指して取り組んでいます。 はじめに データ活用が企業の競争力を左右する時代において、多くの企業がデータ駆動組織への転換を模索しています。私たちレンゴーも例外ではなく、長年にわたりデータ活用の拡大に取り組んできました。しかし、その道のりは順調とは言えませんでした。思うような成果が得られない中、私たちはAWSとパートナー企業（ 株式会社JSOL ）の協力を得て、自社の課題に特化した研修プログラムを開発しました。このアプローチが功を奏し、社内でのデータ活用の取り組みに変化の兆しが見え始めています。本稿では、同様の課題に直面している企業の皆様に向けて、私たちの取り組みと経験から得た気づきを共有します。 データ活用を妨げる三つの課題 レンゴーは、製紙業界が直面する厳しい経営環境と2024年問題として知られる物流危機への対応を迫られていました。業界全体が原材料コスト上昇、環境規制強化、デジタル化による紙需要減少という三重苦に直面する中、データ活用による業務変革が不可欠との判断に至りました。そして、2021年から2023年にかけて、全社で使用する汎用データ基盤の構築に取り組みました。各工場から収集したデータをデータ基盤に集約し、Amazon QuickSightを使って可視化できる分析基盤を構築しました。 技術的な基盤は整ったものの、実際のデータ活用は思うように進展しませんでした。データは蓄積されているにもかかわらず、それを業務改善や意思決定に活かすという段階に至らなかったのです。インフラ構築だけではデータ駆動組織への転換は実現しないという問題に直面しました。私たちはこの問題を引き起こす要因として、「ソフトスキル」「ハードスキル」「ツール」の3つの観点があると仮説を立てました。 (1) 業務部⾨⾃らデータを活⽤する⾵⼟の醸成（ソフトスキル） データ基盤の整備は進んでいたものの、データ活用は情報システム本部や一部の研究開発部門にとどまり、業務部門にまで浸透していませんでした。特に顕著だったのは、現場においてデータを活用して業務効率化を図るという発想自体がないことでした。多くの現場担当者は長年培われた経験や勘を頼りに業務を遂行しており、既存の業務プロセスに特段の課題を感じていませんでした。「今までもうまくいっているのだから」という意識が強く、変革の必要性を実感できていなかったのです。 この状況を打開するためには、データ活用によって得られる具体的なメリットを現場レベルで理解してもらう必要がありました。更に、データを活用して業務改善に取り組むモチベーションを喚起し、継続的な改善に取り組む文化を醸成することが求められていました。 (2) データ分析スキルの取得（ハードスキル） もちろん、データ活用に対する意欲を持つ社員は一定数存在しています。しかし、自身の業務に課題を感じ、改善意欲を持つ担当者がいても、普段の業務に求められるスキルセットと、データ分析に必要なスキルセットとの間には大きな乖離があります。製造現場や営業部門など、それぞれの専門分野では高い能力を持つ社員でも、データ分析については未経験であることがほとんどでした。 この問題を解決するためには、データ分析について基礎から体系的に学ぶ機会を提供することが不可欠でした。担当者一人ひとりが、自らの業務課題とデータ活用を結びつけられるよう、机上の知識の取得するだけでなく、実践的なスキルを習得できるプログラムを構築することが求められていました。 (3) QuickSightの認知度向上（ツール） 業務部門の中でも、一部の部門はデータからレポートを作成する業務を担っていましたが、そういった部署においてもデータ活用は進んでいませんでした。データ分析ツールとしてQuickSightが導入されていたにもかかわらず、従来と変わらずExcel等の表計算ソフトを用いて手作業でレポートを作成していました。　こうした状況の背景には、BIツールの提供する価値や機能が十分に理解されていないという問題がありました。多くの社員はBIツールを「難しい専門家向けのシステム」と捉え、自分たちの業務とは関係ないものだと認識していました。 この問題を解決するためには、まずBIツールを活用するメリットを実感してもらう必要がありました。また、自部門の業務に直結するユースケースを示し、ツールの基本的な操作方法を習得してもらうことで、「自分たちにも使える」という認識を持ってもらうことが重要でした。 目指すべき姿と自社にカスタマイズされた教育プログラムの開発 レンゴーの中期経営計画においても、DXによる価値創出が重要な戦略として位置づけられていました。この目標を実現するためには、組織全体でデータ活用の文化を醸成し、個々の社員が目的意識を持ってデータを活用し、業務改善に取り組む体制になっていることが必要不可欠です。 図1　デジタイゼーション・デジタライゼーションとデジタルトランスフォーメーション（DX) しかし、前述した「ソフトスキル」、「ハードスキル」、「ツール」の三つの課題を解決するためのノウハウは社内にありませんでした。そこで私たちは、AWSが提供している無償の データ活用ワークショッププログラム に着目し、これをベースとして研修プログラムを作成することを検討しました。しかし、AWS の担当者からプログラムの内容をヒアリングする中でプログラムを適用するだけでは、人手とコンテンツのカスタマイズ性の面で、当社特有の課題に対応できない可能性があることがわかりました。そこで、データ活用に対して専門知識を持つパートナー企業を交え、３社共同で研修プログラムの開発に取り組むことを決断しました。そして、研修を前述した3つの課題に対し、それぞれの会社が強みを発揮できる内容に構成しました。 (1) Working Backwards を使用した課題解決手法の習得（ソフトスキル） 研修プログラムの核となる特徴として、Amazonが社内で実践している課題解決のフレームワーク「Working Backwards」を取り入れました。この手法は、目標から逆算して必要なステップを明確化するアプローチで、データ活用においても非常に効果的です。その際、架空のシナリオではなく、現実の課題を題材とすることで、研修の実効性を高めることを目指しました。研修の中で参加者が自部門で実際に直面している課題を題材とし、その課題を解決するために最適なダッシュボードがどのようなものかを検討します。そして、研修期間内に、QuickSightでダッシュボードを作成するところまで実践します。 このアプローチを取ることで、参加者は、課題解決のプロセスを体系的に学ぶことができるだけでなく、データ分析の有用性を体感できます。そして、研修終了時には、明日から実務で使える具体的な成果物を持ち帰ることができるため、学びを即座に実践に移す橋渡しとなります。 (2) データ分析関連の知識を網羅的に学ぶことができるコンテンツの開発（ハードスキル） 初学者でもついていけるような研修プログラムを設計する為、私たちはJSOLに協力を依頼しました。JSOLを選定した理由は主に二つあります。一つ目は、同社が データ活用支援 において豊富な実績を持っていたことです。そして、二つ目の理由は、レンゴーの汎用データ基盤の構築をJSOLが担当していたという点です。データの構造や特性を熟知しているパートナーであれば、より実践的な研修内容を構築できると考えました。 そして、JSOL主導で統計学の基礎知識から始まり、データ分析の手法、そして効果的なダッシュボードデザインの実践に至るまで、データ分析プロセス全体を網羅する包括的な研修コンテンツを作成しました。このコンテンツを設計する際に意識したことは、①「データ分析の経験がまったくない社員でも無理なく参加できること」と、②「データ分析に必要な知識を網羅的に習得できること」の２つです。単なる概念理解にとどまらず、実務で即座に活用できる知識の習得を重視しました。 (3) 実データを使用したQuickSightハンズオンの実施（ツール） レンゴーではコスト効率の高さとAWS環境との親和性を評価し、Amazon QuickSightをBIツールとして導入してます。ダッシュボードを作成する為には、受講者にQuickSightのスキルを習得してもらう必要がありました。そこで、架空のデータではなく、レンゴー社内に実際に蓄積されている業務データを活用することにこだわりハンズオンコンテンツを作成しました。また、ハンズオン手順書についても、初心者が躓きやすいポイントを予測し、詳細な操作ガイドと補足説明を作成するなど、レンゴー社員の視点から理解しやすいコンテンツ作成を意識しました。 このアプローチには二つの重要な狙いがありました。一つ目は、参加者に「実際の業務でどのようにデータを活用するか」の具体的なイメージを掴んでもらうことで、二つ目が新たに必要なデータセットが生じた際に、情報システム部門に相談する方法を知ってもらうことです。データ分析をしたいが「誰に相談すればいいのかわからない」という心理的障壁を取り除くことを目指しました。 全社に向けてデータ活用研修を開催 今回開発した研修プログラムを、2024年11月から2025年1月の3ヶ月間にわたり、東京と大阪の2会場で開催しました。そして、計6日間のカリキュラムに、異なる業務部門から20人が参加しました。この6日間の内訳について掘り下げて説明します。 　　 図2 研修の様子 (1) データ分析の基礎固め         最初の2日間では、統計学の基礎知識やAmazonの「Working Backwards」の学習、そして基本的なQuickSightのハンズオンを通じて、データ分析の土台を固めました。加えて、２日目が終了した時点で、参加者に対し「自部門が抱える実際の課題」を見つけてくるという宿題を課しました。 図 3 研修に使用したコンテンツ (2) 実業務に直結するダッシュボードイメージ作成 3日目は、各参加者が持ち寄った業務課題に対して議論を展開しました。課題の本質を掘り下げた上で、課題を解決するためのダッシュボードを手書きで作成しました。この作業を通して、効果的な可視化方法等をダッシュボード設計の基本原則を実践を通して学んでもらいました。 図 4 ダッシュボード作成ワークショップ (3) QuickSightを使用したダッシュボード作成 4日目と5日目は、手書きで設計したダッシュボードイメージをAmazon QuickSightを使用したインタラクティブなダッシュボードへと具現化する作業に取り組みました。その際、質問をリアルタイムで受け付ける体制を取り、参加者の疑問をその場で解消するよう努めました。 図 5 ダッシュボードイメージ (4) 成果報告会 研修の集大成として6日目には、各部門の上席者を招いた成果報告会を開催しました。参加者が自らが特定した業務課題と課題を解決するために作成したダッシュボードについて発表を行い、自部門の上長に対し成果を共有しました。この報告会は、学びの成果を組織全体に波及させる重要な機会となりました。 図 6 成果報告会の様子 研修がもたらした組織変革の兆し 研修終了時には、研修に参加した20人全員が、自部門の課題解決に直結する実用的なダッシュボードを完成させました。基礎から体系的に学べるカリキュラムにしたことで、6日間という長期間かつ高密度の研修にもかかわらず、一人のリタイアも出しませんでした。さらに喜ばしいことに、研修終了後も社内にデータ活用の土壌が着実に育ちつつあります。具体的には次の３つの成果を得る事ができました。 (1) 参加者主導によるダッシュボードの全国展開 研修プログラムの最も顕著な成果として、参加者が自部門でのデータ活用の推進役となり、実際の業務改善に直結するダッシュボードが全国展開という事例が挙げられます。特に注目すべきは「取り組み状況検索」と名付けられた分析ダッシュボードの開発と普及です。このダッシュボードは、これまで各営業担当者が個別に時間をかけて調査・集計していた情報を一元的に可視化し、即座にアクセスできるようにしたものです。この成功事例は、当初私たちが懸念していた「研修で終わり」という状況に陥らなかったことを如実に示しています。この研修の主要な狙いの一つであった「データを活用する土壌の醸成」が実際に起こった結果だと認識しています。 (2) QuickSight ユーザーの増加 研修プログラムの効果は、具体的な数字としても明確に表れています。研修終了から3ヶ月という短期間のうちに、Amazon QuickSightのAuthor権限（ダッシュボードを自ら作成・編集できる権限）を持つユーザーが100名以上も増加しました。この数字は、単なるツール導入の成功を超え、「自らデータを分析し、可視化する」という行動変容が組織内で広がりつつあることを示しています。また、来期以降も同研修を実施する予定であることを踏まえると、この増加傾向が一時的なものではなく、今後も継続して拡大していく見込みです。 (3) データ収集・蓄積依頼の増加 研修終了後には、データ活用の基盤となるデータの収集・蓄積プロセスにおいても、変化が見られています。これまでレンゴーでは、情報システム部門が主導して「重要と思われるデータ」を特定し、業務部門に対してその活用を提案するという「プッシュ型」のアプローチが一般的でした。しかし研修実施後、この流れは完全に逆転し、業務部門から情報システム部門へのデータ収集依頼が殺到するという「プル型」の状況へと変化しました。現在では、情報システム部門が全てに対応しきれないほどの要件が寄せられており、業務部門と綿密な対話を重ねながら優先度を設定し、段階的に対応を進めている状況です。この変化は、データ活用の価値が業務部門に深く理解され、自らの業務課題解決のためにデータを積極的に活用しようという意識が広がった結果だと言えるでしょう。 これまでに述べた様々な成果から、レンゴー社内においてデータ活用を行う文化が着実に醸成されつつあると判断しています。しかし、私たちはこれを通過点に過ぎないと認識しています。真のデータドリブン組織への変革は一朝一夕に成し遂げられるものではなく、継続的な取り組みが不可欠です。そのため、今回紹介した研修プログラムは単発の施策ではなく、来期以降も継続して実施していく予定です。この活動を継続・拡大していくことで、レンゴー全体のデータ活用促進とDX推進をさらに加速させ、中期経営計画で掲げたDXによる価値創出の実現に向けて着実に前進していきます。 まとめ 本稿では、レンゴーがデータ活用を全社的に拡大するために取り組んだ包括的なアプローチについてご紹介しました。データ駆動組織を作るためには、「ソフトスキル」「ハードスキル」「ツール」という３つの要素全てを同時に、そして継続的に推し進めることが必要です。この認識のもと、私たちはAWSとパートナー企業であるJSOLの協力を得て、三つの観点を網羅する包括的な研修プログラムを構築しました。私たちの取り組みはまだ始まったばかりですが、すでに具体的な成果が表れ始めています。この経験が、同様の課題に直面している他の企業の皆様にとって、データドリブン経営への道筋を考える一助となれば幸いです。 図 7 社内広報（表紙） 著者について レンゴー株式会社 情報システム本部 情報システム第一部 課長代理　平田　匡人（Tadahito Hirata） SIer、事業会社にてシステム企画構想から運用保守まで約15年従事。特にアフターサービス分野、グローバルシステム構築に強みを持つ。現在は、段ボール・紙器・軟包装事業の基幹システム運用保守とDX案件に従事。データ分析分野においては、データ分析人材育成のプロジェクトリーダーとして推進している。

映画スタジオのように、膨大な量のビデオファイル、スクリプト、アニメーションアセットを扱う会社を想像してみてください。これらのファイルは Amazon FSx for Lustre などの高性能ファイルシステムに格納されます。Amazon FSx for Lustre は、世界で最も普及している高性能ファイルシステム上に構築された完全マネージド型の共有ストレージです。各ファイルには POSIX 情報などのメタデータがあります。スタジオのプロジェクトが増えるにつれて、ファイルやディレクトリの数も増えます。ファイルの検索や、ファイルへのアクセス、ディレクトリ内の一覧表示を実施する必要がある場合、システムはこのメタデータをすばやく取得して管理する必要があります。しかしながら、従来のファイルシステムでは、ファイル数が特に数百万または数十億に増加すると、メタデータ操作が大幅に遅くなる可能性があります。この速度低下がボトルネックとなり、ファイルの取得が遅れ、チームの生産性が低下する可能性があります。これは、厳しい締め切りの中で作業する場合に非常に重要です。 FSx for Lustre は、CPU と GPU を最大容量で使用し続け、TB/秒のスループットと数百万 IOPS に達する高速ストレージを必要とするアプリケーション向けに設計されています。何千ものコンピューティングインスタンスから同じファイルやディレクトリへ同時アクセスをサポートしながら、ファイル操作において一貫性のあるミリ秒未満のレイテンシーを提供することは、多くのワークロードを実現に結びつきます。FSx for Lustre は、 図 1 に示すようにオブジェクトストレージサーバ (OSS) を使用して複数のノードにファイルを分散します。そのため、ストレージ容量とスループットのバランスをとるために、各読み取りまたは書き込み操作はクラスター全体で並列化されます。FSx for Lustre は専用のメタデータサーバ (MDS) を使用してメタデータ操作をサポートします。 図 1. スケーラブルなメタデータ機能以前の FSx for Lustre 構成図 ファイルシステムのメタデータパフォーマンスは、ファイルシステムが 1 秒あたりに作成、一覧表示、読み取り、削除できるファイルやディレクトリの数を決定します。メタデータを集中的に使用するワークロードでは、多数の小さなファイルの作成、処理、操作が必要となることが多くあります。FSx for Lustre は、プロビジョニングされたストレージ容量に基づいて、デフォルトのメタデータパフォーマンスレベルを自動的に提供します。スケーラブルなメタデータ機能がリリースされる以前は、デフォルトよりも多くのメタデータ操作を必要とするユーザーは、より大きなファイルシステムを作成するか、データを複数のファイルシステムに分割する必要がありました。スケール可能なメタデータのリリースにより、ユーザーはプロビジョニングされたストレージとは独立して、利用可能なメタデータ IOPS を最大 15 倍まで増やすことができるようになりました。これにより、最もメタデータを集中的に使用するワークロードでも利用が可能になります。さらに、この機能は 図 2 に示すように、ファイルシステムの作成時に有効にすることも、ファイルシステムの作成後に有効にすることも可能で、特定のファイルシステムに対してメタデータ操作専用の IOPS の量を増やすことができます。 図 2. スケーラブルなメタデータ機能を備えた&nbsp;FSx for Lustre 構成図 ワークロードやユースケース この新機能により、データ管理が合理化され、機械学習（ML）、電子設計自動化（EDA）、財務分析リスクシミュレーションなど、メタデータを多用するワークロードを必要とするユースケースの効率が向上します。EDA における基礎設計や、研究者がプロジェクト作成中にデータセットの名前を変更するといった作業負荷は、メタデータを多用する性質上、ファイルシステムに大きな負荷をかけます。 MDTest を使用してこれらの操作の上限をテストできます。 メタデータパフォーマンス 特定のワークロードに FSx for Lustre ファイルシステムを導入するには、パフォーマンスを最適化する上でメタデータ IOPS がどのように重要な役割を果たすかを理解する必要があります。 図 3a に示すように、自動モードの FSx for Lustre はファイルシステムのストレージ容量に基づいてメタデータ IOPS を自動的に割り当てるため、プロセスが簡素化されます。このアプローチでは、IOPS の数とストレージのサイズが相関関係にあるため、手動で調整しなくても大半のワークロードで適切なレベルのパフォーマンスが得られます。たとえば、1,200 GiB のストレージを備えたファイルシステムは自動的に 1,500 のメタデータ IOPS を受け取りますが、大規模なシステムでは 12,000 GiB を超える容量の場合、最大 12,000 メタデータ IOPS にスケールアップします。 一方、 ユーザープロビジョニングモード では、よりきめ細かい制御が可能です。ストレージ容量に関係なく、必要なメタデータ IOPS の正確な値を手動で指定できます。このモードは、自動モードでは対応しきれないメタデータ IOPS を要するワークロードに適しています。 図 3a. ファイルシステムのメタデータパフォーマンス FSx for Lustre は、 図 3b に示すように、ファイルの作成、削除、ディレクトリ操作などにメタデータ操作を分類し、それぞれ 1 秒あたりの処理レートが異なります。これは、数百万にも及ぶファイルシステムの IOPS とは異なります。たとえば、ファイル削除の操作はプロビジョニングされた IOPS ごとの 1 秒あたりの処理レートが 1 であるのに対し、ファイル作成やファイルを開く操作は 1 秒あたりの処理レートが 2 となります。プロビジョニングされた IOPS の値を、ワークロードが必要とする特定の種類の操作に合わせれば、FSx for Lustre はメタデータを効率的に処理できるようになります。この最適化は、ファイルシステム全体のパフォーマンスを向上させるだけでなく、ストレージや運用上のニーズの拡大に応じたスケーラビリティもサポートします。 図 3b. ファイルシステムのメタデータパフォーマンス 前提条件 この操作手順では、次の前提条件を満たす必要があります。 AWS アカウント FSx for Lustre ファイルシステムの作成および変更 Slurm を利用した既存の AWS ParallelCluster の使用 AWS ParallelCluster での Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの作成 Lustre クライアントのチューニングに関する理解 Linux コマンドラインの実践的な知識 Amazon CloudWatch ダッシュボードの作成 メタデータパフォーマンスの設定方法 新しい FSx for Lustre ファイルシステムを作成する場合、 図 4a に示すように、メタデータパフォーマンスを自動モードとして定義する新しいオプションがあります。この場合、IOPS はファイルシステムの容量 (24 TiB のストレージあたり 12,000 メタデータ IOPS) に基づいて自動的に定義されます。または、 図 4b に示すように、ユーザープロビジョニングモードとして定義することもできます。この場合、ユーザーはメタデータ IOPS の値に 1,500、3,000、6,000、あるいは 192,000 メタデータ IOPS までの 12,000 の倍数を指定できます。ユーザーは、 AWS マネジメントコンソール 、 AWS Command Line Interface (AWS CLI), 、または AWS Software Development Kits (SDKs) を使用して、メタデータパフォーマンスを向上させる機能を持った FSx for Lustre ファイルシステムを作成できます。 図 4a. メタデータ設定の自動モード 図 4b. メタデータ設定のユーザープロビジョニングモード テストの実行 このセクションの目標は、さまざまなワークロードシナリオにおける標準のメタデータ設定とスケールされたメタデータ設定のメタデータパフォーマンスを比較することです。また、これらのテストをお客様の AWS アカウントで再現する手順についても説明します。 図 5 は、コンソールで作成されたファイルシステムの例を示しています。この特定のファイルシステムは 12 TiB のストレージで構成されており、1,500 MB/秒のスループット (125 MB/秒) と 192,000 のメタデータ IOPS を実現しています。この構成は、スループット要件は低くメタデータ操作が集中するアプリケーション向けに調整されています。 図 5. 192,000 メタデータ IOPS で作成されたファイルシステム このテストシナリオでは、2 組の大規模ファイルシステムを作成しました。いずれも P250 と P1000 のスループット構成で、一方はスケールされたメタデータを持たないサイズが 12 TiB のファイルシステム、もう一方は 192,000 IOPS のスケールされたメタデータを持つサイズが 12 TiB のファイルシステムです。 AWS ParallelCluster を使用して、この HPC ベンチマークを実行するためのクラスターを構築しました。以下の設定の c5.9xlarge インスタンスタイプのクライアント EC2 インスタンスが 200 個あります。 Instance type: c5.9xlarge Operating Systems: Amazon Linux 2 Linux Kernel: 5.10.219-208.866.amzn2.x86_64 mpi version: Open MPI 4.1.6 lustre version: 2.12.8_198_gde6dd89_dirty ENA driver: 2.12.0g Ranks for job: 800 ParallelCluster: 3.10.1 Lustre クライアント側のパラメータ sudo lctl set_param osc.*OST*.max_rpcs_in_flight=32 sudo lctl set_param mdc.*.max_rpcs_in_flight=64 sudo lctl set_param mdc.*.max_mod_rpcs_in_flight=50 sudo lctl set_param osc.*.max_dirty_mb=64 Lustre パフォーマンス設定の詳細については、 FSx for Lustre パフォーマンスガイド とオンラインの Lustre ドキュメント を詳しく調べてください。 テストツールとして、このシナリオではオープンソースの MDTest を使用してメタデータの I/O シミュレーションを行います。 MDTest のインストールと実行 次のコマンドは、OpenMPI ライブラリとコンパイラを使用してユーザーの PATH と LD_LIBRARY_PATH で実行しました。 $ git clone https://github.com/hpc/ior.git $ cd ior $ ./bootstrap $ ./configure --prefix=/opt/parallelcluster/shared $ make all $ make install この時点で、トラブルシューティングを行ったり、テストを積極的に監視したりしたい場合に備えて、MDTest を起動するためのインタラクティブジョブを実行しています。 $ srun --nodes=200 --ntasks-per-node=32 --time=12:00:00 --pty bash -i EC2 インスタンスが利用可能になった時点で、そのテストを実施するために、自分の UID がフルアクセス権限を持つサブディレクトリを作成しました。 (例) $ sudo mkdir -p /fsx/mdTestFiles $ chown 1000:1000 /fsx/mdTestFiles 次に、ジョブを実行します。このジョブは 3 回繰り返され、ワークロードの平均を確認できます。 $ mpirun --mca plm_rsh_num_concurrent 800 --mca routed_radix 800 --mca routed direct --map-by node --mca btl_tcp_if_include eth0 -np 800 /opt/parallelcluster/shared/bin/mdtest -F -v -n 4000 -i 3 -u -d /fsx/mdtestFiles MDTest オプションの説明 : -F: ファイルのみでテストを実行 (ディレクトリを含まない) -v: 詳細出力 -n 4000: ランクごとに create/stat/read/remove を行うディレクトリやファイルの数 -i 3: テストを実行する反復回数 -u: 各ランクに固有の作業ディレクトリ -d: ジョブのルートディレクトリ 図 6 は単一メタデータターゲット (MDT) を持つ 12 TiB のファイルシステムで実行された最初のジョブの出力例を示しています。 図 6. MDTest 実行時の出力例 このセクションでは、先の図における単一メタデータターゲット (MDT) 12 TiB の FSx for Lustre ファイルシステムの最初のテストで確認されたことを詳しく説明します。ファイル作成 (create) は、1 つのプロセスイベントで 1 ファイルずつ作成されます。これは小さな書き込みワークロードと解釈できます。統計 (stat) の観点から見ると、これは Lustre にとってコストのかかる操作になる可能性があり、ツリーウォークや大規模な “ls -l” がどのように動作するかを表しています。ファイルの読み取り (read) は読み取りワークロードであり、ファイルの削除 (remove) はファイルシステムからファイルを完全に消去することです。メタデータサーバへの負荷は、イベントごとに異なります。 図 7 はクライアントの数とキャパシティを同じ条件に保ちながら、異なるファイルシステムタイプで実施した複数回の実行結果を包括的にまとめた表になります。 図 7. MDTest の結果 上の表は、それぞれメタデータ IOPS が 12,000 と 192,000 のファイルシステムのパフォーマンスの違いを示しています。パフォーマンスの違いは操作タイプに関連しており、メタデータ IOPS が高いほどすべてのテストで改善が見られます。ワークロードの要件によって FSx for Lustre のメタデータ IOPS を高める明確な方法があります。 ファイルシステムのメタデータメトリクスの監視 ファイルシステムの稼働時には、CloudWatch メトリクスを使用してメタデータのパフォーマンスを監視し、増加するワークロード要件に対応するため、必要に応じてパフォーマンスをスケールアップすることができます。FSx for Lustre の監視は、システムの安定性を維持し、発生する可能性のある問題に迅速に対処するために不可欠です。CloudWatch は監視の中心的なツールとして機能し、FSx for Lustre からリアルタイムのメトリクスを継続的に収集して処理します。CloudWatch アラームを設定すると、異常時やパフォーマンスのしきい値に超えたときに、管理者は Amazon Simple Notification Service (Amazon SNS) を通じて即座に通知を受け取ることができ、潜在的な問題を軽減するための対応が可能になります。 FSx for Lustre は、デフォルトで 1 分間隔でメトリクスデータを CloudWatch に自動的に送信し、これらのメトリクスは raw バイトで報告されます。CloudWatch とその機能の詳細については、 CloudWatch ユーザーガイド を参照してください。 FSx for Lustre は、そのメトリクスを CloudWatch の FSx 名前空間に発行します。新しいスケーラブルメタデータ機能により、 図 8a、8b、8c に示すような 新しいメトリクス を利用して、メタデータ操作の詳細を確認できるようになりました。新しいメトリクスには DiskReadOperations や DiskWriteOperations 、 FileCreateOperations 、 FileOpenOperations 、 FileDeleteOperations 、 StatOperations 、 RenameOperations があります。これらのメトリクスからより詳細なデータが利用可能になるため、 FileSystemID (特定のファイルシステム用) と StorageTargetID (特定の MDT – メタデータターゲット用) を使用してデータを絞り込むことができます。 図 8a. CloudWatch ダッシュボードにおける新しいメタデータメトリクス 図 8b. CloudWatch ダッシュボードにおける新しいメタデータメトリクス 図 8c. CloudWatch ダッシュボードにおける新しいメタデータメトリクス FSx for Lustre のスケーラブルなメタデータ用の AWS CloudFormation テンプレートをダウンロードするにはこちらを利用してください : 料金 このソリューションを試す場合、費用が発生します。このソリューションでは EC2 インスタンス、FSx for Lustre ファイルシステム、および CloudWatch ダッシュボードを実行しています。 料金の詳細は、 FSx for Lustre 、 EC2 インスタンス 、および CloudWatch の料金ページで確認できます。 クリーンアップ 今後の確認に備えて、必要なすべてのパフォーマンスの実行をバックアップします。 FSx for Lustre ファイルシステムと関連するコンピューターリソースを削除して、そのプロジェクトの課金を終了してください。CloudFormation ページよりダッシュボードを削除して、アカウントから削除してください。 必要に応じて ParallelCluster を管理してください。コストを節約するために、不要になったら削除してください。 まとめ この新機能の影響は広範囲に及び、特に要求の厳しい AI/ML や HPC ワークロードを実行している組織にとって重要です。これらのワークロードでは、多くの場合、膨大な数の小さなファイルの作成、処理、操作が行われ、メタデータパフォーマンスに大きな負荷がかかります。Amazon FSx for Lustre ではメタデータパフォーマンスをスケールすることで、ユーザーはワークロードを 1 つのファイルシステムに統合できます。これは、ワークロードを分割せずにワークロードをより大規模に実行すること、メタデータパフォーマンスを容易に向上させ変化するパフォーマンス要件に適応すること、メタデータパフォーマンスをストレージ容量から切り離してリソースの使用を最適化することで実現されます。 このブログは 2025 年 2 月 21 日に Tom McDonald (Senior Workload Storage Specialist) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 この記事を読んでいただきありがとうございました。 翻訳はクラウドサポートエンジニアの奥野が担当しました。 <!-- '"` --> TAGS: Amazon FSx for Lustre , AWS Cloud Storage , High-Performance Computing (HPC) , machine learning Tom McDonald Tom McDonald は AWS の Senior Workload Storage Specialist です。Atari 400 やテープの再プログラミングから始まり、Tom はあらゆるストレージサービスのパフォーマンス向上に長年関心を持ち続けてきました。資源開発分野でファイルシステムや高性能コンピューティングの 20 年以上の経験を持つ Tom は、コミュニティやガイダンスを通して多くの方を支援することに情熱を持っています。

AWS の生成 AI コスト最適化に関する全 5 回構成 シリーズ の 4 回目のブログでは、前回までの議論を踏まえて AWS の生成 AI を活用したアシスタントである Amazon Q の価値を最大化することに焦点を当てます。以前の記事では、 Amazon EC2 と SageMaker AI による AI モデル構築のコスト最適化 と Amazon Bedrock で基盤モデルを使用する際のコスト最適化 について説明しましたが、今回は Amazon Q を利用する際のコスト最適化戦略を探ります。適切な料金プランの選択、戦略的ユーザー管理の実装から、コンテンツのインデックス作成の最適化やコスト予測可能性の向上まで、機能性とコスト効率のバランスを取るのに役立つ実践的なアプローチを紹介します。生成 AI を活用したアシスタントとして Amazon Q Business を使用する場合でも、開発者の生産性を高めるために Amazon Q Developer を使用する場合でも、これらのベストプラクティスは、Q の利用について情報に基づいた意思決定を行うのに役立ちます。 Amazon Q を理解する: Business と Developer Amazon Q Business は、情報の検索、コンテンツの生成、およびタスクの自動化を支援するように設計された AI 搭載アシスタントです。利点として、迅速な対応による生産性の向上、コンテキストを踏まえた回答、安全なデータアクセスによる意思決定の強化やビジネスツールとのシームレスな統合などがあります。生成 AI のニーズに応えて Amazon Q Business を採用するケースが増えるにつれ、投資収益率（ROI）を最大化するには、コスト最適化戦略を理解することが重要になります。 Amazon Q Developer は、リアルタイムのコード提案システムと自動タスク実行を通じてソフトウェア開発を促進し、生産性の向上と開発期間の短縮を実現しています。このツールにより、開発ライフサイクル全体にわたる迅速なオンボーディング、コード品質の向上やセキュリティ統合が可能になります。Amazon Q Developer は、あらゆる規模のビジネスに対応できるようにユーザー単位の価格を設定しており、JetBrains、VS Code、Visual Studio や Eclipse などの IDE と統合できます。Amazon Q Developer について言えば、先日、私たちはコスト最適化の機会を見つけるのに役立つ魅力的な新しいコスト最適化推奨機能を発表しました。この機能は、自然言語での会話を通じ、インスタンスのライトサイジング、Savings Plans やリザーブドインスタンスの購入やアイドル状態のリソースの終了などのコスト最適化の機会を見つけるのに役立ちます。これは、コードの作成中にリソースの使用を最適化し、コストを最適化するための効率的な方法となります。 図 1. Amazon Q によるコスト最適化分析 それでは、メイントピックである Amazon Q のコストを最適化するための実践的なヒントに戻りましょう。 料金プランの選択 始めに決めることは、適切な料金プランを選択することです。Amazon Q Business には、Amazon Q Business Lite と Amazon Q Business Pro の 2 つの料金プランがあります。 Amazon Q Business の料金 をご覧ください。ビジネス要件に合わせてプランを慎重に選択することで、最大 85% のコスト削減を実現できます。Amazon Q Business Lite の料金は、ユーザー 1 人につき 1 か月あたり $3 です。安全なデータアクセスや権限に応じた応答などの基本機能を提供します。応答の最大サイズは 1 ページまでとなります。（訳注：1 ページのサイズは ドキュメント 参照）Amazon Q Business Pro は、ユーザー 1 人につき 1 か月あたり $20 です。すべての Amazon Q Business Lite 機能に加えて、Amazon Q Apps、コンテンツ作成ツールや最大 7 ページの長い応答が含まれます。Amazon Q Business Pro のユーザーは、Q in QuickSight (Reader Pro) を使用して構造化データに関するインサイトを得たり、一般的なサードパーティアプリ用のカスタムプラグインやマネージドプラグインを使用したり、画像ベースの応答を受け取ったりすることもできます。 Amazon Q Business 料金プランの変更 Amazon Q Developer にも、Amazon Q Developer 無料利用枠と Amazon Q Developer Pro の 2 つの料金プランがあります。 Amazon Q Developer の料金 をご覧ください。無料利用枠では、Amazon Q Developer を簡単に使い始めることができます。無料利用枠には、コードの提案、CLI の補完、CLI の統合がありますが、 高度な機能への 1 ヶ月あたりのアクセスが制限されています。Amazon Q Developer Pro は 1 か月あたり $19 で、無料利用枠のすべての機能に加えて、エンタープライズアクセス制御、コードベースのカスタマイズやクエリ作成、コード変換などの高度な機能に対する制限の緩和が含まれます。 料金プランの決定は、より高い料金プランを無条件で選択するのではなく、ユースケースとユーザーニーズを分析して決定する必要があります。これにより、ユーザーが実際に利用する機能に見合った料金プランとなるためコスト効率を維持できます。 戦略的ユーザー管理 Amazon Q Business と Amazon Q Developer のユーザーアクセスを管理することは、コストの最適化と業務の効率化にとって非常に重要です。これは、サービスの料金がユーザーごとに設定されているためです。厳格なユーザー管理手法を導入することで、その機能を本当に必要とするユーザーだけがアクセスできるようにし、非アクティブなユーザーやたまにしか使用しないユーザーによる不必要なライセンスコストを防ぐことができます。ユーザーアカウントを定期的に監査し、離職したユーザーのアクセス権を削除し、使用パターンが最小限であるユーザーにはライセンスの必要性を再評価する必要があります。さらに、ユーザーを役割とニーズに基づいて適切な権限階層とグループに分割することで、データアクセスをより適切に制御し、セキュリティコンプライアンスを維持し、リソースの浪費を防ぐことができます。ユーザー管理に対するこの戦略的なアプローチは、ユーザーのコストを削減するだけでなく、サービスの使用状況をより適切に監視するのにも役立ちます。 コンテンツインデックスの最適化 Amazon Q Business は、データソースの接続による検索拡張生成（RAG）をサポートしています。 Amazon Q Business データソースの接続 を参照してください。インデックス作成プロセスは単位時間ごとの料金設定で、1 つのアベイラビリティーゾーンのスターターインデックスを作成するか、3 つのアベイラビリティーゾーンにまたがってエンタープライズインデックスを作成できます。インデックス作成の時間と頻度を最小限に抑えることは、インデックス作成コストにプラスの影響を与えます。インデックス費用の例については、 Amazon Q Business の料金ページ の「価格設定の例」セクションの例 3 から 5 を参照してください。インデックス作成コストを管理するうえで重要な 2 つの手段は、「同期モード」と「同期実行スケジュール」です。 同期モードには 2 つのオプションがあります。「Full sync」 を選択すると、Amazon Q は以前の同期ステータスに関係なく、すべてのコンテンツを同期してインデックスを作成します。「New, modified, or deleted content sync」を選択すると、Amazon Q は新規、変更、削除されたコンテンツのみを同期します。データを段階的に追加または変更する場合は、コストを最小限に抑えるために 「New, modified, or deleted content sync」 を選択する必要があります。データソースに大きな変更を加える必要がある場合は、「Full sync」 を選択して同期を 1 回実行するとよいでしょう。その後、「New, modified, or deleted content sync」に戻す必要があります。 「「Sync run schedule」では、インデックス作成の頻度を設定できます。選択できる項目は、時間単位、日単位、週単位、月単位、またはカスタム（cron 式）です。接続されているデータソースが更新される頻度と、ソリューションに必要なデータのインデックス作成頻度に基づいて、インデックス作成頻度を最適化する必要があります。この設定の実行頻度が高すぎると、予期しないコストが発生する可能性があります。 結論 Amazon Q Business と Amazon Q Developer の最大の利点の 1 つは、予測可能なコスト構造です。コアビジネスの目標に焦点を当てながら、経費を正確に予測できます。この予測可能性とフルマネージド型のサービスを組み合わせることで、インフラストラクチャの管理を気にすることなく価値の提供に集中できます。 ここまで、料金プランの選択、ユーザー管理やコンテンツインデックスの最適化を通じて、Amazon Q Business と Amazon Q Developer のコストを最適化するための主な要素について説明してきました。次回のブログでは、AI ソリューションと連動するサービス (ストレージ、ベクトルデータベース、データ転送やレポート) のコスト最適化戦略について説明します。費用対効果が高くスケーラブルな AI アプリケーションを構築するための重要なインサイトをお見逃しなく。 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Adam Richter Adam Richter は、AWS OPTICS のシニア最適化ソリューションアーキテクトです。この役職では、Adam は AI コスト最適化と FinOps プラクティスを専門としています。Amazon Q Business や Amazon Q Developer などの顧客向け機能に貢献したほか、AWS re:Invent やその他の業界プラットフォームでの講演を通じてオピニオンリーダーとしての役割を果たしてきました。 Bowen Wang Bowen は AWS 請求およびコスト管理サービスのプリンシパルプロダクトマーケティングマネージャーです。彼女は、財務およびビジネスリーダーがクラウドの価値とクラウドファイナンス管理を最適化する方法をよりよく理解できるようにすることに重点を置いています。以前のキャリアでは、テック系スタートアップの中国市場への参入を支援しました。

コンタクトセンターにおける予期せぬサービス中断は、深刻な影響を及ぼす可能性があります。エージェントがシステムにアクセスできない、顧客が接続の問題に直面する、そしてサポートチームがサービスの迅速な復旧に追われることになります。このようなシナリオは極端に思えるかもしれませんが、現代のコンタクトセンター運営においては、このような状況に対する机上演習が不可欠です。 このブログ記事では、Amazon Web Services (AWS) が提供する AI を活用したクラウドコンタクトセンターソリューション、 Amazon Connect 向けのいくつかの机上演習を紹介します。これらは、コンタクトセンターの移行に際しての様々なシナリオの確認や、予期せぬ事態に備えたプロセスと手順の更新に役立つはずです。 机上演習とは 机上演習は、企業規模を問わず重要な取り組みです。机上演習は、サイバー攻撃、自然災害、システム障害などの危機に対する対応計画をテストでき、体系的に管理された環境を構築するのに役立ちます。演習では、企業のシニアエグゼクティブ、部門長、危機管理チームなどの主要な利害関係者が参加し、戦略的な議論と意思決定プロセスに関わることが必要です。潜在的な脅威や混乱に対処する訓練を通して、企業は緊急時対応手順の不足やずれを特定し、コミュニケーションや連携を改善、実際の事態が発生した際の各チームの役割をしっかりと理解することができます。 また、机上演習は組織のリスク管理戦略を改善し、組織のレジリエンスを高め、予期せぬ課題に直面した際に、自信をもって迅速かつ効果的に対応する能力を構築し、最終的には企業の業務継続と評判を保護することに役立ちます。 1) Amazon Connect サービスの中断 シナリオ : Amazon Connect で一時的なサービス停止が発生し、特定のリージョンでコンタクトセンターでの通話の発信や受信ができなくなりました。顧客がサポートエージェントに連絡できず、エージェントも通話を処理するためのシステムにアクセスできません。 主な方針 : 事象が自身の Amazon Connect インスタンスに限定されているのか、複数のリージョンに影響しているのかを確認します AWS PHD でサービスの問題を確認します CloudWatch メトリクス を使用して、潜在的な原因（接続性の問題、API 制限など）を調査します エンドユーザーとステークホルダーに対して、停止の状況と復旧予想時間を通知する方法を決定します 代替システムへの通話の転送や、異なるリージョンの使用など、回避策を実施します 2) 品質低下または遅延発生 シナリオ : 顧客通話の一部で高い遅延と音声品質の低下が発生し、顧客体験の悪化につながっています。この問題は、特定の地域のエージェントと顧客との間の通話に影響を与えているようです。 主な方針 : Amazon Connect の音声メトリクスと Amazon CloudWatch を使用してネットワークパフォーマンスを調査します SIP トランキングや電話統合など、関係する第三者システムの状態を確認します 問題が地域のインフラまたはネットワーク輻輳に関連しているかを特定します Amazon Connect Voice Analytics ツールや CloudWatch Logs などの診断ツールを使用して音声品質をテストします AWS サポートに連絡する際、サポートのトラブルシューティングに役立つよう、 HAR ファイル/コンソールログを準備します(参照: https://repost.aws/ja/knowledge-center/support-case-browser-har-file ) 3) コンタクトフローの設定ミス シナリオ : 新しく更新されたコンタクトフローにより、顧客が正しい部署にルーティングされない状況が発生しています。意図したエージェントにつながらず、顧客との接続が切断されたり、誤ったキューに転送されたりしています。 主な方針 : CloudWatch メトリクス で「ContactFlowErrors」と「ContactFlowFatalErrors」を確認します 影響を受けたコンタクトを特定し、 CloudWatch のコンタクトフローログでエラーに関する詳細情報を確認します コンタクトフローを確認し、設定ミス（不適切な条件、誤ったキューへのルーティングなど）を特定します 設定変更が問題の原因である場合、機能を復旧するためのロールバック計画またはホットフィックスを実施します 変更後にコンタクトフローをテストし、問題が解決されたことを確認します チームとエンドユーザーに変更内容を文書化して伝達します 4) Amazon Connect インスタンスの動作が遅い シナリオ : Amazon Connect インスタンスにおいて、エージェントのログインにかかる時間、コールのルーティング、管理ダッシュボードのパフォーマンスに遅延が発生しています。これは顧客とエージェントの両方の体験に影響を与えています。 主な方針 : Amazon CloudWatch を使用してシステムのパフォーマンスとリソース使用状況を監視します 同時使用のスパイクや Amazon Connect のサービス制限を確認します 問題が高トラフィック量または設定エラーに関連しているかを特定します 関連リソースのスケールアップや使用パターンの調整など、是正措置を講じます 5) AWS Lambda 関数のタイムアウト シナリオ : カスタム統合（例：データベースからの顧客データの取得）に使用される Lambda 関数がタイムアウトし、通話処理に遅延を引き起こし、その結果、通話の切断や情報取得の遅延が発生しています。 主な方針 : Lambda 関数 のログを確認し、タイムアウトが発生している理由（例：遅いデータベースクエリ、関数のロジックエラー）を特定します Amazon Connect の外部で Lambda 関数を手動でテストし、パフォーマンスの問題を確認します Lambda のタイムアウト設定を変更し、関数のコードを調整してパフォーマンスを改善します Lambda 関数が AWS サービスの制限に達していないか、リソースの制約に抵触していないかを調査します 6) CRM (Customer Relationship Management) 統合の問題 ( 例：Salesforce、ServiceNow) シナリオ : Amazon Connect から発信された通話で、CRM への顧客データの取り込みが失敗し、エージェントが顧客対応時に必要な情報にアクセスできない状況が発生しています。 主な方針 : Amazon Connect と CRM システム間の API 統合が機能しているか調査する CRM または Amazon Connect の統合に関する最近のアップデートや変更で問題の原因となった可能性があるものを確認する 両システム間の認証と承認の設定（API キー、IAM ロールなど）を確認する Amazon Connect と CRM 間の接続を手動でテストし、エラーがないかログを確認する 7) ルーティングプロファイルの設定ミス シナリオ : エージェントが誤ったルーティングプロファイルに割り当てられており、その結果、間違ったキューからの通話を受信したり、まったく通話を受信できない状態になっています。 主な方針 : ルーティングプロファイル を確認し、正しいエージェントに割り当てられていることを確認します キューに配置されるメンバーとスキルが適切に設定され、通話が適切にルーティングされるようにします 異なるエージェントでルーティングロジックをテストし、通話が正しくルーティングされることを確認します 設定の不一致を調整し、システムの改善状況を監視します 8) 高い通話放棄率 シナリオ : コンタクトセンターで異常に高い通話放棄率が発生しています。顧客がエージェントに到達する前に、またはキュー待機中に電話を切ってしまっています。 主な方針 : Amazon Connect のメトリクスを使用してキューの長さと待ち時間をモニタリングし、許容範囲を超えていないか確認します コンタクトフローの設定を確認し、推定待ち時間が顧客に明確に伝えられているか検証します エージェントの稼働状況にボトルネックがないか、またはシステムが過負荷になっていないか確認します 待ち時間を短縮し、より正確な待ち時間予測を提供するために IVR やルーティング戦略を調整します 9) エージェントの認証失敗 シナリオ : エージェントが Amazon Connect インスタンスにログインできない状態です。アイデンティティプロバイダー（例：AWS IAM Identity Center 、Active Directory）の設定ミスが原因と考えられる認証エラーが発生しています。 主な方針 : Amazon Connect とアイデンティティプロバイダーの連携が有効な状態を維持しているか確認します エージェントのログインに影響を与える可能性のある IAM ロール 、ポリシー、またはセキュリティ設定の最近の変更を確認します 認証やアクセス許可のエラーについて CloudWatch Logs を確認します 問題がアカウント固有のものかシステム全体に及ぶものかを切り分けるため、異なるアカウントでエージェントのログインをテストします 10) 顧客データの不整合 シナリオ : Amazon Connect または統合されたシステム (AWS Lambda、Amazon DynamoDB など)に保存されている顧客データが、顧客とのやり取りの中で一貫性を持っていません。例えば、以前のケースメモや顧客の設定が次の通話でエージェントに表示されないなどの問題が発生しています。 主な方針 : データ統合のプロセス(Lambda、DynamoDB、Salesforce など)が正しく機能していることを確認します 通話中にリアルタイムで顧客データが正しく取得、保存、更新されていることを確認します 不整合の原因となる可能性のあるデータ同期の問題を調査します エージェントのデータ取得の一貫性を確保するための修正を実装し、将来のデータの不一致に備えてログ記録とエラー処理を見直します 11) マルチチャネル体験の品質低下 シナリオ : 顧客のマルチチャネル体験（音声、チャット、メール）が低下し、顧客が異なるチャネル間で一貫性のない対応を受けています。 主な方針 : Amazon Connect と他のチャネルとの統合を確認します 各チャネルのコンタクトフローが正しく設定されており、顧客データがチャネル間で共有されていることを確認します（例：音声からチャットへ、またはその逆にコンテキストを受け渡せているか） すべてのチャネルの CloudWatch メトリクスを監視し、特定のチャネルのパフォーマンスが低下していないか確認します 各チャネル（音声、チャット、メール）を個別にテストし、品質低下の性質を確認します チャネル間のエスカレーションオプション（例：チャットから音声通話への転送）を実装し、顧客のコンテキストがチャネル間で保持されることを確認します まとめ このブログ記事では、Amazon Connect の 11 種類の多様な机上演習シナリオを紹介し、コンタクトセンター環境で発生する可能性のある一般的な問題のトラブルシューティングと解決に向けた包括的なアプローチを紹介しました。それぞれの課題に対処するための詳細な手順を確認することで、みなさまが Amazon Connect の機能を効果的に管理するための貴重な知見を得られることを願っています。 これらの演習は問題解決技術を強化するだけでなく、安定的な運用を維持するための事前計画、テスト、継続的なモニタリングの重要性も示しています。コンタクトセンターのマネージャーであれ、技術専門家であれ、これらのシナリオを練習することで、実際の問題に自信を持って効率的に取り組むために必要なレジリエンスと専門知識を身につけることができます。 そして、継続的にこのような演習を通じて改善することで、Amazon Connect 環境の堅牢性を維持し、優れた顧客体験の提供を保つことができます。 Renato Gentil Renato は、アイルランドを拠点とする AWS での 7 年以上の経験を持つシニアテクニカルアカウントマネージャーです。4 つの AWS 認定資格を保有しており、世界中のさまざまな顧客と大規模なレジリエンスプロジェクトに取り組み、机上演習やインシデント管理プロセスを通じてレジリエンスの改善を支援しています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

数万人の顧客が Amazon DynamoDB の グローバルテーブル を最終的整合性で正常に使用していますが、さらに強力なレジリエンスに対する新たなニーズが出てきています。多くの組織は、DynamoDB の複数アベイラビリティゾーンアーキテクチャと最終的整合性のグローバルテーブルが要件を満たすことを見出していますが、決済処理システムや金融サービスのような重要なアプリケーションには、さらに高い要求があります。 これらのアプリケーションでは、顧客は稀なリージョン全体のイベント時にゼロ目標復旧時点 (RPO) を要求します。つまり、アプリケーションが任意のリージョンから最新のデータを読み取れるようにする必要があります。マルチリージョンアプリケーションは、場所に関係なく常に同じデータにアクセスする必要があります。 6 月 30 日より、Amazon DynamoDB グローバルテーブルの新機能として、マルチリージョン強整合性 (MRSC) がご利用いただけるようになりました。これにより、ゼロ RPO (目標復旧時点) を実現できます。この機能は、 2024 年の AWS re:Invent でプレビュー として初めて発表され、グローバル規模で高い耐障害性を備えたアプリケーションの構築を簡素化します。 以下は、既存の空の DynamoDB テーブルから MRSC を有効にする方法です。 次の手順で、既存の空の DynamoDB テーブルに対して MRSC を有効にできます。あるリージョンでアプリケーションの処理が中断された場合でも、MRSC レプリカを保持する別のリージョンにトラフィックをリダイレクトすることで、最新のデータを用いて処理を継続できることが保証されます。 はじめに この新しい機能の使い方を順を追ってご説明します。 MRSC を利用開始するには、データが含まれていない既存の DynamoDB テーブルからグローバルテーブルを作成する必要があります。既存のテーブルに移動し、 グローバルテーブルタブ を選択して、 レプリカの作成 を選択します。 MRSC の可用性アーキテクチャでは、3 つの AWS リージョンが必要です。MRSC は、3 つのフルレプリカを構成することも、2 つのレプリカとウィットネスで構成することもできます。ウィットネスには、必要な可用性を確保するための変更データのみが複製され、テーブルデータ全体のコピーは保持されません。 次のスクリーンショットは、2 つのレプリカとウィットネスで MRSC を構成する方法を示しています。代わりに 3 つのフルレプリカで MRSC を構成するには、 リージョン 2 をウィットネスとして構成する のチェックを外すことで設定できます。 既存のテーブルをプログラムで更新する必要がある場合は、次のプロンプトを使用して、必要なコマンドを生成するために Amazon Q CLI を利用できます。 &gt; ねえ Q! us-east-1 リージョンの 「demo-mrsc」という DynamoDB テーブル を、us-east-2 リージョンにまたがるマルチリージョン強整合性 (MRSC) 対応に更新し、us-west-2 リージョンにウィットネスを構成します その後すぐに、Q CLI は次のコマンドを返してきます。 &gt; マルチリージョン強整合性を有効にするには、適切なパラメータを指定して、update-table コマンドを使用して DynamoDB テーブルを更新する必要があります。以下のように実行します: aws dynamodb update-table \ --table-name demo-mrsc \ --replica-updates '[{"Create": {"RegionName": "us-east-2"}}]' \ --global-table-witness-updates '[{"Create": {"RegionName": "us-west-2"}}]' \ --multi-region-consistency STRONG \ --region us-east-1 処理が完了したら、MRSC グローバルテーブルのステータスを確認できます。DynamoDB グローバルテーブルに ウィットネス が設定されていることを確認できます。ウィットネスは、マルチリージョン強整合性による高い耐障害性を維持しつつ、コストを削減します。 次に、アプリケーション内で ConsistentRead を使用することで、強整合性を持ってデータを読み取ることができます。以下は Python の例です: import boto3 # 使用するリージョンに合わせて DynamoDB クライアントを設定する dynamodb = boto3.resource('dynamodb', region_name='us-east-2') table = dynamodb.Table('demo-mrsc') pk_id = "demo#test123" # リージョン間で強整合性を保った読む response = table.get_item( Key={ 'PK': pk_id }, ConsistentRead=True ) print(response) 最も強力なレジリエンスを必要とするオペレーションには、 ConsistentRead=True を使用できます。最終的な整合性で問題ないような重要度の低い処理では、このパラメータを省略することで、パフォーマンスの向上とコストの削減が期待できます。 知っておくべき追加情報 以下の点にご注意ください: 可用性 — Amazon DynamoDB のマルチリージョン強整合性機能は、以下の AWS リージョンで利用できます: 米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (大阪、ソウル、東京)、ヨーロッパ (フランクフルト、アイルランド、ロンドン、パリ) 価格設定 — マルチリージョン強整合性の料金は、既存のグローバルテーブルの料金体系に従います。DynamoDB は最近、グローバルテーブルの料金を最大 67% 削減し、これまで以上に高耐障害性のアーキテクチャを手頃な価格で利用できるようになりました。詳しくは、AWS Database Blog の Amazon DynamoDB がオンデマンドスループットとグローバルテーブルの料金を引き下げ の記事をご覧ください。 アプリケーションの最高レベルの耐障害性を実現し、どのリージョンにおいても常に最新のデータを読み取れる、常時稼働のアプリケーションを構築する方法については、 Amazon DynamoDB グローバルテーブル のページをご覧ください。 開発をお楽しみください! — Donnie 原文は こちら です。

6 月 30 日、 AWS Graviton4 プロセッサと最新の第 6 世代 AWS Nitro Card を搭載した Amazon Elastic Compute Cloud (Amazon EC2) C8gn ネットワーク最適化インスタンスの一般提供が発表されました。EC2 C8gn インスタンスは最大 600 Gbps のネットワーク帯域幅を提供します。これは、EC2 ネットワーク最適化インスタンスの中でも最高レベルの帯域幅です。 C8gn インスタンスは、セキュリティおよびネットワーク仮想アプライアンス (仮想ファイアウォール、ルーター、ロードバランサー、プロキシサーバー、DDoS アプライアンス)、データ分析、密結合クラスターコンピューティングジョブなど、要求が最も厳しいネットワーク集約型ワークロードを実行するために使用できます。 EC2 C8gn インスタンスの仕様 C8gn インスタンスは、最大 192 個の vCPU と 384 GiB のメモリを提供し、Graviton3 ベースの EC2 C7gn インスタンス よりも最大 30% 優れたコンピューティングパフォーマンスを実現します。 C8gn インスタンスの仕様は次のとおりです。 インスタンス名 vCPU 数 メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) c8gn.medium 1 2 最大 25 最大 10 c8gn.large 2 4 最大 30 最大 10 c8gn.xlarge 4 8 最大 40 最大 10 c8gn.2xlarge 8 16 最大 50 最大 10 c8gn.4xlarge 16 32 50 10 c8gn.8xlarge 32 64 100 20 c8gn.12xlarge 48 96 150 30 c8gn.16xlarge 64 128 200 40 c8gn.24xlarge 96 192 300 60 c8gn.metal-24xl 96 192 300 60 c8gn.48xlarge 192 384 600 60 c8gn.metal-48xl 192 384 600 60 C8gn インスタンスは、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI)、または AWS SDK を使用して起動できます。 現在 C7gn インスタンスを使用している場合は、新しい C8gn インスタンスでも同様の vCPU/メモリ比率が提供されるため、ネットワーク集約型ワークロードの C8gn インスタンスへの移行を簡単に行えます。詳細については、一連の Graviton リソース をご覧ください。これらは、Graviton インスタンスタイプへのアプリケーションの移行を開始するために役立ちます。 また、「 Level up your compute with AWS Graviton 」ページにアクセスして、Graviton 導入ジャーニーを開始することもできます。 今すぐご利用いただけます Amazon EC2 C8gn インスタンスは、本日から米国東部 (バージニア北部) リージョンと米国西部 (オレゴン) リージョンでご利用いただけます。2 つのメタルインスタンスサイズが提供されるのは、米国東部 (バージニア北部) リージョンのみです。これらのインスタンスは、 オンデマンド 、 Savings Plans 、 スポットインスタンス 、または ハードウェア専有インスタンス および 専有ホスト として購入できます。 Amazon EC2 コンソール で C8gn インスタンスをぜひお試しください。詳細については、「 Amazon EC2 C8g Instances 」ページをご確認ください。ご意見やご要望がありましたら、 EC2 の AWS re:Post 、または通常の AWS サポート窓口までお寄せください。 – Channy 原文は こちら です。

本ブログはユーザックシステム株式会社様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS アカウントマネージャーの藤川です 。 昨今、多くのお客様から生成 AI の活用についてご相談いただくようになりました。ISV(独立系ソフトウェアベンダー)/SaaS業界のお客様においても、生成 AI を活用した新しい製品・サービス開発の取り組みが増えてきています。 企業の業務プロセスの自動化・効率化を支援するユーザックシステム株式会社様（以下、ユーザックシステム様）は、 Amazon Bedrock を活用し、従来は自動化が困難であった非定型の受注業務に生成AI を活用することによって自動化に成功しました。本記事では、生成AIを活用した受注業務における効率化の取り組みについてご紹介します。 お客様の状況と検証に至る経緯 ユーザックシステム様は、20年以上にわたり受注業務の効率化に取り組んできました。同社のRPA(Robotic Process Automation)ソリューション「Auto ジョブ名人」により、定型的な業務の自動化は着実に進展していました。 しかし、「得意先や担当者ごとに対応が異なる」「処理に人の判断が必要」といった非定型業務は、依然として人手に依存せざるを得ない状況が続いていました。特に食品卸業界では、FAXやメールでの注文書のやり取りが主流であり、これらを確認して社内システムに入力する作業に多大な工数を要していました。 また、取引先や社内システムごとに独自のルールが存在するため、受注担当者が一人前になるまでに約1年の経験が必要でした。さらに「昨今の人手不足も相まって、受注業務における生産性向上は喫緊の課題となっていました」とユーザックシステム様は当時を振り返ります。 ソリューション／構成 この課題を解決するため、ユーザックシステム様は「Knowfa 受注AIエージェント」の開発に着手しました。このシステムは、生成AIとRPAを組み合わせることで、非定型の受注業務の完全自動化を目指すソリューションです。(プレスリリースは こちら ) システムの処理フローは以下の通りです。 注文担当者が、お客様からのFAX や電子メールで届いた注文書の画像をシステムに登録する システムが注文書の画像を分析し、文字や数字を自動的に読み取る (例：商品名、個数、お客様情報など) システムは読み取った情報を使って、過去の注文データベースから類似の注文内容を探し出す(例：同じお客様の過去の注文や、似た商品の注文履歴など) システムは 2 で読み取った注文内容と 3 の過去のデータを照らし合わせて、注文内容を判断する (例：商品コード、注文数の確認など) 導入効果 Knowfa 受注AIエージェントの導入により、以下のような顕著な効果が得られました。 AIエージェントが判断業務を担い、人はチェック業務だけに専念する役割分担を確立。これまでRPAで対応できなかった受注業務の80%自動化に成功。 Amazon Bedrockのセキュリティや信頼性により、気密性の高いデータを扱うエンドユーザーにとって安心材料に。 また「AWSのサーバーレスアーキテクチャとマネージドサービスの活用により、エンジニア3名とプロジェクトマネージャー1名という少人数体制でも、約4ヶ月という短期間でβ版開発を実現できました」と、技術面でのメリットを説明します。 今後の展望 今後の展開について、ユーザックシステム様は次のように意欲を示しています。 「現在はFAX注文書を中心に対応していますが、今後はメールやその他の受注業務への展開も計画しています。Amazon Bedrock エージェントを活用し、AIエージェントの自律性を高めながら、対応可能な業務の範囲を拡大していきたいと考えています」 ユーザックシステム株式会社 : 上野 真裕様（中央） Amazon Web Services Japan : アカウントマネージャー 藤川 高志朗（左端）、ソリューションアーキテクト 呉 敏禎（右端）

みなさん、こんにちは！製造業のお客様を中心に技術支援を行っているソリューションアーキテクトの山田です。 AWS Summit Japan 2025 が開催され、製品設計・エンジニアリング分野の展示「CAD や CAE で使用するデスクトップワークステーション環境をクラウド化して最適化〜Research and Engineering Studio on AWS〜」において、多くの関心をいただきました！ 今回の展示では、 Research and Engineering Studio on AWS (RES) による CAD（コンピューター支援設計）/CAE（コンピュータ支援エンジニアリング） 環境のクラウド化と、その環境上で Amazon Q Developer を活用した CAE アプリケーションによる流体解析のデモを実施いたしました。従来の製品設計・CAE 解析プロセスがどのように効率化されるのかをご紹介します。 従来の課題と RES による解決 研究・開発環境の課題 研究とエンジニアリングにおけるイノベーションの阻害要因として以下のような例が挙げられます。 海外の設計チームとデータ共有や打ち合わせが難しく、各拠点でバラバラに作業することになり、同じような問題を何度も解決する無駄が発生する ワークステーションの設定やソフトウェアのインストール、ライセンス管理などに時間を取られ、本来の設計・解析業務に集中できない 手持ちのワークステーションでは大規模な CFD（計算流体力学）解析ができず、「もっと高性能なコンピューティングリソースが欲しい」と思っても簡単には増強できない Research and Engineering Studio on AWS (RES) とは RES は、研究開発チームがクラウドの専門知識を必要とせずに研究者とエンジニアがワークロードを実行できる環境を管理および構築するためのオープンソースの使いやすいウェブベースのポータルです。 図1 RESアーキテクチャ 管理者にとってのメリット インストール、設定、管理が楽になる ハードウェア調達を待つ必要なし、数分で環境構築完了 各拠点への CAD 環境配布も仮想環境で一括管理（図2） 仮想環境により設計拠点に捉われずに CAD 環境の展開やバージョンアップなどのメンテナンスも容易 プロジェクト全体の AWS 使用状況とコストを一元的に監視・管理（図3） 既存の ID 認証システム（ AWS マネージド AD サービス ）と統合でき、セキュリティとガバナンスを一元管理 エンドユーザーにとってのメリット Web ポータルにログインしてタスクに集中できる 最適なコンピュータ環境を使用することで開発の時間を短縮（図4） AWS リソースの管理を習熟する必要は無い 自宅でも出張先でも、どこからでも同じ環境にアクセス可能 大規模解析の時だけ高性能 GPU、普段は低コスト環境で無駄なし 共有データにアクセスできる環境でチーム間の共同作業が可能 図2 Virtual Desktops 図3 Virtual Desktop Dashboard 図4 選択できる高性能な仮想サーバ(Amazon EC2 インスタンス)一例 RES の使用開始方法 GitHub のAmazon Web Servicesリポジトリ にホストされている RES ソースコードをダウンロードします。 RESの起源となる事例 – Amazon Lab126の事例 – Amazon Lab126 は、カリフォルニア州サニーベールに拠点を置く、 Amazon の研究所です。このラボには Amazon Devices のハードウェア、ソフトウェア、運用チームが含まれており、Amazon Echo や Amazon Kindle など 知名度の高い製品を開発しています。 Amazon Lab126 では、老朽化した、コストのかかるオンプレミスの CAE 環境を使用していました。そのためエンジニアリングチームが必要とするスケーラビリティと使いやすさを提供できませんでした。 AWS ベースの CAE 機能を有効にするために、Amazon Lab126 は、最も多くの I/O 集中型ワークロード向けに Amazon FSx for Lustre を使用しました。また、 AWS Backup を使用してクラスターの耐障害性を高める新しいスケールアウトコンピューティングフレームワークを作成しました。 これにより、CAE ジョブの実行を3倍高速化し、新規ユーザーを数週間ではなく1日足らずでオンボーディングすることが可能になりました。必要に応じて新しい CAE クラスターを起動でき、製品設計の革新を推進することができました。 デモ：RES 環境での Amazon Q Developer を活用したCFD（計算流体力学）解析業務支援 アーキテクチャ 図5 RES 環境での Amazon Q Developer を活用した CFD 解析 アーキテクチャ 想定ユーザー例：若手エンジニア 想定ユーザープロファイル ： 学歴・基礎知識：機械工学科卒業、CFD 理論は学習済み 実務経験：CAD 基本操作可能（FreeCAD 等）、流体力学基礎知識あり プログラミング：Python 基礎レベル CFD 経験：学生時代に OpenFOAM を少し触った程度 課題 ： 学生時代の簡単な CFD と実務レベルのギャップが大きい 多機能・高機能な CAE ソフトは使い方がよくわからない 上司から「バイクフレームの空力解析やって」と言われたが、実務経験なし 社内に CFD 専門家がいない（または忙しくて教えてもらえない） Amazon Q Developer による設計プラン作成 Amazon Q Developer（生成 AI 会話アシスタント）とのチャットやり取りで設計目標等を相談し、設計プランドキュメントを作成してもらいます。 図6 バイクフレーム CFD 解析 設計プランドキュメント例 Amazon Bedrock Knowledge Bases による RAG 活用 市販 CAE アプリケーションのユーザーガイドは web で一般公開されているケースが少なく、ソフト購入者のみが見れるケースが一般的です。従って生成 AI モデルで十分に学習済みではないため、Amazon Q Developer が自律的に判断して Amazon Bedrock Knowledge Bases で必要な CAE アプリケーションのマニュアルもしくはドキュメントを RAG（検索拡張生成） 検索して操作ガイドや解析自動実行 Java マクロファイルなどを作成してユーザーに提示します。 2 つの利用方法 1. GUI 操作ガイド CAE アプリケーションの GUI 画面で操作を行っていきたい場合は、Amazon Q Developer が生成した詳細な操作ガイドに従って操作していきます。 図7 バイクフレーム CFD 解析 CAE アプリケーション GUI 操作ガイド例 2. Java マクロ自動実行 CAE でユーザーサブルーチンでカスタマイズしたり自動化するなどの目的でコードを書く必要がある場合（マクロ機能の実行イメージの場合）には、Amazon Q Developper にコードを生成させて利用するようなユースケース（マクロファイルの実行ボタンを押すだけで自動解析実行が行われるイメージ）も考えられます。 図8 バイクフレーム CFD 解析 CAE 自動化コード例 赤字で示された箇所のような、パラメータの数値を変更するだけで様々なバリエーションの解析が自動実行できます。 図9 バイクフレーム CFD 解析 メッシュ分割、流速分布図 CAE アプリケーションを実行時に、ハイスペックな EC2 インスタンスに変更して処理することで、シミュレーション時間を大幅に短縮できます。 RES と同じ AWS 上に構成した HPC （ハイパフォーマンスコンピューティング） クラスタで処理させて、これまで実現できなかった大規模で高精度な解析にチャレンジすることも可能です。 図10 並列処理による解析時間の変化 まとめ AWS Summit Japan 2025 の展示「CAD や CAE で使用するデスクトップワークステーション環境をクラウド化して最適化〜Research and Engineering Studio on AWS〜」では、RES による CAD/CAE 環境のクラウド化と、Amazon Q Developer を活用した CFD（計算流体力学）解析業務支援のデモを通じて、製品設計・エンジニアリング分野における以下のような革新的な変化を実現できることを示しました。 技術面での革新 専門知識の民主化 : 若手エンジニアでも高度な CFD 解析を実行可能 学習コストの削減 : 生成 AI による対話的な学習とガイダンス 自動化の推進 : Java マクロによる解析プロセスの自動化 運用面での改善 迅速な環境構築 : 数分でのワークステーション起動 柔軟なリソース管理 : 需要に応じたスケーリング コスト最適化 : 使用量ベースの課金とリソース管理 組織面での効果 グローバルコラボレーション : 地理的制約を超えた共同作業 知識の共有 : チーム間での専門知識の共有促進 イノベーションの加速 : 技術的制約の解消による創造性の向上 AWS の様々なサービスと組み合わせてどんどん機能拡張させていくことが可能ですが、まずは初めの一歩として、RES 環境での Amazon Q Developer 活用による製品設計・エンジニアリング分野でのデジタルトランスフォーメーションを推進し、競争力の向上を実現していきましょう。 著者プロフィール 山田 航司 (Koji Yamada) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 製造業のお客様を中心にクラウド活用の技術支援を担当しています。好きな AWS のサービスは Amazon Bedrock です。 愛読書は「大富豪トランプのでっかく考えて、でっかく儲けろ」です。

私がシアトルを訪れるたびに空港で最初に出迎えてくれるのは、 レーニア山 です。 Amazon Web Services (AWS) で最も革新的なプロジェクトがこの山にちなんで名付けられていることをご存知でしたか? Project Rainier は、米国内の複数のデータセンターで AI モデルをトレーニングするために、世界で最も強力なものとなることが期待されるコンピュータを作成する新しいプロジェクトです。Anthropic は、現在最も大規模なトレーニングクラスターの 5 倍の計算能力を備える高度な Claude モデル バージョンを開発する予定です。 Project Rainier を支える主要テクノロジーは、 AWS がカスタム設計した Trainium2 チップ です。このチップは、複雑な AI モデルのトレーニングに必要となる膨大なデータ処理に特化しています。大規模なシステム全体での超高速な通信とデータ共有を可能にする、新しいタイプの Amazon EC2 UltraServer と EC2 UltraCluster のアーキテクチャ内で、何千個もの Trainium2 チップが接続されることになります。 チップからソフトウェアに及ぶテクノロジースタックのあらゆるコンポーネントを設計し、最大限の効率性と信頼性のためにシステム全体を最適化することを可能にする、 Project Rainer での AWS の垂直統合 に関する詳細をご覧ください。 6 月 23 日週のリリース 私が注目したリリースをいくつかご紹介します。 Amazon FSx for OpenZFS のための Amazon S3 アクセス – Amazon S3 Access Points を通じて FSx for OpenZFS ファイルデータにアクセスし、分析することができます。このため、ファイルシステムからデータを移動しなくても、AWS の AI/ML サービスや分析サービスとシームレスに統合できるようになります。FSx for OpenZFS データを S3 に保存されているかのように扱うことができるため、Amazon Bedrock、Amazon SageMaker、AWS Glue や、その他の S3 ベースのクラウドネイティブアプリケーションを含めたさまざまなアプリケーションのために S3 API 経由でデータにアクセスすることが可能になります。 Amazon S3 の Apache Iceberg テーブル向けの sort および z-order コンパクション – 新しい sort および z-order コンパクションを使用して、クエリパフォーマンスの向上とコスト削減を実現できます。S3 Tables では、sort コンパクションが定義された列順序に基づいてデータファイルを自動的に整理し、z-order コンパクションは効率的な複数列のクエリのためにメンテナンス API 経由で有効化できます。 Amazon CloudWatch 調査 – 異常の特定、関連するシグナルの表面化、および修復手順の提案に役立つ Amazon CloudWatch の AI 駆動の調査機能を使用することで、AWS 環境内での運用上のトラブルシューティングを迅速化することができます。この機能は、CloudWatch データウィジェット、複数の AWS コンソール、CloudWatch アラームアクション、または Amazon Q チャットを通じて開始でき、チームコラボレーションと Slack や Microsoft Teams との統合を可能にします。 Amazon Bedrock ガードレールの Standard ティア – 新しい Standard ティアを使用することで、AI コンテンツの安全対策を強化できます。このティアは、最大 60 の言語全体でのコンテンツフィルタリング機能とトピック拒否機能の改善、誤字等の表記ゆれ検出の向上、プロンプト攻撃に対する保護の強化を実現します。この機能では、有害コンテンツのブロック、モデルハルシネーションの防止、個人を特定できる情報 (PII) のリダクション、自動推論チェックによる事実に基づく主張の検証を行うためのセーフガードを設定できます。 プライベートホストゾーン向けの Amazon Route 53 Resolver エンドポイント – プライベートホストゾーンのサブドメイン向けの新しい Route 53 DNS 委任機能を使用することで、AWS とオンプレミスインフラストラクチャ全体での DNS 管理を簡素化できます。この機能は、インバウンドとアウトバウンド両方の Resolver エンドポイントで活用できます。ネームサーバーレコードを使用してオンプレミスインフラストラクチャと Route 53 Resolver クラウドサービス間でサブドメイン権限を委任できるため、複雑な条件付き転送ルールが不要になります。 Java 変換向けの Amazon Q Developer CLI – 新しい Amazon Q Developer Java 変換コマンドラインインターフェイス (CLI) を使用して、Java アプリケーションのアップグレードを自動化し、スケールすることができます。この機能は、Java バージョン 8、11、17、または 21 からバージョン 17 または 21 へのアップグレードをコマンドラインから直接実行します。このツールは選択的な変換オプションを提供するため、変換計画から特定のステップを選択し、ライブラリのアップグレードをカスタマイズすることができます。 新しい AWS IoT Device Management マネージド統合 – 新しいマネージド統合機能を使用することで、複数のメーカーやプロトコル全体でのモノのインターネット (IoT) デバイス管理を簡素化できます。この機能は、デバイスが直接接続するか、ハブまたはサードパーティークラウド経由で接続するかにかかわらず、それらデバイスを制御するための統合インターフェイスを提供します。この機能には、事前構築された Cloud-to-Cloud (C2C) コネクタ、デバイスデータモデルテンプレート、および ZigBee、Z-Wave、Wi-Fi プロトコルをサポートする SDK が含まれていますが、カスタムコネクタやデータモデルを作成することも可能です。 AWS のお知らせに関する詳細なリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース AWS サービス用のさまざまな Model Context Protocol (MCP) サーバー がリリースされました。皆さんが関心を持つと思われる MCP サーバー関連のチュートリアルをいくつかご紹介します。 AWS costs estimation using Amazon Q CLI and AWS Cost Analysis MCP – Amazon Q CLI と AWS Cost Analysis MCP サーバーを併用することで、AWS ベストプラクティスに従う高度なコスト分析を実行できます。詳しい例とステップバイステップの手順を使用して、基本的な設定と高度なテクニックを説明します。 Supercharging AWS database development with AWS MCP servers – MCP の背後にある中核的概念について学び、新しい AWS MCP サーバーが自然言語プロンプトを通じてデータベース開発を加速する方法を実証できます。 Create your own MCP server with C# and .NET with Amazob Q CLI – Amazon Q CLI を MCP クライアントとして使用して、C# MCP サーバーを構築し、テストするためのローカル開発環境を設定することで、AI 駆動のアプリケーションを作成、反復、改善する能力を強化します。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS re:Invent – 今すぐ登録して、一足先に最適な学習パスを選択し、移動手段と宿泊先を予約して、皆さんのチームとともに学び、つながり、楽しみましょう。若手のプロフェッショナルならば、 All Builders Welcome Grant プログラム に申し込むこともできます。このプログラムは、経済的な障壁を取り除き、クラウドテクノロジーへの多様な道のりを創り出すように設計されています。 AWS NY Summit – コンピューティング、ストレージ、生成 AI における最新かつ最新鋭の AWS テクノロジーに焦点を当てた Swami の基調講演からインサイトを得ることができます。ニュースブログチームもエキサイティングなニュースをいくつか用意しています。直接参加できない場合でも、 グローバルライブストリームに登録 して参加することが可能です。また、最寄りの都市で 7 月と 8 月に開催される予定の Summit の日付も確認しておきましょう。 AWS Builders Online Series – 太平洋時間帯の地域を拠点としているならば、AWS でワークロードを構築、移行、デプロイするために役立つ基本的な AWS 概念やアーキテクチャ上のベストプラクティスを学び、実践的なデモに参加することができます。 近日開催されるすべての対面イベントと仮想イベント をご覧いただけます。 6 月 30 日週のニュースは以上です。7 月 7 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。

6 月 25 日より、 Amazon S3 Access Points を Amazon FSx for OpenZFS ファイルシステムにアタッチして、 Amazon Simple Storage Service (Amazon S3) に格納されているかのようにデータにアクセスできるようになりました。この新機能を使用すると、S3 と連動する Amazon Web Services (AWS) の幅広い 人工知能 (AI)、 機械学習 (ML)、 分析 サービスやアプリケーションで使用するデータとして FSx for OpenZFS 内のデータにアクセスできます。ファイルデータは引き続き FSx for OpenZFS ファイルシステムに格納されます。 組織は数百エクサバイトのファイルデータをオンプレミスで保存しており、このデータを AWS に移動して、優れた俊敏性、信頼性、セキュリティ、スケーラビリティを実現し、コストを削減したいと考えています。ファイルデータの AWS への移動後に、組織がそのデータをさらに活用したいと考えるのはめずらしいことではありません。例えば、多種多様な AWS 生成 AI サービスと機械学習サービス を使用して、エンタープライスデータで 生成 AI アプリケーションを強化したり、機械学習モデルをトレーニングしたりすることを考えます。また、新しい AWS アプリケーションで独自のファイルデータを使用する柔軟性も求めています。ところが、AWS データ分析サービスとアプリケーションの多くは、Amazon S3 に保存されたデータをデータレイクとして使用するように構築されており、移行した後で Amazon S3 と連動するツールをデータソースとして使用できます。これまで、これには Amazon FSx for OpenZFS ファイルシステムと Amazon S3 バケット間でデータをコピーするためのデータパイプラインが必要でした。 FSx for OpenZFS ファイルシステムに Amazon S3 Access Points をアタッチすると、ファイルプロトコルと Amazon S3 API 操作の両方を経由する統合アクセスが維持され、データの移動やコピーが必要なくなります。 GetObject 、 PutObject 、 ListObjectsV2 などの S3 オブジェクト操作を使用したファイルデータの読み取りや書き込みが行えます。1 つのファイルシステムに数百個の S3 Access Point をアタッチでき、各 Access Point にはアプリケーション固有の許可を設定できます。これらの S3 Access Point は、S3 バケットにアタッチされる S3 のアクセスポイントと同様のきめ細かなアクセス許可コントロールをサポートします。これには、 AWS Identity and Access Management (IAM) アクセスポイントポリシー や パブリックアクセスブロック のほか、 仮想プライベートクラウド (VPC) へのアクセスを制限するなどのネットワークオリジンコントロールが含まれます。データはそのまま FSx for OpenZFS ファイルシステムに格納されるため、引き続き ネットワークファイルシステム (NFS) を使用してデータにアクセスし、既存のデータ管理機能からメリットを得ることができます。 S3 API を使用することで、データが S3 に格納されているかのように Amazon FSx for OpenZFS ファイルシステム内のファイルデータを使用して、 検索拡張生成 (RAG) ワークフローのために Amazon Bedrock で生成 AI アプリケーションを強化し、 Amazon SageMaker で ML モデルをトレーニングして、 Amazon Athena &nbsp;と AWS Glue で分析や ビジネスインテリジェンス (BI) を実行できます。また、データを移動したりリファクタリングしたりすることなく、 Apache Spark や Apache Hive などのオープンソースツールを使用してインサイトを生成することも可能です。 始めましょう S3 Access Point は、 Amazon FSx コンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用して作成し、Amazon FSx for OpenZFS にアタッチできます。 まず、 Amazon FSx for OpenZFS ファイルシステムのドキュメントページ にある手順に従ってファイルシステムを作成します。次に、Amazon FSx コンソールで [アクション] に移動し、 [S3 Access Point を作成] を選択します。&nbsp;標準設定をそのまま変更せずに作成します。 作成の進行状況は、Amazon FSx コンソールで監視できます。 利用可能になったら、新しい S3 Access Point の名前を選択し、Access Point の概要を確認します。概要には自動生成されたエイリアスが含まれています。このエイリアスは、通常 S3 バケット名を使用する場所ならどこでも機能します。 バケットスタイルのエイリアスを使用すると、S3 API 操作経由で FSx データに直接アクセスできます。 ListObjectsV2 API を使用してオブジェクトを一覧表示する GetObject API を使用してファイルを取得する PutObject API を使用してデータを書き込む データには引き続き NFS 経由でアクセスできます。 S3 API 経由で FSx データにアクセスする以外にも、S3 内のデータを処理する幅広い AI、ML、分析サービスを使用してデータを活用できます。私の例を挙げると、私の旅行サポートアプリケーションリポジトリである WhatsApp-Powered RAG Travel Support Agent: Elevating Customer Experience with PostgreSQL Knowledge Retrieval から取得した 航空会社のカスタマーサービス情報が含まれる PDF をデータソースとして使用して、 Amazon Bedrock のナレッジベース を作成しました。 Amazon Bedrock のナレッジベースを作成するため、「 ナレッジベースの Amazon S3 に接続する 」ユーザーガイドの接続ステップを実行しました。データソースとして Amazon S3 を選択し、S3 ソースとして S3 Access Point エイリアスを入力してから、ナレッジベースを設定して作成しました。 ナレッジベースが同期されるとすべてのドキュメントが表示され、 ドキュメントソース が S3 になっていることがわかります。 最後に、ナレッジベースに対してクエリを実行し、コンテキストに即した回答を提供するために Amazon FSx for OpenZFS ファイルシステムのファイルデータが正常に使用されたことを確認しました。そうすることで、データの移動を必要としないシームレスな統合が行われたことがわかります。 知っておくべきこと 統合とアクセスコントロール – Amazon FSx for OpenZFS ファイルシステム向けの Amazon S3 Access Points は、S3 エンドポイント経由での標準 S3 API 操作 (GetObject、ListObjectsV2、PutObject など) をサポートし、AWS Identity and Access Management (IAM) の許可とファイルシステムユーザー認証によるきめ細かなアクセスコントロールを使用します。S3 Access Point には、S3 バケット名を使用してデータにアクセスするための自動生成された Access Point エイリアスが含まれています。Amazon FSx リソースへのパブリックアクセスはデフォルトでブロックされます。 データ管理 – データは Amazon FSx for OpenZFS ファイルシステムに留まるものの、Amazon S3 内にあるかのようにアクセスできるため、データを移動またはコピーする必要がなくなります。ファイルデータは引き続き NFS ファイルプロトコル経由でアクセスできます。 パフォーマンス – Amazon FSx for OpenZFS ファイルシステム向けの Amazon S3 Access Points は、S3 バケットアクセスと同様に、数十ミリ秒範囲のファーストバイトレイテンシーを実現します。パフォーマンスは Amazon FSx ファイルシステムのプロビジョンドスループットに合わせてスケールし、最大スループットは基盤となる FSx ファイルシステムの設定に基づいて判断されます。 料金 – Amazon FSx の標準料金に加えて、S3 Access Points 経由のリクエストとデータ転送に対する Amazon S3 料金が請求されます。詳細については、「 Amazon FSx for OpenZFS の料金 」ページをご覧ください。 Amazon FSx for OpenZFS システムへの Amazon S3 Access Points のアタッチは、Amazon FSx コンソール、AWS CLI、または AWS SDK を使用して今すぐ開始できます。この機能は、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、欧州 (フランクフルト、アイルランド、ストックホルム)、およびアジアパシフィック (香港、シンガポール、シドニー、東京) の各 AWS リージョン でご利用いただけます。 –&nbsp; Eli 原文は こちら です。