AWS Thai Blog

สิ่งที่ควรต้องคำนึงถึงสำหรับการย้าย Workloads ข้าม AWS Regions

บทความนี้ระบุสิ่งที่ควรต้องคำนึงถึงอย่างครอบคลุมสำหรับการย้าย Workloads ข้าม AWS Regions ทั้งในด้านธุรกิจและด้านเทคนิค ซึ่งประกอบด้วยการสร้างหลักการทางธุรกิจ การประเมินความเข้ากันได้ของ Workloads การวางรากฐานโครงสร้างพื้นฐาน และการเลือกกลยุทธ์การย้ายที่เหมาะสม ประเด็นเหล่านี้จะช่วยให้องค์กรสามารถวางแผนและดำเนินการย้ายได้อย่างราบรื่น ลดผลกระทบจากการย้าย และรักษาความต่อเนื่องของ Workloads ได้อย่างมีประสิทธิภาพ

บทความนี้แปลมาจาก Considerations for migrating workloads between AWS Regions โดยคุณ Vineedh George, Bryn Price, Harpreet Virk, และ Mike Kuznetsov

Amazon Web Services (AWS) มอบโครงสร้างพื้นฐานคลาวด์ที่มีความน่าเชื่อถือสูง สามารถขยายได้ และมีต้นทุนต่ำในหลาย Regions ทั่วโลก AWS ได้ออกแบบ Regions เหล่านี้ให้แยกออกจากกันโดยสิ้นเชิง การออกแบบเช่นนี้ทำให้แอปพลิเคชันสามารถบรรลุ high level of fault tolerance and stability นอกจากนี้ Regions ยังถูกจัดกลุ่มเป็น Partitions ต่างๆ เช่น aws, aws-gov, aws-cn และ aws-iso โดย Partitions เหล่านี้มีการแยกออกจากกันมากกว่าระหว่าง Regions ทั้งในแง่ของเครือข่ายและความปลอดภัย

เมื่อ AWS เปิดให้บริการใน Regions ใหม่ ลูกค้าอาจต้องการย้าย workloads จาก Regions เดิมที่ใช้งานอยู่ เพื่อปรับปรุงประสิทธิภาพด้าน latency หรือเพื่อให้เป็นไปตามข้อกำหนดด้านการกำกับดูแลใหม่ๆ อีกสถานการณ์หนึ่งที่พบบ่อยคือ Independent Software Vendors (ISV) ที่ต้องการขยายฐานลูกค้าโดยการนำเสนอผลิตภัณฑ์ใน Regions ใหม่ การลงมือย้าย workloads ดังกล่าวจำเป็นต้องผ่าน migration journey เช่นมี ขั้นตอนการประเมิน source environment , การจัดสรรทรัพยากรเพื่อวางรากฐาน และสุดท้ายคือ ขั้นตอนการย้าย workloads เหล่านั้น

บทความนี้ครอบคลุมประเด็นสำคัญที่ควรพิจารณาเมื่อต้องย้าย workloads จากหนึ่ง AWS Region ไปยังอีก Region หนึ่งภายใน Partitions เดียวกันเท่านั้น แต่การย้ายข้าม Partitions นั้นต้องมีการพิจารณาเพิ่มเติม ซึ่งไม่ได้กล่าวถึงในบทความนี้

การสร้าง Business Case และพิจารณาผลกระทบด้านต้นทุน

เช่นเดียวกับ Migrate workloads ทุกครั้ง ขั้นตอนแรกที่แนะนำคือการเริ่มต้นด้วย assess phase และสร้าง Business Case เริ่มจากระบุเหตุผลในการย้าย workloads และประเมินผลประโยชน์ทั้งในเชิงปริมาณและคุณภาพ เพื่อให้ผู้มีส่วนได้ส่วนเสียและผู้บริหารมีความเข้าใจที่ตรงกัน ยกตัวอย่างเช่น หากคุณย้าย workloads เพื่อปรับปรุง user experience ให้คุณระบุจำนวนผู้ใช้งานที่อาจได้รับผลกระทบ และประโยชน์ในแง่ของการลด latency เนื่องจากระยะทางที่เปลี่ยนไป รวมทั้งมูลค่าทางธุรกิจที่จะได้รับจากการย้ายครั้งนี้

การประเมินต้นทุนในการย้าย workloads ของคุณไปยัง Region ปลายทาง นอกเหนือจากต้นทุนการย้ายทั่วไป เช่น ค่าใช้จ่ายในการดำเนินโครงการ, double bubble และอื่นๆ แล้ว คุณยังต้องพิจารณาต้นทุนดังต่อไปนี้:

  • Service price: เนื่องจากราคาของแต่ละบริการแตกต่างกันในแต่ละ Region ให้คุณตรวจสอบค่าบริการของ AWS และประมาณการต้นทุนสำหรับ workload ของคุณใน Region ปลายทาง
  • Spending commitment: ทบทวน Spending Commitment ของคุณ เช่น Amazon EC2 Reserved Instances (RI) และ AWS Savings Plans เนื่องจากอาจมีข้อจำกัดอยู่ใน Region เท่านั้น คุณมีตัวเลือกในการขาย Amazon EC2 Reserved Instance ที่มีอยู่ใน Reserved Instances Marketplace หรือสามารถซื้อ Reserved Instances ใน Region ปลายทางจาก Reserved Instance Marketplace ได้ หรือสามารถซื้อโดยตรงจาก AWS สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีซื้อและขาย Reserved Instances ให้ดูที่ Sell in the Reserved Instance Marketplace และ Amazon EC2 Reserved Instance Marketplace
  • Egress costs: มี costในการส่งข้อมูลออกจาก Region ปัจจุบันไปยัง Region ปลายทาง อย่างไรก็ตาม ไม่มี costในการรับข้อมูลเข้าสู่ Region ปลายทาง ซึ่ง cost ของการส่งข้อมูลออกจะแตกต่างกันไปขึ้นอยู่กับวิธีการถ่ายโอนข้อมูล ไม่ว่าจะเป็นทางอินเทอร์เน็ต , VPC peering, AWS Transit Gateway หรืออื่นๆ สามารถดูข้อมูลเพิ่มเติมเกี่ยวกับต้นทุนการถ่ายโอนข้อมูลได้ใน บทความ Overview of Data Transfer Costs for Common Architectures

การตัดสินใจว่าจะย้ายส่วนใดของ workload ไปยัง Region ปลายทาง

ระบุบริการ AWS ทั้งหมดที่ถูกนำมาใช้ในขั้นตอนการทำงานของ workload แบบ end-to-end ตั้งแต่ deployment pipeline จนถึง day-to-day operations และพิจารณาถึงองค์ประกอบที่มี dependencies จากทั้ง source และ target รวมถึงวิธีการที่ผู้ใช้งานปลายทางมีการทำงานใน workload การทราบรายละเอียดเหล่านี้จะช่วยให้คุณสามารถกำหนดขอบเขตการย้ายได้อย่างชัดเจน และประเมินผลกระทบทั้งหมดที่อาจเกิดขึ้นจากการเปลี่ยนแปลงใดๆ

การย้ายแบบ ข้าม Region นี้จะแตกต่างจากการย้ายจาก on-premises datacenter ที่ลูกค้ามักจะตัดขาดออกไปหลังการย้ายเสร็จสิ้น แต่การย้ายแบบข้าม Region นี้ ส่วนของ Region ต้นทางของ AWS ยังคงสามารถเข้าถึงได้หลังการย้าย workload ทำให้คุณมีทางเลือกว่าจะย้ายองค์ประกอบใดของ workload ไปยัง Region ปลายทาง และจะคงองค์ประกอบใดไว้ที่ Region ต้นทาง

ส่วนประกอบของ workload ที่ควรพิจารณาในการย้ายมีดังนี้ :

  • Configuration : ตัวอย่างเช่น parameter groups และ option groups ภายใน Amazon Relational Database Service (Amazon RDS) หรือการ Configure ค่าต่างๆ เช่น detailed monitoring หรือ VPC flow logs สำหรับ Amazon Elastic Compute Cloud (Amazon EC2) instance และ Amazon Virtual Private Cloud (VPC) อาจมีบางกรณีที่คุณต้องการย้าย Configuration Files เวอร์ชันเก่าไปด้วย
  • Code/Software package: ตัวอย่างเช่น Code หรือ Software package ที่มีอยู่ในรูปแบบ container images ใน Amazon Elastic Container Registry (Amazon ECR) หรือฟังก์ชันใน AWS Lambda
  • Data: การพิจารณาส่วนนี้ ครอบคลุมถึงการย้าย historical และข้อมูล ongoing จาก Region ต้นทางไปยัง Region ปลายทาง ซึ่งอาจไม่จำเป็นต้องทำเสมอไป ขึ้นอยู่กับความต้องการของ workload ด้วย ยกตัวอย่างเช่น คงข้อมูล historical ไว้ใน Amazon Simple Storage Service Glacier (Amazon S3 Glacier) ในกรณีที่ข้อมูลส่วนนี้ไม่จำเป็นต้องใช้ในการทำงานของ workload ใน Region ปลายทาง อีกตัวอย่างหนึ่งคือ workload ที่ต้องแยกตาม location ของผู้ใช้งาน อาจจะย้ายเฉพาะข้อมูลบางส่วนที่จำเป็นไปยัง Region ปลายทางเท่านั้น
  • Supplemental Data: ข้อมูลประเภท backups , snapshots หรือ logs อาจจะไม่ใช่สิ่งจำเป็นสำหรับการทำงานของ workload เราสามารถคงข้อมูลเหล่านี้ไว้ที่ Region ต้นทาง และจะมีเฉพาะ supplemental data ที่สร้างใหม่ใน Region ปลายทางเท่านั้น

การตรวจสอบความเข้ากันได้ (compatibility) ของ workload ใน Region ปลายทาง

อาจมีความแตกต่างของ services และ features ระหว่าง Region ต่างๆ ซึ่งความแตกต่างเหล่านี้อาจเป็นเพียงชั่วคราว เนื่องจาก services และ features ต่างๆ จะถูกเปิดตัวในแต่ละ Region ตามกำหนดการที่แตกต่างกัน ก่อนการย้าย คุณควรตรวจสอบให้แน่ใจว่า workload ของคุณสามารถใช้งานได้ใน Region ปลายทาง ซึ่งทำได้โดยเริ่มต้นจากการรวบรวมรายละเอียดของ workload รวมถึง instance types , services ที่ใช้ , software versions , quotas ฯลฯ จากนั้นเปรียบเทียบกับสิ่งที่พร้อมให้ใช้งานของ Region ปลายทาง ซึ่งความแตกต่างระหว่าง Region ประกอบด้วยด้านต่างๆ ดังนี้

  • Instance type : Amazon มี Instance type ต่างๆ ให้บริการสำหรับบริการต่างๆ เช่น Amazon EC2, Amazon RDS, AWS Database Migration Service (AWS DMS) เป็นต้น อาจมีสถานการณ์ที่ Instance type บางอย่างยังไม่มีให้บริการใน Region นั้นๆ หรือในบางกรณี Instance type เก่าๆ อาจไม่มีให้บริการใน Region ใหม่ ขึ้นอยู่กับบริการแต่ละประเภท มีวิธีการต่างๆ ในการตรวจสอบว่า Instance type นั้นๆ มีให้บริการใน Region หรือไม่ ยกตัวอย่างเช่น สำหรับ Amazon EC2 คุณสามารถใช้ API describe-instance-type-offerings
  • Marketplace/Third-party products : Community Amazon Machine Images (AMI) และ products จาก AWS Marketplace เช่น marketplace AMI และ container images อาจไม่มีให้บริการในทุก Region นอกจากนี้ยังอาจมีข้อจำกัดด้าน license เมื่อนำ third-party products มาใช้งานใน Region อื่น คุณควร review การใช้งาน third-party products ใน workload ของคุณ และติดต่อผู้ให้บริการจาก AWS partner ที่เกี่ยวข้องเพื่อขอข้อมูลเพิ่มเติม
  • Service and/or feature availability : อาจมีสถานการณ์ที่บริการบางอย่างยังไม่มีให้บริการใน Region นั้น หรือ service อาจมีให้บริการแล้ว แต่บาง features ยังไม่พร้อมใช้งาน นอกจากนี้ยังอาจพบว่ามี API บางตัวที่ไม่สนับสนุนในบาง Region หรืออาจมีความแตกต่างกันบ้าง ในกรณีเหล่านี้ คุณสามารถหาข้อมูลเกี่ยวกับความพร้อมใช้งานของบริการได้จากหน้า product documentation และคุณสามารถตรวจสอบความพร้อมของ featureในแต่ละ Region ได้โดยใช้ AWS CloudFormation registry ตัวอย่างเช่น :
  • Runtime versions : อาจมีสถานการณ์ที่ Runtime versions บางตัวไม่มีให้บริการสำหรับ managed service ใน Region ปลายทาง เวอร์ชันที่ support ภายในแต่ละ Region จะระบุอยู่ใน product documentation ยกตัวอย่างเช่น Lambda ไม่ supports Runtime versions ที่กำลังจะถูกยกเลิกภายในหกเดือนข้างหน้าใน Region ใหม่ๆ
  • AWS Service Quotas : คุณควรคาดการณ์ความต้องการด้านทรัพยากรสำหรับ workload ของคุณใน Region ปลายทาง และวางแผนล่วงหน้า AWS Service Quotas แต่ละบริการที่เป็นค่าเริ่มต้นนั้น จะเป็นค่าเฉพาะสำหรับแต่ละ Region เว้นแต่จะมีการระบุไว้เป็นอย่างอื่น และอาจแตกต่างกันไปในแต่ละ Region คุณสามารถขอเพิ่ม Quotas บางรายการ แต่บาง Quotas ไม่สามารถขอเพิ่มได้ คุณสามารถตรวจสอบ Service Quotas ของบริการต่างๆ ได้ที่ Service Quotas console
  • Certification/Compliance : คุณควรตรวจสอบรายงานล่าสุดใน AWS Artifact เพื่อยืนยันว่า Region ปลายทางนั้น เป็นไปตาม compliance requirement ที่เฉพาะเจาะจงสำหรับ workload ของคุณหรือไม่

การวางรากฐาน (Foundation) ใน Region ใหม่

ในการวางรากฐานใน Region ปลายทางก่อนที่จะย้าย workload ไป หาก Cloud Foundation ถูกตั้งค่าบน AWS อยู่แล้ว ให้ extend ไปยัง Region ปลายทาง เริ่มต้นด้วยการเปิดใช้งาน AWS Region ปลายทางก่อน จากนั้นตรวจสอบให้แน่ใจว่า Region ปลายทางนั้นพร้อมสำหรับการนำ workload ไปทำการ Deploy , Configure , secure workloads และมีความพร้อมสำหรับ on-going operations ด้วย คุณอาจพิจารณาใช้ AWS Control Tower เพื่อจัดการสภาพแวดล้อมที่กระจายอยู่ในหลาย Accounts และ Regions ได้อย่างมีประสิทธิภาพมากขึ้น

พิจารณาหัวข้อเหล่านี้เพื่อการขยาย Foundation ได้แก่ :

  • Infrastructure: ตรวจสอบให้แน่ใจว่ามีการจัดเตรียมโครงสร้างพื้นฐานด้านเครือข่ายที่เหมาะสมใน Region ปลายทางแล้ว ยกตัวอย่างเช่น Configure การเชื่อมต่อ AWS Direct Connect จาก on-premises data centers ไปยัง Region ปลายทาง และกำหนดค่า Transit Gateway สำหรับการเชื่อมต่อระหว่าง Region หากการย้ายครั้งนี้เป็นส่วนหนึ่งของการขยายไปยัง Region ใหม่ คุณอาจพิจารณาใช้ AWS Transit Gateway Network Manager เพื่อช่วยในการจัดการและแสดงภาพรวมแบบ centralized นอกจากนี้ ให้ตรวจสอบว่ามี solutions สำหรับ security information and event management (SIEM) , firewalls และอุปกรณ์ด้านความปลอดภัยอื่นๆ ติดตั้งอยู่ใน Region ปลายทางด้วย
  • Security : นำนโยบายและการควบคุมด้านความปลอดภัยมาใช้ใน Region ปลายทาง เพื่อป้องกันทรัพยากรจากช่องโหว่และภัยคุกคามทั้งจากภายนอกและภายใน ซึ่งประกอบด้วยกิจกรรมหลายประการ เช่น การอัปเดต Service Control Policies (SCP) และ AWS Identity and Access Management (IAM) เพื่ออนุญาตการปฏิบัติการใน Region ปลายทาง ตัวอย่างอื่นๆ ได้แก่ การใช้ multi-Region keys ใน AWS Key Management Service (AWS KMS) และ AWS Secrets Manager
  • Business Continuity : สร้างความยืดหยุ่นให้กับแอปพลิเคชันใน Region ปลายทาง เพื่อให้บรรลุเป้าหมายทาง Business และ Security รวมทั้งการกำหนด Recovery Point Objectives (RPO) และRecovery Time Objectives (RTO) คุณอาจต้องการเลือก Region สำรองใหม่สำหรับ disaster recovery ซึ่งคุณสามารถจัดเก็บสำเนาข้อมูลของคุณไว้ที่นั่น และอย่าลืม Update กระบวนการ Backup and Restore ให้ชี้ไปยัง Region สำรองใหม่นี้ด้วย
  • Operations : ตรวจสอบให้แน่ใจว่ามี Observability ที่เข้มแข็งได้รับการนำมาใช้ และเทคนิคในการเก็บรวบรวมข้อมูลเหล่านั้น ยกตัวอย่างเช่น Amazon CloudWatch มีการเตรียม Feature อัตโนมัติสำหรับการ Observe ข้ามหลาย Region คุณควรประเมินการตรวจสอบสุขภาพและการทดสอบเสมือนจริง เช่น Canary ภายใน Region ปลายทาง เพื่อให้ได้ข้อมูล metrics ทั้งที่เกี่ยวกับ performance และ availability อีกด้วย เมื่อย้าย workload ที่ให้บริการกับลูกค้าโดยตรง (customer-facing workloads) คุณอาจพิจารณาใช้ Amazon CloudWatch Internet Monitor เพื่อประเมินประสิทธิภาพในปัจจุบันและที่คาดการณ์ไว้ เนื่องจาก Network Path อาจจะมีการเปลี่ยนแปลงใน Region ปลายทางได้
  • Finances : ขยายกระบวนการ Cloud Financial Management ที่มีอยู่เดิมให้ครอบคลุมถึง Region ปลายทางด้วย และเพิ่มกระบวนการในการติดตามค่าใช้จ่ายข้ามหลาย Region สำหรับแต่ละแอปพลิเคชัน เพื่อให้ผู้มีส่วนได้ส่วนเสียมีข้อมูลที่ชัดเจนและเพียงพอสำหรับการตัดสินใจต่อไป
  • Governance, Risk Management, and Compliance: ขยายกระบวนการกำกับดูแล บริหารความเสี่ยง และการปฏิบัติตามข้อกำหนดที่จัดการแบบรวมศูนย์ไปยัง Region ปลายทาง ยกตัวอย่างเช่น สร้าง Logs Group ใหม่ใน CloudWatch ใน Region ปลายทาง เพื่อรวบรวมและจัดเก็บ environment logs แบบรวมศูนย์ อีกตัวอย่างหนึ่งคือ ขยาย change management process ไปยัง Region ปลายทาง เพื่อควบคุม lifecycle ของการเปลี่ยนแปลงใน Region ปลายทาง

การเลือกวิธีการย้าย (Choose your migration path)

แนวทางที่ระบุไว้ในส่วนนี้ สมมติว่าคุณกำลังย้ายไปยัง Region ใหม่ แต่เช่นเดียวกับการย้ายครั้งอื่นๆ ก็มี migration strategies หลายแบบให้เลือก คุณควรเลือกวิธีการย้ายโดยเริ่มจากการจัดประเภทบริการ AWS ใน Workload ของคุณตาม AWS Fault Isolation Boundaries และความสามารถในการใช้งานข้าม Region จากนั้นจึงค่อยเลือกหนึ่งใน migration paths ที่มีให้

Global services

สำหรับ global services เช่น Amazon Route 53 และ Amazon CloudFront การเปลี่ยนแปลงมักจะทำได้โดย Configure เพื่อ extend การทำงานของ Data Plane ไปยัง Region ปลายทาง ยกตัวอย่างเช่น CloudFront ซึ่งคุณสามารถกำหนดค่า Origin ไปยัง resourceใน Region ปลายทางได้ อีกตัวอย่างหนึ่งคือ IAM ซึ่งอาจมีการ hard-coded การเข้าถึงทรัพยากรในบาง Region โดยเฉพาะ ซึ่งจำเป็นต้องมีการเปลี่ยนแปลงให้เหมาะสมด้วย

Regional and zonal services with cross-Region capability

มีหลายบริการของ AWS ที่รองรับการทำงานแบบ Cross-region เช่น AWS KMS, Amazon Aurora Global Database และ Amazon DynamoDB สำหรับบริการเหล่านี้ จำเป็นต้องมีการเปลี่ยนแปลง Configuration เพื่อขยายทรัพยากรไปยัง Region ปลายทาง ตัวอย่างเช่น AWS KMS ซึ่งคุณสามารถสร้าง replica keys ใน Region อื่นได้ เมื่อใช้กับ customer managed key และ Region ที่สองนี้ ยังได้รองรับการใช้งานกับ Amazon Aurora Global Database ด้วย

ในหลายๆ กรณี คุณสามารถ Promote resource ใน Region สำรองให้เป็นอิสระจากกันได้ จากนั้นคุณสามารถลบทรัพยากรใน Region ต้นทาง ซึ่งจะทำให้การย้ายทรัพยากรจาก Region ต้นทางไปยัง Region ปลายทางสมบูรณ์ อย่างไรก็ตาม ยังมีบางกรณีเช่นใน AWS KMS ที่ไม่สามารถเปลี่ยน Home Region ของ customer managed key ได้

ยังมีอีกหลายแนวทาง และหลายบริการ ที่สามารถย้ายได้ ตามรายละเอียดดังนี้

All Other Services

สำหรับ Services ระดับ Regional และ Zonal ส่วนใหญ่ คุณสามารถใช้วิธีการย้าย ที่คล้ายกับการย้ายจาก on-premises data center ไปยังคลาวด์ AWS ซึ่งโดยทั่วไปจะมีหนึ่งในสามตัวเลือกดังนี้ – redeploy, restore, หรือ replicate.

  • Redeploy : คุณสามารถ redeploy ใน Region ปลายทาง สำหรับบริการต่างๆ เช่น Amazon ECR, Lambda, Amazon Simple Queue Service (Amazon SQS) และ stateless applications ใน Amazon EC2 และมีบางบริการ เช่น AWS DMS และ AWS Elastic Disaster Recovery ที่มีตัวเลือกเพียงแค่ redeploy and reconfigureใน Region ปลายทาง
  • Restore : คุณสามารถทำการ backups/snapshots และ restore ใน Region ปลายทาง สำหรับบาง service เช่น Amazon EC2 and Amazon RDS.
  • Replicate : คุณสามารถใช้เครื่องมือสำหรับทำ replicate เช่น AWS Application Migration Service สำหรับการย้ายเซิร์ฟเวอร์ และ AWS DataSync สำหรับ Amazon FSx นอกจากนี้ ซอฟต์แวร์บางตัวเช่น PostgreSQL หรือ MySQL มี native replication methods ที่สามารถนำมาใช้สำหรับการย้าย workload ได้เช่นกัน หากต้องการใช้ AWS replication tool แนะนำให้ตรวจสอบความพร้อมใช้ service และ features ทั้ง Region ต้นทางและปลายทางด้วย

แม้ว่าแนวทางนี้จะสามารถนำไปใช้กับ AWS partner solutions ได้โดยทั่วไป แต่เราขอแนะนำให้คุณทำงานร่วมกับ Partner ของคุณ เพื่อศึกษารายละเอียดเกี่ยวกับ options ที่มีให้มากขึ้น อย่าลืมปรับปรุงองค์ประกอบอื่นๆ ให้สอดคล้องกับการเปลี่ยนแปลง Region ด้วย เช่น DevOps pipelines , Operational scripts/processes และเอกสารต่างๆ เช่น operational runbooks และ playbooks เพื่อให้การย้ายเป็นไปอย่างราบรื่นและครอบคลุมทุก ๆ ด้าน

สรุป

การวางแผนและการทดสอบอย่างครอบคลุมนั้นมีความสำคัญสูงสุดเมื่อต้องดำเนินการย้ายในทุกประเภท รวมถึงการย้ายข้าม Region ด้วย ลูกค้าควรวางแผนสำหรับทุกส่วนของการย้าย ซึ่งรวมถึงการเตรียม failback processes สำหรับกรณีที่ผลลัพธ์ไม่ตรงกับที่คาดการณ์ไว้ ซึ่ง AWS ทำให้กระบวนการนี้ง่ายขึ้นด้วยการให้ multiple migration paths , เครื่องมือ และความสามารถในการคงโครงสร้างพื้นฐานเดิมไว้จนกว่าการย้ายจะเสร็จสมบูรณ์

หากคุณมีคำถามเกี่ยวกับการย้าย Workloads ระหว่าง AWS Regions กรุณาติดต่อ AWS contact and support team