ISO/IEC 5140:2024

International
Standard
ISO/IEC 5140
First edition
Information technology — Cloud
2024-01
computing — Concepts for multi-
cloud and the use of multiple cloud
services
Technologies de l'information — Informatique en nuage —
Concepts pour le multi-nuage et l'utilisation des services en
nuages multiples
Reference number
© ISO/IEC 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2024 – All rights reserved
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms. 1
5 Notational conventions . 2
6 Cloud computing using multiple CSPs . 2
6.1 General .2
6.2 Interactions among parties .3
7 Multi-cloud . 3
7.1 General .3
7.2 Multi-cloud sub-types .4
7.2.1 CSC-mediated multi-cloud .4
7.2.2 CSP-connected multi-cloud .4
7.3 Characteristics.5
7.4 Benefits .6
7.5 Considerations .8
7.6 Multi-cloud management . . .8
8 Federated cloud . 9
8.1 General .9
8.2 Benefits .10
8.3 Considerations .11
8.4 Cloud service federation .11
8.4.1 Characteristics .11
8.4.2 CSF membership . 12
8.4.3 Shared resource metadata and discovery . 12
8.4.4 CSF governance . . 12
8.5 CSF domains . 13
8.5.1 General . 13
8.5.2 Administrative domains . 13
8.5.3 Regulatory domains . 13
8.6 CSF management sub-roles .14
8.6.1 General .14
8.6.2 CSF operator .14
8.6.3 CSF manager .14
8.6.4 CSF auditor.14
8.6.5 CSF broker . 15
8.7 CSF topologies . 15
9 Hybrid cloud . 17
9.1 General .17
9.2 Characteristics.18
9.3 Benefits .19
9.4 Considerations .19
9.5 Hybrid cloud management .19
9.6 Hybrid multi-cloud . 20
10 Inter-cloud .20
10.1 General . 20
10.2 Characteristics.21
10.3 Benefits .21
10.4 Considerations .21

© ISO/IEC 2024 – All rights reserved
iii
10.5 Management . . . 22
Annex A (informative) Use cases for multi-cloud management .23
Bibliography .25

© ISO/IEC 2024 – All rights reserved
iv
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 38, Cloud computing and distributed platforms.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2024 – All rights reserved
v
Introduction
Cloud service customers (CSCs) create cloud solutions that satisfy their requirements and benefit from the
use of cloud computing. In creating these cloud solutions, CSCs sometimes use cloud services from multiple
cloud service providers (CSPs). The use of multiple CSPs gives rise to cloud deployment models (CDM) such
as hybrid cloud, multi-cloud and hybrid multi-cloud. Similarly, the CSPs themselves sometimes utilize cloud
services from other CSPs resulting in CDMs such as inter-cloud and federated cloud.
The use of cloud services from multiple CSPs, either through CSC cloud solutions or by CSPs utilizing cloud
services from other CSPs, can potentially enhance availability, resilience, fault-tolerance, latency, flexibility,
business continuity, cost optimization, the ability to operate in multiple geographies or jurisdictions, and
the ability to meet compliance requirements. On the other hand, use of multiple cloud services in general
and multiple cloud services from multiple CSPs can result in increased complexity and other operational
and administrative challenges. These challenges, which can manifest in various ways, are addressed in
order to create a cloud solution. Examples of such challenges include the necessary integrations and data
transformations; additional burdens on management such as logging, monitoring and error resolution; the
reconciliation of the cloud service agreements and cloud SLAs from multiple CSPs; the complexity of total
cost estimation; identity management and access control across multiple CSPs; and privacy.
This document provides an overview of, and foundational concepts for, cloud computing involving multiple
cloud service providers (CSPs). This document establishes a common understanding of cloud solutions
that use cloud services from multiple CSPs by building on the cloud computing concepts defined in the
ISO/IEC 22123 series. It also provides characteristics, benefits and challenges relating to multi-cloud and
other cloud deployment models involving multiple CSPs.

© ISO/IEC 2024 – All rights reserved
vi
International Standard ISO/IEC 5140:2024(en)
Information technology — Cloud computing — Concepts for
multi-cloud and the use of multiple cloud services
1 Scope
This document specifies foundational concepts for multiple cloud services including multi-cloud, hybrid
cloud, inter-cloud and federated cloud.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 22123-1, Information technology — Cloud computing — Part 1: Vocabulary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 22123-1 apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
4 Symbols and abbreviated terms
API application programming interface
CDM cloud deployment model
CSA cloud service agreement
CSC cloud service customer
CSF cloud service federation
CSN cloud service partner
CSP cloud service provider
CSU cloud service user
IDaaS identity as a service
PII personally identifiable information
SLA service level agreement
SO service objective
© ISO/IEC 2024 – All rights reserved
5 Notational conventions
This document follows the same notational conventions and language used in the ISO/IEC 22123 series when
it refers to parties, roles and sub-roles. The major parties of cloud computing are cloud service customer
(CSC), cloud service partner (CSN), and cloud service provider (CSP). These parties are entities that play roles
(and sub-roles). The major roles of cloud computing are cloud service customer role (CSC role), cloud service
partner role (CSN role), and cloud service provider role (CSP role). These roles can be further organized into
sub-roles. It is important to note that a party can play more than one role at any given point in time and may
only engage in a specific subset of activities of that role. As an example, “CSC” refers to the cloud service
customer party and “CSC role” refers to the cloud service customer role.
Within this document, the name of a sub-role has the prefix of “CSC:” for CSC sub-roles, “CSN:” for CSN sub-
roles, or “CSP:” for CSP sub-role and then the sub-role name. Table 1 shows the prefix for each of the three
cloud computing roles.
Table 1 — Cloud computing sub-roles
Role Sub-role prefix Example
CSC role “CSC:” CSC: cloud service user
CSN role “CSN:” CSN: cloud auditor
CSP role “CSP:” CSP: network provider
6 Cloud computing using multiple CSPs
6.1 General
It is sometimes challenging to find an appropriate complete cloud solution from a single CSP that fully meets
the organization’s requisite needs. A strategy that includes cloud services from multiple CSPs enables cloud
solutions that go beyond the capabilities of any single CSP.
[1]
There are several cloud deployment models (CDMs) that involve multiple CSPs. These include, but are not
limited to:
— multi-cloud (see Clause 7)
— federated cloud (see Clause 8)
— hybrid cloud (see Clause 9)
— hybrid multi-cloud (see subclause 9.6)
— inter-cloud (see Clause 10).
There are three fundamental approaches for CDMs that involve multiple CSPs:
— The CSC controls and manages the cloud services that are being delivered by each of the CSPs including
the orchestration of the cloud solution; one example is a multi-cloud.
— One CSP combines the cloud services from multiple CSPs with varying degrees of orchestration, control
and management activities; one example of this is an inter-cloud in which the CSC interacts with only one
CSP.
— Multiple CSPs form a partnership through out-of-band collaboration and share their resources via cloud
services; one example of this is a federated cloud.
These approaches are not mutually exclusive and it is possible to combine them.
The presence of multiple CSPs, and consequently of multiple cloud services, creates additional challenges for
governance, access control, sharing of resources, trust, security and privacy that should be addressed.

© ISO/IEC 2024 – All rights reserved
The implementation of a CDM that involves multiple CSPs should take into consideration the location of
data centres, connectivity among them, data locality, management of instances, failure models, and error
propagation. For example, appropriate cloud service agreements, cloud SLAs and interoperable single sign-
on are implemented by co-operating CSPs.
6.2 Interactions among parties
In a single CSP cloud solution, most interactions are between the CSC and the CSP. For the multiple CSP
environment, the nature of the interactions depends on the CDMs being used for the cloud solution. The
choice of CDM affects the responsibilities of each party within the cloud solution, the cloud SLAs between
the parties, the cooperation required from the parties involved and the data path/flow among the parties.
Interactions among parties involved in cloud solutions consisting of multiple CSPs include:
— Interactions between the CSC and the CSPs: Interactions between the CSC and the multiple CSPs
involved in the cloud solution depend on the CDM being used. For example, in the inter-cloud case, the
CSC interacts only with a single primary CSP and it is that primary CSP's responsibility to use the cloud
services of the secondary CSPs to provide cloud services that the CSC needs. This is unlike the multi-
cloud case, where the CSPs involved are potentially unaware of each other and the CSC provides the
necessary orchestration activities required to create the cloud solution.
— Interactions among CSPs: Each CSP offers cloud services that can be similar to or different from the
cloud services offered by the other CSPs that are part of the cloud solution. The CSPs can be collaborating
with each other, or they can be unaware of each other’s involvement in the CSC’s cloud solution. This can
result in different CDMs being used in the cloud solution. For example, in the multi-cloud case, it is the
CSC that is responsible for the orchestration and the data transformations/translations that are needed
to create the cloud solution, with the CSPs not necessarily aware of each other. Whereas in the case
of federated cloud, the multiple CSPs are aware of each other and cooperate with each other to share
resources and data within a CSF domain.
Each of these interactions among the parties can be further classified as:
a) Operational interaction, which is used for delivering the services that are required.
b) Management and administration interaction, which are used to manage, administer the services,
and support security and privacy capabilities.
7 Multi-cloud
7.1 General
In a multi-cloud CDM, the CSC is responsible for providing cloud service administrator and business manager
functions for a defined set of cloud service users (CSUs) (i.e. domain of control over a set of end users and
their activities). The operational interactions between the CSC and the CSP(s) are for the CSUs while the
management and administration interactions support the administrator and manager activities.
Multi-cloud CDMs can be divided into two sub-types:
— CSC-mediated multi-cloud: Multi-clouds in which all interactions are between the CSC and the CSPs.
See subclause 7.2.1.
— CSP-connected multi-cloud: Multi-clouds in which some or all interactions are between the CSPs’
data centres but are initiated, controlled and managed by the CSC or code under CSC’s control. See
subclause 7.2.2.
In multi-cloud solutions, the CSC has a cloud service agreement (CSA), which includes a cloud SLA, with each
of the CSPs separately. Each cloud SLA may be different in terms of capabilities being provided, the qualities
of the services, the period and locations of service delivery, and the costs associated with the services.

© ISO/IEC 2024 – All rights reserved
7.2 Multi-cloud sub-types
7.2.1 CSC-mediated multi-cloud
In a CSC-mediated multi-cloud solution the CSC selects cloud services offered by two or more CSPs. Multi-
cloud is the term used to describe the situation where one CSC uses public cloud services from two or more
CSPs. This is shown in Figure 1, in which a CSC uses one cloud service from CSP1 and another cloud service
from CSP2. The essence of multi-cloud, which differentiates it from other forms of interoperation of multiple
cloud services, is that decision-making and control of the use of the multiple cloud services lies with the
CSC. In a CSC-mediated multi-cloud solution, the CSPs involved are possibly but not necessarily aware of the
multiple cloud services being used.
Figure 1 — Basic multi-cloud example
While the multiple cloud services can be used independently by the CSC, for the multi-cloud case the CSC
creates a cloud solution by combining the cloud services offered by multiple CSPs. It is the CSC’s responsibility
to apply any necessary data translation, data transformations and integration functions.
One example is when the output of one cloud service is used to create input for a second cloud service,
organized by the CSC, such that the two cloud services involved are unaware of each other’s existence.
7.2.2 CSP-connected multi-cloud
The different cloud services can be used together more directly as shown in Figure 2. For example, a compute
service from CSP1 can use a storage service from CSP2. In this case, the compute service uses the APIs of the
storage service to store or read data from the storage service. It is the CSC that organizes the enablement of
the API used in the code deployed in the cloud service at CSP1 or the configuration at CSP1 to use the storage
service at CSP2.
In Figure 2, where the data is processed (CSP1) and stored (CSP2) by different CSPs, the CSC has a cloud
SLA with CSP1 to address compute-related service objectives (SOs) and another SLA with CSP 2 to address
storage related SOs such as data storage locations and controls. Additionally, in this example the CSC
requires that the compute service used at CSP1 has connectivity to access the storage service at CSP2.

© ISO/IEC 2024 – All rights reserved
Figure 2 — Example of a multi-cloud with an inter-CSP connection
In the case of a web application, typically there is a user interface component that consists of the code that
serves up the web pages, a business logic component that has the code to perform business transactions and
a database component that holds the data used within the application.
Figure 3 shows that the user interface service (CSP1) uses the business logic service (CSP2), while the
business logic service (CSP2) uses the database service (CSP3). The solution is organized by the CSC by
configuring the relevant cloud services. In this case each component is implemented using a cloud service
from a different CSP.
Figure 3 — Example of a more complex multi-cloud
In Figure 3, it can be the case that the use of the business logic service by the user interface service is
arranged by the CSC through configuration of the code in the user interface service. The same pattern
applies to the use of the database service by the business logic service.
7.3 Characteristics
Since multi-cloud is a CSC-driven CDM, the participating CSPs are not necessarily aware of each other. The
requirements of the CSC provide the reasons for choosing multi-cloud.

© ISO/IEC 2024 – All rights reserved
Multi-cloud can be used for the following cloud capabilities types for the reasons listed:
— Application: Some applications are only available from specific CSPs, potentially leading to a mix of
CSPs. The CSC may require integration of cloud services offered by different CSPs.
— Platform: CSPs may specialize in the business or technical platforms that are required for specific
applications.
— Infrastructure: Different CSPs can provide customized or specialized resources or offer infrastructure
services in different cloud regions or availability zones.
In addition, a multi-cloud can be a mix of CSPs that offer different application, platform and infrastructure
capabilities types.
At its most fundamental, multi-cloud is an extension of cloud computing to include public cloud services from
more than one CSP. Multi-cloud inherits all the standard benefits of a public cloud. The key characteristics
of multi-cloud are derived directly from those of cloud computing as described in the ISO/IEC 22123 series.
These are:
— Broad network access: Network accessibility is a key characteristic for all cloud services in a multi-cloud
environment. CSCs benefit from a wider selection of cloud access points. Broad accessibility can improve
resilience and minimize single points of failure. Access to inter-CSP networks can also be required.
— Measured service: Services that are measured and pay-as-you-go permit multiple CSP cost optimization
and workload distribution including across jurisdictions.
— Multi-tenancy: Extensions across CSP boundaries provide additional opportunities for the CSC to
partition its CSUs into tenancies that use cloud services from different CSPs. For example, a CSC can
choose to partition its CSUs into different tenancies based on which CSP services they access.
— On-demand self-service: Self-service operations and management automation become more critical
when multiple CSPs are involved. Multi-cloud requires integrated multiple CSP operations and
management.
— Rapid elasticity and scalability: Multi-cloud provides additional options for elasticity and scalability
such as balancing workloads across multiple CSPs and global optimization of cost, performance, and
functionality.
— Resource pooling: A CSP typically aggregates or pools resources in order to serve multi-tenant CSCs. In
the case of multi-cloud, the CSC can use a service-based approach to optimize the use of the underlying
resources offered by the cloud service of the multiple CSPs.
Additional characteristics that apply to multi-cloud include:
— Cloud infrastructure independence: Individual CSPs within a multi-cloud are physically and logically
independent of each other and can provide different cloud services.
— Cloud controls: The CSC controls the multi-cloud and each CSP involved in the multi-cloud performs
activities to its own cloud services according to the requested control by the CSC. These cloud controls
can include activation, configuration, integration, orchestration and de-activation of each cloud service
and its underlying resources.
7.4 Benefits
Multi-cloud provides a wide range of possibilities for cloud solutions that are not limited to a single CSP.
Potential benefits of multi-cloud include:
— Flexibility: Multi-cloud facilitates the “mixing and matching” of CSPs and their cloud services. Multi-
cloud configurations can provide enhanced resilience, wider distribution, extended functionality,
stronger security, and possibly reduced overall cost. Service flexibility applies to application, platform,
and infrastructure capabilities types.

© ISO/IEC 2024 – All rights reserved
EXAMPLE 1 Compute services are often chosen to minimize latency, to take advantage of network resources
[2]
or to be close to storage. In the case of edge computing that uses a multi-cloud solution, different CSPs can be
selected for different geographical regions.
— Availability: A multi-cloud environment occurs when one CSP does not offer all the required cloud
services. In some cases, a cloud service is only available from specific CSPs, either globally or in specific
locations.
EXAMPLE 2 A CSC requires a specific weather service that is available from only one CSP. The service is not
portable, so the CSC chooses that CSP’s weather service. If the CSC’s application itself is hosted by another CSP,
then a multi-cloud solution would be required.
— Best of breed: Different CSPs offer “best of breed” solutions for the different cloud services needed by a
CSC. By choosing each cloud service on its own merits, the CSC ends up using multiple CSPs.
EXAMPLE 3 A company acquires storage services from different CSPs based on price, storage requirements,
affinity with other services, sharing requirements, or other criteria such as company policy.
— Fault-tolerance: A CSC can choose two or more CSPs for a given set of cloud services to enhance fault-
tolerance in case the cloud services from one CSP become unavailable for some reason. This is an
alternative to the use of regions and availability zones of a public cloud from one CSP.
EXAMPLE 4 Diversification of storage in the previous example is used to avoid a single point of failure. At least
two storage services would be selected, with the choice made for each CSU or by department or division.
— Proximity and latency: It can be the case that different CSPs have their cloud service resources in
different geographic regions and that, for proximity and latency reasons, the CSC chooses two or more
CSPs in order to meet the performance requirements of the CSUs.
EXAMPLE 5 The resources available from a CSP will vary by cloud region, and there will be differences in the
specific cloud services that are available. If a CSC can select a CSP that is close to the CSC, then quality of service
improvement is possible. Edge computing is an example where edge services may not be available everywhere
from the same CSP.
— Data residency: Data residency requirements can dictate the use of more than one CSP.
EXAMPLE 6 Data residency issues may occur if a single CSP does not have coverage in all required areas or is
not able to securely store data in all jurisdictions.
EXAMPLE 7 Data residency issues may require data to be stored in a particular jurisdiction, location or with
specific CSPs. In data backup cases there may be a requirement for data to not be stored in a particular location.
— Regulatory requirements: Some aspects of cloud computing are subject to local regulatory controls,
which potentially are not met by all CSPs. The ability to select a CSP that meets local requirements is
important for designs that include data residency, data disclosure, criminal laws, cross-border data flow
and possibly tax regimes.
EXAMPLE 8 Certain financial data and banking information cannot be stored outside the country of origin.
Since a CSP’s cloud services vary in their degree of compliance with applicable regulations, the CSC benefits by
choosing the CSP to maximize adherence to local regulations and conditions.
— Cost: Multi-cloud provides opportunities to manage costs by choosing the most effective overall solution
and through negotiating more favourable discounts. This, however, should be balanced against increased
complexity and an increased need for automation and control.
EXAMPLE 9 Multiple CSPs can offer similar services using different pricing models and conditions, possibly
dependent on volume, time, location or other discounting criteria. A CSC with a multi-cloud solution can more
easily move data or workloads to take advantage of lower costs.

© ISO/IEC 2024 – All rights reserved
7.5 Considerations
The use of multi-cloud results in several challenges that should be addressed.
— Complexity: Settings, defaults, security controls and functionality can vary across CSPs. Interacting
with different CSPs with different processes and interfaces can make it harder for a CSC to manage its
use of cloud services. The CSC can rationalize the interfaces and processes to create a unified multi-CSP
dashboard or user interface. There can be additional considerations for multi-cloud management, such
as identity brokering, cloud service discovery, routing, network and connectivity.
— Latency: While multi-cloud can potentially provide the benefit of reducing overall application latency,
it can increase latency between the cloud services provided by different CSPs that frequently interact.
This can be significant if the communicating cloud services are distant. Multi-cloud management should
account for such latency variances.
— Performance: Different CSPs can have different cloud SLAs and therefore the associated service level
guarantees can be different. Any use of multi-cloud should account for these differences.
— Cost estimation and optimisation: Different CSPs can have different cost structures and billing
practices. A multi-cloud deployment that is trying to constrain and optimise costs should take this into
account.
— Logging and monitoring: An application that uses cloud services from multiple CSPs should collect
telemetry from each cloud service, analyse it and provide operational insights. Given the potential
differences in the content, format and associated metrics, as well as how and when the data is available
from the different CSPs, multi-cloud management should account for all these differences. This can
require providing unified capabilities for monitoring, logging, tracing and analytics for cloud services
across different CSPs.
— Cloud service level agreements: When an application makes use of multiple CSPs, in which each CSP
provides a unique cloud service that is not replicated elsewhere, the overall availability of the application
depends on the availability of each cloud service provided by the independent CSPs. For example, the
configuration shown in Figure 3 requires that the three services provided by CSP1, CSP2 and CSP3 be
available for the overall application to be available. This results in application availability that is lower
than the availability of each individual service. The CSC should take reliability into consideration when
evaluating cloud SLAs.
— Privacy of data: Data privacy in a multi-cloud solution is quite complex. It can be challenging to comply
across all CSP cloud services with respect to data protection requirements while identifying, monitoring,
processing, sharing and moving sensitive data. The implementation of policies, privacy and security
controls across CSPs can be important in meeting regulations, laws and governance rules.
— Assessment and compliance: CSCs should understand the regulatory requirements, laws, and
governance for developing a compliance strategy. They should consider the implications of using multi-
cloud solutions that involve multiple CSPs in potentially different jurisdictions. CSPs can have different
approaches to addressing compliance and regulation. Considerations include, though are not limited to,
data residency, data use, criminal laws, cross-border data flow and tax regimes. CSCs should involve
many stakeholders to formulate and design a strategy that satisfies many pertinent components such as
legal, technological and administrative.
— Workforce technical skills: Incorporating public cloud services provided by different CSPs would
require the CSCs to have workforce with sufficient skills to operate, maintain and handle the diverse
cloud services and technologies involved.
7.6 Multi-cloud management
Multi-cloud management includes managing the use and operation of multiple public cloud services from
two or more CSPs. Since the CSPs or the cloud services that they offer are not necessarily aware of each
other, the primary responsibility for management of a multi-cloud solution lies with the CSC.

© ISO/IEC 2024 – All rights reserved
Different CSPs provide different capabilities, interfaces, data centre locations, provisioning mechanisms,
connectivity, security and access protocols. Ideally multi-cloud management would provide a consistent
way to manage the provisioning of cloud services across multiple cloud services and CSPs including:
— access
— security
— connectivity
— logging and monitoring of resources and services
While a multi-cloud manager need not be a separate operational entity, Figure 4 shows the capabilities
needed for such a multi-cloud manager.
Figure 4 — Basic functions of multi-cloud management
The multi-cloud manager, implemented by the CSC, is responsible for identifying the cloud services offered
by public clouds that meet CSC’s requirements and orchestrating any additional needs such as load balancing,
connectivity, high availability, monitoring and logging. The multi-cloud manager provides the means for
accessing, managing and operating the cloud services. The operational capability of a multi-cloud manager
can include the ability to manage the lifecycle of a multi-cloud solution. Annex A lists a few use cases that
illustrate the complexities of, and the need for, multi-cloud management.
8 Federated cloud
8.1 General
A federated cloud is a CDM in which cloud services are provided by two or more members of a cloud
service federation (CSF). A CSF is a collaboration among CSPs that is designed to support the sharing of
resources. To be part of a CSF means agreeing to the policies, rules, standards, mechanisms and federated
cloud SLAs (which are part of CSAs) by which the resources will be shared among the CSF members. In this
case, federated cloud SLAs represent cloud SLAs that are established internally in the federation between
member CSPs.
A cloud SLA is an agreement between a CSC and a CSP (see ISO/IEC 19086-1). A federated cloud offers cloud
services to the members of the CSF. In that context, the federated cloud SLA is an agreement between the

© ISO/IEC 2024 – All rights reserved
member of the CSF that uses the cloud service (and therefore has the CSC role) and the federated cloud
(which has the CSP role).
The existence of a federated cloud SLA does not preclude additional agreements between specific CSF
members.
Note that CSF members may offer cloud services to parties that are not CSF members. Such cloud services
are outside the scope of this document and can require a separate cloud SLA.
There is a great variety of ways that resources can be arranged within a CSF (see subclause 8.7). Some of the
more common elements that dictate how the resources are arranged include: the focus on the purpose of the
CSF; how identity management is managed; and how the resources are shared, discovered, managed, and
paid for by the users of the cloud service. It is possible
...