- Thailand
- Vietnam
For local subsidiaries in Thailand using Amazon Web Services (AWS), the scope of operations can expand to include post-implementation monitoring, fault diagnosis, and reporting to the Japanese headquarters. If responsibilities and reporting routes remain unclear, response procedures and decision-making criteria will depend on specific individuals, leading to inconsistencies in initial responses to faults and information sharing with headquarters.
This article outlines common challenges faced by local subsidiaries in Thailand, tasks that can be outsourced, and key points to consider when selecting an AWS operations and maintenance company, for companies considering AWS operations and maintenance in Thailand.
The launch of the AWS Asia Pacific (Thailand) region expands the options for using AWS as a foundation for systems serving users within Thailand and for business systems at local subsidiaries. The ability to choose an environment closer to the domestic Thai environment, taking into account latency, data placement, and business continuity, represents a significant change for local subsidiaries.
However, simply selecting a region and performing the initial setup does not mean that the operational system after setup is in place. To continue using the AWS environment, you need to decide in advance who will be responsible for monitoring settings, initial response in the event of a failure, backup verification, log management, permission review, and usage fee monitoring.
In particular, for local subsidiaries in Thailand, a key challenge is how to divide the responsibilities between initial response on the ground and management from the Japanese headquarters. By clarifying the scope of operation, communication flow, and reporting system from the design phase before construction, it becomes possible to continuously manage the AWS environment after it is built.
The challenges in AWS operations and maintenance extend beyond technical configurations to include areas such as responsibilities, response times, decision-making authority, and reporting routes. If these areas remain ambiguous, responses to incidents and information sharing with headquarters will depend on the individual judgment of each person in charge.
At local offices, IT personnel are often not solely dedicated to AWS, but also handle internal network management, PC administration, business systems, and local vendor support. If they are then tasked with checking AWS alerts and providing initial support during outages, their responsibilities expand beyond their regular duties to include root cause investigation and contacting relevant parties.
The burden lies in the decision-making process after receiving an alert. If only a limited number of people are responsible for determining the scope of impact, conducting initial troubleshooting, deciding whether recovery work is feasible, and contacting headquarters or external partners, it can lead to delays in response and reliance on individual expertise.
The problem isn't a lack of skills among local staff, but rather the broad scope of their responsibilities. By pre-determining which tasks—monitoring, initial response, root cause investigation, recovery decision-making, and reporting—are to be handled locally, the workload during a failure can be reduced.
Maintaining a continuous AWS environment requires daily monitoring and recording of changes. Even if monitoring settings and backups are initially in place, if verification methods and recovery procedures are not shared, the quality of response during a failure will depend on the experience of the person in charge.
For example, even if backups are taken, if recovery procedures are not reviewed, it will take a long time to recover in the event of an actual failure. Even if logs are saved, if the storage location and review procedures are not shared, investigating the cause will depend on the experience of the person in charge.
To prevent reliance on individual expertise, simply creating procedure manuals is not enough. Regularly review backup procedures, log verification methods, change histories, and recovery procedures, and ensure they are shared with headquarters and external partners.
When using AWS at overseas locations, a regular sharing mechanism is necessary for the Japanese headquarters to understand account configurations and resource usage. Without knowing which systems are running on which AWS accounts, who has what permissions, and which services are causing increased costs, company-wide management will be hindered.
When expanding the environment based on local decisions, the standards for access control and cost management may differ from those at headquarters. If unnecessary resources remain, excessive access is granted, logs are not collected sufficiently, and billing details are not checked, the burden of organizing the overall picture later becomes significant.
The information that headquarters should manage is not limited to configuration diagrams and usage fees. Having access to access lists of permissions, change histories, incident response histories, and monthly reports allows for a better understanding of local operations and enables decisions regarding improvements and additional investments.
When outsourcing AWS operations and maintenance, don't judge solely by the task name; confirm the scope of work and the division of responsibilities. The tasks remaining for the local staff and the Japanese headquarters will differ depending on whether the response is just notification or includes initial troubleshooting and recovery support.
Services that can be requested | Main contents | Points to check |
Monitoring and alert response | Check server, network, resource usage, and various alerts. | Monitoring targets, notification conditions, response time, scope of initial response |
Troubleshooting | Alert confirmation, initial troubleshooting, cause investigation, recovery support, escalation | To what extent should the initial response be handled, and at what point should the decision be left to headquarters? |
Backup and recovery support | Backup settings, verification of backup status, and development of recovery procedures. | Recovery targets, retention period, and whether recovery tests are performed. |
Log Management | Checking the acquisition and storage status of operation logs, access logs, and system logs. | Log storage location, storage period, and scope of verification during investigations. |
Security and access control | IAM, permission settings, configuration errors, checking for unnecessary permissions | Frequency of permission inventory, approval flow for changes |
Cost control | Checking usage fees, identifying unnecessary resources, and suggesting improvements. | Contents of the monthly report, scope of reduction proposals |
Operational Report | Reports on operational status, failure history, change history, costs, and improvements. | Required reporting content for local subsidiaries and Japanese headquarters |
When outsourcing tasks, it's important to differentiate the decisions that remain within your own company. Approving recovery work that involves system downtime, assessing business impact, final approval for granting permissions, and deciding on the implementation of cost reduction measures are not solely the responsibility of the support company. By defining who—the local staff, the Japanese headquarters, or the support company—will make these decisions, you can minimize misunderstandings during system failures or changes.
When choosing an AWS operations and maintenance company, you should consider not only the price and response time, but also on-site support, reporting to headquarters, scope of work, division of responsibility, and improvement suggestions. The most suitable support company will vary depending on whether the operations are handled solely by the Thai office or if they also include management standards from the Japanese headquarters.
For our Thai subsidiary, it's essential to have a system in place to quickly contact local personnel in the event of a system failure or alert. Having defined support languages, contact methods, operating hours, and the scope of initial response will help minimize disruption during such incidents.
If operations are handled solely on-site, there is a risk that the Japanese headquarters will not be able to grasp the status of the AWS environment. Having a system in place to share monthly reports, incident reports, change histories, and cost information with headquarters allows for seamless operation without separating on-site support from headquarters management.
Local vendors have an advantage in understanding local conditions and coordinating with local personnel. However, if the requirements include reporting formats, security standards, access control, and audit compliance as stipulated by the Japanese headquarters, it's crucial to determine whether their support system meets the headquarters' management requirements.
The scope of AWS operations and maintenance services varies depending on the support company and contract. It may range from simply providing monitoring and notifications to including initial troubleshooting, root cause investigation, recovery support, configuration changes, and proposals for preventing recurrence.
What we want to confirm is not whether or not there is a service menu, but the response flow in the event of an outage. We need to clarify who will perform the initial check after an alert is detected, to what extent the scope of impact will be isolated, and who will be responsible for the temporary response. If we also decide on the approval of recovery work, reporting to headquarters and local personnel, and sharing of measures to prevent recurrence, then decision-making during an outage will not be biased towards an individual.
The same applies to security and cost management. We pre-determine what is included in standard support and what requires additional support, such as checking IAM permissions, verifying log acquisition status, identifying unnecessary resources, and creating usage cost reports.
We will also examine the differences between monitoring time and incident response time. Even with 24-hour monitoring, root cause investigation, recovery work, configuration changes, and emergency contact may be subject to support hours and contract scope. By organizing response times, response conditions, emergency contacts, and the scope of recovery work separately from monitoring conditions, discrepancies in understanding during incidents can be minimized.
AWS environments require review depending on usage and business conditions. Even configurations that were appropriate during initial setup may require revisions to monitoring items, backup policies, permission designs, and cost management if the number of users, data volume, connection locations, and security requirements change.
When choosing an operations and maintenance company, we look for one that can handle not only daily monitoring and incident response, but also continuous improvement suggestions. Knowledge of various AWS services, experience in multi-account management, security design, cost optimization, and backup design are all factors in determining their long-term operational capabilities.
Furthermore, the decision-making process will not only focus on improving the Thai branch itself, but also on ensuring alignment with the AWS management policies and security standards of the Japanese headquarters. Whether local practices and headquarters management standards can be handled within the same support system is a major factor in the decision-making process for AWS operations and maintenance at overseas branches.
IIJ Managed Cloud for AWS is a managed service that supports everything from designing, implementing, building, operating, monitoring, and maintaining AWS. It supports companies expanding into Southeast Asia, including Thailand, in operating their AWS environments, optimizing costs, and promoting digital transformation (DX).
Our support covers account management, access control, cost optimization, and operational automation. Specifically, you can utilize access control with AWS Organizations and Guardrails, Trusted Advisor and RI/SP purchase suggestions, cost management with Budgets notifications, and automated backup, shutdown, and startup with Cloud Automator. We also offer help desk support in local languages and Japanese, and provide localized support for Thailand, Vietnam, and Indonesia.
Through the collaboration between IIJ and Serverworks, we have a track record of supporting AWS implementations for over 1,300 companies. As an AWS Premier Tier Services Partner, Serverworks possesses expertise and can provide consultation on not only AWS but also networking, security, and the entire IT infrastructure, including existing on-premises environments.
For local subsidiaries using AWS in Thailand, it is essential to define the scope of operations after implementation in advance. If the initial response after monitoring, decision-making in the event of a failure, feasibility of recovery work, and reporting routes to headquarters remain unclear, the quality of response will depend on the experience of the person in charge.
When outsourcing operations and maintenance, clearly define the roles of the local staff, the Japanese head office, and the support company. When reviewing AWS operations and maintenance at the Thailand office, it's a good idea to start by separating and organizing the tasks to be handled locally, the information to be confirmed by the head office, and the scope of work to be entrusted to external partners.