learning-path-az-305.txt

{"category":"Design infrastructure solutions":[In this module, we explore compute solutions available in Azure. We look at Azure Virtual Machines, Azure Logic Apps, Azure App Service, Azure Functions, Azure Kubernetes Service, and other options. Some compute solutions support serverless scenarios, while other solutions work well with virtual machines and containers. We examine fast, scalable, flexible solution options to add compute power to your infrastructure.||Meet Tailwind Traders|||Tailwind Traders is a fictitious home improvement retailer. The company operates retail hardware stores across the globe and online.||As you work through this lesson, suppose you work for Tailwind Traders. The management team needs your input on several development projects that need to migrate to the cloud. There are also several new projects that should be optimized for the cloud. The departmental budgets are tight. It's important to select the right compute technology for each project. Ideally, you'd like to create and configure compute resources for each project, and pay only for the resources and services used.||Learning objectives|In this module, you learn how to:||Choose an Azure compute service.||Design for Azure Virtual Machines solutions.||Design for Azure Batch solutions.||Design for Azure Functions solutions.||Design for Azure Logic Apps solutions.||Design for Azure Container Instances solutions.||Design for Azure App Service solutions.||Design for Azure Kubernetes Service solutions.||Skills measured|The content in the module helps you prepare for Exam AZ-305: Designing Microsoft Azure Infrastructure Solutions. The module concepts are covered in:||Design infrastructure solutions||Design for compute solutions||Recommend an appropriately sized compute solution based on workload requirements||Recommend a container-based compute solution||Recommend a serverless-based compute solution||Recommend a virtual machine-based compute solution||Prerequisites|Conceptual knowledge of Azure compute solutions||Working experience with virtual machines, containers, and app serviceChoose an Azure compute service|Completed|100 XP|5 minutes|Azure offers several compute services. Compute refers to the hosting model for the computing resources that your applications run on.||Things to know about Azure compute services|Let's take a quick look at the Azure compute services we review in this module.||Azure Virtual Machines: Deploy and manage virtual machines inside an Azure virtual network.||Azure Batch: Apply this managed service to run large-scale parallel and high-performance computing (HPC) applications.||Azure App Service: Host web apps, mobile app backends, RESTful APIs, or automated business processes with this managed service.||Azure Functions: Use this managed service to run code in the cloud, without worrying about the infrastructure.||Azure Logic Apps: Configure this cloud-based platform to create and run automated workflows similar to capabilities in Azure Functions.||Azure Container Instances: Run containers in Azure in a fast and simple manner without creating virtual machines or relying on a higher-level service.||Azure Kubernetes Service (AKS): Run containerized applications with this managed Kubernetes service.||Things to consider when choosing Azure compute services|As you begin to compare Azure compute services to choose your infrastructure solution for Tailwind Traders, there are several implementation points to think about.||Architecture and infrastructure requirements|Support for new workload scenarios, like HPC applications|Required hosting options, including platform, infrastructure, and functions|Support for migrations, such as cloud-optimized or lift and shift|Workloads and architecture|When you plan for new instances of Azure services and new workloads, consider the following scenarios.||Control: Determine if you require full control over installed software and applications.||Workloads: Consider the workloads you need to support, such as HPC workloads or event-driven workloads.||Architecture: Think about what architecture best supports your infrastructure, including microservice, full-fledged orchestration, and serverless.||Migrations|An important consideration for your compute service involves analyzing the migration capabilities.||Cloud optimized: To migrate to the cloud and refactor applications to access cloud-native features, consider compute services that are cloud-optimized.||Lift and shift: For lift and shift workload migrations, consider compute services that don't require application redesigns or code changes.||Containerized: In your migration planning, consider whether your compute service needs to support containerized applications, or commercial off the shelf (COTS) apps.||Hosting|The hosting option of your compute solution determines the developer and cloud provider responsibilities. Azure offers three hosting options across the compute services.||Diagram that highlights the developer and cloud provider responsibilities for infrastructure and platform services.||Infrastructure-as-a-Service (IaaS) lets you create individual virtual machines along with the associated networking and storage components. Then you deploy the software and applications you want onto those virtual machines. This model is the closest to a traditional on-premises environment, except that Microsoft manages the infrastructure. You still manage the individual virtual machines. Azure Virtual Machines offers IaaS hosting.||Platform-as-a-Service (PaaS) provides a managed hosting environment, where you can deploy your application without needing to manage virtual machines or networking resources. Azure compute services that offer PaaS hosting include Azure Batch, App Service, Container Instances, and Azure Kubernetes Service.||Function-as-a-Service (FaaS) goes further in removing the need to worry about the hosting environment. In a FaaS model, you deploy your code, and the service automatically runs it. Azure Functions and Logic Apps offer FaaS hosting.||Azure compute service decision flowchart|Azure provides a decision flowchart with high-level guidance for how to select the appropriate Azure compute service for your scenario.|| Note||The following diagram has been edited to show only the Azure services described in this module.||The output from this decision flowchart is a starting point for your planning. You'll need to do a detailed evaluation of the services to determine exactly which solution meets your requirements. As you work through this module, refer to this diagram to become familiar with the considerations and options.||Flowchat that shows considerations and options for Azure compute solutions.||Design for Azure Virtual Machines solutions|Completed|100 XP|6 minutes|Azure Virtual Machines is the basis of the Azure Infrastructure-as-a-Service (IaaS) model. Virtual Machines can be used for developing, testing, and deploying applications in the cloud, or to extend your datacenter. Virtual Machines offers a fast, scalable, flexible way to add more compute power to your enterprise.||Things to know about Azure Virtual Machines|There are two main scenarios where Azure Virtual Machines can be an ideal compute solution for an infrastructure. Virtual Machines can be used to build new workloads and migrate data by using the lift and shift pattern.||Flowchart that shows the decision tree for selecting Azure Virtual Machines to build new workloads and to support lift and shift migration.||Build new workloads: Azure Virtual Machines is ideal when you're building new workloads and demand for your applications can fluctuate. It's economical to run your applications on a virtual machine in Azure.||Lift and shift migration: If you're using lift and shift (rehosting) migration to move data and applications from an on-premises location, targeting Azure Virtual Machines in the cloud is an effective strategy.||Things to consider when using Azure Virtual Machines|Let's walk through a checklist of things to consider when using Azure Virtual Machines as a compute solution. As you review these points, think about what configuration is needed for the Tailwind Traders requirements.||Start with your network.|Name your virtual machine, and decide the location.|Determine the size of your virtual machine.|Review the pricing model, and Azure Storage options.|Select an operating system.|Network configuration|The first thing to think about isn't your virtual machines at all - it's the network. Spend some time thinking about your network configuration for Tailwind Traders. Network addresses and subnets aren't trivial to change after they're configured. If you have an on-premises network, you'll want to carefully consider the network topology before you create any virtual machines.||Virtual machine name|Some developers don't give much thought about the name for a virtual machine. However, the virtual machine name defines a manageable Azure resource, and the value isn't easy to change. Choose machine names that are meaningful and consistent, so you can easily identify what each virtual machine does.||Consider how to name the first development web server for Tailwind Traders that's hosted in the US South Central location. In this scenario, you might use the machine name devusc-webvirtual machine01. dev stands for development and usc identifies the location. web indicates the machine as a web server, and the suffix 01 shows the machine is the first in the configuration.||Virtual machine location|Azure has datacenters all over the world filled with servers and disks. These datacenters are grouped into geographic regions like West US, North Europe, Southeast Asia, and so on. The datacenters provide redundancy and availability.||Each virtual machine is in a region where you want the resources like CPU and storage to be allocated. The regional location lets you place your virtual machines as close as possible to your users. The location of the machine can improve performance and ensure you meet any legal, compliance, or tax requirements.||There are two other points to consider about the virtual machine location.||The machine location can limit your available options. Each region has different hardware available, and some configurations aren't available in all regions.|There are price differences between locations. To find the most cost-effective choice, check for your required configuration in different regions.|Virtual machine size|After you choose the virtual machine name and location, you need to decide on the size of your machine. Azure offers different memory and storage options for different virtual machine sizes.||The best way to determine the appropriate machine size is to consider the type of workload your machine needs to run. Based on the workload, you can choose from a subset of available virtual machine sizes. The following table shows size classifications for Azure Virtual Machines workloads and recommended usage scenarios.||Classification	Description	Scenarios|General purpose	General-purpose virtual machines are designed to have a balanced CPU-to-memory ratio.	- Testing and development|- Small to medium databases|- Low to medium traffic web servers|Compute optimized	Compute optimized virtual machines are designed to have a high CPU-to-memory ratio.	- Medium traffic web servers|- Network appliances|- Batch processes|- Application servers|Memory optimized	Memory optimized virtual machines are designed to have a high memory-to-CPU ratio.	- Relational database servers|- Medium to large caches|- In-memory analytics|Storage optimized	Storage optimized virtual machines are designed to have high disk throughput and I/O.	- Virtual machines running databases|GPU	GPU virtual machines are specialized virtual machines targeted for heavy graphics rendering and video editing.	- Model training and inferencing with deep learning|High performance computes	High performance compute offers the fastest and most powerful CPU virtual machines with optional high-throughput network interfaces.	- Workloads that require fast performance|- High traffic networks|Virtual machine pricing|A subscription is billed two separate costs for every virtual machine: compute and storage. By separating these costs, you can scale them independently and only pay for what you need.||Compute costs: Compute expenses are priced on a per-hour basis but billed on a per-minute basis. If the virtual machine is deployed for 55 minutes, you're charged for only 55 minutes of usage. You're not charged for compute capacity if you stop and deallocate the virtual machine. The hourly price varies based on the virtual machine size and operating system you select.||Storage costs: You're charged separately for the Azure Storage the virtual machine uses. The status of the virtual machine has no relation to the Azure Storage charges that are incurred. You're always charged for any Azure Storage used by the disks.||Azure Storage|Azure Managed Disks handle Azure storage account creation and management in the background for you. You specify the disk size and the performance tier (Standard or Premium). Azure creates and manages the disk. As you add disks or scale the virtual machine up and down, you don't have to worry about the storage being used.||Operating system|Azure provides various operating system images that you can install into the virtual machine, including several versions of Windows and flavors of Linux. Azure bundles the cost of the operating system license into the price.||If you're looking for more than just base operating system images, you can search Azure Marketplace. There are various install images that include not only the operating system but popular software tools, such as WordPress. The image stack consists of a Linux server, Apache web server, a MySQL database, and PHP. Instead of setting up and configuring each component, you can install an Azure Marketplace image and get the entire stack all at once.||If you don't find a suitable operating system image, you can create your own disk image. Your disk image can be uploaded to Azure Storage and used to create an Azure virtual machine. Keep in mind that Azure only supports 64-bit operating systems.||Business application|Try the Azure Virtual Machines selector tool to find other sizes that best fit your workload.Design for Azure Batch solutions|Completed|100 XP|3 minutes|Azure Batch runs large-scale applications efficiently in the cloud. You can schedule compute-intensive tasks and dynamically adjust resources for your solution without managing infrastructure. Azure Batch can create and manage a pool of compute nodes (virtual machines). Azure Batch can also install the application you want to run, and schedule jobs to run on the compute nodes.||Things to know about Azure Batch|There are many scenarios where Azure Batch can be an ideal compute solution for your infrastructure. Azure Batch is similar to Azure Virtual Machines and can be used to build new workloads and migrate data.||Flowchart that shows the decision tree for selecting Azure Batch to build new workloads, and to support lift and shift or cloud-optimized migrations.||Azure Batch works well with applications that run independently (parallel workloads).||Azure Batch is effective for applications that need to communicate with each other (tightly coupled workloads). You can use Batch to build a service that runs a Monte Carlo simulation for a financial services company or a service to process images.||Azure Batch enables large-scale parallel and high-performance computing (HPC) batch jobs with the ability to scale to tens, hundreds, or thousands of virtual machines. When you're ready to run a job, Azure Batch:||Starts a pool of compute virtual machines for you.|Installs applications and staging data.|Runs jobs with as many tasks as you have.|Identifies failures, requeues work, and scales down the pool as work completes.|How Azure Batch works|A typical real-world scenario for Azure Batch requires data and application files. The Batch workflow begins with uploading the data and application files to an Azure storage account. Based on the demand, you create a Batch pool with as many Windows or Linux virtual compute nodes as needed. If the demand increases, compute nodes can be automatically scaled.||Diagram that shows how Azure Batch works to upload, download, create, and monitor tasks.||As you plan for your own configuration, you can separate aspects of the scenario into two parts: your service and the Azure Batch compute.||Your service uses Azure as the platform. The platform is used for completing computationally intensive work and retrieving results. You can also monitor jobs and task progress.||Azure Batch operates as the compute platform behind your service. Batch uses Azure Storage to fetch applications or data needed to complete a task. Azure Batch writes output to Azure Storage. Behind the scenes, there are collections (pools) of virtual machines. Pools are the resources that jobs and tasks are executed on.||Things to consider when using Azure Batch|Let's look at some best practices for using Azure Batch. As you review the suggestions, think about what scenarios can be accomplished by integrating Azure Batch in the Tailwind Traders infrastructure.||Consider pools. If your jobs consist of short-running tasks, don't create a new pool for each job. The overhead to create new pools diminishes the run time of the job. Also, it's best to have your jobs use pools dynamically. If your jobs use the same pool for everything, there's a chance that jobs won't run if something goes wrong with the pool.||Consider nodes. Individual nodes aren't guaranteed to always be available. If your Azure Batch workload requires deterministic, guaranteed progress, you should allocate pools with multiple nodes. Consider using isolated virtual machine sizes for workloads with compliance or regulatory requirements.||Consider jobs. Uniquely name your jobs so you can accurately monitor and log the activity. Consider grouping your tasks into efficiently sized jobs. It's more efficient to use a single job that contains 1,000 tasks rather than creating 100 jobs that have 10 tasks each.||Business application|Take a few minutes to read about other Azure Batch best practices.Design for Azure App Service solutions|Completed|100 XP|4 minutes|Azure App Service is an HTTP-based service that lets you build and host web apps, background jobs, mobile backends, and RESTful APIs. You can use the programming language of your choice and build automated deployments from GitHub, Azure DevOps, or any Git repo. App Service offers automatic scaling and high availability.||Things to know about Azure App Service|With Azure App Service, all your apps share common benefits. These benefits make App Service the ideal compute solution for any hosted web application to support new workloads and migrate data.||Flowchart that shows the decision tree for selecting Azure App Service to build new workloads and to support lift and shift migrations.||Azure App Service is a platform as a service (PaaS) environment. You focus on the website development and API logic. Azure handles the infrastructure to run and scale your web apps.||App Service supports development in multiple languages and frameworks, and offers integrated deployment and management with secured endpoints.||App Service offers built-in load balancing and traffic management at global scale with high availability.||App Service provides built-in authentication and authorization capabilities (sometimes referred to as Easy Auth). You can sign in users and access data by writing minimal or no code.||Continuous deployment|Azure App Service enables continuous deployment. Azure DevOps provides developer services for support teams to plan work, collaborate on code development, and build and deploy applications. Whenever possible when continuously deploying your code, use deployment slots for a new production build.||Diagram that shows container slots for development, staging, primary, and production when using Azure App Service.||When you choose a Standard App Service Plan tier or better, you can deploy your app to a staging environment, validate your changes, and do performance tests. When you're ready, you can swap your staging and production slots. The swap operation triggers the necessary worker instances to match your production scale.||Azure App Service costs|You pay for the Azure compute resources your app uses while it processes requests. The cost is based on the Azure App Service plan you choose. The App Service plan determines how much hardware is devoted to your host. The plan specifies whether you're using dedicated or shared hardware and how much memory is reserved. You can have different app service plans for different apps, and your plan can be scaled up and down at any time.||Things to consider when using Azure App Service|Let's look at some scenarios for using Azure App Service. As you review these options, think about how you can integrate Azure App Service in the Tailwind Traders infrastructure.||Consider web apps. Create web apps with App Service by using ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP, or Python. You can choose either Windows or Linux as the host operating system.||Consider API apps. Build API apps similar to REST-based web APIs with your choice of language and framework. Azure App Service offers full Swagger support, and the ability to package and publish your API in Azure Marketplace. The apps can be consumed from any HTTP or HTTPS client.||Consider WebJobs. Use the App Service WebJobs feature to run a program or script. Program examples include Java, PHP, Python, or Node.js. Script examples include cmd, bat, PowerShell, or Bash. WebJobs can be scheduled or run by a trigger. WebJobs are often used to run background tasks as part of your application logic.||Consider Mobile apps. Exercise the Mobile Apps feature of Azure App Service to quickly build a backend for iOS and Android apps. On the mobile app side, App Service provides SDK support for native iOS and Android, Xamarin, and React native apps. With just a few steps in the Azure portal, you can:||Store mobile app data in a cloud-based SQL database.|Authenticate customers against common social providers, such as MSA, Google, X, and Facebook.|Send push notifications.|Execute custom back-end logic in C# or Node.js.|Consider continuous deployment. Choose the Standard App Service Plan tier or better to enable continuous deployment of your code. Deploy your app to a staging slot and validate your app with test runs. When the app is ready for release, swap your staging and production slots. The swap operation warms up the necessary worker instances to match your production scale, which eliminates downtime.||Consider authentication and authorization. Take advantage of the built-in authentication capabilities in Azure App Service. You don't need any language, SDK, security expertise, or even any code to use the functionality in your web app or API. You can integrate with multiple sign-in providers, such as Microsoft Entra ID, Facebook, Google, and X. Azure Functions offers the same built-in authentication features that are available in App Service.||Consider multiple plans to reduce costs. Configure different Azure App Service plans for different apps. Scale your plan up and down at any time. Start testing your web app in a Free App Service plan and pay nothing. When you want to add your custom DNS name to the web app, just scale your plan up to the Shared tier.Design for Azure Container Instances solutions|Completed|100 XP|5 minutes|Virtual machines are an excellent way to reduce costs versus the investments that are necessary for physical hardware. However, each virtual machine is still limited to a single operating system. If you want to run multiple instances of an application on a single host machine, containers are an excellent choice.||Azure Container Instances are a fast and simple way to run a container on Azure. Scenarios for using Azure Container Instance include simple applications, task automation, and build jobs.||Things to know about Azure Container Instances|Azure Container Instances offers many benefits, including fast startup, per second billing, and persistent storage. These benefits make Azure Container Instances a great compute solution to support new workloads and migrate data by using the lift and shift pattern.||Flowchart that shows the decision tree for selecting Azure Container Instances to build new workloads and to support lift and shift migrations.||Azure Container Instances enables fast startup. You can launch containers in seconds for immediate access to applications.||Azure Container Instances implements per second billing. You incur costs only while your container is running.||Azure Container Instances supports custom sizes for your containers. You can specify exact values for CPU cores and memory and avoid costs for unused resources.||Container Instances offers persistent storage. Azure Files shares can be mounted directly to a container to retrieve and persist state.||Container Instances can be used with Linux and Windows. Schedule both Windows and Linux containers using the same API.||Container groups|The top-level resource in Azure Container Instances is the container group. A container group is a collection of containers that get scheduled on the same host machine. The containers in a container group share a lifecycle, resources, local network, and storage volumes.||Diagram that shows container groups with access from DNS on port 80 and Azure files on port 1433.||Multi-container groups are useful when you want to divide a single functional task into several container images. These images can then be delivered by different teams and have separate resource requirements. Some example scenarios include:||A container serving a web application and a container pulling the latest content from source control.|An application container and a logging container. The logging container collects the logs and metrics output by the main application and writes them to long-term storage.|An application container and a monitoring container. The monitoring container periodically makes a request to the application to ensure it's running and responding correctly, and raises alerts as needed.|A front-end container and a back-end container. The frontend might serve a web application with the backend running a service to retrieve data.|Things to consider when using Azure Container Instances|When you work with Azure Container Instances, there are several recommended security practices.||Use a private registry. Containers are built from images that are stored in one or more repositories. These repositories can belong to a public registry or to a private registry. An example of a private registry is the Docker Trusted Registry, which can be installed on-premises or in a virtual private cloud. Another example is Azure Container Registry that can be used to build, store, and manage container images and artifacts.||Ensure image integrity throughout the lifecycle. Part of managing security throughout the container lifecycle is to ensure the integrity of the container images. Images with vulnerabilities, even minor, shouldn't be allowed to run in a production environment. Keep the number of production images small to ensure they can be managed effectively.||Monitor container resource activity. Monitor your resource activity, like files, network, and other resources that your containers access. Monitoring resource activity and consumption are useful both for performance monitoring and as a security measure.||Compare Azure Container Instances to Azure Virtual Machines|The following table compares how important features are supported in Azure Container Instances and Azure Virtual Machines. As you review the following features, consider what features and support are required for the Tailwind Traders infrastructure compute solution.||Compare	Azure Container Instances	Azure Virtual Machines|Isolation	Container Instances typically provide lightweight isolation from the host and other containers, but doesn't provide as strong a security boundary as a virtual machine.	A virtual machine provides complete isolation from the host operating system and other virtual machines. Isolation is useful when a strong security boundary is critical, such as hosting apps from competing companies on the same server or cluster.|Operating system	Container Instances runs the user mode portion of an operating system and can be tailored to contain just the needed services for your application. This configuration results in fewer system resources being utilized.	Each virtual machine runs a complete operating system. Azure Virtual Machines typically requires more system resources than Container Instances, such as CPU, memory, and storage.|Deployment	Container Instances deploy individual containers by using Docker via the command line. Multiple containers are deployed by using an orchestrator such as Azure Kubernetes Service.	You can deploy individual virtual machines by using Windows Admin Center or Hyper-V Manager. Multiple virtual machines can be deployed by using PowerShell or System Center Virtual Machine Manager.|Persistent storage	Container Instances use Azure Disks for local storage for a single node, or Azure Files (SMB shares) for storage shared by multiple nodes or servers.	With Azure Virtual Machines, you can use a virtual hard disk (VHD) for local storage for a single virtual machine, or an SMB file share for storage shared by multiple servers.|Fault tolerance	If a cluster node fails in Azure Container Instances, any containers running on it are rapidly recreated by the orchestrator on another cluster node.	A virtual machine can fail over to another server in a cluster with the operating system of the virtual machine restarting on the new server.|Design for Azure Kubernetes Service solutions|Completed|100 XP|4 minutes|Kubernetes is a portable, extensible open-source platform for automating deployment, scaling, and the management of containerized workloads. This orchestration platform provides the same ease of use and flexibility as with Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) offerings. Kubernetes provides both container management and container orchestration.||Diagram that shows how container orchestration dynamically or automatically scales container instances.||Container management is the process of organizing, adding, removing, or updating a significant number of containers. Most of these tasks are manual and error prone. Container orchestration is a system that automatically deploys and manages containerized applications. The orchestrator can dynamically increase or decrease the deployed instances of the managed application. The orchestrator can also ensure all deployed container instances get updated if a new version of a service is released.||Azure Kubernetes Service (AKS) manages your hosted Kubernetes environment and makes it simple to deploy and manage containerized applications in Azure.||Things to know about Azure Kubernetes Service|The Azure Kubernetes Service environment is enabled with many features, such as automated updates, self-healing, and easy scaling. Review the following characteristics that make AKS an appealing compute option to build new workloads and support lift and shift migrations.||Flowchart that shows the decision tree for selecting Azure Kubernetes Service to build new workloads and to support lift and shift migrations.||The Kubernetes cluster is managed by Azure and is free. You manage the agent nodes in the cluster and only pay for the virtual machines on which your nodes run.||When you create the cluster, you can use Azure Resource Manager (ARM) templates to automate cluster creation. With ARM templates, you specify features like as advanced networking, Azure Active Directory (AD) integration, and monitoring.||AKS gives you the benefits of open-source Kubernetes. You don't have the complexity or operational overhead of running your own custom Kubernetes cluster.||Things to consider when using Azure Kubernetes Service|There are several factors to consider when deciding whether Azure Kubernetes Service is the right compute solution for your infrastructure. A good approach is to plan your strategy from two points of view. Consider the features from the approach of a green field new project, and also from the perspective of a lift-and-shift migration. The following features are configurable when you create a new cluster and also after you deploy.||Feature	Consideration	Solution|Identity and security management	Do you already use existing Azure resources and make use of Azure Active Directory (Azure AD)?	You can configure an Azure Kubernetes Service cluster to integrate with Azure AD and reuse existing identities and group membership.|Integrated logging and monitoring	Are you using Azure Monitor?	Azure Monitor provides performance visibility of the cluster.|Automatic cluster node and pod scaling	Do you need to scale up or down a large containerization environment?	AKS supports two auto cluster scaling options. The horizontal pod autoscaler watches the resource demand of pods and increases pods to meet demand. The cluster autoscaler component watches for pods that can't be scheduled because of node constraints. It automatically scales cluster nodes to deploy scheduled pods.|Cluster node upgrades	Do you want to reduce the number of cluster management tasks?	AKS manages Kubernetes software upgrades and the process of cordoning off nodes and draining them.|Storage volume support	Does your application require persisted storage?	AKS supports both static and dynamic storage volumes. Pods can attach and reattach to these storage volumes as they're created or rescheduled on different nodes.|Virtual network support	Do you need pod-to-pod network communication or access to on-premises networks from your AKS cluster?	An AKS cluster can be deployed into an existing virtual network with ease.|Ingress with HTTP application routing support	Do you need to make your deployed applications publicly available?	The HTTP application routing add-on makes it easy to access AKS cluster deployed applications.|Docker image support	Do you already use Docker images for your containers?	By default, AKS supports the Docker file image format.|Private container registry	Do you need a private container registry?	AKS integrates with Azure Container Registry (ACR). You aren't limited to ACR though, you can use other container repositories, public, or private.|Business application|Take a few minutes to read about how Mercedes-Benz R&D is using Azure Kubernetes Service.Design for Azure Functions solutions|Completed|100 XP|3 minutes|Azure Functions is a serverless application platform. Functions are used when you want to run a small piece of code in the cloud, without worrying about the infrastructure.||Things to know about Azure Functions|Let's review some benefits and scenarios of Azure Functions that make it a great compute solution for building new workloads.||Flowchart for selecting Azure Functions solutions to build new workloads.||Azure Functions provides intrinsic scalability. You're charged only for the resources you use.||With Azure Functions, you can write your function code in the language of your choice.||Azure Functions supports compute on demand in two significant ways:||Azure Functions lets you implement your system's logic into readily available blocks of code. These code blocks (functions) can run anytime you need to respond to critical events.||As requests increase, Azure Functions meets the demand with as many resources and function instances as necessary. As requests complete, any extra resources and application instances drop off automatically.||Azure Functions is an ideal solution for handling specific definable actions triggered by an event. A function can process an API call and store the processed data in Azure Cosmos DB. After the data transfer happens, another function can trigger a notification.||Diagram that shows how Azure Functions responds to API calls and outputs data to Azure Notification Hubs.||Things to consider when using Azure Functions|Let's look at some best practices for using Azure Functions. As you consider these suggestions, think about the advantages to using Azure Functions in the Tailwind Traders infrastructure.||Consider long running functions. Avoid large, long-running functions that can cause unexpected timeout issues. Whenever possible, refactor large functions into smaller function sets that work together and return responses faster. The default timeout is 300 seconds for Consumption Plan functions, and 30 minutes for any other plan.||Consider durable functions. Overcome timeout issues in your configuration with durable functions and smaller function sets. Durable functions let you write stateful functions. Behind the scenes, the function manages the application state, checkpoints, and restarts. An example application pattern for durable functions is function chaining. Function chaining executes a sequence of functions in a specific order. The output of one function is applied to the input of another function.||Consider performance and scaling. Plan how to group functions with different load profiles. Consider a scenario where you have two functions. One function processes many thousands of queued messages and has low memory requirements. The other function is called only occasionally but has high memory requirements. In this scenario, you might want to deploy separate function applications, where each function has its own set of resources. Separate resources means you can independently scale the functions.||Consider defensive functions. Design your functions to handle exceptions. Downstream services, network outages, or memory limits can cause a function to fail. Write your functions so they can continue if a failure occurs.||Consider not sharing storage accounts. Maximize performance by using a separate storage account for each function application. When you create a function app, associate it with a unique storage account. Using a unique storage account is important if your function generates a high volume of storage transactions.||Business application|Take a few minutes to read about other Azure Functions best practices.||You can get more ideas on how to use Azure Functions by checking out the code samples page.Design for Azure Logic Apps solutions|Completed|100 XP|4 minutes|Azure Logic Apps is another type of serverless compute solution that offers a cloud-based platform for creating and running automated workflows. Workflows are step-by-step processes that integrate your applications, data, services, and systems. With Azure Logic Apps, you can quickly develop highly scalable integration solutions for your enterprise and business-to-business (B2B) scenarios.||Things to know about Azure Logic Apps|Let's review some characteristics of Azure Logic Apps and scenarios for using the compute solution to build new workloads.||Flowchart for selecting Azure Logic Apps solutions to build new workloads.||Azure Logic Apps is a component of Azure Integration Services. Logic Apps simplifies the way you connect legacy, modern, and cutting-edge systems across cloud, on-premises, and hybrid environments.||With Logic Apps, you can schedule and send email notifications by using Office 365 when a specific event happens, such as a new file uploaded.||Use Logic Apps to route and process customer orders across on-premises systems and cloud services.||Implement Logic Apps to move uploaded files from an SFTP or FTP server to Azure Storage.||Monitor tweets and analyze sentiment with Logic Apps, and create alerts or tasks for items that need review.||Compare Azure Logic Apps and Azure Functions|Azure Logic Apps is similar to Azure Functions as a compute service, but there are basic differences. Azure Functions is a code-first technology that uses durable functions. Azure Logic Apps is a design-first technology. Review the following flowchart and table to compare the two solutions.||Flowchart that shows the decision tree for when to use Azure Functions and Azure Logic Apps.||Compare	Azure Functions	Azure Logic Apps|Development	Code-first	Design-first|Method	Write code and use the durable functions extension	Create orchestrations with a GUI or by editing configuration files|Connectivity	- Large selection of built-in binding types|- Write code for custom bindings	- Large collection of connectors|- Enterprise Integration Pack for B2B scenarios|- Build custom connectors|Monitoring	Azure Application Insights	Azure portal, Azure Monitor Logs (Log Analytics)|Things to consider when using Azure Logic Apps|There are several points to consider when deciding whether Azure Logic Apps is the ideal compute solution for your infrastructure. Review the following considerations, and think about how Azure Logic Apps can enhance the compute strategy for Tailwind Traders.||Consider integration. Use Logic Apps to provide the critical infrastructure component of integration with services. Logic Apps is a good option when you need to get multiple applications and systems to work together. If you're building an app with no external connections, Logic Apps is probably not the best option.||Consider performance. Scale your apps automatically with the Logic Apps execution engine. Logic Apps can process large datasets in parallel to let you achieve high throughput. However, fast activation time isn't always guaranteed, nor enforcement of real-time constraints on execution time.||Consider conditional expressions. Build highly complex and deeply nested conditionals into your Logic Apps. Logic Apps provides control constructs like Boolean expressions, switch statements, and loops so your apps can make decisions based on your data.||Consider connectors. Investigate whether pre-built connectors are available for all the services you need to access. You might need to create custom connectors. If a service has an existing REST or SOAP API, you can make the custom connector in a few hours without writing any code. Otherwise, you need to create the API first before making the connector.||Consider mixing compute solutions. Take advantage of diverse features by mixing and matching services when you build an orchestration. You can call functions from Logic Apps, and call logic apps from an Azure function. Build each orchestration based on the service capabilities or your personal preference.||Consider other options. Know when not to use Azure Logic Apps. There are cases where Logic Apps might not be the best option. Logic Apps isn't an ideal solution for real-time requirements, complex business rules, or if you're using non-standard services.||Business application|Take a few minutes to learn how Azure Logic Apps distributes data from drones inspecting power lines.||You can use the following flowchart for other questions to ask as you plan for using Azure Logic Apps.||Flowchart that shows a detailed decision tree for when to use Azure Logic Apps.<Knowledge check|Completed|200 XP|3 minutes|Tailwind Traders has several active development projects. As the solution Architect for the company, you're responsible for selecting the right compute technology for each project. Ideally, you'd like to create compute resources and configure them to do the work and only pay for the services used.||Here are the specific project requirements:||Real-time inventory tracking. Each evening, product availability is updated on the company website. The management team wants the stock inventory updated as soon as products are ordered. To fulfill this requirement, the product database needs to be updated, and stock reorder notifications need to be sent, as needed. The current program is a Windows service written in C#.||Migrate datacenter virtual machines. The datacenter virtual machines host relational database servers. These machines are used for online orders. The company needs a solution to move this capability to the cloud.||Host data processing application in the cloud. The company has a small data processing application. The app ingests new product photos and writes the content to Azure Blob Storage. The app takes only a few seconds to run. The sales team needs a solution that hosts the app in the cloud and reduces costs.||Answer the following questions|Choose the best response for each of the questions. Then select Check your answers.|||1. Which compute option best supports the real-time inventory tracking requirement? ||Azure Logic Apps||Azure Functions|Correct. The Tailwind Traders development logic is written in C#. It makes sense to copy the relevant C# code from the Windows service and port it to an Azure function. The developers can bind the function to trigger each time a new message appears on a specific queue.|||Azure Virtual Machines|2. What type of virtual machine is best for the datacenter migration requirement? ||General purpose VM||Compute-optimized VM|Incorrect. Compute-optimized VMs are designed to have a high CPU-to-memory ratio. Compute-optimized VMs are suitable for medium traffic web servers, network appliances, batch processes, and application servers.|||Memory-optimized VM|Correct. Memory-optimized VMs are designed to have a high memory-to-CPU ratio. Memory-optimized VMs are great for relational database servers, medium to large caches, and in-memory analytics.||3. What compute solution is best for hosting the company's data processing application? ||Azure Container Instances|Correct. Azure Container Instances is an ideal compute solution for containers. The company can achieve significant cost savings by using per-second billing.|||Azure Virtual Machines||Web Apps (supported by Azure App Service)|Incorrect. The Web Apps feature is a better option for hosted web applications.>Summary and resources|Completed|100 XP|2 minutes|In this module, you learned how to choose and recommend an Azure compute solution. You reviewed scenarios for Azure Virtual Machines, Azure Logic Apps, Azure Functions, and Azure Container Instances. Azure Logic Apps and Azure Functions offer serverless compute options. You also looked at scenarios for supporting applications with Azure Batch, Azure App Service, and Azure Kubernetes Service. App Service lets you use the programming language of your choice. Azure Kubernetes Service makes it simple to deploy and manage containerized applications. You explored how to host applications in the cloud with Azure compute services to improve performance, scalability, and flexibility.||Learn more with Azure documentation|Choose an Azure compute service.||Review documentation for virtual machines in Azure.||Read about Azure App Service.||Read about Azure Batch.||Read about Azure Container Instances.||Read about Azure Functions.||Read about Azure Logic Apps.||Discover what is Kubernetes.||Read about the Azure Kubernetes Service.||Review security considerations for Azure Container Instances.||Learn more with self-paced training|Choose the best Azure service to automate your business processes.||Align requirements with cloud types and service models in Azure.||Complete an introduction to Azure Logic Apps.||Complete an introduction to Azure Kubernetes Service.||Learn more with optional hands-on exercises|Practice with an Introduction to Azure Virtual Machines (sandbox).||Create an Azure Batch account by using the Azure portal. (Azure subscription required.)||Create serverless logic with Azure Functions (sandbox).||Create a web app in the Azure portal (sandbox).||Create a Windows virtual machine (sandbox).||Create the social media tracker Logic App (sandbox).||Host a web application with Azure App Service (sandbox).]}
{"category":"Design identity, governance, and monitor solutions":[|Plan|Completed|100 XP|5 minutes|How the cloud can advance your business strategy depends on your situation. The cloud delivers fundamental technology benefits that can aid in executing multiple business strategies. Using cloud-based approaches can improve business agility, reduce costs, accelerate time to market, and even allow businesses to quickly expand into new markets.||As your organization moves forward in your cloud adoption journey, proper planning is key to your success. Your organization already has technology investments, so you must understand your current state and then develop a prioritization plan for your cloud journey.||In this stage, you focus on two main actions:||Rationalize your digital estate: Understand the organization's current digital estate to maximize return and minimize risks by running a workload assessment.|Create your cloud adoption plan: Develop a plan where prioritized workloads are defined and aligned with business outcomes.|Icon indicating play video||Watch this video to learn more.||||Rationalize your digital estate|A digital estate is the collection of IT assets that power business processes and supporting operations. To begin cloud rationalization of the digital estate, inventory all the digital assets the organization owns today. Then, evaluate each asset to determine the best way to migrate or modernize each component to the cloud.||During this process, we recommend that you proceed incrementally, application by application. Don't make decisions too broadly or too early across the entire application portfolio.||There are five options for cloud rationalization, sometimes referred to as the Five Rs:||Rationalization option||Expected business outcome||Share Rehost||Also known as a lift-and-shift migration, a rehost effort moves a current state asset to the chosen cloud provider, with minimal change to overall architecture.||Reduce capital expense.|Free up datacenter space.|Achieve rapid return on investment in the cloud.|Web design Refactor||Refactor also refers to the application development process of refactoring code to allow an application to deliver on new business opportunities.||Experience faster and shorter updates.|Benefit from code portability.|Achieve greater cloud efficiency in the areas of resources, speed, cost.|Playbook Rearchitect||When aging applications aren't compatible with the cloud, they might need to be rearchitected to produce cost and operational efficiencies in the cloud.||Gain application scale and agility.|Adopt new cloud capabilities more easily.|Use a mix of technology stacks.|Power Rebuild/New||Unsupported, misaligned, or out-of-date on-premises applications might be too expensive to carry forward. A new code base with a cloud-native design might be the most appropriate and efficient path.||Accelerate innovation.|Build applications faster.|Reduce operational cost.|Cloud computing Replace||Sometimes the best approach is to replace the current application with a hosted application that meets all functionality required in the cloud.||Standardize around industry best practices.|Accelerate adoption of business process-driven approaches.|Reallocate development investments into applications that create competitive differentiation or advantages.|Create your cloud adoption plan|As you develop a business justification model for your organization's cloud journey, identify business outcomes that can be mapped to specific cloud capabilities and business strategies to reach the desired state of transformation. Documenting all these outcomes and business strategies serves as the foundation for your organization's cloud adoption plan.||Key steps to build this plan are to:||Review sample business outcomes.|Identify the leading metrics that best represent progress toward the identified business outcomes.|Establish a financial model that aligns with the outcomes and learning metrics.| Tip||Links to sample business outcomes, the business outcome template, learning metrics, the financial model, and the digital estate document are available in the Summary and resources unit at the end of this module.||Icon of key||Here are the key points from this unit:||In the plan stage, there are two major actions: rationalizing your digital estate and creating your cloud adoption plan.|In the Plan phase, there are five options for cloud rationalization: rehost, refactor, rearchitect, rebuild/new, and replace. During this process, we recommend that you proceed incrementally.We just looked at how a business plan aligned to a digital estate rationalization can ensure you know why you'll benefit from moving to the cloud. Cloud adoption is a strategic change that requires involvement from both business decision makers and end users. Now, let's talk about how to get your organization ready for this journey:||Define skills and support readiness: Create and implement a skills-readiness plan to:|Address current gaps.|Ensure that IT and business people are ready for the change and the new technologies.|Define support needs.|Create your landing zone: Set up a migration target in the cloud to handle prioritized applications.|The Azure readiness guide introduces features that help you organize resources, control costs, and secure and manage your organization. Links to sample skills-readiness learning paths on Microsoft Learn and Azure Support are available in the Summary and resources unit at the end of this module.||Create your landing zone|Before you begin to build and deploy solutions with Azure services, make sure your environment is ready. The term landing zone is used to describe an environment that's provisioned and prepared to host workloads in a cloud environment, such as Azure. A fully functioning landing zone is the final deliverable of any iteration of the Cloud Adoption Framework for Azure methodology.||Icon of lightbulb||Each landing zone is part of a broader solution for organizing resources across a cloud environment. These resources include management groups, resource groups, and subscriptions. Azure offers many services that help you organize resources, control costs, and secure and manage your organization's Azure subscription. Microsoft Cost Management + Billing also provides a few ways to help you predict, analyze, and manage costs.|| Note||For an interactive experience, view the environment-readiness content in the Azure portal. Go to the Azure Quickstart Center in the Azure portal, and select introduction to Azure setup. Then follow the step-by-step instructions.|| Tip||Standards-based Azure Blueprints samples are available and ready to use. Visit the list of available samples that are ready to use or modify for your needs, linked in the Summary and resources unit at the end of this module.||Icon of key||Here are the key points from this unit:||Cloud adoption is a strategic change that requires involvement from both business decision makers and end users.|When you define skills and support readiness, create and implement a skills-readiness plan to address current gaps, ensure that people are ready for the change, and define support needs.|The process of creating your landing zone sets up a migration target in the cloud to handle prioritized applications.At this point, you've established your business justification and defined your business outcomes. You've prepared your organization. Your people and your Azure environment are ready to deploy your prioritized applications. You're ready to adopt cloud technologies following the selected digital estate rationalization path.|As discussed, your organization has unique motivations to adopt the cloud. They all converge into migration or innovation to the cloud.|Cloud migration|Cloud migration is the process of moving existing digital assets to a cloud platform. Existing assets are replicated to the cloud with minimal modifications. After an application or workload becomes operational in the cloud, users are transitioned from the existing solution to the cloud solution.||Icon of lightbulb||Cloud migration is one way to effectively balance a cloud portfolio. This is often the fastest and most agile approach in the short term. Conversely, some benefits of the cloud might not be realized without additional future modification. Enterprises and mid-market customers use this approach to accelerate the pace of change, avoid planned capital expenditures, and reduce ongoing operational costs.||The strategy and tools you use to migrate an application to Azure largely depend on your business motivations, technology strategies, and timelines. Your decisions are also based on a deep understanding of the application and the assets to be migrated. These assets include infrastructure, apps, and data. This decision tree serves as high-level guidance to help you select the best tools to use based on migration decisions.||Migration preparation: Establish a rough migration backlog, based largely on the current state and desired outcomes.||Business outcomes: The key business objectives that drive this migration. They're defined in the Plan phase.|Digital estate estimate: A rough estimate of the number and condition of workloads to be migrated. It's defined in the Plan phase.|Roles and responsibilities: A clear definition of the team structure, separation of responsibilities, and access requirements. They're defined in the Ready phase.|Change management requirements: The cadence, processes, and documentation required to review and approve changes. They're defined in the Ready phase.|Cloud innovation|Cloud-native applications and data accelerate development and experimentation cycles. Older applications can take advantage of many of the same cloud-native benefits by modernizing the solution or components of the solution. Modern DevOps and software development lifecycle (SDLC) approaches that use cloud technology shorten the time from idea to product transformation. Combined, these tools invite the customer into the process to create shorter feedback loops and better customer experiences.||Modern approaches to infrastructure deployment, operations, and governance are rapidly bridging the gaps between development and operations. Modernization and innovation in the IT portfolio create tighter alignment with DevOps and accelerate innovations across the digital estate and application portfolio.||Icon of key||Here are the key points from this unit:||Cloud migration is the process of moving existing digital assets to a cloud platform. Adopt is divided into two different options, migrate and innovate.|Each cloud migration activity is contained during one of the following processes, as it relates to the migration backlog: assess, migrate, optimize, and secure. Then, you manage each backlog asset.|Modernization and innovation in the IT portfolio create tighter alignment with DevOps and accelerate innovations across the digital estate and application portfolio.|You've learned how to plan, get ready, and start to deploy your first applications to the cloud. Now let's talk about governance and management in the cloud.|Govern and manage|Completed|100 XP|6 minutes|The process of adopting the cloud is a journey, not a destination. Along the way, there are clear milestones and tangible business benefits. The final state of cloud adoption is unknown when an organization begins the journey. As your organization moves or deploys new applications to the cloud, this final state starts to form. It's important to consider the following aspects of managing and operating a cloud platform:||Define governance solutions for your cloud environment that meet your organization's business needs, provide agility, and control risks.|Manage your cloud environment based on the governance solutions to allow it to evolve, grow, and adapt to your organization's changing business needs.|Cloud governance|Cloud governance creates guardrails that keep the organization on a safe path throughout the journey. The Cloud Adoption Framework for Azure governance model identifies key areas of importance. Each area relates to different types of risks the organization must address as it adopts more cloud services.||Because governance requirements will evolve throughout the cloud adoption journey, a flexible approach to governance is required. IT governance must move quickly and keep pace with business demands to stay relevant during cloud adoption.||Incremental governance relies on a small set of corporate policies, processes, and tools to establish a foundation for adoption and governance. That foundation is called a minimum viable product (MVP). An MVP allows the governance team to quickly incorporate governance into implementations throughout the adoption lifecycle. After this MVP is deployed, additional layers of governance can be quickly incorporated into the environment.|| Tip||To determine where you should start to implement your own cloud governance, use the Microsoft assessment tools linked in the Summary and resources unit at the end of this module.||Cloud management|The goal of the Manage methodology is to maximize ongoing business returns by creating balance between stability and operational costs. Stable business operations lead to stable revenue streams. Controlled operational costs reduce the overhead to drive more profit from the business processes.|| Tip||Links to the scalability, availability, and resiliency resources are available in the Summary and resources unit at the end of this module.||Cloud operations creates a maturity model that helps the team fulfill commitments to the business. In the early stages of maturity, customers focus on basic needs such as inventory and visibility into cloud assets and performance. As operations in the cloud mature, the team can use cloud native or hybrid approaches to maintaining operational compliance, which reduces the likelihood of interruptions through configuration and state management. After compliance is achieved, protection and recovery services provide low-impact ways to reduce the duration and effect of business process interruptions. During platform operations, aspects of various platforms (like containers or data platforms) are adjusted and automated to improve performance.||Icon of key||Here are the key points from this unit:||As your organization moves or deploys new applications to the cloud, it's important to consider these aspects of operating a cloud platform:|Define governance solutions for your cloud environment.|Manage your cloud environment.|The Cloud Adoption Framework governance model identifies key areas of importance. Each area relates to different types of risks the organization must address as it adopts more cloud services. The Five Disciplines of Cloud Governance are Cost Management, Security Baseline, Resource Consistency, Identity Baseline, and Deployment Acceleration.|Knowledge check|Completed|200 XP|7 minutes||1. The Cloud Adoption Framework for Azure helps customers make their journey to the cloud. What are the three main stages of the framework? ||Plan, Business Justification, and Implementation.||Migrate, Test, and Optimize.||Plan, Ready, and Adopt.|Correct. The Cloud Adoption Framework describes how the organization must prepare its people with technical readiness, adjust business processes to drive business and technology changes, and enable business outcomes through implementation of the defined technology plan.||2. Motivations for cloud adoption include migration and innovation triggers. Migration triggers include such things as cost saving and operations optimization. Which of the following is an example of an innovation trigger, which drives cloud adoption? ||Reduction in IT staff for on-premises hardware.|Incorrect. Reduction in IT staff isn't an innovation trigger, but optimization of internal operations can be a migration trigger.|||Transform products or services.|Correct. The desire to transform products or services might be an innovation trigger, which drives cloud adoption.|||Increase business agility.|3. What are the five disciplines of cloud governance? ||Business risk, process, policy and compliance, resource consistency, and deployment acceleration.||Business risk, policy and compliance, security baseline, process, and operations.||Cost management, security baseline, resource consistency, identity baseline, and deployment acceleration.|Correct. When you build your cloud governance strategy, you need to think about cost management, setting a security baseline, working toward resource consistency through best practices, establishing the identity and access strategy, and accelerating deployment with consistent templates.||4. The common value drivers that business decision makers can use to justify moving their business to the cloud are Cost, Scale, Productivity, and Reliability. What is the specific value of scale in cloud computing? ||Scale is the ability to deliver the right amount of IT resources.|Correct. Scale is the ability to scale elastically and deliver the right amount of IT resources.|||Scale eliminates capital expense.|Incorrect. Cost, not Scale, is the cloud computing business value area, which eliminates capital expense.|||Scale eases the burden of data backup, disaster recovery, and business continuity.|5. Financial planning for cloud adoption requires organizations to decide whether to expand on-premises capabilities or move certain workloads and functions off-premises to cloud-delivered services. Microsoft has tools that can help. What Microsoft tool is available for a CFO who's trying to estimate the expected monthly bill? ||The Azure Total Cost of Ownership (TCO) Calculator.||The Azure Pricing Calculator.|Correct. Organizations can estimate their expected monthly bills by using the pricing calculator to track their actual account usage and bills at any time on the billing portal.|||Microsoft Cost Management.||Summary and resources|Completed|100 XP|4 minutes|Moving to the cloud is a complex undertaking. It requires the alignment of senior business leaders on the business value of making the move. They must then create an effective cloud adoption strategy that will be adopted by employees.||The Microsoft Cloud Adoption Framework for Azure can help your business easily identify:||When to move to the cloud.|How to create an effective migration strategy.|Which approach to technology migration and modernization your business should take.|Now that you have reviewed this module, you should be able to:||Use the Cloud Adoption Framework to identify where you are in the digital transformation journey.|Identify triggers and opportunities for cloud adoption.|Recognize the components needed to develop a digital transformation strategy around your business, people, and technology.|Key takeaways|Here are the six key takeaways:||Icon of lightbulb||The three main components of the Cloud Adoption Framework (plan, ready, and adopt) can be applied to different stages for cloud adopters. They should be revisited often because cloud adoption is an ongoing journey, not a destination.||A modernization trigger is an event that initiates the cloud adoption journey for an enterprise. The most common modernization triggers include datacenter contracts expiring, the need to deliver applications and features faster, urgent capacity needs, a software or hardware refresh, the need to address security threats, compliance, enabling new business opportunities, and software end of support.||The Plan phase focuses on aligning technology decisions to business priorities, with clear business outcomes and setting the proper cloud rationalization approach.||Readying your people, organization process, and environment for cloud adoption are critical factors in the success of your cloud adoption journey.||Adopting the cloud technologies defined in your plan and for which you have readied your organization depends on what you're actually doing. Are you migrating or innovating with a new workload to the cloud?||Governing and managing your cloud environment is as critical to your successful cloud adoption as any other stage. As such, it should be considered and executed properly.||Resources|Use these resources to discover more.|| Tip||To open a resource link, select and hold (or right-click) and select Open in a new tab or window. That way, you can check out the resource and easily return to the module tab to unlock your achievement when you're finished.||Microsoft Cloud Adoption Framework for Azure:||Microsoft Cloud Adoption Framework for Azure documentation|Financial planning:||Total cost of ownership (TCO) calculator||Azure pricing calculator||Microsoft Cost Management||Create a financial model for cloud transformation||Skills readiness paths:||Azure fundamentals part 1: describe core Azure concepts|Microsoft certified: Azure solutions architect expert|Solutions architect: learning path|Cloud migration:||Migration in documentation||Migration considerations||Migration tools decision guide||Cloud governance:||Governance in the Cloud Adoption Framework||Azure Blueprints samples||Cloud adoption plan:||Review sample business outcomes.||Review approaches to digital estate planning.||Document those findings in the provided business outcome template to share with internal partners during the transformation journey.||Identify the learning metrics that best represent progress toward the identified business outcomes.||Establish a financial model that aligns with the outcomes and learning metrics.||Document and incorporate the digital estate in the current environment to populate the financial model.||),(Design identity, governance, and monitor solutions:The term governance describes the general process of establishing rules and policies. Governance ensures those rules and policies are enforced.||A good governance strategy helps you maintain control over the applications and resources that you manage in the cloud. Maintaining control over your environment ensures that you stay compliant with:||Industry standards, such as information security management.||Corporate or organizational standards, such as ensuring that network data is encrypted.||Governance is most beneficial when you have:||Multiple engineering teams working in Azure.||Multiple subscriptions to manage.||Regulatory requirements that must be enforced.||Standards that must be followed for all cloud resources.||Meet Tailwind Traders|||Tailwind Traders is a fictitious home improvement retailer. The company operates retail hardware stores across the globe and online. As you work through this lesson, suppose you're the CTO for Tailwind Traders. You're aware of the opportunities offered by Azure and also understand the need for strong governance. Without strong governance, the company might end up with an environment that's difficult to manage, and costs that are hard to track and control. You're interested in understanding how Azure manages and enforces governance standards.||Learning objectives|In this module, you learn how to:||Design for governance.||Design for management groups.||Design for Azure subscriptions.||Design for resource groups.||Design for Azure Policy.||Design for resource tags.||Design for Azure landing zones.||Skills measured|The content in this module helps you prepare for Exam AZ-305: Designing Microsoft Azure Infrastructure Solutions. The module concepts are covered in:||Design identity, governance, and monitoring solutions||Design a governance solution||Recommend a strategy for Azure policies and resource tags||Recommend a strategy for Azure Blueprints||Recommend a strategy for Azure landing zones||Prerequisites|Conceptual knowledge of governance policies, resource organization, and subscription management||Working experience with organizing resources, applying governance policies, and enforcing compliance requirements|Design for governance|Completed|100 XP|2 minutes|Governance provides mechanisms and processes to maintain control over your applications and resources in Azure. Governance involves determining your requirements, planning your initiatives, and setting strategic priorities.||To effectively apply your governance strategies, you must first create a hierarchical structure for your organizational environment. This structure lets you apply governance strategies exactly where they're needed. The governance strategies we cover in this module are Azure policy and resource tags.||Diagram of the Azure hierarchy that shows the tenant root group, management groups, subscriptions, resource groups, and resources.||A typical Azure hierarchy has four levels: management groups, subscriptions, resource groups, and resources. We examine the details of these levels later in this module.||Management groups help you manage access, policy, and compliance for multiple subscriptions.||Subscriptions are logical containers that serve as units of management and scale. Subscriptions are also billing boundaries.||Resource groups are logical containers into which Azure resources are deployed and managed.||Resources are instances of services that you create. For example, virtual machines, storage, and SQL databases.|| Note||The tenant root group contains all the management groups and subscriptions. This group allows global policies and Azure role assignments to be applied at the directory level.|Design for management groups|Completed|100 XP|3 minutes|Management groups are containers that help you manage access, policy, and compliance across multiple subscriptions. You can use management groups to:||Limit the regions where virtual machines can be created, across subscriptions.||Provide user access to multiple subscriptions by creating one role assignment inherited by other subscriptions.||Monitor and audit role and policy assignments, across subscriptions.||Things to know about management groups|As you plan the governance strategy for Tailwind Traders, consider these characteristics of management groups:||Management groups can be used to aggregate policy and initiative assignments via Azure Policy.||A management group tree can support up to six levels of depth. This limit doesn't include the tenant root level or the subscription level.||Azure role-based access control authorization for management group operations isn't enabled by default.||By default, all new subscriptions are placed under the root management group.||Things to consider when creating management groups|Tailwind Traders has Sales, Corporate, and Information Technology (IT) departments. The Sales department manages offices in the West and in the East. The Corporate main office includes Human Resources (HR) and Legal. The IT department handles research, development, and production. There are currently two applications hosted in Azure.||Here's a proposed management group hierarchy for your organization:||||Design management groups with governance in mind. Use Azure policies at the management group level for all workloads that require the same security, compliance, connectivity, and feature settings.||Keep the management group hierarchy reasonably flat. Plan the Tailwind Traders hierarchy to have no more than three or four levels of management groups. A flat hierarchy may not provide flexibility and complexity for large organizations. A hierarchy with too many levels can be difficult to manage.||Consider a top-level management group. Implement a top-level management group to support common platform policy and Azure role assignments across the entire organization. A Tailwind Traders management group can be a top-level management group for all organizational-wide policies.||Consider an organizational or departmental structure. Design your management groups based on the organizational structure, to make it easy to understand. Separate the management groups for each Tailwind Traders department like Sales, Corporate, and IT.||Consider a geographical structure. Build your management groups by using a geographical structure to allow for compliance policies in different regions. Allocate unique management groups for governance in the West and East sales regions for Tailwind Traders.||Consider a production management group. Institute a production management group to create policies that apply to all corporate products. A production management group for Tailwind Traders can provide product-specific policies for corporate applications.||Consider a sandbox management group. Offer a sandbox management group for users to experiment with Azure. The sandbox provides isolation from your development, test, and production environments. Users can experiment with resources that might not yet be allowed in official Tailwind Traders production environments.||Consider isolating sensitive information in a separate management group. Secure sensitive data by using a corporate management group for Tailwind Traders. The separate management group provides both standard and enhanced compliance policies for the main office.|Design for subscriptions|Completed|100 XP|3 minutes|Azure Subscriptions are logical containers that serve as units of management and scale and billing boundaries. Limits and quotas can be applied, and each organization can use subscriptions to manage costs and resources by group.​||Things to know about subscriptions|To use Azure, you must have an Azure subscription. A subscription provides you with a logical container to create and pay for Azure products and services. There are several types of subscriptions, such as Enterprise Agreement and Pay-as-You-Go.||Diagram of Microsoft Entra ID showing the subscription types - dev, test, and production.||As you plan the governance strategy for Tailwind Traders, consider these characteristics of subscriptions:||Subscriptions can provide separate billing environments, such as development, test, and production.||Policies for individual subscriptions can help satisfy different compliance standards.||You can organize specialized workloads to scale beyond the limits of an existing subscription.||By using subscriptions, you can manage and track costs for your organizational structure.||Things to consider when creating subscriptions|You defined your strategy for the Tailwind Traders management group structure. Now you need to determine where to assign subscriptions. Here's one possible solution:||Diagram that shows subscription options for Tailwind Traders departments, such as sales, corporate, and IT.||Treat subscriptions as a democratized unit of management. Align your subscriptions to meet specific Tailwind Traders business needs and priorities.||Group subscriptions together under management groups. Group together subscriptions that have the same set of policies and Azure role assignments to inherit these settings from the same management group. For Tailwind Traders, both the West and East subscriptions can inherit policy settings from the Sales management group.||Consider a dedicated shared services subscription. Use a shared services subscription to ensure all common network resources are billed together and isolated from other workloads. Examples of shared services subscriptions include Azure ExpressRoute and Virtual WAN.||Consider subscription scale limits. Subscriptions serve as a scale unit for component workloads. Large, specialized workloads like high-performance computing, IoT, and SAP are all better suited to use separate subscriptions. By having separate subscriptions for different Tailwind Traders groups or tasks, you can avoid resource limits (such as a limit of 50 Azure Data Factory integrations).||Consider administrative management. Subscriptions provide a management boundary, which allows for a clear separation of concerns. Will each subscription for Tailwind Traders need a separate administrator, or can you combine subscriptions? The Corporate management group could have a single subscription for both the HR and Legal departments.||Consider how to assign Azure policies. Both management groups and subscriptions serve as a boundary for the assignment of Azure policies. Workloads like those for the Payment Card Industry (PCI) typically require extra policies to achieve compliance. Rather than using a management group to group workloads that require PCI compliance, you can achieve the same isolation with a subscription. These types of decisions ensure you don't have too many Tailwind Traders management groups with only a few subscriptions.||Consider network topologies. Virtual networks can't be shared across subscriptions. Resources can connect across subscriptions with different technologies, such as virtual network peering or Virtual Private Networks (VPNs). Consider which Tailwind Traders workloads must communicate with each other when you decide if a new subscription is required.||Consider making subscription owners aware of their roles and responsibilities. Conduct a quarterly or biannual access review by using Microsoft Entra Privileged Identity Management. Access reviews ensure privileges don't proliferate as users move within the Tailwind Traders customer organization.|| Note||When it comes to subscriptions, one size doesn't fit all. A solution that works for one business unit might not be suitable for another. Explore your options.|Design for resource groups|Completed|100 XP|4 minutes|Resource groups are logical containers into which Azure resources are deployed and managed. These resources can include web apps, databases, and storage accounts. You can use resource groups to:||Place resources of similar usage, type, or location in logical groups.||Organize resources by life cycle so all the resources can be created or deleted at the same time.||Apply role permissions to a group of resources or give a group access to administer a group of resources.||Use resource locks to protect individual resources from deletion or change.||Things to know about resource groups|As you plan the governance strategy for Tailwind Traders, consider these characteristics of resource groups:||Resource groups have their own location (region) assigned. This region is where the metadata is stored.||If the resource group's region is temporarily unavailable, you can't update resources in the resource group because the metadata is unavailable. The resources in other regions still function as expected, but you can't update them.||Resources in the resource group can be in different regions.||A resource can connect to resources in other resource groups. You can have a web application that connects to a database in a different resource group.||Resources can be moved between resource groups with some exceptions.||You can add a resource to or remove a resource from a resource group at any time.||Resource groups can't be nested.||Each resource must be in one, and only one, resource group.||Resource groups can't be renamed.||Things to consider when creating resource groups|Tailwind Traders has two Azure-based applications (App1 and App2). Each application has a web service with SQL database, virtual machines, and storage. You need to decide how to organize the resource groups for Tailwind Traders.||||Consider group by type. Group resources by type for on-demand services that aren't associated with an app. For Tailwind Traders, you can have a resource group for the SQL databases (SQL-RG) and a separate resource group (WEB-RG) for the web services.||||Consider group by app. Group resources by app when all resources have the same policies and life cycle. This method can also be applied to test or prototype environments. For Tailwind Traders, App1 and App2 can have separate resource groups. Each group can have all the resources for the specific application.||||Consider group by department, group by location (region), and group by billing (cost center). Review other grouping strategies that aren't common but might be useful in your situation.||Consider a combination of organizational strategies. Don't restrict your Tailwind Traders strategy to using only a single resource group option. A combination of options is best.||Consider resource life cycle. Design your resource groups according to life cycle requirements. Do you want to deploy, update, and delete certain resources at the same time? If so, place these resources in the same resource group.||Consider administration overhead. Include overhead planning in your strategy. How many resource groups would you like to manage? Does Tailwind Traders use centralized or decentralized Azure administrators?||Consider resource access control. Implement access control for your resource groups. At the resource group level, you can assign Azure policies, Azure roles, and resource locks. Resource locks prevent unexpected changes to critical resources.||Consider compliance requirements. Plan to build in support for compliance in your Tailwind Traders strategy. Do you need to ensure your resource group metadata is stored in a particular region?||Design for resource tags|Completed|100 XP|4 minutes|Resource tags are another way to organize resources. Tags provide extra information, or metadata, about your resources.|| Tip||Before you start a resource tagging project, ask yourself what you want to accomplish. Will reporting or billing use tags? Can you use the tags to enable more effective searching for Tailwind Traders? Will automated scripts use tags? Be sure to clearly define your goals.||Things to know about resource tags|As you plan the governance strategy for Tailwind Traders, consider these characteristics of resource tags:||A resource tag consists of a name-value pair. For example, env = production or env = dev, test.||You can assign one or more tags to each Azure resource, resource group, or subscription.||Resource tags can be added, modified, and deleted. These actions can be done with PowerShell, the Azure CLI, Azure Resource Manager (ARM) templates, the REST API, or the Azure portal.||Tags can be applied to a resource group. However, tags applied to a resource group aren't inherited by the resources in the group.||Things to consider when creating resource tags|You created the organizational hierarchy for Tailwind Traders. Now you need to determine which resource tags to apply.||Diagram that shows an example hierarchy of resource tags.||Consider your organization's taxonomy. Align your resource tags with accepted department nomenclature to make it easier to understand. Are there recognized terms for compliance or cost reporting for the Tailwind Traders organization? Add tags for office locations, confidentiality levels, or other defined policies.||Consider whether you need IT-aligned or business-aligned tagging. Implement IT-aligned tagging or business-aligned tagging, or a combination of these approaches to be most effective.|| Tip||Many organizations are shifting from IT-aligned to business-aligned tagging strategies.||The following table describes the tagging options in detail.||Alignment	Description	Example scenarios|IT-aligned	The IT-aligned option is useful for tracking workload, application, function, or environment criteria. This option can reduce the complexity of monitoring assets. IT-aligned tagging simplifies making management decisions based on operational requirements.	Tailwind Traders printers are busy 80% of the time. We have five high-speed color printers and should buy more. Use IT-aligned tagging to support printer resource workload and function.|Business-aligned	The Business-aligned option helps to focus on accounting, business ownership, cost responsibility, and business criticality. This option provides improved accounting for costs and value of IT assets to the overall business. You can use Business-aligned tagging to shift the focus from an asset's operational cost to an asset's business value.	The Tailwind Traders Marketing department's promotional literature increased sales revenue 10%. We should invest in more printing capabilities. Use Business-aligned tagging to support marketing resource ownership, accounting, and cost.|Consider the type of tagging required. Plan to use different types of resource tags to support the Tailwind Traders organization. Resource tags generally fall into five categories: functional, classification, accounting, partnership, and purpose.||Tag type	Description	Example name-value pairs|Functional	Functional tags categorize resources according to their purpose within a workload. This tag shows the deployed environment for a resource, or other functionality and operational details.	- app = catalogsearch1|- tier = web|- webserver = apache|- env = production, dev, staging|Classification	Classification tags identify a resource by how it's used and what policies apply to it.	- confidentiality = private|- SLA = 24hours|Accounting	Accounting tags allow a resource to be associated with specific groups within an organization for billing purposes.	- department = finance|- program = business-initiative|- region = northamerica|Partnership	Partnership tags provide information about the people (other than IT members) who are associated with a resource, or otherwise affected by the resource.	- owner = jsmith|- contactalias = catsearchowners|- stakeholders = user1;user2;user3|Purpose	Purpose tags align resources to business functions to better support investment decisions.	- businessprocess = support|- businessimpact = moderate|- revenueimpact = high|Consider starting with a few tags and then scale out. The resource tagging approach you choose can be simple or complex. Rather than identify all the possible tags required by the Tailwind Traders organization, prototype with just a few important or critical tags. Determine how effective the tagging scheme is before you add more resource tags.||Consider using Azure policy to apply tags and enforce tagging rules and conventions. Resource tagging is only effective if used consistently across an organization. You can use Azure policy to require that certain tags be added to new resources as they're created. You can also define rules that reapply tags when deleted.||Consider which resources require tagging. Keep in mind that you don't need to enforce that a specific tag is present on all Tailwind Traders resources. You might decide that only mission-critical resources have the Impact tag. All nontagged resources would then not be considered as mission critical.|| Note||To implement an effective resource tagging structure, be sure to seek input from the different stakeholders in your organization.|Design for Azure Policy|Completed|100 XP|4 minutes|Azure Policy is a service in Azure that enables you to create, assign, and manage policies to control or audit your resources. These policies enforce different rules over your resource configurations so the configurations stay compliant with corporate standards.||Things to know about Azure Policy|As you plan the governance strategy for Tailwind Traders, consider these characteristics of Azure Policy:||Azure Policy lets you define both individual policies and groups of related policies, called initiatives. Azure Policy comes with many built-in policy and initiative definitions.||Azure policies are inherited down the hierarchy.||You can scope and enforce Azure policies at different levels in the organizational hierarchy.||Azure Policy evaluates all resources in Azure and Arc-enabled resources (specific resource types that are hosted outside of Azure).||Azure Policy highlights resources that aren't compliant with the current policies.||Use Azure Policy to prevent noncompliant resources from being created, and automatically remediate noncompliant resources.||Azure Policy integrates with Azure DevOps by applying predeployment and post-deployment policies.||Things to consider when using Azure Policy|You're ready to consider how to apply Azure Policy settings to your Tailwind Traders applications. You'll probably apply some policies at the Production management group level. Other policies can be assigned at the application level.||Diagram that shows different Azure policies applied at the Production and Application resource group levels.||Consider using the Azure Policy compliance dashboard. Use the Azure Policy compliance dashboard to analyze the overall state of the environment. The dashboard offers an aggregated view where you can drill down to see Tailwind Traders policies for each resource and level. The tool provides bulk remediation for existing resources and automatic remediation for new resources, to resolve issues rapidly and effectively.||Consider when Azure Policy evaluates resources. Plan for how Azure Policy evaluates your Tailwind Traders resources at specific times. Understand when and how evaluations are triggered. There might be a delay in identifying non-compliant resources. The following events or times trigger an evaluation:||A resource is created, deleted, or updated in scope with a policy assignment.||A policy or an initiative is newly assigned to a scope.||An assigned policy or initiative for a scope is updated.||The standard compliance evaluation cycle (occurs once every 24 hours).||Consider how to handle a noncompliant resource. Determine how you're going to handle noncompliant resources for Tailwind Traders. An organization can have a different way of handling noncompliance depending on the resource. Here are some examples:||Deny changes to the resource.||Log changes to the resource.||Alter the resource before or after the change.||Deploy related compliant resources.||Consider when to automatically remediate noncompliant resources. Decide if you want Azure Policy to do automatic remediation for noncompliant resources. Remediation is especially useful in resource tagging. Azure Policy can tag resources and reapply tags that are removed. You can use Azure Policy to ensure all resources in a certain resource group are tagged with a specific tag like Location to identify the region.||Consider how Azure Policy is different from role-based access control (RBAC). It's important to understand that Azure Policy and Azure RBAC are different. For your Tailwind Traders strategy, Azure RBAC and Azure Policy should be used together to achieve full scope control.||You use Azure Policy to ensure the resource state is compliant with the organization's business rules. Compliance doesn't depend on who made the change or who has permission to make changes. Azure Policy evaluates the state of a resource, and acts to ensure the resource stays compliant.||You implement Azure RBAC to focus on user actions at different scopes. Azure RBAC manages who can access Azure resources, what they can do with those resources, and what areas they can access. If actions need to be controlled, use Azure RBAC. If a user has access to complete an action, but the result is a noncompliant resource, Azure Policy still blocks the action.||Control resource access|After you determine your identity management solution for Tailwind Traders, it's time to think about resource access. What resources should these identities be able to access? How will you enforce that access? How will you monitor and review the access?||A user's identity goes through several phases. Initially, the user has no access. Access can be granted through RBAC and verified with Microsoft Entra Conditional Access. Microsoft Entra ID Protection can be used to monitor the user's access. Periodically, Microsoft Entra access reviews confirm the access is still required.||Design for role-based access control (RBAC)|Completed|100 XP|4 minutes|Azure RBAC allows you to grant access to Azure resources that you control. Azure RBAC evaluates each request for access and determines if access should be blocked, not allowed, or allowed.||Diagram of an RBAC decision tree that shows the flow from no access to access allowed.||RBAC is an allow model. An allow model means when a user is assigned a specific role, Azure RBAC allows the user to perform the actions associated with that role. A role assignment could grant a user read permissions to a resource group. To have write permissions, the role would need to explicitly allow write access.||Things to know about Azure RBAC|Suppose you need to manage access to resources in Azure for Tailwind Traders Development, Engineering, and Marketing teams. Here are some scenarios you can implement with Azure RBAC:||Allow one user to manage virtual machines in a subscription, and allow another user to manage virtual networks.||Allow members of a database administrator group to manage SQL databases in a subscription.||Allow a user to manage all resources in a resource group, such as virtual machines, websites, and subnets.||Allow an application to access all resources in a resource group.||Things to consider when using Azure RBAC|You have a plan for how to apply Azure Policy settings to your Tailwind Traders applications. Now consider how to integrate Azure RBAC to control user privileges and resource access.||Consider the highest scope level for each requirement. Your first step is to accurately define each role definition and its permissions. Next, assign the roles to specific users, groups, and service principles. Lastly, scope the roles to management groups, subscriptions, resource groups, and resources. Assign each role at the highest scope level that meets the requirements.||Diagram that shows how a role definition is assigned to a resource and then scoped.||Consider the access needs for each user. As you plan your access control strategy, it's a best practice to grant users the least privilege they need to get their work done. This method makes it easier to separate team member responsibilities. By limiting roles and scopes, you limit what resources are at risk if a security principle is ever compromised. You can create a diagram like the following example to help plan your Azure RBAC roles for Tailwind Traders.||Diagram that shows how to plan roles of different scope levels within the organization.||Consider assigning roles to groups, and not users. To make role assignments more manageable, avoid assigning roles directly to users. Instead, assign roles to groups. Assigning roles to groups helps minimize the number of role assignments.||Consider when to use Azure policies. Azure policies are used to focus on resource properties. During deployment, an Azure policy can be used to ensure users can deploy only certain virtual machines in a resource group. By using a combination of Azure policies and Azure RBAC, you can provide effective access control in your Tailwind Traders solution. The following table compares these access models.||Azure Policy	Azure RBAC|Description	Defined policies to ensure resources are compliant with a set of rules.	Authorization system that provides fine-grained access controls.|Main focus	Focused on the properties of resources.	Focused on what resources users can access.|Implementation	Specify a set of rules.	Assign roles and scopes.|Default access	By default, policy rules are set to allow.	By default, all access for all users is denied.|Consider when to create a custom role. Sometimes, the built-in roles don't grant the precise level of access you need. Custom roles allow you to define roles that meet the specific needs of your organization. Custom roles can be shared between subscriptions that trust the same Microsoft Entra ID.||Consider how to resolve overlapping role assignments. Azure RBAC is an additive model, so your effective permissions are the sum of your role assignments. Consider a user is granted the Contributor role at the subscription scope and the Reader role on a resource group. The sum of the Contributor permissions and the Reader permissions is effectively the Contributor role for the subscription. Therefore, in this case, the Reader role assignment has no impact.||Design for Azure landing zones|Completed|100 XP|3 minutes|An Azure landing zone provides an infrastructure environment for hosting your workloads. Landing zones ensure key foundational principles are put in place before you deploy services.||To use an analogy, shared city utilities like water, gas, and electricity are available to new homes before they're built. In the same manner, the network, identity and access management, policies, and monitoring configuration for landing zones must be ready before you try to deploy. These "utilities" for landing zones need to be active and ready to help streamline the application migration process.||Things to know about Azure landing zones|As you plan the governance strategy for Tailwind Traders, consider these characteristics of Azure landing zones:||Landing zones are defined by management groups and subscriptions that are designed to scale according to business needs and priorities.||The following diagram shows landing zones for SAP, Corporate, and Online applications.||Diagram of a management group and subscription organization that uses landing zones.||Azure policies are associated with landing zones to ensure continued compliance with the organization platform.||Landing zones are pre-provisioned through code.||A landing zone can be scoped to support application migrations and development to scale across the organization's full IT portfolio.||The Azure landing zone accelerator can be deployed into the same Microsoft Entra tenant for an existing Azure architecture. The accelerator is an Azure-portal-based deployment.||Things to consider when using Azure landing zones|You're ready to finalize your governance strategy for Tailwind Traders. Consider how you can use Azure landing zones to scale your design:||Consider including landing zones in your design. Include landing zones in your overall Azure infrastructure design. You can use subscriptions as a unit of management and scale aligned with business needs and priorities. Apply Azure Policy to provide guardrails and ensure continued compliance with your organization's platform, along with the applications that are deployed onto it.||Consider creating landing zones through code. Implement landing zones that are pre-provisioned through code. As your situation changes, you should expect to refactor the code. Use an iterative approach that maximizes learning opportunities and minimizes time to business success. You can minimize refactoring by having a central IT team to review both short term and long-term scenarios.||Consider using the Azure landing zone accelerator. Use the accelerator to provide a full implementation of the conceptual architecture, along with opinionated configurations for key components like management groups and policies.||Consider focusing on your applications. Focus on application-centric migrations and development rather than pure infrastructure lift-and-shift migrations, such as moving virtual machines.||Consider Azure-native design and aligning with the platform. Favor using Azure-native platform services and capabilities, when possible. It's crucial to align with the Azure platform roadmap to ensure that new capabilities are made available within customer environments.||Consider scoping for both migrations and green field situations. Scope the landing zone to support application migrations and green field development at scale in Azure. This expansion allows for a design that can scale across your organization's complete IT portfolio, which looks well beyond a short-term cloud-adoption plan.||Consider transitioning existing architectures to Azure landing zones. Take advantage of landing zones for existing Azure architecture. Deploy the Azure landing zone accelerator into the same Microsoft Entra tenant in parallel with the current environment. You can create a new management group structure and ensure that the existing environment isn't affected by these changes.|| Note||It's recommended to conduct an Azure landing zone review, to host workloads that you plan to build in or migrate to the cloud. This assessment is designed for customers with two or more years of experience. If you're new to Azure, this assessment helps you identify investment areas for your adoption strategy.||Knowledge check|Completed|200 XP|4 minutes|Tailwind Traders is planning on making some significant changes to their governance solution. They would like your assistance with recommendations and questions. Here are the specific requirements:||Consistency across subscriptions. It appears each subscription has different policies for the creation of virtual machines. The IT department would like to standardize the policies across the Azure subscriptions.|Ensure critical storage is highly available. There are several critical applications that use storage. The IT department wants to ensure the storage is made highly available across regions.|Identify research and development costs. The CFO wants to know the cost estimates for a new project. The costs are spread out across multiple departments.|ISO compliance. Tailwind Traders wants to certify that it complies with the ISO 27001 standard. The standard requires resource groups, policy assignments, and templates.|Answer the following questions|Choose the best response for each of the questions. Then select Check your answers.|||1. How can Tailwind Traders ensure policies are implemented across multiple subscriptions? ||Add a resource tag that includes the required policy.|Incorrect. Resource tagging provides extra information, or metadata, about your resources, but doesn't impact policy implementation.|||Create a management group and place all the relevant subscriptions in the new management group.|Correct. A management group could include all the subscriptions. Then a policy could be scoped to the management group and applied to all the subscriptions.|||Add a resource group and place all the relevant subscriptions in it.|2. How can Tailwind Traders ensure applications use geo-redundancy to create highly available storage applications? ||Add a resource tag to each storage account for geo-redundant storage.||Add a geo-redundant resource group to contain all the storage accounts.||Add an Azure policy that requires geo-redundant storage.|Correct. An Azure policy can enforce different rules over your resource configurations.||3. How can Tailwind Traders report all the costs associated with a new product? ||Add a resource tag to identify which resources are used for the new product.|Correct. Resource tagging provides extra information, or metadata, about your resources. You could then run a cost report on all resources with that tag.|||Add a resource group and move all product assets into the group.||Add a spreadsheet and require each department to log their costs.||Summary and resources|In this module, you learned how to design with governance in mind. You discovered different strategies for implementing an organizational hierarchy, and enforcing rules and policies. You reviewed options for designing governance that uses management groups, resource groups, and resource tagging with Azure Policy settings on Azure subscriptions. You explored the advantages to deploying with Azure Blueprints and Azure landing zones.||Learn more with Azure documentation|Read about governance in the Microsoft Cloud Adoption Framework for Azure.|Organize resources with management groups in Azure Governance.|Organize and manage Azure subscriptions with Microsoft Cloud Adoption Framework.|Plan how to name resources and tags with Microsoft Cloud Adoption Framework.|Review recommended policies for Azure services from Azure Policy.|Learn more with self-paced training|Build a cloud governance strategy on Azure.|Describe core Azure architectural components.|Explore Microsoft Cloud Adoption Framework for Azure.|Secure your Azure resources with Azure RBAC.|Learn about enterprise-scale landing zones in the Microsoft Cloud Adoption Framework for Azure.|Choose the best Azure landing zone to support your requirements for cloud operations.|Learn more with optional hands-on exercises|Learn how to configure list access by using Azure RBAC and the Azure portal.]}
{"category":"Design business continuity solutions":[Azure Architects design solutions to back up and recover their data to avoid costly business interruptions. Microsoft Azure provides an end-to-end backup and disaster recovery solution to support multiple scenarios. It's easy to implement, secure, scalable, and cost-effective.||Meet Tailwind Traders|||Tailwind Traders is a fictitious home improvement retailer. The company currently manages on-premises data centers to host their retail website. The data centers also store all the data and streaming video for the web applications.||The IT department performs all management tasks for the computing hardware and software. They handle the procurement process to buy new hardware, install and configure software, and deploy everything throughout the data center. These management responsibilities create some obstacles for delivering applications to Tailwind Traders' users and customers in a timely fashion. So, the company is shifting on-premises workloads to the cloud.||You're responsible for selecting appropriate backup solutions for migrated workloads. You also need to select an appropriate disaster recovery option for these workloads.||Learning objectives|In this module, you learn how to:||Design for backup and recovery.||Design for Azure Backup.||Design for Azure Blob Storage backup and recovery.||Design for Azure Files backup and recovery.||Design for Azure Virtual Machines backup and recovery.||Design for Azure SQL backup and recovery||Design for Azure Site Recovery.||Skills measured|The content in the module helps you prepare for Exam AZ-305: Designing Microsoft Azure Infrastructure Solutions. The module covers the following course concept requirements:||Design business continuity solutions||Design a solution for backup and disaster recovery|Prerequisites|Conceptual knowledge of business continuity and disaster recovery solutions.||Working experience with object replication, backup solution tools, and recovery options.Design for backup and recovery|Completed|100 XP|3 minutes|Organizations, such as Tailwind Traders, require a high degree of reliability from their mission-critical apps. To achieve the desired reliability for on-premises based apps, it's typical to purchase more computing resource, such as servers and storage. Purchasing more computing resources builds redundancy into an on-premises infrastructure.||It's also vital that any mission-critical app, and its associated data, is recoverable following a failure-ideally to the point of failure. This recoverability is often provided by backup, restore components, and procedures. For organizations with apps hosted in Azure, or organizations with hybrid app deployments, there are other considerations and options.||Reliable apps are:||Resilient to component failure.||Highly available and can run in a healthy state with no significant downtime.||To achieve the desired resilience and high availability, you must first define your requirements.|| Note||This module will use the term resiliency as the ability of a system to gracefully handle and recover from failures, both inadvertent and malicious.||Define your requirements|Defining your requirements involves:||Identifying your business needs.||Building your resiliency plan to address those needs.||Use the following table of considerations to provide guidance on this process.||Consideration	Description|What are your workloads and their usage?	A workload is a distinct capability or task that is logically separated from other tasks, in terms of business logic and data storage requirements. Each workload probably has different requirements for availability, scalability, data consistency, and disaster recovery.|What are the usage patterns for your workloads?	Usage patterns can determine your requirements. Identify differences in requirements during both critical and noncritical periods. To ensure uptime, plan redundancy across several regions in case one region fails. Conversely, to minimize costs during noncritical periods, you can run your application in a single region.|What are the availability metrics?	Mean time to recovery (MTTR) and mean time between failures (MTBF) are the typically used metrics. MTBF is how long a component can reasonably expect to last between outages. MTTR is the average time it takes to restore a component after a failure. Use these metrics to determine where you need to add redundancy, and to determine service-level agreements (SLAs) for customers.|What are the recovery metrics?	The recovery time objective (RTO) is the maximum acceptable time one of your apps can be unavailable following an incident. The recovery point objective (RPO) is the maximum duration of data loss that is acceptable during a disaster. Also consider the recovery level objective (RLO). This metric determines the granularity of recovery. In other words, whether you must be able to recover a server farm, a web app, a site, or just a specific item. To determine these values, conduct a risk assessment. Ensure that you understand the cost and risk of downtime or data loss in your organization.|What are the workload availability targets?	To help ensure that your app architecture meets your business requirements, define target SLAs for each workload. Account for the cost and complexity of meeting availability requirements, in addition to application dependencies.|What are your SLAs?	In Azure, the SLA describes the Microsoft commitments for uptime and connectivity. If the SLA for a particular service is 99.9 percent, you should expect the service to be available 99.9 percent of the time.| Tip||If the MTTR of any critical component in a highly available scenario exceeds the system RTO, then a failure in the system might cause an unacceptable business disruption. In other words, you can't restore the system within the defined RTO.||Define your own target SLAs for each workload in your solution by answering the preceding questions. This helps ensure that the architecture meets your business requirements. For example, if a workload requires 99.99 percent uptime, but depends on a service with a 99.9 percent SLA, that service can't be a single point of failure in the system.||After defining your recovery requirements, you can select a suitable recovery technology.Design for Azure Backup|Completed|100 XP|3 minutes|Azure Backup uses Azure resources for short-term and long-term storage. Azure Backup minimizes or even eliminates the need for maintaining physical backup media. Some examples of backup media include tapes, hard drives, and DVDs.||Diagram that shows the Azure Backup service with on-premises and cloud agents.||Things to know about Azure Backup|Azure Backup offers multiple components that you can download and deploy on the appropriate computer, server, or in the cloud. The component (or agent) that you deploy depends on what you want to protect. The following table summarizes the types of backup you can perform with Azure Backup.||Backup type	Description|On-premises	Back up files, folders, and system state with the Microsoft Azure Recovery Services (MARS) agent. You can also use System Center Data Protection Manager (DPM) or the Microsoft Azure Backup Server (MABS) agent to protect on-premises virtual machines (both Hyper-V and VMware) and other on-premises workloads.|Azure Virtual Machines	Back up entire Windows or Linux virtual machines (by using backup extensions), or back up files, folders, and system state with the MARS agent.|Azure Files	Back up Azure file shares to a storage account.|SQL Server in Azure virtual machines	Back up SQL Server databases running on Azure virtual machines.|SAP HANA databases in Azure virtual machines	Back up SAP HANA databases running on Azure virtual machines.|Microsoft cloud	Azure Backup can replace your existing on-premises or off-site backup solution with a cloud-based solution that's reliable, secure, and cost-competitive.|Azure Backup storage vaults|Azure Backup organizes your backup data in a storage entity called a vault. A storage vault stores backup copies, recovery points, and backup policies. There are two types of vaults: Azure Backup and Azure Recovery Services. The primary differences are the types of supported data sources and Azure products.||Azure Backup vault: Azure Backup vaults are used with Azure Backup only. Supported data sources include Azure Database for PostgreSQL servers, Azure blobs, and Azure disks.||Azure Recovery Services vault: Azure Recovery Services vaults can be used with Azure Backup or Azure Site Recovery. Supported data sources include Azure virtual machines, SQL or SAP HANA in an Azure virtual machine, and Azure file shares. You can back up data to a Recovery Services vault from Azure Backup Server, Azure Backup Agent, and System Center Data Protection Manager.||Things to consider when using storage vaults|In your planning for Azure Backup and vault storage, consider the following points. Think about how you can use Azure Backup and storage vaults to support the Tailwind Traders BCDR requirements.||Consider vault organization. Think about how you want to organize your storage vaults. If all your workloads are managed from a single subscription and single resource, you can use a single vault. If your workloads are spread across subscriptions, you can create multiple vaults. Use separate vaults for Azure Backup and Azure Site Recovery.||Consider Azure Policy. For consistent policy settings across all your vaults, use Azure Policy to propagate your backup policy across multiple vaults. A backup policy is scoped to a vault.||Consider role-based protection. Protect your vaults by using Azure role-based access control (RBAC). You can secure your vaults and manage access with role-based access.||Consider redundancy. Specify how data in your vault is replicated for redundancy.||Use locally redundant storage (LRS) to protect against failure in a datacenter. LRS replicates data to a storage scale unit.|Use geo-redundant storage (GRS) to protect against region-wide outages. GRS replicates your data to a secondary region.Design for Azure blob backup and recovery|Completed|100 XP|3 minutes|Azure Backup provides operational backup for Azure blobs, which is a local backup solution for Azure Blob Storage. In this backup method, your backup data is stored in your source Azure storage account rather than being transferred to an Azure Backup storage vault.||Things to know about Azure Blob Storage backup and recovery|Here are some of the prominent features available for backup and recovery of Azure Blob Storages.||Operational backup for Azure blobs provides you with a continuous backup solution. You don't need to schedule any backups.||All changes in an operational blob backup are retained for a specified period of time, and restorable from a selected point in time.||The soft delete feature lets you protect your data from accidental deletion or corruption. During the retention period, you can restore a soft-deleted blob object to its state at the time it was deleted. Soft delete is available for blobs and containers.||The retention period for deleted blobs or containers can be specified between 1 and 365 days. The default period is seven days.||The operational backup solution supports blob versioning. You can restore an earlier version of a blob, or recover your data after incorrect modification or deletion.||The point-in-time restore feature for block blobs lets you protect against accidental deletion or corruption. During the retention period, you can restore block blobs from the present state to a state at a previous time.||The resource lock feature prevents resources from being accidentally deleted or changed. You can set the resource lock to prohibit deletion or allow reading only.||Let's examine some of these features in more detail. As you review these options, consider which features can benefit the Tailwind Traders solution.||Things to consider when using soft delete and versioning|You can implement the soft delete feature to protect an individual blob, snapshot, container, or blob version from accidental deletes or overwrites. Soft delete maintains the deleted data in the system for your specified retention period. During the retention period, you can restore a soft-deleted object to its state at the time it was deleted.||The following diagram shows a high-level view of the soft delete feature for containers and blobs, and blob versions.||Image that shows a high-level view of the soft delete feature as described in the text.||There are different options for implementing soft delete and blob versioning:||Implement blob soft delete to restore a specific deleted file, such as a blob, snapshot, or blob version.||Use container soft delete to restore a container and its contents.|| Note||Container soft delete doesn't protect against the deletion of a storage account, but only against the deletion of containers in a storage account.||Add blob versioning to automatically maintain previous versions of a blob. You can restore an earlier version of a blob, or use the feature to recover your data. Blob versioning is useful when you have multiple authors editing the same files. Implement blob versioning to maintain or restore individual changes from each author.||Things to consider when using point-in-time restore|Like soft delete, point-in-time restore for block blobs also protects against accidental deletion or corruption. Create a management policy for the source storage account and specify your retention period. During the retention period, you can restore block blobs from the present state to a state at a previous time. Point-in-time restore lets you test scenarios that require reverting a data set to a known state before you run further tests.||The following diagram shows how point-in-time restore works. One or more containers or blob ranges is restored to its previous state. The result of the process is to revert write and delete operations that occurred during the retention period.||Image that shows how point-in-time restore works as described in the text.||Things to consider when using resource locks|You can protect your data and avoid accidental changes by using resource locks. This feature prevents resources from being accidentally deleted or changed. There are two lock levels: CanNotDelete and ReadOnly.||CanNotDelete permits authorized users to read and modify a resource, but they can't delete the resource without first removing the lock.||ReadOnly allows authorized users to read a resource, but they can't delete or change the resource. Applying this lock is like restricting all authorized users to the permissions granted by the Reader role in Azure RBAC.Design for Azure files backup and recovery|Completed|100 XP|3 minutes|Azure Files provides the capability to take share snapshots of file shares. Share snapshots give you an extra level of security, and help reduce the risk of data corruption or accidental deletion. You can also use share snapshots as a general backup for disaster recovery.||Diagram of Azure file shares snapshots stored in a Recovery Services vault.||Things to know about Azure File share backup and recovery|Let's review some of the characteristics regarding backup and recovery of Azure file shares.||Share snapshots capture the share state at that specific point in time.||Snapshots can be created manually by using the Azure portal, REST API, client libraries, the Azure CLI, and PowerShell.||Snapshots can be automated by using Azure Backup and backup policies.||Snapshots are at the root level of a file share and apply to all the folders and files contained in the share. Retrieval is provided at the individual file level.||Snapshots are incremental. Only the deltas between your snapshots are stored.||After a share snapshot is created, it can be read, copied, or deleted, but it can't be modified.||You can't delete a share that has share snapshots. To delete the share, you must delete all the share snapshots.|| Important||Snapshots aren't a replacement for cloud-side backups.||Automated file share backups|You can automate and manage your Azure file shares snapshots. Automating snapshot backups with Azure Backup is the recommended approach. The following diagram shows how automatic backups of file shares can be restored from a Recovery Services vault.||Diagram that shows how Azure file shares snapshots are restored from a Recovery Services vault in Azure Backup.||Azure Backup keeps the metadata about the snapshot backup in the Recovery Services vault, but no data is transferred. This method provides you with a fast backup solution that has built-in backup and reporting.||When Azure Backup is enabled on the file share, the soft delete feature is also enabled.||You can configure snapshot backups for daily, weekly, monthly, or yearly retention.||Things to consider when using file share backups|Take a moment to review some considerations for creating and recovering from file share backups. Think about how you can use this approach to support the Tailwind Traders BCDR requirements.||Consider instant restore. Azure file share backup uses file share snapshots. You can select just the files you want to restore instantly.||Consider alerts and reporting. You can configure alerts for backup and restore failures and use the reporting solution provided by Azure Backup. These reports provide insights on file share backups.||Consider self-service restore. Azure Backup uses server endpoint Windows Volume Shadow Copy Service (VSS) snapshots. You might consider giving advanced users the ability to restore files themselves.||Consider on-demand backups. Azure Backup policies are limited to scheduling a backup once a day. If a user creates a file in the morning and works on it all day, a nightly backup doesn't include the new file. For these reasons, consider on-demand backups for the most critical file shares.||Consider file share organization. Organize your file shares according to how you intend to store the data in backups. You might separate your file shares for backup according to public facing data versus internal file shares.||Consider code deployments. If a bug or application error is introduced with the new deployment, you can go back to a previous version of your data on that file share. To help protect against these scenarios, you can take a share snapshot before you deploy new application code.Design for Azure virtual machine backup and recovery|Completed|100 XP|3 minutes|Azure Backup provides independent and isolated backups for Azure virtual machines. You can use Azure Backup to take snapshot backups and restore the data on your virtual machines if there's data corruption or accidental deletion.||Things to know about virtual machine backup and recovery|Let's examine how Azure Backup supports backup and recovery of Azure virtual machines.||Azure Backup allows for simple configuration and scaling for Windows and Linux virtual machines.|| Note||Azure Backup has specialized offerings for database workloads like SQL Server and SAP HANA. These offerings are workload-aware, provide 15-minute RPO (recovery point objective), and allow back up and restore of individual databases.||The backup job for a virtual machine involves two phases:||First, a virtual machine snapshot is taken.|Second, the virtual machine snapshot is transferred to a Recovery Services vault.|The transfer of the backup data to the Recovery Services vault has no effect on your production workloads.||Azure virtual machine backups stored in a Recovery Services vault provide built-in management of recovery points.||Virtual machine backups are optimized so you can easily restore a full backup, or from a specific recovery point.||Snapshot backups support different levels of consistency, including Application, System, and Crash.||Virtual machine backups are encrypted at rest with Storage Service Encryption (SSE). Azure Backup can also back up Azure virtual machines that are encrypted by using Azure Disk Encryption.||The following image shows a high-level view of how Azure virtual machines are backed up with Azure Backup.||Diagram that shows how Azure virtual machine snapshot backups are stored in a Recovery Services vault.||Things to consider when using virtual machine backup and recovery|Here are some things to review when planning backup and recovery for your virtual machines. Consider how you can use Azure virtual machine backups in the Tailwind Traders BCDR solution.||Consider your backup schedule. Identify the best backup schedule for your business needs. To distribute backup traffic, consider backing up different virtual machines at different times of the day, and make sure the backup times don't overlap. Ensure your backup scheduled start time is during nonpeak production application times.||Consider backup frequency. Determine how frequently you need to create fresh backups. Implement both short-term (daily) and long-term (weekly) backups. If you need to take a backup outside of your scheduled via backup policy, you can use an on-demand backup. You might do on-demand backups multiple times per day when scheduled backup permits only one backup per day.||Consider backup policies. Create a single backup policy for a group of virtual machines that require the same schedule start time, frequency, and retention settings. You might establish a backup policy for critical virtual machines, and a separate policy for noncritical machines.||Consider plan changes. After you implement your backup solution, continue to monitor and review your plan. As your business requirements change, make sure to review and change your backup policies. Enable monitoring and alerting features and review the results.||Consider practice restore runs. Restoring backups for virtual machines can be time-consuming. It's a recommended practice to try restoring from your backups before you experience a critical scenario where recovery is essential.||The total restore time depends on the Input/Output operations per second (IOPS) and the throughput of the storage account. The total restore time can be affected if the target storage account is loaded with other application read and write operations. To improve restore operation, select a storage account that isn't loaded with other application data.||Consider throttling during restore. If you're restoring virtual machines from a single Recovery Services vault, we highly recommend that you use different general-purpose v2 storage accounts. By using a v2 storage account, you can ensure your target storage account doesn't get throttled. Consider a scenario where each virtual machine must have a different storage account. If 10 virtual machines are being restored, plan to use 10 different storage accounts.||Consider Cross Region Restore (CRR). CRR allows you to restore Azure virtual machines in a secondary region, which is an Azure paired region. This option lets you conduct drills to meet audit or compliance requirements. You can also restore the virtual machine or its disk if there's a disaster in the primary region. CRR is an opt-in feature for any Recovery Services vault. CRR also works for SQL databases and SAP HANA databases hosted on Azure virtual machines.Design for Azure SQL backup and recovery|Completed|100 XP|3 minutes|It's essential that you can recover your SQL database data. You should consider automated backups of your Azure SQL Database and Azure SQL Managed Instances. Database backups enable database restoration to a specified point in time and within a configured retention period.||Describe automated backups|Both SQL Database and SQL Managed Instance use SQL Server technology to create full backups every week, differential backups every 12-24 hours, and transaction log backups every 5 to 10 minutes. The frequency of transaction log backups is based on the compute size and the amount of database activity. When you restore a database, the service determines which full, differential, and transaction log backups need to be restored.||Full backups: In a full backup, everything in the database and the transaction logs is backed up. SQL Database makes a full backup once a week.||Differential backups: In a differential backup, everything that changed since the last full backup is backed up. SQL Database makes a differential backup every 12 - 24 hours.||Transactional backups: In a transactional backup, the contents of the transaction logs are backed up. If the latest transaction log fails or is corrupted, the option is to fall back to the previous transaction log backup. Transactional backups enable administrators to restore up to a specific time, which includes the moment before data was mistakenly deleted. Transaction log backups every five to 10 minutes.||Describe backup usage cases|You can use the automated backups in several ways.||Restore an existing database to a point in time in the past within the retention period. This operation creates a new database on the same server as the original database but uses a different name to avoid overwriting the original database. After the restore completes, you can delete the original database.||Restore a deleted database to the time of deletion or to any point in time within the retention period. The deleted database can be restored only on the same server or managed instance where the original database was created.||Restore a database to another geographic region. Geo-restore allows you to recover from a geographic disaster when you can't access your database or backups in the primary region. It creates a new database on any existing server or managed instance, in any Azure region.||Restore a database from a specific long-term backup of a single database or pooled database. If the database is configured with a long-term retention polic, you can restore an old version of the database.||Long-term backup retention policies|Azure SQL Database automatic backups remain available to restore for up to 35 days. This period is enough for the purposes of day-to-day administration. But sometimes you might need to retain data for longer periods. For example, data protection regulations in your local jurisdiction might require you to keep backups for several years.||For these requirements, use the long-term retention (LTR) feature. This way, you can store Azure SQL Database backups in read-access geo-redundant storage (RA-GRS) blobs for up to 10 years. If you need access to any backup in LTR, you can restore it as a new database by using either the Azure portal or PowerShell.Design for Azure Site Recovery|Completed|100 XP|3 minutes|Azure Site Recovery provides BCDR features for your applications in Azure, on-premises, and in other cloud providers. The service offers plans to help automate your disaster recovery. You can define how your virtual machines are failed over, and the order in which they're restarted after successful failover.||Things to consider when using Site Recovery|Azure Site Recovery provides a simple BCDR solution with management support from the Azure portal. Set up and manage replication, fail over, and failback for your virtual machines from a single location.||Let's review some of the many capabilities of Azure Site Recovery.||Feature	Description|Replicate Azure virtual machines	Set up disaster recovery of your Azure virtual machines, and fail over from a primary region to a secondary region.|Replicate on-premises virtual machines	Replicate your on-premises virtual machines and physical servers to Azure, or to a secondary on-premises datacenter.|Replicate workloads	Replicate any workload running on supported Azure virtual machines, on-premises Hyper-V and VMware virtual machines, and Windows or Linux physical servers.|Automate BCDR tasks	Automate your BCDR tasks and further reduce your recovery time objective. You can use Azure Site Recovery to set up automatic periodic test failovers, and monitor the overall effectiveness of the recovery process.|Maintain data resilience	Orchestrate replication without intercepting app data by using Azure Site Recovery. When failover occurs, Azure virtual machines are created based on the replicated data. When you replicate to Azure, data is stored in Azure Storage, and you gain the resilience provided by that service.|Meet RTO and RPO targets	Keep the RTO and RPO goals within the defined organizational limits. Azure Site Recovery provides continuous replication for Azure virtual machines and VMware virtual machines, and replication frequency as low as 30 seconds for Hyper-V.|Maintain consistent apps after failover	By using app-consistent snapshots, you can replicate from specific recovery points. These snapshots capture disk data, data in memory, and all in process transactions.|Test without disruption	Run disaster recovery tests without affecting ongoing replication.|Run flexible failovers	Execute planned failovers for expected outages with no data loss. Run unplanned failovers with minimal data loss, and fail back to your primary site when it's available again.|Customize recovery plans	Create recovery plans so you can customize and sequence the failover and recovery of your multi-tier apps running on multiple virtual machines. Group virtual machines together in a recovery plan, and add scripts and manual actions as needed. Integrate recovery plans with Azure Automation runbooks.|Integrate with BCDR technologies	Integrate Azure Site Recovery with other BCDR technologies. Use Site Recovery to protect the SQL Server backend of your corporate workloads. Because of its native support for SQL Server AlwaysOn, you can manage the failover of availability groups.|Access Azure Automation integration	Download from the Azure Automation library and integrate app-specific scripts with Azure Site Recovery.|Use Azure Site Recovery with Azure Backup|Let's examine how you can implement Azure Site Recovery with Azure Backup for a BCDR solution.||Suppose you have an on-premises environment with a Hyper-V host server for hosting virtual machines. You want to back up all the files and folders in your virtual machine to Azure. You also want to protect any workloads running on your virtual machine and keep them running if the virtual machine fails. Azure Backup and Site Recovery can be used together in a single solution.||Diagram that shows a BCDR solution with Azure Site Recovery and Azure Backup.||In this scenario, Azure Backup periodically backs up the files and folders on your Windows machine to Azure. This process ensures they data is secure and retrievable even if the whole on-premises environment stops functioning. Separately, Azure Site Recovery is used to protect your running workloads and keep them running. Because Site Recovery can replicate frequently, the RTO for your workloads can be reduced.Knowledge check|Completed|200 XP|3 minutes|Tailwind Traders is assessing their backup continuity and disaster recovery plan. You're responsible for selecting an appropriate backup solution for migrated workloads. As part of your plan, you also need to select an appropriate disaster recovery option for these workloads. Here are some specific requirements.||Regional outage option for Azure virtual machine backups. The company has stringent recovery time objectives and recovery point objectives. The IT department is concerned about regional outages and requests a solution.||Backup option for on-premises virtual machines. The IT department needs a way to back up on-premises virtual machines. They want to define the frequency and only pay-as-they-go for storage.||Database backup option for Azure SQL databases. The company has several Azure SQL databases in an elastic pool. The IT department needs a solution for when the primary database fails or needs to be offline.||Accidental deletion and recovery of video files. Each product in the retail catalog has an associated video. This video is critical to the marketing of the product on the company website. The IT department wants to ensure they can recover snapshots of these files, if they're deleted.||Answer the following questions|Choose the best response for each of the following questions. Then select Check your answers.|||1. What replication option would be best for the Azure virtual machine backups? ||Azure Site Recovery|Correct. Azure Site Recovery is designed to provide continuous replication to a secondary region.|||Azure Backup||Active geo-replication|2. What backup solution is best for the on-premises virtual machines? ||Azure Site Recovery||Azure Backup|Correct. Azure Backup can protect on-premises virtual machines.|||Active geo-replication|3. What solution would be best for the Azure SQL database requirement? ||Azure Site Recovery||Azure Backup||Active geo-replication.|Correct. Active geo-replication can fail over to a secondary database if your primary database fails or needs to be taken offline.||4. ‎To address the company’s concern with accidental data deletion, which of these solutions is best? ||Enable disk caching||Enable soft delete|Correct. With soft delete you can specify a retention period. The data is retained during the retention period and can be recovered.|||Add a resource lock to the storage account|Azure Architects understand how to design solutions to back up their data and support disaster recovery. These solutions help to avoid costly business interruptions due to component failures, malicious attacks, and outages. Microsoft Azure provides an end-to-end backup and disaster recovery solution that's secure, scalable, and resilient, while remaining cost-effective.||In this module, you learned how to select appropriate backup solutions for Azure workloads. You also reviewed how to select appropriate disaster recovery options for these workloads. You explored backup and recovery options for Azure files, blobs, virtual machines, and SQL databases. You examined how to design solutions for several Azure services, including Azure Backup and Azure Site Recovery.||Learn more|Read more about Azure file share backup.||Peruse Azure Backup service documentation.||Explore Azure Recovery Services vaults.||Peruse Azure Site Recovery documentation.||Examine Azure to Azure disaster recovery architecture.||Read about Azure Traffic Manager.||Use auto-failover groups to enable transparent and coordinated failover of multiple databases.||Explore Azure Storage redundancy.||Back up Azure file shares.Implementing HADR database platform solutions is more than just deploying a feature. Understand why and what you are doing to implement the right strategy.||||Suppose you need to implement high availability and disaster recovery (HADR) for an IaaS virtual machine that is running SQL Server 2019. Do you know how much time you would have to bring things back online if there was a problem? Do you know what options are available in SQL Server and the reasons for choosing one option over another?||||By the end of this module, you will have a solid foundation that will allow you to implement HADR solutions in Azure.||||Learning objectives||After this module, you will understand:||||Recovery time objective (RTO)||||Recovery point objective (RPO)||||The available HADR options for both IaaS and PaaS||||How to devise a HADR strategyDescribe recovery time objective and recovery point objective||Completed||100 XP||10 minutes||Understanding recovery time and recovery point objectives are crucial to your high availability and disaster recovery (HADR) plan as they're the foundation for any availability solution.||||Recovery Time Objective||Recovery Time Objective (RTO) is the maximum amount of time available to bring resources online after an outage or problem. If that process takes longer than the RTO, there could be consequences such as financial penalties, work not able to be done, and so on. RTO can be specified for the whole solution, which includes all resources, as well as for individual components such as SQL Server instances and databases.||||Recovery Point Objective||Recovery Point Objective (RPO) is the point in time to which a database should be recovered and equates to the maximum amount of data loss that the business is willing to accept. For example, suppose an IaaS VM containing SQL Server experiences an outage at 10:00 AM and the databases within the SQL Server instance have an RPO of 15 minutes. No matter what feature or technology is used to bring back that instance and its databases, the expectation is that there will be at most 15 minutes worth of data lost. That means the database can be restored to 9:45 AM or later to ensure minimal to no data loss meeting that stated RPO. There may be factors that determine if that RPO is achievable.||||Defining Recovery Time and Recovery Point Objectives||RTOs and RPOs are driven by business requirements but are also based on various technological and other factors, such as the skills and abilities of the administrators (not just DBAs). While the business may want no downtime or zero data loss, that may not be realistic or possible for a variety of reasons. Determining your solution’s RTO and RPO should be an open and honest discussion between all parties involved.||||One of the aspects crucial for both RTO and RPO is knowing the cost of downtime. If you define that number and the overall effect being down or unavailable has to the business, it's easier to define solutions. For example, if the business can lose 10,000 per hour or could be fined by a government agency if something could not be processed, that is a measurable way to help define RTO and RPO. Spending on the solution should be proportional to the amount, or the cost, of downtime. If your HADR solution costs $X, but you wind up only being affected for a few seconds instead of hours or days when a problem occurs, it has paid for itself.||||From a nonbusiness standpoint, RTO should be defined at a component level (for example, SQL Server) as well as for the entire application architecture. The ability to recover from an outage is only as good as its weakest link. For example, if SQL Server and its databases can be brought online in five minutes but it takes application servers 20 minutes to do the same, the overall RTO would be 20 minutes, not five. The SQL Server environment could still have an RTO of five minutes; it still will not change the overall time to recover.||||RPO deals specifically with data and directly influences the design of any HADR solution as well as administrative policies and procedures. The features used must support both the RTO and RPOs that are defined. For example, if transaction log back ups are scheduled every 30 minutes but there is a 15-minute RPO, a database could only be recovered to the last transaction log backup available which in the worst case would be 30 minutes ago. This timing assumes no other issues and the backups have been tested and are known to be good. While it is hard to test every backup generated for each database in your environment, backups are just files on a file system. Without doing at least periodic restores, there is no guarantee they're good. Running checks during the backup process can give you some degree of confidence.||||The specific features used, such as an Always On Availability Group (AG) or an Always On Failover Cluster Instance (FCI) will also affect your RTOs and RPOs. Depending on how the features are configured, IaaS or PaaS solutions may or may not automatically fail over to another location, which could result in longer downtime. By defining RTO and RPO, the technical solution that supports that requirement can be designed knowing the allowances for time and data loss. If those wind-up being unrealistic, RTOs and RPOs must be adjusted accordingly. For example, if there is a desired RTO of two hours but a backup will take three hours to copy to the destination server for restoring, the RTO is already missed. These types of factors must be accounted for when determining your RTOs and RPOs.||||There should be RTOs and RPOs defined for both HA and DR. HA is considered a more localized event that can be recovered from more easily. One example of high availability would be an AG automatically failing over from one replica to another within an Azure region. That may take seconds, and at that point, you would need to ensure that the application can connect after the failovers. SQL Server’s downtime would be minimal. A local RTO or RPO may potentially be measured in minutes depending on the critical nature of the solution or system.||||DR would be akin to bringing up a whole new data center. There are lots of pieces to the puzzle; SQL Server is just one component. Getting everything online may take hours or longer. This is why the RTOs and RPOs are separate. Even if many the technologies and features used for HA and DR are the same, the level of effort and time involved may not be.||||All RTOs and RPOs should be formally documented and revised periodically or as needed. Once they're documented, you can then consider what technologies and features you may use for the architecture.Explore high availability and disaster recovery options||Completed||100 XP||15 minutes||To envision a solution for virtual machines (VMs), you must first understand the availability options for IaaS-based deployments.||||Infrastructure-as-a-Service versus Platform-as-a-Service||When it comes to availability, the choice of IaaS or PaaS makes a difference. With IaaS, you have a virtual machine, which means there is an operating system with an installation of SQL Server. The administrator or group responsible for SQL Server would have a choice of high availability and disaster recovery (HADR) solutions and a great deal of control over what how that solution was configured.||||With PaaS-based deployments such as Azure SQL Database, the HADR solutions are built into the feature and often just need to be enabled. There are minimal options that can be configured.||||Because of these differences, the choice of IaaS or PaaS may influence the final design of your HADR solution.||||SQL Server HADR Features for Azure Virtual Machine||When using IaaS, you can use the features provided by SQL Server to increase availability. In some cases, they can be combined with Azure-level features to increase availability even further.||||The features available in SQL Server are shown in the table below||||Feature Name	Protects||Always On Failover Cluster Instance (FCI)	Instance||Always On Availability Group (AG)	Database||Log Shipping	Database||An instance of SQL Server is the entire installation of SQL Server (binaries, all the objects inside the instance including things like logins, SQL Server Agent jobs, and databases). Instance-level protection means that the entire instance is accounted for in the availability feature.||||A database in SQL Server contains the data that end users and applications use. There are system databases that SQL Server relies on, as well as databases created for use by end users and applications. An instance of SQL Server always has its own system databases. Database-level protection means that anything that is in the database, or is captured in the transaction log for a user or application database, is accounted for as part of the availability feature. Anything that exists outside of the database or that is not captured as part of the transaction log such as SQL Server Agent jobs and linked servers must be manually dealt with to ensure the destination server can function like the primary if there is a planned or unplanned failover event.||||Both FCIs and AGs require an underlying cluster mechanism. For SQL Server deployments running on Windows Server, it is a Windows Server Failover Cluster (WSFC) and for Linux it is Pacemaker.||||Always On Failover Cluster Instances||An FCI is configured when SQL Server is installed. A standalone instance of SQL Server cannot be converted to an FCI. The FCI is assigned a unique name as well as an IP address that is different from the underlying servers, or nodes, participating in the cluster. The name and IP address must also be different from the underlying cluster mechanism. Applications and end users would use the unique name of the FCI for access. This abstraction enables applications to not have to know where the instance is running. One major difference between Azure-based FCIs versus on-premises FCIs, is that for Azure, an internal load balancer (ILB) is required. The ILB is used to help ensure applications and end users can connect to the FCI’s unique name.||||When an FCI fails over to another node of a cluster, whether it is initiated manually or happens due to a problem, the entire instance restarts on another node. That means the failover process is a full stop and start of SQL Server. Any applications or end users connected to the FCI will be disconnected during failover and only applications that can handle and recover from this interruption can reconnect automatically.||||Upon starting up on the other node, the instance goes through the recovery process. The FCI will be consistent to the point of failure, so technically there will be no data loss but any transactions that need to be rolled back will do so as part of recovery. As noted above, because this is instance-level protection, everything necessary (logins, SQL Server Agent jobs, etc.) is already there so business can continue as usual once the databases are ready.||||FCIs require one copy of a database, but that is also its single point of failure. To ensure another node can access the database, FCIs require some form of shared storage. For Windows Server-based architectures, this can be achieved via an Azure Premium File Share, iSCSI, Azure Shared Disk, Storage Spaces Direct (S2D), or a supported third-party solution like SIOS DataKeeper. FCIs using Standard Edition of SQL Server can have up to two nodes. FCIs also require the use of Active Directory Domain Services (AD DS) and Domain Name Services (DNS), so that means AD DS and DNS must be implemented somewhere in Azure for an FCI to work.||||Using Windows Server 2016 or later, FCIs can use Storage Replica to create a native disaster recovery solution for FCIs without having to use another feature such as log shipping or AGs.||||Always On availability groups||AGs were introduced in SQL Server 2012 Enterprise Edition and as of SQL Server 2016, are also in Standard Edition. In Standard Edition, an AG can contain one database whereas in Enterprise Edition, an AG can have more than one database. While AGs share some similarities with FCIs, in most ways they are different.||||The biggest difference between an FCI and an AG is that AGs provide database-level protection. The primary replica is the instance participating in an AG that contains the read/write databases. A secondary replica is where the primary sends transactions over the log transport to keep it synchronized. Data movement between a primary replica can be synchronous or asynchronous. The databases on any secondary replica are in a loading state, which means they can receive transactions but cannot be a fully writeable copy until that replica becomes the primary. An AG in Standard Edition can have at most two replicas (one primary, one secondary) whereas Enterprise Edition supports up to nine (one primary, eight secondary). A secondary replica is initialized either from a backup of the database, or as of SQL Server 2016, you can use a feature called ‘automatic seeding’. Automatic seeding uses the log stream transport to stream the backup to the secondary replica for each database of the availability group using the configured endpoints.||||An AG provides abstraction with the listener. The listener functions like the unique name assigned to an FCI and has its own name and IP address that is different from anything else (WSFC, node, etc.). The listener also requires an ILB and goes through a stop and start. Applications and end users can use the listener to connect, but unlike an FCI, if desired, the listener does not have to be used. Connections directly to the instance can occur. With Enterprise Edition, secondary replicas in Enterprise Edition can also be configured for read-only access if desired and can be used for other functionality such as database consistency checks (DBCCs) and backups.||||AGs can have a quicker failover time compared to an FCI, which is one reason they are attractive. While AGs do not require shared storage, each replica has a copy of the data, which increases the total number of copies of the database and overall storage costs. The storage is local to each replica. For example, if the data footprint of the databases on the primary replica is 1 TB, each replica will also have the same. If there are five replicas, that means you need 5 TB of space.||||Remember that any object that exists outside of the database or is not captured in the database’s transaction log must manually be created and accounted for on any other SQL Server instance should that instance need to become the new primary replica. Examples of objects you would be responsible for include SQL Server Agent jobs, instance-level logins, and linked servers. If you can use Windows authentication or use contained databases with AGs, it will simplify access.||||Many organizations may face challenges implementing highly available architectures, and may only need the high availability provided by the Azure platform, or using a PaaS solution like Azure SQL Managed Instance. Before we look at Azure platform solutions, there is one other SQL Server feature that you should know about: log shipping.||||Log shipping||Log shipping has been around since the early days of SQL Server. The feature is based on backup, copy, and restore and is one of the simplest methods of achieving HADR for SQL Server. Log shipping is primarily used for disaster recovery, but it could also be used to enhance local availability.||||Log shipping, like AGs, provides database-level protection, which means you still need to account for SQL Server Agent jobs, linked servers, instance-level logins, etc. There is no abstraction provided natively by log shipping, so a switch to another server participating in log shipping must be able to tolerate a name change. If that is not possible, there are methods such as a DNS alias, which can be configured at the network layer to try to mitigate the name change issues.||||The log shipping mechanism is simple: first, take a full backup of the source database on the primary server, restore it in a loading state (STANDBY or NORECOVERY) on another instance known as a secondary server or warm standby. This new copy of the database is known as a secondary database. An automated process built into SQL Server will then automatically backup the primary database’s transaction log, copy the backup to the standby server, and finally, restore the backup onto the standby.||||The SQL Server HADR features are not the only options to enhance IaaS availability. There are some features in Azure that should also be considered.Describe Azure high availability and disaster recovery features for Azure Virtual Machines||Completed||100 XP||7 minutes||Azure provides three main options to enhance availability for IaaS deployments:||||Availability Sets||||Availability Zones||||Azure Site Recovery||||All three of these options are external to the virtual machine (VM) and don't know what kind of workload is running inside of it.||||Availability sets||Availability sets provide uptime against Azure-related maintenance and single points of failure in a single data center. This was one of the first availability features introduced into the Azure platform, and effectively it can be thought of as anti-affinity rules for your VMs. This means if you had two SQL Server VMs in an availability set or log shipping pair, they would be guaranteed to never run on the same physical server.||||Availability sets are separated into both fault domains and update domains to support both updates to the underlying Azure Infrastructure. Fault domains are sets of servers within a data center, which use the same power source and network There can be up to three fault domains in a data center as depicted in the image below by FD 0, 1, and 2. Update domains, denoted by UD in the image below, indicate groups of virtual machines and underlying physical hardware that can be rebooted at the same time. Different update domains ensure separation.||||-----||FD 0 | =  ||FD 0 | UD 0 =  ||FD 0 | =||FD 0 | =||||FD 0 | =  ||FD 0 | UD 1 =  ||FD 0 | UD 2 =||FD 0 | =||||FD 0 | =  ||FD 0 | =  ||FD 0 | =||FD 0 | =||----- ||||||Availability sets and zones don't protect against in-guest failures, such as an OS or RDBMS crash; which is why you need to implement additional solutions such as AGs or FCIs to ensure you meet RTOs and RPOs. Both availability sets and zones are designed to limit the impact of environmental problems at the Azure level such as datacenter failure, physical hardware failure, network outages, and power interruptions.||||For a multi-tier application, you should put each tier of the application into its own availability set. For example, if you were building a web application that has a SQL Server backend along with Active Directory Domain Services (AD DS), you would create an availability set for each tier (web, database, and AD DS).||||Availability sets are not the only way to separate IaaS VMs. Azure also provides Availability Zones, but the two can't be combined. You can pick one or the other.||||Availability zones||Availability zones account for data center-level failure in Azure. Each Azure region consists of many data centers with low latency network connections between them. When you deploy VM resources in a region that supports Availability Zones, you have the option to deploy those resources into Zone 1, 2, or 3. A zone is a unique physical location, that is, a data center, within an Azure region.||||Zone numbers are logical representations. For example, if two Azure subscribers both deploy a VM into Zone 1 in their own subscriptions, that doesn't mean those VMs exist in the same physical Azure data center. Additionally, because of the distance there can be some additional latency introduced into zonal deployments. You should test the latency between your VMs to ensure that the latency meets performance targets. In most cases round-trip latency will be less than 1 millisecond, which supports synchronous data movement in features like availability groups. You can also deploy Azure SQL Database into Availability Zones.||||Azure Site Recovery||Azure Site Recovery provides enhanced availability for VMs at the Azure level and can work with VMs hosting SQL Server. Azure Site Recovery replicates a VM from one Azure region to another to create a disaster recovery solution for that VM. As noted earlier, this feature does not know that SQL Server is running in the VM and knows nothing about transactions. While Azure Site Recovery may meet RTO, it may not meet RPO since it isn't accounting for where data is inside SQL Server. Azure Site Recovery has a stated monthly RTO of two hours. While most database professionals may prefer to use a database-based method for disaster recovery, Azure Site Recovery works well if it meets your RTO and RPO needs.||||Describe high availability and disaster recovery options for PaaS deployments||Completed||100 XP||5 minutes||PaaS is different when it comes to availability; you can only configure the options that Azure provides.||||For the SQL Server-based options of Azure SQL Database and Azure SQL Database Managed Instance, the options are active geo-replication (Azure SQL Database only) and autofailover groups (Azure SQL Database or Azure SQL Database Managed Instance).||||Azure Database for MySQL has a service level agreement, which guarantees availability of 99.99, meaning nearly no downtime should be encountered. For Azure Database for MySQL, if a node-level problem happens such as hardware failure, a built-in failover mechanism will kick in. All transactional changes to the MySQL database are written synchronously to storage upon commit. If a node-level interruption occurs, the database server automatically creates a new node and attaches the data storage.||||From an application standpoint, you will need to code the necessary retry logic because all connections are dropped as part of spinning up the new node and any in flight transactions are lost. This process is considered a best practice for any cloud application, as they should be designed to handle transient failures.||||Azure Database for PostgreSQL uses a similar model to MySQL in its standard deployment model; however, Azure PostgreSQL also offers a scale-out hyperscale solution called Citus. Citus provides both scale-out and additional high availability for a server group. If enabled, a standby replica is configured for every node of a server group, which would also increase cost since it would double the number of servers in the group. In the event, the original node has a problem such as becoming unresponsive or failing completely, the standby takes its place. The data is kept in sync via PostgreSQL synchronous streaming replication.||||As with Azure Database for MySQL, solutions that use Azure Database for PostgreSQL must also include retry logic in the application because of dropped connections and loss of in-flight transactions.||||Both Azure Database for MySQL and PostgreSQL supports the option for a read replica. This means a replica can be used for activities like reporting to offload work from the primary database. A read replica also enhances availability because it exists in another region.||||Explore an IaaS high availability and disaster recovery solution||Completed||100 XP||11 minutes||There are many different combinations of features that could be deployed in Azure for IaaS. This section will cover five common examples of SQL Server high availability and disaster recovery (HADR) architectures in Azure.||||Single Region High Availability Example 1 – Always On availability groups||If you only need high availability and not disaster recovery, configuring an (availability group) AG is one of the most ubiquitous methods no matter where you are using SQL Server. The image below is an example of what one possible AG in a single region could look like.||||An Availability Group in a single region||||Why is this architecture worth considering?||||This architecture protects data by having more than one copy on different virtual machines (VMs).||||This architecture allows you to meet recovery time objective (RTO) and recovery point objective (RPO) with minimal-to-no data loss if implemented properly.||||This architecture provides an easy, standardized method for applications to access both primary and secondary replicas (if things like read-only replicas will be used).||||This architecture provides enhanced availability during patching scenarios.||||This architecture needs no shared storage, so there is less complication than when using a failover cluster instance (FCI).||||Single Region High Availability Example 2 – Always On Failover Cluster Instance||Until AGs were introduced, FCIs were the most popular way to implement SQL Server high availability. FCIs, however, were designed when physical deployments were dominant. In a virtualized world, FCIs do not provide many of the same protections in the way they would on physical hardware because it is rare for a VM to have a problem. FCIs were designed to protect against things like network card failure or disk failure, both of which would likely not happen in Azure.||||Having said that, FCIs do have a place in Azure. They work, and as long as you have the right expectations about what is and is not provided, an FCI is a perfectly acceptable solution. The image below, from the Microsoft documentation, shows a high-level view of what an FCI deployment looks like when using Storage Spaces Direct.||||A FCI deployment using Storage Spaces Direct||||Why is this architecture worth considering?||||FCIs are still a popular availability solution.||||The shared storage story is improving with feature like Azure Shared Disk.||||This architecture meets most RTO and RPO for HA (although DR is not handled).||||This architecture provides an easy, standardized method for applications to access the clustered instance of SQL Server.||||This architecture provides enhanced availability during patching scenarios.||||Disaster Recovery Example 1 – Multi-Region or Hybrid Always On availability group||If you are using AGs, one option is to configure the AG across multiple Azure regions or potentially as a hybrid architecture. This means that all nodes which contain the replicas participate in the same WSFC. This assumes good network connectivity, especially if this is a hybrid configuration. One of the biggest considerations would be the witness resource for the WSFC. This architecture would require AD DS and DNS to be available in every region and potentially on premises as well if this is a hybrid solution. The image below shows what a single AG configured over two locations looks like using Windows Server.||||A single AG configured over two locations||||Why is this architecture worth considering?||||This architecture is a proven solution; it is no different than having two data centers today in an AG topology.||||This architecture works with Standard and Enterprise editions of SQL Server.||||AGs naturally provide redundancy with additional copies of data.||||This architecture makes use of one feature that provides both HA and D/R||||Disaster Recovery Example 2 –Distributed availability group||A distributed AG is an Enterprise Edition only feature introduced in SQL Server 2016. It is different than a traditional AG. Instead of having one underlying WSFC where all of nodes contain replicas participating in one AG as described in the previous example, a distributed AG is made up of multiple AGs. The primary replica containing the read write database is known as the global primary. The primary of the second AG is known as a forwarder and keeps the secondary replica(s) of that AG in sync. In essence, this is an AG of AGs.||||This architecture makes it easier to deal with things like quorum since each cluster would maintain its own quorum, meaning it also has its own witness. A distributed AG would work whether you are using Azure for all resources, or if you are using a hybrid architecture.||||The image below shows an example distributed AG configuration. There are two WSFCs. Imagine each is in a different Azure region or one is on premises and the other is in Azure. Each WSFC has an AG with two replicas. The global primary in AG 1 is keeping the secondary of replica of AG 1 synchronized as well as the forwarder, which also is the primary of AG 2. That replica keeps the secondary replica of AG 2 synchronized.||||An example distributed AG configuration||||Why is this architecture worth considering?||||This architecture separates out the WSFC as a single point of failure if all nodes lose communication||||In this architecture, one primary is not synchronizing all secondary replicas.||||This architecture can provide failing back from one location to another.||||Disaster Recovery Example 3 – Log shipping||Log shipping is one of the oldest HADR methods for configuring disaster recovery for SQL Server. As described above, the unit of measurement is the transaction log backup. Unless the switch to a warm standby is planned to ensure no data loss, data loss will most likely occur. When it comes to disaster recovery, it is always best to assume some data loss even if minimal. The image below, from the Microsoft documentation, shows an example log shipping topology.||||Configuration showing backup, copy, & restore jobs||||Why is this architecture worth considering?||||Log shipping is a tried-and-true feature that has been around for over 20 years||||Log shipping is easy to deploy and administer since it is based on backup and restore.||||Log shipping is tolerant of networks that are not robust.||||Log shipping meets most RTO and RPO goals for DR.||||Log shipping is a good way to protect FCIs.||||Disaster Recovery Example 4 – Azure Site Recovery||For those who do not want to implement a SQL Server-based disaster solution, Azure Site Recovery is a potential option. However, most data professionals prefer a database-centric approach as it will generally have a lower RPO.||||The image below, from the Microsoft documentation. shows where in the Azure portal you would configure replication for Azure Site Recovery.||||Configuring Azure Site Recovery||||Why is this architecture worth considering?||||Azure Site Recovery will work with more than just SQL Server.||||Azure Site Recovery may meet RTO and possibly RPO.||||Azure Site Recovery is provided as part of the Azure platform.||Describe hybrid solutions||Completed||100 XP||4 minutes||You should now understand recovery time objectives (RTOs) and recovery point objectives (RPOs) as well as the different features both in SQL Server as well as Azure to increase availability, you can put all of that together and design a solution to meet your high availability and disaster recovery (HADR) requirements.||||While an architecture can be deployed in one or more Azure regions, many organizations will need or want to have solutions that span both on premises and Azure, or possibly Azure to another public cloud. This type of architecture is known as a hybrid solution.||||PaaS solutions by nature aren't designed to allow traditional hybrid solutions. HADR is provided by the Azure infrastructure. There are some exceptions. For example, SQL Server’s transactional replication feature can be configured from a publisher located on premises (or another cloud) to an Azure SQL Managed Instance subscriber, but not the other way.||||Hybrid solutions are therefore IaaS-based since they rely on traditional infrastructure. Hybrid solutions are useful. Not only can they be used to help migrate to Azure, but the most common usage of a hybrid architecture is to create a robust disaster recovery solution for an on premises system. For example, a secondary replica for an AG can be added in Azure. That means any associated infrastructure must exist, such as AD DS and DNS.||||Arguably the most important consideration for a hybrid HADR solution that extends to Azure is networking. Not having the right bandwidth could mean missing your RTO and RPO. Azure has a fast networking option called ExpressRoute. If ExpressRoute isn't something your company can or will implement, configure a secure site-to-site VPN so that the Azure VMs will act as an extension of your on premises infrastructure. Exposing IaaS VMs directly to the public internet is discouraged.||||Although not traditionally thought of as hybrid, Azure can also be used as the destination for a database backup and as cold, archival storage for backups.||||<Knowledge check||Completed||200 XP||5 minutes||Check your knowledge||||1. What is RPO? ||||The number of nodes in a cluster||||The point to which data needs to be recovered after a failure||That's correct. RPO is the point in time to which a database should be recovered and equates to the maximum amount of data loss that the business is willing to accept.||||||A partial database restores||2. What is a hybrid solution? ||||A solution that has resources both in Azure as well as on premises or in another cloud provider||That's correct. Hybrid solutions span both on premises and Azure, or possibly Azure to another public cloud.||||||A solution that uses two different database engines, for example, MySQL and SQL Server||||A solution that spans two different versions of SQL Server||3. What is available after failover with database-level protection in SQL Server? ||||Logins, Databases, and SQL Server Agent Job||||Databases and SQL Server Agent jobs||||Whatever is in the databases; anything outside must be dealt with manually||That's correct. Database-level protection means that anything that is captured in the transaction log for a user or application database is accounted for as part of the availability feature. Anything that exists outside of the database or that isn't captured as part of the transaction log such as SQL Server Agent jobs and linked servers must be manually dealt with to ensure the destination server can function like the primary in the event of a planned or unplanned failover event.>]}
{"category":"Design data storage solutions":[Data storage describes how different data is stored and managed in your organization. The type of data storage that you implement is based on the structure of your data and how your data is accessed.||Data can be highly organized like machine configurations and customer invoices. Other data is less structured, such as fax images and engineering white papers. Some data is used only by specific users like system administrators or file owners. And other data is used by all users, including internal employees and external partners.||Meet Tailwind Traders|||Tailwind Traders is a fictitious home improvement retailer. The company operates retail hardware stores across the globe and online. As you work through this lesson, suppose you're the CTO for Tailwind Traders. You're investigating storage solutions for data that's not highly organized. You're interested in how storage accounts can be used with blob, file, and disk storage for unstructured data. You want to implement strong protection for your data storage. The company is seeking a data storage solution that balances features with strong performance and reasonable cost.||Learning objectives|In this module, you learn how to:||Design for data storage.||Design for Azure storage accounts.||Design for Azure Blob Storage.||Design for data redundancy.||Design for Azure Files.||Design for Azure managed disks.||Design for storage security.||Skills measured|The content in this module helps you prepare for Exam AZ-305: Designing Microsoft Azure Infrastructure Solutions. The module concepts are covered in:||Design data storage solutions||Design a data storage solution for nonrelational data||Recommend a data storage solution to balance features, performance, and cost||Design a data solution for protection and durability||Recommend access control solutions for data storage||Prerequisites|Conceptual knowledge of storage accounts, blobs, files, disks, and data protection.||Working experience with creating and securing storage systems.Design for data storage|Completed|100 XP|2 minutes|The first step in your design for Azure storage is to determine what types of data are required to support the Tailwind Traders organization. In general, data can be classified in three ways: structured, semi-structured, and unstructured. Most organizations need to provide storage options for all data types.||Things to know about types of data|The following table describes three data types. Consider how these different types are used in your organization.||Structured	Semi-structured	Unstructured|		|Structured data is stored in a relational format that has a shared schema. Structured data is often contained in a database table with rows, columns, and keys.	Semi-structured data is less organized. The data fields don't fit neatly into tables, rows, and columns. Semi-structured data contains tags that clarify how the data is organized. The data is defined by using a serialization language.	Unstructured data is the least organized. This data is a mix of information without a clear relationship. The format of unstructured data is referred to as nonrelational.|- Relational databases, such as medical records, phone books, and financial accounts|- Application data for an e-commerce website	- Hypertext Markup Language (HTML) files|- JavaScript Object Notation (JSON) files|- Extensible Markup Language (XML) files	- Media files like photos, videos, and audio|- Office files, such as Word documents and PowerPoint slides|- Text files like PDF, TXT, and RTF| Note||In this module, we review storage options for unstructured nonrelational data. You can discover how to work with structured and relational data in the module, Design a data storage solution for relational data.||Things to consider when choosing data storage|Nonrelational data in Azure can be stored in several different data objects. We look at scenarios that implement four storage objects. As you review these options for Tailwind Traders, think about what types of nonrelational data are of most interest to your organization. Consider the storage objects that you might need to implement.||Consider Azure Blob Storage. Store vast amounts of unstructured data by using Azure Blob Storage. Blob stands for Binary Large Object. Blob Storage is often used for images and multimedia files.||Consider Azure Files. Provide fully managed file shares in the cloud with Azure Files. This storage data is accessible via the industry standard Server Message Block (SMB) protocol, Network File System (NFS) protocol, and the Azure Files REST API.||Consider Azure managed disks. Support Azure Virtual Machines by using Azure managed disks. These disks are block-level storage volumes managed by Azure. Managed disks perform like physical disks in an on-premises server, but in a virtual environment.||Consider Azure Queue Storage. Use Azure Queue Storage to store large numbers of messages. Queue Storage is commonly used to create a backlog of work to process asynchronously.Design for Azure storage accounts|Completed|100 XP|4 minutes|After you determine the data storage requirements for your organization, you need to create storage accounts for Tailwind Traders.||An Azure storage account groups together all of your Azure Storage services. The storage account provides a unique namespace that's accessible from anywhere (assuming you have the correct permissions) in the world over HTTPS. Data in your storage account is durable and highly available, secure, and massively scalable.||A storage account represents a collection of settings like location, replication strategy, and subscription owner. Organizations often have multiple storage accounts so they can implement different sets of requirements. The following illustration shows two storage accounts in the Tailwind Traders organization that differ only in the data location (region). But, this one difference is enough to require separate storage accounts in the infrastructure.||Diagram showing storage account considerations like location, compliance, cost, replication, and administration.||Things to know about storage account types|Azure Storage offers several storage account options. Each storage account supports different features and has its own pricing model. Review the following options and think about what storage accounts are required to support Tailwind Traders applications.||Storage account	Supported services	Recommended usage|Standard general-purpose v2	Blob Storage (including Data Lake Storage), Queue Storage, Table Storage, and Azure Files	Standard storage account for most scenarios, including blobs, file shares, queues, tables, and disks (page blobs).|Premium block blobs	Blob Storage (including Data Lake Storage)	Premium storage account for block blobs and append blobs. Recommended for applications with high transaction rates. Use Premium block blobs if you work with smaller objects or require consistently low storage latency. This storage is designed to scale with your applications.|Premium file shares	Azure Files	Premium storage account for file shares only. Recommended for enterprise or high-performance scale applications. Use Premium file shares if you require support for both Server Message Block (SMB) and NFS file shares.|Premium page blobs	Page blobs only	Premium high-performance storage account for page blobs only. Page blobs are ideal for storing index-based and sparse data structures, such as operating systems, data disks for virtual machines, and databases.|Things to consider when choosing storage accounts|You review Azure storage account options and some scenarios for when to use different types of storage accounts. Take a few minutes to think about the storage accounts in the Tailwind Traders organization. If you're already using storage accounts, explore how well the configuration meets the business scenarios.||Consider your storage locations. Locate data storage close to where it's most frequently used. Does Tailwind Traders have data that's specific to a location? You might need a storage account to best support each location.||Consider compliance requirements. Examine regulatory guidelines for Tailwind Traders business scenarios. Are there guidelines for keeping data in a specific location? Does your company have internal requirements for auditing or storing data? You might require different storage accounts to meet the different requirements.||Consider data storage costs. Factor in data storage costs into your plan for Tailwind Traders. A storage account by itself has no financial cost. But, the settings you choose for the account do influence the cost of services in the account. Geo-redundant storage costs more than locally redundant storage. Premium performance and the hot access tier increase the cost of blobs. Do you need to keep track of expenses or billing by department or project? Are you working with partners where storage costs need to be separated? By creating multiple storage accounts, you can better control the overall costs.||Consider replication scenarios. Configure data storage to support different replication strategies. You could partition your data into critical and noncritical categories. You could place Tailwind Traders critical data into a storage account with geo-redundant storage. You could put Tailwind Traders noncritical data in a different storage account with locally redundant storage.||Consider administrative overhead. Plan for administrative overhead in your Tailwind Traders storage design. Each storage account requires some time and attention from an administrator to create and maintain. Using multiple storage accounts increases the complexity for users who add data to your cloud storage. Users in this role need to understand the purpose of each storage account to ensure they add new data to the correct account.||Consider data sensitivity. Protect sensitive and proprietary Tailwind Traders data in your data storage. You can enable virtual networks for proprietary data and not for public data. This scenario might require separate storage accounts.||Consider data isolation. Segregate regulatory and compliance data, or local policies by using multiple storage accounts for Tailwind Traders. You can separate data in one application from data in another application to ensure data isolation.Design for data redundancy|Completed|100 XP|15 minutes|Azure Storage always stores multiple copies of your Tailwind Traders data. This redundancy ensures the data is protected from planned and unplanned events. These events can include transient hardware failures, network or power outages, and massive natural disasters. Storage redundancy ensures your storage account meets its availability and durability targets.||Things to know about data redundancy|Review the following characteristics of data redundancy in Azure Storage.||Redundancy is achieved by replicating data to a primary region.||When you create a storage account, you select the primary region for the account.||The primary region supports two replication options: locally redundant storage (LRS) and zone-redundant storage (ZRS).||Replication can also be done for a secondary region. A secondary region is recommended for applications that require high durability.||The paired secondary region is determined based on the primary region and can't be changed.||The secondary region is usually in a geographic location that's distant to the primary region. The distance helps to protect against regional disasters.||The secondary region supports two replication options: geo-redundant storage (GRS) and geo-zone-redundant storage (GZRS).||Redundancy in the primary region|Azure Storage offers two options for how your data is replicated in the primary region: locally redundant storage and zone-redundant storage.||Diagram of locally redundant storage with three copies in the data center, and zone-redundant storage with three copies in different data centers.||Locally redundant storage is the lowest-cost redundancy option, and offers the least durability. LRS protects your data against server rack and drive failures. However, if the data center fails, all replicas of a storage account that use LRS might be lost or unrecoverable.||Zone-redundant storage replicates synchronously across three Azure availability zones in the primary region. With ZRS, your data is still accessible for both read and write operations even if a zone becomes unavailable.||Redundancy in a secondary region|For applications that require high durability, you can choose to copy the data in your storage account to a secondary region. Azure Storage offers two options for copying your data to a secondary region: geo-redundant storage and geo-zone-redundant storage.||Diagram that shows locally redundant storage and zone-redundant storage replicated to the secondary region.||The primary difference between GRS and GZRS is how data is replicated in the primary region. Within the secondary region, data is always replicated synchronously with LRS.||If the primary region becomes unavailable, you can choose to fail over to the secondary region. After the failover completes, the secondary region becomes the primary region, and you can again read and write data.||Data is replicated to the secondary region asynchronously. A failure that affects the primary region might result in data loss if the primary region can't be recovered.||With GRS or GZRS, the data in the secondary region isn't available for read or write access unless there's a failover to the secondary region. For read access to the secondary region, configure your storage account to use read-access geo-redundant storage (RA-GRS) or read-access geo-zone-redundant storage (RA-GZRS).||Things to consider when using data redundancy|You review the different options for implementing replication. Data redundancy is accomplished through a primary region and paired secondary region. As you plan the storage accounts and redundancy settings for Tailwind Traders, consider the following factor.||Consider primary replication options. Explore different scenarios for how Tailwind Traders data can be replicated in the primary region. The redundancy options present tradeoffs between lower costs and higher availability. Some business centers can require more data redundancy. Specific departments or regions might work with data that's not sensitive or which doesn't require high durability. You can implement multiple storage accounts with different redundancy to control the overall costs across the organization.||Consider locally redundant storage. Implement LRS for a low cost redundancy solution, but with limited durability. LRS is suited for Tailwind Traders apps that store data that can be easily reconstructed if data loss occurs. LRS is also a good choice for apps that are restricted to replicating data only within a location due to data governance requirements.||Consider zone-redundant storage. Choose ZRS for excellent performance, low latency, and resiliency for your data if it becomes temporarily unavailable. Keep in mind that ZRS by itself might not protect your data against a regional disaster where multiple zones are permanently affected.||Consider secondary regions. For applications requiring high durability, you can choose to additionally copy the data in your storage account to a secondary region that is hundreds of miles away from the primary region. If your storage account is copied to a secondary region, then your data is durable even if a complete regional outage or a disaster in which the primary region isn't recoverable.||Consider read access requirements. Identify Tailwind Traders applications that require read access to the replicated data in the secondary region, if the primary region becomes unavailable for any reason. Configure your storage account with read access to the secondary region. Your applications can seamlessly shift to reading data from the secondary region if the primary region becomes unavailable.Design for Azure Blob Storage|Completed|100 XP|5 minutes|There are two main points to consider in an implementation plan for Azure Blob Storage. First, you need to identify which Azure blob access tier satisfies your organization's storage availability, latency, and cost requirements. The second consideration is to decide if you need access to immutable storage.||There are four access options: Hot, Cool, Cold, and Archive access tiers. All four options support availability and latency, but they have differing costs depending on the level of support. All options also support immutable storage, but the storage is implemented differently for the Hot, Cool, and Archive access tiers.||The four access options for Azure Blob Storage offer a range of features and support levels to help you optimize your storage costs.||Comparison	Hot access tier	Cool access tier	Cold access tier	Archive access tier|Availability	99.9%	99%	99%	99%|Availability (RA-GRS reads)	99.99%	99.9%	99.9%	99.9%|Latency (time to first byte)	milliseconds	milliseconds	milliseconds	hours|Minimum storage duration	N/A	30 days	90 days	180 days|Things to know about Azure blob access tiers|Think about your data sets, and which access options can satisfy the requirements for Tailwind Traders.||Hot tier|The Hot tier is optimized for frequent reads and writes of objects in the Azure storage account. A good usage case is data that is actively being processed. By default, new storage accounts are created in the Hot tier. This tier has the lowest access costs, but higher storage costs than the Cool and Archive tiers.||Cool tier|The Cool tier is optimized for storing large amounts of infrequently used data. This tier is intended for data that remains in the Cool tier for at least 30 days. A usage case for the Cool tier is short-term backup and disaster recovery datasets and older media content. This content shouldn't be viewed frequently, but it needs to be immediately available. Storing data in the Cool tier is more cost-effective. Accessing data in the Cool tier can be more expensive than accessing data in the Hot tier.||Cold tier|The Cold tier is also optimized for storing large amounts of infrequently used data. This tier is intended for data that can remain in the tier for at least 90 days.||Archive tier|The Archive tier is an offline tier that's optimized for data that can tolerate several hours of retrieval latency. Data must remain in the Archive tier for at least 180 days or be subject to an early deletion charge. Data for the Archive tier includes secondary backups, original raw data, and legally required compliance information. This tier is the most cost-effective option for storing data. Accessing data is more expensive in the Archive tier than accessing data in the other tiers.||Things to know about Azure Blob immutable storage|Immutable storage for Azure Blob Storage enables users to store business-critical data in a WORM (Write Once, Read Many) state. While in a WORM state, data can't be modified or deleted for a user-specified interval. By configuring immutability policies for blob data, you can protect your data from overwrites and deletes. Policies are applied at the container level and audit logs are available.||Diagram that shows policies applied at the container level.||Azure Blob Storage supports two forms of immutability policies for implementing immutable storage:||Time-based retention policies let users set policies to store data for a specified interval. When a time-based retention policy is in place, objects can be created and read, but not modified or deleted. After the retention period expires, objects can be deleted, but not overwritten. The Hot, Cool, and Archive access tiers support immutable storage by using time-retention policies.||Legal hold policies store immutable data until the legal hold is explicitly cleared. When a legal hold is set, objects can be created and read, but not modified or deleted. Premium Blob Storage uses legal holds to support immutable storage.||The following diagram shows how time-based retention policies and legal holds prevent write and delete operations.||Diagram shows time-based retention policies versus legal holds.||Things to consider when implementing Azure Blob Storage|You review the different access options for Azure Blob Storage, and how to use immutable storage. Take a few minutes to determine how you can configure Azure Blob Storage for Tailwind Traders.||Consider Blob Storage availability. Determine the level of availability required for your data. Are there scenarios where offline data is sufficient? The Archive access tier is optimized for data that can remain offline for hours.||Consider Blob Storage latency. Plan for the required time to access the first byte of data in different scenarios. Some work tasks require instant access to data, while others can accommodate some delay. Premium Blob Storage supports single-digit millisecond latency for data, while the Hot and Cool access tiers support latency in milliseconds.||Consider Blob Storage costs. Weigh your options for total cost. Factor in data storage minimum durations, and potential charges for transactions and access. Premium Blob Storage and the Hot access tier have higher overall storage costs, but lower charges for access and transactions. The Cool and Archive access tiers offer lower storage costs, but tend to have higher charges for access and transactions.||Consider immutable storage. Review your business scenarios to identify where you might need immutable storage. Consider the different types immutability policies and which form satisfies your organization's requirements.Design for Azure Files|Completed|100 XP|5 minutes|Azure Files provides fully managed cloud-based file shares that are hosted on Azure. Shared files are accessible by using the industry standard Server Message Block (SMB) protocol, Network File System (NFS) protocol, and the Azure Files REST API. You can mount or connect to an Azure file share at the same time on all the main operating systems.||Diagram that shows an Azure storage account, Azure Files and file shares, directories, and files.||Things to know about Azure Files|Azure Files can be used to add to or replace a company's existing on-premises network attached storage (NAS) devices or file servers. Here are some reasons why your organization might want to use Azure Files:||Developers can store apps and configuration files in a file share and connect new VMs to the shared files. This action reduces the time to get new machines into production.||With file shares on Azure, a company doesn't need to buy and deploy expensive redundant hardware and manage software updates. The shares are cross-platform, and you can connect to them from Windows, Linux, or macOS.||Your file share has all the resilence of the Azure platform, which makes files globally redundant. You also gain options to use the integrated snapshots feature, and set up automatic backups by using Recovery Services vaults.||All the data is encrypted in transit by using HTTPS and is stored encrypted when at rest.||Choose your data access method|To move your company's shared files into Azure Files, you need to analyze your options and make an important decision. How are you going to access and update the files? You could replace your existing Server Message Block (SMB) file shares with their equivalent in Azure Files. Another option is to set up an instance of Azure File Sync. If you choose to use Azure File Sync, there's more flexibility on how files are secured and accessed.||Azure file shares can be used in two ways. You can directly mount serverless Azure file shares (SMB) or cache Azure file shares on-premises by using Azure File Sync.||Direct mount of Azure file shares: Because Azure Files provides SMB access, you can mount Azure file shares on-premises or in the cloud. Mounting uses the standard SMB client available in Windows, macOS, and Linux. Because Azure file shares are serverless, deploying for production scenarios doesn't require managing a file server or NAS device. Direct mounting means you don't have to apply software patches or swap out physical disks.||Cache Azure file shares on-premises with Azure File Sync: Azure File Sync lets you centralize your organization's file shares. Azure Files provides the flexibility, performance, and compatibility of an on-premises file server. Azure File Sync transforms an on-premises (or cloud) Windows Server into a quick cache of your Azure file share.||Choose your performance level|Because Azure Files stores files in a storage account, you can choose your performance level. Performance metrics differ between standard and premium storage account levels. Premium accounts offer lower latency and higher IOPS and bandwidth.||Standard performance accounts use HDD to store data. With HDD, the costs are lower but so is the performance. SSD arrays back the premium storage account's performance, which comes with higher costs. Currently, premium accounts can only use file storage accounts with ZRS storage in a limited number of regions.||Determine your storage tier|Azure Files offers four tiers of storage. These tiers allow you to tailor your file shares to meet the performance and price requirements for your scenarios.||Premium: File shares use solid-state drives (SSDs) and provide consistent high performance and low latency. Used for the most intensive IO workloads. Suitable workloads include databases, web site hosting, and development environments. Can be used with both Server Message Block (SMB) and Network File System (NFS) protocols.||Transaction optimized: Used for transaction heavy workloads that don't need the latency offered by premium file shares. File shares are offered on the standard storage hardware backed by hard disk drives (HDDs).||Hot access tier: Storage optimized for general purpose file sharing scenarios such as team shares. Offered on standard storage hardware using HDDs.||Cool access tier: Cost-efficient storage optimized for online archive storage scenarios. Offered on storage hardware using HDDs.||Things to consider when choosing your implementation|Your decision about which technology to implement depends on your business use cases, the protocols required for your files, and your performance goals. We review considerations for using Azure Blob Storage and Azure Files. Another option is to use Azure NetApp Files, which is a fully managed, highly available, enterprise-grade NAS service. Azure NetApp Files can handle the most demanding, high-performance, low-latency workloads. You can migrate workloads that are deemed "unmigratable."||The following table compares features and uses cases for these three implementation options. Consider how you might implement Azure Blob Storage or Azure NetApp Files instead of Azure Files storage for Tailwind Traders.||Comparison	Azure Blob Storage	Azure Files	Azure NetApp Files|Description	Azure Blob Storage is best suited for large scale read-heavy sequential access workloads where data is ingested once and modified later.||Blob Storage offers the lowest total cost of ownership, if there's little or no maintenance.	Azure Files is a highly available service best suited for random access workloads.||For NFS shares, Azure Files provides full POSIX file system support and can easily be used from container platforms like Azure Container Instance (ACI) and Azure Kubernetes Service (AKS).	Azure NetApp Files is a fully managed file service in the cloud, powered by NetApp, with advanced management capabilities.||Azure NetApp Files is suited for workloads that require random access and provides broad protocol support and data protection capabilities.|Use cases	Large scale analytical data, Throughput sensitive high-performance computing, Backup and archive, Autonomous driving, Media rendering, or Genomic sequencing	Shared files, Databases, Home directories, Traditional applications, ERP, CMS, NAS migrations that don't require advanced management, Custom applications that require scale-out file storage	On-premises enterprise NAS migration that requires rich management capabilities, Latency sensitive workloads like SAP HANA, Latency-sensitive or IOPS intensive high performance compute, Workloads that require simultaneous multi-protocol access|Available protocols	- NFS 3.0|- REST|- Data Lake Storage Gen2	- SMB|- NFS 4.1|- REST	- NFS 3.0 and 4.1|- SMB|Performance (per volume)	Up to 20,000 IOPS. Up to 15 GiB/s throughput.	Up to 100,000 IOPS. Up to 10 GiB/s throughput	Up to 460,000 IOPS. Up to 4.5 GiB/s throughput for regular volumes. Up to 10 GiB/s throughput for large volumes.Design for Azure managed disks|Completed|100 XP|3 minutes|Azure offers many disk solutions. In this module, we examine how to work with data disks by using Azure managed disks.||Data disks are used by virtual machines to store data like database files, website static content, or custom application code. The number of data disks you can add depends on the virtual machine size. Each data disk has a maximum capacity of 32,767 GB.|| Tip||Microsoft recommends always using Azure managed disks. You specify the disk size, the disk type, and provision the disk. Azure handles the remaining operations.||Things to know about managed disks|Azure offers several types of managed disks. The following table shows a comparison of four data disk types.||Comparison	Ultra-disk	Premium SSD	Standard SSD	Standard HDD|Disk type	SSD	SSD	SSD	HDD|Scenario	IO-intensive workloads, such as SAP HANA, top tier databases like SQL Server and Oracle, and other transaction-heavy workloads	Production and performance sensitive workloads	Web servers, Lightly used enterprise applications, Development and testing	Backup, Noncritical, Infrequent access|Max throughput	2,000 Mbps	900 Mbps	750 Mbps	500 Mbps|Max IOPS	160,000	20,000	6,000	2,000|Choose an encryption option|There are several encryption types available for your managed disks.||Azure Disk Encryption (ADE) encrypts the VM's virtual hard disks (VHDs). If VHD is protected with ADE, the disk image is accessible only by the VM that owns the disk.||Server-Side Encryption (SSE) is performed on the physical disks in the data center. If someone directly accesses the physical disk, the data is encrypted. When the data is accessed from the disk, it's decrypted and loaded into memory. This form of encryption is also referred to as encryption at rest or Azure Storage encryption.||Encryption at host ensures that data stored on the VM host is encrypted at rest and flows encrypted to the Storage service. Disks with encryption at host enabled aren't encrypted with SSE. Instead, the server hosting your VM provides the encryption for your data, and that encrypted data flows into Azure Storage.||Things to consider when using managed disks|Think about what data disk types are needed for Tailwind Traders. Consider your scenarios, throughput, and IOPS.||Consider your scenarios, throughput, and IOPS. Compare disk types and choose the data disks that satisfy your business scenarios, and throughput and IOPS requirements. For more information, see Select a disk type for Azure IaaS VMs - managed disks||Ultra-disk storage: Azure Ultra Disk storage provides the best performance. Choose this option when you need the fastest storage performance in addition to high throughput, high input/output operations per second (IOPS), and low latency. Ultra-disk storage might not be available in all regions.||Premium SSD storage: Azure Premium SSD-managed disks provide high throughput and IOPS with low latency. These disks offer a slightly less performance compared to Ultra Disk Storage. Premium SSD storage is available in all regions.||Standard SSD: Azure Standard SSD-managed disks are a cost-effective storage option for VMs that need consistent performance at lower speeds. Standard SSD disks aren't as fast as Premium SSD disks or Ultra Disk Storage. You can attach Standard SSD disks to any VM.||Standard HDD: In Azure Standard HDD-managed disks, data is stored on conventional magnetic disk drives that have moving spindles. Disks are slower and the variation in speeds is higher compared to solid-state drives (SSDs). Like Standard SSD disks, you can use Standard HDD disks for any VM.||Consider data caching. Improve performance with disk caching. Azure Virtual Machines disk caching optimizes read and write access to the virtual hard disk (VHD) files. The VHDs are attached to Azure Virtual Machines. For OS disks, the default cache setting is ReadWrite, and for data disks, the default is ReadOnly.|| Warning||Disk caching isn't supported for disks 4 TiB and larger. When multiple disks are attached to your Virtual Machine, each disk smaller than 4 TiB supports caching. Changing the cache setting of an Azure disk, detaches and reattaches the target disk. When it's the OS disk, the VM is restarted.||Consider using encryption. Secure your data disks with encryption. To fully protect your data disks, combine encryption services: ADE, SSE, and encryption at rest.Design for storage security|Completed|100 XP|5 minutes|Azure Storage provides a layered security model that lets you secure and control the level of access to your storage accounts. The model consists of several storage security options, including firewall policies, customer-managed keys, and endpoints.||Diagram that shows storage security options, including firewall policies, customer-managed keys, and endpoints.||Things to know about storage security|Let's take a look at some best practices for storage security. Think about options can be used for the Tailwind Traders infrastructure.||Azure security baseline for Azure Storage grants limited access to Azure Storage resources. Azure security baseline provides a comprehensive list of ways to secure your Azure storage.||Shared access signatures provide secure delegated access to resources in your storage account. With a SAS, you have granular control over how a client can access your data.||Firewall policies and rules limit access to your storage account. Requests can be limited to specific IP addresses or ranges, or to a list of subnets in an Azure virtual network. The Azure Storage firewall provides access control for the public endpoint of your storage account.||Virtual network service endpoints restrict network access and provide direct connection to your Azure storage. You can secure storage accounts to your virtual network, and enable private IP addresses in the virtual network to reach the service endpoint. With private endpoints, you can create a special network interface for an Azure service in your virtual network.||Secure transfer enables an Azure storage account to accept requests from secure connections. When you require secure transfer, any requests originating from nonsecure connections are rejected. Microsoft recommends that you always require secure transfer for all your storage accounts.||Data in your storage account is automatically encrypted. Azure Storage encryption offers two ways to manage encryption keys at the storage account level:||Microsoft-managed keys: By default, Microsoft manages the keys used to encrypt your storage account.||Customer-managed keys: You can optionally choose to manage encryption keys for your storage account. Customer-managed keys must be stored in Azure Key Vault.||Things to consider when implementing storage security|You review some of the security options for Azure Storage. Take a few minutes to determine how you can configure security for Tailwind Traders.||Consider Azure security baseline options. Review the comprehensive options provided by Azure security baseline provides to secure your Azure storage. Grant limited access to Azure Storage resources.||Consider shared access signatures. Specify what Tailwind Traders resources clients can access. Define the access permissions for resources. Configure how long the SAS remains valid.||Consider firewall policies and rules. Limit requests to IP addresses or subnets in an Azure virtual network. Use the Azure Storage firewall to block all access through the public endpoint when using private endpoints. Select trusted Azure platform services to access the storage account securely.||Consider service endpoints. Secure Azure storage accounts to your virtual networks by using service endpoints. You can provide optimal routing by always keeping traffic destined to Azure Storage on the Azure backbone network. Enable private IP addresses in the virtual network to reach the service endpoint without requiring a public IP address. Allow on-premises networks to access resources by using NAT IP addresses.||Diagram of a virtual machine that uses an endpoint to access an Azure storage account.||Consider private endpoints. Add private endpoints to create a special network interface for an Azure service in your virtual network. When you implement a private endpoint for your storage account, it provides secure connectivity between clients on your virtual network and your storage.||Diagram of a private endpoint that uses a private link to Azure storage accounts.||Consider secure transfer. (Microsoft recommended) Always require secure transfer for all your Azure storage accounts. In the Azure portal, choose Enable secure transfer for your storage accounts. The Secure transfer required property is enabled by default when an Azure storage account is created.||Consider customer-managed keys. Manage encryption keys for your storage account by using customer-managed keys stored in Azure Key Vault. Customer-managed keys give you full control over access to your encryption keys and encrypted data.<Knowledge check|Completed|200 XP|4 minutes|Tailwind Traders wants to reduce storage costs by reducing duplicate content and migrating it to the cloud, when possible. The company is interested in a solution that centralizes maintenance while providing nation-wide access for customers. Customers should be able to browse and purchase items online even an entire Azure region goes offline. Here are some specific requirements:||Warranty document retention. The Compliance and Legal teams require warranty documents be kept for three years.||New photos and videos. Each product has an accompanying photo or video to demonstrate the product.||External vendor development. A vendor creates and develops some of the online e-commerce features. The developer needs access to the HTML files, but only during the development phase.||Product catalog updates. The product catalog is updated every few months. Older versions of the catalog aren't viewed frequently, but they must be available immediately, if accessed.||Answer the following questions|Choose the best response for each of the questions. Then select Check your answers.|||1. What's the best way for Tailwind Traders to protect their warranty information? ||Legal hold policy||Time-based retention policy|Correct. With a time-based retention policy, users can set policies to store data for a specified interval. When a time-based retention policy is in place, objects can be created and read, but not modified or deleted.|||Private endpoint for storage account|2. Which storage option should Tailwind Traders use for their photos and videos? ||Blob Storage|Correct. Blob Storage is best for storing photos.|||Azure Files||Disk storage|3. How can you provide your developers with access to the business e-commerce HTML files? ||Enable secure transfer||Enable firewall policies and rules|Incorrect. Firewall policies and rules are for network access.|||Shared access signatures|Correct. Shared access signatures (SAS) provide secure delegated access. This functionality can be used to define permissions, and how long access is allowed.||4. Which access tier should be used for the older versions of the product catalog? ||Hot access tier||Cool access tier|Correct. The Cool access tier is for content that isn't viewed frequently, but must be available immediately, if accessed.|||Archive access tier|Incorrect. The older catalogs are still accessed, although infrequently. In the Archive access tier, you can incur an early deletion charge, if data is accessed sooner than 180 days.>Summary and resources|Completed|100 XP|1 minute|In this module, you learned how to design for unstructured nonrelational data. You compared the features of different types of Azure storage accounts and Storage access tiers. You explored scenarios for using Azure Blob Storage, Azure managed disks, Azure Files, and Azure NetApp Files. You reviewed how to implement support for data redundancy, and examined options for storage security, including customer-managed encryption keys, and secure transfer.||Learn more with Azure documentation|Read an introduction to Azure Storage.||Review Azure Storage options.||Examine Azure disk storage options.||Configure Azure security baseline for Azure Storage.||Discover more about Azure Blob Storage.||Explore more about Azure Files.||Read more about Azure NetApp Files.||Learn more with self-paced training|Choose the right disk storage for your virtual machine workload.||Configure Azure Blob Storage.||Optimize performance and costs by using Azure disk storage.||Get an introduction to securing data at rest on Azure.||Choose a data storage approach in Azure.||Learn more with optional hands-on exercises|Create a storage account by using the Azure portal (sandbox).||Manage caching and performance in Azure Storage disks (sandbox).||Secure your Azure Virtual Machines disks (sandbox).]}