翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# MemoryDB 内のセキュリティ
のクラウドセキュリティが最優先事項 AWS です。お客様は AWS 、セキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャを活用できます。
セキュリティは、 AWS お客様とお客様の間の責任共有です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)ではこれをクラウドのセキュリティおよびクラウド内のセキュリティと説明しています。
+ **クラウドのセキュリティ** – AWS クラウドで AWS サービスを実行するインフラストラクチャを保護する AWS 責任があります。 AWS また、 では、安全に使用できるサービスも提供しています。サードパーティーの監査者は、[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)コンプライアンスプログラムの一環として、当社のセキュリティの有効性を定期的にテストおよび検証。MemoryDB に適用されるコンプライアンスプログラムの詳細については、「コンプライアンスプログラム[AWS による対象範囲内のサービスコンプライアンスプログラム](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
+ **クラウドのセキュリティ** – お客様の責任は、使用する AWS サービスによって決まります。また、お客様は、データの機密性、会社の要件、適用される法律や規制など、その他の要因についても責任を負います。
このドキュメントは、MemoryDB を使用する際の責任共有モデルの適用方法を理解するのに役立ちます。ここでは、セキュリティとコンプライアンスの目標を満たすように MemoryDB を設定する方法を説明します。また、MemoryDB リソースのモニタリングや保護に役立つ他の AWS サービスの使用方法についても説明します。
**Topics**
+ [データ保護](data-protection.md)
+ [ID とアクセス管理](iam.md)
+ [ログ記録とモニタリング](monitoring-overview.md)
+ [コンプライアンス検証](memorydb-compliance.md)
+ [インフラストラクチャセキュリティ](infrastructure-security.md)
+ [
# ネットワーク間のトラフィックのプライバシー
](Security.traffic.md)
+ [サービスの更新](service-updates.md)
# MemoryDB 内のデータ保護
責任 AWS [共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)、 でのデータ保護に適用されます。このモデルで説明されているように、 AWS はすべての を実行するグローバルインフラストラクチャを保護する責任があります AWS クラウド。ユーザーは、このインフラストラクチャでホストされるコンテンツに対する管理を維持する責任があります。また、使用する「 AWS のサービス 」のセキュリティ設定と管理タスクもユーザーの責任となります。データプライバシーの詳細については、[データプライバシーに関するよくある質問](https://aws.amazon.com/compliance/data-privacy-faq/)を参照してください。欧州でのデータ保護の詳細については、*AWS セキュリティブログ*に投稿された「[AWS 責任共有モデルおよび GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/)」のブログ記事を参照してください。
データ保護の目的で、認証情報を保護し AWS アカウント 、 AWS IAM アイデンティティセンター または AWS Identity and Access Management (IAM) を使用して個々のユーザーを設定することをお勧めします。この方法により、それぞれのジョブを遂行するために必要な権限のみが各ユーザーに付与されます。また、次の方法でデータを保護することもお勧めします:
+ 各アカウントで多要素認証 (MFA) を使用します。
+ SSL/TLS を使用して AWS リソースと通信します。TLS 1.2 は必須ですが、TLS 1.3 を推奨します。
+ で API とユーザーアクティビティのログ記録を設定します AWS CloudTrail。CloudTrail 証跡を使用して AWS アクティビティをキャプチャする方法については、「 *AWS CloudTrail ユーザーガイド*」の[CloudTrail 証跡の使用](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)」を参照してください。
+ AWS 暗号化ソリューションと、 内のすべてのデフォルトのセキュリティコントロールを使用します AWS のサービス。
+ Amazon Macie などの高度な管理されたセキュリティサービスを使用します。これらは、Amazon S3 に保存されている機密データの検出と保護を支援します。
+ コマンドラインインターフェイスまたは API AWS を介して にアクセスするときに FIPS 140-3 検証済み暗号化モジュールが必要な場合は、FIPS エンドポイントを使用します。利用可能な FIPS エンドポイントの詳細については、「[連邦情報処理規格 (FIPS) 140-3](https://aws.amazon.com/compliance/fips/)」を参照してください。
お客様の E メールアドレスなどの極秘または機密情報を、タグ、または **[名前]** フィールドなどの自由形式のテキストフィールドに含めないことを強くお勧めします。これは、コンソール、API、または SDK を使用して AWS CLIまたは他の AWS のサービス を操作する場合も同様です。 AWS SDKs タグ、または名前に使用される自由記述のテキストフィールドに入力したデータは、請求または診断ログに使用される場合があります。外部サーバーに URL を提供する場合、そのサーバーへのリクエストを検証できるように、認証情報を URL に含めないことを強くお勧めします。
# MemoryDB 内のデータのセキュリティ
データを安全に保つために、MemoryDB および Amazon EC2 は、サーバーのデータへの不正アクセスに対する防御メカニズムを提供します。
MemoryDB には、クラスター上のデータの暗号化機能も用意されています。
+ 転送時の暗号化では、ある場所から別の場所に移動するデータ (クラスターのノード間、クラスターとアプリケーション間など) に対して必ず暗号化が行なわれます。
+ 保管時の暗号化では、スナップショット操作中にトランザクションログとオンディスクデータが暗号化されます。
[アクセスコントロールリスト (ACL) によるユーザー認証](clusters.acls.md) を使用してクラスターへのユーザーアクセス制御も可能です。
**Topics**
+ [
# MemoryDB 内のデータのセキュリティ
](encryption.md)
+ [
# MemoryDB に保存時の暗号化
](at-rest-encryption.md)
+ [
# MemoryDBの転送時の暗号化 (TLS)
](in-transit-encryption.md)
+ [
# アクセスコントロールリスト (ACL) によるユーザー認証
](clusters.acls.md)
+ [
# IAM を使用した認証
](auth-iam.md)
# MemoryDB に保存時の暗号化
データを安全に保つために、MemoryDB と Amazon S3 は、クラスター内のデータへのアクセスを制限するさまざまな方法を用意しています。詳細については、「[MemoryDB と Amazon VPC](vpcs.md)」および「[MemoryDB でのアイデンティティとアクセス権の管理](iam.md)」を参照してください。
MemoryDB の保管時の暗号化は常に有効になっており、永続データを暗号化することでデータのセキュリティを強化します。以下の項目を暗号化します。
+ トランザクションログ内のデータ
+ 同期、スナップショット、およびスワップオペレーション中のディスク
+ Amazon S3 に保存されたバックアップ
MemoryDB は、保管時のデフォルト (サービス管理) の暗号化だけでなく、[AWS Key Management Service (KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) で独自の対称カスタマー管理カスタマールートキーを使用する機能を提供します。
データ階層化が有効なクラスター内の SSD (ソリッドステートドライブ) に保存されたデータは、デフォルトで常時暗号化されます。
転送時の暗号化については、「[MemoryDBの転送時の暗号化 (TLS)](in-transit-encryption.md)」を参照してください。
**Topics**
+ [
## AWS KMS のカスタマー管理のキーの使用
](#using-customer-managed-keys-for-memorydb-security)
+ [
## 以下の資料も参照してください。
](#at-rest-encryption-see-also)
## AWS KMS のカスタマー管理のキーの使用
MemoryDB は、保管時の暗号化用の対称カスタマー管理の KMS キー (KMS キー) をサポートしています。カスタマー管理の KMS キーは、AWS アカウントで作成、所有、管理される暗号化キーです。詳細については、「AWSKey Management Service デベロッパーガイド」の「[カスタマールートキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#root_keys)」を参照してください。キーは、MemoryDB で使用する前に AWS KMS で作成する必要があります。
AWS KMS ルートキーを作成する方法の詳細については、*AWS Key Management Service デベロッパーガイド*の「[キーの作成](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)」を参照してください。
MemoryDB を使用すると、AWS KMS と統合できます。詳細については、*AWS Key Management Service デベロッパーガイド*の「[付与の使用](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)」を参照してください。MemoryDB と AWS KMS の統合を有効にするために、お客様の作業は必要ありません。
`kms:ViaService` 条件キーは、AWS KMS キーの使用を、指定された AWS サービスからのリクエストに制限します。MemoryDB で `kms:ViaService` を使用するには、両方のViaService 名を条件キーの値 `memorydb.amazon_region.amazonaws.com` に含めます。 詳細については、「[kms:ViaService](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service)」を参照してください。
[AWSCloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) を使用して、MemoryDB によってお客様に代わって AWS Key Management Service に送信されるリクエストを追跡できます。カスタマー管理のキーに関連する AWS Key Management Service へのすべての API コールには、対応する CloudTrail ログがあります。[ListGrants](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListGrants.html) KMS API コールを行うことで、MemoryDB によって作成される許可を表示することもできます。
カスタマー管理のキーを使用してクラスターが暗号化されると、クラスターのすべてのスナップショットは以下のように暗号化されます。
+ 毎日の自動スナップショットは、クラスターに関連付けられたカスタマー管理のキーを使用して暗号化されます。
+ クラスターが削除されたときに作成される最終スナップショットも、クラスターに関連付けられたカスタマー管理のキーを使用して暗号化されます。
+ 手動で作成されたスナップショットは、デフォルトで、クラスターに関連付けられた KMS キーを使用して暗号化されます。この動作は、別のカスタマー管理のキーを選択して上書きできます。
+ スナップショットをコピーするとき、デフォルトでは、ソーススナップショットに関連付けられたカスタマー管理のキーが使用されます。この動作は、別のカスタマー管理のキーを選択して上書きできます。
**注記**
選択した Amazon S3 バケットにスナップショットをエクスポートするとき、カスタマー管理のキーは使用できません。ただし、Amazon S3 にエクスポートされたすべてのスナップショットは、[サーバー側の暗号化](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html)を使用して暗号化されます。 スナップショットファイルを新しい S3 オブジェクトにコピーし、カスタマー管理の KMS キーを使用して暗号化するか、KMS キーを使用してデフォルトの暗号化が設定された別の S3 バケットにコピーするか、ファイル自体の暗号化オプションを変更するかを選択できます。
カスタマー管理のキーを使用して、暗号化にカスタマー管理のキーを使用しない手動で作成されたスナップショットを暗号化することもできます。このオプションを使用すると、データが元のクラスターで暗号化されていない場合でも、Amazon S3 に保存されているスナップショットファイルは KMS キーを使用して暗号化されます。
スナップショットから復元するときは、新しいクラスターの作成時に使用できる暗号化オプションと同様に、使用可能な暗号化オプションから選択できます。
+ キーを削除するか、キーを[無効化](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html)して、クラスターの暗号化に使用したキーの[許可を取り消す](https://docs.aws.amazon.com/kms/latest/APIReference/API_RevokeGrant.html)と、クラスターは回復不可能になります。 つまり、ハードウェア障害の後に変更も回復もできなくなります。AWSルートキーは 7 日間以上の待機期間後にのみ KMS によって削除されます。キーが削除された後、別のカスタマー管理のキーを使用して、アーカイブ目的のスナップショットを作成できます。
+ 自動キー更新は AWS KMS ルートキーのプロパティを保持するため、お客様が MemoryDB データにアクセスできるかどうかには影響しません。暗号化された MemoryDB クラスターは、新しいルートキーの作成と古いキーへの参照の更新を伴う手動キーローテーションをサポートしません。詳細については、「AWS Key Management Service デベロッパーガイド」の「[ Rotating Customer root Keys](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html)」を参照してください。
+ KMS キーを使用して MemoryDB クラスターを暗号化するには、クラスターごとに 1 つの許可が必要です。この許可はクラスターの有効期間を通じて使用されます。さらに、スナップショットの作成時には、スナップショットごとに 1 つの権限が使用されます。この許可はスナップショットの作成後に無効になります。
+ AWS KMS の付与と制限の詳細については、「AWS Key Management Service デベロッパーガイド」の「[クォータ](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html)」を参照してください。
## 以下の資料も参照してください。
+ [MemoryDBの転送時の暗号化 (TLS)](in-transit-encryption.md)
+ [MemoryDB と Amazon VPC](vpcs.md)
+ [MemoryDB でのアイデンティティとアクセス権の管理](iam.md)
# MemoryDBの転送時の暗号化 (TLS)
データを安全に保つために、MemoryDB および Amazon EC2 は、サーバーのデータへの不正アクセスに対する防御メカニズムを提供します。MemoryDB では転送時の暗号化機能を提供されるため、ある場所から別の場所に移動しているデータの保護ツールとして使用できます。例えば、クラスター内、またはクラスターとアプリケーションの間でプライマリノードからリードレプリカノードにデータを移動するとします。
**Topics**
+ [
## 転送時の暗号化の概要
](#in-transit-encryption-overview)
+ [
## 関連情報
](#in-transit-encryption-see-also)
## 転送時の暗号化の概要
MemoryDB の転送時の暗号化は、データがある場所から別の場所に転送されるときに、最も脆弱なポイントでのデータのセキュリティを強化できる機能です。
MemoryDB 転送時の暗号化では、次の機能が実装されます。
+ **暗号化接続**-サーバー接続もクライアント接続もTransport Layer Security (TLS)で暗号化されている。
+ **暗号化レプリケーション** — プライマリノードとレプリカ ノード間を移動するデータが暗号化されます。
+ **サーバー認証** — クライアントは、適切なサーバーに接続していることを認証できます。
2023 年 7 月 20 日以降、新規および既存のクラスターでサポートされる最小バージョンは TLS 1.2 です。AWS のTLS 1.2 の詳細については、こちらの「[リンク](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/)」を参照してください。
MemoryDB クラスターとの接続の詳細については、「[redis-cli を使用して MemoryDB ノードに接続する](getting-started.md#connect-tls)」を参照してください。
## 関連情報
+ [MemoryDB に保存時の暗号化](at-rest-encryption.md)
+ [アクセスコントロールリスト (ACL) によるユーザー認証](https://docs.aws.amazon.com/memorydb/latest/devguide/clusters.acls.html)
+ [MemoryDB と Amazon VPC](vpcs.md)
+ [MemoryDB でのアイデンティティとアクセス権の管理](iam.md)
# アクセスコントロールリスト (ACL) によるユーザー認証
アクセスコントロールリスト (ACL) を使用してユーザーを認証できます。
ACL を使用すると、ユーザーをグループ化してクラスターアクセスを制御できます。これらのアクセスコントロールリストは、クラスターへのアクセスを分類する方法として設計されています。
ACL では、以下で説明されているように、アクセス文字列を使用してユーザーを作成し、ユーザーに特定のアクセス許可を割り当てます。特定のロール (管理者、人事) と連携したアクセスコントロールリストにユーザーを割り当てます。その後、それらは 1 つ以上の MemoryDB クラスターにデプロイされます。これにより、同じMemoryDBクラスターまたはクラスターを使用するクライアント間にセキュリティ境界を設定し、クライアントが互いのデータにアクセスできないようにすることができます。
ACL は、Redis OSS 6 の [ACL](https://valkey.io/docs/topics/acl/) の導入をサポートするように設計されています。MemoryDB クラスターで ACL を使用する場合は、いくつかの制約があります。
+ アクセス文字列にパスワードを指定することはできません。パスワードは [CreateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateUser.html) または [UpdateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateUser.html) コールで設定します。
+ ユーザー権限については、`on` および `off` をアクセス文字列の一部としてパスします。アクセス文字列にどちらも指定されていない場合、ユーザーには `off` が割り当てられ、クラスターへのアクセス権はありません。
+ 禁止されたコマンドは使用できません。禁止されているコマンドを指定すると、例外がスローされます。これらのコマンドの一覧については、「[制限されるコマンド](restrictedcommands.md)」を参照してください。
+ `reset` コマンドを、アクセス文字列の一部として使用することはできません。API パラメータを用いてパスワードを指定すると、MemoryDB がパスワードを管理します。したがって、`reset` を使用することはできません。それによりユーザーのすべてのパスワードが削除されるからです。
+ Redis OSS 6 は、[ACL LIST](https://valkey.io/commands/acl-list) コマンドを導入します。このコマンドは、ユーザーのリストと、各ユーザーに適用される ACL ルールを返します。MemoryDB は `ACL LIST` コマンドをサポートしますが、Redis OSS のようにパスワードハッシュのサポートは含まれていません。MemoryDB を使用すると、[DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html) オペレーションを使用して、アクセス文字列に含まれるルールなど、同様の情報を取得できます。ただし、[DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html) は、ユーザーパスワードを取得しません。
MemoryDB でサポートされているその他の読み取り専用コマンドには、[ACL WHOAMI](https://valkey.io/commands/acl-whoami)、[ACL USERS](https://valkey.io/commands/acl-users)、[ACL CAT](https://valkey.io/commands/acl-cat)などがあります。MemoryDB は、他の書き込みベースの ACL コマンドをサポートしていません。
MemoryDB での ACL の使用については、以下で詳しく説明します。
**Topics**
+ [
## アクセス文字列を使用したアクセス許可の指定
](#access-string)
+ [
## ベクトル検索機能
](#access-vss)
+ [
## MemoryDB のクラスターに ACL を適用します
](#rbac-using)
## アクセス文字列を使用したアクセス許可の指定
MemoryDB クラスターへのアクセス許可を指定するには、 AWS CLI または を使用してアクセス文字列を作成し、ユーザーに割り当てます AWS マネジメントコンソール。
アクセス文字列は、ユーザーに適用されるスペース区切りルールのリストとして定義されます。それらは、ユーザーが実行できるコマンドと、ユーザーが操作できるキーを定義します。コマンドを実行するには、ユーザーは、実行されているコマンドと、そのコマンドによってアクセスされているすべてのキーにアクセスできる必要があります。ルールは左から右に累積的に適用され、提供された文字列に冗長性がある場合は、提供された文字列の代わりに、より単純な文字列を使用できます。
ACL ルールの構文の詳細については、「[ACL](https://valkey.io/topics/acl)」を参照してください。
次の例では、アクセス文字列は、使用可能なすべてのキーおよびコマンドにアクセスできるアクティブなユーザーを表します。
`on ~* &* +@all`
アクセス文字列の構文は、次のように分類されます。
+ `on` — ユーザーはアクティブなユーザーです。
+ `~*` — アクセス権はすべての使用可能なキーに与えられます。
+ `&*` - アクセス権はすべての pubsub チャネルに与えられます。
+ `+@all` — アクセス権はすべての使用可能なコマンドに与えられます。
上記の設定は、最も制限が緩い設定です。これらの設定を変更して、セキュリティを強化できます。
次の例では、アクセス文字列は「app::」キースペースで始まるキーに対する読み取りアクセスに制限されたアクセス権を持つユーザーを表します。
`on ~app::* -@all +@read`
ユーザーがアクセス権を持つコマンドを一覧表示することで、これらのアクセス許可をさらに絞り込むことができます。
`+command1` — ユーザーのコマンドへのアクセスは *`command1`* に制限されます。
`+@category` — ユーザーのアクセスは、コマンドのカテゴリーに制限されます。
アクセス文字列をユーザーに割り当てる方法については、「[コンソールと CLI を使用したユーザーおよびアクセスコントロールリストの作成](#users-management)」を参照してください。
既存のワークロードを MemoryDB に移行する場合は、`ACL LIST` を呼び出すことでアクセス権を取得して、ユーザーおよびパスワードハッシュを除外できます。
## ベクトル検索機能
[ベクトル検索](vector-search.md) では、すべての検索コマンドは `@search` カテゴリに属しており、検索コマンドを含むために既存のカテゴリ `@read`、`@write`、`@fast`、および `@slow` が更新されます。ユーザーがあるカテゴリにアクセスできない場合、そのユーザーは、そのカテゴリ内のいかなるコマンドにもアクセスできません。例えば、ユーザーが `@search` にアクセスできない場合、そのユーザーは、検索関連のいかなるコマンドも実行できません。
次の表は、適切なカテゴリへの検索コマンドのマッピングを示しています。
| VSS コマンド | @read | @write | @fast | @slow |
| --- | --- | --- | --- | --- |
| FT.CREATE | | はい | Y | |
| FT.DROPINDEX | | Y | Y | |
| FT.LIST | Y | | | Y |
| FT.INFO | Y | | Y | |
| FT.SEARCH | Y | | | Y |
| FT.AGGREGATE | Y | | | Y |
| FT.PROFILE | Y | | | Y |
| FT.ALIASADD | | Y | Y | |
| FT.ALIASDEL | | Y | Y | |
| FT.ALIASUPDATE | | Y | Y | |
| FT.\$1ALIASLIST | Y | | | Y |
| FT.EXPLAIN | Y | | Y | |
| FT.EXPLAINCLI | Y | | Y | |
| FT.CONFIG | Y | | はい | |
## MemoryDB のクラスターに ACL を適用します
MemoryDB ACL を使用するには、次のステップに従います。
1. 1 つ以上のユーザーを作成します。
1. ACL を作成し、ユーザーをリストに追加します。
1. ACL をクラスターに割り当てます。
これらのステップは、以下に詳細が説明されます。
**Topics**
+ [
### コンソールと CLI を使用したユーザーおよびアクセスコントロールリストの作成
](#users-management)
+ [
### コンソールおよび CLI を使用したアクセスコントロールリストの管理
](#user-groups)
+ [
### アクセスコントロールリストのクラスターへの割り当て
](#users-groups-to-clusterss)
### コンソールと CLI を使用したユーザーおよびアクセスコントロールリストの作成
ACLユーザーのユーザー情報は、ユーザー名、およびオプションのパスワードとアクセス文字列です。アクセス文字列は、キーとコマンドでのアクセス許可レベルを提供します。この名前 はユーザーに対して一意であり、エンジンに渡されるものです。
指定するユーザー許可が、ACLの意図した目的に合っていることを確認してください。例えば、`Administrators` というACLを作成した場合、そのグループに追加するユーザーは、アクセス文字列をキーおよびコマンドへのフルアクセスに設定する必要があります。 `e-commerce` ACL のユーザーの場合、アクセス文字列を読み取り専用アクセスに設定できます。
MemoryDB は、アカウントごとにユーザー名を使用してデフォルトユーザー `"default"` を自動的に設定します。ACL に明示的に追加しない限り、どのクラスターにも関連付けられません。このユーザーを変更または削除することはできません。このユーザーは、以前の Redis OSS バージョンのデフォルト動作との互換性を意図して作成されており、すべてのコマンドを呼び出してすべてのキーにアクセスできるようにするアクセス文字列を持っています。
デフォルトユーザーを含むすべてのアカウントに対して、不変の「オープンアクセス」ACLが作成されます。これは、デフォルトユーザーがメンバーになれる唯一の ACL です。クラスターを作成するときに、クラスター関連付けるACLを選択する必要があります。デフォルトユーザーで「オープンアクセス」ACL を適用することもできますが、ビジネスニーズに合わせて権限が制限されているユーザーを含む ACL を作成することを強くお勧めします。
TLS が有効になっていないクラスターでは、「オープンアクセス」ACL を使用してオープン認証を行う必要があります。
ACL はユーザーなしで作成できます。空の ACL はクラスターにアクセスできず、TLS 有効なクラスターにのみ関連付けることができます。
ユーザーを作成するときは、最大 2 つのパスワードを設定できます。パスワードを変更しても、クラスターへの既存の接続はすべて維持されます。
特に、MemoryDBでACLを使用する場合は、ユーザーパスワードの制約に注意してください：
+ パスワードは、印刷可能な 16～128 文字にする必要があります。
+ 次の英数字以外の文字は使用できません: `,` `""` `/` `@`。
#### コンソールおよび CLI を使用したユーザーの管理
##### ユーザーの作成 (コンソール)
**コンソールでユーザーを作成するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) で MemoryDB コンソールを開きます。
1. 左のナビゲーションペインで、**[ユーザー]** を選択します。
1. **[ユーザーの作成]** を選択します。
1. **[ユーザーの作成]** ページで **[名前]** を入力します。
クラスターの命名に関する制約は次のとおりです。
+ 1～40 個の英数字またはハイフンを使用する必要があります。
+ 先頭は文字を使用する必要があります。
+ 連続する 2 つのハイフンを含めることはできません。
+ ハイフンで終わることはできません。
1. **[パスワード]** には、最大 2 つのパスワードを入力できます。
1. **[アクセス文字列]** にアクセス文字列を入力します。アクセス文字列は、ユーザーが許可されたキーとコマンドのアクセス許可レベルを設定します。
1. **タグ**では、オプションでタグを適用してユーザーを検索およびフィルタリングしたり、 AWS コストを追跡したりできます。
1. **[作成]** を選択します。
##### を使用したユーザーの作成 AWS CLI
**CLI を使用してユーザーを作成するには**
+ ユーザーを作成するには、[create-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-user.html)コマンドを使用します。
Linux、macOS、Unix の場合:
```
aws memorydb create-user \
--user-name user-name-1 \
--access-string "~objects:* ~items:* ~public:*" \
--authentication-mode \
Passwords="abc",Type=password
```
Windows の場合:
```
aws memorydb create-user ^
--user-name user-name-1 ^
--access-string "~objects:* ~items:* ~public:*" ^
--authentication-mode \
Passwords="abc",Type=password
```
##### ユーザーの変更 (コンソール)
**コンソールでユーザーに変更を加えるには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) で MemoryDB コンソールを開きます。
1. 左のナビゲーションペインで、**[ユーザー]** を選択します。
1. 変更するユーザーの横にあるラジオボタンを選択し、**[アクション]** ->**[変更]** を選択します。
1. パスワードを変更する場合は、**[パスワードの変更]** ラジオボタンを選択します。パスワードが 2 つある場合は、どちらか一方を変更するときに両方を入力する必要があることに注意してください。
1. アクセス文字列を更新する場合は、新しい文字列を入力します。
1. **[Modify]** (変更) を選択します。
##### を使用したユーザーの変更 AWS CLI
**CLI を使用してユーザーを変更するには**
1. 「[ユーザーの更新](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-user.html)」コマンドを使用してユーザーを変更します。
1. ユーザーが変更されると、そのユーザーに関連付けられたアクセスコントロールリストが、ACL に関連付けられたクラスターとともに更新されます。既存の接続はすべて維持されます。以下は例です。
Linux、macOS、Unix の場合:
```
aws memorydb update-user \
--user-name user-name-1 \
--access-string "~objects:* ~items:* ~public:*"
```
Windows の場合:
```
aws memorydb update-user ^
--user-name user-name-1 ^
--access-string "~objects:* ~items:* ~public:*"
```
##### ユーザーの詳細を表示する (コンソール)
**コンソールでユーザーの詳細を表示するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) で MemoryDB コンソールを開きます。
1. 左のナビゲーションペインで、**[ユーザー]** を選択します。
1. **[ユーザー名]** でユーザーを選択するか、検索ボックスを使用してユーザーを検索します。
1. **[ユーザー設定]** で、ユーザーのアクセス文字列、パスワード数、ステータス、Amazon リソースネーム (ARN) を確認できます。
1. **[アクセスコントロールリスト (ACL)]** では、ユーザーが所属する ACL を確認できます。
1. **[タグ]** では、ユーザーに関連付けられているすべてのタグを確認できます。
##### を使用したユーザーの詳細の表示 AWS CLI
「[ユーザーの詳細](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-users.html)」 コマンドを使用して、ユーザーの詳細を表示します。
```
aws memorydb describe-users \
--user-name my-user-name
```
##### ユーザーの削除 (コンソール)
**コンソールでユーザーを削除するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) で MemoryDB コンソールを開きます。
1. 左のナビゲーションペインで、**[ユーザー]** を選択します。
1. 変更するユーザーの横にあるラジオボタンを選択し、**[アクション]**->**[削除]** を選択します。
1. 確認テキストボックスで、`delete` を入力し、**確認** を選択します。
1. キャンセルするには、**キャンセル** をクリックします。
##### を使用したユーザーの削除 AWS CLI
**CLI を使用してサービスロールを削除するには**
+ ユーザーを削除するには、[delete-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-user.html) コマンドを使用します。
アカウントが削除され、そのアカウントが属するアクセス制御リストから削除されます。以下に例を示します。
Linux、macOS、Unix の場合:
```
aws memorydb delete-user \
--user-name user-name-2
```
Windows の場合:
```
aws memorydb delete-user ^
--user-name user-name-2
```
### コンソールおよび CLI を使用したアクセスコントロールリストの管理
次に示すように、アクセスコントロールリストを作成して、1 つ以上のクラスターに対するユーザーのアクセスを分類および制御できます。
次の手順に従って、コンソールを使用してアクセス制御リストを管理します。
#### アクセスコントロールリスト (ACL) の作成 (コンソール)
**コンソールを使用してアクセスコントロールリストを作成するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) で MemoryDB コンソールを開きます。
1. 左側のナビゲーションペインで、**[アクセスコントロールリスト (ACL)]** を選択します。
1. **[ACL を作成]** を選択します。
1. **[アクセスコントロールリスト (ACL) の作成]** ページで、ACL 名を入力します。
クラスターの命名に関する制約は次のとおりです。
+ 1～40 個の英数字またはハイフンを使用する必要があります。
+ 先頭は文字を使用する必要があります。
+ 連続する 2 つのハイフンを含めることはできません。
+ ハイフンで終わることはできません。
1. **[ユースケースを選択する]** で、次のいずれかを実行します。
1. **[ユーザーの作成]** を選択して新規ユーザーを作成します。
1. ユーザーを追加するには、**[管理]** を選択し、**[ユーザーの管理]** ダイアログからユーザーを選択し、**[選択]** を選択します。
1. **タグ**では、オプションでタグを適用して ACLsしたり、 AWS コストを追跡したりできます。
1. **[作成]** を選択します。
#### を使用したアクセスコントロールリスト (ACL) の作成 AWS CLI
次の手順で、CLI を使用してアクセスコントロールリストを作成します。
**CLI を使用して新しいACLを作成し、ユーザーを追加するには**
+ [create-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-acl.html) コマンドを使用して ACL を作成します。
Linux、macOS、Unix の場合:
```
aws memorydb create-acl \
--acl-name "new-acl-1" \
--user-names "user-name-1" "user-name-2"
```
Windows の場合:
```
aws memorydb create-acl ^
--acl-name "new-acl-1" ^
--user-names "user-name-1" "user-name-2"
```
#### アクセスコントロールリスト (ACL) の変更 (コンソール)
**コンソールを使用してアクセスコントロールリストを変更するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) で MemoryDB コンソールを開きます。
1. 左側のナビゲーションペインで、**[アクセスコントロールリスト (ACL)]** を選択します。
1. 変更する ACL を選択し、**[変更]** をクリックします。
1. **[変更]** ページの **[選択したユーザー]** で、次のいずれかを実行します。
1. **[ユーザーの作成]** を選択して新しいユーザーを作成し、ACL に追加します。
1. ユーザーを追加または削除するには、**[管理]** を選択し、**[ユーザーの管理]** ダイアログでユーザーを選択または選択解除し、**[選択]** を選択します。
1. **[アクセスコントロールリスト (ACL) の作成]** ページで、ACL 名を入力します。
クラスターの命名に関する制約は次のとおりです。
+ 1～40 個の英数字またはハイフンを使用する必要があります。
+ 先頭は文字を使用する必要があります。
+ 連続する 2 つのハイフンを含めることはできません。
+ ハイフンで終わることはできません。
1. **[ユースケースを選択する]** で、次のいずれかを実行します。
1. **[ユーザーの作成]** を選択して新規ユーザーを作成します。
1. ユーザーを追加するには、**[管理]** を選択し、**[ユーザーの管理]** ダイアログからユーザーを選択し、**[選択]** を選択します。
1. **[変更]** を選択して変更を保存するか、**[キャンセル]** を選択して変更を破棄します。
#### を使用したアクセスコントロールリスト (ACL) の変更 AWS CLI
**CLI を使用して新しいユーザーを追加するか、現在のメンバーを削除してACLを変更するには**
+ 「[ACL の更新](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-acl.html)」コマンドを使用して ACL を変更します。
Linux、macOS、Unix の場合:
```
aws memorydb update-acl --acl-name new-acl-1 \
--user-names-to-add user-name-3 \
--user-names-to-remove user-name-2
```
Windows の場合:
```
aws memorydb update-acl --acl-name new-acl-1 ^
--user-names-to-add user-name-3 ^
--user-names-to-remove user-name-2
```
**注記**
ACLから削除されたユーザーに属するオーペン接続はすべて、このコマンドによって終了されます。
#### アクセスコントロールリスト (ACL) の詳細の表示 (コンソール)
**ACL の詳細をコンソールに表示するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) で MemoryDB コンソールを開きます。
1. 左のナビゲーションペインで、**[アクセスコントロールリスト (ACL)]** をクリックします。
1. **[ACL 名]** の下にある ACL を選択するか、検索ボックスを使用して ACL を検索します。
1. **[ユーザー]** で、ACL に関連付けられているユーザーのリストを確認できます。
1. **[関連クラスター]** で、ACL が属するクラスターを確認できます。
1. **[タグ]** では、ACL に関連付けられたすべてのタグを確認できます。
#### を使用したアクセスコントロールリスト (ACL) の表示 AWS CLI
「[ACL の詳細](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-acls.html)」コマンドを使用して ACL の詳細を表示します。
```
aws memorydb describe-acls \
--acl-name test-group
```
#### アクセスコントロールリスト (ACL) の削除 (コンソール)
**コンソールを使用してアクセスコントロールリストを削除するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) で MemoryDB コンソールを開きます。
1. 左側のナビゲーションペインで、**[アクセスコントロールリスト (ACL)]** を選択します。
1. 変更する ACL を選択し、**[削除]** を選択します
1. ACL が削除されないようにするには、**[削除]** ページで確認ボックスに `delete` を入力し、**[削除]** または **[キャンセル]** を選択します。
グループに属するユーザーではなく、ACL自体が削除されます。
#### を使用したアクセスコントロールリスト (ACL) の削除 AWS CLI
**CLI を使用してACLを削除するには**
+ [delete- acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-acl.html) コマンドを使用してACLを削除します。
Linux、macOS、Unix の場合:
```
aws memorydb delete-acl /
--acl-name
```
Windows の場合:
```
aws memorydb delete-acl ^
--acl-name
```
上記の例では、次の応答を返します。
```
aws memorydb delete-acl --acl-name "new-acl-1"
{
"ACLName": "new-acl-1",
"Status": "deleting",
"EngineVersion": "6.2",
"UserNames": [
"user-name-1",
"user-name-3"
],
"clusters": [],
"ARN":"arn:aws:memorydb:us-east-1:493071037918:acl/new-acl-1"
}
```
### アクセスコントロールリストのクラスターへの割り当て
ACL を作成してユーザーを追加した後、ACL を実装する最後の手順では、ACL をクラスターに割り当てます。
#### コンソールを使用してクラスターにアクセスコントロールリストを割り当てます
を使用してクラスターに ACL を追加するには AWS マネジメントコンソール、「」を参照してください[MemoryDB クラスターの作成](getting-started.md#clusters.create)。
#### を使用したクラスターへのアクセスコントロールリストの割り当て AWS CLI
次の AWS CLI オペレーションでは、転送中の暗号化 (TLS) が有効になっているクラスターと、値 を持つ **acl-name**パラメータを作成します`my-acl-name`。サブネット グループ `subnet-group` を、実存のサブネットグループに置き換えます。
**主要パラメータ**
+ **--engine-version** -「6.2」を指定してください
+ **--tls-enabled** – 認証と ACL の関連付けに使用されます。
+ **--acl-name** — この値は、クラスターに対して指定されたアクセス権限を持つユーザーで構成されるアクセス制御リストを提供します。
Linux、macOS、Unix の場合:
```
aws memorydb create-cluster \
--cluster-name "new-cluster" \
--description "new-cluster" \
--engine-version "6.2" \
--node-type db.r6g.large \
--tls-enabled \
--acl-name "new-acl-1" \
--subnet-group-name "subnet-group"
```
Windows の場合:
```
aws memorydb create-cluster ^
--cluster-name "new-cluster" ^
--cluster-description "new-cluster" ^
--engine-version "6.2" ^
--node-type db.r6g.large ^
--tls-enabled ^
--acl-name "new-acl-1" ^
--subnet-group-name "subnet-group"
```
次の AWS CLI オペレーションでは、転送中の暗号化 (TLS) が有効になっているクラスターと、値 を持つ **acl-name**パラメータを変更します`new-acl-2`。
Linux、macOS、Unix の場合:
```
aws memorydb update-cluster \
--cluster-name cluster-1 \
--acl-name "new-acl-2"
```
Windows の場合:
```
aws memorydb update-cluster ^
--cluster-name cluster-1 ^
--acl-name "new-acl-2"
```
# IAM を使用した認証
**Topics**
+ [
## 概要:
](#auth-iam-overview)
+ [
## 制限事項
](#auth-iam-limits)
+ [
## セットアップ
](#auth-iam-setup)
+ [
## 接続中
](#auth-iam-Connecting)
## 概要:
IAM 認証では、クラスターが Valkey または Redis OSS バージョン 7 以降を使用するように設定されている場合、IAM ID AWS を使用して MemoryDB への接続を認証できます。これにより、セキュリティモデルを強化し、多くの管理セキュリティタスクを簡素化できます。IAM 認証では、個々の MemoryDB クラスターと MemoryDB ユーザーごとにきめ細かいアクセス制御を設定し、最小特権の権限の原則に従うことができます。MemoryDB の IAM 認証は、有効期間の長い MemoryDB ユーザーパスワードの代わりに、有効期間が短い IAM 認証トークンを `AUTH` または `HELLO` コマンドで提供することにより機能します。IAM 認証トークンの詳細については、 AWS 全般のリファレンスガイドの署名[バージョン 4 の署名プロセス](https://docs.aws.amazon.com//general/latest/gr/signature-version-4.html)と、以下のコード例を参照してください。
IAM アイデンティティとそれに関連するポリシーを使用して、Valkey または Redis OSS アクセスをさらに制限できます。また、フェデレーテッド ID プロバイダーのユーザーに MemoryDB クラスターへのアクセス権を直接付与することもできます。
MemoryDB で AWS IAM を使用するには、まず認証モードを IAM に設定して MemoryDB ユーザーを作成し、IAM ID を作成または再利用する必要があります。IAM アイデンティティには、MemoryDB クラスターと MemoryDB ユーザーに `memorydb:Connect` アクションを許可するための関連ポリシーが必要です。設定したら、IAM ユーザーまたはロールの AWS 認証情報を使用して IAM 認証トークンを作成できます。最後に、MemoryDB クラスターノードに接続するときに、有効期間が短い IAM 認証トークンを Valkey または Redis OSS クライアントのパスワードとして指定する必要があります。認証情報プロバイダーをサポートしているクライアントは、新しい接続ごとに一時的な認証情報を自動的に生成できます。MemoryDB for Redis は、IAM が有効な MemoryDB ユーザーの接続リクエストに対して IAM 認証を実行し、その接続リクエストを IAM で検証します。
## 制限事項
IAM 認証を使用する場合、以下の制限が適用されます。
+ Valkey または Redis OSS エンジンバージョン 7.0 以上を使用している場合、IAM 認証が利用できます。
+ IAM 認証トークンは 15 分間有効です。長時間接続する場合は、認証情報プロバイダーインターフェイスをサポートする Redis OSS クライアントを使用することをお勧めします。
+ MemoryDB for Redis への IAM 認証された接続は、12 時間後に自動的に切断されます。新しい IAM 認証トークンを使用して`AUTH` または `HELLO` コマンドを送信することで、接続を 12 時間延長できます。
+ IAM 認証は `MULTI EXEC` コマンドではサポートされていません。
+ 現在、IAM 認証はすべてのグローバル条件コンテキストキーをサポートしていません。グローバル条件コンテキストキーの詳細については、「IAM ユーザーガイド」の「[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
## セットアップ
IAM 認証をセットアップするには:
1. クラスターを作成する
```
aws memorydb create-cluster \
--cluster-name cluster-01 \
--description "MemoryDB IAM auth application"
--node-type db.r6g.large \
--engine-version 7.0 \
--acl-name open-access
```
1. アカウントが新しいロールを引き継ぐことを許可するロール用の IAM 信頼ポリシードキュメントを以下に示すように作成します。ポリシーを *trust-policy.json* というファイルに保存します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Action": "sts:AssumeRole"
}
}
```
------
1. 以下に示すように、IAM ポリシードキュメントを作成します。ポリシーを *policy.json* というファイルに保存します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect" : "Allow",
"Action" : [
"memorydb:connect"
],
"Resource" : [
"arn:aws:memorydb:us-east-1:123456789012:cluster/cluster-01",
"arn:aws:memorydb:us-east-1:123456789012:user/iam-user-01"
]
}
]
}
```
------
1. IAM ロールを作成します。
```
aws iam create-role \
--role-name "memorydb-iam-auth-app" \
--assume-role-policy-document file://trust-policy.json
```
1. IAM ポリシーを作成します。
```
aws iam create-policy \
--policy-name "memorydb-allow-all" \
--policy-document file://policy.json
```
1. IAM ポリシーをロールにアタッチします。
```
aws iam attach-role-policy \
--role-name "memorydb-iam-auth-app" \
--policy-arn "arn:aws:iam::123456789012:policy/memorydb-allow-all"
```
1. IAM を有効にしている新しいユーザーを作成します。
```
aws memorydb create-user \
--user-name iam-user-01 \
--authentication-mode Type=iam \
--access-string "on ~* +@all"
```
1. ACL を作成し、ユーザーをアタッチします。
```
aws memorydb create-acl \
--acl-name iam-acl-01 \
--user-names iam-user-01
aws memorydb update-cluster \
--cluster-name cluster-01 \
--acl-name iam-acl-01
```
## 接続中
**トークンをパスワードとして接続**
最初に、[AWS SigV4 の署名済みリクエスト](https://docs.aws.amazon.com//general/latest/gr/sigv4-signed-request-examples.html)を使用して、有効期間が短い IAM 認証トークンを生成する必要があります。その後、以下の例に示すように、MemoryDB クラスターに接続するときに IAM 認証トークンをパスワードとして指定します。
```
String userName = "insert user name"
String clusterName = "insert cluster name"
String region = "insert region"
// Create a default AWS Credentials provider.
// This will look for AWS credentials defined in environment variables or system properties.
AWSCredentialsProvider awsCredentialsProvider = new DefaultAWSCredentialsProviderChain();
// Create an IAM authentication token request and signed it using the AWS credentials.
// The pre-signed request URL is used as an IAM authentication token for MemoryDB.
IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userName, clusterName, region);
String iamAuthToken = iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials());
// Construct URL with IAM Auth credentials provider
RedisURI redisURI = RedisURI.builder()
.withHost(host)
.withPort(port)
.withSsl(ssl)
.withAuthentication(userName, iamAuthToken)
.build();
// Create a new Lettuce client
RedisClusterClient client = RedisClusterClient.create(redisURI);
client.connect();
```
以下は `IAMAuthTokenRequest` の定義です。
```
public class IAMAuthTokenRequest {
private static final HttpMethodName REQUEST_METHOD = HttpMethodName.GET;
private static final String REQUEST_PROTOCOL = "http://";
private static final String PARAM_ACTION = "Action";
private static final String PARAM_USER = "User";
private static final String ACTION_NAME = "connect";
private static final String SERVICE_NAME = "memorydb";
private static final long TOKEN_EXPIRY_SECONDS = 900;
private final String userName;
private final String clusterName;
private final String region;
public IAMAuthTokenRequest(String userName, String clusterName, String region) {
this.userName = userName;
this.clusterName = clusterName;
this.region = region;
}
public String toSignedRequestUri(AWSCredentials credentials) throws URISyntaxException {
Request request = getSignableRequest();
sign(request, credentials);
return new URIBuilder(request.getEndpoint())
.addParameters(toNamedValuePair(request.getParameters()))
.build()
.toString()
.replace(REQUEST_PROTOCOL, "");
}
private Request getSignableRequest() {
Request request = new DefaultRequest<>(SERVICE_NAME);
request.setHttpMethod(REQUEST_METHOD);
request.setEndpoint(getRequestUri());
request.addParameters(PARAM_ACTION, Collections.singletonList(ACTION_NAME));
request.addParameters(PARAM_USER, Collections.singletonList(userName));
return request;
}
private URI getRequestUri() {
return URI.create(String.format("%s%s/", REQUEST_PROTOCOL, clusterName));
}
private void sign(SignableRequest request, AWSCredentials credentials) {
AWS4Signer signer = new AWS4Signer();
signer.setRegionName(region);
signer.setServiceName(SERVICE_NAME);
DateTime dateTime = DateTime.now();
dateTime = dateTime.plus(Duration.standardSeconds(TOKEN_EXPIRY_SECONDS));
signer.presignRequest(request, credentials, dateTime.toDate());
}
private static List toNamedValuePair(Map> in) {
return in.entrySet().stream()
.map(e -> new BasicNameValuePair(e.getKey(), e.getValue().get(0)))
.collect(Collectors.toList());
}
}
```
**認証情報プロバイダーに接続**
以下のコードは、IAM 認証情報プロバイダーを使用して MemoryDB for Redis で認証する方法を示しています。
```
String userName = "insert user name"
String clusterName = "insert cluster name"
String region = "insert region"
// Create a default AWS Credentials provider.
// This will look for AWS credentials defined in environment variables or system properties.
AWSCredentialsProvider awsCredentialsProvider = new DefaultAWSCredentialsProviderChain();
// Create an IAM authentication token request. Once this request is signed it can be used as an
// IAM authentication token for MemoryDB.
IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userName, clusterName, region);
// Create a credentials provider using IAM credentials.
RedisCredentialsProvider redisCredentialsProvider = new RedisIAMAuthCredentialsProvider(
userName, iamAuthTokenRequest, awsCredentialsProvider);
// Construct URL with IAM Auth credentials provider
RedisURI redisURI = RedisURI.builder()
.withHost(host)
.withPort(port)
.withSsl(ssl)
.withAuthentication(redisCredentialsProvider)
.build();
// Create a new Lettuce cluster client
RedisClusterClient client = RedisClusterClient.create(redisURI);
client.connect();
```
以下は、IAMAuthTokenRequest を認証情報プロバイダーにラップして、必要に応じて一時的な認証情報を自動生成する Lettuce クラスタークライアントの例です。
```
public class RedisIAMAuthCredentialsProvider implements RedisCredentialsProvider {
private static final long TOKEN_EXPIRY_SECONDS = 900;
private final AWSCredentialsProvider awsCredentialsProvider;
private final String userName;
private final IAMAuthTokenRequest iamAuthTokenRequest;
private final Supplier iamAuthTokenSupplier;
public RedisIAMAuthCredentialsProvider(String userName,
IAMAuthTokenRequest iamAuthTokenRequest,
AWSCredentialsProvider awsCredentialsProvider) {
this.userName = userName;
this.awsCredentialsProvider = awsCredentialsProvider;
this.iamAuthTokenRequest = iamAuthTokenRequest;
this.iamAuthTokenSupplier = Suppliers.memoizeWithExpiration(this::getIamAuthToken, TOKEN_EXPIRY_SECONDS, TimeUnit.SECONDS);
}
@Override
public Mono resolveCredentials() {
return Mono.just(RedisCredentials.just(userName, iamAuthTokenSupplier.get()));
}
private String getIamAuthToken() {
return iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials());
}
```
# MemoryDB でのアイデンティティとアクセス権の管理
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御 AWS のサービス するのに役立つ です。IAM 管理者は、どのユーザーが MemoryDB リソースの使用を*認証* (サインイン) および*承認* (権限を持たせる) されるかを制御します。IAM は、追加料金なしで使用できる AWS のサービス です。
**Topics**
+ [
## オーディエンス
](#security_iam_audience)
+ [
## アイデンティティを使用した認証
](#security_iam_authentication)
+ [
## ポリシーを使用したアクセスの管理
](#security_iam_access-manage)
+ [
# MemoryDB と IAM の連携の仕組み
](security_iam_service-with-iam.md)
+ [
# MemoryDB のアイデンティティベースのポリシーの例
](security_iam_id-based-policy-examples.md)
+ [
# MemoryDB のアイデンティティとアクセスの問題のトラブルシューティング
](security_iam_troubleshoot.md)
+ [
## アクセスコントロール
](#iam.accesscontrol)
+ [
# MemoryDB リソースに対する許可の管理の概要
](iam.overview.md)
## オーディエンス
AWS Identity and Access Management (IAM) の使用方法は、ロールによって異なります。
+ **サービスユーザー** - 機能にアクセスできない場合は、管理者にアクセス許可をリクエストします (「[MemoryDB のアイデンティティとアクセスの問題のトラブルシューティング](security_iam_troubleshoot.md)」を参照)。
+ **サービス管理者** - ユーザーアクセスを決定し、アクセス許可リクエストを送信します (「[MemoryDB と IAM の連携の仕組み](security_iam_service-with-iam.md)」を参照)
+ **IAM 管理者** - アクセスを管理するためのポリシーを作成します (「[MemoryDB のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照)
## アイデンティティを使用した認証
認証とは、ID 認証情報 AWS を使用して にサインインする方法です。、IAM ユーザー AWS アカウントのルートユーザー、または IAM ロールを引き受けることで認証される必要があります。
( AWS IAM アイデンティティセンター IAM Identity Center)、シングルサインオン認証、Google/Facebook 認証情報などの ID ソースからの認証情報を使用して、フェデレーティッド ID としてサインインできます。サインインの詳細については、「*AWS サインイン ユーザーガイド*」の「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。
プログラムによるアクセスの場合、 は SDK と CLI AWS を提供してリクエストを暗号化して署名します。詳細については、「*IAM ユーザーガイド*」の「[API リクエストに対するAWS 署名バージョン 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。
### AWS アカウント ルートユーザー
を作成するときは AWS アカウント、まず、すべての AWS のサービス および リソースへの完全なアクセス権を持つ AWS アカウント *root ユーザー*と呼ばれる 1 つのサインインアイデンティティから始めます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。
### フェデレーテッドアイデンティティ
ベストプラクティスとして、人間のユーザーが一時的な認証情報 AWS のサービス を使用して にアクセスするには、ID プロバイダーとのフェデレーションを使用する必要があります。
*フェデレーティッド ID* は、エンタープライズディレクトリ、ウェブ ID プロバイダー、または ID Directory Service ソースの認証情報 AWS のサービス を使用して にアクセスするユーザーです。フェデレーテッドアイデンティティは、一時的な認証情報を提供するロールを引き受けます。
アクセスを一元管理する場合は、 AWS IAM アイデンティティセンターをお勧めします。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[IAM アイデンティティセンターとは](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。
### IAM ユーザーとグループ
*[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、特定の個人やアプリケーションに対する特定のアクセス許可を持つアイデンティティです。長期認証情報を持つ IAM ユーザーの代わりに一時的な認証情報を使用することをお勧めします。詳細については、*IAM ユーザーガイド*の[「ID プロバイダーとのフェデレーションを使用して にアクセスする必要がある AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、IAM ユーザーの集合を指定し、大量のユーザーに対するアクセス許可の管理を容易にします。詳細については、「*IAM ユーザーガイド*」の「[IAM ユーザーに関するユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)」を参照してください。
### IAM ロール
*[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*は、特定のアクセス許可を持つアイデンティであり、一時的な認証情報を提供します。ユーザー[から IAM ロール (コンソール) に切り替えるか、 または API オペレーションを呼び出すことで、ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)を引き受けることができます。 AWS CLI AWS 詳細については、「*IAM ユーザーガイド*」の「[ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)」を参照してください。
IAM ロールは、フェデレーションユーザーアクセス、一時的な IAM ユーザーのアクセス許可、クロスアカウントアクセス、クロスサービスアクセス、および Amazon EC2 で実行するアプリケーションに役立ちます。詳細については、*IAM ユーザーガイド* の [IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
## ポリシーを使用したアクセスの管理
でアクセスを制御する AWS には、ポリシーを作成し、ID AWS またはリソースにアタッチします。ポリシーは、ID またはリソースに関連付けられたときにアクセス許可を定義します。 は、プリンシパルがリクエストを行うときにこれらのポリシー AWS を評価します。ほとんどのポリシーは JSON ドキュメント AWS として に保存されます。JSON ポリシードキュメントの詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。
管理者は、ポリシーを使用して、どの**プリンシパル**がどの**リソース**に対して、どのような**条件**で**アクション**を実行できるかを定義することで、誰が何にアクセスできるかを指定します。
デフォルトでは、ユーザーやロールにアクセス許可はありません。IAM 管理者は IAM ポリシーを作成してロールに追加し、このロールをユーザーが引き受けられるようにします。IAM ポリシーは、オペレーションの実行方法を問わず、アクセス許可を定義します。
### アイデンティティベースのポリシー
アイデンティティベースのポリシーは、アイデンティティ (ユーザー、グループ、またはロール) にアタッチできる JSON アクセス許可ポリシードキュメントです。これらのポリシーは、アイデンティティがどのリソースに対してどのような条件下でどのようなアクションを実行できるかを制御します。アイデンティティベースポリシーの作成方法については、*IAM ユーザーガイド* の [カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) を参照してください。
アイデンティティベースのポリシーは、*インラインポリシー* (単一の ID に直接埋め込む) または*管理ポリシー* (複数の ID にアタッチされたスタンドアロンポリシー) にすることができます。管理ポリシーとインラインポリシーのいずれかを選択する方法については、「*IAM ユーザーガイド*」の「[管理ポリシーとインラインポリシーのいずれかを選択する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)」を参照してください。
### リソースベースのポリシー
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。例としては、IAM *ロール信頼ポリシー*や Amazon S3 *バケットポリシー*などがあります。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。リソースベースのポリシーでは、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。
リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーでは、IAM の AWS マネージドポリシーを使用できません。
### その他のポリシータイプ
AWS は、より一般的なポリシータイプによって付与されるアクセス許可の最大数を設定できる追加のポリシータイプをサポートしています。
+ **アクセス許可の境界** – アイデンティティベースのポリシーで IAM エンティティに付与することのできるアクセス許可の数の上限を設定します。詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティのアクセス許可境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
+ **サービスコントロールポリシー (SCP)** - AWS Organizations内の組織または組織単位の最大のアクセス許可を指定します。詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
+ **リソースコントロールポリシー (RCP)** – は、アカウント内のリソースで利用できる最大数のアクセス許可を定義します。詳細については、「*AWS Organizations ユーザーガイド*」の「[リソースコントロールポリシー (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)」を参照してください。
+ **セッションポリシー** – ロールまたはフェデレーションユーザーの一時セッションを作成する際にパラメータとして渡される高度なポリシーです。詳細については、「*IAM ユーザーガイド*」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。
### 複数のポリシータイプ
1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに難しくなります。が複数のポリシータイプが関与する場合にリクエストを許可するかどうか AWS を決定する方法については、*「IAM ユーザーガイド*」の[「ポリシー評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)」を参照してください。
# MemoryDB と IAM の連携の仕組み
IAM を使用して MemoryDB へのアクセスを管理する前に、MemoryDB で利用できる IAM の機能について学びます。
**MemoryDB で使用できる IAM の機能**
| IAM 機能 | MemoryDB サポート |
| --- | --- |
| [アイデンティティベースのポリシー](#security_iam_service-with-iam-id-based-policies) | あり |
| [リソースベースのポリシー](#security_iam_service-with-iam-resource-based-policies) | なし |
| [ポリシーアクション](#security_iam_service-with-iam-id-based-policies-actions) | あり |
| [ポリシーリソース](#security_iam_service-with-iam-id-based-policies-resources) | あり |
| [ポリシー条件キー](#security_iam_service-with-iam-id-based-policies-conditionkeys) | あり |
| [ACL](#security_iam_service-with-iam-acls) | はい |
| [ABAC (ポリシー内のタグ)](#security_iam_service-with-iam-tags) | あり |
| [一時的な認証情報](#security_iam_service-with-iam-roles-tempcreds) | あり |
| [プリンシパルアクセス権限](#security_iam_service-with-iam-principal-permissions) | あり |
| [サービスロール](#security_iam_service-with-iam-roles-service) | あり |
| [サービスリンクロール](#security_iam_service-with-iam-roles-service-linked) | はい |
MemoryDB およびその他の AWS のサービスがほとんどの IAM 機能と連携する方法の概要については、IAM *ユーザーガイド*の[AWS 「IAM と連携する のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
## MemoryDB のアイデンティティベースのポリシー
**アイデンティティベースのポリシーのサポート:** あり
アイデンティティベースポリシーは、IAM ユーザー、ユーザーグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースポリシーの作成方法については、「*IAM ユーザーガイド*」の「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
IAM アイデンティティベースのポリシーでは、許可または拒否するアクションとリソース、およびアクションを許可または拒否する条件を指定できます。JSON ポリシーで使用できるすべての要素について学ぶには、「*IAM ユーザーガイド*」の「[IAM JSON ポリシーの要素のリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。
### MemoryDB のアイデンティティベースのポリシーの例
MemoryDB アイデンティティベースのポリシーの例を表示するには、「[MemoryDB のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。
## MemoryDB 内のリソースベースのポリシー
**リソースベースのポリシーのサポート:** なし
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM *ロールの信頼ポリシー*や Amazon S3 *バケットポリシー*があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または を含めることができます AWS のサービス。
クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、リソースベースのポリシーのプリンシパルとして指定します。詳細については、IAM ユーザーガイド**の[IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)を参照してください。
## MemoryDB のポリシーアクション
**ポリシーアクションのサポート:** あり
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。
MemoryDB アクションのリストを確認するには、「*サービス認可リファレンス*」の「[Actions Defined by MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-actions-as-permissions)」を参照してください。
MemoryDB のポリシーアクションは、アクションの前に以下のプレフィックスを使用します。
```
MemoryDB
```
単一のステートメントで複数のアクションを指定するには、アクションをカンマで区切ります。
```
"Action": [
"MemoryDB:action1",
"MemoryDB:action2"
]
```
ワイルドカード (\$1) を使用して複数アクションを指定できます。例えば、`Describe` という単語で始まるすべてのアクションを指定するには次のアクションを含めます。
```
"Action": "MemoryDB:Describe*"
```
MemoryDB アイデンティティベースのポリシーの例を表示するには、「[MemoryDB のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。
## MemoryDB のポリシーリソース
**ポリシーリソースのサポート:** あり
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件**下で**アクション**を実行できるかということです。
`Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルのアクセス許可をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (\$1) を使用します。
```
"Resource": "*"
```
MemoryDB のリソースタイプとその ARN のリストを確認するには、「*サービス認可リファレンス*」の「[Resources Defined by MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-resources-for-iam-policies)」。どのアクションで各リソースの ARN を指定できるかについては、「[Actions Defined by MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-actions-as-permissions)」を参照してください。
MemoryDB アイデンティティベースのポリシーの例を表示するには、「[MemoryDB のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。
## MemoryDB のポリシー条件キー
**サービス固有のポリシー条件キーのサポート:** あり
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
`Condition` 要素は、定義された基準に基づいてステートメントが実行される時期を指定します。イコールや未満などの[条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)を使用して条件式を作成して、ポリシーの条件とリクエスト内の値を一致させることができます。すべての AWS グローバル条件キーを確認するには、*「IAM ユーザーガイド*」の[AWS 「グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
MemoryDB アイデンティティベースのポリシーの例を表示するには、「[MemoryDB のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。
### 条件キーの使用
IAM ポリシーを有効にする方法を決める条件を指定できます。MemoryDB では、JSON ポリシーの `Condition` 要素を使用して、リクエストコンテキストのキーを、ポリシーで指定したキー値と比較できます。ポリシー要素の詳細については、[IAM JSON policy elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) を参照してください。
MemoryDB の条件キーのリストを確認するには、「*サービス認可リファレンス*」の「[MemoryDB の条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-policy-keys)」を参照してください。
グローバル条件キーのリストについては、「[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
#### 条件の指定: 条件キーの使用
きめ細かなコントロールを実装するには、特定のリクエストに対して個別のパラメータセットを制御するための条件を指定した IAM アクセス許可ポリシーを作成します。次に、IAM コンソールを使用して作成する IAM ユーザー、グループ、またはロールにそのポリシーを適用できます。
条件を適用するには、条件情報を IAM ポリシーステートメントに追加します。例えば、TLS が無効になっている MemoryDB クラスターの作成を禁止するには、ポリシーステートメントで次の条件を指定できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"memorydb:CreateCluster"
],
"Resource": [
"*"
],
"Condition": {
"Bool": {
"memorydb:TLSEnabled": "false"
}
}
}
]
}
```
------
タグ付けの詳細については、「[MemoryDB リソースのタグ付け](tagging-resources.md)」を参照してください。
ポリシー条件演算子の使用に関する詳細については、「[MemoryDB API の許可: アクション、リソース、条件リファレンス](iam.APIReference.md)」を参照してください。
#### ポリシー例: きめ細かなパラーメータコントロールのための IAM ポリシー条件の使用
このセクションでは、前述の MemoryDB パラメータに対してきめ細かなアクセスコントロールを実装するためのポリシー例について説明します。
1. **memorydb:TLSEnabled** - TLS を有効にした場合にのみクラスターを作成するように指定します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster"
],
"Resource": [
"arn:aws:memorydb:*:*:parametergroup/*",
"arn:aws:memorydb:*:*:subnetgroup/*",
"arn:aws:memorydb:*:*:acl/*"
]
},
{
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster"
],
"Resource": [
"*"
],
"Condition": {
"Bool": {
"memorydb:TLSEnabled": "true"
}
}
}
]
}
```
------
1. **memorydb:UserAuthenticationMode:** - 特定のタイプ認証モード (IAM など) でユーザーを作成できるように指定します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"memorydb:Createuser"
],
"Resource": [
"arn:aws:memorydb:*:*:user/*"
],
"Condition": {
"StringEquals": {
"memorydb:UserAuthenticationMode": "iam"
}
}
}
]
}
```
------
「Deny」ベースのポリシーを設定する場合は、[StringEqualsIgnoreCase](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_String) 演算子を使用して、ケースに関係なく、特定のユーザー認証モードタイプのすべての呼び出しを回避することをお勧めします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"memorydb:CreateUser"
],
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {
"memorydb:UserAuthenticationMode": "password"
}
}
}
]
}
```
------
## MemoryDB のアクセスコントロールリスト (ACL)
**ACL のサポート:** あり
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
## MemoryDB での属性ベースのアクセスコントロール (ABAC)
**ABAC (ポリシー内のタグ) のサポート:** あり
属性ベースのアクセス制御 (ABAC) は、タグと呼ばれる属性に基づいてアクセス許可を定義する認可戦略です。IAM エンティティと AWS リソースにタグをアタッチし、プリンシパルのタグがリソースのタグと一致するときにオペレーションを許可するように ABAC ポリシーを設計できます。
タグに基づいてアクセスを管理するには、`aws:ResourceTag/key-name`、`aws:RequestTag/key-name`、または `aws:TagKeys` の条件キーを使用して、ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)でタグ情報を提供します。
サービスがすべてのリソースタイプに対して 3 つの条件キーすべてをサポートする場合、そのサービスの値は**あり**です。サービスが一部のリソースタイプに対してのみ 3 つの条件キーのすべてをサポートする場合、値は「**部分的**」になります。
ABAC の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可でアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。ABAC をセットアップする手順を説明するチュートリアルについては、「*IAM ユーザーガイド*」の「[属性ベースのアクセスコントロール (ABAC) を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)」を参照してください。
## MemoryDB での一時的な認証情報の使用
**一時的な認証情報のサポート:** あり
一時的な認証情報は AWS 、リソースへの短期的なアクセスを提供し、フェデレーションまたはスイッチロールの使用時に自動的に作成されます。長期的なアクセスキーを使用する代わりに、一時的な認証情報を動的に生成 AWS することをお勧めします。詳細については、「*IAM ユーザーガイド*」の「[IAM の一時的な認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)」および「[AWS のサービス と IAM との連携](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
## MemoryDB のクロスサービスプリンシパル許可
**転送アクセスセッション (FAS) のサポート:** あり
転送アクセスセッション (FAS) は、 を呼び出すプリンシパルのアクセス許可と AWS のサービス、ダウンストリームサービス AWS のサービス へのリクエストをリクエストする を使用します。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。
## MemoryDB のサービスロール
**サービスロールのサポート:** あり
サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、IAM ユーザーガイド**の [AWS のサービスに許可を委任するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)を参照してください。
**警告**
サービスロールの許可を変更すると、MemoryDB の機能が破損する可能性があります。MemoryDB が指示する場合以外は、サービスロールを編集しないでください。
## MemoryDB 用のサービスリンクロール
**サービスリンクロールのサポート:** あり
サービスにリンクされたロールは、 にリンクされたサービスロールの一種です AWS のサービス。サービスは、ユーザーに代わってアクションを実行するロールを引き受けることができます。サービスにリンクされたロールは に表示され AWS アカウント 、サービスによって所有されます。IAM 管理者は、サービスにリンクされたロールのアクセス許可を表示できますが、編集することはできません。
サービスにリンクされたロールの作成または管理の詳細については、「[IAM と提携するAWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。表の「**サービスリンクロール**」列に `Yes` と記載されたサービスを見つけます。サービスにリンクされたロールに関するドキュメントをサービスで表示するには、**[はい]** リンクを選択します。
# MemoryDB のアイデンティティベースのポリシーの例
デフォルトでは、ユーザーおよびロールには、MemoryDB またはリソースを作成または変更するアクセス許可はありません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。
これらのサンプルの JSON ポリシードキュメントを使用して IAM アイデンティティベースのポリシーを作成する方法については、「*IAM ユーザーガイド*」の「[IAM ポリシーを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)」を参照してください。
MemoryDB が定義するアクションとリソースタイプ (リソースタイプごとの ARN の形式を含む) の詳細については、「*サービス認可リファレンス*」の「[MemoryDB のアクション、リソース、および条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html)」を参照してください。
**Topics**
+ [
## ポリシーに関するベストプラクティス
](#security_iam_service-with-iam-policy-best-practices)
+ [
## MemoryDB コンソールの使用
](#security_iam_id-based-policy-examples-console)
+ [
## 自分の権限の表示をユーザーに許可する
](#security_iam_id-based-policy-examples-view-own-permissions)
## ポリシーに関するベストプラクティス
ID ベースのポリシーは、ユーザーのアカウントで誰かが MemoryDB リソースを作成、アクセス、または削除できるどうかを決定します。これらのアクションでは、 AWS アカウントに費用が発生する場合があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください:
+ ** AWS 管理ポリシーを開始し、最小特権のアクセス許可に移行する** – ユーザーとワークロードにアクセス許可の付与を開始するには、多くの一般的なユースケースにアクセス許可を付与する*AWS 管理ポリシー*を使用します。これらは で使用できます AWS アカウント。ユースケースに固有の AWS カスタマー管理ポリシーを定義することで、アクセス許可をさらに減らすことをお勧めします。詳細については、*IAM ユーザーガイド* の [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) または [ジョブ機能のAWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) を参照してください。
+ **最小特権を適用する** – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、最小特権アクセス許可とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、*IAM ユーザーガイド* の [IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。
+ **IAM ポリシーで条件を使用してアクセスをさらに制限する** - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。たとえば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。条件を使用して、サービスアクションが などの特定の を通じて使用されている場合に AWS のサービス、サービスアクションへのアクセスを許可することもできます CloudFormation。詳細については、*IAM ユーザーガイド* の [IAM JSON ポリシー要素:条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) を参照してください。
+ **IAM アクセスアナライザー を使用して IAM ポリシーを検証し、安全で機能的な権限を確保する** - IAM アクセスアナライザー は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、*IAM ユーザーガイド* の [IAM Access Analyzer でポリシーを検証する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) を参照してください。
+ **多要素認証 (MFA) を要求する** – で IAM ユーザーまたはルートユーザーを必要とするシナリオがある場合は AWS アカウント、MFA をオンにしてセキュリティを強化します。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、*IAM ユーザーガイド* の [MFA を使用した安全な API アクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) を参照してください。
IAM でのベストプラクティスの詳細については、*IAM ユーザーガイド* の [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) を参照してください。
## MemoryDB コンソールの使用
MemoryDB コンソールにアクセスするには、最小限の許可セットが必要です。これらのアクセス許可により、 の MemoryDB リソースの詳細を一覧表示および表示できます AWS アカウント。最小限必要な許可よりも制限が厳しいアイデンティティベースのポリシーを作成すると、そのポリシーを持つエンティティ (ユーザーまたはロール) に対してコンソールが意図したとおりに機能しません。
AWS CLI または AWS API のみを呼び出すユーザーには、最小限のコンソールアクセス許可を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスが許可されます。
ユーザーとロールが引き続き MemoryDB コンソールを使用できるようにするには、MemoryDB `ConsoleAccess`または `ReadOnly` AWS 管理ポリシーもエンティティにアタッチします。詳細については、「*IAM ユーザーガイド*」の「[ユーザーへのアクセス許可の追加](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)」を参照してください。
## 自分の権限の表示をユーザーに許可する
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を IAM ユーザーに許可するポリシーの作成方法を示します。このポリシーには、コンソールで、または AWS CLI または AWS API を使用してプログラムでこのアクションを実行するアクセス許可が含まれています。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# MemoryDB のアイデンティティとアクセスの問題のトラブルシューティング
次の情報は、MemoryDB と IAM を使用する際に発生する可能性がある一般的な問題の診断や修復に役立ちます。
**Topics**
+ [
## MemoryDB でアクションを実行する権限がない
](#security_iam_troubleshoot-no-permissions)
+ [
## iam:PassRole を実行する権限がない
](#security_iam_troubleshoot-passrole)
+ [
## AWS アカウント外のユーザーに MemoryDB リソースへのアクセスを許可したい
](#security_iam_troubleshoot-cross-account-access)
## MemoryDB でアクションを実行する権限がない
にアクションを実行する権限がないと AWS マネジメントコンソール 通知された場合は、管理者に連絡してサポートを依頼する必要があります。担当の管理者はお客様のユーザー名とパスワードを発行した人です。
以下のエラー例は、`mateojackson` ユーザーがコンソールを使用して架空の `my-example-widget` リソースに関する詳細情報を表示しようとしているが、架空の `MemoryDB:GetWidget` 許可がないという場合に発生します。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: MemoryDB:GetWidget on resource: my-example-widget
```
この場合、Mateo は、`MemoryDB:GetWidget` アクションを使用して `my-example-widget` リソースにアクセスできるように、管理者にポリシーの更新を依頼します。
## iam:PassRole を実行する権限がない
`iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して MemoryDB にロールを渡すことができるようにする必要があります。
一部の AWS のサービス では、新しいサービスロールまたはサービスにリンクされたロールを作成する代わりに、既存のロールをそのサービスに渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。
以下の例のエラーは、`marymajor` という IAM ユーザーがコンソールを使用して MemoryDB でアクションを実行しようする場合に発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与されたアクセス許可が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、Mary のポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。
サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン資格情報を提供した担当者が管理者です。
## AWS アカウント外のユーザーに MemoryDB リソースへのアクセスを許可したい
他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。
詳細については、以下を参照してください:
+ MemoryDB でこれらの機能がサポートされるかどうかを確認するには、「[MemoryDB と IAM の連携の仕組み](security_iam_service-with-iam.md)」を参照してください。
+ 所有 AWS アカウント している のリソースへのアクセスを提供する方法については、[「IAM ユーザーガイド」の「所有 AWS アカウント している別の の IAM ユーザーへのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)」を参照してください。 **
+ リソースへのアクセスをサードパーティーに提供する方法については AWS アカウント、*IAM ユーザーガイド*の[「サードパーティー AWS アカウント が所有する へのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)」を参照してください。
+ ID フェデレーションを介してアクセスを提供する方法については、*IAM ユーザーガイド* の [外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) を参照してください。
+ クロスアカウントアクセスにおけるロールとリソースベースのポリシーの使用方法の違いについては、*IAM ユーザーガイド* の [IAM でのクロスアカウントのリソースへのアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
## アクセスコントロール
有効な認証情報があればリクエストを認証できますが、アクセス許可が付与されている場合を除き、MemoryDB リソースの作成やアクセスはできません。例えば、MemoryDB クラスターを作成するためのアクセス権限が必要です。
次のセクションでは、MemoryDB の許可を管理する方法について説明します。最初に概要のセクションを読むことをお勧めします。
+ [MemoryDB リソースに対する許可の管理の概要](iam.overview.md)
+ [MemoryDB でのアイデンティティベースのポリシー (IAM ポリシー) の使用](iam.identitybasedpolicies.md)
# MemoryDB リソースに対する許可の管理の概要
すべての AWS リソースは AWS アカウントによって所有され、リソースを作成またはアクセスするためのアクセス許可はアクセス許可ポリシーによって管理されます。アカウント管理者は、IAM アイデンティティ (つまり、ユーザー、グループ、ロール) に許可ポリシーをアタッチできます。さらに、MemoryDB では、アクセス許可ポリシーをリソースにアタッチすることもできます。
**注記**
*アカウント管理者* (または管理者ユーザー) は、管理者権限を持つユーザーです。詳細については、「*IAM ユーザーガイド*」の「[IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。
アクセスを提供するには、ユーザー、グループ、またはロールにアクセス許可を追加します。
+ 以下のユーザーとグループ AWS IAM アイデンティティセンター:
アクセス許可セットを作成します。「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[アクセス許可セットを作成する](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html)」の手順に従ってください。
+ IAM 内で、ID プロバイダーによって管理されているユーザー:
ID フェデレーションのロールを作成します。詳細については *IAM ユーザーガイド* の [サードパーティー ID プロバイダー (フェデレーション) 用のロールを作成する](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) を参照してください。
+ IAM ユーザー:
+ ユーザーが担当できるロールを作成します。手順については *IAM ユーザーガイド* の [IAM ユーザーのロールの作成](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) を参照してください。
+ (お奨めできない方法) ポリシーをユーザーに直接アタッチするか、ユーザーをユーザーグループに追加します。*IAM ユーザーガイド* の [ユーザー (コンソール) へのアクセス許可の追加](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) の指示に従います。
**Topics**
+ [
## MemoryDB リソースおよびオペレーション
](#iam.overview.resourcesandoperations)
+ [
## リソース所有権についての理解
](#access-control-resource-ownership)
+ [
## リソースへのアクセスの管理
](#iam.overview.managingaccess)
+ [
# MemoryDB でのアイデンティティベースのポリシー (IAM ポリシー) の使用
](iam.identitybasedpolicies.md)
+ [
# リソースレベルのアクセス許可
](iam.resourcelevelpermissions.md)
+ [
# MemoryDB 用のサービスリンクロール
](using-service-linked-roles.md)
+ [
# AWS MemoryDB の マネージドポリシー
](security-iam-awsmanpol.md)
+ [
# MemoryDB API の許可: アクション、リソース、条件リファレンス
](iam.APIReference.md)
## MemoryDB リソースおよびオペレーション
MemoryDB では、プライマリリソースは*クラスター*です。
これらのリソースには、以下に示すとおり、一意の Amazon リソースネーム (ARN) が関連付けられています。
**注記**
リソースレベルのアクセス許可を有効にするには、ARN 文字列のリソース名を小文字にする必要があります。
****
| リソースタイプ | ARN 形式 |
| --- | --- |
| ユーザー | arn:aws:memorydb:*us-east-1:123456789012*:user/user1 |
| アクセスコントロールリスト (ACL) | arn:aws:memorydb:*us-east-1:123456789012*:acl/myacl |
| クラスター | arn:aws:memorydb:*us-east-1:123456789012*:cluster/my-cluster |
| Snapshot | arn:aws:memorydb:*us-east-1:123456789012*:snapshot/my-snapshot |
| パラメータグループ | arn:aws:memorydb:*us-east-1:123456789012*:parametergroup/my-parameter-group |
| サブネットグループ | arn:aws:memorydb:*us-east-1:123456789012*:subnetgroup/my-subnet-group |
MemoryDB では、MemoryDB リソースを操作する一連のオペレーションが用意されています。可能なオペレーションのリストについては、MemoryDB「[アクション](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_Operations.html)」を参照してください。
## リソース所有権についての理解
*リソース所有者*は、リソースを作成した AWS アカウントです。つまり、リソース所有者は、リソースを作成するリクエストを認証するプリンシパルエンティティの AWS アカウントです。*プリンシパルエンティティ* はルートアカウント、IAM ユーザー、または IAM ロールです。次の例は、この仕組みを示しています。
+ AWS アカウントのルートアカウントの認証情報を使用してクラスターを作成するとします。この場合、 AWS アカウントはリソースの所有者です。MemoryDB では、リソースはクラスターです。
+ AWS アカウントに IAM ユーザーを作成し、そのユーザーにクラスターを作成するアクセス許可を付与するとします。この場合、ユーザーはクラスターを作成できます。ただし、ユーザーが属する AWS アカウントはクラスターリソースを所有します。
+ クラスターを作成するアクセス許可を持つ IAM ロールを AWS アカウントに作成するとします。この場合、ロールを引き受けることができるいずれのユーザーもクラスターを作成できます。ロールが属する AWS アカウントは、クラスターリソースを所有します。
## リソースへのアクセスの管理
*アクセス権限ポリシー* では、誰が何にアクセスできるかを記述します。以下のセクションで、アクセス許可ポリシーを作成するために使用可能なオプションについて説明します。
**注記**
このセクションでは、MemoryDB のコンテキストでの IAM の使用について説明します。ここでは、IAM サービスに関する詳細情報を提供しません。完全な IAM ドキュメンテーションについては、「*IAM ユーザーガイド*」の「[IAM とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」を参照してください。IAM ポリシー構文の詳細と説明については、*IAM ユーザーガイド*の [AWS IAM ポリシーの参照](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html)を参照してください。
IAM アイデンティティにアタッチされているポリシーは、*アイデンティティベース*のポリシー (IAM ポリシー) と呼ばれます。リソースに添付されたポリシーは、リソースベースのポリシーと呼ばれます。
**Topics**
+ [
### アイデンティティベースのポリシー (IAM ポリシー）
](#iam.overview.managingaccess.identitybasedpolicies)
+ [
### ポリシー要素の指定: アクション、効果、リソース、プリンシパル
](#iam.overview.policyelements)
+ [
### ポリシーでの条件の指定
](#iam.specifyconditions)
### アイデンティティベースのポリシー (IAM ポリシー）
ポリシーを IAM アイデンティティにアタッチできます。例えば、次のオペレーションを実行できます。
+ **アカウントのユーザーまたはグループにアクセス許可ポリシーをアタッチする** – アカウント管理者は、特定のユーザーに関連付けられるアクセス許可ポリシーを使用して、アクセス許可を付与できます。この場合、アクセス許可は、そのユーザーがクラスター、パラメータグループ、セキュリティグループなどの MemoryDB リソースを作成するためのものです。
+ **アクセス権限ポリシーをロールにアタッチする (クロスアカウントの許可を付与)** - ID ベースのアクセス権限ポリシーを IAM ロールにアタッチして、クロスアカウントの権限を付与することができます。たとえば、アカウント A の管理者は、次のように別の AWS アカウント (アカウント B など) または AWS サービスにクロスアカウントアクセス許可を付与するロールを作成できます。
1. アカウント A の管理者は、IAM ロールを作成して、アカウント A のリソースに許可を付与するロールに許可ポリシーをアタッチします。
1. アカウント A の管理者は、アカウント B をそのロールを引き受けるプリンシパルとして識別するロールに、信頼ポリシーをアタッチします。
1. アカウント B の管理者は、アカウント B の任意のユーザーにロールを引き受けるアクセス許可を委任できます。これにより、アカウント B のユーザーがアカウント A のリソースを作成またはアクセスできるようになります。場合によっては、ロールを引き受けるアクセス許可を AWS サービスに付与することもできます。このアプローチをサポートするために、信頼ポリシーのプリンシパルを AWS のサービスのプリンシパルにすることもできます。
IAM を使用した許可の委任の詳細については、「IAM ユーザーガイド」の「[アクセス管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html)」を参照してください。
以下は、ユーザーが AWS アカウントの `DescribeClusters`アクションを実行できるようにするポリシーの例です。MemoryDB では、API アクションのリソース ARN を使用した特定のリソースの識別もサポートしています。(このアプローチは、リソースレベルのアクセス許可とも呼ばれます)。
でアイデンティティベースのポリシーを使用する場合の詳細については、MemoryDB「[MemoryDB でのアイデンティティベースのポリシー (IAM ポリシー) の使用](iam.identitybasedpolicies.md)」を参照してください。ユーザー、グループ、ロール、アクセス許可の詳細については、*IAM ユーザーガイド*の「[アイデンティティ (ユーザー、グループ、ロール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)」を参照してください。
### ポリシー要素の指定: アクション、効果、リソース、プリンシパル
サービスは、MemoryDB リソースごとに ([MemoryDB リソースおよびオペレーション](#iam.overview.resourcesandoperations)を参照)、一連の API オペレーションを定義します ([アクション](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_Operations.html)を参照)。こうした API オペレーションへの許可を付与するために、MemoryDB はポリシーに定義できる一連のアクションを定義します。例えば、MemoryDB クラスターリソースに対して、アクション `CreateCluster`、`DeleteCluster`、`DescribeClusters` を定義します。1 つの API オペレーションの実行で、複数のアクションのアクセス権限が必要になる場合があります。
最も基本的なポリシーの要素を次に示します。
+ **リソース**– ポリシーで Amazon リソースネーム (ARN) を使用して、ポリシーを適用するリソースを識別します。詳細については、「[MemoryDB リソースおよびオペレーション](#iam.overview.resourcesandoperations)」を参照してください。
+ **アクション** – アクションキーワードを使用して、許可または拒否するリソース操作を特定します。例えば、指定した `Effect` に応じて、`memorydb:CreateCluster` アクセス権限では、MemoryDB `CreateCluster` オペレーションの実行をユーザーに許可または拒否します。
+ **効果** – ユーザーが特定のアクションを要求する際の効果を指定します。許可または拒否のいずれかになります。リソースへのアクセスを明示的に付与 (許可) していない場合、アクセスは暗黙的に拒否されます。リソースへのアクセスを明示的に拒否することもできます。例えば、別のポリシーでリソースへのアクセスが許可されているユーザーに対して、そのリソースへのアクセスを禁止できます。
+ **プリンシパル** - ID ベースのポリシー (IAM ポリシー) で、ポリシーがアタッチされているユーザーが黙示的なプリンシパルとなります。リソースベースのポリシーでは、アクセス許可 (リソースベースのポリシーにのみ適用) を受け取りたいユーザー、アカウント、サービス、またはその他のエンティティを指定します。
IAM ポリシー構文の詳細と説明については、*IAM ユーザーガイド*の「[AWS IAM ポリシーリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html)」を参照してください。
すべての MemoryDB API アクションを示す表については、「[MemoryDB API の許可: アクション、リソース、条件リファレンス](iam.APIReference.md)」を参照してください。
### ポリシーでの条件の指定
許可を付与するとき、IAM ポリシー言語を使用して、ポリシーが有効になる必要がある条件を指定できます。例えば、特定の日付の後にのみ適用されるポリシーが必要になる場合があります。ポリシー言語での条件の指定の詳細については、「*IAM ユーザーガイド*」の「[条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition)」を参照してください。
# MemoryDB でのアイデンティティベースのポリシー (IAM ポリシー) の使用
このトピックでは、アカウント管理者が IAM ID (ユーザー、グループ、ロール) へのアクセス許可ポリシーをアタッチする、ID ベースのポリシーの例を示します。
**重要**
最初に、MemoryDB リソースへのアクセスを管理するための基本的な概念とオプションについて説明するトピックを読むことをお勧めします。詳細については、「[MemoryDB リソースに対する許可の管理の概要](iam.overview.md)」を参照してください。
このセクションでは、次のトピックを対象としています。
+ [MemoryDB コンソールの使用に必要なアクセス権限](#iam.identitybasedpolicies.minconpolicies)
+ [MemoryDB のAWS管理 (事前定義) ポリシー](security-iam-awsmanpol.md#iam.identitybasedpolicies.predefinedpolicies)
+ [カスタマーマネージドポリシーの例](#iam.identitybasedpolicies.customermanagedpolicies)
以下に示しているのは、アクセス許可ポリシーの例です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "AllowClusterPermissions",
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster",
"memorydb:DescribeClusters",
"memorydb:UpdateCluster"],
"Resource": "*"
},
{
"Sid": "AllowUserToPassRole",
"Effect": "Allow",
"Action": [ "iam:PassRole" ],
"Resource": "arn:aws:iam::123456789012:role/EC2-roles-for-cluster"
}
]
}
```
------
このポリシーには以下の 2 つのステートメントがあります。
+ 最初のステートメントは、アカウントが所有するクラスター上の MemoryDB アクション (`memorydb:CreateCluster`、`memorydb:DescribeClusters`、`memorydb:UpdateCluster`) のアクセス権限を付与します。
+ 2 番目のステートメントは、`Resource` 値の最後に指定した IAM ロール名での IAM アクション`iam:PassRole`のアクセス許可を付与します。
ID ベースのポリシーでアクセス許可を得るプリンシパルを指定していないため、ポリシーでは `Principal` 要素を指定していません。ユーザーにポリシーをアタッチすると、そのユーザーが暗黙のプリンシパルになります。IAM ロールにアクセス権限ポリシーをアタッチすると、ロールの信頼ポリシーで識別されたプリンシパルがアクセス権限を得ることになります。
すべての MemoryDB API アクションとそれらが適用されるリソースの表については、「[MemoryDB API の許可: アクション、リソース、条件リファレンス](iam.APIReference.md)」を参照してください。
## MemoryDB コンソールの使用に必要なアクセス権限
アクセス権限のリファレンス表では、MemoryDB API オペレーションとそれらの各オペレーションに必要なアクセス権限を示しています。MemoryDB API オペレーションの詳細については、「[MemoryDB API の許可: アクション、リソース、条件リファレンス](iam.APIReference.md)」を参照してください。
MemoryDB コンソールを使用するには、まず、以下のアクセス権限ポリシーに示しているように、追加のアクションのためのアクセス権限を付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "MinPermsForMemDBConsole",
"Effect": "Allow",
"Action": [
"memorydb:Describe*",
"memorydb:List*",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeVpcs",
"ec2:DescribeAccountAttributes",
"ec2:DescribeSecurityGroups",
"cloudwatch:GetMetricStatistics",
"cloudwatch:DescribeAlarms",
"s3:ListAllMyBuckets",
"sns:ListTopics",
"sns:ListSubscriptions" ],
"Resource": "*"
}
]
}
```
------
MemoryDB コンソールには、以下の理由でこれらの追加のアクセス権限が必要になります。
+ MemoryDB アクションを実行するためのアクセス権限。コンソールで、アカウントの MemoryDB リソースを表示するために必要です。
+ Amazon EC2 に対してクエリを行う `ec2` アクションを実行するためのアクセス権限。コンソールで、アベイラビリティーゾーン、VPC、セキュリティグループ、アカウント属性を表示するために必要です。
+ `cloudwatch` アクションを実行するためのアクセス許可。コンソールで、Amazon CloudWatch メトリクスとアラームを取得し、表示するために必要です。
+ `sns` アクションのアクセス許可を使用すると、Amazon Simple Notification Service (Amazon SNS) のトピックやサブスクリプションを取得し、コンソールにそれらを表示することができます。
## カスタマーマネージドポリシーの例
デフォルトポリシーを使用せず、カスタムマネージドポリシーを使用することを選択した場合は、以下の 2 点のいずれかを確認してください。`iam:createServiceLinkedRole` を呼び出すためのアクセス許可があることが必要です (詳細については、「[例 4: ユーザーが IAM CreateServiceLinkedRole API を呼び出すことを許可する](#create-service-linked-role-policy)」を参照)。または、MemoryDB サービスにリンクされたロールを作成済みであることが必要です。
MemoryDB コンソールを使用するために必要な最小限のアクセス権限と組み合わせて、このセクションでのポリシーの例は、追加のアクセス権限を付与します。これらの例は、 AWS SDKsと にも関連しています AWS CLI。MemoryDB コンソールを使用するために必要なアクセス権限の詳細については、「[MemoryDB コンソールの使用に必要なアクセス権限](#iam.identitybasedpolicies.minconpolicies)」を参照してください。
IAM ユーザーおよびグループのセットアップ手順については、*IAM ユーザーガイド*の「[最初の IAM ユーザーおよび管理者グループの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html)」を参照してください。
**重要**
IAM ポリシーは必ず、本稼働環境での使用前にテストしてください。MemoryDB のアクションによっては、シンプルに見えても、MemoryDB コンソールの使用時にそれらのアクションをサポートするために、他のアクションが必要になる場合があります。例えば、`memorydb:CreateCluster` は、 MemoryDBクラスターを作成するためのアクセス権限を付与します。ただし、このオペレーションを実行するために、 MemoryDB コンソールでは `Describe` と `List` の多数のアクションが使用されて、リストが事前設定されます。
**Topics**
+ [
### 例 1: MemoryDB リソースへの読み取り専用アクセスをユーザーに許可する
](#example-allow-list-current-memorydb-resources)
+ [
### 例 2: ユーザーに一般的な MemoryDB システム管理者タスクの実行を許可する
](#example-allow-specific-memorydb-actions)
+ [
### 例 3: ユーザーにすべての MemoryDB API アクションへのアクセスを許可する
](#allow-unrestricted-access)
+ [
### 例 4: ユーザーが IAM CreateServiceLinkedRole API を呼び出すことを許可する
](#create-service-linked-role-policy)
### 例 1: MemoryDB リソースへの読み取り専用アクセスをユーザーに許可する
以下のポリシーでは、リソースを一覧表示する MemoryDB アクションを実行するためのアクセス権限をユーザーに付与します。通常、このタイプのアクセス権限ポリシーは管理者グループにアタッチします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Sid": "MemDBUnrestricted",
"Effect":"Allow",
"Action": [
"memorydb:Describe*",
"memorydb:List*"],
"Resource":"*"
}
]
}
```
------
### 例 2: ユーザーに一般的な MemoryDB システム管理者タスクの実行を許可する
一般的なシステム管理者タスクには、クラスター、パラメータ、パラメータグループの変更が含まれます。システム管理者は MemoryDB イベントに関する情報を取得することが必要になる場合もあります。以下のポリシーでは、これらの一般的なシステム管理タスクの MemoryDB アクションを実行する権限をユーザーに付与します。通常、このタイプのアクセス権限ポリシーはシステム管理者グループにアタッチします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "MDBAllowSpecific",
"Effect": "Allow",
"Action": [
"memorydb:UpdateCluster",
"memorydb:DescribeClusters",
"memorydb:DescribeEvents",
"memorydb:UpdateParameterGroup",
"memorydb:DescribeParameterGroups",
"memorydb:DescribeParameters",
"memorydb:ResetParameterGroup"
],
"Resource": "*"
}
]
}
```
------
### 例 3: ユーザーにすべての MemoryDB API アクションへのアクセスを許可する
以下のポリシーでは、ユーザーにすべての MemoryDB アクションへのアクセスを許可します。このタイプのアクセス権限ポリシーは管理者ユーザーにのみ付与することをお勧めします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Sid": "MDBAllowAll",
"Effect":"Allow",
"Action":[
"memorydb:*" ],
"Resource":"*"
}
]
}
```
------
### 例 4: ユーザーが IAM CreateServiceLinkedRole API を呼び出すことを許可する
次のポリシーでは、ユーザーが IAM `CreateServiceLinkedRole` API を呼び出すことを許可します。mutative MemoryDB オペレーションを実行するユーザーには、このタイプのアクセス許可ポリシーを与えることをお勧めします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"CreateSLRAllows",
"Effect":"Allow",
"Action":[
"iam:CreateServiceLinkedRole"
],
"Resource":"*",
"Condition":{
"StringLike":{
"iam:AWS ServiceName":"memorydb.amazonaws.com"
}
}
}
]
}
```
------
# リソースレベルのアクセス許可
IAM ポリシーでリソースを指定することで、アクセス許可の範囲を制限できます。多くの AWS CLI API アクションは、アクションの動作に応じて異なるリソースタイプをサポートしています。各 IAM ポリシーステートメントによって、リソースで実行されるアクションに対するアクセス許可が付与されます。アクションが名前の付いたリソースで動作しない場合、またはすべてのリソースに対してアクションを実行するアクセス許可を付与した場合、ポリシー内のリソースの値はワイルドカード (\$1) になります。多くの API アクションでは、リソースの Amazon リソースネーム (ARN)、または複数のリソースに一致する ARN パターンを指定することによって、ユーザーが変更できるリソースを制限できます。リソース別にアクセス許可を制限するには、ARN 別にリソースを指定します。
**MemoryDB リソース ARN フォーマット**
**注記**
リソースレベルのアクセス許可を有効にするには、ARN 文字列のリソース名を小文字にする必要があります。
+ ユーザー – arn:aws:memorydb:*us-east-1:123456789012*:user/user1
+ ACL – arn:aws:memorydb:*us-east-1:123456789012*:acl/my-acl
+ クラスター – arn:aws:memorydb:*us-east-1:123456789012*:cluster/my-cluster
+ スナップショット – arn:aws:memorydb:*us-east-1:123456789012*:snapshot/my-snapshot
+ パラメータグループ – arn:aws:memorydb:*us-east-1:123456789012*:parametergroup/my-parameter-group
+ サブネットグループ – arn:aws:memorydb:*us-east-1:123456789012*:subnetgroup/my-subnet-group
**Topics**
+ [
## 例 1: 特定の MemoryDB リソースタイプへのフルアクセスをユーザーに許可する
](#example-allow-list-current-memorydb-resources-resource)
+ [
## 例 2: クラスターへのユーザーアクセスを拒否する。
](#example-allow-specific-memorydb-actions-resource)
## 例 1: 特定の MemoryDB リソースタイプへのフルアクセスをユーザーに許可する
次のポリシーでは、サブネットグループ、セキュリティグループ、クラスターのすべてのリソースへの指定された `account-id` フルアクセスを明示的に許可します。
```
{
"Sid": "Example1",
"Effect": "Allow",
"Action": "memorydb:*",
"Resource": [
"arn:aws:memorydb:us-east-1:account-id:subnetgroup/*",
"arn:aws:memorydb:us-east-1:account-id:securitygroup/*",
"arn:aws:memorydb:us-east-1:account-id:cluster/*"
]
}
```
## 例 2: クラスターへのユーザーアクセスを拒否する。
次の例では、特定のクラスターへの指定された `account-id` アクセスを明示的に拒否します。
```
{
"Sid": "Example2",
"Effect": "Deny",
"Action": "memorydb:*",
"Resource": [
"arn:aws:memorydb:us-east-1:account-id:cluster/name"
]
}
```
# MemoryDB 用のサービスリンクロール
MemoryDB は AWS Identity and Access Management (IAM) [サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)を使用します。サービスにリンクされたロールは、MemoryDB などの AWS サービスに直接リンクされた一意のタイプの IAM ロールです。MemoryDB サービスリンクロールは、MemoryDB によって事前定義されています。それらには、サービスがユーザーのクラスターに代わって AWS のサービスを呼び出すために必要なすべてのアクセス許可が含まれます。
必要な権限を手動で追加する必要がないため、サービスリンクロールは MemoryDB のセットアップを容易にします。ロールは AWS アカウント内に既に存在しますが、MemoryDB ユースケースにリンクされており、事前定義されたアクセス許可があります。これらのロールを引き受けることができるのは MemoryDB のみで、事前定義されたアクセス権限ポリシーを使用することができるのはこれらのロールのみです。ロールを削除するには、まず関連リソースを削除します。これは、リソースにアクセスするためのアクセス権限を誤って削除できないように、MemoryDB リソースを保護します。
サービスにリンクされたロールをサポートする他のサービスについては、「[IAM と連携するAWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照して、**サービスにリンクされたロール**列が**はい**になっているサービスを見つけてください。サービスにリンクされた役割に関するドキュメントをサービスで表示するには[**はい**] リンクを選択してください。
**Contents**
+ [サービスリンクロールのアクセス許可](#service-linked-role-permissions)
+ [
## サービスにリンクされたロールの作成 (IAM)
](#create-service-linked-role-iam)
+ [IAM コンソールの使用](#create-service-linked-role-iam-console)
+ [IAM CLI の使用](#create-service-linked-role-iam-cli)
+ [IAM API の使用](#create-service-linked-role-iam-api)
+ [サービスにリンクされたロールの説明の編集](#edit-service-linked-role)
+ [IAM コンソールの使用](#edit-service-linked-role-iam-console)
+ [IAM CLI の使用](#edit-service-linked-role-iam-cli)
+ [IAM API の使用](#edit-service-linked-role-iam-api)
+ [
## MemoryDB のサービスにリンクされたロールの削除
](#delete-service-linked-role)
+ [
### サービスにリンクされたロールのクリーンアップ
](#service-linked-role-review-before-delete)
+ [
### サービスにリンクされたロールの削除 (IAMコンソール)
](#delete-service-linked-role-iam-console)
+ [
### サービスにリンクされたロールの削除 (IAM CLI)
](#delete-service-linked-role-iam-cli)
+ [
### サービスにリンクされたロールの削除 (IAM API)
](#delete-service-linked-role-iam-api)
## MemoryDB のサービスにリンクされたロールのアクセス権限
MemoryDB は、**AWSServiceRoleForMemoryDB** という名前のサービスにリンクされたロールを使用します。このポリシーにより、MemoryDB はクラスターの管理に必要な AWS リソースをユーザーに代わって管理できます。
AWSServiceRoleForMemoryDB サービスリンクロールのアクセス権限ポリシーでは、MemoryDB は、指定されたリソースで次のアクションを完了できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateNetworkInterface"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"AmazonMemoryDBManaged"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws-cn:ec2:*:*:network-interface/*",
"arn:aws-cn:ec2:*:*:subnet/*",
"arn:aws-cn:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AmazonMemoryDBManaged": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:security-group/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudwatch:namespace": "AWS/MemoryDB"
}
}
}
]
}
```
------
詳細については、「[AWS マネージドポリシー: MemoryDBServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-memorydbServiceRolePolicy)」を参照してください。
**IAM エンティティが AWSServiceRoleForMemoryDB サービスにリンクされたロールを作成するには**
以下のポリシーステートメントを IAM エンティティのアクセス許可に追加します。
```
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB*",
"Condition": {"StringLike": {"iam:AWS ServiceName": "memorydb.amazonaws.com"}}
}
```
**IAM エンティティが AWSServiceRoleForMemoryDB サービスにリンクされたロールを削除するには**
以下のポリシーステートメントを IAM エンティティのアクセス許可に追加します。
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB*",
"Condition": {"StringLike": {"iam:AWS ServiceName": "memorydb.amazonaws.com"}}
}
```
または、 AWS 管理ポリシーを使用して MemoryDB へのフルアクセスを提供することもできます。
## サービスにリンクされたロールの作成 (IAM)
IAM コンソール、CLI または API を使用して、サービスにリンクされたロールを作成できます。
### サービスにリンクされたロールの作成 (IAM コンソール)
IAM コンソールを使用して、サービスにリンクされたロールを作成できます。
**サービスにリンクされたロールを作成するには (コンソール)**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。
1. IAM コンソールのナビゲーションペインで **[ロール]** をクリックします。次に、**新しいロールの作成**を選択します。
1. **信頼されたエンティティの種類を選択** の下で、**AWS Service** (サービス) を選択します。
1. **[またはサービスを選択してそのユースケースを表示する]** で、**[MemoryDB]** を選択します。
1. **次: 許可** を選択します。
1. **ポリシー名** の下で、`MemoryDBServiceRolePolicy` はこのロールに必要であることに注意してください。**次: タグ** を選択します。
1. タグは、サービスにリンクされたロールではサポートされないことに注意してください。**次: レビュー** を選択します。
1. 「オプショナル」**ロールの説明** で、サービスにリンクされた新しいロールの説明を編集します。
1. ロール情報を確認し、**ロールの作成** を選択します。
### サービスにリンクされたロールの作成 (IAM CLI)
から IAM オペレーションを使用して AWS Command Line Interface 、サービスにリンクされたロールを作成できます。このロールには、ロールを引き受けるためにサービスで必要な信頼ポリシーやインラインポリシーを含めることができます。
**サービスにリンクされたロールを作成するには (CLI)**
次のオペレーションを使用してください。
```
$ aws iam [create-service-linked-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html) --aws-service-name memorydb.amazonaws.com
```
### サービスにリンクされたロールの作成 (IAM API)
IAM API を使用して、サービスにリンクされたロールを作成できます。このロールには、ロールを引き受けるためにサービスで必要な信頼ポリシーやインラインポリシーを含めることができます。
**サービスにリンクされたロールを作成するには (API)**
[CreateServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html) API コールを使用します。リクエストで、サービス名`memorydb.amazonaws.com`を指定します。
## MemoryDB のサービスにリンクされたロールの説明の編集
MemoryDB では、AWSServiceRoleForMemoryDB のサービスにリンクされたロールを編集できません。サービスリンクロールの作成後は、さまざまなエンティティがロールを参照する可能性があるため、ロール名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。
### サービスにリンクされたロールの説明の編集 (IAMコンソール)
サービスにリンクされたロールの説明は、IAM コンソールを使用して編集できます。
**サービスにリンクされたロールの説明を編集するには (コンソール)**
1. IAM コンソールのナビゲーションペインで **[ロール]** をクリックします。
1. 変更するロールの名前を選択します。
1. **ロールの説明**の右端にある**編集**を選択します。
1. ボックスに新しい説明を入力し、**保存**を選択します。
### サービスにリンクされたロールの説明の編集 (IAM CLI)
から IAM オペレーションを使用して AWS Command Line Interface 、サービスにリンクされたロールの説明を編集できます。
**サービスにリンクされたロールの説明を変更するには (CLI)**
1. (オプション) ロールの現在の説明を表示するには、IAM オペレーション AWS CLI の を使用します`[get-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)`。
**Example**
```
$ aws iam [get-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) --role-name AWSServiceRoleForMemoryDB
```
CLI オペレーションでは、ARN ではなくロール名を使用してロールを参照します。例えば、ロールの ARN が `arn:aws:iam::123456789012:role/myrole` である場合、そのロールを **myrole** と参照します。
1. サービスにリンクされたロールの説明を更新するには、IAM オペレーション AWS CLI の を使用します`[update-role-description](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)`。
Linux、macOS、Unix の場合:
```
$ aws iam [update-role-description](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html) \
--role-name AWSServiceRoleForMemoryDB \
--description "new description"
```
Windows の場合:
```
$ aws iam [update-role-description](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html) ^
--role-name AWSServiceRoleForMemoryDB ^
--description "new description"
```
### サービスにリンクされたロールの説明の編集 (IAM API)
サービスにリンクされたロールの説明は、IAM API を使用して編集できます。
**サービスにリンクされたロールの説明を変更するには (API)**
1. 「オプショナル」現在のロールの説明を表示するには、IAM API オペレーション [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) を使用します。
**Example**
```
https://iam.amazonaws.com/
?Action=[GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)
&RoleName=AWSServiceRoleForMemoryDB
&Version=2010-05-08
&AUTHPARAMS
```
1. ロールの説明を更新するには、IAM API オペレーション [UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html) を使用します。
**Example**
```
https://iam.amazonaws.com/
?Action=[UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)
&RoleName=AWSServiceRoleForMemoryDB
&Version=2010-05-08
&Description="New description"
```
## MemoryDB のサービスにリンクされたロールの削除
サービスリンクロールを必要とする機能やサービスが不要になった場合は、ロールを削除することをお勧めします。そうすることで、モニタリングや保守が積極的に行われていない未使用のエンティティを排除できます。ただし、削除する前に、サービスにリンクされた役割をクリーンアップする必要があります。
MemoryDB はサービスにリンクされたロールを削除しません。
### サービスにリンクされたロールのクリーンアップ
IAM を使用してサービスにリンクされたロールを削除するには、まずそれに関連付けられているリソース (クラスター) がないことを確認する必要があります。
**サービスにリンクされたロールにアクティブなセッションがあるかどうかを、IAM コンソールで確認するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。
1. IAM コンソールのナビゲーションペインで **[ロール]** をクリックします。次に、AWSServiceRoleForMemoryDB ロールの名前 (チェックボックスではありません) を選択します。
1. 選択したロールの **概要** ページで、**アクセスアドバイザー** タブを選択します。
1. **アクセスアドバイザー** タブで、サービスにリンクされたロールの最新のアクティビティを確認します。
**AWSServiceRoleForMemoryDB を必要とする MemoryDB リソースを削除するには (コンソール)**
+ クラスターを削除するには、以下を参照してください。
+ [の使用 AWS マネジメントコンソール](getting-started.md#clusters.deleteclusters.viewdetails)
+ [の使用 AWS CLI](getting-started.md#clusters.delete.cli)
+ [MemoryDB API の使用](getting-started.md#clusters.delete.api)
### サービスにリンクされたロールの削除 (IAMコンソール)
IAM コンソールを使用して、サービスにリンクされたロールを削除できます。
**サービスにリンクされたロールを削除するには (コンソール)**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。
1. IAM コンソールのナビゲーションペインで **[ロール]** をクリックします。ロール名または行そのものではなく、削除するロール名の横にあるチェックボックスをオンにします。
1. ページ上部にある **ロールのアクション** で **ロールの削除** を選択します。
1. 確認ページで、サービスの最終アクセス時間データを確認します。このデータには、選択した各ロールが最後に AWS サービスにアクセスした日時が表示されます。これは、そのロールが現在アクティブであるかどうかを確認するのに役立ちます。先に進む場合は、**[Yes, Delete]** (はい、削除する) を選択し、削除するサービスにリンクされたロールを送信します。
1. IAM コンソール通知を見て、サービスにリンクされたロールの削除の進行状況をモニタリングします。IAM サービスにリンクされたロールの削除は非同期であるため、削除するロールを送信すると、削除タスクは成功または失敗する可能性があります。タスクが失敗した場合は、通知から **詳細を表示**または **リソースを表示**を選択して、削除が失敗した理由を知ることができます。
### サービスにリンクされたロールの削除 (IAM CLI)
から IAM オペレーションを使用して AWS Command Line Interface 、サービスにリンクされたロールを削除できます。
**サービスにリンクされたロールを削除するには (CLI)**
1. 削除するサービスにリンクされたロールの名前が分からない場合、以下のコマンドを入力します。このコマンドでは、アカウントにあるロールとその Amazon リソースネーム (ARN) を一覧表示します。
```
$ aws iam [get-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) --role-name role-name
```
CLI オペレーションでは、ARN ではなくロール名を使用してロールを参照します。例えば、ロールに ARN `arn:aws:iam::123456789012:role/myrole` がある場合、そのロールを **myrole** と参照します。
1. サービスにリンクされているロールは、使用されている、または関連するリソースがある場合は削除できないため、削除リクエストを送信する必要があります。これらの条件が満たされない場合、そのリクエストは拒否される可能性があります。レスポンスから `deletion-task-id` を取得して、削除タスクのステータスを確認する必要があります。サービスにリンクされたロールの削除リクエストを送信するには、以下を入力します。
```
$ aws iam [delete-service-linked-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html) --role-name role-name
```
1. 削除タスクのステータスを確認するには、以下を入力します。
```
$ aws iam [get-service-linked-role-deletion-status](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html) --deletion-task-id deletion-task-id
```
削除タスクのステータスは、`NOT_STARTED`、`IN_PROGRESS`、`SUCCEEDED`、または `FAILED` となります｡ 削除が失敗した場合は、失敗した理由がコールによって返され、トラブルシューティングが可能になります。
### サービスにリンクされたロールの削除 (IAM API)
IAM API を使用して、サービスにリンクされたロールを削除できます。
**サービスにリンクされたロールを削除するには (API)**
1. サービスにリンクされたロールの削除リクエストを送信するには、[DeleteServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html) を呼び出します。リクエストで、ロール名を指定します。
サービスにリンクされているロールは、使用されている、または関連するリソースがある場合は削除できないため、削除リクエストを送信する必要があります。これらの条件が満たされない場合、そのリクエストは拒否される可能性があります。レスポンスから `DeletionTaskId` を取得して、削除タスクのステータスを確認する必要があります。
1. 削除タスクのステータスを確認するには、[GetServiceLinkedRoleDeletionStatus](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html) を呼び出します。リクエストで `DeletionTaskId` を指定します。
削除タスクのステータスは、`NOT_STARTED`、`IN_PROGRESS`、`SUCCEEDED`、または `FAILED` となります｡ 削除が失敗した場合は、失敗した理由がコールによって返され、トラブルシューティングが可能になります。
# AWS MemoryDB の マネージドポリシー
ユーザー、グループ、ロールにアクセス許可を追加するには、自分でポリシーを記述するよりも AWS 管理ポリシーを使用する方が簡単です。チームに必要な権限のみを提供する [IAM カスタマーマネージドポリシーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)には時間と専門知識が必要です。すぐに開始するには、 AWS マネージドポリシーを使用できます。これらのポリシーは一般的なユースケースを対象としており、 AWS アカウントで利用できます。 AWS 管理ポリシーの詳細については、*IAM ユーザーガイド*の「 [AWS 管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
AWS サービスは、 AWS 管理ポリシーを維持および更新します。 AWS 管理ポリシーのアクセス許可は変更できません。サービスでは新しい機能を利用できるようにするために、 AWS マネージドポリシーに権限が追加されることがあります。この種類の更新はポリシーがアタッチされている、すべてのアイデンティティ (ユーザー、グループおよびロール) に影響を与えます。新しい機能が立ち上げられた場合や、新しいオペレーションが使用可能になった場合に、各サービスが AWS マネージドポリシーを更新する可能性が最も高くなります。サービスは AWS マネージドポリシーからアクセス許可を削除しないため、ポリシーの更新によって既存のアクセス許可が損なわれることはありません。
さらに、 は、複数の サービスにまたがるジョブ関数の 管理ポリシー AWS をサポートしています。例えば、**ReadOnlyAccess** AWS 管理ポリシーは、すべての AWS サービスとリソースへの読み取り専用アクセスを提供します。サービスが新機能を起動すると、 は新しいオペレーションとリソースの読み取り専用アクセス許可 AWS を追加します。ジョブ機能のポリシーの一覧および詳細については、「*IAM ユーザーガイド*」の「[AWS のジョブ機能のマネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)」を参照してください。
## AWS マネージドポリシー: MemoryDBServiceRolePolicy
MemoryDBServiceRolePolicy AWS 管理ポリシーをアカウントの ID にアタッチすることはできません。このポリシーは、 AWS MemoryDB サービスにリンクされたロールの一部です。このロールにより、サービスはアカウント内のネットワークインターフェイスとセキュリティグループを管理できます。
MemoryDB は、このポリシーの権限を使用して EC2 セキュリティグループとネットワークインターフェイスを管理します。これは MemoryDB クラスターを管理するために必要です。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateNetworkInterface"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"AmazonMemoryDBManaged"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws-cn:ec2:*:*:network-interface/*",
"arn:aws-cn:ec2:*:*:subnet/*",
"arn:aws-cn:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AmazonMemoryDBManaged": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:security-group/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudwatch:namespace": "AWS/MemoryDB"
}
}
}
]
}
```
------
## MemoryDB のAWS管理 (事前定義) ポリシー
AWS は、 によって作成および管理されるスタンドアロン IAM ポリシーを提供することで、多くの一般的なユースケースに対処します AWS。マネージドポリシーは、一般的ユースケースに必要な許可を付与することで、どの許可が必要なのかをユーザーが調査する必要をなくすることができます。詳細については、「*IAM ユーザーガイド*」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
アカウントのユーザーにアタッチできる以下の AWS 管理ポリシーは、MemoryDB に固有です。
### AmazonMemoryDBReadOnlyAccess
`AmazonMemoryDBReadOnlyAccess` ポリシーを IAM アイデンティティにアタッチできます。このポリシーは、すべての読み取り専用アクセスを許可する管理者権限を付与します。
**AmazonMemoryDBReadOnlyAccess** - MemoryDB リソースへの読み取り専用のアクセス権を付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"memorydb:Describe*",
"memorydb:List*"
],
"Resource": "*"
}]
}
```
------
### AmazonMemoryDBFullAccess
`AmazonMemoryDBFullAccess` ポリシーを IAM アイデンティティにアタッチできます。このポリシーは、すべてのMemoryDBリソースへのフルアクセスを許可する管理者権限を付与します。
**AmazonMemoryDBFullAccess** - MemoryDB リソースへの完全なアクセス権を付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "memorydb:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "memorydb.amazonaws.com"
}
}
}
]
}
```
------
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "memorydb:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws-cn:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "memorydb.amazonaws.com"
}
}
}
]
}
```
------
独自のカスタム IAM ポリシーを作成して、MemoryDB API アクションにアクセス権限を付与することもできます。これらのカスタムポリシーは、それらのアクセス許可が必要な IAM ユーザーまたはグループにアタッチできます。
## AWS 管理ポリシーに対する MemoryDB の更新
このサービスがこれらの変更の追跡を開始した以降の MemoryDB の AWS マネージドポリシーの更新に関する詳細を表示します。このページの変更に関する自動通知については、ドキュメントの履歴ページの RSS フィードをサブスクライブしてください。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| [AWS マネージドポリシー: MemoryDBServiceRolePolicy](#security-iam-awsmanpol-memorydbServiceRolePolicy) - ポリシーの追加 | MemoryDBServiceRolePolicy によって memorydb:ReplicateMultiRegionClusterData のアクセス許可が追加されました。このアクセス許可により、サービスにリンクされたロールは MemoryDB マルチリージョンクラスターのデータをレプリケートできるようになります。 | 12/01/2024 |
| [AmazonMemoryDBFullAccess](#iam.identitybasedpolicies.predefinedpolicies-fullaccess) - ポリシーの追加 | MemoryDB では、サポートされているリソースを記述して一覧表示するための新しいアクセス許可が追加されました。これらのアクセス許可は、MemoryDB がアカウント内のサポートされているすべてのリソースをクエリするために必要です。 | 10/07/2021 |
| [AmazonMemoryDBReadOnlyAccess](#iam.identitybasedpolicies.predefinedpolicies-readonly) - ポリシーの追加 | MemoryDB では、サポートされているリソースを記述して一覧表示するための新しいアクセス許可が追加されました。これらのアクセス許可は、MemoryDB がアカウント内のサポートされているすべてのリソースをクエリしてアカウントベースのアプリケーションを作成するために必要です。 | 10/07/2021 |
| MemoryDB が変更の追跡を開始しました | サービスの起動 | 8/19/2021 |
# MemoryDB API の許可: アクション、リソース、条件リファレンス
[アクセスコントロール](iam.md#iam.accesscontrol) を設定し、IAM ポリシーにアタッチするアクセス許可ポリシー (アイデンティティベースまたはリソースベース) を作成するときは、以下の表をリファレンスとして使用できます。この表には、各 MemoryDB API オペレーション、およびその実行のためのアクセス権限を付与できる対応するアクションを示しています。ポリシーの `Action` フィールドでアクションを指定し、ポリシーの `Resource` フィールドでリソースの値を指定します。特に明記されていない限り、リソースは必須です。一部のフィールドには、必須リソースとオプションリソースの両方が含まれます。リソース ARN がない場合、ポリシー内のリソースはワイルドカード (\$1) になります。
**注記**
アクションを指定するには、API オペレーション名 (`memorydb:DescribeClusters` など) の前に `memorydb:` プレフィックスを使用します。
スクロールバーを使用して、テーブルの残りの部分を確認します。
**MemoryDB API およびアクションで必要なアクセス権限**
| MemoryDB API オペレーション | 必要な許可 (API アクション) | リソース |
| --- | --- | --- |
| [BatchUpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_BatchUpdateCluster.html) | `memorydb:BatchUpdateCluster` | クラスター |
| [CopySnapshot](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CopySnapshot.html) | `memorydb:CopySnapshot` `memorydb:TagResource` `s3:GetBucketLocation` `s3:ListAllMyBuckets` | スナップショット (ソース、ターゲット) \$1 \$1 |
| [CreateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateCluster.html) | `memorydb:CreateCluster` `memorydb:TagResource` `s3:GetObject` `SnapshotArns` パラメータを使用する場合、`SnapshotArns` リストの各メンバーには、そのリソースとして `s3` ARN を関連付けた独自の `s3:GetObject` アクセス権限が必要です。 | パラメータグループ。「オプショナル」クラスター、スナップショット、セキュリティグループID、サブネットグループ `arn:aws:s3:::my_bucket/snapshot1.rdb` ここで、*my\$1bucket*/*snapshot1* はクラスターの作成元になる S3 バケットとスナップショットです。 |
| [CreateParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateParameterGroup.html) | `memorydb:CreateParameterGroup` `memorydb:TagResource` | パラメータグループ |
| [CreateSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateSubnetGroup.html) | `memorydb:CreateSubnetGroup` `memorydb:TagResource` | サブネットグループ | \$1 |
| [CreateSnapshot](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateSnapshot.html) | `memorydb:CreateSnapshot` `memorydb:TagResource` | クラスター,スナップショット |
| [CreateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateUser.html) | `memorydb:CreateUser` `memorydb:TagResource` | ユーザー |
| [CreateACL](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateACL.html) | `memorydb:CreateACL` `memorydb:TagResource` | アクセスコントロールリスト (ACL) |
| [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) | `memorydb:UpdateCluster` | クラスター |
| [DeleteCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteCluster.html) | `memorydb:DeleteCluster` | クラスター。「オプショナル」スナップショット |
| [DeleteParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteParameterGroup.html) | `memorydb:DeleteParameterGroup` | パラメータグループ |
| [DeleteSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteSubnetGroup.html) | `memorydb:DeleteSubnetGroup` | サブネットグループ |
| [DeleteSnapshot](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteSnapshot.html) | `memorydb:DeleteSnapshot` | Snapshot |
| [DeleteUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteUser.html) | `memorydb:DeleteUser` | ユーザー |
| [DeleteACL](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteACL.html) | `memorydb:DeleteACL` | ACL |
| [DescribeClusters](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeClusters.html) | `memorydb:DescribeClusters` | クラスター |
| [DescribeEngineVersions](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEngineVersions.html) | `memorydb:DescribeEngineVersions` | リソース ARN がありません: \$1 |
| [DescribeParameterGroups](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeParameterGroups.html) | `memorydb:DescribeParameterGroups` | パラメータグループ |
| [DescribeParameters](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeParameters.html) | `memorydb:DescribeParameters` | パラメータグループ |
| [DescribeSubnetGroups](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSubnetGroups.html) | `memorydb:DescribeSubnetGroups` | サブネットグループ | \$1 |
| [DescribeEvents](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html) | `memorydb:DescribeEvents` | リソース ARN がありません: \$1 |
| [DescribeClusters](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeClusters.html) | `memorydb:DescribeClusters` | クラスター |
| [DescribeServiceUpdates](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeServiceUpdates.html) | `memorydb:DescribeServiceUpdates` | リソース ARN がありません: \$1 |
| [DescribeSnapshots](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSnapshots.html) | `memorydb:DescribeSnapshots` | Snapshot |
| [DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html) | `memorydb:DescribeUsers` | ユーザー |
| [DescribeACLs](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeACLs.html) | `memorydb:DescribeACLs` | ACL |
| [ListAllowedNodeTypeUpdates](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ListAllowedNodeTypeUpdates.html) | `memorydb:ListAllowedNodeTypeUpdates` | クラスター |
| [ListTags](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ListTags.html) | `memorydb:ListTags` | 「オプショナル」 クラスター、スナップショット |
| [UpdateParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateParameterGroup.html) | `memorydb:UpdateParameterGroup` | パラメータグループ |
| [UpdateSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateSubnetGroup.html) | `memorydb:UpdateSubnetGroup` | サブネットグループ |
| [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) | `memorydb:UpdateCluster` | クラスター。「オプショナル」パラメータグループ、セキュリティグループ |
| [UpdateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateUser.html) | `memorydb:UpdateUser` | ユーザー |
| [UpdateACL](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateACL.html) | `memorydb:UpdateACL` | ACL |
| [UntagResource](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UntagResource.html) | `memorydb:UntagResource` | 「オプショナル」 クラスター、スナップショット |
| [ResetParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ResetParameterGroup.html) | `memorydb:ResetParameterGroup` | パラメータグループ |
| 「[フェイルオーバーシャード](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_FailoverShard.html)」 | `memorydb:FailoverShard` | クラスター、シャード |
# ログ記録とモニタリング
モニタリングは、MemoryDB および他の AWS ソリューションの信頼性、可用性、パフォーマンスの維持に重要な要素です。AWS は、MemoryDB をモニタリングし、問題が発生した場合には報告を行い、必要に応じて自動アクションを実行するために以下のモニタリングツールを提供しています。
+ Amazon CloudWatch は、AWS のリソースおよび AWS で実行しているアプリケーションをリアルタイムでモニタリングします。メトリクスの収集と追跡、カスタマイズしたダッシュボードの作成、および指定したメトリクスが指定したしきい値に達したときに通知またはアクションを実行するアラームの設定を行うことができます。例えば、CloudWatch で Amazon EC2 インスタンスの CPU 使用率などのメトリクスを追跡し、必要に応じて新しいインスタンスを自動的に起動できます。詳細については、「[Amazon CloudWatch ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)」を参照してください。
+ *Amazon CloudWatch Logs* では、Amazon EC2 インスタンス、CloudTrail、その他ソースから得たログファイルのモニタリング、保存、およびアクセスが可能です。CloudWatch Logs は、ログファイル内の情報をモニタリングし、特定のしきい値が満たされたときに通知します。高い耐久性を備えたストレージにログデータをアーカイブすることも可能です。詳細については、「[Amazon CloudWatch Logs ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/)」を参照してください。
+ **AWS CloudTrail は、AWS アカウントにより、またはそのアカウントに代わって行われた API よルや関連イベントを取得し、指定した Amazon S3 バケットにログファイルを配信します。AWS を呼び出したユーザーとアカウント、呼び出し元の IP アドレス、および呼び出しの発生日時を特定できます。詳細については、[AWS CloudTrailユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)を参照してください。
# Amazon CloudWatch による MemoryDB のモニタリング
CloudWatch を使用して MemoryDB を監視できます。CloudWatch は raw データを収集し、それを読み取り可能なほぼリアルタイムのメトリクスに処理します。これらの統計は 15 か月間保持されるため、履歴情報にアクセスし、ウェブアプリケーションまたはサービスの動作をより的確に把握できます。また、特定のしきい値を監視するアラームを設定し、これらのしきい値に達したときに通知を送信したりアクションを実行したりできます。詳細については、「[Amazon CloudWatch ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)」を参照してください。
以下のセクションでは、MemoryDB のメトリクスとディメンションを一覧表示しています。
**Topics**
+ [
# ホストレベルのメトリクス
](metrics.HostLevel.md)
+ [
# MemoryDB のメトリック
](metrics.memorydb.md)
+ [
# モニタリングすべきメトリクス
](metrics.whichshouldimonitor.md)
+ [
# メトリクスの統計と期間の選択
](metrics.ChoosingStatisticsAndPeriods.md)
+ [
# CloudWatch メトリクスを使用したモニタリング
](cloudwatchmetrics.md)
# ホストレベルのメトリクス
`AWS/MemoryDB` 名前空間は、各ノードに対する以下のホストレベルのメトリクスが含まれます。
**以下の資料も参照してください**
+ [MemoryDB のメトリック](metrics.memorydb.md)
| メトリクス | 説明 | 単位 |
| --- | --- | --- |
| CPUUtilization | ホスト全体の CPU 使用率の割合 (%)。Valkey および Redis OSS はシングルスレットであるため、4 個以上の vCPU を持つノードで EngineCPUUtilization メトリクスをモニタリングすることをお勧めします。 | 割合 (%) |
| FreeableMemory | ホストで使用可能な空きメモリの量。この数字は、OS によって解放できる可能性があるとレポートされる RAM のメモリとバッファから算出されます。 | バイト |
| NetworkBytesIn | ホストがネットワークから読み取ったバイト数。 | バイト |
| NetworkBytesOut | すべてのネットワークインターフェイスでの、このインスタンスから送信されたバイトの数。 | バイト |
| NetworkPacketsIn | すべてのネットワークインターフェイスでの、このインスタンスによって受信されたパケットの数。このメトリクスは受信トラフィックのボリュームを単一インスタンスでのパケット数として識別します。 | カウント |
| NetworkPacketsOut | すべてのネットワークインターフェイスでの、このインスタンスから送信されたパケットの数。このメトリクスは送信トラフィックのボリュームを単一インスタンスでのパケット数として識別します。 | カウント |
| NetworkBandwidthInAllowanceExceeded | インバウンドの集計帯域幅がインスタンスの最大値を超えたために形成されたパケットの数。 | カウント |
| NetworkConntrackAllowanceExceeded | 接続トラッキングがインスタンスの最大数を超え、新しい接続を確立できなかったために形成されたパケットの数。これにより、インスタンスとの間で送受信されるトラフィックのパケット損失が発生する可能性があります。 | カウント |
| NetworkBandwidthOutAllowanceExceeded | アウトバウンド集計帯域幅がインスタンスの最大値を超えたために形成されたパケットの数。 | カウント |
| NetworkPacketsPerSecondAllowanceExceeded | 1 秒あたりの双方向パケットがインスタンスの最大値を超えたために形成されたパケットの数。 | カウント |
| NetworkMaxBytesIn | 1 分間の受信バイトの最大毎秒バースト量。 | バイト |
| NetworkMaxBytesOut | 1 分間の送信バイトの最大毎秒バースト量。 | バイト |
| NetworkMaxPacketsIn | 1 分間の受信パケットの最大毎秒バースト量。 | カウント |
| NetworkMaxPacketsOut | 1 分間の送信パケットの最大毎秒バースト量。 | カウント |
| SwapUsage | ホストで使用されるスワップの量。 | バイト |
# MemoryDB のメトリック
`AWS/MemoryDB` 名前空間には、次のメトリクスが含まれます。
`ReplicationLag`、`EngineCPUUtilization`、`SuccessfulWriteRequestLatency`、および `SuccessfulReadRequestLatency` を除き、これらのメトリクスは、Valkey および Redis OSS の **info** コマンドから算出されます。各メトリクスは、ノードレベルで算出されます。
**INFO** コマンドの詳細なドキュメントについては、「[INFO](http://valkey.io/commands/info)」を参照してください。
**「」、「」も参照してください。**
+ [ホストレベルのメトリクス](metrics.HostLevel.md)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/memorydb/latest/devguide/metrics.memorydb.html)
以下は特定の種類のコマンドの集計で、**info commandstats** から算出されています。コマンドスタッツのセクションには、呼び出し回数など、コマンドタイプに基づく統計情報が表示されます。
利用可能なコマンドの完全な一覧については、「[コマンド](https://valkey.io/commands)」を参照してください。
| メトリクス | 説明 | 単位 |
| --- | --- | --- |
| EvalBasedCmds | eval ベースのコマンドの合計数。これは、eval、evalsha を合計することによって commandstats 統計から算出されます。 | カウント |
| GeoSpatialBasedCmds | 地理空間ベースのコマンドの総数。これは commandstats 統計から算出されます。これは、すべての geo の種類のコマンド (geoadd、geodist、geohash、geopos、georadius、および georadiusbymember) を合計することによって算出されます。 | カウント |
| GetTypeCmds | read-only 型のコマンドの合計数。これは、すべての read-only の種類のコマンド (get、hget、scard、lrange など) を合計することによって commandstats 統計から算出されます。 | カウント |
| HashBasedCmds | ハッシュベースのコマンドの総数。これは、1 つ以上のハッシュに対して実行されるすべてのコマンド (hget、hkeys、hvals、hdel など) を合計することによって commandstats 統計から算出されます。 | カウント |
| HyperLogLogBasedCmds | HyperLogLog ベースのコマンドの合計数。これは、すべての pf の種類のコマンド (pfadd、pfcount、pfmerge など) を合計することによって commandstats 統計から算出されます。 | カウント |
| JsonBasedCmds | JSON ベースのコマンドの総数。これは、commandstats 統計に基づき、1 つ以上の JSON ドキュメントオブジェクトに対して実行されるすべてのコマンドを合計して算出されます。 | カウント |
| KeyBasedCmds | キーベースのコマンドの総数。これは、複数のデータ構造で 1 つ以上のキーに対して実行されるすべてのコマンド (del、expire、rename など) を合計することによって、commandstats 統計から算出されます。 | カウント |
| ListBasedCmds | リストベースのコマンドの総数。これは、1 つ以上のリストに対して実行されるすべてのコマンド (lindex、lrange、lpush、ltrim など) を合計することによって commandstats 統計から算出されます。 | カウント |
| PubSubBasedCmds | pub/sub 機能のコマンドの総数。これは、pub/sub 機能で使用されるすべてのコマンド (psubscribe、publish、pubsub、punsubscribe、subscribe、unsubscribe) を合計することによって commandstats 統計から算出されます。 | カウント |
| SearchBasedCmds | 読み取りコマンドと書き込みコマンドの両方を含む、セカンダリインデックスと検索コマンドの総数。これは、セカンダリインデックスに作用するすべての search コマンドを合計することにより、commandstats 統計から導出されます。 | カウント |
| SearchBasedGetCmds | セカンダリインデックスと検索読み取り専用コマンドの総数。これは、すべてのセカンダリインデックスと search get コマンドを合計することによって、commandstats 統計から導出されます。 | カウント |
| SearchBasedSetCmds | セカンダリインデックスと検索書き込みコマンドの総数。これは、すべてのセカンダリインデックスと search set コマンドを合計することによって、commandstats 統計から導出されます。 | カウント |
| SearchNumberOfIndexes | インデックスの総数。 | カウント |
| SearchNumberOfIndexedKeys | インデックス付きキーの総数 | カウント |
| SearchTotalIndexSize | すべてのインデックスによって使用されるメモリ (バイト)。 | バイト |
| SetBasedCmds | セットベースのコマンドの総数。これは、1 つ以上のセットに対して実行されるすべてのコマンド (scard、sdiff、sadd、sunion など) を合計することによって commandstats 統計から算出されます。 | カウント |
| SetTypeCmds | write 型のコマンドの合計数。これは、データ上で動作する mutative の種類のすべてのコマンド (set、hset、sadd、lpop など) を合計することによって commandstats 統計から算出されます。 | カウント |
| SortedSetBasedCmds | ソートされたセットベースのコマンドの総数。これは、1 つ以上のソートされたセットに対して実行されるすべてのコマンド (zcount、zrange、zrank、zadd など) を合計することによって commandstats 統計から算出されます。 | カウント |
| StringBasedCmds | 文字列ベースのコマンドの総数。これは、1 つ以上の文字列に対して実行されるすべてのコマンド (strlen、setex、setrange など) を合計することによって commandstats 統計から算出されます。 | カウント |
| StreamBasedCmds | ストリームベースのコマンドの総数。これは、1 つ以上のストリームデータの種類に対して実行されるすべてのコマンド (xrange、xlen、xadd、xdel など) を合計することによって commandstats 統計から算出されます。 | カウント |
# モニタリングすべきメトリクス
次の CloudWatch メトリクスは、MemoryDB パフォーマンスを把握するのに役立ちます。ほとんどの場合、パフォーマンスの問題が発生する前に修正作業を行うことができるように、これらのメトリクスに CloudWatch アラームを設定することをお勧めします。
**Topics**
+ [
## CPUUtilization (CPU使用度)
](#metrics-cpu-utilization)
+ [
## EngineCPUUtilization
](#metrics-engine-cpu-utilization)
+ [
## SwapUsage
](#metrics-swap-usage)
+ [
## Evictions
](#metrics-evictions)
+ [
## CurrConnections
](#metrics-curr-connections)
+ [
## メモリ
](#metrics-memory)
+ [
## ネットワーク
](#metrics-network)
+ [
## レイテンシー
](#metrics-latency)
+ [
## レプリケーション
](#metrics-replication)
## CPUUtilization (CPU使用度)
パーセント値でレポートされるホストレベルのメトリクスです。詳細については、「[ホストレベルのメトリクス](metrics.HostLevel.md)」を参照してください。
2 個以下の vCPU を持つ小さなノードタイプの場合は、`CPUUtilization ` メトリクスを使用してワークロードをモニタリングします。
一般的に、利用可能な CPU の 90% にしきい値を設定することをお勧めします。Valkey および Redis OSS はシングルスレッドであるため、実際のしきい値はノードの総容量に占める割合のごく一部になるよう計算します。例えば、2 個のコアを搭載するノードタイプを使用しているとします。この場合、CPUUtilization のしきい値は 90/2、つまり 45% になります。ノードタイプに搭載されたコア数 (vCPU) を調べる方法については、「[MemoryDB 料金表](https://aws.amazon.com/memorydb/pricing/?p=ps)」を参照してください。
使用しているノードのコア数に基づいて独自のしきい値を決定する必要があります。このしきい値を超えた場合で、主なワークロードが読み込みリクエストから生成されている場合、リードレプリカを追加してクラスターをスケールします。主なワークロードが書き込みリクエストからのものである場合は、より多くのシャードを追加して、より多くのプライマリノード間で書き込みワークロードを分散することをお勧めします。
**ヒント**
ホストレベルのメトリクス `CPUUtilization` を使用する代わりに、Valkey または Redis OSS エンジンコアの使用率をレポートするメトリクス `EngineCPUUtilization` を使用できる場合があります。 コードでこのメトリクスが利用できるかどうか、およびその詳細については、「[MemoryDB のメトリクス](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html)」を参照してください。
4 個以上の vCPU を持つ大きなノードタイプでは、Valkey または Redis OSS エンジンコアでの使用量のパーセント値をレポートする `EngineCPUUtilization` メトリクスを使用することをお勧めします。コードでこのメトリクスが利用できるかどうか、およびその詳細については、「[MemoryDB のメトリクス](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html)」を参照してください。
## EngineCPUUtilization
4 個以上の vCPU を持つ大きなノードタイプでは、Valkey または Redis OSS エンジンコアでの使用量のパーセント値をレポートする `EngineCPUUtilization` メトリクスを使用することをお勧めします。コードでこのメトリクスが利用できるかどうか、およびその詳細については、「[MemoryDB のメトリクス](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html)」を参照してください。
## SwapUsage
バイト単位でレポートされるホストレベルのメトリクスです。詳細については、「[ホストレベルのメトリクス](metrics.HostLevel.md)」を参照してください。
`FreeableMemory` CloudWatch メトリクスが 0 に近い (つまり 100 MB 未満) 場合、または `SwapUsage` メトリクスが `FreeableMemory` メトリクスより大きい場合は、ノードがメモリプレッシャーを受けている可能性があります。
## Evictions
これは、エンジンのメトリクスです。アプリケーションニーズに基づいてこのメトリクスの独自のアラームしきい値を決定することをお勧めします。
## CurrConnections
これは、エンジンのメトリクスです。アプリケーションニーズに基づいてこのメトリクスの独自のアラームしきい値を決定することをお勧めします。
*CurrConnections* の値が大きくなった場合、アプリケーションに問題があることを示している可能性があります。アプリケーション動作を調査してこの問題を解決する必要があります。
## メモリ
メモリは Valkey および Redis OSS の中核的な側面です。クラスターのメモリ使用率を理解することは、データの損失を回避し、データセットの将来の増加に対応するために必要です。ノードのメモリ使用率に関する統計は、[INFO](https://valkey.io/commands/info) コマンドのメモリセクションで確認できます。
## ネットワーク
クラスターのネットワーク帯域幅容量の決定要因の 1 つは、選択したノードの種類です。ノードのネットワーク容量の詳細については、「[Amazon MemoryDB 料金表](https://aws.amazon.com/memorydb/pricing/)」を参照してください。
## レイテンシー
レイテンシーメトリクス `SuccessfulWriteRequestLatency` および `SuccessfulReadRequestLatency` は、Valkey エンジンの MemoryDB がリクエストに応答するのにかかる合計時間を測定します。
**注記**
Valkey クライアントで CLIENT REPLY を有効にして Valkey パイプラインを使用すると、`SuccessfulWriteRequestLatency` および `SuccessfulReadRequestLatency` メトリクスの値が異常に大きくなる可能性があります。Valkey パイプラインは、個々のコマンドへの応答を待たずに複数のコマンドを一度に実行することでパフォーマンスを向上させる手法です。値が異常に大きくなるのを防ぐために、[CLIENT REPLY OFF](https://valkey.io/commands/client-reply/) の状態でコマンドをパイプラインするように Redis クライアントを設定することをお勧めします。
## レプリケーション
レプリケーションされるデータの量は、`ReplicationBytes` メトリクスを介して見ることができます。レプリケーション容量のスループットに対して`MaxReplicationThroughput` を監視できます。レプリケーション容量のスループットが最大になったら、シャードを追加することをお勧めします。
`ReplicationDelayedWriteCommands` はまた、ワークロードが最大レプリケーション容量スループットを超えているかどうかもわかります。MemoryDB でのレプリケーションの詳細については、「[MemoryDB レプリケーションの概要](https://docs.aws.amazon.com/memorydb/latest/devguide/replication.html)」を参照してください
# メトリクスの統計と期間の選択
CloudWatch では、各メトリクスの統計および期間を選択できますが、すべての組み合わせが役に立つとは言えません。例えば、CPUUtilization の Average、Minimum、および Maximum 統計は役に立ちますが、Sum 統計は役に立ちません。
MemoryDB のすべてのサンプルは、個々のノードに対して 60 秒間発行されています。任意の 60 秒間において、ノードメトリクスに含められるサンプルは 1 つだけです。
# CloudWatch メトリクスを使用したモニタリング
MemoryDB と CloudWatch は、多様なメトリクスを収集できるように統合されています。CloudWatch を使用して、これらのメトリクスをモニタリングできます。
**注記**
次の例には、CloudWatch コマンドラインツールが必要です。CloudWatch の詳細とデベロッパーツールのダウンロードについては、「[CloudWatch 製品ページ](https://aws.amazon.com/cloudwatch)」を参照してください。
次の手順は、CloudWatch を使用して、過去 1 時間のクラスターのストレージ領域統計を収集する方法を示しています。
**注記**
以下の例で指定されている `StartTime` 値と `EndTime` 値は、例示を目的としています。実際のノードに適した開始時刻値および終了時刻値で置き換える必要があります。
MemoryDB の制限について詳しくは、「[AWS MemoryDB のサービス制限](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_memorydb)」を参照してください。
## CloudWatch メトリクスをモニタリングする (コンソール)
**クラスターの CPU 使用率統計を収集するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) で MemoryDB のコンソールを開きます。
1. メトリクスを表示するノードを選択します。
**注記**
20 個を超えるノードを選択すると、コンソールでメトリクスを表示できなくなります。
1. AWS マネジメントコンソールの **[クラスター]** ページで、1 つ以上のキャッシュクラスターの名前をクリックします。
クラスターの詳細ページが表示されます。
1. ウィンドウ上部にある **Nodes** タブをクリックします。
1. 詳細ウィンドウの **[ノード]** タブで、メトリクスを表示するキャッシュノードを選択します。
使用可能な CloudWatch メトリクスのリストがコンソールウィンドウの下部に表示されます。
1. **CPU Utilization** メトリクスをクリックします。
CloudWatch コンソールが開き、選択されたメトリクスが表示されます。**Statistic** および **Period** ドロップダウンリストボックスや **Time Range** タブを使用すると、表示されるメトリクスを変更できます。
## CloudWatch CLI を使用した CloudWatch メトリクスのモニタリング
**クラスターの CPU 使用率統計を収集するには**
+ 以下のパラメータを指定して、CloudWatch コマンド **aws cloudwatch get-metric-statistics** を使用します (示されている開始時刻と終了時刻は例です。適切な開始時刻と終了時刻に置き換える必要があります)。
Linux、macOS、Unix の場合:
```
1. aws cloudwatch get-metric-statistics CPUUtilization \
2. --dimensions=ClusterName=mycluster,NodeId=0002" \
3. --statistics=Average \
4. --namespace="AWS/MemoryDB" \
5. --start-time 2013-07-05T00:00:00 \
6. --end-time 2013-07-06T00:00:00 \
7. --period=60
```
Windows の場合:
```
1. mon-get-stats CPUUtilization ^
2. --dimensions=ClusterName=mycluster,NodeId=0002" ^
3. --statistics=Average ^
4. --namespace="AWS/MemoryDB" ^
5. --start-time 2013-07-05T00:00:00 ^
6. --end-time 2013-07-06T00:00:00 ^
7. --period=60
```
## CloudWatch API を使用した CloudWatch メトリックスのモニタリング
**クラスターの CPU 使用率統計を収集するには**
+ 以下のパラメータを指定して、CloudWatch API `GetMetricStatistics` を呼び出します（示されている開始時刻と終了時刻は例です。適切な開始時刻と終了時刻に置き換える必要があります）。
+ `Statistics.member.1``=Average`
+ `Namespace``=AWS/MemoryDB`
+ `StartTime``=2013-07-05T00:00:00`
+ `EndTime``=2013-07-06T00:00:00`
+ `Period``=60`
+ `MeasureName``=CPUUtilization`
+ `Dimensions``=ClusterName=mycluster,NodeId=0002`
**Example**
```
1. http://monitoring.amazonaws.com/
2. ?SignatureVersion=4
3. &Action=GetMetricStatistics
4. &Version=2014-12-01
5. &StartTime=2013-07-16T00:00:00
6. &EndTime=2013-07-16T00:02:00
7. &Period=60
8. &Statistics.member.1=Average
9. &Dimensions.member.1="ClusterName=mycluster"
10. &Dimensions.member.2="NodeId=0002"
11. &Namespace=Amazon/memorydb
12. &MeasureName=CPUUtilization
13. &Timestamp=2013-07-07T17%3A48%3A21.746Z
14. &AWS;AccessKeyId=<&AWS; Access Key ID>
15. &Signature=
```
# MemoryDB イベントのモニタリング
重要なイベントがクラスター上で発生すると、MemoryDB から特定の Amazon SNS トピックに通知が送信されます。例には、ノードの追加の失敗、ノードの追加の成功、セキュリティグループの変更などが含まれます。主要イベントをモニタリングすることで、クラスターの現在の状態を知り、イベントに基づいて是正措置を取ることができます。
**Topics**
+ [
# MemoryDB Amazon SNS 通知の管理
](mdbevents.sns.md)
+ [
# MemoryDB イベントの表示
](mdbevents.viewing.md)
+ [
# イベント通知と Amazon SNS
](memorydbsns.md)
# MemoryDB Amazon SNS 通知の管理
Amazon Simple Notification Service (Amazon SNS) を使用して重要なクラスターイベントの通知が送信されるように MemoryDB を設定できます。これらの例では、Amazon SNS トピックの Amazon リソースネーム（ARN）を使用してクラスターを設定し、通知を受け取るようにします。
**注記**
このトピックでは、Amazon SNS にサインアップし、Amazon SNS トピックをセットアップおよびサブスクライブしていることを前提としています。これを行う方法の詳細については、「[Amazon Simple Notification Service デベロッパーガイド](https://docs.aws.amazon.com/sns/latest/dg/)」を参照してください。
## Amazon SNS トピックを追加する
以下のセクションでは、Amazon SNS トピックを AWS コンソール、AWS CLI、または MemoryDB API を使用して追加する方法について説明します。
### Amazon SNS トピックを追加する (コンソール)
以下の手順は、クラスターの Amazon SNS トピックを追加する方法を示しています。
**注記**
このプロセスは、Amazon SNS トピックの変更に使用できます。
**クラスターの Amazon SNS トピックを追加または変更するには (コンソール)**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) で MemoryDB のコンソールを開きます。
1. **クラスター** で、Amazon SNS トピック ARN を追加または変更するクラスターを選択します。
1. **変更**を選択します。
1. **クラスターを変更** の **SNS 通知のトピック** で、追加する SNS トピックを選択します。または、**手動 ARN 入力** を選択して Amazon SNS トピックの ARN を入力します。
1. **変更**を選択します。
### Amazon SNS トピックを追加する (AWS CLI)
クラスターの Amazon SNS トピックを追加または変更するには、AWS CLI コマンド `update-cluster` を使用します。
次のコード例では、Amazon SNS トピック ARN を *my-cluster* に追加します。
Linux、macOS、Unix の場合:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--sns-topic-arn arn:aws:sns:us-east-1:565419523791:memorydbNotifications
```
Windows の場合:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--sns-topic-arn arn:aws:sns:us-east-1:565419523791:memorydbNotifications
```
詳細については、「[UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html)」を参照してください。
### Amazon SNS トピックを追加する (MemoryDB API)
クラスターの Amazon SNS トピックを追加または変更するには、以下のパラメータを指定して `UpdateCluster` アクションを呼び出します。
+ `ClusterName``=my-cluster`
+ `SnsTopicArn``=arn%3Aaws%3Asns%3Aus-east-1%3A565419523791%3AmemorydbNotifications`
クラスターの Amazon SNS トピックを追加または更新するには、`UpdateCluster` アクションを呼び出します。
詳細については、「[クラスターの更新](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html)」を参照してください。
## Amazon SNS 通知の有効化と無効化
クラスターでは、通知を有効または無効にすることができます。次の手順は、Amazon SNS 通知を無効にする方法を示しています。
### Amazon SNS 通知の有効化と無効化（コンソール）
**AWS マネジメントコンソール を使用して Amazon SNS 通知を無効にするには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) で MemoryDB のコンソールを開きます。
1. 通知を変更するクラスターの左側にあるラジオボタンを選択します。
1. **変更**を選択します。
1. **クラスターを変更** の **SNS 通知のトピック** で、*通知を無効にする* を選択します。
1. **変更**を選択します。
### Amazon SNS 通知の有効化と無効化（AWS CLI)
Amazon SNS 通知を無効にするには、以下のパラメータを指定して `update-cluster` コマンドを使用します。
Linux、macOS、Unix の場合:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--sns-topic-status inactive
```
Windows の場合:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--sns-topic-status inactive
```
### Amazon SNS 通知の有効化と無効化 (MemoryDB API)
Amazon SNS 通知を無効にするには、以下のパラメータを指定して `UpdateCluster` アクションを呼び出します。
+ `ClusterName``=my-cluster`
+ `SnsTopicStatus``=inactive`
この呼び出しにより、以下のような出力が返されます。
**Example**
```
1. https://memory-db.us-east-1.amazonaws.com/
2. ?Action=UpdateCluster
3. &ClusterName=my-cluster
4. &SnsTopicStatus=inactive
5. &Version=2021-01-01
6. &SignatureVersion=4
7. &SignatureMethod=HmacSHA256
8. &Timestamp=20210801T220302Z
9. &X-Amz-Algorithm=Amazon4-HMAC-SHA256
10. &X-Amz-Date=20210801T220302Z
11. &X-Amz-SignedHeaders=Host
12. &X-Amz-Expires=20210801T220302Z
13. &X-Amz-Credential=
14. &X-Amz-Signature=
```
# MemoryDB イベントの表示
MemoryDB は、クラスターのインスタンス、セキュリティグループ、パラメータグループに関連するイベントを記録します。この情報には、イベントの日付と時刻、イベントのソース名とソースタイプ、イベントの説明などがあります。MemoryDB コンソール、AWS CLI `describe-events` コマンド、またはMemoryDB API アクション `DescribeEvents` を使用して、ログから簡単にイベントを取得できます。
次の手順は、過去 24 時間 (1440 分) のすべての MemoryDB イベントを表示する方法を示しています。
## MemoryDB イベントの表示 (コンソール)
次の手順は、MemoryDB コンソールを使用してイベントを表示します。
**MemoryDB コンソールを使用してイベント表示するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) で MemoryDB のコンソールを開きます。
1. 左側のナビゲーションペインで **イベント** を選択します。
*イベント*画面が開き、利用可能なすべてのイベントが一覧表示されます。Events 画面のリスト内の各行は 1 個のイベントを表し、イベントのソース、イベントの種類 (キャッシュクラスター、キャッシュパラメータグループ、キャッシュセキュリティグループ、キャッシュサブネットグループ)、イベントの GMT 時間、イベントの説明が表示されます。
**Filter** を使用して、イベントリストにすべてのイベントを表示するか特定タイプのイベントのみを表示するかを指定できます。
## メモリデータベースイベントの表示 (AWS CLI)
AWS CLI を使用して MemoryDB イベントのリストを作成するには、`describe-events` コマンドを使用します。オプションパラメータを使用して、一覧されるイベントのタイプ、イベントの期間、イベント一覧の最大数などを制御できます。
次のコードでは、最大 40 個のクラスターイベントを一覧表示します。
```
aws memorydb describe-events --source-type cluster --max-results 40
```
次のコードでは、過去 24 時間 (1440 分) のすべてのイベントを一覧表示します。
```
aws memorydb describe-events --duration 1440
```
`describe-events` のコマンドによる出力は次のようになります。
```
{
"Events": [
{
"Date": "2021-03-29T22:17:37.781Z",
"Message": "Added node 0001 in Availability Zone us-east-1a",
"SourceName": "memorydb01",
"SourceType": "cluster"
},
{
"Date": "2021-03-29T22:17:37.769Z",
"Message": "cluster created",
"SourceName": "memorydb01",
"SourceType": "cluster"
}
]
}
```
使用できるパラメータおよび許可されたパラメータ値などの詳細については、「[https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html)」を参照してください。
## MemoryDB イベントの表示 (MemoryDB API)
MemoryDB API を使用して MemoryDB イベントのリストを生成するには、`DescribeEvents` アクションを使用します。オプションパラメータを使用して、一覧されるイベントのタイプ、イベントの期間、イベント一覧の最大数などを制御できます。
次のコードは、40 個の最新のクラスターイベントを一覧します。
```
https://memory-db.us-east-1.amazonaws.com/
?Action=DescribeEvents
&MaxResults=40
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SourceType=cluster
&Timestamp=20210802T192317Z
&Version=2021-01-01
&X-Amz-Credential=
```
次のコードは、過去 24 時間 (1440 分) のクラスターイベントを一覧します。
```
https://memory-db.us-east-1.amazonaws.com/
?Action=DescribeEvents
&Duration=1440
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SourceType=cluster
&Timestamp=20210802T192317Z
&Version=2021-01-01
&X-Amz-Credential=
```
上記のアクションでは、次のような出力が生成されます。
```
cluster created
cluster
2021-08-02T18:22:18.202Z
my-memorydb-primary
(...output omitted...)
e21c81b4-b9cd-11e3-8a16-7978bb24ffdf
```
使用できるパラメータおよび許可されたパラメータ値などの詳細については、「[https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html)」を参照してください。
# イベント通知と Amazon SNS
MemoryDBは、クラスターで重要なイベントが発生したときに、Amazon Simple Notification Service (SNS) を使用してメッセージを発行できます。この機能を使用すると、クラスターの個々のノードエンドポイントに接続されたクライアントコンピュータでサーバーリストを更新できます。
**注記**
価格の情報やAmazon SNS ドキュメントへのリンクを含む、Amazon Simple Notification Service (SNS) の詳細については、「[Amazon SNS 製品ページ](https://aws.amazon.com/sns)」を参照してください。
通知は、指定した Amazon SNS *トピック* に発行されます。通知の要件は以下のとおりです:
+ MemoryDB 通知に対して設定できるトピックは 1 つだけです。
+ Amazon SNS トピックを所有する AWS アカウントは、通知が有効になっているクラスターを所有するアカウントと同じアカウントである必要があります。
## MemoryDB イベント
以下の MemoryDB イベントにより、Amazon SNS 通知がトリガーされます:
| イベント名 | メッセージ | 説明 |
| --- | --- | --- |
| MemoryDB: ノード追加が完了しました | "Modified number of nodes from %d to %d" | ノードがクラスターに追加され、使用可能になっています。 |
| IPアドレスの空き不足による MemoryDB:AddNodeFailed | "Failed to modify number of nodes from %d to %d due to insufficient free IP addresses" | 利用可能なIPアドレスが不足しているため、ノードを追加できませんでした。 |
| MemoryDB: ClusterParametersChanged | "Updated parameter group for the cluster" 作成の場合は、`"Updated to use a ParameterGroup %s"` も送ります。 | 1 つ以上のクラスターパラメータが変更されました。 |
| MemoryDB: クラスタープロビジョニングが完了しました | "Cluster created." | クラスターのプロビジョニングが完了し、クラスター内のノードが使用可能になりました。 |
| MemoryDB: 互換性のないネットワーク状態のため、クラスタープロビジョニングに失敗しました | "Failed to create cluster due to incompatible network state. %s" | 存在しない 仮想プライベートクラウド (VPC) に新しいキャッシュクラスターに起動する試みが行われました。 |
| MemoryDB: クラスターの復元に失敗しました | "Restore from %s failed for node %s. %s" | MemoryDB はスナップショットデータをクラスターに入力できませんでした。これは、Amazon S3 にスナップショットファイルが存在しないか、そのファイルに対する不適切なアクセス許可が原因である可能性があります。クラスターを記述する場合は、ステータスは `restore-failed` です。クラスターを削除して最初からやり直す必要があります。 詳細については、「[外部で作成されたスナップショットによる新しいクラスターのシード](snapshots-seeding-redis.md)」を参照してください。 |
| MemoryDB: クラスタースケーリングが完了しました | `"Succeeded applying modification to node type to %s."` | キャッシュクラスターのスケールアップが正常に完了しました。 |
| MemoryDB: クラスタースケーリングに失敗しました | `"Failed applying modification to node type to %s."` | クラスターのスケールアップが失敗しました。 |
| MemoryDB:NodeReplaceStarted | "Recovering node %s" | MemoryDB が、ノードを実行しているホストのパフォーマンスが低下しているか、到達できないことを検出したため、ノードの置き換えを開始しました。 置き換えられたノードの DNS エントリは変更されません。 ほとんどのインスタンスでは、このイベントが発生したときにクライアントのサーバーリストを更新する必要はありません。ただし、一部のクライアントライブラリは、MemoryDB がノードを置き換えた後でもノードの使用を停止する可能性があります。この場合、このイベントが発生したとき、アプリケーションがサーバーリストを更新する必要があります。 |
| MemoryDB:NodeReplaceComplete | "Finished recovery for node %s" | MemoryDB が、ノードを実行しているホストのパフォーマンスが低下しているか、到達できないことを検出したため、ノードの置き換えを完了しました。 置き換えられたノードの DNS エントリは変更されません。 ほとんどのインスタンスでは、このイベントが発生したときにクライアントのサーバーリストを更新する必要はありません。ただし、一部のクライアントライブラリは、MemoryDB がノードを置き換えた後でもノードの使用を停止する可能性があります。この場合、このイベントが発生したとき、アプリケーションがサーバーリストを更新する必要があります。 |
| MemoryDB:CreateClusterComplete | "Cluster created" | クラスターが正常に作成されました。 |
| MemoryDB:CreateClusterFailed | "Failed to create cluster due to unsuccessful creation of its node(s)." および "Deleting all nodes belonging to this cluster." | クラスターは作成されませんでした。 |
| MemoryDB:DeleteClusterComplete | "Cluster deleted." | クラスターと関連するすべてのアプリケーションノードの削除が完了しました。 |
| MemoryDB:FailoverComplete | `"Failover to replica node %s completed"` | レプリカノードへのフェイルオーバーが成功しました。 |
| MemoryDB:NodeReplacementCanceled | "The replacement of node %s which was scheduled during the maintenance window from start time: %s, end time: %s has been canceled" | 置き換え対象となっていたクラスター内のノードが置き換え対象ではなくなりました。 |
| MemoryDB:NodeReplacementRescheduled | "The replacement in maintenance window for node %s has been re-scheduled from previous start time: %s, previous end time: %s to new start time: %s, new end time: %s" | 以前置き換え対象になったクラスター内のノードのスケジュールが、通知に記載されている新しい期間に変更されました。 実行可能なアクションについては、「[ノードの置換](nodes.nodereplacement.md)」を参照してください。 |
| MemoryDB:NodeReplacementScheduled | "The node %s is scheduled for replacement during the maintenance window from start time: %s to end time: %s" | クラスター内のノードが、通知に記載されている期間中の置き換え対象となりました。 実行可能なアクションについては、「[ノードの置換](nodes.nodereplacement.md)」を参照してください。 |
| MemoryDB:RemoveNodeComplete | "Removed node %s" | ノードがクラスターから削除されました。 |
| MemoryDB:SnapshotComplete | "Snapshot %s succeeded for node %s" | スナップショットの作成が正常に完了しました。 |
| MemoryDB:SnapshotFailed | "Snapshot %s failed for node %s" | スナップショットが失敗しました。詳細な原因については、クラスターのイベントを参照してください。 [DescribeSnapshots](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSnapshots.html)を参照してスナップショットを記述する場合は、ステータスは `failed`です。 |
# AWS CloudTrail で MemoryDB API 呼び出しをログに記録する
MemoryDB は AWS CloudTrail と統合されており、これにより、ユーザー、ロール、または AWS サービスによって MemoryDB で実行されたアクションの記録を提供しています。CloudTrail は、MemoryDB のコンソールからの呼び出しや、MemoryDB API オペレーションへのコードからの呼び出しなど、MemoryDB のすべての API 呼び出しをイベントとしてキャプチャします。証跡を作成する場合は、MemoryDB のイベントを含む CloudTrail イベントを Amazon S3 バケットに継続的に配信できます。証跡を設定しない場合でも、CloudTrail コンソールの **[イベント履歴]** で最新のイベントを表示できます。CloudTrail によって収集された情報を使用して、MemoryDB に対して行われたリクエスト、リクエストが行われた IP アドレス、リクエストを行った人、リクエストが行われた日時、その他の詳細を特定できます。
CloudTrail の詳細については、 『[AWS CloudTrail ユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)』を参照してください。
## CloudTrail の MemoryDB 情報
AWS アカウントを作成すると、そのアカウントに対して CloudTrail が有効になります。アクティビティが MemoryDB で発生すると、そのアクティビティは **[イベント履歴]** にある他の AWS サービスイベントと共に CloudTrail イベントに記録されます。最近のイベントは、AWSアカウントで表示、検索、ダウンロードできます。詳細については、 「[CloudTrail イベント履歴でのイベントの表示](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)」を参照してください。
MemoryDB のイベントなど、AWS アカウントのイベントの継続的な記録については、証跡を作成します。[Trail] (追跡) により、CloudTrail はログファイルを Simple Storage Service (Amazon S3) バケットに配信できます。デフォルトでは、コンソールで追跡を作成するときに、追跡がすべてのリージョンに適用されます。証跡は AWS パーティションのすべてのリージョンからのイベントをログに記録し、指定した Amazon S3 バケットにログファイルを配信します。さらに、CloudTrail ログで収集したイベントデータをより詳細に分析し、それに基づいて対応するため、他の AWS サービスを構成できます。詳細については、次を参照してください:
+ [証跡の作成のための概要](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail がサポートするサービスと統合](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [CloudTrail 用 Amazon SNS 通知の構成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [複数のリージョンから CloudTrail ログファイルを受け取る](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html)および[複数のアカウントから CloudTrail ログファイルを受け取る](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
すべての MemoryDB アクションは、CloudTrail によりログに記録されます。例えば、`CreateCluster`、`DescribeClusters`、`UpdateCluster` の各アクションを呼び出すと、CloudTrail ログファイルにエントリが生成されます。
各イベントまたはログエントリには、誰がリクエストを生成したかという情報が含まれます。同一性情報は次の判断に役立ちます。
+ リクエストが、ルートと IAM ユーザー認証情報のどちらを使用して送信されたか。
+ リクエストがロールまたはフェデレーションユーザーの一時的なセキュリティ認証情報を使用して行われたかどうか。
+ リクエストが別の AWS サービスによって行われたかどうか。
詳細については、「[CloudTrail userIdentity 要素](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html)」を参照してください。
## MemoryDB のログファイルエントリについて
「トレイル」は、指定した Amazon S3 バケットにイベントをログファイルとして配信するように設定できます。CloudTrail のログファイルは、単一か複数のログエントリを含みます。イベントはあらゆるソースからの単一のリクエストを表し、リクエストされたアクション、アクションの日時、リクエストのパラメータなどの情報が含まれます。CloudTrail ログファイルは、パブリック API コールの順序付けられたスタックトレースではないため、特定の順序では表示されません。
次は、`CreateCluster` アクションを示す CloudTrail ログエントリの例です。
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T17:56:46Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "CreateCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.create-cluster",
"requestParameters": {
"clusterName": "memorydb-cluster",
"nodeType": "db.r6g.large",
"subnetGroupName": "memorydb-subnet-group",
"aCLName": "open-access"
},
"responseElements": {
"cluster": {
"name": "memorydb-cluster",
"status": "creating",
"numberOfShards": 1,
"availabilityMode": "MultiAZ",
"clusterEndpoint": {
"port": 6379
},
"nodeType": "db.r6g.large",
"engineVersion": "6.2",
"enginePatchVersion": "6.2.6",
"parameterGroupName": "default.memorydb-redis6",
"parameterGroupStatus": "in-sync",
"subnetGroupName": "memorydb-subnet-group",
"tLSEnabled": true,
"aRN": "arn:aws:memorydb:us-east-1:123456789012:cluster/memorydb-cluster",
"snapshotRetentionLimit": 0,
"maintenanceWindow": "tue:06:30-tue:07:30",
"snapshotWindow": "09:00-10:00",
"aCLName": "open-access",
"dataTiering": "false",
"autoMinorVersionUpgrade": true
}
},
"requestID": "506fc951-9ae2-42bb-872c-98028dc8ed11",
"eventID": "2ecf3dc3-c931-4df0-a2b3-be90b596697e",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
以下の例は、`DescribeClusters` アクションを示す CloudTrail ログエントリです。MemoryDB Describe および List 呼び出し (`Describe*` および `List*`) では、`responseElements` セクションが削除され、`null` として表示されることに注意してください。
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T18:39:51Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "DescribeClusters",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.describe-clusters",
"requestParameters": {
"maxResults": 50,
"showShardDetails": true
},
"responseElements": null,
"requestID": "5e831993-52bb-494d-9bba-338a117c2389",
"eventID": "32a3dc0a-31c8-4218-b889-1a6310b7dd50",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
次の例では `UpdateCluster` アクションを記録する CloudTrail のログエントリを示します。
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T19:23:20Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "UpdateCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.update-cluster",
"requestParameters": {
"clusterName": "memorydb-cluster",
"snapshotWindow": "04:00-05:00",
"shardConfiguration": {
"shardCount": 2
}
},
"responseElements": {
"cluster": {
"name": "memorydb-cluster",
"status": "updating",
"numberOfShards": 2,
"availabilityMode": "MultiAZ",
"clusterEndpoint": {
"address": "clustercfg.memorydb-cluster.cde8da.memorydb.us-east-1.amazonaws.com",
"port": 6379
},
"nodeType": "db.r6g.large",
"engineVersion": "6.2",
"EnginePatchVersion": "6.2.6",
"parameterGroupName": "default.memorydb-redis6",
"parameterGroupStatus": "in-sync",
"subnetGroupName": "memorydb-subnet-group",
"tLSEnabled": true,
"aRN": "arn:aws:memorydb:us-east-1:123456789012:cluster/memorydb-cluster",
"snapshotRetentionLimit": 0,
"maintenanceWindow": "tue:06:30-tue:07:30",
"snapshotWindow": "04:00-05:00",
"autoMinorVersionUpgrade": true,
"DataTiering": "false"
}
},
"requestID": "dad021ce-d161-4365-8085-574133afab54",
"eventID": "e0120f85-ab7e-4ad4-ae78-43ba15dee3d8",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
以下の例は、`CreateUser` アクションを示す CloudTrail ログエントリです。機密データを含む MemoryDB の呼び出しの場合、そのデータは以下の `requestParameters` セクションに示されるように、対応する CloudTrail イベントで削除されることに注意してください。
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T19:56:13Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "CreateUser",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.create-user",
"requestParameters": {
"userName": "memorydb-user",
"authenticationMode": {
"type": "password",
"passwords": [
"HIDDEN_DUE_TO_SECURITY_REASONS"
]
},
"accessString": "~* &* -@all +@read"
},
"responseElements": {
"user": {
"name": "memorydb-user",
"status": "active",
"accessString": "off ~* &* -@all +@read",
"aCLNames": [],
"minimumEngineVersion": "6.2",
"authentication": {
"type": "password",
"passwordCount": 1
},
"aRN": "arn:aws:memorydb:us-east-1:123456789012:user/memorydb-user"
}
},
"requestID": "ae288b5e-80ab-4ff8-989a-5ee5c67cd193",
"eventID": "ed096e3e-16f1-4a23-866c-0baa6ec769f6",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
# MemoryDB のコンプライアンス検証
サードパーティーの監査者は、さまざまな AWS コンプライアンスプログラムの一環として MemoryDB のセキュリティとコンプライアンスを評価します。これには、以下が含まれます。
+ Payment Card Industry Data Security Standard (PCI DSS)。詳細については、「[PCI DSS](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/)」を参照してください。
+ 医療保険の相互運用性と説明責任に関する法律の事業提携契約 (HIPAA BAA)。詳細については、「[HIPAA コンプライアンス](https://aws.amazon.com/compliance/hipaa-compliance)」を参照してください。
+ System and Organization Controls (SOC) 1、2、および 3。詳細については、「[SOC](https://aws.amazon.com/compliance/soc-faqs)」を参照してください。
+ Federal Risk and Authorization Management Program (FedRAMP) Moderate。詳細については、「[FedRAMP](https://aws.amazon.com/compliance/services-in-scope/FedRAMP/)」を参照してください。
+ ISO/IEC 27001:2013、27017:2015、27018:2019、および ISO/IEC 9001:2015。詳細については、「[AWS ISO and CSA STAR certifications and services](https://aws.amazon.com/compliance/iso-certified/)」を参照してください。
特定のコンプライアンスプログラムの対象範囲に含まれる AWS のサービスのリストについては、「[コンプライアンスプログラムによる対象範囲内の AWS のサービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
AWS Artifact を使用して、サードパーティーの監査レポートをダウンロードできます。詳細については、「[AWS Artifact でレポートをダウンロードする](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)」を参照してください。
MemoryDB を使用する際のユーザーのコンプライアンス責任は、ユーザーのデータの機密性や貴社のコンプライアンス目的、適用される法律および規制によって決まります。AWS では、コンプライアンスに役立つ以下のリソースを提供しています。
+ [セキュリティおよびコンプライアンスのクイックスタートガイド](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance) – これらのデプロイガイドでは、アーキテクチャ上の考慮事項について説明し、セキュリティとコンプライアンスに重点を置いたベースライン環境を AWS でデプロイするための手順を説明します。
+ [AWS コンプライアンスリソース](https://aws.amazon.com/compliance/resources/) – このワークブックおよびガイドのコレクションは、お客様の業界と拠点に適用される場合があります。
+ *AWS Config デベロッパーガイド*の「[ルールでのリソースの評価](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)」– AWS Config は、リソース設定が、社内のプラクティス、業界のガイドラインそして規制にどの程度適合しているのかを評価します。
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – この AWS のサービスは、AWS 内でのユーザーのセキュリティ状態に関する包括的な見解を提供し、業界のセキュリティ標準、およびベストプラクティスに対するコンプライアンスを確認するために役立ちます。
+ [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html) – この AWS サービスでは、AWS の使用状況を継続的に監査し、リスクの管理方法と、規制や業界標準へのコンプライアンスの管理方法を簡素化できます。
# MemoryDB のインフラストラクチャセキュリティ
マネージドサービスである MemoryDB は、ホワイトペーパー「[Amazon Web Services: セキュリティプロセスの概要](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf)」に記載されている AWS グローバルネットワークセキュリティの手順で保護されています。
AWS が発行している API コールを使用して、ネットワーク経由で MemoryDB にアクセスします。クライアントは、Transport Layer Security (TLS) 1.2 以降をサポートする必要があります。TLS 1.3 以降が推奨されます。また、一時的ディフィー・ヘルマン Ephemeral Diffie-Hellman (DHE) や Elliptic Curve Ephemeral Diffie-Hellman (ECDHE) などの Perfect Forward Secrecy (PFS) を使用した暗号スイートもクライアントでサポートされている必要があります。これらのモードは、Java 7 以降など、最近のほとんどのシステムでサポートされています。
また、リクエストは、アクセスキー ID と、IAM プリンシパルに関連付けられているシークレットアクセスキーを使用して署名する必要があります。または、[AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html)AWS STSを使用して、一時的なセキュリティ認証情報を生成し、リクエストに署名することもできます。
# ネットワーク間のトラフィックのプライバシー
MemoryDB では、以下の方法によりデータを不正なアクセスからセキュリティで保護します。
+ **[MemoryDB と Amazon VPC](vpcs.md)** では、インストールに必要なセキュリティグループのタイプを説明します。
+ **[MemoryDB API とインターフェイス VPC エンドポイント (AWS PrivateLink)](memorydb-privatelink.md)** は VPC と MemoryDB API エンドポイントの間にプライベート接続を確立できます。
+ **[MemoryDB でのアイデンティティとアクセス権の管理](iam.md)** は、ユーザー、グループ、グループ、ロールの付与と制限のためのものです。
# MemoryDB と Amazon VPC
Amazon Virtual Private Cloud (Amazon VPC) サービスは、従来のデータセンターに非常によく似た仮想ネットワークを定義します。お客様が Amazon VPCで仮想プライベートクラウド（VPC）を設定すると、IP アドレス範囲の選択、サブネットの作成、ルートテーブル、ネットワークゲートウェイ、セキュリティの設定などが可能になります。仮想ネットワークにクラスターを追加でき、Amazon VPC のセキュリティグループを使用して、クラスターへのアクセスを制御できます。
このセクションでは、VPC 内で手動で MemoryDB クラスターを設定する方法を説明します。この情報は、MemoryDB と Amazon VPC との連携について理解を深めたいユーザーを対象としています。
**Topics**
+ [
# MemoryDB と VPC について
](vpcs.mdb.md)
+ [
# Amazon VPC の MemoryDB クラスターにアクセスするためのアクセスパターン
](memorydb-vpc-accessing.md)
+ [
# Virtual Private Cloud (VPC) の作成
](VPCs.creatingVPC.md)
# MemoryDB と VPC について
MemoryDB は Amazon VPC と完全に統合されています。MemoryDB ユーザーにとって、これは次のことを意味します。
+ MemoryDB は常に VPC でクラスターを起動します。
+ AWS を初めて使用する場合は、デフォルト VPC が自動的に作成されます。
+ デフォルト VPC をお持ちのお客様が、クラスター起動時にサブネットを指定しなかった場合は、そのクラスターはお客様のデフォルト Amazon VPC で起動されます。
詳細については、「[サポートされているプラットフォームとデフォルト VPC があるかどうかを確認する](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html#detecting-platform)」を参照してください。
Amazon VPCを使用することによって、従来のデータセンターに非常によく似た仮想ネットワークを AWS クラウド内に作成できます。お客様の VPC はお客様が設定できます。例えば、IP アドレス範囲の選択、サブネットの作成、ルートテーブル、ネットワークゲートウェイ、セキュリティの設定などが可能です。
MemoryDB では、ソフトウェアのアップグレード、パッチ、障害検出、および復旧を管理します。
## VPC での MemoryDB の概要
+ VPC は、独自の IP アドレスのブロックが割り当てられた AWS クラウドの独立した部分です。
+ インターネットゲートウェイは VPC を直接インターネットに接続し、他の AWS リソースへのアクセスを提供します。それには、VPC の外部で実行されている Amazon Simple Storage Service (Amazon S3) などのリソースが含まれます。
+ VPC サブネットは、セキュリティおよび運用上のニーズに合わせて AWS リソースを分離できる Amazon VPC の IP アドレス範囲のセグメントです。
+ Amazon VPC セキュリティグループは、MemoryDB クラスターと Amazon EC2 インスタンスのインバウンドとアウトバウンドのトラフィックを制御します。
+ サブネットで MemoryDB クラスターを起動できます。ノードは、サブネットのアドレス範囲のプライベート IP アドレスを持ちます。
+ サブネットで Amazon EC2 インスタンスを起動することもできます。各 Amazon EC2 インスタンスはサブネットのアドレス範囲内のプライベート IP アドレスを持ちます。Amazon EC2 インスタンスは、同じサブネット内のすべてのノードに接続できます。
+ インターネットからアクセス可能な VPC 内の Amazon EC2 インスタンスの場合は、インスタンスに Elastic IP アドレスと呼ばれる静的なパブリックアドレスを割り当てる必要があります。
## 前提条件
VPC 内に MemoryDB クラスターを作成するには、VPC が次の要件を満たしている必要があります。
+ VPCは、専用ではない Amazon EC2 インスタンスを許可する必要があります。ハードウェア専有インスタンスのテナンシー用に設定された VPC では、MemoryDB を使用できません。
+ VPC 用にサブネットグループを定義する必要があります。MemoryDB はそのキャッシュサブネットグループを使用して、そのサブネット内でノードに関連付けるサブネットおよび IP アドレスを選択します。
+ VPC 用にセキュリティグループを定義する必要があります。または、用意されているデフォルトを使用できます。
+ 各サブネットの CIDR ブロックは、メンテナンス作業で使用する予備の IP アドレスを MemoryDB に提供するのに十分な大きさが必要です。
## ルーティングとセキュリティ
VPC でルーティングを設定して、トラフィックの送信先（インターネットゲートウェイ、仮想プライベートゲートウェイなど）を制御できます。インターネットゲートウェイの場合、VPC は、同じ VPC で実行されているのではない他の AWS リソースに直接アクセスできます。お客様の組織のローカルネットワークに接続された仮想プライベートゲートウェイのみを選択した場合、VPN 経由でインターネット宛てのトラフィックをルーティングし、ローカルセキュリティポリシーとファイアウォールを使用して出口を制御できます。この場合、インターネット経由で AWS リソースにアクセスする際に、追加の帯域幅料金が発生します。
Amazon VPC セキュリティグループを使用して、Amazon VPC 内の MemoryDB クラスターと Amazon EC2 インスタンスをセキュリティで保護することができます。セキュリティグループは、サブネットレベルでなくインスタンスレベルでファイアウォールのように動作します。
**注記**
基礎となる IP アドレスは変わる可能性があるため、ノードに接続するには DNS 名を使用することを強くお勧めします。
## Amazon VPC ドキュメント
Amazon VPC に関するドキュメントには、Amazon VPC の作成および使用方法について説明する独自のドキュメントがあります。Amazon VPC ガイドの情報の参照先について以下の表にまとめます。
| 説明 | ドキュメント |
| --- | --- |
| Amazon VPC の使用を開始する方法 | [Amazon VPC の開始方法](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-getting-started.html) |
| AWS マネジメントコンソール を通じて Amazon VPC を使用する方法 | [Amazon VPC User Guide](https://docs.aws.amazon.com/vpc/latest/userguide/) |
| すべての Amazon VPC コマンドの詳細説明 | [Amazon EC2 コマンドラインリファレンス](https://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/) (Amazon VPC コマンドは、Amazon EC2 リファレンスに記載されています) |
| Amazon VPC API オペレーション、データタイプ、およびエラーの詳細説明 | [Amazon EC2 API リファレンス](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/) (Amazon VPC API オペレーションは、Amazon EC2 リファレンスに記載されています) |
| オプションとして IPsec VPN 接続のゲートウェイを設定する必要のあるネットワーク管理者向け情報 | [AWS Site-to-Site VPN とは](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) |
Amazon Virtual Private Cloud の詳細については、「[Amazon Virtual Private Cloud](https://aws.amazon.com/vpc/)」を参照してください。
# Amazon VPC の MemoryDB クラスターにアクセスするためのアクセスパターン
MemoryDB は、Amazon VPC 内のクラスターにアクセスするための以下のシナリオをサポートしています。
**Contents**
+ [
## MemoryDB クラスターと Amazon EC2 インスタンスが同じ Amazon VPC にある場合の MemoryDB クラスターへのアクセス
](#memorydb-vpc-accessing-same-vpc)
+ [
## MemoryDB クラスターと Amazon EC2 インスタンスが異なる Amazon VPC にある場合のアクセス
](#memorydb-vpc-accessing-different-vpc)
+ [同じリージョンの異なる VPC 内](#memorydb-vpc-accessing-different-vpc-same-region)
+ [トランジット・ゲートウェイ の使用](#memorydb-vpc-accessing-using-transit-gateway)
+ [異なるリージョンの異なる VPC 内](#memorydb-vpc-accessing-different-vpc-different-region)
+ [トランジット VPC の使用](#memorydb-vpc-accessing-different-vpc-different-region-using-transit-vpc)
+ [
## 顧客のデータセンター内で実行されるアプリケーションからの MemoryDB クラスターへのアクセス
](#memorydb-vpc-accessing-data-center)
+ [VPN 接続を使用したアクセス](#memorydb-vpc-accessing-data-center-vpn)
+ [Direct Connect の使用](#memorydb-vpc-accessing-data-center-direct-connect)
## MemoryDB クラスターと Amazon EC2 インスタンスが同じ Amazon VPC にある場合の MemoryDB クラスターへのアクセス
最も一般的ユースケースは、EC2 インスタンスにデプロイされたアプリケーションが同じ VPC のクラスターに接続する必要がある場合です。
同じ VPC 内の EC2 インスタンスとクラスター間のアクセスを管理する方法として最も簡単なのは、次の方法です。
1. クラスターの VPC セキュリティグループを作成します。このセキュリティグループを使用して、クラスターへのアクセスを制限できます。例えば、クラスターを作成したときに割り当てたポートと、クラスターにアクセスするのに使用する IP アドレスを使用して TCP へのアクセスを許可する、このセキュリティグループのカスタムルールを作成できます。
MemoryDB クラスターのデフォルトのポートは `6379` です。
1. EC2 インスタンス (ウェブサーバーとアプリケーションサーバー) 用の VPC セキュリティグループを作成します。このセキュリティグループは、必要に応じて VPC のルーティングテーブルを介してインターネットから EC2 インスタンスへのアクセスを許可できます。例えば、ポート 22 経由で EC2 インスタンスへの TCP アクセスを許可するルールをこのセキュリティグループに設定できます。
1. EC2 インスタンス用に作成したセキュリティグループからの接続を許可するクラスターのセキュリティグループで、カスタムルールを作成します。これは、セキュリティグループのメンバーにクラスターへのアクセスを許可します。
**他のセキュリティグループからの接続を許可する VPC セキュリティグループでルールを作成するには**
1. AWS マネジメントコンソールにサインインして、Amazon VPC コンソール ([https://console.aws.amazon.com/vpc](https://console.aws.amazon.com/vpc)) を開きます。
1. 左のナビゲーションペインで **セキュリティグループ**を選択します。
1. クラスターに使用するセキュリティグループを選択または作成します。**インバウンドルール** で、**インバウンドルールの編集** を選択し、**ルールの追加** を選択します。このセキュリティグループは、他のセキュリティグループのメンバーへのアクセスを許可します。
1. **Type** で **Custom TCP Rule** を選択します。
1. **Port Range** ポートには、クラスター作成時に使用したポートを指定します。
MemoryDB クラスターのデフォルトのポートは `6379` です。
1. **ソース** ボックスに、セキュリティグループの ID の入力を開始します。リストから、Amazon EC2 インスタンスに使用するセキュリティグループを選択します。
1. 終了したら、**保存** を選択します。
## MemoryDB クラスターと Amazon EC2 インスタンスが異なる Amazon VPC にある場合のアクセス
クラスターにアクセスするために使用している EC2 インスタンスとは別の VPC にクラスターがある場合、クラスターにアクセスするにはいくつかの方法がある。クラスターとEC2インスタンスが異なるVPCにあるが、同じリージョンにある場合は、VPCピアリングを使用できる。クラスターとEC2インスタンスが異なるリージョンにある場合、リージョン間でVPN接続を作成できる。
**Topics**
+ [同じリージョンの異なる VPC 内](#memorydb-vpc-accessing-different-vpc-same-region)
+ [異なるリージョンの異なる VPC 内](#memorydb-vpc-accessing-different-vpc-different-region)
### MemoryDB クラスターと Amazon EC2 インスタンスが同じリージョン内の異なる Amazon VPC にある場合のアクセス
*同じリージョンの異なる Amazon VPC で Amazon EC2 インスタンスによってアクセスされるクラスター - VPC ピア接続*
VPC ピア接続は、プライベート IP アドレスを使用して 2 つの VPC 間でトラフィックをルーティングすることを可能にするネットワーク接続です。どちらの VPC のインスタンスも、同じネットワーク内に存在しているかのように、相互に通信できます。VPC ピア接続は、自分の Amazon VPC 間、または、1 つのリージョン内の他の AWS アカウントにある Amazon VPC との間に作成できます。Amazon VPC ピア接続の詳細については、「[VPC ドキュメント](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html)」を参照してください。
**ピア接続経由で別の Amazon VPC のクラスターにアクセスするには**
1. 2 つの VPC に、重複する IP 範囲がないことを確認します。重複する IP 範囲がある場合、それらをピア接続することができません。
1. 2 つの VPC をピア接続します。詳細については、「[VPC ピア接続の作成と使用](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/create-vpc-peering-connection.html)」を参照してください。
1. ルーティングテーブルを更新します。詳細については、「[VPC ピア接続のルートテーブルを更新する](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/vpc-peering-routing.html)」を参照してください
1. MemoryDBクラスターのセキュリティグループを変更し、ピアリングされたVPCのApplication Security Groupからのインバウンド接続を許可します。詳細については、「[ピア VPC セキュリティグループの参照](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/vpc-peering-security-groups.html)」を参照してください。
ピア接続によりクラスターにアクセスすると、追加のデータ転送コストが発生します。
#### トランジット・ゲートウェイ の使用
トランジットゲートウェイを使用すると、同じ AWS リージョンに VPC と VPN 接続をアタッチして、それらの間でトラフィックをルーティングできます。トランジットゲートウェイは AWS アカウント間で機能し、AWS Resource Access Manager を使用してトランジットゲートウェイを他のアカウントと共有できます。他のAWSアカウントとトランジットゲートウェイを共有した後、アカウントの所有者はトランジットゲートウェイにそれらの VPC をアタッチすることができます。どちらのアカウントのユーザーも、アタッチメントをいつでも削除できます。
トランジットゲートウェイでマルチキャストを有効にしてから、ドメインに関連付ける VPC アタッチメントを介してマルチキャストソースからマルチキャストグループメンバーにマルチキャストトラフィックを送信できるようにする トランジットゲートウェイマルチキャストドメインを作成できます。
また、異なるAWSリージョンでトランジットゲートウェイ間にピア接続アタッチメントを作成することもできます。これにより、異なるリージョン間でトランジットゲートウェイのアタッチメント間でトラフィックをルーティングできます。
詳細については、「[トランジットゲートウェイ](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html)」を参照してください。
### MemoryDB クラスターと Amazon EC2 インスタンスが異なるリージョン内の異なる Amazon VPC にある場合のアクセス
#### トランジット VPC の使用
VPC ピアリングの代わりに使用する、複数の、地理的に離れた VPC とリモートネットワークを接続する別の一般的な方法は、グローバルなネットワーク中継センターとして機能する中継 VPC の作成です。中継 VPC はネットワーク管理を単純化して、複数の VPC とリモートのネットワークを接続するために必要な接続数を最小限に抑えます。この設計は、コロケーション中継ハブを物理的に設立したり、物理的なネットワーク設備をデプロイしたりするための従来の費用をほとんどかけずに実装できるため、時間と労力を節約し、コストも削減できます。
*異なるリージョンの異なる VPC 間での接続*
Transit Amazon VPCが確立されると、あるリージョンの "スポーク "VPCにデプロイされたアプリケーションは、別のリージョン内の "スポーク "VPCにあるMemoryDBクラスターに接続することができます。
**別の AWS リージョン内の異なる VPC のクラスターにアクセスするには**
1. Transit VPC ソリューションをデプロイします。詳細については、「[AWS トランジットゲートウェイ](https://aws.amazon.com/transit-gateway/)」を参照してください。
1. アプリとVPCのVPCルーティングテーブルを更新して、VGW（Virtual Private Gateway）とVPNアプライアンスを経由するトラフィックをルーティングします。ボーダーゲートウェイプロトコル (BGP) を使用した動的ルーティングの場合、ルートは自動的に伝達される可能性があります。
1. MemoryDBクラスターのセキュリティグループを変更して、アプリケーションインスタンスの IP 範囲からのインバウンド接続を許可します。このシナリオでは、アプリケーションサーバーセキュリティグループを参照することはできません。
リージョン間でクラスターにアクセスすると、ネットワークのレイテンシーが生じ、リージョン間のデータ転送コストが追加で発生します。
## 顧客のデータセンター内で実行されるアプリケーションからの MemoryDB クラスターへのアクセス
もう 1 つのシナリオとして、クライアントまたは顧客のデータセンター内のアプリケーションが VPC の MemoryDB クラスターにアクセスする必要がある場合のようなハイブリッドアーキテクチャが考えられます。このシナリオは、顧客の VPC とデータセンター間で VPN または Direct Connect による接続がある場合にサポートされます。
**Topics**
+ [VPN 接続を使用したアクセス](#memorydb-vpc-accessing-data-center-vpn)
+ [Direct Connect の使用](#memorydb-vpc-accessing-data-center-direct-connect)
### 顧客のデータセンター内で実行されるアプリケーションからの VPN 接続を使用した MemoryDB クラスターへのアクセス
VPN によるデータセンターから MemoryDB への接続
**VPN 接続経由でオンプレミスアプリケーションから VPC のクラスターにアクセスするには**
1. VPC にハードウェア仮想プライベートゲートウェイを追加して、VPN 接続を確立します。詳細については、「[VPC へのハードウェア仮想プライベートゲートウェイの追加](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html)」を参照してください。
1. MemoryDB クラスターがデプロイされているサブネットの VPC ルーティングテーブルを更新して、オンプレミスアプリケーションサーバーからのトラフィックを許可します。BGP を使用した動的ルーティングの場合、ルートは自動的に伝達される可能性があります。
1. MemoryDB クラスターのセキュリティグループを変更して、オンプレミスアプリケーションサーバーからのインバウンド接続を許可します。
VPN 接続経由でクラスターにアクセスすると、ネットワークのレイテンシーが生じ、追加のデータ転送コストが発生します。
### 顧客のデータセンター内で実行されるアプリケーションからの Direct Connect を使用した MemoryDB クラスターへのアクセス
Direct Connect によるデータセンターから MemoryDB への接続
**Direct Connect を使用して、ネットワークで実行されるアプリケーションから MemoryDB クラスターにアクセスするには**
1. Direct Connect 接続を確立します。詳細については、「[AWS Direct Connect 入門ガイド](https://docs.aws.amazon.com/directconnect/latest/UserGuide/getting_started.html)」を参照してください。
1. MemoryDB クラスターのセキュリティグループを変更して、オンプレミスアプリケーションサーバーからのインバウンド接続を許可します。
DX 接続経由でクラスターにアクセスすると、ネットワークのレイテンシーが生じ、追加のデータ転送料金が発生する場合があります。
# Virtual Private Cloud (VPC) の作成
この例では、各アベイラビリティーゾーンのプライベートサブネットを持つ Amazon VPCサービスに基づいて仮想プライベートクラウド（VPC）を作成します。
## VPC の作成 (コンソール)
**Amazon Virtual Private Cloud 内に MemoryDB キャッシュクラスターを作成するには**
1. AWS マネジメントコンソールにサインインして Amazon VPC コンソール ([https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)) を開きます。
1. VPC ダッシュボードで、**[VPC を作成]** を選択します。
1. **Resources to create** (作成するリソース) で、**VPC only** (VPC など) を選択します。
1. **Number of Availability Zones (AZs)** (アベイラビリティーゾーンの数 (AZ)) で、サブネットを起動するアベイラビリティーゾーンの数を選択します。
1. **Number of public subnets** (パブリックサブネットの数) で、VPC に追加するパブリックサブネットの数を選択します。
1. **Number of private subnets** (プライベートサブネットの数) で、VPC に追加するプライベートサブネットの数を選択します。
**ヒント**
サブネットの識別子と、どちらがパブリックで、どちらがプライベートであるかを書き留めておきます。この情報は、後でクラスターを起動し、Amazon VPC に Amazon EC2 インスタンスを追加するときに必要になります。
1. Amazon VPC セキュリティグループを作成します。クラスターと Amazon EC2 インスタンスでは、このグループを使用します。
1. AWS マネジメントコンソール の左のナビゲーションペインで **[セキュリティグループ]** を選択します。
1. **Create Security Group** (セキュリティグループの作成) を選択します。
1. 対応するボックスにセキュリティグループの名前と説明を入力します。**[VPC]** の ID を選択します。
1. すべての設定が正しいことを確認したら、**Yes, Create** を選択します。
1. セキュリティグループのネットワーク Ingress ルールを定義します。このルールは、Secure Shell (SSH) を使用して Amazon EC2 インスタンスに接続することを許可します。
1. 左のナビゲーションペインで **セキュリティグループ**を選択します。
1. リストで対象となるセキュリティグループを探して選択します。
1. **Security Group** の下で、**Inbound** タブを選択します。**Create a new rule** ボックスで、**SSH** を選択し、**Add Rule** を選択します。
新しいインバウンドルールに次の値を設定して、HTTP へのアクセスを許可します。
+ Type: HTTP
+ ソース: 0.0.0.0/0
1. 新しいインバウンドルールに次の値を設定して、HTTP へのアクセスを許可します。
+ Type: HTTP
+ ソース: 0.0.0.0/0
**Apply Rule Changes** を選択します。
これで、VPC内に[サブネットグループ](https://docs.aws.amazon.com/memorydb/latest/devguide/subnetgroups.html)を作成し、[クラスターを作成する](https://docs.aws.amazon.com/memorydb/latest/devguide/getting-started.createcluster.html)準備が整いました。
# サブネットおよびサブネットグループ
サブネットグループ** は、Amazon Virtual Private Cloud (VPC) 環境で実行しているクラスターに対して指定できるサブネット (通常はプライベート) の集合です。
Amazon VPC でクラスターを作成する場合、サブネットグループを指定するか、デフォルトで提供されるサブネットグループを使用できます。MemoryDB はそのキャッシュサブネットグループを使用して、そのサブネット内でノードに関連付けるサブネットおよび IP アドレスを選択します。
このセクションでは、サブネットおよびサブネットグループを作成し活用して、MemoryDB リソースへのアクセスを管理する方法を扱います。
Amazon VPC 環境でのサブネットグループの使用方法の詳細については、「[ステップ 3: クラスターへのアクセスの許可](getting-started.md#getting-started.authorizeaccess)」を参照してください。
**サポートされている MemoryDB AZ ID**
| リージョン名/リージョン | サポートされる AZ ID |
| --- | --- |
| 米国東部 (オハイオ) リージョン `us-east-2` | `use2-az1, use2-az2, use2-az3` |
| 米国東部(バージニア州北部) リージョン `us-east-1` | `use1-az1, use1-az2, use1-az4, use1-az5, use1-az6` |
| US West (N. California) リージョン `us-west-1` | `usw1-az1, usw1-az2, usw1-az3` |
| 米国西部 (オレゴン) リージョン `us-west-2` | `usw2-az1, usw2-az2, usw2-az3, usw2-az4` |
| カナダ (中部) リージョン `ca-central-1` | `cac1-az1, cac1-az2, cac1-az4` |
| アジアパシフィック (香港) リージョン `ap-east-1` | `ape1-az1, ape1-az2, ape1-az3` |
| アジアパシフィック (ムンバイ) リージョン `ap-south-1` | `aps1-az1, aps1-az2, aps1-az3` |
| アジアパシフィック (東京) リージョン `ap-northeast-1` | `apne1-az1, apne1-az2, apne1-az4` |
| Asia Pacific (Seoul) Region `ap-northeast-2` | `apne2-az1, apne2-az2, apne2-az3` |
| アジアパシフィック (シンガポール) リージョン `ap-southeast-1` | `apse1-az1, apse1-az2, apse1-az3` |
| アジアパシフィック (シドニー) リージョン `ap-southeast-2` | apse2-az1, apse2-az2, apse2-az3 |
| 欧州 (フランクフルト) リージョン `eu-central-1` | `euc1-az1, euc1-az2, euc1-az3` |
| 欧州 (アイルランド) リージョン `eu-west-1` | `euw1-az1, euw1-az2, euw1-az3` |
| 欧州 (ロンドン) リージョン `eu-west-2` | `euw2-az1, euw2-az2, euw2-az3` |
| 欧州 (パリ) リージョン `eu-west-3` | `euw3-az1, euw3-az2, euw3-az3` |
| 欧州 (ストックホルム) リージョン `eu-north-1` | `eun1-az1, eun1-az2, eun1-az3 ` |
| 欧州 (ミラノ) リージョン `eu-south-1` | `eus1-az1, eus1-az2, eus1-az3 ` |
| 南米 (サンパウロ) リージョン `sa-east-1` | `sae1-az1, sae1-az2, sae1-az3` |
| 中国 (北京) リージョン `cn-north-1` | `cnn1-az1, cnn1-az2` |
| 中国 (寧夏) リージョン `cn-northwest-1` | `cnw1-az1, cnw1-az2, cnw1-az3` |
| `us-gov-east-1` | `usge1-az1, usge1-az2, usge1-az3` |
| `us-gov-west-1` | `usgw1-az1, usgw1-az2, usgw1-az3` |
| 欧州 (スペイン) リージョン `eu-south-2` | `eus2-az1, eus2-az2, eus2-az3` |
**Topics**
+ [
# MemoryDB と IPV6
](subnetgroups.ipv6.md)
+ [
# サブネットグループの作成
](subnetgroups.creating.md)
+ [
# サブネットグループの更新
](subnetgroups.modifying.md)
+ [
# サブネットグループの詳細の表示
](subnetgroups.Viewing.md)
+ [
# サブネットグループの削除
](subnetgroups.deleting.md)
# MemoryDB と IPV6
デュアルスタックおよび ipv6 専用サブネットをサブネットグループに提供することで、Valkey エンジンと Redis OSS エンジンの両方を備えた新しいデュアルスタックおよび ipv6 専用クラスターを作成できます。既存のクラスターのネットワークタイプを変更することはできません。
この機能を使用すると、次のことができます。
+ デュアルスタックサブネットに ipv4 専用およびデュアルスタッククラスターを作成する。
+ ipv6 専用サブネットに ipv6 専用クラスターを作成する。
+ ipv4 専用、デュアルスタック、および ipv6 専用サブネットをサポートする新しいサブネットグループを作成する。
+ 既存のサブネットグループを、基盤となる VPC の追加のサブネットを含むように変更する。
+ サブネットグループの既存のサブネットを変更する
+ IPv6 専用サブネットを、IPv6 用に設定されたサブネットグループに追加する
+ IPv4 およびデュアルスタックをサポートするように設定されたサブネットグループに IPv4 またはデュアルスタックサブネットを追加する
+ デュアルスタックおよび ipv6 クラスター用のエンジン検出コマンドを使用して、ipv4 アドレスまたは ipv6 アドレスを持つクラスター内のノードをすべて検出する。このような検出コマンドには、`redis_info` や `redis_cluster` などがあります。
+ デュアルスタックおよび ipv6 クラスター用の DNS 検出コマンドを使用して、クラスター内のすべてのノードの ipv4 アドレスと ipv6 アドレスを検出する。
# サブネットグループの作成
新しいサブネットグループを作成する場合は、使用可能な IP アドレス数に注意してください。サブネットの空き IP アドレス数が非常に少ない場合は、クラスターに追加できるノード数が制約される可能性があります。この問題を解決するために、クラスターのアベイラビリティーゾーンで十分な数の IP アドレスを使用できるように、サブネットグループに 1 つ以上のサブネットを割り当てることができます。その後で、クラスターにノードを追加できます。
以下の手順では、`mysubnetgroup` (コンソール)、AWS CLI、および MemoryDB API というサブネットグループを作成する方法を示します。
## サブネットグループの作成 (コンソール)
次の手順では、サブネットグループ (コンソール) を作成する方法を示します。
**サブネットグループ (コンソール) を作成するには**
1. AWS マネジメントコンソールにサインインし、 ([https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)) MemoryDBのコンソールを開きます。
1. 左のナビゲーションペインで、**[サブネットグループ]** を選択します。
1. **Create Subnet Group** を選択します。
1. **[サブネットグループの作成]** ウィンドウで次の操作を行います。
1. **Name** ボックスにサブネットグループの名前を入力します。
クラスターの命名に関する制約は次のとおりです。
+ 1～40 個の英数字またはハイフンを使用する必要があります。
+ 先頭は文字を使用する必要があります。
+ 連続する 2 つのハイフンを含めることはできません。
+ ハイフンで終わることはできません。
1. **Description** ボックスにサブネットグループの説明を入力します。
1. **VPC ID** ボックスで、作成した Amazon VPC を選択します。まだ作成していない場合は、**[VPC を作成]** ボタンを選択し、手順に従って作成してください。
1. **[選択されたサブネット]** でプライベートサブネットのアベイラビリティーゾーンと ID を選択し、**[選択]** を選択します。
1. **[タグ]** では、オプションでタグを適用してサブネットを検索およびフィルタリングしたり、AWS のコストを追跡したりできます。
1. すべての設定が正しいことを確認したら、**[作成]** を選択します。
1. 表示された確認メッセージで、**Close** を選択します。
MemoryDB コンソールの **[サブネットグループ]** のリストに新しい DB サブネットグループが表示されます。ウィンドウの下部で、サブネットグループを選択して、ウィンドウの下部で詳細 (このグループに関連付けられているすべてのサブネットなど) を確認します。
## サブネットグループの作成 AWS
コマンドプロンプトで、`create-subnet-group` コマンドを使用してサブネットグループを作成します。
Linux、macOS、Unix の場合:
```
aws memorydb create-subnet-group \
--subnet-group-name mysubnetgroup \
--description "Testing" \
--subnet-ids subnet-53df9c3a
```
Windows の場合:
```
aws memorydb create-subnet-group ^
--subnet-group-name mysubnetgroup ^
--description "Testing" ^
--subnet-ids subnet-53df9c3a
```
このコマンドでは、次のような出力が生成されます。
```
{
"SubnetGroup": {
"Subnets": [
{
"Identifier": "subnet-53df9c3a",
"AvailabilityZone": {
"Name": "us-east-1a"
}
}
],
"VpcId": "vpc-3cfaef47",
"Name": "mysubnetgroup",
"ARN": "arn:aws:memorydb:us-east-1:012345678912:subnetgroup/mysubnetgroup",
"Description": "Testing"
}
}
```
詳細については、AWS CLI のトピック「[create-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-subnet-group.html)」を参照してください。
## サブネットグループの作成 (MemoryDB API)
以下のパラメータを指定して、MemoryDB API を使用して `CreateSubnetGroup` を呼び出します。
+ `SubnetGroupName=``mysubnetgroup`
+ `Description=``Testing`
+ `SubnetIds.member.1=``subnet-53df9c3a`
# サブネットグループの更新
サブネットグループの説明を更新することや、サブネットグループに関連付けられたサブネット ID のリストを変更することができます。クラスターが現在サブネットを使用している場合、サブネットグループからそのサブネット ID を削除することはできません。
次の手順では、サブネットグループを更新する方法を示します。
## サブネットグループの更新 (コンソール)
**サブネットグループを更新するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) で MemoryDB のコンソールを開きます。
1. 左のナビゲーションペインで、**[サブネットグループ]** を選択します。
1. サブネットグループのリストで、変更するグループを選択します。
1. **[名前]**、**[VPC ID]**、**[説明]** フィールドは変更できません。
1. **[選択されたサブネット]** セクションで **[管理]** をクリックし、サブネットに必要なアベイラビリティーゾーンに変更を加えます。変更を保存するには**保存**を選択します。
## サブネットグループの更新 (AWS CLI)
コマンドプロンプトで、`update-subnet-group` コマンドを使用してサブネットグループを更新します。
Linux、macOS、Unix の場合:
```
aws memorydb update-subnet-group \
--subnet-group-name mysubnetgroup \
--description "New description" \
--subnet-ids "subnet-42df9c3a" "subnet-48fc21a9"
```
Windows の場合:
```
aws memorydb update-subnet-group ^
--subnet-group-name mysubnetgroup ^
--description "New description" ^
--subnet-ids "subnet-42df9c3a" "subnet-48fc21a9"
```
このコマンドでは、次のような出力が生成されます。
```
{
"SubnetGroup": {
"VpcId": "vpc-73cd3c17",
"Description": "New description",
"Subnets": [
{
"Identifier": "subnet-42dcf93a",
"AvailabilityZone": {
"Name": "us-east-1a"
}
},
{
"Identifier": "subnet-48fc12a9",
"AvailabilityZone": {
"Name": "us-east-1a"
}
}
],
"Name": "mysubnetgroup",
"ARN": "arn:aws:memorydb:us-east-1:012345678912:subnetgroup/mysubnetgroup",
}
}
```
詳細については、AWS CLI のトピック「[update-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-subnet-group.html)」を参照してください。
## サブネットグループの更新 (MemoryDB API)
以下のパラメータを指定して、MemoryDB API を使用して `UpdateSubnetGroup` を呼び出します。
+ `SubnetGroupName=``mysubnetgroup`
+ 変更したいその他のパラメーター値。この例では、`Description=``New%20description` を使用してサブネットグループの説明を変更します。
**Example**
```
https://memory-db.us-east-1.amazonaws.com/
?Action=UpdateSubnetGroup
&Description=New%20description
&SubnetGroupName=mysubnetgroup
&SubnetIds.member.1=subnet-42df9c3a
&SubnetIds.member.2=subnet-48fc21a9
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=Amazon4-HMAC-SHA256
&X-Amz-Credential=
&X-Amz-Date=20141201T220302Z
&X-Amz-Expires=20141201T220302Z
&X-Amz-Signature=
&X-Amz-SignedHeaders=Host
```
**注記**
新しいサブネットグループを作成する場合は、使用可能な IP アドレス数に注意してください。サブネットの空き IP アドレス数が非常に少ない場合は、クラスターに追加できるノード数が制約される可能性があります。この問題を解決するために、クラスターのアベイラビリティーゾーンで十分な数の IP アドレスを使用できるように、サブネットグループに 1 つ以上のサブネットを割り当てることができます。その後で、クラスターにノードを追加できます。
# サブネットグループの詳細の表示
次の手順では、サブネットグループの詳細を表示する方法を示します。
## サブネットグループの詳細の表示 (コンソール)
**サブネットグループの詳細を表示するには (コンソール)**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) で MemoryDB のコンソールを開きます。
1. 左のナビゲーションペインで、**[サブネットグループ]** を選択します。
1. **[サブネットグループ]** ページで、**[名前]** の下にあるサブネットグループを選択するか、検索バーにサブネットグループの名前を入力します。
1. **[サブネットグループ]** ページで、**[名前]** の下にあるサブネットグループを選択するか、検索バーにサブネットグループの名前を入力します。
1. **[サブネットグループ設定]** では、サブネットグループの名前、説明、VPC ID、Amazon リソースネーム (ARN) を表示できます。
1. **[サブネット]** では、サブネットグループのアベイラビリティーゾーン、サブネット ID、CIDR ブロックを表示できます
1. **[タグ]** には、サブネットグループに関連付けられているすべてのタグが表示されます。
## サブネットグループの詳細の表示 (AWS CLI)
コマンドプロンプトで、コマンド `describe-subnet-groups` を使用して、指定したサブネットグループの詳細の情報を表示します。
Linux、macOS、Unix の場合:
```
aws memorydb describe-subnet-groups \
--subnet-group-name mysubnetgroup
```
Windows の場合:
```
aws memorydb describe-subnet-groups ^
--subnet-group-name mysubnetgroup
```
このコマンドでは、次のような出力が生成されます。
```
{
"subnetgroups": [
{
"Subnets": [
{
"Identifier": "subnet-060cae3464095de6e",
"AvailabilityZone": {
"Name": "us-east-1a"
}
},
{
"Identifier": "subnet-049d11d4aa78700c3",
"AvailabilityZone": {
"Name": "us-east-1c"
}
},
{
"Identifier": "subnet-0389d4c4157c1edb4",
"AvailabilityZone": {
"Name": "us-east-1d"
}
}
],
"VpcId": "vpc-036a8150d4300bcf2",
"Name": "mysubnetgroup",
"ARN": "arn:aws:memorydb:us-east-1:53791xzzz7620:subnetgroup/mysubnetgroup",
"Description": "test"
}
]
}
```
すべてのサブネットグループの詳細を表示するには、サブネットグループ名を指定せずに同じコマンドを使用します。
```
aws memorydb describe-subnet-groups
```
詳細については、AWS CLI のトピック「[describe-subnet-groups](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-subnet-group.html)」を参照してください。
## サブネットグループの表示 (MemoryDB API)
以下のパラメータを指定して、MemoryDB API を使用して `DescribeSubnetGroups` を呼び出します。
`SubnetGroupName=``mysubnetgroup`
**Example**
```
https://memory-db.us-east-1.amazonaws.com/
?Action=UpdateSubnetGroup
&Description=New%20description
&SubnetGroupName=mysubnetgroup
&SubnetIds.member.1=subnet-42df9c3a
&SubnetIds.member.2=subnet-48fc21a9
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Timestamp=20211801T220302Z
&Version=2021-01-01
&X-Amz-Algorithm=Amazon4-HMAC-SHA256
&X-Amz-Credential=
&X-Amz-Date=20210801T220302Z
&X-Amz-Expires=20210801T220302Z
&X-Amz-Signature=
&X-Amz-SignedHeaders=Host
```
# サブネットグループの削除
サブネットグループが必要ではなくなったと判断した場合、サブネットグループを削除できます。サブネットグループがクラスターで現在使用されている場合、サブネットグループを削除できません。また、マルチ AZ が有効になっているクラスターのサブネットグループを削除したときに、そのクラスターのサブネット数が 2 つ未満になる場合は、サブネットグループを削除できません。最初に **[マルチ AZ]** のチェックを外し無効にしてから、サブネットを削除する必要があります。
次の手順では、サブネットグループを削除する方法を示します。
## サブネットグループの削除 (コンソール)
**サブネットグループを削除するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) で MemoryDB のコンソールを開きます。
1. 左のナビゲーションペインで、**[サブネットグループ]** を選択します。
1. サブネットグループのリストで、削除する項目 **[アクション]** をクリックしてから、**[削除]** を選択します。
**注記**
デフォルトのサブネットグループやクラスターに関連付けられているサブネットグループは削除できません。
1. **[サブネットグループの削除]** の確認画面が表示されます。
1. サブネットグループを削除するには、確認テキストボックスに `delete` を入力します。サブネットグループを保持するには、**キャンセル** を選択します。
## サブネットグループの削除 AWS
AWS CLI を使用して、以下のパラメーターでコマンド **delete-subnet-group** を呼び出します。
+ `--subnet-group-name` *mysubnetgroup*
Linux、macOS、Unix の場合:
```
aws memorydb delete-subnet-group \
--subnet-group-name mysubnetgroup
```
Windows の場合:
```
aws memorydb delete-subnet-group ^
--subnet-group-name mysubnetgroup
```
詳細については、AWS CLI のトピック「[delete-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-subnet-group.html)」を参照してください。
## サブネットグループの削除 (MemoryDB API)
以下のパラメータを指定して、MemoryDB API を使用して `DeleteSubnetGroup` を呼び出します。
+ `SubnetGroupName=mysubnetgroup`
**Example**
```
https://memory-db.us-east-1.amazonaws.com/
?Action=DeleteSubnetGroup
&SubnetGroupName=mysubnetgroup
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Timestamp=20210801T220302Z
&Version=2021-01-01
&X-Amz-Algorithm=Amazon4-HMAC-SHA256
&X-Amz-Credential=
&X-Amz-Date=20210801T220302Z
&X-Amz-Expires=20210801T220302Z
&X-Amz-Signature=
&X-Amz-SignedHeaders=Host
```
このコマンドでは何も出力されません。
詳細については、MemoryDB API トピックの「[DeleteSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteSubnetGroup.html)」を参照してください。
# MemoryDB API とインターフェイス VPC エンドポイント (AWS PrivateLink)
*インターフェイス VPC エンドポイント*を作成して、VPC と Amazon MemoryDB API エンドポイント間にプライベート接続を確立できます。インターフェイスエンドポイントは を利用しています[AWS PrivateLink](https://aws.amazon.com/privatelink)。 AWS PrivateLink を使用すると、インターネットゲートウェイ、NAT デバイス、VPN 接続、または AWS Direct Connect 接続を使用せずに、MemoryDB API オペレーションにプライベートにアクセスできます。
VPC のインスタンスは、パブリック IP アドレスがなくても MemoryDB API エンドポイントと通信できます。また、MemoryDB API オペレーションの使用にも、パブリック IP アドレスを必要としません。VPC と MemoryDB 間のトラフィックは、Amazon ネットワークを離れません。各インターフェイスエンドポイントは、サブネット内の 1 つ以上の Elastic Network Interface によって表されます。Elastic Network Interface の詳細については、*Amazon EC2 ユーザーガイド*の「[Elastic Network Interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)」を参照してください。
+ VPC エンドポイントの詳細については、*Amazon VPC ユーザーガイド*の「[インターフェイス VPC エンドポイント (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html)」を参照してください。
+ 「[MemoryDB API オペレーション](https://docs.aws.amazon.com/memorydb/latest/APIReference/Welcome.html)」の詳細については、「MemoryDB API オペレーション」を参照してください。
インターフェイス VPC エンドポイントを作成した後、エンドポイントの[プライベート DNS](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-private-dns) ホスト名を有効にすると、デフォルトの MemoryDB エンドポイント (https://memorydb.*Region*.amazonaws.com が VPC エンドポイントに解決されます。 プライベート DNS ホスト名を有効にしない場合は、Amazon VPC が以下の形式で使用できる DNS エンドポイント名を提供します。
```
VPC_Endpoint_ID.memorydb.Region.vpce.amazonaws.com
```
詳細については、Amazon [VPC ユーザーガイドの「インターフェイス VPC エンドポイント (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html)」を参照してください。 **MemoryDB は、VPC 内のすべての [API アクション](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_Operations.html)の呼び出しをサポートしています。
**注記**
プライベート DNS ホスト名は、VPC 内の 1 つの VPC エンドポイントに対してのみ有効にできます。追加の VPC エンドポイントを作成する場合は、プライベート DNS ホスト名を無効にする必要があります。
## VPC エンドポイントに関する考慮事項
MemoryDB API エンドポイントのインターフェイス VPC エンドポイントを設定する前に、*Amazon VPC ユーザーガイド* の「[インターフェイスエンドポイントのプロパティと制限](https://docs.aws.amazon.com/vpc/latest/privatelink/endpoint-services-overview.html)」を確認してください。MemoryDB リソースの管理に関連するすべての MemoryDB API オペレーションは、 AWS PrivateLinkを使用して VPC から利用できます。VPC エンドポイントポリシーは MemoryDB API エンドポイントでサポートされます。デフォルトでは、エンドポイント経由で MemoryDB API オペレーションへのフルアクセスが許可されます。詳細については、「*Amazon VPC ユーザーガイド*」の「[VPC エンドポイントによるサービスのアクセスコントロール](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html)」を参照してください。
### MemoryDB API 用のインターフェイス VPC エンドポイントの作成
MemoryDB API 用の VPC エンドポイントは、Amazon VPC コンソールまたは AWS CLIで作成できます。詳細については、「Amazon VPC ユーザーガイド」の[インターフェイスエンドポイントの作成](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html)を参照してください。
インターフェイス VPC エンドポイントを作成した後、エンドポイントのプライベート DNS ホスト名を有効にできます。実行すると、デフォルトの MemoryDB エンドポイント (https://memorydb.*Region*.amazonaws.com) が VPC エンドポイントに解決されます。詳細については、「Amazon VPC ユーザーガイド**」の「[インターフェイスエンドポイントを介したサービスへのアクセス](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#access-service-though-endpoint)」を参照してください。
### Amazon MemoryDB API 用の VPC エンドポイントポリシーの作成
VPC エンドポイントに MemoryDB API へのアクセスをコントロールするエンドポイントポリシーをアタッチできます。本ポリシーでは、以下を規定します。
+ アクションを実行できるプリンシパル。
+ 実行可能なアクション。
+ アクションを実行できるリソース。
詳細については、「*Amazon VPC ユーザーガイド*」の「[VPC エンドポイントでサービスへのアクセスを制御する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html)」を参照してください。
**Example MemoryDB API アクションの VPC エンドポイントポリシー**
MemoryDB API のエンドポイントポリシーの例を次に示します。このポリシーは、エンドポイントにアタッチされると、すべてのリソースのすべてのプリンシパルに対して、登録されている MemoryDB API アクションへのアクセスを許可します。
```
{
"Statement": [{
"Principal": "*",
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster",
"memorydb:UpdateCluster",
"memorydb:CreateSnapshot"
],
"Resource": "*"
}]
}
```
**Example 指定された AWS アカウントからのすべてのアクセスを拒否する VPC エンドポイントポリシー**
次の VPC エンドポイントポリシーは、 AWS アカウント *123456789012* がエンドポイントを使用したリソースへのすべてのアクセスを拒否します。このポリシーは、他のアカウントからのすべてのアクションを許可します。
```
{
"Statement": [{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": "*"
},
{
"Action": "*",
"Effect": "Deny",
"Resource": "*",
"Principal": {
"AWS": [
"123456789012"
]
}
}
]
}
```
# 共通脆弱性識別子 (CVE): MemoryDB で対処されたセキュリティ脆弱性
一般的な脆弱性と露出 (CVE) は、一般的に知られているサイバーセキュリティの脆弱性に関するエントリの一覧です。各エントリは、識別番号、説明、および少なくとも 1 つの公開リファレンスを含むリンクです。このページでは、MemoryDB で対処されたセキュリティ脆弱性のリストを確認できます。
MemoryDB を既知の脆弱性から保護するために、常に最新バージョンにアップグレードすることをお勧めします。MemoryDB は PATCH コンポーネントを公開します。パッチバージョンは、下位互換性のあるバグ修正、セキュリティ修正、非機能的な変更を目的とします。
以下の表を参照して、MemoryDB の特定のバージョンに特定のセキュリティ脆弱性に対する修正があるかどうかを確認できます。お使いの MemoryDB キャッシュがサービスの更新を保留している場合は、以下に示すセキュリティ脆弱性のいずれかに対して脆弱である可能性があります。サービスの更新を適用することをお勧めします。サポートされている MemoryDB エンジンのバージョンとアップグレード方法の詳細については、「[エンジンバージョン](engine-versions.md)」を参照してください。
**注記**
CVE が 1 つの MemoryDB バージョンで対処されている場合、それ以降のバージョンでも対処されていることを意味します。
以下の表のアスタリスク (\$1) は、セキュリティ脆弱性に対処するために、記載されているバージョンを実行している MemoryDB クラスターに最新のサービス更新を適用する必要があることを示しています。クラスターが実行されている MemoryDB バージョンに最新のサービス更新が適用されていることを確認する方法の詳細については、「[サービスの更新の管理](managing-updates.md)」を参照してください。
| MemoryDB バージョン | 対処された CVE |
| --- | --- |
| Valkey 7.3 および Valkey のそれ以前のすべてのバージョン Redis OSS 7.1 および Redis OSS のそれ以前のすべてのバージョン | [CVE-2025-49844](https://www.cve.org/CVERecord?id=CVE-2025-49844)\$1、[CVE-2025-46817](https://www.cve.org/CVERecord?id=CVE-2025-46817)\$1、[CVE-2025-46818](https://www.cve.org/CVERecord?id=CVE-2025-46818)\$1、[CVE-2025-46819](https://www.cve.org/CVERecord?id=CVE-2025-46819)\$1 |
| Valkey 7.2 および 7.3 | [CVE-2025-21607](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21607)\$1、[CVE-2025-21605](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21605)\$1、[CVE-2024-31449](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31449)\$1、[CVE-2024-31227](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31227)\$1、[CVE-2024-31228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31228)\$1 |
| Valkey 7.2.7 | [CVE-2024-51741](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-51741) |
| Redis OSS 7.1 および 6.2 | [CVE-2025-21605](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21605)\$1、[CVE-2024-31449](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31449)\$1、[CVE-2024-31227](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31227)\$1、[CVE-2024-31228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31228)\$1、[CVE-2023-41056](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41056) |
| Redis OSS 7.0.7 | [CVE-2023-41056](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41056)\$1 |
| Redis OSS 6.2.7 | [CVE-2024-46981](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-46981) |
| Redis OSS 6.2.6 | [CVE-2022-24834](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24834)\$1、[CVE-2022-35977](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-35977)\$1、[CVE-2022-36021](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-36021)\$1、[CVE-2023-22458](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-22458)、[CVE-2023-25155](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-25155)、[CVE-2023-28856](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-28856) [CVE-2023-45145](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-45145): この CVE は、Redis OSS 6.2 および 7.0 では対処されていますが、Redis OSS 7.1 では対処されていないことに注意してください。 |
| Redis OSS 6.0.5 | [CVE-2022-24735](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24735)\$1、[CVE-2022-24736](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24736)\$1 |
# MemoryDB のサービスの更新
MemoryDB は、サービスの更新が利用可能になったときに適用されるように、クラスターとノードのフリートを自動的にモニタリングします。通常、MemoryDB がこれらの更新を適用できるように、事前定義されたメンテナンスウィンドウを設定します。ただし、場合によっては、このアプローチが厳格すぎて、ビジネスフローが制限される可能性もあります。
[MemoryDB のサービスの更新](#service-updates)では、更新を適用するタイミングと内容を制御できます。選択した MemoryDB クラスターに対するこれらの更新の進行状況をリアルタイムでモニタリングすることもできます。
# サービスの更新の管理
MemoryDB のサービスの更新は定期的にリリースされています。これらのサービスの更新の対象となるクラスターが 1 つ以上ある場合は、更新がリリースされたときに、E メール、SNS、Personal Health Dashboard (PHD)、および Amazon CloudWatch Events より通知が送信されます。更新は、MemoryDB コンソールの **[サービスの更新]** ページにも表示されます。このダッシュボードを使用すると、MemoryDB フリートに関するサービスの更新とそのステータスをすべて表示できます。
自動更新を開始する前に、更新を適用するタイミングを制御します。最新のセキュリティパッチで MemoryDB を常に最新の状態に維持できるように、できるだけ早く **[セキュリティ更新]** タイプの更新を適用することを強くお勧めします。
以下のセクションでは、これらのオプションについて詳しく説明します。
**Topics**
+ [
## Amazon MemoryDB のマネージドメンテナンスとサービスの更新の概要
](#managing-updates-maintenance)
## Amazon MemoryDB のマネージドメンテナンスとサービスの更新の概要
当社は、インスタンスにシームレスに適用されるパッチとアップグレードを使用して、頻繁に MemoryDB フリートのアップグレードを行います。これには以下の 2 つの方法があります。
1. 継続的マネージドメンテナンス。
1. サービスの更新。
このメンテナンスとサービスの更新は、セキュリティ、信頼性、運用パフォーマンスを強化するアップグレードを適用するために必要です。
継続的マネージドメンテナンスは、ユーザーのアクションを必要とせずに、メンテナンスウィンドウ内で随時、直接行われます。メンテナンスウィンドウはすべてのお客様に必須であり、オプトアウトはできないことに注意してください。この設定されたメンテナンスウィンドウ中にクリティカルな、または重要なアクティビティを行わないようにすることを強く推奨します。また、システムのセキュリティと最適なパフォーマンスを確保するために、重要な更新はスキップできないことにも注意してください。
サービスの更新では、更新を自分の判断で柔軟に適用できます。サービスの更新には期限があります。期限が切れると、更新がメンテナンスウィンドウに移動され、当社によって適用される場合があります。
更新は、できるだけ早く適用することによって適切に管理できます。また、ノードの交換によって管理することもできます。交換時に自動的に更新が適用されるからです。次回のメンテナンスウィンドウの前に更新がすべてのノードに適用されている場合、次回のメンテナンスウィンドウ中に更新アクティビティが行われることはありません。
### サービスの更新
[MemoryDB のサービスの更新](service-updates.md)では、特定のサービス更新を自分の判断で適用できます。これらの更新には、セキュリティパッチとマイナーなソフトウェア更新があります。これらの更新は、クラスターのセキュリティ、信頼性、運用パフォーマンスの強化に役立ちます。
これらのサービスの更新の価値は、更新を適用するタイミングを制御できることです (例えば、MemoryDB クラスターの 24 時間 365 日の可用性を必要とする重要なビジネスイベントがある場合には、サービス更新の適用を遅らせることができます)。
これらのサービスの更新の対象となるクラスターが 1 つ以上ある場合は、更新がリリースされたときに、E メール、[Amazon SNS](mdbevents.sns.md)、[AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)、および [Amazon CloudWatch Events](monitoring-cloudwatch.md) より通知が送信されます。更新は、MemoryDB コンソールの **[サービスの更新]** ページにも表示されます。このダッシュボードを使用すると、MemoryDB フリートに関するサービスの更新とそのステータスをすべて表示できます。
自動更新を開始する前に、更新を適用するタイミングを制御します。最新のセキュリティパッチで MemoryDB を常に最新の状態に維持できるように、できるだけ早く [セキュリティ更新] タイプの更新を適用することを強くお勧めします。
クラスターは、複数の異なるサービス更新の対象である場合があります。ほとんどの更新では、更新を個別に適用する必要はありません。クラスターに 1 つの更新を適用すると、該当する他の更新も「完了」とマークされます。ステータスが自動的に「完了」に変わらない場合は、同じクラスターに複数の更新を個別に適用する必要が生じることがあります。
#### サービスの更新による影響とダウンタイム
ユーザーまたは Amazon MemoryDB が 1 つ以上の MemoryDB クラスターにサービスの更新を適用した場合、更新は、選択したすべてのクラスターが更新されるまで、各シャード内で一度に 1 つのノードにのみ適用されます。更新中のノードでは数秒のダウンタイムが発生しますが、残りのクラスターはトラフィックを処理し続けます。
+ クラスター設定は変更されません。
+ CloudWatch メトリクスに遅延が生じますが、メトリクスは可能な限り早く追いつきます。
**ノード交換はアプリケーションにどのように影響するか?** – MemoryDB ノードの場合、交換プロセスは耐久性と可用性を保証するように設計されています。単一ノードの MemoryDB クラスターの場合、MemoryDB はレプリカを動的にスピンアップし、耐久性コンポーネントからデータを復元してから、そのレプリカにフェイルオーバーします。複数のノードで構成されるレプリケーショングループの場合、MemoryDB は既存のレプリカを交換し、耐久性コンポーネントから新しいレプリカにデータを同期します。MemoryDB は複数のノードがある場合にのみマルチ AZ であるため、このシナリオでは、プライマリを交換すると、リードレプリカへのフェイルオーバーがトリガーされます。計画されたノード交換は、クラスターが受信した書き込みリクエストを処理する間に完了します。ノードが 1 つしかない場合、MemoryDB はプライマリを交換し、耐久性コンポーネントからデータを同期します。この間、プライマリノードは使用できなくなるため、書き込みの中断が長くなります。
**交換をスムーズに行い、データ損失を最小限に抑えるには、どのようなベストプラクティスに従う必要があるか?** – MemoryDB では、データの耐久性が高いため、単一ノードの実装でさえもデータ損失は予期されません。ただし、万一障害が発生した場合の損失の可能性を最小限に抑えるため、マルチ AZ およびバックアップ戦略を実施することを推奨します。当社は、交換をスムーズに行えるようクラスターを安定した状態に維持するために、同じクラスターの必要最小限のノードの交換を試みます。マルチ AZ を有効にすると、プライマリとリードレプリカを異なるアベイラビリティーゾーンにプロビジョニングできます。この場合、ノードが交換されると、プライマリロールはシャード内のレプリカにフェイルオーバーします。このシャードはトラフィックを処理し、データはその耐久性コンポーネントから復元されます。シャードごとにプライマリとレプリカがそれぞれ 1 つしか含まれていない構成の場合は、パッチ適用の前にレプリカを追加することを推奨します。これにより、パッチ適用プロセス中の可用性の低下が防止されます。交換は受信書き込みトラフィックが少ない期間中にスケジュールすることを推奨します。
**メンテナンス中のアプリケーションの中断を最小限に抑えるには、どのようなクライアント設定のベストプラクティスに従う必要があるか?** – MemoryDB では、クラスターモード設定は常に有効になっています。これにより、マネージド型またはアンマネージド型のオペレーション中に最高の可用性が提供されます。レプリカノードの個々のノードエンドポイントは、あらゆる読み取り操作に使用できます。MemoryDB では、クラスターで常に自動フェイルオーバーが有効になっています。つまり、プライマリノードが変更される可能性があります。したがって、アプリケーションでノードのロールを確認し、すべての読み取りエンドポイントを更新することで、プライマリに大きな負荷がかからないようにする必要があります。同様に、メンテナンスウィンドウ中にレプリカが読み取りリクエストで過負荷状態になるのを回避します。これを実現する方法の 1 つは、メンテナンス中の読み取りの中断を避けるために、少なくとも 2 つのリードレプリカを用意することです。
クライアントアプリケーションをテストし、アプリケーションが Redis/Valkey クラスタープロトコルに準拠していること、およびリクエストをノード間で適切にリダイレクトできることを確認することが重要です。メンテナンスおよび交換作業中に MemoryDB ノードが過負荷状態になるのを回避するために、バックオフおよび再試行戦略を実施することを推奨します。
**再スケジュール** – [メンテナンスウィンドウ](maintenance-window.md)を変更することで、サービスの更新を延期できます。スケジュールされた更新は、スケジュールされた日付がクラスターのメンテナンスウィンドウに一致する場合にのみクラスターに適用されます。メンテナンスウィンドウを変更し、スケジュールされた日付を過ぎると、サービスの更新は、今後の週に新しく指定したウィンドウに再スケジュールされます。新しい日付の 1 週間前に新しい通知が届きます。
のセキュリティ AWS は共有責任です。更新をできるだけ早く適用することを強く推奨します。
**サービスの更新のオプトアウト **– サービスの更新をオプトアウトできるかどうかを判断するには、[自動更新開始日] 属性の値を確認します。サービスの更新の [自動更新開始日] 属性の値が設定されている場合、MemoryDB は残りのクラスターへのサービスの更新を今後のメンテナンスウィンドウにスケジュールします。これをオプトアウトすることはできません。ただし、メンテナンスウィンドウの前に残りのクラスターにサービスの更新を適用した場合、MemoryDB はメンテナンスウィンドウ中にサービスの更新を再適用しません。詳細については、「[サービスの更新の適用](applying-updates.md)」を参照してください。
**メンテナンスウィンドウ中に MemoryDB がサービスの更新を直接適用できないのはなぜか?** – サービスの更新の目的は、更新を適用するタイミングをユーザーが柔軟に決定できるようにすることです。MemoryDB がサポートする[コンプライアンス](memorydb-compliance.md)プログラムに参加していないクラスターは、これらの更新を適用しないか、年間を通じて低い頻度で適用するかを選択できます。ただし、規制への準拠を維持する更新を適用することを推奨します。これは、サービスの更新の [自動更新開始日] 属性の値が存在しない場合にのみ当てはまります。詳細については、「[MemoryDB のコンプライアンス検証](memorydb-compliance.md)」を参照してください。
**メンテナンスウィンドウで適用される更新は、サービスの更新とどのように異なるか?** – 継続的マネージドメンテナンスを介して適用された更新は、メンテナンスウィンドウに直接スケジュールされます。ユーザー側のアクションは必要ありません。サービスの更新には期限があり、ユーザーは [自動更新開始日] までに適用するタイミングを制御できます。それまでに適用されない場合、MemoryDB はメンテナンスウィンドウでこれらの更新をスケジュールすることがあります。
### 継続的マネージドメンテナンスの更新
これらの更新は必須であり、メンテナンスウィンドウに直接適用されます。ユーザー側のアクションは必要ありません。これらの更新は、サービスの更新で提供される更新とは異なります。
#### 継続的メンテナンスによる影響とダウンタイム
**ノードの交換にはどのくらいの時間がかかるか?** – 交換は通常は 30 分以内に完了します。特定のインスタンス設定やトラフィックパターンでは、交換にそれ以上の時間がかかる場合があります。
**ノード交換はアプリケーションにどのように影響するか?** – 継続的マネージドメンテナンスの更新は、ノード交換を通じて「サービスの更新」と同じ方法で適用されます。詳細については、上記の「サービスの更新による影響とダウンタイム」セクションを参照してください。
**ノード交換を自分で管理するにはどうすればよいか?** – このような交換を、スケジュールされたノード交換ウィンドウより前に、任意のタイミングで独自に管理することもできます。交換を自分で管理することを選択した場合は、ユースケースに応じてさまざまなアクションを実行できます。
+ [クラスター内のノードを 1 つ以上のシャードに交換する](nodes.nodereplacement.md): [バックアップと復元](snapshots-restoring.md)またはスケールアウト後のスケールインを使用して[ノードを交換](cluster-resharding-online.md)できます。
+ [メンテナンスウィンドウを変更する](maintenance-window.md): クラスターのメンテナンスウィンドウを変更することもできます。後でメンテナンスウィンドウをより便利な時間に変更するには、[UpdateCluster API](clusters.modify.md)、[update-cluster CLI](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-cluster.html) を使用するか、MemoryDB マネジメントコンソールで [[変更]](clusters.modify.md) をクリックします。メンテナンスウィンドウを変更すると、MemoryDB は新しく指定されたウィンドウ中にノードのメンテナンスをスケジュールします。
これが実際にどのように機能するか見てみましょう。今が 11/09、木曜日の 1500 とします。次のメンテナンスウィンドウは 11/10、金曜日の 1700 です。次の 3 つのシナリオがあります。
+ メンテナンスウィンドウを金曜日の 1600 に変更します (現在の日時より後で、次の予定メンテナンスウィンドウより前)。ノードは 11/10、金曜日の 1600 に置き換えられます。
+ メンテナンスウィンドウを土曜日の 1600 に変更します (現在の日時より後で、次の予定メンテナンスウィンドウより後)。ノードは 11/11、土曜日の 1600 に置き換えられます。
+ メンテナンスウィンドウを水曜日の 1600 に変更します (週の中で、現在の日時より前)。ノードは 11/15、次の水曜日の 1600 に置き換えられます。
詳細については、「[メンテナンスの管理](maintenance-window.md)」を参照してください。
さまざまなリージョンのさまざまなクラスターのノードを同時に交換できます。ただし、対象となるクラスターのメンテナンスウィンドウが同じになるように設定されていることが条件です。
**今後予定されている交換について確認するにはどうすればよいか?** - ヘルスダッシュボードで AWS ヘルス通知を受け取る必要があります。DescribeServiceUpdates API を使用して、さまざまなサービスアップグレードのステータスを確認することもできます。当社では、予測可能な交換について事前にお客様に通知するよう努めています。ただし、予測不可能な障害などの例外的なケースでは、予告なしに交換を行う可能性があります。
**スケジュールされたメンテナンスをより適切なタイミングに変更できるか?** – はい。[メンテナンスウィンドウ](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeServiceUpdates.html)を変更することで、スケジュールされたメンテナンスをより適切な時間に延期できます。
**これらのノード交換を行うのはなぜか?** – これらの交換は、基盤となるホストに必須のソフトウェア更新を適用するために必要です。これらの更新は、セキュリティ、信頼性、運用パフォーマンスの強化に役立ちます。
**これらの交換は複数アベイラビリティーゾーンのノードと異なるリージョンのクラスターに同時に影響するか?** – 交換は、クラスターのメンテナンスウィンドウに応じて、複数のアベイラビリティーゾーンまたはリージョンで並行して実行できます。
# サービスの更新の適用
フリートに対するサービスの更新の適用は、更新が **使用可能** ステータスになってから開始することができます。サービスの更新は累積的です。つまり、未適用の更新も最新の更新に含まれます。
サービスの更新で自動更新が有効になっている場合、使用可能になったときにアクションを実行しないよう選択できます。MemoryDB は、**[自動更新開始日]** 以降、クラスターのメンテナンス期間中に更新を適用するようにスケジュールします。更新のステージごとに、関連する通知を受け取ります。
**注記**
ステータスが **使用可能**または **スケジュール済み** であるサービスの更新だけを適用できます。
該当する MemoryDB クラスターへのサービス固有の更新の確認および適用の詳細については、「[コンソールを使用したサービスの更新の適用](#applying-updates-console-APIReferenceconsole)」を参照してください。
1 つ以上の MemoryDB クラスターで新しいサービス更新が利用可能になったら、MemoryDB コンソール、API、または AWS CLI を使用して更新を適用できます。次のセクションでは、更新の適用に使用できるオプションについて説明します。
## コンソールを使用したサービスの更新の適用
使用可能なサービスの更新のリストと他の情報を確認するには、コンソールの **サービスの更新** (サービスの更新) ページに移動します。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) で MemoryDB コンソールを開きます。
1. ナビゲーションペインで、**サービスの更新**を選択します。
**[サービスの更新の詳細]** では、次の項目を表示できます。
+ **サービスの更新名**: サービスの更新の一意の名前
+ **サービスの更新名**: サービスの更新に関する詳細情報
+ **自動更新開始日**:この属性が設定されている場合、MemoryDB は、この日付以降に適切なメンテナンスウィンドウでクラスターを自動更新するようにスケジューリングを始めます。正確なスケジュールされたメンテナンスウィンドウに事前に通知が届きますが、**[自動更新開始日]** の直後のメンテナンスウィンドウではない場合があります。ただし、クラスターにはいつでもアップデートを適用できます。属性が設定されていない場合、サービスの更新は自動更新が有効になっておらず、MemoryDB はクラスターを自動的に更新しません。
**クラスターの更新ステータス**セクションでは、サービスの更新が適用されていない、または最近適用されたばかりのクラスターのリストを表示できます。クラスターごとに、以下を表示できます。
+ **クラスター名**: クラスターの名前
+ **ノードを更新しました**: 特定のクラスター内で更新された、または特定のサービスの更新に対して利用可能な状態の個々のノードの比率。
+ **更新タイプ**: サービスの更新のタイプ (**セキュリティ更新** または **エンジン更新**のいずれか)
+ **ステータス**: クラスター上のサービス更新のステータス。以下のいずれかです。
+ *使用可能*: 必要なクラスターでこの更新が利用可能です。
+ *進行中*: このクラスターに更新を適用しています。
+ *スケジュール済み*: 更新日がスケジュールされています。
+ *完了*: 更新が正常に適用されました。完了ステータスのクラスターは、完了後 7 日間表示されます。
ステータスが **使用可能**または **スケジュール済み** (スケジュール済み) であるクラスターのいずれかまたはすべてを選択してから、**今すぐ適用**を選択した場合、更新がそれらのクラスターに適用され始めます。
## を使用したサービス更新の適用 AWS CLI
サービスの更新が利用可能であるという通知を受け取ったら、 AWS CLIを使用してそれらの更新を確認し、適用することができます。
+ 利用可能なサービスの更新の説明を取得するには、次のコマンドを実行します。
`aws memorydb describe-service-updates --status available`
詳細については、「[describe-service-updates](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-service-updates.html)」を参照してください。
+ クラスターのリストにサービスの更新を適用するには、次のコマンドを実行します。
`aws memorydb batch-update-cluster --service-update ServiceUpdateNameToApply=sample-service-update --cluster-names cluster-1 cluster2`
詳細については、「[batch-update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/batch-update-cluster.html)」を参照してください。