
Đặt vấn đề
Khi triển khai hạ tầng ngân hàng trên AWS, bước đầu tiên và cực kỳ quan trọng là xác định cách tổ chức và quản lý tài khoản AWS. Bạn sẽ sử dụng một tài khoản duy nhất hay nhiều tài khoản khác nhau? Nếu chọn nhiều tài khoản, cần tổ chức theo tiêu chí nào và làm sao để quản lý hiệu quả?
Một hay nhiều tài khoản AWS?
Theo khuyến nghị từ AWS, đối với các tổ chức có quy mô lớn, việc triển khai theo mô hình Landing Zone với nhiều tài khoản AWS sẽ mang lại nhiều lợi ích:
- Tránh giới hạn dịch vụ (AWS Service Quotas): Mỗi tài khoản AWS có giới hạn tài nguyên riêng, sử dụng nhiều tài khoản giúp phân bổ tài nguyên tốt hơn.
- Tăng cường bảo mật: Nếu một tài khoản bị xâm nhập, các tài khoản khác sẽ không bị ảnh hưởng.
- Quản lý chi phí: Phân bổ chi phí theo từng tài khoản giúp dễ dàng theo dõi và tối ưu.
Với hệ thống ngân hàng, sử dụng nhiều tài khoản AWS không chỉ là một lựa chọn hợp lý mà còn là cần thiết để đảm bảo hiệu suất, bảo mật và khả năng mở rộng.
Tiêu chí tổ chức tài khoản AWS
Tiêu chí phổ biến để tạo tài khoản là dựa theo môi trường và những thành phần phổ biến trong một hệ thống phần mền.
Ví dụ khi phát triển sản phẩm thì ta có môi trường là DEV, UAT, STAGING, PROD. Đối với các môi trường như DEV, UAT, STAGING có thể gôm lại thành môi trường nonprod. Còn những thành phần phổ biến trong một hệ thống thì bao gồm Networking, Workload, Operation (CI/CD), Monitoring, Logging, Data System.

Vậy ta có thể tạo các tài khoản với tên như sau (nonprod dùng cho các môi trường không phải production):
- networking-nonprod
- workload-nonprod
- operation-nonprod
- observability-nonprod
- data-nonprod
- networking-prod
- workload-prod
- operation-prod
- observability-prod
- data-prod
Networking dùng để quản lý network ra vào, tất cả các request đi vào và ra đều phải đi qua networking account trước rồi mới đi tiếp. Mục đích là để ta truy vết được toàn bộ request đi vào ra hệ thống.
Workload account dùng để triển khai ứng dụng, database, cache.
Operation account dùng để thực thi các tác vụ liên quan tới CI/CD, tạo hạ tầng cho các tài khoản khác.
Observability account dùng để triển khai hệ thống monitoring, logging và tracing.
Data account dùng để thực thi các tác vụ về dữ liệu như thu thập, xử lý dữ liệu và hiển thị dữ liệu đẹp cho người dùng nội bộ.
Quản lý nhiều tài khoản AWS
Quản lý tài chính và tổ chức
Khi tạo nhiều tài khoản như trên thì ta quản lý như thế nào về mặt AWS Billing và truy cập. Để quản lý chi phí và tài khoản tập trung, bạn cần một tài khoản root sử dụng các dịch vụ như:
- AWS Organizations: Tổ chức và quản lý tài khoản trong một hệ thống phân cấp.
- AWS Control Tower: Tự động hóa việc thiết lập Landing Zone và áp dụng các chính sách bảo mật nhất quán.

Truy cập và phân quyền
Vấn đề tiếp theo là về việc truy cập các tài khoản khác nhau. Khi ta có nhiều tài khoản AWS như trên thì khi truy cập ta cần làm thế nào để tiện nhất? Ta không thể dùng Console thông thường rồi login và logut để truy cập từng tài khoản được.
Bên cạnh đó còn vấn đề về IAM User và Premission, nếu có một bạn cần truy cập nhiều tài khoản thì không lẻ ta phải vào từng tài khoản để tạo IAM User cho bạn?
Để dễ dàng truy cập các tài khoản trong Control Tower thì AWS hỗ trợ dịch vụ IAM Identity Center. Ta chỉ cần tạo quyền và user ở một nơi và họ có thể truy cập được các tài khoản khác nhau thông qua IAM Identity Center, hình minh họa.

Quy trình quản lý tài khoản mẫu
- Theo dõi chi phí: Kích hoạt AWS Cost Explorer và AWS Budgets để giám sát chi phí từng tài khoản.
- Tạo tài khoản root: Sử dụng AWS Organizations và Control Tower để quản lý tất cả các tài khoản.
- Phân quyền với IAM Identity Center: Tạo nhóm quyền theo vai trò (admin, developer, operator) và chỉ định user phù hợp.
Kết luận
Quản lý tài khoản AWS không chỉ là việc tạo tài khoản mà còn bao gồm cả tổ chức, bảo mật và tối ưu hóa quản lý. Mô hình nhiều tài khoản theo tiêu chí môi trường và chức năng là giải pháp hiệu quả để triển khai hạ tầng ngân hàng trên Cloud.
Trong bài tiếp theo, mình sẽ giới thiệu về cách sử dụng Operation Account để tự động hóa việc tạo hạ tầng cho các tài khoản khác.
Trích: Quân Huỳnh – Cloud Engineer, Tác giả trang devopsvn.tech

