Start with the problem of an open network, then see how a firewall changes the picture.

The problem

When you build systems in the cloud, they talk to each other and to the outside world. A web server talks to a database. A database server might try to download updates. A developer laptop connects in from home. Every one of these conversations is a possible path for an attacker. If everything may talk to everything, one stolen password or one infected machine can spread through the whole network like water through a leaky ship.

What the service is

Azure Firewall is a managed, cloud-based network firewall. “Managed” means Microsoft runs and updates the machines behind it, so you do not patch or replace anything. “Firewall” means it sits on the path of traffic and decides, packet by packet or connection by connection, whether to allow or deny it. It is stateful, which means it remembers a conversation: if it allowed a request out, it knows the reply coming back is part of the same conversation and lets it through.

What it gives you

Understanding the history of firewalls explains why the cloud version looks the way it does.

The first firewalls: packet filters

Early firewalls were simple. They looked at each small piece of data, called a packet, and checked a few facts on its label: where it came from, where it was going and which port number it used. A port is like a numbered door on a computer; web traffic uses one door, email another. A rule might say “allow door 80 to this server, deny all else.” These filters were fast but forgetful. They treated every packet alone, with no memory of the conversation.

Stateful firewalls

The next step added memory. The firewall tracked each connection, so it knew when a packet belonged to a conversation that was already allowed. This made rules shorter and safer, since you only had to describe who may start a conversation.

Application-aware firewalls

Then attackers started hiding bad behavior inside normal-looking doors. A web request on the web door could carry a harmful payload or head to a dangerous website. Newer firewalls learned to read the application conversation: which website name was requested, what kind of content it was and whether the traffic matched known attack patterns. The most advanced are sometimes called next-generation firewalls.

The move to the cloud

In an office, a firewall was a physical box in a rack at the edge of the network. In the cloud, there is no edge in that sense. Networks are software, created in seconds and changed constantly. Teams first ran firewall software on virtual machines, which meant patching, sizing and fixing them. Cloud providers then built managed firewalls to take that burden away.

The old idea of a perimeter

Traditionally, companies drew a line around their network. Inside was trusted, outside was not. In the cloud, this simple picture fades: staff work from everywhere, applications call each other across networks, and attackers who get inside move sideways. Modern security therefore also inspects traffic inside, between your own parts. This idea, often called zero trust, treats every connection as something to verify. A central firewall is one of the tools that makes this practical.

Each term below says what it is, why it exists, where it is used, a picture from daily life and an example.

How the words fit together

Read it as a chain. A route table sends traffic from a subnet to the firewall. The firewall consults its policy, which contains rule collection groups, holding rule collections, holding individual rules. The first match decides, and the decision is written to a log. If you remember this chain, the portal and documentation make sense.

Here is where the firewall sits and what surrounds it in a typical design.

flowchart TD
  NET["Internet"]  FWPIP["Firewall public IP"]
  subgraph HUB["Hub virtual network"]
    FW["Azure Firewall in its own subnet"]
    BAS["Management subnet for admin access"]
  end
  FWPIP  FW
  subgraph S1["Spoke 1 virtual network"]
    A1["Web servers"]
  end
  subgraph S2["Spoke 2 virtual network"]
    A2["Database servers"]
  end
  A1  FW
  A2  FW
  ONP["On-premises network"] |"VPN or private circuit"| FW
  POL["Firewall policy"] -.-> FW
  LOG["Log workspace"] -.-> FW

The firewall subnet

The firewall needs its own subnet with a specific required name, and no other resource may live there. Think of it as a guardhouse with its own plot of land. The subnet must be large enough for the firewall to grow, since it adds instances behind the scenes as traffic rises. Check the current minimum size in the documentation and choose comfortably above it.

Public and management addresses

The firewall has at least one public address, used for traffic going to the internet and for inbound translation. Some tiers and configurations also need an additional management subnet and address so Azure can control the firewall without using your data path. This is a detail to confirm for your chosen tier.

The hub

In a hub-and-spoke design, the hub is a central virtual network that holds shared services such as the firewall, connections to on-premises and sometimes name resolution. The spokes are separate networks for applications, each connected to the hub. This layout makes the firewall a single choke point where all important traffic must pass.

The policy

The firewall’s behavior lives in a policy. A policy can inherit from a parent policy, so a central security team defines company-wide rules, and application teams add their own rules below. This is the cloud version of a company rulebook with local appendices.

Supporting pieces

Azure Firewall comes in more than one tier. Each adds protection and cost, so choose by need.

This table is a simplified picture. Exact features, limits and names change, so confirm the current comparison on the official page before you decide.

Basic

Meant for smaller environments with moderate traffic. It gives essential filtering at a lower price, with fixed throughput limits lower than other tiers. Good for a small company that needs a managed gatekeeper but not deep inspection.

Standard

The common choice for production. It adds full threat intelligence, filtering by categories of websites, more rule capacity and automatic scaling to high throughput.

Premium

For sensitive and regulated systems. It adds a system that watches for signatures of known attacks, can look inside encrypted web traffic after decrypting it with a certificate you provide, and filters at the level of the full web address, not only the website name.

Choosing a tier

Start with the questions: Is there regulation requiring intrusion detection or inspection of encrypted traffic? How much throughput do you expect? How many rules and networks? Do you need to filter by full address? If you answer “no” to the heavy features, Standard is usually enough. Premium is worth it when the data is valuable or rules demand it. Switching tiers later is possible but should be planned and tested.

Follow one connection from a server to the internet and see every decision on the way.

sequenceDiagram
  participant VM as Spoke server
  participant UDR as Route table
  participant FW as Azure Firewall
  participant TI as Threat intelligence
  participant NET as Internet site
  VM->>UDR: Send packet to a website
  UDR-->>VM: Next hop is the firewall
  VM->>FW: Packet arrives
  FW->>TI: Is destination known bad?
  TI-->>FW: No
  FW->>FW: Check NAT, then network, then application rules
  FW->>FW: Rule matches, action is allow
  FW->>NET: Forward with the firewall public address
  NET-->>FW: Reply
  FW->>FW: Match reply to remembered connection
  FW-->>VM: Deliver reply
  FW->>FW: Write log entry

Step by step

Network rules versus application rules

Network rules work on addresses and ports and are evaluated first. Application rules understand the name in a web request or in the secure handshake, so they can say “allow this server to reach the update site on the secure web door.” Because application rules look at names, they are more precise for internet destinations, whose addresses may change without notice.

What about the premium extras

In premium, an additional engine inspects traffic for patterns of known attacks and can drop matching connections. If encrypted inspection is enabled, the firewall acts like a trusted middleman: it ends the encrypted conversation, reads the content, and starts a new one toward the real destination. Clients must trust the certificate the firewall uses for this. A later chapter covers the benefits and cautions.

Rules are the heart of the firewall. Writing them well is the difference between a safe network and a false sense of safety.

Network rules

A network rule names a source, a destination, a protocol and a port. Sources and destinations can be single addresses, ranges, IP groups, service tags or, in some cases, names. Example: allow the application subnet to reach the database subnet on the database port. Network rules suit traffic between your own networks, traffic to on-premises, and non-web traffic such as time synchronization or remote login.

Application rules

An application rule names the source, the protocol (such as the secure web protocol) and the destination website names. Wildcards are allowed at the start of a name, such as every host under one company domain. Premium adds filtering by full web address and by web categories like gambling or social media. Use these for outbound web access, so a server can reach only the update site and the monitoring site it needs.

NAT rules

A NAT rule, also called a destination translation rule, takes traffic arriving at the firewall’s public address and port and forwards it to a private server and port. It is useful for exposing a service without giving the server its own public address. Use it sparingly and prefer a web gateway for public web applications, since the firewall is not a web application firewall.

Rule order

When a network rule allows traffic, application rules for the same traffic are not consulted. When a network rule denies it, the deny stands. This detail surprises many people: a broad network rule can silently override a careful application rule.

Writing good rules

When you have more than one firewall, managing each separately becomes a chore and a risk. Policies solve this.

What a policy contains

A firewall policy stores the rule collection groups, the threat intelligence mode, DNS settings, and in premium the intrusion detection mode and the certificate for encrypted inspection. You attach a policy to one or several firewalls. Updating the policy updates all firewalls using it.

Parent and child

A child policy inherits everything from its parent and can add its own rules. Rules in the parent are evaluated first and cannot be removed by the child. This allows the central security team to say “these destinations are always blocked” and “these services are always allowed,” while application teams add what they need.

flowchart TD
  P["Company base policy: global blocks and shared allows"] --> R1["Region A policy"]
  P --> R2["Region B policy"]
  R1 --> F1["Firewall in Region A hub"]
  R2 --> F2["Firewall in Region B hub"]
  R1 --> F3["Firewall in Region A test hub"]

Firewall Manager

Azure Firewall Manager is a central console for creating policies, attaching them to firewalls and managing security across many virtual networks and subscriptions. It also supports secured virtual hubs, which are Microsoft-managed hubs that include a firewall, simplifying routing in large designs.

Who may change what

Use role-based access control to separate duties. A small security team may edit the base policy. Application teams may edit only their own child policy. Auditors can read everything but change nothing. Every change should go through review, since a single wrong rule can open the network or cut off a service.

Infrastructure as code

Describe policies in template files stored in version control. Reviewers can see exactly what changes, test environments can be created from the same files, and a bad change can be reverted quickly. Clicking in the portal leaves no trail and invites drift between environments.

Limits to keep in mind

There are limits on the number of rules, collections and groups per policy, and on how many IP addresses can be used in rules. Large estates should check the current limits and design around them, for example by using IP groups and service tags to keep rule counts down.

A firewall only guards traffic that passes through it. Routing is how you make sure that happens.

User-defined routes

Azure creates default routes for each subnet. To send traffic through the firewall, you create your own route table with a route that matches all destinations, written as 0.0.0.0/0, and set the next stop to the firewall’s private address. You then attach the table to the spoke subnets. From then on, traffic leaving those subnets for the internet reaches the firewall first.

Spoke to spoke traffic

By default, two spokes connected to the same hub cannot talk to each other. They are not directly connected. To let them communicate, routes in each spoke send the other spoke’s address range to the firewall, which then decides whether to allow it. Now the firewall can inspect and log east-west traffic, meaning traffic that moves sideways inside your network.

On-premises traffic

Traffic from your offices arrives through a VPN or private circuit into the hub. To inspect it, route it through the firewall as well, using routes on the gateway subnet. Traffic back to on-premises from spokes goes to the firewall first, then onward.

Asymmetric routing

A connection must travel through the same firewall in both directions. If the request goes through the firewall but the reply takes another path, the firewall sees only half the conversation, treats the reply as unknown and drops it. This is called asymmetric routing, and it causes some of the most confusing faults. The fix is to review routes on both ends so all paths agree.

flowchart LR
  A["Spoke 1 server"] -->|"route to firewall"| F["Firewall"]
  F -->|"allowed"| B["Spoke 2 server"]
  B -->|"reply must return the same way"| F
  F --> A
  B -. "direct reply path would break it" .-> A

Forced tunneling

Some organizations want all internet traffic to go through their own network first, for example through a corporate proxy. The firewall supports a forced tunneling mode where internet-bound traffic is passed onward to another device. It needs an extra management subnet so Azure can still reach the firewall. This setup adds complexity; use it only when required.

Routes learned automatically

Gateways can advertise routes learned from on-premises, and these may compete with your custom routes. If an automatically learned route is more specific than your default route, it wins. Check effective routes for a network interface when behavior surprises you. Most guides recommend disabling propagation of gateway routes on spoke route tables so that your own routes stay in charge.

Where you place the firewall shapes everything else. A few well-known layouts cover most needs.

Why hub-and-spoke is popular

It centralizes expensive and sensitive services in one place while keeping applications in neat separate spokes. A new application team gets a spoke and a route table, and automatically inherits the company’s baseline rules. The firewall’s cost is shared across all applications.

Layering with other protections

Where public web traffic fits

A common design puts a web application gateway with a firewall feature at the front for incoming web traffic, while Azure Firewall guards outbound traffic and traffic between networks. Each does what it is best at. The two can be arranged in series or in parallel, and the choice depends on where you need to inspect and which addresses your servers see.

The advanced protections go beyond simple allow and deny lists. Understand what each one does and what it costs.

Threat intelligence

Microsoft maintains feeds of addresses, names and web addresses known to be linked to malware, scanning and other harm. The firewall can compare traffic with these feeds. In alert mode, it only writes a log entry. In alert and deny mode, it blocks the traffic as well. Start with alert if you are worried about false matches, then move to deny after reviewing a period of logs. Feeds change often, so you gain protection without writing new rules.

Intrusion detection and prevention

In the premium tier, a signature-based engine looks for patterns that match known attacks across many categories. Signatures are updated regularly. Modes include off, alert only, and alert and deny. You can override a signature, such as turning off a noisy one for a specific source, or setting different handling by category. Signature checking costs processing power, which is why throughput limits are lower with this feature on than with simple rules alone.

Inspecting encrypted traffic

Most web traffic is encrypted, so a firewall that cannot see inside misses most of what is happening. In the premium tier, the firewall can decrypt outbound web traffic, inspect it, then re-encrypt it. For this to work, you give the firewall an intermediate certificate from your own certificate authority, stored in Key Vault, and make every client machine trust that authority.

Limits of encrypted inspection

The feature applies to outbound traffic and traffic between your own networks. Inspection of inbound encrypted traffic to public web applications is handled by a web application gateway at the front. Pinned certificates, client certificates and some protocols cannot be decrypted. Always test with your applications before enforcing.

URL and category filtering

Standard allows filtering by website name and category. Premium also reads the full web address of decrypted requests. This helps allow one folder of a site while blocking another, though only if decryption is used for that traffic.

Names and addresses are the plumbing under every rule. When they go wrong, everything looks broken.

DNS proxy

DNS turns a name into an address. When the firewall is set as a DNS proxy, servers send their name questions to the firewall, which forwards them to a name server and returns the answers. This matters for rules that use names: the firewall must resolve a name to the same address that the server resolves, or the rule may not match. Using one resolver for both avoids such gaps. It also gives you a log of every name asked, which is valuable for spotting suspicious activity.

Outbound address and port exhaustion

When many servers go to the internet through one public address, the firewall must tell connections apart by using different source port numbers. Each public address offers a limited number of ports for a given destination. A busy system opening very many connections to the same destination can run out, and new connections fail. The remedy is to add more public addresses or use a NAT gateway with the firewall subnet, which offers many more ports. Plan this in advance for heavy outbound workloads.

Known destinations your servers need

Servers often quietly need access to platform services: operating system updates, time synchronization, monitoring agents and license servers. Block everything, and these silently fail. Microsoft publishes tags that group these destinations so you can allow them without chasing addresses. Use FQDN tags and service tags where possible; they update automatically.

Private access to platform services

Instead of sending storage or database traffic across the internet, you can give those services private addresses inside your network using private endpoints. The traffic stays on the private network and the firewall can inspect it. Consider that private endpoint traffic may need special route settings to flow through the firewall, so verify the behavior in your design.

IPv6 and other protocols

Check whether your tier and region support the address types and protocols you need. Do not assume that all features of one protocol family work for another.

The guard at the gate must also be guarded. Whoever controls the firewall controls the network.

Who may change it

Use role-based access control with the smallest roles that work. Separate the right to read from the right to write. Consider requiring approval for changes to the base policy, and use privileged access features so powerful roles are active only for a short time when needed. Every rule change is an audit event; send these events to a protected log store that the changers cannot edit.

Protecting secrets

The certificate used for encrypted traffic inspection is extremely sensitive: anyone holding it could impersonate sites to your users. Store it in Key Vault with tight access, use a managed identity for the firewall, rotate it on schedule and monitor its use. Never email or store it in shared folders.

Avoiding over-broad rules

The most common weakness is not a software bug but a rule that is too wide. A rule that allows all ports from all internal addresses to anywhere defeats the firewall. Review rules for words like “any” and for large address ranges. Tools that analyze rule hits and suggest tighter rules can help.

Defense in depth

Do not make the firewall your only protection. Add subnet filters, server hardening, strong identity, patching and monitoring. If an attacker slips past one layer, others should still stand. A good test is to ask: if this firewall rule were wrong, what else would stop an attacker?

Protecting management paths

Administrators need to reach servers, but exposing remote login ports to the internet is risky. Use a managed bastion service or just-in-time access that opens a port only for a short time and for a named person. The firewall can then allow remote login only from the bastion subnet.

Compliance and evidence

Regulated organizations must show that controls exist and work. Keep records of rule approvals, regular rule reviews, log retention and test results. Firewall logs, policy history and activity logs together tell a clear story to an auditor.

A firewall that cannot keep up becomes a traffic jam at the gate. Know how it grows.

Automatic scaling

Behind the single name, Azure Firewall runs several instances. When traffic or the number of connections rises, new instances are added; when it falls, they are removed. You do not pick a size. The tier sets the upper limit of throughput, and the actual speed depends on what features are on. Simple rules are fastest; intrusion prevention and encrypted inspection cost more processing and lower the ceiling.

Scaling takes time

Adding instances takes minutes. A sudden, enormous burst can arrive faster than scale-out. If you expect a known event, such as a big batch job or a migration, consider the effect in advance and test it. Watch the throughput and the health metrics during growth.

A worked example

These numbers are illustrative and are not official limits. Suppose a company has 40 servers and each moves about 50 megabits per second at busy times, but not all at once. If 60 percent are busy together, the peak is 40 times 0.6 times 50, which is 1,200 megabits per second, or about 1.2 gigabits per second. If your chosen tier and feature mix comfortably handle, say, 5 gigabits per second, there is room to grow. If you turn on intrusion prevention and the practical ceiling drops to 1 gigabit per second, you would exceed it and should choose another approach, such as splitting traffic across firewalls or excluding trusted internal flows from deep inspection. Always check real limits for your tier on the official pages.

Factors that reduce throughput

Reducing load sensibly

Do not send traffic through the firewall that gains nothing from it. For example, large data copies between two trusted servers in the same subnet do not need inspection; keep them local. Use private endpoints and platform firewalls for services that have their own protection. Group servers sensibly so noisy traffic stays away from the hub.

Latency

Every extra hop adds a little time. A firewall adds typically small delays, but a design that sends a connection through two firewalls and across regions adds up. Keep paths short and avoid sending traffic to a distant hub when a local one exists.

If the gate stops working, either everyone is shut out or everyone walks in. Neither is acceptable, so plan for failure.

Availability zones

In supported regions you can deploy the firewall across several availability zones, which are separate buildings with their own power and cooling in one region. If one zone fails, instances in others keep working. This raises the availability promise, but spread the servers behind it as well. Zone choice must be made when creating the firewall in some cases, so decide early. Verify the current service level and options in the documentation.

Planned maintenance

Microsoft updates the underlying machines. The managed design is meant to roll updates without interruption, but long-lived connections may reset. Applications should reconnect gracefully.

Across regions

One firewall belongs to one region. For protection against a region-wide outage, deploy a second hub and firewall in another region, with applications replicated there, and use global routing or DNS to move users. Keep both firewalls on matching policies, which is easy when they share a base policy. Practice the failover regularly.

flowchart LR
  subgraph RA["Region A"]
    FA["Firewall across zones"] --> AA["Applications A"]
  end
  subgraph RB["Region B"]
    FB["Firewall across zones"] --> AB["Applications B"]
  end
  POLB["Shared base policy"] -.-> FA
  POLB -.-> FB
  U["Users and on-premises"] --> FA
  U -. "failover path" .-> FB

Fail open or fail closed

If the firewall is unreachable, traffic through it stops, which is fail closed and safe, but business stops too. Some teams worry and add bypass routes. Such bypasses defeat the point of the gate. The better answer is making the firewall itself resilient and testing recovery steps, not adding a secret back door.

Backup of configuration

Keep policies in code. If a policy is damaged or deleted, you can recreate it quickly. Use resource locks on production firewalls and policies so that no one deletes them by accident.

Failure modes to expect

A guard who writes nothing down cannot answer questions later. Logs and metrics make the firewall explainable.

Metrics

Metrics are numbers over time. Useful ones include throughput, the number of processed connections, how many rule hits were applications versus network rules, the health state of the firewall, counts of SNAT port use, and latency probe results. Chart them on a dashboard and learn what normal looks like.

Logs

Log categories include application rule logs, network rule logs, NAT rule logs, threat intelligence logs, intrusion detection logs, DNS proxy logs and flow trace logs. Send them to a Log Analytics workspace to search with queries, to a storage account for long retention, or to an event stream for outside tools. Structured logs let you find, for example, every denied connection from one server in the last hour.

Useful questions the logs answer

Alerts worth having

Alert when the firewall health drops, when SNAT port use passes about eighty percent, when throughput nears the tier limit, when threat intelligence reports a deny, when denied traffic spikes suddenly and when any rule or policy changes outside the approved process.

A troubleshooting walk

Azure Firewall is a premium security service, and its bill has a few parts. Prices change, so use the official calculator for real figures.

A worked monthly example

The numbers below are invented to show the method. Suppose a standard-tier firewall costs 1.25 dollars per hour. A month of 730 hours is 1.25 times 730, which is 912.50 dollars. If it processes 20 terabytes, which is 20,000 gigabytes, at an illustrative 0.016 dollars per gigabyte, that is 320 dollars. One public address at 0.005 dollars per hour is 3.65 dollars. The total is about 1,236.15 dollars before logs. Add a second firewall for a test hub that runs all month, and you add roughly another 916 dollars in hourly charges. That is why test firewalls should be deleted when idle or shared.

Ways to reduce cost

Share one firewall across many spokes in a hub rather than building one per application. Pick the tier to fit the need, not the maximum. Keep traffic that does not need inspection away from the firewall by using local controls. Deallocate or delete non-production firewalls outside working hours where the service allows it. Trim log categories and retention. Consider whether a simpler option, such as network security groups and platform firewalls, is enough for small isolated workloads.

Where money is wasted

Typical waste includes premium features that nobody uses, firewalls left running in forgotten test subscriptions, large volumes of low-value logs and duplicate firewalls built by separate teams. A quarterly review against traffic data finds these quickly.

Several Azure services protect networks. Each answers a different question, and they usually work together.

flowchart TD
  Q["What do you need to control?"] --> A{"Incoming public web traffic?"}
  A -->|"Yes"| W["Web application firewall at the front"]
  A -->|"No"| B{"Traffic between networks or to the internet?"}
  B -->|"Yes"| F["Azure Firewall in a hub"]
  B -->|"No"| C{"Simple subnet-level filtering?"}
  C -->|"Yes"| N["Network security group"]
  C -->|"No"| O["Check private endpoints, bastion and other tools"]

Network security groups versus the firewall

Security groups are free, fast and local, but they work only with addresses, ports and tags. They have no names-based rules, no threat intelligence and no central view. Use them as a second layer for every subnet. Use the firewall for central policy, name-based rules, inspection and logs.

Third-party firewalls

Many vendors sell virtual firewall appliances in Azure. They bring familiar features and consoles to teams who use the same product on-premises, and sometimes offer advanced functions the native service lacks. The trade-offs are that you run and patch them, license them and design their high availability. Native services are easier to manage; appliances offer familiarity and special features. Compare against your real requirements.

An honest look at what the service does well and where it falls short.

Key trade-offs

Finding balance

Security teams tend to want more control, and application teams want fewer obstacles. A workable balance is a clear request process with a fast approval path for low-risk rules, a standard set of common allows built into the base policy, and regular reviews to clean up. Making rules easy to request lowers the temptation to ask for “allow everything” just to avoid delays.

Teams with good results repeat a few habits. Teams with bad results repeat a few mistakes. Naming both helps you copy the first and avoid the second.

Patterns that work

Anti-patterns to avoid

A checklist to apply before any firewall carries real traffic.

Best practices

Common mistakes

Walk through the failures before they happen, and recovery becomes routine.

Scenario one: a new application cannot reach its database

A team deploys an application in a new spoke. Connections to the database time out. The firewall log shows nothing. Cause: the spoke has no route table, so traffic never reached the firewall and was blocked by another layer, or went the wrong way. Recovery: attach the route table and add the needed rule. Prevention: create the spoke from a template that includes routes.

Scenario two: everything to the internet stops at once

Servers cannot download updates or reach any website. Cause: a recent change to a parent policy, or port exhaustion on the public address. Recovery: check the activity log for the latest policy change, revert it, or add public addresses. Prevention: change review, alerts on port use, and staged rollout of base policy changes.

Scenario three: a legitimate site is blocked

Staff cannot reach a business partner’s site. Cause: the site falls in a blocked category or appears in a threat feed. Recovery: confirm that it is safe through the security team, then add a narrow exception with an expiry date and a note. Prevention: a defined exception process.

Scenario four: encrypted inspection breaks an application

After turning on decryption, one application fails with certificate errors. Cause: the application pins certificates or uses client certificates, which cannot work with a middleman. Recovery: exclude that destination from decryption, record the reason and review it later. Prevention: pilot with a few machines before enabling widely.

Scenario five: compromised server talks to a bad address

Threat intelligence logs show a server connecting to a known malicious address, and the connection was denied. Action: isolate the server, review its logs, change credentials it held, and search the logs for other servers contacting the same destination. Prevention: alerts that notify the team in minutes.

Scenario six: a region outage

The hub’s region fails. Recovery: move traffic to the second region’s hub, which uses the same base policy, and follow the tested runbook. Prevention: a second hub, replicated data and regular drills.

flowchart TD
  A["Connection fails"] --> B{"Entry in firewall log?"}
  B -->|"No"| C["Check routes and subnet filters"]
  B -->|"Yes, denied"| D["Find rule or default deny, then adjust rule or priority"]
  B -->|"Yes, allowed"| E["Check destination server, DNS and return path"]
  C --> F["Retest and confirm in log"]
  D --> F
  E --> F

The firewall is shared infrastructure. Treat changes to it with the care you would give the main gate of a busy city.

Build from code

Write the firewall, policies, route tables and peering as code and keep them in version control. Every change then has an author, a reason, a reviewer and a history. Test, staging and production can be built from the same files with different settings, so a rule that works in test behaves the same in production.

A safe change path

Governance with policy

Azure Policy can enforce rules about the environment itself: every subnet must have a route table that points to the firewall, no virtual machine may have a public address, firewalls must send logs to the central workspace. These checks prevent the quiet drift that weakens security over time.

Ownership

Assign a clear owner for the firewall platform, for the base policy and for each child policy. Write down how requests are made, how fast they are handled and who approves emergency changes. Ambiguity causes both delays and dangerous shortcuts.

Documentation

Keep a simple diagram of the network, a list of what each rule collection is for, and a runbook for the six scenarios in the previous chapter. A new team member should be able to understand the design in an afternoon.

Moving from old firewalls

When replacing an on-premises or virtual appliance firewall, do not copy thousands of old rules blindly. Analyze which are used, translate them into groups and names, clean up, test in a copy of the network, and cut over in stages with a clear rollback. Migration is a chance to tidy years of accumulated rules.

These are typical, invented scenarios that show the ideas at work. They are not reports about any named company.

What they share

Each example starts from deny, writes narrow rules, uses logs to learn and adjust, and treats rules as controlled changes. The tool helped, but the discipline made the difference.

A rule that has never been tested is only a hope. Careful testing shows that the firewall allows what it should and blocks what it should.

Test both directions

Most people test only that the needed traffic works. A complete test also proves that the unwanted traffic fails. If the web tier may reach the database on one port, test that connection, and also test that it cannot reach the database on another port, that the database cannot start connections back to the web tier, and that a server in another spoke cannot reach the database at all. A firewall passes its exam only when the forbidden doors stay shut.

Build a test list from the design

Take the network diagram and list every flow that should be allowed. Then list a handful of flows that must be denied, chosen as the most dangerous ones: remote login from the internet, database access from the wrong tier, outbound access to a random website, and traffic to a known bad test address provided by your security team. Write each as a simple sentence with source, destination, port and expected result. This list becomes a repeatable checklist that you can run after every change.

Use the logs as the judge

For each test, look at the log entry, not just the result on the screen. The log shows which rule matched and whether the action was allow or deny. If a test works but shows a match on an unexpected broad rule, you have found a weakness even though the connection succeeded.

Test in a copy first

Build a small test network from the same code as production and run the checklist there before any production change. Automate the checklist with scripts, so it runs in a pipeline after each deployment and a failed test stops the release.

Test the surrounding systems

Test the failures you fear: remove a route and see what happens; fill a log workspace and see if alerts fire; let a test certificate expire and watch how the applications react. These drills are best done on purpose, in daylight, with the team ready, rather than discovered at three in the morning.

Re-test on a schedule

Networks drift. People add exceptions, services change addresses and new teams join. Run the checklist every month, and after any large change. Compare results to the previous run, and follow up on every difference.

Short answers to common questions. Where a detail may have changed, confirm in the current Microsoft documentation.

Azure Firewall is the managed gatekeeper of your cloud network. It remembers conversations, applies rules by address and by name, blocks known bad traffic and records what it decides.