Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pondasi platform
Bagian ini berfokus pada penilaian kesiapan infrastruktur lokal, menyiapkan AWS landing zone atau meninjau desain landing zone yang ada, dan mengidentifikasi alat migrasi yang diperlukan. Anda meninjau infrastruktur umum, operasi, dan pertanyaan keamanan yang harus Anda pertimbangkan untuk membangun platform. Anda mendokumentasikan jawaban dan keputusan Anda sebagai prinsip migrasi. Akibatnya, Anda memiliki platform yang solid untuk mencapai skala dan kecepatan yang diperlukan untuk migrasi besar.
Bagian ini mencakup topik-topik berikut:
+ [Pertimbangan zona pendaratan untuk migrasi besar](landing-zone.md)
+ [Pertimbangan lokal untuk migrasi besar](on-premises.md)
+ [Dokumentasikan prinsip migrasi Anda](document.md)
# Pertimbangan zona pendaratan untuk migrasi besar
*Landing zone* adalah AWS lingkungan yang dirancang dengan baik yang dapat diskalakan dan aman. Dengan menetapkan standar untuk landing zone, seperti mendefinisikan jumlah akun dan merancang subnet dan kelompok keamanan, Anda membangun fondasi yang kuat. Yayasan ini memberi Anda kemampuan untuk mengaktifkan, menyediakan, dan mengoperasikan lingkungan Anda untuk kelincahan bisnis dan tata kelola dalam skala besar sambil mempercepat perjalanan adopsi cloud Anda. Untuk informasi selengkapnya tentang zona pendaratan dan strategi untuk membangunnya, lihat [Menyiapkan lingkungan multi-akun AWS yang aman dan dapat diskalakan](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/).
Selain pertimbangan bisnis, operasional, keamanan, dan kepatuhan standar untuk strategi landing zone Anda, Anda harus mempertimbangkan cara memfasilitasi migrasi besar. Anda harus mendesain landing zone untuk mendukung beban kerja lokal yang ada selama migrasi dan setelahnya, jika beberapa beban kerja tetap berada di lokasi. Panduan ini memberikan pertimbangan landing zone tambahan yang memengaruhi kecepatan migrasi dan garis waktu migrasi secara keseluruhan.
Biasanya, zona pendaratan dirancang dan digunakan untuk mendukung beban kerja baru di. AWS Cloud Ini karena organisasi mengadopsi AWS sebelum membuat keputusan untuk memigrasi sejumlah besar aplikasi yang ada. Manfaat dari pendekatan ini adalah bahwa organisasi memperoleh pengetahuan dan keterampilan yang berharga AWS sebelum migrasi besar, tetapi juga dapat menyebabkan konflik antara berbagai pemangku kepentingan. Beberapa pemangku kepentingan mungkin ingin memodernisasi aplikasi selama migrasi karena mereka ingin memanfaatkan fitur cloud-native. Namun, tujuan umum dari migrasi besar adalah untuk mencapai kecepatan migrasi maksimum dan memudahkan transisi dengan memigrasikan sebanyak mungkin aplikasi tanpa memodifikasi beban kerja. Anda kemudian memodernisasi aplikasi ini setelah migrasi selesai.
Beberapa faktor kunci dari landing zone yang dapat mempengaruhi proyek program migrasi besar Anda adalah:
+ Ketersediaan dan manajemen bandwidth jaringan
+ Strategi akun untuk isolasi beban kerja dan manajemen sumber daya
+ Kontrol keamanan dan administratif untuk beban kerja yang dimigrasi
Bagian ini meninjau infrastruktur, operasi, dan pertanyaan keamanan yang harus Anda pertimbangkan saat membangun AWS landing zone Anda. Ini juga berisi rekomendasi tentang cara merancang dan menyebarkan landing zone Anda untuk mendukung proyek migrasi besar. Saat Anda menjawab pertanyaan di bagian ini, keputusan ini menjadi prinsip migrasi, yang Anda dokumentasikan sesuai dengan instruksi dalam [Dokumentasikan keputusan Anda sebagai prinsip migrasi besar](document.md).
## Pertimbangan infrastruktur
| Sudahkah Anda mempertimbangkan? | Deskripsi | Tindakan |
| --- | --- | --- |
| Berapa banyak data yang akan Anda migrasi per hari dan per minggu? | Kecepatan migrasi yang diinginkan menentukan jenis koneksi jaringan dan persyaratan throughput jaringan. Hal ini juga dapat mempengaruhi kriteria pemilihan perencanaan gelombang. | Setelah Anda menyelesaikan penilaian portofolio, tentukan jumlah total penyimpanan yang diperlukan untuk semua sumber daya yang dimigrasi di cloud. Gunakan nilai ini untuk menghitung jumlah waktu yang diperlukan untuk memigrasikan data menggunakan bandwidth jaringan saat ini. Anda mungkin perlu meningkatkan bandwidth untuk memenuhi jangka waktu migrasi, atau Anda mungkin perlu menggunakan alternatif, seperti AWS Snow Family solusi. Dalam [template playbook foundation](samples/foundation-playbook-templates.zip), Anda dapat menggunakan *kalkulator replikasi data* (format Microsoft Excel) untuk menghitung bandwidth yang diperlukan untuk setiap gelombang migrasi. |
| Berapa kecepatan tulis rata-rata server sumber di setiap gelombang? | Bandwidth yang diperlukan untuk mentransfer data yang direplikasi didasarkan pada kecepatan tulis server sumber yang berpartisipasi. Jumlah bandwidth yang diperlukan untuk replikasi server adalah kecepatan tulis rata-rata server sumber Anda dikalikan dengan jumlah server dalam gelombang terbesar. | Selama penilaian portofolio, Anda perlu menentukan jumlah rata-rata penulisan data yang dilakukan per oleh setiap server. Dalam [template playbook foundation](samples/foundation-playbook-templates.zip), Anda dapat menggunakan *kalkulator replikasi data* (format Microsoft Excel) untuk memahami bandwidth yang diperlukan untuk lalu lintas migrasi. Bandwidth yang diperlukan untuk lalu lintas migrasi adalah tambahan dari bandwidth yang digunakan untuk aktivitas bisnis normal. Setelah migrasi selesai, Anda tidak lagi memerlukan bandwidth tambahan untuk mendukung aktivitas migrasi. |
| Bisakah aktivitas jaringan tambahan atau infrastruktur yang ada membatasi atau mengurangi kecepatan replikasi? | Jika bandwidth jaringan juga mendukung fungsi bisnis lainnya, aktivitas ini dapat mengurangi jumlah bandwidth yang tersedia untuk mereplikasi server selama migrasi. | Di awal siklus hidup proyek, hati-hati menilai dan menghitung bandwidth jaringan yang diperlukan untuk mendukung semua kegiatan bisnis. Pertimbangkan bandwidth yang diperlukan untuk aktivitas bisnis normal, replikasi server, dan aktivitas terkait migrasi baru, seperti menyinkronkan berbagi file lokal dengan data aktif. AWS Penyedia mungkin memiliki waktu tunggu yang lama untuk meningkatkan kapasitas jaringan, dan Anda mungkin perlu meningkatkan infrastruktur lokal yang ada. Pertimbangkan apakah ada peningkatan tambahan yang diperlukan sebagai konsekuensi dari peningkatan infrastruktur jaringan. Menilai persyaratan bandwidth di awal proyek menyediakan waktu untuk membuat perubahan yang diperlukan. |
| Apakah strategi AWS subnet Anda saat ini memenuhi persyaratan pengalamatan IP untuk memigrasikan beban kerja lokal? | Jumlah server dan persyaratan isolasi beban kerja menentukan strategi subnet untuk landing zone Anda. Migrasi besar mungkin membutuhkan subnet yang lebih besar dari yang Anda harapkan. Dalam migrasi besar, Anda mengelompokkan beban kerja dalam subnet yang mirip dengan penyiapannya di infrastruktur lokal. Untuk menyederhanakan migrasi, desain subnet yang lebih besar dan lebih datar lebih disukai pada awalnya, dan kemudian, selama modernisasi, Anda mendesain ulang subnet sesuai kebutuhan. | Ketika penilaian portofolio memiliki informasi yang cukup tentang inventaris infrastruktur, menilai struktur jaringan lokal dan memasukkannya ke dalam desain landing zone sedini mungkin. |
| Berapa banyak server yang Anda rencanakan untuk direplikasi dan dimigrasikan secara paralel? | Ukuran gelombang migrasi terbesar mempengaruhi persyaratan subnet dan [kuota AWS layanan](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html). | Tinjau rencana migrasi tingkat tinggi, dan gunakan itu untuk mendesain subnet Anda. Misalnya, jika Anda memiliki rencana untuk memigrasikan 200 server ke dalam satu subnet, rentang Classless Inter-Domain Routing (CIDR) untuk subnet tersebut harus memiliki alamat IP yang cukup untuk mendukung jumlah server target. Selain itu, tingkatkan kuota AWS layanan untuk setiap akun target sesuai kebutuhan. |
| Sudahkah Anda mengidentifikasi strategi grup keamanan untuk sumber daya migrasi Anda? | Kelompok keamanan digunakan untuk mengelola lalu lintas masuk dan keluar untuk AWS sumber daya. Penting untuk merancang kelompok keamanan lebih awal untuk menghindari penundaan migrasi. | Di buku runbook untuk prioritas aplikasi, tinjau strategi migrasi, lalu rancang grup keamanan berdasarkan strategi migrasi. Misalnya, jika strategi migrasi adalah meng-host ulang sebagian besar beban kerja, pertimbangkan grup keamanan generik sementara yang mendukung pemotongan migrasi alih-alih memfaktorkan ulang jaringan dan menerapkan grup keamanan khusus aplikasi. |
| Apakah ada penyeimbang beban yang digunakan? | Biasanya, saat memigrasikan server di lingkungan dengan penyeimbang beban, Anda perlu menilai konfigurasi penyeimbang beban dan kemudian memigrasikan penyeimbang beban. Opsi migrasi untuk penyeimbang beban termasuk menggunakan Elastic Load Balancing (ELB) atau solusi berbasis peralatan mitra. | Penilaian load balancer harus dimulai di awal fase penemuan untuk memperhitungkan konfigurasi kustom apa pun. Di sebagian besar lingkungan, konfigurasi penyeimbang beban cukup standar, tetapi beberapa mungkin memiliki logika kompleks yang menentukan apakah Anda dapat bermigrasi ke ELB atau solusi berbasis peralatan mitra. |
| Apakah ada server yang perlu mempertahankan alamat IP sumbernya? | Cara teraman dan termudah untuk memigrasikan server ke cloud adalah dengan mengalokasikan alamat IP baru ke instance yang dimigrasi. Dalam beberapa situasi, Anda mungkin perlu menyimpan alamat IP yang sama dengan server sumber. Misalnya, aplikasi lama mungkin memiliki alamat IP hardcode yang tidak ada yang tahu cara mengubahnya. | Menjaga alamat IP sumber memengaruhi cara Anda membentuk grup bergerak saat perencanaan gelombang. Pendekatan yang paling umum adalah memigrasikan seluruh subnet ke AWS dalam satu grup bergerak karena ini membuat perutean dan peralihan langsung ke tingkat jaringan. Berikut ini adalah tindakan utama untuk menyimpan alamat IP: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/large-migration-foundation-playbook/landing-zone.html) |
| Berapa banyak latensi yang dapat diterima antara sumber dan? AWS | Adalah umum untuk memulai migrasi dengan tautan VPN karena dapat diatur dengan cepat dan kemudian beralih ke koneksi langsung yang dibuat menggunakan AWS Direct Connect. Tautan VPN umumnya memiliki latensi yang lebih tinggi dan lebih bervariasi, yang memengaruhi throughput data dan, yang lebih penting, waktu respons aplikasi. | Jika Anda menggunakan jenis koneksi latensi tinggi atau variabel, tinjau persyaratan setiap aplikasi dan rencanakan gelombang migrasi yang sesuai. Rencanakan untuk menempatkan aplikasi yang memerlukan koneksi latensi rendah di gelombang selanjutnya, ketika jenis koneksi alternatif tersedia. |
## Pertimbangan operasi
| Sudahkah Anda mempertimbangkan? | Deskripsi | Tindakan |
| --- | --- | --- |
| Sudahkah Anda mengidentifikasi strategi AWS akun untuk landing zone Anda? | AWS Praktik terbaik untuk lingkungan yang dirancang dengan baik merekomendasikan agar Anda memisahkan sumber daya dan beban kerja Anda menjadi beberapa akun. AWS Anda dapat menganggap AWS akun sebagai wadah sumber daya yang terisolasi: mereka menawarkan kategorisasi beban kerja dan dapat mengurangi ruang lingkup dampak jika terjadi bencana. | Di buku runbook untuk prioritas aplikasi, tinjau strategi migrasi yang dipilih dan gunakan untuk menentukan strategi akun Anda. Misalnya, jika Anda ingin bermigrasi secepat mungkin dan rehost adalah strategi migrasi yang paling umum, lebih sedikit akun akan lebih mudah dikelola. Namun, jika strategi migrasi Anda memerlukan modernisasi aplikasi dan Anda perlu memisahkan unit bisnis untuk alasan kepatuhan, Anda harus menyertakan satu atau lebih akun untuk setiap unit bisnis dalam strategi akun Anda. |
| Apakah Anda perlu mengganti alat pemantauan selama migrasi? Jika demikian, apakah ini bagian dari proses migrasi, atau apakah itu terjadi sebelum atau sesudah migrasi? | Alat pemantauan sangat penting untuk operasi cloud. Alat Anda yang ada mungkin tidak berfungsi di cloud karena alasan kompatibilitas atau lisensi. Sebagai bagian dari desain, Anda perlu memutuskan alat pemantauan mana yang akan digunakan untuk beban kerja di AWS Cloud. | Pilih alat pemantauan sebelum memulai migrasi. Pastikan tim migrasi menyertakan instruksi untuk menyiapkan pemantauan dalam pola migrasi. Sebaiknya buat skrip otomatisasi yang menggantikan atau menggunakan kembali alat pemantauan, sesuai kebutuhan. |
| Sudahkah Anda mengidentifikasi pemilik aplikasi, dan apakah mereka mengetahui adanya perubahan yang harus dilakukan pada aplikasi sehingga berfungsi dengan baik di cloud? | Migrasi besar adalah transformasi, bukan hanya proyek infrastruktur. Sertakan pemilik aplikasi lebih awal untuk mendukung migrasi. Misalnya, pemilik aplikasi memvalidasi rencana gelombang, membuat rencana pengujian, dan berpartisipasi dalam cutover. | Bekerja dengan kantor manajemen proyek dan tim Cloud Enablement Engine untuk menyelaraskan diri dengan pemimpin tim aplikasi dan memastikan bahwa komunikasi jelas di semua tim aplikasi. Untuk informasi selengkapnya tentang komunikasi dan transparansi proyek, lihat [buku pedoman tata kelola proyek untuk migrasi AWS besar](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/). |
| Sudahkah Anda memilih solusi pencadangan dan pemulihan, dan apakah itu berfungsi dengan beban kerja yang dimigrasi? | Alat Backup dan Recovery sangat penting untuk operasi cloud. Alat Anda yang ada mungkin tidak berfungsi di cloud karena alasan kompatibilitas atau lisensi. Sebagai bagian dari desain, Anda perlu memutuskan alat pencadangan dan pemulihan mana yang akan digunakan untuk beban kerja di AWS Cloud. | Pilih alat pencadangan dan pemulihan sebelum memulai migrasi. Pastikan tim migrasi menyertakan petunjuk untuk menyiapkan pencadangan dan pemulihan dalam pola migrasi. Sebaiknya buat skrip otomatisasi yang menggantikan atau menggunakan kembali alat pencadangan dan pemulihan, sesuai kebutuhan. |
| Sudahkah Anda mengidentifikasi semua layanan bersama dan menerapkannya di landing zone? | *Layanan bersama* adalah layanan yang mendukung beberapa aplikasi, seperti email, Active Directory, atau lingkungan database bersama. Anda biasanya perlu menerapkan layanan bersama di cloud sebelum migrasi agar aplikasi yang dimigrasi berfungsi seperti yang diharapkan. | Jadwalkan penyelaman mendalam dengan tim infrastruktur dan pemimpin tim aplikasi sebelum menyelesaikan desain landing zone. Tinjau dan konfirmasikan daftar layanan bersama yang harus Anda terapkan di cloud sebelum memulai migrasi. Layanan bersama yang paling umum adalah Active Directory, perangkat jaringan, Domain Name System (DNS), dan perangkat lunak infrastruktur. |
| Sudahkah Anda meninjau kuota AWS layanan untuk AWS Wilayah dan akun target Anda? | Setiap AWS layanan memiliki kuota layanan. Beberapa kuota ini dapat ditingkatkan. Penting untuk meninjau kuota sebelum cutover. Jika sumber daya tidak mencukupi tersedia, cutover mungkin gagal. | Tinjau rencana migrasi. Untuk akun target apa pun yang memerlukan peningkatan kuota layanan, minta kenaikan. Untuk informasi dan instruksi selengkapnya, lihat [kuota AWS layanan](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html). |
| Apakah Anda perlu meng-upgrade paket AWS Support Anda? | AWS Paket dukungan perusahaan menawarkan dukungan telepon 24/7 dan waktu respons yang lebih cepat daripada paket lainnya. Karena jendela cutover biasanya sangat pendek, memiliki akses ke insinyur berpengalaman untuk membantu menyelesaikan masalah cutover dapat menjadi penting untuk keberhasilan migrasi besar. | Hubungi tim AWS akun Anda untuk mendiskusikan opsi dukungan yang berbeda dan pilih paket dukungan yang sesuai untuk proyek migrasi besar Anda. |
| Sudahkah Anda memberi tahu manajer akun AWS teknis (TAM) tentang rencana migrasi besar Anda? | Tim dukungan AWS Enterprise On-Ramp menugaskan sekelompok Manajer Akun Teknis (TAMs) yang mengoordinasikan akses ke program proaktif, program pencegahan, dan pakar materi pelajaran. AWS Anda TAMs dapat menjadwalkan ketersediaan sumber daya dukungan sesuai kebutuhan. | Beri tahu manajer akun AWS teknis Anda tentang proyek migrasi besar Anda yang akan datang dan bagikan rencana migrasi Anda. Anda TAMs akan memastikan sumber daya AWS dukungan tersedia saat dibutuhkan. Misalnya, Anda TAMs dapat menjadwalkan insinyur dukungan selama pemotongan, dan insinyur dapat membantu mengurangi masalah teknis dan merampingkan pemotongan. |
## Pertimbangan keamanan
| Sudahkah Anda mempertimbangkan? | Deskripsi | Tindakan |
| --- | --- | --- |
| Sudahkah Anda mengidentifikasi peran dan kebijakan AWS Identity and Access Management (IAM) untuk manajemen akses? | Kelola identitas dan akses untuk semua anggota proyek migrasi besar Anda. Dengan melampirkan peran IAM ke sumber daya yang dimigrasi dan menentukan kebijakan akses, Anda mengontrol siapa yang dapat mengakses sumber daya yang dimigrasi di cloud. | Bekerja dengan tim migrasi untuk mengidentifikasi peran dan tanggung jawab. Tentukan peran mana yang dapat mengakses AWS akun mana, dan identifikasi tingkat akses yang dimiliki setiap peran. Bekerja dengan tim keamanan untuk memvalidasi bahwa peran IAM benar untuk setiap sumber daya target AWS . |
| Apakah ada persyaratan kepatuhan untuk beban kerja Anda? | Beban kerja mungkin memiliki persyaratan kepatuhan yang berbeda, seperti Undang-Undang Portabilitas dan Akuntabilitas Asuransi Kesehatan (HIPAA) atau Standar Keamanan Data industri kartu pembayaran (PCI DSS). Anda harus mengidentifikasi persyaratan ini sebelum migrasi dan merencanakan cara memenuhinya. | Bekerja dengan tim kepatuhan dan tim portofolio untuk mengidentifikasi persyaratan kepatuhan untuk setiap aplikasi, dan rancang AWS akun target Anda sesuai dengan itu. Misalnya, Anda mungkin perlu memigrasikan beberapa beban kerja ke AWS GovCloud (US) atau ke Wilayah tertentu AWS . Kami menyarankan Anda untuk mendokumentasikan persyaratan kepatuhan untuk setiap aplikasi sehingga Anda dapat menggunakan informasi ini nanti dalam proses prioritas aplikasi dan perencanaan gelombang. |
| Apakah tim keamanan Anda perlu meninjau dan menyetujui alat atau layanan apa pun yang Anda rencanakan untuk digunakan selama migrasi? | Sebuah proyek migrasi besar AWS Cloud menggunakan banyak layanan, seperti, AWS Database Migration Service (AWS DMS) AWS Application Migration Service AWS DataSync, dan alat penemuan portofolio (seperti Flexera One). Beberapa organisasi mengharuskan semua alat dan layanan baru disetujui sebelum digunakan. | Bekerja dengan tim migrasi untuk mengidentifikasi semua alat, layanan, dan aplikasi yang Anda harapkan untuk digunakan dalam migrasi. Bekerja sama dengan tim keamanan untuk meninjau kebijakan perusahaan dan menyetujui alat ini sebelum migrasi dimulai. |
# Pertimbangan lokal untuk migrasi besar
Infrastruktur lokal yang mendukung operasi bisnis Anda juga harus siap untuk migrasi besar. Dengan menyiapkan infrastruktur saat ini, Anda dapat membantu mengurangi dampak migrasi besar ke operasi bisnis dan pengguna aplikasi.
Bagian ini meninjau pertanyaan infrastruktur, operasi, dan keamanan yang harus Anda pertimbangkan saat menyiapkan infrastruktur lokal untuk migrasi besar. Saat Anda menjawab pertanyaan di bagian ini, keputusan ini menjadi *prinsip migrasi*, yang Anda dokumentasikan sesuai dengan instruksi dalam [Dokumentasikan keputusan Anda sebagai prinsip migrasi besar](document.md).
## Pertimbangan infrastruktur
| Sudahkah Anda mempertimbangkan? | Deskripsi | Tindakan |
| --- | --- | --- |
| Sudahkah Anda merancang DNS dan router lokal untuk mendukung lalu lintas ke dan dari akun target? AWS | Karena banyaknya server dan AWS akun target, penting untuk mengonfirmasi bahwa komponen jaringan yang berbeda dikonfigurasi dengan benar untuk mendukung strategi dan skala migrasi. | Tinjau desain tabel perutean, dan pastikan ada rute yang benar antara AWS akun dan pusat data lokal. Selain itu, pastikan server DNS dapat mendukung kueri DNS dari server lokal dan sumber daya. AWS |
| Bagaimana tim migrasi mengakses lokal dan AWS lingkungan? | Tim migrasi perlu mengakses server sumber dan target untuk melakukan aktivitas migrasi, seperti menginstal agen replikasi di server sumber atau menghapus instalasi perangkat lunak lama di server target. | Tinjau mekanisme otentikasi dan otorisasi yang ada dan bangun strategi untuk memberikan akses. Anda dapat menggunakan grup Active Directory, peran IAM, dan federasi Security Assertion Markup Language 2.0 (SAMB 2.0) untuk mengizinkan proses masuk tunggal ke akun. AWS Sebaiknya buat pengguna admin lokal jika ada masalah otentikasi dengan Active Directory. |
| Apakah ada titik kemacetan yang diketahui dalam konfigurasi jaringan saat ini yang akan memperlambat throughput data selama migrasi? | Migrasi besar membutuhkan banyak bandwidth untuk mereplikasi data dari pusat data lokal ke cloud. Memahami titik kemacetan atau batasan yang ada membantu Anda merencanakan migrasi dengan lebih baik. | Tinjau konfigurasi jaringan dengan tim jaringan untuk lebih memahami jalur jaringan dari mesin sumber ke AWS akun target. Identifikasi titik kemacetan potensial, seperti koneksi yang dibagi antara migrasi dan beban kerja produksi. |
## Pertimbangan operasi
| Sudahkah Anda mempertimbangkan? | Deskripsi | Tindakan |
| --- | --- | --- |
| Apakah Anda memiliki hari terjadwal yang diblokir, juga dikenal sebagai *pembekuan perubahan*, yang dapat memengaruhi migrasi? | Pembekuan perubahan selama migrasi dapat menghilangkan sumber daya dan waktu penting dari proyek migrasi yang sedang berlangsung. | Tinjau proses manajemen perubahan dengan tim operasi, dan pertimbangkan hari-hari yang diblokir saat Anda merencanakan jendela cutover. |
| Sudahkah Anda memesan hari perubahan untuk migrasi? | Proses manajemen perubahan bisa rumit, dan beberapa organisasi mengizinkan perubahan hanya di jendela pemeliharaan tertentu. | Menurut proses manajemen perubahan Anda, jadwalkan perubahan setidaknya lima gelombang sebelumnya. Ini membantu mencegah penundaan |
| Apakah semua server dalam ruang lingkup migrasi baru-baru ini di-boot ulang? | Perubahan sistem atau tambalan yang dihapus dapat menyebabkan masalah selama migrasi, yang akan memerlukan jendela cutover yang panjang atau memutar kembali server. Praktik terbaik adalah mengonfirmasi bahwa server baru saja di-boot ulang di sisi target sebelum bermigrasi. | Tinjau tanggal reboot server terakhir. Jika server belum dimulai ulang dalam 90 hari terakhir, jadwalkan restart sebelum memigrasi server. |
| Bagaimana pemulihan bencana dan rencana kelangsungan bisnis bekerja hari ini, dan apakah ini telah diperhitungkan dalam desain landing zone? | Pemulihan bencana dan rencana kelangsungan bisnis merupakan komponen penting untuk memenuhi tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO) aplikasi. Anda perlu memastikan rencana ini berfungsi baik untuk lokal maupun AWS beban kerja Anda selama masa transisi. | Tinjau rencana pemulihan bencana dan kelangsungan bisnis yang ada dan pastikan rencana tersebut berfungsi untuk AWS akun target Anda. Jika tidak, rancang rencana baru sebelum memindahkan beban kerja ke. AWS Cloud |
## Pertimbangan keamanan
| Sudahkah Anda mempertimbangkan? | Deskripsi | Tindakan |
| --- | --- | --- |
| Sudahkah Anda membuat aturan firewall untuk mendukung migrasi besar? | Bergantung pada proses di organisasi Anda, dibutuhkan waktu lama untuk menyelesaikan permintaan perubahan untuk konfigurasi firewall. | Tinjau proses perubahan firewall yang ada dengan tim keamanan, dan rancang strategi untuk perubahan firewall migrasi besar yang sesuai. Anda mungkin perlu merancang proses kustom untuk proyek migrasi besar, atau Anda mungkin perlu mengirimkan perubahan di awal proyek. Disarankan agar Anda mempertimbangkan untuk menggunakan AWS virtual private cloud (VPC) sebagai ekstensi ke pusat data Anda dan menghindari membangun aturan firewall yang terlalu rumit, yang secara signifikan dapat menunda migrasi besar. |
| Sudahkah Anda mengatur Active Directory di AWS lingkungan? | Active Directory digunakan untuk otentikasi dan otorisasi. Anda perlu memastikan beban kerja akun target dapat terhubung ke pengontrol domain untuk otentikasi dan otorisasi. Anda dapat menambahkan pengontrol domain baru di VPC target, atau Anda dapat mengizinkan AWS beban kerja terhubung ke pengontrol domain lokal. | Tinjau desain Active Directory dengan tim keamanan dan infrastruktur Anda. Pastikan AWS akun target memiliki konektivitas ke pengontrol domain yang benar. Pastikan bahwa blok CIDR AWS subnet target berada di situs Active Directory yang benar sehingga beban kerja dapat AWS terhubung ke pengontrol domain terdekat. |
| Sudahkah Anda mengidentifikasi koneksi pihak ketiga dan saling ketergantungan aplikasi? | Koneksi pihak ketiga dan saling ketergantungan aplikasi mengharuskan Anda memodifikasi aturan firewall, daftar kontrol akses jaringan, dan grup keamanan. | Selama sesi deep dive dengan pemilik aplikasi, tinjau dependensi eksternal untuk setiap aplikasi. Kirim permintaan untuk memodifikasi aturan firewall dan daftar kontrol akses jaringan dan mengubah grup keamanan yang sesuai, berdasarkan persyaratan ketergantungan pihak ketiga. |
| Apakah lingkungan lokal Anda memiliki alat keamanan tambahan yang mengontrol akses dan proses yang berjalan pada sistem, seperti? CyberArk | Anda mungkin perlu menilai dan memperbarui alat keamanan ini agar alat migrasi dapat berfungsi di AWS landing zone. | Tinjau kebijakan akses di lingkungan sumber Anda. Jika alat keamanan digunakan dalam kebijakan akses, konfirmasikan bahwa alat tersebut berfungsi di AWS Cloud, lalu pastikan tim migrasi memiliki akses ke lingkungan sumber dan target. Jika ada perubahan yang diperlukan, tambahkan langkah-langkah ini ke dalam runbook migrasi Anda. |
# Dokumentasikan prinsip migrasi Anda
Setelah meninjau pertimbangan landing zone dan lokal, Anda harus mendokumentasikan jawaban dan keputusan Anda. Ini menjadi prinsip migrasi yang memandu sisa proyek.
Lakukan hal-hal berikut:
1. Di [templat buku pedoman dasar, buka templat](samples/foundation-playbook-templates.zip) *Prinsip migrasi* (format Microsoft Word).
1. Tinjau infrastruktur, operasi, dan pertimbangan keamanan dalam [pertimbangan zona pendaratan untuk migrasi besar dan pertimbangan](landing-zone.md) di [tempat untuk bagian migrasi besar](on-premises.md) dari panduan ini, dan diskusikan pertanyaan dengan tim yang direkomendasikan.
1. Dokumentasikan keputusan infrastruktur, operasi, dan keamanan dalam dokumen prinsip migrasi Anda. Untuk contoh cara mencatat keputusan ini, lihat tabel berikut.
1. Sesuai kebutuhan untuk kasus penggunaan Anda, tambahkan kategori, item, dan prinsip baru. Misalnya, Anda mungkin ingin mencatat prinsip migrasi untuk penilaian portofolio atau keputusan manajemen proyek.
Berikut ini adalah contoh bagaimana Anda dapat mencatat keputusan Anda untuk beberapa pertanyaan dalam panduan ini.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/large-migration-foundation-playbook/document.html)