

• AWS Systems Manager CloudWatch Dasbor tidak akan lagi tersedia setelah 30 April 2026. Pelanggan dapat terus menggunakan CloudWatch konsol Amazon untuk melihat, membuat, dan mengelola CloudWatch dasbor Amazon mereka, seperti yang mereka lakukan hari ini. Untuk informasi selengkapnya, lihat [dokumentasi CloudWatch Dasbor Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). 

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

# AWS Systems ManagerPatch Managertutorial
<a name="patch-manager-tutorials"></a>

Tutorial di bagian ini menunjukkan cara menggunakanPatch Manager, alat di AWS Systems Manager, untuk beberapa skenario penambalan.

**Topics**
+ [Tutorial: Menambal server di IPv6 satu-satunya lingkungan](patch-manager-server-patching-iPv6-tutorial.md)
+ [Tutorial: Buat baseline patch untuk menginstal Paket Layanan Windows menggunakan konsol](patch-manager-windows-service-pack-patch-baseline-tutorial.md)
+ [Tutorial: Perbarui dependensi aplikasi, tambal node terkelola, dan lakukan pemeriksaan kesehatan khusus aplikasi menggunakan konsol](aws-runpatchbaselinewithhooks-tutorial.md)
+ [Tutorial: Menambal lingkungan server menggunakan AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)

# Tutorial: Menambal server di IPv6 satu-satunya lingkungan
<a name="patch-manager-server-patching-iPv6-tutorial"></a>

Patch Managermendukung penambalan node di lingkungan yang hanya memiliki IPv6. Dengan memperbarui SSM Agent konfigurasi, operasi patching dapat dikonfigurasi untuk hanya melakukan panggilan ke titik akhir IPv6 layanan.

**Untuk menambal server di IPv6 satu-satunya lingkungan**

1. Pastikan bahwa SSM Agent versi 3.3270.0 atau yang lebih baru diinstal pada node terkelola.

1. Pada node terkelola, navigasikan ke file SSM Agent konfigurasi. Anda dapat menemukan `amazon-ssm-agent.json` file di direktori berikut:
   + Linux: `/etc/amazon/ssm/`
   + macOS: `/opt/aws/ssm/`
   + Windows Server: `C:\Program Files\Amazon\SSM`

   Jika `amazon-ssm-agent.json` belum ada, salin isi di `amazon-ssm-agent.json.template` bawah direktori yang sama ke`amazon-ssm-agent.json`.

1. Perbarui entri berikut untuk mengatur Wilayah yang benar dan atur `UseDualStackEndpoint` ke`true`:

   ```
   {
    --------
       "Agent": {
           "Region": "region",
           "UseDualStackEndpoint": true
       },
   --------
   }
   ```

1. Mulai ulang SSM Agent layanan menggunakan perintah yang sesuai untuk sistem operasi Anda:
   + Linux: `sudo systemctl restart amazon-ssm-agent`
   + Ubuntu Servermenggunakan Snap: `sudo snap restart amazon-ssm-agent`
   + macOS: `sudo launchctl stop com.amazon.aws.ssm` diikuti oleh `sudo launchctl start com.amazon.aws.ssm`
   + Windows Server: `Stop-Service AmazonSSMAgent` diikuti oleh `Start-Service AmazonSSMAgent`

   Untuk daftar lengkap perintah per sistem operasi, lihat[Memeriksa SSM Agent status dan memulai agen](ssm-agent-status-and-restart.md).

1. Jalankan operasi penambalan apa pun untuk memverifikasi operasi penambalan berhasil di lingkungan IPv6 -only Anda. Pastikan node yang ditambal memiliki konektivitas ke sumber patch. Anda dapat memeriksa Run Command output dari eksekusi patching untuk memeriksa peringatan tentang repositori yang tidak dapat diakses. Saat menambal node yang berjalan di lingkungan IPv6 satu-satunya, pastikan bahwa node memiliki konektivitas ke sumber patch. Anda dapat memeriksa Run Command output dari eksekusi patching untuk memeriksa peringatan tentang repositori yang tidak dapat diakses. Untuk sistem operasi berbasis DNF, dimungkinkan untuk mengonfigurasi repositori yang tidak tersedia untuk dilewati selama penambalan jika opsi diatur ke bawah. `skip_if_unavailable` `True` `/etc/dnf/dnf.conf` Sistem operasi berbasis DNF termasuk Amazon Linux 2023, Red Hat Enterprise Linux 8 dan versi yang lebih baru, 8 dan versi yang lebih baru,,Rocky Linux, AlmaLinux & CentOS Oracle Linux 8 dan versi yang lebih baru. Di Amazon Linux 2023, `skip_if_unavailable` opsi diatur ke secara `True` default.
**catatan**  
 Saat menggunakan fitur Install Override List atau Baseline Override, pastikan URL yang disediakan dapat dijangkau dari node. Jika opsi SSM Agent konfigurasi `UseDualStackEndpoint` disetel ke`true`, maka klien S3 dualstack digunakan saat URL S3 disediakan.

# Tutorial: Buat baseline patch untuk menginstal Paket Layanan Windows menggunakan konsol
<a name="patch-manager-windows-service-pack-patch-baseline-tutorial"></a>

Ketika Anda membuat dasar patch kustom, Anda dapat menentukan bahwa semua, beberapa, atau hanya satu jenis patch yang didukung telah diinstal.

Di dasar patch untuk Windows, Anda dapat memilih `ServicePacks` sebagai satu-satunya opsi **Klasifikasi** untuk membatasi pembaruan patching hanya untuk Service Packs. Paket Layanan dapat diinstal secara otomatis olehPatch Manager, alat di AWS Systems Manager, asalkan pembaruan tersedia di Windows Update atau Windows Server Update Services (WSUS).

Anda dapat mengkonfigurasi dasar patch untuk mengendalikan apakah Service Packs untuk semua versi Windows diinstal, atau hanya untuk versi tertentu, seperti Windows 7 atau Windows Server 2016. 

Gunakan prosedur berikut untuk membuat baseline patch kustom untuk digunakan secara eksklusif untuk menginstal semua Paket Layanan pada node terkelola Windows Anda. 

**Untuk membuat baseline patch untuk menginstal Windows Service Packs (konsol)**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Patch Manager**.

1. Pilih tab **Patch baseline**, lalu pilih **Create patch** baseline. 

1. Untuk **Nama**, masukkan nama untuk dasar patch baru Anda, misalnya, `MyWindowsServicePackPatchBaseline`.

1. (Opsional) Untuk **Deskripsi**, masukkan deskripsi untuk dasar patch ini.

1. Untuk **Sistem operasi**, pilih `Windows`.

1. Jika Anda ingin mulai menggunakan dasar patch ini sebagai default untuk Windows segera setelah Anda membuatnya, pilih **Atur dasar patch ini sebagai dasar patch default untuk instans Windows Server**.
**catatan**  
Opsi ini hanya tersedia jika Anda pertama kali mengakses Patch Manager sebelum [kebijakan tambalan](patch-manager-policies.md) dirilis pada 22 Desember 2022.  
Untuk informasi tentang mengatur dasar patch yang ada sebagai default, lihat [Mengatur dasar patch yang ada sebagai default](patch-manager-default-patch-baseline.md).

1. Di bagian **Aturan persetujuan untuk sistem operasi**, gunakan bidang tersebut untuk membuat satu atau lebih aturan persetujuan otomatis.
   + **Produk**: Versi sistem operasi yang berlaku untuk aturan persetujuan, seperti`WindowsServer2012`. Anda dapat memilih satu, lebih dari satu, atau semua versi Windows yang didukung. Pilihan default adalah `All`.
   + **Klasifikasi**: Pilih `ServicePacks`. 
   + **Kepelikan**: Nilai kepelikan patch yang diberlakukan aturan. Untuk memastikan bahwa semua Service Packs disertakan oleh aturan, pilih `All`. 
   + **Persetujuan otomatis**: Metode untuk memilih patch untuk persetujuan otomatis.
     + **Menyetujui patch setelah beberapa hari tertentu**: Jumlah hari Patch Manager untuk menunggu setelah patch dirilis atau diperbarui sebelum patch secara otomatis disetujui. Anda dapat memasukkan bilangan bulat apa saja dari nol (0) sampai 360. Untuk sebagian besar skenario, kami merekomendasikan untuk menunggu tidak lebih dari 100 hari.
     + **Menyetujui patch yang dirilis hingga tanggal tertentu: Tanggal** rilis patch yang Patch Manager secara otomatis menerapkan semua patch yang dirilis atau diperbarui pada atau sebelum tanggal tersebut. Misalnya, jika Anda menentukan 7 Juli 2023, tidak ada tambalan yang dirilis atau terakhir diperbarui pada atau setelah 8 Juli 2023, yang diinstal secara otomatis.
   + (Opsional) **Laporan kepatuhan**: Tingkat kepelikan yang ingin Anda tetapkan untuk Service Packs yang disetujui oleh baseline, seperti `High`.
**catatan**  
Jika Anda menentukan tingkat pelaporan kepatuhan dan status patch dari Paket Layanan yang disetujui dilaporkan sebagai`Missing`, maka tingkat keparahan kepatuhan yang dilaporkan secara keseluruhan baseline patch adalah tingkat keparahan yang Anda tentukan.

1. (Opsional) Untuk **Kelola tag**, terapkan satu atau beberapa name/value pasangan kunci tag ke baseline patch.

   Tanda adalah metadata opsional yang Anda tetapkan ke sumber daya. Tag memungkinkan Anda untuk mengkategorikan sumber daya dengan berbagai cara, seperti berdasarkan tujuan, pemilik, atau lingkungan. Untuk dasar patch ini yang didedikasikan untuk memperbarui Service Packs, Anda dapat menentukan pasangan kunci-nilai seperti berikut:
   + `Key=OS,Value=Windows`
   + `Key=Classification,Value=ServicePacks`

1. Pilih **Buat dasar patch**.

# Tutorial: Perbarui dependensi aplikasi, tambal node terkelola, dan lakukan pemeriksaan kesehatan khusus aplikasi menggunakan konsol
<a name="aws-runpatchbaselinewithhooks-tutorial"></a>

Dalam banyak kasus, node terkelola harus di-boot ulang setelah ditambal dengan pembaruan perangkat lunak terbaru. Namun, me-reboot node dalam produksi tanpa perlindungan di tempat dapat menyebabkan beberapa masalah, seperti memanggil alarm, merekam data metrik yang salah, dan mengganggu sinkronisasi data.

Tutorial ini menunjukkan bagaimana menghindari masalah seperti ini dengan menggunakan AWS Systems Manager dokumen (dokumen SSM) `AWS-RunPatchBaselineWithHooks` untuk mencapai operasi penambalan multi-langkah yang kompleks yang menyelesaikan hal berikut:

1. Mencegah koneksi baru ke aplikasi

1. Menginstal pembaruan sistem operasi

1. Memperbarui dependensi paket aplikasi

1. Memulai ulang sistem

1. Melakukan pemeriksaan kesehatan khusus aplikasi

Untuk contoh ini, kami telah menyiapkan infrastruktur kami dengan cara ini:
+ Mesin virtual yang ditargetkan terdaftar sebagai node terkelola dengan Systems Manager.
+ `Iptables` digunakan sebagai firewall lokal.
+ Aplikasi yang di-host pada node terkelola berjalan pada port 443.
+ Aplikasi yang di-host pada node yang dikelola adalah `nodeJS` aplikasi.
+ Aplikasi yang di-host pada node yang dikelola dikelola oleh manajer proses pm2.
+ Aplikasi ini sudah memiliki titik akhir pemeriksaan kesehatan yang ditentukan.
+ Titik akhir pemeriksaan kesehatan aplikasi tidak memerlukan autentikasi pengguna akhir. Titik akhir memungkinkan dilakukannya pemeriksaan kesehatan yang memenuhi persyaratan organisasi dalam menetapkan ketersediaan. (Di lingkungan Anda, mungkin cukup untuk memastikan bahwa `nodeJS` aplikasi berjalan dan dapat mendengarkan permintaan. Dalam kasus lain, Anda mungkin ingin juga memverifikasi bahwa koneksi ke lapisan caching atau lapisan database telah dibuat.)

Contoh dalam tutorial ini adalah untuk tujuan demonstrasi saja dan tidak dimaksudkan untuk diimplementasikan apa adanya ke dalam lingkungan produksi. Juga, perlu diingat bahwa fitur kait siklus hidup, alat di Systems ManagerPatch Manager, dengan `AWS-RunPatchBaselineWithHooks` dokumen dapat mendukung banyak skenario lainnya. Berikut adalah beberapa contoh tanda.
+ Hentikan agen pelaporan metrik sebelum menambal dan memulai ulang setelah node terkelola reboot.
+ Lepaskan node terkelola dari cluster CRM atau PCS sebelum menambal dan memasang kembali setelah node reboot.
+ Perbarui perangkat lunak pihak ketiga (misalnya, Java, Tomcat, aplikasi Adobe, dan sebagainya) pada Windows Server mesin setelah pembaruan sistem operasi (OS) diterapkan, tetapi sebelum node yang dikelola reboot.

**Untuk memperbarui dependensi aplikasi, tambal node terkelola, dan lakukan pemeriksaan kesehatan khusus aplikasi**

1. Buat dokumen SSM untuk script pra-instalasi Anda dengan konten berikut ini dan berikan nama `NodeJSAppPrePatch`. Ganti *your\$1application* dengan nama aplikasi Anda.

   Script ini segera memblokir permintaan masuk baru dan menyediakan lima detik untuk permintaan yang sudah aktif agar diselesaikan sebelum memulai operasi patching. Untuk opsi `sleep`, tentukan jumlah detik lebih besar daripada yang biasanya diperlukan untuk permintaan masuk diselesaikan.

   ```
   # exit on error
   set -e
   # set up rule to block incoming traffic
   iptables -I INPUT -j DROP -p tcp --syn --destination-port 443 || exit 1
   # wait for current connections to end. Set timeout appropriate to your application's latency
   sleep 5 
   # Stop your application
   pm2 stop your_application
   ```

   Untuk informasi tentang membuat dokumen SSM, lihat [Membuat konten dokumen SSM](documents-creating-content.md).

1. Buat dokumen SSM lain dengan konten berikut ini untuk script pasca instalasi Anda untuk memperbarui dependensi aplikasi Anda dan berikan nama `NodeJSAppPostPatch`. Ganti */your/application/path* dengan jalur ke aplikasi Anda.

   ```
   cd /your/application/path
   npm update 
   # you can use npm-check-updates if you want to upgrade major versions
   ```

1. Buat dokumen SSM lain dengan konten berikut ini untuk script `onExit` Anda untuk menyalakan kembali aplikasi Anda dan melakukan pemeriksaan kesehatan. Namakan dokumen SSM ini `NodeJSAppOnExitPatch`. Ganti *your\$1application* dengan nama aplikasi Anda.

   ```
   # exit on error
   set -e
   # restart nodeJs application
   pm2 start your_application
   # sleep while your application starts and to allow for a crash
   sleep 10
   # check with pm2 to see if your application is running
   pm2 pid your_application
   # re-enable incoming connections
   iptables -D INPUT -j DROP -p tcp --syn --destination-port 
   # perform health check
   /usr/bin/curl -m 10 -vk -A "" http://localhost:443/health-check || exit 1
   ```

1. Buat asosiasi diState Manager, alat di AWS Systems Manager, untuk mengeluarkan operasi dengan melakukan langkah-langkah berikut:

   1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

   1. Di panel navigasi, pilih **State Manager**, lalu pilih **Buat asosiasi**.

   1. Untuk **Nama**, berikan nama untuk membantu mengidentifikasi tujuan asosiasi.

   1. Di daftar **Dokumen**, pilih `AWS-RunPatchBaselineWithHooks`.

   1. Untuk **Operasi**, pilih **Instal**.

   1. (Opsional) Untuk **Snapshot Id**, berikan GUID yang Anda buat untuk membantu mempercepat operasi dan memastikan konsistensi. Nilai GUID dapat sesederhana `00000000-0000-0000-0000-111122223333`.

   1. Untuk **Pre Install Hook Doc Name**, masukkan `NodeJSAppPrePatch`. 

   1. Untuk **Post Install Hook Doc Name**, masukkan `NodeJSAppPostPatch`. 

   1. Untuk **On ExitHook Doc Name**, masukkan`NodeJSAppOnExitPatch`. 

1. Untuk **Target**, identifikasi node terkelola Anda dengan menentukan tag, memilih node secara manual, memilih grup sumber daya, atau memilih semua node terkelola.

1. Untuk **Tentukan jadwal**, tentukan seberapa sering untuk menjalankan asosiasi. Untuk patch node terkelola, seminggu sekali adalah irama umum.

1. Di bagian **Rate control**, pilih opsi untuk mengontrol bagaimana asosiasi berjalan pada beberapa node terkelola. Pastikan bahwa hanya sebagian dari node terkelola yang diperbarui pada suatu waktu. Jika tidak, semua atau sebagian besar armada Anda dapat dijadikan offline sekaligus. Untuk informasi lebih lanjut tentang menggunakan kontrol rate, lihat [Memahami target dan kontrol tingkat dalam State Manager asosiasi](systems-manager-state-manager-targets-and-rate-controls.md).

1. (Opsional) Untuk **Pilihan output**, untuk menyimpan output perintah ke file, pilih kotak **Aktifkan output penulisan ke S3**. Masukkan nama bucket dan prefiks (folder) di dalam kotak.
**catatan**  
Izin S3 yang memberikan kemampuan untuk menulis data ke bucket S3 adalah izin dari profil instance yang ditetapkan ke node terkelola, bukan izin pengguna IAM yang melakukan tugas ini. Untuk informasi selengkapnya, lihat [Mengonfigurasi izin instans yang diperlukan untuk Systems Manager](setup-instance-permissions.md) atau [Membuat peran layanan IAM untuk lingkungan hibrid](hybrid-multicloud-service-role.md). Selain itu, jika bucket S3 yang ditentukan berbeda Akun AWS, verifikasi bahwa profil instance atau peran layanan IAM yang terkait dengan node terkelola memiliki izin yang diperlukan untuk menulis ke bucket tersebut.

1. Pilih **Buat Asosiasi**.

# Tutorial: Menambal lingkungan server menggunakan AWS CLI
<a name="patch-manager-patch-servers-using-the-aws-cli"></a>

Prosedur berikut ini menjelaskan cara melakukan patching untuk lingkungan server dengan menggunakan dasar patch kustom, grup patch, dan jendela pemeliharaan.

**Sebelum Anda mulai**
+ Instal atau perbarui SSM Agent pada node terkelola Anda. Untuk menambal node yang dikelola Linux, node Anda harus menjalankan SSM Agent versi 2.0.834.0 atau yang lebih baru. Untuk informasi selengkapnya, lihat [Memperbarui SSM Agent penggunaan Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
+ Konfigurasikan peran dan izin untukMaintenance Windows, alat di AWS Systems Manager. Untuk informasi selengkapnya, lihat [Menyiapkan Maintenance Windows](setting-up-maintenance-windows.md).
+ Instal dan konfigurasikan AWS Command Line Interface (AWS CLI), jika Anda belum melakukannya.

  Untuk selengkapnya, lihat [Menginstal atau memperbarui versi terbaru AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).

**Untuk mengkonfigurasi Patch Manager dan menambal node yang dikelola (baris perintah)**

1. Jalankan perintah berikut ini untuk membuat dasar patch untuk Windows yang bernama `Production-Baseline`. Garis dasar tambalan ini menyetujui tambalan untuk lingkungan produksi 7 hari setelah dirilis atau terakhir diperbarui. Artinya, kami menandai dasar patch untuk menunjukkan bahwa itu untuk lingkungan produksi.
**catatan**  
`OperatingSystem`Parameter dan `PatchFilters` bervariasi tergantung pada sistem operasi node terkelola target yang berlaku untuk patch baseline. Untuk informasi selengkapnya, lihat [OperatingSystem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-OperatingSystem) dan [PatchFilter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html).

------
#### [ Linux & macOS ]

   ```
   aws ssm create-patch-baseline \
       --name "Production-Baseline" \
       --operating-system "WINDOWS" \
       --tags "Key=Environment,Value=Production" \
       --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" \
       --description "Baseline containing all updates approved for production systems"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm create-patch-baseline ^
       --name "Production-Baseline" ^
       --operating-system "WINDOWS" ^
       --tags "Key=Environment,Value=Production" ^
       --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" ^
       --description "Baseline containing all updates approved for production systems"
   ```

------

   Sistem mengembalikan informasi seperti berikut ini.

   ```
   {
      "BaselineId":"pb-0c10e65780EXAMPLE"
   }
   ```

1. Jalankan perintah berikut ini untuk mendaftarkan dasar patch "Production-Baseline" untuk dua grup patch. Grup tersebut bernama "Database Servers" dan "Front-End Servers".

------
#### [ Linux & macOS ]

   ```
   aws ssm register-patch-baseline-for-patch-group \
       --baseline-id pb-0c10e65780EXAMPLE \
       --patch-group "Database Servers"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-patch-baseline-for-patch-group ^
       --baseline-id pb-0c10e65780EXAMPLE ^
       --patch-group "Database Servers"
   ```

------

   Sistem mengembalikan informasi seperti berikut.

   ```
   {
      "PatchGroup":"Database Servers",
      "BaselineId":"pb-0c10e65780EXAMPLE"
   }
   ```

------
#### [ Linux & macOS ]

   ```
   aws ssm register-patch-baseline-for-patch-group \
       --baseline-id pb-0c10e65780EXAMPLE \
       --patch-group "Front-End Servers"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-patch-baseline-for-patch-group ^
       --baseline-id pb-0c10e65780EXAMPLE ^
       --patch-group "Front-End Servers"
   ```

------

   Sistem mengembalikan informasi seperti berikut ini.

   ```
   {
      "PatchGroup":"Front-End Servers",
      "BaselineId":"pb-0c10e65780EXAMPLE"
   }
   ```

1. Jalankan perintah berikut ini untuk membuat dua jendela pemeliharaan untuk server produksi. Jendela pertama berjalan setiap hari Selasa pukul 10 malam. Jendela kedua berjalan setiap hari Sabtu pukul 10 malam. Selain itu, jendela pemeliharaan telah ditandai untuk menunjukkan bahwa itu untuk lingkungan produksi.

------
#### [ Linux & macOS ]

   ```
   aws ssm create-maintenance-window \
       --name "Production-Tuesdays" \
       --tags "Key=Environment,Value=Production" \
       --schedule "cron(0 0 22 ? * TUE *)" \
       --duration 1 \
       --cutoff 0 \
       --no-allow-unassociated-targets
   ```

------
#### [ Windows Server ]

   ```
   aws ssm create-maintenance-window ^
       --name "Production-Tuesdays" ^
       --tags "Key=Environment,Value=Production" ^
       --schedule "cron(0 0 22 ? * TUE *)" ^
       --duration 1 ^
       --cutoff 0 ^
       --no-allow-unassociated-targets
   ```

------

   Sistem mengembalikan informasi seperti berikut.

   ```
   {
      "WindowId":"mw-0c50858d01EXAMPLE"
   }
   ```

------
#### [ Linux & macOS ]

   ```
   aws ssm create-maintenance-window \
       --name "Production-Saturdays" \
       --tags "Key=Environment,Value=Production" \
       --schedule "cron(0 0 22 ? * SAT *)" \
       --duration 2 \
       --cutoff 0 \
       --no-allow-unassociated-targets
   ```

------
#### [ Windows Server ]

   ```
   aws ssm create-maintenance-window ^
       --name "Production-Saturdays" ^
       --tags "Key=Environment,Value=Production" ^
       --schedule "cron(0 0 22 ? * SAT *)" ^
       --duration 2 ^
       --cutoff 0 ^
       --no-allow-unassociated-targets
   ```

------

   Sistem mengembalikan informasi seperti berikut ini.

   ```
   {
      "WindowId":"mw-9a8b7c6d5eEXAMPLE"
   }
   ```

1. Jalankan perintah berikut ini untuk mendaftarkan grup patch server `Database` dan `Front-End` dengan jendela pemeliharaan masing-masing.

------
#### [ Linux & macOS ]

   ```
   aws ssm register-target-with-maintenance-window \
       --window-id mw-0c50858d01EXAMPLE \
       --targets "Key=tag:PatchGroup,Values=Database Servers" \
       --owner-information "Database Servers" \
       --resource-type "INSTANCE"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-target-with-maintenance-window ^
       --window-id mw-0c50858d01EXAMPLE ^
       --targets "Key=tag:PatchGroup,Values=Database Servers" ^
       --owner-information "Database Servers" ^
       --resource-type "INSTANCE"
   ```

------

   Sistem mengembalikan informasi seperti berikut.

   ```
   {
      "WindowTargetId":"e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE"
   }
   ```

------
#### [ Linux & macOS ]

   ```
   aws ssm register-target-with-maintenance-window \
   --window-id mw-9a8b7c6d5eEXAMPLE \
   --targets "Key=tag:PatchGroup,Values=Front-End Servers" \
   --owner-information "Front-End Servers" \
   --resource-type "INSTANCE"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-target-with-maintenance-window ^
       --window-id mw-9a8b7c6d5eEXAMPLE ^
       --targets "Key=tag:PatchGroup,Values=Front-End Servers" ^
       --owner-information "Front-End Servers" ^
       --resource-type "INSTANCE"
   ```

------

   Sistem mengembalikan informasi seperti berikut ini.

   ```
   {
      "WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE"
   }
   ```

1. Jalankan perintah berikut ini untuk mendaftarkan sebuah tugas patch yang menginstal pembaruan yang hilang pada server `Database` dan `Front-End` selama jendela pemeliharaan masing-masing.

------
#### [ Linux & macOS ]

   ```
   aws ssm register-task-with-maintenance-window \
       --window-id mw-0c50858d01EXAMPLE \
       --targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" \
       --task-arn "AWS-RunPatchBaseline" \
       --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
       --task-type "RUN_COMMAND" \
       --max-concurrency 2 \
       --max-errors 1 \
       --priority 1 \
       --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-task-with-maintenance-window ^
       --window-id mw-0c50858d01EXAMPLE ^
       --targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" ^
       --task-arn "AWS-RunPatchBaseline" ^
       --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
       --task-type "RUN_COMMAND" ^
       --max-concurrency 2 ^
       --max-errors 1 ^
       --priority 1 ^
       --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
   ```

------

   Sistem mengembalikan informasi seperti berikut.

   ```
   {
      "WindowTaskId":"4f7ca192-7e9a-40fe-9192-5cb15EXAMPLE"
   }
   ```

------
#### [ Linux & macOS ]

   ```
   aws ssm register-task-with-maintenance-window \
       --window-id mw-9a8b7c6d5eEXAMPLE \
       --targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" \
       --task-arn "AWS-RunPatchBaseline" \
       --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
       --task-type "RUN_COMMAND" \
       --max-concurrency 2 \
       --max-errors 1 \
       --priority 1 \
       --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-task-with-maintenance-window ^
       --window-id mw-9a8b7c6d5eEXAMPLE ^
       --targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" ^
       --task-arn "AWS-RunPatchBaseline" ^
       --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
       --task-type "RUN_COMMAND" ^
       --max-concurrency 2 ^
       --max-errors 1 ^
       --priority 1 ^
       --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
   ```

------

   Sistem mengembalikan informasi seperti berikut ini.

   ```
   {
      "WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE"
   }
   ```

1. Jalankan perintah berikut ini untuk mendapatkan ringkasan kepatuhan patch tingkat tinggi untuk grup patch. Ringkasan kepatuhan patch tingkat tinggi mencakup jumlah node terkelola dengan tambalan di masing-masing status patch.
**catatan**  
Diharapkan melihat nol untuk jumlah node terkelola dalam ringkasan hingga tugas tambalan berjalan selama jendela pemeliharaan pertama.

------
#### [ Linux & macOS ]

   ```
   aws ssm describe-patch-group-state \
       --patch-group "Database Servers"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm describe-patch-group-state ^
       --patch-group "Database Servers"
   ```

------

   Sistem mengembalikan informasi seperti berikut ini.

   ```
   {
      "Instances": number,
      "InstancesWithFailedPatches": number,
      "InstancesWithInstalledOtherPatches": number,
      "InstancesWithInstalledPatches": number,
      "InstancesWithInstalledPendingRebootPatches": number,
      "InstancesWithInstalledRejectedPatches": number,
      "InstancesWithMissingPatches": number,
      "InstancesWithNotApplicablePatches": number,
      "InstancesWithUnreportedNotApplicablePatches": number
   }
   ```

1. Jalankan perintah berikut untuk mendapatkan status ringkasan tambalan per node yang dikelola untuk grup tambalan. Ringkasan node per terkelola mencakup sejumlah tambalan di masing-masing status patch per node terkelola untuk grup patch.

------
#### [ Linux & macOS ]

   ```
   aws ssm describe-instance-patch-states-for-patch-group \
       --patch-group "Database Servers"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm describe-instance-patch-states-for-patch-group ^
       --patch-group "Database Servers"
   ```

------

   Sistem mengembalikan informasi seperti berikut ini.

   ```
   {
      "InstancePatchStates": [ 
         { 
            "BaselineId": "string",
            "FailedCount": number,
            "InstalledCount": number,
            "InstalledOtherCount": number,
            "InstalledPendingRebootCount": number,
            "InstalledRejectedCount": number,
            "InstallOverrideList": "string",
            "InstanceId": "string",
            "LastNoRebootInstallOperationTime": number,
            "MissingCount": number,
            "NotApplicableCount": number,
            "Operation": "string",
            "OperationEndTime": number,
            "OperationStartTime": number,
            "OwnerInformation": "string",
            "PatchGroup": "string",
            "RebootOption": "string",
            "SnapshotId": "string",
            "UnreportedNotApplicableCount": number
         }
      ]
   }
   ```

Untuk contoh AWS CLI perintah lain yang dapat Anda gunakan untuk tugas Patch Manager konfigurasi Anda, lihat[Bekerja dengan Patch Manager sumber daya menggunakan AWS CLI](patch-manager-cli-commands.md).