IBM Cloud Platform (Account, IAM, Regions, Billing, Key Management)¶

Scope¶

This file covers the platform-level concepts of IBM Cloud that apply across every service: the account hierarchy and enterprise model, IAM (access groups, trusted profiles, service IDs, classic-vs-IAM permission split, MFA, SAML federation), regions and availability zones, the parallel classic infrastructure and VPC infrastructure stacks (a historical Bluemix/SoftLayer split that still shapes design choices), the billing model (Pay-As-You-Go, Subscription accounts, Enterprise consolidated billing, monthly vs hourly resources), and managed key management via Key Protect and Hyper Protect Crypto Services (HPCS) -- including the HPCS deprecation announcement that materially changes greenfield design choices. For Power-specific service detail see providers/ibm/powervs.md. For VPC networking, Direct Link, and Transit Gateway see providers/ibm/networking.md. For ROKS / IKS container platforms see providers/ibm/roks-iks.md.

Checklist¶

Account Hierarchy and Enterprise¶

[Critical] Is the account topology chosen against IBM Cloud's hierarchy -- a single Account (PAYG or Subscription), an Enterprise that aggregates multiple child accounts under one billing entity, and optional Account Groups for organizational layering -- with explicit reasoning for why the chosen shape suits the operating model? (Enterprises are the IBM Cloud equivalent of AWS Organizations / Azure Management Groups. Greenfield deployments expecting more than one tenant, business unit, or environment boundary should start with an Enterprise; retrofitting one across pre-existing standalone accounts is operationally noisy.)
[Critical] Are Resource Groups used as the primary scoping container for IAM policies and billing rollup, with a documented naming convention (e.g., prod-app, nonprod-shared, network) that maps to ownership and chargeback boundaries? (Resource Groups in IBM Cloud are roughly analogous to Azure resource groups, but unlike Azure they cannot nest. A single flat namespace per account drives the design discipline: a "Default" resource group is the wrong long-term home for production workloads.)
[Recommended] For an Enterprise, is the account-group structure mapped to the organization's billing-and-access model (by business unit, by environment, by geography) with deliberate decisions on which workloads live in dedicated child accounts vs shared accounts? (Child accounts are the strongest blast-radius boundary IBM Cloud provides; a security incident in one child account does not directly compromise others. Enterprise admins can centrally apply IAM templates and policies via the Enterprise-managed IAM features.)

IAM and Identity¶

[Critical] Is the dual permission model explicitly recognized -- IBM Cloud IAM controls IAM-enabled platform services (VPC, ROKS, COS, Key Protect, Db2 on Cloud, etc.), while Classic Infrastructure permissions (the SoftLayer-era model) separately govern bare-metal servers, classic virtual servers, classic networking, and the legacy portal -- and is there a documented owner for each side? (The single most common IBM Cloud governance bug is granting IAM platform access and assuming it grants classic-infrastructure access. It does not. Master-user and classic permission groups are a separate ACL stack that must be administered alongside IAM.)
[Critical] Are Access Groups used as the only mechanism for granting IAM access -- never direct policies on individual users -- with groups named for the access pattern (e.g., vpc-admin-prod, cos-reader-shared, roks-developer-nonprod) and policy assignments at the resource-group or service-instance scope rather than account-wide? (Direct user-to-policy bindings are an IBM Cloud anti-pattern; they do not scale, they bypass the audit trail Access Groups provide, and they are the source of most "we cannot tell who has access to what" findings.)
[Critical] Are Trusted Profiles used for compute-resource-to-resource authentication (a ROKS pod, a VPC VSI, a Code Engine job calling COS or Db2 on Cloud), rather than embedding Service ID API keys in workload images or secrets? (Trusted Profiles are IBM Cloud's equivalent of AWS IAM Roles and Azure Managed Identities. They eliminate stored credentials and bind authorization to the compute identity rather than to a long-lived key. Service IDs with API keys remain valid for service-to-service automation that does not run on an IBM Cloud compute resource, but Trusted Profiles are the strategic direction for in-cloud workloads.)
[Critical] Is MFA enforced at the account level with the strongest method the user population supports -- TOTP (free, baseline), U2F / FIDO2 security keys (phishing-resistant, recommended for admins), or IBMid-based MFA -- and are the enforcement settings configured per identity type (federated users vs IBMid users vs service IDs)? (Account-level MFA enforcement is set per-account by the account owner. Without account-level enforcement, individual users can opt out, which the auditor will find on every cycle.)
[Critical] Is federated identity configured via SAML to the enterprise IdP (Microsoft Entra ID, Okta, Ping, ADFS) so that IBM Cloud users are provisioned and deprovisioned through the IdP lifecycle, not the IBMid-direct flow? (Direct IBMid users are the worst-case identity pattern at audit time -- they survive employee offboarding indefinitely unless someone manually removes them. SAML federation pushes lifecycle management to the IdP, which is where it belongs. App ID and IBM Verify provide the federation broker; for many shops a direct IdP-to-IBM-Cloud SAML trust is simpler.)
[Recommended] Are classic infrastructure API keys and the legacy <account_ID>_<email> VPN usernames inventoried, rotated, and IP-restricted where they still exist, with a plan to migrate any remaining classic-infrastructure-only workflows to API key + IAM authorization where possible? (Classic API keys are per-user, one-per-account, and outlive the user's IAM access if not cleaned up. They are the IBM Cloud equivalent of orphaned root-account access keys in AWS.)

Regions and Zones¶

[Critical] Is the region and zone layout chosen against IBM Cloud's published Multi-Zone Region (MZR) and Single-Zone Region footprint -- with current MZRs including Dallas, Washington DC, Toronto, Sao Paulo, Frankfurt, Madrid, London, Tokyo, Osaka, Sydney, Mumbai, Chennai, each with three availability zones -- and against the residency and adjacency requirements of the workload? (Not every IBM Cloud service is available in every region. PowerVS, ROKS, VPC, COS, and Db2 on Cloud have overlapping but not identical region coverage. Validate the catalog for the target region before committing the design.)
[Recommended] Is the distinction between VPC infrastructure (modern, software-defined networking, the current strategic direction) and classic infrastructure (the historical SoftLayer offering, still required for some workloads such as classic bare metal, Power-adjacent connectivity, and certain regulated patterns) explicit in the design, with each workload categorized as VPC, classic, or hybrid? (Most greenfield workloads should be VPC-only. Hybrid VPC-plus-classic designs exist because the customer is mid-migration, because a service (such as PowerVS or specific bare-metal SKUs) is classic-only, or because a regulated workload requires a specific classic-network pattern. Document the reason; "we did it that way because the consultant did" is not a reason.)

Billing and Cost Management¶

[Critical] Is the account billing type chosen -- Pay-As-You-Go (PAYG) (no commitment, list-rate pricing, fast to start), Subscription account (committed monthly spend over a 1-3 year term, discount applied to subscription-eligible services), or an Enterprise with consolidated billing across child accounts -- with the financial commitment validated against forecast usage? (A Subscription account is the IBM Cloud answer to AWS Enterprise Discount Program / Azure MACC. Discounts are meaningful (typically 5-20%) but require a hard commitment; under-utilization is real cost lost.)
[Recommended] Is the monthly vs hourly resource billing model understood per service -- VSIs, VPCs, COS, and most platform services bill by the second or hour while some classic infrastructure SKUs and reserved capacity bill monthly -- and reflected in the cost model? (Mixing monthly and hourly billing on a single project line item is the most common source of "the invoice doesn't match the estimate" surprises.)
[Recommended] Are usage reports, account-group-scoped views, and tag-based cost allocation configured in the Enterprise so that chargeback and showback are possible without manual export-and-pivot? (Enterprise usage reports support drill-down by account group, account, service, and tag. Tagging conventions must be set up before the workload starts billing -- retroactive tag-based cost allocation is not possible.)

Key Management¶

[Critical] Is the key management service chosen against the data-sensitivity and compliance requirements -- Key Protect Standard (multi-tenant HSM, FIPS 140-2 Level 3, BYOK, the default choice for most workloads), Key Protect Dedicated (single-tenant HSM partition, FIPS 140-3 Level 4 submission in progress, KYOK, the new home for HPCS users), or Hyper Protect Crypto Services (HPCS) for legacy / in-flight deployments only? (HPCS is being deprecated -- the announcement on 20 March 2026 set the service shutdown for 20 March 2027. Greenfield workloads must use Key Protect Dedicated, not HPCS, even where HPCS is the regulated-industry pattern of record in older designs.)
[Critical] For workloads with an HPCS dependency, is a migration to Key Protect Dedicated (or, for KMIP / PKCS#11 use cases, the planned Key Protect Dedicated PKCS#11 offering, or on-premises IBM LinuxONE with the Unified Key Orchestrator) scheduled before the 20 March 2027 HPCS shutdown? (After the shutdown date, remaining HPCS instances will be terminated and cryptographic material deleted. This is the single most consequential IBM Cloud platform-level migration on the 2026-2027 roadmap for regulated customers.)
[Recommended] Are envelope encryption patterns adopted for every service that supports them -- COS bucket encryption, VPC block-storage encryption, Db2 on Cloud KP-managed keys, ROKS secret encryption -- with a documented root-key rotation cadence and dual-authorization policies for sensitive key destroy operations? (Without envelope encryption configured per-service, the workload defaults to IBM-managed keys, which is acceptable for many use cases but does not meet KYOK / BYOK compliance requirements where the customer must hold the key hierarchy.)

Observability and Compliance Posture¶

[Recommended] Are IBM Cloud Activity Tracker (events) and the corresponding service event streams routed to a long-retention log target (COS bucket with object-lock, IBM Cloud Logs, or an external SIEM) with retention aligned to the compliance regime (often 1-7 years)? (Activity Tracker is the IBM Cloud equivalent of AWS CloudTrail / Azure Activity Log. Default retention is short; long-retention is a deliberate configuration choice and a frequent audit gap.)
[Recommended] Is Context-Based Restrictions (CBR) configured to limit which network zones (IPs, VPCs, service references) can reach IAM-enabled services such as COS buckets, Key Protect, Secrets Manager, and Code Engine? (CBR is the IBM Cloud counterpart to AWS VPC endpoint policies / Azure service endpoints. Without it, a leaked API key from any source IP can reach the service; with it, the same key is unusable outside the defined network zone.)

Why This Matters¶

IBM Cloud is structurally different from AWS and Azure in three ways that catch architects out. First, it is two parallel platforms -- classic infrastructure (the SoftLayer heritage) and VPC infrastructure (the modern offering) -- with different IAM, different networking, and different billing surfaces. The default assumption that "IBM Cloud is one cloud" produces designs that route classic-only services through a VPC-only network plane, or grant IAM permissions and discover at the cutover that classic infrastructure access is still missing. Second, IAM is two layers (platform IAM and classic infrastructure permissions) administered through different control planes; an organization-wide IBM Cloud governance review must audit both. Third, the strategic direction (VPC, IAM-managed access, Trusted Profiles, Key Protect Dedicated) is not where every workload sits today, so a real-world design almost always includes some legacy-side coverage with a documented retirement plan.

The cost model has the same dual character. Subscription accounts deliver meaningful discounts on subscription-eligible services but bind the customer to a multi-year commit; PAYG is the right default for early-stage engagements and for non-production accounts. Enterprise consolidated billing is necessary the moment more than one account is in play; retrofitting it later costs cycles. Hourly-versus-monthly billing surfaces appear on the same invoice and routinely produce variance-explanation conversations after the first close. Tagging conventions, resource-group naming, and the cost-allocation report shape are decisions that must be made before workloads start billing.

The HPCS deprecation announced in March 2026 is the most disruptive platform-level change on the IBM Cloud roadmap. Regulated customers in financial services and federal who chose IBM Cloud specifically for HPCS's FIPS 140-2 Level 4 KYOK posture now need a migration plan to Key Protect Dedicated (multi-tenant Level 4 submission in progress) by 20 March 2027. The migration is non-trivial: KMIP integrations (notably for VMware on IBM Cloud), GREP11/PKCS#11 workloads, and Unified Key Orchestrator deployments each have different migration paths, and some land outside IBM Cloud entirely (on-premises LinuxONE for GREP11/UKO use cases). Any greenfield design that still references HPCS is already out of date.

Federation, MFA, and the account-vs-classic permission split are where the audit findings concentrate. Direct IBMid users that survive employee offboarding, classic API keys orphaned on terminated users, MFA enforced for some user populations but not all, and Access Groups that grant platform access without the corresponding classic permission -- these are the recurring patterns in IBM Cloud assessment engagements. The remedy is operational discipline, not architectural cleverness: SAML federation to the corporate IdP, account-level MFA enforcement, Access Groups for all IAM grants, periodic Access Reports against both IAM and classic, and Activity Tracker streaming to long-retention storage.

Common Decisions (ADR Triggers)¶

PAYG account vs Subscription account vs Enterprise -- PAYG (no commitment, list rates, fastest to start) vs Subscription (committed monthly spend, discount on subscription-eligible services, multi-year term) vs Enterprise (consolidated billing across child accounts, central IAM templates, account-group governance). Subscription pays back at moderate scale; Enterprise is mandatory beyond one or two long-lived accounts.
VPC infrastructure vs classic infrastructure vs hybrid -- VPC (modern, IAM-managed, strategic direction, required for most new services) vs classic (legacy SoftLayer, required for certain bare-metal and Power-adjacent patterns) vs hybrid (transitional, in-flight migrations, regulated workloads with a classic-only dependency). Greenfield should be VPC unless a specific dependency forces classic.
Access Groups with Trusted Profiles vs Service IDs with API keys -- Trusted Profiles (no stored credentials, identity bound to compute resource, strategic direction) vs Service IDs (long-lived API keys, required for non-cloud automation, must be rotated and inventoried). Production workloads on IBM Cloud compute should use Trusted Profiles; external CI/CD and on-prem automation use Service IDs.
Key Protect Standard vs Key Protect Dedicated vs HPCS (legacy) -- Standard (multi-tenant HSM, FIPS 140-2 Level 3, BYOK, default) vs Dedicated (single-tenant HSM partition, FIPS 140-3 Level 4 in submission, KYOK, the new home for HPCS workloads) vs HPCS (deprecated, shutdown 20 March 2027, migration mandatory). Greenfield regulated workloads should use Key Protect Dedicated; standard workloads should use Key Protect Standard; nothing new should use HPCS.
SAML federation to enterprise IdP vs IBMid-direct users -- SAML federation (lifecycle managed by IdP, no orphaned users, mandatory for any enterprise deployment) vs IBMid-direct (only acceptable for break-glass admin accounts and for vendors that cannot federate). Direct IBMid users in production accounts are an audit-finding pattern.
Region and zone strategy for multi-region resilience -- single MZR (three zones, sufficient for most workloads) vs cross-region active-passive (DR target in a paired region, asynchronous replication, larger cost) vs cross-region active-active (latency-tolerant workloads only, Cloudant / COS cross-region replication). The right shape is workload-RTO-driven and not a default.

Reference Links¶

IBM Cloud account types and billing overview -- PAYG, Subscription, and Trial accounts; Enterprise overview
IBM Cloud Enterprise documentation -- account hierarchy, account groups, consolidated billing
IBM Cloud IAM access concepts -- Access Groups, Trusted Profiles, Service IDs, policies, ABAC model
IBM Cloud classic infrastructure API keys and permissions -- the parallel classic permission model
IBM Cloud SAML federation guide -- federating to enterprise IdP via App ID or IBM Verify
IBM Cloud regions and zones -- current MZR / SZR footprint and per-service availability
IBM Cloud Key Protect documentation -- Standard (multi-tenant) and Dedicated (single-tenant) tiers, BYOK and KYOK
Hyper Protect Crypto Services deprecation FAQ -- deprecation timeline (shutdown 20 March 2027) and migration paths
IBM Cloud Activity Tracker overview -- audit event capture and routing
IBM Cloud Context-Based Restrictions -- network-zone restrictions on IAM-enabled services