Some things: (1) I do not like putting all my eggs in one basket for telecom. I don't care if Amazon is managing the API server for my grandma's heart monitor

Some things: (1) I do not like putting all my eggs in one basket for telecom. I don't care if Amazon is managing the API server for my grandma's heart monitor - I never trust one TSP. One TSP = one point of failure. I hope they do something to address this. (and please don't bother replying with some assumption that multiple paths disqualifies the need for redundancy through multiple TSPs) >Amazon Connect runs on Amazon Web Services proven infrastructure operating 42 Availability Zones within 16 geographic regions around the world. This makes Amazon Connect more highly available, fault tolerant and scalable than would be possible if a contact center solution was run from a single data center. Amazon Connect is only offered in US East as of right now. I wonder what that means for reliability/fault tolerance. Does the user have to initiate geographical replication? (2) I do not like relying solely on an internet service for telephony/CC. I will rely on it for most of my telephony/CC most of the time, but I see no reason why CC offerings shouldn't have some kind of offline component. I hope they do something to address this concern. (3) I see they have released the "Streams" API[1]. It's well documented, which means I can create similar API calls for an offline replacement. I'm glad they addressed this somewhat, although I wish they would consider making a useful multipurpose soft phone so I can use SIP registrations from other systems in an emergency. (4) The limit of 10 DIDs seems exceptionally low. Sure, once the call hits Amazon, it can go through its routing steps, but Amazon is not in control of where the customer gets the number. DIDs often serve an analytical function, especially when that's the only useful data (besides Caller ID) coming in from the PSTN. It would seem more reasonable to max out at 100 (yes even for a starter account). I hope they do something to address this concern. (5) Getting to use their ASR is a big deal - especially over the PSTN. When I realized I'd have to write an MRCP plugin just to reliably stream audio to the Google Speech API, I gave up on that dream. I wish Google would address the concern of PSTN to the Google Speech API... I don't care about any other call center doodad, but being able to leverage a speech processing - especially Google's or Amazon's - API is a really big deal. The fact Amazon has made this available over the PSTN with the possibility of having an API make decisions from speech is exciting. All in all, this is nice and I'm sure they have rough edges they'll polish. At the end of the day, their speech stuff is something I'll definitely be using, the other stuff does not make me feel confident it's redundant/fault-tolerant. There are just too many points of failure. [1]:https://github.com/aws/amazon-connect-streams https://github.com/aws/amazon-connect-streams