คำถามที่พบบ่อยเกี่ยวกับ AWS Lambda

โค้ดที่คุณเรียกใช้บน AWS Lambda จะถูกอัปโหลดเป็น “ฟังก์ชัน Lambda” แต่ละฟังก์ชันมีข้อมูลการกำหนดค่าที่เกี่ยวข้อง เช่น ชื่อ คำอธิบาย จุดเข้า และความต้องการทรัพยากร โค้ดต้องเขียนในรูปแบบ "ไม่มีสถานะ" กล่าวคือ จะถือว่าไม่มีความเกี่ยวข้องกับโครงสร้างพื้นฐานการประมวลผลที่สำคัญ การเข้าถึงระบบไฟล์ในเครื่อง กระบวนการลูก และสิ่งประดิษฐ์ที่คล้ายคลึงกันอาจไม่สามารถเข้าถึงเกินอายุการใช้งานของคำขอได้ และการเขียนข้อมูลอย่างต่อเนื่องใดๆ ควรเก็บไว้ใน Amazon S3, Amazon DynamoDB, Amazon EFS หรือบริการจัดเก็บข้อมูลทางอินเทอร์เน็ตอื่น ฟังก์ชัน Lambda สามารถรวมไลบรารีที่มีอยู่ รวมถึงไลบรารีดั้งเดิม

เพื่อปรับปรุงประสิทธิภาพ AWS Lambda อาจเลือกที่จะเก็บอินสแตนซ์ของฟังก์ชันของคุณไว้และนำมาใช้ใหม่เพื่อรองรับคำขอในภายหลังแทนที่จะสร้างสำเนาใหม่ หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับวิธีที่ Lambda ใช้งานอินสแตนซ์ฟังก์ชันใหม่อีกครั้ง โปรดอ่านเอกสารประกอบของเรา โค้ดของคุณไม่ควรคาดเดาว่าสิ่งนี้จะเกิดขึ้นเสมอ

คุณสามารถกำหนดค่าฟังก์ชัน Lambda แต่ละรายการด้วยพื้นที่จัดเก็บชั่วคราวระหว่าง 512 MB ถึง 10,240 MB ได้โดยเพิ่มขึ้นทีละ 1 MB พื้นที่จัดเก็บชั่วคราวมีอยู่ในไดเรกทอรี /tmp ของแต่ละฟังก์ชัน

แต่ละฟังก์ชันมีสิทธิ์เข้าถึงพื้นที่จัดเก็บข้อมูล 512 MB โดยไม่มีค่าใช้จ่ายเพิ่มเติม เมื่อกำหนดค่าฟังก์ชันของคุณด้วยพื้นที่จัดเก็บชั่วคราวมากกว่า 512 MB คุณจะถูกเรียกเก็บเงินตามปริมาณพื้นที่จัดเก็บที่คุณกำหนดค่า และตามระยะเวลาที่ฟังก์ชันของคุณทำงานโดยคิดเพิ่มทีละ 1 มิลลิวินาที เพื่อเป็นการเปรียบเทียบ ใน Region สหรัฐอเมริกาฝั่งตะวันออก (โอไฮโอ) ราคาพื้นที่จัดเก็บชั่วคราวของ AWS Fargate คือ 0.000111 USD ต่อ GB ต่อชั่วโมง หรือ 0.08 USD ต่อ GB ต่อเดือน ราคาปริมาณพื้นที่จัดเก็บ gp3 ของ Amazon EBS ในสหรัฐอเมริกาฝั่งตะวันออก (โอไฮโอ) คือ 0.08 USD ต่อ GB ต่อเดือน ราคาพื้นที่จัดเก็บชั่วคราวของ AWS Lambda คือ 0.0000000309 USD ต่อ GB ต่อวินาที หรือ 0.000111 USD ต่อ GB ต่อชั่วโมง และ 0.08 USD ต่อ GB ต่อเดือน หากต้องการเรียนรู้เพิ่มเติม โปรดดูค่าบริการ AWS Lambda

คุณสามารถกำหนดค่าฟังก์ชัน Lambda แต่ละรายการด้วยพื้นที่จัดเก็บชั่วคราวระหว่าง 512 MB ถึง 10,240 MB ได้โดยเพิ่มขึ้นทีละ 1 MB โดยใช้ AWS Lambda Console, AWS Lambda API หรือเทมเพลต AWS CloudFormation ระหว่างการสร้างหรือการอัปเดตฟังก์ชัน

ใช่ ข้อมูลทั้งหมดที่จัดเก็บไว้ในพื้นที่จัดเก็บชั่วคราวจะมีการเข้ารหัสเอาไว้เมื่อไม่ได้ใช้งานด้วยคีย์ที่ดูแลจัดการโดย AWS

คุณสามารถใช้มาตรวัด AWS CloudWatch Lambda Insight เพื่อตรวจสอบการใช้พื้นที่จัดเก็บชั่วคราวของคุณได้ หากต้องการเรียนรู้เพิ่มเติม โปรดดูเอกสารประกอบเกี่ยวกับ AWS CloudWatch Lambda Insight

หากแอปพลิเคชันของคุณต้องการพื้นที่จัดเก็บที่คงทนถาวร ให้พิจารณาใช้ Amazon S3 หรือ Amazon EFS หากแอปพลิเคชันของคุณต้องการจัดเก็บข้อมูลที่จำเป็นสำหรับโค้ดในการเรียกใช้ฟังก์ชันเดียว ให้ลองใช้พื้นที่จัดเก็บชั่วคราวของ AWS Lambda เป็นแคชชั่วคราว หากต้องการเรียนรู้เพิ่มเติม โปรดดูที่การเลือกระหว่างตัวเลือกการจัดเก็บข้อมูล AWS Lambda ในเว็บแอป

ใช่ อย่างไรก็ตาม หากแอปพลิเคชันของคุณต้องการพื้นที่จัดเก็บถาวร ให้พิจารณาใช้ Amazon EFS หรือ Amazon S3 หากคุณเปิดใช้การทำงานพร้อมกันที่มีการเตรียมใช้งานสำหรับฟังก์ชันของคุณ โค้ดเริ่มต้นของฟังก์ชันของคุณจะทำงานระหว่างการจัดสรรและทำงานทุกๆ สองสามชั่วโมง เนื่องจากจะนำอินสแตนซ์ที่ทำงานอยู่ของฟังก์ชันของคุณกลับมาใช้ใหม่ คุณสามารถดูเวลาเริ่มต้นในบันทึกและการติดตามหลังจากที่อินสแตนซ์ประมวลผลคำขอแล้ว อย่างไรก็ตาม ระบบจะเรียกเก็บค่าบริการจากการเริ่มต้นนี้ แม้ว่าอินสแตนซ์จะไม่ประมวลผลคำขอก็ตาม ลักษณะการเริ่มต้นการทำงานพร้อมกันที่มีการเตรียมใช้งานนี้อาจส่งผลต่อวิธีที่ฟังก์ชันของคุณโต้ตอบกับข้อมูลที่คุณจัดเก็บไว้ในพื้นที่จัดเก็บชั่วคราว แม้ว่าฟังก์ชันของคุณจะไม่ได้ประมวลผลคำขอก็ตาม หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับกระบวนการทำงานพร้อมกันที่มีการเตรียมใช้งาน โปรดดูเอกสารประกอบที่เกี่ยวข้อง

คุณสามารถกำหนดค่าฟังก์ชัน Lambda แต่ละรายการด้วยพื้นที่จัดเก็บชั่วคราวระหว่าง 512 MB ถึง 10,240 MB ได้โดยเพิ่มขึ้นทีละ 1 MB โดยใช้ AWS Lambda Console, AWS Lambda API หรือเทมเพลต AWS CloudFormation ระหว่างการสร้างหรือการอัปเดตฟังก์ชัน

ใช่ ข้อมูลทั้งหมดที่จัดเก็บไว้ในพื้นที่จัดเก็บชั่วคราวจะมีการเข้ารหัสเอาไว้เมื่อไม่ได้ใช้งานด้วยคีย์ที่ดูแลจัดการโดย AWS

คุณสามารถใช้มาตรวัด AWS CloudWatch Lambda Insight เพื่อตรวจสอบการใช้พื้นที่จัดเก็บชั่วคราวของคุณได้ หากต้องการเรียนรู้เพิ่มเติม โปรดดูเอกสารประกอบเกี่ยวกับ AWS CloudWatch Lambda Insight

การเก็บรักษาฟังก์ชันแบบไม่มีสถานะทำให้ AWS Lambda สามารถเปิดใช้งานสำเนาของฟังก์ชันได้อย่างรวดเร็วตามต้องการเพื่อปรับขนาดให้เหมาะสมกับอัตราเหตุการณ์ที่เข้ามา ขณะที่รูปแบบการเขียนโปรแกรมของ AWS Lambda เป็นแบบไม่มีสถานะ โค้ดของคุณสามารถเข้าถึงข้อมูลแบบมีสถานะได้โดยเรียกใช้บริการเว็บอื่นๆ เช่น Amazon S3 หรือ Amazon DynamoDB

ใช่ AWS Lambda ช่วยให้คุณสามารถใช้ภาษาปกติและคุณสมบัติของระบบปฏิบัติการ เช่นการสร้างเธรดและกระบวนการเพิ่มเติม ทรัพยากรที่จัดสรรให้กับฟังก์ชัน Lambda รวมถึงหน่วยความจำ เวลาดำเนินการ ดิสก์ และการใช้งานเครือข่าย ต้องถูกแบ่งกันระหว่างเธรด/กระบวนการทั้งหมดที่ใช้ คุณสามารถเริ่มต้นกระบวนการโดยใช้ภาษาใดก็ได้ที่ Amazon Linux รองรับ

Lambda พยายามที่จะกำหนดข้อจำกัดให้น้อยที่สุดเท่าที่จะเป็นไปได้ในภาษาปกติและกิจกรรมของระบบปฏิบัติการ แต่มีกิจกรรมบางอย่างที่ปิดใช้งานอยู่ นั่นคือการเชื่อมต่อเครือข่ายขาเข้าจะถูกบล็อกโดย AWS Lambda และสำหรับการเชื่อมต่อขาออก มีเพียงซ็อกเก็ต TCP/IP และ UDP/IP เท่านั้นที่ได้รับการรองรับ และการเรียกระบบ (แก้ไขจุดบกพร่อง) ptrace จะถูกบล็อก การรับส่งข้อมูลพอร์ต TCP 25 จะถูกบล็อกเช่นกันเพื่อเป็นมาตรการป้องกันสแปม

ถ้าคุณใช้ Node.js หรือ Python คุณสามารถเขียนโค้ดสำหรับฟังก์ชันของคุณโดยใช้ตัวแก้ไขโค้ดใน AWS Lambda Console ซึ่งจะช่วยให้คุณสามารถเขียนและทดสอบฟังก์ชันของคุณ และดูผลลัพธ์ของการเรียกใช้ฟังก์ชันในสภาพแวดล้อมแบบ IDE ที่มีประสิทธิภาพได้ ไปที่คอนโซลเพื่อเริ่มต้นใช้งาน

นอกจากนี้คุณยังสามารถบีบอัดโค้ด (และไลบรารีที่เกี่ยวข้อง) เป็นไฟล์ ZIP และอัปโหลดโดยใช้ Console ของ AWS Lambda จากสภาพแวดล้อมท้องถิ่นของคุณ หรือระบุตำแหน่ง Amazon S3 ที่มีไฟล์ ZIP อยู่ ไฟล์อัปโหลดต้องมีขนาดไม่เกิน 50MB (แบบบีบอัด) คุณสามารถใช้ปลั๊กอิน AWS Eclipse เพื่อเขียนและปรับใช้ฟังก์ชัน Lambda ใน Java ได้ คุณสามารถใช้ปลั๊กอิน Virtual Studio เพื่อเขียนและปรับใช้ฟังก์ชัน Lambda ใน C# และ Node.js ได้

คุณสามารถบีบอัดโค้ด (และไลบรารีที่เกี่ยวข้อง) เป็นไฟล์ ZIP และอัปโหลดโดยใช้ AWS CLI จากสภาพแวดล้อมท้องถิ่นของคุณ หรือระบุตำแหน่ง Amazon S3 ที่มีไฟล์ ZIP อยู่ ไฟล์อัปโหลดต้องมีขนาดไม่เกิน 50MB (แบบบีบอัด) ไปที่คู่มือเริ่มต้นใช้งาน Lambda เพื่อเริ่มต้นใช้งาน

ใช่ คุณสามารถสร้างและแก้ไขตัวแปรทางสภาพแวดล้อมได้จาก AWS Lambda Console, CLI หรือ SDK หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับตัวแปรทางสภาพแวดล้อม โปรดดูเอกสารประกอบ

สำหรับข้อมูลที่สำคัญ เช่น รหัสผ่านของฐานข้อมูล เราขอแนะนำให้ใช้การเข้ารหัสฝั่งไคลเอ็นต์โดยใช้ AWS Key Management Service และจัดเก็บค่าผลลัพธ์เป็น Ciphertext ในตัวแปรสภาพแวดล้อมของคุณ คุณต้องใส่ลอจิกในโค้ดฟังก์ชัน AWS Lambda เพื่อถอดรหัสค่าเหล่านี้

คุณสามารถปรับและรักษาความปลอดภัยให้ทรัพยากรที่เกี่ยวข้องกับฟังก์ชัน Lambda ของคุณโดยใช้ Lambda API หรือคอนโซล หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับเรื่องนี้ โปรดดูเอกสารประกอบ

ได้ คุณสามารถจัดแพคเกจโค้ด (เฟรมเวิร์ก, SDK, ไลบรารี และอีกมากมาย) เช่น Lambda Layer และจัดการแล้วแบ่งปันโค้ดกับหลายฟังก์ชันได้อย่างง่ายดาย

AWS Lambda ตรวจสอบฟังก์ชัน Lambda แทนคุณโดยอัตโนมัติ รายงานเมตริกแบบเรียลไทม์ผ่าน Amazon CloudWatch รวมถึงคำขอทั้งหมด การใช้งานพร้อมกันระดับบัญชีและฟังก์ชัน เวลาแฝง อัตราข้อผิดพลาด และคำขอที่ถูก จำกัด คุณสามารถดูสถิติสำหรับแต่ละฟังก์ชัน Lambda ได้ผ่านทาง Console ของ Amazon CloudWatch หรือผ่าน Console ของ AWS Lambda นอกจากนี้คุณยังสามารถเรียก API ตรวจสอบบุคคลภายนอกในฟังก์ชัน Lambda ได้ด้วย
 

ไปที่ตัววัดการแก้ปัญหาของ CloudWatch เพื่อเรียนรู้เพิ่มเติม ค่ามาตรฐานสำหรับ AWS Lambda จะนำมาใช้กับตัววัดในตัวของ Lambda

AWS Lambda ทำงานร่วมกับ Amazon CloudWatch Logs โดยอัตโนมัติ โดยจะสร้างกลุ่มบันทึกสำหรับแต่ละฟังก์ชัน Lambda และจัดเตรียมรายการบันทึกเหตุการณ์วงจรชีวิตของแอปพลิเคชันพื้นฐาน รวมถึงการบันทึกทรัพยากรที่ใช้สำหรับการใช้ฟังก์ชันนั้นในแต่ละครั้ง คุณสามารถแทรกบันทึกการเข้าสู่ระบบเพิ่มเติมลงในโค้ดของคุณได้อย่างง่ายดาย นอกจากนี้คุณยังสามารถเรียก API บันทึกการเข้าสู่ระบบของบุคคลภายนอกในฟังก์ชัน Lambda ได้อีกด้วย ไปที่การแก้ไขปัญหาฟังก์ชัน Lambda เพื่อเรียนรู้เพิ่มเติม อัตรา Amazon CloudWatch logs จะได้รับการนำมาใช้

คุณไม่จำเป็นต้องปรับขนาดฟังก์ชัน Lambda ของคุณ ซึ่ง AWS Lambda จะปรับขนาดแทนคุณให้เองโดยอัตโนมัติ ทุกครั้งที่ได้รับการแจ้งเตือนเหตุการณ์สำหรับฟังก์ชันของคุณ AWS Lambda จะหาความจุที่ว่างในฟลีตการประมวลผลอย่างรวดเร็วและเรียกใช้โค้ดของคุณ เนื่องจากโค้ดของคุณไม่มีสถานะ AWS Lambda จึงสามารถทำสำเนาฟังก์ชันของคุณได้มากตามต้องการโดยไม่ต้องปรับใช้งานเป็นเวลานานและกำหนดค่าจนล่าช้า ไม่มีข้อจำกัดพื้นฐานในการปรับฟังก์ชัน AWS Lambda จะจัดสรรความจุแบบไดนามิกเพื่อให้ตรงกับอัตราของเหตุการณ์ที่เข้ามา

ในรูปแบบทรัพยากร AWS Lambda คุณจะเลือกจำนวนหน่วยความจำที่คุณต้องการสำหรับฟังก์ชันของคุณและได้รับการจัดสรรพลังงาน CPU และทรัพยากรอื่นๆ ตามสัดส่วน ตัวอย่างเช่น การเลือกหน่วยความจำ 256 MB จะจัดสรรพลังงาน CPU ให้กับฟังก์ชัน Lambda ของคุณมากกว่าสองเท่าโดยประมาณหากเทียบกับการขอหน่วยความจำ 128 MB และจัดสรรพลังงาน CPU เพียงครึ่งเดียวหากเทียบกับการเลือกหน่วยความจำ 512 MB หากต้องการเรียนรู้เพิ่มเติม ให้ดูที่เอกสารประกอบการกำหนดค่าฟังก์ชัน

คุณสามารถตั้งค่าหน่วยความจำของคุณได้ตั้งแต่ 128 MB ไปจนถึง 10,240 MB

ขณะนี้ลูกค้าที่ใช้งานหน่วยความจำหรือปริมาณงานที่ต้องประมวลผลอย่างหนักสามารถใช้หน่วยความจำสำหรับฟังก์ชันของตนได้มากขึ้นแล้ว ฟังก์ชันหน่วยความจำขนาดใหญ่ช่วยให้การใช้งานแบบมัลติเธรดสามารถทำงานได้เร็วขึ้น เหมาะสำหรับการใช้งานข้อมูลและการประมวลผลอย่างหนัก เช่น แมชชีนเลิร์นนิ่ง, งานที่ต้องประมวลผลเป็นชุดและ ETL, การจำลองด้านการเงิน, จีโนมิกส์, HPC และการประมวลผลสื่อ

ฟังก์ชัน AWS Lambda สามารถกำหนดค่าให้ทำงานได้สูงสุดถึง 15 นาทีต่อการดำเนินการ คุณสามารถตั้งค่าการหมดเวลาเป็นค่าใดก็ได้ระหว่าง 1 วินาทีและ 15 นาที

AWS Lambda มีค่าใช้จ่ายตามจำนวนครั้งที่ใช้งาน โปรดดูรายละเอียดในหน้าค่าบริการ AWS Lambda

ใช่ นอกจากจะประหยัดค่าใช้จ่ายใน Amazon EC2 และ AWS Fargate แล้ว คุณยังสามารถใช้ Compute Savings Plans เพื่อประหยัดค่าใช้จ่ายใน AWS Lambda ได้เช่นกัน Compute Savings Plans มีส่วนลดสูงสุดถึง 17% สำหรับระยะเวลา กระบวนการทำงานพร้อมกันที่มีการเตรียมใช้งาน และระยะเวลา (กระบวนการทำงานพร้อมกันที่มีการเตรียมใช้งาน) Compute Savings Plans จะไม่มีส่วนลดสำหรับคำขอในใบเรียกเก็บเงิน Lambda ของคุณ แต่คุณสามารถนำสัญญาการใช้งาน Compute Savings Plans มาใช้กับคำขอได้ในอัตราปกติ

ใช่ โดยค่าเริ่มต้นแล้ว ฟังก์ชัน AWS Lambda แต่ละอันจะมีโค้ดเวอร์ชันปัจจุบันอยู่แล้ว ไคลเอ็นต์ของฟังก์ชัน Lambda ของคุณสามารถเรียกใช้เวอร์ชันที่เฉพาะเจาะจงหรือรับการใช้งานล่าสุดได้ โปรดอ่านเอกสารประกอบเกี่ยวกับการกำหนดเวอร์ชันของฟังก์ชัน Lambda

เวลาในการปรับใช้อาจแตกต่างกันไปตามขนาดโค้ดของคุณ แต่ฟังก์ชัน AWS Lambda โดยทั่วไปจะพร้อมใช้งานภายในไม่กี่วินาทีหลังจากอัปโหลด

ใช่ คุณสามารถรวมสำเนาไลบรารีของคุณเอง (รวมถึง AWS SDK) เพื่อใช้เวอร์ชันอื่นนอกเหนือจากเวอร์ชันตามค่าเริ่มต้นของ AWS Lambda ได้

AWS Lambda เสนอระดับราคาพร้อมส่วนลดสำหรับระยะเวลาฟังก์ชันตามคำขอรายเดือนที่สูงกว่าเกณฑ์ที่กำหนด ราคาตามระดับขั้นสามารถใช้ได้กับฟังก์ชันที่ทำงานบนสถาปัตยกรรมทั้ง x86 และ Arm ระดับราคาของ Lambda จะใช้เพื่อรวมระยะเวลาตามความต้องการรายเดือนของฟังก์ชันของคุณที่ทำงานบนสถาปัตยกรรมเดียวกัน (x86 หรือ Arm ตามลำดับ) ในภูมิภาคเดียวกันภายในบัญชี หากคุณกำลังใช้การเรียกเก็บเงินรวมใน AWS Organizations ระดับราคาจะถูกนำไปใช้กับระยะเวลารวมรายเดือนของฟังก์ชันของคุณที่ทำงานบนสถาปัตยกรรมเดียวกัน ในภูมิภาคเดียวกัน ทั่วทุกบัญชีในองค์กร ตัวอย่างเช่น หากคุณใช้งานฟังก์ชัน x86 Lambda ในภูมิภาคสหรัฐอเมริกาฝั่งตะวันออก (โอไฮโอ) คุณจะต้องจ่าย 0.0000166667 USD ในทุก GB-วินาทีในช่วง 6 พันล้าน GB-วินาทีแรกต่อเดือน และ 0.0000150000 USD ในทุก GB-วินาทีสำหรับ 9 พันล้านถัดไป GB-วินาทีต่อเดือน และ 0.0000133334 USD สำหรับทุก GB-วินาที ที่มากกว่า 15 พันล้าน GB-วินาทีต่อเดือน ในภูมิภาคนั้น ราคาสำหรับคำขอของกระบวนการทำงานพร้อมกันที่มีการเตรียมใช้งาน และระยะเวลาการทำงานพร้อมกันที่มีการเตรียมใช้งานยังคงไม่เปลี่ยนแปลง สำหรับข้อมูลเพิ่มเติม โปรดดูค่าบริการ AWS Lambda

ใช่ การใช้ Lambda ที่อยู่ในแผนการออมรายชั่วโมงจะนำมาคำนวนค่าใช้จ่ายด้วยเรต CSP พร้อมส่วนลด การใช้งานที่นอกเหนือจากแผนการใช้งานนี้จะถูกเก็บเงินตามระดับการใช้งานรายเดือนของคุณ

แหล่งเหตุการณ์คือบริการของ AWS หรือแอปพลิเคชันที่นักพัฒนาสร้างขึ้นซึ่งสร้างเหตุการณ์ที่เรียกใช้ฟังก์ชัน AWS Lambda เพื่อใช้งาน บริการบางอย่างเผยแพร่เหตุการณ์เหล่านี้ไปยัง Lambda ด้วยการเรียกใช้ฟังก์ชันระบบคลาวด์โดยตรง (ยกตัวอย่างเช่น Amazon S3) Lambda ยังสามารถสำรวจทรัพยากรในบริการอื่นๆ ที่ไม่ได้เผยแพร่เหตุการณ์ไปยัง Lambda ตัวอย่างเช่น Lambda สามารถดึงบันทึกจากสตรีม Amazon Kinesis หรือคิว Amazon SQS และเรียกใช้ฟังก์ชัน Lambda สำหรับข้อความที่ดึงมาแต่ละรายการ บริการอื่น ๆ เช่น AWS CloudTrail สามารถทำหน้าที่เป็นแหล่งเหตุการณ์ได้เพียงแค่ลงชื่อเข้าใช้ Amazon S3 และใช้การแจ้งเตือนบัคเก็ต S3 เพื่อเรียกใช้ฟังก์ชัน AWS Lambda

โปรดดูรายชื่อแหล่งเหตุการณ์ทั้งหมดได้จากเอกสารประกอบของเรา

เหตุการณ์จะถูกส่งผ่านไปยังฟังก์ชัน Lambda เป็นพารามิเตอร์อินพุตเหตุการณ์ สำหรับแหล่งเหตุการณ์ที่ซึ่งเหตุการณ์มาถึงเป็นชุด เช่น Amazon SQS, Amazon Kinesis และ Amazon DynamoDB Streams พารามิเตอร์เหตุการณ์สามารถมีเหตุการณ์หลายรายการในการเรียกใช้หนึ่งครั้ง ทั้งนี้ขึ้นอยู่กับขนาดชุดที่คุณขอ หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการแจ้งเตือนเหตุการณ์ Amazon S3 โปรดไปที่การกำหนดค่าการแจ้งเตือนสำหรับเหตุการณ์ Amazon S3 หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับ Amazon DynamoDB Streams โปรดไปที่คู่มือนักพัฒนา DynamoDB Stream หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการเรียกใช้ฟังก์ชัน Lambda โดยใช้ Amazon SNS โปรดไปที่คู่มือนักพัฒนา Amazon SNS สำหรับข้อมูลเพิ่มเติมเกี่ยวกับเหตุการณ์ Amazon Cognito โปรดไปที่ Amazon Cognito สำหรับข้อมูลเพิ่มเติมเกี่ยวกับข้อมูลบันทึก AWS CloudTrail และการตรวจสอบการเรียกใช้ API ในบริการของ AWS โปรดดูที่ AWS CloudTrail

จาก Console ของ AWS Lambda คุณสามารถเลือกฟังก์ชันและเชื่อมโยงกับการแจ้งเตือนจากบัคเก็ต Amazon S3 หรือคุณสามารถใช้ Console ของ Amazon S3 และกำหนดค่าการแจ้งเตือนของบัคเก็ตเพื่อส่งไปยังฟังก์ชัน AWS Lambda ของคุณ ฟังก์ชันการทำงานแบบเดียวกันนี้ยังสามารถใช้ได้ผ่าน AWS SDK และ CLI

คุณสามารถเรียกใช้ฟังก์ชัน Lambda เมื่อมีการอัปเดตตาราง DynamoDB ได้โดยการสมัครฟังก์ชัน Lambda กับ DynamoDB Stream ที่เกี่ยวข้องกับตาราง คุณสามารถเชื่อมโยง DynamoDB Stream กับฟังก์ชัน Lambda ได้โดยใช้ Amazon DynamoDB Console, AWS Lambda Console หรือ registerEventSource API ของ Lambda

จาก Console ของ AWS Lambda คุณสามารถเลือกฟังก์ชัน Lambda และเชื่อมโยงกับสตรีม Amazon Kinesis ที่เป็นของบัญชีเดียวกันได้ ฟังก์ชันการทำงานแบบเดียวกันนี้ยังสามารถใช้ได้ผ่าน AWS SDK และ CLI

บันทึก Amazon Kinesis และ DynamoDB ที่ถูกส่งไปยังฟังก์ชัน AWS Lambda ของคุณจะได้รับการจัดลำดับอย่างเคร่งครัดต่อส่วน นั่นหมายความว่าถ้าคุณใส่บันทึกสองชิ้นลงในส่วนเดียวกัน Lambda จะรับประกันว่าฟังก์ชัน Lambda ของคุณจะถูกเรียกใช้งานสำเร็จด้วยบันทึกแรกก่อนที่จะถูกเรียกใช้กับบันทึกที่สอง หากการเรียกบันทึกหนึ่งครั้งหมดเวลา ถูกจำกัด หรือพบข้อผิดพลาดอื่นๆ Lambda จะลองอีกครั้งจนกว่าจะสำเร็จ (หรือบันทึกครบกำหนดหมดอายุใน 24 ชั่วโมง) ก่อนที่จะย้ายไปยังบันทึกถัดไป ไม่รับประกันการจัดลำดับบันทึกในส่วนข้อมูลที่แตกต่างกัน และการประมวลผลส่วนข้อมูลแต่ละส่วนจะเกิดขึ้นแบบคู่ขนาน

AWS Lambda ช่วยให้คุณดำเนินการรวมข้อมูลโดยอิงตามเวลา (เช่น จำนวน ค่าสูงสุด ผลรวม ค่าเฉลี่ย เป็นต้น) ในระยะเวลาสั้นๆ ไม่เกิน 15 นาที สำหรับข้อมูลใน Amazon Kinesis หรือ Amazon DynamoDB Streams ในพาร์ติชันเชิงตรรกะหนึ่งครั้ง เช่น ส่วนข้อมูล การทำเช่นนี้ช่วยให้คุณมีตัวเลือกในการตั้งค่าการวิเคราะห์อย่างง่ายได้สะดวกสำหรับแอปพลิเคชันตามเหตุการณ์ โดยไม่ต้องเพิ่มความซับซ้อนทางสถาปัตยกรรมใด เพราะธุรกิจและตรรกะการวิเคราะห์ของคุณสามารถอยู่ในฟังก์ชันเดียวกันได้ Lambda ช่วยให้มีการรวมระยะเวลาที่ติดกันสูงสุด 15 นาทีตามการลงตราประทับเวลาของเหตุการณ์ บริการวิเคราะห์ข้อมูลของ Amazon Kinesis ช่วยให้คุณสร้างแอปพลิเคชันการวิเคราะห์ที่ซับซ้อนยิ่งขึ้นที่รองรับตัวเลือกการประมวลผลที่ยืดหยุ่นและความทนต่อข้อผิดพลาดที่มีประสิทธิภาพด้วยการประมวลผลเพียงครั้งเดียวโดยไม่ต้องทำรายการซ้ำ และสามารถดำเนินการวิเคราะห์ Data Stream ทั้งหมดในส่วนตรรกะต่าง ๆ ได้ เพียงมี KDA คุณก็สามารถวิเคราะห์ข้อมูลภายในระยะเวลาแบบรวมประเภทต่างๆ (ระยะเวลาที่ติดกัน ระยะเวลาการเอนเอียง ระยะเวลาการเปลี่ยนแปลง ระยะเวลาเซสชัน) โดยใช้เวลาของเหตุการณ์หรือเวลาในการประมวลผล
 

	AWS Lambda	Amazon KDA
ระยะเวลาที่ติดกัน	ใช้ได้	ใช้ได้
ระยะเวลาการเอนเอียง	ใช้ไม่ได้	ใช้ได้
ระยะเวลาการเปลี่ยนแปลง	ใช้ไม่ได้	ใช้ได้
ระยะเวลาเซสชัน	ใช้ไม่ได้	ใช้ได้
การเพิ่มคุณค่าของข้อมูล	ใช้ไม่ได้	ใช้ได้
อินพุตร่วมและตารางข้อมูลอ้างอิง	ใช้ไม่ได้	ใช้ได้
สตรีมอินพุตแบบแยก	ใช้ไม่ได้	ใช้ได้
การประมวลผลเพียงครั้งเดียว	ใช้ไม่ได้	ใช้ได้
ระยะเวลาสูงสุด	15 นาที	ไม่จำกัด
ขอบเขตการรวม	การแยก/ส่วน	สตรีม
ความหมายของเวลา	เวลาของเหตุการณ์	เวลาของเหตุการณ์ เวลาในการประมวลผล

จาก Console ของ AWS Lambda คุณสามารถเลือกฟังก์ชัน Lambda และเชื่อมโยงกับหัวข้อ Amazon SNS ฟังก์ชันการทำงานแบบเดียวกันนี้ยังสามารถใช้ได้ผ่าน AWS SDK และ CLI

จาก Console ของ Amazon SES คุณสามารถตั้งค่ากฎการรับเพื่อให้ Amazon SES ส่งข้อความของคุณไปยังฟังก์ชัน AWS Lambda ได้ ฟังก์ชันการทำงานเดียวกันนี้สามารถใช้งานได้ผ่าน AWS SDK และ CLI

อันดับแรก ให้กำหนดค่าการแจ้งเตือนเพื่อส่งการแจ้งเตือน Amazon SNS จากนั้นจาก Console ของ AWS Lambda เลือกฟังก์ชัน Lambda และเชื่อมโยงกับหัวข้อ Amazon SNS นั้น ดูคู่มือนักพัฒนา Amazon CloudWatch สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการตั้งค่าการแจ้งเตือน Amazon CloudWatch

จาก Console ของ AWS Lambda คุณสามารถเลือกฟังก์ชันที่จะเรียกใช้เมื่อชุดข้อมูลที่เกี่ยวข้องกับกลุ่มข้อมูลระบุตัวตน Amazon Cognito ได้รับการซิงโครไนซ์ ฟังก์ชันการทำงานแบบเดียวกันนี้ยังสามารถใช้ได้ผ่าน AWS SDK และ CLI ไปที่ Amazon Cognito เพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้ Amazon Cognito เพื่อแชร์และซิงค์ข้อมูลผ่านอุปกรณ์ของผู้ใช้

คุณสามารถเรียกใช้ฟังก์ชัน Lambda ได้โดยใช้เหตุการณ์ที่กำหนดเองผ่านทาง API การเรียกใช้ของ AWS Lambda เฉพาะเจ้าของฟังก์ชันหรือบัญชี AWS อื่นที่เจ้าของให้สิทธิ์เท่านั้นที่จะสามารถเรียกใช้ฟังก์ชันได้ โปรดไปที่คู่มือนักพัฒนา Lambda เพื่อเรียนรู้เพิ่มเติม

AWS Lambda ออกแบบมาเพื่อประมวลผลเหตุการณ์ภายในมิลลิวินาที เวลาแฝงจะสูงขึ้นทันทีหลังจากที่สร้าง อัปเดต หรือหากไม่ได้ใช้งานฟังก์ชัน Lambda เมื่อเร็วๆ นี้

ให้อัปโหลดโค้ดที่ต้องการให้ AWS Lambda ดำเนินการ จากนั้นเรียกใช้งานจากแอปมือถือของคุณโดยใช้ AWS Lambda SDK ที่รวมอยู่ใน AWS Mobile SDK คุณสามารถเรียกใช้ทั้งแบบทางตรง (ซิงโครนัส) และแบบอะซิงโครนัสเพื่อดึงหรือตรวจสอบข้อมูลแบบเรียลไทม์ได้ นอกจากนี้คุณยังสามารถกำหนด API เองโดยใช้ Amazon API Gateway และเรียกใช้ฟังก์ชัน Lambda ของคุณผ่านทางไคลเอ็นต์ที่รองรับ REST ได้อีกด้วย หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับ AWS Mobile SDK โปรดไปที่หน้า AWS Mobile SDK หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับเกตเวย์ของ Amazon API โปรดไปที่หน้า Amazon API Gateway

คุณสามารถเรียกใช้ฟังก์ชัน Lambda ผ่าน HTTPS ได้โดยการกำหนด RESTful API เองโดยใช้ Amazon API Gateway วิธีนี้จะช่วยมอบตำแหน่งข้อมูลสำหรับฟังก์ชันของคุณซึ่งสามารถตอบสนองต่อการเรียกใช้งาน REST ได้ เช่น GET, PUT และ POST อ่านเพิ่มเติมเกี่ยวกับการใช้ AWS Lambda กับ Amazon API Gateway

เมื่อเรียกผ่าน AWS Mobile SDK ฟังก์ชัน AWS Lambda จะได้รับข้อมูลเชิงลึกเกี่ยวกับอุปกรณ์และแอปพลิเคชันโดยอัตโนมัติ ซึ่งเรียกผ่านอ็อบเจกต์ “บริบท”

เมื่อแอปใช้ข้อมูลประจำตัวของ Amazon Cognito ผู้ใช้ตำแหน่งข้อมูลสามารถรับรองความถูกต้องเองได้โดยใช้ผู้ให้บริการเข้าสู่ระบบแบบสาธารณะที่หลากหลาย เช่น Amazon, Facebook, Google และบริการอื่นๆ ที่รองรับ OpenID Connect ข้อมูลประจำตัวผู้ใช้จะถูกส่งต่อโดยอัตโนมัติและปลอดภัยไปยังฟังก์ชัน Lambda ของคุณในรูปแบบของรหัส Amazon Cognito เพื่อให้สามารถเข้าถึงข้อมูลผู้ใช้จาก Amazon Cognito หรือเป็นกุญแจสำคัญในการจัดเก็บและดึงข้อมูลใน Amazon DynamoDB หรือบริการเว็บอื่นๆ

AWS Lambda มีการผสานรวมเข้ากับ Alexa Skills Kit ซึ่งเป็นคอลเลกชันของ API แบบบริการตนเอง เครื่องมือ เอกสารประกอบ และตัวอย่างโค้ดที่ช่วยให้คุณสามารถสร้างความสามารถ (หรือ “ทักษะ”) ที่ขับเคลื่อนด้วยเสียงสำหรับ Alexa ได้ง่ายๆ เพียงอัปโหลดโค้ดฟังก์ชัน Lambda สำหรับทักษะใหม่ของ Alexa ที่คุณสร้างขึ้น แล้ว AWS Lambda จะจัดการในส่วนที่เหลือ ซึ่งก็คือการเรียกใช้โค้ดเพื่อตอบสนองต่อการโต้ตอบด้วยเสียงของ Alexa และจัดการทรัพยากรการประมวลผลแทนคุณโดยอัตโนมัติ อ่านข้อมูลเพิ่มเติมได้จากเอกสารประกอบ Amazon Skills Kit

สำหรับการแจ้งเตือนบัคเก็ต Amazon S3 และเหตุการณ์ที่กำหนดเอง AWS Lambda จะพยายามเรียกใช้ฟังก์ชันของคุณสามครั้งในกรณีที่มีข้อผิดพลาดในโค้ดของคุณหรือถ้าคุณใช้เกินขีดจำกัดของบริการหรือทรัพยากร สำหรับแหล่งเหตุการณ์ตามคำสั่งที่ AWS Lambda ทำงานแทนคุณเช่น Amazon DynamoDB Streams และ Amazon Kinesis Streams นั้น Lambda จะพยายามดำเนินการในกรณีที่เกิดข้อผิดพลาดของโค้ดนักพัฒนาต่อไปจนกว่าข้อมูลจะหมดอายุ คุณสามารถติดตามความคืบหน้าผ่าน Console ของ Amazon Kinesis และ Amazon DynamoDB และผ่านทางตัววัด Amazon CloudWatch ที่ AWS Lambda สร้างขึ้นสำหรับฟังก์ชันของคุณ นอกจากนี้คุณยังสามารถตั้งค่าการแจ้งเตือน Amazon CloudWatch ตามข้อผิดพลาดหรืออัตราการควบคุมการทำงาน

แอปพลิเคชันที่ใช้ Lambda (เรียกอีกอย่างว่าแอปพลิเคชันไร้เซิร์ฟเวอร์) ประกอบด้วยฟังก์ชันที่เรียกใช้โดยเหตุการณ์ แอปพลิเคชันไร้เซิร์ฟเวอร์โดยทั่วไปประกอบด้วยหนึ่งหรือหลายฟังก์ชันที่เรียกใช้โดยเหตุการณ์ต่างๆ เช่นการอัปโหลดออบเจ็กต์ไปยัง Amazon S3, การแจ้งเตือน Amazon SNS หรือการดำเนินการ API ฟังก์ชันเหล่านี้สามารถทำงานได้เองหรือใช้ประโยชน์จากทรัพยากรอื่นๆ เช่นตาราง DynamoDB หรือบัคเก็ต Amazon S3 แอปพลิเคชันไร้เซิร์ฟเวอร์แบบพื้นฐานที่สุดคือฟังก์ชัน

คุณสามารถปรับใช้และจัดการแอปพลิเคชันไร้เซิร์ฟเวอร์โดยใช้ AWS Serverless Application Model (AWS SAM) AWS SAM เป็นข้อกำหนดที่กำหนดกฎสำหรับการแสดงแอปพลิเคชันไร้เซิร์ฟเวอร์บน AWS ข้อกำหนดนี้สอดคล้องกับรูปแบบคำสั่งที่ AWS CloudFormation ใช้ในปัจจุบันและได้รับการรองรับแบบเนทีฟภายใน AWS CloudFormation ในฐานะชุดของประเภททรัพยากร (เรียกว่า "ทรัพยากรแบบไร้เซิร์ฟเวอร์") ทรัพยากรเหล่านี้ทำให้ลูกค้าของ AWS สามารถใช้งาน CloudFormation ได้ง่ายขึ้นเพื่อกำหนดค่าและปรับใช้แอปพลิเคชันแบบไร้เซิร์ฟเวอร์โดยใช้ CloudFormation API ที่มีอยู่

คุณสามารถเลือกจากคอลเลกชันของแอปพลิเคชันไม่ต้องใช้เซิร์ฟเวอร์ซึ่งเผยแพร่โดยนักพัฒนา บริษัท และพาร์ทเนอร์ในชุมชน AWS ด้วย AWS Serverless Application Repository หลังจากการค้นพบแอปพลิเคชันแล้ว คุณสามารถกำหนดค่าและใช้งานได้โดยตรงจาก Console ของ Lambda

คุณสามารถดำเนินการเผยแพร่แอปพลิเคชันไร้เซิร์ฟเวอร์ของคุณโดยอัตโนมัติได้โดยใช้ AWS CodePipeline และ AWS CodeDeploy CodePipeline คือบริการจัดส่งแบบต่อเนื่องที่ช่วยให้คุณสามารถจำลอง แสดงภาพ และดำเนินการขั้นตอนต่างๆ ที่จำเป็นสำหรับการเผยแพร่แอปพลิเคชันไร้เซิร์ฟเวอร์ของคุณโดยอัตโนมัติ CodeDeploy มีกลไกการปรับใช้ระบบอัตโนมัติสำหรับแอปพลิเคชันที่ใช้ Lambda CodeDeploy ช่วยให้คุณสามารถปรับแต่งการใช้งานได้ตามวิธีปฏิบัติที่ดีที่สุดที่ได้รับการยอมรับเช่นการใช้ Canary และการปรับใช้โดยตรง และช่วยให้คุณสร้างกรอบที่จำเป็นเพื่อตรวจสอบว่าโค้ดใหม่ที่มีการใช้งานนั้นปลอดภัย มั่นคง และพร้อมที่จะปล่อยสู่กระบวนการผลิตอย่างเต็มที่
 

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับ CI/CD แบบไร้เซิร์ฟเวอร์ โปรดไปที่เอกสารประกอบของเรา

ไปที่ AWS Lambda Console และดาวน์โหลดพิมพ์เขียวแบบใดแบบหนึ่งของเราเพื่อเริ่มต้น ไฟล์ที่คุณดาวน์โหลดจะมีไฟล์ AWS SAM (ซึ่งกำหนดทรัพยากร AWS ในแอปพลิเคชันของคุณ) และไฟล์ .ZIP (ซึ่งรวมถึงโค้ดฟังก์ชันของคุณ) จากนั้นคุณสามารถใช้คำสั่ง AWS CloudFormation เพื่อรวมแพ็กเกจและปรับใช้แอปพลิเคชันแบบไร้เซิร์ฟเวอร์ที่คุณเพิ่งดาวน์โหลดมาได้ โปรดไปที่เอกสารประกอบของเราเพื่อดูรายละเอียดเพิ่มเติม

คุณสามารถใช้ AWS Step Functions เพื่อประสานงานฟังก์ชัน AWS Lambda ชุดต่าง ๆ ตามลำดับที่กำหนด คุณสามารถเรียกใช้ฟังก์ชัน Lambda หลายๆ แบบตามลำดับ ส่งผ่านข้อมูลจากที่หนึ่งไปยังอีกที่ และ/หรือแบบขนาน และ Step Functions จะรักษาสถานะไว้ในระหว่างการดำเนินการสำหรับคุณ

คุณสามารถเปิดใช้งานฟังก์ชัน Lambda ของคุณสำหรับการติดตามด้วย AWS X-Ray โดยเพิ่มสิทธิ์ X-Ray ในบทบาทการดำเนินการของ Lambda และเปลี่ยน “โหมดการสืบค้นกลับ” ของฟังก์ชันเป็น “ใช้งานอยู่” เมื่อเปิดใช้งาน X-Ray สำหรับฟังก์ชัน Lambda ของคุณ AWS Lambda จะส่งข้อมูลการติดตามไปยัง X-Ray เกี่ยวกับค่าใช้จ่ายบริการของ Lambda ที่เกิดขึ้นเมื่อเรียกใช้ฟังก์ชันของคุณ ซึ่งจะช่วยให้ข้อมูลเชิงลึกแก่คุณเช่นค่าใช้จ่ายบริการ Lambda เวลาเริ่มทำงาน และเวลาการทำงานของฟังก์ชัน นอกจากนี้คุณยังสามารถใช้ X-Ray SDK ในแพคเกจการติดตั้ง Lambda ของคุณเพื่อสร้างกลุ่มการติดตาม อธิบายร่องรอย หรือดูส่วนการติดตามสำหรับการเรียกดาวน์สตรีมจากฟังก์ชัน Lambda ของคุณ X-Ray SDK มีให้บริการแล้วสำหรับ Node.js และ Java โปรดไปที่การแก้ไขปัญหาแอปพลิเคชันที่ใช้งาน Lambda เพื่อเรียนรู้เพิ่มเติม จะใช้อัตรา AWS X-Ray

ใช่ คุณสามารถสร้างแอปพลิเคชันแบบไร้เซิร์ฟเวอร์ Lambda ที่ปรับขนาดได้และมีความปลอดภัยสูง ซึ่งเชื่อมต่อฐานข้อมูลแบบเชิงสัมพันธ์โดยใช้พร็อกซีของ Amazon RDS ซึ่งเป็นพร็อกซีฐานข้อมูลที่มีความพร้อมใช้งานสูงและจัดการการเชื่อมต่อพร้อมกันหลายพันรายการกับฐานข้อมูลแบบเชิงสัมพันธ์ ปัจจุบัน RDS Proxy ให้การสนับสนุนฐานข้อมูล MySQL และ Aurora คุณสามารถเริ่มใช้ RDS Proxy ได้ผ่านคอนโซล Amazon RDS หรือคอนโซล AWS Lambda ระบบจะเรียบเก็บเงินค่าแอปพลิเคชันแบบไร้เซิร์ฟเวอร์ที่ใช้กลุ่มการเชื่อมต่อที่มีการจัดการอย่างเต็มรูปแบบจาก RDS Proxy ตาม ค่าบริการ RDS Proxy

ข้อกำหนดนี้เป็นแบบโอเพนซอร์สภายใต้ Apache 2.0 ซึ่งช่วยให้คุณและผู้อื่นสามารถปรับใช้และรวม AWS SAM ในเครื่องมือสำหรับบิลด์ การปรับใช้ การตรวจสอบ และการจัดการที่มีสิทธิ์ใช้งานเชิงพาณิชย์ คุณสามารถเข้าถึงพื้นที่เก็บข้อมูล AWS SAM บน GitHub ได้ที่นี่

ตอนนี้ AWS Lambda ช่วยให้คุณสามารถรวมแพ็กเกจและติดตั้งใช้ฟังก์ชันจริงเป็นอิมเมจคอนเทนเนอร์ ลูกค้าสามารถใช้ประโยชน์จากความยืดหยุ่นและความคุ้นเคยของเครื่องมือคอนเทนเนอร์ และความคล่องตัวรวมถึงความง่ายดายในการทำงานของ AWS Lambda เพื่อสร้างแอปพลิเคชัน

คุณสามารถเริ่มต้นจากอิมเมจพื้นฐานที่ AWS ให้มาสำหรับ Lambda หรือใช้หนึ่งในอิมเมจในชุมชนหรือในบริษัทเอกชนที่คุณต้องการ จากนั้นเพียงใช้ Docker CLI สร้างอิมเมจ อัปโหลดไปยัง Amazon ECR แล้วสร้างฟังก์ชันโดยใช้อินเทอร์เฟซและเครื่องมือ Lambda ทั้งหมดที่คุณคุ้นเคย เช่น AWS Management Console, AWS CLI, AWS SDK, AWS SAM และ AWS CloudFormation

คุณสามารถปรับใช้อิมเมจพื้นฐานของ Linux จากบริษัทภายนอก (เช่น Alpine หรือ Debian) ลงใน Lambda เพิ่มเติมจากอิมเมจที่ Lambda มีให้ได้ AWS Lambda จะรองรับอิมเมจทั้งหมดตามรูปแบบรายการอิมเมจดังต่อไปนี้: Docker Image Manifest V2 Schema 2 (ใช้กับ Docker เวอร์ชัน 1.10 หรือใหม่กว่า) หรือ Open Container Initiative (OCI) Spec (v1.0 หรือใหม่กว่า) Lambda รองรับรูปภาพขนาดสูงสุด 10 GB

AWS Lambda ให้รูปภาพพื้นฐานที่หลากหลายที่ลูกค้าสามารถขยายเพิ่มได้ และลูกค้ายังสามารถใช้รูปภาพของ Linux ตามที่ต้องการโดยมีขนาดสูงสุดไม่เกิน 10 GB

คุณสามารถใช้เครื่องมือคอนเทนเนอร์ใดก็ได้ตราบเท่าที่มีการรองรับหนึ่งในรูปแบบรายการอิมเมจคอนเทนเนอร์ดังต่อไปนี้: Docker Image Manifest V2 Schema 2 (ใช้กับ Docker เวอร์ชัน 1.10 หรือใหม่กว่า) หรือ Open Container Initiative (OCI) Specifications (v1.0 หรือใหม่กว่า) เช่น คุณสามารถใช้เครื่องมือคอนเทนเนอร์แบบเนทีฟ (เช่น รันด็อคเกอร์, สร้างด็อคเกอร์, Buildah และ Packer) เพื่อกำหนดฟังก์ชันของคุณเป็นอิมเมจคอนเทนเนอร์และติดตั้งใช้จริงกับ Lambda

คุณสมบัติที่มีอยู่ทั้งหมดของ AWS Lambda สามารถใช้ได้กับฟังก์ชันที่ติดตั้งใช้จริงเป็นอิมเมจคอนเทนเนอร์ ยกเว้นเลเยอร์ Lambda และการลงชื่อโค้ด หลังจากติดตั้งใช้จริงแล้ว AWS Lambda จะปฏิบัติต่อรูปภาพเป็นแบบเปลี่ยนแปลงไม่ได้ ลูกค้าสามารถใช้เลเยอร์คอนเทนเนอร์ในระหว่างขั้นตอนการสร้างเพื่อรวมความเกี่ยวข้องเข้าด้วยกัน

ยังใช้ไม่ได้ในขณะนี้ หลังติดตั้งใช้จริงลงใน AWS Lambda แล้ว รูปภาพของคุณจะเปลี่ยนแปลงไม่ได้ บริการจะไม่แพทช์หรืออัปเดตรูปภาพ อย่างไรก็ตาม AWS Lambda จะเผยแพร่รูปภาพพื้นฐานที่มีการจัดการดูแลสำหรับรันไทม์ที่รองรับทั้งหมดที่ขึ้นอยู่กับสภาพแวดล้อมที่ได้รับการจัดการของ Lambda รูปภาพที่เผยแพร่เหล่านี้จะได้รับการแพทช์และอัปเดตไปพร้อมกับการอัปเดตต่างๆ ในรันไทม์ที่ได้รับการจัดการของ AWS Lambda คุณสามารถดึงและใช้รูปภาพพื้นฐานล่าสุดจาก DockerHub หรือ Amazon ECR Public สร้างอิมเมจคอนเทนเนอร์ใหม่ และติดตั้งใช้จริงใน AWS Lambda ผ่านทาง Amazon ECR การทำเช่นนี้ช่วยให้คุณสามารถสร้างและทดสอบอิมเมจรวมถึงรันไทม์ที่อัปเดตก่อนการปรับใช้อิมเมจในการผลิต

ฟังก์ชันที่สร้างโดยใช้การเก็บถาวร ZIP เทียบกับอิมเมจคอนเทนเนอร์ แตกต่างกันสามประการหลักๆ คือ

1. ฟังก์ชันที่สร้างโดยใช้การเก็บถาวร ZIP มีขนาดแพ็กเกจโค้ดสูงสุด 250 MB แบบแตกไฟล์ไว้ และฟังก์ชันที่สร้างโดยใช้อิมเมจคอนเทนเนอร์มีขนาดรูปภาพสูงสุด 10 GB 
2. Lambda ใช้ Amazon ECR เป็นพื้นที่เก็บโค้ดที่สำคัญสำหรับฟังก์ชันที่ได้รับการกำหนดให้เป็นอิมเมจคอนเทนเนอร์ ดังนั้นฟังก์ชันจึงไม่สามารถเรียกคืนได้เมื่อรูปภาพที่สำคัญถูกลบออกจาก ECR 
3. ฟังก์ชัน ZIP จะแพทช์โดยอัตโนมัติเพื่อความปลอดภัยของรันไทม์ล่าสุดและการแก้ไขจุดบกพร่อง ฟังก์ชันที่กำหนดให้เป็นอิมเมจคอนเทนเนอร์จะเปลี่ยนแปลงไม่ได้ และลูกค้าต้องรับผิดชอบต่อส่วนประกอบที่รวมเป็นแพ็กเกจในฟังก์ชันของตน ลูกค้าสามารถใช้ประโยชน์จากอิมเมจพื้นฐานที่ AWS ให้มา ซึ่ง AWS จะอัปเดตเป็นประจำเพื่อความปลอดภัยและการแก้ไขจุดบกพร่อง โดยใช้แพทช์ล่าสุดที่มี

ไม่แตกต่าง AWS Lambda จะตรวจสอบให้แน่ใจว่าโพรไฟล์ประสิทธิภาพสำหรับฟังก์ชันที่รวมแพ็กเกจเป็นอิมเมจคอนเทนเนอร์นั้นเหมือนกับฟังก์ชันที่รวมแพ็กเกจเป็นการเก็บถาวร ZIP รวมถึงมีเวลาในการเริ่มต้นใหม่เพียงเสี้ยววินาทีตามปกติ

ไม่มีการเรียกเก็บเงินเพิ่มเติมสำหรับการรวมแพ็กเกจและติดตั้งใช้ฟังก์ชันเป็นอิมเมจคอนเทนเนอร์ใน AWS Lambda เมื่อคุณเรียกใช้ฟังก์ชันที่ติดตั้งใช้เป็นอิมเมจคอนเทนเนอร์ คุณเพียงชำระเงินในราคาปกติตามคำขอและระยะเวลาในการดำเนินการเท่านั้น หากต้องการเรียนรู้เพิ่มเติม โปรดไปที่ค่าบริการ AWS Lambda ระบบจะเรียกเก็บเงินสำหรับการจัดเก็บอิมเมจคอนเทนเนอร์ใน Amazon ECR ที่ราคามาตรฐานสำหรับ ECR หากต้องการเรียนรู้เพิ่มเติม โปรดไปที่ค่าบริการ Amazon ECR

Lambda Runtime Interface Emulator เป็นพร็อกซีสำหรับ Runtime API ของ Lambda ซึ่งช่วยให้ลูกค้าสามารถทดสอบฟังก์ชัน Lambda ในพื้นที่ที่รวมแพ็กเกจเป็นภาพคอนเทนเนอร์ได้ RIE เป็นเว็บเซิร์ฟเวอร์ที่ใช้พื้นที่น้อยซึ่งจะแปลงคำขอ HTTP ไปเป็นเหตุการณ์ JSON และจำลอง Lambda Runtime API ช่วยให้คุณทดสอบฟังก์ชันภายในโดยใช้เครื่องมือที่คุ้นเคย เช่น cURL และ Docker CLI (เมื่อทดสอบฟังก์ชันที่รวมแพ็กเกจเป็นอิมเมจคอนเทนเนอร์) ทั้งยังช่วยให้การใช้งานแอปพลิเคชันของคุณเป็นเรื่องง่ายบนบริการประมวลผลเพิ่มเติม คุณสามารถรวม Lambda Runtime Interface Emulator ลงในอิมเมจคอนเทนเนอร์ของคุณเพื่อให้ยอมรับคำขอ HTTP ได้แบบเนทีฟแทนเหตุการณ์ JSON ที่จำเป็นสำหรับการปรับใช้กับ Lambda ส่วนประกอบนี้จะไม่จำลองตัวประสานการทำงานของ Lambda หรือการกำหนดค่าความปลอดภัยและการตรวจสอบสิทธิ์ Runtime Interface Emulator เป็นเครื่องมือแบบโอเพนซอร์สบน GitHub คุณสามารถเริ่มต้นใช้งานโดยดาวน์โหลดและติดตั้งลงภายในเครื่องของคุณ

Lambda Runtime API ในบริการ Lambda ที่กำลังทำงานอยู่ ยอมรับเหตุการณ์ JSON และให้การตอบกลับ Lambda Runtime Interface Emulator ช่วยให้ฟังก์ชันที่ถูกรวมแพ็กเกจเป็นอิมเมจคอนเทนเนอร์ยอมรับคำขอ HTTP ในระหว่างการทดสอบภายในโดยใช้เครื่องมือ เช่น cURL และเผยคำขอเหล่านั้นผ่านทางอินเทอร์เฟซเดียวกันภายในให้แก่ฟังก์ชัน ช่วยให้คุณสามารถใช้คำสั่งการรันด็อคเกอร์หรือการสร้างด็อคเกอร์เพื่อทดสอบแอปพลิเคชัน Lambda ภายในของคุณ

คุณสามารถใช้โปรแกรมจำลองเพื่อทดสอบว่าโค้ดฟังก์ชันใช้งานได้กับสภาพแวดล้อมของ Lambda ทำงานได้อย่างราบรื่น และให้ผลลัพธ์ตามที่คาดหวังหรือไม่ เช่น คุณสามารถจำลองเหตุการณ์การทดสอบจากแหล่งเหตุการณ์ต่างๆ ได้ คุณยังสามารถใช้เพื่อทดสอบส่วนต่อขยายและเอเจนต์ที่สร้างลงในอิมเมจคอนเทนเนอร์เทียบกับ Lambda Extensions API ได้

ลูกค้าสามารถเพิ่ม Runtime Interface Emulator เป็นจุดขาเข้าในอิมเมจคอนเทนเนอร์หรือรวมแพ็กเกจเป็นตัวพ่วงเพื่อให้แน่ใจว่าตอนนี้อิมเมจคอนเทนเนอร์ยอมรับคำขอ HTTP แทนเหตุการณ์ JSON การทำเช่นนี้ช่วยให้ทำการเปลี่ยนแปลงที่จำเป็นในการเรียกใช้อิมเมจคอนเทนเนอร์บนบริการประมวลผลเพิ่มเติมมีความง่ายยิ่งขึ้น ลูกค้าจะต้องรับผิดชอบในการตรวจสอบให้แน่ใจว่าตนปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดทั้งหมดด้านความปลอดภัย ประสิทธิภาพ และการทำงานพร้อมกันสำหรับสภาพแวดล้อมที่ตนเลือก RIE เป็นเครื่องมือสำเร็จรูปอยู่ในรูปภาพที่ AWS Lambda มีให้ และพร้อมใช้งานตามค่าเริ่มต้นใน AWS SAM CLI ผู้ให้บริการอิมเมจพื้นฐานสามารถใช้เอกสารประกอบเพื่อมอบประสบการณ์เดียวกันสำหรับอิมเมจพื้นฐานของตนเองได้

คุณสามารถติดตั้งใช้แอปพลิเคชันที่มีคอนเทนเนอร์ลงใน AWS Lambda เมื่อเป็นไปตามข้อกำหนดด้านล่างนี้:

1. อิมเมจคอนเทนเนอร์ต้องใช้งาน Lambda Runtime API เรามีชุดแพ็กเกจซอฟต์แวร์แบบโอเพนซอร์สอย่าง Runtime Interface Clients (RIC) ที่ใช้งาน Lambda Runtime API ช่วยให้คุณขยายรูปภาพพื้นฐานที่ต้องการให้สามารถใช้งานได้กับ Lambda อย่างราบรื่น
2. อิมเมจคอนเทนเนอร์จะต้องสามารถทำงานได้บนระบบไฟล์แบบอ่านอย่างเดียว โค้ดฟังก์ชันของคุณสามารถเข้าถึงพื้นที่เก็บข้อมูลของไดเรกทอรี/tmp แบบเขียนได้ขนาด 512 MB หากคุณใช้อิมเมจที่จะต้องมีไดเรกทอรีรากแบบเขียนได้ ให้กำหนดค่าอิมเมจเพื่อเขียนลงในไดเรกทอรี /tmp
3. ผู้ใช้ Lambda เริ่มต้นสามารถอ่านไฟล์ที่จำเป็นสำหรับการดำเนินการของโค้ดฟังก์ชันได้ Lambda กำหนดผู้ใช้ Linux เริ่มต้นให้มีสิทธิ์ที่มีความพิเศษน้อยที่สุดที่สอดคล้องตามแนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัย คุณจำเป็นต้องตรวจสอบยืนยันว่าโค้ดแอปพลิเคชันของคุณไม่ได้ขึ้นอยู่กับไฟล์ที่ถูกจำกัดโดยผู้ใช้ Linux รายอื่นสำหรับใช้ดำเนินการ
4. เป็นอิมเมจคอนเทนเนอร์บน Linux

AWS SnapStart สามารถปรับปรุงประสิทธิภาพในการเริ่มใช้งานจากหลายวินาทีเป็นต่ำที่สุดจนเท่ากับวินาทีย่อยสำหรับแอปพลิเคชันที่อ่อนไหวต่อเวลาแฝง SnapStart ทำงานโดยการสแนปชอตสถานะหน่วยความจำ (และดิสก์) ที่เริ่มต้นของฟังก์ชันของคุณ และแคชสแนปช็อตนี้เพื่อเข้าถึงเวลาแฝงต่ำ เมื่อเรียกดำเนินการฟังก์ชันของคุณในภายหลัง Lambda จะดำเนินการต่อในสภาพแวดล้อมการดำเนินการจากสแนปช็อตที่เริ่มต้นล่วงหน้านี้แทนที่จะเริ่มต้นสแนปช็อตดังกล่าวตั้งแต่แรก ซึ่งจะช่วยลดเวลาแฝงในการเริ่มใช้งานได้ เพื่อความยืดหยุ่น Lambda จะเก็บสำเนาแคชของสแนปช็อตของคุณและนำไปใช้กับการอัปเดตซอฟต์แวร์โดยอัตโนมัติ เช่น การอัปเกรดรันไทม์และแพตช์ความปลอดภัยไปยังสแนปช็อตดังกล่าว

Lambda SnapStart คือการกำหนดค่าระดับฟังก์ชันอย่างง่ายที่สามารถกำหนดค่าสำหรับฟังก์ชันทั้งอันใหม่และอันที่มีอยู่ด้วยการใช้งาน Lambda API, คอนโซลการจัดการของ AWS, อินเทอร์เฟซบรรทัดคำสั่ง (CLI) ของ AWS, AWS SDK, AWS Cloud Development Kit (CDK), AWS CloudFormation และโมเดลแอปพลิเคชันแบบไม่ต้องใช้เซิร์ฟเวอร์ (SAM) ของ AWS เมื่อคุณตั้งค่า Lambda SnapStart ทุกเวอร์ชันของฟังก์ชันที่เผยแพร่หลังจากนั้นจะได้รับประโยชน์จากการปรับปรุงประสิทธิภาพในการเริ่มต้นที่ให้โดย Lambda SnapStart เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับ Lambda SnapStart โปรดดูที่ เอกสารประกอบ

Lambda SnapStart คือการเพิ่มประสิทธิภาพที่ช่วยให้ฟังก์ชันของคุณใช้เวลาเริ่มต้นเร็วขึ้น โดยใช้การลดเวลาแฝงของตัวแปรที่เกิดขึ้นระหว่างการดำเนินการทดสอบรหัสการเริ่มต้นแบบครั้งเดียว ในระหว่างที่ Lambda SnapStart ลดเวลาแฝงในการเริ่มใช้งานลง แต่การทำงานนี้เป็นการเพิ่มประสิทธิภาพที่ดีที่สุดและไม่รับประกันว่าจะหยุดการทำงานของการเริ่มต้นแบบไม่เชื่อมต่อกับอินเทอร์เน็ต หากแอปพลิเคชันมีข้อกำหนดด้านเวลาแฝงที่เข้มงวดและต้องการเวลาเริ่มต้นด้วยตัวเลขสองหลักในระดับมิลลิวินาที เราขอแนะนำให้คุณใช้ PC

Lambda SnapStart รองรับรันไทม์หลายรายการ รวมถึง Java 11 (และใหม่กว่า), Python 3.12 (และใหม่กว่า) และ .NET 8 (และใหม่กว่า) เวอร์ชันในอนาคตของรันไทม์จะได้รับการรองรับหลังจากมีการเปิดตัว สำหรับรันไทม์ที่ Lambda รองรับทั้งหมดดูได้ที่ เอกสารประกอบรันไทม์ Lambda

ไม่ Lambda SnapStart และ PC ไม่สามารถเปิดใช้งานพร้อมกันได้ในฟังก์ชันตัวเดียวกัน

ใช่ คุณสามารถปรับแต่งฟังก์ชันของ Lambda SnapStart เพื่อเข้าถึงทรัพยากรใน Virtual Private Cloud (VPC) ได้ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการตั้งค่าฟังก์ชันด้วย VPC ดูได้ที่ เอกสารประกอบ Lambda

ใช่ คุณสามารถกำหนดค่า Lambda SnapStart สำหรับฟังก์ชันที่เรียกใช้บนสถาปัตยกรรมทั้ง x86 และ Arm ได้

ไม่ คุณไม่สามารถใช้งาน Lambda SnapStart ด้วย Amazon EFS ได้ในขณะนี้

ไม่ คุณไม่สามารถใช้งาน Lambda SnapStart ด้วยพื้นที่จัดเก็บชั่วคราวที่ใหญ่กว่า (/tmp) 512 MB ได้ในขณะนี้

ใช่ หากโค้ดของคุณถือว่าสถานะไม่ซ้ำกัน คุณจำต้องประเมินความยืดหยุ่นของโค้ดของคุณเพื่อดำเนินการสแนปช็อต (เช่น การโคลนและการดำเนินการต่อ) เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับการพิจารณาความเป็นเอกลักษณ์ด้วย Lambda SnapStart ดูที่ เอกสารประกอบและบล็อกเกี่ยวกับการทำความเข้าใจเอกลักษณ์ใน VM สแนปช็อตด้วย Lambda SnapStart

ใช่ คุณสามารถใช้ซอฟต์แวร์ตรรกะก่อนการสร้าง (ตรวจสอบจุดตรวจสอบ) สแนปช็อตและหลังจากกู้คืนสแนปช็อตด้วยการใช้ฮุครันไทม์ เพื่อเรียนรู้เพิ่มเติม ดูที่เอกสารประกอบ Lambda SnapStart

ใช่ ระบบจะเรียกเก็บเงินคุณสำหรับการแคชสแนปช็อตในช่วงเวลาที่เวอร์ชันฟังก์ชันของคุณใช้งานอยู่ ซึ่งเป็นเวลาอย่างน้อย 3 ชั่วโมงและต่อมิลลิวินาทีหลังจากนั้น ราคาจะขึ้นอยู่กับจำนวนหน่วยความจำที่คุณใช้กับฟังก์ชันของคุณ นอกจากนี้ ระบบจะเรียกเก็บเงินคุณทุกครั้งที่ Lambda กลับมาดำเนินการในสภาพแวดล้อมการดำเนินการโดยการกู้คืนสแนปช็อตของคุณด้วยเช่นกัน โดยราคาขึ้นอยู่กับจำนวนหน่วยความจำที่คุณจัดสรรให้กับฟังก์ชันของคุณ หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการกำหนดราคา SnapStart โปรดไปที่การกำหนดราคา AWS Lambda

การกำหนดราคา SnapStart จะไม่นำไปใช้กับรันไทม์ที่ได้รับการจัดการโดย Java ที่รองรับ ซึ่งสามารถแคชสแนปชอตได้นานถึง 14 วันเท่านั้น

เช่นเดียวกับฟังก์ชัน Lambda ทั้งหมด จะมีการนำค่าบริการระยะเวลาไปใช้กับฟังก์ชัน SnapStart ด้วยเช่นกัน สำหรับฟังก์ชันที่ใช้ SnapStart ระยะเวลาจะรวมถึงเวลาที่ใช้ในการโหลดรันไทม์ รหัสใด ๆ ที่ทำงานในรันไทม์ของ Hook และรหัสการเตรียมใช้งานที่ดำเนินการเมื่อสร้างสำเนาสแนปช็อตเพื่อความยืดหยุ่น

Lambda SnapStart สำหรับ Python และ .NET ทำให้สแนปช็อตฟังก์ชันของคุณจะยังคงใช้งานอยู่ต่อไปตราบใดที่ฟังก์ชันของคุณยังคงทำงาน สำหรับฟังก์ชัน Java สแนปช็อตที่เชื่อมโยงกับฟังก์ชันที่เผยแพร่จะหมดอายุหากไม่มีการใช้งานนานกว่า 14 วัน

สแนปช็อตจะถูกเข้ารหัสเป็นค่าเริ่มต้นด้วย AWS Key Management Service (KMS) เฉพาะของลูกค้าที่เป็นเจ้าของและจัดการโดยบริการ Lambda ลูกค้ายังสามารถเข้ารหัสสแนปช็อตด้วยการใช้ คีย์ KMS ที่เป็นเจ้าของและจัดการโดยลูกค้า

ระยะเวลาการเริ่มต้นสูงสุดที่อนุญาตสำหรับ Lambda SnapStart จะตรงกับระยะเวลาหมดเวลาการดำเนินการที่คุณกำหนดไว้สำหรับฟังก์ชันของคุณ ขีดจำกัดการหมดเวลาการดำเนินการที่กำหนดค่าได้สูงสุดสำหรับฟังก์ชันคือ 15 นาที

กระบวนการทำงานพร้อมกันที่มีการเตรียมใช้งานช่วยให้คุณสามารถควบคุมประสิทธิภาพการทำงานของแอปพลิเคชันแบบไร้เซิร์ฟเวอร์ได้ดียิ่งขึ้น เมื่อเปิดใช้งานแล้ว กระบวนการทำงานพร้อมกันที่มีการเตรียมใช้งานจะเริ่มต้นฟังก์ชันต่างๆ และพร้อมตอบสนองภายในเวลามิลลิวินาทีสองหลัก

คุณสามารถกำหนดค่ากระบวนการทำงานพร้อมกันในฟังก์ชันของคุณได้ผ่าน AWS Management Console, Lambda API, AWS CLI และ AWS CloudFormation วิธีที่ง่ายที่สุดที่จะได้รับประโยชน์จากกระบวนการทำงานพร้อมกันที่มีการเตรียมใช้งานนั้นคือการใช้งาน AWS Auto Scaling คุณสามารถใช้ Auto Scaling ของแอปพลิเคชันเพื่อกำหนดค่าตารางเวลา หรือให้ Auto Scaling ปรับระดับกระบวนการทำงานพร้อมกันที่มีการเตรียมใช้งานโดยอัตโนมัติแบบเรียลไทม์เมื่อความต้องการเปลี่ยนแปลง หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับกระบวนการทำงานพร้อมกันที่มีการเตรียมใช้งาน โปรดดูที่เอกสารประกอบ

คุณไม่จำเป็นต้องทำการเปลี่ยนแปลงใดๆ กับโค้ดของคุณเพื่อใช้กระบวนการทำงานพร้อมกันที่มีการเตรียมใช้งาน เพราะกระบวนการนี้สามารถทำงานได้อย่างกลมกลืนกับฟังก์ชันและรันไทม์ที่มีอยู่ทั้งหมด ไม่มีการเปลี่ยนแปลงรูปแบบคำขอร้องและการดำเนินการของ Lambda เมื่อใช้กระบวนการทำงานพร้อมกันที่มีการเตรียมใช้งาน

กระบวนการทำงานพร้อมกันที่มีการเตรียมใช้งานจะเพิ่มขอบเขตราคาของ ‘กระบวนการทำงานพร้อมกันที่มีการเตรียมใช้งาน’ เพื่อให้ฟังก์ชันเริ่มต้นทำงานต่อไป เมื่อเปิดใช้งานแล้ว คุณจะชำระเงินตามจำนวนกระบวนการทำงานพร้อมกันที่คุณกำหนดค่าและตามรอบระยะเวลาที่คุณกำหนดค่า เมื่อฟังก์ชันของคุณได้ดำเนินการในขณะที่มีการกำหนดค่ากระบวนการทำงานพร้อมกันที่มีการเตรียมใช้งาน คุณยังต้องชำระเงินตามคำขอและระยะเวลาดำเนินการ หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับราคาของกระบวนการทำงานพร้อมกันที่มีการเตรียมใช้งาน โปรดดูที่ ค่าบริการ AWS Lambda

กระบวนการทำงานพร้อมกันที่มีการเตรียมใช้งานนั้นเหมาะสำหรับการสร้างแอปพลิเคชันที่มีการตอบสนองอย่างรวดเร็ว เช่น แบ็กเอนด์เว็บหรือมือถือ, API ที่เรียกใช้แบบซิงโครนัส และไมโครเซอร์วิสเชิงโต้ตอบ คุณสามารถกำหนดค่าจำนวนกระบวนการทำงานพร้อมกันที่เหมาะสมตามความต้องการเฉพาะของแอปพลิเคชันได้อย่างง่ายดาย คุณสามารถเพิ่มจำนวนกระบวนการทำงานพร้อมกันในช่วงเวลาที่มีความต้องการสูงและลดลงได้ หรือปิดใช้งานอย่างสมบูรณ์เมื่อมีความต้องการน้อยลง

หากกระบวนการทำงานพร้อมกันของฟังก์ชันมีระดับตามที่กำหนดไว้ คำขอร้องฟังก์ชันที่ตามมาจะมีลักษณะเวลาแฝงและขนาดเหมือนฟังก์ชัน Lambda ปกติ คุณสามารถจำกัดฟังก์ชันของคุณให้ขยายได้ถึงระดับที่กำหนดไว้เท่านั้นได้ วิธีนี้จะช่วยป้องกันไม่ให้ฟังก์ชันสูงเกินระดับที่กำหนดของกระบวนการทำงานพร้อมกันที่มีการเตรียมใช้งาน ซึ่งเป็นกลไกในการป้องกันความแปรปรวนที่ไม่พึงประสงค์ในแอปพลิเคชันของคุณ เมื่อความต้องการสูงเกินจำนวนที่คาดการณ์ไว้

AWS Lambda ช่วยให้คุณสามารถเรียกใช้ฟังก์ชันบนตัวประมวลผลแบบ x86 หรือแบบ Arm ได้ ตัวประมวลผล AWS Graviton2 เป็นตัวประมวลผลที่สร้างขึ้นเฉพาะโดย Amazon Web Services ด้วยการใช้แกนประมวลผล Arm Neoverse แบบ 64 บิต เพื่อเพิ่มประสิทธิภาพด้านราคาสำหรับปริมาณงานบนระบบคลาวด์ของคุณ ลูกค้าจะได้รับข้อดีต่างๆ เช่นเดียวกันกับ AWS Lambda, การเรียกใช้โค้ดโดยไม่ต้องจัดเตรียมหรือจัดการเซิร์ฟเวอร์, การปรับขนาดอัตโนมัติ, ความพร้อมใช้งานสูง และการจ่ายเฉพาะทรัพยากรที่คุณใช้เท่านั้น

ฟังก์ชัน AWS Lambda ที่ขับเคลื่อนด้วย Graviton2 โดยใช้สถาปัตยกรรมตัวประมวลผลแบบ Arm ที่ออกแบบโดย AWS ได้รับการออกแบบมาเพื่อมอบประสิทธิภาพด้านราคาที่ดีขึ้นสูงสุดถึง 34% เมื่อเทียบกับฟังก์ชันที่ทำงานบนหน่วยประมวลผลแบบ x86 สำหรับปริมาณงานแบบไร้เซิร์ฟเวอร์ที่หลากหลาย เช่น การประมวลผลแบ็คเอนด์ของเว็บและมือถือ ข้อมูล และสตรีม โดยฟังก์ชัน Graviton2 สามารถขับเคลื่อนแอปพลิเคชันแบบไร้เซิร์ฟเวอร์ที่สำคัญต่อภารกิจได้ด้วยเวลาแฝงที่ต่ำกว่า, ประสิทธิภาพที่ดีขึ้นสูงสุด 19%, ค่าใช้จ่ายที่ต่ำลง 20% และประสิทธิภาพพลังงานสูงสุดที่ AWS มีให้บริการในปัจจุบัน ลูกค้าสามารถกำหนดค่าทั้งฟังก์ชันที่มีอยู่และฟังก์ชันใหม่เพื่อกำหนดเป้าหมายตัวประมวลผล Graviton2 ได้ โดยลูกค้าสามารถปรับใช้ฟังก์ชันที่ทำงานบน Graviton2 เป็นไฟล์ zip หรืออิมเมจคอนเทนเนอร์ได้

คุณสามารถกำหนดค่าฟังก์ชันให้ทำงานบน Graviton2 ผ่าน AWS Management Console, AWS Lambda API, AWS CLI และ AWS CloudFormation ได้โดยการตั้งค่าสถานะสถาปัตยกรรมเป็น 'arm64' สำหรับฟังก์ชันของคุณ

ไม่มีการเปลี่ยนแปลงระหว่างฟังก์ชันที่ใช้ x86 และ Arm เพียงอัปโหลดโค้ดของคุณผ่าน AWS Management Console, ไฟล์ zip หรืออิมเมจคอนเทนเนอร์ แล้ว AWS Lambda จะเรียกใช้โค้ดของคุณโดยอัตโนมัติเมื่อทริกเกอร์ โดยที่คุณไม่ต้องจัดเตรียมหรือจัดการโครงสร้างพื้นฐาน

แอปพลิเคชันสามารถมีฟังก์ชันที่ทำงานบนสถาปัตยกรรมทั้งสองได้ AWS Lambda ช่วยให้คุณสามารถเปลี่ยนสถาปัตยกรรม ('x86_64' หรือ 'arm64') ของฟังก์ชันในเวอร์ชันปัจจุบันได้ เมื่อคุณสร้างเวอร์ชันเฉพาะของฟังก์ชันแล้ว จะไม่สามารถเปลี่ยนแปลงสถาปัตยกรรมได้

ภาษาที่ตีความแล้ว เช่น Python, Java และ Node โดยทั่วไปไม่ต้องดำเนินการคอมไพล์ซ้ำ เว้นแต่โค้ดของคุณจะอ้างอิงถึงไลบรารีที่ใช้ส่วนประกอบเฉพาะของสถาปัตยกรรม ในกรณีดังกล่าว คุณจะต้องจัดเตรียมไลบรารีที่กำหนดเป้าหมายไปยัง arm64 สำหรับรายละเอียดเพิ่มเติม โปรดดูหน้าการเริ่มต้นใช้งาน AWS Graviton ภาษาที่ไม่ได้ตีความแล้วจะต้องคอมไพล์โค้ดของคุณเพื่อกำหนดเป้าหมาย arm64 แม้ว่าคอมไพเลอร์ที่ทันสมัยกว่าจะสร้างโค้ดที่คอมไพล์แล้วสำหรับ arm64 แต่คุณจะต้องปรับใช้โค้ดดังกล่าวในสภาพแวดล้อมแบบ Arm เพื่อทดสอบ หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการใช้ฟังก์ชัน Lambda ด้วย Graviton2 โปรดดูเอกสารประกอบ

ไม่ แต่ละเวอร์ชันของฟังก์ชันสามารถใช้อิมเมจคอนเทนเนอร์ได้เพียงรายการเดียวเท่านั้น

ได้ โดยสามารถกำหนดเป้าหมายเลเยอร์และส่วนขยายไปยังสถาปัตยกรรมที่เข้ากันได้กับ 'x86_64' หรือ 'arm64' สถาปัตยกรรมเริ่มต้นสำหรับฟังก์ชันและเลเยอร์คือ 'x86_64'

เมื่อเปิดตัว ลูกค้าสามารถใช้อิมเมจ Python, Node.js, Java, Ruby, .Net Core, Custom Runtime (provided.al2) และ OCI Base ได้ หากต้องการเรียนรู้เพิ่มเติม โปรดดูที่ AWS Lambda Runtimes

ฟังก์ชัน AWS Lambda ที่ขับเคลื่อนด้วยตัวประมวลผล AWS Graviton2 มีราคาถูกกว่า 20% เมื่อเทียบกับฟังก์ชัน Lambda ที่ใช้ x86 Free Tier ของ Lambda ใช้กับฟังก์ชัน AWS Lambda ที่ขับเคลื่อนด้วยสถาปัตยกรรมแบบ x86 และ Arm

แต่ละปริมาณงานมีความแตกต่างกัน และเราขอแนะนำให้ลูกค้าทดสอบฟังก์ชันของตนเพื่อระบุการปรับปรุงประสิทธิภาพด้านราคาที่พวกเขาอาจได้รับ หากต้องการดำเนินการเช่นนั้น เราขอแนะนำให้ใช้เครื่องมือ AWS Lambda Power Tuning เราขอแนะนำให้เริ่มต้นด้วยการประมวลผลแบ็คเอนด์ของเว็บและมือถือ ข้อมูล และสตรีมเมื่อทดสอบปริมาณงานของคุณเพื่อปรับปรุงประสิทธิภาพด้านราคาที่อาจเกิดขึ้น

ด้วย Amazon Elastic File System (Amazon EFS) สำหรับ AWS Lambda ลูกค้าสามารถอ่าน เขียน และเก็บรักษาข้อมูลจำนวนมากได้อย่างปลอดภัยในทุกขนาดอย่างแท้จริงโดยใช้ระบบไฟล์ NFS แบบยืดหยุ่นที่มีการจัดการอย่างเต็มรูปแบบซึ่งสามารถปรับขนาดได้ตามความต้องการโดยไม่จำเป็นต้องมีการจัดเตรียมหรือการจัดการความจุ ก่อนหน้านี้นักพัฒนาได้เพิ่มโค้ดลงในฟังก์ชั่นของตนเพื่อดาวน์โหลดข้อมูลจาก S3 หรือฐานข้อมูลไปยังพื้นที่จัดเก็บชั่วคราวในเครื่องซึ่งจำกัดอยู่ที่ 512MB ด้วย EFS สำหรับ Lambda นักพัฒนาไม่จำเป็นต้องเขียนโค้ดเพื่อดาวน์โหลดข้อมูลไปยังพื้นที่จัดเก็บชั่วคราวเพื่อประมวลผลข้อมูลนั้น

นักพัฒนาสามารถเชื่อมต่อระบบไฟล์ EFS ที่มีอยู่เข้ากับฟังก์ชัน Lambda ได้ง่าย ๆ ผ่านทาง EFS Access Point โดยใช้ Console, CLI หรือ SDK เมื่อเรียกใช้งานฟังก์ชันครั้งแรก ระบบไฟล์จะติดตั้งโดยอัตโนมัติและพร้อมใช้งานกับโค้ดฟังก์ชัน คุณสามารถเรียนรู้เพิ่มเติมได้ในเอกสารประกอบ

ได้ เป้าหมายติดตั้งสำหรับ Amazon EFS จะเชื่อมโยงกับซับเน็ตใน VPC ต้องกำหนดค่าฟังก์ชัน AWS Lambda เพื่อเข้าถึง VPC นั้น

การใช้ EFS สำหรับ Lambda เหมาะสำหรับการสร้างแอปพลิแมชชีนเลิร์นนิง หรือโหลดไฟล์หรือโมเดลอ้างอิงขนาดใหญ่ การประมวลผลหรือสำรองข้อมูลจำนวนมาก การโฮสต์เนื้อหาเว็บ หรือหรือพัฒนาระบบสร้างภายในเครื่อง นอกจากนี้ลูกค้ายังสามารถใช้ EFS สำหรับ Lambda เพื่อรักษาสถานะระหว่างการเรียกภายในสถาปัตยกรรมไมโครเซอร์วิสแบบมีสถานะ ในเวิร์กโฟลว์ StepFunctions หรือการแชร์ไฟล์ระหว่างแอปพลิเคชันแบบไร้เซิร์ฟเวอร์กับอินสแตนซ์หรือแอปพลิเคชันที่ใช้คอนเทนเนอร์

ได้ การเข้ารหัสข้อมูลระหว่างการส่งจะใช้ Transport Layer Security (TLS) 1.2 ระดับมาตรฐานอุตสาหกรรมเพื่อเข้ารหัสข้อมูลที่ส่งระหว่างฟังก์ชัน AWS Lambda กับระบบไฟล์ Amazon EFS

ลูกค้าสามารถจัดเตรียม Amazon EFS ให้เข้ารหัสข้อมูลในระหว่างการพักเก็บ ข้อมูลที่จัดเก็บซึ่งเข้ารหัสไว้จะมีการเข้ารหัสอย่างโปร่งใสขณะเขียนข้อมูล และมีการถอดรหัสอย่างโปร่งใสขณะอ่านข้อมูล คุณจึงไม่จำเป็นต้องแก้ไขแอปพลิเคชันของคุณ AWS Key Management Service (KMS) จะเป็นตัวจัดการคีย์การเข้ารหัส ซึ่งทำให้ไม่จำเป็นต้องสร้างและบำรุงรักษาโครงสร้างการจัดการคีย์เพื่อความปลอดภัย

ไม่มีค่าบริการเพิ่มเติมในการใช้งาน Amazon EFS สำหรับ AWS Lambda ลูกค้าชำระค่าบริการตามราคามาตรฐานสำหรับ AWS Lambda และสำหรับ Amazon EFS เมื่อใช้ Lambda และ EFS ใน Availability Zone เดียวกัน ลูกค้าจะไม่ถูกเรียกเก็บค่าบริการสำหรับการถ่ายโอนข้อมูล อย่างไรก็ตาม หากลูกค้าใช้ VPC Peering เพื่อการเข้าถึงข้ามบัญชี ลูกค้าจะถูกเรียกเก็บค่าบริการการถ่ายโอนข้อมูล เพื่อเรียนรู้เพิ่มเติม โปรดดูที่ค่าบริการ

ไม่ได้ ฟังก์ชัน Lambda แต่ละฟังก์ชันจะสามารถเข้าถึงระบบไฟล์ EFS ได้ระบบเดียว

ได้ Amazon EFS รองรับฟังก์ชัน Lambda, ECS และคอนเทนเนอร์ Fargate และ EC2 instance คุณสามารถแชร์ระบบไฟล์เดียวกันและใช้นโยบาย IAM และ Access Point เพื่อควบคุมสิ่งที่แต่ละฟังก์ชัน คอนเทนเนอร์ หรืออินสแตนซ์สามารถเข้าถึงได้  

ใช่ คุณสามารถกำหนดค่าฟังก์ชัน Lambda ด้วย URL ของฟังก์ชัน ซึ่งเป็นตำแหน่งข้อมูล HTTPS ในตัวที่คุณเรียกใช้ได้โดยใช้เบราว์เซอร์, cURL และไคลเอ็นต์ HTTP URL ของฟังก์ชันช่วยให้เริ่มสร้างฟังก์ชันที่ HTTPS เข้าถึงได้อย่างง่ายดาย

คุณสามารถกำหนดค่า URL ของฟังก์ชันสำหรับฟังก์ชันของคุณได้ผ่าน AWS Management Console, AWS Lambda API, AWS CLI, AWS CloudFormation และ AWS Serverless Application Model โดยสามารถเปิดใช้ URL ของฟังก์ชันเป็นเวอร์ชัน $LATEST ที่ไม่มีเงื่อนไขของฟังก์ชันคุณ หรือในนามแฝงของฟังก์ชันใดๆ ก็ได้ ดูเอกสารประกอบเพื่อเรียนรู้เพิ่มเติมเกี่ยวกับการกำหนดค่า URL ของฟังก์ชัน

URL ของฟังก์ชัน Lambda ได้รับการรักษาความปลอดภัยด้วยสิทธิ์การอนุญาต IAM ตามค่าเริ่มต้น คุณสามารถเลือกที่จะปิดการให้สิทธิ์ IAM เพื่อสร้างตำแหน่งข้อมูลสาธารณะหรือหากคุณวางแผนที่ปรับใช้การให้สิทธิ์แบบกำหนดเองเป็นส่วนหนึ่งของตรรกะทางธุรกิจของฟังก์ชันได้

คุณสามารถเรียกใช้ฟังก์ชันของคุณได้ง่ายๆ จากเว็บเบราว์เซอร์โดยไปที่ URL ของ Lambda จากโค้ดของแอปพลิเคชันไคลเอ็นต์ของคุณที่ใช้ไลบรารี HTTP หรือจากบรรทัดคำสั่งที่ใช้ cURL

ใช่ คุณสามารถเปิดใช้ URL ของฟังก์ชัน Lambda เป็นฟังก์ชันหรือนามแฝงฟังก์ชันได้ หากไม่มีการระบุนามแฝง URL จะนำไปที่ $LATEST โดยค่าเริ่มต้น URL ของฟังก์ชันไม่สามารถกำหนดเป้าหมายเวอร์ชันของฟังก์ชันเฉพาะรายการได้

ปัจจุบัน URL ของฟังก์ชันยังไม่รองรับชื่อโดเมนแบบกำหนดเอง คุณสามารถใช้โดเมนแบบกำหนดเองกับ URL ของฟังก์ชันคุณได้โดยสร้างการกระจาย Amazon CloudFront และ CNAME เพื่อจับคู่โดเมนแบบกำหนดเองของคุณกับชื่อการกระจาย CloudFront จากนั้น จับคู่ชื่อโดเมนการกระจาย CloudFront ของคุณ เพื่อกำหนดเส้นทางไปยัง URL ของฟังก์ชันคุณเป็นจุดเริ่มต้น

ได้ สามารถใช้ URL ของฟังก์ชันเพื่อเรียกใช้ฟังก์ชัน Lambda ใน VPC ได้

ไม่มีค่าบริการเพิ่มเติมในการใช้งาน URL ของฟังก์ชัน คุณเพียงชำระเงินในราคามาตรฐานสำหรับการใช้ AWS Lambda ก็พอ หากต้องการเรียนรู้เพิ่มเติม โปรดดูค่าบริการ AWS Lambda

Lambda@Edge ช่วยให้คุณเรียกใช้โค้ดในตำแหน่งที่ตั้งของ AWS ทั่วโลกได้โดยไม่ต้องจัดเตรียมหรือจัดการเซิร์ฟเวอร์ เพื่อตอบสนองต่อผู้ใช้ตำแหน่งข้อมูลด้วยเวลาแฝงของเครือข่ายที่ต่ำที่สุด เพียงคุณอัปโหลดโค้ด Node.js หรือ Python ไปยัง AWS Lambda และกำหนดค่าฟังก์ชันของคุณให้สามารถเรียกใช้เพื่อตอบสนองต่อคำขอ Amazon CloudFront (เช่น เมื่อได้รับคำขอจากผู้ชม เมื่อส่งต่อหรือรับคำขอกลับมาจากต้นทาง และก่อนที่จะตอบสนองกลับไปยังผู้ใช้ตำแหน่งข้อมูล) จากนั้นโค้ดจะพร้อมดำเนินการในตำแหน่งที่ตั้งต่างๆ ของ AWS ทั่วโลกเมื่อได้รับคำขอเนื้อหา และจะปรับตามปริมาณคำขอ CloudFront ทั่วโลก เรียนรู้เพิ่มเติมได้ในเอกสารประกอบของเรา

เมื่อต้องการใช้ Lambda@Edge คุณเพียงอัปโหลดโค้ดของคุณไปที่ AWS Lambda และเชื่อมโยงเวอร์ชันฟังก์ชันที่จะเรียกใช้เพื่อตอบสนองคำขอ Amazon CloudFront โค้ดของคุณต้องเป็นไปตาม Service Limits ของ Lambda@Edge Lambda@Edge รองรับ Node.js และ Python สำหรับคำขอร้องทั่วโลกโดยเหตุการณ์ CloudFront ในขณะนี้ เรียนรู้เพิ่มเติมได้ในเอกสารประกอบของเรา

Lambda@Edge เหมาะสำหรับกรณีใช้งานที่ไวต่อเวลาแฝง ที่ซึ่งผู้ชมตำแหน่งข้อมูลของคุณกระจายตำแหน่งที่ตั้งไปทั่วโลก ข้อมูลทั้งหมดที่คุณต้องใช้ในการตัดสินใจมีอยู่ใน CloudFront ที่ Edge ภายในฟังก์ชันและคำขอ นั่นหมายความว่า ตอนนี้กรณีใช้งานที่คุณต้องตัดสินใจวิธีการให้บริการเนื้อหาตามลักษณะของผู้ใช้ (เช่น ตำแหน่งที่ตั้ง อุปกรณ์ไคลเอ็นต์ เป็นต้น) จะสามารถดำเนินการและให้บริการใกล้กับผู้ใช้ของคุณได้โดยไม่ต้องส่งกลับไปที่เซิร์ฟเวอร์ส่วนกลาง

คุณสามารถเชื่อมโยงฟังก์ชัน Lambda ที่มีอยู่กับเหตุการณ์ CloudFront สำหรับคำขอร้องทั่วโลกหากฟังก์ชันตอบสนองข้อกำหนดและข้อจำกัดด้านบริการ Lambda@Edge อ่านเพิ่มเติมเกี่ยวกับการอัปเดตคุณสมบัติการทำงานของคุณได้ที่นี่

ฟังก์ชันของคุณจะเรียกใช้งานโดยอัตโนมัติเพื่อตอบสนองเหตุการณ์ของ Amazon CloudFront ต่อไปนี้

• คำขอจากผู้ชม - เหตุการณ์นี้จะเกิดขึ้นเมื่อผู้ใช้ตำแหน่งข้อมูลหรืออุปกรณ์บนอินเทอร์เน็ตส่งคำขอ HTTP(S) ไปยัง CloudFront และคำขอดังกล่าวไปถึง Edge Location ที่อยู่ใกล้ผู้ใช้รายนั้นมากที่สุด
• การตอบสนองจากผู้ชม - เหตุการณ์นี้จะเกิดขึ้นเมื่อเซิร์ฟเวอร์ CloudFront ที่ Edge พร้อมที่จะตอบสนองต่อผู้ใช้ตำแหน่งข้อมูลหรืออุปกรณ์ที่ส่งคำขอ
• คำขอจากต้นทาง - เหตุการณ์นี้จะเกิดขึ้นเมื่อเซิร์ฟเวอร์ CloudFront ที่ Edge ไม่มีอ็อบเจกต์ที่ขออยู่ในแคช และคำขอจากผู้ชมก็พร้อมที่จะส่งไปยังเว็บเซิร์ฟเวอร์แบ็คเอนด์ต้นทางของคุณ (เช่น Amazon EC2 หรือ Application Load Balancer หรือ Amazon S3)
• การตอบสนองจากต้นทาง - เหตุการณ์นี้จะเกิดขึ้นเมื่อเซิร์ฟเวอร์ CloudFront ที่ Edge ได้รับการตอบสนองจากเว็บเซิร์ฟเวอร์แบ็คเอนด์ต้นทางของคุณ

ความแตกต่างคือ API Gateway และ Lambda เป็นบริการระดับภูมิภาค การใช้ Lambda@Edge และ Amazon CloudFront ช่วยให้คุณสามารถประมวลผลลอจิกได้ใน AWS หลายตำแหน่งตามจุดที่ผู้ชมตำแหน่งข้อมูลของคุณอยู่

AWS Lambda ได้รับการออกแบบมาเพื่อใช้การจำลองแบบและความซ้ำซ้อนเพื่อให้มีความพร้อมใช้งานสูงสำหรับทั้งบริการและฟังก์ชัน Lambda ที่ดำเนินการ ไม่มีกรอบการบำรุงรักษาหรือการหยุดทำงานที่กำหนดไว้สำหรับทั้งสองระบบ

ใช่ เมื่อคุณอัปเดตฟังก์ชัน Lambda จะมีช่วงเวลาสั้นๆ ซึ่งโดยทั่วไปจะน้อยกว่าหนึ่งนาทีเมื่อคำขอสามารถทำงานได้โดยใช้ทั้งฟังก์ชันเวอร์ชันเก่าหรือใหม่

ไม่ AWS Lambda ได้รับการออกแบบมาเพื่อเรียกใช้อินสแตนซ์ฟังก์ชันของคุณหลายรายการพร้อมกัน อย่างไรก็ตาม AWS Lambda มีขีดจำกัดความปลอดภัยเริ่มต้นสำหรับจำนวนการดำเนินการที่เกิดขึ้นพร้อมกันต่อบัญชีต่อ Region (โปรดดูข้อมูลเกี่ยวกับขีดจำกัดความปลอดภัยเริ่มต้นที่นี่) นอกจากนี้ คุณยังสามารถควบคุมการดำเนินการที่เกิดขึ้นพร้อมกันสูงสุดสำหรับฟังก์ชัน AWS Lambda แต่ละรายการได้ ซึ่งคุณสามารถใช้เพื่อสำรองชุดย่อยของขีดจำกัดในกระบวนการทำงานพร้อมกันของบัญชีสำหรับฟังก์ชันที่สำคัญ หรือกำหนดอัตราการรับส่งข้อมูลให้กับทรัพยากรดาวน์สตรีม

หากคุณต้องการส่งคําขอเพื่อเพิ่มขีดจํากัดการดําเนินการพร้อมกันคุณสามารถใช้โควตาบริการเพื่อขอเพิ่มขีดจํากัด

เมื่อเกินขีดจำกัดการดำเนินการพร้อมกันสูงสุด ฟังก์ชัน AWS Lambda ที่ถูกเรียกดำเนินการแบบซิงโครนัสจะส่งคืนข้อผิดพลาดเกี่ยวกับการควบคุมปริมาณ (รหัสข้อผิดพลาด 429) ฟังก์ชัน Lambda ที่ถูกเรียกใช้แบบอะซิงโครนัสสามารถดูดซับการรับส่งข้อมูลที่เหมาะสมได้ประมาณ 15-30 นาทีหลังจากที่เหตุการณ์ขาเข้าจะถูกปฏิเสธเนื่องจากมีการควบคุม ในกรณีที่ฟังก์ชัน Lambda ถูกเรียกใช้เพื่อตอบสนองต่อเหตุการณ์ Amazon S3 กิจกรรมที่ AWS Lambda ปฏิเสธอาจถูกเก็บรักษาและเรียกซ้ำโดย S3 เป็นเวลา 24 ชั่วโมง เหตุการณ์จาก Amazon Kinesis Streams และ Amazon DynamoDB Streams จะถูกเรียกซ้ำจนกว่าฟังก์ชัน Lambda จะสำเร็จหรือข้อมูลหมดอายุ Amazon Kinesis Streams และ Amazon DynamoDB Streams จะเก็บข้อมูลเป็นเวลา 24 ชั่วโมง

ขีดจํากัดการดําเนินการพร้อมกันสูงสุดเริ่มต้นมีการใช้ที่ระดับบัญชี อย่างไรก็ตาม คุณยังสามารถกําหนดขีดจํากัดสำหรับแต่ละฟังก์ชันได้เช่นกัน (เยี่ยมชมที่นี่เพื่อดูข้อมูลเกี่ยวกับ Reserved Concurrency)

ฟังก์ชัน Lambda ที่เรียกดำเนินการพร้อมกันแต่ละฟังก์ชันสามารถปรับขนาดได้ในอัตราการดําเนินการพร้อมกันสูงสุด 1,000 รายการทุกๆ 10 วินาที แม้ว่าอัตราการปรับขนาดของ Lambda จะเหมาะสําหรับกรณีการใช้งานส่วนใหญ่ แต่จะเหมาะอย่างยิ่งสําหรับผู้ที่มีปริมาณการใช้งานที่คาดการณ์ได้หรือคาดเดาไม่ได้ ตัวอย่างเช่น การประมวลผลข้อมูลที่ผูกกับ SLA จะต้องมีการปรับขนาดที่คาดการณ์ได้แต่รวดเร็วเพื่อตอบสนองความต้องการในการประมวลผล ในทํานองเดียวกัน การให้บริการบทความข่าวด่วน หรือการแฟลชเซลอาจเพิ่มระดับการเข้าชมที่คาดเดาไม่ได้ในช่วงเวลาสั้นๆ อัตราการปรับขนาดของ Lambda สามารถอํานวยความสะดวกให้กับกรณีการใช้งานดังกล่าวได้โดยไม่ต้องกําหนดค่าหรือเครื่องมือเพิ่มเติม นอกจากนี้ ขีดจํากัดการปรับขนาดพร้อมกันยังเป็นขีดจํากัดระดับฟังก์ชัน ซึ่งหมายความว่าแต่ละฟังก์ชันในบัญชีของคุณจะปรับขนาดโดยไม่ขึ้นกับฟังก์ชันอื่นๆ

เมื่อเกิดข้อผิดพลาด ฟังก์ชัน Lambda ที่เรียกใช้พร้อมกันจะตอบสนองโดยมีข้อยกเว้น ฟังก์ชัน Lambda ที่ถูกเรียกใช้แบบอะซิงโครนัสจะถูกเรียกใหม่อย่างน้อย 3 ครั้ง เหตุการณ์จาก Amazon Kinesis Streams และ Amazon DynamoDB Streams จะถูกเรียกซ้ำจนกว่าฟังก์ชัน Lambda จะสำเร็จหรือข้อมูลหมดอายุ สตรีม Kinesis และ DynamoDB จะเก็บข้อมูลไว้อย่างน้อย 24 ชั่วโมง

คุณสามารถกำหนดค่าคิว Amazon SQS หรือหัวข้อ Amazon SNS เป็นคิวที่ทำไม่สำเร็จได้

เมื่อเกินนโยบายการลองใหม่สำหรับการเรียกแบบอะซิงโครนัส คุณสามารถกำหนดค่า "คิวที่ทำไม่สำเร็จ" (DLQ) ที่จะวางเหตุการณ์ ในกรณีที่ไม่มี DLQ ที่กำหนดเหตุการณ์อาจถูกปฏิเสธ เมื่อเกินนโยบายการลองใหม่สำหรับการเรียกดำเนินการตามสตรีม ข้อมูลจะหมดอายุและถูกปฏิเสธในที่สุด

คุณให้สิทธิ์แก่ฟังก์ชัน Lambda ของคุณเพื่อเข้าถึงทรัพยากรอื่นๆ โดยใช้ IAM Role AWS Lambda รับบทบาทในขณะที่ดำเนินการฟังก์ชัน Lambda ของคุณ เพื่อให้คุณสามารถควบคุมทรัพยากร AWS ที่จะใช้งานได้อย่างเต็มที่และปลอดภัย โปรดไปที่การตั้งค่า AWS Lambda เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับบทบาท

เมื่อคุณกำหนดค่าบัคเก็ต Amazon S3 เพื่อส่งข้อความไปยังฟังก์ชัน AWS Lambda กฎนโยบายทรัพยากรจะถูกสร้างขึ้นเพื่อให้สิทธิ์การเข้าถึง โปรดไปที่คู่มือนักพัฒนา Lambda เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับนโยบายทรัพยากรและการควบคุมการเข้าถึงสำหรับฟังก์ชัน Lambda

การควบคุมการเข้าถึงจะได้รับการจัดการผ่านบทบาทของฟังก์ชัน Lambda บทบาทที่คุณกำหนดให้กับฟังก์ชัน Lambda ของคุณจะกำหนดว่า AWS Lambda สามารถสำรวจทรัพยากรใดได้เองบ้าง โปรดไปที่คู่มือนักพัฒนา Lambda เพื่อเรียนรู้เพิ่มเติม

การควบคุมการเข้าถึงสามารถจัดการได้โดยบทบาทฟังก์ชัน Lambda หรือการตั้งค่านโยบายทรัพยากรในคิวเอง หากมีทั้งสองนโยบาย สิทธิ์ที่มีข้อจำกัดเข้มงวดที่สุดจากทั้งสองสิทธิ์จะมีผลบังคับใช้

คุณสามารถเปิดใช้งานฟังก์ชัน Lambda เพื่อเข้าถึงทรัพยากรใน VPC ของคุณได้โดยการระบุซับเน็ตและกลุ่มมาตรการรักษาความปลอดภัยให้เป็นส่วนหนึ่งในการกำหนดค่าฟังก์ชันของคุณ ฟังก์ชัน Lambda ที่กำหนดค่าให้เข้าถึงทรัพยากรใน VPC โดยเฉพาะจะไม่สามารถเข้าถึงอินเทอร์เน็ตได้เป็นค่าเริ่มต้น หากต้องการให้อินเทอร์เน็ตแก่ฟังก์ชันเหล่านี้ ให้ใช้อินเทอร์เน็ตเกตเวย์. ตามค่าเริ่มต้น ฟังก์ชัน Lambda จะสื่อสารกับทรัพยากรใน VPC แบบสแต็กคู่ผ่าน IPv4 คุณสามารถกำหนดค่าฟังก์ชันของคุณให้เข้าถึงทรัพยากรใน VPC แบบสแต็กคู่ผ่าน IPv6 ได้ หากต้องการรายละเอียดเพิ่มเติมเกี่ยวกับฟังก์ชัน Lambda ที่กำหนดค่าด้วย VPC โปรดดูที่การสร้างเครือข่ายส่วนตัว Lambda ด้วย VPC

การลงชื่อโค้ดสำหรับ AWS Lambda มอบการควบคุมความน่าเชื่อถือและความถูกต้องสมบูรณ์ ซึ่งช่วยให้คุณตรวจสอบยืนยันได้ว่ามีเฉพาะโค้ดที่ไม่ได้ปรับเปลี่ยนจากผู้พัฒนาที่ได้รับอนุมัติเท่านั้นที่จะปรับใช้ในฟังก์ชัน Lambda ของคุณ คุณสามารถใช้ AWS Signer ซึ่งเป็นบริการรับรองโค้ดที่มีการจัดการเต็มรูปแบบเพื่อลงชื่ออาร์ทิแฟกต์โค้ดแบบดิจิทัลและกำหนดค่าฟังก์ชัน Lambda ของคุณให้ตรวจสอบยืนยันลายเซ็นเมื่อมีการปรับใช้ ขณะนี้การลงชื่อโค้ดสำหรับ AWS Lambda มีให้บริการสำหรับฟังก์ชันที่รวมแพ็กเกจเป็นการเก็บถาวร ZIP เท่านั้น

คุณสามารถสร้างอาร์ทิแฟกต์โค้ดที่มีการลงชื่อแบบดิจิทัลได้โดยใช้โพรไฟล์การลงชื่อผ่านทาง AWS Signer Console, Signer API, SAM CLI หรือ AWS CLI หากต้องการเรียนรู้เพิ่มเติม โปรดดูที่เอกสารประกอบสำหรับ AWS Signer

คุณสามารถเปิดใช้การลงชื่อโค้ดโดยสร้างการกำหนดค่าการลงชื่อโค้ดผ่านทาง AWS Management Console, Lambda API, AWS CLI, AWS CloudFormation และ AWS SAM การกำหนดค่าการลงชื่อโค้ดช่วยคุณระบุโพรไฟล์การลงชื่อที่ได้รับอนุมัติและกำหนดว่าต้องการเตือนหรือปฏิเสธการติดตั้งใช้จริงหากตรวจสอบลายเซ็นไม่สำเร็จหรือไม่ สามารถแนบใช้การกำหนดค่าการลงชื่อโค้ดกับแต่ละฟังก์ชันของ Lambda ได้เพื่อเปิดใช้คุณสมบัติการลงชื่อโค้ด จากนั้นฟังก์ชันดังกล่าวก็จะเริ่มตรวจสอบยืนยันลายเซ็นเมื่อมีการติดตั้งใช้จริง

AWS Lambda จะดำเนินการตรวจสอบลายเซ็นดังต่อไปนี้เมื่อมีการปรับใช้

• ลายเซ็นไม่สมบูรณ์ - เกิดขึ้นในกรณีที่ตัวโค้ดถูกดัดแปลงตั้งแต่เมื่อลงชื่อ
• ลายเซ็นไม่ตรง - เกิดขึ้นในกรณีที่ตัวโค้ดถูกเซ็นโดยใช้โพรไฟล์การลงชื่อที่ไม่ได้รับการอนุมัติ
• ลายเซ็นหมดอายุ - เกิดขึ้นในกรณีที่ลายเซ็นผ่านพ้นวันที่หมดอายุที่กำหนดไว้แล้ว
• ลายเซ็นถูกเพิกถอน - เกิดขึ้นในกรณีที่เจ้าของโพรไฟล์การลงชื่อเพิกถอนงานการลงชื่อ

หากต้องการเรียนรู้เพิ่มเติม โปรดดูที่เอกสารประกอบสำหรับ AWS Lambda

ได้ คุณสามารถเปิดใช้การลงชื่อโค้ดสำหรับฟังก์ชันที่มีอยู่ได้โดยแนบติดกากรำหนดค่าการลงชื่อโค้ดเข้ากับฟังก์ชัน สามารถทำได้โดยใช้แผงควบคุมของ AWS Lambda, Lambda API, AWS CLI, AWS CloudFormation และ AWS SAM

ไม่มีค่าใช้จ่ายเพิ่มเติมเมื่อใช้การลงชื่อโค้ดสำหรับ AWS Lambda คุณเพียงชำระเงินในราคามาตรฐานสำหรับการใช้ AWS Lambda ก็พอ เพื่อเรียนรู้เพิ่มเติม โปรดดูที่ค่าบริการ

เพื่อให้คุณได้ประสบการณ์การบันทึกที่ง่ายดายและเพิ่มประสิทธิภาพตั้งแต่เริ่มใช้ AWS Lambda นำเสนอการควบคุมการบันทึกขั้นสูง เช่น ความสามารถในการบันทึกข้อมูลบันทึกรูปแบบในโครงสร้าง JSON แบบเนทีฟ ควบคุมการกรองระดับข้อมูลบันทึกของข้อมูลบันทึกฟังก์ชัน Lambda โดยไม่ต้องทําการเปลี่ยนแปลงโค้ดใดๆ และปรับแต่งกลุ่มข้อมูลบันทึกของ Amazon CloudWatch ที่ Lambda ส่งบันทึกไป

คุณสามารถบันทึกข้อมูลบันทึกฟังก์ชัน Lambda รูปแบบในโครงสร้าง JSON โดยไม่ต้องใช้ไลบรารีการบันทึกของคุณเอง ข้อมูลบันทึกในโครงสร้าง JSON ช่วยให้ค้นหา กรอง และวิเคราะห์รายการข้อมูลบันทึกจํานวนมากได้ง่ายยิ่งขึ้น คุณสามารถควบคุมการกรองระดับข้อมูลบันทึกของข้อมูลบันทึกฟังก์ชัน Lambda ได้โดยไม่ต้องทําการเปลี่ยนแปลงโค้ดใดๆ ซึ่งช่วยให้คุณสามารถเลือกระดับความละเอียดในการบันทึกที่จําเป็นสําหรับฟังก์ชัน Lambda ได้ โดยไม่ต้องค้นในข้อมูลบันทึกจํานวนมากเมื่อแก้จุดบกพร่องและแก้ไขข้อผิดพลาด คุณยังสามารถตั้งค่าว่าจะส่งข้อมูลบันทึกไปยังกลุ่มข้อมูลบันทึก Amazon CloudWatch ของ Lambda ใด ทําให้ง่ายต่อการรวมข้อมูลบันทึกจากหลายฟังก์ชันภายในแอปพลิเคชันได้ในที่เดียว จากนั้นคุณสามารถใช้นโยบายความปลอดภัย การกํากับดูแล และการเก็บรักษากับข้อมูลบันทึกที่ระดับแอปพลิเคชัน แทนที่จะใช้แยกทีละรายการกับทุกฟังก์ชัน

คุณสามารถระบุการควบคุมการบันทึกขั้นสูงสําหรับฟังก์ชัน Lambda ของคุณได้โดยใช้ API ของ AWS Lambda API, คอนโซล AWS Lambda, CLI ของ AWS, AWS Serverless Application Model (SAM) และ AWS CloudFormation หากต้องการเรียนรู้เพิ่มเติม เยี่ยมชมเปิดบล็อกโพสต์เพื่อดูการควบคุมการบันทึกข้อมูลขั้นสูงหรือคู่มือนักพัฒนา Lambda

ได้ คุณสามารถใช้ไลบรารีข้อมูลบันทึกของคุณเองเพื่อสร้างข้อมูลบันทึก Lambda ในรูปแบบโครงสร้าง JSON ได้ เพื่อให้แน่ใจว่าไลบรารีข้อมูลบันทึกของคุณทํางานได้อย่างราบรื่นด้วยความสามารถเนทีฟในการบันทึกในโครงสร้าง JSON ของ Lambda นั้น Lambda จะไม่เข้ารหัสสองครั้งกับข้อมูลบันทึกใดๆ ที่สร้างโดยฟังก์ชันของคุณที่เข้ารหัส JSON อยู่แล้ว คุณยังสามารถใช้ไลบรารี Powertools สำหรับ AWS Lambda เพื่อบันทึกข้อมูลบันทึก Lambda ในรูปแบบโครงสร้าง JSON ได้อีกด้วย

ไม่มีค่าใช้จ่ายเพิ่มเติมในการใช้การควบคุมการบันทึกขั้นสูงบน Lambda คุณจะถูกเรียกเก็บค่าบริการสําหรับการนําเข้าและเก็บข้อมูลบันทึก Lambda ของคุณโดย Amazon CloudWatch Logs ต่อไป ดูหน้าค่าบริการของ CloudWatch สําหรับรายละเอียดค่าบริการข้อมูลบันทึก

สัญญาณแอปพลิเคชัน CloudWatch เป็นโซลูชัน Application Performance Monitoring (APM) ซึ่งช่วยให้นักพัฒนาและผู้ปฏิบัติงานสามารถตรวจติดตามสถานะและประสิทธิภาพของแอปพลิเคชันแบบไม่ต้องใช้เซิร์ฟเวอร์ที่สร้างขึ้นด้วย Lambda ได้อย่างง่ายดาย สัญญาณแอปพลิเคชันมีแดชบอร์ดมาตรฐานที่สร้างไว้ล่วงหน้าสำหรับตัววัดแอปพลิเคชันที่สำคัญ รายการติดตามที่สัมพันธ์กัน และการโต้ตอบระหว่างฟังก์ชัน Lambda และการพึ่งพาของฟังก์ชันโดยไม่ต้องใช้เครื่องมือด้วยตนเองหรือการเปลี่ยนแปลงโค้ดจากนักพัฒนา

คุณสามารถเปิดใช้งานสัญญาณแอปพลิเคชันสำหรับฟังก์ชันของคุณด้วยการคลิกครั้งเดียวในส่วน “เครื่องมือการตรวจติดตามและการปฏิบัติการ” ภายใต้แท็บการกำหนดค่าในคอนโซล Lambda หลังจากเปิดใช้งานสัญญาณแอปพลิเคชันแล้ว คุณสามารถดูแดชบอร์ดที่สร้างไว้ล่วงหน้า แผนที่บริการ และอื่น ๆ รวมถึงวิเคราะห์ประสิทธิภาพและสถานะของแอปพลิเคชันแบบไม่ต้องใช้เซิร์ฟเวอร์ของคุณในคอนโซล CloudWatch ได้ หากต้องการเรียนรู้เพิ่มเติม โปรดไปที่คู่มือนักพัฒนา Lambda และ คู่มือนักพัฒนาสัญญาณแอปพลิเคชัน ไปที่หน้าราคา CloudWatch เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับวิธีที่คุณถูกเรียกเก็บค่าบริการสำหรับการใช้สัญญาณแอปพลิเคชันกับฟังก์ชัน Lambda ของคุณ

CloudWatch Logs Live Tail เป็นความสามารถในการวิเคราะห์และการสตรีมข้อมูลบันทึกเชิงโต้ตอบ ช่วยให้คุณสามารถดูข้อมูลบันทึกได้แบบเรียลไทม์ ซึ่งช่วยให้พัฒนาและแก้ไขปัญหาของฟังก์ชัน Lambda ได้ง่ายขึ้น ดังนั้น จึงทำให้นักพัฒนาทดสอบและตรวจสอบการเปลี่ยนแปลงโค้ดหรือการกำหนดค่าแบบเรียลไทม์ได้รวดเร็ว ซึ่งช่วยให้การเขียน ทดสอบ และนำไปปรับใช้ (เรียกอีกอย่างว่า “inner dev loop”) ดำเนินไปอย่างรวดเร็วยิ่งขึ้นเมื่อสร้างแอปพลิเคชันด้วย Lambda นอกจากนี้ ประสบการณ์การใช้งาน Live Tail ยังช่วยให้ทีมผู้ปฏิบัติงานและทีม DevOps ตรวจจับและแก้ไขความล้มเหลวหรือข้อผิดพลาดที่สำคัญในโค้ดฟังก์ชัน Lambda อย่างมีประสิทธิภาพมากขึ้น พร้อมช่วยลดเวลาเฉลี่ยในการกู้คืน (MTTR) เมื่อทำการแก้ไขข้อผิดพลาดของฟังก์ชัน Lambda

หากต้องการใช้ Live Tail สำหรับฟังก์ชัน Lambda ของคุณ โปรดไปที่คอนโซล Lambda และคลิกปุ่ม “เปิด CloudWatch Live Tail” ในตัวแก้ไขโค้ด สำหรับข้อมูลเพิ่มเติม โปรดไปที่คู่มือนักพัฒนา Lambda ไปที่หน้าราคา CloudWatch เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับวิธีที่คุณถูกเรียกเก็บค่าบริการสำหรับการใช้ Live Tail กับฟังก์ชัน Lambda ของคุณ

คุณสามารถใช้เครื่องมือมาตรฐานเช่น Maven หรือ Gradle เพื่อคอมไพล์ฟังก์ชัน Lambda ของคุณ กระบวนการสร้างของคุณควรเลียนแบบกระบวนการสร้างเดียวกันที่คุณจะใช้เพื่อคอมไพล์โค้ด Java ที่ขึ้นอยู่กับ AWS SDK เรียกใช้เครื่องมือคอมไพล์ Java ในไฟล์ต้นฉบับของคุณและรวม AWS SDK 1.9 หรือเวอร์ชันที่ใหม่กว่าด้วยการอ้างอิงแบบขนานในเส้นทางเดินระบบของคุณ สำหรับรายละเอียดเพิ่มเติม โปรดดูเอกสารประกอบของเรา

Lambda มาพร้อมบิลด์ Amazon Linux ของ openjdk 1.8

ใช่ คุณสามารถใช้แพคเกจ NPM และแพคเกจที่กำหนดเองได้ เรียนรู้เพิ่มเติมที่นี่

ใช่ โปรแกรมทดสอบใน Lambda ช่วยให้คุณสามารถเรียกใช้ชุด ("เชลล์") สคริปต์ รันไทม์ภาษาอื่นๆ ชุดคำสั่งยูทิลิตี และไฟล์ปฏิบัติการ เรียนรู้เพิ่มเติมที่นี่

ใช่ โมดูลเนทีฟที่เชื่อมโยงแบบคงที่สามารถรวมอยู่ในไฟล์ ZIP ที่คุณอัปโหลด รวมทั้งโมดูลที่เชื่อมโยงแบบไดนามิกที่คอมไพล์ด้วย rpath ที่ชี้ไปยังไดเรกทอรีรากของ Lambda เรียนรู้เพิ่มเติมที่นี่

ใช่ คุณสามารถใช้คำสั่ง child_process ของ Node.js เพื่อดำเนินการไบนารีที่คุณรวมไว้ในฟังก์ชันหรือไฟล์ปฏิบัติการใดๆ จาก Amazon Linux ที่สามารถมองเห็นได้จากฟังก์ชันของคุณ หรืออีกหลายแพ็กเกจ NPM ที่มีอยู่ที่ตัดไบนารีบรรทัดคำสั่ง เช่น node-ffmpeg เรียนรู้เพิ่มเติมที่นี่

หากต้องการใช้ฟังก์ชัน Lambda ที่เขียนขึ้นใน Node.js เพียงแค่คุณใส่โค้ด Javascript และไลบรารีที่อ้างอิงเป็นไฟล์ ZIP คุณสามารถอัปโหลดไฟล์ ZIP จากสภาพแวดล้อมท้องถิ่นของคุณหรือระบุตำแหน่งที่ตั้ง Amazon S3 ที่มีไฟล์ ZIP อยู่ สำหรับรายละเอียดเพิ่มเติม โปรดดูเอกสารประกอบของเรา

ใช่ คุณสามารถใช้ pip เพื่อติดตั้งแพคเกจ Python ที่จำเป็นได้

คุณสามารถสร้างฟังก์ชัน C# Lambda โดยใช้ Visual Studio IDE โดยเลือก "เผยแพร่ไปที่ AWS Lambda" ใน Solution Explorer หรือคุณสามารถเรียกใช้คำสั่ง "dotnet lambda publish" โดยตรงจาก dotnet CLI ที่มีการติดตั้ง [แพทช์เครื่องมือ # Lambda CLI] ซึ่งจะสร้าง ZIP ของซอร์สโค้ด C# ของคุณพร้อมกับการอ้างอิงทั้งหมดของ NuGet และการรวบรวม DLL ที่เผยแพร่ของคุณเอง และจะอัปโหลดไปยัง AWS Lambda โดยอัตโนมัติโดยใช้พารามิเตอร์รันไทม์ "dotnetcore1.0"

แพคเกจการปรับใช้งาน PowerShell Lambda เป็นไฟล์ ZIP ที่ประกอบด้วยสคริปต์ PowerShell, โมดูล PowerShell ที่จำเป็นสำหรับสคริปต์ PowerShell และการผนวกรวมที่จำเป็นต่อการโฮสต์ PowerShell Core จากนั้นใช้โมดูล AWSLambdaPSCore PowerShell ที่คุณสามารถติดตั้งได้จากPowerShell Gallery เพื่อสร้างแพคเกจการปรับใช้งาน PowerShell Lambda

อัปโหลดส่วนที่สามารถปฏิบัติได้ของ Go เป็นไฟล์ ZIP ผ่าน AWS CLI หรือคอนโซล Lambda แล้วเลือกรันไทม์ go1.x คุณสามารถใช้เครื่องมือที่มีมาตั้งแต่แรกของ Go เพื่อสร้างและทำแพคเกจโค้ดของคุณได้ด้วย Lambda สำหรับรายละเอียดเพิ่มเติม โปรดอ่านเอกสารประกอบ 

หากต้องการปรับใช้งานฟังก์ชัน Lambda ที่เขียนขึ้นใน Ruby ให้จัดแพคเกจโค้ดและ Ruby และ Gems เป็น ZIP คุณสามารถอัปโหลดไฟล์ ZIP จากสภาพแวดล้อมท้องถิ่นของคุณหรือระบุตำแหน่งที่ตั้ง Amazon S3 ที่มีไฟล์ ZIP อยู่

คุณสามารถดูรายการเวอร์ชันที่สนับสนุนได้ที่นี่

ไม่ได้ AWS Lambda มีระบบปฏิบัติการและรันไทม์ภาษาที่ได้รับการจัดการแบบเวอร์ชันเดียวสำหรับผู้ใช้บริการทั้งหมด คุณสามารถนำรันไทม์ภาษาของคุณมาใช้ใน Lambda ได้

AWS Lambda ถูกผสานรวมกับ AWS CloudTrail AWS CloudTrail สามารถบันทึกและส่งไฟล์บันทึกไปยังบัคเก็ต Amazon S3 ของคุณซึ่งอธิบายถึงการใช้ API ของบัญชีของคุณ

คุณสามารถใช้ฟังก์ชัน Amazon Step เพื่อประสานงานฟังก์ชัน Lambda หลายฟังก์ชัน คุณสามารถเรียกใช้ฟังก์ชัน Lambda หลายๆ แบบโดยส่งผ่านเอาต์พุตของหนึ่งฟังก์ชันไปยังอีกอันหรือแบบคู่ขนาน โปรดดูรายละเอียดเพิ่มเติมที่เอกสารประกอบ

รองรับ AWS Lambda รองรับชุดคำสั่ง Advanced Vector Extensions 2 (AVX2) หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับวิธีรวมโค้ดแอปพลิเคชันของคุณเพื่อกำหนดเป้าหมายชุดคำสั่งนี้เพื่อให้มีประสิทธิภาพยิ่งขึ้น โปรดดูที่เอกสารประกอบสำหรับนักพัฒนา AWS Lambda