What should a solutions architect do to meet this requirement with the LEAST operational effort?
Create a new AWS Key Management Service (AWS KMS) encryption key. Use AWS Secrets Manager to create a new secret that uses the KMS key with the appropriate credentials. Associate the secret with the Aurora DB cluster. Configure a custom rotation period of 14 days.
Create two parameters in AWS Systems Manager Parameter Store: one for the user name as a string parameter and one that uses the SecureString type for the password. Select AWS Key Management Service (AWS KMS) encryption for the password parameter, and load these parameters in the application tier. Implement an AWS Lambda function that rotates the password every 14 days.
Store a file that contains the credentials in an AWS Key Management Service (AWS KMS) encrypted Amazon Elastic File System (Amazon EFS) file system. Mount the EFS file system in all EC2 instances of the application tier. Restrict the access to the file on the file system so that the application can read the file and that only super users can modify the file. Implement an AWS Lambda function that rotates the key in Aurora every 14 days and writes new credentials into the file.
Store a file that contains the credentials in an AWS Key Management Service (AWS KMS) encrypted Amazon S3 bucket that the application uses to load the credentials. Download the file to the application regularly to ensure that the correct credentials are used. Implement an AWS Lambda function that rotates the Aurora credentials every 14 days and uploads these credentials to the file in the S3 bucket.
Explanations:
Using AWS Secrets Manager allows for secure storage and automatic rotation of database credentials. Associating the secret with the Aurora DB cluster ensures that the application can retrieve the updated credentials with minimal operational effort. Configuring a custom rotation period of 14 days meets the security guideline requirement.
While AWS Systems Manager Parameter Store can securely store credentials, it requires more manual effort for implementation, such as creating a Lambda function for rotation and managing two separate parameters (username and password). Additionally, the rotation mechanism is less integrated than Secrets Manager’s built-in functionality.
Storing credentials in an encrypted EFS file adds unnecessary complexity and operational overhead, as it requires managing file access and ensuring that the application can read the file securely. Moreover, implementing a Lambda function for password rotation in this context complicates the solution without providing significant benefits over using Secrets Manager.
Storing credentials in an encrypted S3 bucket involves manual processes for downloading and ensuring the latest credentials are used. This method also requires a Lambda function for rotation and lacks the seamless integration provided by AWS Secrets Manager, making it less efficient and more prone to operational issues.
I categorize that the answer is:
Create a new AWS Key Management Service (AWS KMS) encryption key. Use AWS Secrets Manager to create a new secret that uses the KMS key with the appropriate credentials. Associate the secret with the Aurora DB cluster. Configure a custom rotation period of 14 days.
I organize that the answer is:
Create a new AWS Key Management Service (AWS KMS) encryption key. Use AWS Secrets Manager to create a new secret that uses the KMS key with the appropriate credentials. Associate the secret with the Aurora DB cluster. Configure a custom rotation period of 14 days.