Looking at what CloudFormation can and can't do it seems like completely different teams work on a service and its CloudFormation support.
I guess Amazon use the AWS API internally?
I say alleged because who knows if that's the code that's really running. And related to this current thread even if it is the code, with this being Amazon who knows if I ever found a bug and PR-ed it that it wouldn't /dev/null for 5 years before being closed by some stale-issue-bot or something
I work at AWS. The service teams do own and write their CloudFormation providers, although if you've written a custom provider you'd see it is somewhat clunky, so it's sometimes considered more of an operational burden, and you can tell.
We dogfood both the SDK and CloudFormation internally, we just deal with its numerous gripes much the same way you would externally (although we can also contact service teams directly if needed).
Million dollar question would be if all the “feature requests” that AWS support opens when they don’t know what else to do actually go someplace or if they just get swept aside every few days. I’ve always been under the impression they receive very little or no attention. Even bugs where I have included a reproducible test case that results in an internal error, they just keep trying to close the ticket every few days until you go on vacation or e-mail burps and you miss the notice.
I work for AWS. We have an internal tracking system containing customer feature requests, and our service teams review them biweekly and they get prioritized by product management. “Working backwards from the customer” is gospel here.
That is cool to know! For several years I have been tell the support people not to bother with feature requests because I didn’t think they went anyplace, maybe I’ll let them open them going forward.