Apache Ignite

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for Apache Ignite. Select the SecureAnyCloud listing and choose Select, then Continue on the subscription summary.

Pick an instance type of m5.large or larger. Choose your EC2 key pair under Key pair (login). Under Network settings, select your VPC and subnet, and either create or select a security group that allows inbound port 22 from your management network. Leave the root volume at the default size or larger. The Ignite data volume is attached automatically from the image.

Select Launch instance. First-boot initialization activates the cluster and generates the per-instance password. It takes a minute or two after the instance state becomes Running and the status checks pass.

The following command launches an instance from the SecureAnyCloud Apache Ignite Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing. Replace <key-name> with your EC2 key pair name, <subnet-id> with your subnet ID, and <security-group-id> with a security group that opens inbound port 22.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --metadata-options HttpTokens=required \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=ignite-01}]'

On success, the command prints a JSON document. Note the instance ID. When the instance is running, retrieve its public address with aws ec2 describe-instances --instance-ids <instance-id> --query "Reservations[].Instances[].PublicIpAddress" --output text.

Connect over SSH with the key pair you selected and the public IP address from step 2. The SSH login user depends on the operating system of the AMI variant you launched:

AMI variant SSH login user

Apache Ignite 2.16 on Ubuntu 24.04 ubuntu

ssh <login-user>@<public-ip>

Wait until the instance has passed both EC2 status checks before you connect. The first-boot service runs before the SSH daemon is ready, so Ignite is initialized by the time you can log in.

The first-boot service generates a fresh password for the ignite user on this instance and writes it, with the connection details, to /root/ignite-credentials.txt. Only the root user can read the file. Display it from your SSH session:

sudo cat /root/ignite-credentials.txt

The file looks like this, with a password unique to your instance:

IGNITE_USERNAME=ignite IGNITE_PASSWORD=<your generated password> IGNITE_HOST=127.0.0.1 IGNITE_SQL_PORT=10800 IGNITE_PUBLIC_IP=<your instance public IP>

The default ignite / ignite account that ships with Apache Ignite is rotated away during first boot, so it no longer works. Use the generated password for every connection.

Ignite runs under systemd as the ignite service and starts automatically on boot. Confirm that it is active:

systemctl is-active ignite

The command prints active. Next, confirm that the thin-client and SQL connector is listening. Ignite binds to the loopback address 127.0.0.1 on port 10800, so it is reachable from the instance itself:

ss -tln | grep 10800

The output shows a listening socket on 127.0.0.1:10800. The discovery (47500) and communication (47100) ports are bound to loopback in the same way.

Ignite bundles sqlline.sh, a SQL shell that connects over the thin-client JDBC driver. Open an interactive session against the local node with the generated password. Replace <password> with the value from /root/ignite-credentials.txt:

export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 /opt/ignite/bin/sqlline.sh -u 'jdbc:ignite:thin://127.0.0.1/' -n ignite -p '<password>'

The screenshot below shows a complete session that creates a table, inserts rows and reads them back on the running node.

An authenticated Ignite thin-client SQL session creating a table, inserting rows and reading them back.

The following command runs a full create, insert and read round trip in a single non-interactive invocation. It creates a table, inserts two rows, reads them back and drops the table. Replace <password> with the value from /root/ignite-credentials.txt:

export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 IGNITE_HOME=/opt/ignite printf '%s\n' \
  "CREATE TABLE IF NOT EXISTS demo (id INT PRIMARY KEY, name VARCHAR, qty INT);" \
  "INSERT INTO demo (id, name, qty) VALUES (1, 'widget', 42);" \
  "INSERT INTO demo (id, name, qty) VALUES (2, 'gadget', 17);" \
  "SELECT id, name, qty FROM demo ORDER BY id;" \
  "DROP TABLE demo;" \
  "!quit" \
  | /opt/ignite/bin/sqlline.sh --silent=true --showHeader=true --outputformat=csv \
  -u 'jdbc:ignite:thin://127.0.0.1/' -n ignite -p '<password>'

The SELECT returns the two rows you inserted, which confirms the authenticated data path end to end.

control.sh is the cluster administration utility. Authentication is enabled, so pass the ignite user and the generated password. Report the cluster state, which is ACTIVE on this image:

export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 IGNITE_HOME=/opt/ignite /opt/ignite/bin/control.sh --user ignite --password '<password>' --state

The screenshots below show the service active with every data-grid port bound to loopback, and the default credential rejected while native persistence lives on the dedicated volume.

The Ignite service active, the thin-client, discovery and communication ports bound to loopback only, and the Apache Ignite 2.16.0 core library.

The default ignite credential rejected after first-boot rotation, and native persistence on a dedicated data volume with a per-instance credential file.

The thin-client port is loopback only, so connect a remote SQL client or application by forwarding the port over SSH. From your workstation, replace <login-user> and <public-ip> with your instance's values:

ssh -L 10800:127.0.0.1:10800 <login-user>@<public-ip>

While that tunnel is open, point any Ignite thin-client, JDBC tool or application at 127.0.0.1:10800 on your workstation. It reaches the node securely and authenticates with the generated password. For a production deployment, bind Ignite to a private address inside your VPC and control access with security groups instead of a tunnel.

Ignite native persistence, the work directory and the write-ahead log are stored under /var/lib/ignite, which is a dedicated EBS volume separate from the operating system disk. Confirm the mount:

findmnt /var/lib/ignite

The output shows /var/lib/ignite is its own ext4 filesystem on a separate device. Because the data directory is on its own volume, you can take an Amazon EBS snapshot of it on its own schedule and grow it independently of the root volume. Check the available space at any time with:

df -h /var/lib/ignite

systemd manages Ignite, and the service starts automatically on boot.

Check the service status:

systemctl status ignite --no-pager

Stop, start and restart the service when needed:

sudo systemctl stop ignite
sudo systemctl start ignite
sudo systemctl restart ignite

Because native persistence is enabled, the cluster state and all persisted data survive a restart. The node comes back up ACTIVE with your data intact. Ignite writes its log under the work directory on the data volume and to the systemd journal. Review the log when you diagnose a startup or runtime problem:

sudo journalctl -u ignite --no-pager | tail -n 100

/var/lib/ignite is a dedicated EBS volume, so the simplest durable backup is an Amazon EBS snapshot of that volume. The snapshot captures the persistence store, work directory and write-ahead log as a point-in-time copy. Schedule snapshots with Amazon Data Lifecycle Manager or AWS Backup.

For a file-level archive, stop the service first so the store is quiesced, then archive the data directory:

sudo systemctl stop ignite
sudo tar -czf /var/backups/ignite-$(date +%F).tgz -C /var/lib/ignite .
sudo systemctl start ignite

Ignite also supports its own snapshot feature through control.sh --snapshot create <name> for consistent online backups of persisted caches. Consult the Ignite documentation for restore procedures.

This image runs Ignite as a single-node cluster, which suits development, testing and smaller production workloads. Ignite is designed to scale horizontally by adding nodes. To build a multi-node cluster:

• Launch additional instances from this same AMI, one per node, in the same VPC.
• Allow inbound TCP ports 47500 (discovery) and 47100 (communication) between the nodes, and 10800 from your application tier.
• On every node, edit /etc/ignite/ignite-config.xml and change localHost from 127.0.0.1 to the node's own private IP address. List the private addresses of the cluster in the TcpDiscoveryVmIpFinder addresses.
• Restart Ignite on each node. Confirm with control.sh --state that the cluster is ACTIVE with the expected number of server nodes.

The Apache Ignite documentation at https://ignite.apache.org/docs/latest/ covers clustering, data partitioning, SQL, compute and performance tuning in depth.