DEV Community: Ganiyat Olagoke Adebayo

End-to-End Monitoring in Azure: From Logs to Alerts

Ganiyat Olagoke Adebayo — Sat, 14 Feb 2026 21:03:26 +0000

Monitoring is essential for maintaining application reliability, performance, and security in the cloud.
With Azure Monitor, organizations can collect telemetry from applications, virtual machines, and networks, analyze it centrally, and trigger alerts when issues arise.

This walkthrough follows a practical implementation that moves from creating a Log Analytics workspace to configuring full monitoring and alerting. However, before delving into the project proper, we need to prepare the environment.

Environment Preparation for Azure Monitor Project (Step-by-Step)

Before configuring monitoring, we must deploy the infrastructure that will generate telemetry.
This setup includes resource groups, security identities, virtual machines, and web applications.

All resources in this guide are deployed using the Azure portal.

Step 1 – Create the Resource Group

In the portal search bar, type Resource groups.

Click Create.

Select your Subscription.
Enter rg-alpha as the name.
Choose East US as the region.

Click Review + Create → Create.

Result

A container is available to hold all lab resources.

Step 2 – Create the App Log Examiners Security Group

This group will later be granted permissions to review monitoring data.

Search for Microsoft Entra ID (Azure Active Directory).

Select Groups.

Click New group.

Configure:
- Group type: Security
- Group name: App Log Examiners
- Description: App Log Examiners
Click Create.

Result

An identity group exists for access delegation.

Step 3 – Deploy and Configure Windows VM (WS-VM1)

This VM will host IIS and generate logs for monitoring.

Create the VM

Search Virtual Machines.
Click Create → Azure virtual machine.

Basics configuration:

Resource group: rg-alpha
VM name: WS-VM1
Region: East US

Availability: No infrastructure redundancy
Security type: Standard
Image: Windows Server 2022 Datacenter: Azure Edition

Size: Standard_D4s_v3
Username: prime
Password: your secure password

Inbound port: RDP (3389)

Click Review + Create → Create.

Restrict RDP access

After deployment:

Open the VM → Networking.
Select the RDP rule.

Change Source to My IP address.

Save.

Add HTTP inbound rule

From Networking → Add inbound port rule.

Configure:
- Source: Any
- Service: HTTP
- Action: Allow
- Priority: 310
- Name: AllowAnyHTTPInbound
Click Add.

Connect to the VM

Open the VM → Connect.
Under Native RDP, choose Download RDP file.

Open it.
Username: .\prime
Enter your password.

Install IIS

Inside the VM:

Right-click Start → Windows PowerShell (Admin).
Run as Admin:

Install-WindowsFeature Web-Server -IncludeAllSubFeature -IncludeManagementTools

Deploy sample website

cd c:\inetpub\wwwroot\
wget https://raw.githubusercontent.com/Azure-Samples/html-docs-hello-world/master/index.html -OutFile index.html

Result

A Windows web server is now producing logs.

Step 4 – Deploy Linux VM (Linux-VM2)

This machine will be used later for network and monitoring configuration.

Create the VM

Go to Virtual Machines → Create.

Basics:

Resource group: rg-alpha
Name: Linux-VM2
Region: East US
Image: Ubuntu Server 20.04

Size: Standard_D2s_v3
Authentication: Password
Username: Prime

Public inbound ports: None
Review and create.

Install Network Watcher Agent

Open the VM.
Select Extensions + applications.
Click Add.

Choose Network Watcher Agent for Linux.

Create.

Result

Linux VM ready for monitoring integration.

Step 5 – Deploy Web App with SQL Database

This deployment provides application + database telemetry.
Ensure that you’re signed into the Azure Portal.

In your browser, open a new browser tab and navigate to https://github.com/Azure/azure-quickstart-templates/tree/master/quickstarts/microsoft.web/web-app-sql-database

Open the GitHub quickstart.
Click Deploy to Azure.

If prompted, sign in.

Edit the template

Select Edit template.

Delete lines 158–174 and the comma on line 157.

Click Save.

Provide parameters

Resource group: rg-alpha
Region: East US
SKU: F1
SQL admin: prime
Password: your secure password

Click Create.

Result

A web application backed by SQL is deployed.

Step 6 – Deploy Linux Web App

Open the quickstart link.
Click Deploy to Azure.

Provide configuration

Resource group: rg-alpha
Region: East US
Web app name: AzureLinuxAppXXXX
SKU: S1
Runtime: PHP 7.4

Click Create.

Environment Setup Complete

At this point, your lab includes:

Resource group
Identity security group
Windows IIS VM
Linux VM
Web app with SQL
Linux web app

These components will generate the telemetry required for Log Analytics, Application Insights, data collection rules, and alerts.

Conclusion

The environment is now fully prepared to support centralized monitoring.
The next phases will connect these resources to Azure Monitor, enable diagnostics, and implement alerting mechanisms.

This preparation stage ensures realistic, production-style visibility across both PaaS and IaaS services.

Project Exercises

Deploy Log Analytics
Monitor web applications
Configure monitoring for compute services
Configure alerts

Each exercise builds on the previous one.

Step 1 – Deploy Log Analytics Workspace

Create the workspace

Sign in to the Azure portal.
In the search bar, type Log Analytics workspaces.

Select Create.

Choose your Subscription and Resource Group.
Enter a Workspace name.
Select a Region.

Click Review + create → Create.

Step 2 – Install and Configure the Azure Monitor Agent on Linux-VM Using a Data Collection Rule (DCR)

Once the Linux VM is deployed, the next step is to enable monitoring by installing the Azure Monitor Agent (AMA) and configuring a Data Collection Rule (DCR) to send telemetry to the Log Analytics workspace.

This ensures that performance data from the Linux VM is automatically collected and available for analysis.

Step 2.1 – Create a Data Collection Rule

In the Azure Portal search bar, type Data Collection Rules.

Click + Create to start a new DCR.

Basics

Rule name: DCR-Linux-VM
Subscription: Your subscription
Resource Group: rg-alpha
Region: East US (or the region matching your VM/workspace)
Platform type: Linux

Click Next: Resources >.

Resources

Click + Add resources.

Search for Linux-VM2 and select it.

Click Apply.

Click Next: Collect and deliver >.

Collect and Deliver

Click + Add data source.

Data source type: Performance Counters
Click Next: Destination >.

Destination

Click + Add destination.

Destination type: Azure Monitor Logs
Destination Details: Select LogAnalytics1 (rg-alpha)
Click Add data source.

Click Next: Review + create.

Review and Deploy

Review all settings.
Click Create.

Note: Assigning the DCR automatically deploys the Azure Monitor Agent to the VM. You do not need to manually add the agent under Extensions.

Step 2.2 – Verify Agent Installation and Data Ingestion

Search for Log Analytics workspaces in the portal.

Select LogAnalytics1 from the workspace list.

In the left-hand menu, select Logs.

Switch the mode from Simple to KQL (Query Language mode).

In the query window, enter:

Heartbeat
| where Computer contains "Linux-VM2"
| sort by TimeGenerated desc

Click Run or press Shift + Enter.

Result:
If results are returned, the Azure Monitor Agent is installed correctly, and performance data is flowing into the Log Analytics workspace.

Outcome

The Linux VM is now fully monitored:

Performance data is automatically collected.
Logs are centralized in LogAnalytics1.
The VM is ready for inclusion in further monitoring exercises, alerts, and analysis.

Step 3 – Configure Log Analytics Data Retention and Daily Cap

After creating the Log Analytics workspace, it is important to configure how long data is kept and how much data can be ingested daily. This helps control costs and ensures compliance with organizational policies.

Step 3.1 – Set Data Retention

In the Azure Portal search bar, type Log Analytics and select Log Analytics workspaces.
Click on LogAnalytics1 from the workspace list.
In the left-hand menu, under Settings, select Usage and estimated costs.
Click Data Retention.
Set the retention slider to 60 days.

Click OK.

Step 3.2 – Configure Daily Data Cap

On the LogAnalytics1 workspace page, under Settings → Usage and estimated costs, select Daily cap.
Switch the setting to On.
Set the daily cap to 10 GB.

Click OK.

Outcome

Data will be retained for 60 days in the workspace.
Daily ingestion will be limited to 10 GB, preventing unexpected costs.
The workspace is now ready for all subsequent monitoring tasks.

Step 4 – Enable Access to the Log Analytics Workspace

After creating and configuring the workspace, you need to assign permissions to users or groups who will be analyzing the data. In this lab, the App Log Examiners security group will be granted read access.

Step 4.1 – Open the Workspace

In the Azure Portal search bar, type Log Analytics and select Log Analytics workspaces.
Click LogAnalytics1 from the list of workspaces.
In the workspace menu, select Access control (IAM).
Click Add → Add role assignment.

From the list of roles, select Log Analytics Reader.

Click Next.
On the Members page, click Select members.
Search for and select App Log Examiners security group.

Click Select.
Click Review + Assign to complete the assignment.

Outcome

The App Log Examiners group now has read access to the Log Analytics workspace.
Members of this group can view and query telemetry data without having write permissions.
The workspace is ready for monitoring and analytics tasks.

Step 5 – Configure Monitoring for the Web App and SQL Database

After preparing the infrastructure and the Log Analytics workspace, the next objective is to ensure that the application layer sends telemetry for analysis.

In this section, you will:

Enable Application Insights
Disable unnecessary debugging features
Route HTTP logs to Log Analytics
Send SQL Insights data to the workspace

Step 5.1 – Enable Application Insights

In the Azure Portal search bar, type rg-alpha and open the resource group.

From the resource list, select the App Service associated with the Web App and SQL Database deployment.

Under Monitoring, choose Application Insights.

Click Turn on Application Insights.

Ensure Create new resource is selected.
Confirm the Log Analytics workspace is set to LogAnalytics1.

Click Apply.
In the confirmation dialog, select Yes.

Outcome

The web application can now collect request rates, failures, dependencies, and performance metrics.

Step 5.2 – Disable .NET Core Snapshot Debugger

In lab environments, this feature is not required and may generate unnecessary overhead.

Stay within the App Service.
Under Monitoring, open Application Insights.
In Instrument your application, select .NET Core.

Set Snapshot Debugger to Off.
Click Apply.
Confirm by choosing Yes.

Outcome

Diagnostic capture is optimized for essential telemetry only.

Step 5.3 – Send Web App HTTP Logs to Log Analytics

From the App Service menu, select Diagnostic settings.
Click + Add diagnostic setting.

Configure the following:

Property	Value
Diagnostic setting name	httplogs
Categories	HTTP logs
Destination	Send to Log Analytics workspace
Subscription	Your subscription
Workspace	LogAnalytics1

Click Save.

Outcome

Web traffic logs are now centralized in the workspace.

Step 5.4 – Send SQL Insights to Log Analytics

Return to the rg-alpha resource group.
Select the SQL database created during deployment.

Under Monitoring, choose Diagnostic settings.

Click Add diagnostic setting.

Provide:

Property	Value
Diagnostic setting name	InsightLogAnalytics
Categories	SQL Insights
Destination	Send to Log Analytics workspace
Subscription	Your subscription
Workspace	LogAnalytics1

Click Save.

Outcome

Database performance and behavior can now be correlated with application activity.

Result of Step 5

At this point, you have achieved:

Application performance monitoring
Centralized HTTP request logging
SQL telemetry integration
Unified visibility across app and database

Your Log Analytics workspace is becoming the single source of truth for operational data.

6. Configure Monitoring for Compute Services

step 6.1 – Create a Data Collection Endpoint

In the Azure portal search bar, type Monitor and open Azure Monitor.

Under Settings, select Data Collection Endpoints.

Select Create.

Basics tab

Property	Value
Endpoint name	IaaSVMCollectionEndpoint
Subscription	Your subscription
Resource Group	rg-alpha
Region	East US

Select Review + Create.
Select Create.

6.2 – Create a Data Collection Rule

In the Azure portal search bar, type Monitor and open it.
Under Settings, select Data Collection Rules.
Select Create.

Basics tab

Property	Value
Rule name	WinVMDCR
Subscription	Your subscription
Resource Group	rg-alpha
Region	East US
Platform type	Windows
Data collection endpoint	IaaSVMCollectionEndpoint

Select Next.

Resources

Select Add resources.
On Select a scope, check WS-VM1.

Select Apply.
Select Next.

Collect and deliver

Select Add data source.
Choose Windows Event Logs.

Configure:

Application → Critical, Error
Security → Audit Failure
System → Critical, Error

Select Next.

Destination

Property	Value
Destination type	Azure Monitor Logs
Subscription	Your subscription
Account or namespace	LogAnalytics1

Select Add data source.

Select Review + Create.

Select Create.

The rule will now begin sending VM logs to the workspace.

Step 6.3 – Add IIS Log Collection to the Existing Rule

In the Azure portal search bar, type Monitor and open it.
Select Data Collection Rules.
Choose WinVMDCR in resource group rg-alpha.

Add source

Under Configuration, select Data sources.

Select Add.

Choose IIS Logs.
Select Next.

Destination

Property	Value
Destination type	Azure Monitor Logs
Subscription	Your subscription
Account or namespace	LogAnalytics1

Select Add data source.

IIS telemetry is now included in the rule.

Step 7 – Configure Connection Monitor for the Linux VM

This validates network connectivity between machines and stores results in LogAnalytics1.

In the Azure portal search bar, type Network Watcher and open Azure Network Watcher.

Under Monitoring, select Connection Monitor.

Select Create.

Basics

Property	Value
Connection Monitor name	LinuxVMPubIP
Subscription	Your subscription
Region	East US 2
Workspace	LogAnalytics1

Select Next.

Test group

Enter name LinuxIPTest.
Select Add sources.

Azure Endpoints
Type → Virtual machines
Select Subnet
Check Linux-VM
Select Add endpoints.

Test configuration

Select Add Test Configuration.

Name → DefaultHTTP.
Select Add Test Configuration.

Destinations

Select Add destinations.

Azure Endpoints
Type → Virtual machines
Select Subnet
Check WS-VM1
Select Add endpoints.

Select Add Test Group.

Finish

Select Review + Create.
Select Create.

You have now:

Connected Windows event logs
Connected IIS logs
Configured VM telemetry
Enabled network performance monitoring

Your compute environment is fully integrated with Log Analytics.

8 Configure Alerts and Notifications

Step 8.1 – Create an Action Group to Send Email

In the Azure portal search bar, type Monitor and open Azure Monitor.

From the left menu, select Alerts.

Choose Action groups.

Select Create.

Basics

Property	Value
Subscription	Your subscription
Resource Group	rg-alpha
Region	Global
Action group name	NotifyCPU
Display name	NotifyCPU

Select Next: Notifications.

Notifications

Notification type → Email/SMS message/Push/Voice
Name → NotificationEmail
Select the pencil (edit) icon.

Inside the pane:

✔ Email
Enter → prime@fabrikam.com

Select OK.

Select Review + Create.
Select Create.

**Your email notification channel is ready.

Step 8.2 – Create an Alert for VM CPU Utilization

We will trigger an email when CPU usage is high.

In the Azure portal search bar, type rg-alpha and open the resource group.
From the resources list, select Linux-VM2.

Under Monitoring, select Alerts.

Choose Create → Alert rule.

Condition

Signal name → Percentage CPU.

Keep default threshold values.
Select Next.

Actions

Select Select action group.
Choose NotifyCPU.

Select Select.

Details

Property	Value
Alert rule name	HighCPU

Select Review + Create.

Select Create.

** Now, whenever CPU crosses the threshold, an email goes to prime@fabrikam.com.

Step 9 – Clean Up the Subscription

Important for labs and cost control.

Delete the Resource Group

In the Azure portal search bar, type Resource groups and open it.
Select rg-alpha.
Select Delete resource group.
Type rg-alpha to confirm.
Select Delete.

Delete the Security Group

Search for Microsoft Entra ID and open Microsoft Entra ID.
Select Groups.
Open App Log Examiners.
Select Delete → Yes.

Executive Summary – Azure Monitoring & Observability Implementation

This project delivered an end-to-end monitoring and observability framework across application, database, and infrastructure resources using Azure Monitor in Microsoft Azure.

The engagement established centralized telemetry collection, standardized data ingestion, controlled access to operational data, and proactive alerting. The result is improved service reliability, faster incident response, and stronger cost governance.

Objectives

Centralize logs and metrics into a single analytics platform
Enable performance visibility for web and database workloads
Collect security and system events from virtual machines
Monitor network connectivity between resources
Implement automated alerts for critical conditions
Apply role-based access and data retention policies

Solution Delivered

Centralized Log Platform

A Log Analytics workspace was configured as the unified destination for platform logs, application diagnostics, performance counters, and network telemetry.

Retention policies and a daily ingestion cap were implemented to balance operational insight with financial control.

Application & Database Observability

Application performance monitoring was enabled through Azure Application Insights, providing visibility into requests, dependencies, and failures.

Diagnostic pipelines were configured so that:

Web server HTTP logs
SQL Insights

flow into the central workspace for correlation and investigation.

Infrastructure Monitoring

Using Data Collection Rules and endpoints, virtual machines were onboarded to send:

Windows event logs (critical, error, audit failures)
IIS operational data
Linux performance telemetry

Agent deployment was automated through rule association, ensuring consistency and reducing administrative overhead.

Network Visibility

Connectivity monitoring between Linux and Windows workloads was implemented via Azure Network Watcher.

This provides continuous validation of reachability and supports rapid isolation of communication failures.

Proactive Alerting

An action group was created to deliver email notifications when CPU utilization breaches defined thresholds.
This converts raw telemetry into actionable operations signals.

Governance & Security

Access to monitoring data followed least-privilege principles by assigning read-only rights to a designated security group.
Temporary lab resources were removed at the end of the project to eliminate unnecessary spend.

Business Impact

The implementation enables:

Faster troubleshooting through correlated data
Reduced downtime via early detection
Improved accountability with auditable logs
Predictable monitoring costs
Scalable onboarding of future workloads

The environment now reflects a production-ready monitoring baseline aligned with cloud operational best practices.

Getting Started with Azure App Service: Deploying Your First Web App

Ganiyat Olagoke Adebayo — Mon, 02 Feb 2026 17:44:38 +0000

Introduction: What Is Azure App Service?

Azure App Service is a fully managed Platform as a Service (PaaS) offering that allows you to build, deploy, and host web applications without managing servers or infrastructure. With App Service, Microsoft handles the underlying operating system, patching, scaling, and availability, so developers and learners can focus entirely on the application itself.

Unlike Virtual Machines—where you are responsible for configuring and maintaining the server—Azure App Service abstracts away those complexities. It supports multiple programming languages and frameworks, offers built-in security, and provides easy integration with deployment tools, making it ideal for web apps, APIs, and backend services.

One of the most powerful aspects of Azure App Service is its flexibility. Applications can be deployed in several ways, including GitHub Actions, ZIP deployment, FTP, and even directly through the Azure portal using the Advanced Tools (Kudu) PowerShell console. This makes App Service especially suitable for learning, rapid prototyping, and simple production workloads.

In this guide, I demonstrate a hands-on approach to deploying a web application by creating an App Service in the Azure portal and copying application code directly into the wwwroot folder using PowerShell. This method helps beginners understand how App Service works behind the scenes while keeping the deployment process simple and visual.

In this guide, I walk through a hands-on, beginner-friendly approach to deploying a web app by directly copying and pasting application code into Azure using the PowerShell Debug Console.

This method is ideal for learning, quick tests, and simple applications.

Step 1: Prepare the Application Code

Before going to Azure, ensure your application code is ready.

This could be:

A simple HTML/CSS/JavaScript web app
A basic landing page

Example:

<!DOCTYPE html>
<html>
<head>
  <title>My Azure App</title>
</head>
<body>
  <h1>Hello from Azure App Service</h1>
</body>
</html>

Having your code ready makes deployment fast and smooth.

Step 2: Create an App Service in Azure

Sign in to the Azure Portal
Search for App Services

Click Create

Enter the required details:
- Subscription
- Resource Group
- App name (must be globally unique)
- Runtime stack
- Region
- App Service Plan (Free or Basic for learning)

Click Review + Create

Click Create Azure will deploy your App Service in a few minutes.

Step 3: Confirm App Creation Status

In the App Service menu, locate Default domain
Click the domain link

At this stage, you should see the default Azure App Service page, confirming the app was created successfully.

Step 4: Open Advanced Tools (Kudu)

In the App Service menu, search for Advanced Tools
Click Go

This opens the Kudu environment, which provides debugging and file management tools.

Step 5: Open PowerShell Debug Console

In Kudu, click Debug Console
Select PowerShell

This gives you direct access to the App Service file system.

Step 6: Navigate to the Application Folder

In PowerShell:
Click site

Click wwwroot

The wwwroot folder contains the files served by your web app.

Step 7: Replace the Default App Code

Locate the hostingstart.html file
Click Edit

Clear the existing content
Paste your application code

Save the file

This replaces the default Azure page with your own app.

Step 8: Verify the Application Is Running

Return to the Azure Portal
Open your App Service

Click the Default domain again

You should now see your custom application live and running.

Step 9: Clean Up Resources (Cost Awareness)

After testing:

Delete the App Service
Delete the App Service Plan
Or delete the entire Resource Group

In Azure, unused resources continue to incur costs — cleaning up is part of responsible cloud usage.

How This Fits into the Bigger Azure Journey

This exercise builds naturally on previous Azure concepts:

Virtual Machines → full control, more management
Virtual Machine Scale Sets → scalable infrastructure
App Service → managed platform with faster deployment

From creating virtual machines, capturing images, building scale sets, and now deploying applications using App Service, this journey highlights how Azure supports multiple levels of abstraction — from infrastructure to fully managed platforms.

Conclusion

Deploying an application using Azure App Service and the PowerShell Debug Console is a simple yet powerful way to understand how platform-as-a-service works in practice.

By preparing the code, creating the App Service, enabling authentication, and deploying directly into wwwroot, you can quickly get an application live without worrying about servers.

This hands-on approach reinforces an important cloud principle:
choose the service that matches your workload — not every solution needs a virtual machine.

From Virtual Machines to Virtual Machine Scale Sets

Ganiyat Olagoke Adebayo — Wed, 28 Jan 2026 16:12:00 +0000

After exploring Azure Virtual Machines and resource management, the next logical step is creating Azure Virtual Machine Scale Sets (VMSS) — a service designed to deploy and manage multiple identical VMs automatically.

VMSS builds on the same VM fundamentals but introduces scalability, availability, and automation, which are essential in real-world cloud environments.

What Is Azure VM Scale Set?

Explain simply:

A VMSS is a group of identical VMs
Managed as one unit
Automatically scales based on demand

One VM handles traffic. VMSS handles growth.

Why VM Scale Sets Matter

Cover real-world benefits:

Automatic scaling (up & down)
High availability
Load balancing integration
Cost efficiency (pay only for what you need)

VM vs VM Scale Set (Simple Comparison)

Azure VM	VM Scale Set
Single instance	Multiple instances
Manual scaling	Auto-scaling
Basic availability	High availability

Core Components of VMSS

Introduce key concepts:

Instance count
Scaling rules
Load Balancer
Availability Zones
Upgrade policies

When to Use VM Scale Sets

Examples:

Web applications
APIs
Background processing
Seasonal or unpredictable traffic

Here is A step-by-step guide

Step 1: Create a Virtual Machine (Foundation)

Every scalable system starts with a single, well-configured VM.

Create a Virtual Machine in Azure Portal

Choose:
- Image (Windows/Linux)

VM size
Authentication (password or SSH key)

Configure networking and security rules

Deploy the VM

Why this matters:
This VM becomes the template for scaling later.

Step 2: Add and Configure an Additional Disk

Once the VM is running, you can extend its storage.

Steps:

Open the VM → Disks

Click Create and attach a new disk
Select disk type (Standard / Premium)

Attach and save
Initialize and format the disk inside the VM (OS level)

To complete this set up check out my Blog on

https://dev.to/adebayo_ganiyatoladunjoy/how-to-add-a-data-disk-to-an-azure-virtual-machine-windows-linux-331n

Why this matters:
Real workloads often require multiple disks — OS + data + logs.

Step 3: Prepare the VM for Imaging

Before capturing an image, the VM must be cleaned and generalized.

For Windows:

Run Sysprep
Shut down the VM

For Linux:

Deprovision the VM
Shut down the VM

VM must be Stopped (deallocated) before capture.

Why this matters:
This ensures every future VM created from the image starts fresh.

Step 4: Create an Azure Compute Gallery

Azure Compute Gallery (formerly Shared Image Gallery) helps manage VM images.

Steps:

Create an Azure Compute Gallery

Create an Image Definition

OS type
VM generation
Publisher / Offer / SKU

Capture the VM into the gallery as an Image Version

Why this matters:
The gallery makes your image:

Reusable
Versioned
Scalable across regions

Step 5: Capture the VM Image

Now you turn your configured VM into a reusable image.

Steps:

From the VM → Capture

Select Azure Compute Gallery

Choose the image definition

Create a new image version

Once completed:

From the image created, we can further create a virtual machine or a virtual machine skill set. Here, as the title implies, we are creating a ** virtual machine skill sets

The VM image is ready
The original VM is no longer needed for scaling

Step 6: Create a Virtual Machine Scale Set (VMSS)

Now comes the scaling part

Steps:

Create **Virtual Machine Scale Set

Choose the **custom image from the Compute Gallery

Configure:

Instance count (min / max)
Autoscaling rules
Attach:
Load Balancer
Networking
Review and deploy

Result:
Azure deploys multiple identical VMs automatically based on demand.

Step 7: Monitor and Scale

Once deployed:

Monitor CPU, memory, and traffic
Azure automatically:
- Scales out during high demand
- Scales in when demand drops

Why this matters:
This is how production-grade cloud applications are built.

Clean-Up: Delete Resources to Optimize Cost

After creating the virtual machine skill sets and confirmed that it works as expected, it’s important to clean up unused resources.

For learning and practice environments:

Virtual Machines
Disks
Public IPs
Load Balancers
Image versions (if no longer needed)

…can continue to incur costs if left running.

Deleting resources you no longer need helps you:

Control cloud spending
Practice good cloud governance habits
Build cost-awareness early in your cloud journey

In the cloud, what you don’t delete, you pay for.

Bringing It All Together

This hands-on process connects multiple Azure concepts into one complete workflow:

Create a Virtual Machine – the foundation
Add and initialize a data disk – realistic storage setup
Prepare and capture the VM image – consistency and reusability
Store the image in Azure Compute Gallery – versioned image management
Create a Virtual Machine Scale Set – scalability and high availability

What starts as a single virtual machine evolves into a scalable, automated system capable of handling real-world workloads.

This journey reinforced an important lesson for me:
scalability isn’t a separate feature — it’s the result of intentional, well-planned steps.

Key Takeaways (Perfect Blog Closing)

A single VM can become a scalable system
Azure Compute Gallery enables consistency
VM Scale Sets automate availability and scaling
Planning images correctly saves time and cost

This journey helped me understand that scaling isn’t magic — it’s structured preparation.

AWS CloudTrail: Tracking Activity and Changes in Your AWS Account

Ganiyat Olagoke Adebayo — Mon, 26 Jan 2026 14:21:54 +0000

AWS CloudTrail: Tracking Activity and Changes in Your AWS Account

Quick Recap: Where We Are in Our AWS Journey

In previous posts, we:

Created an EC2 instance to run an application
Used Auto Scaling to manage traffic automatically
Set up CloudWatch to monitor performance and receive alerts

Monitoring performance is important, but it doesn’t tell us who did what inside our AWS account.
This is where AWS CloudTrail comes in.

What Is AWS CloudTrail?

AWS CloudTrail is a service that records all actions taken in your AWS account.

It helps you answer questions like:

Who launched or stopped an EC2 instance?
Who modified a security group?
When was Auto Scaling changed?
Which IAM user or role made the change?

CloudTrail is essential for security, auditing, and troubleshooting.

Why CloudTrail Is Important

CloudTrail helps you:

Track user and API activity
Investigate security incidents
Meet compliance and auditing requirements
Understand changes made across AWS services

Unlike CloudWatch (which monitors performance), CloudTrail monitors actions.

Step-by-Step: Creating a CloudTrail Trail

Step 1: Open CloudTrail

Sign in to the AWS Management Console
Search for CloudTrail
Click CloudTrail

Step 2: Create a Trail

Click Trails from the left menu
Click Create trail

Step 3: Configure Trail Settings

Fill in the following:

Trail name:
Example: management-event
Storage location:
Select Create new S3 bucket

AWS will automatically store your logs in this bucket.

Step 4: Choose Log Events

Select:

✅ Management events
✅ Read and Write events

Leave other options as default for beginners.

Step 5: Enable Trail for All Regions

Check Enable for all regions

This ensures all activity across AWS regions is logged.

Step 6: Create the Trail

Click Create trail

CloudTrail starts logging activity immediately.

Viewing CloudTrail Events

Step 1: Open Event History

In CloudTrail, click Event history

Here you’ll see:

Event name (e.g., StartInstances)
AWS service used
IAM user or role
Time of the event
Source IP address

Step 2: Filter Events

You can filter by:

Event name
User name
Resource type
Time range

This is very useful when investigating issues.

Example: What CloudTrail Can Show You

If you:

Start or stop an EC2 instance
Modify a security group
Create an Auto Scaling group
Change CloudWatch alarms

CloudTrail records who performed the action and when.

How CloudTrail Complements CloudWatch

Service	Purpose
CloudWatch	Monitors performance and triggers alarms
CloudTrail	Tracks user actions and API calls

Together, they provide visibility + accountability.

Best Practice for Beginners

Always enable CloudTrail
Store logs securely in S3
Review event history regularly
Use CloudTrail when troubleshooting unexpected changes

Final Thoughts

CloudTrail gives you confidence and control over your AWS account by recording every important action.

With EC2, Auto Scaling, CloudWatch, and CloudTrail, you now have:

Compute
Scalability
Monitoring
Auditing

A solid foundation for working in AWS

Amazon CloudWatch: Monitoring Your EC2 Instances

Ganiyat Olagoke Adebayo — Mon, 26 Jan 2026 13:50:03 +0000

Step 1: Recap – Creating an Amazon EC2 Instance

Before we get into Amazon CloudWatch, let’s quickly recap how we created an EC2 instance, since CloudWatch monitors resources like EC2.

Step 1.1: Open the EC2 Dashboard

Log in to the AWS Management Console
Search for EC2
Click EC2 to open the dashboard

Step 1.2: Launch an EC2 Instance

Click Launch instance

Enter an instance name
Choose an Amazon Machine Image (AMI) (for example, Amazon Linux)
Select an instance type (e.g., t2.micro for free tier)

Step 1.3: Configure Key Pair and Security Group

Create or select a key pair
Configure a security group

Allow SSH (port 22)
Allow HTTP (port 80) if running a web app

Step 1.4: Launch and Verify

Click Launch instance

Wait for the instance status to show Running

At this point, your application is running on EC2.

Why Monitoring Is Important After Creating EC2

Once an EC2 instance is running, it’s important to understand how it performs. Without monitoring:

You won’t know when CPU usage is high
Performance issues can go unnoticed
Auto Scaling cannot work effectively

This leads us to Amazon CloudWatch.

Step 2: Introduction to Amazon CloudWatch

Amazon CloudWatch is a monitoring service that collects metrics, logs, and events from AWS resources. It helps you monitor EC2 performance and respond to changes automatically.

Step 3: Viewing EC2 Metrics in CloudWatch

Step 3.1: Open CloudWatch

Search for CloudWatch in the AWS console
Click CloudWatch

Step 3.2: View EC2 Metrics

Click Metrics

Select EC2

Choose Per-Instance Metrics

Select CPUUtilization

You’ll see a graph showing how your EC2 instance is performing.

Step 4: Create a CloudWatch Alarm for EC2

Step 4.1: Create Alarm

Click Alarms

Click Create alarm

Select specify metric and condition

Select EC2 CPU utilization

Step 4.2: Set Threshold

Condition: CPU ≥ 75%

Evaluation period: as preferred
Click Next

Step 4.4: Create Alarm

Name the alarm

Click Create alarm

Step 4.3: Configure Notifications

Create or select an SNS topic

Create or select an Subscription

Enter your email

Confirm the email subscription

Step: Testing the CloudWatch Alarm Using Stress

After creating the CloudWatch alarm, it’s important to confirm that it works correctly. To do this, we will intentionally increase the CPU usage on our EC2 instance and observe whether the alarm sends an email notification.

Step 1: Connect to Your EC2 Instance

Go to EC2 → Instances
Select your running instance
Click Connect
Connect using EC2 Instance Connect or SSH

You should now be logged into your EC2 instance terminal.

Step 2: Install the Stress Tool

The stress tool is used to simulate high CPU usage.

Run the command below:

sudo yum install stress -y

This installs the stress utility on Amazon Linux.

Step 3: Generate High CPU Load

Once installation is complete, run the following command:

stress --cpu 2 --timeout 300

What this command does:

--cpu 2 → Uses 2 CPU workers to increase CPU usage
--timeout 300 → Runs the stress test for 300 seconds (5 minutes)

This will push the CPU utilization above the threshold set in your CloudWatch alarm.

Step 4: Monitor CPU Usage in CloudWatch

Open Amazon CloudWatch
Go to Metrics → EC2 → Per-Instance Metrics
Select CPUUtilization

You should see a noticeable spike in CPU usage.

Step 5: Confirm the Alarm State

Go to CloudWatch → Alarms
Select your alarm
The alarm status should change from OK to In alarm

Step 6: Confirm Email Notification

Check the email address linked to your SNS topic
You should receive an alarm notification indicating high CPU usage

This confirms that your CloudWatch alarm is working correctly.

Step 7: Alarm Returns to OK State

Once the stress command finishes (after 300 seconds):

CPU usage will drop
The alarm will automatically return to the OK state
You may receive another email notification (depending on your alarm settings)

Why This Test Is Important

Testing the alarm confirms that:

CloudWatch is correctly monitoring your EC2 instance
Notifications are properly configured
Auto Scaling (if enabled) can respond to real workload changes

Tip

Always test your alarms after creating them. An untested alarm is as risky as having no alarm at all.

How CloudWatch Works with Auto Scaling

CloudWatch alarms can trigger Auto Scaling actions when thresholds are met. This allows AWS to automatically add or remove EC2 instances based on demand.

Summary

You created an EC2 instance
CloudWatch monitors its performance
Alarms notify you when something changes
Auto Scaling uses CloudWatch data to scale automatically

Conclusion

Amazon CloudWatch is essential for monitoring EC2 instances and supporting Auto Scaling decisions. By combining EC2, Auto Scaling, and CloudWatch, you create a reliable and scalable AWS environment.

You can’t scale what you can’t monitor.

AWS Auto Scaling Explained: A Beginner-Friendly Step-by-Step Guide

Ganiyat Olagoke Adebayo — Thu, 22 Jan 2026 09:03:02 +0000

In my previous post, I explained how to create and use an Amazon EC2 instance to run applications in the AWS cloud. While EC2 gives you control over your servers, it requires manual effort to handle changes in traffic and workload.

As applications grow and traffic becomes unpredictable, managing capacity manually can be inefficient and costly. AWS Auto Scaling solves this by automatically adjusting the number of EC2 instances based on demand.
In the next section, we’ll walk through a step-by-step guide on how to set up AWS Auto Scaling from scratch.

What Is AWS Auto Scaling?

AWS Auto Scaling automatically adjusts the number of EC2 instances running in your application based on demand. When traffic increases, Auto Scaling adds more instances. When traffic decreases, it removes extra instances.

AWS Auto Scaling automatically increases or decreases the number of EC2 servers running your application based on traffic or usage.

More users → more servers added

Fewer users → extra servers removed

This keeps your application available while controlling costs.

Think of Auto Scaling like a security team at an event:

When more people arrive, more guards are added
When people leave, extra guards go home
The event runs smoothly without waste

Moving forward, in a previous post, we created an Amazon EC2 instance to run an application. As we progress, we will build on that setup and extend it by configuring AWS Auto Scaling.

Setting Up AWS Auto Scaling (Step by Step)

Step 1: Confirm Your EC2 Instance Is Running

Before setting up Auto Scaling:

Go to EC2 → Instances
Ensure your EC2 instance created earlier is running
Confirm it has:
- A working application
- A security group allowing required traffic (for example, HTTP on port 80)

This EC2 instance will be used as the base for Auto Scaling.

Step 2: Create an Auto Scaling Group

Click Auto Scaling Groups

Click Create Auto Scaling group

Enter a name
Select the launch template

Click Next

Step 3: Choose Network Settings

Select your VPC
Choose at least two subnets

Click Next

This improves availability.

Step 4 Attach a Load Balancer (Recommended)

Choose Attach to a new load balancer
Select Application Load Balancer
Enable Health checks

This ensures traffic is shared and unhealthy instances are replaced.

Step 5: Set Capacity Limits

Define how many servers can run:

Desired capacity: 1
Minimum capacity: 1
Maximum capacity: 3

Click Next.

Step 6: Configure Scaling Policy

This tells AWS when to scale.

Choose Target tracking scaling
Metric: Average CPU utilization
Target value: 50%

AWS will now scale automatically.

Step 7: Review and Create

Review your settings
Click Create Auto Scaling group

Your EC2-based application is now fully scalable.

What Just Happened?

You started with one EC2 instance
Auto Scaling now launches identical EC2 instances when needed
Extra instances are removed when traffic drops

User traffic reaches the Load Balancer → traffic is shared across EC2 instances → Auto Scaling monitors CPU usage → new instances are added when demand increases → unused instances are removed when demand drops.

When Should You Use Auto Scaling?

Use Auto Scaling when:

Traffic is unpredictable
You want high availability
You want to reduce costs
You don’t want to manage servers manually

Final Thoughts

AWS Auto Scaling helps your application stay online, responsive, and cost-efficient without manual effort. It works perfectly with EC2, Load Balancers, and Elastic Beanstalk, making it a core AWS service every beginner should understand.

Without Auto Scaling, a single EC2 instance can become overwhelmed or fail. By extending your EC2 setup with Auto Scaling, you ensure better performance, availability, and cost control.

Auto Scaling does not replace EC2—it builds on it to make your application scalable and reliable.

A Step-by-Step Guide to AWS Elastic Beanstalk :Simplifying Application Deployment

Ganiyat Olagoke Adebayo — Wed, 24 Dec 2025 21:02:01 +0000

Deploying applications in the cloud can sometimes feel overwhelming, especially when you have to manage servers, scaling, monitoring, and security on your own. This is where AWS Elastic Beanstalk comes in.

AWS Elastic Beanstalk is a service that makes it easy to deploy, manage, and scale applications on AWS without worrying about the underlying infrastructure. You simply upload your application, and Elastic Beanstalk automatically handles the setup and management for you.

Elastic Beanstalk supports popular platforms such as:

Java
.NET
Node.js
Python
PHP
Ruby
Docker

How AWS Elastic Beanstalk Works

When you deploy an application using Elastic Beanstalk, AWS automatically provisions and manages the required resources, including:

Amazon EC2 instances
Load balancers
Auto Scaling groups
Monitoring and health checks

Although Elastic Beanstalk manages these resources for you, you still have access to them if you need more control.

Benefits of AWS Elastic Beanstalk

Some key benefits include:

Easy deployment – Upload your application and let AWS handle the rest
Automatic scaling – Your application scales up or down based on traffic
Cost-effective – You only pay for the AWS resources used
Less infrastructure management – Focus more on development, less on servers
Flexible control – You can customize settings when needed

AWS Elastic Beanstalk vs Amazon EC2

A simple way to understand the difference:

Amazon EC2:
You are responsible for managing servers, updates, scaling, and monitoring.
AWS Elastic Beanstalk:
AWS manages the infrastructure, while you focus on your application.

Elastic Beanstalk actually runs on EC2, but it removes the complexity of managing everything manually.

When Should You Use AWS Elastic Beanstalk?

AWS Elastic Beanstalk is a good choice if:

You want a fast and easy way to deploy applications
You do not want to manage servers directly
You are new to AWS and want a simpler starting point
You need automatic scaling and monitoring

Here is a Step-by-Step Guide to Creating an AWS Elastic Beanstalk Application

Step 1: Sign in to the AWS Management Console

Go to the AWS Management Console and sign in with your AWS account.

Step 2: Navigate to Elastic Beanstalk

In the AWS search bar, type Elastic Beanstalk
Click Elastic Beanstalk from the services list

Step 3: Create a New Application

Click Create application

Enter an Application name (for example: getting-started-app)
(Optional) Add a description

Step 4: Choose Your Platform

Under Platform, select the programming language your app uses
Examples:
- Node.js
- Python
- PHP
- Java
- .NET
Choose the platform version (you can leave the default)

Step 5: Upload Your Application Code

Under Application code, choose:
- Sample application (recommended for first-time users),

Upload your code (if you already have an app)
- If uploading your code, select your file (ZIP format)

Step 6: Configure Application Settings (Service Role, Instance Profile, and Key Pair)

Before creating the environment, you need to configure security and access settings so Elastic Beanstalk can manage AWS resources and you can securely access your EC2 instances.

Step 6.1: Configure the Elastic Beanstalk Service Role

The service role allows Elastic Beanstalk to interact with other AWS services on your behalf.

To configure service access
Next, you need two roles. A service role allows Elastic Beanstalk to monitor your EC2 instances and upgrade your environment’s platform. An EC2 instance profile role permits tasks such as writing logs and interacting with other services.

To create or select the Service role If you have previously created a Service role and would like to choose an existing one, select the value from the Service role drop-down and skip the remainder of these steps to create a Service role.

If you don't see any values listed for the Service role, or you'd like to create a new one, continue with the next steps.

For Service role, choose Create role.

For Trusted entity type, choose AWS service.

For Use case, choose Elastic Beanstalk – Environment.

Choose Next.

Verify that Permissions policies include the following, then choose Next:

AWSElasticBeanstalkEnhancedHealth

AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy

Choose Create role.

Return to the Configure service access tab, refresh the list, then select the newly created service role.

Step 6.2 To create or select an EC2 instance profile
The EC2 instance profile allows EC2 instances in your environment to access AWS services securely.
If you have previously created an EC2 instance profile and would like to choose an existing one, select the value from the EC2 instance profile drop-down and skip the remainder of these steps to create an EC2 instance profile.

If you don't see any values listed for EC2 instance profile, or you'd like to create a new one, continue with the next steps.

Choose Create role.

For Trusted entity type, choose AWS service.

For Use case, choose Elastic Beanstalk – Compute.

Choose Next.

Verify that Permissions policies include the following, then choose Next:

AWSElasticBeanstalkWebTier

AWSElasticBeanstalkWorkerTier

AWSElasticBeanstalkMulticontainerDocker

Choose Create role.

Return to the Configure service access tab, refresh the list, then select the newly created EC2 instance profile.

To finish configuring and creating your application
Step 6.3: Select a Key Pair

A key pair allows you to securely connect to the EC2 instances created by Elastic Beanstalk.

Search for key pair

Under EC2 key pair: Select an existing key pair, or Click Create a new key pair

Enter a key pair name

Download and store the key file securely

Without a key pair, you will not be able to connect to the EC2 instance using SSH.

Optional steps: networking, databases, scaling parameters, advanced configuration for updates, monitoring, and logging.

On the Review page, which shows a summary of your choices, choose Submit.

Step 6.4: Review Other Settings (Optional)

You can keep the default settings for now or adjust them if needed:

Instance type (EC2 size)

Auto scaling options

Environment variables

Security groups

Beginners can safely proceed with the default configuration.

Step 7: Create the Environment

Click Create application
AWS will automatically set up the required resources, including:
- EC2 instances
- Load balancer
- Auto Scaling group
- Monitoring and health checks

This process may take a few minutes. Once complete, your application will be live.

And your Beanstalk is LIVE

To access the EC2 created
On the AWS Console, search EC2

** Check the dashboard to confirm the instance status is running

Click on the App created and then connect

And here is the EC2 instance that was created while setting up the Elastic Beanstalk

S3 Bucket created

Auto Scaling group created

Step 8: Terminate the Application

** To stop billing: Terminate the environment when you’re done
To delete the application and all associated resources
Delete all application versions.

Open the Elastic Beanstalk console, and in the Regions list, select your AWS Region.

In the navigation pane, choose Applications, and then choose getting-started-app.

In the navigation pane, find your application's name and choose Application versions.

On the Application versions page, select all application versions that you want to delete.

Choose Actions, and then choose Delete.

Turn on Delete versions from Amazon S3.

Choose Delete, and then choose Done.

Terminate the environment.

In the navigation pane, choose getting-started-app, and then choose GettingStartedApp-env in the environment list.

Choose Actions, and then choose Terminate Environment.

Confirm that you want to terminate GettingStartedApp-env by typing the environment name, and then choose Terminate.

Delete the getting-started-app application.

In the navigation pane, choose the getting-started-app.

Choose Actions, and then choose Delete application.

Confirm that you want to delete getting-started-app by typing the application name, and then choose Delete.

Conclusion

AWS Elastic Beanstalk simplifies application deployment by handling infrastructure management for you behind the scenes. It is a great option for developers who want the power of AWS without the complexity of managing servers manually.

From Azure VMs to AWS EC2 — Learning Compute Across Clouds

Ganiyat Olagoke Adebayo — Wed, 17 Dec 2025 11:55:57 +0000

As I continue learning Microsoft Azure, I’ve started exploring Amazon Web Services (AWS) to understand how core cloud concepts translate across platforms.

Today, I worked on creating an EC2 (Elastic Compute Cloud) instance — AWS’s virtual server service. While the interface and terminology differ from Azure Virtual Machines, the fundamentals remain the same:

Choose an image
Select instance size
Configure networking & security
Launch and connect

Amazon Elastic Compute Cloud (EC2) is an AWS service that lets you run virtual servers in the cloud whenever you need them. Instead of buying physical hardware, you can quickly create servers online and start building or running applications faster and at a lower cost.

With EC2, you can choose how many servers you need, set up security and networking, and manage storage easily. You can increase server capacity when you have heavy workloads or high website traffic, and reduce it again when demand is low, helping you save costs.

An EC2 instance is simply a virtual server in AWS. When you create one, you choose an instance type, which decides how much computing power, memory, networking, and storage the server will have.

Documenting these similarities and differences is helping me strengthen my cloud fundamentals and build a true multi-cloud mindset.

Here’s a step-by-step guide from my hands-on experience:

Sign in & Navigate

Log in to your AWS Management Console.
Go to the EC2 service under “Compute.”

Click Launch Instance to start creating your virtual server.

Add Tag

Choose an Amazon Machine Image (AMI)

Pick a pre-configured operating system (Linux, Windows, etc.).
Think of it like choosing the OS for an Azure VM — same concept, different interface.

Add key pair

Select RDP and http

Launch & Connect

Review all settings and click Launch.

*Generate and copy the password

Download the key pair (.pem file) to securely connect via SSH (Linux) or RDP (Windows).

Download the RDP file and connect with the copied password

Congratulations! Your EC2 instance is live.

Start surfing the internet

EC2 creation feels different from Azure VMs at first, but the cloud fundamentals are consistent.
Documenting these steps helps me compare platforms and strengthen my multi-cloud skills.

# 🧹 Azure Management Series — Cleaning Up Resources Safely in Azure

Ganiyat Olagoke Adebayo — Mon, 15 Dec 2025 09:36:10 +0000

When working in Azure—especially during guided projects, labs, or training—it's easy to accumulate resources that continue running in the background. Virtual machines, disks, storage accounts, and networking components can quietly incur charges even when you're no longer using them.

That’s why cleanup is the final and most critical step. In this post, you’ll walk through the Azure cleanup process for the guided project environment—removing locks, deleting the resource group, and ensuring no leftover infrastructure continues to generate costs.

Let’s dive in! 👇

Why Cleanup Matters

Azure resources cost money as long as they exist—even if they’re not running.

Proper cleanup helps you:

Avoid surprise charges
Keep your Azure environment tidy and manageable
Ensure you start fresh for future labs or projects
Follow best practices for real-world cloud resource lifecycle management

Once you're done with a lab or temporary environment, deleting the resource group is the fastest and cleanest way to remove everything at once.
But first—you must clear any delete locks.

Exercise — Clean Up Azure Resources

Below is the step-by-step process to safely remove all resources created during the guided project.

1. Remove Delete Locks

Delete locks prevent accidental deletion—but they also prevent the resource group from being removed. So you must remove them first.

Steps:

Log in to Azure Portal → https://portal.azure.com
In the search bar, type Virtual machines
Select guided-project-vm
Under Settings, choose Locks
Locate VM-delete-lock, then click Delete
Confirm deletion in the pop-up

If you created additional delete locks during previous exercises, remove those as well.

The VM is now ready to be deleted.

2. Delete the Project Resource Group

This is the quickest way to delete all resources created for the guided project.

Steps:

In the portal search bar, type Resource groups
Select guided-project-rg
Click Delete resource group
Check Apply force delete…
Type guided-project-rg to confirm
Select Delete
Confirm once more in the pop-up

The deletion may take about 5 minutes.
Refresh the page until the group disappears.

Important Reminder: NetworkWatcherRG

Azure sometimes creates a NetworkWatcherRG resource group automatically.

You must check whether it already existed before the project:

If it existed originally → DO NOT delete it
If Azure created it during this project → you MUST delete it

To delete it (only if required):

Open Resource groups
Select NetworkWatcherRG
Choose Delete resource group
Confirm with the name
Delete

Again, it may take around 5 minutes.

Final Thoughts — And What’s Next

Congratulations! You’ve completed the final step of the guided Azure Management Project: performing a proper cleanup.

This brings your entire project cycle full-circle:

You prepared the environment
Created networks and subnets
Deployed and managed virtual machines
Controlled storage access
Applied tags and locks
And now… safely removed all resources

You're now ready for the cloud adventure, where you’ll expand into more advanced Azure responsibilities and continue developing real-world cloud management skills.

Azure Management Series — Managing Tags & Locks in Azure

Ganiyat Olagoke Adebayo — Wed, 10 Dec 2025 11:55:29 +0000

Introduction

Having completed the previous exercises, you’ve managed to add a subnet to a virtual network, made changes to a virtual machine, and worked with an Azure storage account.

As your Azure environment grows, keeping resources organized and protected becomes essential. Tags help you track metadata such as cost centers, owners, and environments—while locks ensure that important resources cannot be accidentally deleted or modified.
In this post, you’ll learn how to apply tags, manage resource locks, and strengthen governance across your Azure resources, building on the work you completed in the previous exercises.

Step-by-Step Guide

Add a Tag to a Resource

Log in to Azure Portal: https://portal.azure.com
Select virtual machines under services.
Select guided-project-vm virtual machine
From the left menu, select Tags.
Click + Add.
Add the following tag:

On one line * Name: Department
* Value: Customer Service
On the next line
* Name: Purpose
* Value: FTP Server

Select Save. Select Apply

Your resource now has metadata attached for easier tracking and reporting.

Create a Resource Lock

Locks prevent accidental deletion or changes to a resource, so While you’re working on the virtual machine, it’s a great time to add a resource lock..

expand the Settings submenu.
Select Locks
Select + Add.

For the name, enter VM-delete-lock.
For the Lock type, select Delete. You may enter a note to help remind you why you created the lock.

Select OK.

Now, your storage account cannot be deleted until the lock is removed.

Test the Lock

You can go ahead to test the lock by:

Open the storage account.
Select Delete.
You’ll receive an error because the resource is locked.
Cancel the operation — the lock works as expected.

That’s it. Now the VM is protected from deletion and has tags assigned to help track use. Time to move onto the network.

Add tags to network resources

Select Home to return to the Azure portal home page.
From the Azure portal home page, in the search box, enter virtual networks.
Select virtual networks under services.
Select the guided-project-vnet network.
From the menu pane, select Tags.

Note: Notice that now you can select an existing tag to apply or add a new tag. You can also select just the name or value and apply create something new in the other field.

For the Name select Department.
For the Value enter IT.
Select Apply.

Now both the VNet and VM have are organized.

Conclusion

Great work! You’ve now improved governance in your Azure environment by using tags for organization and locks for protection. These small steps make resource management more scalable and secure—especially in environments with multiple admins or large deployments.

Next, we move to the final step of this series:
Cleaning Up Azure Resources Safely and Efficiently.

# 🚀 Azure Storage Series — Controlling Storage Access with Containers, File Shares & SAS Tokens

Ganiyat Olagoke Adebayo — Wed, 10 Dec 2025 09:47:32 +0000

As organizations generate more files and application data, secure and efficient storage management becomes critical.
The Azure admin wants you to get more familiar with storage accounts, containers, and file shares. They anticipate needing to share an increasing number of files and need someone who is skilled using these services. They’ve given you a task of creating a storage container and a file share and uploading files to both locations. In this hands-on Azure lab, we explore how to:

Create a Blob Storage Container
Upload and manage files
Change Blob Access Tiers
Create a File Share
Secure access using a Shared Access Signature (SAS)
Revoke access by rotating access keys

This exercise is perfect for beginners building real-world Azure storage skills.

Prerequisites

Before starting, make sure you already have:

An active Azure subscription
A Storage Account created earlier
Access to the Azure Portal
A file saved on your computer to upload (an image or document)

Part 1: Create a Storage Container

Log in to the Azure portal: https://portal.azure.com
In the search bar, type Storage accounts
Select your previously created storage account

Under Data storage, select Containers
Click + Add container
Enter the name: storage-container
Click Create

Your blob container is now ready.

Part 2: Upload a File to the Storage Container

Open storage-container
Click Upload
Select a file from your computer
Click Upload

Once uploaded, Azure automatically assigns it to the Hot access tier.

Part 3: Change the Blob Access Tier (Hot → Cold)

Select the uploaded file
Click Change tier

Choose Cold
Click Save

This reduces storage cost for files that are accessed less frequently.

Part 4: Create a File Share

Go back to your Storage Account

Under Data storage, select File shares
Click + File share
Name it: file-share

Open the Backup tab
Uncheck Enable backup

Click Review + create → Create

Now, click Upload and upload the same file or any other file.

You now have both Blob Storage and File Share storage configured.

Part 5: Secure Access Using Shared Access Signature (SAS)

Instead of giving full access to your storage account, Azure allows you to grant temporary, limited access using a SAS token.
The next piece of the puzzle is figuring one way to control access to the files that have been uploaded. Azure has many ways to control files, including things like role-based access control. In this scenario, we shall use shared access tokens or keys.

Generate a SAS Token

Open your Storage Account
Select Storage browser

Expand Blob containers

Open storage-container

Click the three dots (⋯) next to your uploaded file
Select Generate SAS

Configure the SAS

Signing method: Account key
Signing key: Key 1

Permissions: Read
Allowed protocol: HTTPS only
Leave Start & Expiry time as default (or customize)

Click Generate SAS token and URI

Copy the Blob SAS URL and open it in a new browser tab.

Your file should display immediately.

This means:
👉 Anyone with this link can access the file
👉 Only for the duration you specified

Part 6: Revoke Access by Rotating Keys🔄

To disable the SAS link, we rotate the key that created it.

Go to the Storage Account
Open Security + networking

Select Access keys

Under Key 1, click Rotate key
Confirm by clicking Yes

Now return to your SAS URL tab and refresh the page.

❌ You should now see an authentication failed error

This confirms the SAS access has been successfully revoked.

Key Takeaways

Azure Blob Storage is used for unstructured data like images and backups
File Shares are useful for shared file systems
Access tiers help optimize storage costs
SAS tokens allow temporary, secure access
Key rotation instantly revokes shared access

Conclusion

In this lab, you successfully:

Created a Blob container & File share
Uploaded files to both storage services
Changed a blob from Hot to Cold
Generated a secure SAS token
Revoked access using key rotation

These skills are essential for Azure administrators, cloud engineers, and DevOps professionals who manage real-world storage environments.

# 🛰️ Azure Networking Series — Creating a Subnet, NSG, and Securing an FTP Server Environment

Ganiyat Olagoke Adebayo — Thu, 04 Dec 2025 11:24:35 +0000

In this part of the Azure project, you’re assisting an Azure Administrator with maintaining and organizing cloud resources. There’s an underutilized Linux virtual machine, and the team needs a new Linux VM that will serve as an FTP server.

Before deploying that VM, you must first prepare the network properly. The admin wants to track network flow and resource utilization for the upcoming FTP server, so you’ll start by creating a new subnet — separate from the existing one — and securing it with a Network Security Group (NSG).

This ensures better isolation, higher security, and cleaner management for SFTP/FTP-related traffic.

Let’s walk through the steps.

Step 1 — Create a New Subnet on an Existing Virtual Network (VNet)

1. Log into Azure

Go to: https://portal.azure.com

2. Open Virtual Networks

In the search bar, type “virtual networks”
Select Virtual networks under Services
Choose guided-project-vnet

3. Add a New Subnet

On the vNet blade, under Settings, select Subnets
Click + Subnet

Leave Subnet purpose as Default
For Name, enter: ftpSubnet
Leave all other settings unchanged
Select Add

You have successfully created a new subnet!
This subnet will be dedicated to SFTP/FTP workloads, separate from the main subnet.

Step 2 — Create a Network Security Group (NSG)

To secure the new subnet, you’ll create an NSG that controls which traffic is allowed.

1. Navigate to Network Security Groups

Go back to Home
Search for Network security groups

Select Network security groups under services
Click + Create

2. Configure the NSG

Confirm the correct Subscription
Choose Resource Group → guided-project-rg
Name → ftpNSG
Select Review + create → then Create

When deployment completes, click Go to resource.

Step 3 — Add an Inbound Security Rule

The FTP/SFTP server needs SSH traffic (Port 22), so you’ll create an allow rule.

1. Open Inbound Security Rules

Under Settings, select Inbound security rules

Click + Add

2. Configure the Rule

Destination port range → change from 8080 to 22
Protocol → TCP
Name → ftpInbound
Select Add

You’ve now created a network security group with SSH (port 22) allowed, suitable for an FTP/SFTP server environment.

Step 4 — Associate the NSG with the Subnet

Now link the NSG to the subnet you created earlier.

1. Navigate back to the VNet

Go to Home
Search virtual networks
Select guided-project-vnet

2. Apply the NSG to the Subnet

Under Settings, select Subnets
Choose ftpSubnet

Under Security, set Network security group → ftpNSG

Click Save

Done! The subnet is now protected with your NSG.

Conclusion

In this exercise, you prepared the network layer for a future FTP server by:

✔ Creating a new, isolated subnet
✔ Building a Network Security Group
✔ Adding an inbound SSH rule
✔ Associating the NSG with the subnet

This ensures the upcoming Linux FTP VM will sit in a secure, well-structured environment, with traffic carefully controlled.

You're now ready for the next step: deploying and configuring the Linux VM that will serve as your FTP server.