While 403 related problems have been posted before, I believe my findings deserve it's own ticket.
My setup
I'm operating 10+ sites with a nearly identical setup and extensions apart from the user data. The sites serve billiard leagues and all come with Akeeba Backup Pro and my league code which I wrote and maintain since more than 10 years. All sites are hosted on the same server and get updated at the same time to current versions, but I usually update extensions including Akeeba when updating the Joomla version. I use Akeeba with front-end backups since years on all my sites.
Error description
8 out of my 12 sites with identical setup and extensions do not update Akeeba from 8.0.3 to 8.0.6. Same behavior, whether first updating Joomla from 3.9.26 to 27, or first updating Akeeba. The other 4 sites would update without problem.
Analyzing table #__update_sites
Some sites have 1 entry for field name="Akeeba Backup Professional" (as it should be), some have 2, and some have 3 entries. All sites have an entry with field location="https://cdn.akeeba.com/updates/pkgakeebapro.xml", plus 0, 1, or 2 entries with field location="https://cdn.akeebabackup.com/updates/pkgakeebapro.xml". Both xml file locations serve valid update instructions and can be accessed from the sites.
I could not find a pattern for which entry will be picked if there is more than one, but I observed the following. When there is an entry with field extra_query="dlid=<my Akeeba download ID>" then the update sometimes works. Sometimes, because it only seems to work if the Joomla Updater picks that entry (not always the first, not always the last).
When adding "dlid=<my Akeeba download ID>" to the extra_query field of all "Akeeba Backup Professional" entries of a site the update always works.
Further comments
All sites have the Download ID set in Akeeba's options. All sites have plugin "Installer - Akeeba Backup Professional" enabled. All sites always updated successfully before, last to Akeeba version 8.0.3.
I guess there are some changes in the Joomla Updater which made the update break. My understanding is that the said plugin should always make sure the Download ID is transmitted, but that seems not to be the case. I'm unable to track down these errors in the code at the moment, but thought it can help others to describe what I found. If you have a lot of sites to admin and have access to the database executing a simple query could solve the problem.