Không phải tác vụ nào cũng phù hợp với một EC2 instance chạy liên tục; container phù hợp với nhiều kiểu tác vụ khác nhau, từ dịch vụ web tới job chạy theo lịch.

Chọn một tác vụ, chạy thử với phương án đơn giản nhất, sau đó bật tuỳ chọn để áp dụng tính năng AWS phù hợp:

Một số tình huống khác của MFTECH:

• Worker hiện tại giao tiếp với message broker qua AMQP và đội ngũ không muốn quản lý node: chạy worker trên EKS với Fargate, chuyển broker sang Amazon MQ (managed broker, hỗ trợ AMQP).
• Service trên ECS quá tải CPU: kích hoạt Service Auto Scaling (dựa trên Application Auto Scaling) để tăng số task theo metric CPU, bộ nhớ của service (phần 3).

IRSA và Kubernetes RBAC giải quyết hai bài toán khác nhau. Kubernetes RBAC (gán qua EKS access entries hoặc Kubernetes group) quy định ai được thao tác đối tượng Kubernetes trong cluster, ví dụ quyền dùng kubectl để xem hoặc sửa Deployment. RBAC không cấp và không giới hạn quyền gọi AWS API như S3 hay DynamoDB. Nếu gắn cả policy S3 và DynamoDB vào IAM role của node (instance profile), mọi Pod trên node đều có cả hai quyền, bất kể RBAC cấu hình thế nào. Để Pod giao diện chỉ truy cập DynamoDB và Pod xử lý dữ liệu chỉ truy cập S3, mỗi service dùng một service account riêng, ánh xạ tới một IAM role riêng qua IRSA (annotation eks.amazonaws.com/role-arn đặt trên service account, không gắn policy trực tiếp vào Pod) hoặc qua EKS Pod Identity. Dùng chung một service account cho mọi Pod thì ranh giới quyền không còn.

Not every task suits an EC2 instance that runs all the time; containers fit many kinds of work, from web services to scheduled jobs.

Pick a task, try it with the simplest option, then turn on the option to apply the matching AWS feature:

Some other MFTECH scenarios:

• An existing worker talks to a message broker over AMQP and the team does not want to manage nodes: run the worker on EKS with Fargate and move the broker to Amazon MQ (a managed broker that supports AMQP).
• A service on ECS is CPU-bound: turn on Service Auto Scaling (based on Application Auto Scaling) to increase the number of tasks based on the service’s CPU and memory metrics (part 3).

IRSA and Kubernetes RBAC solve two different problems. Kubernetes RBAC (granted through EKS access entries or Kubernetes groups) controls who can work with Kubernetes objects in the cluster, for example permission to use kubectl to view or change a Deployment. RBAC neither grants nor limits permission to call AWS APIs such as S3 or DynamoDB. If both the S3 and DynamoDB policies are attached to the node IAM role (instance profile), every Pod on the node has both permissions, whatever RBAC says. To let the UI Pods reach only DynamoDB and the data-processing Pods reach only S3, give each service its own service account, mapped to its own IAM role through IRSA (the eks.amazonaws.com/role-arn annotation goes on the service account; no policy is attached directly to a Pod) or through EKS Pod Identity. Sharing one service account across all Pods removes the permission boundary.