InfluxDB 2.9.1 on AWS User Guide

Overview

This guide covers launching and using the InfluxDB 2.9.1 on Ubuntu 24.04 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg Search, OLAP and Time-Series database listing on AWS Marketplace; you pick it as the software version when you subscribe and launch.

InfluxDB 2 is an open source time series database: one server (influxd) with a built in web UI, an HTTP API for writing points (line protocol) and querying them (Flux and InfluxQL), buckets with retention periods, tasks, checks and alerts, and token based access control. Telegraf, Grafana and the InfluxDB client libraries for Python, Go, Java, JavaScript and C# all talk to it over the HTTP API.

The cloudimg image adds:

• No onboarding wizard, no default login. A fresh InfluxDB 2 serves an unauthenticated setup endpoint: the first visitor becomes the owner. This image ships with an empty data directory and completes the setup itself on first boot, on a private loopback-only server, with an admin password and an all-access operator token generated on your instance. Neither is baked into the image, and InfluxDB and nginx refuse to start until the setup has finished.
• HTTPS from the first boot. nginx serves the web UI and the API on port 443 with a certificate generated on your instance; port 80 redirects to HTTPS. influxd itself listens on 127.0.0.1 only. Requests for a host name the instance does not serve get no answer.
• Hardened InfluxDB settings. API tokens are stored hashed, strong passwords are required, Flux and template HTTP requests cannot reach private, loopback or link-local addresses, template file:// URLs are off and no usage telemetry leaves the instance.
• Built from source with a current Go. The upstream 2.9.1 binaries were built with Go 1.25.10, a Go release line that no longer receives fixes. This image compiles InfluxDB 2.9.1 and the influx CLI 2.8.0 from their source with Go 1.26.10 and the fixed releases of the dependencies with known advisories; the build record is in /usr/share/doc/influxdb/BUILD-PROVENANCE.txt.
• Metadata access blocked. InfluxDB and nginx cannot reach the EC2 instance metadata service, so a Flux query or task cannot fetch instance credentials, and the AMI requires IMDSv2. The client address in the nginx log comes from the connection, never from a header a client can forge.
• Fully patched Ubuntu 24.04 LTS at build time, with unattended security upgrades switched on.

What is on the image: influxd 2.9.1 (/usr/local/bin/influxd), the influx CLI 2.8.0 (/usr/local/bin/influx), nginx, Ubuntu 24.04 LTS, cloud-init and the AWS Systems Manager agent.

Default user: ubuntu · Architecture: x86_64 · Recommended instance type: m5.large

Prerequisites

• An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet with a route to the internet (or a private route you use for management).
• A security group that allows TCP 443 (web UI and API) and TCP 80 (redirects to HTTPS) from the clients and people who will use InfluxDB, and TCP 22 (SSH) from your own networks only. InfluxDB's own port 8086 is not exposed and does not need a rule.

Step 1: Launch the instance

In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration, pick InfluxDB 2.9.1 on Ubuntu 24.04 as the software version and your Region, then Launch through EC2. Choose m5.large (or larger for heavy write loads), your key pair and a security group as above.

Your data is stored on the root volume under /var/lib/influxdb, so give the root volume the space your retention needs (for example 100 GiB instead of the default 8 GiB). The root file system grows to fill the volume on first boot.

With the AWS CLI (replace the values in angle brackets):

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --block-device-mappings 'DeviceName=/dev/sda1,Ebs={VolumeSize=100,VolumeType=gp3}' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=influxdb}]'

Step 2: Connect to your instance

ssh -i <your-key.pem> ubuntu@<public-ip>

Step 3: Check the services

First boot takes a few seconds. Then InfluxDB, nginx and the first boot unit are active:

systemctl is-active influxdb nginx influxdb-firstboot

active
active
active

nginx is the only network listener besides SSH; influxd listens on 127.0.0.1:8086 only:

sudo ss -tlnp | awk 'NR==1 || /nginx|sshd|influxd/' | awk '{print $1, $4}'

State Local
LISTEN 0.0.0.0:443
LISTEN 0.0.0.0:80
LISTEN 0.0.0.0:22
LISTEN 127.0.0.1:8086
LISTEN [::]:443
LISTEN [::]:80
LISTEN [::]:22

The binaries report their release:

influxd version
influx version

InfluxDB v2.9.1 (git: d4fa1941fd) build_date: 2026-10-20T09:18:48Z
Influx CLI 2.8.0 (git: 8cdf401) build_date: 2026-10-20T09:21:31Z

Step 4: Get your URL, password and token

sudo cat /root/influxdb-credentials.txt

The file holds the address InfluxDB is served as (your instance's public IP address by default) and the secrets generated on this instance:

# InfluxDB 2.9.1 - generated on first boot by influxdb-firstboot.service. Unique to this instance; keep it safe.
# The web UI and the HTTP API are served over HTTPS by nginx with this instance's own self-signed certificate
# (browsers warn once; API clients need the certificate or an insecure-skip-verify option).

INFLUXDB_URL=https://<public-ip>/
influxdb.host=<public-ip>
influxdb.username=admin
influxdb.password=<32 letters and digits>
influxdb.org=cloudimg
influxdb.bucket=metrics
influxdb.token=<64 letters and digits>

# The token above is the all-access OPERATOR token. Create narrower tokens for applications:
#   https://<public-ip>/ -> Load Data -> API Tokens   (or: influx auth create --help)
# On the instance, influxd also answers on loopback: http://127.0.0.1:8086
# Change the host name:  sudo influxdb-set-host <dns-name>
# User guide: https://www.cloudimg.co.uk/guides/influxdb-2-9-1-on-ubuntu-24-04-aws/

The first boot created the organisation cloudimg, the bucket metrics (infinite retention) and the user admin, and wrote an hour of demo points (cloudimg_demo) so the UI has something to show. The onboarding endpoint now reports that setup is complete:

curl -sk https://127.0.0.1/api/v2/setup

{
    "allowed": false
}

Step 5: Sign in to the web UI

Open INFLUXDB_URL in your browser. The certificate is self signed (generated on your instance), so accept the browser warning once, or use your own name and certificate (Step 10). Sign in as admin with influxdb.password:

The Data Explorer shows the cloudimg_demo measurement in the metrics bucket; pick the measurement and the cpu field and choose Submit:

Load Data → API Tokens lists the operator token (shown as admin's Token) and lets you create read or write tokens scoped to single buckets for your applications. Tokens are stored hashed, so a token's value is shown only once, when you create it:

Step 6: Use the influx CLI on the instance

On the instance the CLI can talk to influxd directly over loopback. Pass the token in the INFLUX_TOKEN environment variable rather than on the command line:

export INFLUX_TOKEN="$(sudo sed -n 's/^influxdb.token=//p' /root/influxdb-credentials.txt)"
influx bucket list --host http://127.0.0.1:8086 --org cloudimg

ID          Name        Retention   Shard group duration    Organization ID     Schema Type
0462d13e5a57d7e9    _monitoring 168h0m0s    24h0m0s         70773f8d8b21cdb3    implicit
5aebfc3bfe7d6154    _tasks      72h0m0s     24h0m0s         70773f8d8b21cdb3    implicit
5e27ce71d7c8965d    metrics     infinite    168h0m0s        70773f8d8b21cdb3    implicit

Count the demo points with a Flux query:

export INFLUX_TOKEN="$(sudo sed -n 's/^influxdb.token=//p' /root/influxdb-credentials.txt)"
influx query --host http://127.0.0.1:8086 --org cloudimg \
  'from(bucket:"metrics") |> range(start:-24h) |> filter(fn:(r) => r._measurement == "cloudimg_demo" and r._field == "cpu") |> count()' \
  | awk '/cloudimg_demo/{print "cloudimg_demo cpu points:", $NF}'

cloudimg_demo cpu points: 60

To create a narrower token for an application, see influx auth create --help (for example --write-bucket <bucket-id>), or use Load Data → API Tokens in the UI.

Step 7: Write and query over HTTPS

Remote clients use https://<public-ip>/ (or your own DNS name) with a token. This writes one point in line protocol and reads it back with Flux. The token is read into a shell variable and handed to curl as a header file, so it never appears on a command line:

TOKEN="$(sudo sed -n 's/^influxdb.token=//p' /root/influxdb-credentials.txt)"
HOST="$(sudo sed -n 's/^influxdb.host=//p' /root/influxdb-credentials.txt)"
HDR="$(mktemp)"; printf 'Authorization: Token %s\n' "$TOKEN" > "$HDR"
curl -s -o /dev/null -w 'write: HTTP %{http_code}\n' --cacert /etc/nginx/ssl/influxdb.crt --resolve "$HOST:443:127.0.0.1" \
  -X POST -H "@$HDR" --data-binary "weather,site=lab temperature=21.5 $(date +%s)" \
  "https://$HOST/api/v2/write?org=cloudimg&bucket=metrics&precision=s"
curl -s --cacert /etc/nginx/ssl/influxdb.crt --resolve "$HOST:443:127.0.0.1" -X POST -H "@$HDR" \
  -H 'Accept: application/csv' -H 'Content-Type: application/vnd.flux' \
  --data 'from(bucket:"metrics") |> range(start:-10m) |> filter(fn:(r) => r._measurement == "weather") |> last()' \
  "https://$HOST/api/v2/query?org=cloudimg" | awk -F, '/weather/{print "read back:", $7, $8, $9}'
rm -f "$HDR"

write: HTTP 204
read back: 21.5 temperature weather

From another machine, copy /etc/nginx/ssl/influxdb.crt from the instance and pass it as the CA certificate (--cacert for curl, ssl_ca for Telegraf's [[outputs.influxdb_v2]]), or use your own certificate (Step 10). A Telegraf output looks like this:

[[outputs.influxdb_v2]]
  urls = ["https://<public-ip>"]
  token = "$INFLUX_TOKEN"
  organization = "cloudimg"
  bucket = "metrics"
  tls_ca = "/etc/telegraf/influxdb.crt"

Step 8: Check the security model

Requests without a token, or with a wrong one, are refused:

curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1/api/v2/buckets
curl -sk -o /dev/null -w '%{http_code}\n' -H 'Authorization: Token admin' https://127.0.0.1/api/v2/buckets

401
401

The onboarding endpoint cannot be used to claim the instance, through nginx or on InfluxDB's own port:

curl -sk -o /dev/null -w 'via nginx: %{http_code}\n' -X POST -H 'Content-Type: application/json' \
  --data '{"username":"x","password":"Sample-Passw0rd-x","org":"x","bucket":"x"}' https://127.0.0.1/api/v2/setup
curl -s -X POST -H 'Content-Type: application/json' \
  --data '{"username":"x","password":"Sample-Passw0rd-x","org":"x","bucket":"x"}' http://127.0.0.1:8086/api/v2/setup | grep -o '"message": "[^"]*"'

via nginx: 403
"message": "onboarding has already been completed"

The settings that harden InfluxDB itself:

grep -E '^(http-bind-address|use-hashed-tokens|strong-passwords|hardening-enabled|template-file-urls-disabled|reporting-disabled)' /etc/influxdb/config.toml

http-bind-address = "127.0.0.1:8086"
use-hashed-tokens = true
strong-passwords = true
hardening-enabled = true
template-file-urls-disabled = true
reporting-disabled = true

InfluxDB and nginx cannot reach the instance metadata service, and Flux refuses to fetch link-local or private addresses:

systemctl show -p IPAddressDeny influxdb nginx
export INFLUX_TOKEN="$(sudo sed -n 's/^influxdb.token=//p' /root/influxdb-credentials.txt)"
OUT="$(influx query --host http://127.0.0.1:8086 --org cloudimg \
  'import "experimental/http" import "array" array.from(rows: [{v: string(v: http.get(url: "http://169.254.169.254/latest/meta-data/").statusCode)}])' 2>&1 || true)"
grep -o 'no such host' <<<"$OUT"

IPAddressDeny=168.63.129.16/32 169.254.169.254/32 fd00:ec2::254/128
IPAddressDeny=168.63.129.16/32 169.254.169.254/32 fd00:ec2::254/128
no such host

The full self test that the image build runs is available too:

sudo influxdb-selftest

Step 9: Retention, users and backups

• Retention: the metrics bucket keeps data forever. Set a retention period in the UI (Load Data → Buckets → Settings) or with influx bucket update --id <bucket-id> --retention 30d.
• More users: Settings → Members in the UI, or influx user create followed by influx user password (which prompts for the password). Passwords must be at least 8 characters and mix upper case, lower case, digits or symbols.
• Backups: influx backup /path/to/backup --host http://127.0.0.1:8086 (with INFLUX_TOKEN set as in Step 6) writes a full backup, including the metadata needed to restore users and tokens; keep it safe. EBS snapshots of the root volume are an alternative.

Step 10: Your own DNS name and certificate

Point a DNS name at the instance, then make it the served name. This writes a new self signed certificate for that name and adds it to the names nginx answers for:

sudo influxdb-set-host influx.example.com

To use a certificate from your own CA or from Let's Encrypt, replace /etc/nginx/ssl/influxdb.crt and /etc/nginx/ssl/influxdb.key (keep the key mode 0600) and run sudo systemctl reload nginx. Clients then trust it without --cacert.

Step 11: Change the admin password or rotate the token

Change the admin password in the UI (user menu → Change Password) or with the CLI, which prompts for the new password:

export INFLUX_TOKEN="$(sudo sed -n 's/^influxdb.token=//p' /root/influxdb-credentials.txt)"
influx user password --host http://127.0.0.1:8086 --name admin

To retire the operator token, create a new all-access token in Load Data → API Tokens, update /root/influxdb-credentials.txt and your clients, then delete the old token. Keep at least one all-access token.

Step 12: Server components

Logs: journalctl -u influxdb and /var/log/nginx/.

Never empty /var/lib/influxdb on a running instance and start InfluxDB by hand: an InfluxDB with no data serves the unauthenticated onboarding endpoint. The influxdb.service unit refuses to start without the first boot's ready marker.

Step 13: Security recommendations

• Allow port 22 in the security group from your own networks only, and open 80 and 443 only to the clients and people that need InfluxDB.
• Give each application its own token scoped to the buckets it needs, and keep the operator token for administration.
• Use your own DNS name and a certificate your clients trust (Step 10).
• Keep the operating system patched; unattended security upgrades are on, and sudo apt-get update && sudo apt-get upgrade applies everything else.

Support and licensing

InfluxDB 2.9.1 and the influx CLI are open source software under the MIT License; copies are at /usr/share/doc/influxdb/LICENSE and /usr/share/doc/influxdb/LICENSE.influx-cli. This image builds the 2.9.1 source from https://github.com/influxdata/influxdb with newer dependency versions and one small fix (an empty password at sign in no longer causes a server error when strong passwords are on), all listed in /usr/share/doc/influxdb/BUILD-PROVENANCE.txt. There is no per user or per CPU licence fee. The AMI price covers cloudimg's hardening, first boot setup and support. InfluxDB is a trademark of InfluxData; cloudimg is not affiliated with or endorsed by InfluxData.

• Email: support@cloudimg.co.uk
• Website: https://www.cloudimg.co.uk
• Support: 24/7, with a 24 hour response SLA