テレコム 5G および IMS コンテナベースのワークロードは、 Multus CNI を利用してトラフィックとルーティングの分離とパケットアクセラレーションを実現します。Multus コンテナネットワークインターフェイスプラグインを使用すると、Kubernetes ポッドを複数のインターフェイスとネットワークに接続できるようになります。Multus CNIは「メタプラグイン」であり、 VPC CNI ( Amazon Elastic Kubernetes Service (Amazon EKS) のデフォルト CNI)、 IPVLAN CNI などの他のCNIを呼び出すことでこれを実現します。VPC CNI は Kubernetes ポッドのプライマリインターフェイスを管理しますが、IPVLAN CNI では、ワーカーノードの Elastic Network Interface (ENI) 上の同じ MAC アドレスを使用することで、ポッドがワーカーノードのセカンダリインターフェイスを使用できるようになります。Multus CNI は、 host-local 、 static 、および whereabouts などの IPAM CNI も呼び出します。 「 Amazon EKS now supports Multus CNI 」の記事は、Amazon EKS で Multus ワークロードをデプロイし始めるのに役立ちます。Amazon EKS に Multus ベースのワークロードをプロダクション向けにデプロイするには、次の 2 つのトピックの管理を計画する必要があります。 Multus ワーカーノードグループ: ワーカーノードサブネット、およびワーカーノードの IP アドレス管理。各ワーカーノード ENI にはサブネットの IP アドレスが必要 Multus ポッドネットワーク: ワーカーノードサブネットからの Multus ポッドの IP 管理、および Amazon Virtual Private Cloud (Amazon VPC) でのポッド通信。 この記事では、標準の Multus ノードグループのデプロイ方法と、Amazon VPC 内の Multus ワークロードで ipvlan CNI を使用する際の上記のトピックを管理するための課題とアプローチについて説明します。 標準的な Multus ノードグループ導入アプローチ 上の図は、IPVLAN CNIを使用した Multus ワークロードのデプロイ例を示しており、この記事で説明していきます。この例では、Amazon EKS クラスターと 2 つのワーカーノードを持つノードグループがあります。両方のワーカーノードは、次のように 2 つのサブネットに接続されます。 eth0 ネットワーク:10.10.12.0/24 (VPC CNI、即ちポッドのプライマリインターフェイスに使用) eth1 ネットワーク:10.10.1.0/24 (Multus ipvlan cni、即ちポッドのセカンダリインターフェイスに使用) 上のサンプルデプロイ方法では、デプロイは Amazon EKS クラスターデプロイから始まり、その後に Amazon EKS ノードグループのデプロイが続きます。ノードグループがデプロイされたら、Multus CNI と関連するプラグインをデプロイしてワークロードをサポートできます。プラグインがデプロイされたら、ワークロードをデプロイできます。 次のセクションでは、Multus ワーカーノードグループと IP 管理のデプロイ戦略について説明します。 Multus ワーカーノードグループのデプロイと IP 管理 Multus ワーカーノードデプロイ 自己管理型の Multus ノードグループは、オートスケーリンググループを使用して復元力（最小限のワーカー数を維持）とスケーラビリティを提供します。オートスケーリンググループは、 起動テンプレート を使用して Amazon Elastic Compute Cloud (Amazon EC2) ワーカーノードを構成します。オートスケーリンググループは、起動テンプレートと組み合わせて、同じサブネットに属する単一または複数のインターフェースを持つワーカーノードを作成できます。カスタムデプロイメント戦略では、カスタム AWS Lambda を使用して、異なるサブネットからの複数のネットワークインターフェイスアタッチを実現します。これにより、Amazon EC2 オートスケーリングライフサイクルフックに Multus インターフェイスが追加されます。 次の図に示すように、デプロイメントはオートスケーリンググループが起動テンプレートを使用して単一インターフェイス (eth0) のワーカーノードを作成するところから始まります。ワーカーが起動すると、カスタム Lambda が単一のインターフェイスノードを終了します。このスケールインにより、「autoscaling: EC2_INSTANCE_TERMINATING」イベントが発生し、カスタム Lambda がトリガーされてからノードをドレインします、もしくは何も行われません。 このイベントが完了すると、オートスケーリンググループは必要な容量を満たすためにスケールアウトし、「autoscaling: EC2_INSTANCE_LAUNCHING」イベントが発生します。このイベントはカスタム Lambda 関数をトリガーし、タグ (key: node.k8s.amazonaws.com/no_manage 値: true) を使用して Multus サブネットからセカンダリインターフェイスを追加します。 EKS Multus ノードグループの作成フロー ワーカーノードの IP 管理に関する課題 オートスケーリンググループは、Amazon EKS ワーカーノードグループに弾力性と復元力を提供し、すべてのインターフェイスに DHCP IP 割り当てを使用して同じようにサポートします。一方、Multus ポッドの場合、非 VPC IPAM CNI（ host-local 、 whereabouts 等）は、静的アドレス範囲/プールを使用してセカンダリインターフェイスでの IP 割り当てを管理します。ポッドの出力/入力は対応するワーカー ENI を介して行われるため、ポッド IP とワーカー ENI IP アドレスはサブネットから取得する必要があります。アプリケーション計画者は、Multus network-attachment-definition の構成とアノテーションによって、Multus ポッドの静的 IP 範囲を割り当てます。 同じサブネット上の 2 つの異なる別々の IP 割り当て方法 (DHCP と静的) は、ワークロードのデプロイにおいて興味深い課題となります。DHCP によるワーカーノードの IP 割り当てはランダムであり、他の静的割り当てを認識しないため、ポッドに対して計画された静的 IP 範囲から任意の IP アドレスを取得できます。Multus IPAM CNI ( host-local 、 whereabouts 等) は、この割り当てを認識しません。この IP アドレスがワーカーインターフェイスによって取得されると、アプリケーションポッドで IP 競合が発生し、IP 割り当てが失敗し、予期しないアプリケーションのデプロイが発生してしまいます。 ソリューション 以下のセクションでは、ワーカーノードと Multus ワークロードの IP アドレスを競合しない方法でより適切に管理するための 2 つの方法を紹介します。 アプローチ 1: カスタム Lambda を使用してワーカー IP を静的に割り当てる このソリューションアプローチは、ワーカーとポッド間の論理サブネット共有モデルで機能します。このアプローチでは、ワーカーノードはサブネットの最初から未割り当ての IP を取得し、Multusポッドはサブネットの終わりから未割り当ての IP を取得します。この割り当て戦略では、IP アドレスはワーカーノードインターフェイスにランダムに割り当てられるのではなく、IP 割り当てはサブネットで最初に空いている空き IP から静的に行われます。 詳細な説明、サンプル AWS CloudFormation テンプレート、サポートされている Lambda 関数については、GitHub リポジトリ「 Allocate Worker IPs statically via a custom lambda-based solution 」を参照してください。 アプローチ 2: ポッドの IP アドレスに VPC サブネット CIDR 予約 (静的) を使用する このアプローチでは、 VPC サブネット CIDR 予約 戦略を使用して、ワーカーノードと Multus ポッドの IP アドレス割り当てを分離します。このアプローチでは、Multus ポッドの IP CIDR 範囲を静的として明示的に予約でき、Amazon EC2 ワーカーノードの DHCP がこのブロックからワーカーノードに IP アドレスを割り当てないようにすることができます。 これを実現する為に、明示的 (静的) 割り当てのみを目的として、ポッド IP アドレスの塊に対して 1 つ以上のサブネット CIDR 予約を作成できます。サブネット CIDR の予約されていない塊は、オートスケーリンググループの背後にあるワーカーノードへの DHCP（デフォルト）割り当てに使用できます。 詳細な説明、サンプルの CloudFormation テンプレート、およびサポートされている Lambda 関数については、GitHub リポジトリ「 Use VPC subnet cidr reservation (static) for pods IP addresses 」を参照してください。 自動 Multus ポッドネットワーキング Amazon EKS クラスターと Multus ノードグループが前述のアプローチのいずれかでデプロイされたので、Multus を使用して Amazon EKS にワークロードをデプロイできます。次のステップとして、 git リポジトリ に記載されているように Multus CNI をデプロイし、 whereabouts IPAM CNI をインストールします。この記事では、 whereabouts IPAM CNI を使用してクラスターの一意の Multus IP アドレスを管理しています。 ここで、VPC での IP 通信の仕組み、ルーティングを有効にする方法、および自動化された方法で Multus ポッドに IP を割り当てる方法を理解しましょう。 Multus ポッドのIP 管理とルーティングの課題 次の例では、Multus ポッドをデプロイすると、セキュリティグループルール/NACL がトラフィックをブロックしていない場合でも、異なるワーカー上のポッド間通信が機能しないことに留意してください。ただし、同じワーカーノード上のポッド間の相互通信は正常に機能します。 ここでは、この動作について詳しく説明します。Amazon VPC クラウドは、ワークロードにレイヤー 3 ネットワーキングを提供します。ENI は、1 つ以上の IP アドレスと対応する MAC アドレスを含む論理ネットワークエンティティです。Amazon VPC は、ENI に割り当てられた IP アドレスに基づいて、トラフィックを正しい宛先にルーティングします。Amazon EC2 ワーカーノードに接続されている各 ENI には、適格な IP アドレスが割り当てられている必要があります。 ポッドのプライマリインターフェイスでは、Amazon VPC CNI は DHCP を使用してプライマリポッド IP アドレス (上の図では 10.10.12.x) をポッド eth0 (VPC CNI マネージドインターフェイス) に割り当て、これらの IP をワーカーノード ENI のセカンダリ IP として割り当てます。非 VPC IPAM CNI (whereabouts、host-local、static 等) は、IP アドレスを Multus ポッドに割り当てます。したがって、Amazon VPC はこの IP アドレスの割り当てを認識しません。さらに、これらの IP アドレスは、それぞれのワーカーノード ENI (上の図では eth1) のセカンダリ IP として割り当てられません。 Amazon EC2 コンソールでワーカーノードの ENI を調べることで同じことを確認できます: Amazon EC2 コンソール → インスタンス → インスタンスの選択 (ワーカー) → アクション → ネットワーキング → IP アドレスの管理。 この問題は、ポッドが想定する IP アドレスがそれぞれのワーカー ENI に割り当てられると解決されます。これらの IP がそれぞれの ENI (例: eth1) に割り当てられると、Amazon VPC は割り当てられた IP の マッピングを ENI へ更新し、指定された Multus IP アドレスにトラフィックをルーティングします。 次の例では、Multus ポッド IP アドレス 10.10.1.80 および 10.10.1.82 が、最初のワーカーノードの eth1 ENI 上のセカンダリ IP アドレスとして割り当てられます。同様に、10.10.1.81 セカンダリ IP が 2 番目のワーカーノード eth1 ENI に割り当てられます。 自動化ソリューション Amazon EC2 の IP アドレスの割り当て/IP アドレスの割り当て解除 API 呼び出しにより、ワーカーノード ENI での IP 割り当てを自動化できます。 git リポジトリ にあるサンプル Python コードとスクリプトでも同じ結果が得られます。 以下で説明する自動化アプローチでは、アプリケーションイメージやソースコードを変更する必要はありません。これらのポッドでカスタムの「IP 管理」コンテナを利用して、アプリケーションコンテナやそのアーキテクチャに影響を与えることなく、それぞれのワーカーノード ENI で IP 割り当ての自動化を実行できます。この追加のコンテナを使用して、ワークロードの pod/deployment/statefulset の仕様を強化できます。 この機能を提供し、次のいずれかのソリューションオプションで使用できる Docker コンテナイメージをビルドするには、「 How to build 」を参照してください。 アプローチ1: InitContainer ベースのIP 管理ソリューション このソリューションは、フローティング IP (次のアプローチで説明) などの特別な処理やカスタム処理を行わなくても、ほとんどの ipvlan CNI ポッドで機能します 。このアプローチでは、ワーカーに追加の CPU/メモリ要件の制約が追加されません。 この「IP 管理」コンテナは、ポッドが init 状態のときに最初のコンテナとして実行されます。このコンテナは、ポッドが初期 (init) 状態にあるときに、ポッドの IP アドレスを確認し、その IP アドレスを ENI に割り当てます。Multus IP アドレスがワーカーノード ENI に正常に割り当てられると、この initContainer は終了し、ポッドは初期状態から抜け出します。 このソリューションを使用するには、 InitContainer IP management ドキュメントとデプロイ手順を参照してください。 Amazon EC2 コンソールでワーカーノードの ENI を調べることで、同じことを確認できます。Amazon EC2 コンソール → インスタンス → インスタンスの選択 (ワーカー) → アクション → ネットワーキング → IP アドレスの管理。 アプローチ 2: サイドカー IP 管理ソリューション このアプローチでは、「IP管理」コンテナはサイドカーコンテナとして動作します。さらに、initContainer とは異なり、Multus インターフェイス上のポッド IP アドレスを常に監視して、新規または変更された IP アドレスがないかどうかを確認します。これは、アクティブ/スタンバイポッドに対するカスタムの「フローティング IP」処理を持つポッドにとって役立ち、内部ロジックに基づいて、トラフィックを中断することなく「フローティング IP」がスタンバイポッドにフェイルオーバーします。この場合、サイドカーは IP アドレスの変更についてポッドを常に監視するため、Multus ベースのポッドごとにこのコンテナ用の CPU/メモリ (最小限) が追加で使用されます。 このソリューションを使用するには、 Sidecar IP management Solution のドキュメントと手順を参照してください。 Amazon EC2 コンソールで確認できます: Amazon EC2 コンソール → インスタンス → インスタンスの選択 (ワーカー) → アクション → ネットワーキング → IP アドレスの管理。 クリーンアップ この記事でデプロイされたサンプル Multus ワークロードをクリーンアップするには、GitHub リポジトリの「 Cleanup 」を参照してください。さらに、今後の料金の発生を避けるために、CloudFormation コンソールから Multus Worker ノードグループを削除してください。Amazon EKS クラスターは Amazon EKS コンソールから削除できます。 まとめ この記事では、Amazon VPC クラウド内のワーカーノードと Multus ポッドの IP アドレスの IP 割り当て、管理、分離の際にお客様が直面する課題について説明しました。さらに、Multus ポッドがどのように Amazon EKS および Amazon VPC スコープで動作し、VPC内 でトラフィックをルーティングするかについても説明しました。 加えてこの記事では、ソフトウェア/イメージを変更することなく、Amazon EKS ノードグループと Multus ポッドの IP 管理自動化の、自動化サンプルメソッドも提供しております。 分かり易くするために、この記事の上の例では IPv4 の処理のみを説明しました。但し、 git リポジトリ のサンプル コードは IPv6 もサポートしています。様々なアプリケーションアーキテクチャやユースケースに応じて、git リポジトリ内のサンプル ソースコードをさらに調整して頂けます。 この記事はアマゾン ウェブ サービス ジャパンの黒田由民が翻訳を担当しました。 (原文は こちら ) Raghvendra Singh Raghvendra Singh は AWS 5G および AWS のネットワークトランスフォーメーションプラクティスのスペシャリストです。彼は AWS の 5G ソリューション設計全体、E2E 統合、ネットワークアーキテクチャ、自動化、セキュリティ全般を担当しています。彼は 4G/5G NFV 分野を専門とし、お客様が AWS 上でクラウドネイティブのコンテナネットワーク機能を導入および統合できるよう支援しています。

従来から、通信サービスプロバイダ (CSP) は Virtual Routing and Forwarding (VRF) 技術を使用して、データセンター (DC) ネットワークをネットワークドメインごとに分離しています。例えば、運用管理 (OAM)、シグナリング、ローミング、ユーザートラフィックネットワークなどのドメインなどです。また、データセンターの各 VRF ドメインを他のデータセンターと同等の VRF に接続して、ネットワークを地域的および全国的にカバーする必要があります。さらに、CSP がエンドカスタマーに提供するサービスでは、CSP がマルチ VRF ベースのネットワークをネットワーク分離したまま、外部のプライベートネットワークに拡張する必要があることもよくあります。従って、DC 間接続と通信ネットワーク拡張の両方で、ネットワーク分離（VRF）を維持し、複数の自律システム（AS）サポートを相互接続するための特定の要件が生じます。一般的な解決策として、 RFC4364 ではこの要件に対応する 2 つのオプションが導入されています。オプションA は、RFC 4364 の VRF to VRF 接続により、ネットワーク間相互接続（NNI）の両側のルーティングコンテキストが 1:1 で調整されることを意味します。また、オプションB は、NNI のラベルスイッチングパラダイムに基づくマルチプロトコルラベルスイッチング（MPLS）AS 間接続を、グローバル QoS ポリシー、強化スキーム、および単一のMP-eBGPセッションを備えた単一の MPLS 対応論理インターフェイスで使用します。AWS で実行されているアプリケーションを、既存のマルチ VRF で分離されたネットワーク上のワークロードに相互接続する場合、この要件とソリューションを実装する必要があります。最初で最も簡単な方法として、RFC4364 オプションAの方法で、アプリケーションを個別の Amazon Virtual Private Cloud（Amazon VPC）に分離し、各 VRF にマッピングすることを考えることができます。これは次の図1に示すように、オンプレミスの VRF と AWS 上にマップされた VPC の間に個別の AWS Site to Site (S2S) VPN または AWS Direct Connect (DX) で接続することにより実現します。 図1 VRF から VPC への相互接続 (RFC4364 オプション A) これはうまく機能し分かり易いですが、ネットワークアプリケーションをそれぞれの VPC に分離できる場合にのみ機能します。ただし、仮想ネットワーク機能（VNF）やコンテナネットワーク機能（CNF）などの通信ネットワークアプリケーション/アプライアンスのほとんどの場合、特定のアプライアンス（EPC（evolved packet core）や 5GC（5G Core）等）では、複数のネットワークドメインを1つの VPC 内に限定する必要があります（OAM VRF、シグナリングネットワーク VRF、ユーザープレーン VRF、ローミングインターフェイス VRF 等）。これにより通常、ネットワーク分離の要件を維持したまま通信サービスプロバイダのネットワークと AWS 間のネットワーク拡張を実装しようとすると、複雑さとコストが増えます。そのため、特に AWS 上の通信アプリケーションに 1 つの VPC アーキテクチャを使用する場合は、ベストプラクティスを検討することが合理的です。 図 2 VRF から単一 VPC への相互接続 この記事では、AWS と複数の VRF で分離された CSP ネットワーク間にハイブリッドネットワークを構築するための 5 つの実行可能なデザインパターンを紹介します。1) Customer Gateweay (CGW) のルートフィルター オプション設定によるパターン、2) AWS Transit Gateway (Transit Gateway) ルートテーブルの分離によるパターン、3) Transit Gateway ルートテーブルの分離と Transit Gateway Connect によるパターン、4) VPC 内の仮想ルータアプライアンスによるパターン、及び 5) Multi-VPC ENI Attachments 機能を使用したパターン、の5つです。パターン 1 ～ 3 及び 5 では、オンプレミス側プロバイダエッジ (PE) ルーターまたは Transit Gateway の各側で微調整された構成を持つネイティブ AWS ネットワーキング構造を使用します。一方パターン 4 では、RFC4363 オプション B 構成を実装するために、VPC 内に仮想ルータアプライアンスが必要になります。これら 5 つのパターン以外にも他のオプションが存在する可能性がありますが、これらを一般的なアプローチとして、また AWS の VPC アーキテクチャと既存の VRF 分離ネットワークの両方への影響を最小限に抑えるベストプラクティスとして紹介します。 パターン 1 – CGW（プロバイダエッジ（PE）ルータ）でルートマップ IN フィルタを使用して VRF を単一の VPC に接続する 最初のデザインパターンは、最もシンプルな AWS ネットワーク構成方法で、VRF ごとに個別 Site to Site (S2S) 仮想プライベートネットワーク (VPN) または Direct Connect (DX) 仮想インターフェイス (VIF) を利用し、PE ルータ側に特定の構成を行います。前の章で説明したように、1つの VPC が AWS ネットワークの 1つのルーティングドメインになります。したがって、S2S VPN または DX を介して VRF 分離が存在するオンプレミスネットワークに Amazon VPC を接続すると、すべての VPC CIDR 範囲が接続されているすべてのピア VRF に広報されます。この際、各 VRF ルータ（VPC への各 S2S 接続の CGW としても見られます）のルートポリシーマップは、各 VRF 向け他 Amazon VPC サブネットからの干渉を受けないように実装されることができます。このインバウンドルートポリシーは、Amazon VPC 内の Amazon Virtual Private Gateway (VGW) との BGP 関連付けを介した現在の VRF とは関係のない、広報されたサブネットをフィルタで除外するために、適用される必要があります。つまり、このパターンでは、オンプレミス VRF ルータ側での事前設定が必要ですが、各 VRF 対応にマッピングする事前定義された Amazon VPC サブネットに関する情報も必要になります。このプライベートネットワーク側の構成に加えて、インスタンスとサブネットインターフェイスでセキュリティグループとアクセス コントロールリスト (ACL) を使用して、セキュリティ及び分離の適切な境界を設定する必要もあります。これにより、VPC 内でのネットワーク分離を実装可能とします。 図3 デザインパターン1; PE ルータでルートフィルタを使用する 図 3 の VRF1 ルータの場合、VPC が VPC CIDR 10.0.0.0/16 範囲全体を広報している一方で、VRF-1 サブネットが VPC で 10.0.10.0/24 として事前に設定されている場合に、ルートマップフィルタ設定例を次のように記載できます。S2S VPN または DX 接続を介して広報された複数の VPC CIDR 範囲を受信してフィルタリングするには、広報するプレフィックスごとに新しいセカンダリ VPC CIDR を設定し、その CIDR から VPC サブネットを作成する必要があることに留意ください。DXと S2S VPN は、プライマリ VPC CIDR だけでなく、セカンダリ VPC CIDR ごとに1つの VPC CIDR プレフィックスを広報します。これにより、オンプレミスの CIDR に基づいてフィルタリングできます。 router bgp 65001 network 169.254.205.58 neighbor 169.254.205.57 remote-as 64512 neighbor 169.254.205.57 route-map SET-LOCAL-PREF in ! route-map SET-LOCAL-PREF permit 10 match ip address 2 set local-preference 120 ! route-map SET-LOCAL-PREF permit 20 ! access-list 2 permit 10.0.10.0 0.0.0.255 access-list 2 deny any パターン2 – Transit Gateway ルートテーブル分離を使用する マルチ VRF 用の個別の S2S VPN または DX VIF がある（つまり、各 S2S VPN または VIF が各 VRF に個別にある）場合は、それらを使用して各 VRF を単一の VPC に接続できます。この環境では、AWS Transit Gateway (TGW)と Transit Gateway ルートテーブル を使用して、VPC CIDR のルート伝播を各 VRF に分けることができます。このアプローチ（および次のパターン3）で覚えておくべく留意点の1つは、Transit Gateway はデータトラフィックの料金がかかるため、大量のトラフィックを処理する必要がある通信サービスプロバイダの 4G/5G コアネットワークのユースケースにてユーザートラフィックの伝送には、最適なオプションとはならない可能性がある点です。次の図4に示すように、このデザインパターンの重要な考え方は、VRF 側への Amazon VPC の伝播を無効にし、代わりに各 VRF 専用ルートテーブルで静的ルートを定義して、VPC CIDR 範囲内の対応するサブネットのみを含むようにすることです。次の図例では、結果として、PE ルータの VRF1 側は Transit Gateway 側の BGP 広報から Private-VRF1 サブネット範囲のみを受信し、VRF2 側では Private-VRF2 サブネット範囲のみを参照します。前のデザインパターンと同様に、VPC 内のネットワーク分離は、各サブネットレベルとインスタンスレベルで NACL とセキュリティグループを介して実装する必要があります。 図4 デザインパターン2; TGW ルートテーブル分離を使用する パターン3 – 単一の DX Transit VIF を介して Transit Gateway Connect を使用する 前のパターンと似ていますが、DX 接続が1つだけ存在する場合は、 Transit Gateway Connect 機能がより効果的です。Transit Gateway Connect は、単一の DX Transit VIF を介して複数の AS 及び複数の VRF ネットワークを AWS に相互接続する方法を提供します。これにより、Generic Routing Encapsulation (GRE) と Border Gateway Protocol (BGP) を使用したオンプレミスデータセンタと AWS ドメイン間の物理ネットワーク接続を簡素化できます。 図5 デザインパターン3; TGW Connect と TGW ルート テーブルの分離を使用する 上の図は、複数の VRF を使用した複数の Transit Gateway attachment タイプ Connect の実装を示しています。Direct Connect Gateway（DX-GW）はTransit VIF で構成され、Transit Gateway の CIDR 範囲を広報します。DX-GW は Transit Gateway に接続されるため、DX-GW アタッチメントが作成されます。DX-GW アタッチメントは、Transit Gateway attachment タイプ Connect のトランスポートになります。Transit Gateway attachment タイプ Connect を作成したら、Connect ピア (GREトンネル) を作成してオンプレミス VRF で GRE + BGP を設定します。Transit Gateway の GRE 外部 IP アドレス (ピア IP アドレス) は、Transit Gateway CIDR からの任意の IP になり、VRFアプライアンス側の GRE 外部 IP アドレスは、オンプレミスの PE ルータから広報されたアドレスのいずれかになります。CIDR ブロック内の BGP は、169.254.0.0/16 範囲の /29 CIDR である必要があります。/29 IPv4 範囲の最初のアドレスは、 VRF アプライアンスの BGP ピア IP アドレスになり、他の 2 つのアドレスが Transit Gateway BGP ピア用に選択されます。すべての GRE 接続に対して 2 つの BGP ピアを設定でき、これにより各 GRE トンネル内に組み込みの冗長性が提供されます。各 Transit Gateway タイプ Connect には、トラフィックを分離するための独自の Transit Gateway ルーティングテーブルがあります。VPC アタッチメントがルーティングテーブルの伝播に追加されると、VPC CIDR は VRF に動的に伝播されます。オンプレミス VRF は、対応する Transit Gateway attachment タイプ Connect がルーティング テーブルの伝播に追加されると、それぞれのルーティングテーブル上でそのネットワークを広報します。前のパターンと同様に、この場合も NACL とセキュリティグループを使用して VPC 内のネットワーク分離を確認する必要があります。 パターン 4 – 仮想ルーターアプライアンスを使用した VRF 分離 (RFC4364-オプション B) VPC 内の仮想ルータアプライアンスによって構築されたオーバーレイネットワークの使用を考慮できます。次の図が示すように、オンプレミスネットワークの PE ルータとこの仮想ルータアプライアンスの間に、MPLS over GRE 接続を介して確立されたオプション B のネットワーク間インターフェイス (NNI) を作成できます。 図6 デザインパターン4; 仮想ルータアプライアンスによるオーバーレイネットワークの使用 簡単な検証のため、このアーキテクチャは、AWS Marketplace の Juniper Networks Virtual SRX (vSRX) を使用して、次の図の例示的な構成でテストできます。VPC1 のルータアプライアンスの左側はオンプレミスの PE ルータを模倣し、別の VPC2 のルータアプライアンスの右側は、オーバーレイネットワークを提供する VPC 内の仮想ルータアプライアンスを表します。これにより、両方の VPC がインターネット上の S2S VPN 経由で接続されるようになります。 図7 デザインパターン4の検証環境例 このデモ環境では、異なる MPLS L3 VPN から/へのトラフィックは、AWS Transit VPC の仮想ルーターアプライアンス上で終端される単一のオプション B オーバーレイ接続を介して多重化されます。この仮想ルータアプライアンスは、対応するルートターゲットをインポートおよびエクスポートすることで、ローカルに設定された複数の VRF にフローを明確化し、AWS Transit VPC 内の 1 つまたは複数のサブネットにバインドできます。以下は自律システム境界ルータ (ASBR) として機能する vSRX の構成例です。 [edit configuration] routing-instances { vSRXForWorkload-LAN1 { interface ge-0/0/1.0; instance-type vrf; route-distinguisher 65002:1; vrf-import import-vSRXOnPrem1; vrf-export export-vSRXForWorkload1; vrf-table-label; } vSRXForWorkload-LAN2 { interface ge-0/0/2.0; instance-type vrf; route-distinguisher 65002:2; vrf-import import-vSRXOnPrem1; vrf-export export-vSRXForWorkload2; vrf-table-label; } } 共通または異なるルートターゲットに基づくインポート及びエクスポートポリシーの適格な組み合わせも実装できます。AWS 側では、これらの各サブネットを同じ VPC に属する共通または専用のルートテーブルに関連付けることができます。サブネットルートテーブルごとに、VPC 内で異なるルーティングルックアップを実装できます。さらに、ルーティングコンテキスト間の分離を実現でき、前のパターンと同様に NACL とセキュリティグループを使用することもできます。 パターン 5 – Multi-VPC ENI Attachments を使用した VRF 分離 Multi-VPC ENI Attachments は、VPC レベルの分離を通じてアプライアンスが複数の個別のネットワークインターフェイスを持つことをサポートする機能です。この機能により、図 8 及び 図 9 に示すように、VPC の分離を維持しながら、アプライアンスなどのネットワーク機能が複数の ENI を持つことが可能になります。 図8 – デザインパターン5 の検証環境例 (TGW 使用) 図9 – デザインパターン5の検証環境例（VGW 使用） 図 1 で前述したように、このアーキテクチャは RFC4364 オプション A に準拠しており、各オンプレミス VRF を専用 VRF VPC に接続します。Multi-VPC ENI Attachments 機能により、ネットワーク機能アプライアンスを複数の VRF に接続できます。このアーキテクチャを使用する場合、パターン 2 と同様に、VRF-VPC ごとに個別の TGW ルートテーブルを使用する (図 8) か、ネットワーク要件に基づいて各 VPC で VGW を使用する (図 9) かを選択できます。 まとめ 一般的なクラウドの概念では、Amazon VPC は 1 つのルーティングドメインを提供する単一のフラットネットワークであるため、一致する VRF ごとに個別の VPC を持つことが最もシンプルな方法になります。ただし、4G/5G コア ネットワーク (UPF や PGW など) のようなアプリケーションでは、ルータをプライベートネットワークの複数の VRF に接続する必要がありますが、これらアプリケーションは通常、複数の VPC に分割することが出来ません。従って、VRF で分離されたプライベートネットワークへの単一 VPC の統合というこの課題は、AWS 上でのモバイルネットワーク実装のコンテキストで表面化することがよくあります。この記事では、Amazon VPC を VRF で分離されたオンプレミスのプライベートネットワークに接続するための 5 つの異なるアプローチについて説明しました。これは、AWS 上に 5G コアネットワークやプライベート 4G/5G ネットワークを構築するなど、通信業界のユースケースで必要になることがよくあります。各アプローチには、実装の複雑さ、運用コスト、スケーラビリティと性能要件の制約に関して長所と短所があります。よって、リストされたアプローチを使用した詳細な実装は、ユースケースの環境に応じて決定されることを推奨します。   長所 短所 パターン 1: PE ルータ（CGW）のルートマップフィルタ Amazon VPC 向けの最もシンプルな構成（S2S VPN, DX, VGW, Transit Gateway, サブネットルートテーブル） 複数の VIF および S2S VPN が必要（それぞれ VRF ごとに） PE ルータにはフィルタリング設定が必要 パターン2: 複数の S2S VPN または VIF を使用した Transit Gateway ルートテーブルの分離 各 VRF は、PE ルータを変更しなくても、対応するサブネットの広報を受信できる 複数の VIF および S2S VPN が必要（それぞれ VRF ごとに） 静的ルートの Transit Gateway ルートテーブルの設定が必要 Transit Gateway の使用が必要 パターン3: Transit Gateway ルートテーブルの分離、及び単一の Transit VIF を使用した Transit Gateway Connect 各 VRF は、PE ルータを変更しなくても、対応するサブネットの広報を受信できる 単一の VIF を活用 PE ルータには GRE のサポートが必要であり、GRE の制限（フローごとの制限等）に留意する必要がある 静的ルートの Transit Gateway ルートテーブルの設定が必要 Transit Gateway の使用が必要 パターン4: 仮想ルータベース ネットワークエンジニアにとって最も分かりやすい（従来の通信ネットワーク向け） オーバーレイおよびアンダーレイネットワークを構築するための追加コスト/複雑さ（高可用性、スケーラビリティ、性能に関する懸念を含む） パターン5: Multi-VPC ENI Attachments の使用 Amazon VPC 向けの最もシンプルな構成（S2S VPN, DX, VGW, Transit Gateway, サブネットルートテーブル） 各 VRF は、PE ルータを変更しなくても、対応するサブネットの広報を受信できる 複数の VIF および S2S VPN が必要（それぞれ VRF ごとに） この記事はアマゾン ウェブ サービス ジャパンの黒田由民が翻訳を担当しました。 (原文は こちら ) 著者 Rolando Jr Hilvano Rolando Jr Hilvano は、Amazon Web Services (AWS) のワールドワイドテレコムビジネスユニットのプリンシパルテレコムソリューションアーキテクトです。彼は 5G 分野を専門としており、通信領域のパートナーや顧客と協力しながら、AWS 上で通信ワークロードの構築やデプロイをしています。 Gonzalo Gomez Herrero Gonzalo Gomez Herrero は、AWS テレコムビジネスユニット EMEA チームのプリンシパルソリューションアーキテクトです。彼は20年以上にわたり、ネットワーク設計、エンジニアリング、計画、導入、および運用において世界中の通信サービスプロバイダをサポートしており、さまざまな役割にわたってコンサルティング、プロフェッショナルサービス、ソリューションアーキテクチャを提供してきました。Gonzalo は、サラゴサ大学で電気通信工学の修士号を取得し、ミュンヘン工科大学でコンピューターサイエンスの大学院研究を行いました。 Ammar Latif Ammar Latif は AWS のプリンシパルテレコムソリューションアーキテクトです。彼は、クラウドテクノロジーを使用してビジネス上の課題に取り組むお客様を支援しています。これまでのキャリアを通じて、Ammar は世界中の多くのテレコムおよびメディアのお客様と協力してきました。Ammar はニュージャージー工科大学で博士号を取得しています。 Matt Lehwess Matt Lewess は AWS のシニアプリンシパルソリューションアーキテクトです。マットは、ネットワークサービスプロバイダ分野でネットワークエンジニアとして長年働いており、アジア太平洋地域と北米で大規模なWANネットワークを構築し、データセンタテクノロジーとそれに関連するネットワークインフラストラクチャを展開してきました。その結果、彼は Amazon VPC、AWS Direct Connect、およびその他の Amazon のインフラストラクチャに焦点を当てた製品やサービスを最もよく使って作業しています。Matt は AWS のパブリックスピーカーでもあり、AWS クラウドプラットフォームを使用してお客様が大規模な問題を解決できるよう支援しています。仕事以外では、Matt は屋内と屋外の両方で熱心なロッククライマーであり、熱心なサーファーです。 Young Jung Young Jung 博士は、AWS ワールドワイドテレコムビジネスユニットのプリンシパルソリューションアーキテクトです。彼の主な焦点とミッションは、テレコムの Core /RAN パートナーとお客様が AWS 環境でクラウドネイティブ NFV ソリューションを設計及び構築出来るように支援することです。また、AWS のサービスとテクノロジーを活用したテレコムエッジサービス実装のため、通信業界向けの AWS Outposts のユースケースも専門としています。

通信サービスプロバイダ (CSP) が AWS 上に Long Term Evolution (LTE) または 5G ネットワーク機能をデプロイする場合、SGi (LTE の場合) または N6 (5G の場合) インターフェイスを介したユーザープレーンデータネットワークのブレークアウトに関するさまざまなオプションが存在します。3GPP は、SGi インターフェイスをパケットデータネットワーク（PDN）ゲートウェイ（S-GW およびP -GW）とデータネットワーク間の基準点として定義しています。さらに、N6 はユーザープレーン機能（UPF）とデータネットワークの間の基準点として定義されています。PDN は、公共の外部（インターネットなど）データネットワーク、プライベートパケットデータネットワーク（VPNなど）、またはオペレータ内パケットデータネットワークとすることができます。 この記事では、非ローミングシナリオでの AWS 上での LTE または 5G UPF のデータネットワークブレークアウトオプションについて説明します。UPF という用語は、3GPP TS 29.244 に記載されているように、SGW-U、PGW-U、TDF-U、UPF などのノードを指します。この記事では、PGW-U を P-GW と呼びます。 図 1: LTE の P-GW およびデータネットワーク (インターネット) 間の SGi インターフェイス 図2: 5G の UPF とデータネットワーク (インターネット) 間の N6 インターフェイス ソリューション設計 AWS 上の LTE または 5G ネットワークは、CSP によってパブリックネットワークまたはプライベートネットワークとして運営されています。各ネットワークタイプは、通常パブリックネットワークの消費者市場に関連する Enhanced Mobile Broad Band（eMBB: 高速大容量通信）、自動運転車に関連するユースケースのような遅延に厳しい要件がある Ultra Reliable Low Latency Communications（URLLC: 超信頼・低遅延通信）、データを送信する多数のデバイスをサポートするMassive Machine Type Communications（mMTC: 多数同時接続）など、様々なタイプのユースケースに対応します。ユースケースが何であれ、ユーザープレーンのトラフィックは P-GW または UPF を出てアプリケーションへ到達します。AWS 上でネットワーク機能を実行する場合、データネットワークにアクセスするにはさまざまな方法があります。5G UPF 機能をリファレンスとして使用する様々なブレークアウトアーキテクチャについて説明します。 設計1: AWS Internet Gateway 経由のパブリックデータネットワーク (インターネットなど) へのユーザープレーンのブレークアウト このアーキテクチャでは、N3 トラフィックはオンプレミスから AWS 上の UPF に到達します。UPF は、N6 インターフェイスに送信する前に、NAT を実行してユーザー機器 IP（UEIP）を UPF ENI IPに変換します。N6 ユーザープレーンのトラフィックブレイクアウトは、AWS Internet Gateway (IGW) 経由でパブリックデータネットワークであるインターネットに送られます。IGW は、VPC とインターネット間の通信を可能にする、水平方向に拡張された冗長で可用性の高い仮想プライベートクラウド (VPC) コンポーネントで、IPv4 とIPv6 のトラフィックをサポートしています。このアーキテクチャの UPF には、N6 トラフィックがインターネット宛先に到達するための1つ以上のパブリック IP アドレス（Elastic IP アドレスなど）が割り当てられています。N6 Elastic Network Interface (ENI) サブネットの VPC ルーティングテーブルには、インターネットトラフィック宛先のネクストホップとして IGW があります。 設計2: CSP のオンプレミスネットワークを介したパブリックデータネットワーク（インターネットなど）へのユーザープレーンのブレークアウト このアーキテクチャは、N6 トラフィックがルーティングでオンプレミスネットワークに戻ることをを示しています。このアプローチでは、AWS 上に配置されている UPF との間のユーザープレーントラフィックがヘアピンされます。このタイプのアーキテクチャを使用する CSP は、インターネットへの既存の ISP 接続またはエンタープライズ顧客へのプライベート接続を引き続き活用できます。N6 ENI サブネット向けの VPC ルーティングテーブルには、インターネットトラフィック宛先向けのネクストホップとして   AWS Transit Gateway   があります。Transit Gateway では、N6 データネットワークトラフィックは N6 Virtual Routing and Forwarding（VRF）セグメントに戻され、オンプレミスに到達します。 設計3: AWS Site-to-Site VPN によるプライベートデータネットワークへのユーザープレーンのブレークアウト このアーキテクチャは、UPF からの N6 トラフィックが、  AWS Site-to-Site VPN または VPN アプライアンスを使用する安全な VPN 接続を介してサードパーティのロケーションに向けて終端するプライベートネットワークの一般的なユースケースとなります。AWS Site to Site VPN サービスは、仮想プライベートゲートウェイまたは AWS 側の Transit Gateway を使用して確立できます。Site to Site VPN の設定の詳細については、 こちら をご覧ください。AWS Site to Site VPN の単一の VPN 接続の帯域幅容量 (1.25Gbps) を考慮に入れる必要があります。ただし、複数 VPN トンネルの等価コストマルチパス（ECMP）では、トラフィックが必要とする全体帯域幅を増加させることも可能です。 設計4: VPC ピアリングによる AWS 上のプライベートデータネットワークへのユーザープレーンのブレークアウト このアーキテクチャは、5G ネットワーク機能とユースケースアプリケーションの両方が AWS 上のそれぞれの VPC 上で動作するプライベートネットワークの一般的なユースケースとなります。2 つの VPC は VPC ピアリングを使用して相互接続されます。VPC ピアリング接続は、プライベート IPv4 アドレスまたは IPv6 アドレスを使用してトラフィックをルーティングする 2 つの VPC 間のネットワーク接続です。いずれかの VPC 内のインスタンスまたはワーカーノードは、あたかも同じネットワーク内にあるかのように相互に通信できます。N3 トラフィックがオンプレミスから AWS 上の UPF に到着すると、UPF は NAT を実行して UEIP を UPF ENI IP に変換してから N6 インターフェイスに送信します。UPF からの N6 データネットワークトラフィックは、VPC ピアリングをネクストホップとして使用してアプリケーション VPC にルーティングされます。完全修飾ドメイン名 (FQDN) アプリケーションアドレスは、ネットワーク機能 VPC をアプリケーション VPC の Amazon Route 53 プライベートホストゾーンに関連付けることで解決されます。 設計5: Transit Gateway 経由の AWS 上のプライベートデータネットワークへのユーザープレーンのブレークアウト このアーキテクチャは、プライベートネットワークの他の一般的なユースケースの 1 つです。5G ネットワーク機能とユースケースアプリケーションの両方が AWS 上のそれぞれの VPC 上で 動作します。2つのVPCは、VPCアタッチメントを介して Transit Gateway を使用して相互接続されます。VPC アタッチメントの詳細については、 こちら をご覧ください。UPF からの N6 データネットワークトラフィックは、ネクストホップとして Transit Gateway 経由でアプリケーションにルーティングされます。FQDN アプリケーションアドレスは、ネットワーク機能 VPC をアプリケーション VPC の Route53 プライベートホストゾーンに関連付けることで解決されます。VPC ピアリングとは異なり、Transit Gateway では推移的なルーティングが可能です。 設計6: AWS Resource Access Manager 経由のサブネット共有による AWS上 のプライベートデータネットワークへのユーザープレーンのブレークアウト このアーキテクチャは、ある AWS アカウントで動作する UPF からの N6 データネットワークトラフィックが、別の AWS アカウントで動作しているアプリケーションに送信されるプライベートネットワークのユースケースです。UPF の N6 インターフェイスとアプリケーションインターフェイスの両方が同じサブネット上にあります。サブネット共有は AWS Resource Access Manager (AWS RAM) を使用してリソース共有を作成することで可能になります。VPC 所有者であるネットワーク機能 VPC は、アプリケーションアカウントとサブネットを共有します。 共有されると、アプリケーションアカウントはサブネットにアクセスし、VPC リソースを起動できるようになります。サブネット共有の詳細については、 こちら をご覧ください。 まとめ  LTE や 5G のユーザープレーントラフィックをインターネットや非ローミングシナリオのアプリケーションにブレイクアウトする方法については、複数の設計があります。AWS はパブリックネットワークとプライベートネットワークの両方のユースケースで、CSP がアプリケーションに SGi または N6 トラフィックを送信できるようにする様々なサービスを提供しています。アーキテクチャ設計を選択する際には、遅延、アプリケーションのエントリポイントまたはアクセスポイント、そしてユースケースなどの要素を考慮する必要があります。詳細については、 AWS for Telecom をご覧ください。 この記事はアマゾン ウェブ サービス ジャパンの黒田由民が翻訳を担当しました。 (原文は こちら ) Rolando Jr Hilvano Rolando Jr Hilvano は、Amazon Web Services (AWS) のワールドワイドテレコムビジネスユニットのプリンシパルテレコムソリューションアーキテクトです。彼は 5G 分野を専門としており、通信領域のパートナーや顧客と協力しながら、AWS 上で通信ワークロードの構築やデプロイをしています。

このブログは、AWSの以下のメンバーによって共同執筆されました： Pavol Masarovic, EMEA Principal SAP Innovation Architect Allison Quinn, Senior Analytics Solutions Architect Australia and New Zealand Peter Perbellini, Head of APJ Solutions Architecture, ERP on AWS はじめに AWSでは、お客様からSAPシステムをクラウドに移行するだけでなく、データに対して分析機能を活用し、組織の変革を実現したいという声をよく聞きます。去年リリースされたジョイントレファレンスアーキテクチャ (JRA) に沿って、RISE with SAP on AWS を採用している客様に更なる価値をもたらすために、AWS ネイティブサービスを統合しています。AWS と SAP BTP の ジョイントレファレンスアーキテクチャ は、異なるビジネスソリューションシナリオでどのように SAP BTP や AWS サービスを使用するかについて、お客様やパートナー様からの質問に対応するために開発されました。 SAP のお客様は既に AWS 上のデータレイクを活用し、SAP と SAP 以外のデータを組み合わせ、AWSの業界をリードするストレージとアナリティクス機能を活用しています。その中には、 Bizzy 、 Invista 、 Zalando 、 Burberry 、 Visy 、 Delivery Hero 、 Engie のようなお客様を含め、何年前からこのような取り組みを行っているお客様は複数います。お客様は、SAP と SAP 以外のデータ (例えば、CRM システムからのリード情報、顧客満足度点数、住宅統計、気象データ) を組み合わせたエンタープライズ・ダッシュボード、ML モデル、「what-if」シナリオを構築する方法を探しています。 AWS Analytics Fabric for SAP ソリューションを利用することで、SAP on AWS のお客様は、構築に必要な AWS サービスを考える負担がなくなり、構築作業を最大 90% 削減しながら、データドリブンアプローチにより数時間以内にSAPデータから実用的な洞察を得られます。 AWS Analytics Fabric for SAP を使用することで、ユーザーは製品、顧客、販売注文、納品、請求書などの機能領域を選択することができ、ソリューションのテンプレートには必要なテーブルとそれらの関連性を特定します。 AWS Analytics Fabric for SAP は以下の内容を含めます。 生成される データモデル は、ビジネスコンテキストを持ち、ビジネスフレンドリーな名前を提供 差分データ抽出 (CDC)、データ変換ルール、カスタムフィールドの自動的に含める包括的な機能を備えた、シンプルで適応性の高いニアリアルタイムの データパイプライン を実現 Amazon S3 で高度にスケーラブル可能な AWS データレイクを構築し、 Amazon S3 Intelligent Tiering を使用して費用対効果の高い階層に データを保存 ユーザが SAP データおよび  SAP 以外のデータに対して高度な分析やレポート作成をするために、高品質のデータモデルを提供 AWS Analytics Fabric for SAP を使用する主なメリット AWS Analytics Fabrics for SAP は、RISE のお客様の変革を加速し、AWS のデータ分析や AI/ML サービスからさらなる価値を引き出すために構築されました。モダンデータアーキテクチャのフレームワークに基づいているため、SAP on AWS のすべてのお客様がデータを活用し、ビジネスユースケースの要件に応じて拡張することも可能です。これらのアクセラレータは、開発のベースラインとして使用したり、お客様の要件に合わせて簡単に変更・カスタマイズすることができます。 データの取り込みは、標準で提供される SAP Business Content Extractor に基づいています。これらは要件に応じて、 SAP HANA CDS ビューまたはソーステーブルから抽出するように変更できます。データ取り込み処理は、分単位の間隔でスケジュールし、差分データのみ抽出します。この方法では、データソースで行われた変更を含めすべてのデータが取り込まれます。 その後、データは Amazon Redshift にロードされますが、ロードの処理は AWS Step Functions で制御され、参照整合性のために適切な順序を保ちます。Amazon Redshift 側には、様々な SAP ソースを結合したデータモデルのサンプルも提供されており、 Amazon QuickSight でこれらのデータを迅速に利用し、洞察を得ることができます。お客様は、これらの事前定義されたデータモデルを簡単に改修したり、SAP のソースデータを Redshift やデータレイク環境で利用可能な他のデータと簡単にモデリングできます。 このアーキテクチャ図は、OData プロトコルを介して SAP からデータを抽出し、AWS 上で SAP データを使用してクラウドデータウェアハウス構成と構築ステップを表しています。 以下は各ステップの説明です。前提条件に関しては次のセクションで詳しく説明します。 前提条件 – 標準の SAP Business Content Extractors をインストールし、有効化します。SAP システムの SAP Gateway で、ODP ベースの OData を設定します。 前提条件 – Amazon AppFlow から SAP ソースシステムへの OData 接続先を作成します。SAP on AWS 又は VPN /ダイレクトコネクト経由で AWS との接続がある場合はPrivateLinkを使用可能であり、またはインターネット経由での接続も可能です。 前提条件 – データを保存する Amazon S3 バケットを作成します。 Amazon AppFlow で、ステップ 2 で作成した SAP ソースとの接続先を使用してフローを作成します。フローを実行して SAP からデータを抽出し、Amazon S3 バケットに保存します。 Amazon S3 バケットに抽出された SAP データのメタデータを認識するために、データカタログエントリを作成します。 ‘ COPY ‘ コマンドで Amazon Redshift にデータをロードします。データを適切にモデル化し、データの過去の動きを可視化する機能を有効にします Amazon Redshift をデータソースとして Amazon QuickSight でデータセットを作成します。要件に応じてビジネスデータのダッシュボードを作成します。 AWS Step Functions でエンド・ツー・エンドのプロセスを自動化します。 SAP ソースシステムから抽出されたデータにより、お客様は直ちに、受注件数、受注総額、未決済受注件数および未決済受注総額、返品件数、平均受注額（AOV）、納期遵守率（DIFOT）、請求済み受注、受注処理率等のOrder-to-Cashに関連する主要業績評価指標（KPI）を導き出すことができます。これに加えて、データの差分抽出（CDC）を活用することで、お客様は、注文数量変更や納品時間枠変更など、データ更新を含む各注文のジャーニーを時系列で分析することができます。 前提条件 AWS Analytics Fabric for SAPのデプロイには3つの前提条件があります。 Git レポジトリ に記載されているエクストラクタをSAPシステムでインストールします。既に SAP BW システムがある場合は、すでにインストールされているかもしれません。これらのエクストラクタは、トランザクションコード SEGW で ODataサービスのソース ODP として定義する必要があります。 Amazon AppFlow で SAP システムへの 接続先 を作成します。これは接続先の情報と認証情報だけの簡単な入力も可能であり、AWS と SAP システム間の AWS PrivateLink を使う場合 PrivateLinkの情報も必要になります。これは 1 回だけ行う必要があるステップです。 SAP データを格納する Amazon S3 バケット を作成します。 これらの前提条件が完了すれば、残りの構築ステップはスムーズになります。 デプロイメント デプロイは、 AWS CloudFormation テンプレートとスクリプトを使用して自動化されており、必要に応じて迅速に実装、変更、拡張することができます。テンプレートはパラメータ化されており、迅速なデプロイが可能です。AWS Analytics Fabric for SAP の初回リリースは、”Order to Cash ” プロセスにフォーカスしており、他のプロセスも今後リリースされる予定です。 Git リポジトリのガイダンスに従って、定義された順序で各コンポーネントを実装してください。 Git レポジトリ には、テンプレート以外に、ほかの参考情報も記載してあります。 デプロイのステップは以下になります。 SAP システムからデータを抽出するために Amazon AppFlow のフローをデプロイします。これにより、自動的にフローがアクティブになり、指定したタイミングに基づいてデータの取り込み処理が実行されます。 データエントリーの技術メタデータカタログである AWS Glue データカタログ をデプロイします。これにより、Amazon Athena などのサービスでデータを参照して利用できるようになります。 Redshift クラスタを作成するために、Git レポジトリに Redshift 用のスクリプトがあります。最初に DDL（データ定義言語）スクリプトを実行し、データをロードするためのテーブル定義を作成します。その後、ほかのスクリプトを実行し、データパイプラインコンポーネントとCDC（Change Data Capture）パイプライン管理を作成します。すべてのテンプレートスクリプトは定義済みですが、SAP ソースシステムでカスタマイズがある場合など、カスタマイズや変更、拡張が可能です。 プロセス全体のオーケストレーションとデータパイプラインアラートのために Step Functions をデプロイします。 Amazon QuickSight アカウント を作成し（まだアクティブなアカウントがない場合）、 Amazon Redshift クラスタ に接続し、Amazon Redshift で使用可能なモデリングされたデータに基づいてデータソースを定義します。 上記は、提供された CloudFormation テンプレートのデータセットを使って Amazon QuickSight での可視化の例です。SAP 注文の異常検知や予測を追加するために、機械学習を活用した洞察機能で Order-to-cash の様々な KPI を可視化することができます。 まとめ AWS Analytics Fabric for SAP は、ビジネスユーザーが SAP データから迅速に実用的な洞察を得られるために、簡単で効率的な方法を提供しています。AWS 上で SAP 環境を稼働しているお客様は、AWS マネジメントコンソールでこのサービスを使い始めることができます。また、オンプレミスで SAP システムを稼動しているお客様は、SAP データを Amazon S3 に格納することで、AWS 上で強力なデータレイクを作成し、SAP への投資効果拡大や企業データから新たな価値を得ることができます。 アクセラレータを利用するための初期費用は不要で、利用する AWS サービスに対する課金となります。例としては、Amazon AppFlow のフロー実行コストは、実行ごとにわずか $0.001 です。販売伝票ヘッダーの取込みを 5 分ごとに 24 時間実行する場合、1 日あたり 288 回の実行があり、1ヶ月あたりのコストは $8.76 となります ( 1 日288 回 * ( 月の平均 730 時間 / 1 日 24 時間) =　月に 8760 フロー実行 * $0.001 = $8.76 ) 。また、処理したデータ量に応じて、1GB までは 1GB あたり $0.02、1GB 以上は 1GB あたり $0.10 の課金になります。差分抽出を実行することで、データ処理コストを最小限に抑えられます。Glue データカタログは、最初の 100 万オブジェクトの保存料と、最初の月間 100 万リクエストは無料です。Redshift サーバーレスの価格は、RPU 時間（Redshift 処理ユニット）あたり $0.36 からです。AWS価格の詳細については、 AWS Pricing Calculator をご覧ください。(**この例の参考価格はすべて us-east-1 リージョンに基づいていることをご注意ください。) 始めるには、まず AWS Analytics Fabric for SAP のリポジトリ をご覧ください。AWS が何千のアクティブな SAP お客様にイノベーションプラットフォームとして選択された理由は、 AWS for SAP のページをご覧ください。 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。

11月28日、 Amazon Q を発表しました。これは、仕事用に設計された新しい生成系人工知能 (AI) 搭載アシスタントで、お客様のビジネスに合わせてカスタマイズできます。Amazon Q を使用して、会社の情報リポジトリ、コード、データ、企業システムに接続することで、会話し、問題を解決し、コンテンツを生成し、インサイトを獲得し、行動を起こすことができます。Amazon Q は、タスクを合理化し、意思決定と問題解決を加速し、職場での創造性とイノベーションを促進するために、関連性の高い情報とアドバイスを従業員に即座に提供します。 Amazon Q はユーザーベースのプランを提供しているため、製品の使用方法に合わせた機能、料金、オプションを利用できます。Amazon Q は、ビジネスの既存のアイデンティティ、ロール、許可に基づいて、個々のユーザーに合わせてインタラクションが行えます。AWS は、基盤となるモデルのトレーニングに Amazon Q のお客様のコンテンツを使用することはありません。 つまり、会社の情報は安全かつプライベートに保たれます。 この記事では、 Amazon Q を一般的なビジネス用途 に使用する方法について簡単に説明します。 デベロッパーと IT プロフェッショナルが Amazon Q を使用する方法については、「 Amazon Q は IT 専門家とデベロッパーに生成系 AI を活用した支援を提供 プレビュー 」を参照してください。 ビジネスアナリストが QuickSight で Amazon Q を使用する方法については、「 QuickSight の新しい Amazon Q では、生成系 AI アシスタンスを使用して、データインサイトをより迅速かつ簡単に取得 (プレビュー) 」を参照してください。 コンタクトセンターのエージェントによる Amazon Q in Connect の活用法については、「 Amazon Q を含む Amazon Connect の新しい生成系 AI 機能により、コンタクトセンターサービスをさらに向上 」を参照してください。 Amazon Q はお客様のビジネスのエキスパートです ビジネスユーザーが簡単な自然言語プロンプトを使用してタスクを完了するのに Amazon Q がどのように役立つかについて、いくつかの例を見てみましょう。マーケティングマネージャーは、Amazon Q に依頼して、プレスリリースをブログ記事に変換させたり、プレスリリースの概要を作成させたり、提供されたリリースに基づいて E メールをドラフトさせたりすることができます。Amazon Q は、例えば社内のスタイルガイドなどの会社のコンテンツを検索して、会社のブランド基準に適した回答を提供することができます。次に、Amazon Q に依頼して、各ソーシャルメディアチャネルを通じてストーリーを宣伝するためのカスタマイズされたソーシャルメディアプロンプトを生成してもらうことができます。その後、Amazon Q に依頼して、キャンペーンの結果を分析し、経営陣がレビューできるように要約してもらうことができます。 次の例では、 2023 年の AWS ニュースブログの記事 へのアクセス権を持つ Amazon Q をデプロイし、アシスタントを「AWS ブログエキスパート」と呼びます。 前の例に戻って、私がマーケティングマネージャーで、最近の会社のブログ記事のためにソーシャルメディアの投稿を作成するのを Amazon Q に手伝ってもらいたいとします。 次のようなプロンプトを入力します。「Antje が最近の AWS Weekly Rounup の記事から得た重要なインサイトを要約し、最も重要な点を強調するだけでなく、エンゲージメントを促進する、説得力のあるソーシャルメディアの投稿を作成してください。ターゲットオーディエンスを考慮し、ブランドアイデンティティに沿ったトーンになることを目指してください。ソーシャルメディアの投稿は、読者がクリックして記事全体を読むように促すために、簡潔で有益で魅力的なものでなければなりません。コンテンツは共有可能で、視認性を最大限高めるために関連するハッシュタグを含めるようにしてください。」 舞台裏では、Amazon Q は接続されたデータソース内のドキュメントを検索し、私のブログ記事に基づいてソーシャルメディアの投稿のための詳細な提案を作成します。Amazon Q は、どのドキュメントが回答の生成に使用されたかも教えてくれます。この場合、問題のブログ記事の PDF ファイルです。 管理者は、応答のコンテキストを定義し、無関係なトピックを制限し、信頼できる企業情報のみを使用して応答するか、基盤となるモデルからの知識で応答を補完するかを設定できます。信頼できる企業情報のみに基づく応答に制限することで、ハルシネーションを軽減できます。ハルシネーションは、基礎となるモデルが、もっともらしく聞こえるが、誤解されたデータや存在しないデータに基いた応答を生成するという、一般的な現象です。 Amazon Q はきめ細かなアクセスコントロールを行うことができ、応答を従業員のアクセスレベルに基づいたデータの使用や行動に制限したり、事実確認とトレーサビリティのために元の情報源への引用や参照を提供したりします。 Amazon S3 、Google Drive、Microsoft SharePoint、Salesforce、ServiceNow、Slack など、一般的なデータソースやエンタープライズシステムに対応する 40 種類以上の組み込みコネクタの中から選択できます。 Amazon Q をビジネスに合わせてカスタマイズする方法 Amazon Q をビジネスに合わせてカスタマイズするには、 コンソールで Amazon Q に移動し、左側のメニューで [Applications] (アプリケーション) を選択し、 [Create application] (アプリケーションを作成) を選択します。 これにより、次のワークフローが開始されます。 ステップ 1 . アプリケーションを作成します 。アプリケーション名を指定し、Amazon Q が引き受けることができる AWS Identity and Access Management (IAM) サービスロールを新規作成するか、既存のサービスロールを選択します。このデモのアプリケーションを AWS-Blog-Expert と呼びます。次に、 [Create] (作成) を選択します。 ステップ 2 . レトリーバーを選択します 。レトリーバーは、会話中にインデックスからリアルタイムでデータを取得します。Amazon Q ネイティブリトリーバーを使用するか、既存の Amazon Kendra レトリーバーを使用するかの 2 つのオプションから選択できます。ネイティブリトリーバーは、Amazon Q がサポートするデータソースに接続できます。既に Amazon Kendra を使用している場合は、既存の Amazon Kendra レトリーバーを選択して、関連するデータソースを Amazon Q アプリケーションに接続できます。ネイティブリトリーバーオプションを選択します。次に、 [Next] (次へ) をクリックします。 ステップ 3 . データソースを接続します 。Amazon Q には、一般的なデータソースやエンタープライズシステム用のコネクタが組み込まれています。このデモでは、 Amazon S3 を選択し、ブログ記事の PDF が保存されている S3 バケットを参照してデータソースを設定します。 データソースの同期が正常に完了し、レトリーバーが正確なドキュメント数を表示したら、ウェブエクスペリエンスをプレビューして会話を開始できます。データソースの同期には、インデックスを作成するデータの量とサイズに応じて、数分から数時間かかる場合があります。 ServiceNow、Jira、Salesforce、Zendesk など、企業システムへのアクセスを管理するプラグインを接続することもできます。プラグインにより、Amazon Q はサポートチケットの作成や売上予測の分析など、ユーザーが要求したタスクを実行できます。 ウェブエクスペリエンスをプレビューしてデプロイする アプリケーションの概要で、 [Preview web experience] (ウェブエクスペリエンスをプレビュー) を選択します。これにより、カスタマイズされた Amazon Q の AWS ブログエキスパートとチャットするための会話型インターフェイスを利用したウェブエクスペリエンスを享受できます。最後のステップでは、Amazon Q ウェブエクスペリエンスをデプロイします。IAM を使用して SAML 2.0 準拠の外部 ID プロバイダー (IdP) を統合できます。Amazon Q は、SAML 2.0 に準拠しているすべての IdP と連携できます。Amazon Q は、サービス起動型シングルサインオン (SSO) を使用してユーザーを認証します。 プレビューをお試しください Amazon Q は現在、米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョンでプレビュー版をご利用いただけます。 Amazon Q がビジネスのエキスパートになれる 方法については、製品ページをご覧ください。 また、 Amazon Q Slack Gateway の GitHub リポジトリもご確認ください。このリポジトリには、Amazon Q を Slack Bot アプリケーションとしてユーザーが利用できるようにする方法が記載されています。 詳細はこちら Amazon Q のメインの製品ページ 一般的なビジネス用途向けの Amazon Q –  Antje 原文は こちら です。

アプリケーションが古くなるにつれて、アプリケーションを安全に保ち、スムーズに実行するためだけにますます多くの労力が必要になります。アップグレードを管理するデベロッパーは、過去のアップグレードで既に他のデベロッパーが発見した、重大な変更やパフォーマンスの最適化に潜む複雑さと微妙な違いを再学習する必要に迫られます。その結果、新機能と重要なメンテナンス作業のバランスを取ることが難しくなります。 11月28日、 Amazon Q Code Transformation のプレビュー版をご利用いただけるようになりました。この新機能により、 生成系人工知能 (AI) を活用した新しいタイプのアシスタントである Amazon Q を使用して、既存のアプリケーションコードを簡単にアップグレードおよび最新化できます。Amazon Q は仕事に特化して設計されており、お客様のビジネスに合わせてカスタマイズできます。 Amazon Q Code Transformation では、バージョン 8 および 11 から Java Long-Term Support (LTS) リリースであるバージョン 17 への Java アプリケーションのアップグレードが行えます。また、まもなく Windows ベースの .NET Framework アプリケーションをクロスプラットフォームの .NET に変換できるようになります。 以前は、デベロッパーは各アプリケーションのアップグレードに 2～3 日を費やす必要がありました。社内テストでは、手動アップグレードでは通常数日または数週間かかるのに対し、トランスフォーメーション機能によってアプリケーションを数分でアップグレードできることが示されています。これにより、新しいビジネス要件に集中する時間ができます。例えば、5 人で構成される Amazon のある社内チームは、2 日間で 1,000 個の本番アプリケーションを Java 8 から 17 にアップグレードすることに成功しました。アプリケーションのアップグレードには平均で 10 分かかり、最長のアップグレードにかかった時間は 1 時間未満でした。 Amazon Q Code Transformation は、既存のコードを自動的に分析し、変換プランを生成し、プランによって提案された変換タスクを完了します。その際、パッケージの依存関係を特定して更新し、非推奨で非効率なコードコンポーネントをリファクタリングし、新しい言語フレームワークに切り替え、セキュリティのベストプラクティスを組み込みました。完了したら、変更を受け入れる前に、変換されたコードを確認して、ビルドとテストの結果を完成させることができます。 これにより、わずか数ステップでアプリケーションを最新の状態に保ち、サポートを維持し、パフォーマンス上のメリットを享受し、サポートされていないバージョンを使用することによる脆弱性を取り除くことができるため、新しいビジネス要件に集中する時間を確保できます。では、これが実際にどのように機能するのかを見てみましょう。 Java アプリケーションをバージョン 8 から 17 へアップグレードする このチュートリアルでは IntelliJ IDEA を使用しています (Visual Studio Code でも同じことができます)。IDE で Amazon Q Code Transformation を使用するには、 AWS Toolkit for IntelliJ IDEA の最新バージョンをインストールし、組織から提供された AWS IAM アイデンティティセンター の認証情報を使用してサインインします。Amazon Q Code Transformation にアクセスするには、組織が使用するプロファイルで、 CodeWhisperer 管理者が Amazon Q 機能へのアクセス許可を明示的に付与する必要があることにご注意ください 。 新しいバージョンの Java に更新する時間がなかった古いプロジェクトを開きます。プロジェクトは Apache Maven を使用してビルドを管理しています。プロジェクトの XML 表現であるプロジェクトオブジェクトモデル (POM) ファイル ( pom.xml ) は、ルートディレクトリにあります。 まず、プロジェクト設定で、プロジェクトが正しい SDK バージョン (この場合は 1.8) を使用するように設定されていることを確認します。左側のペインで [AWS Toolkit] (AWS ツールキット) を選択し、次に [Amazon Q+ CodeWhisperer] タブを選択します。 [Amazon Q (Preview)] (Amazon Q (プレビュー)) セクションで、 [Transform] (変換) を選択します。 これによりダイアログが開き、変換を続行する前に、アップグレード用に正しい Maven モジュールが選択されていることを確認できます。 [Transformation Hub] (変換ハブ) ウィンドウで進捗状況を確認します。私の小さなアプリケーションではアップグレードは数分で完了しますが、大きなアプリケーションでは完了するまでに 1 時間以上かかる場合があります。 エンドツーエンドのアプリケーションアップグレードは、次の 3 つのステップで構成されます。 アプリケーションを識別し分析する – コードはクラウド内の管理環境にコピーされ、リポジトリ内の指示に基づいてビルドプロセスがセットアップされます。この段階で、アップグレードするコンポーネントが特定されます。 変換プランを作成する – コードを分析して、Amazon Q Code Transformation がコードをアップグレードするために実行するステップを列挙した変換プランを作成します。このステップには、依存関係の更新、アップグレードされたコードの構築、アップグレード中に発生したビルドエラーの反復修正などがあります。 コードを生成し、ビルドをテストし、ファイナライズする – 変換プランを繰り返し実行して、既存のコードと設定ファイルを更新し、必要に応じて新しいファイルを生成し、コードとともに提供されたテストを用いてビルド検証を実行し、失敗したビルドで特定した問題を修正します。 数分後、変換は正常に終了します。ここから、プランと変換の概要を開くことができます。提案されている変更を確認するには、 [View diff] (差分を表示) を選択します。 [Apply Patch] (パッチを適用) ダイアログに、追加、変更、または削除されたファイルの要約が表示されます。 まず、 pom.xml ファイルを選択し、次に [Show Difference] (差分を表示) (左/右矢印の付いたアイコン) を選択すると、プロジェクト内の現在のコードと提案されている変更が並べて表示されます。例えば、依存関係の 1 つ ( Project Lombok ) が、ターゲットの Java バージョンとの互換性のためにバージョンアップしていることがわかります。 Java ファイルでは、アップグレードされた依存関係で使用される注釈が更新されました。新しいバージョンでは、 @With が昇格し、(実験的な) @Wither は非推奨になりました。これらの変更は インポート ステートメントに反映されます。 また、アップグレードを完了するために加えられた変更をすばやく確認できるように、コードリポジトリにサマリーファイルを保存しています。 ファイルを確認するのに少し時間を費やします。次に、 [OK] を選択してすべての変更を確定します。 これでパッチは正常に適用され、提案された変更がコードとマージされました。リポジトリに変更をコミットし、移行が完了するのを待っていたビジネスクリティカルな変更に焦点を当てます。 知っておくべきこと Amazon Q Code Transformation のプレビューは、 AWS Toolkit for IntelliJ IDEA と AWS Toolkit for Visual Studio Code の Amazon CodeWhisperer Professional Tier のお客様に本日ご利用いただけます。Amazon Q Code Transformation を使用するには、組織が使用するプロファイルへのアクセス権を CodeWhisperer 管理者が付与する必要 があります。 プレビュー中に Amazon Q Code Transformation を使用しても追加費用はかかりません。 Apache Maven を使用して構築された Java 8 および 11 アプリケーションを Java バージョン 17 にアップグレードできます。プロジェクトのルートディレクトリには POM ファイル ( pom.xml ) が必要です。間もなく、Windows ベースの .NET Framework アプリケーションをクロスプラットフォーム .NET に変換するオプションを追加し、Linux への移行を迅速に行えるようにする予定です。 変換ジョブが完了したら、差分ビューを使用して提案された変更を確認して承認できます。最終的な変換の概要には、Amazon Q Code Transformation によって更新された依存関係と変更されたコードファイルの詳細が表示されます。また、アップグレードされたコードの最終ビルドで発生したビルドエラーの詳細も記載されており、問題の修正やアップグレードの完了に使用できます。 Amazon Q Code Transformation は、自動推論と静的コード分析への Amazon の長期投資と 生成系 AI の力を組み合わせることで、基盤モデルを組み込んでいます。これは、後方互換性のない変更で Java ライブラリのロングテールを更新する必要があることが多いコンテキスト固有のコード変換に不可欠であることがわかりました。 AWS が構築した生成系 AI を活用したコード変換に加えて、Amazon Q Code Transformation では OpenRewrite の一部を使用して、お客様の Java アップグレードをさらに加速しています。AWS では、サービスの多くがオープンソースコンポーネントで構築されており、これらのコミュニティの長期的な持続可能性を促進することは、AWS とお客様にとって非常に重要です。だからこそ、OpenRewrite のようなコミュニティに貢献し、業界全体がそのイノベーションの恩恵を受け続けることができるようにすることが当社にとって重要なのです。AWS は、Amazon Q Code Transformation のオープンソースへの移行の一環として開発された OpenRewrite レシピと改善に貢献する予定です。 「ソフトウェアがはるかに速いペースで適応できることは、どの企業にとっても最も基本的な利点の 1 つです。だからこそ、AWS がオープンソースの自動コードリファクタリング技術である OpenRewrite をサービスの構成要素として使用していることは喜ばしいことです」と、 Moderne (OpenRewrite のスポンサー) の CEO 兼共同創設者である Jonathan Schneider 氏は述べています。「AWS が OpenRewrite コミュニティに参加してくれたことを嬉しく思います。フレームワークの移行、脆弱性へのパッチ適用、API の更新をさらに簡単にするために AWS が貢献してくれることを楽しみにしています」。 Java アプリケーションを今すぐアップグレード Amazon Q Code Transformation 製品ページ – Danilo 原文は こちら です。

こんにちは！アマゾンウェブサービスジャパン合同会社ソリューションアーキテクトの松本です。2023 年 11 月 17 日に製造業のお客様を対象にした「Sustainability Event」を開催いたしました。イベントの開催報告として、このブログではイベントの背景や実施内容などをお届けいたします。 はじめに 製造業に限らず、多くのお客様はサステナビリティへの取り組み目標や戦略をサステナビリティレポートや中期経営計画に掲げており、特に環境におけるカーボンニュートラル、低炭素の具体数値目標の達成に向けて高い関心をお持ちです。私たちソリューションアーキテクトはお客様のビジネス変革や IT 変革をリードすることがミッションであり、サステナビリティの観点でもお客様をご支援する方法を常に模索しています。今回のイベントはそのアイデアの一つとして開催する運びとなりました。 イベントの狙い サステナビリティへの取り組みは、その目標を設定した経営層だけではなく、多くの場合で社員全員が当事者意識を持ち、目標達成に貢献することが求められます。普段私たちが接している技術ロールの皆様も例外ではありませんが、通常業務とサステナビリティへの貢献を関連付けることは、なかなか難しいですよね。もしくは、どのような点で IT やクラウドの活用が貢献できるのか、その手段や特徴を知る機会も限られているかもしれません。一方で、AWS には AWS Well-Architected Framework (W-A Framework) の 持続可能性の柱 や AWS Gravtion プロセッサ など、サステナビリティにおける課題を解決できるソリューションを提供しています。既にこれらのソリューションを活用しているお客様も多くいらっしゃいますが、ご存知ない方がいらっしゃることもまた事実です。 そこで私たちは、お客様にサステナビリティ目標達成に向けた最初の一歩を踏み出していただくため、AWS のソリューションとその特徴を知っていただくこと、そして実際に利用する経験の場を提供することが必要と考え、今回の企画を始動しました。 イベント概要 AWS のソリューションを効果的に学んでいただくためには、実践的な体験をすることが重要だと考えています。ただし、体験する内容に理解が無いまま取り組むこともまた効果的とは言えません。そこで今回のイベントでは、まず AWS を利用することがどういった観点でサステナビリティへ貢献できるのかを理解していただくため、 W-A Framework Boot Camp の 持続可能性の柱版 を実施しました。この Boot Camp とは、仮想シナリオとアーキテクチャをもとに、W-A Framework を使ったレビューを体験していただくワークショップです。参加者は 4 ~ 5 名のグループに分かれ、チームごとに割り当てられた項目について As-Is と To-Be を議論・整理・発表していただきます。実際に W-A Framework を使った議論とレビュー、グループ間の情報交換や質疑を重ねることによって、W-A Framework の項目に対する理解を深めることができます。 このワークショップを実施した上で、 Sustainability GameDay にチャレンジしていただきました。GameDay とは、AWS ソリューションを利用して現実世界の技術的問題を解決することを目指すゲーム化された学習イベントです。参加チームにはイベント開始と同時にセットアップ済みの AWS アカウントが与えられ、そこで発生する様々なトラブルやクエストをクリアしていきます。（詳しくは こちら をご参照ください。）GameDay には様々なポートフォリオ（シナリオ）があり、今回は「 Reuse, Recycle, Reduce, Rearchitect 」にチャレンジしていただきました。 当日の様子 当日は AWS の目黒オフィスと Amazon Chime を利用したリモートのハイブリッド形式で開催し、総勢 40 名 14 チームの方にご参加いただきました。 はじめに、エンタープライズ技術本部製造グループ本部長の岡本から開会のご挨拶をさせていただきました。サステナビリティの高いアーキテクチャは、同時にコスト最適化など異なる観点にも寄与することから、実務にも大いに活かせることを解説させていただきました。 次に、イベント全体を通じて登場する AWS Gravtion プロセッサについて、ソリューションアーキテクトの寺部からご紹介させていただきました。詳しい内容にご興味がある方は、ぜひ AWS Black Belt オンラインセミナーをご覧ください。 ( 動画 、 資料 ) 続いて、ソリューションアーキテクトの杉本からは W-A Framework の持続可能性の柱について、ご説明させていただきました。皆様も持続可能性の柱が追加になったことはご存知だと思いますが、その設計原則や質問まではご覧になっていないかもしれません。この機会にぜひ一度 チェックしてみてください。 そして午前のメインイベント、W-A Framework Boot Camp です。今回は持続可能性の柱から、4 つの質問をピックアップし、チームごとに割り当てさせていただきました。当日のシナリオは残念ながらこの場でお見せすることはできませんが、以下のようなワークシートをもとに As-Is と To-Be を議論していただきました。 約 40 分のディスカッションタイムを終え、各参加チームは自チームの検討結果を発表しながら、他チームの発表にも耳を傾けていました。 お昼休憩のあとは、いよいよ GameDay の開催です。 イントロダクションは今回の舞台となるスタートアップ企業「ユニコーンレンタル」の CEO の挨拶から始まりました。どうやらこの会社はとても自由な社風のようですね。この GameDay には「ひどいジョークに対しても大笑いする義務がある」というレギュレーションがあるのですが、ありがたいことに違反者は一人も出ませんでした。 GameDay についても、あいにく詳細を明かすことはできませんが、参加者の皆様は困難な状況に立たされてしまったユニコーンレンタルを救うべく、様々な問題に果敢に挑戦していただきました。約 2.5 時間の熾烈な戦いの末、ついに優勝チームが決定し、AWS のささやかな商品贈呈と表彰式とともにイベントの幕を閉じました。 開催を振り返って 盛況のうちに終了した丸一日のイベントでしたが、ご参加いただいた皆様からはどのようなフィードバックをいただけたのでしょうか。ここでいくつかご紹介させていただくと、「 こういうサービスがあるということはわかっていましたが、実際に作業をすることはほとんどないので勉強になりました。 」「 普段触らないサービスをに触れる機会ができ勉強になりました。 」とまさに実践の必要性をご体感いただけていたようです。また、「 サステナビリティの達成に活用できるサービスはいっぱいあると思うので、掘り下げて紹介してほしい 」のように、今回のテーマであるサステナビリティへの関心を高めて下さった方もいらっしゃり、大変嬉しく感じています。中には「 内容はよかったが私の準備が足りておらず太刀打ちできなかった 」と悔しさを滲ませるコメントもありましたが、ぜひ今後の学習やイベント参加の糧にしていただきたいと思います。 まとめ 私たちは今回のイベントをお客様がサステナビリティ目標達成に向けて初めの一歩を踏み出す場と位置付けていました。まだお客様がご存知ない、あるいは体験したことが無い AWS のソリューションを経験していただき、サステナビリティに貢献できることに多少なりとも気づいていただけたと実感しています。しかし、まだまだ至らない点があることにも気づかされました。私たちはこの一度の開催に留まらず、さらに貢献できる方法を模索し続けたいと考えています。 もし、このブログを通じて「こういったイベントに参加したい」もしくは「自社で参加者を募って開催したい」などのご要望があれば、ぜひご担当のソリューションアーキテクトか、 こちら までご連絡ください。すぐにユニコーンレンタルの CEO とともに駆けつけたいと思います。 ここまで読んでいただき、ありがとうございました。 松本 修一 アマゾンウェブサービスジャパン合同会社のソリューションアーキテクトです。普段は製造業のお客様のご支援を中心に活動しています。趣味はオンラインゲームで、日々インターネットの向こうにいる仲間たちと冒険に出かけています。

11月28日、 Amazon CodeCatalyst の新しい生成系人工知能 (AI) 機能のプレビュー版をご紹介できることを嬉しく思います。これにより、 Amazon Q を使用してソフトウェアの配信を高速化できます。 機能開発を加速する – Amazon Q の機能開発機能は、コメントや README の追加、問題の説明の改良、小さなクラスや単体テストの生成、CodeCatalyst ワークフローの更新など、デベロッパーにとって時間がかかり面倒で差別化されていないソフトウェア開発タスクの実装を加速するのに役立ちます。デベロッパーは、わずか数回クリックするだけで、自然言語の入力のみで問題内のアイデアから、完全にテストされ、マージの準備が整った実行可能なコードへと移ることができます。AI は、人間のプロンプトを実行可能なプランに変換し、ソースコードリポジトリを要約し、コード、単体テスト、ワークフローを生成し、デベロッパーに割り当てられるプルリクエストの変更を要約するという面倒な作業を行います。発行されたプルリクエストについて直接 Amazon Q にフィードバックを行い、新しいリビジョンを生成するよう依頼することもできます。コード変更が期待通りにならなかった場合は、プルリクエストから直接開発環境を作成し、必要な調整を手動で行い、新しいリビジョンを発行し、承認されたらマージを進めることができます。 例: 既存のアプリケーションで API を変更する ナビゲーションペインで [Issues] (課題) を選択し、次に [Create issue] (課題を作成) を選択します。課題に、 get_all_mysfits() API を変更して、Age 属性でソートされた mysfits を返す というタイトルを付けます。次に、この課題を Amazon Q に割り当て、 [Create issue] (課題を作成) を選択します。 Amazon Q は、課題のタイトルと説明を分析して潜在的な解決策を策定する間、課題を自動的に [In progress] (進行中) 状態に移します。課題について既に話し合いが行われている場合は、Q が何をすべきかを理解できるように、説明に簡潔に記述する必要があります。処理が進むにつれ、Amazon Q は各段階で課題に関するコメントを残して進捗状況を報告します。リポジトリに既に存在するコードの理解と、策定したアプローチに基づいて、ソリューションを作成しようとします。Amazon Q が潜在的なソリューションを上手く生成できれば、ブランチを作成し、そのブランチにコードをコミットします。次に、プルリクエストを作成し、承認されると変更をデフォルトブランチにマージします。プルリクエストが発行されると、Amazon Q は問題のステータスを [In Review] (レビュー中) に変更します。これにより、ユーザーとチームはコードをレビューする準備ができたことがわかります。 変更を要約する – プルリクエストの作成者は、発行している変更をレビュー用に要約するよう Amazon Q に依頼することで、時間を節約できます。これまで、プルリクエストの作成者は説明を手動で記述しなければならず、まったく記述しないことにする場合もあります。作成者が説明を行わないと、どのような変更が行われたのか、またその理由をレビュー担当者が理解しにくくなり、レビュープロセスが遅れ、ソフトウェアの配信に遅れが出てしまいます。 プルリクエストの作成者とレビュー担当者は、Amazon Q にプルリクエストに残されたコメントを要約するよう依頼することで時間を節約することもできます。概要は、共通のフィードバックテーマを簡単に確認できるため、作成者にとって便利です。レビュー担当者にとっては、自分自身や他のチームメンバーからの会話やフィードバックにすばやく追いつくことができるので便利です。全体的なメリットには、コラボレーションの効率化、レビュープロセスの迅速化、ソフトウェア配信の迅速化があります。 プレビューをお試しください Amazon Q は本日より、米国西部 (オレゴン) の AWS リージョンのスペースで Amazon CodeCatalyst でご利用いただけるようになります。 詳細はこちら Amazon CodeCatalyst の製品ページ Amazon CodeCatalyst ユーザーガイド – Irshad 原文は こちら です。

また一つ re:Invent が閉幕し、参加されたお客様は、期間中、技術セッションで学習し、インタラクティブなデモを巡り、仲間とネットワーキングし、re:Play セレブレーションでの楽しんだりと、忙しい1週間を過ごされたと思います。 新しいサービス、機能、ソリューションに関する素晴らしいアナウンスがあり、これらは製造業の企業がクラウドでのデジタルトランスフォーメーションの旅を加速し、パイロット状態の先にあるスケーラブルなビジネス変革のイニシアチブへの移行に役立ちます。 今回のイベントには製造業の経営層や一般参加者も多く参加され、このイベントが「ただの」開発者に向けたものという概念がなくなったことを示しています。 注目のセッションを視聴する ライブストリームされた基調講演セッションを見逃された場合は、 CEO の Adam Selipsky の基調講演 をチェックすることをおすすめします。彼はクラウドトランスフォーメーションについての視点を共有し、データ、インフラストラクチャ、人工知能と機械学習の分野のイノベーションを強調しました。 これらの進歩により、AWS のお客様は目標をより速く達成し、未開拓分野の可能性を掘り下げ、より良い未来を創造することができます。 Adam の基調講演に続いて、製造・自動車担当 Vice President の Wendy Bauer が イノベーショントーク を発表しました。 彼女は、自動車、航空宇宙、民生エレクトロニクスなどの業界の企業が、クラウドテクノロジーを使用してビジネスの運用を最適化し、上市までの時間を短縮し、新しいビジネスアプローチによって新しい収益源を生み出す方法について説明しました。 Siemens Digital Industries Software の社長兼 CEO である Tony Hemmelgarn が AWS 上で動作する Xcelerator 産業ソフトウェアポートフォリオを使用してイノベーションを起こす方法について語りました。本田技研工業のコネクテッドソリューション開発本部長の野川忠文氏、アメリカ HONDA のサステナビリティ・ビジネス開発担当 Vice President の Jay Joseph と Wendy が、AWS でのソフトウェア定義 (Software Defined) のモビリティと電動化における本田との取り組みについて語り合いました。 エマージングテックのイノベーショントーク では、AWS のエンジニアリング担当 Vice President の Bill Vass と Siemens Factory Automation の CEO Rainer Brehm が OT における課題、特にデータのアクセシビリティと IT との統合について説明しました。 また、 Siemens Industrial Edge Marketplace で利用可能な AWS IoT SiteWise Edge を発表し、生産現場からクラウドへの OT データフローを容易にすることを発表しました。これに 関連するブレークアウトセッション で、AWS IoT Industrial Edge のヘッド Nicolas Pouyez と Siemens Factory Automation のエッジエコシステム担当 Vice President の Torben Poertner が、AWS と Siemens の新しい提携について説明しました。産業機器データの AWS クラウドへの送信を簡単にし、取り組みの加速とコスト削減に役立つ AWS と Siemens の提携の詳細については、 Accelerate shop floor digitization with edge-to-cloud data integration (IOT215) のセッション録画や ブログアナウンス をご確認ください。 月曜日には、 Peter DeSantis が AWS サービスを支えるエンジニアリングに深く掘り下げました。 AWS のユニークなアプローチとイノベーション文化が、シリコンからサービスに至る全領域にわたって、パフォーマンスやコストを犠牲にすることなく、最先端のソリューションを作成する方法を詳しく紹介しています。 水曜日には、データと AI 担当の Vice President である Dr. Swami Sivasubramanian が、目の前で繰り広げられている、人間・データ・AI のパワフルな関係について探求しました。 生成系 AI は生産性と創造性を新しい方法で高めていますが、その背後は大量のエンタープライズデータと人間の知性が推進しています。 Swami は、企業が独自の生成系 AI アプリケーションを構築し、組織全体の従業員の生産性を加速するためにどうデータを使用するかについて説明しました。 登壇されたお客様は、生成系 AI ユースケースをサポートし、顧客に新しいエクスペリエンスを提供するためのデータ活用の実例について詳しく説明されました。 木曜日に最高技術責任者の Dr. Werner Vogels は、回復力がありコストを意識したアーキテクチャ設計のベストプラクティスを強調し、人工知能は、システムを開発する際にすべてのビルダーが考慮すべきものであること、そしてそれが世界に及ぼす影響についても説明しました。 すべての基調講演とイノベーションセッションの録画を ここで チェックしてください。 製造業のお客様は多くのセッションに参加されていますが、以下のリストは、現在製造業のお客様に最も人気のあるトピックをまとめたものです。 From Machine to Digital Services: Equipment as a Service (MFG 104) Improving Manufacturing at Panasonic Energy (MFG 101) Accelerating Innovation with High-Performance Computing on AWS (MFG 105) Product Innovation and Customer Engagement with Ferrari and Autodesk (MFG 106) Northvolt’s Software-defined Factories (MFG 202) Highly Automated Driving with BMW and Qualcomm (AUT 202) Cloud Migration with Zero Downtime: Toyota Drivelink Safety Connect (AUT 205) Predictive maintenance at scale: Koch Ag & Energy Solutions (AIM 216) サービス、機能、ソリューションのリリース re:Invent の直前からイベント期間中、AWS のイノベーションはまるで鳴り続けるドラムロールのようでした。まず、製造業や産業企業に適用できる、いくつかのサービスと拡張機能をリリースしました。なぜそれらが重要なのか、読み解いていきましょう。 以前のブログ で、生成系 AI には新しい製品デザインを作り出す可能性、これまでにないレベルで製造生産性を高める可能性、サプライチェーン アプリケーションを最適化する可能性があると説明しました。期間中、いくつかの生成系 AI 関連のサービスと機能をリリースしましたが、最も注目すべきは Amazon Q (プレビュー)です。Amazon Q は、企業の情報リポジトリ、コード、エンタープライズ システムにあるデータと専門知識を使用して、急ぎの質問に対して迅速で関連性の高い回答を得て、問題を解決し、コンテンツを生成や、業務上のアクションを実行するのに役立ちます。Amazon Q とチャットすると、業務の効率化、意思決定のスピードアップ、職場での創造性とイノベーションの促進に役立つ、タイムリーな関連情報とアドバイスを提供します。開発者と IT 専門家にとって、Amazon Q は AWS 上でアプリケーションやワークロードを構築、展開、運用する方法を変革します。Amazon Q は AWS Well-Architected フレームワークのパターン、ベストプラクティス、ドキュメント、ソリューションの実装についてのエキスパートであり、製造業の企業が新しいサービスと機能を知り、すぐに使い始め、新しいテクノロジーを学習し、ソリューションを設計し、トラブルシューティングを行い、アプリケーションをアップグレードするのが容易になります。また、機械学習のトレーニング時間とコストを低減し、エネルギー消費量を削減する AWS Graviton4 と AWS Trainium2 もリリースしました。さらに、 Amazon SageMaker HyperPod もリリースしました。これは、大規模なトレーニング コンピュートクラスターを管理し最適化する際の大掛かりな作業を減らし、基盤モデル (FM) のトレーニングを加速させるためのものです。SageMaker HyperPod を使えば、週や月にわたる FM のトレーニングでも中断することなく実行できます。 産業用 IoT と機械学習の新たな発表 AWS IoT SiteWise は、産業機器からのデータを大規模に収集、保存、整理、監視することを簡単にするマネージド サービスであり、より良いデータ駆動型の意思決定を支援します。新たに AWS パートナーの Domatica との統合を通じて、10 種類の産業プロトコル (Modbus (TCP & RTU)、Ethernet/IP、Siemens S7、KNX、LoRaWAN、MQTT、Profinet、Profibus、BACnet、Rest インターフェイス) に対するサポート追加の一般利用可能 (GA) を発表しました。これは、ネイティブでサポートしている OPC UA に追加されるものです。そして、機器データの取り込みと保存のコスト削減を目的とした、 アセットモデルコンポーネント 、 アセットの一括インポート 、 Lookout for Equipment との統合 、 バッファされた取り込み 、 ユーザー定義の一意の識別子 、 クエリ API/SQL 、新しい ウォームストレージ階層 などの、新たな拡張機能も発表しました。また、工場のエッジに導入されるオンプレミスソフトウェアの AWS IoT SiteWise Edge を、 Siemens Industrial Edge マーケットプレイス から直接展開できるようになったと発表しました。これにより、産業機器のデータを AWS クラウドに送信することを簡単にし、時間を短縮し、コストを削減できます。 このブログ は、AWS IoT SiteWise でリリースされた全機能のまとめを提供しており、お客様が価値を見出すまでの時間短縮に役立ちます。 また、 AWS IoT TwinMaker の拡張機能 を発表しました。これにより、顧客はデジタルツインをさらに迅速かつ効率的にモデル化し、展開し、大規模に拡大することできます。メタデータの一括操作(インポート、エクスポート、更新など)、より大きなエンティティ数とコンポーネント数をサポートする AWS IoT TwinMaker サービスクォータ の引き上げ、複雑なコンポーネントタイプを構築するための柔軟性と効率性を提供する新しい複合コンポーネントタイプが含まれます。Amazon Monitron も新しい Amazon Monitron Ex 定格センサー で進化を遂げています。これは、危険な環境向けの本質安全 (Intrinsically Safe) な製品です。 サプライチェーンのリリース 昨年の re:Invent では、製造業のお客様にとって重要なサプライチェーン領域を支援するために、AWS Supply Chain をリリースしました。今年、AWS Supply Chain は4つの新機能を発表しました: サプライプランニング、N 階層の可視化、サステナビリティ、AWS Supply Chain における Amazon Q (プレビュー)です。これらの 新機能 は、サプライヤや取引先からの原材料や部品の調達と移動を含む、サプライチェーンの上流部分を最適化します。加えて、EDI ベースのビジネスクリティカルな取引をスケールして自動化する AWS B2B Data Interchange をリリースしました。B2B Data Interchange は、取引先との EDI の構築と管理にかかる時間や、複雑さ、コストを削減し、取引データから洞察を得ることに集中できるようにします。 もう一つの産業機器メーカーに有意義なサービス発表は、 AWS Clean Rooms ML (プレビュー)です。これは、産業機器メーカーとそのエンドユーザ製造業者が、生データを共有することなく、プライバシー保護を行いながら ML を適用して予測に基づくインサイトを生成できるようにすることができます。この機能でサポートされる最初のモデルは、企業が類似セグメントのデータ作成を支援するために開発されています。 AWS Clean Rooms ML の類似モデリングを使用すれば、自社のデータを使用してカスタムモデルをトレーニングし、パートナーに少量のレコードサンプルをコラボレーションに持ち込んでもらい、基礎となるデータを保護しながら、類似レコードのセットを拡大生成することができます。 ストレージとハイパフォーマンスコンピューティングのリリース データへのアクセス速度を S3 Standard クラスに比べ10倍改善し、リクエストコストを50%削減できる Amazon S3 Express One Zone ストレージクラス をリリースしました。これは、一貫して1桁ミリ秒のリクエストレイテンシを必要とするパフォーマンス重視のアプリケーション向けに設計された最速のクラウドオブジェクトストレージです。 Amazon WorkSpaces Thin Client が一般提供開始となりました。これは、幅広いエンドユーザーにコスト効率の良い安全な仮想デスクトップへのアクセスを提供し、エンドユーザーと IT スタッフの生産性を向上させます。エンドユーザーはデバイス上のガイド付きデプロイメントエクスペリエンスを使用してエンドポイントデバイスの設定と仮想デスクトップへの接続を数分で完了でき、IT からの追加の支援を必要としません。 re:Invent の直前には、 Research and Engineering Studio on AWS (RES) もリリースしました。これは管理者がセキュアなクラウドベースの研究・エンジニアリング環境を作成し管理するための、オープンソースの使いやすい Web ベースのポータルです。RES を使用すると、科学者やエンジニアはクラウドの専門知識を必要とせずに、データの可視化やインタラクティブアプリケーションの実行が可能です。 最後に、AWS は3つ種類の 新しい Amazon EC2 インスタンス を導入しました: NVIDIA H200 Tensor Core GPU で動作する P5e インスタンスは、大規模かつ最新の生成 AI および HPC ワークロード向けです。NVIDIA L4 GPU とNVIDIA L40S GPU でそれぞれ動作する G6 および G6e インスタンスは、AI ファインチューニング、推論、グラフィックス、映像ワークロードなど、幅広いアプリケーション向けです。 終わりに 今年の re:Invent では、AWS のイノベーションが製造業のデジタルトランスフォーメーションを加速し、ビジネスを最適化するのにどう役立つかが示されました。また、開発者中心のカンファレンスから、製造バリューチェーン全体を対象としたイベントへの移行も印象的でした。本年のイベントに参加できなかったお客様は、次回の re:Invent がネバダ州ラスベガスで 2024年 12 月 2 日から 6 日の日程で開催されることを楽しみにしてください! TAGS: AWS for Industrial , aws manufacturing , Manufacturing , re:invent Scot Wlodarczak Scot は 2018 年 7 月に AWS に入社し、現在は製造業のマーケティング活動を管理しています。Scot はこれまで、シスコとロックウェル・オートメーションに勤務し、インダストリアル・マーケティング・マネージャーおよびリージョナル・マーケティング・リーダーを務めました。 Scot は、デジタル変革の過程にある産業界の顧客へのマーケティングと、IT と OT のギャップを埋めることに重点を置いてきました。 彼は幅広い業界でオートメーションの経験があります。 Scot は、ニューヨーク州立大学バッファロー校で機械工学の学位を、コロラド大学で経営学の修士号を取得しています。 コロラド在住。 本記事は AWS ブログ re:Invent wrap up for manufacturing – not only for developers anymore! を翻訳したものです。翻訳はソリューションアーキテクトの山本が担当しました。

Amazon EKS Pod Identity を利用すると Amazon EKS の Pod 単位で簡単に IAM ロール権限を与えることができます。このブログでは Amazon EKS Pod Identity を利用して Amazon Bedrock アクセスするアプリケーションを実行する例をご紹介します。 Amazon EKS Pod Identity の開始方法や詳細につきましては以下のブログをご確認ください。 ブログ： Amazon EKS Pod Identity は、Amazon EKS クラスター上のアプリケーションの IAM 許可を簡素化します 前提条件 このブログでは、既存の Amazon EKS クラスター を使用します。 Amazon Bedrock は 東京リージョン ( ap-northeast-1 ) で anthropic.claude-instant-v1 のモデルが有効化している状態とします。 Amazon EKS Pod Identity の Add-on が既存の Amazon EKS クラスター にインストールしている状態とします。 本手順で公開するアプリケーションは 0.0.0.0:80 でパブリックに公開されますので、必要に応じてセキュリティグループを利用してアクセス制限を行ってください。 特に本番環境で利用する上では Amazon EKS のセキュリティベストプラクティス をご確認の上デプロイを行ってください。 Amazon Bedrock アクセスするアプリケーションの実行 まずは IAM ロール権限がない状態で以下のソースコードで実行されるアプリケーションを build して Amazon EKS 上で実行し、Amazon Bedrock アクセスできないことを確認します。 コンテナイメージの作成 Amazon Bedrock アクセスするアプリケーションのコードの例 ( app.py ) import streamlit as st import boto3 import json st.title("Bedrock Chat") # Bedrock Runtimeサービス用のクライアント bedrock = boto3.client( service_name='bedrock-runtime', region_name='ap-northeast-1') def format_chat_history(messages): formatted_history = "" for message in messages: # ユーザーかアシスタントかに応じてロールを設定 role = "Human:" if message["role"] == "user" else "Assistant:" # メッセージを整形して追加 formatted_history += f"{role} {message['content']}\n" return formatted_history # チャット履歴の初期化 if "messages" not in st.session_state: st.session_state.messages = [] # アプリ再実行時にチャットメッセージを表示 for message in st.session_state.messages: with st.chat_message(message["role"]): st.markdown(message["content"]) # ユーザー入力の受け取り if prompt := st.chat_input("What is up?"): # ユーザーメッセージをチャットメッセージコンテナに表示 with st.chat_message("user"): st.markdown(prompt) # ユーザーメッセージをチャット履歴に追加 st.session_state.messages.append({"role": "user", "content": prompt}) # 対話履歴を整形してモデルの入力用に準備 chat_history = format_chat_history(st.session_state.messages) # アシスタントの応答をチャットメッセージコンテナに表示 with st.chat_message("assistant"): message_placeholder = st.empty() full_response = "" # 整形された対話履歴と新しいユーザー入力をモデルに送信 body = json.dumps({ 'prompt': chat_history + 'Human: ' + prompt + '\n\nAssistant:', 'max_tokens_to_sample': 1000, "stop_sequences": ["\n\nHuman:"], "anthropic_version": "bedrock-2023-05-31" }) accept = 'application/json' contentType = 'application/json' model_id = 'anthropic.claude-instant-v1' response = bedrock.invoke_model_with_response_stream( body=body, modelId=model_id, accept=accept, contentType=contentType) stream = response.get('body') for event in stream: chunk = event.get('chunk') if chunk: # 取得したチャンクを追加し、Streamlitに表示 full_response += json.loads(chunk.get('bytes').decode() )["completion"] message_placeholder.markdown(full_response + "▌") message_placeholder.markdown(full_response) # アシスタントの応答をチャット履歴に追加 st.session_state.messages.append( {"role": "assistant", "content": full_response}) Dockerfileの例 FROM python:3.11-slim WORKDIR /app RUN apt-get update && apt-get install -y \ curl \ && rm -rf /var/lib/apt/lists/* COPY ./requirements.txt /app/requirements.txt RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt COPY ./app.py /app RUN adduser --disabled-password --gecos '' streamlit USER streamlit EXPOSE 8501 HEALTHCHECK CMD curl --fail http://localhost:8501/_stcore/health ENTRYPOINT ["streamlit", "run", "app.py", "--server.port=8501", "--server.address=0.0.0.0"] requirements.txtの例 boto3==1.29.4 botocore==1.32.4 streamlit==1.28.2 Amazon EKS Pod Identity 使用する場合、 AWS SDK は 一定以上のバージョン が必要になります。 以下のようにディレクトリにソースコードを配置してコンテナ image を build し Amazon EKS から利用できる コンテナレジストリー に push を行います。 $ tree . ├── app.py ├── Dockerfile ├── requirements.txt このブログでは Amazon ECR を利用した手順をご紹介します。 以下の手順では事前に Amazon ECR 上に llm-app というプライベートレジストリが作成が必要です。 # ご自身のAWSアカウントIDを設定 export AWS_ACCOUNT_ID=XXXXXXXXXXXX # 認証トークンを取得し、レジストリに対して Docker クライアントを認証 aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin ${AWS_ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com # Docker イメージを構築 docker build -t llm-app:sample . # リポジトリにイメージをプッシュできるように、イメージにタグ付けを行う docker tag llm-app:sample ${AWS_ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com/llm-app:sample # イメージをプッシュ docker push ${AWS_ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com/llm-app:sample Amazon EKS 上での実行 以下の manifest ファイルのようにしてアプリケーションを実行します。 この手順では sample-app という Namespace を作成し、 Service は type: LoadBalancer を利用してアプリケーションを公開します。 ※Amazon EKS でロードバランサーを取り扱う場合は AWS Load Balancer Controller の利用を推奨します Namespace の manifest ファイルの例 apiVersion: v1 kind: Namespace metadata: name: sample-app Deployment の manifest ファイルの例 ※ Deployment のコンテナイメージはご自身のコンテナレジストリのイメージに変更してください。 apiVersion: apps/v1 kind: Deployment metadata: labels: app: llm-app name: llm-app namespace: sample-app spec: replicas: 1 selector: matchLabels: app: llm-app template: metadata: labels: app: llm-app spec: containers: # ご自身のコンテナレジストリのイメージに変更してください - image: XXXXXXXXXXXX.dkr.ecr.ap-northeast-1.amazonaws.com/llm-app:sample name: sampleapp Service の manifest ファイルの例 apiVersion: v1 kind: Service metadata: name: llm-app-lb namespace: sample-app spec: type: LoadBalancer selector: app: llm-app ports: - protocol: TCP port: 80 targetPort: 8501 アプリケーションを実行すると以下のようなアプリケーションが実行されます。 しかしながら、 Amazon Bedrock への IAM ロール権限が無いため画面のように AccessDeniedException となるはずです。 アプリケーション へ Amazon Bedrock へのアクセス権限を追加する Amazon Bedrock へのアクセス権限を持つ IAM ロールを作成し、 Amazon EKS 上で実行されている Pod に IAM ロールの追加を行います。 Amazon Bedrock へのアクセス権限を持つ IAM ロールの作成 IAM ロールの作成からユースケースで EKS – Pod Identity を選択し、 AmazonBedrockFullAccess の許可ポリシーを追加したロールを作成します。 Amazon EKS Pod Identity を利用して IAM ロールと ServiceAccount のアソシエーションを行う 以下の manifest ファイルのようにして ServiceAccount を作成し、Amazon EKS Pod Identity を利用して IAM ロールと ServiceAccount のアソシエーションを行います。アソシエーションは AWS Management Console 、もしくは CLI を利用して行うことができます。 ServiceAccount の manifest ファイルの例 apiVersion: v1 kind: ServiceAccount metadata: name: bedrock-sa namespace: sample-app CLI を利用したアソシエーションの例 ※ —role-arn ではご自身で作成した IAM ロールの arn を指定してください。 # IAM ロールと ServiceAccount の association aws eks create-pod-identity-association \ --cluster-name <CLUSTER_NAME> \ --role-arn arn:aws:iam::XXXXXXXXXXXX:role/eks-pod-identity-bedrock \ --namespace sample-app \ --service-account bedrock-sa # association の確認 eksctl get podidentityassociation --cluster <CLUSTER_NAME> ASSOCIATION ARN NAMESPACE SERVICE ACCOUNT NAME IAM ROLE ARN arn:aws:eks:ap-northeast-1:XXXXXXXXXXXX:podidentityassociation/develop/a-zxckaesu4um17oi7e sample-app bedrock-sa arn:aws:iam::XXXXXXXXXXXX:role/eks-pod-identity-bedrock アプリケーションへ ServiceAccount を追加する IAM ロールと ServiceAccount のアソシエーションが完了したら、あとはアプリケーションが定義されている Pod へ ServiceAccount の追加を行うだけです。 Deployment に serviceAccountName を追加し、 先程の手順でIAM ロール とアソシエーションした ServiceAccount を指定します。 Deployment の manifest ファイルの例 apiVersion: apps/v1 kind: Deployment metadata: labels: app: llm-app name: llm-app namespace: sample-app spec: replicas: 1 selector: matchLabels: app: llm-app template: metadata: labels: app: llm-app spec: # serviceAccountName を追加 serviceAccountName: bedrock-sa containers: # ご自身のコンテナレジストリのイメージに変更してください - image: XXXXXXXXXXXX.dkr.ecr.ap-northeast-1.amazonaws.com/llm-app:sample name: sampleapp アプリケーションを更新すると以下の様に、Amazon Bedrock へのアクセス権限が追加されていることがわかります。 Amazon EKS Pod Identity の良さを感じて頂いたのではないでしょうか。 まとめ このブログでは、 Amazon EKS 上で動作するアプリケーションに対して、Amazon EKS Pod Identity を利用して Amazon Bedrock への IAM ロール 権限を追加する方法をご紹介しました Amazon EKS Pod Identity を利用して ServiceAccount との IAM ロールのアソシエーションを行うと、 ServiceAccount を Pod に指定するだけで、 IAM ロールベースのアクセス権限を簡単に付与することができます。 サービスアカウントの IAM ロール (IRSA) と比較すると、 IAM ロールに Amazon EKS クラスター毎に信頼ポリシーを更新する必要がなく、複数のクラスターから IAM ロールを簡単に再利用できます。また ServiceAccount にアノテーションを付与する必要がないためよりシンプルな構成にすることができます。 このブログが皆様の Amazon EKS を利用したビジネスにお役立ちできれば幸いです。 作者情報 ソリューションアーキテクト 瀧田 直斗 (Takita Naoto) 中堅中小企業様を中心に技術的な側面からお客様のビジネスを支援させて頂いております。

11月28日、 Amazon Q のプレビュー版についてお知らせします。これは、仕事に特化した新しいタイプの生成系人工知能 (AI) 搭載アシスタントで、お客様のビジネスに合わせてカスタマイズできます。 Amazon Q には、デベロッパーと IT 専門家をサポートする一連の機能が用意されています。これで、Amazon Q を使用して、AWS でのアプリケーションの構築を開始したり、ベストプラクティスを調査したり、エラーを解決したり、アプリケーションの新機能をコーディングする際に支援を受けたりすることができます。例えば、Amazon Q Code Transformation では、Java アプリケーションのバージョン 8 と 11 からバージョン 17 へのアップグレードを今すぐ実行できます。 Amazon Q は AWS のさまざまな地域で利用できるため、どこにいても回答やアイデアを迅速に得ることができます。統合開発環境 (IDE) も含めて、Amazon Q を簡単に見てみましょう。 Amazon Q と一緒にアプリケーションを構築する アプリケーション開発は旅のようなものです。これには、調査、開発、デプロイ、最適化、および保守の継続的なサイクルが含まれます。各段階で、使用すべき適切な AWS のサービスの特定から、アプリケーションコードの問題のトラブルシューティングまで、数多くの課題があります。 17 年間にわたる AWS の知識とベストプラクティスに基づいてトレーニングを受けた Amazon Q は、開発の各段階で、AWS で新たなアプリケーション構築エクスペリエンスが得られるように設計されています。Amazon Q を使用すると、AWS の課題に対応するために必要な知識の習得し、AWS の新機能の探索、なじみのないテクノロジーの学習、イノベーションを促進するソリューションの設計に必要な時間と労力を最小限に抑えることができます。 Amazon Q の機能をいくつかご紹介しましょう。 1.会話形式の Q&A 機能 Amazon Q の会話型 Q&A 機能を活用して、AWS コンソールから焦点を移すことなく、AWS でのアプリケーションの構築を開始したり、新しいことを学んだり、ベストプラクティスを研究したり、繰り返し試したりすることができます。 この機能の使用を開始するには、 AWS マネジメントコンソール の右側にある Amazon Q アイコンを選択します。 例えば、「サーバーレス API を構築するための AWS サーバーレスサービスとは何ですか」と尋ねることができます。 Amazon Q は簡潔な説明と、質問のフォローアップやガイダンスの検証に使用できる参考資料を提供します。また、Amazon Q を使用して、質問をフォローアップしたり、繰り返し質問したりすることもできます。Amazon Q では、より詳細な回答を参考資料とともに表示します。 かなり具体的な要件があるユースケースについて質問がある場合があります。Amazon Q では、ユースケースをより詳細に説明してコンテキストを提供できます。 例えば、Amazon Q に「1 日あたり 10 万リクエストのサーバーレス API を作成することを計画しています。各リクエストはデータベースを検索する必要があります。このワークロードに最適なサービスは何ですか」と質問することができます。 Amazon Q は、お客様が使用できる AWS のサービスのリストを返します。また、回答結果を正確に参照でき、ベストプラクティスで検証されたものに限定しようとします。 知っておきたい追加情報を次に示します。 Amazon Q の会話型 Q&A 機能は、現在、すべての商用 AWS リージョンでプレビュー中です。 この機能は、 AWS マネジメントコンソール 、 AWS コンソールモバイルアプリケーション 、 AWS ドキュメント 、 AWS ウェブサイト 、および AWS Chatbot を通じて Slack と Teams に統合されているため、より便利で必要な情報を簡単に見つけることができます。 2.Amazon EC2 インスタンスの選択を最適化する すべてのオプションを利用できる状況で、ワークロードに適した Amazon Elastic Compute Cloud (Amazon EC2) インスタンスタイプを選択するのは難しい場合があります。Amazon Q は、パーソナライズされたレコメンデーションを提供することで、これを簡単に選択できるようにすることを目指しています。 この機能を使用するには、Amazon Q に「アプリケーションをホストするためにウェブアプリケーションサーバーをデプロイする際、どのインスタンスファミリーを使用したらよいですか」と質問してみてもいいでしょう。 この機能は、 Amazon EC2 コンソール でインスタンスを起動することにした場合にも利用できます。 [Instance type] (インスタンスタイプ) では、 [Get advice on instance type selection] (インスタンスタイプの選択に関するアドバイスを受ける) を選択できます。これにより、要件を定義するダイアログが表示されます。 要件は、Amazon Q チャットパネルのプロンプトに自動的に変換されます。Amazon Q は、お客様のユースケースに適した EC2 インスタンスの提案リストを返します。この機能により、適切なインスタンスタイプと設定を選択できるため、ワークロードを円滑かつコスト効率よく実行できます。 ユースケースに基づいて EC2 インスタンスタイプを推奨するこの機能は、すべての商用 AWS リージョンでプレビュー版として利用できます。 3.コンソールで直接エラーをトラブルシューティングして解決する Amazon Q は、さまざまな AWS のサービスのエラーをコンソールで直接解決するのにも役立ちます。Amazon Q が提案するソリューションを使用すると、手動でのログチェックや調査にかかる時間を省くことができます。 AWS Lambda 関数で Amazon DynamoDB テーブルとやり取りするとします。しかし、(まだ) 未知の理由で、実行に失敗します。Amazon Q では、 [Troubleshoot with Amazon Q] (Amazon Q でトラブルシューティング) を選択することで、この問題をより迅速にトラブルシューティングして解決できるようになりました。 Amazon Q では、エラーの簡潔な分析が行えるため、問題の根本原因を理解し、提案されている解決策を把握するのに役立ちます。この情報があれば、Amazon Q で説明されている手順に従って問題を解決できます。 わずか数分で問題を解決するソリューションが得られ、開発ワークフローを中断することなく時間を大幅に節約できます。コンソールのエラーのトラブルシューティングに役立つ Amazon Q 機能は、米国西部 (オレゴン) において、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Simple Storage Service (Amazon S3) 、 Amazon ECS 、および AWS Lambda 向けにプレビューされています。 4.ネットワークトラブルシューティングの支援 また、Amazon Q に、現在の AWS アカウントのネットワーク設定ミスによるネットワーク接続の問題のトラブルシューティングの支援を依頼することもできます。この機能では、Amazon Q は Amazon VPC Reachability Analyzer と連携して接続を確認し、ネットワーク設定を検査して潜在的な問題を特定します。 これにより、「なぜ EC2 インスタンスに SSH 接続できないのか」といった、AWS ネットワークの問題を簡単に診断して解決できます。または「インターネットからウェブサーバーにアクセスできないのはなぜですか」と Amazon Q に尋ねることができます。 次に、応答テキストで、 [preview experience here] (ここでプレビューエクスペリエンス) を選択できます。これにより、ネットワーク接続関連の問題のトラブルシューティングに役立つ説明が表示されます。 いくつかの注意点があります。 この機能は現在、米国東部 (バージニア北部) においてプレビュー版でご利用いただけます。 機能の詳細と質問例については、AWS ドキュメントの「 Amazon Q ネットワークトラブルシューティングの使用開始 」を参照してください。 5.IDE 内の統合機能と会話機能 既に述べたように、Amazon Q はサポート対象の IDE でもご利用いただけます。これにより、Amazon Q とチャットしたり、チャットボックスに「 / 」と入力してアクションを呼び出したりすることで、IDE 内で質問したり支援を受けたりすることができます。 開始するには、最新の AWS ツールキットをインストールまたは更新し、 Amazon CodeWhisperer にサインインする必要があります。Amazon CodeWhisperer にサインインすると、IDE の Amazon Q 会話機能が自動的にアクティブ化されます。Amazon Q を有効にすると、チャットを開始してコーディングの支援を受けることができます。 Amazon Q にソースコードファイルを説明するよう依頼できます。 ここから、アプリケーションを Amazon DynamoDB と統合するなどして、アプリケーションを改善できます。Amazon Q に、「データパラメータを受け入れる save_data() という名前の DynamoDB テーブルにデータを保存するコードを生成し、オペレーションが正常に実行された場合はブーリアンステータスを返す」ように依頼できます。 生成されたコードを確認したら、手動でコピーしてエディタに貼り付けることができます。 [Insert at cursor] (カーソル位置で挿入) を選択して、生成されたコードをソースコードに直接配置することもできます。 この機能により、IDE を離れて回答やコンテキスト固有のコーディングガイダンスを得る必要がなくなるため、アプリケーションの構築に本当に集中しやすくなります。この機能のプレビューは Visual Studio Code と JetBrains IDE で試すことができます。 6.機能開発能力 Amazon Q が提供するもう 1 つの素晴らしい機能は、IDE と Amazon CodeCatalyst 内でアイデアから新機能の構築まで、インタラクティブにガイドしてくれることです。対話型のステップバイステップの説明とベストプラクティスを使用して、IDE から直接、自然言語によるプロンプトからアプリケーションの機能に数分で移行できます。Amazon Q はプロンプトを使って、アプリケーション構造を理解し、プロンプトを論理的でアトミックな実装ステップに分けようとします。 この機能を使用するには、まず Amazon Q でアクションコマンド /dev を呼び出し、Amazon Q で処理する必要のあるタスクを記述します。 次に、ここから、実装が必要な特定の領域について、チャットで Amazon Q のレビュー、コラボレーション、ガイドを行うことができます。 Amazon CodeCatalyst を使用している場合は、完全なプルリクエストで機能をより早くリリースするのに役立つ追加機能を利用できます。Amazon CodeCatalyst では、新規または既存の課題を Amazon Q に割り当てて、エンドツーエンドの開発ワークフローを処理してもらえます。Amazon Q は既存のコードをレビューし、ソリューションアプローチを提案し、そのアプローチに関するフィードバックを求め、マージ可能なコードを生成し、レビュー用のプルリクエストを発行します。あとは、Amazon Q から提案されているソリューションを確認するだけです。 次のスクリーンショットは、Amazon CodeCatalyst で Amazon Q によって作成されたプルリクエストを示しています。 知っておくべきことをいくつかご紹介します。 Amazon Q の機能開発機能は現在、Visual Studio Code と Amazon CodeCatalyst でプレビュー中です。 IDE でこの機能を使用するには、Amazon CodeWhisperer Professional Tier が必要です。詳細については、 Amazon CodeWhisperer の料金表ページをご覧ください。 7.Amazon Q Code Transformation を使用してアプリケーションをアップグレードする Amazon Q を使うと、ガイド付きコード変換を開始することで、アプリケーション全体を数時間以内にアップグレードできるようになりました。Amazon Q Code Transformation と呼ばれるこの機能により、既存のアプリケーションの保守、移行、アップグレードが簡単になります。 まず、 CodeWhisperer セクションに移動し、 [Transform] (変換) を選択します。Amazon Q Code Transformation は、既存のコードベースを自動的に分析し、変換プランを生成し、プランによって提案された主要な変換タスクを完了します。 この機能に関する追加情報: Amazon Q Code Transformation は、AWS Toolkit for IntelliJ IDEA と AWS Toolkit for Visual Studio Code で本日よりプレビュー版でご利用いただけるようになりました。 この機能を使用するには、Amazon CodeWhisperer Professional Tier がプレビュー中必要になります。 プレビュー中に、Java 8 および 11 アプリケーションを Java Long-Term Support (LTS) リリースであるバージョン 17 にアップグレードできます。 Amazon Q の使用を今すぐ開始する Amazon Q では、AI エキスパートがそばにいて、質問に答えたり、コードをすばやく記述したり、問題のトラブルシューティングを行ったり、ワークロードを最適化したり、さらには新機能のコーディングを支援したりすることができます。これらの機能により、AWS でのアプリケーション構築のすべての段階が簡素化されます。 Amazon Q では、追加のサポートが必要な場合に、Q インターフェイスから AWS サポートエージェントと直接やり取りできるため、顧客がセルフサービスで行う際に直面する行き詰まりがなくなります。AWS サポートとの統合はコンソールで利用でき、AWS サポートプランで受けられていたことを引き続き利用することができます。 詳細はこちら Amazon Q のメインの製品ページ IT 専門家とデベロッパー向けの Amazon Q の詳細 Amazon Q の使用開始 – AWS のエキスパートアシスタント –  Donnie & Channy 原文は こちら です。

この投稿は、AWS と Fortinet の以下の担当者が共同で執筆しました： Ferry Mulyadi, Principal Partner Solution Architect, AWS Derek Ewell, Principal Partner Solution Architect, AWS Julian Petersohn, Global SAP Engineer, Fortinet Fabian Lee, Solution Architect, AWS Introduction CyberCrime の編集長スティーブ・モーガンによると、「 サイバー犯罪は2025年までに年間10.5兆ドルのコストを世界にもたらす 」-これは米国、中国に次いで世界第3位の経済規模に相当します。SAP システムにはミッションクリティカルなデータが格納されており、そのデータは機密性が高いことが多いため、悪質のある攻撃者にとって格好の標的となっています。S/4HANA へのモダナイゼーションを進めている SAP のお客様にとって、セキュリティリスクの状況は、SAP Fiori、Web ユーザーインターフェイス、モバイルデバイス、システムインターフェイス、SAP アプリケーションに接続されるクラウドサービスなど、新たな領域に移行しつつあります。このため、SAP のお客様は最終的に、ビジネスクリティカルなエンタープライズシステムに対して、セキュリティアップデート以外の追加のセキュリティ管理を実施する必要に迫られます。SAP のお客様を支援するために、我々は AWS Network Firewall がどのように SAP on AWS デプロイメントに対するセキュリティを向上させることができるかについてブログをシリーズで複数書きました。 最初のブログ では、送受信インターフェース、SAP サポート、リモートユーザー、モバイルアクセス、SAP BTP 統合などの SAP のユースケースに基づいて、SAP のお客様にデプロイ可能な様々なアーキテクチャパターンについて説明しました。このアーキテクチャパターンは、 AWS Security Reference Architecture (SRA) と AWS Network Firewall を使った Inspection Deployment Models に基づいており、悪意のある攻撃者が SAP システムのパフォーマンスや可用性に影響を与えるのを防ぎ、SAP システムからのデータ盗難を防ぎます。Customer Obsessionを貫く私たちは、AWS Network Firewall のデプロイ速度を向上させるためにどのような支援ができるか、常にお客様やパートナー様の声に耳を傾けています。私たちが Network Firewall を開発するとき、タスクの 1 つは SAP ネットワークトラフィックをきめ細かく制御するファイアウォール ルールを定義することです。ゼロから始める場合、この作業は大変です。 AWS マネージドルール は、AWS が作成・管理するすぐに使えるルールであり、AWS のお客様が無料で利用できるため、これらのファイアウォール ルールの実装をすぐに始めることができます。また、カスタムルールとパートナーマネージドルールについても説明しますので、組織のセキュリティニーズに合わせてより専門的なルールを導入することができます。このブログでは、Fortinet を招待し、Amazon Network Firewall 用のマネージド IDS と IPS ルールについて共有します。 Network Firewall の AWS マネージドルール AWS Network Firewall は、柔軟なファイアウォール ルールエンジンを提供し、きめ細かなネットワーク保護を実現します。Network Firewall の AWS マネージドルールは、あらかじめ定義されたすぐに使えるファイアウォール ルールです。新しい脆弱性や脅威が出現すると、AWS は自動的にマネージドルールグループを更新します。 AWS マネージドルールグループは、アプリケーションにセキュリティの別のレイヤーを追加することで、一般的な脅威からエンタープライズワークロードを保護するように設計されています。ただし、AWS マネージドルールグループは、お客様のセキュリティ責任を代替するものではありません。AWS のリソースが適切に保護されていることを確認するには、 責任共有モデル  を参照してください。 現在、AWS のマネージドルールグループには以下のものがあります： Domain List Rule Groups : HTTP または HTTPS のドメイン名に基づいてトラフィックを識別し、ブロックします。 Threat Signature Rule Groups : Threat signature のいくつかのカテゴリに基づいてトラフィックを識別し、ブロックします。 マネージド ドメインリスト ルールグループ (Egress Filtering) ドメインリストルールは、レピュテーションが低い、またはマルウェアやボットネットとの関連が知られている、または疑われているドメインへの HTTP または HTTPS トラフィックをブロックします。これらのルールグループを「 A2. インターネットエグレスアクセスのアーキテクチャ設計パターン 」（このブログシリーズのパート1）を使用してこれらのルールグループを展開すると、SAP 環境から発信される疑わしいエグレス トラフィックをブロックできます。 ルール名 説明 AbusedLegitBotNetCommandAndControlDomainsActionOrderRules 一般的には合法的だが、危険でボットネットをホストしている可能性があるドメインのクラスへのリクエストをブロックできるルール MalwareDomainsActionOrder マルウェアをホストしていることが知られているドメインへのリクエストをブロックできるルール AbusedLegitMalwareDomainsActionOrder 一般的には合法だが、危険でマルウェアをホストしている可能性があるドメインのクラスへのリクエストをブロックできるルール BotNetCommandAndControlDomainsActionOrder ボットネットをホストしていることが知られているドメインへのリクエストをブロックできるルール AWS Network Firewall は、HTTPS の TLS ネゴシエーション中に Server Name Indication (SNI) エクステンションによって、HTTP トラフィックのホストヘッダによってリクエストのドメイン名を決定します。DNS 解決レベルでドメインをフィルタリングするには、Amazon Route 53 Resolver DNS Firewall を Amazon Network Firewall ルールと組み合わせて活用することで、さらに保護することができます。： Amazon Route 53 Resolver DNS Firewall で Amazon VPC の DNS 解決を保護 SAP に適用可能な脅威シグネチャのルールグループ AWS Network Firewall が管理する脅威シグネチャのルールグループは、様々なタイプのマルウェアやエクスプロイト、サービス拒否、ボットネット、Web 攻撃、クレデンシャルフィッシング、スキャンツール、メールやメッセージング攻撃から保護するために、いくつかのカテゴリの脅威シグネチャをサポートしています。また、侵入検知や公正使用ポリシーの適用、新たな脅威に対する防御のためのシグネチャもあります。現在、Network Firewall は Suricata 互換のステートフル マネージドルールグループのみをサポートしています。 下表のルールは、SAP の技術スタックに有害な既知のシグネチャを持つ悪意のあるリクエストをブロックします。以下のようなルールは SAP のユースケースとは関係ないため除外しています： マルウェアコインマイニング、VOIP、ゲーム、不適切、P2P。実装コストを最適化するために、該当するこれらのルールを事前に選択することができます。 カテゴリ ルール名 Botnet ThreatSignaturesBotnet – アクティブなボットネットやその他のコマンド＆コントロール（C2）ホストの既知および確認された複数のソースから自動生成されたシグネチャ Botnet Web ThreatSignaturesBotnetWeb – HTTP ボットネットを検出するシグネチャ Compromised ThreatSignaturesIOC –  攻撃レスポンス – LMHost ファイルのダウンロード、特定のウェブバナーの存在、Metasploit Meterpreter kill コマンドの検出など、侵入を示すレスポンスを識別するためのシグネチャ エクスプロイトキット – エクスプロイトキットやそのインフラストラクチャ、配信に関連する活動を検知するためのシグネチャ DoS ThreatSignaturesDoS – サービス拒否（DoS）の試みを検出するシグネチャ Emerging Threats ThreatSignaturesEmergingEvents – 現在のイベント – 活発で短期間のキャンペーンや、一時的なものと予想される注目度の高い項目に対応して開発されたルールを持つ署名 DoS ThreatSignaturesDoS – サービス拒否（DoS）の試みを検出するシグネチャ Exploits ThreatSignaturesExploits – エクスプロイト – 特定のサービス・カテゴリでカバーされていない直接的なエクスプロイトから保護するシグネチャ。ActiveX、FTP、ICMP、NetBIOS、リモート・プロシージャ・コール（RPC）、ShellCode（リモート・シェルコード検出）、SNMP（Simple Network Management Protocol）、Telnet、TFTP（Trivial File Transport Protocol）、SQL（Structured Query Language） Malware ThreatSignaturesMalware – マルウェアを検出するシグネチャ（TCP、UDP、SMTP、ICMP、SMB、IP）および WORM。マルウェア – 悪意のあるソフトウェアを検出します。このカテゴリのルールは、ネットワーク上で検出された悪意のあるソフトウェアに関連するアクティビティを検出します。ワーム – 脆弱性を悪用してインターネット全体またはネットワーク内に自動的に拡散しようとする悪意のあるアクティビティを検出します。 Malware Mobile ThreatSignaturesMalwareMobile – Google Android、Apple iOS などのモバイルおよびタブレット OS に関連するマルウェアを示すシグネチャ Malware Web ThreatSignaturesMalwareWeb – HTTP と TLS プロトコルの悪意のあるコードを検出するシグネチャ Phishing ThreatSignaturesPhishing – クレデンシャルフィッシング活動を検出するシグネチャ Scanners ThreatSignaturesScanners – Nessus、Nikto、その他のポートスキャンツールなどのツールからの偵察やプロービングを検出するシグネチャ。ユーザーエージェント – 不審なユーザーエージェントや異常なユーザーエージェントを検出するシグネチャ Web Attacks ThreatSignaturesWeb – ウェブクライアント – ウェブブラウザや CURL、WGET などのクライアント側アプリケーションなどのウェブクライアントに関する攻撃や脆弱性を検出するシグネチャ。ウェブサーバー – APACHE、TOMCAT、NGINX、Microsoft Internet Information Services（IIS）、その他のウェブサーバーソフトウェアなどのウェブサーバーインフラストラクチャに対する攻撃を検出するシグネチャ。Web Specific Apps – 特定のWeb アプリケーションの攻撃や脆弱性を検出するシグネチャ。 AWS マネージドルールによる AWS Network Firewall のテスト AWS マネージドルールを実装した後、ルールの検証を行いたい場合があります。以下のようなことができます： ” ThreatSignaturesWeb ” ルールを例にしてみましょう。 AWS Network Firewall によってトラフィックが検査される Fiori を提供する SAP サーバーがある場合、 curl や metasploit などのツールを使って、ウェブサーバーのクエリセグメントにペイロードを注入してみることができます。 このブログ の例を参考にしてください。 CloudWatch Logs Log Group でアラートの Log Destination にマッチするものが表示され始めます。 次に、シグネチャを識別子として使用することで、一致する AWS Network Firewall マネージドルールを検索することができます。以下に例を示します： "alert": {             "action": "blocked",             "signature_id": 2811788,             "rev": 7,             "signature": "ipTIME firmware < 9.58 RCE",             "category": "Web Application Attack",             "severity": 1,             "metadata": {                 "created_at": [                     "2015_07_03"                 ],                 "updated_at": [                     "2020_10_01"                 ]             }         },         "http": {             "hostname": "54.179.180.129",             "http_port": 80,             "url": "/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh",             "http_user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36",             "http_method": "POST",             "protocol": "HTTP/1.1",             "length": 0         },         "files": [             {                 "filename": "/bin/sh",                 "sid": [],                 "gaps": false,                 "state": "CLOSED",                 "stored": false,                 "size": 33,                 "tx_id": 0             }         ],         "app_proto": "http"     } カスタム ファイアーウォール ルール AWS Network Firewall は、 2つのルールエンジン を使用してパケットを検査します。エンジンは、ファイアウォールポリシーで設定されたルールに従ってパケットを検査します。 ステートレス ルールエンジン – トラフィックの方向や、パケットが既存の承認された接続の一部であるかどうかなどの要素を考慮することなく、各パケットを個別に検査します。ネットワークファイアウォールのステートレスルールは、Amazon VPC のネットワークアクセスコントロールリスト（ ACL ）と動作や使い方が似ています。 ステートフル ルールエンジン – パケットをトラフィックフローのコンテキストで検査し、より複雑なルールを使用することができ、ネットワークトラフィックを記録し、トラフィックに関する Network Firewall アラートを記録することができます。ステートフルルールはトラフィックの方向を考慮します。ステートフルエンジンは、オープンソースの侵入防御システム（IPS）である Suricata と互換性のあるルールを使用します。詳細については、 AWS Network Firewall のステートフル ルールグループを使用する を参照してください。 以下のブログを参考に、独自のファイアウォールルールを作成することができます： Hands on walkthrough of the AWS Network Flexible rules engine part-1 Hands on walkthrough of the AWS Network Flexible rules engine part-2 SAP アプリケーションに関連するルールの例： #These example Firewall Rules will alert SQL injection attempts to SAP MaxDB Sybase database as well as SAP Netweaver AS Java Use Case #alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE SAP MaxDB error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"SQL error"; fast_pattern; content:"POS("; distance:0; pcre:"/SQL error.*POS\([0-9]+\)/m"; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020545; rev:2;) #alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE SAP MaxDB error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"Warning"; content:"maxdb"; fast_pattern; distance:0; pcre:"/Warning.*maxdb/m"; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020546; rev:2;) #alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE Sybase error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"Warning"; content:"sybase"; fast_pattern; distance:0; pcre:"/i?Warning.*sybase/m"; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020547; rev:3;) #alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE Sybase error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"Sybase message"; fast_pattern:only; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020548; rev:2;) #alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE Sybase error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"Sybase Server message"; fast_pattern:only; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020549; rev:2;) alert http any any -> $HOME_NET any (msg: "ATTACK [PTsecurity] SAP NetWeaver AS Java UDDI 7.11-7.50 SQL Injection (CVE-2016-2386)"; flow: established, to_server; content: "POST"; http_method; content: "/UDDISecurityService/UDDISecurityImplBean"; http_uri; fast_pattern; content: "permissionId"; http_client_body; content: "|27|"; http_client_body; distance: 0; pcre: "/permissionId\s*>[^<]+?\x27/Pi"; reference: cve, 2016-2386; reference: url, github.com/vah13/SAP_exploit; classtype: attempted-recon; reference: url, github.com/ptresearch/AttackDetection; sid: 10002408; rev: 1; ) パートナー マネージド ルール セキュリティのニーズがすぐに利用できる AWS マネージドルールを超えている場合、 パートナーの提供するソリューション を活用することができます。このブログでは、AWS パートナーである Fortinet のマネージド IDS と IPS ルールを取り上げます。 Fortinet Managed IPS Rules for AWS Firewall は、AWS Network Firewall のための設定済みのルールセットを提供し、様々なネットワーク攻撃を検知、防止するように設計されています。これらのルールは、既知の脆弱性やエクスプロイト、Web アプリケーション攻撃だけでなく、従来のセキュリティ対策では検出が困難な未知のエクスプロイトであるゼロデイ攻撃からも保護するために使用できます。 Fortinet のマネージド IPS ルールは、FortiGuard Labs が提供する最新の脅威インテリジェンスデータに基づいて定期的にメンテナンスされ、最新の脅威からお客様の環境を確実に保護します。これは、機密データが保存されているため攻撃者の標的になりやすい SAP ランドスケープにとって特に重要です。 お客様の導入要件を満たすために、 複数のグループセット が用意されています。これらのルールセットは以下の通りです： Name Technical Name クライアントの脆弱性 Fortinet-ips-client-enable-rulegroup1 Fortinet-ids-client-alert-rulegroup1 マルウェア検出 Fortinet-ips-malware-enable-rulegroup1 Fortinet-ids-malware-alert-rulegroup1 サーバおよびOSの脆弱性 Fortinet-ips-serveros-enable-rulegroup1 Fortinet-ips-serveros-enable-rulegroup2 Fortinet-ids-serveros-alert-rulegroup1 Fortinet-ids-serveros-alert-rulegroup2 Web クライアントの脆弱性 Fortinet-ips-webclient-enable-rulegroup1 Fortinet-ids-webclient-alert-rulegroup1 Webアプリケーションの脆弱性 Fortinet-ips-webapp-enable-rulegroup1 Fortinet-ids-webapp-alert-rulegroup1 Webサーバの脆弱性 Fortinet-ips-webserver-enable-rulegroup1 Fortinet-ids-webserver-alert-rulegroup1  ルールの各セットは、侵入検知シグネチャと侵入防止シグネチャの2つのサブセットで構成されます： 侵入防御シグネチャ（IPS）は DROP または ALERT アクションを実行できる 侵入検知シグネチャ（IDS）は ALERT アクションしか実行できない。 全体として、AWS Firewall 用 の Fortinet Managed IPS Rules は、SAP ランドスケープに追加のセキュリティレイヤーを提供し、ビジネスクリティカルなデータとアプリケーションの保護に役立ちます。 Fortinet Managed Rules for AWS Firewall のセットアップと検証方法の詳細については、 管理ガイド を参照してください。 SAP 専用の侵入防御シグネチャルール Fortinet は、SAP 専用にカスタマイズされたマネージド AWS ネットワークファイアウォール ルールのほか、ファイアウォール、エンドポイントプロテクション、クラウドセキュリティサービスなど、さまざまなセキュリティソリューションを提供しています。これらのソリューションは高度な脅威の検知と防止機能を提供し、既知の脅威から新たな脅威まで、幅広い脅威から SAP システムを保護します。 Fortinet は、SAP アプリケーションに特化した攻撃や悪意のある動作を防止するために、60 種類以上（さらに増加中）のシグネチャを提供しています。これらのシグネチャは、Fortinet が提供するマネージド IPS ルールの一部です。 Signature Name  Severity  Area SAP.Netweaver.publicinfo.HTTP.Request.Smuggling  Server  SAP.Netweaver.Visual.Composer.Unrestricted.File.Upload  Server  SAP.Netweaver.LM.Configuration.Wizard.Authentication.Bypass  Server SAP.Netweaver.SOAP.Query.Directory.Traversal  Server SAP.Solution.Manager.SMDAgent.Remote.Code.Execution  Server SAP.Netweaver.Log.Injection.Remote.Command.Injection  Server SAP.Netweaver.DIAG.Request.DoS  Server SAPGUI.Regsver32.Rule.Security.Policy.Bypass  Client SAP.Netweaver.CrashFileDownloadServlet.Directory.Traversal  Server SAP.Netweaver.UDDI.Server.SQL.Injection  Server SAP.SQL.Anywhere.NET.Data.Provider.Column.Alias.Buffer.Overflow  Server SAP.Sybase.Event.Stream.Processor.DoS  Server SAP.Sybase.Event.Stream.Processor.Code.Execution  Server Figure 1.  Fortinet マネージド IPS ルールにおける SAP 固有のシグネチャの例  複雑さを避けるため、これらの署名は提供されたルールグループに分散されます。SAP 導入の安全性を確保するには、以下のルールグループが非常に重要であります。 サーバおよびOSの脆弱性 Webアプリケーションの脆弱性 Webサーバの脆弱性 クライアントの脆弱性 マルウェア検出 どのルールグループがあなたのユースケースに関連するかを確認するには、 管理ガイドのユースケースのセクション を参照してください。例えば AWS 上の SAP S/4 HANA デプロイメントの場合、以下のルールグループが該当します： サーバーと OS の脆弱性、Web サーバーの脆弱性、Web アプリケーションの脆弱性。 サーバおよびOSの脆弱性 ルールグループは、オペレーティングシステムと SAP Web Dispatcher、RFC (Remote Function Call) Gateway などの SAP サービスに対する攻撃を防ぎます。 SAP が SAP Web ベースのフロントエンド Fiori に移行するにつれて、HTTP(s) リクエストは OWASP Top 10 (Open Web Application Security Project) に対して保護される必要があります。このような HTTP(s) リクエストを保護するために、AWS WAF や Forti Web のような Web Application Firewall を実装することを強く推奨します。このような Web Application Firewall は、SQL インジェクションやクロスサイトスクリプティングを特定するために、HTTP ヘッダー、HTTP ボディ、URI 文字列、ペイロードなど、 OSI モデル のレイヤー 7 の情報を分析するように設計されています。前述の Web サーバの脆弱性 および Web アプリケーションの脆弱性 管理ルールグループは、このようなシナリオにおいて基本的な Web 保護を提供します。 AWS 上の SAP S/4HANA デプロイメントを保護するコンテキストでは、 クライアントの脆弱性 ルールグループは使用されません。このルールグループは、Chrome ブラウザや SAP GUI のようなクライアントソフトウェアに対する攻撃をブロックすることにのみ有効であり、サーバーコンポーネントに対する攻撃を防ぐことはできません。SAP  デプロイがクライアントとして機能する場合、たとえば、送信トラフィック（ エグレス トラフィック）の保護とフィルタリングを行う場合は、 クライアントの脆弱性 および マルウェア検出 ルールグループが関連します。 これらのルールセットは、 FortiGuard Labs の脅威インテリジェンスから定期的に更新されるため、含まれるシグネチャの数は時間の経過とともに増加し、新しい攻撃をブロックするルールが含まれるようになります。 SAP 環境で AWS Network Firewall を使用する際の設計と使用上の考慮点 AWS 上の SAP デプロイメントに AWS Network Firewall を実装する前に、いくつかの要因を考慮することが不可欠であります。 ユースケースに応じて、 AWS WAF、AWS Network Firewall、Amazon VPC セキュリティグループの組み合わせを使用することを検討してください。 AWS Web Application Firewall (WAF) は、Application Load Balancer (ALB)、Amazon API Gateway、または Amazon CloudFront によってフロントされる HTTP ベースのトラフィックに対してレイヤー 7 の保護を提供します。 AWS Firewall Manager は、AWS 組織内の AWS リージョン、アカウント、リソースにまたがるファイアウォールルールの設定とデプロイを行うための中心的な場所として機能するセキュリティ管理サービスです 。Firewall Manager は、新しいアカウントやリソースが作成された場合でも、すべてのファイアウォールルールが一貫して適用されるようにします。Firewall Manager は、AWS Network Firewall、Amazon Route 53 Resolver DNS Firewall、AWS WAF、AWS Shield Advanced、Amazon VPC セキュリティグループと統合されています。 正当なトラフィックをブロックしないように、常にテストを実施してください。 AWS マネージド ルール グループをカスタマ マネージド ルール グループにコピーし、 含まれるルールのライフサイクルをカスタマイズまたは制御することができます。ベストプラクティスとして、本番環境に適用する前に、まずステージング環境に AWS およびパートナー マネージド ルールを実装してテストすることをお勧めします。これにより、これらの新しいルールを SAP 環境に追加した場合の影響を理解し、適切にカスタマイズすることができます。AWS Network Firewall は、”alert mode ” を介してルールとトラフィック間の相互作用の観測可能性を提供します。これにより、ルールを削除する代わりに、ルールの一致をアラートすることで、ルールをテストすることができます。AWS マネージド ルール グループについては、これを実装するためのステップバイステップの手順が ここ にあります。Fortinet マネージドルールには、IPS と IDS のバージョンがあります。IDS ルールは、ルールの一致に対してアラートを発するため、テストに使用できます。 ネットワークファイアウォール ルールと IPS シグネチャは、パフォーマンスに悪影響を及ぼす可能性があります 。AWS ネットワークファイアウォール ルールの数は、検査のパフォーマンスに影響を与えます。これらのルールは、ネットワークトラフィックをリアルタイムで分析して動作するため、ネットワークトラフィックの処理が遅くなり、SAP アプリケーションのパフォーマンスに悪影響を及ぼす可能性があります。このため、SAP Application と Database コンポーネント間のネットワークトラフィックを検査することは推奨されません。 イングレス トラフィック インスペクションとエグレス トラフィック インスペクション。 ネットワークファイアウォールによるイングレス トラフィック フィルタリングは、外部からネットワークに侵入する脅威の検出と防止に重点を置いています。一方、エグレス トラフィッ ク フィルタリングは、データの盗難/流出やその他の悪意のある行為など、ネットワークから出ようとする脅威の検出と防止に関係します。SAP システムはクライアントとして機能することができ（例：アウトバウンド Web インターフェース）、関連する エグレストラフィック検査が適用されることに留意してください。 まとめ AWS Network Firewall 用のすぐに使える AWS マネージドルールが、よく知られた攻撃から SAP 環境を保護するのに役立つことを説明しました。これは、カスタム ファイアウォール ルールを実装し、維持するためのオーバーヘッドを削減しながら、この保護を提供します。セキュリティのニーズが既存の AWS マネージドルールでカバーできない場合は、Fortinet などの AWS パートナーによるソリューションで補完することができます。 Fortinet は、AWS 上のSAP デプロイメントを保護するために特別に設計されたさまざまな Fortinet Managed IPS ルールなど、SAP デプロイメント専用のセキュリティサービスとサポートを提供しています。これらの IPS ルールは、ターゲットを絞った脅威の検出と防止機能を提供し、既知の脅威や新たな脅威から SAP システムを保護します。SAP セキュリティに対する Fortinet の取り組みは、重要なビジネスシステムを保護することの重要性を強調し、SAP 環境特有のニーズに合わせた専用のセキュリティソリューションの必要性を浮き彫りにしています。 要約すると、AWS Network Firewall は、不審なネットワークトラフィックを検査して遮断することで、AWS 上の SAP ワークロードの安全を確保し、柔軟なステートレスおよびステートフル ルールエンジンを提供することで、新たな脅威から SAP システムを保護することができます。AWS 上の安全でパフォーマンスの高い SAP デプロイメントにより、SAP ユーザーはミッションクリティカルなビジネスプロセスを完了することができます。 SAP on AWS と AWS Network Firewall の詳細については、 AWS 製品のドキュメント をご覧ください。 Fortinet  の詳細については、 Fortinet の SAP セキュリティソリューション と、 Fortinet が重要な SAP エンタープライズ環境の保護にどのように役立つか をご覧ください。 翻訳は Specialist SA 菅谷が担当しました。原文は こちら です。

AWS で SAP を実行しているお客様にとって、データベースと SAP アプリケーションの非データベースファイルシステムを保護するには、強固なバックアップ戦略を持つことが不可欠です。バックアップは、データが失われた場合でもシステムを復旧できるため、SAP ワークロードの実行において重要な役割を果たします。サードパーティ、データベースネイティブ、AWS ネイティブなどオプションが多数用意されているため、適切なバックアップツールと戦略を選択することは複雑なプロセスになる可能性があります。各オプションを慎重に評価し、ビジネスニーズ、予算、IT インフラストラクチャ全体に最適なオプションを選択することが不可欠です。バックアップとリカバリの手順を適切に計画、実装、テストすることで、停電や災害が発生した場合でも、事業継続性を確保し、ダウンタイムを最小限に抑えることができます。 このブログでは、SAP HANA、Oracle、Microsoft SQL Server、SAP ASE データベースなど、AWS 上で実行されている SAP ワークロードで利用できるさまざまなバックアップオプションの概要を包括的に説明します。また、SAP アプリケーション固有の非データベースファイルシステムのバックアップの詳細についても詳しく説明します。目的は、AWS のネイティブサービスを使用して利用できるさまざまなバックアップソリューションを読者に明確に理解してもらい、どのオプションが自分の SAP ワークロードに最も適しているかを判断できるようにすることです。このブログを読み終える頃には、SAP ワークロードを保護し、予期しない障害やデータ損失が発生した場合の事業継続性を確保するために AWS でバックアップを設定する方法についての理解が深まるでしょう。 アーキテクチャー設計 以下のアーキテクチャ設計は、AWS 上の SAP ワークロードのバックアップアプローチの概要を示しています。 データベースのバックアップから始めましょう　 データベースのバックアップから始めましょう。データベースを任意の時点に復元できるバックアップをすることで、システム停止前の状態にできるだけ近い状態に復元できます。復元するには、次の 2 種類のバックアップを実行する必要があります。 データベースのバックアップ: フルバックアップ、増分バックアップ、または差分バックアップ トランザクションログのバックアップ アプリケーションレベルで実行されるデータベース全体のバックアップに加えて、トランザクションログのバックアップは、データベースを特定の時点に復元したり、コミットされたトランザクションが永続レベルで保存された後にディレクトリからログを空にしたりするために重要です。 Amazon S3 は、あらゆる規模や業界のお客様があらゆる量のデータを保存および保護できるため、データベースのバックアップを保存するための理想的なストレージソリューションを提供します。Amazon S3 のバックアップストレージと、Amazon S3 でデータベースを直接バックアップ/復元する方法の自動化によるデータベースの保護に重点を置きます。これにより、 Amazon Elastic Block Storage (EBS) と Amazon Elastic File System (EFS) の中間ストレージにコストがかからないようになります。また、自動化されたAmazon S3 ライフサイクルポリシーにより、バックアップを Amazon S3-IA および Amazon Glacier ストレージに移動し、コストを削減することができます。これについては、このブログの後のセクションで説明します。また、バックアップは Amazon S3 バケットレプリケーションを使用して DR リージョンへレプリケートし、災害発生時に復旧することもできます。データ保護は、転送中のデータだけでなく保存中のデータに対しても提供されます。転送中のデータ保護は SSL 経由で、保存中のデータ保護は 256 ビットの高度暗号化標準 (AES-256) で提供されます。 SAP HANA データベース AWS チームは AWS Backint Agent for SAP HANA を開発しました。これは、データベースのバックアップ/復元操作を可能にする SAP 認定ソリューションです。AWS Backint Agent は SAP HANA データベースを Amazon S3 にバックアップし、SAP HANA Cockpit、SAP HANA Studio、SQL コマンドなどの SAP 管理ツールを使用して復元します。AWS Backint Agent は、Amazon S3 標準、S3 標準 – 低頻度アクセス (IA)、および S3 1 ゾーン – 低頻度アクセス (IA) へのバックアップをサポートしています。AWS Backint Agent を使用しても費用はかかりません。お支払いいただくのは、実際に使用した基盤となる AWS サービスに対してのみです。 AWS Backup は AWS Backint Agent と統合されており、SAP HANA のバックアップとリストアを実行します。 AWS Backup は、Amazon EC2 上で稼働する SAP HANA データベース向けに、シンプルで費用対効果が高く、アプリケーションと整合性のあるバックアップと復元ソリューションを提供します。AWS Backup for SAP HANA は、一元化されたコンソールベースのバックアップ管理を提供し、サポートされるすべての AWS リソースで一貫した操作を提供します。機能には、IAM ポリシーによるセキュリティの向上、専用のバックアップボールト、標準化された AWS の監視およびレポート機能へのアクセス、継続的なバックアップを最適化してポイントインタイムリカバリを行うインテリジェンスなどがあります。AWS Backup と AWS Organizations のシームレスな統合により、すべてのアカウントで SAP HANA データベースの不変なバックアップを作成して管理し、不注意や悪意のあるアクションからデータを保護し、データを復元できます。詳細については、 こちら の AWS ドキュメントを参照してください。 Oracle データベース AWS 上の Oracle データベース で SAP を実行していて、Oracle データベースのバックアップアプローチにネイティブ AWS サービスを活用したいと考えているお客様もいます。Oracle Database 9i リリース 2 以降、Oracle は Oracle データベースのバックアップ媒体として Amazon S3 の機能を拡張するセキュアバックアップ クラウドモジュールを導入しました。 Oracle Secure Backup (OSB) モジュールをサーバーにインストールすると、Amazon S3 バケットからデータベースのバックアップと復元の操作を直接実行できます。OSB を使用すると、バックアップ設定に使用される RMAN コマンドを少し変更するだけで、RMAN は Oracle データベースを Amazon S3 にバックアップできます。バックアップ実行に使用される RMAN コマンドは、テープではなく Amazon S3 を指す必要がある「destination」パラメータを除いて変更はありません。RMAN を使用すると、複数のバックアップチャネルを指定して並列処理を強化し、バックアップを高速化できます。ただし、この方法ではネットワーク帯域幅をより多く利用する可能性があります。このアプローチを使用すると、Oracle データベース バックアップを 30 分以内に構成し、5.5 TB サイズのデータベースのバックアップを 1 時間 45 分以内に実行できました。 Oracle で SAP ワークロードを実行しているお客様は、AWS ネイティブ EBS のマルチボリューム クラッシュコンシステント スナップショット を利用して、Oracle データベースのバックアップとリカバリを行うことができます。スナップショットにはフルバックアップが 1 つしか保持されず、残りはデルタスナップショットになるため、この手順はストレージコストの節約に役立ちます。さらに、バックアップの即時復元が必要な場合は、Amazon EBS 高速スナップショット復元を適用して復元速度を向上させることができます。このアプローチの利点については、 ケロッグのお客様事例 をご覧ください。 Microsoft SQL Server データベース Microsoft Windows 上の Microsoft SQL Serverには、Amazon S3 で直接バックアップ/復元操作を実行するオプションもあります。この機能を利用するには、バックアップスクリプトの Amazon S3 バケット URL をバックアップターゲットとして使用するだけです。以下の内容でバックアップスクリプトを更新してください。詳細な手順については、この ドキュメント を参照してください。 Set @FullName = ‘s3://<bucketname>.s3.<region-name>.amazonaws.com/<FolderName>/                        BACKUP DATABASE <SID> to URL = @FullName Microsoft Windows 上で実行されている Microsoft SQL Server は、VSS (ボリュームシャドウコピーサービス) 機能を使用して、整合性のとれた データベースのバックアップを実行することもできます。 VSS は AWS Backup とも統合されている ため、バックアップ/リストア操作の管理が容易になります。詳細な設定とテスト手順については、 ブログ を参照してください。 SAP ASE データベース SAP ASE (Adaptive Server Enterprise) データベースで SAP ワークロードを実行しているお客様は、バックアップストレージとして Amazon S3 を利用することもできます。このソリューションでは、 AWS ファイルゲートウェイ が HTTPS 接続を介してデータを Amazon S3 に非同期で転送する必要があります。さらに、SAP は詳細な分析を行い、この方法の設定手順を含む ソリューション を共有しました。 他のデータベースと同様に、SAP ASE データベースでは、バックアップと復元操作に Amazon EBS スナップショットを利用することもできます。Amazon EBS スナップショットを使用して SAP ASE データベースでバックアップ/復元操作を実行および自動化する詳細な手順については、この ブログ を参照してください。 適切な S3 ストレージ階層でコンプライアンスを管理 バックアップストレージの保存期間に関しては、組織によってコンプライアンス要件が異なります。これらのコンプライアンス要件は、組織全体のポリシー、SAP システムの重要性、または監査上の要件によって導かれる場合があります。コンプライアンス要件によって、バックアップの種類 (フル/増分)、バックアップの保持期間、および復元にかかる許容時間が決まります。 Amazon S3 サービスはデータベースバックアップの保存に最適なストレージです。S3 にはさまざまなストレージクラスが用意されているため、ユーザーはデータアクセス速度、ストレージコスト、データ取り出しコストの優先順位に基づいてストレージクラスを選択できます。SAP データベースバックアップの保存に使用する適切な S3 ストレージクラスを決定する主な要因は、次の 3 つです。 バックアップへのアクセスと復元に許可される最大時間 バックアップにかかる費用 バックアップの保存期間を規定する企業/業界の規制要件の遵守 ストレージクラス アクセス/取り出しスピード 最小ストレージ期間 コスト要因 S3 標準 ミリ秒 無し ストレージ S3 標準 – IA ミリ秒 30 日 ストレージ + GB あたりの取り出しコスト S3 1 ゾーン – IA ミリ秒 30 日 ストレージ + GB あたりの取り出しコスト S3 Glacier Instant Retrieval ミリ秒 90 日 ストレージ + GB あたりの取り出しコスト S3 Glacier Flexible Retrieval 分〜時間 90 日 ストレージ + GB あたりの取り出しコスト S3 Glacier Deep Archive 時間 180 日 ストレージ + GB あたりの取り出しコスト バックアップストレージの最適なコストを決定する際には、SAP データベースバックアップの全体的なコストに影響を与える「最小ストレージ期間」の要素も考慮する必要があります。S3 標準 は他のクラスに比べてストレージコストが高くなりますが、最小ストレージ期間はありません。S3 標準は、バックアップ保持要件がなく、1 週間以内のリストアポイントで良いというお客様にとって、最も費用対効果の高いバックアップストレージクラスになります。 コンプライアンス要件が数週間にわたるお客様 数週間（30 日以内）のバックアップデータを維持する必要があるという規制要件があるお客様は、S3 標準と S3 -標準 IA を組み合わせてバックアップを保存できます。 プライマリデータベースの障害/破損の場合に関連性の高い最新のバックアップは、S3 標準に保存できます (例:過去 7 日間のバックアップ)。これにより、「最小ストレージ期間」の要件によるストレージコストのオーバーヘッドなしに、バックアップからの復元が最短時間で行うことができます。 古いバックアップは、可用性要件に基づいて S3 標準- IA または S3 1 ゾーン – IA のいずれかに保存できるため、復元時間に影響を与えずに古いバックアップの全体的なストレージコストを最小限に抑えることができます。 数ヶ月にわたるコンプライアンス要件を持つお客様　 コンプライアンス要件により、数か月間（3 か月以内）のデータバックアップを維持することが義務付けられているお客様は、S3 標準 と S3 Glacier を組み合わせてバックアップを保存できます。 プライマリデータベースの障害/破損の場合に関連性の高い最新のバックアップは、S3 標準に保存できます (例:過去 7 日間のバックアップ)。これにより、「最小ストレージ期間」の要件によるストレージコストのオーバーヘッドなしに、バックアップからの復元時間を最短で行うことができます。 古いバックアップは、復元時間要件の柔軟性に応じて S3 Glacier Instant Retrievalまたは S3 Glacier Flexible Retrieval のいずれかに保存できます。 コンプライアンス要件が定義されていないお客様　 コンプライアンス要件が明確に定義されていない、またはコンプライアンス要件が不明確なお客様は、S3 Intelligent – Tiering の使用を選択できます。S3 Intelligent – Tiering は、アクセスパターンに基づいてオブジェクトを適切な S3 ストレージ階層に保存することを決定することで、ストレージコストを最適化します。S3 Intelligent – Tiering はオブジェクトのアクセスパターンを監視し、30 日間連続してアクセスがなかった場合は、データを低頻度アクセス階層に自動的に移動します。連続90日を経過したオブジェクトは、アーカイブインスタントアクセス階層に移動されます。 ファイルシステムのバックアップ 前のセクションでデータベースバックアップオプションについて説明したので、次はデータベース部分以外のバックアップオプションに焦点を当てます。通常、SAP ワークロードの Amazon EC2 インスタンスには、Amazon EBS と Amazon EFS の 2 種類のボリュームがアタッチされています。このセクションでは、両方のタイプのボリュームのバックアップ方法について説明します。 データベース以外の EBS ボリュームバックアップ SAP サーバーにはルートボリュームや SAP アプリケーション固有のボリュームなど、データベースの一部ではないいくつかの Amazon EBS ボリュームがアタッチされています。データが失われた場合に備えて、これらのボリュームをバックアップして復旧することが不可欠です。AWS Backup は、クラウド内の AWS サービス全体のデータをバックアップできる一元管理型サービスです。AWS Backup では、Amazon EBS ボリュームや Amazon EC2 インスタンスなど、さまざまな AWS リソースのバックアップ、復元、ポリシーベースの保持を 1 つのダッシュボードで行えます。AWS Backup は、以前はサービスごとに実行されていたバックアップタスクを自動化して統合するため、カスタムスクリプトや手動プロセスを作成する必要がありません。 SAP アプリケーションサーバーの場合、AWS Backup を使用して Amazon EC2 インスタンス全体をバックアップできます。または、ルートボリュームを含む個々の Amazon EBS ボリュームをバックアップして特定のファイルを復元する必要がある場合に、それぞれの Amazon EBS ボリュームを復元できるようにすることもできます。データベースサーバーでは、データベース固有のツールを使用してデータベースのバックアップがすでに行われているため、データボリュームとログボリュームを除くすべての Amazon EBS ボリュームをバックアップできます。Commvault などのサードパーティツールでも、特定のボリュームをスキップして Amazon EC2 インスタンスをバックアップできますので、 Amazon EC2 インスタンスをバックアップする代替オプションになり得ます。 共有ファイルシステムのバックアップ /sapmnt、/usr/sap/trans、/interfaces などの共有ファイルシステムは、SAP アプリケーションに不可欠な部分です。AWS のお客様は、これらの共有ファイルシステムのために、 Linux ベースのシステムでは Amazon EFS を使用し、Microsoft Windows ベースのシステムでは Amazon FSx for Windows ファイルサーバーを使用しています。AWS Backup は、Amazon EFS と Amazon FSx のファイル共有の両方をバックアップするために使用できます。AWS Backupは Amazon EFS とネイティブに統合されているため、AWS Backupによって開始された I/O 操作は Amazon EFS バーストクレジットや汎用モードの制限にはカウントされません。AWS Backup には、Amazon EFS ファイルシステムのバックアップをウォームストレージから低コストのコールドストレージ階層に移行するオプションもあります。 まとめ 結論として、バックアップと復旧は、AWS 上で実行される SAP ワークロードの重要なコンポーネントです。さまざまなバックアップオプションが用意されているため、特定のワークロードに最適なものを判断するのは難しい場合があります。私たちのブログでは、SAP HANA、Oracle、Microsoft SQL Server、SAP ASE データベース、データベース以外のファイルシステムなど、利用可能なさまざまなバックアップソリューションの概要を紹介しています。各ソリューションの違いと機能を理解することで、読者はビジネスニーズと IT インフラストラクチャを満たす適切なバックアップ戦略を選択できるようになります。バックアップを正しく構成することは、災害発生時にデータを保護し、事業継続性を確保するために不可欠です。このブログが、読者が AWS 上で実行されている SAP ワークロードについて情報に基づいた意思決定を行い、バックアップと復旧の手順を最適化するのに役立つことを願っています。 何千ものお客様が SAP ワークロードの移行、最新化、革新において AWS を信頼している理由については、 SAP on AWS ページをご覧ください。 翻訳は Specialist SA 菅谷が担当しました。原文は こちら です。

不動産仲介業者や代理店にとって、優れた不動産リスティングを行うには優れたマーケティングが必要です。 Anywhere Real Estate の Listing Concierge アプリケーションはこのニーズを満たし、リスティング促進のための直感的なツールセットを提供します。このアプリは、国内所有権管理、決済、企業移転、全国規模の住宅ローンの作成・引受に関するジョイントベンチャーなどを提供する大手住宅不動産サービスプロバイダーが開発しました。 Listing Concierge アプリケーションを設計するに当たり、Anywhere は顧客体験と拡張性に重点を置いており、そのために Amazon Web Services ( AWS ) を活用しています。 「私たちは今、大きな変革の中におり、リスティングの作成とマーケティング、資金・所有権の移転支援、クロージングに至るまで、あらゆる不動産体験を切れ目なくするために取り組んでいます。AWS は私たちの取り組みを加速させてくれます」と、 Anywhere のテクノロジーバイスプレジデントである Brian Hanks 氏は語ります。「分散型のビジネスロジックから、 AWS のサーバーレス技術を活用した単一のプラットフォームに移行することで、新しいツールをより迅速に構築できます。また、データセンターの仮想インスタンスでは不可能だったレガシーアプリケーションのリフトアンドシフトも可能です。」Anywhere のインフラストラクチャは、 AWS Lambda や AWS Fargate などのサーバーレスソリューションに加えて、 Amazon Elastic Container Service ( ECS ) , Amazon CloudFront , Amazon Route 53 , Amazon Simple Queue Service ( SQS ) , Amazon ElastiCache , Amazon Simple Storage Service ( Amazon S3 ) 、 Okta とアクセス管理プラットフォーム、およびサードパーティ製品で構成されています。 クラウド転換計画 Anywhere がクラウドへの移行を検討し始めるにあたり、同社のチームは利用可能なクラウドサービスに基づいて PoC ワークフローを開発しました。性能、拡張性、クラウド知識を持つ人材へのアクセス容易性が重要な考慮事項でした。また、チームは新しいアプリやアップデートの市場投入までの時間を短縮する必要もありました。こうした点において AWS は明らかに優れていました。 「AWS では全てがスクリプト化されているため、機能がビルドされてデプロイされるまでの間に発生する待ち時間をなくすことができます。」と Hanks 氏は言います。「私達は他のほとんどの不動産会社よりも多くのエージェントと連携しているため、拡張性が不可欠です。AWS のテクノロジーは、新しいユーザーへの対応、AI のような新しい技術の活用、Listing Concierge のようなアプリの迅速なリリースなど、プラットフォームを拡張・進化させるための柔軟性を提供しました。」 クラウド上での最高の不動産マーケティングツールを構想する 同社の Listing Concierge アプリは AWS を活用しクラウドネイティブかつサーバーレスに構築された、ウェブサイト、オンラインビデオ、パンフレットなどの不動産マーケティング資料の作成と配布を促進する多用途不動産マーケティングツールです。ユーザーはアプリにアクセスし、必要なサービス（写真、印刷広告、ウェブサイトなど）を選択し、支払いや掲載情報を送信します。その後、コーディネーターがパッケージを処理し、エージェントの承認を得るための資料を作成し、承認されると資料は発送されます。 これまで、Anywhere は複数のサードパーティソリューションを組み合わせてそれぞれのニーズに対応してきました。しかし、AWS のサーバーレスアーキテクチャとマイクロサービスを使用することで、これらすべての機能をサードパーティ製品と統合した 1 つのアプリケーションとすることができました。サードパーティ製品には支払い、通知、パンフレット等マーケティング資料の処理が含まれます。これにより、作業調整の時間を数週間から数時間に短縮しながらコストを節約できました。 AWS とチームのサーバーレスアプローチの功績を称えて、 Hanks 氏は次のように語っています。「当初はコンテナ、つまり仮想環境でアプリケーションを構築していましたが、現在ではその半分を AWS Lambda を使用するサーバーレス機能に置き換えて成果を上げています。私たちは自動化をさらに進めることで、ユーザーニーズに基づいたアプリケーションの機能調整が可能になり、ユーザー規模の拡大による性能問題にも対処できるようになりました。これは大きな成功です。エージェントはマーケティング資料の注文作業が大幅に快適になり、買い手と売り手はより良い資料をより早く入手できるようになりました。取引の迅速化に役立っています。」 Anywhere はコンテナからサーバーレスインフラへ移行を進むにつれて、複雑な画像処理ニーズへの対応が簡単だと気づきました。Listing Concierge は数十万人のユーザーに利用されているため、何百もの高解像度のリスティング写真が並行してアップロードされる可能性があります。8K でアップロードされた写真は、トリミング、構造化などの修正を加えて加工し、異なるサイズで再出力する必要があります。AWS の導入により、アプリケーションはニーズに合わせてスケーリングされ、写真ごとに個別の AWS Lambda が起動するようになりました。 「AWS Lambda は Listing Concierge が必要とするパフォーマンスを提供し、アップロードの課題を軽減します」と Hanks 氏は言います。「これまで1,500 件の画像アップロードを同時に処理しているのを確認しましたが、以前は、エージェントが個々の写真のアップロードを待たなければならなかったでしょう。今では、すべての写真を同時にアップロードし、Amazon S3 や AWS Lambda に直接送信して処理できるようになりました。美しいです。」 継続的イノベーションへの取り組み Anywhere は完全なクラウドベースの不動産テクノロジープラットフォームへのモダナイゼーションの途中にいますが、イノベーションを止めるつもりはありません。Anywhere のテクノロジー担当シニアバイスプレジデントである Damian Ng 氏は、「 AWS の最も優れた点の 1 つは、継続的に進化しており、新しい機能を活用してエージェント、ブローカー、消費者へのサービスを強化できることです」と述べています。 「 AWS チームは、テクノロジーの進歩に伴い、チームの学習、進化、改善を支援するというコミットメントを示し続けています。これは驚くべきことです」と Ng 氏は付け加えます。「 AWS との提携により、世界クラスの不動産技術組織への変革が加速します。」 Anywhere に関する詳細は https://www.anywhere.re/ をご覧ください。 本ブログはソリューションアーキテクトの奈良 一希が翻訳しました。原文は こちら 。 著者 Emily McKinzie Emily McKinzie は、アマゾン ウェブ サービスの業界マーケティングマネージャーです。

11月27日は、Amazon CodeCatalyst の新しいエンタープライズ層とカスタムブループリントをご紹介します。 Amazon CodeCatalyst のエンタープライズ層は、カスタムブループリントやプロジェクトライフサイクル管理などの機能を提供する新しい料金プランです。エンタープライズ層の料金は、ユーザー 1 人あたり月額 20 USD です。各エンタープライズ層スペースでは、有料ユーザー 1 人あたり 1,500 分のコンピューティング時間、160 時間の開発環境の利用時間、64 GB の開発環境ストレージが用意されています。カスタムブループリントを使用すると、アプリケーションコード、ワークフロー、インフラストラクチャのベストプラクティスを定義できます。また、これらのブループリントを CodeCatalyst スペースに公開して、プロジェクト作成時や既存プロジェクトへの標準適用時に使用できます。 ブループリントを使用すると、プロジェクトを数分でセットアップできるため、すぐにコーディングに取り掛かることができます。数回クリックするだけで、プロジェクトファイルを設定できるほか、特定のプロジェクトタイプのベストプラクティスを使用して、完全に統合された組み込みツール (ソースリポジトリ、問題管理、継続的インテグレーションおよびデリバリー (CI/CD) パイプラインなど) を設定できます。必要に応じて、GitHub などの一般的なツールを入れ替えることが可能で、その場合にも一貫したエクスペリエンスが保たれます。プロジェクトの存続期間中に開発者ツールの構築、統合、運用に費やす時間を削減できます。 カスタムブループリントでは、CodeCatalyst プロジェクトのさまざまな要素を定義できます。例えば、ワークフロー定義、Infrastructure as Code (IaC)、アプリケーションコードなどです。カスタムブループリントを更新すると、その変更はプルリクエストの更新として、ブループリントを使用するすべてのプロジェクトに反映されます。この合理化されたプロセスにより、プロジェクトの設定におけるオーバーヘッドが削減され、ベストプラクティスをプロジェクト全体に一貫して適用できます。管理者は、CodeCatalyst スペースの各ブループリントをどのプロジェクトが使用しているかを簡単に詳しく表示でき、プロジェクト全体における標準の適用状況を把握できます。 CodeCatalyst でカスタムブループリントを作成する CodeCatalyst コンソール を開いて、自分のスペースに移動します。 [Settings] タブの左側のナビゲーションペインで [Blueprints] をクリックし、次に [Create blueprint] をクリックします。ここで、ブループリントのベストプラクティスを体系化します。準備が完了したら、そのブループリントを自分のスペースに公開して、チームがプロジェクト作成時に使用できるようにします。 ブループリントを公開すると、 [Settings] タブの CodeCatalyst スペースにそのブループリントが表示され、管理できます。左側のパネルで、 [Blueprints] をクリックします。次に、 [Space blueprints] をクリックします。 カスタムブループリントから CodeCatalyst プロジェクトを作成するには、 [Create project] > [Space blueprints] の順にクリックします。 可用性 Amazon CodeCatalyst のエンタープライズ層は、米国西部 (オレゴン) リージョンと欧州 (アイルランド) リージョンで利用できます。ただし、デプロイは任意の商用リージョンに行えます。 詳細については、 Amazon CodeCatalyst のウェブページ をご覧ください。 構築しましょう! – Irshad 原文は こちら です。

AWS Fault Injection Service (FIS) は、大規模にカオスエンジニアリングを実践するために役立ちます。本日 (2023 年 11 月 30 日) 、FIS の新しい シナリオ を発表します。これにより、例えば AWS のアベイラビリティゾーンが全て停電したり、ある AWS リージョンから別のリージョンへの接続が途絶えた場合でも、アプリケーションが予定通りに機能するかを確認できます。 このシナリオを使った実験により、問題発生時にアプリケーションが単一リージョンでもマルチリージョンでも期待通りに機能するという自信を得られます。これにより、直接的および間接的な依存関係を深く理解し、復旧時間をテストするのに役立ちます。アプリケーションを試験して、期待通りに動作することを確認した後、実験結果をコンプライアンスの目的で使用できます。FIS と AWS Resilience Hub を組み合わせることで、アプリケーションの全体的な 耐障害性状況 を十分に理解するのに役立ちます。 シナリオ紹介 2021 年に AWS アプリケーションで制御された実験を行うため FIS を発表しました。その発表の際の 投稿 で、実験テンプレートの作成と使用方法を紹介しました。実験は、特定種類の AWS リソース群に影響を与えるよう設計された、強力かつ基本的な操作を用いて構築されます。例えば、以下のアクションは EC2 インスタンスと Auto Scaling Groups に作用します。 最近、これらのアクションをビルディングブロックとして、 AWS FIS Scenario Library を立ち上げました。ライブラリの各シナリオは、アプリケーションの回復力をテストするために使用できるイベントや条件を定義しています。 各シナリオは、実験テンプレートの作成に使用されます。シナリオをそのまま使用することも、任意のテンプレートを必要に応じてカスタマイズまたは拡張することもできます。 シナリオは、同じ AWS アカウントまたは他の AWS アカウントのリソースを対象にすることができます。 新しいシナリオ これらの情報を踏まえた上で、新しいシナリオを見ていきましょう。 AZ の可用性 : 電源の中断 – このシナリオでは、単一のアベイラビリティゾーンにある特定のリソース群に対して一時的に “電源を抜く” 操作を行います。対象となるリソースには、EC2 インスタンス (EKS および ECS クラスタのものを含む) 、EBS ボリューム、Auto Scaling Groups 、VPC サブネット、 Amazon ElastiCache for Redis クラスタ、 Amazon Relational Database Service (RDS) クラスタなどが含まれます。ほとんどの場合、複数のアベイラビリティゾーンにリソースを持つアプリケーションで実行しますが、このシナリオを単一のアベイラビリティゾーンで動作するアプリケーションに適用することもできます。この場合、アプリケーションが一時的に停止することが想定されます。単一のアベイラビリティゾーンをターゲットとし、指定した IAM ロールまたは Auto Scaling Groups が実験中に新しいインスタンスを起動したり、停止したインスタンスを起動できないようにすることもできます。 新しいターゲットとアクションエクスペリエンス では、シナリオ内のアクションと、それらが影響する AWS リソースのタイプなど、すべてを一目で簡単に確認できます： シナリオには、実験テンプレートをカスタマイズするためのパラメータが含まれています： 詳細パラメータ – ターゲティングタグ では、実験の対象となるリソースを見つけるために使用されるタグのキーと値をコントロールできます： クロスリージョン : 接続 – このシナリオは、テストリージョンにあるアプリケーションがターゲットリージョンのリソースにアクセスするのを防ぎます。これには、VPC に接続された EC2 インスタンス、ECS タスク、EKS Pod 、Lambda 関数からのトラフィックが含まれます。また、 Transit Gateway や VPC ピアリング 接続を通過するトラフィックや、リージョンをまたぐ S3 や DynamoDB のレプリケーションも含まれます。このシナリオは、初期設定で以下のようになっています： disruptionDuration パラメータを変更しない限りこのシナリオは 3 時間実行され、指定された方法でターゲットリージョンからテストリージョンを分離します。分離されたリージョン内で実験の影響を受ける AWS リソースを特定するために使うタグを管理するための詳細パラメータがあります。この設定を通じて、どのリソースが実験によって影響を受けるかを具体的に決めることができます： また、このシナリオで使用される Disrupt と Pause アクションは、それぞれ単体でも役立つかもしれません： 例えば、 aws:s3:bucket-pause-replication アクションは、リージョン内でレプリケーションを一時停止するために使用できます。 知っておくべきこと 新しいシナリオについて知っておくべきことがいくつかあります： リージョン – 新しいシナリオは、FIS が利用可能なすべての商用 AWS リージョンで、追加費用なしで利用可能です。 価格 – 実行した実験によって消費されたアクション分の時間に対して料金を支払います。詳細は AWS Fault Injection Service Pricing Page を参照してください。 サービス名 – このサービスは以前 AWS Fault Injection Simulator と呼ばれていました。 — Jeff ; Jeff Barr Jeff Barr は AWS のチーフエバンジェリストです。彼は 2004 年にこのブログを始め、それ以来ほぼノンストップで投稿を書いています。 翻訳はソリューションアーキテクト 渡部 拓実 が担当しました。原文は こちら です。

アマゾンウェブサービス (AWS) は、使いやすいクラウドコンタクトセンター Amazon Connect を 2017 年に提供開始しました。この度、提供開始以来初めて、2023 年第 1 四半期の The Forrester Wave : Contact Center as a Service でリーダーに選ばれました。このリーダーへの選出は、私たちのイノベーションのペースの早さと、それによってあらゆる規模のお客様が継続的に優れたカスタマーサービスを低コストで提供できた成功を反映していると考えています。 このレポートでは、最も重要な CCaaS プロバイダーのうち 11 社を 34 の基準で評価しています。Amazon Connect は、AI アーキテクチャ、プロアクティブエンゲージメント、カスタマーセルフサービス、エージェントデスクトップ、イノベーションロードマップ、顧客数、テキストと音声の分析を含む 11 の基準で最高得点を獲得しました。そして、AWS は最大の市場プレゼンスをもつ CCaaS プロバイダーと並びました。これは、AWS の CCaaS 分野での、財務、マーケットでの強みに関する Forrester の評価を反映していると考えています。 我々にとって、この選出は、Amazon Connect があらゆる規模の企業が顧客体験を最適化できるようにするイノベーションのスピードを物語っています。現在、何万もの AWS のお客様が Amazon Connect を使用して、毎日 1,000 万件を超えるコンタクトセンターでのやり取りを行っています。Best Western 、 Capital One、富士通、Intuit、John Hancock、New York Times、Priceline、National Australia Bank などのお客様が、Amazon Connect を使用して優れたカスタマーサービスを低コストで提供しています。 顧客体験の継続的な革新を目指すお客様にとって、 Forrester のレポートはビジネスに役立つコンタクトセンターソリューションを見つけるための貴重な指針となります。 The Forrester Wave : Contact Center as a Service, Q1 2023 の無償版はこちらからご覧いただけます 。 無料のオンラインイベント、AWS Contact Center Day もご覧ください。カスタマーサービスの未来、機械学習がどのように顧客とエージェントのエクスペリエンスを最適化できるかなどについて学ぶことができます。 今すぐ登録 ※訳注 オンラインイベントは2023年4月26日に開催されました。現在はイベントをオンデマンド配信でご覧いただけます。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

はじめに 配送プロセスの最後の段階を「ラストマイル」と呼ぶのは、サプライチェーンや物流業界では一般的であり、宅配業者が担当します。ラストマイルの配送としては、例えば準備ができた食品をできるだけ速やかに配送する必要がある「即時配送」があり、他にもECサイトで購入した商品の「当日配送」や「多日配送」も含まれます。 ラストマイルは、配送の中で最も複雑でコストのかかる部分です。宅配業者は、ビジネス、物流、技術的な多数の複雑な問題を同時に解決する必要があります。 対応可能なドライバーの位置を監視する。 ルートと車両の空きスペースに基づいて、ドライバーに最適な配車を割り当てる。 ドライバーの移動距離を最小限に抑えることで、コストを抑える。 顧客の待ち時間をできるだけ短くする。 その他の特定のビジネスルールを遵守する。 COVID-19パンデミックの世界的な流行は、消費者の行動を大きく変えました。オンラインショッピングの需要が急増し、食品や日用品の宅配サービスも大幅に伸びています。アナリストは この傾向が続く と予測しています。（ただし、流行が収束した後は、少しずつ店舗での買い物に回帰する人も出てくるでしょう。） 配送業務やラストマイル物流サービスの開始を計画しているお客様からのよくある質問に対応するため、AWS ASEAN (東南アジア諸国連合) のプロトタイピングチームは オープンソースの コンテンツ を公開しました。これにより、企業は簡単に独自のラストマイル機能を構築できると同時に、即時配送と当日配送といったニーズに対応できます。IoT、サーバーレス、機械学習、地理空間技術を活用するとともに、イベント駆動型アーキテクチャも採用しています。 これはブログシリーズの第1部です。ここでは即時配送に焦点を当て、この新機能の詳細や仕組み、既存の環境への統合方法について説明しています。第2部では当日配送について説明する予定です。 機能的アーキテクチャ AWS 即時配送機能は、大まかに言うと、以下の 機能的アーキテクチャ図 (図 1) に示すように 2 つの主要部分で構成されています。 位置の追跡。 このモジュールにより、数万人のドライバーの現在地をほぼリアルタイムで追跡し、検索することができます。単純な位置検索や、より複雑な区域内のドライバー検索が可能です。設計上の重要なポイントは、ドライバーの位置特定までのレイテンシと、システムが同時に追跡できるドライバー数のスループットの2点です。 注文の発送。 このモジュールは、ドライバーに効率的に注文を割り当てるために使用されます。即時配送と当日配送の2つのサブモジュールがあり、まず即時配送についてこの記事で紹介します。配送事業は運用コストが高く、特に配送車両の管理が主な費用となります。そのため、注文とドライバーを適切にマッチングするシステムは、収益性と事業の持続可能性に大きな影響を与えます。このソリューションでは事前に定義された最適化手法を利用していますが、これらは会社のデータやビジネス要件に応じて容易に変更可能です。 図1.機能的アーキテクチャ 高度な技術アーキテクチャ 図2.高度な技術アーキテクチャ 図2 に示すアーキテクチャは、イベント駆動型のサーバーレスシステムを示しています。イベントバスとして Amazon EventBridge を活用しており、お客様のアプリケーションやソフトウェア、AWSサービスから発生したイベントを取り込んで大規模なイベント駆動型アプリケーションを構築できるようになっています。このコンポーネントがシステムの中核を担っており、すべての注文とステータス更新をシステムが処理します。また、ビジネスルールに基づいて特定のエンドポイントへメッセージを転送することも可能です。 システムのコアモジュールは2つです。 位置の追跡 注文の発送 位置追跡サービス このサービスは、位置情報が中心的な役割を果たすすべてのタスクを管理するのに役立ちます。 ドライバーの位置をGPSで追跡 位置情報の検索 ジオフェンシング AWS IoT Core サービスを高速メッセージブローカーとして利用し、ドライバーアプリと顧客アプリの間でメッセージを安全に送受信できます。MQTTプロトコルをサポートしており、MQTTプロトコルはHTTPと比較して同じ量の情報を少ないデータ量で送信できます。このユースケースでは、ドライバーアプリが位置データをAWS IoT Coreに継続的に送信し、そのデータパケットをリアルタイムストリーミングデータ収集・処理・分析サービスの Amazon Kinesis に転送します。そこから位置追跡サービスにインデックス化されます。データは、 基本的な取り込み を使用して取り込まれます。基本的な取り込みは、AWS IoTルールに従ってデバイスデータを対象サービスに安全に送信でき、メッセージングコストが発生しません。 位置追跡サービスは、Redis 互換の高速・耐久性のインメモリデータベースである Amazon MemoryDB for Redis と、OpenSearchのクラスターをAWS上で簡単にデプロイ・運用・スケーリングできる Amazon OpenSearch Service を組み合わせたものです。前者は「半径或いは矩形内の全ドライバーを追跡する」ようなシンプルなクエリを、後者は「ポリゴン内の全ドライバーを追跡する」ような複雑なクエリをそれぞれサポートしています。 ドライバーアプリは、AWS IoT Coreを通じて Amazon Eventbridge とステータス更新を送受信しています。一方で、 Amazon API Gateway は、さまざまな規模でのAPIの作成、保守、保護に役立つとともに、Amazon MemoryDB for Redisおよび位置追跡サービスのOpenSearchクラスタから位置情報を問い合わせるためのAPIを提供しています。 ジオフェンシング ドライバーに注文が割り当てられると、注文管理システムがEventBridgeにメッセージを送信します。位置追跡サービスがそのメッセージを受信し、割り当てられたドライバーの位置を追跡し始めます。MemoryDB for Redisを利用した位置情報制御により、ドライバーが目的地の近くに来た時点でEventBridgeに通知が送信されます。その情報は顧客や関連会社に共有されます。 図3.ジオフェンシングアーキテクチャ その他の考慮事項 ドライバーを継続的に追跡すると、モバイルバッテリーが急速に消耗する可能性があります。ただし、ドライバーを頻繁に追跡しないと、ドライバーがどのルートをたどったのか、特定の瞬間にどこにいるのかを正確に知ることが難しくなります。また、割り当てエラーにつながる可能性もあります。たとえば、ドライバーが特定のピックアップポイントの近くにいて、ロケーションが更新されていないためにそのピックアップポイントから注文を受け取れない場合などです。 ドライバーの位置を常に追跡すると、モバイルバッテリーの消耗が速くなる可能性があります。 しかし、頻繁に追跡しないと、ドライバーが実際にどのルートを通ったのか、ある瞬間にどこにいたのかを正確に把握することが難しくなります。 また、注文の割り当てミスにもつながりかねません。例えば、ドライバーが特定の地点の近くにいるにも関わらず、位置情報が更新されていないために、その地点からを注文を受け取れないといったケースです。 このシステムは、ドライバーの位置を見失うことなく、バッテリーの消費を抑えるため、次の2つの方法を採用しています。 アクティブモードとパッシブモードで、ドライバーの位置を追跡するために使用する周波数を変更しています。これらのモードはさまざまな周波数をオンにしてGPS位置情報を取得し、データをクラウドに送信しています。 位置情報の取得の頻度とクラウドへの送信頻度を分けています。GPS位置情報の取得頻度は上げていますが、クラウドへの送信頻度は下げています。 これらのアプローチは設定を変更することができます。ユーザーがアプリをデバイス上で起動した際、最新の構成が取得されます。既にアプリを実行しているデバイスで設定を変更した場合、ほぼリアルタイムでその変更が適用されます。 この図は、システムのフローを示しています。このシステムを使うと、アプリケーションに他の設定をプッシュすることもできます(例:A/Bテストを行う)。 図4.グローバルモバイルアプリ設定 注文管理： ルールエンジンと注文配分 注文管理モジュールは、ドライバーや配送場所、利用可能な時間帯、業務ルールなど、さまざまな制約を考慮しつつ、注文を一元管理してドライバーへ配送依頼を行うのに役立ちます。このモジュールは以下の2つのコア要素から構成されています。 注文オーケストレーターと、地域ごとに業務ルールを適用するためのプロバイダールールエンジン 配送プロバイダー 注文オーケストレーターとプロバイダールールエンジン 企業がラストマイル配送を含むビジネスを立ち上げる際、自社配送車両を構築するか、APIを利用してサードパーティの配送車両(複数可)を利用するかを選択できます。このシステムにより、注文を国内外の配送車両に分散させ、地域ごとに配分比率を設定できます。例えば、エリアA1では1社の配送業者(外部プロバイダーPr1)のみを利用する場合がありますが、エリアA2では、外部プロバイダーPr2とPr3の間で注文を分散する場合があります。この配分は、 プロバイダールールエンジン を利用して実施されます。 このプロトタイプは、外部プロバイダーが使える様々な実装に対応できるよう、 Webhook プロバイダーと ポーリング プロバイダーの2つの通信技術をサポートしています。 プロバイダールールエンジン プロバイダルールエンジンの実装は、ほとんどの利用シーンではシンプルですが、システムは拡張性と設定のしやすさを考慮して設計されています。 本番運用移行時には、お客様は独自の業務ルールを実装し、特定の分野でどのプロバイダーを選択するかを決定する必要があります。 追加の業務ルールへの対応や、新しい優先順位の定義、新しいオペレータを追加するなど、システムをカスタマイズすることができます。 図5.プロバイダールールエンジンによって選択される複数のプロバイダー (内部プロバイダーと外部プロバイダー) の例 人口地域 都市や町の特定の地域には、配送業者に関する独自のルールが設定されている場合があります。 例えば、「A1地域」と指定されたエリア内では、配送にその地域専属の配送車両しか利用できないことになっています。 一方で、「A2地域」と呼ばれる別の地域では、2社の外部プロバイダー間で注文を配分できるというルールになっています。 人口地域のリストは、フルマネージド型のサーバーレス key-value NoSQLデータベースである Amazon DynamoDB に保存され、プロバイダールールエンジンの設定は、それぞれの人口地域を示す同じテーブルに保存されます。レストランや食料品店などの店舗を登録するたびに、その場所がどの人口地域に属するかを示すタグが付与されます。 図6.地域ごとに異なるルール（例：地域ごとに異なる外部プロバイダー） 配送システム 即時配送システム について詳しく見てみましょう。 図7.即時配送プロバイダー このモジュールは、次の3つのプロセスを管理しています。 まず、 注文処理用のリクエストハンドラー が注文を受け取り、各注文にステータスを割り当てます。 次に、 ジオクラスタリングマネージャー が注文をグループ化し、位置関係に基づいてクラスターを形成します。 最後に、 発送オーケストレーター は 発送エンジン を起動してこれらのクラスタを分析し、事業者の定める制約を考慮してドライバーへの注文割り当てを決定します。 ジオクラスタリング デフォルト設定では、 即時配送プロバイダー は他のプロバイダーと同じインターフェースを公開しています。 注文オーケストレーターサービス は、Amazon API Gatewayのエンドポイントに対してHTTPリクエストを送信することで、これらのプロバイダーを呼び出します。プロバイダーは Amazon Kinesis を使用して注文をバッチ処理することができ、これにより一括で処理することが可能です。グループのサイズはビジネスニーズに応じて設定できます。ただし、グループサイズを大きくすると、クラスターが大きくなり、最適なソリューションの生成に時間がかかる可能性がある点に注意が必要です。 グループからの注文を処理する前に、 ジオクラスタリングマネージャー は事前最適化の手順を実行します。このコンポーネントは、分散アプリケーションのビジュアルワークフローである AWS Step Functions を使用して実装され、ピックアップ地点が近い注文をクラスター化します。これにより、 発送エンジン が利用可能な運転手を探す複雑な検索を行う必要がなくなるため、発送が最適かつスピーディーに行われるようになります。 発送オーケストレーター は、AWS Step Functionsを使用して実装されています。 ジオクラスタリングマネージャー によって作成されたすべてのジオクラスターに対して、発送オーケストレーターが実行されます。 発送オーケストレーターは、クラスターごとに配車を最適化し(コストを最小限に抑える)配車エンジンを起動します。ドライバーが選ばれると、発送オーケストレーターはAWS IoT Coreを通じてメッセージでドライバーに通知します。 ドライバーは配車を承諾または拒否できます。ドライバーが配車を拒否した場合、その配車はKinesisを使用してバッチに戻されます。 配車の状況は 注文状況ストア で管理されています。 図8.ジオクラスタリングの例 (ソース：GraphHopper) 発送エンジンによる制約解決 発送エンジン は、即日配送や当日配送などの配送ドメインに関連する最適化問題を解決するために使用されるカスタムアプリケーションです。プロトタイプでは、オープンソースのAIベースの最適化ソルバー「 OptaPlanner 」を利用して、こうした配送ドメインをモデル化し実装しています。技術的な詳細についてさらに学びたい場合は、関連する ブログとドキュメント を参考にすることをお勧めします。 制約の解決には、様々なレベルの制約(ハード、ミディアム、ソフトなど)と、最大化するスコア関数や最小化するコスト関数を定義できます。 OptaPlanner ドキュメント には、問題領域を適切にモデル化するために必要な全ての情報が記載されています。ドライバーを注文に割り当てる方法はたくさんあります。ソフトウェアは割り当てごとにスコアを計算し、最もスコアの高い割り当てを提供する必要があります。OptaPlannerは、最適な結果を得るために必要な計算量を削減するスマートな手法です。最良の制約解決アプローチは、システムが競合する優先順位に対応できるかどうかを検証します。例えば、注文をドライバー間で均等に分配するか、評価の高いドライバーに優先して割り当てるかなどです。 即時配送ソリューションを最適化する際の推奨事項は以下の通りです。 注文はできる限り対応可能なドライバーに均等に割り振る。空いているドライバーがいる場合は1人に注文を集中させるのではなく、そのドライバーに新規注文を割り当てる。 ピックアップ場所(レストランなど)からの距離が近いドライバーを優先的に選択する。(お客様が評価の高いドライバーや近隣の注文をまとめるなど、異なる判断基準を設定できることに留意する。) 使用されている地理空間技術に関するクイックノート：GraphHopperの役割 このシステムは、オープンソースのGraphHopperをルーティングエンジンとして利用しています。 位置追跡サービスでは、Amazon MemoryDB for Redisによる簡易な地理空間クエリと、Amazon OpenSearch Serviceによる複雑なポリゴン地理空間クエリの両方をサポートしています。 GraphHopperを使ってピックアップ地点周辺の等時線を取得し、その結果を利用してAmazon OpenSearchでポリゴン内のドライバーを検索するクエリを実行することができます。 それらの結果をキャッシュしておき、後で地理空間クエリに再利用することも可能です。 図9.等時線：車で10分または20分以内にどこまで行けますか？(ソース：GraphHopper) シミュレータ プロトタイプを大規模にテストするため、シミュレータが含まれています。プロトタイプはイベント駆動型のバックエンドシステムとして設計されているので、シミュレータは関連するイベント(ドライバーの位置情報更新、注文、注文割り当て、承認/拒否メッセージなど)を生成します。 シミュレータは、内部プロバイダと外部プロバイダの間で注文が適切に配分されているか、システムが指定された負荷を処理できるかどうかを判断するのに役立ちます。 シミュレーターを使用することで、ドライバー、店舗や倉庫などの出発地、顧客などの目的地といった、様々な関係者の動きを模倣することができます。これらのエンティティは、 Amazon Elastic Container Service (Amazon ECS)のコンテナを利用してシミュレートされます。これによって組織は、コンテナ化されたアプリケーションを簡単にデプロイ、管理、スケーリングすることが可能となります。各コンテナは、それぞれの関係者の複数の行動をシミュレートできます。コンテナのサイズにもよりますが、1つのコンテナ当たり最大10個以上の行動をシミュレートできます。 ドライバーコンテナ は、ドライバーの動き(移動、注文の受け入れ/拒否、ピックアップ/配送)をシミュレートします。コンテナはクラウドからのメッセージを IoT トピック を通じて受信し、メッセージを受け取るとドライバーは割り当てを承認/拒否して配送をシミュレートし、ステータスの更新を別の IoT トピックに送信します。また、ドライバーは位置情報を定期的に送信することで、位置追跡モジュールによるデータの取り込みとインデックス作成をトリガーします。位置追跡モジュールは、ドライバーが乗車地点または降車地点に近づいたときにジオフェンシングイベントを送信する役割も果たしています。 オリジンコンテナ はIoTトピックから注文を受け取り、受け入れるか拒否するかを決定します。Web UIから拒否率を設定でき、自動的に拒否される注文の割合が決まります。 宛先コンテナ は、ランダムなオリジンを選択し、Web UIからシステムに注文を送信するロジックを提供します。このコンテナには、入力ファイルに基づいて既存のイベントを再生するオプションもあります。これにより、通常日のデータ分布(低負荷、中負荷、高負荷のピーク)を使用して、システムの反応を確認しながら、特定の負荷テストシナリオをシミュレートできます。イベントは、受注の時間間隔に基づいて、それらが表示される順序で再生されます。 図11.シンプルなシミュレーターアーキテクチャ 図12.シミュレーター UI 図13.シミュレータダッシュボード 負荷能力 プロトタイプは、5万人のドライバーの位置をリアルタイムで追跡し、5分間に5千件の配送注文を処理するようテストされています。これは1日当たり数十万件の注文量に相当します。システムは水平スケール可能で、この注文量を更に上回る規模にも対応できるよう設計されています。 個々のサービスのスケーリング 次のようなサーバーレスコンポーネントがあります。 AWS IoT Core AWS Lambda：サーバーやクラスターについて考えることなくコードを実行できます。 Amazon EventBridge AWS Step Functions：分散アプリケーションの視覚的なワークフローを提供します。 Amazon Kinesis Data Streams ：あらゆる規模のデータストリームを簡単にキャプチャ、処理、保存できるサーバーレスのストリーミングデータサービスです。 需要に応じて自動的にスケーリングします(AWS アカウントの上限を超えないよう注意が必要です)。 Amazon MemoryDB for Redis、Amazon OpenSearch、Amazon ECS でスケーリングする場合は、あらかじめ計画を立てる必要があります。これらのサービスは、水平スケールと垂直スケールの両方が可能です。 顧客のフロントエンドとバックエンドとの統合 Amazon EventBridgeに実装されている グローバルイベントハブ を利用することで、顧客システムやサードパーティシステムとの統合が容易になります。外部システムとの疎結合した連携が可能になるのです。 具体的には、イベントをグローバルイベントハブに公開し、イベント発生時の応答や更新状況をイベントハブを通じて確認できるようにします。このイベント駆動型アーキテクチャにより疎結合なアーキテクチャを実現できます。 注文発送サービスと位置追跡サービスはグローバルイベントハブを監視し、イベントをグローバルイベントハブに公開します。 例えば 注文発送サービスは、注文割り当ての詳細をグローバルイベントハブに公開し、ドライバーや位置サービスなどの関係者や機能コンポーネントに伝達しています。 位置追跡サービスの位置特定機能は、位置情報をグローバルイベントハブに公開しています。 また、注文発送サービスは、位置追跡サービスと直接連携して、指定区域内のドライバーなどのデータをリアルタイムで取得しています。これは注文発送に要求される速報性を確保するためです。 ドライバーアプリおよび顧客アプリにおけるパブリックエンドポイント ドライバーアプリは、MQTT プロトコルを使って AWS IoT Core 経由でクラウドと連携を行います。 顧客アプリは、HTTP プロトコルを使って AWS API Gateway で経由でクラウドと連携を行います。 図14.イベント伝播による統合 結論 即時配送のラストマイル配送ソリューションは、お客様の不要な労力を減らし、データ主導のイノベーションに注力できるよう支援します。システムの大部分はサーバーレスですが、その他の部分はマネージドサービスで構成されているので、メンテナンスと運用がしやすくなっています。ほとんどの部分が自動的にスケールするため、運用コストが比較的低く抑えられます。このシステムは、設定可能なルールエンジンと最適化エンジンを通じて革新を促進することができます。また、多くの配送業者がサードパーティの車両を利用している実状も考慮されています。 さらに、システムは、ラストマイル配送の課題を解決するために、さまざまな AWS サービスを効果的に使用する方法を示しています。これらのサービスには、AWS IoT Core、Amazon Kinesis、AWS Lambda、AWS Step Functions、Amazon API Gateway、Amazon MemoryDB for Redis、Amazon OpenSearch Service、Amazon ECS などが含まれます。 次回のブログ記事では、当日配送用の AWS ベースの ラストマイル配送ソリューション について詳しく見ていきます。 免責事項 このソフトウェアは Amazon Software License (ASL) に基づいて共有されているため、AWSはいかなる責任も負いません。システム設計では AWS Well-Architected の原則 に沿って、パフォーマンス、信頼性、コスト効率、持続可能性を考慮しています。実運用を開始する前に、十分な注意とテストを推奨します。 翻訳はソリューションアーキテクト 駒野 達也 が担当しました。原文は こちら です。  

はじめに コネクテッドモビリティソリューションが自動車業界の変化を促進しています。遠隔コマンド、センサー、カメラ、人工知能、5G モバイルネットワークにより、自動車はますますスマート化し、そしてコネクテッド化しています。コネクテッドモビリティソリューションが大きな顧客価値をもたらす一方で、セキュリティ、安全性、プライバシーの面で、適切な管理を要する新たなリスクをもたらします。 自動車メーカーは、サイバーセキュリティをコアビジネスに不可欠な要素として考慮し、車両プラットフォームと関連するデジタルモビリティサービスを最初から安全に設計する必要があります。自動車の相手先ブランド製造&nbsp;(OEM)&nbsp;業者やサプライヤーが、コネクテッドビークルのイノベーションとリスクのバランスを取れるように、AWS は AWS IoT でコネクテッドビークルプラットフォームを構築するための リファレンスアーキテクチャ を発表しました。このガイダンスは、AWS 上のコネクテッドモビリティソリューションのための以下の 10 個のセキュリティゴールデンルールに基づいた、多層的なアプローチを推奨しています。 1. 規制および社内コンプライアンス要件に対応するための共通フレームワークによるセキュリティリスク評価を実施する。 AWS は、コネクテッドカーの IT 技術を活用する前に、リスク、ギャップ、脆弱性を十分に理解し、主体的に管理できるように、サイバーセキュリティのリスク評価を実施することを推奨しています。自動車規制要件&nbsp;( UN-R155 および UN-R156 など)&nbsp;と社内要件を満たすために必要な管理策を決定します。クラウドリソースの最新の脅威モデルと、関連する車載コンポーネントの脅威分析とリスクアセスメント&nbsp;( TARA )&nbsp;を作成し、維持します。ISO 21434、NIST 800-53、ISO 27001 などの規格が有用なガイダンスを提供しています。 自動車 OEM は、消費者がアフターマーケット機器&nbsp;(保険用ドングルなど)&nbsp;や個人用機器&nbsp;(携帯電話など)&nbsp;を車内に持ち込み、メーカーが提供するインターフェースを介して車両システムに接続するリスクを考慮すべきです。 無線接続された ECU と低レベルの車両制御システム、特にブレーキ、ステアリング、推進力、パワーマネジメントなどの 安全上重要な機能を制御するシステム 間の接続を制限するためには、車載ネットワークのセグメンテーションと分離技術を使用する必要があります。 データの送信とコマンドの受信は、常に信頼できるエンドポイント&nbsp;(MQTT over TLS など)&nbsp;への接続を車両に確立させ、着信接続の試みを許可しないようにします。 リモートで車両のロックを解除するなど、クラウドから車両にコマンドが送信されるクローズドループオペレーションでは、セキュリティコントロールとテストをさらに厳密に行う必要があります。 参考リソース： AWS コンプライアンスプログラムとオファリング。 Amazon Virtual Private Cloud&nbsp;(Amazon VPC)&nbsp; は、ユーザーが定義した論理的に分離された仮想ネットワーク内に AWS リソースを起動できるサービスです。 AWS Network Firewall は、すべての Amazon VPC に必要不可欠なネットワーク保護を簡単に導入できるマネージドサービスです。 AWS Control Tower は、アイデンティティ、連携アクセス、アカウント構造に関するベストプラクティスのブループリントを使用して、新しいランディングゾーンのセットアップを自動化します。 AWS セキュリティブログの 脅威モデリングのアプローチ方法 。 2. 車両に搭載されているすべてのハードウェアとソフトウェアのアセットインベントリを管理する。 車両に搭載されているすべてのハードウェアとソフトウェアのアセットインベントリを作成し、維持します。このアセットインベントリは、メーカーやモデル、ECU ID または ESN にマッピングされた VIN、ハードウェアとソフトウェアの構成など、車両の主な特徴とともに、コネクテッドビークルのフリートの記録のためのシステムおよび単一の真のソースとして機能します。 アセットを機能&nbsp;(セーフティクリティカル、車両制御システム、車両ゲートウェイなど)&nbsp;、ソフトウエア更新が適用可能かどうか&nbsp;(パッチ適用可能か不可能か)&nbsp;、ネットワーク設計&nbsp;(オープンネットワーク用に設計されているか、クローズドネットワーク用に設計されているか)&nbsp;に基づいて分類し、その重要性と最新のセキュリティ制御をサポートする能力を認識します。必要に応じて、リスクを軽減するための代替策を適用します。 これらのシステムがどのように相互接続されているか、その関係&nbsp;(アセットの階層構造)&nbsp;を示す最新の車載ネットワークアーキテクチャを作成および維持し、ネットワークアーキテクチャのセキュリティレビューを実施します。 NHSTA の「現代自動車の安全のためのサイバーセキュリティのベストプラクティス&nbsp;( Cybersecurity Best Practices for the Safety of Modern Vehicles )&nbsp;」、特に「車両上のハードウェア及びソフトウェアのアセットのインベントリとその管理」に関するセクション 4.2.6 のガイダンスに従います。SPDX や CycloneDX などの業界標準を使用して、ソフトウェアサプライチェーンにおけるコードの可視性、透明性、セキュリティ、完全性を向上させるために、ソフトウェア部品表&nbsp;(SBOM)&nbsp;を維持します。 参考リソース： AWS IoT Core に接続されたデバイスのための AWS IoT Device Management クラウドインスタンスとオンプレミスのコンピュータのための AWS Systems Manager インベントリ 。 ソフトウェアパッケージとそのバージョンのインベントリの管理のための AWS IoT Device Management Software Package Catalog 。 NHSTA の現代の自動車の安全のためのサイバーセキュリティベストプラクティス 3. 各電子制御ユニット&nbsp;(ECU)&nbsp;に固有の ID と認証情報を提供し、認証とアクセス制御のメカニズムを適用する。車両とクラウドサービス間の通信に業界標準プロトコルを使用する。 各 ECU および最新の IoT デバイスに一意の ID を割り当て、ECU/デバイスがクラウドサービスに接続する時は、X.509 証明書とそれに対応する秘密鍵、セキュリティトークン、またはその他のクレデンシャルなどを使用して認証しなければならないようにします。 OCSP またはクレデンシャルの生成、配布、検証、ローテーション、および失効（ X.509 証明書の CRL の使用など）を促進するメカニズムを構築します。 デバイスで利用可能な場合は、Trusted Platform Modules&nbsp;(TPM)&nbsp;などのハードウェアで 保護されたモジュールを使用して、ルートオブトラストを確立します。秘密鍵などの秘密情報は、HSM のような特殊な保護モジュールに格納します。 制約のあるデバイス用に設計された軽量メッセージングプロトコルである MQTT のような業界標準プロトコルを使用します。 可能であれば、TLS バージョン 1.2 または 1.3 を使用して転送中の暗号化を実施し、セキュリティを強化します。 参考リソース： AWS IoT でのセキュリティとアイデンティティ 。 Amazon Cognito &nbsp;は、Web アプリやモバイルアプリの認証、認可、ユーザー管理を提供するサービスです。 AWS Identity and Access Management&nbsp;(IAM )&nbsp;は、AWS サービスとリソースへのアクセスを安全に管理できるサービスです。 AWS IoT Core における証明書要件の変更への対応方法に関するガイダンス 。 AWS プライベート CA ：AWS プライベート CA は、ルート CA や下位 CA を含むプライベートな認証局&nbsp;(CA)&nbsp;階層の作成を可能にします。 4. コネクテッドビークルの脆弱性管理の優先順位付けと実施、およびソフトウェアとファームウェアの更新のための適切な更新メカニズムを定義する。 ソフトウェアの普及と複雑化に伴い、不具合の数も増加し、その一部は悪用可能な脆弱性となり得ます。脆弱性に対処する際には、重要度&nbsp;( CVSS スコア など)&nbsp;に応じて優先順位をつけ、最も重要なアセットからパッチを適用します。 車載機器にソフトウェアやファームウェアをプッシュし、セキュリティ脆弱性にパッチを当て、機器の機能を向上させる仕組みを構築します。 ソフトウェアの実行を開始する前に、そのソフトウェアの真正性と完全性を検証し、それが信頼できるソース&nbsp;(ベンダーの署名入り)&nbsp;から提供されたものであり、安全な方法で入手されたものであることを確認します。 ソフトウェアのアップデートは、車両が安全な状態になり、さらにユーザーによって確認された場合にのみ実行できるようにします。 バージョンとパッチの状態を含め、接続されたデバイスフリート全体に展開されたソフトウェアのインベントリを維持します。 コネクテッドビークルのフリート全体のデプロイ状況を監視し、デプロイの失敗や停滞を調査するとともに、インフラストラクチャがフリートに対してセキュリティ更新をデプロイできない場合は関係者に通知します。 車両のソフトウェア更新に関する UNR 156 のような規制や、ソフトウェア更新エンジニアリングに関する ISO 24089 のような規格の範囲と要件を認識します。 参考リソース： Amazon FreeRTOS の OTA アップデート 。 AWS IoT Greengrass Core ソフトウェアの OTA アップデート 。 AWS IoT ジョブ は、AWS IoT に接続された 1 つ以上のデバイスに送信して実行するリモート操作のセットを定義します。 AWS Key Management Service&nbsp;(KMS )&nbsp;は、クラウド上の暗号操作に使用される鍵を簡単に作成し、制御することができます。AWS KMS に格納された非対称秘密鍵を使用してソフトウェアパッケージに署名し、対応する公開鍵を使用して ECU で署名を検証できます。 AWS IoT Device Management Software Package Catalog &nbsp;は、ソフトウェアパッケージとそのバージョンのインベントリを管理し、AWS IoTジョブと統合します。 5.&nbsp;保管時のデータを暗号化することにより、車両内およびクラウド内のデータを保護し、安全なデータ共有、ガバナンス、および主権のメカニズムを構築する。 暗号化と適切なアクセス制御が実装されている場合は、車両とクラウドの保管時のデータを暗号化し、不正アクセスのリスクを低減します。 前述のリスク分析に基づいて、コネクテッドビークル・システム全体で収集されたデータを特定し、分類します。 潜在的な不正データ改変を特定するために、静止状態の本番データを監視し、完全性チェックを適用します。 顧客のプライバシーと透明性への期待と、コネクテッドビークルを製造、配布、運用する法域における対応する法的要件を考慮します。 参考リソース： AWS データプライバシー 。 AWS Well-Architected Framework のセキュリティの柱における 保管中のデータの保護 。 センシティブなデータを発見し、保護するための&nbsp; Amazon Macie 。 AWS コンプライアンスプログラムとオファリング 。 6.&nbsp;車内で安全でないプロトコルを使用する場合は、ゲートウェイ ECU をクラウドへの安全なブリッジとして使用できます。 トランスポート層のセキュリティに加えて、機密データをバックエンドシステムに送信する前にクライアント側で暗号化することも検討します。 最新のインターネットネイティブ暗号ネットワークプロトコルを選択することで、データ転送、監視、管理、プロビジョニング、デプロイに使用するインバウンドおよびアウトバウンドのネットワーク通信チャネルの機密性と完全性を保護します。 可能であれば、特定の環境内で実装されるプロトコルの数を制限し、使用されていないデフォルトのネットワークサービスを無効にします。 必要な時に車両がオンラインでない場合&nbsp;(バッテリーを節約するためなど)&nbsp;を考慮して、信頼できるエンドポイントへの接続を確立するために車両をトリガーする別の方法を実装することを検討します。 参考リソース： デバイスを AWS IoT に安全かつ迅速に接続するための AWS IoT SDK 。 組み込みアプリケーションのネットワーキングとセキュリティのための FreeRTOS ライブラリ 。 AWS Encryption SDK は、クライアントサイドの暗号化ライブラリで、データをクラウドに送信する前に AWS KMS のキーを使用してクライアントサイドで車両データを暗号化するために使用できます。 AWS KMS を使用することで、クラウド上で暗号処理に使用する鍵を簡単に作成、管理することができる。 7. すべてのコネクティッド・リソース&nbsp;(特にインターネットに接続されたリソース)&nbsp;を強固にし、クラウドサービスへのセキュアな接続と車両へのリモートアクセスを確立する。 ECU や IoT デバイスなどのインターネットに接続されたネットワークリソースは、 Auto ISAC のセキュア設計原則 などのベストプラクティスに従って堅牢化する必要があります。 車両 ECU のネットワークサービスの利用は、必要不可欠な機能のみに制限します。 WS サービスへのアクセスには、長期的な認証情報の代わりにデバイスの証明書と一時的な認証情報を使用し、専用の暗号エレメントやセキュアフラッシュなどのメカニズムを使用して、保管時のデバイスの認証情報を保護します。デバイスは、ハードウェアのルートオブトラストとセキュアブートをサポートする必要があります。 プライベートセルラーネットワークと AWS IoT Core VPC エンドポイントを使用してクラウドへのプライベート接続を確立することにより、インターネットからネットワークトラフィックを分離します。 参考リソース： NIST Guide to General Server Security 。 AWS IoT Greengrass ハードウェアセキュリティ 。 Auto ISAC セキュリティ開発ライフサイクル 。 AWS サービスへのプライベート接続のための AWS PrivateLink 。 AWS IoT Core 認証情報プロバイダの VPC エンドポイント 。 8. セキュリティ監査と監視の仕組みを導入し、コネクテッドカーとクラウド全体でセキュリ ティアラートを一元管理する。 個々の車両やフリートが影響を受ける可能性のある、車両やクラウドリソースの脅威や脆弱性を検出して対応する仕組みを導入します。車載ネットワークとコネクテッド・サービスは、車両コンピューティング・リソースへの不正アクセスの検出をサポートするデータを生成します。 セキュリティイベント、脅威、脆弱性について車両を監視することをメーカーに義務付ける UNR155 などの規制に注意します。 ネットワークトラフィックのベースラインを作成し、異常とベースラインへの準拠を監視するために、コネクテッド・ビークル用の監視ソリューションを導入します。 ネットワークログ、アクセス制御の権限、資産構成の定期的なレビューを実施します。 セキュリティログを収集し、専用ツール&nbsp;(例えば、車両セキュリティ・オペレーション・センター&nbsp;(VSOC)&nbsp;内のようなセキュリティ情報・イベント管理&nbsp;(SIEM)&nbsp;クラスのソリューション)&nbsp;を使用してリアルタイムで分析する。 参考リソース： AWS IoT Device Defender は、コネクテッドカーの IoT デバイスのフリートを監視および監査します。 AWS Config ：AWS リソースの構成を評価、監査、評価します。 Amazon GuardDuty ：AWS アカウントとワークロードを保護するために、悪意のあるアクティビティと不正な動作を継続的に監視します。 AWS Security Hub ：AWS のセキュリティチェックを自動化し、セキュリティアラートを一元化します。 AWS リソースを監視するための Amazon CloudWatch と AWS CloudTrail 。 9. インシデント対応プレイブックを作成し、セキュリティ対応の成熟度に合わせて自動化を構築して、イベントを封じ込め、既知の良好な状態に戻す。 セキュリティインシデント対応計画を維持し、定期的に演習して、監視機能をテストします。 セキュリティログを収集し、自動化ツールを使用してリアルタイムで分析します。想定外の発見に関するプレイブックを作成します。 役割と責任を明確に理解したインシデント対応プレイブックを作成します。インシデント対応プレイブックには、準備手順、識別/トリアージ、封じ込め、対応、復旧、教訓も含めます。 インシデント対応手順を、ゲームデイや卓上演習で定期的にテストします。 手順がより安定するにつれて、その実行を自動化するが、人間による対話は維持します。 参考リソース： AWS セキュリティインシデント対応ガイド 。 AWS Systems Manager は、運用に関する洞察を収集し、日常的な管理タスクを実行するための、一元化された一貫性のある方法を提供します。 AWS Step Functions ：AWS Step Functions を使用すると、車両攻撃に関するセキュリティインシデント対応のために、手動承認ステップを含む自動化されたワークフローを作成できます。 AWS Security Hub &nbsp;は、AWS サービス、パートナー、またはその他のソースから取り込まれた車両固有の調査結果に対応し、格納します。 AWS での自動化されたセキュリティ対応 。 10. NIST の出版物や ISO/SAE 21434 に概説されているような、安全なソフトウェア開発のベストプラクティスに従う。 “シフトレフト“によって、システム開発の早い段階でセキュリティ対策に取り組み、セキュアなコードを実装します。パイプラインにコードをデプロイしてテストする時に、コードレビューを実施し、静的コード解析、動的アプリケーションセキュリティテストを使用します。製品のライフサイクルのできるだけ早い段階でサイバーセキュリティの管理と仕組みを適用し、開発・リリースサイクルを通じて、製品の寿命が尽きるまで継続的にテストを自動化します。 サイバーセキュリティはダイナミックで継続的に進化する性質があるため、自動車業界のメンバーは、 SAE International 、 ISO/IEC 33601 に基づく ASPICE フレームワーク、その他の ISO 規格 、 Auto-ISAC 、 NHTSA 、 Cybersecurity Infrastructure Security Agency&nbsp;(CISA) 、 NIST 、業界団体、その他公認の標準設定機関に基づく、またはそれらによって発行された、利用可能なサイバーセキュリティガイダンス、ベストプラクティス、設計原則、標準を常に把握しておくことが重要です。 Auto-ISAC&nbsp;への参加など、効果的な情報共有を通じて、教訓&nbsp;(脆弱性の共有など)&nbsp;を業界全体で迅速に採用する方法を制度化します。 参考リソース： Well-Architected CI/CD アプローチの選択 。 AWS Well-Architected Framework アプリケーションのセキュリティ 。 Amazon CodeGuru ：Amazon CodeGuru Security は、機械学習を使ってセキュリティポリシー違反や脆弱性を検出する静的アプリケーションセキュリティツールです。 AWS の CI/CD サービスを理解するために、この Complete CI/CD ブログポスト をチェックしてください。 AWS Well-Architected Framework の&nbsp; IoT Lens ：アーキテクチャのベストプラクティスに沿った IoT ワークロードを設計、デプロイ、アーキテクトするためのレンズ。 まとめ このブログポストでは、AWS の多層的なセキュリティアプローチと包括的なセキュリティサービスや機能を使用して、コネクテッドモビリティソリューションを安全に保つためのベストプラクティスのいくつかをレビューしました。AWS のコネクテッドビークル・セキュリティは、オープンスタンダードと認知度の高いサイバーセキュリティ・フレームワークに基づいて構築されています。自動車企業は、AWS のセキュリティサービスや、 AWS&nbsp;セキュリティコンピテンシーパートナー が提供する自動車ワークロードのためのセキュリティに特化したパートナーソリューションのネットワークから柔軟に選択できます。 詳細については、 AWS の取り組み: オートモーティブ&nbsp; をご覧ください。 この記事は&nbsp;Ryan Dsouza、Maitreya Ranganath、Omar Zoma&nbsp;によって書かれた&nbsp; Ten security golden rules for connected mobility solutions の日本語訳です。この記事は プロフェッショナルサービス本部 IoT コンサルタントの宮本 篤が翻訳しました。 <!-- '"` -->

最小権限の原則に従い、ユーザーはアプリケーション、ペルソナ、グループ、組織単位（OU）に基づいて、 Amazon Simple Storage Service（Amazon S3） のデータへのきめ細やかなアクセスを定義します。この方法は、不正アクセスのリスクを軽減し、セキュリティ侵害が発生した場合の損害を抑制するのに役立ちます。従業員が自分のタスクに不可欠なリソースへのアクセスのみを持つため、不注意による誤ったデータの取り扱いミスを抑制します。さらに、お客様は精密なユーザーアクティビティの追跡と分析を可能にする包括的な監査機能を望んでいます。この機能は、規制要件と内部ガバナンス基準への遵守に不可欠であり、異常な振る舞いやセキュリティインシデントの迅速な検出を可能にします。 先日、Amazon Web Services（AWS）は、新機能として Amazon S3 Access Grants を発表しました。これは、 Microsoft Entra （以前の Microsoft Azure AD）や Okta などのディレクトリ内のアイデンティティを Amazon S3 のデータセットにマッピングすることをユーザーに可能にします。これにより、ユーザーは企業アイデンティティに基づいてエンドユーザーに適切な Amazon S3 アクセスを自動的に付与することで、大規模にデータ権限を管理することができます。S3 Access Grants は、 AWS Identity and Access Management（IAM） と共に使用することも可能であり、Amazon S3 内の既存のリソースレベルのコントロール（例えば S3 バケットポリシー）を補完する簡単でスケーラブルな方法として利用できます。さらに、S3 Access Grants は、Amazon S3 データへのアクセスに使用されたエンドユーザーのアイデンティティとアプリケーションを AWS CloudTrail に記録します。これは、S3 バケット内のすべてのデータアクセスの詳細な監査履歴を提供するのに役立ちます。 この投稿では、S3 Access Grants とその構成についての概要を提供し、特定のアクセスパターンに基づいて S3 Access Grants の使用方法を例示します。これには、 IAM プリンシパルとの S3 Access Grants の使用方法と、企業ディレクトリからのユーザーやグループとの使用方法が含まれます。 大規模な詳細アクセスを実現 現在、ユーザーは Amazon S3 のデータへの詳細なアクセスを達成するために、アクセスパターンの規模と複雑さに応じてさまざまなアプローチを持っています。 Amazon S3 のデータへの詳細なアクセスを達成する方法は、アクセスパターンの規模と複雑さに基づいて変わります。小規模なデータセットの場合、ユーザーは通常、ポリシーサイズの制限内に収まる限り、 IAM アクセスポリシー と バケットポリシー を使用します。データセットとユースケースの数が増えるにつれて、AWS アカウント毎のリージョンあたり数千のアクセスポイントを許可する Amazon S3 アクセスポイント を使用するという代替オプションがあります。ただし、このアプローチには、データセットに適したアクセスポイントを見つけるための追加ロジックが必要であり、静的なアクセスパターンに適しています。データ権限の複雑で洗練された評価が必要な場合、第三のアプローチが検討され、ここでは「 IAM セッションブローカー 」パターンを採用し、ユーザーはアクセス決定のロジックを処理し、動的に短期の IAM セッション資格情報を生成します。この方法はスケーラビリティをサポートしていますが、ユーザー自身でアクセスパターンロジックを設計および実装する必要があります。 これらのアプローチではすべて、Amazon S3 データアクセスをユーザーやグループにマッピングし、アクセスを監査することに、ある程度のオーバーヘッドがあります。S3 Access Grants と IAM Identity Center の新しい Trusted Identity Propagation は、ユーザーやグループへの Amazon S3 の詳細なアクセスを管理するというこの複雑で時間のかかる作業をユーザーから取り除きます。 S3 Access Grants は、バケット、プレフィックス、またはオブジェクトレベルでの読み取り専用、書き込み専用、または読み書きアクセスなどの単純な権限を定義することをユーザーに可能にします。その後、ユーザーは IAM プリンシパルを S3 Access Grants に割り当てることができます。または、 AWS IAM Identity Center との統合を使用して、企業ディレクトリからユーザーやグループにアクセスを割り当てることができます。IAM Identity Center との統合を使用する場合、ユーザーはディレクトリにユーザーを認証する企業アプリケーションを持ち込むことができ、IAM Identity Center API との統合に数行のコードを追加することで、それらのアプリケーションが認証された各ユーザーの代理として Amazon S3 上のデータにアクセスできるようになります。さらに、IAM Identity Center 統合を使用すると、ユーザーのアイデンティティが Amazon S3 データへのすべてのアクセスとともに記録されるため、誰が何にアクセスしたかの監査が可能になります。 Amazon S3 Access Grants は、あなたのユースケースに適していますか？ Amazon S3 での多くの権限ユースケースは、IAM プリンシパルと S3 バケットの両方に対して IAM ポリシーを使用して、簡単かつ効果的に実装することができます。小規模なユースケースには、このアプローチをお勧めします。S3 Access Grants は、次のような状況で S3 でのデータ権限の管理を簡素化します： Amazon S3 に大量のデータセットがあり、IAM や S3 バケットポリシーの文字数制限が懸念される場合。 権限スキームがユーザー/グループからデータセットへのパターンにより自然に適合し、中間の IAM ロールを使用してアクセスを得るよりも、ディレクトリグループに直接権限を割り当てる方が簡単な場合。 より複雑な多対多のユーザーからデータへのマッピング、例えば個々のユーザーが複数のグループのメンバーであり、そのための Amazon S3 内のデータセットの和集合へのアクセスが必要なケース。 S3 Access Grants の仕組みを詳しく説明する前に、S3 Access Grants のさまざまな構成要素を理解しましょう。 Amazon S3 Access Grants – コンセプト S3 Access Grants は、その簡略化されたアクセススキームのためにいくつかのコンセプトを導入します。まず、それらを定義していきます。 S3 Access Grants インスタンス: S3 Access Grants インスタンスは、Amazon S3 データへのアクセスレベルが誰にどのように付与されているかを定義する個々の権限の論理的なグループです。1 つの AWS アカウント内の 1 つの AWS リージョンごとに 1 つのインスタンスを設定できます。このアカウントおよびリージョンレベルの S3 Access Grants インスタンスは、同じアカウントおよび AWS リージョンのすべてのバケットへのアクセスを制御できます。外部ディレクトリのユーザーやグループにアクセスを付与するために S3 Access Grants を使用する場合は、S3 Access Grants インスタンスを IAM Identity Center インスタンスに関連付ける必要があります。他の AWS アカウントの IAM プリンシパルにアクセスを付与する場合は、これらのクロスアカウント API 呼び出しを許可するために、S3 Access Grants インスタンスにリソースベースのポリシーを使用します。 ロケーション: S3 Access Grants は、特定の Amazon S3 プレフィックスへのアクセスをスコープとした IAM 資格情報を発行することで機能します。S3 Access Grants ロケーションは、これらの一時セッションが作成される IAM ロールに関連付けられています。最も一般的な設定は、すべての S3 Access Grants に対して s3:// で単一のロケーションを使用することで、AWS リージョンおよびアカウント内のすべての S3 バケットへのアクセスをカバーできます。S3 Access Grants はこれを「デフォルト」ロケーションと呼びます。より高度なユースケースで複数の異なる IAM ロールの使用が必要な場合、お客様はそれを行うために複数の S3 Access Grants ロケーションを作成できます。 権限: S3 Access Grants の個々の権限は、特定のエンティティ（IAM プリンシパル、ディレクトリユーザー、またはディレクトリグループ）に対して、S3 バケット、プレフィックス、またはオブジェクトへのアクセスを許可します。たとえば、特定のディレクトリグループ 01234567-89ab-cdef-0123-456789abcdef に s3://DOC-EXAMPLE-BUCKET/projects/foo/* への READ アクセスを許可する権限を持っている場合、そのグループのユーザーはそのバケット内の projects/foo/ の下のすべてに読み取りアクセスを許可されます。 S3 Access Grants の一時的な資格情報: アプリケーションは、新しい Amazon S3 API、 GetDataAccess を呼び出して、単一のオブジェクト、プレフィックス、またはバケットへのアクセス権限をリクエストし、READ、WRITE、または READWRITE の権限レベルを要求します。S3 Access Grants 機能はリクエストを設定された権限に対して評価します。一致する権限があれば、その権限のロケーションに関連付けられた IAM ロールを引き継ぎ、権限を IAM セッションの権限に正確にスコープし、Amazon S3 プレフィックスまでの権限を与えます。アクセス資格情報の有効期限はデフォルトで 1 時間ですが、15 分から 36 時間まで任意の値に設定することができます。 これらの構成を例を挙げて理解しましょう。最初のセクションではシナリオを説明し、次にそのシナリオに対して S3 Access Grants を実装します。 Amazon S3 Access Grants – セットアップ 私たちが説明する例において、S3 Access Grants がどのようにマップされるかを理解するために、 developerRole および analystRole 、2 つの IAM ロールを定義します。重要なのは、ロールは実際の人々ではなく、人々やサービスが引き受ける役割であるということです。後ほど、IAM Identity Center を使用して、アクセスが実際のユーザーやグループに基づいていることを示します。 アクセスパターンのシナリオ 以下の図では、 s3:// でスコープが定義されたデフォルトの Amazon S3 のロケーションと、アカウント内で Amazon S3 のアクションを実行する権限を持つ IAM ロール s3ag-location-role が定義されています。S3 Access Grants は、アクセスのリクエストに対してこの IAM ロールを使用して一時的な資格情報を作成します。 次に、以下のアクセスを定義します。IAM ロール developerRole は、 developer/ プレフィックスに対して READ および WRITE のアクセス権を持ちます。別の IAM ロール analystRole は、 analysis/ プレフィックスに対して READ アクセスのみが許可されます。左側の S3 Access Grants（青色で表示）は、 DOC-BUCKET-EXAMPLE バケット内のプレフィックス developer/ へのアクセスを developerRole に与えるために定義されています。右側の S3 Access Grants（緑色で表示）は、 DOC-BUCKET-EXAMPLE バケット内のプレフィックス analysis/ へのアクセスを analystRole に与えるために定義されています。これは 図 1 で示されています。 図 1: S3 Access Grants の概要 図 1 に示されているように、Bob がデータを読む時、 developerRole IAM ロールを使用して S3 Access Grants GetDataAccess API を呼び出します。 s3://DOC-BUCKET-EXAMPLE/developer/ で始まる任意の Amazon S3 プレフィックスまたはオブジェクトへの READ 権限を要求する場合、 GetDataAccess は s3://DOC-BUCKET-EXAMPLE/developer/* への権限を持つ S3 Access Grants の一時的な資格情報を返します。同様に、WRITE アクセスを要求することもできます。なぜなら、権限はそれも許可しているからです。 同様に、Alice は analystRole IAM ロールを使用して GetDataAccess を呼び出し、Amazon S3 の s3://DOC-BUCKET-EXAMPLE/analysis/ で始まるものへの READ アクセスを要求できます。そして、S3 Access Grants は適切にスコープされた IAM セッション資格情報を返します。しかし、WRITE 権限を要求する場合、データへの書き込み権限を与える権限がないため、アクセス拒否エラーが発生します。さらに、Alice が s3://DOC-BUCKET-EXAMPLE/developer/ の下のデータへのアクセスを任意のレベルで要求する場合、または Bob が s3://DOC-BUCKET-EXAMPLE/analysis/ の下のデータへのアクセスを任意のレベルで要求する場合も、アクセス拒否となります。 S3 Access Grants インスタンスあたり最大 10 万の権限と 1,000 のロケーションを持つことができます。個々のユーザーとプレフィックスのアクセス許可の組み合わせが追加または削除されるたびに、長く複雑な S3 バケットポリシーを編集する代わりに、各関係に対して個別の権限を追加および削除することができます。 アクセスパターンのシナリオのセットアップ S3 Access Grants についての基本的な概念を理解したところで、前のセクションで示した権限を作成する方法を見ていきましょう。この例では、IAM ロール developerRole と analystRole 、および S3 バケット DOC-EXAMPLE-BUCKET が既に存在しているとします。 1. S3 Access Grants インスタンスの作成: S3 Access Grants インスタンスを作成するには、以下のコマンドを実行します。 aws s3control create-access-grants-instance --account-id 123456789012 2. S3 Access Grants ロケーションの作成: 次のステップは、S3 Access Grants ロケーションを作成することです。これを行うには、S3 Access Grants サービスに信頼を持ち、Amazon S3 リソースへのアクセスを許可する IAM ロールが必要です。この IAM ロールを s3ag-location-role と呼びます。 i. S3 Access Grants IAM ロール : S3 Access Grants が資格情報を生成できるようにするためには、IAM ロールを作成し、それをロケーションに関連付ける必要があります。IAM ロール信頼ポリシーは、サービスプリンシパル access-grants.s3.amazonaws.com が以下のアクションを実行できるようにする必要があります： – sts:AssumeRole – 要求者のアイデンティティで IAM 資格情報を生成するために必要 – sts:SetSourceIdentity – IAM ロールを引き受ける権限を使用する場合に必要 – sts:SetContext – DIRECTORY_USER/DIRECTORY_GROUP の権限を使用する場合に必要 trust-policy.json というファイルを作成し、以下の内容をファイルにコピー＆ペーストしてください： //trust-policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "access-grants.s3.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity", "sts:SetContext" ] } ] } その後、以下のコマンドを実行してください： aws iam create-role --role-name s3ag-location-role \ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --assume-role-policy-document file://trust-policy.json ii.&nbsp;IAM ロールに Amazon S3 の権限を付与する IAM ポリシーを作成する iam-policy.json というファイルを作成してください //iam-policy.json { "Version": "2012-10-17", "Statement": [ { "Sid": "ObjectLevelReadPermissions", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:GetObjectVersion", "s3:GetObjectAcl", "s3:GetObjectVersionAcl", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "{{accountId}}" }, "ArnEquals": { "s3:AccessGrantsInstanceArn": [ "arn:aws:s3:{{region}}:{{accountId}}:access-grants/{{instanceId}}" ] } } }, { "Sid": "ObjectLevelWritePermissions", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:PutObjectAcl", "s3:PutObjectVersionAcl", "s3:DeleteObject", "s3:DeleteObjectVersion", "s3:AbortMultipartUpload" ], "Resource": [ "arn:aws:s3:::*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "{{accountId}}" }, "ArnEquals": { "s3:AccessGrantsInstanceArn": [ "arn:aws:s3:{{region}}:{{accountId}}:access-grants/{{instanceId}}" ] } } }, { "Sid": "BucketLevelReadPermissions", "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "{{accountId}}" }, "ArnEquals": { "s3:AccessGrantsInstanceArn": [ "arn:aws:s3:{{region}}:{{accountId}}:access-grants/{{instanceId}}" ] } } }, { "Sid": "KMSPermissions", "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": [ "*" ] } ] } 注記: この IAM ポリシーでは、プレースホルダー {{ accountId }}, {{ region }}, および {{ instanceId }} を、それぞれあなたのアカウント、AWS リージョン、Access Grants インスタンス ID の情報に置き換える必要があります。上記のポリシーはデフォルトロケーション用です。デフォルト以外のロケーションを作成する場合は、ポリシーのリソース要素内のロケーションリストを更新してください。 その後、以下のコマンドを実行してください： aws iam put-role-policy --role-name s3ag-location-role --policy-name s3ag-location-role --policy-document file://iam-policy.json iii. S3 Access Grants ロケーションの作成 IAM ロールを作成したので、アカウント用のデフォルト S3 Access Grants ロケーションを作成し、その IAM ロールと関連付けることができます。 aws s3control create-access-grants-location \ --account-id 123456789012 \ --location-scope s3:// \ --iam-role-arn arn:aws:iam::123456789012:role/s3ag-location-role ロケーションスコープを s3:// に設定することは、S3 Access Grants ロケーションを作成する際に推奨されるオプションです。これにより、すべての GetDataAccess リクエストに対して s3ag-location-role を使用して資格情報を発行するように S3 Access Grants に指示します。 S3 Access Grants を使用した Amazon S3 データへのアクセス（同一アカウントのシナリオ） 1. アクセス権限の作成: これで、IAM ロール developerRole と analystRole にそれぞれ developer/ および analysis/ プレフィックスへのアクセス許可を付与する権限を作成することができます。この時点で、 developerRole に s3://DOC-EXAMPLE-BUCKET/developer/* への読み書きアクセス権限を与えるための 1 つの権限と、 analystRole に s3://DOC-EXAMPLE-BUCKET/analysis/* への読み取り専用アクセス権限を与えるための別の権限を作成できます。 developer/ プレフィックスに developerRole 用の READWRITE S3 Access Grants の権限を作成します。 aws s3control create-access-grant \ --account-id 123456789012 \ --access-grants-location-id default \ --access-grants-location-configuration S3SubPrefix=”DOC-EXAMPLE-BUCKET/developer/*” \ --permission READWRITE \ --grantee GranteeType=IAM,GranteeIdentifier=arn:aws:iam::123456789012:role/developerRole analysis/ プレフィックスに analystRole 用の READ S3 Access Grants の権限を作成します。 aws s3control create-access-grant \ --account-id 123456789012 \ --access-grants-location-id default \ --access-grants-location-configuration S3SubPrefix=”DOC-EXAMPLE-BUCKET/analysis/*” \ --permission READ \ --grantee GranteeType=IAM,GranteeIdentifier=arn:aws:iam::123456789012:role/analystRole developerRole と analystRole の IAM ロールに Amazon S3 プレフィックスへのアクセスを S3 Access Grants の権限を通じて与えるため、データへの直接的なアクセス権限（例： s3:GetObject アクション）を与える必要はありません。代わりに、各ロールに必要なのは s3:GetDataAccess 、つまり S3 Access Grants からデータへのアクセスを要求する能力です。言い換えれば、S3 Access Grants は、これらの IAM ロールのどれがどのデータセットへのアクセス権を持っているかを評価します。 ここには、IAM ロール developerRole と analystRole に必要な IAM ポリシーの例があります： { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetDataAccess" ], "Resource": [ "arn:aws:s3:us-east-2:123456789012:access-grants/default" ] } ] } developer および analyst の IAM ロールのための権限が現在設定されています。次に、 developerRole を使用して Bob がその権限を利用して Amazon S3 のデータを読む方法を示します。 2. 一時的な資格情報のリクエスト: developerRole を使用して、Bob は S3 Access Grants の GetDataAccess API への API リクエストを行います。 aws s3control get-data-access \ --account-id 123456789012 \ --target s3://DOC-EXAMPLE-BUCKET/bob/developer/*&nbsp; \ --permission READ S3 Access Grants はリクエストを行ったプリンシパル、ターゲット、およびリクエストされた権限に基づいてリクエストを評価します。ターゲットがこのバケットとプレフィックスで始まる任意の権限と一致する限り、S3 Access Grants は成功レスポンスを返します。この成功レスポンスは S3 からのデータを返すわけではなく、そのデータにアクセスするための S3 Access Grants の一時的な資格情報を返します。前述のリクエストに対して、 GetDataAccess API は成功します。なぜなら呼び出し元である developerRole は、リクエスト ( s3://DOC-EXAMPLE-BUCKET/developer/ ) と一致するターゲット s3://DOC-EXAMPLE-BUCKET/developer/* に権限を持っているためです。 レスポンスは以下のようになります： { "Credentials": { "AccessKeyId": "ASIACKCEVSQ6C2EXAMPLE", "SecretAccessKey": "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY", "SessionToken": "&lt;SessionTokenString...&gt;", "Expiration": "2023-11-07T17:34:37+00:00" }, "MatchedGrantTarget": "s3://DOC-EXAMPLE-BUCKET/developer/*" } 前述の成功レスポンスには一時的な IAM セッションの認証情報が含まれています。これらの認証情報を使用して、アプリケーションは例えば Amazon S3 の GetObject API などの Amazon S3 リクエストを行い、これらの認証情報が有効な期間内に s3://DOC-EXAMPLE-BUCKET/developer/ 下の任意のオブジェクトにアクセスすることができます。言い換えれば、S3 Access Grants アプリケーションは通常、個々のオブジェクトへのアクセスをそれぞれリクエストするべきではありません。代わりに、一致した権限の下での全てのアクセスに対して認証情報を再利用すべきです。 GetDataAccess への任意のリクエストがこの権限と一致する場合、成功レスポンスで同じ MatchedGrantTarget が結果として返されます。例えば、もし Bob が s3://DOC-EXAMPLE-BUCKET/developer/reports/file.txt への READ アクセスをリクエストした場合、それも権限と一致するため、S3 Access Grants は成功します。デフォルトでは、その成功レスポンスには一致した権限の下ですべてにアクセスするための一時的な IAM セッションの認証情報が含まれています。これは s3://DOC-EXAMPLE-BUCKET/developer/ です。ほとんどの S3 Access Grants の使用例では、アプリケーションが同じプレフィックスの下で多くの後続のリクエストを行う可能性が高いため、これが望ましい挙動です。しかし、アプリケーションがより狭い範囲のアクセスを望む場合が稀にあります。その場合、「privilege」オプションのパラメーターを「minimal」の値に設定できます。その場合、S3 Access Grants は特定のリクエストされたオブジェクトにのみアクセスする一時的な IAM セッションの認証情報を返します。 GetDataAccess リクエストと developerRole のレスポンスの例をいくつか示します。この例では、 developerRole に対して次の二つの権限があると仮定します： s3://DOC-EXAMPLE-BUCKET/developer/* への READ 権限 s3://DOC-EXAMPLE-BUCKET/developer/reports/* への READ 権限 developerRole への権限に対する privilege の動作を見てみましょう。 リクエストされた範囲 privilege 設定 返された範囲 効果 DOC-EXAMPLE-BUCKET/developer/ default DOC-EXAMPLE-BUCKET/developer/* “developer/”で始まるすべてのオブジェクトへの読み取りアクセス DOC-EXAMPLE-BUCKET/developer/ minimal DOC-EXAMPLE-BUCKET/developer/ “developer/”という名前の S3 オブジェクトへの読み取りアクセスのみ（そのようなオブジェクトがあることは一般的ではない）；“developer/”プレフィックスの下のオブジェクトへのアクセス権は無し DOC-EXAMPLE-BUCKET/developer/images/* minimal DOC-EXAMPLE-BUCKET/developer/images/* “developer/images/”で始まるすべてのオブジェクトへの読み取りアクセス DOC-EXAMPLE-BUCKET/developer/reports/file.txt default DOC-EXAMPLE-BUCKET/developer/reports/* “developer/reports/”で始まるすべてのオブジェクトへの読み取りアクセス（より具体的な一致した権限があったため） DOC-EXAMPLE-BUCKET/developer/reports/file.txt minimal DOC-EXAMPLE-BUCKET/developer/reports/file.txt キー developer/reports/file.txt を持つオブジェクトへの読み取りアクセス。他のオブジェクトへのアクセス権は無し 前述の例では、Amazon S3 内の 2 つのプレフィックスにロールベースのアクセスを提供することにより、S3 Access Grants の動作を説明しました。S3 内のたった 2 つの IAM ロールと 2 つのデータセットを使用するこのパターンは、直接の IAM 許可技術を使用して十分に実装することができ、そのために S3 Acess Grants は必要ありません。しかし、IAM ロール、Amazon S3 内のプレフィックス、およびアクセスマッピングの数と複雑さが増すにつれて、S3 Access Grants は管理上の利点を持ち始めます。これにより、単一の権限を一つずつ管理できるようになり、大規模に編集すると複雑になることがある一枚岩の IAM ポリシードキュメントの編集よりも効果的です。特に、これらの IAM ロールの一部がバケットとは異なる AWS アカウント内にある場合、S3 バケットポリシーのサイズ制限が、サポートできる異なるアクセスパターンの数に影響します。 次のセクションでは、AWS アカウント間でのアクセスのための S3 Access Grants の設定方法について説明します。 S3 Access Grants を使用した Amazon S3 データへのアクセス（クロスアカウントのシナリオ） S3 Access Grants インスタンスはリソースベースのポリシーをサポートしています。そのため、適切なリソースベースのポリシーがあれば、S3 Access Grants は他の AWS アカウントの IAM プリンシパルにアクセスを許可するためにも使用することができます。 この例では、AWS アカウント 111111111111 への権限の付与をサポートすることを目的としています。AWS アカウント 111111111111 の IAM プリンシパルが s3:GetDataAccess を使用して S3 内のデータにアクセスすることが期待されているため、このアクションをクロスアカウントで実行することを許可しています。ここに示されている s3:ListAccessGrants と s3:ListAccessGrantsLocations の権限は、このアカウントが S3 Access Grants をリストし、それらを使用してデータにアクセスすることを期待している場合に必要となります。 //s3ag-policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "111111111111" }, "Action": [ "s3:ListAccessGrants", "s3:ListAccessGrantsLocations", "s3:GetDataAccess" ], "Resource": "arn:aws:s3:us-east-2:123456789012:access-grants/default" } ] } このポリシードキュメントを S3 Access Grants インスタンスに割り当てるには、次のコマンドを実行できます： aws s3control put-access-grants-instance-resource-policy \ --account-id 123456789012 \ --policy file://s3ag-policy.json \ --region us-east-2 この S3 Access Grants インスタンスのポリシーは通常のリソースベースのポリシーであり、IAM ポリシー言語がサポートするすべてをサポートしています。たとえば aws:PrincipalArn 条件を使用してアカウント 111111111111 の特定の IAM プリンシパルにアクセスを許可することもできましたが、通常はここでそれを行う必要はありません。代わりに、S3 Access Grantsインスタンス内で、そのアカウントの個々の IAM プリンシパルに対して詳細な権限を記述します。これらは S3 Access Grants で個別に管理する方が、リソースベースのポリシーで行うよりも簡単です。 以下は、アカウント 1111111111 から testingRole へのクロスアカウント権限付与の図です。 図 2: クロスアカウントアクセスを持つ Access Grants これまでに、同じ AWS アカウント内および異なる AWS アカウントの IAM プリンシパルにアクセスを許可するために S3 Access Grants を使用することについて話しました。特に強力な機能は、IAM Identity Center との S3 Access Grants の統合によってもたらされる、ディレクトリユーザーとグループに直接権限を付与する能力です。たとえば、組織のユーザーがデータにアクセスするために使用する企業アプリケーションがある場合、これらのユーザーとグループに直接アクセスを許可することができます。これにより、これらのアプリケーションは以前のようにユーザーを IAM ロールにマッピングする必要がなくなります。次のセクションでは、S3 Access Grants をディレクトリユーザーやグループと使用する方法を紹介します。 ディレクトリユーザーの S3 Access Grants を使用した S3 データへのアクセス S3 Access Grants を AWS IAM Identity Center と一緒に使用する場合、企業ディレクトリ内のユーザーまたはそのグループメンバーシップに基づいてロケーションへのアクセスをユーザーに提供することができます。IAM Identity Center は AWS クラウド内で持っているユーザーを取り込み、AWS 管理アプリケーションや AWS アカウントへの割り当てに利用できるようにする一つの場所を提供します。S3 Access Grants を IAM Identity Center に接続すると、ユーザーは S3 Access Grants を使用してシングルサインオン体験を提供するアプリケーションを通じて Amazon S3 データにアクセスすることができます。これらのユーザーは IAM ロールを直接理解したり使用したりする必要はありません。これによるもう一つの利点は、ユーザーのアイデンティティが Amazon S3 の AWS CloudTrail データイベントに記録されることで、誰が（どのユーザーが）データにアクセスしたかを判断する監査作業が簡素化されることです。 S3 Access Grants をこの方法で使用する前に、まず AWS IAM Identity Center を設定する必要があります。詳細については、 ワークフォースアイデンティティの管理 を参照してください。知っておくべき主なことは、以下の通りです： IAM Identity Center にサポートされているアイデンティティプロバイダーを接続し、既存のユーザーとグループを使用するか、IAM Identity Center 内でユーザーとグループを作成することができます。 S3 Access Grants を使用するユーザーとグループを IAM Identity Center にプロビジョニングする必要があります。外部アイデンティティプロバイダーを使用する場合、これはクロスドメインアイデンティティ管理（SCIM）プロトコルを使用して行うのが最適です。 ユーザーは、IAM Identity Center と統合されている AWS サービスやアプリケーションを通じてデータにアクセスする必要があります。シングルサインオン体験を通じてデータセットにアクセスするアプリケーションを構築する方法については、 このブログ記事 を参照してください。 IAM Identity Center の設定方法については、 AWS IAM Identity Center を有効にする をご覧ください。 ここでは、企業のユーザーやグループ向けに S3 Access Grants で権限を作成する方法をご紹介します。 IAM Identity Center を有効にし、ID ソースを設定し、ユーザーをプロビジョニングしたら、ユーザーやグループに直接アクセスを許可する準備が整います。その手順は以下の通りです： 1. S3 Access Grants を IAM Identity Center に関連付ける この手順により、Access Grants で IAM Identity Center のユーザーやグループを参照できるようになります。これは S3 Access Grants コンソールでワンクリックで行うこともできます。 aws s3control associate-access-grants-identity-center \ --account-id 123456789012 \ --identity-center-arn arn:aws:sso:::instance/ssoins-1234567890abcdef 2. IAM Identity Center からユーザーやグループに権限を作成する Identity Center から特定のユーザーやグループに S3 Access Grant を作成するには、IAM Identity Center で GUID を見つける必要があります。以下では、IAM Identity Center コンソールでこの値を見つける場所を示しています。例えば、ユーザー「 Rafael 」の IAM Identity Center での GUID は 83d43802-00b1-7054-db02-f1d683aacba5 です。 図 3: ユーザー ID 付き Identity Center ユーザー情報 IAM Identity Center のユーザーの GUID を見つける別の方法としては、AWS CLI を通じて、または AWS SDK を使用してプログラム的に Identity Store API への API リクエストを行う方法があります。 こちらが Identity Store API のドキュメント です。 たとえば、このコマンドは IAM Identity Center のユーザーを名前と識別子と共にリストします。 aws identitystore list-users --identity-store-id d-1a2b3c4d1234 このコマンドはユーザーの GUID を返します。 aws identitystore get-user-id --region us-east-21 --cli-input-json '{ "IdentityStoreId": "d-1a2b3c4d1234", "AlternateIdentifier": { "UniqueAttribute": { "AttributePath": "UserName", "AttributeValue": "rafael" } } }' このコマンドは IAM Identity Center のグループをリストします。 aws identitystore list-groups --identity-store-id d-1a2b3c4d1234 そして、このコマンドは “ TeamA ” という名前のグループの GUID を返します。 aws identitystore get-group-id --region us-east-21 --cli-input-json '{ "IdentityStoreId": "d-1a2b3c4d1234", "AlternateIdentifier": { "UniqueAttribute": { "AttributePath": "DisplayName", "AttributeValue": "TeamA" } } }' IAM Identity Center のディレクトリユーザーとグループに S3 Access Grants 権限を付与することは、IAM プリンシパルへのアクセスを付与することに似ています。付与される対象のタイプは DIRECTORY_USER または DIRECTORY_GROUP で、付与される識別子は IAM Identity Center がユーザーやグループを識別するために使用する GUID になります。 例えば、 get-user-id を使用して Rafael の GUID を取得し、以下のコマンドでそのユーザー ID&nbsp; 83d43802-00b1-7054-db02-f1d683aacba5 に DOC-EXAMPLE-BUCKET/rafael/* の範囲でアクセス権を付与します。 aws s3control create-access-grant \ --account-id 123456789012 \ --access-grants-location-id default \ --access-grants-location-configuration S3SubPrefix="DOC-EXAMPLE-BUCKET/rafael/*" \ --permission READWRITE \ --grantee GranteeType=DIRECTORY_USER,GranteeIdentifier=83d43802-00b1-7054-db02-f1d683aacba5 \ 結論 この投稿では、S3 Access Grants が Amazon S3 へのデータアクセスを拡張する方法について学びました。これらの権限は IAM プリンシパルをサポートするだけでなく、IAM Identity Center と同期された企業ディレクトリのユーザーとグループに直接アクセス権を付与することも可能です。 S3 Access Grants は、IAM ベースの技術よりも柔軟でスケーラブルなメカニズムを提供し、大規模なアクセスパターンを定義できます。IAM Identity Center Trusted Identity Propagation との統合により、認証された各ユーザーの代わりに Amazon S3 のデータにアクセスし、ユーザーを認証するデータアプリケーションを開発することができます。また、最終的なユーザーのアイデンティティが Amazon S3 の AWS CloudTrail データイベントに表示されるため、監査が簡素化されます。 S3 Access Grants について詳しく知りたい場合は、 ドキュメント をご覧ください。 Rafael Koike Rafael M. Koike は、サウスイーストのエンタープライズカスタマーをサポートするプリンシパルソリューションアーキテクトであり、Storage TFC の一員です。セキュリティ、ストレージ、ネットワーキング、アプリケーション開発における彼の専門知識は、お客様が安全かつ迅速にクラウドへ移行する際に重要な役割を果たしています。 Vaibhav Sabharwal Vaibhav Sabharwal は、ニューヨークを拠点とする Amazon Web Services のシニアソリューションアーキテクトです。新しいクラウドテクノロジーの学習に情熱を持ち、クラウド採用戦略の構築、革新的なソリューションの設計、オペレーショナル・エクセレンスの推進を顧客に支援しています。AWS の金融サービス技術分野コミュニティのメンバーとして、業界内の協力的な取り組みに積極的に貢献しています。 この記事は Scaling data access with Amazon S3 Access Grants (記事公開日: 2023 年 11 月 26 日) を翻訳したものです。翻訳は串上が担当しました。 <!-- '"` -->