{"id":7164,"date":"2021-12-01T17:54:15","date_gmt":"2021-12-01T17:54:15","guid":{"rendered":"https:\/\/rax-stg-wp-aws.com\/blogs\/how-to-call-and-export-environment-variables-in-aws-elastic-beanstalk\/"},"modified":"2026-11-03T19:28:08","modified_gmt":"2026-11-03T19:28:08","slug":"how-to-call-and-export-environment-variables-in-aws-elastic-beanstalk","status":"publish","type":"blogs","link":"https:\/\/www.rackspace.com\/de\/blogs\/how-to-call-and-export-environment-variables-in-aws-elastic-beanstalk\/","title":{"rendered":"How to call and export environment variables in AWS Elastic Beanstalk"},"content":{"rendered":"

Originally published in Apr 2017, at the Onica blog here<\/a>.<\/em><\/p>\n

The AWS Elastic Beanstalk documentation doesn’t tell you how to export environment variables or set top-level shell commands. We use variables for all kinds of things, so we decided to create a how-to guide for calling and viewing environment variables in *ebextension* config files. In this post, we dive into several ways to export environment variables, set top-level shell commands, and see how they show up under different circumstances.<\/p>\n

Environment variables in ebextension config files: How to call and export in Elastic Beanstalk<\/strong><\/p>\n

Let’s take the following as our .ebextensions\/00-variables.config<\/em> file. This is the basis for all of our tests:<\/p>\n

    option_settings:
\n    “aws: elasticbeanstalk:application:environent”:
\n    envvar1: value1<\/em><\/p>\n

commands and container_commands<\/strong><\/p>\n

`echo`output<\/p>\n

The first test is to see how we can use these two in the commands<\/strong> and container_commands <\/strong>sections of an ebextensions configuration file:<\/p>\n

    commands:
\n    a00_command_line_test:
\n    command: “echo $envvar1> \/tmp\/a00_command_line_test”<\/em><\/p>\n

    container commands:
\n    c00_command_line_test:
\n    command: “echo $envvar1> \/tmp\/c00_command_line_test”<\/em><\/p>\n

Here are the results:<\/em><\/p>\n

    $ cat \/tmp\/a00_command_line_test<\/em><\/p>\n

    $ cat \/tmp\/c00_command_line_test
\n    value1<\/em><\/p>\n

The \/tmp\/a00_command_line_test<\/strong> file ends up being empty while the latter \/tmp\/c00_command_line_test <\/strong>file has the `value1` value in it as expected.<\/p>\n

You can’t see the envvar1<\/strong> variable when you use it in commands.<\/strong><\/p>\n

To force this you can use the env:<\/strong> option along with the command<\/strong>: option:<\/p>\n

    commands:
\n        a00_command_line_test:
\n        command: “echo $envvar1 > \/tmp\/a00_command_line_test”<\/em><\/p>\n

    env:<\/p>\n

    envvar1: 
\n        “Fn::GetOptionSetting”:
\n        Namespace: “aws:elasticbeanstalk:application:environment”
\n        OptionName: envvar1<\/em><\/p>\n

`get-config` output<\/p>\n

The next test we conducted was simply to use the get-config<\/em> command included in  all Elastic Beanstalk AMIs:<\/p>\n

 commands:
\n      a01_command_line_test:
\n        command: “\/opt\/elasticbeanstalk\/bin\/get-config environment 
\n    -k envvar1 > \/tmp\/a01_command_line_test”<\/em><\/p>\n

    container_commands:
\n      c01_command_line_test:
\n        command: “\/opt\/elasticbeanstalk\/bin\/get-config environment 
\n    -k envvar1 > \/tmp\/c01_command_line_test”<\/em><\/p>\n

    $ cat \/tmp\/a01_command_line_test
\n    value1$<\/em><\/p>\n

    $ cat \/tmp\/c01_command_line_test
\n    value1$<\/em><\/p>\n

Both files have the variable in it, but there\u2019s no newline. This is due to the `echo` command above natively adding a newline. We use this command in shell scripts as shown in the following example:<\/p>\n

 somevar=$(\/opt\/elasticbeanstalk\/bin\/get-config environment -k envvar1)<\/p>\n

files<\/em><\/p>\n

The next tests we did were around the files directive. We created two files&mdash;a bash script and a python script. Each one tests the ability to do the following actions:<\/p>\n

1. Simply just call an environment variable when run.
\n2. Use the `backtick + curly brace + Fn::GetOptionSetting` command embedded in the file.
\n3. Use the `get-config` command.<\/p>\n

files:<\/strong><\/p>\n

  “\/tmp\/00_file_test.sh”:
\n          content: |
\n            #!\/bin\/sh
\n            env_method_1=$envvar1
\n            echo $env_method_1<\/p>\n

       env_method_2=`{“Fn::GetOptionSetting”: {“Namespace”: 
\n       “aws:elasticbeanstalk:application:environment”, “OptionName”: 
\n          “envvar1”, “DefaultValue”: “my_default_value”}}`
\n          echo $env_method_2<\/p>\n

       env_method_3=$(\/opt\/elasticbeanstalk\/bin\/get-config 
\n       environment -k envvar1)
\n          echo $env_method_3<\/p>\n

       group: root
\n       mode: “000755”
\n       owner: root<\/p>\n

       “\/tmp\/00_file_test.py”:
\n          content: |
\n          #!\/usr\/bin\/env python
\n          import os, subprocess<\/p>\n

       try: 
\n       env_method_1 = os.environ[‘envvar1’]
\n          print(env_method_1)
\n    
\n       except:
\n       print(“Failed to get env_method_1”)<\/p>\n

       try:
\n       env_method_2 = “`{“Fn::GetOptionSetting”: {“Namespace”: 
\n       “aws:elasticbeanstalk:application:environment”, “OptionName”: 
\n       “envvar1”, “DefaultValue”: “my_default_value”}}`”
\n           print(env_method_2)<\/p>\n

       except:
\n       print(“Failed to get env_method_2”)<\/p>\n

       try:
\n       env_method_3 = subprocess.check_output
\n       ([‘\/opt\/elasticbeanstalk\/bin\/get-config’, 
\n       ‘environment’, ‘-k’, ‘envvar1’])
\n            print(env_method_3)<\/p>\n

       except:
\n       print(“Failed to get env_method_3”)<\/p>\n

       group: root
\n       mode: “000755”
\n       owner: root<\/p>\n

 The result of the files <\/strong>directive are these files:<\/p>\n

 $ cat \/tmp\/00_file_test.sh
\n       #!\/bin\/sh
\n       env_method_1=$envvar1
\n       echo $env_method_1<\/p>\n

       env_method_2=value1
\n       echo $env_method_2<\/p>\n

       env_method_3=$
\n       (\/opt\/elasticbeanstalk\/bin\/get-config environment 
\n       -k envvar1)
\n       echo $env_method_3<\/p>\n

       $ cat \/tmp\/00_file_test.py
\n       #!\/usr\/bin\/env python
\n       import os, subprocess<\/p>\n

       try:
\n       env_method_1 = os.environ[‘envvar1’]
\n       print(env_method_1)<\/p>\n

       except:
\n       print(“Failed to get env_method_1”)<\/p>\n

       try:
\n       env_method_2 = “value1”
\n       print(env_method_2)
\n    
\n       except:
\n       print(“Failed to get env_method_2”)<\/p>\n

       try:
\n       env_method_3 = subprocess.check_output
\n       ([‘\/opt\/elasticbeanstalk\/bin\/get-config’, ‘environment’,
\n        ‘-k’, ‘envvar1’])
\n         print(env_method_3)<\/p>\n

       except:
\n       print(“Failed to get env_method_3”)<\/p>\n

It is very important to notice how this affects scripts<\/strong><\/p>\n

In the second test on both the shell script and the Python script, the variable is already embedded into the script. You can run either script at any time under any user, and it always has the right variable there. The variable is set when you create the file at deploy time, rather than evaluating the variable when it runs.<\/p>\n

If the environment variable changes and this file is not updated—; say you remove it from the ebextentions <\/strong>configuration file, but another script or program can call it—; it will then have the wrong variable in it.<\/p>\n

The other two tests: env_method_1<\/em> and env_method_3<\/em> still gather the environment variable when they\u2019re run. Lets run them under commands<\/strong> and container_commands<\/strong> and check out the results:<\/p>\n

    commands:
\n        a20_files_test:
\n            command: \/tmp\/00_file_test.sh > \/tmp\/a20_files_test
\n        a21_files_test:
\n            command: python \/tmp\/00_file_test.py > \/tmp\/a21_files_test<\/em><\/p>\n

    container_commands:
\n        c20_files_test:
\n            command: \/tmp\/00_file_test.sh > \/tmp\/c20_files_test<\/em><\/p>\n

        c21_files_test:
\n            command: python \/tmp\/00_file_test.py > \/tmp\/c21_files_test<\/em><\/p>\n

    $ cat \/tmp\/a20_files_test<\/em><\/p>\n

    value1
\n    value1<\/em>
\n <\/p>\n

  $ cat \/tmp\/a21_files_test
\n    Failed to get env_method_1
\n    value1
\n    value1<\/em><\/p>\n

    $ cat \/tmp\/c20_files_test
\n    value1
\n    value1
\n    value1<\/em><\/p>\n

    $ cat \/tmp\/c21_files_test
\n    value1
\n    value1
\n    value1<\/em><\/p>\n

As we can see from these results, the commands<\/strong> don’t seem to see the $envvar1<\/em> variable in env_method_1<\/em> of either script. Otherwise, all scripts pick up all other variables.<\/p>\n

Next, we run these as the standard ec2-user<\/em> by using SecureShell (ssh):<\/p>\n

   $ \/tmp\/00_file_test.sh
\n    value1
\n    value1
\n    Permission denied @ rb_sysopen – 
\n    \/opt\/elasticbeanstalk\/deploy\/configuration\/containerconfiguration<\/p>\n

    $ python \/tmp\/00_file_test.py
\n    value1
\n    value1
\n    Permission denied @ rb_sysopen – 
\n    \/opt\/elasticbeanstalk\/deploy\/configuration\/containerconfiguration<\/p>\n

As you can see, you need to use `sudo` for the `get-config` command. Lets try that:<\/p>\n

   $ sudo \/tmp\/00_file_test.sh<\/p>\n

    value1
\n    value1<\/p>\n

    $ sudo python \/tmp\/00_file_test.py
\n    Failed to get env_method_1
\n    value1
\n    value1
\nRunning them as `root` with `sudo` yields effectively the same results as running under commands<\/strong>. However, if we run them under the webserver user via the actual webserver, we get the following result:<\/p>\n

    $ cat \/var\/app\/current\/index.php
\n    <?php
\n    echo `\/tmp\/00_file_test.sh`;
\n    ?>
\n    $ curl localhost
\n    value1
\n    value1<\/p>\n

    $ cat \/var\/app\/current\/index.php
\n    <?php
\n    echo `\/usr\/bin\/python \/tmp\/00_file_test.py`;
\n    ?>
\n    $ curl localhost
\n    value1
\n    value1
\n    Failed to get env_method_3
\n    $
\n <\/p>\n

As you can see, the webserver has the environment variables set, but the `get-config` command is still limited to the `root` user. Therefore, it fails.<\/p>\n

Hopefully, these experiments shed some light on how Elastic Beanstalk uses environment variables. We see all tools as having their place and believe each of the preceding methods has appropriate use cases. It’s up to you to determine which method you want to use in which specific situation.<\/p>\n","protected":false},"excerpt":{"rendered":"

How to call and export environment variables in AWS Elastic Beanstalk<\/p>\n","protected":false},"author":2,"featured_media":7166,"menu_order":0,"comment_status":"open","ping_status":"open","template":"","format":"standard","meta":{"content-type":"","nid":"26288","content_type":"blog","created_by":"10130","authored_on":"2023-11-23T17:54:15+00:00","field_article_industries":"","tag_category":"Technical","field_blog_author_text":"by Rackspace Technology Staff","seo_description":"Learn various methods for calling and exporting environment variables in AWS Elastic Beanstalk, enabling flexibility in application deployment.\r\n","field_featured_image":"","insights_image":"\/wp-content\/uploads\/2026\/blog_technical_images\/26288-insights_image-aws-technical-blog-1-insights.png","field_partners":"","rxt_platforms":"Amazon Web Services (AWS)","product":"","publisheddate":"2021-12-01T17:54:15","rxt_solutions":"Onica by Rackspace Technology","opengraph_tag":"","x_tag":"","teaser_flag":"Technical Blog","seo_titile":"AWS Elastic Beanstalk Variables | Rackspace Technology","field_topics":"","field_slug":"how-to-call-and-export-environment-variables-in-aws-elastic-beanstalk","footnotes":""},"categories":[178],"tags":[204],"class_list":["post-7164","blogs","type-blogs","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","tag-technical"],"_links":{"self":[{"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/blogs\/7164","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/blogs"}],"about":[{"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/types\/blogs"}],"author":[{"embeddable":true,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/comments?post=7164"}],"version-history":[{"count":1,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/blogs\/7164\/revisions"}],"predecessor-version":[{"id":7165,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/blogs\/7164\/revisions\/7165"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/media\/7166"}],"wp:attachment":[{"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/media?parent=7164"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/categories?post=7164"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/tags?post=7164"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}