Alibaba Cloud Resource Access Management (RAM) Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Security

1. Introduction

Resource Access Management (RAM) is Alibaba Cloud’s identity and access management service. It helps you securely control who (users, roles, applications) can access what (cloud resources) and how (allowed actions, conditions, authentication requirements).

In simple terms: RAM lets you create identities (RAM users/roles), group them, and attach permissions (policies) so people and systems can use Alibaba Cloud without sharing the root account credentials.

In technical terms: RAM provides centralized authorization via policies (system-managed or custom JSON policies) that are evaluated when a principal (RAM user/role) calls an Alibaba Cloud API. RAM integrates tightly with Alibaba Cloud authentication (AccessKey pairs, MFA, SSO) and authorization across services (ECS, OSS, RDS, VPC, etc.). RAM roles commonly pair with Security Token Service (STS) to issue temporary credentials for least-privilege, short-lived access.

What problem it solves:
Without RAM, teams often share a single AccessKey or use the root account for daily work—both are high-risk. RAM enables least privilege, separation of duties, auditable access, safer automation, and scalable operations for organizations of any size.

Service status note: Resource Access Management (RAM) is the current, active Alibaba Cloud service name for IAM. (If you see older materials referencing similar concepts, treat them as historical and verify against current RAM documentation.)

2. What is Resource Access Management (RAM)?

Official purpose

RAM is Alibaba Cloud’s service for identity management and access control. It allows you to: – Create and manage RAM users, user groups, and RAM roles – Grant or deny permissions through policies – Control how identities authenticate (password login, AccessKey, MFA, SSO) – Enable secure delegation and temporary access (commonly with STS)

Official documentation entry point:
https://www.alibabacloud.com/help/en/ram

Core capabilities (what it does)

Identity management: Create RAM users for humans and service accounts for automation.
Authorization: Attach policies to users/groups/roles to control actions on resources.
Role-based access control (RBAC): Use groups and roles to simplify permission management.
Delegation: Use roles to delegate access within an account or across accounts (patterns vary by org structure; verify your scenario in docs).
Authentication options: Console password, AccessKey pairs for APIs, and multi-factor authentication (MFA). SSO integration is commonly used in enterprises.

Major components

Alibaba Cloud account (root): The subscription owner identity. Highest privilege—should not be used for day-to-day operations.
RAM user: An identity for a person or application under your Alibaba Cloud account.
User group: A container for RAM users so you can assign permissions at scale.
RAM role: An identity that can be assumed by trusted principals (often via STS) to obtain temporary credentials.
Policy:
System policy: Alibaba Cloud managed, predefined permissions (broadly used for standard roles like read-only access).
Custom policy: JSON-defined permissions tailored to your least-privilege needs.
AccessKey pair: Programmatic credential for API/CLI/SDK access (prefer temporary credentials where possible).
MFA device: Adds a second factor for console sign-in and sensitive operations (depending on configuration).

Service type and scope

Service type: Control-plane security service (identity and access management).
Scope: RAM is generally account-scoped and works across Alibaba Cloud services.
Many IAM-style services are effectively global in nature because identities/policies are not tied to a single region. Verify any region-specific behaviors (for example, resource ARNs and service endpoints) in official docs for the services you govern.

How RAM fits into the Alibaba Cloud ecosystem

RAM sits at the center of Alibaba Cloud Security governance: – Grants access to resources in services like ECS, OSS, RDS, VPC, ACK, etc. – Works with STS for temporary credentials (recommended for workloads and federated access). – Works alongside ActionTrail (audit logging of API calls) for traceability. – Commonly used with Resource Directory / multi-account governance in larger organizations (to avoid putting everything in one account). – Often used with SSO solutions (Alibaba Cloud CloudSSO or external IdPs via SAML/OIDC patterns—verify current supported integrations in docs).

3. Why use Resource Access Management (RAM)?

Business reasons

Reduce breach risk: Stop sharing root credentials and long-lived keys.
Scale teams safely: Onboard/offboard employees quickly without touching root access.
Improve accountability: Each action can be tied back to a unique identity (especially when combined with ActionTrail).
Support governance: Standardize how access is requested, approved, granted, and reviewed.

Technical reasons

Least-privilege access: Grant only necessary permissions for each user/app.
Role-based design: Use groups and roles to keep permissions maintainable.
Temporary credentials: Use roles + STS for time-limited access to reduce exposure.
Fine-grained authorization: Custom policies can restrict actions and, for many services, restrict specific resources (service-dependent).

Operational reasons

Centralized administration: One place to manage identities and access.
Repeatable automation: Use RAM with IaC/CI/CD patterns (Terraform, ROS, SDKs) to manage permissions consistently.
Separation of duties: Split admin, developer, and auditor permissions.

Security/compliance reasons

MFA support: Strengthen console access.
Auditability: When paired with ActionTrail, RAM helps satisfy auditing and compliance requirements (e.g., ISO 27001-style controls, SOC-like evidence, internal security policies).
Controlled external access: Use roles for vendor, partner, or temporary access.

Scalability/performance reasons

Scales with organization growth: Use groups, roles, and standard policies across many teams and projects.
Avoid permission sprawl: With good structure (naming, groups, boundaries), permissions remain understandable over time.

When teams should choose RAM

Any time more than one person or system accesses Alibaba Cloud.
If you need to enforce least privilege, rotation, MFA, or audited access.
When you want secure CI/CD and automation that doesn’t rely on root keys.

When teams should not choose it (or should combine it)

If you need full identity lifecycle (HR-driven joiner/mover/leaver), device posture, conditional access, etc., you’ll often combine RAM with an enterprise IdP/SSO solution. RAM still remains the authorization layer for Alibaba Cloud resources.
If you need organization-wide multi-account policy enforcement, you’ll typically combine RAM with Resource Directory and governance tooling (service coverage varies; verify).

4. Where is Resource Access Management (RAM) used?

Industries

SaaS and internet companies running production workloads on Alibaba Cloud
Finance, healthcare, and retail needing auditable access controls
Gaming and media with high automation needs
Manufacturing and IoT platforms using API-driven provisioning
Education and research environments with multiple labs and short-term users

Team types

Platform engineering and cloud enablement teams
DevOps/SRE teams managing CI/CD and infrastructure automation
Security engineering and GRC teams designing access controls and audits
Application teams requiring controlled access to specific services (OSS, RDS, etc.)

Workloads

Production apps on ECS/ACK/Function Compute with role-based access
Data pipelines accessing OSS, MaxCompute, AnalyticDB (permissions vary by service)
CI/CD pipelines deploying to ECS/ACK and reading secrets/config (often integrated with KMS/Secrets patterns)

Architectures

Single-account environments using RAM users/groups/roles for internal access
Multi-account organizations using Resource Directory for account separation plus RAM for per-account IAM
Hybrid identity environments where users authenticate via an enterprise IdP and are authorized in RAM

Real-world deployment contexts

Production: strict least-privilege, MFA, roles, STS, audit trails, periodic access reviews
Dev/test: faster iteration but still avoid root key sharing; use groups and managed policies carefully

5. Top Use Cases and Scenarios

Below are realistic RAM use cases you will encounter in Alibaba Cloud Security design.

1) Replace root account usage with named administrators

Problem: Engineers use the root account for daily work; actions are not attributable.
Why RAM fits: Create named RAM admin users and enforce MFA.
Scenario: Two cloud admins get AdministratorAccess-style permissions while the root account is locked down.

2) Onboard developers with least-privilege access to OSS

Problem: Developers need to read build artifacts from OSS but must not delete or overwrite.
Why RAM fits: Use a group with read-only policy for OSS.
Scenario: dev-oss-readonly group is attached to AliyunOSSReadOnlyAccess (or a custom least-privilege policy).

3) CI/CD pipeline deploy permissions without sharing personal keys

Problem: A CI job needs to deploy to ECS/ACK using stable credentials.
Why RAM fits: Use a dedicated RAM user or (preferably) a role with STS and scoped policies.
Scenario: GitLab runner assumes a role to push images and deploy resources.

4) Temporary vendor access to a specific project

Problem: A contractor needs access for two weeks.
Why RAM fits: Create a RAM user with scoped permissions; disable or delete after.
Scenario: Contractor can only view logs and read OSS objects in a specific bucket.

5) Break-glass access model

Problem: Need emergency admin access with strict controls and auditing.
Why RAM fits: Create a dedicated RAM user/role requiring MFA and tightly controlled distribution.
Scenario: Break-glass credential stored in a vault, access logged, used only during incidents.

6) Enforce separation of duties (SoD)

Problem: Same person shouldn’t deploy and approve production changes.
Why RAM fits: Separate roles/groups: deployers vs auditors vs network admins.
Scenario: Network team can change VPC/Security Groups; app team can deploy to ECS but not change VPC.

7) Read-only auditor access for compliance

Problem: Auditors need visibility but must not modify resources.
Why RAM fits: Read-only policies across services + ActionTrail review.
Scenario: Auditor group can list configurations and view billing reports but cannot create/modify resources.

8) Service-to-service access using RAM roles

Problem: Workloads running on compute need to access OSS/RDS APIs securely.
Why RAM fits: Attach scoped permissions to a RAM role and use temporary credentials (STS).
Scenario: An app reads configuration from OSS without embedding long-lived AccessKeys in code.

9) Centralized permission management via groups

Problem: Managing permissions per-user becomes unmaintainable as headcount grows.
Why RAM fits: Use groups (RBAC) so users inherit permissions.
Scenario: New developer is added to project-a-dev group and immediately receives the correct access set.

10) Multi-environment boundaries (dev/stage/prod)

Problem: Developers accidentally modify production.
Why RAM fits: Separate accounts/projects and enforce environment-specific roles.
Scenario: prod-operators group has limited production access; developers only have dev/stage access.

11) API access for automation with periodic rotation

Problem: Long-lived AccessKeys are leaked or never rotated.
Why RAM fits: Use dedicated RAM users for automation, rotate keys, minimize permissions.
Scenario: Rotation runbook updates CI secrets monthly and deactivates old keys.

12) Standardize naming and tagging access

Problem: Only platform team should set tagging standards and cost allocation tags.
Why RAM fits: Restrict tag write operations to a specific group/role (service support varies).
Scenario: FinOps group can manage tags; dev groups can only read tags.

6. Core Features

Feature availability and policy granularity can differ by Alibaba Cloud service. Always verify resource-level permission support and condition keys in the relevant service’s authorization documentation.

6.1 RAM users (human and service identities)

What it does: Lets you create identities under your Alibaba Cloud account with their own login credentials and/or AccessKeys.
Why it matters: Avoid using the root account and improve accountability.
Practical benefit: Clean offboarding—disable the RAM user without rotating shared keys.
Caveats: RAM users do not “own” resources; resources belong to the Alibaba Cloud account. Overusing AccessKeys for humans is risky—prefer SSO and MFA.

6.2 User groups (RBAC at scale)

What it does: Groups multiple RAM users to assign permissions once.
Why it matters: Reduces permission sprawl and admin overhead.
Practical benefit: Add/remove users from groups without editing policies repeatedly.
Caveats: Don’t mix unrelated permissions in one group; use role-based group design.

6.3 RAM roles (delegation and temporary access)

What it does: Defines an assumable identity with a permission policy; trusted entities can assume it to obtain temporary credentials (often via STS).
Why it matters: Minimizes long-lived credentials and supports delegation.
Practical benefit: Safer automation and cross-account patterns.
Caveats: Trust policy configuration is sensitive—incorrect trust broadens access. Token/session duration and assume-role constraints apply (verify STS limits in docs).

6.4 System policies (Alibaba Cloud managed)

What it does: Predefined permission sets maintained by Alibaba Cloud (for common access patterns like read-only access).
Why it matters: Fast and reliable for standard job functions.
Practical benefit: Less JSON to maintain; kept updated for new API actions (generally).
Caveats: Often broader than strict least privilege. Use with care in production.

6.5 Custom policies (fine-grained control)

What it does: Lets you write JSON policies specifying allowed/denied actions and resources.
Why it matters: Enables least privilege for sensitive environments.
Practical benefit: Limit access to a single OSS bucket, specific APIs, or specific operational tasks.
Caveats: Policy language and resource formats are service-specific. Misconfigured policies cause AccessDenied. Always test.

6.6 Console login management (password, login URL/alias)

What it does: Allows RAM users to sign in to Alibaba Cloud console using a dedicated RAM login URL (often with an account alias).
Why it matters: Clean separation between root sign-in and user sign-in.
Practical benefit: Users can access console with their own credentials and MFA.
Caveats: Users may try to sign in via the root login page. Train users to use the RAM user login URL shown in the RAM console.

6.7 Multi-factor authentication (MFA)

What it does: Adds a second factor (typically TOTP) for console login and/or sensitive actions depending on configuration.
Why it matters: Protects against credential theft.
Practical benefit: Dramatically lowers the risk from password compromise.
Caveats: Plan recovery procedures (lost device) and enforce MFA for privileged users.

6.8 AccessKey management for API/CLI/SDK

What it does: Creates programmatic credentials for RAM users.
Why it matters: Enables automation and integration with tools.
Practical benefit: Each system can have its own identity and key lifecycle.
Caveats: AccessKeys are high-value secrets. Prefer STS temporary credentials for workloads; rotate keys; avoid embedding keys in code.

6.9 Policy attachment and inheritance model

What it does: Permissions can be attached to users, groups, and roles; users inherit group permissions.
Why it matters: Enables layered permission assignment.
Practical benefit: Combine baseline permissions (group) with exceptions (user policy) if needed.
Caveats: Keep it simple—too many attachments complicate audits.

6.10 Integration with auditing and governance (ActionTrail)

What it does: RAM identities appear in API call logs recorded by ActionTrail (where enabled).
Why it matters: Post-incident investigations and compliance reporting depend on identity attribution.
Practical benefit: Know which user/role performed which action and when.
Caveats: Audit logging is not automatic for all needs; ensure ActionTrail is configured and retained per your policies (verify ActionTrail configuration options and pricing).

7. Architecture and How It Works

High-level architecture

RAM is part of Alibaba Cloud’s control plane:

A principal (RAM user, assumed role session) makes an API call to an Alibaba Cloud service.
The request is authenticated (password session, AccessKey signature, or temporary STS credentials).
The authorization engine evaluates RAM policies attached to the principal (and groups) against the request action/resource/conditions.
The target service either allows the action or returns an access denied error.
The action can be logged by services such as ActionTrail for auditing.

Request / data / control flow

Control plane: RAM policies, users, groups, roles, and authentication settings.
Data plane: The actual resource data (OSS objects, ECS instances, RDS databases) lives in the target services.
Authorization decisions: Happen before the target service performs operations.

Integrations with related services

Commonly integrated services include: – Security Token Service (STS): Temporary credentials for assumed roles (verify current STS docs). – ActionTrail: Audit trail of API calls and console actions. – Resource Directory: Multi-account governance and account structure (enterprise usage). – KMS / Secrets patterns: For secrets storage (RAM controls who can access keys/secrets; verify product names and integration patterns). – OSS: Frequently used in labs for access verification because it’s straightforward to test permissions.

Dependency services

RAM itself is foundational and not dependent on a single region’s infrastructure in the same way compute is. However: – You depend on target cloud services supporting RAM authorization for their APIs. – You often depend on STS for secure temporary access patterns.

Security/authentication model

Console access: RAM user + password (+ MFA).
Programmatic access: AccessKey pair or STS temporary credentials from assumed roles.
Best practice: Use MFA for privileged accounts and STS for workloads whenever feasible.

Networking model

RAM is a control-plane service accessed through Alibaba Cloud APIs over HTTPS.
Network restrictions are typically enforced at the service level (VPC endpoints/private links differ per service—verify for your region and service). RAM focuses on identity/policy, not network path control.

Monitoring/logging/governance considerations

Use ActionTrail for audit logs and export to a SIEM if required.
Maintain an access review process: list who has admin permissions, rotate keys, validate MFA adoption.
Tagging/naming conventions help with policy clarity and audits.

Simple architecture diagram (Mermaid)

flowchart LR
  U[RAM User] -->|Console Login / API call| API[Alibaba Cloud API Gateway/Endpoints]
  API --> AUTH[RAM Authentication & Policy Evaluation]
  AUTH -->|Allow| SVC[Target Service: OSS/ECS/RDS...]
  AUTH -->|Deny| DENY[AccessDenied Response]
  SVC --> LOG[ActionTrail (Audit Logs)]

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Identity
    IdP[Enterprise IdP (SAML/SSO)\n(verify supported methods)]
    RAM[Resource Access Management (RAM)]
    MFA[MFA (TOTP)]
  end

  subgraph AccessPatterns
    Admins[Admins\nLeast privilege + MFA]
    Devs[Developers\nGroup-based RBAC]
    CICD[CI/CD System\nService identity]
    Role[RAM Role]
    STS[Security Token Service (STS)]
  end

  subgraph CloudServices
    OSS[OSS Buckets]
    ECS[ECS / ACK Workloads]
    RDS[RDS Instances]
    VPC[VPC Resources]
  end

  subgraph Governance
    AT[ActionTrail]
    SIEM[Log/SIEM Destination\n(optional)]
  end

  IdP --> RAM
  Admins --> MFA --> RAM
  Devs --> RAM
  CICD -->|AssumeRole| STS --> Role --> RAM

  RAM -->|Authorize| OSS
  RAM -->|Authorize| ECS
  RAM -->|Authorize| RDS
  RAM -->|Authorize| VPC

  OSS --> AT
  ECS --> AT
  RDS --> AT
  VPC --> AT
  AT --> SIEM

8. Prerequisites

Before you start the lab and production usage, ensure you have:

Account requirements

An active Alibaba Cloud account (root account).
Access to the RAM console in the Alibaba Cloud console.

Permissions needed

To perform the tutorial as an administrator, you need permissions to: – Manage RAM users, groups, and policies (RAM administrative privileges) – Create and manage OSS resources (for verification)

If you’re not the root account owner, ask for a RAM admin role or equivalent privileges.

Billing requirements

RAM is typically not billed as a metered resource by itself (see pricing section).
Creating OSS buckets/objects may incur storage and request costs (usually small for a lab, but not zero).
Ensure a valid billing method is on file to avoid provisioning failures.

Tools (optional but recommended)

Alibaba Cloud CLI (aliyun) for API-driven steps:
https://www.alibabacloud.com/help/en/alibaba-cloud-cli/latest/what-is-alibaba-cloud-cli
ossutil for OSS command-line verification (optional):
Verify in OSS docs for your platform’s download link.

Region availability

RAM is used across regions; your target service resources (like OSS buckets) are region-specific. Pick a region where OSS is available for your account.

Quotas/limits

RAM has quotas such as: – Maximum RAM users/groups/roles/policies – Policy size limits – AccessKey limits per user

Quotas can change—check the Quotas page in your console and official documentation for current limits.

Prerequisite services

For this tutorial: – Object Storage Service (OSS) (for permission testing)

9. Pricing / Cost

Current pricing model (how RAM is billed)

As of current general positioning, RAM is generally provided at no additional charge; you pay for the Alibaba Cloud resources you create and use (ECS, OSS, RDS, etc.). However, pricing and included features can change.

Official product page (verify current pricing statement):
https://www.alibabacloud.com/product/ram
Official documentation:
https://www.alibabacloud.com/help/en/ram

If you require an official pricing page line item: – Verify in official docs/pricing pages for your account type and region.

Pricing dimensions (what can still cost money)

Even if RAM itself is free, you may incur costs from: – OSS storage and requests used to validate permissions – ActionTrail retention, delivery, or event ingestion (depending on configuration) – Log service / SIEM ingestion and storage if exporting audit logs – Network egress for downloading objects from OSS to the public internet – Compute if you test instance profiles/roles using ECS/ACK

Free tier considerations

RAM itself is commonly “free,” but there may not be a separate “free tier” concept required. Your overall account may have free trials for OSS or other services—verify availability in your console.

Cost drivers

Number and type of governed resources (indirect: more services = more audit/log data)
Audit log retention duration and export destination
Automation usage patterns that increase API calls (usually negligible cost for RAM itself, but can increase logs and related service usage)

Hidden or indirect costs

Security operations time: Poorly structured permissions increase admin time.
Incident response: Long-lived AccessKeys in CI can lead to costly security incidents.
Audit and compliance: Not enabling ActionTrail or not retaining logs can create compliance gaps that are expensive to remediate later.

Network/data transfer implications

RAM does not transfer your data plane traffic; it authorizes requests. But: – Downloading from OSS to clients on the public internet can incur internet egress charges. – Exporting ActionTrail logs to external systems can incur traffic and ingestion charges.

How to optimize cost

Prefer roles + STS for workloads to reduce long-lived key sprawl.
Keep OSS lab resources minimal: one small bucket, a few tiny objects.
Configure audit logs intentionally: retain what you need, archive efficiently.

Example low-cost starter estimate (no fabricated numbers)

A minimal lab can be extremely low cost if you: – Create one OSS bucket – Upload a few small text files – Keep the lab short and delete resources afterward

Actual cost depends on region, OSS storage class, request volume, and egress. Use official pricing: – OSS pricing: https://www.alibabacloud.com/product/oss (navigate to pricing from here)
– Alibaba Cloud Pricing Calculator (if available in your locale): https://www.alibabacloud.com/pricing (verify)

Example production cost considerations

In production, the “cost” of RAM is typically not line-item billing; instead focus on: – Audit logging costs (ActionTrail + storage/log service) – Operational overhead of managing access reviews and rotations – Security risk cost avoided by not using shared long-lived keys

10. Step-by-Step Hands-On Tutorial

Objective

Create a secure, least-privilege access setup using Resource Access Management (RAM): – Create a RAM user for a developer – Grant the user read-only access to OSS using a managed policy – Verify access in the console (and optionally via CLI) – Enable MFA for the RAM user – Clean up all resources

This lab is designed to be safe and low-cost.

Lab Overview

You will: 1. Create an OSS bucket with a test object (for permission verification). 2. Create a RAM user and a RAM user group. 3. Attach an OSS read-only policy to the group. 4. Add the user to the group. 5. Sign in as the RAM user and verify read-only access. 6. Enable MFA for the RAM user. 7. Clean up: delete user/group/bucket and revoke keys.

Notes: – UI labels can change. Follow the intent of each step. – If any screen or parameter differs, verify in official RAM docs: https://www.alibabacloud.com/help/en/ram

Step 1: Create a small OSS bucket for testing (console)

Sign in to the Alibaba Cloud console with an administrator account.
Go to Object Storage Service (OSS).
Create a bucket: – Choose a region close to you. – Use a globally unique bucket name, for example: ram-lab-<random-suffix>. – Keep defaults unless your org requires specific settings.
Upload a small file (for example hello.txt) into the bucket.

Expected outcome:
You have one OSS bucket with at least one object that you can use to test read permissions.

Verification: – In OSS console, open the bucket and confirm hello.txt exists.

Step 2: Create a RAM user group (console or CLI)

Option A: Console

Open RAM in the Alibaba Cloud console.
Go to Identities (or similar) → Groups.
Click Create Group.
Name it: oss-readonly-lab-group.

Expected outcome:
A RAM group exists to carry OSS read-only permissions.

Option B: Alibaba Cloud CLI

If you prefer CLI automation, configure the CLI first (see official CLI docs) and then run:

aliyun ram CreateGroup --GroupName oss-readonly-lab-group

Expected outcome:
CLI returns group metadata (or success response).

Step 3: Attach an OSS read-only system policy to the group

To keep the lab reliable and executable, use an Alibaba Cloud system policy for OSS read-only access.

Console steps

In RAM console, open the group oss-readonly-lab-group.
Choose Permissions (or Authorization) → Add Permissions.
Select System Policy.
Find and attach: AliyunOSSReadOnlyAccess (name may vary slightly; select the official OSS read-only managed policy).

Expected outcome:
The group now has read-only OSS permissions.

Verification: – Group permissions list shows the attached OSS read-only policy.

CLI equivalent (if needed)

aliyun ram AttachPolicyToGroup \
  --PolicyType System \
  --PolicyName AliyunOSSReadOnlyAccess \
  --GroupName oss-readonly-lab-group

If the policy name differs in your environment, list system policies and pick the OSS read-only one (verify in docs).

Step 4: Create a RAM user and enable console login

You will create a user dev-oss-readonly who will inherit permissions from the group.

Option A: Console

In RAM console, go to Users → Create User.
Set User Name: dev-oss-readonly.
Enable Console Access (login password).
Set an initial password and require password reset at first login (recommended).
Optionally enable Programmatic Access (AccessKey). For this lab, you can skip it unless you want CLI verification.

Expected outcome:
A RAM user exists, and you have a RAM user login URL (often based on your account alias).

Important: Copy the RAM User Login URL shown in the console. Do not guess it.

Option B: CLI

aliyun ram CreateUser --UserName dev-oss-readonly

Create a login profile (password-based console access):

aliyun ram CreateLoginProfile \
  --UserName dev-oss-readonly \
  --Password 'ReplaceWithAStrongTemporaryPassword!' \
  --PasswordResetRequired true

Expected outcome:
The RAM user can sign in to the console using the RAM login URL and password.

Step 5: Add the RAM user to the group

Console

Open the group oss-readonly-lab-group.
Add member: dev-oss-readonly.

CLI

aliyun ram AddUserToGroup --UserName dev-oss-readonly --GroupName oss-readonly-lab-group

Expected outcome:
The user inherits the group’s OSS read-only permissions.

Verification: – The group membership list shows the user. – The user’s effective permissions include the OSS read-only policy via group membership.

Step 6: Sign in as the RAM user and verify read-only access

Open an incognito/private browser window (so you don’t reuse the admin session).
Use the RAM User Login URL copied earlier.
Sign in as: – Username: dev-oss-readonly – Password: the one you set (you may be forced to reset it on first login)

Now verify OSS access: 1. Go to OSS in the console. 2. Confirm you can list buckets and open your test bucket. 3. Confirm you can download/view hello.txt. 4. Attempt a write action (for example, try to upload a new object or delete hello.txt).

Expected outcome: – Read operations succeed. – Write/delete operations fail with an authorization error (AccessDenied / forbidden).

Step 7 (Recommended): Enable MFA for the RAM user

MFA is one of the most effective hardening steps for console users.

While signed in as the RAM user, go to Security Settings (or user profile/security center).
Find MFA or Virtual MFA device.
Bind a TOTP authenticator app (scan QR, enter verification code).

Expected outcome:
Next sign-in requires username/password + MFA code.

Verification: – Sign out and sign in again to confirm MFA is enforced.

If you are implementing this at scale, consider enforcing MFA for privileged groups and administrators. Exact enforcement options can vary—verify in official RAM docs.

Validation

Use this checklist:

[ ] OSS bucket exists with one object (hello.txt)
[ ] RAM group exists: oss-readonly-lab-group
[ ] Group has system policy attached: OSS read-only policy
[ ] RAM user exists: dev-oss-readonly
[ ] User is a member of the group
[ ] User can read OSS objects but cannot upload/delete
[ ] MFA is enabled for the RAM user (recommended)

Optional CLI validation (admin context):

aliyun ram GetUser --UserName dev-oss-readonly
aliyun ram ListGroupsForUser --UserName dev-oss-readonly
aliyun ram ListPoliciesForGroup --GroupName oss-readonly-lab-group

Troubleshooting

Common issues and fixes:

RAM user cannot sign in – Cause: Using the root account sign-in page instead of the RAM user login URL. – Fix: Copy the RAM user login URL from the RAM console and use that.
User can’t see OSS at all – Cause: Group policy not attached or user not added to group. – Fix: Re-check group membership and attached policies.
User can still upload/delete objects – Cause: User has additional permissions (another group, user-attached policy) granting write access. – Fix: Review all group memberships and user-attached policies. Remove overly broad policies.
AccessDenied when trying to list buckets – Cause: The attached policy doesn’t include list permissions or the wrong policy was selected. – Fix: Attach the official OSS read-only system policy. If using a custom policy, verify OSS action/resource syntax in official OSS authorization docs.
MFA binding fails – Cause: Time drift on the device or incorrect authenticator setup. – Fix: Enable time sync on your phone; re-bind MFA device; try again.

Cleanup

To avoid ongoing costs and reduce clutter, delete lab resources.

Delete the OSS objects, then delete the bucket: – In OSS console, delete hello.txt (as admin). – Delete the OSS bucket.
Remove RAM user from group, then delete user: – Remove user dev-oss-readonly from oss-readonly-lab-group. – Delete login profile (if required by console flow). – Delete the RAM user.
Detach policy from group, then delete group: – Detach AliyunOSSReadOnlyAccess from oss-readonly-lab-group. – Delete the group.
If you created AccessKeys, disable and delete them.

Expected outcome:
No lab identities or OSS resources remain.

11. Best Practices

Architecture best practices

Prefer roles over long-lived keys for workloads (apps, CI/CD) whenever feasible.
Use account separation (for example dev/stage/prod) for strong blast-radius control; use RAM within each account.
Design permissions around job functions and resource boundaries.

IAM/security best practices

Do not use the root account for daily operations. Protect it with MFA and minimal key usage.
Use groups for humans and roles for workloads.
Apply least privilege:
Start with read-only
Add narrow write permissions as needed
Use custom policies for sensitive resources
Enforce MFA for:
All administrators
Any user with write permissions to production resources
Use STS temporary credentials for automation where possible.
Rotate credentials:
Regularly rotate AccessKeys used by automation
Immediately rotate after suspected exposure
Keep permissions auditable:
Avoid attaching too many policies directly to users
Prefer group-based assignment
Name policies clearly and document intent

Cost best practices

Treat RAM as “free but not free to operate”:
Keep policy design simple to reduce admin time
Limit audit log volume to what you need, but don’t under-log
Remove unused users/keys and stale permissions to reduce operational overhead.

Performance best practices

RAM policy evaluation is not usually a performance bottleneck for typical workloads; however:
Avoid overly complex policies and excessive condition logic unless necessary.
Use stable role assumptions patterns; avoid re-authenticating excessively (cache tokens appropriately in apps—verify SDK guidance).

Reliability best practices

Ensure you have at least two admin identities (named admins) with MFA to avoid lockout.
Document a break-glass procedure that is tested periodically.

Operations best practices

Centralize audit: configure ActionTrail and retain logs per policy.
Implement access review routines:
Monthly review of admin group membership
Quarterly review of sensitive policies
Regular key rotation checks
Automate IAM with IaC where possible; treat policies as code and review changes.

Governance/tagging/naming best practices

Standardize naming:
Users: firstname.lastname or team.service for automation
Groups: project-env-role (e.g., payments-prod-readonly)
Roles: svc-<app>-<env>-role
Policies: pol-<service>-<scope>-<level>
Document each policy’s purpose and owner.

12. Security Considerations

Identity and access model

RAM is your primary authorization layer for Alibaba Cloud APIs.
Always design with:
Least privilege
Separation of duties
Traceability (unique identities per person/system)

Encryption

RAM manages identities and permissions, not your data encryption.
For data services (OSS/RDS), enable encryption features as appropriate and use RAM to restrict who can disable or alter encryption settings.

Network exposure

RAM is accessed via HTTPS APIs and console.
Network access controls (VPC-level restrictions, service endpoints) are service-specific—use them alongside RAM for defense in depth.

Secrets handling

Treat AccessKeys as secrets:
Never commit to source control
Store in a secrets manager/vault
Rotate and audit usage
Prefer temporary credentials (STS) for workloads.

Audit/logging

Enable ActionTrail and retain logs.
Ensure logs include:
Identity (RAM user/role session)
Source IP and user agent (where available)
Target action and resource
Export logs to centralized logging for correlation if required.

Compliance considerations

RAM supports common compliance controls: – Unique user identities – MFA for privileged access – Access review support through reporting and logs – Policy-driven least privilege

Your compliance success depends on configuration and process: – Evidence collection (ActionTrail retention, access review records) – Enforced MFA and rotation – Documented SoD

Common security mistakes

Using root account AccessKeys in CI/CD
Granting broad system policies (admin-level) to many users
Skipping MFA for admins
Leaving contractor accounts active after engagement
Not reviewing which policies are attached where
Building custom policies without testing and peer review

Secure deployment recommendations

Start with a small set of standard groups:
admins (MFA enforced)
security-auditors (read-only)
developers-<env>
ops-<env>
Use roles + STS for all compute workloads.
Keep a clear “permission boundary” between prod and non-prod (often via separate accounts).
Turn on ActionTrail early and treat audit logs as critical security data.

13. Limitations and Gotchas

Specific numeric quotas and some feature behaviors can change. Always verify in official documentation and the Quotas console.

Known limitations / caveats

Service authorization varies by product: Not all Alibaba Cloud services support the same level of resource-level granularity or condition keys.
Policy complexity: Custom policies can be error-prone; start from known-good examples.
User sign-in confusion: RAM users must use the RAM user login URL (not the root account login).
Long-lived AccessKeys risk: Easy to create, hard to secure at scale—prefer STS where possible.

Quotas

Maximum number of RAM users, groups, roles, and policies per account.
Limits on:
Policy document size
Number of policies attached to identities
Number of AccessKeys per RAM user

Verify current quotas in Alibaba Cloud console and official docs.

Regional constraints

RAM identities and policies are generally account-level, but the resources they govern are often regional.
Resource identifiers used in policies can be region- and service-specific.

Pricing surprises

RAM may not be billed directly, but enabling audit trails, log export, and storing large audit logs can incur meaningful cost.
OSS egress (internet downloads) can cost more than expected.

Compatibility issues

Some older SDKs or tools may not support newer authentication flows cleanly—verify CLI/SDK versions.
Some services use specialized authorization models; RAM still participates, but policy syntax may differ per service.

Operational gotchas

Removing a user from a group does not invalidate already-issued tokens immediately in all scenarios (token behavior is service/STS-dependent—verify).
Multiple policies attached across users/groups can create unexpected effective permissions.

Migration challenges

Migrating from shared root keys to RAM:
Requires inventory of where keys are used
Requires staged rotation and rollback planning
Requires updating CI/CD secrets and workloads

14. Comparison with Alternatives

RAM is Alibaba Cloud’s native IAM for cloud resource authorization. You may still use other services alongside it.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Alibaba Cloud Resource Access Management (RAM)	Controlling access to Alibaba Cloud resources	Native integration, policies, roles, groups, MFA; foundational Security control	Policy complexity; service-by-service granularity differences	Always for Alibaba Cloud access control
Alibaba Cloud Resource Directory	Multi-account organization and account governance	Strong account separation; org structure; centralized governance patterns	Not a replacement for per-account IAM; added complexity	When you need multiple accounts (dev/prod/business units)
Alibaba Cloud ActionTrail	Auditing who did what	Audit logging, investigation, compliance evidence	Doesn’t grant access—only records it	Always alongside RAM for audit/compliance
Alibaba Cloud CloudSSO / Federated SSO (verify current product)	Centralized workforce authentication	Central login, lifecycle, integration with enterprise IdP	Still needs RAM for authorization; integration work	Enterprises with existing IdP and many users
AWS IAM	IAM within AWS	Mature IAM ecosystem	Not applicable to Alibaba Cloud resources	Use if your workloads are on AWS
Azure Entra ID + Azure RBAC	IAM in Microsoft cloud	Strong enterprise identity features	Not for Alibaba Cloud resource authorization	Use if your workloads are on Azure
Google Cloud IAM	IAM in GCP	Fine-grained IAM model	Not for Alibaba Cloud	Use if your workloads are on GCP
Keycloak (self-managed)	Central identity brokering/SSO	Flexible, open source	You still need RAM for Alibaba Cloud authorization; ops burden	When you need self-managed identity plus federation
Open Policy Agent (OPA)	App-level authorization	Powerful policy-as-code for apps	Not a cloud IAM replacement	When you need authorization inside applications/microservices

15. Real-World Example

Enterprise example: Financial services company with strict separation of duties

Problem:
A regulated enterprise runs payment processing on Alibaba Cloud. Auditors require: – Unique identities (no shared admin accounts) – MFA enforcement for privileged actions – Clear separation between network admins, DBAs, and application deployers – Immutable audit logs

Proposed architecture: – Use Resource Directory for separate accounts: prod, stage, dev, security, shared-services (structure varies). – In each account, use RAM: – Groups: prod-ops, prod-db-admin, prod-network-admin, security-audit – Roles for workloads: svc-payments-prod-role with STS – Enable ActionTrail across accounts and centralize logs into a security account (implementation depends on ActionTrail capabilities—verify).

Why RAM was chosen: – Native authorization for Alibaba Cloud resources – Mature RBAC model via groups and policies – Supports MFA and audit attribution

Expected outcomes: – Reduced unauthorized changes and accidental production modifications – Faster audits with clear identity attribution and access review evidence – Lower credential leakage risk by using roles/STS for workloads

Startup/small-team example: SaaS startup securing CI/CD and OSS artifacts

Problem:
A startup stores build artifacts in OSS and deploys to ECS. They currently share one AccessKey in CI, and developers sometimes use it locally.

Proposed architecture: – Create RAM users for each engineer (console access + MFA). – Create a dev-readonly-oss group for artifact access. – Create a dedicated CI identity: – Prefer a RAM role assumed via STS (if CI supports it), or a RAM user with a tightly scoped policy and aggressive key rotation. – Enable ActionTrail for audit visibility.

Why RAM was chosen: – Fast to implement, no need for external IdP on day one – Enforces least privilege and separates human vs machine access

Expected outcomes: – No more shared keys across developers – Reduced blast radius if CI credentials leak – Clear record of who accessed/deployed what

16. FAQ

What is Resource Access Management (RAM) in Alibaba Cloud?
RAM is Alibaba Cloud’s IAM service for creating users/roles and managing permissions (policies) to access Alibaba Cloud resources.
Is RAM the same as AWS IAM?
Conceptually similar (users, roles, policies), but policy syntax, integrations, and service behaviors are Alibaba Cloud-specific.
Should I use the root account for daily operations?
No. Create RAM admin users with MFA and reserve root for billing and rare account-level tasks.
What’s the difference between a RAM user and a RAM role?
A RAM user is a persistent identity (often a person or service account). A RAM role is assumed by trusted identities to obtain temporary credentials (commonly via STS).
Do RAM users own resources?
No. Resources are owned by the Alibaba Cloud account. RAM controls who can operate on them.
What are system policies vs custom policies?
System policies are managed by Alibaba Cloud; custom policies are JSON policies you write for fine-grained least privilege.
Can I restrict access to a specific OSS bucket only?
Often yes using a custom policy, but the exact resource format and actions are OSS-specific. Verify in OSS authorization documentation.
How do I enforce MFA for administrators?
RAM supports MFA binding; enforcement mechanisms can vary by configuration and product evolution. Verify current enforcement options in RAM docs and implement org policy.
Is RAM regional?
RAM identities/policies are generally account-level, while resources are often regional. Always check how each service defines resources in policy statements.
What’s the best practice for CI/CD authentication?
Prefer RAM roles with STS temporary credentials. If not possible, use a dedicated RAM user with minimal permissions and frequent key rotation.
How do I audit what a RAM user did?
Enable ActionTrail and review logs for the RAM user/role session. Ensure logs are retained and protected.
What happens if I delete a RAM user?
The identity is removed. Ensure you also remove/rotate any keys used by automation and update systems accordingly.
Can I integrate RAM with my corporate identity provider?
Many organizations use SSO/federation patterns. Verify current Alibaba Cloud supported SSO products and protocols (SAML/OIDC) in official docs.
Why am I getting AccessDenied even though I attached a policy?
Common causes: user not in the correct group, wrong policy attached, service requires different actions/resources, or an explicit deny. Review effective permissions and test.
How many AccessKeys should a RAM user have?
Keep it minimal. Prefer zero for human users. For automation, use one active key (or STS) and rotate regularly; follow Alibaba Cloud limits and security guidance.
Can I use RAM to control billing access?
Yes, typically via policies that allow read-only billing access for finance users and deny resource operations. Exact permissions vary—verify in billing authorization docs.
What’s the safest way to grant a vendor temporary access?
Use a dedicated RAM user or role with strict, time-bounded access and monitor via audit logs; remove access immediately after the engagement.

17. Top Online Resources to Learn Resource Access Management (RAM)

Resource Type	Name	Why It Is Useful
Official documentation	RAM documentation (Alibaba Cloud Help Center) — https://www.alibabacloud.com/help/en/ram	Primary source for current features, UI, and API references
Official product page	Resource Access Management product page — https://www.alibabacloud.com/product/ram	High-level overview and (often) pricing statement; good for stakeholders
Official getting started	RAM “What is / Getting started” (navigate within Help Center) — https://www.alibabacloud.com/help/en/ram	Step-by-step onboarding patterns for users, groups, roles
API reference	RAM API Reference (Help Center; verify exact URL path) — https://www.alibabacloud.com/help/en/ram	Authoritative API parameters for automation
Official CLI docs	Alibaba Cloud CLI overview — https://www.alibabacloud.com/help/en/alibaba-cloud-cli/latest/what-is-alibaba-cloud-cli	Installing and using `aliyun` CLI securely
Related service docs	Security Token Service (STS) docs (verify) — https://www.alibabacloud.com/help	Temporary credentials and assume-role patterns
Related service docs	ActionTrail docs (verify) — https://www.alibabacloud.com/help	Auditing and compliance evidence for RAM identities
Related service docs	OSS docs — https://www.alibabacloud.com/help/en/oss	OSS authorization examples to test RAM policies
Architecture resources	Alibaba Cloud Architecture Center (verify current) — https://www.alibabacloud.com/solutions/architecture	Reference architectures for secure cloud foundations
Community learning	Alibaba Cloud community portal (verify) — https://www.alibabacloud.com/blog	Practical posts and updates; validate against official docs

If a link redirects or the page structure changes, use the Help Center search for “RAM”, “STS”, and “ActionTrail”.

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website
DevOpsSchool.com	DevOps engineers, SREs, platform teams	Cloud security basics, IAM/RAM concepts, automation practices	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate engineers	DevOps foundations, processes, tooling that complements cloud IAM	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud engineers and operations teams	Cloud operations practices; may include access governance	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs and reliability-focused engineers	SRE practices, operational controls, security and access hygiene	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops and monitoring teams	Operations automation and governance; adjacent to access control	Check website	https://www.aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website
RajeshKumar.xyz	DevOps/cloud training content (verify offerings)	Beginners to intermediate cloud/DevOps learners	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training and guidance (verify scope)	DevOps practitioners seeking structured learning	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps services/training platform (verify scope)	Teams needing hands-on help or mentoring	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support and training resources (verify scope)	Ops teams needing practical support	https://www.devopssupport.in/

20. Top Consulting Companies

Company	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website
cotocus.com	Cloud/DevOps consulting (verify offerings)	Cloud foundation, access governance, delivery automation	IAM/RAM design, CI/CD hardening, audit readiness planning	https://cotocus.com/
DevOpsSchool.com	DevOps and cloud consulting/training (verify offerings)	Platform enablement, DevSecOps practices, governance	RAM best-practice rollout, least-privilege policy standardization, operational runbooks	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify offerings)	DevOps transformation and operations	Secure automation patterns, access reviews, pipeline credential hardening	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before RAM

Cloud fundamentals: regions, networking (VPC), compute (ECS), storage (OSS)
Security fundamentals: least privilege, MFA, secrets management, audit logging
Basic JSON (for custom policies)
CLI basics (optional but valuable): aliyun CLI usage and credential configuration

What to learn after RAM

STS and role assumption patterns for temporary credentials
ActionTrail and log retention strategy
Secure workload identity patterns (roles for ECS/ACK/Function Compute—verify service support)
Multi-account governance using Resource Directory
Infrastructure as Code:
Terraform / ROS templates to manage RAM users/groups/policies as code (verify provider/resource support)
Security monitoring and incident response integration (SIEM, alerting)

Job roles that use RAM

Cloud engineer / cloud administrator
DevOps engineer / platform engineer
Site Reliability Engineer (SRE)
Security engineer / cloud security architect
FinOps analyst (read-only billing and tagging governance)
Compliance/GRC analyst (audit review)

Certification path (if available)

Alibaba Cloud certifications evolve. For a current path: – Start with Alibaba Cloud associate-level cloud certification (verify current names). – Add security-focused certification or specialty if offered. – Use RAM, STS, ActionTrail, and networking security as core study areas.

Verify the latest Alibaba Cloud certification catalog in official training/certification pages.

Project ideas for practice

Build a “secure baseline” repo:
RAM groups: admin, auditor, developer
Policies: read-only, deploy-only, break-glass
ActionTrail enabled + retention strategy
Implement CI/CD credentials:
Replace long-lived keys with assumed roles (STS) where possible
Run quarterly access review automation:
Export users/groups/policies and generate a report for security review

22. Glossary

Alibaba Cloud account (root): Primary account owning billing and resources; highest privileges.
RAM (Resource Access Management): Alibaba Cloud service for identity and access control.
RAM user: Identity under an Alibaba Cloud account for a person or application.
User group: Collection of RAM users used to assign permissions together.
RAM role: Assumable identity granting permissions via temporary credentials.
Policy: JSON document defining allowed/denied actions on resources.
System policy: Alibaba Cloud-managed policy.
Custom policy: User-defined policy written in JSON.
Least privilege: Grant only the minimum permissions required.
MFA: Multi-factor authentication; typically TOTP-based in cloud consoles.
AccessKey: Long-lived programmatic credential (AccessKey ID + Secret).
STS (Security Token Service): Issues temporary security credentials for assumed roles.
ActionTrail: Alibaba Cloud audit logging service for API and console actions.
RBAC: Role-based access control; manage permissions via roles/groups rather than per-user.

23. Summary

Resource Access Management (RAM) is Alibaba Cloud’s core Security service for controlling access to cloud resources. It provides users, groups, roles, and policies so you can implement least privilege, separate duties, and avoid risky shared root credentials.

Architecturally, RAM sits in the control plane: every API request is authenticated and then authorized against RAM policies before the target service acts. Operationally, RAM becomes far more valuable when paired with STS (temporary credentials) and ActionTrail (auditing).

Cost-wise, RAM is typically not a direct cost driver, but the ecosystems around it—audit logging, storage, and operational processes—do affect your bill and your security posture.

Use RAM any time multiple people or systems access Alibaba Cloud. Start with groups and managed policies for speed, then move toward custom least-privilege policies, MFA enforcement, and role-based temporary access as you mature.

Next learning step: implement RAM roles + STS for workload authentication and enable ActionTrail with a retention/export strategy aligned to your compliance requirements.

Category

1. Introduction

2. What is Resource Access Management (RAM)?

Official purpose

Core capabilities (what it does)

Major components

Service type and scope

How RAM fits into the Alibaba Cloud ecosystem

3. Why use Resource Access Management (RAM)?

Business reasons

Technical reasons

Operational reasons

Security/compliance reasons

Scalability/performance reasons

When teams should choose RAM

When teams should not choose it (or should combine it)

4. Where is Resource Access Management (RAM) used?

Industries

Team types

Workloads

Architectures

Real-world deployment contexts

5. Top Use Cases and Scenarios

1) Replace root account usage with named administrators

2) Onboard developers with least-privilege access to OSS

3) CI/CD pipeline deploy permissions without sharing personal keys

4) Temporary vendor access to a specific project

5) Break-glass access model

6) Enforce separation of duties (SoD)

7) Read-only auditor access for compliance

8) Service-to-service access using RAM roles

9) Centralized permission management via groups

10) Multi-environment boundaries (dev/stage/prod)

11) API access for automation with periodic rotation

12) Standardize naming and tagging access

6. Core Features

6.1 RAM users (human and service identities)

6.2 User groups (RBAC at scale)

6.3 RAM roles (delegation and temporary access)

6.4 System policies (Alibaba Cloud managed)

6.5 Custom policies (fine-grained control)

6.6 Console login management (password, login URL/alias)

6.7 Multi-factor authentication (MFA)

6.8 AccessKey management for API/CLI/SDK

6.9 Policy attachment and inheritance model

6.10 Integration with auditing and governance (ActionTrail)

7. Architecture and How It Works

High-level architecture

Request / data / control flow

Integrations with related services

Dependency services

Security/authentication model

Networking model

Monitoring/logging/governance considerations

Simple architecture diagram (Mermaid)

Production-style architecture diagram (Mermaid)

8. Prerequisites

Account requirements

Permissions needed

Billing requirements

Tools (optional but recommended)

Region availability

Quotas/limits

Prerequisite services

9. Pricing / Cost

Current pricing model (how RAM is billed)

Pricing dimensions (what can still cost money)

Free tier considerations

Cost drivers

Hidden or indirect costs

Network/data transfer implications

How to optimize cost

Example low-cost starter estimate (no fabricated numbers)

Example production cost considerations

10. Step-by-Step Hands-On Tutorial

Objective

Lab Overview

Step 1: Create a small OSS bucket for testing (console)

Step 2: Create a RAM user group (console or CLI)

Option A: Console