こんにちは。ソリューションアーキテクトの柴田です。 2025 年 11 月 21 日に「Security for App Builders @ Loft #1」イベントを目黒の AWS Startup Loft Tokyo にて開催しました。こちらは AWS 上のアプリケーションそのものや、SDLC (ソフトウェア開発ライフサイクル) におけるセキュリティの考え方にフォーカスした、開発者・セキュリティエンジニアの方向けのイベントです。第一回では特に Coding Agent が生成したコードの安全性の確保という課題に焦点を当てて開催しております。ご参加いただきました皆様には、改めて御礼申し上げます。 本ブログでは、当日の内容を簡単にご紹介しつつ、発表資料を公開いたします。 イベント概要 AI を活用した開発プロセスが浸透するに従い、必ずしもセキュリティに精通したエンジニアが関与できない状況で技術的な判断をする機会が増えつつあります。これにより、時に生成 AI や Coding Agent が生成したコードの安全性をどのように説明するかという点で、多くの開発者が悩みを抱えています。 本イベントは、こうした課題を抱えるアプリケーション開発者向けに、セキュリティの原理原則とプラクティスを学んでいただくことを目的にセッションを実施いたしました。セキュリティ組織の方々にとっても、開発現場とのコミュニケーションを円滑にするための知見を得られる内容となっています。また、セッション終了後はネットワーキングということで、各社プロダクトのセキュリティに関心を持つ方同士での情報交換も行われました。 以下、各セッションの概要と当日の様子を紹介いたします。 セッションの紹介 Opening Session : なぜ今アプリケーションセキュリティなのか アマゾン ウェブ サービス ジャパン 合同会社 技術統括本部 デジタルサービス技術本部 ISV/SaaS ソリューション部 部長 大場 崇令 イベントの冒頭では、大場より、AI がコードを書く時代における新たなセキュリティ課題について解説しました。イベント直前に RC1 が公開された OWASP Top10:2025 をピックアップし、アプリケーションセキュリティにおいては、アクセスコントロールの欠陥、設計上の欠陥、サプライチェーン攻撃など、考慮すべき要素が時代と共に変化していることにも触れつつ、AWS 上でセキュアに開発を行うための考え方について全体感を説明しました。 セッション資料 ビルダーのための脅威モデリング アマゾン ウェブ サービス ジャパン 合同会社 技術統括本部 エンタープライズ技術本部 ソリューションアーキテクト 泉 航 SDLC では不具合の修正は早いほどコストが低いと言われています。本セッションでは設計フェーズにおいて構造的欠陥を見つけ出す手段である脅威モデリングについて、どのような流れで進めるのか、効果的なアプローチや進めるためのフレームワークについて泉より解説しました。EC サイトに対する脅威を例に、STRIDE フレームワークによる脅威モデリングの進め方をご案内すると共に、これまで労力のかかっていた脅威モデリングの取り組みについても Kiro を用いることでより少ない準備時間でも脅威モデリングが実施できることを紹介しました。 セッション資料 セキュリティのシフトレフト アマゾン ウェブ サービス ジャパン 合同会社 技術統括本部 デジタルサービス技術本部 ソリューションアーキテクト 吉田 裕貴 吉田からは、SDLC の各フェーズにおけるセキュリティの実践について、その重要性とどのようなツールが利用できるかを解説しました。DevSecOps の登場当時は一定の対応難易度の高さがあったものの、2025 年時点においては SAST / DAST などのツールが検出した結果を元に AI と対話しながら開発者自身で理解を進めることができるようになっています。こうした時代において、改めて Amazon Q Developer を用いた静的レビュー、パイプライン上での SCA、デプロイ後の監視など複数のツールを組み合わせて開発チームとしてシフトレフトの仕組みを実現する方法を紹介しました。 セッション資料 マネージドサービスによるアプリケーションセキュリティの実装 アマゾン ウェブ サービス ジャパン 合同会社 技術統括本部 デジタルサービス技術本部 シニアソリューションアーキテクト 柴田 龍平 最後のセッションでは、柴田より AI Coding 時代に求められる開発チームとセキュリティチーム間のコラボレーションについて触れ、「セキュリティガーディアン」と呼ばれる AWS 内部のプログラム をご紹介しながら、どのようにセキュリティを確保しながら AI による開発をスケールさせるかというお話をしました。セッションの後半では、認証や認可を例に可能な限りマネージドサービスを活用することで、Undeferenciated Heavy Lifting を減らすというお話をしました。本番稼働させるアプリケーションにおいては、安全性のため、そして将来のメンテナンス時のコンテキストのためにも、全てを AI に作り込ませず、可能な限りマネージドサービスや、スタンダードな技術を活用するよう Agent をコントロールしていくことの重要性をお伝えしました。 セッション資料 まとめ 本イベントではセッション後はネットワーキングの場もあり、参加された方からも「今回のセッションは意識付け、仕組みの導入など自社に必要なものが多く参加してよかった」「脅威モデリングを社内に広めていきたい」「セキュリティについて特別な対策はなく、今まで通りの考え方が重要であることが改めて理解できて良かった」とポジティブなフィードバックをいただきました。 本イベントをきっかけに、多くの開発者の皆様に AI Agent を活用しながらより安全で信頼性の高いアプリケーションを構築するためのヒントを得ていただければ幸いです。本文内へリンクされた各セッション資料も是非ご参考ください。各セッションでセキュリティ改善にも AI 自体を活用する、という点に触れておりましたが、12月に行われた re:Invent 2025 では SDLC 全体のアプリケーション保護を行うための フロンティアエージェント として AWS Security Agent もプレビューとして発表されておりますので、ぜひこちらもご確認ください。今後も、お客様のアプリケーション開発におけるセキュリティ向上を支援するため、このようなイベントを継続的に企画・開催してまいります。AWS のサービスを利用することをご検討いただいているお客様がいらっしゃいましたら、無料で個別相談会を開催しておりますので、 こちらのリンク からぜひお申し込みください。 アマゾン ウェブ サービス ジャパン ソリューションアーキテクト 柴田 龍平

  Deutsch | English | Español | Français | Italiano 私は欧州市民として、特に公共部門の組織や規制の厳しい業界におけるデジタル主権の重要性を身をもって理解しています。2026 年 1 月 14 日、 AWS European Sovereign Cloud の一般提供が、すべてのお客様に対して開始されたことをお知らせいたします。 弊社は、この新しい独立したクラウドインフラストラクチャを構築する計画を 2023 年に初めて発表しましたが 、2026 年 1 月 14 日、 包括的な一連の AWS サービスにより 、欧州のお客様の極めて厳格な主権要件を満たす準備が整いました。 ブランデンブルク門 (ベルリン) の夕焼け 欧州の主権要件への対応 欧州全域の組織は、データレジデンシー、運用上のコントロール、ガバナンスの独立性に関する、ますます複雑化する規制要件に直面しています。今日において、極めて厳しい主権要件を満たす必要がある欧州の組織が、従来のオンプレミス環境や、サービスと機能が制限されたオファリングにがんじがらめになっている例は枚挙にいとまがありません。この重要なニーズに応えるため、AWS European Sovereign Cloud は、強力な技術的なコントロール、主権保証、法的保護に裏付けられた、独立運用されるフル機能の唯一のソブリンクラウドです。規制の厳しい業界の公共部門や企業は、最新のクラウドサービスに期待されるイノベーション、セキュリティ、信頼性を維持する、強化された主権コントロールを提供するクラウドインフラストラクチャを必要としています。これらの組織は、データと運用が欧州の管轄下にあり、明確なガバナンス構造と欧州連合 (EU) 内での運用の自律性を確実に実現する必要があります。 欧州向けの新しい独立したクラウドインフラストラクチャ AWS European Sovereign Cloud は、物理的および論理的に独立したクラウドインフラストラクチャであり、すべてのコンポーネントが完全に EU 内に配置されています。AWS European Sovereign Cloud の最初の AWS リージョン はドイツのブランデンブルク州にあり、2026 年 1 月 14 日より一般公開されています。このリージョンは、既存の AWS リージョンとは独立して運用されます。このインフラストラクチャは、冗長化された電源とネットワーキングを備えた複数のアベイラビリティーゾーンを特徴としており、世界との接続が中断された場合でも継続して稼働するように設計されています。 当社は、厳格な分離、国内のデータレジデンシー、低レイテンシーの要件をサポートするため、AWS European Sovereign Cloud のフットプリントを、ドイツから EU 全体に拡張することを計画しています。これは、ベルギー、オランダ、ポルトガルにある新しいソブリン ローカルゾーン から始まる予定です。さらに、AWS European Sovereign Cloud インフラストラクチャは、 AWS 専有ローカルゾーン 、 AWS AI Factory 、または AWS Outposts を利用して、選択した場所 (お客様独自のオンプレミスデータセンターを含む) で拡張できるようになる予定です。 AWS European Sovereign Cloud とそのローカルゾーンは、独自の運用モデルを通じて、強化された主権コントロールを提供します。AWS European Sovereign Cloud は、EU 内に所在する EU 居住者によってのみ運用されるようになる予定です。これには、日常的な運用、技術サポート、カスタマーサービスなどの活動が含まれます。弊社は現在、AWS European Sovereign Cloud を、 EU 内に所在する EU 市民によってのみ運用される ように段階的に移行しています。この移行期間中、当社は引き続き EU 居住者と EU 内に所在する EU 市民から成る混合チームで業務を継続していく予定です。 インフラストラクチャは、ドイツの法令に基づいて設立された専用の欧州法人を通じて管理されます。2025 年 10 月、AWS は、EU 在住の EU 市民である Stéphane Israël 氏を Managing Director に任命しました。Stéphane 氏は、インフラストラクチャ、テクノロジー、サービスを含む AWS European Sovereign Cloud の管理と運用を担当するとともに、AWS のより広範なデジタル主権の取り組みを主導していく予定です。また、2026 年 1 月、AWS は Stefan Hoechbauer 氏 (AWS、Vice President, Germany and Central Europe) を AWS European Sovereign Cloud の Managing Director に任命しました。Hoechbauer 氏は、Stéphane Israel 氏とともに、AWS European Sovereign Cloud を率いていく予定です。 EU 市民のみで構成され、独立した第三者である代表者 2 名を含むアドバイザリーボードが、主権に関する問題について、追加的な監督と専門知識を提供します。 強化されたデータレジデンシーとコントロール AWS European Sovereign Cloud は、包括的なデータレジデンシーの保証を提供するため、極めて厳格なデータレジデンシー要件を満たすことができます。世界中の既存の AWS リージョンと同様に、お客様が別途選択しない限り、すべてのコンテンツはお客様が選択したリージョン内に保存されたままとなります。また、コンテンツに加えて、ロール、許可、リソースラベル、設定など、お客様が作成したメタデータも、EU 内にとどまります。このインフラストラクチャは、その独自の専用 AWS Identity and Access Management (IAM) と課金システムを備えており、すべて欧州圏内で独立して運用されています。 インフラストラクチャに組み込まれた技術的なコントロールにより、 EU 域外からの AWS European Sovereign Cloud へのアクセスが防止 されます。このインフラストラクチャには、 認証期間の運用のための専用の欧州トラストサービスプロバイダー が含まれており、専用の Amazon Route 53 ネームサーバーを使用します。これらのサーバーは、 自身の名前に European Top-Level Domains (TLD) のみを使用します。AWS European Sovereign Cloud は、EU 域外の人員やインフラストラクチャに重大な依存関係を有していません。 セキュリティとコンプライアンスのフレームワーク AWS European Sovereign Cloud は、暗号化、キー管理、アクセスガバナンス、コンピューティング分離のための AWS Nitro System など、お客様が AWS に期待するのと同じコアセキュリティ機能を維持しています。これは、EC2 インスタンスが、暗号的に検証されたプラットフォームの完全性と、ハードウェアで強制された境界から恩恵を享受し、パフォーマンスを犠牲にすることなくデータへの不正アクセスを防止して、ワークロードに必要な主権制御と計算能力の両方を提供することを意味します。インフラストラクチャは、ISO/IEC 27001:2013、SOC 1/2/3 レポート、 Federal Office for Information Security (BSI) C5 認証などのコンプライアンスプログラムに準拠した、 独立したサードパーティー監査 を受けています。 AWS European Sovereign Cloud: Sovereign Reference Framework は、ガバナンスの独立性、運用上のコントロール、データレジデンシー、技術的分離にわたる具体的な主権制御を定義します。このフレームワークは AWS Artifact で利用でき、SOC 2 認証を通じてエンドツーエンドの可視性を提供します。 包括的なサービス可用性 AWS European Sovereign Cloud では、提供開始時から幅広い AWS サービスにアクセスいただけます。これには、人工知能および機械学習 (AI/ML) ワークロード向けの Amazon SageMaker や Amazon Bedrock が含まれます。コンピューティングには、 Amazon Elastic Compute Cloud (Amazon EC2) と AWS Lambda をご利用いただけます。コンテナオーケストレーションは、 Amazon Elastic Kubernetes Service (Amazon EKS) と Amazon Elastic Container Service (Amazon ECS) を通じてご利用いただけます。データベースサービスには、 Amazon Aurora 、 Amazon DynamoDB 、 Amazon Relational Database Service (Amazon RDS) が含まれます。ストレージオプションには、 Amazon Simple Storage Service (Amazon S3) と Amazon Elastic Block Store (Amazon EBS) 、 Amazon Virtual Private Cloud (Amazon VPC) を封じたネットワーキング、 AWS Key Management Service (AWS KMS) と AWS Private Certificate Authority を含むセキュリティサービスが含まれます。最新のサービスリストについては、AWS Builder Center で最近公開された AWS Capabilities の表 をご覧ください。 AWS European Sovereign Cloud は、お客様が主権要件を満たすのを支援することに尽力している AWS パートナーによってサポートされています 。Adobe、Cisco、Cloudera、Dedalus、Esri、Genesys、GitLab、Mendix、Pega、SAP、SnowFlake、Trend Micro、Wiz などのパートナーが、AWS European Sovereign Cloud でソリューションを提供しており、セキュリティ、データ分析、アプリケーション開発、業界固有のワークロードの分野で必要なツールとサービスを提供しています。この幅広いパートナーサポートは、AWS サービスと信頼できるパートナーテクノロジーを組み合わせたソブリンソリューションを構築するのに役立ちます。 欧州のインフラストラクチャへの多額の投資 AWS European Sovereign Cloud は、インフラストラクチャ、雇用創出、スキル開発に対する 78 億 EUR の投資によって支えられています。この投資は、2040 年までに欧州経済に 172 億 EUR の貢献をもたらし、現地の企業で年間約 2,800 人のフルタイム相当の雇用を支えると見込まれています。 技術的な詳細 AWS European Sovereign Cloud は、所在地を問わず、すべてのお客様にご利用いただけます。インフラストラクチャには、 パーティション 名である aws-eusc とリージョン名である eusc-de-east-1 を使用してアクセスできます。パーティションは、AWS リージョンのグループです。各 AWS アカウントは、1 つのパーティションにスコープされます。 インフラストラクチャは、 AWS マネジメントコンソール 、 AWS SDK 、 AWS コマンドラインインターフェイス (AWS CLI) など、すべての標準的な AWS アクセス方法をサポートしているため、既存のワークフローやオートメーションに簡単に統合できます。AWS European Sovereign Cloud パーティション用の新しいルートアカウントを作成したら、このインフラストラクチャ固有の新しい IAM ID とロールを作成することから始めます。これにより、欧州ソブリン環境内のアクセス管理を完全に制御できます。 今すぐ始めましょう AWS European Sovereign Cloud は、AWS のイノベーションと機能へのアクセスを維持しながら、強化された主権コントロールを欧州の組織に提供します。Amazon Web Services EMEA SARL を通じてサービス契約を締結できます。料金は EUR 建てで、請求は 今日サポートされている 8 つの通貨 のいずれかで行われます。このインフラストラクチャは、使い慣れた AWS アーキテクチャ、サービスポートフォリオ、API を使用しているため、アプリケーションの構築と移行が容易です。 AWS European Sovereign Cloud の補遺 には、AWS European Sovereign Cloud に関する追加の契約上のコミットメントが記載されています。 欧州人である私にとって、今回のリリースは、私たちの大陸特有のニーズに応え、業界全体にわたってイノベーションを推進するクラウド機能を提供するという AWS のコミットメントを表しています。AWS European Sovereign Cloud について、そしてお客様の組織が主権要件を満たすのにそれがどのように役立つのかについて、ぜひ詳しくご確認ください。「 Overview of the AWS European Sovereign Cloud 」を読んで、設計目標とアプローチの詳細をご確認いただき、 新規アカウントにサインアップ して、今すぐ最初のワークロードのデプロイを計画しましょう。 – seb 原文は こちら です。 ドイツ語版 Start der AWS European Sovereign Cloud Als Bürger Europas weiß ich aus eigener Erfahrung, wie wichtig digitale Souveränität ist, insbesondere für unsere öffentlichen Einrichtungen und stark regulierten Branchen.Ich freue mich, Ihnen heute mitteilen zu können, dass die AWS European Sovereign Cloud nun für alle Kunden allgemein verfügbar ist. Wir haben unsere Pläne zum Aufbau dieser neuen unabhängigen Cloud-Infrastruktur erstmals im Jahr 2023 vorgestellt .Heute ist diese Infrastruktur bereit, mit einem umfassenden Angebot an AWS-Services die strengsten Souveränitätsanforderungen europäischer Kunden zu erfüllen. Berlin, Brandenburger Tor bei Sonnenuntergang Erfüllung europäischer Souveränitätsanforderungen Organisationen in ganz Europa sehen sich mit zunehmend komplexen regulatorischen Anforderungen in Bezug auf Datenresidenz, operative Kontrolle und Unabhängigkeit der Governance konfrontiert.Europäische Organisationen mit höchsten Souveränitätsanforderungen sind heutzutage allzu oft in veralteten lokalen Umgebungen oder Angeboten mit eingeschränkten Services und Funktionen gefangen.Die AWS European Sovereign Cloud ist die Antwort auf diesen dringenden Bedarf.Sie ist die einzige unabhängig betriebene souveräne Cloud mit vollem Funktionsumfang, die durch strenge technische Kontrollen, Souveränitätszusicherungen und rechtlichen Schutz abgesichert ist.Einrichtungen des öffentlichen Sektors und Unternehmen in stark regulierten Branchen benötigen eine Cloud-Infrastruktur, die erweiterte Souveränitätskontrollen bietet und gleichzeitig die von modernen Cloud-Services erwartete Innovation, Sicherheit und Zuverlässigkeit gewährleistet.Diese Organisationen benötigen die Zusicherung, dass ihre Daten und Aktivitäten unter europäischer Zuständigkeit bleiben, mit klaren Governance-Strukturen und operativer Autonomie innerhalb der Europäischen Union (EU). Eine neue unabhängige Cloud-Infrastruktur für Europa Die AWS European Sovereign Cloud ist eine physisch und logisch getrennte Cloud-Infrastruktur, deren Komponenten sich vollständig innerhalb der EU befinden.Die erste AWS-Region in der AWS European Sovereign Cloud befindet sich im deutschen Bundesland Brandenburg und ist ab heute allgemein verfügbar.Diese Region arbeitet unabhängig von bestehenden AWS-Regionen.Die Infrastruktur umfasst mehrere Availability Zones mit redundanter Stromversorgung und Netzwerkverbindung, die auch bei einer Unterbrechung der Verbindung zum Rest der Welt einen kontinuierlichen Betrieb gewährleisten. Wir beabsichtigen, die Präsenz der AWS European Sovereign Cloud von Deutschland aus EU-weit auszuweiten, um strenge Anforderungen hinsichtlich Isolierung, Datenresidenz innerhalb einzelner Länder und geringer Latenz zu erfüllen.Dies beginnt mit neuen souveränen Local Zones in Belgien, den Niederlanden und Portugal.Darüber hinaus können Sie die Infrastruktur der AWS European Sovereign Cloud mit dedizierten AWS Local Zones , AWS AI Factories oder AWS Outposts an Standorten Ihrer Wahl, einschließlich Ihrer eigenen lokalen Rechenzentren, erweitern. Dank ihres einzigartigen Betriebsmodells bieten die AWS European Sovereign Cloud und ihre Local Zones erweiterte Souveränitätskontrollen.Der Betrieb der AWS European Sovereign Cloud wird ausschließlich von EU-Bürgern mit Wohnsitz in der EU sichergestellt.Dies umfasst Aktivitäten wie den täglichen Betrieb, den technischen Support und den Kundenservice.Wir stellen die AWS European Sovereign Cloud schrittweise so um, dass als Betriebspersonal ausschließlich EU-Bürger mit Wohnsitz in der EU zum Einsatz kommen .Während dieser Übergangsphase werden wir weiterhin mit einem gemischten Team aus in der EU ansässigen Personen und in der EU lebenden EU-Bürgern arbeiten. Die Infrastruktur wird durch spezielle europäische juristische Personen nach deutschem Recht verwaltet.Im Oktober 2025 berief AWS Stéphane Israël , einen in der EU ansässigen EU-Bürger, zum Geschäftsführer.Stéphane wird für das Management und den Betrieb der AWS European Sovereign Cloud verantwortlich zeichnen.Dies umfasst die Bereiche Infrastruktur, Technologie und Services sowie die Federführung bei den breit angelegten Initiativen von AWS auf dem Gebiet der digitalen Souveränität.Im Januar 2026 ernannte AWS zudem Stefan Hoechbauer (Vice President, Germany and Central Europe, AWS) zum Geschäftsführer der AWS European Sovereign Cloud.Er wird gemeinsam mit Stéphane Israel die Leitung der AWS European Sovereign Cloud innehaben. Ein Beirat, dem ausschließlich EU-Bürger, einschließlich zwei unabhängigen externen Vertretern, angehören, fungiert als zusätzliche Kontrollinstanz und bringt Fachwissen in Fragen der Souveränität ein. Verbesserte Datenresidenz und -kontrolle Die AWS European Sovereign Cloud bietet umfassende Garantien hinsichtlich der Datenresidenz, sodass Sie selbst die strengsten Anforderungen in diesem Bereich erfüllen können.Wie auch bei unseren bestehenden AWS-Regionen weltweit verbleiben alle Ihre Inhalte in der von Ihnen ausgewählten Region, sofern Sie keine anderen Einstellungen vornehmen.Neben den Inhalten verbleiben auch die vom Kunden erstellten Metadaten, einschließlich Rollen, Berechtigungen, Ressourcenbezeichnungen und Konfigurationen, innerhalb der EU.Die Infrastruktur verfügt über ein eigenes AWS Identity and Access Management (IAM) und ein eigenes Abrechnungssystem – beides wird innerhalb der europäischen Grenzen unabhängig betrieben. In die Infrastruktur integrierte technische Kontrollen verhindern den Zugriff auf die AWS European Sovereign Cloud von außerhalb der EU .Die Infrastruktur umfasst einen dedizierten europäischen Trust Service Provider für Zertifizierungsstellen und nutzt dedizierte Amazon-Route-53 -Namenserver.Diese Server verwenden ausschließlich europäische Top-Level-Domains (TLDs) für ihre eigenen Namen .Die AWS European Sovereign Cloud unterliegt keinen kritischen Abhängigkeiten hinsichtlich Personal oder Infrastruktur außerhalb der EU. Sicherheits- und Compliance-Framework Die AWS European Sovereign Cloud bietet dieselben zentralen Sicherheitsfunktionen, die Sie von AWS erwarten.Dazu gehören Verschlüsselung, Schlüsselverwaltung, Zugriffskontrolle und das AWS Nitro System für die Isolierung von Rechenressourcen.Dies bedeutet, dass Ihre EC2-Instanzen von einer kryptografisch verifizierten Plattformintegrität und hardwaregestützten Grenzen profitieren, die unbefugten Zugriff auf Ihre Daten verhindern, ohne die Leistung zu beeinträchtigen.So erhalten Sie sowohl die Souveränitätskontrollen als auch die Rechenleistung, die Ihre Workloads erfordern.Die Infrastruktur wird unabhängigen Audits durch Dritt e unterzogen.Die Compliance-Programme umfassen ISO/IEC 27001:2013, SOC-1/2/3-Berichte und das C5-Zertifikat des Bundesamtes für Sicherheit in der Informationstechnik (BSI) . Das AWS European Sovereign Cloud: Sovereign Reference Framework definiert spezifische Souveränitätskontrollen in den Bereichen Governance-Unabhängigkeit, operative Kontrolle, Datenresidenz und technische Isolierung.Dieses Framework ist in AWS Artifact verfügbar und bietet durch SOC-2-Zertifizierung durchgängige Transparenz. Umfassende Serviceverfügbarkeit Von Beginn an steht Ihnen in der AWS European Sovereign Cloud eine breite Palette von AWS-Services zur Verfügung – darunter Amazon SageMaker und Amazon Bedrock für Workloads im Bereich Künstliche Intelligenz und Machine Learning (KI/ML).Für die Rechenleistung stehen Ihnen Amazon Elastic Compute Cloud (Amazon EC2) und AWS Lambda zur Verfügung.Die Container-Orchestrierung ist über den Amazon Elastic Kubernetes Service (Amazon EKS) und den Amazon Elastic Container Service (Amazon ECS) verfügbar.Zu den Datenbank-Services gehören Amazon Aurora , Amazon DynamoDB und Amazon Relational Database Service (Amazon RDS) .Die Speicheroptionen umfassen Amazon Simple Storage Service (Amazon S3) und Amazon Elastic Block Store (Amazon EBS) mit Vernetzung über Amazon Virtual Private Cloud (Amazon VPC) und Sicherheits-Services wie AWS Key Management Service (AWS KMS) und AWS Private Certificate Authority .Eine aktuelle Liste der Services finden Sie in der AWS-Funktionsmatrix , die kürzlich im AWS Builder Center veröffentlicht wurde. Die AWS European Sovereign Cloud wird von AWS-Partnern unterstützt , die es sich zur Aufgabe gemacht haben, Ihnen bei der Erfüllung Ihrer Souveränitätsanforderungen zur Seite zu stehen.Partner wie Adobe, Cisco, Cloudera, Dedalus, Esri, Genesys, GitLab, Mendix, Pega, SAP, SnowFlake, Trend Micro und Wiz stellen ihre Lösungen in der AWS European Sovereign Cloud zur Verfügung und bieten Ihnen die Tools und Services, die Sie in den Bereichen Sicherheit, Datenanalyse, Entwicklung von Anwendungen und branchenspezifische Workloads benötigen.Dank dieser umfassenden Unterstützung durch Partner können Sie eigenständige Lösungen, die AWS-Services mit bewährten Partnertechnologien kombinieren, entwickeln. Erhebliche Investitionen in die europäische Infrastruktur Hinter der AWS European Sovereign Cloud steht eine Investition in Höhe von 7,8 Milliarden Euro in Infrastruktur, die Schaffung von Arbeitsplätzen und die Entwicklung von Kompetenzen.Diese Investition wird bis 2040 voraussichtlich 17,2 Milliarden Euro zur europäischen Wirtschaftsleistung beitragen und jährlich rund 2 800 Vollzeitstellen in lokalen Unternehmen sichern. Einige technische Details Die AWS European Sovereign Cloud steht allen Kunden zur Verfügung, unabhängig davon, wo sie sich befinden.Sie können mit dem Partitionsnamen aws-eusc und dem Regionsnamen eusc-de-east-1 auf die Infrastruktur zugreifen.Eine Partition ist eine Gruppe von AWS-Regionen.Jedes AWS-Konto ist auf eine Partition beschränkt. Die Infrastruktur unterstützt alle gängigen AWS-Zugriffsmethoden, einschließlich der AWS Management Console , AWS SDKs und der AWS Command Line Interface (AWS CLI) , sodass sie sich problemlos in Ihre bestehenden Workflows und Automatisierungsprozesse integrieren lässt.Nachdem Sie ein neues Root-Konto für die Partition der AWS European Sovereign Cloud erstellt haben, beginnen Sie mit der Erstellung neuer IAM-Identitäten und -Rollen, die speziell für diese Infrastruktur vorgesehen sind.Dadurch erhalten Sie die vollständige Kontrolle über die Zugriffsverwaltung innerhalb der europäischen souveränen Umgebung. Erste Schritte Die AWS European Sovereign Cloud bietet europäischen Organisationen erweiterte Souveränitätskontrollen und gewährleistet gleichzeitig den Zugriff auf die Innovationen und Funktionen von AWS.Sie können Services über Amazon Web Services EMEA SARL in Auftrag geben.Die Preise werden in Euro angegeben und die Abrechnung erfolgt in einer der acht Währungen, die wir derzeit unterstützen .Die Infrastruktur basiert auf der bekannten AWS-Architektur, dem AWS-Serviceportfolio und den AWS-APIs, wodurch die Entwicklung und Migration von Anwendungen vereinfacht wird. Der AWS European Sovereign Cloud Addendum enthält die zusätzlichen vertraglichen Verpflichtungen für die AWS European Sovereign Cloud. Für mich als Europäer symbolisiert dieser Launch das Engagement von AWS, den spezifischen Anforderungen unseres Kontinents gerecht zu werden und Cloud-Funktionen bereitzustellen, die Innovationen in allen Branchen vorantreiben.Ich lade Sie ein, mehr über die AWS European Sovereign Cloud zu erfahren und zu entdecken, wie sie Ihrer Organisation dabei helfen kann, ihre Souveränitätsanforderungen zu erfüllen.Lesen Sie die Übersicht über die AWS European Sovereign Cloud und erfahren Sie mehr über die Designziele und den Ansatz. Registrieren Sie sich für ein neues Konto und planen Sie noch heute die Bereitstellung Ihrer ersten Workload. – seb フランス語版 Ouverture de l’AWS European Souvereign Cloud En tant que citoyen européen, je mesure personnellement l’importance de la souveraineté numérique, en particulier pour nos organisations du secteur public et les industries fortement réglementées.Aujourd’hui, j’ai le plaisir d’annoncer que l’ AWS European Sovereign Cloud est désormais disponible pour l’ensemble de nos clients. Nous avions annoncé pour la première fois notre projet de construction de cette nouvelle infrastructure cloud indépendante en 2023 , et elle est aujourd’hui prête à répondre aux exigences de souveraineté les plus strictes des clients européens, avec un large ensemble de services AWS . Berlin, porte de Brandebourg au coucher du soleil Répondre aux exigences européennes en matière de souveraineté Partout en Europe, les organisations sont confrontées à des exigences réglementaires de plus en plus complexes en matière de résidence des données, de contrôle opérationnel et d’indépendance de la gouvernance.Trop souvent aujourd’hui, les organisations européennes ayant les besoins de souveraineté les plus élevés se retrouvent contraintes de rester sur des environnements sur site, ou de recourir à des offres cloud aux services et fonctionnalités limités.Pour répondre à cet enjeu critique, l’AWS European Sovereign Cloud est le seul cloud souverain entièrement fonctionnel, exploité de manière indépendante, et reposant sur des contrôles techniques robustes, des garanties de souveraineté et des protections juridiques solides.Les acteurs du secteur public et les entreprises des secteurs fortement réglementés ont besoin d’une infrastructure cloud offrant des contrôles de souveraineté renforcés, sans renoncer à l’innovation, à la sécurité et à la fiabilité attendues des services cloud modernes.Ces organisations doivent avoir l’assurance que leurs données et leurs opérations restent sous juridiction européenne, avec des structures de gouvernance claires et une autonomie opérationnelle au sein de l’Union européenne (UE). Une nouvelle infrastructure cloud indépendante pour l’Europe L’AWS European Sovereign Cloud repose sur une infrastructure cloud physiquement et logiquement distincte, dont l’ensemble des composants est situé exclusivement au sein de l’UE.La première région AWS de l’AWS European Sovereign Cloud est implantée dans le Land de Brandebourg, en Allemagne, et est disponible dès aujourd’hui.Cette région fonctionne de façon indépendante par rapport aux autres régions AWS existantes.L’infrastructure comprend plusieurs zones de disponibilité, avec des systèmes redondants d’alimentation et de réseau, conçus pour fonctionner en continu même en cas d’interruption de la connectivité avec le reste du monde. Nous prévoyons d’étendre l’empreinte de l’AWS European Sovereign Cloud depuis l’Allemagne à l’ensemble de l’UE, afin de répondre aux exigences strictes d’isolation, de résidence des données dans certains pays et de faible latence.Cette extension débutera avec de nouvelles Local Zones souveraines situées en Belgique, aux Pays-Bas et au Portugal.En complément, vous pourrez étendre l’infrastructure de l’AWS European Sovereign Cloud à l’aide des AWS Dedicated Local Zones , des AWS AI Factories ou d’ AWS Outposts , dans les sites de votre choix, y compris au sein de vos propres centres de données sur site. L’AWS European Sovereign Cloud et ses Local Zones offrent des contrôles de souveraineté renforcés grâce à un modèle opérationnel unique.L’AWS European Sovereign Cloud est exploité exclusivement par des résidents de l’UE basés dans l’UE.Cela couvre notamment les opérations quotidiennes, le support technique et le service client.Nous sommes en train d’opérer une transition progressive afin que l’AWS European Sovereign Cloud soit exploité exclusivement par des citoyens de l’UE résidant dans l’UE .Durant cette période de transition, nous continuons de travailler avec une équipe mixte composée de résidents de l’UE et de citoyens de l’UE basés dans l’UE. L’infrastructure est gérée par des entités juridiques européennes dédiées, établies conformément au droit allemand.En octobre 2025, AWS a nommé Stéphane Israël , citoyen de l’UE résidant dans l’UE, au poste de directeur général.Stéphane est responsable de la gestion et de l’exploitation de l’AWS European Sovereign Cloud, couvrant l’infrastructure, la technologie et les services, ainsi que de la direction des initiatives plus larges d’AWS en matière de souveraineté numérique.En janvier 2026, AWS a également nommé Stefan Hoechbauer (Vice-président, Allemagne et Europe centrale, AWS) comme directeur général de l’AWS European Sovereign Cloud.Il travaillera aux côtés de Stéphane Israël pour piloter l’AWS European Sovereign Cloud. Un conseil consultatif, composé exclusivement de citoyens de l’UE et incluant deux représentants indépendants, apporte un niveau supplémentaire de supervision et d’expertise sur les questions de souveraineté. Résidence des données et contrôle renforcés L’AWS European Sovereign Cloud fournit des garanties complètes en matière de résidence des données afin de répondre aux exigences les plus strictes.Comme dans les régions AWS existantes à travers le monde, l’ensemble de vos contenus reste dans la région que vous sélectionnez, sauf indication contraire de votre part.Au-delà des contenus, les métadonnées créées par les clients — telles que les rôles, les autorisations, les étiquettes de ressources et les configurations — restent également au sein de l’UE.L’infrastructure dispose de son propre système dédié de AWS Identity and Access Management (IAM) et de facturation, opérant de manière totalement indépendante à l’intérieur des frontières européennes. Des contrôles techniques intégrés à l’infrastructure empêchent tout accès à l’AWS European Sovereign Cloud depuis l’extérieur de l’UE .L’infrastructure comprend un prestataire européen de services de confiance dédié pour les opérations d’autorité de certification et utilise des serveurs de noms Amazon Route 53 dédiés.Ces serveurs n’utilisent que des domaines de premier niveau (TLD) européens pour leurs propres noms .L’AWS European Sovereign Cloud ne présente aucune dépendance critique vis-à-vis de personnels ou d’infrastructures situés en dehors de l’UE. Cadre de sécurité et de conformité L’AWS European Sovereign Cloud conserve les capacités de sécurité fondamentales attendues d’AWS, notamment le chiffrement, la gestion des clés, la gouvernance des accès et le système AWS Nitro pour l’isolation des charges de calcul.Concrètement, vos instances EC2 bénéficient d’une intégrité de plateforme vérifiée cryptographiquement et de frontières matérielles, empêchant tout accès non autorisé à vos données sans compromis sur les performances.Vous bénéficiez ainsi à la fois des contrôles de souveraineté et de la puissance de calcul nécessaires à vos charges de travail.L’infrastructure fait l’objet d’audits indépendants réalisés par des tiers , et s’inscrit dans des programmes de conformité incluant ISO/IEC 27001:2013, les rapports SOC 1/2/3, ainsi que l’attestation C5 de l’ Office fédéral allemand pour la sécurité de l’information (BSI) . Le AWS European Sovereign Cloud: Sovereign Reference Framework définit précisément les contrôles de souveraineté couvrant l’indépendance de la gouvernance, le contrôle opérationnel, la résidence des données et l’isolation technique.Ce cadre est disponible dans AWS Artifact et offre une visibilité de bout en bout via une attestation SOC 2. Disponibilité étendue des services Dès son lancement, l’AWS European Sovereign Cloud donne accès à un large éventail de services AWS, notamment Amazon SageMaker et Amazon Bedrock pour les charges de travail d’intelligence artificielle et de machine learning (IA/ML).Pour le calcul, vous pouvez utiliser Amazon Elastic Compute Cloud (Amazon EC2) et AWS Lambda .L’orchestration de conteneurs est disponible via Amazon Elastic Kubernetes Service (Amazon EKS) et Amazon Elastic Container Service (Amazon ECS) .Les services de bases de données incluent Amazon Aurora , Amazon DynamoDB et Amazon Relational Database Service (Amazon RDS) .Les options de stockage comprennent Amazon Simple Storage Service (Amazon S3) et Amazon Elastic Block Store (Amazon EBS) , avec des capacités réseau via Amazon Virtual Private Cloud (Amazon VPC) et des services de sécurité tels que AWS Key Management Service (AWS KMS) et AWS Private Certificate Authority .Pour obtenir la liste la plus à jour des services disponibles, consultez la matrice des capacités AWS récemment publiée sur l’AWS Builder Center. L’AWS European Sovereign Cloud est supporté par de nombreux partenaires AWS engagés à vous aider à répondre à vos exigences de souveraineté.Des partenaires tels qu’Adobe, Cisco, Cloudera, Dedalus, Esri, Genesys, GitLab, Mendix, Pega, SAP, SnowFlake, Trend Micro et Wiz rendent leurs solutions disponibles sur l’AWS European Sovereign Cloud, vous offrant ainsi les outils et services nécessaires dans les domaines de la sécurité, de l’analyse de données, du développement applicatif et des charges de travail spécifiques à certains secteurs industriels.Cet ensemble de partenaires vous permet de construire des solutions souveraines combinant les services AWS et des technologies de partenaires de confiance. Un investissement majeur dans l’infrastructure européenne L’AWS European Sovereign Cloud s’appuie sur un investissement de 7,8 milliards d’euros dans l’infrastructure, la création d’emplois et le développement des compétences.Cet investissement devrait contribuer à hauteur de 17,2 milliards d’euros à l’économie européenne d’ici 2040 et soutenir environ 2.800 emplois équivalent temps plein par an au sein des entreprises locales. Quelques détails techniques L’AWS European Sovereign Cloud est accessible à tous les clients, quel que soit leur lieu d’implantation.Vous pouvez accéder à l’infrastructure en utilisant le nom de partition aws-eusc et le nom de région eusc-de-east-1 .Une partition correspond à un ensemble de régions AWS.Chaque compte AWS est rattaché à une seule partition. L’infrastructure prend en charge toutes les méthodes d’accès AWS standards, y compris la console de gestion AWS , les AWS SDKs et la AWS Command Line Interface (AWS CLI) , ce qui facilite son intégration dans vos flux de travail et vos automatisations existants.Après avoir créé un nouveau compte racine pour la partition AWS European Sovereign Cloud, vous commencez par définir de nouvelles identités et rôles IAM spécifiques à cette infrastructure, vous donnant un contrôle total sur la gestion des accès au sein de l’environnement souverain européen. Pour commencer L’AWS European Sovereign Cloud offre aux organisations européennes des contrôles de souveraineté renforcés tout en leur permettant de continuer à bénéficier de l’innovation et des capacités d’AWS.Vous pouvez contractualiser les services via Amazon Web Services EMEA SARL, avec une tarification en euros et une facturation possible dans l’une des huit devises que nous prenons en charge aujourd’hui .L’infrastructure repose sur une architecture, un portefeuille de services et des API AWS familiers, ce qui simplifie le développement et la migration des applications. L’ avenant AWS European Sovereign Cloud précise les engagements contractuels supplémentaires propres à l’AWS European Sovereign Cloud. En tant qu’Européen, ce lancement illustre l’engagement d’AWS à répondre aux besoins spécifiques de notre continent et à fournir les capacités cloud qui stimulent l’innovation dans tous les secteurs.Je vous invite à découvrir l’AWS European Sovereign Cloud et à comprendre comment il peut aider votre organisation à satisfaire ses exigences de souveraineté.Consultez Overview of the AWS European Sovereign Cloud (en anglais) pour en savoir plus sur les objectifs de conception et l’approche retenue, créez un nouveau compte et planifiez dès aujourd’hui le déploiement de votre première charge de travail. – seb イタリア語版 Lancio di AWS European Sovereign Cloud Come cittadino europeo, conosco benissimo l’importanza della sovranità digitale, in particolare per le nostre organizzazioni del settore pubblico e dei settori altamente regolamentati.Oggi sono lieto di annunciare che AWS European Sovereign Cloud è ora generalmente disponibile per tutti i clienti. Abbiamo annunciato per la prima volta i nostri piani per la creazione di questa nuova infrastruttura cloud indipendente nel 2023. Finalmente oggi è pronta a soddisfare i più rigorosi requisiti di sovranità dei clienti europei con un set completo di servizi AWS . Berlino, Porta di Brandeburgo al tramonto Soddisfare i requisiti di sovranità europea Le organizzazioni di tutta Europa devono far fronte a requisiti normativi sempre più complessi in materia di residenza dei dati, controllo operativo e indipendenza della governance.Troppo spesso, le organizzazioni europee con i più elevati requisiti di sovranità sono bloccate a causa di offerte o ambienti on-premises legacy con funzionalità e servizi ridotti.In risposta a questa esigenza fondamentale, l’AWS European Sovereign Cloud rappresenta l’unico cloud sovrano con funzionalità complete e a gestione autonoma. supportato da solidi controlli tecnici, garanzie di sovranità e protezioni legali.Gli enti pubblici e le aziende di settori altamente regolamentati necessitano di un’infrastruttura cloud che fornisca controlli di sovranità avanzati che garantiscano l’innovazione, la sicurezza e l’affidabilità che si aspettano dai moderni servizi cloud.Queste organizzazioni devono essere certe che i propri dati e le proprie operazioni restino sotto la giurisdizione europea, con chiare strutture di governance e autonomia operativa nell’ambito dell’Unione europea (UE). Una nuova infrastruttura cloud indipendente per l’Europa L’AWS European Sovereign Cloud rappresenta un’infrastruttura cloud separata fisicamente e logicamente, con tutti i componenti situati interamente all’interno dell’UE.La prima Regione AWS nell’AWS European Sovereign Cloud, situata nello stato di Brandeburgo (Germania) e ora disponibile a livello generale, opera indipendentemente dalle Regioni AWS esistenti.L’infrastruttura presenta diverse zone di disponibilità con risorse di alimentazione e rete ridondanti, progettate per funzionare continuamente anche in caso di interruzione della connettività con il resto del mondo. Abbiamo intenzione di estendere la presenza dell’AWS European Sovereign Cloud dalla Germania all’intera UE per supportare i rigorosi requisiti di isolamento, residenza dei dati all’interno di un determinato Paese e bassa latenza.Inizieremo con nuove zone locali sovrane situate in Belgio, nei Paesi Bassi e in Portogallo.Inoltre, sarà possibile estendere l’infrastruttura AWS European Sovereign Cloud con Zone locali AWS dedicate , AWS AI Factories o AWS Outposts in posizioni selezionate, inclusi i data center on-premises. L’AWS European Sovereign Cloud e le relative zone locali forniscono controlli sovrani avanzati tramite un modello operativo esclusivo.L’AWS European Sovereign Cloud sarà gestito esclusivamente da residenti UE che si trovano nell’UE.Ciò copre attività come operazioni quotidiane, supporto tecnico e servizio clienti.Stiamo gradualmente trasformando l’AWS European Sovereign Cloud in modo che sia gestito esclusivamente da cittadini UE che si trovano nell’UE .Durante questo periodo di transizione, continueremo a lavorare con un team misto di residenti e cittadini comunitari che si trovano nell’UE. L’infrastruttura è gestita da entità giuridiche europee dedicate, costituite secondo il diritto tedesco.Nell’ottobre 2025, AWS ha assegnato l’incarico di managing director a Stéphane Israël , cittadino comunitario residente nell’UE.Sarà responsabile della gestione e delle operazioni dell’AWS European Sovereign Cloud, inclusi infrastruttura, tecnologia e servizi, oltre a guidare le più ampie iniziative di sovranità digitale di AWS.Nel gennaio 2026, AWS ha inoltre nominato managing director dell’AWS European Sovereign Cloud Stefan Höchbauer (vicepresidente, Germania ed Europa centrale, AWS).Collaborerà con Stéphane Israël per guidare l’AWS European Sovereign Cloud. Un comitato consultivo composto esclusivamente da cittadini comunitari, inclusi due rappresentanti terzi indipendenti, fornirà ulteriore supervisione e competenza in materia di sovranità. Ottimizzazione del controllo e della residenza dei dati L’AWS European Sovereign Cloud offre garanzie complete sulla residenza dei dati in modo da poter soddisfare i requisiti più rigorosi in materia.Come per le nostre Regioni AWS esistenti a livello mondiale, tutti i contenuti restano all’interno della Regione selezionata, a meno che non si scelga diversamente.Oltre ai contenuti, anche i metadati creati dai clienti, tra cui ruoli, autorizzazioni, etichette delle risorse e configurazioni, restano nell’ambito dell’UE.L’infrastruttura è dotata di un proprio sistema AWS Identity and Access Management (AWS IAM) e di fatturazione dedicato, completamente gestito in modo indipendente all’interno dei confini europei. I controlli tecnici integrati nell’infrastruttura impediscono l’accesso all’AWS European Sovereign Cloud dall’esterno dell’UE .L’infrastruttura include un provider di servizi fiduciari europeo dedicato per le operazioni delle autorità di certificazione e utilizza nameserver Amazon Route 53 dedicati.Questi server utilizzeranno solo domini di primo livello (TLD) europei per i propri nomi .L’AWS European Sovereign Cloud non ha dipendenze fondamentali da personale o infrastrutture non UE. Framework di sicurezza e conformità L’AWS European Sovereign Cloud mantiene le stesse funzionalità di sicurezza di base di AWS, tra cui crittografia, gestione delle chiavi, governance degli accessi e AWS Nitro System per l’isolamento computazionale.Ciò significa che le istanze EC2 beneficiano dell’integrità della piattaforma verificata a livello di crittografia e dei limiti imposti dall’hardware che impediscono l’accesso non autorizzato ai dati senza compromettere le prestazioni, offrendo i controlli di sovranità e la potenza di calcolo richiesti dai carichi di lavoro.L’infrastruttura è sottoposta ad audit di terze parti indipendenti , con programmi di conformità che includono ISO/IEC 27001:2013, report SOC 1/2/3 e attestazione C5 dell’ Ufficio Federale per la Sicurezza Informatica (BSI) . L’ AWS European Sovereign Cloud: Sovereign Reference Framework definisce i controlli di sovranità specifici in termini di indipendenza della governance, controllo operativo, residenza dei dati e isolamento tecnico.Questo framework è disponibile in AWS Artifact e fornisce visibilità end-to-end tramite l’attestazione SOC 2. Disponibilità completa del servizio Dal momento del lancio, sarà possibile accedere a un’ampia gamma di servizi AWS nell’AWS European Sovereign Cloud, tra cui Amazon SageMaker e Amazon Bedrock per carichi di lavoro di intelligenza artificiale e machine learning (IA/ML).Per i calcoli, è possibile utilizzare Amazon Elastic Compute Cloud (Amazon EC2) e AWS Lambda .L’orchestrazione di container è disponibile tramite Amazon Elastic Kubernetes Service (Amazon EKS) e Amazon Elastic Container Service (Amazon ECS) .I servizi di database includono Amazon Aurora , Amazon DynamoDB e Amazon Relational Database Service (Amazon RDS) .Le opzioni di storage includono Amazon Simple Storage Service (Amazon S3) e Amazon Elastic Block Store (Amazon EBS) , con connessione in rete tramite Amazon Virtual Private Cloud (Amazon VPC) e servizi di sicurezza tra cui Servizio AWS di gestione delle chiavi (AWS KMS) e Autorità di certificazione privata AWS (AWS Private CA) .Per un elenco aggiornato dei servizi, è possibile consultare l’ elenco delle funzionalità AWS pubblicato di recente su AWS Builder Center. L’AWS European Sovereign Cloud è supportato dai partner AWS , che aiutano a soddisfare i propri requisiti di sovranità.Partner come Adobe, Cisco, Cloudera, Dedalus, Esri, Genesys, GitLab, Mendix, Pega, SAP, SnowFlake, Trend Micro e Wiz stanno rendendo disponibili le loro soluzioni nell’AWS European Sovereign Cloud, fornendo gli strumenti e i servizi necessari per la sicurezza, l’analisi dei dati, lo sviluppo di applicazioni e i carichi di lavoro specifici del settore.Questo ampio supporto dei partner aiuta a creare soluzioni sovrane che combinano i servizi AWS con tecnologie di partner affidabili. Investimenti significativi nelle infrastrutture europee L’AWS European Sovereign Cloud è sostenuto da un investimento di 7,8 miliardi di euro destinati a infrastrutture, creazione di posti di lavoro e sviluppo delle competenze.Si prevede che questo investimento contribuirà con 17,2 miliardi di euro all’economia europea fino al 2040 e sosterrà circa 2.800 posti di lavoro equivalenti a tempo pieno all’anno nelle aziende locali. Alcuni dettagli tecnici L’AWS European Sovereign Cloud è disponibile per tutti i clienti, indipendentemente da dove si trovino.È possibile accedere all’infrastruttura utilizzando il nome della partizione aws-eusc e il nome della Regione eusc-de-east-1.Una partizione è un gruppo di Regioni AWS.Ogni account AWS è associato a una partizione. L’infrastruttura supporta tutti i metodi di accesso AWS standard, tra cui la Console di gestione AWS , gli SDK AWS e l’ interfaccia della linea di comando AWS (AWS CLI) , semplificando l’integrazione nell’automazione e nei flussi di lavoro esistenti.Dopo aver creato un nuovo account root per la partizione Di AWS European Sovereign Cloud, si inizia creando nuove identità e ruoli IAM specifici per questa infrastruttura, che consentiranno di avere il controllo completo sulla gestione degli accessi all’interno dell’ambiente sovrano europeo. Nozioni di base L’AWS European Sovereign Cloud fornisce alle organizzazioni europee controlli di sovranità avanzati pur mantenendo l’accesso all’innovazione e alle funzionalità di AWS.È possibile contrattare servizi tramite Amazon Web Services EMEA SARL, con prezzi in EUR e fatturazione in una delle otto valute supportate oggi .L’infrastruttura utilizza l’architettura AWS, il portafoglio di servizi e le API tradizionali, semplificando la creazione e la migrazione delle applicazioni. L’ addendum di AWS European Sovereign Cloud include gli impegni contrattuali aggiuntivi per l’AWS European Sovereign Cloud. Per me come europeo, questo lancio rappresenta l’impegno di AWS per soddisfare le esigenze specifiche del nostro continente e fornire le funzionalità cloud che guidano l’innovazione in tutti i settori.Invito tutti a scoprire di più sull’AWS European Sovereign Cloud e su come può aiutare le organizzazioni a soddisfare i requisiti di sovranità.Nella Panoramica di AWS European Sovereign Cloud sono disponibili maggiori informazioni sugli obiettivi e sull’approccio di progettazione, creare un nuovo account  e pianificare l’implementazione del primo carico di lavoro oggi stesso. – seb スペイン語版 Apertura de AWS European Sovereign Cloud Como ciudadano europeo, comprendo de primera mano la importancia de la soberanía digital, especialmente para las organizaciones de nuestro sector público y las industrias altamente reguladas.Hoy me complace anunciar que la AWS European Sovereign Cloud ya está disponible de forma generalizada para todos los clientes. Anunciamos por primera vez nuestros planes de crear esta nueva infraestructura de nube independiente en 2023 , y hoy está lista para cumplir los requisitos de soberanía más estrictos de los clientes europeos con un exhaustivo conjunto de servicios de AWS . Berlín, Puerta de Brandeburgo al atardecer Cumplimiento de los requisitos de soberanía europeos Las organizaciones de toda Europa se enfrentan a unos requisitos normativos cada vez más complejos en relación con la residencia de los datos, el control operativo y la independencia de la gobernanza.Hoy en día, con demasiada frecuencia, las organizaciones europeas con los requisitos de soberanía más estrictos se ven atrapadas en entornos locales heredados u ofertas con servicios y funcionalidades reducidos.En respuesta a esta necesidad crítica, la AWS European Sovereign Cloud es la única nube soberana independiente con todas las características que está respaldada por sólidos controles técnicos, garantías de soberanía y protecciones legales.Las entidades del sector público y las empresas de industrias altamente reguladas necesitan una infraestructura en la nube que proporcione controles de soberanía mejorados que mantengan la innovación, la seguridad y la fiabilidad que se esperan de los servicios modernos en la nube.Estas organizaciones necesitan la garantía de que sus datos y operaciones permanecen bajo la jurisdicción europea, con estructuras de gobernanza claras y autonomía operativa dentro de la Unión Europea (UE). Una nueva infraestructura de nube independiente para Europa La AWS European Sovereign Cloud es una infraestructura de nube separada de manera física y lógica, en la que todos los componentes están ubicados íntegramente dentro de la UE.La primera región de AWS de la AWS European Sovereign Cloud se encuentra en el estado de Brandeburgo (Alemania) y ya está disponible para el público en general.Esta región opera de forma independiente de las regiones de AWS existentes.La infraestructura cuenta con varias zonas de disponibilidad con fuentes de alimenacion y redes redundantes, diseñadas para funcionar de forma continua incluso si se interrumpe la conectividad con el resto del mundo. Tenemos previsto ampliar la presencia de la AWS European Sovereign Cloud de Alemania a toda la UE para cumplir los requisitos de aismlamiento estrictos, residencia de los datos dentro del país y baja latencia.Esto comenzará con nuevas zonas locales soberanas ubicadas en Bélgica, los Países Bajos y Portugal.Además, podrá ampliar la infraestructura de la AWS European Sovereign Cloud con zonas locales dedicadas de AWS , AWS AI Factories o AWS Outposts en las ubicaciones que elija, incluidos sus propios centros de datos locales. La AWS European Sovereign Cloud y sus zonas locales proporcionan controles soberanos mejorados a través de su modelo operativo único.La AWS European Sovereign Cloud será operada exclusivamente por residentes de la UE ubicados en la UE.Abarca actividades como las operaciones diarias, la asistencia técnica y el servicio de atención al cliente.Estamos realizando una transición gradual de la AWS European Sovereign Cloud para que se opere exclusivamente por ciudadanos de la UE ubicados en la UE .Durante este período de transición, seguiremos trabajando con un equipo mixto de residentes de la UE y ciudadanos de la UE ubicados en la UE. La infraestructura se administra a través de entidades jurídicas europeas especializadas constituidas en el marco de la legislación alemana.En octubre de 2025, AWS nombró director general a Stéphane Israël , ciudadano de la UE que reside en la UE.Stéphane será responsable de la administración y las operaciones de la AWS European Sovereign Cloud, lo que incluye la infraestructura, la tecnología y los servicios, además de liderar los esfuerzos más amplios de AWS en materia de soberanía digital.En enero de 2026, AWS también nombró a Stefan Hoechbauer (vicepresidente de AWS para Alemania y Europa Central) director general de la AWS European Sovereign Cloud.Stefan dirigirá la AWS European Sovereign Cloud junto con Stéphane Israël. Un consejo consultivo compuesto exclusivamente por ciudadanos de la UE, que incluye a dos representantes independientes externos, proporciona supervisión y experiencia adicional en materia de soberanía. Mejor control y residencia de datos La AWS European Sovereign Cloud ofrece amplias garantías de residencia de datos para que pueda cumplir los requisitos más estrictos en materia de residencia de datos.Al igual que ocurre con nuestras regiones de AWS existentes en todo el mundo, todo el contenido permanece dentro la región que elija, a menos que decida lo contrario.Además del contenido, los metadatos creados por los clientes, incluidos los roles, los permisos, las etiquetas de recursos y las configuraciones, también permanecen dentro de la UE.La infraestructura cuenta con su propio sistema dedicado de AWS Identity and Access Management (AWS IAM) y facturación, que funciona de forma independiente dentro de las fronteras europeas. Los controles técnicos integrados en la infraestructura impiden el acceso a la AWS European Sovereign Cloud desde fuera de la UE .La infraestructura incluye un proveedor de servicios de confianza europeo dedicado para las operaciones de las autoridades de certificación y utiliza servidores de nombres de Amazon Route 53 dedicados.Estos servidores solo usarán dominios de nivel superior europeos para sus propios nombres .La AWS European Sovereign Cloud no tiene dependencias críticas de personal o infraestructura fuera de la UE. Marco de seguridad y cumplimiento La AWS European Sovereign Cloud mantiene las mismas capacidades de seguridad básicas que cabe esperar de AWS, como el cifrado, la administración de claves, la gobernanza del acceso y AWS Nitro System para el aislamiento de la computación.Esto significa que sus instancias de EC2 se benefician de la integridad de la plataforma verificada criptográficamente y de los límites impuestos por el hardware que impiden el acceso no autorizado a sus datos sin comprometer el rendimiento, lo que le proporciona tanto los controles de soberanía como la potencia computacional que requieren sus cargas de trabajo.La infraestructura se somete a auditorías independientes externas , con programas de cumplimiento que incluyen la norma ISO/IEC 27001:2013, informes SOC 1/2/3 y la certificación C5 de la Oficina Federal de Seguridad de la Información . El marco de referencia de soberanía de la AWS European Sovereign Cloud define los controles de soberanía específicos en relación con la independencia de la gobernanza, el control operativo, la residencia de datos y el aislamiento técnico.Este marco está disponible en AWS Artifact y proporciona visibilidad total a través de la certificación SOC 2. Disponibilidad total del servicio Puede acceder a una amplia variedad de servicios de AWS en la AWS European Sovereign Cloud desde su lanzamiento, incluidos Amazon SageMaker y Amazon Bedrock para cargas de trabajo de inteligencia artificial y machine learning.Para el procesamiento, puede usar Amazon Elastic Compute Cloud (Amazon EC2) y AWS Lambda .La orquestación de contenedores está disponible a través de Amazon Elastic Kubernetes Service (Amazon EKS) y Amazon Elastic Container Service (Amazon ECS) .Los servicios de bases de datos incluyen Amazon Aurora , Amazon DynamoDB y Amazon Relational Database Service (Amazon RDS) .Dispone de opciones de almacenamiento como Amazon Simple Storage Service (Amazon S3) y Amazon Elastic Block Store (Amazon EBS) , con redes a través de Amazon Virtual Private Cloud (Amazon VPC) y servicios de seguridad como AWS Key Management Service (AWS KMS) y AWS Private Certificate Authority .Para obtener una lista actualizada de los servicios, consulte la matriz de capacidades de AWS que se ha publicado recientemente en AWS Builder Center. La AWS European Sovereign Cloud cuenta con el respaldo de los socios de AWS , que se comprometen a ayudarle a cumplir sus requisitos de soberanía.Socios como Adobe, Cisco, Cloudera, Dedalus, Esri, Genesys, GitLab, Mendix, Pega, SAP, SnowFlake, Trend Micro y Wiz ofrecen sus soluciones en la AWS European Sovereign Cloud, lo que le proporciona las herramientas y los servicios que necesita en materia de seguridad, análisis de datos, desarrollo de aplicaciones y cargas de trabajo específicas del sector.Este amplio apoyo de los socios le ayuda a crear soluciones soberanas que combinan los servicios de AWS con tecnologías de socios de confianza. Inversión importante. en la infraestructura europea La AWS European Sovereign Cloud está respaldada por una inversión de 7.800 millones de EUR en infraestructura, creación de empleo y desarrollo de habilidades.Se espera que esta inversión aporte 17.200 millones de EUR a la economía europea para 2040 y ayude a crear el equivalente a aproximadamente 2.800 puestos de trabajo a tiempo completo por año en empresas locales. Algunos detalles técnicos La AWS European Sovereign Cloud está disponible para todos los clientes, independientemente de dónde se encuentren.Puede acceder a la infraestructura utilizando el nombre de partición aws-eusc y el nombre de región eusc-de-east-1.Una partición es un grupo de regiones de AWS.Cada cuenta de AWS tiene limitado su alcance a una sola partición. La infraestructura admite todos los métodos de acceso estándar de AWS, como la Consola de administración de AWS , los AWS SDK y la Interfaz de la línea de comandos de AWS (AWS CLI) , lo que facilita la integración en sus flujos de trabajo y automatización existentes.Tras crear una nueva cuenta raíz para la partición de la AWS European Sovereign Cloud, primero deberá crear nuevas identidades y roles de IAM específicos para esta infraestructura, lo que le permitirá tener un control total sobre la administración del acceso en el entorno soberano europeo. Cómo empezar La AWS European Sovereign Cloud proporciona a las organizaciones europeas controles de soberanía mejorados, al tiempo que mantiene el acceso a la innovación y las capacidades de AWS.Puede contratar los servicios a través de Amazon Web Services EMEA SARL, con precios en EUR y facturación en cualquiera de las ocho divisas que admitimos actualmente .La infraestructura utiliza la arquitectura, la cartera de servicios y las API habituales de AWS, lo que facilita la creación y la migración de aplicaciones. La adenda de la AWS European Sovereign Cloud contiene los compromisos contractuales adicionales para la AWS European Sovereign Cloud. Para mí, como europeo, este lanzamiento representa el compromiso de AWS de satisfacer las necesidades específicas de nuestro continente y proporcionar las capacidades en la nube que impulsan la innovación en todos los sectores.Le invito a descubrir más sobre la AWS European Sovereign Cloud y cómo puede ayudar a su organización a cumplir sus requisitos de soberanía.Lea la descripción general de la AWS European Sovereign Cloud para obtener más información sobre los objetivos y el enfoque del diseño, regístrese para obtener una nueva cuenta y planifique hoy mismo el despliegue de su primera carga de trabajo. – seb

エージェントが IDE のエラーを見逃す理由 初期のコーディングエージェントには大きな問題がありました。AI が生成したコードは一見正しく見えても、IDE が検出したエラーがエージェントには見えないのです。エージェントは追加のツールを実行しない限り、これらのエラーを認識できませんでした。その結果、エージェントは自信を持って次のタスクに進む一方で、コードベースには技術的負債が蓄積されていきました。 これは、診断情報を活用していないコーディングエージェントに共通する根本的な課題です。 現代の IDE のほとんどは、リアルタイムでエラーを検出する高度な言語解析ツールを継続的に実行しています。しかし、エージェントがこの豊富な情報に効率的にアクセスできなければ、コード検証のために（コストのかかる）ビルド/テストコマンドを実行せざるを得ません。これは実行速度が遅く、トークンを消費し、開発環境がすでに提供している詳細なフィードバックを見逃してしまいます。結果として、必要以上にリソースを消費するコード検証プロセスになってしまうのです。 診断情報なしでコードを生成するコスト エージェントが IDE の診断情報を参照できない場合、品質向上のための反復改善ができません。代わりに、正しいと思われるコードを生成して次のタスクに進んでしまいます。その結果、開発者がエージェントの品質保証を担うことになります。型エラーの手動修正（例：実際のプロパティは user.name なのに user.getName() を呼び出している）、不足しているインポートの追加（ Button を使用しているのに import { Button } from '@/components/ui/button' を忘れている）、リンティング違反の解決（未使用の変数、一貫性のないインデント）などです。これは開発速度を低下させるだけでなく、エージェントが生成したコードへの信頼を損なう結果にもつながります。 Kiro におけるフィードバックループの完結 現代の IDE は、高度な言語解析インフラストラクチャで動作しています。言語サーバーがコードベースをリアルタイムで解析します。例えば、TypeScript 拡張機能は型チェックを実行し、ESLint はコードスタイルを検証し、Java 拡張機能は即座にコンパイルフィードバックを提供します。また、CloudFormation や Terraform の拡張機能は、デプロイ前にリソースプロパティ、必須引数、リソース参照などのインフラストラクチャ設定を検証します。 この解析はコーディング中に継続的に実行され、エラーを 診断情報 として表示します。エディタで見る赤い波線や問題マーカーがそれです。これらの診断情報は、コードの正確性に関する即座で正確なフィードバックの貴重な情報源となっています。 しかし、初期の AI コーディングアシスタントは、この情報にアクセスできませんでした。代わりに、ビルドコマンド（ npm run build 、 npm test など）を実行してコードを検証していましたが、1 回の実行に数秒から数分かかることもありました。 仕様駆動開発を通じて AI コーディングに構造をもたらすエージェント型 IDE である Kiro では、エージェントに IDE 診断情報への直接アクセスを提供することで、この課題を解決しました。現在、Kiro がコードを書くと、開発者が見るのと同じエラーを即座に確認し、レビュー前に修正できます。コード品質への影響は顕著で、手動修正が減り、プロジェクトの品質基準への準拠が向上しました。Kiro のコーディングエージェントは、これらのクライアント側の診断情報と緊密に統合され、コードの理解と生成の両方を強化します。IDE を動かすのと同じ言語サーバーへの接続を通じて、エージェントはコンパイル時エラー、型警告、リンティング結果をリアルタイムで読み取り、解釈できるようになりました。Kiro がコードを生成または変更すると、この診断情報を参照して正確性を検証します。例えば、Java の不足しているシンボルや Python の構文エラーを検出し、そのフィードバックに基づいて出力を自動的に改善できます。 ワークフローの比較 従来のアプローチは、遅い反復サイクルを繰り返します。エージェントがコードを生成し、時間のかかるビルド（および/またはテスト）コマンドを実行します。ビルドがエラーで失敗すると、エージェントは修正を生成し、再度ビルドコマンドを実行します。この重いプロセスは、ビルドが成功するまで繰り返されます。 診断駆動型アプローチははるかに高速です。コード生成後、エージェントは 35 ミリ秒未満で診断情報をチェックします。行番号と説明を含む具体的なエラーが提供されます。エージェントはターゲットを絞った修正を生成し、さらに 35 ミリ秒で診断を介して検証してから、検証済みのコードで続行します。 時間差は、複数ステップのタスクで複合的に拡大します。仕様駆動開発では、Kiro が数十のタスクを実装する際、診断ツールは vibe-coding モードと比較して約 4 倍の頻度で呼び出されます。これは、各タスクの境界で受け入れ基準が満たされていることを確認する必要があるためです。これにより、実装プロセス全体を通じて継続的な検証が実現されます。 実際の効果 本番環境での使用と制御されたベンチマークを通じて、診断統合の効果を測定しました。結果は、測定可能なコード品質の向上とともに、大幅な効率改善を示しています。効率面では、ビルド/テストコマンドの削減により、コマンド実行が 29% 削減されました。この指標は、診断機能の導入前後の数日間にわたる本番環境でのエージェントのインタラクション統計を比較することで算出されました。エンドツーエンドのレイテンシを削減しながら、コード品質が向上しました。 言語に依存しないアーキテクチャ 診断システムの強みは、その汎用性にあります。各言語用にカスタム解析を構築するのではなく、Kiro は、すでに多数の IDE 機能を支えている Language Server Protocol（LSP）と拡張 API を活用しています。本番環境のデータは、これが多様な技術スタックで機能することを実証しています。例えば、TypeScript、Python、Rust などの汎用言語や、SQL、YAML、GraphQL などのドメイン固有言語の 人気のある拡張機能 は、型チェックとリンティング情報を提供します。さらに、主要なビルドツール（Maven、Make、Cargo など）やプログラマティック設定ファイル（Terraform、Kubernetes YAML、Dockerfile など）の拡張機能により、セットアップとデバッグの体験が向上します。 活用シナリオ 本番環境での使用分析により、診断ツールが既存または新規生成されたコードの品質を向上させる一般的なパターンが明らかになりました。 シナリオ 1 [構文エラー]： 分析用の Python コードベースで、エージェントがウィンドウ集計の新機能を実装します。 診断ツールは、正規表現エラー（ missing ), unterminated subpattern at position 13 ）を発見し、エージェントが修正します。再検証により、エラーが解消されたことが確認されます。診断ツールがない場合、エージェントはコマンドラインでテストを作成・実行して問題をチェックする必要があります。 シナリオ 2 [ハルシネーションの回避]： TypeScript コードベースで、Kiro がコンポーネントに変更を加え、即座に検証します。 診断ツールは、即座に 2 つの 型の不一致 （ Type 'number' is not assignable to type 'string' と Cannot assign to read-only 'executionTime' ）と プロパティのハルシネーション （ Property 'itemAge' does not exist on type 'StackProps' ）を報告します。これらの問題を基に、エージェントは修正を生成し、変更を再検証します。このパターン（生成 → 検証 → 改善）は、型エラーが一般的ですが言語サーバーで簡単に検出できる静的型付け言語で頻繁に見られます。 シナリオ 3 [型検証]： Swift プロジェクトで、Kiro が新しい機能を追加し、編集されたファイルの診断をチェックします。 診断により、ファイルの 1 つに 型エラー があることが判明します。エージェントは問題を修正し、影響を受けたファイルを再検証して、修正が正しいことを確認します。 シナリオ 4 [Infrastructure as Code — IaC]： 診断検証は、アプリケーションコードを超えて機能します。ユーザーが Kiro に Terraform 設定 のチェックを依頼します。 これは、診断システムが従来のプログラミング言語だけでなく、ドメイン固有言語や設定フォーマットでも機能することを示しています。 エージェント開発のメリット コード生成とコード検証を統合することで、診断ツールは次の改善を実現します： 認知負荷の軽減： AI が生成したコードを手動で検証する時間が減ります。Kiro が「診断エラーなし」と報告すると、開発者はより高い信頼性を持って作業を続行できます。 高速な反復： bash コマンドの実行頻度の削減は、具体的な時間の節約につながります。 コード品質の向上： 問題が発生した時点で即座に対処することで、よりクリーンで高品質なコードが実現します。 まとめ IDE 診断情報は、コード検証のための重要な即時フィードバックの源です。診断情報を Kiro のエージェントワークフローに直接統合することで、初期のコーディングエージェントが抱えていたコード生成と検証の間のギャップを解消しました。 結果は明確です。コマンド実行の削減、高速な検証サイクル、多様な技術スタックにわたるコード品質の向上を実現しました。エージェントに遅くてコストのかかるビルド/テストコマンドに依存させるのではなく、Kiro は、すでに現代の IDE を支えている高度な言語解析インフラストラクチャを活用します。TypeScript の型チェックから Terraform の設定検証まで幅広く対応しています。 この診断駆動型アプローチは、エージェントのフィードバックループを高速化します。盲目的にコードを生成して動作を期待するのではなく、Kiro は開発者が見るのと同じエラーを確認し、積極的に修正します。結果として、手動修正が少なく、開発者の信頼を得られるコードが実現します。 この違いを体験する準備はできましたか？ Kiro を無料で始めて 、診断機能を備えたエージェントが開発ワークフローをどのように変革するかを確認してください。 Discord のコミュニティに参加して、フィードバックを共有し、質問をし、AI 支援コーディングで開発している他の開発者とつながりましょう。 謝辞 クレジット（アルファベット順）：Al Harris、Nathan Jones、Nikhil Swaminathan、Siwei Cui、Varun Kumar

Kiro を最初にローンチしたとき、私たちは初期ユーザーの一部を困惑させる意図的な決断を下しました。「すべてのタスクを一括実行」ボタンを実装しなかったのです。各タスクの後に必ずエージェントと確認する必要がありました。これは見落としではありません。意図的な設計でした。 スピードとコントロールの間の緊張 「なぜ仕様のすべてのタスクを一度に実行できないのか？」は、6 か月前のローンチ後に最も多く寄せられた質問の 1 つでした。このリクエストは理にかなっていました。仕様には 5 個、10 個、時には 20 個以上のタスクが含まれることがよくあります。それぞれを個別にクリックするのは面倒に感じられました。エージェントは、できるだけ手を離せるようにするためのものではないのでしょうか？はい、でもいいえでもあります。 Kiro における私たちの基本的な考え方は、開発者が可視性とコントロールを維持することで AI 開発が最も効果的に機能するというものです。何が起こっているかを確認し、各タスクの実行を理解し、問題を早期に発見してほしかったのです。その対極にある選択肢、つまりコーヒーを取りに行っている間に AI がコードベース全体を自動実行するというのは、無謀に思えました。内部テストでは、エージェントが自律的にうまく機能するケースもありましたが、失敗するケースもあり、その場合ユーザーは問題の発生箇所を特定し、修正するために多くの時間を費やすことになりました。 そこで私たちはノーと言いました。そして、リクエストが積み重なってもノーと言い続けました。 まず基盤を構築する ユーザーの要望を急いで実装する代わりに、私たちは「すべて実行」を本当に 安全 にするための基盤構築に集中しました。過去数か月間、Kiro の信頼性を根本的に向上させる一連の機能を着実にリリースしてきました。 プロパティベーステスト（PBT） – 「このタスクは私が望むことをしているか？」 ：コードが実行されるだけでなく、仕様の要件を満たしていることを検証するプロパティベーステストを生成するようになりました。これらは単純なユニットテストではありません。コードがさまざまな入力にわたって正しく動作することを保証する不変条件チェックです。PBT により、エージェントは次に進む前に、タスクの実装が期待どおりに動作することを確認できます。 開発サーバー と LSP 診断 – 「実装は実際に機能するか？」 ：タスクが実行中のサーバーに対してテストされ、言語サーバー診断で分析される実際の検証環境です。コードは、ランタイムの動作と静的な正確性の両方について検証され、メインブランチに到達する前に問題をキャッチします。 サブエージェント – 「エージェントはコンテキストの腐敗に迷うことなく軌道に乗り続けるか？」 ：独自のローカルコンテキストを維持しながら、特定のタスクを処理する特殊なエージェントです。メインエージェントが仕様を進めるにつれて、サブエージェントはコンテキスト管理を分散して集中させることで、過負荷になるのを防ぎます。 これらの機能を組み合わせることで、Kiro はコードを 生成 するツールから、コードを 検証 するツールへと変貌しました。これにより、複数のタスクを実行することが単に高速であるだけでなく、安全であるという確信が得られました。 すべてのタスクを一括実行：ついに利用可能に 本日、皆さんが求めていたものを公開します。1 回のクリックで仕様のすべてのタスクを実行する機能です。この機能は、皆さんが求めていたものの精神に従っていますが、私たちの実装により、必要なだけ頻繁に使用できる自信が得られます。 「すべてのタスクを実行」を押すと、単にコードをより速く実行するだけではありません。検証の試練を通してコードを実行します。 各タスクの出力は、プロパティベーステスト（PBT）に対して検証されます コードは開発サーバーに対して検証され、LSP 診断でチェックされます サブエージェントは、集中したローカルコンテキストを維持するため、メインエージェントは仕様全体で効果的に機能し続けます 各ステップで何が起こっているかをリアルタイムで確認できます 結果は？慎重に監視された開発の信頼性を備えた自動実行のスピードが得られます。 これは、エージェントを手取り足取り導きたくない小規模な機能仕様に最適だと考えています。そして、いつものように、プロンプトに基づいて Kiro が考え出した仕様を事前に少し時間をかけて検証することで、実際に必要なコードをより速く全体的に公開できるようになります。 「すべてのタスクを実行」は、単に追加したボタンではありません。これは、バッチ実行を実際に信頼できるものにするための数か月の作業の集大成であり、事後により複雑な混乱を修正する必要なく、タスクを実行しながら時間と労力を節約できます。 「すべてのタスクを実行」は、現在すべての Kiro ユーザーが利用できます。 次の仕様で試して 、 ご意見をお聞かせください 。

AWS re:Invent 2025 での プレビューリリース でお知らせしたとおり、メモリ最適化された新しい Amazon Elastic Compute Cloud (Amazon EC2) X8i インスタンスが一般提供されることを発表します。これらのインスタンスは、AWS でのみ利用可能な 3.9 GHz の持続的なオールコアターボ周波数を備えたカスタム Intel Xeon 6 プロセッサを搭載しています。これらの SAP 認定インスタンスは、クラウドにおける同等の Intel プロセッサの中でも最高のパフォーマンスと最速のメモリ帯域幅を提供します。 X8i インスタンスは、高いコンピューティングパフォーマンスと大規模なメモリフットプリントを必要とする SAP HANA などのインメモリデータベース、従来の大規模データベース、データ分析、Electronic Design Automation (EDA) など、メモリを大量に消費するワークロードに最適です。 これらのインスタンスは、前世代の X2i インスタンス と比較して 1.5 倍のメモリ容量 (最大 6 TB) と 3.4 倍のメモリ帯域幅を提供します。また、これらのインスタンスは X2i インスタンスと比較して最大 43% 高いパフォーマンスを実現し、一部の実際のワークロードではより高いパフォーマンスを発揮します。SAP Application Performance Standard (SAPS) のパフォーマンスが最大 50%、PostgreSQL のパフォーマンスが最大 47%、Memcached のパフォーマンスが最大 88%、AI 推論のパフォーマンスが最大 46% 向上します。 プレビュー中、 RISE with SAP などのお客様は、最大6 TB のメモリ容量を活用し、X2i インスタンスと比較してコンピューティングパフォーマンスが 50% 向上しました。これにより、SAP HANA ワークロードのトランザクション処理が加速し、クエリ応答時間が短縮されました。 Orion は、パフォーマンスのしきい値を維持しながら、X2idn インスタンスと比較して X8i インスタンスのアクティブコア数を削減し、SQL Server のライセンスコストを 50% 削減しました。 X8i インスタンス X8i インスタンスでは、3 つの大きいインスタンスサイズ ( 48xlarge 、 64xlarge 、 96xlarge ) を含む 14 のサイズが用意されているため、アプリケーションのスケールアップに適したサイズを選択できます。また、物理リソースに直接アクセスできるワークロードをデプロイするために 2 つのベアメタルサイズ ( metal-48xl と metal-96xl ) を選択できます。X8i インスタンスは、 Elastic Fabric Adapter (EFA) のサポートによる最大 100 Gbps のネットワーク帯域幅と、 Amazon Elastic Block Store (Amazon EBS) への最大 80 Gbps のスループットを備えています。 X8i インスタンスの仕様は次のとおりです。 インスタンス名 vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) x8i.large 2 32 最大 12.5 最大 10 x8i.xlarge 4 64 最大 12.5 最大 10 x8i.2xlarge 8 128 最大 15 最大 10 x8i.4xlarge 16 256 最大 15 最大 10 x8i.8xlarge 32 512 15 10 x8i.12xlarge 48 768 22.5 15 x8i.16xlarge 64 1,024 30 20 x8i.24xlarge 96 1,536 40 30 x8i.32xlarge 128 2,048 50 40 x8i.48xlarge 192 3,072 75 60 x8i.64xlarge 256 4,096 80 70 x8i.96xlarge 384 6,144 100 80 x8i.metal-48xl 192 3,072 75 60 x8i.metal-96xl 384 6,144 100 80 X8i インスタンスは、他の第 8 世代インスタンスタイプと同じく インスタンス帯域幅設定 (IBC) 機能をサポートしており、ネットワークと EBS 帯域幅の間でリソースを柔軟に割り当てることができます。ネットワークまたは EBS の帯域幅を最大 25% まで拡張できるため、データベースのパフォーマンス、クエリ処理速度、ログ記録効率が向上します。これらのインスタンスは第 6 世代の AWS Nitro Card を使用しており、CPU の仮想化、ストレージ、ネットワーキング機能を専用のハードウェアとソフトウェアにオフロードし、ワークロードのパフォーマンスとセキュリティを強化します。 今すぐご利用いただけます Amazon EC2 X8i インスタンスは現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (フランクフルト) の AWS リージョン でご利用いただけます。リージョンの提供状況と今後のロードマップについては、 [リージョン別の AWS 機能] の [CloudFormation リソース] タブでインスタンスタイプを検索してください。 これらのインスタンスは、 オンデマンドインスタンス 、 Savings Plans 、 スポットインスタンス として購入できます。詳細については、 Amazon EC2 の料金ページ をご覧ください。 Amazon EC2 コンソール でぜひ X8i インスタンスをお試しください。詳細については、 Amazon EC2 X8i インスタンスのページ をご覧ください。また、 AWS re:Post for EC2 に、あるいは通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

私は年初に、その年の最も重要な抱負を設定するようにしています。自分が達成したいことに集中するためです。AI とクラウドコンピューティングが抱負リストに含まれている場合、 AWS 無料利用枠 アカウントを作成して、最大 200 USD のクレジットを受け取り、6 か月間リスクなしで AWS サービスを試すことをご検討ください。 この期間中は、コンピューティング、ストレージ、データベース、AI/ML にまたがる重要なサービスを利用できるほか、毎月の使用制限内で 30 以上の常時無料のサービスにアクセスできます。6 か月後に、スタンダード AWS アカウントにアップグレードするかどうかを決定できます。 キャリアの選択肢を模索している学生も、スキルセットを拡大している開発者も、クラウドテクノロジーを使用し構築を行っているプロフェッショナルも、この実践的なアプローチにより、最も重要なこと、つまり自分が情熱を注いでいる分野で真の専門知識を育むことに集中できます。 1 月 5 日週のリリース 私が 1 月 12 日週に注目したリリースをご紹介します。 AWS Lambda – .NET 10 をマネージドランタイムとコンテナベースイメージの両方として使用するサーバーレスアプリケーションの作成のサポート を開始しました。更新が利用可能になり次第、AWS はマネージドランタイムとベースイメージに自動的に更新を適用します。 このブログ記事 で詳細をご覧ください。 Amazon ECS – EC2 起動タイプに加えて、 AWS Fargate および Amazon ECS マネージドインスタンスで実行されている Linux タスクに tmpfs マウントのサポート を追加しました。tmpfs を使用すると、タスクストレージにデータを書き込むことなく、コンテナ化されたワークロード用のメモリバックアップのファイルシステムを作成できます。 AWS Config – Amazon EC2、Amazon SageMaker、Amazon S3 Tables などの主要なサービス全体で、 追加の AWS リソースタイプ を発見、評価、監査、修正できるようになりました。 Amazon MQ – RabbitMQ ブローカー向けに HTTP ベースの認証を導入 しました。このプラグインは、関連する構成ファイルを変更することでブローカーに設定できます。また、RabbitMQ ブローカー向けの 相互 TLS を使用した証明書ベースの認証のサポート を開始しました。 Amazon MWAA – Amazon Managed Workflows for Apache Airflow (MWAA) を使用して Apache Airflow バージョン 2.11 環境を作成 できるようになりました。このバージョンの Apache Airflow には、Apache Airflow 3 へのアップグレードの準備に役立つ変更が導入されています。 Amazon EC2 – M8i 、 C8i と C8i-Flex 、 R8i と R8i-Flex 、 I7ie のインスタンスを、他の AWS リージョンでも利用 できるようになりました。 AWS Client VPN – 新しいクイックスタートにより、クライアント VPN エンドポイントのセットアップに必要なステップの数を削減 しました。 Amazon Quick Suite – AI エージェント向けの統合を、組み込みアクションライブラリに追加 しました。例えば、これらには現在、GitHub、Notion、Canva、Box、Linear、Hugging Face、Monday.com、HubSpot、Intercom などが含まれます。 その他のアップデート その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 AWS Transform を使用した AWS SDK for Java v1 から v2 へのアップグレードの自動化 – 手動による介入や潜在的なエラーを最小限に抑えながら、Java アプリケーションの効率的なモダナイズをサポートします。 AWS Advanced JDBC Wrapper を使用して標準 JDBC ドライバーで Amazon Aurora の高度な機能を活用 – オープンソースの標準 JDBC ドライバーを使用する既存のアプリケーションを強化し、最小限のコード変更で Aurora と AWS クラウドの機能を活用できます。 Amazon Aurora DSQL のマルチリージョンエンドポイントルーティングの実装 – 手動で設定を変更することなく、データベーストラフィックを別のリージョンのエンドポイントにリダイレクトする自動ソリューションです。 Amazon Nova マルチモーダル埋め込みを使用したクロスモーダル検索 – 埋め込みの生成、クエリの処理、パフォーマンスの測定を行うことで、クロスモーダル検索システムを実装する方法です。実用的なコード例とこれらの機能をアプリケーションに追加するためのヒントをご紹介します。 今後の AWS イベント 1 月 28 日または 29 日 (タイムゾーンによって異なります) に Best of AWS re:Invent にご参加ください。これは、AWS re:Invent での最も影響力が大きい発表と上位セッションをお届けする無料のバーチャルイベントです。オープニングセッションでは、AWS VP 兼 Chief Evangelist の Jeff Barr がハイライトをご紹介します。 1 月 21 日まで、25 万 USD の賞金と AWS クレジットを獲得できる Global 10,000 AIdeas Competition にご参加いただけます (「AIdeas」の「I」は「Idea」の「I」で、小文字の「l (L)」ではありません)。コードはまだ必要ありません。アイデアを送信するだけです。セミファイナリストに選ばれた場合は、 AWS 無料利用枠 の範囲内で Kiro を使用してアプリを構築します。 AWS re:Invent 2026 での賞金獲得や注目の出展の可能性だけでなく、次世代 AI ツールの実地経験を積み、世界中のイノベーターとつながることができます。 これらの機会にご興味がおありの場合は、 AWS Builder Center に参加して AWS コミュニティのビルダーと一緒に学びましょう。 1 月 12 日週のニュースは以上です。1 月 19 日週の Weekly Roundup もお楽しみに! – Danilo 原文は こちら です。

本ブログは 株式会社デジナーレ 様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。ソリューションアーキテクト 伊勢田氷琴です。 セキュリティ脆弱性への対応は、現代のソフトウェア開発において避けて通れない重要な業務です。しかし、日々公開される膨大な脆弱性情報を収集し、自社システムへの影響を分析する作業は、多くの企業にとって大きな負担となっています。この記事では、株式会社デジナーレ様が Amazon Bedrock 、 Strands Agents 、 Amazon Bedrock AgentCore Runtime を活用して、脆弱性情報の収集から分析、レポート作成までを完全自動化したシステムを構築した事例をご紹介します。 多くの企業が直面するセキュリティ脆弱性管理の課題 株式会社デジナーレは、新サービス・UI 企画開発、UI プロトタイピング、自社事業展開を手がける企業です。同社では、自社で開発・運用するシステムのセキュリティを維持するため、日々公開される脆弱性情報を継続的に監視する必要がありました。 従来の脆弱性管理プロセスでは、エンジニアが複数の脆弱性情報サイトを手動で巡回し、関連する情報を収集・分析していました。この作業には毎日数時間が必要で、特に重要な脆弱性が公開された際には、迅速な対応が求められるため、担当者の負担は大きなものでした。また、情報の見落としや分析の遅れが、セキュリティリスクの増大につながる可能性もありました。 デジナーレ様が構築した脆弱性情報自動収集システムは、これらの課題を解決し、エンジニアが本来の開発業務に集中できる環境を実現しました。 生成 AI エージェントによる自動化を選択した理由 デジナーレ様は、この課題を解決するために、生成 AI エージェント技術の活用を検討しました。AWS を選択した理由は以下の通りです。 まず、Amazon Bedrock が提供する高性能な基盤モデルにより、複雑な脆弱性情報の理解と分析が可能になると判断しました。特に Claude などのモデルは、技術文書の読解と要約に優れた性能を発揮します。 次に、Strands Agents フレームワークの存在が大きな決め手となりました。Strands Agents は、複雑なエージェントループやツール利用の実装を抽象化し、開発者が本質的なビジネスロジックに集中できる環境を提供します。特に Agent Workflows 機能により、複数のエージェントを協調させた段階的な処理を簡潔に実装できる点が魅力的でした。 さらに、AgentCore Runtime により、開発したエージェントを AWS クラウド上に迅速かつセキュアにデプロイできることも重要なポイントでした。サーバーレスアーキテクチャにより、運用負荷を最小限に抑えながら、スケーラブルなシステムを構築できます。 ソリューションの概要 デジナーレ様が構築したシステムは、脆弱性情報の自動収集エージェントを中心に、フロントエンドとバックエンドで構成されています。 システム全体は、 AWS Lambda 、 Amazon DynamoDB 、 Amazon Cognito 、 Amazon S3 、 Amazon CloudFront 、 Amazon API Gateway で構成されています。フロントエンドは S3 と CloudFront から配信され、バックエンドは Lambda 関数と API Gateway で構成されます。過去の調査ログやレポートは DynamoDB に保存され、いつでも参照可能です。 図1: 脆弱性情報収集システムのアーキテクチャ Strands Agents で実装したエージェントは AgentCore Runtime にデプロイされており、定時実行により前日に公開された脆弱性情報を自動的に収集・分析します。 協調する 3 つの AI エージェントによる段階的処理 脆弱性情報収集エージェントは、Strands Agents の Agent Workflows 機能を使用して実装された 3 段階のワークフローで構成されています。この設計により、脆弱性調査という定型作業を再現性のある「決定的なワークフロー（Deterministic Workflow）」に迅速に落とし込むことができました。 図2: 調査、執筆、校正の3段階で構成されるエージェントワークフロー 図2に示すように、システムは以下の3つのエージェントで構成されています。 第1段階：調査エージェント エントリーポイントとなる調査エージェントは、以下の3つのツールを持っています。 RSS ツール ：複数の脆弱性公表サイトを RSS として登録し、最新情報を取得 脆弱性対応状況検索ツール ：各脆弱性への対応状況を調査 Web 検索ツール ：関連情報を補完的に取得 これらのツールを組み合わせることで、脆弱性情報を体系的に調査します。 第2段階：執筆エージェント 調査結果は、次の執筆エージェントにコンテキストとして渡されます。執筆エージェントはファイル編集ツールを持った編集特化のエージェントであり、指定された形式で読みやすいレポート記事を作成します。 第3段階：校正エージェント 最後に、執筆エージェントの出力を校正エージェントが確認します。事前に指定した要件に合致しているかを判定し、例えば報告内容の脆弱性が既に対応済みであったり、古い情報を参照している場合には、調査エージェントにフィードバックして再調査・再作成を行います。 このフィードバックループにより、常に最新かつ正確な情報がレポートに含まれることが保証されます。 調査業務の完全自動化による業務変革 このシステムの導入により、デジナーレ様は大きな成果を得ることができました。 開発者の業務効率化 最も顕著な効果は、脆弱性情報の調査にかかる時間の削減です。Strands Agents と AgentCore Runtime により、従来は担当者が毎日数時間を費やしていた調査作業が、事実上ゼロ時間になりました。エンジニアは、システムが自動生成したレポートを確認し、必要な対応を判断するだけで済むようになったのです。 また、情報収集の網羅性と即時性も向上しました。人手による巡回では見落としの可能性がありましたが、自動化により複数のソースから漏れなく情報を収集できるようになりました。さらに、定時実行により、毎朝最新の脆弱性情報がレポートとして用意されているため、迅速な対応判断が可能になりました。 生成されるレポートの品質 システムが自動生成するレポートは、セキュリティ担当者が必要とする情報を網羅的かつ簡潔にまとめています。 図3: システムが自動生成した脆弱性情報レポートのサンプル 図3に示すように、生成されるレポートには以下の特徴があります。 脆弱性の詳細情報 ：CVE 番号、影響を受けるバージョン、公開日などの基本情報が明確に記載 影響範囲の可視化 ：リスクの説明が色分けにより強調され、一目で重要度を把握可能 対応方針の明示 ：SDK のアップデート手順など、具体的な解決策がチェックリスト形式で提示 一次情報へのアクセス ：参照リンクが記載されており、詳細な技術情報への導線を確保 このように構造化された情報提示により、セキュリティ担当者は必要な情報に素早くアクセスし、適切な対応判断を下すことができます。 システムによる価値提供 レポート品質の向上は、Strands Agents の複数の特性が複合的に作用した結果です。エージェントの動作を完全に制御でき、カスタムツール（RSS、Web検索、ファイル編集など）を確実に統合でき、基盤モデルを各段階に最適なものに選択できるという特性により、3段階のワークフローで情報の収集、整理、検証が体系的に行われ、常に一定の品質を保ったレポートが生成されるようになりました。 組織への展開と影響 このソリューションは、デジナーレ様のグループ会社にも展開され、セキュリティ担当者を中心に約 10 名のメンバーに活用されています。各社のセキュリティ担当者が同じフォーマットのレポートを参照することで、グループ全体でのセキュリティ対応の標準化と効率化が実現されました。 生成 AI エージェント活用の今後の展開 デジナーレ様は、今回の成功を踏まえて、生成 AI エージェント技術のさらなる活用を検討しています。 脆弱性情報収集システムについては、現在は取得する一次情報のソースが固定化されているため、特定の情報が取得できないケースがあります。今後は、アカウント単位で取得元をカスタマイズできる機能の実装を予定しています。また、デフォルトの一次情報取得元を増やすとともに、より広範なネットワーク検索を行う仕組みの実装も検討しています。 Strands Agents と AgentCore Runtime の組み合わせにより、エージェント開発から本番運用までのサイクルが短縮されたことで、新しいアイデアを迅速に試すことができる環境が整いました。 お客様の声 本システムの開発を主導した安原氏（役職 x）は、今回の開発を振り返り次のようにコメントしています。 「Strands Agents を使用したシステムの構築を初めて行いましたが、様々な可能性を感じています。Strands Tools やオリジナルのツールを使って AI エージェントの動作を担保できる点が、今までとは違います。ワークフローでそれぞれのエージェントに専門性を持たせることによって、より精度の高いものが出来上がっていると感じました。」 まとめ デジナーレ様の事例は、Strands Agents と AgentCore Runtime を活用することで、複雑な業務プロセスを効果的に自動化できることを示しています。 特に注目すべき点は、Agent Workflows による段階的な処理の実装により、調査、執筆、校正という明確な役割分担を持つエージェント群を構築できたことです。これにより、各エージェントの責務が明確になり、保守性の高いシステムを実現しています。 脆弱性管理をはじめとするセキュリティ業務の自動化は、多くの企業にとって重要な課題です。生成 AI エージェント技術は、こうした課題に対する有力な解決策となり得ます。 株式会社デジナーレ：CTO 津村 忠助様（左）、SE 安原 大喜様 様（右） ソリューションアーキテクト 伊勢田氷琴

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。今年の目標は Kiro にどんどん業務をオフロードしていくことです。まずは Kiro powers を作るための Power Builder power に入門してみようと思います。 それでは、1 月 12 日週の生成 AI with AWS界隈のニュースを見ていきましょう。昨年実施したイベントの報告やBedrock のコスト分析を楽にするアップデートなどさまざまなアップデートが発表されております。 さまざまなニュース ブログ記事「 弥生株式会社様の AI-DLC Unicorn Gym 開催レポート: 開発プロセスの再設計による生産性の限界突破への挑戦 」を公開 弥生株式会社様とAWS Japanが共同で実施したAI-DLC Unicorn Gymの実践レポートです。2025年12月10日から12日の3日間、実際のプロダクトを対象にAI-DLC（AI駆動開発ライフサイクル）を実践し、通常1ヶ月以上かかる開発を2.5日で完了させました。「まず会議」から「まず AI」への転換、ロールを越えたコラボレーション、並列開発における統合の課題など、実践から得られた学びが詳しく紹介されています。 ブログ記事「 【開催報告】企業の生成 AI 活用を加速する Dify Enterprise on AWS 〜セキュアなデータの活用とパートナー導入事例〜 」を公開 2025年11月21日に開催されたDify Enterprise on AWSイベントの開催報告です。Difyの最新機能（MCP、ナレッジパイプライン、トリガー機能など）の紹介に加え、Snowflakeとの連携によるセキュアなデータ活用、AWS上でのDify構築の選択肢、リコー様によるパートナー導入事例が紹介されています。 ブログ記事「 [資料公開 & 開催報告] Amazon Q Developer & Kiro Meetup #5 を開催しました 」を公開 2025年12月15日に開催されたAmazon Q Developer & Kiro Meetup #5の開催報告です。AWS re:Invent 2025でのKiroアップデート情報に加え、ゼンリンデータコム様のIAM IdCとルールファイルによる組織展開事例、NTTドコモ様のPOPLAR開発での活用事例、リクルート様のAI-DLC導入事例が紹介されています。 ブログ記事「 Agentic workflowを使用したAmazon Nova Premierによるコード移行の効率化 」を公開 レガシーなCコードを最新のJava/Springフレームワークに移行する際の課題と、Amazon Bedrock Converse APIとAmazon Nova Premierを活用したagentic workflowによる解決方法を紹介しています。複数の専門エージェント（コード分析、変換、セキュリティ評価、検証など）を組み合わせることで、移行時間とコストを削減し、コード品質を向上させる実践的なアプローチが解説されています。 ブログ記事「 VMware マイグレーションの加速: AWS Transform の新しいエクスペリエンス 」を公開 AWS Transform for VMwareの新機能を紹介しています。AI駆動のアプローチにより、VMware環境からAmazon EC2へのエンドツーエンド移行を支援します。検出、移行計画、ネットワーク変換（Cisco ACI、Palo Alto、Fortinetのサポート追加）、サーバー移行の各ステップで、チャットベースの操作とマルチアカウントサポートを提供し、移行プロセスを大幅に簡素化します。 ブログ記事「 Amazon Q Business と Amazon Bedrock によるSAP データ価値の最大化 – パート 2 」を公開 Amazon Bedrock Knowledge Bases for Structured Dataを使用して、SAPデータに自然言語で質問する方法を解説しています。Amazon Redshiftにロードしたサンプルの自転車販売データを例に、構造化データ用ナレッジベースの設定から、基盤モデルを使った自然言語によるデータ分析までをステップバイステップで紹介しています。 サービスアップデート Amazon Lex が英語向けに改善された音声認識モデルを提供開始 Amazon Lexが英語向けのニューラル自動音声認識（ASR）モデルを提供開始しました。複数の英語ロケールのデータで訓練されたこのモデルは、非ネイティブスピーカーや地域アクセントを含む多様な話し方のパターンを認識する精度が向上しています。これにより、エンドカスタマーが繰り返し話す必要性が減り、セルフサービスの成功率が向上します。 Amazon Lex が音声活動検出感度の設定機能を提供開始 Amazon Lexが3段階の音声アクティビティ検出（VAD）感度レベル（デフォルト、高、最大）を提供開始しました。デフォルトは一般的な背景ノイズレベルに適しており、高は忙しいオフィスや小売スペースなどの一貫した中程度のノイズレベル向け、最大は製造現場や建設現場などの非常にノイズの多い環境向けです。Amazon ConnectのConversational AI designerでボットロケールを作成または更新する際に設定できます。 AWS Data Exports が Amazon Bedrock モデル使用の詳細な操作可視性を追加 AWS Data Exportsが、Amazon Bedrockの操作タイプをコストレポートで区別できるようになりました。これまでの汎用的な「Usage」ラベルに代わり、「InvokeModelInference」や「InvokeModelStreamingInference」などの具体的な操作タイプが表示されます。FinOpsチームやコスト最適化担当者にとって、Amazon Bedrockを使用する組織の詳細な請求分析が可能になります。 AWS Transform custom が AWS PrivateLink サポートを追加し、欧州（フランクフルト）リージョンに拡大 AWS Transform customがAWS PrivateLinkをサポートし、欧州（フランクフルト）リージョンで利用可能になりました。AWS Transform customは、言語バージョンのアップグレード、APIマイグレーション、フレームワーク更新などの反復的な変換タスクを自動化することで、組織の技術的負債を削減します。AWS PrivateLinkサポートにより、パブリックインターネットを経由せずにAmazon VPCからAWS Transform customにアクセスでき、セキュリティとコンプライアンス要件を満たすことができます。 Amazon SageMaker HyperPod がコンソールでのクラスター作成前にサービスクォータを検証 Amazon SageMaker HyperPodコンソールが、クラスター作成を開始する前にAWSアカウントのサービスクォータを検証するようになりました。大規模なAI/MLクラスターを作成する際、インスタンス、ストレージ、ネットワークリソースに十分なクォータがあることを確認する必要がありますが、これまでは複数のAWSサービスにわたる手動チェックが必要でした。新しいクォータ検証機能は、インスタンスタイプの制限、EBSボリュームサイズ、VPC関連のクォータなど、クラスター構成に対してアカウントレベルのクォータを自動的にチェックし、クォータ超過の可能性がある場合は警告とService Quotasコンソールへの直接リンクを提供します。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近見たドラマは「ストレンジャーシングス」です。

みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします。 2026年になり、早 3 週間近くが過ぎましたね。皆様、今年の目標は立てましたか？ 私は今年、英会話を再開しようと計画しています。昨年末にもお伝えしましたが、 AWS 認定試験の受験支援キャンペーン が2026年2月15日で終了します。このキャンペーンでは、期間中に初回受験を済ませれば、万が一不合格でも2026年3月31日までに同じ試験を1回無料で再受験できます。新年の目標にAWS資格取得を掲げた方は、このチャンスをぜひ活用してください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2026年1月12日週の主要なアップデート 1/12(月) Amazon Inspector が Java Gradle サポートを追加し、エコシステムカバレッジを拡張 Amazon Inspector が Java Gradle サポートと新たなエコシステムカバレッジを追加しました。Lambda 関数や ECR イメージのスキャンで、従来の Java Maven に加えて Gradle プロジェクトの依存関係も自動検出できるようになり、MySQL や PHP、Jenkins-core なども対象に含まれます。これにより、パッケージマネージャー外でインストールされたソフトウェアの脆弱性も発見できるため、より包括的なセキュリティ対策が可能です。詳細は こちらの Amazon Inspector ページをご参照ください。 Amazon Lex が音声アクティビティ検出感度設定を開始 Amazon Lex で各ボットのロケール毎に音声アクティビティ検出 (VAD) の感度を 3 段階で設定できるようになりました。デフォルトのレベルは典型的な背景ノイズレベルの環境、高レベルは忙しいオフィスや店舗などの中程度の騒音環境、最大レベルでは製造現場、建設現場、屋外など高騒音環境に対応します。これまで騒音の多い環境では音声認識の精度が落ちる課題がありましたが、環境に応じた感度調整により、様々な場所でのチャットボット活用が可能になります。詳細は こちらのドキュメントをご参照ください。 1/13(火) Amazon Connect Cases が AWS CloudFormation をサポート開始 Amazon Connect Cases が AWS CloudFormation に対応し、ケース管理の設定を Infrastructure as Code で管理できるようになりました。従来は手動で行っていたテンプレートやフィールド、レイアウトの設定を、CloudFormation テンプレートで自動化できます。これにより複数の Connect インスタンス間で一貫した設定が可能になり、設定ミスの削減や運用効率の向上が期待できます。詳細は こちらのドキュメントをご参照ください。 Amazon RDS for PostgreSQL がマイナーバージョン 12.22-rds.20251114 および 11.22-rds.20251114 の延長サポートを発表 Amazon RDS for PostgreSQL でマイナーバージョン 12.22-rds.20251114 と 11.22-rds.2025111412.22 の延長サポートが提供開始されました。延長サポートでは、コミュニティサポート終了後も最大 3 年間、Amazon RDS が重要なセキュリティ・バグ修正を提供するため、急なメジャーバージョンアップグレードの負担を軽減できます。自動マイナーバージョンアップグレード機能も活用でき、運用負荷を削減しながら最新の修正を適用可能です。詳細は こちらのドキュメントをご参照ください。 1/14(水) Amazon VPC IPAM ポリシーが RDS と Application Load Balancer をサポート Amazon VPC IPAM で RDS インスタンスと Application Load Balancer (ALB) のポリシー機能がサポート開始されました。これにより IP 管理者が中央でこれらのリソースの IP 割り当て戦略を設定・強制できるようになります。従来はデータベース管理者やアプリケーション開発者に IP 割り当て要件を教育し、ベストプラクティスの遵守に頼る必要がありましたが、今回のアップデートで確実に特定の IPAM プールから IP が割り当てられるため、セキュリティグループやファイアウォールでの IP ベースフィルタリングを安心して実装できます。詳細は こちらのドキュメントをご参照ください。 1/15(木) AWS Data Exports が Amazon Bedrock モデル使用量の詳細なオペレーション可視性を追加 AWS Data Exports で Amazon Bedrock の操作タイプが詳細に表示されるようになりました。従来は「Usage」という曖昧な表示でしたが、「InvokeModelInference」や「InvokeModelStreamingInference」など具体的な操作名で区別できます。CUR レポートや Cost Explorer で利用でき、FinOps チームや組織がコスト分析や最適化を効率的に行えるようになります。詳細は こちらのドキュメントをご参照ください。 Amazon RDS が Microsoft SQL Server の最新 CU および GDR アップデートをサポート Amazon RDS for SQL Server で Microsoft SQL Server の最新セキュリティアップデートが利用可能になりました。SQL Server 2016、2017、2019、2022 の各バージョンに対応し、重要なセキュリティ脆弱性 CVE-2025-59499 が修正されています。これにより、データベースのセキュリティが大幅に強化され、安心してビジネスクリティカルなアプリケーションを運用できます。既存の RDS インスタンスも簡単にアップグレード可能で、コンソールや CLI から数クリックで最新の安全な環境に移行できます。詳細は こちらのドキュメントをご参照ください。 AWS Lambda が DynamoDB Streams のクロスアカウントアクセスを発表 AWS Lambda で DynamoDB Streams のクロスアカウントアクセスが可能になりました。これまで複数の AWS アカウント間で DynamoDB のデータ変更イベントを共有するには、複雑なデータレプリケーション仕組みが必要でした。今回のアップデートにより、リソースベースポリシーを設定するだけで、別アカウントの Lambda 関数から DynamoDB Streams にアクセスできます。マルチアカウント環境での運用が大幅に簡素化され、運用負荷を削減できます。詳細は こちらのドキュメントをご参照ください。 Amazon EC2 メモリ最適化 X8i インスタンスの発表 AWS がメモリ最適化された新しい EC2 X8i インスタンスを発表しました。従来の X2i と比較して 43% 高いパフォーマンスと 1.5 倍のメモリ容量 (最大 6TB) を提供します。SAP HANA や大規模データベース、データ分析などのメモリ集約的なワークロードに最適で、PostgreSQL では 47% 高速化、AI 推論では 46% の性能向上を実現します。現在バージニア北部、オハイオ、オレゴン、フランクフルトリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 AWS データベースが Vercel の v0 で利用可能になりました Vercel の AI 駆動型 UI 生成ツール v0 で、Amazon Aurora PostgreSQL、Amazon Aurora DSQL、Amazon DynamoDB が利用可能になりました。自然言語でプロンプトを入力するだけで、フロントエンドからバックエンドまで含むフルスタック Web アプリを数分で構築し、AWS データベースに自動接続できます。新規 AWS アカウントには 100 ドルのクレジットが付与され、DynamoDB のオンデマンドモードなど使用量ベースの課金により、リクエストがない時はコストを最小限に抑えられるため、プロトタイプ開発や本格運用まで幅広く活用できます。詳細は こちらのドキュメントをご参照ください。 1/16(金) AWS Outposts ラックが複数の LGW ルーティングドメインをサポート AWS Outposts ラックで複数の LGW (ローカルゲートウェイ) ルーティングドメインがサポートされました。1 つの Outpost につき最大 10 個の独立したルーティングドメインを作成でき、各ドメインは独自のルートテーブルと BGP セッションを持ちます。これにより部門やビジネスユニット間でネットワークトラフィックを完全に分離できるようになり、セキュリティとガバナンスが大幅に向上します。第 2 世代 Outposts ラックで追加料金なしに利用可能です。詳細は こちらの Blog 記事をご参照ください。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWSサービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

トラフィックの変動に対して自動的にキャパシティを調整する Auto Scalingと、安全なデプロイメントを実現する Blue/Green デプロイ戦略の組み合わせは、可用性と運用効率を両立する構成です。今回のテーマである Amazon ECS を利用する際に採用しているユーザーも多いのではないでしょうか。 しかし一方、Auto Scaling と Blue/Green デプロイ戦略を併用する場合、両機能が同時に作用するタイミングで複雑な相互作用が発生します。そのため、「Blue/Green デプロイメント中は Auto Scaling を停止している」といった声や「リスクが少ない夜間に更新を行う判断をしている」という声を複数聞きます。もちろん、組織の状況や運用するシステムの特性にもよるため、必ずしも悪い運用ではありませんが、もしかしたら相互作用の機序を明らかにすることで、労力を削減する余地があるかもしれません。 本記事ではまず、本テーマで扱う課題について詳しくない方に向けて Auto Scaling と Blue/Green デプロイを併用する際の相互作用について解説します。次に、2025年7月に発表された ECS built-in Blue/Green デプロイの技術的特徴にフォーカスし、 Auto Scaling との併用に焦点をあて安全かつ効率的に併用する実装方法の例を示します。 ※本記事では最新の ECS built-in Blue/Green デプロイ戦略にフォーカスしますが、記事の大部分については CodeDeploy を利用したデプロイ戦略やカスタムデプロイ戦略を採用する場合にも当てはまります。また、厳密には ECS の新しいデプロイ戦略は ECS Blue/Green デプロイや ECS native Blue/Green デプロイといった表記をされることがありますが、本記事では ECS built-in Blue Green デプロイという表記で統一します。 Auto Scaling と Blue/Green デプロイの相互作用を理解する ECS Service をベースに Auto Scaling と Blue/Green デプロイを併用している際の複雑さについて解説します。 まず、複雑になるタイミングについて、Auto Scaling は常に対象のサービスのメトリクスを読み取りスケールを判断しています。一方、Blue/Green デプロイメントは、アプリケーションの更新時のデプロイ戦略の一つであるため、デプロイタイミングで一時的にデプロイ中という状態が発生します。 従って、ユーザー視点では Blue/Green デプロイが行われるアプリケーションの更新時に、ECS Service の状態が複雑になります。 上記タイミングで発生する相互作用の複雑さの原因は、大別すると 2 つに分けられます。1 つ目は Blue/Green デプロイの環境のリソース数です。Auto Scaling は環境の情報を元にスケールアウト、スケールインを判断しますが、Blue/Green デプロイ時はユーザーのリクエストはそのままに、環境に含まれるリソースの数は一時的に 2 倍となります。そのため、環境全体ではユーザーリクエストに対して一時的に 2 倍のリソースが存在することとなり、Auto Scaling からは過剰にリソースをプロビジョンしているように見えてしまう場合があります。 2 つ目はリソースの内部状態です。Green 環境のリソースはデプロイ後十分に初期化処理が終了するまでは不安定な状態にあります。Green 環境には最初トラフィックが流れないため、リソースの使用量が少ないことが想定されますが、初期化処理によってはリソースが激しく消費され、追加のリソースが必要、と判断されてしまう可能性があります。 なお、2 つの複雑さを説明しましたが、多くの場合 1 つ目の複雑さ、つまり Blue/Green 中のリソース数の一時的な増加による、本来より小さいメトリクスの値の報告の方が重要度が高い場合が多いです。後者はスケールアウトを招く可能性がある一方、前者であるこれはスケールインを招くことから、サービスの提供そのものに影響を与える可能性があるからです。 ECS Service における Application Auto Scaling と Blue/Green デプロイメント戦略の詳細 前章では、一般的な Blue/Green と Auto Scaling の併用による複雑さについて説明しました。 具体的なサービスや機能ではこれらの点を部分的にカバーしている場合もあります。ECS で本テーマについて考える際には、以下 5 つの点を押さえる必要があります。 1. デフォルトのメトリクスは Blue 環境と Green 環境のリソースを統合的に扱う ECS のターゲット追跡ポリシーで提供するデフォルトのメトリクス設定のうち、「ALBRequestCountPerTarget」は現時点で Blue/Green デプロイに対応していません。残りの「ECSServiceAverageMemoryUtilization」、「ECSServiceAverageCPUUtilization」は、いずれも ECS Service がディメンションであるメトリクスです。つまり ECS Service に含まれる、各 ECS Task のリソース使用率の平均を元にスケールを判断します。つまり、Blue/Green 中はタスクが 2 倍になることで本来の値より低い値となる可能性があります。 https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html ブルー/グリーンデプロイタイプでは、ターゲット追跡スケーリングポリシーの ALBRequestCountPerTarget メトリクスはサポートされません。 2. ECS はデプロイメント中はスケールインのみ無効化する ECS Service のデプロイ中は、外部デプロイコントローラーを使用する場合を除き、スケールインのみ無効化されます。これは Application Auto Scaling による意図しないタスク削除を防ぐための保護メカニズムで、スケールアウトは通常通り動作を継続します。 対象となる ECS Service における Blue/Green の切り替えにかかる時間が非常に短い場合、こちらの性質を活用するだけで十分な可能性もあります。 https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-auto-scaling.html#service-auto-scaling-deployments Application Auto Scaling は、 Amazon ECS デプロイの進行中 にスケールインプロセスをオフにします。ただし、スケールアウトプロセスは、中断しない限り、デプロイ中に引き続き発生します。 注意点として、デプロイが終了した時点からスケールインのプロセスも有効になります。スケールイン実施判断に使用されるメトリクスは Blue/Green 中に出力されたメトリクスを含むため、厳密にはデプロイ完了直後において本来必要のないスケールインが発生するリスクが存在します。こちらは 4 で解説します。 3. ロールバック機能 Blue/Green デプロイメントではロールバックの機能がありますが、これはデプロイメントプロセス中の中で行われます。したがってロールバックが終了するまでがデプロイメントの範囲となるため、スケールインは無効化されます。 そのため、ロールバックの発生に関して特別な設定は必要ありません。しかし、ロールバックを選択する際は、通常のデプロイが意図通り成功しなかったと言うことであり、デプロイにかかっている時間が増加している可能性があります。そういった場合に意図せずスケールインされないかについては確認する必要があります。 4. ターゲット追跡スケーリングの参照範囲とデプロイ時間の関係 ECS のターゲット追跡ポリシーで提供するデフォルトのメトリック設定を適用した場合、スケールアウト方向には過去3データポイント（3分間）のメトリックが、スケールイン方向には過去15データポイント（15分間）のメトリックを対象に基準値との相違点や距離を判定します。 Blue/Green によるデプロイ時間が短い場合は問題ないと考えられる一方、15分以上デプロイに時間がかかる場合、本来より低いメトリックの値が15分以上記録されることになります。 2. で述べたとおり ECS ではデプロイ中のスケールインは無効化されているものの、デプロイ明け直後にはスケールインが可能となるため、デプロイ明け直後にスケールインが走るリスクがある場合は、ポリシーを見直す必要があるでしょう。 5. ECS で推奨されるユーザーのカスタマイズ範囲 以下の通り、ECS Service に対して Auto Scaling を設定する際は、事前定義された設定を利用する、もしくは Auto Scaling でカスタムのメトリクスを利用する方法の 2 種類になります。   この際、以下の通り自動で作成される Amazon CloudWatch Alarm の設定の変更については推奨されていません。つまり、アラームの発火に使用するデータポイント数の設定などの変更が現状は非推奨であるため、スケールインに使用されるデータポイントの期間の範囲が15分であることの変更等は現時点では難しい、といった状況に注意する必要があります。なお、ステップスケーリングではデータポイントの数の変更については明記されていませんので注意してください。 ターゲットメトリクスを使用して Amazon ECS サービスをスケールする https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html ターゲット追跡スケーリングポリシーのためにサービスの自動スケーリングが管理する CloudWatch アラームを編集または削除しないでください。スケーリングポリシーを削除するときに、サービスの自動スケーリングはアラームを自動的に削除します。 ECS Service における Application Auto Scaling と Blue/Green デプロイメント戦略の併用の例 ここまでの内容を踏まえると、まずは ECS のデフォルトの仕組みで十分対応可能であるかどうかについて検討する必要があります。失敗時のケース等を含め、デプロイ時間が十分に短い等、リスクを許容し併用するといった意思決定もありうると思います。 スケールイン等のリスクが許容できない場合、Green リソースの追加による一時的なリソースの増加に対応する必要があります。ここからは特にスケールインのリスクに対する対応の例を3つ示します。これらの例で対応可能な場合は併用を採用し、それでも要件上難しい場合は併用しないといった意思決定をとることになります。 なお、以下説明で頻出する、ECS Service におけるカスタムのメトリクスやアラームを設定する具体的な方法については以下のブログを参考ください。 カスタムメトリクスに基づいた Application Auto Scaling による Amazon ECS サービスのオートスケール | Amazon Web Services ブログ https://aws.amazon.com/jp/blogs/news/autoscaling-amazon-ecs-services-based-on-custom-metrics-with-application-auto-scaling/ パターン1: 「本来のタスク数をベースとしたリソース使用率を算出するカスタム設定されたアラーム」を使用するターゲット追跡スケーリングポリシーを設定する この方法は、スケールインの懸念に対する対応として有効です。 ECS のメトリクスでは、Blue/Green 中も値が変化しないメトリクスとして、DesiredTaskCount が利用可能です。そのため、例えば Container Insights のメトリクスを利用し、以下のような式に対してアラームを設定することで、本来のタスク数を分母とした CPU 使用率に近い値を導出することができます。 式 CPUUtilization * RunningTaskCount / DesiredTaskCount 各メトリクスの説明 DesiredTaskCount: ECS Service で設定した必要なタスクの数 RunningTaskCount: 現在 RUNNING 状態にあるタスクの数 CPUUtilization サービスに属するタスクで使用されている CPU ユニットの総数を、サービスに属するタスク用に予約されている CPU ユニットの総数で割った値 パターン2: 「バックエンド ECS Task に依存しないカスタムメトリクスを活用するカスタムアラーム」を使用するターゲット追跡スケーリングポリシーを設定する ECS Task の前段に配置される ALB の TargetResponseTime や NewConnectionCount などのメトリクスは、Blue/Green 中もリソースの状態が変化しません。そのため、実際のリソース使用状況ではなく間接的な値となるものの、これらを利用することで この方法は、 ECS Task の状態に依存しないため、スケールイン方向、スケールアウト方向いずれの方向においても一貫した値をベースにBlue/Green 中もスケールを判断することができます。 式 TargetResponseTime NewConnectionCount パターン3: ECS Service に対して複数のターゲット追跡スケーリングポリシーを設定する ECS では一つの ECS Service に対して複数のターゲット追跡スケーリングポリシーを設定できます。この場合、スケールアウト方向にはいずれか 1 つのメトリックが閾値を超えれば良いのに対し、スケールインでは全てのメトリックが条件を満たす必要があります。 ターゲットメトリクスを使用して Amazon ECS サービスをスケールする – Amazon Elastic Container Service https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html Amazon ECS サービスに対して複数のターゲット追跡スケーリングポリシーを設定できます。ただし、各ポリシーがそれぞれ異なるメトリクスを使用している必要があります。サービスの自動スケーリングの目的は常に可用性を優先することであるため、その動作は、スケールアウトまたはスケールインに対するターゲット追跡ポリシーの準備が整っているかどうかに応じて異なります。ターゲット追跡ポリシーのいずれかでスケールアウトする準備ができると、サービスがスケールアウトされますが、すべてのターゲット追跡ポリシー (スケールイン部分がオン) でスケールインする準備ができている場合にのみスケールインされます。 従って、現在設定しているポリシーに追加で、Blue/Green 中に発火しにくい、低い値のターゲット追跡スケーリングポリシーを設定することで、スケールアウト方向にはこれまでと同じ速度である一方、スケールインについてはより緩やかな実施を実現することが可能です。この方法はこれまでのパターンと併用することが可能です。 まとめ 本記事では、ECS built-in Blue/Green デプロイメントとApplication Auto Scaling の効果的な併用方法について包括的に解説しました。従来の運用では、Auto Scaling と Blue/Green の併用時に発生する技術的課題を回避するため、デプロイ中の Auto Scaling 停止という対処法が一般的でしたが、これによりトラフィック増加への対応不可、デプロイ頻度の制限、運用工数の増加といった新たな課題が生じていました。 本記事では、サービスによっては既存の ECS の仕組みに任せたり、カスタムのメトリクスを設定することで Auto Scaling と ECS Blue/Green デプロイを設定変更せず併用する余地があることを示しました。また、その背景となる Auto Scaling と Blue/Green デプロイの相互作用の仕組みを明らかにし、ユーザーのより高度な活用の基礎となる要素を示すことができたと考えています。 ECS built-in Blue/Green デプロイメントと Auto Scaling の組み合わせは、現代のクラウドネイティブアプリケーション運用において、可用性、効率性、アジリティのすべてを同時に向上させる強力なソリューションです。ビジネスやサービスの要件に応じて適切な選択をする際に、本記事がその一助となれば幸いです。

ニフティ株式会社では、ネットワークサービス事業と Web サービス事業の 2 軸でビジネスを展開しています。 @nifty光など、各種サービスの申込みや開通状況の確認など接続サービスで使用しているデータベースを 2024 年 5月に Amazon RDS for Oracle へ移行しました。本ブログでは、 Amazon RDS for Oracle への移行検討から移行後の効果について、お客様の声を紹介いたします。 移行検討の背景と課題 同社は、長年利用していたレガシーシステムに課題を抱えており、これらを解決するためにアマゾン ウェブ サービス (AWS) への移行を進めています。Web サービスを提供している約 800 台のサーバーの移行を終え、現在はネットワークサービス事業用の基幹システムの移行を進めています。その中の 1 つの接続サービスで使用しているデータベースが稼働しているサーバーのハードウェア老朽化と保守期限が迫ってきていたため、早期の移行が必要でした。また、高額なランニングコストや、そのコストに見合う機能を使い切れていないという課題を抱えていました。運用面では、データベースのメンテナンスタイミングをサービス都合で選択できず、ベンダーの指定タイミングに従わざるを得ない制約があり、さらにメモリ不足による予期せぬフェイルオーバーが発生するなど、安定性にも問題を抱えていました。 AWS での構築システムが多く、親和性が高かったため、Amazon RDS for Oracle を選択しました。また、同種エンジンの Amazon RDS for Oracle の最適なライセンスモデルを移行先とすることで、コスト最適化を目指すとともに、クラウドの弾力性を活かし、適切なサイジングにより、更なるコスト最適化を目指しました。ライセンスやサイジングの最適化を行えた理由としては、移行後、万が一性能要件を満たせないことが判明した場合でも、直ぐにスペックアップにより対応できることも判断理由の一つです。また、課題となっていたメンテナンスタイミングは、メンテナンスウィンドウの調整により実現しました。 アーキテクチャと移行プロセス ニフティの回線サービスに関するデータ ( 顧客の申込情報や契約進捗状況など ) は、統合データベースで一元管理されています。このデータベースには、各回線サービスシステムからアクセスが可能です。システムは AWS だけでなく、他のクラウド環境にも構築されているため、VPN 経由でアクセスが行われます。 2022 年 から移行検討を開始し、AWS のデータベース移行支援プログラムを活用し、Statspack レポート分析や AWS Schema Conversion Tool レポート分析を AWS の Solutions Architect とともに実施し、移行難易度の調査やサイジングを行い、事前に移行難易度が低いことを確認しました。 2023 年 6 月から移行の本格検討を開始し、2023 年 9 月から 3 か月間 PoC を実施し、2023 年 12 月から 2024 年 2 月にかけて、データベースの設計、構築、データ移行の準備を進めました。そして、 2024 年 2 月から 5 月にかけて、段階的に移行を進めました。データベース移行のデータ移行では、約 4000 のオブジェクト ( 内 プロシージャ 150 ) 、約 1 TB のデータを、マテリアライズドビューを使用して、Amazon RDS へ移行しました。 移行方式採用の理由としては、データサイズが大きいため、ダウンタイムが長くなる懸念がありました。差分移行を行う上で、ネイティブ機能を利用した移行のほうが、安全性が高いと判断し、マテリアライズドビューを使用して、高速リフレッシュにより差分データを移行し、移行当日にマテリアライズドビューをテーブルに切り替えて行う移行方式を採用しました。この移行方式により、本番データベースの CPU 使用率が通常時から比べ 30% ほど上昇しましたが、業務処理への影響はありませんでした。 また、移行時の課題として、サービス影響を最小限にするため、アプリケーション移行対象スキーマが約 50 あり、スキーマ間で参照権限が設定されている箇所が多数あったため、移行順序を精査しながら、移行計画を作成しました。また、移行完了後、移行元環境に残っているアプリケーションとデータベース間のネットワークレイテンシーの増加により、処理時間が延びる事象は発生しましたが、PoC で予め検知できていたため、今後、AWS 環境に移行することで改善される事象として、課題管理できており、大きな問題にはなりませんでした。 Amazon RDS への移行の効果 2023 年 6 月 から、今回のシステムのデータベースの移行を検討し始め、約 1 年で移行を完了しました。移行した結果、ライセンス最適化によるライセンスコストの削減だけでなく、スペック最適化により、ランニングコストの削減に成功しました。 また、マネージドサービスを活用することで、運用・保守作業の大幅な効率化ができ、バックアップ運用やパッチ準備などの運用負荷が下がっただけでなく、ベンダー都合によるメンテナンス対応に追われることがなくなり、任意のスケジュールでメンテナンスが可能になりました。また、最適なサイジングの結果、移行前のような予期せぬフェイルオーバーも発生しなくなり、安定性も向上しました。マネージドサービスの活用により、サーバーへ直接ログインした不正アクセスの防止など潜在的に潜んでいたセキュリティリスクの低減だけでなく、データベースの構築・運用作業が簡素化されたことにより、これまでベテランエンジニアの専任領域となっていたデータベース関連の作業に、若手エンジニアも積極的に携われるようになりました。結果として、エンジニアのスキル育成にも良い影響を与えています。その流れに合わせて、運用手順の整備や業務効率化をする機会にでき、クラウド移行を前向きな良い機会とすることができています。 コスト面では、Amazon RDS 移行によりシステム環境のランニングコストを 77 % 削減という効果を出せています。 今後に向けて ニフティ株式会社 基幹システムグループ 中廣 可奈子氏からのコメント： まだ、他にも WEB やバッチなどのアプリケーション環境が旧環境に残っているため、引き続き移行を推進していきます。 AWS への移行完了後、マイクロサービス化など、更なるアーキテクチャ最適化を目指していきます。 まとめ ニフティ株式会社では、Amazon RDS に移行することで、システム環境のコストを77%削減しました。また、運用・保守作業の効率化、メンテナンス時期の柔軟な選択が可能になり、システムの安定性とセキュリティも向上しました。さらに、若手エンジニアの育成機会の創出にもつながっています。

2025 年 12 月 15 日に AWS Startup Loft Tokyo (目黒) で開催された「 Amazon Q Developer & Kiro Meetup #5: AWS re:Invent アップデート速報 & お客様の活用事例紹介 」のイベントの様子をレポートします。 登壇資料は こちらからダウンロード (zip) していただけます。 このイベントは、AWS re:Invent 2025 でアップデートのあった Kiro の機能紹介と、お客様による Amazon Q Developer / Kiroの実践活用事例をテーマに実施しました。まずソリューションアーキテクトの稲田から Kiro の概要と AWS re:Invent 2025 前後で発表されたアップデートをご紹介しました。続いて、株式会社ゼンリンデータコム様、株式会社NTTドコモ様から Amazon Q Developer / Kiro の社内展開や活用方法の事例を共有していただきました。最後に株式会社リクルート様に AI-DLC の導入状況について発表していただきました。 参加者の方からは「各社の取り組み、AIに対する考えを知ることができ非常に有意義でした。」などのご感想をいただきました。現地参加の方のみ、ケータリングをご用意し、ネットワーキングのための懇親会を実施しました。 登壇者の方への質問や、参加者同士の意見交換、AWS メンバーへの相談が活発におこなわれていました。 イベント概要 開催日時: 2025年12月15日 19:00- 会場: AWS Startup Loft Tokyo (目黒)、オンライン配信 スピーカー 株式会社ゼンリンデータコム様「Amazon Q Developer の組織展開 ～IAM IdC × ルールファイルで実現する標準化と統制～」 株式会社 NTT ドコモ様「NTT ドコモにおける Amazon Q Developer 活用事例の紹介」 株式会社リクルート様「AI-DLC を現場にインストールしてみた：プロトタイプ開発で分かったこと・やめたこと」 ソリューションアーキテクト 稲田 大陸 Amazon Web Services Japan G.K. 「Amazon Q Developer および Kiro のAWS re:Invent のアップデート」 乾杯の挨拶: 事業開発マネージャー　井形 健太郎 Amazon Q Developer および Kiro の AWS re:Invent のアップデート スピーカー: ソリューションアーキテクト 稲田 大陸, Amazon Web Services Japan G.K. はじめに、ソリューションアーキテクトの稲田より、AWS re:Invent 2025 前後の Amazon Q Developer / Kiro のアップデート情報をご紹介しました。 AWS Japan 独自の Blog 連載イベント「 Kiroweeeeeeek in Japan 」をご案内し、Kiro の概要や Kiro がガイドする仕様駆動開発 (Spec Driven Development) についてもご説明しました。Kiro のアップデート情報として、GA (一般提供開始) や Kiro for Enterprise の提供開始、チェックポイントやプロパティベーステストの導入、Kiro CLI の提供開始をご紹介しました。 さらに、AWS が提供する フロンティアエージェント の一つである Kiro Autonomous Agent が生まれた背景や特徴についてご説明しました。Kiro powers といった新機能や新しい料金体系についてもご紹介しました。 株式会社ゼンリンデータコム様「Amazon Q Developer の組織展開 ～IAM IdC × ルールファイルで実現する標準化と統制～」 株式会社ゼンリンデータコム様からは、「Amazon Q Developer の組織展開 ～IAM IdC × ルールファイルで実現する標準化と統制～」と題して AWS 環境の管理業務に対する Amazon Q Developer / Kiro の活用と、全社展開における取り組みについて発表していただきました。 社内展開にあたって実施した、AWS IAM Identity Center によるマルチアカウント環境でのユーザ管理や、役割ベースの権限セットへの集約といった工夫についてお話しいただきました。さらに、利用者ごとのスキル差や誤操作リスクの緩和のための、独自のルールファイルを作成によるプロンプト入力の簡素化や MCP サーバーの利用についてもご説明いただきました。 Kiro CLI のカスタムエージェント の活用による AWS 環境管理業務の効率化の取り組みについてもご紹介いただきました。 株式会社 NTT ドコモ様「NTT ドコモにおける Amazon Q Developer 活用事例の紹介」 株式会社 NTT ドコモ様からは、「NTT ドコモにおける Amazon Q Developer 活用事例の紹介」と題して、社内の主要 Web サービス提供基盤「POPLAR」開発における Amazon Q Developer の活用状況と利用上の工夫について発表していただきました。 まず Amazon Q Developer 採用に至る経緯についてお話しいただき、活用状況として設計・実装・テスト・運用各フェーズにおける利用状況や品質・効率面での成果についてご共有いただきました。また、POPLAR の開発における Amazon Q Developer の組織的な活用のための取り組みについて利用ガイドラインの策定・周知や利用状況の可視化といった具体例を挙げてご説明いただきました。最後に、Kiro の採用も含めた今後の展望についてご紹介いただきました。 POPLAR における Amazon Q Developer の活用状況の詳細については AWS ブログ 「 NTTドコモの Web サービス基盤『 POPLAR 』開発における Amazon Q Developer 活用 」もぜひご覧ください。 株式会社リクルート様「AI-DLC を現場にインストールしてみた：プロトタイプ開発で分かったこと・やめたこと」 株式会社リクルート様からは、「AI-DLCを現場にインストールしてみた：プロトタイプ開発で分かったこと･やめたこと」と題して、AI を最大限ソフトウェア開発に活用する手法として提唱されている AI-DLC (AI-Driven Development Lifecycle, AI 駆動開発ライフサイクル) の活用状況について発表していただきました。 まずソフトウェア開発フェーズやタスクの計画を AI で作成する、検討内容は AI でドキュメント化する、AI の成果物は人間がレビューし、必要に応じて AI との質疑応答を取り入れる、などのテクニックについておさらいとしてご説明いただきました。 AI-DLC を実プロジェクトに取り入れる上での各フェーズでの流れやプロンプト、アウトプットの例をご紹介いただきました。最後に AI-DLC の採用に向いているプロジェクトの要素として、求められる品質やリードタイム、既存のインプット、チームの状況といった観点からそれぞれご説明いただきました。 株式会社リクルート様の登壇資料は「 AI-DLCを現場にインストールしてみた：プロトタイプ開発で分かったこと･やめたこと 」からご覧いただけます。 AI-DLC の詳細については過去の開催報告 「 [資料公開 & 開催報告] Amazon Q Developer Meetup #3 を開催しました 」 や、AWS ブログ 「 AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 」 をご覧ください。 おわりに 今回の Amazon Q Developer & Kiro Meetup #5 では、AWS re:Invent 2025 でアップデートのあった Kiro の機能紹介と、お客様による Amazon Q Developer / Kiroの実践活用事例をテーマとして開催させていただきました。株式会社ゼンリンデータコム様、株式会社NTTドコモ様、株式会社リクルート様にご登壇いただき、各社での取り組みや工夫、得られた知見についてお話しいただきました。 今後も、開発者の皆様が生成 AI をより有効に活用していただくための AI-DLC をはじめとしたプラクティスや Amazon Q Developer や Kiro といったツールについて発信・アップデートをお届けします。 筆者 yamazaki hiroki profile-20250806 山崎 宏紀 (Hiroki Yamazaki) 山崎宏紀 は Amazon Web Services Japan G.K. のソリューションアーキテクトとして、ISV/SaaS 業界のお客様を中心にアーキテクチャ設計や構築、生成 AI の活用・AI エージェントの開発をご支援しています。Kiro CLI や AWS CDK を好みます。(より良いご支援のために) AI エージェントに代わりに働いてもらおうと画策しています。

Amazon Multi-Channel Fulfillment and Buy with Prime Accelerators for SAP S/4HANA のご紹介 本日、 Amazon Multi-Channel Fulfillment（MCF）and Buy with Prime Accelerators for SAP S/4HANA の提供開始を発表できることを嬉しく思います。この強力な統合により、SAPのお客様は既存のSAP S/4HANA実装を活用してAmazon MCFおよびBuy with Primeを利用できるようになります。これにより、Amazonのフルフィルメントインフラストラクチャの潜在能力を最大限に活用し、ビジネスを成長させ、カスタマーエクスペリエンスを向上させることができます。 この発表は、地球上で最もお客様を大切にする企業であるという私たちの使命に貢献するいくつかの取り組みの中心に位置しています。 オンラインショッピング: 私たちは、Amazon.comを通じて何百万ものお客様に利便性、品揃え、低価格を提供することで最もよく知られています。これにより、世界最大のフルフィルメントネットワークを構築し、何百万もの商品を提供できるようになりました。その多くは、Primeメンバー向けに無料の2日配送、さらには当日配送も可能です。 マーチャントの支援: また、マーチャントがAmazon.com、自社のウェブサイト、他のオンライン小売業者、ソーシャルメディアチャネルでビジネスを構築・拡大できるよう支援するプログラムの作成にも力を入れています。 クラウドでのミッションクリティカルなアプリケーションの実行: 同様に、AWSはこのお客様第一の取り組みから生まれました。ITを民主化し、企業がデータセンター管理ではなくコアビジネスに集中できるよう支援しています。お客様は、AWSでミッションクリティカルなSAPシステムを実行している何千ものお客様を含め、事実上すべてのアプリケーションとユースケースにAWSを使用しています。 AWSのお客様からは、Amazonのグローバルな規模、サプライチェーン、運用のベストプラクティスを活用して、フルフィルメントとeコマース業務を変革する方法について、ますます多くのお問い合わせをいただいています。Amazon MCFやBuy with Primeなどのソリューションにより、私たちは世界クラスの物流ネットワークを自社のストアを超えて拡張し、ブランドがまさにそれを実現できるよう支援しています。 マーチャントがAmazon MCFとBuy with Primeを愛用する理由 Amazon Multi Channel Fulfilment（MCF） は、マーチャントがAmazonのフルフィルメントネットワークを活用して、すべての販売チャネルで注文のピッキング、梱包、発送、配送を行えるようにするサードパーティロジスティクス（3PL）ソリューションです。Amazon MCFを使用することで、マーチャントはAmazonのフルフィルメントネットワーク内の単一の在庫プールを活用して、在庫切れ率を削減し、在庫回転率を向上させ、運用効率を高めることができます。マーチャントは、 Amazon以外の小売チャネルにMCFを追加して以来、平均で売上または収益が約19%増加した と報告しています。 Buy with Prime は、ブランドが自社のウェブサイトで直接、迅速で無料の配送、簡単な返品、24時間年中無休のショッパーサポート、Amazonからのレビューなど、Primeショッピングの特典を提供することで、ビジネスを成長させるのに役立ちます。Amazonは、お客様が知っていて、愛し、信頼しているショッピング体験をブランドが提供できるよう支援することで、マーチャントが新しいショッパーを引き付け、既存のお客様を維持するのを支援します。実際、 Buy with Primeを使用したショッパーの95%が再度使用する可能性が非常に高いと回答し*、マーチャントはBuy with Primeを提供することで、平均してショッパーあたりの収益が16%増加しました** 。 SAP S/4HANA向けAmazon MCFおよびBuy with Primeアクセラレーターは、SAP Business Technology Platform（SAP BTP）とSAP Integration Suite、およびAmazonの事前構築されたAPIを活用して、必要な統合作業を最大75%削減し、多くのお客様が6週間以内に本番稼働できるようにします。 「お客様は単なるクラウドプロバイダーを求めているのではなく、成長を支援し、運用の回復力を向上させ、お客様により良いサービスを提供できる変革パートナーを求めています」 と、AWSのWW SAP Go-To-Market担当ゼネラルマネージャーであるSara Alligoodは述べています。 「私たちは、SAPとのパートナーシップを拡大し、マーチャントがSAP S/4HANAで実行されている既存のビジネスプロセスに破壊的な変更を加えることなく、Amazon Multi-Channel FulfilmentとBuy with Primeの力を活用できるよう支援できることを嬉しく思います。」 「Buy with PrimeとSAP S/4HANAをSAP Integration Suiteと統合することで、お客様はAmazonのグローバルネットワークと運用のベストプラクティスにアクセスでき、業界を超えた小売業者が注文管理を最適化し、運用コストを削減しながらカスタマーエクスペリエンスを向上させることができます」 と、SAP BTPのプレジデントでありSAP SEの拡大役員会メンバーであるDr Michael Amelingは述べています。 仕組み この統合は、 SAP BTP を活用して既存のシステムを接続するというシンプルさを念頭に設計されています。Multi-Channel Fulfilment APIとBuy with Prime APIは、組織の既存の注文管理およびeコマースシステムがeコマースとフルフィルメントをサポートするAmazonシステムと対話するためのプログラマティックな方法を提供します。APIを使用するマーチャントは、検索、商品ページ、カート、チェックアウトなど、既存のウェブサイトエクスペリエンスにBuy with Primeおよび/またはMCFを追加し、日々の注文データをバックエンドアプリケーションに統合できます。 従来、MCFとBuy with Primeを活用したいSAPのお客様は、SAP S/4HANAシステムがAmazonの注文データの受け入れ、Prime商品がAmazonによってフルフィルされるようにフルフィルメントリクエストを分割する、または注文後の更新を受信するなどの機能を実行できるようにするために、いくつかのバックエンド変更を行っていました。SAPのお客様からは、初期実装を簡素化し、SAP S/4HANAシステムとAmazonのBuy with Prime APIとの統合を容易にする方法について、ますます多くのお問い合わせをいただいています。 SAP S/4HANA向けAmazon MCFおよびBuy with Primeアクセラレーターは、このプロセスを劇的に簡素化します。これらは、既存のSAPワークフローと構成とシームレスに連携する、さまざまなeコマースフルフィルメントのユースケースをサポートする、すぐに使える一般的なインタラクションを提供します。アクセラレーターにはSAP Integration Suiteが必要です。お客様は、既存のSAP Integration Suiteへの投資を活用するか、 AWS MarketplaceからSAP Integration Suiteをサブスクライブ できます。 SAP S/4HANAシステムをAmazonのMCFおよびBuy with Prime APIに接続するだけで、Amazonのフルフィルメントネットワークの力を活用し始めることができます。この統合により、SAP S/4HANAでレコードを取得、作成、更新できます。 現在、以下のモジュールが利用可能です： モジュール 機能 Fulfill with Customer すべてのeコマース注文をCustomerでフルフィル Fulfill with Customer 選択した商品のeコマース注文をCustomerでフルフィル Fulfill with Customer フルフィルメントのキャンセルを許可 Fulfill with Customer 注文ステータスの更新をCustomerに送信 Customer Fulfillment Status Updates パッケージフルフィルメントの更新を受信 Customer Fulfillment Status Updates パッケージキャンセルの更新を受信 Customer Fulfillment Status Updates パッケージ配送マイルストーンステータスを受信 Returns through Customer Customerを通じて返品を受信 Returns through Customer 返品注文の更新を受信 Returns Outside Customer 返品詳細をCustomerと同期 Customer Refund Updates Customerから返金準備完了通知を受信 Customer Refund Updates Customerが発行した返金の詳細を受信 Synchronize issue refunds 発行された返金を同期 Customer Inventory Updates Customerからリアルタイムの在庫更新を受信 Customer Inventory Updates Customerから定期的な在庫更新を受信 前提条件 アクセラレーターをインストールする前に、以下の前提条件を満たしていることを確認してください。 eコマースサイトで注文が行われた場合、SAP S/4HANAは、eコマースサイトによって生成された注文詳細をキャプチャするように設定されている必要があります。 生成された注文詳細に、Buy with Primeを通じてPrime配送で購入された商品がタグ付けされるように、eコマースサイトを変更する必要があります。 SAP Integration Suiteをサブスクライブします。 オプションで、Buy with Primeを通じて提供される商品を、Amazonでのみフルフィルしたい場合は、そのような商品にタグを付けることもできます。 今すぐ始めましょう SAPランドスケープを変革し、優れたカスタマーエクスペリエンスを提供する準備はできていますか？ Amazon MCF and Buy with Prime Accelerators for SAP S/4HANA は、SAP Business Accelerator Hubからダウンロードできます。 eコマースと注文フルフィルメント機能のモダナイゼーションについて詳しく知りたい場合は、 AmazonのMCFページ および Buy with Primeページ をご覧ください。SAP BTPがエンタープライズ向けに構築されたテクノロジープラットフォームで、ミッションクリティカルなビジネスプロセスのためのAI、データ、アプリケーションの潜在能力を最大限に引き出す方法については、 SAP BTP をご覧ください。 AWSは、このプロジェクトとブログ投稿へのサポートについて、Aaron Graberと拡大SAPチームに感謝します。 *出典：Buy with Prime購入後カスタマー調査、2024年8月 **このデータポイントは、2023年7月から2024年6月の間に167のマーチャントから収集されたA/Bテスト結果に基づいており、同じ期間中にBuy with Primeが購入オプションであった場合とそうでなかった場合に生成された収益の平均増加を測定しています。 リソース SAP on AWS Case Studies SAP on AWS FAQ Contact Us Find a Partner 本ブログはAmazon Bedrockによって翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

本ブログは 2025 年 11 月 21 日に公開された AWS Blog “ Accelerate investigations with AWS Security Incident Response AI-powered capabilities ” を翻訳したものです。 セキュリティイベントの調査で、 AWS CloudTrail のログを何時間もかけて手動で調べ、 AWS Identity and Access Management (IAM) の権限を確認し、タイムラインをつなぎ合わせた経験がある方なら、インシデント調査に必要な時間と労力をよくご存知でしょう。本日 (2025 年 11 月 21 日)、 AWS Security Incident Response に AI を活用した調査機能を追加したことを発表します。この機能により、証拠収集と分析作業が自動化されます。 AWS Security Incident Response は、セキュリティイベントへの準備、対応、復旧をより迅速かつ効果的に行えるよう支援するサービスです。今回追加された AI を活用した調査機能は、セキュリティ検出結果の自動監視・自動トリアージや封じ込めといった既存機能、そして AWS Customer Incident Response Team (CIRT) への 24 時間 365 日のダイレクトアクセスと組み合わせて提供されます。 不審な API コールや異常なネットワークアクティビティを調査する際には、何が起こったのか全体像を把握する必要があります。そのためには、複数のデータソースへのクエリ、タイムスタンプの照合、関連イベントの洗い出しなど、多くの作業が求められます。セキュリティオペレーションセンター (SOC) のアナリストは、各調査に多大な時間を費やしており、その約半分は様々なツールや複雑なログから証拠を手動で収集してつなぎ合わせる作業に費やされています。この手作業が、分析と対応を遅らせる原因となっています。 AWS は Security Incident Response に調査エージェントを導入し、この状況を変え、効率を飛躍的に高めます。調査エージェントにより、潜在的なセキュリティイベントの検証と対応に必要な時間を大幅に短縮できます。セキュリティの問題についてケースが作成されると (お客様が作成した場合でも、Security Incident Response が自動的に作成した場合でも)、調査エージェントはまず状況を正確に把握するための確認質問を行います。その後、CloudTrail イベント、IAM 設定、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの詳細から自動的に証拠を収集し、コスト使用パターンも分析します。数分以内に、証拠を相関付け、パターンを特定し、明確な調査サマリーを提示します。 実際の動作 例を見る前に、調査エージェントの使い方と、その目的・機能について説明します。調査エージェントは、Security Incident Response に標準で備わっており、ケースを作成すると自動的に利用可能になります。その目的は、最初の対応者として機能することです。証拠を収集し、AWS サービス全体のデータを相関付け、イベントの包括的なタイムラインを作成することで、検出から復旧まで迅速に進めることができます。 例えば、アカウント内の IAM ユーザーの AWS 認証情報がパブリックな GitHub リポジトリで公開されていることを発見したとします。その認証情報でどのようなアクションが実行されたかを把握し、ラテラルムーブメント (横方向への移動) や偵察活動を含め、影響範囲を特定する必要があります。作成された可能性のある永続化メカニズムを特定し、適切な封じ込め手順を決定する必要があります。開始するには、 Security Incident Response コンソール でケースを作成し、状況を説明します。 ここで、エージェントのアプローチが従来の自動化と異なる点があります。まず状況を正確に把握するための確認質問を行います。 認証情報が最初に公開されたのはいつですか? IAM ユーザー名は何ですか? すでに認証情報をローテーションしましたか? 影響を受けている AWS アカウントはどれですか? このインタラクティブなステップにより、証拠収集を開始する前に適切な詳細とメタデータを収集します。つまり、汎用的な結果ではなく、個々のインシデントに特化した調査が行われます。 エージェントが必要な情報を得ると、調査を開始します。CloudTrail イベントを調べて、侵害された認証情報を使用してどのような API コールが行われたかを確認し、IAM ユーザーとロールの詳細を取得してどのような権限が付与されていたかを確認し、新しく作成された IAM ユーザーやロールを特定し、コンピューティングリソースが起動された場合は EC2 インスタンス情報を確認し、異常なリソース消費がないかコストと使用パターンを分析します。お客様が各 AWS サービスに個別にクエリを実行する必要はありません。エージェントがこれらを自動的にまとめて処理します。 数分以内に以下の図に示すような調査サマリーが得られます。調査サマリーには、概要と重要な検出結果が含まれます。重要な検出結果には、認証情報の公開パターン、観察されたアクティビティとその発生期間、影響を受けたリソース、調査における制約事項が含まれます。 図 1 – 調査サマリー このレスポンスは AWS の生成 AI 機能を使用して生成されました。特定のコンテキストで推奨事項を評価し、適切な監視とセーフガードを実装する責任はお客様にあります。 AWS の責任ある AI の要件の詳細をご覧ください 。 注 : 上記の例は代表的な出力です。実際のフォーマットは検出結果によって異なります。 調査サマリーには、以下の図に示すようなイベントタイムラインを含む技術的な検出結果など、詳細情報を表示するための様々なタブが含まれています。 図 2 – セキュリティイベントのタイムライン 一刻を争う状況で迅速かつ的確に対応するには、この透明性が不可欠です。AWS の専任セキュリティエキスパートグループである AWS CIRT にエスカレーションする必要がある場合や、経営陣に調査結果を説明する必要がある場合にも、関係者全員が同じ画面でインシデントを確認できます。 調査が完了すると、何が起こったかの高解像度の全体像が得られ、封じ込め、根絶、復旧について十分な情報に基づいた意思決定ができます。上記の認証情報公開シナリオでは、以下の対応が必要になる可能性があります。 侵害されたアクセスキーを削除する 新しく作成された IAM ロールを削除する 不正な EC2 インスタンスを終了する 関連する IAM ポリシーの変更を確認して元に戻す 他のユーザー用に作成された追加のアクセスキーがないか確認する AWS CIRT と連携する際、エージェントが収集した証拠に基づいて、封じ込め戦略に関する追加のガイダンスを受けることができます。 セキュリティ運用への影響 認証情報漏洩のシナリオでは、単一のインシデントに対してエージェントができることを示しました。しかし、エージェントがもたらすメリットはそれだけではありません。日々のセキュリティ運用にも大きな効果があります。 証拠収集にかかる時間を削減できます。 調査エージェントは、調査で最も時間のかかる部分である複数のソースからの証拠収集と相関付けを自動化します。手動のログ分析に 1 時間費やす代わりに、その時間の大部分を封じ込めの意思決定と再発防止に費やすことができます 自然言語で調査できます。 調査エージェントは自然言語処理 (NLP) を使用しており、 unusual API calls from IP address X や data access from terminated employee's credentials のように、調査内容を自然言語で記述できます。エージェントがそれを必要な技術的クエリに変換します。AWS のログ形式に精通していたり、CloudTrail をクエリするための正確な構文を知っている必要はありません 高精度で正確な調査の基盤が得られます。 調査エージェントは、証拠の収集、パターンの特定、包括的なサマリーの提供といった初期調査を処理します。ケースでより深い分析が必要な場合や、複雑なシナリオに関するガイダンスが必要な場合は、AWS CIRT と連携できます。AWS CIRT は、エージェントがすでに行った作業をすぐに活用できるため、対応時間が短縮されます。同じ証拠とタイムラインを確認できるため、ゼロから始めるのではなく、高度な脅威分析と封じ込め戦略に集中できます 開始方法 すでに Security Incident Response を有効にしている場合、AI を活用した調査機能は今すぐ利用可能です。追加の設定は必要ありません。次のセキュリティケースを作成すると、エージェントが自動的に動作を開始します。 Security Incident Response を初めて使用する場合は、以下の手順でセットアップします。 AWS Organizations の管理アカウントから Security Incident Response を有効にする。 AWS マネジメントコンソールから数分で完了し、アカウント全体をカバーできます ケースを作成する。 調査内容を記述します。Security Incident Response コンソールまたは API から行うか、 Amazon GuardDuty または AWS Security Hub のアラートから自動的にケースを作成するよう設定することもできます 分析結果を確認する。 エージェントは Security Incident Response コンソールを通じて検出結果を提示します。 Jira や ServiceNow などの既存のチケットシステムからもアクセスできます 調査エージェントは、AWS サポートの サービスリンクロール を使用して AWS リソースから情報を収集します。このロールは AWS アカウントのセットアップ時に自動的に作成され、サポートツールが CloudTrail イベント、IAM 設定、EC2 の詳細、コストデータをクエリするために必要なアクセス権を提供します。エージェントが実行したアクションは、完全な監査可能性のために CloudTrail に記録されます。 調査エージェントは Security Incident Response に追加費用なしで利用できます。Security Incident Response は現在、毎月最初の 10,000 件の検出結果の取り込みをカバーする 無料利用枠付きの従量課金 を提供しています。それを超える検出結果は、ボリュームに応じて低減する料金で課金されます。この従量課金制のアプローチにより、ニーズの成長に合わせてセキュリティインシデント対応機能をスケールできます。 既存ツールとの連携 Security Incident Response のケースは、お客様が作成することも、サービスが自動的に作成することもできます。調査エージェントは新しいケースが作成されると自動的にトリガーされ、ケースはコンソール、API、または Amazon EventBridge 統合 を通じて管理できます。 EventBridge を使用すると、GuardDuty、Security Hub、Security Incident Response 自体からのセキュリティイベントをルーティングする自動化されたワークフローを構築し、ケースを作成して対応計画を開始できます。これにより、検出から調査までのエンドツーエンドのパイプラインが実現します。調査エージェントが作業を開始する前に、サービスの自動トリアージシステムが GuardDuty およびサードパーティのセキュリティツールからのセキュリティ検出結果を Security Hub を通じて監視およびフィルタリングします。既知の IP アドレスや IAM エンティティなどのお客様固有の情報を使用して、予想される動作に基づいて検出結果をフィルタリングし、アラートボリュームを削減しながら、即座の対応が必要なアラートをエスカレーションします。これにより、調査エージェントは実際に調査が必要なアラートに集中できます。 まとめ この記事では、AWS Security Incident Response の新しい調査エージェントが証拠収集と分析を自動化し、セキュリティイベントの調査に必要な時間を数時間から数分に短縮する方法を紹介しました。エージェントは、状況を正確に把握するための確認質問を行い、複数の AWS データソースに自動的にクエリを実行し、証拠を相関付け、完全な透明性と監査可能性を維持しながら、包括的なタイムラインと調査サマリーを提示します。 調査エージェントの追加により、Security Incident Response のお客様は、必要に応じて AWS セキュリティエキスパートの専門知識と監視に支えられた、AI を活用した自動化のスピードと効率性を得られるようになりました。 AI を活用した調査機能は、Security Incident Response が運用されているすべての商用 AWS リージョンで本日 (2025 年 11 月 21 日) から利用可能です。料金と機能の詳細、または開始方法については、 AWS Security Incident Response 製品ページ をご覧ください。 Daniel Begimher Daniel は Global Services Security のシニアセキュリティエンジニアで、クラウドセキュリティ、アプリケーションセキュリティ、インシデントレスポンスを専門としています。AWS Security and Compliance Technical Field Community 内の Application Security フォーカスエリアを共同でリードし、すべての AWS 認定を保有しています。また、オープンソースのコードスキャンツールである Automated Security Helper (ASH) の作成者でもあります。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 11 月 25 日に公開された AWS Blog “ AWS Secrets Manager launches Managed External Secrets for Third-Party Credentials ” を翻訳したものです。 AWS Secrets Manager は Amazon Web Services (AWS) のシークレットライフサイクルを効果的に管理できます。しかし、クラウドアプリケーションの利用拡大に伴い、サードパーティソフトウェアプロバイダーの認証情報管理が組織にとって新たな課題となっています。複数のサードパーティサービスを利用する組織では、各プロバイダーの認証情報を管理する標準的な方法がなかったため、プロバイダーごとに異なるセキュリティアプローチを開発することがよくあります。これらのサードパーティの認証情報を Secrets Manager に保存する際、サービス接続を容易にするために、シークレット値内に追加のメタデータを保持することが一般的です。このアプローチでは、メタデータが変更されるたびにシークレット値全体を更新する必要があり、プロバイダー固有のシークレットローテーションプロセスを実装する必要がありますが、これは手動で時間がかかります。シークレットローテーションの自動化を検討している組織は、通常、各サードパーティソフトウェアプロバイダーに合わせたカスタム関数を開発しますが、これにはサードパーティと AWS の両方のシステムに関する専門知識が必要です。 お客様がサードパーティのシークレット管理を効率化できるよう、AWS Secrets Manager に新機能「マネージド外部シークレット」を導入しました。このブログでは、この新機能がセキュリティのベストプラクティスを維持しながら、サードパーティソフトウェアの認証情報の管理とローテーションをどのように簡素化するかを説明します。 マネージド外部シークレットの紹介 AWS Secrets Manager は、 Amazon Relational Database Service (Amazon RDS) や Amazon DocumentDB などの AWS サービスのシークレットを、マネージドローテーション機能を通じて安全に管理してきた実績があります。この実績を基に、Secrets Manager はマネージド外部シークレットを導入しました。これは、Salesforce などのサードパーティソフトウェアアプリケーションにも同じシームレスな体験を提供する新しいシークレットタイプで、標準化されたフォーマットと自動ローテーションによってシークレット管理の課題を簡素化します。 この機能を使用すると、サードパーティソフトウェアプロバイダーが発行するシークレットを事前定義されたフォーマットで保存できます。これらのフォーマットは、信頼できる統合パートナーと協力して開発され、シークレットの構造とローテーションに必要なメタデータの両方を定義しているため、独自の保存方法を設計する必要がありません。マネージド外部シークレットは、ソフトウェアプロバイダーと直接統合することで自動ローテーションも提供します。ローテーション関数を維持する必要がないため、運用オーバーヘッドを削減しながら、 AWS Identity and Access Management (IAM) を使用した きめ細かなアクセス許可管理 、 Amazon CloudWatch と AWS CloudTrail によるシークレットアクセスの監視、 Amazon GuardDuty による自動化されたシークレット固有の脅威検出など、重要なセキュリティコントロールの恩恵を受けることができます。さらに、AWS とサードパーティの両方のシークレットに対して、単一のサービスから一元化された一貫したシークレット管理プラクティスを実装できるため、組織で複数のシークレット管理ソリューションを運用する必要がなくなります。マネージド外部シークレットは標準の Secrets Manager の料金 に従い、この新しいシークレットタイプの使用に追加コストはかかりません。 前提条件 マネージド外部シークレットを作成するには、Secrets Manager への適切なアクセス権を持つアクティブな AWS アカウントが必要です。アカウントには、シークレットを作成および管理するための十分なアクセス許可が必要で、 AWS マネジメントコンソール へのアクセス、または AWS Command Line Interface (AWS CLI) や AWS SDK を介したプログラムによるアクセスが可能である必要があります。最低限、以下のアクションに対する IAM アクセス許可が必要です: secretsmanager:DescribeSecret 、 secretsmanager:GetSecretValue 、 secretsmanager:UpdateSecret 、 secretsmanager:UpdateSecretVersionStage 。 AWS にシークレットを管理させる予定のサードパーティソフトウェアプロバイダーの有効な認証情報と必要なアクセス許可を持っている必要があります。 シークレットの暗号化については、 AWS Key Management Service (AWS KMS) の AWS マネージドキー を使用するか、 カスタマーマネージドキー を使用するかを決定する必要があります。カスタマーマネージドキーの場合は、必要なキーポリシーが設定されていることを確認してください。 AWS KMS キーポリシー では、Secrets Manager が暗号化と復号化の操作にキーを使用できるようにする必要があります。 マネージド外部シークレットの作成 現在、マネージド外部シークレットは Salesforce、Snowflake、BigID の 3 つの統合パートナーをサポートしています。Secrets Manager はパートナーリストを継続的に拡大しており、今後さらに多くのサードパーティソフトウェアプロバイダーが追加される予定です。最新のリストについては、 統合パートナー を参照してください。 マネージド外部シークレットを作成するには、以下のセクションの手順に従ってください。 注: この例では Salesforce External Client App の認証情報を取得する手順を示していますが、Secrets Manager と統合された他のサードパーティベンダーの認証情報についても同様の手順で設定できます。 シークレットタイプの選択と詳細の追加 AWS マネジメントコンソールで Secrets Manager サービスに移動し、[新しいシークレットを保存] を選択します [シークレットタイプ] で [マネージド外部シークレット] を選択します [AWS Secrets Manager 統合サードパーティベンダー] セクションで、利用可能なオプションからプロバイダーを選択します。このウォークスルーでは、[Salesforce External Client App Credential] を選択します [Salesforce External Client App Credential シークレットの詳細] セクションで設定を入力します。Salesforce External Client App の認証情報は、いくつかの主要なコンポーネントで構成されています コンシューマーキー (クライアント ID) は、OAuth 2.0 の認証情報識別子として機能します。コンシューマーキー は Salesforce External Client App Manager の OAuth 設定から直接取得できます コンシューマーシークレット (クライアントシークレット) は、OAuth 2.0 認証のプライベートパスワードとして機能します。コンシューマーシークレットは Salesforce External Client App Manager の OAuth 設定から直接取得できます ベース URI は、Salesforce 組織のベース URL ( https://MyDomainName.my.salesforce.com の形式) で、Salesforce API との連携に使用されます アプリ ID は、 Salesforce External Client Apps (ECA) を識別するもので、Salesforce OAuth 使用状況エンドポイントを呼び出すことで取得できます コンシューマー ID は、Salesforce ECA を識別するもので、Salesforce OAuth credentials by App ID エンドポイントを呼び出すことで取得できます。コマンドの一覧については、Salesforce ドキュメントの Stage, Rotate, and Delete OAuth Credentials for an External Client App を参照してください ドロップダウンメニューから [暗号化キー] を選択します。AWS マネージドキーまたはカスタマーマネージドキーを使用できます [次] を選択します 図 1: シークレットタイプの選択 シークレットの設定 このセクションでは、シークレットの設定情報を入力します [シークレットの名前] にわかりやすい名前を入力し、オプションでシークレットの目的と用途を識別するのに役立つ詳細な [説明] を入力します。追加の設定オプションも利用できます。リソースを整理しやすくするための [タグ] の追加、アクセスを制御するための特定の [リソースのアクセス許可] の設定、 マルチリージョンの耐障害性のためのシークレットのレプリケート の選択が可能です [次] を選択します 図 2: シークレットの設定 ローテーションとアクセス許可の設定 (オプション) オプションの [ローテーションを設定する] ステップでは、新しいシークレット設定でメタデータ管理に焦点を当てた 2 つの主要なセクションが導入されています。これらはシークレット値とは別に保存されます。 [ローテーションメタデータ] で、Salesforce アプリが使用している API バージョンを指定します。API バージョンを確認するには、Salesforce ドキュメントの List Available REST API Versions を参照してください。 注: 必要な最小バージョンは v65.0 です [管理者シークレット ARN] を選択します。これには、Salesforce クライアントシークレットのローテーションに使用される管理者 OAuth 認証情報が含まれています [シークレットローテーションのサービス権限] セクションでは、Secrets Manager がシークレット値をローテーションするために必要なアクセス許可を持つロールを自動的に作成します。これらのデフォルトのアクセス許可は、[アクセス許可の詳細を表示] を選択するとインターフェースに表示され、確認できます。シークレットローテーション管理をよりきめ細かく制御するために、デフォルトのアクセス許可の選択を解除することもできます [次] を選択します 図 3: ローテーションの設定 レビュー 最後のステップでは、シークレットの設定の概要が表示されます。[レビュー] ページで、シークレットを作成する前にパラメータを確認できます。 設定が正しいことを確認したら、[保存] を選択してプロセスを完了し、指定した設定でシークレットを作成します。 図 4: レビュー 正常に作成されると、シークレットが [シークレット] タブに表示されます。設定、ローテーションステータス、アクセス許可など、シークレットのさまざまな側面を表示、管理、監視できます。作成後は、暗号化設定やクロスアカウントアクセス用のリソースポリシーなどのシークレット設定を確認し、さまざまな AWS SDK 向けに提供されているサンプルコードを調べて、シークレットの取得をアプリケーションに統合できます。[シークレット] タブでは、シークレットの概要が表示され、シークレットを一元管理できます。シークレットを選択して [シークレットの詳細] を表示します。 図 5: シークレットの詳細を表示 これで、マネージド外部シークレットが Secrets Manager に正常に作成されました。このシークレットには、Secrets Manager コンソールから、または AWS API を使用してプログラムでアクセスおよび管理できます。 Secrets Manager の統合パートナーとしてオンボーディングする 新しいマネージド外部シークレットタイプにより、サードパーティソフトウェアプロバイダーは Secrets Manager と統合し、AWS 上で提供するシークレットをプログラムで安全に管理する方法をお客様に提供できます。この統合により、お客様は AWS とサードパーティ両方のシークレットのライフサイクルを一元管理でき、シークレット作成時から自動ローテーション機能を利用できます。Salesforce などのソフトウェアプロバイダーは、すでにこの機能を活用しています。 「Salesforce では、セキュリティはイノベーションの障壁ではなく、イノベーションを可能にするものであるべきだと考えています。マネージド外部シークレットに関する AWS とのパートナーシップは、セキュリティ・バイ・デフォルトの実践であり、エンタープライズグレードの保護を提供しながら、お客様の運用負担を軽減します。AWS Secrets Manager がパートナーにも拡張され、自動化されたゼロタッチローテーションによって人的リスクが排除されることで、専門知識や追加コストなしに安全な認証情報をシームレスに利用できる新しい業界標準を確立しています。」— Salesforce プロダクトマネジメント担当シニアバイスプレジデント Jay Hurst 氏 統合パートナーとして Secrets Manager にオンボーディングするための追加コストはかかりません。開始するには、 パートナーオンボーディングガイド に記載されているプロセスに従ってください。統合パートナーになることについてご質問がある場合は、 aws-secrets-mgr-partner-onboarding@amazon.com まで、件名を「[パートナー名] Onboarding request」としてお問い合わせください。 まとめ このブログでは、Secrets Manager の新しいシークレットタイプ「マネージド外部シークレット」を紹介しました。この機能は、事前定義されたフォーマットと自動ローテーションを通じて、サードパーティシークレットのライフサイクルを安全に管理するという課題に対応します。独自の保存方法の設計や複雑なローテーション関数の開発が不要になり、AWS サービス、カスタムアプリケーション、サードパーティプロバイダーのいずれのシークレットも、単一のサービスから一貫して管理できるようになりました。マネージド外部シークレットは、きめ細かなアクセス許可管理、オブザーバビリティ、コンプライアンスコントロールなど、標準の Secrets Manager シークレットと同じセキュリティ機能を提供しながら、追加コストなしで信頼できるパートナーとの組み込み統合を追加しています。 開始するには、 技術ドキュメント を参照してください。既存のパートナーシークレットをマネージド外部シークレットに移行する方法については、 既存のシークレットの移行 を参照してください。この機能は、すべての AWS 商用リージョンで利用できます。Secrets Manager が利用可能なリージョンの一覧については、 AWS リージョン表 を参照してください。このブログについてご質問がある場合は、 Secrets Manager re:Post で新しいスレッドを開始するか、 AWS サポート にお問い合わせください。 Rohit Panjala Rohit は AWS のセキュリティスペシャリストで、データ保護と暗号化サービスに注力しています。AWS データ保護サービスの市場投入 (GTM) 戦略の策定と実行、およびグローバル規模でのお客様とパートナーの導入促進を担当しています。AWS 入社前は、IBM でセキュリティプロダクトマネジメント、および電気エンジニアリングの職務に従事していました。オハイオ州立大学で工学の学士号を取得しています。 Rochak Karki Rochak は AWS のセキュリティスペシャリストソリューションアーキテクトで、脅威検出、インシデント対応、データ保護に注力し、お客様が安全な環境を構築できるよう支援しています。米国陸軍の退役軍人で、ワイオミング大学で工学の学士号を取得しています。仕事以外では、家族や友人と過ごしたり、ハイキングや旅行を楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

こんにちは！ アマゾン ウェブ サービス ジャパンのソリューションアーキテクト馬渕です。普段は交通業界のお客様の技術支援を担当していますが、その他にも業界問わず Dify や Amazon Bedrock を活用したお客様の AI 活用推進をご支援しております。 2025年11月21日（金）15:30-17:00に「企業の生成 AI 活用を加速する Dify Enterprise on AWS 〜セキュアなデータの活用とパートナー導入事例〜」を開催し、多くのお客様にご参加いただきました。今回のイベントでは、Dify の最新機能や、 Dify Enterprise とプラグインによるセキュアなデータ活用、Dify on AWS のメリット、パートナー企業による実践的な導入事例をテーマにプレゼンテーションを実施しました。 本ブログでは、イベント内容を簡単にご紹介しつつ、当日のセッションの様子を共有いたします。また、各セッションで紹介された内容のポイントもお伝えしますので、今後の Dify 活用の参考にしていただければと思います。 イベント概要 本イベントは以下のような形で実施しました。 日時 : 2025年11月21日（金）15:30-17:00（開場 15:00） 場所 : アマゾンジャパン合同会社目黒オフィス 参加対象 : 社内の生成 AI 活用を推進している IT 部門責任者、機密度の高い重要な企業システムの管理者、データ活用に生成 AI を活かしたいデータ基盤管理者 時間 セッション 資料 15:30 – 15:35 Opening – 15:35 – 15:55 Agentic AI 開発の実力 – 最先端技術で安全なDX変革を実現 (Dify アップデート紹介) 株式会社 LangGenius 田口太一様 PDF 15:55 – 16:15 Dify プラグイン & Enterprise 株式会社 LangGenius 橋本龍生様 PDF Dify Enterprise でセキュアなデータも扱おう – Snowflake と連携してインサイトを生む – アマゾンウェブサービスジャパン合同会社 阿部拓也 PDF 16:15 – 16:30 Dify on AWS の選択肢 〜 Why Dify on AWS？ 〜 アマゾンウェブサービスジャパン合同会社 関谷侑希 SpeakerDeck PDF 16:30 – 16:50 パートナーと進める Dify 活用 株式会社リコー 萩原智様 PDF 16:50 – 17:00 Q&A / Closing – 17:00 – 18:00 懇親会 – Agentic AI 開発の実力 – 最先端技術で安全なDX変革を実現(Dify アップデート紹介) 最初のセッションでは、株式会社 LangGenius の田口様より、Dify の最近の新機能群について発表いただきました。新機能である MCP（Model Context Protocol）やナレッジパイプライン、トリガー機能のご紹介や、現在開発中の Human In The Loop 機能の解説をいただきました。 いずれの機能も注目の新機能ですが、特にアンケートで注目が集まっていたのはトリガーと Human-in-the-loop 機能でした。Dify で生成 AI ワークフローは作りきっているものの、そのワークフローの定期実行等のために別のワークフローツールを併用している……というお客様も多くいましたが、今回のトリガー機能により Dify で完結できるようになりました。 Dify Enterprise でセキュアなデータも扱おう – Snowflake と連携してインサイトを生む – 次のセッションは、前半を株式会社 LangGenius 橋本様にお話いただき、後半をアマゾンウェブサービスジャパン合同会社の阿部からお話する共同セッション形式でお送りしました。 前半では、株式会社 LangGenius 橋本様より、Dify Enterprise の機能とプラグインエコシステムについてお話いただきました。多くのお客様が、 Dify をプラグイン経由で外部システム接続できるエコシステムを活用して生成 AI 活用に役立てています。このエコシステムは非常に便利な一方、ユーザが好き放題にプラグインを導入してしまうとセキュリティ・ガバナンス上のリスクたりえるため、その統制が重要となります。Dify Enterprise ではかねてよりマルチテナント・SSO ・アプリの権限管理等のガバナンス機能を有していましたが、さらにプラグイン管理機能も備えるようになり、プラグインを安全に導入できるようになりました。 後半では、プラグインエコシステムを活かした Dify Enterprise の実践的なユースケースとして、Snowflake と Dify の連携について AWS 阿部よりお話しました。Dify の公式プラグインである Snowflake SQL プラグイン を介して安全に連携し、企業 DWH データを自然言語で自在にクエリするユースケースとアーキテクチャを、実際の動作デモを交えてご紹介しました。企業の重要なデータが格納された DWH を Dify に連携して生成 AI でクエリする場合、閲覧権限の適切なコントロールがネックになりがちですが、Dify Enterprise であればマルチテナント機能・アプリ権限管理機能によりセキュリティを保って連携できる点は注目すべきポイントとなります。 なお、このプレゼンテーションで登場した Snowflake プラグインは、今回のイベントに合わせて LangGenius に開発いただきました。 Dify on AWS の選択肢 〜 Why Dify on AWS？ 〜 続いて、アマゾンウェブサービスジャパン合同会社の関谷より、AWS 上で Dify を構築する際の選択肢と、AWS を選ぶメリットについて詳しく解説しました。 Dify を on AWS で構築する際、選択肢としては大きく ① OSS 版を単一 VM 上に構築、② OSS 版をマネージドサービス上に構築、③ Enterprise 版を Kubernetes 上に構築、という 3 つの方法があります。それらの詳細なメリット・デメリットの比較についてお伝えしたうえで、Dify を AWS 上に構築するメリットについてもお伝えしました。Dify の SaaS 版が on AWS で構築されているという実績や、Dify を AWS 上に迅速に構築できるアセットについてご紹介したほか、AWS Marketplace での Dify Enterprise ライセンス購入により、基盤費用とライセンス費用の効率的な管理が可能であることもお伝えしました。 パートナーと進める Dify 活用 最後のセッションでは、株式会社リコーの萩原様より、 Dify パートナーとしての豊富な社内実践をもとにした価値提供についてご紹介いただきました。 リコー様は、自社内向けの生成 AI 活用環境として、 Dify Enterprise を AWS 環境上に構築して展開しています。AWS 上の Dify のアーキテクチャ観点と、社内普及のための AI 活用推進の観点の両面で知見をご共有いただきました。特に、Dify Enterrprise 機能の社内ガバナンス観点の活用方法や、社員一人一人が Dify を活用していく市民開発を促すための仕組みづくりなど、自社で使い倒しているからこその知見をもとにお客様をご支援できる点が注目すべきポイントでした。 まとめ 今回のイベントでは、Dify Enterprise の最新機能から AWS との連携によるセキュアなデータ活用、そしてパートナー企業による実践的な導入事例まで、幅広い内容をカバーすることができました。 参加者の皆様からは「Dify のアップデートを詳細に説明してもらえて理解が深まった」「エンタープライズ版の機能紹介が参考になった」「市民開発を推進するにあたり環境面、運用面で素晴らしい事例だった」といった声を多数いただき、大変好評でした。 企業における生成 AI の活用は、技術的な実現可能性だけでなく、セキュリティやガバナンスの観点からも慎重な検討が必要です。今回のイベントで紹介された Dify Enterprise と AWS の組み合わせは、これらの課題を解決しながら、効果的な AI 活用を実現するための有力な選択肢となることを改めて確認できました。 ご参加いただいた皆様、ありがとうございました。 Dify Enterprise on AWS の導入にご興味がございましたら、 AWS の営業担当者までお声がけください。また、Dify 未活用のお客様も、まずは ワンクリックで Dify を AWS 上に構築し 、生成 AI 活用の第一歩を踏み出しましょう。 今後も AWS では、Dify を通じたお客様の生成 AI 活用を継続してご支援してまいります。 関連リンク Dify on AWS with CDK サンプル AWS Generative AI Solution Box Dify での生成 AI アプリケーション構築ワークショップ AWS Marketplace – Dify Enterprise   馬渕 俊介 (Mabuchi, Shunsuke) 交通業界のお客様を支援するソリューションアーキテクト。前職では性能のスペシャリストとして従事していたため、好きな AWS ソリューションは AWS での分散負荷テスト ソリューションです。最近は Dify にハマり、 Dify on AWS に関する様々な知見を発信しています。

本記事は 2025 年 12 月 24 日 に公開された「 Accelerating VMware migration: AWS Transform’s new experience 」を翻訳したものです。 2025 年初めの画期的なローンチに続き、 AWS は新しい強力な AI 機能を追加 し、 AWS Transform for VMware マイグレーションエージェントを強化しました。AWS Transform for VMware は、お客様のビジネス優先度を理解し、環境に適応し、マイグレーションの各ステップでより良い制御を提供します。エージェントは、依存関係マッピング、インテリジェントなウェーブプランニング、複数のターゲットアカウントにわたるネットワーク構成の変換など、移行プロセスをオーケストレーションします。マイグレーションエージェントのネットワーク機能は、Cisco ACI、Palo Alto、Fortinet ネットワークを含む新しいベンダーでのセキュリティグループ変換をサポートするようになりました。 VMware 環境のすべてのワークロードを Amazon EC2 へエンドツーエンドの移行を計画している場合でも、VMware インフラストラクチャの特定のワークロードやサーバーをターゲットにしている場合でも、AWS Transform の AI 駆動アプローチは実行において柔軟性を実現します。必要に応じて移行計画を変更し、インフラストラクチャの進化に合わせて検出ステップを繰り返し、完了した作業の整合性を維持しながら選択的にマイグレーションウェーブを実装できます。このインテリジェントなアプローチにより、移行のリスクが軽減され、移行期間を短縮できます。統一された Web インターフェースと AI アシスタンスにより、マイグレーション全体を通じて一貫性を維持できます。AWS Transform for VMware は 追加料金なしで利用が可能 です。この新しいソリューションは、 AWS Transform が提供されているすべての AWS リージョン で利用可能になり、 16 の AWS リージョン へのサーバーとネットワークのマイグレーションをサポートします。 このブログでは、環境分析のための検出、移行計画、インフラストラクチャ適応のためのネットワーク変換、Amazon EC2 へのワークロード変換のためのサーバー移行を行うエンドツーエンドの移行について説明いたします。 前提条件 セットアップを開始するには、以下が必要です: AWS Organizations のセットアップ AWS IAM Identity Center のセットアップ AWS アカウント: 移行計画アカウント – 移行のアクティベーションとオーケストレーションのコントロールセンターとして機能します。AWS Transform はこのアカウントで実行されます。 ターゲットアカウント – ワークロードの移行先となるアカウントです。 エンタープライズ規模のマイグレーションでは、上記のように特定の目的のために異なるアカウントを持つことを推奨しますが、機能を 1 つのアカウントに統合することも可能です。すべてのアカウントは同じ AWS Organizations に属している必要があります。 開始方法 移行計画アカウントで AWS Transform を有効にし、ユーザーを割り当てるには以下の手順に従います: AWS Transform セットアップ AWS コンソールで、 AWS Transform に移動します 使用を開始 を選択します 暗号化キーを選択し、 AWS Transform 機能を有効にする を選択します ユーザーを管理 を選択します IAM Identity Center から AWS Transform にユーザーまたはグループを追加します 左ペインから Settings に移動し、 ウェブ アプリケーション URL をコピーします ユーザーは Web アプリケーション URL を使用して AWS Transform にログインできます 最初の AWS Transform ジョブを作成する Transform コンソールで、 Create workspace を選択して新しいワークスペースを作成します Create job を選択し、 Migration > VMware Migration を選択して VMware マイグレーションジョブを作成します 利用可能なジョブオプションのリストからジョブを選択します チャットでの後続のプロンプトに従って、移行プロセスを続行します 図 1: AWS Transform for VMware ジョブオプション 検出 AWS Transform はソースデータを分析し、パターンを自動的に識別し、データの競合を解決し、重複エントリを排除して、VMware 環境のよりクリーンで正確なビューを提供します。マイグレーションエージェントの検出機能は、複数のデータコレクターによって生成されるさまざまな種類のエクスポートに対応します。 検出の中核となるのは AWS Transform discovery tool で、VMware vCenter の一元管理された Discovery Collector OVA (Open Virtualization Format Archive) ファイルを通じてデプロイされます。AWS 接続を必要とせずにオンプレミス環境内で完全に動作し、このツールはサーバー仕様やネットワーク依存関係を含む環境に関する詳細情報を自動的に検出および収集します。このツールは基本的なインベントリ収集にとどまらず、適切なサイジング推奨のためのリソース使用率、SQL Server データベースメタデータ、依存関係マッピングのためのサーバー間接続などの重要なデータポイントをキャプチャします。収集されたすべてのデータは、マイグレーションを進めることを選択するまで、オンプレミスインフラストラクチャ内に安全に保存されます。 図 2: AWS Transform for VMware Discovery tool 既存のツールとプロセスについて、AWS Transform は柔軟なデータ取り込みオプションを提供します。vSwitch、ポートグループ、VLAN を含む VMware 環境に関する詳細情報を提供する CSV または XLSX 形式の RVTools エクスポートを活用できます。エージェントは、既存のインフラストラクチャ管理ソリューションと統合して、ModelizeIT や Cloudamize などの 一部のサードパーティツールからのデータインポート もサポートします。 さらに、AWS Transform 検出ステップでは、Large Language Model (LLM) を使用してコンテンツを分析し、任意の形式のファイルを処理できます。処理に成功すると、既存のインベントリレコードを更新するか、新しいエントリを作成するためのサーバー情報を抽出します。 図 3: マイグレーションジョブデータ取り込み 検出ステップでは、検証済みのインフラストラクチャインベントリを作成し、データ品質の問題を特定し、対応が必要なギャップや不整合を浮き彫りにします。この環境の包括的な理解は、移行計画、ネットワーク変換、サーバー移行を含む後続のマイグレーションステップの基盤となります。 図 4: マイグレーションジョブ検出サマリー 移行計画の作成 エンドツーエンドマイグレーションの次のステップは、 移行ウェーブ計画の作成 です。AWS Transform は、AI を活用した新しい移行計画機能を導入し、お客様の VMware 移行計画へのアプローチを刷新します。この機能は、会話型インターフェースを通じて、複雑なインフラストラクチャデータを実用的な移行戦略へと変換します。構造化された検証とインテリジェントな依存関係分析を組み合わせることで、AWS Transform は、お客様が移行プロセスをコントロールしながら、計画プロセスにおける変化するビジネス要件に適応できるよう支援します。 これはデータ処理とインフラストラクチャ分析から始まります。AWS Transform は、通常 CSV または XLSX 形式のインフラストラクチャインベントリファイルを処理し、サーバー名、オペレーティングシステム、設定、CPU、メモリ、ストレージ割り当て、ネットワーク依存関係の詳細を抽出します。この分析により、検証済みインフラストラクチャインベントリが生成され、データ品質の問題が特定され、明確化が必要なギャップや不整合がハイライトされます。 図 5: インフラストラクチャインベントリ分析 移行計画ステップでは、AWS Transform は 3 段階のプロセスを実装します。まず、アプローチを定義し、アプリケーションに関連するビジネスインプットをエージェントと共有します。次に、エージェントはこれらのルールを適用してアプリケーション定義を作成し、各サーバーが正確に 1 つのアプリケーションに割り当てられることを保証します。第三に、アプリケーションはビジネスクリティカリティ、技術的複雑さ、リスク許容度などの要因に基づいて優先度スコアを受け取り、移行の順序付けを促進する構造化されたポートフォリオが作成されます。 図 6: 移行計画 – アプリケーションのグループ化 次の段階は移行グループの作成です。各移行グループには、一緒に移行する必要がある関連アプリケーションが含まれます。AWS Transform はアプリケーション間の依存関係を分析して、アプリケーションが依存関係より前に移行されるシナリオを回避します。移行グループは、データベースアプリケーションをまとめて管理したり、開発環境と本番環境を分離したりするなど、定義済みのサイズ設定ルールと構成要件に従います。 図 7: 移行計画 – 移行グループ 移行計画の作成は、ウェーブの作成で終了します。AWS Transform は、移行グループを順次ウェーブに整理することで移行タイムラインを作成します。各ウェーブには 1 つ以上の移行グループが含まれ、定義された順序で実行されます。AWS Transform は依存関係を考慮しながらスケジュールを最適化します。依存関係のない移動グループは並行して実行でき、依存関係のあるものは特定の順序に従う必要があります。エージェントは、月あたりの最大ウェーブ数やウェーブ間の必要なバッファなどのビジネス制約を組み込んで、実行可能なマイグレーションスケジュールを作成します。 図 8: 移行計画 – ウェーブ計画 移行計画のステップ全体を通して、AWS Transform はあらゆるフェーズで反復的な改善をサポートします。アプリケーションのグループ化の変更は移行グループとウェーブの再生成をトリガーし、移行グループの変更はウェーブ計画のみを再生成します。このターゲットを絞った再生成により、完了した作業を中断することなく、効率的な更新が保証されます。 ネットワーク変換とマイグレーション マイグレーションウェーブを確定した後、AWS Transform for VMware は、ソースネットワーク設定を変換し、ターゲット AWS アカウント全体にデプロイすることで、ネットワーク設定のマイグレーションを自動化します。VMware vSphere と VMware NSX のサポートに加えて、以下のネットワークインフラストラクチャソースのサポート範囲を拡大し、既存のネットワーク構成を AWS ネットワーク構成にシームレスに変換できるようになりました。 Cisco Application Centric Infrastructure (ACI) ネットワークポリシー設定 Palo Alto Networks ファイアウォールセキュリティポリシー Fortinet FortiGate ファイアウォールセキュリティポリシー ネットワーク変換は ターゲット AWS アカウントの接続 から始まり、単一アカウントまたは 複数アカウントの移行 を定義できます。ターゲットアカウントを接続した後、ソースネットワーク設定をインポートできます。AWS Transform は VMware NSX と VMware vSphere の RVTools エクスポートからの複数のファイル形式をサポートします。ファイル検証後、セキュリティグループ設定に進み、 サポートされているセキュリティアプライアンスからの追加設定データを組み込む ことでセキュリティ体制を強化できます。これはオプションですが、ターゲット環境で一貫したセキュリティポリシーを維持するために推奨されます。 図 9: セキュリティグループ設定のためのネットワーク構成入力 セキュリティグループ設定を完了した後、AWS Transform はネットワークトポロジー選択をガイドし、2 つのアーキテクチャパターンを提示します。どちらのトポロジーについてもサンプルアーキテクチャを説明するためにチャットすることもでき、実装前にネットワーク設計を理解するのに役立ちます。 分離された仮想プライベートクラウド (VPC) 独立して動作する VPC を作成 各 VPC は独自のインターネットゲートウェイとルーティング設定を持つスタンドアロンネットワークとして機能 シンプルなデプロイメントと VPC 間通信のニーズが最小限の環境に最適 VPC 間の接続を手動で追加変更および設定することを計画しているカスタムネットワーク設計に最適 ハブアンドスポーク VPC AWS Transit Gateway を作成し、ルートテーブルを使用してすべての VPC を接続 すべての VPC 間トラフィックは Transit Gateway を通じてルーティングされ、集中化されたネットワーク管理と共有サービスを提供 集中制御、共有サービス、または頻繁な VPC 間通信を必要とする環境に最適 図 10: ネットワークトポロジーの説明 これにより、オンプレミスネットワークアーキテクチャの AWS ネットワーキングコンポーネントへの変換が自動化されます。ソースネットワーク設定を分析し、VPC、サブネット、セキュリティグループ、ルーティングテーブルを含むターゲット AWS ネットワーク環境を定義する Infrastructure as Code (IaC) テンプレートを生成します。 Landing Zone Accelerator (LZA) on AWS 互換 YAML、 AWS CloudFormation 、 AWS Cloud Development Kit (CDK) 、 HashiCorp Terraform を含む複数の IaC 形式を活用でき、デプロイメントアプローチの柔軟性を提供します。これらのテンプレートは簡単にアクセスできるよう S3 バケットに自動的に保存されます。 AWS Transform は、さまざまな組織のニーズに対応するため、自動化と手動の両方のデプロイメントオプションを提供します。ネットワーク構成時に、AWS Transform では 生成された VPC の CIDR 範囲を指定および編集 でき、ネットワークの重複を回避し、IP アドレス指定ポリシーに準拠し、すべての計画されたサブネットとワークロードに十分な IP アドレス空間を確保できます。さらに、ネットワークのデプロイメント要求には AWS Transform の Approvals タブを通じた明示的な承認が必要で、 AWS Transform ワークスペース管理者 による検証後にのみデプロイメントが進行します。AWS Transform がネットワークをデプロイするために使用される場合、 VPC Reachability Analyzer サービス を使用してデプロイされたネットワーク全体の接続性を検証します。この柔軟なネットワーク構成と、様々な IaC ソリューションによるデプロイのサポートを組み合わせることで、安全で適切に設計されたネットワーク基盤が保証されます。 図 11: 生成された VPC 設定の確認と編集 このエージェントの強みは、その汎用性にあります。ネットワーク変換を単独の移行として実行することも、複数のターゲットアカウント間での検出、ウェーブプランニング、サーバー移行などの他のステップと統合することもできます。プロセス全体を通じて、提案されたネットワーク設定を確認および検証し、必要に応じて調整し、一貫したコンプライアンス要件を維持でき、最終的に潜在的な接続性の問題を最小化し、移行リスクを軽減します。 サーバー移行 移行プロセスの最終ステップとして、AWS Transform は AWS でネイティブに実行するようにサーバーを変換する自動化されたリホスティング機能でサーバー移行を効率化します。マイグレーションエージェントは、実績のある AWS Application Migration Service (AWS MGN) を活用してデータレプリケーションを処理しながら、ウェーブレベルと個別サーバーレベルの両方でマイグレーションの制御を提供します。 AWS MGN は、ソースサーバーあたり継続使用の最初の 90 日間は無料で利用できます。レプリケーション中およびテストまたはカットオーバーインスタンスを起動する際、AWS 料金プランに従って、Amazon EC2 インスタンスや Amazon EBS ボリュームなどのプロビジョニングされた AWS リソースに対して標準料金 が発生します。 サーバー移行は EC2 インスタンスの推奨 から始まり、AWS Transform はワークロード使用率に基づいてインテリジェントな適切サイジングオプションを提供します。平均または最大使用率メトリクスを選択して最適なインスタンスサイズを決定し、 専用または共有テナンシーオプション を選択し、考慮から除外する EC2 インスタンスタイプを指定できます。このカスタマイズ可能なアプローチにより、移行されたワークロードがパフォーマンスとコスト効率の両方に適切にサイズ設定されることが保証されます。 図 12: サーバーの EC2 推奨 AWS Transform は、移行ウェーブごとに 柔軟な IP アドレス指定オプション を提供し、ネットワーク要件に基づいて静的または動的 IP 割り当てを選択できます。以下を含む、マイグレーション予定のサーバーの包括的なインベントリを生成します: ターゲット EC2 インスタンスタイプの推奨 ターゲットサブネットの割り当て セキュリティグループ設定 前に選択した IP アドレス指定スキーム 移行を進める前に、インベントリを確認および変更して正確性を確保できます。マイグレーションエージェントのチャットベースのインターフェースは、粒度の細かいサーバーレベル制御を提供し、注意が必要な特定のケースに対してテストの復元やカットオーバーアクションなどの個別サーバー操作を管理できます。 AWS Transform は、次のようなサーバー移行の重要な側面を自動化します。 サーバーレプリケーション 互換性チェックと変換 テストと検証 カットオーバーオーケストレーション 自動化により、手作業によるエラーが大幅に削減され、アプリケーションの安定性を維持しながら移行期間が短縮されます。ステップ全体を通じて、AWS Transform は一般的な問題の詳細なエラー検出と説明を含む、強化されたエラーハンドリング機能を提供します。 図 13: サーバーのレプリケーションステータス AWS Transform は MGN を使用するため、プライベートデータ転送の場合サーバーは AWS Direct Connect または Site-to-Site VPN を通じてレプリケーションでき、パブリックインターネット接続の必要性を排除します。AWS Transform と AWS サービス間の通信に TLS 1.2 以上の暗号化を利用し、Amazon S3 バケットに保存されたデータに AWS 管理暗号化キーを使用して、転送中および保存中のデータの 包括的な暗号化を維持 します。 AWS Transform のモジュール型アプローチにより、サーバー移行を独立したプロジェクトとして実行することも、オーケストレーションされたマイグレーション戦略の一部として実行することもできます。ウェーブレベルと個別サーバーレベルの両方でサーバー移行テストとカットオーバーインスタンスを制御でき、サーバーを AWS に移行する方法を管理できます。 クリーンアップ クリーンアッププロセスは、本番環境の移行を実行したか、移行をテストしたかによって異なります。 本番移行の場合、必要に応じて AWS Transform コンソール から Transform ジョブを削除します。Transform ジョブを削除すると、ネットワーク IaC テンプレートや移行計画ドキュメントを含む、生成されたすべてのアーティファクトが永続的に削除されることに注意してください。削除を進める前に、必要なアーティファクトをバックアップしてください。マイグレーションされたリソースは本番環境で実行されているため、削除しないでください。 マイグレーションをテストしている場合は、以下を実行してリソースをクリーンアップします: AWS Transform コンソール に移動し、AWS Transform ジョブを削除し、ワークスペースを削除します (オプション) Amazon VPC コンソール に移動し、デプロイされたネットワークリソース (VPC、サブネット、セキュリティグループ) を削除します カットオーバーの完了後、AWS MGN サービスはステージングエリアのリソース (Amazon EC2 レプリケーションインスタンス、Amazon EBS ボリューム) をクリーンアップします。カットオーバーを完了していない場合は、手動で AWS MGN レプリケーションエージェントをアンインストール できます。 Amazon EC2 コンソール に移動し、レプリケーションリソースが終了していることを確認し、起動されたテスト/カットオーバーインスタンスを終了します。 まとめ この最新リリースのエージェント機能は、移行目標の達成に必要なインテリジェンスと柔軟性をお客様に提供するという AWS のコミットメントを表しています。要約すると、AWS Transform for VMware には以下の機能が追加されました: 複雑な移行タスクを簡素化するチャットベース操作 エンタープライズ規模のマイグレーションのためのマルチアカウントサポート リアルタイム変更を可能にする動的な移行計画 Cisco ACI、Palo Alto、Fortinet を含む拡張されたネットワークインフラストラクチャサポート 複数形式をサポートする柔軟な Infrastructure as Code (IaC) 生成 ウェーブレベルと個別サーバーレベルの両方での強化されたサーバー移行制御 これらの機能は連携して、制御を維持しリスクを軽減しながらマイグレーションジャーニーを加速するのに役立ちます。新機能は、エンドツーエンドのインフラストラクチャ移行から特定のワークロード移行まで、さまざまな移行シナリオをサポートし、ニーズに最適なアプローチを選択できます。 詳細については、 AWS Transform for VMware ページをご覧いただき、 最新機能について学び 、 AWS Transform を開始 してください。 Suhail Fouzan Suhail Fouzan は、IT 業界で 15 年以上の経験を持つ Amazon Web Services (AWS) の Specialist Solutions Architect です。Microsoft ワークロード、マイグレーションサービス、AWS Systems Manager を使用した運用管理を専門とし、お客様のインフラストラクチャの AWS への成功的なマイグレーションを支援しています。仕事以外では、クリケットをプレイし、家族と時間を過ごすことを楽しんでいます。 Bianca Velasco Bianca Velasco は AWS の Product Marketing Manager で、AWS での VMware ベースワークロードのマイグレーションと変革に焦点を当てています。マーケティングとテクノロジーで 7 年以上の経験を持ち、複雑なテクノロジーを意味のある関連性のあるものにするナラティブの作成に情熱を注いでいます。AWS 以外では、ボランティア活動、ダンス、ボルダリングを楽しんでいます。 Pedro Calixto Pedro Calixto は AWS の Senior Solutions Architect で、ワークロードのマイグレーションとモダナイゼーションを専門としています。企業がオンプレミス環境を AWS 内で拡張、マイグレーション、保護することを支援し、AWS サービスを使用したアプリケーションモダナイゼーションの加速に焦点を当てています。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。

本稿は弥生株式会社様と AWS Japan の共同執筆により、AI 駆動開発ライフサイクル（AI-DLC）Unicorn Gym の実践を通じて得られた学びと今後の取り組みをお伝えするものです。 はじめに 2025年、生成 AI の台頭により開発現場は大きな変革期を迎えました。弊社 (弥生株式会社) でも AI ツールの導入を推進してきましたが、従来の開発手法と AI のポテンシャルをどう融合させるべきか、プロダクトごとに異なる環境の中で最適な手法を模索している段階にありました。 こうした中、AWS が提唱する「 AI 駆動開発ライフサイクル（AI-DLC） 」が、開発プロセスを再定義する鍵になると考え、2025年12月10日から12日の3日間にわたって「AI-DLC Unicorn Gym」を AWS と共同で実施しました。本記事では、その実践から得られた学びを共有します。 これまでの課題 弥生株式会社では「AI 駆動開発」を掲げ、全社的に AI を活用してプロダクト開発の効率化を進めています。 一方で、個々のチームや個人の工夫に依存している部分がいまだに大きく、要件整理・設計・実装・テスト・運用までを一気通貫で支える “開発プロセスそのもの” の標準化にはまだ踏み込めていませんでした。 AI-DLC Unicorn Gym の実施内容 この課題に対し、弥生株式会社と AWS Japan は共同で「 AI-DLC Unicorn Gym」を開催しました。実際のプロダクトを対象として 3日間にわたって AI-DLC を実践し、その効果や導入に至るまでのギャップの検証に取り組みました。 今回の AI-DLC Unicorn Gym では、参加者が「AI チーム」と「サブスクチーム」の 2つの独立したチームに分かれ、それぞれ異なるプロダクトに対する機能の開発を通じて AI-DLC の効果を検証しました。ツールとしては AI IDE「 Kiro 」 を用いました。 チーム名 取り組み内容 参加者構成 成果 開発所要期間 (推定値→実績値) AI チーム 分析用 AI チャットツール、データ連携基盤および情報受け渡しフローの実装 エンジニア・ビジネス・デザイナー・マーケター・QA (計 12 名/ 3サブチーム) 動作するモックの完成 (一部 API 連携を除く) 1 ヶ月以上 → 2.5 日 サブスクチーム ユーザー登録・製品利用ライセンスの付与・認可 エンジニア・マーケター (計 8 名/2サブチーム) 動作するモックの完成 1 ヶ月以上 → 2.5 日 ※品質比較未実施 AI-DLC Unicorn Gym の学び 実質 2.5 日という限られた時間の中で、AI-DLC を実際のプロダクトに投入することで見えてきた「理想と現実のギャップ」がありました。これらは単なる失敗ではなく、今後の開発プロセスの改善に対する重要な学びでした。参加者からは「既存製品の仕様や制約をどのようにインプットさせるかの障壁は高いですが、導入しないと時代の流れに取り残されそうな強い危機感を覚えました。」といった感想が挙がりました。 「まず会議」から「まず AI」へ: AI-DLC Unicorn Gym の冒頭で私たちは「何を作るか」という議論で足踏みをしていました。正解のない不確実な領域で机上の議論にとどまり、多くの時間を費やしていました。この停滞に対し、 「もっと早い段階から AI を活用しましょう」 との助言を AWS メンバーからいただいたことが転換点となりました。自分たちだけで仕様を完璧に固めてから AI に渡すのではなく、言語化できていないモヤモヤした状態のまま AIに具体化してもらうフローへと切り替えました。 AI のアウトプットを議論の起点にすることで、不確実な状況下での意思決定が大幅に加速しました。人間だけで悩み続ける前に、AI に叩き台を作らせて判断することが会議の時間を短縮し、判断スピードを上げるための鍵となりました。 ロールの壁を越えるコラボレーション: 実装工程では、ロール（役割）の重要性を再認識しました。例としてフロントエンド実装において、デザイナーが書くプロンプトの解像度の高さには、エンジニア目線にはなかった視点が含まれていました。エンジニアでは言語化しにくい UI の勘所が、デザイナーの巧みなプロンプトによって具体化されました。同時に、ビジネスサイドが仕様の細部をその場で決断し、実装に反映させるサイクルも実現しました。並列でユニットの実装を進めることによる効率性と、上流工程における複数ロール間の協働こそが、AI-DLC を成功させるポイントであると実感しました。 一方でビジネスサイドやデザイナーも実作業に加わる中で、開発環境のセットアップで予想以上の時間をロスしてしまったことは大きな反省点です。また、作業が本格的なコーディングフェーズへ移行すると、エンジニア以外のメンバーがプロセスの詳細を追いきれず、議論から距離ができてしまう状況も発生しました。AI-DLC のメリットを最大化するためには、「誰もが即座にアウトプットに関与できる土台」と、「実装の進捗をチーム全員が直感的に理解できる共有の仕組み」が不可欠であることを認識しました。 AI 駆動の爆速並列開発を阻んだ「つなぎ込み」の壁: AI チームにおいて、最大の学びとなったのは「ユニット統合（つなぎ込み）」における課題でした。 今回は開発の並列度を高めるため、一つの機能を、フロントエンド・AI エージェント・バックエンドの 3 つのユニットに分割し、サブチームに分かれて並列で実装を進めました。しかし、各ユニットを統合するフェーズでいくつかの課題が明らかになりました。 並列開発における最大の課題は、バックエンドとの最終結合まで、各ユニット間でのこまめなマージや中間共有が十分にできていなかったことです。人間同士の開発であれば、日々のコミュニケーションで補完し合えていた「認識のズレ」が、AI が圧倒的な速度でアウトプットを出し続ける環境ではコードの不一致として積み上がり、最終的な統合コストを増大させてしまいました。事前の Pact (契約テストフレームワーク) によるガードレール整備や、マージ前の取り込みが不十分だったこと、規約の不備によるコードの衝突と命名規則の不一致が主な要因でした。 AI-DLC の爆速開発を支えるのは、「自由」ではなく「規約」でした。初期段階でインターフェースを厳密に定義し、こまめな同期によって認識のズレを解消すること、この「ガードレールを敷きながら走る」開発プロセス設計の徹底が重要であると感じました。 今後の取り組み AI-DLC Unicorn Gym で得た知見を単なる体験に留めず、実務へ還元していくために検討したいポイントをまとめました。 モブワークとスウォーミングによる停滞しない開発フローの構築: 同期的に意思決定を行う「モブワーク」と、自律的に並列実行する「スウォーミング」をシームレスに切り替える開発フローの適用を検討しています。 上流工程で複数ロールによるモブワークを徹底し、全員の認識を揃えた「ユニットオブワーク」へと落とし込みます。タスクを分解したのちに各メンバーが独立して動く「スウォーミング」へと移行することで、AI を休ませることなくフローを最大化するサイクルを構築していきたいと考えています。 AI との整合性を高める「ナレッジの資産化」: 人間と AI の協働によるポテンシャルを最大限活用するためには、AI が自律的に参照できる「共通のガードレール」の整備が不可欠です。 今後は、DDD（ドメイン駆動設計）に基づく業務知識や、TDD（テスト駆動開発）の指針などを Markdown 形式等で集約する “ Docs-as-Code” の考え方を取り入れたいと考えています。AI エージェントが常に最新の設計方針や規約を参照できる状態を整えることで、人間はタスクの推奨案の提示や軌道修正といった、より高度な判断に専念できる環境を目指します。 判断のための専門スキルとマインドセットの底上げ: AI が実装段階の大部分を担うようになることで、エンジニアの職能を「書くスキル」から「レビュー・判断するスキル」へとアップデートしていく必要があります。AI のアウトプットが正しいかを判定するには、これまで以上に深い専門知識が求められます。AI の回答を盲信するのではなく、その意図を正しく解釈し、的確に介入できるメタな視点でのスキルセットの構築を、個人・組織の両面で検討していきます。 まとめ AI-DLC は単なるツール導入ではなく、「プロセスそのものを再設計する」意思決定が必要となるアプローチです。 机上の議論に時間を費やしてしまう前に、まずは AI と共に見えるものを高速に作り上げ、壊し、また作る。試行回数を増やすことが AI 時代の開発における重要な戦略であると感じました。 今回の AI-DLC Unicorn Gym は対面形式で行われ、チーム全員が常に画面を共有しながら意思疎通を続けるプロセスを実践しました。このワーク形式は常に脳をフル回転させ続ける、大きな疲労感を伴うものでもありました。しかし、その濃密な時間の中でその場ですぐに方針を決定し、プロダクトが猛スピードで形になっていく様子を体験できたことは、非常に大きな収穫でした。 今回の学びは個人に留まらず、チームとして AI をどう活用し、開発プロセスをどうアップデートすべきかという点に集約されています。すべてを明日からそのまま適用できるわけではありませんが、既存プロダクトや環境との違いを考慮しながら、一つずつ現場への適用を模索していきます。AI-DLC Unicorn Gym で得た新しい考え方・経験を、弥生株式会社の新しい開発文化へと繋げていきたいと考えています。 著者 yuki sekiguchi 関口 勇樹 (Yuki Sekiguchi) 弥生株式会社 クラウドプロダクト開発部 エンジニア 受託開発にて様々なシステム構築を経験した後、2024年10月より弥生株式会社にエンジニアとして参画。現在は「AI を活用したプロダクト開発」を探求のテーマとし、プライベートでも AI エージェントによるライブラリ開発のトライアンドエラーを繰り返すなど、実践的な技術活用に注力している。また、 Zenn や note にて技術情報の発信も行っている。 futa kimura 木村 風太 (Futa Kimura) 弥生株式会社 クラウドプロダクト開発部 エンジニア バックオフィス職からエンジニアへ転身し、事業会社での開発経験を経て2023年8月から現職へ。現在は新製品開発に携わり、バックエンド中心にフルスタックで開発。全社的な AI 駆動開発推進の PM も担当しています。 yamazaki hiroki profile-20250806 山崎 宏紀 (Hiroki Yamazaki) 山崎宏紀 は Amazon Web Services Japan G.K. のソリューションアーキテクトとして、ISV/SaaS 業界のお客様を中心にアーキテクチャ設計や構築、生成 AI の活用をご支援しています。Kiro CLI や AWS CDK を好みます。(より良いご支援のために) AI エージェントに代わりに働いてもらおうと画策しています。

本稿は、株式会社日本取引所グループ（以下「JPX」）傘下の株式会社東京証券取引所（以下「東証」）による「膨大な取引データの処理 – AWS 活用で実現した次世代データ分析基盤」について、インフラ開発をリードされた齋藤 尚樹様に寄稿いただきました。 イントロダクション 東証は、株式売買システム arrowhead4.0 の稼働に伴い、膨大な注文や約定等の取引データに係るトランザクションを効率的に蓄積・分析するための新しいデータ分析基盤を構築しました。 arrowhead は、東証及び富士通が開発してきた世界最高水準の高速性・信頼性・拡張性を兼ね備えた株式売買システムで、2010 年の初代システムから進化を続け、2024 年 11 月 5 日には、市場利用者の利便性や国際競争力、レジリエンスをさらに高めることを目的とした arrowhead 4.0 が稼働しました。 近年、活況なマーケットや取引処理の高速化にともない、1 日に数億件という膨大なトランザクションを安定的に処理するキャパシティが求められると同時に、ピーク時には 1 秒間に 10 万件を超える高いスループットでデータが発生し続けるため、遅延なくリアルタイムでデータ処理できる性能も、データ分析基盤に求められます。 図：arrowheadの1日注文処理件数の推移（億件/日） 従来のデータ分析基盤では、こうした両面の要件を同時に満たすことが難しく、スケーラビリティや処理性能に限界がありました。こうした課題を解決するため、東証は AWS のクラウド技術を活用し、システムリソースやトランザクションログを蓄積・分析する高性能かつ柔軟なデータ分析基盤を AWS 上に整備しました。 背景と課題 近年、取引データの発生件数増加に伴い、arrowhead では日々数億件規模のデータが生成・蓄積され、それらの大量データが分析対象となっています。従来のデータ分析基盤では Excel VBA や個別開発したツール等を駆使していましたが、膨大なデータを扱うには非効率的であり 、半日以上に及ぶデータ抽出・集計処理が端末を占有するなど、日々の解析処理やレポート作成に多大な時間と労力を要していました。また、オンプレミス環境ではサーバ増設やストレージ拡張に時間がかかり、急速な市場変化や突発的な取引量の増加に柔軟に対応することが困難でした。さらに、システム全体の安定運用や障害発生時の迅速な原因特定、キャパシティ計画の高度化といった運用面での課題にも対応する必要がありました。 ソリューション概要 上記課題の解決に向けて AWS の各サービスをどのように活用したかについて、下図のアーキテクチャ図と共に解説します。 オンプレミス領域から AWS へのデータ連携においては、特にリアルタイム性と大規模データ処理能力が重視されます。arrowhead で1秒間に数万件単位で発生する各種電文ログやリソース監視データは、オンプレミス環境のサーバ上に集約されます。これらのデータは、サーバ上で稼働する Amazon Kinesis Agent によって取得され、 AWS Direct Connect や AWS Transit Gateway などの専用線ネットワークを経由して、安全かつ高速に AWS クラウド環境へ転送されます。その後、 Amazon Data Firehose を用いてリアルタイムで AWS 環境に連携されたのち Amazon S3 に蓄積され、 AWS Lambda による ETL 処理を経て Amazon Redshift に格納されます。この一連の処理を通じて、多種多様な膨大なデータを、セキュアかつ遅滞なく連携することを可能にしました。 このリアルタイム連携の主な対象となるのが「電文ログ」と「リソース監視データ」です。電文ログは、業務観点での分析や障害発生時のトラブルシューティングなど多岐にわたる用途で活用されます。また、リソース監視データは、CPU やメモリ、ネットワーク帯域、ディスク I/O など各種リソースの監視やボトルネック分析、将来的なキャパシティ拡張計画の根拠データとして利用されています。 Amazon Redshift は数億件規模のデータを高速かつ並列に処理することができ、ピーク時の高スループットにも耐えうるスケーラビリティを実現しています。これにより、電文ログやリソース監視データの大量集計・分析が短時間で可能となり、システム部門はリアルタイムに近い形で状況把握や性能解析を実施できます。 また、Amazon Redshift 上での分析結果は、ダッシュボードやレポートとして可視化され、JPX グループ全役職員が常時閲覧可能なかたちで展開されるとともに、異常検知や将来的なキャパシティ計画の根拠データとしても活用されています。例えば、過去の取引量やリソース使用状況の推移をもとに、将来的なシステム増強のタイミングや必要スペックを予測したり、障害発生時のリソース逼迫状況を迅速に特定することが可能となりました。 導入効果 AWS 上にデータ分析基盤を構築することによって、従来の手法では数時間要していたデータ分析処理が、Amazon Redshift を中心とした並列処理や AWS Lambda や AWS Step Functions による自動化により数分で完了するようになりました。これにより、運用担当者は日々の業務負荷を大幅に軽減し、より高度な分析や障害対応、改善活動にリソースを集中できるようになりました。また、AWS を使用することにより、必要なリソースをオンデマンドで追加できるため、突発的な取引データの増加や新たな分析ニーズにも柔軟に対応できるようになっています。さらに、性能監視やキャパシティ計画を自動化することで、システムの安定性と信頼性が向上し、障害発生時の影響範囲の特定や復旧対応の迅速化にも寄与しています。 今後の展望 今後、さらなる取引データの増加に対しても、安定した市場運営を継続するのはもとより、AI などによる異常検知や予測など、分析基盤としての一層の強化を AWS を活用して進めていく予定です。 執筆者 齋藤 尚樹 (株式会社東京証券取引所 IT開発部トレーディングシステム 調査役) 日本取引所グループに入社後、東京証券取引所のシステム部門において、株式売買システム「arrowhead」のインフラ開発のほか、RFQ プラットフォーム「CONNEQTOR」の初期開発からローンチ、運用まで一貫して担当し、取引インフラの高度化を推進。また、AWS を活用したデータ分析基盤を開発し、クラウド技術を活用したキャパシティ監視の運用効率化などを主導。

本ブログは 2025 年 12 月 15 日に公開された AWS Blog “ What AWS Security learned from responding to recent npm supply chain threat campaigns ” を翻訳したものです。 AWS のインシデント対応チームは、お客様、AWS クラウド、AWS グローバルインフラストラクチャを保護するために 24 時間体制で活動しています。この活動を通じて、さまざまな課題から学び、特徴的な傾向を発見しています。 ここ数か月、サードパーティのソフトウェアリポジトリに関連する注目度の高いソフトウェアサプライチェーン攻撃キャンペーンが発生し、あらゆる組織にとってソフトウェアサプライチェーンを保護することの重要性が浮き彫りになりました。この記事では、Nx パッケージの侵害、Shai-Hulud ワーム、Amazon Inspector が 15 万件を超える悪意のあるパッケージを特定したトークンファーミングキャンペーン (オープンソースレジストリで確認された最大規模の攻撃の 1 つ) など、最近の脅威に AWS がどのように対応したかをご紹介します。 AWS Security は、この記事で紹介する各事例に対して、一貫した体系的なアプローチで対応しました。AWS のインシデント対応アプローチの重要な部分は、将来のインシデントに備えてセキュリティを向上させるために、対応ワークフローとセキュリティシステムを継続的に改善することです。また、お客様とグローバルなセキュリティコミュニティの改善を支援することにも深くコミットしています。この記事の目的は、これらのインシデントへの対応経験と、そこから得た教訓を共有することです。 生成 AI を通じて拡散を試みた Nx の侵害 2025 年 8 月下旬、サードパーティソフトウェアの生成 AI プロンプト実行における異常なパターンが検出され、インシデント対応チームへ即時にエスカレーションが行われました。30 分以内にセキュリティインシデントの指揮体制が確立され、AWS の世界各地のチームが連携して調査を開始しました。 調査の結果、 侵害された 人気の npm パッケージ Nx を通じて、生成 AI コマンドラインツールを悪用するように設計された JavaScript ファイル「telemetry.js」の存在を特定しました。 AWS のチームはマルウェアを分析し、攻撃者が GitHub を通じて機密性の高い設定ファイルを窃取しようとしていたことを確認しました。しかし、有効なアクセストークンの生成に失敗したため、データが侵害されることはありませんでした。この分析により、AWS とお客様を保護するための直接的な対策に役立つ重要なデータが得られました。 インシデント対応プロセスの中で、AWS のチームが実施した主なタスクには以下が含まれます。 AWS サービスとインフラストラクチャの包括的な影響アセスメントを作成しました。このアセスメントは、インシデントの範囲を定義し、対応の一環として検証が必要な環境の領域を特定するマップとして機能します 侵害された npm パッケージへのさらなる露出を防ぐために、リポジトリレベルでの npm パッケージのブロックリスト登録を実施しました 影響を受けた可能性のあるリソースを特定し、他の攻撃ベクトルを探すための詳細な調査を実施しました 影響を受けたホストの調査、分析、修復を行いました 分析から得た知見を活用して、環境全体の検出機能を改善し、Amazon Q のセキュリティ対策を強化しました。これには、認証情報の窃取を拒否する新しいシステムプロンプトガードレール、システムプロンプトの抽出を防ぐ修正、権限の高い実行モードに対する追加の強化対策が含まれます この作業から得られた知見は、インシデント対応プロセスに取り込まれ、異常なふるまいを監視する方法と複数のインテリジェンスソースを相互参照する方法を改善することで、検出メカニズムを強化しました。これらの取り組みは、その後の npm サプライチェーン攻撃キャンペーンの特定と対応において重要な役割を果たしました。 Shai-Hulud とその他の npm キャンペーン その後、わずか 3 週間後の 2025 年 9 月上旬に、他の 2 つの npm サプライチェーンキャンペーンが始まりました。最初のキャンペーンは 18 の人気パッケージ (Chalk や Debug など) を標的とし、2 番目の「Shai-Hulud」と呼ばれるキャンペーンは、最初の波で 180 のパッケージを標的とし、2025 年 11 月下旬には第 2 波の「Shai-Hulud 2」が発生しました。これらのタイプのキャンペーンは、信頼された開発者のマシンを侵害して開発者がアクセス可能なシステムへの足がかりを得ようとします。 Shai-Hulud ワームは、npm トークン、GitHub パーソナルアクセストークン、クラウド認証情報を窃取しようとします。npm トークンが見つかると、Shai-Hulud は、それらのトークンが npm レジストリでアクセスできるパッケージの更新として、感染したパッケージを公開することで、その範囲を拡大します。侵害されたパッケージは postinstall スクリプトとしてワームを実行し、新しいユーザーがダウンロードするたびに次々と感染していきます。また、このワームは GitHub リポジトリを改ざんして悪意のあるワークフローを使用し、すでに感染したリポジトリで足がかりを維持しつつ、感染拡大を試みます。 これらのイベントはそれぞれ異なるアプローチを取りましたが、Nx パッケージの侵害への対応から AWS Security が学んだ教訓は、これらのキャンペーンへの対応に効果を発揮しました。Shai-Hulud の影響を受けたパッケージが公開されてから 7 分以内に、AWS は対応プロセスを開始しました。これらの対応中に実施した主なタスクには以下が含まれます。 影響を受けたパッケージを Open Source Security Foundation (OpenSSF) に登録し、セキュリティコミュニティ全体での連携対応を可能にしました > 詳細は AWS Security Blog 「サプライチェーン攻撃への防御策: Chalk/Debug 侵害と Shai-Hulud ワームの対応事例から」 をご参照ください。Amazon Inspector チームの検出システムがこれらのパッケージをどのように発見し、OpenSSF と連携してセキュリティコミュニティがこのようなインシデントに対応できるよう支援しているかについて説明しています。 異常なふるまいを検出するための監視を実施しました。疑わしいアクティビティが検出された場合、 AWS Personal Health Dashboard 通知、AWS サポートケース、アカウントのセキュリティ連絡先への直接メールを通じて、影響を受けたお客様に即座に通知しました ワームの完全な機能をより深く理解するために、侵害された npm パッケージを分析しました。この分析では、生成 AI を使用してカスタムデトネーションスクリプト (マルウェア実行スクリプト) を開発し、制御されたサンドボックス環境で安全に実行しました。この作業により、マルウェアが GitHub トークン、AWS 認証情報、Google Cloud 認証情報、npm トークン、環境変数を標的にするために使用する手法が明らかになりました。この情報を基に、AI を使用して難読化された JavaScript コードを分析し、既知の指標と影響を受けたパッケージの範囲を拡大しました 認証情報の窃取と一致する異常なふるまいの検出方法、npm リポジトリ全体のパターン分析方法、そして複数のインテリジェンスソースとの相互参照を改善することで、AWS Security はこれらのタイプの組織的なキャンペーンについての理解を深めることができました。これにより、正当なパッケージアクティビティとこれらのタイプの悪意のあるアクティビティを区別できるようになりました。この取り組みにより、わずか 1 か月後にはチームがさらに効果的に対応できるようになりました。 tea[.]xyz トークンファーミング 10 月下旬から 11 月上旬にかけて、Amazon Inspector チームが以前のインシデントで改良した手法により、侵害された npm パッケージの急増を検出しました。tea[.]xyz は、オープンソースソフトウェアの開発者やメンテナーに対して、プロジェクトの利用状況に応じて暗号資産の Tea トークンを付与するプラットフォームです。改良した検出システムは、このトークンを不正に取得しようとする新たな攻撃を検出しました。 チームは、脅威アクターのキャンペーン中に 15 万件の侵害されたパッケージを発見 しました。検出のたびに、チームは 30 分以内に悪意のあるパッケージを OpenSSF の悪意のあるパッケージレジストリに自動的に登録することができました。この迅速な対応により、Amazon Inspector を使用しているお客様を保護しただけでなく、これらの結果をコミュニティと共有することで、他のチームやツールも自社の環境を保護できるようになりました。 AWS Security チームは、脅威を検出するたびに、新しいことを学び、それをインシデント対応プロセスに取り込んで検出機能をさらに強化しています。このキャンペーンの独自のターゲットである tea[.]xyz トークンは、AWS Security チームが導入しているさまざまな検出と保護を改良する新たな機会となりました また、この記事をまとめていた 2025 年 12 月に、npm パッケージを標的とした新たな攻撃を確認しました。1 週間で npm レジストリで約 1,000 件の疑わしいパッケージを検出しました。”elf-” と呼ばれるこの攻撃は、機密性の高いシステムデータと認証情報を窃取するように設計されていました。AWS の自動防御メカニズムはこれらのパッケージを迅速に特定し、OpenSSF に報告しました。 組織を保護する方法 この記事では、AWS がインシデント対応プロセスからどのように学んでいるか、そして npm レジストリを標的とした最近のサプライチェーンキャンペーンが、AWS の内部システムと、お客様が責任共有モデルにおける責任を果たすために使用する製品の改善にどのように役立ったかを説明しました。お客様ごとに規模やシステムは異なりますが、 AWS Well-Architected フレームワーク と AWS Security Incident Response テクニカルガイド を組織の運用に組み込み、以下の戦略を採用して、このような攻撃に対する組織のレジリエンスを強化することをお勧めします。 継続的な監視と強化された検出を実装し、異常なパターンを特定して早期の脅威検出を可能にしてください。複数の信頼できるソースと結果を比較し、セキュリティツールの検出カバレッジを定期的に監査してください。 AWS Security Hub などの AWS サービスは、クラウド環境、セキュリティの検出結果、コンプライアンスチェックの包括的なビューを提供し、組織が大規模に対応できるようにします。また、 Amazon Inspector はソフトウェアサプライチェーンの継続的な監視を支援します 多層防御を採用してください。自動化された脆弱性スキャンと管理 ( Amazon GuardDuty や Amazon Inspector など)、パッケージの異常なふるまいの監視 ( Amazon CloudWatch と AWS CloudTrail など)、認証情報管理 ( IAM のセキュリティベストプラクティス )、データ漏洩を防ぐためのネットワーク制御 ( AWS Network Firewall ) を組み合わせて実装します 間接的な依存関係やデプロイ場所を含む、すべてのオープンソース依存関係の包括的なインベントリを維持し、脅威が特定されたときに迅速に対応できるようにしてください。 Amazon Elastic Container Registry (ECR) などの AWS サービスは、 コンテナイメージの脆弱性を自動スキャン でき、 AWS Systems Manager [1] [2] はセキュリティとコンプライアンスの目標を達成するように設定できます 疑わしいパッケージをメンテナーに報告し、業界グループと脅威インテリジェンスを共有し、集団防御を強化するイニシアチブに参加してください。最近投稿されたセキュリティ速報の詳細については、 AWS セキュリティ速報 ページをご参照ください。パートナーシップとグローバルなセキュリティコミュニティへの貢献は重要です セキュリティツール、専門家、実践的な対応手順を組み合わせた、プロアクティブなリサーチ、包括的な調査、連携した対応 ( AWS Security Incident Response など) を実装してください この記事で紹介した例が示すように、サプライチェーン攻撃は巧妙さと規模において進化し続けています。これらのキャンペーンには共通のパターンがあります。オープンソースネットワーク内の信頼関係の悪用、大規模な運用、認証情報の窃取と不正なシークレットアクセス、そして従来のセキュリティ制御を回避するための高度な手法の使用です。 これらのイベントから得られた教訓は、多層的なセキュリティ制御の実装、継続的な監視の維持、そして協調的な防御活動への参加が極めて重要であることを示しています。これらの脅威が進化し続ける中、AWS は包括的なセキュリティアプローチを通じてお客様に継続的な保護を提供し続けます。AWS は、自社の業務改善、お客様への支援、そしてセキュリティコミュニティへの貢献のために、継続的な学習に取り組んでいます。 この記事への貢献者: Mark Nunnikhoven、Catherine Watkins、Tam Ngo、Anna Brinkmann、Christine DeFazio、Chris Warfield、David Oxley、Logan Bair、Patrick Collard、Chun Feng、Sai Srinivas Vemula、Jorge Rodriguez、Hari Nagarajan この記事に関するご質問がある場合は、 AWS サポート にお問い合わせください。 Nikki Pahliney Nikki は AWS Security Messaging Manager として、外部のお客様向けのセキュリティコミュニケーションのキュレーション、AWS Security Blog および aws.amazon.com/security のウェブコンテンツの管理に携わるセキュリティメッセージングスペシャリストのチームを率いています。IT セキュリティとセキュリティメッセージング、業務プロセスの再設計、テクニカルプログラムマネジメント、財務モデリング、ビジネスマネジメント、採用など、幅広い経験を持っています。 David Magnotti David Magnotti は Amazon Threat Intelligence のプリンシパルセキュリティエンジニアです。Amazon のサイバー脅威インテリジェンス機能を支える調査プログラムの設計と運用を担当しています。国家支援型や高度な犯罪活動を含むサイバー脅威アクティビティの分析に注力し、調査結果を Amazon と AWS 全体で実行可能な保護策に変換しています。 Jeff Laskowski Jeff は、エンタープライズトランスフォーメーションと戦略的イノベーションにおいて 30 年以上の経験を持つ、サイバーセキュリティと IT のベテランエグゼクティブです。現在は AWS のシニアマネージャーとして、グローバルな企業サイバーセキュリティ対応に注力しています。注目度の高いサイバーインシデント調査の指揮、サイバー攻撃からの復旧の指揮、戦略的イニシアチブの推進など、輝かしいキャリアを持っています。バージニア州ハーンドンを拠点とし、Old Dominion University でコンピュータサイエンスを専攻しました。ソフトウェア開発、エンタープライズアーキテクチャ、セキュアな IT 環境に関する専門知識を持っています。 Ryan Tick Ryan は AWS のシニアセキュリティエンジニアで、大規模な脅威検出とインシデント対応に注力しています。AWS 入社前は、コンサルタントとして AWS における潜在的なセキュリティイベントの予防、準備、対応についてお客様を支援していました。仕事以外では、家族との時間を過ごしたり、Notre Dame Fighting Irish のフットボールチームを応援したり、旅行を楽しんでいます。 Charlie Bacon Charlie は AWS の Amazon Inspector のセキュリティエンジニアリングおよびリサーチ責任者です。Amazon Inspector やその他の Amazon Security 脆弱性管理ツールを支える脆弱性スキャンとインベントリ収集サービスのチームを率いています。AWS 入社前は、金融およびセキュリティ業界で 20 年間、リサーチと製品開発の両方でシニアロールを務めていました。 Chi Tran Chi は Amazon Web Services のシニアセキュリティリサーチャーで、オープンソースソフトウェアのサプライチェーンセキュリティを専門としています。オープンソースソフトウェアの悪意のあるパッケージを検出する Amazon Inspector のエンジンの研究開発を主導しています。Amazon Inspector の SME として、複雑なセキュリティ実装や高度なユースケースについてお客様に技術的なガイダンスを提供しています。クラウドセキュリティ、脆弱性リサーチ、アプリケーションセキュリティにわたる専門知識を持っています。OSCP、OSCE、OSWE、GPEN などの業界認定資格を保有し、複数の CVE を発見し、オープンソースセキュリティイノベーションに関する特許を出願中です。 Dan Dutrow Dan は AWS Security のソフトウェア開発マネージャーです。Amazon が AWS 全体のネットワーク、アプリケーション、認証情報の悪用を特定し阻止するためにセキュリティテレメトリを分析する内部ツール Sonaris を率いています。ソフトウェアエンジニアリング、データサイエンス、セキュリティ分析を活用してクラウドセキュリティの課題を解決する、学際的なチームの経験豊富なエンジニアリングリーダーです。 Stephen Goodman Stephen は Amazon アクティブディフェンスのシニアマネージャーとして、AWS のお客様とインターネットを脅威アクターから保護するためのデータ駆動型プログラムを主導しています。 Albin Vattakattu BlackHat および DEFCON のスピーカーである Albin は、AWS のシニアセキュリティエンジニア兼チームリードです。ネットワークおよびアプリケーションセキュリティにおいて 10 年以上の専門知識を持っています。AWS 入社前は、北米および南米でインシデント対応チームを率いていました。ニューヨーク大学でサイバーセキュリティの修士号を取得し、CISSP を含む複数のセキュリティ認定資格を保有しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。