Azure-in-bullet-points

Implement workloads and security

Azure Migration

Migration Phases
- Discover
  - Inventory of on-prem resources to plan where the migration should start
  - Tools: Azure Migrate Service, Database Migration Assistant
  - Answer to questions such as _What are my applications? How are they made up JAVA or .NET? Data structure, SQL VM or SQL? How will they look like in Azure?
  - You can use Azure partner discovery services such as Cloudamize, CloudSpace…
- Migrate
  - Tools: Azure Site Discovery, Azure Database Migration Service, Azure Data Box
  - Deploy identity, network, storage, and compute infrastructure
    - You move selected workloads to Azure.
- Optimize
  - Fine tune your Azure-based workloads and maximize your ROI (Return on Investment).
  - Tools: Azure management and Security (e.g. backup, monitoring, security, assessment), Azure Cost Management, third party solutions such as Cloudyn
  - Security + performance improvements
  - 3rd parties help with with backup, monitoring, security assessments, and cost management.
Arguments for migrating
- No hardware obsolesce cycle: No need to sell hardware after a while
- No pre-purchase capacity model, but pay for what you use.
- Lack of IT agility
- Desire to focus on core competencies
- Expense of maintaining a global presence
- Enable disaster-recovery scenarios: Geographically dispersed locations.

Azure Migrate Service

Free tool for primarily IaaS-based assessments.
Good for lift-and-shift migrations.
Supports VMware-virtualized Windows and Linux VMs.
Non-intrusive discovery of on-premises VM’s & workloads
Examines & assets:
- Azure readiness (suitability of on-premises machines)
  - Asserts • ready for azure, • ready with conditions, • not ready for Azure, • Azure readiness unknown (when readiness cannot be identified due to data unavailability)
- Sizing suggestions for VM’s & disks based on history
  - Two settings:
    - As on-premises
    - Performance based
      - Based on utilization history
        
        Storage: default is Premium disks
        
        Network: performance required by network adapters
        
        Compute: CPU & memory requirements
- Cost estimation: The estimated cost for running the machines & storages in Azure
- High confidence migration
  - Migration risks and recommended tools: recommends e.g. Azure Site Recovery
  - Visualize dependencies of on-premises machines through dependency maps
  - Create groups that you will asses and migrate together
Flow
1. Create migration project
  - In Azure, create an Azure Migrate project.
2. Install Collector
  - You download .OVA & import in VMware vCenter as VM
  - Read-only VM to log
3. Configure Collector
  - You connect to console of VM or web to initiate the discovery
  - Copy & paste your project id and key from Azure.
  - It reads: config data, virtual processors, memory size, disk, network configuration, performance history (CPU utilization, memory, disk IOPS & throughput, network output to choose right size for VMs)
4. Select VM’s or groups (can customize groups) & create assessment.
  - Customize machines in report to recalculate costs.
5. You can optionally install Dependency Agent to see dependency maps
Assessment content
- Target location, Storage type, Reserved Instances, Sizing criterion, Performance history, Comfort factor, VM series, Currency, Discount (%), VM uptime, Azure offer, Azure Hybrid Benefit
  - Comfort factor: Buffer that’s applied on top of machine utilization data for VMs.
❗ Assesses only VMWare (>5.5) environments, for Hyper-V machines use Azure Site Recovery Deployment Planner.

Azure Site Recovery Service ^{DRaaS: Disaster Recovery as a Service}

Tool for VM replication and migration from anywhere to Azure
Lifting and shifting of servers, apps, databases, and data.
- Lift and shift: A strategy for moving an application or operation from one environment to another without redesigning the application.
Containerization of existing applications and infrastructure.
Modernization options for apps and databases.
Can automatically replicate to Azure or from Azure
- Supports Hyper-V, VMWare, Windows, Linux VM’s
Pre-, post scripting with Azure Automation
- Safeguard complex workloads against outage with
Use-cases
- Use Azure as a secondary site for conducting business during outages.
- Continuous health monitoring remotely from Azure.
Pricing:
- First 31 days free then to Azure (25$), to on-prem(15$) per month for single instance
- Storage always costs
- Azure Compute Charges for recovered VMs (if fail-over / migration is done)
- Outbound data transfer (egress charges, when failing back)
Azure Backup vs Azure Site Recovery
- You need to have both to have a full business continuity plan.
- Azure Backup: Copy of data to restore business back to a specific period of time
Flow:
- Prerequisites:
  - Minimum permissions: Virtual Machine Contributor, Site Recovery Contributor, write to selected storage account.
  - Create storage account to store replicated VM’s
  - Create VNet
  - Plan with Azure Site Recovery Deployment Planner
    - A command line tool that gives an excel file with on-premises summary, recommendations, VM storage placement, compatible + incompatible VMs, on-premises storage requirement, initial replication batching, cost estimation
      1. Set up Recovery Services vault
    - Create a resource -> Management Tools -> Backup and Site Recovery
    - It stores your back-ups and recovery points.
    - Backups are protected with Azure Backup (prevention, alerting)
    - 💡 Create or manage a Recovery Services vault in the context of the target service.
    - Central monitoring: Azure VM’s + on prem, RBAC
    - Azure Recovery Services vs Back-up Vault
      - You can no longer create Backup vaults, and all existing Backup vaults have been upgraded to Recovery Services vaults.
        
        Set up target environment in Azure
    - Select storage, recovery vault and network
    - LRS or GRS storage is recommended, so the data is resilient if a regional outage occurs, or if the primary region cannot be recovered.
      1. Select a replication goal (protection goal)
    - Recovery Services vaults > vault > Recovery > Prepare Infrastructure > Protection goal
    - Select what you want to migrate e.g.
      - VMware: Select To Azure > Yes, with VMWare vSphere Hypervisor.
      - Physical machine: Select To Azure > Not virtualized/Other.
      - Hyper-V: Select To Azure > Yes, with Hyper-V. If Hyper-V VMs are managed by VMM, select Yes.
        
        Set up the source environment
    - Download and import ASR configuration server and process server into vCenter Server
      1. Replicate the VM’s that you want to migrate to Azure
    - You can create replication policy
      - You set how often recovery points will be created.
      - Recovery Services vault -> Site Recovery infrastructure > Replication Policies > +Replication Policy.
    - Enable replication directly
      - In the vault, click +Replicate.
      - Select VM’s
    - Everything is copied in storage.
      - 💡 Paging files have a lot of churn and will generate a lot of replication events.
        
        You can optimize via:
        
        Split the single virtual disk into two virtual disks. One virtual disk has the operating system, and the other has the paging file.
        
        Exclude the paging file disk from replication.
        
        Pagingfile: a pagefile is a reserved portion of a hard disk that is used as an extension of random access memory (RAM) for data in RAM that hasn’t been used recently.
        
        Run test failover: it’s no impact migration testing.
        
        Switch production environment to Azure
    - Create a recovery plan
      - Recovery plan describes the way migration will work in the event of a disaster.
      - In recovery plan, you can:
        
        Change order of VM starts.
        
        Customize fail-over
        
        Run scripts via Azure Automation
        
        Azure Automation: Runs runbooks (piece of script of NodeJs, PowerShell, Python), has support for modules.
        
        Select order
        
        Create groups
        
        VM’s in same group are shut down and booted in the same time
        
        Across groups they’re booted & shut down sequentially, without groups at the same time
        
        Choose VM size and customize other settings by c licking on “replicate items” in recovery plan.
        
        Set the target IP address.
        
        💡 If you don’t provide an address, the failed-over machine uses DHCP.
        
        You can use Hybrid Use Benefit (up to 40% cut for existing Windows Server licenses)
    - Failover to azure on recovery plan
      - Settings > Replicated items -> Click the machine > Failover.
      - Failover & Failback
        
        The failover operation is the process of switching production to a backup facility (normally your recovery site)
        
        Failover isn’t automatic but a manual process.
        
        Unplanned failover:
        
        E.g. natural or IT disaster.
        
        Done from latest point with minimal data loss
        
        Planned failover
        
        You choose the point, zero data loss
        
        A failback operation is the process of returning production to its original location after a disaster or a scheduled maintenance period.
        
        Failback is a planned failover from Azure to on-premises
        
        Flow: Go to vault -> Click on “planned failover” -> choose data synchronization -> Choose between a full download (quicker) or synchronization of delta changes (lesser downtime)
        
        Two ways to synchronize data:
        
        Full download: A full download is faster but requires the VM to be shutdown which couses more downtime.
        
        Minimize downtime: More time to synchronize the changes, but the VM is not shut down so less downtime.
    - After failover, Commit migration for production
      - Choose VM’s for fully migration, click on “Complete migration” on recovery plan.
Disaster recovery to Azure for on-premises physical servers
1. Set up an Azure storage account
2. Create a vault
3. Select a protection goal: To Azure > Not virtualized/Other
  - 💡In Azure Backup it’s called Backup Goal
4. Set up the source environment
  - Recovery > Prepare Infrastructure > Source > +Configuration server > Add Server
  - Download the vault registration key
  - Download & install the Site Recovery Unified Setup installation file.
5. Set up the target environment: Prepare infrastructure > Target
6. Create a replication policy to choose when (how often) to replicate
  - Site Recovery infrastructure > Replication Policies > +Replication Policy.
7. Enable replication
❗ Limitations:
- 64 bit only.
- Max disk size: 4TB
- Max OS size: 2TB but for generation 2 hyper-v it’s 200GB

Web Apps ^PaaS

PaaS for web applications.
App Service Plan is the infrastructure app services run on.
- Defines compute resources.
- Can be dedicated VM or shared.
- ❗ You cannot move it to a different region, but you can clone apps.
Multiple languages and frameworks are supported
- Good support: ASP. NET, Node.js, Java, PHP and Python
- Can run any scripts/executables on VM’s.
DevOps
- CI/CD from Azure DevOps, GitHub, Docker Hub and other git sources.
  - Enable on app’s menu blade -> App Development -> Deployment Options
- Deployment Slots
  - Deployment slot = Another web-app that’s linked to a web-app
    - dev <=> staging <=> production
  - Standard => 5, Premium => 20 slots
  - All slots have their own names & urls.
  - Advantages:
    - Validate app changes in staging before swap (preview before swap)
    - No cold start
      - Ensures all instances are warned up with no downtime, no request drop
    - If it fails, you can swap back
  - Swapping settings
    - Many settings are swapped, some are not.
    - You can choose some Application Settings to be sticky (won’t swapped)
Network
- Access on-premises data using Hybrid Connections_r_VNet’s.
  - You can use to access e.g. to on-prem database.
- App Service Environment
  - Clusters servers
    - All the way from front-end load balancers, workers, databases, everything that composes your infrastructure
    - Runs entire configuration in a VNet.
  - Configure inbound network traffic rules
  - Setup a Web Application Firewall in front of your ASE
Some application settings:
- 64-bit: costs more memory, use it carefully
- Always on => If VM goes down etc, Azure will try to turn VM on every 10-15 ms.
  - If you get little requests, VM is brought up when it’s needed
- ARR affinity => You don’t care for states, turn it off, it’ll scale better.
Backup
- Only Standard or Premium tier.
- You need a storage in same subscription as the app.
- You can back-up databases as well if connection string exists in app settings.
  - works for: SQL Database, Azure Database for MySQL, Azure Database for PostgreSQL, MySQL in-app
- You can automate backup with back-up schedule: How often? When? Retention?
- You can exclude some files.
Snapshots
- For premium or higher, snapshots are taken automatically.
- Advantages over back-ups:
  - No file copy errors due to file locks.
  - No storage size limitation.
  - No configuration required.
- 3 months of snapshots are kept, can only restore for the last 30 days.
You can clone app across regions on premium.
You can create from application templates (e.g. WordPress, Joomla, Drupal).
Other features: scale up/out automatically / manually.
Key Features
- Deployment Slots
- Security: SSL certificates
- Load balancing, auto scaling
Azure Mobile App
- Native & cross-platform apps with e.g. Xamarin, Cordova, Unity.
- Can connect to on-premises.
- Build offline-ready apps with data sync: Syncs when internet is there
- Some special options:
  - Azure Easy Table: Light SQL on portal.
  - Azure Easy APIs: Code & build directly in Azure portal for Node.js back-end.

App Service Security

Infrastructure and platform security
- Managed by Azure = You trust Azure
- Your app service apps are isolated from both the Internet and from the other customers’ Azure resources.
- Communication of secrets (e.g. connection strings) in a resource group does not cross any network boundaries and are always encrypted.
- All communication between App Service and external resources (e.g. REST) are encrypted.
- Microsoft Threat Management
- Azure Security Center => natively part of Azure + PaaS services
  - Monitors without any deployment
    - Can protect on-prem by installing “Microsoft Monitoring Agent”
  - Set monitor policies.
  - See Network Map of all VNet’s
  - Helps you configure recommended controls (add firewall, use AAD etc).
  - Windows Defender Advanced Threat Protection
    - On all VM’s out of the box.
    - Protects from malware, DDoS, man-in-the-middle and more.
    - Man-in-the-middle
      - Reroutes communication between two users through the attackers computers without their knowledge. He can monitor and read the traffic before sending it on the intended recipient.
- Other protections:
  - SQL injection
  - Session hijacking
    - Active: Takes over clients position
    - Passive: Monitors the traffic for password etc.
  - Cross-site-scripting: via click or script tags malicious script is executed.
Application security: You design with security features
- AAD integration, certification management, secure communication with different services etc.
- Access Restriction
  - Authentication & Authorization
    - No code authentication
      - App Service can validate user assertations.
      - Uses JWT tokens
        
        ADD => authorization header as bearer token
        
        Mobile App Client SDK’s
      - Federated identity
        
        Identity providers
        
        Default: AAD, Microsoft Account, Facebook, Google, Twitter.
        
        Can be extended with custom providers.
    - Client certificate authentication
      - Inbound (TLS mutual authentication)
        
        Someone who wants to come to your site needs to present a certificate
        
        Use API or Resource explorer to set.
      - Outbound (using a client certificate from your app)
        
        Application talks to another server and that servers requires app to have certification.
        
        Set in App settings with WEBSITE\_LOAD\_CERTIFICATION key.
      - Resource explorer = Visualizes API’s and manage rules, you can force require inbound certification there you can also set “expect” one.
  - Static/Dynamic IP restriction
    - Configured in web.config file.
    - Static IP restriction: e.g. geo-fencing
    - Dynamic IP restriction: e.g. DDoS protection
      - You set request frequency & concurrency rules.
  - Security scanning
    - Via 3rd party “Tinfoil Security”
    - Paid & billed outside of Azure
    - Managed in Kudo => Extensions
    - Use e.g. before you switch slot from production you can see if you introduce any vulnerability.

Serverless Computing

Abstraction of servers, infrastructure, and operating systems.
Main flow => An event triggers code, code gets data, and gives utput
Activity based billing => Only pay when you use resources
- Billing is based just on resources consumed or the actual time your code is running.
Applications in Azure:
- (Compute) Azure Functions, (Storage) Azure Storage, (Database) Azure Cosmos Db, (Security and access control) Azure Active Directory, (Cloud messaging) Event Grid, Service Bus, (Workflow orchestration) Logic Apps, (API Management) Azure API Management, Azure Function Proxies: single API surface that calls different functions, (Analytics) Azure Stream Analytics, Event Hubs, (Intelligence) Azure Bot Service, Cognitive Services

Azure Functions ^{FaaS: Functions as a Service}

Built on top of WebJobs SDK.
No idle capacity charges.
Execute event-driven code with any programming language.
Can run locally or in the cloud.
- Azure Functions Runtime is free & open-source.
- Local development requires bindings.
  - Bindings are a way to provide input and output to the function.
  - A function can have multiple input and output bindings.
  - They’re defined in a Json file can have different parameters (queueName, tableName) etc. depending on bound target.
Automatically scaling.
- Scale controller monitors the rate of events and uses heuristics to scales out/in.
- A single function app will only scale to a maximum of 200 instances. A single instance may process more than message/request at a time though.
Pricing
- Consumption Plan
  - Scale out automatically.
  - Billing is based on number of executions, execution time, and memory used.
- App Service Plan
  - Linux only, you pay for the IaaS.
  - Provides cost predictability and warm start.
By default, a function will timeout after 5 minutes, and a function can run for a maximum of 10 minutes.
Triggers
- Can be triggered by Event Hubs, storages, devices from IoT hub, custom sources etc.
- Or with a scheduled by e.g. webhook, API, data processing.
  - Timer is scheduled with CRON expression
Bring your own dependencies
- Supports NuGet, NPM etc., allowing use of preferred libraries.
Integrated security
- HTTP-triggered functions can be protected with OAuth providers (AAD, google etc.)
Code directly in portal or use deployments from GitHub, Visual Studio, etc.
Best practices
- Avoid long running functions
- Use cross function communication
- Stateless functions
- Defensive functions: An exception can happen whenever possible
- For scalability:
  - Share & manage connections
  - Don’t mix test and production code in the same function app
  - Use async code but avoid blocking calls
  - Receive messages in batch whenever possible
  - Configure host behavior to better handle concurrency (max outstanding requests, max concurrent requests etc).

Event Grid ^{iPaaS: Integration Platform as a Service}

Fully managed, http-based event routing service for events.
It connects and integrates all Azure services.
- You can create events in Events blade of resources (e.g. blob storage)
Eliminate polling because it’s expensive.
- Long polling: Server waits until the data is available instead of empty directly.
  - it is very expensive in terms of CPU, memory and bandwidth
Concepts
- Event Publishers (sources) =>(through topics) Event Grid =>(through subscriptions) Event Handlers
- Topic: Endpoint where the source sends events.
- Event Subscription: what you’re interested in receiving
  - Can be filtered
  - Can have expriration date.
Batching is supported (array of events) and recommended.
Use case example:
- Ops automation: New VM created or SQL DB spun up => check whether configurations are compliant, tag, file work items etc.
You can use custom events
- Get easy to use UI
- Native integrated event handlers
- Uniform consumption of events
Uses pub/sub model.
- Can send events to multiple recipients
Pricing:
- Pay by number of operations
- Published events, + delivery attempts, - monthly free grant (100k) = total operations x $0.60

Service Bus^PaaS

Managed messaging infrastructure across private & public cloud.
Publish/Subscribe
- Temporal decoupling
  - Producers (senders) and consumers (receivers) do not have to be sending and receiving messages at the same time, because messages are stored durably in the queue.
- Load leveling => producers consumers send & receive messages at different rates.
  - You don’t have to pay for a system that is underutilized part of the time.
- Loose coupling:
  - Resilience because messages are durable until they reach the worker.
- Load balancing: bring on more workers as the queue increases.
- Topics and subscriptions: one to many (recievers)
  - Messages can be filtered in topics
- Other features: Others: auto-forwarding, batching, scheduled delivery (delayed processing), and message deferral
Implementation
- Create namespaces where pub/subs will meet
  - Provides a service + security boundary.
  - Can be integrated with Azure Relay
    - Integrates on-premises communication easily.
    - Less intrusive than VPN.
    - Traditional one-way, request/response, and peer-to-peer communication
    - Event distribution at internet-scope to enable publish/subscribe scenarios
    - Bi-directional and unbuffered socket communication across network boundaries.
  - The name provides a unique identifier for the object. For example, sbces12345.servicebus.windows.net
- Create a queue
  - You can select: Message time to live, lock duration, duplicate detection (duplicates won’t be accepted), dead lettering (hold messages can’t be delivered in another queue), sessions (guarantees FIFO), partitioning.
Receive events
- RecievesAndDelete
  - Simplest, ok if system can tolerate if a message is missing if it can’t be handled
- PeekLock
  - CompleteAsync => Message is handled & deleted
  - AbondonAsync => Re-queued
Pricing
- Premium: Fixed size, predictable performance, up-down scaling,messages up to 1MB
- Standard: Elastic, auto-scaling, message size up to 256 KB.
Monitoring
- Metrics
  - Request metrics counts the number of requests.
  - Message metrics counts the messages (active, incoming, outgoing etc)
  - Connection metrics active/opened/closed messages
  - Resource usage metrics in Premium: CPU/memory size usage per namespace.
- Diagnostics Logs: ActivityId, EvetName, resourceId, SubscriptionId, EventTimeString, EventProperties, Status, Caller, category (= operationalLogs)
Service Buses vs Storage Queues
- Service buses are built on top of storage queues and are more advanced:
  - Clients can use AMQP (ISO standard for queueing)
  - FIFO is guaranteed with sessions.
  - And other features such as batch send, automatic dead lettering, message auto-forwarding, message groups, duplicate detection, sessions, transactions, duplicate detection, durable publish/subscribe.
- In storage queues is REST only, FIFO is not guaranteed, lease/lock is on message level (while it’s on queue level in service buses).

Logic Apps

Cloud & serverless only & scalable service to orchestrate workflows.
- Can be integrated with on-prem connectors.
Connects serverless functions and API’s.
- Integrates data with apps.
- Can be customized.
You can manage & manipulate data.
Many built-in triggers
- You can have polling triggers, push triggers or recurrence (time-based) triggers.
- Other built-in triggers include: HTTP, Request, Azure Functions, Batch, and other Azure Logic apps
- Can be extended.
- Can be triggered time-based (recurrence scheduling)
More than 200 built-in connectors
- Managed connectors: Azure Service Bus, SQL Server, Office 365 Outlook, Azure Blob Storage, SFTP, SharePoint Online, Dynamics 365 CRM Online, FTP, Salesforce, Twitter, Azure Event Hubs, Azure Event Grid, ..
- On-prem connectors: BizTalk Server, File System, IBM DB2, IBM Informix, MySQL, Oracle DB, PostgreSQL, SharePoint Server, SQL Server, Teradata.
- For additional cost: Enterprise Connectors (SAP, IBM MQ..), Integrations account connectors (B2B messages via special protocols, XML handling).
- Each connector has specific actions
  - twitter has => Post a tweet, get followers, get following actions.
Built logic with
- Error handlers
- Conditionals: for each, condition (if), scope, switch, terminate, until.
- Manage variables with expressions (such as div, concat etc)
  - Data operations (compose, create html/csv, filter array, join, parse json, select)
  - Date Time (add to time, convert time zone, current time, get future time, get pas t time, subscract from time)
  - Variables (append to array, append to string, decrement, increment, initialize, set)

Networking

To understand difference between Azure Load Balancer and Application Gateway (also a load balancer) it’s good to understand OSI layers:
- 1: The physical layer, 2: The data-link layer, 3: The network layer, 4: The transport layer (Load Balancer), 5: The session layer, 6: The presentation layer, 7: The application layer (Application Gateway)
Azure Traffic Manager
- Used for geo-routing.
- It provides DNS-based routing to redirect end user traffic to globally distributed end points.

Azure Load Balancer

OSI Layer 4 (TCP & UDP) load balancer that distributes inbound traffic to backend pools (resources) according to rules and health probes.
- For application-layer processing, see Application Gateway (e.g. SSL off-load)
- For DNS load balancer (geo-based) see Traffic Manager
In actual Azure infrastructure there’s always a load balancer.
- No instance is really created, capacity is always available.
Front-end <=> Load balancer => (through load balancing rules and health probs) Back-end pools (includes VM’s)
Features:
- Instant scaling to applications
- Reliability via health checks through health probes.
- Secure: You can add NAT
  - Network Address Translation: remapping one IP to another in VM.
  - Lowers attack surface of the VM’s that otherwise could be attacked directly.
- Port forwarding => A frontend IP to a port of a back-end inside VNet.
- Agnostic & transparent => Endpoint is only answered by VM (VM TCP handshakes)
Two types of load balancers:
- Public load balancer
  - Internet facing
    - Maps public IP+port of incoming traffic <=> private IP+port.
  - E.g. TCP port 80 <=> VM’s in web tier subnet in a multi-tiered architecture.
  - Can be placed in front of public load balancer to create multi-tier application.
- Internal load balancer
  - Routes traffic between VM’s inside private VNet’s or VNet’s that use VPN access to Azure.
  - Good for:
    - Handling communication within same VNet.
    - Hybrid scenarios: On-prem to VM’s in same VNet
    - Multi-tiered applications
      - E.g.: an internal load balancer can receive DB requests that needs to be distributed to back-end SQL servers.
    - Critical (line-of-business) applications.
  - Frontend IP’s and VNet’s are never directly exposed to internet.
    - Accessed from within Azure or on-prem resources
  - Can be used to create multi-tiered hybrid applications.

Load balancing rules

Load balancing rules determine how traffic is distributed to the backend.
E.g. you can spread load of incoming web request traffic across multiple webservers.
Settings: Port, protocol, IP version, back-end port, backend pool, health probe, session persistence, floating IP (enable/disable).
Back-end server pool
- IP addresses of back-end servers.
- Back-ends span to two VNet’s, must be in same VNet.
Front-end port is called Listener and can have SSL certificate.
Frontend & backend pool are connected with rules.
- Front-end is associated with the back-end VM through rule definition.
- Rules reference to a health probe of target VM.

You can set Multiple Frontends

Load balance on multiple ports, multiple IP addresses or both.

Default rule with no-back-end port reuse

Each rule must have a flow with unique IP+port
Multiple rules can distribute flows to same DIP on different ports.
- DIP = destination IP of VM

Example:

Rule	Map frontend	To backend pool
1	💚Frontend1:80	💚DIP1:80, 💚DIP2:80
2	💜Frontend2:80	💜DIP1:81, 💜DIP2:81

Backend port reuse by using Floating IP

If you want to reuse back-end port across multiple rules.
Good for: e.g. clustering for high availability, network virtual appliances, and exposing multiple TLS endpoints without re-encryption.

Example:

Rule	Map frontend	To backend pool
1	💚Frontend1:80	💚 DIP1:80, 💚DIP2:80
2	💜Frontend2:80	💜 DIP1:80, 💜DIP2:80

Floating IP rule allows backend ports to be re-used.
- It must be enabled.
- It’s a part of DSR (Direct Server Return)
  - Flow topology
    - Outbound part of a flow is always correctly rewritten to flow directly back to the origin.
    - At platform level LB operates this way.
  - IP address mapping scheme
    - By changing destination IP, you can enable port re-use on same VM.

Session persistence
- Provides stickiness to same VM.
- A session is a 5-tuple hash of: Source IP, source port, destination IP, destination port (public port), protocol (optional).
- Settings
  - When adding a rule you can select only client IP or client IP + protocol.
  - Idle timeout: Default: 4 min, same server response via HTTP(S)/TCP sessions but no guarantee that connection is maintained.
Health probe
- Allows resilience and scalability.
- The health probe dynamically adds or removes VMs from the load balancer rotation based on their response to health checks.
- Types:
  - HTTP: HTTP 200 => healthy (timeout : 31 seconds)
  - TCP: If connection is accepted / refused
  - Guest probe: Runs inside VM, not recommended
- Standard SKU sends health probe status as metrics through Azure Monitor.
A high availability ports (HA ports)
- Is a variant of a load balancing rule for internal load balancers.
- Single rule to load-balance all TCP and UDP flows that arrive on all ports of an internal load balancer.
- Non floating: Cannot add more rules.
- Floating: can have same back-end instance or multiple back-ends.

NAT rules
- NAT rule ->
  - Must be explicitly attached to a VM (or network interface) to complete the path to the target
- Load balancing rule
  - VM is selected from the back-end address pool or VMs
- 💡 You would use NAT rule when you have 1 backend server or you know which backend server to get to and loadbalancing rule when you want to loadbalance to multiple backend servers.
Pricing
- SKU’s: Standard & Basic
  - New applications should use Standard.
    - More flexible & larger backend pools
    - Outbound rules (public IP, NAT, HTTPS), SLA is available only in Standard.
    - When back-end pool probes down
      - Standard allows TCP connections to continue
      - Basic terminates all connections.
  - Basic is free & subset of Standard.
    - HA ports are not available.
  - Not mutable, requires re-deploy.
There are quick start ARM templates. e.g.: 2 VM’s internal load balancer.

Azure Application Gateway ^{Application Delivery Controller (ADC) as a service}

Web traffic load balancer at Layer 7 – Application as opposed to Load Balancer that operates at Layer 4 – TCP and UDP
Application gateway can be configured as
- Internet-facing gateway
- Internal-only gateway
- Combination of both.

Components

Frontend IP Configuration <=> Application Gateway (has WAF and is L7 LB) <=> Listener (through rules) => Backend Server Pool
Frontend IP configuration : Traffic-facing port
Backend server pool. The list of IP addresses of the backend servers.
- The IP addresses listed should either belong to the virtual network subnet or should be a public IP/VIP.
- Every pool has settings like port, protocol, and cookie-based affinity.
Listener : Front-end configuration of the gateway.
- has a front-end port, a protocol (HTTP or HTTPS), and the SSL certificate name (optional).
- Can terminate SSL (SSL ofloading), so that traffic flows unencrypted to the backend servers.
  - Unburdens from encryption & decryption overhead.
  - To implement this, upload certificate & set it on listener.
Rule
- Binds the listener and the backend server pool
- Defines which backend server pool the traffic should be directed to when it hits a listener.
- Health probes can be HTTP, HTTPS, default => default webpage, you can configure custom URL.
- Path based rules allows routing based on paths
  - /video/* => video backend, /picture/* => picture backend
- Rules are processed in the order they are listed
Web application firewall (WAF).
- Centralizes security management of web applications = Simpler management.
- Uses rules from OWASP Core Rule Set:
  - Protection against: SQL Injection (SQLi), Cross Site Scripting (XSS), Local File Inclusion (LFI), Remote File Inclusion (RFI), PHP Code Injection, Java Code Injection, Shellshock, Unix/Windows Shell Injection, Session Fixation, Scripting/Scanner/Bot Detection, Metadata/Error Leakages
- You can deselect rules or disable the firewall.

Sizing

3 SKU’s

Average back-end page response size	Small	Medium	Large
6KB	7.5 Mbps	13 Mbps	50 Mbps
100KB	35 Mbps	100 Mbps	200 Mbps

Instance count: Ensures availability: 💡 Min 2 recommended for production

You can configure more than one web site on same instance
- ❗ Up to 20 web sites.
- Each website is directed to its own backend pool of servers.
- Implementation: 2 backend server pools, 2 listeners (type of multi-site), 2 routing rules.
Other features:
- Redirection: One port to other port => enables HTTP => HTTPS and more (ex. external site
- Session affinity: Keep a user session on the same server
- Other features: WebSockets & HTTP/2 traffic, rewrite HTTP headers

Site-to-Site VPN Connections

A Site-to-Site (S2S) connection is a connection over IPsec/IKE (IKEv1 or IKEv2) VPN tunnel.
- Azure-provided name resolution
  - No configuration, azure based address
  - Name resolution that uses your own DNS server
In order to do it with on-prem, following steps are followed:
1. Create a new custom VNet and gateway subnet
  - Deploy VNet (addresses should be free on-prem)
2. Create a VPN Gateway
  - Deploy Gateway Subnet in VNet
  - Deploy VPN Gateway
    - Settings:
      - VPN type
        
        Policy based = static routing
        
        Route based = dynamic routing
        
        Most VPN’s are route based.
      - SKU: Affects number of tunnels and the aggregate throughput benchmark.
      - Virtual Networks: Associate VNet with gateway.
        
        Each VNet requires its own VPN gateway.
  - You can see IP address in portal after deployment.
3. Add a local site (Local network gateway)
  - +Create a resource => Local network gateway
  - Register IP address and address space of on-prem network.
    - So the routing table can be built by Azure.
4. Configure a VPN device
  - Microsoft lists VPN devices that works well with Azure (e.g. Cisco, Juniper, Ubiquiti, and Barracuda Networks).
  - Download & run configuration script for the VPN device.
5. Create VPN connection
  - VNet Resource -> Overview -> Connected devices -> VPN Gateway > Connections > +Add
    - Connection type: Select Site-to-site(IPSec)
    - Shared Key: use key from your device or generate key & use in both places
6. Verify VPN connection
  - In Connection object you should see “Succeeded”

ExpressRoute

With ExpressRoute, you can establish connections to Microsoft cloud services, such as Microsoft Azure, Office 365, and CRM Online.
ExpressRoute connections do not go over the public Internet.
- More reliable, faster speeds, lower latencies, higher security.
Excellent for scenarios like periodic data migration, replication for business continuity, disaster recovery, and other high-availability strategies
Pricing
- You pay for Circuit bandwidth (50mpbs to 10gpbs etc)
- If you choose metered not unlimited => Writing to Azure is free, fetching from Azure costs per GB
Connection options:
- Connectivity providers can offer one or more connectivity models.
- Features and capabilities are identical.
- CloudExchange Co-location (Layer 2: Data-link, or Layer 3: Network)
  - If you’re in a facility with a cloud exchange, you can use their ethernet exchange.
- Point-to-point ethernet connection (Layer 2: Data-link, or Layer 3: Network)
- Any-to-any (IPVPN) Connection (typically Layer 3: Network)
  - You can integrate your WAN with Microsoft cloud.
    - WAN: Wide area network, geographically distributed private telecommunications network that interconnects multiple LANs.
  - Microsoft cloud can be connected to WAN like any other office branch.
Implementation
- Resources => Create ExpressRoute circuit =>
  - Select connectivity provider (Telia etc)
  - Bandwith => You can always increase, recommended to start low
  - Billing model => Unlimited (flat fee), metered (pay only for data transfer outside Microsoft network, egress)
  - Deployment is done => Microsoft is open to connections
  - Then you enable connection on your side & configure via service key provided in Azure
Monitoring
- Within Log Analytics you have NPM: Network Performance Monitor.
- Enables you to monitor
  - throughput, latency, packet loss across various VNets
  - All paths in network in a network map, see latencies across the hubs
- Requires installation of Log Analytics Agent
  - Both on Azure VM’s and on-prem in at least one server of each VNet.
- Can be integrated with SCOM (System Center Operations Management)
  - It works with Microsoft Windows Server and Unix-based hosts.
  - The agent watches several sources on that computer, including the Windows Event Log
Site-to-site and ExpressRoute can co-exist
- Why?
  - You can configure a Site-to-Site VPN as a secure failover path for ExpressRoute
  - Site-to-Site VPNs to connect to sites that are not part of your network, but that are connected through ExpressRoute
    - Requires two gateways, one type of VPN, other one type of ExpressRoute.
- ❗ Limitations
  - Transit routing is not supported.
    - You cannot route (via Azure) between your local network connected via Site-to-Site VPN and your local network connected via ExpressRoute.
    - Transing routing is supported when VNets are peered instead.
❗ You can have up to 10 virtual networks connections on a standard ExpressRoute circuit, and up to 100 on a premium ExpressRoute circuit.

Manage role-based access control (RBAC)

Create a custom role

Example:

{
  "Name": "Virtual Machine Operator",
  "Id": "88888888-8888-8888-8888-888888888888",
  "IsCustom": true,
  "Description": "Can monitor and restart virtual machines.",
  "Actions": [
    "Microsoft.Storage/*/read",
    "Microsoft.Network/*/read",
    "Microsoft.Compute/*/read",
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Authorization/*/read",
    "Microsoft.Resources/subscriptions/resourceGroups/read",
    "Microsoft.Insights/alertRules/*",
    "Microsoft.Insights/diagnosticSettings/*",
    "Microsoft.Support/*"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscriptionId1}",
    "/subscriptions/{subscriptionId2}",
    "/subscriptions/{subscriptionId3}"
  ]
}

Steps (through either PowerShell or Azure CLI)
1. Determine the permissions you need
  - Add in Actions and NotActions for data operations use DataActions and NotDataActions.
  - You can see all operations through az provider operation list.
2. Create the custom role
  - az role definition create
  - You need to have Microsoft.Authorization/roleDefinitions/write permissions on all AssignableScopes such as Owner or User Access Administrator
Limitations
- Azure supports up to 2000 role assignments per subscription.
- When you transfer a subscription to a different tenant, all role assignments are permanently deleted. You must re-create your role assignments in the target tenant.

Configure access to Azure resources by assigning roles
- Through a resource
  - Modify in Access control (IAM) in any Azure object.
  - In Check Access tab you can check access level of individual user, group, service principal or managed identity.
  - Add a role assignment
    1. Access control (IAM) -> Add role assignment
    2. Select Role e.g. Virtual Machine Contributor.
    3. In the Select list, select a user, group, service principal, or managed identity.
- For built-in global roles such as Contributor:
  - AD -> Users -> Select user -> Directory role -> +Add role
- Assign roles to licenses: Azure Active Directory > Licenses
- Assign roles to devices: Azure Active Directory -> Devices
Configure management access to Azure
- Securing privileged access requires changes to
  - Processes, administrative practices, and knowledge management
  - Technical components such as host defenses, account protections, and identity management
- Recommended roadmap:
  1. Stage 1: Critical items that we recommend you do right away (24-48 hours)
    - General preparation
      - Turn on Azure AD Privileged Identity Management
        
        Organizations can give JIT user access to specific Azure AD & resources.
        
        Help you protect access to applications and resources across the on-premises environment and into the cloud.
        
        This includes creating separate admin accounts for users who need to conduct on-premises administrative tasks, deploying Privileged Access Workstations for Active Directory administrators, and creating unique local admin passwords for workstations and servers.
        
        Define at least two emergency access accounts
        
        E.g. if on-prem AD DS goes down.
        
        Highly privileged and are not assigned to specific individuals.
        
        Turn on multi-factor authentication and register all other highly-privileged single-user non-federated admin accounts
        
        Features:
        
        Provide just-in-time privileged access to Azure AD and Azure resources
        
        Assign time-bound access to resources using start and end dates
        
        Require approval to activate privileged roles
        
        Enforce multi-factor authentication to activate any role
        
        Use justification to understand why users activate
        
        Get notifications when privileged roles are activated
        
        Conduct access reviews to ensure users still need roles
        
        Download audit history for internal or external audit
  2. Stage 2: Mitigate the most frequently used attack techniques (2-4 weeks)
    - Conduct an inventory of services, owners, and admins
      - Identify the users who have administrative roles and the services where they can manage.
      - Use Azure AD PIM to find out which users in your organization have admin access to Azure AD, including additional roles beyond those listed in Stage 1.
      - Ensure that your admin accounts have working email addresses attached to them and have registered for Azure MFA or use MFA on-premises.
    - Identify Microsoft accounts in administrative roles that need to be switched to work or school accounts
    - Ensure separate user accounts and mail forwarding for global administrator accounts
    - Ensure the passwords of administrative accounts have recently changed
    - Turn on password hash synchronization
    - Require multi-factor authentication (MFA) for users in all privileged roles as well as exposed users
    - Configure Identity Protection (ML to asses risks)
      - Detecting vulnerabilities and risky accounts
        
        Providing custom recommendations to improve overall security posture by highlighting vulnerabilities
        
        Calculating sign-in risk levels
        
        Calculating user risk levels
      - Investigating risk events
        
        Sending notifications for risk events
        
        Investigating risk events using relevant and contextual information
        
        Providing basic workflows to track investigations
        
        Providing easy access to remediation actions such as password reset
      - Risk-based conditional access policies
        
        Policy to mitigate risky sign-ins by blocking sign-ins or requiring multi-factor authentication challenges
        
        Policy to block or secure risky user accounts
        
        Policy to require users to register for multi-factor authentication
    - Monitor Azure Activity Log
  3. Stage 3: Build visibility and take full control of admin activity (1-3 months)
    - Complete an access review of users in administrator roles
    - Establish integrated monitoring
      - The Azure Security Center provides integrated security monitoring and policy management across your Azure subscriptions, helps detect threats that may otherwise go unnoticed, and works with a broad ecosystem of security solutions.
    - Inventory your privileged accounts within hosted Virtual Machines
      - Grant only the amount of access to users who need to perform specific jobs
    - Integrate information protection
      - Microsoft Cloud App Security (MCAS) scans & classifies based on policies using Azure Information Protection classification labels.
        
        E.g. confidentiality levels
Conditional access policies
- When this happens -> then do this
- You also set Users the users performing an access attempt (Who).
- Cloud apps: The targets of an access attempt (What).
- Controls (when this happens)
  - Grant controls
    - Support AND and OR operators.
    - Compliant device: Azure AD registered devices, Azure AD joined devices, Hybrid Azure AD joined devices
      - Hybrid Azure AD joined devices: Windows desktops, laptops, and enterprise tablets that are joined to an on-premises Active Directory
    - Approved client app through Intune app protection policies
    - Enforce acceptance of Terms of Use
    - Custom controls: Validation through custom API’s.
  - Session controls
    - Use app enforced restrictions: The device information enables the cloud apps to know whether a connection is initiated from a compliant or domain-joined device.

Multi-Factor Authentication (MFA)

Enable MFA for an Azure tenant
- First you need to install MFA server on Azure (managed).
- Enable options:
  - Enabled by conditional access policy
    - E.g. wen any user is outside my company network, They’re required to sign in with multi-factor authentication
    - Cloud only, premium feature of Azure AD
    - Flow:
      1. Choose verification options: Azure Active Directory -> Users -> Multi-Factor Authentication -> Service Settings -> Enable verification methods you want: call to phone, text message to phone, notification through mobile app, verification code from mobile app or hardware token
      2. Create conditional access policy: Azure Active Directory -> Conditional access -> New policy
        
        Select users, groups.
        
        Select which cloud apps
        
        Select conditions
        
        E.g. if you have enabled Azure Identity Protection, you can choose to evaluate sign-in risk as part of the policy.
        
        E.g. If you have configured trusted locations or named locations, you can specify to include or exclude those locations from the policy.
        
        Under Grant -> Ensure “Grant Access” and “Require multi-factor-authentication” is selected.
  - Enabled by Azure AD Identity Protection
    - Uses the Azure AD Identity Protection risk policy to require two-step verification based only on sign-in risk for all cloud applications
    - Cloud only
    - Flow: Azure AD -> Identity Protection -> (Configure) User risk policy
  - Enabled by changing user state
    - Requires users to perform two-step verification every time they sign in
      - Overrides conditional access policies
    - Works with both Azure MFA in the cloud and Azure MFA Server
    - User states
      - All users start out Disabled. When you enroll users in Azure MFA, their state changes to Enabled. When enabled users sign in and complete the registration process, their state changes to Enforced.
      - Do not manually change the user state to Enforced.
    - You can view states for users, and enable:
      - On Portal: Azure Active Directory > Users and groups > All users
      - Powershell script with iteration of users.
- MFA settings
  - Block/unblock users: Azure Active Directory > MFA > Block/unblock users -> Add -> Type e-mail
  - Fraud alerts
    - Allows users to report fraudulent attempts to access their resources by using the mobile app or through their phone.
    - Specific to on-premises MFA server.
    - Azure Active Directory > MFA > Fraud alert > Set On for Allow users to submit fraud alerts
    - Configuration options:
      - Block user when fraud is reported: If a user reports fraud, their account is blocked for 90 days or until an administrator unblocks their account.
      - Code to report fraud during initial greeting: When users receive a phone call to perform two-step verification, user presses a code to report its not user itself.
        
        It’s 0# by default, you can change it, you should then also change voice greeting with your own recording.
    - View fraud reports: Azure Active Directory > Sign-ins
  - One-time bypass
    - Allows a user to authenticate a single time without performing two-step verification.
    - The bypass is temporary and expires after a specified number of seconds.
    - It’s good when e.g. in situations where the mobile app or phone is not receiving a notification or phone call.
    - Create: Azure Active Directory > MFA > One-time bypass -> Enter user e-mail + seconds that the session will last
    - View: Azure Active Directory > MFA > One-time bypass.
  - Caching rules
    - You can set a time period to allow authentication attempts after a user is authenticated by using the caching feature
    - It’s not intended for Azure AD but on-premises.
    - Set-up: Azure Active Directory > MFA > Caching rules
  - Trusted IPs
    - Bypasses two-step verification for users who sign in from the company intranet.
    - Premium only feature
    - Options
      - Managed Azure AD Tenant: Specific range of IP addresses
      - Federated: All Federated Users (only from intranet), Specific range of IP addresses
    - End-user experience outside corpnet: Regardless of whether the Trusted IPs feature is enabled, two-step verification is required
    - Flow:
      - Via conditional access
        
        Enable named locations by using conditional access
        
        Azure Active Directory > Conditional access > Named locations -> New location -> Enter name + IP range + mark as trusted location
        
        Enable the Trusted IPs feature by using conditional access
        
        Azure Active Directory > Conditional access > Named locations -> Configure MFA trusted IPs
      - Via service settings
        
        Azure AD -> Users -> Multi-Factor Authentication -> Service settings
      - Two options while enabling trusted IPs:
        
        For requests from federated users originating from my intranet
        
        Ensure AD FS adds intranet claim with a rule.
        
        For requests from a specific range of public IPs
  - Remember Multi-factor Authentication: Remembers the device.
    - Azure Active Directory > Users and groups > All users -> MFA -> Service settings

This site is open source. Improve this page.

Azure-in-bullet-points

Implement workloads and security

Azure Migration

Azure Migrate Service

Azure Site Recovery Service DRaaS: Disaster Recovery as a Service

Web Apps PaaS

App Service Security

Serverless Computing

Azure Functions FaaS: Functions as a Service

Event Grid iPaaS: Integration Platform as a Service

Service BusPaaS

Logic Apps

Networking

Azure Load Balancer

Azure Application Gateway Application Delivery Controller (ADC) as a service

Site-to-Site VPN Connections

ExpressRoute

Manage role-based access control (RBAC)

Multi-Factor Authentication (MFA)

Azure Site Recovery Service ^{DRaaS: Disaster Recovery as a Service}

Web Apps ^PaaS

Azure Functions ^{FaaS: Functions as a Service}

Event Grid ^{iPaaS: Integration Platform as a Service}

Service Bus^PaaS

Azure Application Gateway ^{Application Delivery Controller (ADC) as a service}