Hướng dẫn triển khai ứng dụng Web lên AWS EC2 từ A đến Z

Chạy được ứng dụng trên một instance EC2 mới là nửa đầu chặng đường. Để phục vụ người dùng thật, bạn cần thêm địa chỉ cố định và tên miền, HTTPS, cơ chế tự khởi động lại, quyền truy cập an toàn tới các dịch vụ AWS khác, giám sát, sao lưu và một kế hoạch mở rộng. Bài này đi qua toàn bộ những bước đó theo thứ tự hợp lý, giả định bạn đã có một instance đang chạy ứng dụng phía sau Nginx.

Nếu bạn chưa làm đến bước đó, hãy bắt đầu với hướng dẫn tạo instance và chạy ứng dụng đầu tiên trên EC2.

A. Thiết kế mạng trước khi mở rộng

Instance thử nghiệm thường nằm trong VPC mặc định với subnet công khai. Với production, nên có VPC riêng gồm subnet công khai cho cân bằng tải và subnet riêng tư cho máy chủ ứng dụng, cơ sở dữ liệu. Máy chủ trong subnet riêng tư không có IP công khai, chỉ nhận lưu lượng từ cân bằng tải, giảm đáng kể bề mặt tấn công. Nếu máy chủ cần tải gói cập nhật từ Internet, dùng NAT Gateway hoặc VPC endpoint cho dịch vụ AWS.

Với ứng dụng một máy chủ đơn giản, bạn có thể tạm giữ instance ở subnet công khai, nhưng hãy siết Security Group: chỉ mở 80 và 443 cho mọi nơi, SSH chỉ cho IP quản trị hoặc tắt hẳn và dùng Session Manager.

B. Địa chỉ cố định và tên miền

IP công khai mặc định của instance thay đổi mỗi khi stop/start. Có hai cách giữ địa chỉ ổn định:

• Elastic IP: địa chỉ tĩnh gắn vào instance. Phù hợp kiến trúc một máy chủ. Lưu ý AWS tính phí địa chỉ IPv4 công khai, kể cả Elastic IP.
• Application Load Balancer (ALB): cung cấp tên DNS ổn định, phân phối lưu lượng tới một hoặc nhiều instance. Đây là lựa chọn cho mọi hệ thống định mở rộng.

Với tên miền, bạn có thể dùng Amazon Route 53 hoặc nhà cung cấp DNS hiện có. Trỏ bản ghi A tới Elastic IP, hoặc bản ghi alias/CNAME tới tên DNS của ALB.

C. HTTPS: bắt buộc, không phải tùy chọn

Trình duyệt hiện đại đánh dấu trang HTTP là không an toàn, và mọi dữ liệu đăng nhập phải đi qua kết nối mã hóa. Hai hướng phổ biến:

Sau khi có HTTPS, cấu hình chuyển hướng toàn bộ HTTP sang HTTPS và cân nhắc bật HSTS.

D. Chạy ứng dụng như một dịch vụ

Ứng dụng phải tự khởi động khi máy chủ khởi động lại và tự chạy lại khi bị lỗi. Trên Linux hiện đại, cách chuẩn là tạo một unit systemd:

• Khai báo lệnh khởi động, thư mục làm việc, người dùng chạy tiến trình (không dùng root).
• Đặt Restart=on-failure để tự khởi động lại khi tiến trình thoát bất thường.
• Nạp biến môi trường từ file có quyền đọc hạn chế.
• Bật dịch vụ với systemctl enable để chạy khi khởi động máy.

Với Node.js, PM2 là lựa chọn quen thuộc khác, hỗ trợ chế độ cluster và tự tạo script khởi động. Nếu ứng dụng đã được đóng gói container, chạy bằng Docker với chính sách restart cũng là một hướng gọn gàng.

E. Quyền truy cập: dùng IAM Role, không dùng khóa

Ứng dụng thường cần đọc ghi S3, gửi email qua SES hay đọc bí mật từ Secrets Manager. Sai lầm phổ biến là tạo access key rồi dán vào file cấu hình. Thay vào đó, gắn một IAM Role (instance profile) vào instance; SDK của AWS tự lấy thông tin xác thực tạm thời từ dịch vụ metadata. Chỉ cấp đúng quyền cần thiết cho đúng tài nguyên.

Đồng thời, yêu cầu IMDSv2 cho dịch vụ metadata của instance. Phiên bản này dùng token phiên, giúp giảm rủi ro bị lợi dụng qua lỗ hổng SSRF trong ứng dụng.

F. Cơ sở dữ liệu: tách khỏi máy chủ ứng dụng

Cài MySQL hay PostgreSQL ngay trên instance ứng dụng thì rẻ, nhưng bạn tự lo sao lưu, cập nhật, và máy hỏng là mất cả hai. Amazon RDS hoặc Aurora cung cấp sao lưu tự động, khôi phục theo thời điểm, tùy chọn Multi-AZ. Đặt cơ sở dữ liệu trong subnet riêng tư, Security Group chỉ cho phép kết nối từ Security Group của máy chủ ứng dụng.

G. Giám sát và nhật ký

• CloudWatch metrics: CPU, mạng, trạng thái kiểm tra của instance có sẵn. Muốn có RAM và dung lượng đĩa, cài CloudWatch Agent.
• CloudWatch Logs: đẩy log ứng dụng và log Nginx lên để tìm kiếm tập trung, không phụ thuộc vào việc SSH vào máy.
• Cảnh báo: tạo alarm cho CPU cao kéo dài, ổ đĩa sắp đầy, lỗi 5xx từ ALB, gửi qua SNS tới email hoặc kênh chat.
• Kiểm tra từ bên ngoài: một dịch vụ kiểm tra uptime gọi trang chủ định kỳ giúp phát hiện sự cố mà người dùng thấy.

H. Sao lưu

Dùng AWS Backup hoặc Data Lifecycle Manager để tạo snapshot EBS tự động theo lịch, với thời gian lưu giữ rõ ràng. Lý tưởng nhất là máy chủ ứng dụng không giữ dữ liệu quan trọng nào: file người dùng tải lên lưu trên S3, dữ liệu nằm trong RDS. Khi đó máy chủ có thể bị thay thế bất kỳ lúc nào. Với kế hoạch phục hồi đầy đủ hơn, xem bài Disaster Recovery trên cloud.

I. Cập nhật và deploy

Đăng nhập SSH, git pull và khởi động lại dịch vụ là cách deploy của giai đoạn đầu. Khi ổn định, hãy chuyển sang quy trình lặp lại được:

1. Pipeline CI build và kiểm thử mã.
2. Artifact (gói hoặc image) được lưu ở S3 hoặc ECR.
3. Bước deploy dùng AWS CodeDeploy, Systems Manager Run Command hoặc thay instance mới từ AMI mới.
4. Kiểm tra sức khỏe sau deploy, rollback nếu thất bại.

Hệ điều hành cũng cần cập nhật bảo mật định kỳ; Systems Manager Patch Manager có thể tự động hóa việc này.

J. Mở rộng khi lưu lượng tăng

Khi một máy không đủ, kiến trúc điển hình là: ALB phía trước, Auto Scaling Group quản lý nhiều instance tạo từ một Launch Template, tự thêm bớt máy theo tải. Điều kiện tiên quyết là ứng dụng không lưu trạng thái trên máy: phiên đăng nhập lưu ở Redis hoặc cơ sở dữ liệu, file lưu ở S3. Trải instance qua ít nhất hai Availability Zone để chịu được sự cố một vùng sẵn sàng.

K. Kiểm soát chi phí

Khi hệ thống đã chạy ổn định, xem xét Savings Plans hoặc Reserved Instances cho tải nền, chọn đúng cỡ instance dựa trên số liệu giám sát thực, và dọn dẹp snapshot, Elastic IP, ổ đĩa không dùng. Bài tối ưu chi phí đám mây trình bày chi tiết hơn.

Checklist trước ngày ra mắt

• Tên miền trỏ đúng, HTTPS hoạt động, HTTP tự chuyển sang HTTPS.
• SSH không mở công khai; MFA bật cho mọi tài khoản quản trị AWS.
• Ứng dụng chạy dưới systemd hoặc trình quản lý tiến trình, đã thử khởi động lại máy.
• Instance dùng IAM Role, không có access key trong mã.
• Sao lưu tự động đã bật và đã khôi phục thử ít nhất một lần.
• Có alarm cho các chỉ số chính và người nhận cảnh báo.
• Có budget cảnh báo chi phí.