What are the differences between IAM and Enterprise Management?
Identity and Access Management (IAM) is an identity management service that provides identity authentication, permission assignment, access control, and other related functions.
Enterprise Management is a cloud resource management service designed for enterprise customers, aligning with multi-level organizational and project structures. It primarily includes enterprise project resource management and permission management.
Similar to IAM, Enterprise Management enables personnel management and permission assignment. However, it offers more granular resource authorization compared to IAM and is a better choice for medium and large enterprises.
Differences between IAM and Enterprise Management
l Enabling Method
IAM is an identity management service on the cloud platform. After system registration, it can be used free of charge without additional payment.
Enterprise Management is a resource management service on the cloud platform. After system registration, you need to submit a customer service ticket to request activation. Once enabled, it is free to use at no cost.
Resource Isolation
n IAM isolates resources across different regions by creating projects within each region. Authorization is performed on a per-project basis, allowing users to access all resources within a designated project.
n Enterprise Management allows you to create multiple enterprise projects in a region for resource isolation. An enterprise project can contain resources from multiple regions and enables authorization for a specific resource. For example, you can add an ECS to an enterprise project, and assign permissions to a user for managing the ECS in the project instead of other ECSs.
Relationship between IAM and Enterprise Management
l The user and user group creation functions in IAM and Enterprise Management are synchronized with each other.
l After applying to enable the Enterprise Management service, when using the user group authorization feature in Enterprise Management, this function relies on IAM's policy authorization. If the system-preset policies in Enterprise Management fail to meet your requirements, you need to create a custom policy in IAM. The custom policy will be synchronized to Enterprise Management, and you can then authorize user groups with the custom policy either in IAM or Enterprise Management.
l If a user group is authorized in both IAM and Enterprise Management, the user will possess both IAM project-based policies and enterprise project-based policies. When initiating an access request, the system performs authorization checks based on the Actions defined in the user's authorized access policies.
n If a policy contains the same Action, the effect set in IAM will prevail. For example, when a user requests to create an ECS, if the authorization result is Deny as defined in IAM, the ECS cannot be created.
IAM project strategy includes the following actions:
{
"Action": [
"ecs:cloudServers:create"
],
"Effect": "Deny"
}
Enterprise project strategy includes the following actions：
{
"Action": [
"ecs:cloudServers:create"
],
"Effect": "Allow"
}
n If the policy contains different Actions, both the settings in IAM and Enterprise Management take effect. The following example indicates that the user can create and delete ECSs.
IAM project strategy includes the following actions：
{
"Action": [
"ecs:cloudServers:create"
],
"Effect": "Allow"
}
Enterprise project strategy includes the following actions：
{
"Action": [
"ecs:cloudServers:delete"
],
"Effect": "Allow"
}
What are the Differences Between IAM Projects and Enterprise Projects?
IAM Project
An IAM project isolates resources and services at the granularity of each eSurfing Cloud resource node, ensuring physical isolation.
There is a one-to-one correspondence between IAM projects and resource nodes. Resources within an IAM project cannot be transferred—they can only be deleted and recreated.
Enterprise Project
An Enterprise Project can be understood as an upgraded version of an IAM project, designed for grouping and managing resources across different business projects within an enterprise, providing logical isolation.
An Enterprise Project can include resources from multiple regions, and resources within the project can be migrated in or out. It enables authorization for specific cloud resources—for example, adding a particular ECS instance to an Enterprise Project and granting permissions at the project level allows controlling user access so that they can only manage that specific ECS instance.
If you enable Enterprise Management, you will no longer be able to create IAM projects.
An Enterprise Project can contain resources across multiple regions, and resources within the project can be migrated in or out. It enables fine-grained authorization for specific cloud resources. For example, by adding a particular ECS instance to an Enterprise Project and configuring permissions at the project level, you can restrict users to managing only that specific ECS instance.
Regions and Availability Zones (AZs)
What are Regions and AZs?
Regions and AZs describe the physical location of data centers, allowing you to create resources in specific regions and zones.
l A region refers to a physical data center. Each region operates in complete isolation, providing maximum fault tolerance and stability. Once resources are created, their Region cannot be changed.
l An AZ is a physically isolated area within the same region, with independent power and network infrastructure, ensuring that a failure in one AZ does not affect others. A region can contain multiple AZs, which are physically isolated from each other but interconnected via an internal network. This design ensures the independence of AZs while providing low-cost, low-latency network connections.
Figure: Regions and AZs
How do I select a region?
It is recommended to choose a region close to you or your target users, as this can reduce network latency and improve access speed.
How do I select an AZ?
Whether to deploy resources within the same AZ primarily depends on your requirements for disaster recovery capability and network latency.
l If your application requires high disaster recovery capability, it is recommended to deploy resources across different AZs within the same region.
l If your application demands low network latency between instances, it is recommended to create resources within the same AZ.