Hands-On: Moving Configuration Parameters to the SSM Parameter Store

Let’s move the configuration parameters from the EC2 user data into the SSM parameter store.

We learned the commands to do so already in the last lesson:

• ssm put-parameter to create a new parameter
• ssm get-parameter to read a SSM parameter

Now it’s your turn!

Extracting database credentials

The script below extracts the EC2 user data from the latest version of our launch template and stores the following configuration values in variables:

• DB_HOST: The hostname of our RDS database
• DB_PASSWORD: The password for our RDS database
• DB_NAME: The database name within RDS database
• DB_USER: The username to connect to our RDS database

Additionally, the DNS name of the EFS file system is stored in the EFS_FILESYSTEM_ID variable.

Parameter names and their types

Add ssm put-parameter commands to write the following parameters:

Parameter Name	Read from Variable	Parameter Type
/wordpress/DB_HOST	DB_HOST	String
/wordpress/DB_PASSWORD	DB_PASSWORD	SecureString
/wordpress/DB_NAME	DB_NAME	String
/wordpress/DB_USER	DB_USER	String
/wordpress/EFS_FILESYSTEM_ID	EFS_FILESYSTEM_ID	String

Note that the parameter /wordpress/DB_PASSWORD contains a password and therefore should be stored as a SecureString. All other values should be stored as String.

We can add the ssm put-parameter commands in section 5 of the script, after # ADD COMMANDS HERE. The first command to create the /wordpress/DB_HOST parameter has already been created. Now it’s your turn to create the other four.

Tip: You can run the script as often as you want by pressing the “Run” button. It will tell you which parameters are set correctly.

Note: If you get an error that a parameter already exists, this is not a problem (you’ve probably created it already). However, if you set the values wrong, you can add the --overwrite parameter to the ssm put-parameter command to update its value, even if it already exists.