EC2 Scenario

Bạn tạo EC2 instance loại Nitro-based và cần biết thông tin instance (region, AZ, IAM role credentials) mà không cần gọi API có auth. Làm sao?

Dùng Instance Metadata Service (IMDS) qua địa chỉ 169.254.169.254. Nên dùng IMDSv2 (session-oriented, cần PUT token trước) để chống tấn công SSRF, thay vì IMDSv1.

Khách hàng phàn nàn ứng dụng chạy trên EC2 bị crash ngầm nhưng AWS Console vẫn hiện instance "running". Cách xử lý?

Kiểm tra Status Checks: System Status Check (lỗi hạ tầng AWS) và Instance Status Check (lỗi OS/config). Có thể cấu hình Auto Recovery (CloudWatch Alarm + StatusCheckFailed_System) để tự động recover instance sang host mới, giữ nguyên metadata, private IP, Elastic IP.

Bạn set Termination Protection nhưng instance vẫn bị "Stop" khi bấm nhầm nút Stop. Termination Protection có ngăn được không?

Không. Termination Protection chỉ chặn hành động Terminate, không chặn Stop hay Shutdown từ OS (trừ khi cấu hình thêm DisableApiStop hoặc Instance Shutdown Behavior).

Ứng dụng cần scale để chịu tải tăng đột biến vào giờ cao điểm, sau đó giảm lại. Nên dùng Vertical hay Horizontal Scaling?

Horizontal Scaling (thêm/bớt số lượng instance qua Auto Scaling Group) — phù hợp cho tải biến động, có thể tự động và không downtime. Vertical Scaling (đổi instance type lớn hơn) thường cần restart/downtime.

Bạn launch instance từ Instance Store-backed AMI, sau đó Stop instance. Dữ liệu trên ổ đĩa có mất không?

Có, vì Instance Store là ephemeral storage — dữ liệu mất khi Stop, Terminate, hoặc phần cứng host bị lỗi. Chỉ tồn tại được khi Reboot.

Bạn cần workload có IOPS cực cao, latency thấp, chấp nhận rủi ro mất dữ liệu khi instance stop. Chọn loại volume nào?

Instance Store Volume (NVMe SSD gắn trực tiếp vào host) — nhanh hơn EBS nhưng dữ liệu không persistent.

Ứng dụng database cần disk IOPS ổn định trên 16,000 và có thể scale riêng IOPS mà không cần tăng dung lượng. Loại EBS nào phù hợp?

EBS Provisioned IOPS SSD (io1/io2) — cho phép chọn IOPS độc lập với size, phù hợp cho database workload đòi hỏi hiệu năng cao và ổn định.

Bạn cần lưu trữ log file, ít truy cập ngẫu nhiên, ưu tiên chi phí thấp. Loại EBS nào phù hợp?

EBS HDD-based (st1 - Throughput Optimized hoặc sc1 - Cold HDD) — rẻ hơn SSD, tối ưu cho truy cập tuần tự (sequential), không phù hợp cho boot volume.

Bạn muốn di chuyển EBS Volume sang AZ khác. Có thể attach trực tiếp không?

Không. EBS Volume chỉ hoạt động trong cùng AZ. Phải tạo Snapshot rồi restore thành volume mới ở AZ đích.

Bạn cần backup EBS Volume nhưng muốn Volume mới sẵn sàng sử dụng ngay lập tức thay vì chờ load dữ liệu từ S3. Giải pháp?

Dùng Fast Snapshot Restore (FSR) khi tạo Snapshot, giúp Volume restore từ Snapshot có full performance ngay từ đầu, tránh "lazy loading" gây latency ban đầu.

Công ty yêu cầu tất cả EBS Volume phải được mã hóa nhưng instance hiện tại dùng Volume chưa encrypt. Làm sao encrypt volume đang chạy?

Không thể encrypt trực tiếp volume đang tồn tại. Cần: Snapshot volume → Copy snapshot với encryption enabled → Tạo volume mới từ snapshot đã encrypt → Attach vào instance.

Bạn snapshot 1 EBS Volume đã encrypted rồi share snapshot đó cho account khác. Account kia có xem/dùng được ngay không?

Không. Snapshot encrypted dùng KMS Key riêng — phải share cả KMS Key (qua key policy) cho account đích thì họ mới decrypt và tạo volume được.

Bạn launch EC2 bằng public AMI nhưng muốn custom OS + software riêng để launch hàng loạt instance giống hệt nhau. Nên làm gì?

Tạo Custom AMI: launch 1 instance, cài đặt/cấu hình xong, tạo Image (AMI) từ instance đó, sau đó dùng AMI này để launch các instance khác — đảm bảo đồng nhất và giảm thời gian config.

Doanh nghiệp có workload chạy ổn định 24/7 trong 1 năm, muốn tiết kiệm chi phí tối đa. Nên chọn Purchase Option nào?

Reserved Instance (Standard, 1 hoặc 3 năm, All Upfront) — tiết kiệm chi phí nhiều nhất cho tải ổn định, dự đoán được.

Ứng dụng có thể chịu được gián đoạn (interrupt) và cần chi phí thấp nhất, ví dụ batch processing hoặc big data analysis. Nên chọn loại instance pricing nào?

Spot Instance — rẻ nhất (giảm tới 90%) nhưng AWS có thể thu hồi instance bất cứ lúc nào khi cần capacity, chỉ phù hợp cho tải chịu được gián đoạn.

Công ty cần đảm bảo instance luôn chạy trên phần cứng vật lý riêng, không share tenant với khách hàng khác (yêu cầu compliance). Chọn tenancy nào?

Dedicated Host hoặc Dedicated Instance. Dedicated Host cho phép kiểm soát vị trí physical server (hữu ích khi cần license theo socket/core/VM), còn Dedicated Instance chỉ đảm bảo không share hardware nhưng không kiểm soát được host cụ thể.

EC2 instance cần nhiều network interface để tách traffic quản lý và traffic ứng dụng, hoặc để làm failover. Giải pháp?

Gắn thêm Elastic Network Interface (ENI) — mỗi ENI có private IP, MAC address riêng, có thể attach/detach độc lập và di chuyển sang instance khác trong cùng AZ khi cần failover.

Bạn cần Public DNS/IP cố định cho instance dù bị stop/start lại (IP public mặc định của EC2 thay đổi mỗi lần start). Giải pháp?

Dùng Elastic IP (địa chỉ IP tĩnh gắn với account, có thể remap giữa các instance) thay vì Public IP tự động cấp.

Bạn launch 1 EC2 instance ở AZ us-east-1a, sau đó Stop rồi Start lại. Instance có bị chuyển sang AZ khác không? Private IP và Public IP có giữ nguyên không?

Instance không đổi AZ khi Stop/Start (chỉ đổi khi bạn tạo mới từ Snapshot ở AZ khác). Private IP giữ nguyên, nhưng Public IP tự động sẽ đổi (trừ khi dùng Elastic IP). Volume gốc (root EBS) và data vẫn còn vì đây là Stop chứ không phải Terminate.

EBS Volume hoạt động như thế nào ở tầng hạ tầng — vì sao nó tồn tại độc lập với vòng đời của EC2 instance?

EBS là Network-Attached Storage: dữ liệu được replicate tự động trong cùng AZ (không phải trên chính host của instance), rồi kết nối tới instance qua network. Vì vậy dù Terminate instance (nếu volume không set Delete on Termination), EBS Volume vẫn tồn tại độc lập và có thể attach lại instance khác.

Bạn attach 1 EBS Volume vào EC2 instance ở AZ A, sau đó launch thêm 1 instance ở AZ B và muốn attach chung volume đó vào cả 2 để share dữ liệu real-time. Có làm được không?

Không. EBS Volume chỉ attach được vào 1 instance tại 1 thời điểm (trừ io1/io2 hỗ trợ Multi-Attach nhưng vẫn giới hạn cùng AZ) và không thể attach cross-AZ. Nếu cần share storage cho nhiều instance ở nhiều AZ, nên dùng EFS hoặc FSx.

Bạn cần biết Private IP, Public IP và DNS hostname của EC2 instance thay đổi ra sao qua các lần Stop/Start, và vì sao đôi khi app bị lỗi kết nối sau khi restart instance?

Mỗi lần Start lại instance, AWS cấp Public IP và Public DNS mới (trừ khi dùng Elastic IP), trong khi Private IP và Private DNS giữ nguyên trong vòng đời instance (trừ khi Terminate). Nếu ứng dụng hard-code Public IP cũ, sẽ mất kết nối sau khi restart — nên dùng DNS Name hoặc Elastic IP để tránh vấn đề này.

Bạn cài WordPress thủ công trên EC2, sau đó muốn nhân bản server này để deploy thêm nhiều môi trường dev/test giống hệt. Quy trình chuẩn là gì?

Sau khi cài đặt và cấu hình WordPress hoàn chỉnh trên instance, tạo Custom AMI từ instance đó (Create Image). AMI này chứa toàn bộ OS, software, config đã cài, dùng để launch nhanh các instance mới giống hệt mà không cần cài lại thủ công.

Bạn tạo AMI từ 1 instance ở region ap-southeast-1 nhưng cần launch instance ở region us-east-1 bằng chính AMI này. Làm sao?

AMI có tính chất region-specific (không tự động khả dụng ở region khác). Cần thực hiện Copy AMI sang region đích (Copy Image action), việc này sẽ copy luôn snapshot liên quan sang region đó, sau đó mới launch instance từ AMI đã copy.

Bạn muốn share AMI cho đối tác nhưng không muốn họ thấy hay dùng lại được AMI này cho mục đích khác ngoài thỏa thuận, đồng thời muốn giới hạn accounts được share cụ thể (không public). Nên làm gì?

Chia sẻ AMI ở chế độ Private, share với Specific AWS Account ID (không chọn Public). Nếu AMI dùng Encrypted Snapshot, còn phải share thêm quyền dùng KMS Key cho account đó. Lưu ý: account được share chỉ có thể launch instance từ AMI, không sở hữu được AMI gốc.

Doanh nghiệp có traffic tăng đột biến trong 1-2 tháng do sự kiện đặc biệt, sau đó trở lại bình thường. Loại Purchase Option nào phù hợp thay vì mua Reserved Instance dài hạn?

On-Demand Instance kết hợp Auto Scaling cho traffic ngắn hạn không dự đoán được, hoặc nếu biết trước thời điểm/thời lượng chính xác có thể cân nhắc Scheduled Reserved Instance (dù ít phổ biến hơn hiện nay) — tránh cam kết Standard/Convertible RI dài hạn (1-3 năm) không cần thiết.

Bạn muốn chạy container trên AWS nhưng không muốn quản lý, patch hay scale các EC2 instance bên dưới. Nên chọn launch type nào cho ECS?

Chọn Fargate (serverless compute cho container). Chỉ cần khai báo CPU/memory trong Task Definition, AWS tự quản lý hạ tầng. Dùng EC2 launch type nếu cần kiểm soát instance, dùng GPU hoặc tối ưu chi phí cho workload ổn định lớn.

Team muốn lưu trữ Docker image riêng tư, tích hợp IAM và tự động quét lỗ hổng bảo mật khi push image. Nên dùng dịch vụ nào?

Dùng Amazon ECR (Elastic Container Registry). Hỗ trợ private repository, phân quyền bằng IAM, image scanning (basic/enhanced) và lifecycle policy để tự động xóa image cũ. Tích hợp sẵn với ECS, EKS, Fargate.

Container trong ECS task cần đọc file từ S3 và ghi log vào DynamoDB. Nên cấp quyền bằng cách nào?

Gán IAM Task Role trong Task Definition với quyền tối thiểu cần thiết (least privilege). Không nhúng access key vào image.

Một công ty đang phát triển ứng dụng bằng Python. Ứng dụng chạy bình thường trên máy của Developer nhưng khi deploy lên server production lại gặp lỗi do khác biệt về Python version, dependencies và environment variables.

Công ty muốn đóng gói ứng dụng cùng toàn bộ dependencies để đảm bảo ứng dụng chạy nhất quán trên nhiều môi trường. Nên sử dụng giải pháp gì?

Sử dụng Docker Container để đóng gói ứng dụng cùng các dependencies cần thiết.

• Tạo Docker Image chứa application code, runtime, libraries và dependencies.

• Chạy Docker Image thành Container trên các môi trường khác nhau.

• Giúp đảm bảo tính nhất quán giữa Development, Testing và Production.

Lưu ý: Container chia sẻ OS Kernel của host, khác với Virtual Machine cần hệ điều hành riêng.

Một công ty đã build thành công Docker Image trên máy local. Bây giờ họ muốn lưu trữ Image trên AWS để ECS có thể pull Image và deploy ứng dụng.

Họ không muốn sử dụng Docker Hub mà muốn sử dụng dịch vụ container registry của AWS. Nên sử dụng dịch vụ nào? Quy trình triển khai như thế nào?

Sử dụng Amazon Elastic Container Registry (ECR).

Một công ty đang chạy ECS với EC2 Launch Type. Họ muốn chạy 10 Containers nhưng nhận thấy các EC2 Instances hiện tại không đủ CPU và Memory để chứa thêm Containers.

ECS có tự động tạo thêm EC2 Instances để đáp ứng nhu cầu này không? Công ty cần làm gì?

Không mặc định.

Với ECS EC2 Launch Type, khách hàng chịu trách nhiệm quản lý hạ tầng EC2 cung cấp compute capacity cho Containers.

Cần bổ sung capacity bằng cách:

1. Launch thêm EC2 Instances và đăng ký chúng vào ECS Cluster thông qua ECS Container Agent.

2. Hoặc cấu hình Auto Scaling Group kết hợp ECS Capacity Provider để tự động mở rộng EC2 capacity.

3. Đảm bảo EC2 Instances có đủ CPU, Memory và các tài nguyên cần thiết để chạy Tasks.

Lưu ý: ECS Service có thể yêu cầu thêm Tasks nhưng không thể chạy nếu Cluster không đủ capacity.

Một Startup muốn deploy ứng dụng container trên ECS nhưng không muốn quản lý EC2 Instances, không muốn tự patch OS, quản lý server hay tính toán capacity của từng EC2 Instance.

Họ vẫn muốn sử dụng ECS để quản lý Containers. Nên chọn Launch Type nào? Vì sao?

Chọn AWS Fargate Launch Type.

Fargate là serverless compute engine dành cho Containers.

Bạn cần tự động cài Nginx và cấu hình ứng dụng ngay khi một EC2 Instance mới được launch. Không muốn SSH vào từng instance để cài đặt thủ công. Nên làm gì?

Sử dụng EC2 User Data để bootstrap instance khi khởi chạy.

Công ty cần launch 100 EC2 Instances giống nhau, đã cài sẵn application, dependencies và security configurations. Muốn giảm thời gian bootstrapping và tăng tính nhất quán. Nên làm gì?

Sử dụng AMI Baking.

• Tạo và cấu hình một EC2 Instance mẫu.

• Cài application, dependencies, cấu hình cần thiết.

• Tạo Custom AMI từ instance đó.

• Launch các EC2 Instances từ Custom AMI.

Ưu điểm: Launch nhanh, cấu hình đồng nhất, giảm phụ thuộc vào User Data.

Một ứng dụng cần triển khai trên nhiều EC2 Instances. Team muốn phân biệt giữa cài đặt phần mềm khi launch và chuẩn bị sẵn phần mềm trước khi launch. Nên dùng User Data hay AMI Baking?

• User Data: Bootstrap và thực hiện cấu hình khi instance khởi chạy.

• AMI Baking: Cài đặt, chuẩn bị sẵn cấu hình vào Custom AMI trước khi launch.

Dùng AMI Baking khi cần tốc độ launch nhanh và môi trường đồng nhất; User Data khi cần cấu hình linh hoạt lúc khởi chạy.

Bạn tạo EC2 Instance bằng CloudFormation và muốn tự động cài packages, tạo files, chạy commands và khởi động services theo cấu hình khai báo trong template. Nên dùng công cụ nào?

Sử dụng cfn-init.

CloudFormation tạo EC2 Instance thành công nhưng application bên trong vẫn chưa cài đặt xong. Bạn muốn CloudFormation chỉ đánh dấu resource hoàn tất sau khi EC2 thực sự bootstrap thành công. Nên làm gì?

Sử dụng CreationPolicy + cfn-signal.

• CreationPolicy quy định số lượng success signals cần nhận và timeout.

• EC2 chạy bootstrap, sau đó gọi cfn-signal.

• CloudFormation chờ đủ signals trước khi hoàn tất resource creation.

• Nếu không nhận đủ signals trong timeout, resource creation thất bại.

Lưu ý: cfn-init cấu hình instance; cfn-signal báo kết quả cho CloudFormation.

Một EC2 Instance cần đọc file từ S3. Team không muốn lưu AWS Access Key và Secret Key trực tiếp trong code hoặc file cấu hình. Nên làm gì?

Gắn IAM Role thông qua Instance Profile vào EC2.

• IAM Role chứa permissions, ví dụ s3:GetObject.

• Instance Profile là cơ chế đưa Role vào EC2.

• AWS cung cấp temporary credentials qua Instance Metadata Service (IMDS).

Bạn đã tạo IAM Role với quyền truy cập DynamoDB nhưng không thể trực tiếp gắn IAM Role như một resource độc lập vào EC2 Instance theo cơ chế instance profile. Cần sử dụng thành phần nào?

Sử dụng IAM Instance Profile.

• Instance Profile chứa một IAM Role.

• EC2 được gắn Instance Profile.

• Instance sử dụng temporary credentials của Role để gọi AWS APIs.

Lưu ý: Instance Profile là lớp trung gian giữa EC2 và IAM Role.

Một ứng dụng chạy trên nhiều EC2 Instances cần đọc database endpoint, API configuration và secret. Team không muốn hardcode các giá trị này trong AMI hoặc source code. Nên sử dụng dịch vụ nào?

Sử dụng AWS Systems Manager Parameter Store.

Một ứng dụng HPC chạy trên nhiều EC2 Instances cần network latency thấp và throughput cao giữa các instances. Nên sử dụng loại Placement Group nào?

Sử dụng Cluster Placement Group.

Một hệ thống có 5 EC2 Instances quan trọng. Công ty muốn phân tán chúng trên các hardware khác nhau để giảm nguy cơ nhiều instances cùng bị ảnh hưởng khi hardware failure. Nên dùng Placement Group nào?

Sử dụng Spread Placement Group.

Một hệ thống Hadoop hoặc Kafka chạy trên nhiều EC2 Instances. Công ty muốn phân chia instances thành các nhóm hardware riêng biệt để giảm ảnh hưởng khi một nhóm gặp sự cố. Nên sử dụng loại Placement Group nào?

Sử dụng Partition Placement Group.

Một doanh nghiệp sử dụng phần mềm có license tính theo physical CPU sockets và cores. Họ cần kiểm soát và biết chính xác EC2 Instances đang chạy trên physical server nào. Nên sử dụng giải pháp gì?

Sử dụng EC2 Dedicated Hosts.

Một ứng dụng xử lý dữ liệu lớn cần network throughput cao, latency thấp và giảm CPU overhead khi truyền dữ liệu giữa EC2 Instances. Nên sử dụng tính năng nào?

Sử dụng EC2 Enhanced Networking.

Một EC2 Instance chạy database có workload đọc/ghi EBS volume rất lớn. Bạn muốn đảm bảo network bandwidth dành cho EBS I/O không bị cạnh tranh với traffic mạng thông thường. Nên sử dụng gì?

Sử dụng EBS-Optimized EC2 Instance.