Câu hỏi thường gặp về AWS Lambda

Mã mà bạn chạy trên AWS Lambda được tải lên dưới dạng “hàm Lambda”. Mỗi hàm có các thông tin cấu hình liên kết, ví dụ như tên, mô tả, điểm bắt đầu và các yêu cầu về tài nguyên. Mã phải được viết theo kiểu “không có trạng thái”, tức là mã phải giả định không có bố trí với cơ sở hạ tầng điện toán chạy ngầm. Khả năng truy cập hệ thống tệp cục bộ, các quá trình phụ và các thành phần lạ tương tự không được kéo dài vượt quá vòng đời của yêu cầu và mọi trạng thái bền vững đều phải được lưu trên Amazon S3, Amazon DynamoDB, Amazon EFS hoặc dịch vụ lưu trữ khác có trên Internet. Hàm Lambda có thể sử dụng các thư viện, kể cả thư viện gốc.

Để cải thiện hiệu suất, AWS Lambda có thể chọn giữ lại phiên bản hàm và sử dụng lại để phục vụ cho yêu cầu sau đó thay vì tạo bản sao mới. Để tìm hiểu thêm về cách Lambda sử dụng lại các phiên bản hàm, hãy truy cập vào tài liệu của chúng tôi. Mã của bạn không được giả định rằng điều này sẽ luôn xảy ra.

Bạn có thể cấu hình từng hàm Lambda với dung lượng lưu trữ tạm thời của riêng nó từ 512MB đến 10.240MB với gia số 1MB. Dung lượng lưu trữ tạm thời có sẵn trong thư mục /tmp của từng hàm.

Mỗi hàm có quyền truy cập 512MB dung lượng lưu trữ mà không mất thêm phí. Khi bạn cấu hình các hàm với hơn 512MB dung lượng lưu trữ tạm thời, bạn sẽ bị tính phí dựa trên dung lượng lưu trữ mà bạn cấu hình và thời gian chạy hàm của bạn, được tính theo gia số 1ms. Để so sánh, ở khu vực Miền Đông Hoa Kỳ (Ohio), giá dung lượng lưu trữ tạm thời của AWS Fargate là 0,000111 USD với mỗi GB-giờ hoặc 0,08 USD với mỗi GB-tháng. Mức định giá dung lượng lưu trữ gp3 của Amazon EBS ở Miền Đông Hoa Kỳ (Ohio) là 0,08 USD với mỗi GB-tháng. Mức định giá dung lượng lưu trữ tạm thời của AWS Lambda là 0,0000000309 USD với mỗi GB-giây hoặc 0,000111 USD với mỗi GB-giờ và 0,08 USD với mỗi GB-tháng. Để tìm hiểu thêm, hãy xem mục Định giá AWS Lambda.

Bạn có thể cấu hình từng hàm Lambda với dung lượng lưu trữ tạm thời của riêng nó từ 512MB đến 10.240MB với gia số 1MB bằng cách sử dụng bảng điều khiển AWS Lambda, API AWS Lambda, hoặc mẫu AWS CloudFormation trong quá trình tạo hay cập nhật hàm.

Có. Tất cả dữ liệu được lưu trong bộ nhớ lưu trữ tạm thời đều được mã hoá hoàn toàn bằng khoá do AWS quản lý.

Bạn có thể sử dụng các chỉ số AWS CloudWatch Lambda Insight để theo dõi việc sử dụng bộ nhớ lưu trữ tạm thời của mình. Để tìm hiểu thêm, hãy xem tài liệu về AWS CloudWatch Lambda Insight.

Nếu ứng dụng của bạn cần lưu trữ lâu dài, liên tục, hãy cân nhắc sử dụng Amazon S3 hoặc Amazon EFS. Nếu ứng dụng của bạn cần lưu trữ dữ liệu cần thiết bằng mã trong một lệnh gọi hàm duy nhất, hãy cân nhắc sử dụng bộ nhớ lưu trữ tạm thời AWS Lambda làm bộ nhớ đệm tạm thời. Để tìm hiểu thêm, vui lòng xem Lựa chọn giữa các tùy chọn lưu trữ dữ liệu của AWS Lambda trong các ứng dụng web.

Có. Tuy nhiên, nếu ứng dụng của bạn cần lưu trữ liên tục, hãy cân nhắc sử dụng Amazon EFS hoặc Amazon S3. Khi bạn bật Tính đồng thời được cung cấp cho hàm của mình, mã khởi tạo của hàm sẽ chạy trong quá trình phân bổ và cứ sau vài giờ, khi các phiên bản đang chạy của hàm được sử dụng lại. Bạn có thể xem thời gian khởi tạo trong nhật ký và truy vết sau khi một phiên bản xử lý yêu cầu. Tuy nhiên, quá trình khởi tạo vẫn sẽ được ghi lại ngay cả khi phiên bản chưa từng xử lý yêu cầu. Hành động khởi tạo của Tính đồng thời được cung cấp này có thể ảnh hưởng đến cách hàm của bạn tương tác với dữ liệu được lưu trong bộ nhớ lưu trữ tạm thời, ngay cả khi hàm đang không xử lý yêu cầu. Để tìm hiểu thêm về Tính đồng thời được cung cấp, vui lòng xem tài liệu liên quan.

Bạn có thể cấu hình từng hàm Lambda với dung lượng lưu trữ tạm thời của riêng nó từ 512MB đến 10.240MB với gia số 1MB bằng cách sử dụng bảng điều khiển AWS Lambda, API AWS Lambda, hoặc mẫu AWS CloudFormation trong quá trình tạo hay cập nhật hàm.

Có. Tất cả dữ liệu được lưu trong bộ nhớ lưu trữ tạm thời đều được mã hoá hoàn toàn bằng khoá do AWS quản lý.

Bạn có thể sử dụng các chỉ số AWS CloudWatch Lambda Insight để theo dõi việc sử dụng bộ nhớ lưu trữ tạm thời của mình. Để tìm hiểu thêm, hãy xem tài liệu về AWS CloudWatch Lambda Insight.

Việc duy trì hàm không có trạng thái cho phép AWS Lambda khởi chạy nhanh chóng số lượng bản sao cần thiết để thay đổi quy mô theo tốc độ của các sự kiện đến. Mặc dù mô hình lập trình của AWS Lambda là không có trạng thái, mã của bạn vẫn có thể truy cập dữ liệu có trạng thái bằng cách gọi các dịch vụ web khác, như Amazon S3 hoặc Amazon DynamoDB.

Có. AWS Lambda cho phép bạn sử dụng ngôn ngữ và các tính năng hệ điều hành thông thường như tạo các luồng và quy trình bổ sung. Các nguồn tài nguyên phân bổ cho hàm Lambda, bao gồm bộ nhớ, thời gian thực thi, ổ đĩa và mức sử dụng mạng, phải được chia sẻ với tất cả các luồng và quy trình mà hàm sử dụng. Bạn có thể khởi chạy các quy trình bằng bất kỳ ngôn ngữ nào Amazon Linux hỗ trợ.

Lambda cố gắng đặt ra ít hạn chế nhất có thể đối với các hoạt động ngôn ngữ và hệ điều hành thông thường, tuy nhiên, có một số hoạt động bị vô hiệu hóa: AWS Lambda chặn kết nối mạng đến và đối với kết nối đi thì chỉ hỗ trợ ổ cắm TCP/IP và UDP/IP, đồng thời các lệnh gọi hệ thống ptrace (gỡ lỗi) cũng bị chặn. Lưu lượng cổng 25 của giao thức TCP cũng bị chặn để chống thư rác.

Nếu đang sử dụng Node.js hoặc Python, bạn có thể tạo mã cho hàm bằng trình biên tập mã trên bảng điều khiển AWS Lambda, tại đó bạn có thể tạo và kiểm thử hàm, cũng như xem kết quả thực thi hàm trong một môi trường mạnh mẽ, giống như IDE. Đi tới bảng điều khiển để bắt đầu.

Bạn cũng có thể đóng gói mã (và mọi thư viện phụ thuộc) dưới dạng ZIP và tải gói lên bằng bảng điều khiển AWS Lambda từ môi trường cục bộ hoặc chỉ định vị trí Amazon S3 chứa tệp ZIP. Các tệp tải lên không được phép lớn hơn 50MB (nén). Bạn cũng có thể sử dụng phần bổ trợ AWS Eclipse để tạo và triển khai các hàm Lambda trong Java. Bạn có thể sử dụng phần bổ trợ Visual Studio để tạo và triển khai các hàm Lambda trong C# và Node.js.

Bạn cũng có thể đóng gói mã (và mọi thư viện phụ thuộc) dưới dạng ZIP và tải gói lên AWS CLI từ môi trường cục bộ hoặc chỉ định vị trí Amazon S3 chứa tệp ZIP. Các tệp tải lên không được phép lớn hơn 50MB (nén). Hãy truy cập vào mục hướng dẫn Bắt đầu với Lambda để bắt đầu.

Có. Bạn có thể dễ dàng tạo và chỉnh sửa các biến môi trường từ Bảng điều khiển, CLI hay các SDK của AWS Lambda. Để tìm hiểu thêm về các biến môi trường, hãy xem tài liệu.

Đối với thông tin nhạy cảm, như mật khẩu cơ sở dữ liệu, bạn nên sử dụng mã hóa phía máy khách thông qua Dịch vụ quản lý khóa của AWS và lưu các giá trị thu được dưới dạng bản mã trong biến môi trường. Bạn sẽ cần sử dụng logic trong mã hàm AWS Lambda để giải mã các giá trị này.

Bạn có thể điều chỉnh và bảo mật các tài nguyên được liên kết với hàm Lambda của mình bằng API hoặc bảng điều khiển Lambda. Để tìm hiểu thêm, hãy xem tài liệu.

Có, bạn có thể đóng gói mã bất kỳ (framework, SDK, thư viện, v.v.) dưới dạng Lớp Lambda và quản lý cũng như chia sẻ dễ dàng qua nhiều chức năng.

AWS Lambda tự động giám sát các hàm Lambda thay bạn, báo cáo các số liệu theo thời gian thực qua Amazon CloudWatch, bao gồm tổng số yêu cầu, mức sử dụng đồng thời ở cấp độ tài khoản và cấp độ hàm, độ trễ, tỷ lệ lỗi và số yêu cầu được điều tiết. Bạn có thể xem số liệu thống kê cho từng hàm Lambda thông qua bảng điều khiển Amazon CloudWatch hoặc thông qua bảng điều khiển AWS Lambda. Bạn cũng có thể gọi API giám sát từ bên thứ ba trong hàm Lambda của mình.
 

Hãy truy cập vào mục Khắc phục sự cố về số liệu CloudWatch để tìm hiểu thêm. Phí tiêu chuẩn đối với AWS Lambda áp dụng cho việc sử dụng số liệu tích hợp sẵn của Lambda.

AWS Lambda tự động tích hợp với Amazon CloudWatch logs, nhờ đó tạo một nhóm nhật ký cho từng hàm Lambda và cung cấp các mục nhập nhật ký sự kiện cơ bản trong vòng đời của ứng dụng, bao gồm ghi nhật ký các tài nguyên đã tiêu tốn khi sử dụng hàm đó. Bạn có thể dễ dàng chèn các câu lệnh ghi nhật ký khác vào mã của mình. Bạn cũng có thể gọi API ghi nhật ký từ bên thứ ba trong hàm Lambda của mình. Hãy truy cập vào mục Khắc phục sự cố hàm Lambda để tìm hiểu thêm. Sẽ áp dụng phí Amazon CloudWatch Logs.

Bạn không cần phải thay đổi quy mô cho các hàm Lambda – AWS Lambda thay mặt bạn tự động điều chỉnh quy mô cho các hàm. Mỗi khi nhận được thông báo sự kiện từ hàm của bạn, AWS Lambda sẽ nhanh chóng tìm vị trí công suất trống trong danh mục thiết bị điện toán và chạy mã của bạn. Vì mã của bạn không có trạng thái, AWS Lambda có thể bắt đầu bao nhiêu bản sao hàm cần thiết mà không mất thời gian trễ dài từ việc triển khai và cấu hình. Không có giới hạn cơ bản đối với việc thay đổ quy mô hàm. AWS Lambda sẽ phân bổ công suất linh hoạt để phù hợp với tốc độ của các sự kiện đến.

Trong mô hình tài nguyên AWS Lambda, bạn chọn lượng bộ nhớ mong muốn cho hàm của mình và được phân bổ công suất CPU tương ứng cũng như các tài nguyên khác. Ví dụ: khi chọn 256MB bộ nhớ, hàm Lambda của bạn sẽ nhận được công suất CPU bằng khoảng hai lần so với khi yêu cầu 128MB bộ nhớ và bằng một nửa công suất CPU so với khi chọn 512MB bộ nhớ. Để tìm hiểu thêm, hãy tham khảo tài liệu Cấu hình hàm của chúng tôi.

Bạn có thể đặt bộ nhớ của mình từ 128 MB đến 10.240 MB.

Khách hàng đang thực hiện khối lượng công việc cần nhiều dung lượng bộ nhớ hoặc nặng về tính toán giờ đã có thể dùng thêm dung lượng bộ nhớ cho các hàm của họ. Các hàm bộ nhớ lớn hơn giúp các ứng dụng đa luồng chạy nhanh hơn, nhờ đó, chúng trở nên lý tưởng với các ứng dụng nặng về dữ liệu và tính toán như máy học, các tác vụ hàng loạt và ETL, mô hình tài chính, bộ gen, HPC và xử lý đa phương tiện.

Hàm AWS Lambda có thể được cấu hình để chạy tối đa 15 phút mỗi đợt thực thi. Bạn có thể đặt thời gian chờ thành bất kỳ giá trị nào từ 1 giây đến 15 phút.

Giá của AWS Lambda được tính theo mức sử dụng. Vui lòng xem trang định giá AWS Lambda để biết chi tiết.

Có. Ngoài việc tiết kiệm tiền trên Amazon EC2 và AWS Fargate, bạn cũng có thể sử dụng Compute Savings Plans để tiết kiệm tiền trên AWS Lambda. Compute Savings Plans giảm giá tới 17% cho Thời lượng, Đồng thời được cung cấp và Thời lượng (Đồng thời được cung cấp). Compute Savings Plans không giảm giá trên các Yêu cầu trong hóa đơn Lambda của bạn. Tuy nhiên, cam kết Compute Savings Plans của bạn có thể áp dụng cho các Yêu cầu ở mức giá thông thường.

Có. Theo mặc định, mỗi hàm AWS Lambda có một phiên bản mã mới nhất, duy nhất. Các máy khách sử dụng hàm Lambda của bạn có thể gọi một phiên bản cụ thể hoặc nhận một bản thực thi mới nhất. Vui lòng đọc tài liệu về lập phiên bản hàm Lambda của chúng tôi.

Thời gian triển khai có thể thay đổi theo kích thước của mã, tuy nhiên các hàm AWS Lambda thường sẵn sàng gọi sau khi tải lên vài giây.

Có. Bạn có thể đưa vào sử dụng phiên bản thư viện của riêng mình (bao gồm cả SDK AWS) để dùng một phiên bản không phải phiên bản mặc định do AWS Lambda cung cấp.

AWS Lambda cung cấp các bậc định giá chiết khấu cho thời lượng sử dụng hàm theo nhu cầu hàng tháng trên các ngưỡng nhất định. Định giá theo bậc khả dụng đối với các hàm chạy trên cả hai kiến trúc x86 và Arm. Các bậc định giá của Lambda được áp dụng để tổng hợp thời lượng sử dụng hàm theo nhu cầu hàng tháng, trong đó những hàm này chạy trên cùng một kiến trúc (tương ứng là x86 hoặc Arm), trong cùng một khu vực của tài khoản. Nếu bạn đang sử dụng phương thức thanh toán tổng hợp trong Tổ chức AWS, các bậc định giá được áp dụng cho thời lượng sử dụng hàm tổng hợp hàng tháng của bạn, trong đó những hàm này chạy trên cùng một kiến trúc, trong cùng một khu vực, trên các tài khoản của tổ chức. Ví dụ: nếu bạn đang chạy các hàm Lambda x86 ở khu vực Miền Đông Hoa Kỳ (Ohio), bạn sẽ trả 0,0000166667 USD cho mỗi GB-giây cho 6 tỷ GB-giây đầu tiên mỗi tháng, 0,0000150000 USD cho mỗi GB-giây cho 9 tỷ GB-giây tiếp theo mỗi tháng và 0,0000133334 USD cho mỗi GB-giây trên 15 tỷ GB-giây mỗi tháng, ở khu vực đó. Mức định giá dành cho Truy vấn, Tính đồng thời được cung cấp và Thời lượng đồng thời được cung cấp vẫn không thay đổi. Để biết thêm thông tin, vui lòng xem Định giá AWS Lambda

Có. Mức sử dụng Lambda được bao trả trong cam kết của gói tiết kiệm theo giờ của bạn sẽ được tính theo mức giá và chiết khấu hiện hành của nhà cung cấp dịch vụ đám mây (CSP). Mức sử dụng còn lại không được cam kết này bao trả sẽ được tính theo mức giá tương ứng với bậc của thời lượng sử dụng hàm tổng hợp hàng tháng của bạn.

Nguồn sự kiện là một dịch vụ AWS hoặc một ứng dụng do nhà phát triển xây dựng tạo ra các sự kiện kích hoạt chạy một hàm AWS Lambda. Một số dịch vụ công bố các sự kiện này với Lambda bằng cách trực tiếp gọi ra chức năng đám mây (ví dụ: Amazon S3). Lambda cũng có thể thăm dò tài nguyên trong các dịch vụ khác không công bố sự kiện với Lambda. Ví dụ: Lambda có thể lấy bản ghi từ luồng Amazon Kinesis hoặc hàng đợi Amazon SQS và thực thi hàm Lambda cho mỗi tin nhắn được truy cập. Nhiều dịch vụ khác, chẳng hạn như AWS CloudTrail, có thể hoạt động như nguồn sự kiện chỉ bằng cách đăng nhập vào Amazon S3 và dùng thông báo vùng lưu trữ S3 để kích hoạt các hàm AWS Lambda

Vui lòng xem tài liệu của chúng tôi để biết danh sách đầy đủ các nguồn sự kiện.

Các sự kiện được gửi đến hàm Lambda với tư cách là tham số đầu vào sự kiện. Đối với các nguồn sự kiện mà sự kiện đến theo lô, ví dụ như Amazon SQS, Amazon Kinesis và Amazon DynamoDB Streams, tham số sự kiện có thể chứa nhiều sự kiện trong một lệnh gọi đơn lẻ, tùy theo kích thước lô mà bạn yêu cầu. Để tìm hiểu thêm về thông báo sự kiện của Amazon S3, hãy truy cập vào Cấu hình thông báo cho các sự kiện của Amazon S3. Để tìm hiểu thêm về Luồng Amazon DynamoDB, hãy truy cập vào mục Hướng dẫn cho nhà phát triển luồng DynamoDB. Để tìm hiểu thêm về cách gọi các hàm Lambda bằng Amazon SNS, hãy truy cập vào Hướng dẫn dành cho nhà phát triển Amazon SNS. Để biết thêm thông tin về các sự kiện của Amazon Cognito, hãy truy cập vào Amazon Cognito. Để biết thêm thông tin về nhật ký AWS CloudTrail và kiểm tra các lệnh gọi API trên nhiều dịch vụ AWS, hãy xem AWS CloudTrail.

Từ bảng điều khiển AWS Lambda, bạn có thể chọn một hàm và liên kết hàm đó với các thông báo từ bộ chứa Amazon S3. Hoặc, bạn có thể sử dụng bảng điều khiển Amazon S3 và cấu hình để các thông báo của bộ chứa gửi đến hàm AWS Lambda của bạn. Chức năng tương tự này cũng có sẵn thông qua AWS SDK và AWS CLI.

Bạn có thể kích hoạt hàm Lambda trên các bản cập nhật bảng DynamoDB bằng cách đăng ký hàm Lambda với Luồng DynamoDB liên kết với bảng. Bạn có thể liên kết một Luồng DynamoDB với hàm Lambda bằng bảng điều khiển Amazon DynamoDB, bảng điều khiển AWS Lambda hoặc API registerEventSource của Lambda.

Từ bảng điều khiển AWS Lambda, bạn có thể chọn một hàm và liên kết hàm đó với một luồng Amazon Kinesis được sở hữu bởi cùng tài khoản. Chức năng tương tự này cũng có sẵn thông qua AWS SDK và AWS CLI.

Các bản ghi của Amazon Kinesis và DynamoDB Streams đã gửi đến hàm AWS Lambda của bạn được xếp số thứ tự chặt chẽ trên mỗi phân đoạn. Điều này đồng nghĩa rằng, nếu bạn đặt hai bản ghi trong cùng một phân đoạn, Lambda đảm bảo hàm Lambda của bạn sẽ được gọi ra thành công bằng bản ghi đầu tiên trước khi được gọi bằng bản ghi thứ hai. Nếu yêu cầu gọi cho một bản ghi hết thời gian chờ, được điều tiết, hay gặp bất kỳ lỗi nào khác, Lambda sẽ thử lại cho đến khi thao tác gọi thành công (hoặc bản ghi đạt đến thời gian hết hạn sau 24 giờ) trước khi chuyển sang bản ghi tiếp theo. Không có đảm bảo về thứ tự của các bản ghi trên các phân mảnh khác nhau và quá trình xử lý từng phân mảnh diễn ra song song.

AWS Lambda cho phép bạn thực hiện các phép tổng hợp dựa trên thời gian (chẳng hạn như phép count, max, sum, average (đếm, lớn nhất, tổng, trung bình), v.v.) trong một khoảng thời gian ngắn kéo dài tối đa 15 phút cho dữ liệu trong Amazon Kinesis hoặc Luồng Amazon DynamoDB trên một phân vùng logic đơn lẻ, ví dụ như một phân mảnh. Như vậy, bạn có thể dễ dàng thiết lập phân tích đơn giản cho ứng dụng dựa trên sự kiện mà không làm tăng thêm sự phức tạp về kiến trúc, vì logic kinh doanh và phân tích của bạn có thể được đặt trong cùng một hàm. Lambda hỗ trợ các phép tổng hợp trong khung thời gian cố định tối đa là 15 phút, dựa trên dấu thời gian sự kiện. Phân tích dữ liệu Amazon Kinesis cho phép bạn xây dựng các ứng dụng phân tích phức tạp hơn để hỗ trợ các lựa chọn xử lý linh hoạt và khả năng chịu lỗi mạnh mẽ với quá trình xử lý chính xác một lần không trùng lặp, cũng như xây dựng phép phân tích có thể được thực hiện trên toàn bộ luồng dữ liệu ở nhiều phân vùng logic. Với KDA, bạn có thể phân tích dữ liệu qua nhiều loại khung thời gian tổng hợp (khung thời gian cố định, khung thời gian linh hoạt, khung thời gian trượt, khung thời gian phiên) bằng cách sử dụng thời gian diễn ra sự kiện hoặc thời gian xử lý.
 

	AWS Lambda	Amazon KDA
Khung thời gian cố định	Có	Có
Khung thời gian linh hoạt	Không	Có
Khung thời gian trượt	Không	Có
Khung thời gian phiên	Không	Có
Bổ sung	Không	Có
Bảng đầu vào chung và bảng tham chiếu	Không	Có
Luồng đầu vào phân tách	Không	Có
Xử lý chính xác một lần	Không	Có
Khung thời gian tối đa	15 phút	Không có giới hạn
Phạm vi tổng hợp	Phân vùng/phân mảnh	Luồng
Ngữ nghĩa thời gian	Thời gian diễn ra sự kiện	Thời gian diễn ra sự kiện, Thời gian xử lý

Từ bảng điều khiển AWS Lambda, bạn có thể chọn một hàm và liên kết hàm đó với một chủ đề Amazon SNS. Chức năng tương tự này cũng có sẵn thông qua AWS SDK và AWS CLI.

Từ bảng điều khiển Amazon SES, bạn có thể thiết lập quy tắc nhận để Amazon SES cung cấp thông điệp đến hàm AWS Lambda. Chức năng tương tự có sẵn thông qua AWS SDK và AWS CLI.

Trước tiên, hãy cấu hình cảnh báo để gửi các thông báo của Amazon SNS. Sau đó, từ bảng điều khiển AWS Lambda, chọn một hàm Lambda và liên kết hàm đó với một chủ đề Amazon SNS. Xem Hướng dẫn dành cho nhà phát triển Amazon CloudWatch để tìm hiểu thêm về cách thiết lập cảnh báo của Amazon CloudWatch.

Từ bảng điều khiển AWS Lambda, bạn có thể chọn một hàm để kích hoạt khi bất kỳ tập dữ liệu nào liên kết với nhóm danh tính Amazon Cognito được đồng bộ hóa. Chức năng tương tự này cũng có sẵn thông qua AWS SDK và AWS CLI. Tham khảo Amazon Cognito để biết thêm thông tin về cách sử dụng Amazon Cognito cho việc chia sẻ và đồng bộ hóa dữ liệu trên nhiều thiết bị của một người dùng.

Bạn có thể gọi ra một hàm Lambda bằng sự kiện tùy chỉnh thông qua API gọi của AWS Lambda. Chỉ chủ sở hữu của hàm hoặc một tài khoản AWS khác được chủ sở hữu cấp quyền mới có thể gọi ra hàm. Hãy truy cập vào mục Hướng dẫn dành cho nhà phát triển Lambda để tìm hiểu thêm.

AWS Lambda được thiết kế để xử lý các sự kiện trong vài mili giây. Độ trễ sẽ cao hơn ngay sau khi hàm Lambda được tạo, cập nhật hoặc nếu hàm không được sử dụng gần đây.

Bạn tải mã cần AWS Lambda thực thi lên, sau đó gọi mã ra từ ứng dụng di động bằng AWS Lambda SDK có trong AWS Mobile SDK. Bạn có thể tạo cả các lệnh gọi trực tiếp (đồng bộ) để truy xuất hoặc kiểm tra dữ liệu trong thời gian thực cũng như các lệnh gọi không đồng bộ. Bạn cũng có thể xác định một API tùy chỉnh bằng Amazon API Gateway và gọi ra các hàm Lambda thông qua bất kỳ máy khách nào tương thích với REST. Để tìm hiểu thêm về SDK di động của AWS, hãy truy cập vào trang SDK di động của AWS. Để tìm hiểu thêm về Cổng API Amazon, hãy truy cập vào trang Cổng API Amazon.

Bạn có thể gọi ra một hàm Lambda qua HTTPS bằng cách xác định một API RESTful tùy chỉnh bằng Amazon API Gateway. Thao tác này cung cấp cho bạn một điểm cuối cho hàm có thể phản hồi với các lệnh gọi REST như GET, PUT và POST. Đọc thêm về cách sử dụng AWS Lambda với Amazon API Gateway.

Khi được gọi thông qua AWS Mobile SDK, các hàm AWS Lambda tự động nhận được thông tin chuyên sâu về thiết bị và ứng dụng đã thực hiện lời gọi thông qua đối tượng ‘ngữ cảnh’.

Khi ứng dụng của bạn sử dụng thông tin định danh từ Amazon Cognito, người dùng cuối có thể tự xác thực bằng nhiều nhà cung cấp thông tin đăng nhập công cộng như Amazon, Facebook, Google và các dịch vụ khác tương thích với OpenID Connect. Sau đó, thông tin định danh của người dùng được trình diện một cách tự động và bảo mật với hàm Lambda của bạn dưới dạng thông tin định danh từ Amazon Cognito, cho phép hàm truy cập dữ liệu người dùng từ Amazon Cognito hoặc dưới dạng khóa để lưu trữ và truy xuất dữ liệu trong Amazon DynamoDB hoặc các dịch vụ web khác.

AWS Lambda được tích hợp với Bộ công cụ kỹ năng Alexa, một tập hợp các API, công cụ, tài liệu hướng dẫn và các mã mẫu để bạn tự tìm hiểu, từ đó bạn có thể dễ dàng tạo các chức năng (hoặc “kỹ năng”) được điều khiển bằng giọng nói cho Alexa. Bạn chỉ việc tải mã hàm Lambda lên cho kỹ năng Alexa mới mà bạn đang tạo và AWS Lambda sẽ làm công việc còn lại, thực thi mã để phản hồi với các tương tác qua giọng nói của Alexa và thay bạn tự động quản lý các tài nguyên điện toán. Đọc tài liệu về Bộ công cụ kỹ năng Alexa để biết thêm chi tiết.

Đối với các thông báo và sự kiện tùy chỉnh của bộ chứa Amazon S3, AWS Lambda sẽ cố gắng thực thi hàm của bạn ba lần nếu có tình trạng lỗi trong mã hoặc nếu bạn vượt quá giới hạn dịch vụ hoặc tài nguyên. Đối với các nguồn sự kiện đã yêu cầu mà AWS Lambda thay bạn thăm dò, ví dụ như các luồng Amazon DynamoDB và các luồng Amazon Kinesis, Lambda sẽ tiếp tục cố gắng thực hiện khi mã của nhà phát triển gặp lỗi cho đến khi dữ liệu hết hạn. Bạn có thể giám sát tiến trình thông qua bảng điều khiển Amazon Kinesis và Amazon DynamoDB, cũng như qua số liệu của Amazon CloudWatch mà AWS Lambda tạo ra cho hàm của bạn. Bạn cũng có thể đặt các cảnh báo Amazon CloudWatch dựa trên tỷ lệ lỗi hoặc tốc độ điều tiết thực thi.

Ứng dụng dựa trên Lambda (còn gọi là ứng dụng serverless) được cấu thành từ các hàm kích hoạt bằng sự kiện. Một ứng dụng serverless tiêu biểu bao gồm một hoặc nhiều hàm kích hoạt bằng các sự kiện chẳng hạn như các lượt tải đối tượng lên Amazon S3, các thông báo của Amazon SNS hoặc các hành động trên API. Các chức năng này có thể đứng độc lập hay tận dụng các tài nguyên khác như bảng DynamoDB hoặc bộ chứa Amazon S3. Ứng dụng serverless cơ bản nhất chỉ đơn giản là một hàm.

Bạn có thể triển khai và quản lý các ứng dụng serverless bằng Mô hình ứng dụng serverless của AWS (AWS SAM). AWS SAM là một chỉ dẫn kỹ thuật quy định các quy tắc biểu diễn các ứng dụng serverless trên AWS. Chỉ dẫn kỹ thuật này phù hợp với cú pháp mà AWS CloudFormation đang sử dụng và được hỗ trợ gốc trên AWS CloudFormation dưới dạng tập hợp các loại tài nguyên (được gọi là “tài nguyên phi máy chủ”). Các tài nguyên này giúp khách hàng AWS sử dụng CloudFormation dễ dàng hơn trong việc cấu hình và triển khai các ứng dụng phi máy chủ thông qua những API CloudFormation hiện tại.

Bạn có thể chọn từ tuyển tập các ứng dụng phi máy chủ do các nhà phát triển, các công ty và các đối tác phát hành trong cộng đồng AWS thông qua Kho ứng dụng phi máy chủ AWS. Sau khi tìm được một ứng dụng, bạn có thể cấu hình và triển khai ứng dụng đó trực tiếp từ bảng điều khiển Lambda.

Bạn có thể tự động hóa quá trình phát hành ứng dụng phi máy chủ bằng AWS CodePipeline và AWS CodeDeploy. CodePipeline là một dịch vụ phân phối liên tục cho phép bạn mô hình hóa, hình ảnh hóa và tự động hóa các bước cần thiết để phát hành ứng dụng phi máy chủ. CodeDeploy cung cấp công cụ tự động hóa triển khai cho các ứng dụng dựa trên Lambda. CodeDeploy cho phép bạn điều phối các hoạt động triển khai theo các phương pháp thực hành tốt nhất, ví dụ như quy trình triển khai canary hoặc tuyến tính, đồng thời giúp bạn thiết lập được hành lang bảo vệ cần thiết để xác minh mã mới phát triển đảm bảo an toàn, ổn định và sẵn sàng phát hành hoàn toàn vào sản xuất.
 

Để tìm hiểu thêm về CI/CD phi máy chủ, hãy truy cập vào tài liệu của chúng tôi.

Để bắt đầu, hãy truy cập bảng điều khiển AWS Lambda và tải xuống một trong các bản kế hoạch của chúng tôi. Tệp tải xuống sẽ bao gồm một tệp AWS SAM (xác định các tài nguyên của AWS trong ứng dụng của bạn) và một tệp .ZIP (chứa mã của hàm của bạn). Sau đó, bạn có thể sử dụng các lệnh AWS CloudFormation để đóng gói và triển khai ứng dụng phi máy chủ mà bạn vừa tải xuống. Để biết thêm chi tiết, hãy truy cập vào tài liệu của chúng tôi.

Bạn có thể sử dụng AWS Step Functions để điều phối một loạt các hàm AWS Lambda theo trình tự cụ thể. Bạn có thể gọi ra các hàm Lambda theo cách tuần tự, chuyển đầu ra của một hàm đến hàm khác, hoặc chuyển song song và Step Functions sẽ giúp bạn giữ nguyên trạng thái trong các thao tác thực thi.

Bạn có thể cho phép hàm Lambda dò vết thông qua AWS X-Ray bằng cách bổ sung các quyền X-Ray cho vai trò thực thi của hàm Lambda và chuyển “tracing mode” (chế độ dò vết) của hàm sang “active” (hoạt động). Khi X-Ray được kích hoạt cho hàm Lambda, AWS Lambda sẽ phát thông tin dò vết đến X-Ray về chi phí dịch vụ Lambda phát sinh khi gọi hàm của bạn. Hoạt động này sẽ cung cấp cho bạn các thông tin chuyên sâu như chi phí dịch vụ Lambda, thời gian khởi tạo hàm và thời gian thực thi hàm. Ngoài ra, bạn có thể đưa X-Ray SDK vào trong gói triển khai Lambda để tạo các đoạn vết của riêng mình, chú thích cho các vết hoặc xem các đoạn vết cho các lời gọi xuôi chiều được thực hiện từ hàm Lambda. X-Ray SDK hiện đã có sẵn cho Node.js và Java. Hãy truy cập vào mục Khắc phục sự cố ứng dụng dựa trên Lambda để tìm hiểu thêm. Phí AWS X-Ray sẽ áp dụng.

Có. Bạn có thể sử dụng Proxy cho Amazon RDS, một proxy cơ sở dữ liệu có độ sẵn sàng cao quản lý hàng ngàn kết nối đồng thời với cơ sở dữ liệu quan hệ, để xây dựng các ứng dụng phi máy chủ dựa trên Lambda an toàn và có quy mô linh hoạt kết nối với cơ sở dữ liệu quan hệ. Hiện tại, RDS Proxy hỗ trợ các cơ sở dữ liệu MySQL và Aurora. Bạn có thể bắt đầu sử dụng RDS Proxy thông qua bảng điều khiển Amazon RDS hoặc bảng điều khiển AWS Lambda. Các ứng dụng phi máy chủ sử dụng nhóm kết nối được quản lý toàn phần từ Proxy RDS sẽ được tính phí theo Giá Proxy RDS.

Chỉ dẫn kỹ thuật có nguồn mở theo Apache 2.0 cho phép bạn và người khác áp dụng cũng như tích hợp AWS SAM vào các công cụ xây dựng, triển khai, giám sát và quản lý bằng một giấy phép có lợi cho hoạt động thương mại. Bạn có thể truy cập kho AWS SAM trên GitHub tại đây.

AWS Lambda hiện cho phép bạn đóng gói và triển khai các hàm dưới dạng hình ảnh bộ chứa. Khách hàng có thể tận dụng sự linh hoạt và sự quen thuộc của công cụ bộ chứa, cũng như sự linh hoạt và đơn giản trong hoạt động của AWS Lambda để xây dựng các ứng dụng.

Bạn có thể bắt đầu với hình ảnh cơ sở do AWS cung cấp cho Lambda hoặc bằng cách sử dụng một trong những hình ảnh cộng đồng hoặc doanh nghiệp tư nhân ưa thích của bạn. Sau đó, chỉ cần sử dụng Docker CLI để xây dựng hình ảnh, tải nó lên Amazon ECR rồi tạo hàm bằng mọi công cụ và giao diện Lambda quen thuộc, ví dụ như Bảng điều khiển quản lý AWS, AWS CLI, AWS SDK, AWS SAM và AWS CloudFormation.

Bên cạnh các hình ảnh do Lambda cung cấp, bạn có thể triển khai hình ảnh cơ sở Linux của bên thứ ba (ví dụ: Alpine hoặc Debian) cho Lambda. AWS Lambda sẽ hỗ trợ mọi hình ảnh dựa trên các định dạng tệp kê khai hình ảnh sau: Docker Image Manifest V2 Schema 2 (được sử dụng với Docker phiên bản 1.10 trở lên) hoặc Open Container Initiative (OCI) Spec (v1.0 trở lên). Lambda hỗ trợ hình ảnh có kích cỡ lên đến 10 GB.

AWS Lambda cung cấp nhiều loại hình ảnh cơ sở mà khách hàng có thể mở rộng, đồng thời, khách hàng cũng có thể sử dụng các hình ảnh nền Linux ưa thích của mình với kích cỡ lên đến 10 GB.

Bạn có thể sử dụng bất kỳ công cụ bộ chứa nào miễn là công cụ đó có hỗ trợ một trong các định dạng tệp kê khai hình ảnh bộ chứa sau: Docker Image Manifest V2 Schema 2 (được sử dụng với Docker phiên bản 1.10 trở lên) hoặc Thông số kỹ thuật Open Container Initiative (OCI) (v1.0 trở lên). Ví dụ: Bạn có thể sử dụng các công cụ bộ chứa gốc (ví dụ: docker run, docker compose, Buildah và Packer) để xác định các hàm của mình dưới dạng hình ảnh bộ chứa và triển khai tới Lambda.

Mọi tính năng AWS Lambda hiện có, ngoại trừ các lớp Lambda và Ký mã, đều có thể được sử dụng với các hàm được triển khai dưới dạng hình ảnh bộ chứa. Sau khi được triển khai, AWS Lambda sẽ coi một hình ảnh là bất biến. Khách hàng có thể sử dụng các lớp bộ chứa trong khi xây dựng để đưa các phần phụ thuộc vào.

Vào thời điểm này thì không. Hình ảnh của bạn, sau khi được triển khai tới AWS Lambda, sẽ không thay đổi. Dịch vụ sẽ không vá hay cập nhật hình ảnh. Tuy nhiên, AWS Lambda sẽ phát hành các hình ảnh cơ sở được sắp xếp cho toàn bộ thời gian hoạt động được hỗ trợ dựa trên môi trường được quản lý bởi Lambda. Những hình ảnh đã phát hành này sẽ được vá và cập nhật cùng với các bản cập nhật cho thời gian chạy được quản lý của AWS Lambda. Bạn có thể kéo và sử dụng hình ảnh cơ sở mới nhất từ DockerHub hoặc Amazon ECR Public, xây dựng lại hình ảnh bộ chứa của bạn và triển khai lên AWS Lambda thông qua Amazon ECR. Điều này cho phép bạn xây dựng và kiểm tra các hình ảnh và thời gian hoạt động đã cập nhật, trước khi triển khai hình ảnh vào sản xuất

Có ba điểm khác biệt chính giữa các hàm được tạo bằng lưu trữ ZIP và hình ảnh bộ chứa:

1. Các hàm được tạo bằng cách sử dụng lưu trữ ZIP có kích cỡ gói mã tối đa là 250 MB đã giải nén và các hàm được tạo bằng hình ảnh bộ chứa có kích thước hình ảnh tối đa là 10 GB. 
2. Lambda sử dụng Amazon ECR làm bộ lưu trữ mã cơ bản cho các hàm được xác định là hình ảnh bộ chứa, do đó, một hàm có thể không được thu hồi khi hình ảnh cơ bản bị xóa khỏi ECR. 
3. Các hàm ZIP được vá tự động trong các bản sửa lỗi và bảo mật thời gian hoạt động mới nhất. Các hàm được định nghĩa là hình ảnh bộ chứa đều bất biến và khách hàng phải chịu trách nhiệm về các thành phần được đóng gói trong hàm của họ. Khách hàng có thể tận dụng các hình ảnh cơ sở do AWS cung cấp được AWS cập nhật thường xuyên để bảo mật và sửa lỗi, bằng cách sử dụng các bản vá mới nhất hiện có.

Không - AWS Lambda đảm bảo rằng cấu hình hiệu năng cho các hàm được đóng gói dưới dạng hình ảnh bộ chứa cũng giống như các cấu hình được đóng gói dưới dạng lưu trữ ZIP, bao gồm cả thời gian khởi động thường tính bằng mili giây.

Không có phí bổ sung cho việc đóng gói và triển khai các hàm dưới dạng hình ảnh bộ chứa lên AWS Lambda. Khi bạn thu hồi hàm được triển khai dưới dạng hình ảnh bộ chứa, bạn sẽ thanh toán cho các yêu cầu và thời lượng thực thi theo giá thông thường. Để tìm hiểu thêm, hãy truy cập vào mục giá AWS Lambda. Bạn sẽ bị tính phí lưu trữ hình ảnh bộ chứa của mình trong Amazon ECR với mức giá ECR tiêu chuẩn. Để tìm hiểu thêm, hãy truy cập vào mục giá Amazon ECR.

Lambda Runtime Interface Emulator là một proxy API Thời gian chạy của Lambda, cho phép khách hàng kiểm thử cục bộ hàm Lambda được đóng gói dưới dạng hình ảnh bộ chứa. Đây là một máy chủ web gọn nhẹ chuyển đổi yêu cầu HTTP thành sự kiện JSON và mô phỏng API thời gian chạy của Lambda. Thành phần này cho phép bạn kiểm thử cục bộ các hàm của mình bằng các công cụ quen thuộc như cURL và Docker CLI (khi kiểm thử các hàm được đóng gói dưới dạng hình ảnh bộ chứa). Lambda Runtime Interface Emulator cũng đơn giản hóa việc chạy ứng dụng của bạn trên các dịch vụ điện toán bổ sung. Bạn có thể đưa Lambda Runtime Interface Emulator vào trong hình ảnh bộ chứa của mình để thành phần này chấp nhận các yêu cầu HTTP nguyên bản thay vì các sự kiện JSON cần thiết để triển khai tới Lambda. Thành phần này không mô phỏng trình điều phối của Lambda hay cấu hình bảo mật và xác thực. Runtime Interface Emulator có nguồn mở trên GitHub. Bạn có thể bắt đầu bằng cách tải xuống và cài đặt thành phần này lên máy cục bộ của mình.

API Thời gian hoạt động của Lambda trong dịch vụ Lambda đang chạy chấp nhận các sự kiện JSON và trả về phản hồi. Lambda Runtime Interface Emulator cho phép hàm được đóng gói dưới dạng hình ảnh bộ chứa để chấp nhận các yêu cầu HTTP trong quá trình kiểm thử cục bộ bằng các công cụ như cURL và hiển thị chúng qua cùng một giao diện cục bộ cho hàm. Thành phần này cho phép bạn sử dụng lệnh docker run hoặc docker-compose up để kiểm thử cục bộ ứng dụng lambda của bạn.

Bạn có thể sử dụng trình giả lập để kiểm thử xem mã hàm của bạn có tương thích với môi trường Lambda, chạy thành công và cung cấp đầu ra mong đợi hay không. Ví dụ: Bạn có thể kiểm thử sự kiện thử nghiệm từ các nguồn sự kiện khác nhau. Bạn cũng có thể sử dụng thành phần này để kiểm tra tiện ích mở rộng và tác nhân được tích hợp trong hình ảnh bộ chứa dựa trên API Tiện ích mở rộng của Lambda.

Khách hàng có thể thêm Runtime Interface Emulator làm điểm nhập cho hình ảnh bộ chứa hoặc đóng gói thành phần này dưới dạng một thành phần đồng hành để đảm bảo hình ảnh bộ chứa hiện chấp nhận các yêu cầu HTTP thay vì các sự kiện JSON. Điều này đơn giản hóa các thay đổi cần thiết để chạy hình ảnh bộ chứa trên các dịch vụ điện toán bổ sung. Khách hàng sẽ chịu trách nhiệm đảm bảo tuân theo tất cả các biện pháp tốt nhất về bảo mật, hiệu năng và tính đồng thời cho môi trường họ chọn. RIE được đóng gói sẵn trong các hình ảnh do AWS Lambda cung cấp và có sẵn theo mặc định trong AWS SAM CLI. Các nhà cung cấp hình ảnh cơ sở có thể dùng tài liệu này để cung cấp trải nghiệm tương tự cho hình ảnh cơ sở của họ.

Bạn có thể triển khai một ứng dụng được chứa trong AWS Lambda nếu ứng dụng đáp ứng các yêu cầu dưới đây:

1. Hình ảnh bộ chứa phải triển khai API Thời gian hoạt động của Lambda. Chúng tôi đã tạo nguồn mở cho một bộ các gói phần mềm, Máy khách giao diện thời gian hoạt động (RIC), có tác dụng triển khai API Hoạt động nhằm cho phép bạn mở rộng liền mạch các hình ảnh cơ sở ưa thích của mình để tương thích với Lambda.
2. Hình ảnh bộ chứa phải chạy được trên hệ thống tệp chỉ đọc. Mã hàm của bạn có thể truy cập 512 MB dung lượng lưu trữ của thư mục /tmp có thể ghi. Nếu bạn đang sử dụng hình ảnh yêu cầu thư mục gốc có thể ghi, hãy định cấu hình hình ảnh để ghi vào thư mục /tmp.
3. Người dùng Lambda mặc định có thể đọc các tệp cần thiết để thực thi mã hàm. Lambda định nghĩa người dùng Linux mặc định có ít đặc quyền nhất dựa theo các biện pháp bảo mật tốt nhất. Bạn cần xác minh rằng mã ứng dụng của mình không dựa vào các tệp bị hạn chế thực thi bởi những người dùng Linux khác.
4. Đây là một hình ảnh bộ chứa nền Linux.

AWS SnapStart có thể cải thiện hiệu năng khởi động từ vài giây xuống chưa tới một giây đối với các ứng dụng có yêu cầu cao về độ trễ. SnapStart hoạt động bằng cách tạo ảnh chụp nhanh cho trạng thái bộ nhớ (và ổ đĩa) đã khởi tạo cho hàm của bạn và lưu ảnh chụp nhanh đó vào bộ nhớ đệm để giúp truy cập với độ trễ thấp. Khi hàm của bạn được gọi sau đó, Lambda sẽ tiếp tục vận hành môi trường thực thi từ ảnh chụp nhanh đã khởi tạo trước này thay vì khởi tạo chúng lại từ đầu, nhờ đó cải thiện độ trễ khi khởi động. Để có khả năng phục hồi, Lambda duy trì các bản sao của ảnh chụp nhanh trong bộ nhớ đệm và tự động áp dụng các bản cập nhật phần mềm, chẳng hạn như nâng cấp thời gian hoạt động và các bản vá bảo mật cho chúng.

Lambda SnapStart là cấu hình đơn giản ở cấp độ hàm, có thể được cấu hình cho các hàm mới và hiện có bằng cách sử dụng API Lambda, Bảng điều khiển quản lý AWS, Giao diện dòng lệnh (CLI) AWS, SDK AWS, Bộ phát triển đám mây (CDK) AWS, AWS CloudFormation và Mô hình ứng dụng phi máy chủ (SAM) AWS. Khi bạn cấu hình Lambda SnapStart, mọi phiên bản hàm được xuất bản sau đó đều được hưởng lợi ích nhờ tác dụng cải thiện hiệu suất khởi động mà Lambda SnapStart mang lại. Để tìm hiểu thêm về Lambda SnapStart, hãy xem tài liệu.

Lambda SnapStart là tính năng tối ưu hóa hiệu năng, giúp các hàm của bạn đạt được thời gian khởi động nhanh hơn bằng cách giảm độ trễ thay đổi phát sinh trong quá trình thực thi mã khởi tạo một lần. Mặc dù làm giảm độ trễ khởi động, Lambda SnapStart chỉ là công cụ tối ưu hóa nỗ lực cao nhất và không đảm bảo loại bỏ khởi động nguội. Nếu ứng dụng của bạn có các yêu cầu nghiêm ngặt về độ trễ và cần có thời gian khởi động trên mười mili giây, chúng tôi khuyên bạn nên sử dụng PC.

Lambda SnapStart hỗ trợ nhiều thời gian hoạt động, bao gồm Java 11 (và mới hơn), Python 3.12 (và mới hơn) và .NET 8 (và mới hơn). Các phiên bản thời gian hoạt động trong tương lai sẽ được hỗ trợ sau khi được phát hành. Để biết tất cả các thời gian chạy mà Lambda hỗ trợ, vui lòng tham khảo tài liệu thời gian chạy Lambda.

Không. Không thể kích hoạt cả Lambda SnapStart và PC đồng thời trên cùng một hàm.

Có. Bạn có thể định cấu hình hàm Lambda SnapStart để truy cập các tài nguyên trong đám mây riêng ảo (VPC). Để biết thêm thông tin về cách định cấu hình hàm của bạn với VPC, vui lòng tham khảo tài liệu về Lambda.

Có. Bạn có thể cấu hình Lambda SnapStart cho các hàm chạy trên cả kiến trúc x86 và Arm.

Không. Bạn không thể kích hoạt Lambda SnapStart với Amazon EFS tại thời điểm này.

Không. Bạn không thể kích hoạt Lambda SnapStart với dung lượng lưu trữ tạm thời (/tmp) trên 512 MB tại thời điểm này.

Có. Nếu mã của bạn có trạng thái duy nhất, bạn cần đánh giá khả năng phục hồi của mã đối với các hoạt động của bản kết xuất nhanh (chẳng hạn như sao chép và khôi phục). Để tìm hiểu thêm về các cân nhắc về tính duy nhất với Lambda SnapStart, vui lòng tham khảo tài liệu và blog để hiểu về tính duy nhất trong các bản kết xuất nhanh VM với Lambda SnapStart.

Có. Bạn có thể triển khai logic phần mềm của riêng mình trước khi tạo (tạo điểm kiểm tra) bản kết xuất nhanh và sau khi khôi phục bản kết xuất nhanh bằng hook thời gian chạy. Để tìm hiểu thêm, vui lòng tham khảo tài liệu Lambda SnapStart.

Có, bạn sẽ bị tính phí cho việc lưu trữ ảnh chụp nhanh trong khoảng thời gian mà phiên bản hàm của bạn hoạt động, trong tối thiểu 3 giờ và mỗi mili giây sau đó. Mức giá phụ thuộc vào dung lượng bộ nhớ bạn phân bổ cho hàm của mình. Bạn cũng bị tính phí mỗi khi Lambda tiếp tục vận hành môi trường thực thi bằng cách khôi phục ảnh chụp nhanh của bạn, với giá tùy thuộc vào lượng bộ nhớ bạn phân bổ cho hàm của mình. Để tìm hiểu thêm về cách định giá SnapStart, vui lòng truy cập trang Định giá AWS Lambda.

Cách định giá SnapStart không áp dụng cho các thời gian hoạt động được quản lý bởi Java được hỗ trợ, vốn chỉ có thể lưu trữ ảnh chụp nhanh trong tối đa 14 ngày.

Tương tự như tất cả các hàm Lambda, phí thời lượng cũng được áp dụng cho các hàm SnapStart. Đối với các hàm sử dụng SnapStart, thời lượng bao gồm thời gian tải cho thời gian hoạt động, bất kỳ mã nào chạy trong hook thời gian hoạt động và mã khởi tạo được thực thi trong quá trình tạo bản sao ảnh chụp nhanh để đảm bảo khả năng phục hồi.

Với Lambda SnapStart dành cho Python và .NET, ảnh chụp nhanh hàm của bạn vẫn sẽ hoạt động miễn là hàm của bạn hoạt động. Đối với các hàm Java, ảnh chụp nhanh liên kết với một hàm đã phát hành sẽ hết hạn nếu không hoạt động trong hơn 14 ngày.

Bản kết xuất nhanh được mã hóa mặc định với các khóa của Dịch vụ quản lý khóa của AWS (KMS) duy nhất cho từng khách hàng và được dịch vụ Lambda sở hữu và quản lý. Khách hàng cũng có thể mã hóa bản kết xuất nhanh bằng khóa KMS được khách hàng sở hữu và quản lý.

Khoảng thời gian khởi tạo tối đa được phép cho Lambda SnapStart sẽ khớp với khoảng thời gian chờ thực thi mà bạn đã cấu hình cho hàm của bạn. Giới hạn thời gian chờ thực thi được cấu hình tối đa cho một hàm là 15 phút.

Tính đồng thời được cung cấp cho phép bạn kiểm soát tốt hơn hiệu năng của các ứng dụng serverless. Khi được kích hoạt, Tính đồng thời được cung cấp sẽ đảm bảo tính sẵn sàng cực cao và duy trì khởi tạo nhằm đáp ứng trong vài mili giây cho các hàm của bạn.

Bạn có thể cấu hình tính đồng thời trên hàm của bạn thông qua Bảng điều khiển quản lý AWS, Lambda API, AWS CLI và AWS CloudFormation. Cách dễ nhất để hưởng lợi từ Tính đồng thời được cung cấp là sử dụng AWS Auto Scaling. Bạn có thể sử dụng Auto Scaling của ứng dụng để cấu hình lịch hoặc thiết lập để Auto Scaling tự động điều chỉnh mức độ Tính đồng thời được cung cấp theo thời gian thực khi nhu cầu thay đổi. Để tìm hiểu thêm về Tính đồng thời được cung cấp, hãy xem tài liệu.

Bạn không cần phải thay đổi gì với mã để sử dụng Tính đồng thời được cung cấp. Tính năng này hoạt động liền mạch với tất cả các hàm và thời gian chạy hiện có. Không có thay đổi nào đối với mô hình gọi và thực thi của Lambda khi sử dụng Tính đồng thời được cung cấp.

Tính đồng thời được cung cấp bổ sung một khía cạnh giá mới để khởi tạo hàm, đó là giá ‘Tính đồng thời được cung cấp’. Khi bật tính năng này, bạn sẽ trả cho dung lượng xử lý đồng thời mà bạn cấu hình và cho khoảng thời gian bạn cấu hình nó. Nếu hàm của bạn thực thi trong khi Tính đồng thời được cung cấp được cấu hình cho hàm đó, bạn cũng sẽ trả tiền cho Yêu cầu và Thời lượng thực thi. Để tìm hiểu thêm về cách định giá tính năng Tính đồng thời được cung cấp, hãy xem mục Định giá AWS Lambda.

Tính đồng thời được cung cấp sẽ là tính năng lý tưởng khi xây dựng các ứng dụng đòi hỏi cao về độ trễ, như backend web hoặc di động, API được gọi ra đồng thời và các vi dịch vụ tương tác. Bạn có thể dễ dàng cấu hình mức dung lượng đồng thời thích hợp theo nhu cầu duy nhất của ứng dụng của bạn. Bạn có thể tăng mức đồng thời trong thời gian có nhu cầu cao và giảm hoặc tắt hoàn toàn, khi nhu cầu giảm.

Nếu tính đồng thời của một hàm đạt đến mức được cấu hình thì các lần gọi tiếp theo của hàm sẽ mang các đặc tính về độ trễ và quy mô của các hàm Lambda thông thường. Bạn có thể giới hạn hàm chỉ mở rộng đến mức được cấu hình. Làm như vậy sẽ ngăn không để hàm vượt quá mức được cấu hình của Tính đồng thời được cung cấp. Đây là một cơ chế để ngăn sự biến động không mong muốn trong ứng dụng khi nhu cầu vượt quá mức dự kiến.

AWS Lambda cho phép bạn chạy các hàm của mình trên những bộ xử lý dựa trên x86 hoặc Arm. Bộ xử lý AWS Graviton2 được Amazon Web Services xây dựng tùy chỉnh, sử dụng lõi Arm Neoverse 64 bit để đem đến hiệu quả chi phí tối ưu cho khối lượng công việc đám mây của bạn. Khách hàng nhận được những lợi thế tương tự như của AWS Lambda, chạy mã mà không cần cung cấp hoặc quản lý máy chủ, tự động thay đổi quy mô, tính khả dụng cao và chỉ trả tiền cho tài nguyên sử dụng.

Các hàm AWS Lambda do Graviton2 cung cấp, sử dụng kiến trúc của bộ xử lý dựa trên Arm do AWS thiết kế, có mục tiêu mang tới hiệu quả chi phí tốt hơn tới 34% so với những hàm chạy trên các bộ xử lý x86, dành cho nhiều loại khối lượng công việc phi máy chủ, chẳng hạn như phần phụ trợ, dữ liệu và xử lý luồng của web và thiết bị di động. Với độ trễ thấp hơn, hiệu suất cao hơn tới 19%, chi phí thấp hơn 20% và hiệu suất năng lượng cao nhất hiện có tại AWS, các hàm của Graviton2 có thể hỗ trợ cho những ứng dụng phi máy chủ tối quan trọng. Khách hàng có thể cấu hình cho cả hàm hiện có và hàm mới nhắm mục tiêu tới bộ xử lý Graviton2. Khách hàng có thể triển khai các hàm chạy trên Graviton2 dưới dạng tệp zip hoặc hình ảnh bộ chứa.

Bạn có thể cấu hình các hàm để chạy trên Graviton2 thông qua Bảng điều khiển quản lý AWS, API AWS Lambda, AWS CLI và AWS CloudFormation bằng cách đặt cờ kiến trúc thành ‘arm64’ cho hàm của bạn.

Không có sự thay đổi nào giữa các hàm dựa trên x86 và dựa trên Arm. Bạn chỉ cần tải lên mã của mình qua Bảng điều khiển quản lý AWS, tệp zip hoặc hình ảnh bộ chứa, AWS Lambda sẽ tự động chạy mã của bạn khi được kích hoạt mà không yêu cầu bạn cung cấp hoặc quản lý cơ sở hạ tầng.

Một ứng dụng có thể chứa các hàm chạy trên cả hai kiến trúc. AWS Lambda cho phép bạn thay đổi kiến trúc (‘x86_64’ hoặc ‘arm64’) cho phiên bản mới nhất của hàm. Không thể thay đổi kiến trúc sau khi đã tạo một phiên bản cụ thể cho hàm.

Các ngôn ngữ được thông dịch như Python, Java và Node thường không yêu cầu biên dịch lại, trừ khi mã của bạn tham chiếu đến các thư viện sử dụng những thành phần kiến trúc cụ thể. Trong những trường hợp đó, bạn cần cung cấp các thư viện được nhắm mục tiêu đến arm64. Để biết thêm chi tiết, vui lòng xem trang Bắt đầu sử dụng AWS Graviton. Các ngôn ngữ không được thông dịch sẽ yêu cầu biên dịch mã của bạn để nhắm mục tiêu tới arm64. Trong khi các trình biên dịch hiện đại hơn sẽ tạo ra các mã đã biên dịch cho arm64, bạn sẽ cần triển khai mã này vào một môi trường dựa trên arm để kiểm tra. Để tìm hiểu thêm về cách sử dụng các hàm Lambda bằng Graviton2, vui lòng xem tài liệu.

Không. Mỗi phiên bản hàm chỉ có thể sử dụng một hình ảnh bộ chứa duy nhất.

Có. Có thể nhắm mục tiêu các lớp và tiện ích mở rộng tới những kiến trúc tương thích với ‘x86_64’ hoặc ‘arm64’. Kiến trúc mặc định cho các hàm và lớp là ‘x86_64’.

Khi khởi chạy, khách hàng có thể sử dụng ảnh Python, Node.js, Java, Ruby, .Net Core, Custom Runtime (có sẵn.al2) và OCI Base. Để tìm hiểu thêm, vui lòng xem Thời gian hoạt động AWS Lambda.

Các hàm AWS Lambda do bộ xử lý AWS Graviton2 cung cấp có mức giá rẻ hơn 20% so với các hàm Lambda dựa trên x86. Bậc miễn phí Lambda áp dụng cho các hàm AWS Lambda do kiến trúc dựa trên x86 và Arm cung cấp.

Mỗi khối lượng công việc đều có tính duy nhất và chúng tôi khuyên khách hàng nên kiểm tra các hàm của mình để xác định mức độ cải thiện hiệu suất chi phí mà họ có thể thấy. Để làm được điều đó, bạn nên sử dụng công cụ Điều chỉnh công suất AWS Lambda. Chúng tôi khuyên bạn nên bắt đầu với phần phụ trợ, dữ liệu và xử lý luồng của web và thiết bị di động khi kiểm tra khối lượng công việc của mình để có thể tăng hiệu suất chi phí.

Với Amazon Elastic File System (Amazon EFS) cho AWS Lambda, khách hàng có thể đọc, ghi và lưu trữ khối lượng dữ liệu lớn ở hầu hết mọi quy mô bằng cách sử dụng một hệ thống tệp NFS linh hoạt được quản lý toàn phần có thể thay đổi quy mô theo nhu cầu mà không cần cung cấp hoặc quản lý dung lượng. Trước đây, các nhà phát triển đã thêm mã vào các hàm của mình để tải dữ liệu từ S3 hoặc cơ sở dữ liệu xuống kho lưu trữ tạm thời cục bộ, được giới hạn ở 512 MB. Với EFS cho Lambda, các nhà phát triển không cần phải viết mã để tải dữ liệu xuống kho lưu trữ tạm thời để xử lý.

Các nhà phát triển có thể dễ dàng kết nối hệ thống tệp EFS hiện có với một hàm Lambda thông qua Điểm truy cập EFS bằng bảng điều khiển, CLI hoặc SDK. Khi hàm được gọi lần đầu tiên, hệ thống tệp sẽ tự động được gắn và cung cấp cho mã hàm. Bạn có thể tìm hiểu thêm trong tài liệu.

Có. Các mục tiêu gắn kết cho Amazon EFS được liên kết với một mạng con trong một VPC. Hàm AWS Lambda cần được cấu hình để truy cập vào VPC đó.

Sử dụng EFS for Lambda thường lý tưởng để xây dựng các ứng dụng máy học hoặc tải các tệp hoặc mô hình tham chiếu lớn, xử lý hoặc sao lưu lượng lớn dữ liệu, lưu trữ nội dung web hoặc phát triển hệ thống xây dựng nội bộ. Khách hàng cũng có thể sử dụng EFS for Lambda để duy trì trạng thái giữa các yêu cầu gọi trong cùng một cấu trúc vi dịch vụ có trạng thái, trong luồng công việc Step Functions hoặc chia sẻ tệp giữa các ứng dụng phi máy chủ và các ứng dụng dựa trên bộ chứa hoặc phiên bản.

Có. Mã hóa dữ liệu khi đang truyền sử dụng giao thức Bảo mật lớp vận chuyển (TLS) 1.2 theo tiêu chuẩn công nghiệp để mã hóa dữ liệu được gửi giữa các hàm AWS Lambda và các hệ thống tệp Amazon EFS.

Khách hàng có thể cung cấp Amazon EFS để mã hóa dữ liệu ở trạng thái lưu trữ. Dữ liệu được mã hóa ở trạng thái lưu trữ sẽ được mã hóa trong khi ghi và được giải mã khi đọc, do đó, bạn không phải sửa đổi ứng dụng của mình. Các khóa mã hóa được quản lý bởi AWS Key Management Service (KMS), do đó, bạn không cần xây dựng và duy trì cơ sở hạ tầng quản lý khóa bảo mật.

Việc sử dụng Amazon EFS cho AWS Lambda sẽ không bị tính thêm phí. Khách hàng sẽ trả mức giá tiêu chuẩn cho AWS Lambda và cho Amazon EFS. Khi sử dụng Lambda và EFS trong cùng một vùng sẵn sàng, khách hàng không bị tính phí truyền dữ liệu. Tuy nhiên, nếu sử dụng kết nối ngang hàng VPC để truy cập liên tài khoản, khách hàng sẽ phải chịu phí truyền dữ liệu. Để tìm hiểu thêm, vui lòng xem mục Định giá.

Không. Mỗi hàm Lambda sẽ có thể truy cập một hệ thống tệp EFS.

Có. Amazon EFS hỗ trợ các hàm Lambda, ECS, bộ chứa Fargate và các phiên bản EC2. Bạn có thể chia sẻ cùng một hệ thống tệp, đồng thời sử dụng chính sách IAM và Điểm truy cập để kiểm soát mỗi hàm, bộ chứa hoặc phiên bản có quyền truy cập.  

Có. Các hàm Lambda có thể được định cấu hình bằng URL hàm, một điểm cuối HTTPS được tích hợp sẵn có thể được gọi bằng trình duyệt, lệnh curl và bất kỳ máy khách HTTP nào. URL hàm là một cách thức đơn giản để bắt đầu xây dựng các hàm dễ dàng truy cập vào HTTPS.

Bạn có thể cấu hình URL hàm cho hàm của mình thông qua Bảng điều khiển quản lý AWS, API AWS Lambda, AWS CLI, AWS CloudFormation và AWS Serverless Application Model. URL hàm có thể được bật trên phiên bản không đủ tiêu chuẩn $LATEST của hàm của bạn, hay trên bất kỳ bí danh hàm nào. Để tìm hiểu thêm về việc cấu hình URL hàm, hãy xem tài liệu.

URL hàm Lambda được bảo mật với ủy quyền IAM theo mặc định. Bạn có thể lựa chọn tắt ủy quyền IAM để tạo một điểm cuối công khai hoặc nếu bạn dự định triển khai ủy quyền tùy chọn làm một phần logic kinh doanh của hàm.

Bạn có thể dễ dàng gọi hàm từ trình duyệt web của bạn bằng cách điều hướng đến URL Lambda, từ mã của ứng dụng máy khách bằng cách sử dụng thư viện HTTP, hoặc từ dòng lệnh bằng curl.

Có. URL hàm Lambda có thể được bật trên một hàm hoặc bí danh hàm. Nếu không có bí danh nào được chỉ định, URL sẽ chỉ đến $LATEST theo mặc định. URL hàm không thể nhắm mục tiêu đến phiên bản hàm riêng lẻ.

Các tên miền tùy chỉnh hiện không được hỗ trợ bởi URL hàm. Bạn có thể sử dụng miền tùy chỉnh với URL hàm của bạn bằng cách tạo một bản phân phối Amazon CloudFront và một CNAME để sắp xếp miền tùy chỉnh của bạn theo tên bản phân phối CloudFront. Sau đó, sắp xếp tên miền phân phối CloudFront của bạn để chuyển đến URL hàm của bạn như một nguồn.

Có, URL hàm có thể được dùng để gọi một hàm Lambda trong VPC.

Bạn không bị tính thêm phí khi sử dụng URL hàm. Bạn có thể thanh toán giá tiêu chuẩn cho AWS Lambda. Để tìm hiểu thêm, vui lòng xem Định giá AWS Lambda.

Lambda@Edge cho phép bạn chạy mã tại nhiều vị trí của AWS trên toàn cầu mà không cần cung cấp hay quản lý máy chủ, phản hồi tới người dùng cuối với độ trễ mạng thấp nhất. Bạn chỉ cần tải mã Node.js hoặc Python lên AWS Lambda và cấu hình để hàm được kích hoạt khi phản hồi lại những yêu cầu của Amazon CloudFront (nói cách khác, khi có một yêu cầu của người xem, khi yêu cầu được chuyển tiếp đến hoặc nhận lại từ nguồn, hoặc ngay trước khi phản hồi lại tới người dùng cuối). Sau đó, mã này sẽ sẵn sàng để thực thi tại nhiều vị trí của AWS trên toàn cầu khi nhận được yêu cầu nội dung và mã sẽ mở rộng quy mô theo khối lượng yêu cầu của CloudFront trên toàn cầu. Hãy tìm hiểu thêm trong tài liệu của chúng tôi.

Để sử dụng Lambda@Edge, bạn chỉ cần tải mã lên AWS Lambda và liên kết một phiên bản hàm cần kích hoạt khi phản hồi với các yêu cầu của Amazon CloudFront. Mã của bạn phải thỏa mãn các giới hạn dịch vụ của Lambda@Edge. Tại thời điểm này, Lambda@Edge hỗ trợ Node.js và Python cho việc gọi hàm toàn cầu bởi các sự kiện CloudFront. Hãy tìm hiểu thêm trong tài liệu của chúng tôi.

Lambda@Edge được tối ưu hóa cho những trường hợp có đòi hỏi khắt khe về độ trễ, trong đó người xem cuối của bạn phân bố khắp toàn cầu. Tất cả thông tin bạn cần để ra quyết định sẽ có tại biên CloudFront, trong phạm vi của hàm và yêu cầu. Điều này đồng nghĩa rằng, các trường hợp sử dụng mà bạn muốn đưa ra quyết định về cách phục vụ nội dung dựa trên đặc tính người dùng (ví dụ: vị trí, thiết bị khách, v.v.) giờ đây có thể được thực thi và phục vụ cận kề với người dùng mà không cần phải định tuyến ngược trở lại một máy chủ tập trung.

Bạn có thể liên kết các hàm Lambda hiện có với các sự kiện CloudFront cho các yêu cầu gọi từ khắp toàn cầu nếu hàm thỏa mãn các yêu cầu và giới hạn dịch vụ của Lambda@Edge. Đọc thêm ở đây để biết cách cập nhật các thuộc tính hàm của bạn.

Các hàm của bạn sẽ tự động kích hoạt để phản hồi với các sự kiện Amazon CloudFront sau:

• Yêu cầu từ người xem – Sự kiện này diễn ra khi người dùng cuối hoặc một thiết bị trên Internet tạo ra một yêu cầu HTTP(S) tới CloudFront và yêu cầu này đi đến vị trí biên gần nhất với người dùng đó.
• Phản hồi từ người xem – Sự kiện này diễn ra khi máy chủ CloudFront tại biên đã sẵn sàng để phản hồi người dùng cuối hoặc thiết bị đưa ra yêu cầu đó.
• Yêu cầu từ nguồn – Sự kiện này diễn ra khi máy chủ biên CloudFront chưa có đối tượng được yêu cầu trong bộ lưu trữ đệm và yêu cầu của người xem đã sẵn sàng để được chuyển về máy chủ web nguồn backend của bạn (ví dụ: Amazon EC2, Application Load Balancer hay Amazon S3).
• Phản hồi từ nguồn - Sự kiện này diễn ra khi máy chủ CloudFront tại biên nhận một phản hồi từ máy chủ web nguồn backend.

Điểm khác biệt nằm ở chỗ API Gateway và Lambda là các dịch vụ khu vực. Sử dụng Lambda@Edge và Amazon CloudFront cho phép bạn thực thi logic trên nhiều khu vực AWS dựa theo vị trí của người dùng cuối của bạn.

AWS Lambda được thiết kế với khả năng tái tạo và độ dôi dư nhằm mang đến độ sẵn sàng cao cho bản thân dịch vụ và cho các hàm chạy trên dịch vụ. Khung thời gian bảo trì hay thời gian ngừng hoạt động theo lịch đều không cần đến.

Có. Khi bạn cập nhật hàm Lambda, sẽ có một khung thời gian ngắn, thường dưới một phút, trong đó các yêu cầu có thể được phục vụ bởi phiên bản cũ hoặc phiên bản mới của hàm.

Không. AWS Lambda được thiết kế để chạy song song nhiều phiên bản hàm. Tuy nhiên, AWS Lambda có một ngưỡng điều tiết an toàn mặc định đối với số lượng thao tác thực thi đồng thời trên mỗi tài khoản theo từng khu vực (hãy truy cập vào đây để biết thông tin về giới hạn điều tiết an toàn mặc định). Bạn cũng có thể kiểm soát số thao tác thực thi đồng thời tối đa đối với từng hàm AWS Lambda, bạn có thể sử dụng chức năng này để dự trữ một phần nhỏ giới hạn chạy đồng thời cho các hàm quan trọng của tài khoản hoặc giới hạn tốc độ lưu lượng đối với các tài nguyên xuôi chiều.

Nếu muốn gửi yêu cầu tăng giới hạn thực thi đồng thời, bạn có thể sử dụng Hạn mức dịch vụ để yêu cầu tăng giới hạn.

Khi vượt quá giới hạn thực thi đồng thời tối đa, các hàm AWS Lambda đang được gọi đồng thời sẽ trả về lỗi tiết lưu (mã lỗi 429). Các hàm Lambda đang được gọi ra đồng thời có thể chiếm các phần lưu lượng tăng đột biến chấp nhận được trong khoảng 15-30 phút, sau đó các sự kiện đến sẽ bị từ chối do được điều tiết. Trong trường hợp hàm Lambda đang được gọi ra để phản hồi với các sự kiện Amazon S3, các sự kiện bị AWS Lambda từ chối có thể được S3 giữ lại và thử lại trong vòng 24 giờ. Sự kiện từ các luồng Amazon Kinesis và các luồng Amazon DynamoDB được thử lại cho đến khi hàm Lambda thành công hoặc dữ liệu hết hạn. Các Luồng Amazon Kinesis và Amazon DynamoDB giữ lại dữ liệu trong vòng 24 giờ.

Giới hạn thực thi đồng thời tối đa mặc định được áp dụng ở cấp tài khoản. Tuy nhiên, bạn cũng có thể đặt giới hạn cho các hàm riêng lẻ (hãy truy cập vào đây để biết thông tin về Tính đồng thời đặt trước).

Mỗi hàm Lambda được gọi đồng bộ có thể điều chỉnh quy mô với tốc độ lên đến 1000 lần thực thi đồng thời trong mỗi 10 giây. Mặc dù tốc độ điều chỉnh quy mô của Lambda phù hợp với hầu hết các trường hợp sử dụng, đây là lựa chọn cực kỳ lý tưởng cho những dịch vụ có lưu lượng truy cập tăng đột biến có thể dự báo được hoặc không thể đoán trước. Ví dụ: xử lý dữ liệu buộc phải tuân thủ SLA sẽ yêu cầu điều chỉnh quy mô nhanh chóng nhưng có thể dự báo được nhằm đáp ứng nhu cầu xử lý. Tương tự, việc phân phối các bài báo tin tức nóng hổi hoặc chương trình giảm giá siêu tốc có thể đẩy lưu lượng truy cập lên cao đến mức khó đoán trước trong một khoảng thời gian ngắn. Tốc độ điều chỉnh quy mô của Lambda có thể tạo điều kiện thuận lợi cho các trường hợp sử dụng như vậy mà không cần cấu hình hoặc công cụ bổ sung. Ngoài ra, giới hạn điều chỉnh quy mô đồng thời là giới hạn cấp hàm, có nghĩa là mỗi hàm trong tài khoản của bạn có quy mô độc lập với các hàm khác.

Khi gặp lỗi, các hàm Lambda đang được gọi ra đồng thời sẽ phản hồi bằng một ngoại lệ. Các hàm exception đang được gọi ra đồng thời sẽ được thử lại ít nhất 3 lần. Sự kiện từ các luồng Amazon Kinesis và các luồng Amazon DynamoDB được thử lại cho đến khi hàm Lambda thành công hoặc dữ liệu hết hạn. Các Luồng Kinesis và DynamoDB giữ lại dữ liệu trong vòng tối thiểu 24 giờ.

Bạn có thể cấu hình hàng chờ Amazon SQS hoặc chủ đề Amazon SNS làm hàng chờ thư chết.

Khi vượt quá chính sách thử lại cho các yêu cầu gọi đồng thời, bạn có thể cấu hình một “hàng chờ thư chết” (DLQ) mà sự kiện sẽ được đặt vào đó; khi không có DLQ nào được cấu hình, sự kiện có sẽ bị từ chối. Khi vượt quá chính sách thử lại đối với các yêu cầu gọi từ luồng, dữ liệu có thể đã hết hạn và do đó, bị từ chối.

Bạn cấp quyền cho hàm Lambda truy cập các tài nguyên khác bằng vai trò IAM. AWS Lambda giữ vai trò này khi thực thi hàm Lambda, do đó bạn luôn duy trì được khả năng kiểm soát đầy đủ, bảo mật về chính xác các tài nguyên AWS nào mà hàm có thể sử dụng. Truy cập Thiết lập AWS Lambda để tìm hiểu thêm về vai trò.

Khi bạn cấu hình một vùng lưu trữ Amazon S3 để gửi thông điệp đến một hàm AWS Lambda, một quy tắc chính sách tài nguyên sẽ được tạo để cấp quyền truy cập. Hãy tham khảo Hướng dẫn dành cho nhà phát triển Lambda để tìm hiểu thêm về các chính sách về tài nguyên và khả năng kiểm soát truy cập đối với các hàm Lambda.

Khả năng kiểm soát truy cập được quản lý thông qua vai trò của hàm Lambda. Vai trò mà bạn chỉ định cho hàm Lambda cũng quyết định AWS Lambda có thể thay cho hàm thăm dò (các) tài nguyên nào. Hãy truy cập Hướng dẫn dành cho nhà phát triển Lambda để tìm hiểu thêm.

Khả năng kiểm soát truy cập có thể được quản lý thông qua vai trò của hàm Lambda hoặc cài đặt chính sách tài nguyên trên chính hàng chờ. Nếu có cả hai chính sách, quyền nào hạn chế hơn sẽ áp dụng.

Bạn có thể cho phép hàm Lambda truy cập các tài nguyên trong VPC của bạn bằng cách chỉ định mạng con và nhóm bảo mật làm một phần của cấu hình hàm. Các hàm Lambda được cấu hình để truy cập các tài nguyên trong một VPC cụ thể sẽ không có quyền truy cập Internet theo cấu hình mặc định. Để cấp Internet cho các hàm này, hãy sử dụng cổng Internet. Theo mặc định, các hàm Lambda giao tiếp với các tài nguyên trong VPC thực thi đồng thời hai giao thức qua IPv4. Bạn có thể cấu hình các hàm của mình để truy cập các tài nguyên trong VPC thực thi đồng thời hai giao thức qua IPv6. Để biết thêm chi tiết về các hàm Lambda được cấu hình với VPC, hãy xem Kết nối mạng riêng Lambda với VPC.

Ký mã cho AWS Lambda cung cấp các biện pháp kiểm soát độ tin cậy và tính toàn vẹn, cho phép bạn xác minh rằng chỉ mã còn toàn vẹn đến từ các nhà phát triển đã được phê duyệt mới được triển khai trong hàm Lambda của bạn. Bạn có thể dùng AWS Signer, một dịch vụ ký mã được quản lý toàn diện để ký nhận điện tử những thành phần lạ của mã và định cấu hình các hàm Lambda của bạn để xác minh các chữ ký khi triển khai. Ký mã cho AWS Lambda hiện chỉ khả dụng với các hàm được đóng gói dưới dạng lưu trữ ZIP.

Bạn có thể tạo các thành phần lạ được ký điện tử bằng Hồ sơ ký thông qua bảng điều khiển AWS Signer, API Signer, SAM CLI hoặc AWS CLI. Để tìm hiểu thêm, vui lòng xem tài liệu về AWS Signer.

Bạn có thể bật tính năng ký mã bằng cách tạo Cấu hình ký mã thông qua Bảng điều khiển quản lý AWS, API Lambda, AWS CLI, AWS CloudFormation và AWS SAM. Cấu hình ký mã giúp bạn chỉ định cấu hình ký được phê duyệt và định cấu hình cảnh báo hoặc từ chối triển khai nếu kiểm tra chữ ký không thành công. Cấu hình ký mã có thể được gắn vào các hàm Lambda riêng lẻ để bật tính năng ký mã. Các hàm như vậy hiện bắt đầu xác minh chữ ký khi triển khai.

AWS Lambda có thể thực hiện các hoạt động kiểm tra chữ ký sau đây khi triển khai:

•Chữ ký bị hỏng - Điều này xảy ra nếu thành phần lạ của mã đã bị thay đổi sau khi ký.
• Chữ ký không khớp - Điều này xảy ra nếu thành phần lạ của mã được ký bởi một cấu hình ký không được phê duyệt.
• Chữ ký hết hạn - Điều này xảy ra nếu chữ ký đã qua ngày hết hạn đã định cấu hình.
• Chữ ký đã thu hồi - Điều này xảy ra nếu chủ sở hữu hồ sơ ký thu hồi các tác vụ ký.

Để tìm hiểu thêm, vui lòng xem tài liệu về AWS Lambda.

Có, bạn có thể bật tính năng ký mã cho các hàm hiện có bằng cách đính kèm cấu hình ký mã vào hàm. Bạn có thể thực hiện việc này bằng bảng điều khiển AWS Lambda, API Lambda, AWS CLI, AWS CloudFormation và AWS SAM.

Không có chi phí phát sinh khi sử dụng Ký mã cho AWS Lambda. Bạn có thể thanh toán giá tiêu chuẩn cho AWS Lambda. Để tìm hiểu thêm, vui lòng xem mục Định giá.

Để cung cấp cho bạn trải nghiệm ghi nhật ký đơn giản và nâng cao theo mặc định, AWS Lambda cung cấp các biện pháp kiểm soát ghi nhật ký nâng cao như khả năng thu thập chính gốc bản ghi hàm Lambda ở định dạng có cấu trúc JSON, kiểm soát cách lọc ở cấp độ bản ghi của bản ghi hàm Lambda mà không cần thay đổi mã, cũng như tùy chỉnh nhóm bản ghi Amazon CloudWatch mà Lambda gửi bản ghi đến.

Bạn có thể thu thập bản ghi hàm Lambda ở định dạng có cấu trúc JSON mà không cần phải sử dụng thư viện ghi nhật ký của riêng bạn. Bản ghi có cấu trúc JSON giúp tìm kiếm, lọc và phân tích khối lượng lớn các mục bản ghi dễ dàng hơn. Bạn có thể kiểm soát cách lọc ở cấp độ bản ghi của bản ghi hàm Lambda mà không cần thay đổi mã, cho phép bạn chọn mức độ chi tiết ghi nhật ký cần thiết cho các hàm Lambda mà không cần sàng lọc qua khối lượng lớn bản ghi khi gỡ lỗi và khắc phục sự cố. Bạn cũng có thể đặt nhóm bản ghi Amazon CloudWatch mà Lambda gửi bản ghi đến, giúp việc tổng hợp bản ghi từ nhiều hàm trong một ứng dụng ở một nơi dễ dàng hơn. Sau đó, bạn có thể áp dụng các chính sách bảo mật, quản trị và lưu giữ cho bản ghi ở cấp ứng dụng thay vì riêng lẻ cho từng hàm.

Bạn có thể chỉ định các biện pháp kiểm soát ghi nhật ký nâng cao cho các hàm Lambda của mình bằng API AWS Lambda, bảng điều khiển AWS Lambda, AWS CLI, Mô hình ứng dụng phi máy chủ AWS (SAM) và AWS CloudFormation. Để tìm hiểu thêm, hãy truy cập vào bài đăng blog khởi chạy để biết các biện pháp kiểm soát tạo bản ghi nâng cao hoặc Hướng dẫn dành cho nhà phát triển của Lambda.

Có, bạn có thể sử dụng thư viện ghi nhật ký của riêng mình để tạo bản ghi Lambda ở định dạng có cấu trúc JSON. Để đảm bảo thư viện ghi nhật ký của bạn hoạt động liền mạch với khả năng ghi nhật ký có cấu trúc JSON gốc của Lambda, Lambda sẽ không mã hóa kép bất kỳ bản ghi nào được tạo bởi hàm của bạn đã được mã hóa JSON. Bạn cũng có thể sử dụng thư viện Powertools cho AWS Lambda để thu thập bản ghi Lambda ở định dạng có JSON cấu trúc.

Bạn không mất thêm phí khi sử dụng các biện pháp kiểm soát ghi nhật ký nâng cao trên Lambda. Bạn sẽ tiếp tục bị tính phí cho việc nhập và lưu trữ bản ghi Lambda của bạn bởi Bản ghi Amazon CloudWatch. Xem trang giá CloudWatch để biết chi tiết về giá bản ghi.

Tín hiệu ứng dụng CloudWatch là giải pháp giám sát hiệu năng ứng dụng (APM) cho phép các nhà phát triển và người vận hành dễ dàng theo dõi tình trạng và hiệu năng của các ứng dụng phi máy chủ được xây dựng bằng Lambda. Tín hiệu về ứng dụng cung cấp các bảng điều khiển được chuẩn hóa, dựng sẵn cho các số liệu ứng dụng quan trọng, dấu vết tương quan và tương tác giữa các hàm Lambda và các phần phụ thuộc – tất cả đều không yêu cầu nhà phát triển phải đo lường thủ công hay thay đổi mã.

Bạn có thể bật Tín hiệu về ứng dụng cho hàm của mình chỉ bằng một cú nhấp chuột trong phần “Công cụ giám sát và vận hành” ở tab Cấu hình trong bảng điều khiển Lambda. Sau khi bật Tín hiệu ứng dụng, bạn có thể xem bảng điều khiển được dựng sẵn, bản đồ dịch vụ, v.v., đồng thời phân tích hiệu năng và tình trạng của các ứng dụng phi máy chủ trong bảng điều khiển CloudWatch. Để tìm hiểu thêm, hãy truy cập hướng dẫn dành cho nhà phát triển Lambda và hướng dẫn dành cho nhà phát triển Tín hiệu về ứng dụng. Truy cập trang giá CloudWatch để tìm hiểu thêm về cách tính phí khi sử dụng Tín hiệu về ứng dụng với các hàm Lambda.

Live Tail Bản ghi Amazon CloudWatch là một chức năng phân tích và phân luồng bản ghi giàu tính tương tác, mang đến khả năng hiển thị bản ghi theo thời gian thực, giúp dễ dàng phát triển và khắc phục sự cố hàm Lambda hơn. Điều này cho phép nhà phát triển nhanh chóng kiểm tra cũng như xác thực điểm thay đổi cấu hình hoặc mã theo thời gian thực, đẩy nhanh chu kỳ soạn thảo – kiểm thử – triển khai (còn được gọi là “vòng lặp phát triển bên trong”) khi phát triển ứng dụng bằng Lambda. Trải nghiệm Live Tail cũng giúp người vận hành và đội ngũ DevOps phát hiện cũng như gỡ lỗi và sự cố nghiêm trọng về mã của hàm Lambda hiệu quả hơn, giảm thời gian trung bình để phục hồi (MTTR) khi khắc phục lỗi về hàm Lambda.

Để sử dụng Live Tail cho hàm Lambda, bạn hãy truy cập bảng điều khiển Lambda và nhấp vào nút “Mở CloudWatch Live Tail” trong trình soạn mã. Để biết thêm thông tin, hãy truy cập hướng dẫn dành cho nhà phát triển Lambda. Truy cập trang giá CloudWatch để tìm hiểu thêm về cách tính phí khi sử dụng Live Tail với các hàm Lambda.

Bạn có thể sử dụng các công cụ tiêu chuẩn như Maven hoặc Gradle để biên soạn hàm Lambda. Quy trình xây dựng của bạn phải tương đồng với quy trình mà bạn sẽ sử dụng để biên soạn mã Java bất kỳ tùy thuộc vào AWS SDK. Chạy công cụ biên soạn Java trên các tệp nguồn và đưa AWS SDK 1.9 hoặc mới hơn vào sử dụng cùng với các quan hệ phụ thuộc bắc cầu trên classpath. Để biết thêm chi tiết, hãy xem tài liệu của chúng tôi.

Lambda cung cấp bản dựng Amazon Linux openjdk 1.8.

Có. Bạn có thể sử dụng các gói NPM cũng như các gói tùy chỉnh. Tìm hiểu thêm tại đây.

Có. Sandbox tích hợp sẵn của Lambda cho phép bạn chạy các tập lệnh xử lý theo lô (“shell”), các thời gian chạy ngôn ngữ khác, lịch trình tiện ích và các tệp thực thi. Tìm hiểu thêm tại đây.

Có. Bất cứ mô-đun gốc nào có liên kết về mặt thống kê đều có thể đưa vào trong tệp ZIP mà bạn tải lên, cũng như các mô-đun liên kết linh hoạt được soạn thảo bằng rpath trỏ đến thư mục gốc của hàm Lambda. Tìm hiểu thêm tại đây.

Có. Bạn có thể sử dụng lệnh child_process của Node.js để thực thi một tệp nhị phân mà bạn đã đưa vào trong hàm hoặc một tệp thực thi bất kỳ từ Amazon Linux hiển thị với hàm của bạn. Ngoài ra còn tồn tại một số gói NPM có chứa các tệp nhị phân dòng lệnh, chẳng hạn như node-ffmpeg. Tìm hiểu thêm tại đây.

Để triển khai một hàm Lambda viết bằng Node.js, bạn chỉ cần đóng gói mã Javascript và các thư viện phụ thuộc dưới dạng tệp ZIP. Bạn có thể tải tệp ZIP này lên từ môi trường cục bộ của mình hoặc chỉ định một vị trí Amazon S3 chứa tệp ZIP. Để biết thêm chi tiết, hãy xem tài liệu của chúng tôi.

Có. Bạn có thể sử dụng pip để cài đặt bất kỳ gói Python nào cần thiết.

Bạn có thể tạo một hàm C# Lambda thông qua IDE Visual Studio bằng cách chọn “Publish to AWS Lambda” (Phát hành đến AWS Lambda) trong Trình khám phá giải pháp. Nếu không, bạn có thể chạy trực tiếp lệnh “dotnet lambda publish” từ CLI dotnet đã cài đặt [# bản vá công cụ CLI của Lambda], thao tác này tạo một tệp ZIP chứa mã nguồn C# cùng với tất cả các quan hệ phụ thuộc NuGet cũng như các tập hợp DLL đã phát hành của riêng bạn, đồng thời tự động tải tệp này lên AWS Lambda bằng tham số thời gian chạy “dotnetcore1.0”

Gói triển khai PowerShell Lambda là một tập ZIP chứa tập lệnh PowerShell của bạn, các mô-đun PowerShell bắt buộc hỗ trợ tập lệnh PowerShell và các tập hợp cần thiết để lưu trữ PowerShell Core. Sau đó, bạn sẽ sử dụng mô-đun PowerShell AWSLambdaPSCore mà bạn có thể cài đặt từ Thư viện PowerShell để tạo gói triển khai PowerShell Lambda của bạn.

Tải lên thành phần lạ thực thi Go của bạn dưới dạng tập ZIP thông qua AWS CLI hoặc bảng điều khiển Lambda và lựa chọn thời gian chạy go1.x. Với Lambda, bạn có thể sử dụng các công cụ gốc của Go để xây dựng và đóng gói mã của mình. Để biết thêm chi tiết, đọc tài liệu của chúng tôi. 

Để triển khai một hàm Lambda viết bằng Ruby, hãy đóng gói mã Ruby và các gem dưới dạng tệp ZIP. Bạn có thể tải tệp ZIP này lên từ môi trường cục bộ của mình hoặc chỉ định một vị trí Amazon S3 chứa tệp ZIP.

Bạn có thể xem danh sách phiên bản được hỗ trợ ở đây.

Không. AWS Lambda cung cấp một phiên bản hệ điều hành và thời gian chạy ngôn ngữ có quản lý duy nhất cho tất cả người dùng dịch vụ. Bạn có thể sử dụng thời gian chạy ngôn ngữ của riêng bạn trong Lambda.

AWS Lambda được tích hợp với AWS CloudTrail. AWS CloudTrail có thể ghi lại và cung cấp các tệp nhật ký có bộ chứa Amazon S3 mô tả mức sử dụng API của tài khoản của bạn.

Bạn có thể sử dụng Amazon Step Functions để điều phối nhiều hàm Lambda đang gọi. Bạn có thể gọi ra nhiều hàm Lambda theo cách tuần tự, chuyển đầu ra của hàm này sang hàm khác, hoặc song song. Hãy xem tài liệu của chúng tôi để biết thêm chi tiết.

Có, AWS Lambda hỗ trợ bộ hướng dẫn Advanced Vector Extensions 2 (AVX2). Để tìm hiểu thêm về cách biên dịch mã ứng dụng của bạn để hướng bộ hướng dẫn này vào việc cải thiện hiệu năng, hãy truy cập tài liệu dành cho nhà phát triển AWS Lambda.