Secure Your Azure VNET Using Network Security Groups

Akins IT • October 4, 2019

As mentioned in my previous blog titled “Microsoft Azure: Networking Basics”, subnets carved out from a VNET address space have complete access to communicate with one another. Although there’s more than one way to control cross network communication, this blog will cover the method of using Network Security Groups (NSG) to achieve this goal.

NSGs can be deployed through the Azure Marketplace and associated to either a subnet, VM network interface or both. When applied to the subnet, all VM’s contained within its network range will be impacted by the NSG. Applying the NSG directly to a VM interface can provide access control on a per VM level. Note that a VM that has an NSG applied to its virtual interface will still be impacted by a separate NSG at the subnet level.

a screenshot of the microsoft azure marketplace .

During the initial NSG creation process, you will be asked to fill in the name for your new NSG object as well as its resource group. The resource group is a logical container for Azure objects to exist in and can be one that you’ve already created or a newly provisioned group.

a screenshot of a microsoft azure sponsorship subscription and resource group .

Configuring & Applying A Network Security Group

Once deployed from the Azure Marketplace, you can now configure the inbound and outbound security rules and associate the NSG to either a subnet or VM interface.

Security rules use a combination of source and destination addresses or networks, port ranges, and protocols. Also note that just like access control lists, the rules are processed from a top to bottom order based on its priority number.

a screenshot of the add inbound security rule window .

Options to configure security rules and association to a subnet or network interface can be accessed from the menu show below.

a screenshot of a computer screen showing a list of people .

Once associated to a subnet or network interface, it can take several seconds to take effect. Inbound and outbound security rules must also be configured in their respective menu options. Configuring a rule meant for outbound traffic under the inbound section for example could result in unintended filtering of network traffic.

It’s also worth noting that if a VM has a public IP directly associated to its network interface, the NSG can be used to control and filter traffic between the VM and internet sources (as long as a UDR isn’t being used to route internet traffic through a virtual security appliance). In this scenario, an NSG applied to the VM interface would be used.

AWS stumbled this morning. Here’s why multi‑cloud keeps you moving.

By Shawn Akins • October 20, 2025

October 20, 2025 — Early today, Amazon Web Services experienced a major incident centered in its US‑EAST‑1 (N. Virginia) region. AWS reports the event began around 12:11 a.m. PT and tied back to DNS resolution affecting DynamoDB , with mitigation within a couple of hours and recovery continuing thereafter. As the outage rippled, popular services like Snapchat, Venmo, Ring, Roblox, Fortnite , and even some Amazon properties saw disruptions before recovering. If your apps or data are anchored to a single cloud, a morning like this can turn into a help‑desk fire drill. A multi‑cloud or cloud‑smart approach helps you ride through these moments with minimal end‑user impact. What happened (and why it matters) Single‑region fragility: US‑EAST‑1 is massive—and when it sneezes, the internet catches a cold. Incidents here have a history of wide blast radius. Shared dependencies: DNS issues to core services (like DynamoDB endpoints) can cascade across workloads that never directly “touch” that service. Multi‑cloud: practical resilience, not buzzwords For mid‑sized orgs, schools, and local government, multi‑cloud doesn’t have to mean “every app in every cloud.” It means thoughtful redundancy where it counts : Multi‑region or multi‑provider failover for critical apps Run active/standby across AWS and Azure (or another provider), or at least across two AWS regions with automated failover. Start with citizen‑facing portals, SIS/LMS access, emergency comms, and payment gateways. Portable platforms Use Kubernetes and containers, keep state externalized, and standardize infra with Terraform/Ansible so you can redeploy fast when a region (or a provider) wobbles. (Today’s DNS hiccup is exactly the kind of scenario this protects against.) Resilient data layers Replicate data asynchronously across clouds/regions; choose databases with cross‑region failover and test RPO/RTO quarterly. If you rely on a managed database tied to one region, design an escape hatch. Traffic and identity that float Use global traffic managers/DNS to shift users automatically; keep identity (MFA/SSO) highly available and not hard‑wired to a single provider’s control plane. Run the playbook Document health checks, automated cutover, and comms templates. Then practice —tabletops and live failovers. Many services today recovered within hours, but only teams with rehearsed playbooks avoided user‑visible downtime. The bottom line Cloud concentration risk is real. Outages will happen—what matters is whether your constituents, students, and staff feel it. A pragmatic multi‑cloud stance limits the blast radius and keeps your mission‑critical services online when one provider has a bad day. Need a resilience check? Akins IT can help you prioritize which systems should be multi‑cloud, design the right level of redundancy, and validate your failover plan—without overspending. Let’s start with a quick, 30‑minute review of your most critical services and RPO/RTO targets. (No slideware, just actionable next steps.)