Apache BifroMQ Secure Multi-Tenant MQTT Broker

This is a repackaged open source software product wherein additional charges apply for cloudimg support services.

## Apache BifroMQ - Hardened Multi-Tenant MQTT Broker AMI

Deploy a distributed, high-performance MQTT broker on AWS in minutes - not hours. This AMI delivers Apache BifroMQ preinstalled and running as managed system services, with authentication enforced on every connection out of the box, so an authenticated MQTT endpoint answers the moment the instance boots.

BifroMQ implements MQTT 3.1, 3.1.1 and 5.0 and is built around native multi-tenancy: every connection is resolved to a tenant, and each tenant's topics, subscriptions and sessions are isolated from every other tenant's on the same broker.

### Why This AMI Instead of a DIY Install

• Secure by default, not by accident: A stock BifroMQ install loads a development authentication provider that accepts every connection without checking the password and grants every publish and subscribe - an open broker. This image replaces that with real per-connection credential checking and closes the related failure where a broker whose authentication service is unreachable would silently grant every action instead of denying it.
• No baked credential: A unique MQTT username and a long random password are generated on each instance's first boot and written to a root-only file. No shared or default secret ever ships in the image.
• Tuned and supervised: The Java runtime is sized for the instance rather than left to a default that would exhaust its memory, and the broker plus its authentication service are started, ordered and restarted by systemd.

### Application Stack

• Apache BifroMQ installed under /opt/bifromq, run by a dedicated unprivileged service account
• Headless OpenJDK Java runtime with JVM heaps and direct memory tuned for the instance
• MQTT over TCP on port 1883, authenticated by a loopback policy service via the bundled webhook auth plugin
• Authorization configured to fail CLOSED - pub/sub is denied, never silently granted, if the auth service is unavailable
• Two unauthenticated management ports bound to loopback and additionally enforced there by a persistent firewall rule

### AWS Integrations

• Amazon CloudWatch: Export broker metrics and JVM health data to CloudWatch for centralized monitoring and alerting across your fleet of instances.
• AWS Certificate Manager: Use ACM-issued or imported certificates to enable MQTT over TLS on port 8883, simplifying certificate lifecycle management.
• Amazon VPC: Deploy within private subnets and use VPC security groups to restrict MQTT access to trusted client CIDRs, ensuring network-level tenant isolation.
• Amazon EC2 Auto Scaling: Scale broker instances horizontally behind a Network Load Balancer to handle connection surges from large device fleets.

### Security

Authentication on Every Connection: The broker validates a salted-hashed credential on every MQTT CONNECT, and denies wrong-password and anonymous connects. A per-instance username and password are generated at first boot.

Fail-Closed Authorization: The image ships with authorization set to fail closed, so a transient outage of the authentication service denies publish and subscribe rather than granting them.

Loopback-Only Management: The admin HTTP API and the plugin metrics endpoint are bound to loopback and enforced there by a persistent iptables rule; reach them over an SSH tunnel.

Network Isolation: The recommended security group opens only SSH. Open the MQTT port (1883, or 8883 for TLS once you supply a certificate) only to the trusted client CIDRs your fleet connects from, ideally within a private VPC subnet.

### Multi-Tenancy

BifroMQ derives a tenant from the authenticated principal, and tenants are strictly isolated - a publisher and subscriber must share a tenant credential to exchange messages. This lets one broker serve many isolated groups of clients without cross-tenant leakage.

### Use Cases

• Smart building and industrial IoT: Connect thousands of sensors per tenant across building management systems, with each property manager's devices isolated on a shared broker, ingesting telemetry into downstream analytics pipelines.
• Platform operators serving multiple customers: SaaS providers and managed service companies that need to offer isolated MQTT messaging to each of their end-customers from shared infrastructure, without deploying a separate broker per customer.
• Vehicle and fleet telemetry: Automotive and logistics companies streaming real-time GPS, diagnostics and event data from connected vehicles over MQTT into event-driven processing systems running on AWS.

### Evaluation Path

Launch the AMI on a t3.medium instance to validate authentication, multi-tenancy and message flow with your MQTT clients before scaling to production instance types. See the pricing tab for current software charges.