Now that we have had a good tour of the environment dashboard, it should be relatively easy to configure the production environment as per our requirements. Let's start off by increasing the instance count for our production environment:

1. Select the Scaling configuration tile from the newly created production environment's configuration dashboard and change the Environment type from Single instance to Load balancing, auto scaling. The instance count settings as well as the auto scaling features, will only be available once the new changes are reflected in the environment. Click Apply once done.

2. Next, you can also change the default instance type from t1.micro to something a bit more powerful, such as t2.medium or t2.large, using the Instances configuration section.
3. Once your major settings are done, you will also require a new RDS backed MySQL database for your production instances. So go ahead and create a new MySQL DB instance using the RDS Management Console at https://console.aws.amazon.com/rds/.

4. Remember to make a note of the database name, the database endpoint, as well as the username and password, before moving on to the next steps!
5. Next, using the production environment URL, launch your WordPress site and fill in the required database configuration details, as depicted in the following screenshot:

This method of configuring database settings is not ideal, especially when it comes to a production environment. Alternatively, Elastic Beanstalk provides you with the concept of environment properties that enable you to pass key-value pairs of configurations directly to your application.

6. To do so, you need to select the Configuration section from your Production dashboard, and within that, opt to modify the Software configuration.
7. Here, under the Environment Properties section, fill out the required production database variables, as depicted in the following screenshot:

But where do these variables actually end up getting configured? That's where we leverage the WordPress configuration file called wp-config.php and configure all these variables into it. Upon loading, PHP will read the values of each of these properties from the environment property that we just set in Elastic Beanstalk.

8. Open your wp-config.php file using your favorite text editor, and change the database section, as shown in the following snippet:

/** The name of the database for WordPress */ 
define('DB_NAME', getenv('DB_NAME')); 
 
/** MySQL database username */ 
define('DB_USER', getenv('DB_USER')); 
 
/** MySQL database password */ 
define('DB_PASSWORD', getenv('DB_PASSWORD')); 
 
/** MySQL hostname */ 
define('DB_HOST', getenv('DB_HOST')); 

9. Save the file and push the newly modified code into the production environment using the eb deploy command. Simple isn't it?

Here's what the new environment should look like after the deployments:

Looking good so far, right? With this done, your WordPress setup should be able to scale in and out efficiently without you having to worry about the load balancing needs or even about the MySQL instances. Additionally, now that we have configured the instances to fetch the database information from Elastic Beanstalk itself, we no longer have to worry about what will happen to our site if the underlying WordPress instances restart or terminate. This is exactly what we set out to do in the first place, but there's still a small catch. What about the content files that you will eventually upload on your WordPress website, such as images and videos? These uploads will end up getting stored on your instance's local disks, and that's a potential issue as you may end up losing all of your data if that instance gets terminated by the auto-scaling policies. Luckily for us, AWS has a solution to this problem, and that's exactly what we are going to learn about next.