Ngân hàng đề — AWS Certified Solutions Architect Associate

Đáp án

C — Tách rời các thành phần bằng Amazon SQS queue, và cấu hình một dead-letter queue để thu các request xử lý thất bại.

Vì sao đúng

Đề nêu bốn dữ kiện, và SQS + DLQ khớp từng cái: | Dữ kiện | Cách đáp ứng | |---|---| | Cần TÁCH RỜI thành phần nhận và thành phần xử lý | hàng đợi ở giữa | | 10.000 request mỗi ngày | SQS thừa sức | | Xử lý mất tới 2 NGÀY | SQS giữ tới 14 ngày | | Request thất bại phải được GIỮ LẠI | dead-letter queue |

Vế thứ tư là điểm quyết định:

"Requests that fail to process must be RETAINED"
    → đây chính là định nghĩa của dead-letter queue
        ↓
    Thông điệp thử N lần không thành công
    → chuyển sang DLQ thay vì mất đi
    → điều tra và xử lý lại sau

Cấu hình:

aws sqs create-queue --queue-name hang-doi-that-bai

aws sqs create-queue --queue-name hang-doi-chinh --attributes '{
  "MessageRetentionPeriod":"1209600",
  "VisibilityTimeout":"43200",
  "RedrivePolicy":"{\"deadLetterTargetArn\":\"<arn-dlq>\",\"maxReceiveCount\":\"3\"}"}'

⚠ MessageRetentionPeriod: 1209600 = 14 ngày — mức tối đa, cần thiết vì xử lý mất tới 2 ngày.

⚠ Và visibility timeout là chỗ phải cẩn thận với việc chạy 2 ngày:

Visibility timeout TỐI ĐA của SQS = 12 GIỜ
    → nhưng xử lý mất tới 2 NGÀY
        ↓
    Không thể đặt visibility timeout bằng 2 ngày
    → phải GIA HẠN ĐỘNG trong lúc xử lý

import boto3, threading
sqs = boto3.client('sqs')

def giu_thong_diep(url, receipt, dung_lai):
    while not dung_lai.is_set():
        sqs.change_message_visibility(
            QueueUrl=url, ReceiptHandle=receipt, VisibilityTimeout=3600)
        dung_lai.wait(1800)      # gia hạn mỗi 30 phút

# Trong vòng xử lý
dung_lai = threading.Event()
threading.Thread(target=giu_thong_diep,
                 args=(URL, m['ReceiptHandle'], dung_lai), daemon=True).start()
xu_ly_request(m['Body'])         # có thể mất 2 ngày
dung_lai.set()
sqs.delete_message(QueueUrl=URL, ReceiptHandle=m['ReceiptHandle'])

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Bên nhận không chờ bên xử lý | tách rời theo thời gian | | Hàng đợi đệm khi tải tăng | | | Thông điệp lỗi không bị mất | DLQ |

Và co giãn theo độ dài hàng đợi:

aws autoscaling put-scaling-policy --auto-scaling-group-name asg-xu-ly   --policy-name theo-hang-doi --policy-type TargetTrackingScaling   --target-tracking-configuration '{"TargetValue":10.0,
    "CustomizedMetricSpecification":{
      "MetricName":"ApproximateNumberOfMessagesVisible",
      "Namespace":"AWS/SQS",
      "Dimensions":[{"Name":"QueueName","Value":"hang-doi-chinh"}],
      "Statistic":"Average"}}'

Vì sao các phương án khác sai

• **B. Dùng Kinesis Data Stream với Kinesis Client Library — đây là phương án gần nhất và về mặt kỹ thuật cũng tách rời được, nhưng nó không có cơ chế giữ thông điệp lỗi sẵn có: Kinesis là luồng theo thứ tự, một bản ghi xử lý lỗi sẽ chặn cả shard cho tới khi bạn tự xử lý. Và với 10.000 request mỗi ngày, quản lý shard là công thừa.
• **A. Dùng DynamoDB Streams và cho thành phần xử lý đọc từ stream — DynamoDB Streams chỉ giữ 24 GIỜ, trong khi xử lý mất tới 2 ngày. Và nó vốn dùng để phản ứng với thay đổi dữ liệu, không phải làm hàng đợi công việc.
• **D. Tách rời bằng "Amazon SQS Topic" và cho bên nhận đăng ký SNS Topic — mô tả lẫn lộn hai dịch vụ. Và SNS là mô hình đẩy, không lưu trữ: nếu bên nhận đang bận hoặc chết, thông điệp mất.

Ghi nhớ

⚠ Ba dịch vụ tách rời — bảng phải thuộc: | Dịch vụ | Mô hình | Giữ dữ liệu | |---|---|---| | Amazon SQS | hàng đợi, KÉO | tới 14 ngày | | Amazon SNS | pub/sub, ĐẨY | không lưu | | Kinesis Data Streams | luồng, nhiều consumer | tới 365 ngày |

Từ khoá nhận diện:

"failed requests must be retained" → SQS + dead-letter queue "multiple consumers read the same data" → Kinesis "notify many subscribers" → SNS

⚠ Ba giới hạn thời gian của SQS phải thuộc: | Giới hạn | Con số | |---|---| | Message retention | tối đa 14 ngày (mặc định 4) | | Visibility timeout | tối đa 12 GIỜ | | Long polling WaitTimeSeconds | tối đa 20 giây |

Với việc chạy quá 12 giờ, có ba lựa chọn: | Lựa chọn | Chi tiết | |---|---| | Gia hạn visibility động | ← như ví dụ trên | | AWS Step Functions với callback pattern | task token, chờ tới 1 năm | | Chia nhỏ công việc thành nhiều bước | |

Step Functions callback đáng biết:

Step Functions gửi task token vào SQS
    → worker xử lý (có thể mất nhiều ngày)
    → gọi SendTaskSuccess với token
        ↓
    Không có visibility timeout nào để lo

Ba tham số của dead-letter queue: | Tham số | Việc | |---|---| | deadLetterTargetArn | hàng đợi đích | | maxReceiveCount | thử bao nhiêu lần rồi bỏ | | Retention của DLQ | nên đặt 14 ngày |

⚠ maxReceiveCount phải tính cùng visibility timeout:

Xử lý mất 2 ngày, visibility timeout 12 giờ, không gia hạn
    → thông điệp hiện lại sau 12 giờ khi vẫn đang xử lý
    → tăng receive count
    → sau 3 lần → vào DLQ dù đang xử lý bình thường
        ↓
    Đây là lỗi rất khó chẩn đoán

Đưa thông điệp từ DLQ về xử lý lại:

aws sqs start-message-move-task   --source-arn <arn-dlq> --destination-arn <arn-hang-doi-chinh>

Hai loại hàng đợi SQS: | Loại | Thứ tự | Thông lượng | |---|---|---| | Standard | không đảm bảo | không giới hạn | | FIFO | đảm bảo | 300 TPS (3.000 gộp lô) |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible | tồn đọng | | ApproximateAgeOfOldestMessage | có bị kẹt không | | Số thông điệp trong DLQ | có lỗi hệ thống |

Đặt alarm trên DLQ là việc bắt buộc:

aws cloudwatch put-metric-alarm --alarm-name co-thong-diep-loi   --namespace AWS/SQS --metric-name ApproximateNumberOfMessagesVisible   --dimensions Name=QueueName,Value=hang-doi-that-bai   --statistic Sum --period 300 --evaluation-periods 1   --threshold 0 --comparison-operator GreaterThanThreshold

Không có alarm: DLQ đầy dần mà không ai biết
    → "giữ lại request lỗi" trở thành "vứt request vào một chỗ không ai nhìn"

Ba lưu ý về idempotent: | Lưu ý | Chi tiết | |---|---| | Standard queue giao ÍT NHẤT MỘT LẦN | có thể trùng | | Consumer phải chịu được xử lý lại | | | Dùng khoá nghiệp vụ chống ghi trùng | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tính theo số request | | | Long polling giảm mạnh | | | Gộp lô 10 thông điệp mỗi lần | |

Và một lời khuyên: hãy đặt alarm trên số thông điệp trong DLQ ngay khi tạo nó. Dead-letter queue giữ lại request lỗi đúng như yêu cầu, nhưng nếu không ai được báo thì nó chỉ là một nơi để chôn vấn đề — và bạn sẽ phát hiện ra hàng nghìn request chưa xử lý vào lúc khách hàng gọi tới hỏi.

Đáp án

C — Dùng AWS IAM Identity Center tích hợp với Active Directory hiện có, tạo permission set với quyền chi tiết cho RDS và S3, gán thành viên vào nhóm AD tương ứng.

Vì sao đúng

Đề nêu năm yêu cầu, và Identity Center thoả hết: | Yêu cầu | Cách đáp ứng | |---|---| | Đã dùng IAM Identity Center | tiếp tục dùng, không thêm dịch vụ | | Ba đội cần quyền khác nhau với RDS và S3 | permission set riêng cho từng đội | | Đặc quyền tối thiểu | quyền chi tiết trong permission set | | Kiểm soát truy cập TẬP TRUNG | một nơi gán quyền cho mọi tài khoản | | ÍT công vận hành NHẤT | ánh xạ nhóm AD, không tạo IAM user |

Vì sao ánh xạ nhóm AD là điểm mấu chốt:

Gán quyền cho NHÓM AD, không phải từng người
    → thành viên mới: chỉ thêm vào nhóm AD
    → nghỉ việc: khoá tài khoản AD là mất quyền mọi nơi
        ↓
    Không phải đụng gì tới AWS

Cấu hình:

aws sso-admin create-permission-set --instance-arn <arn-instance>   --name DoiPhatTrien --session-duration PT8H

aws sso-admin put-inline-policy-to-permission-set   --instance-arn <arn-instance> --permission-set-arn <arn-ps>   --inline-policy '{"Version":"2012-10-17","Statement":[
    {"Effect":"Allow","Action":["s3:GetObject","s3:PutObject"],
     "Resource":"arn:aws:s3:::bao-cao-y-te/dev/*"},
    {"Effect":"Allow","Action":"rds-db:connect",
     "Resource":"arn:aws:rds-db:*:*:dbuser:*/dev_user"}]}'

aws sso-admin create-account-assignment --instance-arn <arn-instance>   --target-id 111122223333 --target-type AWS_ACCOUNT   --permission-set-arn <arn-ps>   --principal-type GROUP --principal-id <id-nhom-ad-dev>

Ba lợi ích cho tuân thủ y tế: | Lợi ích | Chi tiết | |---|---| | KHÔNG có access key dài hạn | credential tạm, tự hết hạn | | Mọi lần đăng nhập ghi vào CloudTrail | | | Một nơi rà soát quyền của mọi tài khoản | |

Vế đầu quan trọng với dữ liệu sức khoẻ:

IAM user có access key tồn tại vô thời hạn
    → rò rỉ là mất quyền vĩnh viễn cho tới khi ai đó xoay khoá
        ↓
    Identity Center chỉ cấp credential có hạn 1-12 giờ

Và IAM database authentication cho RDS:

aws rds modify-db-instance --db-instance-identifier csdl-benh-nhan   --enable-iam-database-authentication --apply-immediately

Kết nối RDS bằng token IAM thay vì mật khẩu
    → token hạn 15 phút
    → không có mật khẩu CSDL nào để rò rỉ
        ↓
    Kết hợp với permission set là mô hình chặt nhất

Vì sao các phương án khác sai

• **A. Dùng Organizations tách tài khoản cho từng đội, áp SCP, và dùng cross-account IAM role — đây là phương án gần nhất và là kiến trúc tốt về mặt cô lập, nhưng nó nhiều việc hơn: phải quản lý ba tài khoản, viết và bảo trì SCP, rồi vẫn phải tạo và duy trì IAM role trong từng tài khoản. Identity Center làm hết phần cuối đó và vẫn phối hợp được với Organizations.
• **B. Dùng Cognito user pool và Lambda tự sinh credential tạm — sai vai trò dịch vụ: Cognito quản lý danh tính người dùng ứng dụng (khách hàng đăng nhập vào app), không phải nhân viên truy cập tài nguyên AWS. Và tự viết logic phân quyền trong Lambda là công vận hành cao nhất.
• **D. Tạo IAM user riêng cho từng người với managed policy, rà soát bằng Access Analyzer — công vận hành cao và kém an toàn nhất: nhân số người × số tài khoản, access key dài hạn, và không dùng lại được AD hiện có.

Ghi nhớ

⚠ Ba dịch vụ quản lý danh tính — bảng phải thuộc: | Dịch vụ | Dành cho | |---|---| | IAM Identity Center | NHÂN VIÊN truy cập tài nguyên AWS | | Amazon Cognito | NGƯỜI DÙNG ỨNG DỤNG (khách hàng) | | IAM user/role | dịch vụ và trường hợp đặc thù |

Từ khoá nhận diện:

"employees, multiple accounts, existing AD" → IAM Identity Center "app users sign up and sign in" → Cognito "least privilege + centralized" → permission set ánh xạ nhóm

Ba nguồn danh tính cho Identity Center: | Nguồn | Khi nào | |---|---| | Identity Center directory | chưa có IdP | | Active Directory | đã có AD ← câu này | | IdP ngoài qua SAML 2.0 | Okta, Entra ID |

Hai cách nối AD: | Cách | Đặc điểm | |---|---| | AWS Managed Microsoft AD | AD thật trên AWS, lập trust được | | AD Connector | proxy, không lưu dữ liệu |

Ba khái niệm cốt lõi: | Khái niệm | Nghĩa | |---|---| | Permission set | tập quyền tái dùng | | Account assignment | (nhóm) × (permission set) × (tài khoản) | | Session duration | 1-12 giờ |

Ba cách xây permission set: | Cách | Chi tiết | |---|---| | AWS managed policy | nhanh | | Customer managed policy | phải tồn tại ở MỌI tài khoản đích | | Inline policy | riêng cho permission set đó |

⚠ Customer managed policy là bẫy triển khai:

Permission set tham chiếu policy tên "ChinhSachYTe"
    → tài khoản nào không có policy đó → gán quyền THẤT BẠI
        ↓
    Triển khai policy bằng CloudFormation StackSets trước

Ba lưu ý cho tuân thủ y tế (HIPAA): | Lưu ý | Chi tiết | |---|---| | Ký BAA với AWS | | | Chỉ dùng dịch vụ đủ điều kiện HIPAA | RDS, S3, Lambda đều có | | Mã hoá at rest và in transit | |

Ba biện pháp đặc quyền tối thiểu cho S3: | Biện pháp | Chi tiết | |---|---| | Giới hạn Resource tới tiền tố cụ thể | | | Tách quyền đọc và ghi | | | Bucket policy làm lớp thứ hai | |

⚠ Quyền cấp bucket và cấp object khác nhau:

s3:ListBucket → Resource: "arn:aws:s3:::bucket"   (KHÔNG có /*)
s3:GetObject  → Resource: "arn:aws:s3:::bucket/*" (CÓ /*)
        ↓
    Nhầm chỗ này là lỗi AccessDenied khó hiểu nhất

Ba biện pháp cho RDS: | Biện pháp | Chi tiết | |---|---| | IAM database authentication | không mật khẩu | | Hoặc Secrets Manager có xoay tự động | | | Đặt trong subnet riêng tư | |

Ba lưu ý về ABAC: | Lưu ý | Chi tiết | |---|---| | Truyền thuộc tính AD làm session tag | | | Policy dùng aws:PrincipalTag | | | Giảm số permission set phải tạo | |

{"Effect":"Allow","Action":"s3:GetObject",
 "Resource":"arn:aws:s3:::bao-cao-y-te/*",
 "Condition":{"StringEquals":
   {"s3:ExistingObjectTag/doi":"${aws:PrincipalTag/doi}"}}}

Ba công cụ rà soát định kỳ: | Công cụ | Việc | |---|---| | IAM Access Analyzer | tìm quyền dư và truy cập ngoài | | CloudTrail | ai làm gì | | AWS Config | cấu hình có tuân thủ không |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đăng nhập thử bằng tài khoản AD của từng đội | | | Kiểm tra chỉ thấy đúng tài khoản được gán | | | Khoá một tài khoản AD, xác nhận mất quyền | |

Và một lời khuyên: hãy gán quyền cho nhóm AD chứ đừng bao giờ gán cho từng người. Đó là khác biệt duy nhất giữa một hệ thống mà việc cho nhân viên nghỉ việc là một thao tác, và một hệ thống mà đó là một danh sách kiểm tra dài mà ai đó sẽ quên một dòng.

Đáp án

C — Tạo một gateway VPC endpoint cho S3, và cập nhật bảng định tuyến của VPC để đẩy lưu lượng S3 qua endpoint đó.

Vì sao đúng

Đề nêu hai yêu cầu, và gateway endpoint là công cụ chính xác: | Yêu cầu | Cách đáp ứng | |---|---| | Lưu lượng tải lên S3 phải RIÊNG TƯ | endpoint đi trên hạ tầng AWS | | KHÔNG dùng Internet công cộng | không qua IGW, không qua NAT |

Gateway endpoint hoạt động thế nào:

Nó thêm một route vào bảng định tuyến:
    đích = prefix list của S3 (pl-xxxxx)
    next hop = vpce-xxxxx
        ↓
    Gói tin tới S3 rẽ vào endpoint
    → không đi qua Internet Gateway hay NAT Gateway

Tạo endpoint:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc   --service-name com.amazonaws.ap-southeast-1.s3   --vpc-endpoint-type Gateway   --route-table-ids rtb-rieng-tu-a rtb-rieng-tu-b

⚠ Tham số --route-table-ids là bước quyết định:

Tạo endpoint mà quên chọn route table
    → không có route nào được thêm
    → lưu lượng vẫn đi qua NAT như cũ
        ↓
    Mọi thứ VẪN CHẠY — không có lỗi nào
    → chỉ là vẫn qua Internet và vẫn tốn phí NAT

Kiểm tra route đã có:

aws ec2 describe-route-tables --route-table-ids rtb-rieng-tu-a   --query "RouteTables[0].Routes[?DestinationPrefixListId!=null]"   --output table

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | MIỄN PHÍ hoàn toàn | gateway endpoint không tính phí | | Không đi qua Internet | | | Tiết kiệm phí xử lý dữ liệu của NAT Gateway | |

Vế thứ ba là lợi ích chi phí thật:

Không có endpoint: EC2 → NAT Gateway → Internet → S3
    → trả phí xử lý dữ liệu của NAT theo GB
        ↓
Có gateway endpoint: MIỄN PHÍ, không tính phí GB
    → với tải nặng S3, tiết kiệm rất lớn

Và nên siết thêm bằng endpoint policy:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["s3:PutObject", "s3:GetObject"],
  "Resource": ["arn:aws:s3:::kho-anh-nghien-cuu/*"]}]}

Endpoint chỉ cho phép truy cập bucket của tổ chức
    → mã độc trong EC2 không đẩy dữ liệu ra bucket lạ

Vì sao các phương án khác sai

• **A. Triển khai NAT Gateway và cho EC2 gửi lưu lượng ra qua đó — đây là phương án gần nhất vì NAT đúng là cách cho subnet riêng tư ra ngoài, nhưng lưu lượng qua NAT vẫn đi ra Internet công cộng rồi mới tới endpoint công khai của S3. Không đáp ứng yêu cầu riêng tư, và còn tốn phí xử lý dữ liệu.
• **B. Dùng S3 Access Point — Access Point là cơ chế quản lý quyền truy cập cho bucket dùng chung (mỗi ứng dụng một điểm vào với policy riêng). Nó không thay đổi đường đi mạng; access point thường vẫn được truy cập qua Internet.
• **D. Cấu hình VPC peering giữa VPC và Amazon S3 — S3 không nằm trong VPC nào cả. Nó là dịch vụ vùng, không có VPC để peer tới.

Ghi nhớ

⚠ Hai loại VPC endpoint — bảng phải thuộc: | Loại | Dịch vụ | Cơ chế | Phí | |---|---|---|---| | Gateway endpoint | CHỈ S3 và DynamoDB | route trong route table | MIỄN PHÍ | | Interface endpoint (PrivateLink) | hầu hết dịch vụ AWS | ENI có IP riêng | theo giờ + GB |

Từ khoá nhận diện:

"S3 or DynamoDB privately" + "cost-effective" → gateway endpoint (miễn phí) "other AWS services privately" → interface endpoint "access from on-premises via DX" → interface endpoint (gateway không dùng được)

⚠ Ba đặc điểm của gateway endpoint: | Đặc điểm | Chi tiết | |---|---| | Miễn phí | | | CHỈ dùng được TỪ TRONG VPC | không dùng từ tại chỗ qua DX/VPN | | Phải gắn vào route table | |

Vế thứ hai quan trọng khi có mạng lai:

Máy chủ tại chỗ qua Direct Connect muốn tới S3 riêng tư
    → gateway endpoint KHÔNG dùng được
        ↓
    Phải dùng interface endpoint cho S3
    → hoặc public VIF của DX

Ba khác biệt khác của interface endpoint cho S3: | Đặc điểm | Chi tiết | |---|---| | Có tên DNS riêng | | | Có security group | | | Dùng được từ tại chỗ | |

Ba lớp bảo vệ nên có cùng nhau: | Lớp | Việc | |---|---| | VPC endpoint | đường đi riêng tư | | Endpoint policy | giới hạn bucket được truy cập | | Bucket policy với aws:SourceVpce | chỉ nhận từ endpoint đó |

Bucket policy khoá chặt:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::kho-anh-nghien-cuu",
              "arn:aws:s3:::kho-anh-nghien-cuu/*"],
 "Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-0abc123"}}}

Từ chối MỌI truy cập không đến từ endpoint
    → kể cả credential hợp lệ từ Internet
        ↓
    Cẩn thận: chính bạn cũng không xem được bucket từ console

Ba khoá điều kiện liên quan: | Khoá | Nghĩa | |---|---| | aws:SourceVpce | một endpoint cụ thể | | aws:SourceVpc | mọi endpoint trong một VPC | | aws:PrincipalOrgID | chỉ tài khoản trong tổ chức |

Ba dịch vụ hay cần interface endpoint: | Dịch vụ | Vì sao | |---|---| | Secrets Manager | lấy credential | | SSM, SSMMessages, EC2Messages | Session Manager | | ECR api và dkr | kéo ảnh container |

⚠ Kéo ảnh ECR cần CẢ gateway endpoint cho S3:

Lớp ảnh container nằm trong S3
    → có endpoint ECR nhưng thiếu S3 gateway endpoint
    → xác thực thành công, tải lớp ảnh thất bại

Ba lưu ý về prefix list: | Lưu ý | Chi tiết | |---|---| | Route dùng prefix list ID, không phải CIDR | | | AWS tự cập nhật dải IP của S3 | | | Dùng được trong security group rule | |

aws ec2 describe-prefix-lists   --filters "Name=prefix-list-name,Values=com.amazonaws.ap-southeast-1.s3"

Ba lưu ý về kiến trúc của đề: | Lưu ý | Chi tiết | |---|---| | Ảnh lưu tạm trên EBS rồi tải lên buổi tối | mất khi instance hỏng | | Cân nhắc tải lên ngay khi xử lý xong | | | Hoặc dùng EFS nếu cần nhiều máy xử lý | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra route đã thêm chưa | | | aws s3 cp từ EC2 | phải chạy được | | Xem VPC Flow Logs không còn lưu lượng ra IGW | |

Và một lời khuyên: hãy kiểm tra bảng định tuyến sau khi tạo gateway endpoint, đừng chỉ tin vào thông báo "created". Đây là kiểu lỗi tệ nhất trong nhóm này — không có gì hỏng, không có lỗi nào, chỉ là dữ liệu vẫn đi qua Internet và bạn vẫn trả phí NAT cho từng GB.

Đáp án

C — Dựng ECS cluster trên AWS Fargate sau một Application Load Balancer, và dùng Amazon QLDB làm tầng lưu trữ.

Vì sao đúng

Đề nêu bốn yêu cầu, và mỗi cái loại bớt lựa chọn: | Yêu cầu | Cách đáp ứng | |---|---| | Lưu trữ dữ liệu BẤT BIẾN "out of the box" | QLDB có sổ cái bất biến sẵn | | Mã hoá at rest | QLDB mã hoá mặc định bằng KMS | | **Có thuộc tính ACID | QLDB hỗ trợ giao dịch ACID | | Tầng tính toán dùng CONTAINER, ít việc nhất | ECS trên Fargate |

Vế đầu là điểm quyết định:

"immutable data OUT OF THE BOX"
    → không phải tự dựng cơ chế bất biến
        ↓
    QLDB có một JOURNAL chỉ ghi thêm (append-only)
    → mọi thay đổi được ghi lại vĩnh viễn
    → được xác minh bằng mã băm mật mã

QLDB hoạt động thế nào:

Mọi giao dịch ghi vào journal chỉ-thêm
    → mỗi mục được băm và liên kết với mục trước
    → tạo thành một chuỗi băm (giống cây Merkle)
        ↓
    Sửa dữ liệu lịch sử → chuỗi băm gãy → phát hiện được
    → và có API để CHỨNG MINH toàn vẹn bằng mật mã

Xác minh bằng mật mã:

aws qldb get-digest --name so-cai-tai-chinh

aws qldb get-revision --name so-cai-tai-chinh   --block-address '{"IonText":"{strandId:\"...\",sequenceNo:14}"}'   --document-id "abc123" --digest-tip-address '{"IonText":"..."}'

Trả về một bằng chứng mật mã
    → chứng minh bản ghi này chưa từng bị sửa
        ↓
    Đây là thứ mà "immutable out of the box" nghĩa là

Và Fargate cho tầng tính toán:

aws ecs create-service --cluster cum-tai-chinh --service-name dich-vu-api   --task-definition api-tai-chinh:1 --desired-count 3 --launch-type FARGATE   --network-configuration 'awsvpcConfiguration={
    subnets=[subnet-a,subnet-b],securityGroups=[sg-api],assignPublicIp=DISABLED}'   --load-balancers targetGroupArn=<arn-tg>,containerName=api,containerPort=8080

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không quản lý máy chủ nào | Fargate + QLDB đều serverless | | Lịch sử thay đổi đầy đủ, không xoá được | | | Truy vấn bằng PartiQL (giống SQL) | |

Truy vấn lịch sử — tính năng đặc trưng:

SELECT * FROM history(TaiKhoan) AS h
WHERE h.metadata.id = 'abc123';

Trả về MỌI phiên bản của bản ghi qua thời gian
    → ai sửa, sửa lúc nào, sửa gì
        ↓
    Với dữ liệu tài chính, đây chính là yêu cầu kiểm toán

Vì sao các phương án khác sai

• **B. ECS trên Fargate + Amazon S3 làm tầng lưu trữ — đây là phương án gần nhất vì tầng tính toán hoàn toàn đúng, nhưng S3 không có thuộc tính ACID: không có giao dịch nhiều object, không có nhất quán ở mức giao dịch. Và bất biến của S3 (Object Lock) phải bật thêm chứ không phải "out of the box".
• **A. ECS trên EC2 trong ASG + DynamoDB — hai vấn đề: ECS trên EC2 là công vận hành cao hơn Fargate, và DynamoDB không có lịch sử bất biến sẵn (phải tự dựng bằng Streams) dù có hỗ trợ giao dịch ACID.
• **D. ASG với EC2 sau ALB + S3 — không dùng container như đề yêu cầu, và cùng vấn đề S3 không có ACID.

Ghi nhớ

⚠ Bốn CSDL chuyên biệt hay bị hỏi — bảng phải thuộc: | Dịch vụ | Đặc trưng | |---|---| | Amazon QLDB | sổ cái BẤT BIẾN, có bằng chứng mật mã | | Amazon Neptune | CSDL đồ thị — quan hệ, mạng xã hội | | Amazon Timestream | chuỗi thời gian — IoT, metric | | Amazon DocumentDB | tài liệu, tương thích MongoDB |

Từ khoá nhận diện:

"immutable, verifiable history, ledger" → QLDB "relationships, graph traversal" → Neptune "time-series, IoT sensor data" → Timestream "blockchain with multiple parties" → Managed Blockchain

⚠ QLDB và Managed Blockchain — bảng phân biệt: | | QLDB | Managed Blockchain | |---|---|---| | Quyền sở hữu | MỘT bên tin cậy trung tâm | NHIỀU bên không tin nhau | | Mô hình | sổ cái tập trung | blockchain phân tán | | Hiệu năng | cao hơn 2-3 lần | thấp hơn |

Một công ty tài chính tự quản dữ liệu của mình
    → QLDB (có một bên trung tâm)
Nhiều ngân hàng cùng ghi vào một sổ chung
    → Managed Blockchain

Ba đặc điểm của QLDB: | Đặc điểm | Chi tiết | |---|---| | Journal chỉ ghi thêm, không sửa không xoá | | | Băm mật mã liên kết các mục | | | Truy vấn bằng PartiQL | |

Ba khái niệm cần biết: | Khái niệm | Nghĩa | |---|---| | Journal | nhật ký giao dịch bất biến — nguồn sự thật | | Digest | mã băm đại diện toàn bộ journal | | Ledger | sổ cái, chứa nhiều bảng |

⚠ Ba hạn chế của QLDB cần biết: | Hạn chế | Chi tiết | |---|---| | Không hỗ trợ nhiều vùng | không có global ledger | | Không có read replica | | | Xuất dữ liệu ra S3 để phân tích | không dùng làm data warehouse |

Xuất journal ra S3:

aws qldb export-journal-to-s3 --name so-cai-tai-chinh   --inclusive-start-time 2026-08-01T00:00:00Z   --exclusive-end-time 2026-08-31T00:00:00Z   --s3-export-configuration '{"Bucket":"kho-xuat-qldb",
    "Prefix":"thang-8/","EncryptionConfiguration":{"ObjectEncryptionType":"SSE_S3"}}'

Ba lựa chọn nếu cần bất biến trên S3: | Lựa chọn | Chi tiết | |---|---| | S3 Object Lock chế độ compliance | WORM, không ai xoá được | | Versioning + MFA Delete | yếu hơn | | Glacier Vault Lock | dịch vụ Glacier cũ |

Ba đặc điểm ACID: | Thuộc tính | Nghĩa | |---|---| | Atomicity | toàn bộ hoặc không gì | | Consistency | ràng buộc luôn được giữ | | Isolation | giao dịch không thấy nhau dở dang | | Durability | commit rồi là bền |

Ba lựa chọn ACID trên AWS: | Dịch vụ | ACID | |---|---| | RDS, Aurora | ✅ đầy đủ | | QLDB | ✅ | | DynamoDB | ✅ (transaction, giới hạn 100 item) | | S3 | ❌ |

Ba mức "được quản lý" cho container: | Mức | Dịch vụ | |---|---| | Cao nhất | App Runner | | Cao | ECS/EKS trên Fargate ← câu này | | Trung bình | ECS/EKS trên EC2 |

Ba lưu ý về bảo mật tài chính: | Lưu ý | Chi tiết | |---|---| | QLDB mã hoá at rest mặc định | | | Đặt Fargate trong subnet riêng tư | | | Bí mật trong Secrets Manager | |

Và một lời khuyên: hãy kiểm tra QLDB có đáp ứng nhu cầu truy vấn của bạn trước khi cam kết. Nó xuất sắc ở việc chứng minh dữ liệu chưa bị sửa, nhưng không có read replica, không đa vùng, và không phải công cụ để chạy báo cáo phân tích — những phần đó vẫn cần xuất ra S3 và dùng Athena.

Đáp án

C — Cấu hình một S3 gateway endpoint, và cập nhật bảng định tuyến của subnet riêng tư để đẩy lưu lượng S3 qua endpoint.

Vì sao đúng

Đề nêu ba yêu cầu, và gateway endpoint thoả cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Mọi lưu lượng phải ở trong mạng riêng của AWS | endpoint đi trên hạ tầng AWS | | KHÔNG qua Internet công cộng | không qua IGW, không qua NAT | | TIẾT KIỆM CHI PHÍ NHẤT | gateway endpoint MIỄN PHÍ |

Vế thứ ba là điểm phân biệt C và D: | Loại endpoint | Chi phí | |---|---| | Gateway endpoint (S3, DynamoDB) | MIỄN PHÍ hoàn toàn | | Interface endpoint (PrivateLink) | ~0,01 USD/giờ mỗi AZ + phí theo GB |

Cả hai đều đáp ứng yêu cầu riêng tư
    → nhưng gateway endpoint không tính phí gì
        ↓
    Với yêu cầu "MOST cost-effectively", C thắng D

Và nó còn giảm chi phí NAT:

Hiện tại: máy ở subnet riêng tư → NAT Gateway → Internet → S3
    → trả phí xử lý dữ liệu của NAT theo từng GB
        ↓
Sau khi có gateway endpoint:
    → lưu lượng S3 rẽ vào endpoint, không qua NAT
    → tiết kiệm cả phí NAT lẫn đảm bảo riêng tư

Tạo endpoint:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc   --service-name com.amazonaws.ap-southeast-1.s3   --vpc-endpoint-type Gateway   --route-table-ids rtb-rieng-tu-a rtb-rieng-tu-b   --policy-document file://chinh-sach-endpoint.json

Endpoint policy siết chặt hơn:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["s3:PutObject", "s3:GetObject", "s3:ListBucket"],
  "Resource": ["arn:aws:s3:::bao-cao-tin-dung",
               "arn:aws:s3:::bao-cao-tin-dung/*"]}]}

Endpoint chỉ cho phép truy cập bucket của công ty
    → mã độc trong hệ thống không đẩy dữ liệu tín dụng
      ra bucket của kẻ tấn công
        ↓
    Đây là biện pháp chống rò rỉ dữ liệu rất hiệu quả

Và khoá bucket lại từ phía kia:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::bao-cao-tin-dung",
              "arn:aws:s3:::bao-cao-tin-dung/*"],
 "Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-0abc123"}}}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Miễn phí | | | Không có gói nào ra Internet | | | Chứng minh được cho kiểm toán qua Flow Logs | |

Vì sao các phương án khác sai

• **D. Cấu hình S3 INTERFACE endpoint với security group — đây là phương án gần nhất và hoàn toàn đáp ứng yêu cầu riêng tư, nhưng nó tính phí theo giờ mỗi AZ cộng phí theo GB, trong khi gateway endpoint miễn phí. Đề hỏi "MOST cost-effectively", nên C thắng.
• **A. Bật S3 Transfer Acceleration và giới hạn IP tin cậy — Transfer Acceleration đi qua edge location trên Internet công cộng, hoàn toàn ngược với yêu cầu. Và nó còn tính thêm phí mỗi GB.
• **B. Tạo VPN connection giữa VPC và Amazon S3 — S3 không phải một mạng để nối VPN tới. VPN nối VPC với mạng tại chỗ, không nối với dịch vụ AWS.

Ghi nhớ

⚠ Gateway và Interface endpoint — bảng phải thuộc: | | Gateway endpoint | Interface endpoint | |---|---|---| | Dịch vụ | CHỈ S3 và DynamoDB | hầu hết dịch vụ AWS | | Cơ chế | route trong route table | ENI có IP riêng | | Phí | MIỄN PHÍ | theo giờ + GB | | Từ tại chỗ (DX/VPN) | ❌ không dùng được | ✅ | | Security group | ❌ | ✅ | | DNS riêng | ❌ | ✅ |

Từ khoá nhận diện:

"S3 or DynamoDB privately" + "cost-effective" → gateway endpoint "access from on-premises privately" → interface endpoint "other AWS services privately" → interface endpoint

⚠ Khi nào PHẢI dùng interface endpoint cho S3: | Trường hợp | Vì sao | |---|---| | Truy cập từ tại chỗ qua DX/VPN | gateway không dùng được | | Cần security group kiểm soát | | | Cần tên DNS riêng cho S3 | |

Ba bước bắt buộc: | Bước | Chi tiết | |---|---| | 1. Tạo endpoint | | | 2. Gắn vào ĐÚNG route table | hay bị quên | | 3. Kiểm tra route đã xuất hiện | |

Kiểm tra:

aws ec2 describe-route-tables --route-table-ids rtb-rieng-tu-a   --query "RouteTables[0].Routes[?VpcEndpointId!=null]" --output table

Ba lớp bảo vệ nên có: | Lớp | Việc | |---|---| | VPC endpoint | đường đi riêng tư | | Endpoint policy | giới hạn bucket được truy cập | | Bucket policy aws:SourceVpce | chỉ nhận từ endpoint |

Ba khoá điều kiện: | Khoá | Nghĩa | |---|---| | aws:SourceVpce | một endpoint cụ thể | | aws:SourceVpc | mọi endpoint trong VPC | | aws:PrincipalOrgID | tài khoản trong tổ chức |

⚠ Cẩn thận khi áp bucket policy Deny:

Deny theo aws:SourceVpce
    → console AWS truy cập qua Internet
    → chính bạn cũng không xem được bucket
        ↓
    Cân nhắc ngoại lệ cho một role quản trị

Ba cách chứng minh cho kiểm toán: | Cách | Chi tiết | |---|---| | VPC Flow Logs | không còn lưu lượng ra IGW | | CloudTrail với vpcEndpointId | ghi rõ request qua endpoint nào | | AWS Config rule | kiểm tra endpoint tồn tại |

CloudTrail ghi lại endpoint:

{"eventName": "PutObject",
 "vpcEndpointId": "vpce-0abc123",
 "sourceIPAddress": "10.0.1.50"}

Trường vpcEndpointId là bằng chứng trực tiếp
    → request này đi qua endpoint riêng tư

Ba lưu ý về chi phí NAT (khoản tiết kiệm được): | Khoản | Chi tiết | |---|---| | Phí theo giờ mỗi NAT Gateway | không giảm được | | Phí xử lý theo GB | endpoint giúp giảm khoản này | | Nhiều AZ = nhân lên | |

Ba dịch vụ nên có endpoint để giảm phí NAT: | Dịch vụ | Loại endpoint | |---|---| | S3 | gateway (miễn phí) | | DynamoDB | gateway (miễn phí) | | ECR, Secrets Manager, SSM | interface (có phí nhưng thường vẫn rẻ hơn NAT) |

Ba lưu ý về prefix list: | Lưu ý | Chi tiết | |---|---| | Route dùng prefix list ID | AWS tự cập nhật dải IP | | Dùng được trong security group | | | Xem bằng describe-prefix-lists | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra route | | | aws s3 cp từ instance | | | Xem Flow Logs xác nhận không ra IGW | |

Và một lời khuyên: hãy tạo gateway endpoint cho cả S3 và DynamoDB ở mọi VPC, ngay cả khi chưa có yêu cầu tuân thủ. Chúng miễn phí, giảm độ trễ, và cắt bớt một khoản phí NAT mà hầu như không ai để ý cho tới khi đọc kỹ hoá đơn.

Đáp án

C và E.

• C — API Gateway REST API gọi một Lambda function, hàm đó đọc dữ liệu từ bảng DynamoDB
• E — API Gateway REST API truy cập THẲNG vào bảng DynamoDB

Vì sao đúng

Đề yêu cầu kiến trúc dùng dịch vụ được quản lý, tối thiểu công bảo trì — và cả hai phương án đều không có máy chủ nào: | Phương án | Thành phần | Máy chủ phải quản lý | |---|---|---| | C | API Gateway + Lambda + DynamoDB | không có | | E | API Gateway + DynamoDB | không có |

Phương án E ít người biết — API Gateway gọi thẳng DynamoDB:

API Gateway hỗ trợ AWS SERVICE INTEGRATION
    → gọi trực tiếp API của dịch vụ AWS
    → không cần Lambda ở giữa
        ↓
    Bớt một thành phần, bớt độ trễ, bớt chi phí

Cấu hình tích hợp trực tiếp:

aws apigateway put-integration --rest-api-id abc123   --resource-id xyz789 --http-method GET --type AWS   --integration-http-method POST   --uri arn:aws:apigateway:ap-southeast-1:dynamodb:action/Query   --credentials arn:aws:iam::123456789012:role/VaiTroApiGatewayDynamoDB   --request-templates '{"application/json":
    "{\"TableName\":\"DoanhSo\",\"KeyConditionExpression\":\"ma_vung = :v\",
      \"ExpressionAttributeValues\":{\":v\":{\"S\":\"$input.params(\u0027vung\u0027)\"}}}"}'

Khi nào chọn C, khi nào chọn E: | | C (có Lambda) | E (trực tiếp) | |---|---|---| | Cần biến đổi dữ liệu, logic nghiệp vụ | ✅ | ❌ | | Độ trễ | thêm ~10-50 ms | thấp hơn | | Chi phí | có phí Lambda | không | | Khởi động lạnh | có thể có | không | | Dễ gỡ lỗi | ✅ | khó hơn (VTL template) |

Chỉ đọc và trả dữ liệu như-là  → E rẻ và nhanh hơn
Cần lọc, gộp, gọi nhiều nguồn  → C linh hoạt hơn

Phương án C:

import boto3, json
bang = boto3.resource('dynamodb').Table('DoanhSo')

def handler(event, context):
    vung = event['queryStringParameters']['vung']
    r = bang.query(KeyConditionExpression=Key('ma_vung').eq(vung))
    return {'statusCode': 200,
            'body': json.dumps(r['Items'], ensure_ascii=False, default=str)}

Ba lợi ích chung của cả hai: | Lợi ích | Chi tiết | |---|---| | Không có máy chủ để vá lỗi | | | Tự co giãn từ 0 tới hàng nghìn request | | | Trả tiền theo lượng dùng thật | |

Vì sao các phương án khác sai

• **B. ELB chuyển tiếp tới target group EC2 chạy ứng dụng đọc DynamoDB — đây là phương án gần nhất vì hoàn toàn chạy được, nhưng nó có máy chủ phải quản lý: vá lỗi hệ điều hành, cấu hình Auto Scaling, giám sát. Đề đòi "minimal operational maintenance".
• **D. ELB chuyển tiếp tới target group có DynamoDB làm target — bất khả thi: target group của ELB chỉ nhận EC2 instance, địa chỉ IP, Lambda function hoặc ALB. DynamoDB không phải một loại target hợp lệ.
• **A. Route 53 hosted zone định tuyến tới "AWS Lambda endpoint" — không tồn tại: Lambda không có endpoint HTTP để trỏ DNS tới. Muốn gọi Lambda qua HTTP phải qua API Gateway, Lambda Function URL, hoặc ALB.

Ghi nhớ

⚠ Bốn cách phơi bày Lambda qua HTTP — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | API Gateway | đầy đủ: xác thực, throttle, cache, giai đoạn | | Lambda Function URL | đơn giản nhất, endpoint HTTPS thẳng | | ALB với Lambda target | tích hợp với hạ tầng ALB sẵn có | | Route 53 trỏ thẳng | ❌ không có |

Lambda Function URL đáng biết:

aws lambda create-function-url-config --function-name doc-doanh-so   --auth-type AWS_IAM --cors '{"AllowOrigins":["https://vidu.com"]}'

Cho ra một URL HTTPS ngay
    → không cần API Gateway
    → nhưng thiếu throttling, cache, usage plan

Từ khoá nhận diện:

"managed services, minimal maintenance" + web app → API Gateway + Lambda + DynamoDB "simple pass-through to a service" → API Gateway service integration "need full API management" → API Gateway

Ba loại tích hợp của API Gateway: | Loại | Gọi tới | |---|---| | AWS_PROXY | Lambda (proxy — truyền nguyên event) | | AWS | dịch vụ AWS bất kỳ (DynamoDB, SQS, Kinesis...) | | HTTP / HTTP_PROXY | endpoint HTTP bên ngoài | | MOCK | trả về cố định, để thử |

Ba dịch vụ hay tích hợp trực tiếp: | Dịch vụ | Dùng cho | |---|---| | DynamoDB | CRUD đơn giản ← câu này | | SQS | nhận request vào hàng đợi | | Kinesis Firehose | nạp dữ liệu theo luồng |

⚠ Ba nhược điểm của tích hợp trực tiếp: | Nhược điểm | Chi tiết | |---|---| | Phải viết VTL mapping template | cú pháp khó, khó gỡ lỗi | | Không có logic nghiệp vụ | | | Xử lý lỗi hạn chế | |

VTL là rào cản thực tế:

Velocity Template Language chuyển đổi request/response
    → không có debugger, lỗi cú pháp báo rất mơ hồ
        ↓
    Với logic đơn giản thì đáng dùng
    → phức tạp hơn thì Lambda dễ bảo trì hơn nhiều

Hai loại API của API Gateway: | Loại | Đặc điểm | |---|---| | REST API | đầy đủ tính năng: cache, usage plan, WAF, service integration | | HTTP API | rẻ hơn ~70%, nhanh hơn, ít tính năng hơn |

⚠ HTTP API không hỗ trợ AWS service integration trực tiếp như REST API — đó là lý do đề nói "REST API".

Ba cách xác thực API Gateway: | Cách | Dùng cho | |---|---| | IAM | dịch vụ nội bộ | | Cognito user pool | người dùng ứng dụng | | Lambda authorizer | logic tuỳ chỉnh |

Ba lưu ý về quyền: | Lưu ý | Chi tiết | |---|---| | Tích hợp trực tiếp cần IAM role cho API Gateway | | | Lambda cần execution role có quyền DynamoDB | | | Giới hạn Resource tới đúng bảng | |

{"Effect":"Allow","Action":["dynamodb:Query","dynamodb:GetItem"],
 "Resource":"arn:aws:dynamodb:ap-southeast-1:123456789012:table/DoanhSo"}

Ba cách tối ưu chi phí: | Cách | Chi tiết | |---|---| | Dùng HTTP API nếu không cần tính năng REST | | | Bật cache của API Gateway | giảm gọi backend | | DynamoDB on-demand cho tải không đều | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Thiết kế khoá DynamoDB theo mẫu truy vấn | | | Dùng Query, tránh Scan | | | GSI cho mẫu truy cập khác | |

⚠ Scan là bẫy hiệu năng và chi phí:

Scan đọc TOÀN BỘ bảng rồi mới lọc
    → tốn RCU cho cả dữ liệu không dùng
        ↓
    Query chỉ đọc đúng partition cần
    → thiết kế khoá để luôn Query được

Ba lưu ý về giao diện người dùng: | Lưu ý | Chi tiết | |---|---| | Trang tĩnh đặt trên S3 + CloudFront | | | Bật CORS trên API Gateway | | | Dùng Cognito nếu cần đăng nhập | |

Và một lời khuyên: hãy bắt đầu bằng API Gateway + Lambda, và chỉ chuyển sang tích hợp trực tiếp khi đã đo được rằng Lambda là nút thắt. Tích hợp trực tiếp rẻ và nhanh hơn thật, nhưng VTL template là thứ mà người tiếp quản dự án sáu tháng sau sẽ rất khó sửa.

Đáp án

C — Thêm các VPN bổ sung vào Production VPC từ một thiết bị customer gateway THỨ HAI.

Vì sao đúng

Đề mô tả hai kết nối lai, và chỉ một bên có điểm hỏng đơn lẻ: | VPC | Kết nối | Điểm hỏng | |---|---|---| | Pre-Production | VGW + HAI Direct Connect | đã có dự phòng | | Production | VPN qua MỘT customer gateway | thiết bị đó là điểm hỏng duy nhất |

Chỗ hỏng nằm chính xác ở đâu:

Site-to-Site VPN connection đã có SẴN hai tunnel
    → hai tunnel đó kết thúc ở HAI thiết bị khác nhau PHÍA AWS
        ↓
    Nhưng cả hai đều xuất phát từ MỘT thiết bị phía bạn
    → thiết bị đó hỏng → mất cả hai tunnel
        ↓
    Dự phòng phía AWS đã có sẵn; thiếu là ở phía khách hàng

Cách sửa:

aws ec2 create-customer-gateway --type ipsec.1   --public-ip 203.0.113.20 --bgp-asn 65000

aws ec2 create-vpn-connection --type ipsec.1   --customer-gateway-id cgw-thu-hai --vpn-gateway-id vgw-abc   --options '{"StaticRoutesOnly":false}'

Kết quả:

Trước:  trung tâm dữ liệu ─[1 thiết bị]─ 2 tunnel ─ VGW
Sau:    trung tâm dữ liệu ─[thiết bị A]─ 2 tunnel ─┐
                          └[thiết bị B]─ 2 tunnel ─┴ VGW
        ↓
    Tổng 4 tunnel, hai thiết bị độc lập
    → đây là cấu hình AWS khuyến nghị

Và BGP tự chuyển đường:

Thiết bị A hỏng
    → BGP session của nó chết
    → route bị rút
    → lưu lượng tự đi qua thiết bị B
        ↓
    Không cần can thiệp

Ba lưu ý để dự phòng thật sự: | Lưu ý | Chi tiết | |---|---| | Hai thiết bị NGUỒN ĐIỆN khác nhau | | | Hai đường mạng ISP khác nhau | | | Bật BGP, không dùng static route | |

Vế thứ ba quan trọng:

Static route không tự rút khi đường chết
    → lưu lượng vẫn được gửi vào đường hỏng
        ↓
    BGP phát hiện và chuyển tự động

Vì sao các phương án khác sai

• **A. Thêm một virtual private gateway thứ hai gắn vào Production VPC — đây là phương án gần nhất vì cũng nhắm vào việc thêm dự phòng, nhưng một VPC chỉ gắn được MỘT virtual private gateway. Và VGW vốn đã có tính sẵn sàng cao ở phía AWS — không phải chỗ hỏng.
• **B. Thêm một VPC peering connection thứ hai giữa hai VPC — peering không phải điểm hỏng cần sửa: AWS quản lý peering với tính sẵn sàng cao ở tầng hạ tầng, và một VPC không thể có hai peering trùng nhau tới cùng một VPC.
• **D. Thêm VPN giữa Production và Pre-Production VPC — không giải quyết vấn đề: đây là kết nối giữa hai VPC (vốn đã có peering), không đụng gì tới điểm hỏng ở customer gateway phía trung tâm dữ liệu.

Ghi nhớ

⚠ Ba thành phần của Site-to-Site VPN — bảng phải thuộc: | Thành phần | Ở đâu | Dự phòng | |---|---|---| | Customer Gateway (CGW) | phía BẠN | bạn phải tự lo | | Virtual Private Gateway (VGW) | phía AWS | AWS lo sẵn | | VPN Connection | hai tunnel | có sẵn |

Nguyên tắc: AWS lo phía AWS, bạn lo phía bạn
    → mọi câu hỏi về "single point of failure" trong VPN
      gần như luôn chỉ về customer gateway

Từ khoá nhận diện:

"single customer gateway device" → thêm thiết bị CGW thứ hai "single DX connection" → thêm DX ở location khác "single AZ" → trải đa AZ

⚠ Bốn mức phục hồi của Direct Connect: | Mức | Cấu hình | SLA | |---|---|---| | Development/Test | 1 kết nối, 1 location | không | | High Resiliency | 2 kết nối, 2 DX location | 99,9% | | Maximum Resiliency | 2 kết nối ở MỖI location, 2 location | 99,99% |

Trong đề, Pre-Production đã có hai DX — đó là lý do nó không phải chỗ cần sửa.

Ba mẫu dự phòng cho kết nối lai: | Mẫu | Chống được | |---|---| | DX + VPN dự phòng | hỏng DX | | Hai CGW với VPN | hỏng thiết bị phía bạn ← câu này | | Hai DX ở hai location | hỏng cả một cơ sở |

Ba đặc điểm của VPN tunnel: | Đặc điểm | Chi tiết | |---|---| | Mỗi connection có ĐÚNG hai tunnel | | | Hai tunnel ở hai AZ phía AWS | | | Tối đa ~1,25 Gbps mỗi tunnel | |

⚠ Muốn hơn 1,25 Gbps phải làm gì:

Một tunnel giới hạn ~1,25 Gbps
    → dùng ECMP với Transit Gateway để gộp nhiều tunnel
        ↓
    VGW KHÔNG hỗ trợ ECMP; Transit Gateway thì có

Ba lợi ích của Transit Gateway cho VPN: | Lợi ích | Chi tiết | |---|---| | Hỗ trợ ECMP — gộp băng thông nhiều tunnel | | | Nối nhiều VPC qua một VPN | | | Bắc cầu được (peering thì không) | |

Ba tham số BGP nên cấu hình: | Tham số | Việc | |---|---| | AS path prepending | ưu tiên đường chính | | Local preference | | | BFD | phát hiện đường chết trong dưới 1 giây |

BFD là chi tiết đáng nhớ:

Không có BFD: BGP mất tới 90 giây mới nhận ra đường chết
Có BFD:       phát hiện dưới 1 giây
        ↓
    Với hạ tầng quan trọng, đây là khác biệt lớn

⚠ Ba đặc điểm của VPC Peering cần nhớ: | Đặc điểm | Chi tiết | |---|---| | KHÔNG bắc cầu | | | Không dùng chung VPN, NAT, IGW của VPC kia | | | AWS quản lý, tính sẵn sàng cao | |

Vế thứ hai giải thích vì sao D vô nghĩa:

Production VPC KHÔNG dùng được DX của Pre-Production
    → dù có peering
        ↓
    Muốn dùng chung DX thì phải dùng Transit Gateway
    hoặc Direct Connect Gateway

Ba lưu ý về CIDR: | Lưu ý | Chi tiết | |---|---| | Không được trùng giữa các VPC peering | | | Không trùng với mạng tại chỗ | | | Lên kế hoạch CIDR từ đầu | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | TunnelState | tunnel UP hay DOWN | | TunnelDataIn/Out | có lưu lượng không | | Số route BGP nhận được | |

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-abc   --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,LastStatusChange]"   --output table

Ba việc kiểm chứng dự phòng: | Việc | Cách | |---|---| | Tắt thiết bị CGW thứ nhất, đo thời gian chuyển | | | Kiểm tra cả hai đường đều có lưu lượng | | | Diễn tập trong cửa sổ bảo trì | |

Vế thứ hai đáng chú ý:

Đường dự phòng chưa bao giờ chở lưu lượng
    → là đường chưa được kiểm chứng
        ↓
    Cấu hình để cả hai cùng hoạt động (ECMP),
    hoặc chủ động chuyển qua lại định kỳ

Và một lời khuyên: hãy kiểm tra hai thiết bị customer gateway có thật sự độc lập không — khác nguồn điện, khác đường cáp, khác nhà mạng. Hai router đặt cạnh nhau trong cùng một tủ rack, cắm cùng một ổ điện, là hai thiết bị trên sơ đồ nhưng chỉ là một điểm hỏng trên thực tế.

Đáp án

D — Dùng AWS Batch điều phối job biên tập video trên Spot Instance, lưu metadata trong ElastiCache for Redis và video đã xử lý trong S3 Intelligent-Tiering.

Vì sao đúng

Đề nêu bốn dữ kiện, và AWS Batch trên Spot là mô hình chuẩn cho tải này: | Dữ kiện | Cách đáp ứng | |---|---| | Xử lý video nặng, mỗi tệp vài TB, mất tới 25 phút | AWS Batch cho job chạy lâu | | Cần co giãn theo nhu cầu cao điểm | Batch tự cấp máy theo hàng đợi | | Phải TIẾT KIỆM | Spot rẻ tới 90% | | Video giữ được ít nhất 90 ngày | S3 Intelligent-Tiering |

Vì sao AWS Batch chứ không phải ECS thẳng:

AWS Batch được thiết kế cho job xử lý theo lô:
    → hàng đợi có ưu tiên
    → tự cấp và thu hồi compute environment
    → job dependency, array job, tự thử lại
        ↓
    Và nó tích hợp SẴN với Spot, tự xử lý việc bị thu hồi

Vì sao Spot phù hợp ở đây:

Xử lý video là công việc:
    → chạy theo lô, không phục vụ người dùng trực tiếp
    → idempotent — chạy lại được nếu bị cắt giữa chừng
        ↓
    Đúng hồ sơ của tải nên dùng Spot
    → tiết kiệm 70-90% so với On-Demand

Cấu hình:

aws batch create-compute-environment   --compute-environment-name moi-truong-video   --type MANAGED --state ENABLED   --compute-resources '{
    "type":"SPOT","allocationStrategy":"SPOT_CAPACITY_OPTIMIZED",
    "minvCpus":0,"maxvCpus":512,"desiredvCpus":0,
    "instanceTypes":["c6i","m6i","r6i"],
    "subnets":["subnet-a","subnet-b"],
    "securityGroupIds":["sg-batch"],
    "instanceRole":"ecsInstanceRole",
    "bidPercentage":100}'

aws batch create-job-queue --job-queue-name hang-doi-video   --priority 1 --state ENABLED   --compute-environment-order order=1,computeEnvironment=moi-truong-video

⚠ minvCpus: 0 là tham số quan trọng:

Không có job → Batch thu về 0 máy
    → không trả tiền compute nào khi rảnh
        ↓
    Đây là phần lớn khoản tiết kiệm

Gửi job:

aws batch submit-job --job-name xu-ly-video-001   --job-queue hang-doi-video --job-definition dinh-nghia-video:1   --retry-strategy attempts=3   --container-overrides '{"environment":[
    {"name":"S3_NGUON","value":"s3://video-tho/clip001.mov"}]}'

⚠ --retry-strategy attempts=3 xử lý việc Spot bị thu hồi:

Spot bị thu hồi giữa chừng
    → job thất bại
    → Batch tự chạy lại trên máy khác
        ↓
    Không có tham số này thì phải theo dõi và gửi lại bằng tay

Và S3 Intelligent-Tiering cho phần lưu trữ:

Video mới xử lý được tải về nhiều trong tuần đầu
    → sau đó gần như không ai đụng
        ↓
    Intelligent-Tiering tự chuyển tầng theo thực tế
    → KHÔNG có phí lấy dữ liệu
    → đáp ứng "accessible for a minimum of 90 days"

Vì sao các phương án khác sai

• **C. Dùng ECS với Fargate chạy container biên tập, metadata trong DynamoDB, video trong S3 Standard-IA — đây là phương án gần nhất và hoàn toàn chạy được, nhưng nó đắt hơn đáng kể: Fargate không có tuỳ chọn Spot rẻ bằng EC2 Spot cho tải tính toán nặng, và Standard-IA có phí lấy dữ liệu cộng ngưỡng tối thiểu 30 ngày — không lợi bằng Intelligent-Tiering khi mẫu truy cập không đoán trước.
• **B. EC2 trong ASG sau ALB với SQS, video lưu trong Glacier Flexible Retrieval — Glacier Flexible cần khôi phục mất vài phút tới vài giờ, vi phạm yêu cầu video phải truy cập được trong 90 ngày. Và ALB không cần thiết cho tải xử lý theo lô.
• **A. Máy chủ tại chỗ nối Storage Gateway — không co giãn được theo nhu cầu cao điểm, đúng thứ đề yêu cầu. Và đây là công vận hành cao nhất.

Ghi nhớ

⚠ Ba dịch vụ chạy job theo lô — bảng phải thuộc: | Dịch vụ | Đặc điểm | |---|---| | AWS Batch | hàng đợi, ưu tiên, tự cấp máy, hợp Spot | | ECS scheduled task | job đơn giản theo cron | | AWS Lambda | tối đa 15 phút — không hợp job 25 phút |

⚠ Giới hạn 15 phút của Lambda loại nó khỏi bài này — job mất tới 25 phút.

Từ khoá nhận diện:

"batch processing", "job queue", "cost-effective", "interruptible" → AWS Batch + Spot "under 15 minutes, event-driven" → Lambda "always-running web service" → ECS service, App Runner

Ba thành phần của AWS Batch: | Thành phần | Việc | |---|---| | Compute environment | máy chạy job (EC2, Spot, Fargate) | | Job queue | hàng đợi có ưu tiên | | Job definition | ảnh container, vCPU, RAM |

Ba chiến lược cấp phát Spot: | Chiến lược | Đặc điểm | |---|---| | SPOT_CAPACITY_OPTIMIZED | chọn pool ít bị thu hồi nhất ← khuyến nghị | | SPOT_PRICE_CAPACITY_OPTIMIZED | cân bằng giá và năng lực | | BEST_FIT_PROGRESSIVE | |

⚠ Ba đặc điểm của Spot phải nhớ: | Đặc điểm | Chi tiết | |---|---| | Rẻ tới 90% so với On-Demand | | | Bị thu hồi với 2 PHÚT báo trước | | | "Spot blocks" đã NGỪNG từ 12/2021 | |

Xử lý thông báo thu hồi:

# Trong container, kiểm tra metadata
curl -s http://169.254.169.254/latest/meta-data/spot/instance-action

Nhận được thông báo → lưu tiến độ, thoát sạch
    → job được thử lại từ điểm checkpoint

Ba cách làm job chịu được gián đoạn: | Cách | Chi tiết | |---|---| | Chia video thành đoạn nhỏ | mất ít công khi bị cắt | | Ghi checkpoint ra S3 | | | Đặt retry-strategy | |

Ba lưu ý về job xử lý tệp lớn: | Lưu ý | Chi tiết | |---|---| | Vài TB không tải hết vào đĩa cục bộ | dùng streaming | | Cân nhắc FSx for Lustre liên kết S3 | | | Chọn instance có băng thông mạng cao | |

S3 Intelligent-Tiering — ba tầng chính: | Tầng | Chuyển sau | |---|---| | Frequent Access | mặc định | | Infrequent Access | 30 ngày không truy cập | | Archive Instant Access | 90 ngày |

⚠ Ba lý do Intelligent-Tiering hợp với bài này: | Lý do | Chi tiết | |---|---| | KHÔNG có phí lấy dữ liệu | | | Không có ngưỡng lưu tối thiểu | khác Standard-IA (30 ngày) | | Video vẫn truy cập TỨC THÌ ở cả ba tầng đầu | |

Phí giám sát là điều duy nhất cần cân nhắc:

Tính phí giám sát mỗi object mỗi tháng
    → với video vài TB thì không đáng kể
    → với hàng triệu tệp nhỏ thì mới thành vấn đề

Ba lựa chọn metadata: | Lựa chọn | Khi nào | |---|---| | ElastiCache for Redis | tra cứu rất nhanh, dữ liệu tạm | | DynamoDB | bền vững, không mất | | RDS | cần quan hệ và truy vấn phức tạp |

⚠ Lưu ý về ElastiCache làm nơi giữ metadata:

ElastiCache là CACHE — dữ liệu có thể mất
    → nếu metadata là nguồn sự thật duy nhất thì rủi ro
        ↓
    Bật snapshot và Multi-AZ,
    hoặc cân nhắc MemoryDB (bền vững như CSDL)

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Spot rẻ nhất cho compute | | | minvCpus: 0 để không trả khi rảnh | | | Intelligent-Tiering tự tối ưu lưu trữ | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | Số job trong trạng thái RUNNABLE | tồn đọng | | Tỷ lệ job thất bại | Spot bị thu hồi nhiều không | | Thời gian chạy trung bình | |

Và một lời khuyên: hãy thiết kế job ghi checkpoint ngay từ đầu khi dùng Spot. Một job 25 phút bị thu hồi ở phút thứ 24 và phải chạy lại từ đầu sẽ ăn hết khoản tiết kiệm — còn một job chia thành năm đoạn năm phút thì mất nhiều nhất là năm phút công.

Đáp án

D — Dùng Amazon S3 File Gateway cung cấp lưu trữ độ trễ thấp cho ứng dụng tại chỗ; gateway sẽ cache dữ liệu hay dùng ở cục bộ.

Vì sao đúng

Đề nêu ba dữ kiện, và File Gateway khớp cả ba: | Dữ kiện | Cách đáp ứng | |---|---| | Dữ liệu đã chuyển hết lên S3 để tiết kiệm | File Gateway giữ dữ liệu chính ở S3 | | Ứng dụng tại chỗ cần truy cập ĐỘ TRỄ THẤP | cache cục bộ cho dữ liệu nóng | | TIẾT KIỆM CHI PHÍ NHẤT | S3 là kho rẻ nhất, chỉ cache một phần tại chỗ |

Vì sao cache là mảnh ghép quyết định:

Dữ liệu chính nằm ở S3 (rẻ)
    → mỗi lần đọc phải tải qua Internet thì rất chậm
        ↓
    File Gateway giữ dữ liệu hay dùng trong đĩa cache tại chỗ
    → đọc dữ liệu nóng ở tốc độ mạng LAN
    → đọc dữ liệu nguội thì tải từ S3

Triển khai:

aws storagegateway create-nfs-file-share   --client-token $(uuidgen) --gateway-arn <arn-gateway>   --location-arn arn:aws:s3:::du-lieu-mo-phong   --role <arn-role> --client-list 192.168.1.0/24   --default-storage-class S3_STANDARD

Ứng dụng mount như một thư mục bình thường:

sudo mount -t nfs -o nolock,hard   10.0.1.50:/du-lieu-mo-phong /mnt/mo-phong

Ứng dụng mô phỏng không cần sửa mã
    → vẫn đọc ghi bằng open()/read()/write()

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chỉ cần đĩa cache nhỏ tại chỗ | không giữ toàn bộ dữ liệu | | Dung lượng "nhìn thấy" gần như vô hạn | | | Mỗi tệp là object S3 bình thường | dùng được lifecycle |

Và tỷ lệ trúng cache quyết định trải nghiệm:

aws cloudwatch get-metric-statistics --namespace AWS/StorageGateway   --metric-name CacheHitPercent --dimensions Name=GatewayId,Value=sgw-abc   --start-time 2026-08-29T00:00:00Z --end-time 2026-08-30T00:00:00Z   --period 3600 --statistics Average

Tỷ lệ trúng thấp → mỗi lần đọc phải tải từ S3
    → "low-latency access" không đạt trên thực tế
        ↓
    Cấp đĩa cache đủ chứa tập dữ liệu đang xử lý

Vì sao các phương án khác sai

• **C. Chép dữ liệu từ S3 sang FSx for Lustre, dùng FSx File Gateway cho ứng dụng tại chỗ — đây là phương án gần nhất và cho hiệu năng cao nhất, nhưng nó sai ở hai điểm: FSx File Gateway chỉ dành cho FSx for Windows File Server, không phải Lustre. Và FSx for Lustre là dịch vụ chạy trên AWS, không phục vụ ứng dụng tại chỗ với độ trễ thấp — cộng thêm chi phí lưu trữ cao hơn S3 nhiều lần.
• **A. Dùng DataSync chép dữ liệu hay dùng về hệ thống lưu trữ tại chỗ — làm được nhưng ngược mục tiêu tiết kiệm: phải duy trì hạ tầng lưu trữ tại chỗ, và phải tự đoán trước tệp nào sẽ được dùng. DataSync không có cache tự động.
• **B. Nâng cấp đường Internet và cho ứng dụng gọi thẳng S3 API — sai giao diện và sai độ trễ: ứng dụng mô phỏng cũ đọc ghi qua hệ thống tệp, không dùng SDK. Và mọi lần đọc đều đi qua Internet, không đạt "low-latency".

Ghi nhớ

⚠ Bốn chế độ Storage Gateway — bảng phải thuộc: | Chế độ | Giao diện | Dữ liệu chính | |---|---|---| | S3 File Gateway | NFS, SMB | S3 ← câu này | | FSx File Gateway | SMB | FSx for Windows | | Volume Gateway | iSCSI (khối) | S3 (cached) hoặc tại chỗ (stored) | | Tape Gateway | iSCSI VTL | S3/Glacier |

⚠ FSx File Gateway CHỈ dành cho FSx for Windows File Server — không có gateway nào cho Lustre.

Từ khoá nhận diện:

"on-premises app needs low-latency access to S3 data" → S3 File Gateway "block storage, iSCSI" → Volume Gateway "migrate data once" → DataSync "HPC on AWS with S3 integration" → FSx for Lustre

⚠ DataSync và Storage Gateway — bảng phân biệt: | | DataSync | Storage Gateway | |---|---|---| | Mục đích | DI CHUYỂN dữ liệu | truy cập LIÊN TỤC | | Cache cục bộ | ❌ | ✅ | | Chạy | theo lịch | liên tục |

Ba cách triển khai gateway: | Cách | Khi nào | |---|---| | Máy ảo (VMware, Hyper-V, KVM) | có hạ tầng ảo hoá | | Hardware Appliance | không có tài nguyên ảo hoá | | EC2 | tải chạy trên AWS |

Ba yêu cầu tài nguyên: | Yêu cầu | Con số tối thiểu | |---|---| | vCPU | 4 | | RAM | 16 GB | | Đĩa cache | 150 GB |

Ba metric bắt buộc theo dõi: | Metric | Ngưỡng cảnh báo | |---|---| | CacheHitPercent | thấp = ứng dụng chậm | | CachePercentUsed | cache đầy | | CloudBytesDownloaded | lượng phải tải từ S3 |

Ba đặc điểm của File Gateway: | Đặc điểm | Chi tiết | |---|---| | Mỗi tệp thành MỘT object S3 | đọc trực tiếp từ AWS được | | Ghi vào share → đẩy lên S3 bất đồng bộ | | | Dùng SSD cho đĩa cache | |

⚠ Ba lưu ý về nhất quán: | Lưu ý | Chi tiết | |---|---| | Object ghi thẳng vào S3 KHÔNG tự hiện trong share | | | Phải gọi RefreshCache | | | Hoặc đặt CacheStaleTimeoutInSeconds | |

aws storagegateway refresh-cache --file-share-arn <arn> --recursive

Ba lưu ý về băng thông: | Lưu ý | Chi tiết | |---|---| | Đặt giới hạn tải lên theo giờ | | | Lần đồng bộ đầu tốn nhiều băng thông | | | Theo dõi độ trễ khi cache miss | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lưu trữ S3 theo lớp | | | Phí gateway theo lượng dữ liệu ghi | | | Phí lấy dữ liệu nếu dùng lớp IA | |

⚠ Chọn lớp mặc định cẩn thận:

Đặt S3_STANDARD_IA cho rẻ
    → nhưng mỗi cache miss phải trả phí lấy dữ liệu
        ↓
    Với ứng dụng mô phỏng đọc lại nhiều,
    S3 Standard rồi lifecycle sau 90 ngày lại rẻ hơn

Ba lựa chọn nếu cần hiệu năng cao hơn: | Lựa chọn | Đặc điểm | |---|---| | Chuyển tải tính toán lên AWS + FSx for Lustre | nhanh nhất | | Tăng đĩa cache của gateway | | | Hardware Appliance thay vì máy ảo | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo thời gian mở tệp nóng và tệp nguội | | | Theo dõi CacheHitPercent một tuần | | | Điều chỉnh cỡ cache theo số đo | |

Và một lời khuyên: hãy tính cỡ đĩa cache theo tập dữ liệu của một lần chạy mô phỏng, không theo tỷ lệ phần trăm tổng dữ liệu. Ứng dụng khoa học thường đọc đi đọc lại cùng một bộ dữ liệu trong suốt một lần chạy rồi chuyển sang bộ khác — cache đúng bằng một bộ cho tỷ lệ trúng cao nhất với chi phí thấp nhất.

Đáp án

A — Dùng Amazon FSx for NetApp ONTAP để hợp nhất lưu trữ và cho phép truy cập đa giao thức cả SMB lẫn NFS.

Vì sao đúng

Đề nêu bốn yêu cầu, và FSx for ONTAP là dịch vụ duy nhất thoả hết: | Yêu cầu | Cách đáp ứng | |---|---| | File server tại chỗ có CẢ Windows SMB lẫn Linux NFS | ONTAP hỗ trợ cả hai GỐC | | HỢP NHẤT thành một giải pháp | một file system, một nơi quản lý | | PROTOCOL SHARING — chia sẻ dữ liệu giữa hai giao thức | cùng volume truy cập được bằng cả hai | | Dự phòng ở mức Availability Zone | Multi-AZ |

Vế thứ ba là điểm quyết định:

"provide PROTOCOL SHARING"
    → cùng MỘT tập dữ liệu
    → máy Windows đọc qua SMB
    → máy Linux đọc qua NFS
        ↓
    Đây là tính năng đa giao thức của ONTAP
    → không phải hai hệ thống tệp riêng

Tạo file system:

aws fsx create-file-system --file-system-type ONTAP   --storage-capacity 2048 --storage-type SSD   --subnet-ids subnet-a subnet-b   --ontap-configuration '{
    "DeploymentType":"MULTI_AZ_1",
    "PreferredSubnetId":"subnet-a",
    "ThroughputCapacity":512,
    "FsxAdminPassword":"...",
    "RouteTableIds":["rtb-abc"]}'

Tạo SVM (storage virtual machine) nối AD:

aws fsx create-storage-virtual-machine --file-system-id fs-abc   --name svm-chung   --active-directory-configuration '{
    "NetBiosName":"FSXSVM",
    "SelfManagedActiveDirectoryConfiguration":{
      "DomainName":"congty.local",
      "DnsIps":["10.0.1.10","10.0.2.10"],
      "UserName":"svc_fsx","Password":"..."}}'

Tạo volume cho phép cả hai giao thức:

aws fsx create-volume --volume-type ONTAP --name du-lieu-chung   --ontap-configuration '{
    "StorageVirtualMachineId":"svm-abc",
    "JunctionPath":"/du-lieu-chung",
    "SecurityStyle":"MIXED",
    "SizeInMegabytes":1048576,
    "StorageEfficiencyEnabled":true}'

⚠ SecurityStyle là tham số quyết định cách phân quyền: | Giá trị | Nghĩa | |---|---| | NTFS | quyền theo ACL Windows | | UNIX | quyền theo POSIX | | MIXED | theo giao thức ghi gần nhất |

Chọn sai security style
    → một bên thấy quyền lạ, hoặc không truy cập được
        ↓
    MIXED linh hoạt nhất nhưng cần hiểu rõ cách nó hoạt động

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một hệ thống tệp cho cả hai loại máy | | | Multi-AZ với chuyển đổi tự động | | | Tính năng NetApp: snapshot, dedup, nén, cloning | |

Và tiết kiệm dung lượng đáng kể:

Storage efficiency của ONTAP:
    → deduplication + nén + compaction
        ↓
    Với dữ liệu văn phòng thường tiết kiệm 50-65%

Vì sao các phương án khác sai

• **C. Dùng FSx for Windows cho SMB và FSx for OpenZFS cho NFS — đây là phương án gần nhất vì mỗi giao thức đều được phục vụ đúng dịch vụ, nhưng nó tạo ra HAI hệ thống tệp riêng biệt. Không có "protocol sharing" — hai nhóm máy không thấy cùng dữ liệu, và bạn phải quản lý, sao lưu, đồng bộ hai nơi.
• **B. Dựng hai EC2 với lưu trữ cục bộ, một cho SMB một cho NFS — công vận hành cao nhất, không có dự phòng AZ, không hợp nhất dữ liệu, và phải tự lo mọi thứ.
• **D. Dùng S3 với S3 File Gateway cho cả SMB và NFS client — File Gateway đúng là hỗ trợ cả hai giao thức, nhưng nó dành cho truy cập từ hạ tầng TẠI CHỖ, còn đề nói rõ là hợp nhất lên đám mây. Và mỗi file share chỉ dùng một giao thức, không chia sẻ dữ liệu chéo giao thức.

Ghi nhớ

⚠ Bốn dịch vụ FSx — bảng phải thuộc: | Dịch vụ | Giao thức | Đa giao thức | |---|---|---| | FSx for Windows File Server | SMB | ❌ | | FSx for Lustre | Lustre | ❌ | | FSx for NetApp ONTAP | NFS + SMB + iSCSI | ✅ ← câu này | | FSx for OpenZFS | NFS | ❌ |

Từ khoá nhận diện:

"both SMB and NFS" + "protocol sharing" → FSx for NetApp ONTAP "Windows only" → FSx for Windows "Linux only" → EFS hoặc FSx for OpenZFS "HPC" → FSx for Lustre

⚠ Lưu ý: FSx for Windows cũng mount được từ Linux (qua cifs-utils) — nhưng đó là Linux nói SMB, không phải "protocol sharing" thật. ONTAP cho mỗi bên dùng giao thức GỐC của mình trên cùng dữ liệu.

Ba khái niệm của ONTAP cần biết: | Khái niệm | Nghĩa | |---|---| | File system | hạ tầng vật lý | | SVM (Storage Virtual Machine) | máy chủ tệp ảo — nối AD, có IP riêng | | Volume | nơi chứa dữ liệu thật |

Ba tính năng nổi bật của ONTAP: | Tính năng | Chi tiết | |---|---| | Storage efficiency | dedup, nén, compaction | | Snapshot tức thì, không tốn dung lượng | | | FlexClone | nhân bản volume gần như miễn phí | | SnapMirror | sao chép sang ONTAP khác (kể cả tại chỗ) |

SnapMirror rất hữu ích khi di chuyển:

Hệ thống NetApp tại chỗ → SnapMirror → FSx for ONTAP
    → di chuyển với thời gian ngừng tối thiểu
        ↓
    Đây là con đường di chuyển được khuyến nghị
    nếu đã dùng NetApp tại chỗ

⚠ Ba tầng lưu trữ của ONTAP: | Tầng | Đặc điểm | |---|---| | SSD (primary) | nhanh, đắt | | Capacity pool | tự động phân tầng dữ liệu nguội | | — | tiết kiệm đáng kể |

aws fsx update-volume --volume-id fsvol-abc   --ontap-configuration '{"TieringPolicy":{"Name":"AUTO","CoolingPeriod":31}}'

Dữ liệu không đụng tới 31 ngày → tự chuyển sang capacity pool
    → rẻ hơn nhiều, vẫn truy cập được

Hai chế độ triển khai: | Chế độ | SLA | |---|---| | Single-AZ | 99,9% | | Multi-AZ | 99,99% ← đề yêu cầu |

Ba yêu cầu để dựng: | Yêu cầu | Chi tiết | |---|---| | Subnet ở hai AZ (Multi-AZ) | | | Active Directory nếu dùng SMB | | | Route table cho floating IP | Multi-AZ |

⚠ Route table là chi tiết riêng của ONTAP Multi-AZ:

ONTAP Multi-AZ dùng floating IP để chuyển đổi
    → phải khai RouteTableIds khi tạo file system
        ↓
    Thiếu bước này thì client không tới được sau khi failover

Ba lưu ý về security style: | Style | Dùng khi | |---|---| | NTFS | chủ yếu Windows truy cập | | UNIX | chủ yếu Linux truy cập | | MIXED | cả hai cùng ghi |

Ba lưu ý về ánh xạ danh tính: | Lưu ý | Chi tiết | |---|---| | Người dùng Windows (SID) và Linux (UID) phải ánh xạ | | | Dùng LDAP hoặc name mapping rule | | | Sai ánh xạ = quyền hiển thị lạ | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | SSD đắt hơn capacity pool nhiều | | | Throughput capacity tính riêng | | | Storage efficiency giảm chi phí thật | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tạo tệp từ Windows, đọc từ Linux | | | Kiểm tra quyền hiển thị hợp lý ở cả hai | | | Thử chuyển đổi Multi-AZ | |

Và một lời khuyên: hãy quyết định security style và ánh xạ danh tính trước khi chép dữ liệu vào. Đổi security style trên volume đã có dữ liệu là việc phức tạp và dễ làm hỏng quyền — còn chọn đúng từ đầu thì mọi thứ vừa khít ngay lần đầu.