It is Saturday night in Bengaluru. While most people are out roaming around the outer ring road or chilling in cafes, I made a conscious choice to sit at my desk, open up my terminal, and grind. I want to be part of that 1% crowd—the professionals who don’t just talk about growth but are genuinely curious, willing to put in the hours, and execute.
Over this intense weekend session, I successfully shattered my dependency on the visual Azure Portal (GUI), moved completely into command-line infrastructure automation, and expanded my secure digital sandbox into an enterprise-grade network topology.
Here is exactly how I built it, the real-world bugs I encountered, and the core architectural concepts broken down so simply that even a non-technical person can understand them.
🛑Day 4: Moving from "Pointing-and-Clicking" to Code
Up until yesterday, I built my cloud infrastructure by manually clicking buttons, menus, and checkboxes inside the Azure Portal web interface.
💡The Analogy: The Hand-Carved Bakery vs. The Smart Machine
The Manual Way (Days 1–3): Imagine baking a cake where you have to manually measure flour, crack every egg, and closely watch the oven dial. This works great for one cake. But what if a major corporate company in Whitefield orders 500 identical cakes for an event? If you try to do it all by hand, it will take forever, you will get exhausted, and some cakes will inevitably taste different due to human error.
The Automation Way (Day 4): Imagine programming a digital, industrial smart-mixer. You type in the exact measurements into a script once, press a button, and the machine perfectly outputs 500 identical cakes with zero errors.
In the cloud world, we call this Infrastructure as Code (IaC). Enterprise networks are massive; we cannot scale by clicking buttons in a browser. We use text-based scripts to deploy identical, flawless environments in seconds.
🛠️ The Simplified Command-Line Blueprint
I opened up the browser-based Azure Cloud Shell and used Azure CLI to fire up my infrastructure using tight, professional shortcut flags:
-g stands for the Resource Group (our logical container).
-n stands for the Name of our resource.
-l stands for the Location (Southeast Asia/Singapore datacenters).
Here are the exact three direct commands that built my perimeter security:
BASH
# 1. Create the Security Guard Shack (Network Security Group)
az network nsg create -g Marathahalli_Lab_RG -n Sec_Hub_SEA_NSG -l southeastasia
# 2. Program the Guard to strictly allow my home ISP IP on Port 22 (SSH)
az network nsg rule create -g Marathahalli_Lab_RG --nsg-name Sec_Hub_SEA_NSG -n Allow_SSH_Home_Only --priority 100 --source-address-prefixes 205.254.163.132 --destination-port-ranges 22
# 3. Create the Private Network and bind it to the Guard Shack instantly
az network vnet create -g Marathahalli_Lab_RG -n Sec_Hub_SEA_VNet -l southeastasia --address-prefixes 10.0.0.0/16 --subnet-name Management_SEA_Subnet --subnet-prefixes 10.0.1.0/24 --nsg Sec_Hub_SEA_NSG
🔍 The Day 4 Troubleshooting Story: Defeating the Location Clash
When I first ran my script, Azure halted everything and threw a glaring red error:
[InvalidResourceLocation] The resource 'Sec_Hub_VNet' already exists in location 'centralindia' in resource group 'Marathahalli_Lab_RG'. A resource with the same name cannot be created in location 'southeastasia'
The Lesson:
During my early labs, I had manually created a network named Sec_Hub_VNet inside India. Today, my script tried to create a new network with the exact same name inside Singapore, but within the same resource group wrapper.
Azure taught me an important architectural lesson here: While a single Resource Group can hold assets from different cities around the world, it absolutely cannot hold two items that share the exact same name.
The Fix: I modified my automation script variables, changing the name to Sec_Hub_SEA_VNet. The script instantly cleared the validation check and deployed flawlessly.
🏛️Deep-Dive Concept: How Firewalls Process Cloud Traffic
As a Network Security Engineer, I had to understand exactly how Azure evaluates firewall rules when we bind them programmatically.
In Azure, you can attach Network Security Groups (NSGs) at two distinct boundaries: the Subnet level (the whole road) and the NIC level (the specific house's front door).
💡The Analogy: The High-Security Corporate Tech Park
Imagine visiting a secure corporate client office in Marathahalli:
The Subnet Gate: First, you drive up to the main outer gate of the tech park. Security checks your vehicle. If you are on the list, they let you drive onto the campus (Allow).
The NIC Gate: Next, you walk up to the glass door of Building 3 inside that campus. The security guard at that specific door checks your ID badge and says, "You don't have access to this particular building" (Deny).
Result? You get dropped right there on the floor. You cannot enter. For a packet to reach an application, both security checkpoints must say "Allow".
INBOUND PACKET FLOW:
[Public Internet] ---> ( Subnet NSG: ALLOW ) ---> ( NIC NSG: DENY ) ---> [ Packet Dropped! ]
🚀Day 5: Scaling Out to a Hub-and-Spoke Topology
Once Day 4's automation was rock solid, I immediately jumped into Day 5 to scale my lab into a production-grade architecture. Enterprise companies do not dump everything into a single network. They isolate environments using a Hub-and-Spoke Topology.
💡The Analogy: The International Airport Terminal
The Hub (Sec_Hub_SEA_VNet): Think of this like the main central airport terminal building. This is where customs officers stand, passport control happens, and bags are scanned. Everything entering or leaving the airport must go through here.
The Spoke (Sec_Spoke_SEA_VNet): Think of this like the isolated airplane boarding gates far down the hallway. Gate A houses domestic flights; Gate B houses cargo. These gates do not need their own expensive customs setups; they rely entirely on the main central terminal (The Hub) to keep them secure.
📊 The Network Topology Map (Architecture Layout)
[ PUBLIC INTERNET ]
|
| (Strict Port 22 Lockdown Rule)
v
=================== HUB VNET (10.0.0.0/16) ===================
| |
| [ Sec_Hub_SEA_NSG ] ---> Applied to Subnet Layer |
| | |
| v |
| [ Management_SEA_Subnet ] (10.0.1.0/24) |
| |
==============================================================
| ^
| |
|-----> [ Hub-to-Spoke Peering ] ------|
| (Status: Connected) |
| |
|-----> [ Spoke-to-Hub Peering ] ------|
v |
================== SPOKE VNET (10.1.0.0/16) ==================
| |
| [ App_Prod_Subnet ] (10.1.1.0/24) |
| (Production Database / App Microservices workloads) |
| |
==============================================================
💻 Day 5 Code: Line-by-Line Technical Breakdown
To build this architecture, I executed three specific commands. Here is exactly what each line does under the hood:
- Creating the Spoke Network Space
`BASH
az network vnet create -g Marathahalli_Lab_RG -n Sec_Spoke_SEA_VNet -l southeastasia --address-prefixes 10.1.0.0/16 --subnet-name App_Prod_Subnet --subnet-prefixes 10.1.1.0/24
`
az network vnet create: Tells the Azure Resource Manager to carve out a new software-defined virtual network fabric.
-g Marathahalli_Lab_RG: Places this new network inside my existing resource group container.
-n Sec_Spoke_SEA_VNet: Names this specific network space our "Spoke".
--address-prefixes 10.1.0.0/16: Allocates a massive pool of over 65,000 private IPs. Critical detail: This does not overlap with our Hub network (10.0.0.0/16), completely preventing routing collisions.
--subnet-name App_Prod_Subnet --subnet-prefixes 10.1.1.0/24: Instantly slices out a subset corridor within the Spoke where our actual production application databases and web servers will live.
- Building the Walkway: From Hub to Spoke
`BASH
az network vnet peering create -g Marathahalli_Lab_RG --vnet-name Sec_Hub_SEA_VNet -n Hub-to-Spoke --remote-vnet Sec_Spoke_SEA_VNet --allow-vnet-access
`
az network vnet peering create: Tells Azure to construct a low-latency, private routing bridge directly across the Microsoft backbone network.
--vnet-name Sec_Hub_SEA_VNet: Specifies the starting point of our bridge (The Hub).
-n Hub-to-Spoke: Labels this directional leg of the bridge.
--remote-vnet Sec_Spoke_SEA_VNet: Connects the other end of the bridge straight into our Spoke network asset.
--allow-vnet-access: Programmatically permits the virtual machines inside the Hub to talk across this bridge natively.
- Completing the Two-Way Street: From Spoke to Hub
`BASH
az network vnet peering create -g Marathahalli_Lab_RG --vnet-name Sec_Spoke_SEA_VNet -n Spoke-to-Hub --remote-vnet Sec_Hub_SEA_VNet --allow-vnet-access
`
- Why this line is mandatory: In cloud architecture, a peering connection is not automatically bidirectional. It is a one-way street until you configure the return path. This command sets the starting point at the Spoke (--vnet-name Sec_Spoke_SEA_VNet) and maps it right back to the Hub (--remote-vnet Sec_Hub_SEA_VNet), completing the secure loop.
💰Financial Discipline Check
Since I only deployed logical networking paths, subnets, and routing bridges without provisioning any heavy virtual machine CPU power today, my automated environment runs at a cost of exactly ₹0 per hour. My Azure free trial credits remain 100% optimized and safe.
🏁Weekend Wrap-Up
This weekend was a massive leap forward. By stepping completely out of the comfort zone of the graphical portal, writing raw CLI scripts, conquering real-world resource location bugs, and standing up a verified Hub-and-Spoke enterprise topology, I am actively building the real-world skills needed to command senior cloud security roles.
The grind continues, where we will start hijacking these default routing paths using User-Defined Routes (UDRs) to force all traffic through a centralized firewall!
Onward and upward!🚀🔥
Top comments (0)