AWS IoT Core vs. EMQX: In-Depth Comparison of MQTT Features and Platform Limitations
EMQX Team
Table of Contents
- 1. MQTT Protocol Compliance and Advanced Features
- 2. Operational Limits and Performance Constraints
- 3. Data Integration and Stream Processing
- 4. Security, Authentication, and Extensibility
- 5. Enterprise Features and Real-World Scalability
- 6. Understanding Platform Limitations and Trade-offs
- 7. Matching EMQX Deployment Models to Real Scenarios
- Looking Beyond the First Phase of IoT Growth
As IoT deployments expand, the messaging layer often becomes the defining constraint on system performance, reliability, and long-term flexibility. AWS IoT Core offers a convenient entry point for AWS-centric teams, with straightforward integrations into the broader AWS ecosystem. However, as systems grow, the platform’s protocol deviations, quota boundaries, and regional limitations can introduce friction.
EMQX approaches messaging from a different angle. It is a fully compliant, horizontally scalable MQTT platform designed for large, long-lived IoT, IIoT, and connected device workloads. Whether deployed as a managed cloud service, a dedicated VPC deployment, or self-hosted infrastructure, EMQX focuses on predictable performance and architectural freedom.
This comparison highlights the technical differences that matter most when building IoT systems intended to scale: MQTT compliance, performance constraints, extensibility, and enterprise-level capabilities.
1. MQTT Protocol Compliance and Advanced Features
A foundational distinction between the two platforms is their approach to MQTT standards. AWS IoT Core supports MQTT 3.1.1 and 5.0 but deviates from the official specification in several important areas.
MQTT Feature Comparison
| Feature | AWS IoT Core | EMQX Dedicated Flex | EMQX Enterprise |
|---|---|---|---|
| MQTT Version Support | MQTT 3.1.1, 5.0 (partial implementation) | Fully compliant MQTT 3.x & 5.0 | Fully compliant MQTT 3.x & 5.0 |
| QoS 2 | Not supported | Supported | Supported |
| Complete MQTT 5 Packet Support | Missing several packets (AUTH, PUBREC, PUBREL, PUBCOMP, DUP flag) | Full support | Full support |
| MQTT over QUIC | No | No | Yes |
| Protocol Variety | MQTT, MQTT over WSS, HTTPS publish, LoRaWAN | MQTT, CoAP, STOMP, LwM2M, HTTP | MQTT, QUIC, CoAP, STOMP, LwM2M, HTTP |
AWS’s partial MQTT implementation often surprises teams when behavior differs from standard expectations, particularly for reliability and acknowledgement flows. EMQX maintains strict compliance, which is crucial for predictable behavior across millions of devices, diverse client libraries, and multi-vendor hardware environments.
EMQX also expands shared subscription handling with multiple dispatch strategies such as round robin, sticky hashing, and local node routing. These strategies help backend microservices maintain cache locality and consistent load distribution.
2. Operational Limits and Performance Constraints
AWS IoT Core enforces a variety of quotas that restrict scale and throughput. While some can be increased through support requests, they still form an upper bound that matters for large deployments.
Key Operational Limits
| Feature | AWS IoT Core | EMQX Dedicated Flex | EMQX Enterprise |
|---|---|---|---|
| Max Concurrent Connections | Up to 500,000 per account per region | 10,000 default, higher with custom plans | 100M+ (resource dependent) |
| Max Message Payload | 128 KB | 1 MB (adjustable up to 10 MB) | 256 MB |
| Publish Throughput | 100 publish requests per second per connection | 1,500 messages per second per client (default) | Unlimited (resource dependent) |
| Retained Message Limits | 500,000 per account | 500,000 | Unlimited |
| Client ID Length | 128 characters | 1,024 | Up to 65,535 |
These boundaries affect system design early on. For example, teams often discover they need multiple AWS accounts to scale beyond 500,000 devices in a region, which complicates routing and operational workflows. Large payload data, compressed telemetry, or aggregated messages also struggle under AWS’s 128 KB limit.
EMQX is designed for linear horizontal scale. Enterprise clusters routinely handle millions of connections and very high publish and subscribe throughput without requiring account sharding or regional fragmentation.
3. Data Integration and Stream Processing
Data routing is one of the most important aspects of an IoT messaging layer. AWS IoT Core and EMQX take very different approaches to this part of the architecture.
Integration Model Comparison
| Feature | AWS IoT Core | EMQX |
|---|---|---|
| Integration Approach | SQL-like Rules Engine to AWS services | SQL-based rules, Flow Designer, 40+ connectors |
| Ecosystem Scope | AWS ecosystem only | Broad ecosystem: Kafka, Oracle, SAP, PostgreSQL, MongoDB, Redis, and more |
| Streaming Optimization | Basic Ingest (bypasses broker routing) | Pre-processing, filtering, batching |
| Durable Queueing | Requires external services (SQS, SNS, etc.) | Built-in Message Queue (EMQX 6.0) |
The Rules Engine in AWS IoT Core is powerful for AWS-centric environments, but far less flexible when data needs to land in external systems. EMQX provides direct connectors to many enterprise platforms and allows data transformation before it leaves the broker.
A major architectural advantage of EMQX is the Message Queue feature introduced in version 6.0. It adds durable queue semantics directly into MQTT pipelines, reducing the need for separate queueing systems.
4. Security, Authentication, and Extensibility
The two platforms also differ significantly in how they handle authentication, authorization, and custom logic.
Security and Extensibility Overview
| Feature | AWS IoT Core | EMQX |
|---|---|---|
| Authentication Methods | X.509, IAM Roles, Cognito | X.509, Username/Password, JWT, PSK, Kerberos, SCRAM |
| Custom Authentication | Lambda Authorizers | External Auth (LDAP, SQL, NoSQL, HTTP) |
| Extensibility Model | Lambda + Rules Engine | Erlang plugins, gRPC-based hooks (ExHooks) |
| Observability | CloudWatch | Built-in Dashboard, Prometheus, Datadog, OpenTelemetry |
AWS IoT Core requires Lambda for most forms of custom logic, which adds cost and latency. EMQX allows authentication and extension logic to run natively inside the broker, improving performance and reducing moving parts.
For observability, EMQX supports industry-standard monitoring tools and exposes detailed metrics, logs, and traces suitable for highly scaled systems.
5. Enterprise Features and Real-World Scalability
Enterprise IoT deployments often require global scale, multi-tenancy, or hybrid cloud operation. AWS IoT Core and EMQX diverge sharply in how they handle these needs.
Enterprise Capability Comparison
| Capability | AWS IoT Core | EMQX Enterprise |
|---|---|---|
| Multi-Tenancy | Domain configurations or multiple AWS accounts | Namespace-based logical tenancy within a single cluster |
| GEO Scale | Region-bound deployments | Cluster Linking enables multi-region and multi-cloud communication |
| On-Premise / Hybrid | Not available | Fully supported |
| Custom Protocol Gateways | Limited | Built-in gateways (OCPP, JT/T 808, GBT32960) |
EMQX’s Cluster Linking feature is especially valuable for multi-region deployments because it allows geographically distributed clusters to operate as a unified system while remaining resilient to network interruptions.
6. Understanding Platform Limitations and Trade-offs
Every platform has trade-offs, and choosing between AWS IoT Core and EMQX depends on technical priorities.
AWS IoT Core Limitations to Consider
- No QoS 2 support
- 128 KB message size limit
- Up to 500,000 device connections per region per account
- Throughput is capped per connection
- No guarantee of message ordering
- Deep dependency on AWS ecosystem services
- Custom logic requires Lambda
EMQX Cloud and Enterprise Considerations
- Fewer built-in device management features than AWS IoT Core
- Relies on standard MQTT client SDKs rather than a proprietary SDK
- EMQX Serverless has connection and TPS caps by design
- Self-hosted Enterprise requires operational ownership
A balanced understanding of these factors helps teams choose the right messaging layer for the long term.
7. Matching EMQX Deployment Models to Real Scenarios
EMQX offers multiple deployment models to meet different architectural, compliance, and operational requirements.
EMQX Deployment Options
| Offering | Deployment Model | Key Advantages | Best Fit |
|---|---|---|---|
| EMQX Enterprise | Self-hosted (on-prem or customer cloud) | Unlimited scale, full customization, multi-protocol support | Industrial IoT, Telecom, and regulated industries |
| EMQX Dedicated Flex | Fully managed, isolated VPC | Predictable performance, SLA-backed, enterprise support | Mission-critical production workloads |
| EMQX Serverless | Fully managed, multi-tenant | Pay-as-you-go, quick startup | POCs, development workloads, small device fleets |
| BYOC | Customer cloud with EMQ operations | Full control and enterprise features | Data sovereignty and multi-cloud strategies |
Looking Beyond the First Phase of IoT Growth
AWS IoT Core is a sensible starting point for teams building cloud-connected device systems inside the AWS ecosystem. Its managed nature and tight integration with AWS services make early development accessible and convenient.
However, the platform’s protocol deviations, payload limits, throughput caps, and regional boundaries can become significant architectural challenges as deployments grow. EMQX is designed to address these long-term needs through full MQTT standard compliance, predictable performance at scale, extensive integration options, and deployment flexibility across cloud and on-prem environments.
If you are also evaluating AWS IoT Core from a cost perspective, we recently published a companion analysis that explains why messaging expenses increase sharply at scale and how EMQX reduces those costs by up to 80 percent. For a broader look at why many teams choose to move away from AWS IoT Core, you can also explore our overview of the most common technical and business drivers behind switching to EMQX.