Terraform / cloud-init waiting for http proxy

Question

I'm using the Hetzner cloud Terraform provider for creating two hosts pub and backend both being connected to a common private network. In addition pub does have a second network interface to the internet. Both hosts are being created using Terraform each having its own cloud-init configuration:

resource "hcloud_server" "pub" {
  name         = "pub"
       ...
  public_net {
    ipv4 = data.hcloud_primary_ip.ip.id
  }
  network {
    network_id = hcloud_network.hc_private.id
    ip         = "10.0.1.20"
  }
  user_data = file("pub.yml")
}


resource "hcloud_server" "backend" {
  name         = "backend"
   ...
  public_net {
    ipv4_enabled = false
    ipv6_enabled = false
  }
  network {
    network_id = hcloud_network.hc_private.id
    ip         = "10.0.1.30"
  }

  depends_on = [
    hcloud_network_subnet.hc_private_subnet
  ]
  user_data = file("backend.yml")
}

Since backend is not being connected to the internet I'm using apt-cacher-ng on pub as a proxy offering its service on port 3142. apt on backend is being configured using pub as proxy server for package related operations.

Creating host pub requires time for package install and updates. Unfortunately host backenddoes not wait forpub's proxy service to come up thus all package related operations fail.

I've tried the following /usr/bin/waitForAptProxy script in cloud-init's runcmd section of backend to enforce waiting for the aforementioned proxy service:

#!/bin/bash

echo "Waiting for apt-cacher-ng to launch on 3142 ..."  
while ! nc -z 10.0.1.20 3142; do
  sleep 1 # wait for 1 second before check again
  echo not yet ...
done
echo "apt-cacher-ng launched"

Unfortunately this does not help since the package install / update phase on backend happens earlier. And moving the very same script to the bootcmd section does not work either since at that time backend's network is not yet up.

I'd like to e.g. hook the above script into the system's network configuration for postponing the »network ready« status so that package related operations only start afterwards.

My current hack in backend.yml:

runcmd:
...
  - /usr/bin/waitForAptProxy # See above script
  - apt -y update
  - apt -y install vim fail2ban ufw
 ...

Albeit working this completely defeats cloud-init's declarative approach.

Another (even more hacky / unsatisfactory) idea is waiting »sufficiently« long for the service to come up:

bootcmd:
  - sleep 300 # Too much / enough?

I'm new to the field thus hints pointing to a totally different approach are welcome as well. For security reasons backend should remain isolated from external internet access.

I've also tried using pub as a NAT based gateway to backend. This solution suffers from the very same issue of access happening too early as well. In addition I favor the idea of an application level rather than network proxy for both security and caching reasons.