Bài toán kiến trúc
Bạn được giao thiết kế một website bán vé. Lượng truy cập bình thường thấp, nhưng khi mở bán một chương trình nổi tiếng, traffic tăng đột biến. Người dùng phải đăng nhập, xem danh sách vé, thanh toán và nhận email xác nhận. Hệ thống cần bảo vệ dữ liệu cá nhân, không để một máy chủ lỗi làm cả website dừng, và không biến một đợt cao điểm thành hóa đơn bất ngờ.
Một Solutions Architect không bắt đầu bằng câu hỏi “dùng dịch vụ AWS nào?”. Họ bắt đầu bằng yêu cầu:
- Security: ai được truy cập dữ liệu và bằng cách nào?
- Reliability: điều gì xảy ra khi instance, AZ hoặc database gặp lỗi?
- Performance: latency và throughput cần đạt bao nhiêu?
- Cost: tải ổn định hay biến động, thành phần nào cần commitment?
- Operational Excellence: làm sao triển khai, quan sát và khôi phục lặp lại được?
1. Mô hình tư duy của Solutions Architect
Tách yêu cầu thành functional và non-functional
Functional requirement mô tả hệ thống phải làm gì: đăng nhập, giữ chỗ, thanh toán, gửi email. Non-functional requirement mô tả hệ thống phải làm tốt đến mức nào: 99.9% availability, phản hồi dưới 200 ms, mã hóa dữ liệu, khôi phục trong 30 phút.
Hai hệ thống có cùng chức năng vẫn có thể cần kiến trúc khác nhau nếu một hệ thống yêu cầu RTO/RPO thấp hơn hoặc chịu tải lớn hơn.
Tư duy “managed service trước, nhưng có lý do”
AWS cung cấp nhiều mức abstraction. EC2 cho quyền kiểm soát máy ảo; RDS giảm công việc vận hành database; S3 phù hợp object; Lambda chạy code theo event. Managed service thường giảm operational overhead, nhưng không tự giải quyết schema, IAM, network, dữ liệu hay chi phí.
Đừng chọn managed service chỉ vì nó mới hơn. Hãy hỏi workload cần quyền kiểm soát nào, access pattern ra sao và failure mode nào phải xử lý.
2. Kiến trúc tham chiếu cho website nhiều tầng
Một hướng thiết kế cơ bản:
User
|
Route 53 / CloudFront
|
Application Load Balancer (public subnets, nhiều AZ)
|
Application tier (private subnets, Auto Scaling Group)
|
RDS Multi-AZ / DynamoDB S3 (object, upload, backup)
Mỗi thành phần có một vai trò khác nhau:
| Thành phần | Câu hỏi nó giải quyết |
|---|---|
| Route 53 | Người dùng tìm đúng endpoint bằng DNS thế nào? |
| CloudFront | Nội dung tĩnh có thể cache gần người dùng không? |
| ALB | Traffic đi tới instance khỏe nào? |
| ASG | Khi tải tăng hoặc instance lỗi, capacity thay đổi ra sao? |
| RDS Multi-AZ | Database failover trong một Region thế nào? |
| S3 | Object upload được lưu bền vững và phân quyền ra sao? |
Đây chưa phải kiến trúc hoàn chỉnh. Ta vẫn cần quyết định session management, transaction/locking khi giữ vé, encryption, backup, logging, deployment và giới hạn chi phí.
3. Shared Responsibility trong kiến trúc
AWS bảo vệ security of the cloud: data center, phần cứng, mạng vật lý và lớp ảo hóa. Bạn vẫn chịu security in the cloud: IAM policy, security group, dữ liệu, cấu hình bucket, secret, guest OS trên EC2 và cách ứng dụng xử lý dữ liệu.
Ví dụ, RDS giúp AWS quản lý nhiều phần patching và vận hành database engine, nhưng bạn vẫn phải:
- Giới hạn quyền ứng dụng bằng IAM role.
- Đặt database trong network boundary phù hợp.
- Chọn backup/retention theo RPO.
- Bảo vệ dữ liệu và kiểm tra log truy cập.
Managed không có nghĩa là “AWS chịu trách nhiệm mọi thứ”.
4. Thực hành: đọc kiến trúc trước khi triển khai
Không cần tạo tài nguyên có phí cho bài đầu tiên. Hãy vẽ kiến trúc ticketing ở trên và trả lời:
- Vì sao database không nên nằm trong public subnet?
- Vì sao ALB và application tier cần trải trên nhiều AZ?
- Vì sao file upload phù hợp S3 hơn EBS của một EC2 cụ thể?
- Nếu chỉ cần đọc dữ liệu, lựa chọn nào khác với RDS Multi-AZ có thể phù hợp?
- Khi traffic giảm, thành phần nào có thể scale in và thành phần nào cần giữ dữ liệu?
Sau đó kiểm tra context AWS CLI mà không tạo resource:
aws sts get-caller-identity --profile study
aws configure list --profile study
Nếu ARN là Root user, dừng lab và đổi sang IAM Identity Center/role hoặc identity tối thiểu. Một kiến trúc tốt bắt đầu từ identity đúng.
5. Các bẫy thường gặp trong SAA-C03
- Multi-AZ không phải backup: nó tăng availability/failover; backup phục vụ khôi phục dữ liệu.
- Read Replica không phải Multi-AZ: replica chủ yếu scale đọc; Multi-AZ chủ yếu phục vụ availability.
- Public subnet không đồng nghĩa public resource: route, public IP và security group đều ảnh hưởng khả năng truy cập.
- Serverless không có nghĩa không cần security: Lambda vẫn cần execution role, timeout, logging và kiểm soát input.
- Lowest cost không luôn là best architecture: phải đáp ứng requirement về reliability, performance và operations trước.
6. Checkpoint cuối bài
Bạn sẵn sàng sang Ngày 2 khi có thể nhìn một yêu cầu và viết được: functional requirements, non-functional requirements, failure modes, dữ liệu cần bảo vệ và các trade-off. Hãy giữ bản vẽ này; các bài VPC, EC2, RDS, HA và DR sau sẽ lần lượt nâng cấp nó thay vì học dịch vụ rời rạc.