I can’t speak to Red Hat nor Amazon Linux.
Normally our kernels are released on a three-week cadence. There’s no perfect time scale for new updates – too slow, and we may leave our users exposed to vulnerabilities for long enough for exploit authors to prepare tools. Too fast, and users will grow fatigued.
Sometimes, an issue feels important enough to issue updates out of cycle, or there may be regressions in fixes that should be addressed out of cycle.
So, we’ve tried to balance update timeliness with convenience as well as our own efforts in preparing and testing updates. No one frequency is going to serve everyone.
We offer a Livepatch service that can reduce the need for immediate reboots: https://ubuntu.com/security/livepatch Not all security issues can be mitigated with livepatches, but many are, and using the Livepatch service may reduce your need for rebooting.
Depending upon what services and users your machines have, you may also choose to skip reboots for a while. My laptop is a single-user machine where I keep up on updates daily, use extensive AppArmor profiles, and doesn’t interact much with untrusted content. On this machine I reboot perhaps every two months. The server in the basement that never interacts with untrusted content at all reboots perhaps every six months.
Determining if it’s safe to skip rebooting into a new kernel may be difficult; when in doubt, it’s probably better to reboot into the new kernel. (Or new OpenSSL libraries, glibc libraries, etc.) But you may not necessarily need to reboot for every one we publish.
You can also try to design your services so that you can perform rolling reboots and still be able to serve your users: taking machines out of load balancers during quiet times, rebooting, putting them back, adjusting DNS entries to move from one load balancer to another, etc. Not all services can do this but many can.