Các dịch vụ AWS khác
1. WorkSpaces & AppStream 2.0
Phần tiêu đề “1. WorkSpaces & AppStream 2.0”Nhiều doanh nghiệp cần cung cấp cho nhân viên một “máy tính làm việc” từ xa mà không phải mua và bảo trì phần cứng vật lý — đặc biệt hữu ích khi làm việc từ xa, thuê nhân sự thời vụ, hoặc cần bảo mật cao (dữ liệu không lưu trên laptop cá nhân). AWS có hai dịch vụ giải quyết vấn đề này theo hai cách rất khác nhau: Amazon WorkSpaces và Amazon AppStream 2.0. Đây là cặp dịch vụ dễ gây nhầm lẫn nhất trong chương này, vì cả hai đều “đưa phần mềm tới người dùng qua Internet”, nhưng bản chất khác biệt.
Amazon WorkSpaces
Phần tiêu đề “Amazon WorkSpaces”Amazon WorkSpaces là một giải pháp Desktop as a Service (DaaS) được quản lý hoàn toàn — cho phép cấp phát nhanh một máy tính desktop Windows hoặc Linux đầy đủ, chạy trên AWS, cho nhân viên truy cập từ bất kỳ đâu. Về bản chất, nó thay thế hạ tầng VDI (Virtual Desktop Infrastructure) mà trước đây doanh nghiệp phải tự dựng và vận hành tại chỗ (mua server, cài phần mềm virtualization, quản lý licence…). Với WorkSpaces:
- Có thể mở rộng nhanh tới hàng nghìn người dùng chỉ trong vài phút.
- Dữ liệu được bảo mật, tích hợp sẵn với AWS KMS để mã hóa.
- Thanh toán theo mô hình pay-as-you-go — có thể tính theo giờ hoặc theo tháng, tùy vào việc người dùng dùng thường xuyên hay không.
- Có thể triển khai WorkSpaces ở nhiều Region khác nhau, để phục vụ nhân viên tại các văn phòng ở các vị trí địa lý khác nhau (ví dụ: WorkSpaces đặt tại N. Virginia phục vụ văn phòng California, WorkSpaces đặt tại London phục vụ văn phòng Paris — chọn Region gần người dùng nhất để có độ trễ thấp).
Amazon AppStream 2.0
Phần tiêu đề “Amazon AppStream 2.0”Amazon AppStream 2.0 lại không cấp cho người dùng một “máy desktop ảo” hoàn chỉnh, mà streaming (truyền trực tiếp) một ứng dụng cụ thể tới trình duyệt web của người dùng. Người dùng không cần cài đặt gì, không cần “đăng nhập vào một máy ảo” — họ chỉ mở trình duyệt và ứng dụng hiện ra như đang chạy ngay trên máy họ, dù thực tế ứng dụng đang chạy trên một server của AWS ở đâu đó. Điều này giúp doanh nghiệp phân phối ứng dụng nội bộ (kể cả ứng dụng cấu hình phần cứng nặng như phần mềm CAD, phân tích dữ liệu) tới bất kỳ máy nào có trình duyệt, mà không cần công ty tự đầu tư hạ tầng.
| Tiêu chí | Amazon WorkSpaces | Amazon AppStream 2.0 |
|---|---|---|
| Đối tượng cấp phát | Toàn bộ desktop ảo (VDI) | Một ứng dụng cụ thể |
| Cách truy cập | Kết nối vào máy ảo, mở ứng dụng gốc hoặc WAM (Workspaces Application Manager) trong đó | Mở trực tiếp trong trình duyệt web, không cần “vào” máy ảo |
| Chế độ hoạt động | On-demand (theo giờ) hoặc Always-on (luôn chạy) | Chạy theo phiên khi người dùng mở ứng dụng |
| Thiết bị hỗ trợ | Cần ứng dụng client WorkSpaces hoặc trình duyệt hỗ trợ | Bất kỳ thiết bị có trình duyệt web |
| Tùy biến tài nguyên | Chọn loại “bundle” WorkSpace (gói cấu hình chung) | Có thể cấu hình loại instance riêng (CPU/RAM/GPU) cho từng ứng dụng cụ thể |
2. IoT & phát triển ứng dụng
Phần tiêu đề “2. IoT & phát triển ứng dụng”AWS IoT Core
Phần tiêu đề “AWS IoT Core”IoT (Internet of Things) là khái niệm chỉ mạng lưới các thiết bị kết nối Internet có khả năng thu thập và truyền dữ liệu — ví dụ cảm biến nhiệt độ, camera an ninh, thiết bị đeo tay theo dõi sức khỏe, xe hơi thông minh… AWS IoT Core là dịch vụ giúp kết nối hàng loạt thiết bị IoT như vậy vào AWS Cloud một cách dễ dàng. Đây là một dịch vụ serverless, được thiết kế để bảo mật và có thể mở rộng tới hàng tỷ thiết bị và hàng nghìn tỷ tin nhắn. Mô hình giao tiếp của IoT Core là publish & subscribe (pub/sub): thiết bị publish dữ liệu lên các topic, còn ứng dụng hoặc dịch vụ quan tâm thì subscribe topic đó — hai bên không cần biết nhau, nhờ vậy hệ thống mở rộng được tới quy mô hàng tỷ thiết bị. Một điểm hay của IoT Core là các ứng dụng có thể “giao tiếp” với thiết bị ngay cả khi thiết bị đó tạm thời mất kết nối (dữ liệu/lệnh sẽ được đồng bộ khi thiết bị kết nối lại). IoT Core tích hợp chặt với nhiều dịch vụ AWS khác như Lambda (xử lý dữ liệu theo sự kiện), S3 (lưu trữ), SageMaker (áp dụng machine learning lên dữ liệu cảm biến) — cho phép xây dựng toàn bộ pipeline “thu thập → xử lý → phân tích → hành động” trên dữ liệu IoT.
AWS AppSync
Phần tiêu đề “AWS AppSync”AWS AppSync là dịch vụ giúp lưu trữ và đồng bộ dữ liệu theo thời gian thực (real-time) giữa các ứng dụng mobile và web — ví dụ khi một người dùng cập nhật dữ liệu trên điện thoại, những người dùng khác đang mở ứng dụng cũng thấy thay đổi ngay lập tức. AppSync sử dụng GraphQL — một công nghệ truy vấn dữ liệu ban đầu do Facebook phát triển, cho phép client chỉ định chính xác dữ liệu cần lấy (khác với REST API truyền thống thường trả về nguyên khối dữ liệu cố định). Các đặc điểm chính:
- Có thể tự động sinh code phía client (client code generation) để tích hợp nhanh vào ứng dụng.
- Tích hợp sẵn với DynamoDB và Lambda làm nguồn dữ liệu phía sau.
- Hỗ trợ subscription thời gian thực (real-time subscriptions) — client “đăng ký” nhận thông báo khi dữ liệu thay đổi.
- Hỗ trợ đồng bộ dữ liệu offline (offline data synchronization) — thay thế cho tính năng Cognito Sync trước đây.
- Có cơ chế bảo mật chi tiết (fine-grained security) tới từng trường dữ liệu.
AWS Amplify
Phần tiêu đề “AWS Amplify”AWS Amplify là một bộ công cụ và dịch vụ giúp phát triển và triển khai nhanh các ứng dụng full-stack web và mobile có thể mở rộng, mà không cần nhóm phát triển phải tự ghép nối từng dịch vụ AWS riêng lẻ. Amplify cung cấp sẵn các module cho: Authentication (xác thực người dùng), Storage (lưu trữ file), API (REST hoặc GraphQL), CI/CD (tự động build/deploy), PubSub (giao tiếp publish/subscribe), Analytics, các tính năng AI/ML Predictions, Monitoring, và có thể lấy mã nguồn trực tiếp từ AWS hoặc từ GitHub. Ở phía sau (backend), Amplify có thể tận dụng nhiều dịch vụ AWS khác: S3, Cognito, AppSync, API Gateway, Lambda, DynamoDB, SageMaker, Lex. Amplify còn có Amplify Studio — một môi trường phát triển trực quan (visual development), giúp xây dựng giao diện và luồng dữ liệu bằng cách kéo-thả mà ít cần viết code thủ công.
Có thể hiểu quan hệ giữa hai dịch vụ này như sau: AppSync là “công cụ đồng bộ dữ liệu GraphQL thời gian thực”, còn Amplify là “bộ khung phát triển ứng dụng toàn diện hơn”, và trong nhiều trường hợp Amplify sử dụng AppSync ở phía sau như một trong các thành phần backend của nó.
AWS Infrastructure Composer
Phần tiêu đề “AWS Infrastructure Composer”AWS Infrastructure Composer là công cụ cho phép thiết kế trực quan (visually design) các ứng dụng serverless mà không cần là chuyên gia về hạ tầng AWS. Bạn có thể kéo-thả để cấu hình cách các tài nguyên tương tác với nhau, và công cụ này sẽ tự động sinh ra mã Infrastructure as Code (IaC) dưới dạng CloudFormation. Nó cũng có khả năng nhập (import) các template CloudFormation/SAM đã có sẵn để trực quan hóa chúng — giúp người mới dễ hình dung kiến trúc hơn là đọc code YAML/JSON thô.
AWS Device Farm
Phần tiêu đề “AWS Device Farm”AWS Device Farm là dịch vụ được quản lý hoàn toàn, giúp kiểm thử ứng dụng web và mobile trên nhiều trình duyệt desktop, thiết bị di động, và máy tính bảng thật (không phải máy giả lập/emulator). Điểm mạnh của Device Farm:
- Chạy test đồng thời trên nhiều thiết bị cùng lúc — giúp rút ngắn thời gian kiểm thử đáng kể.
- Có thể cấu hình các thiết lập trên thiết bị như GPS, ngôn ngữ, Wi-Fi, Bluetooth để kiểm thử trong nhiều tình huống thực tế khác nhau.
- Vì dùng thiết bị thật, kết quả test phản ánh chính xác hơn cách ứng dụng hoạt động trên tay người dùng thật, so với việc chỉ test trên emulator.
3. Backup & Disaster Recovery
Phần tiêu đề “3. Backup & Disaster Recovery”AWS Backup
Phần tiêu đề “AWS Backup”Trước AWS Backup, việc backup dữ liệu trên AWS thường bị phân tán: EBS có snapshot riêng, RDS có backup riêng, DynamoDB có cơ chế riêng… rất khó quản lý tập trung khi hệ thống có hàng chục loại tài nguyên. AWS Backup ra đời để giải quyết đúng vấn đề này — là dịch vụ được quản lý hoàn toàn, cho phép quản lý và tự động hóa backup tập trung trên nhiều dịch vụ AWS cùng lúc. Các khả năng chính:
- Backup theo yêu cầu (on-demand) hoặc theo lịch (scheduled).
- Hỗ trợ PITR (Point-in-Time Recovery) — khôi phục dữ liệu về một thời điểm cụ thể trong quá khứ.
- Có thể cấu hình chu kỳ giữ dữ liệu (retention period), quản lý vòng đời (lifecycle management), và các chính sách backup (backup policies) áp dụng đồng loạt.
- Hỗ trợ backup xuyên Region (cross-region) và xuyên tài khoản (cross-account, thông qua AWS Organizations) — hữu ích cho việc phòng ngừa rủi ro ở cấp độ toàn tổ chức.
Luồng hoạt động cơ bản: bạn tạo một Backup Plan (định nghĩa tần suất backup và chính sách retention) → gán các tài nguyên AWS cần backup vào plan đó (có thể là EC2, EBS, DynamoDB, RDS, EFS, Aurora, FSx, Storage Gateway, S3…) → hệ thống sẽ tự động thực hiện backup theo đúng lịch đã cấu hình, không cần bạn thao tác lại mỗi lần.
Bốn chiến lược DR
Phần tiêu đề “Bốn chiến lược DR”Disaster Recovery (khôi phục sau thảm họa) là kế hoạch giúp hệ thống hoạt động trở lại sau khi gặp sự cố nghiêm trọng (mất Region, lỗi phần cứng lớn, tấn công mạng…). AWS thường trình bày 4 chiến lược DR theo thang tăng dần về chi phí và mức độ sẵn sàng, đồng thời giảm dần về thời gian khôi phục (Recovery Time):
| Chiến lược | Mô tả | Chi phí | Thời gian khôi phục |
|---|---|---|---|
| Backup and Restore | Chỉ backup dữ liệu (từ trung tâm dữ liệu công ty hoặc server trên AWS Cloud) lên S3; khi có sự cố mới bắt đầu dựng lại hệ thống từ backup. | Thấp nhất | Chậm nhất |
| Pilot Light | Chỉ giữ các chức năng lõi (core) của ứng dụng chạy ở mức tối thiểu trên AWS Cloud (ví dụ một EC2 Web Server ở trạng thái standby), sẵn sàng để mở rộng quy mô nhanh khi cần. | Trung bình-thấp | Nhanh hơn Backup & Restore |
| Warm Standby | Chạy sẵn một phiên bản đầy đủ tính năng của ứng dụng trên AWS Cloud, nhưng ở quy mô (size) tối thiểu; khi xảy ra thảm họa thì scale up (tăng quy mô) lên để đáp ứng tải thật. | Trung bình-cao | Nhanh |
| Multi-Site / Hot-Site | Chạy sẵn phiên bản đầy đủ của ứng dụng ở quy mô đầy đủ, hoạt động liên tục trên AWS Cloud mọi lúc. | Cao nhất | Nhanh nhất (gần như tức thì) |
Ví dụ điển hình về triển khai DR trên Cloud: một hệ thống chạy chính ở Region N. Virginia (us-east-1), với các EC2 Instance rải trên nhiều Availability Zone (AZ A và AZ B) để chịu lỗi trong cùng Region; khi cần dự phòng ở cấp Region, hệ thống có thể failover (chuyển hướng) sang một Region phụ như London (eu-west-2), với các EC2 Instance cũng được rải trên nhiều AZ tại đó.
AWS DRS
Phần tiêu đề “AWS DRS”AWS Elastic Disaster Recovery, trước đây có tên là “CloudEndure Disaster Recovery”, là dịch vụ giúp khôi phục nhanh và dễ dàng các server vật lý, server ảo, hoặc server đang chạy trên cloud khác — đưa chúng vào AWS khi xảy ra sự cố. Đây là lựa chọn phù hợp để bảo vệ những hệ thống quan trọng nhất: cơ sở dữ liệu doanh nghiệp (Oracle, MySQL, SQL Server), ứng dụng doanh nghiệp lớn (như SAP), hoặc để bảo vệ dữ liệu khỏi các cuộc tấn công ransomware. Cơ chế hoạt động dựa trên sao chép liên tục ở cấp block (continuous block-level replication):
- Server nguồn (tại trung tâm dữ liệu công ty hoặc bất kỳ cloud nào) — bao gồm disk, OS, ứng dụng, database — được cài AWS Replication Agent.
- Agent liên tục sao chép dữ liệu (theo từng giây) sang khu vực Staging trên AWS — nơi dùng các EC2 Instance và EBS Volume chi phí thấp để giữ bản sao “ngủ chờ”, tối ưu chi phí trong thời gian chưa có sự cố.
- Khi thảm họa xảy ra, tiến hành failover (chỉ trong vài phút) — khởi động các EC2 Instance và EBS Volume đích thật, đưa hệ thống vào trạng thái Production để tiếp tục vận hành.
- Sau khi hệ thống nguồn khôi phục, có thể thực hiện failback để chuyển hoạt động trở lại vị trí ban đầu.
4. Di trú (Migration)
Phần tiêu đề “4. Di trú (Migration)”AWS DataSync
Phần tiêu đề “AWS DataSync”AWS DataSync là dịch vụ giúp di chuyển một lượng lớn dữ liệu từ hạ tầng on-premise lên AWS (hoặc thậm chí giữa các dịch vụ lưu trữ AWS với nhau). Dữ liệu có thể được đồng bộ tới: Amazon S3 (ở bất kỳ storage class nào, kể cả Glacier), Amazon EFS, hoặc Amazon FSx for Windows. Đặc điểm quan trọng:
- Các nhiệm vụ đồng bộ (replication task) có thể được lên lịch theo giờ, theo ngày, hoặc theo tuần.
- Sau lần đồng bộ đầy đủ đầu tiên, các lần sau chỉ đồng bộ phần thay đổi (incremental) — giúp tiết kiệm thời gian và băng thông.
- Cần cài đặt một AWS DataSync Agent tại trung tâm dữ liệu on-premise; agent này kết nối qua TLS tới dịch vụ AWS DataSync trong Region, rồi đồng bộ dữ liệu tới S3/EFS/FSx.
Để phân biệt DataSync với các dịch vụ chuyển dữ liệu khác đã học ở chương 6 (Snowball, Storage Gateway): DataSync phù hợp khi bạn cần di chuyển dữ liệu qua network một cách có kiểm soát và lặp lại (đồng bộ định kỳ, tăng dần); Snowball phù hợp khi lượng dữ liệu quá lớn hoặc kết nối mạng quá yếu để chuyển qua Internet (chuyển bằng thiết bị vật lý); còn Storage Gateway phù hợp khi bạn cần một “cầu nối lưu trữ” hoạt động liên tục, cho ứng dụng on-premise truy cập dữ liệu như đang dùng ổ đĩa local trong khi dữ liệu thực chất nằm trên AWS.
Chiến lược di trú Cloud — 7Rs
Phần tiêu đề “Chiến lược di trú Cloud — 7Rs”Khi một tổ chức quyết định chuyển hệ thống lên AWS, không phải ứng dụng nào cũng di trú theo cùng một cách. AWS tổng hợp thành 7 chiến lược (7Rs), mỗi chiến lược phù hợp với một mức độ sẵn sàng/lợi ích kinh doanh khác nhau:
| Chiến lược | Ý nghĩa | Ví dụ |
|---|---|---|
| Retire | Tắt hẳn những gì không còn cần dùng — giảm diện tích bị tấn công (attack surface), tiết kiệm 10-20% chi phí. | Loại bỏ ứng dụng nội bộ không còn ai dùng. |
| Retain | Chưa làm gì cả (giữ nguyên tại chỗ) — vì lý do bảo mật/tuân thủ/hiệu năng/phụ thuộc hệ thống khác, hoặc di trú không mang lại giá trị kinh doanh rõ ràng. | Ứng dụng mainframe cũ, chưa có lý do cấp thiết để di trú. |
| Relocate | Di chuyển ứng dụng từ on-premise sang phiên bản Cloud tương ứng, hoặc chuyển EC2 Instance sang VPC/tài khoản/Region khác. | Chuyển VMware SDDC sang VMware Cloud on AWS. |
| Rehost (“lift and shift”) | Di chuyển đơn giản, giữ nguyên hệ thống, không tối ưu gì thêm cho cloud. Có thể tiết kiệm khoảng 30% chi phí. | Dùng AWS Application Migration Service để chuyển thẳng server sang EC2. |
| Replatform (“lift and reshape”) | Không thay đổi kiến trúc lõi, nhưng tận dụng một số tối ưu của cloud (dịch vụ quản lý/serverless) để tiết kiệm thời gian & tiền bạc. | Di chuyển database sang RDS, di chuyển ứng dụng sang Elastic Beanstalk. |
| Repurchase (“drop and shop”) | Chuyển sang dùng một sản phẩm khác hẳn khi lên cloud, thường là nền tảng SaaS. Chi phí cao trong ngắn hạn nhưng triển khai rất nhanh. | Chuyển CRM tự viết sang Salesforce, hệ thống HR sang Workday, CMS sang Drupal. |
| Refactor / Re-architect | Thiết kế lại toàn bộ kiến trúc ứng dụng để tận dụng các đặc tính cloud-native, thường vì cần thêm tính năng, cải thiện khả năng mở rộng/hiệu năng/bảo mật/độ linh hoạt. | Chuyển từ kiến trúc monolith sang microservices, dùng kiến trúc Serverless và S3. |
Application Discovery Service
Phần tiêu đề “Application Discovery Service”AWS Application Discovery Service giúp lập kế hoạch di trú bằng cách thu thập thông tin về trung tâm dữ liệu on-premise hiện tại — mức sử dụng tài nguyên của server và bản đồ phụ thuộc giữa các hệ thống (server A cần server B để hoạt động, v.v.) — những dữ liệu rất quan trọng để lập kế hoạch di trú chính xác. Có hai cách thu thập:
- Agentless Discovery (qua AWS Agentless Discovery Connector): thu thập thông tin kiểm kê VM, cấu hình, và lịch sử hiệu năng (CPU, RAM, disk usage) — không cần cài agent vào từng máy.
- Agent-based Discovery (qua AWS Application Discovery Agent): thu thập chi tiết hơn — cấu hình hệ thống, hiệu năng hệ thống, các tiến trình đang chạy, và thông tin kết nối mạng.
Toàn bộ dữ liệu thu thập được có thể xem tập trung trong AWS Migration Hub.
MGN vs DMS
Phần tiêu đề “MGN vs DMS”AWS Application Migration Service (MGN) là phiên bản kế nhiệm của “CloudEndure Migration”, thay thế cho dịch vụ AWS Server Migration Service (SMS) đã cũ. MGN là giải pháp lift-and-shift (rehost), giúp đơn giản hóa việc di trú toàn bộ server — vật lý, ảo, hoặc đang chạy trên cloud khác — để chạy trực tiếp (native) trên AWS. MGN hỗ trợ rất nhiều nền tảng, hệ điều hành, và cơ sở dữ liệu khác nhau, với mục tiêu giảm thời gian downtime và chi phí. Về kỹ thuật, MGN dùng đúng kiến trúc continuous-replication giống AWS Elastic Disaster Recovery đã nói ở mục 3 — nhưng mục tiêu khác nhau: MGN dùng để di trú một lần rồi cutover xong là kết thúc, còn Elastic Disaster Recovery dùng để duy trì khả năng phòng thảm họa liên tục, lâu dài.
Đừng nhầm MGN với AWS Database Migration Service (DMS) đã học ở chương 7: DMS chỉ tập trung riêng vào việc di trú cơ sở dữ liệu (ví dụ từ Oracle on-premise sang RDS/Aurora), trong khi MGN di trú toàn bộ server (OS, ứng dụng, mọi thứ trên đó) — không chỉ riêng phần dữ liệu.
AWS Migration Evaluator
Phần tiêu đề “AWS Migration Evaluator”AWS Migration Evaluator giúp xây dựng luận điểm kinh doanh (business case) dựa trên dữ liệu thực tế cho việc di trú lên AWS — tức là trả lời câu hỏi “di trú có đáng đầu tư không, tiết kiệm được bao nhiêu”. Nó cung cấp một bức tranh rõ ràng về những gì tổ chức đang chạy hiện tại. Quy trình gồm: cài đặt Agentless Collector để thực hiện khảo sát toàn diện (broad-based discovery) → thu thập ảnh chụp (snapshot) về hạ tầng on-premise và các phụ thuộc giữa các server → nhập dữ liệu (có thể từ công cụ bên thứ ba hoặc từ Application Discovery Service) → nhận báo cáo Quick Insights → từ đó xây dựng Business Case hoàn chỉnh để trình lên ban lãnh đạo.
AWS Migration Hub
Phần tiêu đề “AWS Migration Hub”AWS Migration Hub là nơi tập trung để thu thập dữ liệu kiểm kê server và ứng dụng, phục vụ việc đánh giá, lập kế hoạch, và theo dõi tiến độ các dự án di trú lên AWS — giúp đẩy nhanh quá trình di trú và tự động hóa việc lift-and-shift. Bốn việc chính Migration Hub làm: khám phá, phân tích và gom nhóm server thành ứng dụng; right-size khối lượng công việc dựa trên khuyến nghị từ dữ liệu thu thập được; điều phối (orchestrate) việc di trú trên nhiều công cụ khác nhau; và tái cấu trúc (refactor) ứng dụng dần dần sau khi đã lên AWS. Trong đó, Migration Hub Orchestrator cung cấp các template dựng sẵn để tiết kiệm thời gian di trú các ứng dụng doanh nghiệp phức tạp (như SAP, MS SQL Server). Migration Hub cũng hỗ trợ nhận cập nhật trạng thái di trú trực tiếp từ Application Migration Service (MGN) và Database Migration Service (DMS), giúp bạn theo dõi toàn cảnh dự án di trú ở một nơi duy nhất.
5. Step Functions & FIS
Phần tiêu đề “5. Step Functions & FIS”AWS Step Functions
Phần tiêu đề “AWS Step Functions”AWS Step Functions cho phép xây dựng các workflow trực quan (visual workflow), serverless để điều phối (orchestrate) nhiều Lambda function chạy theo đúng trình tự nghiệp vụ mong muốn. Thay vì viết code phức tạp để tự quản lý trình tự gọi hàm, xử lý lỗi, chờ đợi… Step Functions cho phép định nghĩa toàn bộ luồng đó dưới dạng một biểu đồ trạng thái (state machine), với các khả năng:
- Thực hiện tuần tự (sequence), song song (parallel).
- Rẽ nhánh theo điều kiện (conditions), giới hạn thời gian chờ (timeouts), và xử lý lỗi (error handling) có cấu trúc rõ ràng.
- Có thể tích hợp không chỉ với Lambda mà còn với EC2, ECS, các server on-premise, API Gateway, hàng đợi SQS.
- Có thể triển khai bước “chờ con người phê duyệt” (human approval) ngay trong workflow — ví dụ workflow tạm dừng chờ một quản lý bấm “Đồng ý” trước khi tiếp tục.
Các trường hợp sử dụng phổ biến: xử lý hoàn tất đơn hàng (order fulfillment), pipeline xử lý dữ liệu (data processing), luồng nghiệp vụ trong ứng dụng web, hay bất kỳ workflow nhiều bước nào cần điều phối rõ ràng, dễ theo dõi trạng thái.
AWS FIS
Phần tiêu đề “AWS FIS”AWS Fault Injection Simulator là dịch vụ được quản lý hoàn toàn, cho phép chạy các thí nghiệm chèn lỗi có chủ đích (fault injection experiments) lên hệ thống đang chạy trên AWS. Ý tưởng nền tảng đến từ Chaos Engineering — một triết lý kỹ thuật: chủ động tạo ra các sự cố gây rối (ví dụ tăng CPU/memory đột ngột, ngắt kết nối mạng…) trong môi trường có kiểm soát, quan sát hệ thống phản ứng ra sao, rồi từ đó cải thiện độ bền vững (resilience) của hệ thống trước khi sự cố thật xảy ra ngoài đời. FIS giúp phát hiện các lỗi ẩn (hidden bugs) và điểm nghẽn hiệu năng (performance bottlenecks) mà việc kiểm thử thông thường khó phát hiện ra.
FIS hỗ trợ chèn lỗi cho các dịch vụ như EC2, ECS, EKS, RDS, và cung cấp sẵn các template dựng sẵn (pre-built templates) để tạo ra các loại gián đoạn mong muốn mà không cần tự viết từ đầu. Luồng hoạt động: bạn tạo một Experiment Template → hệ thống tạo ra một thử nghiệm (experiment) tác động lên các tài nguyên chỉ định (EC2/ECS/EKS/RDS) → toàn bộ quá trình được giám sát qua CloudWatch/EventBridge → thử nghiệm sẽ tự dừng khi hoàn tất hoặc khi một alarm được kích hoạt (để tránh gây hại thật) → sau đó bạn xem kết quả để xác định các vấn đề về hiệu năng, khả năng quan sát (observability), hoặc độ bền vững (resiliency) cần cải thiện.
6. Ground Station & Pinpoint
Phần tiêu đề “6. Ground Station & Pinpoint”AWS Ground Station
Phần tiêu đề “AWS Ground Station”AWS Ground Station là dịch vụ được quản lý hoàn toàn, cho phép bạn điều khiển liên lạc vệ tinh, xử lý dữ liệu, và mở rộng quy mô hoạt động vệ tinh mà không cần tự xây trạm thu phát vệ tinh riêng — một hạ tầng vốn cực kỳ tốn kém nếu tự đầu tư. AWS cung cấp một mạng lưới toàn cầu các trạm mặt đất (ground station) đặt gần các Region của AWS. Nhờ vậy, dữ liệu vệ tinh có thể được tải xuống (download) trực tiếp vào VPC của bạn trên AWS chỉ trong vài giây, và gửi thẳng tới S3 hoặc một EC2 Instance để xử lý tiếp. Các trường hợp sử dụng: dự báo thời tiết, chụp ảnh bề mặt Trái Đất (surface imaging), truyền thông liên lạc, và phát sóng video.
Amazon Pinpoint
Phần tiêu đề “Amazon Pinpoint”Amazon Pinpoint là dịch vụ truyền thông marketing hai chiều (2-way) có thể mở rộng quy mô lớn — hỗ trợ gửi và nhận thông tin qua email, SMS, push notification, voice (gọi điện thoại tự động), và tin nhắn trong ứng dụng (in-app messaging). Pinpoint cho phép phân khúc (segment) và cá nhân hóa (personalize) nội dung gửi tới từng nhóm khách hàng, đồng thời có khả năng nhận phản hồi từ người dùng (ví dụ khách hàng trả lời SMS). Pinpoint có thể mở rộng tới hàng tỷ tin nhắn mỗi ngày, phù hợp cho các trường hợp chạy chiến dịch gửi tin marketing, tin nhắn hàng loạt (bulk), hoặc tin nhắn giao dịch (transactional SMS, ví dụ mã OTP, xác nhận đơn hàng). Pinpoint còn đẩy (stream) các sự kiện gửi tin — ví dụ TEXT_SUCCESS, TEXT_DELIVERED — sang SNS, Kinesis Data Firehose hoặc CloudWatch Logs, để bạn theo dõi và phân tích tỷ lệ gửi/nhận thành công.
Một điểm quan trọng cần phân biệt là Amazon Pinpoint so với Amazon SNS/Amazon SES (đã học ở các chương trước): với SNS và SES, bạn phải tự quản lý mọi thứ theo cách thủ công hơn — tự xác định đối tượng nhận (audience), tự soạn nội dung, tự lên lịch gửi cho từng use case. Trong khi đó, Amazon Pinpoint cung cấp một lớp trừu tượng marketing cao hơn hẳn: bạn tạo template thông điệp tái sử dụng được, thiết lập lịch gửi tự động, xây dựng các phân khúc khách hàng nhắm mục tiêu (highly-targeted segments) rất chi tiết, và quản lý toàn bộ như những chiến dịch (campaigns) hoàn chỉnh — gần giống một công cụ marketing automation chuyên dụng hơn là một dịch vụ gửi tin nhắn đơn thuần.
| Tiêu chí | Amazon SNS / SES | Amazon Pinpoint |
|---|---|---|
| Vai trò | Hạ tầng gửi tin nhắn/email cơ bản, lập trình viên tự điều khiển logic | Nền tảng marketing đầy đủ: campaign, segment, template |
| Quản lý đối tượng nhận | Tự làm thủ công trong code | Có sẵn công cụ phân khúc (segmentation) khách hàng |
| Cá nhân hóa nội dung | Hạn chế, tự lập trình | Có sẵn template & cá nhân hóa theo từng khách hàng |
| Phù hợp cho | Thông báo hệ thống, cảnh báo kỹ thuật, gửi email transaction đơn giản | Chiến dịch marketing, chăm sóc khách hàng quy mô lớn |
Tổng kết chương
Phần tiêu đề “Tổng kết chương”- WorkSpaces vs AppStream 2.0: WorkSpaces cấp cả một desktop ảo hoàn chỉnh; AppStream 2.0 chỉ stream một ứng dụng cụ thể qua trình duyệt.
- IoT Core: kết nối hàng tỷ thiết bị IoT vào AWS Cloud, serverless và có thể mở rộng lớn.
- AppSync vs Amplify: AppSync là công cụ đồng bộ dữ liệu real-time bằng GraphQL; Amplify là bộ khung phát triển full-stack toàn diện hơn (có thể dùng AppSync bên trong).
- AWS Backup: quản lý và tự động hóa backup tập trung cho nhiều dịch vụ AWS cùng lúc.
- 4 chiến lược DR: Backup & Restore → Pilot Light → Warm Standby → Multi-Site/Hot-Site, chi phí tăng dần, thời gian khôi phục giảm dần.
- AWS Elastic Disaster Recovery (DRS): sao chép liên tục ở cấp block để phục hồi server nhanh khi có thảm họa, dùng chung kỹ thuật với MGN nhưng cho mục đích DR dài hạn.
- DataSync vs Snowball vs Storage Gateway: DataSync đồng bộ qua network định kỳ; Snowball chuyển vật lý khi dữ liệu quá lớn/mạng yếu; Storage Gateway là cầu nối lưu trữ hoạt động liên tục.
- 7Rs di trú: Retire, Retain, Relocate, Rehost, Replatform, Repurchase, Refactor/Re-architect.
- MGN vs DMS: MGN di trú toàn bộ server (rehost); DMS chỉ di trú cơ sở dữ liệu.
- Step Functions vs FIS: Step Functions điều phối workflow hợp lệ; FIS chủ động chèn lỗi để kiểm tra độ bền vững (chaos engineering).
- Amazon Pinpoint vs SNS/SES: Pinpoint là nền tảng marketing đầy đủ (campaign, segment, template); SNS/SES là hạ tầng gửi tin nhắn cơ bản hơn.