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
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.
Top comments (0)