Single Region

Single region deployment in AWS consolidates all infrastructure components within one selected region.

Single Region Deployment on EKS

⚠️ Reference Only (If you are using Terraform)

The highflame-iac repository contains reference Terraform configurations for managing Highflame cloud resources. Do not copy these directly into your IaC code or run them against your cloud environment without first reviewing and patching them to match your account, networking, and security requirements.

Benefits of Single-Region Deployment

  • Simplified Management: Easier oversight and maintenance due to a single, centralized location for all resources.

  • Cost Efficiency: Potentially lower data transfer costs between services within the same region.

  • Consistency: Ensures uniformity of services and offers within a specific AWS region.

Prerequisites

Ensure that the following tools and resources are installed and available:

  • Access to AWS Management Console

  • Set of domain names for Highflame services (Highflame Team will share the list of services that require the ingress)

  • EKS cluster with at least 6 worker nodes (Best Practice: 3 zones for the VPC and use 6 nodes, with 2 nodes in each Availability Zone, to ensure high availability)

  • EKS worker nodes should have the following IAM permissions

    • arn:aws:iam::aws:policy/CloudWatchFullAccess

    • arn:aws:iam::aws:policy/CloudWatchLogsFullAccess

    • arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy

  • EKS addons to be installed

    • coredns

    • kube-proxy

    • vpc-cni

    • aws-ebs-csi-driver

    • amazon-cloudwatch-observability

  • EKS can be configured with cluster-autoscaler for managing the worker node group scaling

  • EKS should be configured with metrics-server for managing the Highflame service HPA

  • Aurora Postgres cluster from RDS

  • Redis cluster from Elasticache

  • ALB ingress controller for EKS and SSL certificates in the ACM

  • Helm v3

  • Kubectl utility

  • All the cloud resources (managed services such as Postgres, Redis etc) should be in the same VPC, or those should be accessible from the Kubernetes Cluster

Cloud Resources and Sizing

Highflame components
Cloud Resources
Size

Highflame services

Deploying the services into your EKS cluster with help of the helm charts

  • CPU nodes: Setup atleast 3 nodes across different zones and the worker node type can be c6a.2xlarge with ami type AL2023_x86_64_STANDARD

  • GPU nodes: Setup atleast 4 nodes across different zones and the worker node type can be g4dn.xlarge with ami type AL2023_x86_64_NVIDIA

Trascational Database

Aurora database compatible with postgres

The Aurora server can be single node or cluster and the node type can be db.r6g.large

Analytical Database

Clickhouse database server

Deploying into the EKS

Cache

ElastiCache for Redis OSS

Redis cluster of min 2 nodes with node type cache.m5.large

Object Store

S3 bucket

Highflame services required to store files and data in object store, such as Store the clickhouse db backup in the S3 for DR as clickhouse is deploying into the EKS cluster

Logging

Cloudwatch

The EKS service logs can be pushed to the Cloudwatch with help of fluent-bit

Authentication

Clerk

External - Managed by Highflame

Highflame AWS IAM Role

Prerequisites

Ensure that the following tools and resources are installed and available:

  • Access to the EKS cluster setup above

  • AWS CLI

  • eksctl

IAM Role

  1. Setting up the environment vars

  1. Get the AWS Account ID

  1. Fetch the EKS cluster's OIDC issuer

  1. Create an IAM OIDC provider if it does not exist

  1. Create a Trust Relationship

  1. Get the ARN of the IAM role

Resource Access - Amazon S3

There will be a few S3 bucket requirements for HighFlame, and those were mentioned in the highflame service variables list.

For each S3 bucket, this policy needs to be added to the IAM role created above

Logging Setup

Fluent Bit is deployed as a DaemonSet in the EKS cluster to collect logs from each node. It is configured to:

  • Tail logs from /var/log/containers/*.log for each microservice deployed in the EKS

  • Parse Kubernetes logs using the Kubernetes filter and create an individual log group with the highflame service name

  • Forward logs to Amazon CloudWatch Logs under the respective log stream name, the name matches the highflame service name

IAM Permissions for Fluent Bit (via IRSA) are configured to allow writing to CloudWatch Logs.

A production-ready guide to deploying Fluent Bit as a DaemonSet on an Amazon EKS cluster using Helm 3, with logs shipped to Amazon CloudWatch Logs

Overview

Fluent Bit is a lightweight log processor and forwarder built for containerized environments. On EKS, we deploy it as a DaemonSet, so a single pod runs on every node and tails:

  • /var/log/containers/*.log — all container stdout/stderr

  • /var/log/messages — node systemd / kubelet logs (optional)

  • /var/log/kube-apiserver-audit.log — audit logs (optional)

Logs are enriched with Kubernetes metadata (pod, namespace, labels) and shipped to a configured output — CloudWatch Logs by default.

IAM Setup (IRSA)

Fluent Bit needs permission to write to CloudWatch Logs. We grant this via IAM Roles for Service Accounts (IRSA) — no static keys. Either you can use the EKS worker nodes permission (mentioned in the Prerequisites or create a custom IAM policy and role, then pass it to the fluent-bit helm deployment)

Add the Helm Repository

Install Fluent Bit

A complete, annotated values.yaml for shipping EKS logs to CloudWatch:

Change the following according to your setup in the Helm values file

Deploy the fluent bit

References

Analytical Database setup - Clickhouse on EKS

This document is the long-form runbook for installing ClickHouse on an EKS cluster using the Altinity ClickHouse Operator, and an S3-backed clickhouse-backup sidecar.

What gets deployed

The full stack lives entirely inside a dedicated clickhouse namespace and consists of five logical components:

Component
Kind
Source
Notes

Altinity operator

Helm release ch-operator

Upstream chart

Watches ClickHouseInstallation (CHI) and ClickHouseKeeperInstallation (CHK) CRDs

Service account, ConfigMap, Secret

k8s resources

highflame-clickhouse-deps.yml

IRSA-annotated clickhouse-sa, clickhouse-cm, and clickhouse-secrets

ClickHouse Keeper

ClickHouseKeeperInstallation/ch

highflame-clickhouse-values.yml

1 replica, 20Gi PVC. Replaces ZooKeeper

ClickHouse cluster

ClickHouseInstallation/ch

highflame-clickhouse-values.yml

1 shard × 1 replica, 4 CPU / 12 Gi RAM, 512 Gi PVC, clickhouse-backup sidecar

Backup config

k8s resources

highflame-clickhouse-backup-config.yml

Backup config for S3 integration

CronJob + Job

k8s resources

highflame-clickhouse-addons-values.yml

12-hourly remote backups, 60-backup retention; setup Job applies 3-day TTL on system.*_log tables

Pinned versions (verify before installing):

  • Operator chart: 0.25.5

  • clickhouse/clickhouse-server: 25.10.2

  • clickhouse/clickhouse-keeper: 25.10.2

  • altinity/clickhouse-backup: 2.6.39

After installation, the in-cluster service endpoints are:

  • HTTP: clickhouse-ch.clickhouse.svc.cluster.local:8123

  • Native TCP: clickhouse-ch.clickhouse.svc.cluster.local:9000

  • Keeper: keeper-ch.clickhouse.svc.cluster.local:2181

These match the CLICKHOUSE_HOST ConfigMap value and the zookeeper.nodes block in the CHI spec

Prerequisites

Before you start, you need:

  1. An EKS cluster with kubectl context pointing at it (kubectl config current-context).

  2. A storage class that supports ReadWriteOnce PVCs — gp3 is recommended. Both the Keeper and the ClickHouse server use the cluster default unless you uncomment storageClassName in the CHI/CHK templates.

  3. An S3 bucket for remote backups, in the same AWS account as the cluster. Versioning + lifecycle rules are recommended but not required.

  4. An IAM role for the backup Service Account (IRSA) with permission to s3:GetObject, s3:PutObject, s3:DeleteObject, s3:ListBucket on that bucket. The role's trust policy must allow the OIDC provider of the cluster to assume it for system:serviceaccount:clickhouse:clickhouse-sa.

  5. helm ≥ 3.10

Config files

highflame-clickhouse-deps.yml

Defines:

  • ServiceAccount/clickhouse-sa — annotation eks.amazonaws.com/role-arn must be set to the IRSA role ARN created in the prerequisites.

  • ConfigMap/clickhouse-cmCLICKHOUSE_HOST, BACKUP_KEEP=60, CREATE_DB_LIST (comma-separated DBs to create on first boot), BACKUP_DB_LIST=highflame (comma-separated DBs to back up).

  • Secret/clickhouse-secrets — admin / readonly / backup usernames + passwords.

You must edit:

Field
Required value

eks.amazonaws.com/role-arn

IRSA role ARN

CH_ADMIN_PASSWORD

strong password for admin user highflame_admin

CH_READONLY_PASSWORD

strong password for readonly user highflame_readonly

CH_BACKUP_PASSWORD

strong password for backup user highflame_backup

highflame-clickhouse-values.yml

Defines the ClickHouseKeeperInstallation/ch and ClickHouseInstallation/ch custom resources.

Other useful knobs in this file (edit if your environment differs):

  • templates.podTemplates[clickhouse].spec.containers[clickhouse].resources — default request and limit are both cpu: 4, memory: 12Gi.

  • templates.volumeClaimTemplates[clickhouse-data].resources.requests.storage — default 512Gi.

  • templates.podTemplates[clickhouse].spec.nodeSelector — uncomment to pin to a specific nodegroup.

highflame-clickhouse-backup-config.yml

Renders into Secret/clickhouse-backup-config (mounted into the sidecar at /opt/backup-config.yml). Update:

  • S3_BUCKET — bucket name.

  • S3_REGION — AWS region (drives both region and the endpoint URL).

  • clickhouse.username / clickhouse.password to match CH_BACKUP_USERNAME / CH_BACKUP_PASSWORD from the previous step

  • The default path: highflame-clickhouse is a key prefix inside the bucket — change it per environment if you share a bucket between environments.

highflame-clickhouse-addons-values.yml

Defines:

  • CronJob/clickhouse-backup — runs every 12h (0 */12 * * *), iterates BACKUP_DB_LIST from the ConfigMap, calls clickhouse-backup create_remote per DB, and prunes old remote backups beyond BACKUP_KEEP.

  • Job/clickhouse-setup — one-shot job that waits for ClickHouse to answer /ping, creates databases listed in CREATE_DB_LIST, and applies MODIFY TTL event_date + INTERVAL 3 DAY to every system.*_log table.

Install — step by step

Run from the repo root unless noted otherwise.

Namespace

Operator

Verify the operator pod is running, and the CRDs are installed:

You should see

  • clickhouseinstallations.clickhouse.altinity.com

  • clickhouseinstallationtemplates.clickhouse.altinity.com

  • clickhousekeeperinstallations.clickhouse-keeper.altinity.com

Dependencies (SA + ConfigMap + Secret)

Keeper + ClickHouse cluster

Verify the deployment:

Backup secret

The setup Job runs once and exits Completed. The CronJob fires every 12h

Clickhouse S3 backup management (From the backup containers)

List down the remote backup

Restore from remote backup (For DR)

Highflame service deployment

Follow this documentation to deploy Highflame services to your Kubernetes cluster using Helm charts.

Whether you're standing up a fresh environment or upgrading an existing one, this guide has you covered end to end.

Highflame Services

Last updated