Azure Foundations & Azure Functions

Review of Azure fundamentals, with a special focus on Azure Functions - a powerful serverless compute service that enables event-driven, scalable applications without managing infrastructure.

Part 1: Azure Foundations Review

1.1 Core Azure Concepts

Before diving into Azure Functions, let's consolidate the foundational knowledge from our Azure modules. Understanding these concepts is essential because everything in Azure builds on this hierarchy.

Azure Resource Hierarchy

Understanding how Azure organizes resources is critical for proper cloud architecture. Think of it like organizing files on your computer - you have folders within folders, and Azure works the same way but with cloud resources:

Key Principle: Always group related resources together. When you delete a Resource Group, all resources inside are deleted too. This makes cleanup easy - delete one Resource Group and everything associated with your project is gone.

1.2 Essential Azure CLI Commands

The Azure CLI is your primary tool for managing Azure resources from the command line. While you can do everything in the Azure Portal (web interface), the CLI is faster, scriptable, and essential for automation.

Why Use CLI Instead of Portal?

Portal (Web)	CLI (Command Line)
Click through menus	Type commands
Good for learning, exploring	Good for automation, scripting
Hard to repeat exact steps	Easy to save commands as scripts
Takes time with many resources	Fast, can process many resources quickly

Account & Subscription Management

When you first start with Azure, you need to authenticate (login) and select which subscription to work with. Think of a subscription as your Azure "account" - it's where all your resources live and where billing happens.

# Login to Azure
# This opens a browser window where you enter your Azure credentials
az login

# Login for headless/server environments (no browser available)
# Useful for VMs, remote servers, or CI/CD pipelines
# It gives you a code to enter at microsoft.com/devicelogin
az login --use-device-code

# Show current subscription context
# Tells you which subscription you're currently working with
az account show

# List all available subscriptions
# If you have multiple Azure accounts or subscriptions, this shows them all
az account list --output table

# Set active subscription
# Switch to a different subscription (useful if you have dev/prod subscriptions)
az account set --subscription "Your-Subscription-Name"

# Show your assigned roles
# What permissions do you have? This command shows your role assignments
az role assignment list --assignee $(az ad signed-in-user show --query id -o tsv) --output table

Understanding Subscriptions:

Most students have a single "Azure for Students" subscription with $100 credit. In enterprise environments, companies often have multiple subscriptions to separate billing and access:

• Development subscription - for testing, experimentation

• Production subscription - for live applications

• Sandbox subscription - for learning, no restrictions

Resource Group Operations

Resource Groups are containers that hold related resources for an Azure solution. Think of them as project folders - everything for one project goes in one Resource Group.

Best Practice: Create a new Resource Group for each lab or project. This way, when you're done, you can delete the entire Resource Group and clean up all resources at once.

# Create a resource group
# Every resource needs a Resource Group and a location (Azure region)
az group create \
  --name myResourceGroup \
  --location westeurope

# List all resource groups
# See all Resource Groups in your subscription
az group list --output table

# Show resource group details
# Get information about a specific Resource Group
az group show --name myResourceGroup

# List all resources in a group
# See what's inside a Resource Group
az resource list --resource-group myResourceGroup --output table

# Delete a resource group (and ALL resources inside!)
# WARNING: This is permanent! All VMs, databases, storage - everything is deleted
# --yes skips confirmation prompt
# --no-wait runs the deletion in background (doesn't wait for completion)
az group delete --name myResourceGroup --yes --no-wait

Command Flag Reference:

Flag	What It Does
--name or -n	Name of the resource
--location or -l	Azure region (westeurope, eastus, etc.)
--output or -o	Output format: table, json, yaml, tsv
--yes or -y	Skip confirmation prompts
--no-wait	Don't wait for operation to complete

Region & Location Management

Azure has datacenters around the world. When you create resources, you choose where they physically live. This affects:

• Latency: Resources closer to users respond faster

• Compliance: Some data must stay in specific countries

• Cost: Some regions are cheaper than others

• Availability: Not all services are available in all regions

# List all available Azure regions
# Shows all datacenters where you can create resources
az account list-locations --output table

# Filter for European regions
# Use JMESPath query to filter results
az account list-locations --query "[?contains(name, 'europe')]" --output table

Common European Regions:

Region Name	Display Name	Use Case
westeurope	West Europe	Netherlands - main EU region
northeurope	North Europe	Ireland - backup/DR region
germanywestcentral	Germany West Central	Data residency in Germany
polandcentral	Poland Central	Closest to Poland

1.3 Virtual Machines - Key Commands

Virtual Machines (VMs) are the foundation of cloud computing. A VM is a computer running in Azure's datacenter that you control remotely. You can install any software, run any application - it's like having a server without buying hardware.

When to Use VMs:

• You need full control over the operating system

• Running legacy applications that can't be containerized

• Need specific software that only runs on Windows/Linux

• Learning and experimentation

When NOT to Use VMs:

• Running simple web applications (use App Service)

• Running containerized microservices (use Container Apps)

• Running event-driven code (use Azure Functions)

Creating Virtual Machines

# Create a Linux VM
# This creates an Ubuntu 22.04 VM with SSH key authentication
az vm create \
  --resource-group myResourceGroup \
  --name myVM \
  --image Ubuntu2204 \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-address myPublicIP

Understanding the VM Create Parameters:

Parameter	What It Means
--resource-group	Which Resource Group to put the VM in
--name	Name of your VM
--image	Operating system to install (Ubuntu2204, Win2022Datacenter, etc.)
--size	How powerful the VM is (CPU, RAM)
--admin-username	Username for logging in
--generate-ssh-keys	Create SSH keys for secure access (Linux only)
--public-ip-address	Create a public IP so you can connect from internet

Common VM Sizes for Learning:

Size	vCPUs	RAM	Cost/month (approx)	Use Case
Standard_B1s	1	1 GB	~$8	Very basic, testing only
Standard_B2s	2	4 GB	~$30	Development, learning
Standard_B2ms	2	8 GB	~$60	Small production workloads
Standard_D2s_v3	2	8 GB	~$70	General purpose production

B-series VMs are "burstable" - perfect for learning because they're cheap for workloads that don't use 100% CPU constantly.

# Create a Windows VM
# Note: Windows requires a password, not SSH keys
az vm create \
  --resource-group myResourceGroup \
  --name myWindowsVM \
  --image Win2022Datacenter \
  --size Standard_B2s \
  --admin-username azureuser \
  --admin-password 'YourSecurePassword123!'

Finding Images and Sizes

# List available VM sizes in a region
# Not all sizes are available in all regions!
az vm list-sizes --location westeurope --output table

# List available VM images
# There are thousands! Filter by what you need
az vm image list --offer Ubuntu --all --output table

# Common image shortcuts:
# Ubuntu2204     = Ubuntu 22.04 LTS
# Debian11       = Debian 11
# Win2022Datacenter = Windows Server 2022

Controlling VMs (Start, Stop, Deallocate)

Understanding the difference between stop and deallocate is crucial for cost management:

State	Description	Billing
Running	VM is on and working	Full cost
Stopped	OS shutdown, but resources still allocated	Still charged for compute!
Deallocated	Resources released back to Azure	No compute charges

Important: If you just run az vm stop, you still pay! Always use az vm deallocate to stop billing.

# Start a VM
az vm start --resource-group myResourceGroup --name myVM

# Stop a VM (OS shutdown, but still billed!)
az vm stop --resource-group myResourceGroup --name myVM

# Restart a VM
az vm restart --resource-group myResourceGroup --name myVM

# Deallocate VM (stop billing for compute!)
# This is what you want when you're done for the day
az vm deallocate --resource-group myResourceGroup --name myVM

Getting Information and Remote Access

# Get VM public IP address
# You need this to SSH or RDP into your VM
az vm show --resource-group myResourceGroup --name myVM \
  --show-details --query publicIps -o tsv

# Run a command on VM remotely (without SSH)
# Useful for VMs in private subnets or for automation
az vm run-command invoke \
  --resource-group myResourceGroup \
  --name myVM \
  --command-id RunShellScript \
  --scripts "apt update && apt install -y nginx"

1.4 Networking Fundamentals

Networking in Azure is about connecting your resources together and controlling what can communicate with what. This is fundamental for security - you don't want your database accessible from the internet!

Key Networking Concepts:

Concept	What It Is
VNet	Virtual Network - your private network in Azure
Subnet	A range of IP addresses within a VNet
NSG	Network Security Group - firewall rules for traffic
Public IP	An IP address accessible from the internet
Private IP	An IP address only accessible within your VNet
NAT Gateway	Allows outbound internet access from private subnets

Virtual Network (VNet) Operations

A VNet is your private, isolated network in Azure. Resources in a VNet can communicate with each other by default, but are isolated from other VNets and the internet.

IP Address Planning:

When you create a VNet, you define an address space using CIDR notation:

• 10.0.0.0/16 = 65,536 IP addresses (10.0.0.0 to 10.0.255.255)

• 10.0.1.0/24 = 256 IP addresses (10.0.1.0 to 10.0.1.255)

# Create a VNet with a subnet
# The VNet has a large address space (10.0.0.0/16)
# The subnet is a smaller piece of that (10.0.1.0/24)
az network vnet create \
  --resource-group myResourceGroup \
  --name myVNet \
  --address-prefix 10.0.0.0/16 \
  --subnet-name mySubnet \
  --subnet-prefix 10.0.1.0/24

# Add another subnet to the same VNet
# Maybe for a database or different tier of application
az network vnet subnet create \
  --resource-group myResourceGroup \
  --vnet-name myVNet \
  --name anotherSubnet \
  --address-prefix 10.0.2.0/24

# List subnets in a VNet
az network vnet subnet list \
  --resource-group myResourceGroup \
  --vnet-name myVNet \
  --output table

Common Subnet Layout:

Subnet Name	CIDR	Purpose
web-subnet	10.0.1.0/24	Web servers (public access)
app-subnet	10.0.2.0/24	Application servers (internal)
db-subnet	10.0.3.0/24	Database servers (most secure)

Network Security Groups (NSGs)

NSGs are Azure's firewall. They contain security rules that allow or deny network traffic to resources. Think of them as a bouncer at a club - they check every "packet" against rules and decide if it can enter or leave.

NSG Rule Components:

Component	What It Means
Priority	Lower number = evaluated first (100-4096)
Direction	Inbound (coming in) or Outbound (going out)
Access	Allow or Deny
Protocol	TCP, UDP, ICMP, or * (any)
Source/Destination Address	Where traffic is coming from/going to
Source/Destination Port	Which port (22=SSH, 80=HTTP, 443=HTTPS, etc.)

# Create an NSG
az network nsg create \
  --resource-group myResourceGroup \
  --name myNSG

# Add inbound rule (allow SSH from anywhere)
# Priority 100 = evaluated early
az network nsg rule create \
  --resource-group myResourceGroup \
  --nsg-name myNSG \
  --name Allow-SSH \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes '*' \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges 22

# Add outbound rule (deny all outbound traffic)
# Priority 4000 = evaluated late (after other rules)
az network nsg rule create \
  --resource-group myResourceGroup \
  --nsg-name myNSG \
  --name Deny-All-Outbound \
  --priority 4000 \
  --direction Outbound \
  --access Deny \
  --protocol '*' \
  --source-address-prefixes '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges '*'

# List NSG rules
az network nsg rule list \
  --resource-group myResourceGroup \
  --nsg-name myNSG \
  --output table

Common Security Rules:

Rule Name	Direction	Port	Purpose
Allow-SSH	Inbound	22	Remote access to Linux VMs
Allow-RDP	Inbound	3389	Remote access to Windows VMs
Allow-HTTP	Inbound	80	Web traffic (unencrypted)
Allow-HTTPS	Inbound	443	Web traffic (encrypted)
Deny-All	Inbound	*	Block everything else (catch-all)

Private Subnets & NAT Gateway

Security Best Practice: VMs should NOT have public IP addresses by default. Instead:

1. Put VMs in private subnets (no direct internet access)

2. Use NAT Gateway for outbound access (VMs can reach internet, but internet can't reach VMs)

3. Use Azure Bastion for administrative access (instead of public IPs)

# Create a private subnet (no default outbound access)
az network vnet subnet update \
  --resource-group myResourceGroup \
  --vnet-name myVNet \
  --name mySubnet \
  --default-outbound false

# Create NAT Gateway for controlled outbound access
# VMs can download updates, but internet can't initiate connections
az network public-ip create \
  --resource-group myResourceGroup \
  --name myNATGatewayIP \
  --sku Standard

az network nat gateway create \
  --resource-group myResourceGroup \
  --name myNATGateway \
  --public-ip-addresses myNATGatewayIP

# Associate NAT Gateway with subnet
az network vnet subnet update \
  --resource-group myResourceGroup \
  --vnet-name myVNet \
  --name mySubnet \
  --nat-gateway myNATGateway

1.5 Storage Fundamentals

Azure Storage is used to store files, blobs (binary large objects), queues, and tables. The most common use is Blob Storage - storing files like images, documents, backups, and logs.

Storage Account Hierarchy:

Storage Account (mystorageaccount123)
├── Blob Container (images)
│   ├── photo1.jpg
│   ├── photo2.jpg
│   └── subfolder/
│       └── photo3.jpg
├── Blob Container (backups)
│   └── database-backup.sql
└── Blob Container (logs)
    └── app-logs-2026-01.log

Storage Redundancy Options:

SKU	Description	Durability
Standard_LRS	3 copies in one datacenter	99.999999999%
Standard_ZRS	3 copies across 3 availability zones	99.9999999999%
Standard_GRS	6 copies: 3 local + 3 in another region	99.99999999999999%
Standard_RAGRS	Like GRS but can read from secondary region	Highest

For learning: Standard_LRS is cheapest and sufficient.

# Create a storage account
# Name must be globally unique! (only lowercase letters and numbers)
az storage account create \
  --resource-group myResourceGroup \
  --name mystorageaccount123 \
  --sku Standard_LRS \
  --location westeurope

# Create a blob container
# Containers are like folders for your blobs
az storage container create \
  --account-name mystorageaccount123 \
  --name mycontainer \
  --auth-mode login

# Upload a file to blob storage
az storage blob upload \
  --account-name mystorageaccount123 \
  --container-name mycontainer \
  --name uploaded-file.txt \
  --file ./local-file.txt \
  --auth-mode login

# List blobs in container
az storage blob list \
  --account-name mystorageaccount123 \
  --container-name mycontainer \
  --auth-mode login \
  --output table

Accessing Storage Securely:

There are several ways to access Azure Storage:

Method	Use Case
--auth-mode login	Use your Azure AD credentials (recommended)
Account Key	Full access to everything (dangerous if leaked!)
SAS Token	Limited, time-bound access to specific resources
Managed Identity	For Azure services to access storage securely

# Generate SAS token for secure, temporary access
# This token gives read-only access until Dec 31, 2025
az storage container generate-sas \
  --account-name mystorageaccount123 \
  --name mycontainer \
  --permissions r \
  --expiry 2025-12-31

Part 2: Azure Functions - Serverless Computing

Now let's dive into Azure Functions - one of the most powerful and practical Azure services for modern applications.

2.1 What Are Azure Functions?

Azure Functions is a serverless compute service that lets you run code without managing servers. You write the code, Azure handles everything else: scaling, infrastructure, patching, and availability.

2.2 Key Characteristics of Azure Functions

Feature	Description
Event-Driven	Functions are triggered by events (HTTP requests, timers, queues, file uploads)
Auto-Scaling	Automatically scales from 0 to thousands of instances based on demand
Pay-Per-Execution	You only pay when your code runs (Consumption plan)
Multiple Languages	Supports C#, JavaScript, Python, Java, PowerShell, TypeScript
Stateless by Default	Each execution is independent (use Durable Functions for stateful workflows)

2.3 Azure Functions Triggers

A trigger is what causes a function to execute. Understanding triggers is key to understanding Azure Functions:

Trigger Types Explained

Trigger	Use Case	Example
HTTP	REST APIs, webhooks, web services	User submits form → process data
Timer	Scheduled tasks, cron jobs	Every night at 2 AM → cleanup old files
Blob Storage	File processing	Image uploaded → resize/thumbnail
Queue Storage	Async processing, work queues	Order placed → process payment
Event Hub	High-volume event streaming	IoT devices → process sensor data
Cosmos DB	Database change events	Document updated → sync to search index
Service Bus	Enterprise messaging	Message received → notify systems

2.4 Hosting Plans

Azure Functions offers three hosting plans, each with different characteristics:

Plan	Scaling	Max Timeout	Cold Start	Best For
Consumption	Auto (0 → ∞)	5-10 min	Yes	Intermittent workloads, pay-per-use
Premium	Auto (1+ → ∞)	Unlimited	No	Production APIs, low latency required
Dedicated (App Service)	Manual	Unlimited	No	Existing App Service infrastructure

Cold Start Explained:

When using the Consumption plan, if your function hasn't been called recently, Azure may deallocate the resources. The next request needs to "wake up" the function, causing a delay (cold start). Premium plan keeps instances warm.

2.5 Real-World Scenarios

Here are practical examples of how Azure Functions are used in production:

Scenario 1: Image Processing Pipeline

The Problem: A company allows users to upload profile photos. These photos need to be resized into multiple formats (thumbnail, medium, large) for different parts of the website. Traditional approach would require running a server 24/7 just waiting for uploads.

The Serverless Solution: Use a Blob-triggered Azure Function that automatically activates whenever a new image is uploaded to Azure Blob Storage.

How It Works:

1. User uploads a photo through a web form

2. The photo is saved to Azure Blob Storage (container: "uploads")

3. Azure detects the new blob and automatically triggers the Function

4. The Function reads the image, creates resized versions using image processing libraries

5. Processed images are saved to another container (e.g., "processed")

6. The Function terminates and no compute resources are consumed until the next upload

Why This Is Powerful: If 1,000 users upload photos simultaneously, Azure automatically spins up 1,000 function instances to process them in parallel. When uploads stop, the system scales back to zero - you pay nothing while waiting.

Scenario 2: Microservices API Backend

The Problem: Building a REST API typically requires setting up a web server (like Express.js or Flask), configuring routing, managing server infrastructure, and handling scaling. For APIs with variable traffic, you end up paying for idle server time.

The Serverless Solution: Use HTTP-triggered Azure Functions where each API endpoint is a separate function. Azure handles all the server infrastructure, routing, and scaling automatically.

How It Works:

1. Frontend application (mobile app or website) makes an HTTP request to the function URL

2. Azure receives the request and routes it to the appropriate function based on the URL path

3. The function executes: reads request data, queries the database, processes the result

4. The function returns a JSON response to the frontend

5. After the response is sent, the function instance can be reused or terminated

Why This Is Powerful:

Each function can scale independently. If your /users endpoint gets 10x more traffic than /orders, Azure will automatically allocate more instances for /users while keeping /orders at minimal capacity.

This is the essence of microservices architecture - small, independent, single-purpose services.

Scenario 3: Scheduled Data Processing

The Problem: Many business operations need to run on a schedule - generating daily reports, cleaning up old database records, syncing data from external systems, or creating backups. Traditionally, this requires running a dedicated server with cron jobs or Windows Task Scheduler.

The Serverless Solution: Use Timer-triggered Azure Functions that run on a schedule defined using CRON expressions. No server needed - Azure wakes up the function at the specified time, runs it, and you pay only for execution time.

How It Works:

1. You define a CRON expression in the function configuration: "0 0 2 * * *" means "at 2:00 AM every day"

2. Azure's scheduler monitors this schedule and triggers the function at exactly 2:00 AM

3. The function performs ETL (Extract-Transform-Load): pulls data from sources, transforms it, and loads it to the destination

4. Function logs execution status and any errors for monitoring

5. After completion, the function terminates until the next scheduled run

Understanding CRON Expressions:

• "0 0 2 * * *" = At 2:00:00 AM every day

• "0 */5 * * * *" = Every 5 minutes

• "0 0 9-17 * * 1-5" = Every hour from 9 AM to 5 PM, Monday to Friday

• Format: {second} {minute} {hour} {day} {month} {day-of-week}

Why This Is Powerful:

You don't pay for a server running 24/7 just to execute a 5-minute job once per day. The function runs, completes its task, and you're billed only for those few minutes of execution.

Scenario 4: Real-Time Event Processing (IoT)

The Problem: IoT (Internet of Things) systems generate massive amounts of data - thousands of sensors sending readings every second. Processing this data in real-time requires infrastructure that can handle millions of events and scale instantly when traffic spikes.

The Serverless Solution: Use Event Hub-triggered Azure Functions. Azure Event Hub acts as a buffer that can ingest millions of events per second, and Azure Functions process these events in real-time, scaling automatically to match the incoming data rate.

How It Works:

1. IoT devices (temperature sensors, motion detectors, smart meters) continuously send data

2. Azure Event Hub receives all incoming events and stores them temporarily in partitions

3. Azure Functions are triggered by new events in Event Hub (batch processing for efficiency)

4. Each function instance processes a batch of events: analyzes data, detects anomalies, triggers alerts

5. Results are stored in a database and alerts are sent to monitoring systems

6. Functions scale up/down based on the event backlog in Event Hub

Real-World Example: A smart building with 10,000 temperature sensors. Each sensor sends a reading every 10 seconds. That's 1,000 events per second! If a temperature exceeds a threshold, the function immediately sends an alert to the maintenance team and logs the event.

Why This Is Powerful: Event Hub decouples the event producers (sensors) from consumers (functions). If the processing temporarily slows down, events are safely buffered. Functions scale independently to catch up with the backlog.

Scenario 5: Webhook Integration

The Problem: Modern applications need to integrate with external services - payment processors (Stripe), version control (GitHub), communication platforms (Slack, Twilio). These services notify your application about events via webhooks - HTTP POST requests sent to your endpoint.

The Serverless Solution: Use HTTP-triggered Azure Functions as webhook endpoints. When an external service sends a webhook, your function processes the event and takes appropriate actions (update database, send notifications, trigger workflows).

How It Works:

1. You create an HTTP-triggered function and get a public URL (e.g., https://myfunc.azurewebsites.net/api/github-webhook)

2. You configure the external service (GitHub, Stripe) to send webhooks to this URL

3. When an event occurs (code pushed, payment received), the service sends a POST request with event data

4. Your function parses the webhook payload, validates the signature (for security), and processes the event

5. The function performs actions: updates database, sends Slack notification, triggers other workflows

6. Returns a 200 OK response to confirm receipt

Security Consideration: Always validate webhook signatures! Services like GitHub and Stripe include a secret signature in the request header. Your function should verify this signature to ensure the webhook is authentic and not from a malicious source.

Why This Is Powerful: You get instant notifications about external events without polling APIs repeatedly. The serverless model is perfect for webhooks - they're sporadic (you don't know when they'll arrive), short-lived (just process and respond), and vary in volume (Black Friday vs. regular Tuesday).

2.6 Benefits of Azure Functions

Benefit	Description
No Infrastructure Management	Focus on code, not servers. No OS updates, no patching.
Automatic Scaling	Handles 1 request or 1 million - automatically
Cost Efficiency	Pay only for execution time (Consumption plan: first 1M executions free!)
Fast Development	Quick to deploy, easy to test, integrate with Azure services
Event-Driven Architecture	Natural fit for microservices and reactive systems
DevOps Friendly	Easy CI/CD integration, infrastructure as code with Terraform

2.7 Azure Functions vs Other Compute Options

When should you use Functions vs VMs vs Containers vs App Service?

Need	Best Choice	Reason
Run code occasionally, pay per use	Azure Functions	Scales to zero, pay-per-execution
API with consistent traffic	App Service or Premium Functions	Always warm, predictable performance
Full control over OS	Virtual Machines	Complete control, complex deps
Containerized microservices	Container Apps / AKS	Container orchestration, complex apps
Background job processing	Azure Functions (Queue trigger)	Event-driven, auto-scaling
Real-time data processing	Azure Functions (Event Hub)	High throughput, serverless

2.8 Creating Your First Azure Function

Creating an Azure Function involves two main steps:

1. setting up the infrastructure (Function App, storage account) and

2. writing the actual function code.

Let's walk through both.

What You Need to Understand First:

• Function App - A container that hosts one or more functions. Think of it like a project that groups related functions together.

• Storage Account - Required by Azure Functions to store internal data (function code, logs, trigger state). Every Function App needs one.

• Consumption Plan - The serverless billing model where you pay only for execution time. Functions scale automatically and can scale to zero when idle.Here's how to create and deploy a simple HTTP-triggered function:

Azure Functions can be written in different language than your main app language!

Using Azure CLI

The following commands create all the infrastructure needed to run Azure Functions. Each command builds on the previous one.

# Create a resource group
az group create \
  --name myFunctionAppRG \
  --location westeurope

# Create a storage account (required for Functions)
az storage account create \
  --name myfuncstorageacc123 \
  --resource-group myFunctionAppRG \
  --location westeurope \
  --sku Standard_LRS

# Create a Function App (Consumption plan - serverless)
az functionapp create \
  --resource-group myFunctionAppRG \
  --consumption-plan-location westeurope \
  --runtime python \
  --runtime-version 3.11 \
  --functions-version 4 \
  --name myuniquefunctionapp123 \
  --storage-account myfuncstorageacc123 \
  --os-type Linux

# List your function apps
az functionapp list --output table

# Get the URL of your function app
az functionapp show \
  --name myuniquefunctionapp123 \
  --resource-group myFunctionAppRG \
  --query defaultHostName -o tsv

Simple Python HTTP Function

Now let's look at the actual function code. Azure Functions use a decorator-based approach where you define what triggers the function using Python decorators.

Understanding the Code Structure:

# function_app.py
import azure.functions as func
import json

app = func.FunctionApp()

@app.function_name(name="HttpTrigger")
@app.route(route="hello", auth_level=func.AuthLevel.ANONYMOUS)
def hello(req: func.HttpRequest) -> func.HttpResponse:
    """
    Simple HTTP trigger function.
    Responds with a greeting message.
    """
    name = req.params.get('name', 'World')

    return func.HttpResponse(
        json.dumps({"message": f"Hello, {name}!"}),
        mimetype="application/json",
        status_code=200
    )

Line-by-Line Explanation:

• app = func.FunctionApp() - Creates the main application object that will host all your functions

• @app.function_name(name="HttpTrigger") - Gives this function a name for identification in Azure Portal

• @app.route(route="hello", ...) - Defines the HTTP endpoint. The function will be accessible at https://yourapp.azurewebsites.net/api/hello

• auth_level=func.AuthLevel.ANONYMOUS - No authentication required (anyone can call this endpoint)

• req: func.HttpRequest - The incoming HTTP request object containing headers, query params, body

• req.params.get('name', 'World') - Gets the name query parameter, defaults to "World" if not provided

• func.HttpResponse(...) - Returns an HTTP response with JSON body and status code

Testing Your Function:

Once deployed, you can test it with:

# Call the function with curl
curl "https://myuniquefunctionapp123.azurewebsites.net/api/hello"
# Response: {"message": "Hello, World!"}

curl "https://myuniquefunctionapp123.azurewebsites.net/api/hello?name=Student"
# Response: {"message": "Hello, Student!"}

Timer Trigger Example

Timer-triggered functions run on a schedule. They're perfect for recurring tasks like backups, reports, or data synchronization.

# function_app.py
import azure.functions as func
import logging

app = func.FunctionApp()

@app.function_name(name="DailyCleanup")
@app.schedule(schedule="0 0 2 * * *", arg_name="timer", run_on_startup=False)
def daily_cleanup(timer: func.TimerRequest) -> None:
    """
    Timer trigger function.
    Runs every day at 2:00 AM.
    CRON expression: second minute hour day month dayOfWeek
    """
    logging.info('Daily cleanup function started')

    # Your cleanup logic here
    # - Delete old files
    # - Archive logs
    # - Sync data

    logging.info('Daily cleanup completed')

Key Points About Timer Triggers:

• schedule="0 0 2 * * *" - CRON expression defining when to run (2:00 AM daily)

• run_on_startup=False - Don't run when the Function App starts (only on schedule)

• timer: func.TimerRequest - Contains information about the timer (past due status, schedule)

• Timer functions don't return anything (-> None) since there's no caller to respond to

Blob Trigger Example

Blob-triggered functions react to file uploads in Azure Blob Storage. They're ideal for file processing pipelines.

# function_app.py
import azure.functions as func
import logging

app = func.FunctionApp()

@app.function_name(name="ProcessImage")
@app.blob_trigger(arg_name="blob",
                  path="uploads/{name}",
                  connection="AzureWebJobsStorage")
def process_image(blob: func.InputStream) -> None:
    """
    Blob trigger function.
    Fires when a new file is uploaded to 'uploads' container.
    """
    logging.info(f'Processing blob: {blob.name}')
    logging.info(f'Blob size: {blob.length} bytes')

    # Read blob content
    content = blob.read()

    # Your processing logic here
    # - Resize image
    # - Extract text (OCR)
    # - Analyze content

    logging.info(f'Processing complete for {blob.name}')

Key Points About Blob Triggers:

• path="uploads/{name}" - Watches the "uploads" container. {name} captures the filename

• connection="AzureWebJobsStorage" - References the storage connection string from app settings

• blob: func.InputStream - Provides access to the uploaded file as a stream

• blob.read() - Reads the entire file content into memory (be careful with large files!)

Important Consideration: Blob triggers have a slight delay (can be up to several minutes for large containers). For real-time processing, consider Event Grid triggers instead.

2.9 Azure Functions + DevOps Integration

Azure Functions integrate perfectly with the DevOps tools you've learned. This section shows how Docker and Terraform work together with serverless computing to create a complete, automated deployment pipeline.

Why Integrate Functions with DevOps Tools?

• Docker: Ensures your function runs identically in development, testing, and production

• Terraform: Automates infrastructure creation, making deployments repeatable and version-controlled

• Together: You can deploy entire serverless architectures with a single command

With Docker

You can containerize Azure Functions for consistent deployments. This is especially useful when:

• Your function has complex dependencies that are hard to install on Azure

• You want to test locally with the exact same environment as production

• You need to run functions on Azure Container Apps or Kubernetes instead of the built-in Functions host

# Dockerfile for Azure Functions
FROM mcr.microsoft.com/azure-functions/python:4-python3.11

ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
    AzureFunctionsJobHost__Logging__Console__IsEnabled=true

COPY requirements.txt /
RUN pip install -r /requirements.txt

COPY . /home/site/wwwroot

Understanding the Dockerfile:

• FROM mcr.microsoft.com/azure-functions/python:4-python3.11 - Uses Microsoft's official Azure Functions base image with Python 3.11. This image includes the Functions runtime and all necessary tools.

• AzureWebJobsScriptRoot=/home/site/wwwroot - Tells the Functions runtime where to find your code

• AzureFunctionsJobHost__Logging__Console__IsEnabled=true - Enables console logging so you can see output when running locally

• COPY requirements.txt and RUN pip install - Installs your Python dependencies

• COPY . /home/site/wwwroot - Copies your function code into the container

Building and Running Locally:

# Build the Docker image
docker build -t my-function-app .

# Run the container locally
docker run -p 8080:80 my-function-app

# Test your function
curl http://localhost:8080/api/hello

With Terraform

Infrastructure as Code for Functions allows you to define your entire serverless infrastructure in code, version it with Git, and deploy it automatically.

What This Terraform Configuration Creates:

1. A Resource Group to contain all resources

2. A Storage Account (required by Functions for internal operations)

3. A Service Plan (defines the hosting model - Consumption, Premium, or Dedicated)

4. The Function App itself

# main.tf
"azurerm_resource_group"">resource "azurerm_resource_group" "function_rg" {
  name     = "function-app-rg"
  location = "West Europe"
}

"azurerm_storage_account"">resource "azurerm_storage_account" "function_storage" {
  name                     = "funcstorageacc123"
  resource_group_name      = azurerm_resource_group.function_rg.name
  location                 = azurerm_resource_group.function_rg.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

"azurerm_service_plan"">resource "azurerm_service_plan" "function_plan" {
  name                = "function-app-plan"
  resource_group_name = azurerm_resource_group.function_rg.name
  location            = azurerm_resource_group.function_rg.location
  os_type             = "Linux"
  sku_name            = "Y1"  # Consumption plan
}

"azurerm_linux_function_app"">resource "azurerm_linux_function_app" "function_app" {
  name                = "my-unique-function-app"
  resource_group_name = azurerm_resource_group.function_rg.name
  location            = azurerm_resource_group.function_rg.location

  storage_account_name       = azurerm_storage_account.function_storage.name
  storage_account_access_key = azurerm_storage_account.function_storage.primary_access_key
  service_plan_id            = azurerm_service_plan.function_plan.id

  site_config {
    application_stack {
      python_version = "3.11"
    }
  }
}

Understanding the Terraform Resources:

• azurerm_resource_group - Container for all related Azure resources

• azurerm_storage_account - Storage for function code, logs, and trigger state. LRS means locally redundant (cheapest option)

• azurerm_service_plan with sku_name = "Y1" - The Consumption (serverless) plan. "Y1" is Azure's code for Consumption tier

• azurerm_linux_function_app - The actual Function App. References the storage and service plan created above

Deploying with Terraform:

# Initialize Terraform (download Azure provider)
terraform init

# Preview what will be created
terraform plan

# Create the infrastructure
terraform apply

# When done, destroy everything
terraform destroy

The Power of IaC: With this Terraform file, you can recreate your entire serverless infrastructure in any Azure subscription with a single terraform apply command. This is invaluable for disaster recovery, testing environments, and multi-region deployments.

2.10 Security Best Practices for Azure Functions

Security is critical for serverless applications because your functions are exposed to the internet and process potentially untrusted input. Unlike traditional servers where you control the network perimeter, serverless functions require a different security mindset.

Quick Reference Table:

Practice	Implementation
Use Authentication	Configure Azure AD, API keys, or managed identities
Secure Connection Strings	Use Azure Key Vault, not app settings for secrets
Network Restrictions	Use VNet integration, private endpoints
HTTPS Only	Enforce HTTPS for all HTTP triggers
Input Validation	Always validate and sanitize input data
Least Privilege	Use managed identities with minimal permissions

Understanding Authentication Levels

Azure Functions provide three built-in authentication levels for HTTP triggers:

# Example: Configure authentication level
# In function.json or using decorators:
# auth_level=func.AuthLevel.FUNCTION  (requires function key)
# auth_level=func.AuthLevel.ADMIN     (requires master key)
# auth_level=func.AuthLevel.ANONYMOUS (no key required)

What Each Level Means:

• ANONYMOUS - Anyone can call your function without any key. Use only for truly public endpoints.

• FUNCTION - Requires a function-specific key in the request. Each function can have its own key.

• ADMIN - Requires the master key (also called host key). This key has access to ALL functions in the app.

How to Call a Protected Function:

# Function key can be passed as query parameter
curl "https://myfunc.azurewebsites.net/api/hello?code=YOUR_FUNCTION_KEY"

# Or as a header (more secure - key not visible in logs)
curl -H "x-functions-key: YOUR_FUNCTION_KEY" \
     "https://myfunc.azurewebsites.net/api/hello"

Enforcing HTTPS

Never allow HTTP (unencrypted) connections to your functions. All data, including API keys, would be visible to attackers on the network.

# Example: Enable HTTPS only
az functionapp update \
  --name myuniquefunctionapp123 \
  --resource-group myFunctionAppRG \
  --set httpsOnly=true

Using Managed Identities (Recommended)

Instead of storing credentials in your code or configuration, use Managed Identities. Azure automatically provides your function with an identity that can authenticate to other Azure services.

The Problem with Traditional Credentials:

# BAD: Hardcoded credentials in code
connection_string = "DefaultEndpointsProtocol=https;AccountName=...;AccountKey=SECRET..."

The Solution with Managed Identity:

# GOOD: No credentials in code - Azure handles authentication
from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

credential = DefaultAzureCredential()
blob_service = BlobServiceClient(
    account_url="https://mystorageaccount.blob.core.windows.net",
    credential=credential
)

How Managed Identity Works:

1. You enable Managed Identity for your Function App in Azure

2. You grant that identity permissions to access other resources (e.g., "read blobs from storage account X")

3. Your code uses DefaultAzureCredential() which automatically obtains tokens from Azure

4. No secrets to store, rotate, or accidentally commit to Git!

Input Validation

Always validate and sanitize input data. Never trust data coming from users or external systems.

@app.route(route="process", auth_level=func.AuthLevel.FUNCTION)
def process_data(req: func.HttpRequest) -> func.HttpResponse:
    try:
        # Parse JSON body
        data = req.get_json()
    except ValueError:
        return func.HttpResponse("Invalid JSON", status_code=400)

    # Validate required fields
    if 'email' not in data:
        return func.HttpResponse("Missing 'email' field", status_code=400)

    # Validate email format
    import re
    email_pattern = r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$'
    if not re.match(email_pattern, data['email']):
        return func.HttpResponse("Invalid email format", status_code=400)

    # Now safe to process
    # ...

Common Validation Checks:

• Check for required fields

• Validate data types (string, number, boolean)

• Validate formats (email, phone, date)

• Check string lengths (prevent oversized payloads)

• Sanitize data before using in database queries (prevent SQL injection)

Storing Secrets in Azure Key Vault

Never store sensitive data (API keys, passwords, connection strings) in plain text in your function configuration.

# Create a Key Vault
az keyvault create \
  --name myFunctionKeyVault \
  --resource-group myFunctionAppRG \
  --location westeurope

# Store a secret
az keyvault secret set \
  --vault-name myFunctionKeyVault \
  --name "DatabasePassword" \
  --value "super-secret-password"

# Grant your Function App access to the Key Vault
az keyvault set-policy \
  --name myFunctionKeyVault \
  --object-id <function-app-managed-identity-id> \
  --secret-permissions get list

Then reference the secret in your Function App configuration:

# Reference Key Vault secret in app settings
az functionapp config appsettings set \
  --name myuniquefunctionapp123 \
  --resource-group myFunctionAppRG \
  --settings "DatabasePassword=@Microsoft.KeyVault(VaultName=myFunctionKeyVault;SecretName=DatabasePassword)"

Your code can now read DatabasePassword from environment variables, and Azure automatically fetches the actual value from Key Vault.

Part 3: Quick Reference Cheatsheet

Azure CLI Essential Commands

# ============= ACCOUNT =============
az login                                     # Login
az account show                              # Current subscription
az account list -o table                     # All subscriptions
az account set -s "name"                     # Switch subscription

# ============= RESOURCE GROUPS =============
az group create -n NAME -l LOCATION          # Create
az group list -o table                       # List
az group delete -n NAME --yes                # Delete

# ============= VIRTUAL MACHINES =============
az vm create -g RG -n NAME --image IMAGE     # Create
az vm start/stop/restart -g RG -n NAME       # Control
az vm list -g RG -o table                    # List

# ============= NETWORKING =============
az network vnet create -g RG -n NAME         # Create VNet
az network nsg create -g RG -n NAME          # Create NSG
az network nsg rule create -g RG --nsg-name  # Add rule

# ============= STORAGE =============
az storage account create -g RG -n NAME      # Create
az storage container create --account-name   # Create container
az storage blob upload --account-name        # Upload file

# ============= FUNCTIONS =============
az functionapp create -g RG -n NAME          # Create
az functionapp list -o table                 # List
az functionapp delete -g RG -n NAME          # Delete

Azure Services Comparison

Service	Use Case	Scaling	Cost Model
Virtual Machines	Full control, legacy apps	Manual	Per hour (always on)
App Service	Web apps, APIs	Auto/Manual	Per plan tier
Azure Functions	Event-driven, serverless	Automatic	Per execution
Container Apps	Containerized microservices	Automatic	Per resource usage
AKS	Complex container orchestration	Manual/Auto	Per cluster + nodes