Introduction

User data on EC2 is a practical way to bootstrap environment variables during instance initialization. The important detail is that "set an environment variable" can mean several different scopes: for the current shell, for all future login shells, or for a system service that starts your application.

User Data Runs at Boot Time

On Linux EC2 instances, user data is commonly handled through cloud-init. That means the script runs during instance initialization, which makes it a good place to write environment configuration files.

A simple user-data script looks like this:

1#!/bin/bash
2set -e
3
4echo 'APP_ENV=production' >> /etc/environment
5echo 'API_BASE_URL=https://api.example.com' >> /etc/environment

This writes variables into /etc/environment, which is one common way to make them available system-wide for later sessions.

/etc/environment Versus Profile Scripts

There is an important distinction between writing to /etc/environment and writing to a shell profile script.

• '/etc/environment is good for general system-wide environment values.'
• '/etc/profile.d/*.sh is good for shell-oriented exports.'

Example using a profile script:

1#!/bin/bash
2set -e
3
4cat > /etc/profile.d/myapp.sh <<'SCRIPT'
5export APP_ENV=production
6export API_BASE_URL=https://api.example.com
7SCRIPT
8
9chmod 644 /etc/profile.d/myapp.sh

This is useful when you care about interactive shells and login sessions.

Systemd Services Need Their Own Attention

If your application runs as a systemd service, writing variables to shell-oriented files may not be enough by itself. Services often need explicit environment configuration in the unit or an environment file referenced by the unit.

Example environment file:

1#!/bin/bash
2set -e
3
4cat > /etc/myapp.env <<'ENV'
5APP_ENV=production
6API_BASE_URL=https://api.example.com
7ENV

Then in the service unit:

[Service]
EnvironmentFile=/etc/myapp.env
ExecStart=/usr/bin/python3 /opt/myapp/app.py

That is often the most reliable pattern for application processes started by systemd.

Keep Secrets Out of User Data

User data is not the right place for high-sensitivity secrets. It can be viewed through the EC2 control plane and should be treated as bootstrap configuration rather than as a secret vault.

For sensitive values, prefer a dedicated secret-management path and have the instance fetch them securely at runtime.

Verify the Result

After boot, confirm that the variables were written where you expected.

cat /etc/environment
cat /etc/profile.d/myapp.sh
systemctl show myapp --property=Environment

Validation matters because many "environment variable" bugs are really scope bugs. The variable exists, but not in the process or shell where you expected it.

Reprovisioning Beats Manual Drift

If the variable setup matters to the role of the instance, keep it in user data or another bootstrap path rather than patching it manually after launch. Reproducible provisioning is more valuable than one-off shell edits that nobody remembers later.

Common Pitfalls

• Assuming a variable written in one shell context automatically applies to systemd services.
• Putting sensitive secrets directly into user data.
• Writing exports to shell startup files when the real target is a background service.
• Forgetting that user data usually runs at launch time rather than every reboot by default.
• Debugging application code when the real problem is the variable scope or bootstrap file location.

Summary

• EC2 user data is a good place to bootstrap environment configuration during instance initialization.
• Decide whether the variable should apply to shells, the whole system, or a systemd service.
• '/etc/environment, /etc/profile.d, and service EnvironmentFile entries serve different scopes.'
• Validate the final runtime environment after boot instead of assuming the variable landed in the right place.
• Keep secrets out of user data and use a safer secret-management path for sensitive values.