Deploy using the NGINXaaS Console

Overview

This guide explains how to deploy F5 NGINXaaS for Google Cloud (NGINXaaS) using Google Cloud Console and the NGINXaaS Console. The deployment process involves creating a new deployment, configuring the deployment, and testing the deployment.

Before you begin

Before you can deploy NGINXaaS, follow the steps in the Prerequisites topic to subscribe to the NGINXaaS for Google Cloud offering in the Google Cloud Marketplace.

Access the NGINXaaS Console

Once you have completed the subscription process, you can access the NGINXaaS Console.

  • Open the NGINXaaS Console.
  • Log in with your preferred identity provider.
  • Select the Geography you want to work in.
Caution
Select the Geography that supports the region where you plan to deploy. See NGINXaaS for Google Cloud supported regions.

Create or import an NGINX configuration

In the NGINXaaS Console,

  1. On the left menu, select Configurations.

  2. Select Add Configuration to add a new NGINX configuration.

  3. You can either create a new configuration from scratch or copy an existing configuration:

    • Select New configuration to create a new config.
      • Provide a name for your configuration and an optional description.
      • Select to start with the "F5 NGINXaaS Default" (a basic NGINX setup) or an empty configuration file.
      • Select Next.
    • Select Copy existing configuration to use one of the existing configuration files in your account as template.
      • Provide a name for your configuration and an optional description.
      • Use the Choose configuration to copy list to select the configuration file you want to copy.
      • Use the Choose configuration version to copy list to select the version of the configuration file you want to copy.
      • Select Next.

  4. Modify the configuration file as needed.

    • Select Add File to stage new content such as certificates, configuration files, or upload non-configuration files.
    • Select File Actions to rename, move, delete, or copy files as you build out the overall configuration filesystem.
    • Warnings, errors, and recommendations appear in the editor as you modify your configuration content.
    • You can hover over an NGINX configuration directive to view helpful descriptions and usage details.

  5. Select Save.

Create a new deployment

Next, create a new NGINXaaS deployment using the NGINXaaS Console:

  1. On the left menu, select Deployments.

  2. Select Add Deployment to create a new deployment.

    • Enter a Name.
    • Add an optional description for your deployment.
    • Change the NCU Capacity if needed.
      • The default value of 20 NCU should be adequate for most scenarios.
    • Enable WAF if you want F5 WAF for NGINX enabled for your deployment.
    • In the Apply Configuration section, select an NGINX configuration you created earlier from the Choose Configuration list.
    • Select a Configuration Version from the list.
    • In the Cloud Details section, select a Region.
      • Make a note of this region — you’ll need to create a network attachment in the same region.
    • Optional: In the Cloud Details section, enter a network attachment ID or select one in the Network attachment list. A network attachment connects this deployment to your upstream servers, and is required for most use cases.
      • The network attachment ID is formatted like the following example: projects/my-google-project/regions/us-east1/networkAttachments/my-network-attachment.
    • If you haven’t created a network attachment yet, you can leave this field empty and add one after creating your deployment.
    • Select Managed Public Endpoint or Private Endpoint under Service Frontend.
      • Refer to the Service Frontend documentation for more information on these two frontend types.
    • Select Submit to begin the deployment process.

Your new deployment will appear in the list of deployments. The status of the deployment will be "Pending" while the deployment is being created. Once the deployment is complete, the status will change to "Ready".

If you did not add a network attachment while creating the deployment, make a note of its Region, visible under the Cloud Info section. If you plan to accept connections only from selected projects, also note the deployment’s Project ID. You’ll need these values in the next section. If you already added a network attachment, skip to Configure your deployment.

Create a network attachment

To connect your NGINXaaS deployment to your upstream servers, create a network attachment and add it to your deployment.

Caution

NGINXaaS for Google Cloud is supported in the following regions per geography:

NGINXaaS Geography Google Cloud Regions
US us-east1, us-east4, us-west1, us-west2, us-west3, us-west4, us-central1
EU europe-west1, europe-west2, europe-west3, europe-west4, europe-north1, europe-central2
APAC asia-southeast1, asia-south1, asia-south2, asia-northeast1, asia-northeast2, asia-northeast3
CA northamerica-northeast1, northamerica-northeast2

  1. Access the Google Cloud Console.

  2. Create a consumer VPC network and subnetwork. See Google’s documentation on creating a VPC and subnet for a step-by-step guide.

    Create the network attachment in the same region as your deployment.

  3. Create a network attachment in your new subnet. See Google’s documentation on creating a network attachment for a step-by-step guide. Configure the Connection preference on the Network Attachment resource using one of the following options:

    • Accept connections from selected projects (recommended): This option helps maintain security by ensuring only trusted providers can connect to your service by letting you manually approve trusted connections. Add your NGINXaaS deployment’s Project ID to the accept list to connect it to your upstream servers.

    • Automatically accept connections for all projects: This option lets you skip adding your deployment’s Project ID to an accept list.

      Caution 
        For development and testing purposes, or in scenarios where speed and simplicity are prioritized over security, you have the option to configure the **Connection Preference** to **Automatically accept connections for all projects**. Please note that this approach is inherently less secure and may expose your service to unintended or unauthorized access. We encourage you to exercise caution if using the less restrictive option and to avoid using it in production or sensitive environments.

  4. Copy the network attachment value. You can find it in the Google Cloud Console by following the steps below:

    1. Go to Network Attachments at the following link: https://console.cloud.google.com/net-services/psc/list/networkAttachments?project=my-google-project (replace my-google-project in the URL with your project name).
    2. Open the desired network attachment and copy the value from the Network Attachment field. Example format: projects/my-google-project/regions/us-east1/networkAttachments/my-network-attachment.

  5. Add the network attachment value to your deployment, either while creating the deployment or by editing an existing deployment. This connects your NGINXaaS deployment to your upstream servers.

You can add or remove a network attachment after creating a deployment by editing the deployment.

Warning
You cannot switch a deployment directly from one network attachment to another. To change the network attachment, first remove the existing one, wait for the deployment to return to a Ready state, then add the new network attachment.
Deployments created before Sept 8, 2026 do not support network attachment changes.

Configure your deployment

In the NGINXaaS Console,

  1. To open the details of your deployment, select its name from the list of deployments.
    • You can view the details of your deployment, including the status, region, network attachment, NGINX configuration, and more.
  2. Select Edit to modify the deployment description, NCU Capacity, and WAF enablement.
    • You can also configure monitoring from here. Detailed instructions can be found in Enable Monitoring
    • You can add or remove a network attachment from the Cloud Details section. See Create a network attachment for details on switching from one network attachment to another.
  3. Select Update to save your changes.
  4. Select the Configuration tab to view the current NGINX configuration associated with the deployment.
  5. Select Update Configuration to change the NGINX configuration associated with the deployment.
  6. To modify the contents of the NGINX configuration, see Update an NGINX Configuration.

Set up connectivity (Private Endpoint only)

If you selected Private Endpoint as the service frontend type, complete the following steps to allow client access. If you selected Managed Public Endpoint, skip this section.

Internal traffic

To set up private connectivity to your NGINXaaS deployment, create a Private Service Connect (PSC) endpoint in the same VPC as your internal clients.

  1. Go to the Google Cloud Console and select the project where you want to create networking resources for your F5 NGINXaaS deployment.
  2. Create or reuse a VPC network.
  3. Create a PSC endpoint. See Google’s documentation on creating an endpoint for a step-by-step guide.
    • For Target service, enter your NGINXaaS deployment’s Service Attachment, which is visible on the Deployment Details section for your deployment.

External traffic

To set up public connectivity for external clients, configure a Private Service Connect (PSC) backend for your NGINXaaS deployment.

  1. Go to the Google Cloud Console and select the project where you want to create networking resources for your F5 NGINXaaS deployment.
  2. Create or reuse a VPC network.
  3. Create a proxy-only subnet in your consumer VPC. See Google’s documentation on creating a proxy-only subnet for a step-by-step guide.
  4. Create a public IP address. See Google’s documentation on reserving a static address for a step-by-step guide.
  5. Create a Private Service Connect Network Endpoint Group (PSC NEG). See Google’s documentation on creating a NEG for a step-by-step guide.
    • Set Network endpoint group type to Private Service Connect NEG (Regional).
    • Set Target to Published service.
    • For Target service, enter your NGINXaaS deployment’s Service Attachment, which is visible on the Deployment Details section for your deployment.
    • For Producer port, enter the port your NGINX server is listening on. If you’re using the default NGINX config, enter port 80.
    • For Network and Subnetwork select your consumer VPC network and subnet.
  6. Create a regional external proxy Network Load Balancer. See Google’s documentation on configuring the load balancer for a step-by-step guide.
    • For Network, select your consumer VPC network.
    • For Backend configuration, follow Google’s step-by-step guide to add a backend.
    • In the Frontend configuration section,
      • For IP address, select the public IP address created earlier.
      • For Port number, enter the same port as your NEG’s Producer port, for example, port 80.

Each listening port configured on NGINX requires its own PSC network endpoint group with a matching port. You can use the following helper script to automate these steps:

Show helper script
bash
#!/bin/bash
set -euo pipefail
# Default values
PROJECT=""
REGION=""
NETWORK=""
SUBNET=""
SA_URI=""
PORTS="80"
PROXY_SUBNET="psc-proxy-subnet"
VIPNAME="psc-vip"

# Prerequisites:
# - gcloud CLI installed and configured
# - An existing projectID and a VPC network created in that project
# - A valid Service Attachment URI from F5 NGINXaaS

# Function to display usage
usage() {
   cat << EOF
Usage: $0 --project PROJECT --region REGION --network NETWORK --subnet SUBNET --service-attachment SA_URI [--ports PORTS]

Options:
   --project                 GCP Project ID
   --region                  GCP Region
   --network                 VPC Network name
   --subnet                  GCP Subnet for Backend Connectivity (must be in the same region and network)
   --service-attachment      Service Attachment Self Link
   --ports                   Comma-separated list of ports (default: 80)
   --help                    Show this help message

Note: Proxy subnet and public IP will be automatically created as 'psc-proxy-subnet' and 'psc-vip' respectively.
   These resources will not be deleted, if deleted this script will create new ones.

Example:
   $0 --project my-project --region us-central1 --network my-vpc --subnet my-subnet \\
      --service-attachment "projects/producer-proj/regions/us-central1/serviceAttachments/my-service" \\
         --ports "80,443,8080"
EOF
}

# Parse command line arguments
while [[ $# -gt 0 ]]; do
   case $1 in
     --project)
         PROJECT="$2"
         shift 2
         ;;
     --region)
         REGION="$2"
         shift 2
         ;;
     --network)
         NETWORK="$2"
         shift 2
         ;;
     --service-attachment)
         SA_URI="$2"
         shift 2
         ;;
     --ports)
         PORTS="$2"
         shift 2
         ;;
     --subnet)
         SUBNET="$2"
         shift 2
         ;;
     --help|-h)
         usage
         exit 0
         ;;
     *)
         echo "Unknown option: $1"
         usage
         exit 1
         ;;
   esac
done

# Validate required parameters
missing_params=()
[[ -z "$PROJECT" ]] && missing_params+=("--project")
[[ -z "$REGION" ]] && missing_params+=("--region")
[[ -z "$NETWORK" ]] && missing_params+=("--network")
[[ -z "$SUBNET" ]] && missing_params+=("--subnet")
[[ -z "$SA_URI" ]] && missing_params+=("--service-attachment")

if [[ ${#missing_params[@]} -gt 0 ]]; then
   echo "Error: Missing required parameters: ${missing_params[*]}"
   usage
   exit 1
fi

# Create proxy-only subnet (skip if exists)
echo "Creating proxy-only subnet if it doesn't already exist..."
if ! gcloud compute networks subnets describe $PROXY_SUBNET --region=$REGION --project=$PROJECT >/dev/null 2>&1; then
   gcloud compute networks subnets create $PROXY_SUBNET \
      --project=$PROJECT --region=$REGION \
      --network=$NETWORK \
      --range=192.168.1.0/24 \
      --purpose=REGIONAL_MANAGED_PROXY \
      --role=ACTIVE
fi

echo "Using proxy-only subnet: $PROXY_SUBNET"

# Create regional VIP address (skip if exists)
echo "Creating regional VIP address..."
if ! gcloud compute addresses describe $VIPNAME --region=$REGION --project=$PROJECT >/dev/null 2>&1; then
   gcloud compute addresses create $VIPNAME --region=$REGION --project=$PROJECT
fi
VIP=$(gcloud compute addresses describe $VIPNAME --region=$REGION --project=$PROJECT --format='get(address)')
echo "Using VIP address: $VIP"

# Convert comma-separated ports to array
IFS=',' read -ra PORTS_ARRAY <<< "$PORTS"

for P in "${PORTS_ARRAY[@]}"; do
   echo "Processing port $P..."

   # Create Network Endpoint Group (skip if exists)
   if ! gcloud compute network-endpoint-groups describe psc-neg-$P --region=$REGION --project=$PROJECT >/dev/null 2>&1; then
      gcloud compute network-endpoint-groups create psc-neg-$P \
      --project=$PROJECT --region=$REGION \
      --network-endpoint-type=private-service-connect \
      --psc-target-service="$SA_URI" \
      --network=$NETWORK \
      --subnet=$SUBNET \
      --producer-port=$P
   fi

   # Create Backend Service (skip if exists) - NO HEALTH CHECKS for PSC
   if ! gcloud compute backend-services describe be-$P --region=$REGION --project=$PROJECT >/dev/null 2>&1; then
      gcloud compute backend-services create be-$P \
         --project=$PROJECT --region=$REGION \
         --protocol=TCP --load-balancing-scheme=EXTERNAL_MANAGED

      # Add backend to service
      gcloud compute backend-services add-backend be-$P \
         --project=$PROJECT --region=$REGION \
         --network-endpoint-group=psc-neg-$P \
         --network-endpoint-group-region=$REGION
   fi

   # Create Target TCP Proxy (skip if exists)
   if ! gcloud compute target-tcp-proxies describe tp-$P --region=$REGION --project=$PROJECT >/dev/null 2>&1; then
      gcloud compute target-tcp-proxies create tp-$P \
      --project=$PROJECT --region=$REGION --backend-service=be-$P
   fi

   # Create Forwarding Rule (skip if exists)
   if ! gcloud compute forwarding-rules describe fr-$P --region=$REGION --project=$PROJECT >/dev/null 2>&1; then
      gcloud compute forwarding-rules create fr-$P \
      --project=$PROJECT --region=$REGION \
      --address=$VIP --network=$NETWORK \
      --target-tcp-proxy=tp-$P --target-tcp-proxy-region=$REGION \
      --ports=$P --load-balancing-scheme=EXTERNAL_MANAGED \
      --network-tier=PREMIUM --ip-protocol=TCP
   fi

   echo "Completed setup for port $P"
done
echo "Setup complete! Public Virtual IP: $VIP"

Test your deployment

  1. To test your deployment, connect to the IP address created in Set up connectivity or the service endpoint created with your managed public endpoint deployment.
The deployment is privately deployed in your subnet. If you want to route traffic to an application over the public internet, consider setting up Cloud NAT.

What’s next

View source
View as Markdown
Edit this page
Create a new issue