Id expect its something that customers have asked for and theres ~0 marginal cost to provide it. I can see two aspects for customers; its simplicity & consistency with edge or on prem nodes using the same time source as your cloud infra. Theres a degree of trust and consistency for those same customers to get time from AWS instead of a random pool.ntp provider.
Disclaimer: principal at AWS but the above are my sole conjecture/thoughts. I have no involvement or inside knowledge of this service release.
So if i started with AWS, and then later decide to add infra from other cloud providers. i must somehow remind myself to use AWS ntp servers. If not be ready for surprises?
Better default NTP config for Amazon software that usually runs inside AWS but sometimes runs outside? Amazon Corretto, Amazon Linux, etc?
This helps Amazon claim that those "run best on AWS", as NTP would be in the same datacenter (I think?) otherwise it looks like they use a regional endpoint[1].
Being slightly closer to a NTP server doesn’t at all warrant saying a service runs best on AWS. Accurate time isn’t going to improve your Linux or Java performance in any way.
Accurate time is critical for ensuring Data accuracy and most apps utilize the system time. There are also a lot of Database functions that require accurate time. If you want to do DB clustering then a good reference time is required and Oracle even went so far as to make a service called "Cluster Time Synchronization Service (CTSS)" that specifically validates the system time configuration. Although why they still only support ntp and not chrony is something I would love to know.
It looks to be targeted at large organizations that have very strict ITIL based change control and they have to go through a CAB level approval process for every single change. I've worked in one of those environments before and yeah, the CAB would question the need to have two different configurations to effectively handle the same job.
The concept of ITIL is one of those "good on paper" type things but at some places they think its only a starting point and it's like death by meeting.
I don't think it's good on paper any more. Change control should happen in source control with lots of automation keyed off it. Meetings should be designed around that primary principle.
Disclaimer: principal at AWS but the above are my sole conjecture/thoughts. I have no involvement or inside knowledge of this service release.