Migrate From Azure Firewall to Cloud Firewalls

Azure Firewall is a managed firewall service by Microsoft that provides stateful traffic inspection and filtering for Azure Virtual Networks. It allows administrators to define rules based on IP addresses, ports, protocols, and fully qualified domain names (FQDNs). It supports both application-level and network-level filtering.

Cloud Firewalls on Akamai Cloud is a network-level firewall service that lets users control traffic for Linode instances and NodeBalancers, Akamai Cloud’s load balancing service. Cloud Firewalls support inbound and outbound traffic management for Linode instances and inbound traffic for NodeBalancers. They operate at Layers 3 and 4 of the OSI model (see diagram below), providing IP, protocol, and port filtering.

This guide includes steps on how to migrate a basic security setup from Azure Firewall to Cloud Firewalls. It covers planning, documenting your configuration, creating equivalent rules with Cloud Firewalls, and testing results to ensure network security after migration.

Feature Comparison

Before beginning the migration process between service providers, it’s important to understand the capabilities and specifications of both Azure Firewall and Cloud Firewalls. This can help optimize your results by identifying which rules can be migrated directly and which may require additional configuration.

Features of Azure Firewall

Azure Firewall inspects both inbound and outbound traffic for Azure Virtual Networks. It supports rule sets for network-level filtering (based on IP addresses, ports, and protocols) and application-level filtering (based on FQDNs and web categories). Administrators can apply threat intelligence filtering to allow or deny traffic from known malicious sources. Azure Firewall policies integrate with Azure Monitor for logging and provides centralized control over traffic flows across regions and resource groups. Note that features may differ depending whether you are using Azure Firewall Premium, Standard, or Basic.

Features of Cloud Firewalls

Cloud Firewalls on Akamai Cloud is a Layer 3/4 stateless packet filter designed for simplicity and performance. It allows users to specify rules that allow or deny traffic based on source IP, destination port, and protocol (TCP, UDP, ICMP, and IPEncap). The Cloud Firewalls service does not inspect application-layer traffic; however, it is effective at managing access to services based on IP and port-level rules.

What’s Not Directly Portable

Since Cloud Firewalls doesn’t currently support Layer 7 inspection, features such as pattern matching, geographic filtering, and rate limiting cannot be replicated natively. These must be implemented at the application level using reverse proxies like NGINX or other third-party services.

Before You Begin

Complete the following prerequisites prior to following the steps in this guide.

Follow our Get Started guide to create an Akamai Cloud account if you do not already have one.
Create a personal access token using the instructions in our Manage personal access tokens guide.
Install the Linode CLI using the instructions in the Install and configure the CLI guide. See our API reference for comprehensive documentation of Linode CLI functionality.
You need an Azure subscription with a user or service principal that has permission to list, view, and modify Firewall and Network resources.
Ensure the Azure CLI is installed locally and configured (via az login) for the appropriate account and default subscription.

Example Environment Used in This Guide

The example used throughout this guide involves an Azure VM instance on a network with traffic governed by an Azure Firewall. The VM instance is configured for several services:

Web traffic handled by NGINX on ports 80 and 443
PostgreSQL database on port 5432
SSH on port 22
Redis on port 6379

The Azure Firewall is configured with inbound rules to restrict access to known IP addresses.

The equivalent setup on Akamai Cloud uses a single Linode instance running the same services. The Cloud Firewalls service is used to recreate the access controls previously handled by the Azure Firewall.

Document Your Current Configuration

Before making changes, it’s essential to fully understand your existing Azure VM instance and Azure Firewall configuration. Document and template how traffic flows to your Azure VM by noting which ports are open and which services are bound to each port. This can help you set up equivalent access controls using Cloud Firewalls.

Review Azure Firewall Rules

Use the Azure Firewall Manager in the Azure Portal or the az CLI to export or list your Azure Firewall rules.

In the Azure Portal, navigate to your Resource group to view your list of Azure resources.
Select the appropriate VM instance to view its details:
Within the VM details, navigate to Network settings:
Take note of the names of the virtual network and subnet as well as the private IP address for the VM. In the above example, the VM resides in the vm-workloads subnet of the virtual network called my-virtual-network. Its private IP address in the virtual network is 10.0.0.5.
Click the virtual network name, then navigate to the Subnets page for the virtual network:
Note the IP address range for the subnet in which your VM resides. In the above example, VM instances in the vm-workloads subnet are allocated IP addresses within the 10.0.0.0/24 range.
Return to the overview page of your Resource group. Find the Azure Firewall and click on it:
On the Details page for the Azure Firewall, navigate to Rules. Find the NAT rule collection and click on it:
On the NAT rule collection page is a list of firewall rules:
The rules in the example above allow traffic from certain sources to specific ports on the Azure Firewall’s public IP address (20.245.225.123). These are then routed through the virtual network to the corresponding port at the private IP address of the VM instance (10.0.0.5).

To view Azure Firewall rules from the az CLI, run the following commands:

First, display the name of the Azure firewall along with its NAT rule collections, replacing RESOURCE_GROUP the name of your resource group (e.g. my-resource-group):

Show firewall and rule collection names

az network firewall list \
    --resource-group RESOURCE_GROUP \
    --query '[].{Firewall:name,RuleCollections:natRuleCollections[].name}'

[
  {
    "Firewall": "my-virtual-network-Firewall",
    "RuleCollections": [
      "my-nat-rule-collection"
    ]
  }
]

Use the name of the AZURE_FIREWALL (e.g. my-virtual-network-Firewall) and the NAT_RULE_COLLECTION (e.g. my-nat-rule-collection) to list the firewall rules:

List firewall rules

az network firewall nat-rule collection show \
    --resource-group RESOURCE_GROUP \
    --firewall-name AZURE_FIREWALL \
    --collection-name NAT_RULE_COLLECTION \
    --query 'rules'

[
  {
    "description": null,
    "destinationAddresses": [
      "20.245.225.123"
    ],
    "destinationPorts": [
      "22"
    ],
    "name": "SSH",
    "protocols": [
      "TCP"
    ],
    "sourceAddresses": [
      "*"
    ],
    "sourceIpGroups": [],
    "translatedAddress": "10.0.0.5",
    "translatedFqdn": null,
    "translatedPort": "22"
  },
  {
    "description": null,
    "destinationAddresses": [
      "20.245.225.123"
    ],
    "destinationPorts": [
      "5432"
    ],
    "name": "PostgreSQL",
    "protocols": [
      "TCP"
    ],
    "sourceAddresses": [
      "174.17.18.21"
    ],
    "sourceIpGroups": [],
    "translatedAddress": "10.0.0.5",
    "translatedFqdn": null,
    "translatedPort": "5432"
  },
  {
    "description": null,
    "destinationAddresses": [
      "20.245.225.123"
    ],
    "destinationPorts": [
      "6379"
    ],
    "name": "Redis",
    "protocols": [
      "TCP"
    ],
    "sourceAddresses": [
      "174.17.18.21",
      "173.230.141.194"
    ],
    "sourceIpGroups": [],
    "translatedAddress": "10.0.0.5",
    "translatedFqdn": null,
    "translatedPort": "6379"
  },
  {
    "description": null,
    "destinationAddresses": [
      "20.245.225.123"
    ],
    "destinationPorts": [
      "80"
    ],
    "name": "HTTP All",
    "protocols": [
      "TCP"
    ],
    "sourceAddresses": [
      "*"
    ],
    "sourceIpGroups": [],
    "translatedAddress": "10.0.0.5",
    "translatedFqdn": null,
    "translatedPort": "80"
  },
  {
    "description": null,
    "destinationAddresses": [
      "20.245.225.123"
    ],
    "destinationPorts": [
      "443"
    ],
    "name": "HTTPS All",
    "protocols": [
      "TCP"
    ],
    "sourceAddresses": [
      "*"
    ],
    "sourceIpGroups": [],
    "translatedAddress": "10.0.0.5",
    "translatedFqdn": null,
    "translatedPort": "443"
  }
]

The inbound traffic routing rules for the example in this guide are diagrammed below:

Plan Your Rule-Mapping Strategy

After documenting your Azure networking setup, plan how to translate those rules using the Cloud Firewalls syntax and feature set.

In this example, core services are exposed on ports 22, 80, 443, 5432, and 6379. The Azure Firewall routes traffic to certain ports (5432 and 6379) only from an approved IP allowlist, while traffic from any source can reach ports 22, 80, 443. These rules must be recreated on Akamai Cloud to maintain equivalent protection.

It can be helpful to create a side-by-side comparison, mapping Azure Firewall rules to their Cloud Firewalls equivalents. For example, a rule that allows PostgreSQL traffic (TCP 5432) from a specific IP should be represented as a Cloud Firewalls rule allowing TCP traffic on port 5432 from that same IP.

Back up Your Existing Configuration

Before disabling or removing Azure resources, create a backup of all relevant configuration data.

Run the following command to export your existing Azure Firewall DNAT rules and save the outputs to file:

az network firewall nat-rule collection list \
    --resource-group RESOURCE_GROUP \
    --firewall-name AZURE_FIREWALL \
    --output json \
    > firewall-rules.json

Create Equivalent Rules with Cloud Firewalls

Once planning and documentation are complete, begin building your new network firewall configuration in Akamai Cloud.

Cloud Firewalls rules can be managed through the Cloud Manager web interface or via the Linode CLI. This section demonstrates both methods.

Enable Cloud Firewalls

While logged into Cloud Manager, navigate to the Firewalls dashboard, and click Create Firewall.
Specify a label for the Cloud Firewall and accept the defaults for the inbound and outbound policies, and click Create Firewall. Initially, you do not need to assign any services. You can focus on rule creation first, then associate services later.

Once the Cloud Firewall has been created, you should see an initially empty list of inbound and outbound firewall rules.

Use the Linode CLI to create a firewall, replacing CLOUD_FIREWALL_LABEL with a label of your choosing (e.g. my-cloud-firewall):

linode-cli firewalls create \
    --rules.inbound_policy DROP \
    --rules.outbound_policy ACCEPT \
    --label "CLOUD_FIREWALL_LABEL"

┌---------┬--------------------┬---------┬---------------------┐
│ id      │ label              │ status  │ created             │
├---------┼--------------------┼---------┼---------------------┤
│ 2420060 │ my-cloud-firewall  │ enabled │ 2025-04-28T17:42:45 │
└---------┴--------------------┴---------┴---------------------┘

Recreate Rules Within Akamai Cloud Manager Web UI

Recreate each of the rules documented from your Azure Firewall.

Select your Cloud Firewall, and create a new rule by clicking Add An Inbound Rule.
Specify a label and description for the rule. For example:
Next, select the protocol and which ports to apply this rule to. You can select from commonly used ports or select Custom to specify a custom port range. For example:
For Sources, specify whether you want the rule to apply to all IPv4 or IPv6 addresses, or if you want to provide specific IP addresses. If providing specific IP addresses, add them one at a time. See our guide on managing firewall rules for syntax specifications.
Finally, decide whether the rule is meant to serve as an allowlist (Accept) or denylist (Drop). For this example migration from Azure Firewall, the action would be Accept. Click Add Rule.
Repeat the steps above to recreate all the equivalent rules from the Azure Firewall configuration.
After adding all rules, click Save Changes.

When using the web UI, rules must be created one at a time. With the Linode CLI, you can add all rules with a single call of the rules-update action for the firewalls command.

First, use nano or text editor of your choice to create a file called inbound-rules.json:

nano inbound-rules.json

Enter all the inbound rules as a JSON array, for example:

File: inbound-rules.json

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
[
    {
        "action": "ACCEPT",
        "addresses": {
            "ipv4": [
                "<span class="placeholder-shortcode">ALLOWED_IP_ADDRESS_1</span>/32",
                "<span class="placeholder-shortcode">ALLOWED_IP_ADDRESS_2</span>/32"
            ],
            "ipv6": []
        },
        "description": "Redis",
        "label": "restrict",
        "ports": "6379",
        "protocol": "TCP"
    },
    {
        "action": "ACCEPT",
        "addresses": {
            "ipv4": [
                "<span class="placeholder-shortcode">ALLOWED_IP_ADDRESS_1</span>/32",
                "<span class="placeholder-shortcode">ALLOWED_IP_ADDRESS_2</span>/32"
            ],
            "ipv6": []
        },
        "description": "PostgreSQL",
        "label": "restrict",
        "ports": "5432",
        "protocol": "TCP"
    },
    {
        "action": "ACCEPT",
        "addresses": {
            "ipv4": [
                "0.0.0.0/0"
            ],
            "ipv6": []
        },
        "description": "SSH",
        "label": "allow",
        "ports": "22",
        "protocol": "TCP"
    },
    {
        "action": "ACCEPT",
        "addresses": {
            "ipv4": [
                "0.0.0.0/0"
            ],
            "ipv6": []
        },
        "description": "HTTP web",
        "label": "allow",
        "ports": "80",
        "protocol": "TCP"
    },
    {
        "action": "ACCEPT",
        "addresses": {
            "ipv4": [
                "0.0.0.0/0"
            ],
            "ipv6": []
        },
        "description": "HTTPS web",
        "label": "allow",
        "ports": "443",
        "protocol": "TCP"
    }
]

When done, press CTRL+X, followed by Y then Enter to save the file and exit nano.

With the file in place, run the following Linode CLI command, making sure to supply your Akamai CLOUD_FIREWALL_ID (e.g. 2420060):

linode-cli firewalls rules-update CLOUD_FIREWALL_ID \
    --inbound "$(cat inbound-rules.json)"

┌-------------┬----------------┬-----------------┬---------┐
│ fingerprint │ inbound_policy │ outbound_policy │ version │
├-------------┼----------------┼-----------------┼---------┤
│ 96379b42    │ DROP           │ ACCEPT          │ 2       │
└-------------┴----------------┴-----------------┴---------┘

inbound
┌--------┬--------------------┬-------------┬---------┬-------┬---------┐
│ action │ addresses.ipv4     │ description │ label   │ ports │ protocol│
├--------┼--------------------┼-------------┼---------┼-------┼---------┤
│ ACCEPT │ 173.230.145.119/32 │ Redis       │ restrict│ 6379  │ TCP     │
├--------┼--------------------┼-------------┼---------┼-------┼---------┤
│ ACCEPT │ 50.116.12.84/32    │ PostgreSQL  │ restrict│ 5432  │ TCP     │
├--------┼--------------------┼-------------┼---------┼-------┼---------┤
│ ACCEPT │ 0.0.0.0/0          │ SSH         │ allow   │ 22    │ TCP     │
├--------┼--------------------┼-------------┼---------┼-------┼---------┤
│ ACCEPT │ 0.0.0.0/0          │ HTTP web    │ allow   │ 80    │ TCP     │
├--------┼--------------------┼-------------┼---------┼-------┼---------┤
│ ACCEPT │ 0.0.0.0/0          │ HTTPS web   │ allow   │ 443   │ TCP     │
└--------┴--------------------┴-------------┴---------┴-------┴---------┘

outbound
┌--------┬--------------------┬-------------┬---------┬-------┬---------┐
│ action │ addresses.ipv4     │ description │ label   │ ports │ protocol│
├--------┼--------------------┼-------------┼---------┼-------┼---------┤
└--------┴--------------------┴-------------┴---------┴-------┴---------┘

Attach Instances to the Firewall

You can attach multiple Linodes or NodeBalancers to the Cloud Firewall. Note that inbound and outbound rules apply to Linode instances, whereas only inbound rules apply to NodeBalancers.

See our additional migration documentation for guidance on migrating other services – such as compute instances – to Akamai Cloud.

Navigate to the Linodes tab for your Cloud Firewall and click Add Linodes to Firewall:
From the list, select which Linode (or Linodes) to assign to the Cloud Firewall and click Add:

The firewall rules you specified should now be applied to the Linode (or Linodes) you have added.

To assign Linodes to a Cloud Firewall using the Linode CLI, first retrieve the id of the Linode you want to add:

linode-cli linodes list

┌----------┬-------------┬--------┬---------┬-----------------┐
│ id       │ label       │ region │ status  │ ipv4            │
├----------┼-------------┼--------┼---------┼-----------------┤
│ 76033001 │ my-linode   │ us-lax │ running │ 172.235.225.120 │
├----------┼-------------┼--------┼---------┼-----------------┤
│ 76033002 │ my-linode-2 │ us-lax │ running │ 172.221.114.36  │
├----------┼-------------┼--------┼---------┼-----------------┤
│ 76033003 │ my-linode-3 │ us-lax │ running │ 172.218.17.4    │
└----------┴-------------┴--------┴---------┴-----------------┘

Next, execute the device-create action to assign a Linode to the Cloud Firewall, supplying both the LINODE_ID (e.g. 76033001) and the CLOUD_FIREWALL_ID (e.g. 2420060):

linode-cli firewalls device-create \
    --type linode --id LINODE_ID \
    CLOUD_FIREWALL_ID

┌---------┬---------------------┬---------------------┐
│ id      │ created             │ updated             │
├---------┼---------------------┼---------------------┤
│ 4877449 │ 2025-04-28T18:55:59 │ 2025-04-28T18:55:59 │
└---------┴---------------------┴---------------------┘

Test and Validate Your Configuration

After applying rules to your Cloud Firewalls, confirm that they behave as expected under real traffic conditions. Note that your firewall configurations may require different testing methods than those listed in this section.

Simulate Expected and Blocked Traffic

From an IP on the allowlist, test access for each service and confirm that the connection succeeds to your instance’s endpoint. Use ssh to test connections from any IP address.

In all examples, replace SERVER_IP_ADDRESS with the IP address of the instance assigned to your Cloud Firewall (e.g. 172.236.228.122).

Use curl to test HTTP traffic through NGINX:

cURL HTTP Connection Attempt

curl -I http://SERVER_IP_ADDRESS

HTTP/1.1 200 OK
Server: nginx/1.24.0 (Ubuntu)
Date: Mon, 28 Apr 2025 21:00:32 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Mon, 28 Apr 2025 20:58:01 GMT
Connection: keep-alive
ETag: "680febd9-267"
Accept-Ranges: bytes

Similarly, you can also use curl to test HTTPS traffic through NGINX:

cURL HTTPS Connection Attempt

curl -I https://SERVER_IP_ADDRESS

HTTP/1.1 200 OK
Server: nginx/1.24.0 (Ubuntu)
Date: Mon, 28 Apr 2025 21:02:02 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Mon, 28 Apr 2025 20:58:01 GMT
Connection: keep-alive
ETag: "6434bbbe-267"
Accept-Ranges: bytes

Note

If you generated a self-signed certificate, skip certificate verification by adding the -k flag:

curl -Ik https://SERVER_IP_ADDRESS

Attempt to connect to the PostgreSQL server with the psql client from an allowed IP address, replacing PSQL_PORT (e.g. 5432), PSQL_USERNAME (e.g. testuser), and PSQL_DATABASE (e.g. testdb):

Successful PostgreSQL Connection Attempt

psql --host SERVER_IP_ADDRESS \
    --port PSQL_PORT \
    --username PSQL_USERNAME \
    --dbname PSQL_DATABASE \
    --password

Password: ********
psql (17.2 (Ubuntu 17.2-1.pgdg20.04+1), server 16.8 (Ubuntu 16.8-0ubuntu0.24.04.1))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off, ALPN: none)
Type "help" for help.

testdb=#

In contrast, if you attempt to connect to the PostgreSQL server with the psql client from an IP address not allowed through the Cloud Firewall rules, the execution hangs after prompting for the password:
Blocked PostgreSQL Connection Attempt
psql --host SERVER_IP_ADDRESS \ --port PSQL_PORT \ --username PSQL_USERNAME \ --dbname PSQL_DATABASE \ --password
```
Password: ********
```

Attempt to connect to Redis with redis-cli from an allowed IP address, replacing REDIS_PORT (e.g. 6379):

Successful Redis Connection Attempt

redis-cli -h SERVER_IP_ADDRESS -p REDIS_PORT

The result should be similar to the following:

172.236.228.122:6379> INFO Server
# Server
redis_version:7.0.15
…
executable:/usr/bin/redis-server
config_file:/etc/redis/redis.conf
io_threads_active:0

Now attempt to connect to Redis with redis-cli from an IP address that is not on the allowlist:
Blocked Redis Connection Attempt
redis-cli -h SERVER_IP_ADDRESS -p REDIS_PORT
The connection attempt simply hangs:

Log and Monitor Behavior

The Cloud Firewalls service does not show per-packet or rule-level logging. To verify behavior, rely on logs from the services themselves. For example:

NGINX access logs, as configured in individual virtual server configuration files, are found in /etc/nginx/sites-available.
SSH authentication logs are located at (/var/log/auth.log).
Redis logs are typically found in /var/log/redis/redis-server.log, though this is configurable in /etc/redis/redis.conf.
PostgreSQL logs are typically found in /var/log/postgresql/, though this is configurable in /etc/postgresql/[PATH-TO-VERISON]/postgresql.conf.

Connection and activity logs from these services can help to confirm whether traffic is reaching them as expected.

Monitor Post-Migration Performance

Ongoing monitoring helps identify any overlooked configuration issues or unexpected traffic patterns. Continue observing application logs and metrics post-migration. Make sure services are available to intended users and there are no spikes in error rates or timeouts.

If legitimate traffic is being blocked or malicious traffic is being allowed, refine your Cloud Firewalls rules. It may take a few iterations to achieve parity with your original Azure Firewall behavior.

Finalize Your Firewall Migration

Once you’ve validated the new firewall configuration, clean up legacy resources and update internal references:

Find components that were connecting with your Microsoft Azure VM instance.
Create equivalent rules with Cloud Firewalls to allow traffic from legitimate components.
Remove the Azure Firewall.
Remove the Azure VM instance.

Update runbooks, internal network diagrams, and configuration documentation to reflect the new firewall architecture based on Cloud Firewalls.

More Information

You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

Compute

Storage

Networking

Databases

Services

Solutions

Pricing

Library

Technical Resources

Community

Marketplace

What's New

Search Results

No Results

Filters