Group Policy - Issues with DFSR, NETLOGON/SYSVOL?

We have an issue where some computers don't seem to be picking up all of their GPO's. When looking in group policy management editor we see many many "red x", "file not found" GPOs (and which don't specify which GPO they are).

A little about our environment, we have 4 domain controllers at Server 2008 R2 functional level. 2 DCs are on-prem Server2k8R2, 2 others are off-site AWS EC2 instances running Server 2016.

Running "net share" shows both NETLOGON and SYSVOL shared at DIFFERENT paths for the 2 2K8R2 DCs vs the 2K16 DCs (I don't know if this is an issue).

Server2016 DCs show these paths: 
NETLOGON - C:\Windows\SYSVOL\sysvol\domain.local\SCRIPTS
SYSVOL - C:\Windows\SYSVOL\sysvol

Server 2008 R2 DCs show these paths:
NETLOGON - C:\Windows\SYSVOL_DFSR\sysvol\superior.local\SCRIPTS
SYSVOL - C:\Windows\SYSVOL_DFSR\sysvol

In all cases, the C:\Windows\SYSVOL\sysvol is empty except for the domain.local folder.

Running "DCDIAG" shows failure for the "SystemLog" test for all four, and warnings on DFSREvent test:

AWSDC01 & AWSDC02: 
SystemLog test-
"The Netlogon service encountered a client using RPC signing instead of RPC sealing". 
"The Netlogon service denied a vulnerable Netlogon secure channel connection from a machine account. 

DFSREvent test - "There are warning or error events within the last 24 hours after the SYSVOL has been shared. Failing SYSVOL replication problems may cause problems with group policy"
"

OnSite-DC1:
DFRSEvent test - "There are warning or error events within the last 24 hours after the SYSVOL has been shared. Failing SYSVOL replication problems may cause problems with group policy"
SystemLog test - "An error event occurred. Event ID 0xC2000001. Unexpected failure. Error code 490@01010004"

OnSite-DC2:
DFRSEvent test - "There are warning or error events within the last 24 hours after the SYSVOL has been shared. Failing SYSVOL replication problems may cause problems with group policy"
and
"This computer could not authenticate with \\AWSDC01.domain.local, a Windows domain controller for domain DOMAINNAME, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized."

Some additional things to note:

-Event viewer logs (on on-site DC1 and on-site DC2) under application and services > DFS replication show only information about replication between each other. No mention of replication between the AWS DC's. 
- Every hour the on-prem DCs show a DFS error "the dfs replication service is stopping communication with partner {other on-prem DC} for replication group Domain System Volume due to an error. Error 9036. 

AWS DC02 only shows error logs regarding DFS replication with on-prem DC02. Same error 9036 "replication service stopping due to an error". 

AWS DC01, same thing - only shows logs regarding DFS replication with on-prem DC01. Error 9036 "replication service stopped due to an error". 

any idea what could be going on here, or where to look next?

The errors do suggest an authentication problem so the recent kerberos update - referenced by Greg Askew - may well be the cause, especially if you updated recently and the problem started at that point. If you think so, consider removing that update temporarily and then when everything is working again, plan to dcpromo the 2008 servers out ASAP.

You could try this tool: https://www.microsoft.com/en-us/download/details.aspx?id=30005

I'm sure I've used another replication monitoring tool from MS before too, I just can't remember what it's called right now. It was an MSI install is all I can remember about it! Maybe it was FRS diag only, not dfrs.

AD Replication is highly reliant on DNS and on synced time, so definitely triple check all of that setup. You could compare times with:

net time \\server

See if there's any disparity - if it works at all (Ie if no connection problem between servers when running the command). Otherwise look at syncing them all from the same external time source, pool.ntp.org for example.

To test DNS, ping every server fqdn from every other server, compare results to each other and to what you expect. I presume you've some VPN or similar non-nat L3 routing between on-prem and AWS? E.g. 192.168.1.10 can ping 10.0.0.2, or whatever the 'internal' IPs are on-prem and on AWS (I'm only familiar with Azure so might not be the same, forgive me if AWS works differently somehow).

You might also want to check both AWS and on-prem in AD sites and services, drill down to NTDS and look at the replication relationships. You can right-click and replicate, see if it says (paraphrasing) "ok" or "can't do it" - might help narrow down the problem.