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

Tìm thấy 2194 câu.

Câu 581 Design High-Performing Architectures

The database backend for a retail company's website is hosted on Amazon RDS for MySQL having a primary instance and three read replicas to support read scalability. The company has mandated that the read replicas should lag no more than 1 second behind the primary instance to provide the best possible user experience. The read replicas are falling further behind during periods of peak traffic spikes, resulting in a bad user experience as the searches produce inconsistent results.

You have been hired as an AWS Certified Solutions Architect - Associate to reduce the replication lag as much as possible with minimal changes to the application code or the effort required to manage the underlying resources.

Which of the following will you recommend?

  1. A

    Set up database migration from Amazon RDS MySQL to Amazon DynamoDB. Provision a large number of read capacity units (RCUs) to support the required throughput and enable Auto-Scaling
  2. B

    Set up an Amazon ElastiCache for Redis cluster in front of the MySQL database. Update the website to check the cache before querying the read replicas
  3. C

    Host the MySQL primary database on a memory-optimized Amazon EC2 instance. Spin up additional compute-optimized Amazon EC2 instances to host the read replicas
  4. D

    Set up database migration from Amazon RDS MySQL to Amazon Aurora MySQL. Swap out the MySQL read replicas with Aurora Replicas. Configure Aurora Auto Scaling
Xem giải thích

Đáp án

D — Di chuyển từ RDS MySQL sang Aurora MySQL; thay read replica của MySQL bằng Aurora Replica; cấu hình Aurora Auto Scaling.

Vì sao đúng

Đề nêu yêu cầu rất cụ thể: độ trễ sao chép không quá 1 GIÂY, và đó là điểm mà Aurora khác hẳn RDS.

RDS MySQL read replica:
    → sao chép ở TẦNG DATABASE (qua binlog)
    → primary phải đọc và gửi binlog
    → replica áp dụng lại từng câu lệnh
        ↓
    Độ trễ tính bằng GIÂY tới PHÚT, và tăng vọt khi có đỉnh tải

Aurora sao chép ở TẦNG LƯU TRỮ:

Aurora:
    → tầng lưu trữ tự sao chép các thay đổi
    → KHÔNG dùng tài nguyên của instance database
    → replica đọc CÙNG một tầng lưu trữ
        ↓
    Độ trễ thường DƯỚI 100 MILI GIÂY
    → thoả yêu cầu dưới 1 giây rất thoải mái

Và vế "ít thay đổi mã ứng dụng nhất":

Aurora MySQL TƯƠNG THÍCH ở mức giao thức với MySQL
    → ứng dụng chỉ đổi CHUỖI KẾT NỐI
    → không sửa truy vấn, không sửa driver

Di chuyển với gián đoạn tối thiểu:

① Tạo Aurora read replica CỦA instance RDS MySQL
② Chờ độ trễ sao chép về 0
③ Promote Aurora cluster thành độc lập
④ Chuyển ứng dụng sang endpoint mới
        ↓
    Gián đoạn chỉ vài phút

Và Aurora Auto Scaling xử lý đỉnh tải:

aws application-autoscaling register-scalable-target   --service-namespace rds --resource-id cluster:cum-ban-le   --scalable-dimension rds:cluster:ReadReplicaCount   --min-capacity 3 --max-capacity 15

aws application-autoscaling put-scaling-policy   --policy-name giu-cpu-reader --service-namespace rds   --resource-id cluster:cum-ban-le   --scalable-dimension rds:cluster:ReadReplicaCount   --policy-type TargetTrackingScaling   --target-tracking-scaling-policy-configuration     '{"TargetValue":60.0,"PredefinedMetricSpecification":
      {"PredefinedMetricType":"RDSReaderAverageCPUUtilization"}}'

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

  • **B. Đặt ElastiCache for Redis trước database và sửa website kiểm tra cache trước — đây là phương án gần nhất và thực sự giảm tải đọc rất hiệu quả, nhưng nó đòi sửa mã ứng dụng đáng kể: phải viết logic kiểm tra cache, nạp khi trượt, và vô hiệu hoá khi dữ liệu đổi. Đề yêu cầu "minimal changes to the application code".
  • **A. Di chuyển sang DynamoDB với RCU cao và auto scaling — thay đổi lớn nhất: DynamoDB là NoSQL, chuyển sang nó đòi thiết kế lại mô hình dữ liệu và viết lại toàn bộ tầng truy cập.
  • **C. Chuyển primary sang EC2 tối ưu bộ nhớ và replica sang EC2 tối ưu tính toán — tăng rất nhiều công vận hành: tự cài MySQL, tự cấu hình sao chép, tự vá lỗi. Và sao chép của MySQL tự quản lý vẫn có cùng vấn đề độ trễ.

Ghi nhớ

RDS và Aurora — bảng phân biệt cốt lõi: | | RDS MySQL | Aurora MySQL | |---|---|---| | Sao chép | tầng DATABASE (binlog) | tầng LƯU TRỮ | | Độ trễ replica | giây tới phút | thường dưới 100ms | | Số read replica | 5 | 15 | | Bản sao dữ liệu | 2 (Multi-AZ) | 6 qua 3 AZ | | Hiệu năng | chuẩn | cao hơn tới 5 lần | | Chuyển đổi | 60–120 giây | thường dưới 30 giây | | Mở rộng lưu trữ | cấp phát trước | tự động tới 128 TB | | Auto Scaling cho replica | ❌ | ✅ |

Từ khoá nhận diện:

"replication lag under 1 second", "read scalability", "minimal code change" → Aurora "cache query results" → ElastiCache (nhưng cần sửa mã) "NoSQL, key-value" → DynamoDB (thay đổi lớn)

Ba endpoint của Aurora: | Endpoint | Trỏ tới | |---|---| | Cluster (writer) | instance ghi hiện tại | | Reader | cân bằng tải qua MỌI replica | | Custom | nhóm instance do bạn định nghĩa |

Reader endpoint là thứ ứng dụng cần dùng:

ket_noi_ghi = connect(host='cum.cluster-abc.ap-northeast-1.rds.amazonaws.com')
ket_noi_doc = connect(host='cum.cluster-ro-abc.ap-northeast-1.rds.amazonaws.com')

Thêm replica là tự động được dùng — không phải cấu hình lại gì.

Ba cách di chuyển từ RDS MySQL sang Aurora: | Cách | Gián đoạn | |---|---| | Tạo Aurora read replica rồi promote | rất ngắn ← khuyến nghị | | Khôi phục từ snapshot | dài hơn | | AWS DMS với CDC | ngắn, phức tạp hơn |

Ba lưu ý về độ trễ sao chép: | Lưu ý | Chi tiết | |---|---| | Theo dõi AuroraReplicaLag | metric chính | | Replica nên CÙNG CỠ với writer | replica nhỏ hơn sẽ tụt lại | | Không dùng replica cho đọc-sau-ghi | vẫn có độ trễ dù nhỏ |

Mẫu xử lý đọc-sau-ghi:

def cap_nhat(ma, du_lieu):
    ghi_vao_writer(ma, du_lieu)
    danh_dau_vua_ghi(ma, thoi_han=2)

def doc(ma):
    if vua_ghi(ma):
        return doc_tu_writer(ma)
    return doc_tu_reader(ma)

Ba tính năng khác của Aurora: | Tính năng | Chi tiết | |---|---| | Aurora Serverless v2 | tự co giãn năng lực tính toán | | Global Database | replica xuyên Region, độ trễ dưới 1 giây | | Backtrack | quay ngược thời gian tại chỗ (chỉ MySQL) | | Database cloning | copy-on-write, gần như tức thì |

Ba lưu ý về Aurora Auto Scaling: | Lưu ý | Chi tiết | |---|---| | Chỉ co giãn READER, không co giãn writer | | | Metric: CPU hoặc số kết nối | | | Đặt MinCapacity đủ chịu tải nền | |

Ba lựa chọn bổ sung để giảm tải đọc: | Cách | Chi tiết | |---|---| | Tối ưu truy vấn và index | rẻ nhất, thường hiệu quả nhất | | Custom endpoint tách truy vấn nặng | báo cáo không làm chậm ứng dụng | | ElastiCache cho truy vấn lặp lại | cần sửa mã |

Custom endpoint rất hữu ích:

aws rds create-db-cluster-endpoint --db-cluster-identifier cum-ban-le   --db-cluster-endpoint-identifier bao-cao --endpoint-type READER   --static-members replica-bao-cao

Ba metric cần theo dõi sau khi chuyển: | Metric | Ý nghĩa | |---|---| | AuroraReplicaLag | phải dưới 1 giây theo yêu cầu | | DatabaseConnections | gần trần thì cần RDS Proxy | | SelectThroughput trên reader | tải đọc đã tách chưa |

Và Performance Insights nên bật:

Nó cho biết truy vấn nào tốn tài nguyên nhất
    → thường tìm ra một hai truy vấn chiếm phần lớn tải
    → tối ưu chúng có khi hiệu quả hơn thêm replica

Và một lời khuyên: hãy kiểm chứng ứng dụng thật sự đang dùng reader endpoint sau khi chuyển. Rất thường gặp trường hợp mã chính đã sửa nhưng một tác vụ nền hoặc thư viện ORM vẫn dùng chuỗi kết nối cũ — và bạn trả tiền cho replica mà tải trên writer không giảm chút nào.

Câu 582 Design Resilient Architectures

The DevOps team at an IT company has created a custom VPC (V1) and attached an Internet Gateway (I1) to the VPC. The team has also created a subnet (S1) in this custom VPC and added a route to this subnet's route table (R1) that directs internet-bound traffic to the Internet Gateway. Now the team launches an Amazon EC2 instance (E1) in the subnet S1 and assigns a public IPv4 address to this instance. Next the team also launches a Network Address Translation (NAT) instance (N1) in the subnet S1.

Under the given infrastructure setup, which of the following entities is doing the Network Address Translation for the Amazon EC2 instance E1?

  1. A

    Subnet (S1)
  2. B

    Network Address Translation (NAT) instance (N1)
  3. C

    Internet Gateway (I1)
  4. D

    Route Table (R1)
Xem giải thích

Đáp án

C — Internet Gateway (I1) thực hiện Network Address Translation cho instance E1.

Vì sao đúng

Điểm mấu chốt: Internet Gateway thực hiện NAT một-một cho instance có IP công cộng.

Instance E1 trong VPC:
    → chỉ có IP RIÊNG trên network interface (ví dụ 10.0.1.50)
    → IP công cộng KHÔNG được gán vào hệ điều hành
        ↓
    Chạy `ifconfig` trên E1 chỉ thấy IP riêng

Vậy IP công cộng nằm ở đâu?

IP công cộng được AWS ánh xạ tới IP riêng
    → và Internet Gateway thực hiện việc dịch địa chỉ này
        ↓
Lưu lượng ĐI RA:
    E1 (10.0.1.50) → IGW dịch nguồn thành IP công cộng → Internet

Lưu lượng ĐI VÀO:
    Internet → IGW dịch đích từ IP công cộng thành 10.0.1.50 → E1

Đây là NAT một-một (1:1 NAT), khác với NAT nhiều-một của NAT gateway.

Và NAT instance N1 không tham gia gì:

N1 tồn tại trong cùng subnet
    → nhưng route table R1 trỏ lưu lượng Internet TỚI IGW
    → không có route nào trỏ tới N1
        ↓
    N1 hoàn toàn không nằm trên đường đi của E1

Ba vai trò trong kiến trúc này: | Thành phần | Vai trò | |---|---| | Internet Gateway (I1) | thực hiện NAT và cho phép lưu lượng ra vào Internet | | Route table (R1) | quyết định lưu lượng đi ĐÂU (tới IGW) | | Subnet (S1) | phạm vi mạng chứa instance | | NAT instance (N1) | không được dùng trong luồng này |

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

  • **B. NAT instance (N1) thực hiện NAT — đây là phương án gần nhất và là bẫy chính: N1 có tên là "NAT instance" và nằm trong cùng subnet, nhưng không có route nào trỏ tới nó. NAT instance chỉ hoạt động khi route table của private subnet trỏ lưu lượng Internet tới nó — ở đây thì không.
  • **D. Route table (R1) thực hiện NAT — nhầm vai trò: route table chỉ quyết định hướng đi của gói tin, nó không dịch địa chỉ.
  • **A. Subnet (S1) thực hiện NAT — subnet chỉ là dải địa chỉ, không phải thành phần xử lý gói tin.

Ghi nhớ

Hai loại NAT trong VPC — bảng phải thuộc: | Loại | Thành phần | Cơ chế | |---|---|---| | NAT một-một (1:1) | Internet Gateway | mỗi IP công cộng ↔ một IP riêng | | NAT nhiều-một (many-to-1) | NAT gateway hoặc NAT instance | nhiều IP riêng dùng chung một IP công cộng |

Và hai loại này phục vụ hai kịch bản khác nhau:

Instance ở PUBLIC subnet, có IP công cộng:
    → IGW làm NAT 1:1
    → nhận được kết nối TỪ Internet vào

Instance ở PRIVATE subnet, không có IP công cộng:
    → NAT gateway làm NAT nhiều-một
    → CHỈ kết nối được ra ngoài, không nhận được vào

Định nghĩa public và private subnet:

Public subnet:  route table CÓ route tới Internet Gateway
Private subnet: route table KHÔNG có route tới IGW
        ↓
    Đây là khác biệt DUY NHẤT — không có công tắc "public/private"

Ba điều kiện để instance truy cập Internet: | Điều kiện | Chi tiết | |---|---| | VPC có Internet Gateway gắn vào | | | Route table có route 0.0.0.0/0 tới IGW | | | Instance có IP công cộng hoặc Elastic IP | ← thiếu cái này là không ra được |

Cả ba đều phải có — thiếu một là không hoạt động.

Ba cổng ra Internet của VPC: | Cổng | Họ địa chỉ | Chiều | |---|---|---| | Internet Gateway | IPv4 và IPv6 | HAI CHIỀU | | NAT gateway | CHỈ IPv4 | CHỈ ĐI RA | | Egress-only internet gateway | CHỈ IPv6 | CHỈ ĐI RA, MIỄN PHÍ |

Ba đặc điểm của Internet Gateway: | Đặc điểm | Chi tiết | |---|---| | Dư thừa theo chiều ngang, sẵn sàng cao | AWS quản lý, không phải điểm hỏng | | KHÔNG giới hạn băng thông | | | MIỄN PHÍ | chỉ trả phí truyền dữ liệu | | Một IGW mỗi VPC | |

Ba loại IP của EC2: | Loại | Đặc điểm | |---|---| | IP riêng | luôn có, không đổi trong vòng đời instance | | IPv4 công cộng tự động | thu hồi khi stop/start | | Elastic IP | tĩnh, giữ được, có phí khi không gắn |

Và chi tiết quan trọng: IP công cộng KHÔNG hiện trong hệ điều hành:

# Trên instance:
ip addr show          # chỉ thấy IP riêng
# Muốn biết IP công cộng:
TOKEN=$(curl -sX PUT "http://169.254.169.254/latest/api/token"   -H "X-aws-ec2-metadata-token-ttl-seconds: 300")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN"   http://169.254.169.254/latest/meta-data/public-ipv4

Đây là hệ quả trực tiếp của việc IGW làm NAT 1:1.

Ba lưu ý về NAT instance: | Lưu ý | Chi tiết | |---|---| | PHẢI tắt source/destination check | nếu không, NAT không hoạt động | | Là điểm hỏng duy nhất | cần script chuyển đổi tự viết | | Công nghệ CŨ | AWS khuyến nghị NAT gateway |

aws ec2 modify-instance-attribute --instance-id i-0nat --no-source-dest-check

NAT gateway và NAT instance — bảng phân biệt: | | NAT gateway | NAT instance | |---|---|---| | Quản lý | AWS hoàn toàn | bạn | | Sẵn sàng cao | ✅ trong AZ | ❌ tự dựng | | Băng thông | 5–100 Gbps tự co giãn | theo loại instance | | Security group | ❌ không gắn được | ✅ | | Bastion, port forwarding | ❌ | ✅ |

Ba lưu ý về NAT gateway: | Lưu ý | Chi tiết | |---|---| | Phải đặt ở PUBLIC subnet | cần đường ra IGW | | Mỗi AZ nên có một cái | tránh phí chéo AZ và điểm hỏng | | Chi phí ~33 USD/tháng + 0,045 USD/GB | |

Ba công cụ chẩn đoán mạng VPC: | Công cụ | Việc | |---|---| | VPC Reachability Analyzer | kiểm tra đường đi giữa hai điểm | | VPC Flow Logs | thấy lưu lượng thật, kể cả bị từ chối | | Route table và security group | kiểm tra cấu hình |

Và một lời khuyên: hãy dùng VPC Reachability Analyzer khi instance không ra được Internet. Nó chỉ ra chính xác thành phần nào chặn — thiếu route, security group, NACL, hay thiếu IP công cộng — thay vì phải kiểm tra từng thứ một bằng tay.

Câu 583 Design Secure Architectures

An engineering lead is designing a VPC with public and private subnets. The VPC and subnets use IPv4 CIDR blocks. There is one public subnet and one private subnet in each of three Availability Zones (AZs) for high availability. An internet gateway is used to provide internet access for the public subnets. The private subnets require access to the internet to allow Amazon EC2 instances to download software updates.

Which of the following options represents the correct solution to set up internet access for the private subnets?

  1. A

    Set up three Internet gateways, one in each private subnet in each AZ. Create a custom route table for each AZ that forwards non-local traffic to the Internet gateway in its AZ
  2. B

    Set up three NAT gateways, one in each private subnet in each AZ. Create a custom route table for each AZ that forwards non-local traffic to the NAT gateway in its AZ
  3. C

    Set up three NAT gateways, one in each public subnet in each AZ. Create a custom route table for each AZ that forwards non-local traffic to the NAT gateway in its AZ
  4. D

    Set up three egress-only internet gateways, one in each public subnet in each AZ. Create a custom route table for each AZ that forwards non-local traffic to the egress-only internet gateway in its AZ
Xem giải thích

Đáp án

C — Dựng ba NAT gateway, mỗi cái trong một PUBLIC subnet ở mỗi AZ; tạo route table riêng cho mỗi AZ chuyển lưu lượng không cục bộ tới NAT gateway của AZ đó.

Vì sao đúng

Có hai điểm phải đúng, và chỉ đáp án C đúng cả hai: | Điểm | Chi tiết | |---|---| | NAT gateway đặt ở PUBLIC subnet | cần đường ra Internet Gateway | | Mỗi AZ một NAT gateway riêng | chịu lỗi và tránh phí chéo AZ |

Điểm thứ nhất là ràng buộc kỹ thuật:

NAT gateway cần route 0.0.0.0/0 tới Internet Gateway
    → chỉ PUBLIC subnet mới có route đó
        ↓
    Đặt NAT gateway ở private subnet: KHÔNG hoạt động

Điểm thứ hai là thiết kế chịu lỗi:

Một NAT gateway cho cả ba AZ:
    → AZ chứa nó hỏng → CẢ BA AZ mất đường ra Internet
    → và lưu lượng từ hai AZ kia phải đi CHÉO AZ (tính phí)

Ba NAT gateway, mỗi AZ một cái:
    ✓ AZ hỏng chỉ ảnh hưởng chính AZ đó
    ✓ không có phí truyền chéo AZ

Kiến trúc đúng:

AZ-a: public subnet (NAT-a) ← private subnet A (route → NAT-a)
AZ-b: public subnet (NAT-b) ← private subnet B (route → NAT-b)
AZ-c: public subnet (NAT-c) ← private subnet C (route → NAT-c)
        ↓
    Ba route table riêng, mỗi cái trỏ vào NAT gateway cùng AZ

Cấu hình:

for az in a b c; do
  eip=$(aws ec2 allocate-address --domain vpc --query AllocationId --output text)
  nat=$(aws ec2 create-nat-gateway --subnet-id subnet-public-$az     --allocation-id $eip --query NatGateway.NatGatewayId --output text)
  aws ec2 create-route --route-table-id rtb-private-$az     --destination-cidr-block 0.0.0.0/0 --nat-gateway-id $nat
done

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

  • **B. Dựng ba NAT gateway, mỗi cái trong một PRIVATE subnet — đây là phương án gần nhất và có vế "một cái mỗi AZ" hoàn toàn đúng, nhưng nó đặt sai chỗ: NAT gateway trong private subnet không có đường ra Internet Gateway, nên nó không hoạt động.
  • **D. Dựng ba egress-only internet gateway trong public subnet — sai họ địa chỉ: egress-only internet gateway chỉ phục vụ IPv6. Đề nói rõ VPC và subnet dùng IPv4 CIDR.
  • **A. Dựng ba Internet Gateway, mỗi cái trong một private subnet — hai lỗi: một VPC chỉ gắn được MỘT Internet Gateway, và IGW không "đặt trong subnet" — nó gắn ở cấp VPC. Ngoài ra, cho private subnet route tới IGW sẽ biến nó thành public subnet.

Ghi nhớ

Ba cổng ra Internet của VPC — bảng phải thuộc: | Cổng | Họ địa chỉ | Chiều | Đặt ở đâu | |---|---|---|---| | Internet Gateway | IPv4 và IPv6 | hai chiều | gắn ở cấp VPC, MỘT cái | | NAT gateway | CHỈ IPv4 | chỉ đi ra | PUBLIC subnet | | Egress-only IGW | CHỈ IPv6 | chỉ đi ra | gắn ở cấp VPC, MIỄN PHÍ |

Định nghĩa public và private subnet:

Public subnet:  route table CÓ route tới Internet Gateway
Private subnet: route table KHÔNG có route tới IGW

Ba lưu ý về sẵn sàng của NAT gateway: | Lưu ý | Chi tiết | |---|---| | Dư thừa TRONG một AZ | AWS quản lý, không phải điểm hỏng trong AZ | | KHÔNG trải nhiều AZ | AZ hỏng thì NAT gateway đó mất | | Mỗi AZ nên có một cái riêng | ← điểm của câu này |

Ba khoản chi phí của NAT gateway: | Khoản | Giá tham khảo | |---|---| | Theo giờ | ~0,045 USD/giờ (~33 USD/tháng) | | Xử lý dữ liệu | ~0,045 USD/GB | | Truyền chéo AZ nếu đặt sai | thêm ~0,01 USD/GB mỗi chiều |

Với ba NAT gateway: khoảng 100 USD/tháng chỉ riêng phí giờ — đó là cái giá của việc chịu lỗi.

Ba cách giảm chi phí NAT gateway: | Cách | Tiết kiệm | |---|---| | Gateway VPC endpoint cho S3 và DynamoDB | MIỄN PHÍ, tránh hẳn phí NAT | | Interface endpoint cho dịch vụ hay dùng | ECR, SSM, CloudWatch Logs | | Dùng ít NAT gateway hơn ở môi trường dev | chấp nhận rủi ro cao hơn |

Gateway endpoint là khoản tiết kiệm dễ nhất:

aws ec2 create-vpc-endpoint --vpc-id vpc-0abc   --service-name com.amazonaws.ap-northeast-1.s3   --route-table-ids rtb-private-a rtb-private-b rtb-private-c

Hoàn toàn miễn phí, và lưu lượng tới S3 thường rất lớn.

Ba đánh đổi khi chọn số NAT gateway: | Số lượng | Chịu lỗi | Chi phí | |---|---|---| | Một cái | thấp — AZ hỏng là mất hết | thấp nhất | | Ba cái (mỗi AZ) | cao | cao nhất ← câu này | | Hai cái | trung bình | trung bình |

Với môi trường dev, một NAT gateway thường chấp nhận được — với sản xuất thì nên mỗi AZ một cái.

Ba đặc điểm của NAT gateway: | Đặc điểm | Chi tiết | |---|---| | Cần Elastic IP | | | KHÔNG gắn security group được | kiểm soát bằng NACL của subnet | | Băng thông 5–100 Gbps tự co giãn | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | BytesOutToDestination | lưu lượng ra Internet | | ErrorPortAllocation | cạn cổng — cần thêm NAT gateway | | PacketsDropCount | gói bị bỏ |

ErrorPortAllocation đáng chú ý:

Một NAT gateway hỗ trợ ~55.000 kết nối đồng thời
    tới CÙNG một đích (IP + cổng)
        ↓
    Vượt qua thì phải chia tải sang nhiều NAT gateway

NAT gateway và NAT instance: | | NAT gateway | NAT instance | |---|---|---| | Quản lý | AWS | bạn | | Sẵn sàng cao trong AZ | ✅ | ❌ | | Băng thông | tự co giãn | theo loại instance | | Security group | ❌ | ✅ | | Trạng thái | khuyến nghị | cũ |

Ba lựa chọn thay thế NAT gateway: | Lựa chọn | Phù hợp | |---|---| | VPC endpoint cho dịch vụ AWS | không cần Internet chút nào | | NAT tập trung ở shared services VPC | nhiều VPC dùng chung | | Systems Manager cho vá lỗi | không cần đường ra Internet |

Systems Manager với VPC endpoint đáng cân nhắc:

Tạo interface endpoint cho ssm, ssmmessages, ec2messages
    + gateway endpoint cho S3
        ↓
    Vá lỗi và quản lý instance hoàn toàn không cần Internet

Ba lưu ý khi thiết kế VPC: | Lưu ý | Chi tiết | |---|---| | Route table riêng cho mỗi AZ | ← bắt buộc để dùng NAT cùng AZ | | CIDR đủ rộng cho tăng trưởng | mở rộng sau rất khó | | Ghi tài liệu sơ đồ mạng | |

Và một lời khuyên: hãy tạo gateway endpoint cho S3 và DynamoDB ngay khi dựng VPC. Chúng miễn phí hoàn toàn, và khi ứng dụng bắt đầu đọc ghi S3 nhiều, bạn đã tránh được khoản phí xử lý dữ liệu 0,045 USD mỗi GB của NAT gateway mà không phải làm gì thêm.

Câu 584 Design Cost-Optimized Architectures

An e-commerce company has deployed its application on several Amazon EC2 instances that are configured in a private subnet using IPv4. These Amazon EC2 instances read and write a huge volume of data to and from Amazon S3 in the same AWS region. The company has set up subnet routing to direct all the internet-bound traffic through a Network Address Translation gateway (NAT gateway). The company wants to build the most cost-optimal solution without impacting the application's ability to communicate with Amazon S3 or the internet.

As an AWS Certified Solutions Architect Associate, which of the following would you recommend?

  1. A

    Set up a Gateway Load Balancer (GWLB) endpoint for Amazon S3. Update the route table in the private subnet to direct the S3-bound traffic via the Gateway Load Balancer (GWLB) endpoint
  2. B

    Set up an egress-only internet gateway in the public subnet. Update the route table in the private subnet to route traffic to the internet gateway. Update the network ACL to allow the S3-bound traffic
  3. C

    Provision an internet gateway. Update the route table in the private subnet to route traffic to the internet gateway. Update the network ACL (NACL) to allow the S3-bound traffic
  4. D

    Set up a VPC gateway endpoint for Amazon S3. Attach an endpoint policy to the endpoint. Update the route table to direct the S3-bound traffic to the VPC endpoint
Xem giải thích

Đáp án

D — Dựng VPC gateway endpoint cho S3, gắn endpoint policy, và cập nhật route table để chuyển lưu lượng tới S3 qua VPC endpoint.

Vì sao đúng

Đề nêu vấn đề chi phí rõ ràng: lưu lượng lớn tới S3 đang đi qua NAT gateway.

Hiện tại:
    EC2 (private subnet) → NAT gateway → Internet → S3
        ↓
    Trả ~0,045 USD/GB phí xử lý dữ liệu của NAT
    + phí truyền dữ liệu

Gateway endpoint loại bỏ hoàn toàn khoản đó:

EC2 → gateway endpoint → S3
    ↓
    ✓ HOÀN TOÀN MIỄN PHÍ
    ✓ lưu lượng không rời mạng AWS
    ✓ không đi qua NAT gateway

Và với "huge volume of data", khoản tiết kiệm rất lớn:

10 TB mỗi tháng qua NAT gateway:
    10.000 GB × 0,045 USD = 450 USD/tháng

Qua gateway endpoint:
    0 USD

Cấu hình:

aws ec2 create-vpc-endpoint --vpc-id vpc-0abc   --service-name com.amazonaws.ap-northeast-1.s3   --route-table-ids rtb-private-a rtb-private-b   --policy-document file://endpoint-policy.json

Gateway endpoint thêm route vào bảng định tuyến:

Đích                          Target
10.0.0.0/16                   local
0.0.0.0/0                     nat-0abc          ← Internet khác
pl-xxxxx (prefix list của S3) vpce-0abc123      ← lưu lượng S3

AWS tự thêm route với prefix list của S3 — không phải khai tay dải IP.

Và vế "không ảnh hưởng khả năng ra Internet" được giữ:

Route 0.0.0.0/0 → NAT gateway VẪN CÒN
    → lưu lượng Internet khác vẫn đi qua NAT
    → chỉ lưu lượng S3 được tách sang endpoint

Endpoint policy để siết chặt thêm:

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

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

  • **B. Dựng egress-only internet gateway trong public subnet và trỏ route từ private subnet tới đó — đây là phương án gần nhất vì egress-only cũng là cổng chỉ đi ra, nhưng nó sai họ địa chỉ: egress-only internet gateway chỉ phục vụ IPv6. Đề nói rõ instance dùng IPv4.
  • **C. Cấp Internet Gateway và trỏ route từ private subnet tới đó — phá vỡ tính riêng tư: subnet có route tới IGW thì trở thành public subnet, và instance cần IP công cộng để hoạt động.
  • **A. Dựng Gateway Load Balancer endpoint cho S3 — sai loại endpoint: GWLB endpoint dùng để chuyển hướng lưu lượng qua thiết bị bảo mật (tường lửa, IDS), nó không phải cách truy cập S3.

Ghi nhớ

Ba loại VPC endpoint — bảng phải thuộc: | Loại | Dịch vụ | Cơ chế | Chi phí | |---|---|---|---| | Gateway endpoint | CHỈ S3 và DynamoDB | route table | MIỄN PHÍ | | Interface endpoint (PrivateLink) | hầu hết dịch vụ AWS | ENI có IP riêng | có phí | | Gateway Load Balancer endpoint | thiết bị bảo mật | chuyển hướng lưu lượng | có phí |

Gateway endpoint MIỄN PHÍ — nên tạo ở mọi VPC.

Gateway và Interface endpoint cho S3 — bảng so sánh: | | Gateway endpoint | Interface endpoint | |---|---|---| | Chi phí | MIỄN PHÍ | ~0,01 USD/giờ + 0,01 USD/GB | | Cơ chế | route table | ENI có IP riêng | | Truy cập từ TẠI CHỖ | ❌ KHÔNG | ✅ CÓ | | Truy cập từ VPC khác (peering) | ❌ | ✅ | | Security group | ❌ | ✅ |

Dòng "truy cập từ tại chỗ" là khác biệt quan trọng:

Gateway endpoint hoạt động qua ROUTE TABLE của VPC
    → chỉ tài nguyên TRONG VPC dùng được
    → máy tại chỗ qua Direct Connect KHÔNG dùng được
        ↓
    Muốn truy cập S3 riêng tư từ tại chỗ: interface endpoint

Ba lợi ích của gateway endpoint: | Lợi ích | Chi tiết | |---|---| | MIỄN PHÍ | không có phí giờ hay phí dữ liệu | | Tránh phí NAT Gateway | ~0,045 USD/GB | | Lưu lượng không ra Internet | an toàn hơn |

Ba cách kiểm soát truy cập: | Cách | Chi tiết | |---|---| | Endpoint policy | giới hạn bucket và hành động qua endpoint | | Bucket policy với aws:SourceVpce | chỉ cho phép qua endpoint cụ thể | | IAM policy | như thường |

Bucket policy với aws:SourceVpce rất mạnh:

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

Bucket chỉ truy cập được qua đúng endpoint đó — kể cả từ Internet cũng không vào được.

Ba cạm bẫy khi dùng VPC endpoint: | Cạm bẫy | Chi tiết | |---|---| | aws:SourceIp KHÔNG hoạt động qua endpoint | dùng aws:SourceVpce thay | | Chính sách chặn theo IP có thể chặn nhầm | kiểm tra lại sau khi bật endpoint | | Endpoint policy quá hẹp | chặn nhầm ứng dụng |

Cạm bẫy đầu tiên gây sự cố thật:

Bucket policy chặn theo aws:SourceIp
    → EC2 gọi S3 qua gateway endpoint
    → request KHÔNG có SourceIp công cộng
        ↓
    Bị TỪ CHỐI dù đúng ra phải được phép

Ba dịch vụ dùng interface endpoint phổ biến: | Dịch vụ | Khi VPC không có Internet | |---|---| | SSM, ssmmessages, ec2messages | quản lý và vá lỗi instance | | ECR api và dkr | kéo container image | | CloudWatch Logs | gửi log | | Secrets Manager, KMS | lấy bí mật và giải mã |

Ba lưu ý về prefix list của S3: | Lưu ý | Chi tiết | |---|---| | AWS tự cập nhật dải IP | không phải khai tay | | Xem được bằng describe-prefix-lists | | | Dùng được trong security group outbound | giới hạn ra S3 |

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

Ba lưu ý khi triển khai: | Lưu ý | Chi tiết | |---|---| | Gắn endpoint với ĐÚNG route table | của private subnet | | Kiểm chứng bằng cách thử gọi S3 | và xem metric NAT giảm | | Endpoint chỉ dùng được trong CÙNG Region | S3 ở Region khác vẫn qua NAT |

Dòng cuối đáng lưu ý: gateway endpoint chỉ định tuyến tới S3 của cùng Region — truy cập bucket ở Region khác vẫn đi qua NAT.

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | NAT gateway BytesOutToDestination | giảm mạnh sau khi bật endpoint | | Chi phí NAT trong Cost Explorer | xác nhận tiết kiệm | | Lỗi AccessDenied từ S3 | endpoint policy quá hẹp |

Và một lời khuyên: hãy so metric của NAT gateway trước và sau khi bật endpoint. Nếu lưu lượng NAT không giảm, nghĩa là route chưa được thêm vào đúng route table — và đó là lỗi cấu hình phổ biến nhất, vì gateway endpoint chỉ có tác dụng với những subnet mà route table của chúng được gắn vào.

Câu 585 Design High-Performing Architectures

A company has set up AWS Organizations to manage several departments running their own AWS accounts. The departments operate from different countries and are spread across various AWS Regions. The company wants to set up a consistent resource provisioning process across departments so that each resource follows pre-defined configurations such as using a specific type of Amazon EC2 instances, specific IAM roles for AWS Lambda functions, etc.

As a solutions architect, which of the following options would you recommend for this use-case?

  1. A

    Use AWS CloudFormation stacks to deploy the same template across AWS accounts and regions
  2. B

    Use AWS Resource Access Manager (AWS RAM) to deploy the same template across AWS accounts and regions
  3. C

    Use AWS CloudFormation StackSets to deploy the same template across AWS accounts and regions
  4. D

    Use AWS CloudFormation templates to deploy the same template across AWS accounts and regions
Xem giải thích

Đáp án

C — Dùng AWS CloudFormation StackSets để triển khai cùng một template trên nhiều tài khoản và nhiều Region.

Vì sao đúng

Đề nêu ba yêu cầu, và StackSets được thiết kế đúng cho bài toán này: | Yêu cầu | Cơ chế | |---|---| | Triển khai trên NHIỀU TÀI KHOẢN | StackSets nhắm tới nhiều tài khoản | | Trên NHIỀU REGION | StackSets nhắm tới nhiều Region | | Cấu hình nhất quán, định sẵn | template CloudFormation |

Khác biệt giữa Stack và StackSet:

CloudFormation Stack:
    → triển khai vào MỘT tài khoản, MỘT Region
    → muốn 20 tài khoản × 3 Region = phải chạy 60 lần

CloudFormation StackSet:
    → MỘT thao tác triển khai ra MỌI tài khoản và Region
    → và giữ chúng đồng bộ khi template thay đổi

Tạo StackSet:

aws cloudformation create-stack-set   --stack-set-name chuan-hoa-tai-nguyen   --template-body file://template.yaml   --permission-model SERVICE_MANAGED   --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false   --capabilities CAPABILITY_NAMED_IAM

Và triển khai tới toàn bộ OU:

aws cloudformation create-stack-instances   --stack-set-name chuan-hoa-tai-nguyen   --deployment-targets OrganizationalUnitIds=ou-abc-12345678   --regions ap-northeast-1 eu-west-1 us-east-1   --operation-preferences MaxConcurrentPercentage=25,FailureTolerancePercentage=10

Ba lợi ích quan trọng: | Lợi ích | Chi tiết | |---|---| | auto-deployment | tài khoản MỚI thêm vào OU tự nhận stack | | Cập nhật tập trung | sửa template một chỗ, áp cho mọi nơi | | Phát hiện lệch cấu hình (drift) | biết nơi nào bị sửa tay |

Điểm đầu tiên rất quan trọng với công ty đang mở rộng:

Phòng ban mới tạo tài khoản AWS
    → tự động thêm vào OU
    → StackSet TỰ triển khai cấu hình chuẩn
        ↓
    Không ai phải nhớ làm gì

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

  • **A. Dùng CloudFormation Stack để triển khai cùng template trên nhiều tài khoản và Region — đây là phương án gần nhất và về nguyên tắc là làm được, nhưng nó phải chạy thủ công ở TỪNG tài khoản và TỪNG Region: với hàng chục tài khoản và nhiều Region, đó là hàng trăm lần triển khai phải theo dõi và giữ đồng bộ bằng tay.
  • **D. Dùng CloudFormation template để triển khai — template chỉ là TỆP MÔ TẢ, nó không phải cơ chế triển khai. Bạn vẫn cần Stack hoặc StackSet để thực thi nó.
  • **B. Dùng AWS Resource Access Manager (RAM) — sai chức năng: RAM CHIA SẺ tài nguyên đã có (subnet, Transit Gateway, Resolver rule) giữa các tài khoản. Nó không triển khai hay tạo tài nguyên mới.

Ghi nhớ

Stack, StackSet và Template — bảng phân biệt: | Khái niệm | Là gì | |---|---| | Template | TỆP mô tả tài nguyên (YAML hoặc JSON) | | Stack | thực thể triển khai trong MỘT tài khoản, MỘT Region | | StackSet | tập hợp stack trên NHIỀU tài khoản và Region |

Hai mô hình quyền của StackSets: | Mô hình | Đặc điểm | |---|---| | SELF_MANAGED | tự tạo IAM role ở tài khoản quản trị và tài khoản đích | | SERVICE_MANAGED | tích hợp AWS Organizations, tự lo quyền ← khuyến nghị |

SERVICE_MANAGED đơn giản hơn nhiều:

Bật tin cậy với Organizations:
    aws cloudformation activate-organizations-access
        ↓
    Nhắm tới OU thay vì liệt kê từng tài khoản
    Không phải tạo IAM role thủ công

Ba tuỳ chọn triển khai quan trọng: | Tuỳ chọn | Việc | |---|---| | MaxConcurrentPercentage | bao nhiêu tài khoản triển khai cùng lúc | | FailureTolerancePercentage | dừng nếu quá nhiều tài khoản lỗi | | RegionConcurrencyType | Region triển khai tuần tự hay song song |

Triển khai từ từ là thực hành tốt:

MaxConcurrentPercentage=25, FailureTolerance=10
    → triển khai 25% tài khoản mỗi đợt
    → lỗi quá 10% thì DỪNG
        ↓
    Template sai không phá hỏng toàn bộ tổ chức

Ba khái niệm của StackSets: | Khái niệm | Việc | |---|---| | Stack instance | một stack ở một (tài khoản, Region) cụ thể | | Deployment target | OU hoặc danh sách tài khoản | | Operation | một lần tạo, cập nhật hoặc xoá |

Ba trường hợp dùng StackSets: | Trường hợp | Ví dụ | |---|---| | Chuẩn hoá cấu hình bảo mật | CloudTrail, Config, GuardDuty ở mọi tài khoản | | IAM role chuẩn | vai trò kiểm toán, vai trò cho CI/CD | | Cấu hình mạng chuẩn | VPC, subnet, flow log | | Guardrail và tag policy | ← đúng bài toán trong đề |

Và với yêu cầu "loại instance EC2 cụ thể, IAM role cụ thể cho Lambda", StackSets kết hợp với SCP:

StackSets: TẠO tài nguyên chuẩn (IAM role, launch template)
SCP:       CHẶN việc tạo tài nguyên không đúng chuẩn
        ↓
    Hai cơ chế bổ sung nhau

Ba công cụ quản trị nhiều tài khoản: | Công cụ | Việc | |---|---| | CloudFormation StackSets | triển khai tài nguyên ← câu này | | Service Control Policy | giới hạn quyền tối đa | | AWS Control Tower | landing zone với guardrail dựng sẵn |

Control Tower đáng cân nhắc:

Control Tower dùng StackSets bên dưới, và cung cấp:
    ✓ guardrail dựng sẵn (preventive và detective)
    ✓ Account Factory tạo tài khoản theo chuẩn
    ✓ tài khoản log và audit riêng
        ↓
    Ít công hơn tự dựng bằng StackSets thuần

Ba lưu ý về drift detection: | Lưu ý | Chi tiết | |---|---| | Phát hiện tài nguyên bị sửa NGOÀI CloudFormation | | | Chạy được ở mức StackSet | biết tài khoản nào lệch | | Không tự sửa | phải chạy cập nhật để đưa về chuẩn |

aws cloudformation detect-stack-set-drift   --stack-set-name chuan-hoa-tai-nguyen

Ba lưu ý về template: | Lưu ý | Chi tiết | |---|---| | Dùng Parameters cho khác biệt theo môi trường | | | Dùng Mappings cho giá trị theo Region | ví dụ id AMI | | Conditions cho tài nguyên chỉ tạo ở một số nơi | |

Mappings cho AMI theo Region:

Mappings:
  AmiTheoRegion:
    ap-northeast-1: {Ami: ami-0abc}
    eu-west-1:      {Ami: ami-0def}
Resources:
  MayChu:
    Properties:
      ImageId: !FindInMap [AmiTheoRegion, !Ref "AWS::Region", Ami]

Ba lựa chọn thay thế cho CloudFormation: | Lựa chọn | Đặc điểm | |---|---| | AWS CDK | định nghĩa hạ tầng bằng ngôn ngữ lập trình, sinh ra CloudFormation | | Terraform | đa đám mây, cộng đồng lớn | | AWS SAM | chuyên cho serverless |

Và một lời khuyên: hãy triển khai StackSet vào một OU thử nghiệm trước, với FailureTolerancePercentage thấp. Một template sai áp cho hàng chục tài khoản sản xuất cùng lúc có thể tạo ra sự cố diện rộng — và cơ chế triển khai theo đợt của StackSets tồn tại chính vì lý do đó.

Câu 586 Design High-Performing Architectures

A healthcare company has deployed its web application on Amazon Elastic Container Service (Amazon ECS) container instances running behind an Application Load Balancer. The website slows down when the traffic spikes and the website availability is also reduced. The development team has configured Amazon CloudWatch alarms to receive notifications whenever there is an availability constraint so the team can scale out resources. The company wants an automated solution to respond to such events.

Which of the following addresses the given use case?

  1. A

    Configure AWS Auto Scaling to scale out the Amazon ECS cluster when the CloudWatch alarm's CPU utilization rises above a threshold
  2. B

    Configure AWS Auto Scaling to scale out the Amazon ECS cluster when the ECS service's CPU utilization rises above a threshold
  3. C

    Configure AWS Auto Scaling to scale out the Amazon ECS cluster when the Application Load Balancer's target group's CPU utilization rises above a threshold
  4. D

    Configure AWS Auto Scaling to scale out the Amazon ECS cluster when the Application Load Balancer's CPU utilization rises above a threshold
Xem giải thích

Đáp án

B — Cấu hình AWS Auto Scaling mở rộng cụm ECS khi mức dùng CPU của ECS SERVICE vượt ngưỡng.

Vì sao đúng

Điểm mấu chốt: metric phải phản ánh đúng thứ cần co giãn, và với ECS đó là mức dùng CPU của service.

ECS Service CPU utilization:
    = tổng CPU mà các task của service đang dùng
      ÷ tổng CPU đã cấp cho service
        ↓
    Đây là chỉ báo trực tiếp cho việc "service có cần thêm task không"

Cấu hình ECS Service Auto Scaling:

aws application-autoscaling register-scalable-target   --service-namespace ecs   --resource-id service/cum-ung-dung/dich-vu-web   --scalable-dimension ecs:service:DesiredCount   --min-capacity 2 --max-capacity 20

aws application-autoscaling put-scaling-policy   --policy-name giu-cpu-70 --service-namespace ecs   --resource-id service/cum-ung-dung/dich-vu-web   --scalable-dimension ecs:service:DesiredCount   --policy-type TargetTrackingScaling   --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"}}'

Và ba metric dựng sẵn của ECS Service Auto Scaling: | Metric | Đo gì | |---|---| | ECSServiceAverageCPUUtilization | CPU trung bình của service ← câu này | | ECSServiceAverageMemoryUtilization | bộ nhớ trung bình | | ALBRequestCountPerTarget | số request mỗi target — thường phản ánh tải tốt hơn |

Vì sao đây là giải pháp "tự động" mà đề hỏi:

Hiện tại:
    CloudWatch alarm → thông báo → CON NGƯỜI mở rộng thủ công

Sau khi cấu hình:
    Metric vượt ngưỡng → Application Auto Scaling TỰ tăng desiredCount
        ↓
    Không cần ai can thiệp

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

  • **A. Mở rộng khi mức dùng CPU của CloudWatch alarm vượt ngưỡng — đây là phương án gần nhất và gần đúng về ý tưởng, nhưng nó diễn đạt sai: "CPU utilization của CloudWatch alarm" không phải khái niệm có thật. CloudWatch alarm theo dõi metric, bản thân nó không có mức dùng CPU.
  • **C. Mở rộng khi CPU utilization của target group vượt ngưỡng — không tồn tại metric như vậy: target group của ALB có metric về số request, số target khoẻ mạnh, độ trễ — không có metric CPU.
  • **D. Mở rộng khi CPU utilization của Application Load Balancer vượt ngưỡng — cũng không tồn tại: ALB là dịch vụ được quản lý, AWS không công bố metric CPU của nó.

Ghi nhớ

Hai tầng co giãn của ECS — bảng phải thuộc: | Tầng | Co giãn gì | Cơ chế | |---|---|---| | ECS Service Auto Scaling | SỐ TASK của service | Application Auto Scaling ← câu này | | Cluster Auto Scaling | SỐ EC2 INSTANCE trong cụm | Capacity Provider + ASG |

Với Fargate, chỉ cần tầng thứ nhất — không có instance nào để co giãn.

Ba loại scaling policy của ECS Service: | Loại | Đặc điểm | |---|---| | Target tracking | giữ metric ở giá trị mục tiêu — đơn giản nhất | | Step scaling | ngưỡng + các bậc điều chỉnh | | Scheduled scaling | theo thời điểm |

Ba metric dựng sẵn cho target tracking: | Metric | Dùng khi | |---|---| | ECSServiceAverageCPUUtilization | tải nặng CPU | | ECSServiceAverageMemoryUtilization | tải nặng bộ nhớ | | ALBRequestCountPerTarget | web — phản ánh tải thật tốt hơn CPU |

ALBRequestCountPerTarget thường là lựa chọn tốt hơn cho web:

CPU tăng SAU KHI request đã tồn đọng
    → phản ứng muộn

Số request mỗi target tăng NGAY khi lưu lượng tăng
    → phản ứng sớm hơn

Ba tham số quan trọng: | Tham số | Việc | |---|---| | TargetValue | giá trị cần giữ | | ScaleInCooldown / ScaleOutCooldown | thời gian chờ giữa hai lần co giãn | | DisableScaleIn | chỉ mở rộng, không thu hẹp |

Cooldown quan trọng để tránh dao động:

ScaleOutCooldown ngắn (60 giây):  phản ứng nhanh với đỉnh tải
ScaleInCooldown dài (300 giây):   thu hẹp thận trọng

Ba khái niệm của ECS: | Khái niệm | Việc | |---|---| | Task definition | bản mô tả container (image, CPU, bộ nhớ, biến môi trường) | | Task | một thực thể đang chạy của task definition | | Service | duy trì số task mong muốn, tích hợp load balancer |

Hai launch type của ECS: | Launch type | Bạn quản lý | |---|---| | Fargate | KHÔNG có máy nào | | EC2 | instance, AMI, vá lỗi, cluster auto scaling |

Với Fargate, bài toán trong đề đơn giản hơn nhiều — chỉ cần Service Auto Scaling.

Cluster Auto Scaling cho launch type EC2:

aws ecs create-capacity-provider --name nha-cung-cap-nang-luc   --auto-scaling-group-provider '{
    "autoScalingGroupArn": "<arn-asg>",
    "managedScaling": {"status":"ENABLED","targetCapacity":80},
    "managedTerminationProtection": "ENABLED"}'

Capacity Provider tự:
    ✓ tăng số instance khi task không xếp chỗ được
    ✓ giảm khi thừa năng lực
    ✓ bảo vệ instance đang chạy task khỏi bị chấm dứt

Ba cấu hình của service để sẵn sàng cao: | Cấu hình | Chi tiết | |---|---| | desiredCount tối thiểu 2 | chịu được mất một task | | Trải qua nhiều AZ | subnet ở nhiều AZ | | Health check của target group | phát hiện task hỏng |

Ba cấu hình triển khai: | Cấu hình | Chi tiết | |---|---| | minimumHealthyPercent | bao nhiêu phần trăm task phải khoẻ trong lúc triển khai | | maximumPercent | trần tạm thời khi triển khai | | Deployment circuit breaker | tự rollback khi triển khai thất bại |

Circuit breaker rất đáng bật:

--deployment-configuration '{
  "deploymentCircuitBreaker": {"enable": true, "rollback": true},
  "minimumHealthyPercent": 100, "maximumPercent": 200}'

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CPUUtilization của service | tải hiện tại | | RunningTaskCount | số task đang chạy | | UnhealthyHostCount của target group | task không phục vụ được |

Ba lưu ý khi co giãn ECS: | Lưu ý | Chi tiết | |---|---| | Task cần thời gian khởi động | đặt health check grace period | | Nếu dùng EC2, cụm phải có đủ chỗ | cần Cluster Auto Scaling | | maxCapacity đủ lớn | chạm trần thì không mở rộng thêm được |

Và một lời khuyên: hãy cân nhắc chuyển sang Fargate nếu đang dùng launch type EC2. Nó loại bỏ hẳn tầng Cluster Auto Scaling — một nguồn phức tạp và một chỗ có thể gây nghẽn khi task không xếp được chỗ vì cụm chưa kịp mở rộng.

Câu 587 Design High-Performing Architectures

An e-commerce company uses Microsoft Active Directory to provide users and groups with access to resources on the on-premises infrastructure. The company has extended its IT infrastructure to AWS in the form of a hybrid cloud. The engineering team at the company wants to run directory-aware workloads on AWS for a SQL Server-based application. The team also wants to configure a trust relationship to enable single sign-on (SSO) for its users to access resources in either domain.

As a solutions architect, which of the following AWS services would you recommend for this use-case?

  1. A

    AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD)
  2. B

    Simple Active Directory (Simple AD)
  3. C

    Amazon Cloud Directory
  4. D

    Active Directory Connector
Xem giải thích

Đáp án

A — AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD).

Vì sao đúng

Đề nêu ba yêu cầu, và Managed Microsoft AD là lựa chọn duy nhất thoả cả ba: | Yêu cầu | Cơ chế | |---|---| | Chạy tải NHẬN BIẾT THƯ MỤC (directory-aware) | là AD thật, hỗ trợ LDAP và Kerberos đầy đủ | | Ứng dụng dựa trên SQL Server | SQL Server cần AD cho Windows Authentication | | Thiết lập QUAN HỆ TIN CẬY (trust) cho SSO | CHỈ Managed Microsoft AD hỗ trợ trust |

Vế thứ ba là điểm phân biệt tuyệt đối:

Quan hệ tin cậy (trust relationship) đòi hỏi
    HAI DOMAIN THẬT nói chuyện với nhau
        ↓
    AD Connector KHÔNG phải domain — nó chỉ là cầu nối
    Simple AD dựa trên Samba — KHÔNG lập trust với AD thật được
        ↓
    Chỉ Managed Microsoft AD là AD thật do Microsoft cung cấp

Cấu hình:

aws ds create-microsoft-ad --name aws.congty.local   --password '<mat-khau>' --edition Enterprise   --vpc-settings VpcId=vpc-0abc,SubnetIds=subnet-a,subnet-b

Và thiết lập trust hai chiều:

aws ds create-trust --directory-id d-1234567890   --remote-domain-name congty.local   --trust-password '<mat-khau-trust>'   --trust-direction Two-Way   --trust-type Forest   --conditional-forwarder-ip-addrs 10.100.0.10 10.100.0.11

Kết quả:

Người dùng ở domain TẠI CHỖ
    → đăng nhập được vào tài nguyên trên AWS
Người dùng ở domain trên AWS
    → truy cập được tài nguyên tại chỗ
        ↓
    Đó chính là single sign-on hai chiều mà đề yêu cầu

Và Managed Microsoft AD hỗ trợ nhiều dịch vụ AWS: | Dịch vụ | Dùng AD để | |---|---| | RDS for SQL Server | Windows Authentication | | FSx for Windows File Server | phân quyền NTFS | | WorkSpaces, AppStream | đăng nhập người dùng | | EC2 Windows | tham gia domain |

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

  • **D. Active Directory Connector (AD Connector) — đây là phương án gần nhất và thực sự cho phép dùng AD tại chỗ với AWS, nhưng nó không lập được quan hệ tin cậy: AD Connector chỉ chuyển tiếp yêu cầu xác thực về AD tại chỗ, nó không phải một domain. Và nó không hỗ trợ tải directory-aware như RDS for SQL Server với Windows Authentication.
  • **B. Simple AD — không hỗ trợ trust: Simple AD dựa trên Samba 4, tương thích một phần với AD nhưng không lập được quan hệ tin cậy với Microsoft AD thật, và thiếu nhiều tính năng (trust, MFA, PowerShell của AD).
  • **C. Amazon Cloud Directory — sai loại dịch vụ hoàn toàn: đây là kho thư mục dạng đồ thị cho dữ liệu phân cấp (danh mục thiết bị, tổ chức người dùng của ứng dụng), không phải Active Directory và không xác thực Windows.

Ghi nhớ

Ba lựa chọn của AWS Directory Service — bảng phải thuộc: | Lựa chọn | Là gì | Trust | Dữ liệu trên AWS | |---|---|---|---| | AWS Managed Microsoft AD | AD THẬT của Microsoft | ✅ | ✅ hoạt động độc lập | | AD Connector | CẦU NỐI, chuyển tiếp xác thực | ❌ | ❌ | | Simple AD | tương thích Samba | ❌ | ✅ |

Từ khoá nhận diện:

"trust relationship", "directory-aware workloads", "SQL Server Windows Auth" → Managed Microsoft AD "use existing on-prem AD, no data on AWS" → AD Connector "simple, low-cost, basic AD features" → Simple AD "hierarchical data for applications" → Cloud Directory

Ba đặc điểm của Managed Microsoft AD: | Đặc điểm | Chi tiết | |---|---| | Là Windows Server AD thật | hỗ trợ mọi tính năng của AD | | AWS quản lý domain controller | vá lỗi, sao lưu, giám sát | | Hoạt động ĐỘC LẬP với tại chỗ | mất kết nối vẫn xác thực được |

Điểm cuối là khác biệt lớn với AD Connector:

AD Connector:
    → VPN hoặc Direct Connect đứt
    → KHÔNG xác thực được gì trên AWS

Managed Microsoft AD:
    → có domain controller riêng trên AWS
    → vẫn hoạt động khi mất kết nối

Hai phiên bản của Managed Microsoft AD: | Phiên bản | Quy mô | |---|---| | Standard | ~5.000 người dùng, 1 GB dữ liệu thư mục | | Enterprise | ~500.000 người dùng, 17 GB |

Ba loại quan hệ tin cậy: | Loại | Chi tiết | |---|---| | One-way (incoming) | domain kia tin domain này | | One-way (outgoing) | domain này tin domain kia | | Two-way | cả hai tin nhau — cho SSO đầy đủ ← câu này |

Và trust cần cấu hình ở CẢ HAI phía:

Phía AWS:  aws ds create-trust
Phía tại chỗ: tạo trust tương ứng trong Active Directory Domains and Trusts
        ↓
    Dùng CÙNG một mật khẩu trust

Ba yêu cầu mạng cho trust: | Yêu cầu | Chi tiết | |---|---| | Kết nối tới AD tại chỗ | VPN hoặc Direct Connect | | Mở các cổng AD | 389/636 (LDAP), 88 (Kerberos), 445 (SMB), 53 (DNS), 135, 49152–65535 (RPC) | | Conditional forwarder cho DNS | hai chiều |

Dải cổng RPC động là chi tiết hay bị bỏ sót — thiếu nó thì trust thiết lập được nhưng xác thực thất bại.

Ba trường hợp dùng Managed Microsoft AD: | Trường hợp | Chi tiết | |---|---| | RDS for SQL Server với Windows Authentication | ← câu này | | FSx for Windows File Server | phân quyền NTFS | | EC2 Windows tham gia domain | quản lý tập trung | | WorkSpaces, AppStream 2.0 | đăng nhập người dùng |

Cấu hình RDS SQL Server với AD:

aws rds create-db-instance --db-instance-identifier db-sql   --engine sqlserver-se --domain d-1234567890   --domain-iam-role-name rds-directoryservice-access-role

Ba lưu ý về sẵn sàng cao: | Lưu ý | Chi tiết | |---|---| | Managed Microsoft AD tự dựng 2 domain controller | ở hai AZ | | Thêm domain controller nếu cần | mở rộng theo tải | | Sao lưu tự động hằng ngày | AWS quản lý |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tính theo giờ | Standard rẻ hơn Enterprise đáng kể | | Thêm domain controller | tính riêng | | AD Connector rẻ hơn | nhưng thiếu tính năng |

Ba lựa chọn khác cho danh tính trên AWS: | Lựa chọn | Phù hợp | |---|---| | Managed Microsoft AD | tải Windows, cần AD thật ← câu này | | IAM Identity Center | truy cập console và CLI của con người | | Cognito | người dùng của ứng dụng |

Và Identity Center kết hợp được với Managed Microsoft AD:

Managed Microsoft AD làm nguồn danh tính
    → Identity Center dùng nhóm AD để gán permission set
        ↓
    Một danh tính cho cả tài nguyên Windows lẫn console AWS

Và một lời khuyên: hãy kiểm chứng trust bằng cách đăng nhập thật từ một tài khoản tại chỗ vào một máy Windows trên AWS. Trust thiết lập thành công không đảm bảo xác thực hoạt động — thiếu một cổng RPC hoặc một conditional forwarder DNS là đủ để trust hiện trạng thái "verified" mà người dùng vẫn không đăng nhập được.

Câu 588 Design High-Performing Architectures

A media startup is looking at hosting their web application on AWS Cloud. The application will be accessed by users from different geographic regions of the world to upload and download video files that can reach a maximum size of 10 gigabytes. The startup wants the solution to be cost-effective and scalable with the lowest possible latency for a great user experience.

As a Solutions Architect, which of the following will you suggest as an optimal solution to meet the given requirements?

  1. A

    Use Amazon S3 for hosting the web application and use Amazon CloudFront for faster distribution of content to geographically dispersed users
  2. B

    Use Amazon EC2 with Amazon ElastiCache for faster distribution of content, while Amazon S3 can be used as a storage service
  3. C

    Use Amazon EC2 with AWS Global Accelerator for faster distribution of content, while using Amazon S3 as storage service
  4. D

    Use Amazon S3 for hosting the web application and use Amazon S3 Transfer Acceleration (Amazon S3TA) to reduce the latency that geographically dispersed users might face
Xem giải thích

Đáp án

D — Dùng Amazon S3 để lưu ứng dụng web và dùng S3 Transfer Acceleration (S3TA) để giảm độ trễ cho người dùng ở xa.

Vì sao đúng

Đề nêu ba dữ kiện, và chúng dẫn tới S3 + S3TA: | Dữ kiện | Kết luận | |---|---| | Người dùng TẢI LÊN và TẢI XUỐNG tệp video | cần tăng tốc CẢ HAI chiều | | Tệp tới 10 GB | multipart upload và S3TA | | Người dùng ở nhiều vùng địa lý | khoảng cách là nút thắt chính |

Vế "tải lên" là điểm phân biệt:

CloudFront tối ưu cho TẢI XUỐNG (đệm nội dung)
S3TA tối ưu cho TẢI LÊN (vào mạng AWS sớm nhất)
        ↓
    Đề nêu rõ "upload AND download video files"
    → S3TA giải quyết chiều mà CloudFront không giúp được

Cách S3TA hoạt động:

Không có S3TA:
    Người dùng ở Tokyo → Internet công cộng (nhiều chặng, mất gói)
                       → bucket ở Mỹ

Có S3TA:
    Người dùng ở Tokyo → điểm biên CloudFront tại Tokyo (rất gần)
                       → MẠNG XƯƠNG SỐNG RIÊNG của AWS
                       → bucket ở Mỹ
        ↓
    Nhanh hơn 50–500% với đường truyền xa

Bật S3TA:

aws s3api put-bucket-accelerate-configuration   --bucket kho-video --accelerate-configuration Status=Enabled

aws s3 cp video.mp4 s3://kho-video/   --endpoint-url https://kho-video.s3-accelerate.amazonaws.com

Và tệp 10 GB bắt buộc dùng multipart:

Giới hạn một lần PUT: 5 GB
    → tệp 10 GB PHẢI dùng multipart upload
        ↓
    AWS CLI và SDK tự làm điều này

Và S3TA chỉ tính phí khi thực sự nhanh hơn — đó là đặc điểm giá đáng nhớ.

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

  • **A. Dùng S3 với CloudFront để phân phối nội dung nhanh hơn — đây là phương án gần nhất và là lựa chọn tuyệt vời cho chiều TẢI XUỐNG, nhưng nó không giải quyết chiều tải lên: CloudFront đệm nội dung để phục vụ, nó không tăng tốc việc đưa tệp 10 GB vào S3. Đề nêu rõ cả hai chiều.
  • **C. Dùng EC2 với Global Accelerator, S3 làm kho lưu trữ — thêm hạ tầng không cần thiết: đưa tệp 10 GB qua EC2 làm trung gian vừa tốn băng thông vừa tốn chi phí, trong khi S3 nhận trực tiếp được.
  • **B. Dùng EC2 với ElastiCache, S3 làm kho lưu trữ — sai công cụ: ElastiCache là bộ đệm trong bộ nhớ cho dữ liệu nhỏ, không dùng để phân phối tệp video hàng GB.

Ghi nhớ

Ba kỹ thuật tăng tốc S3 — giải quyết ba nút thắt khác nhau: | Kỹ thuật | Nút thắt | Chiều | |---|---|---| | Multipart upload | kích thước tệp | tải lên | | S3 Transfer Acceleration | khoảng cách địa lý | tải lên (và tải xuống) | | CloudFront | khoảng cách địa lý | tải xuống |

Nhầm lẫn giữa S3TA và CloudFront là lỗi phổ biến:

CloudFront: ĐỆM nội dung ở biên → tối ưu TẢI XUỐNG lặp lại
S3TA:       ĐƯỜNG ĐI qua mạng AWS → tối ưu TẢI LÊN
        ↓
    Hai thứ khác nhau, và dùng CÙNG NHAU được

Ba đặc điểm của S3TA: | Đặc điểm | Chi tiết | |---|---| | Dùng mạng điểm biên của CloudFront | vào mạng AWS sớm nhất | | Endpoint riêng | bucket.s3-accelerate.amazonaws.com | | CHỈ tính phí khi THỰC SỰ nhanh hơn | AWS tự đo |

Và có công cụ đo trước khi bật:

s3-accelerate-speedtest.s3-accelerate.amazonaws.com
    → so tốc độ có và không có S3TA từ vị trí của bạn

Ba trường hợp S3TA KHÔNG giúp: | Trường hợp | Lý do | |---|---| | Client ở CÙNG Region với bucket | đã gần rồi | | Tệp rất nhỏ | chi phí thiết lập lấn át | | Nghẽn ở băng thông của chính người dùng | S3TA không nới được |

Ba ràng buộc của S3TA: | Ràng buộc | Chi tiết | |---|---| | Tên bucket KHÔNG chứa dấu chấm | yêu cầu của endpoint | | Tên tuân thủ quy tắc DNS | | | Mất tới 20 phút để có hiệu lực | sau khi bật |

Ba ngưỡng của multipart upload: | Ngưỡng | Giá trị | |---|---| | Bắt buộc | trên 5 GB | | AWS khuyến nghị | trên 100 MB | | Số phần tối đa | 10.000 | | Kích thước phần | 5 MB – 5 GB |

Và phần dở dang tính phí mãi mãi:

{"Rules": [{"Status": "Enabled",
  "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}]}

Bắt buộc có với tệp video — mỗi lần tải lên thất bại để lại hàng GB tính tiền.

Ba tham số của AWS CLI ảnh hưởng tốc độ:

aws configure set default.s3.multipart_threshold 100MB
aws configure set default.s3.multipart_chunksize 100MB
aws configure set default.s3.max_concurrent_requests 20
aws configure set default.s3.use_accelerate_endpoint true

Kiến trúc đầy đủ cho ứng dụng chia sẻ video:

Tải lên:
    Trình duyệt → presigned URL → S3 (qua S3TA endpoint)
        ↓ S3 event
    Lambda → MediaConvert (chuyển mã nhiều độ phân giải)

Tải xuống:
    Người xem → CloudFront → S3

Presigned URL là kỹ thuật quan trọng:

url = s3.generate_presigned_url('put_object',
    Params={'Bucket': 'kho-video', 'Key': f'{ma_nguoi_dung}/{ma_video}.mp4'},
    ExpiresIn=3600)

Lợi ích:
    ✓ video KHÔNG đi qua máy chủ ứng dụng
    ✓ không tốn băng thông và CPU của EC2
    ✓ tải lên nhanh hơn

Ba lớp lưu trữ S3 cho video: | Lớp | Dùng khi | |---|---| | Standard | video mới, xem nhiều | | Intelligent-Tiering | mẫu truy cập khó đoán — không có phí truy xuất | | Standard-IA, Glacier IR | video cũ |

Intelligent-Tiering rất phù hợp với nội dung người dùng:

Video cũ bỗng được chia sẻ nhiều (lan truyền)
    → Intelligent-Tiering tự đưa về tầng nóng
    → KHÔNG có phí truy xuất bất ngờ

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | S3TA | ~0,04–0,08 USD/GB thêm vào | | Truyền vào S3 | MIỄN PHÍ (không tính S3TA) | | Truyền ra qua CloudFront | rẻ hơn từ S3 trực tiếp |

Ba lựa chọn thay thế cho tải lên khối lượng lớn: | Lựa chọn | Phù hợp | |---|---| | S3TA + multipart | tệp lẻ từ người dùng cuối ← câu này | | DataSync | đồng bộ thư mục định kỳ | | Bucket ở Region gần + replication | nhiều người dùng ở một khu vực |

Và một lời khuyên: hãy dùng CẢ S3TA cho tải lên LẪN CloudFront cho tải xuống. Đề chỉ cho chọn một, nhưng trong kiến trúc thật hai thứ này giải quyết hai chiều khác nhau và không loại trừ nhau — bỏ CloudFront nghĩa là mỗi lượt xem video đều phải kéo từ bucket gốc, vừa chậm vừa đắt.

Câu 589 Design High-Performing Architectures

A financial services company is modernizing its analytics platform on AWS. Their legacy data processing scripts, built for both Windows and Linux environments, require shared access to a file system that supports Windows ACLs and SMB protocol for compatibility with existing Windows workloads. At the same time, their Linux-based applications need to read from and write to the same shared storage to maintain cross-platform consistency. The solutions architect needs to design a storage solution that allows both Windows and Linux EC2 instances to access the shared file system simultaneously, while preserving Windows-specific features like NTFS permissions and Active Directory (AD) integration.

Which solution will best meet these requirements?

  1. A

    Deploy Amazon FSx for Windows File Server and mount it using the SMB protocol from both Windows and Linux EC2 instances
  2. B

    Create an S3 bucket and mount it on EC2 instances using Mountpoint for Amazon S3, managing access through IAM policies to support both Windows and Linux workloads
  3. C

    Deploy Amazon FSx for Lustre and mount the file system using a POSIX-compliant client from both platforms
  4. D

    Use Amazon EFS with the Standard storage class and mount the file system using NFS from both Windows and Linux instances
Xem giải thích

Đáp án

A — Triển khai Amazon FSx for Windows File Server và mount bằng giao thức SMB từ CẢ EC2 Windows LẪN Linux.

Vì sao đúng

Đề nêu bốn yêu cầu, và FSx for Windows đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Hỗ trợ Windows ACL và giao thức SMB | FSx for Windows chạy Windows Server thật | | Linux đọc ghi CÙNG dữ liệu đó | Linux mount SMB được bằng cifs-utils | | Giữ quyền NTFS | ACL của NTFS nguyên vẹn | | Tích hợp Active Directory | tham gia domain trực tiếp |

Điểm mà nhiều người bỏ qua: Linux mount SMB được.

sudo yum install -y cifs-utils
sudo mount -t cifs //amznfsxabc123.congty.local/share /du-lieu   -o vers=3.0,sec=krb5,cruid=$(id -u),multiuser

Linux không chỉ dùng NFS
    → giao thức SMB được hỗ trợ đầy đủ qua cifs-utils
    → xác thực Kerberos với AD
        ↓
    Cả Windows lẫn Linux truy cập CÙNG một file share

Và đó là cách duy nhất giữ được ACL của NTFS:

Yêu cầu: "preserving Windows-specific features like NTFS permissions
          and Active Directory integration"
        ↓
    Chỉ hệ thống tệp dựa trên Windows mới giữ được
    → EFS (NFS thuần) KHÔNG có khái niệm ACL của NTFS

Cấu hình:

aws fsx create-file-system --file-system-type WINDOWS   --storage-capacity 2048 --storage-type SSD   --subnet-ids subnet-a subnet-b --security-group-ids sg-fsx   --windows-configuration '{
    "ActiveDirectoryId": "d-1234567890",
    "ThroughputCapacity": 512,
    "DeploymentType": "MULTI_AZ_1"}'

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

  • **D. Dùng Amazon EFS với lớp Standard, mount bằng NFS từ cả Windows lẫn Linux — đây là phương án gần nhất và EFS là dịch vụ tệp chia sẻ tốt, nhưng nó thiếu hai thứ đề yêu cầu: EFS chỉ hỗ trợ NFS, không hỗ trợ SMB, và không có ACL của NTFS hay tích hợp AD. Windows mount NFS được nhưng mất hoàn toàn mô hình quyền Windows.
  • **C. Dùng FSx for Lustre với client POSIX — sai loại hệ thống tệp: Lustre dành cho HPC trên Linux, không hỗ trợ SMB, không có ACL của NTFS, không tích hợp AD.
  • **B. Dùng S3 với Mountpoint for Amazon S3 và IAM policy — không phải hệ thống tệp đầy đủ: Mountpoint hỗ trợ một tập con thao tác tệp, không có ngữ nghĩa POSIX hay ACL đầy đủ, và không tích hợp AD.

Ghi nhớ

Bốn dịch vụ FSx theo giao thức — bảng phải thuộc: | Dịch vụ | Giao thức | ACL NTFS và AD | |---|---|---| | FSx for Windows File Server | SMB | ✅ ← câu này | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | ✅ đa giao thức | | FSx for Lustre | Lustre (POSIX) | ❌ | | FSx for OpenZFS | NFS | ❌ | | Amazon EFS | NFS | ❌ |

Từ khoá nhận diện:

"NTFS permissions", "SMB", "Active Directory" → FSx for Windows hoặc FSx for ONTAP "both SMB and NFS natively on same data" → FSx for ONTAP "NFS only, Linux, auto-scaling" → EFS "HPC, parallel" → FSx for Lustre

FSx for Windows và FSx for ONTAP — chọn cái nào: | | FSx for Windows | FSx for ONTAP | |---|---|---| | SMB nguyên bản | ✅ | ✅ | | NFS nguyên bản | ❌ (Linux dùng SMB) | ✅ | | ACL NTFS | ✅ | ✅ | | Tự phân tầng dữ liệu lạnh | ❌ | ✅ | | Đơn giản hơn | ✅ | phức tạp hơn |

Với yêu cầu trong đề, FSx for ONTAP cũng làm được — nhưng FSx for Windows đơn giản hơn và đủ dùng vì Linux mount SMB được.

Ba tuỳ chọn khi Linux mount SMB: | Tuỳ chọn | Chi tiết | |---|---| | sec=krb5 | xác thực Kerberos với AD — giữ danh tính người dùng | | vers=3.0 trở lên | dùng SMB hiện đại, có mã hoá | | multiuser | mỗi người dùng Linux dùng danh tính riêng |

sec=krb5 là chi tiết quan trọng:

Không dùng Kerberos:
    → mount bằng MỘT tài khoản duy nhất
    → mọi người dùng Linux thao tác dưới danh tính đó
    → ACL của NTFS mất ý nghĩa

Dùng krb5 + multiuser:
    → mỗi người dùng Linux xác thực bằng vé Kerberos riêng
    → ACL áp đúng theo từng người

Ba tính năng của FSx for Windows: | Tính năng | Chi tiết | |---|---| | Data deduplication | tiết kiệm 50–60% | | Shadow Copy | người dùng tự khôi phục phiên bản cũ | | DFS Namespaces và Replication | gộp nhiều file system | | User quota | giới hạn theo người dùng |

Hai kiểu triển khai: | Kiểu | Đặc điểm | |---|---| | Single-AZ | rẻ hơn, không chịu được mất AZ | | Multi-AZ | standby ở AZ khác, tự chuyển đổi |

Ba yêu cầu triển khai: | Yêu cầu | Chi tiết | |---|---| | Active Directory | Managed AD hoặc AD tự quản | | Security group mở cổng SMB (445) và cổng AD | | | DNS phân giải được tên domain | Route 53 Resolver rule |

Ba lựa chọn lưu trữ: | Loại | Phù hợp | |---|---| | SSD | ứng dụng cần I/O cao | | HDD | dung lượng lớn, truy cập thưa | | SSD cache trên HDD | cân bằng |

Ba cách chuyển dữ liệu lên FSx: | Cách | Đặc điểm | |---|---| | AWS DataSync | nhanh, GIỮ ACL và metadata NTFS | | Robocopy | thủ công, khối lượng nhỏ | | DFS Replication | đồng bộ liên tục từ AD tại chỗ |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Chọn SSD cho tải phân tích | HDD quá chậm cho I/O ngẫu nhiên | | Cấp đủ thông lượng | khai riêng với dung lượng | | Đặt EC2 cùng AZ với file system | giảm độ trễ và phí chéo AZ |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Tính theo dung lượng CẤP PHÁT | không phải dung lượng dùng | | Thông lượng tính riêng | ảnh hưởng giá đáng kể | | Bật deduplication | giảm dung lượng cần cấp |

Ba biện pháp bảo mật cho dịch vụ tài chính: | Biện pháp | Chi tiết | |---|---| | Mã hoá at rest bằng KMS | bật lúc tạo | | Mã hoá in transit (SMB 3.0+) | | | ACL của NTFS từ AD | giữ nguyên mô hình quyền hiện có |

Và một lời khuyên: hãy kiểm chứng ACL hoạt động đúng từ phía Linux trước khi chuyển hẳn. Mount SMB từ Linux mà không cấu hình Kerberos đúng cách sẽ khiến mọi thao tác chạy dưới một danh tính duy nhất — và bạn chỉ phát hiện điều đó khi ai đó truy cập được tệp mà lẽ ra họ không được phép.

Câu 590 Design Secure Architectures

A developer has configured inbound traffic for the relevant ports in both the Security Group of the Amazon EC2 instance as well as the Network Access Control List (Network ACL) of the subnet for the Amazon EC2 instance. The developer is, however, unable to connect to the service running on the Amazon EC2 instance.

As a solutions architect, how will you fix this issue?

  1. A

    Security Groups are stateful, so allowing inbound traffic to the necessary ports enables the connection. Network ACLs are stateless, so you must allow both inbound and outbound traffic
  2. B

    Network ACLs are stateful, so allowing inbound traffic to the necessary ports enables the connection. Security Groups are stateless, so you must allow both inbound and outbound traffic
  3. C

    Rules associated with Network ACLs should never be modified from command line. An attempt to modify rules from command line blocks the rule and results in an erratic behavior
  4. D

    IAM Role defined in the Security Group is different from the IAM Role that is given access in the Network ACLs
Xem giải thích

Đáp án

A — Security group là STATEFUL, nên cho phép lưu lượng vào ở cổng cần thiết là đủ để kết nối hoạt động. Network ACL là STATELESS, nên phải cho phép CẢ lưu lượng vào LẪN lưu lượng ra.

Vì sao đúng

Đây là khác biệt căn bản nhất giữa hai cơ chế lọc, và là nguyên nhân của lỗi trong đề.

Lập trình viên đã mở cổng vào ở CẢ security group LẪN NACL
    → nhưng NACL là STATELESS
    → phản hồi đi RA bị chặn
        ↓
    Kết nối thiết lập được nhưng không nhận được dữ liệu trả về

Cơ chế stateful của security group:

Client → EC2 cổng 443 (inbound rule cho phép)
    ↓
Security group GHI NHỚ kết nối này
    ↓
EC2 → Client (phản hồi)
    → TỰ ĐỘNG được phép ra, không cần outbound rule

Cơ chế stateless của NACL:

Client → EC2 cổng 443 (inbound rule cho phép) ✓
    ↓
EC2 → Client cổng NGẪU NHIÊN (1024–65535)
    → NACL KHÔNG nhớ gì
    → cần OUTBOUND rule cho phép dải cổng đó
        ↓
    Thiếu rule này là kết nối treo

NACL đúng phải có cả hai chiều:

# Vào: cho phép HTTPS
aws ec2 create-network-acl-entry --network-acl-id acl-0abc   --rule-number 100 --protocol tcp --port-range From=443,To=443   --cidr-block 0.0.0.0/0 --rule-action allow --ingress

# Ra: cho phép dải cổng tạm thời cho phản hồi
aws ec2 create-network-acl-entry --network-acl-id acl-0abc   --rule-number 100 --protocol tcp --port-range From=1024,To=65535   --cidr-block 0.0.0.0/0 --rule-action allow --egress

Dải 1024–65535 gọi là "ephemeral port range" — cổng nguồn ngẫu nhiên mà client dùng, và cũng là cổng đích của phản hồi.

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

  • **B. NACL là stateful, security group là stateless — đây là phương án gần nhất và là bẫy chính: nó nêu đúng hai khái niệm nhưng gán ngược cho hai dịch vụ. Security group stateful, NACL stateless.
  • **C. Không được sửa NACL từ dòng lệnh, làm vậy gây hành vi bất thường — không có ràng buộc nào như vậy: console, CLI và API đều là cách hợp lệ để sửa NACL.
  • **D. IAM role trong security group khác với IAM role trong NACL — nhầm lẫn khái niệm hoàn toàn: security group và NACL là cơ chế lọc mạng, chúng không có IAM role.

Ghi nhớ

Security group và NACL — bảng phải thuộc: | | Security group | Network ACL | |---|---|---| | Phạm vi | ENI (instance) | SUBNET | | Trạng thái | STATEFUL | STATELESS | | Quy tắc | CHỈ Allow | Allow và Deny | | Đánh giá | mọi quy tắc | theo SỐ THỨ TỰ, dừng ở quy tắc đầu khớp | | Nguồn | IP, CIDR, security group khác, prefix list | CHỈ CIDR | | Mặc định | chặn inbound, cho outbound | cho cả hai chiều |

Đây là bảng được hỏi nhiều nhất về mạng VPC.

Dải cổng tạm thời (ephemeral port) theo hệ điều hành: | Hệ điều hành | Dải | |---|---| | Linux nhân hiện đại | 32768–60999 | | Windows | 49152–65535 | | Network Load Balancer, Lambda | 1024–65535 |

AWS khuyến nghị mở 1024–65535 để an toàn — bao phủ mọi trường hợp.

Ba đặc điểm của NACL: | Đặc điểm | Chi tiết | |---|---| | Đánh giá theo SỐ THỨ TỰ tăng dần | dừng ở quy tắc ĐẦU TIÊN khớp | | Có quy tắc Deny | cơ chế duy nhất chặn được một IP | | NACL mặc định cho phép mọi thứ | NACL tự tạo thì chặn mọi thứ |

Thứ tự đánh giá rất quan trọng:

Rule 100: Allow 0.0.0.0/0 port 443
Rule 200: Deny  203.0.113.45/32 port 443
        ↓
    IP 203.0.113.45 khớp rule 100 TRƯỚC → ĐƯỢC PHÉP
    → rule Deny không bao giờ được xét
        ↓
    Phải đặt Deny ở SỐ NHỎ HƠN

Ba lưu ý về NACL tự tạo: | Lưu ý | Chi tiết | |---|---| | NACL MẶC ĐỊNH cho phép mọi thứ | | | NACL bạn TỰ TẠO chặn mọi thứ | phải thêm rule tường minh | | Nhớ thêm rule cho CẢ hai chiều | ← lỗi của câu này |

Ba trường hợp cần dùng NACL: | Trường hợp | Lý do | |---|---| | CHẶN một IP cụ thể | security group không có Deny | | Lớp phòng thủ thứ hai | phòng khi security group cấu hình sai | | Áp quy tắc cho cả subnet | không phải sửa từng security group |

Với hầu hết trường hợp, security group là đủ — AWS khuyến nghị dùng NACL mặc định (cho phép mọi thứ) trừ khi có nhu cầu cụ thể.

Ba nguyên tắc thiết kế security group: | Nguyên tắc | Chi tiết | |---|---| | Một SG cho mỗi TẦNG | dễ quản lý | | Tham chiếu SG thay vì CIDR | an toàn hơn và tự thích ứng | | Chỉ mở cổng thật sự cần | |

Mẫu chuỗi tham chiếu:

SG-ALB:  inbound 443 từ 0.0.0.0/0
SG-Web:  inbound 80  từ SG-ALB
SG-DB:   inbound 5432 từ SG-Web
        ↓
    Mỗi tầng chỉ nhận từ tầng ngay trên nó

Ba hạn mức: | Hạn mức | Giá trị | |---|---| | Quy tắc mỗi SG | 60 inbound + 60 outbound | | SG mỗi ENI | 5 (nâng tối đa 16) | | Quy tắc mỗi NACL | 20 (nâng tối đa 40) |

Ba bước chẩn đoán khi không kết nối được:

① Security group của instance có cho phép cổng đó vào không?
② NACL của subnet có cho phép CẢ vào LẪN ra không?
③ Route table có đường đi tới đích không?

Và VPC Reachability Analyzer làm cả ba bước tự động:

aws ec2 create-network-insights-path   --source i-client --destination i-server   --destination-port 443 --protocol tcp
aws ec2 start-network-insights-analysis --network-insights-path-id nip-0abc

Nó chỉ ra chính xác thành phần nào chặn — security group, NACL, hay route table.

Ba công cụ khác: | Công cụ | Việc | |---|---| | VPC Flow Logs | thấy lưu lượng bị TỪ CHỐI (REJECT) | | AWS Config rule | phát hiện SG mở quá rộng | | Console: Network ACL tab | xem quy tắc hiện tại |

Flow log là cách nhanh nhất xác nhận NACL chặn:

Bản ghi có action = REJECT
    → nếu security group đã cho phép
    → thì thủ phạm là NACL

Và một lời khuyên: hãy để NACL ở cấu hình mặc định (cho phép mọi thứ) trừ khi có yêu cầu bảo mật cụ thể. Security group đã đủ cho phần lớn trường hợp, và NACL stateless là nguồn của những lỗi kết nối rất khó chẩn đoán — đúng như tình huống trong câu hỏi này.