Aurora ヘッドレスクラスターで Secrets Manager 管理有効化時に “Unable to reset your password” が出た理由
はじめに
Amazon RDS/Aurora では、マスターユーザーパスワードを AWS Secrets Manager で管理できます。
Secrets Manager 管理を有効化すると、RDS/Aurora がパスワードを生成・管理するため、パスワード管理やローテーションの運用を簡略化できます。
今回、DB インスタンスを持たない Aurora DB クラスター、いわゆるヘッドレスクラスターに対して Secrets Manager によるマスターユーザーパスワード管理を有効化したところ、RDS コンソールのイベントに以下のメッセージが出力されました。
Unable to reset your password. Error information: DB cluster has no instances available to perform master password reset. Your new password will be applied once a new writer is created.
一方、同じヘッドレスクラスターで通常のマスターパスワード変更を行った場合、このイベントは出力されませんでした。
この記事では、Secrets Manager 管理有効化時にこのイベントが出力された理由と、通常のマスターパスワード変更との違いを整理します。
いきなり結論
- 今回のイベントは、Secrets Manager 管理で生成されたパスワードを DB 側へ反映するための Writer DB インスタンスが存在しなかったため出力されたと考えられます。
- 通常のマスターパスワード変更と Secrets Manager 管理の有効化は、どちらもパスワードに関する操作ですが、処理内容が異なります。
| 操作 | 主な処理内容 |
|---|---|
| マスターパスワードを変更する | 利用者が指定した新しいパスワードを DB クラスターのマスターユーザーパスワードとして設定する |
| Secrets Manager によるマスターユーザーパスワード管理を有効化する | Aurora がパスワードを生成し、Secrets Manager で管理する。DB 側への反映も必要になる |
この違いにより、ヘッドレスクラスターでは Secrets Manager 管理有効化時のみ、今回のようなイベントが出力されたと考えられます。
マスターパスワード変更と Secrets Manager 管理有効化の違い
通常のマスターパスワード変更と、Secrets Manager 管理の有効化は、どちらもマスターユーザーパスワードに関する操作です。
しかし、指定する API パラメータは異なります。
| 操作 | 指定するパラメータ |
|---|---|
| マスターパスワードを変更する | MasterUserPassword |
| Secrets Manager 管理を有効化する | ManageMasterUserPassword |
通常のマスターパスワード変更では、利用者が指定したパスワードを MasterUserPassword として設定します。
一方、Secrets Manager 管理を有効化する場合は、ManageMasterUserPassword を指定します。この場合、Aurora が新しいパスワードを生成し、Secrets Manager の Secret として管理します。
なお、公式ドキュメントにも記載のとおり、ManageMasterUserPassword と MasterUserPassword は同時に指定できません。
このことからも、通常のパスワード変更と Secrets Manager 管理の有効化は、API 上も別の操作として扱われることが分かります。
なぜ Writer DB インスタンスが関係するのか
前述のとおり Secrets Manager 管理を有効化すると、Aurora がマスターユーザーパスワードを生成し、Secrets Manager で管理します。
また、Aurora 管理の Secret では、Secret 側のパスワードに合わせて DB クラスター側のマスターユーザーパスワードも変更されます。
そのため、Secret に保存されたパスワードで実際に DB に接続できるようにするには、DB 側のマスターユーザーにも同じパスワードが反映される必要があります。
今回の対象は、DB インスタンスを持たないヘッドレスクラスターでした。
Secrets Manager 管理で生成されたパスワードを DB 側へ反映するには Writer DB インスタンスが必要です。
しかし、対象クラスターには Writer が存在しなかったため、RDS コンソールのイベントに以下のメッセージが出力されたと考えられます。
DB cluster has no instances available to perform master password reset.
またイベントメッセージの末尾には、以下の文も含まれていました。
Your new password will be applied once a new writer is created.
このことからも、今回のイベントは Writer が存在しないためにパスワード反映ができず、新しい Writer が作成されるまで適用が保留された状態を示していることが伺えます。
挙動確認
実際に、Aurora ヘッドレスクラスターに対して以下の 2 つの操作を実行し、挙動を確認してみます。
- 通常のマスターパスワード変更
- Secrets Manager によるマスターユーザーパスワード管理の有効化
DBクラスターの作成
まず、Aurora DB クラスターを作成します。
ここでは Writer DB インスタンスは作成せず、DB クラスターのみを作成します。
REGION=ap-northeast-1
CLUSTER_ID=headless-test
DB_SUBNET_GROUP_NAME=<db-subnet-group-name>
VPC_SECURITY_GROUP_ID=<security-group-id>
aws rds create-db-cluster \
--region $REGION \
--db-cluster-identifier $CLUSTER_ID \
--engine aurora-mysql \
--master-username admin \
--master-user-password '<initial-password>' \
--db-subnet-group-name $DB_SUBNET_GROUP_NAME \
--vpc-security-group-ids $VPC_SECURITY_GROUP_ID
作成後、DB インスタンスが存在しないことを確認します。
aws rds describe-db-clusters \
--region $REGION \
--db-cluster-identifier $CLUSTER_ID \
--query 'DBClusters[0].DBClusterMembers'
結果は空配列でした。この時点で、対象の Aurora DB クラスターには Writer DB インスタンスが存在しないことが分かります。
[]
マスターパスワードの変更
次に、通常のマスターパスワード変更を実行します。
aws rds modify-db-cluster \
--region $REGION \
--db-cluster-identifier $CLUSTER_ID \
--master-user-password '<new-password>'
実行結果のうち、今回確認したい項目だけ抜粋します。
{
"DBCluster": {
"DBClusterIdentifier": "headless-test",
"Status": "available",
"Engine": "aurora-mysql",
"EngineVersion": "8.0.mysql_aurora.x.xx.x",
"MasterUsername": "admin",
"DBClusterMembers": []
}
}
コマンドはエラーなく完了し、RDS コンソールのイベントにもパスワードリセット失敗のメッセージは出力されませんでした。

Secrets Manager によるマスターユーザーパスワード管理を有効化
次に、Secrets Manager によるマスターユーザーパスワード管理を有効化します。
aws rds modify-db-cluster \
--region $REGION \
--db-cluster-identifier $CLUSTER_ID \
--manage-master-user-password
実行結果のうち、関連する項目だけ抜粋します。
{
"DBCluster": {
"DBClusterIdentifier": "headless-test",
"Status": "available",
"Engine": "aurora-mysql",
"DBClusterMembers": [],
"PendingModifiedValues": {
"MasterUserPassword": "****"
},
"MasterUserSecret": {
"SecretArn": "arn:aws:secretsmanager:ap-northeast-1:<account-id>:secret:<secret-name>",
"SecretStatus": "creating",
"KmsKeyId": "arn:aws:kms:ap-northeast-1:<account-id>:key/<kms-key-id>"
}
}
}
DBClusterMembers は空配列のままです。
"DBClusterMembers": []
一方で、PendingModifiedValues に MasterUserPassword が表示され、MasterUserSecret も作成中の状態になっていました。
"PendingModifiedValues": {
"MasterUserPassword": "****"
},
"MasterUserSecret": {
"SecretStatus": "creating"
}
この状態で RDS コンソールのイベントを確認すると、当該のイベントが出力されました。

まとめ
Aurora ヘッドレスクラスターで、通常のマスターパスワード変更と Secrets Manager 管理の有効化を試したところ、挙動に差がありました。
どちらもマスターユーザーパスワードに関する操作ですが、API 上は別の操作として扱われることが分かりました。
また今回のイベントは、Secrets Manager 管理を有効化する際に、DB 側へパスワードを反映するための Writer DB インスタンスが存在しなかったことで出力されたと考えられます。
ただし、イベントメッセージにもある通り、新しいパスワードは Writer DB インスタンスが作成されたタイミングで適用されます。そのため、このイベントは致命的なエラーというより、Writer が存在しないためパスワード反映が保留された状態を示すものと捉えるのがよさそうです。







