2 . Plan the Resource Group model that will be used (heterogeneous vs.
homogeneous) and the role-based access control used. Create the Resource
Groups.
3 . Create virtual networks in the regions required in the pre-created Resource
Groups.
4 . Create storage accounts in the regions required in the pre-created Resource
Groups with the desired resiliency option configured.
5 . Agree on how resources in Azure will be accessed. Will a site-to-site VPN or
ExpressRoute be used for access to VMs via their private IP addresses? For
services published to the Internet, will Public IPs be assigned directly to VMs or to
a load balancer that can use forwarding rules to VMs?
6 . Create virtual machines using the existing resource groups, virtual networks, and
storage accounts.
7 . How will services be provisioned by normal users? Will I leverage PowerShell or
JSON templates with an existing service catalog to provide a single portal for all
types of requests?
8 . How will services in Azure be backed up? Services such as Azure Backup can be
leveraged and replicated to other regions.
There are other considerations, but I consider these to be the absolute key minimums
in order to get running. Note that after you create resources, you cannot just move
them between regions. You would need to export out the resources and import them
into the new region, so pick your regions carefully when creating new services.
Notice at the top of the Microsoft Azure management portal is a status bar that has
the actions related to configuration of the portal experience, such as customizing tiles,
changing the theme, and modifying the subscriptions that will have objects shown in
the portal if your account has access to multiple subscriptions. There is also a bell
icon, which shows any current actions being performed. Click the icon to get details
such as those shown in Figure 12.9. Some of the notifications can be dismissed, and
others will show more details via an information icon.