Diagram 1:
Azure subscriptions are a grouping of resources with an assigned owner responsible for billing and permissions management. Unlike AWS, where any resources created under the AWS account are tied to that account, subscriptions exist independently of their owner accounts, and can be reassigned to new owners as needed.
Account Administrator. The subscription owner and the billing owner for the resources used in the subscription. The account administrator can only be changed by transferring ownership of the subscription. Only one Account administrator is assigned per Azure Account.
Service Administrator. This user has rights to create and manage resources in the subscription, but is not responsible for billing. By default, for a new subscription, the Account Administrator is also the Service Administrator. The account administrator can assign a separate user to the service administrator for managing the technical and operational aspects of a subscription. Only one service administrator is assigned per subscription.
Co-administrator. There can be multiple co-administrators assigned to a subscription. Co-administrators have the same access privileges as the Service Administrator, but they cannot change the service administrator.
Link: https://docs.microsoft.com/en-us/azure/architecture/aws-professional/accounts
1. Workload separation strategy:
An organization often adds new workloads to the cloud. Different ownership of subscriptions or basic separation of responsibility might result in multiple subscriptions in both the production and nonproduction management groups. This approach provides basic workload separation. But it doesn't take good advantage of the inheritance model to automatically apply policies across a subset of your subscriptions.
-
Application category strategy:
As an organization's cloud footprint grows, more subscriptions are typically created to support applications. These applications have fundamental differences in business criticality, compliance requirements, access controls, or data protection needs. Built from the initial production and nonproduction subscriptions, the subscriptions that support these application categories are organized under either the production or nonproduction management group as applicable. These subscriptions are typically owned and administered by the operations staff of a central IT team.
Each organization categorizes their applications differently. They often separate subscriptions based on specific applications or services, or by application archetypes. This categorization is designed to support workloads that are likely to consume most of the resource limits of a subscription. It might also separate mission-critical workloads to ensure they don't compete with other workloads under these limits. Some workloads that might justify a separate subscription include:- Mission-critical workloads.
- Applications that are part of cost of goods sold (COGS) within your company. For example, every widget manufactured by a company contains an Azure IoT module that sends telemetry. This process might require a dedicated subscription for accounting or governance purposes to be part of COGS.
- Applications subject to regulatory requirements like HIPAA or FedRAMP.
-
Mix Subscription Strategies:
Management group hierarchies can be up to six levels deep. This depth gives you the flexibility to create a hierarchy that combines several of these strategies to meet your organizational needs. For example, the following diagram shows an organizational hierarchy that combines a business unit strategy with a geographic strategy.
Link: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/decision-guides/subscriptions/
When you define your management group hierarchy, first create the root management group. Then move all existing subscriptions in the directory into the root management group. New subscriptions always go into the root management group initially. Later, you can move them to another management group.
What happens when you move a subscription to an existing management group? The subscription inherits the policies and role assignments from the management group hierarchy above it. Establish many subscriptions for your Azure workloads. Then create other subscriptions to contain Azure services that other subscriptions share.
Link: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions
Access by management group:
Another scenario where you would use management groups is to provide user access to multiple subscriptions. By moving multiple subscriptions under that management group, you can create one Azure role assignment on the management group, which will inherit that access to all the subscriptions. One assignment on the management group can enable users to have access to everything they need instead of scripting Azure RBAC over different subscriptions.
Each directory is given a single top-level management group called the root management group. The root management group is built into the hierarchy to have all management groups and subscriptions fold up to it. This root management group allows for global policies and Azure role assignments to be applied at the directory level. The Azure AD Global Administrator needs to elevate themselves to the User Access Administrator role of this root group initially. After elevating access, the administrator can assign any Azure role to other directory users or groups to manage the hierarchy. As administrator, you can assign your own account as owner of the root management group.
Restrictions:
Management groups can support 6 levels of depth (not including root level or subscription level). Each management group and subscription can only support one parent.
Azure custom role support for management groups is currently in preview with some limitations. You can define the management group scope in the Role Definition's assignable scope. That Azure custom role will then be available for assignment on that management group and any management group, subscription, resource group, or resource under it. This custom role will inherit down the hierarchy like any built-in role.
Link: https://docs.microsoft.com/en-us/azure/governance/management-groups/overview
Subscription best practices tutorial: https://www.youtube.com/watch?v=LMAC0IIYSJM
- AWS EC2 == Azure VM
- AWS EBS == Azure Storage for VM Disks
- AWS Lambda == Azure Functions, Azure Web-Jobs, and Azure Logic Apps
- AWS Autoscaling == Azure VM scaling, and Azure App Service Autoscale
- AWS EKS == Azure Kubernetes Service
- AWS AppMesh == Azure Service Fabric
- AWS ECS == Azure Container Instances
Link: https://docs.microsoft.com/en-us/azure/architecture/aws-professional/compute
- AWS RDS == SQL Database, Azure Database for MySQL, Azure Database for PostgreSQL, Azure Database for MariaDB
- AWS Aurora == Azure SQL Database (https://docs.microsoft.com/en-us/azure/azure-sql/database/serverless-tier-overview?view=azuresql)
- AWS DynamoDB / Amazon DocumentDB == Cosmos DB
- AWS ElastiCache == Cache for Redis
- AWS ELB == Azure Load Balancer
- AWS ALB == Azure Application Gateway
- AWS Route53 == Azure DNS + Azure Traffic Manager
- AWS DirectConnect == Azure ExpressRoute
- AWS Route Tables == Azure User-Defined Routes
- AWS Private Link == Azure Private Link
- AWS VPC Peering == Azure VNet Peering
- AWS CloudFront == Azure CDN
- AWS VPC == Azure Virtual Network (VNet)
- AWS NAT Gateway == Azure Virtual Network NAT
- AWS VPN Gateway == Azure VPN Gateway
- AWS VPC Endpoint == Azure Private Endpoint
- AWS VPC Flow Logs == Azure Network Watcher
Diagram 2:
In Azure, a region is divided into two or more Availability Zones. An Availability Zone corresponds with a physically isolated datacenter in the geographic region. Azure has numerous features for providing application redundancy at every level of potential failure, including availability sets, availability zones, and paired regions.
Availability Set Availability Zone Paired region
Scope of failure Rack Datacenter Region
Request routing Load Balancer Cross-zone Load Balancer Traffic Manager
Network latency Very low Low Mid to high
Virtual networking VNet VNet Cross-region VNet peering
- AWS SES does not have an Azure equivalent, you need a third party solution. (e.g. SendGrid)
- AWS SQS == Azure Queue Storage
- AWS SNS == Azure Service Bus
- AWS EventBridge == Azure Event Grid
- AWS Kinesis == Event Hubs
The term "resource" in Azure is used in the same way as in AWS, meaning any compute instance, storage object, networking device, or other entity you can create or configure within the platform.
Both Azure and AWS have entities called "resource groups" that organize resources such as VMs, storage, and virtual networking devices. However, Azure resource groups are not directly comparable to AWS resource groups.
While AWS allows a resource to be tagged into multiple resource groups, an Azure resource is always associated with one resource group. A resource created in one resource group can be moved to another group, but can only be in one resource group at a time. Resource groups are the fundamental grouping used by Azure Resource Manager.
Resources can also be organized using tags. Tags are key-value pairs that allow you to group resources across your subscription irrespective of resource group membership.
Resources can be managed in these ways:
- Web interface
- API
- Command Line
- PowerShell
- Templates
Azure naming tool: https://github.com/microsoft/CloudAdoptionFramework/tree/master/ready/AzNamingTool
- AWS S3 == Azure Blob Storage
- AWS EBS == Azure Managed Disks
- AWS EFS == Azure Files
- AWS S3 Infrequent Access == Azure Storage Cool Tier
- AWS S3 Glacier == Azure Storage Archive access tier
- AWS Backup == Azure Backup
- AWS Storage Gateway == Azure StorSimple
- AWS DataSync == Azure File Sync
Azure AD Elevated Access:
When you elevate your access, you will be assigned the User Access Administrator role in Azure at root scope (/). This allows you to view all resources and assign access in any subscription or management group in the directory. User Access Administrator role assignments can be removed using Azure PowerShell, Azure CLI, or the REST API.
Azure AD Elevated Access using Azure CLI:
az rest --method post --url "/providers/Microsoft.Authorization/elevateAccess?api-version=2016-07-01"
Link: https://docs.microsoft.com/en-us/azure/role-based-access-control/elevate-access-global-admin
Azure RBAC vs. AD:
While RBAC roles are used to manage access to Azure resources like VMs and storage accounts, Azure AD Administrator roles are used to manage Azure AD resources in a directory.
Basic Tutorial: https://www.youtube.com/watch?v=AtAb_8Av4iU
More In-Depth Tutorial: https://www.youtube.com/watch?v=Ma7VAQE7ga4 (Useful times: 9:19-20:23 && 22:59-27:42)
Using tags for billing/cost calculating:
The API now supports cost management based on tags. "Today, filters support resource groups, instances and meters and with this release will also include tags. Scoping a budget to a tag or a set of tags will continue to leverage filters."
Group by common properties to break down costs and identify top contributors. To group by resource tags, for example, select the tag key you want to group by. Costs are broken down by each tag value, with an extra segment for resources that don't have that tag applied.
Links:
https://azure.microsoft.com/en-us/blog/announcing-the-support-for-tags-in-cost-management-apis/
https://docs.microsoft.com/en-us/azure/cost-management-billing/costs/quick-acm-cost-analysis
Scope is the set of resources that the access applies to. When you assign a role, you can further limit the actions allowed by defining a scope. This is helpful if you want to make someone a Website Contributor, but only for one resource group.
In Azure, you can specify a scope at four levels: management group, subscription, resource group, or resource. Scopes are structured in a parent-child relationship. You can assign roles at any of these levels of scope.
A role definition is a collection of permissions. It's typically just called a role. A role definition lists the actions that can be performed, such as read, write, and delete. Roles can be high-level, like owner, or specific, like virtual machine reader.
A role assignment is the process of attaching a role definition to a user, group, service principal, or managed identity at a particular scope for the purpose of granting access. Access is granted by creating a role assignment, and access is revoked by removing a role assignment.
The following diagram shows an example of a role assignment. In this example, the Marketing group has been assigned the Contributor role for the pharma-sales resource group. This means that users in the Marketing group can create or manage any Azure resource in the pharma-sales resource group. Marketing users do not have access to resources outside the pharma-sales resource group, unless they are part of another role assignment.
Role assignments are transitive for groups which means that if a user is a member of a group and that group is a member of another group that has a role assignment, the user will have the permissions in the role assignment.
RBAC is an additive model, so therefore if a user has multiple role assignments they gain permissions from all of them.
Azure RBAC supports deny assignments in a limited way. Deny assignments block users from performing specified actions even if a role assignment grants them access. Deny assignments take precedence over role assignments.
Link: https://docs.microsoft.com/en-us/azure/role-based-access-control/overview
NOT the same thing as RBAC. Differences include:
There are a few key differences between Azure Policy and Azure role-based access control (Azure RBAC). Azure Policy evaluates state by examining properties on resources that are represented in Resource Manager and properties of some Resource Providers. Azure Policy doesn't restrict actions (also called operations). Azure Policy ensures that resource state is compliant to your business rules without concern for who made the change or who has permission to make a change. Some Azure Policy resources, such as policy definitions, initiative definitions, and assignments, are visible to all users. This design enables transparency to all users and services for what policy rules are set in their environment.
Azure RBAC focuses on managing user actions at different scopes. If control of an action is required, then Azure RBAC is the correct tool to use. Even if an individual has access to perform an action, if the result is a non-compliant resource, Azure Policy still blocks the create or update.
The combination of Azure RBAC and Azure Policy provides full scope control in Azure.
Azure RBAC Permissions in Azure Policy:
Azure Policy has several permissions, known as operations, in two Resource Providers:
Microsoft.Authorization
Microsoft.PolicyInsights
Many built-in roles grant permission to Azure Policy resources. The Resource Policy Contributor role includes most Azure Policy operations. Owner has full rights. Both Contributor and Reader have access to all read Azure Policy operations.
Link: https://docs.microsoft.com/en-us/azure/governance/policy/overview
Rollback:
Deployments 'states' are saved upon deployment by name. This allows you to rollback to a specific state by name in case of a faulty deployment.
Link: https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/rollback-on-error
Teardown:
Teardown consists of deleting the resource group.