คำถามที่พบบ่อยเกี่ยวกับ 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 Lambda SnapStart สำหรับ Java ให้ประสิทธิภาพการเริ่มต้นฟังก์ชันเร็วขึ้นสูงสุด 10 เท่า สำหรับฟังก์ชันตามความต้องการ ระยะการเริ่มต้น (ที่ AWS Lambda โหลดโค้ดของฟังก์ชันและเริ่มต้นการอ้างอิงภายนอก) เป็นผู้สนับสนุนรายใหญ่ที่สุดสำหรับเวลาแฝงในการเริ่มต้นและจะเกิดขึ้นในการใช้งานครั้งแรก ด้วย Lambda SnapStart Lambda จะเริ่มต้นโค้ดฟังก์ชันล่วงหน้าแบบครั้งเดียวเมื่อคุณเผยแพร่เวอร์ชันของฟังก์ชัน แทนที่จะเริ่มต้นเมื่อคุณใช้งานฟังก์ชันครั้งแรก จากนั้น Lambda จะถ่ายสแนปช็อตและแคชหน่วยความจำและสถานะของดิสก์ของสภาพแวดล้อมการดำเนินการในการเริ่มต้น เมื่อคุณใช้งานฟังก์ชัน—และเมื่อเพิ่มทรัพยากรขึ้น— Lambda จะคืนค่าฟังก์ชันจากภาพแคชสแนปช็อตแทนที่จะเริ่มต้นฟังก์ชันตั้งแต่แรก

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

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

Lambda SnapStart รองรับ Java 11 รันไทม์ เวอร์ชันในอนาคตของ Java จะได้รับการรองรับหลังจากมีการเปิดตัว สำหรับรันไทม์ที่ Lambda รองรับทั้งหมดดูได้ที่ เอกสารประกอบรันไทม์ Lambda

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

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

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

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

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

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

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

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

ด้วย Lambda SnapStart Lambda จะเก็บสแนปช็อตของสภาพแวดล้อมการดำเนินการสำหรับเวอร์ชันฟังก์ชันสามอันสุดท้ายที่เผยแพร่ ตราบใดที่เวอร์ชันที่เผยแพร่ยังคงถูกเรียกใช้ สแนปช็อตที่เชื่อมโยงกับเวอร์ชันที่เผยแพร่จะหมดอายุหากไม่มีการใช้งานนานกว่า 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 เป็นฟังก์ชันหรือนามแฝงฟังก์ชันได้