How to Choose an IoT Cloud Platform for Millions of Connected Devices

Most IoT pilots run beautifully on a few hundred devices. The real test comes later, once that number climbs into the millions.

An IoT cloud platform that looked solid in a demo often buckles under production load nobody planned for. Connection storms, message backlogs, and runaway costs all show up at exactly the wrong moment.

Luckily, you’re just a few minutes away from learning how to avoid all these issues. Scroll a little to find out what determines whether a platform scales gracefully or falls over.

AWS IoT Core: The Default Choice, and Why It Still Requires Real Design Work

AWS IoT Core has become the default starting point for most new IoT deployments, and for good reason. It handles device connectivity, authentication, and message routing at genuine scale out of the box.

That built-in scalability doesn’t mean scaling is automatic, though. Topic design, shadow update frequency, and rule engine complexity all still need deliberate planning from day one.

A poorly designed topic hierarchy can quietly become a bottleneck long before device count becomes the real constraint. Wildcard subscriptions across a badly organized topic tree get expensive fast at real scale.

Device shadows are a common source of hidden cost too, particularly when every device pushes frequent state updates. Each shadow update is a billable event, and that adds up quickly across millions of devices.

Rules engine logic deserves the same scrutiny as shadow design, since inefficient rules run on every single message. A rule that does unnecessary transformation work multiplies that cost across every device connected to the platform.

Testing rules against realistic message volume, not a handful of sample payloads, catches this problem before it reaches production. A rule that looks fine in a small test can become surprisingly expensive once real traffic arrives.

IoT Platform: What Handling Millions of Devices Actually Requires

An IoT platform built for real scale needs more than a managed service sitting underneath it. It needs deliberate architecture for connection management, message ingestion, and device lifecycle handling.

Connection management alone becomes a genuine engineering problem past a certain device count. A platform needs to handle mass reconnection gracefully after an outage, not just steady-state traffic.

That reconnection scenario is where many platforms first reveal their real limits. Thousands of devices reconnecting simultaneously after a network blip can look identical to a distributed denial-of-service attack.

Exponential backoff with jitter on the device side helps prevent that reconnection storm from overwhelming the platform. It’s a small firmware-level decision with outsized consequences once a deployment reaches real scale.

Rate limiting on the platform side provides a second layer of defense against exactly this scenario. Together, these two measures turn a potential outage into a manageable, gradual recovery instead.

Device lifecycle management is the other piece platforms often underinvest in early on. Provisioning, certificate rotation, firmware updates, and eventual decommissioning all need to work reliably at scale. A handful of pilot units rarely reveals these gaps in time.

💡 The right platform depends on the ecosystem your devices and applications already rely on. For instance, when choosing an internet of things platform, you also have the option of Azure IoT Hub. Your choice should be based on device scale, cloud integrations, security requirements, data processing needs, and your team’s existing expertise. The better fit is the one that minimizes integration complexity while supporting your long-term IoT roadmap.

Case Study: A Cost-Optimized IoT Cloud Platform at 200,000+ Devices

Our client, iApartments, needed an IoT cloud platform that could scale with a fast-growing multifamily portfolio without a costly re-architecture. Its early deployment had already outgrown what ad hoc device management could support.

DPL built an AWS IoT Core platform now managing more than 200,000 connected devices across residential properties nationwide. Cost efficiency and low latency both had to hold as device count climbed steadily each quarter.

The results show what disciplined IoT cloud platform architecture delivers under sustained growth. The platform now runs at sub-$1 per device monthly, with latency held under 200 milliseconds.

That architecture has absorbed 300 percent growth in connected devices without requiring a single re-architecture. You can read our comprehensive iApartments case study to learn more.

IoT Gateway: The Layer That Decides Whether Ingestion Survives a Spike

An IoT gateway sits between raw devices and the cloud platform, and its design choices ripple through everything downstream. A poorly designed gateway layer becomes the actual bottleneck long before the cloud platform itself does.

Protocol translation is usually the gateway’s first job, converting device-native protocols into something the cloud platform can ingest cleanly. That translation step needs to survive both device diversity and traffic spikes without dropping messages.

Buffering at the gateway matters more than most teams initially expect during planning. A gateway with no local buffer loses data outright the moment upstream connectivity drops, even briefly.

Local buffering with store-and-forward logic prevents that data loss during a temporary network outage. It costs a bit of gateway-side complexity, but it’s one of the cheapest reliability wins available in this architecture.

The internet of things platform market reached USD 67.47 billion in 2026, projected to hit USD 121.81 billion by 2031. Much of that growth is driven by exactly this kind of gateway and ingestion investment.

That market growth reflects a genuine shift in how seriously enterprises now treat this layer of the stack. Gateway architecture used to be an afterthought bolted on late in a project. It now gets budgeted and staffed from the very start of serious deployments.

Choosing between a cloud-managed broker and a self-hosted one is one of the earliest decisions a gateway architecture forces. Neither option is universally correct, and the right answer depends on specific operational constraints.

Team size and existing infrastructure investment both weigh heavily on this decision in practice. A team without dedicated infrastructure staff usually fares better starting with a managed option. Revisiting that choice later is far easier than reversing a premature self-hosted commitment.

Edge processing at the gateway layer is worth considering for deployments generating high-frequency sensor data. Filtering and aggregating locally cuts the volume that actually needs to reach the cloud platform.

That reduction in upstream volume translates directly into lower ingestion costs at scale. It also reduces the blast radius of a temporary network disruption considerably.

Teams often discover the value of edge filtering only after a cost overrun forces the question. Building it in from the start avoids that expensive lesson entirely.

IoT Cloud Architecture: Designing for Failure, Not Just Scale

IoT cloud architecture built only for scale, without planning for failure, tends to fail in expensive and visible ways. Redundancy and graceful degradation matter as much as raw throughput capacity.

Multi-region deployment is worth the added complexity for any platform expected to run at genuine production scale. A single-region outage shouldn’t take an entire fleet of devices offline simultaneously.

Queue-based ingestion, rather than direct synchronous writes, gives a platform room to absorb traffic spikes without dropping data. That decoupling is one of the more valuable architectural decisions available at this layer.

A recent industry survey found that 60 percent of enterprises cite a lack of internal or external expertise. It’s the top obstacle cited. Scaling is where that gap shows up most.

Security architecture deserves equal weight here, since a compromised device fleet at scale is a genuinely serious incident. A single weak credential shared across thousands of devices turns one breach into a fleet-wide event.

Rotating credentials on a defined schedule closes off a common attack path. Leaving them static for a device’s entire lifespan invites exactly this kind of long-lived compromise.

Most breach post-mortems trace back to exactly this kind of overlooked hygiene issue. It’s a cheap fix relative to the cost of the incident it prevents. Teams that automate rotation rarely think about it again once it’s set up correctly.

Certificate lifecycle automation tools handle most of this work without ongoing manual effort once configured properly. That upfront setup cost is small compared to the risk it eliminates for years afterward.

Certificate-based device authentication, rather than shared credentials, limits the damage any single compromised device can cause. That isolation matters enormously once a fleet reaches millions of connected units.

Observability across the entire pipeline, from gateway to storage, is what makes failures diagnosable instead of mysterious. A platform without end-to-end tracing turns every incident into a lengthy investigation.

IoT Data Management: What Happens After Ingestion

IoT data management picks up exactly where ingestion leaves off, and it’s where many otherwise solid platforms start to strain. Storage costs, query performance, and retention policy all compound quickly at real device scale.

Time-series databases have become the default storage choice for this kind of data, and for good reason. They’re purpose-built for the write-heavy, time-ordered pattern that sensor data naturally produces.

Retention policy needs a deliberate decision early, not a default setting left unexamined until storage costs become a problem. Raw telemetry rarely needs to stay at full resolution forever.

Downsampling older data while keeping recent data at full fidelity is a common, sensible compromise. It keeps storage costs manageable without sacrificing the detail teams actually need for recent troubleshooting.

Compliance requirements sometimes override this default, particularly in regulated industries with mandated retention periods. Those requirements should shape the retention policy from the outset, not get discovered midway through a project.

Query patterns should shape schema design from the very beginning of a project, not get bolted on afterward. A schema optimized for writes but never for the actual queries teams run creates painful bottlenecks later.

💡 Managing telemetry effectively is only part of the challenge; the data also needs to reach the systems that can act on it. IoT integration connects device data with business applications, analytics platforms, dashboards, and workflows, turning raw telemetry into actionable information. Designing these connections early helps prevent data silos and makes it easier to scale IoT operations across the organization.

Choosing a Platform That Won’t Need Replacing

An IoT cloud platform earns its keep by surviving the jump from pilot to production without a rebuild. Architecture decisions made early are the ones that determine whether that jump succeeds.

That query-first mindset extends well beyond the data layer. It shapes how a platform gets chosen and staffed in the first place. Teams that plan for scale from day one rarely regret the extra design work later.

Documenting these decisions as the platform evolves pays off considerably when a new engineer eventually inherits the system. Undocumented architecture choices become tribal knowledge that quietly walks out the door with whoever made them.

DPL’s IoT development team has the experience and expertise to help you in this regard. You can contact us via the form below. Rest assured we’ll build a platform that keeps working, saving you from costly rebuilding later.