Praktik terbaik untuk Fungsi Web Lambda

Setiap titik akhir dapat dijangkau dari internet, apa pun jenis otentikasinya. DenganApplicationManaged, Lambda tidak mengautentikasi permintaan, sehingga setiap klien yang mengetahui domain dapat memanggil aplikasi Anda. Menerapkan otentikasi, otorisasi, validasi input, pemeriksaan ukuran permintaan, dan perlindungan penyalahgunaan dalam aplikasi atau di pintu depan.

Gunakan IamAuth saat penelepon dapat menandatangani permintaan dan kebijakan IAM menyediakan model otorisasi yang diperlukan. Kebijakan sumber daya lingkup ke ARN dan prinsipal titik akhir tertentu.

Letakkan Amazon CloudFront atau Amazon API Gateway di depan titik akhir saat Anda memerlukan domain khusus, AWS WAF inspeksi, caching, atau kontrol tepi terpusat. Batasi asal sehingga klien tidak dapat melewati pintu depan. Dengan CloudFront, gunakan IamAuth endpoint dan origin access control (OAC), seperti yang dijelaskan dalam. CloudFront integrasi Dengan pintu depan lainnya, titik akhir tetap dapat dijangkau secara langsung, jadi verifikasi rahasia atau token bersama dalam aplikasi.

Gunakan peran eksekusi khusus dengan izin hak istimewa paling sedikit. Pisahkan identitas penerapan, pengunggah kode, prinsip layanan Lambda, peran eksekusi, dan izin pemanggil titik akhir.

Jangan menaruh rahasia dalam paket penyebaran atau log. Muat rahasia saat runtime dari toko rahasia yang sesuai, cache hanya selama diperlukan, dan edit bidang permintaan sensitif.

Aktifkan pembuatan versi pada bucket kode dan rekam ID versi objek untuk setiap penerapan.

Jangan menimpa atau menghapus versi objek yang digunakan oleh revisi aktif atau rollback. Simpan akses utama layanan Lambda selama revisi mereferensikan objek.

Bangun paket penerapan dalam pipeline yang dapat diulang. Instal dependensi produksi dari file kunci, kecualikan file pengembangan, dan uji arsip yang tepat sebelum mengunggah.

Bangun dependensi asli untuk Arm64. Modul asli yang dibuat untuk x86_64 tidak berjalan di lingkungan eksekusi Fungsi Web.

Gunakan bucket, awalan, peran, atau akun terpisah saat lingkungan memiliki persyaratan kepercayaan atau retensi yang berbeda.

Simpan data khusus permintaan dalam lingkup permintaan. Jangan menyimpan kredensi, data pelanggan, objek respons, atau status per permintaan yang dapat berubah dalam variabel global.

Gunakan asinkron I/O. CPU sinkron atau kerja sistem file memblokir loop Node.js peristiwa dan menunda setiap permintaan dalam penerbangan di lingkungan.

Gunakan worker_threads untuk CPU-intensive pekerjaan yang harus menggunakan beberapa vCPU, atau maxConcurrencyPerEnvironment lebih rendah untuk mengurangi pertengkaran.

Akun untuk Node.js heap secara terpisah dari memori lingkungan. Lingkungan memiliki 2 GB, sedangkan tumpukan V8 default adalah 1.024 MB. Jika Anda meningkatkan heap dengan --max-old-space-size inNODE_OPTIONS, tinggalkan memori untuk buffer, modul asli, runtime, dan permintaan bersamaan.

Gunakan kembali klien yang diinisialisasi dan kumpulan koneksi di seluruh permintaan, tetapi validasi koneksi basi dan pertumbuhan cache terikat. Pertahankan status yang diperlukan di luar lingkungan eksekusi.

Jaga agar koneksi keluar tetap hidup sehingga permintaan ke database dan dependensi lain menggunakannya kembali alih-alih membuka koneksi baru setiap kali. Node.jsmemungkinkan keep-alive secara default di agen HTTP globalnya. Jika Anda membuat agen sendiri atau mengonfigurasi klien SDK, tetap aktifkan keep-alive. Juga menangani koneksi yang ditutup oleh sisi jarak jauh saat mereka menganggur.

Gunakan nama unik untuk file sementara dan hapus ketika mereka tidak lagi diperlukan. Beberapa permintaan berbagi sistem /tmp file 512 MB lingkungan, dan file dapat bertahan di seluruh permintaan hingga lingkungan dihapus.

Mulai server HTTP segera dan dengarkan nilai yang tepat dari. AWS_LAMBDA_HTTP_ENDPOINT

Jaga agar paket tetap kecil dan hapus dependensi produksi yang tidak digunakan.

Inisialisasi hanya sumber daya yang dibutuhkan sebelum server dapat menerima lalu lintas. Lakukan pekerjaan opsional dengan malas, tetapi mencegah permintaan bersamaan menduplikasi inisialisasi yang mahal.

Tangani SIGTERM pembersihan yang selesai dalam 1 detik, tetapi jangan mengandalkan panggilan balik shutdown untuk mempertahankan data yang diperlukan.

Uji beban dengan dependensi aplikasi yang sama dan layanan hilir yang digunakan dalam produksi. Tingkatkan konkurensi hingga latensi, konsumsi CPU, memori, atau kapasitas hilir menjadi kendala pengikatan.

Gunakan maxConcurrencyPerEnvironment untuk mengikat pertikaian per proses, maxEnvironments ke skala horizontal terikat, dan rateLimit untuk melindungi dependensi hilir dari semburan permintaan.

Periksa akun yang diterapkan dan batas Regional sebelum pengujian kinerja dan peluncuran. Konfigurasi titik akhir tidak dapat membuat kapasitas di luar batas akun.

Coba lagi respons HTTP 429 dan respons HTTP 503 yang tidak memiliki header. lambda-web-error-type Gunakan backoff dan jitter, dan coba lagi hanya ketika operasi idempoten. Gunakan kunci idempotensi atau deduplikasi tingkat aplikasi untuk penulisan.

Gunakan bobot revisi manual untuk titik akhir produksi. Simpan penerapan revisi terbaru otomatis untuk lingkungan pengembangan di mana peluncuran langsung dapat diterima.

Tunggu hingga revisi baru selesai Active dan pembaruan titik akhir selesai sebelum Anda mengevaluasinya. Untuk MultiRegion dan PerRegion titik akhir, verifikasi status pembaruan di setiap Wilayah.

Gunakan log aplikasi atau metrik khusus yang menyertakan pengenal revisi selama penerapan canary. Service-vended metrik tidak termasuk dimensi revisi.

Sebelum Anda mengalihkan lalu lintas, tentukan metrik yang harus dipenuhi oleh revisi baru dan berapa lama Anda mengamatinya (kriteria panggang), dan ambang batas yang memicu kemunduran. Pertahankan versi objek kode revisi sebelumnya, akses kunci, dan konfigurasi hingga jendela rollback berakhir. Lambda secara otomatis menghapus revisi tertua yang tidak dirutekan titik akhir ketika Fungsi Web melebihi batas revisinya, jadi pertahankan revisi rollback pada titik akhir (misalnya, titik akhir pengujian) atau siap untuk membuatnya kembali dari versi objek yang sama. Lihat perinciannya di Batas revisi dan pembersihan otomatis.

Memancarkan log aplikasi terstruktur dengan ID permintaan, ID revisi, rute, kode status, durasi, dan pengidentifikasi yang diperlukan untuk mendiagnosis kegagalan hilir. Jangan mencatat kredensi, token, atau badan permintaan sensitif.

Alarm pada respons 5xx dan throttle, dan pantau permintaan yang dieksekusi, lingkungan aktif, dan kapasitas akun. Konfigurasikan metrik kesalahan jarang untuk menangani data yang hilang dengan tepat.

Gunakan ID permintaan respons dan header log-stream untuk menghubungkan kegagalan klien dengan log. Aktifkan log sistem DEBUG hanya saat Anda membutuhkan acara tambahan.

Rekam operasi manajemen dan peristiwa data pemanggilan titik akhir AWS CloudTrail saat persyaratan audit Anda membutuhkannya.

Buat data aplikasi, rahasia, kunci, dan dependensi hilir tersedia di setiap Wilayah yang dapat menerima lalu lintas.

Uji kegagalan penerapan sebagian dan kegagalan ketergantungan Regional. Jangan berasumsi bahwa semua Wilayah menjalankan revisi yang sama sampai setiap pembaruan Regional melaporkan keberhasilan.

Setelah setiap pembaruan titik akhir, periksa updateStatus setiap entri diregionalEndpoints. Replikasi dapat gagal di beberapa Wilayah sementara berhasil di daerah lain. Akibatnya, pembaruan dapat diterapkan sebagian. Coba lagi atau putar kembali sebelum Anda memperlakukan penerapan sebagai selesai.

Untuk PerRegion titik akhir, uji DNS eksternal atau failover pintu depan Anda secara independen dari penerapan Fungsi Web.

Memusatkan pandangan operasional di Wilayah asal, tetapi pertahankan jalur pemulihan untuk penundaan atau gangguan telemetri.