翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 転送時の暗号化を有効にする際のベストプラクティス
<a name="enable-python-best-practices"></a>

## 転送中の暗号化を有効にする前: DNS レコードが適切に処理されていることを確認
<a name="enable-python-best-practices-before"></a>

**注記**  
このプロセス中に、古いエンドポイントを変更および削除します。エンドポイントの使い方を誤ると、Valkey または Redis OSS クライアントが古くて削除されたエンドポイントを使用し、クラスターに接続できなくなる可能性があります。

クラスターが TLS なしから TLS 優先へ移行される間、古いクラスター設定エンドポイントの DNS レコードは保持され、新しいクラスター設定エンドポイントの DNS レコードは別のフォーマットで生成されます。TLS が有効なクラスターは、TLS が無効のクラスターとは異なる形式の DNS レコードを使用します。クラスターが `encryption mode: Preferred` に設定されている場合、ElastiCache は両方の DNS レコードを保持するため、アプリケーションおよび他の Valkey または Redis OSS のクライアントは、レコード間で切り替えることができます。TLS 移行プロセス中に、DNS レコードの次の変更が行われます。

### 転送中の暗号化を有効にした場合に行われる DNS レコードの変更の説明
<a name="enable-python-best-practices-before-desc"></a>

**CME クラスターの場合**

クラスターが [転送暗号化モード: 優先] に設定されている場合:
+ TLS なしクラスター用の元のクラスター設定エンドポイントはアクティブな状態を維持します。クラスターを TLS 暗号化モード [なし] から [優先] に再設定しても、ダウンタイムは発生しません。
+ クラスターが TLS 優先モードに設定されると、新しい TLS Valkey または Redis OSS エンドポイントが生成されます。これらの新しいエンドポイントは、古いエンドポイントと同じ IP (TLS なし) に解決されます。
+ 新しい TLS Valkey または Redis OSS 設定エンドポイントは ElastiCache コンソールと `describe-replication-group` API へのレスポンスで公開されます。

クラスターが [転送暗号化モード: 必須] に設定されている場合:
+ TLS が有効になっていない古いエンドポイントは削除されます。TLS クラスターエンドポイントのダウンタイムは発生しません。
+ 新しい `cluster-configuration-endpoint` は、ElastiCache コンソールまたは `describe-replication-group` API から取得できます。

**自動フェイルオーバーが有効または自動フェイルオーバーが無効な CMD クラスターの場合**

レプリケーショングループが [転送暗号化モード: 優先] に設定されている場合:
+ TLS が有効になっていないクラスターの元のプライマリエンドポイントとリーダーエンドポイントはアクティブなままです。
+ クラスターが TLS `Preferred` モードに設定されると、新しいプライマリエンドポイントとリーダーエンドポイントが生成されます。この新しいエンドポイントは、古いエンドポイントと同じ IP (TLS なし) に解決されます。
+ 新しいプライマリエンドポイントとリーダーエンドポイントは ElastiCache コンソールと `describe-replication-group` API へのレスポンスで公開されます。

レプリケーショングループが [転送暗号化モード: 必須] に設定されている場合:
+ 古い TLS なしのプライマリエンドポイントとリーダーエンドポイントは削除されます。TLS クラスターエンドポイントのダウンタイムは発生しません。
+ 新しいプライマリエンドポイントとリーダーエンドポイントは、ElastiCache コンソールまたは `describe-replication-group` API から取得できます。

### DNS レコードの推奨される使用方法
<a name="enable-python-best-practices-before-usage"></a>

**CME クラスターの場合**
+ アプリケーションのコードでは、ノードごとの DNS レコードの代わりにクラスター設定エンドポイントを使用してください。ノードごとの DNS 名を直接使用することはお勧めしません。移行中に DNS 名は変更され、アプリケーションコードによってクラスターへの接続が切断されるためです。
+ クラスター設定エンドポイントはこのプロセス中に変更されるため、アプリケーションでハードコードしないでください。
+ クラスター設定エンドポイントはこのプロセス中に変更される可能性があるため、アプリケーションでハードコードすることはお勧めしません。送信中の暗号化が完了したら、`describe-replication-group` API (上記太字で表記) を使用してクラスター設定エンドポイントのクエリを実行し、応答として取得した DNS をこの時点から使用します。

**自動フェイルオーバーが有効になっている CMD クラスターの場合**
+ クラスターを TLS なしから TLS 優先に移行すると、古いノードごとの DNS 名が削除され、新しい DNS 名が生成されるため、アプリケーションのコードではノードごとの DNS 名の代わりにプライマリエンドポイントとリーダーエンドポイントを使用してください。将来クラスターにレプリカを追加する可能性があるため、ノードごとの DNS 名を直接使用することはお勧めしません。また、自動フェイルオーバーが有効になっている場合、プライマリクラスターとレプリカのロールが ElastiCache サービスによって自動的に変更されます。これらの変更を追跡しやすくするために、プライマリエンドポイントとリーダーエンドポイントを使用することをお勧めします。最後に、リーダーエンドポイントを使用すると、レプリカからの読み取りをクラスター内のレプリカ間で均等に分散できます。
+ TLS 移行プロセス中に変更される可能性があるため、プライマリエンドポイントとリーダーエンドポイントをアプリケーションにハードコードすることはお勧めしません。TLS 優先への移行が完了したら、describe-replication-group API を使用してプライマリエンドポイントとリーダーエンドポイントをクエリし、レスポンスとして取得した DNS をこの時点から使用します。これにより、エンドポイントの変更を動的に追跡できます。

**自動フェイルオーバーが無効になっている CMD クラスターの場合**
+ アプリケーションのコードでは、ノードごとの DNS 名の代わりに、プライマリエンドポイントとリーダーエンドポイントを使用します。自動フェイルオーバーが無効になっている場合、スケーリング、パッチ、フェイルオーバー、および自動フェイルオーバーが有効な場合に ElastiCache サービスによって自動的に管理されるその他の手順は、代わりにユーザーが実行します。これにより、さまざまなエンドポイントを手動で追跡することが容易になります。クラスターを TLS なしから TLS 優先に移行する際に、古いノードごとの DNS 名は削除され、新しい DNS 名が生成されるため、ノードごとの DNS 名を直接使用しないでください。これは、TLS 移行中にクライアントがクラスターに接続するために必須です。また、リーダーエンドポイントを使用する場合、レプリカ間で読み取りを均等に分散させ、クラスターにレプリカを追加または削除するときに DNS レコードを追跡できるという利点もあります。
+ TLS 移行プロセス中に変更される可能性があるため、クラスター設定エンドポイントをアプリケーションにハードコードすることは推奨されません。

## 転送中の暗号化中: 移行プロセスが終了するタイミングに注意
<a name="enable-python-best-practices-during"></a>

転送中の暗号化モードの変更は、即座に行われるわけではなく、ある程度の時間を要することがあります。これは、大規模なクラスターの場合に特にあてはまります。クラスターが TLS 優先への移行を完了した場合にのみ、TCP 接続と TLS 接続の両方を受け入れてサービスを提供できるようになります。そのため、転送中の暗号化が完了するまでは、クラスターへの TLS 接続を確立しようとするクライアントを作成しないでください。

転送中の暗号化が成功または失敗したときに通知を受け取る方法はいくつかあります (上記のコード例には示されていません)。
+ SNS サービスを使用して暗号化が完了したときに通知を受け取る
+ 暗号化が完了するとイベントを発行する `describe-events` API を使用する
+ ElastiCache コンソールに暗号化が完了したことを示すメッセージが表示される

暗号化が完了したかどうかを確認するロジックをアプリケーションに実装することもできます。上の例では、クラスターが移行を完了したことを確認する方法をいくつか見てきました。
+ 移行プロセスが開始される (クラスターのステータスが「変更中」に変わる) まで待ち、変更が完了する (クラスターのステータスが「使用可能」に戻る) まで待つ
+ `describe-replication-group` API をクエリして、クラスターの `transit_encryption_enabled` が [True] に設定されていることを確認する。

### 転送中の暗号化を有効にした後: 使用するクライアントが正しく設定されていることを確認
<a name="enable-python-best-practices-after"></a>

クラスターが TLS 優先モードになっている間、アプリケーションはクラスターへの TLS 接続を開き、それらの接続のみを使用する必要があります。これにより、転送中の暗号化を有効にしてもアプリケーションのダウンタイムは発生しません。SSL セクションの info コマンドを使用すると、Valkey または Redis OSS エンジンへのクリアな TCP 接続がないことを確認できます。

```
# SSL
ssl_enabled:yes
ssl_current_certificate_not_before_date:Mar 20 23:27:07 2017 GMT
ssl_current_certificate_not_after_date:Feb 24 23:27:07 2117 GMT
ssl_current_certificate_serial:D8C7DEA91E684163
tls_mode_connected_tcp_clients:0   (should be zero)
tls_mode_connected_tls_clients:100
```