Azure

Landing Zone - Considerations

Developing an inventory is the first step in digital estate planning. In this process, a list of IT assets that support specific business functions are collected for later analysis and rationalization

The complete rationalization of a large digital estate is prone to risk and can suffer delays because of its complexity. The assumption behind the incremental approach is that delayed decisions stagger the load on the business to reduce the risk of roadblocks.

Accurate rationalization requires a deep knowledge of the workload and associated assets (apps, VMs, and data). Most importantly, accurate rationalization decisions take time. We recommend using an incremental rationalization process.

Rationalizing an entire IT portfolio or even a single datacenter can delay the realization of business value by months or even years. Full rationalization should be avoided when possible. Instead, use the power of 10 approach to release planning to make wise decisions about the next 10 workloads that are slated for cloud adoption.

To develop a business justification for a cloud adoption effort, make a few basic assumptions at the portfolio level. When motivations are aligned to innovation, assume rearchitecture. When motivations are aligned to migration, assume rehost. These assumptions can accelerate the business justification process. Assumptions are then challenged and budgets refined during the assessment phase of each workload's adoption cycles.

tag - rehost , paas or re architecting projects 

Platform as a service (PaaS) options can reduce the operational costs that are associated with many applications. It's a good idea to slightly refactor an application to fit a PaaS-based model.

Some aging applications aren't compatible with cloud providers because of the architectural decisions that were made when the application was built. In these cases, the application might need to be rearchitected before transformation.

Sometimes software as a service (SaaS) applications can provide all the necessary functionality for the hosted application. In these scenarios, a workload can be scheduled for future replacement, effectively removing it from the transformation effort.

We can apply these rationalization techniques to a digital estate to help us  make rationalization decisions about the migration phase  of each application.

Select the first workload

a workload that has minimum dependencies and can be moved as a small group of assets. We recommend that you select a workload with a defined testing path to make validation easier.

    What person (or group of people) will be responsible for completing technical tasks in the cloud adoption plan?

    What person will be accountable for the team's ability to deliver technical changes?

    What person (or group of people) will be responsible for implementing protective governance mechanisms?

    What person will be accountable for the defining those governance controls?

    Are there other capabilities or people that will have accountability or responsibility within the cloud adoption plan?

Aligning efforts to iterations and releases requires an understanding of velocity. Velocity is the amount of work that can be completed in any given iteration. During early planning, velocity is an estimate. After several iterations, velocity becomes a highly valuable indicator of the commitments that the team can make confidently

Organizing your cloud-based resources is critical to securing, managing, and tracking the costs related to your workloads. To organize your resources, use the management hierarchies within the Azure platform, implement well-thought-out naming conventions, and apply resource tagging

Azure provides four levels of management scope: management groups, subscriptions, resource groups, and resources. The following image shows the relationship of these levels.

Management groups: These groups are containers that help you manage access, policy, and compliance for multiple subscriptions. All subscriptions in a management group automatically inherit the conditions applied to the management group.

    Subscriptions: A subscription groups together user accounts and the resources that were created by those user accounts. Each subscription has limits or quotas on the amount of resources you can create and use. Organizations can use subscriptions to manage costs and the resources that are created by users, teams, or projects.

    Resource groups: A resource group is a logical container into which Azure resources like web apps, databases, and storage accounts are deployed and managed.

    Resources: Resources are instances of services that you create, like virtual machines, storage, or SQL databases.

You can apply management settings, like policies and role-based access controls, at any of the management levels. The level you select determines how widely the setting is applied

 if you have many subscriptions, you should consider creating a management-group hierarchy to simplify managing your subscriptions and resources.

Management groups allow efficient management of access, policies, and compliance for an organization's subscriptions. Each management group is a container for one or more subscriptions.

you define this hierarchy in your Azure Active Directory (Azure AD) tenant to align with your organization's structure and needs. The top level is called the root management group. You can define up to six levels of management groups in your hierarchy. Each subscription is contained by only one management group.

https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-setup-guide/organize-resources?tabs=AzureManagmentGroupsAndHierarchy

Create a management group

Create a management group to help you manage access, policy, and compliance for multiple subscriptions.

The private IP address spaces available are in the Class A (10.0.0.0/8), Class B (172.16.0.0/12), and Class C (192.168.0.0/16) ranges.

Best practice: Don’t assign allow rules with broad ranges

Best practice: Segment the larger address space into subnets.

Best practice: Avoid small virtual networks and subnets to ensure simplicity and flexibility.

Best practice: Simplify network security group rule management by defining Application Security Groups.

Adopt a Zero Trust approach

Perimeter-based networks operate on the assumption that all systems within a network can be trusted. But today’s employees access their organization’s resources from anywhere on a variety of devices and apps, which makes perimeter security controls irrelevant. Access control policies that focus only on who can access a resource are not enough. To master the balance between security and productivity, security admins also need to factor in how a resource is being accessed.

Zero Trust networks eliminate the concept of trust based on network location within a perimeter.

Zero Trust architectures

Best practice: Give Conditional Access to resources based on device, identity, assurance, network location, and more.

Detail: Azure AD Conditional Access lets you apply the right access controls by implementing automated access control decisions based on the required conditions

Best practice: Enable port access only after workflow approval.

Best practice: Grant temporary permissions to perform privileged tasks, which prevents malicious or unauthorized users from gaining access after the permissions have expired. Access is granted only when users need it.

Zero Trust is the next evolution in network security. 

A perimeter network (also known as a DMZ) is a physical or logical network segment that provides an additional layer of security between your assets and the internet. Specialized network access control devices on the edge of a perimeter network allow only desired traffic into your virtual network.

Perimeter networks are useful because you can focus your network access control management, monitoring, logging, and reporting on the devices at the edge of your Azure virtual network. A perimeter network is where you typically enable distributed denial of service (DDoS) prevention, intrusion detection/intrusion prevention systems (IDS/IPS), firewall rules and policies, web filtering, network antimalware, and more. The network security devices sit between the internet and your Azure virtual network and have an interface on both networks.

Although this is the basic design of a perimeter network, there are many different designs, like back-to-back, tri-homed, and multi-homed.

Based on the Zero Trust concept mentioned earlier, we recommend that you consider using a perimeter network for all high security deployments to enhance the level of network security and access control for your Azure resources.