Leveraging multi-cloud technologies and architectural patterns is becoming an increasingly important part of modern technology architecture. Whilst multi-cloud approaches offer numerous advantages, they also add complexity resulting in an expanded knowledge burden, additional access controls and an absence of replicable patterns.
SkySiege products are designed to operate across multiple cloud providers, and our extensive security experience spans all major cloud platforms and a good selection of smaller providers. We’ve also worked extensively in on-premises bare-metal environments, giving us a deep understanding of the underlying physical infrastructure of the cloud including running our own hardware for hosting our security assessment tools.
Our experts have been kind enough to summarise this introduction to multi-cloud adoption, outlining some of the reasons for adopting multi-cloud strategies and how they provide tangible business benefits.
Multi-cloud refers to the use of multiple cloud providers to host or constitute your technical services. While utilising a single cloud provider is still the most common architecture pattern, multi-cloud is gaining importance due to its ability to significantly reduce the impact of potential failures and offer a wider access to specialised tools unique to each provider.
Multi-cloud patterns can be as simple as keeping storage on one provider and compute services on another provider, however, this isn’t particularly useful as in this scenario failure on either provider would lead to service outage therefore increasing the risk of outages over utilising a single provider. When we discuss multi-cloud patterns we’re usually concerned with implementing architectural patterns that reduce the overall risk and increase the resiliency of the service. Usually this means the ability to host an entire service across any provider without loss of functionality. Whether these services run in parallel or can be rapidly redeployed depends on your use case, so long as you can switch between cloud providers and meeting your business obligations we would consider that a successful multi-cloud design.
The key universal benefits of adopting a multi-cloud strategy include:
Additionally, we would add three more advantages the we have regular encountered from our consultancy experience:
Given the rapid changes in the technology landscape, it’s increasingly valuable to decouple your services from individual critical suppliers. This offers several advantages, such as ensuring continuous up time even if your primary provider encounters issues. For example, Microsoft Azure has faced challenges with provisioning adequate IP addresses, preventing services from creating new resources. Similarly, AWS has experienced provider-wide outages including issues with Identity and Access Management services resulting in complete loss of access for customers.
An interesting aspect of cloud provider outages is the cascading effect that outages cause due to immediate reactions by technical teams to attempt to restore service. This usually exacerbates the outage as operating infrastructure is captured quickly and other services handle increased activity as customers attempt their own solutions.
By having an alternative cloud provider as a fully provisioned fallback, you can maintain service continuity, regardless of disruptions with your primary provider. This approach removes your business operations from being tied to a single provider’s up time as well as removes the business and technical teams from being caught in the configuration stampede of affected customers attempting fixes.
Using multiple cloud providers offers an additional benefit that may not seem as critical, but is more likely to occur than prolonged cloud provider outages whilst potentially being more devastating to an individual organisation. While cloud providers do experience occasional outages, they are highly motivated to minimise downtime as these outages always affect multiple customers. However, this motivation doesn’t extend to problems that are isolated to your specific service or account. For instance, account compromises or accidental actions within a cloud provider’s environment can severely impact your service but will understandably not warrant the attention and effort that provider-wide issues receive.
In our consulting experience, account wide issues happened more often than provider outages but impacted services just as dramatically. These account wide impacts included issues such as:
All of these incidents can result in the same level of service obliteration, however responsibility for management and recover falls to the organisation and not the cloud provider.
While multi-cloud adoption can’t prevent such incidents, it can mitigate their impact reducing the blast radius of these effects to affecting only one instance of your service rather than the entire service. For example, if you’re running an application on an AWS EC2 instance and it’s accidentally deleted, your multi-cloud presence ensures that such a deletion wouldn’t affect the Azure virtual machine running the same service and acting as a fail over. Designing a multi-cloud solution naturally encourages treating these environments separately, eliminating the possibility of account wide issues affecting all your resources.
There are similar benefits to consider from a strategic concern such as the business, legal and international considerations of being wedded to a single provider. Organisations might face restrictions or find it difficult to work with certain cloud providers due to changes in business strategy, trade laws or government regulations. This could also come from the cloud provider’s side, resulting in providers altering or discontinuing services, impacting your business. An exotic example we’ve encountered involved a startup organisation purchased by a large retailer who had their entire service hosted on Amazon Web Services. The retailer did not want a connection to an Amazon owned provider therefore requiring the acquired service to be migrated to another provider, freezing all development and bringing all hands to task to deliver the migration under time pressure.
Similarly, multi-cloud flexibility can safeguard against a cloud provider decommissioning a key service you rely on. For example, AWS no longer accepts hosting Git repositories via its CodeCommit service. If CodeCommit was your critical code hosting solution, having a multi-cloud strategy would allow for a more graceful transition to another on-boarded supplier, turning what could have been a disruptive change into a manageable adjustment without the need for a complete architectural overhaul.
Not all cloud providers offer the same level of services, and by utilising multiple cloud providers, you gain the flexibility to select the best solutions for your specific needs. This allows you to leverage the top-performing services while also optimising costs. For example, at SkySiege we have a strong preference for AWS services like Route 53, AWS Lambda, and EC2 because they provide reliable, long-term infrastructure that fit well into our architecture patterns.
We also find that Google’s Kubernetes Engine (GKE) and Cloud Run offer a more accessible platform for hosting longer-lived, distributed services. For instance, we prefer Google Cloud Run over AWS Fargate or AWS Elastic Beanstalk when hosting persistent services that don’t fit well within Lambda’s run time constraints. Additionally, simpler services like DigitalOcean Spaces often appeal to us over AWS S3, particularly due to S3’s growing complexity across both pricing and configuration. DigitalOcean’s straightforward pricing is hugely appreciated.
These preferences aren’t necessarily recommendations, but they highlight how multi-cloud architectures give us the flexibility to make these choices. With a multi-cloud strategy, we can adopt the best tools and services that suit our needs, helping us deliver more efficient and cost-effective solutions.
A common challenge when working with larger clients is navigating the procurement process, which can become a lengthy and uncertain endeavour without a clear resolution. Establishing multi-cloud access and operations in advance removes this time pressure from the procurement process ahead of technical or business pressures requiring utilisation of another cloud provider.
Managing a multi-cloud environment begins with deploying your service on another cloud provider. This process forces you to fully account for all the resources that make up your service and successfully release it on a different platform. Not only does this demand clear categorisation of your service, but it also requires you to manage redeployment and gain a deeper understanding of your architecture. For instance, services using different databases must ensure compatibility by assessing the database versions and customisation’s that may not translate easily between providers.
Similarly, for serverless functions like AWS Lambda, which are specifically coded for AWS’s run time, migrating such services directly to another cloud isn’t possible. Refactoring is required to maintain functionality resulting in two different code bases. This analysis and cataloguing is a key aspect of adopting a multi-cloud strategy, as deploying and migrating services across providers will reveal dependencies or issues that have accumulated over years of relying on a single cloud that may not be apparent or known in your architecture.
Even simple patterns such as replicating backups to another cloud provider will require consideration of what your backups are, how often they are created, and whether they can be exported in a format that works across platforms. For example, database snapshots are typically cloud-specific, designed to restore within the same cloud’s ecosystem. If your snapshot is not easily exportable as a full file, it may not be usable on a different cloud provider, exposing an implicit reliance on your current cloud infrastructure for your backup data.
By undertaking a multi-cloud approach, your teams are required to gain a comprehensive understanding of your service’s structure and dependencies, enabling you to confidently take full ownership of both your service and its hosting environment having released to other cloud providers.
A key indicator of strong service ownership is the ability to strip down and rebuild a service from scratch, potentially in a different environment. If this process can be done quickly, ideally near-instantly, and all service components are well-documented and accounted for, the service is almost guaranteed to have robust management and resilient service operations, which directly benefit business continuity. The ability to redeploy core technical services without being locked into a single cloud provider or architecture infers technical control and capability.
Running a multi-cloud architecture mirrors the rebuild process as it requires the full mapping of your service and the proven ability to recreate and maintain it. The ideal scenario is to have a live service that can automatically fail over to another cloud provider without manual intervention. Whilst achieving this level of automation is rare, we have seen services capable of rapid redeployment on alternate platforms. This is an achievable goal to aim for.
By being able to meet this standard where services are known in their entirety and can be provably controlled, organisations have full control over their product, granting realistic opportunities to refine or reposition services. For example, Software-as-a-Service (SaaS) providers are asked whether they can offer dedicated, on-premises versions of their services. Running a service across multiple clouds proves the capability to host on various infrastructures, allowing you to confidently offer tailored versions to clients without hastily retrofitting a new on-premises solution under sales pressure.
This flexibility not only opens new sales opportunities but also unlocks new client demographics. Banks, governments, and regulated entities are often interested in controlling their data, and offering self-hosted versions of your service becomes a lucrative option. Multi-cloud capability enables your technology team to meet these demands, as the process has been rigorously tested across different environments.
Another example scenario we’ve encountered are retailers who do not want to use Amazon’s platform. By being able to host your service on a non-competing cloud provider, you open up opportunities to partner with major players that might otherwise avoid your offering.
Our next article focuses on some simple multi-cloud patterns which provide easy to adopt processes which are less likely to require major shifts in your services’ operations or your organisational burden. Which you can read now!
In our previous article, we explored the benefits of adopting a multi-cloud architecture. In this article, we’ll deliver as promised some introductory architectures that can serve as your starting point for adopting a multi-cloud infrastructure.
multicloud security architecture
An AWS security assessment evaluates the security posture of an AWS account, analysing the cloud resources contained in an account and their configuration. The goal of this assessment is to find any resources or vulnerabilities that can be maliciously utilised to compromise any services hosted in the AWS Account. Minimising these vulnerabilities will result in the hosted services being more resilient to attack and therefore adopting a stronger security posture.
vulnerability scan cloud aws
If you are hosting applications on Amazon Web Services (AWS), it is important to consider the impact to AWS from your penetration testing. A key aspect of this consideration is determining whether what penetration testing can be safely conducted on the AWS platform without advanced permission and which testing should be abstained from without prior agreement.
penetration testing cloud aws