Back
Cloud, Oct 20, 2022

Enterprise cloud service offering: Key challenges and how to mitigate them

Credera

The aim of this article is to highlight the key challenges associated with the enterprise cloud service offering and provide tips on how to mitigate them.

What is the enterprise cloud service offering?

Enterprise cloud is a computing model where an enterprise can use virtualised IT resources from a public or private cloud services provider. These resources can include storage, virtual servers, networking, security components, and serverless computing.

In larger enterprises, there are normally cloud centre of excellence teams who can provide the cloud service offering and help onboard different business units to the cloud. They provide different teams with access to the cloud resources, and ensure provisioned workloads meet compliance and security standards.

Read next: How to create an Enterprise Architecture function

Outcomes

Below are some of the key outcomes that an enterprise would typically like to achieve from its cloud service offering across different business units.

Outcome Description
Agility and efficiency To drive greater agility/ time to value and efficiency
Innovation using cloud-native features To take advantage of cloud offerings beyond core infrastructure
Appropriate level of security controls To ensure appropriate security is a part of the workload
Visibility of costs To keep track of cloud costs across the enterprise and ensure all costs are attributable to a division, department, or a workload
Observability To ensure all workloads have observability defined and implemented to help with incidents resolution when needed


Key challenges

At the start of an organisation’s cloud adoption journey, there are usually a few teams that will start using it. Managing the cloud is simple as there are only a few accounts and workloads deployed there. However, as cloud usage grows across an enterprise, several key challenges can begin to emerge if they are not tackled as part of the initial landing zone designs.

Single or few accounts used by different business units

While a single account works in the beginning, it is not sustainable as the cloud usage grows across business units and teams.

Complexity in managing common security guardrails as they are applied at individual account level

Initially, it is okay to apply common guardrails at account level, but to ease and simplify management, it is better to apply them at higher levels such organisation units in AWS, management groups in Azure, and folders in GCP.

Workloads deployed in management accounts

This can be a security risk as privileged operations are normally allowed in the management accounts.

Production and non-production environments sharing the same account

Production and non-production workloads have different security profile and needs, hence putting them in the same account could be a security risk.

Several dozen workloads deployed into a single account

This makes management, security, and access control more complex.

Complexity in managing individual users without federated access

Lack of a Single Sign On (SSO) solution means individual users accounts must be created and maintained by the cloud team, which is cumbersome, error prone, and non-sustainable in the long-term for larger enterprises.

Manual deployments to production workloads

Whilst this is initially okay for trying out cloud resources and for quick POCs, an organisation needs proper CI/CD processes and tools in place to scale the cloud adoption.

Lack of central security hub

Managing security incidents and having an oversight across dozens or hundreds of accounts can be challenging. It requires a central security hub where security incidents from all accounts can be centrally managed and acted on.

No availability for security hardened common VM templates (a.k.a. machine images)

By reducing variability, we can improve standardisation and implement security best practices.

Lack of traceability for production incidents

Workloads are deployed but there is no properly defined observability (logging, metrics, and alerts). Without these, it is very difficult to resolve production incidents.

Weak security controls and no threat modelling for deployed workloads

Deployed workloads have poor security posture and lack defence in depth controls applied at different levels. These can lead to security incidents and data leaks that could be quite costly and cause significant reputational damage in the long run.

No oversight for cloud costs and difficult to attribute costs to different entities, and workloads

Cloud costs can easily spiral out of control without proper oversight, and it is difficult to track and reduce costs without proper attribution.

Trying to use cloud as a traditional data centre

Cloud offers agility, and a lot of IaaS, PaaS, and SaaS solutions that can be leveraged together in innovative ways to design efficient, cost effective, secure, and scalable solutions. However, using cloud as a traditional data centre results in rigid controls, inefficient use of resources, lack of agility and efficiency, and stifles innovation.

How public cloud helps to manage and govern environments

All ‘Big 3’ public clouds provide capabilities to their customers to help manage, structure, and govern large-scale enterprise environments as their cloud usage grows. Using these management capabilities, an enterprise can structure its cloud resources appropriately to manage complexity and allow cloud usage to scale rapidly across the enterprise.

Some of the benefits of using these governance controls include the ability to quickly scale your workloads by programmatically creating resource containers such as org units/accounts in AWS, folders/projects in GCP, and management groups/subscriptions/resource groups in Azure.

By applying governance policies at higher abstraction levels (org units in AWS, folders in GCP, and management groups in Azure), you can give freedom to teams to build their workload resources whilst staying within the boundaries set by policies at a higher level. For example, you can set policies to control which cloud regions could be used to provision company’s cloud resource and place restrictions to avoid someone accidentally switching off audit logs or security components.

You can centrally enforce your recommended backup, configuration, and security requirements by enforcing them at the higher level in the resource hierarchy (as mentioned above). This allows you to centrally secure and audit your environments.

Permissions management and access control can be simplified by applying policies at the right level in the resource hierarchy.

Amazon Web Services (AWS)

AWS uses concepts of organisation units and accounts to structure and manage an organisation’s teams, projects, and cloud resources:

  • Organisation: Root of the hierarchy is organisation / company.
  • Organisation Units (OU): OU in AWS can be used to create a hierarchy of business divisions, teams, and different product lines. Different policies can be applied at these levels.
  • Accounts: Accounts are the containers for all cloud resources. E.g., A Product 1 (OU) can contain three accounts, and each account can contain environment-specific resources.

Enterprise cloud service offering - AWS

Microsoft Azure

Azure uses concepts of management groups, subscriptions, and resource groups to structure and manage an organisation’s teams, projects, and cloud resources:

  • Organisation: Root of the hierarchy is organisation / company.
  • Management groups: These could be used to create a hierarchy of business divisions, teams, and different product lines. Different policies can be applied at these levels.

Resource groups: These are the containers for all cloud resources. E.g., A Product 1 (management group) can contain three subscriptions, and each subscription can contain environment specific resources.

Enterprise cloud service offering - Microsoft azureGoogle Cloud Platform (GCP)

GCP uses concepts of organisation, folders, and projects to structure and manage an organisation’s teams, projects, and cloud resources:

  • Organisation: Root of the hierarchy is organisation / company.
  • Folders: Folders in GCP can be used to create a hierarchy of business divisions, teams, and different product lines. Different policies can be applied at these levels.
  • Projects: Projects are the containers for all cloud resources. E.g., A product 1 (folder) can contain three projects, and each project can contain environment specific resources.

Enterprise cloud service offering - GCPDesign principles for enterprise cloud service offering

Along with the governance options available in the public clouds noted above, we have successfully used the below design principles to tackle the challenges that arise from the enterprise cloud service offering when using cloud at scale within large enterprises.

Enterprise cloud service offering

Design Principle Rationale
Devolve account structure To promote innovation and agility
Organise cloud accounts based on security and operational needs To meet security and operational needs
Apply common security guardrails to org units (OU) in AWS, folders in GCP, and management groups in Azure (rather than accounts/projects/subscriptions) To simplify management and application of those controls
Avoid deep org unit (AWS), folder (GCP) or management group (Azure) hierarchies To avoid overly complicated hierarchies that are difficult to maintain
Avoid deploying workloads to the organisation’s management account To prevent privileged operations from being performed by the workloads (without any policy restrictions)
Separate production from non-production workloads Both have different security profiles and needs
Assign a single or small set of related workloads to each production account To simplify access management, streamline change approval process, and limit scope of impact due to misconfigurations
Use federated access To help simplify managing human access to accounts
Always use automation for new accounts creation, environments, and CI/CD To support agility, consistency, and scalability


Security

Design Principle Rationale
Use a central security org unit/account where all security-related alerts and notifications are sent This will act as a security hub to allow oversight and management of incidents in a single place
Security hardened baseline golden images are used to create new cloud infrastructure This promotes standardisation and best practice security enforcements
Enable traceability To help teams investigate and mitigate security and operational incidents
Apply security at all layers. Apply this to all layers (for example, edge of network, VPC, load balancing, every instance and compute service, operating system, application, and code) To provide defence in-depth with multiple security controls
Implement a strong identity foundation, centralising identity management and eliminating reliance on long-term static credentials To provide strong authentication and easy of identity management


Cost optimisation

Design Principle Rationale
Ensure all costs can be easily tracked and attributed to a division, department, workload, or environment by implementing an appropriate tagging policy To control costs and make them visible
Adopt a consumption model, paying only for the computing resources that you require and increasing or decreasing usage depending on business requirements To benefit from cloud and its flexibility to reduce OpEx
Implement cloud financial management and invest in cloud financial management / cost optimisation To control cloud costs and provide oversight


Observability

Design Principle Rationale
Observability is considered as part of design (rather than an afterthought) To make it easy to investigate incidents


Performance efficiency / innovate with cloud-native solutions

Design Principle Rationale
Leverage managed solutions offered by the cloud provider To democratise advanced technologies and make advanced technology implementation easier for your team
Use serverless architectures (where possible) To remove the need for your teams to run and maintain physical servers for traditional compute activities

 

In a nutshell

By improving the enterprise cloud service offering governance and structure and adopting the above design principles, an enterprise can truly reap the benefits of the cloud while avoiding some of the challenges that are highlighted in this article.

If you would like us to provide design critique for your enterprise cloud service offering or need help with optimising and improving it to meet business needs, please get in touch.

Download our latest cloud whitepaper

Read more:
Podcast: Maximising your organisation's cloud transformation journey
AWS Cloud Governance Part 1: Three keys to starting your AWS governance journey
AWS Cloud Governance Part 2: Centralised account management and organisation controls
AWS Cloud Governance Part 3: Compliance, security, & cost management
AWS Cloud Governance Part 4: Monitoring and observability
Cloud computing: Getting more out of serverless


Have a question?

FIND YOUR SOLUTION

Let’s find a solution that fits your challenge.

Contact us