Considerations when migrating from AWS Middle East Region to EU Region — from data protection, contractual, and tax perspectives

I am Shiga from Berlin. Recently, I returned to Japan temporarily, and came back to Germany with the onslaught of pollen.

On March 1, 2026, due to escalating tensions in the Middle East, AWS Middle East (UAE) Region (ME-CENTRAL-1) and Middle East (Bahrain) Region (ME-SOUTH-1) data centers suffered physical damage. AWS strongly recommends affected customers migrate to other regions.

This article outlines key considerations that are often overlooked when businesses providing services to the Middle East, Africa, and Turkey migrate to AWS European regions (Milan eu-south-1, Frankfurt eu-central-1, etc.). I'll explain why "just moving servers" is insufficient from regulatory, contractual, and tax perspectives.

What Actually Happened

In the early hours of March 1, 2026 (PST), as a result of military conflicts in the Middle East region, AWS data centers in UAE and Bahrain suffered physical damage from drone attacks. Structural damage, power supply disruptions, and water damage from firefighting efforts were reported.

AWS officially announced the following responses:

• Prioritizing recovery of tools to support data backup and migration from affected regions
• Recommending customers execute DR plans and switch traffic to other regions
• Suggesting alternative regions in the US, Europe, and Asia Pacific

What was previously considered a theoretical risk—cloud infrastructure exposed to physical geopolitical risks—has now become reality.

Three Key Considerations When Migrating to European Regions

For services targeting the Middle East and Africa, including Turkey, Milan (eu-south-1) or Frankfurt (eu-central-1) are reasonable choices from a latency perspective. Milan in particular is gaining attention as a region because most submarine cables from Africa make landfall in Italy. However, placing infrastructure within the EU has legal and practical implications beyond simply relocating servers.

GDPR's Scope — Is "No EU Resident Users Means No GDPR" Really True?

The scope of GDPR (General Data Protection Regulation) is determined not by the physical storage location of data, but by the location of data subjects and the targeting of services (Article 3).

This means that even if you store data in the Milan region, GDPR Article 3(2) requirements aren't met if data subjects aren't located within the EU. For services targeting only Middle Eastern and African users, this understanding is generally correct.

However, there are three important points to consider:

Point 1: Risk of EU Residents "Mixing In"

The assumption that "target users don't include EU residents" is often a service design premise rather than a technically guaranteed fact. Even for services targeting the Middle East and North Africa (MENA) region, there's a significant possibility that users originally from these regions who are studying, working, or living in the EU might access the service. Germany has a Muslim community of about 5 million people, mainly of Turkish origin, and France has about 6 million people, mainly of North African origin, who regularly use online services targeted at their countries of origin from within the EU.

Unless you implement geo-blocking, you aren't technically excluding access from within the EU. In this case, there's a possibility of unintentionally falling under GDPR Article 3(2).

Point 2: Strict Enforcement Stance of Italian Authority (Garante)

Choosing the Milan region means conducting data processing within the jurisdiction of the Italian data protection authority, Garante per la protezione dei dati personali. The Garante has been particularly active in enforcement within the EU, finding GDPR violations regarding the use of Google Analytics in 2022 and temporarily banning ChatGPT in 2023.

Even if GDPR doesn't directly apply, the possibility of inquiries from Garante if incidents occur on EU-based infrastructure cannot be ruled out. It's prudent risk management to establish contact points and procedures for such inquiries in advance.

Point 3: ePrivacy Directive

For web-based services, there's another regulatory axis—the ePrivacy Directive. This regulation works independently but in conjunction with GDPR, and establishes consent requirements for placing cookies on devices. Websites accessible from within the EU may require cookie consent management regardless of users' nationalities or the service's target region.

After reading this far, you might think "So GDPR isn't relevant after all," but what's important is not whether the risk is zero, but how the cost of response compares if risks materialize. If the cost of preventive measures is relatively low, taking preemptive action becomes a rational business decision.

Operational Structure Within the EU — Is Placing Infrastructure Sufficient?

When using AWS European regions, Amazon Web Services EMEA SARL (Luxembourg entity)'s GDPR-compliant Data Processing Addendum (DPA) is applied as standard, ensuring contractual protection for data processing on AWS's side.

However, AWS only covers responsibilities as an infrastructure layer (Processor). Service providers' own responsibilities as Controllers—such as determining whether to notify authorities in case of incidents, responding to data subject inquiries, deciding when to conduct DPIAs—must be fulfilled by the company itself.

The practical challenge here is whether businesses without operational touchpoints within the EU can engage in timely dialogue with EU regulatory authorities and users.

Time Zone and Language Barriers

EU data protection authorities strictly enforce notification deadlines (GDPR Article 33: notification to authorities within 72 hours). If an incident occurs during European business hours, starting to respond after offices in Asia or the Middle East notice it the next business day would waste most of the 72-hour window. Having a system that can initiate responses within the EU time zone makes a substantial difference for compliance.

GDPR Article 27 — Obligation to Designate an EU Representative

If GDPR Article 3(2) applies (if the aforementioned "mixing in" risk materializes), businesses without an establishment in the EU are obligated to designate an EU representative under GDPR Article 27. Failure to designate an EU representative is itself a separate violation, so if you determine that "the possibility of GDPR application is not zero," preventively appointing a representative is a cost-effective measure.

Preparation for Future Regulatory Strengthening

The implementation of the EU Data Act (Regulation 2023/2854) strengthens freedom to switch cloud services and data access rights. Discussions on the European Cybersecurity Certification Scheme (EUCS) are also progressing, with certification requirements for cloud services within the EU likely to become stricter. While this benefits cloud service users, maintaining EU expertise to track regulatory trends in real-time and assess their impact on your company is effective for long-term risk management.

VAT and Tax Handling

When using AWS regions within the EU, value-added tax (VAT) processing is necessary.

When non-EU businesses contract directly with AWS EMEA SARL, the Reverse Charge Mechanism is expected to apply as a B2B transaction, but depending on the usage pattern, EU VAT registration obligations may arise. Particularly when providing services to end users within the EU (B2C), you may need to comply with the VAT One Stop Shop (OSS) system.

While AWS's invoices may handle VAT processing for the usage fees themselves, the tax implications of your own services within the EU require separate consideration. Consulting with partners familiar with EU taxation in advance can prevent unexpected tax risks from emerging later.

Beware of "Reverse Application" of Third-Country Transfers

An often-overlooked issue is access from outside the EU to data stored within the EU.

For example, if you remotely access a database placed in the Milan region from offices outside the EU for management and analysis purposes, this may constitute a "data transfer from the EU to a third country" under GDPR.

While Japan has received an adequacy decision from the European Commission making transfers legal, this adequacy decision assumes compliance with supplementary rules and doesn't automatically allow everything. If access is from countries without adequacy decisions, such as Turkey or Egypt, separate Standard Contractual Clauses (SCCs) need to be concluded. In either case, records of transfers and documentation of appropriate safeguards are required.

GDPR Compliance Is Not "Just for the EU"

While I've discussed the costs of GDPR compliance, from another perspective, building a GDPR-compliant data management system offers benefits beyond services targeting the EU.

Since its implementation in 2018, GDPR has effectively become the reference model for data protection legislation worldwide. Brazil's LGPD, Thailand's PDPA, India's DPDPA, Saudi Arabia's PDPL, Turkey's KVKK, South Africa's POPIA—all refer to GDPR's basic structure (data subject rights, legal bases for processing, cross-border transfer regulations, incident notification obligations) in their design. Japan's amended Personal Information Protection Act has also undergone revisions with GDPR consistency in mind to obtain and maintain EU adequacy recognition.

This means that once you build a GDPR-level data management system, most of the data protection measures required when expanding to other countries/regions are already covered. Each country's laws have unique requirements (localization requirements, consent methods, authority notification procedures, etc.), but these can be handled as "differential responses" from the GDPR baseline. There's a significant difference in workload compared to considering each country's laws individually from scratch.

While the migration from Middle East regions is prompted by geopolitical risk, entering the scope of GDPR—the most systematized international data protection framework—could ultimately provide a foundation for global expansion beyond the Middle East and Africa. As a byproduct of emergency response, this isn't a bad outcome.

Conclusion: Migration Goes Beyond "Infrastructure Relocation"

This AWS Middle East region incident represents the first case where geopolitical risks to cloud infrastructure have materialized. In such high-urgency situations, selecting a migration destination requires comprehensive judgment including regulatory, contractual, and tax perspectives—not just technical latency considerations.

In summary, points to consider when migrating to EU regions include:

• Confirming GDPR's scope: Assessing the risk of EU resident users mixing in, implementing geo-blocking
• ePrivacy compliance: Managing cookie consent for web services accessible from within the EU
• EU operational structure: Initial incident response, authority notification, necessity of EU representatives (Art. 27)
• Third-country transfers: Transfer records and documentation for remote access from outside the EU (adequacy decisions, necessity of SCCs)
• VAT handling: Determining EU VAT registration obligations, considering simplification through resellers

---

Classmethod Europe GmbH (CME), based in Berlin, Germany, provides AWS environment construction/operation support and compliance with European regulations such as GDPR and ePrivacy. We cover practical necessities for businesses placing infrastructure within the EU, including EU representative services, cookie consent management (Cookiebot) implementation support, and initial incident response in EU time zones. Please feel free to contact us for consultation.