Well Architected and Amazon Connect

If you were to take the Amazon Connect documentation and PDF it, you'd end up with about 15,000 pages of material (yes I know you can do Markdown as well - I miss being able to open issues up against a GitHub PR). Within that material you'll find a lot of noise (which you could expect from that style of documentation - different from Lego, different from Ikea). At least, unlike Oracle, you'll find screenshots on occasion. You'll also find some pretty important information, like US TFN numbers are potentially more resilient than local numbers? If you've ever asked me why I'm hesitant to offer an alternative to ACGR, that might be why (https://docs.aws.amazon.com/connect/latest/adminguide/workload-layers.html#workload-layers-telephony). I'm ashamed to say it took me 5 minutes to find that, good
thing I have an okay memory, for now, at least.

 

Material within this documentation gets added and removed (as various folks at AWS have heard
me complain about - EVT? Instance to instance contact transfers?), yes there are release notes and yes there is a document history - I find they lag behind the changes being made to the platform, though.

 

So what's the point I'm making? Well, I talked exactly about this at last weeks AWS User Group Alpharetta Meetup (https://www.meetup.com/aws-user-group-alpharetta/events/316417665/?eventOrigin=group_events_list) , and shared the idea that:

1) AWS, Connect, AI/ML, your mission, technology, the world is constantly changing.
2) Singular memory alone can't remember, find and address deficiencies in architecture.
3) I've not yet run into a focused approach for managing these challenges with Connect.

 

So what did I do? I AI'ed my way through those 15,000 pages and used that memory of mine to come up with "best practices" for Connect with an eye for the evolution of it
(remember when the URL format changed?). That's become a custom Amazon Connect
Lens.

 

I didn't stop there. I built automation around the review process and the discovery, so I'm able to answer about 30% of the questions in the Lens (and that's brute forcing APIs - no AI yet) and a Claude skill to go along with it so I can ask - "Hey, is it a good idea to use the default version in a Lex bot?".

 

Now, what I like about this process is it can be evolved - documentation updates trigger an
update to the Lens and Skill. Post incident/Post implementation reviews? Incorporate those findings as well. I've built a workflow around keeping the Lens, automated review and Skill current in an evolving landscape.

 

I've also defined prescriptive guidance on how to address findings. 100 buckets without encryption or 100 IAM users, with no recent usage or password key rotation, which is more important? This is exactly the guidance customers are looking for - what is going to burn and how much is that burn going to cost.

 

Take a look at past meetups and stay tuned for future meetups (and other events) where I'll share more on my journey to help you become more Well Architect in your own Amazon Connect instance.