@AusSupport180
The actual siteLink cost values aren't important on their own.
My best guess is that "large" (large being subjective) values were used between countries to promote regionally-local sites ahead of crossing international boundaries, in which case those large values make total sense.
What matters is their relative weighting compared to other siteLink objects coming from the same site (if there are multiple, that is.)
The cost attribute is an INTEGER that has no upper or lower limit bounds meaning it can accept ridiculously large values, so there's really nothing to worry about.
There are other influential control points outside of the siteLink cost value, too, such as whether automatic site bridging has been left enabled (uncommon in larger environments but definitely possible) and whether siteLinkBridge objects have been defined (rarely used, which is sad because they're incredibly useful from a disaster recovery perspective - which is exactly the situation you're now in.)
One thing to watch out for is where the site design isn't done very well and lots of inappropriately-configured perimeter firewalls exist. The outcome from this kind of misconfiguration is unhappy users as authentication functions frequently time out as their client randomly tries to talk to domain controllers blocked by intermediate firewalls.
If this is happening, you can run the following statement in PowerShell on one of the affected clients - assuming they're Windows domain-joined clients - to get a brief overview of what that client believes it are the next closest (i.e. value in "AdjacentSites".) You do not need administrative rights to do this.
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite() | Select-Object -Property Name, AdjacentSites
Proper site design is a big topic, filled with "it depends"-style answers. But for your file server issue, it's mostly unrelated - the obvious overlap being authentication (which would mostly incur infrequent, up-front overhead for the France clients when accessing a new file server or their current Kerberos ticket expires, etc.)
Getting back to your file server situation.
File servers that use DFS-N to point to underlying hosts in different locations will still continue to work, since clients choose what they think is the most appropriate server based on data stored in Active Directory, which you don't lose just because one domain controller disappeared. The pain point for the clients is that they can't query a local domain controller to get that information: it has to come from another domain controller elsewhere. But, since the data does still exist, they will arrive at the same conclusion as when the local domain controller existed.
So long as the local DFS-N target is still working, the user might experience a longer time in opening the file while the local domain controller is offline, but once opened should perform normally.
As my previous post alluded though (via the SYSVOL comment, but it could be any other DFS-N namespace using the domain controllers as a target), this is assuming the files don't live on the domain controllers themselves (which they shouldn't.)
However, the understanding I got from your original post is the file servers only live exclusively in AWS-London, in which case the DFS-N points above, while interesting, would have nothing to do with your current domain controller issue in France.
Cheers,
Lain
