Data Residency for Cloud Workloads: Where the Data Actually Lives

What this page claims, and what it leaves out

A residency page that cites rules without a sourced list is a liability, so this one stays with architecture and evidence. It names the kinds of regulator a reviewer may face, but it does not restate their circulars, gazette IDs or the wording of a policy that has not been checked against a primary source this week. Which rules apply to you is a question for your counsel. Those rules are not summarized here.

The company holds ISO 9001:2015 (certificate 25/182622) and ISO/IEC 27001:2022 (certificate 25/18024), both issued by A Cube TIC Limited and valid to 7 October 2028 and 6 October 2028. This page does not claim a SOC 2 or PCI DSS certificate. TiCON offers readiness support for both and holds neither. Encryption and access controls are not presented as those certificates. Staff certification counts are not listed. No latency figures are published from Dhaka to Mumbai or Singapore, since those need a dated measurement.

What is sourced: AWS has no region in Bangladesh. The regions TiCON uses for Bangladesh-based production are Asia Pacific (Mumbai) and Asia Pacific (Singapore). Azure and Google Cloud also have no Bangladesh region. TiCON is an AWS Advanced Tier Partner on the AWS Partner Solutions Finder and resells AWS usage on a local-currency invoice. A local invoice is a billing fact. It is not a statement about where the data is stored.

• cloud for your industry
• pay AWS from Bangladesh
• AWS partners and resellers

Data residency vs data sovereignty

People use these terms interchangeably. Auditors do not, so write both down or the design will be argued about after cutover.

Data residency is the physical and logical place where data is stored and processed: a named AWS region, a named local facility, an edge cache, a laptop. If an object lives in ap-south-1, its residency for that copy is India, whatever currency the invoice uses. A content delivery network can serve cacheable bytes closer to users, but it does not move the origin. Treating an edge hit as the system of record is how reviews fail.

Data sovereignty is which legal process can reach the data, the operator and the encryption keys. A copy in Mumbai can still be reached through the legal processes that apply to the cloud provider and to the customer and contracting entity. Encryption and tighter access shrink the set of people who can read a copy. They do not remove the legal overlay. The architecture has to say which copy sits in which region, which keys protect it, and who can compel access to them.

For a regulated estate, both answers belong in the audit pack before the first replica. "We use AWS" is neither answer. "We pay in local currency" is neither answer. "Mumbai, encrypted, customer-managed keys, these access roles, and a local copy for category X" is a start.

Regional availability: no Bangladesh region today

AWS, Microsoft Azure and Google Cloud do not run a region in Bangladesh. Traffic from Dhaka is served from India or Singapore. That is geography, not a latency contest.

AWS's public region list, checked on 21 September 2026, has no Bangladesh region. The regions TiCON uses for Bangladesh-based production are ap-south-1 (Mumbai) and ap-southeast-1 (Singapore). Other AWS regions exist, and this page does not imply that any of them is nearer.

Azure's published India geographies are Central India (Pune), South India (Chennai) and West India (Mumbai), plus Southeast Asia (Singapore). Google Cloud's nearest published compute regions are typically Mumbai, Delhi and Singapore. Announced regions that are not live are not treated as available. None of these lists includes a Bangladesh region.

If a reviewer asks, "Can we run this on AWS and keep the data in Bangladesh?", the first honest sentence is no, not as a region. The second is that some categories can run in Mumbai or Singapore under a written control set, and some categories need an in-country path. Deciding which is which is a classification exercise, not a slogan.

Region names come from the AWS global infrastructure page, accessed 21 September 2026. Azure geographies and Google Cloud regions were checked the same day. No ping times are published.

A local invoice is not data residency

Finance and architecture are separate workstreams. Mixing them is how a board ends up believing "we pay locally, so the data is local."

On a TiCON AWS engagement, usage arrives on a monthly invoice in local currency. That document serves the customer's accounts team and whoever files the local bill. It does not move S3 objects from Mumbai to Dhaka. The same estate can be fully in ap-south-1 and fully billed in BDT. Both facts can be true at once, and only one of them is residency.

Azure and Google Cloud usage, where those clouds are part of the estate, stays on the paperwork those providers issue, unless a written contract says otherwise. Architecture work quoted in a local currency does not create a reseller product for those clouds, and it does not create a Bangladesh region for them.

If the requirement is "the system of record must not leave the country," start with classification and a local or hybrid path. If the requirement is "we need a local invoice for AWS," start with the reseller conversation. Do both when both are required, and do not let one stand in for the other.

• pay AWS from Bangladesh
• get an AWS account without buying one

Residency options TiCON designs for

There is rarely one box to tick. The design combines paths by data category, then writes the combination down.

In-region cloud. Run the workload in a named AWS region, usually Mumbai or Singapore, with encryption in transit and at rest, least-privilege access, logging, and a written statement of where each data class sits. This is the default for estates that may leave the country. It is not "data in Bangladesh." (Named region, encryption, access controls, logging, audit pack before cutover.)

Local data center and custom CDN. Keep the origin or a copy in-country when the category must stay. TiCON builds a custom CDN inside local data centers for content sovereignty, which suits media delivery where content should not depend on an overseas origin alone. This page publishes no data-center product list and no delivery-time claim. (In-country origin or copy, custom CDN for content that must stay, integrated with the cloud estate.)

Controlled hybrid. Split by sensitivity. Identity, logs and the product run in-region, while the regulated store or content library sits on the local path. The costly part is the map, not the diagram. Without the map, a hybrid is just two places an auditor has to chase. (Classification first, a written boundary, and a record of who can reach each copy.)

• government and broadcast
• OTT streaming at national scale
• banking and fintech

What goes in the audit pack

Controls that are not written down do not exist for an auditor. The pack is the product of a residency engagement, not a slide.

TiCON writes the architecture and operates the estate when that is in scope. Counsel writes the legal opinion. Mixing those roles on a marketing page is how "compliant" becomes a word with no owner. This site will not print a rule number that did not come from a primary source.

• ✓Data classification: what may leave, what must stay, and whether payment-card data is in scope.
• ✓Location map: region or local path for each class, including replicas, backups and logs. A backup in another region is still residency.
• ✓Identity and keys: who can assume which role, where keys live, and whether the customer holds them.
• ✓Encryption and logging: in transit, at rest, and an audit trail the compliance team can export.
• ✓Commercial path: AWS usage invoiced in local currency where that is the engagement, and Azure or Google Cloud on their own paperwork. The invoice currency is listed so nobody mistakes it for a location.
• ✓Open items: rule citations and reference numbers that the customer's counsel will attach. This page does not fill in those blanks.

• managed cloud and cost management
• cloud migration

Sector notes, without statute citations

The industry pages describe the architecture pattern for each sector. This section covers only the residency stance. The case studies name the clients: United Commercial Bank (UCB), Rabbithole, Bangladesh Television (BTV), Banglalink Digital Communications and OnnoRokom.

Financial services. Banks and fintechs usually land on a named region with a written control set, add a local path for categories that must stay, and keep an audit pack for each. Payment-card workloads need a documented boundary. This page does not claim a PCI DSS certificate.

Public sector and media. Public bodies need a sovereignty split in writing. The published write-up is the government-broadcaster case study. A local content delivery path is in scope when content must stay in-country.

Telecom. Data platforms still need a named region and an access model. The telecom data-platform case study, for Banglalink Digital Communications, shows that pattern.

Personal data. Classify it first. Counsel names the rules that apply. Encryption and a location map have to exist whether or not the citation is attached yet.

This page is not legal advice. Confirm the requirements that apply to you, as applicable in your jurisdiction, with your counsel and compliance team.

• cloud for your industry
• telecom data platform and BI

How to brief a residency design

Bring the data categories and the regulator you answer to. Do not expect a rule-by-rule lecture from a page that has no sourced list of rules.

Brief a data-residency design with TiCON: about 30 minutes

A useful briefing covers the data classes, the regulator you report to, and a named path for each class. It does not start with a request for rule numbers this page does not publish.