A Network Security Group, usually shortened to NSG, is a list of allow and deny rules for network traffic.

Computers on a network talk by sending small packages of data called packets. Network traffic is simply the flow of these packets from one place to another. When you open a website, packets travel from your computer to a server and back. When an application reads from a database, packets travel between two servers.

In Azure, resources such as virtual machines live inside a virtual network, which is your private network in the cloud. By default, many of these resources can talk to each other freely. An NSG lets you say exactly which conversations are allowed and which are blocked. It filters traffic coming into a resource, called inbound traffic, and traffic going out of it, called outbound traffic.

An NSG is not a physical box and it is not a server. It is a set of rules stored in Azure and applied automatically by the platform. It costs nothing to create. You can attach the same NSG to many subnets or network cards, and you can change a rule at any time, with the change taking effect within seconds.

Words you will meet again and again

A network with no rules is like a building with no doors.

Imagine a company that places a web server, an application server and a database inside the same virtual network. If nothing limits the traffic, a problem in one machine can spread to all the others. An attacker who breaks into the web server could try to reach the database directly. A mistake by a developer could expose a management port to the entire internet.

The security idea behind NSGs is called least privilege. It means every resource should be allowed to talk only to the exact peers it needs, using only the exact ports that are needed, and nothing more. NSGs are the everyday tool for putting this idea into practice at the network level.

Every rule answers the same set of questions, so once you learn them you can read any NSG.

A security rule describes one kind of traffic and says what to do with it. To describe the traffic, it uses five pieces of information, often called the five-tuple. Together with a direction, a priority and an action, these make up a complete rule.

Understanding ports and protocols

A port is like a numbered door on a computer. Each service waits at a well-known door. The secure web service waits at one door, plain web at another, remote login for Linux at another, and remote desktop for Windows at yet another. Databases wait at their own doors. When you write a rule, you choose which doors it covers.

The protocol describes the style of conversation. TCP is careful and reliable, like a phone call where each side confirms what was heard, and is used by websites and databases. UDP is quick and light, like shouting a message across a room, and is used for some streaming and name lookups. ICMP is used for simple checks, such as the ping test.

Priority and the first match

Rules are checked in order of priority, from the lowest number to the highest. As soon as one rule matches the traffic, Azure applies its action and stops looking at the other rules. This means the order matters a lot. A broad rule with a low number can hide a narrower rule with a higher number.

A brand-new NSG is not empty, because Azure places safe starting rules in it.

Every NSG carries a set of default rules. They have very high priority numbers, which means they are checked last. You cannot delete or edit them, but you can override them by adding your own rules with lower numbers. They give a sensible baseline: resources in the same network may talk to each other, the internet may not start conversations with your servers, and your servers may reach out to the internet.

What the defaults really mean

The first inbound default says that anything inside your virtual network may talk to anything else inside it. This is friendly but also dangerous, because a compromised machine can reach all its neighbours. That is why serious designs add their own deny rules between tiers, with lower numbers than 65000.

The last two defaults deny everything else. For inbound traffic this means that unless you add an allow rule, the internet cannot reach your servers. For outbound traffic, the internet is allowed by the earlier default, so servers can download updates unless you block them.

NSGs remember conversations, which makes rules much simpler to write.

NSGs are stateful. This means that when a conversation is allowed in one direction, the replies belonging to that same conversation are allowed back automatically. Azure keeps a short-lived record of each allowed conversation, called a flow. You do not need to write a second rule for the answer.

For example, if you allow visitors to reach your web server on the secure web port, the web server’s replies to those visitors leave freely, even if an outbound rule would otherwise block them. The reverse is also true. If your server starts a conversation to a database and the outbound rule allows it, the database’s replies come back in without an extra inbound rule.

sequenceDiagram
  participant V as Visitor
  participant N as NSG
  participant W as Web Server
  V->>N: Request to web door
  N->>N: Inbound rule allows, flow recorded
  N->>W: Request delivered
  W-->>N: Reply
  N-->>V: Reply passes automatically
        

An NSG does nothing until you attach it to something.

You can associate an NSG with a subnet, with a network interface card, or with both. A subnet is a slice of your virtual network, and a network interface card, called a NIC, is the virtual plug that connects one machine to the network. A rule set on a subnet applies to every resource in that subnet. A rule set on a NIC applies only to that one machine.

The order of checking

When both a subnet NSG and a NIC NSG exist, traffic must be allowed by both. For incoming traffic, the subnet NSG is checked first and then the NIC NSG. For outgoing traffic, the NIC NSG is checked first and then the subnet NSG. A deny at any step stops the traffic.

flowchart LR
  I["Inbound Traffic"] --> S1["Subnet NSG"]
  S1 --> N1["NIC NSG"]
  N1 --> VM["Virtual Machine"]
  VM --> N2["NIC NSG"]
  N2 --> S2["Subnet NSG"]
  S2 --> O["Outbound Traffic"]
        

Typing long lists of addresses is boring and error-prone, so Azure provides ready-made labels.

Azure services use many internet addresses, and these addresses change over time. A service tag is a name that stands for a whole group of addresses belonging to one Azure service or category. Microsoft keeps each tag up to date automatically. You simply use the name in a rule, and the group of addresses behind it stays correct without any effort from you.

Rules that mention addresses become hard to read, so name your servers by their role instead.

An Application Security Group, called an ASG, is a label that you create and attach to the network cards of machines that share a role. You might create one called “web-servers”, one called “app-servers” and one called “db-servers”. Then you write rules using those names instead of numbers.

Understanding what happens to each packet makes troubleshooting far easier.

Azure applies NSG rules on the host machine that runs your virtual machine, inside a piece of software called the virtual switch. Because the check happens on the host, before a packet reaches your machine, nothing inside your server needs to change. The operating system of the server never even sees the traffic that was denied.

flowchart TD
  P["Packet arrives at host"] --> F{"Part of an allowed flow?"}
  F -->|"Yes"| D["Deliver to server"]
  F -->|"No"| R["Check rules by priority"]
  R --> M{"First matching rule"}
  M -->|"Allow"| C["Record flow and deliver"]
  M -->|"Deny"| X["Drop packet silently"]
        

Let us walk through a classic example: a web tier, an application tier and a database tier.

Suppose your system has three groups of servers. The web servers receive visitors, the application servers run business logic, and the database servers store data. Each group lives in its own subnet with its own NSG. The goal is that traffic flows only in one direction down the chain.

flowchart TD
  I["Internet"] -->|"Secure web door only"| W["Web Subnet"]
  W -->|"Application door only"| A["Application Subnet"]
  A -->|"Database door only"| D["Data Subnet"]
  M["Management Subnet"] -.->|"Admin access"| W
  M -.->|"Admin access"| A
  M -.->|"Admin access"| D
        

The shape of a good rule list

Azure has several security tools, and each one fits a different job.

Not every Azure service lives inside your subnet, and some subnets have special needs.

An NSG filters traffic for resources that have a network card in your virtual network, such as virtual machines. Many platform services, like storage accounts and databases, do not sit in your subnet. They are reached through their own addresses. NSG rules can control traffic going out to them with service tags, but the service itself is protected through its own firewall, private endpoints and identity settings.

Traffic the platform treats specially

A few pieces of basic infrastructure traffic, such as the address-giving service of Azure and the health checks from the platform, use special platform addresses. Some of this traffic is handled by the platform and is not controlled the same way as ordinary traffic. Rely on the official documentation for the exact list instead of guessing.

The most attacked doors on any server are the ones used for remote administration.

To manage a server, administrators connect remotely. Windows servers use a remote desktop door and Linux servers use a secure shell door. Because these doors give full control of a machine, attackers constantly scan the internet for them and try common passwords. A server with an open management door on a public address is usually attacked within minutes.

A rule list is only trustworthy if you can see what it is really doing.

Azure offers several ways of watching NSG behaviour. Together they let you answer three questions: “who changed the rules?”, “what traffic was allowed or blocked?” and “does this specific traffic pass?”

Follow a calm checklist instead of changing rules at random.

A company with hundreds of subnets cannot manage rules by clicking in a portal.

As an environment grows, the number of NSGs and rules grows with it. Azure offers generous limits on how many NSGs and rules you can have, but human attention is the real limit. Without discipline, rule lists fill up with forgotten exceptions and nobody dares to remove anything.

These approaches appear again and again in well-run Azure environments.

flowchart TD
  INT["Internet"] --> FW["Central Firewall in Hub"]
  FW --> SP1["Spoke 1 with NSGs per subnet"]
  FW --> SP2["Spoke 2 with NSGs per subnet"]
  SP1 --> T1["Web Tier"]
  SP1 --> T2["Application Tier"]
  SP1 --> T3["Data Tier"]
        

NSGs quietly guard almost every serious Azure deployment.

These shortcuts regularly lead to break-ins, outages and confusing audits.

Walk through these steps whenever you design NSGs for a new network.

An NSG is a basic, free packet filter that works with addresses, ports and protocols. A full firewall such as Azure Firewall adds central management, filtering by website name, threat intelligence and richer logging. Many designs use both.

Creating and using NSGs is free. Costs can appear from related features such as storing flow logs and analysing traffic.

The rule with the lower priority number is checked first, and its action applies. Later rules are ignored for that traffic, so ordering is important.

No. Default rules cannot be removed or changed, but you can override them by adding your own rules with lower priority numbers.

No. NSGs are stateful, so once a conversation is allowed, its replies are allowed automatically in the opposite direction.

In most cases attach it to the subnet, which keeps the design simple and easy to audit. Use network card NSGs only for special exceptions, and remember that when both exist, traffic must be allowed by both.

Denied packets are dropped silently, so the sender waits until it times out. A hanging connection often points to a network rule, a route or a firewall, while an instant refusal usually means nothing is listening on the port.

No. NSGs work with network addresses and ports. To filter by website name, use Azure Firewall or another service that understands domain names.

Use a service tag for storage in your outbound rule, or better, connect through a private endpoint and restrict the storage account’s own firewall. This keeps traffic off the open internet.

Use the IP Flow Verify tool in Network Watcher. Enter the source, destination, port, protocol and direction, and it names the rule that allows or denies the traffic. Flow logs can also show blocked connections over time.

A Network Security Group is the everyday rulebook of an Azure network. Each rule describes a kind of traffic and says allow or deny, rules are checked by priority from the lowest number up, and the first match wins. Default rules provide a safe but loose baseline, so serious designs add their own rules to separate tiers and limit outgoing traffic. With service tags, application security groups, careful placement on subnets, safe administration paths, good logging and management through code, NSGs turn a flat cloud network into a set of well-guarded rooms.