> Nothing about this bed should depend on off-site servers. Nothing about the product should necessitate a subscription fee.
I'll play the Devil's Advocate here. If this product isn't controlled by a remote server, it either needs to be controlled by a local bit of hardware (i.e. with its own screen and hardware input devices) or by your phone. Considering the upper-class target market (high-priced luxury product), the "local bit of hardware" option is a bad call. If it's controlled by your phone, then it would presumably happen over Bluetooth, which is both (a) unreliable and (b) would disconnect if you don't have your phone in your bedroom, which if you're willing to spend $2k on a cover for better sleep, you've probably already tried.
The industry went in the direction of direct-to-Internet connections for home devices because, quite frankly, it's the lowest-friction approach for most home users. Everything else is a distraction from a great product experience for 99% of the market.
With all that said... bundling in hard-coded AWS IAM keys (for Kinesis Data Streams) and hard-coded SSH public keys is just bad engineering. You can't revoke an abusive customer without revoking everyone, and you can't fire any employees without updating every customer end device. Sleep Eight needed to set up IAM Roles Anywhere with a private CA where a user's initial setup gets the private CA to issue a cert for the base unit in the user's name, which is then used to get temporary credentials through AWS STS to write to Kinesis. Similar story with SSH, if it's actually genuinely needed for some reason, set up a private CA, in both cases, with certificate revocation lists. They're unlikely to sell enough beds (remember: luxury product) or fire enough employees for CRLs not to scale well on this solution.