DEV Community: Joy Imarah

From Manual Deployments to Infrastructure as Code with Azure ARM Templates (Part 2)

Joy Imarah — Sun, 05 Jul 2026 13:47:08 +0000

Introduction

In my previous article, I shared my experience getting started with Microsoft Azure after building a foundation in AWS.

Once I became comfortable navigating Azure, I wanted to take the next step:

Move from manual resource creation to automated infrastructure deployment.

This introduced me to Infrastructure as Code (IaC) using Azure Resource Manager (ARM) Templates and Azure CLI.

Why Infrastructure as Code Matters

While manually creating resources in the Azure Portal is useful for learning, it becomes inefficient and error-prone in real-world environments.

Infrastructure as Code solves this by allowing us to:

Define infrastructure using code
Reproduce environments consistently
Reduce manual errors
Enable automation and version control
Instead of clicking through the Azure Portal, I could now deploy entire environments using a single template.

Project Overview

In this project, I deployed a Linux Virtual Machine using an ARM template.

The deployment included:

Resource Group
Virtual Network (VNet)
Subnet
Network Security Group (NSG)
Public IP Address
Network Interface
Linux Virtual Machine

All resources were created automatically based on the ARM template definition.

Technologies Used

Microsoft Azure
Azure CLI
ARM Templates (JSON)
Linux Virtual Machine
SSH
Git & GitHub

Challenges Encountered

ARM Template Validation Errors At first, my deployment failed due to incorrect parameter values and resource dependencies.

How I fixed it:

I reviewed the ARM template structure carefully, validated the deployment using Azure CLI, corrected the parameters, and redeployed successfully.

SSH Connection Issues After successful deployment, I initially couldn’t connect to the VM via SSH.

How I fixed it:

I verified:

VM was running
Correct public IP was assigned
NSG allowed inbound traffic on port 22
Correct username was used

Once everything was aligned, SSH access worked successfully.

Understanding Azure Networking Behavior Coming from AWS, I had to adjust to how Azure handles networking through:

Network Interfaces
NSGs
Subnet associations

How I adapted:

I mapped Azure networking concepts to AWS equivalents (VPC, Security Groups) to better understand the architecture.

Key Learning

The biggest lesson from this project was:

Infrastructure as Code is not just automation — it is consistency, reliability, and scalability in practice.

Another important insight:

Troubleshooting is part of cloud engineering. Every error teaches you something about how the system actually works.

Repository

GitHub:
https://github.com/JoySmarty/3mtt-arm-vm-deployment

Security Improvement (Important)

While this project uses password authentication for simplicity, a production-grade setup should use:

SSH key authentication
Disabled password login

This improves security and aligns with cloud best practices.

Resource Cleanup

To avoid unnecessary costs, I deleted the entire Resource Group after testing.

This automatically removed:

Virtual Machine
Network Interfaces
Public IP
Virtual Network
NSG

This reinforces an important cloud principle:

Always clean up unused resources to avoid unnecessary billing.

What’s Next

The next stage of my learning journey focuses on cloud economics.

I will be working on:

Azure vs AWS Cost Comparison for a Small Web Application

This project will explore:

Compute pricing differences
Storage costs
Network egress charges
Free tier comparisons
Cost optimization strategies

This will help bridge the gap between technical architecture and financial decision-making in the cloud.

Final Thoughts

This project deepened my understanding of Infrastructure as Code and how cloud infrastructure can be managed efficiently.

More importantly, it reinforced my multi-cloud perspective — seeing how AWS and Azure approach similar problems in different ways.

Closing Note

If you’re also exploring cloud computing or transitioning between AWS and Azure, I’d love to connect and hear about your experiences.

Building a Secure Azure Virtual Machine Environment with Azure Bastion (No Public IP Required) (Part 5)

Joy Imarah — Tue, 30 Jun 2026 07:07:00 +0000

Cloud security starts with reducing unnecessary exposure.

One common mistake when deploying virtual machines is assigning public IP addresses and opening SSH or RDP ports to the internet.

While this may work for quick testing, it significantly increases the attack surface of your infrastructure.

In this hands-on Azure lab, I explored a more secure approach by deploying Linux and Windows virtual machines that are administered entirely through Azure Bastion.

Project Goal

The objective was to deploy two virtual machines inside a secure Azure Virtual Network while ensuring that administrative access remained private.

The environment includes:

Azure Resource Group
Virtual Network
AzureBastionSubnet
Application subnet
Network Security Group
Ubuntu Server VM
Windows Server 2022 VM
Azure Bastion

The virtual machines were intentionally deployed without public IP addresses.

Architecture

Resource Group
│
├── Virtual Network
│
├── AzureBastionSubnet
│ └── Azure Bastion
│
└── subnet-webapp
 ├── Ubuntu VM
 ├── Windows Server VM
 └── Network Security Group

This architecture follows Azure security best practices by keeping administrative services off the public internet.

Deploying the Virtual Machines

Both virtual machines were created inside the same Virtual Network.

For Linux:

Ubuntu Server 22.04 LTS
SSH Key Authentication

For Windows:

Windows Server 2022
Username & Password Authentication

Instead of assigning public IP addresses, Azure Bastion provides browser-based SSH and RDP access directly from the Azure Portal.

Security Configuration

The Network Security Group (NSG) was associated with the application subnet to manage inbound and outbound traffic for both virtual machines.

This approach simplifies administration because a single NSG protects every resource within the subnet.

Key security features include:

No public IPs on either VM
Azure Bastion for secure remote access
Centralized traffic filtering through an NSG
Private Virtual Network deployment

Validation

Linux

After connecting through Azure Bastion, I verified the deployment with:

whoami pwd uname -a ls -la

These commands confirmed that the virtual machine was functioning correctly.

Windows

Using Azure Bastion's browser-based Remote Desktop connection, I successfully accessed:

Windows Desktop Server Manager Administrative tools

Both operating systems were fully accessible without exposing RDP or SSH to the internet.

Challenges Encountered

The Linux virtual machine connected successfully through Azure Bastion on the first attempt.

The Windows VM, however, initially failed to establish an RDP session.

To resolve the issue, I reviewed:

Azure Bastion deployment
AzureBastionSubnet configuration
Virtual network settings
Network Security Group association
Windows administrator credentials

Once the networking configuration was corrected, Azure Bastion successfully connected to the Windows virtual machine.

This troubleshooting exercise reinforced the importance of validating every component of a cloud deployment instead of assuming the issue lies with a single service.

Lessons Learned

Working through this project reinforced several important Azure concepts:

Azure Bastion provides secure browser-based administration without exposing virtual machines to the public internet.
Network Security Groups can be applied at the subnet level to simplify security management.
Proper subnet planning is critical when deploying Azure networking resources.
Troubleshooting cloud infrastructure is an essential part of becoming a cloud engineer.

Final Thoughts

This lab strengthened my understanding of Azure networking, secure remote administration, and infrastructure security. More importantly, it demonstrated how Azure's native services can be combined to create environments that are both functional and secure.

The complete documentation, deployment notes, and project files are available on GitHub:

🔗 Repository: https://github.com/JoySmarty/3mtt-vm-remote-connection-lab

If you're learning Azure, I highly recommend building projects like this yourself. The lessons you gain from troubleshooting are often the ones you'll remember the longest.

I'm documenting my cloud engineering journey through hands-on Azure projects. Follow along as I continue exploring networking, security, identity, and infrastructure on Microsoft Azure.

AWS vs Azure Multi-Region Cost Analysis (Part 3)

Joy Imarah — Sat, 27 Jun 2026 09:05:00 +0000

Introduction

Cloud pricing behaves differently depending on provider, region, and workload design. In this project, I built identical infrastructure across AWS and Microsoft Azure to compare real-world cost differences across multiple regions.
The goal was to understand not just pricing - but how location changes cloud economics.

Architecture Overview

The same workload was deployed across both providers:

Compute
AWS: EC2 t3.micro (Linux)
Azure: B1s Virtual Machine (Linux and Windows with Azure Hybrid Benefit)

Storage
AWS: 32GB EBS + 50GB S3 Standard
Azure: 32GB Managed Disk + 50GB Blob Storage (Hot Tier)

Networking
100GB outbound internet traffic per month

💰 Final Cost Comparison (US Region Baseline)
AWS: $19.15/month

Azure (Linux): $12.07/month
Azure (Windows + AHB): $12.07/month

Key Insight
AWS is approximately 58.6% more expensive than Azure for this workload.

🌍 Regional Cost Comparison (Major Insight)

This is where pricing differences become more interesting.

🇺🇸 US East (Baseline)
AWS: $19.15
Azure: $12.07

🌏 Asia (Tokyo / East Asia)
AWS (Tokyo)
$24.40/month

Azure (East Asia)
$13.91/month (Linux VM + Blob Storage)

👉 AWS is ~75% more expensive than Azure in Asia

🇪🇺 Europe (Ireland / West Europe)
AWS (Ireland)
$20.14/month

Azure (West Europe)
$13.27/month (Linux VM + Blob Storage)

👉 AWS is ~51.8% more expensive than Azure in Europe

📊 Summary of Regional Impact
RegionAWS CostAzure CostAWS IncreaseUS East$19.15$12.07~58.6%Europe$20.14$13.27~51.8%Asia$24.40$13.91~75%

🔍 Key Findings

Data transfer is the biggest AWS cost driver Outbound traffic significantly increases AWS pricing.
Azure is more stable across regions Pricing variation is smaller and more predictable.
Asia is the most expensive region Both providers increase pricing, but AWS increases much more sharply.

⚖️ Service Equivalency Mapping
EC2 ↔ Azure Virtual Machines
S3 ↔ Azure Blob Storage
EBS ↔ Managed Disks

📌 GitHub Repository
Full project and all estimates:
https://github.com/JoySmarty/3mtt-azure-vs-aws-cost-comparison.git

🚀 Conclusion
Cloud cost is not fixed - it changes based on:
region
traffic
compute type
provider pricing model

AWS becomes significantly more expensive at scale, especially in high-cost regions like Asia.
Azure provides more stable pricing, making it more predictable for small-to-medium workloads.

Azure Resource Organization: Building a Governed Multi-Environment Cloud Architecture (Part 4)

Joy Imarah — Sat, 27 Jun 2026 07:48:00 +0000

Introduction

Cloud environments become complex quickly without proper structure and governance. In this project, I designed and implemented a structured Azure environment to understand how real-world cloud systems are organized, secured, and monitored.

The focus was on:

Resource organization
Naming conventions
Tagging strategy
RBAC (Role-Based Access Control)
Azure Policy
Monitoring with Log Analytics

Architecture Overview

I designed a multi-environment structure consisting of:

Development environment
Production environment
Staging environment
Shared services environment

Each environment was isolated using dedicated Resource Groups to ensure proper lifecycle management and separation of concerns.

Resource Groups Design

The following Resource Groups were created:

rg-webapp-dev-eastus
rg-webapp-prod-eastus
rg-webapp-staging-eastus
rg-webapp-shared-eastus

This structure allows:

Environment isolation
Independent deployments
Better cost tracking
Cleaner access control

Naming Convention Strategy

A consistent naming structure was applied:

<resource-type>-webapp-<environment>-<region>-<instance>

Example:

vm-webapp-dev-eastus-01
vnet-webapp-prod-eastus

This ensures clarity and scalability across resources.

Tagging Strategy

All resources were tagged using a standard structure:

environment
owner
project
costCenter

This enables:

Cost allocation tracking
Resource filtering
Governance enforcement

RBAC Implementation

Role-Based Access Control was applied at the Resource Group level to simulate a multi-team environment.
This demonstrated how access can be restricted based on environment and team responsibilities.

Azure Policy

Azure Policy concepts were explored to enforce:

Required tags
Naming standards
Compliance rules

This introduces governance automation into the architecture.

Monitoring with Log Analytics

A Log Analytics Workspace was deployed in the shared services Resource Group to support:

Centralized logging
Monitoring and diagnostics
Future alerting and observability setups

Key Learnings

Cloud architecture is fundamentally about governance, not just deployment
Tagging and naming conventions directly affect cost management
Resource Groups are essential for lifecycle management
Monitoring is critical for production-ready systems
Azure Policy enables scalable governance

Conclusion

This project helped me understand how enterprise Azure environments are structured and governed. It strengthened my knowledge of cloud organization principles and introduced me to FinOps and governance best practices.

GitHub Repository

https://github.com/JoySmarty/3mtt-azure-resource-organization.git

From AWS Foundations to Microsoft Azure: My First Hands-on Azure Project (Part 1)

Joy Imarah — Sat, 20 Jun 2026 08:10:25 +0000

Introduction

After earning multiple AWS certifications, I decided to expand my cloud engineering experience by exploring Microsoft Azure.

While cloud concepts like compute, storage, networking, and identity are consistent across providers, each platform has its own architecture, terminology, and way of organizing resources.

Rather than just reading documentation, I wanted to gain hands-on experience in Azure by building real infrastructure.

This project marks the beginning of my Azure journey and the first part of my multi-cloud learning series.

Why I Started Exploring Azure

Coming from an AWS background, I was already familiar with core cloud principles like:

Virtual machines (EC2 equivalents)
Object storage (S3 equivalents)
Networking concepts (VPC equivalents)
Identity and access management

However, I wanted to understand:

How are these concepts implemented differently in Microsoft Azure?

This curiosity led me to start building directly in Azure instead of only studying it.

Project Objective

The goal of this project was to:

Understand Azure’s resource organization model
Learn how the Azure Portal works
Gain familiarity with core services like:
Resource Groups
Virtual Machines
Networking basics
Build confidence navigating a new cloud environment

What I Learned

This project helped me understand Azure from a practical perspective.

Key areas explored:

Resource Groups as a way of organizing infrastructure

Virtual Machines and how compute is provisioned
Basic networking concepts in Azure
How Azure structures and manages cloud resources

One interesting realization was how familiar cloud concepts are implemented differently across providers.

Even though AWS and Azure solve the same problems, their structure and naming conventions differ significantly.

Key Insight (Multi-Cloud Perspective)

One of the most valuable takeaways was recognizing patterns across clouds.

For example:

AWS EC2 ↔ Azure Virtual Machines
AWS S3 ↔ Azure Blob Storage (within Azure Storage Accounts)

AWS VPC ↔ Azure Virtual Networks
AWS IAM ↔ Azure Active Directory (Entra ID)

This reinforced an important idea:

Cloud engineering is less about memorizing services and more about understanding underlying patterns.

Challenges Faced

Getting comfortable with Azure’s structure

Azure’s organization model felt different from AWS at first, especially with Resource Groups acting as a central organizing layer.

How I adapted:
I focused on understanding Resource Groups as the foundation of everything in Azure, which made navigation much easier.

Terminology differences

Even when services do the same thing, Azure and AWS use different names.

How I handled it:
I mapped equivalent services between AWS and Azure to build mental connections between both platforms.

Repository

GitHub:
https://github.com/JoySmarty/3mtt-first-azure-project

What’s Next

After getting comfortable with Azure fundamentals, I wanted to go deeper into automation.

The next step was learning how to deploy infrastructure using code instead of the Azure Portal.

That led me to Infrastructure as Code (IaC) using ARM Templates, covered in Part 2.

Final Thoughts

This project wasn’t about learning cloud computing from scratch—it was about expanding my perspective beyond AWS.

Understanding Azure helped me strengthen my multi-cloud thinking and improved how I approach cloud architecture in general.

Introduction

Joy Imarah — Thu, 18 Jun 2026 14:11:32 +0000

Hi everyone 👋

I’m new to Dev.to and excited to be here. I’m currently exploring cloud computing, DevOps, and machine learning, and I enjoy learning how modern systems are built and deployed.

I recently started working on real-world projects involving AWS and automation, and I’m looking forward to improving my skills and connecting with other developers here.

Happy to learn from you all and share my journey as I grow 🚀