Environment setup

To provision the AWS infrastructure for OpenLM Platform on Amazon EKS, use Terraform or create the resources manually. Each infrastructure service runs either as a managed AWS service or in the cluster.

For detailed sizing and service specifications, see Requirements.

Infrastructure components

OpenLM Platform needs only an endpoint for each infrastructure service, so you can replace a managed service with the chart from the deployment package. Use Amazon MSK for Kafka, or In-cluster Kafka when you can't.

The AWS deployment uses the following services:

Component	AWS service	Purpose
Kubernetes	Amazon EKS	Container orchestration
SQL database	Amazon RDS for SQL Server	Identity, operational, and reporting data
Message broker	Amazon MSK (recommended), or Kafka in the cluster	Event streaming (Kafka)
Cache	Amazon ElastiCache for Valkey	Caching and session storage
MongoDB	MongoDB Atlas or self-hosted	Document storage (AWS DocumentDB is not supported)

Terraform reference

A Terraform configuration is available as a reference for provisioning the complete AWS infrastructure. It comes with the deployment package. Contact OpenLM to get it. It provisions:

• Networking: VPC with public and private subnets across 3 availability zones, NAT gateway, S3 gateway endpoint
• EKS cluster: Managed node groups with node labels, OIDC provider, EBS CSI driver, control plane logging
• RDS SQL Server: Multi-AZ, gp3 storage, enhanced monitoring, Performance Insights
• MSK (Kafka): 3 brokers with SASL/SCRAM authentication, TLS encryption, CloudWatch logging
• ElastiCache (Redis): 3-node replication group with encryption and authentication
• Security: KMS customer-managed keys for secrets, logs, and data at rest

The configuration creates MSK in every case. If you run Kafka in the cluster, remove the MSK resources before you apply it.

The node groups it creates carry the labels openlm.com/role=main-workload and openlm.com/role=reporting-workload, which the node affinity in the OpenLM Platform chart doesn't match. Change them to openlm.com/role=main and openlm.com/role=spark before you apply the configuration, or turn node affinity off as described in Node affinity.

Note

The Terraform configuration is a reference starting point. Review and adapt it to your organization's security policies, naming conventions, and network topology before applying.

Key Terraform variables

The following table lists the key Terraform variables:

Variable	Default	Description
eks_version	1.34	Kubernetes version
eks_public_access_cidrs	[]	Allowed CIDRs for EKS API public access
db_engine	sqlserver-se	RDS engine (SQL Server Standard)
db_instance_class	db.m6i.xlarge	RDS instance size
main_instance_type	m6i.xlarge	Main workload node instance type
reporting_instance_type	m6i.xlarge	Reporting node instance type
infra_instance_type	m6i.large	Infrastructure node instance type
msk_kafka_version	3.8.x	Kafka version
msk_instance_type	kafka.m5.large	MSK broker instance type
cache_node_type	cache.m6g.large	ElastiCache node type

Apply the Terraform configuration

Run these commands:

# Initialize Terraform
terraform init

# Review the plan
terraform plan -var-file="production.tfvars"

# Apply
terraform apply -var-file="production.tfvars"

After applying, Terraform outputs the connection details needed for the Helm chart configuration:

• EKS cluster endpoint
• RDS SQL Server endpoint
• MSK bootstrap brokers (SASL/SCRAM)
• Redis primary and reader endpoints

A managed-connections.txt file is generated with all connection strings.

Manual provisioning

If you prefer not to use Terraform, provision the following resources manually. For detailed specifications, see Infrastructure requirements.

Network

Provision the following network resources:

• VPC with at least a /22 CIDR block
• 3 private subnets (one per availability zone) for workloads
• 3 public subnets for load balancers
• NAT gateway for outbound internet access from private subnets

EKS cluster

Configure the EKS cluster with the following settings:

• Activate public and private API endpoint access
• Restrict public access to your organization's CIDRs
• Activate control plane logging (API, audit, authenticator, controller manager, scheduler)
• Install the EBS CSI driver for persistent volumes

Node groups

Create three managed node groups with the following labels:

Node group	Instance type	Count	Label
Infrastructure	m6i.large	1	openlm.com/role=infrastructure-workload
Main workload	m6i.xlarge	3	openlm.com/role=main
Reporting	m6i.xlarge	3	openlm.com/role=spark

Managed services

Provision RDS and ElastiCache as described in Infrastructure requirements, and MSK only if you don't run Kafka in the cluster. Confirm that the security groups allow traffic from the EKS cluster security group.

In-cluster Kafka

Use Amazon MSK for Kafka on AWS. When your organization can't, deploy the Kafka chart that OpenLM provides with the deployment package. It comes with its own values file. OpenLM Platform connects to Kafka through its in-cluster address, with no authentication on that listener, and creates its topics after the installation as on every other path. Kafka-compatible brokers such as RedPanda aren't supported.

1. Create the infrastructure namespace:

   kubectl create namespace openlm-infrastructure

2. In the values file, set controller.persistence.storageClass to your EBS gp3 storage class and controller.persistence.size to the storage you plan for. Allow the same storage as for an MSK broker, 250 GB in the sizing baseline. Kafka traffic in OpenLM Platform is light, under 1 MiB/s in OpenLM's own production environments, so plan for retention rather than throughput. To keep Kafka on the infrastructure node group, add node affinity for the openlm.com/role=infrastructure-workload label.

3. Install the chart:

   helm install kafka kafka-<version>.tgz -f values.yaml -n openlm-infrastructure

The bootstrap address for the OpenLM Platform secrets is then kafka.openlm-infrastructure.svc.cluster.local:9092. See Create the secrets.

MongoDB

AWS DocumentDB is not supported. Use one of the following alternatives:

• MongoDB Atlas: A managed service with direct VPC peering. Recommended.
• Self-hosted in Kubernetes: Deploy MongoDB into the cluster using a Helm chart.

Next steps

After you provision the infrastructure:

1. Configure kubectl to connect to the EKS cluster:

   aws eks update-kubeconfig --name openlm-eks --region eu-central-1

2. Complete the Prerequisites checklist.
3. Proceed to Platform installation.