Cloud Fundamentals

"The cloud" is someone else's data centres, rented through an API. Instead of buying servers, waiting weeks and guessing how many you'll need, you ask for computers, storage and databases with a click or a command, get them in minutes, and pay per second or per gigabyte while you use them. Three things make it different from renting a server: it's on demand, it's elastic (grow and shrink any time), and everything is controlled by an API, so it can be automated. "คลาวด์" คือศูนย์ข้อมูลของคนอื่นที่เราเช่าผ่าน API แทนที่จะซื้อเซิร์ฟเวอร์ รอหลายสัปดาห์ และเดาว่าต้องใช้กี่เครื่อง เราขอคอมพิวเตอร์ ที่เก็บข้อมูล และฐานข้อมูลได้ด้วยการคลิกหรือคำสั่งเดียว ได้มาในไม่กี่นาที และจ่ายเป็นวินาทีหรือเป็นกิกะไบต์เท่าที่ใช้ สามสิ่งที่ทำให้ต่างจากการเช่าเซิร์ฟเวอร์คือ ได้ทันทีเมื่อต้องการ (on demand) ยืดหยุ่น (elastic) ขยายและลดได้ทุกเมื่อ และทุกอย่าง ควบคุมผ่าน API จึงทำให้เป็นอัตโนมัติได้

A region is a city-sized area with cloud data centres, such as Singapore, Jakarta or Bangkok. Inside a region are usually three or more availability zones: separate data centres with their own power, cooling and network, a few kilometres apart and joined by very fast links. A fire or power cut in one zone shouldn't touch the others. region คือพื้นที่ขนาดประมาณหนึ่งเมืองที่มีศูนย์ข้อมูลของคลาวด์ เช่น สิงคโปร์ จาการ์ตา หรือกรุงเทพฯ ภายใน region มักมี availability zone สามแห่งขึ้นไป คือศูนย์ข้อมูลที่แยกกันและมีไฟฟ้า ระบบทำความเย็น และเครือข่ายของตัวเอง อยู่ห่างกันไม่กี่กิโลเมตรและเชื่อมกันด้วยลิงก์ที่เร็วมาก ไฟไหม้หรือไฟดับใน zone หนึ่งไม่ควรกระทบ zone อื่น

Design rule: run important things in at least two zones. One zone failing is rare but normal; a whole region failing is very rare, and protecting against it (a second region) costs much more. The next lesson shows why two zones help so much. หลักการออกแบบคือ รันสิ่งที่สำคัญใน อย่างน้อยสอง zone zone หนึ่งล่มนั้นเกิดขึ้นได้แม้จะไม่บ่อย ส่วนทั้ง region ล่มนั้นเกิดขึ้นยากมาก และการป้องกัน (ใช้ region ที่สอง) มีค่าใช้จ่ายสูงกว่ามาก บทถัดไปจะแสดงว่าทำไมสอง zone จึงช่วยได้มาก

Providers promise availability in a service level agreement (SLA), like "99.9% per month", and give credits if they miss it. The "nines" sound alike but mean very different amounts of downtime: ผู้ให้บริการสัญญาเรื่องความพร้อมใช้งานไว้ใน service level agreement (SLA) เช่น "99.9% ต่อเดือน" และคืนเครดิตถ้าทำไม่ได้ จำนวน "เลขเก้า" ฟังดูคล้ายกัน แต่หมายถึงเวลาที่ระบบล่มต่างกันมาก

Your app depends on several services in a chain: a load balancer, a VM, a database. It works only if all of them work, so their availabilities multiply, and the result is lower than any one of them. Running two VMs in different zones changes the picture: the app is down only if both are down at the same time. แอปของเราพึ่งพาหลายบริการต่อกันเป็นสาย เช่น load balancer, VM และฐานข้อมูล แอปทำงานได้ก็ต่อเมื่อทุกตัวทำงาน ความพร้อมใช้งานจึง คูณกัน และผลลัพธ์ต่ำกว่าตัวใดตัวหนึ่ง การรัน VM สองเครื่องในต่าง zone เปลี่ยนภาพนี้ เพราะแอปจะล่มก็ต่อเมื่อทั้งสองเครื่องล่มพร้อมกัน

The second VM cut expected downtime from about 69 to 26 minutes a month, and what's left now comes mostly from the database and the load balancer. That is the whole idea of high availability: find the single points of failure and give each one a partner in another zone. VM เครื่องที่สองลดเวลาที่คาดว่าจะล่มจากประมาณ 69 เหลือ 26 นาทีต่อเดือน และส่วนที่เหลือตอนนี้มาจากฐานข้อมูลและ load balancer เป็นหลัก นี่คือแนวคิดทั้งหมดของ high availability คือหาจุดที่ล้มแล้วระบบล่มทั้งหมด (single point of failure) แล้วให้แต่ละจุดมีคู่ใน zone อื่น

The provider secures the cloud itself: buildings, hardware, the network, the virtualisation. You secure what you put in it. Where the line falls depends on the model; your data, your users and their permissions are always yours. ผู้ให้บริการดูแลความปลอดภัยของตัวคลาวด์ ได้แก่ อาคาร ฮาร์ดแวร์ เครือข่าย และระบบเสมือน ส่วน เรา ดูแลความปลอดภัยของสิ่งที่เรานำไปใส่ เส้นแบ่งอยู่ตรงไหนขึ้นกับรูปแบบบริการ แต่ข้อมูล ผู้ใช้ และสิทธิ์ของผู้ใช้เป็นของเราเสมอ

Most cloud security incidents happen on your side of the line: a storage bucket left public, a password in a Git repository, a firewall open to the whole internet. Lesson 12 shows the usual ones. เหตุการณ์ด้านความปลอดภัยบนคลาวด์ส่วนใหญ่เกิดฝั่ง เรา เช่น bucket ที่ถูกเปิดเป็นสาธารณะ รหัสผ่านใน Git repository หรือไฟร์วอลล์ที่เปิดให้ทั้งอินเทอร์เน็ต บทที่ 12 แสดงกรณีที่พบบ่อย

Every API call to a cloud is made by an identity, a principal: a person, or a program using a role (a service account). Policies say which actions a principal may perform on which resources. Clouds evaluate them in the same spirit: everything is denied unless something allows it, and an explicit deny always wins. Here is a tiny version of that logic: ทุกการเรียก API ของคลาวด์ทำโดยตัวตนหนึ่งที่เรียกว่า principal ซึ่งอาจเป็นคน หรือโปรแกรมที่ใช้ role (service account) policy บอกว่า principal ทำ action ใดกับทรัพยากรใดได้บ้าง คลาวด์ประเมินด้วยหลักเดียวกัน คือทุกอย่างถูกปฏิเสธ เว้นแต่มีสิ่งที่อนุญาต และการปฏิเสธอย่างชัดแจ้ง (explicit deny) ชนะเสมอ นี่คือตรรกะนั้นในแบบย่อ

A virtual private cloud (VPC on AWS and Google Cloud, VNet on Azure) is your own private network inside the cloud, with an address range you choose, like 10.0.0.0/16. You divide it into subnets. A public subnet has a route to the internet (for load balancers); a private subnet doesn't (for app servers and databases), and reaches out only through a NAT gateway. The subnet maths is the same as in the Networking guide: virtual private cloud (VPC บน AWS และ Google Cloud, VNet บน Azure) คือเครือข่ายส่วนตัวของเราภายในคลาวด์ โดยเลือกช่วง address เอง เช่น 10.0.0.0/16 แล้วแบ่งเป็น ซับเน็ต ซับเน็ต สาธารณะ มีเส้นทางออกอินเทอร์เน็ต (สำหรับ load balancer) ส่วนซับเน็ต ส่วนตัว ไม่มี (สำหรับเซิร์ฟเวอร์แอปและฐานข้อมูล) และออกไปข้างนอกได้ผ่าน NAT gateway เท่านั้น การคำนวณซับเน็ตเหมือนใน คู่มือ Networking

One public and one private subnet per zone, three zones: the usual layout. Private subnets are made big because that's where the servers and containers live. Traffic is then filtered by security groups (AWS), network security groups (Azure) or firewall rules (Google Cloud): lists of allowed ports and sources, with everything else dropped, exactly like the firewall in the Networking guide. ซับเน็ตสาธารณะหนึ่งวงและส่วนตัวหนึ่งวงต่อ zone รวมสาม zone คือรูปแบบที่ใช้กันทั่วไป ซับเน็ตส่วนตัวทำให้ใหญ่ เพราะเป็นที่อยู่ของเซิร์ฟเวอร์และ container จากนั้นการรับส่งข้อมูลจะถูกกรองด้วย security group (AWS), network security group (Azure) หรือ firewall rule (Google Cloud) ซึ่งเป็นรายการพอร์ตและต้นทางที่อนุญาต ที่เหลือถูกทิ้งทั้งหมด เหมือนไฟร์วอลล์ในคู่มือ Networking

There are three main ways to run code, from most control to least work: วิธีหลักในการรันโค้ดมีสามแบบ เรียงจากควบคุมได้มากที่สุดไปถึงทำงานน้อยที่สุด

Autoscaling adds machines or containers when load rises and removes them when it falls, based on CPU, requests or queue length. It's the "elastic" in Lesson 1, and the main reason the cloud can be cheaper than owning servers: you stop paying for capacity you only need at peak. Autoscaling เพิ่มเครื่องหรือ container เมื่อโหลดสูงขึ้น และลดลงเมื่อโหลดต่ำลง โดยอิงจาก CPU จำนวนคำขอ หรือความยาวของคิว นี่คือความ "ยืดหยุ่น" ในบทที่ 1 และเป็นเหตุผลหลักที่คลาวด์ถูกกว่าการมีเซิร์ฟเวอร์เอง เพราะไม่ต้องจ่ายค่ากำลังเครื่องที่ต้องใช้เฉพาะช่วงพีก

Cloud bills come from a few meters: compute time (per second or hour), storage (per GB per month), requests, and data transfer out of the cloud (per GB). Data coming in is usually free; data going out to the internet is not, and it surprises many teams. Here's an example month with three small VMs, 500 GB of files and 2 TB downloaded by users: ค่าใช้จ่ายของคลาวด์มาจากมิเตอร์ไม่กี่ตัว ได้แก่ เวลาประมวลผล (ต่อวินาทีหรือชั่วโมง) ที่เก็บข้อมูล (ต่อ GB ต่อเดือน) จำนวนคำขอ และ ข้อมูลที่ส่งออก จากคลาวด์ (ต่อ GB) ข้อมูลขาเข้ามักไม่เสียเงิน แต่ข้อมูลขาออกไปยังอินเทอร์เน็ตเสียเงิน และทำให้หลายทีมประหลาดใจ นี่คือตัวอย่างหนึ่งเดือนที่มี VM ขนาดเล็กสามเครื่อง ไฟล์ 500 GB และผู้ใช้ดาวน์โหลด 2 TB

In this example the data leaving the cloud costs more than the servers. A CDN, compression and caching cut it. ในตัวอย่างนี้ข้อมูลที่ออกจากคลาวด์มีค่าใช้จ่ายมากกว่าเซิร์ฟเวอร์ CDN การบีบอัด และการแคชช่วยลดได้

Once you know the idea, a new cloud is mostly new names. Some equivalents are close rather than exact. เมื่อเข้าใจแนวคิดแล้ว คลาวด์ใหม่ส่วนใหญ่ก็แค่ชื่อใหม่ บางบริการเทียบได้ใกล้เคียง ไม่ได้เหมือนกันทุกประการ

Terraform (or OpenTofu) works with all three, which is why many teams use it for infrastructure as code. The provider guides in this series run each cloud's own tools against local emulators, so you can practise without an account or a bill. Terraform (หรือ OpenTofu) ใช้ได้กับทั้งสามคลาวด์ หลายทีมจึงใช้มันทำ infrastructure as code คู่มือของแต่ละผู้ให้บริการในชุดนี้จะรันเครื่องมือของคลาวด์นั้นกับ emulator ในเครื่อง จึงฝึกได้โดยไม่ต้องมีบัญชีและไม่มีค่าใช้จ่าย

These are the mistakes behind most cloud incidents and surprise bills. The examples are written in the style of AWS; the same settings exist on every cloud. นี่คือข้อผิดพลาดเบื้องหลังเหตุการณ์และค่าใช้จ่ายที่ไม่คาดคิดบนคลาวด์ส่วนใหญ่ ตัวอย่างเขียนในรูปแบบของ AWS แต่การตั้งค่าแบบเดียวกันมีในทุกคลาวด์