Cloud computing... fun times. FWIW, IPSec+IKE can actually be quite simple. For example, here's the lone configuration line from /etc/iked.conf needed to create a VPN tunnel using OpenBSD:

  ikev2 "home-to-colo" quick active esp \
    from 1.2.3.4 to 0.0.0.0/0 \
    peer yournode.cloudvendor.com \
    ikesa auth hmac-sha2-256 enc aes-128 prf hmac-sha2-256 group curve25519 \
    childsa enc aes-128-gcm group curve25519 \
    psk "some password"

That's the whole of it beyond enabling the iked service at startup. The other side of the above tunnel (taken from a working example, names changed to protect privacy) is exactly the same except the flows are reversed (from 0.0.0.0/0 to 1.2.3.4) and its configured for passive mode (waits for someone to connect and claim the flow for 1.2.3.4). The above tunnel is actually used to give my home router a static IP address (1.2.3.4), routed through a vultr VM. vultr let's you add up to 2 additional IP addresses to a $5/month instance.

An X.509-based PKI setup is just as easy, other than generating and signing the certificates.

It's actually easier than using Wireguard, IMHO. Now, if you want to be interoperable with random vendors you have to be mindful of which cipher suites are supported. Few IPSec implementations support curve25519, for example. I manually specify the ikesa and childsa cipher suites in the above to ensure that the negotiated ciphers will be hardware accelerated on my PCEngines APU2, but also to prove that IPSec can use the latest cipher modes like aes-gcm and curve25519. OpenBSD even supports chacha20-poly1305 if you wanted to be really hip. But aes-128 + SHA-256 + one of the ECDSA groups (I forget which one) is supported by all modern BSD, Linux, macOS, Windows, and iPhone implementations, so in 2019 near universal support is actually quite easy to achieve.

Technically you shouldn't need to specify any cipher modes at all as IKE endpoints can negotiate a shared set themselves. But IKE works differently than TLS. Rather than a peer sending all supported ciphers and the other peer selecting one from their shared set as TLS does, the IKE peers go through multiple cycles of proposals and rejections. The problem is that many vendor implementations will give up after 2 or 3 cycles, so you need to constrain the supported cipher suites to ensure they agree on cipher modes within the first few proposal cycles. Easiest thing to do is to just constrain one endpoint to the known best cipher suite.

Alas Android still only supports IKEv1 natively, which means for maximum interoperability you have to rely on IKEv1 + L2TP server side. L2TP is usually implemented as a separate service requiring additional configuration, which adds to the confusion. IKEv2 simultaneously simplified tunnel setup while also obsoleting L2TP. The irony of Android possibly getting native Wireguard before native IKEv2 kills me....

FWIW, Linux IPSec stacks like FreeSwan don't have the concise configuration of OpenBSD's IKE daemon, partly because the Linux ecosystem sucks at polish, partly because OpenBSD's IKE daemon is many years newer and has less baggage. But conceptually it's just as simple.