AWS recently announcedAppSync 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 ofIoT Core which exists for many years. Let's find out if this is the case...

API Gateway Websockets?
A while ago I comparedAPI 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 butonly 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 disconnectusing 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 withnews/sports/f1 andnews/sports/soccer.

AppSync Events

In AppSync Events this is called called"channel namespaces". A wildcard* is supported to receive messages from all sports usingnews/sports/* or all news events usingnews/*. 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 toreceive messages. To publish a message, you need to use anHTTP 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.

Update April 2025: AppSync Events now supportspublishing over websockets.

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 supportsmultiple 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 apre-signed url, acustom authorizer and/orcertificates 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 thatanything is possible. AnIAM policy allows you todecide exactly which client can do what on your topics.

Event Handling

AppSync Events

AppSync Events allows you to provide an optionalhandler for a channel namespace:

Event handlers are functions that run onAWS 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 isvery 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.

Update April 2025: AppSync Events now offers several integrations (called data channels)like Lambda, DynamoDB and EventBridge.

IoT Core

In IoT Core on the other hand, you can create SQL likerules to capture messages, send them to an AWS service of choice (including Lambda) usingactions 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 aboutRules.

SELECT color AS rgb FROM 'topic/subtopic' WHERE temperature > 50

These queries areextremely 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 exampleshere.

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 exampleshere.

As you can see, the pricing isvery 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 forAppSync Events andIoT Core have a few notable differences:

• AppSync Events has a maximum message size of1.2 Megabytes where IoT Core can do only128 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 tocreate 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 acustom resource with a Lambda to retrieve it, quite cumbersome. Other than that, it isvery well supported within CloudFormation.

WAF

AppSync Events

AppSync Events issupported 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 inamount of documentation compared toAppSync 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". Thisoptional 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 theAmplify 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 hardwareat 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.

Update April 2025: Now that AppSync Events supports bi-directional communication and integrations with other services like Lambda, DynamoDB and EventBridge the service got a lot more interesting. Personally I still prefer IoT Core as it is still more flexible since you do not need to define your channel namespaces upfront and the policies of IoT Core seem to be more fine grained.

AppSync Events powered by IoT Core?

Looking at the different services I feel that AppSync Events technicallycould 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?