[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-faqs-cloud-region-data-residency-pdpa-en":3,"blog-post-cloud-region-data-residency-pdpa-en":28},[4,8,12,16,20,24],{"answer":5,"id":6,"question":7},"A region is the geographic location where compute and the primary database run. A zone is a subdivision within that same region for availability — an outage in one data center within a region does not take down another zone in the same region. Region choice sets which country your data sits in; zone choice is about availability within that region.","6tp1qg37dfmxusx","What is the difference between a region and a zone?",{"answer":9,"id":10,"question":11},"Yes, but it is not a config change like it would have been before real data existed. A live system needs a full data migration, a fresh compliance review, and a carefully planned cutover window so the system doesn't go down mid-move. The more data and the more integrations pointing at it, the higher that cost climbs.","2mx90t3u76ex41n","If we picked the wrong region at the start, can it be fixed later?",{"answer":13,"id":14,"question":15},"Not as permanent storage. Cloudflare's Regional Services controls which data center decrypts and processes HTTPS traffic in transit, not where the underlying data is permanently stored. Your personal data still lives in whatever region your primary database uses, even when traffic is routed through an edge location near Thailand.","jllp39ufnh3ooac","Does a CDN like Cloudflare store personal data at the edge?",{"answer":17,"id":18,"question":19},"PDPA does not state a blanket requirement to keep all data inside Thailand, but it does set conditions on sending or transferring personal data to a foreign country, and those conditions depend on the destination and the safeguards used for the transfer. That specific determination belongs with your organization's legal counsel or DPO, or with PDPC directly — not with a general article.","4cop7epzf187u39","Does PDPA require personal data on Thai individuals to stay inside Thailand?",{"answer":21,"id":22,"question":23},"Not technically. A DR region is usually chosen far enough from the primary region that the same disaster does not take out both, but if the DR region sits in a different country from the primary one, the organization needs to check the cross-border transfer implications of both regions, not just the primary one.","jkl9188pawi9n6d","Does a backup or DR region have to be in the same country as the primary region?",{"answer":25,"id":26,"question":27},"Not urgently, but it is worth recording the assumption explicitly — this system has no cross-border data — and revisiting it whenever the system's scope changes, such as gaining customers abroad or integrating with a service hosted outside the region.","ecp3ohuec3r7ytn","Does a small organization with no cross-border data need to worry about this?",{"id":29,"parentId":30,"title":31,"excerpt":32,"content":33,"image":34,"date":35,"isoDate":36,"views":37,"tag":38,"categorySlug":39,"slug":40,"to":41,"readTime":42,"isHighlight":43,"sortOrder":44,"video":45,"video_id":45,"keywords":46},"7mdh5ymgdfhqljx","as91yptnxanclu9","Where Does Your Data Actually Live? Cloud Region Choice and Data-Residency Obligations","Choosing a Google Cloud or Azure region is usually decided in minutes at project kickoff, but it fixes data location, PDPA exposure, and latency for Thai users for years afterward.","\u003Cp>When a new project starts on Google Cloud or Microsoft Azure, the team picks a region in the first setup screen, and the decision is usually over in a few minutes. At that point there is no real data in the system yet, no use case to justify to a board, and nobody asks where the data will actually sit. Three years later, the same system holds millions of customer rows, legal starts asking which country the data lives in, and \"we can just move region later\" turns out to be far less simple than it sounded at the start.\u003C\u002Fp>\u003Cp>The region picked on day one fixes where data physically lives, whether the organization has to answer Thailand's PDPA questions about cross-border data transfer, and the latency Thai end users feel every day. It is an architecture decision made once, early, and almost never revisited until something forces the question. A system that starts with users in one country can expand into several within a few years, and when that happens, the residency assumptions baked in at the start have to be reopened entirely.\u003C\u002Fp>\u003Ch2>Region, Zone, and Edge Cache — Three Layers That Get Conflated\u003C\u002Fh2>\u003Cp>\"Where is the data\" actually has three layers stacked on top of each other. The first is the primary region — where the compute instances and the primary database actually run. Google Cloud publishes a network of 43 regions and 130 zones worldwide (source: Google Cloud, \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fcloud.google.com\u002Fabout\u002Flocations\">cloud.google.com\u002Fabout\u002Flocations\u003C\u002Fa>, accessed 29 September 2026). Azure works on the same principle: customers specify the geography where a service stores and processes data, and Microsoft states it will not move customer data outside that chosen geo without authorization (source: Microsoft Azure, \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fazure.microsoft.com\u002Fen-us\u002Fexplore\u002Fglobal-infrastructure\u002Fdata-residency\u002F\">azure.microsoft.com\u002Fen-us\u002Fexplore\u002Fglobal-infrastructure\u002Fdata-residency\u003C\u002Fa>, accessed 29 September 2026).\u003C\u002Fp>\u003Cp>The second layer is the backup or DR region, a separate decision from the primary region even though the two are related — Azure notes it may copy customer data between regions within the same geo for redundancy. An organization planning failover needs to know the location of both the primary and the backup region, not just one. That decision connects to the failover and incident-response questions we \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fen\u002Fblogs\u002Fdr-plan-roles-and-decisions-during-an-outage\">covered separately\u003C\u002Fa> — but this article is about where the data sits, not what happens during an incident.\u003C\u002Fp>\u003Cp>The third layer is CDN edge caching, and this is where the confusion usually starts. Cloudflare's Regional Services controls which data center decrypts and processes HTTPS traffic in transit — it does not control where the underlying data is permanently stored (source: Cloudflare, \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fdevelopers.cloudflare.com\u002Fdata-localization\u002Fregional-services\u002F\">developers.cloudflare.com\u002Fdata-localization\u002Fregional-services\u003C\u002Fa>, accessed 29 September 2026). In other words, routing traffic through an edge location near Thailand does not move the stored personal data anywhere; it still lives in whatever region was chosen for the primary database.\u003C\u002Fp>\u003Cp>A concrete case makes this easier to see: a website with a contact form sends the submitted data to the primary database's region, while the CDN only serves the page's HTML, CSS, and images faster from whichever data center sits closest to the visitor. A team that reads \"we have a CDN presence in Asia\" as \"our customer data is in Asia too\" has answered the residency question wrong from the start.\u003C\u002Fp>\u003Ch2>What Thailand's PDPA Actually Asks About Cross-Border Transfer\u003C\u002Fh2>\u003Cp>Thailand's Personal Data Protection Act (PDPA) includes rules on sending or transferring personal data to a foreign country, and the Personal Data Protection Committee (PDPC) is the body that issues the notifications spelling out the detail — including criteria for destination countries considered to have adequate protection, and safeguard requirements for transfers where that adequacy has not been established (source: Office of the Personal Data Protection Committee, \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.pdpc.or.th\u002Fen\u002F10547\u002F\">pdpc.or.th\u002Fen\u002F10547\u003C\u002Fa>, accessed 29 September 2026).\u003C\u002Fp>\u003Cp>In practice, the data flowing outside Thailand is rarely limited to the system's main database. It also includes secondary services engineering teams often configure separately — a transactional email provider, a behavioral analytics tool, a support-ticketing platform run by a vendor abroad. These services can sit in a different region from the primary database entirely, and they are the piece most often missed when an organization tries to map what data goes where.\u003C\u002Fp>\u003Cp>What this article can responsibly say is that this requirement exists and connects directly to region choice: if the primary or backup region sits outside Thailand, personal data flowing there for storage or processing may fall under the cross-border transfer rules. What this article cannot responsibly say is whether any specific organization's system is in scope, because that depends on the data category, the purpose of processing, and detail that changes as PDPC issues further notifications. A question that specific belongs with the organization's own legal counsel or Data Protection Officer, or with PDPC directly — not with a system-builder's blog post.\u003C\u002Fp>\u003Ch2>How Much Location Control Google Cloud and Azure Actually Give You\u003C\u002Fh2>\u003Cp>As of when this article was written, the two platforms are in different positions. Google Cloud has opened its Bangkok region (asia-southeast3) and states that the region supports keeping specified data within Thailand's borders (source: \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fcloud.google.com\u002Fblog\u002Fproducts\u002Finfrastructure\u002Fgoogle-cloud-launches-new-region-in-bangkok-thailand\">Google Cloud Blog, Bangkok region launch announcement\u003C\u002Fa>, accessed 29 September 2026). Azure does not yet operate a generally available region inside Thailand. Whether data can stay in-country therefore depends on the provider and the services chosen, not on a limit every provider shares, and because region lists change, check each provider's region picker or locations page on the day the decision is actually made.\u003C\u002Fp>\u003Cp>What is actually configurable is how tightly that location gets enforced. Google Cloud's organization policy constraints can restrict where resources are allowed to be created at all, and a product like Assured Workloads exists specifically to enforce stricter compliance and residency controls than the default setup. Azure lets customers specify the region most services use to store and process data, and states it will not move that data outside the chosen geo without authorization. Setting this up is a design-time decision — retrofitting it after resources already exist in a different region is a much bigger job than turning on a setting, and it changes how the architecture team designs IAM and policy from the start, not just which region name gets typed into a form.\u003C\u002Fp>\u003Ch2>What It Costs to Fix After Go-Live\u003C\u002Fh2>\u003Cp>Moving the region of a system with no real data yet is a configuration change. Moving the region of a system already in production is a separate project with costs layered on top of each other. The first is the tooling and time needed to move real data without losing any of it in transit. Next comes the cost of running both the old and new region in parallel during the cutover window, which means paying for two sets of infrastructure during that period. On top of that, every vendor contract and data processing agreement tied to the new setup needs to be reviewed again. Last is the time the team spends re-verifying that every feature still works correctly after the move, because every integration pointing at the old endpoint has to be checked from scratch.\u003C\u002Fp>\u003Cp>This is the argument for discussing region choice in the same meeting as budget and timeline, not leaving it as a default setting the engineering team clicks through because nobody asked.\u003C\u002Fp>\u003Ch2>The Honest Limit: Not Every System Needs to Treat This as Urgent\u003C\u002Fh2>\u003Cp>A small internal system with no external personal data, no cross-border integration, and no near-term plan to expand into another market does not need to treat region and PDPA as an urgent architecture concern from day one. Over-engineering location constraints has its own cost too — time spent on organization policy setup, and a narrower region choice that can hurt latency or price for no real benefit. The right move in that case is to record the assumption explicitly — this system has no cross-border data — and revisit it whenever the system's scope changes, rather than dropping the question entirely.\u003C\u002Fp>\u003Ch2>The Objection We Hear Most Often\u003C\u002Fh2>\u003Cp>The most common pushback is: \"our cloud provider already holds every compliance certificate we could need, so why think about region at all?\" A certification like ISO 27001 or SOC 2 confirms the provider's own infrastructure is managed to a standard — it does not decide, on the organization's behalf, whether sending data to the chosen region counts as a cross-border transfer under PDPA.\u003C\u002Fp>\u003Cp>A second objection is \"let's wait until our provider has a Thailand region.\" As of when this article was written, Google Cloud already has a Bangkok region, while Azure does not yet operate a generally available region in Thailand, and this article has no confirmed information about when that will change. The more workable option for an organization that needs to build something now is designing the data layer separately from the compute layer from the start, so that a future region move, if it ever becomes necessary, is a smaller job than untangling a system built with everything wired together.\u003C\u002Fp>\u003Cdiv data-type=\"horizontalRule\">\u003Chr>\u003C\u002Fdiv>\u003Ch2>Where to Start\u003C\u002Fh2>\u003Cp>Start by mapping what data currently flows outside Thailand — the primary region, the backup region, and secondary services like logging or analytics that are sometimes quietly configured in a different region from everything else. Ask every service the system uses what data goes to it and which country processes it; the answer is usually sitting in that service's own documentation page. Next, separate which of that data counts as personal data under PDPA and which does not. Then take that list to the organization's own legal function or DPO and ask whether it triggers the cross-border transfer rules. Finally, write the region decision down as an architecture document, with the reasoning behind it, so the next team does not have to guess why the system lives where it does. This kind of decision is part of the same architecture work \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fen\">our team\u003C\u002Fa> does with organizations.\u003C\u002Fp>\u003Cp>One takeaway, if nothing else: map where your data actually flows before there is too much of it to move easily. If your organization is designing a new system or reviewing an existing architecture and wants a second opinion on this, we are glad to talk.\u003C\u002Fp>\u003Cp>To discuss your project in detail, contact us at 088-983-9386 or email contact@superdev.tech. Our office is in Bang Kapi, Bangkok. If you are still drafting scope, we are happy to talk through the problem first, before any documentation is finalized — and if that conversation shows the timing is not right for a new system, we will say so directly, because starting a project at the wrong moment costs more than waiting one more quarter.\u003C\u002Fp>","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fpbc_2128795511\u002F7mdh5ymgdfhqljx\u002Fcover_cover_rv4h1gwp33.webp","September 29, 2026","2026-09-29 04:13:34.829Z",124,"Enterprise","enterprise","cloud-region-data-residency-pdpa","\u002Fblogs\u002Fcloud-region-data-residency-pdpa",9,false,0,"",[47,48,49,50,51,52],"data residency","PDPA","cloud region","Google Cloud","Microsoft Azure","Cloudflare"]