Ini adalah Panduan Pengembang AWS CDK v2. CDKV1 yang lebih lama memasuki pemeliharaan pada 1 Juni 2022 dan mengakhiri dukungan pada 1 Juni 2023.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Praktik terbaik untuk mengembangkan dan menerapkan infrastruktur cloud dengan AWS CDK

Dengan itu AWS CDK, pengembang atau administrator dapat menentukan infrastruktur cloud mereka dengan menggunakan bahasa pemrograman yang didukung. CDKaplikasi harus diatur ke dalam unit logis, seperti databaseAPI, dan sumber daya pemantauan, dan secara opsional memiliki saluran untuk penerapan otomatis. Unit logis harus diimplementasikan sebagai konstruksi termasuk yang berikut:

Tumpukan mendefinisikan model penyebaran unit logis ini. Untuk pengantar yang lebih rinci tentang konsep di balikCDK, lihatMemulai dengan AWS CDK.

Ini AWS CDK mencerminkan pertimbangan yang cermat terhadap kebutuhan pelanggan dan tim internal kami dan pola kegagalan yang sering muncul selama penyebaran dan pemeliharaan berkelanjutan aplikasi cloud yang kompleks. Kami menemukan bahwa kegagalan sering terkait dengan perubahan out-of-band "" pada aplikasi yang tidak sepenuhnya diuji, seperti perubahan konfigurasi. Oleh karena itu, kami mengembangkan model di mana seluruh aplikasi Anda didefinisikan dalam kode, tidak hanya logika bisnis tetapi juga infrastruktur dan konfigurasi. AWS CDK Dengan begitu, perubahan yang diusulkan dapat ditinjau dengan cermat, diuji secara komprehensif di lingkungan yang menyerupai produksi dengan tingkat yang berbeda-beda, dan sepenuhnya diputar kembali jika terjadi kesalahan.

Pada waktu penerapan, AWS CDK mensintesis rakitan cloud yang berisi hal-hal berikut:

Dengan ituCDK, setiap komit di cabang kontrol versi utama aplikasi Anda dapat mewakili versi aplikasi Anda yang lengkap, konsisten, dan dapat diterapkan. Aplikasi Anda kemudian dapat digunakan secara otomatis setiap kali perubahan dilakukan.

Filosofi di balik AWS CDK mengarah pada praktik terbaik yang kami rekomendasikan, yang telah kami bagi menjadi empat kategori besar.

Praktik terbaik untuk organisasi

Pada tahap awal AWS CDK adopsi, penting untuk mempertimbangkan bagaimana mengatur organisasi Anda untuk sukses. Ini adalah praktik terbaik untuk memiliki tim ahli yang bertanggung jawab untuk melatih dan membimbing seluruh perusahaan saat mereka mengadopsi. CDK Ukuran tim ini mungkin bervariasi, dari satu atau dua orang di perusahaan kecil hingga Cloud Center of Excellence (CCoE) yang lengkap di perusahaan yang lebih besar. Tim ini bertanggung jawab untuk menetapkan standar dan kebijakan untuk infrastruktur cloud di perusahaan Anda, dan juga untuk pelatihan dan pendampingan pengembang.

CCoEMungkin memberikan panduan tentang bahasa pemrograman apa yang harus digunakan untuk infrastruktur cloud. Detail akan bervariasi dari satu organisasi ke organisasi berikutnya, tetapi kebijakan yang baik membantu memastikan bahwa pengembang dapat memahami dan memelihara infrastruktur cloud perusahaan.

Ini CCoE juga menciptakan “landing zone” yang mendefinisikan unit organisasi Anda di dalamnya AWS. Landing zone adalah AWS lingkungan multi-akun yang telah dikonfigurasi sebelumnya, aman, dapat diskalakan, berdasarkan cetak biru praktik terbaik. Untuk menyatukan layanan yang membentuk landing zone Anda, Anda dapat menggunakan AWS Control Tower, yang mengonfigurasi dan mengelola seluruh sistem multi-akun Anda dari satu antarmuka pengguna.

Tim pengembangan harus dapat menggunakan akun mereka sendiri untuk menguji dan menyebarkan sumber daya baru di akun ini sesuai kebutuhan. Pengembang individu dapat memperlakukan sumber daya ini sebagai ekstensi dari workstation pengembangan mereka sendiri. Menggunakan CDKPipelines, AWS CDK aplikasi kemudian dapat digunakan melalui akun CI/CD untuk pengujian, integrasi, dan lingkungan produksi (masing-masing diisolasi di AWS Wilayah atau akunnya sendiri). Ini dilakukan dengan menggabungkan kode pengembang ke dalam repositori kanonik organisasi Anda.

Praktik terbaik pengkodean

Bagian ini menyajikan praktik terbaik untuk mengatur AWS CDK kode Anda. Diagram berikut menunjukkan hubungan antara tim dan repositori kode tim, paket, aplikasi, dan pustaka konstruksi.

Mulai sederhana dan tambahkan kompleksitas hanya ketika Anda membutuhkannya

Prinsip panduan untuk sebagian besar praktik terbaik kami adalah menjaga hal-hal sesederhana mungkin—tetapi tidak lebih sederhana. Tambahkan kompleksitas hanya ketika kebutuhan Anda menentukan solusi yang lebih rumit. Dengan AWS CDK, Anda dapat memfaktorkan ulang kode Anda seperlunya untuk mendukung persyaratan baru. Anda tidak perlu merancang untuk semua skenario yang mungkin di muka.

Sejajarkan dengan Kerangka AWS Well-Architected

AWS Well-Architected Framework mendefinisikan komponen sebagai kode, konfigurasi, AWS dan sumber daya yang bersama-sama memenuhi persyaratan. Komponen biasanya berupa unit kepemilikan teknis, dan terpisah dari komponen lainnya. Istilah beban kerja digunakan untuk mengidentifikasi serangkaian komponen yang dikombinasikan untuk memberikan nilai bisnis. Beban kerja biasanya merupakan tingkat detail yang dibicarakan oleh pimpinan bisnis dan teknologi.

AWS CDK Aplikasi memetakan ke komponen seperti yang didefinisikan oleh AWS Well-Architected Framework. AWS CDK aplikasi adalah mekanisme untuk mengkodifikasi dan memberikan praktik terbaik aplikasi cloud yang Dirancang dengan Baik. Anda juga dapat membuat dan berbagi komponen sebagai pustaka kode yang dapat digunakan kembali melalui repositori artefak, seperti. AWS CodeArtifact

Setiap aplikasi dimulai dengan satu paket dalam satu repositori

Satu paket adalah titik masuk AWS CDK aplikasi Anda. Di sini, Anda menentukan bagaimana dan di mana untuk menyebarkan unit logis yang berbeda dari aplikasi Anda. Anda juga menentukan pipeline CI/CD untuk menyebarkan aplikasi. Konstruksi aplikasi menentukan unit logis dari solusi Anda.

Gunakan paket tambahan untuk konstruksi yang Anda gunakan di lebih dari satu aplikasi. (Konstruksi bersama juga harus memiliki siklus hidup dan strategi pengujian sendiri.) Dependensi antar paket dalam repositori yang sama dikelola oleh perkakas build repo Anda.

Meskipun mungkin, kami tidak menyarankan untuk menempatkan beberapa aplikasi di repositori yang sama, terutama saat menggunakan pipeline penerapan otomatis. Melakukan hal ini meningkatkan “radius ledakan” perubahan selama penerapan. Ketika ada beberapa aplikasi dalam repositori, perubahan pada satu aplikasi memicu penerapan yang lain (bahkan jika yang lain tidak berubah). Selain itu, jeda dalam satu aplikasi mencegah aplikasi lain dikerahkan.

Pindahkan kode ke repositori berdasarkan siklus hidup kode atau kepemilikan tim

Ketika paket mulai digunakan dalam beberapa aplikasi, pindahkan ke repositori mereka sendiri. Dengan cara ini, paket dapat direferensikan oleh sistem build aplikasi yang menggunakannya, dan mereka juga dapat diperbarui pada irama independen dari siklus hidup aplikasi. Namun, pada awalnya mungkin masuk akal untuk meletakkan semua konstruksi bersama dalam satu repositori.

Juga, pindahkan paket ke repositori mereka sendiri ketika tim yang berbeda sedang mengerjakannya. Ini membantu menegakkan kontrol akses.

Untuk menggunakan paket di seluruh batas repositori, Anda memerlukan repositori paket pribadi—mirip dengan,, atau Maven Central NPM PyPi, tetapi internal organisasi Anda. Anda juga memerlukan proses rilis yang membangun, menguji, dan menerbitkan paket ke repositori paket pribadi. CodeArtifactdapat meng-host paket untuk sebagian besar bahasa pemrograman populer.

Dependensi pada paket dalam repositori paket dikelola oleh manajer paket bahasa Anda, seperti NPM untuk atau aplikasi. TypeScript JavaScript Manajer paket Anda membantu memastikan bahwa build dapat diulang. Ini dilakukan dengan merekam versi spesifik dari setiap paket yang bergantung pada aplikasi Anda. Ini juga memungkinkan Anda memutakhirkan dependensi tersebut secara terkontrol.

Paket bersama membutuhkan strategi pengujian yang berbeda. Untuk satu aplikasi, mungkin cukup baik untuk menyebarkan aplikasi ke lingkungan pengujian dan mengonfirmasi bahwa itu masih berfungsi. Tetapi paket bersama harus diuji secara independen dari aplikasi yang dikonsumsi, seolah-olah mereka dirilis ke publik. (Organisasi Anda mungkin memilih untuk benar-benar merilis beberapa paket bersama ke publik.)

Perlu diingat bahwa konstruksi bisa sewenang-wenang sederhana atau kompleks. A Bucket adalah konstruksi, tetapi CameraShopWebsite bisa menjadi konstruksi juga.

Infrastruktur dan kode runtime hidup dalam paket yang sama

Selain menghasilkan AWS CloudFormation template untuk menerapkan infrastruktur, mereka AWS CDK juga menggabungkan aset runtime seperti fungsi Lambda dan gambar Docker dan menerapkannya di samping infrastruktur Anda. Ini memungkinkan untuk menggabungkan kode yang mendefinisikan infrastruktur Anda dan kode yang mengimplementasikan logika runtime Anda ke dalam satu konstruksi. Ini adalah praktik terbaik untuk melakukan ini. Kedua jenis kode ini tidak perlu tinggal di repositori terpisah atau bahkan dalam paket terpisah.

Untuk mengembangkan dua jenis kode bersama-sama, Anda dapat menggunakan konstruksi mandiri yang sepenuhnya menggambarkan sepotong fungsionalitas, termasuk infrastruktur dan logikanya. Dengan konstruksi mandiri, Anda dapat menguji dua jenis kode secara terpisah, berbagi dan menggunakan kembali kode di seluruh proyek, dan versi semua kode yang disinkronkan.

Membangun praktik terbaik

Bagian ini berisi praktik terbaik untuk mengembangkan konstruksi. Konstruksi adalah modul yang dapat digunakan kembali dan dapat dikomposisi yang merangkum sumber daya. Mereka adalah blok bangunan AWS CDK aplikasi.

Model dengan konstruksi, gunakan dengan tumpukan

Tumpukan adalah unit penerapan: semua yang ada di tumpukan dikerahkan bersama. Jadi saat membangun unit logis tingkat tinggi aplikasi Anda dari beberapa AWS sumber daya, wakili setiap unit logis sebagai Construct, bukan sebagai. Stack Gunakan tumpukan hanya untuk menjelaskan bagaimana konstruksi Anda harus disusun dan dihubungkan untuk berbagai skenario penerapan Anda.

Misalnya, jika salah satu unit logis Anda adalah situs web, konstruksi yang menyusunnya (seperti bucket Amazon S3, GatewayAPI, fungsi Lambda, atau tabel RDS Amazon) harus disusun menjadi satu konstruksi tingkat tinggi. Kemudian konstruksi itu harus dipakai dalam satu atau lebih tumpukan untuk penerapan.

Dengan menggunakan konstruksi untuk bangunan dan tumpukan untuk digunakan, Anda meningkatkan potensi penggunaan kembali infrastruktur Anda dan memberi diri Anda lebih banyak fleksibilitas dalam cara penerapannya.

Konfigurasikan dengan properti dan metode, bukan variabel lingkungan

Pencarian variabel lingkungan di dalam konstruksi dan tumpukan adalah anti-pola yang umum. Baik konstruksi dan tumpukan harus menerima objek properti untuk memungkinkan konfigurasi penuh sepenuhnya dalam kode. Melakukan sebaliknya memperkenalkan ketergantungan pada mesin tempat kode akan berjalan, yang menciptakan lebih banyak informasi konfigurasi yang harus Anda lacak dan kelola.

Secara umum, pencarian variabel lingkungan harus dibatasi pada tingkat atas aplikasi. AWS CDK Mereka juga harus digunakan untuk menyampaikan informasi yang diperlukan untuk berjalan di lingkungan pengembangan. Untuk informasi selengkapnya, lihat Lingkungan untuk AWS CDK.

Unit menguji infrastruktur Anda

Untuk menjalankan rangkaian lengkap pengujian unit secara konsisten pada waktu pembuatan di semua lingkungan, hindari pencarian jaringan selama sintesis dan modelkan semua tahapan produksi Anda dalam kode. (Praktik terbaik ini dibahas nanti.) Jika ada komit tunggal yang selalu menghasilkan template yang dihasilkan sama, Anda dapat mempercayai pengujian unit yang Anda tulis untuk mengonfirmasi bahwa templat yang dihasilkan terlihat seperti yang Anda harapkan. Untuk informasi selengkapnya, lihat AWS CDK Aplikasi uji.

Jangan ubah ID logis sumber daya stateful

Mengubah ID logis sumber daya menghasilkan sumber daya diganti dengan yang baru pada penerapan berikutnya. Untuk sumber daya stateful seperti database dan bucket S3, atau infrastruktur persisten seperti AmazonVPC, ini jarang yang Anda inginkan. Hati-hati tentang refactoring AWS CDK kode Anda yang dapat menyebabkan ID berubah. Tulis pengujian unit yang menyatakan bahwa logika IDs sumber daya stateful Anda tetap statis. ID logis berasal dari yang id Anda tentukan saat Anda membuat instance konstruksi, dan posisi konstruksi di pohon konstruksi. Untuk informasi selengkapnya, lihat Logis IDs.

Konstruksi tidak cukup untuk kepatuhan

Banyak pelanggan perusahaan menulis pembungkus mereka sendiri untuk konstruksi L2 (konstruksi “dikurasi” yang mewakili AWS sumber daya individu dengan default waras bawaan dan praktik terbaik). Pembungkus ini menerapkan praktik terbaik keamanan seperti enkripsi statis dan kebijakan khususIAM. Misalnya, Anda dapat membuat MyCompanyBucket yang kemudian Anda gunakan dalam aplikasi Anda sebagai pengganti konstruksi Amazon S3 Bucket biasa. Pola ini berguna untuk memunculkan panduan keamanan di awal siklus hidup pengembangan perangkat lunak, tetapi jangan mengandalkannya sebagai satu-satunya sarana penegakan hukum.

Sebagai gantinya, gunakan AWS fitur seperti kebijakan kontrol layanan dan batasan izin untuk menegakkan pagar keamanan Anda di tingkat organisasi. Gunakan Aspek dan AWS CDK atau alat seperti CloudFormation Guard untuk membuat pernyataan tentang properti keamanan elemen infrastruktur sebelum penerapan. Gunakan AWS CDK untuk apa yang terbaik.

Terakhir, perlu diingat bahwa menulis konstruksi “L2+” Anda sendiri dapat mencegah pengembang Anda memanfaatkan AWS CDK paket seperti Konstruksi AWS Solusi atau konstruksi pihak ketiga dari Construct Hub. Paket-paket ini biasanya dibangun di atas AWS CDK konstruksi standar dan tidak akan dapat menggunakan konstruksi pembungkus Anda.

Praktik terbaik aplikasi

Pada bagian ini kita membahas cara menulis AWS CDK aplikasi Anda, menggabungkan konstruksi untuk menentukan bagaimana AWS sumber daya Anda terhubung.

Buat keputusan pada waktu sintesis

Meskipun AWS CloudFormation memungkinkan Anda membuat keputusan pada waktu penerapan (menggunakanConditions,{ Fn::If }, danParameters), dan AWS CDK memberi Anda beberapa akses ke mekanisme ini, sebaiknya jangan menggunakannya. Jenis nilai yang dapat Anda gunakan dan jenis operasi yang dapat Anda lakukan pada mereka terbatas dibandingkan dengan apa yang tersedia dalam bahasa pemrograman tujuan umum.

Sebagai gantinya, cobalah untuk membuat semua keputusan, seperti konstruksi mana yang akan dibuat, dalam AWS CDK aplikasi Anda dengan menggunakan if pernyataan bahasa pemrograman Anda dan fitur lainnya. Misalnya, CDK idiom umum, mengulangi daftar dan membuat instance konstruksi dengan nilai dari setiap item dalam daftar, tidak mungkin menggunakan ekspresi. AWS CloudFormation

Perlakukan AWS CloudFormation sebagai detail implementasi yang AWS CDK digunakan untuk penerapan cloud yang kuat, bukan sebagai target bahasa. Anda tidak menulis AWS CloudFormation template dalam TypeScript atau Python, Anda menulis CDK kode yang kebetulan digunakan CloudFormation untuk penerapan.

Gunakan nama sumber daya yang dihasilkan, bukan nama fisik

Nama adalah sumber daya yang berharga. Setiap nama hanya dapat digunakan satu kali. Oleh karena itu, jika Anda membuat hardcode nama tabel atau nama bucket ke dalam infrastruktur dan aplikasi Anda, Anda tidak dapat menerapkan infrastruktur itu dua kali di akun yang sama. (Nama yang kita bicarakan di sini adalah nama yang ditentukan oleh, misalnya, bucketName properti pada konstruksi bucket Amazon S3.)

Yang lebih buruk, Anda tidak dapat membuat perubahan pada sumber daya yang mengharuskannya untuk diganti. Jika properti hanya dapat disetel pada pembuatan sumber daya, seperti tabel Amazon DynamoDB, maka properti tersebut tidak dapat diubah. KeySchema Mengubah properti ini membutuhkan sumber daya baru. Namun, sumber daya baru harus memiliki nama yang sama untuk menjadi pengganti yang sebenarnya. Tetapi tidak dapat memiliki nama yang sama sementara sumber daya yang ada masih menggunakan nama itu.

Pendekatan yang lebih baik adalah menentukan sesedikit mungkin nama. Jika Anda menghilangkan nama sumber daya, itu AWS CDK akan menghasilkannya untuk Anda dengan cara yang tidak akan menimbulkan masalah. Misalkan Anda memiliki tabel sebagai sumber daya. Anda kemudian dapat meneruskan nama tabel yang dihasilkan sebagai variabel lingkungan ke dalam AWS Lambda fungsi Anda. Dalam AWS CDK aplikasi Anda, Anda dapat mereferensikan nama tabel sebagaitable.tableName. Atau, Anda dapat membuat file konfigurasi pada EC2 instance Amazon Anda saat startup, atau menulis nama tabel yang sebenarnya ke AWS Systems Manager Parameter Store sehingga aplikasi Anda dapat membacanya dari sana.

Jika tempat yang Anda butuhkan adalah AWS CDK tumpukan lain, itu bahkan lebih mudah. Misalkan satu tumpukan mendefinisikan sumber daya dan tumpukan lain perlu menggunakannya, hal berikut ini berlaku:

Menentukan kebijakan penghapusan dan penyimpanan log

AWS CDK Upaya untuk mencegah Anda kehilangan data dengan default ke kebijakan yang mempertahankan semua yang Anda buat. Misalnya, kebijakan penghapusan default pada sumber daya yang berisi data (seperti bucket Amazon S3 dan tabel database) tidak menghapus sumber daya saat dihapus dari tumpukan. Sebaliknya, sumber daya menjadi yatim piatu dari tumpukan. Demikian pula, defaultnya adalah mempertahankan semua log selamanya. CDK Dalam lingkungan produksi, default ini dapat dengan cepat menghasilkan penyimpanan sejumlah besar data yang sebenarnya tidak Anda butuhkan, dan tagihan yang sesuai. AWS

Pertimbangkan dengan cermat apa yang Anda inginkan kebijakan ini untuk setiap sumber daya produksi dan tentukan sesuai dengan itu. Gunakan Aspek dan AWS CDK untuk memvalidasi kebijakan penghapusan dan pencatatan di tumpukan Anda.

Pisahkan aplikasi Anda menjadi beberapa tumpukan seperti yang ditentukan oleh persyaratan penerapan

Tidak ada aturan keras dan cepat untuk berapa banyak tumpukan yang dibutuhkan aplikasi Anda. Anda biasanya akan mendasarkan keputusan pada pola penerapan Anda. Ingatlah pedoman berikut:

Berkomitmen cdk.context.json untuk menghindari perilaku non-deterministik

Determinisme adalah kunci keberhasilan AWS CDK penerapan. AWS CDK Aplikasi pada dasarnya harus memiliki hasil yang sama setiap kali diterapkan ke lingkungan tertentu.

Karena AWS CDK aplikasi Anda ditulis dalam bahasa pemrograman tujuan umum, aplikasi dapat mengeksekusi kode arbitrer, menggunakan pustaka arbitrer, dan membuat panggilan jaringan arbitrer. Misalnya, Anda dapat menggunakan an AWS SDK untuk mengambil beberapa informasi dari AWS akun Anda saat mensintesis aplikasi Anda. Ketahuilah bahwa melakukan hal itu akan menghasilkan persyaratan pengaturan kredensyal tambahan, peningkatan latensi, dan kemungkinan, betapapun kecilnya, kegagalan setiap kali Anda menjalankan. cdk synth

Jangan pernah memodifikasi AWS akun atau sumber daya Anda selama sintesis. Mensintesis aplikasi seharusnya tidak memiliki efek samping. Perubahan pada infrastruktur Anda harus terjadi hanya dalam fase penerapan, setelah AWS CloudFormation template dibuat. Dengan cara ini, jika ada masalah, secara otomatis AWS CloudFormation dapat memutar kembali perubahan. Untuk membuat perubahan yang tidak dapat dengan mudah dibuat dalam AWS CDK kerangka kerja, gunakan sumber daya khusus untuk mengeksekusi kode arbitrer pada waktu penerapan.

Bahkan panggilan hanya-baca yang ketat belum tentu aman. Pertimbangkan apa yang terjadi jika nilai yang dikembalikan oleh panggilan jaringan berubah. Bagian apa dari infrastruktur Anda yang akan berdampak? Apa yang akan terjadi pada sumber daya yang sudah digunakan? Berikut adalah dua contoh situasi di mana perubahan mendadak dalam nilai dapat menyebabkan masalah.

Situasi ini dapat merusak karena perubahan AWS sisi mungkin terjadi setelah berbulan-bulan atau bertahun-tahun penerapan yang berhasil. Tiba-tiba penerapan Anda gagal “tanpa alasan” dan Anda sudah lama lupa apa yang Anda lakukan dan mengapa.

Untungnya, AWS CDK termasuk mekanisme yang disebut penyedia konteks untuk merekam snapshot nilai non-deterministik. Hal ini memungkinkan operasi sintesis future untuk menghasilkan template yang persis sama seperti yang mereka lakukan saat pertama kali digunakan. Satu-satunya perubahan dalam template baru adalah perubahan yang Anda buat dalam kode Anda. Saat Anda menggunakan .fromLookup() metode konstruksi, hasil panggilan di-cache. cdk.context.json Anda harus melakukan ini ke kontrol versi bersama dengan kode lainnya untuk memastikan bahwa eksekusi CDK aplikasi Anda di masa mendatang menggunakan nilai yang sama. CDKToolkit menyertakan perintah untuk mengelola cache konteks, sehingga Anda dapat menyegarkan entri tertentu saat diperlukan. Untuk informasi selengkapnya, lihat Nilai konteks dan AWS CDK.

Jika Anda memerlukan beberapa nilai (dari AWS atau di tempat lain) yang tidak ada penyedia CDK konteks asli, kami sarankan untuk menulis skrip terpisah. Skrip harus mengambil nilai dan menuliskannya ke file, lalu membaca file itu di CDK aplikasi Anda. Jalankan skrip hanya jika Anda ingin menyegarkan nilai yang disimpan, bukan sebagai bagian dari proses pembuatan reguler Anda.

Biarkan AWS CDK mengelola peran dan kelompok keamanan

Dengan metode grant() kenyamanan AWS CDK pustaka konstruksi, Anda dapat membuat AWS Identity and Access Management peran yang memberikan akses ke satu sumber daya dengan sumber daya lainnya menggunakan izin cakupan minimal. Misalnya, pertimbangkan baris seperti berikut ini:

amzn-s3-demo-bucket.grantRead(myLambda)

Baris tunggal ini menambahkan kebijakan ke peran fungsi Lambda (yang juga dibuat untuk Anda). Peran itu dan kebijakannya lebih dari selusin baris CloudFormation yang tidak perlu Anda tulis. Hanya AWS CDK memberikan izin minimal yang diperlukan agar fungsi dapat dibaca dari bucket.

Jika Anda mengharuskan pengembang untuk selalu menggunakan peran yang telah ditentukan sebelumnya yang dibuat oleh tim keamanan, AWS CDK pengkodean menjadi jauh lebih rumit. Tim Anda bisa kehilangan banyak fleksibilitas dalam cara mereka merancang aplikasi mereka. Alternatif yang lebih baik adalah menggunakan kebijakan kontrol layanan dan batas izin untuk memastikan bahwa pengembang tetap berada di dalam pagar pembatas.

Model semua tahapan produksi dalam kode

Dalam AWS CloudFormation skenario tradisional, tujuan Anda adalah menghasilkan artefak tunggal yang diparameterisasi sehingga dapat digunakan ke berbagai lingkungan target setelah menerapkan nilai konfigurasi khusus untuk lingkungan tersebut. DalamCDK, Anda dapat, dan harus, membangun konfigurasi itu ke dalam kode sumber Anda. Buat tumpukan untuk lingkungan produksi Anda, dan buat tumpukan terpisah untuk setiap tahapan Anda yang lain. Kemudian, letakkan nilai konfigurasi untuk setiap tumpukan dalam kode. Gunakan layanan seperti Secrets Manager dan Systems Manager Parameter Store untuk nilai sensitif yang tidak ingin Anda periksa ke kontrol sumber, menggunakan nama atau ARNs sumber daya tersebut.

Saat Anda mensintesis aplikasi Anda, rakitan cloud yang dibuat di cdk.out folder berisi templat terpisah untuk setiap lingkungan. Seluruh bangunan Anda bersifat deterministik. Tidak ada out-of-band perubahan pada aplikasi Anda, dan setiap komit yang diberikan selalu menghasilkan AWS CloudFormation template yang sama persis dan aset yang menyertainya. Ini membuat pengujian unit jauh lebih andal.

Ukur semuanya

Mencapai tujuan penyebaran berkelanjutan penuh, tanpa campur tangan manusia, membutuhkan otomatisasi tingkat tinggi. Otomatisasi itu hanya dimungkinkan dengan pemantauan dalam jumlah ekstensif. Untuk mengukur semua aspek sumber daya yang Anda gunakan, buat metrik, alarm, dan dasbor. Jangan berhenti mengukur hal-hal seperti CPU penggunaan dan ruang disk. Juga catat metrik bisnis Anda, dan gunakan pengukuran tersebut untuk mengotomatiskan keputusan penerapan seperti rollback. Sebagian besar konstruksi L2 AWS CDK memiliki metode kenyamanan untuk membantu Anda membuat metrik, seperti metricUserErrors() metode pada kelas DynamoDB.table.