What's the difference between the bash and cloud-init formats?

A plain bash script runs top-to-bottom as `/bin/bash` on first boot, exactly like a shell script you'd run manually. Cloud-init YAML uses cloud-init's declarative modules (`packages`, `users`, `runcmd`, etc.), which run in a defined order across boot stages and work across many Linux distributions and cloud providers, not just EC2's bash execution.

Where does EC2 actually run this user data?

On instance launch, EC2 passes the User Data field to cloud-init (present on all standard Amazon Linux, Ubuntu, and most Linux AMIs), which either executes it directly as a script (if it starts with a shebang like #!/bin/bash) or interprets it as a cloud-init config (if it starts with #cloud-config).

Why does the script redirect output to a log file?

User data runs unattended during boot with no terminal attached, so without redirecting output you have no way to debug a failure. Both formats append their output to a log file (default `/var/log/user-data.log`) so you can SSH in afterward and check exactly what happened.

Does the generated user data run only once?

By default, EC2 and cloud-init both run user data once, on first boot only. If you need it to run on every boot, that requires additional cloud-init directives (like a `cloud-config` `runcmd` combined with disabling the once-per-instance guard) that this generator does not add.

EC2 User Data Generator - Bash & Cloud-Init Bootstrap Scripts

Overview

Introduction

Writing EC2 bootstrap logic from scratch means remembering the right shebang, the right package-manager invocation, and how to wire up logging so a failed boot is actually debuggable, every single time.

This tool generates that user data for you, as either a plain bash script or a cloud-init YAML document, with package installation, an optional user, hostname configuration, and a log redirect already wired up.

What Is EC2 User Data Generator?

A generator for EC2 instance user data, the script or configuration EC2 passes to cloud-init on first boot.

It supports two output formats: a plain bash script (starting with `#!/bin/bash`) and a cloud-init YAML document (starting with `#cloud-config`), both accepting a package list, a username to create with sudo access, a hostname, and a log file path.

How EC2 User Data Generator Works

In bash mode, the script sets `set -euxo pipefail` so it exits on the first error rather than silently continuing, redirects all output to the log file via `tee -a`, then runs `apt-get update`/`install`, hostname setting, and user creation in sequence.

In cloud-init mode, the same intent is expressed declaratively: `packages` and `package_update: true` handle installation, `users` adds the account with `sudo: ['ALL=(ALL) NOPASSWD:ALL']`, `hostname`/`fqdn` set the hostname, and a `runcmd` entry appends a completion line to the log file.

When To Use EC2 User Data Generator

Use it when launching an EC2 instance (directly, via an Auto Scaling group, or via CloudFormation/Terraform's user_data field) and you need it to install packages, create a deploy user, and log what happened, without writing that boilerplate by hand each time.

It's also useful as a starting point you then extend with your own application-specific setup steps.

Often used alongside ECS Task Definition Generator and AWS Lambda Config Generator.

Features

Advantages

Produces both a portable cloud-init YAML form and a simpler plain bash form from the same inputs.
Wires up output logging by default, so failures during boot are actually diagnosable via SSH afterward.
Includes a ready-to-use sudo user creation snippet, one of the most commonly hand-written parts of bootstrap scripts.

Limitations

Assumes a Debian/Ubuntu-style `apt-get` package manager; Amazon Linux/RHEL-based AMIs need the packages section adapted to `yum`/`dnf`.
Doesn't handle EC2-specific IMDS calls, instance metadata retrieval, or multi-part MIME user data with multiple scripts.

Examples

Bash script installing nginx and creating a deploy user

Input

format: bash, packages: nginx, git, username: deploy, hostname: web-01, logFile: /var/log/user-data.log

Output

#!/bin/bash
set -euxo pipefail

exec > >(tee -a /var/log/user-data.log) 2>&1

hostnamectl set-hostname web-01

apt-get update -y
apt-get install -y nginx git

useradd -m -s /bin/bash deploy
usermod -aG sudo deploy
echo "deploy ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers.d/deploy

echo "user-data script completed at $(date -u --iso-8601=seconds)" >> /var/log/user-data.log

Each provided field adds its own block; omitted fields (like packages or username) are skipped entirely rather than left blank.

Best Practices & Notes

Best Practices

Always redirect user data output to a log file, unattended boot failures are otherwise nearly impossible to debug.
Keep user data idempotent-safe where possible, since some tooling (Auto Scaling health-check replacements, manual `cloud-init clean && reboot`) can re-run it.
Prefer baking heavyweight setup into a custom AMI and reserving user data for lightweight, environment-specific configuration.

Developer Notes

Both output modes are built from the same four inputs (packages, username, hostname, log file) via plain string templating, no YAML or shell library is involved, so the output is deterministic and directly a function of the fields provided. The bash form uses `set -euxo pipefail` for fail-fast behavior; the cloud-init form relies on cloud-init's own module ordering (`package_update`/`packages` before `users` before `runcmd`) rather than an explicit sequence.

EC2 User Data Generator Use Cases

Bootstrapping a fresh EC2 instance with required packages and a deploy user on first boot
Setting an instance's hostname to match its role (e.g. web-01, db-primary) via user data instead of a custom AMI
Providing the `user_data` value for a Terraform `aws_instance` or CloudFormation `AWS::EC2::Instance` resource

Common Mistakes

Forgetting the leading `#!/bin/bash` or `#cloud-config` line when hand-editing, without it EC2/cloud-init won't recognize the format.
Not redirecting output anywhere, then having no way to diagnose why an instance came up in a broken state.

Tips

Pair this with the Security Group Generator to also produce the ingress rules a freshly bootstrapped web or database instance will need.

EC2 User Data Generator