- restoration
The opening of the AWS Asia Pacific (Thailand) region allows for the deployment of systems and data within the AWS region of Thailand. However, even for systems used at a Thai location, the Thai region may not always be the optimal choice.
The available services, pricing, communication latency for users, and data storage locations vary by region. For systems that connect with the Japanese headquarters and other locations in Southeast Asia, inter-location communication and compatibility with existing environments also influence the selection process.
This article outlines the basic information about the AWS Thailand region and its differences from the Singapore and Tokyo regions. It also explains when the Thailand region is suitable and how to choose the right AWS region based on your system's purpose.
The AWS Asia Pacific (Thailand) region is an AWS region that became generally available in January 2025. Its region code is "ap-southeast-7," and it comprises three Availability Zones within Thailand.
An Availability Zone is a group of data centers with independent power supplies and networks. By distributing systems across multiple Availability Zones, you can design a configuration that is prepared for failures at a single location.
When using AWS in Thailand, in addition to the Thailand region, the Singapore region and Tokyo region are also options.
The main differences between the regions are as follows:
Comparison item | Thailand Region | Singapore Region | Tokyo Region |
Region code | ap-southeast-7 | ap-southeast-1 | ap-northeast-1 |
Number of Availability Zones | 3 | 3 | 4 |
Trends in communication delays | It tends to be more advantageous when used from within Thailand. | For use from various Southeast Asian countries, measurements will be required at each location. | It tends to be more advantageous for users within Japan. |
Available services | Supports major services. Availability needs to be checked for each service and function. | Availability needs to be checked for each service and feature. | Availability needs to be checked for each service and feature. |
Price | It varies depending on the service and configuration. | It varies depending on the service and configuration. | It varies depending on the service and configuration. |
Regional service data location | Thailand | Singapore | Japan |
The Singapore and Tokyo regions have been operational for longer than the Thailand region, and the services and features available may differ. However, service availability is updated regularly, so please check the official AWS information for each service you plan to use.
Communication latency is not determined solely by the distance between the user and the AWS region. The network quality at the local site, the communication path, and the application configuration also play a role.
If the primary users are located in Thailand, deploying the system to the Thailand region may result in shorter response times compared to configurations that require communication to Singapore or Tokyo. For business systems that frequently display screens and input data, even slight delays can affect usability.
On the other hand, if the same system is to be used from multiple countries in Southeast Asia, the Singapore region is also a viable option. If there is a lot of access from the Japanese headquarters or communication with the Japanese system, the Tokyo region should also be included in the comparison.
Geographical location alone is not sufficient to determine the appropriate region. Before implementation, connection tests are conducted from each site to the candidate region to measure response time and communication stability.
The availability of AWS services varies by region. In the Thailand region, you can use major services such as Amazon EC2, Amazon S3, Amazon RDS, and AWS Lambda.
However, even if the service itself is supported, the available features, instance types, database engines, and generative AI models may not be the same as those in the Singapore and Tokyo regions.
When choosing a region, check not only the service name but also the following items.
Features I plan to use
Amazon EC2 instance types
Amazon RDS database engines and versions
Available Availability Zones
Services used for backup and disaster recovery.
Services that may be added in the future
If the necessary functions are not available in the Thailand region, you can consider deploying the system to Singapore or Tokyo. While it's also an option to use only the required functions in a different region, this will complicate inter-region communication and data management.
Since the availability status of AWS services is constantly being updated, we check the latest availability information on official AWS sources during the design phase.
AWS pricing varies depending on the services used, region, specifications, uptime, and data transfer volume. The Thailand region is not always the cheapest.
When comparing prices across regions, at least the following conditions should be met:
Amazon EC2 instance types and uptime
Amazon RDS database engines, instances, and storage capacity
Amazon S3 storage capacity and number of requests
Amount of data sent to the internet
Data traffic between the site and AWS
Amount of data to transfer between regions
Backup storage capacity and location
For example, simply comparing the hourly rates for Amazon EC2 doesn't give you a clear picture of the overall system cost. If there's a lot of communication between the Japanese headquarters and other overseas locations, data transfer fees will impact the overall cost. In configurations where backups are stored in multiple regions, storage costs and inter-region transfers should also be included in the estimate.
When using the AWS pricing tool, create the same configuration in each region and ensure that monthly uptime and data transfer volume are the same. Reflecting future increases in the number of users and data volume will make it easier to compare costs after deployment.
AWS allows users to select the region where their data is stored. If you use the Thailand region and do not configure replication or transfer to another region, the customer data in question will, in principle, be stored within the Thailand region.
However, simply deploying applications and databases to the Thailand region does not guarantee that all system data will reside within Thailand. You should also check the following storage and transfer destinations.
Backup and disaster recovery destination
Location where monitoring logs and operation logs are stored.
Partners for integration with external SaaS and business systems
Data to be sent to the Japanese head office and other overseas branches.
Data used for fault analysis and support.
Placing data within Thailand and complying with Thailand's Personal Data Protection Act (PDPA) are not the same thing. When copying or transmitting personal data from Thailand to Singapore or Japan, it is necessary to clarify the requirements for international transfers.
In order to comply with the PDPA, you should understand not only the location of the region, but also the purpose of data use, access rights, retention period, outsourcing partners, and whether the data has been transferred overseas. For overall PDPA compliance, it is appropriate to consult with legal personnel or experts.
The AWS Thailand region is suitable when the main users, data, and system processing are concentrated within Thailand.
On the other hand, for systems with a large volume of communication with the Japanese headquarters, or systems used in multiple Southeast Asian countries, the Singapore or Tokyo region may be more suitable.
The main examples of decisions made by each system are as follows:
System | A strong candidate | Main conditions under which the judgment changes |
Web services for use within Thailand | Thailand | Availability of necessary services, percentage of international users |
Business system of the Thai subsidiary | Thailand | Frequency and volume of communication with the Japanese head office. |
Core system shared with the Japanese head office | Tokyo or existing region | Number of users, processing volume, and communication delay on the Thai side. |
A system used in multiple Southeast Asian countries. | Comparison including Singapore | Communication status from each location, data storage requirements |
In the actual selection process, communication tests and cost estimates are conducted in candidate regions to verify that the necessary services are provided.
For web services whose primary users are located within Thailand, the Thailand region is a strong candidate. By placing applications and databases closer to users, it may be possible to reduce the time required for screen display and data transmission.
When considering your configuration, you should check not only the web server and database, but also the services you will use for authentication, payment, email delivery, analytics, etc. If the necessary functions are not available in the Thailand region, choosing the Singapore or Tokyo region may simplify the configuration.
For web services that receive a large amount of traffic from outside Thailand, one option is to combine them with a CDN such as Amazon CloudFront. Analyze the distribution of traffic sources and design separate regions for application deployment and content delivery paths.
For sales management, inventory management, application processing, and internal portals used by employees of our Thai subsidiary, the Thailand region is a strong candidate.
If the system is completed entirely within Thailand, users, applications, and data can be consolidated within the country. Communication routes can be limited, and the data storage location becomes clear.
On the other hand, if the authentication infrastructure and master data are managed at the Japanese headquarters, check the frequency of integration with the headquarters system. If the system requires a query to the Japanese side every time a screen operation is performed, even if the application is located in the Thailand region, you may not get the expected response time.
Another approach is to separate the configuration by processing unit, for example, by placing locally completed processes in the Thailand region and only linking data that needs to be shared with headquarters.
When the Japanese head office and the Thai subsidiary use a common core system, the relationship with the existing environment will be the main factor in the selection process.
If there are many users and connected systems on the Japanese side, and the environment is already running stably in the Tokyo region, then continuing with the existing environment is the most practical option. Changing to the Thailand region would require data migration, changes to connection destinations, and application functionality testing.
If the number of users and processing volume on the Thai side are high and communication delays are impacting business operations, we will also consider deploying to the Thailand region. However, migrating the entire core system is not the only option. We can also consider a configuration where only certain functions and data used in Thailand are isolated and linked to the head office system.
For core systems, operational conditions such as fault response, access control, backup, and audit logs also influence the selection process, in addition to response time.
In systems used across multiple countries, such as Thailand, Vietnam, Singapore, and Indonesia, communication conditions from each location are compared.
The Singapore region is one option, but it may not be the best fit for all locations. We will conduct communication tests from major locations in each country to Thailand, Singapore, Tokyo, and other locations to confirm response time and stability.
When developing systems used in multiple countries, it's crucial to pay attention to each country's data protection regulations. One possible approach is to consolidate common functions into a single region and place only country-specific data in local regions.
However, a multi-region configuration complicates data synchronization, fault tolerance, monitoring, and access rights management. The selection should be made after evaluating the balance between the advantages of communication performance and data placement, and the burden of construction and operation.
If you are already operating in the Singapore or Tokyo region, you do not need to migrate simply because the Thailand region is opening.
When considering a migration, clearly define the current challenges and the expected benefits, and compare them with the necessary costs and work.
The first thing we need to check is the issues currently occurring in the system.
The main items under consideration are as follows:
Communication delays from within Thailand
Data storage location
Membership Fee
Support for necessary AWS services
Communication with the Japanese headquarters and other overseas offices.
Incident response and operational system
If response times from within Thailand are a problem, migrating to the Thailand region may improve performance. However, if the cause lies in the network or application processing at the branch office, changing regions may not provide sufficient improvement.
First, measure the current communication path and processing time to identify where delays are occurring. Once the extent to which improvements can be made by changing regions is clear, it becomes easier to evaluate the benefits of the migration.
Region migration involves various tasks in addition to data transfer.
Rebuilding the AWS environment
Changing application and connection settings
data migration
Operational testing and performance testing
Switching to production mode
Changes to monitoring and operating procedures
Dual operation during the transition period
On the other hand, the expected benefits of the migration include reduced communication latency, compliance with data placement requirements, and optimization of pricing.
When making comparisons, include not only the monthly AWS fees, but also the costs associated with migration, downtime, and internal man-hours required for operational changes. The criteria for evaluation should be to organize which issues will be improved and to what extent after the migration, in terms of numerical values and changes in business operations.
If no major issues are arising in the current environment, it may be more rational to continue using the existing region.
Using the Thailand region is not limited to a complete migration of existing systems.
For example, core systems shared with the Japanese headquarters can be left in Tokyo or Singapore, while only new systems for the Thai subsidiary are built in the Thailand region. Another approach is to isolate functions with communication latency or data placement issues and migrate them in stages.
Starting with partial use allows you to assess the performance and operational burden of the Thailand region before expanding your usage. Compared to a full migration, it also helps to minimize the impact during the switchover.
However, using multiple regions simultaneously complicates inter-system communication, data integrity, monitoring, and troubleshooting. Since data transfer fees between regions are also incurred, it's necessary to estimate these costs when determining the scope of the migration.
By clearly separating the parts of the existing environment that will be maintained from the parts that will be migrated to the Thailand region, it becomes easier to balance the benefits of the migration with the operational burden.
Even when using AWS in Thailand, the Thailand region isn't always the best option. We'll compare the Thailand, Singapore, and Tokyo regions by considering the location of the main users, the AWS services they need, connectivity with existing systems, and data storage requirements.
If systems are already running stably in the Singapore or Tokyo regions, it is essential to compare the benefits and workload of migration. Instead of limiting yourself to a full migration, options include creating a new system for your Thai subsidiary or utilizing the Thailand region for specific functions.
Building an AWS environment in Thailand requires not only designing the AWS side, but also coordinating connections from the Thai office, providing local support, and dividing operational responsibilities with the Japanese headquarters.
Serverworks and the IIJ Group provide AWS implementation and operation support to Japanese and local companies in Thailand. We offer comprehensive support for all aspects of AWS utilization in Thailand, from AWS environment construction and operational support to cost management and operational automation.
If you are unsure whether to use the Thailand region or continue using the existing Singapore/Tokyo regions, you should review your current system configuration and usage, and then compare the candidate configurations.