Your Cloud VPN Still Depends on the Hosting Provider

You installed the operating system, hardened the service and hold the keys, and it starts to feel like the server is yours. It is yours in the way a rented flat is yours: the door lock is under your control and the building is not. The hypervisor, the network in front of the instance and the account that can rebuild it all belong to someone else. That distinction decides what a recovery plan has to cover, and it is the part self-hosting changes least.

The Account Is the Real Control Plane

A hosting account manages the virtual machine, its disks, its snapshots, its public addresses and its network rules. Every one of those can be changed without logging into the guest at all, which places the account outside the threat model most VPN guides describe. A perfect tunnel configuration survives an account action that replaces a disk.

Protect that account as a separate asset: independent credentials, hardware-backed second factors, and an audit trail that somebody actually reads. Sharing it with the same password manager entry as the VPN service is the mistake that makes every other control irrelevant.

Read the provider's split of duties for the specific product rather than for cloud in general. The shared responsibility model is a useful example of how the layers are divided, and other providers describe their own boundaries rather than inheriting that one. What you are looking for is which failures you are expected to fix and which ones you can only report.

Infrastructure Events You Cannot Administer

Live migration, host maintenance, a hardware failure on the physical node and a capacity event are all things the provider handles on its own schedule. You may see a reboot, a brief packet loss or an address change, and you will not see the reason. A design that treats the instance as a fixed point will interpret each of those as a VPN fault. The corrective action is to make the service tolerant of an instance that disappears, rather than to investigate a cause you will never be shown.

Backups belong to this layer, not to the tunnel. Keep the server configuration, identities, address plan and permitted routes somewhere that does not depend on the instance being reachable, and confirm that the copy can be restored without the original disk.

Address behaviour deserves its own check. Whether a public address survives a stop, a replacement or a deletion depends on how it was allocated, and the three operations are not interchangeable. Write down which one you rely on before an incident makes the question urgent.

Check What Survives a Rebuild

Build the recovery path while everything works. Identify the console or out-of-band access the provider offers, confirm you can reach it without the tunnel, and store the credentials somewhere that a failed laptop or a lost phone does not take with it. If a local firewall change blocks the tunnel, that console is the only way back in.

curl -s http://169.254.169.254/latest/meta-data/instance-id
curl -s http://169.254.169.254/latest/meta-data/public-ipv4
cloud-init status --long

The metadata service answers questions about the instance that the guest cannot otherwise see, and its exact paths differ between providers and between platforms, so verify them against the documentation for the product you run. Then run one controlled rebuild of a test instance and time it. A recovery procedure nobody has executed is a hypothesis.

Note what the rebuild did to the address, the host keys, the disk identity and anything the clients pin. Clients that cached a host key will complain after a rebuild, and that complaint is correct behaviour rather than a bug to suppress.

Decide What Self-Hosting Actually Changes

Running your own VPN moves trust from a VPN operator to a hosting provider plus yourself. That is a real change, and it is not the same as removing a third party. If the point was to stop a commercial VPN from observing traffic, the provider can still observe the instance's network, its disk and its billing records.

Your own logs describe your software, and they do not describe every infrastructure record the provider keeps. The reverse is also true: infrastructure visibility does not establish what a provider retains. Both questions need the provider's policy and your own configuration, and neither answers the other.

Write the answer down as a division of labour: which layer failed, who can repair it, and how long that repair takes. Self-hosting changes who you trust, and the useful part of the exercise is knowing exactly which layer you are trusting them for.