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

Praktik terbaik AWS Database Migration Service

Untuk menggunakan AWS Database Migration Service (AWS DMS) paling efektif, lihat rekomendasi bagian ini tentang cara paling efisien untuk melakukan migrasi data Anda.

Perencanaan migrasi untuk AWS Database Migration Service

Ketika merencanakan migrasi basis data menggunakan AWS Database Migration Service, pertimbangkan hal berikut:

Mengubah skema

AWS DMS tidak melakukan konversi skema atau kode. Jika Anda ingin mengubah skema yang ada untuk mesin basis data yang berbeda, Anda dapat menggunakan AWS SCT. AWS SCTmengubah objek sumber, tabel, indeks, tampilan, pemicu, dan berbagai objek sistem lainnya ke dalam format bahasa definisi data target (DDL). Anda juga dapat menggunakan AWS SCT untuk mengubah sebagian besar kode aplikasi Anda, seperti PL/SQL atau TSQL, untuk bahasa target yang setara.

Anda bisa mendapatkan AWS SCT dengan mengunduh secara gratis dari AWS. Untuk informasi lebih lanjut tentang AWS SCT, lihat Panduan Pengguna AWS SCT.

Jika titik akhir sumber dan target Anda berada di mesin database yang sama, Anda dapat menggunakan alat seperti Oracle SQL Developer, MySQL Workbench, atau 4 untuk memindahkan skema Anda. PgAdmin

Meninjau dokumentasi publik AWS DMS

Kami sangat menyarankan agar Anda pergi ke halaman dokumentasi publik AWS DMS untuk sumber dan titik akhir target sebelum migrasi pertama Anda. Dokumentasi ini dapat membantu Anda mengidentifikasi prasyarat untuk migrasi dan memahami keterbatasan saat ini sebelum memulai. Untuk informasi lebih lanjut, lihat Bekerja dengan Titik akhir DMS AWS.

Selama migrasi, dokumentasi publik dapat membantu Anda memecahkan masalah apa pun dengan AWS DMS. Halaman pemecahan masalah dalam dokumentasi dapat membantu Anda menyelesaikan berbagai masalah umum menggunakan AWS DMS dan basis data titik akhir yang dipilih. Untuk informasi lebih lanjut, lihat Memecahkan masalah tugas migrasi di AWS Database Migration Service.

Menjalankan bukti konsep

Untuk membantu menemukan masalah dengan lingkungan Anda pada fase awal migrasi basis data Anda, sebaiknya jalankan migrasi uji singkat. Melakukan hal ini juga dapat membantu Anda mengatur ketepatan waktu migrasi yang lebih realistis. Selain itu, Anda mungkin perlu menjalankan migrasi uji menskalakan penuh untuk mengukur apakah AWS DMS dapat menangani throughput basis data pada jaringan Anda. Selama waktu ini, kami merekomendasikan untuk menetapkan tolok ukur dan mengoptimalkan awal beban penuh Anda dan replikasi yang sedang berlangsung. Melakukan hal ini dapat membantu memahami latensi jaringan Anda dan mengukur performa secara keseluruhan.

Pada saat ini, Anda juga memiliki kesempatan untuk memahami profil data Anda dan seberapa basis data large Anda, termasuk berikut ini:

Meningkatkan performa suatu migrasi AWS DMS

Sejumlah faktor memengaruhi performa Migrasi AWS DMS Anda:

Anda dapat meningkatkan performa dengan menggunakan beberapa atau semua praktik terbaik yang disebutkan berikut. Apakah Anda dapat menggunakan salah satu praktik ini tergantung pada kasus penggunaan spesifik Anda. Anda dapat menemukan beberapa keterbatasan berikut:

Menggunakan server nama on-premise Anda sendiri

Biasanya, instans replikasi AWS DMS menggunakan resolver Sistem Nama Domain (DNS) dalam instans Amazon EC2 untuk menyelesaikan titik akhir domain. Namun, Anda dapat menggunakan server nama on-premise Anda sendiri untuk menyelesaikan titik-titik akhir tertentu jika Anda menggunakan Amazon Route 53 Resolver. Dengan perangkat ini, Anda dapat melakukan kueri antara on-premise dan AWS menggunakan titik akhir masuk (inbound) dan keluar (outbound), aturan penerusan, dan koneksi privat. Manfaat menggunakan server nama on-premise mencakup peningkatan keamanan dan kemudahan penggunaan di balik firewall.

Jika Anda memiliki titik akhir masuk (inbound), Anda dapat menggunakan kueri DNS yang berasal dari on-premise untuk menyelesaikan domain host AWS. Untuk mengkonfigurasi titik akhir, tetapkan alamat IP di setiap subnet yang ingin Anda berikan resolver. Untuk membangun konektivitas antara infrastruktur DNS on-premise dan AWS, gunakan AWS Direct Connect atau jaringan pribadi virtual (VPN).

Connect titik akhir keluar ke server nama on-premise Anda. Server nama hanya memberi kemudahan untuk mengakses ke alamat IP yang disertakan dalam daftar yang mengizinkan maksud tersebut dan diatur dalam titik akhir keluar. Alamat IP server nama Anda adalah alamat IP target. Ketika Anda memilih grup keamanan untuk titik akhir keluar, pilihlah grup keamanan sama yang digunakan oleh instans replikasi.

Untuk meneruskan domain pilihan ke server nama, gunakan aturan penerusan. Titik akhir keluar dapat menangani beberapa aturan penerusan. Lingkup aturan penerusan adalah virtual private cloud (VPC) Anda. Dengan menggunakan aturan penerusan yang terkait dengan VPC, Anda dapat memiliki persediaan bagian Cloud AWS yang terisolasi secara logis. Dari bagian yang terisolasi secara logis ini, Anda dapat meluncurkan sumber daya AWS dalam jaringan virtual.

Anda dapat melakukan konfigurasi domain yang dihosting dalam infrastruktur DNS on-premise sebagai aturan penerusan bersyarat yang mengatur kueri DNS keluar. Ketika suatu kueri dibuat untuk salah satu domain tersebut, beberapa aturan menjadikan pemicu sebagai upaya untuk meneruskan permintaan DNS ke server yang dikonfigurasi dengan aturan tersebut. Sekali lagi, diperlukan koneksi privat melalui AWS Direct Connect atau VPN.

Diagram berikut menunjukkan arsitektur Route 53 Resolver.

Untuk informasi selengkapnya tentang penggunaan Route 53 DNS Resolver, lihat Memulai dengan Route 53 Resolver dalam Panduan Developer Amazon Route 53.

Menggunakan Amazon Route 53 Resolver dengan AWS DMS

Anda dapat membuat server nama on premise untuk AWS DMS untuk menyelesaikan titik akhir menggunakan Amazon Route 53 Resolver.

Ketika semuanya dibuat, VPC Anda dikaitkan dengan aturan masuk dan keluar Anda dan lalu lintas perutean dapat mulai.

Untuk informasi selengkapnya tentang Route 53 Resolver, lihat Memulai dengan Route 53 Resolver dalam Panduan Developer Amazon Route 53.

Melakukan migrasi objek biner large (LOB)

Secara umum, AWS DMS melakukan migrasi data LOB dalam dua tahap:

Proses migrasi untuk LOB mensyaratkan bahwa, selama migrasi, semua kolom LOB pada tabel target harus tidak dapat dibatalkan. Hal ini sedemikian rupa sehingga bahkan jika kolom LOB bukan tidak dapat dibatalkan pada tabel sumber. Jika AWS DMS menciptakan tabel target, maka menetapkan kolom LOB supaya tidak dapat dibatalkan secara default. Dalam beberapa kasus, Anda mungkin membuat tabel target menggunakan beberapa mekanisme lain, seperti impor atau ekspor. Dalam kasus tersebut, pastikan bahwa kolom LOB tidak dapat dibatalkan sebelum Anda mulai tugas migrasi.

Persyaratan ini memiliki satu pengecualian. Misalkan Anda melakukan migrasi homogen dari sumber Oracle ke target Oracle, dan Anda memilih Mode Lob terbatas. Dalam hal ini, seluruh baris diisi sekaligus, termasuk nilai-nilai LOB. Untuk kasus seperti itu, AWS DMS dapat membuat kolom LOB tabel target dengan kendala bukan tidak dapat dibatalkan, jika diperlukan.

Menggunakan mode LOB terbatas

AWS DMS menggunakan dua metode yang menyeimbangkan performa dan kemudahan ketika migrasi Anda berisi nilai-nilai LOB:

Untuk beberapa mesin basis data, seperti PostgreSQL, AWS DMS memperlakukan tipe data JSON seperti LOBs. Pastikan bahwa jika Anda memilih Mode LOB terbatas, pengukuran LOB maksimal diatur pada nilai yang tidak menyebabkan data JSON dipotong.

AWS DMS menyediakan support penuh untuk menggunakan tipe data objek large (BLOB, CLOB, dan NCLOB). Titik akhir sumber berikut memiliki support LOB penuh:

Titik akhir target berikut memiliki support LOB penuh:

Titik akhir target berikut memiliki support LOB terbatas. Anda tidak dapat menggunakan pengukuran LOB tak terbatas untuk titik akhir target ini.

Untuk titik akhir yang memiliki support LOB penuh, Anda juga dapat menetapkan batas pengukuran untuk LOB tipe data.

Peningkatan performa LOB

Sementara melakukan migrasi data LOB, Anda dapat menentukan pengaturan optimasi LOB yang berbeda berikut.

Pengaturan LOB per tabel

Menggunakan pengaturan LOB per tabel, Anda dapat mengganti pengaturan LOB tingkat tugas untuk beberapa atau semua tabel Anda. Untuk melakukannya, tentukan lob-settings di aturan table-settings. Berikut ini adalah contoh tabel yang mencakup beberapa nilai LOB large.

SET SERVEROUTPUT ON
CREATE TABLE TEST_CLOB
(
ID NUMBER,
C1 CLOB,
C2 VARCHAR2(4000)
);
DECLARE
bigtextstring CLOB := '123';
iINT;
BEGIN
WHILE Length(bigtextstring) <= 60000 LOOP
bigtextstring := bigtextstring || '000000000000000000000000000000000';
END LOOP;
INSERT INTO TEST_CLOB (ID, C1, C2) VALUES (0, bigtextstring,'AnyValue');
END;
/
SELECT * FROM TEST_CLOB;
COMMIT

Berikutnya, membuat tugas migrasi dan memodifikasi penanganan LOB untuk tabel Anda dengan menggunakan aturan baru lob-settings. Nilai bulk-max-siz menentukan pengukuran LOB maksimum (KB). Ini terpotong jika lebih besar dari pengukuran yang ditentukan.

{
	"rules": [{
			"rule-type": "selection",
			"rule-id": "1",
			"rule-name": "1",
			"object-locator": {
				"schema-name": "HR",
				"table-name": "TEST_CLOB"
			},
			"rule-action": "include"
		},
		{
			"rule-type": "table-settings",
			"rule-id": "2",
			"rule-name": "2",
			"object-locator": {
				"schema-name": "HR",
				"table-name": "TEST_CLOB"
			},
			"lob-settings": {
				"mode": "limited",
				"bulk-max-size": "16"
			}
		}
	]
}

Bahkan jika tugas ini AWS DMS dibuat dengan FullLobMode : true, beberapa pengaturan LOB per tabel mengarahkan AWS DMS untuk memotong data LOB dalam tabel khusus ini pada 16.000. Anda dapat memeriksa catatan tugas untuk mengonfirmasi ini.

721331968: 2018-09-11T19:48:46:979532 [SOURCE_UNLOAD] W: The value of column 'C' in table
'HR.TEST_CLOB' was truncated to length 16384

Pengaturan LOB sebaris

Saat Anda membuat suatu tugas AWS DMS, mode LOB menentukan bagaimana LOB ditangani.

Dengan mode LOB penuh dan mode LOB terbatas, masing-masing memiliki manfaat dan kekurangan tersendiri. Mode LOB sebaris menggabungkan keuntungan dari kedua mode LOB penuh dan mode LOB terbatas.

Anda dapat menggunakan mode LOB sebaris ketika Anda perlu mereplikasi baik LOB kecil maupun large, dan sebagian besar LOB kecil. Ketika Anda memilih opsi ini, selama beban penuh, tugas AWS DMS mentransfer baris LOB kecil, yang lebih efisien. Tugas AWS DMS mentransfer LOB large dengan performa pencarian dari tabel sumber.

Selama pemrosesan perubahan, LOB kecil dan large direplikasi dengan performa pencarian dari tabel sumber.

Bila Anda menggunakan modus LOB sebaris, tugas AWS DMS memeriksa semua pengukuran LOB untuk menentukan mana yang ditransfer sebaris. LOB yang lebih besar dari pengukuran yang ditentukan direplikasi dengan menggunakan mode LOB penuh. Oleh karena itu, jika Anda tahu bahwa sebagian besar LOB lebih besar dari pengaturan yang ditentukan, lebih baik tidak menggunakan opsi ini. Sebaliknya, mengizinkan pengukuran LOB yang tak terbatas.

Anda mengkonfigurasi opsi ini menggunakan atribut dalam pengaturan tugas, InlineLobMaxSize, yang hanya tersedia saat FullLobMode dilakukan pengaturan ke true. Nilai default untuk InlineLobMaxSize adalah 0 dan kisarannya adalah 1 —102400 kilobyte (100 MB).

Misalnya, Anda dapat menggunakan perintah berikut: pengaturan tugas AWS DMS. Di sini, pengaturan InlineLobMaxSize ke nilai 5 menghasilkan semua LOB yang lebih kecil dari atau sama dengan 5 KiB (5.120 byte) ditransfer sebaris.

{
  "TargetMetadata": {
  "TargetSchema": "",
  "SupportLobs": true,
  "FullLobMode": true,
  "LobChunkSize": 64,
  "LimitedSizeLobMode": false,
  "LobMaxSize": 32,
  "InlineLobMaxSize": 5,
  "LoadMaxFileSize": 0,
  "ParallelLoadThreads": 0,
  "ParallelLoadBufferSize":0,
  "BatchApplyEnabled": false,
  "TaskRecoveryTableEnabled": false},
  . . .
}

Meningkatkan performa ketika melakukan migrasi tabel-tabel large menggunakan filter baris

Untuk meningkatkan kinerja saat memigrasikan tabel besar, pisahkan migrasi menjadi lebih dari satu tugas. Untuk membagi migrasi menjadi beberapa tugas menggunakan filter baris, gunakan satu kunci atau kunci partisi. Misalnya, jika Anda memiliki ID kunci primer integer dari 1 hingga 8.000.000, Anda dapat membuat delapan tugas menggunakan filter baris untuk melakukan migrasi masing-masing 1 juta catatan.

Jika Anda memiliki tabel partisi besar yang dipartisi berdasarkan tanggal, Anda dapat memigrasikan data berdasarkan tanggal. Misalnya, anggap bahwa Anda memiliki tabel yang dipartisi berdasarkan bulan, dan hanya data bulan saat ini yang diperbarui. Dalam hal ini, Anda dapat membuat tugas beban penuh untuk setiap partisi bulanan statis dan membuat beban penuh ditambah tugas CDC untuk partisi yang sedang diperbarui.

Jika tabel Anda memiliki kunci primer satu kolom atau indeks unik, Anda dapat membuat AWS DMS tugas Anda mengelompokkan tabel menggunakan beban paralel dari jenis rentang untuk memuat data secara paralel. Untuk informasi selengkapnya, lihat Tabel dan koleksi pengaturan aturan dan operasi.

Replikasi yang sedang berlangsung

AWS DMS menyediakan replikasi data yang sedang berlangsung, menjaga sumber dan target basis data tetap sinkron. Ini mereplikasi hanya jumlah terbatas bahasa definisi data (DDL). AWS DMS tidak mengembangkan item seperti indeks, pengguna, hak istimewa, prosedur yang disimpan, dan perubahan basis data lainnya yang tidak terkait langsung dengan data tabel.

Jika Anda berencana untuk menggunakan replikasi yang sedang berlangsung, aturlah opsi Multi-AZ saat membuat instans replikasi Anda. Dengan memilih Multi-AZ, Anda mendapatkan ketersediaan yang tinggi dan failover support untuk instans replikasi. Namun, opsi ini dapat berdampak pada performa dan dapat memperlambat replikasi sementara menerapkan perubahan sistem target.

Sebelum Anda memutakhirkan sumber atau target basis data, kami menyarankan agar Anda menghentikan setiap tugas AWS DMS yang berjalan di basis data ini. Lanjutkan tugas setelah pemutakhiran sistem selesai.

Selama replikasi yang sedang berlangsung, sangat penting untuk mengidentifikasi bandwidth jaringan antara sistem basis data sumber dan instans replikasi AWS DMS. Pastikan bahwa jaringan tidak menyebabkan kemacetan selama replikasi berlangsung.

Penting juga untuk mengidentifikasi tingkat perubahan dan hasil dari mencatat arsip per jam pada sistem basis data sumber Anda. Melakukan hal ini dapat membantu Anda untuk memahami throughput yang mungkin Anda dapatkan selama replikasi yang sedang berlangsung.

Mengurangi beban pada basis data sumber Anda

AWS DMS menggunakan beberapa sumber daya pada basis data sumber Anda. Selama tugas beban penuh, AWS DMS melakukan pemindaian tabel lengkap dari tabel sumber untuk setiap tabel yang diproses secara paralel. Dan juga, setiap tugas yang Anda buat sebagai bagian dari migrasi kueri sumber untuk perubahan sebagai bagian dari proses CDC. Supaya AWS DMS melakukan CDC untuk beberapa sumber, seperti Oracle, Anda mungkin perlu meningkatkan jumlah data yang ditulis dengan mencatat perubahan basis data Anda.

Jika mengetahui bahwa Anda membebani basis data sumber Anda, kurangi jumlah tugas atau tabel untuk setiap tugas migrasi Anda. Setiap tugas mendapat perubahan sumber secara terpisah, sehingga menggabbungkan beberapa tugas dapat mengurangi perubahan yang menangkap beban kerja.

Mengurangi kemacetan pada basis data target Anda

Selama migrasi, cobalah menghapus proses yang bersaing untuk sumber daya tulis pada basis data target Anda:

Menggunakan validasi data selama migrasi

Untuk memastikan bahwa data Anda dimigrasi secara akurat dari sumber ke target, kami sangat menyarankan agar Anda menggunakan validasi data. Jika Anda mengaktifkan validasi data untuk suatu tugas, AWS DMS mulai membandingkan sumber dan target data segera setelah beban penuh dilakukan untuk tabel.

Validasi data bekerja dengan basis data berikut di mana pun AWS DMS mendukungnya sebagai sumber dan target titik akhir:

Untuk informasi selengkapnya, lihat AWS Validasi data DMS.

Pemantauan tugas AWS DMS menggunakan metrik

Anda memiliki beberapa opsi pemantauan metrik untuk tugas Anda dengan menggunakan konsol AWS DMS tersebut:

Untuk informasi selengkapnya tentang pemantauan metrik, lihat AWS DMSTugas pemantauan.

Tindakan dan notifikasi

AWS DMS menggunakan Amazon SNS untuk memberikan notifikasi ketika tindakan AWS DMS terjadi, misalnya penciptaan atau penghapusan instans replikasi. Anda dapat bekerja dengan notifikasi ini dalam bentuk apa pun yang didukung oleh Amazon SNS untuk Wilayah AWS. Ini dapat mencakup pesan email, pesan teks, atau panggilan pada titik akhir HTTP.

Untuk informasi lebih lanjut, lihat Bekerja dengan acara Amazon SNS dan pemberitahuan diAWS Database Migration Service.

Menggunakan cara dengan mencatat tugas untuk memecahkan masalah migrasi

Dalam beberapa kasus, AWS DMS dapat mengalami berbagai masalah yang memunculkan peringatan atau pesan kesalahan hanya dengan mencatat tugas. Secara khusus, masalah pemotongan data atau penolakan baris karena pelanggaran kunci asing hanya ditulis dengan mencatat tugas. Oleh karena itu, pastikan untuk meninjau setelah mencatat tugas ketika melakukan migrasi basis data. Untuk melihat log tugas, konfigurasikan Amazon CloudWatch sebagai bagian dari pembuatan tugas.

Untuk informasi selengkapnya, lihat Memantau tugas replikasi menggunakan Amazon CloudWatch.

Memecahkan masalah tugas replikasi dengan Time Travel

Untuk memecahkan masalah AWS DMS migrasi, Anda dapat bekerja dengan Time Travel. Untuk informasi lebih lanjut tentang Perjalanan Waktu, lihatPengaturan tugas Perjalanan Waktu.

Saat Anda bekerja dengan Time Travel, perhatikan pertimbangan berikut:

Mengubah pengguna dan skema untuk target Oracle

Bila Anda adalah pengguna Oracle sebagai target, AWS DMS melakukan migrasi data ke skema yang dimiliki oleh pengguna titik akhir target.

Misalnya, anggaplah Anda melakukan migrasi skema bernama PERFDATA pada titik akhir target Oracle, dan bahwa nama pengguna titik akhir target adalah MASTER. AWS DMS menghubungkan ke target Oracle sebagai MASTER dan mengisi skema MASTER dengan objek basis data dari PERFDATA.

Untuk membatalkan perilaku ini, berikan perubahan skema. Misalnya, untuk melakukan migrasi objek skema PERFDATA ke skema PERFDATA pada titik akhir target, gunakan perubahan berikut.

{
    "rule-type": "transformation",
    "rule-id": "2",
    "rule-name": "2",
    "object-locator": {
        "schema-name": "PERFDATA"
    },
    "rule-target": "schema",
    "rule-action": "rename",
    "value": "PERFDATA"
}

Untuk informasi lebih lanjut tentang perubahan, lihat Menentukan pemilihan tabel dan transformasi aturan menggunakan JSON.

Mengubah tempat penyimpanan tabel dan indeks untuk target Oracle

Bila menggunakan Oracle sebagai target, AWS DMS melakukan migrasi semua tabel dan indeks ke ruang penyimpanan default dalam target. Misalnya, anggap bahwa sumber Anda adalah mesin basis data selain Oracle. Semua tabel dan indeks target dimigrasi ke tempat penyimpanan default yang sama.

Untuk membatalkan perilaku ini, berikan perubahan tempat penyimpanan yang sesuai. Sebagai contoh, misalkan Anda ingin melakukan migrasi tabel dan indeks ke tempat penyimpanan tabel dan indeks di target Oracle yang diberi nama sesuai skema dalam sumber. Dalam hal ini, Anda dapat menggunakan perubahan serupa dengan yang berikut. Di sini, skema dalam sumber diberi nama INVENTORY dan tempat penyimpanan tabel dan indeks yang sesuai dalam target diberi nama INVENTORYTBL dan INVENTORYIDX.

{
   "rule-type": "transformation",
   "rule-id": "3",
   "rule-name": "3",
   "rule-action": "rename",
   "rule-target": "table-tablespace",
   "object-locator": {
      "schema-name": "INVENTORY",
      "table-name": "%",
      "table-tablespace-name": "%"
   },
   "value": "INVENTORYTBL"
},
{
   "rule-type": "transformation",
   "rule-id": "4
   "rule-name": "4",
   "rule-action": "rename",
   "rule-target": "index-tablespace",
   "object-locator": {
      "schema-name": "INVENTORY",
      "table-name": "%",
      "index-tablespace-name": "%"
   },
   "value": "INVENTORYIDX"
}

Untuk informasi lebih lanjut tentang perubahan, lihat Menentukan pemilihan tabel dan transformasi aturan menggunakan JSON.

Apabila Oracle adalah sumber dan target, Anda dapat mempertahankan tugas tempat penyimpanan tabel atau indeks yang ada dengan menetapkan atribut koneksi tambahan sumber Oracle enableHomogenousTablespace=true. Untuk informasi lebih lanjut, lihat Pengaturan titik akhir saat menggunakan Oracle sebagai sumber AWS DMS.

Pemutakhiran versi instans replikasi

AWS secara berkala merilis versi baru dari perangkat lunak mesin replikasi AWS DMS, dengan fitur baru dan peningkatan performa. Setiap versi perangkat lunak mesin replikasi memiliki nomor versi sendiri. Sangat penting untuk menguji versi AWS DMS instans replikasi Anda yang menjalankan beban kerja produksi sebelum Anda memutakhirkan instans replikasi Anda ke versi yang lebih baru. Untuk informasi lebih lanjut tentang pemutakhiran versi, lihat Catatan rilis AWS DMS.

Memahami biaya migrasi Anda

AWS Database Migration Service membantu Anda melakukan migrasi basis data ke AWS secara mudah dan aman dengan biaya rendah. Anda hanya membayar untuk instans replikasi Anda dan penyimpanan setelah mencatat informasi tambahan. Setiap instans migrasi basis data termasuk penyimpanan yang cukup untuk ruang tukar, catatan replikasi, dan cache data untuk sebagian besar replikasi dan transfer data masuk adalah gratis.

Anda mungkin memerlukan lebih banyak sumber daya selama beban awal atau selama waktu unggah puncak. Anda dapat memantau penggunaan sumber daya instans replikasi menggunakan metrik cloud watch. Anda kemudian dapat menaikkan skala dan menurunkan skala ukuran instans replikasi berdasarkan penggunaan.

Untuk informasi lebih lanjut tentang memperkirakan biaya migrasi Anda, lihat: