Memecahkan masalah kesalahan RFC di AMS - Panduan Pengguna Tingkat Lanjut AMS
Kesalahan RFC “Manajemen”Kesalahan RFC “Penerapan”Validasi RFC versus kesalahan eksekusiPesan kesalahan RFCCara mendapatkan bantuan dengan RFC

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

Memecahkan masalah kesalahan RFC di AMS

Banyak kegagalan RFC penyediaan AMS dapat diselidiki melalui dokumentasi. CloudFormation Lihat Pemecahan Masalah AWS CloudFormation: Kesalahan Pemecahan Masalah

Saran pemecahan masalah tambahan disediakan di bagian berikut.

Kesalahan RFC “Manajemen” di AMS

AMS “Manajemen” Jenis perubahan kategori (CTs) memungkinkan Anda untuk meminta akses ke sumber daya serta mengelola sumber daya yang ada. Bagian ini menjelaskan beberapa masalah umum.

Kesalahan akses RFC

  • Pastikan Username dan FQDN yang Anda tentukan di RFC sudah benar dan ada di domain. Untuk bantuan menemukan FQDN Anda, lihat Menemukan FQDN Anda.

  • Pastikan ID tumpukan yang Anda tentukan untuk akses adalah tumpukan EC2 -related. Tumpukan seperti ELB dan Amazon Simple Storage Service (S3) bukan kandidat untuk RFCs akses, sebagai gantinya, gunakan peran akses baca saja untuk mengakses sumber daya tumpukan ini. Untuk bantuan menemukan ID tumpukan, lihat Menemukan tumpukan IDs

  • Pastikan ID tumpukan yang Anda berikan sudah benar dan milik akun yang relevan.

Untuk bantuan terkait kegagalan akses RFC lainnya, lihat Manajemen akses.

YouTube Video: Bagaimana cara mengajukan Request for Change (RFC) dengan benar untuk menghindari penolakan dan kegagalan?

Kesalahan penjadwalan CT RFC (manual)

Sebagian besar jenis perubahan adalah ExecutionMode = Otomatis, tetapi beberapa ExecutionMode = Manual dan itu memengaruhi cara Anda menjadwalkannya untuk menghindari kegagalan RFC.

Dijadwalkan RFCs dengan ExecutionMode =Manual, harus diatur untuk mengeksekusi setidaknya 24 jam di masa mendatang jika Anda menggunakan Konsol AMS untuk membuat RFC. Peringatan ini tidak berlaku untuk AMS API/CLI, tetapi masih penting untuk menjadwalkan Manual RFCs setidaknya 8 jam ke depan.

AMS bertujuan untuk menanggapi CT manual dalam waktu empat jam, dan akan berkorespondensi sesegera mungkin, tetapi bisa memakan waktu lebih lama bagi RFC untuk benar-benar dieksekusi.

Menggunakan RFCs dengan pembaruan manual CTs

Operasi AMS menolak Manajemen | Lainnya | Lainnya RFCs untuk pembaruan tumpukan, ketika ada jenis perubahan Pembaruan untuk jenis tumpukan yang ingin Anda perbarui.

Kesalahan tumpukan hapus RFC

Kegagalan tumpukan penghapusan RFC: Jika Anda menggunakan Manajemen | Tumpukan standar | Tumpukan | Hapus CT, Anda akan melihat peristiwa terperinci di AWS CloudFormation Konsol untuk tumpukan dengan nama tumpukan AMS. Anda dapat mengidentifikasi tumpukan Anda dengan memeriksanya terhadap nama yang ada di Konsol AMS. AWS CloudFormation Konsol memberikan rincian lebih lanjut tentang penyebab kegagalan.

Sebelum menghapus tumpukan, Anda harus mempertimbangkan bagaimana tumpukan dibuat. Jika Anda membuat tumpukan menggunakan AMS CT dan tidak menambahkan atau mengedit sumber daya tumpukan, Anda dapat menghapusnya tanpa masalah. Namun, itu adalah ide yang baik untuk Anda menghapus sumber daya yang ditambahkan secara manual dari tumpukan sebelum mengirimkan tumpukan hapus RFC terhadapnya. Misalnya, jika Anda membuat tumpukan menggunakan tumpukan penuh CT (HA Two Tier), itu termasuk grup keamanan - SG1. Jika Anda kemudian menggunakan AMS untuk membuat grup keamanan lain - SG2, dan mereferensikan yang baru SG2 di SG1 dibuat sebagai bagian dari tumpukan penuh, dan kemudian menggunakan CT tumpukan hapus untuk menghapus tumpukan, tidak SG1 akan dihapus seperti yang direferensikan oleh SG2.

penting

Menghapus tumpukan dapat memiliki konsekuensi yang tidak diinginkan dan tidak terduga. AMS lebih suka *tidak* menghapus tumpukan atau menumpuk sumber daya atas nama pelanggan karena alasan ini. Perhatikan, AMS hanya akan menghapus sumber daya atas nama Anda (melalui Mangement yang dikirimkan | Lainnya | Lainnya | Jenis perubahan pembaruan) yang tidak mungkin dihapus menggunakan jenis perubahan yang sesuai, otomatis, untuk dihapus. Pertimbangan tambahan:

  • Jika sumber daya diaktifkan untuk 'hapus perlindungan', AMS dapat membantu membuka blokir ini jika Anda mengirimkan Manajemen | Lainnya | Lainnya | Perbarui jenis perubahan dan, setelah perlindungan penghapusan dihapus, Anda dapat menggunakan CT otomatis untuk menghapus sumber daya tersebut.

  • Jika ada beberapa sumber daya dalam tumpukan, dan Anda hanya ingin menghapus sebagian dari sumber daya tumpukan, gunakan jenis perubahan CloudFormation Pembaruan (lihat CloudFormation Ingest Stack: Update). Anda juga dapat mengirimkan Manajemen | Lainnya | Lainnya | Perbarui jenis perubahan dan insinyur AMS dapat membantu Anda menyusun set perubahan, jika diperlukan.

  • Jika ada masalah dalam menggunakan CT CloudFormation Pembaruan karena drift, AMS dapat membantu jika Anda mengirimkan Manajemen | Lainnya | Lainnya | Pembaruan untuk menyelesaikan penyimpangan (sejauh yang didukung oleh CloudFormation Layanan AWS) dan memberikan ChangeSet yang kemudian dapat Anda validasi dan jalankan menggunakan CT, Management/Custom Stack/Stack From CloudFormation Template/Approve Changeset, dan Pembaruan otomatis.

AMS mempertahankan pembatasan di atas untuk membantu memastikan tidak ada penghapusan sumber daya yang tidak terduga atau tidak terduga.

Untuk informasi selengkapnya, lihat Pemecahan Masalah AWS CloudFormation: menghapus tumpukan gagal.

Kesalahan DNS pembaruan RFC

Beberapa RFCs untuk memperbarui zona yang dihosting DNS dapat gagal, beberapa tanpa alasan. Membuat beberapa RFCs sekaligus untuk memperbarui zona yang dihosting DNS (pribadi atau publik) dapat menyebabkan beberapa RFCs gagal karena mereka mencoba memperbarui tumpukan yang sama pada saat yang bersamaan. Manajemen perubahan AMS menolak atau gagal RFCs yang tidak dapat memperbarui tumpukan karena tumpukan sudah diperbarui oleh RFC lain. AMS merekomendasikan agar Anda membuat satu RFC sekaligus dan menunggu RFC berhasil sebelum menaikkan yang baru untuk tumpukan yang sama.

Kesalahan entitas IAM RFC

AMS menyediakan sejumlah peran dan profil IAM default ke dalam akun AMS yang dirancang untuk memenuhi kebutuhan Anda. Namun, Anda mungkin perlu meminta sumber daya IAM tambahan sesekali.

Proses untuk mengirimkan RFCs permintaan sumber daya IAM kustom mengikuti alur kerja standar untuk manual RFCs, tetapi proses persetujuan juga mencakup tinjauan keamanan untuk memastikan kontrol keamanan yang tepat ada. Oleh karena itu, prosesnya biasanya memakan waktu lebih lama daripada manual lainnya RFCs. Untuk mengurangi waktu siklus ini RFCs, ikuti panduan berikut.

Untuk informasi tentang apa yang kami maksud dengan tinjauan IAM dan cara memetakannya ke Standar Teknis dan proses Penerimaan Risiko kami, lihatMemahami ulasan keamanan RFC.

Permintaan sumber daya IAM umum:

  • Jika Anda meminta kebijakan yang berkaitan dengan aplikasi utama yang kompatibel dengan cloud, misalnya CloudEndure, lihat CloudEndure kebijakan IAM AMS yang telah disetujui sebelumnya: Buka paket file Contoh Zona Pendaratan WIGs Cloud Endure dan buka file customer_cloud_endure_policy.json

    catatan

    Jika Anda menginginkan kebijakan yang lebih permisif, diskusikan kebutuhan Anda dengan Anda CloudArchitect/CSDM dan dapatkan, jika diperlukan, AMS Security Review and Signoff sebelum mengirimkan RFC yang menerapkan kebijakan tersebut.

  • Jika Anda ingin mengubah sumber daya yang digunakan oleh AMS di akun Anda secara default, sebaiknya Anda meminta salinan sumber daya yang dimodifikasi, bukan perubahan pada yang sudah ada.

  • Jika Anda meminta izin untuk pengguna manusia (alih-alih melampirkan izin ke pengguna) lampirkan izin ke peran, lalu berikan izin kepada pengguna untuk mengambil peran tersebut. Untuk detail tentang hal ini, lihat Akses konsol AMS Advanced sementara.

  • Jika Anda memerlukan izin luar biasa untuk migrasi sementara atau alur kerja, berikan tanggal akhir untuk izin tersebut dalam permintaan Anda.

  • Jika Anda telah mendiskusikan subjek permintaan Anda dengan tim keamanan Anda, berikan bukti persetujuan mereka kepada CSDM Anda dengan sedetail mungkin.

Jika AMS menolak IAM RFC, kami memberikan alasan yang jelas untuk penolakan tersebut. Misalnya, kami mungkin menolak permintaan pembuatan kebijakan IAM dan menjelaskan kebijakan yang tidak pantas. Dalam hal ini, Anda dapat membuat perubahan yang diidentifikasi dan mengirimkan kembali permintaan. Jika kejelasan tambahan tentang status permintaan diperlukan, kirimkan permintaan layanan, atau hubungi CSDM Anda.

Daftar berikut menjelaskan risiko umum yang AMS coba mitigasi saat kami meninjau IAM Anda. RFCs Jika IAM RFC Anda memiliki salah satu risiko ini, itu dapat mengakibatkan penolakan RFC. Dalam kasus di mana Anda memerlukan pengecualian, AMS meminta persetujuan dari tim keamanan Anda. Untuk mencari pengecualian seperti itu, koordinasikan dengan CSDM Anda.

catatan

AMS dapat, dengan alasan apa pun, menolak perubahan apa pun pada sumber daya IAM di dalam akun. Untuk masalah mengenai penolakan RFC, hubungi Operasi AMS melalui permintaan layanan, atau hubungi CSDM Anda.

  • Eskalasi hak istimewa, seperti izin yang memungkinkan Anda mengubah izin Anda sendiri, atau untuk mengubah izin sumber daya lain di dalam akun. Contoh:

    • Penggunaan iam:PassRole dengan peran lain yang lebih istimewa.

    • Izin untuk kebijakan attach/detach IAM dari peran atau pengguna.

    • Modifikasi kebijakan IAM di akun.

    • Kemampuan untuk melakukan panggilan API dalam konteks infrastruktur manajemen.

  • Izin untuk mengubah sumber daya atau aplikasi yang diperlukan untuk menyediakan layanan AMS kepada Anda. Contoh:

    • Modifikasi infrastruktur AMS seperti benteng, host manajemen, atau infrastruktur EPS.

    • Penghapusan fungsi AWS Lambda manajemen log, atau aliran log.

    • Penghapusan atau modifikasi aplikasi CloudTrail pemantauan default.

    • Modifikasi Direktori Layanan Direktori Aktif (AD).

    • Menonaktifkan alarm CloudWatch (CW).

    • Modifikasi prinsip, kebijakan, dan ruang nama yang digunakan di akun sebagai bagian dari landing zone.

  • Penyebaran infrastruktur di luar praktik terbaik, seperti izin yang memungkinkan pembuatan infrastruktur dalam keadaan yang membahayakan keamanan informasi Anda. Contoh:

    • Pembuatan bucket S3 publik, atau tidak terenkripsi, atau berbagi volume EBS secara publik.

    • Penyediaan alamat IP publik.

    • Modifikasi kelompok keamanan untuk memungkinkan akses luas.

  • Izin yang terlalu luas yang dapat menyebabkan dampak aplikasi, seperti izin yang dapat mengakibatkan kehilangan data, kehilangan integritas, konfigurasi yang tidak tepat, atau gangguan layanan untuk infrastruktur Anda dan aplikasi di dalam akun. Contoh:

    • Menonaktifkan, atau mengarahkan, lalu lintas jaringan melalui suka atau. APIs ModifyNetworkInterfaceAttribute UpdateRouteTable

    • Menonaktifkan infrastruktur terkelola dengan melepaskan volume dari host yang dikelola.

  • Izin untuk layanan bukan bagian dari deskripsi layanan AMS dan tidak didukung oleh AMS.

    Layanan yang tidak tercantum dalam deskripsi Layanan AMS tidak dapat digunakan di akun AMS. Untuk meminta dukungan untuk fitur atau layanan, silakan hubungi CSDM Anda.

  • Izin yang tidak memenuhi tujuan yang Anda nyatakan karena terlalu murah hati, atau terlalu konservatif, atau diterapkan pada sumber daya yang salah. Contoh:

    • Permintaan s3:PutObject izin ke bucket S3 yang memiliki enkripsi KMS wajib, tanpa KMS:Encrypt izin ke kunci yang relevan.

    • Izin yang berkaitan dengan sumber daya yang tidak ada di akun.

    • IAM RFCs di mana deskripsi RFC tampaknya tidak cocok dengan permintaan.

Kesalahan RFC “Penerapan”

AMS “Deployment” Jenis perubahan kategori (CTs) memungkinkan Anda untuk meminta berbagai sumber daya yang didukung AMS ditambahkan ke akun Anda.

Sebagian besar AMS CTs yang membuat sumber daya didasarkan pada AWS CloudFormation templat. Sebagai pelanggan, Anda memiliki akses hanya-baca ke semua layanan AWS termasuk AWS CloudFormation, Anda dapat dengan cepat mengidentifikasi AWS CloudFormation tumpukan yang mewakili tumpukan Anda berdasarkan deskripsi tumpukan menggunakan AWS CloudFormation Konsol. Tumpukan yang gagal kemungkinan akan berada dalam keadaan DELETE_COMPLETE. Setelah Anda mengidentifikasi AWS CloudFormation tumpukan, peristiwa akan menunjukkan sumber daya spesifik yang gagal dibuat, dan mengapa.

Menggunakan CloudFormation dokumentasi untuk memecahkan masalah

Sebagian besar penyediaan AMS RFCs menggunakan CloudFormation templat dan dokumentasi tersebut dapat membantu pemecahan masalah. Lihat dokumentasi untuk AWS CloudFormation template itu:

RFC membuat kesalahan AMIs

Amazon Machine Image (AMI) adalah templat yang berisi konfigurasi perangkat lunak (misalnya, sistem operasi, server aplikasi, dan aplikasi). Dari AMI, Anda meluncurkan instance, yang merupakan salinan AMI yang berjalan sebagai server virtual di cloud. AMIs sangat berguna, dan diperlukan untuk membuat EC2 instance atau grup Auto Scaling; namun, Anda harus mematuhi beberapa persyaratan:

  • Instance yang Anda tentukan Ec2InstanceId harus dalam keadaan berhenti agar RFC berhasil. Jangan gunakan instans Auto Scaling group (ASG) untuk parameter ini karena ASG akan menghentikan instance yang dihentikan.

  • Untuk membuat AMS Amazon Machine Image (AMI), Anda harus memulai dengan instance AMS. Sebelum Anda dapat menggunakan instance untuk membuat AMI, Anda harus menyiapkannya dengan memastikan bahwa instans tersebut dihentikan dan tidak bergabung dari domainnya. Untuk detailnya, lihat Membuat Gambar Mesin Amazon Standar Menggunakan Sysprep

  • Nama yang Anda tentukan untuk AMI baru harus unik di dalam akun atau RFC gagal. Cara melakukannya dijelaskan dalam AMI | Buat, dan untuk detail selengkapnya, lihat dan AWS AMI Design.

catatan

Untuk informasi tambahan tentang persiapan pembuatan AMI, lihat AMI | Buat.

RFCs membuat EC2s atau ASGs kesalahan

Untuk EC2 atau kegagalan ASG dengan batas waktu, AMS menyarankan Anda mengonfirmasi apakah AMI yang digunakan disesuaikan. Jika ya, silakan lihat langkah-langkah pembuatan AMI yang disertakan dalam panduan ini (lihat AMI | Buat) untuk memastikan bahwa AMI dibuat dengan benar. Kesalahan umum saat membuat AMI kustom adalah tidak mengikuti langkah-langkah dalam panduan untuk mengganti nama atau memanggil Sysprep.

RFCs membuat kesalahan RDS

Kegagalan Amazon Relational Database Service (RDS) dapat terjadi karena berbagai alasan karena Anda dapat menggunakan banyak mesin yang berbeda saat membuat RDS, dan setiap mesin memiliki persyaratan dan keterbatasannya sendiri. Sebelum mencoba membuat tumpukan AMS RDS, tinjau nilai parameter AWS RDS dengan cermat, lihat Membuat. DBInstance

Untuk mempelajari lebih lanjut tentang Amazon RDS secara umum, termasuk rekomendasi ukuran, lihat Dokumentasi Layanan Amazon Relational Database Service.

RFCs membuat kesalahan Amazon S3

Satu kesalahan umum saat membuat bucket penyimpanan S3 adalah tidak menggunakan nama unik untuk bucket. Jika Anda mengirimkan bucket S3 Create CT dengan nama yang sama dengan yang dikirimkan sebelumnya, itu akan gagal karena bucket S3 sudah ada dengan itu. BucketName Ini akan dirinci di AWS CloudFormation Konsol, di mana Anda akan melihat bahwa peristiwa tumpukan menunjukkan bahwa nama bucket sudah digunakan.

Validasi RFC versus kesalahan eksekusi

Kegagalan RFC dan pesan terkait berbeda dalam pesan keluaran pada halaman detail RFC konsol AMS untuk RFC yang dipilih:

  • Alasan Kegagalan Validasi hanya tersedia di Bidang Status

  • Alasan Kegagalan Eksekusi tersedia di Output Eksekusi serta Bidang Status.

Request for change details showing rejected status due to no domain trust found.

Pesan kesalahan RFC

Ketika Anda menemukan kesalahan berikut untuk jenis perubahan yang tercantum (CTs), Anda dapat menggunakan solusi ini untuk membantu Anda menemukan sumber masalah dan memperbaikinya.

{"errorMessage":"An error has occurred during RFC execution. We are investigating the issue.","errorType":"InternalError"}

Jika Anda memerlukan bantuan lebih lanjut setelah merujuk pada opsi pemecahan masalah berikut, maka libatkan AMS melalui korespondensi RFC atau buat permintaan layanan. Lihat Korespondensi dan Lampiran RFC (Konsol) dan Membuat Permintaan Layanan di AMS untuk detail selengkapnya.

Kesalahan konsumsi beban kerja (WIGS)

catatan

Alat validasi untuk Windows dan Linux dapat diunduh dan dijalankan langsung di server lokal Anda, serta EC2 instance di AWS. Hal ini dapat ditemukan melalui Panduan Pengembang Aplikasi AMS Advanced Migrating workloads: Linux pre-ingestion validation dan Migrating workloads: Windows pre-ingestion validation.

  • Pastikan EC2 instance ada di akun AMS target. Misalnya, jika Anda telah membagikan AMI dari akun non-AMS ke akun AMS, Anda harus membuat EC2 instance di akun AMS dengan AMI bersama sebelum dapat mengirimkan RFC Workload Ingest.

  • Periksa untuk melihat apakah grup keamanan yang dilampirkan pada instance memiliki lalu lintas jalan keluar yang diizinkan. Agen SSM harus dapat terhubung ke titik akhir publiknya.

  • Periksa untuk melihat apakah instance memiliki izin yang tepat untuk terhubung dengan agen SSM. Izin ini disertakan dengancustomer-mc-ec2-instance-profile, Anda dapat memeriksanya di EC2 konsol:

    EC2 instance details showing IAM role set to customer-mc-ec2-instance-profile.

EC2 kesalahan penghentian tumpukan contoh

  • Periksa untuk melihat apakah instance sudah dalam keadaan berhenti atau dihentikan.

  • Jika EC2 instans sedang online dan Anda melihat InternalError kesalahan, maka kirimkan permintaan layanan untuk diselidiki AMS.

  • Perhatikan bahwa Anda tidak dapat menggunakan tipe perubahan Management | Advanced stack components | EC2 instance stack | Stop ct-3mvvt2zkyveqj untuk menghentikan instance Auto Scaling group (ASG). Jika Anda perlu menghentikan instans ASG, maka kirimkan permintaan layanan.

EC2 instance stack membuat kesalahan

InternalErrorPesannya berasal dari CloudFormation; alasan status CREATION_FAILED. Anda dapat menemukan detail tentang kegagalan tumpukan dalam peristiwa CloudWatch tumpukan dengan mengikuti langkah-langkah berikut:

  • Di konsol AWS Management, Anda dapat melihat daftar peristiwa tumpukan saat tumpukan dibuat, diperbarui, atau dihapus. Dari daftar ini, temukan peristiwa kegagalan dan kemudian lihat alasan status untuk peristiwa tersebut.

    Alasan status mungkin berisi pesan kesalahan dari AWS CloudFormation atau dari layanan tertentu yang dapat membantu Anda memahami masalah tersebut.

  • Untuk informasi selengkapnya tentang melihat peristiwa tumpukan, lihat Melihat Data dan Sumber Daya AWS CloudFormation Stack di AWS Management Console.

EC2 kesalahan pemulihan volume instance

AMS membuat RFC pemecahan masalah internal saat pemulihan volume EC2 instans gagal. Ini dilakukan karena pemulihan volume EC2 instans merupakan bagian penting dari pemulihan bencana (DR) dan AMS membuat RFC pemecahan masalah internal ini untuk Anda secara otomatis.

Saat RFC pemecahan masalah internal dibuat, spanduk ditampilkan memberi Anda tautan ke RFC. Pemecahan masalah internal RFC ini memberi Anda lebih banyak visibilitas ke kegagalan RFC dan, daripada mengirimkan percobaan ulang yang RFCs mengarah ke kesalahan yang sama, atau membuat Anda secara manual menjangkau AMS untuk kegagalan ini, Anda dapat melacak perubahan Anda dan mengetahui bahwa kegagalan sedang dikerjakan oleh AMS. Ini juga mengurangi metrik time-to-recovery (TTR) untuk perubahannya karena Operator AMS secara proaktif bekerja pada kegagalan RFC alih-alih menunggu permintaan Anda.

Cara mendapatkan bantuan dengan RFC

Anda dapat menghubungi AMS untuk mengidentifikasi akar penyebab kegagalan Anda. Jam kerja AMS adalah 24 jam sehari, 7 hari seminggu, 365 hari setahun.

AMS menyediakan beberapa jalan bagi Anda untuk meminta bantuan atau membuat permintaan layanan.

  • Untuk meminta informasi atau saran, atau akses ke layanan TI yang dikelola AMS, atau meminta layanan tambahan dari AMS, gunakan konsol AMS dan kirimkan permintaan layanan. Untuk detailnya, lihat Membuat Permintaan Layanan. Untuk informasi umum tentang permintaan layanan AMS, lihat Manajemen Permintaan Layanan.

  • Untuk melaporkan masalah kinerja layanan AWS atau AMS yang memengaruhi lingkungan terkelola Anda, gunakan konsol AMS dan kirimkan laporan insiden. Untuk detailnya, lihat Melaporkan Insiden. Untuk informasi umum tentang manajemen insiden AMS, lihat Respons insiden.

  • Untuk pertanyaan spesifik tentang bagaimana Anda atau sumber daya atau aplikasi Anda bekerja dengan AMS, atau untuk meningkatkan insiden, kirim email ke satu atau beberapa hal berikut:

    1. Pertama, jika Anda tidak puas dengan permintaan layanan atau tanggapan laporan insiden, kirimkan email ke CSDM Anda: ams-csdm@amazon.com

    2. Selanjutnya, jika eskalasi diperlukan, Anda dapat mengirim email ke Manajer Operasi AMS (tetapi CSDM Anda mungkin akan melakukannya): ams-opsmanager@amazon.com

    3. Eskalasi lebih lanjut akan ke Direktur AMS: ams-director@amazon.com

    4. Akhirnya, Anda selalu dapat menghubungi AMS VP: ams-vp@amazon.com