Navigating data residency and protecting sensitive data

All right, thanks everyone for joining today early in the morning. Did anyone do the 5k run? I wasn't sure if you could do the run, get back to the hotel, take the shower, come, come to see the awesome session on data sovereignty.

All right. Well, thanks for joining us today. Um the promise of cloud computing is utopian in the sense that your developer writes an application, you launch it in a nearby cloud region and everywhere you go in the world, you can run your application effortlessly with no friction. Well, for everyone that's sitting in this room, that's probably not the case, ok? It's not that easy because you're running your businesses and locations that are constrained by data sovereignty regulations and other regulations that dictate how you manage data and where and how you run your workloads, ok. Not only does this create headaches for your developers, but it creates, but there's real legal risk if you don't get it right? Ok.

So that's what we're here to talk about today. Uh I'm Mike Davis. I've helped almost 100 customers at this point deploy AWS Outposts. That's one of the services that's in the scope here um uh in support of of workloads that are constrained by data sovereignty regulations. And um Abir Nafa is our Senior ah ah Solution Architect. She's based in the Middle East where by the way, just about every country in the Middle East is in some state of deploying data sovereignty regulations. So she's very close to all those issues, all right.

Um and so what I'm gonna talk about is um uh I'm gonna provide a snapshot of where this industry is headed because we're working very closely with a lot of regu a lot of the regulators globally. Uh what we see is the trends there, what is, what is driving some of the diversity in these requirements. And then uh what I really want to do is turn it over to a beer who's going to talk about the architectural patterns in the way our customers have deployed so far using hybrid services, AWS regions and, and other things to go meet those requirements. Ok.

So, um looking at this space and all the diversity in here, here's some examples from Italy, from Vietnam, from Turkey, from Mexico, one that's focused on the financial services industry and interestingly even in the USA. So one of the oldest regulations that controls data movement and how you process data is the Wire Act of 1961 which was long before the internet was created. I don't think we can give them credit for that. But, uh, um, and it dictates how wagering is conducted. So, if you're doing sports betting, online, gambling, online, casino and so forth, things can't cross state lines. And so we'll actually have a customer example later on, uh, how, how regulations dictate how processing happens, but not necessarily how you manage pi i which can still go to AWS regions. Right. So there's a lot of diversity.

Um, this is not going away. We are now at 137 different countries that are in process or have already implemented. Uh regulatory frameworks that control uh data movement and processing Europe has generally been the epicenter of this. Um not surprisingly, um but new regulatory frameworks are continuing to launch globally and all of these frameworks are not necessarily created equal. Again, there's that friction for developers on, on how to manage this.

Um here's an attempt uh by an analyst to look at uh where the restrictions are the strongest we have China on the far left and where the restrictions are the are the least strong. And that's uh I believe that was Panama way over on the right. And um one of the interesting things is that even though the European Union is currently trying to enforce some consistency across the union countries have already taken things into their own hands. So if we look at um on the left, we have, I believe that's France and Germany over on the left with very strong controls and then we have Norway and Croatia way over on the right. Um so even within something like the European Union union, there's been a lot of fragmentation, ok? But this is now a permanent and expanding cost of doing business in a global market now.

Uh to understand what I meant by all regulations are not created equal. We need to understand that different regulators have different motivations, ok? And, and the first and obvious one is data privacy. Um uh everyone expects to see uh data sovereignty regulations that limits the movement of pi i, for example, um Saudi Arabia is a good, a good example there where basically all consumer information cannot leave the borders of Saudi Arabia. Um but then let's look at South Africa slightly different. They allow movement of data um within similarly regulated jurisdiction. So as long as you're, you're moving it into another jurisdiction that has responsibly, you know, solid controls on that data, you're allowed to transfer pi i um Egypt and India slightly different. Again, you're allowed to transfer pi i but only with customer consent. And so in their terms and conditions and application design, um that's more of a developer consideration, confidentiality driven interests um uh tend to be industry specific. So industry uh India's financial services industry allows you to transfer financial records out of the country for processing and temporary storage, but the primary copy needs to stay inside the country. Uh Korea is an interesting example because they view GIS data and semiconductor data to be nationally critical. And if you're in those businesses, you typically can't move that data outside your firewall. So it's not just a country border consideration, you know, finding a data center in a country border, you may need to move AWS into your own data center. Ok.

Um Saudi Arabia is another example where um they're very protective of their largest industry, which is oil and gas. Ok. So seismic data, for example, can't leave the borders of Saudi Arabia.

Um lastly, I would say uh independence driven interests and this is kind of a broad category, but um these are uh uh regulatory frameworks um such as in Vietnam where they want to assure primary processing of the data is conducted inside the country and that helps them establish a diverse and solid IT industry locally. Ok. So they're, they're looking after the health of particular industries uh elsewhere, a country might want to preserve the option to sever themselves from the outside world and operate autonomously. Uh and then independence, like in Vietnam, it's the idea that I want my industries and sectors to thrive and gain a competitive advantage uh by building technical skills and infrastructure locally. So collectively, this is what AWS thinks of as digital sovereignty.

So you may have seen our digital sovereignty pledge from November last the dates in there, November uh uh 2022 Matt Garman's uh blog post. I encourage you to go back and take a look at it. Um you'll also find a more recent blog post on our digital sovereignty pledge that talks about dedicated local zones. And that's a, that's a, a version of our local zones and outpost service um that we can talk about a little bit as one of our solutions for meeting data sovereignty requirements.

Um and then most recently our announcement of the European uh sovereignty uh cloud European sovereign cloud ESC is, is what we're calling it internally. And I'll touch on that in the next slide because there may be some questions there.

Um but the key points to, to, to make on our sovereignty pledge are that we, we're going to be giving customers uh all the control they need over data location, verifiable controls over access to that data, uh the ability to encrypt everywhere. Um we provide the real resilience of the cloud and of course, the shared responsibility model says you provide the resilience in the cloud.

Um we're also working very heavily with regulators. We have compliance teams working with regulators uh around the world, ok. And we're working to develop things like our certification for CISPE Cloud Infrastructure Service Providers in Europe, that's part of the GDPR framework.

Um uh and um and we're committing to innovation, for example, I'll give you some examples where um just recently we announced um residency data, residency guard rails as part of AWS Control Tower. Ok. So it, it's, it's very pervasive how especially in control plane mechanisms like identity access management, um landing zones, control tower, et cetera. We want to continue to be looking for ways to augment um you know, not just transparency and where the data is, but to also put guardrails in place so that a developer can't inadvertently uh trip up your company and, and violate the sovereignty regulation. Ok.

Um so the European Sovereign Cloud think of the European Sovereign Cloud. Uh a little bit like our GovCloud region in the USA where um it is an isolated region with, that's located in the EU, with EU operators uh with EU operations and support. Ok. It is a full-fledged region from a resilience perspective. So all that same redundancy and network connectivity and so forth. It's also a multi AZ uh region. Um our first European Sovereign Cloud will be in Germany. Ok. We announced that we are not yet announcing any other locations. Um uh we're not yet announcing the launch date, the go live date for it either. So sorry, I can't answer that question.

Um and one of the important things about w whether it's our GovCloud region in the US or the, or the European Sovereign Cloud is that it has an entirely isolated control plane, uh counting mechanisms and so forth uh from our regular AWS regions.

Um um and so this is a, a kind of an exciting development for us, a lot of options. All right.

Um so let me just spend a little bit of time talking about our services that, that are really in scope that a lot of our customers are using to meet their sovereignty requirements. Um you know, we kind of start with our regions. Uh we certainly have a lot of customers using AWS regions, even where they're bound by data sovereignty regulations. And if you can use an AWS region, that's always gonna be the best solution where you're gonna get economies of scale, diversity of services, uh and so forth. Ok. So we always look first to our regions, but even though we're now in over 100 and two availability zones, and we'll continue to expand that, we need to find ways to move more quickly, whether it's into new metro locations where we don't have regions or into your data center. Right? So that's, that's where these topics come in.

And we have, you know, so when the, if we look at this kind of as an end to end spectrum, we have on the far left, we have our regions on the far right. We have things like Snowball that can operate in a mobile and a disconnected environment. So our focus really here is kind of in the middle categories where how do we get into new metros? How do we get into your data center to support these requirements?

And so we first talk about AWS Local Zones. So if you haven't had an in depth discussion on local zones, think of it as an AZ local zones is a special kind of AZ. But instead of being 30 kilometers from kind of the central uh center of gravity of a region like us east, it might be 500 kilometers away.

You know, for example, our Dallas Fort Worth local zone is part of US East. So it's a kind of an extended tethered availability zone. So we now have either launched or in the process of launching in 36 new locations. And this has allowed us to move much more quickly as a company into new locations.

It is a fully managed infrastructure by AWS. It's pay as you go pricing, so on demand EC2 instances and so forth. From a developer perspective, it's great because obviously it's the same API mechanisms, control planes. And it's very easy to just land and expand in new local zones - 36 locations, I think 18, I counted this morning, 18 as of today are still in some state of rollout.

So you can expect to see updates on the new local zones as we get out there. But again, this has allowed us to move, it's a very significant investment from AWS. And you can imagine over the course of time that local zones end up being kind of a tip of the spear for AWS that as demand develops in some place like Delhi, we may end up continuing to scale that maybe there will be multiple zones created and eventually becomes a full-fledged region.

Outpost is the next interesting service here. And this allows us to bring fully managed services into your data center or into your colo location cage. We have a lot of customers that might be North American based, but they need to go operate in Indonesia, or some location where we don't have a region. We can drop outposts into a co location cage for them.

Now, what's important to think about here is that this is not a hardware sale, even though this is the same great hardware we use in our regions. It's very dense, it operates at high temperature, lots of good things there. We want you to think of this being a managed pool of capacity that we deliver for you and operate for you. So, installation maintenance monitoring is all included as part of this service offering.

We size these to meet your workload requirements - what type of EC2 instances, how much containers capacity, EBS storage, S3 storage, we build these to order and deliver them into your data center in over 100 countries today for outposts. So we support countries where there are no local zones. For example, we have customers that have started with outposts and then we've launched a local zone and they've moved into the local zone and we'll take the outpost back.

So there's lots of interesting use models that we're seeing out there. This is a connected service. It operates as an extension of an AWS region of your choice. And that AWS region is typically across that country border somewhere else. But that's we found that that's ok.

So does having that service link connection back to an AWS region violate data sovereignty regulations? In all the cases that we're aware of today, the customers that are currently deployed, the answer is no, that has not caused friction with regulators or auditors because you always know where the data is and where the application is running. Those are typically just control plane mechanisms.

What's really important about services like outpost is that we can deliver cloud services, right? So not all 200 services that run in AWS regions are available in outpost. But really the foundational services your developers need to run locally - EC2, containers, ECS, EKS analytics and EMR, elastic cache, load balancing with ALB, databases. So SQL Server, Windows workloads work great and so forth. There will always be more to come on that roadmap.

One of the important philosophical points I wanted to make is that the control plane mechanism operates from AWS regions. That includes things like pushing out software patches automatically and rigorously out through our Nitro instances that are running at the edge in the outposts. And that provides a very important consistency that your developers need - APIs will always behave the same way. It's the same IAM, it's the single global source of truth and identity and access management, encryption, key management.

One of my favorites here is Resource Access Manager because RAM, which is hosted from the region, is the service that allows you to subdivide a service like outposts into sub accounts, and provide a multi-tenant environment for a shared services environment. So you get all the same richness that you would get in an AWS region as far as control plane services, providing governance for those edge services running in AWS Outposts.

A couple of customer examples and then I want to hand it over to Abir. NaturalSoft is an interesting one - there's a theme that you're gonna see here when you're a provider wanting to expand globally, but everywhere you want to go, you see a new regulatory framework that's potentially creating friction for your business.

This is a company that started in Spain. They were very successful winning and providing new software packages into clinical health care, hospital environments and so forth. And they're so successful now, they're getting a lot of demand globally for their software and running up against these digital sovereignty requirements.

So they deployed in local zones primarily. And they actually migrated, they went down the path of deploying run of the mill hardware VMware clusters and so forth in colo location cages. But if you think about the time and cost to negotiate those contracts, the potential configuration skew across all these diverse locations, it made it so much easier for them to migrate their workloads in local zones, which is just on demand, drop your armies, you land and expand your service is up and running in the cloud. It's the same software stack everywhere you go.

So Chile, Argentina, Peru, Miami, and now they're looking at other local zone locations. In fact, they're starting to orient their sales and launch strategy for their business around where we're gonna be landing local zones, because they know that's such an important operational impediment, getting that infrastructure up and running and local zones just makes it so easy for them.

The next one is in that gambling and betting and wagering space. FanDuel is the world's largest real money gaming online wagering company for sports betting and so forth. And if you've been into any of the casinos around here, looking at watching the sports, you'll see their name come up really strongly.

And this is a case where in the USA, the US Wire Act and local state deregulation activities really force these companies to go through a state by state process of launching infrastructure. The striking of the bet in a sports game, if you're betting on a football game, for example, and you decide if that's soccer or American football, that's up to you depending where you're from, has to remain within the borders of that state.

So if you want to go operate in the state of Colorado, then you need to have infrastructure there in Colorado. FanDuel is a great example of where they built a template around AWS Outposts, and that's where they deploy their production instances. They do test and dev in AWS regions, they drop their Outposts into an Outpost and they launch as soon as they get the green light from regulators.

In this case, that time from the green light from the regulator to generating the first revenue is crucially important in this industry - it's first mover advantage. And so we've gotten it down where we can get the Outpost in place, they can drop their armies and launch their business and generate their first dollar of revenue in - it went from like 15 weeks using traditional infrastructure to 8 days.

They actually got much better application performance using Outposts - how they use EBS, how they use containers and EC2 and so forth, they were able to accelerate that part of their business. But the real win there was that time to market and the ability to land anywhere with a very consistent template, both the infrastructure template as well as the software and the governance layer that continues to run from AWS regions.

So that's a lot of background on where we are in the data sovereignty space. I want to turn it over now and talk much more deeply about the technology and the architecture. Abir, this is for you.

Thank you very much. Hello everyone, this is Abir Nafa based out of Dubai as Mike said. Happy to have you here today as we dive into this. I want you to have two takeaways:

1. Identifying in scope data for your business is a pivotal step that affects every aspect of your design and probably investment.

2. Data residency is not black and white, it's a spectrum with shades where each scenario differs from one industry to another, from one country to another and even from one organization to another, because your organization impacts the requirements around data residency.

As we navigate in those scenarios we are going to uncover how the continuum of the cloud that Mike shared with us enables and empowers you to meet your regulatory requirements in an efficient manner.

In key scenarios involving in scope data, we found that it can be stored outside your jurisdiction - that can either happen with the proper consent of the customer or when the data can be stored outside the country with a country that has the same standards or higher.

Having said that, would you consider moving your data outside the country? When you face scenarios like this, I think you should think of AWS as a big toolbox where you have in the cloud a wide array of services that enables you to virtually do anything you might need.

So keep the region, keep the users of the region as the forefront of your considerations, especially when compliance can be achieved with customer consent or some regulatory bodies' approval to have your data outside the country. Why? Because you have control over your data, the location of your data in the region, viable control over the data access - who can access what, the ability to encrypt everything everywhere and the resilience of the cloud.

In different situations, we have encountered that regulatory requirements demand the primary servicing copy must reside within your jurisdiction, within your country. Picture this - if you basically can have the data processed outside the jurisdiction of your country, yet the data just needs to be within your location.

AWS recognizes this need and that's why we provided you with the continuum to address those requirements, allowing you to maintain compliance while leveraging the power of the cloud.

As Mike mentioned, AWS has 36 local zones worldwide. If you are in an area with one of those, it's like having a special cloud within your jurisdiction - pay as you go, unified management and governance solution, security and protection services. Only regulated data, again in scope data must be identified, only regulated data is advised to be on local zones in such scenarios.

Another option you have is deploying the workload on Outpost whenever it's available. Of course, think of it like bringing a piece of the cloud right at your doorstep. Deploying to Outpost means you are making up the most of the cloud capability in the region while having other capabilities within your premises.

Now, you might be wondering what if I'm operating in multi jurisdiction. Let's paint a picture of a solution for that. Imagine you are in an ecommerce business operating in Country A and Country B with a digital wallet. As part of your system regulations require you require that the wallets from each country to be stored within their respective countries.

Now imagine a customer of yours. A customer you have, let's call her Emma. Emma accesses your application in the region. She keys on her credit card information, the application process, the information, the business logic will, will identify the regulated details, saves or stores, the regulated data within the region because the non regulated data within the region because that's an important piece separating what is regulated from non regulated data you have within solution within your solution.

So you take the power of all the services we have in the region while the regulated data must be stored within Country B in this case, the logic in within your business identified through the card scheme that this card is Emma's card belongs to Country B. The design allows you to segregate regulated data, effectively manage the business logic centrally and avoid significant additional investment in Country B instead of having all the investment happening in each country for, for the whole workloads, you might have to build your ecommerce business. You have just the regulated data there.

Deregulated information like credit card info, credit card details the name, the expiry tokenization we found with the regulatory bodies that tokenizing the regulated data is acceptable. Masking is not again, you need to work with your legal team to identify this, but tokenization is important here so that you manage to correlate between your, your main solution, the centralized one and the one in Country B in this case, it's, it's a good practice to anticipate the traffic expected between the region and Country B leveraging Outposts in this case over the service link.

Another scenario you might think of is what if I can't operate outside the jurisdiction and I can't process my data outside my country. In this scenario, you still can split the nonregulated details from deregulated details that you have.

And let's paint a new picture that Mike shared with us regarding the gaming industry in the US. The regulated environment is quite complex and multi layered at federal level. The Wire Act restricts the interstate betting mandating physical presence of, of your customer, of the end customer to be within the state where the bet occurs and perhaps the usage of, of wire to, to have an interstate betting for each with, some states allow betting as, as you can see here, at state level, some of them allows you to have the data anywhere as long as it's within the jurisdiction of that state, other states are more strict and allows you to have the data within a specific location or colo location where even if you have a local zone in that, in that state, you cannot use it. In this case, you, the option is for you to go with Outpost.

Let's have a look how, how can you navigate these requirements again? Let's paint a picture that the solution might look like this in the region where you are operating in State A and State B. As you can see the application for deregulated information or details like sports book is has to happen within the state and Route 53 enables you to redirect the customer to the right application based on the geolocation of the customer.

So if your customer Mike is trying to do a bet or a wager, Route 53 redirected Mike to State A because he's physically there. And as Mike begins bet details for League X, the application will process the logic as usual safely regulated details of that transaction within the jurisdiction of State A. And you can, you can share the non regulated details like about this transaction that the interest of the league that Mike has with the, with your, with the your centralized solution and in the region.

Why would you need this? It, it helps you to have some centralized operations around piece of information that is less sensitive, not regulated, like the interest of your customer and have for example, a marketing campaign addressing Mike as with, with the league that he is interested in. The importance of sharing customer interest is enabling the efficiency of having one solution within the region centralized while keeping your compliant with the transactions happened within the jurisdiction, in this case, State A.

Having said that, the hybrid offering help you with the fast go to market, meet your data, residency requirements, consistency across environment, which, which means operational excellence for you, fully managed services with our Local Zones and the Outpost and unified APIs for your developers and operations.

Now, you can ask what if Mike said actually that the Outpost is a connected solution? How can I make sure that the data is not moving, how, how, how can I make sure that AWS does not move my data outside the location that I wanted it to be?

Yes, we have connected solutions. The management and control of AWS Outpost has to go between the region and the physical outpost within your premise. And this is an example, data flow of it. As you can see the management from the region goes back to Outpost telemetry for management because it's a managed solution about the Outpost, the health of it. The hardware metrics, the CloudWatch logs goes back to the region and you have the option to move back the data, the backups, the snapshots, the, the EBS snapshots as well. You have these options.

AWS does not move your data outside the jurisdiction yet. You have the capability to control. AWS Control Tower offers the easiest way to set up and govern a new, secure multi-account structure for you based on AWS best practices. And it enables you to build well architected multi-account structure features as guardrails, centralized logging monitoring is supported there with Control Tower data residencies, guardrail, you can specify the AWS region and regions your customer data is stored within service.

On the other hand, Service Control Policies are a type of organization and policies that you can use to manage permissions in your organization and limit or deny access for root users at account level to do X or Y or Z actions. And it's recommended when you have data residency requirements to segregate the data, segregate all the networking in the subnets of, of your workloads on Outpost. Deny the, the, the access of, of your users to move the data back to the region and deny the access of creating snapshots. And this is what we're gonna see in our demo.

Any questions? So, so far before starting the demo, ok. As you can see here, I'll be posing this is the dashboard. Oops, this is the dashboard. Oh my god, how to stop? I can't see it. Ok. Ok. This is the dashboard for Control Tower. As you can see, you can have a fully organized multi-account structure. You can see the summary of your organizational units, accounts. You have the controls, you configured for your organization, preventative controls, detective controls and proactive controls, if any.

Oh, I'm sorry about this. Ok. And with, with account factory, you can configure the creation and baseline, the accounts. You have the shared accounts, management logs and audits, landing zone, the deploying the landing zone, the well architected multi account structure would, would be there for you. You can see the the regions. I'm trying to stop, I'm trying it, it's moving to the, ok. Just a second. Give me a second.

Um I do apologize about this, ok. Uh that's better. So the shared shared accounts, the management log logs and audit are part of the well architected framework. When, when you, when you implement the Control Tower landing zone feature, as you can see here, the landing zone enables you to, to configure the regions that are available for you to operate and you enable disable the region you want. And you can see the compliance status there.

Now, I moved here to AWS Organizations because I wanna show you the one of the OUs that is connected to Outpost and this OU the data residency, one has one account that I'll be accessing through a separate browser before going there. I want to show you the organization unit and the policies that I have configured for this OU and this is the account that we can access and see what we can do.

And the policies here, SCPs Service Controlled Policies. This is the policy where you go one by one. I'll stop here. The first, the first policy, as you can see here is the one that denied copy to the region as you can see, it denies the import easy to import images, RDS backups, modify snapshots, attributes if and only if the backup target is not Outpost. So in, in, in such guardrails, you make sure that no one from your team can move the data from Outpost to the region as a backup for, for the RDS that you might have on Outpost. This is one of the policies that we have configured.

The second one is basically a policy that, that segregates the workload that you want to have for data residency, regulated components within Outpost. How you do that by making sure that no data can be saved into the region. It's part of the segregation process. So as you can see, SageMaker, Glue all, all types of services, visual services are stopped are denied for the second.

The third policy here is the denying storage in in Outpost in S3 buckets in the region because you need to make sure that you are using S3 buckets within Outpost. The last one denies the snapshot of EC2 instances, modification of those snapshots as long as you are not creating those snapshots with an Outpost subnet for for your workload. So you are actually segregating the data, denying the access for anyone to move it outside the Outpost.

And if you have further, further rules or further strict requirements, let's look at the second policy as it moves. Yeah, this is the subnet that I have configured on Outpost for the regulated workloads. This policy basically denies the creation of instance and running instances or create instance interface within the region unless it's working unless it's operating within the Outpost on this specific subnet created for residency requirements.

Now let's go to the account that might be the root account that might be operating within Outpost. This is the account. It's again, this is the account part of the organization unit that has the whole configuration set up. Let's go try to create an EC2 instance in the region. It's the public subnet. I just need to select the key pair. I stopped here as you can see, it's actually denying explicitly denied action per the service policy that we have configured. Can you see the error? Is it clear for you?

Ok. So with Service Control Policy, you have upper control over the accounts that you are that you good accounts that you have given your team to, to operate with them and you can set the and define the what, what operations that your team can do to avoid any intentional or unintentional access to do something that is not compliant.

Let's go to the second piece. This is an instance on Outpost. I wanna try to make EBS volume snapshots as well, and while creating a snapshot for your volume, you have the option to have it in region or on Outpost. This is on the region. And as you can see, the account has been explicitly denied to create snapshots on the region. At the same time when I tried to create the snapshots on Outpost, it's there. It's successfully created.

Lastly, let's go to the RDS. And here I have created two databases. If you remember one of the policies are denying access for RDS backup unless it's, it's going to unless the backup target is, is Outpost. So the first one, I'm opening the RDS, the databases. This is the first one that has the backup on Outpost and I'm trying to take a snapshot there. It's working. It's creating the snapshot at the same time. Let's take the second RDS that has the backup target on, on the cloud in the region. Test denied per, per the service policy.

Now, we can't go here those policies, those guardrails can be found here. Any questions?