AWS năm 2025: Những điều bạn nghĩ mình biết nhưng giờ đã sai

• Các dịch vụ cốt lõi của AWS đang tiến hóa rất nhanh
• Các tính năng chính như EC2, S3, Lambda nay mang lại hiệu năng và độ linh hoạt vượt xa kỳ vọng của người dùng so với trước đây
• Nhiều thay đổi và tối ưu hóa cũng đã diễn ra trong mạng, xác thực, phương án tiết kiệm chi phí
• Có thể phát sinh nhầm lẫn do các bài blog cũ hoặc thông tin lỗi thời
• Nắm được các bản cập nhật mới nhất và chính sách đã thay đổi là điều thiết yếu để tận dụng AWS hiệu quả

---

AWS 2025: Hiện tại đã khác với nhận thức trong quá khứ

• AWS là một nền tảng đám mây có lịch sử gần 20 năm, và vì thế những “điều ai cũng biết” về dịch vụ này liên tục thay đổi
• Ngay cả người dùng lâu năm cũng khó theo kịp tốc độ thay đổi khi rất nhiều tính năng cốt lõi đã được cải thiện
• Vẫn có nhiều bài blog cung cấp thông tin cũ, nên việc nắm chính xác những gì đã thay đổi trong cấu hình thực tế là rất quan trọng

EC2

• Security Group và IAM Role của EC2 instance giờ đây có thể thay đổi mà không cần dừng dịch vụ
• Có thể thay đổi kích thước, gắn/tháo EBS volume trên instance đang chạy
• Gần đây có thể buộc dừng hoặc chấm dứt EC2 instance, nên không còn phải chờ timeout quá lâu
• Tính năng live migration giữa các máy chủ vật lý đã được triển khai, khiến cảnh báo suy giảm hiệu năng instance trở nên hiếm hơn
• Độ tin cậy của instance đã tăng mạnh, nên gần như không còn chuyện instance biến mất đột ngột như trước
• Biến động giá của Spot instance đã chuyển sang dạng tăng giảm dần dần, giúp giảm nhu cầu phải canh theo thời gian thực như thị trường đầu cơ
• Những trường hợp thực sự cần dedicated instance nay cực kỳ hiếm (ngay cả HIPAA BAA cũng gần 10 năm nay hầu như không còn cần)
• AMI Block Public Access được bật mặc định cho tài khoản mới (tính đến năm 2023 còn áp dụng cả với tài khoản không sở hữu public AMI nào trong hơn 90 ngày)

S3

• S3 không còn là Eventually Consistent nữa mà cung cấp Read-After-Write Consistency
• Không còn cần ngẫu nhiên hóa phần đầu của object key, nên bớt lo về phân tán dữ liệu và vấn đề hotspot
• ACLs (Access Control List) không còn được khuyến nghị, và mặc định bị tắt trên bucket mới
• Bucket mới mặc định được bật Block Public Access
• Mã hóa dữ liệu lưu trữ được áp dụng tự động
• Trước khi Glacier trở thành một storage class của S3, nó từng là dịch vụ riêng; hiện nay đã được tích hợp, chỉ còn để lại dấu vết trong mục billing và một số nơi khác
• Chi phí và tốc độ khôi phục Glacier nay dễ dự đoán hơn nhiều và rẻ hơn so với trước. Nỗi sợ về chi phí khôi phục khổng lồ trước đây không còn đúng nữa

Mạng (Networking)

• EC2-Classic đã biến mất hoàn toàn
• Địa chỉ IPv4 công khai hiện không còn miễn phí, và bị tính phí như Elastic IP
• Thay vì VPC Peering, hiện đã có những lựa chọn tốt hơn như Transit Gateway, chia sẻ VPC/tài nguyên, Cloud WAN
• Có thể giải quyết các bài toán mạng phức tạp dễ dàng hơn với VPC Lattice và Tailscale
• Thời gian áp dụng cập nhật của CloudFront đã giảm từ 45 phút xuống khoảng 5 phút (dù khi chờ triển khai CloudFormation vẫn có thể thấy lâu)
• ELB Classic từng tính phí truyền dữ liệu liên AZ, còn ALB chỉ tính phí LCU. Cần lưu ý NLB vẫn tiếp tục tính phí liên AZ
• Network Load Balancer đã được bổ sung hỗ trợ security group
• Trước đây ID của Availability Zone khác nhau theo từng tài khoản, nhưng nay có thể đồng bộ Zone ID bằng Resource Access Manager

Lambda

• Lambda đã tăng thời gian chạy từ 5 phút lên 15 phút, đồng thời bổ sung hỗ trợ container image (Docker), EFS shared storage, tối đa 10GB RAM, và /tmp 10GB
• Tốc độ gọi Lambda trong VPC đã được cải thiện đáng kể
• Vấn đề cold start đã được giảm nhẹ rất nhiều so với trước

EFS

• Điều chỉnh hiệu năng I/O của EFS giờ có thể thực hiện độc lập với dung lượng, nên không còn phải lấp đầy không gian bằng dữ liệu vô nghĩa

EBS

• EBS volume mới có thể dùng ngay hiệu năng tối đa nếu không có dữ liệu nền
• Volume được tạo từ snapshot có thể chậm ở lần đọc dữ liệu đầu tiên, nên nên đọc toàn bộ đĩa một lượt trước (cũng có tùy chọn nhanh hơn)
• io1 volume có thể gắn đồng thời vào nhiều EC2 instance, nhưng trên thực tế chỉ nên dùng trong những tình huống rất đặc thù

DynamoDB

• Giờ đây cho phép trường rỗng trong item
• Hiệu năng đã ổn định hơn nhiều, nên ít cần phải giám sát riêng vấn đề hot key bằng công cụ riêng như trước
• Với thay đổi về pricing, loại On Demand hợp lý hơn với đa số người dùng

Các lựa chọn tiết kiệm chi phí (Cost Savings Vehicles)

• Reserved Instances đang dần bị loại bỏ, và Savings Plans là tiêu chuẩn trong tương lai. Mức giảm giá của Savings Plan đã thấp hơn so với RI, nhưng tính linh hoạt cao hơn
• Chi phí sử dụng EC2 được tính theo từng giây, nên ngay cả việc bật instance trong thời gian rất ngắn cũng vẫn hiệu quả về chi phí
• Cost Anomaly Detector phát hiện các mẫu sử dụng bất thường với độ chính xác rất cao và hoàn toàn miễn phí
• Compute Optimizer đưa ra khuyến nghị đáng tin cậy cho nhiều tài nguyên như EBS. Các khuyến nghị từ Trusted Advisor thì vẫn còn thiếu nhất quán

Xác thực (Authentication)

• Nên cấp quyền bằng IAM Role, còn IAM User chỉ phù hợp cho các ứng dụng legacy
• IAM Identity Center thay thế AWS SSO và được dùng để truy cập tài khoản. Điều này vẫn gây ra một phần nhầm lẫn
• Có thể đăng ký nhiều thiết bị MFA cho tài khoản root
• Không cần cấu hình riêng root credential cho các tài khoản thành viên trong tổ chức

Khác (Miscellaneous)

• Độ tin cậy và độ bền của us-east-1 đã cải thiện rất nhiều so với trước. Những sự cố từng xảy ra thường xuyên nay đã đủ hiếm để trở thành tin tức
• Việc ngừng hỗ trợ (Deprecation) dịch vụ AWS vẫn hiếm nhưng đang tăng dần, nên cần cân nhắc mức độ phụ thuộc vào các dịch vụ nhỏ
• Hiện tượng điểm dữ liệu cuối cùng của CloudWatch hiển thị thấp bất thường do sai lệch không còn xảy ra nữa
• Từ tài khoản root có thể trực tiếp đóng cả các tài khoản thành viên AWS trong tổ chức

[roxie]

Wow, đã thay đổi rất nhiều thật.

[howudoin]

Giờ đây không thể chỉ chọn dùng một dịch vụ đơn lẻ của AWS.
Muốn làm một thứ gì đó thì phải móc nối đủ thứ để dùng cùng nhau.
Hoàn toàn không hề đơn giản.
Nếu dùng ở startup thì không chỉ tốn chi phí cloud mà còn phải chi cả nhân sự DevOps.
Muốn xây dựng cho đúng bài bản thì khối lượng công việc tăng vọt đến mức phần ngọn còn to hơn phần gốc, gần như lấy hết thời gian phát triển.
Hơn nữa, ngày càng nhiều trường hợp dùng managed service sẽ tốt hơn, nên ngay từ cấp độ code đã bị phụ thuộc vào nền tảng.

[GN⁺]

Ý kiến trên Hacker News

• Thấy Block Public Access của S3 giờ được bật mặc định cho bucket mới, tôi nghĩ đây rõ ràng là quyết định đúng đắn, trước đây đã có rất nhiều vụ rò rỉ dữ liệu lớn vì bucket S3 cấu hình sai. Nhưng đôi khi tôi chỉ muốn tạo một bucket S3 có quyền đọc công khai để phục vụ file công khai, vậy mà cứ mỗi lần lại có gì đó thay đổi, công thức cũ không còn dùng được nữa và tôi lại phải học lại từ đầu.
  • Tôi muốn nói là hãy xem kỹ thiết lập Block Public Access. Đây là một kiểu chốt an toàn để ngăn mọi người mắc sai lầm lớn. Dù bạn có đặt bucket policy rất lỏng lẻo hay ACL (đã cũ nhưng vẫn còn dùng), nếu Block Public Access đang bật thì vẫn không thể truy cập công khai. Ngược lại, nếu tắt Block Public Access và dùng bucket policy được thiết kế tốt thì cũng không sao, vì bucket policy sẽ quyết định hoàn toàn ai có thể truy cập. Tất nhiên về lâu dài, policy có thể vô tình bị thay đổi, có IAM role mới được thêm vào hoặc trust policy bị sửa ngoài ý muốn, nên việc quản lý những thứ đó rất quan trọng.
  • Tôi hay dùng LLM trong những tình huống thế này. Tôi nhờ nó đọc tài liệu và lôi ra các đoạn demo code rải rác trong tài liệu chính thức của AWS, rồi sau đó hỏi luôn cách chỉnh sửa theo nhu cầu riêng.
  • Tôi có cảm giác deja vu kiểu như chuyện này đã từng xảy ra rồi. Hình như 10 năm trước ai cũng để bucket mở nên mới phải có mấy biện pháp như vậy.
  • Những thay đổi kiểu này làm cho câu hỏi phỏng vấn như “Bạn có quen công nghệ này không?” trở nên rất mơ hồ. Công nghệ thay đổi từng tháng, nên tôi chỉ muốn hỏi là biết theo mốc thời gian nào.
  • Nếu muốn học một cách chính thức thì họ còn cho bạn trả $250 để thi chứng chỉ nữa.
• Trên EC2, việc thay security group hay IAM role mà không cần tắt instance đã làm được từ vài năm trước. Spot instance ngày xưa là thị trường đấu giá, nhưng giờ bản thân cơ chế đấu giá đã biến mất, nên ngược lại lại tốt hơn nhiều vì không còn biến động giá đột ngột hay chuyện chỉ một số người dùng nhất định mới tiếp cận được. Trước đây cũng từng có khuyến nghị là phải làm ngẫu nhiên phần đầu object key để tránh hotspot, nhưng giờ không còn cần nữa. Tôi đã mất khá lâu để thuyết phục đồng nghiệp, nhưng thực ra họ chỉ lưu mấy file siêu nhỏ chẳng liên quan gì đến nút thắt cổ chai backend của S3. Lambda ngày xưa bị giới hạn 5 phút và cũng không hỗ trợ container image, còn bây giờ thì hỗ trợ runtime 15 phút, Docker image, chia sẻ EFS, tối đa 10GB RAM và cả 10GB dung lượng /tmp. Một điều tôi cũng từng nhận ra là global scope của Python cũng tồn tại dai dẳng giống như /tmp.
• Việc khôi phục Glacier giờ không còn phải chậm đến mức đau khổ nữa. Theo kiểu suy đoán rất Amazon, tôi từng nghĩ Glacier ngày xưa chắc thực sự chạy ở một kho hàng nào đó của Amazon, kiểu khi bạn yêu cầu dữ liệu thì có nhân viên đi lấy media rời từ trên kệ rồi cắm vào server. Nó giống cách backup bằng băng từ của các máy tính chia sẻ thời gian ngày xưa, khi đó phải trực tiếp thay băng bằng tay.
  • Thực tế có lẽ họ dùng thiết bị tự động kiểu robot tape library nhiều hơn, ví dụ ảnh liên quan. Robot chứ không phải con người sẽ lấy băng, đưa vào ổ đọc, tua đến offset, đọc xong rồi tua lại và cất về chỗ cũ. Độ trễ xuất hiện vì phải tìm băng, tua lại và chờ ổ đọc rảnh. Có lẽ để hiệu quả hơn thì họ sẽ xử lý hết các yêu cầu trên một cuộn băng trong một lần lắp vào rồi mới tháo ra.
  • Tôi không thể nói về tình hình nội bộ, nhưng tôi chưa từng thấy ai đoán đúng thiết kế của Glacier. Tôi cũng từng ở AWS, và tôi có thể nói rằng dù sao Glacier cũng chạy trong cùng các datacenter như những dịch vụ AWS khác. Điều quan trọng trong engineering hay product management là quản lý kỳ vọng của khách hàng cho tốt. Nếu bạn nói giới hạn upload là 10 mà lại cho upload được 12, thì khách hàng sẽ tiếp tục kỳ vọng là 12. Quản lý kỳ vọng là chuyện rất quan trọng.
  • Ổ cứng có tính đồng nhất nên tôi nghĩ kho hàng sẽ được vận hành bằng robot tự động. Con người thường được dùng cho các trường hợp phi tiêu chuẩn như nhiều kích cỡ hay hình dạng khác nhau.
  • Dù sao thì các loại thiết bị như vậy đã được robot hóa từ vài chục năm nay rồi.
• Tôi không còn đăng nhập được vào tài khoản AWS nữa vì trước đó chưa thiết lập MFA. Muốn được cấp thiết bị thì lại phải đăng nhập trước, nên dù đã được cảnh báo từ trước, cơ chế không thể yêu cầu thiết bị MFA khi chưa đăng nhập vẫn khá bực bội.
  • Có lẽ nên liên hệ bộ phận hỗ trợ.
    Liên hệ AWS Support
  • Có vẻ đây là kiểu vấn đề mà đội hỗ trợ có thể xử lý khá dễ.
• Tôi nghĩ chắc có nhiều người giống tôi, tức là muốn bỏ qua kiểu làm AWS truyền thống — phải sờ vào API Gateway, Lambda serverless và IAM role cho khớp — để chỉ dùng EC2 hoặc VPS LightSail, bucket S3 và Route53 nối domain rồi khỏi bận tâm phần còn lại.
  • Nếu chỉ dùng storage + VPS thì VPS truyền thống rẻ hơn AWS rất nhiều. Còn tôi thì lại có triết lý rằng đã dùng AWS thì phải dùng cho ra dùng, dùng thật nhiều. Cái gì có thể ủy thác thì giao hết cho Amazon để tăng hiệu quả và giảm chi phí. Step Functions, Lambda và DynamoDB đều đã vượt qua các phương án thay thế. Chỉ tiếc là tôi thấy các developer thường không tối ưu hóa việc tận dụng vendor tốt như họ có thể.
  • Thực tế cũng có nhiều nơi trong ngành đã đơn giản hóa cloud, và lý do là giới hạn vùng dịch vụ hoặc hóa đơn dễ dự đoán hơn.
  • Quản lý IAM tốn thời gian quá mức, cảm giác như thời gian trước đây dành cho quản trị hệ thống giờ dồn hết vào quản lý permission. IAM khó đến mức rốt cuộc bị lỗ ròng. Có lẽ có một điểm ngọt nào đó nằm giữa VPS và việc quản lý least privilege quá mức cho serverless. Fargate có thể là ứng viên đó, nên tôi định chuyển thêm sang đó để thử nghiệm.
• Tôi mong AWS thay vì bị phân tâm bởi AI và tung ra đủ thứ để chạy theo các mảng khác, nên tập trung hơn vào những “dịch vụ nền tảng nhưng quan trọng” mà họ vốn làm tốt. Tôi có cảm giác ban lãnh đạo AWS hiện giờ đang mất phương hướng ở mảng GenAI, trong khi hạ tầng cơ bản thì họ vẫn làm tốt. Vì AI mà họ trông như đang hoảng loạn, và từ góc nhìn khách hàng thì điều đó quá rối và khó chịu.
  • Hướng đi của ban lãnh đạo hiện tại là làm cho hạ tầng trở nên đơn giản để ai cũng có thể chọn model và dùng ngay, không cần vật lộn với khâu thiết lập.
• Việc bucket S3 dù ở cùng region với VPC mà nếu đi qua Internet công cộng thì vẫn bị tính phí NAT Gateway thật sự vô lý. Mặc định đúng ra phải là opt-out, nhưng việc để opt-in làm mặc định có lẽ là vì AWS kiếm thêm doanh thu từ cấu trúc này. Chắc rất ít người thật sự muốn đường đi hiện tại như thế.
  • Đây là thiết kế có tính đến chuyện bảo mật là mặc định. Nếu không cấu hình NAT Gateway, VPC Gateway Endpoint (S3) hay các đường ra Internet khác thì workload sẽ không thể truy cập S3. Networking nên ở trạng thái đóng sẵn, và nếu người dùng không hiểu rõ đường đi rồi tự dựng gì đó thì trách nhiệm thuộc về khách hàng. Nên xem AWS chỉ cung cấp các công cụ Infrastructure as a Service (IaaS) ở mức thô.
  • S3 VPC Gateway Endpoint tồn tại chính vì mục đích này, và nó miễn phí.
    Tài liệu chính thức của AWS
  • Sau khi tự thiết lập VPC, subnet, endpoint PrivateLink các thứ rồi thì đúng là thấy rất lố bịch. Họ còn đầu tư cả vào cái tên PrivateLink nữa (xét về mặt kỹ thuật thì cũng có ý nghĩa), nhưng tôi vẫn nghĩ những thứ như vậy đáng ra phải có sẵn mặc định mà không cần cấu hình. Thậm chí nếu dùng private subnet thì chẳng phải PrivateLink là cách duy nhất để truy cập S3 và các dịch vụ tương tự sao, cảm giác rất kỳ quặc.
  • Tôi nghĩ toàn bộ VPC endpoint nên được áp dụng mặc định và miễn phí. Phải trả thêm tiền chỉ để dùng API của chính dịch vụ trong hệ sinh thái của họ thì hơi quá.
  • Đây là để phân tầng giá. Khách hàng không nhạy cảm về giá thì chẳng buồn quan tâm, còn bên quan tâm thì sẽ cố giảm chi phí, và trong những tình huống như vậy thì nhiều khi họ vẫn buộc phải dùng AWS.
• Bài này làm tôi yên tâm hơn. Tôi lúc nào cũng lo Amazon sẽ thay đổi lớn gì đó rồi ép phải migration, nhưng từ năm 2013 đến giờ tôi dùng EC2 gần như không cần quản lý gì nhiều và nó vẫn hoạt động tốt. Thật mừng vì không có thay đổi bất ngờ nào.
• Tôi bị sốc khi biết trước đây Availability Zones từng được map ngẫu nhiên theo từng tài khoản.
  • Đó là để phân tán tải. Nếu nhiều tài khoản cùng cố định vào một AZ như 1b thì việc map như vậy sẽ giúp phân tán vật lý thực tế đồng đều hơn. Sau này họ cung cấp canonical name cho từng AZ, có lẽ vì những tài khoản từng tạo hotspot và những tài khoản cần metadata thực ra không phải là cùng một nhóm.
  • Tôi nghĩ mục đích là ngăn tình trạng ai cũng chọn mặc định us-east-1a rồi dồn hết vào một AZ cụ thể.
  • Ban đầu thì tốt cho cân bằng tải, nhưng khi kết nối mạng giữa nhiều tài khoản với nhau, như PrivateLink chẳng hạn, thì rất rối vì phải kiểm tra từng AZ tương ứng với AZ nào. Thế là chúng tôi còn phải tự làm phương pháp mapping một-một theo từng tài khoản và dựng cả bảng tra cứu nội bộ, rồi sau này AWS mới thêm zone ID vào metadata để có thể tra dễ hơn.
  • Tôi đã khổ sở thật sự nhiều vì chính sách đó.
• Có một điều tôi muốn đính chính: những mẩu kiến thức vặt vô nghĩa có thể bị đảo lộn hoàn toàn.
  Weird Al: Everything You Know is Wrong
  Firesign Theatre: Everything You Know is Wrong