Can you remap/copy/alias environment variables to new ones in AWS elastic beanstalk?

Question

Right now my database variables are defined as RDS_*, however I'd like to remap them to my app's conventions.

This would help in avoiding writing AWS-specific detections inside of my project, which is obviously desirable.

Answer 1

There are a few different options, each with their own pitfalls:

1. Adding Environment Variables to EB Configuration

When inside of your environment navigate to the Configuration and then Software Configuration section. In there you will see a list of environment variables and at the bottom you can list your own custom variables. The downside to this is that there is now way to dynamically map the values from the AWS environment variables. If a value in AWS changes then you need to manually update yours. This is most likely to happen in the case that you upgrade/downgrade your database. So you will want to update the host for the DB to the new RDS endpoint. (NOTE: This is based on options available to PHP environments. I've seen variations for other languages, but it could be old documentation.)

2. Adding a post deploy script

This is a bit of a pain with beanstalk, but it is possible to run post deploy scripts. I won't go in to great detail, but basically you will need to add post deploy scripts as described in this article to a default beanstalk ami. Then you will need to copy the instance as a new ami, and switch it in your beanstalk instances to use it by default. In the post deploy script you can add the mapping to your environment variables.

3. Adding the mapping to your code

I realize you don't want to do this, but I think this would be the least amount of headaches for you. I've included a very simple example in PHP. Be careful interchanging $_ENV and getenv()/putenv()/$_SERVER if you use PHP as they pull from different sources and can be changed independently.

<?php
    if(getenv('RDS_VAR')) {
        putenv('NEW_VAR', getenv('RDS_VAR'))
    }
?>

Final Thoughts

I use a combination of 1 and 3 when deploying an app to Beanstalk as it gives the most flexibility when dealing with dynamic environment variables. I first map the values to my applications configuration as described in #3, then if I want to plan for possibly swapping out the RDS endpoint, password, or username I can add environment variables as mentioned in #1 and put overrides to my AWS env mapping. This allows me to stay in sync with the AWS environment variables, but also manually overriding them in the software configuration if I need to swap out the DB for a backup.