Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Penilaian aplikasi yang diprioritaskan Salah satu hasil utama dari tahap sebelumnya, [penemuan portofolio dan perencanaan awal](portfolio-discovery-initial-planning.md), adalah [memprioritaskan subset aplikasi untuk penilaian](prioritization-and-migration-strategy.md#prioritizing-applications) terperinci. Bagian ini mengeksplorasi penilaian rinci aplikasi. Melihat detail beberapa aplikasi sejak dini akan mendorong akselerasi. Proses penilaian dan desain arsitektur calon memunculkan pemblokir potensial dan mengklarifikasi tugas-tugas penting yang merupakan prekursor migrasi dengan cakupan yang lebih besar. Tugas-tugas ini termasuk mengumpulkan persyaratan untuk membangun AWS fondasi, seperti landing zone on AWS, atau untuk memperluas dan memvalidasi landing zone yang ada. Penilaian ini juga merupakan waktu untuk mempertimbangkan langkah-langkah dan strategi migrasi. Hasil utama dari tahap ini adalah sebagai berikut: + Daftar aplikasi yang diprioritaskan yang divalidasi + Arsitektur keadaan saat ini yang didokumentasikan + Arsitektur target awal yang terdokumentasi dan strategi migrasi untuk kandidat migrasi + Pola dan perkakas migrasi yang teridentifikasi + Persyaratan platform yang terdokumentasi (keamanan, AWS infrastruktur, dan operasi) + Pertimbangan cutover terdokumentasi untuk perencanaan migrasi + Perkiraan laju AWS lari # Memahami persyaratan data penilaian terperinci Tabel berikut menjelaskan informasi yang diperlukan untuk mendapatkan tampilan portofolio lengkap dari aplikasi dalam migrasi dan infrastruktur terkait. Tabel menggunakan singkatan berikut: + R, untuk yang dibutuhkan + O, untuk opsional + N/A, karena tidak berlaku **Aplikasi** | **Nama atribut** | **Deskripsi** | **Penemuan, desain, dan strategi migrasi** | **Perkiraan laju lari** | **Tingkat kesetiaan yang disarankan (minimum)** | | --- |--- |--- |--- |--- | | Pengenal unik | Misalnya, ID aplikasi. Biasanya tersedia pada inventaris internal dan sistem kontrol yang ada CMDBs atau lainnya. Pertimbangkan untuk membuat unik IDs setiap kali ini tidak didefinisikan dalam organisasi Anda. | R | O | Tinggi | | Nama aplikasi | Nama yang dengannya aplikasi ini diketahui organisasi Anda. Sertakan vendor komersial off-the-shelf (COTS) dan nama produk jika berlaku. | R | R | Tinggi | | Apakah COTS? | Ya atau Tidak. Apakah ini aplikasi komersial atau pengembangan internal | R | R | Tinggi | | Produk dan versi COTS | Nama dan versi produk perangkat lunak komersial | R | R | Tinggi | | Deskripsi | Fungsi dan konteks aplikasi utama | R | O | Tinggi | | Kekritisan | Misalnya, aplikasi strategis atau menghasilkan pendapatan, atau mendukung fungsi kritis | R | O | Tinggi | | Tipe | Misalnya, database, manajemen hubungan pelanggan (CRM), aplikasi web, multimedia, layanan bersama TI | R | O | Tinggi | | Lingkungan | Misalnya, produksi, pra-produksi, pengembangan, pengujian, kotak pasir | R | R | Tinggi | | Kepatuhan dan peraturan | Kerangka kerja yang berlaku untuk beban kerja (misalnya, HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) dan persyaratan peraturan | R | O | Tinggi | | Dependensi | Dependensi hulu dan hilir ke aplikasi atau layanan internal dan eksternal | R | N/A | Tinggi | | Pemetaan infrastruktur | Pemetaan ke aset and/or virtual fisik yang membentuk aplikasi | R | R | Tinggi | | Lisensi | Jenis lisensi perangkat lunak komoditas (misalnya, Microsoft SQL Server Enterprise) | R | R | Tinggi | | Biaya | Biaya untuk lisensi perangkat lunak, operasi perangkat lunak, dan pemeliharaan | N/A | R | Tinggi medium | | Unit bisnis | Misalnya, pemasaran, keuangan, penjualan | R | O | Tinggi | | Detail pemilik | Informasi kontak untuk pemilik aplikasi | R | O | Tinggi | | Jenis arsitektur | Misalnya, aplikasi web, 2-tier, 3-tier, microservices, service-oriented architecture (SOA) | R | R | Tinggi | | Tujuan titik pemulihan (RPO), tujuan waktu pemulihan (RTO), dan/service-level agreement (SLA) | Atribut manajemen layanan saat ini | R | R | Tinggi | | Aplikasi yang menghasilkan pendapatan atau aplikasi strategis bisnis? | Ya, jika aplikasi secara langsung atau tidak langsung mempengaruhi pendapatan perusahaan atau dianggap strategis oleh bisnis. | R | O | Tinggi medium | | Jumlah pengguna (bersamaan) | Misalnya, pengguna internal, atau eksternal atau, pengguna/pelanggan and/or eksternal internal | R | R | Tinggi medium | | Lokasi pengguna | Asal sesi pengguna | R | R | Tinggi medium | | Risiko dan masalah | Risiko dan masalah yang diketahui | R | O | Tinggi medium | | Pertimbangan migrasi | Informasi tambahan apa pun yang mungkin relevan untuk migrasi | R | R | Tinggi medium | | Strategi migrasi | Misalnya, salah satu dari AWS 6 Rs untuk migrasi | R | R | Tinggi medium | | Rincian basis data | Misalnya, partisi, enkripsi, replikasi, ekstensi, dukungan Secure Sockets Layer (SSL) | R | R | Tinggi | | Tim Support | Misalnya, nama tim operasi aplikasi | R | O | Tinggi medium | | Solusi pemantauan | Produk yang digunakan untuk memantau aplikasi ini | R | O | Tinggi medium | | Persyaratan Backup | Jadwal pencadangan yang diperlukan di AWS | R | R | Tinggi medium | | Informasi DR | Misalnya, komponen pemulihan bencana untuk aplikasi ini | R | R | Tinggi medium | | AWS Persyaratan target | Misalnya, komponen, penempatan akun, jaringan, keamanan | R | R | Tinggi | **Infrastruktur** | | | | | | | --- |--- |--- |--- |--- | | **Nama Atribut** | **Deskripsi** | **Penemuan, desain, dan strategi migrasi** | **Perkiraan laju lari** | **Tingkat kesetiaan yang disarankan (minimum)** | | Pengenal unik | Misalnya, ID server. Biasanya tersedia pada inventaris internal dan sistem kontrol yang ada CMDBs atau lainnya. Pertimbangkan untuk membuat unik IDs setiap kali ini tidak didefinisikan dalam organisasi Anda. | R | O | Tinggi | | Nama jaringan | Nama aset dalam jaringan (misalnya, nama host) | R | O | Tinggi | | Nama DNS (nama domain yang sepenuhnya memenuhi syarat, atau FQDN) | Nama DNS | O | O | Tinggi medium | | Alamat IP dan netmask | Alamat IP and/or publik internal | R | R | Tinggi | | Jenis aset | Misalnya, server fisik atau virtual, hypervisor, wadah, perangkat, contoh database | R | R | Tinggi | | Nama produk | Vendor komersial dan nama produk (mis. VMware ESXi, IBM Power Systems, Exadata) | R | R | Tinggi | | Sistem operasi | Misalnya, REHL 8, Windows Server 2019, AIX 6.1 | R | R | Tinggi | | Konfigurasi | CPU yang dialokasikan, jumlah inti, utas per inti, total memori, penyimpanan, kartu jaringan | R | R | Tinggi | | Pemanfaatan | CPU, memori, dan puncak penyimpanan dan rata-rata. Database instance throughput. | R | R | Tinggi | | Lisensi | Jenis lisensi komoditas (misalnya, Standar RHEL) | R | R | Tinggi | | Apakah infrastruktur bersama? | Ya atau Tidak untuk menunjukkan layanan infrastruktur yang menyediakan layanan bersama seperti penyedia otentikasi, sistem pemantauan, layanan cadangan, dan layanan serupa | R | O | Tinggi | | Pemetaan aplikasi | Aplikasi atau komponen aplikasi yang berjalan di infrastruktur ini | R | O | Tinggi | | Data komunikasi | Misalnya, server ke server pada tingkat proses | R | N/A | Tinggi medium | | AWS Persyaratan target | Misalnya, jenis contoh, akun, subnet, grup keamanan, perutean | R | R | Tinggi | | Strategi, pola, dan alat migrasi | Misalnya, salah satu dari 6 Rs untuk migrasi, pola teknis tertentu, alat migrasi | R | O | Tinggi | | Risiko dan masalah | Risiko dan masalah yang diketahui | R | O | Tinggi medium | # Penilaian aplikasi terperinci Tujuan dari penilaian aplikasi terperinci adalah pemahaman lengkap tentang aplikasi yang ditargetkan dan infrastruktur terkait (komputasi, penyimpanan, dan jaringan). Data kesetiaan tinggi diperlukan untuk menghindari jebakan. Misalnya, adalah umum bagi organisasi untuk berasumsi bahwa mereka sepenuhnya memahami aplikasi. Ini wajar, dan itu benar dalam banyak kasus. Namun, untuk meminimalkan risiko terhadap bisnis, penting untuk memvalidasi pengetahuan kelembagaan dan dokumentasi statis dengan memperoleh data terprogram sebanyak mungkin. Ini akan menangani proses penemuan yang berat. Anda dapat fokus pada elemen data yang berasal dari sumber alternatif, seperti informasi spesifik bisnis, peta jalan strategis, dan lain-lain. Kuncinya adalah menghindari perubahan menit terakhir selama dan setelah migrasi. Misalnya, saat bermigrasi, penting untuk menghindari perubahan berdasarkan dependensi tak dikenal yang mungkin memerlukan penyertaan server ke dalam gelombang migrasi yang sedang berlangsung. Tak lama setelah migrasi, penting untuk menghindari perubahan berdasarkan persyaratan platform terkait untuk mengizinkan lalu lintas atau menyebarkan layanan tambahan. Perubahan yang tidak direncanakan ini meningkatkan risiko masalah keamanan dan operasional. Kami sangat merekomendasikan penggunaan alat penemuan terprogram untuk memvalidasi pola lalu lintas dan dependensi saat melakukan penilaian aplikasi terperinci. Di awal penilaian, Anda harus mengidentifikasi pemangku kepentingan aplikasi. Ini biasanya sebagai berikut: + Unit bisnis memimpin + Pemilik aplikasi + Arsitek + Operasi dan dukungan + Tim pemberdayaan cloud + Tim platform tertentu seperti komputasi, penyimpanan, dan jaringan Ada dua pendekatan untuk penemuan terperinci. Penemuan top-down dimulai dengan aplikasi, atau bahkan dengan pengguna, dan berjalan sampai ke infrastruktur. Ini adalah pendekatan yang disarankan ketika identifikasi aplikasi jelas. Sebaliknya, penemuan bottom-up dimulai dengan infrastruktur dan berjalan sampai ke aplikasi atau layanan dan penggunanya. Pendekatan ini berguna ketika program migrasi didorong oleh tim infrastruktur dan saat application-to-infrastructure pemetaan tidak jelas. Secara umum, Anda cenderung menggunakan kombinasi keduanya. Untuk menyelam jauh ke dalam aplikasi, diagram arsitektur yang ada adalah awal yang baik. Jika ini tidak tersedia, buat satu berdasarkan pengetahuan saat ini. Jangan meremehkan pentingnya tugas ini, bahkan untuk rehost sederhana atau relokasi strategi migrasi. Merencanakan diagram arsitektur membantu Anda mengidentifikasi inefisiensi yang dapat dengan cepat diatasi dengan perubahan kecil saat berada di cloud. Bergantung pada apakah Anda melakukan pendekatan top-down atau bottom-up, diagram awal akan memplot komponen aplikasi dan layanan atau komponen infrastruktur seperti server dan penyeimbang beban. Setelah komponen dan antarmuka utama diidentifikasi, validasi dengan data terprogram dari alat penemuan dan alat pemantauan kinerja aplikasi. Alat harus mendukung analisis ketergantungan dan memberikan informasi komunikasi antar komponen. Setiap komponen yang membentuk aplikasi ini harus diidentifikasi. Selanjutnya, dokumentasikan dependensi ke aplikasi dan layanan lain, baik internal maupun eksternal. Dengan tidak adanya perkakas untuk memvalidasi dependensi dan pemetaan, diperlukan pendekatan manual. Misalnya, Anda dapat masuk ke komponen infrastruktur dan menjalankan skrip untuk mengumpulkan informasi komunikasi seperti port terbuka dan koneksi yang sudah mapan. Demikian juga, Anda dapat mengidentifikasi proses yang berjalan dan perangkat lunak yang diinstal. Jangan meremehkan upaya yang diperlukan untuk penemuan manual. Perkakas terprogram dapat menangkap dan melaporkan sebagian besar dependensi dalam beberapa hari, kecuali yang terjadi pada interval yang lebih besar (biasanya persentase kecil). Penemuan manual dapat memakan waktu berminggu-minggu untuk mengumpulkan dan menggabungkan semua titik data, dan masih rentan terhadap kesalahan dan data yang hilang. Lanjutkan untuk mendapatkan informasi yang ditentukan di bagian [persyaratan data](understanding-detailed-assessment-data-requirements.md) untuk setiap aplikasi yang diprioritaskan dan infrastruktur yang dipetakan. Selanjutnya, gunakan kuesioner berikut untuk memandu Anda melalui proses penilaian terperinci. Bertemu dengan pemangku kepentingan yang teridentifikasi untuk mendiskusikan jawaban atas pertanyaan-pertanyaan ini. ## Umum + Apa tingkat kekritisan aplikasi ini? Apakah itu menghasilkan pendapatan? Apakah ini aplikasi bisnis-strategis atau mendukung bisnis? Apakah ini layanan infrastruktur inti yang dimiliki oleh sistem lain? + Apakah ada proyek transformasi yang sedang berlangsung untuk aplikasi ini? + Apakah ini aplikasi yang dihadapi secara internal atau eksternal? ## Arsitektur + Apa jenis arsitektur saat ini (misalnya, SOA, layanan mikro, monolit)? Berapa banyak tingkatan yang dimiliki arsitektur? Apakah itu digabungkan dengan erat atau digabungkan secara longgar? + Apa saja komponennya (misalnya, komputasi, database, penyimpanan jarak jauh, penyeimbang beban, layanan caching)? + Apa yang dimaksud dengan APIs? Jelaskan ini, termasuk nama API, operasi URLs, port, dan protokol. + Apa latensi maksimum yang ditoleransi antara komponen dan antara ini dan aplikasi atau layanan lainnya? ## Operasi + Di lokasi apa aplikasi ini beroperasi? + Siapa yang mengoperasikan aplikasi dan infrastruktur? Apakah ini dioperasikan oleh tim internal atau AWS Mitra? + Apa yang terjadi jika aplikasi ini turun? Siapa yang terpengaruh? Apa dampaknya? + Di mana pengguna atau pelanggan berada? Bagaimana mereka mengakses aplikasi? Berapa jumlah pengguna bersamaan? + Kapan penyegaran teknologi terakhir? Apakah penyegaran dijadwalkan di masa depan? Jika demikian, kapan? + Apa risiko dan masalah yang diketahui untuk aplikasi ini? Bagaimana sejarah pemadaman dan insiden tingkat keparahan sedang dan tingkat keparahan tinggi? + Apa siklus penggunaan (dalam jam kerja)? Apa zona waktu operasi? + Apa periode pembekuan perubahan? + Solusi apa yang digunakan untuk memantau aplikasi ini? ## Performa + Apa yang ditunjukkan oleh informasi kinerja yang dikumpulkan? Apakah penggunaan runcing atau konstan dan dapat diprediksi? Berapa kerangka waktu, interval, dan tanggal data kinerja yang tersedia? + Apakah ada pekerjaan batch terjadwal yang merupakan bagian dari atau berinteraksi dengan aplikasi ini? ## Siklus hidup perangkat lunak + Berapa tingkat perubahan saat ini (mingguan, bulanan, triwulanan, atau tahunan)? + Apa siklus hidup pengembangan (misalnya, pengujian, pengembangan, QA, UAT, pra-produksi, produksi)? + Apa metode penyebaran untuk aplikasi dan infrastruktur? + Apa itu perkakas penyebaran? + Apakah aplikasi atau infrastruktur ini menggunakan continuous integration (CI) /continuous delivery (CD)? Apa tingkat otomatisasi? Apa tugas manualnya? + Apa persyaratan perizinan untuk aplikasi dan infrastruktur? + Apa itu Service Level Agreement (SLA)? + Apa mekanisme pengujian saat ini? Apa tahapan tesnya? ## Migrasi + Apa pertimbangan migrasi? Pada titik ini, perhatikan pertimbangan apa pun saat memigrasikan aplikasi ini. Untuk penilaian yang lebih lengkap dan akurat, dapatkan jawaban atas pertanyaan ini dari berbagai pemangku kepentingan. Kemudian kontraskan pengetahuan dan pendapat mereka. ## Ketahanan + Apa metode pencadangan saat ini? Produk apa yang digunakan untuk cadangan? Apa jadwal pencadangan? Apa kebijakan retensi cadangan? + Apa tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO) saat ini? + Apakah aplikasi ini memiliki rencana pemulihan bencana (DR)? Jika demikian, apa solusi DR? + Kapan tes DR terakhir? ## Keamanan dan kepatuhan + Apa saja kerangka kepatuhan dan peraturan yang berlaku untuk aplikasi ini? Apa tanggal audit terakhir dan berikutnya? + Apakah aplikasi ini meng-host data sensitif? Apa klasifikasi datanya? + Apakah data dienkripsi saat transit atau diam, atau keduanya? Apa mekanisme enkripsi? + Apakah aplikasi ini menggunakan sertifikat SSL? Apa otoritas penerbit? + Apa metode otentikasi untuk pengguna, komponen, dan aplikasi dan layanan lainnya? ## Basis Data + Database apa yang digunakan aplikasi ini? + Berapa jumlah tipikal koneksi bersamaan ke database? Berapa jumlah minimum dan jumlah maksimum koneksi? + Apa metode koneksi (misalnya, JDBC, ODBC)? + Apakah string koneksi didokumentasikan? Jika demikian, di mana? + Apa skema database? + Apakah database menggunakan tipe data khusus? ## Dependensi + Apa ketergantungan antar komponen? Perhatikan dependensi apa pun yang tidak dapat diselesaikan dan yang memerlukan migrasi komponen bersama-sama. + Apakah komponen dibagi di seluruh lokasi? Apa konektivitas antara lokasi-lokasi ini (misalnya, WAN, VPN)? + Apa dependensi aplikasi ini ke aplikasi atau layanan lain? + Apa dependensi operasional? Misalnya, siklus pemeliharaan dan rilis seperti menambal jendela. # AWS desain aplikasi dan strategi migrasi Merancang dan mendokumentasikan keadaan masa depan aplikasi Anda adalah faktor keberhasilan migrasi utama. Sebaiknya buat desain untuk semua jenis strategi migrasi, tidak peduli seberapa sederhana atau kompleksnya. Membuat desain akan memunculkan potensi pemblokir, dependensi, dan peluang untuk mengoptimalkan aplikasi bahkan dalam kasus di mana arsitektur tidak diharapkan berubah. Kami juga merekomendasikan untuk mendekati status aplikasi masa depan AWS dengan lensa strategi migrasi. Pada tahap ini, pastikan Anda menentukan seperti apa tampilan aplikasi AWS sebagai hasil dari migrasi ini. Desain yang dihasilkan akan berfungsi sebagai dasar untuk evolusi lebih lanjut setelah migrasi. Daftar berikut berisi sumber daya untuk membantu proses desain: + [AWS Architecture Center](https://aws.amazon.com/architecture/) menggabungkan alat dan panduan, seperti AWS Well-Architected Framework. Selain itu, ia menyediakan arsitektur referensi yang dapat Anda gunakan untuk aplikasi Anda. + [Amazon Builders' Library](https://aws.amazon.com/builders-library/) berisi beberapa sumber tentang bagaimana Amazon membangun dan mengoperasikan perangkat lunak. + [AWS Solutions Library](https://aws.amazon.com/solutions/) menawarkan koleksi solusi berbasis cloud, diperiksa oleh AWS, untuk puluhan masalah teknis dan bisnis. Ini mencakup banyak koleksi arsitektur referensi. + [AWS Panduan Preskriptif](https://aws.amazon.com/prescriptive-guidance/) menyediakan strategi, panduan, dan pola yang membantu proses desain dan praktik terbaik migrasi. + [AWS Documentation](https://docs.aws.amazon.com/)berisi informasi tentang AWS layanan, termasuk Panduan Pengguna dan Referensi API. + [Getting Started Resource Center](https://aws.amazon.com/getting-started/) menyediakan beberapa tutorial langsung dan penyelaman mendalam untuk mempelajari dasar-dasarnya sehingga Anda dapat mulai membangun. AWS Tergantung di mana Anda berada dalam perjalanan cloud, AWS yayasan mungkin sudah ada. AWS Yayasan ini meliputi: + Wilayah AWS telah diidentifikasi. + Akun telah dibuat atau dapat diperoleh sesuai permintaan. + Jaringan umum telah diimplementasikan. + AWS Layanan dasar telah digunakan di dalam akun. Sebaliknya, Anda mungkin berada di awal proses, dan AWS fondasi belum didirikan. Kurangnya fondasi yang mapan dapat membatasi ruang lingkup desain aplikasi Anda atau memerlukan pekerjaan lebih lanjut untuk mendefinisikannya. Jika ini masalahnya, kami sarankan untuk mendefinisikan dan mengimplementasikan desain dasar dari landing zone secara paralel dengan pekerjaan desain aplikasi. Desain aplikasi membantu mengidentifikasi persyaratan seperti Akun AWS struktur, jaringan, virtual private cloud (VPCs), rentang Classless Inter-Domain Routing (CIDR), layanan bersama, keamanan, dan operasi cloud. [AWS Control Tower](https://aws.amazon.com/controltower/)menyediakan cara termudah untuk mengatur dan mengatur AWS lingkungan multi-akun yang aman, yang disebut landing zone. AWS Control Tower membuat landing zone Anda menggunakan AWS Organizations, yang menyediakan pengelolaan dan tata kelola akun yang berkelanjutan serta implementasi pengalaman berbasis praktik AWS terbaik bekerja dengan ribuan pelanggan saat mereka pindah ke cloud. ## Aplikasi future state Mulailah dengan menetapkan strategi migrasi awal untuk aplikasi ini. Pada titik ini, strategi dianggap awal karena dapat berubah sebagai bagian dari desain negara masa depan, yang dapat mengungkap potensi keterbatasan. Untuk memvalidasi asumsi awal, lihat pohon [keputusan 6 Rs](prioritization-and-migration-strategy.md#migration-r-type). Juga, dokumentasikan fase migrasi potensial. Misalnya, apakah aplikasi ini akan dimigrasikan dalam satu acara (semua komponen dimigrasikan secara bersamaan)? Atau apakah ini migrasi bertahap (beberapa komponen dimigrasikan nanti)? Perhatikan bahwa strategi migrasi untuk aplikasi tertentu mungkin tidak unik. Ini karena beberapa tipe R dapat digunakan untuk memigrasikan komponen aplikasi. Misalnya, pendekatan awal bisa mengangkat dan menggeser aplikasi tanpa perubahan. Namun, komponen aplikasi mungkin berada di aset infrastruktur yang berbeda yang mungkin memerlukan perawatan yang berbeda. Misalnya, aplikasi terdiri dari tiga komponen, masing-masing berjalan di server terpisah, dan salah satu server menjalankan sistem operasi lama yang tidak didukung di cloud. Komponen itu akan memerlukan pendekatan replatform, sementara dua komponen lainnya, berjalan dalam versi server yang didukung, dapat dihosting ulang. Ini adalah kunci untuk menetapkan strategi migrasi ke setiap komponen aplikasi dan infrastruktur terkait yang sedang dimigrasikan. Selanjutnya, dokumentasikan konteks dan masalah, dan tautkan artefak yang ada yang menentukan status saat ini: + Mengapa aplikasi ini dimigrasikan? + Apa saja perubahan yang diusulkan? + Apa manfaatnya? + Apakah ada risiko atau pemblokir utama? + Apa kerugian saat ini? + Apa yang ada di ruang lingkup dan di luar ruang lingkup? ## Pengulangan Sepanjang pekerjaan desain, pertimbangkan bagaimana solusi dan arsitektur untuk aplikasi ini dapat digunakan kembali untuk aplikasi lain. Bisakah solusi ini digeneralisasi? ## Persyaratan Dokumentasikan persyaratan fungsional dan nonfungsional untuk aplikasi ini, termasuk keamanan. Ini termasuk persyaratan status saat ini dan masa depan, tergantung pada strategi migrasi yang dipilih. Gunakan informasi yang dikumpulkan selama penilaian aplikasi terperinci untuk memandu proses ini. ## Arsitektur yang akan datang Jelaskan arsitektur future untuk aplikasi ini. Pertimbangkan untuk membuat templat diagram yang dapat digunakan kembali yang berisi blok bangunan untuk lingkungan sumber Anda (lokal) dan AWS lingkungan target (misalnya, target, akun Wilayah AWS VPCs, dan Availability Zone). Buat tabel komponen yang sedang dimigrasikan dan komponen yang akan menjadi baru. Sertakan aplikasi dan layanan lain (baik di tempat atau di cloud) yang berinteraksi dengan aplikasi ini. Tabel berikut mencantumkan contoh komponen. Itu tidak mewakili arsitektur referensi atau konfigurasi yang diperiksa. | **Nama** | **Deskripsi** | **Detail** | | --- |--- |--- | | Aplikasi | Layanan eksternal (koneksi masuk) | Layanan menggunakan data dari API yang terbuka. | | DNS | Resolusi nama (internal) | Amazon Route 53 digunakan sebagai bagian dari pengaturan akun dasar | | Penyeimbang Beban Aplikasi | Mendistribusikan lalu lintas di antara layanan backend | Menggantikan penyeimbang beban lokal. Migrasi Kolam A. | | Keamanan aplikasi | Perlindungan DDoS | Diimplementasikan dengan menggunakan AWS Shield | | Grup keamanan | Firewall virtual | Batasi akses ke instance aplikasi pada port 443 (inbound). | | Server A | Front-end | Rehost, menggunakan Amazon Elastic Compute Cloud (Amazon EC2). | | Peladen B | Front-end | Rehost menggunakan Amazon EC2. | | Peladen C | Logika aplikasi | Rehost menggunakan Amazon EC2. | | Peladen D | Logika aplikasi | Rehost menggunakan Amazon EC2. | | Layanan Database Relasional Amazon (Amazon RDS) - Amazon Aurora | Basis Data | Menggantikan server E dan F | | Pemantauan dan peringatan | Ubah kontrol | Amazon CloudWatch | | Pencatatan audit | Ubah kontrol | AWS CloudTrail | | Penambalan dan akses jarak jauh | Maintenance | AWS Systems Manager | | Akses sumber daya | Kontrol akses yang aman | AWS Identity and Access Management (IAM) | | Autentikasi | Akses pengguna | Amazon Cognito | | Sertifikat | SSL/TLS | AWS Certificate Manager | | API 1 | API Eksternal | Amazon API Gateway | | Penyimpanan objek | Hosting gambar | Amazon Simple Storage Service (Amazon S3) | | Kredensial | Manajemen dan hosting kredensional | AWS Secrets Manager | | AWS Lambda fungsi | Pengambilan kredensi database dan kunci API | AWS Lambda | | gateway internet | Akses internet keluar | Gerbang internet ke VPC | | Subnet pribadi 1 | Backend dan DB | Zona Ketersediaan 1 — VPC 1 | | Subnet pribadi 2 | Backend dan DB | Zona Ketersediaan 2 — VPC 1 | | Subnet publik 1 | Front-end | Zona Ketersediaan 1 — VPC 1 | | Subnet publik 2 | Front-end | Zona Ketersediaan 2 — VPC 1 | | Layanan Backup | Database dan cadangan instans EC2 | AWS Backup | | DR | Ketahanan Amazon EC2 | AWS Elastic Disaster Recovery | Setelah komponen diidentifikasi, plot mereka dalam diagram menggunakan alat pilihan Anda. Bagikan desain awal dengan pemangku kepentingan aplikasi utama, termasuk pemilik aplikasi, arsitek perusahaan, dan tim platform dan migrasi. Pertimbangkan untuk mengajukan pertanyaan-pertanyaan berikut: + Apakah tim umumnya setuju dengan desainnya? + Dapatkah tim operasi mendukungnya? + Bisakah desain dikembangkan? + Apakah ada pilihan lain? + Apakah desain sesuai dengan standar arsitektur dan kebijakan keamanan? + Apakah ada komponen yang hilang (misalnya, repositori kode, CI/CD perkakas, titik akhir VPC)? ## Keputusan arsitektur Sebagai bagian dari proses desain, Anda mungkin akan menemukan lebih banyak opsi untuk keseluruhan arsitektur atau bagian tertentu darinya. Dokumentasikan opsi ini di samping alasan untuk opsi yang disukai atau dipilih. Keputusan ini dapat didokumentasikan sebagai keputusan arsitektur. Pastikan bahwa opsi utama terdaftar dan dijelaskan dengan cukup detail bagi pembaca baru untuk memahami opsi dan alasan di balik keputusan untuk menggunakan satu opsi di atas yang lain. ## Lingkungan siklus hidup perangkat lunak Dokumentasikan setiap perubahan pada lingkungan saat ini. Misalnya, lingkungan pengujian dan pengembangan akan dibuat ulang AWS dan tidak dimigrasikan. ## Penandaan Jelaskan penandaan wajib dan direkomendasikan untuk setiap komponen infrastruktur serta nilai penandaan untuk desain ini. ## Strategi migrasi Pada titik desain ini, asumsi awal tentang strategi migrasi harus divalidasi. Konfirmasikan bahwa ada konsensus tentang strategi R yang dipilih. Dokumentasikan strategi migrasi aplikasi secara keseluruhan dan strategi untuk komponen aplikasi individual. Seperti disebutkan sebelumnya, komponen aplikasi yang berbeda mungkin memerlukan tipe R yang berbeda untuk migrasi. Selain itu, selaraskan strategi migrasi dengan pendorong dan hasil bisnis utama. Juga, jelaskan setiap pendekatan bertahap untuk migrasi, seperti pergerakan komponen dalam peristiwa migrasi yang berbeda. Untuk informasi lebih lanjut tentang menentukan 6 Rs Anda, lihat [rekomendasi AWS Migration Hub strategi](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/). ## Pola dan alat migrasi Dengan strategi migrasi yang ditentukan untuk komponen aplikasi dan infrastruktur, Anda sekarang dapat menjelajahi pola teknis tertentu. Misalnya, strategi rehost dapat diimplementasikan dengan alat migrasi seperti. [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/) Jika Anda tidak perlu mereplikasi status atau data, Anda dapat mencapai hasil yang sama dengan menerapkan ulang aplikasi menggunakan Amazon Machine Image (AMI) dan pipeline penerapan aplikasi. Demikian pula, untuk memplatform ulang atau memfaktorkan ulang (arsitek ulang) aplikasi, Anda dapat menggunakan alat seperti [AWS App2Container](https://aws.amazon.com/app2container/), [AWS Database Migration Service (AWS DMS), ()](https://aws.amazon.com/dms/), [AWS Schema Conversion Tool](https://aws.amazon.com/dms/schema-conversion-tool/).AWS SCT[AWS DataSync](https://aws.amazon.com/datasync/) Untuk containerizing, Anda dapat menggunakan [Amazon Elastic Container Service (Amazon ECS), Amazon [Elastic Kubernetes Service (Amazon](https://aws.amazon.com/eks/) EKS)](https://aws.amazon.com/ecs/), atau. [AWS Fargate](https://aws.amazon.com/fargate/) Saat membeli kembali, Anda dapat menggunakan AMI untuk produk tertentu atau solusi perangkat lunak sebagai layanan (SaaS) dari. [AWS Marketplace](https://aws.amazon.com/marketplace/) Evaluasi berbagai pola dan opsi yang tersedia untuk mencapai tujuan. Pertimbangkan pro dan kontra, dan kesiapan operasional migrasi. Untuk membantu analisis Anda, gunakan pertanyaan-pertanyaan berikut: + Dapatkah tim migrasi mendukung pola-pola ini? + Apa keseimbangan antara biaya dan manfaat? + Dapatkah aplikasi, layanan, atau komponen ini dipindahkan ke layanan terkelola? + Apa upaya untuk menerapkan pola ini? + Apakah ada peraturan atau kebijakan kepatuhan yang mencegah penggunaan pola tertentu? + Bisakah pola ini digunakan kembali? Pola yang dapat digunakan kembali lebih disukai. Namun, terkadang sebuah pola hanya akan digunakan satu kali. Pertimbangkan keseimbangan antara upaya pola sekali pakai atas pola alternatif yang dapat digunakan kembali. [AWS Panduan Preskriptif](https://aws.amazon.com/prescriptive-guidance/) berisi berbagai pola dan teknik migrasi. ## Manajemen dan operasi layanan Saat membuat desain aplikasi untuk migrasi ke AWS, pertimbangkan kesiapan operasional. Saat mengevaluasi persyaratan kesiapan dengan tim aplikasi dan infrastruktur Anda, pertimbangkan pertanyaan-pertanyaan berikut: + Apakah mereka siap mengoperasikannya? + Apakah prosedur respons insiden didefinisikan? + Apa perjanjian tingkat layanan yang diharapkan (SLA)? + Apakah pemisahan tugas diperlukan? + Apakah tim yang berbeda siap untuk mengoordinasikan tindakan dukungan? + Siapa yang bertanggung jawab untuk apa? ## Pertimbangan cutover Mempertimbangkan strategi dan pola migrasi, apa yang penting untuk diketahui saat aplikasi dimigrasikan? Perencanaan cutover adalah kegiatan pasca-desain. Namun, dokumentasikan pertimbangan apa pun untuk kegiatan dan persyaratan yang dapat diantisipasi. Misalnya, mendokumentasikan persyaratan untuk melakukan bukti konsep, jika berlaku, dan menguraikan persyaratan pengujian, audit, atau validasi. ## Risiko, asumsi, masalah, dan ketergantungan Dokumentasikan setiap risiko terbuka, asumsi, dan potensi masalah yang belum terselesaikan. Tetapkan kepemilikan yang jelas untuk item-item ini, dan lacak kemajuan sehingga desain dan strategi keseluruhan dapat disetujui untuk implementasi. Selain itu, dependensi kunci dokumen untuk mengimplementasikan desain ini. ## Memperkirakan biaya operasional Untuk memperkirakan biaya AWS arsitektur target Anda, gunakan [Kalkulator AWS Harga](https://calculator.aws/). Tambahkan komponen infrastruktur Anda seperti yang ditentukan oleh desain Anda, dan dapatkan perkiraan biaya operasional. Faktor dalam lisensi perangkat lunak yang diperlukan untuk komponen aplikasi Anda dan yang belum termasuk dalam AWS layanan yang akan Anda gunakan.