Introducing the NAT Gateway and Network Load Balancer

In this installment, we introduce our first 'non-VM' resources: the NAT Gateway and the Network Load Balancer (NLB). The former uses Source NAT to provide a simple way for for VMs without a direct Internet connection to reach public sites and endpoints — something that wasn't possible, e.g., in Part 3 of this series; the latter effectively uses Destination NAT to provide a relatively 'out-of-the-box' way to acheive Layer 4 load-balancing and/or redundancy. Their corresponding entries in our Ansible Module's documentation can be found here and here, respectively.

Please note that, as both the NAT Gateway and the NLB require their own reserved IP address, your will need to be able to reserve at least two IP addresses (you can see you how many 'reserved IP addresses' your contract is currently using and still able to reerve in the DCD under [Profile Icon] --> Resource Overview).

Also note: From

SNAT Support: Managed NLB is not configured to support Source NAT (SNAT); targets cannot initiate network connections through the load balancer.

NLB operates at TCP/IP layer 4 of the Open Systems Interconnection (OSI) model. NLB will distribute any TCP-based network traffic, including upper application layer protocols, such as HTTP and HTTPS. However, rules and health checks are strictly TCP-based, which means that HTTP rules (e.g., routing decisions based on the URL) are not supported.

What's in this example?

This example consists of the following files:



This playbook builds upon the Cube-related code from Example 3, by adding the necessary calls to reserve an IP address block and create a NAT Gateway with its associated rule


After retrieving the necessary information via the Cloud API, this playbook provisions one or more 'application servers' and an NLB, along with two rules that will forward incoming ssh and http requests to said servers in a round-robin fashion. (And whilst it's hardly ground-breaking, this playbook also shows how one might provision multiple 'sister-VMs' given a minimal list of configuration options, too)


This playbook runs on the app servers themselves to (amongst other things) install the NGINX web server and custom, host-specific index.html files (which, in turn, show which server you've reached)


This playbook cleans up all of the resources provisioned in the previous parts, and should be run once you're done with the earlier parts


This file contains the variable definitions common to all of this example's individual playbooks


This file is common to all of our Ansible examples and contains a set of more generally-used variable definitions

More concretely, this example introduces the following IONOS Cloud modules:

  1. ionoscloudsdk.ionoscloud.ipblock

  2. ionoscloudsdk.ionoscloud.nat_gateway and nat_gateway_rule

  3. ionoscloudsdk.ionoscloud.network_load_balancer and network_load_balancer_rule

whilst also showing how one can dynamically create a list of objects given a pre-existing list (see the three set_fact tasks beginning with the one which defines target_ips in 02__create_app_servers_and_nlb.yml).


Note: As with all other 'executable' examples in this repository, an 'End User Licence Agreement'-like statement will be displayed, which must also be accepted before the tasks proper can be executed.

Please note that, while potentially quite minimal, you will incur charges for the resources based upon how long you keep them provisioned; for more information on the actual costs, you can follow the links displayed in the 'EULA' text. Also note that, if you run the following through to completion, the playbook should 'clean up' after itself, but we recommend you verify this, e.g., via the DCD or ionosctl to make sure you won't be charged for any unwanted resources.

  1. To provision the jumpbox and NAT Gateway, run the following command:

    ansible-playbook 01__create_jumpbox_and_nat_gw.yml
  2. To provision the application servers and the NLB, run the following command:

    ansible-playbook 02__create_app_servers_and_nlb.yml
  3. To configure the application servers that were provisioned in Step 2, run:

    ansible-playbook -i inventory.yml 03__configure_app_servers.yml
  4. Optionally, examine the resources that were provisioned in Steps 1 and 2

  5. Execute the following to delete the resources provisioned in the previous steps:

    ansible-playbook 04__clean_up.yml

Between Steps 3 and 5, you can also run the following commands to access the various resources, directly and via the load balancer:


ssh -F ssh_config ${TARGET_HOST}

ssh into the specified server, where ${TARGET_HOST} is one of jumpbox, app-server-1 or app-server-2

ssh -F ssh_config nlb

ssh into one of the app servers via the load balancer (in a round-robin fashion); to see, e.g., the internal servers' IP addresses, you could append ip addr to the 'base command'

curl http://${NLB_ADDRESS}

retrieve the index.html file from one of the app servers via the load balancer, where ${NLB_ADDRESS} is the public IP address assigned to the NLB (visible either, e.g., via ionosctl ipblock list or the DCD, or in the ssh_config file)


In this tutorial, we saw examples of:

  1. how to use the ionoscloudsdk.ionoscloud.ipblock module to reserve an IP address block;

  2. how the ionoscloudsdk.ionoscloud.nat_gateway and nat_gateway_rule modules can be used to provision and configure a NAT Gateway;

  3. how the ionoscloudsdk.ionoscloud.network_load_balancer and network_load_balancer_rule modules can be used to provision and configure an NLB; and

  4. how we can verify that an NLB with a round-robin policy is forwarding incoming connections as expected.

Last updated