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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

みなさん、こんにちは。Amazon Connect ソリューションアーキテクトの坂田です。 2026年2月に発表された Amazon Connect のアップデートをまとめてお届けします。今月は、エージェントの通話品質を向上させる音声強化機能や、タスクの AI 概要・推奨アクション、ダッシュボードのきめ細かいアクセス制御、Amazon Connect Cases の複数の機能拡張、スケジューリングやアウトバウンドキャンペーンの運用改善など、合計 13件のアップデートが発表されました。加えて、AWS Contact Center Blog では AI エージェントの活用やコンタクトセンター移行のベストプラクティスなど 4件のブログ記事が公開されています。以下、カテゴリごとにご紹介します。 目次 注目のアップデートについて 2026年2月のアップデート一覧 エージェント体験の向上 AI・分析機能の強化 Amazon Connect Cases の機能強化 スケジューリングとアウトバウンドキャンペーン AWS Contact Center Blog のご紹介 まとめ 1. 注目のアップデートについて 今月の注目アップデートは以下の 3つです! 注目 1: Amazon Connect が騒音環境向けのオーディオ拡張機能を導入 ひとつめは、2月4日に発表された Audio Enhancement 機能 です。これは、エージェント側の音声をリアルタイムで処理し、エンドカスタマーが聞く音声品質を向上させるものです。コンタクトセンターではしばしば、他のエージェントの会話やネットワーク機器から発せられる騒音など、周囲の雑音が気になることがあります。今回のアップデートは、こうした環境で業務を行うエージェントにとって特に有用な機能です。 この機能には 2つのモード が用意されています。 ノイズ抑制（Noise Suppression）モード : バックグラウンドノイズを低減します。有線・無線ヘッドセット、ヘッドセットなしのいずれの構成でも利用可能です。 音声分離（Voice Isolation）モード : ノイズ低減に加え、コンタクトセンター内で複数の人が話している環境でもエージェントの音声を分離します。有線ヘッドセット使用時のみ推奨されます。 有効化方法 : 管理者がユーザー管理画面から対象エージェントの Phone type を Soft phone に設定し、Audio Enhancement のモードを選択します。設定変更は次の通話から適用されます。セキュリティプロファイルの「コンタクトコントロールパネル (CCP)」権限の「オーディオデバイスの設定」を有効にすると、エージェント自身が CCP 上でモードを切り替えることも可能です。 API サポート : CreateUser / UpdateUserConfig API の VoiceEnhancementConfigs パラメータ、Amazon Connect Streams API の agent.setVoiceEnhancementMode() 、ConnectSDK の Voice API に対応しています。 前提条件 : ソフトフォンユーザーのみ対象。最低 4コア CPU（仮想マシンは 4 vCPU）が必要。VDI 環境ではローカルブラウザアクセス方式のみサポート（Amazon Connect audio optimization 方式は非対応）。 利用可能リージョン : Amazon Connect が提供されているすべての AWS 商用リージョン 関連リソース : Amazon Connect でエージェントのオーディオ強化を有効にする 注目 2: タスクの AI 概要と推奨アクション 概要 : Amazon Connect にタスクの AI 概要と推奨アクション機能が追加されました。エージェントがタスクを受け取った際に、AI が過去のアクティビティを要約し、次に取るべきアクションを提案します。例えば、オンラインフォームから送信された返金リクエストのタスクを受け取った場合、注文詳細の確認、返品資格のチェック、支払い方法の確認といった過去のアクティビティが要約され、返金を完了するための推奨ステップが提示されます。この機能を有効にするには、タスクがエージェントに割り当てられる前のフローに コネクトアシスタント フローブロックを追加します。ナレッジベースを追加することで、推奨内容をさらにガイドすることも可能です。 利用可能リージョン : Amazon Connect のリアルタイムエージェントアシスタンスが利用可能なすべての AWS リージョン 関連リソース Amazon Connect のフローブロック: Connect Assistant 注目 3: Agent Workspace での通知機能 概要 : Amazon Connect Agent Workspace に通知機能が追加されました。ワークスペースのヘッダーに通知が表示され、どのページからでも確認できるため、エージェントやビジネスユーザーは現在の作業を中断することなく、緊急のアップデートやポリシー変更、アクションアイテムなどの重要な情報を受け取ることができます。新しい通知 API を使用することで、組織内の特定のオーディエンスに対してプログラムからターゲットメッセージを送信することが可能です。パブリック API および AWS CloudFormation にも対応しています。 利用可能リージョン : Amazon Connect が提供されているすべての AWS リージョン 関連リソース : ワークスペースヘッダーの通知機能 通知の設定方法 通知の作成・送信はすべて API 経由で行います。Amazon Connect の Notifications API として以下の8つのアクションが提供されています。 CreateNotification : 新しい通知を作成し、指定した受信者に配信します UpdateNotificationContent : 既存の通知内容を更新します DeleteNotification : 通知を削除します DescribeNotification / ListNotifications / SearchNotifications : 通知の詳細取得・一覧・検索を行います ListUserNotifications : 特定ユーザーの通知一覧を取得します UpdateUserNotificationStatus : ユーザーの通知ステータス（既読/未読）を更新します 通知を作成する際の主なパラメータは以下の通りです。 Content : ロケールコード（ ja_JP 、 en_US など 11言語）をキーとしたマップ形式で、各言語の通知テキストを指定します（1言語あたり最大 500文字）。リンクの埋め込みにも対応しています。 Recipients : 受信者のユーザー ARN を配列で指定します（最大 200件）。インスタンス ARN を指定すると、インスタンス内の全ユーザーに送信できます。 Priority : HIGH または LOW を指定します。高優先度の通知は低優先度より上に表示されます。 ExpiresAt : 通知の有効期限をタイムスタンプで指定します。未指定の場合、デフォルトで作成から1週間後に自動的に非表示になります。 Tags : タグベースアクセス制御（TBAC）に使用するタグを付与できます。 アクセス制御 通知の受信には追加の権限は不要ですが、通知の作成・編集・削除・送信済み通知の閲覧には API 権限が必要です。タグベースアクセス制御（TBAC）により、管理者は自身に割り当てられたタグと一致する通知のみを管理でき、一致するタグを持つユーザーにのみ送信できます。階層ベースアクセス制御（HBAC）では、管理者は自身の階層レベル以下のユーザーにのみ通知を送信できます。 2. 2026年2月のアップデート一覧 2.1. エージェント体験の向上 エージェントパフォーマンス評価の異議申し立てワークフロー （2026年2月3日） 概要 : エージェントがパフォーマンス評価に対して異議を申し立てるための統合ワークフローが追加されました。エージェントは評価に同意できない場合、Connect UI 上から理由を添えて異議を申し立てることができます。指定されたマネージャーには自動メール通知が送信され、異議の確認と解決を行います。マネージャーは異議が申し立てられた評価の一覧やステータスを追跡でき、タイムリーな解決が可能です。 利用可能リージョン : Amazon Connect が提供されているすべてのリージョン 関連リソース : 評価の異議申し立て Audio Enhancement（音声強化）によるエージェント通話品質の向上 （2026年2月4日） 注目 1 を確認してください! チャット・タスク・Eメール・コールバックの自動応答（Auto-Accept）設定 （2026年2月5日） 概要 : チャット、タスク、Eメール、コールバックの各チャネルに対して、エージェントの自動応答（Auto-Accept）を設定できるようになりました。自動応答を有効にすると、着信コンタクトがエージェントの手動承認を待たずに自動的に接続されるため、顧客への迅速な対応が可能になります。これまでこの設定はインバウンド音声通話に対してのみ利用可能でしたが、今回のアップデートでチャネルごとに個別に設定できるようになりました。例えば、タスクには自動応答を有効にしつつ、音声通話では無効のままにするといった運用が可能です。 利用可能リージョン : Amazon Connect が提供されているすべての AWS リージョン 関連リソース : 自動応答の有効化 チャネル別の後処理（ACW）タイムアウト設定 （2026年2月11日） 概要 : チャット、タスク、Eメール、コールバックの各チャネルに対して、エージェントの後処理（After Contact Work）タイムアウトを設定できるようになりました。ACW タイムアウトにより、エージェントが後処理に費やせる時間を制限し、タイムアウト後は自動的に対応可能状態に戻ります。これは、エージェントごと、チャネルごとに異なるタイムアウトを設定でき、例えばEメールには短い ACW タイムアウトを設定しつつ、音声通話には次の顧客対応に備えるためのクールダウン時間として長めのタイムアウトを維持するといった運用が可能です。 利用可能リージョン : Amazon Connect が提供されているすべての AWS リージョン 関連リソース : エージェントの設定 Agent Workspace 内の通知機能の追加 （2026年2月13日） 注目 3 を確認してください! 2.2. AI・分析機能の強化 音声インタラクションのテスト・シミュレーション API （2026年2月） 概要 : コンタクトセンターの体験をシミュレーションするテストを構成・実行するための API が追加されました。発信者の電話番号やカスタマープロファイル、通話理由（「注文状況を確認したい」など）、期待される応答（「リクエストが処理されました」など）、営業時間外やキュー満杯といったビジネス条件をプログラムで設定できます。CI/CD パイプラインへの統合、複数テストの同時実行、デプロイサイクルの一部としての自動回帰テストが可能になり、ワークフローの変更を迅速に検証して本番環境へ自信を持ってデプロイできます。 利用可能リージョン : アジアパシフィック（ムンバイ、ソウル、シンガポール、シドニー、東京）、アフリカ（ケープタウン）、欧州（フランクフルト、ロンドン）、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部） 関連リソース : Amazon Connect API リファレンス タスクの AI 概要と推奨アクション （2026年2月13日） 注目 2 を確認してください! ダッシュボードのきめ細かいアクセス制御 （2026年2月12日） 概要 : Amazon Connect ダッシュボードにきめ細かいアクセス制御機能が追加されました。リソースタグを適用することで、特定のエージェント、キュー、ルーティングプロファイルなどのリソースに対するメトリクスの表示権限を制御できます。タグを使用してメトリクスをフィルタリングし、同じタグを共有するエージェントやキューの集計メトリクスを表示することも可能です。例えば、エージェントに「Department:Customer Service」タグを付与することで、カスタマーサービスチームのマネージャーのみがダッシュボードメトリクスを閲覧できるよう制限できます。 利用可能リージョン : Amazon Connect が提供されているすべての AWS 商用リージョンおよび AWS GovCloud (US-West) 関連リソース : ダッシュボードのタグベースアクセス制御 2.3. Amazon Connect Cases の機能強化 依存フィールドオプションをマッピングするための CSV アップロードをサポート （2026年2月6日） 概要 : Amazon Connect Cases のケースフィールドに設定する依存フィールドドロップダウンメニューを CSV ファイルのアップロードで一括設定できるようになりました。依存フィールドオプションは、カスケードドロップダウンメニューを作成します。1 つのフィールド (ターゲットフィールド) で使用可能な選択肢は、別のフィールド (ソースフィールド) で選択された値によって異なります。CSV ファイルは「Parent Field Name」「Child Field Name」「Parent Value」「Child Value」の4列フォーマットで、各行が1つの親子関係を表します。1つの CSV ファイルに複数のフィールドペアを含めることも可能です。地理的な階層構造（国 → 都道府県 → 市区町村）や製品カテゴリの分類（カテゴリ → サブカテゴリ）など、複雑な階層データの設定作業を大幅に効率化できます。なお、ソースフィールドとターゲットフィールドはいずれも単一選択型である必要があります。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト、ロンドン)、アジアパシフィック (ソウル、シンガポール、シドニー、東京)、アフリカ (ケープタウン) 関連リソース : 依存フィールドオプション 依存フィールドオプションの CSV アップロード ケーステンプレートでの複数行テキストフィールドのサポート （2026年2月17日） 概要 : ケーステンプレートで複数行テキストフィールドがサポートされるようになりました。この新しいフィールドタイプは、複数の段落に対応して縦方向に拡張されるため、エージェントは根本原因分析、取引の詳細、調査結果などの詳細な自由記述ノートや構造化データをケース内に直接記録できます。これまでの単一行テキストフィールドでは記録しきれなかった詳細情報を、ケースに直接紐づけて管理できるようになり、ケース管理の質が向上します。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト、ロンドン)、アジアパシフィック (ソウル、シンガポール、シドニー、東京)、アフリカ (ケープタウン) 関連リソース : Amazon Connect Cases でケースフィールドを作成する AWS Service Quotas との統合 （2026年2月18日） 概要 : Amazon Connect Cases が AWS Service Quotas に対応しました。管理者は Service Quotas コンソールから、適用されているクォータの確認、使用率のモニタリング、およびクォータの引き上げリクエストを一元的に行えるようになりました。対象となるクォータの引き上げリクエストは手動介入なしで自動承認されるため、予期しないサービス制約に遭遇することなくケースワークロードをスケールできます。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト、ロンドン)、アジアパシフィック (ソウル、シンガポール、シドニー、東京)、アフリカ (ケープタウン) 関連リソース : Amazon Connect Cases のサービスクォータ 2.4. スケジューリングとアウトバウンドキャンペーン ドラフトスケジュールでのエージェント休暇リクエスト表示 （2026年2月17日） 概要 : 承認済みのエージェント休暇リクエストがドラフトスケジュール内に表示されるようになりました。スケジュール管理者は、特定の日にエージェントがスケジュールされなかった理由を容易に確認でき、スケジュールを公開する前にカバレッジのギャップを特定して調整することが可能になります。これにより、スケジュール作成時の可視性が向上し、人員配置の最適化に役立ちます。 利用可能リージョン : Amazon Connect のエージェントスケジューリングが利用可能なすべての AWS リージョン 関連リソース : 休暇管理 アウトバウンドキャンペーンのダイヤルモード動的切り替え （2026年2月26日） 概要 : アウトバウンドキャンペーンにおけるダイヤルモードの動的切り替え機能が発表されました。コンタクトセンターの管理者は、アクティブなキャンペーン実行中にプレビューモードと非プレビューモード（プログレッシブダイヤルなど）を切り替えることができます。従来はキャンペーン開始後にダイヤルモードを変更するにはキャンペーンの停止と再起動が必要でしたが、今回のアップデートによりキャンペーンを中断することなくリアルタイムで切り替えが可能になりました。例えば、高優先度のコンタクトに対応する際にプログレッシブダイヤルからプレビューモードに切り替え、追加のコンテキストを確認した後、通常のトラフィックパターンに戻った際に元のモードに復帰させるといった運用が可能です。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト、ロンドン)、アジアパシフィック (ソウル、シンガポール、シドニー、東京)、アフリカ (ケープタウン) 関連リソース : アウトバウンドキャンペーンの設定 3. AWS Contact Center Blog のご紹介 2026年2月には、AWS Contact Center Blog において Amazon Connect に関連する 4件のブログ記事が公開されました。機能アップデートの発表とは別に、AI エージェントの活用方法やコンタクトセンター移行のベストプラクティスなど、実践的な知見が共有されています。 AI エージェントによるハイパーパーソナライゼーション （2026年2月2日） Amazon Connect Customer Profiles と Amazon Personalize を組み合わせ、顧客対応中にリアルタイムでパーソナライズされた商品レコメンデーションを提供する方法を解説しています。「おすすめ商品」「類似アイテム」「よく一緒に購入される商品」「人気商品」「トレンド商品」の5つのレコメンデーションユースケースが紹介されており、AI エージェントのガードレールやプロンプトのカスタマイズによるブランド一貫性の確保方法も説明されています。さらに、アウトバウンドキャンペーンを活用したプロアクティブな Web 通知の配信についても触れられています。 CX 業界予測 2026 （2026年2月3日） 2026年のカスタマーエクスペリエンス（CX）業界の展望をまとめたソートリーダーシップ記事です。AVOA、Cavell、IDC、Constellation Research などのアナリストの見解を集約し、「オーケストレーション（断片的な AI 導入から統合的なマルチエージェント体験へ）」「トラスト（AI ガバナンスフレームワークの構築）」「スケール（AI 成果の測定可能なビジネスアウトカムへの転換）」の3つのテーマで整理されています。 Amazon Connect への移行ベストプラクティス （2026年2月26日） 既存のコンタクトセンターから Amazon Connect への移行における「人」の側面に焦点を当てた包括的なガイドです。オペレーションチーム（エージェント、スーパーバイザー、QA アナリスト、ワークフォースマネージャー）、インフラストラクチャチーム（テレフォニーエンジニア、ACD 管理者、ネットワークスペシャリスト）、アプリケーションチーム（CX 開発者、エージェントデスクトップ開発者、ルーティング開発者）の3カテゴリに分けて、レガシーロールから Amazon Connect ロールへのトレーニングパスが詳細に解説されています。 Kiro を活用した AI エージェント開発の高速化 （2026年2月27日） AI コーディングアシスタント Kiro を使用して、15 のバックエンド API を統合した Amazon Connect AI エージェントをわずか3日間で構築した事例を紹介しています。通常 2〜3週間かかる POC 開発を大幅に短縮し、Kiro によるアーキテクチャ設計、Lambda 関数のコード生成、CloudWatch ログ分析によるデバッグ、MCP ツールスキーマの作成といった開発プロセスが解説されています。Amazon Bedrock Agents、AWS Lambda、Amazon DynamoDB、Amazon Bedrock AgentCore Gateway を活用した統合パターンが示されています。 4. まとめ 2026年2月は、エージェント体験の向上（Audio Enhancement、チャネル別設定、Agent Workspace 内の通知機能）、AI・分析機能の強化（タスクの AI 概要・推奨アクション、ダッシュボードのきめ細かいアクセス制御）、Amazon Connect Cases の機能強化（CSV 一括設定、複数行テキスト、Service Quotas 統合）、そしてスケジューリングとアウトバウンドキャンペーンの運用改善と、幅広い領域にわたる13件の機能アップデートが発表されました。 特に、Audio Enhancement によるエージェントの通話品質向上、タスクの AI 概要・推奨アクションによるエージェント生産性の向上、そしてアウトバウンドキャンペーンのダイヤルモード動的切り替えは、日々のコンタクトセンター運用に直接的なメリットをもたらす注目のアップデートです。 また、AWS Contact Center Blog では、AI エージェントによるハイパーパーソナライゼーション、CX 業界の 2026年予測、Amazon Connect への移行ベストプラクティス、Kiro を活用した AI エージェント開発の高速化の 4件のブログ記事が公開されました。機能アップデートと合わせて、これらのブログ記事もぜひご確認ください。 今後も最新の Amazon Connect のアップデート情報は AWS の What’s New ページ や Amazon Connect のリリースノート 、そして AWS Contact Center Blog で確認できます。引き続き最新情報をチェックしてみてください。 シニア スペシャリスト ソリューションアーキテクト/Amazon Connect, 坂田 陽一郎

2026 年 3 月 12 日、 Amazon Simple Storage Service (Amazon S3) の新機能を発表しました。この機能を使用すると、独自のアカウントのリージョン名前空間に汎用バケットを作成でき、データストレージの規模や用途の拡大に伴うバケットの作成および管理を簡素化できます。複数の AWS リージョンにまたがる汎用のバケット名を作成すると、希望するバケット名をいつでも使用できることが保証されます。 この機能を使用すると、リクエストしたバケット名にアカウント固有のサフィックスを追加することで、自分のアカウントのリージョナル名前空間に予測どおりの名前を付けて汎用バケットを作成できます。たとえば、アカウントのリージョナル名前空間にバケット mybucket-123456789012-us-east-1-an を作成できます。 mybucket は指定したバケット名のプレフィックスです。次に、リクエストされたバケット名にアカウントのリージョナルサフィックス -123456789012-us-east-1-an を追加します。別のアカウントが私のアカウントのサフィックスを使用してバケットを作成しようとすると、そのアカウントのリクエストは自動的に拒否されます。 セキュリティチームは、 AWS Identity and Access Management (AWS IAM) ポリシーと AWS Organizations サービスコントロールポリシーを使用して、従業員が新しい s3: x-amz-bucket-namespace 条件キーを使用してアカウントのリージョナル名前空間にのみバケットを作成するように強制できます。これにより、チームが組織全体でアカウントのリージョナル名前空間を採用しやすくなります。 アカウントのリージョナル名前空間を実際に使って S3 バケットを作成する 開始するには、 Amazon S3 コンソール で [バケットを作成] を選択します。アカウントのリージョナル名前空間にバケットを作成するには、 [アカウントのリージョナル名前空間] を選択します。このオプションを選択すると、アカウントとリージョンに固有の任意の名前でバケットを作成できます。 この設定は、グローバル名前空間の汎用バケットと同じ機能をすべてサポートします。唯一の違いは、アカウントのサフィックスが付いたバケット名を使用できるのはそのアカウントのみであるという点です。バケット名のプレフィックスとアカウントのリージョナルサフィックスを合わせた長さは、3～63 文字以内にする必要があります。 AWS コマンドラインインターフェイス (AWS CLI) を使用して、 x-amz-bucket-namespace: account-regional リクエストヘッダーを指定し、互換性のあるバケット名を指定することで、アカウントのリージョナル名前空間のバケットを作成できます。 $ aws s3api create-bucket --bucket mybucket-123456789012-us-east-1-an \ --bucket-namespace account-regional \ --region us-east-1 AWS SDK for Python (Boto3) を使用すると、 CreateBucket API リクエストを使用してアカウントのリージョナル名前空間を持つバケットを作成できます。 import boto3 class AccountRegionalBucketCreator: """アカウントリージョナル名前空間機能を使用して S3 バケットを作成します。""" ACCOUNT_REGIONAL_SUFFIX = "-an" def __init__(self, s3_client, sts_client): self.s3_client = s3_client self.sts_client = sts_client def create_account_regional_bucket(self, prefix): """ 指定されたプレフィックスを持つアカウントリージョナルの S3 バケットを作成します。 STS GetCallerIdentity API を使用して発信者の AWS アカウント ID を取得します。 フォーマット: ---an """ account_id = self.sts_client.get_caller_identity()['Account'] region = self.s3_client.meta.region_name bucket_name = self._generate_account_regional_bucket_name( prefix, account_id, region ) params = { "Bucket": bucket_name, "BucketNamespace": "account-regional" } if region != "us-east-1": params["CreateBucketConfiguration"] = { "LocationConstraint": region } return self.s3_client.create_bucket(**params) def _generate_account_regional_bucket_name(self, prefix, account_id, region): return f"{prefix}-{account_id}-{region}{self.ACCOUNT_REGIONAL_SUFFIX}" if __name__ == '__main__': s3_client = boto3.client('s3') sts_client = boto3.client('sts') creator = AccountRegionalBucketCreator(s3_client, sts_client) response = creator.create_account_regional_bucket('test-python-sdk') print(f"Bucket created: {response}") AWS CloudFormation などの Infrastructure as Code (IaC) ツールを更新すると、アカウントのリージョナル名前空間にバケットを簡単に作成できます。AWS CloudFormation には AWS:: AccountId と AWS::Region という疑似パラメータが用意されているため、アカウントのリージョナル名前空間バケットを作成する CloudFormation テンプレート を簡単に構築できます。 次の例は、既存の CloudFormation テンプレートを更新して、アカウントのリージョナル名前空間にバケットの作成を開始する方法を示しています。 BucketName: !Sub "amzn-s3-demo-bucket-${AWS::AccountId}-${AWS::Region}-an" BucketNamespace: "account-regional" または、 BucketNamePrefix プロパティを使用して CloudFormation テンプレートを更新することもできます。 BucketNamePrefix を使用すると、バケット名の顧客定義部分のみを指定でき、リクエスト元の AWS アカウントと指定されたリージョンに基づいて、アカウントのリージョナル名前空間サフィックスが自動的に追加されます。 BucketNamePrefix: 'amzn-s3-demo-bucket' BucketNamespace: "account-regional" これらのオプションを使用すると、カスタム CloudFormation テンプレートを構築して、アカウントのリージョナル名前空間に汎用バケットを簡単に作成できます。 知っておくべきこと 既存のグローバルバケットの名前をアカウントのリージョナル名前空間のバケット名に変更することはできませんが、アカウントのリージョナル名前空間に新しい汎用バケットを作成することはできます。また、アカウントのリージョナル名前空間は汎用バケットでのみサポートされています。S3 テーブルバケットとベクトルバケットはアカウントレベルの名前空間にすでに存在し、S3 ディレクトリバケットはゾーン名前空間に存在します。 詳細については、Amazon S3 ユーザーガイドの「 汎用バケット用の名前空間 」を参照してください。 今すぐご利用いただけます Amazon S3 のアカウントのリージョナル名前空間に汎用バケットを作成できるようになりました。これは、AWS 中国、AWS GovCloud (米国) リージョンを含む 37 の AWS リージョンで利用可能です。アカウントの リージョナル名前空間に汎用バケットを追加費用なしで作成できます。 Amazon S3 コンソール で 今すぐお試しいただき、 AWS re:Post for Amazon S3 宛てに、または通常の AWS サポート担当者を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

本稿は、2026 年 3 月 9 日に AWS migration-and-modernization Blog で公開された Microsoft and VMware workloads on AWS: Your complete AWS re:Invent 2025 playlist を翻訳したものです。 AWS 上で Microsoft および VMware ワークロードを移行およびモダナイズするには、適切な戦略、ツール、実際の検証が必要です。このプレイリストは、AWS re:Invent 2025 のトップセッションをまとめたもので、 AWS Transform によるエージェント型 AI を活用した自動化、AWS 上でのネイティブな VMware の実行、大規模に実施した顧客からの教訓を取り上げ、クラウドジャーニーのあらゆる段階における実践的なガイダンスを提供します。 大規模な移行とモダナイゼーションのためのエージェンティック AI AWS Transform は、大規模な移行のために特別に構築された初のエージェント型 AI サービスです。これは、検出、依存関係マッピング、ウェーブプランニング、サーバー移行といった、以前は数か月の手作業を必要としたタスクを自動化します。これらのセッションでは、VMware と .NET モダナイゼーションの両方のシナリオで AWS Transform がどのように機能するかを示します。 AWS Transform for VMware によるエージェンティック AI を使用した VMware 移行 | MAM202 | Level: 200 Amazon EC2 への大規模な VMware 移行のための初のエージェンティック AI サービスである AWS Transform をご紹介します。アプリケーション検出、依存関係マッピング、ネットワーク変換、ウェーブプランニング、最適化された EC2 インスタンス選択によるサーバー移行を自動化する方法のライブデモをご覧ください。ライセンスの課題とベンダーロックインを克服しながら、VMware インフラストラクチャをクラウドネイティブアーキテクチャにモダナイズし、より迅速で確実な移行を可能にする方法を学びます。 AWS 移行ジャーニー: Microsoft ワークロードのための 2025 年の旅程 | MAM309 | Level: 300 Active Directory およびファイルサーバーの移行戦略、インフラストラクチャの変革、SQL Server データベースの移行手法、.NET アプリケーションモダナイゼーションアプローチを含む、Microsoft エコシステム専用に設計された画期的な移行ツールをご紹介します。これらのサービスとソリューションが複雑な移行を合理化し、手作業を削減し、移行ジャーニーを加速する方法を直接学びます。 AWS 上でネイティブに VMware ワークロードを実行 Amazon Elastic VMware Service (Amazon EVS) を使用すると、リプラットフォームやリファクタリングなしで VMware ワークロードを AWS に移行できます。既存の VMware ツール、スキル、投資を維持しながら、AWS インフラストラクチャ、スケール、サービスを利用できます。これらのセッションでは、開始方法から高度なアーキテクチャパターンまですべてをカバーします。 Amazon EVS の完全ガイド: VMware ワークロードのための AWS スケールを解放 | MAM201 | Level: 200 Amazon EVS は、リプラットフォームやリファクタリングの手間なく、VMware ワークロードを AWS に移行するシームレスな方法を提供します。このサービスを使用すると、既存の VMware への投資と専門知識を保護しながら、AWS の堅牢なインフラストラクチャを活用できます。自己管理を選択するか、AWS パートナーと協力するかにかかわらず、Amazon EVS は、統合されたストレージ、バックアップ、ディザスタリカバリ機能を備えた仮想環境をカスタマイズするための柔軟なオプションを提供します。プラットフォームの直感的なデプロイプロセスと継続的なイノベーションにより、クラウドジャーニーを最適化するために必要なツールと柔軟性が確保されます。 FSx for ONTAP による Amazon EVS のストレージコスト最適化 (NetApp 提供) | MAM101 | Level: 100 Amazon EVS は、リプラットフォームなしで VMware ワークロードを AWS にシームレスに移行できるようにします。 Amazon FSx for NetApp ONTAP と組み合わせると、高い TCO や複雑なデータ操作などの一般的な移行の課題に対処します。この統合により、オンプレミスソリューションで通常見られるエンタープライズ機能である、シームレスなデータ移行、自律的なランサムウェア保護、ストレージ利用率の最適化など、エンタープライズグレードのデータ管理機能が提供されます。AWS パートナーの NetApp によるプレゼンテーションです。 お客様の成功事例 これらのセッションでは、大規模な移行とモダナイゼーションを完了した顧客が、結果を推進した戦略、ツール、教訓を共有します。 VMware ワークロード – 移行とモダナイゼーションの実現 AWS への VMware マイグレーション: 成功方法、ロードマップと戦略 | MAM203 | Level: 200 VMware 環境を AWS へ成功裡に移行した IT リーダーが、クラウドジャーニーの経験を共有します。移行の計画と実行中に使用された実証済みのツール、戦略、学んだ教訓から学びます。これらのグローバル組織は、モダナイゼーションのロードマップとイノベーション戦略に関する洞察を共有し、開始したばかりでも課題をナビゲートしている場合でも、独自のクラウド変革のための貴重なガイダンスを提供します。 エージェンティック AI による改革の先駆け: CSL VMware および SAP モダナイゼーション | MAM346 | Level: 300 CSL Behring が、 AWS Transform for VMware のエージェンティック AI を使用して 4,000 台を超える VMware サーバーを移行し、SAP システムを統合することでインフラストラクチャを変革した方法を紹介します。彼らの戦略は、技術的負債とライセンスコストを削減しながら、検出とプランニングプロセスを 10 倍高速化しました。 RISE with SAP on AWS を通じて ERP ランドスケープを統合し、エンタープライズ全体のデータ標準を確立した方法を学びます。このケーススタディは、組織の変革ジャーニーに適用できる技術的ガイダンスと実践的な洞察を提供します。 Microsoft ワークロード – 移行とモダナイゼーションの実現 AWS Transform による DMV システムのモダナイズ: Idemia の .NET 成功事例 | MAM410 | Level: 400 米国全土の 48 の DMV (車両管理局) にサービスを提供している Idemia が、 AWS Transform を使用してレガシー .NET Framework アプリケーションをモダナイズし、25 年間の技術的負債に対処した方法を学びます。カスタマイズされたモダナイゼーションのためのコンポーザブル変換、パートナーツールのシームレスな統合、変革中のビジネス継続性を維持するための戦略を探ります Grupo Tress Internacional の AWS Transform による .NET モダナイゼーション | MAM320 | Level: 300 Grupo Tress Internacional が、 AWS Transform for .NET を使用して .NET Framework から .NET 8 に移行しながら、モダナイゼーションの労力を 70% 削減した方法をご紹介します。 Amazon Elastic Container Service (Amazon ECS) および AWS Fargate を使用したコンテナ化、 AWS Lambda を使用したサーバーレス実装、.NET アプリケーションのための DevOps 方法論、生成 AI ツールによる開発者のエンパワーメントに関する実践的な戦略について学びます。 EC2 から EKS へ: Tipalti の AWS 上の Windows コンテナへの変革 | MAM339 | Level: 300 Tipalti が従来の Windows アプリケーションをモダンなコンテナ化されたソリューションに変革し、50% のパフォーマンス向上を達成したジャーニーをたどります。プロセス管理の課題の克服、Windows ワークロードのオートスケーリングの実装、Windows コンテナのベストプラクティス、Windows アプリケーションのモダナイズのための実践的な知識について学びます。 Thomson Reuters のエージェンティック AI によるスケールモダナイゼーション | MAM334 | Level: 300 Thomson Reuters が AWS Transform for .NET を活用して月間 500 万行のコードをモダナイズし、開発速度を 4 倍加速した方法を学びます。このセッションでは、アプリケーション変革を数か月から単一のスプリントに短縮し、運用コストを 30% 削減し、大規模な並列モダナイゼーションを実装した方法を紹介します。また、AI を活用したエージェントが、セキュリティとパフォーマンスを維持しながら技術的負債を削減した方法も紹介します。 ライセンスとコスト最適化 ソフトウェアライセンスの管理は、Microsoft および VMware ワークロードを AWS に移行する際の最も複雑な側面の 1 つです。このセッションでは、適切なサイジング、ライセンスコストの削減、AWS ツールを使用したコンプライアンスの維持とクラウド投資の最大化のための戦略を取り上げます。 AWS におけるエンタープライズソフトウェアライセンスと最適化 | MAM315 | Level: 300 このセッションでは、Microsoft ワークロードとコスト最適化戦略に焦点を当てて、AWS における商用ソフトウェアライセンスについて詳しく説明します。 Microsoft Optimization and Licensing Assessment (OLA) スペシャリストが、クラウドライセンスの複雑さの管理に関する専門的な洞察を共有します。このセッションでは、新しいセルフサービス AWS Transform Assessments を含む、さまざまなデプロイシナリオのための完全に無償の OLA オファリングを取り上げます。これらのツールが、クラウド投資効果を最大化するために AWS サービス全体で重要となる最適なサイジングの推奨事項をどのように提供するかをご覧ください。 チョークトーク re:Invent 2025 の以下のチョークトークは、移行計画、.NET モダナイゼーション、SQL Server、ライセンス、Amazon EVS アーキテクチャに関するインタラクティブで詳細なコンテンツを提供します。 スライドはこちらでご覧いただけます。 エージェンティック AI による AWS 上の SQL Server モダナイゼーションの加速 | MAM304 | Level: 300 AWS におけるライセンス管理と最適化 | MAM321 | Level: 300 .NET クラウドジャーニー: 移行とモダイゼーション戦略 | MAM317 | Level: 300 突然 SQL Server データ管理者になった人のための AWS 基礎 | MAM308 | Level: 300 VMware から AWS への準備: 移行前の基本的な決定事項 | MAM357 | Level: 300 Amazon EVS ディーブダイブ: 高度なネットワークとストレージアーキテクチャ | MAM401 | Level: 400 Amazon EVS ディープダイブ: 戦略的な移行計画 | MAM305 | Level: 300 まとめ AWS re:Invent 2025 は 1 つのことを明確にしました。Microsoft および VMware ワークロードをクラウドに移行することは、これまで以上に現実的になっています。エージェンティック AI により、.NET モダナイゼーションと VMware 移行の手作業が数か月から数週間に短縮されます。専用に設計構築されたインフラストラクチャオプションにより、リプラットフォームの障壁が取り除かれ、適切なライセンス戦略を導入することで、コストを管理しながらより迅速に移行できます。 Thomson Reuters から CSL まで、多くのお客様が、適切なツールと明確な移行戦略を組み合わせ、結果を達成しています。セッションをご覧になり、チョークトークのスライドを確認し、AWS での移行の計画を開始してください。 全ての移行とモダナイゼーションのプレイリストは、 YouTube の全プレイリスト をご覧ください。 <!-- '"` --> Suhail Fouzan Suhail Fouzan は、IT 業界で 15 年以上の経験を持つ Amazon Web Services (AWS) のスペシャリストソリューションアーキテクトです。Microsoft ワークロード、移行サービス、AWS Systems Manager による運用管理を専門とし、Suhail はお客様がインフラストラクチャを AWS に正常に移行できるよう支援しています。仕事以外では、Suhail はクリケットをプレーしたり、家族と過ごしたりすることを楽しんでいます。 Bianca Velasco Bianca Velasco は、AWS 上の VMware ベースのワークロードの移行と変革に焦点を当てた AWS のプロダクトマーケティングマネージャーです。マーケティングとテクノロジーで 7 年以上の経験があり、複雑なテクノロジーを意味があり親しみやすいものにするナラティブを作成することに情熱を注いでいます。AWS 以外では、Bianca はボランティア活動、ダンス、ボルダリングを楽しんでいます。 この投稿の翻訳は Solutions Architect の田澤が担当させていただきました。原文記事は こちら です。