A few issues.
The first frustration is around installation. There isn't a simple .deb or tarball to install as part of the AMI build process if you bake AMIs. Instead, you must run a script at boot. So you build yourself a systemd job, or launch it through cloud-init or whatever.
So now the agent is installed. But no one can login to it, because it's not associated with any groups to provision users. And you can't just specify groups to join in a configuration file, because that would be too easy. No, you have to call an API, which can only be done after the agent is running and has registered the instance. Sounds easy, right? But there's no reliable way to know the agent is correctly running. We ended up starting a systemd one-shot that waits for the presence of a file, which is a hack. Why not just wait for the systemd service to be running? Oh, that service doesn't exist until the install script has run, which then creates the service. So it doesn't exist to wait on at boot time. Why can't they just give a damn package to install at bake time?!
Most of the time, an instance will shutdown cleanly, and you can all the JumpCloud API again to deregister the instance as part of the shutdown process. And most of the time, that's all you do with instances. But occasionally you'll have data stores that use ephemeral storage that you'd rather reboot than replace. Now your shutdown story just got a lot more complicated.
The naive approach is just let the agent uninstall and re-install at the next boot. And that can work at lot of the time. But then there was that employee who left, and you disabled the employee's administrator account, which disabled the key used in the initial install script. So you need to keep that updated as well. Because apparently supplying a mechanism to install without being tied to one employee's credentials never occurred to JumpCloud.
Oh, and what if the JumpCloud API for installation script happens to fail at boot, as it does about 1 in 25 times because of timeouts or whatever other connectivity issues their endpoints are having? I hope you have that SSH key you specify in your launch template/configuration, so you can login and fix it. And you're back to handing that key around to everyone, which kind of defeats the point of using JumpCloud.
It's just a lot of hackery to make JumpCloud functional on AWS. The whole design of JumpCloud is really geared around legacy on-premise systems and laptops or whatever, and the product and engineering people there don't seem to understand the frustrations of trying to use their product in a cloud-native way. And they don't even document the workarounds we had to invent to make their service functional.
It's just a really bad fit on AWS, and I would strongly recommend against using it there. It's just not reliable, it's a pain to implement, and we're tired of the headaches.
It's fine for on-premise stuff though, where machines aren't ephemeral.