Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được giao nhiệm vụ đưa cả một công ty lên cloud. Ngày đầu tiên, mọi thứ trông rất đơn giản: mở một tài khoản AWS (hoặc GCP, Azure), tạo vài con máy ảo, deploy ứng dụng, xong. Nhưng sáu tháng sau, khi công ty có 15 lập trình viên, 4 nhóm sản phẩm, và bắt đầu có khách hàng ngân hàng đòi hỏi kiểm toán bảo mật, bạn nhìn lại và thấy một mớ hỗn độn: tài nguyên của môi trường test nằm chung với production, không ai biết ai đang trả tiền cho cái gì, quyền IAM cấp lung tung theo kiểu "cứ Admin cho nhanh", và log thì mỗi nơi một kiểu. Lúc này việc "dọn nhà" tốn gấp mười lần so với nếu bạn làm đúng ngay từ đầu.
Đó chính là lý do Landing Zone ra đời. Nói ngắn gọn, Landing Zone là nền móng được cấu hình sẵn (pre-configured baseline) cho toàn bộ môi trường cloud của tổ chức — bao gồm cấu trúc multi-account, mạng, IAM, logging tập trung và các "hàng rào an toàn" (guardrails) — được dựng lên trước khi bạn migrate hay xây dựng bất kỳ workload thực sự nào.
Nếu bạn từng xây nhà, Landing Zone giống như phần móng, hệ thống điện nước âm tường, và giấy phép xây dựng. Không ai đến ở trong một cái móng, nhưng nếu làm ẩu phần này thì cả căn nhà phía trên sẽ nứt. Bài học hôm nay sẽ giúp bạn hiểu bản chất Landing Zone, chiến lược phân chia account, và cách dựng nó một cách bài bản.
Khái niệm cốt lõi
Landing Zone là gì và giải quyết vấn đề gì
Landing Zone là một tập hợp các quyết định kiến trúc và cấu hình được chuẩn hóa, tự động hóa, để mỗi khi một nhóm mới cần môi trường cloud, họ nhận được một "khu đất đã san phẳng, có sẵn điện nước" thay vì phải tự dựng lại từ con số không. Nó trả lời bốn câu hỏi lớn:
- Chúng ta chia tài nguyên vào các account như thế nào? (Account Strategy)
- Mạng được thiết kế ra sao để các phần nói chuyện an toàn với nhau? (Networking baseline)
- Ai được làm gì? (IAM và guardrails)
- Chuyện gì đang xảy ra và ai chịu trách nhiệm? (Logging, audit, cost)
Vì sao phải multi-account thay vì một account khổng lồ
Sai lầm phổ biến nhất của các đội mới lên cloud là nhét mọi thứ vào một account duy nhất, rồi cố gắng phân tách bằng tag hoặc naming convention. Vấn đề là:
- Bán kính vụ nổ (blast radius): nếu một credential bị lộ, kẻ tấn công truy cập được toàn bộ mọi thứ, từ dev đến production.
- Không có ranh giới hạn mức (quota): một team lỡ tay tạo 500 máy ảo cho test sẽ ăn hết quota của production.
- Khó phân tách chi phí: không thể trả lời chính xác "team Payments tháng này tốn bao nhiêu".
- Khó áp chính sách khác nhau: môi trường xử lý dữ liệu thẻ ngân hàng cần chính sách chặt hơn môi trường blog nội bộ.
Account Strategy — chia account theo trục nào
Có ba trục thường dùng để chia account, và bạn thường kết hợp cả ba:
- Theo môi trường (environment): Dev, Staging, Production riêng biệt. Đây là ranh giới quan trọng nhất — production luôn phải cô lập.
- Theo nhóm/sản phẩm (business unit / team): team Payments, team Logistics, team Data mỗi nhóm có account riêng để tự chủ và tính chi phí độc lập.
- Theo chức năng nền tảng (foundational): các account dùng chung cho cả tổ chức, không chứa workload:
Guardrails — hàng rào an toàn tự động
Guardrail là các quy tắc được áp ở cấp tổ chức, không thể bị team con vượt qua. Có hai loại:
- Preventive (ngăn chặn): ví dụ Service Control Policy (SCP) trên AWS chặn không cho ai tạo tài nguyên ở region không được phép, hay cấm tắt logging. Dù bạn là Admin của account con, SCP vẫn chặn.
- Detective (phát hiện): ví dụ AWS Config / GCP Security Command Center liên tục quét và cảnh báo khi có cấu hình sai lệch (như một S3 bucket bị để public).
Công cụ dựng sẵn
Bạn hiếm khi phải dựng Landing Zone thủ công. Các nhà cung cấp có bộ khung sẵn: AWS Control Tower (hoặc Landing Zone Accelerator), Google Cloud Foundation Toolkit, và Azure Landing Zones (Cloud Adoption Framework). Chúng dựng cấu trúc account, guardrails, và logging chỉ với vài cấu hình.
Tình huống thực tế
Tình huống 1 — Fintech Đông Nam Á cứu vãn sau kiểm toán
Một startup fintech ở TP.HCM (tạm gọi là PayNimo) phát triển rất nhanh, từ 5 lên 40 kỹ sư trong một năm. Toàn bộ chạy trên một AWS account duy nhất. Khi họ gọi vốn Series A và một ngân hàng đối tác yêu cầu kiểm toán bảo mật (theo hướng ISO 27001), kiểm toán viên phát hiện: môi trường sandbox của intern có thể truy cập database production chứa dữ liệu giao dịch thật, vì tất cả nằm chung một account và IAM cấp quyền quá rộng.
Đội DevOps buộc phải dựng lại Landing Zone bằng AWS Control Tower: tách thành Management account, Log Archive, Security, rồi các account Production / Staging / Sandbox riêng. Họ áp SCP cấm mọi account non-production truy cập vào VPC của production, và ép mọi log CloudTrail đổ về Log Archive account mà không ai xóa được.
Bài học: việc migrate 40 kỹ sư và toàn bộ workload sang cấu trúc mới mất gần 3 tháng và làm chậm lộ trình sản phẩm. Nếu PayNimo dựng Landing Zone ngay từ khi có 5 người, việc này chỉ tốn vài ngày. Nền móng luôn rẻ hơn khi làm sớm.
Tình huống 2 — Doanh nghiệp bán lẻ chia account theo chi phí
Một chuỗi bán lẻ (giả định tên MegaMart) có ba mảng: thương mại điện tử, kho vận (logistics), và ứng dụng khách hàng thân thiết. Ban đầu mọi thứ chung một GCP Project, và cuối mỗi tháng bộ phận tài chính không thể trả lời câu hỏi đơn giản của CFO: "Mảng logistics tốn bao nhiêu tiền cloud?"
Họ tái cấu trúc theo mô hình Organization → Folders (theo mảng) → Projects (theo môi trường). Mỗi mảng có folder riêng, mỗi folder có project Prod/Staging/Dev. Billing được gắn nhãn theo folder, guardrail (Organization Policy) ép mọi project chỉ được tạo tài nguyên ở region asia-southeast1 (Singapore) để tối ưu độ trễ và tuân thủ.
Bài học: sau khi tái cấu trúc, báo cáo chi phí theo mảng trở nên tự động và chính xác. CFO thấy mảng loyalty tốn 40% ngân sách cloud dù chỉ tạo 12% doanh thu, dẫn tới quyết định tối ưu kịp thời. Account Strategy không chỉ là chuyện bảo mật — nó còn là công cụ ra quyết định kinh doanh.
Tình huống 3 — Team nhỏ đừng "over-engineer"
Một studio game 6 người ở Đà Nẵng đọc tài liệu về Landing Zone rồi hào hứng dựng 12 account riêng biệt với đủ SCP phức tạp. Kết quả: mỗi lần muốn deploy một thay đổi nhỏ, họ phải cấu hình cross-account access rối rắm, mất thời gian debug quyền IAM nhiều hơn là code game.
Họ đơn giản hóa lại còn 3 account: một Management, một Production, một Non-production (gộp dev + staging). Vẫn tách được production, vẫn có log tập trung, nhưng không bị chôn vùi trong độ phức tạp.
Bài học: Landing Zone nên cân xứng với quy mô. Nguyên tắc "tách production ra riêng" là bắt buộc với mọi quy mô, nhưng số lượng account nên tăng dần theo nhu cầu, không phải dựng sẵn cho một công ty 500 người khi bạn mới có 6 người.
Hướng dẫn từng bước
Đây là quy trình dựng một Landing Zone cơ bản (lấy AWS làm ví dụ, GCP/Azure tương tự về tư duy):
- Xác định mô hình account. Vẽ ra giấy: bạn cần những account nền tảng nào (Management, Log Archive, Security) và những account workload nào (theo môi trường và/hoặc theo team). Với đội nhỏ, bắt đầu bằng 3–4 account.
- Thiết lập Organization. Bật AWS Organizations trên account gốc (đây sẽ là Management account). Đừng deploy workload nào ở account này — nó chỉ để quản trị và billing.
- Dùng công cụ dựng sẵn. Kích hoạt AWS Control Tower. Nó sẽ tự tạo Log Archive account, Audit account, cấu trúc Organizational Unit (OU), và một bộ guardrail mặc định.
- Thiết kế Organizational Units. Nhóm các account vào OU: một OU cho các account nền tảng (Foundational/Security), một OU cho Production, một OU cho Non-production. Guardrail được áp ở cấp OU nên rất tiện.
- Áp guardrails. Bật các SCP quan trọng: chặn region không dùng, cấm tắt CloudTrail, cấm tạo IAM user với access key vĩnh viễn (khuyến khích dùng SSO/role tạm thời).
- Tập trung logging. Đảm bảo CloudTrail của mọi account đổ về Log Archive account. Áp chính sách chỉ-ghi-thêm để không ai xóa được vết audit.
- Thiết lập truy cập tập trung (SSO). Cấu hình IAM Identity Center (SSO) để nhân viên đăng nhập một lần và nhận role tạm thời vào từng account, thay vì tạo IAM user riêng ở mỗi account.
- Dựng networking baseline. Quyết định dải IP (CIDR) cho từng môi trường ngay từ đầu để tránh trùng lặp khi cần kết nối các VPC sau này. (Chi tiết về VPC Peering, Transit Gateway sẽ học ở bài riêng.)
- Tự động hóa bằng IaC. Ghi lại toàn bộ cấu hình bằng Infrastructure as Code (Terraform/CloudFormation) để có thể tái tạo và version control. Việc tạo account mới nên là một pull request, không phải click chuột thủ công.
- Viết tài liệu quy trình cấp account mới. Khi một team mới cần môi trường, họ phải biết chính xác cần làm gì và ai duyệt.
Lỗi thường gặp & mẹo
- Deploy workload vào Management account. Đây là lỗi kinh điển và nguy hiểm. Management account có quyền lực tối cao; nếu nó bị xâm nhập, toàn bộ tổ chức sụp đổ. Hãy giữ nó "sạch".
- Tạo IAM user với access key ở mỗi account. Cách này khó quản lý và dễ rò rỉ. Mẹo: dùng SSO + role tạm thời để credential luôn ngắn hạn.
- Không lập kế hoạch CIDR từ đầu. Nếu Dev VPC và Prod VPC vô tình trùng dải IP, bạn sẽ không thể peering chúng sau này. Hãy phân bổ dải IP không trùng ngay từ ngày đầu.
- Over-engineer với đội nhỏ. Như tình huống 3, đừng dựng 12 account khi bạn có 6 người. Bắt đầu tối giản, mở rộng theo nhu cầu.
- Quên guardrail phát hiện. Nhiều đội chỉ lo preventive mà quên detective. Hãy bật cả cảnh báo cấu hình sai (như bucket public) để bắt lỗi phát sinh trong quá trình vận hành.
- Mẹo tính chi phí: áp chính sách bắt buộc gắn tag (cost allocation tag) như
team,env,projectngay trong guardrail. Không tag thì không được tạo tài nguyên. Điều này giúp báo cáo chi phí chính xác về sau.
- Mẹo migrate: nếu bạn đã lỡ có một account khổng lồ, đừng cố dời tất cả cùng lúc. Dựng Landing Zone mới song song, rồi migrate từng workload một, bắt đầu từ những cái ít rủi ro nhất.
Bài tập thực hành
- Thiết kế trên giấy: Cho một công ty startup edtech Việt Nam có 20 kỹ sư, 3 nhóm sản phẩm (web học viên, app giáo viên, hệ thống nội bộ), và một khách hàng doanh nghiệp yêu cầu tuân thủ dữ liệu. Hãy vẽ sơ đồ account: liệt kê các account nền tảng và account workload, giải thích lý do chia như vậy.
- Viết guardrail: Liệt kê 5 SCP (hoặc Organization Policy) mà bạn sẽ áp ngay cho công ty ở bài 1, và giải thích mỗi cái ngăn chặn rủi ro gì.
- Phân tích blast radius: Với thiết kế của bạn, giả sử credential của một lập trình viên trong nhóm "web học viên" bị lộ. Kẻ tấn công có thể chạm tới những tài nguyên nào, và những tài nguyên nào được bảo vệ nhờ cấu trúc multi-account? So sánh với trường hợp mọi thứ nằm chung một account.
- (Nâng cao) Thực hành trên free tier: Nếu có tài khoản AWS, bật AWS Organizations, tạo một account con sandbox, và thử áp một SCP đơn giản chặn tạo tài nguyên ngoài region
ap-southeast-1. Quan sát điều gì xảy ra khi bạn cố tạo tài nguyên ở region khác.
Tóm tắt
Landing Zone là nền móng được cấu hình sẵn cho toàn bộ môi trường cloud của tổ chức — dựng trước khi migrate workload, chứ không phải chữa cháy sau. Trái tim của nó là Account Strategy: tách tài nguyên vào nhiều account theo môi trường, theo nhóm, và theo chức năng nền tảng, để giới hạn bán kính vụ nổ, phân tách chi phí, và áp chính sách khác nhau cho từng phần.
Bốn trụ cột cần nhớ: multi-account (ranh giới an toàn), networking baseline (kế hoạch IP không trùng), IAM + guardrails (SSO, role tạm thời, SCP ngăn chặn và cảnh báo phát hiện), và logging tập trung (Log Archive không thể xóa). Dùng công cụ dựng sẵn như AWS Control Tower, GCP Foundation Toolkit hay Azure Landing Zones để tiết kiệm công sức, và tự động hóa mọi thứ bằng IaC.
Nguyên tắc vàng: tách production là bắt buộc với mọi quy mô, nhưng độ phức tạp phải cân xứng với đội của bạn. Bắt đầu tối giản, mở rộng theo nhu cầu, và luôn nhớ rằng nền móng làm đúng từ sớm sẽ rẻ hơn gấp nhiều lần so với việc dọn dẹp một mớ hỗn độn sau này.