Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Modus RFC
Mode RFC adalah mode default untuk pelanggan rencana operasi AMS Advanced. Ini mencakup sistem manajemen perubahan dengan permintaan perubahan atau RFCs dan katalog jenis perubahan yang akan digunakan untuk meminta penambahan atau perubahan yang Anda butuhkan ke akun Anda. Sistem manajemen perubahan ini memberikan tingkat keamanan dalam membatasi siapa yang dapat melakukan perubahan pada akun Anda.
Untuk detail tentang jenis perubahan AMS Advanced, lihat [Apa itu Jenis Perubahan AMS?](https://docs.aws.amazon.com/managedservices/latest/ctref/index.html) .
Untuk detail tentang orientasi ke AMS Advanced, lihat [AWS Managed Services Onboarding](https://docs.aws.amazon.com/managedservices/latest/onboardingguide/index.html) Introduction.
Untuk contoh penelusuran jenis perubahan, lihat bagian “Informasi Tambahan” untuk jenis perubahan yang relevan di bagian *AMS Advanced Change Type Reference Change Type* [by Classification](https://docs.aws.amazon.com/managedservices/latest/ctref/classifications.html).
**catatan**
Mode RFC sebelumnya disebut “Mode Manajemen Ubah” atau “Mode CM Standar.”
**Topics**
+ [Pelajari tentang RFCs](ex-rfc-works.md)
+ [Apa itu jenis perubahan?](understanding-cts.md)
+ [Memecahkan masalah kesalahan RFC di AMS](rfc-troubleshoot.md)
# Pelajari tentang RFCs
Permintaan perubahan, atau RFCs, bekerja dengan cara dua kali lipat. Pertama, ada parameter yang diperlukan untuk RFC itu sendiri. Ini adalah opsi di `CreateRfc` API. Dan kedua, ada parameter yang diperlukan untuk aksi RFC (parameter eksekusi). Untuk mempelajari `CreateRfc` opsi, lihat [CreateRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_CreateRfc.html)bagian *Referensi AMS API*. Opsi ini biasanya muncul di area **Konfigurasi tambahan** pada halaman Buat RFC.
Anda dapat membuat dan mengirimkan RFC dengan `CreateRfc` API, `aws amscm create-rfc` CLI, atau menggunakan konsol AMS Buat halaman RFC. Untuk tutorial tentang membuat RFC, lihat[Buat RFC](ex-rfc-create-col.md).
**Topics**
+ [Apa itu RFCs?](what-r-rfcs.md)
+ [Mengautentikasi saat menggunakan AMS API/CLI](ex-rfc-authentication.md)
+ [Memahami ulasan keamanan RFC](rfc-security.md)
+ [Memahami klasifikasi tipe perubahan RFC](ex-rfc-csio.md)
+ [Memahami tindakan RFC dan status aktivitas](ex-rfc-action-state.md)
+ [Memahami kode status RFC](ex-rfc-status-codes.md)
+ [Memahami pembaruan RFC CTs dan deteksi drift CloudFormation template](ex-rfc-updates-and-dd.md)
+ [Jadwal RFCs](ex-rfc-scheduling.md)
+ [Menyetujui atau menolak RFCs](ex-rfc-approvals.md)
+ [Minta periode berjalan terbatas RFC](ex-rfc-restrict-execute.md)
+ [Buat, kloning, perbarui, temukan, dan batalkan RFCs](ex-rfc-use-examples.md)
+ [Gunakan konsol AMS dengan RFCs](ex-rfc-gui.md)
+ [Pelajari tentang parameter RFC umum](rfc-common-params.md)
+ [Mendaftar untuk email harian RFC](rfc-digest.md)
# Apa itu RFCs?
Permintaan perubahan, atau RFC, adalah cara Anda membuat perubahan di lingkungan yang dikelola AMS, atau meminta AMS untuk membuat perubahan atas nama Anda. Untuk membuat RFC, Anda memilih dari jenis perubahan AMS, pilih parameter RFC (seperti jadwal), lalu kirimkan permintaan menggunakan konsol AMS atau perintah [CreateRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_CreateRfc.html)API dan. [SubmitRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_SubmitRfc.html)
RFC berisi dua spesifikasi, satu untuk RFC itu sendiri, dan satu untuk parameter tipe perubahan (CT). Pada baris perintah, Anda dapat menggunakan perintah Inline RFC, atau CreateRfc template standar dalam format JSON, yang Anda isi dan kirimkan bersama dengan file skema CT JSON yang Anda buat (berdasarkan parameter CT). Nama CT adalah deskripsi informal dari CT. CSIO (kategori, subkategori, item, operasi) adalah deskripsi yang lebih formal dari CT. Hanya ID CT yang harus ditentukan saat membuat RFC.
RFCs melalui dua tahap kunci: Validasi dan Eksekusi.
1. Pada Tahap Validasi, AMS meninjau Permintaan RFC untuk kelengkapan dan kebenaran. AMS juga mengevaluasi permintaan keamanan sesuai dengan [standar teknis keamanan](rfc-security.md#rfc-security.title) kami. AMS memvalidasi bahwa perubahan yang diminta valid dan dapat dieksekusi.
1. Pada Tahap Eksekusi, AMS mencoba perubahan yang diminta pada akun Anda.
AMS menangani kedua tahapan melalui proses otomatis, proses manual, atau kombinasi keduanya. Proses manual ditangani oleh tim Operasi AMS. Untuk informasi selengkapnya, lihat [Otomatis dan manual CTs](ug-automated-or-manual.md).
AMS menyediakan tiga mode eksekusi untuk menangani permintaan:
+ **(Direkomendasikan AMS) Mode eksekusi: Otomatis**. Ini CTs menggunakan otomatisasi untuk validasi dan eksekusi RFC, yang merupakan cara tercepat untuk mencapai hasil bisnis Anda.
+ **(Disarankan AMS) Mode eksekusi: Manual dan Penunjukan: Otomatisasi Terkelola**. Ini CTs memanfaatkan kombinasi proses otomatis dan manual untuk validasi dan eksekusi RFC. Jika otomatisasi tidak dapat menjalankan perubahan yang Anda minta, maka RFC ditransfer (dengan perutean otomatis atau dengan pembuatan RFC pengganti) ke tim Operasi AMS untuk penanganan manual. Pengajuan ini CTs memungkinkan pengambilan permintaan Anda yang lebih terstruktur, dilengkapi dengan otomatisasi AMS untuk meningkatkan kerangka waktu hasil penanganan dan eksekusi.
+ **Mode eksekusi: Manual dan Penunjukan: Diperlukan Tinjauan**. Perubahan yang diminta melalui [ct-1e1xtak34nx76 Manajemen \$1 Lainnya \$1 Lainnya \$1 Pembaruan (diperlukan ulasan) atau [ct-0xdawir96cy7k](https://docs.aws.amazon.com/managedservices/latest/ctref/management-other-other-create-review-required.html) Manajemen \$1 Lainnya \$1 Lainnya \$1 Buat (ulasan diperlukan)](https://docs.aws.amazon.com/managedservices/latest/ctref/management-other-other-update-review-required.html). Ini CTs bergantung pada penanganan manual untuk validasi dan eksekusi. Ini CTs tergantung pada interpretasi manual dari permintaan perubahan.
AMS memberi tahu Anda ketika perubahan telah berhasil diselesaikan (Sukses) atau tidak berhasil (Kegagalan).
**catatan**
Untuk informasi tentang pemecahan masalah kegagalan RFC, lihat. [Memecahkan masalah kesalahan RFC di AMS](rfc-troubleshoot.md)
Grafik berikut menggambarkan alur kerja RFC yang dikirimkan oleh Anda.
![\[Alur kerja RFC yang dikirimkan pelanggan.\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/images/requestForChange-v5g.png)
# Mengautentikasi saat menggunakan AMS API/CLI
Saat Anda menggunakan AMS API/CLI, Anda harus mengautentikasi dengan kredensi sementara. Untuk meminta kredensil keamanan sementara untuk pengguna federasi, cal,, [AssumeRoleWithSALL [ GetFederationToken[AssumeRole](https://docs.aws.amazon.com/STS/latest/UsingSTS/sts_delegate.html)](https://docs.aws.amazon.com/STS/latest/UsingSTS/CreatingFedTokens.html),](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerolewithsaml) atau [ AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerolewithwebidentity)AWS security token service (STS). APIs
Pilihan umum adalah SAFL. Setelah disiapkan, Anda menambahkan argumen ke setiap operasi yang Anda panggil. Sebagai contoh: `aws --profile saml amscm list-change-type-categories`.
Pintasan untuk profil SAFL 2.0 adalah mengatur variabel profil di awal masing-masing API/CLI dengan `set AWS_DEFAULT_PROFILE=saml` (untuk Windows; untuk Linux itu akan`export AWS_DEFAULT_PROFILE=saml`). Untuk informasi tentang menyetel variabel lingkungan CLI, lihat [Mengonfigurasi Antarmuka Baris Perintah AWS,](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-environment) Variabel Lingkungan.
# Memahami ulasan keamanan RFC
Proses persetujuan manajemen perubahan AWS Managed Services (AMS) memastikan bahwa kami melakukan tinjauan keamanan terhadap perubahan yang kami buat di akun Anda.
AMS mengevaluasi semua permintaan untuk perubahan (RFCs) terhadap standar teknis AMS. Setiap perubahan yang mungkin menurunkan postur keamanan akun Anda dengan menyimpang dari standar teknis, akan melalui tinjauan keamanan. Selama tinjauan keamanan, AMS menyoroti risiko yang relevan dan, dalam kasus risiko keamanan tinggi atau sangat tinggi, petugas keamanan resmi Anda menerima atau menolak RFC. Semua perubahan juga dievaluasi untuk menilai dampak buruk pada kemampuan AMS untuk beroperasi. Jika potensi dampak buruk ditemukan, maka tinjauan dan persetujuan tambahan diperlukan dalam AMS.
## Standar teknis AMS
Standar Teknis AMS menentukan kriteria keamanan minimum, konfigurasi, dan proses untuk menetapkan keamanan dasar akun Anda. Standar ini harus diikuti oleh AMS dan Anda.
Setiap perubahan yang berpotensi menurunkan postur keamanan akun Anda dengan menyimpang dari standar teknis, akan melalui proses Penerimaan Risiko, di mana risiko yang relevan disorot oleh AMS dan diterima atau ditolak oleh petugas keamanan yang berwenang dari pihak Anda. Semua perubahan tersebut juga dievaluasi untuk menilai apakah akan ada dampak buruk pada kemampuan AMS untuk mengoperasikan akun dan, jika demikian, ulasan dan persetujuan tambahan diperlukan dalam AMS.
## Proses manajemen risiko keamanan pelanggan (CSRM) RFC
Ketika seseorang dari organisasi Anda meminta perubahan pada lingkungan terkelola Anda, AMS meninjau perubahan tersebut untuk menentukan apakah permintaan tersebut dapat memperburuk postur keamanan akun Anda dengan berada di luar standar teknis. Jika permintaan menurunkan postur keamanan akun, AMS memberi tahu kontak tim keamanan Anda dengan risiko yang relevan, dan mengeksekusi perubahan; atau, jika perubahan tersebut menimbulkan risiko keamanan yang tinggi atau sangat tinggi di lingkungan, AMS meminta persetujuan eksplisit dari kontak tim keamanan Anda dalam bentuk penerimaan risiko (dijelaskan selanjutnya). Proses Penerimaan Risiko Pelanggan AMS dirancang untuk:
+ Memastikan risiko diidentifikasi dan dikomunikasikan dengan jelas kepada pemilik yang tepat
+ Minimalkan risiko yang teridentifikasi terhadap lingkungan Anda
+ Mendapatkan dan mendokumentasikan persetujuan dari kontak keamanan yang ditunjuk yang memahami profil risiko organisasi Anda
+ Mengurangi overhead operasional yang sedang berlangsung untuk risiko yang teridentifikasi
## Cara mengakses standar teknis dan risiko tinggi atau sangat tinggi
Kami telah membuat dokumentasi Standar Teknis AMS tersedia untuk referensi Anda dalam [https://console.aws.amazon.com/artifact/](https://console.aws.amazon.com/artifact/)sebagai laporan. Gunakan dokumentasi Standar Teknis AMS untuk memahami apakah perubahan akan memerlukan penerimaan risiko dari kontak keamanan resmi Anda sebelum mengirimkan permintaan perubahan (RFC).
Temukan laporan Standar Teknis dengan menelusuri “Standar Teknis AWS Managed Services (AMS)” di bilah pencarian tab AWS Artifact **Laporan** setelah masuk dengan default **AWSManagedServicesChangeManagementRole**.
**catatan**
Dokumen standar teknis AMS dapat diakses oleh Customer\$1 ReadOnly \$1Role di landing zone akun tunggal. Di landing zone multi-akun, yang AWSManaged ServicesAdminRole digunakan oleh admin keamanan dan AWSManaged ServicesChangeManagementRole digunakan oleh tim aplikasi, dapat digunakan untuk mengakses dokumen. Jika tim Anda menggunakan peran kustom, buat Other \$1 Other RFC untuk meminta akses dan kami akan memperbarui peran kustom yang ditentukan.
# Memahami klasifikasi tipe perubahan RFC
Jenis perubahan yang Anda gunakan saat mengirimkan RFC dibagi menjadi dua kategori besar:
+ **Deployment**: Klasifikasi ini untuk membuat sumber daya.
+ **Manajemen**: Klasifikasi ini untuk memperbarui atau menghapus sumber daya. Kategori **Manajemen** juga berisi jenis perubahan untuk mengakses instance, mengenkripsi atau berbagi, dan memulai, menghentikan AMIs, me-reboot, atau menghapus tumpukan.
# Memahami tindakan RFC dan status aktivitas
`RfcActionState`(API)/**Status Aktivitas** (konsol) membantu Anda memahami status intervensi manusia, atau tindakan, pada RFC. Digunakan terutama untuk manual RFCs, `RfcActionState` membantu Anda memahami kapan ada tindakan yang diperlukan oleh Anda atau operasi AMS, dan membantu Anda melihat kapan Operasi AMS secara aktif mengerjakan RFC Anda. Ini memberikan peningkatan transparansi ke dalam tindakan yang diambil pada RFC selama siklus hidupnya.
`RfcActionState`Definisi (API)/**Status Aktivitas** (konsol):
+ **AwsOperatorAssigned**: Operator AWS secara aktif mengerjakan RFC Anda.
+ **AwsActionPending**: Respons atau tindakan dari AWS diharapkan.
+ **CustomerActionPending**Respons atau tindakan dari pelanggan diharapkan.
+ **NoActionPending**: Tidak ada tindakan yang diperlukan dari AWS atau pelanggan.
+ **NotApplicable**: Status ini tidak dapat diatur oleh operator AWS atau pelanggan, dan hanya digunakan untuk RFCs yang dibuat sebelum fungsionalitas ini dirilis.
Status tindakan RFC berbeda tergantung pada apakah jenis perubahan yang dikirimkan memerlukan peninjauan manual dan penjadwalan disetel ke **ASAP** atau tidak.
+ **ActionState**Perubahan RFC selama peninjauan, persetujuan, dan dimulainya jenis perubahan manual dengan penjadwalan yang ditangguhkan:
+ Setelah Anda mengirimkan manual, terjadwal, RFC, **ActionState**secara otomatis berubah **AwsActionPending**untuk menunjukkan bahwa operator perlu meninjau dan menyetujui RFC.
+ Ketika operator mulai secara aktif meninjau RFC Anda, **ActionState**perubahan menjadi. **AwsOperatorAssigned**
+ Ketika operator menyetujui RFC Anda, Status RFC berubah menjadi Terjadwal, dan **ActionState**secara otomatis berubah menjadi. **NoActionPending**
+ Ketika waktu mulai yang dijadwalkan dari RFC tercapai, Status RFC berubah menjadi **InProgress**, dan **ActionState**secara otomatis berubah **AwsActionPending**untuk menunjukkan bahwa operator perlu ditugaskan untuk meninjau RFC.
+ Ketika operator mulai aktif menjalankan RFC, mereka mengubah **ActionState**ke **AwsOperatorAssigned**.
+ Setelah selesai, Operator menutup RFC. Ini secara otomatis mengubah **ActionState**ke **NoActionPending**.
![\[RFC ActionStateberubah selama peninjauan, persetujuan, dan dimulainya jenis perubahan manual dengan penjadwalan yang ditangguhkan\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/images/actionStateRfc.png)
**penting**
Status tindakan tidak dapat diatur oleh Anda. Mereka diatur secara otomatis berdasarkan perubahan dalam RFC, atau diatur secara manual oleh operator AMS.
Jika Anda menambahkan korespondensi ke RFC, secara otomatis **ActionState**diatur ke. **AwsActionPending**
Ketika RFC dibuat, secara otomatis **ActionState**diatur ke **NoActionPending**.
Ketika RFC dikirimkan, secara otomatis **ActionState**diatur ke **AwsActionPending**.
Ketika RFC Ditolak, Dibatalkan, atau dilengkapi dengan status Sukses atau Kegagalan, secara otomatis **ActionState**diatur ulang ke. **NoActionPending**
Status tindakan diaktifkan untuk otomatis dan manual RFCs, tetapi sebagian besar penting untuk manual RFCs karena jenis tersebut RFCs sering memerlukan komunikasi.
# Tinjau contoh kasus penggunaan status tindakan RFC
**Kasus Penggunaan: Visibilitas pada Proses RFC Manual**
+ Setelah Anda mengirimkan RFC manual, status tindakan RFC secara otomatis berubah `AwsActionPending` untuk menunjukkan bahwa operator perlu meninjau dan menyetujui RFC. Ketika operator mulai secara aktif meninjau RFC Anda, status tindakan RFC berubah menjadi. `AwsOperatorAssigned`
+ Pertimbangkan RFC manual yang telah disetujui dan dijadwalkan dan siap untuk mulai berjalan. Setelah status RFC berubah`InProgress`, status tindakan RFC secara otomatis berubah menjadi. `AwsActionPending` Ini berubah lagi menjadi `AwsOperatorAssigned` setelah operator mulai aktif menjalankan RFC.
+ Ketika RFC manual selesai (ditutup sebagai “Sukses” atau “Kegagalan”), status Tindakan RFC berubah `NoActionPending` untuk menunjukkan bahwa tidak ada tindakan lebih lanjut yang diperlukan baik dari pelanggan atau operator.
**Kasus penggunaan: korespondensi RFC**
+ Ketika RFC manual`Pending Approval`, Operator AMS mungkin memerlukan informasi lebih lanjut dari Anda. Operator akan memposting korespondensi ke RFC dan mengubah status tindakan RFC menjadi. `CustomerActionPending` Saat Anda merespons dengan menambahkan korespondensi RFC baru, status tindakan RFC secara otomatis berubah menjadi. `AwsActionPending`
+ Ketika RFC otomatis atau manual gagal, Anda dapat menambahkan korespondensi ke detail RFC, menanyakan kepada Operator AMS mengapa RFC gagal. Ketika korespondensi Anda ditambahkan, status tindakan RFC secara otomatis diatur ke. `AwsActionPending` Saat operator AMS mengambil RFC untuk melihat korespondensi Anda, status tindakan RFC berubah menjadi. `AwsOperatorAssigned` Ketika operator merespons dengan menambahkan korespondensi RFC baru, status tindakan RFC dapat diatur`CustomerActionPending`, menunjukkan bahwa ada respons lain dari pelanggan yang diharapkan, atau ke`NoActionPending`, yang menunjukkan bahwa tidak ada respons dari pelanggan yang diperlukan atau diharapkan.
# Memahami kode status RFC
Kode status RFC membantu Anda melacak permintaan Anda. Anda dapat mengamati kode status ini selama RFC berjalan di output CLI, atau dengan menyegarkan halaman daftar RFC di konsol.
Anda juga dapat melihat kode untuk RFC di halaman detail untuk RFC itu, yang mungkin terlihat seperti ini:
![\[Kode status RFC.\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/images/guiRfcStatusCodes.png)
Anda mungkin melihat RFC dalam daftar yang tidak Anda kirimkan. Ketika operator AMS menggunakan CT internal saja, mereka mengirimkannya dalam RFC dan ditampilkan dalam daftar RFC Anda. Untuk informasi selengkapnya, lihat [Jenis perubahan hanya internal](ct-internals.md).
**penting**
Anda dapat meminta pemberitahuan perubahan status RFC. Untuk detailnya, lihat [Pemberitahuan Perubahan Status RFC](https://docs.aws.amazon.com/managedservices/latest/userguide/rfc-state-change-notices.html).
**Kode status RFC**
| Berhasil | Kegagalan |
| --- | --- |
| Pengeditan: RFC telah dibuat tetapi tidak dikirimkan PendingApproval /Dikirim: RFC telah diserahkan dan sistem menentukan apakah memerlukan persetujuan, dan mendapatkan persetujuan itu, jika diperlukan Disetujui oleh AWS/Disetujui oleh pelanggan: RFC telah disetujui. Otomatis RFCs disetujui oleh AWS, manual RFCs disetujui oleh Operator dan, terkadang, pelanggan Dijadwalkan: RFC telah lulus sintaks dan pemeriksaan persyaratan dan dijadwalkan untuk berjalan InProgress: RFC sedang dijalankan, perhatikan RFCs bahwa penyediaan banyak sumber daya atau telah berjalan lama UserData, membutuhkan waktu lebih lama untuk dijalankan Dieksekusi: RFC telah dijalankan Sukses/Berhasil: RFC telah berhasil diselesaikan | Ditolak: ditolak RFCs biasanya karena gagal validasi; misalnya, sumber daya yang tidak dapat digunakan, yaitu subnet, ditentukan Dibatalkan: RFCs biasanya dibatalkan karena tidak lulus validasi sebelum waktu mulai yang dikonfigurasi berlalu Kegagalan: RFC telah gagal; lihat output untuk alasan kegagalan, dan operasi AMS secara otomatis membuat tiket masalah dan berkomunikasi dengan Anda sesuai kebutuhan StatusReason |
**catatan**
Dibatalkan atau ditolak RFCs dapat dikirimkan kembali menggunakan [UpdateRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_UpdateRfc.html); lihat juga. [Perbarui RFCs](ex-update-rfcs.md)
Jika RFC melewati semua kondisi yang diperlukan (misalnya, semua parameter yang diperlukan ditentukan), status berubah menjadi `PendingApproval` (bahkan otomatis CTs memerlukan persetujuan, yang terjadi secara otomatis jika sintaks dan pemeriksaan parameter lulus). Jika tidak lulus, statusnya berubah menjadi`Rejected`. `StatusReason`Memberikan informasi tentang penolakan; `ExecutionOutput` bidang memberikan informasi tentang persetujuan dan penyelesaian. Kode kesalahan meliputi:
+ InvalidRfcStateException: RFC berada dalam status yang tidak mengizinkan operasi yang dipanggil. Misalnya, jika RFC telah pindah ke status Kirim, itu tidak dapat lagi dimodifikasi.
+ InvalidRfcScheduleException: StartTime, EndTime, atau TimeoutInMinutes parameter dilanggar.
+ InternalServerError: Kesulitan dengan sistem ditemui.
+ InvalidArgumentException: Parameter salah ditentukan; misalnya, nilai yang tidak dapat diterima digunakan.
+ ResourceNotFoundException: Nilai, seperti ID tumpukan, tidak dapat ditemukan.
Jika waktu mulai dan akhir yang dijadwalkan yang diminta (juga dikenal sebagai jendela jalankan perubahan) terjadi sebelum perubahan disetujui, status RFC akan berubah menjadi`Canceled`. Jika perubahan disetujui, status RFC berubah menjadi`Scheduled`. Jendela change run untuk ASAP RFCs adalah waktu yang dikirimkan ditambah `ExpectedExecutionDuration` nilai untuk CT.
Kapan saja sebelum kedatangan jendela run perubahan, perubahan terjadwal (dikirimkan dengan a `RequestedStartTime` di CLI) dapat dimodifikasi atau dibatalkan. Jika perubahan yang dijadwalkan diubah, maka harus dikirimkan kembali.
Ketika waktu mulai perubahan tiba (dijadwalkan atau ASAP) dan setelah persetujuan selesai, status berubah `InProgress` dan tidak ada modifikasi yang dapat dilakukan. Jika perubahan selesai dalam jendela run perubahan yang ditentukan, status berubah menjadi`Success`. Jika ada bagian dari perubahan yang gagal, atau jika perubahan masih berlangsung saat jendela run change berakhir, status akan berubah menjadi`Failure`.
**catatan**
Selama`InProgress`,`Success`, atau `Failure` mengubah status, RFC tidak dapat dimodifikasi atau dibatalkan.
Diagram berikut mengilustrasikan status RFC dari panggilan CreateRFC hingga resolusi.
![\[Status RFC dari panggilan CreateRFC hingga resolusi.\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/images/RfcStateFlow2.png)
# Memahami pembaruan RFC CTs dan deteksi drift CloudFormation template
Sumber daya yang disediakan di AMS menggunakan templat yang dimodifikasi CloudFormation . Jika sumber daya memiliki parameter yang diubah secara langsung melalui Konsol AWS Manajemen layanan, maka catatan CloudFormation pembuatan sumber daya tersebut menjadi tidak sinkron. Jika ini terjadi dan Anda mencoba menggunakan jenis perubahan pembaruan AMS untuk memperbarui sumber daya di AMS, AMS mereferensikan konfigurasi sumber daya asli dan berpotensi mengatur ulang parameter yang diubah. Reset ini mungkin merusak, jadi AMS melarang RFCs dengan jenis perubahan pembaruan jika ada perubahan konfigurasi AMS tambahan yang terdeteksi.
Untuk daftar jenis perubahan pembaruan, gunakan filter konsol.
## Remediasi drift FAQs
Pertanyaan dan jawaban tentang remediasi drift AMS. Ada dua jenis perubahan yang dapat Anda gunakan untuk memulai remediasi drift, satu adalah mode eksekusi = manual atau “otomatisasi terkelola,” yang lainnya adalah mode eksekusi = otomatis.
### Sumber daya yang didukung remediasi drift (ct-3kinq0u4l33zf)
Ini adalah sumber daya yang didukung oleh tipe perubahan remediasi drift, (ct-3kinq0u4l33zf). Untuk remediasi sumber daya apa pun, gunakan jenis perubahan “otomatisasi terkelola” (ct-34sxfo53yuzah) sebagai gantinya.
```
AWS::EC2::Instance
AWS::EC2::SecurityGroup
AWS::EC2::VPC
AWS::EC2::Subnet
AWS::EC2::NetworkInterface
AWS::EC2::EIP
AWS::EC2::InternetGateway
AWS::EC2::NatGateway
AWS::EC2::NetworkAcl
AWS::EC2::RouteTable
AWS::EC2::Volume
AWS::AutoScaling::AutoScalingGroup
AWS::AutoScaling::LaunchConfiguration
AWS::AutoScaling::LifecycleHook
AWS::AutoScaling::ScalingPolicy
AWS::AutoScaling::ScheduledAction
AWS::ElasticLoadBalancing::LoadBalancer
AWS::ElasticLoadBalancingV2::Listener
AWS::ElasticLoadBalancingV2::ListenerRule
AWS::ElasticLoadBalancingV2::LoadBalancer
AWS::CloudWatch::Alarm
```
### Jenis perubahan remediasi drift
Pertanyaan dan jawaban tentang penggunaan jenis perubahan remediasi drift AMS.
Untuk daftar sumber daya yang didukung untuk fitur remediasi drift, lihat. [Sumber daya yang didukung remediasi drift (ct-3kinq0u4l33zf)](#drift-remeditate-faqs-sr)
**penting**
Remediasi drift memodifikasi and/or parameter template tumpukan dan wajib untuk memperbarui repositori template lokal Anda atau otomatisasi apa pun yang memperbarui tumpukan ini untuk menggunakan templat dan parameter tumpukan terbaru. Menggunakan and/or parameter template lama tanpa sinkronisasi dapat menyebabkan perubahan merusak pada sumber daya yang mendasarinya.
Otomatisasi tanpa terkelola, otomatis, CT (ct-3kinq0u4l33zf) mendukung remediasi hanya 10 sumber daya per RFC. Untuk memulihkan sumber daya yang tersisa dalam batch 10 buat yang baru RFCs sampai semua sumber daya diperbaiki.
Jenis perubahan remediasi drift mana yang harus saya gunakan?
Sebaiknya gunakan **otomatisasi tanpa terkelola**, CT otomatis (ct-3kinq0u4l33zf) saat:
+ Anda mencoba melakukan pembaruan ke sumber daya tumpukan yang ada menggunakan CT otomatis dan RFC ditolak sebagai tumpukan. `DRIFTED`
+ Anda menggunakan Update CT di masa lalu dan gagal karena tumpukannya DRIFTED. Anda tidak perlu mencoba pembaruan lagi dan dapat menggunakan otomatisasi terkelola, manual, CT sebagai gantinya.
Kami merekomendasikan penggunaan **otomatisasi terkelola**, CT manual (ct-34sxfo53yuzah) hanya ketika jenis sumber daya yang hanyut tidak didukung oleh remediasi drift tidak ada otomatisasi terkelola, otomatis, CT (ct-3kinq0u4l33zf), atau ketika remediasi drift tidak ada otomatisasi terkelola, otomatis, CT gagal.
Perubahan apa yang dilakukan pada tumpukan selama remediasi?
Remediasi memerlukan pembaruan ke and/or parameter template tumpukan tergantung pada properti yang hanyut. Remediasi juga memperbarui kebijakan tumpukan tumpukan selama remediasi dan mengembalikan kebijakan tumpukan ke nilai sebelumnya setelah remediasi selesai.
Bagaimana kita bisa melihat perubahan yang dilakukan pada and/or parameter template tumpukan?
Dalam menanggapi RFC, ringkasan perubahan disediakan dengan informasi berikut:
+ `ChangeSummaryJson`: Berisi ringkasan perubahan and/or Parameter Template Stack sebagai bagian dari remediasi drift. Remediasi dilakukan dalam beberapa fase. Ringkasan perubahan ini terdiri dari perubahan untuk fase individu. Jika Remediasi berhasil periksa perubahan fase terakhir. Lihat ExecutionPlan di JSON untuk fase yang dieksekusi secara berurutan. Misalnya, RestoreReferences bagian saat hadir selalu dieksekusi di akhir dan berisi JSON untuk perubahan pasca remediasi. Jika remediasi dijalankan dalam DryRun mode, tidak satu pun dari perubahan ini akan diterapkan ke tumpukan.
+ `PreRemediationStackTemplateAndConfigurationJson`: Berisi snapshot konfigurasi CloudFormation Stack termasuk Template, Parameter, Output, StackPolicyBody sebelum remediasi dipicu pada tumpukan.
Apa yang harus saya lakukan setelah remediasi dilakukan?
Anda perlu memperbarui repositori template lokal Anda, atau otomatisasi apa pun, yang akan memperbarui tumpukan yang diperbaiki, dengan templat dan parameter terbaru yang disediakan dalam ringkasan RFC. Hal ini sangat penting untuk melakukan ini karena menggunakan and/or parameter template lama dapat menyebabkan perubahan destruktif lebih lanjut pada sumber daya stack.
Apakah aplikasi saya akan diterapkan selama remediasi ini?
Remediasi adalah proses offline yang dilakukan hanya pada konfigurasi CloudFormation tumpukan. Tidak ada pembaruan yang dilakukan pada sumber daya yang mendasarinya.
Dapatkah saya terus menggunakan Manajemen \$1 Lainnya \$1 Lainnya RFCs untuk melakukan pembaruan sumber daya setelah perbaikan?
Kami menyarankan agar Anda selalu melakukan pembaruan untuk menumpuk sumber daya menggunakan Pembaruan otomatis yang tersedia CTs. Jika Pembaruan yang tersedia CTs tidak mendukung kasus penggunaan Anda, gunakan Manajemen \$1 Lainnya \$1 Permintaan lainnya.
Apakah remediasi membuat sumber daya baru di tumpukan?
Remediasi tidak membuat sumber daya baru di tumpukan. Namun, remediasi membuat output baru dan memperbarui bagian [metadata](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/metadata-section-structure.html) template tumpukan untuk menyimpan ringkasan remediasi untuk referensi Anda.
Akankah remediasi selalu berhasil?
Remediasi memerlukan analisis dan validasi konfigurasi template yang cermat untuk menentukan apakah itu dapat dilakukan. Dalam skenario di mana validasi ini gagal, proses remediasi dihentikan dan tidak ada perubahan yang dilakukan pada template tumpukan atau parameter. Selain itu, remediasi hanya dapat dilakukan pada jenis sumber daya yang didukung.
Bagaimana saya bisa melakukan pembaruan untuk menumpuk sumber daya jika remediasi tidak berhasil?
Anda dapat menggunakan Manajemen \$1 Lainnya \$1 Lainnya \$1 Perbarui CT (ct-0xdawir96cy7k) untuk meminta perubahan. AMS memantau skenario tersebut dan bekerja untuk meningkatkan solusi remediasi.
Dapatkah saya memulihkan tumpukan yang memiliki tipe sumber daya yang didukung dan tidak didukung?
Ya. Namun, remediasi dilakukan hanya jika jenis sumber daya yang didukung ditemukan DRIFTED di tumpukan. Jika ada jenis sumber daya yang tidak didukung DRIFTED, remediasi tidak akan dilanjutkan.
Dapatkah saya meminta remediasi untuk tumpukan yang dibuat melalui non-CFN Ingest? CTs
Ya. Remediasi dapat dilakukan pada tumpukan terlepas dari jenis perubahan yang digunakan untuk membuat tumpukan.
Dapatkah saya mengetahui perubahan yang akan dilakukan pada tumpukan sebelum perbaikan?
Ya. Kedua jenis perubahan menyediakan **DryRun**opsi yang dapat Anda gunakan untuk meminta perubahan yang akan dilakukan jika tumpukan diperbaiki. Namun, perubahan remediasi akhir mungkin berbeda tergantung pada penyimpangan yang ada pada tumpukan pada saat remediasi.
# Jadwal RFCs
Fitur **Penjadwalan** memungkinkan Anda memilih waktu mulai untuk RFCs. Opsi berikut tersedia di fitur **Penjadwalan**:
+ **Jalankan perubahan ini secepatnya**: AMS menjalankan RFC segera setelah disetujui. Sebagian CTs besar disetujui secara otomatis. Gunakan opsi ini jika tidak ingin RFC dimulai pada waktu tertentu.
+ **Jadwalkan perubahan ini**: Tetapkan hari, waktu, dan zona waktu agar RFC berjalan. Untuk jenis perubahan otomatis, ini adalah praktik terbaik untuk meminta waktu mulai yang setidaknya 10 menit setelah Anda berencana untuk mengirimkan RFC. Untuk jenis perubahan otomatisasi terkelola, Anda harus meminta waktu mulai setidaknya 24 jam setelah Anda berencana mengirimkan RFC. Jika RFC tidak disetujui oleh waktu mulai yang dikonfigurasi, maka RFC ditolak.
## Tetapkan jadwal RFC
Untuk menjadwalkan RFC, gunakan salah satu metode berikut:
**Jalankan perubahan ini secepatnya**:
+ Konsol: Jangan lakukan apa pun. Ini menggunakan jadwal RFC default.
+ API atau CLI: Hapus `RequestedEndTime` opsi `RequestedStartTime` dan dalam operasi Buat RFC.
**ASAP** “otomatisasi RFCs terkelola” ditolak secara otomatis jika tidak disetujui dalam waktu tiga puluh hari sejak pengiriman.
**Jadwalkan perubahan ini**:
+ Konsol: Pilih tombol **Jadwalkan perubahan radio ini**. Area **waktu mulai** terbuka. Ketik secara manual dalam sehari atau gunakan widget kalender untuk memilih hari. Masukkan waktu, dalam UTC, dinyatakan dalam format ISO 8601, dan gunakan daftar drop-down untuk memilih lokasi. Secara default, AMS menggunakan format ISO 8601 Z atau:MM: YYYYMMDDThhmmss YYYY-MM-DDThh SSZ, salah satu format diterima.
**catatan**
**Waktu Akhir Default** adalah 4 jam dari **waktu Mulai** yang Anda masukkan. Untuk mengatur **Waktu Akhir** perubahan terjadwal Anda melebihi 4 jam, gunakan API atau CLI untuk menjalankan perubahan.
+ API atau CLI: Kirim nilai untuk `RequestedStartTime` dan `RequestedEndTime` parameter dalam operasi Buat RFC. Melewati konfigurasi `RequestedEndTime` tidak menghentikan proses untuk jenis perubahan otomatis yang telah dimulai. Untuk jenis perubahan “otomatisasi terkelola”, jika `RequestedEndTime` tercapai saat riset Operasi AMS masih berlangsung, dan Anda berkomunikasi dengan AMS, maka Anda dapat meminta ekstensi, atau Anda mungkin diminta untuk mengirimkan ulang RFC.
**Tip**
Untuk contoh pembacaan waktu UTC, lihat UTC di situs web [Time-is](https://time.is/UTC). ****Contoh format ISO 8601 untuk date/time nilai 2016-12-05 pada 2:20pm: 2016-12-05T 14:20:00 Z atau 20161205T142000Z.****
Jika Anda memberikan...
+ hanya a`RequestedStartTime`, RFC dianggap dijadwalkan dan `RequestedEndTime` diisi menggunakan nilai. `ExecutionDurationInMinutes`
+ hanya a`RequestedEndTime`, kami melempar InvalidArgumentException.
+ keduanya `RequestedStartTime` dan`RequestedEndTime`, kami menimpa `RequestedEndTime` dengan waktu mulai yang ditentukan ditambah `ExecutionDurationInMinutes` nilainya.
+ baik `RequestedStartTime` maupun`RequestedEndTime`, kami mempertahankan nilai-nilai itu sebagai nol dan RFC diperlakukan sebagai ASAP RFC.
**catatan**
Untuk semua yang dijadwalkan RFCs, waktu akhir yang tidak ditentukan ditulis sebagai waktu yang ditentukan `RequestedStartTime` ditambah `ExpectedExecutionDurationInMinutes` atribut dari jenis perubahan yang dikirimkan. Misalnya, jika “60" (menit), dan yang ditentukan `RequestedStartTime` adalah `2016-12-05T14:20:00Z` (5 Desember 2016 pukul 4:20 pagi), waktu akhir yang sebenarnya akan ditetapkan ke 5 Desember 2016 pukul 5:20 pagi. `ExpectedExecutionDurationInMinutes` Untuk menemukan tipe perubahan tertentu, jalankan perintah ini: `ExpectedExecutionDurationInMinutes`
```
aws amscm --profile saml get-change-type-version --change-type-id CHANGE_TYPE_ID --query "ChangeTypeVersion.{ExpectedDuration:ExpectedExecutionDurationInMinutes}"
```
## Gunakan opsi Prioritas RFC
Gunakan opsi **Prioritas** dalam jenis `execution mode = manual` perubahan untuk mengingatkan Operasi AMS tentang urgensi permintaan.
Opsi **prioritas** di`execution mode = manual`:
Tentukan prioritas RFC manual sebagai **Tinggi**, **Sedang**, atau **Rendah**. RFCs diklasifikasikan sebagai **Tinggi** ditinjau dan disetujui sebelum RFCs diklasifikasikan sebagai **Medium**, tunduk pada tujuan tingkat layanan RFC (SLOs) dan waktu pengajuannya. RFCs dengan Prioritas **rendah** atau tidak ada prioritas yang ditentukan diproses sesuai urutan yang dikirimkan.
# Menyetujui atau menolak RFCs
RFCs diserahkan dengan persetujuan yang diperlukan (manual) CTs harus disetujui oleh Anda atau AMS. Pra-persetujuan CTs diproses secara otomatis. Untuk informasi selengkapnya, lihat [Persyaratan persetujuan CT](constrained-unconstrained-ctis.md).
**catatan**
Saat menggunakan manual CTs, AMS menyarankan Anda menggunakan opsi **Penjadwalan** ASAP (pilih **ASAP** di konsol, biarkan waktu mulai dan berakhir kosong di API/CLI) karena ini CTs memerlukan operator AMS untuk memeriksa RFC, dan mungkin berkomunikasi dengan Anda sebelum dapat disetujui dan dijalankan. Jika Anda menjadwalkan ini RFCs, pastikan untuk mengizinkan setidaknya 24 jam. Jika persetujuan tidak terjadi sebelum waktu mulai yang dijadwalkan, RFC ditolak secara otomatis.
Jika RFC yang diperlukan persetujuan berhasil dikirimkan oleh AMS, maka RFC tersebut harus disetujui secara eksplisit oleh Anda. Atau, jika Anda mengirimkan RFC yang diperlukan persetujuan, maka itu harus disetujui oleh AMS. Jika Anda diminta untuk menyetujui RFC yang dikirimkan AMS, maka email atau komunikasi lain yang telah ditentukan dikirimkan kepada Anda untuk meminta persetujuan. Komunikasi termasuk ID RFC. Setelah komunikasi dikirim, lakukan salah satu hal berikut:
+ Menyetujui atau Menolak Konsol: Gunakan halaman detail RFC untuk RFC yang relevan:
![\[Halaman detail RFC.\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/images/AMS_Console-App-Rej.png)
+ API/CLI Approve: [ApproveRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ApproveRfc.html)menandai perubahan sebagai disetujui. Tindakan harus diambil oleh pemilik dan operator, jika keduanya diperlukan. Berikut ini adalah contoh CLI menyetujui perintah. Dalam contoh berikut, ganti RFC\$1ID dengan ID RFC yang sesuai.
```
aws amscm approve-rfc --rfc-id RFC_ID
```
+ API/CLI Reject: [RejectRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_RejectRfc.html)menandai perubahan sebagai ditolak. Berikut ini adalah contoh perintah CLI reject. Dalam contoh berikut, ganti RFC\$1ID dengan ID RFC yang sesuai.
```
aws amscm reject-rfc --rfc-id RFC_ID --reason "no longer relevant"
```
# Minta periode berjalan terbatas RFC
Sebelumnya dikenal sebagai hari pemadaman, Anda dapat meminta untuk membatasi periode waktu tertentu. Tidak ada perubahan yang dapat dijalankan selama waktu-waktu tersebut.
Untuk menetapkan periode berjalan terbatas, gunakan operasi [UpdateRestrictedExecutionTimes](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_UpdateRestrictedExecutionTimes.html)API dan tetapkan periode waktu tertentu, di UTC. Periode yang Anda tentukan mengesampingkan periode sebelumnya yang ditentukan. Jika Anda mengirimkan RFC selama waktu berjalan terbatas yang ditentukan, pengiriman gagal dengan kesalahan Jadwal RFC Tidak Valid. Anda dapat menentukan hingga 200 periode waktu terbatas. Secara default, tidak ada periode terbatas yang ditetapkan. Berikut ini adalah contoh perintah permintaan (dengan otentikasi SAM dikonfigurasi):
```
aws amscm --profile saml update-restricted-execution-times --restricted-execution-times="[{\"TimeRange\":{\"StartTime\":\"2018-01-01T12:00:00Z\",\"EndTime\":\"2018-01-01T12:00:01Z\"}}]"
```
Anda juga dapat melihat RestrictedExecutionTimes setelan Anda saat ini dengan menjalankan operasi [ListRestrictedExecutionTimes](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ListRestrictedExecutionTimes.html)API. Contoh:
```
aws amscm --profile saml list-restricted-execution-times
```
Jika Anda ingin mengirimkan RFC selama waktu eksekusi terbatas yang ditentukan, tambahkan **RestrictedExecutionTimesOverrideId**dengan nilai **OverrideRestrictedTimeRanges**, dan kemudian kirimkan RFC seperti biasa. Ini adalah praktik terbaik untuk hanya menggunakan metode ini untuk RFC kritis atau darurat. Untuk informasi selengkapnya, lihat referensi API untuk [SubmitRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_SubmitRfc.html).
# Buat, kloning, perbarui, temukan, dan batalkan RFCs
Contoh berikut memandu Anda melalui berbagai operasi RFC.
**Topics**
+ [Buat RFC](ex-rfc-create-col.md)
+ [Kloning RFCs (buat ulang) dengan konsol AMS](ex-clone-rfcs.md)
+ [Perbarui RFCs](ex-update-rfcs.md)
+ [Temukan RFCs](ex-rfc-find-col.md)
+ [Batalkan RFCs](ex-cancel-rfcs.md)
# Buat RFC
## Membuat RFC dengan konsol
Berikut ini adalah halaman pertama proses RFC Create di konsol AMS, dengan **kartu Quick** terbuka dan **Browse change types** aktif:
![\[Quick create section with options for common AWS stack operations and access management.\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/images/quickCreate1.png)
Berikut ini adalah halaman pertama proses RFC Create di konsol AMS, dengan **Pilih berdasarkan kategori aktif:**
![\[Create RFC page with change type categorization options for managed services environment.\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/images/guiRfcCreate1-2.png)
Cara kerjanya:
1. Arahkan ke halaman **Buat RFC**: Di panel navigasi kiri konsol AMS klik **RFCs**untuk membuka halaman RFCs daftar, lalu klik **Buat** RFC.
1. Pilih jenis perubahan populer (CT) di tampilan default **Jelajahi jenis perubahan**, atau pilih CT dalam tampilan **Pilih menurut kategori**.
+ **Jelajahi berdasarkan jenis perubahan**: Anda dapat mengklik CT populer di area **Buat cepat** untuk segera membuka halaman **Jalankan RFC**. Perhatikan bahwa Anda tidak dapat memilih versi CT yang lebih lama dengan pembuatan cepat.
Untuk mengurutkan CTs, gunakan area **Semua jenis perubahan** dalam tampilan **Kartu** atau **Tabel**. Di kedua tampilan, pilih CT dan kemudian klik **Buat RFC** untuk membuka halaman **Jalankan RFC**. Jika berlaku, opsi **Buat dengan versi yang lebih lama** muncul di sebelah tombol **Buat RFC**.
+ **Pilih berdasarkan kategori**: Pilih kategori, subkategori, item, dan operasi dan kotak detail CT terbuka dengan opsi untuk **Membuat dengan versi yang lebih lama** jika berlaku. Klik **Buat RFC** untuk membuka halaman **Jalankan RFC**.
1. Pada halaman **Run RFC**, buka area nama CT untuk melihat kotak detail CT. **Subjek** diperlukan (ini diisi untuk Anda jika Anda memilih CT Anda di tampilan **jenis perubahan Jelajahi**). Buka area **konfigurasi tambahan** untuk menambahkan informasi tentang RFC.
Di area **konfigurasi Eksekusi**, gunakan daftar drop-down yang tersedia atau masukkan nilai untuk parameter yang diperlukan. Untuk mengkonfigurasi parameter eksekusi opsional, buka area **konfigurasi tambahan**.
1. Setelah selesai, klik **Jalankan**. Jika tidak ada kesalahan, **RFC berhasil membuat** halaman ditampilkan dengan rincian RFC yang dikirimkan, dan output **Run** awal.
1. Buka area **parameter Jalankan** untuk melihat konfigurasi yang Anda kirimkan. Segarkan halaman untuk memperbarui status eksekusi RFC. Secara opsional, batalkan RFC atau buat salinannya dengan opsi di bagian atas halaman.
## Membuat RFC dengan CLI
Cara kerjanya:
1. Gunakan Inline Create (Anda mengeluarkan `create-rfc` perintah dengan semua RFC dan parameter eksekusi disertakan), atau Template Create (Anda membuat dua file JSON, satu untuk parameter RFC dan satu untuk parameter eksekusi) dan mengeluarkan `create-rfc` perintah dengan dua file sebagai input. Kedua metode tersebut dijelaskan di sini.
1. Kirim `aws amscm submit-rfc --rfc-id ID` perintah RFC: dengan ID RFC yang dikembalikan.
Pantau `aws amscm get-rfc --rfc-id ID` perintah RFC:.
Untuk memeriksa versi jenis perubahan, gunakan perintah ini:
```
aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=CT_ID
```
**catatan**
Anda dapat menggunakan `CreateRfc` parameter apa pun dengan RFC apa pun apakah itu bagian dari skema untuk jenis perubahan atau tidak. Misalnya, untuk mendapatkan pemberitahuan ketika status RFC berubah, tambahkan baris ini, `--notification "{\"Email\": {\"EmailRecipients\" : [\"email@example.com\"]}}"` ke bagian parameter RFC dari permintaan (bukan parameter eksekusi). Untuk daftar semua CreateRfc parameter, lihat [Referensi AMS Change Management API](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_CreateRfc.html).
*BUAT SEBARIS*:
Keluarkan perintah create RFC dengan parameter eksekusi yang disediakan sebaris (tanda kutip saat memberikan parameter eksekusi sebaris), lalu kirimkan ID RFC yang dikembalikan. Misalnya, Anda dapat mengganti konten dengan sesuatu seperti ini::
```
aws amscm create-rfc --change-type-id "CT_ID" --change-type-version "VERSION" --title "TITLE" --execution-parameters "{\"Description\": \"example\"}"
```
*TEMPLATE MEMBUAT*:
**catatan**
Contoh pembuatan RFC ini menggunakan tipe perubahan tumpukan Load Balancer (ELB).
1. Temukan CT yang relevan. Perintah berikut mencari ringkasan klasifikasi CT untuk yang berisi “ELB” di Nama **Item** dan membuat output dari Kategori, Item, Operasi, dan ChangeType ID dalam bentuk tabel (Subkategori untuk keduanya). `Advanced stack components`
```
aws amscm list-change-type-classification-summaries --query "ChangeTypeClassificationSummaries[?contains(Item,'ELB')].[Category,Item,Operation,ChangeTypeId]" --output table
```
```
---------------------------------------------------------------------
| CtSummaries |
+-----------+---------------------------+---------------------------+
| Deployment| Load balancer (ELB) stack | Create | ct-123h45t6uz7jl |
| Management| Load balancer (ELB) stack | Update | ct-0ltm873rsebx9 |
+-----------+---------------------------+---------------------------+
```
1. Temukan versi terbaru dari CT:
`ChangeTypeId`dan`ChangeTypeVersion`: ID tipe perubahan untuk panduan ini adalah `ct-123h45t6uz7jl` (buat ELB), untuk mengetahui versi terbaru, jalankan perintah ini:
```
aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=ct-123h45t6uz7jl
```
1. Pelajari opsi dan persyaratannya. Perintah berikut output skema ke file JSON bernama .json. CreateElbParams
```
aws amscm get-change-type-version --change-type-id "ct-123h45t6uz7jl" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateElbParams.json
```
1. Memodifikasi dan menyimpan parameter eksekusi file JSON. Contoh ini menamai file CreateElbParams .json.
Untuk CT penyediaan, termasuk dalam skema dan harus diserahkan dalam parameter eksekusi. StackTemplateId
Untuk TimeoutInMinutes, berapa menit yang diizinkan untuk pembuatan tumpukan sebelum RFC gagal, pengaturan ini tidak akan menunda eksekusi RFC, tetapi Anda harus memberikan waktu yang cukup (misalnya, jangan tentukan “5"). Nilai yang valid adalah “60" hingga “360,” untuk CT dengan jangka panjang UserData: Buat EC2 dan Buat ASG. Kami merekomendasikan maksimum yang diizinkan “60" untuk semua penyediaan CTs lainnya.
Berikan ID VPC tempat Anda ingin tumpukan dibuat; Anda bisa mendapatkan ID VPC dengan perintah CLI. `aws amsskms list-vpc-summaries`
```
{
"Description": "ELB-Create-RFC",
"VpcId": "VPC_ID",
"StackTemplateId": "stm-sdhopv00000000000",
"Name": "MyElbInstance",
"TimeoutInMinutes": 60,
"Parameters": {
"ELBSubnetIds": ["SUBNET_ID"],
"ELBHealthCheckHealthyThreshold": 4,
"ELBHealthCheckInterval": 5,
"ELBHealthCheckTarget": "HTTP:80/",
"ELBHealthCheckTimeout": 60,
"ELBHealthCheckUnhealthyThreshold": 5,
"ELBScheme": false
}
}
```
1. Keluarkan template RFC JSON ke file di folder Anda saat ini bernama CreateElbRfc .json:
```
aws amscm create-rfc --generate-cli-skeleton > CreateElbRfc.json
```
1. Ubah dan simpan CreateElbRfc file.json. Karena Anda membuat parameter eksekusi dalam file terpisah, hapus `ExecutionParameters` baris. Misalnya, Anda dapat mengganti konten dengan sesuatu seperti ini:
```
{
"ChangeTypeVersion": "2.0",
"ChangeTypeId": "ct-123h45t6uz7jl",
"Title": "Create ELB"
}
```
1. Buat RFC. Perintah berikut menentukan file parameter eksekusi dan file template RFC:
```
aws amscm create-rfc --cli-input-json file://CreateElbRfc.json --execution-parameters file://CreateElbParams.json
```
Anda menerima ID RFC baru dalam respons dan dapat menggunakannya untuk mengirimkan dan memantau RFC. Sampai Anda mengirimkannya, RFC tetap dalam kondisi pengeditan dan tidak dimulai.
## Kiat
**catatan**
Anda dapat menggunakan AMS API/CLI untuk membuat RFC tanpa membuat file JSON RFC atau file JSON parameter eksekusi CT. Untuk melakukan ini, Anda menggunakan `create-rfc` perintah dan menambahkan parameter RFC dan eksekusi yang diperlukan ke perintah, ini disebut “Buat Sebaris”. Perhatikan bahwa semua penyediaan CTs telah terkandung dalam `execution-parameters` blok `Parameters` array dengan parameter untuk sumber daya. Parameter harus memiliki tanda kutip yang lolos dengan garis miring belakang (\$1).
Metode terdokumentasi lainnya untuk membuat RFC disebut “Template Create.” Di sinilah Anda membuat file JSON untuk parameter RFC dan file JSON lain untuk parameter eksekusi, dan mengirimkan dua file dengan perintah. `create-rfc` File-file ini dapat berfungsi sebagai template dan digunakan kembali untuk masa depan RFCs.
Saat membuat RFCs dengan template, Anda dapat menggunakan perintah untuk membuat file JSON dengan konten yang Anda inginkan dengan mengeluarkan perintah seperti yang ditunjukkan. Perintah membuat file bernama “parameters.json” dengan konten yang ditampilkan; Anda juga bisa menggunakan perintah ini untuk membuat file RFC JSON.
# Kloning RFCs (buat ulang) dengan konsol AMS
Anda dapat menggunakan konsol AMS untuk mengkloning RFC yang ada.
Untuk mengkloning, atau membuat ulang, RFC menggunakan konsol AMS, ikuti langkah-langkah berikut:
1. Temukan RFC yang relevan. Dari navigasi kiri, klik **RFCs**.
RFCs Dasbor terbuka.
1. Gulir halaman sampai Anda menemukan RFC yang ingin Anda kloning. Gunakan opsi **Filter** untuk mempersempit daftar. Pilih RFC yang ingin Anda kloning.
Halaman detail RFC terbuka.
1. Klik **Buat Salinan**.
Halaman **Buat permintaan untuk perubahan** terbuka dengan semua opsi yang ditetapkan seperti pada RFC asli.
1. Buat perubahan yang Anda inginkan. Untuk mengatur opsi tambahan, ubah opsi **Basic** ke **Advanced**. Setelah Anda mengatur semua opsi, pilih **Kirim**.
Halaman detail RFC aktif terbuka dengan ID RFC baru untuk RFC kloning dan RFC kloning muncul di dasbor RFC.
# Perbarui RFCs
Anda dapat mengirimkan ulang RFC yang telah ditolak atau yang belum dikirimkan, dengan memperbarui RFC dan kemudian mengirimkannya, atau mengirimkannya kembali. Perhatikan bahwa sebagian besar ditolak karena RFCs yang ditentukan `RequestedStartTime` telah berlalu sebelum pengiriman atau yang TimeoutInMinutes ditentukan tidak memadai untuk menjalankan RFC (karena TimeoutInMinutes tidak memperpanjang RFC yang berhasil, kami sarankan untuk selalu menyetel ini ke setidaknya “60" dan hingga “360" untuk Amazon atau grup Auto Scaling EC2 Amazon dengan jangka panjang). EC2 UserData Bagian ini menjelaskan cara menggunakan versi CLI dari `UpdateRfc` perintah untuk memperbarui RFC dengan parameter RFC baru, atau parameter baru menggunakan JSON stringified atau file parameter yang diperbarui.
Contoh ini menjelaskan penggunaan AMS UpdateRfc API versi CLI (lihat [Perbarui RFC](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/update-rfc.html)). Meskipun ada jenis perubahan untuk memperbarui beberapa sumber daya (DNS pribadi dan publik, tumpukan penyeimbang beban, dan konfigurasi tambalan tumpukan), tidak ada CT untuk memperbarui RFC.
Kami menyarankan Anda mengirimkan satu UpdateRfc operasi pada satu waktu. Jika Anda mengirimkan beberapa pembaruan, misalnya pada tumpukan DNS, pembaruan mungkin gagal mencoba memperbarui DNS secara bersamaan.
DATA YANG DIPERLUKAN:`RfcId`: RFC yang Anda perbarui.
DATA OPSIONAL`ExecutionParameters`:: Kecuali Anda memperbarui bidang yang tidak wajib`Description`, seperti, Anda akan mengirimkan parameter eksekusi yang dimodifikasi untuk mengatasi masalah yang menyebabkan RFC ditolak atau dibatalkan. Semua nilai non-null yang dikirimkan menimpa nilai-nilai tersebut di RFC asli.
1. Temukan RFC yang ditolak atau dibatalkan yang relevan, Anda dapat menggunakan perintah ini (Anda dapat mengganti nilainya dengan`Canceled`):
```
aws amscm list-rfc-summaries --filter Attribute=RfcStatusId,Value=Rejected
```
1. Anda dapat memodifikasi salah satu parameter RFC berikut:
```
{
"Description": "string",
"ExecutionParameters": "string",
"ExpectedOutcome": "string",
"ImplementationPlan": "string",
"RequestedEndTime": "string",
"RequestedStartTime": "string",
"RfcId": "string",
"RollbackPlan": "string",
"Title": "string",
"WorstCaseScenario": "string"}
```
Contoh perintah memperbarui bidang Deskripsi:
```
aws amscm update-rfc --description "AMSTestNoOpsActionRequired" --rfc-id "RFC_ID" --region us-east-1
```
Contoh perintah memperbarui ExecutionParameters VpcId bidang:
```
aws amscm update-rfc --execution-parameters "{\"VpcId\":\"VPC_ID\"}" --rfc-id "RFC_ID" --region us-east-1
```
Contoh perintah memperbarui RFC dengan file parameter eksekusi yang berisi pembaruan; lihat contoh file parameter eksekusi di langkah 2 dari: [EC2 stack \$1 Buat](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-ec2-stack-create.html):
```
aws amscm update-rfc --execution-parameters file://CreateEc2ParamsUpdate.json --rfc-id "RFC_ID" --region us-east-1
```
1. Kirim ulang RFC menggunakan `submit-rfc` dan ID RFC yang sama dengan yang Anda miliki saat RFC pertama kali dibuat:
```
aws amscm submit-rfc --rfc-id RFC_ID
```
Jika RFC berhasil, Anda tidak menerima konfirmasi atau pesan kesalahan di baris perintah.
1. Untuk memantau status permintaan dan untuk melihat Output Eksekusi, jalankan perintah berikut.
```
aws amscm get-rfc --rfc-id RFC_ID
```
# Temukan RFCs
## Temukan permintaan perubahan (RFC) dengan konsol
Untuk menemukan RFC menggunakan konsol AMS, ikuti langkah-langkah berikut.
**catatan**
Prosedur ini hanya berlaku untuk yang dijadwalkan RFCs, RFCs yaitu, yang tidak menggunakan opsi **ASAP**.
1. Dari navigasi kiri, klik **RFCs**.
RFCs Dasbor terbuka.
1. Gulir daftar atau gunakan opsi **Filter** untuk memperbaiki daftar.
Daftar RFC berubah per kriteria filter.
1. Pilih tautan Subjek untuk RFC yang Anda inginkan.
Halaman detail RFC terbuka untuk RFC itu dengan informasi termasuk ID RFC.
1. Jika ada banyak RFCs di dasbor, Anda dapat menggunakan opsi **Filter** untuk mencari berdasarkan RFC:
+ **Subjek**: Baris subjek, atau judul (dalam API/CLI) diberikan kepada RFC saat dibuat.
+ **ID RFC**: Pengidentifikasi untuk RFC.
+ **Status aktivitas**: Jika Anda mengetahui status RFC, Anda dapat memilih antara **AwsOperatorAssigned**arti operator sedang melihat RFC, yang **AwsActionPending**berarti bahwa operator AMS harus melakukan sesuatu sebelum eksekusi RFC dapat dilanjutkan atau **CustomerActionPending**artinya Anda perlu mengambil beberapa tindakan sebelum eksekusi RFC dapat dilanjutkan.
+ **Status**: Jika Anda mengetahui status RFC, Anda dapat memilih antara:
+ **Dijadwalkan**: RFCs yang dijadwalkan.
+ **Dibatalkan**: RFCs yang dibatalkan.
+ **Sedang berlangsung**: RFCs sedang berlangsung.
+ **Sukses**: RFCs yang dieksekusi dengan sukses.
+ **Ditolak**: RFCs yang ditolak.
+ **Pengeditan**: RFCs yang sedang diedit.
+ **Kegagalan**: RFCs itu gagal.
+ **Persetujuan yang tertunda**: RFCs yang tidak dapat dilanjutkan sampai AMS atau Anda menyetujui. Biasanya, ini menunjukkan bahwa Anda perlu menyetujui RFC. Anda akan mendapatkan pemberitahuan layanan ini di daftar Permintaan Layanan Anda.
+ **Ubah jenis**: Pilih **Kategori**, **Subkategori**, **Item**, dan **Operasi**, dan ID jenis perubahan diambil untuk Anda.
+ **Waktu mulai** yang **diminta atau Waktu akhir** yang diminta: Opsi filter ini memungkinkan Anda memilih **Sebelum** atau **Setelah**, lalu masukkan **Tanggal** dan, secara opsional, **Waktu** (hh: mm dan zona waktu). Filter ini beroperasi dengan sukses hanya pada jadwal RFCs (tidak ASAP RFCs).
+ **Status**: Baik **Dijadwalkan**, **Dibatalkan**, Sedang **berlangsung**, **Sukses**, **Ditolak**, **Mengedit**, atau **Kegagalan**.
+ **Subjek**: Subjek (atau judul, jika RFC dibuat dengan API/CLI) yang Anda berikan RFC.
+ **Ubah tipe ID**: Gunakan pengenal untuk jenis perubahan yang dikirimkan dengan RFC.
Pencarian memungkinkan Anda untuk menambahkan filter, seperti yang ditunjukkan pada gambar berikut.
![\[Search or filter options including Subject, RFC ID, Activity state, and various time-related fields.\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/images/filterRfcAllOptions3.png)
1. Klik tautan Subjek untuk RFC yang Anda inginkan.
Halaman detail RFC terbuka untuk RFC itu dengan informasi termasuk ID RFC.
## Menemukan permintaan perubahan (RFC) dengan CLI
Anda dapat menggunakan beberapa filter untuk menemukan RFC.
Untuk memeriksa versi jenis perubahan, gunakan perintah ini:
```
aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=CT_ID
```
**catatan**
Anda dapat menggunakan `CreateRfc` parameter apa pun dengan RFC apa pun apakah itu bagian dari skema untuk jenis perubahan atau tidak. Misalnya, untuk mendapatkan pemberitahuan ketika status RFC berubah, tambahkan baris ini, `--notification "{\"Email\": {\"EmailRecipients\" : [\"email@example.com\"]}}"` ke bagian parameter RFC dari permintaan (bukan parameter eksekusi). Untuk daftar semua CreateRfc parameter, lihat [Referensi API Manajemen Perubahan AMS](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_CreateRfc.html).
Jika Anda tidak menuliskan ID RFC, dan perlu menemukannya nanti, Anda dapat menggunakan sistem manajemen perubahan AMS (CM) untuk mencarinya dan mempersempit hasilnya dengan filter atau kueri.
1. [ListRfcSummaries](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ListRfcSummaries.html)Operasi CM API memiliki filter. Anda dapat [Memfilter](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_Filter.html) hasil berdasarkan `Attribute` dan `Value` digabungkan dalam operasi AND logis, atau berdasarkan`Attribute`, a`Condition`, dan`Values`.
**Penyaringan RFC**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/ex-rfc-find-col.html)
Contoh:
Untuk menemukan semua IDs yang RFCs terkait dengan SQS (di mana SQS terkandung dalam bagian Item CT), Anda dapat menggunakan perintah ini:
```
list-rfc-summaries --query 'RfcSummaries[?contains(Item.Name,`SQS`)].[Category.Id,Subcategory.Id,Type.Id,Item.Id,RfcId]' --output table
```
Yang mengembalikan sesuatu seperti ini:
```
----------------------------------------------------------------------------
| ListRfcSummaries |
+----------+--------------------------------+-------+-------+----------------+
|Deployment| Advanced Stack Components |SQS |Create |ct-123h45t6uz7jl|
|Management| Monitoring & Notification |SQS |Update |ct-123h45t6uz7jl|
+----------+--------------------------------+-------+-------+----------------+
```
Filter lain yang tersedia `list-rfc-summaries` adalah`AutomationStatusId`, untuk mencari RFCs yang otomatis atau manual:
```
aws amscm list-rfc-summaries --filter Attribute=AutomationStatusId,Value=Automated
```
Filter lain yang tersedia `list-rfc-summaries` adalah `Title` (**Subjek** di konsol):
```
Attribute=Title,Value=RFC-TITLE
```
Contoh struktur permintaan baru di JSON yang mengembalikan RFCs where:
+ (Judul BERISI frasa “Windows 2012" ATAU “Amazon Linux”) DAN
+ (RfcStatusId SAMA DENGAN “Sukses” ATAU "InProgress“) DAN
+ (20170101T000000Z <= <= 20170103T000000Z) DAN (<= 20170103T000000Z) RequestedStartTime ActualEndTime
```
{
"Filters": [
{
"Attribute": "Title",
"Values": ["Windows 2012", "Amazon Linux"],
"Condition": "Contains"
},
{
"Attribute": "RfcStatusId",
"Values": ["Success", "InProgress"],
"Condition": "Equals"
},
{
"Attribute": "RequestedStartTime",
"Values": ["20170101T000000Z", "20170103T000000Z"],
"Condition": "Between"
},
{
"Attribute": "ActualEndTime",
"Values": ["20170103T000000Z"],
"Condition": "Before"
}
]
}
```
**catatan**
Dengan lebih lanjut`Filters`, AMS bermaksud untuk menghentikan bidang berikut dalam rilis mendatang:
Nilai: Bidang Nilai adalah bagian dari bidang Filter. Gunakan bidang Nilai yang mendukung fungsionalitas yang lebih canggih.
RequestedEndTimeRange: Gunakan bagian RequestedEndTime dalam bidang Filter yang mendukung fungsionalitas yang lebih canggih
RequestedStartTimeRange: Gunakan bagian RequestedStartTime dalam bidang Filter yang mendukung fungsionalitas yang lebih canggih.
[Untuk informasi tentang penggunaan kueri CLI, lihat [Cara Memfilter Output dengan Opsi --query](https://docs.aws.amazon.com/cli/latest/userguide/controlling-output.html#controlling-output-filter) dan referensi bahasa kueri, Spesifikasi. JMESPath ](http://jmespath.org/specification.html)
1. Jika Anda menggunakan konsol AMS:
Pergi ke halaman **RFCs**daftar. Jika diperlukan, Anda dapat memfilter pada **Subjek** RFC, yang Anda masukkan sebagai RFC `Title` saat Anda membuatnya.
## Kiat
**catatan**
Prosedur ini hanya berlaku untuk yang dijadwalkan RFCs, RFCs yaitu, yang tidak menggunakan opsi **ASAP**.
# Batalkan RFCs
Anda dapat membatalkan RFC menggunakan Konsol atau AMS API/CLI.
**Untuk membatalkan RFC dengan konsol, temukan RFC di daftar RFC Anda, buka, klik Batal.**
Data yang Diperlukan:
+ `Reason`: Mengapa Anda membatalkan RFC.
+ `RfcId`: RFC yang Anda batalkan.
1. Biasanya Anda akan membatalkan RFC segera setelah mengirimkannya (jadi ID RFC harus berguna); jika tidak, Anda tidak akan dapat membatalkannya kecuali Anda menjadwalkannya dan itu sebelum waktu mulai yang ditentukan. Jika Anda perlu menemukan ID RFC, Anda dapat menggunakan perintah ini (Anda dapat mengganti `Value` dengan `PendingApproval` RFC yang disetujui secara manual):
```
aws amscm list-rfc-summaries --filter Attribute=RfcStatusId,Value=Scheduled
```
1. Contoh perintah untuk membatalkan RFC:
```
aws amscm cancel-rfc --reason "Bad Stack ID" --rfc-id "RFC_ID" --profile saml --region us-east-1
```
# Gunakan konsol AMS dengan RFCs
Konsol AMS menyediakan fitur untuk membantu Anda berhasil membuat dan mengirimkan RFCs.
## Gunakan halaman Daftar RFC (Konsol)
Halaman **RFCs**daftar konsol AMS memberi Anda opsi berikut:
+ Pencarian RFC tingkat lanjut melalui **Filter**. Untuk informasi, lihat [Temukan RFCs](ex-rfc-find-col.md).
+ Menemukan terakhir kali RFC **Dimodifikasi**. Nilai ini menunjukkan bahwa terakhir kali status RFC diubah.
+ **Melihat detail RFC dengan Subjek RFC.** Memilih tautan ini membuka halaman detail untuk RFC itu.
+ Melihat status RFC. Untuk informasi, lihat [Memahami kode status RFC](ex-rfc-status-codes.md)
![\[Halaman daftar RFC.\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/images/guiRfcListTable.png)
## Gunakan RFC quick create (konsol)
Gunakan kartu cepat RFC, atau daftar tabel, atau pilih jenis perubahan RFCs berdasarkan klasifikasi.
Untuk mempelajari selengkapnya, lihat [Buat RFC](ex-rfc-create-col.md).
## Tambahkan korespondensi dan lampiran RFC (konsol)
Anda dapat menambahkan korespondensi ke RFC setelah dikirimkan dan sebelum disetujui; misalnya, saat berada dalam keadaan "”PendingApproval. Setelah RFC disetujui (dalam keadaan “Terjadwal” atau "InProgress“), korespondensi tidak dapat ditambahkan, karena dapat ditafsirkan sebagai perubahan pada permintaan. Setelah RFC selesai (dalam keadaan “Dibatalkan”, “Ditolak”, “Sukses”, atau “Kegagalan”), korespondensi sekali lagi diaktifkan, meskipun korespondensi dinonaktifkan setelah RFC ditutup selama lebih dari 30 hari.
**catatan**
Setiap korespondensi dibatasi hingga 5.000 karakter.
**Batasan untuk lampiran:**
+ Hanya tiga lampiran per korespondensi.
+ Batasi lima puluh lampiran per RFC.
+ Setiap lampiran harus berukuran kurang dari 5 MB.
+ Hanya file teks yang diterima seperti plaintext (`.txt`), nilai yang dipisahkan koma (), JSON (`.csv`), atau YAMB (`.json`). `.yaml` Dalam kasus format YAMAL, file harus dilampirkan menggunakan ekstensi `.yaml` file.
**catatan**
File teks yang memiliki konten XMLdilarang. Jika Anda memiliki konten XMLuntuk dibagikan dengan AMS, gunakan permintaan layanan.
+ Nama file dibatasi hingga 255 karakter, dengan hanya angka, huruf, spasi, tanda hubung (-), garis bawah (\$1), dan titik (.).
+ Memperbarui dan menghapus lampiran pada RFC saat ini tidak didukung.
Untuk menambahkan korespondensi dan lampiran ke RFC, ikuti langkah-langkah berikut:
1. Di konsol AMS, pada halaman detail RFC untuk RFC, temukan bagian **Korespondensi** di bagian bawah halaman.
Sebelum korespondensi apa pun:
![\[Bagian korespondensi kosong.\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/images/correspondence-rfc-detail-new.png)
Setelah beberapa korespondensi:
![\[Bagian korespondensi menunjukkan formulir balasan dan menerima korespondensi.\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/images/correspondence-reply-form2.png)
1. Untuk menambahkan korespondensi baru, ketik pesan Anda di kotak teks **Balas**. Untuk melampirkan file yang terkait dengan korespondensi, pilih **Tambahkan Lampiran**, lalu pilih file yang Anda inginkan.
![\[Bagian korespondensi menampilkan kotak komentar dan lampiran.\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/images/correspondence-add-attachments.png)
1. Setelah selesai, pilih **Kirim**.
Korespondensi baru, bersama dengan tautan ke file terlampir, muncul di daftar korespondensi di halaman detail RFC.
![\[Daftar korespondensi yang diterima.\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/images/correspondence-list2.png)
# Konfigurasikan pemberitahuan email RFC (konsol)
Halaman pembuatan **Permintaan Perubahan** konsol AMS memberi Anda opsi untuk menambahkan alamat email guna menerima pemberitahuan perubahan status RFC:
![\[Tambahkan alamat email untuk menerima pemberitahuan perubahan status RFC.\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/images/emailNoticeOption2.png)
Selain itu, Anda dapat menambahkan alamat email untuk pemberitahuan ke jenis perubahan apa pun, misalnya:
```
aws amscm create-rfc --change-type-id
--change-type-version 1.0 --title "TITLE"
--notification "{\"Email\": {\"EmailRecipients\" : [\"email@example.com\"]}}"
```
Tambahkan baris serupa (`--notification "{\"Email\": {\"EmailRecipients\" : [\"email@example.com\"]}}"`) ke setiap jenis perubahan inline atau permintaan template di bagian parameter RFC dari permintaan, bukan bagian parameter.
# Pelajari tentang parameter RFC umum
Berikut ini adalah parameter RFC yang harus Anda kirimkan, dan parameter yang biasa digunakan di RFCs:
+ Ubah informasi jenis: ChangeTypeId dan ChangeTypeVersion. Dengan daftar jenis perubahan IDs dan nomor versi, lihat [Mengubah Referensi Jenis](https://docs.aws.amazon.com/managedservices/latest/ctref/index.html).
Jalankan `list-change-type-classification-summaries` di CLI dengan `query` argumen untuk mempersempit hasil. Misalnya, mempersempit hasil untuk mengubah jenis yang berisi “Akses” dalam `Item` nama.
```
aws amscm list-change-type-classification-summaries --query "ChangeTypeClassificationSummaries [?contains (Item, 'access')].[Category,Subcategory,Item,Operation,ChangeTypeId]" --output table
```
Jalankan `get-change-type-version` dan tentukan ID tipe perubahan. Perintah berikut mendapatkan versi CT untuk ct-2tylseo8rxfsc.
```
aws amscm get-change-type-version --change-type-id ct-2tylseo8rxfsc
```
+ Judul: Nama untuk RFC; ini menjadi **Subjek** RFC di daftar RFC konsol AMS dan Anda dapat mencarinya dengan `GetRfc` perintah dan filter `Title`
+ Penjadwalan: Jika Anda menginginkan RFC terjadwal, Anda harus menyertakan `RequestedEndTime` parameter `RequestedStartTime` dan, atau gunakan opsi **Jadwalkan konsol perubahan ini**. Untuk **ASAP** RFC (yang berjalan segera setelah disetujui), saat menggunakan CLI, `RequestedStartTime` tinggalkan `RequestedEndTime` dan null. Saat menggunakan konsol, terima opsi **ASAP**.
Jika `RequestedStartTime` terlewatkan, RFC ditolak.
+ Penyediaan CTs: Parameter eksekusi, atau pengaturan khusus `Parameters` yang diperlukan untuk menyediakan sumber daya. Mereka sangat bervariasi tergantung pada CT.
+ Non-penyediaan CTs: CTs yang tidak menyediakan sumber daya, seperti akses CTs atau Lainnya \$1 Lainnya, atau menghapus tumpukan, memiliki parameter eksekusi minimal dan tidak ada blok. `Parameters`
+ Beberapa RFCs juga mengharuskan Anda menentukan`TimeoutInMinutes`, atau berapa menit yang diizinkan untuk pembuatan tumpukan sebelum RFC gagal. Nilai yang valid adalah 60 (menit) hingga 360, untuk jangka panjang UserData. Jika eksekusi tidak dapat diselesaikan sebelum `TimeoutInMinutes` terlampaui, RFC gagal. Namun, pengaturan ini tidak menunda eksekusi RFC.
+ RFCs yang membuat instance, seperti bucket S3 atau ELB, umumnya menyediakan skema yang memungkinkan Anda menambahkan hingga tujuh tag (pasangan kunci/nilai). Anda dapat menambahkan lebih banyak tag ke bucket S3 Anda dengan mengirimkan RFC menggunakan Deployment \$1 Advanced stack components \$1 Tag \$1 Create change type (ct-3cx7we852p3af). EC2, EFS, RDS, dan skema multi-tier (HA Two-Tiered dan HA One-Tiered) memungkinkan hingga lima puluh tag. Tag ditentukan di `ExecutionParameters` bagian skema. Memberikan tag bisa sangat berharga. Untuk informasi selengkapnya, lihat [Menandai EC2 Sumber Daya Amazon Anda](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html).
Saat menggunakan konsol AMS, Anda harus membuka area **konfigurasi tambahan** untuk menambahkan tag.
**Tip**
Banyak skema CT memiliki `Name` bidang `Description` dan di dekat bagian atas skema. Bidang tersebut digunakan untuk memberi nama komponen tumpukan atau tumpukan, mereka tidak memberi nama sumber daya yang Anda buat. Beberapa skema menawarkan parameter untuk memberi nama sumber daya yang Anda buat, dan beberapa tidak. Misalnya, skema CT untuk EC2 tumpukan Create tidak menawarkan parameter untuk menamai EC2 instance. Untuk melakukannya, Anda harus membuat tag dengan kunci “Nama” dan nilai dari nama yang Anda inginkan. Jika Anda tidak membuat tag seperti itu, EC2 instance Anda akan ditampilkan di EC2 konsol tanpa atribut name.
## Gunakan opsi AWS Wilayah RFC
Titik akhir AMS API dan CLI (`amscm`dan`amsskms`) ada di. `us-east-1` Jika Anda berfederasi dengan Security Assertion Markup Language (SAMP), maka skrip diberikan kepada Anda saat orientasi yang mengatur Wilayah Anda ke us-east-1. AWS Jika Anda menggunakan SAMP, maka Anda tidak perlu menentukan `--region` opsi saat Anda mengeluarkan perintah. Jika SAMP Anda dikonfigurasi untuk menggunakan us-east-1 tetapi akun Anda tidak berada di Wilayah itu, maka Anda harus menentukan Wilayah AWS yang dionboard akun saat Anda mengeluarkan perintah lain (misalnya,). AWS `aws s3`
**catatan**
Sebagian besar contoh perintah yang disediakan dalam panduan ini tidak menyertakan `--region` opsi.
# Mendaftar untuk email harian RFC
Anda dapat mendaftar untuk email harian yang merangkum aktivitas RFC di akun Anda selama 24 jam terakhir menggunakan fitur RFC digest. Fitur RFC digest adalah proses efisien yang mengurangi jumlah notifikasi email yang Anda terima terkait akun Anda. RFCs Intisari RFC dapat mengurangi kemungkinan Anda melewatkan tindakan yang menunggu respons Anda.
Untuk mengaktifkan fitur RFC digest, hubungi AMS Cloud Service Delivery Manager (CSDM). CSDM berlangganan Anda. Anda dapat meminta hingga 20 alamat email (atau alias) untuk disertakan dalam daftar email intisari RFC Anda. Jadwal email saat ini ditetapkan pada pukul 09:00 UTC-8.
Untuk mematikan fitur RFC digest, hubungi CSDM Anda dengan permintaan Anda.
Jika Anda tidak mengatur intisari RFC dan menginginkan pemberitahuan mengenai Anda RFCs, atau jika Anda ingin informasi lebih rinci tentang Anda RFCs daripada apa yang disediakan oleh intisari RFC, gunakan Sistem Manajemen Perubahan untuk mengatur pemberitahuan CloudWatch Acara atau pemberitahuan email untuk setiap RFC individu yang Anda inginkan informasi. Untuk informasi tentang cara menyiapkan notifikasi RFC, lihat Pemberitahuan [Perubahan Status RFC](https://docs.aws.amazon.com/managedservices/latest/userguide/rfc-state-change-notices.html).
Topik yang terkandung dalam intisari RFC meliputi:
+ Persetujuan Pelanggan Tertunda: Daftar RFCs yang **PendingApproval**berstatus, menunggu persetujuan Anda
+ Balasan Pelanggan Tertunda: Daftar RFCs yang menunggu balasan Anda pada korespondensi RFC
+ Persetujuan atau Balasan AWS RFCs yang Tertunda: Daftar yang menunggu di AMS untuk balasan atau persetujuan
+ Selesai: Daftar RFCs dalam status **Sukses**, **Kegagalan****, Dibatalkan** dan **Ditolak**
Berikut ini adalah contoh RFC digest:
![\[Contoh RFC digest\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/images/RFCDigestExample.png)
# Apa itu jenis perubahan?
Jenis perubahan mengacu pada tindakan yang dilakukan oleh permintaan perubahan (RFC) AWS Managed Services (AMS) dan mencakup tindakan perubahan itu sendiri, dan jenis perubahan — manual vs otomatis. AMS memiliki banyak koleksi jenis perubahan yang tidak digunakan oleh layanan web Amazon lainnya. Anda menggunakan jenis perubahan ini saat mengirimkan permintaan untuk perubahan (RFC) untuk menyebarkan, atau mengelola, atau mendapatkan akses ke, sumber daya.
**Topics**
+ [Otomatis dan manual CTs](ug-automated-or-manual.md)
+ [Persyaratan persetujuan CT](constrained-unconstrained-ctis.md)
+ [Ubah versi tipe](ct-versions.md)
+ [Buat jenis perubahan](ct-creates.md)
+ [Perbarui jenis perubahan](ct-updates.md)
+ [Jenis perubahan hanya internal](ct-internals.md)
+ [Ubah skema tipe](ct-schemas.md)
+ [Mengelola izin untuk jenis perubahan](ct-permissions.md)
+ [Menyunting informasi sensitif dari jenis perubahan](ct-redaction.md)
+ [Menemukan jenis perubahan, menggunakan opsi kueri](ug-find-ct-ex-section.md)
# Otomatis dan manual CTs
Batasan pada jenis perubahan adalah apakah mereka otomatis atau manual, ini adalah `AutomationStatusId` atribut tipe perubahan, yang disebut **mode Eksekusi di konsol** AMS.
Jenis perubahan otomatis memiliki hasil dan waktu eksekusi yang diharapkan dan dijalankan melalui sistem otomatis AMS, umumnya dalam waktu satu jam atau kurang (ini sangat tergantung pada sumber daya apa yang disediakan CT). Jenis perubahan manual jarang terjadi, tetapi diperlakukan berbeda karena mengharuskan operator AMS bertindak pada RFC sebelum dapat dijalankan. Itu terkadang berarti berkomunikasi dengan pengirim RFC, jadi, jenis perubahan manual memerlukan waktu yang bervariasi untuk menyelesaikannya.
Untuk semua yang dijadwalkan RFCs, waktu akhir yang tidak ditentukan ditulis sebagai waktu yang ditentukan `RequestedStartTime` ditambah `ExpectedExecutionDurationInMinutes` atribut dari jenis perubahan yang dikirimkan. Misalnya, jika “60" (menit), dan yang ditentukan `RequestedStartTime` adalah `2016-12-05T14:20:00Z` (5 Desember 2016 pukul 4:20 pagi), waktu akhir yang sebenarnya akan ditetapkan ke 5 Desember 2016 pukul 5:20 pagi. `ExpectedExecutionDurationInMinutes` Untuk menemukan tipe perubahan tertentu, jalankan perintah ini: `ExpectedExecutionDurationInMinutes`
```
aws amscm --profile saml get-change-type-version --change-type-id CHANGE_TYPE_ID --query "ChangeTypeVersion.{ExpectedDuration:ExpectedExecutionDurationInMinutes}"
```
**catatan**
Dijadwalkan RFCs dengan **mode Eksekusi** = Manual, di Konsol, harus diatur untuk berjalan setidaknya 24 jam di masa mendatang.
**catatan**
Saat menggunakan manual CTs, AMS menyarankan Anda menggunakan opsi **Penjadwalan** ASAP (pilih **ASAP** di konsol, biarkan waktu mulai dan berakhir kosong di API/CLI) karena ini CTs memerlukan operator AMS untuk memeriksa RFC, dan mungkin berkomunikasi dengan Anda sebelum dapat disetujui dan dijalankan. Jika Anda menjadwalkan ini RFCs, pastikan untuk mengizinkan setidaknya 24 jam. Jika persetujuan tidak terjadi sebelum waktu mulai yang dijadwalkan, RFC ditolak secara otomatis.
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 dijalankan.
Untuk daftar yang Manual dan memerlukan tinjauan AMS, lihat file CSV Ubah Jenis, yang tersedia di halaman **Sumber Daya Pengembang** di Konsol. CTs
**YouTube Video**: [Bagaimana cara menemukan jenis perubahan otomatis untuk AMS RFCs?](https://www.youtube.com/watch?v=sOzDuCCOduI&list=PLhr1KZpdzukc_VXASRqOUSM5AJgtHat6-&index=2&t=1s)
Untuk menemukan **mode Eksekusi** untuk CT di konsol AMS, Anda harus menggunakan opsi pencarian **jenis perubahan Jelajahi**. Hasilnya menunjukkan mode eksekusi dari jenis perubahan yang cocok atau jenis perubahan.
Untuk menemukan tipe perubahan tertentu dengan menggunakan AMS CLI, jalankan perintah ini: `AutomationStatus`
```
aws amscm --profile saml get-change-type-version --change-type-id CHANGE_TYPE_ID --query "ChangeTypeVersion.{AutomationStatus:AutomationStatus.Name}"
```
Anda juga dapat mencari jenis perubahan di [Referensi Jenis Perubahan AMS](https://docs.aws.amazon.com/managedservices/latest/ctref/index.html), yang menyediakan informasi tentang semua jenis perubahan AMS.
**catatan**
AMS saat API/CLI ini bukan bagian dari AWSAPI/CLI. To access the AMS API/CLI, Anda mengunduh AMS SDK melalui konsol AMS.
# Persyaratan persetujuan CT
AMS CTs selalu memiliki dua kondisi persetujuan, **AwsApprovalId**dan **CustomerApprovalId**itu menunjukkan apakah RFC memerlukan AMS atau Anda, atau siapa pun, untuk menyetujui eksekusi.
Kondisi persetujuan agak terkait dengan mode eksekusi; untuk detailnya, lihat[Otomatis dan manual CTs](ug-automated-or-manual.md).
Untuk mengetahui kondisi persetujuan untuk CT, Anda dapat melihat di [AMS Change Type Reference](https://docs.aws.amazon.com/managedservices/latest/ctref/index.html), atau menjalankannya [GetChangeTypeVersion](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_GetChangeTypeVersion.html). Keduanya juga akan memberi Anda **mode CT `AutomationStatusId` atau Eksekusi**.
Anda dapat menyetujui RFCs dengan menggunakan konsol AMS atau dengan perintah berikut:
```
aws amscm approve-rfc --rfc-id RFC_ID
```
**Kondisi persetujuan CT**
| Jika kondisi persetujuan CT adalah | Hal ini membutuhkan persetujuan dari | Dan |
| --- | --- | --- |
| `AwsApprovalId: Required` | Sistem tipe perubahan AMS, | Tidak ada tindakan yang diperlukan. Kondisi ini khas untuk otomatis CTs. |
| `AwsApprovalId: NotRequiredIfSubmitter` | Sistem jenis perubahan AMS dan tidak ada orang lain, jika RFC yang dikirimkan adalah untuk akun yang diserahkan, | Tidak ada tindakan yang diperlukan. Kondisi ini khas untuk manual CTs karena akan selalu ditinjau oleh operator AMS. |
| `CustomerApprovalId: NotRequired` | Sistem tipe perubahan AMS, | Jika RFC melewati pemeriksaan sintaks dan parameter, itu disetujui secara otomatis. |
| `CustomerApprovalId: Required` | Sistem tipe perubahan AMS dan Anda, | Pemberitahuan dikirimkan kepada Anda, dan Anda harus secara eksplisit menyetujui RFC, baik dengan menanggapi pemberitahuan, atau menjalankan operasi. [ApproveRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ApproveRfc.html) |
| `CustomerApprovalId: NotRequiredIfSubmitter` | Sistem tipe perubahan AMS dan tidak ada orang lain, jika Anda mengirimkan RFC. | Jika RFC melewati pemeriksaan sintaks dan parameter, itu disetujui secara otomatis. |
| Insiden Keamanan Mendesak atau Patch | AMS | Apakah auto disetujui dan diimplementasikan. |
# Ubah versi tipe
Jenis perubahan diberi versi dan versi berubah saat pembaruan besar dibuat untuk jenis perubahan.
Setelah memilih jenis perubahan menggunakan konsol AMS, Anda memiliki opsi untuk membuka area **konfigurasi tambahan** dan memilih versi jenis perubahan. Anda juga dapat menentukan versi jenis perubahan pada baris API/CLI perintah. Anda mungkin ingin melakukan ini karena berbagai alasan, termasuk:
+ Anda tahu bahwa versi jenis perubahan **Pembaruan** yang Anda inginkan harus cocok dengan versi jenis **Buat** perubahan yang Anda gunakan untuk membuat sumber daya yang sekarang ingin Anda perbarui. Misalnya, Anda mungkin memiliki instance Elastic Load Balancer (ELB) yang dibuat dengan ELB Create change type versi 1. Untuk memperbaruinya, pilih ELB Update versi 1.
+ Anda ingin menggunakan versi jenis perubahan yang memiliki opsi berbeda di dalamnya daripada jenis perubahan terbaru. Kami tidak merekomendasikan hal ini karena pembaruan AMS mengubah jenis terutama untuk alasan keamanan dan kami menyarankan Anda untuk selalu memilih versi terbaru.
# Buat jenis perubahan
Buat jenis perubahan dicocokkan version-to-version dengan jenis perubahan Perbarui. Artinya, versi tipe perubahan yang Anda gunakan untuk menyediakan sumber daya harus sesuai dengan versi jenis perubahan Perbarui yang akan Anda gunakan nanti untuk memodifikasi sumber daya tersebut. Misalnya, jika Anda membuat bucket S3 dengan Create S3 Bucket change type versi 2.0, dan kemudian ingin mengirimkan RFC untuk memodifikasi bucket S3 tersebut, Anda harus menggunakan Update S3 Bucket change type versi 2.0 juga, meskipun ada jenis perubahan Update S3 Bucket dengan versi 3.0.
Sebaiknya simpan catatan ID tipe perubahan dan versi yang Anda gunakan saat menyediakan sumber daya dengan tipe Buat perubahan jika nanti Anda ingin menggunakan jenis perubahan Pembaruan untuk memodifikasinya.
# Perbarui jenis perubahan
AMS menyediakan jenis perubahan Pembaruan untuk memperbarui sumber daya yang dibuat dengan tipe Buat perubahan. Jenis perubahan Perbarui harus dicocokkan version-to-version dengan jenis Buat perubahan yang awalnya digunakan untuk menyediakan sumber daya.
Sebaiknya simpan catatan ID tipe perubahan dan versi yang Anda gunakan saat menyediakan sumber daya agar mudah memperbaruinya.
**YouTube Video**: [Bagaimana cara menggunakan pembaruan CTs untuk mengubah sumber daya di akun AWS Managed Services (AMS)?](https://www.youtube.com/watch?v=dqb31yaAXhc&list=PLhr1KZpdzukc_VXASRqOUSM5AJgtHat6-&index=8&t=30s)
# Jenis perubahan hanya internal
Anda dapat melihat jenis perubahan yang hanya untuk penggunaan internal. Ini agar Anda tahu tindakan apa yang dapat atau dilakukan AMS. Jika ada jenis perubahan internal saja yang ingin Anda miliki untuk digunakan, kirimkan permintaan layanan.
Misalnya, ada Manajemen \$1 Pemantauan dan pemberitahuan \$1 penindasan CloudWatch alarm \$1 Perbarui CT yang hanya internal. AMS menggunakannya untuk menyebarkan pembaruan infrastruktur (seperti menambal) untuk mematikan pemberitahuan alarm yang mungkin dipicu oleh pembaruan secara keliru. Ketika CT ini dikirimkan, Anda akan melihat RFC untuk CT dalam daftar RFC Anda. CT internal apa pun yang digunakan dalam RFC akan muncul di daftar RFC Anda.
# Ubah skema tipe
Semua jenis perubahan menyediakan skema JSON untuk masukan Anda dalam pembuatan, modifikasi, atau akses, sumber daya. Skema menyediakan parameter, dan deskripsinya, bagi Anda untuk membuat permintaan perubahan (RFC).
Keberhasilan eksekusi RFC menghasilkan output eksekusi. Untuk penyediaan RFCs, output eksekusi menyertakan “stack\$1id” yang mewakili tumpukan CloudFormation dan dapat dicari di konsol. CloudFormation Output eksekusi terkadang menyertakan output ID dari instance yang dibuat dan ID tersebut dapat digunakan untuk mencari instance di konsol AWS yang sesuai. Misalnya, output eksekusi Create ELB CT menyertakan “stack\$1id” yang dapat dicari CloudFormation dan mengeluarkan nilai key=ELB = yang dapat dicari di konsol Amazon untuk Elastic Load Balancing. EC2
Mari kita periksa skema CT. Ini adalah skema untuk CodeDeploy Application Create, skema yang cukup kecil. Beberapa skema memiliki `Parameter` area yang sangat luas.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/ct-schemas.html)
**catatan**
Skema ini memungkinkan hingga tujuh tag; namun, EFS EC2, RDS, dan skema pembuatan multi-tier memungkinkan hingga 50 tag.
# Mengelola izin untuk jenis perubahan
Anda dapat menggunakan kebijakan khusus untuk membatasi jenis perubahan (CTs) yang tersedia untuk grup atau pengguna yang berbeda.
Untuk mempelajari lebih lanjut tentang melakukan hal ini, lihat bagian Panduan Pengguna AMS [Menyetel Izin](https://docs.aws.amazon.com/managedservices/latest/userguide/setting-permissions.html).
# Menyunting informasi sensitif dari jenis perubahan
Skema jenis perubahan AMS menawarkan atribut parameter, `"metadata":"ams:sensitive":"true"` yang digunakan untuk parameter yang berisi informasi sensitif, seperti kata sandi. Ketika atribut ini disetel, masukan yang diberikan dikaburkan. Perhatikan bahwa Anda tidak dapat menyetel atribut parameter ini; namun, jika Anda bekerja dengan AMS untuk membuat tipe perubahan dan memiliki parameter yang ingin dikaburkan pada input, Anda dapat meminta ini.
# Menemukan jenis perubahan, menggunakan opsi kueri
Contoh ini menunjukkan cara menggunakan Konsol AMS untuk menemukan jenis perubahan yang sesuai untuk RFC yang ingin Anda kirimkan.
Anda dapat menggunakan konsol atau API/CLI untuk menemukan perubahan jenis ID (CT) atau versi. Ada dua metode, baik pencarian atau memilih klasifikasi. Untuk kedua jenis pilihan, Anda dapat mengurutkan pencarian dengan memilih **Paling sering digunakan, **Paling baru digunakan****, atau **Alfabetis**.
**YouTube Video**: [Bagaimana cara membuat RFC menggunakan AWS Managed Services CLI dan di mana saya dapat menemukan Skema CT?](https://www.youtube.com/watch?v=IluDFwnJJFU&list=PLhr1KZpdzukc_VXASRqOUSM5AJgtHat6-&index=3&t=150s)
Di konsol AMS, pada halaman **RFCs**-> **Buat RFC**:
+ Dengan **Browse by change type** yang dipilih (default), baik:
+ Gunakan area **Quick create** untuk memilih dari AMS yang paling populer CTs. Klik pada label dan halaman **Jalankan RFC** terbuka dengan opsi **Subjek** diisi otomatis untuk Anda. Selesaikan opsi yang tersisa sesuai kebutuhan dan klik **Jalankan** untuk mengirimkan RFC.
+ Atau, gulir ke bawah ke **Semua jenis perubahan** area dan mulai mengetik nama CT di kotak opsi, Anda tidak harus memiliki nama jenis perubahan yang tepat atau lengkap. Anda juga dapat mencari CT dengan mengubah jenis ID, klasifikasi, atau mode eksekusi (otomatis atau manual) dengan memasukkan kata-kata yang relevan.
Dengan tampilan **Kartu** default yang dipilih, kartu CT yang cocok muncul saat Anda mengetik, pilih kartu dan klik **Buat RFC**. Dengan tampilan **Tabel** dipilih, pilih CT yang relevan dan klik **Buat RFC**. Kedua metode membuka halaman **Run RFC**.
+ Atau, dan untuk menjelajahi pilihan jenis perubahan, klik **Pilih berdasarkan kategori** di bagian atas halaman untuk membuka serangkaian kotak opsi drop-down.
+ Pilih **Kategori**, **Subkategori**, **Item**, dan **Operasi**. Kotak informasi untuk jenis perubahan itu muncul panel muncul di bagian bawah halaman.
+ Saat Anda siap, tekan **Enter**, dan daftar jenis perubahan yang cocok akan muncul.
+ Pilih jenis perubahan dari daftar. Kotak informasi untuk jenis perubahan itu muncul di bagian bawah halaman.
+ Setelah Anda memiliki jenis perubahan yang benar, pilih **Buat RFC**.
**catatan**
AMS CLI harus diinstal agar perintah ini berfungsi. Untuk menginstal AMS API atau CLI, buka halaman **Sumber Daya Pengembang** konsol AMS. Untuk materi referensi tentang AMS CM API atau AMS SKMS API, lihat bagian Sumber Informasi AMS di Panduan Pengguna. Anda mungkin perlu menambahkan `--profile` opsi untuk otentikasi; misalnya,`aws amsskms ams-cli-command --profile SAML`. Anda mungkin juga perlu menambahkan `--region` opsi karena semua perintah AMS kehabisan us-east-1; misalnya. `aws amscm ams-cli-command --region=us-east-1`
**catatan**
Titik akhir AMS API/CLI (amscm dan amsskms) berada di Wilayah AWS N. Virginia,. `us-east-1` Bergantung pada cara autentikasi Anda disetel, dan di Wilayah AWS akun dan sumber daya Anda, Anda mungkin perlu menambahkan `--region us-east-1` saat mengeluarkan perintah. Anda mungkin juga perlu menambahkan`--profile saml`, jika itu adalah metode otentikasi Anda.
Untuk mencari jenis perubahan menggunakan AMS CM API (lihat [ListChangeTypeClassificationSummaries](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ListChangeTypeClassificationSummaries.html)) atau CLI:
Anda dapat menggunakan filter atau kueri untuk mencari. ListChangeTypeClassificationSummaries Operasi memiliki opsi [Filter](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ListChangeTypeClassificationSummaries.html#amscm-ListChangeTypeClassificationSummaries-request-Filters) untuk`Category`,`Subcategory`,`Item`, dan`Operation`, tetapi nilainya harus sama persis dengan nilai yang ada. Untuk hasil yang lebih fleksibel saat menggunakan CLI, Anda dapat menggunakan opsi. `--query`
**Ubah jenis penyaringan dengan AMS CM API/CLI**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/ug-find-ct-ex-section.html)
1. Berikut adalah beberapa contoh klasifikasi jenis perubahan daftar:
Perintah berikut mencantumkan semua kategori jenis perubahan.
```
aws amscm list-change-type-categories
```
Perintah berikut mencantumkan subkategori milik kategori tertentu.
```
aws amscm list-change-type-subcategories --category CATEGORY
```
Perintah berikut mencantumkan item milik kategori dan subkategori tertentu.
```
aws amscm list-change-type-items --category CATEGORY --subcategory SUBCATEGORY
```
1. Berikut adalah beberapa contoh pencarian jenis perubahan dengan kueri CLI:
Perintah berikut mencari ringkasan klasifikasi CT untuk yang berisi “S3" di Nama item dan membuat output dari kategori, subkategori, item, operasi, dan mengubah ID tipe dalam bentuk tabel.
```
aws amscm list-change-type-classification-summaries --query "ChangeTypeClassificationSummaries [?contains(Item, 'S3')].[Category,Subcategory,Item,Operation,ChangeTypeId]" --output table
```
```
+---------------------------------------------------------------+
| ListChangeTypeClassificationSummaries |
+----------+-------------------------+--+------+----------------+
|Deployment|Advanced Stack Components|S3|Create|ct-1a68ck03fn98r|
+----------+-------------------------+--+------+----------------+
```
1. Anda kemudian dapat menggunakan ID tipe perubahan untuk mendapatkan skema CT dan memeriksa parameternya. Perintah berikut output skema ke file JSON bernama creates3params.schema.json.
```
aws amscm get-change-type-version --change-type-id "ct-1a68ck03fn98r" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateS3Params.schema.json
```
[Untuk informasi tentang penggunaan kueri CLI, lihat [Cara Memfilter Output dengan Opsi --query](https://docs.aws.amazon.com/cli/latest/userguide/controlling-output.html#controlling-output-filter) dan referensi bahasa kueri, Spesifikasi. JMESPath ](http://jmespath.org/specification.html)
1. Setelah Anda memiliki ID tipe perubahan, kami sarankan untuk memverifikasi versi untuk jenis perubahan untuk memastikan itu adalah versi terbaru. Gunakan perintah ini untuk menemukan versi untuk jenis perubahan tertentu:
```
aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=CHANGE_TYPE_ID
```
Untuk menemukan tipe perubahan tertentu, jalankan perintah ini: `AutomationStatus`
```
aws amscm --profile saml get-change-type-version --change-type-id CHANGE_TYPE_ID --query "ChangeTypeVersion.{AutomationStatus:AutomationStatus.Name}"
```
Untuk menemukan tipe perubahan tertentu, jalankan perintah ini: `ExpectedExecutionDurationInMinutes`
```
aws amscm --profile saml get-change-type-version --change-type-id ct-14027q0sjyt1h --query "ChangeTypeVersion.{ExpectedDuration:ExpectedExecutionDurationInMinutes}"
```
# Memecahkan masalah kesalahan RFC di AMS
Banyak kegagalan RFC penyediaan AMS dapat diselidiki melalui dokumentasi. CloudFormation Lihat [Pemecahan Masalah AWS CloudFormation:](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors) 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](https://docs.aws.amazon.com/managedservices/latest/userguide/find-FQDN.html) FQDN Anda.
+ Pastikan ID tumpukan yang Anda tentukan untuk akses adalah tumpukan terkait EC2. 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](https://docs.aws.amazon.com/managedservices/latest/userguide/find-stack.html)
+ Pastikan ID tumpukan yang Anda berikan sudah benar dan milik akun yang relevan.
Untuk bantuan terkait kegagalan akses RFC lainnya, lihat [Manajemen akses](https://docs.aws.amazon.com/managedservices/latest/userguide/access-mgmt.html).
**YouTube Video**: [Bagaimana cara mengajukan Request for Change (RFC) dengan benar untuk menghindari penolakan dan kegagalan?](https://www.youtube.com/watch?v=IFOn4Q-5Cas&list=PLhr1KZpdzukc_VXASRqOUSM5AJgtHat6-&index=5&t=242s)
### 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.
AMS bertujuan untuk menanggapi CT manual dalam waktu delapan 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 \$1 Lainnya \$1 Lainnya RFCs untuk pembaruan tumpukan, ketika ada jenis perubahan Pembaruan untuk jenis tumpukan yang ingin Anda perbarui.
### Kesalahan tumpukan hapus RFC
Kegagalan tumpukan hapus RFC: Jika Anda menggunakan Manajemen \$1 Stack standar \$1 Stack \$1 Delete CT, Anda akan melihat peristiwa terperinci di CloudFormation Konsol untuk tumpukan dengan nama tumpukan AMS. Anda dapat mengidentifikasi tumpukan Anda dengan memeriksanya terhadap nama yang ada di Konsol AMS. 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 \$1tidak\$1 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 \$1 Lainnya \$1 Lainnya \$1 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 \$1 Lainnya \$1 Lainnya \$1 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](https://docs.aws.amazon.com/managedservices/latest/appguide/ex-cfn-ingest-update-col.html)). Anda juga dapat mengirimkan Manajemen \$1 Lainnya \$1 Lainnya \$1 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 \$1 Lainnya \$1 Lainnya \$1 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](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-delete-stack-fails).
### 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, lihat[Memahami ulasan keamanan RFC](rfc-security.md).
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](samples/wigs-ce-lz-examples.zip) 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](https://docs.aws.amazon.com/managedservices/latest/userguide/access-console-temp.html).
+ 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 CloudFormation templat. Sebagai pelanggan, Anda memiliki akses hanya-baca ke semua layanan AWS termasuk CloudFormation, Anda dapat dengan cepat mengidentifikasi CloudFormation tumpukan yang mewakili tumpukan Anda berdasarkan deskripsi tumpukan menggunakan CloudFormation Konsol. Tumpukan yang gagal kemungkinan akan berada dalam keadaan DELETE\$1COMPLETE. Setelah Anda mengidentifikasi 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 CloudFormation template itu:
+ Buat kegagalan penyeimbang beban aplikasi: [ AWS::ElasticLoadBalancingV2::LoadBalancer (Application Load](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticloadbalancingv2-loadbalancer.html) Balancer)
+ Buat grup penskalaan Otomatis: [ AWS::AutoScaling::AutoScalingGroup (Grup Auto Scaling](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-group.html))
+ Buat cache memcache: [ AWS::ElastiCache::CacheCluster (](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-elasticache-cache-cluster.html)Cache Cluster)
+ Buat cache Redis: [ AWS::ElastiCache::CacheCluster (Cache Cluster](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-elasticache-cache-cluster.html))
+ [Buat DNS Hosted Zone (digunakan dengan Create DNS private/public): AWS::Route53::HostedZone (R53 Hosted Zone)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-route53-hostedzone.html)
+ [Buat DNS Record Set (digunakan dengan Create DNS private/public): AWS::Route53::RecordSet (Resource Record Set)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-route53-recordset.html)
+ Buat tumpukan EC2: [ AWS::EC2::Instance (Awan Komputasi Elastis)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-instance.html)
+ Buat Sistem File Elastis (EFS): [ AWS::EFS::FileSystem (Sistem File Elastis)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-efs-filesystem.html)
+ Buat Load balancer: [ AWS::ElasticLoadBalancing::LoadBalancer (Elastic Load](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-elb.html) Balancer)
+ Buat RDS DB: [ AWS::RDS::DBInstance (Database Relasional](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-rds-database-instance.html))
+ Buat Amazon S3: [ AWS::S3::Bucket (Layanan Penyimpanan Sederhana)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket.html)
+ Buat Antrian: [ AWS::SQS::Queue (Layanan Antrian Sederhana)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-sqs-queues.html)
### RFC membuat kesalahan AMIs
Amazon Machine Image (AMI) adalah templat yang berisi konfigurasi perangkat lunak (misalnya, sistem operasi, server aplikasi, dan aplikasi). Dari AMI, luncurkan sebuah instans, yang merupakan salinan AMI yang dijalankan sebagai server virtual di cloud. AMI sangat berguna, dan diperlukan untuk membuat instans EC2 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](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/Creating_EBSbacked_WinAMI.html#23ami-create-standard)
+ Nama yang Anda tentukan untuk AMI baru harus unik di dalam akun atau RFC gagal. Cara melakukannya dijelaskan dalam [AMI \$1 Buat](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-ami-create.html), dan untuk detail selengkapnya, lihat dan [AWS AMI Design](https://aws.amazon.com/answers/configuration-management/aws-ami-design/).
**catatan**
Untuk informasi tambahan tentang persiapan pembuatan AMI, lihat [AMI \$1 Buat](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-ami-create.html).
### RFCs membuat EC2s atau ASGs kesalahan
Untuk kegagalan EC2 atau 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 \$1 Buat](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-ami-create.html)) 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](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html)
Untuk mempelajari lebih lanjut tentang Amazon RDS secara umum, termasuk rekomendasi ukuran, lihat Dokumentasi Layanan [Amazon Relational Database Service](https://aws.amazon.com/documentation/rds/).
### 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 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.\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/images/rfcReason.png)
## 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 mengacu pada opsi pemecahan masalah berikut, maka libatkan AMS melalui korespondensi RFC. Untuk informasi selengkapnya, lihat [Korespondensi dan Lampiran RFC (Konsol)](https://docs.aws.amazon.com/managedservices/latest/userguide/ex-rfc-gui.html#ex-rfc-correspondence).
### Kesalahan konsumsi beban kerja (WIGS)
**catatan**
Alat validasi untuk Windows dan Linux dapat diunduh dan dijalankan langsung di server lokal Anda, serta instans EC2 di AWS. Hal ini dapat ditemukan melalui *Panduan Pengembang Aplikasi AMS Advanced* [Migrating workloads: Linux pre-ingestion validation dan [Migrating](https://docs.aws.amazon.com/managedservices/latest/appguide/ex-migrate-instance-win-validation.html) workloads: Windows pre-ingestion validation](https://docs.aws.amazon.com/managedservices/latest/appguide/ex-migrate-instance-linux-validation.html).
+ Pastikan instans EC2 ada di akun AMS target. Misalnya, jika Anda telah membagikan AMI dari akun non-AMS ke akun AMS, Anda harus membuat instans EC2 di akun AMS Anda 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 dengan`customer-mc-ec2-instance-profile`, Anda dapat memeriksanya di konsol EC2:
![\[EC2 instance details showing IAM role set to customer-mc-ec2-instance-profile.\]](http://docs.aws.amazon.com/id_id/managedservices/latest/onboardingguide/images/ec2ConsoleWCircle.png)
### Kesalahan penghentian tumpukan instans EC2
+ Periksa untuk melihat apakah instance sudah dalam keadaan berhenti atau dihentikan.
+ Jika instans EC2 sedang online dan Anda melihat `InternalError` kesalahan, maka kirimkan permintaan layanan untuk diselidiki AMS.
+ Perhatikan bahwa Anda tidak dapat menggunakan tipe perubahan Manajemen \$1 Komponen tumpukan lanjutan \$1 Tumpukan instans EC2 \$1 Hentikan ct-3mvvt2zkyveqj untuk menghentikan instans grup Auto Scaling (ASG). Jika Anda perlu menghentikan instans ASG, maka kirimkan permintaan layanan.
### Tumpukan instans EC2 membuat kesalahan
`InternalError`Pesannya berasal dari CloudFormation; alasan status CREATION\$1FAILED. 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](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html).
### Kesalahan pemulihan volume instans EC2
AMS membuat RFC pemecahan masalah internal saat pemulihan volume instans EC2 gagal. Ini dilakukan karena pemulihan volume instans EC2 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.
+ Jika Anda memerlukan bantuan dengan RFC terbuka atau RFC yang selesai tetapi salah, libatkan AMS melalui korespondensi dua arah RFC. Untuk informasi selengkapnya, lihat [Korespondensi dan Lampiran RFC (Konsol)](https://docs.aws.amazon.com/managedservices/latest/userguide/ex-rfc-gui.html#ex-rfc-correspondence).
+ 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](https://docs.aws.amazon.com/managedservices/latest/userguide/gui-ex-report-incident.html). Untuk informasi umum tentang manajemen insiden AMS, lihat [Respons insiden](https://docs.aws.amazon.com/managedservices/latest/userguide/sec-incident-response.html).
+ 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
1. Selanjutnya, jika eskalasi diperlukan, Anda dapat mengirim email ke Manajer Operasi AMS (tetapi CSDM Anda mungkin akan melakukannya): ams-opsmanager@amazon.com
1. Eskalasi lebih lanjut akan ke Direktur AMS: ams-director@amazon.com
1. Akhirnya, Anda selalu dapat menghubungi AMS VP: ams-vp@amazon.com