翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
転送時の暗号化を有効にする際のベストプラクティス
転送中の暗号化を有効にする前に、適切なDNSレコード処理があることを確認してください。
注記
このプロセス中に、古いエンドポイントを変更および削除します。エンドポイントを誤って使用すると、Valkey または Redis OSSクライアントが古いエンドポイントと削除されたエンドポイントを使用してクラスターに接続できなくなる可能性があります。
クラスターが推奨されないTLS からTLS推奨されない に移行する間、古いノードごとのDNSレコードは保持され、新しいノードごとのDNSレコードは別の形式で生成されます。TLSが有効なクラスターは、クラスターとは異なる non-TLS-enabled形式のDNSレコードを使用します。 ElastiCache は、クラスターが暗号化モードで設定されているときに両方のDNSレコードを保持します。アプリケーションと他の Valkey または Redis OSSクライアントがそれらを切り替えられるようにすることをお勧めします。DNS レコードでは、TLS移行プロセス中に次の変更が行われます。
転送中の暗号化を有効にするときに発生するDNSレコードの変更の説明
CMEクラスターの場合
クラスターが [転送暗号化モード: 優先] に設定されている場合:
-
有効になっていないTLSクラスターの元のクラスターエンドポイントはアクティブのままになります。クラスターがTLS暗号化モード「なし」から「優先」に再設定された場合、ダウンタイムはありません。
-
新しい TLS Valkey または Redis OSSエンドポイントは、クラスターが TLS優先モードに設定されているときに生成されます。これらの新しいエンドポイントは、古いエンドポイントIPsと同じ (非) に解決されますTLS。
-
新しい TLS Valkey または Redis OSS設定エンドポイントは、ElastiCache コンソールと
describe-replication-group
へのレスポンスで公開されますAPI。
クラスターが [転送暗号化モード: 必須] に設定されている場合:
-
有効になっていないTLS古いエンドポイントは削除されます。TLS クラスターエンドポイントのダウンタイムはありません。
-
ElastiCache コンソールまたは
cluster-configuration-endpoint
から新しいdescribe-replication-group
を取得できますAPI。
自動フェイルオーバーが有効または自動フェイルオーバーが無効になっているCMDクラスターの場合
レプリケーショングループが [転送暗号化モード: 優先] に設定されている場合:
-
有効になっていないTLSクラスターの元のプライマリエンドポイントとリーダーエンドポイントはアクティブのままになります。
-
クラスターが TLS
Preferred
モードに設定されていると、新しいTLSプライマリエンドポイントとリーダーエンドポイントが生成されます。この新しいエンドポイントは、古いエンドポイント (非) と同じ IP (複数可) に解決されますTLS。 -
新しいプライマリエンドポイントとリーダーエンドポイントは、 ElastiCache コンソールと
describe-replication-group
へのレスポンスで公開されますAPI。
レプリケーショングループが [転送暗号化モード: 必須] に設定されている場合:
-
古い非TLSプライマリエンドポイントとリーダーエンドポイントは削除されます。TLS クラスターエンドポイントのダウンタイムはありません。
-
コンソールまたは から ElastiCache新しいプライマリエンドポイントとリーダーエンドポイントを取得できます
describe-replication-group
API。
DNS レコードの推奨使用法
CMEクラスターの場合
-
アプリケーションのコードのノードごとのDNSレコードではなく、クラスター設定エンドポイントを使用します。ノードごとのDNS名前を直接使用することはお勧めしません。シャードを追加または削除するときに変更される可能性があるためです。
-
このプロセス中に変更されるため、アプリケーションでクラスター設定エンドポイントをハードコードしないでください。
-
このプロセス中に変更される可能性があるため、クラスター設定エンドポイントをアプリケーションにハードコードすることは推奨されません。転送中の暗号化が完了したら、
describe-replication-group
API (上記の (太字) で示すように) でクラスター設定エンドポイントをクエリしDNS、この時点から取得した を使用します。
自動フェイルオーバーが有効になっているCMDクラスターの場合
-
クラスターを no-preferred から -TLSTLSpreferred に移行すると、古いノード名が削除され、新しいノードDNS名が生成されるため、アプリケーションのコードDNS内のノード名ごとにではなく、プライマリエンドポイントとリーダーエンドポイントを使用します。今後、クラスターにレプリカを追加する可能性があるため、ノードごとのDNS名前を直接使用することはお勧めしません。また、自動フェイルオーバーが有効になっている場合、プライマリクラスターとレプリカのロールは ElastiCache サービスによって自動的に変更されます。これらの変更を追跡するために、プライマリエンドポイントとリーダーエンドポイントを使用することをお勧めします。最後に、リーダーエンドポイントを使用すると、レプリカからの読み取りをクラスター内のレプリカ間で均等に分散できます。
-
プライマリエンドポイントとリーダーエンドポイントをアプリケーションにハードコードすることは、TLS移行プロセス中に変更される可能性があるため、不適切な方法です。移行が TLS-preferred に変更されたら、 を使用して describe-replication-groupプライマリエンドポイントとリーダーエンドポイントエンドポイントをクエリAPIし、この時点から取得した DNS を使用します。これにより、エンドポイントの変更を動的に追跡できます。
自動フェイルオーバーが無効になっているCMDクラスターの場合
-
アプリケーションのコード内のノードごとのDNS名前の代わりに、プライマリエンドポイントとリーダーエンドポイントを使用します。自動フェイルオーバーが無効になっている場合、自動フェイルオーバーが有効になっているときに ElastiCache サービスによって自動的に管理されるスケーリング、パッチ適用、フェイルオーバー、およびその他の手順は、代わりにユーザーによって実行されます。これにより、さまざまなエンドポイントを手動で追跡することが容易になります。ノードごとの古いDNS名前は削除され、クラスターを no-TLSpreferred から TLS-preferred に移行すると新しい名前が生成されるため、ノードごとのDNS名前を直接使用しないでください。これは、クライアントが TLS移行中にクラスターに接続できるようにするために必須です。また、リーダーエンドポイントを使用する際にレプリカ間でリードを均等に分散し、クラスターからレプリカを追加または削除するときに DNS-records を追跡するメリットもあります。
-
クラスター設定エンドポイントをアプリケーションでハードコードすることは、TLS移行プロセス中に変更される可能性があるため、悪い方法です。
転送中の暗号化中: 移行プロセスが終了するタイミングに注意
転送中の暗号化モードの変更は、即座に行われるわけではなく、ある程度の時間を要することがあります。これは、大規模なクラスターの場合に特にあてはまります。クラスターが TLS-preferred への移行を完了した場合にのみ、 と TCPTLS接続の両方を受け入れて処理できます。したがって、転送中の暗号化が完了するまで、クラスターTLSへの接続を確立しようとするクライアントを作成しないでください。
転送中の暗号化が成功または失敗したときに通知を受け取る方法はいくつかあります (上記のコード例には示されていません)。
-
暗号化が完了したときに SNSサービスを使用して通知を受け取る
-
暗号化が完了するとイベントを出力
describe-events
APIする の使用 -
ElastiCache コンソールで暗号化が完了したことを示すメッセージを表示する
暗号化が完了したかどうかを確認するロジックをアプリケーションに実装することもできます。上の例では、クラスターが移行を完了したことを確認する方法をいくつか見てきました。
-
移行プロセスが開始される (クラスターのステータスが「変更中」に変わる) まで待ち、変更が完了する (クラスターのステータスが「使用可能」に戻る) まで待つ
-
をクエリして、クラスターが True
transit_encryption_enabled
に設定されていることを主張しますdescribe-replication-group
API。
転送中の暗号化を有効にした後: 使用するクライアントが正しく設定されていることを確認
クラスターが TLS優先モードになっている間、アプリケーションはクラスターTLSへの接続を開き、それらの接続のみを使用する必要があります。これにより、転送中の暗号化を有効にしてもアプリケーションのダウンタイムは発生しません。SSL セクションの 情報コマンドを使用して、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