FAQ AWS Lambda

Kode yang Anda jalankan pada AWS Lambda diunggah sebagai “fungsi Lambda”. Setiap fungsi memiliki informasi konfigurasi yang terkait, seperti nama, deskripsi, titik masuk, dan persyaratan sumber daya. Kode tersebut harus ditulis dalam gaya “stateless”, yaitu harus diasumsikan tidak ada kesamaan dengan infrastruktur komputasi yang mendasarinya. Akses sistem berkas lokal, proses turunan, dan artefak yang serupa tidak boleh melampaui masa permintaan, dan tiap status persisten harus disimpan di Amazon S3, Amazon DynamoDB, Amazon EFS, atau layanan penyimpanan lain yang tersedia di Internet. Fungsi Lambda dapat mencakup pustaka yang sudah ada, bahkan yang asli.

Untuk meningkatkan kinerja, AWS Lambda dapat memilih untuk me-retain suatu instans dari fungsi Anda dan menggunakannya kembali untuk melayani permintaan berikutnya, daripada membuat salinan baru. Untuk mempelajari selengkapnya tentang bagaimana Lambda menggunakan kembali instans fungsi, kunjungi dokumentasi kami. Kode Anda seharusnya tidak mengasumsikan bahwa hal ini akan selalu terjadi.

Anda dapat mengonfigurasi setiap fungsi Lambda dengan penyimpanan sementara miliknya sendiri antara 512MB hingga 10.240MB, dalam kenaikan 1MB. Penyimpanan sementara tersedia di setiap direktori /tmp fungsi.

Setiap fungsi memiliki akses hingga 512MB penyimpanan tanpa tambahan biaya. Saat mengonfigurasi fungsi dengan lebih dari 512MB penyimpanan sementara, Anda akan dikenakan biaya berdasarkan jumlah penyimpanan yang Anda konfigurasi, dan seberapa panjang fungsi Anda berjalan, dihitung dalam kenaikan 1ms. Untuk perbandingan, di wilayah AS Timur (Ohio), harga penyimpanan sementara AWS Fargate adalah 0,000111 USD per GB-jam, atau 0,08 USD per GB-bulan. Harga volume penyimpanan gp3 Amazon EBS di AS Timur (Ohio) adalah 0,08 USD per GB-bulan. Harga penyimpanan sementara AWS Lambda adalah 0,0000000309 USD per GB-detik, atau 0,000111 USD per GB-jam dan 0,08 USD per GB-bulan. Untuk mempelajari selengkapnya, lihat Harga AWS Lambda.

Anda dapat mengonfigurasi setiap fungsi Lambda dengan penyimpanan sementara miliknya sendiri antara 512MB hingga 10.240MB, dalam kenaikan 1MB dengan menggunakan konsol AWS Lambda, API AWS Lambda, atau templat AWS CloudFormation selama pembuatan atau pembaruan fungsi.

Ya. Semua data yang tersimpan di penyimpanan sementara terenkripsi at rest dengan kunci yang dikelola oleh AWS.

Anda dapat menggunakan metrik Wawasan Lambda AWS CloudWatch untuk memantau penggunaan penyimpanan sementara Anda. Untuk mempelajari selengkapnya, lihat dokumentasi Wawasan Lambda AWS CloudWatch.

Jika aplikasi Anda membutuhkan penyimpanan tetap dan berdaya tahan, pertimbangkan untuk menggunakan Simple Storage Service (Amazon S3) atau Amazon EFS. Jika aplikasi Anda memerlukan penyimpanan data yang dibutuhkan oleh kode dalam pemanggilan fungsi tunggal, pertimbangkan untuk menggunakan penyimpanan sementara AWS Lambda sebagai cache sementara. Untuk mempelajari selengkapnya, lihat Pemilihan opsi penyimpanan data AWS Lambda di aplikasi web.

Ya. Namun, Jika aplikasi Anda membutuhkan penyimpanan tetap, pertimbangkan untuk menggunakan Amazon EFS atau Simple Storage Service (Amazon S3). Jika Konkurensi Terprovisi telah diaktifkan untuk fungsi Anda, kode inisialisasi fungsi Anda berjalan selama alokasi dan setiap beberapa jam, karena instans dari fungsi Anda yang berjalan digunakan kembali. Anda dapat melihat waktu inisialisasi di log dan pelacakan setelah instans memproses permintaan. Namun, inisialisasi tetap ditagih bahkan jika instans tidak pernah memproses permintaan. Perilaku inisialisasi Konkurensi Terprovisi ini dapat memengaruhi cara fungsi Anda berinteraksi dengan data yang Anda simpan di penyimpanan sementara, bahkan saat fungsi Anda tidak memproses permintaan. Untuk mempelajari selengkapnya tentang Konkurensi Terprovisi, harap lihat dokumentasi terkait.

Anda dapat mengonfigurasi setiap fungsi Lambda dengan penyimpanan sementara miliknya sendiri antara 512MB hingga 10.240MB, dalam kenaikan 1MB dengan menggunakan konsol AWS Lambda, API AWS Lambda, atau templat AWS CloudFormation selama pembuatan atau pembaruan fungsi.

Ya. Semua data yang tersimpan di penyimpanan sementara terenkripsi at rest dengan kunci yang dikelola oleh AWS.

Anda dapat menggunakan metrik Wawasan Lambda AWS CloudWatch untuk memantau penggunaan penyimpanan sementara Anda. Untuk mempelajari selengkapnya, lihat dokumentasi Wawasan Lambda AWS CloudWatch.

Menjaga fungsi stateless memungkinkan AWS Lambda meluncurkan dengan cepat sebanyak mungkin salinan fungsi sebagaimana diperlukan untuk menskalakan ke tingkat kejadian yang masuk. Meskipun model pemrograman AWS Lambda stateless, kode Anda dapat mengakses data stateful dengan memanggil layanan web lain, seperti Amazon S3 atau Amazon DynamoDB.

Ya. AWS Lambda memungkinkan Anda menggunakan fitur bahasa dan sistem pengoperasian yang normal, seperti membuat utas dan proses tambahan. Sumber daya yang dialokasikan untuk fungsi Lambda, termasuk memori, waktu eksekusi, disk, dan penggunaan jaringan, harus dibagi di antara semua utas/proses yang digunakannya. Anda dapat meluncurkan proses menggunakan bahasa yang didukung oleh Amazon Linux.

Lambda mencoba mengenakan pembatasan sesedikit mungkin pada aktivitas bahasa dan sistem pengoperasian yang normal, tetapi ada beberapa aktivitas yang dinonaktifkan: Koneksi jaringan masuk diblokir oleh AWS Lambda, dan untuk koneksi keluar hanya soket TCP/IP dan UDP/IP yang didukung, dan panggilan sistem ptrace (debugging) diblokir. Lalu lintas TCP port 25 juga diblokir sebagai langkah anti-spam.

Jika menggunakan Node.js atau Phyton, Anda dapat menulis kode untuk fungsi Anda dengan editor kode di konsol AWS Lambda yang memungkinkan untuk menulis dan menguji fungsi Anda, dan melihat hasil eksekusi fungsi dalam lingkungan yang kuat dan seperti IDE. Buka konsol untuk memulai.

Anda juga dapat mengemas kode (dan pustaka yang bergantung) sebagai ZIP dan mengunggahnya menggunakan konsol AWS Lambda dari lingkungan lokal atau menentukan lokasi Amazon S3 tempat file ZIP berada. Unggahan tidak boleh lebih dari 50 MB (terkompresi). Anda dapat menggunakan plugin AWS Eclipse untuk menulis dan menerapkan fungsi Lambda di Java. Anda dapat menggunakan plugin Visual Studio untuk menulis dan menerapkan fungsi Lambda di C#, dan Node.js.

Anda juga dapat mengemas kode (dan pustaka yang bergantung) sebagai ZIP dan mengunggahnya menggunakan AWS CLI dari lingkungan lokal, atau menentukan lokasi Amazon S3 tempat file ZIP berada. Unggahan tidak boleh lebih dari 50 MB (terkompresi). Kunjungi panduan Memulai Lambda untuk memulai.

Ya. Anda dapat dengan mudah membuat dan memodifikasi variabel lingkungan dari Konsol AWS Lambda, CLI, atau SDK. Untuk mempelajari selengkapnya tentang variabel lingkungan, lihat dokumentasi.

Untuk informasi sensitif, seperti kata sandi basis data, sebaiknya gunakan enkripsi di sisi klien menggunakan AWS Key Management Service dan simpan nilai yang dihasilkan sebagai teks sandi dalam variabel lingkungan Anda. Anda harus menyertakan logika dalam kode fungsi AWS Lambda Anda untuk mendekripsi nilai-nilai ini.

Anda dapat menyesuaikan dan mengamankan sumber daya yang terkait dengan fungsi Lambda Anda menggunakan API atau konsol Lambda. Untuk mempelajari selengkapnya mengenai hal itu, lihat dokumentasi.

Ya, Anda dapat mengemas kode apa pun (kerangka kerja, SDK, pustaka, dan lainnya) sebagai Lapisan Lambda dan mengelola serta membagikannya dengan mudah di berbagai fungsi.

AWS Lambda secara otomatis memantau fungsi Lambda untuk Anda, melaporkan metrik real-time melalui Amazon CloudWatch, termasuk total permintaan, penggunaan konkurensi tingkat akun dan tingkat fungsi, latensi, tingkat kesalahan, dan permintaan terbatas. Anda dapat melihat statistik untuk setiap fungsi Lambda melalui konsol Amazon CloudWatch atau melalui konsol AWS Lambda. Anda juga dapat memanggil API pemantauan pihak ketiga dalam fungsi Lambda Anda.
 

Kunjungi Memecahkan masalah metrik CloudWatch untuk mempelajari selengkapnya. Biaya standar untuk AWS Lambda berlaku untuk penggunaan metrik bawaan Lambda.

AWS Lambda secara otomatis terintegrasi dengan Amazon CloudWatch logs, membuat grup log untuk setiap fungsi Lambda, dan menyediakan entri log peristiwa siklus aktif aplikasi dasar, termasuk logging sumber daya yang dikonsumsi untuk setiap penggunaan fungsi itu. Anda dapat dengan mudah memasukkan pernyataan logging tambahan ke dalam kode Anda. Anda juga dapat memanggil API logging pihak ketiga dalam fungsi Lambda Anda. Kunjungi Memecahkan masalah fungsi Lambda untuk mempelajari selengkapnya. Tarif Amazon CloudWatch Logs akan berlaku.

Anda tidak harus menskalakan fungsi Lambda – AWS Lambda menskalakannya secara otomatis untuk Anda. Setiap kali pemberitahuan kejadian diterima untuk fungsi Anda, AWS Lambda dengan cepat menempatkan kapasitas gratis dalam armada komputasinya dan menjalankan kode Anda. Karena kode stateless, AWS Lambda dapat memulai sebanyak mungkin salinan dari fungsi Anda sesuai kebutuhan tanpa penundaan pemasangan dan konfigurasi yang lama. Tidak ada batasan fundamental untuk menskalakan sebuah fungsi. AWS Lambda akan secara dinamis mengalokasikan kapasitas untuk menyesuaikan laju kejadian yang akan datang.

Dalam model sumber daya AWS Lambda, Anda memilih jumlah memori yang diinginkan untuk fungsi Anda, serta dialokasikan daya CPU proporsional dan sumber daya lainnya. Misalnya, memilih memori 256 MB akan mengalokasikan kira-kira dua kali lipat daya CPU ke fungsi Lambda Anda seperti meminta memori 128 MB, dan setengah kali lipat daya CPU seperti memilih memori 512 MB. Untuk mempelajari lebih lanjut, lihat dokumentasi Konfigurasi Fungsi kami.

Anda dapat mengatur memori Anda dari 128 MB menjadi 10.240 MB.

Pelanggan yang menjalankan beban kerja intensif memori atau komputasi sekarang bisa menggunakan lebih banyak memori untuk fungsi mereka. Fungsi memori yang lebih besar membantu aplikasi multithread berjalan lebih cepat, menjadikannya ideal untuk data dan aplikasi intensif komputasi seperti machine learning, tugas batch dan ETL, pemodelan keuangan, genomik, HPC, dan pemrosesan media.

Fungsi AWS Lambda dapat dikonfigurasi agar berjalan hingga 15 menit per eksekusi. Anda dapat mengatur batas waktu ke nilai antara 1 hingga 15 menit.

AWS Lambda diberi harga berdasarkan bayar per penggunaan. Lihat halaman harga AWS Lambda untuk detailnya.

Ya. Selain menghemat uang di Amazon EC2 dan AWS Fargate, Anda juga dapat menggunakan Compute Savings Plans untuk menghemat uang di AWS Lambda. Compute Savings Plans menawarkan diskon hingga 17% pada Durasi, Provisioned Concurrency, dan Durasi (Provisioned Concurrency). Compute Savings Plans tidak menawarkan diskon pada Permintaan dalam tagihan Lambda Anda. Namun, komitmen Compute Savings Plans Anda dapat berlaku untuk Permintaan dengan tarif reguler.

Ya. Secara default, setiap fungsi AWS Lambda memiliki satu versi kode terkini. Klien fungsi Lambda Anda dapat memanggil versi tertentu atau mendapatkan implementasi terbaru. Baca dokumentasi kami tentang versioning fungsi Lambda.

Waktu deployment dapat bervariasi dengan ukuran kode Anda, tetapi fungsi AWS Lambda biasanya siap dipanggil dalam beberapa detik setelah pengunggahan.

Ya. Anda dapat menyertakan salinan pustaka Anda sendiri (termasuk AWS SDK) untuk menggunakan versi yang berbeda dari versi default yang disediakan oleh AWS Lambda.

AWS Lambda menawarkan tingkat harga diskon untuk durasi fungsi sesuai permintaan bulanan di atas batas tertentu. Harga bertingkat tersedia untuk fungsi yang berjalan di arsitektur x86 dan Arm. Tingkat harga Lambda diterapkan ke agregat durasi sesuai permintaan bulanan dari fungsi Anda yang berjalan pada arsitektur yang sama (masing-masing x86 atau Arm), di wilayah yang sama, di dalam akun. Jika Anda menggunakan penagihan gabungan di AWS Organizations, tingkat harga diterapkan ke durasi bulanan agregat dari fungsi Anda yang berjalan di arsitektur yang sama, di wilayah yang sama, di seluruh akun dalam organisasi. Misalnya, jika Anda menjalankan fungsi Lambda x86 di wilayah AS Timur (Ohio), Anda akan membayar 0,0000166667 USD untuk setiap GB-detik untuk 6 miliar GB-detik pertama per bulan, 0,0000150000 USD untuk setiap GB-detik untuk 9 miliar GB-detik berikutnya per bulan, dan 0,0000133334 USD untuk setiap GB-detik lebih dari 15 miliar GB-detik per bulan, di wilayah tersebut. Harga untuk Permintaan, Konkurensi yang Disediakan, dan Durasi Konkurensi yang Disediakan tetap tidak berubah. Untuk informasi selengkapnya, lihat Harga AWS Lambda

Ya. Penggunaan Lambda yang dicakup oleh komitmen Savings Plans per jam Anda ditagihkan dengan tarif dan diskon CSP yang berlaku. Penggunaan lainnya yang tidak dicakup oleh komitmen ini akan ditagihkan dengan tarif sesuai tingkat durasi fungsi agregat bulanan Anda.

Sumber kejadian adalah layanan AWS atau aplikasi buatan pengembang yang memproduksi kejadian yang memicu fungsi AWS Lambda untuk berjalan. Beberapa layanan memublikasikan kejadian ini ke Lambda dengan memanggil fungsi cloud secara langsung (misalnya, Amazon S3). Lambda juga dapat meminta sumber daya di layanan lain yang tidak memublikasikan kejadian ke Lambda. Misalnya, Lambda dapat menarik catatan dari aliran Amazon Kinesis atau antrean Amazon SQS dan mengeksekusi fungsi Lambda untuk setiap pesan yang diambil. Banyak layanan lain, seperti AWS CloudTrail, dapat bertindak sebagai sumber peristiwa hanya dengan masuk ke Amazon S3 dan menggunakan notifikasi bucket S3 untuk memicu fungsi AWS Lambda

Lihat dokumentasi kami untuk daftar lengkap sumber peristiwa.

Kejadian diteruskan ke fungsi Lambda sebagai parameter input kejadian. Untuk sumber kejadian di mana kejadian tiba dalam batch, seperti Amazon SQS, Amazon Kinesis, dan Amazon DynamoDB Streams, parameter kejadian dapat berisi beberapa peristiwa dalam satu panggilan, berdasarkan ukuran batch yang Anda minta. Untuk mempelajari selengkapnya tentang notifikasi peristiwa Amazon S3, kunjungi Mengonfigurasi Notifikasi untuk Peristiwa Amazon S3. Untuk mempelajari selengkapnya tentang Amazon DynamoDB Streams, kunjungi Panduan Developer DynamoDB Streams. Untuk mempelajari selengkapnya tentang memanggil fungsi Lambda menggunakan Amazon SNS, kunjungi Panduan Developer Amazon SNS. Untuk informasi selengkapnya tentang peristiwa Amazon Cognito, kunjungi Amazon Cognito. Untuk informasi selengkapnya tentang log AWS CloudTrail dan mengaudit panggilan API di seluruh layanan AWS, lihat AWS CloudTrail.

Dari konsol AWS Lambda, Anda dapat memilih fungsi dan mengasosiasikannya dengan pemberitahuan dari bucket Amazon S3. Cara lainnya, Anda dapat menggunakan konsol Amazon S3 dan mengonfigurasi pemberitahuan bucket untuk mengirim ke fungsi AWS Lambda Anda. Fungsi yang sama ini juga tersedia melalui AWS SDK dan CLI.

Anda dapat memicu fungsi Lambda pada pembaruan tabel DynamoDB dengan berlangganan fungsi Lambda Anda ke DynamoDB Stream yang terkait dengan tabel. Anda dapat menghubungkan DynamoDB Stream dengan fungsi Lambda menggunakan konsol Amazon DynamoDB, konsol AWS Lambda, atau API registerEventSource Lambda.

Dari konsol AWS Lambda, Anda dapat memilih fungsi Lambda dan menghubungkannya dengan aliran Amazon Kinesis yang dimiliki oleh akun yang sama. Fungsi yang sama ini juga tersedia melalui AWS SDK dan CLI.

Rekaman Amazon Kinesis dan Amazon DynamoDB Streams yang dikirimkan ke fungsi AWS Lambda Anda secara ketat diurutkan, per pecahan. Hal ini berarti bahwa jika Anda memasukkan dua rekaman dalam pecahan yang sama, Lambda menjamin bahwa fungsi Lambda Anda akan berhasil dipanggil dengan rekaman pertama sebelum dipanggil dengan rekaman kedua. Jika permintaan untuk satu kali rekaman habis, dibatasi, atau menemui kesalahan lainnya, Lambda akan mencoba lagi hingga berhasil (atau rekaman mencapai waktu kedaluwarsa 24 jam) sebelum bergerak ke rekaman berikutnya. Urutan rekaman di seluruh serpihan yang berbeda tidak dijamin, dan pemrosesan setiap serpihan terjadi secara paralel.

AWS Lambda memungkinkan Anda melakukan agregasi berbasis waktu (seperti penjumlahan, maks., jumlah, rata-rata, dll.) dalam jangka waktu singkat hingga 15 menit untuk data di Amazon Kinesis atau Amazon DynamoDB Streams, melalui partisi logis tunggal seperti serpihan. Fitur ini memberi Anda opsi menyiapkan analitik sederhana dengan mudah untuk aplikasi berbasis kejadian tanpa menambahkan kerumitan arsitektur, karena logika bisnis dan analitik Anda dapat ditempatkan dalam fungsi yang sama. Lambda memungkinkan agregasi melebihi 15 menit jendela tumbling maksimum berdasarkan tanda waktu kejadian. Amazon Kinesis Data Analytics memungkinkan Anda membangun aplikasi analitik yang lebih kompleks untuk mendukung pilihan pemrosesan yang fleksibel dan toleransi kesalahan yang tangguh dengan pemrosesan tepat satu kali tanpa duplikat, serta analitik yang dapat dilakukan di seluruh aliran data di beberapa partisi logis. Dengan KDA, Anda dapat menganalisis data melalui beberapa tipe jendela agregasi (jendela tumbling, jendela stagger, jendela geser, jendela sesi), baik menggunakan waktu kejadian maupun waktu pemrosesan.
 

	AWS Lambda	Amazon KDA
Jendela Tumbling	Ya	Ya
Jendela Stagger	Tidak	Ya
Jendela Geser	Tidak	Ya
Jendela Sesi	Tidak	Ya
Pengayaan	Tidak	Ya
Tabel input dan referensi gabungan	Tidak	Ya
Pisahkan aliran input	Tidak	Ya
Pemrosesan tepat satu kali	Tidak	Ya
Jendela waktu maksimum	15 menit	Tanpa batas
Cakupan agregasi	Partisi/shard	Aliran
Semantik waktu	Waktu kejadian	Waktu kejadian, Waktu pemrosesan

Dari konsol AWS Lambda, Anda dapat memilih fungsi Lambda dan menghubungkannya dengan topik Amazon SNS. Fungsi yang sama ini juga tersedia melalui AWS SDK dan CLI.

Dari Konsol Amazon SES, Anda dapat menyiapkan aturan penerimaan agar Amazon SES mengirimkan pesan Anda ke fungsi AWS Lambda. Fungsi yang sama tersedia melalui AWS SDK dan CLI.

Pertama, konfigurasi alarm untuk mengirim pemberitahuan Amazon SNS. Kemudian dari konsol AWS Lambda, pilih fungsi Lambda dan kaitkan dengan topik Amazon SNS. Lihat Panduan Developer Amazon CloudWatch untuk informasi selengkapnya tentang menyiapkan alarm Amazon CloudWatch.

Dari konsol AWS Lambda, Anda dapat memilih fungsi untuk dipicu ketika set data apa pun yang dikaitkan dengan kolam identitas Amazon Cognito disinkronkan. Fungsi yang sama ini juga tersedia melalui AWS SDK dan CLI. Kunjungi Amazon Cognito untuk mengetahui informasi lebih lanjut tentang menggunakan Amazon Cognito untuk berbagi dan menyinkronkan data di seluruh perangkat pengguna.

Anda dapat memanggil fungsi Lambda menggunakan kejadian khusus melalui API panggilan AWS Lambda. Hanya pemilik fungsi atau akun AWS lain yang pemiliknya memberikan izin yang dapat memanggil fungsi tersebut. Kunjungi Panduan Developer Lambda untuk mempelajari selengkapnya.

AWS Lambda didesain untuk memproses kejadian dalam satuan milidetik. Latensi akan menjadi lebih tinggi segera setelah fungsi Lambda dibuat, diperbarui, atau jika belum digunakan baru-baru ini.

Anda mengunggah kode yang diinginkan untuk dieksekusi oleh AWS Lambda kemudian memanggilnya dari aplikasi mobile Anda menggunakan AWS Lambda SDK yang disertakan dalam AWS Mobile SDK. Anda dapat membuat panggilan langsung (sinkronis) untuk mengambil atau memeriksa data secara waktu nyata maupun panggilan asinkronis. Anda juga dapat menentukan API khusus menggunakan Amazon API Gateway dan menjalankan fungsi Lambda Anda melalui klien yang kompatibel dengan REST. Untuk mempelajari selengkapnya tentang AWS Mobile SDK, kunjungi halaman AWS Mobile SDK. Untuk mempelajari selengkapnya tentang Amazon API Gateway, kunjungi halaman Amazon API Gateway.

Anda dapat memanggil fungsi Lambda melalui HTTPS dengan menentukan API RESTful khusus menggunakan Amazon API Gateway. Hal ini memberikan Anda titik akhir untuk fungsi yang dapat merespons ke panggilan REST seperti GET, PUT, dan POST. Baca selengkapnya tentang menggunakan AWS Lambda dengan Amazon API Gateway.

Ketika dipanggil melalui AWS Mobile SDK, fungsi AWS Lambda secara otomatis mendapatkan wawasan tentang perangkat dan aplikasi yang membuat panggilan melalui objek ‘konteks’.

Ketika aplikasi Anda menggunakan identitas Amazon Cognito, pengguna akhir dapat mengautentikasi dirinya menggunakan berbagai penyedia layanan login publik seperti Amazon, Facebook, Google, dan layanan lain yang kompatibel dengan OpenID Connect. Kemudian, identitas pengguna secara otomatis dan aman disajikan ke fungsi Lambda Anda dalam bentuk id Amazon Cognito, yang memungkinkannya mengakses data pengguna dari Amazon Cognito, atau sebagai kunci untuk menyimpan dan mengambil data di Amazon DynamoDB atau layanan web lainnya.

AWS Lambda terintegrasi dengan Alexa Skills Kit, kumpulan API mandiri, peralatan, dokumentasi dan contoh kode yang mempermudah Anda untuk membuat kemampuan suara (atau “keterampilan”) untuk Alexa. Anda cukup mengunggah kode fungsi Lambda untuk keterampilan Alexa baru yang Anda buat, dan AWS Lambda melakukan sisanya, mengeksekusi kode sebagai respons untuk interaksi suara Alexa dan secara otomatis mengelola sumber daya komputasi untuk Anda. Baca dokumentasi Alexa Skills Kit untuk detail selengkapnya.

Untuk pemberitahuan bucket Amazon S3 dan kejadian khusus, AWS Lambda akan mencoba menjalankan fungsi Anda tiga kali apabila terjadi kesalahan dalam kode atau jika Anda melebihi batas layanan atau sumber daya. Untuk sumber kejadian berurutan yang diminta AWS Lambda untuk Anda, seperti Amazon DynamoDB Streams dan Amazon Kinesis Streams, Lambda akan terus mencoba eksekusi dalam hal kesalahan kode pengembang sampai data berakhir. Anda dapat memantau kemajuan melalui Amazon Kinesis dan konsol Amazon DynamoDB, serta melalui metrik Amazon CloudWatch yang dihasilkan AWS Lambda untuk fungsi Anda. Anda juga dapat mengatur alarm Amazon CloudWatch berdasarkan tingkat kesalahan atau pembatasan eksekusi.

Aplikasi berbasis Lambda (disebut juga sebagai aplikasi tanpa server) terdiri dari fungsi yang dipicu oleh kejadian. Secara umum, aplikasi tanpa server terdiri dari satu atau beberapa fungsi yang dipicu oleh kejadian seperti unggahan objek ke Amazon S3, pemberitahuan Amazon SNS, atau tindakan API. Fungsi ini dapat berdiri sendiri atau memanfaatkan sumber daya lain seperti tabel DynamoDB atau bucket Amazon S3. Aplikasi tanpa server yang paling dasar adalah sebuah fungsi.

Anda dapat menerapkan dan mengelola aplikasi tanpa server menggunakan Model Aplikasi Tanpa Server AWS (AWS Serverless Application Model (AWS SAM)). AWS SAM adalah spesifikasi yang menentukan aturan untuk mengekspresikan aplikasi tanpa server di AWS. Spesifikasi ini sejajar dengan sintaks yang digunakan oleh AWS CloudFormation saat ini dan didukung secara asli dalam AWS CloudFormation sebagai satu set jenis sumber daya (disebut sebagai "sumber daya tanpa server"). Sumber daya ini memudahkan pelanggan AWS dalam menggunakan CloudFormation untuk mengonfigurasi dan menerapkan aplikasi nirserver, menggunakan API CloudFormation yang ada.

Anda dapat memilih dari kumpulan aplikasi nirserver yang dipublikasikan developer, perusahaan, dan partner di komunitas AWS dengan AWS Serverless Application Repository. Setelah menemukan aplikasi, Anda dapat mengonfigurasikan dan menerapkannya langsung dari konsol Lambda.

Anda dapat mengautomasikan proses rilis aplikasi nirserver menggunakan AWS CodePipeline dan AWS CodeDeploy. CodePipeline adalah layanan pengiriman berkelanjutan yang memungkinkan Anda memodelkan, memvisualisasikan, dan mengautomasikan langkah-langkah yang diperlukan untuk merilis aplikasi nirserver. CodeDeploy memberikan mesin automasi deployment untuk aplikasi berbasis Lambda Anda. CodeDeploy memungkinkan Anda mengorkestrasi penerapan sesuai dengan metodologi praktik terbaik yang sudah ada seperti penerapan canary dan linier, serta membantu Anda menetapkan pagar pembatas yang diperlukan untuk memverifikasi bahwa kode yang baru digunakan itu aman, stabil, dan siap dirilis sepenuhnya untuk produksi.
 

Untuk mempelajari selengkapnya tentang CI/CD nirserver, kunjungi dokumentasi kami.

Untuk memulai, kunjungi konsol AWS Lambda dan unduh salah satu cetak biru kami. File yang Anda unduh akan berisi file AWS SAM (yang menentukan sumber daya AWS di aplikasi) dan file .ZIP (yang termasuk kode fungsi Anda). Anda kemudian dapat menggunakan perintah AWS CloudFormation untuk mengemas dan menerapkan aplikasi tanpa server yang baru saja diunduh. Untuk detail selengkapnya, kunjungi dokumentasi kami.

Anda dapat menggunakan AWS Step Functions untuk mengoordinasikan rangkaian fungsi AWS Lambda dalam urutan tertentu. Anda dapat memanggil beberapa fungsi Lambda secara berurutan, meneruskan output satu ke yang lain, dan/atau secara paralel, dan Step Functions akan mempertahankan status selama eksekusi untuk Anda.

Anda dapat mengaktifkan fungsi Lambda untuk penelusuran menggunakan AWS X-Ray dengan menambahkan izin X-Ray ke peran eksekusi fungsi Lambda dan mengubah “mode penelusuran” fungsi Anda ke “aktif”. Ketika X-Ray diaktifkan untuk fungsi Lambda Anda, AWS Lambda akan memancarkan informasi penelusuran ke X-Ray mengenai biaya layanan Lambda yang timbul saat menjalankan fungsi Anda. Hal ini akan memberi Anda wawasan seperti biaya layanan Lambda, waktu inisiasi fungsi, dan waktu eksekusi fungsi. Selain itu, Anda dapat menyertakan SDK X-Ray dalam paket deployment Lambda. Dengan cara ini, Anda dapat membuat segmen jejak milik sendiri, membuat anotasi jejak, atau melihat segmen jejak untuk panggilan hilir yang dibuat dari fungsi Lambda Anda. SDK X-Ray saat ini tersedia untuk Node.js dan Java. Kunjungi Memecahkan masalah aplikasi berbasis Lambda untuk mempelajari selengkapnya. Tarif AWS X-Ray akan berlaku.

Ya. Anda dapat membangun aplikasi nirserver berbasis Lambda dengan skalabilitas tinggi dan aman yang terhubung ke basis data relasional menggunakan Proksi Amazon RDS, yaitu proksi basis data dengan ketersediaan tinggi yang mengelola ribuan koneksi bersamaan ke basis data relasional. Saat ini, RDS Proxy mendukung database MySQL dan Aurora. Anda dapat mulai menggunakan RDS Proxy melalui konsol Amazon RDS atau konsol AWS Lambda. Aplikasi nirserver yang menggunakan kolam koneksi terkelola penuh dari RDS Proxy akan ditagihkan sesuai dengan Harga RDS Proxy.

Spesifikasi ini bersumber terbuka di bawah Apache 2.0, yang memungkinkan Anda dan orang lain mengadopsi dan menggabungkan AWS SAM ke dalam alat pengembangan, deployment, pemantauan, dan pengelolaan dengan lisensi yang ramah komersial. Anda dapat mengakses repositori AWS SAM di GitHub di sini.

AWS Lambda saat ini memungkinkan Anda mengemas dan men-deploy fungsi sebagai gambar kontainer. Pelanggan dapat memanfaatkan fleksibilitas dan alat kontainer yang dikenal, serta agility dan kemudahan operasional AWS Lambda untuk membangun aplikasi.

Anda dapat memulai dengan gambar dasar yang disediakan AWS untuk Lambda atau menggunakan salah satu gambar komunitas atau perusahaan privat pilihan Anda. Kemudian, cukup gunakan Docker CLI untuk membuat gambar, unggah ke Amazon ECR, lalu buat fungsi menggunakan semua antarmuka dan alat Lambda yang sudah dikenal, seperti AWS Management Console, AWS CLI, AWS SDK, AWS SAM, dan AWS CloudFormation.

Anda dapat menerapkan gambar dasar Linux pihak ketiga (misalnya Alpine atau Debian) ke Lambda selain gambar yang disediakan Lambda. AWS Lambda akan mendukung semua gambar berdasarkan format manifes gambar berikut: Docker Image Manifest V2 Schema 2 (digunakan dengan Docker versi 1.10 dan yang lebih baru) atau Open Container Initiative (OCI) Spec (v1.0 dan yang lebih baru). Lambda mendukung gambar dengan ukuran hingga 10 GB.

AWS Lambda menyediakan berbagai gambar dasar yang dapat diperluas oleh pelanggan dan pelanggan juga dapat menggunakan gambar berbasis Linux yang disukai dengan ukuran hingga 10 GB.

Anda dapat menggunakan alat kontainer apa pun selama alat tersebut mendukung salah satu format manifes gambar kontainer berikut: Docker Image Manifest V2 Schema 2 (digunakan dengan Docker versi 1.10 dan yang lebih baru) atau Open Container Initiative (OCI) Specifications (v1.0 dan yang lebih baru). Misalnya, Anda dapat menggunakan alat kontainer asli (mis. docker run, docker compose, Buildah, and Packer) untuk menentukan fungsi sebagai gambar kontainer dan men-deploy ke Lambda.

Semua fitur AWS Lambda yang ada, kecuali lapis Lambda dan Penandatanganan Kode, dapat digunakan dengan fungsi yang di-deploy sebagai gambar kontainer. Setelah di-deploy, AWS Lambda akan memperlakukan gambar sebagai gambar yang tidak dapat diubah. Pelanggan dapat menggunakan lapis kontainer selama proses pembangunannya untuk menyertakan dependensi.

Tidak pada saat ini. Gambar Anda, setelah di-deploy ke AWS Lambda, tidak akan dapat diubah. Layanan ini tidak akan melakukan patch atau memperbarui gambar. Namun, AWS Lambda akan menerbitkan gambar dasar yang dikurasi untuk semua runtime yang didukung yang didasarkan pada lingkungan yang dikelola Lambda. Gambar yang dipublikasikan ini akan di-patch dan diperbarui bersama dengan pembaruan pada runtime yang dikelola AWS Lambda. Anda dapat menarik dan menggunakan gambar dasar terbaru dari DockerHub atau Amazon ECR Public, membangun ulang gambar kontainer Anda, dan men-deploy ke AWS Lambda melalui Amazon ECR. Layanan ini memungkinkan Anda membangun dan menguji gambar dan runtime yang diperbarui sebelum melakukan deployment gambar untuk diproduksi

Ada tiga perbedaan utama antara fungsi yang dibuat menggunakan arsip ZIP dengan gambar kontainer:

1. Fungsi yang dibuat menggunakan arsip ZIP memiliki ukuran paket kode maksimum sebesar 250 MB saat dibuka dari zip, dan fungsi yang dibuat menggunakan gambar kontainer memiliki ukuran gambar maksimum 10 GB. 
2. Lambda menggunakan Amazon ECR sebagai penyimpanan kode dasar untuk fungsi yang ditentukan sebagai gambar kontainer, agar fungsi tidak dapat digunakan ketika gambar dasar dihapus dari ECR. 
3. Fungsi ZIP secara otomatis di-patch untuk keamanan runtime dan perbaikan bug terbaru. Fungsi yang ditentukan sebagai gambar kontainer tidak dapat diubah dan pelanggan bertanggung jawab atas komponen yang dikemas dalam fungsinya. Pelanggan dapat memanfaatkan gambar dasar yang disediakan AWS yang diperbarui secara berkala oleh AWS untuk keamanan dan perbaikan bug, menggunakan patch terbaru yang tersedia.

Tidak - AWS Lambda memastikan profil performa untuk fungsi yang dikemas sebagai gambar kontainer sama dengan yang dikemas sebagai arsip ZIP, terutama waktu mulai sub-detik.

Tidak ada biaya tambahan untuk mengemas dan men-deploy fungsi sebagai gambar kontainer ke AWS Lambda. Saat memanggil fungsi yang di-deploy sebagai gambar kontainer, Anda membayar harga reguler untuk permintaan dan durasi eksekusi. Untuk mempelajari selengkapnya, kunjungi harga AWS Lambda. Anda akan dikenakan biaya atas penyimpanan gambar kontainer Anda di Amazon ECR dengan harga ECR standar. Untuk mempelajari selengkapnya, kunjungi harga Amazon ECR.

Emulator Antarmuka Runtime Lambda adalah proksi untuk API Runtime Lambda yang memungkinkan pelanggan menguji secara lokal fungsi Lambda yang dikemas sebagai gambar kontainer. Ini adalah server web ringan yang mengonversi permintaan HTTP menjadi kejadian JSON dan meniru API Runtime Lambda. Server ini memungkinkan Anda menguji fungsi secara lokal menggunakan alat yang sudah dikenal seperti cURL dan Docker CLI (saat menguji fungsi yang dikemas sebagai gambar kontainer). Server ini juga menyederhanakan perjalanan aplikasi Anda pada layanan komputasi tambahan. Anda dapat menyertakan Lambda Runtime Interface Emulator dalam gambar kontainer agar menerima permintaan HTTP secara asli, bukan kejadian JSON yang diperlukan untuk deployment ke Lambda. Komponen ini tidak meniru orkestrator Lambda atau konfigurasi keamanan dan autentikasi. Runtime Interface Emulator adalah sumber terbuka di GitHub. Anda dapat memulai dengan mengunduh dan menginstalnya di mesin lokal Anda.

API Runtime Lambda dalam layanan Lambda yang berjalan menerima kejadian JSON dan menampilkan respons. Lambda Runtime Interface Emulator memungkinkan fungsi yang dikemas sebagai gambar kontainer menerima permintaan HTTP selama pengujian lokal dengan alat seperti cURL, dan menampilkannya melalui antarmuka yang sama secara lokal ke fungsi tersebut. Ini memungkinkan Anda menggunakan perintah docker run atau docker-compose up untuk menguji aplikasi lambda Anda secara lokal.

Anda dapat menggunakan emulator untuk menguji apakah kode fungsi Anda kompatibel dengan lingkungan Lambda, berhasil dijalankan, dan memberikan keluaran yang diharapkan. Misalnya, Anda dapat meniru kejadian pengujian dari sumber kejadian lainnya. Anda juga dapat menggunakannya untuk menguji ekstensi dan agen yang dibangun ke dalam gambar kontainer terhadap API Ekstensi Lambda.

Pelanggan dapat menambahkan Runtime Interface Emulator sebagai titik entri ke gambar kontainer atau mengemasnya sebagai tambahan untuk memastikan gambar kontainer sekarang menerima permintaan HTTP, bukan kejadian JSON. Ini menyederhanakan perubahan yang diperlukan untuk menjalankan gambar kontainernya pada layanan komputasi tambahan. Pelanggan akan bertanggung jawab untuk memastikan mereka mengikuti semua praktik terbaik keamanan, performa, dan konkurensi untuk lingkungan pilihan mereka. RIE dikemas sebelumnya ke dalam gambar yang disediakan AWS Lambda, dan tersedia secara default di AWS SAM CLI. Penyedia gambar dasar dapat menggunakan dokumentasi untuk menyediakan pengalaman yang sama bagi gambar dasar mereka.

Anda dapat men-deploy aplikasi dalam kontainer ke AWS Lambda jika memenuhi persyaratan berikut:

1. Gambar kontainer harus mengimplementasikan API Runtime Lambda. Kami memiliki satu set paket perangkat lunak sumber terbuka, Runtime Interface Client (RIC), yang mengimplementasikan API Runtime Lambda, yang memungkinkan Anda memperluas gambar dasar pilihan Anda dengan mulus agar kompatibel dengan Lambda.
2. Gambar kontainer harus bisa berjalan pada sistem file hanya baca. Kode fungsi Anda dapat mengakses penyimpanan direktori /tmp yang dapat ditulis sebesar 512 MB. Jika Anda menggunakan gambar yang memerlukan direktori root yang dapat ditulis, konfigurasikan untuk menulis ke direktori /tmp.
3. File yang diperlukan untuk menjalankan kode fungsi dapat dibaca oleh pengguna Lambda default. Lambda menentukan pengguna Linux default dengan izin hak istimewa paling rendah yang mengikuti praktik terbaik keamanan. Anda perlu memverifikasi kode aplikasi Anda tidak tergantung pada file yang dibatasi oleh pengguna Linux lain agar dapat dijalankan.
4. Ini adalah gambar kontainer berbasis Linux.

AWS Lambda SnapStart for Java menghasilkan performa startup fungsi hingga 10x lebih cepat. Untuk fungsi sesuai permintaan, fase inisialisasi (saat AWS Lambda memuat kode fungsi dan memulai dependensi eksternal) adalah kontributor terbesar untuk latensi startup, dan terjadi pada panggilan pertama. Dengan Lambda SnapStart, Lambda memulai kode satu kali fungsi inisialisasi sebelumnya saat Anda memublikasikan versi fungsi, bukan saat Anda pertama kali memanggil fungsi. Kemudian, Lambda mengambil snapshot dan melakukan caching memori serta status disk lingkungan pelaksanaan yang diinisialisasi. Saat Anda memanggil fungsi—dan saat skalanya dinaikkan—Lambda tidak menginiasialisasi fungsi dari awal, tetapi melanjutkan fungsi dari snapshot dalam cache.

Lambda SnapStart merupakan sebuah konfigurasi tingkat fungsi sederhana yang dapat dikonfigurasikan untuk fungsi Java lama maupun baru dengan menggunakan API Lambda, Konsol Manajemen AWS, AWS Command Line Interface (CLI), AWS SDK, AWS Cloud Development Kit (CDK), AWS CloudFormation, dan AWS Serverless Application Model (SAM). Saat Anda mengonfigurasi Lambda SnapStart, setiap fungsi versi yang dipublikasikan kemudian mendapatkan manfaat dari peningkatan performa startup yang ditawarkan oleh Lambda SnapStart. Untuk mempelajari selengkapnya tentang Lambda SnapStart, lihat dokumentasi.

Lambda SnapStart adalah optimalisasi performa yang membantu fungsi Java Anda untuk mencapai waktu startup hingga 10x lebih cepat dengan mengurangi latensi variabel yang ditanggung selama pelaksanaan kode satu kali inisialisasi. Lambda SnapStart bekerja secara luas di semua fungsi dalam aplikasi atau akun Anda tanpa biaya tambahan. Saat pelanggan memublikasikan versi fungsi dengan Lambda SnapStart, kode fungsi diinisialisasi sebelumnya, bukan pada saat panggilan pertama. Lambda kemudian mengambil snapshot lingkungan pelaksanaan yang diinisialisasi serta mempertahankannya dalam cache bertingkat untuk akses latensi rendah. Saat fungsi pertama kali dipanggil lalu diskalakan, Lambda melanjutkan fungsi dari snapshot dalam cache, alih-alih menginisialisasi dari awal, yang mengakibatkan latensi startup lebih rendah. Meskipun mengurangi latensi startup, Lambda SnapStart berfungsi sebagai pengoptimalan upaya terbaik, dan tidak menjamin eliminasi cold start. Jika aplikasi Anda mempunyai persyaratan latensi yang ketat dan memerlukan waktu startup dua digit milidetik, kami sarankan Anda menggunakan PC.

Lambda SnapStart mendukung waktu proses Java 11. Versi Java mendatang akan didukung setelah dirilis. Untuk semua waktu proses yang didukung oleh Lambda, lihat dokumentasi waktu proses Lambda.

Tidak. Lambda SnapStart dan PC tidak dapat diaktifkan bersamaan, pada fungsi yang sama.

Ya. Anda dapat mengonfigurasikan fungsi Lambda SnapStart untuk mengakses sumber daya di cloud privat virtual (VPC). Untuk informasi selengkapnya mengenai cara mengonfigurasi fungsi dengan VPC, lihat dokumentasi Lambda.

Tidak. Saat ini, Anda dapat mengonfigurasikan Lambda SnapStart hanya untuk fungsi yang berjalan di arsitektur x86.

Tidak. Saat ini, Anda tidak dapat mengaktifkan Lambda SnapStart dengan Amazon EFS.

Tidak. Saat ini, Anda tidak dapat mengaktifkan Lambda SnapStart dengan penyimpanan sementara (/tmp) lebih besar yang melebihi 512 MB.

Ya. Jika kode Anda mengasumsikan keunikan status, Anda harus mengevaluasi ketahanan kode untuk operasi snapshot (seperti dikloning dan dilanjutkan). Untuk mempelajari selengkapnya mengenai pertimbangan keunikan Lambda SnapStart, lihat dokumentasi dan blog mengenai memahami keunikan dalam snapshot VM dengan Lambda SnapStart.

Ya. Anda dapat mengimplementasikan logika perangkat lunak Anda sendiri sebelum membuat (melakukan checkpoint) snapshot dan setelah memulihkan snapshot menggunakan kait waktu proses. Untuk mempelajari selengkapnya, lihat dokumentasi Lambda SnapStart.

Tidak. Tidak ada biaya tambahan untuk mengaktifkan Lambda SnapStart. Anda dikenai biaya berdasarkan jumlah permintaan untuk fungsi dan durasi eksekusi kode berdasarkan Harga Lambda terbaru. Biaya durasi berlaku untuk kode yang dijalankan di handler fungsi dan kait waktu proses, serta kode inisialisasi yang dinyatakan di luar handler. Perhatikan bahwa AWS Lambda mungkin mendaur ulang lingkungan pelaksanaan secara periodik dengan patch keamanan dan menjalankan ulang kode inisialisasi Anda. Untuk detail selengkapnya, lihat dokumentasi Model Pemrograman Lambda.

Dengan Lambda SnapStart, Lambda mempertahankan snapshot lingkungan pelaksanaan yang diinisialisasi untuk tiga versi fungsi yang terakhir dipublikasikan, selama versi yang dipublikasikan terus menerima panggilan. Snapshot yang terkait dengan versi fungsi yang dipublikasikan akan kedaluwarsa jika tetap tidak aktif selama lebih dari 14 hari.

Snapshot dienkripsi secara default dengan kunci AWS Key Management Service (KMS) yang unik untuk tiap pelanggan, yang dimiliki dan dikelola oleh layanan Lambda. Pelanggan juga dapat mengenskripsi snapshot menggunakan kunci KMS yang dimiliki dan dikelola oleh pelanggan.

Durasi inisialisasi yang diizinkan untuk Lambda SnapStart akan sama dengan durasi timeout pelaksanaan yang telah Anda konfigurasikan untuk fungsi Anda. Batas maksimum timeout pelaksanaan yang dapat dikonfigurasikan untuk sebuah fungsi adalah 15 menit.

Provisioned Concurrency memberi Anda kontrol lebih besar pada kinerja aplikasi tanpa server Anda. Jika diaktifkan, Provisioned Concurrency menjaga fungsi selalu dimulai dan sangat siap untuk merespons dalam milidetik dua digit.

Anda dapat mengonfigurasi konkurensi pada fungsi Anda melalui AWS Management Console, Lambda API, AWS CLI, dan AWS CloudFormation. Cara termudah mendapatkan manfaat dari Provisioned Concurrency adalah dengan menggunakan AWS Auto Scaling. Anda dapat menggunakan Application Auto Scaling untuk mengonfigurasi jadwal, atau meminta Auto Scaling untuk menyesuaikan level Provisioned Concurrency secara otomatis dalam real time sebagai perubahan permintaan. Untuk mempelajari selengkapnya tentang Konkurensi yang Tersedia, lihat dokumentasi.

Anda tidak perlu melakukan perubahan apa pun pada kode Anda untuk menggunakan Provisioned Concurrency. Provisioned Concurrency berfungsi lancar dengan semua fungsi dan waktu proses yang ada. Tidak ada perubahan pada model pemanggilan dan eksekusi Lambda saat menggunakan Provisioned Concurrency.

Provisioned Concurrency menambahkan pricing dimension, dari ‘Provisioned Concurrency’, agar fungsi selalu diinisialisasi. Bila diaktifkan, Anda membayar untuk jumlah konkurensi yang Anda konfigurasi dan untuk periode waktu selama Anda mengonfigurasinya. Ketika fungsi Anda dijalankan selagi Provisioned Concurrency dikonfigurasi di dalamnya, Anda juga membayar Permintaan dan Durasi eksekusi. Untuk mempelajari harga Konkurensi yang Tersedia selengkapnya, lihat Harga AWS Lambda.

Provisioned Concurrency cocok untuk membuat aplikasi yang sensitif terhadap latensi, seperti web atau backend mobile, API yang dijalankan secara sinkron, dan microservice interaktif. Anda dapat dengan mudah mengonfigurasi jumlah konkurensi yang sesuai berdasarkan permintaan unik aplikasi Anda. Anda dapat meningkatkan jumlah konkurensi saat permintaan meningkat dan menurunkannya, atau mematikan sepenuhnya, saat permintaan menurun.

Jika konkurensi suatu fungsi mencapai level yang telah dikonfigurasi, pemanggilan fungsi berikutnya akan memiliki karakteristik latensi dan skala fungsi Lambda reguler. Anda dapat membatasi fungsi Anda ke hanya menaikkan skala ke level terkonfigurasi. Jika dilakukan maka akan mecegah fungsi agar tidak melebihi level Provisioned Concurrency yang telah dikonfigurasi. Ini adalah mekanisme untuk mencegah variabilitas yang tidak diinginkan di aplikasi Anda saat permintaan melebihi jumlah yang diantisipasi.

AWS Lambda memungkinkan Anda menjalankan fungsi pada prosesor berbasis x86 atau berbasis Arm. Prosesor AWS Graviton2 dibuat khusus oleh Amazon Web Services menggunakan core Arm Neoverse 64-bit untuk memberikan peningkatan performa harga bagi beban kerja cloud Anda. Pelanggan mendapatkan keuntungan yang sama dari AWS Lambda, menjalankan kode tanpa menyediakan atau mengelola server, penskalaan otomatis, ketersediaan tinggi, dan hanya membayar sumber daya yang Anda konsumsi.

Fungsi AWS Lambda yang didukung oleh Graviton2, menggunakan arsitektur prosesor berbasis Arm yang dirancang oleh AWS, dirancang untuk memberikan performa harga hingga 34% lebih baik dibandingkan dengan fungsi yang berjalan pada prosesor x86, untuk berbagai beban kerja nirserver, seperti backend web dan seluler, data, dan pemrosesan aliran. Dengan latensi yang lebih rendah, performa hingga 19% lebih baik, biaya 20% lebih rendah, dan efisiensi daya tertinggi yang saat ini tersedia di AWS, fungsi Graviton2 dapat menjalankan aplikasi nirserver bermisi kritis. Pelanggan dapat mengonfigurasi fungsi yang ada dan yang baru untuk menargetkan prosesor Graviton2. Mereka dapat men-deploy fungsi yang berjalan di Graviton2 sebagai file zip atau citra kontainer.

Anda dapat mengonfigurasi fungsi untuk dijalankan di Graviton2 melalui Konsol Manajemen AWS, API AWS Lambda, AWS CLI, dan AWS CloudFormation dengan menyetel flag arsitektur ke 'arm64' untuk fungsi Anda.

Tidak ada perubahan antara fungsi berbasis x86 dan berbasis Arm. Cukup unggah kode Anda melalui Konsol Manajemen AWS, file zip, atau citra kontainer, dan AWS Lambda secara otomatis menjalankan kode Anda saat dipicu, tanpa mengharuskan Anda menyediakan atau mengelola infrastruktur.

Sebuah aplikasi dapat berisi fungsi yang berjalan pada kedua arsitektur. AWS Lambda memungkinkan Anda mengubah arsitektur ('x86_64' atau 'arm64') dari versi fungsi Anda saat ini. Setelah Anda membuat versi tertentu dari fungsi Anda, arsitekturnya tidak dapat diubah.

Bahasa yang ditafsirkan seperti Python, Java, dan Node umumnya tidak memerlukan kompilasi ulang kecuali kode Anda mereferensikan pustaka yang menggunakan komponen khusus arsitektur. Dalam kasus tersebut, Anda perlu menyediakan pustaka yang ditargetkan ke arm64. Untuk detail selengkapnya, lihat halaman Mulai menggunakan AWS Graviton. Bahasa yang tidak ditafsirkan akan memerlukan kompilasi kode Anda untuk menargetkan arm64. Sementara kompiler yang lebih modern akan menghasilkan kode yang dikompilasi untuk arm64, Anda perlu men-deploy-nya ke lingkungan berbasis arm untuk menguji. Untuk mempelajari selengkapnya tentang penggunaan fungsi Lambda dengan Graviton2, lihat dokumentasi.

Tidak. Setiap versi fungsi hanya dapat menggunakan satu citra kontainer.

Ya. Lapisan dan ekstensi dapat ditargetkan ke arsitektur yang kompatibel dengan 'x86_64' atau 'arm64'. Arsitektur default untuk fungsi dan lapisan adalah 'x86_64'.

Saat peluncuran, pelanggan dapat menggunakan citra Python, Node.js, Java, Ruby, .Net Core, Custom Runtime (provided.al2), dan OCI Base. Untuk mempelajari selengkapnya, lihat Runtime AWS Lambda.

Fungsi AWS Lambda yang didukung oleh prosesor AWS Graviton2 20% lebih murah dibandingkan dengan fungsi Lambda berbasis x86. Tingkat gratis Lambda berlaku untuk fungsi AWS Lambda yang didukung oleh arsitektur berbasis x86 dan Arm.

Setiap beban kerja bersifat unik dan kami menyarankan pelanggan menguji fungsi mereka untuk menentukan peningkatan performa harga yang mungkin mereka lihat. Untuk melakukan hal ini sebaiknya gunakan alat AWS Lambda Power Tuning. Sebaiknya mulai dengan backend web dan seluler, data, dan pemrosesan aliran saat menguji beban kerja Anda untuk peningkatan performa harga yang potensial.

Dengan Amazon Elastic File System (Amazon EFS) untuk AWS Lambda, pelanggan dapat membaca, menulis, dan mempertahankan volume data yang besar dengan aman, hampir pada segala skala menggunakan sistem file NFS elastis yang dikelola sepenuhnya, yang dapat menskalakan sesuai permintaan tanpa penyediaan atau pengelolaan kapasitas. Sebelumnya, pengembang menambahkan kode ke fungsi untuk mengunduh data dari S3 atau basis data ke penyimpanan lokal sementara, terbatas hanya 512 MB. Dengan EFS untuk Lambda, pengembang tidak perlu menulis kode untuk mengunduh data ke penyimpanan sementara agar dapat memprosesnya.

Developer dapat dengan mudah menghubungkan sistem file EFS yang ada ke fungsi Lambda melalui Titik Akses EFS menggunakan konsol, CLI, atau SDK. Ketika fungsi dipanggil pertama kali, sistem file akan dipasang secara otomatis dan disediakan untuk kode fungsi. Anda dapat mempelajari selengkapnya di dokumentasi.

Ya. Target pemasangan untuk Amazon EFS terkait dengan subnet di VPC. Fungsi AWS Lambda perlu dikonfigurasi untuk mengakses VPC tersebut.

EFS for Lambda cocok digunakan untuk membangun aplikasi machine learning atau memuat file ataupun model referensi yang besar, memproses atau mencadangkan data berjumlah besar, meng-host konten web, atau mengembangkan sistem build internal. Pelanggan juga dapat menggunakan EFS for Lambda untuk mempertahankan status antara panggilan di dalam arsitektur layanan mikro stateful, di alur kerja StepFunctions, atau file bersama antara aplikasi nirserver dan aplikasi berbasis instans atau kontainer.

Ya. Enkripsi data dalam transit menggunakan Transport Layer Security (TLS) 1.2 standar industri untuk mengenkripsi data yang dikirim antara fungsi AWS Lambda dan sistem file Amazon EFS.

Pelanggan dapat menyediakan Amazon EFS untuk mengenkripsi data saat istirahat. Data yang terenkripsi saat istirahat dienkripsi secara transparan saat ditulis dan didekripsi secara transparan saat dibaca, sehingga Anda tidak perlu mengubah aplikasi Anda. Kunci enkripsi dikelola oleh AWS Key Management Service (KMS), menghilangkan kebutuhan untuk membuat dan memelihara infrastruktur pengelolaan kunci yang aman.

Tidak ada biaya tambahan untuk menggunakan Amazon EFS untuk AWS Lambda. Pelanggan membayar harga standar untuk AWS Lambda dan untuk Amazon EFS. Saat menggunakan Lambda dan EFS dalam availability zone yang sama, pelanggan tidak dikenakan biaya untuk transfer data. Namun, jika mereka menggunakan peering VPC untuk akses Lintas Akun, akan menimbulkan biaya transfer data. Untuk mempelajari selengkapnya, lihat Harga.

Tidak. Setiap fungsi Lambda akan dapat mengakses satu sistem file EFS.

Ya. Amazon EFS mendukung fungsi Lambda, kontainer ECS dan Fargate, dan instans EC2. Anda dapat membagikan sistem file yang sama dan menggunakan kebijakan IAM dan Titik Akses untuk mengontrol apa yang dapat diakses oleh setiap fungsi, kontainer, atau instans.  

Ya. Fungsi Lambda dapat dikonfigurasi dengan URL fungsi, sebuah titik akhir HTTPS bawaan yang dapat dipanggil menggunakan peramban, curl, dan klien HTTP apa pun. URL Fungsi adalah cara mudah untuk mulai membangun fungsi yang dapat diakses HTTPS.

Anda dapat mengonfigurasi URL fungsi untuk fungsi Anda melalui Konsol Manajemen AWS, API AWS Lambda, AWS CLI, AWS CloudFormation, dan AWS Serverless Application Model. URL Fungsi bisa diaktifkan pada versi fungsi Anda yang tidak memenuhi syarat $LATEST, atau pada alias fungsi apa pun. Untuk mempelajari selengkapnya tentang mengonfigurasi URL fungsi, lihat dokumentasi.

URL fungsi Lambda diamankan dengan otorisasi IAM secara default. Anda dapat memilih menonaktifkan otorisasi IAM untuk membuat titik akhir publik atau jika Anda berencana untuk menerapkan otorisasi kustom sebagai bagian dari logika bisnis fungsi.

Anda dapat dengan mudah memanggil fungsi dari peramban web dengan bernavigasi ke URL Lambda, dari kode aplikasi klien Anda menggunakan pustaka HTTP, atau dari baris perintah menggunakan curl.

Ya. URL fungsi Lambda dapat diaktifkan pada fungsi atau alias fungsi. Jika tidak ada alias yang ditentukan, URL akan merujuk ke $LATEST secara default. URL Fungsi tidak dapat menargetkan versi fungsi individual.

Nama domain kustom saat ini tidak didukung URL fungsi. Anda dapat menggunakan domain kustom dengan URL fungsi dengan membuat distribusi Amazon CloudFront dan CNAME untuk memetakan domain kustom ke nama distribusi CloudFront Anda. Lalu, petakan nama domain distribusi CloudFront Anda untuk dirutekan ke URL fungsi sebagai asal.

Ya, URL fungsi dapat digunakan untuk memanggil fungsi Lamda di VPC.

Tidak ada biaya tambahan yang dikenakan untuk menggunakan URL fungsi. Anda akan membayar harga standar AWS Lambda. Untuk mempelajari selengkapnya, lihat Harga AWS Lambda.

Lambda@Edge memungkinkan Anda menjalankan kode di lokasi AWS secara global tanpa menyediakan atau mengelola server untuk merespons pengguna akhir dengan latensi jaringan terendah. Anda cukup mengunggah kode Node.js atau Python ke AWS Lambda dan mengonfigurasi fungsi untuk dipicu sebagai respons terhadap permintaan Amazon CloudFront (yaitu ketika permintaan penampil tiba, ketika permintaan diteruskan ke atau diterima kembali dari asalnya, dan tepat sebelum merespons kembali ke pengguna akhir). Kode ini kemudian siap untuk dieksekusi di lokasi AWS secara global ketika permintaan untuk konten diterima, kemudian menskalakan dengan volume permintaan CloudFront secara global. Pelajari lebih lanjut di dokumentasi kami.

Untuk menggunakan Lambda@Edge, Anda cukup mengunggah kode ke AWS Lambda dan mengaitkan versi fungsi untuk dipicu sebagai respons permintaan Amazon CloudFront. Kode harus memenuhi service limits Lambda@Edge. Lambda@Edge mendukung Node.js dan Python untuk permintaan global oleh kejadian CloudFront pada saat ini. Pelajari lebih lanjut di dokumentasi kami.

Lambda@Edge dioptimalkan untuk kasus penggunaan latensi sensitif di mana pengguna akhir Anda didistribusikan secara global. Semua informasi yang Anda perlukan untuk membuat keputusan seharusnya tersedia di edge CloudFront, dalam fungsi dan permintaan. Hal ini berarti bahwa kasus penggunaan ketika Anda ingin membuat keputusan tentang cara menyajikan konten berdasarkan karakteristik pengguna (misalnya lokasi, perangkat klien, dll.) sekarang dapat dijalankan dan disajikan dekat dengan pengguna Anda tanpa harus dirutekan kembali ke pusat server.

Anda dapat mengaitkan fungsi Lambda yang sudah ada dengan kejadian CloudFront untuk permintaan global jika fungsi tersebut memenuhi persyaratan dan batasan layanan Lambda@Edge. Baca selengkapnya di sini cara memperbarui properti fungsi Anda.

Fungsi Anda akan secara otomatis memicu respons terhadap peristiwa Amazon CloudFront berikut:

• Permintaan Pengguna – Kejadian ini terjadi ketika pengguna akhir atau perangkat di Internet membuat permintaan HTTP(S) ke CloudFront, dan permintaan tersebut tiba di lokasi edge yang paling dekat dengan pengguna tersebut.
• Tanggapan Pengguna – Kejadian ini terjadi ketika server CloudFront di edge siap untuk merespons pengguna akhir atau perangkat yang membuat permintaan.
• Permintaan Asal – Peristiwa ini terjadi ketika server edge CloudFront belum memiliki objek yang diminta dalam cache-nya, dan permintaan pelanggan siap dikirim ke server web asal backend Anda (misalnya Amazon EC2, atau Application Load Balancer, atau Amazon S3).
• Respons Asal – Peristiwa ini terjadi ketika server CloudFront di edge menerima respons dari server web asal backend Anda.

Perbedaanya adalah bahwa API Gateway dan Lambda adalah layanan regional. Lambda@Edge dan Amazon CloudFront memungkinkan Anda mengeksekusi logika di beberapa lokasi AWS berdasarkan lokasi penampil akhir Anda.

AWS Lambda didesain untuk menggunakan replikasi dan redundansi guna memberikan ketersediaan yang tinggi untuk layanan itu sendiri maupun fungsi Lambda yang dioperasikannya. Tidak ada jendela pemeliharaan atau waktu henti terjadwal untuk keduanya.

Ya. Ketika Anda memperbarui fungsi Lambda, akan ada jendela waktu singkat, biasanya kurang dari satu menit, ketika permintaan dapat disajikan oleh versi lama atau versi baru dari fungsi Anda.

Tidak. AWS Lambda didesain untuk menjalankan banyak instans fungsi Anda secara paralel. Namun, AWS Lambda memiliki pembatas keamanan default, untuk sejumlah eksekusi bersamaan per akun per wilayah (kunjungi di sini untuk info tentang batas pembatas keamanan default). Anda juga dapat mengontrol eksekusi bersamaan maksimum untuk masing-masing fungsi AWS Lambda, yang dapat Anda gunakan untuk mencadangkan subset dari batas konkurensi akun Anda untuk fungsi-fungsi penting, atau membatasi tingkat lalu lintas ke sumber daya hilir.

Jika Anda ingin mengirimkan permintaan untuk meningkatkan batas eksekusi bersamaan, Anda dapat menggunakan Kuota Layanan untuk meminta peningkatan batas.

Jika melebihi batas eksekusi bersamaan maksimum, fungsi AWS Lambda yang diinvokasi secara sinkronis akan mengembalikan kesalahan throttling (kode kesalahan 429). Fungsi Lambda yang diinvokasi secara asinkronis dapat menyerap lonjakan lalu lintas yang wajar selama sekitar 15-30 menit, setelah itu peristiwa yang masuk akan ditolak karena dibatasi. Jika fungsi Lambda sedang dipanggil sebagai respons atas kejadian Amazon S3, kejadian yang ditolak oleh AWS Lambda dapat disimpan dan dicoba kembali oleh S3 selama 24 jam. Kejadian dari Amazon Kinesis Streams dan Amazon DynamoDB Streams dicoba ulang hingga fungsi Lambda berhasil atau data kedaluwarsa. Amazon Kinesis dan Amazon DynamoDB Streams mempertahankan data selama 24 jam.

Batas eksekusi bersamaan maksimum default diterapkan pada tingkat akun. Namun, Anda juga dapat menetapkan batas pada masing-masing fungsi (kunjungi di sini untuk info tentang Konkurensi Terpesan).

Setiap fungsi Lambda yang diinvokasi secara sinkronis dapat menskalakan hingga 1.000 eksekusi bersamaan setiap 10 detik. Sementara tingkat penskalaan Lambda cocok untuk sebagian besar kasus penggunaan, Lambda sangat ideal bagi mereka yang memiliki lonjakan lalu lintas yang dapat diprediksi atau tidak dapat diprediksi. Misalnya, pemrosesan data terikat SLA akan membutuhkan penskalaan yang dapat diprediksi namun cepat untuk memenuhi permintaan pemrosesan. Demikian pula, menyajikan artikel berita terbaru, atau penjualan kilat dapat mendorong tingkat lalu lintas yang tidak dapat diprediksi dalam waktu singkat. Tingkat penskalaan Lambda dapat memfasilitasi kasus penggunaan tanpa konfigurasi atau alat tambahan. Selain itu, batas penskalaan konkurensi adalah batas tingkat fungsi, yang berarti setiap fungsi di akun Anda diskalakan secara independen dari fungsi lainnya.

Jika gagal, fungsi Lambda yang dipanggil secara sinkronis akan merespons dengan pengecualian. Fungsi Lambda yang dipanggil secara asinkronis dicoba ulang setidaknya 3 kali. Kejadian dari Amazon Kinesis Streams dan Amazon DynamoDB Streams dicoba ulang hingga fungsi Lambda berhasil atau data kedaluwarsa. Kinesis dan DynamoDB Streams me-retain data selama minimal 24 jam.

Anda dapat mengonfigurasi antrean Amazon SQS atau topik Amazon SNS sebagai antrean dead letter.

Jika melebihi kebijakan coba lagi untuk permintaan asinkronis, Anda dapat mengonfigurasi “dead letter queue” (DLQ) ke tempat kejadian akan diletakkan; dengan tidak adanya DLQ yang dikonfigurasi, kejadian tersebut dapat ditolak. Jika kebijakan percobaan ulang untuk invokasi berbasis aliran terlampaui, data akan kedaluwarsa dan karenanya ditolak.

Anda memberikan izin untuk fungsi Lambda guna mengakses sumber daya lain menggunakan IAM role AWS Lambda mengasumsikan peran saat mengeksekusi fungsi Lambda Anda, jadi Anda selalu me-retain kontrol penuh dan aman dari sumber daya AWS yang tepat yang dapat digunakan. Kunjungi Menyiapkan AWS Lambda untuk mempelajari selengkapnya tentang peran.

Ketika Anda mengonfigurasi bucket Amazon S3 untuk mengirim pesan ke fungsi AWS Lambda, aturan kebijakan sumber daya yang memberikan akses akan dibuat. Kunjungi Panduan Developer Lambda untuk mempelajari selengkapnya tentang kebijakan sumber daya dan kontrol akses untuk fungsi Lambda.

Kontrol akses dikelola melalui peran fungsi Lambda. Peran yang Anda berikan untuk fungsi Lambda juga menentukan sumber daya mana yang dapat diminta oleh AWS Lambda untuk dirinya sendiri. Kunjungi Panduan Developer Lambda untuk mempelajari selengkapnya.

Kontrol akses dapat dikelola oleh peran fungsi Lambda atau pengaturan kebijakan sumber daya pada antrean itu sendiri. Jika kedua kebijakan itu ada, kedua izin yang semakin terbatas tersebut akan diterapkan.

Anda dapat mengaktifkan fungsi Lambda untuk mengakses sumber daya di VPC Anda dengan menentukan subnet dan grup keamanan sebagai bagian dari konfigurasi fungsi Anda. Fungsi Lambda yang dikonfigurasi untuk mengakses sumber daya di VPC tertentu tidak akan memiliki akses ke internet sebagai konfigurasi default. Untuk memberikan internet ke fungsi-fungsi ini, gunakan gateway internet. Secara default, fungsi Lambda berkomunikasi dengan sumber daya dalam VPC dual-stack melalui IPv4. Anda dapat mengonfigurasi fungsi Anda untuk mengakses sumber daya dalam VPC dual-stack melalui IPv6. Untuk detail selengkapnya mengenai fungsi Lambda yang dikonfigurasikan dengan VPC, lihat Jaringan Privat Lambda dengan VPC.

Penandatanganan Kode untuk AWS Lambda menawarkan kontrol kepercayaan dan integritas yang memungkinkan Anda memverifikasi bahwa hanya kode yang tidak diubah dari developer yang disetujui yang diterapkan di fungsi Lambda. Anda dapat menggunakan AWS Signer, layanan penandatanganan kode yang terkelola penuh, untuk menandatangani artefak kode secara digital dan mengonfigurasi fungsi Lambda guna memverifikasi tanda tangan saat deployment. Penandatanganan Kode untuk AWS Lambda saat ini hanya tersedia untuk fungsi yang dikemas sebagai arsip ZIP.

Anda dapat membuat artefak kode yang ditandatangani secara digital menggunakan Profil Penandatanganan melalui konsol AWS Signer, Signer API, SAM CLI, atau AWS CLI. Untuk mempelajari selengkapnya, baca dokumentasi untuk AWS Signer.

Anda dapat mengaktifkan penandatanganan kode dengan membuat Konfigurasi Penandatanganan Kode melalui AWS Management Console, Lambda API, AWS CLI, AWS CloudFormation, dan AWS SAM. Konfigurasi Penandatanganan Kode membantu Anda menentukan profil penandatanganan yang disetujui dan mengonfigurasi apakah akan memperingatkan atau menolak deployment jika pemeriksaan tanda tangan gagal. Konfigurasi Penandatanganan Kode dapat dilampirkan ke fungsi Lambda individu untuk mengaktifkan fitur penandatanganan kode. Fungsi tersebut sekarang mulai memverifikasi tanda tangan saat deployment.

AWS Lambda dapat menjalankan pemeriksaan tanda tangan berikut saat penerapan:

• Tanda tangan rusak - Ini terjadi jika artefak kode telah diubah sejak penandatanganan.
• Tanda tangan tidak cocok - Ini terjadi jika artefak kode ditandatangani oleh profil penandatanganan yang tidak disetujui.
• Tanda tangan kedaluwarsa - Ini terjadi jika tanda tangan melebihi tanggal berakhir yang dikonfigurasi.
• Tanda tangan yang dibatalkan - Ini terjadi jika pemilik profil penandatanganan membatalkan tugas penandatanganan.

Untuk mempelajari selengkapnya, lihat dokumentasi AWS Lambda.

Ya, Anda dapat mengaktifkan penandatanganan kode untuk fungsi yang ada dengan melampirkan konfigurasi penandatanganan kode ke fungsi tersebut. Anda dapat melakukannya menggunakan konsol AWS Lambda, API Lambda, AWS CLI, AWS CloudFormation, dan AWS SAM.

Tidak ada biaya tambahan saat menggunakan Penandatanganan Kode untuk AWS Lambda. Anda membayar harga standar untuk AWS Lambda. Untuk mempelajari selengkapnya, lihat Harga.

Untuk memberi Anda pengalaman pencatatan yang disederhanakan dan ditingkatkan secara default, AWS Lambda menawarkan kontrol pencatatan lanjutan seperti kemampuan untuk menangkap log fungsi Lambda secara native dalam format terstruktur JSON, mengontrol pemfilteran tingkat log dari log fungsi Lambda tanpa membuat perubahan kode apa pun, serta menyesuaikan grup log Amazon CloudWatch yang dikirimkan Lambda ke log.

Anda dapat menangkap log fungsi Lambda dalam format terstruktur JSON tanpa harus menggunakan pustaka pencatatan Anda sendiri. Log terstruktur JSON memudahkan pencarian, pemfilteran, dan analisis entri log dengan volume besar. Anda dapat mengontrol pemfilteran tingkat log dari log fungsi Lambda tanpa membuat perubahan kode apa pun, yang memungkinkan Anda memilih tingkat perincian pencatatan yang diperlukan untuk fungsi Lambda tanpa menyaring log bervolume besar saat melakukan debug dan memecahkan masalah kesalahan. Anda juga dapat mengatur ke grup log Amazon CloudWatch mana Lambda mengirimkan log, sehingga memudahkan dalam mengagregasi log dari beberapa fungsi dalam aplikasi di satu tempat. Anda kemudian dapat menerapkan kebijakan keamanan, tata kelola, dan retensi ke log di tingkat aplikasi alih-alih secara individual untuk setiap fungsi.

Anda dapat menentukan kontrol pencatatan lanjutan untuk fungsi Lambda menggunakan API AWS Lambda, konsol AWS Lambda, AWS CLI, AWS Serverless Application Model (SAM), dan AWS CloudFormation. Untuk mempelajari selengkapnya, kunjungi postingan blog peluncuran untuk kontrol pencatatan lanjutan atau Panduan Developer Lambda.

Ya, Anda dapat menggunakan pustaka pencatatan Anda sendiri untuk menghasilkan log Lambda dalam format terstruktur JSON. Untuk memastikan pustaka pencatatan Anda bekerja secara lancar dengan kemampuan pencatatan terstruktur JSON asli Lambda, Lambda tidak akan melakukan enkode ulang setiap log yang dihasilkan oleh fungsi yang sudah dikodekan JSON. Anda juga dapat menggunakan pustaka Powertools for AWS Lambda untuk menangkap log Lambda dalam format terstruktur JSON.

Tidak ada biaya tambahan untuk penggunaan kontrol pencatatan lanjutan di Lambda. Anda akan terus dikenai biaya untuk penyerapan dan penyimpanan log Lambda oleh Log Amazon CloudWatch. Lihat halaman harga CloudWatch untuk detail harga log.

Anda dapat menggunakan alat standar seperti Maven atau Gradle untuk mengompilasi fungsi Lambda Anda. Proses build harus meniru proses build yang sama yang akan Anda gunakan untuk mengompilasi kode Java apa pun yang bergantung pada AWS SDK. Jalankan alat pengompilasi Java Anda pada file sumber Anda dan sertakan AWS SDK 1.9 atau yang lebih baru dengan dependensi transitif pada classpath Anda. Untuk detail selengkapnya, lihat dokumentasi kami.

Lambda menggunakan build Amazon Linux openjdk 1.8.

Ya. Anda dapat menggunakan paket NPM dan juga paket khusus. Pelajari selengkapnya di sini.

Ya. Sandbox bawaan Lambda memungkinkan Anda menjalankan skrip batch (“shell”), runtime bahasa lainnya, rutinitas utilitas, dan eksekusi. Pelajari selengkapnya di sini.

Ya. Setiap modul asli yang terhubung secara statis dapat dimasukkan dalam file ZIP yang Anda unggah, serta modul-modul yang terhubung secara dinamis yang dikompilasi dengan rpath yang menunjuk ke direktori akar fungsi Lambda Anda. Pelajari selengkapnya di sini.

Ya. Anda dapat menggunakan perintah child_process Node.js untuk mengeksekusi biner yang telah dimasukkan ke dalam fungsi atau eksekusi apa pun dari Amazon Linux yang terlihat oleh fungsi Anda. Atau beberapa paket NPM ada yang mengemas baris perintah biner seperti node-ffmpeg. Pelajari selengkapnya di sini.

Untuk menerapkan fungsi Lambda yang tertulis di Node.js, cukup kemas kode Javascript dan pustaka dependen Anda sebagai ZIP. Anda dapat mengunggah ZIP dari lingkungan lokal, atau menentukan lokasi Amazon S3 tempat file ZIP berada. Untuk detail selengkapnya, lihat dokumentasi kami.

Ya. Anda dapat menggunakan pip untuk menginstal paket Python apa pun yang diperlukan.

Anda dapat membuat fungsi Lambda C# menggunakan IDE Visual Studio dengan memilih "Terbitkan ke AWS Lambda" di Solution Explorer. Atau, Anda dapat langsung menjalankan perintah "dotnet lambda publish" dari dotnet CLI yang memiliki [patch alat # Lambda CLI] terinstal, yang membuat ZIP kode sumber C# Anda bersama dengan semua dependensi NuGet serta rakitan DLL yang Anda publikasikan sendiri, dan secara otomatis mengunggahnya ke AWS Lambda menggunakan parameter runtime “dotnetcore1.0”

Paket deployment PowerShell Lambda adalah file ZIP yang berisi skrip PowerShell Anda, modul PowerShell yang diperlukan untuk skrip PowerShell Anda, dan perakitan yang diperlukan untuk menghosting PowerShell Core. Kemudian Anda menggunakan modul AWSLambdaPSCore PowerShell yang dapat Anda instal dari PowerShell Gallery untuk membuat paket deployment PowerShell Lambda Anda.

Unggah artefak Go Anda yang dapat dijalankan sebagai file ZIP melalui AWS CLI atau konsol Lambda dan pilih runtime go1.x. Dengan Lambda, Anda dapat menggunakan peralatan asli Go untuk membuat dan mengemas kode Anda. Untuk detail lebih lanjut, baca dokumentasi kami. 

Untuk menyebarkan fungsi Lambda yang tertulis dalam Ruby, cukup kemas kode Ruby dan permata Anda sebagai ZIP. Anda dapat mengunggah ZIP dari lingkungan lokal, atau menentukan lokasi Amazon S3 tempat file ZIP berada.

Anda dapat melihat daftar versi yang didukung di sini.

Tidak. AWS Lambda menawarkan versi tunggal sistem operasi dan runtime bahasa terkelola ke semua pengguna layanan. Anda dapat membawa runtime bahasa Anda sendiri untuk digunakan di Lambda.

AWS Lambda terintegrasi dengan AWS CloudTrail. AWS CloudTrail dapat merekam dan menyampaikan file log ke bucket Amazon S3 yang mendeskripsikan penggunaan API akun Anda.

Anda dapat menggunakan Amazon Step Functions untuk mengoordinasikan beberapa fungsi Lambda. Anda dapat memanggil beberapa fungsi Lambda secara berangkai, meneruskan output dari satu ke yang lain, atau secara paralel. Baca dokumentasi kami untuk detail selengkapnya.

Ya, AWS Lambda mendukung set petunjuk Advanced Vector Extensions 2 (AVX2). Untuk mempelajari selengkapnya tentang cara menyusun kode aplikasi Anda untuk menargetkan set instruksi ini guna meningkatkan performa, baca dokumentasi developer AWS Lambda.