Replies inline ...

And our setup  is strange as we could never get the global AD admins to make DNS
entries for us among other issues so we ended up choosing a totally new
TLD domain name to run IPA on and bind our servers against; this works
fine except we can't leverage kerberos based features because our realm
is different from our domain.

You can enrol IPA client through through Kerberos, this correct?

Yep! Our oddball IPA setup looks like this, due to a combination of senior IT leadership being frightened of the cloud and global active directory domain admins doing their usual global admin thing and refusing to even take meetings with mortals. So we had to self-support and only got a grudging 1-way trust set with the domain after escalating to very high levels. It works though.

AD Domain (complex multi-child forest) == company-x.com with child domains at nafta.company-x.com, apac.company-x.com etc. etc.
Our FreeIPA domain name is == company-x-ipa.com

So our REALM is COMPANY-X-IPA and that is where we bind our client machines to when enrolling but we set the local domain name and hostname to "company-x.com" when we enroll the host

This works well but from what I've been told we lose the ability to do things like kerberized authentication for filessytem mounts etc. -- since all we really needed was RBAC managed SSH login with a small smattering of custom sudo roles and a bunch of local SSH key storage it works fine for us.

I wish its this, but I dont think so.  If it was this, wouldn't doing
dig @192.168.30.8 neptune.external.example.com work at least?  The
host 192.168.30.8 being in the office?  How is your VPC?   Do you have
public and private and NAT between?  Or just a flat public?  I went
with the later as I assumed IPA don't like working over NAT.

Yeah most of this DNS is on-premise; again because of a corporate desire to use AD for DNS. We basically point all our nameservers at the on-prem domain controllers and don't use FreeIPA for DNS records really much at all (even the _SVR records that enable FreeIPA auto-discovery) -- but no network, DNS query or technical issues at all with DNS being outside of AWS -- works fine for us even DNS queries made on the IPA masters. For rare cases where that did not work (HPC use cases) we did the DNSMasq thing so we could inject custom reverse DNS responses while still delegating other queries back to the domain controllers.

Our VPC is direct connected back to the corporate WAN; no NAT on the private AWS subnets so it would be flat/private. Lots of security controls and firewalls doing SSL intercept and decrypt at edges that blocked

Thanks again for the feedback.

Regards,
William