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 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.2xlargewith ami typeAL2023_x86_64_STANDARDGPU nodes: Setup atleast 4 nodes across different zones and the worker node type can be
g4dn.xlargewith ami typeAL2023_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
Setting up the environment vars
Get the AWS Account ID
Fetch the EKS cluster's OIDC issuer
Create an IAM OIDC provider if it does not exist
Create a Trust Relationship
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/*.logfor each microservice deployed in the EKSParse 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
Fluent Bit Helm chart: https://github.com/fluent/helm-charts/tree/main/charts/fluent-bit
Fluent Bit docs: https://docs.fluentbit.io
EKS logging best practices: https://docs.aws.amazon.com/eks/latest/best-practices/logging.html
CloudWatch output plugin: https://docs.fluentbit.io/manual/pipeline/outputs/cloudwatch
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:
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.5clickhouse/clickhouse-server:25.10.2clickhouse/clickhouse-keeper:25.10.2altinity/clickhouse-backup:2.6.39
After installation, the in-cluster service endpoints are:
HTTP:
clickhouse-ch.clickhouse.svc.cluster.local:8123Native TCP:
clickhouse-ch.clickhouse.svc.cluster.local:9000Keeper:
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:
An EKS cluster with
kubectlcontext pointing at it (kubectl config current-context).A storage class that supports
ReadWriteOncePVCs —gp3is recommended. Both the Keeper and the ClickHouse server use the cluster default unless you uncommentstorageClassNamein the CHI/CHK templates.An S3 bucket for remote backups, in the same AWS account as the cluster. Versioning + lifecycle rules are recommended but not required.
An IAM role for the backup Service Account (IRSA) with permission to
s3:GetObject,s3:PutObject,s3:DeleteObject,s3:ListBucketon that bucket. The role's trust policy must allow the OIDC provider of the cluster to assume it forsystem:serviceaccount:clickhouse:clickhouse-sa.helm≥ 3.10
Config files
highflame-clickhouse-deps.yml
Defines:
ServiceAccount/clickhouse-sa— annotationeks.amazonaws.com/role-arnmust be set to the IRSA role ARN created in the prerequisites.ConfigMap/clickhouse-cm—CLICKHOUSE_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:
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 bothcpu: 4,memory: 12Gi.templates.volumeClaimTemplates[clickhouse-data].resources.requests.storage— default512Gi.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 bothregionand theendpointURL).clickhouse.username/clickhouse.passwordto matchCH_BACKUP_USERNAME/CH_BACKUP_PASSWORDfrom the previous stepThe default
path: highflame-clickhouseis 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 * * *), iteratesBACKUP_DB_LISTfrom the ConfigMap, callsclickhouse-backup create_remoteper DB, and prunes old remote backups beyondBACKUP_KEEP.Job/clickhouse-setup— one-shot job that waits for ClickHouse to answer/ping, creates databases listed inCREATE_DB_LIST, and appliesMODIFY TTL event_date + INTERVAL 3 DAYto everysystem.*_logtable.
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.comclickhouseinstallationtemplates.clickhouse.altinity.comclickhousekeeperinstallations.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 ServicesLast updated