Having achieved almost consumer-grade accessibility, public cloud adoption is increasingly driven by individual business functions.
Enterprise teams no longer need to understand how the technology works, or even where the service operates from. To buy a cloud product they just need a web browser and a credit card. But this level of simplicity raises challenges of its own when it comes to regulatory concerns.
The flexible-by-design nature of the cloud, where the hardware on which data resides, could be anywhere in the world, doesn’t always make it easy to comply with national laws that are based on fixed geographical boundaries.
Furthermore, for a cloud-first business, the cloud offers an attractive way to expand beyond regionally-focused operations and achieve a global footprint. But this means having clustered cloud operations in only one country or region can expose the company to risk of disaster in the event of operational failure.
As a result, many businesses will replicate their infrastructure across multiple regions, again, opening themselves up to the headaches of meeting data localisation laws or data residency requirements.
Location, location, location
Most data protection legislation differentiates between the data controller and data processor and apply different obligations based on the roles. In the case of the EU’s General Data Protection Regulation (GDPR), the data controller is responsible for appropriate technical and organisational measures to protect data against alteration, disclosure, or access.
Processing of the data is typically carried out by a data processor on the data controller’s behalf, and the data controller is also responsible for choosing a processor that provides sufficient technical and organisational measures to protect the data in the same way.
When it comes to where the data actually resides, that is, the hard drives on which the bits and bytes are stored, the GDPR requires that all data collected on citizens must be either stored physically in the EU, so it is subject to European privacy laws, or within a jurisdiction that has similar levels of protection (such as the UK).
Of course, the reality is not so simple. The evolution of local data privacy laws is increasingly linked to more nationalistic views of IT resources, and specific regulations and laws can also set out data residency requirements. Even in the EU, individual countries modify their own data privacy laws.
So, while it is one thing to understand local laws and requirements, it’s quite another to know exactly where all data is across all applications.
Cross-border cloud considerations
The adoption of cloud has displaced decades of on-premise, centralised data centres. With an on-prem model you knew exactly where the data was, whereas a cloud approach permits data to be widely distributed and carried through international borders.
Confusing matters even more are the different definitions, terminologies, and infrastructures deployed by all the major cloud providers. For example:
- AWS has availability zones and regions. Each AWS region consists of multiple, isolated, and physically separate availability zones within a geographic area, unlike other cloud providers, which often define a region as a single data centre.
- Microsoft Azure has regions and geographies, which “define disaster recovery and data residency boundaries” for Azure. Its availability zones are physically separate data centres within regions.
- Google Cloud Platform offers regions and zones, where regions are independent geographic areas that consist of zones. Typically, a GCP region will have three or more zones allocated to it, allowing organisations to distribute apps and storage across multiple zones to protect against service disruptions. These zones are physically located in the same or a nearby data centre.
What you need to be aware of when dealing with regions and zones, is where the data is physically stored and if clusters of infrastructure within those regions and zones might see your data transferred across international or compliance-relevance boundaries, either during normal operation or in the event of a local or larger outage.
When it comes to buying Software-as-a-Service (SaaS), the picture gets even more complicated as you are effectively buying a cloud service through a third party where an application is built on top of or hosted on a public cloud instance.
In this case, it is the SaaS provider or third-party service which decides where data is stored and just because the app is built on AWS or Azure, it does not mean the data is hosted where you think it is. So, customers need to check the data residency terms of service and check what would happen in the event of an outage.
Multi-cloud connectivity and compliance
While a multi-cloud approach can potentially give you more choice in terms of data residency and redundancy, it introduces its own challenges in terms of connectivity and complexity.
For some applications there are considerations that may require hosting in an on-premises data centre or a cloud instance located in a specific geographic location, especially those that have strict geographic stewardship requirements such as data that needs to be hosted in a specific location due to GDPR.
For example, there might be the need to move stored sensitive personal data from an Azure environment in a European country, where it is required to rest for GDPR purposes, to a Google Cloud Platform environment in another country to be computed, before pushing the results back to Azure for storage.
This introduces more network complexity because provisioning direct connections to multiple clouds is no easy feat. As it is, as digital transformation strategies mature, organisations increasingly require the ability to transfer data between multiple clouds or across multiple geographies, but cloud providers do not generally make it easy to interconnect different clouds.
In its “Predicts 2022: Connecting the Digital Enterprise” report, Gartner states that interest in public cloud networking and multi-cloud networking has increased dramatically in the last 15 months, largely because the native networking capabilities of public cloud providers vary greatly and are insufficient for many enterprise use cases.
In short, the connectivity infrastructure offered by major cloud providers is not designed to work seamlessly together with other providers in a multi-cloud world.
Multi-cloud data transfer with CloudRouter®
Console Connect’s new CloudRouter® addresses some of the challenges with multi-cloud connectivity and regulatory compliance by creating a private and secure meshed network for your multi-cloud environment.
Console Connect provides access to all the world’s largest cloud platforms, including AWS, Google Cloud, Microsoft Azure, Oracle Cloud, IBM Cloud, Alibaba Cloud and more, with real-time network provisioning and high availability of bandwidth.
- Instantly connect any cloud to any cloud or any cloud to any location – without the need for dedicated hardware.
- Choose from more than 150 cloud on-ramps worldwide, with new locations being added all the time.
- Enhance the performance of your applications with private connections to your SaaS provider.