PubSub messaging is definitely a PaaS feature more than an IaaS feature, so it's going to be less portable until we have the problem so well surrounded that we get some sort of open source abstraction to the whole problem and all of it's semantics. So, yes, there is a level of lock-in.

However! I know of a number of PaaS products that provide similar functionality, and with some effort, you can build it in AWS or Azure features, or you can build your own on top of RabbitMQ or Apache projects. The characteristics are going to be different, but it's doable. It might be like a MySQL to Postgres migration, or it might be like a MySQL to Mongo migration, but there _is_ a migration. Using a vendor product with unique advantages as a dependency is a known engineering problem with known risks. Take your dependencies carefully, but it's riskier to take no dependencies and fail to deliver a useful product.

PubSub is conceptually simple. There aren't a ton of moving parts on the consumer side or the producer side.

It'd be pretty easy to swap in different techs if all we're talking about is PubSub.