AWS recently announced AppSync Events and it looks like very useful service. However when I was reading about it, it just felt like this is "just" a layer on top of IoT Core which exists for many years. Let's find out if this is the case...
API Gateway Websockets?
A while ago I compared API Gateway Websockets with IoT Core. It might be very useful to also give it a read if you are exploring options for bi-directional communication on AWS.
Connection Management
Both services do their own connection management. There is absolutely no need to store who connected and disconnect yourself or do any garbage collection.
AppSync Events
AppSync Events is able to act on connects but only for deciding if a client is allowed to connect. It does not seem possible to have any interaction with the outside world (ie: databases, AWS services, APIs).
IoT Core
With IoT Core you are able act on connects and disconnect using Lifecycle Events and have total freedom of doing something with this data.
Messaging
Both services use a structure based on segments separated by slashes to create a hierarchy of your own choice, for example: news/gaming, news/sports or a level deeper with news/sports/f1 and news/sports/soccer.
AppSync Events
In AppSync Events this is called called "channel namespaces". A wildcard * is supported to receive messages from all sports using news/sports/* or all news events using news/*. There is a maximum of 5 segments (4 slashes).
You are required to set up all channel names and configure them with an optional function that triggers on connect and when an event is published. It does not seem to be possible to use a Lambda for this.
I was a bit surprised to find out that AppSync Events only uses the socket connection to receive messages. To publish a message, you need to use an HTTP endpoint. While this is perfect for only broadcasting from server to client, this makes it a lot less suitable for use cases where your clients often need to communicate back.
IoT Core
As IoT Core is an MQTT Broker, it uses "topics" which are similar to the channel namespaces from AppSync Events.
You don't need to manage topics. You can just subscribe and publish to any topic on the fly. The only restriction your clients have are the IAM permissions you give them. If a client does something now allowed by it's policy, it will be disconnected. There is a maximum of 8 segments (7 slashes).
IoT Core is fully bi-directional, you can subscribe to topics, receive and publish messages over the same socket connection. Again, only if you allow this by the policy given to the client.
Authentication
AppSync Events
AppSync Events supports multiple authentication types right out of the box with no or minimal development work required. A custom flow is possible with Lambda.
IoT Core
Within IoT Core you can use a pre-signed url, a custom authorizer and/or certificates to manage client access. While this is not super difficult, it does require development and isn't as easy as AppSync Events.
The upside thing is that anything is possible. An IAM policy allows you to decide exactly which client can do what on your topics.
Event Handling
AppSync Events
AppSync Events allows you to provide an optional handler for a channel namespace:
Event handlers are functions that run on AWS AppSync's JavaScript runtime and enable you to run custom business logic. You can use an event handler to process published events or process and authorize subscribe requests.
This is very limited as it does not seem to be possible to use any AWS services, connect to a database or (third party) API. The only kind of integration that it supports is where AppSync Events is called by other services to publish a message.
IoT Core
In IoT Core on the other hand, you can create SQL like rules to capture messages, send them to an AWS service of choice (including Lambda) using actions to process them. This allows you to do virtually anything with the data that is sent from both clients and/or servers and also in any language of choice as long as it is supported by Lambda. Read this article if you want to learn more about Rules.
SELECT color AS rgb FROM 'topic/subtopic' WHERE temperature > 50
These queries are extremely powerful and allow data transformation and filtering.
Pricing
Both services have a generous free tier in the first 12 months but eventually you will have to pay for something of course.
AppSync Events
- $0.08 per million connection minutes.
- $1.00 per million Event API operations. All inbound messages published, outbound messages broadcast, event handlers invoked, and WebSockets operations, like client connection, subscription requests, and ping requests, are considered operations.
Full details and examples here.
IoT Core
IoT Core has more features, I will only list the ones relevant for this comparison (on us-west-1 / eu-west-1 regions).
- $0.08 per million connection minutes.
- $1.00 per million messages (first 1 billion)
- $0.80 per million messages (4 to 5 billion)
- $0.70 per million messages (5+ billion)
- $0.15 per million rules triggered.
Full details and examples here.
As you can see, the pricing is very similar where IoT Core will be a bit cheaper since in AppSync Events as the rules engine is a lot cheaper and you will get a discount when having more than 4 billion messages (which a lot though if you ask me).
Service Quotas
The service quotas for AppSync Events and IoT Core have a few notable differences:
- AppSync Events has a maximum message size of 1.2 Megabytes where IoT Core can do only 128 Kilobytes (hard limit).
- AppSync Events has an outbound messages limit of 1.000.000 per second where IoT Core has a default (soft) limit of 20.000.
- AppSync can do 2.000 connects per second, IoT core has a default (soft) limit of 500 per second.
Overall it seems that AppSync Events is way more generous with it's limits than IoT Core which makes it more suitable for a situations where you primarily want to broadcast to your clients. I had to adjust some of the IoT Core limits for a project and this was not a problem at all but it's always a hassle to do.
Infrastructure As Code
AppSync Events
With AppSync Events you are able to create multiple AppSync Events API instanced which could very useful for separation of environments or different services.
IoT Core
Every account only has a single and default IoT Core instance at time of writing which you don't need to create manually. If you have multiple applications on the same account, you would need to separate access using topic prefixes or IAM policies.
The endpoint for it is not available in CloudFormation, you would have to use a custom resource with a Lambda to retrieve it, quite cumbersome. Other than that, it is very well supported within CloudFormation.
WAF
AppSync Events
AppSync Events is supported by the AWS WAF. As far as I know, WAF does not support websockets and therefor most likely only the publish endpoint is protected.
IoT Core
IoT Core is not supported by the AWS WAF for the simple reason that there are no account level HTTP endpoints to protect for this service.
Additional Features
AppSync Events
This service is very straightforward and doesn't offer much other functionality then previously described.
IoT Core
IoT Core has many more features which can clearly be seen when looking at the difference in amount of documentation compared to AppSync Events. I don't want to pretend I have used all those features, I just want to highlight a few of them:
MQTT
Since IoT Core is a fully managed MQTT broker, it supports the following protocols: MQTT, HTTPS, MQTT over websockets and LoRaWAN. This can be very useful if you have different types of clients. When working with hardware that used MQTT, it's very useful to create a web version that emulates the hardware using the same topics and messages but instead doing it over websockets.
Retained Messages
Retained Messages is an MQTT feature supported by IoT Core where you can publish a message which the client receives when it gets back online. As of now, I could not find the possibility of doing this with AppSync Events.
Device Registry
In IoT Core there is a concept called "Things". This optional feature allows you to keep a registry of all your things/devices. You can group them and even created "shadows" for them.
Shadows provide a reliable data store for devices, apps, and other cloud services to share data. They enable devices, apps, and other cloud services to connect and disconnect without losing a device's state.
Conclusion
My take on the AppSync Events service is that it is most likely added to the portfolio to make it easier to implement push messaging from server to client which focuses on web and app development.
In general it offers a lot less functionality than IoT Core as it focuses primarily on publishing messages to clients and not the other way around. It is however (a lot) easier to get started with and part of the Amplify suite of services. Because of this, I do think that AppSync Events could become a service that will be embraced by many developers. Personally I do see some use cases where I would prefer AppSync Events over IoT Core, especially because of the more generous default quotas.
IoT Core has way more features but has a steeper learning curve and seems more aimed at hardware at first glance. This however doesn't mean it can not be used for web and app. If you are interested in using IoT Core for web and app "the easy way", read this series of articles to get started.
AppSync Events powered by IoT Core?
Looking at the different services I feel that AppSync Events technically could very well be a service that is built on top of IoT Core. However, I'm not so sure anymore looking at the absence of bi-directional communication and the very different service quotas. Maybe an AWS employee could shine a light on this?
Top comments (0)