第 1 部 ( 日本語 ) では、企業内のある組織から別の組織に AWS アカウントを移行する際、ガイダンスと考慮事項が必要となる Organizations のさまざまな機能を確認しました。組織ポリシー、 AWS Resource Access Manager (AWS RAM) による共有、および AWS グローバル条件コンテキストキーに焦点を当てました。 3 部構成の第 2 回となるこの投稿では、AWS サービスに 委任された管理者 として登録されている AWS アカウントを移行する場合のふるまいを明らかにして、アクションを示します。AWS サービスの委任された管理者を登録解除するとどうなるかを理解し、計画を立てるのに役立つ情報とガイダンスを用意しました。また、AWS サービスの既存の委任された管理者がいる組織に AWS アカウントを移行する場合のガイダンスも提供します。第 1 部と同様に、引き続き組織のユーザーガイドに記載されている情報を基に、 組織からメンバーアカウントを削除 した上で、 AWS アカウントを組織に招待 します。組織間で AWS アカウントを移行するには、その AWS アカウントを組織から削除し、AWS アカウントをスタンドアロンにしてから、別の組織への招待を受け入れる必要があります。組織から AWS アカウントを削除する前に、その組織に委任された管理者が登録されているかどうかを確認することをお勧めします。 この記事では、 AWS Command Line Interface (AWS CLI) の例を使用しています。これらを利用するには、まず AWS CLI をインストールして設定する必要があります。詳細については、「 AWS CLI のインストール 」を参照してください。 AWS Organizations の委任された管理者 メンバーアカウントを組織の 委任された管理者 に指定すると、その AWS アカウントに設定された IAM ユーザーと IAM ロールは、互換性のある AWS サービスの管理アクションを実行できます。これにより、AWS Organizations の管理と AWS サービスの管理を分けることができます。委任された管理者として登録されているメンバーアカウントを組織から移行する場合、その AWS アカウントを委任された管理者から解除した上で組織から削除する必要があります。AWS アカウントを委任された管理者から解除して組織から削除する前に、その AWS アカウントに何が起こるか、考慮すべきアクションを理解しておく必要があります。 組織の委任された管理者を現在サポートしている AWS サービスのリストを次のセクションに含めています。AWS サービス名または サービスプリンシパル名 のいずれかで探すことができます。AWS CLI の list-delegated-services-for-account コマンドを使用して、登録済みの委任された管理者の AWS アカウントを出力することでサービスプリンシパル名を確認できます。一部の AWS サービスでは、委任された管理者が設定されているかどうかを AWS サービスコンソールでも確認できます。 次の AWS CLI の例では、指定された AWS アカウントが委任された管理者となっている AWS サービスを確認します。< account-id > を、 確認したい AWS アカウント ID に置き換えてください。 PROMPT > aws organizations list-delegated-services-for-account --account-id < account-id > 組織内に AWS サービスの委任された管理者である AWS アカウントがあるかどうかを確認するには、AWS CLI list-delegated-administrators コマンドを使用します。次の例では、AWS CLI コマンドを使用して、特定の AWS サービスに割り当てられている委任された管理者の AWS アカウントを特定し、その AWS アカウントが委任された管理者となっているサービスプリンシパルがリストされることを確認します。 次の AWS CLI の例では、組織内の委任された管理者として指定されているすべての AWS アカウントのリストを取得します。 PROMPT > aws organizations list-delegated-administrators 次の AWS CLI の例では、指定されたアカウントが委任された管理者である AWS サービスを取得します。前のステップで見つかったそれぞれの “Id” 値に < account-id > を置き換え、“DeleatedAdministrators“ のリストを確認するコマンドを繰り返します。 PROMPT > aws organizations list-delegated-services-for-account --account-id < account-id > 指定した AWS サービスに委任された管理者が設定されているかどうかを確認するには、AWS CLI の list-delegated-administrator コマンドを使用できます。次の AWS CLI の例では、指定されたサービスプリンシパルの AWS サービスで委任された管理者として指定されているすべての AWS アカウントを取得します。< service-principal > を確認したい AWS サービスのサービスプリンシパル名に置き換えてください。 PROMPT > aws organizations list-delegated-administrators --service-principal < service-principal > 組織の管理アカウントの認証情報と AWS CLI deregister-delegated-administrator コマンドを使用して、互換性のある AWS サービスで委任された管理者である AWS アカウントの登録を解除できます。 AWS Audit Manager , Amazon Detective , AWS Firewall Manager , Amazon GuardDuty , Amazon Macie , AWS Security Hub , Amazon VPC IP Address Manager (IPAM) などの一部の AWS サービスには、委任された管理者への AWS アカウントの登録と登録解除のための独自のコマンドまたはコンソールオプションがあります。現時点で委任された管理者をサポートしている AWS サービスのコマンドのバリエーションを詳しく説明します。 次の AWS CLI の例では、引数で指定された AWS サービスにおいて、同じく引数で指定されたメンバーアカウントを委任された管理者から解除します。< account-id > を、委任された管理者から解除したいメンバーアカウントの AWS アカウント ID 番号に置き換えてください。< service-principal > を、この AWS アカウントが委任された管理者となっている AWS サービスのサービスプリンシパル名に置き換えてください。 PROMPT > aws organizations deregister-delegated-administrator --account-id < account-id > --service-principal < service-principal > AWS Service Catalog , AWS CloudFormation StackSets , AWS Network Manager , Amazon S3 Storage Lens , AWS Trusted Advisor , AWS Config などの特定の AWS サービスにおいては、ケースに合わせて 1 つの組織内に複数の委任された管理者アカウントを持つことができます。この記事の後半で、それぞれのクォータについて詳しく説明します。複数の委任された管理者をサポートする AWS サービスでは上限のアカウント数に至るまでは、現在の委任された管理者の登録を解除することなく、別の AWS アカウントを登録できます。これは、組織を維持する予定があり、現在の委任された管理者を別の組織に移すことを検討している場合のオプションとして使用できます。多数の AWS アカウントを移行する間の作業をサポートするために、または組織を維持する場合には、組織内で別の委任された管理者を構成することを検討してください。組織に残っている AWS アカウント、または最後に移行するもしくは閉じる（削除する）既存の AWS アカウントを選択します。移行中に、委任された管理者設定すべてをこの AWS アカウントに割り当てることができます。 組織の委任された管理者だった AWS アカウントが別の組織に移行されると、その AWS アカウントはメンバーアカウントとして新しい組織に参加します。この AWS アカウントは、互換性のある AWS サービスの委任された管理者として登録されていません。 AWS アカウントを別の組織に移行するときは、新しい組織の委任された管理者と連携するように AWS アカウントを設定する必要があるかどうかを確認する必要があります。多くの AWS サービスでは、新しい組織で委任された管理者と連携する通常の設定を再度行うだけで移行できます。ただしいくつかの AWS サービスでは、委任された管理者アカウントにおいて移行のための特別な設定が必要な場合があります。次のセクションで解説する委任された管理者をサポートしている AWS サービスのリストには、そのようなガイダンスも含まれています。対象組織に AWS サービスの委任された管理者である AWS アカウントがあるかどうかを確認するには、AWS CLI の list-delegated-administrators コマンドを使用できます。組織内に委任された管理者が見つかった場合は、AWS CLI list-delegated-services-for-account コマンドを使用して、どの AWS サービスなのかを確認することができます。この情報を使用して、組織に AWS アカウントを追加するときに必要なアクションを計画できます。 AWS Organizations の委任された管理者をサポートしている AWS サービス 次の AWS サービスのリストは AWS Organizations と連携し、かつ委任された管理者もサポートしています。このセクションには、AWS サービスの委任された管理者として AWS アカウントを登録解除する前に考慮すべきガイダンスと動作が含まれています。また既存の委任された管理者がいる組織に移行したときも、AWS アカウントの設定を確認できます。 AWS Account Management: account.amazonaws.com AWS Account Management の 委任された管理者アカウント の登録を解除すると、その AWS アカウントに設定された IAM ユーザーと IAM ロールは AWS Account Management の管理アクションを実行できなくなります。その AWS アカウントは、組織内の他のメンバーアカウントの AWS アカウント管理 API オペレーション を呼び出すことができなくなります。 AWS Audit Manager: auditmanager.amazonaws.com AWS Audit Manager の 委任された管理者アカウント の登録を解除すると、その AWS アカウントに設定された IAM ユーザーと IAM ロールは AWS Audit Manager の管理アクションを実行できなくなります。AWS アカウントでそれまでに収集された証拠には、引き続きアクセスができます。ただしその後は AWS Audit Manager は証拠の収集と AWS アカウントへの添付を停止します。委任された管理者の登録を解除するには、その組織の管理アカウントの AWS Audit Manager コンソールまたは AWS CLI の deregister-organization-admin-account コマンドを使用できます。 AWS CloudFormation StackSets: member.org.stacksets.cloudformation.amazonaws.com AWS CloudFormation StackSets の 委任された管理者アカウント の登録を解除すると、その AWS アカウントに設定された IAM ユーザーと IAM ロールは AWS CloudFormation StackSets の管理アクションを実行できなくなります。その AWS アカウントは、サービスマネージド型のアクセス許可でスタックセットを作成または管理することができなくなります。サービスマネージド型のアクセス許可でそれまでに作成されたスタックセットは、組織の管理アカウントに保持されます。AWS CloudFormation StackSets の委任された管理者として、1 つの組織に最大 5 つのメンバーアカウントを登録できます。 AWS アカウントを別の組織に移行する前に、移行先組織に設定されている StackSets のデプロイ対象を確認してください。移行する AWS アカウントに StackSets が適用されるかどうかをデプロイ対象から判断する必要があります。 セルフマネージド型の権限 を使用して StackSets を設定している場合、 ターゲットアカウント または 管理者アカウント を移行しても影響はありません。このブログシリーズの第 1 部で説明した、管理者アカウントの AWSCloudFormationStackSetAdministrationRole と、ターゲットアカウントの AWSCloudFormationStackSetExecutionRole の 条件キー に関連する AWS Identity and Access Management (IAM) ロールポリシーを確認してください。 AWS Compute Optimizer: compute-optimizer.amazonaws.com AWS Compute Optimizer の 委任された管理者アカウント の登録を解除すると、その AWS アカウントに設定された IAM ユーザーと IAM ロールは AWS Compute Optimizer の管理アクションを実行できなくなります。その AWS アカウントは、組織内のメンバーアカウントの Compute Optimizer レコメンデーションにアクセスして管理したり、組織の Compute Optimizer 推奨設定を管理できなくなります。 AWS Config: config-multiaccountsetup.amazonaws.com AWS Config の 委任された管理者アカウント の登録を解除すると、その AWS アカウントの Config ルールとコンフォーマンスパック、設定された IAM ユーザーおよび IAM ロールは AWS Config の管理アクションを実行できなくなります。この AWS アカウントでは、 Config ルール と コンフォーマンスパック を組織全体にデプロイおよび管理できなくなります。委任された管理者アカウントによってデプロイされたコンフォーマンスパックと Config ルールは、その AWS アカウントと組織のすべてのメンバーアカウントから自動的に削除されます。AWS Config の Config ルールとコンフォーマンスパックの委任された管理者は、1 つの組織に最大 3 つのメンバーアカウントを登録できます。 AWS アカウントを別の組織に移行する場合、その AWS アカウントが管理アカウントまたは AWS Config ルールとコンフォーマンスパックの既存の委任された管理者と連携できるように、AWS Config 設定レコーダー が有効になっていることを確認する必要があります。設定レコーダーが無効な場合、既存の組織のルールとコンフォーマンスパックのデプロイは、AWS アカウントが組織に追加されてから 7 時間以内に再試行されます。 AWS Config: config.amazonaws.com AWS Config データ集約の 委任された管理者アカウント の登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは AWS Config の管理アクションを実行できなくなります。その AWS アカウントは組織全体の AWS Config データを集約できなくなり、設定されたアグリゲータはデータを受信しなくなります。AWS Config データ集約の委任された管理者として、1 つの組織に最大 3 つのメンバーアカウントを登録できます。同じ組織の委任された管理者として同じ AWS アカウントを登録した場合、設定されているアグリゲータは引き続きデータを収集します。 AWS アカウントを別の組織に移行する場合、AWS Config アグリゲータを使用している移行先の委任された管理者と連携するために、該当アカウントで AWS Config を有効にしておく必要があります。 Amazon Detective: detective.amazonaws.com Amazon Detective の 委任された管理者アカウント の登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは Amazon Detective の管理アクションを実行できなくなります。Amazon Detective は委任された管理者アカウントでは無効になり、組織の行動グラフはすべて削除されます。 Amazon Detective の委任された管理者を登録解除するには、管理アカウントの Detective のコンソールまたは AWS CLI の disable-organization-admin-account コマンドを使用する必要があります。Detective のコンソールを使用する場合、現在のリージョンの Detective 管理者アカウント のみが削除されるため、リージョンごとに管理者を削除する必要があります。AWS CLI の disable-organization-admin-account コマンドを使用する場合は、組織の管理アカウントの認証情報を使用し、各リージョンの Detective 管理者アカウントを削除する必要があります。コンソールまたは AWS CLI の deregister-delegated-administrator コマンドを使用して、指定された組織の委任された管理者を削除する必要があります。 アカウントを別の組織に移行するときは、Amazon Detective の [アカウント管理] 設定を確認してください。Amazon Detective は、 新しい組織の AWS アカウントを Amazon Detective メンバーアカウントとして自動的または手動で有効にする ように設定できます。 Amazon DevOps Guru: devops-guru.amazonaws.com Amazon DevOps Guru の 委任された管理者アカウント の登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは Amazon DevOps Guru の管理アクションを実行できなくなります。この AWS アカウントでは、組織全体の DevOps Guru のすべてのインサイトとメトリクスをまとめて表示することはできなくなります。組織の管理アカウントは、引き続き組織内のすべての AWS アカウントのすべてのインサイトにアクセスできます。 AWS Firewall Manager: fms.amazonaws.com AWS Firewall Manager の 委任された管理者アカウント の登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、AWS Firewall Manager の管理アクションを実行できなくなります。 AWS Firewall Manager 管理者 アカウントによって作成されたすべての Firewall Manager ポリシーは、関連する AWS Config マネージドルールも含めて削除されます。AWS Firewall Manager ポリシーを削除すると、 Network Firewall 、 Security group (共通)、 AWS WAF の ポリシーの範囲 の設定によって、Firewall Manager が保護を保持または削除するか、 Firewall Manager が管理するリソースを削除するかが決まります。 DNS Firewall ポリシー を削除すると、 Amazon Route 53 Resolver DNS Firewall ルールグループと任意の Amazon Virtual Private Cloud (VPC) との間のマネージドな関連付けが削除されることに注意してください。 委任された管理者を削除する前に、セキュリティポリシー、アプリケーション、プロトコルリストを含む Firewall Manager の設定を控えておく必要があります。この情報を使用して、別の委任された管理者アカウントにこの設定を引き継ぐことができます。Firewall Manager のセキュリティポリシー、アプリケーション、およびプロトコルを一覧表示するには、組織の管理アカウントの認証情報と AWS CLI の list-policies 、 list-apps-lists 、 list-protocols-lists コマンドをそれぞれ使用します。 委任された管理者を削除するには、委任された管理者アカウントの Firewall Manager コンソールを使用するか、委任された管理者アカウントの認証情報を使用して、バージニア北部リージョン (us-east-1) で AWS CLI の disassociate-admin-account コマンドを使用します。ある AWS アカウントを組織から削除したときに、その AWS アカウントがまだ委任された管理者として登録されていることがわかった場合は、AWS CLI の deregister-delegated-administrator コマンドを使用できます。ある AWS アカウントを別の組織に移行する場合、その AWS アカウントが既存の AWS Firewall Manager ポリシーに関するスコープポリシーに含まれているか、(必要に応じて) 除外されているかを確認してください。 Amazon GuardDuty: guardduty.amazonaws.com Amazon GuardDuty の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、Amazon GuardDuty の管理アクションを実行できなくなります。委任された管理者アカウントの登録を解除しても、その AWS アカウントまたは組織のメンバーアカウントの GuardDuty は無効になりません。組織内の AWS アカウントは関連付けを解除され、すべての設定が保持されたまま GuardDuty がスタンドアロンで動作する AWS アカウントに変換されます。 Amazon GuardDuty の委任された管理者を登録解除するには、管理アカウントの GuardDuty コンソールまたは AWS CLI の disable-organization-admin-account コマンドを使用する必要があります。Amazon GuardDuty コンソールを使用する場合、 GuardDuty の管理者設定はすべてのリージョンで無効化され 、組織で指定されている GuardDuty の委任された管理者設定は削除されます。AWS CLI の deregister-delegated-administrator コマンドを使用する場合は、各リージョンの GuardDuty の管理者設定を無効化してから、このコマンドを使用して組織で指定された委任された管理者設定を削除する必要があります。 ある AWS アカウントを別の組織に移行した際、組織単位で Amazon GuardDuty を有効にしたリージョンでは、自動的に GuardDuty メンバーアカウントとして関連付けられます。GuardDuty が組織単位で有効でなく AWS アカウントが関連付けられていない場合は、委任された管理者アカウントの GuardDuty コンソールを使用してその AWS アカウントを 手動でメンバーアカウントとして追加 できます。 IAM Access Analyzer: access-analyzer.amazonaws.com IAM Access Analyzer の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、IAM Access Analyzer の管理アクションを実行できなくなります。この AWS アカウントは、委任された管理者アカウントとして作成した、信頼ゾーンが組織であるすべてのアナライザーに対する権限を失います。構成済みのアナライザーはすべて無効な状態になり、新しい検出結果の生成や既存の検出結果の更新は行われなくなります。これらのアナライザーにおける既存の検出結果にもアクセスできなくなります。ただし、同じ AWS アカウントをこの組織の委任された管理者として再度登録することで、再びそれらの検出結果にアクセスできるようになります。委任された管理者と同じ AWS アカウントを使用しないことがわかっている場合は、委任された管理者を変更する前にアナライザーを削除することを検討してください。これにより、生成された検出結果がすべて削除されます。別の AWS アカウントを委任された管理者として登録し、新しいアナライザーを作成すると、同じ検出結果の新しいインスタンスがこの AWS アカウントで生成されます。ある AWS アカウントを別の組織に移行するときに、信頼ゾーンが組織であるアナライザーがすでに作成されている場合、移行した AWS アカウントは自動的に分析対象のセットに含まれます。 AWS IAM Identity Center (successor to AWS Single Sign-On): sso.amazonaws.com AWS IAM Identity Center の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、AWS IAM Identity Center の管理アクションを実行できなくなります。AWS IAM Identity Center で設定された権限や割り当ては影響を受けず、エンドユーザーは引き続き AWS アクセスポータルからアプリケーションと AWS アカウントにアクセスできます。 Amazon Inspector: inspector2.amazonaws.com Amazon Inspector の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、Amazon Inspector の管理アクションを実行できなくなります。その AWS アカウントは組織を対象にした Amazon Inspector を監視することができなくなり、 Amazon Elastic Compute Cloud (Amazon EC2) や Amazon Elastic Container Registry (Amazon ECR) の設定データやセキュリティ検出の結果など、関連付けされた組織のメンバーアカウントのメタデータにアクセスできなくなります。委任された管理者を登録解除しても、その AWS アカウントまたは組織のメンバーアカウントの Inspector は無効になりません。組織の AWS アカウントは関連付けを解除され、スキャン設定を保持したまま Inspector がスタンドアロンで動作する AWS アカウントに変換されます。 組織の管理アカウントの Amazon Inspector コンソールを使用して委任された管理者を削除する場合、すべてのリージョンから委任された管理者を削除する必要があります。AWS CLI の deregister-delegated-administrator コマンドを使用すると、委任された管理者がすべてのリージョンから自動的に削除されます。同じ組織の Inspector に別の委任された管理者を設定する場合は、組織のメンバーを委任された管理者アカウントに手動で関連付ける必要があります。 ある AWS アカウントを別の組織に移行すると、「 自動的に有効化 」が設定されたリージョンでは、その AWS アカウントは自動的に委任された管理者と Inspector に関して関連付けられます。移行した AWS アカウントが関連付けられていない場合は、委任された管理者アカウントの Inspector コンソールを使用して、 手動でメンバーアカウントとして追加 できます。 AWS License Manager: license-manager.amazonaws.com: license-manager.member-account.amazonaws.com AWS License Manager の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、AWS License Manager の管理アクションを実行できなくなります。AWS RAM を使用して AWS License Manager のライセンス設定を AWS アカウントと直接共有するのか、組織と連携して共有するのかを確認する必要があります。このブログシリーズの第 1 部では、所有者アカウントとコンシューマーアカウントの両方について、AWS RAM リソースの共有と組織間を移行する際の考慮事項について説明しています。 Amazon Macie: macie.amazonaws.com Amazon Macie の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、Amazon Macie の管理アクションを実行できなくなります。この AWS アカウントは、すべての AWS リージョンのすべての Macie におけるメンバーアカウントの Macie 設定、データ、およびリソースにアクセスできなくなります。委任された管理者アカウントの登録を解除しても、その AWS アカウントまたは組織のメンバーアカウントの Macie は無効になりません。組織のメンバーアカウントは関連付けを解除され、すべての設定が保持されたまま Macie がスタンドアロンで動作する AWS アカウントに変換されます。 Amazon Macie の委任された管理者を登録解除するには、組織の管理アカウントの認証情報を使用して、AWS CLI の disable-organization-admin-account コマンドを実行する必要があります。Macie 管理者が設定されたリージョンでその設定を削除し、次に AWS CLI の deregister-delegated-administrator コマンドを使用して組織で指定された委任された管理者を削除する必要があります。 ある AWS アカウントを別の組織に移行する場合、 自動有効化 が設定されたリージョンでは、AWS アカウントは Macie に関して自動的に委任された管理者と関連付けられます。AWS アカウントが関連付けられていない場合は、委任された管理者アカウントの Macie コンソールを使用して 手動でメンバーアカウントとして追加 できます。 AWS Network Manager: networkmanager.amazonaws.com AWS Network Manager の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、Network Manager の管理アクションを実行できなくなります。登録されている他のメンバーアカウントのトランジットゲートウェイは、その AWS アカウントのグローバルネットワークから登録解除されます。ネットワークトポロジが更新され、他のメンバーアカウントのリソースが表示されなくなります。Network Manager の委任された管理者として、組織毎に最大 10 個のメンバーアカウントを登録できます。 AWS Security Hub: securityhub.amazonaws.com AWS Security Hub の 委任された管理者アカウント の登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、Security Hub の管理アクションを実行できなくなります。委任された管理者を登録解除しても、その AWS アカウントまたは組織のメンバーアカウントの Security Hub は無効になりません。組織のメンバーアカウントは関連付けを解除され、すべての設定が保持されたまま Security Hub がスタンドアロンで動作する AWS アカウントに変換されます。 AWS Security Hub の委任された管理者を登録解除するには、管理アカウントの Security Hub コンソールまたは AWS CLI の disable-organization-admin-account コマンドを使用する必要があります。Security Hub コンソールを使用する場合、Security Hub 管理者はすべてのリージョンで削除され、組織で指定されている Security Hub の委任された管理者は削除されます。AWS CLI の disable-organization-admin-account コマンドを使用する場合は、組織の管理アカウントの認証情報を使用し、各リージョンの Security Hub 管理者を削除する必要があります。完了したら、AWS CLI の deregister-delegated-administrator コマンドを使用して、組織に指定されている委任された管理者を削除します。 ある AWS アカウントを別の組織に移行する場合、 自動有効化 をオンにしたリージョンでは、その AWS アカウントは自動的に Security Hub の委任された管理者と関連付けられます。AWS アカウントが関連付けられていない場合は、委任された管理者アカウントの Security Hub コンソールを使用して 手動でメンバーアカウントとして追加 できます。 Amazon S3 Storage Lens: storage-lens.s3.amazonaws.com Amazon Simple Storage Service (Amazon S3) Storage Lens の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、Amazon S3 Storage Lens の管理アクションを実行したり、組織レベルのダッシュボードを作成することができなくなります。委任された管理者によって作成された Amazon S3 Storage Lens 組織レベルのダッシュボードは、自動的に無効になります。登録解除された AWS アカウントは、データがクエリに使用できるそれぞれの期間に応じて、無効になっているダッシュボードの履歴データを引き続き表示できます。Amazon S3 Storage Lens の委任された管理者として、1 つの組織に組織に最大 5 つのメンバーアカウントを登録できます。 AWS Service Catalog: servicecatalog.amazonaws.com AWS Service Catalog の 委任された管理者 アカウントの登録を解除すると、 IAM ユーザーおよび IAM ロールは、AWS Service Catalog の管理アクションを実行できなくなります。さらに、ポートフォリオを作成、削除、共有する権限がなくなります。この AWS アカウントから作成された AWS Service Catalog ポートフォリオの共有は削除されます。 委任された管理者アカウントによって共有されているポートフォリオから製品をプロビジョニングした AWS アカウントが組織内に 1 つ以上残っている場合は、同じ組織に別の委任された管理者アカウントを設定することで、すべての共有製品を移行できます。また、AWS Service Catalog の委任された管理者として、1 つの組織に最大 50 個のメンバーアカウントを登録できます。組織の管理アカウントに共有ポートフォリオがある場合は、そのポートフォリオを委任された管理者アカウントに移行することを強くお勧めします。 共有製品を同じ組織の AWS Service Catalog の委任された管理者アカウントに移行するには、下記の手順を実施します: 移行元の委任された管理者アカウントの AWS Service Catalog 共有ポートフォリオにプロビジョニング済みの製品が含まれているかどうかを確認します。製品が見つかった場合は、委任された管理者として登録されている別の AWS アカウントのポートフォリオに製品を移行できます。ポートフォリオを共有しているアカウント ID をすべて書き留めておきます。 AWS Service Catalog における別の委任された管理者アカウントを登録します。この AWS アカウントは、全てのプロビジョニング済み製品のポートフォリオの管理に使用されます。 元の製品と同じテンプレートを使用して、移行先の委任された管理者アカウントに新しいポートフォリオを作成します。これにより、プロビジョニング済み製品のリソースが終了したり再作成されたりすることがなくなります。 ステップ 3 で作成したポートフォリオを、ステップ 1 で特定した AWS アカウントに共有してインポートします。これらは、ポートフォリオから作られたプロビジョニング済み製品を持つ AWS アカウントです。 ポートフォリオを共有している各 AWS アカウントで、移行先の委任された管理者アカウントにおける共有された、プロビジョニング済み製品を選択の上で更新して製品を変更します。“Changing the product will update this provisioned product to a different product template. This may terminate resources and create new resources.(製品を変更すると、このプロビジョニング済み製品が別の製品テンプレートに更新されます。これにより、リソースが終了し、新しいリソースが作成される可能性があります。)“ というメッセージが表示されます。元の製品と同じテンプレートを使用してポートフォリオを作成した場合は、このメッセージは無視してかまいません。 移行元の委任された管理者アカウントからすべてのポートフォリオと関連付けられた製品を移行したら、移行元の委任された管理者アカウントのポートフォリオから元の共有を削除できます。移行元の委任された管理者アカウントは登録解除できます。 [オプション] 委任された管理者アカウントの登録を解除しても、委任された管理者が作成したポートフォリオと共有が削除されない場合は、委任された管理者をもう一度登録した上で登録解除します。この 2 番目のアクションにより、この AWS アカウント用に作成されたポートフォリオと共有が削除されます。 プロビジョニング済み製品の AWS アカウントを AWS Service Catalog の共有ポートフォリオから別の組織に移行する場合、その製品を移行先組織のポートフォリオに関連付けることができます。移行先組織における AWS Service Catalog の委任された管理者として登録されたアカウントでポートフォリオと製品を再作成し、その組織内で共有できます。対象の AWS アカウントを移行先組織に参加させて、プロビジョニング済み製品を移行先組織内で共有されている製品に更新できます。このアプローチは、組織を削除する予定で、別の組織に移行しても共有ポートフォリオを維持したい場合に使用できます。 共有製品を別の組織の委任された管理者アカウントに移行するには、下記の手順を実施します: 移行元の委任された管理者アカウントの AWS Service Catalog 共有ポートフォリオにプロビジョニング済みの製品が含まれているかどうかを確認します。製品が見つかったら、そのポートフォリオを共有している AWS アカウント ID をすべて書き留めておきます。 「AWS 組織アカウント」または「AWS アカウント」のいずれかを使用するようにポートフォリオ共有を更新し、上記の移行先組織に移行する AWS アカウントの AWS アカウント ID を指定します。これにより組織から AWS アカウントを削除しても、製品はその AWS アカウントに残ります。 コンシューマーアカウントで、共有ポートフォリオが表示されていない場合は、それをインポートして、製品に対して必要なプリンシパルの権限を更新します。 移行先組織で AWS Service Catalog に関する委任された管理者の AWS アカウントを登録します。この AWS アカウントは、全てのプロビジョニング済み製品のポートフォリオの管理に使用されます。 移行元の製品と同じテンプレートを使用して、移行先の委任された管理者アカウントに新しいポートフォリオを作成します。これにより、プロビジョニング済み製品のリソースが終了したり再作成されたりすることがなくなります。移行元の共有ポートフォリオにおけるプロビジョニング済み製品を保持している移行中 AWS アカウントのために、新しいポートフォリオを元の組織または移行先組織と共有します。 移行元組織からポートフォリオコンシューマーアカウントを削除すると、共有ポートフォリオと製品が表示され、プロビジョニング済み製品は変更されずに残っていることがわかります。 移行先組織にコンシューマーアカウントを追加する際、共有ポートフォリオが表示されていない場合はそれをインポートし、製品に対して必要なプリンシパルの権限を更新します。 ポートフォリオを共有している各 AWS アカウントで、プロビジョニング済み製品を選択し、新しい委任された管理者アカウントから共有した製品に更新します。プロビジョニング済み製品を、移行元組織で共有されていた元の製品から、移行先組織で作成した同じ製品に変更します。“Changing the product will update this provisioned product to a different product template. This may terminate resources and create new resources. (製品を変更すると、このプロビジョニング済み製品が別の製品テンプレートに更新されます。これにより、リソースが終了し、新しいリソースが作成される可能性があります。)“ というメッセージが表示されます。元の製品と同じテンプレートを使用してポートフォリオを作成した場合は、このメッセージは無視してかまいません。 移行元組織の委任された管理者アカウントで、過去に作成した AWS アカウント共有を削除します。これにより、ポートフォリオと製品がコンシューマーアカウントから削除され、新たに共有されたポートフォリオと、新しい所有者のプロビジョニング済み製品のみが残ります。 [オプション] 移行元組織の委任された管理者アカウントが別の組織に移行する場合、移行元の委任された管理者アカウントからすべてのポートフォリオと関連付けられた製品を移行したら、この AWS アカウントを委任された管理者として登録解除できます。 [オプション] 委任された管理者アカウントの登録を解除しても、委任された管理者が作成したポートフォリオと共有が削除されない場合は、委任された管理者をもう一度登録した上で登録解除します。このアクションにより、この AWS アカウント用に作成されたポートフォリオと共有が削除されます。 AWS Systems Manager: ssm.amazonaws.com AWS Systems Manager の 委任された管理者 アカウントの登録を解除すると、AWS Systems Manager Explorer と Change Manager の両方に影響します。AWS アカウントで設定された IAM ユーザーおよび IAM ロールは、AWS Systems Manager Explorer または Change Manager の管理アクションを実行できなくなります。この AWS アカウントは、組織のリソースデータ同期の API オペレーションにアクセスできなくなります。AWS Systems Manager Explorer は、委任された管理者の組織のリソースデータ同期とそれに含まれるデータをすべて削除します。このアクションを実施すると、元に戻すことはできなくなります。この AWS アカウントでは、変更テンプレート、変更リクエスト、変更ランブック、承認ワークフローの管理など、組織全体の Change Manager アクティビティを管理できなくなります。委任された管理者アカウントで作成された、複数の組織単位 (OU) に変更を適用する Change Manager リクエストはすべて残ります。ただし、これらは正常に実行されません。これには、スケジュールされたリクエストや承認待ちのリクエストも含まれます。 AWS Trusted Advisor: reporting.trustedadvisor.amazonaws.com AWS Trusted Advisor の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントで設定された IAM ユーザーおよび IAM ロールは、AWS Trusted Advisor の管理アクションを実行できなくなります。その AWS アカウントは、Trusted Advisor Priority のレコメンデーションを確認、承認、解決、拒否、および再開できなくなります。さらに、Trusted Advisor Priority からのメール通知は届かなくなります。AWS Trusted Advisor の委任された管理者として、組織に最大 5 つのメンバーアカウントを登録できます。 Amazon VPC IP Address Manager (IPAM): ipam.amazonaws.com Amazon VPC IP Address Manager (IPAM) の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントで設定された IAM ユーザーおよび IAM ロールは、IPAM の管理アクションを実行できなくなります。この AWS アカウントでは、組織内の IP アドレス割り当てを管理および監視できなくなり、組織のメンバーアカウント間で IPAM プールを共有することもできなくなります。委任された管理者を削除するには、組織の管理アカウントの IPAM コンソールまたは AWS CLI の disable-ipam-organization-admin-account コマンドを使用できます。 AWS アカウントの登録を解除したときに、AWS RAM を使用して IPAM プールを組織で共有している場合、リソース共有は保持されます。ただし、メンバーアカウントは共有 IPAM にアクセスできなくなります。このような共有 IPAM プールを使用しようとすると、“The operation AllocateIpamPoolCidr is not supported. Account <account-id> is not monitored by IPAM ipam-<ipam-id>.(AllocateIPamPoolCIDR 操作はサポートされていません。<account-id> は IPAM <ipam-id> によって監視されていません。)”という例外処理が表示されます。AWS アカウントが組織を離れると、IPAM プールのリソース共有内の組織のプリンシパルはすべて自動的に共有から切り離されます。 IPAM の委任された管理者として登録されていて、かつ組織の共有 IPAM プールを持つ AWS アカウントを別の組織に移行する場合は、同じ IPAM プール構成を別の AWS アカウントに設定できます。現在の委任された管理者の登録を解除したら、代替の IPAM を設定した AWS アカウントを委任された管理者として登録し、組織で共有します。組織に残っている AWS アカウント、または以前に共有された IPAM プールから CIDR ブロックが割り当てられた Amazon VPC を持つ AWS アカウントは、新しく設定された IPAM プールに引き継がれます。 IPAM の委任された管理者として登録されている AWS アカウントを移行する場合、AWS アカウントを移行した後でも、移行先組織の AWS アカウントで保持されている IPAM を使用できます。IPAM を維持して使用する計画がある場合は、移行元組織に残る AWS アカウントのリソースに対する CIDR ブロックの 割り当ての解除 を検討する必要があります。そうしなければ、CIDR ブロックは引き続き割り当て済みとしてマークされます。移行先組織に移行しない AWS アカウントのリソースに割り当て済みとマークされた CIDR ブロックは、移行先組織の委任された管理者による管理対象ではなくなります。移行先組織で IPAM を使用するには、その AWS アカウントを IPAM の委任された管理者として登録する必要があります。その AWS アカウントでは、移行先組織のプリンシパルを関連付けるように、AWS RAM リソース共有を変更する必要があります。IPAM から CIDR ブロックが割り当てられた Amazon VPC を持つ同じ組織に移行した AWS アカウントが追跡されます。移行先組織にすでに IPAM の委任された管理者がいる場合は、その組織に移行する AWS アカウントのリソースに割り当てるための CIDR ブロックを使用する新規または既存の IPAM を構成できます。 まとめ このブログでは、委任の機能と互換性のある AWS サービスに関して、組織の中で委任された管理者を特定し、そのような AWS アカウントを移行する場合の動作とアクションを特定するための解説をしました。組織の委任された管理者として登録されている AWS アカウントは、組織を削除する前に登録を解除する必要があることを学びました。またある AWS アカウントが、いずれかの AWS サービスの委任された管理者であるかどうかを判断する方法と、AWS アカウントを委任された管理者から解除するときに想定される動作と実行するアクションについても学びました。 このブログシリーズでは、AWS Organizations のさまざまな機能を順を追って説明し、AWS Organizations を使用する場合や、AWS アカウントをある組織から別の組織に移行する際のガイダンスと注意を解説しています。 シリーズの 第 1 部 ( 日本語 ) では、AWS Organizations のさまざまな機能について説明し、AWS Organizations を使用して AWS アカウントをある組織から別の組織に移行する場合のガイダンスと注意を解説しました。 第 3 部 では、組織内で「信頼されたアクセス」が設定された AWS サービスを特定し、AWS アカウントを移行する前のアクションと動作を解説します。 ブログ著者について: Karl Schween Karl Schween は、Amazon Web Services の Principal Solutions Architect です。彼は、お客様がビジネス上の問題に対処できるような、拡張性が高く柔軟で回復力のあるクラウドアーキテクチャを構築できるよう支援しています。 Deepa Pahuja Deepa Pahuja は、Amazon Web Services の Senior Solutions Architect です。Deepa は、お客様と協力して、クラウドネイティブサービスを使用してビジネス上の問題を解決するアーキテクチャを構築することを楽しんでいます。仕事以外では、Deepa は新しい場所の探検、ハイキング、ダンスを楽しんでいます。 翻訳はプロフェッショナルサービス本部の須田が担当しました。原文は こちら です。

コンタクトセンターを管理されている方であれば、エージェントが顧客の信頼とロイヤリティの構築に果たす重要な役割をご存知でしょう。コンタクトセンターに問い合わせをしたことのある人なら、複雑な意思決定を導き、必要な場合には迅速かつ正確なソリューションを提供するエージェントがいかに重要であるかをご存知でしょう。これには時間がかかり、正しく行われなければ、フラストレーションにつながりかねません。 Amazon Connect の生成系 AI 機能 本日、コンタクトセンターが顧客にサービスを提供する方法を変革するために、 Amazon Connect の既存の人工知能（AI）機能に、 Amazon Bedrock を通じて利用可能な大規模言語モデル（LLM） を活用した生成系 AI 機能が追加されたことを発表します。LLM は、一般に基盤モデル（FM）として知られる膨大な量のデータで事前に訓練されており、理解し、学習し、テキストを生成し、インタラクティブな会話に参加し、質問に答え、ダイアログや文書を要約し、推奨することができます。 Amazon Q in Connect：カスタマーサポートを迅速に行うために推奨される応答とアクション 組織は常に変化しています。このような組織の変化に対応し、高いレベルのパフォーマンスを維持するために、コンタクトセンターでは、エージェントの採用、トレーニング、コーチングを継続的に行っています。トレーニングやコーチングを受けたとしても、エージェントは顧客に卓越したサービスを提供するために、製品ガイドや組織の方針など、さまざまな情報源を検索しなければなりません。これは、顧客の待ち時間を増やし、顧客満足度を下げ、コンタクトセンターのコストを増加させる可能性があります。 Amazon Q in Connect は、Amazon Connect Wisdom として提供されていた機能を含む、生成系 AI を搭載したエージェントアシスタントで、顧客の意図を理解し、関連する情報源を使用して、エージェントが顧客固有のニーズを伝え、解決するための正確な応答とアクションを、すべてリアルタイムで提供します。2024 年 3 月 1 日まで、Amazon Q in Connect を無料でお試しいただけます。この機能は簡単に有効化でき、Amazon Connect コンソールで開始できます。 Amazon Connect Contact Lens: 生成されたコンタクト要約で生産性向上 顧客とのやり取りを改善し、今後の参考のために詳細を確認できるようにするために、コンタクトセンターの管理者は、エージェントが顧客とのやり取りの後に手動で作成するメモを頼っています。これらのメモには、顧客の問題にどのように対処したか、会話の重要な瞬間、保留中のフォローアップ項目などの詳細が含まれます。 Amazon Connect Contact Lens は、生成系 AI を搭載したコンタクトの要約を提供し、コンタクトセンターの管理者がより効率的にコンタクトの品質とエージェントのパフォーマンスを監視し、改善することを可能にします。例えば、要約を使用して、顧客との約束を追跡し、フォローアップアクションの迅速な完了を確認することができます。顧客との対話の後に、Contact Lens は会話を簡潔にまとめて要約します。 Amazon Connect in Amazon Lex：スロット解決の支援機能を提供 Amazon Lex を使用することで、チャットボット、バーチャルエージェント、インタラクティブボイスレスポンス（IVR）を構築することができます。これにより、顧客は人間のエージェントに話しかけることなく予約をすることができます。例えば、「自分と2人の子供の旅行の予約を変更したい」という場合、従来のボットでは数値（旅行の予約は何人か？）を解釈するのが難しいかもしれません。 新しいスロット解決支援機能により、Amazon Lex はユーザーの発話からスロットの値を非常に正確に解決できるようになりました（例えば、先ほどの質問に対して正しい数値 3 と答える）。これは、精度を向上させ、より良い顧客体験を提供する LLM の高度な推論機能によるものです。より良いセルフサービス体験の構築を支援する新しい生成系 AI 機能を含めた、 Amazon Lex の機能 の全てをご覧ください。 Amazon Connect Customer Profiles：パーソナライズされた顧客体験のための統一された顧客プロファイルを迅速に作成 顧客はパーソナライズされた顧客サービス体験を期待しています。これを提供するために、コンタクトセンターは顧客の嗜好、購買、インタラクションを包括的に理解する必要があります。これを実現するために、コンタクトセンターの管理者は、多くのアプリケーションからの顧客データを統合することで、統一された顧客プロファイルを作成します。これらのアプリケーションは、それぞれ異なるタイプの顧客データをさまざまなデータストアにさまざまなフォーマットで保存しています。これらのさまざまなデータストアからデータをつなぎ合わせるには、コンタクトセンター管理者はデータを理解し、それをどのように整理して統一されたフォーマットにまとめるかを考えなければならず、そのために、統一された顧客プロファイルをコンパイルするのに数週間を費やしています。 本日より、 Amazon Connect Customer Profiles は LLM を使用することで、統一された顧客プロファイルの作成に必要な時間を短縮します。コンタクトセンター管理者が Amazon Simple Storage Service（Amazon S3） 、Adobe Analytics、Salesforce、ServiceNow、Zendesk などのデータソースを追加すると、Customer Profiles はデータを分析し、データフォーマットとコンテンツが何を表しているか、データが顧客のプロファイルにどのように関連しているかを理解します。そして、Customer Profiles は、異なるソースからのデータをどのように整理し、組み合わせて完全で正確なプロファイルにするかを自動的に決定します。わずか数ステップで、管理者は顧客プロファイルを確認し、必要な編集を行い、セットアップを完了することができます。 Amazon Connect のアプリ内、Web、ビデオ通話機能 組織として、あなたは素晴らしく、使いやすく、便利な顧客サービスを提供したいと考えています。この記事の前半で、セルフサービスのチャットボットと、それがどのように役立つかをお話ししました。時には、顧客はチャットや音声通話よりも密なコミュニケーションを希望することがあります。 Amazon Connect には、 アプリ内、Web、ビデオ通話機能 があり、リッチでパーソナライズされた顧客体験の提供を支援します。フルマネージドなコミュニケーションウィジェットを使用すれば、数行のコードだけで、Web やモバイルアプリケーションにこれらの機能を実装することができます。これにより、顧客はページを離れることなく、Web またはモバイルアプリケーションを通じてサポートを受けることができます。ビデオは、エージェントのみ、顧客のみ、またはエージェントと顧客の両方で有効にすることができます。 Amazon Connect SMS：双方向 SMS 機能 ほとんどの人がモバイルデバイスを所有しており、外出先でもテキストベースのサポートを受けられる柔軟性を好んでいます。コンタクトセンターのリーダーはこのことを知っており、これまでは顧客に双方向の SMS を提供するために、独立したサードパーティのソリューションに頼ってきました。 Amazon Connect は、コンタクトセンターのリーダーがこの柔軟性を提供できるように、 双方向 SMS 機能 の提供を開始しました。これにより、顧客満足度が向上し、コストのかかるサードパーティのソリューションと統合することなく、エージェントの生産性が向上します。SMS チャットは、通話やチャットと同じ設定で、 Amazon Connect Agent Workspace や分析も有効にすることができます。 詳細はこちら Amazon Q in Connect 製品ページ Amazon Connect の使用を開始するユーザーガイド 機能をサポートするリージョンは こちら サポートされる言語は こちら フィードバックの送信 AWS re:Post for Amazon Connect 、またはAWSサポート窓口からご連絡ください。 – Veliswa Veliswa Boya Veliswa Boyaは、シニア・デベロッパー・アドボケイトで、南アフリカを拠点にサハラ以南のアフリカのビルダー・コミュニティと緊密に連携しています。開発者からアナリスト、アーキテクト、クラウドエンジニア、そして現在はデベロッパー・アドボケイトと、技術分野で多くの役割を担っています。Veliswaは特に、技術初心者やAWSを使い始めたばかりの人たちとの仕事を楽しんでいます。 翻訳は、ソリューションアーキテクトの濱上が担当しました。原文は こちら です。

AWSは EventBridge Pipesによるロギング のサポートを発表しました。 Amazon EventBridge Pipes は、イベントのプロデューサとコンシューマを接続し、オプションでフィルタ、変換、エンリッチメントを行うことができるポイント・ツー・ポイントの統合ソリューションです。EventBridge Pipesを利用することで、イベント駆動型アプリケーションを構築する際に、開発者が記述・管理する必要のある統合コードの量を削減できます。よくある統合ソリューションには、 Amazon Kinesis streamsとフィルタリングの接続、 Amazon DynamoDB と Amazon EventBridge の統合、 Amazon SQS と AWS Step Functions の統合などがあります。 EventBridge Pipesのロギングでは、パイプ実行のさまざまな段階についての洞察が得られます。これは Amazon CloudWatchのメトリクスサポート を拡張し、トラブルシューティングとデバッグのための方法を提供します。 パイプの実行ステップ内の様々な成功シナリオと失敗シナリオを把握できるようになりました。イベント変換またはエンリッチメントが成功または失敗した場合、ログを使用してより深く掘り下げ、構成されたパイプに問題がないかトラブルシューティングを開始することができます。 EventBridge Pipesの実行ステップ パイプの実行ステップを理解することは、ログに記録される情報の量を決定する適切なログレベルを選択するのに役立ちます。 パイプの実行は、ソースからターゲットに移動するパイプによって受信されるイベントまたはイベントのバッチです。イベントがパイプを通過すると、 AWS Step Functions 、 AWS Lambda 、 Amazon API Gateway 、 EventBridge API Destinations を使用して、フィルタリング、変換、またはエンリッチメントをすることができます。 パイプの実行は、エンリッチメントとターゲットの2つの主要なステージで構成されます。これらのステージは両方とも、変換と呼び出しのステップを含みます。 Input Transformer を使用すると、イベントがエンリッチメントを受けたり、下流のターゲットにディスパッチされる前に、イベントのペイロードを変更することができる。これにより、構成されたパイプの実行中に、イベントデータの操作をきめ細かく制御することができます。 パイプの実行が開始されると、実行はエンリッチメントの段階に入ります。エンリッチメントステージを設定しない場合、実行はターゲットステージに進みます。 パイプの実行、変換、エンリッチメント、ターゲットの各フェーズで、EventBridge はデバッグやトラブルシューティングに役立つ情報をログに記録できます。パイプのログには、ペイロード、エラー、変換、AWSリクエスト、AWSレスポンスが含まれます。 パイプ実行の詳細については、 こちらのドキュメント を参照してください。 EventBridge Pipes でログレベルを設定 パイプでロギングを有効にすると、EventBridge は実行ステップごとにログ・エントリを作成し、これらのログを指定したログ宛先に送信します。 EventBridge Pipesは3つのログ送信先をサポートしています： Amazon CloudWatch Logs、 Amazon Kinesis Data Firehose stream、 Amazon S3 です。送信されるレコードは、パイプのログ・レベル（OFF、ERROR、INFO、TRACE）を設定することでカスタマイズできます。 OFF – EventBridge はレコードを送信しません。 ERROR – EventBridge は、パイプの実行中に発生したエラーに関連するレコードを送信します。例えば、Execution Failed、Execution Timeout、Enrichment Failures などがあります。 INFO – EventBridge は、パイプ実行中に実行されたエラーと選択された情報に関連するレコードを送信します。例としては、Execution Started、Execution Succeeded、Enrichment Stage Succeeded などがあります。 TRACE – EventBridge は、パイプ実行の任意のステップ中に生成されたすべてのレコードを送信します。 ERRORログレベルは、失敗したパイプ実行の背後にある理由を知る上で有益です。パイプ実行はタイムアウト、エンリッチメントの失敗、変換の失敗、ターゲット呼び出しの失敗など、さまざまな理由で失敗することがあります。ERROR ログを有効にすると、パイプエラーの具体的な原因を知ることができ、問題の解決が容易になります。 INFOログレベルは、ERROR情報をさらに詳細に補足します。INFO ログレベルは、エラーを通知するだけでなく、パイプ実行の開始、エンリッチメントフェーズへの移行、変換フェーズへの移行、ターゲットステージの開始と正常終了に関する洞察を提供します。 より詳細な分析のために、パイプの実行に関する包括的な洞察を得るために TRACE ログレベルを使用することができます。これはサポートされている全てのパイプログを包含し、INFO や ERROR ログを超えた詳細なビューを提供します。TRACE ログレベルでは、スキップされたパイプ実行ステージや、変換やエンリッチメントプロセスの開始などの重要な情報が明らかになります。 ログレベルと送信されるログの詳細については、 ドキュメントを参照 してください。 EventBridge Pipesのロギングに実行データを含める さらにデバッグを助けるためにパイプログ内に実行データを含めることを選択できます。このデータはイベントペイロード、AWS リクエスト、および構成されたエンリッチメントとターゲットコンポーネントに送受信されたレスポンスで構成されます。 また、パイプの実行中に AWS サービスに送信されたペイロード、リクエスト、およびレスポンスに関するさらなる洞察を得るために、実行データを使用することもできます。 実行データを組み込むことで、パイプの実行をより深く理解し、発生した問題のデバッグを支援することができます。 ログ内の実行データには3つの部分があります： payload ： イベント自体の内容。イベントのペイロードには機密情報が含まれている可能性があり、EventBridge はその内容を編集しようとしません。実行データを含めるかどうかはオプションで、オフにすることもできます。 awsRequest ： エンリッチメントまたはターゲットにシリアライズされた JSON 形式で送信されたリクエスト。API Destinations の場合、これにはそのエンドポイントに送信された HTTP リクエストが含まれます。 awsResponse ： エンリッチメントまたはターゲットがJSON形式で返すレスポンス。 API Destinations の場合、これは設定されたエンドポイントから返されるレスポンスです。 イベントのペイロードは、イベント自体が更新可能な場合に入力されます。これらのステージには、最初のパイプ実行、エンリッチメントフェーズ、ターゲットフェーズが含まれる。 awsRequest と awsResponse は、どちらもエンリッチメントとターゲティングの最終段階で生成されます。 ログレベルと実行データの詳細については、 こちらのドキュメント をご覧ください。 EventBridge Pipes ログを使い始める この例では、ロギングを有効にして実行データを含むパイプを作成します。パイプは、エンリッチメントステップなしでターゲット上の入力トランスフォーマーを使用して2つの Amazon SQS キューを接続します。Input Transformer は、ターゲットに到達する前にイベントのペイロードをカスタマイズします。 ソースキューとターゲットキューの作成 # ソース用のキューを作成する aws sqs create-queue --queue-name pipe-source # ターゲット用のキューを作成する aws sqs create-queue --queue-name pipe-target EventBridge Pipesに移動し、 Create pipe を選択します。 ソースとして SQS を選択し、SQS q ueue として pipe-source を選択します。 フィルタリングとエンリッチメントのフェーズをスキップして、新しい Target を追加します。Target サービスとして SQS を、 Queue として pipe-target を選択します。 ターゲット入力トランスフォーマセクションを開き、トランスフォーマーフィールドにトランスフォーマーコードを入力します。 { "body": "Favorite food is <$.body>" } Pipe settings を選択して、新しいパイプのロググループを設定します。 CloudWatch Logs がログ宛先として設定されていることを確認し、ログレベルとして Trace を選択する。“ Include execution data ” チェックボックスをチェックします。これにより、全てのトレースが新しいCloudWatchロググループにログされ、パイプで送信されるSQSメッセージが含まれます。 Create Pipe を選択 送信元キューに SQS メッセージを送信します。 # キューURLの取得 aws sqs get-queue-url --queue-name pipe-source # URLを使ってキューにメッセージを送信する aws sqs send-message --queue-url {QUEUE_URL} --message-body "pizza" 全てのトレースログはモニタリングタブに表示されます。詳細は CloudWatch Logs セクションを参照してください。 まとめ EventBridge Pipes は、イベント・プロデューサとコンシューマ間のポイント・ツー・ポイントの統合を可能にします。EventBridge Pipes でログがサポートされたことで、パイプ実行のさまざまな段階を把握できるようになりました。パイプのログ送信先は CloudWatch Logs、Kinesis Data Firehose、Amazon S3 に設定できます。 EventBridge Pipes は3つのログレベルをサポートしています。 ERROR ログレベルは、エラーに関連するレコードをログ宛先に送信するように EventBridge を構成します。 INFO ログレベルは、パイプ実行中のエラーおよび選択された情報に関連するレコードを送信するように EventBridge を構成します。 TRACE ログレベルは、生成されたすべてのレコードをログ宛先に送信します。 ログに実行データを含めることができ、これにはイベント自体、およびパイプで構成された AWS サービスに対して行われたAWSリクエストとレスポンスが含まれます。これは、パイプの実行に関する更なる洞察を得るのに役立ちます。 EventBridge Pipes Logs の詳細については、ドキュメントをお読みください。 サーバーレスの学習リソースについては、 Serverless Land をご覧ください。 この記事の翻訳は Solutions Architect ポールが担当しました。原文は こちら からご覧いただけます。

はじめに 収益の拡大、業務の効率化、コストの削減を目的に、モノのインターネット (IoT) ソリューションを採用する企業経営者が増えています。産業用機械であれ自律走行車であれ、自社の機器をクラウドに接続しながらセキュリティと安全性を配慮するのは難しいことです。AWS は インダストリアルIoTソリューションにおける10のセキュリティゴールデンルール の中で、製造環境からクラウドへのセキュアな接続と、オンプレミスのリソースへのセキュアなリモートアクセスを確立することを推奨しています。同様に、コネクテッド・モビリティ・ソリューションでは、一般的にプライベート・セルラー・ネットワークを使用して車両をクラウド・サービスに接続しています。 このブログでは、プライベートネットワークを使用して IoT デバイスを安全かつセキュアに AWS に接続するための一般的なアーキテクチャパターンとベストプラクティスについて説明します。 AWS IoT Core 認証プロバイダ の Virtual Private Cloud (VPC) エンドポイント機能 を利用することで、 AWS IoT Greengrass を搭載したデバイスを、パブリックなインターネットアクセスなしに VPC 内で動作させることが可能になりました。さらに、これらのデバイスは AWS PrivateLink を使用して Amazon Elastic Container Registry (Amazon ECR)、 AWS Secrets Manager 、 Amazon CloudWatch logs などの他の AWS サービスにアクセスできます。このアプローチは、プライベート接続を確立しインターネットからネットワークトラフィックを分離することで、接続ソリューションの安全性をより柔軟に確保し、また組織のセキュリティベストプラクティスに準拠するのに役立ちます。 ソリューション概要 このソリューションでは、Amazon VPC 内のプライベートエンドポイントを使用して IoT デバイスを AWS IoT Core と AWS IoT Greengrass に接続できます。プライベートエンドポイントは、仮想ネットワークアドレス空間からのプライベート IP アドレスを使用して、デバイスを VPC 内の AWS IoT Core データエンドポイント と AWS IoT Greengrass にプライベート接続します。 インターフェイス VPC エンドポイント は、インターネットにデータを晒すことなく VPC と AWS サービス間の接続を確立するために使用できる AWS サービスである AWS PrivateLink によって提供されるサービスに接続するために使用されます。接続されたデバイスと AWS IoT Core および AWS IoT Greengrass 間のネットワークトラフィックは、 AWS site-to-site VPN または AWS Direct Connect を使用し、パブリックインターネットへの接続を回避します。ソリューションアーキテクチャとソリューションコンポーネントについて説明します。 シナリオ1：IoT デバイスをプライベートネットワークを使って AWS IoT Core に接続する 図1：プライベートネットワークを通じて AWS IoT Core に接続する工場内の IoT デバイス ソリューションの説明 この手順には以下のステップが含まれています： 工場にあるアセットは「AWS IoT データエンドポイント」のドメイン名を解決する必要があります。AWS IoT デバイスデータエンドポイントは、IoT デバイスの通信ニーズに合わせて設計されたパブリッシュ/サブスクライブプロトコルをサポートしています。事前に構成されたドメインネームシステム (DNS) リゾルバにクエリを送信します。 企業データセンターの DNS リゾルバ には「AWS IoTデータエンドポイント」DNSドメインのすべての DNS クエリをAmazon Route 53 Resolver インバウンド エンドポイントに向ける条件付きフォワーダルールが設定されています。 転送されたクエリは、AWS Direct Connect または AWS Site-to-Site VPN を介して Amazon Route 53 Resolver インバウンドエンドポイントに到着します。すべてのインバウンド DNS クエリは、リゾルバに向かう途中でこの VPC を通過します。信頼性を高めるため、リゾルバでは DNS クエリに 2 つの IP アドレスを指定する必要があります。高可用性を実現するために、2つの異なるアベイラビリティゾーンに IP アドレスを指定することを推奨します。 Amazon Route 53 Resolver インバウンドエンドポイントは、VPC 内の VPC + 2リゾルバにクエリを送信します。 Amazon Route 53 Resolver は、AWS IoT Core データドメイン名の DNS クエリを解決します。 VPC に関連付けられたプライベートホストゾーンは、AWS IoT Core データエンドポイントの DNS レコードを保持するため、Amazon Route 53 Resolver はクエリを解決できます。 AWS IoT Core データエンドポイント宛てのトラフィックは、DNS を使用してエンドポイントのネットワークインターフェイスのプライベート IP アドレスに解決され、VPC エンドポイントと AWS IoT Core 間の接続を使用して AWS サービスにプライベートで送信されます。 セキュリティーを考慮するため、 VPC インターフェイスのエンドポイントにセキュリティグループとネットワーク ACL を設定します VPC 条件コンテキストキーを使用して、VPC エンドポイントを介した AWS IoT Core データへのアクセスを制御します 以下の表は、AWS IoT データ VPC エンドポイントに必要な詳細を示しています。詳細は ドキュメント をご覧ください。 図2：IoT デバイスに対応する DNS エイリアスを持つ VPC エンドポイント 図3：AWS コンソールでの VPC エンドポイントの設定 注: インタフェース VPC エンドポイントの作成 に関する詳細は、 AWS IoT Core とインターフェース VPC エンドポイントの作成 と共に参照してください。Amazon Route 53 でプライベートホストゾーンを作成する詳細については、 ドキュメント を参照してください。 シナリオ 2: AWS IoT Greengrass を搭載したデバイスが AWS IoT 認証情報 VPC エンドポイントを使用して AWS IoT Core に接続する場合 図4：プライベートネットワーク経由で AWS IoT Core に接続する AWS IoT Greengrass 搭載デバイス ソリューションの説明 この手順には以下のステップが含まれています： AWS IoT Greengrass クライアントデバイスであるセンサーは、MQTT を介して AWS IoT Greengrass コアデバイスと接続し、通信します。エッジの AWS IoT Greengrass コアソフトウェアは「AWS IoT データエンドポイント」、「AWS IoT 認証情報プロバイダ」および「Amazon Simple Storage Service (Amazon S3)」ドメイン名を解決する必要があります。事前に設定された DNS リゾルバにクエリを送信します。ユースケースに基づき、追加のエンドポイントが必要になる場合があります。 企業データセンターの DNS リゾルバには「AWS IoT データエンドポイント」、「AWS IoT 認証情報プロバイダ」および「Amazon S3」 の DNS ドメインに対するすべての DNS クエリを Amazon Route 53 Resolver インバウンドエンドポイントに向ける条件付きフォワーダールールがあります。 転送されたクエリは、AWS Direct Connect または AWS Site-to-Site VPN を介して Amazon Route 53 Resolver インバウンド エンドポイントに到達します。すべてのインバウンド DNS クエリは、リゾルバに向かうに途中でこの VPC を通過します。信頼性を高めるため、リゾルバでは DNS クエリに 2 つの IP アドレスを指定する必要があります。高可用性を実現するために、2つの異なるアベイラビリティゾーンに IP アドレスを指定することを推奨します。 Amazon Route 53 Resolver インバウンドエンドポイントは、VPC 内の VPC + 2リゾルバにクエリを送信します。 Amazon Route 53 Resolver は、「AWS IoT データエンドポイント」、「AWS IoT 認証情報プロバイダ」および「Amazon S3」の DNS クエリを解決します。 VPC に関連付けられた プライベートホストゾーンは、Amazon Route 53 Resolver がクエリを解決できるように、「AWS IoT データ」、「AWS IoT 認証情報プロバイダ」および「Amazon S3」 の DNS レコードを保持します。 「AWS IoT データ」、「AWS IoT 認証情報プロバイダ」および「Amazon S3」エンドポイント宛てのトラフィックは、DNS を使用してエンドポイントのネットワークインターフェースのプライベート IP アドレスに解決され、VPC エンドポイントと AWS IoT Core 間の接続を使用して AWS サービスにプライベートに送信されます。 注: AWS IoT Greengrass Core ソフトウェアがコンポーネントをデプロイする際、AWS からコンポーネントのアーティファクトをダウンロードします。Amazon S3 の VPC エンドポイントを設定することにより、Greengrass Core デバイスがこれらのアーティファクトに安全かつ効率的にアクセスできるようになります。 AWS IoT Greengrass nucleus の設定では、greengrassDataPlaneEndpoint を iotdata に設定する必要があります。詳細は Greengrass nucleus configuration を参照してください。この設定は、Greengrass nucleus が AWS IoT Greengrass サービスと通信するために使用するエンドポイントを指定します。iotdata に設定することで、Greengrass Core は AWS IoT Greengrass と通信するために AWS IoT データプレーンエンドポイントを使用します。この設定は、コアデバイスが AWS IoT Core と効率的に通信し、運用やデプロイに必要なデータを送受信できるようにするために重要です。 次の表は、対応するカスタム・プライベート DNS エイリアスに関する情報です。詳細については、 ドキュメント を参照してください。 図5：AWS IoT Greengrass 搭載デバイスに対応する DNS エイリアスを持つ VPC エンドポイント AWS IoT データエンドポイント (com.amazonaws.region.iot.data) は、AWS IoT Greengrass サービスのコンポーネント、デプロイメント、コアデバイスを管理するために使用されます。 このエンドポイントでの認証と認可は、「 AWS IoT Greengrass のデバイス認証と認可 」で説明されているように、X.509 証明書を使用して行われます。 IoT のユースケースと使用する機能によっては、追加のエンドポイントが必要になる場合があります。たとえば、AWS が提供する AWS IoT Greengrass コンポーネントの場合、コンポーネントが機能するために必要なサービスを理解するためにドキュメントを参照してください。よくある例をいくつか挙げます: 図 6: AWS サービス VPC エンドポイントの例 AWS IoT 認証情報プロバイダ VPC エンドポイント (com.amazonaws.<region>.iot.credentials) は、 Amazon Simple Storage Service (Amazon S3) や Amazon Elastic Container Registry (Amazon ECR) のような、X.509 認証と認可をサポートしていない他の AWS クラウド サービスと通信するために使用されます。これらの場合、AWS IoT Core または AWS IoT Greengrass コンポーネントは、X.509 証明書を使用して AWS IoT 認証情報プロバイダのエンドポイントを呼び出し、認証と承認を取得します。エンドポイントは、クライアントが X.509 をサポートしていないサービスの呼び出しに使用する一時的なセキュリティ トークンを発行します。 Amazon S3 と Amazon ECR サービスへの呼び出しは、AWS IoT Greengrass コンポーネントのデプロイ時に必要です。また、AWS IoT Greengrass コンポーネントは、AWS SDK を使用して X.509 証明書の認証および認可メカニズムをサポートしていない他のクラウド サービスと通信する場合にもセキュリティトークンを必要とします。独自のコンポーネントを使用している場合は、依存関係を確認し、追加のエンドポイントが必要かどうかを判断するために追加のテストを実行する必要があるかもしれません。 VPC エンドポイント経由での AWS IoT Core へのアクセス制御 VPC 条件コンテキストキーを使用することで、AWS IoT Core へのデバイスアクセスを VPC エンドポイント経由のみに許可するように制限できます。SourceVpc キーを使用して、ポリシーで指定した VPC からのリクエストかどうかを確認できます。SourceVpce キーを使用して、リクエストの VPC エンドポイント識別子とポリシーで指定したエンドポイント ID を比較し、特定の VPC エンドポイントへのアクセスを制限します。VPCSourceIp を使用すると、リクエストの送信元 IP アドレスをポリシーで指定した IP アドレスと比較できます。 注: このポリシーはパブリック IoT データ・エンドポイントへの接続試行を拒否します AWS IoT Greengrass 用の VPC エンドポイントポリシーの作成 CreateDeployment や ListEffectiveDeployments など、AWS IoT Greengrass のコントロールプレーン操作用のインターフェイス VPC エンドポイントを作成する場合、VPC エンドポイントポリシーを使用して、AWS IoT Greengrass のコントロールプレーン操作へのアクセスを制御することができ、セキュリティ体制の改善に役立ちます。ポリシーは以下の情報を指定します： アクションを実行できるプリンシパル プリンシパルが実行できるアクション プリンシパルがアクションを実行できるリソース 以下は、AWS IoT Greengrass のエンドポイントポリシーの例です。エンドポイントにアタッチすると、このポリシーは、すべてのリソースのすべてのプリンシパルに、リストされた AWS IoT Greengrass アクションへのアクセスを許可します。 { "Statement": [ { "Principal": "*", "Effect": "Allow", "Action": [ "greengrass:CreateDeployment", "greengrass:ListEffectiveDeployments" ], "Resource": "*" } ] } AWS IoT data VPC エンドポイントと AWS IoT Core 認証情報プロバイダエンドポイントの制限事項 このブログを書いている時点では、IoT データ VPC エンドポイントと 認証情報プロバイダエンドポイントにはいくつかの制限があります。例えば、 IoT データ VPC エンドポイントの MQTT ベースのキープアライブ期間は230秒に制限され、各 VPC エンドポイントは最大 10 万台の同時接続デバイスをサポート 両方のエンドポイントで許可されるのは IPv4 トラフィックのみ どちらのエンドポイントも Amazon Trust Service (ATS) 証明書のみを提供し、VPC エンドポイントポリシーはサポートされない ただし、これら制限はありますが AWS IoT Core データエンドポイントと AWS IoT Core 認証情報プロバイダ機能は、プライベートネットワークを使用して多数のデバイスを AWS に接続するための安全な方法を提供します。機能と制約に関する最新情報については、 AWS のドキュメント を確認してください。 まとめ デバイスは様々な環境、場所、シナリオでデプロイされるため、IoT ソリューションを実装する際には柔軟性とセキュリティが必要です。このブログでは、プライベートネットワークを使用して IoT 実装されたデバイスと AWS IoT Greengrass を搭載したデバイスを AWS IoT Core と他の AWS サービスに安全に接続するためのアーキテクチャとベストプラクティスについて説明しました。このソリューションは、接続されたデバイスとネットワークをインターネットから分離し、プライベートネットワークを使用して AWS にデータを送信する機能を提供します。このアプローチは、プライベートネットワーク上で安全な通信を確立し、パブリックネットワークにおけるセキュリティ事象から AWS リソースを保護するのに役立ち、組織のセキュリティベストプラクティスと要件に沿った運用を可能にします。詳細については、 AWS IoT でのセキュリティ をご覧ください。 リソース: インターフェイスVPCエンドポイントでAWS IoT Coreを使用する https://docs.aws.amazon.com/iot/latest/developerguide/IoTCore-VPC.html AWS Direct Connect https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html VPC エンドポイントを経由しての AWS IoT Core へのアクセス制御 https://docs.aws.amazon.com/iot/latest/developerguide/IoTCore-VPC.html#Control-VPC-access VPCとネットワーク間のDNSクエリの解決 https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html Back to Basics: Understanding IOT Core VPC Endpoint Patterns https://www.youtube.com/watch?v=r0NzJjMjhyw AWS IoT Greengrass とインターフェイス VPC エンドポイント (AWS PrivateLink) https://docs.aws.amazon.com/greengrass/v2/developerguide/vpc-interface-endpoints.html     Ryan Dsouza は、AWS のプリンシパル・インダストリアル IoT (IIoT) セキュリティ・ソリューション・アーキテクトです。Ryan はニューヨークを拠点に、AWS の広範かつ深い機能を使って、より安全でスケーラブルかつ革新的な IIoT ソリューションの設計、開発、運用を支援し、測定可能なビジネス成果を提供しています。Ryan は、デジタル・プラットフォーム、スマート製造、エネルギー管理、ビルディング・オートメーション、産業オートメーション、OT/IIoT セキュリティなど、さまざまな業界で 25 年以上の経験を積んでいます。Ryan は、すべてのコネクテッドデバイスにセキュリティを導入し、すべての人にとってより良く、より安全で、よりレジリエントな世界を構築するチャンピオンになることに情熱を注いでいます。AWS 以前は、Accenture、SIEMENS、General Electric、IBM、AECOM に勤務し、顧客のデジタルトランスフォーメーション・イニシアチブに貢献してきました。 この記事は Ryan Dsouza によって書かれた Common architecture patterns to securely connect IoT devices to AWS using private networks の日本語訳です。この記事は SA の渡邉が翻訳しました。

生成系AIが、企業のビジネスを変革しています。企業はAIを使用して、データ主導の意思決定を改善し、オムニチャネル体験を強化し、次世代の製品開発を推進しています。企業は、電子メール、プッシュ通知、その他のアウトバウンドコミュニケーションチャネルを通じたマーケティング活動を強化する目的で、特に生成系AIを使用しています。ガートナーは、「2025年までに、大企業によるアウトバウンドマーケティングメッセージの30%が機械によって生成される」と 予測しています 。しかし、魅力的な顧客コミュニケーションを実現するには、生成系AIだけでは不十分です。調査によると、最もインパクトのあるコミュニケーションはパーソナライズされたもの、つまり、適切なメッセージを適切なタイミングで適切なユーザーに表示されるものです。 マッキンゼーによると 、「71％の消費者は、企業がパーソナライズされたインタラクションを提供することを期待している」。お客様は、 Amazon Personalize と生成系AIを使用して、マーケティングキャンペーン用の簡潔でパーソナライズされたコンテンツを作成し、広告のエンゲージメントを高め、会話型チャットボットを強化することができます。 開発者は、 Amazon Personalize を使用して、 Amazon.com がリアルタイムでパーソナライズされたレコメンデーションに使用しているのと同じ種類の機械学習（ML）技術を搭載したアプリケーションを構築できます。Amazon Personalizeを使えば、開発者はMLの専門知識がなくても、パーソナライズされた製品やコンテンツのレコメンデーションを通じてユーザーエンゲージメントを向上させることができます。Amazon Personalizeが提供する レシピ （特定のユースケースをサポートするために用意されたアルゴリズム）を使用することで、特定の製品やコンテンツのレコメンデーション、パーソナライズされたランキング、ユーザーのセグメンテーションなど、さまざまなパーソナライゼーションを実現できます。さらに、フルマネージドのAIサービスとして、Amazon PersonalizeはMLを活用したお客様のデジタル変革を加速し、パーソナライズされたレコメンデーションを既存のウェブサイト、アプリケーション、メールマーケティングシステムなどに簡単に統合できるようにします。 この投稿では、Amazon Personalizeと Amazon Bedrock の生成系AIを使用してマーケティングキャンペーンを向上させる方法を説明します。Amazon Personalizeと生成系AIを組み合わせることで、個々の消費者の嗜好に合わせたマーケティングを行うことができます。 Amazon PersonalizeとAmazon Bedrockを具体的にどのように連携させるのでしょうか？マーケターとして、プラットフォーム上でユーザーの行動に基づいて、ユーザーが楽しめそうな映画を推薦するようなカスタマイズされたメールを送りたいと想像してみてください。あるいは、ユーザーが興味を持ちそうな新しい靴を宣伝するために、ターゲットを絞ったメールを送りたいかもしれません。以下の使用例では、生成系AIを使用して2つの一般的なマーケティングメールを改善します。 ユースケース1 : 生成系AIを使用して個人向けにパーソナライズされたメールを届ける Amazon PersonalizeとAmazon Bedrockを使用すると、パーソナライズされたレコメンデーションを生成し、各ユーザーに合わせた送信メッセージを作成できます。 次の図は、生成系AIによってパーソナライズされたメールを配信するためのアーキテクチャとワークフローを示しています。 まず、ユーザーの インタラクション のデータセットをAmazon Personalizeにインポートし、トレーニングを行います。Amazon Personalizeは、 Top Picks for You レシピを使用してモデルを自動的にトレーニングします。出力として、Amazon Personalizeはユーザーの好みに沿ったレコメンデーションを提供します。 以下のコードを使用して、ユーザーにおすすめのアイテムを特定することができます： get_recommendations_response = personalize_runtime.get_recommendations( recommenderArn = workshop_recommender_top_picks_arn, userId = str(user_id), numResults = number_of_movies_to_recommend) 詳細は、 Amazon Personalize API reference を参照してください。 得られたレコメンデーションの出力は、 プロンプト の一部としてAmazon Bedrockに取り込まれます。プロンプトには、ユーザーの特徴、デモグラフィック、Amazon Personalizeのレコメンデーションアイテムが含まれます。 例えば、ユーザーにとって魅力的で楽しいパーソナライズされたEメールを作成したいマーケティング担当者は、次のようなプロンプトを使用するかもしれません： ユーザの興味を引くために魅力的で楽しいパーソナライズされたメールを作成してください。ユーザーは最近ファミリー向けの映画を見ました。リトル・マーメイド、エンカント、スパイダーマン：イントゥ・ザ・スパイダーバースがおすすめのアイテムです。 上のプロンプトを使って下のサンプルコードで、 Claude2 のようなAmazon Bedrockで提供されている基盤モデル(FM)の1つを呼び出すことで、ユーザーにパーソナライズされたメールを作成することができます： personalized_email_response = bedrock_client.invoke_model( body = prompt, modelId = identifier_of_the_model) 詳細は、 Amazon Bedrock API reference を参照してください。 Amazon Bedrockは、ユーザーにパーソナライズされたEメールを返します： 件名 : 映画鑑賞のお供に、お勧めの一本をどうぞ！ <ユーザー名>様 秋の心地よさを感じたいですか？大丈夫です！ソファーでくつろぎながら、大切な人と楽しめるオススメの映画ベスト3です： 1. リトル・マーメイド この古典的なディズニー映画は、人間界を夢見る人魚姫アリエルが主人公。人間界を夢見る人魚姫アリエルは、海の魔女アーシュラと契約し、大きな教訓を得ます。 2. ミラベルと魔法だらけの家 魔法の家に住むコロンビアのマドリガル一家を描いたディズニー映画。一家はそれぞれユニークな才能を持っていますが、幼いマリベルだけは違います。 3. スパイダーマン：イントゥ・ザ・スパイダーバース このスーパーヒーロー・アニメ映画は必見のアクション映画。スパイダーマンであるブルックリンの若者マルズモラレスが、他のスパイダーの力を持つ人物と協力して宇宙を救う。 愛すべきキャラクター、キャッチーな曲、そして感動的なストーリー、この3作品で間違いなし！ポップコーンをどうぞ！ ユースケース2 : 生成AIを使用して多人数向けのマーケティングキャンペーンを強化する 一対多のメールマーケティングでは、一般的なコンテンツではエンゲージメントが低くなる（開封率がの低下や配信停止）可能性があります。これを回避する1つの方法は、魅力的な件名の送信メッセージを手作業で作成することです。これは非効率的な時間の使い方につながります。Amazon PersonalizeとAmazon Bedrockをワークフローに統合することで、興味のあるユーザーセグメントを素早く特定し、関連性とエンゲージメントが高いメールコンテンツのバリエーションを作成することができます。 次の図は、生成系AIによってマーケティングキャンペーンを向上させるためのアーキテクチャとワークフローを示しています。 一対多のメールを作成するには、まず、ユーザーの インタラクション のデータセットをAmazon Personalizeにインポートしてトレーニングします。Amazon Personalizeは ユーザーセグメンテーション レシピを使用してモデルをトレーニングします。ユーザーセグメンテーションレシピを使用すると、Amazon Personalizeは選択されたアイテムに対して興味を示すユーザーをターゲットオーディエンスとして自動的に選定します。 ターゲットオーディエンスを特定し、アイテムのメタデータを取得するには、次のサンプルコードを使用できます： create_batch_segment_response = personalize.create_batch_segment_job( jobName = job_name, solutionVersionArn = solution_version_arn, numResults = number_of_users_to_recommend jobInput = { "s3DataSource": { "path": batch_input_path } }, jobOutput = { "s3DataDestination": { "path": batch_output_path } } ) 詳細は、 Amazon Personalize API reference を参照してください。 Amazon Personalizeは、各アイテムのターゲットとなる推奨ユーザーのリストをbatch_output_pathに出力します。その後、プロンプトと共になにかのFMを使用して、Amazon Bedrockにユーザーセグメントを呼び出すことができます。 このユースケースでは、新しくリリースされたスニーカーをEメールで売り込みたいとします。プロンプトの例は以下のようになります： ユーザーセグメント “sneaker heads “に対して、最新のスニーカー “Ultra Fame II “を宣伝するキャッチーなメールを作成してください。ユーザーに10％割引の割引コード「FAME10」を提供します。 最初のユースケースと同様に、Amazon Bedrockで以下のコードを使用します： personalized_email_response = bedrock_client.invoke_model( body = prompt, modelId = identifier_of_the_model) 詳細は、 Amazon Bedrock API reference を参照してください。 Amazon Bedrockは、各ユーザーが選択したアイテムに基づいて、パーソナライズされたメールを返します： 件名 : <<名前>>, 殿堂入りへの切符があなたを待っている <<名前>>様, 待ちに待った。新しい”Ultra Fame II”をご覧ください！これまでで最も革新的で快適なUltra Fameシューズだ。その新しいデザインは、一歩一歩を踏みしめるたびに、あなたを魅了するだろう。さらに、快適性、サポート性、スタイルがミックスされた、殿堂入りにふさわしいシューズだ。 乗り遅れるな。FAME10というコードを使えば、次の一足が10％割引になります。 最高のエンゲージメントにつながるメールをテストして決定するために、Amazon Bedrockを使用すると、手動でテストコンテンツを作成するのにかかる時間のほんの一部で、キャッチーな件名とコンテンツのバリエーションを生成することができます。 結論 Amazon PersonalizeとAmazon Bedrockを統合することで、パーソナライズされた販促コンテンツを適切なオーディエンスに配信することが可能になります。 FMによる生成系AIは、企業が消費者のためにこれまで以上にパーソナライズされた体験を構築する方法を変えています。Amazon PersonalizeやAmazon BedrockのようなAWSのAIサービスは、ユーザーにパーソナライズされた製品、コンテンツ、魅力的なマーケティングメッセージを推奨し、配信するのに役立ちます。AWS上の生成系AIでの作業の詳細については、 AWS上の生成系AIで構築するための新しいツールを発表 をご覧ください。 翻訳はSolutions Architect近藤が担当しました。原文は こちら です。

このシリーズの 第 1 部 では、 Amazon DynamoDB のデータローディング戦略と短時間実行時の DynamoDB の動作について学びました。この記事では、クエリのパフォーマンスと継続した負荷に対してDynamoDBはどのように対応するかについて学びます。 クエリの実行 任意に大規模なトラフィックを発生させ、現実の動作をシミュレートするために、複数のマルチスレッドクライアントが必要です。これらのクライアントは、各クエリはランダムに生成したIPアドレスを可能な限り速くリクエスト送信します。これらはテーブルが提供できるクエリ容量を消費し、残りはスロットリングされます。これを実現するために、同じ単純なクエリクライアントを実行する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの自動スケーリンググループを作成しました。 クエリテスト: オンデマンドテーブル、単一のパーティションキー値 最初のテストでは、単一の値を持つパーティションキーデザインを使用してデータをロードしたオンデマンドテーブルに対してクエリを実行します。前述のように、この単一パーティションキー値の使用はロード速度を遅くしました。それでは、このパーティションキーがクエリ速度にどのような影響を与えるか見てみましょう。 毎秒 6,000 回の読み取りが一定の速度で行われることが期待されます。データは 1 つのパーティションにあり、各パーティションは 毎秒最大 3,000 の読み取りユニットを持ち、結果整合性のあるクエリはそれぞれ 0.5 の読み取りユニットを消費します。したがって、数学的には毎秒 6,000 回のクエリルックアップを 1 つの非常にホットなスロットリングパーティションに対して達成するはずです。しかし、実際の結果はまったく異なります。 次の図 1 には、テスト開始時と最初の 10 分間の状況が表示されています。 図 1: 1 つのオンデマンドテーブル、1つのパーティションキー値のクエリテスト 図 1 では、このクエリが 4,500 の読み取りユニットを消費しており、これは秒間 9,000 回の結果整合性のあるクエリに相当します。これは期待を上回っています。発生していることは次のとおりです。各パーティションには、冗長性のためにデータが 3 つのノードに広く分散されています。リーダーノードはすべての書き込みを受け取り、2 つのフォロワーノードは迅速にそれに続きます。強力な整合性のある読み取りは常に最新のデータを取得するためにリーダーノードに送信されます。リーダーノードは毎秒 3,000 回の読み取りを処理できるため、パーティションは毎秒 3,000 回の強力な整合性のある読み取りを処理できます。結果整合性のある読み取りは 3 つのノードのいずれかに送られます。3 つのノードがすべてアクティブな場合、パーティションは理論的には毎秒 9,000 の読み取りを処理できます。これがここで見られる結果です。通常の運用中には、 3 つのノードのうち1つが短時間ダウンする場合があります。これは内部メンテナンスのためであったり、クエリに応答できないログレプリカに置き換えられたりします。そのような場合、パーティションは毎秒 6,000 回の結果整合性のある読み取りしか処理できず、これはまだ正常な動作と見なされます。そのため、時折毎秒 9,000 回の結果整合性のある読み取りで実行されることがあるとしても、パーティションが毎秒 6,000 回の結果整合性のある読み取りを維持できると仮定して設計するべきです。 連続してクエリを行うと、10 分後にスループットが急上昇する様子が図 2 に示されています。 図 2: テストを継続するとスループットが 2 倍に増加 スループットは正確に 2 倍に増加しました。DynamoDB は、単一のホットパーティションを検知し、それを 2 つの新しいパーティションに分割することを決定し、スループットキャパシティを 2 倍にしました（そして追加費用は発生しませんでした）。 DynamoDB にはアダプティブキャパシティと呼ばれる機能があり、その中で 頻繁にアクセスされるアイテムを分離 する機能をSplit for heat と呼ばれます。 DynamoDB は、あるパーティションが継続的に高い読み取りまたは書き込みスループットを受け取っているのを観測すると、そのパーティションを 2 つの新しいパーティションに分割することがあります。これにより、これらのアイテムが利用できる読み取りおよび書き込みキャパシティが 2 倍になります。 Split for heat のロジックは、最近のトラフィックパターンに基づいてソートキーの分割ポイントを選択し、その結果として得られる 2 つの新しいパーティションに均等に熱を分散させるように調整されます。分割ポイントはほとんど中央になることはめったにありません。IP アドレスのユースケースでは、分割は最もクエリを受けている IP 範囲を分離することを目的とします。 分割ポイントを選択する際、DynamoDB はテーブルがローカルセカンダリインデックス（LSI）を持っているかどうかを考慮する必要があります。もし LSI が存在する場合、分割ポイントはアイテムコレクション（同じパーティションキーを共有するアイテム）の間のみになります。LSI が存在しない場合、DynamoDB はアイテムコレクション内での分割が可能で、その際には分割ポイントの位置にソートキーの値が使用されます。これにより、同じパーティションキーを持つアイテムが、ソートキーの値に基づいて異なるパーティションに割り当てられる可能性があります。パーティションキーのハッシュはパーティションの配置の最初の要素を提供し、ソートキーの値はその配置をさらに微調整します。IP テーブルが LSI で構築されていた場合、単一のアイテムコレクションはさらなる分割ができないため、ここでの Split for heat はクエリのパフォーマンス向上に寄与しません。 Split for heat は読み取りと書き込みに適用され、高いトラフィックが継続するときはいつでも適用されます。実際、 第 1 部 で単一のパーティションキーを使用してランダムなCSVファイルをロードする際、ロードの終盤でパーティションの分割が観察されました。DynamoDB のこの機能は適応力がありますが、それによってクエリテストがより多くのパーティションで開始され、クエリテストに不当な影響を与える可能性があったため、ベンチマーク時にはそれを望まなかったのです。分割が発生しないようにするため、私はシーケンシャルな CSV ファイルからロードすることを選択しました。なぜなら、DynamoDB の Split for heat のロジックは（常に増加するソートキーの値を持つ単一のパーティションキーなど）、一部のソートキーの値に集中した負荷を検出することが難しく、分割が開始しないようになっているからです。これは timestamp をソートキーなどにした場合が顕著です。単一のパーティションキーに負荷は集中しているが、ソートキーは常に最も値が大きいものだけが書きこみされ一度の負荷しか掛かっていない為です。このような場合もし分割を行っても負荷が分散されません。 テストに戻りましょう。しばらくすると、次の図 3 で示されるように、スループットが再び2倍になります。 図 3: テストを続けると、さらに 2 倍になっている この時点で、データを持つ 2 つのパーティションは両方とも分割され、4 つのパーティションがクエリを処理するようになり、最大レートは 2 倍になりました。 安定した負荷のもとで合計 90 分間実行した後、グラフは次の図 4 のパターンを示しました。 図 4: 90 分間のクエリパフォーマンス 図 4 には注目すべき点がたくさんあります。初期の読み取り速度はパーティションキャパシティの制限によって制約され、Split for heat することでキャパシティを増やすために繰り返しパーティションが追加されました。約 1 時間後、パーティションは限界近くまで分割されました。 分割プロセスの一環として、クエリレートに一時的な低下が生じることがあり、負荷が集中しても毎秒 6,000 回の結果整合性のある読み込みに抑えておき、時々 9,000 回付近まで上がることがあるということを織り込んだ設計にすべきというリマインダーです。また、旧パーティションから新パーティションへの切り替えの時点で、そのパーティションへの書き込み（または強力な整合性のある読み取り）に対して約1秒間の Internal Server Error 応答が発生するのは予想されるものです。これは、パーティションの旧リーダーノードが新しいリーダーノードに移るためです。 テストの最後の30分間には、スループットは最終的にテーブルレベルの読み取りスループット制限で 120,000 RCU に制約されました。すべてのアカウントには、 テーブルに付与できるプロビジョニングされた読み取りキャパシティの制限 があります（書き込みには別の制限があります）。これは、オンデマンドテーブルの最大スループットを制御するために暗黙的に使用されます。ほとんどの AWS リージョンでは、デフォルトで 40,000 読み取りユニットです。テストの前に、テストアカウントのテーブルレベルの読み取りスループット制限を 80,000 読み取りユニットに増やしました。これにより、テーブルの制限が発動する前に分割と倍増を観察する時間が増えました。80,000 読み取りユニットのテーブルで結果整合性のあるクエリを実行すると、上記で説明した 50 パーセントのブーストのおかげで、最大 120,000 読み取りユニットの定常状態を達成できます。 では、真ん中の異常なピークについて話しましょう。 バーストキャパシティ のおかげで、一時的にスループットがテーブルの制限を超えることがあります。これは、アダプティブキャパシティのもう一つの機能であるバーストキャパシティによって、テーブルがキャパシティを借りることができるからです（ベストエフォートベースで）。これが、220,000 読み取りユニット（毎秒 440,000 クエリ）までの大きなピークを作り出す原因です。パーティションはもはやボトルネックではなく、バーストキャパシティが提供および消費され始めました。 許容されるバーストキャパシティは有限であり（このテーブルの場合、80,000 * 300 = 24,000,000 読み取りユニット相当）、その後はテーブルレベルの読み取りスループット制限に基づいてトラフィックが制限されます。 もしクエリの負荷を制限以下に軽減していれば、バーストキャパシティは後で再び蓄積されるでしょうが、クエリレートは常にテーブルがサポートできる最大まで保たれていたため、ラインはテーブルレベルの読み取りスループット制限で平坦に続いています。 もし、強力な整合性のある読み取りを行っていた場合、毎秒 80,000 読み取りが限界です。結果整合性のある読み取りを行っているので、上のセクションで説明した仕組みで追加の 50 パーセントがあり、チャートが示すように、毎秒 120,000 読み取りユニットで実行することができます。 ここで興味深いのは、特別な計画なしに、パーティションキーの値が 1 つだけであり（ベストプラクティスのアドバイスに反して）、1 時間後にはインフラが毎秒 44 万クエリを処理でき、制限はアカウント関連のクォータによるものだけだったということです。アイテム単体のスループットと混同しないでください。ソートキーはランダムの値でクエリを実行しています。パーティションという粒度で負荷は分散されていることを注意してください。 クエリテスト: オンデマンドテーブル、複数のパーティションキー値 2 つ目のテストでは、ベストプラクティスのアドバイスに従い、複数のパーティションキー値を使用します。次に、新しいオンデマンドテーブルを使用してプロセスを開始します。図 5 がそれに続きます。期待される結果は何でしょうか？ 図 5: 200 以上のパーティションキー値を使用したクエリテスト 直ちに、毎秒 15,000 読み取りユニット（30,000クエリ）という高いスループットを達成しました。これは以前の開始時点の 4 倍です。なぜなら、新しく作成されたオンデマンドテーブルに存在する 4 つのパーティションをすべて使用しているからです。トラフィックを高く保ち続けると、パーティションは分割され、その後もさらに分割されます。次に続くのが図 6 です。 図 6: パーティション分割でスループットが向上 パーティションキーが 1 つの場合と同じパターンですが、今回は分割可能なパーティションが 1 つではなく 4 つから始まっています。 最終的なグラフは最初のものと非常に似ていますが、ピークは1時間後ではなく 45 分後に来ています。次に続くのが図 7 です。 図 7：クエリを 1 時間実行した場合のスループット ここからの要点は、パーティションキーを良く分散させる方が良いということです。200 以上のパーティションキーを持つ方が、1 つだけの場合よりも高速にスケールアウトします。 また、アダプティブキャパシティのため、DynamoDB をベンチマークする際には、最初の 5 分で見えるものが 1 時間後にも同じとは限らないということです！ クエリテスト： 毎秒 100 万リクエスト 最後に、毎秒 100 万リクエストを目指したテストで締めくくります。 このために、テーブルに 500,000 の読み取りユニットをプロビジョニングします（これにはデフォルトのアカウントクォータの引き上げが必要です）。これは毎秒 100 万のクエリに十分以上のキャパシティを提供するはずです。テーブルをプロビジョニングしたままにするか、作成後にオンデマンドに切り替えるかは選択できます。ただし、オンデマンドテーブルはプロビジョニングされたテーブルよりもパーティションを積極的に分割する傾向があります。しかし、今回のテストではプロビジョニングされたままにしておきます。その理由の 1 つは、プロビジョニングされたスループットが 50 万読み取りユニットである赤いラインを示すことです。これは基本的には毎秒 100 万のリクエストを実現する目標となります。 次の図は、最初の 15 分間で観測された結果を示しています。 図 8: 500,000 RCU でプロビジョニングされたテーブルに対する、200 以上のパーティションキー値を持つ初期読み取りトラフィック 前述の図 8 に示されているように、最初はテーブルが約 225,000 読み取りユニットまたは毎秒 450,000 クエリを達成しました。テーブルレベルでスループットが制限されていなかったため、私たちの読み取りスループットを制限しているホットパーティションがいくつかあったと推測できます。データをより多くのパーティションキー値に広く分散させ、テーブルのパーティションにより均等にデータを配置するためのより良いメカニズムを見つけるべきでしょうか？理想的にはそうですが、試してみないとわかりません。 図 9: 15 分後の読み取りトラフィックが倍増 前述の図 9 は、Split for heat が 15 分後にスループットを倍増させ、消費された RCU が 470,000 個であることから、最終的には毎秒 940,000 の結果整合性のあるクエリを達成していることを示しています。毎秒 100 万クエリにほぼ達しています。さらに 1 時間経過すると、次に続く図 10 に示されている全体的なトラフィックパターンが生成されます。 図 10: 90 分間の読み取りトラフィック、毎秒 1,440,000 クエリの安定を達成 これは、ほぼ毎秒 150 万クエリの定常状態です。テーブルレベルの読み取りスループット制限の結果、そこで止まったに過ぎないです。 レイテンシはどうでしょう？次の図 11 に示す Amazon CloudWatch のメトリクスで見ることができます。 図 11: CloudWatch のクエリレイテンシのメトリクス CloudWatch は、毎秒 100 万以上のクエリを実行した場合でも、クエリあたり平均 1.72～1.88 ミリ秒と安定していることを報告しています。これはスケール時の一貫したパフォーマンスです。 クエリテスト：まとめ DynamoDB は、パーティションが継続的な読み書きトラフィックを受ける場合、そのパーティションを分割することがあります。これにより、そのパーティション内のアイテムの利用可能なスループットが 2 倍になります。分割ポイントは、最近のトラフィックパターンに基づいて理想的な位置が計算されます。テーブルに LSI が存在する場合、分割ポイントはアイテムコレクション間でのみ設定できます。 プロビジョニングされたテーブルへのトラフィックは、読み取りまたは書き込みキャパシティの設定によって制限される可能性があります。オンデマンドテーブルは、テーブルレベルの読み取りおよび書き込みスループット制限に基づく暗黙の最大プロビジョニングキャパシティがあります。これらの制限は引き上げることができます。 バーストキャパシティにより、一時的にテーブルの制限を超えるトラフィックが可能となります。 高いカーディナリティのパーティションキーを使用すると、アイテムをパーティションにスムーズに割り当てることができ、すべてのパーティションがテーブルのスループットに寄与できます。低いカーディナリティのパーティションキーを使用すると、パーティション間での作業負荷が不均一になる可能性があります。このような状況では、Split for heat が特に有用です。ただし、LSI が存在する場合や、ソートキーが増加し続ける場合など、分割が有益でないと判断された場合は、Split for heat はアイテムコレクション内で行うことはできません。 この記事と 第 1 部 で説明した DynamoDB のスケーリング動作とベストプラクティスのヒントについては、ブックマーク可能なリファレンスガイド 第 3 部 をご覧ください。 作者情報 Jaso n Hunter はカリフォルニアを拠点とする DynamoDB 専門のプリンシパルソリューションアーキテクト。2003 年より NoSQL データベースの開発に従事。Java、オープンソース、XML への貢献で知られる。 Vivek Natarajan は Purdue 大学で CS を専攻しており、AWS のソリューションアーキテクトインターン生である。 (本記事は 2023/01/30 に投稿された Scaling DynamoDB: How partitions, hot keys, and split for heat impact performance (Part 2: Querying) を翻訳した記事です。翻訳は SA 鈴木が担当しました。)

Amazon DynamoDB の一般的な原則は、高いカーディナリティのパーティションキーを選択することです。しかし、なぜそのようにすべきなのか、そしてそうしなかった場合の影響は何か？お客様のユースケースをもとに、この疑問に深く迫り、異なるパーティションキーの設計とテーブルの設定を使用して DynamoDB のロードおよびクエリのパフォーマンスを調査します。 各実験の後、生成されたパフォーマンスグラフを分析し、私たちが観察したパターンを説明し、繰り返しの改善イテレーションを通じて、DynamoDB の内部構造の基礎を紹介し、パフォーマンスの高いアプリケーションを構築するためのベストプラクティスを紹介します。テーブルのパーティション、パーティションキー値、ホットパーティション、Split for heat、バーストキャパシティ、およびテーブルレベルのスループット制限についても説明します。 この 3 部構成のシリーズでは、まず初めに探究する問題を紹介し、データロードの戦略と短時間の DynamoDB 実行時の挙動に焦点を当てます。 第 2 部 では、クエリのパフォーマンスと継続した負荷に対して DynamoDB はどのように対応するかについて説明します。このシリーズは、学びとベストプラクティスをまとめた 第 3 部 で終了します。 AWS の試算によれば、今回調査するソリューションは非常にスケーラブルであり、アイテムの読み取りにかかるコストは約 0.18 ドル、継続的なストレージコストは月額 0.05ドルであり、完全に柔軟なオンデマンドモードでは 1 ドルで 800 万回の検索が可能です。最初はゆっくりとした読み取りから始め、最終的には平均レイテンシが 2 ミリ秒以下で数百万回のリクエストを処理している状態になります。 お客様の使用例: IPアドレス検索 この投稿は、高いカーディナリティのパーティションキーの重要性に関するお客様の質問に触発されました。多くの DynamoDB のユースケースでは、自然で明白な高いカーディナリティのパーティションキー（例: 顧客 ID や資産 ID など）がありますが、今回のケースは異なります。Accenture Federal Services は私たちに連絡して、IP アドレスのメタデータ検索サービスを設計したいと伝えました。彼らのデータセットは何十万もの IP アドレス範囲から成り、各範囲には開始アドレス（例: 192.168.0.0）、終了アドレス（例: 192.168.10.255）、および関連するメタデータ（例: 所有者、国、適用するセキュリティルールなど）が含まれていました。彼らのクエリは IP アドレスを受け入れ、それを含む範囲を見つけ、メタデータを返す必要がありました。 Accenture Federal Services が知りたかった事： このルックアップサービスにおいて DynamoDB がどの程度有効か。 どのようなテーブル設計が最適か。 実行時間、コスト、スケーラビリティの観点から最も効率的な設計は何か。 DynamoDB が達成できる 1 秒あたりの理論的な最大ルックアップ数はどのくらいか。 彼らはまた、自分たちのユースケースが古典的な DynamoDB のユースケースのように見えないことを懸念していました。彼らは、それがパフォーマンスを制限するかどうかを知りたかったのです。 この投稿では、これらの問題に取り組み、これらの質問に答えます。 ルックアップアルゴリズム テーブルを設計する前に、基本的なアルゴリズムを用意することが重要です。このアルゴリズムは、IP アドレスを受け入れ、効率的にそのアドレスを含む範囲を特定する必要があります。 DynamoDB のテーブルスキーマには、パーティションキーとオプションのソートキーがあります。追加の属性が存在するかもしれませんが、それらは（セカンダリインデックスに配置されない限り）インデックスされません。 パーティションキーとソートキーに詳しくない場合は、まず DynamoDB の基礎 を学ぶことをお勧めします。動画が好きな方は、「 DynamoDB: Its purpose, main features, and key concepts 」と「 DynamoDB: Under the hood, managing throughput, advanced design patterns 」をご覧いただくとよいでしょう。 DynamoDB からデータを取得する 1 つの方法は、 Query 操作を実行することです。 Query はさまざまなことができますが、その 1 つは、パーティションキーが正確に指定され、ソートキーが不等式で指定された（パーティションキーが X に等しく、ソートキーが Y に等しくない）アイテムを取得することです。IP を IP 範囲から検索するために Query を使用できます。ただし、データが次の 2 つの条件を満たしている場合です: データセット内の IP 範囲は重なってはいけません。これは本質的な条件であり、そうでなければデータセットは曖昧になります（同じ IP が複数のメタデータエントリを持つ可能性があるため）。 IP 範囲は隙間なくすべての IP アドレスを完全に記述しています。これは常に成り立つわけではありません。なぜなら、一部の IP 範囲は特に予約されていてメタデータを持っていないためです。しかし、合成範囲を使用してこの仮定を真にすることができます。合成範囲はメタデータが利用できないことを示すペイロードでギャップを埋めることができます。 各 IP 範囲は DynamoDB 内のアイテム（行）として保存できます。今のところ、単一の固定パーティションキー値（すべてのアイテムで同じ値）と、範囲の開始 IP アドレスに等しいソートキー値を仮定しましょう。以下の図 1 は、このデータモデルを示しています（後でこのデータモデルを改善します）。 図 1：固定パーティションキーを使用したデータモデル Query はパーティションキーが 0 に等しく、かつソートキーが検索対象の IP アドレス以下であるアイテムを後方にスキャンし、 結果を 1 つに限定 することで見つけることができます。最初に一致した項目が、返すべきメタデータです。重複やギャップがないことが分かっているので、終了範囲の値を考慮する必要はありません。以下は、 AWS Lambda 関数のテスト実行を示す Python コードです: import json import boto3 from boto3.dynamodb.conditions import Key client = boto3.resource('dynamodb') table = client.Table('IPAddressRanges') def lambda_handler(event, context): pk = '0' ip = event.get('ip') response = table.query( KeyConditionExpression=Key('PK').eq(pk) & Key('SK').lte(ip), ScanIndexForward = False, Limit = 1 ) print(response['Items'][0]) このアルゴリズムがどのように機能するのか理解するのに苦労している場合は、視覚的な表現が助けになるかもしれません。田舎にあるフェンスがあり、そこにはランダムな間隔でたくさんのフェンスの支柱が立っていると想像してください。フェンスに沿って歩く特定の距離に対応するフェンスの区間を見つけたいとします。この問題を解決するためには、まずその距離だけ歩き進み、それから後ろに向かって歩いてフェンスの支柱に遭遇します。そのフェンスの支柱には、その区間に関するメタデータがすべて含まれています。各フェンスの支柱は、それに続く区間を説明しています。反対側のフェンスの支柱には、それに続く区間のメタデータが含まれています。もしフェンスに隙間がある場合、その隙間の直前のフェンスの支柱には「ここに隙間がある」と記されています。 ただし、1 つのパーティションキー値だけを使用すると、クエリは簡単になりますが、これは DynamoDB のパーティションキー値間のカーディナリティを高くするベストプラクティス に直接反してしまいます。これに関する影響をテストしてみましょう。 データ形式 テストを実行するには、まず実際のデータ形式を考慮する必要があります。ソースデータは CSV ファイルにあり、1 行に 1 つの IP 範囲が記載されており、ギャップやオーバーラップはありません。各行には開始および終了の IP 値とメタデータが含まれています。以下は、可読性を高めるために空白を追加した模擬例です: Netblock , start , end , metadata 1.0.0.0/24 , 1.0.0.0 , 1.0.0.255 , Range 1.0.0.0/24 metadata 1.0.1.0/24 , 1.0.1.0 , 1.0.1.255 , Range 1.0.1.0/24 metadata 1.0.2.0/23 , 1.0.2.0 , 1.0.3.255 , Range 1.0.2.0/23 metadata 1.0.4.0/22 , 1.0.4.0 , 1.0.7.255 , Range 1.0.4.0/22 metadata 1.0.8.0/21 , 1.0.8.0 , 1.0.15.255 , Range 1.0.8.0/21 metadata 1.0.16.0/20 , 1.0.16.0 , 1.0.31.255 , Range 1.0.16.0/20 metadata 1.0.32.0/19 , 1.0.32.0 , 1.0.63.255 , Range 1.0.32.0/19 metadata 1.0.64.0/18 , 1.0.64.0 , 1.0.127.255 , Range 1.0.64.0/18 metadata 1.0.128.0/17 , 1.0.128.0 , 1.0.255.255 , Range 1.0.128.0/17 metadata 開始 IP 文字列をソートキーとして使いたくなるかもしれませんが、文字列を数字のように扱うのは危険です。.100 が .1 と .2 の間にくることがあります。1.0.32.0 が 001.000.032.000 になるように、値にゼロパッドするのが 1 つの解決策です。数字が常に3 桁である場合、文字列と数字は同様にソートされます。 もっと良い方法があります: 各 IP アドレスをその自然な数値に変換することです。IP アドレスはほとんどの場合、1.0.32.0 のようなドット付き 4 進数形式で書かれていますが、これはあくまで人間にとって分かりやすい表現です。基本的に、IP アドレス（IPv4 の場合）は単一の 32 ビットの値です。 IP アドレス 1.0.32.0 を 2 進数に変換すると（ただし、可読性のためにピリオドは保持されます）、00000001.00000000.00100000.00000000 となり、これを 10 進数に変換すると 16,785,408 になります。これがソートキーとして使用される番号モデルです。不等式演算がシンプルで効率的であり、かつ ストレージがコンパクト です。 次に続く図 2 は、IP アドレスを数値に変換した後のテーブルがどのように見えるかのスニペットです。 図 2: IP アドレスを数値に変換したテーブル ローディング さて、テストを開始する準備が整いました。まずは、ロード性能から始めます。CSV ファイルは、シンプルなループを使用したシングルスレッドの Python スクリプトでロードします。すべてのテスト結果は us-east-1 リージョンから収集されました。 ロードテスト: オンデマンドテーブル、シーケンシャルな CSV、単一のパーティションキー 最初のテストとして、新しく作成されたオンデマンドテーブルに対して一括ロードを実行します。CSV ファイルからロードし、Python コードによってすべてのアイテムに同じパーティションキーを割り当て、IP 範囲の文字列を数値に変換します。CSV ファイルのデータは IP 範囲でソートされており、低い IP が先頭にあることに留意してください。このような順序は CSV ファイルで一般的であり、後の実験で重要となります。次に示す図 3 は、その結果です。 図 3: 最初のロードテストの結果：オンデマンドテーブル、シーケンシャルな CSV、単一のパーティションキー 図 3 に示されているように、最初のロードテストは毎秒 1,000 書き込みユニットの安定したレートで実行されます。残りの書き込みリクエストは制限されています。 裏側で何が起こっているかを以下に説明します: すべての DynamoDB テーブルは複数の物理パーティションに分散されています。各物理パーティションは毎秒 3,000 の読み取りユニットと毎秒 1,000 の書き込みユニットをサポートできます。1 つのパーティションキー値を使用することで、すべての書き込みが 1 つのパーティションに送信され、それがボトルネックを引き起こしています。 新しいオンデマンドテーブルが 1 つのパーティションしか割り当てないことを意味するわけではありません。オンデマンドテーブルは常にライブトラフィックに適応し、新しく作成されたオンデマンドテーブルは最大で 4,000 の書き込みリクエストユニットおよび 12,000 の読み取りリクエストユニットを提供できると記載されています。詳細については、「 読み取り/書き込みキャパシティーモード 」を参照してください。 これらのスループット性能は、まさに 4 つのパーティションを持つテーブルと同じです。つまり、4 つのパーティションが利用可能でも、単一のパーティションキー値を使用しているため、すべてのトラフィックはそのうちの 1 つのパーティションに割り当てられ、他の 3 つのパーティションは非アクティブなままです。 データがどのようにパーティションに割り当てられるかを簡単に復習しましょう: 各パーティションは、テーブルのキースペースのサブセットを担当します。パーティションキー値はハッシュ化され、数値に変換されます。そして、その数値を含む範囲のパーティションが、そのパーティションキー値の読み取りまたは書き込みを処理します。パーティションキー値が常に同じであれば、一般的に同じパーティションがすべての読み取りと書き込みを処理します。異なるパーティションキーが同じ数値範囲の一般領域にハッシュすることがあり、その場合、その範囲を処理するパーティションに配置されます。パーティションは分割でき、そのアイテムを 2 つの新しいパーティションに移動し、数値範囲に新しい分割ポイントを導入できます。パーティションはアイテムコレクション内で分割できる場合もあります（同じパーティションキー値を持つアイテム間で）、その場合、ソートキーは分割ポイントの計算に考慮されます。 しかし、1 つのパーティションキー値を使うと、最初はすべてのアイテムが同じパーティションに配置されるため、書き込みが大幅に制限されます。 ロードテスト: オンデマンドテーブル、シーケンシャルな CSV、複数のパーティションキー データを複数のパーティションキー値に分散させれば、ロードを高速化できます。例えば、IP アドレスの最初の部分をパーティションキー値として選択することができます。例えば、192.168.0.0 はパーティションキーが 192 になります。これにより、書き込みが 200 以上のパーティションキー値に分散され、作業がパーティション間でより均等に分散されるはずです。 クエリを調整して IP 範囲に基づいて正しいパーティションキーを指定し、範囲がパーティションキーの境界を越えないようにローダーを調整する必要があります。そうでなければ、コアロジックが失敗します。新しいテーブルデザインは、次に続く図 4 のようになります。 図 4: 各 /8 アドレス範囲に対する異なるパーティションキーを示すテーブルデザイン 次に続く図 5 は、ロードテスト中のパフォーマンスを示しています。 図 5: 2 回目のロードテストの結果: 今回は多くのパーティションキーを使用 ロードは毎秒約 1,250 回の書き込みに改善されました。なぜそれ以上ではないのか、なぜ作業がパーティション間でうまく分散されないのか。それは CSV ファイルが順次処理されているからです。各パーティションキー値に対応する何千もの範囲が次から次へと続いています。あるパーティションが一時的にすべてのトラフィックを処理し、そして別のパーティションが、また別のパーティションが順にトラフィックを処理します。十分に均等に広がっていません。唯一の改善点は、パーティションキー値が切り替わり、新しいパーティションがスロットリングされるパーティションとして順番に割り当てられるときです。 このケースからの教訓は、順次処理された CSV ロードはトラフィックをうまく分散しないということです。 ロードテスト： オンデマンドテーブル、ランダムなCSV、複数のパーティションキー CSV ファイルのエントリの順序をランダムにすると（ファイルを調整するか、Python ローダー内で内部的なシャッフルを行う）、ロードをより均等に分散させ、パフォーマンス向上が期待できます。次に示す図 6 は、我々のテスト結果を示しています。 図 6: 3 回目のロードテストの結果: 今回は行をランダム化した CSV ファイルを使用 このテストは 2 分未満で終了しました。最初と最後のタイミングは部分的なものであり、秒単位のレートを推測することはできません。完全に測定された中央の 1 分間では、毎秒約 3,600 回の書き込みに達しました。これは4つのパーティションが効果的に利用されていることとよく一致しています。データの書き込み順序をランダムにするだけで、書き込みスループットが大幅に向上しました。 これらの理由から、CSV ファイルの行が（つまり、パーティションキー値でグループ化されている）パーティションキー値でソートされている場合は、CSV のロードをランダムにすることが重要です。 また、もしソースデータが他の DynamoDB テーブルの Scan の結果である場合は、ロード前にソースデータをランダムにすることが役立ちます。なぜなら、 Scan で返されるアイテムは自然にパーティションキーのハッシュ値でグループ化され、ロード中に安定したヒートマップが生成される可能性があるからです。 ロードテスト： プロビジョニングされたテーブル、ランダムなCSV、複数のパーティションキー ここまでのテストはすべて、新しく作成されたオンデマンドテーブルを対象としていました。では、10,000 の書き込みキャパシティユニット（WCU）でプロビジョニングされたテーブルをテストしてみましょう（シンプルにするため、オートスケーリングは有効にしません）。引き続きランダムな CSV ファイルを使用します。次に示す図 7 は、私たちが観測した結果です。 図 7: 4 回目のロードテストの結果: 10,000 WCU でプロビジョニングされたテーブルを使用 ロードは1分未満で完了しました。すべてのアクティビティは、毎秒約 6,000 回の書き込みで、1分未満のデータポイントに集約され、その1分間のピークはこれを上回っていました。 10,000 WCU で新たにプロビジョニングされたテーブルは、新しいオンデマンドテーブルよりもパーティションが多く必要です（この書き込み負荷を処理するためには少なくとも10のパーティションが必要です）。そして、これらの追加のパーティションに多くのパーティションキー値を分散させることで、パフォーマンスを向上させることができました。 これはプロビジョニングがオンデマンドよりも優れているという意味ではありません。なぜなら、オンデマンドは素早くトラフィックに応じて キャパシティとパーティションを調整し、増やしていく からです。ただし、オンデマンドテーブルのデフォルトサイズは10,000 WCU 未満です。テーブルが最初から高いトラフィック負荷を受けると予想される場合は、新しいオンデマンドテーブルを特定の初期キャパシティでプロビジョニングし、それを後でオンデマンドに切り替えることでテーブルを事前にウォームアップすることをお勧めします。 ローディングテスト: まとめ 最大の負荷率は、物理パーティションの数、パーティションキー値の数、そして負荷がパーティション全体にわたって作業を並列化する能力に依存します。より多くのパーティションは負荷率を増加させる傾向がありますが、パーティションが最も有益なのは、十分なパーティションキー値が作業をパーティション全体に分散させ、かつロードのロジックが作業をパーティションキー値にわたって分散させる場合です。 第 2 部 では、クエリのパフォーマンスと、継続した負荷に対して DynamoDB はどのように対応するかについて探求します。 まとめ この 3 部構成のシリーズでは、異なるパーティションキー設計を使用してロードおよびクエリのパフォーマンスをテストすることで、DynamoDB の内部について学びました。テーブルのパーティション、パーティションキーの値、ホットパーティション、Split for heat、バーストキャパシティ、およびテーブル全体のスループット制限について説明しました。 いつものように、ご質問やフィードバックはコメントでお気軽にどうぞ。 作者情報 Jaso n Hunter はカリフォルニアを拠点とする DynamoDB 専門のプリンシパルソリューションアーキテクト。2003 年より NoSQL データベースの開発に従事。Java、オープンソース、XML への貢献で知られる。 Vivek Natarajan は Purdue 大学で CS を専攻しており、AWS のソリューションアーキテクトインターン生である。 (本記事は 2023/01/30 に投稿された Scaling DynamoDB: How partitions, hot keys, and split for heat impact performance (Part 1: Loading) を翻訳した記事です。翻訳は SA 鈴木が担当しました。)

重要な情報は Amazon FSx for Windows File Server 上に保存された Windows ファイルシステムなどのソースを含め、組織内の複数のデータソースに散在している可能性があります。 FSx for Windows File Server 用の Amazon Kendra コネクタ を使用して、FSx for Windows File Server 上の Windows ファイルシステムに保存されているドキュメント (HTML、PDF、MS Word、MS PowerPoint、およびプレーンテキスト) にインデックスを付け、 Amazon Kendra のインテリジェント検索を使用してこれらのコンテンツ全体の情報を検索できるようになりました。 組織は、共有 Windows ファイルシステム上のファイルに非構造化データを保存し、Windows アクセスコントロールリスト (ACL) を使用して、企業の Active Directory (AD) ドメインで設定されたアクセス権限に従って、ユーザーがファイルを読み取り、書き込み、作成できるようにすることで、それを保護します。このデータから特定の情報を見つけるには、ファイルを検索するだけでなく、ユーザーにアクセス権限があることを確認する必要があります。FSx for Windows File Server 用の Amazon Kendra コネクタは、FSx for Windows File Server に保存されたファイルにインデックスを付け、Amazon Kendra インデックスに ACL を取り込むことで、ユーザーによる検索クエリのレスポンスに、そのユーザーが読むことを許可されたドキュメントからの結果のみが含まれるようにします。 この投稿では、FSx for Windows File Server で ACL を使用してファイルシステムにセキュアに保存された一連のドキュメントを例にしています。これらのドキュメントは、コネクタを使用してこのファイルシステムをインデックスのデータソースとして構成および同期することで、Amazon Kendra インデックスに取り込まれます。そして、ユーザが検索クエリを実行すると、Amazon Kendra インデックスは、ユーザが所属するユーザ名とグループに基づいた ACL を使用し、ユーザがアクセスすることを許可されたドキュメントのみを返すことを実証します。また、設定の詳細と各段階のスクリーンショットが含まれているため、Amazon Kendra コネクタ for FSx for Windows File Server をセットアップする際の参考資料としてご利用ください。 前提条件 Amazon Kendra コネクタ for FSx for Windows File Server を試すには、以下が必要です: AWS Identity and Access Management (IAM) ロールおよびポリシーを作成する権限を持つ AWS アカウント 。詳細については、 アクセス管理の概要: アクセス許可とポリシー を参照してください。 AWS の基本的な知識と、Windows ACL および Microsoft AD ドメイン管理の実務知識。 FSx for Windows File Server上のファイルシステムへの管理者アクセス権、およびそのファイルシステムが属するADドメインへの管理者アクセス権。あるいは、 FSx for Windows File Server のクイックスタート を使用して、これをデプロイすることもできます。 AWS_Whitepapers.zip は、機能を試すために使用します。最新版については、 AWS Whitepapers & Guides を参照してください。または、独自のドキュメントを使用することもできます。 ソリューション・アーキテクチャ 次の図は、ソリューション・アーキテクチャを示しています: この例のドキュメントは、 FSx for Windows File Server (図中の4) 上のファイルシステム (3) に保存されています。ファイルは、FSx for Windows File Server が属する AWS Directory Service (1) を使用して作成された AD ドメインのユーザーとグループの構成に基づいて、ACL で設定されています。この FSx for Windows File Server 上のファイルシステムは、Amazon Kendra (5) のデータソースとして設定されます。 AWS Single Sign On (AWS SSO) は、AD をアイデンティティソースとして有効化され、Amazon Kendra インデックスは、顧客の検索ソリューションデプロイメント (6) からの検索クエリのユーザーコンテキストのユーザー名とグループ検索に AWS SSO (2) を使用するように設定されている。この例で設定された FSx for Windows File Server ファイルシステム、AWS Managed Microsoft AD サーバー、 Amazon Virtual Private Cloud (Amazon VPC)、およびサブネットは、 FSx for Windows File Server のクイックスタート を使用して作成されます。 FSx for Windows File Server の設定 次のスクリーンショットは、FSx for Windows File Server 上のファイルシステムが、Amazon FSx のコンソールで見たように、この例で使用されている AWS Managed Microsoft AD ドメインの一部として設定されていることを示しています。 AWS Managed Microsoft AD の設定 FSx for Windows File Server が属する AD は、以下の Directory Service コンソールのスクリーンショットのように、AWS Managed Microsoft AD として設定されています。 サンプルデータセットのユーザー、グループ、ACL 設定 この投稿では、いくつかの AWS 公開ホワイトペーパーからなるデータセットを使用し、FSx for Windows File Server 上のファイルシステム上のカテゴリ ( Best_Practices 、 Databases 、 General 、 Machine_Learning 、 Security 、 Well_Architected ) に基づいたディレクトリに格納しました。以下のスクリーンショットは、ファイルシステムが属する AD ドメインの一部である Windows bastion ホストから見たフォルダを示している。 ユーザーとグループは AD ドメインで以下のように設定されています: kadmin – group_kadmin patricia – group_sa 、 group_kauthenticated james – group_db_sa 、 group_kauthenticated john – group_ml_sa 、 group_kauthenticated mary、julie、tom – group_kauthenticated 次のスクリーンショットは、AWS Managed Microsoft AD ドメインに設定されたユーザーとグループを、Windows bastion ホストから見たものです。 各ディレクトリのファイルの ACL は、FSx for Windows File Server が属する AD ドメインのユーザーとグループの構成に基づいて設定されます: すべての認証済みユーザー (group_kauthenticated) – Best_Practices と General ディレクトリのドキュメントにアクセス可能 ソリューションアーキテクト (group_sa) – Best_Practices 、 General 、 Security 、および Well_Architected ディレクトリのドキュメントにアクセス可能 データベース分野の専門ソリューションアーキテクト (group_db_sa) – Best_Practices 、 General 、 Security 、 Well_Architected 、 Database ディレクトリのドキュメントにアクセス可能 機械学習分野の専門ソリューションアーキテクト (group_ml_sa) – Best_Practices 、 General 、 Security 、 Well_Architected 、 Machine_Learning の各ディレクトリにアクセス可能 管理者 (group_kadmin) – 6つのディレクトリのいずれのドキュメントにもアクセス可能 以下のスクリーンショットは、Windows bastion ホストから見た、サンプルデータの各ディレクトリの ACL 構成を示している。 AWS Single Sign-On の設定 AWS SSO は、AD ドメインを ID ソースとして構成されています。以下のスクリーンショットは AWS SSO コンソールでの設定です。 以下のスクリーンショットのように、AD から AWS SSO でグループが同期されます。 以下のスクリーンショットは、AD から同期された group_kauthenticated グループのメンバーを示しています。 Amazon Kendra コネクタ for FSx for Windows File Server を使用したデータソースの設定 Amazon Kendra コンソール上の Amazon Kendra インデックスに、Amazon Kendra コネクタ for FSx for Windows File Server を使用してデータソースを構成します。 新しい Amazon Kendra インデックスを作成する ことも、既存のインデックスを使用して新しいデータソースを追加することもできます。 Amazon Kendra インデックスにデータソースを追加する場合、 Amazon FSx の下の Add connector を選択して FSx for Windows File Server コネクタを選択します。 データソース名とリソースタグを追加する手順は、以下のスクリーンショットに示すように、他のデータソースの追加と同様です。 Amazon FSx 上の特定のファイルシステムとファイルシステムのタイプ (この場合は FSx for Windows File Server) を構成するための詳細は、 Source セクションで構成されます。ファイルシステムの管理者権限を持つユーザーの認証情報は、 AWS Secrets Manager のシークレットを使用して構成されます。 データソース設定の VPC とセキュリティグループの設定には、Amazon FSx と AD サーバーの VPC、サブネット、セキュリティグループの詳細が含まれます。次のスクリーンショットでは、データソース用に新しい IAM ロールも作成しています。 データソース構成の次のステップでは、Amazon FSx コネクタフィールドを Amazon Kendra ファセットまたはフィールド名にマッピングします。次のスクリーンショットでは、設定を変更しないままにしています。この後のステップでは、設定を確認し、データソースを作成することを確認します。 サンプルデータがデータソースとして保存されている FSx for Windows File Server 上のファイルシステムを構成した後、このデータソースに対してカスタムドキュメントエンリッチメント (CDE) の基本操作を構成し、ドキュメントが保存されているディレクトリに基づいて Amazon Kendra インデックス filed_category が構成されるようにします。データソースの同期は CDE 構成の後に開始され、取り込みワークフロー中にドキュメントの _category 属性が構成されるようにします。 次のスクリーンショットに示すように、Amazon Kendra インデックスのユーザーアクセスコントロール設定は、AWS SSO 統合を通じてユーザーとグループを検索するために構成されています。Amazon Kendra Search コンソールからユーザー名とグループ名に基づいて検索するために、JSONトークンベースのユーザーアクセスコントロールが有効になっています。 Amazon Kendra インデックスのファセット定義で、 _category に facetable と displayable のボックスがチェックされていることを確認します。これにより、CDE の基本操作で設定された _category の値を検索時にファセットとして使用することができます。 Amazon Kendraでの検索 データソースの同期が完了したら、Amazon Kendra コンソールのナビゲーションペインで Search indexed content を選択して、Amazon Kendra Search コンソールから検索を開始します。今回は Amazon Kendra のインデックスに取り込むデータセットとして AWS のホワイトペーパーを使用しているため、検索クエリとして “What’s DynamoDB? ” を使用しています。FSx for Windows File Server 上のファイルシステム上のファイルへのアクセスは、認証されたユーザにのみ許可されているため、ユーザ名やグループを設定せずにこの検索クエリを使用すると、結果が得られません。 まず、ユーザ名を mary@kendra-01.com に設定しましょう。ユーザ mary は group_kauthenticated に属しているので、 Best_Practices ディレクトリと General ディレクトリのドキュメントにアクセスする権限があります。以下のスクリーンショットでは、検索応答にファセット category が Best Practices と General に設定された文書が含まれています。CDE の基本操作は、 source_uri に含まれるディレクトリ名に応じてファセット category を設定します。これにより、FSx for Windows File Server 用のコネクタによって Amazon Kendra に取り込まれた ACL が、ユーザー名に基づいた検索結果で実施されていることが確認できます。 ここで、ユーザー名を patricia@kendra-01.com に変更します。ユーザー patricia は group_sa に属し、 Best_Practices と General ディレクトリに加えて、 Security と Well_Architected ディレクトリにアクセスできます。検索応答には、これらの追加ディレクトリからの結果が含まれます。 次のスクリーンショットで、ユーザ名を james@kendra-01.com 、 john@kendra-01.com 、 kadmin@kendra-01.com に変更すると、検索応答の結果がどのように変化するかを観察できます。 クリーンアップ Amazon Kendra コネクタ for FSx for Windows File Server を試すために AWS インフラストラクチャをデプロイした場合は、以下のようにインフラストラクチャをクリーンアップします: FSx for Windows File Server のクイックスタート を使用した場合は、作成した AWS CloudFormation スタックを削除し、作成したリソースをすべて削除します。 新しい Amazon Kendra インデックスを作成した場合は、そのインデックスを削除します。 コネクタを使用して新しいデータソースを追加しただけの場合は、そのデータソースを削除します。 AWS SSO 設定を削除します。 結論 Amazon Kendra コネクタ for FSx for Windows File Server は、非構造化コンテンツに散在する情報のセキュアでインテリジェントな検索を可能にします。データは、ACL を使用して FSx Windows File Server 上のファイルシステムに安全に保存され、Microsoft AD ドメイン資格情報に基づいてユーザーと共有されます。 Amazon Kendra コネクタ for FSx for Windows File Server の詳細については、 Amazon FSx データソース (コンソール) を使い始める と Amazon FSx でデータソースを使用する を参照してください。 カスタムドキュメントエンリッチメントについては、 取り込みプロセスでドキュメントのメタデータをカスタマイズ と、 Amazon Kendra のカスタムドキュメントエンリッチメントによってコンテンツとメタデータを充実させて検索体験を向上させる を参照してください。 この記事の翻訳はソリューションアーキテクトの林 航平が担当しました。原文は こちら です。 著者について Abhinav Jawadekar は Amazon Web Services のシニアパートナーソリューションーキテクトです。AWS パートナーのクラウド・ジャーニーを支援しています。

セキュリティの脅威がより高度化し、その脅威が広がりやすくなるにつれ、お客様はより Amazon CloudFront と AWS WAF を使用して、Web アプリケーションと API のパフォーマンス、回復性、セキュリティを向上させています。 CloudFront はコンテンツ配信ネットワーク (CDN) で、CloudFront の数百のエッジロケーションのうち、ユーザーに最も近い場所からデータを配信することで、世界中のユーザーの待ち時間を短縮します。 AWS WAF は Web アプリケーションファイアウォールで、一般的なエクスプロイトや望ましくないボットの通信トラフィックから Web アプリケーションを保護するために、悪意のあるリクエストを Web サーバーに到達する前に分析・ブロックします。 お客様は CloudFront と AWS WAF を使用してアプリケーションを保護できます。 ただし、開発者、スタートアップ、中小企業は、1)どのセキュリティ保護を有効にするのか、2)セキュリティルールを作成する方法、3)単一の IP アドレスから異常な数のリクエストが発生した時にその共通ログパターンを特定するなどの手法について、セキュリティの専門家に相談できないことがよくあります。 こうしたお客様は、CloudFront 内のシンプルで管理が容易なセキュリティを含め、アプリケーションの安全を確保する方法について追加のガイドを求めることが多いのです。 ここで、 CloudFront セキュリティダッシュボード のご利用開始を発表いたします。これは AWS WAF の可視性とコントロールを CloudFront ディストリビューションに直接提供する統合エクスペリエンスです。 対話型のセキュリティダッシュボードは、可観測性、調査ツール、使い勝手の良い設定インターフェースを組み合わせたもので、簡潔で直感的で便利に使用できます。 サービスコンソールを行ったり来たりすることなく、アプリケーション配信とセキュリティを1か所で管理 アプリケーションの上位のセキュリティトレンド、許可/ブロックされたトラフィック、ボットアクティビティの可視性に優れる ビジュアルログ分析機能を使用してログのクエリを実行することなく、トラフィックパターンをすばやく理解 セキュリティルールを記述することなく、組み込みのブロックコントロールを使用してインラインでアクションを実行 17種類以上のカテゴリに基づいて、許可またはブロックするボットを制御することで、望ましくないボットを防止 この投稿では、次の図に示すように、CloudFront セキュリティダッシュボードを使用してアプリケーションをセキュリティで保護するためのエンドツーエンドのワークフローについて説明します。 まず、コアセキュリティ保護を有効にし、セキュリティ推奨事項を確認して有効にし、アプリケーションを HTTP フラッドから保護する方法を学習します。 次に、組み込みレポートを使用したトラフィックのモニタ方法、ボットからの保護方法、異常なトラフィック パターンの調査方法、およびセキュリティルールの作成をすることなくインラインで軽減を適用する方法を学習します。 ディストリビューション用に AWS WAF がすでに有効になっている場合は、いずれかの CloudFront ディストリビューション 内の新しい Security タブに移動して、履歴メトリクスを含む新しいセキュリティ ダッシュボードの調査を開始します。 それ以外の場合は、この投稿の手順に従って AWS WAF のセキュリティ保護を有効にすることで、メトリクスの収集を開始できます。 図1 – CloudFront セキュリティダッシュボード セキュリティ保護の有効化、推奨事項の確認、HTTPフラッドへの対応 アプリケーションのセキュリティを確保する最初のステップは、新規または既存のディストリビューションに対してセキュリティ保護を有効にすることです。 これらの手順に従う際、適切な場合は推奨される保護が表示されることがあります。 この投稿では、AWS WAF が有効になっているお客様も手順に従えるように、推奨事項の有効化を個別のステップとして分離しています。 Amazon CloudFront コンソールを開きます。 Create distribution を選択してディストリビューションを作成し、保護したいオリジンを入力します。 また、既存のディストリビューションの場合は、ディストリビューションの Security タブに移動して Edit を選択します。 Web Application Firewall(WAF) セクションで、料金の見積もりを確認し、 Enable security protections を選択します。 残りのディストリビューション設定を確認し、 Create distribution を選択するか、既存のディストリビューションを編集している場合は Save changes を選択します。 CloudFront は、アプリケーションに推奨される AWS の標準保護機能を有効にした状態で AWS WAF を自動的に作成および構成します。 含まれているコアのセキュリティ保護機能では、Amazon の内部の脅威インテリジェンスに基づいて潜在的な脅威からの IP アドレスをブロックしたり、OWASP Top 10 で説明されている Web アプリケーションで最も一般的な脆弱性から保護したり、悪意のある者がアプリケーションの脆弱性を発見することから防御したりします。 セキュリティ推奨事項の確認と有効化 図2 – 有効化されたセキュリティ保護機能 CloudFront は、該当する場合に既存構成の要素を利用して適切なセキュリティ推奨事項を提供します。セキュリティタブで Edit ボタンを選択してセキュリティフォームに移動し、ディストリビューションに追加したい推奨セキュリティルールを有効化します。次の図に示す例では、CloudFront を使用して WordPress アプリケーションを高速化および保護しています。 WordPress 専用の保護機能を有効にするために、WordPress の保護チェックボックスにチェックを入れます。 図3 – セキュリティ構成の編集による推奨機能の有効化 さらに、HTTP フラッディングなどのボリューム攻撃からアプリケーションを保護するために、推奨されるレート制限ルールを使用することをお勧めします。前の図を参考にレート制限のチェックボックスに単純にチェックを入れるだけで、こうした攻撃を緩和できます。 レートは各アプリケーション固有のものであるため、CloudFront がアプリケーションの適切なレートを設定および微調整して、これらの攻撃を軽減するのに役立ちます。 有効化後、レート制限はブロックせずにモニターモードでメトリクスをキャプチャします。 レート制限ルールのメトリクスは、次の図に示す Security – Web Application Firewall (WAF) コンテナーのレート制限セクションで確認できます。 レートを超えた場合、 Monitor mode – rate exceeded のテキストを選択すると、レートがどのくらい頻繁に超過したかが表示されます。 また、必要に応じてレートを調整し、準備ができたらブロッキングを有効にすることもできます。 図4 – 上位のレート超過リクエスト アプリケーションのセキュリティを監視および改善する CloudFront のセキュリティダッシュボードは、セキュリティトレンド、ボットリクエスト、リクエストログの 3 つの可視化セクションに分かれています。 セキュリティトレンドセクションでは、トラフィックの概要を一目で確認できます。 総トラフィック、許可/ブロックトラフィックの比率、攻撃タイプ、クライアントの場所などの変化をすばやく把握できます。 特定の国からのトラフィックをブロックしたい場合は、次の図にあるようにその国をマウスオーバー表示してトグルをブロックに設定することができます。 図5 – 上位の攻撃タイプと発信元の国 ボットのコントロール 2番目のセクションのボットリクエストでは、アプリケーションにアクセスしているボットに関する情報が表示されます。 ボット保護が無効な場合、このセクションは、リクエストサンプリングに基づいて、トラフィックのどれだけがボットから来ているかを示します(次の図を参照)。 図6 – サンプリングされたボットトラフィックの概要 AWS WAF の Bot Control を有効にすることで、ボット保護を選択できます。これは、自己識別ボットにラベルを付け、一般的な望ましいボットかを検証し、高信頼度のボットシグネチャを検出する共通の保護レベルを提供します。これにより、リクエストサンプリングではなく、実際のリクエストに基づいて、カテゴリー別に詳細なボットアクティビティを確認できます。多くのお客様は、インフラストラクチャコストを下げるためにボットをブロックすることを選択しています。 ボットトラフィックの詳細な可視性を確認し、許可またはブロックするボットを制御するには、 Manage bot protection ボタンを選択し、 Enable Bot Control for common bots をチェックして、 Save changes をクリックします。 図7 – ボット保護を有効にする設定画面 Bot Control を有効にすると、各未検証ボットがボットカテゴリごとにどのように処理されるかを構成するオプションが表示され、詳細なメトリクスが表示されます。次の図では、未検証の非ブラウザユーザエージェント、HTTP ライブラリ、SEO ボットはモニターモードになっている一方で、リンクチェッカーとセキュリティボットはそれぞれ チャレンジまたは CAPTCHA を受け取ります。 AWS によって既知の一般的で検証可能なボット(たとえば、既知の検索エンジンクローラー)は、ここで設定したアクションの対象にはなりません。 Bot Control は、これらのボットが主張するソースから来ていることを確認する検証を実行してから、検証済みとしてマークします。 図8 – ボット保護有効時の詳細なメトリクスを確認する Bot Requests セクション 画面上で検索、フィルタリング、ログを検査する 最後に、特定のトラフィックパターンを隔離するために、ログを詳細に調査したいと考えるかもしれません。 たとえば、特定のトラフィックがどこから来ているか、最も要求されている URI パスは何かなどです。 最終セクションの Request Logs は、ログクエリを書いたり CloudFront コンソールを離れたりせずにそのような質問に答えるのが簡単になるように設計されています。 ログが有効になっていない場合は、予想されるリクエスト数に基づいて、ログを有効にする価格を見積もるために、組み込みの価格計算機を使用します。 ログを有効にするには、次の図に示すように Enable AWS WAF logs をチェックし、 Enable を選択します。CloudFront は CloudWatch ロググループを作成し、CloudWatch にログを記録するように AWS WAF 設定を更新します。 図9 – AWS WAF のログを有効化する 数分以内にログデータが流れ始めているのが見えます。 個々のリクエストに続いて、HTTP メソッド、上位 URI パス、上位 IP アドレス、上位国別の集計が視覚的に表示されます。 これにより、たとえばリクエストの異例なボリュームが単一の IP アドレスから発生している場合や、特定の URI パスを対象としている場合、またはこれまでログに表示されなかった国から発信されている場合など、すぐにパターンを視覚的に把握できます。 IP アドレス、国、ユーザエージェント、 URI パスなどの属性に基づいてリクエストをフィルタリングし、望ましくないトラフィックを特定するのに役立ちます。 特定されると、個々のリクエストまたはビジュアライゼーションを選択し、悪意のあるトラフィックを直ちにブロックするアクションを実行します。 たとえば、次の図に示すように IP アドレスをポイントしてブロックするなどです。 図10 – Requests logs の表示画面 利用と価格 CloudFront セキュリティダッシュボードは、各 CloudFront ディストリビューションに追加料金なしで含まれています。 CloudFrontコンソールの任意のディストリビューションの Security タブを選択することでアクセスできます。 追加のインサイトと構成オプションは、AWS WAF コンソールで利用できます。 ダッシュボードを介して作成された Web ACL には標準の AWS WAF 料金が適用され、ダッシュボードを介してクエリされたメトリックとログには標準の CloudWatch 料金が適用されます。 インラインでのセキュリティ保護の設定中に、構成可能な価格見積もりが提供されます。 価格設定の詳細については、AWS WAF の料金 と CloudWatch の料金 を参照してください。 CloudFront は、毎月 1 TB のデータ転送と 1,000 万 HTTP(S) リクエストを無料で提供しています。 Amazon Simple Storage Service (Amazon S3) や Application Load Balancer(ALB) などのAWSオリジンをCloudFrontの背後に使用している場合、オリジンフェッチのデータ転送は無料です。 詳細については、 Amazon CloudFront の料金 を参照してください。 まとめ CloudFront セキュリティダッシュボードの導入により、一般的なセキュリティ脅威からアプリケーションを保護および監視するためのシンプルで便利な方法が得られました。この投稿では、CloudFront セキュリティダッシュボードを使用してアプリケーションを確保および監視する方法を学びました。 コアのセキュリティ保護と推奨事項を有効にし、HTTP フラッドから保護し、ログで異常を視覚的に特定し、トラフィックをブロックする方法を学びました。 さらに、ボットを監視し、どのボットがアプリケーションにアクセスできるかを制御する方法を学びました。 CloudFront と AWS WAF の詳細については、 CloudFront デベロッパーガイド と AWS WAF デベロッパーガイド を参照してください。 この記事は、 Introducing CloudFront Security Dashboard, a Unified CDN and Security Experience  を翻訳したものです。 このブログの翻訳は Solutions Architect の加藤知愛が担当しました。

ID 管理は、適切なユーザーがテクノロジーリソースに適切にアクセスできるようにするためのポリシーとテクノロジーのフレームワークです。 Amazon Connect インスタンスの ID 管理は、次の 3 つの方法のいずれかで設定できます。 Amazon Connect にユーザーを保存する方法 既存のディレクトリにリンクする方法 SAML 2.0 ベースの認証を使用する方法 Amazon Connect は、 Security Assertion Markup Language (SAML) 2.0 による ID フェデレーションをサポートしているため、お客様の組織から Amazon Connect インスタンスへのウェブベースのシングルサインオン (SSO) が可能になります。 これにより、ユーザーは 1 つの ID とパスワードで複数のアプリケーションに安全にアクセスできます。 Amazon Connect において、既定では Amazon Connect インスタンスから ID プロバイダー (IdP) への 1:1 のマッピングが可能です。 多くの場合、企業の環境には複数の ID プロバイダー (IdP) があり、様々なアプリケーションに固有のユースケースに対応したり、プライマリ IdP に障害が発生した場合のバックアップメカニズムとして使用したりしています。 このブログ記事では、単一の Amazon Connect インスタンスに追加の ID プロバイダを設定するために必要な手順について詳しく解説します。 ソリューション概要 Amazon Connect インスタンスに追加の IdP を設定するために必要な手順の概要を以下に示します。 お使いの SSO 環境に、追加する SAML ID プロバイダー (IdP) 用の Amazon Connect SSO アプリケーションを作成します。 追加の SAML IdP 用に、AWS IAM でアイデンティティプロバイダリファレンスを作成します。 新しい IdP を含むように信頼関係を更新することで、既存の SAML IdP で使用されている既存の IAM ロールを再利用します。 Amazon Connect の修正されたロールを使用するように SAML IdP アプリケーションを設定します。 Amazon Connect で両方の IdP アプリケーションを使用して SSO をテストします。 このブログ記事では、IdP の例として Okta と AWS Identity Center を使用していますが、この手順は SAML 2.0 準拠のすべての ID プロバイダー に適用されます。 ハイレベルなアーキテクチャ図 シーケンス図 以下の図は、SAML リクエストが行き交う手順を詳しく示しています。 ユーザーは Amazon Connect にログインするためのリンクを含む内部ポータルを参照します。 フェデレーションサービスは組織の ID ストアに認証を要求します。 ID ストアはユーザーを認証し、認証レスポンスをフェデレーションサービスに返します。 認証が成功すると、フェデレーションサービスは SAML アサーションをユーザーのブラウザに送信します。 ユーザーのブラウザは SAML アサーションを AWS サインイン SAML エンドポイントに送信します。 AWS サインインは SAML リクエストを受け取り、リクエストを処理してユーザーを認証し、認証トークンを Amazon Connect に転送します。 Amazon Connect は AWS からの認証トークンを使用してユーザーを認証し、ユーザーのブラウザで Amazon Connect を開きます。 追加の IdP を設定するための前提条件は、既存の SAML 2.0 IdP を持つ Amazon Connect インスタンスがすでにセットアップされていることです。 ステップ 1: お使いの SSO 環境で、追加 IdP 用に Amazon Connect SAML アプリケーションを設定する このステップでは、追加の SAML IdP 内に Amazon Connect アプリケーションを作成し、メタデータをエクスポートします。 SAML 2.0 IdP で Amazon Connect アプリケーションを作成し、デフォルトリレーに以下のように入力します。 https://<リージョンID>.console.aws.amazon.com/connect/federate/<インスタンスID> <リージョンID> は Amazon Connect インスタンスのリージョン（例えば米国東部（バージニア北部）の場合は us-east-1）に置き換えてください。 アプリケーションのメタデータをエクスポートします。 IdP でアプリケーションを作成して IdP メタデータを取得する詳細な方法については、IdP のドキュメントを参照してください。 ステップ 2: IAM で追加の IdP 用の ID プロバイダーリファレンスを作成する このステップでは、IAM 内に追加 IdP 用の ID プロバイダー設定を作成します。 IAM コンソール を開きます。 「 アクセス管理 」で「 ID プロバイダー 」を選択します。 「 プロバイダを追加 」を選択します。 [ SAML ] を選択します。 [ プロバイダ名 ] にプロバイダーの名前を入力します。 例: AWSIdentityCenter-SSO-Agent IAM Identity Center または SSO アプリケーションからダウンロードしたメタデータファイルをアップロードします。 [ プロバイダを追加 ] を選択します。 ID プロバイダーを開き、ARN を書き留めます。 ステップ 3: プライマリ IdP の既存の IAM ロールを編集して、追加の IdP を追加する (信頼関係を編集) このステップでは、プライマリ IdP の Amazon Connect ユーザーに関連付けられている既存のロールを再利用し、新しい ID プロバイダーを参照するように信頼関係を編集します。 AWS アカウントの IAM に移動します。 「 ロール 」を選択します。 プライマリ IdP に使用されている既存の IAM ロールを選択します。 「 信頼関係 」を選択し、「 信頼ポリシーを編集 」 を選択します。 追加の IdP の ID プロバイダーの ARN を追加します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": [ "arn:aws:iam::<AWSアカウントID>:saml-provider/AWSIdentityCenter-SSO-Agent", "arn:aws:iam::<AWSアカウントID>:saml-provider/Okta_Connect_Agent" ] }, "Action": "sts:AssumeRoleWithSAML", "Condition": { "StringEquals": { "SAML:aud": "https://signin.aws.amazon.com/saml" } } } ] } ロール ARN をメモします。「 IAM 」> 「 ロール 」 から該当のロールを選択すると確認できます。 ステップ 4: Amazon Connect の修正されたロールを使用するように SAML IdP アプリケーションを設定する このステップは、お使いの SSO ID プロバイダーによって異なります。以下の手順は AWS Identity Center IdP 用です。 お使いの SSO IdP 内で IAM ロールを参照する方法の詳細については Amazon Connect SSO Setup Workshop を参照してください。 IAM Identity Center に管理者としてログインします。 「 アプリケーションの割り当て 」にある「 アプリケーション 」を選択します。 Amazon Connect SSO アプリケーション名を選択します。 「 アクション 」を選択します。 「 属性マッピングを編集 」を選択します。 [ 新規属性マッピングを追加 ] を選択し、以下を設定します。 「 https://aws.amazon.com/SAML/Attributes/Role 」のユーザー属性を追加し、「<コピーしたIdPロールARN>,<コピーしたIAM IDプロバイダ ARN>」と設定します。 変更を保存します。 ユーザーをアプリケーションに割り当てます。 ステップ 5: Amazon Connect で両方の IdP アプリケーションを使用して SSO をテストする プライマリ SSO IdP にログインして Amazon Connect を起動します。 追加の SSO IdP にログインして Amazon Connect を起動します。 結論 この投稿では、追加の SAML 2.0 ID プロバイダーを追加して Amazon Connect インスタンスを強化する方法を学びました。 つまり、プライマリ IdP に問題が発生した場合でも、ユーザーは代替 ID プロバイダーを使用して Amazon Connect インスタンスに簡単にログインできるため、アクセスが中断されることはなく、シームレスなカスタマーエクスペリエンスを確保できます。 Amazon Connect の詳細については、 Amazon Connect のドキュメントを参照してください。 著者略歴 Mo Miah は Amazon Connect を専門とするソリューションアーキテクトです。彼は 16 年以上コンタクトセンターテクノロジーに関わってきた経験があります。 イギリスのロンドンにて、お客様が Amazon Connect の強力な AI/ML 機能を活用することでビジネス上の成果を達成できるよう支援することを楽しんでいます。 仕事以外では Mo はアクティブでいることを楽しんでおり、2 人の若い娘がいるので忙しくしています。 Sutapa Dasgupta は、Amazon Connect を専門とする AWS プロフェッショナルサービスのシニアコンサルタントです。 彼女は、大規模なコンタクトセンターの設計とクラウド移行、およびクラウド上でカスタマーエンゲージメントワークロードをモダナイゼーションするお客様のご支援経験があります。 翻訳はソリューションアーキテクト遠藤が担当しました。原文は こちら です。

この記事は Firework simplifies live ecommerce with Amazon IVS (記事公開日: 2023 年 4 月 10 日) を翻訳したものです。 ショッパブルビデオのスタートアップは、マネージド型ライブストリーミングサービスを採用して大規模環境での安定性を実現 消費者の行動と期待値は、大きく変化しました。この変化に対し、小売業者はライブストリームビデオなどの画期的な技術を使って顧客とのつながりを深め、買い物客がお気に入りのブランドに関わる方法を変えています。上手に活用すれば、これらのビデオはマネタイズ可能であり、ライブショッピングと呼ばれるライブストリーム e コマースには大きな収益機会があります。 Statista によると、2022 年の米国におけるライブショッピングの売上高は 170 億ドルと推定されており、2026 年までに 550 億ドルに達すると予測されています。これは、アジアですでに行われているもののごく一部に過ぎません。2021 年の マッキンゼーの報告書 によると、中国のライブストリームショッピングは 30 億ドルから 1,710 億ドルに成長しました。2017 年から 2020 年の間に、中国のライブコマース市場の価値は年平均成長率 (CAGR) 280% 以上で成長しました。 ショッパブルビデオのスタートアップで AWS パートナーの Firework は、 Amazon Web Services (AWS) を利用することで、ウェブサイトやアプリにライブ、およびオンデマンドビデオを簡単かつ迅速に統合できるダイナミックなプラットフォームを提供し、ブランドやクリエイターがこのトレンドを活用できるように支援しています。高品質と低レイテンシーが最も重要であるため、Firework は Amazon Interactive Video Service (Amazon IVS) を使用してライブコンテンツを配信しています。Amazon IVS は、インタラクティブなビデオ体験を迅速かつ簡単にセットアップできるように設計されたマネージド型ライブストリーミングソリューションです。プラットフォームを構築するためのソリューションを探す際、 Firework は、低レイテンシー、グローバルなスケーラビリティ、モバイルブロードキャスト用のソフトウェア開発キット (SDK) を理由として Amazon IVS を選択しました。 ※上記イメージの動画バージョンは、 原文 をご覧ください。 「ライブストリーミングをサードパーティのサイトに依存しているブランドは、それら企業の開発サイクルのなすがままになっており、エクスペリエンスの提供が制限されています。この機能を Web サイト内でネイティブに構築するには、バックエンドに 1 行のコードを追加するだけです。これにより、戦略に役立つ豊富な情報が手に入ります」と、Firework の CTO である Rick Zhuang 氏は説明します。「スピードと安定性は、ポジティブなライブストリーム体験に不可欠です。それ以下では取引が成り立たなくなります。AWS は高く評価されており、テクノロジーのグローバルリーダーです。Amazon IVS が当社のライブストリームを支えることで、お客様は世界中の大勢の視聴者に優れた体験を提供でき、シームレスな小売取引が可能になります。」 AWS 上に構築された Firework は、2020 年に初めてショッパブルビデオプラットフォームとして実装されました。このサービスは、37 カ国以上の幅広いブランドからすぐに採用されるようになりました。ライブ配信では最大 20 倍の ROI 向上効果があり、サイト滞在時間は最大 282% 増加、コンバージョン率は最大 307% 向上しています。1 秒あたり最大 900 万件のトランザクションをサポートできるこのプラットフォームは、AWS リソースの可用性を最大限に活用し、ライブストリーミング、ショートビデオホスティング、ニアリアルタイムの在庫トラッキング、インタラクティブなチャットと投票、トランザクション機能などをナビゲーションしやすいブラウザベースのインターフェイスに組み込んでいます。 Firework プラットフォームでは、ブランドが配信される前に、配信中に紹介したい購入可能なアイテムのリストを作成できます。また、Amazon IVS metadata API を介して、動画に同期されたインタラクティブな要素を段階的に配置することもできます。これにより、視聴体験をコンテンツの展示と最適なアライメントに保つことができます。また、Firework では、顧客やホストが Amazon IVS broadcast SDK を使用して携帯電話で簡単にライブ配信を行えるよう、再利用可能なライブ配信を含む録画済みのショッパブルビデオをホストできます。ライブコンテンツの不正使用や拡散を防ぐために、 Firework は Amazon IVS の再生認証機能を使用し、開発者が JSON Web Tokens (JWTs) で保護されたプライベートチャンネルを起動できるようにしています。 「コンテンツを視聴している人が誰で、彼らがどのように反応するかを把握できることは非常に有益です。Firework のユーザーは、視聴率だけでなく、コメント、投票、クイズの回答からも重要な情報を収集することができます。このソリューションを使用することで、さまざまな製品や配信ホストなどの変化を比較し、将来のライブ配信を微調整することができます」と Zhuang 氏は述べています。 Firework のシンプルな実装は、社内に開発リソースがない小規模なブランドにとって特に役立ちます。プラットフォームのコードをユーザーのウェブサイトやアプリに統合すれば、その全機能を使用するのは、ソーシャルメディアへの投稿を作成するのと同じくらい簡単です。さらに、プラットフォームの料金設定は視聴時間に基づいており、始めたばかりの企業のコストを最小限に抑え、実験を促します。 「結局のところ、私たちはデジタルストアフロントを再定義しつつあり、それが e コマースを変えるでしょう。一部のレガシーな小売業者のサイトは 10 年以上変わっていませんが、今では多くの人々が、インターネットを動画コンテンツを中心に利用しています。私たちのビジョンは、静的な画像の代わりに、スワイプ可能なインタラクティブな動画をサイトに掲載し、ショッピング体験を向上させることです」と、Zhuang 氏は締めくくります。 Amazon IVS に加えて、Firework プラットフォームは AWS Elemental MediaLive (MediaLive) を使用しています。MediaLive は高品質なストリームを作成する放送局レベルのライブ動画処理サービスで、 Instagram や Facebook などのサードパーティの SNS プラットフォームにライブストリームを再配信することで、顧客に真にグローバルな体験を提供しています。このプラットフォームでは、 Content Delivery Network (CDN) サービスである Amazon CloudFront も使用しており、AWS の Points of Presence (POP) を使用して、低遅延かつ高速な転送速度で安全にコンテンツを配信しています。 Amazon IVS による魅力的なライブストリームとインタラクティブな動画体験の構築の詳細は、 当社のウェブサイト をご覧ください。 AWS Partner spotlight Firework は、ライブストリームとショッパブルビデオを通じて、ブランドのデジタルストアフロントにライブコマースを提供します。 Amazon Interactive Video Service (Amazon IVS) によって支えられている Firework のビデオコマースソリューションは、ブランド、小売業者、出版社に対し、相互作用とコミュニティエンゲージメントをシームレスかつ大規模に促進する、簡単にデプロイできるライブストリームショッピングテクノロジーを提供します。   この記事は、Josh Walters と Akshara Shah によって書かれた Firework simplifies live ecommerce with Amazon IVS の日本語訳です。翻訳は、ソリューションアーキテクトの髙橋伸幸が担当しました。

2023 年 5 月アマゾン ウェブ サービス ジャパン合同会社 （以下、AWSジャパン）と新潟県は、 地域産業の活性化に向けて、 スタートアップ支援、デジタル人材の育成を軸とした DX を加速する包括的な連携を発表 しました。スタートアップ支援、地域産業のデジタルトランスフォーメーション支援、デジタル人材の育成支援、県行政の DX 支援、の 4 つの支援を軸として、県全体の包括的な DX に連携して取り組んでいくこととしています。 AWS と、AWS の認定トレーニングパートナーである トレノケート は、新潟県の地域のリーダーを育てる新しい取り組み、NINNO ACCADEMIA において、AWSのクラスルームトレーニング Developing on AWS を提供しました。今回はその取り組みをご紹介します。 写真左から、新潟県知事 花角 英世 氏、AWSジャパン代表執行役員社長 長崎 忠雄 「変革と挑戦　選ばれる新潟」の実現に向けた取り組み 新潟県では、首都圏への人口流出の加速、高齢化等の地域課題を解決するため、「変革と挑戦　選ばれる新潟の実現」を掲げて、スタートアップの創出、地域産業のDX化、デジタル人材の育成に力を入れています。具体的には、スタートアップ・IT企業の集積を目指すイノベーション拠点 NINNO （ニーノ）をオープンし、 J-Startup NIIGATA をはじめとした、地域のスタートアップや起業家人材育成支援等を行っています。 2023年10月に、NINNO において、DX 推進、起業家、CTO など地域のリーダーを目指す人材を育てることを目的とした人材育成事業 NINNO ACCADEMIA が開講されました。起業を志す人とスタートアップ、大手企業、行政、大学機関などが交流し、ヒト・モノ・カネの循環が生まれるイノベーションのエコシステムを新潟で創出していくことを目的としています。同事業は国土交通省の「インキュベーション施設等都市間連携プロジェクト」にも選定されており、2025 年までに累計 1800 人の受講者数を目指しています。 新潟発イノベーション人材育成に向けてー CTO人材の輩出も目指すNINNO ACCADEMIAー NINNO ACCADEMIA をリードされている、BSN アイネット執行役員 イノベーション推進室長の坂田 源彦 氏は、NINNO ACCADEMIA について、以下のように述べています。 「IT 活用が広まる中で、新潟における IT 人材は枯渇してきており、人材の争奪戦になっています。そんな中で、社会課題をなんとかしたいと考える地域のリーダーを育てる目的でこちらの NINNO ACCADEMIAを構想しました。新潟の地域・社会課題を解決していく人材を育てるために、様々なプログラムを提供しています。AWS トレーニングを提供しようと考えたきっかけは、2023 年 5月の AWS と新潟県の包括連携協定です。AWS を使う人口は新潟では多く、AWS  ユーザーコミュニティである JAWS-UG の 新潟支部 の活動も活発です。 DERTA を始め、エンジニアコミュニティ作り・ネットワーキング活動が活発化してきており、そういった動きを加速していく狙いもあります。 CTO 人材を育成していくという狙いもありますから、AWS は、初級ではなく中級レベルのトレーニング Developing on AWS を敢えて選びました。このプログラムでは、令和 7 年度までにCTO を 3 人輩出することも目標にしています。」 NINNO ACCADEMIA 開校式の様子 新潟県 産業労働部 創業・イノベーション推進課 鈴木 純一 氏に、本取り組みの背景についてお伺いしました。 「新潟県では、県内の企業のオープンイノベーション、大企業、スタートアップ、行政や大学のオープンイノベーションを加速させることを目指し、各プレイヤーが交わる場所であるイノベーション拠点 NINNO の取組を支援してきました。県としてもエンジニアコミュニティの形成や人材育成に力を入れており、連携協定締結後は、 DERTA と連携して AWSのハンズオンなどを開催 してきました。 今回の NINNO ACCADEMIA は、拠点を運営する 木山産業 、 けんと放送 、 BSNアイネット を始め、地元の民間企業が主導で立ち上げ、AWS にも協力いただけることになり、地域のイノベーションエコシステムが循環する非常に良い流れと考えています。行政としてもこの流れを後押しし、『変革と挑戦、選ばれる新潟の実現』を加速させていきたいです。」 クラスルームトレーニング Developing on AWSとは？ 今回は、数ある AWS の クラスルームトレーニング のうち、デベロッパー向けの中級コースの Developing on AWS を提供しました。2013年より、AWSの 認定トレーニングパートナー として、 AWS Training Partner of the Year – Global Awardを2年連続で受賞 している トレノケート の高山 裕司 氏がインストラクターを務めました。 クラスルームトレーニングコースマップ Developing on AWS コースの概要 このコースは、AWS の認定インストラクターから、AWS のサービスと AWS SDK や AWS CLI などのデベロッパーツールを使用して、安全でスケーラブルなクラウドアプリケーションを開発する方法を学ぶのに役立ちます。コードを使用して AWS を操作する方法について詳しく説明します。また、主要な概念、ベストプラクティス、トラブルシューティングのヒントについても説明します。この 3 日間のクラスルームトレーニングコースでは、プログラムで AWS のサービスを利用して、ウェブソリューションを構築する方法を学びます。 学習目標 AWS ソフトウェア開発キット (AWS SDK)、Command Line Interface (AWS CLI)、および IDE を使用して、シンプルなエンドツーエンドのクラウドアプリケーションを構築する 開発環境をサポートするための AWS Identity and Access Management (IAM) 許可を設定する アプリケーションで複数のプログラミングパターンを使用して AWS のサービスにアクセスする AWS SDK を使用して、Amazon Simple Storage Service (Amazon S3) および Amazon DynamoDB リソースで CRUD (作成、読み取り、更新、削除) 操作を実行する その他 インストラクターを務めた高山 氏は、今回トレーニングを提供した感想として、以下のように述べています。「この度は弊社をトレーニングパートナーにお選びいただき、大変嬉しく思います。オンラインだけではなく、地域のイノベーションを担っていくというモチベーションの高い受講者様と実際にお会いすることで、より濃密なトレーニングをご提供できたと思います。こうした取り組みが、その地域ならではの課題の解決や、イノベーションを進めていくことに繋がると感じられて非常に意義があると感じています。」 Developing on AWS トレーニングの様子 受講者の一人である リンクチャネル株式会社 の鈴木 優紀 氏は、受講の感想についてこのように述べています。 「私はもともと業務で AWS を使う立場でしたが、自力で業務の中で勉強していくことに限界を感じていました。会社として AWS を使っていく方向性だったので、体系的に学ぶ非常によい機会と考え、受講しました。なんといっても、新潟県のお墨付きで AWSのトレーニングが提供されるため、勤務時間内でやることに関して会社にもすぐ納得いただけました。 実際に受講してみて、知らないこと、例えば Amazon CloudWatch などの運用やオブザーバビリティが軽視されがちなことなど、講義の形できっちり教わらないとできないことがあると実感しました。 コースの内容のうち、7-8 割は使ったことがあるサービスでしたが、自己流でやっていたところの裏付けができて非常によかったですし、今回初めて教わった Amazon Dynamo DB  と Amazon API Gateway などは早速業務で活用できる場面がでてきそうです。業務をしながら学んですぐ実装できるのは、事業会社ならではのメリットですね。AWSが新潟県と連携協定を結んでこうして講座が提供され、地場のユーザー企業としては非常に力強く感じます。」 おわりに いかがでしたでしょうか。今回は、新潟県のイノベーション人材育成講座  NINNO ACCADEMIA への Developing on AWS の活用事例についてご紹介しました。 AWS は今後も、様々な地域でイノベーションを担う人材育成をご支援していきます。ご紹介した Developing on AWS 以外にも、多様なレベルのAWS トレーニングをご用意しております。ご関心のある方は、お気軽に こちら よりお問い合わせください。ご連絡をお待ちしております！ このブログは、 アマゾンウェブサービスジャパン合同会社 パブリックセクター シニア事業開発マネージャーである岩瀬 霞が執筆しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 12月に入り、re:Invent 2023も無事終了しました。私自身は仕事の関係でラスベガスに滞在していたのですが、例年にもましてお客様の熱気が凄く圧倒されてしまいそうになりました。たくさんのアップデートも発表されましたので、まだキャッチアップできていないと言う方は まとめWebinarの資料や録画 をご覧ください。 もっと細かく深掘りするスタイルの振り返りセミナーも開催予定です。 業界カット のものと、 ソリューションカット のものがありますので、こちらもぜひよろしくお願いします。 それでは、12 月 4 日週のアップデートを振り返ってみましょう。 2023 年 12 月 4 日週の主要なアップデート 12/4(月) Amazon SageMaker Canvasで包括的なデータ準備機能が利用可能に コーディング不要で機械学習による予測や、基盤モデルをすぐに利用できるAmazon SageMaker Canvasのデータ準備機能が強化されました。50以上のデータソースからデータをインポートし、300種類以上が用意されている組み込み演算子を利用してデータ準備が可能です。専門的な知識なしに作業に取りかかれるので、データ活用に取り組むハードルを引き下げ、より幅広い方にデータ活用にチャレンジいただけます。 Amazon RedshiftでSUPER型のカラムサイズが最大16MBに Amazon Redshiftで半構造化データやドキュメントを格納するためのSUPERデータ型で、最大データサイズが1MBから16MBに拡張されました。1MBを超えるデータを格納する場合も、事前処理なくそのままRedshiftに取り込んで分析処理を実行できます。 12/5(火) AWS Console Mobile App for iOSでAmazon Qがプレビュー可能に 生成系AIベースのアシスタントサービスであるAmazon QがiOS向けのAWS Console Mobile Appでもご利用いただけるようになりました。現時点ではプレビューの扱いです。質問をテキストで入力したり、音声入力で質問すると、AWSに関する疑問に対する回答を得ることが可能です。 Amazon Rekognitionで精度とレイテンシが改善されたFace APIバージョン7をリリース Amazon Rekognitionが提供するFace APIのバージョン7がリリースされ、顔検出・比較・検索の精度がさらに向上し、レイテンシーが短縮されました。精度向上とレイテンシ短縮はユーザエクスペリエンスの向上につながることがメリットです。 AWS DMSが移行ターゲットとしてAmazon RDS for Db2をサポート AWS DMS(Database Migration Service)が移行先ターゲットとして、Amazon RDS for Db2がサポートされました。オンプレミス環境やEC2で独自に構築したDb2環境をマネージドサービスに移行することが容易になります。なお、フルロードとCDC(Change Data Capture)の双方に対応しています。 12/6(水) AWS Lambdaでスケールアップが12倍高速に AWS Lambdaのスケールアップ速度が向上し、アカウント単位で設定されたLambda functionに対する同時実行数の上限にヒットしない範囲で、10秒ごとに1,000同時実行のスピードでスケールアップが可能になりました。変動の大きいトラフィックであり、一定時間以内に応答を返さなければいけない、といったユースケースで嬉しいアップデートです。 Amazon QuickSightのSPICEエンジンが並列データ取り込みに対応し最大4倍高速に Amazon QuickSightのインメモリエンジンであるSPICEのデータ取り込み速度が最大4倍高速になりました。この高速化は並列取り込みに対応したことによるものです。特に大規模なデータセットの取り込みで効果的です。特に設定変更は必要なく、起動時に自動で有効化されます。 Amazon EC2 Instance ConnectがRHEL/CentOS/macOSに対応 EC2インスタンスに安全に接続する方法、Amazon EC2 Instance Connectの対応OSが拡張されました。従来から利用可能だったAmazon Linux, Ubuntuに加えて、RedHat Enterprise Linux(RHEL), CentOS, macOSでご利用いただけるようになりました。Amazon EC2 Instance Connectを利用するとインスタンスへの接続可否をIAMポリシーで制御したり、AWS CloudTrailでアクセスログを取得できるので、管理が容易なところがポイントです。 12/7(木) AWS IoT SiteWiseのデータを可視化するダッシュボードをノーコードで作成可能に オープンソースのIoTダッシュボードアプリケーションを新たに発表しました。このツールはIoT Application Kit上に構築されており、ドラッグアンドドロップの操作でAWS IoT SiteWiseから収集したデータを可視化することが可能です。 GitHubリポジトリはこちら です。 AWS Lambda関数とAmazon RDS, Amazon RDS Proxyへの接続が簡単に AWS Lambdaのコンソールを利用して、Lambda関数をAmazon RDSまたはAmazon RDS Proxyに接続できるようになりました。ガイド付きのワークフローが提供され、それに従う形で既存のデータベースインスタンスやRDS Proxyに接続できます。VPC周辺の設定やAWS Secrets Managerで管理されるシークレット情報を手動で行う必要がなくなり、便利かつ安全に作業を実行できます。 12/8(金) Amazon CloudWatchでアカウントをまたいでMetrics Insightを利用可能に Amazon CloudWatchは複数のアカウントにまたがって可観測性(オブザーバビリティ)を提供する機能がありますが、今回新たにMetrics Insightを利用できるようになりました。CloudWatch Metrics Insightは大量のメトリクスデータの分析に利用できるSQLエンジンです。複数アカウントのメトリクスに対して利用可能になったことにより、これまでよりも広範な分析が可能になるだけでなく、複数の要素を加味してアラーム発報するような仕組みを作れることも嬉しいポイントです。 週刊AWSのアイキャッチ写真を撮影したのが、今年の3月だということに気づきました。新メンバーを迎えた新体制にもなっていますので、そろそろ写真を撮り直さないとなと思っています。近いうちに新しい写真に切り替わる（といいな）と思いますので、ご期待ください。 ソリューションアーキテクト 小林 正人 (twitter – @maccho_j )

本ブログは Amazon QuickSight を使用した AWS Cost and Usage Reports （AWS CUR）（コストと使用状況レポート）の可視化についてご紹介します。 2部構成であり、今回は後編をご紹介します。 前編： AWS CUR や Amazon Athena の設定、 Amazon Athena から SQL クエリを使用した AWS CUR の分析手順 後編： Amazon QuickSight のセットアップ、 AWS CUR の可視化、分析やダッシュボードの共有 Amazon QuickSight のセットアップ この手順では以下を含んだ Amazon QuickSight の初期設定を行います。 Amazon Athena へのアクセス許可 AWS CUR レポートが作成される Amazon S3 バケットへのアクセス許可 詳細の手順は以下をご参照ください。 Setup QuickSight for the first time “5.Select S3 Buckets You Can Access Across AWS, under Use a different bucket enter the CUR bucket name, choose Add S3 bucket and choose Finish.” は実施不要です。 Setup QuickSight IAM Policy は必要に応じて実施してください。 Amazon QuickSight のデータセットの作成 この手順では Amazon QuickSight のデータセットの作成を行います。データソースとして Amazon Athena から検索可能な AWS CUR のテーブルを設定します。 Amazon Athena からデータを Amazon QuickSight に読み込むことによって、 Amazon QuickSight でデータを確認することが可能になります。 詳細の手順は以下をご参照ください。 Create a dataset これで Amazon QuickSight を使って AWS CUR の可視化を行う準備ができました。 AWS CUR の可視化とダッシュボードの作成 Amazon QuickSight を使用した可視化の例として、下記のダッシュボードの作成を行います。 この手順では以下の3つのグラフを作成します。 AWSアカウント単位、プロダクトコード単位のコスト インスタンスタイプ、購入オプション（オンデマンド、スポット、リザーブドインスタンス）ごとの1時間ごとの Amazon EC2 インスタンスの使用状況 line_item_line_item_descrption（利用明細）別の日次のコスト line_item_line_item_descrption とは、利用明細の説明になります。例えば、利用明細の説明として特定の期間に利用した Amazon EC2 のインスタンスタイプを要約したものが記載されます。 詳細の手順は以下をご参照ください。 Create visualizations 設定項目名が分からない場合は Amazon QuickSight の言語設定を English に変えてご確認ください。 Amazon QuickSight のその他の可視化機能については以下のブログをご覧ください。 BIサービス Amazon QuickSight のセルフハンズオンキット日本語版を公開（随時更新） Amazon QuickSight の運用については以下のブログをご覧ください。 【開催報告＆資料公開】Amazon QuickSight のノウハウ総まとめ！ 〜BI設計から運用まで〜 作成した分析の共有とダッシュボードの公開 作成した分析やダッシュボードは共有することが可能です。 詳細の手順は以下をご参照ください。 Share your Analysis and Dashboard ダッシュボードの共有については特定のユーザーやグループを指定する方法、アカウント内の全ユーザーに共有する方法、インターネット上で共有する方法があります。 Amazon QuickSight API を使用して共有を設定することも可能です。 また、ダッシュボードを PDF としてエクスポートすることや、レポートを E メールで送付することも可能です。ぜひご要望に沿った形式でダッシュボードやレポートの共有をご活用ください。 詳細は Amazon QuickSight ダッシュボードの共有 をご参照ください。 前編、後編を通して、AWS CUR の内容を Amazon QuickSight を使用して可視化し、共有する事ができるようになりました。 AWS Cost and Usage Reports【AWS Black Belt】 Amazon QuickSight を使用した AWS CUR の分析については以下の AWS Black Belt Online Seminar でもご紹介していますのでご参照ください。 AWS Cost and Usage Reports【AWS Black Belt】 Cost and Usage Dashboard powered by Amazon QuickSight AWS CUR の可視化として、 Cost and Usage Dashboard powered by Amazon QuickSight が使用可能になりました。 AWS CUR のデータに対して、事前に定義された Amazon QuickSight の100以上のビジュアルを簡単に使用する事が出来ます。こちらもぜひご活用ください。 前編と後編を通じたまとめ クラウドのコストを最適化するためには、まず現在の使用状況を把握、分析することが重要です。書籍「AWS コスト最適化ガイドブック」からコストの可視化に関する記述を引用します。 “クラウド利用費用最適化の最初のステップは、 AWS サービスの利用状況の可視化です。クラウドは利用量によって利用費用が変動する従量課金形式が基本であるため、クラウドを効率的に最適化するためには、根拠となるクラウド利用費用と利用状況の情報の可視化は非常に重要です。可視化のポイントは、何をどこまで可視化するのか、という点にあります。可視化のための手間や得られた情報の保存にかかる費用など、すべてを可視化することが逆に最適化の足かせになってしまうことも考えられます。 無駄な監視や情報収集をしないために、まずは可視化の目的、すなわち、「どのような情報が得られたらどのようなアクションを実施したいのか」という点を明確に定めることで、必要な情報や粒度などが自然と定まります。例えば、各部門（あるいは各システム）の毎月（あるいは毎週）の予算が70％を超えたらアラートを上げる、90％を超えたら新規のインスタンスの立ち上げを認めないようにする、各部門あるいはシステム単位で Amazon EC2 の利用量の日単位での変化を収集し土日の稼働停止がどの程度できているか確認し、常時稼働のシステムについては後述する Savings Plans の適用を検討する、などといったように、可視化で何をしたいのかということが明確に示せるようになれば、可視化したい項目や粒度などが定まってくるでしょう。 ただし、クラウド利用費用の数字だけを可視化・報告するというのは、陥りがちな間違いです。「いくらかかっているのか」という情報だけでなく、「利用量や利用状況に対していくらかかっているのか」ということを可視化することで、その費用の妥当性が判断できるようになります。 AWS の各サービスには、クラウド利用費用がいくらになっているのか、という情報はもちろんのこと、利用者のサービスの利用状況も記録されています。この利用状況の情報を利用者が出力・集計したり、あるいは表やグラフなどの形式で過去の経緯や現在の状況を可視化したりすることができます。” 出典： AWS コスト最適化ガイドブック（門畑 顕博 (著), 仁戸 潤一郎 (著), 柳 嘉起 (著), 杉 達也 (著), 小野 俊樹 (著), 藤本 剛志 (著)） 本ブログでは、前編、後編を通じて、 AWS Well-Architected Framework の コスト最適化の柱 における5つのベストプラクティスのうち、 経費支出と使用量の認識 の可視化に着目してご紹介しました。 他にも、タグポリシーに関するワークショップや、その他のベストプラクティス「 コスト効率を考慮しながらリソースを利用する 」と「 需要を管理しリソースを供給する 」に関するワークショップもありますのでご活用ください。 カスタマーソリューションマネージャー　森川 賢、髙木 香里

本ブログは Amazon QuickSight を使用した AWS Cost and Usage Reports （AWS CUR）（コストと使用状況レポート）の可視化についてご紹介します。 2部構成であり、今回は前編をご紹介します。 前編： AWS CUR や Amazon Athena の設定、 Amazon Athena から SQL クエリを使用した AWS CUR の分析手順 後編： Amazon QuickSight のセットアップ、 AWS CUR の可視化、分析やダッシュボードの共有 クラウドのコストを最適化するためには、まず現在の使用状況を把握、分析することが重要です。 AWS CUR では、課金されるすべての AWS のサービスについて、月単位、日単位または時間単位の使用量の粒度、料金、コスト、使用属性が提供されるため、使用状況の把握、分析に利用することができます。 今回ご紹介する方法は「月次で AWS の利用状況をまとめたレポートを作成し、関係者に報告する」といったユースケースにご活用いただけます。 Amazon QuickSight に AWS CUR の情報を取り込んだダッシュボードを作成していただくことで、ご関係者様がレポートをいつでも見ることができるようになり、ご担当者様も毎月のレポート作成作業が不要になります。 Amazon QuickSight に AWS CUR の情報を取り込んで可視化する方法はいくつかありますが、今回は Amazon Athena 経由で取り込む方法をご紹介します。Amazon QuickSight を使用した可視化のほか、Amazon Athena から SQL クエリを使用したアドホックな AWS CUR の分析も行えるようになります。 AWS Well-Architected Cost Optimization Workshop AWS Well-Architected Framework は、クラウド上でワークロードを設計および実行するための主要な概念、設計原則、アーキテクチャのベストプラクティスについて説明しており、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性の6つの柱で構成されています。 また、AWS Well-Architected Framework に沿ったワークショップが用意されており、各柱のベストプラクティスに沿って構成されています。 コスト最適化の柱 では5つのベストプラクティスが用意されており、コストの可視化は 経費支出と使用量の認識 に含まれます。この5つのベストプラクティスに沿ったワークショップとして AWS Well-Architected Cost Optimization Workshop があり、コスト最適化を図るためのハンズオンを提供しています。 このワークショップを用いて、AWS CUR と Amazon QuickSight を使った可視化にフォーカスしてご紹介します。 AWS CUR （コストと使用状況レポート）の作成 この手順では以下の設定の AWS CUR を作成します。 リソース ID のインクルード 自動的に更新（少なくとも1日1回更新） 詳細度が時間別 Amazon Athena と統合 AWS CUR のデータの保存には、AWS CUR を作成した AWS アカウントが保有する Amazon S3 バケットを使用します。本手順ではレポートを保存する Amazon S3 バケットの作成も行います。 初回レポート作成までに最大24時間かかることがあります。詳細の手順は以下をご参照ください。 Configure a Cost and Usage Report Configure the CUR Bucket for your Cost Optimization Account 以降は必要に応じて実施してください。 AWS CloudFormation を用いた Amazon Athena のセットアップ この手順では以下を行います。  AWS CUR のファイルが正しく作成されている事の確認   AWS CloudFormation を使った AWS Glue , Amazon Athena のセットアップ この手順を実施すると Amazon Athena から AWS CUR を検索できるようになります。 詳細の手順は以下をご参照ください。 Automated CUR Updates and Ingestion Lab Prerequisites , Setup AWS Glue with CloudFormation の範囲を実施してください。 Multiple CURs は必要に応じて実施してください。 Amazon Athena から SQL クエリを使用して AWS CUR を分析する この手順では Amazon Athena から SQL クエリを使用して、 AWS CUR に対していくつか実際に検索を行います。どのようなデータが AWS CUR に保存されているかを確認することができますのでぜひお試しください。なお、この手順では個別の設定は行いません。 詳細の手順は以下をご参照ください。 Cost and Usage Analysis – SQL 以下のような点を確認することが可能です。上記URLに下記情報を抽出するクエリサンプルが記載されています。 上位のコスト タグ付けがされているリソースに対するコスト インスタンス購入オプションに対するコスト AWS CUR の各項目名や意味は以下をご参照ください。 AWS コストと使用状況レポート – データディクショナリ AWS Athena 上は項目名が全て小文字である点と、ヘッダーと明細項目名が“_”で接続されている点にご注意ください。なお、AWS CUR と Amazon QuickSight を直接連携する場合は上記 URL に記載の項目名になります。 前編のまとめ AWS CUR はAWS のコストと利用状況に関する最も細かく最も包括的なデータが含まれています。 なお、AWS リソースの使用量・使用料金に関するデータを可視化し、分析するためのツールとして、 AWS Cost Explorer というサービスもあります。AWS Cost Explorer よりも詳細または複雑な分析、過去12か月を超える期間での分析、独自のダッシュボードでの可視化を行いたいときに、 AWS CUR が使用できます。AWS CUR では取得出来て AWS Cost Explorer では取得できない情報の1つとして、Savings Plans / リザーブドインスタンスの詳細情報があります。 AWS Organizations で共有されている、他のアカウントで購入された Savings Plans / リザーブドインスタンスの割引効果や、他のアカウントで利用された Savings Plans / リザーブドインスタンスの割引効果といったものも算出ができます。 以上、 AWS CUR や Amazon Athena の設定、 Amazon Athena から SQL クエリを使用したアドホックな AWS CUR の分析手順をご紹介しました。後編では Amazon QuickSight の設定からご紹介します。 後編は こちら カスタマーソリューションマネージャー　森川 賢、髙木 香里

2023 年 11 月 26 日、 AWS Step Functions と Amazon Bedrock との最適化された統合を発表します。 AWS Step Functions は、開発者が分散アプリケーションを構築し、プロセスを自動化し、そして、マイクロサービスのオーケストレーションやデータと機械学習のパイプラインを作成するのに役に立つビジュアルワークフローサービスです。 9 月には、基盤モデルを使用した生成系 AI アプリケーションの構築および拡張が最も簡単な Amazon Bedrock が利用可能になりました。 Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Stability AI、Amazon などの主要プロバイダーの基盤モデルを提供し、プライバシーとセキュリティを維持しながら、お客様が生成系 AI アプリケーションを構築するために必要な幅広い機能を提供しています。Amazon Bedrock は、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK から利用できます。 AWS Step Functions の Amazon Bedrock との新たな最適化された統合により、 220 以上の AWS サービス との統合に加え、Amazon Bedrock を使用して生成系 AI アプリケーションを構築するためのタスクをオーケストレーションできます。 AWS Step Functions によって、ワークフローを視覚的に開発、検査、監査できます。 以前は、ワークフローから Amazon Bedrock を使用するために AWS Lambda 関数を呼び出す必要があり、コードの追加や、アプリケーションの実装コストを増やす必要がありました。 AWS Step Functions は、Amazon Bedrock のための 2 つの新しい最適化された API アクションを提供します。 InvokeModel – この統合により、モデルを呼び出し、入力されたパラメーターを使用して推論を実行できます。この API アクションを利用して、テキスト、画像、埋め込みモデルの推論を実行できます。 CreateModelCustomizationJob – この統合により、基盤モデルをカスタマイズするためのファインチューニングジョブが作成されます。パラメーターで、基礎モデルとトレーニングデータの場所を指定します。ジョブが完了すると、カスタムモデルが利用可能になります。これは非同期 API であり、この統合により、AWS Step Functions は ジョブを実行 し、次の状態に進む前にジョブの完了を待つことができます。これは、ステートマシンの実行がモデルのカスタマイズジョブの作成中に一時停止し、ジョブの作成が完了すると自動的に再開されることを意味します。 InvokeModel API アクションは最大 25 MB までのリクエストとレスポンスを受け付けます。しかし、AWS Step Functions ではステートの入出力ペイロードに 256 KB の制限があります。この統合でより大きなペイロードをサポートするために、 InvokeModel API がデータを読み込み、結果を書き込む Amazon Simple Storage Service (Amazon S3) バケットを定義することができます。これらの設定は、設定セクションの API パラメーターという項目で提供されます。 Amazon Bedrock と AWS Step Functions を使い始める方法 始める前に、Amazon Bedrock が利用可能な地域でステートマシンを作成することを確認してください。 この例では、 us-east-1   (US バージニア地域) を利用します。 AWS マネジメントコンソールから、新しいステートマシンを作成します。“bedrock” と検索すると、利用可能な 2 つの API アクションが表示されます。 InvokeModel をステートマシンにドラッグします。 右側のメニューでステートの設定ができるようになりました。まず、使用する基盤モデルを定義できます。一覧からモデルを選択するか、入力からモデルを取得します。 次に、モデルパラメーターを設定する必要があります。テキストボックスに推論パラメーターを入力するか、Amazon S3 からパラメーターを読み込むことができます。 API アクション設定の項目をスクロールすると、宛先となる S3 バケットなど、API の追加設定オプションを指定できます。この宛先となる S3 バケットが指定されている場合、API アクションは、ステート出力セクションではなく、指定されたバケットに API レスポンスを格納します。ここでは、リクエストとレスポンスのコンテンツタイプを指定することもできます。 ステートマシンの設定が完了したら、作成して実行できます。ステートマシンが実行されると、実行の詳細を視覚化し、Amazon Bedrock のステートを選択すると、その入出力を確認できます。 AWS Step Functions を利用すると、必要に応じて広範囲にステートマシンを構築し、さまざまなサービスを組み合わせて多くの問題を解決できます。 たとえば、AWS Step Functions と Amazon Bedrock を利用して、プロンプトチェーンを使用したアプリケーションを作成できます。 これは、非常に長く詳細なプロンプトではなく、複数の小さくてシンプルなプロンプトを FM に渡すことで、複雑な生成系 AI アプリケーションを構築する技術です。 プロンプトチェーンを構築するには、Amazon Bedrock を複数回呼び出して、小さなプロンプトごとに推論を得るステートマシンを作成できます。 並列ステート を使用して、これらすべてのタスクを並行で実行でき、 AWS Lambda 関数を利用すれば、並列タスクの応答を 1 つの応答に統合して結果を生成することができます。 今すぐ利用可能 AWS Step Functions の Amazon Bedrock との最適化された統合は、Amazon Bedrock が利用可能な AWS リージョンに限定されています。 AWS Step Functions コンソール からサンプルプロジェクトを試すことで、AWS Step Functions と Amazon Bedrock を使い始めることができます。 – Marcia 原文は こちら です。

AWS App Runner は、インフラやコンテナの経験がなくても、コンテナ化された Web アプリや API をビルド、デプロイ、実行できるフルマネージドなコンテナアプリケーションサービスです。App Runner はインフラ構成の複雑さを抽象化します。実際、 Wix ・ Hubble ・ Cox やその他多くの企業が、App Runner を利用することでサーバー管理にかける時間を減らし、イノベーションを加速することに集中しています。App Runner では ソースコード または コンテナイメージ から直接、スケーラブルでセキュアなWeb アプリとしてデプロイできます。これらは高速でシンプルで、かつコスト効率の高い方法です。 本日(2023/12/07) 、App Runner のコンテナイメージベースのデプロイ速度の改善をリリースしました。 ベンチマークでは、コンテナイメージサイズに応じて、 リリース前と比較してデプロイ時間が約 30 ～ 40% 短縮しました。 この機能強化により、コンテナイメージリポジトリからイメージをダウンロードできない場合の App Runner の動作も改善されます。 以前は、App Runner がイメージをダウンロードできない場合、ステータスを failed にする前に 10 分間リトライしていました。 App Runner は、コンテナイメージのダウンロードができない何らかの要因があった場合、デプロイのステータスを直ちに failed にするようになりました。 今回の機能改善は自動的に適用され、すべての App Runner ユーザーがメリットを得ることができます。既存の App Runner サービスを更新する必要はありません。 どれだけ速くなったのかを実際に計測 コンテナ化されたアプリケーションの場合、コンテナイメージの大きさは、デプロイ時間やアプリケーションの起動時間に影響します。 より小さなコンテナイメージを使うほど、アプリケーションの起動時間は短くなり、デプロイも速くなります。 これは、コンテナイメージのダウンロードが、アプリケーションのデプロイに最も時間のかかるタスクの 1 つであるためです。 App Runner の今回の機能改善の効果を、コンテナイメージの大きさごとに計測することを目指しました。 デプロイ時間の改善を測るために、 hello-app-runner コンテナイメージを利用しました。 hello-app-runner コンテナイメージは 261 MB です。 次に、50 MB のファイルを大量に生成することで、イメージの大きさを人為的に大きくしました。1 GB、2 GB、および 3 GB の 3 つのイメージを用意しました。 必要な大きさのコンテナイメージを用意したら、それらを使用して App Runner サービスを作成し、サービスのステータスが Healthy になるまでにかかる時間を機能改善の前後で比較しました。 各イメージを 10 回デプロイし、平均値を測定して外れ値を除外しました。 下の表は、デプロイ時間の改善を示しています。 下のグラフは、サービスのステータスが Healthy になるまでの時間を秒単位で示しています。 コンテナイメージの大きさが 1 GB 未満の場合、 デプロイ時間は約 2 分短縮しています 。 大きなイメージの場合、5 分近くの短縮しています。 すでに利用可能です 今回の機能改善は、App Runner を利用可能なすべての AWS リージョンで適用されています。デプロイプロセスが 1 分短くなると、アプリケーション開発やリリースサイクルに大きな影響をもたらすでしょう。App Runner を使うことでみなさまが、みなさまのお客様により迅速にアプリケーションを届けられることを願っています。 このリリースは、ユーザーのみなさまが 大規模な Web アプリや API を、より手軽に実行できるようにするための継続的な取り組みの一環です。 App Runner の最近の機能強化については、 リリースノート をご覧ください。 AWS App Runner における今後の機能開発の詳細については、 App Runner roadmap on GitHub をご覧ください。 また、 AWS re:Post for AWS App Runner でフィードバックや質問もお待ちしています。 翻訳はソリューションアーキテクトの濵が担当しました。原文は こちら です。

本記事は、「 Disaster Recovery 5G Core Network on AWS 」（2023年6月26日公開）を翻訳したものです。 通信サービスプロバイダ（CSP）は、テレコム業界においてさらなる活用事例を見つけようとしています。AWS 上の 5G コアネットワークデプロイは、企業向けのプライベートネットワークや新たな 5G ネットワークの作成などの実用的なユースケースが挙げられて、ますます注目されています。AWS の ホワイトペーパー で強調されているように、AWS のグローバルクラウドインフラストラクチャである AWS Regions 、AWS  Availability Zones（AZ）、 AWS Local Zones 、 AWS Outposts は、ネットワークファンクション（NF）の特性に合わせて 5G コアネットワークをホストするための効果的かつ柔軟な環境を提供できます。一例として、ユーザプレーン機能（UPF）は、低遅延で処理するために AWS Local Zones や AWS Outposts に配置することができます。 5G NF on AWS のさまざまなユースケースの中でも、すでに 5G コアネットワークを構築している CSP にとって、魅力的なケースの1つは、AWS を利用した災害復旧（DR）です。この 5G DR ネットワークは、5G NF の障害、データセンターの完全停止、またはメンテナンスウィンドウに対するスケーラブルかつ即時の対策を目指しています。具体的には、この DR ネットワークは、計画されたメンテナンス、災害による予期せぬ停止に応じてのみ追加される環境であるため、迅速なスケールインとスケールアウトによってリソースのコストを最小限に抑える必要があります。従来の電気通信業界のデータセンターに冗長なネットワークを構築する場合と比較して、AWS は CSP が通常運用時にコストとエネルギー消費を最小限に抑えることを手助けできます。また、輻輳によるトラフィックの急増やメンテナンスイベントなどの変動的な需要にも迅速に対応できます。 この記事では、AWS を 5G ネットワークのもう1つの仮想データセンター環境として活用し、「災害耐性」と「災害回復」の目標を達成する方法について説明し、AWS における 3GPP の高可用性コンセプトや関連する AWS サービス（オートスケーリング、自動化ツール、ネットワークのコスト最適化など）を活用することに焦点を当てています。具体的には、 Amazon Elastic Compute Cloud（Amazon EC2） の Autoscaling 機能、 Amazon Elastic Kubernetes Service（Amazon EKS） の Horizontal Pod Autoscaling と Cluster Autoscaling 機能を使用して、DR 用の VPC 内のコンテナベースのネットワークファンクション（CNF）のフットプリントを最小限に抑えることができます。また、トラフィックの急増に対応するための迅速なスケールアウトもできます。 さらに、コストとエネルギーを最適化するために、 Graviton インスタンスで 5G コア NF をホストすることも検討できます。この記事では、まず DR モデルと戦略を説明します。そして、最初に 5G ネットワークのケースにどのように適用されるかを説明し、次に 3GPP アーキテクチャを活用してこの DR 目標を達成する方法や、いくつかのオープンソースの例を用いて EC2 Autoscaling、Cluster Autoscaling、およびその他の機能などの AWS サービスをどのように活用できるかといった重要なアイデアを示します。 AWS での 5G コアネットワークの DR モデル こちらの DR に関する 記事 と ホワイトペーパー で説明されているように、DRには2つの目標があります。リカバリタイムオブジェクティブ（ RTO ）は、サービスの中断と復旧の間の許容遅延時間を意味し、リカバリポイントオブジェクティブ（ RPO ）は、最後のデータ復旧ポイントからの許容時間を意味します。AWS 上で実行される一般的なアプリケーションの場合、DR のための AWS サービスには AWS Elastic Disaster Recovery（ AWS DRS ）や Amazon Route 53 Application Recovery Controller（ Route 53 ARC ）などがあります。 しかし、5G コアネットワークアプリケーションでは、3GPP 標準に基づくネットワークインタフェースとプロトコルに対するより強い要件があります。AWS DRS などのサービスはコアネットワークのすべてのコンポーネントに常に適用できるわけではありません。この記事ではより包括的な視点から、3GPP の標準アーキテクチャのコンテキストで、AWS のサービスが DR 実装にどのように役立つかに焦点を当てます。 5G NF の場合、AMF、SMF、UPF などのコア機能コンポーネントは、5G 音声およびデータサービスの高速な復旧に重要な役割を果たすため、RTO がより重要です。一方、UDM は RPO と RTO の両方に強く影響されます。なぜなら、UDM は加入者のプロファイルと情報を扱うからです。各 NF には異なる目標があり、異なるタイプのDR戦略を適用すべきです。以下の図は、DR ホワイトペーパーで強調されている DR の 4つの戦略 を示しています。左から右へと進むグラフィックは、DR 戦略によって RTO と RPO が変わることを示しています。5G コア NF の場合、ミッションクリティカルなサービスを提供しているため、より短い RTO が求められる場合があります。 図1: 一般的なアプリケーションの DR 戦略 たとえば、先に述べたように、UDM はリアルタイムに近い RTO と RPO の両方が必要です。したがって、AWS 上の UDM の DR サイトを構築する場合、UDM を常にアクティブな状態に保つためには、従来のデータセンターの UDM と同期する必要があります。この場合、Hot-standby（Active-Active）戦略がより適切です。 一方、その他の NF には、Warm-standby、Pilot light、Backup ＆ Restore などの戦略をユースケースと NF の特性に基づいて適用できます。Backup ＆ Restore は、ミッションクリティカルではい、優先度の低いユースケース（1 時間未満という厳しい RTO が要求されない場合）に適用できます。データセンターと AWS の間に事前に確立された Amazon Direct Connect （もしくは帯域幅制限と安定性を備えた Site-to-Site VPN で代替可能）があれば、 AWS CloudFormation 、AWS Cloud Development Kit（ AWS CDK ）、 AWS CodePipeline などの AWS ツールを利用して、「NF の即時インスタンス化」を実現できます。インフラアズコード（ IaC ）の利点によってさらに加速化することも可能です。詳細については、こちらの AWS 記事 DR Architecture on AWS, Part II を参照してください。また、AWS 上での 5G NF デプロイ CI/CD パイプラインも迅速なサービス回復に貢献できます。詳細については、こちら AWS ホワイトペーパー CI/CD for 5G Networks on AWS を参照してください。 Cold-standby は、ミッションクリティカルでない 5G ネットワークユースケースに対して、コスト効果の高い選択肢です。この戦略では、すべての EC2 インスタンスがシャットオフ状態ですが事前に作成されており、通常運用時は DR サイトにトラフィックを処理させない状態になっています。そのため、Backup ＆ Restore よりも高速で、Warm-standby よりもコスト効果が高くなります。一方、Warm-standby は、テレコムの音声およびデータサービスの RTO を考慮して、AWS 上に DR 5G ネットワークを構築する最も実用的な方法です。この戦略では、DR サイトのほとんどの 5G NF が最小限のデプロイで少量のトラフィックを処理し、トラフィックカットオーバー時にトラフィックを処理できるように拡張します。これにより、5G ネットワークの災害耐性を実現しながら、サービスの連続性を確保することができます。5G NF が Amazon EKS 上に実装されている場合、一般的なオートスケーリンググループベースの機能だけでは、トラフィックの急増を吸収するための瞬時スケールの要件を満たせない場合があります。これは、必要な RTO が Kubernetes オートスケーリングアクションの一般的な応答時間よりも短いためです。そのため、この記事の後半では、Amazon EKS 環境でこのより速い Warm-standby を実現するための効果的な実装スキルを詳細に紹介します。最後に、コスト最適化の観点から、Graviton インスタンスはコストパフォーマンスの面で著しい利点を提供し、エネルギーの節約に関連する問題に取り組んでいます。 3GPP で定義された耐障害性メカニズムと AWS での活用 3GPP は、5G コアネットワークのネットワーク耐性を構築するため、NF Set と呼ばれるコンセプトを TS23.501 で定義しています。このコンセプトでは、NF は単一のインスタンスとして展開されるか、もしくは同じ NF の複数のインスタンスが NF Set を形成することができます。これにより、NF インスタンスが障害になった場合、 NF set 内の代替 NF インスタンスに置き換えて、代わりにリクエストされたサービスを提供したり、サービス要求の急増を処理したりできるため、サービスの冗長性とスケーラビリティが高まります。5GC ネットワークでは、AMF、SMF、UDM など、NF Set の概念をサポートする多くの NF があります。DR のユースケースでは、N2トラフィックを gNodeB から受け取る AMF set の利用により、AMF が各データセンターにある NF にトラフィックを転送します。次の図は、AMF set 構成の例です。AMF set はトラッキングエリアコード（TAC）ごとに構成され、AMF が 3つの異なるデータセンターに跨ってトラフィック負荷を分散し、障害時のスイッチオーバーを行います。3GPP では AMF set のロードバランシングのコンセプトも定義しており、各 AMF の Weight Factor を使用して、各データセンターの AMF の容量に基づいて UE の登録（Registration）を制御できます。 図2: 複数のデータセンターにまたがる3GPP NF Setのデプロイ AMF set のような NF set のコンセプトにより、NF のグループがデータセンター間でトラフィック負荷分散することができますが、Network Repository Function（NRF）は、AMF 以外の NF に対するトラフィック負荷のローカリゼーションすることができます。具体的には、3GPP の標準に従い、NRF は Nnrf_Management（nnrf-nfm）および Nnrf_Discovery（nnrf-disc）サービスを使用して、サービスを要求する他の NF（Consumers）にサービスを提供する NF（Producers）のステータスに関する情報を維持および提供することを担います。NRF サービス Nnrf_Management は、「NFRegister」の動作をサポートし、5GコアネットワークのすべてのNFがNRFに対してそれぞれのプロファイルを登録するために使用されます。登録プロセス中、NF は NFProfile の一部として、nfInstanceID、nfType、nfStatus、FQDN、IPv4/IPv6 アドレスなどの必須情報を NRF に送信し、オプションとして、優先度や地域など、NF Set に関連する情報も送信します。 図3: NRF への NF 登録と NRF へのサービスリクエストの例 NRF サービス Nnrf_NFDiscovery は、5G NF（Network Function）の「Consumer」に「Producer」の情報を提供するための「NFDiscover」という操作をサポートしています。通常、商用ネットワークがより高い可用性を実現するために、CSP は複数の Producer NF のインスタンスを展開します。3GPP では、Producer NF を発見するためのオプションが Consumer NF に提供されています。Consumer は、必要なサービスの要件に一致するすべての Producer NF の一覧リストを要求するか、追加のクエリパラメータで返されるリストを絞ることができます。Consumer NF が使用できるクエリパラメータの1つは、異なる Producer NF に対して NRF から返された優先度情報に基づいています。Consumer NF が使用できるもう1つのパラメータは、「preferred-locality（優先ローカリティ）」です。AMF setとNRF preferred-locality は、DR on AWS のユースケース、特に Pilot light、Warm-standby、または Hot-standby のために活用することができます。例えば、AMFの重み係数が既存のデータセンターと AWS 上の仮想 DR データセンターで同じ値で構成されている場合、DR サイトは Hot-standby モードで動作します。 障害時におけるオンプレミスデータセンターから VPC へのトラフィックシフト 一般的なオンプレミス商用 5G コアネットワークは少なくとも1つの DR サイトで展開されます。DR サイトの数は、CSP の戦略に依存します。さらに、1+1、N+1、または N+K いずれのモデルが採用されます。DR サイトの数に関係なく、オンプレミスの DR サイトには、アクティブサイト障害のトラフィックを引き継ぐために必要となる以上のリソースが常に割り当てられます。 CSP は、NF set のメカニズムを使用して、NF インスタンスのグループをアクティブサイト（または既存のデータセンター）と DR サイト（AWS 上の仮想データセンター）に分散させることができます。AWS 上の DR サイトでは、3GPP をサポートする 5G NF が既存のオンプレミスの NF set の一部として構成することができます。NF set の一部として追加できない 5G NF は、新しいインスタンスにデプロイできます。NRF のデプロイモデル（集中型または分散型）に応じて、DR サイトの NF はオンプレミスの中央集権型 NRF に登録するか、AWS 上のローカル NRF に登録することができます。ただし、いずれの NRF 展開オプションにおいても、Warm-standby 戦略では、DR サイトの NF は登録時に、オンプレミスの NF よりも低い優先度（AMF の場合は低い Weight Factor）を使用することが重要です。これにより、通常時はアクティブなオンプレミスサイトがトラフィックを継続的に処理し、災害、NF の故障、またはメンテナンスウィンドウの発生時にのみ、トラフィックが AWS 上の DR サイトに移行されます。 DR サイトがアクティブになると、AWS のスケーラビリティと弾力性を活用して NF の容量を拡張することも重要です。また、NF の登録プロセス中に「preferred-locality」情報を使用することで、トラフィックを DR サイトの 5G NF 内に保つことができます。これにより、レイテンシが低くなり、サービスリクエストの応答時間が向上します。 図4: AWS 上の 5GC ネットワーク DR サイト 通常時のシナリオでは、大部分のトラフィックはオンプレミスのアクティブサイトで処理されるため、CSP は AWS 上で最小限の DR サイトフットプリントから始めることができます。その後、障害のタイプに応じて、単一または複数の NF が次の章で説明する高速オートスケーリングメカニズムを利用し、適切なリソースまで拡張します。この戦略は、完全なオンプレミスサイトの故障だけでなく、部分的な故障のケースやオンプレミスのメンテナンスウィンドウの間にも適用することができます。 トラフィック急増を対応するための高速オートスケーリング 前章で説明したように、Warm-standby 戦略の場合、5G コア NF は最小のフットプリントで AWS に展開され、アクティブサイトのトラフィックの一部を処理します。しかし、プライマリサイトに障害が発生した場合、トラフィックがプライマリサイトから AWS 上の DR サイトに移行するため、大規模なトラフィックの急増が予想されます。この場合、5G NF と AWS のコンピュートプラットフォームの容量を迅速にオートスケーリングすることが重要です。5G NF のオートスケーリングは通常、Kubernetes HPA（Horizontal Pod Autoscaler）に基づいて行われます。ただし、POD のスケーリングだけではワーカーノードのスケールアウトに対応できません。5G NF は Amazon EKS を利用して AWS にデプロイされているため、この課題の解決策は Autoscaling Groups と関連しています。Amazon EKS は、Kubernetes のワーカーノードのデプロイと管理（スケールアウトを含む）に Autoscaling Group を利用します。ただし、Autoscaling Group の Cluster Autoscaler 機能は、5G のスケールアウトの要件に対しては遅すぎます。これは、Cluster Autoscaler がリアクティブな仕組みで、POD がスケジュールできないと判明した後にのみクラスターのスケーリングがトリガーされるためです。その代わりに、Autoscaling Group の Cold-standby 機能を利用することで、トラフィック急増する際に迅速に Amazon EKS ワーカーノードのスケールアウトを行うことができます。 図5: Amazon EKS ワーカーノードの状態変更による Cold-standby モデルの高速スケールアウト さらに、Cold-standby モデルの使用により、Amazon EKS ワーカーノードはワークロードをホストするために事前に設定されるだけではなく、使用されていない間は電源をオフにしてコストを節約することができます。これは、起動時のスクリプトによる特別なチューニングを必要とするワークロード（通常は Multus と DPDK を使用するワークロードなど）に特に有用です。これらのワーカーノードは、Amazon Elastic Container Registry（ Amazon ECR ）または他の場所から POD コンテナイメージを事前にダウンロードするなど、さまざまな事前処理を行うことができます。そのため、POD の起動時にコンテナの準備完了状態までの時間が短縮されます。Cold-standby ワーカーノードの自動化は、こちらの記事の GitHubリポジトリ で示されているカスタム Lambda 関数によって実現できます。 図6: Cold-Standby Amazon EKS ワーカーノードの自動起動プロセス カスタムメトリクスに基づいたスケーリングの自動化 Warm-standby 戦略では、プライマリサイトがメンテナンス中または災害/障害のためにダウンした時に、トラフィックの急増がアプリケーションのカスタムメトリクスで検知されます。例えば、AMF 登録試行数のメトリクスが急増します。Amazon Distro for Open Telemetry（ ADOT ）のアプリケーション Metrics Scraping を利用し、Cold-standby ノードの起動をトリガーするソリューションも利用できます。以下の図には、 Amazon Managed Prometheus サービスからカスタムメトリクスを収集するために KEDA を使用し、事前に定義されたトリガーと閾値に基づいてKubernetes ジョブをキックオフし、ワーカーノードをオンライン状態にするソリューションの一例が示されています。 図7:カスタムメトリックと KEDA を活用した高速オートスケーリング Hot-standby と Warm-standby の DR 戦略のコスト比較 5G コアの AWS とオンプレミスの地理的冗長ソリューションの TCO 比較はかなり複雑ですが、Warm-standby DR 戦略と前述した Cold-standby の仕組みの組み合わせによるコスト削減効果を検討することができます。例えば、全トラフィックを処理できる Hot-standby（Active-Active）サイトには、6つの m5.8xlarge EC2 インスタンスが必要であり、Warm-standby モードでは、一部分のトラフィックのみを処理するため、2つのm5.8xlarge EC2インスタンスが必要とします。そして、AWS 上の DR サイトへのトラフィックシフトが平均して毎月 4 時間で発生すると仮定します。したがって、毎月 4 時間のみ、DR サイトはすべてのトラフィックを処理するために追加の 4つの m5.8xlarge EC2 インスタンスが必要となります。 Hot-standby の場合、 AWS Calculator と US-East（Ohio）の EC2 インスタンスの saving plan 価格（64GB の EBS ストレージを搭載したインスタンスで、この記事作成時の価格）を使用すると、常時稼働している6つの m5.8xlarge EC2 インスタンスの年間費用は $47,830.32 になります。一方、Warm-standby の場合、 AWS Calculator for Warm Standby を使用して計算すると、コストは$16,914.60 になります。2つの常時稼働している m5.8xlarge EC2 インスタンスの年間費用 $15,943.44 と、毎月 4 時間稼働する 4 つの追加 m5.8xlarge EC2 インスタンスのオンデマンド価格による年間費用 $294.96、および 4 つの 64GB EBS ボリュームの年間費用 $676.20 が含まれます。 以下のグラフから分かるように、Warm-standby モードの利用により、Hot-standby（Active-Active）モードと比較して約 65% の節約が実現されます。 図8: 6つの m5.8xlarge EC2 インスタンスの Hot-standby と Warm-standby のコスト比較 CSP は、5GC ネットワークに対して、上記のアプローチを適用する際に、 AWS Calculator for EC2 を利用して EC2 インスタンスの数量を入力し、Warm-standby DR 戦略の実施による潜在的なコスト削減を推定することができます。 結論 5G モバイルコアネットワークは、音声通話やデータストリーミングなどのミッションクリティカルなサービスを提供するため、サービスの災害耐性を確保し、ネットワークコンポーネントの迅速な災害復旧の能力を持つことが重要です。障害や災害からのより良い保護を実現するために、従来のオンプレミスデータセンターではなくクラウド上に DR 5G ネットワークの構築を検討することが考えられます。また、この DR 5G ネットワークが限られた期間に使用されることが主な目的である場合（サービスの回復やトラフィックバーストの吸収）、クラウドの従量課金モデルとの相性が良いです。AWS は、CSP のお客様に対して、DR 仮想データセンターを構築するための環境だけでなく、この記事の GitHubリポジトリ のサンプルで示されているようなネットワークの自動化とスケーリングツールなどの支援も提供します。この高速スケーリングアウト能力を、Graviton インスタンスなどの適切なタイプ/サイズのインスタンスと組み合わせることで、CSPのお客様にとってコストとエネルギーの節約の利益を最大化することができます。AWS での通信事業者の 5G ユースケースの詳細については、 aws.amazon.com/telecom/contact-us にお問い合わせください。 著者について Ashutosh Tulsi Ashutosh Tulsi は、AWS ワールドワイドテレコムビジネスユニットのプリンシパルソリューションアーキテクトであり、通信サービスプロバイダー (CSP) や通信事業者 ISV パートナーと連携しています。彼は 4G/5G ネットワークの AWS クラウドへの移行を支援するソリューションを提供することで、CSP の運用効率向上とコスト効率向上を目標としています。 Neb Miljanovic Neb Miljanovic は、電気通信ベンダーのパブリッククラウドへの移行をサポートする AWS テレコパートナーソリューションアーキテクトです。彼は 4G/5G/IMS コアアーキテクチャに関する豊富な経験を持ち、その経験をクラウドネイティブな原則を使用して 4G/5G/IMS ネットワークファンクションの AWS への移行に応用することを使命としています。 Dr. Young Jung Dr. Young Jung は、AWS ワールドワイドテレコムビジネスユニットのプリンシパルソリューションアーキテクトであり、NFV 分野を専門としており、さまざまなグローバル通信パートナーと協力して、AWS 環境のパートナー向けにクラウドネイティブ 4G/5G NFV ソリューションの作成に貢献しています。 翻訳はソリューションアーキテクトの陳誠が担当しました。

実店舗に終焉はない 顧客の期待と行動が劇的に変化する中、世界中の小売業界は 10 年間変化の危機に瀕しています。パンデミックは、これまで大切にされてきた概念を覆し、オンラインショッピングの台頭を加速させました。現在、デジタル認知度の高い若い顧客の多くが街中に点在しています。逆説的ですが、これは実店舗の終焉を意味するものではありません。 実店舗は依然として小売売上高のほぼ80％を占めています 。 実店舗では、顧客が商品を見たり触れたり、パーソナライズされたサービスを楽しんだり、ブランドを体験したり、ソーシャルインタラクションを促進したりすることができます。そのため、一部の小売業者は、この新しくて不確実な環境で成功するために、ビジネス戦略において実店舗をリファクタリングしました。たとえば、 IKEA は市内中心部に複数の新しい店舗をオープンしており、オンラインプレーヤーは、この傾向に乗じて 実店舗に進出 しています。 小売業界が、物理チャネルとデジタルチャネルを統合し、顧客体験を向上させてビジネスの成長を促進するという変革を遂げているのも不思議ではありません。過去のサイロ化されたモデルは、もはや意味がありません。 オムニチャネル戦略は、消費者が期待する一貫性のあるシームレスな体験を提供するために、小売業界で徐々に普及しつつあります。Forresterによると 、将来の小売売上高の70％は「デジタルによる影響」を受ける可能性が高い とのことです。オムニチャネルの顧客は、1つのチャネルしか利用しない顧客よりも1.7倍の買い物をしているという結果が出ています。そのため、米国の小売業者は、 2021年に閉店した店舗数の約2倍の店舗出店を発表 したのです。 AWSとInfosysは、スマートストアの開拓を支援できます アマゾンウェブサービス（AWS）を活用したスマートストアソリューションの登場 は、将来の小売業界での成功を目指す小売業者にとって魅力的なソリューションとなっています。スマートストアソリューションは、クラウドベースのテクノロジーを活用して顧客と小売業者の両方の店舗体験を向上させる次世代の実店舗イノベーションとして機能します。次世代デジタルサービスの世界的リーダーである Infosys は、AWSと協力して、小売業者が実店舗の変革の可能性を最大限に引き出せるよう支援しています。 スマートストア戦略を採用し、業界におけるInfosysの長年の専門知識を活用することで、小売業者は最先端のテクノロジーとデータ主導の知見を活用して、オペレーションパフォーマンスを向上させ、ビジネスの成長を促進することができます。Infosysは、当社で最も実績があり経験豊富な AWS パートナーの 1 つとして、小売業者が AWS の機能を活用してスマートストアの可能性を解き放ち、最終的に小売業界での持続的な成功への道を開く上で重要な役割を果たしています。 最近の ブログ と 電子書籍「スマートストアの力を生かす」 で強調されているように、AWS スマートストアは次の 3 つの柱に基づいています。 店舗でのデジタル 店舗運営の強化 スムーズなチェックアウト AWSとInfosysは、これらの柱を支えるソリューションを提供できます。これらのソリューションは小売業者にとって以下のことを支援します。 業務と顧客イニシアティブの調整 差別化された、テクノロジーを活用した店舗内戦略の構築 効率性の向上 財務の改善 競争上の優位性を獲得 AWS と小売コンピテンシーパートナー の Infosys が、小売に焦点を当てたさまざまなサービスを通じて、小売業者のスマートストア導入をどのようにサポートできるかを見てみましょう。 店舗におけるデジタル InfosysのEquinox ソリューションは、あらゆるチャネルやタッチポイントでB2BやB2Cのバイヤーに、高度にパーソナライズされた充実したエクスペリエンスをサポートし、人間中心のデジタルコマースおよびマーケティングプラットフォームを提供します。将来を見据えた柔軟なInfosys Equinoxは、MACH-Xソリューション（マイクロサービス、APIファースト、クラウドネイティブ、ヘッドレス拡張を、オープンソーステクノロジー上に構築） 図1 — Infosys Equinoxは、ヘッドレスで人間中心のクラウドネイティブなデジタルコマースおよびマーケティングプラットフォームです。 店舗運営の強化 店舗管理者向けInfosys Intelligent Store Cockpit は、在庫、顧客の注文、人件費、バックオフィス全体にわたる統合的な洞察に基づく意思決定を可能にします。予測分析は店舗の混乱を防ぎ、スマートなバックオフィス業務はデータの不一致を最小限に抑えます。 エネルギー管理と設備監視は、スマートストアが先導するもう 2 つのオペレーション分野です。 Infosys EcoWatch は、直感的で使いやすいクラウドプラットフォームです。サステナビリティ計画、環境、社会、ガバナンス（ESG）レポート、パフォーマンス管理、分析、ダッシュボード、レポートと開示、ステークホルダー管理などの機能に対応しています。EcoWatchは、企業が将来を見据えたビジネス成果に向けて持続可能性に関するコンプライアンスを測定、管理、報告できるようにするテクノロジーイネーブラーです。 図 2 — Infosys EcoWatch プラットフォーム スムーズなチェックアウト Infosys Extended Store は、AWS上で稼働する店舗内のモバイル顧客チェックアウト体験を提供します。このクラウドベースのアプリケーションは、オンラインショッピングの利便性スピードと、顧客が楽しめる店舗での体験を融合させています。顧客は店舗を訪問してスマートフォンを使って商品をスキャンし、価格や実施中のプロモーションを確認したり、閲覧や買い物行動に基づいて商品に関するおすすめを受け取ったりできます。また、携帯電話からも支払いが可能なため、顧客は自分の判断で店員とやり取りできます。Extended Storeは、店舗内とオンライン体験を融合させた、どの小売業者でも使用できるフリクションレスなショッピング体験プラットフォームです。 図3 — Infosys Extended Storeは、セルフサービスと非接触型チェックアウトを可能にすることで顧客体験を向上させます Infosys Metaverse Foundry のInfosys XR視覚化プラットフォームは、ショールームの設計からeコマースサイトでの仮想試着技術の実現まで、さまざまな機能を備えた素材の3D視覚化を可能にするクラウドネイティブなオムニチャネルソリューションです。 店舗ナビゲーション用の Infosys自律システムプラットフォームSTALLY (Store Ally) : 最適化された小売アプリケーション向けの、自律的で費用対効果が高く、用途が広く、スケーラブルなプラットフォームです。STALLYはマルチモーダルの店内アシスタンスを提供し、お客様が商品の所在地を検索したり、店内ナビゲーションを行ったりするのに役立ちます。店舗マップやプラノグラムのデジタル化、買い物リスト内の商品の配置や商品リストを検索するモバイルアプリについて説明します。また、ガイド機能とセルフナビゲーション機能により、すべての製品ロケーションをカバーする最適なルートを計画できる自律型カートも備えています。 コンピュータビジョン 主導型トラッキング：店舗のCCTVカメラを搭載したコンピュータビジョンにより、小売店は顧客を識別し、その動きトラックし、ほぼリアルタイムのニーズ評価に基づいて状況に応じた支援を提供できます。また、プラノグラムコンプライアンス、トラフィック分析、小売収縮などの機能も含まれています。Infosysは、小売業者が実店舗でこれらのユースケースを実現できるようサポートできます。 小売業者がスマートストアに命を吹き込むのを支援する AWS とInfosysは、スマートストア戦略を実施する小売業者に、画期的なガイダンス、サービス、エクスペリエンスを提供しています。両社は協力して、顧客体験の向上、市場の変化への機敏な対応、オペレーション効率の向上を実現する包括的なソリューションポートフォリオを提供します。高度なテクノロジーとドメイン知識を活用することで、小売業者はパーソナライズされたエクスペリエンス、シームレスなオムニチャネルインタラクション、カスタマイズされたオファーを提供して、顧客ロイヤルティを高めることができます。 aws.amazon.com/retail/ で詳細を確認するか、 AWS と Infosys Retail にお問い合わせください。 Further Reading AWS でInfosysをご覧ください Kmart Australiaがマイクロフォーカスソリューションを使用してAWSへの移行を加速 Infosys Equinox でRetail 向けのマイクロサービスアーキテクチャを構築する方法 Infosys・エクイノックスとAWSで消費者直販戦略を成功に導く方法 小売業者がInfosys Cortex と Amazon Connect を使用してインテリジェントコンタクトセンターを構築する方法 レガシーワークロードの移行、クラウドネイティブアプリケーションの開発、AWS でのモダナイゼーション Justin Swaler Justin Swaler は、AWS のワールドワイド・フィジカル・リテール部門長として、フィジカル・リテールのグローバル戦略とソートリーダーシップをリードしています。Justin は、イノベーション戦略、リテールオペレーション、製品開発、エグゼクティブリーダーシップなど、消費財、リテール、戦略分野で15年以上の経験を持ちます。消費者体験を戦略的に革新し、組織を改革することに情熱を注いでいます。イリノイ大学アーバナ・シャンペーン校で学士号、ケロッグ経営大学院でMBAを取得しています。 Ravindar Vanam Ravindar Vanamは、Infosys のコンシューマー、Retail、ロジスティクスのシニアディレクターです。小売業界の変革と店舗体験戦略を主導し、InfosysとAWSクラウドソリューションの総合的な専門知識を活用して、革新的なソリューションとサービスを顧客に提案することを専門としています。彼はさまざまなグローバル小売ブランドで25年以上働いてきた経験があり、小売業者の特定のニーズと課題を理解するのに役立ちます。 翻訳はソリューションアーキテクトの齋藤が担当いたしました。 原文 はこちらです。

なりすましや悪質業者の世界では、 AWS Amplify と Amplify UI FaceLivenessDetector コンポーネントが、本物のユーザーによってアプリが使用されているか確認するのに役立ちます。この一連のコンポーネントライブラリは、 Amazon Rekognition Face Liveness の機能を利用しています。機械学習や人工知能 (AI) の経験は必要ありません。 この完全にマネージドな機能は、なりすましを検出するのに利用する自分の顔を撮るために正面カメラを使用します。いくつかの簡単なステップで、React、Android、Swift アプリケーションにこの機能を追加できます。 このチュートリアルでは、アプリケーションにサインアップしたユーザーを認証する方法を紹介します。そのために新しいNext.js アプリを作成し、Amplify を設定し、認証機能を追加し、FaceLivenessDetector コンポーネントを追加します。AWS Lambda REST API を使用して、 Amazon Rekognition Liveness の機能と通信するエンドポイントを作成します。これらのエンドポイントは、ユーザーが本物かどうかを判断するのに役立つスコアを返却します。 前提条件 このチュートリアルでは以下のものが必要となります。 利用中の AWS アカウント NPM を利用してインストールされた Node アプリと権限の設定 まず、新しい Next.js アプリケーションを作成しましょう！このチュートリアルでは npm を使いますが、お好きなパッケージマネージャを使ってください。 $ npx create-next-app@latest --no-app このアプリケーションでは、Amplify で必要に応じて使用できる App Router は使用しません。Amplify で App Router を使用する際の詳細については、 Amplify UI Docs をご覧ください。 新しくできた Next アプリのディレクトリへ移動し、Amplify ライブラリをインストールします。 $ npm i @aws-amplify/ui-react-liveness @aws-amplify/ui-react aws-amplify まだインストールしていない場合は、Amplify CLI もインストールします。 $ npm i @aws-amplify/cli -g この先の手順には AWS アカウントが必要です。 こちら からサインアップすることができます。また、初めて Amplify CLI を使用する場合は、必ず amplify configure を実行してください。 Next アプリが Amplify を認識するように設定しましょう。ここでは CLI を使いますが、 Amplify Studio を使うこともできます。 init コマンドを実行します。 amplify init ? Enter a name for the project livenessnextexampleg The following configuration will be applied: Project information | Name: livenessnextexampleg | Environment: dev | Default editor: Visual Studio Code | App type: javascript | Javascript framework: react | Source Directory Path: src | Distribution Directory Path: build | Build Command: npm run-script build | Start Command: npm run-script start ? Initialize the project with the above configuration? Yes Using default provider awscloudformation ? Select the authentication method you want to use: AWS profile 全ての項目でデフォルトを選択し、進めることができます。こちらの手順でアプリ内に amplify フォルダが作成され、 src フォルダ内に aws-exports ファイルが作成されます。 Liveness のための認証機能を追加 認証されたユーザのみ FaceLivenessDetector コンポーネントを使用できるように、 Auth カテゴリ を追加しましょう。これにより、あなたのアカウントの下に Amazon Cognito ユーザーと ID プールが作成されます。 以下のコマンドを実行してください。 $ amplify add auth 電子メールとその他全ての設問をデフォルトの設定で選択します。 必ず変更をプッシュしてください！ $ amplify push 認証されていないユーザに Liveness の使用を許可する場合は、代わりに Manual Configuration を選択することをお勧めします。最も重要なプロンプトは Allow unauthenticated logins です。ここでは必ず Yes を選択してください。これでログインせずに Liveness サービスを使用できるようになります。また、未認証ロールの正しい権限をセットアップする必要があります。IAM 権限のセットアップで、 authRole の代わりに amplify-<project_name>-<env_name>-<id>-unauthRole を更新します。IAM 権限のセットアップ方法の詳細は次のセクションで説明します。 IAM 権限の設定 認証機能の追加後、IAM ロールを少し変更する必要があります。 authRole に Amazon Rekognition Face Liveness サービスへのアクセス権を与える必要があります。このロールはフロントエンドの権限として使用されます。 console コマンドを実行して AWS コンソールを開きます。 $ amplify console マネジメントコンソールが開いたら、 IAM を検索して開きます。 Roles をクリックし、あなたのために作成された Amplify ロールを検索してクリックします。これは、 amplify-<project_name>-<env_name>-<id>-authRole という形式になっており、 <project_name> 、 <env_name> 、 <id> を自分の情報に置き換えて検索してください。 Add Permissions を選択し、 Create Inline Policy を選択し、 JSON タブを選択し、以下を貼り付けます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "rekognition:StartFaceLivenessSession" ], "Resource": "*" } ] } これにより、Rekognition サービスの開始、作成、および結果の取得の権限のみが与えられます。次に Review Policy を選択し、 Create Policy を選択します。 AWS Lambda バックエンド 権限と認証の設定ができたので、バックエンドアプリケーションを作成しましょう。Express を実行する Node.js の AWS Lambda Function を使用して REST API を追加します。Express クライアントを使用して、いくつかのエンドポイントをセットアップし、顔検出の結果を取得します。 ターミナルを開き、add api コマンドを実行します。 $ amplify add api 以下のオプションを選択してください。必ず /session エンドポイントを追加し、テンプレートとして Serverless ExpressJS function を選択してください。選択したカテゴリのラベルを記録しておいてください。後ほどフロントエンドのコードと接続するときに必要になります。 ? Select from one of the below mentioned services: REST Provide a friendly name for your resource to be used as a label for this category in the project: ·liveness Provide a path (e.g., /book/{isbn}): · /session Only one option for [Choose a Lambda source]. Selecting [Create a new Lambda function]. ? Provide an AWS Lambda function name: liveness ? Choose the runtime that you want to use: NodeJS ? Choose the function template that you want to use: Serverless ExpressJS function (Integration with API Gateway) Available advanced settings: - Resource access permissions - Scheduled recurring invocation - Lambda layers configuration - Environment variables configuration - Secret values configuration ? Do you want to configure advanced settings? No ? Do you want to edit the local lambda function now? Yes API Gateway とLambda Function 用の新しいフォルダがいくつか生成されます。 新しいライブラリを追加することから始めていきましょう。 amplify/backend/function/liveness/src フォルダに移動し、以下のコマンドを実行して Rekognition クライアントの正しい依存関係をインストールします。 $ npm i @aws-sdk/client-rekognition 先ほど作成した関数を更新する必要があります。 amplify/backend/function/liveness/src フォルダに移動します。 utils フォルダを追加し、 getRekognitionClient.js という新しいファイルを作成します。 以下のコードを追加します。このコードは Amplify アプリケーションを設定し、新しい Rekognition クライアントを作成しています。 const { Rekognition } = require("@aws-sdk/client-rekognition"); const getRekognitionClient = () => { const rekognitionClient = new Rekognition({ region: 'us-east-1' }); return rekognitionClient; }; module.exports = getRekognitionClient; 上記のコードスニペットの region をあなたのリージョンに合わせて更新してください。リージョンはバックエンドとフロントエンドのコード間で一致していなければならず、 FAQ に示されているように、そのリージョンで liveness が利用可能でなければなりません。 amplify/backend/function/liveness/src フォルダで app.js ファイルを開いてください。いくつかの GET、POST、PUT、DELETE のサンプル関数が表示されます。サンプル関数は削除してかまいません。独自の関数を追加します。 ファイルの先頭に import を追加します。これで、先ほど作成したユーティリティ関数を取り込むことができます。 const getRekognitionClient = require("./utils/getRekognitionClient"); create エンドポイントと get エンドポイントを追加しましょう。 create エンドポイントは新しい Liveness セッションを作成し、フロントエンドに返却します。 get エンドポイントは信頼値を計算し、返却します。 app.get("/session/create", async function (req, res) { const rekognition = getRekognitionClient(); const response = await rekognition.createFaceLivenessSession({}); return res.status(200).json({ sessionId: response.SessionId, }); }); app.get("/session/get", async function (req, res) { const rekognition = getRekognitionClient(); const response = await rekognition.getFaceLivenessSessionResults({ SessionId: req.query.sessionId, }); const isLive = response.Confidence > 90; res.status(200).json({ isLive }); }); ここでは Confidence の値にのみ注目していますが、必要に応じて API から監査画像や参考画像の境界ボックスなど、他の値を取得することもできます。 この例では、信頼度スコアが 90 以上であれば、その画像は実際のユーザーのものであると判断します。これは厳密なルールではないので、アプリケーションやそのニーズに応じて信頼度を高くしたり低くしたりする必要があるかもしれません。また、バックエンドの他の部分に対する将来のリクエストを認可する方法として、信頼度 ( Confidence ) の値を使用することもできます。 最後に、正しいポリシーを設定する必要があります。こちらのファイルを開いてください。 amplify/backend/function/liveness/custom-policies.json こちらのポリシーを入力してください　。これで Lambda は Liveness セッションの作成と結果取得のみできるようになります。 [ { "Action": [ "rekognition:CreateFaceLivenessSession", "rekognition:GetFaceLivenessSessionResults" ], "Resource": ["*"] } ] このファイルを保存し、変更をプッシュアップしてください！ $ amplify push フロントエンドのコードに移りましょう！ Next.js フロントエンド バックエンドが完成したので、次はフロントエンドのサインアップページを作成します。 Amplify Authenticator コンポーネントと FaceLivenessDetector を使用して、このプロセスをより簡単にします。 Next.js を利用する Amplify の設定 _app.tsx ファイルを開き、以下のコードを追加しましょう。 import type { AppProps } from "next/app"; import { Amplify } from "aws-amplify"; import { withAuthenticator } from "@aws-amplify/ui-react"; import "@aws-amplify/ui-react/styles.css"; import awsExports from "../aws-exports"; Amplify.configure(awsExports); function App({ Component, pageProps }: AppProps) { return <Component {...pageProps} />; } export default withAuthenticator(App); withAuthenticator 高階コンポーネントは、アプリケーション全体をラップし、サインインしたユーザーだけが先に進めるようにします。また、 Amplify.configure(awsExports) を実行してフロントエンドを設定し、先ほど追加した AWS の認証サービスとやり取りができるようにします。最後に、 @aws-amplify/ui-react/styles.css からスタイルをインポートします。 Next アプリケーションを起動すると、このようなログインページが表示されます。 Authenticator 続けて、 src に components という新しいフォルダを作成し、その中に Liveness.tsx という新しいファイルを追加します。 以下のコードを追加します。 import { useEffect, useState } from "react"; import { Loader, Heading } from "@aws-amplify/ui-react"; import { FaceLivenessDetector } from "@aws-amplify/ui-react-liveness"; import { API } from "aws-amplify"; export function LivenessQuickStart() { const [loading, setLoading] = useState<boolean>(true); const [sessionId, setSessionId] = useState<{ sessionId: string; } | null>(null); const [success, setSuccess] = useState(''); useEffect(() => { const fetchCreateLiveness = async () => { const response = await API.get("liveness", "/session/create", {}); setSessionId(response); setLoading(false); }; fetchCreateLiveness(); }, []); const handleAnalysisComplete = async () => { const data = await API.get("liveness", "/session/get", { queryStringParameters: { sessionId: sessionId?.sessionId, }, }); if (data.isLive) { setSuccess("User is live"); console.log("live"); } else { setSuccess("User is not live"); console.log("not live"); } }; const handleError = (error: Error) => { console.log("got error", error); }; return ( <> {loading ? ( <Loader /> ) : ( <> <FaceLivenessDetector sessionId={sessionId?.sessionId ?? "1"} region="us-east-1" onAnalysisComplete={handleAnalysisComplete} onError={handleError} /> <Heading level={2}>{success}</Heading> </> )} </> ); } 上記コードの region をあなたが利用しているリージョンに合わせて変更してください。リージョンはバックエンドで使用しているものと同じでなければなりません。 このコードはページが読み込みされるとすぐに /session/create を呼び出し、セッション情報を取得して createLivenessApiData useState に保存します。また、ローディングスピナーも削除します。 liveness は、REST api を追加したときに設定した API Gateway の名前です。この文字列は、選択した API Gateway に合わせて自由に変更してください。この値は aws-exports ファイルの aws_cloud_logic_custom にも記載されています。 handleAnalysisComplete 関数は、 sessionId を使って /session/get エンドポイントを呼び出し、信頼度スコア を返します。これは、次に何をすべきか決定するのに役立ちます。 このチュートリアルでは、返されたスコアに応じて ユーザーがいるかユーザーがいないのか をコンソールログに出力します。実世界の状況では、これを別の方法で処理したくなるかもしれませんし、スコアが低すぎる場合はユーザーに再試行させたくなるかもしれません。 最後に、この新しい Liveness コンポーネントをアプリケーションに追加してみましょう。 index.tsx ファイルを開き、以下のコードを追加します。 import { LivenessQuickStart } from "@/components/Liveness"; import { Button, useAuthenticator, View } from "@aws-amplify/ui-react"; export default function Home() { const { signOut } = useAuthenticator((context) => [context.signOut]); return ( <View width="600px" margin="0 auto"> <LivenessQuickStart /> <Button onClick={signOut} variation="warning"> Sign Out </Button> </View> ); } 全部試してみましょう！ テストする すべてのコードを更新した後、Next アプリを起動し、 localhost:3000 を開いて Create Account タブをクリックし、新規ユーザーを作成します。 サインアップ後、このページが表示されます。 顔検証の手順 このページが表示されない場合は、このページに影響を与えている可能性があるグローバルスタイルをすべて消去する必要があるかもしれません。 Begin check ボタンをクリックします。すると、もっと近づくように指示されます。あなたの顔が楕円で完全に埋まるように、できるだけ近づいてください。 楕円状の顔チェック すべてがうまくいけば、いくつかのフラッシュが表示され、コンソールにスコアが返されます！ページを更新して再挑戦することもできます。 クリーンアップ アプリケーションの検証が終わったら、 amplify delete を実行することで全てのリソースを削除することができます。 まとめ このチュートリアルでは、Next.js と REST API を使って Amplify Face Liveness コンポーネントをセットアップする方法を見てきました。Liveness についてさらに学びたい場合は、 公式ドキュメント をご覧ください。そこから、 国際化対応 や テーマ設定 など、 FaceLivenessDetector コンポーネント を完全にカスタマイズする方法について学ぶことができます。 Amplify についてもっと知りたい方は ドキュメント をご覧ください。また、 AWS の無料枠 で Amplify を試すこともできます。 私についての情報は Twitter の ErikCH で見ることができます！ この記事は、 Detect real users with AWS Amplify and Face Liveness を翻訳したものです。 翻訳はSolutions Architect の Takuya Setaka が担当しました。