2 ปีหลังย้ายออกจาก AWS ไปใช้ Bare Metal: ตอบคำถามเรื่องการหนีออกจาก AWS

• รายงานที่รวบรวมคำตอบติดตามผลต่อคำถามหลากหลายจากชุมชน หลังจากแชร์ประสบการณ์เมื่อ 2 ปีก่อนเรื่อง ย้ายจาก AWS ไปใช้ Bare Metal และประหยัดได้ปีละ 230,000 ดอลลาร์ โดยเปิดเผยข้อมูลการปฏิบัติงานจริงตลอด 2 ปี และระบุว่าสามารถลดค่าใช้จ่ายได้มากกว่า 1.2 ล้านดอลลาร์ต่อปี
• จากการใช้งานจริง ยอดประหยัดเพิ่มขึ้นเป็นมากกว่า 1.2 ล้านดอลลาร์ต่อปี และได้นำเงินส่วนนี้กลับไปลงทุนใน เซิร์ฟเวอร์สำหรับสรุปเหตุขัดข้องด้วย AI และการแก้โค้ดอัตโนมัติ ซึ่งช่วยยกระดับคุณภาพบริการ
• บนพื้นฐานของ MicroK8s + Ceph stack สามารถรักษา availability 99.993% ได้ และใช้ โครงสร้างศูนย์ข้อมูลคู่ เพื่อตัดจุดล้มเหลวเพียงจุดเดียวออกไป
• อธิบายประเด็นสำคัญอย่าง ต้นทุนการปฏิบัติงานจริง การรับมือเหตุขัดข้อง อายุฮาร์ดแวร์ การรับรองความปลอดภัย และบริการทดแทนคลาวด์ พร้อมตัวเลขอย่างเป็นรูปธรรม
• สรุปได้ว่า ทั้งความเสถียรและความคุ้มค่าดีขึ้น และสำหรับระบบที่มีโหลดคงที่ในระดับหนึ่ง Bare Metal เป็นทางเลือกที่สมเหตุสมผลกว่า

---

สรุปผลการดำเนินงานตลอด 2 ปี

• ตลอด 24 เดือน ได้รัน MicroK8s + Ceph stack ในสภาพแวดล้อม production และทำ availability ได้ 99.993%
  • เพื่อแก้ปัญหา rack เดี่ยว ได้เพิ่ม rack ที่สอง ที่แฟรงก์เฟิร์ต และเชื่อมต่อแบบ DWDM ซ้ำซ้อน กับ rack หลักที่ปารีส
  • การใช้ local NVMe และการลดการรบกวนจากสัญญาณรบกวน ช่วยลด latency ฝั่งลูกค้าได้ 19%
• ได้นำต้นทุนที่ประหยัดได้กลับไปลงทุนซื้อ เซิร์ฟเวอร์ AI แบบ bare metal เพื่อขยายความสามารถ การสรุปการแจ้งเตือนด้วย LLM และฟีเจอร์แก้โค้ดอัตโนมัติ ของ OneUptime

ผลการประหยัดและการเปรียบเทียบต้นทุน

• เดิมคาดว่าจะประหยัดได้ $230,000 ต่อปี แต่ตอนนี้เพิ่มเป็น มากกว่า $1.2M
  • เทียบเท่ากับ ประหยัดได้ราว 76% เมื่อเทียบกับ AWS
  • หากอิงค่าจ้างบุคลากรระดับสากล ถือเป็นมูลค่าเทียบเท่าเงินเดือนวิศวกร 2–5 คน
• แม้จะใช้ Savings Plans / Reserved Instances แล้ว Bare Metal ก็ยังได้เปรียบ
  • Savings Plans ไม่ครอบคลุม ค่าใช้จ่าย S3·Egress·Direct Connect
  • ค่าใช้จ่ายอย่าง EKS control plane $1,260/เดือน และ NAT gateway $600/เดือน ก็ลดไม่ได้
  • สำหรับ workload แบบ steady ที่ทำงานตลอด 24/7 ประสิทธิภาพของ reserved instances จึงมีข้อจำกัด

ต้นทุนการย้ายระบบและการปฏิบัติงาน

• การย้ายระบบช่วงแรกเสร็จสิ้นด้วยงานวิศวกรรมประมาณ 1 สัปดาห์
  • งานส่วนใหญ่เป็นสิ่งที่เดิมก็จำเป็นต้องทำอยู่แล้ว เช่น ปรับปรุง IaC และเสริมความเข้มงวดของนโยบายสำรองข้อมูล
• ปัจจุบันต้นทุนการปฏิบัติงานมีดังนี้:
  • ดูแลเองโดยตรง: ประมาณ 24 ชั่วโมงต่อไตรมาส (รวม patch และ firmware update)
  • Remote Hands: ตลอด 24 เดือน ต้องเข้าแทรกแซงเพียง 2 ครั้งเท่านั้น (ส่วนใหญ่เป็นปัญหาดิสก์) โดยใช้เวลาตอบสนองเฉลี่ย 27 นาที
  • Automation: PXE boot (Tinkerbell), การจัดการอิมเมจ Talos, การตั้งค่าอัตโนมัติด้วย Flux/Terraform
• ทีมปฏิบัติการไม่เพียงไม่เพิ่มภาระจากสมัยอยู่ AWS แต่ยัง เพิ่มความเร็วในการปล่อยรีลีส และลดภาระจากการต้องเข้าประชุม “ปรับแต่งต้นทุน” ได้ด้วย

การรับมือเหตุขัดข้องและการทำให้พร้อมใช้งานสูง

• เพิ่ม rack ที่สอง ที่แฟรงก์เฟิร์ต และเชื่อมต่อ DWDM แบบสองเส้นทาง เพื่อตัด single point of failure
  • ใช้ Ceph mirroring แบบ asynchronous replication และโครงสร้าง dual control plane
  • เพิ่ม เส้นทางบริหารจัดการผ่าน 4G/ดาวเทียม เพื่อให้เข้าถึงจากระยะไกลได้เมื่อเกิดปัญหาเครือข่าย
• กำลังเปลี่ยนจาก MicroK8s → Talos
• ยังคงรักษา AWS failover backup cluster เอาไว้ และทำ ซ้อมกู้คืนจากเหตุขัดข้องรายไตรมาส
• ใช้ Ingress แบบ Anycast+BGP ทำให้เวลาหน่วงจากการสลับ DNS ลดลงเหลือต่ำกว่า 1 นาที
• ตลอด 2 ปีรักษา availability 99.993% ได้ และไม่ได้รับผลกระทบจากเหตุขัดข้องของ AWS region ล่าสุด

ฮาร์ดแวร์และการจัดการ CapEx

• เซิร์ฟเวอร์ถูกใช้งานภายใต้สมมติฐาน ค่าเสื่อม 5 ปี (2×EPYC 9654, RAM 1TB, ชุด NVMe)
  • เมื่อประสิทธิภาพเริ่มอิ่มตัว จะ ย้ายไปเป็น analytics cluster แล้วแทนที่ด้วยเซิร์ฟเวอร์ใหม่
  • จากเงินที่ประหยัดได้ ทำให้สามารถ refresh ได้ 40% ทุก 2 ปี และยังคงประหยัดรายปีมากกว่า AWS
• ขยายประกัน Supermicro และมีเซิร์ฟเวอร์สำรอง 3 เครื่อง
  • อายุใช้งานจริงอยู่ที่ 7–8 ปี แต่คำนวณแบบอนุรักษ์นิยมไว้ที่ 5 ปี

เหตุผลในการใช้บริการทดแทน managed service

• ปรัชญาผลิตภัณฑ์ของ OneUptime คือความสามารถในการโฮสต์เองได้ จึงจำเป็นต้องคง stack แบบเดียวกันไว้
  • รักษาความสอดคล้องของ open stack เช่น Kubernetes·Postgres·Redis·ClickHouse
• พัฒนาจาก Terraform + EKS + RDS → MicroK8s + Argo Rollouts + Ceph
  • ใช้โอเพนซอร์สแบบต้นฉบับโดยไม่ทำ fork เอง
• ยังคง ใช้คลาวด์ควบคู่กันไป เช่น AWS Glacier (สำรองข้อมูล), CloudFront (edge caching), และอินสแตนซ์ชั่วคราวสำหรับทดสอบโหลด
• คลาวด์เหมาะกับ ความยืดหยุ่น, ส่วน bare metal เหมาะกับ โหลดพื้นฐานที่มีอยู่ตลอดเวลา

เครือข่ายและความปลอดภัย

• มีวงจรสื่อสาร 5Gbps (95th percentile) จำนวน 2 เส้น ซึ่ง ถูกกว่า AWS egress 8 เท่า
• การป้องกัน DDoS แก้ด้วยการวาง Cloudflare ไว้ด้านหน้าเต็มรูปแบบ
• มีเครือข่ายบริหารจัดการแยกอิสระผ่าน 4G/ดาวเทียม จึงเข้าถึงจากระยะไกลได้เมื่อเกิดเหตุขัดข้อง

การปฏิบัติตามข้อกำหนดและการรองรับการตรวจสอบ

• ยังคงรักษาการรับรอง SOC 2 Type II, ISO 27001
  • ใช้ข้อมูล การรับรอง Tier III, บันทึกการเข้าออก, CCTV ของศูนย์ colocation
  • ใช้ Terraform/Talos configuration log เป็นหลักฐานประวัติการเปลี่ยนแปลง
• ผู้ตรวจประเมินให้ความเห็นว่าเชื่อถือสิ่งเหล่านี้มากกว่าภาพหน้าจอจากคอนโซล AWS

เปรียบเทียบทางเลือกแทนคลาวด์

• เปรียบเทียบ Hetzner, OVH, Leaseweb, Equinix Metal, AWS Outposts
  • Hyperscaler ยังมีค่า egress สูงอยู่
  • ผู้ให้บริการโฮสต์ในยุโรปตอบโจทย์ได้ยากทั้งในด้าน Ceph cluster ขนาดใหญ่และข้อกำหนด SLA
  • Equinix Metal มีพรีเมียมราว 25–30% เมื่อเทียบกับ CapEx
  • การใช้ฮาร์ดแวร์ของตนเองได้เปรียบในด้าน ความหนาแน่นกำลังไฟและอิสระในการอัปเกรด
• สุดท้ายแล้ว ด้วย rack ขนาด 15kW และความสามารถในการนำชิ้นส่วนกลับมาใช้ซ้ำ ทำให้ colocation เหนือกว่าทั้งด้านต้นทุนและประสิทธิภาพ

การวัดภาระงานเชิงปฏิบัติการ (TOIL)

• รายสัปดาห์: patch kernel/firmware และตรวจสอบ Ceph (1 ชั่วโมง)
• รายเดือน: canary upgrade ของ Kubernetes control plane (2 ชั่วโมง)
• รายไตรมาส: ซ้อม DR, วางแผนความจุ, ทบทวนสัญญากับผู้ให้บริการเครือข่าย (12 ชั่วโมง)
• รวมแล้วอยู่ที่ ประมาณ 14 ชั่วโมงต่อเดือน ใกล้เคียงกับสมัยอยู่ AWS แต่จุดโฟกัสย้ายจาก “ติดตามต้นทุน” ไปเป็น “automation ฝั่งปฏิบัติการ”

กรณีที่คลาวด์ยังเหมาะสมอยู่

• เมื่อ workload มีลักษณะ พุ่งสูงเป็นช่วง ๆ หรือเป็นฤดูกาล
• เมื่อพึ่งพา managed services สูง เช่น Aurora Serverless, Kinesis, Step Functions
• เมื่อยังไม่มีความพร้อมในการดูแล Kubernetes·Ceph·monitoring·incident response ด้วยตนเอง
• กล่าวคือ สำหรับธุรกิจระยะเริ่มต้นหรือมีโหลดแปรผันสูง คลาวด์ยังคงได้เปรียบ

แผนในอนาคต

• มีแผนเผยแพร่ Terraform module และ Runbook สำหรับคาดการณ์งบประมาณ colo
• กำลังเตรียมโพสต์เชิงเทคนิคแบบเจาะลึกเกี่ยวกับประสบการณ์ปฏิบัติงานบน Talos
• จะเดินหน้าตอบรับฟีดแบ็กจาก HN·Reddit อย่างต่อเนื่อง พร้อม แชร์กรณีศึกษาที่อิงตัวเลขจริง ต่อไป

[xguru]

ย้ายจาก AWS ไปใช้เบร์เมทัลและประหยัดได้ 230,000 ดอลลาร์ต่อปี (300 ล้านบาท)

[okxrr]

ฉันทำงานอยู่ที่บริษัทที่ใช้งาน AWS อย่างหนักทั้งที่แทบไม่ได้ใช้บริการที่มีเฉพาะบน AWS เลย

เป็นเรื่องชวนขำไม่ออกที่ได้เห็นว่าการตัดสินใจนี้ได้รับอิทธิพลอย่างมากจากความทะเยอทะยานส่วนตัวของผู้นำบางคนเรื่องการพัฒนาเส้นทางอาชีพของตัวเอง..

[GN⁺]

ความคิดเห็นจาก Hacker News

• AWS แพงเกินไป เหตุผลที่จะวางระบบทั้งหมดบน AWS มีน้อยกว่าที่คิด เมื่อก่อนทุกคนยังรู้วิธีดูแล เซิร์ฟเวอร์แบบ bare metal กันเอง แต่ตอนนี้เหมือนจะลืมกันไปแล้ว ทีมของเรารักษา uptime 99.993% มาเกิน 730 วัน และยังรอดจากเหตุขัดข้องของรีเจียน AWS ล่าสุดได้ด้วย แม้จะใช้ Cloudflare ป้องกัน DDoS แต่ก็เข้าใจได้ว่าการดูแล DNS หรือ ingress อาจกลายเป็นงานเต็มเวลา อย่างไรก็ดี ถ้ามีแค่ไมโครเซอร์วิสไม่กี่ตัวกับฐานข้อมูล ก็ดูแลเองได้สบาย AWS คิดค่าบริการแพงเกินไปสำหรับบริษัทส่วนใหญ่

  • ปัญหาที่แท้จริงของ AWS คือ การทำให้พนักงานยึดติดกับ AWS พอไปสอบใบรับรอง AWS และมีบรรยากาศว่าต้องทำตาม AWS Well Architected Framework ก็ทำให้เลิกคิดด้วยตัวเอง บริการแบบ lock-in ของ AWS มักตั้งราคาให้ดูเหมือนถูกโดยตั้งใจ แต่สุดท้ายก็ยิ่งผูกมัดลึกขึ้น เช่น ถ้าย้ายจาก PostgreSQL ไป DynamoDB อาจดูเหมือนประหยัดในระยะสั้น แต่ระยะยาวจะยิ่งพึ่งพา AWS มากขึ้น
  • ระบบ on-premise ถูกกว่า แต่ หาคนที่มีความเชี่ยวชาญได้ยาก เหมาะกับผลิตภัณฑ์ที่ไม่ซับซ้อน แต่ถ้าระบบซับซ้อนมาก ต้นทุนคนและความเสี่ยงด้านปฏิบัติการอาจกลับสูงกว่า AWS/Azure/GCP ไม่ได้สมบูรณ์แบบ แต่ทุกวันนี้ผู้เชี่ยวชาญ on-premise หายากเกินไป
  • เวลาใครวิจารณ์ AWS มักมี คนออกมาต่อต้านแบบแปลกๆ เยอะมาก บน Reddit ก็มีปรากฏการณ์คล้ายกัน รู้สึกเหมือนมีใครรับเงินมาแก้ต่างให้ AWS
  • เรื่องเล่าความสำเร็จของการ self-hosting มี อคติแบบยืนยันความเชื่อเดิม การดูแลเซิร์ฟเวอร์เองช่วงแรกอาจดูดี แต่พอผ่านไปราว 1 ปี เอกสารกับค่าคอนฟิกจริงจะเริ่มไม่ตรงกัน แล้วถ้าคนรับผิดชอบลาออก ความวุ่นวายจะยิ่งหนัก สุดท้ายสตาร์ทอัพจำนวนมากก็กลับไปหา AWS ใหม่ เรื่องล้มเหลวแบบนี้มักไม่ค่อยมีใครแชร์
  • ถ้าจะรัน bare metal ให้ดี ต้องมี วิศวกรที่ชำนาญ ใช้แค่มือใหม่หรือ “ผู้เชี่ยวชาญคลาวด์” จากบริษัทคอนซัลต์นั้นไม่พอ

• คลาวด์ยุคแรกเริ่มต้นจากบริการที่เรียบง่ายและ คุ้มค่าต่อราคา แต่ตอนนี้กลับพันกันยุ่งกับบริการซับซ้อนกว่า 200 ตัว ถ้าไม่บริหารให้ดี ค่าใช้จ่ายจะพุ่งขึ้นอย่างหนัก

  • จริงๆ แล้ว AWS ไม่ได้มีจุดขายว่า “ถูก” มาตั้งแต่แรก แต่คือ “ขยายได้เร็ว” ต่างหาก ช่วงต้นทศวรรษ 2010 ก็แพงอยู่แล้ว แต่เด่นที่ความยืดหยุ่น ตอนนี้ถ้าเทียบราคาต่อประสิทธิภาพก็ยังแพงอยู่ดี ถ้ามีพื้นฐานการดูแลเซิร์ฟเวอร์แค่พอสมควร เซิร์ฟเวอร์เฉพาะทางก็ดีกว่ามาก
  • ตอนนี้ AWS ขยายเกินพอดีจนมี มากกว่า 200 บริการ แล้ว ควรกลับไปโฟกัสที่ฟังก์ชันพื้นฐาน
  • ทุกครั้งที่เข้า AWS Console จะรู้สึกถึง ความซับซ้อนและความเหนื่อยล้า มันใหญ่เทอะทะเกินไป
  • แต่ละบริการของ AWS มี ความคุ้มค่าต่อราคาต่างกันมาก โดยเฉพาะบริการหลักรุ่นเก่าๆ หลายตัวยังมีคุณค่าอยู่

• ความสามารถที่แท้จริงของ AWS คือ (1) ทำให้ การขยายองค์กรและโครงสร้างอำนาจ เป็นไปได้ (2) ทำบัญชีเป็น OpEx แทน CapEx ได้ และ (3) ช่วยกลบโครงสร้างบุคลากรที่ไร้ประสิทธิภาพ เมื่อก่อนใช้คน 5–10 คนก็ดูแลดาต้าเซ็นเตอร์ได้ แต่ตอนนี้กลับมีองค์กร DevOps ขนาด 3,000 คน

  • ไม่เข้าใจว่าความต่างระหว่าง OpEx กับ CapEx สำคัญตรงไหน สุดท้ายเงินก็คือเงินไม่ใช่หรือ?
  • คลาวด์มีประโยชน์กับ สตาร์ทอัพระยะแรก เพราะโตได้เร็วโดยไม่ต้องกังวลเรื่อง capacity planning แต่ถ้าบริษัทโตช้าลงแล้วยังอยู่บนคลาวด์ต่อ ก็จะไม่มีประสิทธิภาพ
  • on-premise มักคัสตอมหนักจน เปลี่ยนคนดูแลได้ยาก ขณะที่คนทำ AWS หาจากที่ไหนก็ได้
  • ผู้ดูแลระบบที่มีประสบการณ์จริงนั้น หายากและค่าตัวแพง เคยเห็นกรณีที่พยายามประหยัดจนแบ็กอัปไม่ทำมา 2 ปีแล้ว

• หัวใจของความสำเร็จนี้คือ โหลดคงที่ตลอด 24/7 ซึ่งจริงๆ แล้วบริษัทส่วนใหญ่ก็มีแพตเทิร์นคล้ายกัน

  • ที่จริงการเริ่มต้นด้วย แร็กเดียว ดาต้าเซ็นเตอร์เดียว ตั้งแต่แรกถือว่าโชคดี เพราะยังไม่ต้องจ่ายต้นทุนด้านความน่าเชื่อถือไว้ล่วงหน้า
  • บทความที่เกี่ยวข้อง: One Big Server
  • AWS มักบอกว่า “ไม่มีสต็อก” แล้วผลักให้ซื้อ reserved instance สุดท้ายต้นทุนก็ใกล้เคียงกับการรันแบบถาวรอยู่ดี
  • ผู้ให้บริการอย่าง Hetzner ให้ประสิทธิภาพระดับเดียวกันในราคาที่ ถูกกว่า AWS 10 เท่า ความ “ยืดหยุ่น” ของคลาวด์เป็นเรื่องเล่าที่ถูกพูดเกินจริง

• ประเด็นสำคัญคือ ความยืดหยุ่นเทียบกับโหลดพื้นฐาน ถ้ามีทราฟฟิกพุ่งเป็นช่วงๆ แบบงานเก็บข้อมูล คลาวด์จะได้เปรียบ แต่ในกรณีส่วนใหญ่ bare metal ดีกว่า

• ในยุค 2010 ฮาร์ดแวร์กับเครือข่ายยังช้า แต่ตอนนี้ ประสิทธิภาพและความคุ้มพลังงานของ CPU ดีขึ้นหลายร้อยเท่า เซิร์ฟเวอร์ 64 เครื่องเมื่อก่อน ตอนนี้ใช้แค่ 1 เครื่องก็พอ ต่อไปอาจไปถึงสัดส่วน 100:1 ได้ ในสถานการณ์แบบนี้ ข้อดีของคลาวด์ก็ลดลงเรื่อยๆ

• ในมุมของพนักงาน Amazon การ ดูแล Kubernetes เอง เสี่ยงเกินไป คอมโพเนนต์อย่าง etcd ไม่เสถียรและเคยต้องแพตช์เองด้วย ความเสี่ยงของ self-hosting ที่บทความพูดถึงยังประเมินต่ำเกินไป

  • แม้แต่ hyperscaler รายอื่นก็เคยเจอเหตุขัดข้องใหญ่จาก การดูแล Kubernetes ล้มเหลว ทางเลือกที่ง่ายกว่าสำหรับแร็กเดียวอย่าง Microk8s น่าจะดีกว่า บทความที่เกี่ยวข้อง: Microk8s 6 Months Later
  • สภาพแวดล้อมที่ซับซ้อนนั้นยากไม่ว่าที่ไหน และสุดท้ายก็ยัง ต้องการผู้เชี่ยวชาญ AWS เองก็ไม่ได้ง่ายเหมือนกัน ถึงคลาวด์จะล่ม โลกก็ยังหมุนต่อไป
  • เวอร์ชันเบาอย่าง k3 เรียบง่ายกว่ามาก
  • ควรใช้ Kubernetes เฉพาะเมื่อจำเป็น ถ้าใช้เป็นค่าเริ่มต้นจะเสียทั้งเวลาและเงิน

• สตาร์ทอัพจำนวนมากคงอยู่ไม่ได้เลยถ้าต้องจ่าย AWS แพงขนาดนั้น ตัวอย่างเช่นการดาวน์โหลด GeoIP ฟรี (ลิงก์) คงเป็นไปไม่ได้ คลาวด์ช้า และมีทั้ง disk latency และ CPU contention สูง ถ้าค่าใช้จ่ายต่ำกว่า 10,000 ดอลลาร์ต่อเดือนยังพอรับได้ แต่เกินจากนั้น bare metal จะมีประสิทธิภาพกว่ามาก

  • เมื่อคุ้นกับประสิทธิภาพที่ช้าของคลาวด์ จะเกิด การปรับตัวแบบประหลาด ควรเทียบกับมาตรฐาน bare metal อยู่เสมอ

• บริษัทที่ผมเคยทำงานก็ทราฟฟิกน้อย แต่ก็พยายามย้ายไป AWS เหตุผลง่ายมาก — เพราะ อยากใส่ AWS ลงในเรซูเม่ ไม่ใช่แค่นักพัฒนา แม้แต่ผู้บริหารก็คิดแบบเดียวกัน เพราะ “ผู้นำการย้ายระบบไป AWS” ดูดีต่อประวัติการทำงาน สุดท้ายบริษัทก็ถูกขาย และออฟฟิศก็ว่างเปล่า ต่อไป “ย้ายออกจาก AWS สำเร็จ” อาจกลายเป็นจุดขายใหม่ในอาชีพก็ได้

  • ถ้านักพัฒนาต้องการ AWS คนรุ่นต่อไปก็จะรู้จักแค่ AWS ทำให้การถกเถียงเอนเอียง
  • สุดท้ายการตัดสินใจก็ขึ้นอยู่กับ ความตั้งใจของผู้นำ

• สุดท้ายสิ่งสำคัญคือ กำลังจะทำอะไร

  • ถ้าเป็นเว็บไซต์ภายในองค์กรที่เน้นข้อมูล แค่เซิร์ฟเวอร์แร็กเดียวก็พอ
  • ถ้าเป็นทราฟฟิกขนาดใหญ่ที่มาไม่สม่ำเสมอและแคชไม่ได้ คลาวด์จะเหมาะกว่า
  • ถ้า DNS หรือ ingress ซับซ้อน การใช้แบบไฮบริดจะดีกว่า
  • ยิ่งขนาดข้อมูลใหญ่ขึ้น โครงสร้างการคิดค่าเสื่อมระยะยาวของคลาวด์ก็ยิ่งได้เปรียบ