Forem: PETER Samuel

Implementing High Availability with Azure Traffic Manager: A Practical Guide

PETER Samuel — Mon, 13 Oct 2025 23:55:40 +0000

What We're Building

In this hands-on exercise, we'll create a high-availability solution for web applications using Azure Traffic Manager. Many organizations face the challenge of keeping their web applications available during regional outages or maintenance. We're going to solve this by deploying web apps across two different Azure regions and setting up automatic failover.

Our Approach

We'll work through four main tasks:

Creating web applications in two Azure regions

Setting up a Traffic Manager profile

Configuring endpoints for failover

Testing our high-availability setup

Task 1: Creating the Web Applications

Let's start by creating our first web application in the East US region.

Open the Azure portal and select "Create a resource," then choose "Web App." If you don't see it immediately, use the search box to find it.

Now we'll configure our first web app with these settings:

Subscription: Your Azure subscription

Resource group: Create new named "Contoso-RG-TM1"

Name: ContosoWebAppEastUS followed by your initials

Publish: Code

Runtime stack: ASP.NET V4.8

Operating system: Windows

Region: East US

Windows Plan: Create new named "ContosoAppServicePlanEastUS"

Pricing Plan: Standard S1

Click the "Monitoring" tab and select "No" for Application Insights to keep things simple for this exercise.

Review your settings and create the web app. Azure will now deploy your first web application.

Now let's create our second web app in West Europe for redundancy. Repeat the same process but with these different settings:

Resource group: Create new named "Contoso-RG-TM2"

Name: ContosoWebAppWestEurope followed by your initials

Region: West Europe

Windows Plan: Create new named "ContosoAppServicePlanWestEurope"

Task 2: Creating the Traffic Manager Profile

Now we'll create the Traffic Manager profile that will handle our traffic routing.

From the Azure portal home, select** "Create a resource"** and search for "Traffic Manager profile."

Click** "Create"** and configure the profile with these settings:

Name: TMProfile followed by your initials

Routing method: Priority

Subscription: Your subscription

Resource group: Contoso-RG-TM1

Resource group location: East US

Review and create the profile. This sets up our traffic management foundation.

To verify both web apps are ready, go to "All services" in the left navigation, select "Web," then "App Services." You should see both web applications listed.

Task 3: Adding Traffic Manager Endpoints

With our Traffic Manager profile ready, we need to connect our web apps as endpoints.

Find your Traffic Manager profile in "All resources" and select it. Under** "Settings,"** choose "Endpoints," then click "Add."

Configure our primary endpoint:

Type: Azure endpoint

**Name: **myPrimaryEndpoint

Target resource type: App Service

Target resource: ContosoWebAppEastUS (East US)

Priority: 1

Click** "Add"** to create the primary endpoint.

Now let's add our failover endpoint using the same process:

**Name: **myFailoverEndpoint

Target resource: ContosoWebAppWestEurope (West Europe)

Priority: 2

The priority setting means traffic will automatically route to our West Europe endpoint if the primary East US endpoint becomes unhealthy.

For better security, let's update the monitoring settings. Go to "Configuration" under Settings, change the protocol to HTTPS and port to 443, then save.

After a few minutes, both endpoints should show "Online" status, indicating they're ready to handle traffic.

Task 4: Testing Our Traffic Manager Setup

Now for the exciting part - testing our high-availability solution!

Go to your Traffic Manager profile overview and copy the DNS name.

Open a new browser tab and paste the DNS name (contoso-tmprofile.trafficmanager.net) into the address bar.

If you see a 404 error, don't worry - this is common with new web apps.

Simply disable and re-enable the profile from the overview page, then refresh.

Currently, all traffic is routing to our primary East US endpoint because we set it to priority 1.

Now let's test our failover capability. We'll simulate an outage by disabling the primary endpoint.

On the Traffic Manager overview, click the number "2" next to Endpoints.

Find myPrimaryEndpoint and click the edit (pencil) icon.

Uncheck "Enable Endpoint" and save.

The primary endpoint should now show as disabled.

Open a new browser session and navigate to your Traffic Manager DNS name again. You should still see your web application working, but now it's being served from the West Europe endpoint!

Cleaning Up

When you're finished testing, remember to clean up your resources to avoid ongoing charges.

Open Cloud Shell in the Azure portal and run:

text
Remove-AzResourceGroup -Name 'Contoso-RG-TM1' -Force -AsJob
Remove-AzResourceGroup -Name 'Contoso-RG-TM2' -Force -AsJob

What We Learned

Through this exercise, we've built a robust high-availability solution that can automatically handle regional outages. The key takeaways are:

Azure Traffic Manager provides DNS-level load balancing across global regions

Priority routing ensures traffic goes to your preferred endpoints first

Automatic health monitoring and failover keep your applications available

Geographic redundancy protects against regional disruptions

This solution is particularly valuable for e-commerce sites, business applications, and any service where downtime means lost revenue or productivity.

Next Steps

If you want to explore further, consider:

Trying different routing methods like weighted or geographic routing

Adding custom domains and SSL certificates

Setting up monitoring and alerts for your endpoints

Implementing nested Traffic Manager profiles for complex scenarios

Remember, the best disaster recovery plan is one you've tested thoroughly - and now you have the skills to build and test these solutions in Azure.

Mastering High Availability: My Azure Load Balancer Implementation Journey

PETER Samuel — Wed, 01 Oct 2025 16:45:36 +0000

The Challenge: Ensuring Application Reliability

In today's digital landscape, application downtime is not an option. Whether you're running an e-commerce platform, internal business applications, or customer-facing services, a single server failure can mean lost revenue, decreased productivity, and damaged reputation.

This was the challenge I set out to solve by implementing Azure's Internal Load Balancer - a solution that ensures applications remain available even when individual servers fail.

Understanding Load Balancing
At its core, load balancing is about distributing network traffic across multiple servers. Think of it like a traffic controller at a busy intersection:

Without load balancer: One server handles all traffic (single point of failure)

With load balancer: Traffic automatically routes to available servers (high availability)

My Implementation Approach

Building the Foundation: Virtual Network
I started by creating a secure network environment:

Virtual Network: IntLB-VNet with IP range 10.1.0.0/16

Segmented Subnets:

Backend subnet (10.1.0.0/24) for web servers

Frontend subnet (10.1.2.0/24) for load balancer

Bastion subnet for secure management

This segmentation follows security best practices, separating different components into their own network spaces.

Creating the Backend Servers

Instead of using automated templates, I manually created three virtual machines to better understand the process:

web1, web2, web3 - Identical Windows Server configurations

Availability Set: Ensures VMs are distributed across multiple physical servers

No Public IPs: Enhanced security through internal-only access

The manual creation process, while more time-consuming, provided valuable insights into Azure VM configuration and networking.

Installing Web Servers

Each VM required individual configuration:

Secure Connection: Using Azure Bastion for browser-based remote access

IIS Installation: PowerShell commands to install web server functionality

Custom Test Pages:

web1: "Hello from Web Server 1"

web2: "Hello from Web Server 2"

web3: "Hello from Web Server 3"

This hands-on approach revealed how enterprise applications are typically deployed across multiple servers.

The Load Balancer Configuration

Key Components Created:

Backend Pool: Group containing all three web servers

Health Probe: Regular checks to ensure servers are responsive

Load Balancing Rule: Distributes HTTP traffic on port 80

Frontend IP: Internal IP address (10.1.0.7) for accessing the service

Why Internal Load Balancer?
I chose an internal load balancer because:

The application doesn't need direct internet access

Enhanced security through network isolation

Perfect for internal business applications

Cost-effective compared to public load balancers

Testing and Validation

The most exciting part was testing the solution:

Connected to a test VM within the same network

Accessed the load balancer IP (10.1.0.7)

Observed traffic distribution across all three servers

The magic happened when refreshing the browser - each request was served by a different backend VM, demonstrating perfect load distribution.

Building Azure's Private Cloud Highway: My ExpressRoute Implementation

PETER Samuel — Mon, 29 Sep 2025 10:13:55 +0000

The Challenge of Cloud Connectivity
Many businesses face a critical problem when moving to the cloud: how to connect their offices to Azure securely and reliably. Standard internet connections expose sensitive data to risks and suffer from unpredictable performance. This becomes especially critical for financial institutions, healthcare organizations, and enterprises handling large data transfers.

Discovering the Solution: Azure ExpressRoute
During my Azure networking certification journey, I implemented ExpressRoute - Microsoft's solution for private cloud connectivity. Unlike traditional VPNs that use the public internet, ExpressRoute creates a dedicated private connection between your network and Azure.

What Makes ExpressRoute Different
ExpressRoute bypasses the public internet entirely. Your data travels through a dedicated connection provided by partners like Equinix, AT&T, or Verizon. This approach offers three key advantages:

Enhanced Security: Data never touches the public internet

Predictable Performance: Consistent latency and throughput

Higher Reliability: 99.95% uptime guarantee

My Implementation Journey

Step 1: Creating the Resource Group

I started by creating the foundational resource group in East US 2 region:

Resource Group Name: ExpressRouteResourceGroup

Location: East US 2

This resource group served as the container for all ExpressRoute components, ensuring organized management and clean resource grouping.

Step 2: Leveraging Existing Virtual Network
Since I already had the virtual network infrastructure in place, I used my existing virtual network:

Virtual Network: CoreServicesVNet

This approach reflects real-world scenarios where organizations build on existing Azure networking infrastructure

Step 3: Creating the ExpressRoute Circuit

With the foundation in place, I configured the ExpressRoute circuit with these specifications:

Resource Group: ExpressRouteResourceGroup

Provider: Equinix

Peering Location: Seattle

Bandwidth: 50 Mbps

SKU: Standard

Location: East US 2

This circuit represents the logical connection that will eventually link to physical infrastructure.

Step 4: The Critical Service Key

After creating the circuit, I retrieved the service key - a unique identifier that connects Azure with the connectivity provider. This key must be shared with your provider to initiate the physical circuit provisioning.

The Reality of Enterprise Connectivity
Here's what most people don't realize: creating the ExpressRoute circuit in Azure is only the beginning. The provider status shows "Not provisioned" because the physical infrastructure hasn't been built yet.

In the real world, this triggers a 30-60 day process where providers like Equinix:

Build dedicated fiber optic connections

Establish cross-connects at peering locations

Test end-to-end connectivity

Hand off to Microsoft

Why This Matters for Businesses
For organizations handling sensitive data or requiring guaranteed performance, ExpressRoute transforms cloud operations:

Financial institutions can process transactions with consistent low latency
Healthcare organizations can transfer patient data while maintaining compliance
Global enterprises can connect offices worldwide with reliable performance

Key Implementation Insights
The implementation taught me several crucial lessons:

Start with proper resource group organization in your target region

ExpressRoute integrates seamlessly with existing virtual networks

Plan ahead: ExpressRoute provisioning takes time

Choose providers strategically based on your locations

Monitor both provider and circuit status during deployment

The Business Impact
While ExpressRoute requires more planning and investment than standard connections, the benefits justify the cost for enterprises where downtime means lost revenue or security breaches mean regulatory penalties.

This infrastructure isn't just about technology - it's about building the foundation for digital transformation at scale.

Configuring Azure ExpressRoute Gateway: A Step-by-Step Guide with Real-World Benefits

PETER Samuel — Fri, 26 Sep 2025 10:14:22 +0000

Introduction
In today's hybrid cloud environments, secure and reliable connectivity between on-premises infrastructure and cloud services is crucial. Azure ExpressRoute provides a dedicated private connection that bypasses the public internet, offering enhanced security, reliability, and performance. In this comprehensive guide, I'll walk you through configuring an ExpressRoute Gateway based on Microsoft's AZ-700 certification lab.

Why ExpressRoute Matters in Modern Enterprises
The Problem with Traditional Internet Connections
Many organizations initially connect to Azure using VPN over the public internet, which presents several challenges:

Security Concerns: Data traversing public networks is vulnerable to interception

Unpredictable Performance: Internet congestion leads to variable latency and throughput

Limited Reliability: Typical SLAs of 99.9% may not meet enterprise requirements

Bandwidth Constraints: Shared internet connections can't guarantee consistent performance

The ExpressRoute Solution
Azure ExpressRoute addresses these challenges by providing:

Private Connectivity: Dedicated circuit between your network and Azure

Enhanced Security: Data never touches the public internet

Predictable Performance: Consistent latency and throughput guarantees

Higher Availability: 99.95% SLA for dedicated connections

Global Reach: Connect across regions with ExpressRoute Global Reach

Lab Environment Setup
Prerequisites
Before we begin, ensure you have:

Azure subscription with appropriate permissions

Basic understanding of Azure networking concepts

Approximately 60 minutes for deployment (including 45-minute gateway wait time)

Step 1: Creating the Virtual Network and Gateway Subnet
The Foundation: Virtual Network (VNet)

azurecli

Create the resource group

az group create --name ContosoResourceGroup --location eastus

Implementation Steps:
Navigate to Virtual Networks

Search "virtual network" in Azure Portal

Select "Virtual networks" from results

Create New Virtual Network

Basics Tab:

Name: CoreServicesVNet

Resource Group: ContosoResourceGroup

Region: East US

Configure IP Address Space

IPv4 address space: 10.20.0.0/16

Click "+ Add subnet" for gateway configuration

Create Gateway Subnet

Subnet purpose: Virtual Network Gateway

Address space: 10.20.0.0/27

Critical Note: The subnet name automatically populates as GatewaySubnet

Validate and Create

Review configuration

Click "Create" after validation passes

Common Challenges & Solutions:
Challenge **Solution**
IP address conflicts Use non-overlapping CIDR ranges (10.20.0.0/16)
Subnet size too small Gateway subnet requires /27 or larger
Region availability issues Choose regions with ExpressRoute support

Step 2: Creating the Virtual Network Gateway
Understanding Gateway Types
Azure offers two primary gateway types:

Gateway Type Use Case Key Characteristics
VPN Gateway Internet-based encrypted connections Lower cost, easier setup
ExpressRoute Gateway Private dedicated connections Higher performance, enhanced security
Implementation Steps:
Navigate to Virtual Network Gateways

Search "virtual network gateway" in Azure Portal

Select "Virtual network gateways" from results

Create New Gateway

Click "+ Create" to start configuration

Configure Gateway Settings

Project Details:

Resource Group: ContosoResourceGroup

Instance Details:

Name: CoreServicesVnetGateway

Region: East US

Gateway type: ExpressRoute ⚠️ (Critical selection!)

SKU: Standard

Virtual network: CoreServicesVNet

Subnet: GatewaySubnet (auto-populated)

Validation and Deployment

Click "Review + create"

Wait for validation (green checkmark)

Click "Create" to start deployment

The 45-Minute Wait: What's Happening?
During this extended deployment period, Azure is:

Provisioning dedicated infrastructure for your gateway

Establishing routing infrastructure within Azure backbone

Configuring high-availability components

Setting up management and monitoring capabilities

Real-World Benefits and Use Cases
Enterprise Scenario: Financial Services Company
Challenge: A financial institution needed secure, low-latency connectivity for real-time trading applications between their data center and Azure.

Solution: Implemented ExpressRoute with Standard SKU gateway.

Results:

Latency reduced from 45ms (VPN) to 8ms (ExpressRoute)

Achieved 99.95% uptime guarantee

Met regulatory compliance requirements for data protection

Healthcare Organization Use Case
Requirement: Secure transfer of patient data between hospital networks and Azure for AI-powered diagnostics.

Benefits Realized:

HIPAA compliance through private connectivity

Consistent performance for large medical imaging transfers

Enhanced security for sensitive patient data

Key Configuration Considerations
SKU Selection Guide
SKU Maximum Connections BGP Routes Typical Use Cases
Standard 4 4,000 Medium enterprises, dev/test
High Performance 4 4,000 Production workloads
Ultra Performance 16 10,000 Large enterprises, mission-critical
Cost Optimization Strategies
Right-size your gateway: Choose appropriate SKU for your needs

Monitor utilization: Use Azure Monitor to track performance

Consider hybrid approach: Combine ExpressRoute with VPN for backup

Troubleshooting Common Issues
Deployment Failures
Problem: Gateway deployment fails after 45 minutes
Solution:

Verify VNet and subnet exist

Check resource group permissions

Ensure region supports ExpressRoute

Connectivity Issues
Problem: Gateway deployed but no connectivity
Solution:

Verify ExpressRoute circuit provisioning

Check BGP peering configuration

Validate route filters and network security groups

Advanced Features to Explore
ExpressRoute Global Reach
Enable direct connectivity between on-premises sites through Azure backbone, reducing latency and costs for multi-site organizations.

ExpressRoute FastPath
Bypass the gateway for improved performance for traffic within the same virtual network.

Monitoring and Management Best Practices
Set up alerts for gateway health metrics

Implement Azure Monitor for performance tracking

Use Network Watcher for troubleshooting connectivity issues

Regularly review utilization and performance metrics

Conclusion
Configuring an Azure ExpressRoute Gateway is a critical skill for cloud architects and network engineers. While the 45-minute deployment time requires patience, the benefits of dedicated, secure connectivity justify the investment for production workloads.

Key Takeaways:
ExpressRoute provides superior performance and security compared to VPN

Proper subnet planning is crucial for successful deployment

Gateway SKU selection impacts both performance and cost

Monitoring and management are essential for maintaining optimal performance

By following this guide, you've taken a significant step toward mastering Azure networking solutions and preparing for the AZ-700 certification.

Next Steps
Practice with different SKU types to understand performance characteristics

Explore ExpressRoute Direct for massive data transfer requirements

Experiment with coexistence of ExpressRoute and VPN for hybrid scenarios

Study route filtering and network security integration

This article is based on Microsoft's AZ-700 Designing and Implementing Microsoft Azure Networking Solutions certification materials. All screenshots and configurations are from hands-on lab experience.

Tags: #Azure #ExpressRoute #Networking #CloudComputing #AZ700 #DevOps #HybridCloud

Skill Level: Intermediate

Time Required: 60 minutes (including deployment time)

From Zero to Cloud Network Hero: My AZ-700 Virtual WAN Lab Journey

PETER Samuel — Thu, 25 Sep 2025 09:19:37 +0000

The Moment Everything Clicked

"I'm supposed to create my Virtual WAN in East US but then put the hub in West US? That seems backwards..."

That was my initial confusion when I started the AZ-700 Virtual WAN lab. As someone relatively new to Azure networking, the concepts felt abstract until I actually built something hands-on. In this article, I'll take you through my journey from confusion to clarity, complete with screenshots and practical explanations.

What Even is Azure Virtual WAN? (And Why Should You Care)
Before we dive into the lab, let me save you the confusion I experienced. Azure Virtual WAN is essentially Microsoft's answer to complex global networking.

Think of it like this:

Traditional networking: Building individual roads between every city (manual, complex)

Virtual WAN: Creating a highway system with on-ramps everywhere (automated, scalable)

The Problem It Solves:
Imagine your company has offices in Seattle, New York, and London. Each needs to connect to Azure resources securely. Without Virtual WAN, you'd be configuring VPNs and routes manually for each location. With Virtual WAN, it's all managed through a single interface.

Lab Scenario: Building Contoso's Global Network
Our mission: Create a Virtual WAN for Contoso that can connect their West Coast research team to Azure resources efficiently.

Task 1: Creating the Virtual WAN - Laying the Foundation

What I Actually Did:
Created a Virtual WAN named ContosoVirtualWAN

Selected Standard type for full functionality

Chose a resource group to keep everything organized

The "Aha!" Moment:
The Virtual WAN itself isn't a physical thing living in a data center. It's a global management overlay - think of it as the mission control center that will coordinate all our networking components across different regions.

Why This Step Matters:
This single resource becomes the brain of our entire network operation. Instead of managing multiple disconnected networks, we now have one pane of glass for global connectivity.

Task 2: Creating the Virtual Hub - The Regional Gateway

What I Actually Did:
Created a hub named ContosoVirtualWANHub-WestUS

Placed it in West US (strategic for West Coast users)

Allocated IP space 10.60.0.0/24 for the hub

Enabled Site-to-site VPN capabilities

The "Aha!" Moment:
Here's where the East US/West US confusion cleared up! The Virtual WAN is the global manager, while the hub is the regional connector. They can be in different regions because they serve different purposes.

Real-World Benefit:
If Contoso has a research team in Seattle, they connect directly to the West US hub instead of routing through Virginia. This means:

✅ Lower latency for West Coast users

✅ Better performance for real-time applications

✅ Redundancy if East US has issues

The Waiting Game:
This step takes about 30 minutes because Azure is provisioning actual VPN gateways behind the scenes. Perfect time for a coffee break! ☕

Task 3: Connecting the VNet - Bringing Cloud Resources Online

What I Actually Did:
Connected ResearchVNet to our Virtual Hub

Named the connection ContosoVirtualWAN-to-ResearchVNet

Configured route propagation

The "Aha!" Moment:
This is where the magic happens! By connecting the Virtual Network to our hub, we're essentially creating an on-ramp to our global highway system. Any resource in ResearchVNet can now communicate securely with any other connected resource.

What Azure Handles Automatically:
Route propagation between regions

Security policy enforcement

Optimal path selection

Traffic encryption

Business Impact:
Researchers can now access their tools and data as if they're on the same local network, regardless of where they're physically located.

🧹 The Most Important Step: Cleanup!

Why I Almost Skipped This:
"I'm learning, why worry about cleanup?" Then I remembered: Azure resources cost money when they're running!

What I Did:
Navigated to Resource Groups

Selected ContosoResourceGroup

Clicked "Delete resource group"

Typed the name to confirm

Watched everything disappear (satisfying!)

Pro Tip:
Always set up budget alerts in your Azure subscription. It's easy to forget about running resources when you're focused on learning.

💡 Key Takeaways From My Journey

Global vs Regional Thinking: Virtual WAN = Global management plane (the strategy)

Virtual Hub = Regional execution point (the tactics)

2.** Automation is Powerful**:
What would take days of manual configuration now happens with a few clicks. Azure handles the complex routing behind the scenes.

Performance Matters: Placing hubs close to users isn't just nice-to-have—it's critical for modern applications.

4.** Cost Awareness**:
Always clean up your learning environments. Cloud resources aren't free!

🚀** Ready to Start Your Own Journey?**
This lab transformed my understanding of cloud networking from theoretical to practical. The best part? You can recreate this exact experience through Microsoft's free learning resources.

Next Steps for Your Learning:
Try creating multiple hubs in different regions

Experiment with Point-to-site VPN for remote users

Explore ExpressRoute for dedicated private connections

Challenge Yourself:
What networking problems does your organization face? How could Virtual WAN solve them?

📚 Resources That Helped Me:
Microsoft Learn AZ-700 Path

Azure Virtual WAN Documentation

Cloud Skills Challenge: Azure Networking

Mastering Azure VNet Peering: How I Connected Isolated Cloud Networks Like a Pro

PETER Samuel — Wed, 24 Sep 2025 13:28:45 +0000

The "Aha!" Moment That Changed Everything

I'll never forget the moment I ran Test-NetConnection after setting up VNet peering and saw TcpTestSucceeded: True - after hours of failed connections, everything finally worked! Here's my real journey through Azure networking, complete with screenshots of every step.

Step 1: Setting Up My Test Environment (The Manual Way)
Why I Ditched the Templates:
The lab provided ARM templates, but I chose manual creation to really understand what was happening behind the scenes.

What I Actually Did:

Created TestVM in ManufacturingVnet:

Resource Group: ContosoResourceGroup

Location: UK West (to match my VNet)

Virtual Network: ManufacturingVnet

Subnet: default (10.30.0.0/24)

Verified TestVM1 in CoreServicesVnet:

Already existed from previous lab

Step 2: The RDP Struggle & Finding Better Solutions

The Problem Every Azure Admin Faces:
RDP connections failed repeatedly with that frustrating "can't connect" message.

My Workaround That Actually Worked Better:
Discovered Azure Run Command:

TestVM → Operations → Run command → RunPowerShellScript

Used Serial Console as Backup:

Perfect for when RDP fails

Direct command-line access

Step 3: The Baseline Test - Proving Isolation

Getting TestVM1's IP:
powershell
ipconfig

The Expected Failure:
powershell
Test-NetConnection 10.20.20.4 -port 3389

This proved the networks were completely isolated - which was exactly what we expected at this stage.

Step 4: Building the Network Bridge - VNet Peering
The Magic Configuration:

CoreServicesVnet → Peerings → + Add:

Peering link name: ManufacturingVnet-to-CoreServicesVnet

Virtual network: ManufacturingVnet

Allow access: Enabled

Automatic Reverse Peering Created:

CoreServicesVnet-to-ManufacturingVnet

Clicked "Sync" and Watched the Status Change:

From "Initiated" to "Connected"

Step 5: The Moment of Truth - Testing Connectivity
Running the Exact Same Command:
powershell
Test-NetConnection 10.20.20.4 -port 3389
The Beautiful Result:
text
TcpTestSucceeded: True
ComputerName: 10.20.20.4
RemotePort: 3389

Step 6: Cleanup & Cost Management

Removing Resources Properly:
powershell
Remove-AzResourceGroup -Name 'ContosoResourceGroup' -Force -AsJob

Key Lessons That Made Me a Better Cloud Engineer

Technical Insights:

Manual configuration > templates for learning

Run Command is incredibly powerful for administration

Peering must be bidirectional to work properly

Business Value Realized:
Cost savings by eliminating VPN gateways

Performance boost through Azure backbone

Security enhancement with private connectivity

Why This Matters for Your Organization
If you're managing multiple Azure environments, VNet peering isn't just technical - it's business-critical for:

Application integration between different teams

Hybrid cloud strategies

Compliance and security requirements

Ready to Help Others Succeed
I'm passionate about making cloud networking accessible. If your organization is facing similar challenges, I'd love to:

Share more detailed configurations

Help troubleshoot specific scenarios

Collaborate on Azure networking projects

What networking challenges are you facing? Share your experiences below!

Simplifying Azure Private DNS: How I Made Cloud Networking Easy Enough for Anyone to Understand

PETER Samuel — Mon, 22 Sep 2025 14:24:24 +0000

The Problem: Cloud Networking Can Be Confusing

When I first looked at Azure Private DNS, the technical documentation felt like reading a foreign language. Terms like "DNS zones," "auto-registration," and "name resolution" made my head spin. But as I worked through the AZ-700 lab, I discovered something important: this isn't as complicated as it looks.

What I Actually Did (In Plain English)
The Goal: Create a Private "Phone Book" for Azure VMs
Imagine you have two computers in your office. Instead of remembering their complex IP addresses (like 192.168.1.15), you want to call them by name ("Accounting-PC" and "HR-PC"). That's exactly what I set up in Azure.

My Simple 4-Step Process:
Step 1: Created the "Phone Book" (Private DNS Zone)

Made a private directory called "contoso.com"

Think of this as creating a company address book that only internal employees can access

Step 2: Connected the Network (Virtual Network Link)

Linked my Azure network to this phone book

Turned on "auto-registration" - meaning new computers automatically get listed

Step 3: Added Computers (Virtual Machines)

Created two servers: vm1 and vm2 (I named them simply instead of TestVM1/TestVM2)

Important: I created these manually to show it works regardless of method

Step 4: Tested the System

From vm1, I tried to "call" vm2 using its name: ping vm2.contoso.com

The call didn't connect (firewall blocked it - which is good for security!)

But when I checked the "phone book" lookup: nslookup vm2.contoso.com - it worked perfectly!

Why This Matters for Businesses

For CEOs and Decision Makers:
Cost Savings: No more maintaining expensive on-premises DNS servers

Security: Private DNS zones are only accessible within your Azure network

Simplicity: New servers automatically register themselves - zero manual work

For IT Teams:
Consistency: Same familiar DNS concepts, but in the cloud

Reliability: Azure handles the infrastructure maintenance

Integration: Works seamlessly with existing Azure services

The "Aha!" Moment
The breakthrough came when I realized: This isn't about technology - it's about communication. Whether you're using automated templates or manual creation (like I did with vm1/vm2), the principle remains the same: make internal networking as simple as using contacts in your phone.

What Organizations Should Take Away
You don't need to be a cloud expert to implement basic Azure networking

Manual configuration works just as well as automated templates - choose what your team is comfortable with

Private DNS is like building your company's internal directory - essential for organized communication

Your Turn to Comment
I'd love to hear from other professionals:

CEOs: What networking challenges is your organization facing?

IT Managers: Have you implemented similar solutions? What was your experience?

Beginners: What parts of this explanation helped you understand? What's still confusing?

The biggest lesson? Cloud networking doesn't have to be complicated when you break it down into human terms.

Designing a Global Azure Network Infrastructure: A Hands-On Guide to the AZ-700

PETER Samuel — Fri, 19 Sep 2025 13:43:37 +0000

Step into the role of a Network Engineer at Contoso Ltd. and learn how to design and implement a scalable, secure, and globally distributed network in Microsoft Azure. This practical walkthrough covers the core skills tested in the AZ-700 certification.

Introduction: Why This Project Matters

Ever wondered how large enterprises structure their cloud networks for performance, security, and growth? It all starts with a robust Virtual Network (VNet) design.

In this guide, I'll take you through a real-world scenario: migrating the fictional company Contoso Ltd. to Azure. You'll get hands-on experience designing and implementing a global network infrastructure from the ground up, which is a fundamental skill for the AZ-700: Designing and Implementing Microsoft Azure Networking Solutions certification.

By the end of this article, you'll understand not just how to click buttons in the Azure portal, but why each decision is critical for building a resilient cloud environment.

The Blueprint: Contoso's Global Network Scenario
Before a single resource is created, a successful cloud migration requires a solid architectural plan. For Contoso Ltd., this meant designing a global network that would support diverse business units with varying needs for scale, security, and connectivity. Our blueprint is built on three core virtual networks, each serving a distinct strategic purpose.

1.** CoreServicesVnet** (East US | 10.20.0.0/16)
This network is the beating heart of Contoso's IT infrastructure in Azure. Hosted in the East US region, it's designed to be the central hub for mission-critical applications. It will house:

Public-facing web services and applications.

Sensitive database servers containing company and customer data.

Shared services like Active Directory domain controllers and DNS servers that other networks will depend on.

A future VPN gateway for secure hybrid connectivity back to the on-premises datacenter.

The large /16 address space was chosen deliberately to accommodate significant anticipated growth and complex subnetting, ensuring we never run out of IP addresses for core services.

ManufacturingVnet (West Europe | 10.30.0.0/16)
Located in West Europe to be near Contoso's physical manufacturing plants, this network is engineered for the Internet of Things (IoT). Its primary function is to handle a massive influx of data from countless sensors on the factory floor, monitoring everything from temperature to assembly line efficiency. The /16 address space provides the immense scale needed to segment these devices into multiple dedicated subnets, allowing for better traffic management and security isolation.
ResearchVnet (Southeast Asia | 10.40.0.0/16)
This network supports the innovation engine of Contoso: the Research & Development team. Deployed in Southeast Asia to be close to this team, it has a simple, stable requirement. The small R&D team needs a secure environment for a predictable number of virtual machines used for testing and development. The /16 space might seem oversized, but it follows best practices for future-proofing and consistency, even if the current need is only a single subnet.

The Golden Rule: A Non-Overlapping Architecture
The entire design hinges on one critical rule: no address space can overlap. The on-premises network (10.10.0.0/16) and the three Azure VNets (10.20.0.0/16, 10.30.0.0/16, 10.40.0.0/16) are all completely separate. This careful planning is what will allow us to connect them all together in the future via peering and gateways without any routing conflicts, creating a seamless, global hybrid network.

Task 1: Laying the Foundation - The Resource Group
Think of a Resource Group as a logical container for your project. It's a best practice to group related resources for easier management, cost tracking, and cleanup.

Steps:

In the Azure Portal, search for and select Resource groups.

Click + Create.

Basics Tab:

Subscription: Choose your subscription

Resource Group: ContosoResourceGroup

Region: (US) East US (We place the group in the same region as our most critical VNet for metadata latency, but it can manage resources in any region).

Why This Matters: Using a single resource group for this project provides a unified management plane for all networking components, making it easy to monitor costs and apply policies.

Task 2: Building the HQ - CoreServicesVnet and Subnets
This is our most complex VNet, requiring careful subnet planning for security and functionality.

Creating the VNet:

Search for and select Virtual networks.

Click + Create.

Basics Tab:

Resource Group: ContosoResourceGroup

Name: CoreServicesVnet

Region: (US) East US

IP Addresses Tab:

IPv4 Address Space: 10.20.0.0/16

The Art of Subnet Design: Now, we segment this large address space into smaller, purpose-driven subnets. This is crucial for applying Network Security Groups (NSGs) and routing rules.

GatewaySubnet (10.20.0.0/27):

Purpose: Virtual Network Gateway. This is a reserved name! Azure requires this specific subnet to deploy a VPN or ExpressRoute gateway later to connect to on-premises networks.

Size: /27 (32 addresses). This is the minimum recommended size to accommodate future gateway SKUs.

SharedServicesSubnet (10.20.10.0/24): For domain controllers, DNS servers, and other infrastructure VMs. This subnet will have strict NSGs.

DatabaseSubnet (10.20.20.0/24): For database servers. This subnet will have the most restrictive NSGs, likely denying all traffic except from the web service subnet.

PublicWebServiceSubnet (10.20.30.0/24): For web servers facing the public internet. This subnet will have NSGs allowing HTTP/HTTPS traffic.

Pro Tip: Notice the logical IP numbering scheme (.10.x, .20.x, .30.x). This isn't required, but it makes management and troubleshooting much easier!

Task 3 & 4: Deploying Regional VNets (Manufacturing & Research)

The process is repeated for the other VNets, but the subnet design reflects their different purposes.

ManufacturingVnet (10.30.0.0/16) in West Europe:
This network anticipates massive growth from IoT sensors.

Subnets:

ManufacturingSystemSubnet (10.30.10.0/24): For the systems controlling the operations.

SensorSubnet1 (10.30.20.0/24)

SensorSubnet2 (10.30.21.0/24)

SensorSubnet3 (10.30.22.0/24)

Benefit: Using multiple smaller subnets for sensors allows for fine-grained traffic control and isolation. If one sensor network has an issue, it can be contained.

ResearchVnet (10.40.0.0/16) in Southeast Asia:
A simple, small network for a stable team.

Subnet:

ResearchSystemSubnet (10.40.0.0/24): A single subnet for all resources. This is cost-effective and simple for a small, trusted team.

Task 5: Verification - The Most Important Step
A good engineer always verifies their work.

Go to All resources and confirm all three VNets are listed.

Click into each VNet, navigate to Subnets under Settings, and verify:

All subnets are present.

The address ranges are exactly as designed. A typo here could cause major problems later!

Key Takeaways and Benefits

This project taught me to:

Think in Layers: From the broad resource group down to the precise /27 subnet.

Design for Purpose: Subnets are security boundaries. Their design should reflect the security and connectivity requirements of the resources within them.

Plan for Growth: Choosing large enough address spaces (like /16) prevents a painful redesign down the line.

Embrace Global Scale: Azure makes it simple to deploy consistent, secure networks across the globe, bringing applications closer to users.

This architecture is the foundation for everything else: connecting these VNets via VNet Peering, deploying firewalls, setting up load balancers, and achieving a truly hybrid network. Mastering this is the first and most critical step toward Azure networking expertise.

Let's Connect!

I'm passionate about cloud networking and always open to discussing design patterns, troubleshooting, and the journey towards certifications like the AZ-700. Feel free to leave a comment or connect with me on LinkedIn.

What Azure networking topic should I deep-dive into next? Peering? Network Security Groups? Let me know below! 👇

Hiring Your First Employee on AWS — Create an IAM User, Policies & Roles

PETER Samuel — Thu, 11 Sep 2025 11:10:49 +0000

Using the root account is like the CEO mopping the floors: possible, but neither safe nor efficient. In this guide we’ll hire your first "digital employee" — create an IAM user, give them permissions, and teach a server how to do its job without a password. I’ll walk you through practical labs, real-world explanations, and little stories so the steps stick.

Note: You mentioned you already have annotated screenshots for each step — great! I added image placeholders where you can drop them in the final draft.

Hiring Your First Employee: Creating an IAM User

Imagine Joy, the CEO of a small but growing company. Joy knows she shouldn't share the root account (the master keys). Instead she hires Samuel — a real person — and gives Samuel a proper employee identity. That identity has a console password so Samuel can log in, and (optionally) programmatic keys if Samuel needs CLI or SDK access.

Why not use the root account?

The root account has full power. If it’s compromised, everything is compromised.

Root access should be reserved for account-level tasks (billing, closing the account, etc.).

Using IAM users lets you apply the principle of least privilege: give people only what they need.

Practical Lab: Creating Your Digital Identity

Before you start: Log in using the root account, or an IAM user with permission to create users.

In the AWS Console, open the IAM service and click Users.

This is where you manage human identities and machine identities.

Click Create user.

You’ll be prompted for a username and credential types.

Enter a username, e.g., Alice.

Use clear, real names where possible (Alice.Smith) for accountability.

Select AWS credential types:

AWS Management Console access — gives a console (web) password so Alice can login.

*Programmatic access *(optional) — creates an access key pair for CLI/SDK. Only enable if truly needed.

Why separate? Console access is for humans using a browser. Programmatic access is for scripts and automated tools.

Click Next: Permissions.

This is where you attach permissions via groups, policies, or inline policies.

Add the user to a group. Click Create group.

Groups are the easiest way to manage sets of permissions.

Enter group name: Admin. Search for and select AdministratorAccess.

For the lab we use AdministratorAccess so you can test workflows. In production prefer more restrictive groups.

Security note: Avoid making every user an admin. Create role-based groups (Dev, Ops, Billing) with only necessary permissions.

Click Create group, then select the Admin group.

Now **Samuel **inherits whatever permissions the Admin group has.

Click Next: Tags (skip for now), then Next: Review.

Tags can help with billing, auditing, and automation. Consider adding team or project tags later.

Review settings and click Create user.

Download the .csv file. It contains the login details and keys. Store it securely.

The .csv includes: IAM sign-in link, username, password (temporary if auto-generated), and access keys if you enabled programmatic access.

Security tip: This file is shown only once. If you lose it, delete keys and create new ones or reset the console password.

Log out of the root account.

Log back in as Samuel using the IAM user sign-in link (found on the IAM Dashboard).

Enter the temporary password from the .csv file, then set a new password.

If you checked Require password reset, Alice will be forced to set a new password at first login. This is a recommended best practice.

You are now logged in as an IAM User with safer credentials.

Quick Story Recap: Joy created Alice, downloaded the CSV, delivered it securely, and Alice logged in and set her own password. Root stays quiet and secure.

** IAM Policies**

Analogy: Think of an IAM policy as a rulebook for what an employee can or cannot do. Policies are JSON documents that say "Allow" or "Deny" specific actions on specific resources.

Example — Read-Only Access to S3 (policy JSON)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": "*"
}
]
}

Explanation:

Effect: "Allow" — this statement grants permission (as opposed to Deny).

Action — the API actions allowed. s3:ListBucket lets you list bucket contents; s3:GetObject lets you download objects.

Resource: "*" — applies to all buckets. In production you should scope this to ARNs for specific buckets.

Practical Lab: Create a Read-Only Group

In the IAM console, go to User Groups → Create group.

Name the group S3-ReadOnly.

Attach the policy AmazonS3ReadOnlyAccess.

This is an AWS-managed policy that implements a safe read-only rule set.

Click Create group.

Add your user Samuel to this group.

Samuel is now in two groups: Admin and S3-ReadOnly.

Permissions are additive — Samuel’s effective permission set is the union of group permissions, except where an explicit Deny overrides.

Why groups & policies?

Easier to audit and scale. Add/remove people without touching policies.

Reuse policies for many users.

** IAM Roles**

Samuel needs an EC2 server to read files from S3. You could give the server an access key (yuck), or you can dress the server in a role — a temporary identity the instance can assume. Roles are the secure, AWS-native way to let services act on behalf of each other.

Practical Lab: Assigning a Role to a Service

In IAM, go to Roles → Create role.

Choose AWS service → EC2.

This sets the trust policy so EC2 instances can assume the role.

Add permissions: AmazonS3ReadOnlyAccess.

Name the role MyEC2S3ReadRole and create it.

Go to EC2 → Launch instance.

Under Advanced details, select IAM instance profile → MyEC2S3ReadRole.

This attaches the role to the instance on launch. If the instance is already running, attach the role via Instance Actions → Security → Modify IAM role.

Launch (or apply) the instance.

Once it’s running, connect using EC2 Instance Connect or SSH.

In the terminal, run:

aws s3 ls

The instance lists your S3 buckets using role permissions — no long-term keys required.

Quick tip: Make sure the instance either has the AWS CLI installed or use the platform's built-in tooling that can access the instance
profile credentials.

Best Practices & Security Checklist

Never use the root account for daily tasks. Keep it locked and enable MFA on root.

Require password reset on first login for any default password you create.

Enable MFA for all console users — especially any admin or privileged accounts.

Principle of least privilege: avoid attaching AdministratorAccess unless needed.

Use groups & roles instead of attaching policies directly to users whenever possible.

Rotate and revoke credentials: If a .csv is lost or a key is exposed, delete it and create new credentials.

Use secure channels to share .csv files (encrypted email, secure vaults). Don’t paste credentials in chat.

Enable CloudTrail to audit actions and detect suspicious behavior.

Limit programmatic keys and prefer roles for services and EC2.

Tag resources & users for billing, ownership, and audits.

Troubleshooting & FAQs

Q: I lost the .csv — can I download it again? A: No. AWS shows access keys and generated passwords only once. If lost, delete the key and create a new one, or reset the console password for that user.

Q: I want Alice to switch teams later — how do I change her permissions? A: Remove Alice from the old group and add her to the new group. Changes take effect immediately.

Q: Do policies add or override? A: Policies are additive — all Allow permissions are combined. However, an explicit Deny in any policy overrides an Allow.

Q: Should I give EC2 instances access keys? A: No — prefer IAM Roles (instance profiles). They provide temporary credentials and are far safer.

*Final Notes *—

Joy did the right thing: she kept the root account safe, created Samuel with a console password, downloaded the .csv, handed it over securely, and had Alice set her own password at first login. Later, Joy used groups and roles to make the environment auditable and maintainable.

Simplifying Workload Communication with Azure Private DNS Zones

PETER Samuel — Wed, 03 Sep 2025 18:40:06 +0000

Scenario

My organization needed workloads to communicate using domain names instead of raw IP addresses. The requirement was to avoid setting up a custom DNS solution and rely solely on Azure-native DNS services.

To meet this, we implemented:

A Private DNS zone (private.contoso.com)

A Virtual network link to app-vnet

A new DNS record for backend resources

This setup provides secure, reliable, and simplified workload communication within Azure virtual networks.

Skilling Tasks

Create and configure a Private DNS zone

Link the DNS zone to a Virtual Network

Add and manage DNS record sets

Configure DNS settings on a virtual network

Architecture Diagram

Step-by-Step Implementation

Create a Private DNS Zone

In the Azure portal, search for Private DNS zones.

Click + Create and configure:

Resource Group: RG1

Name: private.contoso.com

Region: East US

Select Review + Create → Create.

This creates a secure DNS zone for internal name resolution.

Create a Virtual Network Link

To ensure workloads in app-vnet can resolve names from this DNS zone:

Open your private.contoso.com DNS zone.

In the DNS Management blade, select + Virtual network links.

Configure:

Link name: app-vnet-link

Virtual network: app-vnet

Enable auto registration: Enabled

Click Create.

Now, VMs in app-vnet can auto-register and resolve DNS names.

Create a DNS Record Set

Finally, we add a record for the backend workload:

Open the private.contoso.com DNS zone.

Select + Record set.

Configure:

Name: backend

Type: A

TTL: 1

IP Address: 10.1.1.5

Now, workloads can resolve backend.private.contoso.com → 10.1.1.5.

Key Takeaways

Azure Private DNS zones provide a built-in way to manage DNS for private workloads.

Virtual network links allow seamless DNS resolution across VNets.

DNS record sets simplify internal communication without exposing workloads publicly.

This exercise reinforced my skills in Azure networking, DNS configuration, and workload security—a crucial part of designing cloud-native architectures.

Configuring Secure Access to Workloads with Azure Virtual Networking Services

PETER Samuel — Wed, 03 Sep 2025 07:19:12 +0000

Securing workloads in the cloud isn’t just about protecting applications—it’s also about controlling how traffic flows in and out of your environment. In this project, I configured Azure Virtual Network routing to ensure that all outbound traffic from application workloads passes through a firewall for inspection and policy enforcement.

This post walks you through the scenario, architecture, configuration steps, and key takeaways from the project.

Scenario

To enforce firewall policies on outbound traffic, I needed to ensure that application traffic from both the frontend and backend subnets would route through an Azure Firewall.

Requirements:

A route table for the virtual network.

Association of the route table with both the frontend and backend subnets.

A user-defined route to send all outbound traffic (0.0.0.0/0) through the firewall’s private IP address.

Skilling Tasks

Here’s what I practiced in this project:

Creating and configuring a custom route table in Azure.

Associating route tables with subnets.

Adding a route to direct outbound traffic through a firewall.

Architecture

The architecture looks like this:

One virtual network with:

A frontend subnet

A backend subnet

An Azure Firewall

A route table linked to both subnets, forcing outbound traffic through the firewall.

1. Record the Firewall’s Private IP

Navigate to app-vnet-firewall in the Azure Portal.

Under Overview, copy the Private IP address.

2. Create a Route Table

Search for Route tables in the portal → + Create.

Fill in:

Property Value
Resource group RG1
Region East US
Name app-vnet-firewall-rt

Click Review + create → Create.

3. Associate the Route Table with Subnets

Open the route table (app-vnet-firewall-rt).

Under Settings → Subnets → + Associate.

Associate with frontend subnet.

Repeat and associate with backend subnet.

4. Create a Route in the Route Table

In the same route table, go to Routes → + Add.

Configure:

Property Value
Route name outbound-firewall
Destination type IP addresses
Destination CIDR 0.0.0.0/0
Next hop type Virtual appliance
Next hop address Private IP of the firewall

Key Takeaways

Azure automatically applies system routes, but user-defined routes (UDRs) let you override them.

Routing outbound traffic through an NVA (like Azure Firewall) enforces security policies.

Subnet-level associations allow fine-grained control over traffic flow.

Route tables are a critical piece in designing secure cloud networking.

Final Thoughts

This exercise gave me hands-on experience with network routing and security in Azure. Configuring user-defined routes ensures that workloads don’t bypass firewall policies, which is essential for secure architectures in production.

If you’re exploring Azure networking, I’d recommend diving into custom routing and firewalls early—it’s a skill you’ll need for almost every enterprise-grade deployment.

👉 Would you have routed traffic differently, maybe using NSGs or Application Gateway instead of Firewall? I’d love to hear your approach in the comments!

💡 Next step for me: Extend this project by adding monitoring with Azure Monitor and logging firewall activity to see what traffic gets blocked or allowed.

Thanks for reading! If you found this useful, drop a ❤️ or follow me here on Dev.to for more Azure hands-on projects.

🔒 Configuring Secure Access to Workloads with Azure Firewall

PETER Samuel — Tue, 02 Sep 2025 16:11:51 +0000

When building modern cloud applications, security is non-negotiable. As workloads scale, organizations need centralized and flexible network security. Azure Firewall provides exactly that — with application-level filtering, network rules, and threat intelligence baked in.

Recently, I implemented secure access for an application virtual network using Azure Firewall. Here’s a breakdown of the approach.

The Scenario

The application virtual network (app-vnet) needed:

Centralized network security for inbound and outbound traffic.

Granular application filtering to control what services the app can talk to.

Continuous updates from Azure DevOps pipelines.

DNS resolution to external servers.

To meet these, I deployed Azure Firewall with a firewall policy to manage rules at scale.

Key Steps

Deploying Azure Firewall

Created a dedicated AzureFirewallSubnet inside app-vnet.

Provisioned a Standard SKU Azure Firewall with a new public IP (fwpip).

Attached a firewall policy (fw-policy) to centralize rule management.

2. Configuring Firewall Policy

Firewall policies make it easy to group and manage rules. I added:

** Application Rule Collection**

Allowed the application subnet (10.1.0.0/23) to securely reach Azure DevOps and Azure websites for CI/CD updates:

Protocol: HTTPS

Destination FQDNs: dev.azure.com, azure.microsoft.com

** Network Rule Collection**

Enabled DNS resolution by allowing outbound UDP traffic on port 53:

Source: 10.1.0.0/23

Destination IPs: 1.1.1.1, 1.0.0.1 (Cloudflare DNS)

Results

All outbound traffic is filtered through the firewall.

Application has secure, controlled access only to Azure DevOps and Azure websites.

DNS resolution is enabled without exposing unnecessary outbound access.

The firewall and policy deployment completed successfully and are now centrally managed.

Key Takeaways

Azure Firewall provides centralized, cloud-native network security.

Firewall policies simplify management of rules across environments.

Application rules focus on FQDN-based filtering.

Network rules focus on IP/port/protocol control.

This setup ensures that workloads in app-vnet remain locked down yet functional — with only the necessary access for deployments and operations.