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

AWS Migration Hub Orchestrator を使用する理由 世界中の何千ものお客様が、ミッションクリティカルな SAP アプリケーションの実行に AWS を信頼しています。まだオンプレミスの SAP アプリケーションについては、多くのお客様が AWS と SAP のベストプラクティスに従いながら、より簡単に AWS に移行する方法を求めています。 AWS Migration Hub Orchestrator for SAP は、手動タスクの多くを排除し、移行中に関係するさまざまなツール間の依存関係を管理し、移行の進捗状況を 1 か所で確認できるようにすることで、AWS への移行に必要な時間と労力を削減します。 このブログでは、AWS Migration Hub Orchestrator の仕組み、アーキテクチャ、サポートされている移行パターン、前提条件、および全体的な移行プロセスについて説明します。 AWS ソリューションの概要 AWS Migration Hub Orchestrator は、サーバーとエンタープライズアプリケーションの AWS への移行を簡素化および自動化し、移行を一元的に管理および追跡できます。 AWS Migration Hub Orchestrator を使用すると、SAP S/4HANA、SAP BW/4HANA、および SAP ERP on HANA などの SAP HANA ベースの SAP Netweaver アプリケーションを AWS に移行できます。AnyDB を使用して SAP アプリケーションを Amazon EC2 にリホストすることもできます。Migration Hub Orchestrator には、実証済みの SAP 移行のベストプラクティスに基づいた定義済みのワークフローテンプレートが用意されています。さらに、特定の移行要件に応じてステップを追加、並べ替え、または削除することで、移行ワークフローをカスタマイズできます。 Migration Hub Orchestrator がサポートする機能: HANA ベースのテンプレート駆動型 SAP NetWeaver アプリケーションのオンプレミスから AWS への移行 移行方法論とツールにより、技術的なダウンタイムと前後の手動タスクが最小限に抑えられます ワークフローのカスタマイズにより、お客様はお客様固有の移行タスクを実行する手順を追加することができます ソースシステムとターゲットシステム間の移行について、複数のアーキテクチャパターンをサポートします アプリケーションのパフォーマンスと可用性の要件を満たすように、必要に応じてターゲットシステム/SAP システムのコンポーネントのサイズを調整できます オペレーティング・システム・バージョンまたは Linux ディストリビューションの変更をサポートします たとえば、SUSE から RHEL へ、SLES 12 SP4 から SLES 15 SP1 へ 移行中の新しいマイナー HANA バージョンへのアップグレードをサポートします 例:HANA 2.0 SPS01 から HANA 2.0 SPS05 へ ソースシステムとターゲットシステムでサポートされている SAP アプリケーションアーキテクチャ: シングルノード — SAP アプリケーションまたは HANA データベースをシングルノードにデプロイします マルチノード — SAP アプリケーションまたは HANA データベースを異なるノードにデプロイします 高可用性 — SAP アプリケーションまたは HANA データベースを高可用性モードでマルチノードにデプロイします AWS Migration Hub Orchestrator を使用した SAP 移行アーキテクチャ: AWS Migration Hub Orchestrator は、 SAP のネイティブ HANA システムレプリケーション メカニズムを活用してソースとターゲット HANA システム間のデータレプリケーションを設定することにより、SAP HANA ベースの SAP NetWeaver システムを AWS に移行します。移行中は、AWS Launch Wizard for SAP を使用して SAP NetWeaver アプリケーションをホストするターゲット環境を AWS に設定する方法も案内されます。 AWS Migration Hub Orchestrator は現在、HANA データベースと SAP アプリケーションについて以下のソース/ターゲットパターンをサポートしています。 Source System Configuration (HANA Only) Target System Configuration (HANA Only) HANA scale-up/single node HANA scale-up/single node HANA scale-up/single node HANA HANA with High Availability HANA scale-out/multi-node HANA scale-out/multi-node HANA with High Availability HANA with High Availability Source System Configuration (SAP Application and HANA DB) Target System Configuration (SAP Application and HANA DB) SAP central system SAP central system SAP central system SAP distributed system SAP central system SAP application with High Availability SAP distributed system SAP distributed system SAP distributed system SAP applications with High Availability SAP applications with High Availability SAP applications with High Availability 図:マイグレーションハブオーケストレータを使用したシングルノード HANA からシングルノード HANA への移行のアーキテクチャ例 移行前のセットアップと前提条件: お客様は、SAP アプリケーションの移行を開始する前に、一般設定と 1 回限りのセットアップ作業が完了していることを確認する必要があります。 一般設定: オンプレミスと AWS 仮想プライベートクラウド (VPC) およびアカウント間のネットワークレベルの通信を可能にする AWS Direct Connect または AWS VPN SAP HANA システムレプリケーションの前提条件: ソースシステムとターゲットシステムの両方がインストールされ、構成されており、両方が独立して稼働していることを確認してください。 ターゲットシステムは、プライマリシステムと同じ SAP システム ID とインスタンス番号を持っている必要があります。 セカンダリ HANA DB の HANA データベースバージョンは、プライマリサーバーのバージョンと同じかそれ以上でなければなりません。 SAP HANA システムレプリケーションの 前提条件 の詳細については、SAP のドキュメントを参照してください。 ネットワーク要件: ソースとターゲットの SAP Elastic Compute Cloud (EC2) インスタンスは、プラグインサーバーからの SSH ポート 22 経由の通信を許可する必要があります。 API 呼び出しを通じて AWS Migration Hub Orchestrator サービスと通信するには、プラグインサーバーが HTTPS インバウンドおよびアウトバウンド TCP 443 ポートを使用してインターネットに接続する必要があります。 初回セットアップ作業: Migration Hub Orchestrator コンソールにアクセスするには、AWS Identity and Access Management (IAM) 権限が必要です。これらの権限により、AWS アカウントのマイグレーションハブオーケストレータリソースに関する詳細を一覧表示したり表示したりできる必要があります。ユーザーは IAM の前提条件 を満たす必要があります。 Migration Hub Orchestrator プラグインは、オンプレミスの VMware vCenter 環境にインストール ( セットアップ ) できる仮想アプライアンスです。このプラグインは、移行プロセス中にソース SAP システムでの移行アクティビティを調整します。 デプロイしたら、AWS コンソールのプラグインセクションでプラグインのステータスがアクティブであることを確認してください。 SAP ソースサーバーを検出: 移行の最初のステップは、オンプレミスの SAP サーバーの情報を検出し、検出されたサーバーを移行および追跡するアプリケーションにグループ化することです。AWS Migration Hub は、 AWS 検出ツール によるアプリケーション検出をサポートしています。 手順 に従って検出方法を選択し、移行予定のすべてのサーバーの検出を完了してください。 以下の図に示すように、検出プロセスの最後までに SAP ソースサーバーが検出ツールに表示される必要があります。 検出された SAP アプリケーションとデータベースサーバーは、「Applications」の下にグループ化する必要があります。AWS Migration Hub Orchestrator は「Application Name」を使用して定義済みのソースシステムを識別し、ターゲット AWS ランディングゾーンに移行します。 アプリケーション移行フェーズの準備: ソース HANA データベースの認証情報とターゲットシステムのキーペアが AWS Secrets Manager で管理されていることを確認します。 前提条件の手順 に従ってください。 キーペア名とシークレット名は同じでなければなりません。 たとえば、キーペア名「migrationhub-orchestrator-keyname123」など。 たとえば、シークレット名「migrationhub-orchestrator-keyname123」など。 (重要:キーペアは migrationhub-orchestrator-というプレフィックスで始まる必要があり、その後に英数字値が続く必要があります)。 AWS Launch Wizard for SAP を使用してターゲット SAP ランドスケープを AWS にデプロイし、デプロイ名はわかりやすいようにしておきます。移行プロセスでは、移行プロセス中にターゲットシステムのデプロイ名の入力を求められます。 移行プロセスでは、SAP HANA システムレプリケーションを利用してオンプレミスサーバーから AWS にデータを移行します。デプロイされたターゲットシステムは、「SAP HANA システムレプリケーションを設定するための一般的な前提条件」に記載されている HANA システムレプリケーションの前提条件を満たしています。 前提条件情報 については、SAP リファレンスリンクを参照してください。 SAP アプリケーションフェーズの移行: Migration Hub コンソールに移動し、「Orchestrator」→「Create Migration workflow」を選択します。 「Migrate SAP NetWeaver applications to AWS」テンプレートを選択し、「Next」をクリックします。 ワークフローの名前と説明を入力します。 Application name : 検出フェーズの移行前のアクティビティステップで作成されたアプリケーション名を選択します。 要件に応じて移行タイプを選択します。 ソース SAP アプリケーション情報を提供: AWS ADS Server ID for SAP application server: ソース SAP アプリケーションサーバーを選択します。 SAP system ID: ソース SAP SID を指定します。 SAP application hostname: ソース SAP アプリケーションのホスト名を指定します。 SAP HANA データベース構成を指定します。 HSR 用 SSL を無効にする場合は「I want to disable SSL encryption for database replication」チェックボックスを選択し、HSR 用 SSL を有効にする場合はオフのままにします。 SAP HANA replication mode: 要件に応じて [非同期] または [同期] を選択します。 HANA system ID (HANASID): ソース HANA SID Instance Number: ソース HANA インスタンス番号 Database hostname: ソース HANA データベースのホスト名 AWS ADS Server ID for SAP HANA database: ソース SAP HANA サーバーのホスト名 Credentials: 前提条件の一部として作成されたシークレット名を選択します。 Backup location: HANA データベースのバックアップ場所 (例:/backup) データベースレプリケーションで SSL 暗号化を選択する場合は、下部にある [Next] ボタンをクリックする前に、ターゲット HANA システムの global.ini ファイルの system_replication セクションにある enable_ssl パラメーターが ON に設定されていることを確認してください。データベースレプリケーションの SSL をオプトアウトする場合は、「“I want to disable SSL encryption for database replication」チェックボックスを選択するだけで、この設定ではパラメーターを調整する必要はありません。 [Next] をクリックして確認し、ワークフローを使用して移行を開始します。 ワークフローの入力内容を確認し、[Create] を選択します。 新しく作成したワークフローを選択し、[Actions]-&gt; [Run] オプションに移動して移行プロセスを開始します。 Migration Hub Orchestrator は、ほとんどのワークフローステップを自動化して移行プロセスを自動化します。追加の入力やユーザー操作が必要なため、一部のステップは手動です。ワークフローを完了するには、ワークフローのすべてのステップを実行する必要があります。 完了したワークフローの例は、下図のようなステータスになります。 よくある問題のトラブルシューティングと FAQ: 手順「Verify HANA System Replication status task status」が失敗しました ソース SAP および HANA システムにログインし、ターゲット SAP および HANA システムに ping を送信します。 ソースとターゲットの両方の SAP システムにプラグインサーバーからアクセスできることを確認します。 AWS セキュリティグループを検証し、プラグインサーバーから SAP ソースシステムとターゲットシステムの両方へのポート 22 の通信を許可します。 &lt;hdbadm&gt;としてログインして systemReplicationStatus.py を実行します。レプリケーションが行われておらず、ステータスが「initialization」の場合は、ターゲットシステムの HANA DB が稼働しているかどうかを確認してください。レプリケーションを開始するには、ターゲット HANA DB が稼働している必要があります。 &lt;hdbadm&gt;としてログインし、ステータスが「registration status of secondary host not available」の場合は HDBSettings.sh systemReplicationStatus.py を実行し、ソースシステムとターゲットシステムで /etc/hosts エントリが更新されていることを確認します。 プラグインはターゲット HANA システムにログインできません。 ターゲットシステムのシークレットマネージャーで指定したキーペア名が、ステップ 2.d で指定した名前と同期していることを確認します。 ターゲット SAP/HANA システムのセキュリティグループを検証し、プラグインサーバーからポート 22 を許可してください 失敗したステップを再試行するには? 失敗したステップのステータスをクリックし、再試行オプションを選択します。 ソースシステムに関連する失敗したステップのログはどこにありますか? 失敗したステップログは Amazon S3 バケットにあり、バケットのパスは以下のようにステータスメッセージの下に表示されます。 ターゲットシステムに関連する失敗したステップのログはどこにありますか? ターゲットシステムに関連する失敗したステップのログは、以下のように AWS Systems Manager の「Run Command」-&gt;「Command History」に記録されます。 結論: このブログでは、Migration Hub Orchestrator を使用して SAP HANA ベースのアプリケーションの AWS への移行を簡素化および自動化する方法を学びました。 AWS Migration Hub Orchestrator の詳細については、 AWS Migration Hub ページにアクセスするか、この ショート動画 をご覧ください。 このブログは、Pravin Yadav とChandrasekhar Chittuluru が共同執筆し、Partner SA 松本が翻訳しました。原文は こちら です。

この記事は AWS for Games updates from re:Invent 2023 を翻訳したものです。 AWS re:Invent 2023において、AWS for Games チームはお客様が AWS のゲーム開発ツールを使用している最新の方法を紹介し、現在 AWS Games Solutions Library で利用可能ないくつかの新しい専門的なガイダンスとパートナーソリューションを紹介しました。 AWS re:Invent 2023 における AWS for Games のお客様セッション動画には以下のものが含まれます。 Customer Keynote – Riot Games : Riot Games のグローバルインフラストラクチャおよび運用責任者である Brent Rich 氏は、スケジュールや優先順位の変更に直面しながらも、Riot と AWS の関係性がプレイヤーエクスペリエンスをどのように向上させたかについて語りました。 Exiting the data center: A League of Legends and VALORANT story : Riot Games が二つの大規模なゲームを中断することなくオンプレミスからクラウドに移行した方法について詳しく紹介されています。 Scaling Warhammer 40,000: Darktide from 0 to 100,000 players in 1 hour : Fatshark がサーバーレスなバックエンドアーキテクチャ、 Amazon GameLift 、 AWS Global Accelerator を使用して、数百万人のプレイヤー向けにゲームをどのようにスケーリングさせたかを知ることができます。 Modernization of Nintendo eShop: microservice and platform engineering : 任天堂がどのようにモノリシックアーキテクチャからマイクロサービスアーキテクチャに移行し、Nintendo Switch やその他の任天堂プラットフォームにある Nintendo eShop を強化したかを知ることができます。 Scaling a multiplayer game into the millions with Mortal Kombat 1 : Warner Bros. Games は、世界中の何百万人ものプレイヤーに向けてバージョンアップした「Mortal Kombat 1」を展開するために必要となったバックエンドのアーキテクチャについて詳しく紹介されています。 Improve your mobile and web app quality using AWS Device Farm : Riot Games は、 AWS Device Farm を使用してモバイルアプリのテストプロセスを合理化し、モバイルゲームと SDK の品質を向上させ、クラウド上の実際のデバイスで自動テストと手動テストを実行し、問題をより迅速に特定して修正し、アップデートをより高い頻度でリリースする方法を詳しく説明しています。 Improving user experience at Epic Games using Amazon Timestream : Epic Games は、 Amazon Timestream のアプリケーションをカバーし、Epic Games Store 全体で何百万人ものゲームプレイヤーのプレイ時間を監視し、そこからインサイトを引き出すためのスケーラブルなソリューションを構築した事例を紹介しています。 How Electronic Arts modernized its data platform with Amazon EMR : Electronic Arts が Amazon EMR に移行することで、HDFS から Amazon S3 へ、500 以上の ETL ジョブを Amazon EMR 上の Apache Spark へと、データプラットフォームをモダナイズした方法を紹介しています。 新しいガイダンスやパートナーソリューションを含む、 AWS Games Solution Library の最新のアップデートには以下が含まれます: Guidance for Game Analytics Pipeline on AWS (GAP V2) : ゲームクライアントやバックエンドサービスからテレメトリイベントを取り込むためのコード化、モジュール化されたサーバーレスの分析パイプラインを実装できます。 Guidance for Non-Player Character (NPC) Dialogue on AWS : ゲームおよび関連するゲーム開発インフラストラクチャ用のノンプレイヤーキャラクター(NPC)を作成するプロセスを自動化します。 Guidance for Identification of Problematic Betting &amp; Gaming on AWS : ゲームプレイヤーを問題のある賭博行為やゲーム内行動から保護するために、自動化された責任あるゲーム向けのメカニズムを作成する方法をデモンストレーションしています。 Guidance for a Game Production Environment on AWS : 可用性が高く低レイテンシーでユーザーに配信される、Unreal Engine 用の全体的なゲーム制作環境の構築を支援します。 AWS re:Invent 2023 の他のセッション動画をご覧になる場合は、 AWS Events content にアクセスしてください。最新の AWS for Games のお客様およびソリューションに関する最新情報については AWS for Games のブログ および LinkedIn をご覧ください。 翻訳はソリューションアーキテクトの渡邉が担当しました。

本ブログは、「 金融機関向け AWS FISC 安全対策基準対応リファレンス 」における「 金融機関等コンピュータシステムの安全対策基準・解説書（第11版） 」（以下、「FISC 安全対策基準・解説書（第11版）」）への対応についてまとめています。また、「 金融リファレンスアーキテクチャ日本版 」における「FISC 安全対策基準・解説書（第11版）」対応の概要についても記載しています。最後に、パートナー様における「金融リファレンスアーキテクチャ日本版」の活用事例をご紹介いたします。 1. FISC 安全対策基準・解説書に関しての AWS およびパートナー様の今までの取り組みの紹介 「FISC 安全対策基準・解説書」は、1985年に初版が発行されて以来、金融機関のシステムアーキテクチャおよび運用に関する指針として多くの金融機関によって活用されています。より安全に AWS をご活用いただくために、AWS は「金融機関向け AWS FISC 安全対策基準対応リファレンス 」を提供しています。これは「FISC 安全対策基準・解説書」が求める各管理策に対する AWS の取り組みとお客様の責任範囲で実施する事項をまとめており、お客様はどなたでも入手することが可能です。 一方、FISC 準拠支援のための AWS パートナーコンソーシアムはセキュリティ領域の知見を持ち寄り、金融業界における安全な AWS 活用を支援するために「 AWS FISC 安全対策基準対応リファレンス 参考文書 」を提供しております。 さらに、「金融リファレンスアーキテクチャ日本版」は、金融で求められるセキュリティと可用性に関するベストプラクティスを提供するフレームワークとして、AWS が 2022年10月に正式版として発表 し、多くのお客様にご利用いただいております。その後、皆様からいただいたご意見を踏まえ、 2023年7月に複数のアップデート を行いました。 AWS では、 Design for failure 等のサービス設計や運用のベストプラクティスを踏まえた AWS Well-Architected フレームワークの提供や、日本における災害対策を踏まえた「 Resiliency in Japan-日本におけるAWSリージョンのレジリエンス- 」ホワイトペーパーの提供等ににより、お客様のコンテンジェンシープランの策定を支援しています。 AWS が公開している FISC 関連の文書の位置付けを以下の表にまとめています。 2. FISC 安全対策基準対応リファレンスと FISC 安全対策基準・解説書（第11版）対応について FISC は、2021年5月に、金融機関の様々なお客様のクラウドの安全な利活用を促進するために、「 金融機関等におけるクラウド導入・運用に関する解説書（試行版） 」を公表しました。その後、2023年5月に、「金融機関等におけるクラウド導入・運用に関する解説書（試行版）」の内容を正式に取り込んだ「FISC 安全対策基準・解説書（第11版）」を公表しました。第10版からの主要な変更点として、「クラウドサービス固有で対応すべき事項や特に留意すべき事項」に関する内容が追加されています。金融機関は、クラウドサービスの機能やクラウドサービスプロパイダーの運用などの情報を取得、確認した上で、クラウドサービスの機能やサードパーティのツールなどを利用して、金融機関が実施すべき手続きや対応を検討する必要があります。 AWS が提供している「金融機関向け AWS FISC 安全対策基準対応リファレンス 」は、「FISC 安全対策基準・解説書」の各項目のうち、AWS のサービスや情報に関連する事項に対して、AWS の対応状況と関連資料参照先の情報提供を行うための資料です。AWS を利用する金融機関のお客様は、当リファレンスを参照して、AWS が「FISC 安全対策基準・解説書」に対応できているかどうかを確認することができます。※1 今回、当リファレンスをアップデートし、「FISC 安全対策基準・解説書（第11版）」に対応する内容の追加を行いました。第11版で追加された「クラウドサービス固有で対応すべき事項や特に留意すべき事項」に対応する際に参考となる、関連する AWS の機能や運用に関する情報、および&nbsp; AWS Well-Architected フレームワークなどのベストプラクティスに関する情報を追加しました。第10版から追加された部分は、当 リファレンス の変更履歴からご確認いただけます。金融機関のお客様は、アップデートされたリファレンスを参照することで、AWS の最新の対応状況をより効率的に確認し、クラウド移行や運用におけるセキュリティ対策の検討に活用することができます。 ※1：「FISC 安全対策基準・解説書」には AWS のサービスが該当しない項目があること、かつ情報システムに対する安全対策の達成目標は、個々の情報システムのリスク特性に応じて、お客様のご判断で適切な内容で決定されるべきであることから、当リファレンスは AWS を利用するお客様が「FISC 安全対策基準・解説書」に準拠できることを保証するものではございません。 3. 金融リファレンスアーキテクチャ日本版と FISC 安全対策基準・解説書（第11版）対応について 「金融リファレンスアーキテクチャ日本版」においても、「FISC 安全対策基準・解説書（第11版）」に対応する内容のアップデートを実施しました。変更点は以下のとおりです。 3.1 AWS Well-Architected フレームワーク FSI Lens for FISC における ベストプラクティス の追加 「AWS Well-Architected フレームワーク FSI Lens for FISC」は、「FISC 安全対策基準・解説書」に沿って、回復力、セキュリティ、および運用パフォーマンスを促進する金融サービス業界 (FSI) のワークロードを設計、デプロイ、設計する方法に焦点を当てたベストプラクティス集です。今回、「FISC 安全対策基準・解説書（第11版）」で追加された内容に対応して、複数のベストプラクティスを追加しました。 AWS Well-Architected フレームワーク FSI Lens for FISC の位置付け 3.2 AWS Well-Architected フレームワーク FSI Lens for FISC における FISC 安全対策基準 実務基準 リファレンス項目一覧表 の最新化 「AWS Well-Architected フレームワーク FSI Lens for FISC」では、「FISC 安全対策基準・解説書」の各実務基準において、参照すべき AWS Well-Architected フレームワーク、AWS Well-Architected フレームワーク FSI Lens for FISC の一覧表を提供しています。今回、「FISC 安全対策基準・解説書（第11版）」で追加された内容に対応して、一覧表の最新化を行いました。 3.3 FISC 安全対策基準 実務基準と AWS Control Tower コントロールの 対応表 の最新化 「FISC 安全対策基準・解説書」の観点から、有効化すべき AWS Control Tower のコントロールを抽出し、対応表を提供しています。今回、2023年10月13日時点の最新のコントロール（459個）に対して、「FISC 安全対策基準・解説書（第11版）」の内容を反映して最新化を行いました。 3.4 BLEA for FSI ガバナンスベース及び各金融ワークロード（ 勘定系 、 顧客チャネル 、 マーケットデータ 、 オープン API 、 データ分析プラットフォーム ）における FISC 安全対策基準 実務基準に対する対策内容一覧の最新化 「FISC 安全対策基準・解説書」の各実務基準に対して、BLEA for FSI ガバナンスベース、および各金融ワークロードにおける対策内容の一覧を提供しています。今回、「FISC 安全対策基準・解説書（第11版）」で追加された内容に対応して、一覧の最新化を行いました。 4. パートナー様での金融リファレンスアーキテクチャ日本版活用について パートナー様での金融リファレンスアーキテクチャ日本版活用について、シンプレクス株式会社様及びキンドリルジャパン株式会社様の事例を紹介いたします。 4.1 シンプレクス株式会社様 シンプレクス株式会社様（以下、Simplex様）では、AWS 上で提供する金融サービスのセキュリティベースラインとして、コストを抑える工夫を取り入れながら金融リファレンスアーキテクチャ日本版の BLEA for FSI を活用されています。さらに、「FISC 安全対策基準・解説書」実務基準の準拠状況を可視化するため AWS Well-Architected フレームワーク FSI Lens for FISC も活用されています。下記活用状況の詳細を記載します。 Simplex様では様々な金融サービスの構築・運用サービスを提供しています。AWS 環境で Simplex様が運用管理する原則全てのアカウントに適用されるセキュリティベースラインとして、Simplex様固有の要件を踏まえた実装に加え、金融リファレンスアーキテクチャ日本版の BLEA for FSI ガバナンスベースのエッセンスを取り入れています。以下ではSimplex様固有の要件とカスタマイズ内容を紹介いたします。 金融リファレンスアーキテクチャ日本版を適用する場合、基本的には AWS Control Tower にアカウントを登録する必要があります。Simplex様では開発当初はAWS環境の作り直しを頻繁に行うため、AWS Control Tower によるセキュリティ評価がその度に実行されコストが増大する課題がありました。この課題を解決すべく、開発フェーズに応じて AWS アカウントに二段階でセキュリティベースラインを適用する方式を採用しています。具体的にはまず AWS アカウント発行時には AWS Control Tower への登録はすぐには実施せず、Amazon GuardDuty 等のセキュリティサービスにて必要最低限のセキュリティ統制を効かせて開発を実施します。次に、開発が進み環境の作り直しが落ちついたタイミングで AWS Control Tower にアカウントを登録し、金融リファレンスアーキテクチャ日本版の BLEA for FSI ガバナンスベースを効かせることで、コストを抑えることを実現しています。 金融機関のお客様に提供するシステムは、FISC 安全対策基準の実務基準に準拠することが求められるケースがあります。Simplex様では AWS Well-Architected フレームワーク FSI Lens for FISC を AWS アカウントに追加適用することで、FISC 実務基準の準拠状況を定量的に可視化しています。 4.2 キンドリルジャパン株式会社様 キンドリルジャパン株式会社様（以下、キンドリル様）はお客様のビジネスアジリティを加速するためのプラットフォームを開発中です。本プラットフォームはキンドリル様で開発した標準テンプレートをポータル上で選択することで、AWS の各種クラウドサービスを活用したアプリ開発環境や必要なインフラストラクチャーの自動構築が可能となります。また、ポータルへの情報やリンクの集約を行うことにより、開発者や運用者の状況理解の負荷を軽減し、お客様の開発速度およびビジネスアジリティを加速します。 金融業界向けの標準テンプレートの開発にあたっては、金融業界の要求する品質やセキュリティー等への対応が求められます。キンドリル様ではこれまで金融業界向けの経験や実績をもとにしたコンテナー基盤を多くのお客様に提供してきましたが、FISC 準拠や災害対策など近年高まりつつあるお客様の懸念事項に対し、より一層の対応が求められます。 本プラットフォームの開発にあたっては、キンドリル様がこれまで培ってきた経験や実績に加えて、AWS 金融リファレンスアーキテクチャ日本版を活用することで高品質かつ迅速な市場への提供を実現します。具体的には、金融リファレンスアーキテクチャ日本版に含まれるオープン API と勘定系の２つのワークロードをテンプレート化の対象とし、AWS Well-Architected フレームワーク FSI Lens for FISC や金融グレードの統制への対策を組み込むことで、金融業界で求められる機密性と可用性に関するベストプラクティスを利用した高い安全性を確保します。また、他の業種向けの標準テンプレートの開発においても、金融リファレンスアーキテクチャ日本版の持つアーキテクチャおよび CDK テンプレートをベースとすることで、開発が加速され、本プラットフォームの持つケーパビリティーの拡大に寄与しています。 謝辞 アマゾン ウェブ サービス ジャパン合同会社の下記メンバーで FISC 安全対策基準・解説書（第11版）対応を行いました。 FISC 安全対策基準対応リファレンス：高野、松本(照)、保坂、能仁、富永、立花、阿部、渡邉、神部 金融リファレンスアーキテクチャ日本版：木村、保坂、北嵐、畑、遠藤、疋田、都築、辻本、松本(耕)、佐藤、神部

Amazon Timestream は、高速でスケーラブルなフルマネージドの時系列専用データベースであり、1 日に何兆もの時系列データを簡単に保存および分析できます。Timestream は、直近のデータをメモリに保持しつつ、定義したポリシーに基づいてコストが最適化されたストレージ層に履歴データを移動することで、時系列データのライフサイクル管理にかかる時間とコストを節約します。 本投稿では、 バッチロード 機能を使用して、 Amazon Relational Database Service (Amazon RDS) for PostgreSQL から Timestream に時系列データを移行する方法を説明します。尚、時系列データが Amazon Aurora PostgreSQL 互換エディション に存在する場合にも、同じソリューションが機能します。 Timestream の概念 始める前に Timestream の主要な概念をいくつか確認してみましょう。 時系列 – 一定の時間間隔にわたって記録された 1 つ以上のデータポイント (またはレコード) のシーケンス。 レコード – 時系列内の単一のデータ ポイント。 ディメンション – 時系列のメタデータを説明する属性。ディメンションはディメンション名とディメンション値で構成されます。 メジャー – レコードによって測定されている実際の値。例として、株価、CPU またはメモリの使用率、温度または湿度の測定値などが挙げられます。メジャーはメジャー名とメジャー値で構成されます。 Timestream のバッチロード機能を使用すると、Amazon Simple Storage Service (Amazon S3) に保存されている CSV ファイルからデータを取り込むことが可能となり、他のツールを使ったり、カスタムコードを記述する必要はありません。 ソリューションの概要 本ソリューションでは、 マルチメジャー レコードを使用してデータをモデル化し、RDS for PostgreSQL データベースからサンプルデータセットを Timestream にロードします。マルチメジャーレコードを使用すると以下の利点があります。 時系列データをよりコンパクトな形式で保存できるため、ストレージのコスト削減につながります。 コンパクトなストレージは、より単純なクエリ作成に役立ち、クエリパフォーマンスの向上が期待できます。 多くの場合でデータベーススキーマ変更がほぼ必要無くなる為、リレーショナルデータベースから Timestream へのデータ移行を簡素化する事ができます。 本アーキテクチャでは、まずAmazon RDS for PostgreSQL の aws_s3 エクスポート拡張機能 を使用して、時系列データを S3 バケットに CSV ファイルとしてエクスポートし、同時にエポック形式へのタイムスタンプ変換も実行します (これはバッチロードの 前提条件 です)。データが S3 バケットに保存された後、バッチロード機能を利用して、Timestream データベースへの時系列データの 1 回限りの移行を実行します。 以下の図は、本アーキテクチャを示しています。 前提条件 このソリューションを実装するには、次のリソースを作成します。 時系列データを保存する RDS for PostgreSQL インスタンス。セットアップ手順については、 こちら を参照してください。 Amazon S3 からダウンロードされた サンプルデータセット 。ダウンロードしたファイルを確認し、 \ copy コマンドを使用して RDS for PostgreSQL データベースにインポートします。 Amazon RDS for PostgreSQL からのデータを格納する S3 バケット。手順については、 Create your first S3 bucket および Setting up access to an Amazon S3 bucket を参照してください。 AWS Identity and Access Management (IAM) のポリシーとロール。 時系列データを保存し、バッチロードのターゲットとなる Timestream テーブル。手順については、 こちら を参照してください。クエリ実行を最適化するには、顧客定義のパーティション化キーを使用して、ディメンションの hostname に基づいて Timestream テーブルをパーティション化します。次のスクリーンショットは、Timestream コンソールでのこの構成を示しています。パーティション化キーについては、本投稿の後半で詳しく説明します。 さらに、バッチロードの 前提条件 、 クォータ 、 ベストプラクティス を確認することをお勧めします。 データセット Timestream のテーブルは、 measure_name と呼ばれる特別な属性 (または列) をサポートしています。Timestream は、 measure_name の値を使用してデータを分割し、インデックスを作成します。今回は、次のスクリーンショットに示すように、 region の分類を含んだ形で measure_name 属性をデータセットに追加しました。 サンプルデータセットは、AWS の複数のリージョンとアベイラビリティゾーンで実行されているコンピューティングインスタンス群からの CPU とメモリのメトリクスで構成されています。 Amazon S3 への PostgreSQL エクスポート用の Amazon RDS を準備する エクスポートを準備するには、次の手順を実行します。 Amazon RDS for PostgreSQL エンジンのバージョンが Amazon S3 にエクスポートする機能をサポートしていることを 確認 します。 Amazon RDS for PostgreSQL に aws_s3 拡張機能をインストール します。 Amazon RDS for PostgreSQL の アクセス許可 を S3 バケットに付与します。 Amazon RDS for PostgreSQL から時系列データをエクスポートする このステップでは、 aws_s3.query_export_to_s3 関数を使用して、時系列データを Amazon RDS for PostgreSQL から S3 バケットにヘッダー付きの CSV 形式でエクスポートします。 SELECT * FROM aws_s3.query_export_to_s3( 'SELECT cast(EXTRACT(epoch from time) * 1000000 as BIGINT) as time, measure_name, region, location, hostname, mem_usage, cpu_usage from perf_metrics', aws_commons.create_s3_uri('test-aws-dms-target-bucket/batchload', 'perf_metrics.csv', 'us-west-2'), options :='format csv, HEADER true'); Timestream バッチロードの前提条件 を満たすために、 EXTRACT 関数を使用してタイムスタンプ列をエポック (マイクロ秒) 形式に変換することに注意してください。 パフォーマンス指標データのモデリング バッチロードを使用して Timestream テーブルにロードするデータセットの属性と、それがパフォーマンスにどのように影響を与えるのか見てみましょう。 time – パフォーマンスメトリクスが収集された正確な時間 measure_name – パフォーマンス メトリックを分類するための集約属性 region – ホストが存在するリージョン location – ホストが配置されているアベイラビリティーゾーン hostname – メトリクスが収集されるホスト名 mem_usage – ホストのメモリ使用率 cpu_usage – ホストの CPU 使用率 適切なディメンジョンとメジャーを選択する 従来のリレーショナルデータベースから Timestream に移行する場合、テーブルと列を既存のデータベースから Timestream にそのままダンプすればうまくいくと考えるかもしれません。ですが、本当の課題は、クエリパターンを理解し、適切なディメンション、メジャー、およびオプションでパーティションキーを選択することにあります。 レコードのタイムスタンプを含むディメンションは、レコードを誰が、何を、いつ、どこで記録したかを特定するのに役立ちます。また、ディメンションは、データを整理および分類し、クエリの一部としてデータをフィルタリングするために使用されます。したがって、本投稿で使用するテーブルの region 、 location 、および hostname は、サーバーパフォーマンスのメトリックデータを整理および分類するための理想的な選択肢です。 メジャーは定量的なデータ (時間の経過とともに変化する値) であり、データの数学的計算 (合計、平均、変化率の差などの計算) と定量的分析を実行するための値を提供します。したがって、本投稿で使用する列 (測定値) mem_usage と cpu_usage は、ホストのパフォーマンスに関連する重要なメトリックを取得します。 ディメンションの数、メジャー (レコードごとの最大メジャー、テーブル全体の一意のメジャー)、およびレコードの最大サイズには 制限 がある為、データモデルを設計する際には、これらの要素を考慮する必要があります。多くの場合、Timestream に取り込まれるデータは、時系列分析に必要な属性以外の追加の属性を含むイベントまたはメトリクスを通じて発生します。制限に達しないようにするには、必要な属性のみをターゲットにします。データに関連性がなく、一緒にクエリを実行しない場合は、1 つの統合テーブルよりも個別のテーブルを使用する方が適しています。 データモデリングのベストプラクティスの詳細については、 こちらのブログ を参照してください。 顧客定義のパーティションキーの選択 顧客定義のパーティションキー は、クエリを高速化し、特定の時系列データ関連のニーズに基づいてより効率的に洞察を得るために必要な柔軟性を提供する新機能です。パーティショニングは、複数の物理ストレージユニットにデータを分散するために使用される技術で、より高速かつ効率的なデータの取得を可能にします。顧客定義のパーティションキーを使用すると、クエリパターンやユースケースに合わせたパーティションスキーマを作成できます。 Timestream でパーティション化する場合、パーティションキーを自身で選択するか、 measure_name 列に基づくデフォルトのパーティションを使用するかを選択できます。 カーディナリティの高い列を持ち、クエリの述語として頻繁に使用されるディメンションに基づいてパーティション キーを選択することを推奨します。これにより、パーティション間でデータが均等に分散され、パフォーマンスの問題が回避されます。 このパフォーマンスメトリクスの使用例では、 measure_name (デフォルト) や hostname などのカーディナリティの高い列がパーティションキーとして適している可能性がありますが、どの列がクエリ作成時のフィルタリングに頻繁に使用され、カーディナリティの高い列であるかによって選択する必要があります。この使用例では、クエリアクセスパターンは述語として hostname を頻繁に使用しており、カーディナリティの高い列でもある為、 hostname を顧客定義のパーティションキーとして構成しました。 デフォルトのパーティション分割ではなく、顧客定義のパーティションキーを使用することを強くお勧めします。 顧客定義のパーティションキーを使用したクエリパフォーマンスの最適化の詳細については、 こちらのブログ を参照してください。 Timestream のバッチロードを実行する バッチロードタスクを作成 するには、次の手順を実行します。 Timestream コンソールのナビゲーションペインで、 管理ツール 、 バッチロードタスク の順に選択します。 バッチロードを作成 を選択します。 ターゲットデータベース では、前提条件として作成したデータベースを選択します。 ターゲットテーブル で、前提条件として作成したテーブルを選択します。必要に応じて、 新しいテーブルを作成 を選択して、このペインからテーブルを追加できます。 データソースの S3 の場所 で、ソースデータが保存されている S3 バケットを選択します。 S3 を参照 ボタンを使用して、アクティブな AWS アカウントがアクセスできる S3 リソースを表示するか、S3 の場所の URL を入力します。データ ソースは同じリージョンに存在する必要があります。 ファイル形式の設定 では、デフォルト設定を使用して入力データを解析できます。 高度な設定 を選択し、CSV 形式のパラメーターを選択し、入力データを解析するパラメーターを選択することもできます。これらのパラメータの詳細については、 こちら を参照してください。 次に、Visual Builder を使用して データモデルマッピング を構成します。 エラーログリポート の エラーログの S3 の場所 で、エラーの報告に使用される S3 の場所を選択します。このレポートの使用方法については、 こちら を参照してください。 暗号化キータイプ で、次のいずれかを選択します。 Amazon S3 マネージドキー (SSE-S3) &nbsp;– Amazon S3 が作成、管理、および使用する暗号化キー AWS KMS キー (SSE-KMS) – AWS Key Management Service (AWS KMS) によって保護された暗号化キー 次へ を選択します レビューして作成 ページで設定を確認し、必要に応じて編集します。 バッチロードタスクを作成 を選択します。 バッチロードの ステータス を確認します。 問題が発生した場合は、一般的なエラーの トラブルシューティング を参照してください。 バッチ ロードタスクが正常に完了したら、Timestream クエリエディターに移動して結果をクエリできます。 データは次のスクリーンショットのように表示されるはずです。&nbsp; クリーンアップ 継続的な料金が発生しないように次のリソースを削除しましょう。 RDS for PostgreSQL インスタンス S3 バケット Timestream テーブル IAM ポリシー と ロール 結論 本投稿では、バッチロード機能を使用して時系列データをリレーショナルデータベースから Timestream に移行する方法を説明しました。ビジネスニーズに合わせて Amazon QuickSight または Grafana ダッシュボードを使用してデータを視覚化する方法についても利用して頂く事をお勧めします。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。

みなさん、こんにちは、カスタマーソリューションマネージャー (CSM) の西口です。このブログ記事では、AWS の コスト最適化 および可視化を支援するダッシュボードである Cost and Usage Dashboard (CUD) と Cloud Intelligence Dashboards のひとつである CUDOS Dashboard (CUDOS) をご紹介します。 これらビジュアル化されたダッシュボードは、AWS コンソールにアクセスできない、より広い範囲のステークホルダーに対して、コストに関するインサイトやインタラクティブな分析結果を共有することを容易にします。コストの「見える化」、そしてその分析した情報の共有について、課題をお持ちのお客様におすすめします。 また、AWS では、定常的に無駄なコストを減らし適切なコスト状態とするための「最適化」活動を実践するフレームワークとして Cloud Financial Management (CFM) を提唱しています。これらのダッシュボードを利用することで、CFM フレームワークの 4 つの柱のうち特に「可視化」の実現に寄与することが可能となっています。CFM フレームワークについては こちら をご参照ください。 このブログの流れとして、CUD と CUDOS の各特徴を説明した後にそれぞれのユースケースを説明します。その特徴やユースケースを通じて、ダッシュボードが AWS コストの最適化および可視化にどう役立つか詳しく見ていきましょう。 CUD と CUDOS の特徴 CUD は、Amazon QuickSight によって提供され、オープンソースプロジェクトの Cloud Intelligence Dashboards (CID) から着想を得たダッシュボードです。CUD は CID のダッシュボードの 1 つである CUDOS の主要なシートやビジュアル (グラフやチャート) を抽出しており、AWS コンソール画面からセットアップすることが可能です。具体的には AWS コンソールの AWS Billing and Cost Management の Data Exports ページから CUD を数分でデプロイすることができます。後述の CUDOS に比べると、セットアップが簡単であり、また Amazon Athena や AWS Glue クローラのようなベースとなる AWS サービスが不要という特徴があります。そのため運用上の理由などで Amazon Athena の利用を制限している環境やお客様でも CUD を利用することが可能です。CUD のセットアップ方法については こちら を参照ください。 一方、CUDOS も Amazon QuickSight によって提供されるダッシュボードですが、セットアップに Amazon Athena と AWS Glue クローラを使用する AWS CloudFormation (CFn) テンプレートベースのデプロイメントが必要です。CUDOS では CFn のデプロイメントが必要であるため、CUD に比べるとセットアップは簡単ではありませんが、AWS のリソースレベルの情報表示、 リザーブドインスタンス (RI) や Savings Plans (SPs) に関するインサイト、CUDOS 以外の他の CID のダッシュボードを利用することでコスト以外のデータソースをサポートするなど CUD にはない特徴もあります。CID のセットアップ方法については Well-Architected Labs を参照ください。 表 1) CUD と CUDOS の特徴と代表的な違い 特徴 Cost and Usage Dashboard (CUD) CUDOS Dashboard デプロイメントの方法 AWS コンソールからのデプロイ CloudFormation, Command Line, Terraform AWS Organizations 管理単位全体のコスト使用状況確認 管理アカウントのみ 管理アカウント、または専用の個別アカウント (注) 複数の AWS Organizations を統合可能 – ○ 必要な AWS サービスの違い Amazon Athena や AWS Glue クローラが 不要 (Amazon S3, Amazon QuickSight は必要) Amazon Athena や AWS Glue クローラが 必要 (Amazon S3, Amazon QuickSight は必要) コスト使用状況に対する情報表示 ○ ○ リソースレベルの詳細表示 – ○ リザーブドインスタンス (RI) や Savings Plans (SPs) に関する情報表示 – ○ 注：専用の個別アカウントとは、CUDOS 構築時に作成したダッシュボード参照用アカウントのこと。詳細は こちら を参照ください。(リンク先では、Destination / Data Collection Account と表記) CUD と CID の違いについての詳細情報を確認したい場合は こちら を参照ください。但し、CUD と CUDOS ではなく、CUD と CID との違いに言及したドキュメントである点にはご注意ください。 CUD と CUDOS のユースケースと差異 CUD と CUDOS の使い分けをより深く理解してもらうために、Amazon QuickSight のシート (タブ) ごとのユースケース例を用いて違いをご紹介します。Amazon QuickSight の基本的な用語や機能については こちら を参照ください。CUD でも様々なユースケースをカバーしています。前章でご紹介した通り CUD はリソースレベルの詳細表示が省略されているため、 ARN やリソース ID レベルでコスト状況を分析したい場合には、CUDOS を利用ください。CUDOS のみで確認できる具体的なグラフは図 1 から図 11 をご参照ください。 表 2) CUD と CUDOS のユースケースと差異 シート名 内容 利用ユースケース例 CUD CUDOS CUDOS と CUDの特徴的な差異 Introduction ダッシュボード全体像やそれぞれのシートの内容に関する情報を紹介 ダッシュボードの概要を確認する。 ○ – CUD のみ存在 Executive: Billing Summary 保持するアカウント全体の支払い状況と変動の傾向 毎月の請求金額と償却コストの実績を比較しながら、リザーブドインスタンスや Savings Plans やクレジットなどの割引の効果をアカウント単位やサービス単位で確認。割引が十分に活用されているかの分析を通して支払い全体像の把握を行う。 ○ ○ CUD ではリザーブドインスタンスや Savings Plans、クレジットなどによる支払い額の削減に関する情報が含まれない Executive: RI/SP Summary リザーブドインスタンスや Savings Plans の使用状況 リザーブドインスタンスや Savings Plans の購入金額や使用率に加えて、これらの割引による実際の削減額を確認。加えて、オンデマンドやスポットインスタンスなど購入オプションごとの比率を分析を行う。インスタンス調達オプションの変更や追加の必要性を把握する。 – ○ CUDOS のみ存在 Executive: MoM Trends アカウントやサービス単位の月次の変動傾向 アカウントやサービスの単位で３ヶ月間のコスト変動のトレンドや償却コストの状況を確認。使用コストが大きく変動しているアカウントやサービスに関して変動の妥当性の評価を行う。 ○ ○ – (差異なし) Compute Amazon Elastic Compute Cloud (Amazon EC2) や AWS Fargate、AWS Lambda の使用状況や変動の傾向 EC2、Fargate、Lambda について、購入オプションによる単価の現状や過去推移の分析を行うことにより、購入オプションの追加や変更の必要性を確認する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略 (図 1) Storage Amazon Elastic Block Store (Amazon EBS) や Amazon Elastic File System (Amazon EFS)、Amazon FSx などのストレージファイルシステム EBA、EFS、FSx について、月間ストレージコスト、保管データ容量、単価、データ操作ごとのコストを確認。想定外の大容量データの保存や、SnapShot の過剰な取得によるコスト異常を発見する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略 (図 2) Amazon S3 Amazon Simple Storage Service (Amazon S3) の使用状況と変動の傾向 アカウントやバケットごとの S3 利用料金や、Amazon Simple Storage Service Glacier (Amazon S3 Glacier) の使用状況を確認。S3 バケット使用状況の妥当性や、S3 のストレージクラスの変更の必要性を評価する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略 (図 3) Databases Amazon Relational Database Service (Amazon RDS) や Amazon DocumentDB (with MongoDB compatibility)、Amazon Redshift、Amazon ElastiCache、Amazon OpenSearch Service などデータベースに関する使用状況と変動の傾向 各サービスについて、アカウントやリージョン、プロダクトファミリー、データベースエンジンごとの償却コスト、リザーブドインスタンスの使用率、購入オプションの使用状況などを確認。データベースサービス利用状況の妥当性を評価する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略 (図 4) Amazon DynamoDB Amazon DynamoDB の使用状況と変動の傾向 データ転送やバックアップなど操作ごとの発生コストをアカウントごとやテーブルごとに確認。DynamoDB の使用状況の妥当性を評価する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略 (図 5) Messaging and Streaming Amazon Kinesis と Amazon Managed Streaming for Apache Kafka (Amazon MSK) の使用状況と変動の傾向 Kinesis と MSK について、アカウントごとに詳細状況を確認。Kinesis のコストはリソース単位、 MSK のコストはクラスターごとに確認。それぞれのサービスの使用状況の妥当性を評価する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略 (図 6) Data Transfer and Networking データ転送とネットワークの使用状況と変動の傾向 アカウントごとのデータ転送コストに加えて、データ転送量や、リージョン間通信、VPN Peeringなどのコスト内訳を確認。併せて AWS Direct Connect、Elastic Load Balancing (ELB)、 NAT Gateway、 VPN、 Amazon Virtual Private Cloud (Amazon VPC) Endpoint のそれぞれにおいて、日次のコスト詳細や Public IPv4 、 Amazon CloudFront の使用状況を確認。データ転送とネットワーク状況の妥当性を評価する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略(図 7) AI/ML Amazon SageMaker や Amazon Comprehend、Amazon Textract、Amazon Rekognition、Bedrock の使用状況と変動の傾向 SageMaker や Amazon Bedrock、Amazon Textract、Amazon Rekognition のアカウントごとのコスト現状や過去推移を確認。使用状況の妥当性を評価する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略(図 8) Monitoring &amp; Observability Amazon CloudWatch と AWS CloudTrail の 使用状況と変動の傾向 CloudWatch と CloudTrail、AWS Config のアカウントごとのコスト現状や過去推移を確認することで、モニタリングとオブザーバビリティ関連サービス使用状況の妥当性を評価する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略(図 9) End User Computing (※ CUDOSでは上記名称。CUD では Amazon WorkSpaces) Amazon Workspaces の使用状況と変動の傾向 Amazon WorkSpaces のコスト現状や過去推移を確認することで、エンドユーザコンピューティング環境の妥当性を評価する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略(図 10) GameTech &amp; Media Amazon GameLift と AWS Elemental MediaConnect などの使用状況と変動の傾向 Amazon GameLift や MediaConnect などのコスト現状や過去推移を確認することで、ゲームやメディアに関するサービスの妥当性を評価する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略 TAGsplorer タグの状況分析 タグ毎の使用量やトレンドについて詳細を確認することで、タグ単位の使用量推移や妥当性の評価を行う。 – ○ CUD ではシートそのものが省略 OPTICS Explorer その他すべての使用状況と変動の傾向 アカウント毎に使用している主要サービスや、日単位での利用金額の傾向など、他のレポートとは異なる視点での分析を行う。 ○ ○ CUD ではリソースレベルの詳細グラフが省略(図 11) Other Recommendations その他の有用なグラフ ここまでで使用されていない Anomaly Detection からの通知の確認などを行う。 – ○ CUD ではシートそのものが省略 図 1) Compute タブで省略されているリソースレベルの詳細グラフの例。CUDOS では過去 30 日間の Top 50 のコストが発生している Lambda usage をリソース ID 単位で確認可能。 図 2) Storage タブで省略されているリソースレベルの詳細グラフの例。CUDOS では過去 30 日間の Top 20 のコストが発生している EBS ボリューム使用量をリソース ID 単位で確認可能。 図 3) Amazon S3 タブで省略されているリソースレベルの詳細グラフの例。CUDOS では過去 30 日間の Top 20 のコストが発生している S3 に対する操作をリソース ID 単位で確認可能。 図 4) Database タブで省略されているリソースレベルの詳細グラフの例。CUDOS では過去 30 日間の Top 20 のコストが発生している Database に関するUsage を Database ARN 単位で確認可能。 図 5) Amazon DynamoDB タブで省略されているリソースレベルの詳細グラフの例。CUDOS では過去 30 日間のテーブル単位のコストを確認可能。 図 6) Messaging and Streaming タブで省略されているリソースレベルの詳細グラフの例。CUDOS では過去 30 日間の操作単位やリソース ID 単位のコストを確認可能。 図 7) Data Transfer &amp; Networking タブで省略されているリソースレベルの詳細グラフの例。CUDOS ではリソース ID 単位で過去 30 日間のコスト Top 10 や、日次のコスト状況を確認可能。 図 8) AI/ML タブで省略されているリソースレベルの詳細グラフの例。 CUDOS では過去 30 日間の Top 10 のコストが発生している Amazon Bedrock に関するUsage をリソース ID 単位で確認可能。 図 9) Monitoring &amp; Observability タブで省略されているリソースレベルの詳細グラフの例。CUDOS では過去 30 日間の CloudWatch のコストをリソース ID 単位で確認可能。 図 10) Amazon Workspaces タブで省略されている詳細グラフの例。CUDOS では End User Computing タブとして、過去 30 日間の Top 20 のコストが発生している Usage を Workspace id 単位で確認可能。 図 11) OPTICS Explorer タブで省略されている詳細グラフの例。 CUDOS では 過去 30 日間の Top 10 のコストが発生している Usage を リソース ID 単位で確認可能。 おわりに 本ブログでは、AWS コスト最適化と可視化を支援する ダッシュボードである CUD と CUDOS の特徴と差異、その利用ユースケース例をご紹介しました。皆さまの AWS のコスト最適化および可視化のヒントになりましたでしょうか。 初めて AWS コストに関するダッシュボードを利用する場合は簡単に構築できる CUD の利用をおすすめします。また、その一方で CUDOS のみで確認できるダッシュボードも存在しますので、必要なユースケースによっては CUDOS やそれ以外の CID の利用もご検討ください。 参考情報 New – Cost and Usage Dashboard powered by Amazon QuickSight Visualize and gain insights into your AWS cost and usage with Cloud Intelligence Dashboards and CUDOS using Amazon QuickSight AWS Data Exports AWS Billing and Cost Management 向けのデータエクスポートを発表

AWS は、新しいインターネット監視サービスである Amazon CloudWatch Internet Monitor のリリースを発表しました。インターネット上でのパフォーマンスと可用性は、AWS アプリケーションのユーザー体験の水準を高めるのに役立つ重要な指標です。ユーザー体験は、お客様が制御出来ない未知の事象に大きな影響を受ける可能性があります。お客様のアプリケーションでより良いユーザー体験を提供するには、インターネットの状況とユーザー体験を把握している必要があります。 Internet Monitor では、AWS でのワークロードの利用状況に合わせて、可用性やパフォーマンスなどのインターネット測定値を継続的に監視できます。Internet Monitor を使用すると、時間の経過に伴う平均的なインターネットの性能の指標や、場所やインターネットサービスプロバイダー (ISP) ごとの問題 (イベント) に関する洞察を得ることができます。また、Amazon CloudFront、Amazon WorkSpaces ディレクトリ、または Amazon Virtual Private Cloud (Amazon VPC) で直接ホストされているアプリケーションのエンドユーザーのユーザー体験に影響を与えているイベントを簡単に特定できます。アプリケーションエンドポイントに関連する測定値により、問題の範囲、場所、根本原因をすばやく特定できるため、修正に必要なアクションを実行できます。これらすべてを、アプリケーションコードを変更することなく、またワークロードのパフォーマンスに影響を与えることなく実行できます。 Internet Monitor は、ユーザーとアプリケーション間のインターネットを含んだ通信経路をモニタリングし、CloudWatch の各サービス表示できます。 ユーザー体験 – CloudWatch Synthetics と CloudWatch Real User Monitoring (RUM) インターネットの健全性 – Internet Monitor アプリケーションスタックの健全性 – CloudWatch ServiceLens と AWS X-Ray リソースの健全性 – CloudWatch Metrics と CloudWatch Logs (* このブログ執筆時では、CloudWatch ServiceLens は AWS X-Ray service map と統合され、 X-Ray trace map になりました。) Internet Monitor の構成要素 Internet Monitor の仕組みを説明する前に、構成要素について説明します。 モニター : モニターは、監視するリソースを定義したコンテナです。 ヘルスイベント : Internet Monitor はトラフィック性能の大幅な低下を検出すると、ヘルスイベントを作成します。各ヘルスイベントには、影響を受けるクライアントの地理情報とネットワークプロバイダー (ISP) の情報が含まれています。 パフォーマンスおよび可用性スコア ( ヘルススコア ) : アプリケーションへのトラフィックのうち、パフォーマンスの低下や可用性の低下が発生していない割合を統計的に推定したものです。これらのスコアは CloudWatch メトリクスとしても利用できます。 CloudWatch Logs : クライアント固有のロケーションとネットワークプロバイダー向けに、Internet Monitor は、パフォーマンスと可用性スコア、転送されたバイト数、および往復時間 (Round Trip Time , RTT) を含む測定値を CloudWatch Logs に送信します。 仕組み Internet Monitor は、さまざまな AWS リージョンとエッジロケーション、およびお客様がアプリケーションエンドポイントにアクセスするネットワーク間で、AWS が既に収集しているデータを活用します。この接続情報は、インターネット上の接続の問題を事前に検出し、顧客体験を向上させるための対策を講じるために、AWS 自身も使用しています。 すべての AWS リージョンで、インターネットのどの部分がそのリージョンとどのように接続されているかといったネットワークの構成情報を AWS は把握しています。これにより、AWS はネットワークプローブ *と上位プロトコルプローブの両方を、インバウンドとアウトバウンドの両方で使用しモニタリングを実施できます。これらのパフォーマンスと可用性の測定値をベースラインとして、さまざまな地域のエンドユーザーに重大な問題の発生を認識できるように、ヘルススコアを計算します。モニターを作成すると、Internet Monitor はユーザーのリソースに基づいてトラフィックプロファイルを作成し、ユーザーの場所と各ユーザーへのトラフィックの割合を記述します。次に、トラフィックプロファイルが AWS ベースラインパフォーマンスプロファイルと比較します。このプロファイルから、ベースラインからの推定減少を示すパフォーマンススコアと可用性スコアが計算されます。 ( プローブ (probe)* とは 英語で探査・検査を意味し、対象のシステムの性能等を検査する行為およびツールやソフトウェアをさします) Internet Monitor では、さまざまな AWS サービスの使用やトラフィックの再ルーティングに関するパフォーマンスメトリクスを表示することで、サーバー初期応答時間 (Time To First Byte, TTFB) を改善するための洞察や推奨事項も提供します。これは、Amazon CloudFront を使用したり、ワークロードトラフィックをさまざまな AWS リージョンに再ルーティングしたりすることで、ユーザーエクスペリエンスをどのように改善できるかを理解するのに役立ちます。 ヘルスイベントに関するアラート モニターを作成したら、次はアラートを設定します。Internet Monitor のヘルスイベントに関するアラートを受け取る方法はいくつかあります。何を選択するかは、フィルタリングの要件、履歴レコードタイプ、アラームがトリガーされたときのアクションなどによって異なる場合があります。 パフォーマンスと可用性スコアの Internet Monitor のイベントメトリクスに基づいた CloudWatch アラーム CloudWatch Logs のメトリクスフィルターを使用して生成されたメトリクスに基づく CloudWatch アラーム Internet Monitor によって生成されたヘルスイベントをフィルタリングするための Amazon EventBridge ルール CloudWatch アラームは、ユーザー体験のメトリクスをより詳細なレベルで追跡するために追加のメトリクスが必要な場合に役立ちます。 また、Internet Monitor がヘルスイベントを作成するまでには至らない影響がユーザーに発生したときにアラートが必要な場合でも、アラームを発行することができます。加えて、 EventBridge を使用すると、Internet Monitor によって生成されたイベントに対するイベント駆動型の自動応答を作成できます。 前提条件 以下のセクションでは、“VPC や CloudFront ディストリビューションなどの基本的な AWS ネットワーキングサービス”, “WorkSpaces ディレクトリの設定“に精通していることを前提としています。各サービスの詳細については説明しませんが、Internet Monitor でそれらを使用するために必要な手順の概要を説明します。AWS リソースに関する詳細情報は、対応する ユーザーガイド に記載されています。 Internet Monitor のセットアップ ここで、顧客向けのウェブアプリケーションを Amazon Elastic Compute Cloud (EC2) に、リモートチームメンバー向けのインターネットに面したAmazon WorkSpaces ディレクトリをホストしている場合を考えましょう。これらのインターネットに公開されたリソース全体で、エンドユーザーのユーザー体験をグローバルに監視する必要があります。大半のエンドユーザーが北米にいるため、他の地理的ユーザーとは別にアプリケーションにアクセスする際のユーザー体験も監視する必要があります。 モニターを作成してリソースを追加し、ヘルスイベントを通知するように CloudWatch アラームを設定するだけで、Internet Monitor を使い始めることができます。 EC2 でホストされている Web アプリケーションの監視 Step 1 : Internet Monitorでモニターを作成する モニターを作成するには、CloudWatch コンソールのアプリケーションのモニタリングの下にある [インターネットモニター] ページで [モニターを作成] を選択します。モニターの名前を入力し、 [リソースを追加] を選択します。この例では、EC2 でホストされるウェブアプリケーションがあるため、VPC を追加します。リソースページで VPC を選択し、次に [追加] を選択します。 [次へ] を選択し、設定を確認して、 [モニターを作成] を選択します。モニターがアクティブになるまでに数分かかります。 (* 新しいコンソールでは、図1 にあるような Step 1、Step 2 は1つのページで設定する仕様に変更されています。) 図1 – Internet Monitor コンソールでのモニターの作成 ワークロードとその監視ニーズによっては、リソースのグループごとにインターネットモニターで個別のモニターを作成する必要がある場合があります。今回の例では、WorkSpaces ディレクトリ用に別のモニターを作成します。 Step 2 : アラート設定の例 アラートには、Amazon EventBridge を使用します。アプリケーション要件とユーザーベースの例を考慮して、可用性スコアのしきい値を 50%、パフォーマンススコアのしきい値を 50% と定義し、影響を受ける総トラフィックをトラフィックの 1% 以上と指定します。EventBridge ルールは、上記の条件に一致するイベントのログの作成と同時に、このイベントの通知を SNS キューに送信します。(ここでの値はあくまでも一例です。アプリケーションやビジネスに適したレベルでしきい値を設定してください。) イベントフィルターを設定するには、AWS マネジメントコンソールで Amazon EventBridge に移動します。 [EventBridge ルールを作成] を選択し、関連する名前と説明を入力します。ルールには [ defaultイベントバス] を使用し、イベントソースには [その他] を選択します。サンプルイベント構成をスキップし、 [作成のメソッド] として [カスタムパターン] を選択します。例を下記に示します。 { "source": ["aws.internetmonitor"], "detail": { "Status": ["ACTIVE"], "ImpactedLocations": { "CountryCode": ["CA", "US"], "$or": [{ "internetHealth": { "Performance": { "experienceScore": [{ "numeric": ["&lt;", 50] }], "percentageOfTotalTrafficImpacted": [{ "numeric": ["&gt;", 1] }] } } }, { "internetHealth": { "Availability": { "experienceScore": [{ "numeric": ["&lt;", 50] }] } } }] } } } 次に、イベント用に 2 つのターゲットを設定します。1 つは新しい Amazon Simple Notification Service (SNS) トピックで、もう 1 つは CloudWatch の ロググループです。これらは、ログの経時的な変化の分析とレポートを目的としています。ルールに一致するInternet Monitor のヘルスイベントが発生すると、そのイベントは SNS キューと CloudWatch のロググループで受信されます。 図2 – EventBridge ルールのターゲットの設定 Amazon WorkSpaces ディレクトリのモニタリング Step 1 : WorkSpaces ディレクトリのモニターを作成する EC2 のモニター作成の手順に従って、WorkSpaces ディレクトリリソースのモニターを作成します。一部のリソースタイプでは、同じような監視要件を持つリソースを 1 つのモニターにグループ化できます。ただし、WorkSpaces ディレクトリをInternet Monitor の VPC と同じモニターに追加することはできないため、新しいモニターを作成します。 Step 2 : アラート設定の例 WorkSpaces ディレクトリを使用するお客様にとって重要な指標は、往復時間 (Round Trip Time, RTT) です。RTT が 100 ミリ秒を超えると、エンドユーザーのパフォーマンスエクスペリエンスに影響します。今回のユースケースでは、北米のエンドユーザーのみを対象に RTT を視覚化するカスタムメトリクスを作成します。そのための手順は以下のとおりです。 a) クライアントの場所に基づいて Internet Monitor のイベントログをフィルタリングします。 b) Internet Monitor イベントログ用のカスタム CloudWatch メトリクスフィルターを作成します。 c) カスタムメトリクスに基づいてアラームを設定します。 それぞれの設定フローを、詳しく見ていきます。 a) クライアントの地理情報に基づくイベントログのフィルタリング CloudWatch Logs のコンソールでは、Internet Monitor のログデータを JSON 形式で名前空間 /aws/internet-monitor/&lt;your-monitor-name&gt;/&lt;granularity&gt; にて視覚化できます。この例では、北米のエンドユーザーの場合、国レベルの細分化が最も役立ちます。内部のログストリームには、個々の測定イベントが含まれています。各イベントには、クライアントロケーションの地理情報とネットワーク情報、トラフィック統計、可用性スコア、パフォーマンススコアが含まれます。これは、Internet Monitor コンソールに集約されて表示される情報と同じです。 図3 – JSON 形式の Internet Monitor イベントログの例 インターネットモニターのログをフィルタリングするには、 ClientLocation.CountryCode フィールドを次の設定で使用します。例 : {$.clientLocation.CountryCode=US || $.clientLocation.CountryCode=CA} 。これにより、米国またはカナダのクライアントロケーションのログイベントを視覚化できます。 図4 – Internet Monitor のログストリームが、北米にあるクライアントロケーションのイベントのみを表示するようにフィルタリングされている例 b) Internet Monitorイベントログ用の CloudWatch メトリクスフィルターを作成する クライアントの地理情報に基づいてログがフィルタリングされたら、 [メトリクスフィルターを作成] を選択し、フィルターメトリクスの名前と名前空間を設定して、関連するカスタムメトリクスをグループ化します。この例では、90 パーセンタイル (p90) の RTT 値である InternetHealth.Performance.RoundtripTime.p90 に基づいてメトリクスを生成しています。メトリクスの感度が p90 なので、平均値を使用すると見落とされるであろう異常を警告することができ、トリガーの頻度が高すぎることも回避できます。 図 5 – CloudWatch Logs コンソールを使用して Internet Monitor ログイベントに基づくメトリクスフィルターを作成 要件に応じて、構成に p50、p90、または p95 を使用できます。測定パーセンタイルの詳細については、 CloudWatch ユーザーガイド を参照してください。新しいメトリクスフィルタである NorthAmericanRTT は、最初に一致するログイベントが処理された直後に利用できるようになります。 c) カスタムメトリクスに基づいてアラームを設定する 新しいメトリクスに基づいてアラームを作成するには、CloudWatch アラームコンソールを使用して、新しく作成したメトリクスをモニター用に選択します。一例として、RTTのしきい値条件として 100ms を選択しました。また、静的しきい値の代わりに異常検出を使用するアラームを作成して、より正確なユーザーエクスペリエンス分析を行うこともできます。異常検出の詳細については、 CloudWatch ユーザーガイド を参照してください。 アラームのしきい値条件を設定したら、次の図に示すように、アラートを送信する SNS トピックを選択し、アラームを作成します。 図6 – Internet Monitor メトリクスの指定と CloudWatch アラームコンソールでのしきい値の設定 Internet Monitorのイベントの分析 ここで、パフォーマンスまたは可用性が設定したしきい値のいずれかを下回ったというアラートを受け取ったとします。調査を開始するには、モニターのInternet Monitorコンソールの [概要] タブをクリックしてください。概要タブには、監視対象リソースの可用性とパフォーマンスのスコア、および関連するアクティブヘルスイベントが表示されます。 図7 – Internet Monitor コンソールの概要タブで、ヘルススコアと台湾とオーストラリアでのヘルスイベントを示すマップが表示されている様子 この例では、台湾とオーストラリアのユーザーに影響を及ぼすヘルスイベントを確認できます。ヘルスイベントの詳細を確認するには、CSV 形式または JSON 形式で詳細をダウンロードできます。 [アクション] を選択し、必要な形式を選択します。このファイルには、選択した期間のすべてのヘルスイベントが含まれており、関心のあるイベントのみを含めるようにフィルタリングできます。1 つのイベントを見ると、イベントの詳細には、クライアントの場所、ネットワークサービスプロバイダー名、ASN、影響を受けたトラフィックの割合などの情報が含まれていることがわかります。JSON 形式のイベントの例を次に示します。 { "EndedAt": null, "EventArn": "arn:aws:internetmonitor:us-east-1:617055091360:monitor/retryblogmonitor/health-event/2022-10-11T01-15-00Z/availability", "EventId": "2022-10-11T01-15-00Z/availability", "ImpactType": "AVAILABILITY", "ImpactedLocations": [ { "ASName": "TPG Telecom Limited", "ASNumber": 7545, "internetHealth": { "Availability": { "ExperienceScore": 84.78, "PercentOfClientLocationImpacted": 15.22, "PercentOfTotalTrafficImpacted": 8.66 } }, "City": "Canberra", "Country": "Australia", "CountryCode": "AU", "Latitude": -35.2504, "Longitude": 149.1702, "Metro": "", "ServiceLocation": "us-east-1", "ServiceName": "VPC", "Status": "ACTIVE", "Subdivision": "Australian Capital Territory", "SubdivisionCode": "" } ], "PercentOfTotalTrafficImpacted": 8.66, "StartedAt": "2022-10-11T01:15:00.000Z", "Status": "ACTIVE" } 図7 に示す情報を読み取っていきます。ここでは、その場所にいるクライアントの 15.22% が影響を受けました。これは、当時アプリケーションを使用していた全クライアントの 8.66％ に相当します。 ユーザーエクスペリエンスをさらに深く掘り下げるには、 [Historical Explorer] タブに移動して、地域やネットワークプロバイダー、および時間枠でフィルタリングされたより多くのパフォーマンス指標を視覚化します。 図8 – オーストラリアにフィルタリングされたインターネットトラフィックグラフを表示する、Internet Monitor の Historical explorer タブ Internet Monitor を使用してアプリケーション配信を最適化 ここで調査しているような、クライアントネットワークプロバイダーの問題が原因と思われるイベントについては、短期的に実行できるアクションがいくつかあります。 アプリケーションがすでに複数のリージョンから提供されている場合、影響を受けるトラフィックを、別のインターネットパスでアクセスできる別の AWS リージョンのリソースにシフトできる可能性があります。 ネットワークプロバイダーに連絡して、問題を認識しているかどうか、解決策に取り組んでいるかどうかを確認してください。これは、お住まいの地域以外のプロバイダーの場合は、選択できない可能性があります 自分のステータスページやソーシャルメディアを更新して、ある場所で発生している問題はその地域のインターネットのパフォーマンスによるものであることをユーザーに知らせることが出来ます。 影響を受ける顧客からの質問に答えるために、カスタマーサポートを準備する。 長期的なアプローチとしては、例えば Amazon CloudFront のようなサービスを使用して、クライアントトラフィックが通過するインターネットパスを最小限に抑えるなど、エンドユーザーへのアプリケーション配信を改善することが考えられます。AWS リージョンのユーザーおよびオリジンリソースまたはエンドポイントに最も近い AWS POP からのトラフィックはすべて、AWS グローバルネットワークを介して伝送されます。 [トラフィックインサイト] タブでは、可用性やパフォーマンススコア、サーバー初期応答時間 (Time to first byte, TTFB) 別にソートして、さまざまな場所でアプリケーションのパフォーマンスを向上させる方法を調べることができます。また、地理的フィルターやネットワークプロバイダーフィルターを使用して、特定の地域のデータをさらに詳しく調べることもできます。 Internet Monitor では、 [トラフィック最適化の提案] で、EC2 や CloudFront リソースの使用に切り替えたり、トラフィックを他の AWS リージョンやエッジロケーションにルーティングしたりした場合に、クライアントロケーションとネットワークプロバイダーの組み合わせで予想される TTFB 改善の予測も表示されます。さまざまなオプションを試して、それぞれの組み合わせで最良の結果が得られるものを確認してください。 図9 – クライアントロケーショングラフごとの総トラフィックやトラフィック最適化の提案が表示される、Internet Monitor のトラフィックインサイトタブ 環境のクリーンアップ Internet Monitor の機能を確認し終わったら、必ずテスト環境をクリーンアップし、作成したリソースを削除してください。まず、モニターを削除し、次に EventBridge ルール、CloudWatch ログルール、アラーム、メトリクス、ロググループ、SNS トピックなど、作成したその他のリソースを削除します。 その他の注意点 1 つの AWS リージョンに同じようなユーザーベースのアプリケーショングループがある場合は、1 つのモニターを作成して、グループ全体のユーザーエクスペリエンスの集計を監視します。 Internet Monitorの 1 つのモニターで、複数のリージョンのリソースを監視できます。 VPC と CloudFront ディストリビューションを追加する場合、WorkSpaces ディレクトリを同じモニターに追加することはできません。 Internet Monitor には、メトリクス、ログ、作成されたダッシュボード、アラーム、またはインサイトに対して、通常の CloudWatch 料金がかかります。詳細については、 CloudWatch の料金表ページ をご覧ください。 Internet Monitor の AWS CloudFormation サポートはまもなく利用可能になる予定です。 Internet Monitor は現在 20 の AWS リージョン でご利用いただけます。 まとめ このブログでは、Amazon CloudWatch Internet Monitor を紹介しました。これは、AWS がグローバルネットワークインフラストラクチャから収集した接続データを利用して、、インターネットに接続するアプリケーションのパフォーマンスを可視化する新しいサービスです。Internet Monitor は、他の方法では気付かないエンドユーザーのエクスペリエンスに影響を与える要因を使用して、十分な情報に基づいた意思決定を行うことができるため、ワークロードの導入戦略を最適化できます。インターネットモニターの詳細については、 ドキュメント をご覧ください。 本記事は、Alexandra Huides, Tony Hawke らの「 Introducing Amazon CloudWatch Internet Monitor 」を翻訳したものです。翻訳は ソリューションアーキテクトの 伊藤 威が担当しました。

11月27日は、 Amazon ElastiCache Serverless の提供開始についてお知らせします。これは、お客様が 1 分以内にキャッシュを作成し、アプリケーションのトラフィックパターンに基づいて容量を即座にスケールできる新しいサーバーレスオプションです。ElastiCache Serverless は、2 つの一般的なオープンソースキャッシュソリューションである Redis および Memcached と互換性があります。 ElastiCache Serverless を使用すると、最も要求の厳しいワークロードであっても、即座にキャッシュを運用できます。キャパシティプランニングにかける時間を削減でき、キャッシュの専門知識も不要です。ElastiCache Serverless は、アプリケーションのメモリ、CPU、ネットワークリソースの使用状況を常に監視し、処理するワークロードのアクセスパターンの変化に合わせて即座にスケールします。また、複数のアベイラビリティーゾーンにわたってデータを自動的にレプリケートし、サービスレベルアグリーメント (SLA) によって、すべてのワークロードに対する最大 99.99% の可用性が保証されています。そのため可用性の高いキャッシュを作成でき、時間とコストの節約になります。 キャッシュのデプロイと運用には大幅な簡素化が求められていました。ElastiCache Serverless は、基盤となるクラスタートポロジとキャッシュインフラストラクチャを抽象化し、簡素化されたエンドポイントエクスペリエンスを提供します。再接続やノードの再検出を行わなくても、アプリケーションの複雑さを軽減し、より優れた運用を実現できます。 ElastiCache Serverless では、前払いコストは発生せず、使用したリソースに対してのみ料金が発生します。アプリケーションで使用したキャッシュデータストレージと ElastiCache 処理装置 (ECPU) リソースの量に対してのみお支払いいただきます。 Amazon ElastiCache Serverless の開始方法 まずは ElastiCache コンソール に移動し、左側のナビゲーションペインで [Redis キャッシュ] または [Memcached キャッシュ] をクリックします。ElastiCache Serverless は、Redis 7.1 以降または Memcached 1.6 以降のエンジンバージョンをサポートしています。 例えば、Redis キャッシュの場合は、 [Redis キャッシュを作成] をクリックします。 デプロイオプションは 2 つあり、 [サーバーレス] と [独自のキャッシュを設計] のいずれかを選択して、ノードベースのキャッシュクラスターを作成します。 [サーバーレス] オプションをクリックしたら、 [新しいキャッシュ] をクリックして名前を指定します。 デフォルト設定を使用して、デフォルトの VPC、アベイラビリティーゾーン、サービス所有の暗号化キー、セキュリティグループにキャッシュを作成します。推奨されるベストプラクティスが自動的に設定されます。追加の設定を入力する必要はありません。 デフォルト設定をカスタマイズする場合、独自のセキュリティグループの設定や、自動バックアップの有効化ができます。また、キャッシュが特定のサイズを超えないように、コンピューティングとメモリの使用量に上限を設定することも可能です。キャッシュがメモリの上限に達すると、有効期間 (TTL) のあるキーは、最近で最も使用されていない (LRU) ロジックに従って削除されます。コンピューティングの上限に達すると、ElastiCache はリクエストを調整するため、リクエストのレイテンシーが増加します。 新しいサーバーレスキャッシュを作成すると、エンドポイントやネットワーク環境など、接続性とデータ保護の設定を詳しく確認できます。 これで、アプリケーションに ElastiCache Serverless エンドポイントを設定できました。また、Redis をサポートする任意の Redis クライアント ( redis-cli など) を使用して、クラスターモードでエンドポイントに接続できるようになります。 $ redis-cli -h channy-redis-serverless.elasticache.amazonaws.com --tls -c -p 6379 set x Hello OK get x "Hello" キャッシュの管理は、 AWS コマンドラインインターフェイス (AWS CLI) または AWS SDK を使用して行えます。詳細については、AWS ドキュメントの「 Amazon ElastiCache for Redis とは 」を参照してください。 既存の Redis クラスターがある場合は、ElastiCache Serverless キャッシュの作成時に、ElastiCache バックアップまたはバックアップファイルの Amazon S3 ロケーションを標準の Redis rdb ファイル形式で指定します。これにより、データを ElastiCache Serverless に移行できます。 Memcached キャッシュの場合は、Redis と同じ方法で新しいサーバーレスキャッシュを作成して使用できます。 Memcached 用に ElastiCache Serverless を使用すると、大きなメリットが得られます。なぜなら Memcached エンジンでは本来、高い可用性と即座のスケール機能を備えていないためです。Memcached で高い可用性を実現するために、カスタムビジネスロジックの記述、複数キャッシュの管理、サードパーティのプロキシレイヤーを使用したデータのレプリケートを行う必要がなくなります。サービスレベルアグリーメント (SLA) によって最大 99.99% の可用性が保証され、複数のアベイラビリティーゾーンにわたるデータのレプリケートが可能になりました。 Memcached エンドポイントに接続するには、以下の出力例に示す openssl クライアントと Memcached コマンドを実行します。 $ /usr/bin/openssl s_client -connect channy-memcached-serverless.cache.amazonaws.com:11211 -crlf set a 0 0 5 hello STORED get a VALUE a 0 5 hello END 詳細については、AWS ドキュメントの「 Amazon ElastiCache for Memcached の使用開始 」を参照してください。 監視とパフォーマンス ElastiCache Serverless は、キャッシュのスケールアップと並行してスケールアウトを開始することで、最適なタイミングでキャパシティのニーズに応えます。そのため、アプリケーションのダウンタイムやパフォーマンスの低下を発生させずにスケールできます。 ElastiCache Serverless のパフォーマンスを示すために、簡単なスケーリングテストを実施しました。まず、読み取りと書き込みの比率が 80/20 で、キーサイズが 512 バイトの一般的な Redis ワークロードから始めます。Redis クライアントは、Redis コマンド「READONLY」を使用して、レプリカから読み取り (RFR) を実施するように設定されています。これにより、読み取りパフォーマンスを最適化します。このテストの目的は、レイテンシーに影響を与えずに、ElastiCache Serverless でワークロードをいかに高速にスケールできるかを示すことです。 上記のグラフからわかるように、10 分ごとに 1 秒あたりのリクエスト数 (RPS) が 2 倍になり、テストの目標リクエストレートである 100 万 RPS に到達しました。テストの実施中、p50 GET のレイテンシーが約 751 マイクロ秒のままであり、常に 860 マイクロ秒未満であることが確認されました。同様に、p50 SET のレイテンシーは約 1,050 マイクロ秒のままであり、スループットが急激に増加しても 1,200 マイクロ秒を超えないことが確認されました。 留意点 エンジンバージョンのアップグレード – ElastiCache Serverless は、新機能、バグ修正、セキュリティアップデート (エンジンの新しいマイナーバージョンやパッチバージョンを含む) をキャッシュに透過的に適用します。新しいメジャーバージョンがリリースされると、ElastiCache Serverless はコンソールに通知を送信し、 Amazon EventBridge にイベントを送信します。ElastiCache Serverless のメジャーバージョンアップグレードは、アプリケーションを中断しないように設計されています。 パフォーマンスと監視 – ElastiCache Serverless は、メモリ使用量 ( BytesUsedForCache )、CPU 使用量 ( ElastiCacheProcessingUnits )、キャッシュメトリクス ( CacheMissRate 、 CacheHitRate 、 CacheHits 、 CacheMisses 、 ThrottledRequests など) を含む、一連のメトリクスを Amazon CloudWatch に公開します。また、ElastiCache Serverless は、キャッシュの作成、削除、制限更新などの重要なイベントに対して Amazon EventBridge イベントを発行します。使用可能なメトリクスとイベントの完全なリストについては、ドキュメントを参照してください。 セキュリティとコンプライアンス – ElastiCache Serverless キャッシュは、VPC 内からアクセスできます。 AWS Identity and Access Management (IAM) を使用することで、データプレーンにアクセスできます。デフォルトでは、ElastiCache Serverless キャッシュを作成した AWS アカウントのみがアクセスできます。ElastiCache Serverless は、保管中および転送中のすべてのデータを暗号化しており、これには ElastiCache Serverless への各接続を暗号化する Transport Layer Security (TLS) が使用されています。オプションで、VPC 内、サブネット内、IAM アクセス内、暗号化用の AWS Key Management Service (AWS KMS) キー内のキャッシュに対するアクセスを制限することもできます。ElastiCache Serverless は PCI-DSS、SOC、ISO に準拠しており、HIPAA に対応しています。 今すぐご利用いただけます Amazon ElastiCache Serverless は、中国を含むすべての商用 AWS リージョンでご利用いただけるようになりました。ElastiCache Serverless では、前払いコストは発生せず、使用したリソースに対してのみ料金が発生します。キャッシュされたデータ (GB/時)、使用した ECPU、スナップショットストレージ (GB/月) に対してのみお支払いいただきます。 詳細については、「 ElastiCache Serverless ページ 」と「 ElastiCache Serverless の料金ページ 」をご覧ください。ぜひお試しいただき、 AWS re:Post for Amazon ElastiCache または通常の AWS サポートのお問い合わせからフィードバックをお寄せください。 – Channy 原文は こちら です。

はじめに SAP Enterprise Portal (EP) などの SAP Java アプリケーションでは、HTTP(s) 要求のエントリポイントとして SAP Web ディスパッチャを使用します。SAP Web ディスパッチャは、インターネットまたはイントラネットからの要求を受信し、アプリケーションサーバー間で要求を分散します。インターネットベースの HTTP(s) リクエストの場合、SAP Web Dispatcher はインターネットにアクセスできる必要があるため、パブリックサブネットにインストールする必要があります。多くの SAP のお客様は、アタックサーフェスを減らすためにパブリックサブネットに EC2 インスタンスを設置することを避けています。 このブログでは、SAP EP アプリケーションに Elastic Load Balancing （ELB）を使用する方法について説明します。SAP EP アプリケーションは、HTTP リクエストの負荷分散に Application Load Balancer（ALB）を使用します。SAP Web dispatcher とは異なり、ALB はサーバーレスサービスであり、AWS によるマネージドサービスです。SAP EP に HTTP トラフィックを提供するインターネットに面した ALB を構成することができます。ALB では、既知の脆弱性に対処するための AWS Web Application Firewall （WAF）、コンテンツ高速化のための Amazon CloudFront 、TLS/SSL 証明書を管理するための AWS Certificate Manager （ACM）と統合することができます。 Application Load Balancer とその特徴 ALB は可用性の高いサービスで、クライアントからの HTTP(s) リクエストを受け取り、ルールに基づいてターゲットグループに振り分けます。各ターゲットグループには、SAP EP の単一または複数のアプリケーションサーバーの IP アドレスまたは EC2 インスタンス ID と HTTP ポートの組み合わせが含まれます。HTTP(s) リクエストは ALB によってアプリケーションサーバーに転送されます。 ALB は以下の SAP EP の要件を満たすことができます。 可用性が高く、複数のアベイラビリティゾーン（AZ）にリクエストを分散できる、レイヤー 7 の HTTP（s）ロードバランシングサービス。 高セキュリティ、高信頼性、スケーラブルなマネージド AWS サービスであり、手動でのサーバーメンテナンスが不要（サーバーレス）。 HTTP(s) リクエストは、ホストおよび/またはポートベースのマッピングに基づいて、複数のアプリケーションサーバーに転送することができます。 TLS/SSL 暗号化オフロード。ALB は SSL 証明書と連携してロードバランサーとクライアント間のトラフィックを暗号化します。受信トラフィックは、SAP アプリケーションをホストする EC2 インスタンスに到達する前に、アクセス制御リスト（ACL）に対する厳格なチェックを通過しなければなりません。 Simple and Protected GSS-API Negotiation（SPNEGO）と Security Assertion Markup Language（SAML）によるシングルサインオン（SSO）をサポートし、Active Directory などのアイデンティティプロバイダと認証します。 HTTP リクエストフィルタリング。WAF は、 このブログ で紹介した SQL インジェクションのような Open Web Application Security Project (OWASP) の攻撃に対する追加のセキュリティ・レイヤーとして、ALB と共に使用することができます。WAF はまた、ACL とルールの形でトラフィック検査とフィルタリングルールのサポートを提供します。 ドキュメント に従って、WAF でカスタムルールを定義することもできます。 SSL 証明書の管理。ACM は、この ドキュメント で説明されているように、SSL/TLS 証明書を管理するために使用することができます。 アーキテクチャ 1) SAP EP のシングル ALB アーキテクチャ 複数の SAP アプリケーションサーバー間で負荷を分散するために、単一の ALB を使用することができます。ALB は、インターネットに面したものでも、イントラネットに面したものでもかまいません（内部 ALB とも呼ばれます）。ダイレクト・コネクトまたは仮想プライベート・ネットワーク（VPN）を介して顧客のネットワークから到着する HTTP（s）リクエストに対して、「内部」ALB はリクエストを転送し、アプリケーション・サーバーに負荷分散します。しかし、顧客がインターネットから SAP EP へのアクセスを許可したい場合、図 1 の右側の図のように、 パブリックサブネット上のインターネットに面した ALB が必要になります 。 図 1：左：SAP EP の単一内部 ALB アーキテクチャ、右：SAP EP の単一インターネット ALB アーキテクチャ 2) SAP EP の ALB サンドイッチ・アーキテクチャ 図 2：SAP EP の ALB サンドイッチ・アーキテクチャ 図 2 に示すように、インターネットに面した ALB をパブリックサブネットに、2つ目の内部 ALB をプライベートサブネットに配置することで、2 つの ALB を組み合わせることができます。このような配置は、SAP アプリケーションのサブネットがインターネットに露出しないため、爆発半径を小さくすることができ、 AWS Well-Architected Framework と整合して耐障害性を確保しながら、アーキテクチャをよりセキュアにすることができます。 アーキテクチャの説明 パブリックサブネットがネットワークアカウントにあり、プライベートサブネットが AWS 本番アカウントにある 2 アカウント戦略が考えられます。同じアーキテクチャを 1 つのアカウントでデプロイすることもできます。 ネットワークアカウントはインターネットにアクセスできますが、AWS 本番アカウントはインターネットに直接アクセスできません。これにより、AWS 本番アカウントはよりセキュアになります。 2 つの ALB を考えました。Network アカウントの ALB は、SAP EP 用のインターネットに面した ALB です。これはインターネット（外部）ユーザーにサービスを提供し、それはイントラネット（内部）ユーザーにサービスを提供するイントラネットに面した（内部）ALB に接続されています。 図 2 では、可用性と回復力を向上させるために、複数の AZ と Amazon EC2 Auto Scaling グループに分散した VM シリーズのファイアウォールを使用しています。 このようなサンドイッチ・アーキテクチャは、インバウンド・トラフィックのファイアウォール検査の要件に対応するために使用されます。トラフィックはまず、VM シリーズ・ファイアウォールの Auto Scaling Group のフロントエンドとして使用される ALB を通過する。各ファイアウォールの宛先は、その背後にターゲットグループ（この場合は EC2 インスタンス）を含む ALB です。このアプローチにより、セキュリティ検査層とウェブフロントエンド層の両方が、互いに独立したコスト効率の良い方法でスケールイン/スケールアウトできるようになります。詳細はこちらの ブログ を参照してください。 インターネットに面した ALB の構成 インターネットに面した ALB は HTTP または HTTPS トラフィックをリッスンするように設定されます。セキュリティを向上させるために HTTP ポート 80 を HTTPS ポート 443 にルーティングします。 デフォルトのセキュリティポリシー ELBSecurityPolicy-2016-08 は、TLSv1.2 をサポートしているので、インターネットに面したロードバランサーと内部のロードバランサーの両方に推奨されるポリシーです。 HTTPS リスナーについては、 ACM 証明書 またはサードパーティ証明書を使用して、ALB 上に 1 つの SSL/TLS サーバー証明書をデプロイする。 フローは以下の通りである： トラフィックはインターネットに面した ALB で受信されます。 ALB はトラフィックをファイアウォール・インスタンス・ベースのターゲット・グループに転送します。 ファイアウォールインスタンスでは、静的ネットワークアドレス変換（NAT）またはポート間 NAT ポリシーが内部 ALB にトラフィックをルーティングするために使用されます。 内部 ALB はファイアウォールからトラフィックを受信します。 内部 ALB の設定 ポート 80 は、ファイアウォールを経由してルーティングされた、インターネットに面した ALB からの着信要求をリッスンする HTTP ポートとして定義されています。 ポート 443 は、企業ネットワーク内で SAP EP に直接アクセスするユーザーをリッスンする HTTPS ポートとして定義されています。 デフォルトのセキュリティポリシー ELBSecurityPolicy-2016-08 は、TLSv1.2 をサポートしているため、インターネットに面したロードバランサーと内部のロードバランサーの両方に推奨されるポリシーです。 HTTPS リスナーについては、 ACM 証明書 またはサードパーティ証明書を使用して、ALB 上に 1 つの SSL/TLS サーバー証明書を展開します。 図 3 内部 ALB リスナー 内部 ALB のターゲットグループ SAP EP アプリケーションサーバーのすべての IP アドレスがターゲットグループに追加されます。EC2 インスタンスを追加することもできる一方、EC2 インスタンス ID は障害による終了時に変更される可能性があり、新しいインスタンスがその代わりになる可能性があるため、 「IP アドレス」をターゲットとして追加する ことが望ましい。 図4 内部ALBのSAP EPのターゲットグループ SAP EP のターゲットグループの属性 Stickiness Type Application cookie[app_cookie] Stickiness Duration 17 hours App cookie name saplb_* 図 5：SAP EP のスティッキネス属性 SAP EP は、アプリケーションベースのスティッキネスを有効にする必要があります。これは、ステートフルなユーザー・セッションをサポートするために、後続のリクエストを関連するアプリケーション・サーバーに渡すために必要です。バックエンドの SAP EP が saplb_* クッキーを追加し、ALB がその値をコピーして AWSALBAPP-* クッキーと呼ばれる別のクッキーを作成することを確認する必要があります。 スティッキネス期間は、ユーザのセッションが常に ALB によって特定のアプリケーションサーバにルーティングされることを保証するのに十分でなければなりません。これは要件に基づいて調整できます。営業時間または 1 日を推奨します。 リスナールール リスナーは、設定したプロトコルとポートを使用して接続要求をチェックするプロセスです。ALB を作成するときにリスナーを定義し、いつでもロードバランサーにリスナーを追加できます。例えば、図 3 に示すように、内部 ALB に 2 つのリスナーを定義しました： インターネットに面した ALB から到着するトラフィック用の HTTP 80 HTTPS 443 社内ネットワークから来るトラフィック用 リスナーのリスナールールは、ALB が登録されたターゲットにどのようにリクエストをルーティングす るかを決定する。各ルールは、優先度、1 つ以上のアクション、および 1 つ以上の条件で構成されます。詳細については、この ドキュメント を参照してください。 内部 ALB リスナールール 以下の表は、ALB でのルールと設定の例を示しています。 ルール番号 Internal ALB Listener –Port 443 (Rule for internet traffic/internet facing ALB forward) Internal ALB Listener – Port 80 (Rule for intranet traffic) Corresponding SAP Web Dispatcher Rule 5 If Source IP is 10.0.0.0/8 OR 192.168.138.0/23 PATH is */webdynpro/dispatcher/sap.com/tc~sec~ume~wd~umeadmin/* Then Forward to sap-ep-prod-alb-tg: 1(100%) If PATH is */webdynpro/dispatcher/sap.com/tc~sec~ume~wd~umeadmin/* “Return Fixed Response- This Feature is Blocked over Internet” #User Administrator if %{PATH} regimatch ^/webdynpro/dispatcher/sap.com/tc~sec~ume~wd~umeadmin(.*) [and] If %{REMOTE_ADDR} !regimatch 10(.*) [and] %{REMOTE_ADDR} !regimatch 192.168.138(.*) [and] %{REMOTE_ADDR} !regimatch 192.168.139(.*) RegForbiddenURL ^/webdynpro/dispatcher/sap.com/tc~sec~ume~wd~umeadmin(.*) – [break] 6 If PATH is */webdynpro/dispatcher/sap.com/tc~sec~ume~wd~umeadmin/* “Return Fixed Response- This Feature is Blocked over Internet” 上記の 2 つのリスナールール 5 と 6 は、ユーザー管理エンジン（UME）管理者がシステム管理者の内部からのみアクセスできることを保証します。 ルール 5 は、社内サブネット範囲 10.0.0.0/8 または 192.168.138.0/24 または 192.168.139.0/24 内の IP アドレスからの UME 管理者へのアクセスを許可することを示します。 ルール 6 は、UME Admin がその他の IP アドレスからのアクセスを許可されていないことを示します。 図 6：ALB 内部 HTTP リスナーポート 443 の設定 インターネットに面した ALB リスナーのルール HTTP 要求がポート 443 でリッスンしているインターネット向け ALB に到達すると、インターネット向け ALB のターゲットグループとして定義されている内部 ALB にトラフィックを転送します。 リスナー・ルールに従って、インターネットから UME Admin へのリクエストがあると、図 7 と図 8 のようにブロックされます。 図 7: 内部 ALB HTTP リスナー・ポート 80 の設定 図 8：インターネットからユーザ管理 URL にアクセスしようとした結果 ALB の属性とセキュリティに関する考慮事項 ALB が無効なパケットをドロップし、有効でないヘッダーフィールドを持つ HTTP ヘッダーがロードバランサーによって削除されるように ALB が設定されていることを確認することを推奨します。 TLS 1.1 は TLS 1.1 と比較してセキュリティが強化されているため、ALB レベルでは TLS 1.2 が有効です EC2 のオートスケーリングが計画されている場合は、削除保護を無効にする必要がある。 アイドルタイムアウトは、SAP アプリケーションの処理タイムアウトと同じかそれ以上でなければなりません。デフォルトでは、SAP EP のタイムアウトは 600 秒で、これをインターネットとイントラネットの両方の ALB に組み込む必要があります。 インターネット経由で SAP EP 経由で SAP ECC バックエンドコンテンツにアクセスするための ALB サポート ALB が SAP EP への接続をサポートし、インターネット経由で SAP EP から SAP ECC バックエンドにリダイレクトできるようにしたいと考えています。オープンネットワーク上で SAP EP から SAP ECC バックエンドへのトラフィックの流れの詳細については、この SAP ブログ をご覧ください。 一部のお客様には、インターネットトラフィックの完全修飾ドメイン名 (FQDN) とポートの組み合わせを 1 つだけ許可する厳しいポリシーがあります。このような場合、複数の SAP システム間で負荷を分散するには、コンテキストベースまたはパスベースのマッピングが必要です。たとえば、顧客がポート 443 を持つ外部 ALB を 1 つだけ許可していて、SAP EP と SAP Fiori への接続を許可する必要がある場合、リスナールールの条件には、SAP EP の場合は「/irj/portal」または「/nwa」、SAP Fiori の場合は「/fiori」によるマッピングが必要です。ALB が 1 つしかない場合、特に「/icon」、「/sap」などの共通コンテンツでは、パスの競合が発生する可能性があります。そのため、インターネットユーザーやイントラネットユーザー向けに設計するには、複数の SAP ソリューションに対して 2 つ以上の ALB を組み合わせることをお勧めします。 次のアーキテクチャは、コンテキストベースのマッピングに使用される 2 組の ALB を示しています。1 組は SAP EP 用、もう 1 組は SAP ECC がそれぞれのアプリケーションにアクセスするためのものです。 図 9: インターネット経由で SAP EP から SAP ECC コンテンツにアクセスするためのマルチ ALB アーキテクチャ インターネット経由で SAP EP 経由で SAP ECC 機能を利用するという目標を達成するために、2 組の ALB を検討しました。ペア 1 には、前述の SAP EP で説明したアーキテクチャを備えたインターネット向けの ALB と内部 ALB が含まれています。ペア 2 には、SAP ECC システム用のインターネット向け ALB と内部 ALB のセットがもう 1 つ含まれています。 SAP ECC webdynpro URL にはインターネット経由で直接アクセスせず、SAP EP または同じドメインのシステムからのみアクセスできるようにする必要があります。 これは、図 10 に示すように、SAP ECC のインターネット向け ALB にリスナールールを実装することで実現されます。このルールでは、「HTTP ヘッダーリファラー」フィールドにより、ECC サービスには ess-ep.example.com ALB FQDN からのみアクセスでき、インターネット経由の ECC サービスへの直接アクセスは HTTP 応答 402 でブロックされます。 図 10: ECC ALB リスナールールの HTTP ヘッダーリファラー SAP ERP の内部 ALB には、リスナーポート 443 を介して直接アクセスできるため、社内ネットワークから直接アクセスすることも、SAP EP から参照することもできます。 図 11: SAP EP の ESS iView 図 12: システムエイリアス設定 たとえば、インターネットユーザーは、SAP EP ALB ベースのポータル URL https://ess-ep.example.com/irj/portal にログインして、SAP ECC 上で稼働する従業員セルフサービス (ESS) webdynpro アプリケーションにアクセスできます。このアプリケーションは、図 11 に示すように https://ess-ecc.example.com/sap/bc/webdynpro/ZHRESS にある SAP ECC ALB を使用してセットアップされています。 SAP ECC の「システムエイリアス」は、SAP ECC ALB FQDN で定義されています。これにより、図 12 に示すように、https://&lt;EP-ALB URL &gt;/irj/portal-&gt; システム管理-&gt; システムランドスケープまで SAP EP からの直接 SSO が可能になります。SAP ECC のインターネットトランザクションサーバー (ITS) ホスト名とアプリケーションサーバーホスト名は、SAP ECC ALB FQDN で定義されています。 予想される HTTP リクエストフロー: ユーザーはまず SAP EP ポータルの URL にアクセスし、/irj/portal を開きます。 リクエストは VM シリーズのファイアウォールを通過する前に、インターネットに直接接続されている SAP EP ALB に到達します。 その後、SAP EP の内部 ALB に転送され、最後に SAP EP アプリケーションサーバに転送されます。 SAP EP 内に入ると、ユーザーが ESS タブをクリックすると、リクエストは SAP ECC のインターネットに直接接続された ALB にリダイレクトされます。 その後、リクエストは VM シリーズのファイアウォールに送信され、SAP ECC 内部 ALB に到達してリスナールールを検証します。 一致条件に基づいて、トラフィックを SAP ECC ターゲットグループに送信して SAP ECC アプリケーションサーバーに到達します。 ユーザーがインターネット経由で SAP ECC webdynpro URL に直接アクセスしようとすると、アクセスは拒否されます。これは、図 10 に示すように、ルールに示されている「リファラー」である SAP EP ALB が ECC ALB にアクセスする唯一の方法だからです。 HTTP リファラーは外部 ALB 側にしか実装されていないため、イントラネットユーザーが内部 ALB に直接接続しても、URL に直接または間接的にアクセスしても問題はありません。 ALB パフォーマンス分析とトラブルシューティング ALB のパフォーマンスをモニタリングするには、 Amazon CloudWatch コンソール、メトリックスに移動して目的の ALB を選択するか、EC2 コンソール-&gt; 負荷分散-&gt; ターゲットグループに移動し、目的のターゲットグループを選択して [モニタリング] タブをクリックします。詳細については、次の AWS ドキュメント を参照してください。以下は ALB の CloudWatch メトリクスの図の例で、インドの営業時間のピーク時に 30 分間、リクエスト数が 1500 ～ 2000 リクエストだった場合の平均「目標応答時間」が約 150 ～ 200 ミリ秒であることを示しています。 図 13: Amazon クラウドウォッチ ALB パフォーマンスメトリックス このナレッジベース を参照して、高レイテンシーまたはタイムアウトの問題による ALB パフォーマンスのトラブルシューティングを行うことができます。SAP EP に関連する問題を絞り込んだら、ICM ログまたはデフォルトトレースで手がかりがないか確認してください。このような問題を解決するには、 SAP Note 2579836 を確認してください。 結論 このブログ記事では、SAP EP アプリケーション用の ALB のユースケース、アーキテクチャパターン、セットアップ手順について詳しく説明しました。お客様は、ALB の機能や利点を活用するために、SAP アプリケーションに ALB を使用しています。ALB は AWS のマネージドサービスであり、基盤となるオペレーションレイヤーや EC2 インスタンスのメンテナンスを必要としません。可用性が高くスケーラブルなサービスとして提供されるため、SAP 環境を簡素化できます。 SAP on AWS の詳細については、 AWS 製品ドキュメント をご覧ください。 さらに専門的なガイダンスが必要な場合は、AWS アカウントチームに連絡して、地元の SAP スペシャリストソリューションアーキテクトまたは AWS プロフェッショナルサービス SAP 専門プラクティスに依頼してください。 SAP on AWS ディスカッションにご参加ください。 カスタマーアカウントチームと AWS サポートチャネルに加えて、 Re: Post — AWS コミュニティ向けの 再考された Q&amp;A エクスペリエンス で私たちと交流することもできます。SAP on AWS ソリューションアーキテクチャチームは定期的に SAP on AWS のトピックを監視し、お客様やパートナーを支援するためのディスカッションや質問に回答しています。質問がサポートに関連していない場合は、re: Post でのディスカッションに参加して、コミュニティのナレッジベースに追加することを検討してください。 このブログは Sumit Dey が共同執筆し、翻訳は Partner SA 松本が担当しました。原文は こちら です。

Amazon Aurora Limitless Database のプレビューを開始しました。Aurora Limitless Database は自動水平スケーリングをサポートする新機能であり、1 秒間に数百万件の書き込みトランザクションを処理し、1 つの Aurora データベースでペタバイト規模のデータを管理できるようにします。 Amazon Aurora リードレプリカを使用すると、1 つのデータベースインスタンスが提供できる上限を超えて、Aurora クラスターの読み込みキャパシティを増やせます。今回、Aurora Limitless Database によって、データベースの書き込みスループットとストレージ容量を単一の Aurora ライターインスタンスの上限を超えてスケールできるようになりました。Limitless Database に使用されるコンピューティング能力とストレージ容量は、クラスター内のライターインスタンスとリーダーインスタンスの容量とは独立して追加されます。 Limitless Database を使用することで、大規模なアプリケーションの構築に集中できます。ワークロードをサポートするために、複数のデータベースインスタンスにわたってデータをスケールする複雑なソリューションを構築、保守する必要はありません。Aurora Limitless Database はワークロードに基づいてスケーリングを行い、これまで複数の Aurora ライターインスタンスが必要だった書き込みスループットとストレージ容量を実現します。 Amazon Aurora Limitless Database のアーキテクチャ Limitless Database には、複数のデータベースノード (トランザクションルーターまたはシャード) で構成される 2 層アーキテクチャが使用されています。 シャードは Aurora PostgreSQL DB インスタンスであり、それぞれがデータベースのデータのサブセットを保存します。これによって並列処理が可能になり、書き込みスループットが向上します。トランザクションルーターは、データベースの分散性を管理し、単一のデータベースイメージをデータベースクライアントに提供します。 トランザクションルーターは、データの保存場所に関するメタデータの管理、受信した SQL コマンドの解析とシャードへの送信、シャードからのデータの集約と単一の結果のクライアントへの返信、分散トランザクションの管理による分散データベース全体の整合性の維持を行います。Limitless Database アーキテクチャを構成するすべてのノードは、DB シャードグループに含まれています。DB シャードグループには、Limitless Database リソースにアクセスするための独立したエンドポイントがあります。 Aurora Limitless Database の利用開始 Aurora Limitless Database のプレビューを利用するには、サインアップをしてください。間もなく招待されます。プレビューは、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (アイルランド) の各 AWS リージョンにて、新しい Aurora PostgreSQL クラスターのバージョン 15 で利用可能です。 Aurora クラスターの作成ワークフローの一環として、 Amazon RDS コンソール または Amazon RDS API で Limitless Database と互換性のあるバージョンを選択します。次に、DB シャードグループを追加して、新しい Limitless Database テーブルを作成できます。また、Aurora キャパシティユニット (ACU) の最大値を選択できます。 DB シャードグループを作成したら、エンドポイントを含む詳細を [データベース] ページで確認できます。 Aurora Limitless Database を使用するには、 psql または PostgreSQL で動作するその他の接続ユーティリティを使用して、DB シャードグループのエンドポイント (Limitless エンドポイント) に接続する必要があります。 Aurora Limitless Database には、データを格納するテーブルが 2 種類あります。 シャードテーブル – このテーブルは複数のシャードに分散されています。データは、シャードキーと呼ばれるテーブル内の指定された列の値に基づいてシャード間で分割されます。 参照テーブル – このテーブルでは、すべてのデータがすべてのシャードに存在するため、不要なデータ移動がなくなり、結合クエリをより高速に実行できます。製品カタログや郵便番号など、あまり変更されない参照データによく使用されます。 シャードテーブルまたは参照テーブルを作成したら、大量のデータを Aurora Limitless Database にロードし、標準の PostgreSQL クエリを使用してそれらのテーブル内のデータを操作できます。 プレビューが公開中 Amazon Aurora Limitless Database のプレビューで、そのパワーをいち早く体験できます。 ぜひ サインアップ してお試しいただき、 AWS re:Post for Amazon Aurora または通常の AWS サポート窓口をとおしてフィードバックをお寄せください。 – Channy 原文は こちら です。

責任ある人工知能 (AI) 戦略の一環として、 Guardrails for Amazon Bedrock (プレビュー版) を使用して、ユースケースと責任ある AI ポリシーに合わせてカスタマイズされたセーフガードを実装することで、ユーザーと生成系 AI アプリケーション間の安全なやりとりを促進できます。 AWS は、教育と科学に焦点を当てて、開発者が責任ある AI を AI ライフサイクル全体に統合できるよう支援することで、責任ある人間中心の考え方で生成系 AI を開発することに取り組んでいます。Guardrails for Amazon Bedrock を使用すると、自社のポリシーと原則に沿った適切で安全なユーザーエクスペリエンスを提供するためのセーフガードを一貫して実装できます。拒否トピックとコンテンツフィルターを定義して、ユーザーとアプリケーション間のやり取りから望ましくない有害なコンテンツを削除するのにガードレールが役立ちます。これにより、基盤モデル (FM) に組み込まれているあらゆる保護機能に加えて、より高いレベルの管理が可能になります。 Amazon Bedrock の微調整されたモデルや Agents for Amazon Bedrock を含むすべての大規模言語モデル (LLM) にガードレールを適用できます。これにより、さまざまなアプリケーションに詳細設定を適用する方法に一貫性が保たれるため、要件に基づいてユーザーエクスペリエンスを綿密に管理しながら、安全にイノベーションを進めることができます。Guardrails for Amazon Bedrock は、安全性とプライバシー管理を標準化することで、責任あるAI の目標に沿った生成系 AI アプリケーションの構築を支援します。 Guardrails for Amazon Bedrock で利用できる主な管理について簡単に説明します。 主な管理 Guardrails for Amazon Bedrock を使用すると、次のポリシーセットを定義してアプリケーションに安全対策を講じることができます。 拒否トピック — 短い自然言語による説明を使用して、アプリケーションのコンテキストでは望ましくないトピックのセットを定義できます。例えば、銀行の開発者は、投資アドバイスを提供しないように、オンラインバンキングアプリケーションのアシスタントを設定したい場合があります。 私は拒否トピックを「投資アドバイス」という名前で指定し、「投資アドバイスとは、収益の創出または特定の財務目標の達成を目的とした資金または資産の管理または配分に関する問い合わせ、ガイダンス、または推奨を指します」など、自然な言葉で説明しています。 コンテンツフィルター — 憎悪、侮辱、性的、暴力などのカテゴリーで有害なコンテンツをフィルタリングするように閾値を設定できます。多くのFMには、望ましくない有害な応答の発生を防ぐための保護機能がすでに組み込まれていますが、ガードレールを使用すると、ユースケースと責任ある AI ポリシーに基づいて、そのようなインタラクションを必要な程度にフィルタリングするための追加の管理が可能になります。フィルター強度が高いほど、フィルタリングが厳密になります。 PII リダクション (準備中) — 名前、E メールアドレス、電話番号などの個人を特定できる情報 (PII) を選択できるようになります。これらの情報は、FM が生成した応答で編集したり、PII が含まれている場合はユーザー入力をブロックしたりできます。 Guardrails for Amazon Bedrock は Amazon CloudWatch と統合されているため、ガードレールで定義されたポリシーに違反するユーザー入力や FM 応答をモニタリングして分析できます。 プレビューをお試しください 現在、Guardrails for Amazon Bedrock は、制限付きのプレビュー版でご利用いただけます。Guardrails for Amazon Bedrock にアクセスしたい場合は、通常の AWS サポートの連絡先にお問い合わせください。 プレビュー版では、Amazon Bedrock で利用できるすべての大規模言語モデル (LLM) にガードレールを適用できます。これには、Amazon Titan Text、Anthropic Claude、Meta Llama 2、AI21 Jurassic、Cohere Command が含まれます。Agents for Amazon Bedrock だけでなく、カスタムモデルでガードレールを使用することもできます。 詳細については、 Guardrails for Amazon Bedrock に関するウェブページをご覧ください。 –&nbsp; Antje 原文は こちら です。

7 月に、プレビュー版として Agents for Amazon Bedrock をご紹介 しました。現在、 Agents for Amazon Bedrock は一般公開されています。 Agents for Amazon Bedrock は、多段階のタスクのオーケストレーションによって、生成系人工知能 (AI) アプリケーション開発を加速するのに役立ちます。Agents は、基盤モデル (FM) の推論機能を使用して、ユーザーが要求したタスクを複数のステップに分解します。Agents は、デベロッパーから指示された手順に従ってオーケストレーション計画を作成します。その後、企業の API を呼び出すことと、検索拡張生成 (RAG) を使用してナレッジベースにアクセスすることによって計画を実行し、エンドユーザーに最終的な応答を提供します。この仕組みを知りたい場合は、「 高度な推論入門 」や「 RAG 入門 」など Agents に関する私の以前のブログをチェックしてください。 本日より、Agents for Amazon Bedrock には、オーケストレーションの制御の改善や思考の連鎖による推論の可視性の向上など、強化された機能も搭載されています。 目立たないところでは、Agents for Amazon Bedrock は、小売注文の管理や保険金請求の処理など、ユーザーが要求するタスクのプロンプトエンジニアリングとオーケストレーションを自動化しています。エージェントはオーケストレーションプロンプトを自動的に作成し、ナレッジベースに接続されている場合は会社固有の情報で補足し、API を呼び出して自然言語でユーザーに応答します。 デベロッパーは、新しいトレース機能を使用して、計画を実行する際に使用された推論を追っていくことができます。オーケストレーションプロセスの中間ステップを表示し、この情報を使用して問題のトラブルシューティングができます。 また、エージェントが自動的に作成するプロンプトにアクセスして変更できるため、エンドユーザーエクスペリエンスをさらに向上させることができます。この自動的に作成されたプロンプト (またはプロンプトテンプレート) を更新して、FM によるオーケストレーションと応答を改善し、オーケストレーションのより細かい制御を可能にできます。 推論手順の表示方法とプロンプトの変更方法を紹介します。 推論手順を表示 トレースにより、思考の連鎖 (CoT) と呼ばれるエージェントの推論を可視化できます。CoT トレースを使用して、エージェントがどのようにタスクを実行するかをステップバイステップで確認できます。CoT プロンプトは、 ReAct ( 推論 と 行動 の相乗効果) と呼ばれる推論技術に基づいています。ReAct と特定のプロンプト構造の詳細については、 私の以前のブログ記事「高度な推論入門」 をご覧ください。 まず、 Amazon Bedrock コンソール に移動し、既存のエージェントの作業ドラフトを選択します。次に、 [テスト] ボタンを選択し、サンプルユーザーリクエストを入力します。エージェントの応答で、 [トレースを表示] を選択します。 CoT トレースには、エージェントの推論がステップバイステップで表示されます。各ステップを開いて CoT の詳細を確認します。 可視性が向上することで、エージェントがタスクを完了するために用いた論理的根拠を理解しやすくなります。デベロッパーは、この情報を使用してプロンプト、手順、およびアクションの説明を改良し、ユーザーエクスペリエンスを繰り返しテストして改善する際のエージェントのアクションと応答を調整できます。 エージェントが作成したプロンプトを変更する エージェントは、指示された手順に基づいてプロンプトテンプレートを自動的に作成します。ユーザー入力の前処理、オーケストレーション計画、および FM 応答の後処理を更新できます。 まず、Amazon Bedrock コンソールに移動し、既存のエージェントの作業ドラフトを選択します。次に、 [高度なプロンプト] の横にある [編集] ボタンを選択します。 ここでは、4 種類のテンプレートにアクセスできます。前処理テンプレートでは、エージェントが ユーザー入力をコンテキスト化および分類する方法を定義します。オーケストレーションテンプレートでは、短期記憶、実行可能なアクションと利用可能なナレッジベースのリストとその説明、および問題を分解してこれらのアクションと知識をさまざまな順序または組み合わせで使用する方法のいくつかの例をエージェントに提供します。ナレッジベース応答生成テンプレートでは、ナレッジベースがどのように使用され、応答に要約されるかを定義します。後処理テンプレートでは、エージェントが最終応答をフォーマットしてエンドユーザーに提示する方法を定義します。テンプレートのデフォルトをそのまま使用することも、テンプレートのデフォルトを編集してオーバーライドすることもできます。 留意点 ここでは、Amazon Bedrock のエージェントを使用する際に知っておくべきベストプラクティスと重要事項をいくつか紹介します。 Agents は、特定のタスクに集中できるようにすると最高のパフォーマンスを発揮します。目的 (手順) が明確で、利用可能な一連のアクション (API) に焦点が当てられているほど、FM は適切な手順を推論して特定しやすくなります。エージェントにさまざまなタスクを任せる必要がある場合は、エージェントを別々に分けて作成することを検討してください。 その他のガイドラインは次のとおりです。 API の数 – エージェントでは 3～5 個の API を使用し、少数の入力パラメータをいくつか指定します。 API 設計 – 冪等性の確保など、API を設計する際の一般的なベストプラクティスに従います。 API 呼び出しの検証 – API 設計のベストプラクティスに従って、すべての API 呼び出しに網羅的な検証を行います。これは特に重要です。なぜなら、大規模言語モデル (LLM) は幻覚のような入出力を生成する可能性があり、これらの検証はそのような事態が発生した場合に役立つことが証明されているからです。 利用可能なリージョンと料金 Agents for Amazon Bedrock は現在、米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョンでご利用いただけます。エージェントによる推論呼び出し ( InvokeModel API) に対して課金されます。 InvokeAgent API は別途課金されません。「 Amazon Bedrock の料金 」にはすべての詳細が記載されています。 詳細はこちら Agents for Amazon Bedrock の製品ページ Agents for Amazon Bedrock ユーザーガイド コンソールの Agents for Bedrock –&nbsp; Antje 原文は こちら です。

11月28日、 Amazon Bedrock で独自のデータを使用して基盤モデル (FM) をプライベートかつ安全にカスタマイズして、ドメイン、組織、ユースケースに固有のアプリケーションを構築できるようになったことを紹介できることを嬉しく思います。カスタムモデルを使用すると、会社のスタイル、意見、サービスを反映した独自のユーザーエクスペリエンスを作成できます。 微調整 では、タスク固有の独自のラベル付きトレーニングデータセットを供給することによってモデルの精度を高め、FM をさらに専門的にできます。 事前トレーニングの継続 では、カスタマーマネージドキーを使用した安全で管理された環境で、ラベルのない独自のデータを使用してモデルをトレーニングできます。事前トレーニングの継続によって、当初のトレーニングよりもしっかりした知識と適応性が蓄積されて、モデルがさらにドメイン固有のものになります。 2 つのモデルカスタマイズオプションについて簡単に説明します。 Amazon Bedrock コンソール または API を使用して、微調整ジョブや事前トレーニング継続ジョブを作成できます。コンソールで、 [Amazon Bedrock] に移動し、 [カスタムモデル] を選択します。 Meta Llama 2、Cohere Command Light、Amazon Titan の FM を微調整する Amazon Bedrock は、 Meta Llama 2 、 Cohere Command Light 、および Amazon Titan のモデル の微調整もサポートするようになりました。コンソールで微調整ジョブを作成するには、 [モデルのカスタマイズ] を選択し、 [微調整ジョブの作成] を選択します。 AWS SDK for Python (Boto3) を使用した簡単なデモを次に示します。Cohere Command Light を微調整してダイアログを要約するようにしましょう。デモの目的で、公開されている dialogsum データセットを使用していますが、これを貴社固有のデータにして構いません。 Amazon Bedrock での微調整に備えて、データセットを JSON Lines 形式に変換して Amazon S3 にアップロードしてあります。各 JSON 行には、プロンプトフィールドと完了フィールドの両方が必要です。最大 10,000 件のトレーニングデータレコードを指定できますが、数百の例で既にモデルのパフォーマンスが向上していることがわかる場合があります。 {"completion": "Mr. Smith's getting a check-up, and Doctor Haw...", "prompt": Summarize the following conversation.\n\n#Pers..."} {"completion": "Mrs Parker takes Ricky for his vaccines.Dr.P...", "prompt": "Summarize the following conversation.\n\n#Pers..."} {"completion": "#Person1#'s looking for a set of keys and asks...", "prompt": "Summarize the following conversation.\n\n#Pers..."} 簡潔にするために、プロンプトフィールドと完了フィールドを編集しました。 次のコマンドを使用して、微調整をサポートしている使用可能な基盤モデルを一覧表示できます。 import boto3 bedrock = boto3.client(service_name="bedrock") bedrock_runtime = boto3.client(service_name="bedrock-runtime") for model in bedrock.list_foundation_models( byCustomizationType="FINE_TUNING")["modelSummaries"]: for key, value in model.items(): print(key, ":", value) print("-----\n") 次に、モデルカスタマイズジョブを作成します。微調整をサポートする Cohere Command Light モデル ID を指定し、カスタマイズタイプを FINE_TUNING に設定し、トレーニングデータの Amazon S3 ロケーションを示します。必要に応じて、微調整のためにハイパーパラメータを調整することもできます。 # カスタマイズしたい基盤モデルを選択 base_model_id = "cohere.command-light-text-v14:7:4k" bedrock.create_model_customization_job( customizationType="FINE_TUNING", jobName=job_name, customModelName=model_name, roleArn=role, baseModelIdentifier=base_model_id, hyperParameters = { "epochCount": "1", "batchSize": "8", "learningRate": "0.00001", }, trainingDataConfig={"s3Uri": "s3://path/to/train-summarization.jsonl"}, outputDataConfig={"s3Uri": "s3://path/to/output"}, ) # ジョブのステータスを確認 status = bedrock.get_model_customization_job(jobIdentifier=job_name)["status"] ジョブが完了すると、カスタムモデルの一意のモデル ID を受け取ります。微調整されたモデルは、Amazon Bedrock によって安全に保管されます。モデルをテストしてデプロイするには、 プロビジョンドスループット を購入する必要があります。 結果を見てみましょう。データセットから例を 1 つ選択し、微調整前のベースモデルと、微調整後のカスタムモデルに、次のダイアログを要約するように依頼します。 prompt = """次の会話を要約してください。\\n\\n #人物 1#: こんにちは。John Sandals という名前で予約しています。\\n #人物 2#: 身分証明書を見せていただけますか。\\n #人物 1#: はい。これです。\\n #人物 2#: どうもありがとうございます。Sandals 様、クレジットカードはお持ちですか。\\n #人物 1#: はい、もちろん。アメリカンエキスプレスでいいですか。\\n #人物 2#: 申し訳ありません。現在、私どもでは、マスターカードと VISA しか受け付けておりません。\\n #人物 1#: アメリカンエキスプレスでは駄目なんですね。 それでは、VISA もあります。\\n #人物 2#: ありがとうございます。お部屋番号は 507 で、禁煙、クイーンサイズベッドになります。よろしいですか。\\n #人物 1#: はい、結構です。\\n #人物 2#: ありがとうございます。こちらがキーになります。何かご用のときは、いつでもダイヤル 0 にお掛けください。\\n\\n Summary: """ Amazon Bedrock InvokeModel API を使用してモデルをクエリします。 body = { "prompt": prompt, "temperature": 0.5, "p": 0.9, "max_tokens": 512, } response = bedrock_runtime.invoke_model( # 微調整前の応答にはオンデマンド推論モデル ID を使用する # modelId="cohere.command-light-text-v14", # 微調整後の応答には、デプロイしたカスタムモデルの ARN を使用する modelId=provisioned_custom_model_arn, modelId=base_model_id, body=json.dumps(body) ) 微調整前の基本モデルの応答は次のようなものです。 #人物 2# は John Sandals の予約について応対しています。John は自分のクレジットカード情報を伝え、#人物 2# は、マスターカードと VISA しか受け付けないことを確認しました。John の部屋は 507 号室で、何か必要な場合は #人物 2# が対応します。 微調整後の応答は次のようなものです。短く、的を射たものです。 John Sandals は予約したホテルにチェックインしています。#人物 2 # は彼のクレジットカードを受け取って鍵を渡します。 Amazon Titan Text の事前トレーニングの継続 (プレビュー) Amazon Bedrock での事前トレーニングの継続は、現在、Titan Text Express や Titan Text Lite などの Amazon Titan Text モデルのパブリックプレビューでご利用いただけます。コンソールで事前トレーニング継続ジョブを作成するには、 [モデルのカスタマイズ] を選択し、 [継続的な事前トレーニングジョブの作成] を選択します。 次も boto3 を使った簡単なデモです。投資会社に勤務しているとしましょう。金融業界の用語に関する知識をモデルに追加するために、財務レポートとアナリストレポートで事前トレーニングを継続したいとします。デモ用に、トレーニングデータとして Amazon の株主レターのコレクションを選択しました。 事前トレーニングの継続に備えて、今度も、データセットを JSON Lines 形式に変換し、Amazon S3 にアップロードしてあります。ラベル付けされていないデータを扱っているので、各 JSON 行にはプロンプトフィールドのみが必要です。最大 100,000 件のトレーニングデータレコードを指定でき、通常は少なくとも 10 億個のトークンを供給すると有効性が確認できます。 {"input": "Dear shareholders: As I sit down to..."} {"input": "Over the last several months, we to..."} {"input": "work came from optimizing the conne..."} {"input": "of the Amazon shopping experience f..."} 簡潔にするために、入力フィールドを編集しました。 次に、データを指すカスタマイズタイプ CONTINUED_PRE_TRAINING のモデルカスタマイズジョブを作成します。必要に応じて、事前トレーニングの継続のためにハイパーパラメータを調整することもできます。 # カスタマイズしたい基盤モデルを選択 base_model_id = "amazon.titan-text-express-v1" bedrock.create_model_customization_job( customizationType="CONTINUED_PRE_TRAINING", jobName=job_name, customModelName=model_name, roleArn=role, baseModelIdentifier=base_model_id, hyperParameters = { "epochCount": "10", "batchSize": "8", "learningRate": "0.00001", }, trainingDataConfig={"s3Uri": "s3://path/to/train-continued-pretraining.jsonl"}, outputDataConfig={"s3Uri": "s3://path/to/output"}, ) ジョブが完了すると、別の一意のモデル ID を受け取ります。カスタマイズしたモデルは、Amazon Bedrock によって今度も安全に保管されます。微調整の場合と同様に、モデルをテストしてデプロイするには、プロビジョンドスループットを購入する必要があります。 留意点 知っておくべき重要な事項をいくつか次に示します。 データプライバシーとネットワークセキュリティ – Amazon Bedrock を利用すると、自らのデータを管理できるほか、すべての入力とカスタマイズは、ご利用の AWS アカウント以外には非公開のままとなります。プロンプト、完了、カスタムモデル、微調整や事前トレーニングの継続に使用されるデータなどのデータは、サービスの改善には使用されず、サードパーティのモデルプロバイダーと共有されることもありません。データは、API 呼び出しが処理される AWS リージョンに残ります。すべてのデータは、送信時および保管時に暗号化されます。 AWS PrivateLink を使用して VPC と Amazon Bedrock の間にプライベート接続を作成できます。 課金 – Amazon Bedrock では、モデルのカスタマイズ、保存、および推論に対して課金されます。モデルのカスタマイズでは、処理されたトークン数に応じて課金されます。これは、トレーニングデータセット内のトークンの数にトレーニングエポックの数を掛けたものです。エポックとは、カスタマイズ中にトレーニングデータを 1 回完全に通過することです。モデルストレージは、1 か月あたり、モデルごとに課金されます。推論は、プロビジョニングされたスループットを使用してモデルユニットごとに時間単位で課金されます。料金に関する詳細については、「 Amazon Bedrock の料金 」を参照してください。 カスタムモデルとプロビジョニングされたスループット – Amazon Bedrock では、プロビジョニングされたスループットを購入することで、カスタムモデルで推論を実行できます。これにより、長期契約と引き換えに一貫したスループットレベルが保証されます。アプリケーションのパフォーマンスニーズを満たすために必要なモデルユニットの数を指定します。カスタムモデル評価の初期段階では、プロビジョニングされたスループットを長期契約なしで時間単位で購入できます。長期契約がない場合、プロビジョニングされたスループットごとに 1 モデルユニットのクォータを使用できます。1 つのアカウントにつき最大 2 つのプロビジョニングされたスループットを作成できます。 可用性 Meta Llama 2、Cohere Command Light、および Amazon Titan Text FM の微調整サポートは、現在、米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョンでご利用いただけます。事前トレーニングの継続は、現在、米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョンでパブリックプレビューとしてご利用いただけます。詳細については、「 Amazon Bedrock デベロッパーエクスペリエンス 」ウェブページと ユーザーガイド をご覧ください。 Amazon Bedrock で FM を今すぐカスタマイズしましょう! –&nbsp; Antje 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 re:Invent ではキーノート以外にも多数のブレイクアウトセッションが実施されましたが、Youtubeにはそのセッションの多くの録画がアップロードされています。400以上のセッション録画があがっており、観やすいように技術ジャンルごと（例えばDatabaseとかServerless等）に分けて再生リストが作られています。ぜひre:Inventのキャッチアップにご利用ください。 – AWS Events 再生リスト (Youtube) 前回もご案内したように、日本語でのre:Invent振り返りオンラインセミナーも来年開催予定です。業界カット、ソリューションカットで整理して説明しますので、ご興味がある方はぜひお申込みください。 – AWS re:Invent Recap – ソリューション編 – AWS re:Invent Recap – インダストリー編 また、1月18日(木)に実施される初心者向けセミナー「AWS Builders Online Series」のクロージングセッションでも50分間でAWS キーメッセージと主要アップデートが解説されます。こちらもご活用ください。 – AWS Builders Online Series それでは、先週の主なアップデートについて振り返っていきましょう。 2023年12月11日週の主要なアップデート 12/11(月) AWS AppConfig now supports AWS PrivateLink AWS AppConfig が AWS PrivateLink をサポートしました。これにより、インターネットゲートウェイをもたないVPC内のリソースからAppConfigのAPIにアクセスすることが可能になります。 AWS CloudShell has migrated to Amazon Linux 2023 (AL2023) 管理コンソール内から簡単に呼び出せるシェル環境 AWS CloudShell のOSが Amazon Linux 2 (AL2) から Amazon Linux 2023 (AL2023) に変更されました。既存のCloud Shell環境のホームディレクトリは維持されていますが、OSが提供するパッケージは異なりますので（例えばPython 2はサポートされなくなります）、利用の前には動作を確認いただくのが良いでしょう。詳細は こちらのドキュメント を参照してください。 AWS Lambda supports additional concurrency metric for improved quota monitoring AWS Lambda のCloudWatchメトリクスとして ClaimedAccountConcurrency が追加されました。これは、使用されたunreserved concurrency、割り当て済のreserved concurrency とprovisioned concurrencyの合計をレポートするもので、あとどれぐらい同時実行可能かを把握するために利用できます。 AWS CodeDeploy now supports application stop hooks during Amazon EC2 Auto Scaling Group scale-ins CodeDeploy は ASG (Auto Scaling Group) スケールイン中にアプリケーションの停止フック (Stop Hook)を呼び出すことができるようになりました。これによりスケールダウン時の進行中タスクの完了や、アプリケーションリソースの開放等を適切なタイミングで実行可能です。AGS インスタンスの更新操作中にもフックを呼び出すことができるため、アプリケーション稼働させながらインスタンスにパッチを適用する際にも活用可能です。 Amazon Athena now supports user identities for data access and audit Amazon Athena で AWS IAM Identity Center からの trusted identity propagation がサポートされました。これによりシングルサインオンしたユーザーの権限に基づいたクエリや、監査が可能になります。詳細は こちらのドキュメント を参照してください。 12/12(火) Introducing managed package repository support for Amazon CodeCatalyst Amazon CodeCatalyst でマネージドパッケージリポジトリが一般提供開始（GA）になりました。CodeCatalyst ユーザーが npm パッケージをセキュアに保存し、共有可能なパッケージリポジトリです。またこのレポジトリ経由でOSSのパッケージも取得可能です。詳細は こちらのドキュメント を参照してください。 Amazon MSK extends AWS IAM support to all programming languages for existing clusters Amazon Managed Streaming for Apache Kafka (Amazon MSK) のIAMサポートが、AWS SDKが動作するすべてのプログラミング言語で利用できるようになりました。これによりIAMベースでKafkaリソースへのアクセス制御が可能になります。この連携はオープンスタンダードである SASL/OAUTHBEARER ベースで実装されています。詳細は こちらのブログ をご覧ください。 12/13(水) Connect GraphQL APIs to existing MySQL and PostgreSQL databases with AWS Amplify AWS Amplify は AWS Cloud Development Kit (CDK) で作成された GraphQL API のバックエンドとしてこれまでのDynamoDBサポートに加え、既存のMySQLとPostgreSQLを利用できるようになりました。これにより既存のデータソースを活用しつつ、ウェブ/モバイルアプリ用のフロントエンド用 API レイヤーを簡単に構築できます。詳細は こちらのブログ をご覧ください。 Amazon EC2 Inf2 instances, optimized for generative AI, now available globally Amazon EC2 Inf2 インスタンスの利用可能なリージョンが拡大され、新たに東京、ムンバイ、シンガポール、アイルランド、フランクフルトリージョンで利用可能になりました。Inf2 インスタンスは、 AWS Inferentia2 アクセラレーターを内蔵した深層学習等の推論に向くインスタンスで、大規模言語モデル (LLM) やビジョントランスフォーマ向けに高いコストパフォーマンスを提供します。 12/14(木) AWS Lambda adds support for Python 3.12 AWS Lambda のマネージドランタイムおよびコンテナイメージで Python 3.12 がサポートされました。また、Amazon CloudFrontのエッジロケーションで稼働するLambda@Edgeでも同様にPython3.12が利用可能になっています。 AWS Data Exchange now supports data grants for sharing data across organizations AWS Data Exchange で data grants が一般提供開始(GA)になりました。Data Exchangeに登録したリソース(S3やRedshiftの表等)へのリードオンリーアクセスを期限付きで別のAWSアカウントに共有する機能です。Data Exchangeの管理コンソールから簡単な操作で設定が可能です。詳細は ドキュメントをご覧ください 。 AWS IoT Core allows customers to use their own CAs with fleet provisioning AWS IoT Core で、 ユーザー独自のCA (Certificate Authority)をフリートのプロビジョニングに利用可能になりました。AWS IoT にはセキュアな通信のために X.509 クライアント証明書を発行する機能がありますが、今回の機能更新により独自の公開鍵インフラストラクチャ (PKI)を利用することが可能になります。 12/15(金) Amazon Kinesis Data Firehose supports delivery of decompressed CloudWatch Logs to destinations Amazon Kinesis Data Firehose で CloudWatch Logs からの出力ファイルを展開して転送先(S3とSplunk)に連携する機能が追加されました。CloudWatch Logsのデータは初期状態でgzip圧縮されているため、連携後の処理でgzipファイルが扱えない場合は別途展開を実装する必要がありましたが、この機能によりKinesis Data Firehoseの設定だけで展開可能になります。展開処理には追加の費用が発生しますので 料金表を確認してください （現時点では日本語ページは新料金が反映されていないので、英語に変更してご覧ください）。 Amazon Linux announces support for KVM and VMWare images with AL2023.3 Amazon Linux 2023 の3回目の四半期アップデートである AL2023.3 のKVMおよびVMware用のイメージがダウンロード可能になりました。 こちらから ダウンロード可能です。AL2023.3の変更点については こちらのリリースノート を参照してください。 Amazon Connect Cases now supports creating rules for monitoring and updating your cases クラウドコンタクトセンター Amazon Connect でケース（問い合わせ）をプログラム的に管理し、エスカレーションワークフローを設定できる機能が追加されました。Amazon Connect Case のルールデザイナーでルールを設定可能です。例えば、ケースが更新されるたびにタスクを自動的に作成したり、アラートメールを送るといった自動化が可能です。また、コンタクトセンターの会話を分析するAmazon Connect Contact Lensと連携して、会話内容に応じたフォローアップタスクの設定も可能です。 今年も毎週お届けしてきた 週刊AWS は、次号(12/25予定)が年内の最終号になる予定です。 それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (twitter – @simosako )

概要 クラウドアプリケーションとサービスを効果的に運用するには、監視とオブザーバビリティに重点を置く必要があります。チームにとって、メトリクスの定義、キャプチャ、分析、オペレーションの可視性の確保、ログから実用的な洞察を抽出することが重要です。 多くの企業では、技術チームがインテグレーションシステムを共有して、管理するサービスやインフラストラクチャを監視しています。共有されたオブザーバビリティシステムは、組織のパフォーマンスと可用性のデータを統合します。これにより、チームはサービスとコンポーネント間の関係を視覚化できます。チームはリアルタイムのデータを利用して共同作業を行い、パフォーマンス、可用性、またはセキュリティ問題の原因を迅速に特定します。 ワークロードがさまざまなクラウドで実行されるマルチクラウド環境では、一元化されたオブザーバビリティソリューションを作成すると、アプローチがサイロ化され、複雑さが増し、直接的および間接的なコストが増加する可能性があります。マルチクラウド環境でワークロードを実行するお客様にとって、全体像を把握し、統一された方法で監視を行うことは非常に重要です。 AWS は、ハイブリッド環境やマルチクラウド環境におけるモニタリングとオブザーバビリティの改善に役立ついくつかのサービスを提供しています。これらのサービスの1つが Amazon CloudWatch で、AWS、オンプレミス、その他のクラウド上のリソースとアプリケーションの状態を監視するのに役立ちます。 この記事ではAmazon CloudWatch の機能を使い、 Azure Monitor からのメトリクスデータクエリを使用して、マルチクラウド環境のワークロードを監視する方法を紹介します。 この機能により、ハイブリッド環境やマルチクラウド環境で実行されるワークロードや、独自のカスタムデータソースを可視化できます。Amazon EC2 インスタンスと Azure 仮想マシンの両方からの CPU 使用率などのデータを同じダッシュボードでクエリして視覚化し、このデータから アラームを作成 できます。 図 1. 機能の概要 CloudWatch データソースは、メトリクスクエリを実行する AWS Lambda を利用しています。クライアントシークレットや Azure サブスクリプション ID などのリモート認証情報のストレージは、 AWS Secrets Manager によって管理されます。 AWS CloudFormation はこれをユーザーに代わってスタックとして作成します。このアプローチは拡張可能なソリューションを生み出します。メトリクスデータソースの同じフレームワークに基づいて構築されています。このフレームワークにより、 Amazon S3 の CSV ファイルのデータや、 Amazon Managed Service for Prometheus のメトリクスを CloudWatch に組み込むことができます。他のデータソースの詳細については、 ドキュメント を参照してください。 前提条件 AWS アカウントを保有していること Owner 権限を持つ Azure アカウントのサブスクリプションを保有していること ステップ 1. Microsoft Entra ID ポータルで「アプリの登録」を作成する Azure メトリクスデータを Amazon CloudWatch にインテグレーションするには、Azure テナントから「アプリの登録」を作成する必要があります。このプロセスについては簡単に説明しますが、この記事では Azure ロールベースのアクセス制御 (Azure RBAC) や特定のセキュリティとガバナンスのニーズに関する詳細は説明しません。 ここで説明するプロセスを実装する前に、必ずレビューして、セキュリティ要件を満たしていることを確認してください。この設定では、Amazon CloudWatch のサブスクリプション内のすべてのリソースへの Reader アクセスをモニタリングできることに注意してください。 クラウドアプリケーションの管理者として Microsoft Entra 管理センター にサインインします。 「ID」 メニューを選択し、次に「アプリケーション」を選択し、「アプリの登録」を選択します。 「新規登録」を選択します。 名前 (例: Amazon CloudWatch) を入力し、ユースケースに合ったテナントオプションを選択します。これはデフォルトの 「この組織ディレクトリのみに含まれるアカウント (既定のディレクトリ のみ – シングル テナント)」設定のままにします。 「登録」 を選択します。 「証明書とシークレット」メニューを選択し、「新しいクライアントシークレット」を選択します。 「説明」 と 「有効期限」 を入力します。 このシークレットは、有効期限が切れる前に AWS 側で更新する必要があることに注意してください。 「追加」を選択します。 「値」をコピーして安全に保管してください。これは、パスワードやその他のアクセストークンに似た機密性の高い文字列です。 「概要」メニューから次のフィールドをコピーします。 アプリケーション (クライアント) ID ディレクトリ (テナント) ID 「アプリの登録」を作成したら、次のステップ 2 で Azure サブスクリプションからデータを読み取る権限を付与する必要があります。 代替方法: Azure CLI を使用してアプリ登録を作成する このコマンドは、単一テナントの「アプリの登録」を作成します。 az ad app create --display-name 'Amazon CloudWatch' \ --sign-in-audience 'AzureADMyOrg' 前のコマンドから返された ID を以下の引数に置き換えます。 az ad sp create --id 'ID' 引数の ID を、以下の引数の最初のコマンドの ID に置き換えます。 az ad app credential reset --id 'ID' 出力に表示されるパスワードは、Amazon CloudWatch の設定に使用されるため、書き留めておきます。 代替方法: Azure PowerShell を使用してアプリの登録を作成する このコマンドは、単一のテナントの「アプリの登録」を作成します。 New-AzADApplication -DisplayName "Amazon CloudWatch" -SignInAudience "AzureADMyOrg" 前のコマンドから返された App_ID を以下の引数で置き換えます。 New-AzADServicePrincipal -ApplicationId "App_ID" 最初のコマンドから返された ID を以下の引数に置き換えます。 New-AzADAppCredential -ObjectId "ID" | Format-List シークレット値は Amazon CloudWatch の設定に使用されるため、書き留めておきます。 ステップ 2. ポータルで Azure サブスクリプションにアクセス許可を付与する Microsoft Azure Portal にサインインし、グローバル検索ボックスで 「サブスクリプション」を検索します。 Amazon CloudWatch とインテグレーションしたいサブスクリプションを選択します。 メニューから「アクセス制御 (IAM)」を選択し、次に「追加」を選択し、「ロールの割り当ての追加」を選択します。 リストから「Monitoring Data Reader」を選択し、「次へ」を選択します。 「メンバーを選択する」を選択し、「アプリの登録」の名前を入力します。 名前を入力するまでリストに表示されない場合があることに注意してください。「アプリの登録」の名前を選択し、「選択」をクリックします。 最後に、「次へ」を選択し、「レビューと割り当て」を選択します。 これらの権限が適用されていることを確認するには、サブスクリプション内の他のリソース (仮想マシンなど) の IAM ページを確認してください。 代替方法: Azure CLI を使用して Azure サブスクリプションにアクセス許可を付与する 以下のコマンドの Subscription_ID をサブスクリプションに置き換え、app_ID を上記で使用した az コマンドの出力に置き換えます。 az role assignment create --role 'Monitoring Data Reader' \ --scope '/subscriptions/Subscription_ID' --assignee 'app_ID' 代替方法: Azure PowerShell を使用して Azure サブスクリプションにアクセス許可を付与する New-AzADServicePrincipal コマンドから返された ID を下の引数に置き換え、Subscription_ID をサブスクリプションに置き換えてください。 New-AzRoleAssignment -ObjectId "Id" -Scope "/subscriptions/Subscription_ID" -RoleDefinitionName "Monitoring Data Reader" ステップ 3: Azure からメトリクスデータを読み取るように CloudWatch を設定する まず、CloudWatch コンソールの左側のナビゲーションで「設定」を選択し、次に「メトリクスのデータソース」を選択します。 図 2. CloudWatch サービスの設定ページ 次に、「データソースを作成」、「Azure Monitor」、「次へ」 の順に選択します。 図 3. メトリクスデータソースのリストから Azure Monitor 選択 データソースに名前を付けます。この名前は、作成された CloudFormation スタックの名前として表示されることに注意してください。Directory (tenant) ID、Application (client) ID、およびシークレットデータを入力し、「データソースを作成」を選択します。 図 4. Azure アプリの認証情報を使用して新しいデータソースを構成する CloudFormation へのリンクを辿ることで、スタックの進行状況を確認できます。通常、このプロセスは 2 分以内に完了します。Prometheus や Amazon RDS などの他のメトリクスデータソースでは、オプションで VPC 内に Lambda 関数を作成できます。これにより、プロビジョニング時間が 1 ～ 2 分長くなる場合があります。この画面が表示されたら、インテグレーションは完了です。 図 5. CloudWatch の完成したインテグレーションページ ステップ 4. Azure 環境のデータを視覚化する CloudWatch を使用して Azure Monitor にメトリクスデータのクエリを実行できるようになりました。「CloudWatch メトリクスを開く」ボタンをクリックするか、左側のナビゲーションメニューで「すべてのメトリクス」を選択し、次に「マルチソースクエリ」を選択して、ドロップダウンでデータソース名を選択します。 図 6. マルチソースクエリのコンソールの図 サブスクリプション、リソースグループ、その他のフィールドを選択します。CloudWatch は、AWS アカウントと同様に Azure サブスクリプションを監視するようになりました。 図 7. CloudWatchを使用して Azure VM の CPU を視覚化 このインテグレーションがどのように機能するかについて一言 – Azure Monitor (CloudWatch の他のメトリクスデータソースタイプと同様) は CloudWatch に永続化されません。そのため、CloudWatch は Azure のデータにアクセスする際にオンデマンドで Azure にクエリを実行します。これは CloudWatch アラームにも当てはまります。CloudWatch アラームも同様に、アラーム評価ごとに十分なデータポイントをクエリして、アラート条件が満たされているかどうかを確認します。メトリクス Lambda に対応するロググループで、すべてのクエリの詳細を確認できます。 よくある問題のトラブルシューティング Lambda はメトリクスデータソースインテグレーションのクエリを実行するために使用され、ログは CloudWatch Logs に保存されます。ロググループは、設定のエラーを見つけるために利用できます。 最もよく見られるエラーと、解決方法に関する注意事項は次のとおりです。 エラーメッセージ： INFO Sending response: { Data: [], SubscriptionIds: [] } これは、Azure IAM が権限を適用しておらず、Lambda が Azure からのサブスクリプションを列挙できないことを示しています。正しいサブスクリプションでステップ 2 が完了していることを確認してください。 エラーメッセージ： INFO An error occurred: RestError: Commonly allowed time grains:... すべてのメトリクスデータソースのタイプがこの機能をサポートしているわけではありません。ストレージアカウントの使用状況メトリクスなど、Azure Monitor に集約される頻度が低いデータを表示しようとすると発生する場合があります。これは、あまり頻繁に入力されないメトリクスでは予想される動作です。詳細については、Azure Monitor API のドキュメントをご覧ください。 エラーメッセージ： INFO An error occurred: AuthenticationRequiredError: invalid_client ensure your credentials are correct これは通常、AWS Secrets Manager に間違った認証情報が保存されていることが原因です。テナント ID、アプリケーション ID、シークレット値が正しいことを再確認してください。CloudFormation スタックを再作成しなくても、これらの値を AWS Secrets Manager で直接変更できます。 インテグレーションを次のレベルへ ハイブリッドおよびマルチクラウドの監視およびオブザーバビリティソリューションは、クラウド運用を監視するための強力なメカニズムです。CloudWatch をソリューションの中心的なコンポーネントとして使用することで、これらの機能を自動化し、拡張機能を使用して付加価値を高めることができます。最も強力な方法の 1 つは、Azure 環境内のメトリクスデータに基づいてアラームを作成することです。CloudWatch アラームは、管理者へのページ送信、JIRA チケットの作成、サーバーの再起動、フェイルオーバーの開始など、あらゆる自動ワークフローをトリガーできます。 CloudWatch は 1 つ以上のクラウド環境で問題が発生したときにアラートを出す、複合アラームを作成できます。Azure と AWS の両方で動作するワークロードがあり、両方のプロバイダーにデプロイすると機能停止が発生することを考えてみましょう。クラウド環境全体の HTTP エラーの総数に基づく複合アラームを使用し、アクションをトリガーします。これらはすべて、Azure と AWS の両方で作成されたクラウドネイティブなメトリクスに基づいています。ユースケースによっては、環境ごとにアラームを分けるよりもこの方が適している場合があります。 コストと削除 CloudWatch で外部メトリクスデータソースを使用しても追加料金は発生しませんが、Lambda、Secrets Manager、CloudWatch Logs、および CloudWatch アラームの使用には標準料金がかかります。 Azure Monitor API からデータを取得する場合の料金の詳細については、Azure のドキュメントを参照してください。 ステップ 3 で作成した CloudFormation スタックを削除するだけで、インテグレーションを解除できます。これにより、Lambda 関数とシークレット情報が Secrets Manager から削除されます。 まとめ CloudWatch を使用してマルチクラウドのオブザーバビリティソリューションを作成すると、さまざまな環境のメトリクスを視覚化してアクションを実行できます。アラーム、ダッシュボード、 Metric Math などの CloudWatch の機能を使用すると、高度なクエリを作成して、サイロ化されたオペレーションデータを解放し、複数のクラウドプロバイダーを使用する際の複雑さに対処する時間を短縮できます。この機能を使用することで、AWS から外部のメトリクスデータにアクセスしてアクションを実行できるため、CloudWatch はメトリクスデータを運用するための中心的な役割を果たします。 著者について Rich McDonough Rich McDonough は、Amazon Web Services (AWS) のPrincipal Technologist です。IT業界で20年以上の経験を持つ彼は、ディレクター、アーキテクト、DevOpsの役職を歴任し、スタートアップの分野でスキルを磨きました。主なフォーカスエリアは、バックエンド開発、DevOps プラクティスの作成、デジタルネイティブビジネスのクラウド移行でした。現実世界のビジネス上の問題に対処し、AWS サービスの運用を加速させる拡張性、柔軟性、耐障害性に優れたクラウドアーキテクチャを構築できるようお客様をサポートしている同氏は、「オペレーションエクセレンスに理不尽なほど情熱を注いでいる」のです。Rich は、ワークショップの講師、講演、AWSの顧客のためのソリューション開発を楽しんでいます。 Aidan Keane Aidan Keane は AWS の Senior Specialist Solutions Architect で、Microsoft ワークロードを専門としています。彼はテクノロジー業界で25年間働いており、テクノロジーに情熱を注いでおり、顧客向けの新しい技術ソリューションの構築と探求を楽しんでいます。仕事以外では、ゴルフ、サイクリング、リバプールFCに情熱を注ぐ熱心なスポーツ愛好家です。彼は家族との充実した時間を楽しんでいるほか、アイルランドやペルーへ旅行しています。 Aviad Tamir Aviad Tamir は、金融サービス業界向けのソリューションを専門とする AWS の Senior Solutions Architect です。彼はテクノロジー業界で25年間にわたり、新興企業と大企業の両方で働いてきました。彼はオープンソースの哲学、知識の共有、より良いソフトウェアの構築が好きです。 翻訳はテクニカルアカウントマネージャーの日平が担当しました。原文は こちら です。

2023 年 11 月 30 日、 Amazon Route 53 Application Recovery Controller の新機能であるゾーンオートシフトを提供開始しました。これにより、AWS がある アベイラビリティーゾーン に影響する潜在的な障害を特定したときに、ワークロードのトラフィックをそのアベイラビリティーゾーンから自動的かつ安全にシフトし、障害が解決したら元のアベイラビリティーゾーンに戻すことができます。 耐障害性の高いアプリケーションのデプロイでは、通常、リソースをリージョンの複数のアベイラビリティーゾーンにデプロイします。アベイラビリティーゾーンとは、独立した電力、接続、ネットワーク機器、および氾濫原を確保するために、意味のある距離（通常100 km 以内）離れた物理データセンター群のことです。 デプロイの失敗、構成の誤り、オペレーターのミスなど、アプリケーションのエラーからユーザーを保護するために、2022年に 手動またはプログラムでゾーンシフトをトリガーする機能 を導入しました。これにより、あるアベイラビリティーゾーンでメトリクス値の低下を検出したときに、トラフィックをそのアベイラビリティーゾーンから遠ざけることができます。そのためには、すべての新しい接続を正常なアベイラビリティーゾーンのインフラストラクチャのみに転送するようにロードバランサーを設定します。これにより、障害の根本原因を調査する間、顧客はアプリケーションの利用を継続できます。障害が解消されたら、ゾーンシフトを停止して、トラフィックが再びすべてのゾーンに分散されるようにします。 ゾーンシフトは、 Application Load Balancer (ALB) または Network Load Balancer (NLB) の クロスゾーン負荷分散 がオフになっている場合に機能します。これは NLB のデフォルト設定です。ロードバランサーには 2 つのレベルの負荷分散があります。最初のレベルは DNS で設定されます。ロードバランサーはアベイラビリティーゾーンごとに 1 つ以上の IP アドレスを公開し、ゾーン間のクライアントサイドの負荷分散を実現します。トラフィックがアベイラビリティーゾーンに到達すると、ロードバランサーは登録された正常なターゲット、通常は Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにトラフィックを送信します。デフォルトでは、ALB はすべてのアベイラビリティーゾーンのターゲットにトラフィックを送信します。ゾーンシフトを正しく機能させるには、クロスゾーン負荷分散を無効にするようにロードバランサーを設定する必要があります。 ゾーンシフトが始まると、次の図に示すように、DNS は全てのトラフィックを一つのアベイラビリティーゾーンから遠ざけます。 手動によるゾーンシフトは、ユーザー側で発生したエラーからワークロードを保護するために役立ちます。しかし、アベイラビリティーゾーンで障害発生の可能性がある場合、時に障害の特定や検出が困難な場合もあります。アベイラビリティーゾーン単位でメトリクスを追跡することは多くないかもしれません。そのため、アプリケーションメトリクスを使用してアベイラビリティーゾーンの問題を検出することは困難です。さらに、サービスがアベイラビリティーゾーンの境界を越えて依存関係を呼び出すことも多くあります。その結果、すべてのアベイラビリティーゾーンでエラーが発生してしまいます。モダンマイクロサービスアーキテクチャでは、これらの検出と復旧の手順を数十または数百の個別のマイクロサービスで実行しなければならないことが多く、復旧に数時間かかってしまいます。 お客様から、アベイラビリティーゾーンで発生した可能性のある障害を特定する負担を軽減できないかとご要望を頂いてきました。確かに、AWS が内部のモニタリングツールを使用すれば、潜在的な問題についてお客様より先に検出できる可能性があります。 今回のリリースにより、アベイラビリティーゾーンで発生する可能性のある障害からワークロードを保護するようにゾーンのオートシフトを設定できるようになりました。AWS が、ネットワークトラフィックのシフトをいつトリガーするかを決定するために、独自の AWS 内部モニタリングツールとメトリクスを利用します。シフトは自動的に開始され、API を呼び出す必要はありません。ゾーンに電源障害やネットワーク障害などの潜在的な障害が発生していることが検出されると、インフラストラクチャの NLB または ALB トラフィックのオートシフトが自動的にトリガーされ、障害が解決された時点でトラフィックを元に戻します。 言うまでもなく、トラフィックを一つのアベイラビリティーゾーンから遠ざけることはデリケートなオペレーションであり、慎重に準備する必要があります。アプリケーションの可用性を誤って低下させないように、一連の保護手段を構築しました。 まず、トラフィックを一度に複数のアベイラビリティーゾーンから移動させないようにするために、当社には内部制御があります。次に、毎週 30 分間、インフラストラクチャの移行を練習します。お客様は練習実行をブロックする時間帯を定義できます。例えば、月曜日から金曜日の 08:00～18:00 のように定義します。3 つ目は、練習実行中の サーキットブレイカー として機能する 2 つの Amazon CloudWatch アラームを定義できます。1 つは練習実行をまったく開始しないようにするアラーム、もう 1 つは練習実行中のアプリケーションの正常性を監視するアラームです。練習中にどちらかのアラームがトリガーされると、練習を停止し、すべてのアベイラビリティーゾーンへのトラフィックを復元します。練習終了時のアプリケーション正常性をチェックするアラームの状態は、実行の結果 (成功または失敗) を示します。 責任共有モデル により、お客様も 2つの責任を担います。 第一に、お客様はすべてのアベイラビリティーゾーンに十分な容量がデプロイされていることを確認して、トラフィックが移動した後に残りのアベイラビリティーゾーンのトラフィックが増加しても対応できるようにする必要があります。残りのアベイラビリティーゾーンには常に十分な容量を確保し、アプリケーションの復旧を遅らせたり可用性に影響を与えたりする可能性のあるスケーリングメカニズムに依存しないことを強くお勧めします。ゾーンオートシフトがトリガーされると、 AWS Auto Scaling はリソースをスケーリングするのに通常よりも時間がかかる場合があります。リソースを事前にスケーリングすることで、最も要求の厳しいアプリケーションの復旧時間を予測できます。 通常のユーザートラフィックを吸収するために、アプリケーションが 3 つのアベイラビリティーゾーンに 6 つの EC2 インスタンス (2×3 インスタンス) を必要とするとします。ゾーンオートシフトを設定する前に、1 つのアベイラビリティーゾーンが利用できない場合にトラフィックを吸収するのに十分な容量が残りのアベイラビリティーゾーンにあることを確認する必要があります。この例では、アベイラビリティーゾーンごとに 3 つのインスタンスがあることを意味します (トラフィックが 2 つのアベイラビリティーゾーンに移動されたときに 2×3 = 6 つのインスタンスを維持して負荷分散する必要があるため、3 つのアベイラビリティーゾーンに 3×3 = 9 つのインスタンスが必要) 。 実際には、高い信頼性が求められるサービスを運用する場合、顧客を起点とする負荷の急上昇やまれにあるホスト障害などの不測の事態に備えて、ある程度の冗長容量をオンラインで運用するのが一般的です。この方法で既存の冗長性を満たすことで、アベイラビリティーゾーンの問題が発生したときに迅速に復旧できるだけでなく、他のイベントに対する堅牢性も高まります。 第二に、お客様は選択したリソースのゾーンオートシフトを明示的に有効にする必要があります。AWS は、選択したリソースにのみゾーンオートシフトを適用します。ゾーンオートシフトの適用は、アプリケーションに割り当てられる合計容量に影響します。先ほど説明したように、残りのアベイラビリティーゾーンに十分な容量をデプロイして、アプリケーションを準備する必要があります。 もちろん、この追加容量をすべてのアベイラビリティーゾーンにデプロイすることにはコストがかかります。当社がレジリエンスについて話すとき、アプリケーションの可用性とコストのどちらを決めるかというビジネス上のトレードオフがあることを説明します。これが、選択したリソースにのみゾーンオートシフトを適用するもう 1 つの理由です。 ゾーンオートシフトの設定方法を確認しましょう ゾーンオートシフトの設定方法を示すために、よく知られている TicTacToe Web アプリケーション を CDK スクリプト を使ってデプロイします。クロスゾーン負荷分散を無効化するための CDK スクリプトのカスタマイズ方法は本記事の最後に記載しています。デプロイ後、 AWS マネジメントコンソール の Route 53 Application Recovery Controller ページを開きます。左側のペインで、 「ゾーンオートシフト」 を選択します。次に、ウェルカムページで、 「ゾーンオートシフトを設定」 を選択します。 デモアプリケーションのロードバランサーを選択します。現在、クロスゾーン負荷分散が無効になっているロードバランサーのみがゾーンオートシフトの対象であるということに注意してください。コンソールの警告からもわかるように、アベイラビリティーゾーンが 1 つ失われても動作を継続するのに十分な容量がアプリケーションにあることも確認します。 ページを下にスクロールして、AWS に 30 分間の練習を実行させたくない時間と曜日を設定します。最初は、オートシフトに慣れるまで、月曜日から金曜日の 08:00〜18:00 は練習をブロックします。時間はUTCで表され、 サマータイム によって変化しないことに注意してください。 UTC Converter を使用すると便利です。最初は営業時間を外して問題ありませんが、アプリケーションのトラフィックが少ない時や全くない場合に観測できないかもしれない問題を確実にキャプチャできるように、営業時間中にも練習を実行する設定をお勧めします。おそらく、ピーク時に影響を与えずにゾーンオートシフトを実行することが最も要求されることかもしれませんが、テストしたことがないことに、どの程度自信を持てるでしょうか。 常時ブロックしないのが理想ですが、それが常に現実的であるとは限らないことを我々は認識しています。 同じページのさらに下にある 2 つのサーキットブレーカーアラームを入力します。最初のものは練習の開始を防ぎます。このアラームを使って、今は練習を始めるのに良いタイミングではないと示します。例えば、アプリケーションで現在問題が発生している場合や、アプリケーションの新しいバージョンを本番環境にデプロイする場合などです。2 番目の CloudWatch アラームは、練習実行の結果を示します。これにより、ゾーンオートシフトにより、アプリケーションが練習実行にどのように反応しているかを判断できます。アラームが緑色のままであれば、すべてがうまくいったことがわかります。 練習中にこれら 2 つのアラームのいずれかがトリガーされると、ゾーンオートシフトは練習を停止し、すべてのアベイラビリティーゾーンへのトラフィックを復元します。 最後に、30 分間の練習が毎週実行され、アプリケーションの可用性が低下する場合があることに同意します。 そして、 「作成」 を選択します。 設定は以上です。 数日後、コンソールの 「リソースのゾーンシフト履歴」 タブに練習実行の履歴が表示されます。2 つのサーキットブレーカーアラームの履歴をモニタリングして、すべてが正しくモニタリングされ、設定されていることを確認しています。 オートシフト自体をテストすることはできません。アベイラビリティーゾーンで潜在的な問題を検出すると、自動的にトリガーされます。この記事で共有した手順をテストするためにアベイラビリティーゾーンをシャットダウンできるかどうかサービスチームに尋ねたところ、丁寧に断られました。 オートシフトと同じように動作する手動シフトをトリガーすれば、設定のテストができます。 さらに知っておくべきこと ゾーンオートシフトは、現在中国と GovCloud を除くすべての AWS リージョンで追加料金なしで利用できます。 crawl, walk, run方式の適用をお勧めします。まず、手動のゾーンシフトから始め、アプリケーションに対する信頼性を確立します。次に、営業時間外に練習実行を設定したゾーンオートシフトを有効にします。最後に、営業時間中のゾーンオートシフトの練習を含めるようにスケジュールを変更します。イベントに対するアプリケーションの応答を、イベントを発生させたくないときにテストする必要があります。 また、トラフィックを 1 つのアベイラビリティーゾーンから別のアベイラビリティーゾーンに戻したときに、アプリケーションのすべての部分がどのように復旧するかを総合的に考えることをお勧めします。私が思いつくリスト (完全なものではありませんが) は次のようなものです。 まず、既に説明したように、容量増加の計画を立てます。次に、各アベイラビリティーゾーンで発生する可能性のある単一障害点について考えてみましょう。例えば、単一の EC2 インスタンスで実行されるセルフマネージドなデータベースや、1 つのアベイラビリティーゾーンに存在するマイクロサービスなどです。ゾーンシフトを必要とするアプリケーションには、 Amazon DynamoDB や Amazon Aurora などのマネージドデータベースを使用することを強くお勧めします。これらには、レプリケーションとフェイルオーバーのメカニズムが組み込まれています。3 番目に、アベイラビリティーゾーンが再び利用可能になったときに切り替える計画を立ててください。リソースのスケーリングにはどの程度の時間が必要ですか? キャッシュをrehydrateする必要がありますか? 回復力のあるアーキテクチャと方法論について詳しくは、同僚 Adrian が執筆した この素晴らしいシリーズ記事 をご覧ください。 最後に、現在ゾーンオートシフトの対象となるのは、クロスゾーン負荷分散が無効になっているロードバランサーのみであることに注意してください。CDK スクリプトからクロスゾーン負荷分散を無効にするには、 StickinessCookieDuration を削除し、ターゲットグループに load_balancing.cross_zone.enabled=false を追加する必要があります。 CDK と Typescript を使った例を以下に示します。 // Add the auto scaling group as a load balancing // target to the listener. const targetGroup = listener.addTargets('MyApplicationFleet', { port: 8080, // for zonal shift, stickiness &amp; cross-zones load balancing must be disabled // stickinessCookieDuration: Duration.hours(1), targets: [asg] }); // disable cross zone load balancing targetGroup.setAttribute("load_balancing.cross_zone.enabled", "false"); さあ、次はあなたがゾーンオートシフトのメリットが得られるアプリケーションを選んでみましょう。まず、各アベイラビリティーゾーンのインフラストラクチャ容量を確認してから、サーキットブレーカーアラームを定義します。モニタリングが正しく設定されていることを確認したら、 ゾーンオートシフトを有効 にします。 原文は こちら です。翻訳はソリューションアーキテクトの新谷 歩生が担当しました。

このブログは 2020 年 9 月 21 日に Cher Simon (プリンシパルパートナーソリューションアーキテクト) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 多くの組織は、単一の AWS アカウントでクラウドジャーニーを開始し、規制、コンプライアンス、セキュリティ、またはコスト追跡の目的で、徐々に マルチアカウント環境 にクラウド活用を拡大していきます。組織はしばしば、高可用性、スケーラビリティ、パフォーマンスのために、 AWS グローバルインフラストラクチャー の複数のリージョンにワークロードとアプリケーションをデプロイすることを選択します。マルチアカウントかつマルチリージョン環境で構築および運用するには、グローバルな災害復旧 (DR) およびビジネス継続性戦略が必要です。お客様は、オーバーヘッドを削減し、バックアップのコンプライアンスを改善するために、組織の AWS アカウント全体のクロスリージョンバックアップタスクを統合および自動化する集中化されたバックアップ管理プロセスを求めています。 AWS Backup は、 Amazon EBS 、 Amazon EC2 、 Amazon RDS 、 Amazon Aurora 、 Amazon DynamoDB 、 Amazon EFS 、 AWS Storage Gateway など、AWS サービス全体のデータバックアップを簡素化および自動化する、フルマネージドでコスト効果の高いバックアップサービスです。さらに、AWS Backup は AWS Organizations と連携して、マルチアカウント環境におけるリソースのバックアップポリシーをひとつに集約したビューとして提供します。お客様は、リソースにタグ付けをするだけで AWS Backup が管理するクロスリージョンコピーのバックアップポリシーにそのリソースを関連付けることができます。この記事では、AWS Backup でバックアップポリシーをデプロイすることにより、組織の AWS アカウント全体のバックアップタスクを集中的に管理する方法をご紹介します。 前提条件 はじめに、管理アカウントで組織単位 (OU) を作成し、次の図に示すような組織階層に 3 つのメンバーアカウント (Prod アカウント、QA アカウント、Dev アカウント) を配置します。 ルート OU には Prod OU と Non-Prod OU の 2 つの OU が含まれています。 Prod アカウント を Prod OU に配置します。 Non-Prod OU の中に QA OU と Dev OU を作成します。 QA アカウント を QA OU に配置します。 Dev アカウント を Dev OU に配置します。 この チュートリアル のステップ 1 とステップ 2 に従って、同じ組織階層とアカウント構造を作成できます。次に、この ガイド に従って、AWS Organizations のすべての機能を有効にします。これで AWS Backup は、AWS Organizations で構成した組織の AWS アカウント全体のバックアップと復元の操作を管理およびモニタリングできます。 Prod アカウントで以下のリソースを作成し、 backup をキー、 prod を値としてタグ付けをします。 米国東部 (バージニア北部) リージョンに 1 つの Amazon RDS PostgreSQL データベース 欧州 (アイルランド) リージョンに 1 つの Amazon EFS ファイルシステム QA アカウントと Dev アカウントで以下のリソースを作成し、 backup をキー、 nonprod を値としてタグ付けをします。 米国東部 (バージニア北部) と欧州 (アイルランド) リージョンにそれぞれ 1 つの Amazon EC2 インスタンス。既存のリソースを使用することもできます。 のちほど、これらのリソースを米国東部 (バージニア北部) と欧州 (アイルランド) からアジアパシフィック (東京) に自動的にクロスリージョンコピーするため、管理アカウントでバックアップポリシーを作成します。 注意: AWS Backup がサポートするクロスリージョンコピーの対象サービスは こちら をご確認下さい。 ソリューションの概要 次の図は、この記事で説明するマルチアカウントバックアップアーキテクチャのアウトラインを示しています。 Prod OU 用に 1 つ目のバックアップポリシーと、 Non-Prod OU 用に 2 つ目のバックアップポリシーを作成します。次に、メンバーアカウントでの IAM ロールとバックアップボールトのプロビジョニングを自動化するため、 AWS CloudFormation StackSets をデプロイします。 組織の AWS アカウント全体のリソースを保護し、データのバックアップを他のリージョンにレプリケートするには、次の手順に従います。 クロスアカウント管理のオプトイン IAM ロールの作成 バックアップボールトの作成 バックアップポリシーの作成 バックアップポリシーのターゲットへのアタッチ AWS アカウント全体のバックアップと復元のアクティビティモニタリング ステップ 1: クロスアカウント管理のオプトイン 管理アカウントにログインし、 AWS Backup コンソール に移動し、左側のナビゲーションペインで 設定 を選択します。 バックアップポリシー と クロスアカウントモニタリング の両方で オンにする をクリックします。ステータスが オン になっていることを確認します。 AWS Backup がサポートする全てのリソースタイプを有効化します。 ステップ 2: IAM ロールの作成 AWS Backup がバックアップおよび復元の操作を実行できるように AWS Identity and Access Management (IAM) でサービスロールを設定します。メンバーアカウントに IAM ロールをデプロイするには、次の手順を実行します。 管理アカウントで AWS CloudFormation コンソール に移動し、ナビゲーションペインから StackSets を選択します。 StackSets ページの上部で StackSet の作成 を選択します。 Amazon S3 URL に https://awsstorageblogresources.s3.us-west-2.amazonaws.com/chersimoncrossregioncopyblog/IAMStackSet.yaml を貼り付けます。 StackSet の名前 を指定します。 IAM Configuration で crossaccountbackuprole と入力します。 次へ を選択します。 StackSet オプションの設定画面は何も変更せず、 次へ を選択します。 リージョンの指定 で 米国東部 (バージニア北部) を選択します。その他のデフォルト設定はそのままにします。 次へ を選択します。 AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。 にチェックし、 送信 を選択します。 スタックインスタンス タブで StackSet のデプロイ進捗を確認し、次のスクリーンショットのように全てのスタックインスタンスのステータスが SUCCEEDED になるのを待ちます。 注意: AWS Backup は、メンバーアカウントにロールが存在するか、ロールを引き受けることができるかどうかを検証しません。今回のケースでは crossaccountbackuprole が、バックアップポリシーに追加する各アカウントで適切かどうか確認することをお勧めします。 ステップ 3: バックアップボールトの作成 AWS Backup のリカバリーポイントは、バックアップボールトに保存されている特定の時点におけるリソースのバックアップコンテンツを指します。次の手順を完了して、AWS Backup で保護する各アカウントのソースリージョンと宛先リージョンの両方に個別のバックアップボールトを作成します。 管理アカウントにログインしたままで AWS CloudFormation コンソール に移動し、ナビゲーションペインから StackSets を選択します。 StackSets ページの上部で StackSet の作成 を選択します。 Amazon S3 URL に https://awsstorageblogresources.s3.us-west-2.amazonaws.com/chersimoncrossregioncopyblog/BackupVaultStackSet.yaml を貼り付けます。 StackSet の名前 を指定します。 AWS Backup Configuration で prodbackupvault と入力します。 次へ を選択します。 StackSet オプションの設定画面は何も変更せず、 次へ を選択します。 組織単位 (OU) にデプロイ を選択します。 AWS OU ID に、 Prod OU の OU ID を入力します。OU ID は AWS Organizations コンソール のナビゲーションペインから AWS アカウント を選択し、 Prod OU の OU ID を取得します。 リージョンの指定 で 米国東部 (バージニア北部) 、 アジアパシフィック (東京) 、 欧州 (アイルランド) を選択します。その他のデフォルト設定はそのままにします。 次へ を選択します。 送信 を選択します。 Non-Prod OU でこの 7 ステップを繰り返してください。 ステップ 4 の AWS Backup Configuration は nonprodbackupvault に置き換えてください。 ステップ 6 の AWS OU ID を Non-Prod OU の OU ID に置き換えてください。 注意: バックアップボールト名は大文字小文字を区別し、AWS Backup は目的のバックアップボールトが存在するかどうかを検証しません。保護したい各メンバーアカウントとリージョンに適切なバックアップボールトが作成されていることを必ず確認してください。 ステップ 4: バックアップポリシーの作成 Prod-OU 用のバックアップポリシーを作成するには、次の手順に従ってください。 管理アカウントで AWS Backup コンソール に移動し、 バックアップポリシー を選択して バックアップポリシーを作成 を選択します。 ポリシーの作成 セクションで、次の操作を行います。 ポリシー名 に prodbackuppolicy と入力します。 ポリシーの説明を入力します。 バックアッププランを設定 セクションの バックアッププランの詳細 で、次のように指定します。 バックアッププラン名 に prodbackupplan と入力します。 バックアッププランのリージョン で、 米国東部 (バージニア北部) 、 欧州 (アイルランド) 、 アジアパシフィック (東京) を選択します。 バックアップルールを追加 セクションの バックアップルール名 に prodbackuprule と入力します。 バックアップボールト に prodbackupvault と入力します。(※下記のスクリーンショットとはレイアウトが変わっている可能性があります。) バックアップ頻度 で 毎日 を選択します。 バックアップウィンドウ で バックアップウィンドウのデフォルトを使用 – おすすめ を選択します。この選択でバックアップジョブは午前 5 時 (UTC) から 8 時間以内に開始されます。 コールドストレージへの移行 で 月 を選択し、 3 と入力します。 保持期間 で 月 を選択し、 6 と入力します。 注意: コールドストレージが利用できるサービスの最新情報は こちら をご参照ください。対象外のリソースがコールドストレージ移行に追加された場合、その移行は無視されます。このチュートリアルにおいては、Amazon RDS がコールドストレージ移行の対象外です。 コピーを生成-オプション で、 コピー先にコピー-オプション に アジアパシフィック (東京) を選択します。 送信先バックアップボールト に prodbackupvault と入力します。 詳細設定 を展開し、 コールドストレージへの移行 で 月 を選択し、 3 と入力します。 保持期間 で 月 を選択し、 6 と入力します。 リソースを割り当てる セクションで、次のように指定します。 リソース割り当て名 に prodresources と入力し、 IAM ロール に crossaccountbackuprole と入力します。 リソースタグキー に backup 、 タグ値 に prod と入力します。 ポリシーの作成 を選択します。 Non-Prod OU 用のバックアップポリシーを作成するために、これらの 4 つのステップを繰り返します。 ステップ 2a の ポリシー名 は nonprodbackuppolicy に置き換えます。 ステップ 3a の バックアッププラン名 は nonprodbackupplan に置き換えます。 ステップ 3c の バックアップルール名 は nonprodbackuprule に置き換えます。 ステップ 3d の バックアップボールト は nonprodbackupvault に置き換えます。 ステップ 3i の 送信先バックアップボールト は nonprodbackupvault に置き換えます。 ステップ 4a の リソース割り当て名 は nonprodresources に置き換えます。 ステップ 4b の タグ値 は nonprod に置き換えます。 ステップ 5: バックアップポリシーのターゲットへのアタッチ これで、バックアップポリシーをターゲットである個々のアカウントまたは OU にアタッチする準備が整いました。OU にバックアップポリシーを適用すると、選択した OU のメンバーアカウント全体のリソースが保護されます。 管理アカウントで AWS Backup コンソール に移動し、 バックアップポリシー から prodbackuppolicy を選択します。 ターゲット セクションで アタッチ を選択し、 Prod OU を選択します。 アタッチ を選択します。 同様に nonprodbackuppolicy を選択し、 Non-Prod OU を選択します。 ステップ 6: AWS アカウント全体のバックアップと復元のアクティビティモニタリング 管理アカウントの AWS Backup コンソール の クロスアカウントモニタリング で、組織の AWS アカウント全体のバックアップ、コピー、復元ジョブをモニタリングできます。 AWS Backup コンソールで バックアップを復元 するには、メンバーアカウントの AWS Backup コンソールの 保護されたリソース を選択し、リストから リソース ID を選択します。復元する復旧ポイントを選択し、 復元 を選択します。プロンプトに従ってパラメータを指定します。 バックアップを復元 を選択します。 おめでとうございます！AWS のマルチアカウント環境全体でバックアップタスクとクロスリージョンコピーを集中管理するための AWS Backup の構成が完了しました。 クリーンアップ 今後の課金を避けるために、次の手順でサンプルリソースを削除してください。 バックアップポリシーからターゲット OU を削除します。 この ガイド に従って、バックアップポリシー、バックアッププラン、リカバリポイントを削除します。 AWS CloudFormation コンソールで スタックセットからのスタックインスタンスの削除 をし、次に スタックセットの削除 をすることで、IAM ロールとバックアップボールトを削除します。 まとめ この記事では、AWS Backup を使用してクロスアカウント管理を集中化し、クロスリージョンコピーのバックアップポリシーをデプロイする方法を示しました。また、既存および新しい AWS アカウント全体に必要な IAM ロールとバックアップボールトを自動化するためのサンプル CloudFormation StackSets も提供しました。 これで、管理オーバーヘッドを最小限に抑えながら、DR プランにこのプロセスを組み込み、AWS 環境全体でビジネス継続性戦略を簡素化できるようになりました。 &nbsp; この記事を読んでいただきありがとうございました。 翻訳はソリューションアーキテクトの松本が担当しました。 <!-- '"` --> Cher Simon Cher Simon は AWS で機械学習とデータ分析に特化したプリンシパルパートナーソリューションアーキテクトです。Cher は、エンタープライズ規模、データドリブン、AI を駆使したインダストリーソリューションのアーキテクトとして 20 年の経験があります。日々のお客様との業務においてクラウドネイティブなソリューションの構築を行う一方で、Cher は著者でもあり、AWS カンファレンスでも頻繁にスピーカーを勤めています。

会話型アプリケーションの開発には、認証ワークフロー、API インターフェース、データ管理、ビジネスロジックを実現するインテントなど、複数の複雑なコンポーネントが含まれます。これらの要素を適切に統合し、セットアップすることは、特に会話型アプリケーションを構築するのが初めての開発者や、AWS サービスでの豊富な経験がない開発者にとっては、難易度が髙いです。 この記事では、 AWS Amplify のパワーの活用と Amazon Lex のシームレスな統合によって会話型アプリケーションを構築する方法を紹介します。この記事では、認証ワークフロー、API インターフェース、データ管理、ビジネスロジックを実現するインテントなどの重要なバックエンドコンポーネントの確立に焦点を当て、会話型アプリケーションをシームレスに構築するための実用的なソリューションを提供します。 ソリューションの概要 このソリューションは、ユーザーが自然言語のクエリや発話を使用して AWS のサービスと対話できるようにする高度な仮想アシスタントアプリケーションのデモを行います。この仮想アシスタントは自然言語理解（NLU）のために Lex を利用し、強力な会話 AI として振る舞います。 仮想アシスタントに簡単なクエリを送信することで、AWS アカウント内のタスクを自動化することができます。Amplify の幅広いツールとサービスのセットを使用することで、仮想アシスタントのコア機能に集中しながら、簡単に堅牢なフルスタックの Web アプリケーションを作成することができます。 図1: アプリケーションアーキテクチャ このソリューションは、以下のコンポーネントで構成されています（図1）： React フレームワーク ： React のコンポーネントベースのアーキテクチャは、UI 要素の作成を簡素化し、開発者が仮想アシスタントのインターフェースのために再利用可能でモジュール化されたコンポーネントを構築することを可能にします。状態を管理する機能により、アシスタントとのインタラクション中にシームレスなユーザー体験を保証します。 Amplify ： Amplifyは、開発プロセスを効率化する一連のツールとサービスを提供し、開発者が認証や API といった AWS の必須サービスにフロントエンドを迅速につなぎこめるようにします。これにより、ユーザー管理やデータアクセス制御などの機能の実装が簡素化されます。 AWS AppSync ： AWS AppSync は GraphQL API 開発を簡素化し、バックエンドに問い合わせるための単一のエンドポイントを提供します。これにより、仮想アシスタントはバックエンドのサービスとセキュアにやり取りを行うことができ、会話の管理や、ユーザーのセッションデータと応答を効率的に取得することができます。 Amazon DynamoDB : DynamoDB は、仮想アシスタントのバックエンドにスケーラブルで柔軟なデータストレージソリューションを提供します。DynamoDB は、効率的なデータ検索と永続化を可能にし、ユーザーとのやり取りを後で使用するために確実に保存し、シームレスな会話履歴の実装を容易にします。 Amazon Lex ： Lex を使用すると、開発者は、インテント、スロット、およびサンプル発話を定義することによって、カスタム会話インターフェースを作成することができます。これにより、仮想アシスタントはユーザーのクエリを理解し、それを特定のインテントにマッピングすることができ、ユーザーのリクエストに応え、AWS のタスクを自動化することができるようになります。 AWS Lambda ： AWS Lambda は、Lex によって検出されたユーザークエリに基づいてアクションを実行し、インテントを充足させるロジックを処理します。ユーザーのリクエストに応じてバックエンドロジックをスケーラブルに実行できます。仮想アシスタントがユーザーに代わって様々な AWS サービスとやりとりし、AWS のオペレーションを効率的に自動化することができます。 オープンソースのコードとデプロイ手順はこの GitHub リポジトリ にあります。このソリューションでは、以下のような簡単なクエリ/発話を送信することで、AWS アカウントの様々なワークフローや操作を自動化することができます。 t3 microで 2 台の Red Hat インスタンスを起動 すべての Red Hat インスタンスを検索 パブリックサブネットにデプロイされたインスタンスの有無の確認 ワイドオープンなセキュリティグループルールの有無の確認 10.11.12.13 からのトラフィックを許可するようにセキュリティグループのルールの変更 S3 バケットのリストアップ バケット XYZ で “ppt ” の検索 自然言語を使用することは、様々な AWS のサービスを操作する必要がある非技術者の AWS ユーザーが AWS を簡単に利用できるようにします。彼らは、コマンドラインインタフェース（CLI）ツールやソフトウェア開発キット（SDK）の専門的な知識に精通していない可能性があります。 さらに重要な点として、このアプリケーションはアシスタントを搭載した色々な種類の Web アプリケーションを Amplify を活用して構築するためのガイドとしても使用することができます。 図2：ユーザーがアシスタントにクエリを送信しているアプリケーションのスクリーンショット ソリューションのコンポーネント このソリューションは、AWS サービスと相互に作用する強力なバーチャル・アシスタントを形成するいくつかの主要コンポーネントで構成されている。以下はコンポーネントとその利点です。 フロントエンド フロントエンドはインタラクティブな会話型ウェブアプリケーションの重要なコンポーネントです。私たちは create-react-app Node パッケージを使用してプロジェクトの構造をセットアップし、最新の JavaScript で開発環境を準備します。メインの App コンポーネントは App.js に含まれており、関連する React コンポーネントをインポートし、Amplify バックエンドを設定します。App コンポーネントは基本的な React ルーターで構成され、他の React コンポーネントへの主要なルートがいくつかあります： Conversations コンポーネント ： このコンポーネントは、現在のユーザーとアシスタントの会話を一覧表示し、ユーザーが新しい会話を作成したり、既存の会話を削除したりできるようにします。Material UI カードが各会話を表し、会話の説明といくつかのアクションボタンを含んでいます。 Interact コンポーネント ： このコンポーネントは、特定のユーザーの会話をハイライトし、ユーザーが会話の履歴を表示したり、アシスタントに新しいクエリ/発話を送信することを可能にします。また、このコンポーネントは、テキスト、アラート、表、またはその他の形式のものを、アシスタントから受信して表示します（図2）。 バックエンド – 認証 Amplify を使用して Amazon Cognito ユーザープールを作成します。ユーザープールはフルマネージドなユーザーディレクトリとして機能し、ユーザー登録、認証、アカウントの回復、およびその他の操作をすぐに処理します。アプリケーションに認証を追加するには、“amplify add auth” コマンドを使用し、App コンポーネントのエクスポートを “withAuthenticator” コンポーネントでラップするだけです。詳しくは こちら を参照してください。 バックエンド – GraphQL API AppSync と DynamoDB による GraphQL API は、アプリケーションのフロントエンドとバックエンド間の効率的なデータ管理とコミュニケーションを可能にします。また、ユーザーは以前の会話を再開したり、アシスタントから返された以前の回答/データを取得したりできるようにする必要があります。これらの機能を実現するために、Amplify を使用して DynamoDB テーブルでバックアップされた AppSync GraphQL API を作成します。必要なのは、“amplify add api” コマンドを実行し、GraphQL スキーマを定義することだけです。デプロイされると、Amplify は自動的にスキーマを完全に機能する GraphQL API に変換します。 図3：GraphQL APIスキーマ GraphQL スキーマ – モデル API はユーザーの会話データ（ユーザーによって開始された会話とその属性）、および発話データ（ユーザーによって送信された実際のクエリ、またはアシスタントによって生成された応答）を永続化するので、2つのモデルタイプでアプリケーションをモデル化できます： 会話タイプと発話タイプです。Amplify はそれぞれのモデルタイプを独自の DynamoDB テーブルにマッピングします。以下の GraphQL スキーマは、@model ディレクティブを使用してこれら2つのモデルタイプを定義する方法を示しています（図3）。 GraphQL スキーマ – 属性とリレーションシップ スキーマでは、モデルタイプごとに他の属性に加えて主キーを定義することもできます。両方のモデルタイプの主キーは、自動的に生成される「id」フィールドで構成されます。会話モデルの追加属性の例としては、会話の名前と説明、会話を作成したユーザー、createdAt のタイムスタンプなどがあります（図3）。会話は多くの発言から構成されるため、スキーマでこの関係をモデル化する方法が必要です。そのために、@hasMany ディレクティブを使用して、Conversation モデルと Utterance モデルの間に一方向の1対多のリレーションシップを作成します（図3）。このリレーションシップを使用すると、会話データを API に問い合わせることができ、オプションで会話に含まれる発話のリストを含めることができます。 GraphQL スキーマ – アクセスパターン API が重要なアプリケーションのアクセスパターンに対応できていることを確認する必要があります。例えば、前述の “Conversations” React コンポーネントでは、そのユーザーに固有の会話のリストを表示する必要があります。これを行うには、@index ディレクティブを使用して、Conversation モデルの “user” 属性にセカンダリインデックスを設定します（図3）。 GraphQL スキーマ – 認証ルール ユーザーデータを保護し、ユーザーごとのデータアクセスを許可するために、認可レイヤーを追加する必要があります。このアプリケーションのデータの機密性を考慮すると、DynamoDB のテーブルレコード（上記で定義したいずれかのモデル）には、それぞれの所有者のみがアクセスできるようにする必要があります。そのために、スキーマで定義された各モデルに対して@auth ディレクティブを使用し、認可ストラテジーとして “allow:owner” を指定します（図3）。この認可戦略は、サインインした各ユーザー（オーナーとも呼ばれる）が、自分自身の会話や発話のみを作成/読み取り/更新/削除できることを意味します。裏側では、Amplify は先に作成された Cognito ユーザープールを活用して、レコード作成時のレコード所有者の身元を含む所有者フィールドを保存します。このオーナーフィールドは、アクセスを承認する前にユーザーの JWT トークンのクレームと照合されます。 アプリケーションバックエンド: Amazon Lex bot Lexを使って、ユーザーのリクエストに関連するインテントを識別できるボットを作成します。まず、希望するインテントとスロットのリストを作成していきます。各インテントに対して、ボットがインテントを認識できるように訓練するための発話例のリストを提供します。以下は、このボットの一部として定義されたいくつかのインテント例です。完全なリストは GitHub のリポジトリ を参照してください。 EC2-list ：異なるタイプのユーザーフィルター（タイプ、ami、サブネットタイプ）に基づいてインスタンスの一覧表示 EC2-create ：異なる設定（count、type、ami）に基づいてインスタンスを作成 S3-search ：バケットまたは複数のバケットから特定のパターンに一致するオブジェクトを検索 S3-copy-to-bucket : 検索結果から特定したオブジェクトを新しいバケットにコピー Sg-rule-list : 制限されていないセキュリティグループのルールをリストアップ ユーザーのインテントが正常に検出されると、ボットはカスタム Lambda 関数を利用してインテント処理を実行する。この Lambda 関数は、ユーザーのクエリを処理するビジネスロジックが含まれているアプリケーションのバックエンドとして機能する。 例えば、ユーザーが「 Find all Red Hat instances 」というクエリを送信すると、Lex ボットは「 EC2-list 」というインテントを識別し、Lambda 関数を呼び出します。Lambda 関数内では、カスタムロジックが実行され、ユーザーが提供した条件に一致する Amazon Elastic Compute Cloud （Amazon EC2）インスタンスのリストを特定して返します。Lambda 関数の柔軟性を活かし、必要に応じて特定のカスタムインテントを満たすようにコードをカスタマイズすることもできます。 アプリケーションのホスティング アプリケーションをホストするには、 AWS Amplify Hosting を使用することをお勧めします。AWS Amplify Hosting は、フルスタックの CI/CD ワークフローをすぐに利用できます。これにより、コードのコミットに応じてフロントエンドとバックエンドの変更を単一のワークフローで継続的にデプロイすることができます。これを行うには、まず Amplify コンソールから git ブランチに接続する必要があります。あるいは、プロジェクトのバックエンドとフロントエンドの両方をビルドして公開する amplify publish コマンドを使って、手動デプロイでアプリケーションをホストすることもできます。 アプリケーションのビルドとデプロイ GitHub リポジトリ には、前提条件のリスト、詳細なデプロイ手順、使用コマンド例、クリーンアップ手順が掲載されています。 まとめ この記事では、Lex チャットボット、リクエスト処理用の Lambda、データ管理用の GraphQL API 、認証用の Cognito を備えた、アシスタント機能付きの Web アプリケーションをに Amplify を使用して構築する方法を記載しました。具体的には、ユーザが自然言語を使用して AWS と対話し、AWS の操作/設定を自動化することを可能にする “Cloud Assistant” アプリケーションを構築しました。この特定のアプリケーションは、新規 AWS ユーザーの学習曲線をフラットにしてくれますが、それは同時に、一般的なアシスタントを搭載した Web アプリケーションを構築することの有用性と価値も示しています。 Amplify を使ったフルスタックのウェブとモバイルアプリケーションの作成と、それが提供する様々なツールと機能の詳細については、 AWS Amplify をご覧ください。 この記事は、 Build a Conversational AI app to Interact with AWS using AWS Amplify を翻訳したものです。 翻訳は Solutions Architect の&nbsp; Takuya Setaka が担当しました。

この記事は、Salesforce Einstein AI の製品担当ディレクター、 Daryl Martis&nbsp; が共同執筆しています。 これは、Salesforce Data Cloudと Amazon SageMaker の統合について説明するシリーズの第 3 回目の投稿です。 第 1 回 と 第 2 回 では、Salesforce Data Cloud と Einstein Studio と SageMaker の統合により、企業が SageMaker を使用して Salesforce データに安全にアクセスし、そのツールを使用してモデルを構築、トレーニング、および SageMaker でホストされているエンドポイントにデプロイする方法を示します。SageMaker エンドポイントを Salesforce Data Cloud に登録して、Salesforce の予測を有効にすることができます。 この投稿では、ビジネスアナリストやシチズンデータサイエンティストが Amazon SageMaker Canvas でコードなしで機械学習 (ML) モデルを作成し、Salesforce Einstein Studio と統合するためのトレーニング済みモデルをデプロイして強力なビジネスアプリケーションを作成する方法を示します。SageMaker Canvas では、コードを書かなくても Salesforce Data Cloud のデータにアクセスし、数回クリックするだけでモデルをビルド、テスト、デプロイできます。加えて、SageMaker Canvas により特徴の重要度と SHAP 値を使用して予測結果を理解できるため、ML モデルによって算出された予測を簡単に説明できるようになります。 SageMaker Canvas SageMaker Canvas を使用すると、ビジネスアナリストやデータサイエンスチームは、コードを1行も記述しなくても、MLモデルや生成系 AI&nbsp;モデルを構築して使用できます。SageMaker Canvas には、分類、回帰、予測、自然言語処理 (NLP)、およびコンピュータビジョン (CV) に関する正確な ML 予測を生成するための視覚的なポイントアンドクリックインターフェイスが用意されています。さらに、 Amazon Bedrock の基盤モデル (Foundation Models, 以下 FM と呼称) や Amazon SageMaker JumpStart &nbsp;で公開されている FM にアクセスして評価し、生成系 AI ソリューションをサポートするためのコンテンツ生成、テキスト抽出、テキスト要約も行うことができます。加えて、 自ら構築した ML モデルを持ち込んで 、SageMaker Canvas 上で直接予測を生成できます。 Salesforce Data Cloud と Einstein Studio Salesforce Data Cloud は、あらゆるタッチポイントから顧客データをリアルタイムで更新できるデータプラットフォームです。 Einstein Studio は、Salesforce Data Cloud 上の AI ツールへのゲートウェイとなります。Einstein Studio では、システム管理者とデータサイエンティストが数回のクリックまたはコードを使用して簡単にモデルを作成できます。Einstein Studio の独自モデル導入 (BYOM) 機能により、SageMaker などの外部プラットフォームから作成されたカスタムモデルまたは Generative AI モデルを Salesforce Data Cloud に接続することができます。 ソリューション概要 SageMaker Canvas を使用して Salesforce Data Cloud 内のデータを使用して ML モデルを構築する方法を示すために、製品を推奨する予測モデルを作成してみましょう。このモデルでは、顧客の人口統計、マーケティングエンゲージメント、購入履歴など、Salesforce Data Cloud に保存されている特徴量を使用します。製品レコメンデーションモデルは、Salesforce Data Cloud のデータを使用して SageMaker Canvas のノーコードのユーザーインターフェイスを使用して構築およびデプロイされます。 ここでは、 Amazon Simple Storage Service (Amazon S3) に保存されている サンプルデータセット を使用します。このデータセットを Salesforce データクラウドで使用するには、「 Data Cloud で Amazon S3 Data Stream を作成する 」を参照してください。モデルを作成するには、次の変数が必要です。 Club Memeber — お客様がクラブ会員の場合 Campaign — 顧客が参加しているキャンペーン State — 顧客が居住する州または都道府県 Month — 購入月 Case Count — お客様が提起したケースの数 Case Type Return — 顧客が過去1年間に製品を返品したかどうか Case Type Shipment Damaged — 過去1年間に購入者の貨物が破損していたかどうか Enganement Score — 顧客のエンゲージメントのレベル（メールキャンペーンへの応答、オンラインストアへのログインなど） Tenure — 顧客と会社との関係の存続期間 Clicks — 購入前の 1 週間以内にお客様が行った平均クリック数 Pages Visited — 購入前の 1 週間以内に顧客が訪問した平均ページ数 Product Purchased — 実際に購入された製品 これ以降の手順で、エンタープライズデータにアクセスし、予測モデルを構築するために SageMaker Canvas 内で起動した Salesforce Data Cloud コネクタをどのように使用するのかの概要を示していきます。 SageMaker Canvas ドメインを登録するように Salesforce 接続アプリケーションを設定します。 SageMaker Canvas で Salesforce Data Cloud の OAuth を設定します。 組み込みの SageMaker Canvas Salesforce データクラウドコネクタを使用して Salesforce データクラウドデータに接続し、データセットをインポートします。 SageMaker Canvas でモデルを構築してトレーニングします。 モデルを SageMaker Canvas にデプロイし、予測を行います。 SageMaker 推論エンドポイントへのフロントエンド接続として　 Amazon API Gateway エンドポイントを デプロイします。 API Gateway エンドポイントを Einstein Studio に登録します。手順については、「 独自の AI モデルを Data Cloud に取り込む 」を参照してください。 次の図は、ソリューションアーキテクチャを示しています。 前提条件 始める前に、以下の作業手順に沿って SageMaker ドメインを作成し、SageMaker Canvas を有効にしてください。 Amazon SageMaker Studio ドメインを作成します。手順については、「 Onboard to Amazon SageMaker Domain 」を参照してください。 上記の手順で作成されたドメイン ID とユーザープロファイルによって使用される実行ロールを書き留めておきます。このロールには、以降のステップで権限を追加していきます。 以下のスクリーンショットは、この記事のために作成したドメインを示しています。 次に、ユーザープロファイルに移動し、 Edit を選択します。 Amazon SageMaker Canvas 設定セクションに移動し、 Enable Canvas base permissions &nbsp;を選択します。 Enable direct deployments of Canvas models と Enable Model Registory registration permissions for all users &nbsp;を選択します。 これにより、SageMaker Canvas は SageMaker コンソールのエンドポイントにモデルをデプロイできるようになります。これらの設定は、ドメインまたはユーザープロファイルレベルで構成できます。ユーザープロファイル設定はドメイン設定よりも優先されます。 Salesforce 接続アプリケーションを作成または更新する 次に、SageMaker Canvas から Salesforce Data Cloud への OAuth フローを有効にするための Salesforce 接続アプリケーションを作成します。次の手順を完了します。 Salesforce にログインし、 Setup に移動します。 App Manager を検索し、新しい接続アプリケーションを作成します。 次の情報を入力します。 Connected App Name &nbsp;に名前を入力します。 API Name はデフォルトのままにします (自動的に入力されます)。 Connect Email に、連絡先メールアドレスを入力します。 Enable OAuth Settings を選択します。 Calllback URL &nbsp;に&nbsp; https://&lt;domain-id&gt;.studio.&lt;region&gt;.sagemaker.aws/canvas/default/lab &nbsp;と入力します。 &lt;domain-id&gt; にSageMaker ドメインのドメイン ID を、 &lt;region&gt; にリージョンを指定してください。 &nbsp;接続アプリケーションに次のスコープを設定します。 API を介してユーザーデータを管理します（ API ）。 いつでもリクエストを実行できます ( refresh_token , offline_access )。 Salesforce Data Cloud&nbsp;に対して ANSI SQL クエリを実行します（ Data_Cloud_query_api ）。 データクラウドプロファイルデータ を管理します（ Data Cloud_profile_api ）。 ID URL サービスにアクセスします（ id , profile , email , address , phone ）。 固有のユーザー識別子にアクセスします（ openid ）。 接続アプリケーションの IP 緩和設定を [IP 制限の緩和] に設定します。 Salesforce Data Cloud コネクタの OAuth 設定 SageMaker Canvas は AWS シークレットマネージャーを使用して、Salesforce 接続アプリケーションからの接続情報を安全に保存します。SageMaker Canvas では、管理者は個々のユーザープロファイルまたはドメインレベルで OAuth 設定を構成できます。シークレットはドメインとユーザープロファイルの両方に追加できますが、SageMaker Canvas は最初にユーザープロファイル内のシークレットを探すことに注意してください。 OAuth 設定を構成するには、次の手順を実行します。 SageMaker コンソールのドメインまたはユーザープロファイル設定の編集に移動します。ナビゲーションペインからドメインを選択し、設定したいユーザープロファイルを選択してください。その後、 Edit を押下してください。 ナビゲーションペインに表示されている Step4 Canvas setting &nbsp;を選択します。 OAuth settings &nbsp;の Add OAuth configureration を選択します。その後 Data Source で、 Salesforce Data Cloud を選択します。 シークレット設定では、新しいシークレットを作成するか、既存のシークレットを使用できます。この例では、新しいシークレットを作成し、Salesforce 接続アプリケーションからクライアント ID とクライアントシークレットを入力します。 Submit を押下します。 SageMaker Canvas で OAuth を有効にする方法の詳細については、「 Salesforce データクラウド用の OAuth の設定 」を参照してください。 これで、Salesforce データクラウドから SageMaker Canvas にデータアクセスして AI モデルと ML モデルを構築できるようにするセットアップが完了しました。 Salesforce データクラウドからデータをインポートする データをインポートするには、次の手順を実行します。 SageMaker ドメインで作成したユーザープロファイルから Launch を選択し、 Canvas を選択します。 Canvas アプリに初めてアクセスする場合、作成には約 10 分かかります。 ナビゲーションペインで&nbsp; Data Wrangler を選択します。 Create メニューで Tabular&nbsp; を選択し、表形式のデータセットを作成します。 データセットに名前を付け、&nbsp; Create を選択します。 Data Source で、&nbsp; Salesforce Data Cloud を選択し、&nbsp; Add Connection を選択してデータレイクオブジェクトをインポートします。 以前に Salesforce Data Cloud への接続を設定したことがある場合は、新しい接続を作成する代わりにその接続を使用するオプションが表示されます。 新しい Salesforce データクラウド接続の名前を入力し、&nbsp; Add Connection を選択します。 完了するまでに数分かかります。 接続を承認するための Salesforce ログインページにリダイレクトされます。 ログインが成功すると、リクエストはデータレイクオブジェクトリストとともに SageMaker Canvas にリダイレクトされます。 Amazon S3 経由でアップロードされたモデルトレーニング用の機能を含むデータセットを選択します。 ファイルをドラッグアンドドロップし、 Edit in SQL を選択します。 Salesforce はすべてのデータクラウドオブジェクト項目に “__c” &nbsp;を追加します。SageMaker Canvas の命名規則により、フィールド名には “__” &nbsp;は使用できません。 SQL を編集して列の名前を変更し、モデルトレーニングに関係のないメタデータを削除します。テーブル名をオブジェクト名に置き換えます。 SELECT "state__c" as state , "case_type_shipment_damaged__c" as case_type_shipment_damaged , "campaign__c" as campaign , "engagement_score__c" as engagement_score , "case_count__c" as case_count , "case_type_return__c" as case_type_return , "club_member__c" as club_member , "pages_visited__c" as pages_visited , "product_purchased__c" as product_purchased , "clicks__c" as clicks , "tenure__c" as tenure , "month__c" as month FROM product_recommendation__dlm ; Run SQL を選択し、 Create dataset を選択します。 データセットを選択し、 Create a model を選択します。 推奨製品を予測するモデルを作成するには、モデル名を指定し、 Problem type に Predictive analysis を選択し、 Create を選択します。 モデルの構築とトレーニング モデルを構築してトレーニングするには、次の手順を実行します。 モデルを起動したら、ターゲット列を product_purched に設定します。 SageMaker Canvas には、各列とターゲット列の主要な統計と相関関係が表示されます。SageMaker Canvas には、モデルの構築を開始する前にモデルをプレビューしてデータを検証するためのツールが用意されています。 プレビューモデル機能を使用してモデルの精度を確認し、データセットを検証してモデルを構築する際の問題を回避します。 データを確認してデータセットに変更を加えたら、ビルドタイプを選択します。 Quick build の方が速いかもしれませんが、モデルの構築にはデータのサブセットしか使用しません。この記事では、　 Standard build を選択しました。 標準ビルドの完了には 2 ～ 4 時間かかることがあります。 SageMaker Canvas は、モデルの構築中にデータセット内の欠損値を自動的に処理します。また、他のデータ準備変換を適用して、データを使って機械学習ができるように準備します。 モデルの構築が開始されたら、ページを離れることができます。 My models ページでモデルが Ready と表示されると、分析と予測の準備が整います。 モデルを作成したら、 My models に移動し、 View を選択して作成したモデルを表示し、最新バージョンを選択します。 Analyze タブに移動して、各特徴量が予測に与える影響を確認します。 モデルの予測に関する追加情報については、 Scoring タブに移動してください。 製品予測を開始するには、 Predict を選択します。 モデルをデプロイして予測を行う まずはSageMaker Canvas上で作成したモデルの予測結果をプレビューしてみましょう。以下は予測結果をプレビューするためモデルをデプロイし、予測を開始する作業手順となっています。 Batch prediction と Single prediction のどちらを行うかを選択できます。この投稿では、 Single prediction を選択します。 Single prediction を選択すると、SageMaker Canvas にはユーザーが入力できる機能が表示されます。 Update を選択して値を変更し、リアルタイムの予測を表示できます。 モデルの精度と、その特定の予測に対する各特徴量の影響が表示されます。 （訳者注）このようにして、 SageMaker Canvas で作成したモデルを SageMaker Canvas 上で予測を実行することができます。ここまでの操作で、モデルは期待した通りに動いていることがわかります。 SageMaker Canvas で作成したモデルを外部から実行するためには、作成したモデルをデプロイする必要があります。以下はその手順について記載します。 SageMaker Canvas 上からモデルをデプロイするには、デプロイ名を指定し、インスタンスタイプとインスタンス数を選択して、&nbsp; Deploy を選択します。 モデルのデプロイには数分かかります。 デプロイが成功すると、モデルのステータスが In Service に更新されます。 SageMaker Canvas には、デプロイメントをテストするためのオプションが用意されています。 View details を選択します。 Details タブには、モデルエンドポイントの詳細が表示されます。インスタンスタイプ、カウント、入力形式、応答内容、およびエンドポイントは、表示される主な詳細の一部です。 Test deployment を選択して、デプロイされたエンドポイントをテストします。 単一予測と同様に、ビューには入力フィーチャが表示され、エンドポイントをリアルタイムで更新およびテストするオプションが提供されます。 新しい予測は、エンドポイントの呼び出し結果とともにユーザーに返されます。 SageMaker エンドポイントを公開するための API の作成 Salesforce のビジネスアプリケーションを強化する予測を生成するには、SageMaker Canvas のデプロイによって作成された SageMaker 推論エンドポイントを API ゲートウェイ経由で公開し、それを Salesforce Einstein に登録する必要があります。 リクエストとレスポンスの形式は、Salesforce Einstein と SageMaker 推論エンドポイントによって異なります。API Gateway を使用して変換を実行するか、 AWS Lambda を使用してリクエストを変換し、レスポンスをマッピングすることができます。Lambda と API Gateway 経由で SageMaker エンドポイントを公開するには、「 Call an Amazon SageMaker model endpoint using Amazon API Gateway and AWS Lambda 」を参照してください。 次のコードスニペットは、リクエストとレスポンスを変換する Lambda 関数です。 import json import boto3 import os client = boto3.client("runtime.sagemaker") endpoint = os.environ['SAGEMAKER_ENDPOINT_NAME'] prediction_label = 'product_purchased__c' def lambda_handler(event, context): &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;features=[] &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;# Input Sample : {"instances": [{"features": ["Washington", 1, "New Colors", 1, 1, 1, 1, 1, 1, 1, 1]}, {"features": ["California", 1, "Web", 100, 1, 1, 100, 1, 10, 1, 1]}]} &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;for instance in event["instances"]: &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;features.append(','.join(map(str, instance["features"]))) &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;body='\n'.join(features) &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;response = client.invoke_endpoint(EndpointName=endpoint,ContentType="text/csv",Body=body,Accept="application/json") &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;response = &nbsp;json.loads(response['Body'].read().decode('utf-8')) &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;prediction_response={"predictions":[]} &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;for prediction in response.get('predictions'): &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;prediction_response['predictions'].append({prediction_label:prediction['predicted_label']}) &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;return prediction_response 設定に基づいて、Lambda 関数の endpoint と prediction_label の値を更新します。 SageMaker 推論エンドポイントをキャプチャするには、環境変数 SAGEMAKER_ENDPOINT_NAME を追加します。 Einstein Studio に登録されているモデル出力 JSON キーと一致するように予測ラベルを設定します。 Lambda 関数のデフォルトのタイムアウトは 3 秒です。予測リクエストの入力サイズによっては、SageMaker リアルタイム推論 API の応答に 3 秒以上かかる場合があります。 Lambda 関数のタイムアウトを増やしますが、 API Gateway のデフォルトの統合タイムアウト (29 秒) 未満に保ちます。 Salesforce アインシュタインスタジオにモデルを登録 Einstein Studio に API Gateway エンドポイントを登録するには、「 Bring Your Own AI Models to Data Cloud . 」を参照してください。 結論 この記事では、SageMaker Canvas を使用して Salesforce Data Cloud に接続し、自動化された機械学習機能を通じて予測を生成する方法をコードを 1 行も記述せずに説明しました。データセット全体を使ってモデルをトレーニングする標準ビルドを実行する前に、モデルのパフォーマンスを早期にプレビューできる SageMaker Canvas モデルビルド機能を実演しました。また、SageMaker Canvas内の単一の予測インターフェースを使用したり、機能の重要度を利用して予測を理解したりするなど、モデル作成後のアクティビティについても紹介しました。次に、SageMaker Canvas で作成した SageMaker エンドポイントを API として利用できるようにしました。これにより、Salesforce Einstein Studio と統合して強力な Salesforce アプリケーションを作成できます。 今後の記事では、SageMaker Canvas の Salesforce Data Cloud のデータを使用して、視覚的なインターフェイスとシンプルな自然言語プロンプトを使用して、データの洞察と準備をさらに簡単にする方法を紹介します。 SageMaker Canvas を使い始めるには、「 SageMaker Canvas Immersion Day 」と「 Amazon SageMaker Canvas 入門 」を参照してください。 著者について Daryl Martis は、Salesforce Data Cloud の Einstein Studio の製品担当ディレクターです。彼は、AI/MLやクラウドソリューションなど、エンタープライズ顧客向けの世界クラスのソリューションの計画、構築、立ち上げ、管理において10年以上の経験があります。彼は以前、ニューヨーク市のファイナンスサービス業界で働いていました。 Linkedin で彼をフォローしてください。 Rachna Chadha は、AWS のストラテジック・アカウント担当プリンシパル・ソリューション・アーキテクト AI/ML です。Rachna は楽観主義者で、AIを倫理的かつ責任を持って使用することで、将来の社会を改善し、経済的および社会的繁栄をもたらすことができると信じています。余暇には、家族と過ごしたり、ハイキングをしたり、音楽を聴いたりするのがラフナは好きです。 Ife Stewart は、AWS のストラテジック ISV セグメントの主任ソリューションアーキテクトです。彼女は過去 2 年間にわたって Salesforce データクラウドに携わり、Salesforce と AWS 全体で統合されたカスタマーエクスペリエンスの構築を支援してきました。Ife はテクノロジー分野で10年以上の経験があります。彼女はテクノロジー分野における多様性とインクルージョンの提唱者です。 Ravi Bhattiprolu は AWS のシニアパートナーソリューションアーキテクトです。Ravi は、戦略的パートナーである Salesforce や Tableau と協力して、両社の顧客がビジネス目標を実現するのに役立つ、革新的で優れた設計の製品とソリューションを提供しています。 Miriam Lebowitz は、AWS のストラテジック ISV セグメントのソリューションアーキテクトです。彼女はSalesforce Data Cloudを含むSalesforce全体のチームと関わっており、データ分析を専門としています。仕事以外では、お菓子作り、旅行、友人や家族との充実した時間を楽しんでいます。 翻訳はソリューションアーキテクトの辻 浩季が担当しました。原文は こちら です。

はじめに この投稿では、Amazon Elastic Container Service ( Amazon ECS ) におけるアーキテクチャの原則について詳しく説明し、Amazon ECS におけるアプリケーションの高可用性とレジリエンス(回復力)を実現しやすくする機能のいくつかを概説します。Amazon ECS が AWS の可用性と回復力のパターンをどのように活用するように設計されているのか、そして Amazon ECS API などを利用してそうした考え方をどのように簡単に利用できるようになっているのかについて見ていきましょう。これにより、お客様のソリューションの要求に最適な Amazon ECS 構成と機能を選択できるようになると考えています。 AWS の目標は、お客様がビジネスの革新に集中できるように「差別化に繋がらない重労働」を取り除くことです。モダンアプリケーションの多くは、さまざまな障害モードに耐え、高い可用性を備えていることが求められます。回復力と可用性の高いソリューションを構築することは、困難で時間がかかることがあり、多くの場合その投資はビジネスの成功には不可欠ですが、それだけではソリューションを顧客に提供する際の差別化にはなりません。 Amazon ECS は AWS のフルマネージドのコンテナオーケストレーションサービスであり、 Amazon Elastic Compute Cloud (Amazon EC2) 、 AWS Fargate 、または Amazon ECS Anywhere を通じてオンプレミスのハードウェア上でコンテナ化されたアプリケーションを効率的にデプロイ、管理、スケーリングするのに有用です。 Amazon ECS は、AWS が使用している技術を活用して、高可用性を実現しやすくするように構築されています。お客様は Amazon ECS を有効に活用いただくことにより、自社とビジネスを真に差別化する重要な要素であるアプリケーションに集中することができます。 ソリューションの概要 可用性とレジリエンス（回復力） 障害の軽減について検討する際には通常、次の 2 つの領域について検討する必要があります。 そのソリューションはどの程度の可用性が必要なのか そのソリューションにはどの程度の回復力が必要なのか 可用性は、ソリューションが有用な作業を行える確率です。たとえば、ソリューションがカップケーキを販売する Web サイトである場合、ソリューションの可用性は、顧客がいつでもカップケーキを正常に購入できるかどうかで測定できます。ある時点で顧客がカップケーキの購入を完了できなければ、可用性の指標に悪影響を及ぼします。 回復力は可用性に影響しますが、微妙に異なります。回復力とは、悪条件下でも運用を継続できる能力と、通常の運用に戻る速さのことです。カップケーキの例では、顧客が最初に失敗した時点からどれだけ速くカップケーキを購入できるようになるか、で回復力を測ります。別の言い方をすれば可用性は、ある期間にわたってソリューションが動作しなくなった時間の比率として測定でき、回復力は、障害からの回復にかかる平均時間として測定できます。 Amazon ECS のコントロールプレーンを設計する際、私たちはこの 2 つの概念を深く検討し、両方に対応できるサービスとして設計しました。最初に、Amazon ECS がどのように設計され可用性を向上させることができるのかを探り、次に Amazon ECS がどのように設計及び管理されて回復力を向上させているかを確認していきます。 可用性 アプリケーションの稼働期間中に何らかの障害が発生することはほぼ間違いないと考えていいでしょう。AWS の設計で考慮しているのは、 予期せぬ事態を想定すること です。予期していなかった理由で、ある時点で何かがおかしくなることが起こりえます。障害率が非常に低い場合であっても規模が十分に大きい場合には、一定の規模の障害が発生することが想定されます。たとえば、99.99% の可用性で 100 万台のサーバーがある場合、これらのサーバーのうち、いつでも約 100 台に障害が発生すると予想されます。これに対応するため、AWS では、障害が通常の運用の一部であると想定してサービスを設計するようにしています。Amazon ECS では、この考え方を管理レイヤーのサービス設計に取り入れ、Amazon ECS 上に展開されるアプリケーションでも同じことを行うメカニズムを提供する機能を構築しました。 アベイラビリティーゾーンを使用した静的安定性 AWS は、AWS リージョンとアベイラビリティーゾーンの階層構造を通じて、冗長性の高いインフラストラクチャをお客様に提供します。各 AWS リージョンでは、 shared-nothing パターンが採用されています。つまり、各リージョンは他のリージョンから分離され、独立しているため、あるリージョンで起きた障害は他のリージョンには影響を及ぼしません。各 AWS リージョンは複数のアベイラビリティーゾーンによって構成されています。アベイラビリティーゾーンは、ネットワーク遅延の問題を回避するために地理的に十分近接していますが、相関的な障害を避けることを意図して冗長で独立した運用を行えるように、リージョン内に地理的に分散しています。アベイラビリティーゾーンは、それぞれが独自の冗長電源、ネットワーク、およびアベイラビリティーゾーン間接続を備えた 1 つ以上の個別のデータセンターで構成されます。これらのリージョンとアベイラビリティーゾーンという 2 つの構成要素は、可用性の高いサービスを構築するための基盤となります。 Becky Weiss と Mike Furr は、「 アベイラビリティーゾーンを使用した静的安定性 」という記事で、「静的安定性」の意味について説明しています。その記事では AWS のサービスが、アベイラビリティーゾーン全体で事前にスケーリングされた アクティブ – アクティブ ステートレスサービスをどのように活用するか概説しています。Amazon ECS コントロールプレーンは、多数の個別サービスで構成されるマイクロサービスアーキテクチャとなっています。これらのマイクロサービスは、Becky と Mike の記事で概説されているアクティブ – アクティブパターンに基づいて、AWS インフラストラクチャを使用して可用性を最大化するように設計されています。Amazon ECS は、サービス全体の完全かつ独立したコピーがすべてのリージョンにデプロイされています。各マイクロサービスは、リージョン内のすべてのアベイラビリティゾーンにデプロイされ、少なくとも 3 つのアベイラビリティゾーンにまたがってピーク負荷の 150% 以上のオーバープロビジョニングが行われます。これにより 1 つのアベイラビリティーゾーンで障害が発生した場合でも、Amazon ECS は残りのアベイラビリティーゾーンによってマイクロサービスの稼働に十分なキャパシティを確保しているため、お客様のリクエストに応え続けることができます。 Amazon ECS サービスと配置戦略 ワークロードは、コンソール、AWS コマンドラインインターフェイス ( AWS CLI )、または Amazon ECS API を介して直接 Amazon ECS クラスターにプロビジョニングされます。クラスターで実行されているワークロードのインスタンス を起動方法に関係なく「タスク」と呼びます。Amazon ECS のコントロールプレーンは、各マイクロサービスのコピーが少なくとも 3 つのアベイラビリティーゾーンで実行されていることを確認することで、基盤となるインフラストラクチャの障害による影響を軽減します。これと同様の考え方を適用することで、お客様のワークロードにおいて同様の可用性を実現することができます。Amazon ECS を Amazon EC2 で使用する場合、AWS リージョンにおいて利用可能である必要な数のアベイラビリティーゾーンにわたって、サービス内のタスクに spread 戦略を使用するようにサービスを設定します。 Amazon EC2 で Amazon ECS を使用する際にワークロードがアベイラビリティーゾーン全体に分散されるようにするには、それらのアベイラビリティーゾーンのクラスターに Amazon EC2 キャパシティーが登録されていることを確認する必要があります。 Amazon EC2 Auto Scaling グループ (ASG) キャパシティープロバイダー をクラスターに登録し、Amazon EC2 Auto Scaling グループが複数のアベイラビリティーゾーンで Amazon EC2 インスタンスを起動するように設定されていることを確認します。Amazon EC2 のキャパシティが複数のアベイラビリティーゾーンに分散されている場合、タスク配置をアベイラビリティーゾーン全体にできるだけ均等に分散するために spread 配置戦略 を選択することになるでしょう。 Amazon ECS と AWS Fargate を併用すると、タスクをアベイラビリティーゾーン全体に分散させることがさらに簡単になります。サービスを作成するとき、または RunTask リクエストにおいて、タスクのネットワーク設定で複数の Amazon VPC サブネットを指定する必要があります。Amazon VPC の各サブネットはそれぞれ単一のアベイラビリティーゾーンにあります。Amazon ECS は、タスクのプロビジョニング中に設定されたサブネットを使用してタスクを起動するアベイラビリティーゾーンを決定し、すべてのワークロードがこれらのサブネットに分散されるようにします。AWS Fargate は、常にサブネットを介してアベイラビリティーゾーン全体にタスクを分散します。この分散は、サービスをデプロイする場合はサービス名、RunTask を介して単一タスクを起動する場合はタスク定義のファミリー名に基づいています。 分散システムにおけるフォールバックの回避 障害の発生を軽減するためにできることはすべて行ったとしても、ある時点で予期しないイベントによってインフラストラクチャまたはソフトウェアに障害が発生することはあり得ます。Jacob Gabrielson は、「 分散システムでのフォールバックの回避 」という記事の中で、Amazon が障害に直面した際にフォールバック（障害が起きた際に異なるメカニズムを使用して、同じ結果を達成しようとする考え方）することで、かえって障害を悪化させてしまう可能性を発見したことについて概説しています。これを軽減するために、私たちはアクティブ – アクティブ・ソリューションを好んでおり、障害及び、サービス・アーキテクチャにおけるバイモーダル動作（バイモーダル動作とは、サービスが通常モードと障害モードで異なる動作を示すこと）を回避するように努めています。Jacob が概説しているように、我々の経験ではこれは複雑さとリスクをもたらすものです。 自分達のサービスの可用性を向上させるため、1 つのアベイラビリティーゾーンが失われてもサービスが存続できるように (通常、これは利用可能な容量の 33% に相当します)、事前に十分なスケーリングを行っています。例えばあるサービスにおいて、ある程度の余裕があるピーク時のトラフィック負荷をサポートするために 6 つのワーカーが必要であり、そのサービスが 3 つのアベイラビリティーゾーンでホストされている場合、アベイラビリティーゾーンごとに 3 つのワーカー（つまり、アベイラビリティーゾーン毎にプロビジョニングされるワーカー全体の 50%）をプロビジョニングすることで、合計 9 つのワーカーをプロビジョニングします。これにより、1 つのアベイラビリティーゾーンに障害が発生した場合でも、残りのアベイラビリティーゾーンでは十分に事前にスケーリングされ、ピーク時でもサービスがリクエストを処理し続けるのに必要なキャパシティを確保できます。 Amazon ECS サービスで同じ可用性を実現するには、サービスに必要なタスク数をピーク時のトラフィック負荷よりも 50% 大きくし、3 つのアベイラビリティーゾーンに分散して配置します。デプロイ中、またはスケーリングアクティビティの結果として、Amazon ECS は、設定した配置戦略を確実に反映するようにします。Spread 配置の場合、Amazon ECS は設定したアベイラビリティーゾーンにタスクを分散します。 必要なタスク数を決定するには、次の方法をとることができます。 1) まず、サービスを運用する上で必要なタスクの最大数を決定します。これを「基本希望数」と呼びます。 2) 使用する予定のアベイラビリティーゾーンの数を決定します。これを「AZ スプレッド数」と呼びます。 3) 1 つのアベイラビリティーゾーンが利用できなくなった場合でも、ピーク時のトラフィック量を満たし続けるために必要な追加タスク数を計算します。これを「目標希望数」と呼びます。 これを次のように計算します。 目標希望数 = 基本希望数 X ( AZ スプレッド数 / (AZ スプレッド数 – 1) ) たとえば、6 つのタスクが必要で、AZ が 3 つある場合、次のようになります。 目標希望数 = 6 X ( 3 / ( 3 – 1) ) = 9 アベイラビリティーゾーンが 3 つ以上あるリージョンで展開されるような大規模なサービスでは、サービスの構成要素をより多くのアベイラビリティーゾーンに分散させることで、1 つのアベイラビリティーゾーンにおいて必要な事前スケーリング規模を削減することができます。これにより、可用性要件を満たしながら、コストを削減できます。たとえば、us-east-1 には 6 つのアベイラビリティーゾーンがあります (2023/12/15 時点)。次の例を見ると、ピーク負荷を処理するために 600 個の Amazon ECS タスクを必要とするサービスに対して、より多くのアベイラビリティーゾーンで均すことのメリットがわかります。 3 つの AZ で 600 件のタスク:目標希望数 = 600 X ( 3 / ( 3 – 1 ) ) = 900 6 つの AZ で 600 件のタスク:目標希望数 = 600 X ( 6 / ( 6 – 1 ) ) = 720 このケースでは、可用性目標を達成しつつより多くのアベイラビリティーゾーンを使用することでコンピューティングコストを節約できることがわかります。50% の追加コンピューティングが必要なのではなく、上記のシナリオでは 20% で同じ結果が得られます。ワークロードの性質によっては、AZ 間のデータ転送料金が増加し、コストが増加する可能性に注意する必要があります。 このアプローチには多くの利点があります。まず、ロードバランサーと ロードバランサーのヘルスチェック が正しく設定されていれば、1 つのアベイラビリティーゾーンで障害が発生してもサービスは引き続き稼働します。第二に、Jacob が記事で概説したリスクを確実に軽減することになるため、障害を軽減するためのフォールバックがなくて済みます。第三に、このアプローチはテスト環境や検証環境などにおいて同じ設定で環境を構築し、単一のアベイラビリティーゾーン内のすべてのワーカーノードを強制終了することで、簡単にテストすることができます。 Amazon ECS ではアベイラビリティーゾーンからのトラフィックを除外する方法を標準的な運用手順の一部として使用しており、準本番環境および本番環境で定常的に適用しています。これは、顧客に対する高可用性の義務を果たすための重要な考え方です。 シャーディングによるワークロード分離 Amazon ECS では、シャーディングによるワークロード分離を使用しています。これは、Colm MacCártThaigh の記事「 シャッフルシャーディングを使ったワークロードの分離 」で紹介された概念です。これにより、サービスのスケーリングが可能になり、顧客の一連のワークロードを分離する境界を設けることができます。リージョン内の Amazon ECS コントロールプレーンを構成するサービスの中核となるセットは、いわゆるセルに分割されています。各セルは、コントロールプレーンの完全で独立したインスタンスであり、そのリージョンの顧客ワークロードのサブセットを管理します。各セルは前述のように、ピーク負荷容量の 150% 以上で、少なくとも 3 つのアベイラビリティーゾーンにわたってプロビジョニングされます。このセルベースのパーティショニングを使用して、お客様の障害分離をさらに強化しています。顧客のワークロードはリージョン内のセルのサブセットに関連付けられ、それらのワークロードを管理するプロセスは他のセルのプロセスとは異なっています。 このアーキテクチャパターンは、規模と可用性の両方に大きなメリットをもたらすことがわかりました。セルはコントロールプレーンの障害分離境界として機能し、アベイラビリティーゾーンはインフラストラクチャの障害分離境界として機能します。ハードウェアまたはソフトウェアの障害が原因で障害が発生した場合、その障害は通常、単一の障害ゾーンとお客様のワークロードの一部に限定されます。このパターンは、スケーリングを検討する際に非常に役立ちます。セルは本番環境全体の比較的小さな単位であると同時に、完全なソリューションでもあるため、テスト環境や検証環境などの非本番環境において単一セルであっても本番環境相当のスケーリングのテストを行うことができます。本番サービスのスケーリング制約を理解するには、1 つのセルに対してスケーリングのテストを実施するだけで済みます。なぜなら 1 つのセルが本番環境全体の小さな単位であり完全なソリューションであることから、その制約を把握することで本番サービスのスケーリング制約を類推することができるためです。 Amazon ECS のお客様は、クラスターとサービスを組み合わせてこれらの障害分離境界を活用することができます。クラスターを作成すると、1 つ以上の Amazon ECS セルに関連付けられます。クラスターにプロビジョニングされたワークロードは、クラスターが配置されているセル内にあるコントロールプレーンセルによって管理されます。 ソリューションを設計する際の考慮事項の 1 つは、1 つ以上のクラスターをプロビジョニングするかどうかです。Amazon ECS クラスターは、ワークロードをグループ化するために使用される論理的な名前空間です。これは、Amazon ECS 内の障害ゾーンとワークロードを関連させるのに役立ちます。1 つ以上のクラスターをプロビジョニングした場合、異なる Amazon ECS クラスターにおいて相関的な障害からの保護が可能になります。Amazon ECS クラスター内のサービスと Amazon EC2 インスタンスのサービスクォータは比較的大きく、リージョンあたり数千のクラスター、クラスターあたり数千の Amazon ECS サービスに対応できることにお気づきかもしれません。クラスターには料金はかかりません。また、同じ Amazon Virtual Private Cloud ( Amazon VPC ) ネットワークに多くのクラスターを配置できます。ワークロードは同じネットワーク内のクラスタ間で自由に通信できるため、コストをかけずに可用性のニーズに合わせてクラスタを使用することができます。 レジリエンス（回復力） 前述したように、レジリエンス（回復力）とは、悪条件下でも運用を継続できるサービス能力と、通常の運用に戻ることができる速さです。水平方向にスケーリングするワークロードでは、何か障害が発生したとしてもサービスを引き続き利用できるようにしたいと考えています。これは前のセクションで説明したように、事前スケーリングとアベイラビリティーゾーンの静的安定性によって実現されます。回復力の観点からは、サービスができるだけ早く定常状態に戻るようにすると同時に、稼働している状態をできるだけ保ちたいと考えています。 安全なハンズオフ（手放し）デプロイの自動化 AWS では自動化を重視しており、継続的デプロイはこの自動化の重要な部分です。Clare Ligouri は、安全な継続的デプロイを自動化するためのパターンを説明する 素晴らしい記事 を公開しています。 Amazon ECS は、継続的デプロイによって 1 日に複数回デプロイされます。サービスの変更は、障害発生時の影響範囲 (”Blast Radius : 爆発半径“とも呼ばれます)を緩和するために、1 つの AWS リージョンのアベイラビリティーゾーンに一度に 1 つずつ適用されます。また、サービスの新しいリビジョンがそのアベイラビリティーゾーン内のサーバーセットのごく一部にのみ導入されるような頻度でデプロイメントが管理されるようにします。Clare は記事の中で、これをローリングデプロイと呼んでいます。これは、Amazon ECS がお客様のサービスに対してデフォルトでサポートしているのと同じデプロイ戦略です。デプロイが成功しているかを確認するために、サービスの全体的な状態を追跡し、望ましくない動作をすばやく特定できるメトリクスを使用しています。これらのメトリクスで望ましくない結果が見つかった場合、デプロイは自動的にロールバックされます。同時に、1 つのアベイラビリティーゾーンで検出された障害は、影響を受けたアベイラビリティーゾーンのトラフィックを即座に除外する自動化プロセスによって軽減されます。これは、単一の AZ 障害に対応するための事前スケーリングがすでに実施されているため、お客様に影響を与えることなく実現できます。 自動化された安全なハンズオフデプロイとシャーディングによるワークロードの分離 前述のように、Amazon ECS コントロールプレーンを構成するサービスのコアセットは、セルと呼ぶものに分割されています。サービスの回復力をさらに向上させるため、デプロイは単一のセル内と単一のアベイラビリティーゾーン内で行われます。このアプローチにより、アベイラビリティーゾーンでの事前スケーリングを使用して、障害発生時やワークロードの分離時に AZ を除外し、デプロイから生じる予期しない問題への影響をさらに抑えることができます。その結果、変更は一部のサービスワーカーに少しずつ展開されます。 変更は変更セット（変更を加えられる一塊のグループ）としてリリースされます。新しい変更セットを導入する際には、非常に保守的なアプローチを取っています。徹底的なテストが完了すると、新しい変更セットは、ローリングデプロイ戦略を使用して本番環境に少しずつ導入されます。新しい変更セットは、1 つのアベイラビリティーゾーンと 1 つのセル内の 1 つのリージョンに導入され、一部のワーカーにのみ導入されます。デプロイは自動ロールバックアラームで監視されます。いずれかの時点で悪影響が検出された場合、デプロイはすぐにロールバックされます。私たちは待機時間 (Bake Time : Clare の記事 に記載) と初期段階の小さな変更の積み重ねを活用して、変更セットの信頼性を向上させていきます。十分に信頼性が高くなれば、導入のスピードを上げていきます。私たちは、単一の変更セットが、同時に 1 つのリージョンの単一のアベイラビリティーゾーンにのみデプロイされるようにすることに強くこだわっています。 AWS CodePipeline と Amazon ECS を使用すると、同じデプロイパターンをモデル化し、サービスに対して同様のレジリエンス（回復力）を実現できます。 まとめ この投稿では、Amazon ECS で採用しているレジリエンス（回復力）と可用性の原則をいくつか紹介しました。これらのパターンを使用することで、1 つの AZ に障害が発生した場合でも可用性の高いサービスを提供できると同時に、エンジニアリングチームはソフトウェアを安全かつ継続的に提供できるようになります。これらのパターンについては、この記事全体にわたって参照されている Amazon Builders’ Library のドキュメントで詳しく説明されています。これらのドキュメントが、可用性のニーズを満たすサービスを設計する際に有用なガイドとなることを願っています。 この投稿で説明したパターンを使用することには様々な利点があり、それによって Amazon ECS には予期しない障害に直面したとしても高い可用性と回復力が確保されるようになっています。こうしたパターンを継続的デプロイパイプラインに組み込むことで、障害を軽減するメカニズムの標準化ができます。私たちは、コントロールプレーンをセルに分割するというワークロードの分離テクニックを活用し、少なくとも 3 つのアベイラビリティーゾーンにわたってソリューションを事前にスケーリングしています。この考え方を自動ロールバックアラームを備えたローリングデプロイ戦略と組み合わせることで、サービスの可用性を維持しながら開発者の俊敏性を実現することができます。すべてのサービスがこのレベルの可用性や俊敏性を実現する必要があるわけではないため、場合によりこれらのパターンは適切ではないケースもあります。高可用性と回復力の目標を達成する必要がある、大規模で成長過程にあるサービスには、この投稿で紹介した方法論はうまく機能するでしょう。このトピックの詳細については、re: Invent 2023 のセッション “ Deep dive into Amazon ECS resilience and availability (CON401) “を参照ください。 翻訳はパートナーソリューションアーキテクトの髙橋達矢が担当しました。原文は こちら です。