Connexion Dynamic Scaling on AWS

This page explains how Connexion can run as an elastic AWS-hosted cluster. Instead of sizing a fixed cluster for peak load, AWS can add Connexion app servers when work increases and remove them when the cluster is idle.

The result is a more economical deployment model: keep a small baseline running, scale out during heavy processing, and scale back in when the workload is low.

Although this testing was done on AWS, the same concepts exist on other cloud platforms.

Executive Summary

Connexion on AWS integrates with:

• EC2 app servers run Connexion Linux from a prebuilt Connexion AMI.

• An Auto Scaling Group decides how many app servers should exist.

• RDS PostgreSQL stores shared Connexion configuration and message repositories.

• An AWS Network Load Balancer routes UI/management, MCP, health, and inbound channel traffic.

• Connexion rebalances tabs/channel groups across live app servers.

• CloudWatch, AMP, and Grafana provide operational visibility.

• S3 provides optional tier 2/cold storage for historical message data.

Connexion does not directly create or destroy EC2 instances. AWS owns scaling decisions. Connexion reports app-server health and scale-in readiness, then rebalances work as AWS capacity changes.

High-Level Architecture

Open

What Each AWS Service Does

Connexion Pieces

Connexion contributes the app-aware behavior that AWS does not know by itself:

• Database-backed app-server identity leasing.

• Cluster membership and heartbeat reporting.

• Channel/tab placement and rebalancing.

• Health endpoint reporting whether a node is safe to remove.

• AWS NLB route publishing for active inbound routes.

• UI visibility into app-server host state, placement, metrics, and scaling parameters.

The key distinction is that AWS scales machines, while Connexion understands workload ownership.

Dynamic Inbound Routing

Inbound devices can register the TCP, MLLP, HTTP, or HTTPS endpoints they expose. Connexion publishes only routes whose channels are Running and whose owning application servers are healthy.

In the AWS architecture, the Network Load Balancer remains the stable frontend while Connexion updates listeners, target groups, and backend targets from the active channel placement. If a channel moves to another EC2 application server during scale-out, scale-in, maintenance, or recovery, Connexion republishes the route to the new host without requiring the sending system to discover a different endpoint.

See Dynamic Inbound Routing for the end-to-end route lifecycle and the AWS NLB, Kubernetes Gateway API, Traefik, and HAProxy providers.

Horizontal Scaling: Application Servers

Connexion app-server clusters are designed to be dynamic. In AWS, the Auto Scaling Group can add or remove EC2 instances as load changes; in Kubernetes or other container platforms, the same pattern maps to pods or containers being scheduled and terminated by the platform.

Connexion treats each app server as disposable compute capacity. A new app server leases an identity from the configuration database, reports its health, and can host tabs/channel groups once it is live. When capacity changes, Connexion updates placement and rebalances work across the live app servers.

This moves the cluster model away from active/passive failover and toward multi-active horizontal scaling. Every healthy app server can run work, and redundancy comes from having multiple active nodes plus shared configuration, placement, and repository state rather than from keeping passive standby servers idle.

Horizontal Scaling: Data Layer

Connexion uses a single database for configuration storage, and this database can be a small, redundant RDS (or equivalent) instance.

A message repository database stores message data for N groups (where a group is a collection of tabs and channels). There is no technical limit on the number of message repository databases used by Connexion - each group can have a dedicated message repository if necessary. This means that message throughput can be scaled both vertically and horizontally.

Open

Why this matters:

• The configuration database can remain small and stable.

• High-throughput workloads can be split across multiple message repositories.

• Message repository performance becomes easier to reason about when it is not mixed with cluster control data.

Scale-Out: What Happens When Load Increases

Open

Open

Scaling from 1 to 8 app servers

Scale-In: What Happens When Load Drops

Open

Open

Scaling from 8 to 1 app server after load is removed

Performance

Connexion was profiled on AWS to test scaling up processing of typical HL7 messages to 50k/s. We used 240 boilerplate test channels which generate HL7 and metadata, modify that data, and store results.

There is no broad ‘best’ configuration for AWS (EC2, RDS), it really varies by load, desired throughput, and budget. This test involved trying out different EC2 instance types and cluster size along with the RDS size and count. We could likely have achieved our goal of 50k/s via scaling up fewer nodes to larger instances, however the overall goal here was to demonstrate horizontal scaling and the ability to dynamically scale up and down.

We settled on the following parameters:

• c7i.xlarge EC2 app servers.

• Minimum app servers: 1.

• Maximum app servers: 6.

• 240 test channels across 12 tabs.

• Two RDS PostgreSQL message repositories (db.m7g.8xlarge).

• A separate smaller RDS PostgreSQL configuration database (db.t4g.medium).

• AWS NLB frontend.

• CloudWatch Logs plus AMP/Grafana telemetry.

Observed results:

• Connexion scaled out successfully under load and scaled back in when channels stopped.

• The test approached roughly 50k messages/sec.

• App-server CPU/memory were not the primary limiting factor at the end of the run.

• RDS PostgreSQL write throughput, WAL/checkpoint behavior, storage throughput, and repository distribution were often the limiting factor.

The important lesson: once app servers are elastic, the next bottleneck is often the database tier. Adding more EC2 app servers helps until the message repositories saturate. For higher throughput, it can be more economical to split work across multiple appropriately sized RDS message repositories than to keep increasing one very large database instance.

Open

Rules of thumb from testing:

• If app-server CPU is high, scale EC2 app servers. Memory pressure is also important operational telemetry and can be added as a separate scaling signal if configured.

• If app-server CPU and memory are moderate but throughput is capped, inspect RDS.

• If one RDS message repository is hot, split groups/tabs across multiple repositories or tune the RDS instance/storage profile.

• Keep the configuration database separate so management stays healthy even when message repositories are under pressure.

Terraform

The attached Terraform bundle is the reusable starting point for creating a Connexion AWS dynamic-scaling environment. These files intentionally exclude generated plan files, Terraform state, generated working directories, and any filled-in variable file containing environment-specific or sensitive values.

To recreate the environment, download the linked files into one folder, copy terraform.tfvars.example to terraform.tfvars, fill in the customer/environment values, and run Terraform from that folder.

Results & Observations

Open

Scaling from 1 to 6 app servers (and back)

Open

Open

Open

Open

Open

Open

6-node cluster at 47k/s
This particular test was capped at 6 application servers. A separate run with two additional app servers only increased throughput to about 50k/s, so the extra EC2 capacity did not look cost-effective for this workload without further data-layer tuning.

‌