Is the AWS IoT Platform the Right Backend for Your Connected Product? Benefits & Examples
Last updated:14 October 2026
AWS ended support for AWS IoT Greengrass V1 on 7 October 2026. Two other AWS IoT services, AWS IoT Analytics and AWS IoT Events, have already shut down. Many guides to the AWS IoT platform still list all three as current, so a team scoping a connected product can easily plan around services that no longer exist.
The platform itself is in good shape, and the market it serves is growing. Statista estimates that 19.8 billion IoT connections existed worldwide in 2025 and puts the figure above 40.6 billion by 2034. Most of those devices need somewhere to connect, authenticate, and send data, and AWS IoT is one of the default places to do it.
This article is for CTOs and product leads who are choosing or already running an AWS IoT backend. As a company with extensive IoT software development expertise we cover which services are current, how a typical architecture fits together, and what AWS IoT Core costs at fleet scale. We also discuss when to run your own MQTT broker instead and what to do about Greengrass V1 now that its support has ended.
Key Takeaways
- AWS IoT Core is infrastructure for connecting and securing devices, not a finished product. Dashboards, user management, and alerting are yours to build.
- Three AWS IoT services that older guides still list are gone: IoT Analytics, IoT Events, and Greengrass V1.
- IoT Core bills by connection minutes, metered messages, and rules. For 10,000 devices sending one message a minute, messaging is the bill that matters.
- Start on IoT Core unless you have a specific reason not to, such as very high message rates at tiny payloads or a multi-cloud requirement.
- Greengrass V1 and V2 are not backward compatible. Treat the move as a re-platforming and plan the over-the-air rollout first.
What Is the AWS IoT Platform?
AWS IoT is a set of managed services for the Internet of Things (IoT): connecting, securing, and managing devices, with AWS IoT Core as the entry point. Everything else, from fleet operations to edge computing, builds on the connection IoT Core gives each device.
AWS IoT Core
AWS IoT Core is the managed cloud service that lets IoT devices connect to AWS and talk to each other and to your applications. It has five parts you will meet in almost every design:
-
Device Gateway. The connection layer. Devices connect over MQTT (Message Queuing Telemetry Transport, a lightweight publish/subscribe protocol), MQTT over WebSocket or HTTPS.
-
Message broker. Routes messages between devices and applications by topic.
-
Registry. The catalog of every device ("thing") with its attributes.
-
Device Shadow. A JSON document in the cloud that stores a device's last reported state and the state you want it to reach. Applications can read and write it even when the device is offline. It holds state and nothing more.
-
Rules Engine. SQL-style rules that filter, transform, and route incoming messages to other AWS services such as AWS Lambda, DynamoDB, S3, or Kinesis. It routes data; it does not restrict how data is used.
Fleet operations: AWS IoT Device Management and Device Defender
Once devices are connected, you have to operate them. AWS IoT Device Management covers onboarding, fleet indexing and search, jobs for remote operations such as over-the-air (OTA) firmware updates, and secure tunneling, which gives an engineer remote access to a device behind a firewall. For heterogeneous fleets, where hardware versions and firmware vary, this layer is where the registry, jobs and grouping earn their keep.
AWS IoT Device Defender handles security. It audits device configuration and policies against best practices and watches device behavior for anomalies. If your connected devices carry customer data or control physical assets, plan for it early rather than after the first incident.
At the edge: AWS IoT Greengrass V2
AWS IoT Greengrass extends AWS to the device. It runs local compute, messaging, and data processing on the device and syncs with the cloud when a connection is available, which helps when connected devices spend time offline. Greengrass V2 is the current version. The V1 to V2 migration has its own section below.
Which AWS IoT Services Are Still Current in 2026?
Most of the platform is current, but three services that older guides still list have closed. Check the status of any AWS service against the AWS documentation before you design around it.
Services you can build on today
AWS IoT Core, AWS IoT Device Management, AWS IoT Device Defender and AWS IoT Greengrass V2 are all in active use. They are the foundation of the architecture described in the next section.
Closed services
If you relied on IoT Analytics for time-series storage and queries, or IoT Events for detecting state changes, you need replacements built from other AWS services. A common pattern is to stream IoT data through the Rules Engine into Kinesis or storage in S3 and run the detection logic, such as a predictive maintenance alert, in AWS Lambda.
Specialised services
AWS IoT SiteWise collects and organizes data from industrial equipment, AWS IoT TwinMaker builds digital twins, AWS IoT FleetWise gathers vehicle data, and AWS IoT ExpressLink provides connectivity software on partner hardware modules. Check each one's current status on the AWS site before you plan around it.
How Does a Typical AWS IoT Architecture Work?
Data collection starts at the device. It moves to AWS IoT Core, the Rules Engine routes it to other AWS services, and your application reads it from there. A simplified version:
For a connected product with a companion app, the phone often sits in the middle. The device talks to the phone over Bluetooth Low Energy (BLE), and the phone relays commands and telemetry to AWS IoT Core. That keeps the device simple and the connection secure.
Device identity and security
Authentication happens when a device opens a TLS connection to AWS IoT Core: it presents an X.509 certificate (a standard digital certificate) issued to that device. IoT policies attached to the certificate then control exactly which topics the device can publish to and subscribe to. Get this model right at the start, because retrofitting identity across a fleet that is already shipped is slow and expensive.
Shadow or direct messaging?
Device Shadow earns its place when devices go offline and need to sync state later, for example, a lock that must pick up a command it missed. When a device sends telemetry, and nobody needs to set its state remotely, plain MQTT topics are simpler and cheaper, because every shadow update is a billable operation.
What AWS IoT Core does not give you?
AWS IoT Core has no end-user dashboard, no tenant model for separating customers, no user and role management, no alerting interface, and no companion mobile app. This is the application layer for your IoT applications, and it is where most of the engineering effort in an IoT project sits. Budget for it separately from the AWS bill.
Is AWS IoT Core an MQTT Broker, and Is It Free?
Yes, AWS IoT Core includes a managed MQTT message broker, and it has a 12-month free tier, after which you pay as you go.
What the broker supports
Devices publish messages to topics and subscribe to topics to receive messages, and the broker handles delivery between them and your applications. Beyond MQTT, IoT Core accepts MQTT over WebSocket and HTTPS. Because it is also the identity, registry, and rules layer, it does more than a standalone MQTT broker does.
What the free tier covers
For 12 months, AWS IoT Core includes 2,250,000 connection minutes, 500,000 messages, 225,000 registry and Device Shadow operations, and 250,000 rules and 250,000 actions, counted monthly. Credits do not roll over, and the tier does not apply in AWS GovCloud (US). It covers a prototype comfortably and a production fleet briefly.
How Much Does AWS IoT Core Cost at Fleet Scale?
You pay for connection minutes, metered messages, registry and shadow operations, and rules and actions, with no minimum fee. For most fleets, the message meter dominates the bill.
The four meters
All figures are AWS list prices for US East (N. Virginia). Other regions differ.
-
Connectivity: $0.08 per million minutes of connection, metered in one-minute increments.
-
Messaging: $1 per million messages for the first billion, metered in 5 KB increments. A 6 KB message counts as two.
-
Registry and Device Shadow operations: billed per million operations, metered in 1 KB increments.
-
Rules Engine: billed per million rules triggered and per million actions applied, with messages processed in 5 KB increments.
A worked example
Take 10,000 devices, each connected around the clock and sending one message of 5 KB or less every minute, over a 30-day month:
-
Connection time: 10,000 devices × 43,200 minutes = 432 million minutes, or about $34.56.
-
Messaging: 10,000 devices × 43,200 messages = 432 million messages, or about $432.
That is roughly $467 a month before rules, shadow operations, data transfer, and the other AWS services behind the Rules Engine. Rerun the numbers with your own device count and payload size. If the same messages were 6 KB each, the messaging line would double to about $864.
What makes the bill climb
Three things push IoT Core bills up: chatty devices that send many small messages, payloads just over a 5 KB boundary that meter as two messages, and rules and actions that fire on every message. Public engineering discussions of IoT Core bills at fleets of hundreds of thousands of devices describe this pattern again and again.
The usual fixes are batching readings on the device or at the edge, sending fewer and larger messages, and talking to AWS about private pricing at volume.
Should You Build on IoT Core or Run Your Own MQTT Broker?
Start on AWS IoT Core unless you have a specific reason not to, and know in advance what that reason would look like. The decision rests on your team, your message volume, and where your infrastructure has to run.
When AWS IoT Core wins
IoT Core is the better choice when your platform team is small, time to market matters, AWS is already your cloud, and you would otherwise build device identity and fleet provisioning from scratch. You pay per use, and AWS runs the broker, scales it, and patches it. Check the service quotas against your expected load before you commit.
When a custom broker wins
A broker you run yourself starts to make sense at very high message rates with tiny payloads, when you need a multi-cloud or on-premises deployment, or when your protocol needs go beyond what IoT Core offers. Count the ongoing cost. Someone has to be on call for the broker, upgrade it, scale it and patch it, and that cost does not appear on an invoice. The same trade-off shows up one level down in the stack.
The hybrid option
Some teams keep AWS IoT Core for device identity, provisioning and device management, and route high-volume telemetry through a separate path. It can cut the message bill, but you then run and secure two systems. Evaluate it with a real cost model, not on instinct.
If you are weighing AWS IoT Core alternatives, put the engineering hours of running a broker beside the invoice before you compare totals.
What Should You Do Now That Greengrass V1 Support Has Ended?
Greengrass V1 and V2 are not backward compatible, so this is a re-platforming rather than an upgrade. AWS states that the V2 cloud service and Core software "aren't backward compatible" with V1.
What changed on the date
AWS stated that after 7 October 2026, you can no longer access AWS IoT Greengrass V1 resources. V1 had already been in an extended life phase since 30 June 2023, which means AWS released no new features, security patches, or bug fixes after that. Any device still running V1 is now unsupported, so check what it can still reach and put its replacement software on the roadmap.
Two migration paths
AWS describes two V2 runtimes. The Greengrass nucleus path takes less effort: you can import V1 AWS Lambda functions as Lambda components with minimal code changes, and it supports V1 features such as the local shadow service, client devices, and connectors.
The nucleus lite path takes more work because Lambda functions have to be converted to generic components using the AWS IoT Device SDK V2 or the Greengrass Component SDK, and it does not support the local shadow service, client devices, or connectors. Pick the runtime that matches your devices and the features you depend on.
A four-step plan
-
List what each V1 AWS Lambda function does today.
-
Choose an execution model for each piece, such as a Lambda component, a container or a native process.
-
Redesign the data flow. V2 components talk over inter-process communication, where V1 used fixed subscriptions.
-
Test on development hardware, then roll out to thing groups in stages.
What fleets in the field need
The part teams underestimate is the rollout. Decide how you will push the new Greengrass software to devices over the air, what happens to a device that fails halfway, and how you roll back. Plan that path before the first device updates. If you want help sizing the migration, our AWS consulting services team can scope it with you.
What We Build on AWS IoT
We build the layer on top of AWS IoT: device connectivity, the companion mobile app and the cloud backend, which is what our IoT development services cover.
What we have built
Cloud-connected devices. The Etergo case study is our AWS IoT project. We built native iOS and Android apps for electric scooters that let riders lock and unlock the scooter, check the battery, send service requests, and see usage statistics. AWS IoT Core let the scooters receive commands and send telemetry, and it kept the scooters in sync with the backend. We also built a scooter simulator for testing. This is the pattern described earlier: a managed IoT Core connection with an application layer on top.
AWS serverless backends. The same AWS approach runs through the non-IoT projects mentioned earlier: the Acorn-i data pipeline, the Mobile Practice learning platform, and the Elements.cloud migration from EC2 to AWS Lambda.
How we approach AWS IoT projects
We start from the device-to-cloud message model and payload size before we choose services. We estimate the bill from the AWS price list before the architecture is fixed, because the message meter is easier to change on paper than in production. And we plan the OTA update and rollback path before the first device ships.
Why teams work with us
TechMagic has worked since 2014, holds the AWS Partner badge, and our team has AWS Solutions Architect Associate and AWS Security Specialty certifications.
a BPM app using JavaScript stack and Serverless on AWS
Final Thoughts
The AWS IoT platform is a sound base for a connected product, as long as you build on the services that still exist and know where the platform stops. Use AWS IoT Core for connection, identity and routing, budget separately for the application layer, and cost the message meter before you commit. If you still have devices on Greengrass V1, make the move to V2 the next item on the roadmap.
Three trends are likely to shape the next few years of AWS IoT work:
-
More intelligence on the device. AWS now publishes guidance for running small language models, roughly 3 to 15 billion parameters, on edge hardware through Greengrass, so devices can answer questions and act without a cloud connection. Expect more logic that sits in the cloud today to move to the edge, which makes Greengrass V2 skills more valuable.
-
Regulation reaches the device. The EU Cyber Resilience Act covers hardware and software products with a network connection that are sold in the EU. Its vulnerability reporting obligations began in September 2026, and the full requirements follow in December 2027. Device identity, secure OTA updates, and vulnerability handling stop being optional for teams selling connected products in Europe. AWS publishes a mapping of IoT Core, Device Defender, and Device Management to those requirements, but using the services does not make a product compliant by itself.
-
Faster service churn. Between July 2024 and October 2026, AWS closed IoT Analytics to new customers, did the same for IoT Events, and ended support for Greengrass V1. Keep your data in portable storage such as S3 and your business logic in your own code, so that losing one managed service costs you a re-route rather than a rewrite.
Statista expects worldwide IoT revenue to grow from around $419.8 billion in 2025 to more than $908 billion by 2034, so the backend you choose now has a lot of growth to absorb.
Tell us about your connected product, and we will help you size it
FAQs
WS IoT Core has a 12-month free tier that covers 2,250,000 connection minutes, 500,000 messages, 225,000 registry and Device Shadow operations, and 250,000 rules and actions each month. After that, or beyond those quantities, you pay as you go with no minimum fee.
It includes a managed MQTT message broker, plus device identity, a registry, Device Shadow, and the Rules Engine. That makes it more than a broker, because it also authenticates devices and routes their data to other AWS services.
For 10,000 devices that stay connected and each send one message of up to 5 KB per minute, AWS list prices in US East come to about $34.56 for connection time and $432 for messaging per month, before rules and other services. Larger messages meter in 5 KB steps, so payload size changes the total quickly.
Consider your own broker when message rates are very high and payloads tiny, when you need a multi-cloud or on-premises setup, or when you need protocols IoT Core does not offer. Include the cost of running, scaling, and securing the broker in the comparison.
AWS ended support for AWS IoT Greengrass V1 on 7 October 2026 and stated that you can no longer access V1 resources after that date. V1 had no security patches or bug fixes after it entered extended life in June 2023, so plan the migration to Greengrass V2. AWS IoT Events and AWS IoT Analytics have also been shut down.
