Apache HBase on AWS User Guide

Overview

Apache HBase is the open source, distributed, scalable NoSQL big-data store modeled on Google Bigtable, providing random real-time read and write access to very large sparse tables that run on top of Hadoop and HDFS. The cloudimg image installs HBase 2.5.15 in single-node standalone mode: the HBase Master, a RegionServer and an embedded ZooKeeper quorum all run inside one JVM against the local filesystem, so a single EC2 instance gives you a fully functional HBase for development, testing, single-tenant stores, embedded time-series and proof-of-concept workloads with no multi-node Hadoop cluster to stand up. All HBase services bind to loopback; the read-only Master status console is fronted by an nginx reverse proxy on TCP 80 with HTTP Basic auth, and a unique administrator password is generated on the first boot of every instance. Backed by 24/7 cloudimg support.

What is included:

• Apache HBase 2.5.15 (Apache-2.0) in single-node standalone mode (Master + RegionServer + embedded ZooKeeper in one JVM)
• OpenJDK 11
• A dedicated 40 GiB EBS data volume at /var/lib/hbase holding hbase.rootdir, the write-ahead log and the embedded ZooKeeper dataDir — separate from the OS disk, mounted by filesystem UUID and re-provisioned with every instance
• All HBase services bound to 127.0.0.1 (Master RPC 16000, Master status UI 16010, RegionServer RPC 16020, RegionServer info 16030, embedded ZooKeeper 2181)
• nginx reverse proxy on :80 with HTTP Basic auth in front of the Master status console, plus an unauthenticated /health endpoint
• Per-instance admin password generated at first boot, in a root-only file
• hbase and nginx as systemd units, enabled and active
• 24/7 cloudimg support

Prerequisites

An active AWS account with permission to launch EC2 instances, create security groups and subscribe to AWS Marketplace products, and an EC2 key pair in the target region. m5.large (2 vCPU / 8 GiB RAM) is the recommended instance type — HBase plus the embedded ZooKeeper JVM is memory hungry. Security group inbound: allow 22/tcp from your management network and 80/tcp from the users who reach the Master status console (front port 80 with TLS for public exposure — see Enabling HTTPS).

Connecting to your instance

Connect over SSH as the default login user for your AMI's operating system. The password referenced throughout this guide lives in a root-only file on the instance.

Step 1 — Deploy from the AWS Marketplace

Sign in to the AWS Marketplace, search for Apache HBase by cloudimg, choose Continue to Subscribe, accept the terms, then Continue to Configuration and Continue to Launch. Pick the m5.large instance type, select your key pair, and in the security group allow SSH (22) from your management network and HTTP (80) from the users who reach the Master status console. Review the dedicated 40 GiB data volume, then launch.

Step 2 — Deploy from the AWS CLI

aws ec2 run-instances \
  --image-id <ami-id-from-the-listing> \
  --instance-type m5.large \
  --key-name <your-key-pair> \
  --security-group-ids <your-sg> \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=hbase}]'

Step 3 — Connect to your instance

ssh ubuntu@<instance-public-ip>

Step 4 — Confirm the services are running

systemctl is-active hbase.service nginx.service

Both services report active:

active
active

Step 5 — Confirm the gateway answers

The nginx reverse proxy serves an unauthenticated /health endpoint for liveness checks and fronts the HBase Master status console behind HTTP Basic auth:

curl -s -o /dev/null -w 'health endpoint -> HTTP %{http_code}\n' http://127.0.0.1/health
curl -s -o /dev/null -w 'Master UI (no auth) -> HTTP %{http_code}\n' http://127.0.0.1/

The /health endpoint returns HTTP 200; the Master console returns HTTP 401 until you supply the per-instance credentials:

health endpoint -> HTTP 200
Master UI (no auth) -> HTTP 401

Step 6 — Retrieve your admin password

The administrator password is generated uniquely on the first boot of your instance and written to a root-only file:

sudo grep -E '^HBASE_ADMIN_' /root/hbase-credentials.txt

HBASE_ADMIN_USER is admin and HBASE_ADMIN_PASSWORD is the password that protects the Master status console.

Step 7 — Open the Master status console

The Master console sits behind nginx HTTP Basic auth. Confirm a wrong password is rejected while the real one returns the console. Run the password-bearing request with your own password substituted in — for example, to fetch the console with the credentials from Step 6:

curl -s -o /dev/null -w '%{http_code}\n' -u admin:<HBASE_ADMIN_PASSWORD> http://127.0.0.1/

A wrong password returns HTTP 401; the correct one returns HTTP 200. In a browser, open http://<instance-public-ip>/ and sign in as admin with the password from Step 6. The console shows the RegionServer, cluster base stats, backup masters and the user tables backed by the dedicated data volume.

Step 8 — Create a table and put, get and scan rows with the HBase shell

HBase organises data as table / row / column-family:qualifier. The HBase shell creates tables and puts, gets and scans rows. Run it as the hbase service user:

sudo -u hbase /opt/hbase/bin/hbase shell -n <<'EOF'
create 'sensor_readings', {NAME=>'data'}, {NAME=>'meta'}
put 'sensor_readings', 'device-001#1', 'data:temp', '21.4'
put 'sensor_readings', 'device-001#1', 'data:humidity', '58'
get 'sensor_readings', 'device-001#1'
scan 'sensor_readings'
EOF

get returns the two cells you put and scan lists the row, confirming the data plane round-trips end to end:

COLUMN                     CELL
 data:humidity             timestamp=..., value=58
 data:temp                 timestamp=..., value=21.4
1 row(s)

Step 9 — Browse tables and regions in the Master console

The Master console is the status console for the standalone cluster. The Tables section lists every user and system table with its column families and region state; the region visualizer shows storefile size per RegionServer.

The Software Attributes section at the foot of the page reports the HBase, Hadoop and ZooKeeper versions, the ZooKeeper quorum and the HBase root directory on the dedicated data volume.

Confirm the HBase version

sudo -u hbase /opt/hbase/bin/hbase version 2>/dev/null | head -1

HBase 2.5.15

Data persistence

All HBase data — the store files under hbase.rootdir, the write-ahead log and the embedded ZooKeeper state — lives on the dedicated EBS data volume mounted at /var/lib/hbase, separate from the OS disk and mounted by filesystem UUID so it survives reboots and re-launches:

df -h /var/lib/hbase

Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme1n1     40G  568K   38G   1% /var/lib/hbase

Enabling HTTPS

For production, terminate TLS at nginx with a real domain pointed at the instance's public IP. Install certbot and request a certificate (replace the domain):

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain.example.com

Backup and maintenance

All HBase data lives on the dedicated EBS data volume at /var/lib/hbase. Take an EBS snapshot of that volume to back up your store, and keep the OS patched with sudo apt update && sudo apt upgrade. HBase restarts cleanly with sudo systemctl restart hbase nginx. For larger datasets, resize the EBS volume in the AWS console and grow the filesystem. To scale beyond a single node, migrate to a distributed HBase deployment backed by HDFS.

Support

This image is backed by 24/7 cloudimg support. Contact us by email and chat for help with schema and data-model design, the HBase shell and client APIs, capacity and data-volume sizing, scaling toward a distributed cluster, TLS and backups.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.