Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Kasus penggunaan
Anda dapat menggunakan Laporan AWS Biaya dan Penggunaan (AWS CUR) untuk memenuhi kebutuhan manajemen laporan Anda. Bagian ini membahas secara mendalam untuk membantu Anda memahami kasus penggunaan seperti melacak penggunaan, biaya, dan alokasi Savings Plans dan Reserved Instance (RI) Anda.
**Topics**
+ [
# Memahami Savings Plans
](cur-sp.md)
+ [
# Memahami reservasi Anda
](understanding-ri.md)
+ [
# Memahami biaya transfer data
](cur-data-transfers-charges.md)
+ [
# Memahami data alokasi biaya terpisah
](split-cost-allocation-data.md)
# Memahami Savings Plans
Anda dapat menggunakan Cost and Usage Reports (AWS CUR) untuk melacak pemanfaatan, biaya, dan alokasi Savings Plans Anda.
## Item baris Savings Plans
Savings Plans menyediakan model harga fleksibel yang menawarkan harga rendah di Amazon EC2, AWS Fargate AWS Lambda, dan Amazon SageMaker AI dengan imbalan komitmen terhadap jumlah penggunaan yang konsisten (diukur dalam \$1/jam) untuk jangka waktu 1 tahun atau 3 tahun.
Item baris berikut di AWS CUR membantu Anda melacak dan mengelola pengeluaran Anda dengan Savings Plans.
**catatan**
Dalam tabel berikut, kolom dan baris dari AWS CUR dialihkan untuk kejelasan. Nilai di kolom pertama mewakili header laporan. Contoh-contoh ini hanya mencakup beberapa kolom AWS CUR kunci. Untuk mempelajari lebih lanjut tentang kolom AWS CUR lainnya, lihat[Kamus data](data-dictionary.md).
**Biaya dimuka**
Item **SavingsPlanUpfrontFee**baris ditambahkan ke tagihan Anda saat Anda membeli `All Upfront` atau `Partial Upfront` Savings Plans. Tabel berikut menunjukkan bagaimana biaya satu kali ini muncul di beberapa kolom AWS CUR.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/cur/latest/userguide/cur-sp.html)
**Savings Plans biaya bulanan berulang**
Item **SavingsPlanRecurringFee**baris menjelaskan biaya per jam berulang yang sesuai dengan `No Upfront` atau `Partial Upfront` Savings Plans. Awalnya, **SavingsPlanRecurringFee**ditambahkan ke tagihan Anda pada hari pembelian dan setiap jam setelahnya.
**SavingsPlanRecurringFee**Dialokasikan untuk jam (berlaku untuk biaya dan penggunaan per jam) atau hari (berlaku untuk biaya dan penggunaan harian) ditambahkan ke tagihan Anda pada jam pembelian. Itu ditambahkan setiap hour/day periode penagihan selanjutnya.
Untuk `All Upfront` Savings Plans, item baris menunjukkan bagian dari Savings Plans yang tidak digunakan selama periode penagihan.
Tabel berikut menunjukkan bagaimana tagihan per jam berulang muncul di beberapa kolom AWS CUR.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/cur/latest/userguide/cur-sp.html)
SavingsPlanRecurringFee Ini dihitung secara berbeda dari biaya RI berulang. Biaya RI berulang adalah biaya bulanan sedangkan biaya SavingsPlanRecurringFee per jam. Untuk informasi tentang biaya RI berulang, lihat[Biaya RI bulanan berulang](regular-reserved-instances.md#recurring-monthly).
**Manfaat diskon Savings Plans**
Item **SavingsPlanCoveredUsage**baris menjelaskan penggunaan instans yang menerima manfaat Savings Plans. Item **SavingsPlanCoveredUsage**baris menunjukkan biaya yang tidak tercampur dari berapa biaya On-Demand tanpa manfaat Savings Plans. Biaya yang tidak tercampur ini diimbangi oleh item baris yang sesuai **SavingsPlanNegation**.
Di setiap item **SavingsPlanCoveredUsage**baris, Anda dapat melihat bagaimana penggunaan tersebut ditagih terhadap komitmen per jam Savings Plans Anda dengan menggunakan kolom **savingsPlan/SavingsPlanRate**and **savingsPlan/SavingsPlanEffectiveCost**.
Anda akan melihat yang sesuai **SavingsPlanNegation**untuk setiap item **SavingsPlanCoveredUsage**baris. **SavingsPlanNegation**item baris mengimbangi biaya yang tidak tercampur **SavingsPlanCoveredUsage**, dan dikelompokkan pada tingkat per jam berdasarkan SavingsPlan ARN, Operasi, Jenis Penggunaan, dan Zona Ketersediaan. Oleh karena itu, satu item **SavingsPlanNegation**baris mungkin sesuai dengan beberapa item **SavingsPlanCoveredUsage**baris.
Tabel berikut menunjukkan bagaimana penggunaan tertutup dan item baris negasi muncul di beberapa kolom AWS CUR.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/cur/latest/userguide/cur-sp.html)
Jika Anda memiliki lebih banyak penggunaan daripada yang dapat ditanggung oleh komitmen Savings Plans, penggunaan yang tidak tercakup masih muncul sebagai Item Baris Penggunaan dan penggunaan yang tercakup akan muncul seperti **SavingsPlanCoveredUsage**item **SavingsPlanNegation**baris yang sesuai.
# Memahami reservasi Anda
Anda dapat menggunakan Laporan AWS Biaya dan Penggunaan (AWS CUR) untuk melacak pemanfaatan, biaya, dan alokasi Instans Cadangan (RI) Anda. Bagian ini adalah deskripsi mendalam untuk memahami reservasi Anda.
**Topics**
+ [
# Memahami item baris reservasi Anda
](regular-reserved-instances.md)
+ [
# Memahami data reservasi Anda yang diamortisasi
](amortized-reservation.md)
+ [
# Memantau pemesanan fleksibel ukuran Anda untuk Amazon EC2
](monitor-flexible-reservation.md)
+ [
# Memantau reservasi kapasitas On-Demand
](monitor-ondemand-reservations.md)
# Memahami item baris reservasi Anda
RIs memberi Anda diskon yang signifikan dibandingkan dengan harga Instans Sesuai Permintaan. RIsbukan contoh fisik. Ini adalah diskon penagihan yang diterapkan untuk penggunaan Instans Sesuai Permintaan di akun Anda. Instans Sesuai Permintaan ini harus sesuai dengan atribut tertentu untuk mendapatkan keuntungan dari diskon penagihan.
**Topics**
+ [
## Biaya dimuka
](#upfront-fee)
+ [
## Biaya True-up
](#true-up-fee)
+ [
## Biaya RI bulanan berulang
](#recurring-monthly)
+ [
## Manfaat diskon RI
](#discount-benefits)
+ [
## Jenis Instans Cadangan
](#ri-type)
+ [
## Manfaat Instans Cadangan diterapkan pada penggunaan instans
](#ri-instance-usage)
**catatan**
Dalam tabel berikut, kolom dan baris dari AWS CUR dialihkan untuk kejelasan. Nilai di kolom pertama mewakili header laporan. Contoh-contoh ini hanya mencakup beberapa kolom AWS CUR kunci. Untuk mempelajari lebih lanjut tentang kolom AWS CUR lainnya, lihat[Kamus data](data-dictionary.md).
## Biaya dimuka
Item baris **Biaya** ditambahkan ke tagihan Anda saat Anda membeli `All Upfront` atau `Partial Upfront` RI.
Tabel berikut menunjukkan bagaimana biaya satu kali ini muncul di beberapa kolom AWS CUR.
| | |
| --- |--- |
| lineItem/LineItemType | Biaya |
| lineItem/ProductCode | Amazon EC2 |
| lineItem/UsageStartDate | 2016-01-01T 00:00:00 Z |
| lineItem/LineItemDescription | Biaya pendaftaran untuk berlangganan: 363836886, planID: 1026576 |
| lineItem/UnblendedCost | 68 |
| Reservation/ReservationARN | arn:aws:ec2:us-east- 1:123456789012: reserved-instances/f8c204c1-dd48-43f1-adb8-f88aa61e0dea |
## Biaya True-up
Jika Anda menukar Instans Cadangan Konvertibel, biaya apa pun yang terkait dengan pertukaran Instans Cadangan asli dan instans Cadangan baru (biaya true-up) juga ditambahkan ke tagihan Anda sebagai item baris **Biaya**. Untuk biaya true-up, **reservation/ReservationARN**kolom berisi **reserved-instance-exchange/riex**.
Tabel berikut menunjukkan biaya true-up dari penukaran Instans Cadangan Konvertibel.
| lineItem/LineItemType | lineItem/ProductCode | lineItem/UsageStartDate | lineItem/LineItemDescription | lineItem/UnblendedCost | Reservation/ReservationARN |
| --- | --- | --- | --- | --- | --- |
| Biaya | Amazon EC2 | 2016-01-01T 00:00:00 Z | | | arn:aws:ec2:eu-west- 1:012345678901: /riex-examplef-5d71-4215-886f-17a3f64ea972 reserved-instance-exchange |
## Biaya RI bulanan berulang
Item baris **Biaya RI** menjelaskan biaya bulanan berulang yang terkait RIs diterapkan pada bulan itu. **Biaya RI** awalnya ditambahkan ke tagihan Anda pada hari pembelian dan pada hari pertama setiap periode penagihan setelahnya.
**Biaya RI** dihitung dengan mengalikan tarif per jam diskon Anda dan jumlah jam dalam sebulan.
Tabel berikut menunjukkan bagaimana tagihan bulanan berulang muncul dalam laporan.
| | |
| --- |--- |
| lineItem/LineItemType | Biaya RI |
| lineItem/ProductCode | Amazon EC2 |
| lineItem/UsageStartDate | 2016-01-01T 00:00:00 Z |
| lineItem/UsageType | HeavyUsage: m4. besar |
| lineItem/LineItemDescription | Biaya per jam USD 0,0309 per jam ( Linux/UNIX Amazon VPC), m4.large instance |
| lineItem/NormalizationFactor | 4 |
| lineItem/UnblendedCost | 23 |
| Reservation/AvailabilityZone | |
| Reservation/ReservationARN | arn:aws:ec2:us-east- 1:123456789012: reserved-instances/f8c204c1-dd48-43f1-adb8-f88aa61e0dea |
| Reservation/TotalReservedunits | 744 |
| Reservation/TotalReservedNormalizedUnits | 2976 |
Biaya bulanan berulang dicatat secara berbeda untuk RIs yang memiliki cakupan Availability Zone atau Wilayah AWS Region. Untuk RIs yang memiliki cakupan Availability Zone, Availability Zone yang sesuai ditampilkan di **reservation/AvailabilityZone**kolom. Untuk RIs yang memiliki lingkup Wilayah, **reservation/AvailabilityZone**kolom kosong. RIs dengan lingkup Wilayah memiliki nilai untuk **lineitem/NormalizationFactor**dan **reservation/TotalReservedNormalizedUnits**kolom yang menunjukkan ukuran instance.
**catatan**
Biaya RI berulang dihitung secara berbeda dari biaya. SavingsPlanRecurringFee Biaya RI berulang adalah biaya bulanan sedangkan biaya SavingsPlanRecurringFee per jam. Untuk informasi tentang SavingsPlanRecurringFee, lihat[Memahami Savings Plans](cur-sp.md).
## Manfaat diskon RI
Item baris **Penggunaan Diskon** menjelaskan penggunaan instans yang menerima manfaat diskon RI yang cocok, dan ditambahkan ke tagihan Anda jika Anda memiliki penggunaan yang cocok dengan salah satu dari Anda RIs. AWS menghitung manfaat diskon RI berdasarkan penggunaan yang cocok: misalnya, penggunaan instance yang cocok dengan reservasi instans. Jika Anda memiliki penggunaan yang cocok, biaya yang terkait dengan item baris penggunaan selalu nol karena biaya yang terkait dengan RIs sudah diperhitungkan dalam dua item baris lainnya (biaya di muka dan biaya bulanan berulang).
Tabel berikut menunjukkan contoh penggunaan yang menerima manfaat diskon RI.
| | |
| --- |--- |
| lineItem/LineItemType | DiscountedUsage |
| lineItem/ProductCode | Amazon EC2 |
| lineItem/UsageStartDate | 2016-01-01T 00:00:00 Z |
| lineItem/UsageType | BoxUsage:m4. besar |
| lineItem/LineItemDescription | Linux/Unix (Amazon VPC), Instans Cadangan m4.large diterapkan |
| lineItem/ResourceId | i-1bd250bc |
| lineItem/AvailabilityZone | us-east-1b |
| lineItem/NormalizationFactor | 4 |
| lineItem/NormalizedUsageAmount | 4 |
| lineItem/UnblendedRate | 0 |
| lineItem/UnblendedCost | 0 |
| Reservation/ReservationARN | arn:aws:ec2:us-east- 1:123456789012: reserved-instances/f8c204c1-dd48-43f1-adb8-f88aa61e0dea |
Nilai untuk **UsageAmount**di **DiscountedUsage**baris Amazon EC2 adalah jumlah jam aktual yang digunakan. Nilai untuk **NormalizedUsageAmount**adalah nilai untuk **UsageAmount**dikalikan dengan nilai untuk. **NormalizationFactor** Nilai untuk **NormalizationFactor**ditentukan oleh ukuran instance. Ketika diskon manfaat RI diterapkan ke item baris penggunaan yang cocok, nilai Amazon Resource Name (ARN) di **reservation/ReservationARN**kolom untuk biaya awal di muka dan biaya bulanan berulang cocok dengan nilai ARN di item baris penggunaan yang didiskon.
Untuk informasi selengkapnya tentang pemetaan ukuran instans ke faktor normalisasi, lihat [Support untuk memodifikasi ukuran instans di Panduan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ri-modification-instancemove.html) Pengguna *Amazon* EC2.
## Jenis Instans Cadangan
Untuk menentukan apakah item baris laporan Anda dikaitkan dengan Instans Cadangan Standar atau Instans Cadangan Konvertibel, filter **lineItem/LineItemType**kolom berdasarkan **Biaya** atau **biaya RI**. Kemudian, tinjau **product/OfferingClass**kolom, yang menunjukkan jenis Instans Cadangan.
Untuk menentukan apakah item baris laporan Anda terkait dengan Instans Cadangan zona atau regional, tinjau **reservation/AvailabilityZone**kolom tersebut. Untuk Instans Cadangan zona, kolom ini menunjukkan Availability Zone yang sesuai. Untuk Instans Cadangan regional, kolom ini kosong.
## Manfaat Instans Cadangan diterapkan pada penggunaan instans
Untuk memahami item baris penggunaan instance mana yang diuntungkan dari Instans Cadangan, Anda dapat memfilter laporan berdasarkan satu atau beberapa kolom berikut:
+ **reservation/reservationARN**: Filter kolom ini dengan ARN reservasi untuk mengidentifikasi sewa Instans Cadangan mana yang terkait dengan setiap item baris.
+ **lineitem/ResourceId**: Tinjau kolom ini untuk ID sumber daya yang dicakup oleh Instans Cadangan.
+ **lineitem/LineItemType**: Filter kolom ini berdasarkan **Biaya**, **biaya RI**, atau **DiscountedUsage**untuk menentukan biaya atau manfaat terkait.
+ **lineitem/UsageType**: Filter kolom ini dengan **HeavyUsage**untuk mengidentifikasi item baris **biaya RI**. Atau, filter kolom ini **BoxUsage**untuk mengidentifikasi item **DiscountedUsage**baris.
+ **lineitem/UsageAmount**: Untuk item baris **biaya RI**, kolom ini menunjukkan jumlah total jam di bulan saat Instans Cadangan diterapkan. Untuk item **DiscountedUsage**baris, kolom ini menunjukkan jumlah jam yang diterapkan Instans Cadangan ke instans tertentu di tingkat harian atau bulanan, tergantung pada cara Anda mengonfigurasi laporan.
Untuk memahami ukuran unit dinormalisasi Instans Cadangan fleksibel yang diterapkan pada penggunaan instans, tinjau **lineitem/NormalizedUsageAmount**kolom dalam laporan Anda. Nilai dalam kolom ini sama dengan produk dari kolom berikut:
+ **lineitem/UsageAmount**: Kolom ini menunjukkan penggunaan instance terukur yang diukur dalam jam.
+ **lineItem/NormalizationFactor**: Untuk **DiscountedUsage**dan item baris **biaya RI**, kolom ini menunjukkan faktor normalisasi terkait dari instance. Untuk informasi selengkapnya tentang faktor normalisasi, lihat [Fleksibilitas ukuran instans yang ditentukan oleh faktor normalisasi](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/apply_ri.html#ri-normalization-factor) di Panduan Pengguna *Amazon EC2*.
Untuk AWS Organizations dengan beberapa akun, untuk melihat akun mana yang dibeli atau diuntungkan dari Instans Cadangan, tinjau kolom berikut:
+ **reservation/reservationARN**: Tinjau reservasi ARNs untuk melihat akun mana yang membeli Instans Cadangan. ARN menyertakan ID akun.
+ **lineitem/UsageAccountId**: Untuk item **DiscountedUsage**baris, kolom ini mengidentifikasi akun IDs yang menerima manfaat dari Instans Cadangan yang dibeli.
**catatan**
Instans Cadangan adalah langganan penagihan dan bukan sumber daya seperti instans Amazon EC2. Karena itu, Instans Cadangan yang diberi tag tidak mengisi item baris seperti sumber daya yang diberi tag. Untuk item baris dengan **DiscountedUsage**, tag diisi untuk sumber daya yang ditandai dan bukan untuk Instans Cadangan.
Untuk mengidentifikasi biaya yang terkait dengan sewa Instans Cadangan tertentu, Anda dapat memfilter item baris **Biaya** **atau biaya RI** berdasarkan ARN Instans Cadangan, yang merupakan ID sewa. Untuk mengatur data biaya untuk Instans Cadangan, pertimbangkan untuk menggunakan AWS Cost Categories. Untuk informasi selengkapnya, lihat [Mengelola biaya Anda dengan AWS Cost Categories](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) di *Panduan AWS Billing Pengguna*
# Memahami data reservasi Anda yang diamortisasi
Amortisasi adalah ketika Anda mendistribusikan biaya reservasi satu kali selama periode penagihan yang dipengaruhi oleh biaya tersebut. Amortisasi memungkinkan Anda untuk melihat biaya Anda dalam akuntansi berbasis akrual dibandingkan dengan akuntansi berbasis tunai. Misalnya, jika Anda membayar \$1365 untuk All Upfront RI selama satu tahun dan Anda memiliki contoh yang cocok yang menggunakan RI itu, instance itu dikenakan biaya \$11 per hari, diamortisasi.
Anda dapat melihat data yang digunakan Billing and Cost Management untuk menghitung biaya amortisasi Anda di kolom Laporan Biaya dan Penggunaan berikut.
**Topics**
+ [
## Inventaris Instans Cadangan
](#ri-inventory)
+ [
## Data amortisasi untuk periode penagihan
](#amortization-billing-period)
+ [
## Biaya efektif Instans Cadangan
](#ri-effective-costs)
**catatan**
Tidak semua **reservation/**kolom diisi untuk setiap item baris Instans Cadangan. **reservation/**Kolom dalam laporan Anda diisi berdasarkan jenis item baris. Misalnya, item baris **biaya RI** mengisi **reservation/UnusedAmortizedUpfrontFeeForBillingPeriod**kolom. Sementara itu, item **DiscountedUsage**baris mengisi **reservation/effectivecost**kolom.
## Inventaris Instans Cadangan
Anda dapat menggunakan kolom berikut untuk melacak inventaris RI Anda. Nilai untuk kolom ini hanya muncul untuk item baris langganan RI (juga dikenal sebagai item `RI Fee` baris) dan bukan untuk instance aktual yang RIs menggunakan.
Untuk informasi selengkapnya tentang deskripsi kolom dan nilai sampel, lihat[Rincian reservasi](reservation-columns.md).
+ reservation/UpfrontValue
+ reservation/startTime
+ reservation/endTime
+ reservation/modificationStatus
## Data amortisasi untuk periode penagihan
Anda dapat menggunakan kolom berikut untuk memahami biaya amortisasi Anda RIs untuk periode penagihan. Nilai untuk kolom ini hanya muncul untuk item baris langganan RI (juga dikenal sebagai item `RI Fee` baris) dan bukan untuk instance aktual yang RIs menggunakan.
Untuk informasi selengkapnya tentang deskripsi kolom dan nilai sampel, lihat[Rincian reservasi](reservation-columns.md).
+ reservation/amortizedUpfrontFeeForBillingPeriod
+ reservation/unusedQuantity
+ reservation/unusedNormalizedUnitQuantity
+ reservation/unusedRecurringFee
+ reservation/unusedAmortizedUpfrontFeeForBillingPeriod
## Biaya efektif Instans Cadangan
Anda dapat menggunakan kolom berikut untuk memahami biaya efektif Anda di tingkat instans. Nilai untuk kolom ini hanya muncul untuk item baris penggunaan misalnya (juga dikenal sebagai item `Discounted Usage boxUsage` baris).
Untuk informasi selengkapnya tentang deskripsi kolom dan nilai sampel, lihat[Rincian reservasi](reservation-columns.md).
+ reservation/amortizedUpfrontCostForUsage
+ reservation/recurringFeeForUsage
+ reservation/effectiveCost
# Memantau pemesanan fleksibel ukuran Anda untuk Amazon EC2
Instans Cadangan Amazon EC2 yang berlaku untuk Wilayah memberikan fleksibilitas Zona Ketersediaan dan fleksibilitas ukuran instans. Instans Cadangan yang memberikan fleksibilitas Availability Zone memberikan diskon untuk penggunaan di Availability Zone di Wilayah. Instans Cadangan yang memberikan fleksibilitas ukuran instans memberikan diskon untuk penggunaan, terlepas dari ukuran instans dalam keluarga tersebut. Ukuran fleksibel Instans Cadangan berlaku untuk ukuran instans terkecil terlebih dahulu. Untuk informasi selengkapnya, lihat [Cara Instans Cadangan diterapkan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/apply_ri.html) di Panduan *Pengguna Amazon EC2*.
Untuk memahami bagaimana fleksibilitas ukuran instans yang disediakan oleh Instans Cadangan diterapkan pada penggunaan Anda, lihat **lineItem/NormalizedUsageAmount**kolom **lineItem/NormalizationFactor**dan.
**catatan**
Fleksibilitas ukuran instans hanya didukung oleh Instans Cadangan Linux atau Unix dengan penyewaan default yang ditetapkan ke Wilayah. Untuk informasi selengkapnya tentang batasan fleksibilitas ukuran instans untuk Instans Cadangan Regional, lihat [Cara Instans Cadangan regional diterapkan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/apply_ri.html#apply-regional-ri) di Panduan Pengguna *Amazon EC2*.
Dalam Laporan Biaya dan Penggunaan, penggunaan Instans Cadangan diterapkan secara default ke akun yang membeli Instans Cadangan. Manfaat Instans Cadangan yang tersedia yang tidak dapat digunakan oleh akun pembelian dalam satu jam kemudian diterapkan ke akun tertaut lainnya berdasarkan penggunaan Instans Sesuai Permintaan yang tersedia.
## Contoh
Anda membeli satu `m4.xlarge` RI di Wilayah tertentu. `m4.xlarge`RI ini dapat diterapkan secara otomatis untuk semua penggunaan `m4` instance di Wilayah yang sama. Dalam tabel berikut, AWS diterapkan `m4.xlarge` ke dua `m4.large` contoh terpisah.
| | | | |
| --- |--- |--- |--- |
| lineItem/LineItemType | RIFee | Penggunaan Diskon | Penggunaan Diskon |
| lineItem/ProductCode | Amazon EC2 | Amazon EC2 | Amazon EC2 |
| lineItem/UsageStartDate | 2016-01-01T 00:00:00 Z | 2016-01-01T 00:00:00 Z | 2016-01-01T 00:00:00 Z |
| lineItem/UsageType | HeavyUsage:m4.xlarge | BoxUsage:m4. besar | BoxUsage:m4. besar |
| lineItem/LineItemDescription | USD 0.0618 biaya per jam per ( Linux/UNIX Amazon VPC), instans m4.xlarge | Linux/Unix (Amazon VPC), Instans Cadangan m4.large diterapkan | Linux/Unix (Amazon VPC), Instans Cadangan m4.large diterapkan |
| lineItem/ResourceId | | i-1bd250bc | i-1df340ed |
| lineItem/UsageAmount | | 1 | 1 |
| lineItem/NormalizationFactor | 4 | 4 | 4 |
| lineItem/NormalizedUsageAmount | | 4 | 4 |
| lineItem/UnblendedRate | | 0 | 0 |
| lineItem/UnblendedCost | 46 | 0 | 0 |
| Reservation/ ReservationARN | arn:aws:ec2:us-east-1:123456789012: reserved-instance /f8c204c1 | arn:aws:ec2:us-east-1:123456789012: reserved-instance /f8c204c1 | arn:aws:ec2:us-east-1:123456789012: reserved-instance /f8c204c1 |
| Reservation/TotalReservedUnits | 744 | | |
| Reservation/TotalReserved NormalizedUnits | 5952 | | |
Kedua item lini `m4.large` penggunaan memiliki **ResourceId**s yang berbeda, dan keduanya menerima manfaat diskon dari `m4.xlarge` RI tunggal. Hal ini ditunjukkan dengan mencocokkan nilai **ReservationArn** di seluruh penggunaan dan item baris biaya bulanan berulang.
Untuk informasi selengkapnya tentang opsi pembelian RI, lihat [Cara Anda ditagih](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts-reserved-instances-application.html#reserved-instances-payment-options) di Panduan *Pengguna Amazon EC2*.
# Memantau reservasi kapasitas On-Demand
Reservasi kapasitas memungkinkan Anda untuk memesan kapasitas instans Amazon EC2 untuk durasi apa pun di Availability Zone tertentu. Hal ini memungkinkan Anda untuk membuat dan mengelola reservasi kapasitas secara terpisah dari diskon penagihan yang ditawarkan oleh Regional Reserved Instances (RI). Untuk mendapatkan keuntungan dari diskon penagihan, Anda dapat menggunakan Regional RIs dalam kombinasi dengan pemesanan kapasitas.
## Item baris reservasi kapasitas
Anda dapat menggunakan beberapa kolom yang ditentukan dalam kamus data AWS CUR untuk melacak reservasi kapasitas Anda. Kolom berikut juga digunakan untuk pemesanan kapasitas.
Bagian ini mendefinisikan item baris ini dengan definisi tambahan khusus untuk reservasi kapasitas.
Untuk informasi selengkapnya tentang deskripsi kolom Laporan Biaya dan Penggunaan, lihat[Detail item baris](Lineitem-columns.md).
A \$1 [B](#lcr-B) \$1 C \$1 D \$1 E \$1 F \$1 G \$1 H \$1 I \$1 J \$1 K \$1 L \$1 M \$1 N \$1 O \$1 P \$1 T \$1 S \$1 T [R](#lcr-R) \$1 [U](#lcr-U) \$1 VWXYZ
### B
#### lineItem/BlendedRate
Untuk pemesanan kapasitas dengan **UsageType****Reservasi** atau **DedicatedRes**, **BlendedRate**adalah`0`. Ini karena biaya reservasi kapasitas dikaitkan dengan instance yang menyediakan kapasitas, bukan dengan reservasi kapasitas itu sendiri.
### R
#### lineItem/ResourceId
Jika disertakan `lineItem/ResourceId` saat membuat Laporan Biaya dan Penggunaan, Anda dapat mengidentifikasi dan melacak reservasi kapasitas menggunakan **ResourceId**kolom. Reservasi **ResourceId**kapasitas ditangkap hanya untuk **UnusedBox, **UnusedDed**,** **Reservasi**, dan **DedicatedRes**UsageTypes****.
Reservasi kapasitas selalu menyertakan `cr-` ID sumber daya mereka, dan ID sumber daya memiliki format berikut:
```
arn:aws:ec2:::/cr-0be443example1db6f
```
### U
#### lineItem/UnblendedCost
`BlendedRate`Dikalikan dengan. `UsageAmount`
#### lineItem/UnblendedRate
Untuk pemesanan kapasitas dengan **UsageType****Reservasi** atau **DedicatedRes**, **UnblendedRate**adalah`0`. Ini karena biaya untuk reservasi kapasitas dikaitkan dengan instance yang menyediakan kapasitas, bukan dengan reservasi kapasitas itu sendiri.
#### lineItem/UsageAmount
Berapa banyak reservasi kapasitas yang telah Anda gunakan. Setiap reservasi kapasitas dapat memiliki beberapa slot selama satu jam, memungkinkan Anda menjalankan lebih dari satu instance yang menggunakan reservasi selama satu jam. Oleh karena itu, dimungkinkan untuk menggunakan lebih dari satu instance-hour dalam satu jam. **UsageAmount**dihitung dengan mengalikan jumlah slot instance yang dicakup oleh item baris dengan jumlah jam yang dicakup oleh item baris.
#### lineItem/UsageType
Berapa banyak reservasi tertentu yang telah Anda gunakan. Untuk Amazon EC2, opsinya adalah sebagai berikut:
##### lineItem/lineitemtype = BoxUsage
Untuk ini`UsageType`, `UsageAmount` kolom adalah jumlah instance-hours dari instance yang Anda gunakan.
Misalnya, laporan mencakup 1 jam dan memiliki item baris reservasi kapasitas yang dapat mencakup 10 contoh. Jika Anda menggunakan dua slot instans selama periode waktu yang dicakup oleh laporan, ini **BoxUsage**UsageAmount****mencakup jumlah jam instans yang Anda pesan dan gunakan. Dalam hal ini, ini adalah dua (jumlah slot instance yang digunakan) dikalikan dengan 1 jam (waktu yang dicakup oleh laporan) dengan total dua. Untuk laporan yang mencakup 1 hari, dua **UsageAmount**dikalikan dengan 24, dengan total 48.
##### DedicatedRes
Untuk satu **UsageType**dari **DedicatedRes**, **UsageAmount**kolom menjelaskan berapa jam instans dari reservasi kapasitas khusus yang Anda pesan.
##### Reservasi
Untuk **UsageType****Reservasi**, **UsageAmount**kolom menjelaskan berapa jam instans dari reservasi kapasitas yang Anda pesan.
Misalnya, jika laporan mencakup satu jam dan memiliki item baris reservasi kapasitas yang dapat mencakup 10 instans, **Reservasi **UsageAmount****mencakup jumlah slot instans yang Anda pesan. Dalam hal ini, itu adalah 10 (jumlah slot instance yang tersedia) dikalikan dengan 1 jam (waktu yang dicakup oleh laporan) dengan total 10. Untuk laporan yang mencakup 1 hari, **UsageAmount**akan menjadi 10 dikalikan dengan 24, dengan total 240.
##### UnusedBox
Untuk satu **UsageType**dari **UnusedBox**, **UsageAmount**kolom menjelaskan berapa banyak instance-hours dari reservasi kapasitas yang Anda pesan, tetapi tidak digunakan.
Misalnya, laporan mencakup 1 jam dan memiliki item baris reservasi kapasitas yang dapat mencakup 10 contoh. Jika Anda tidak menggunakan delapan slot instans selama periode waktu yang dicakup oleh laporan, itu **UnusedBox**UsageAmount****mencakup jumlah jam instans yang Anda pesan tetapi tidak digunakan. Dalam hal ini, itu delapan (jumlah slot instance yang tidak digunakan) dikalikan dengan 1 jam (waktu yang dicakup oleh laporan) dengan total delapan. Untuk laporan yang mencakup 1 hari, delapan **UsageAmount**dikalikan dengan 24, dengan total 192.
##### UnusedDed
Untuk satu **UsageType**dari **UnusedDed**, **UsageAmount**kolom menjelaskan berapa jam instans dari reservasi kapasitas khusus yang Anda pesan, tetapi tidak digunakan.
# Memahami biaya transfer data
Anda dapat mengidentifikasi biaya transfer AWS data Anda menggunakan [lineItem/UsageType](Lineitem-columns.md#Lineitem-details-U-UsageType) kolom AWS CUR Anda.
**catatan**
Biaya transfer data dapat bervariasi tergantung pada layanan yang digunakan dan AWS wilayah sumber. Untuk informasi harga terperinci, lihat halaman harga layanan. Misalnya, lihat [Harga Sesuai Permintaan Amazon EC2 untuk informasi harga](https://aws.amazon.com/ec2/pricing/on-demand/) terperinci tentang transfer data Amazon EC2.
## Transfer data dalam suatu AWS Wilayah
Transfer data antara Availability Zone di AWS Wilayah yang sama memiliki **UsageType**file`Region-DataTransfer-Regional-Bytes`. Misalnya, jenis `USE2-DataTransfer-Regional-Bytes` penggunaan mengidentifikasi biaya untuk transfer data antara Availability Zone di Wilayah AS Timur (Ohio).
Untuk sumber daya tertentu, Anda dikenakan biaya untuk lalu lintas masuk dan keluar dalam transfer data dalam Wilayah. AWS Ini berarti untuk setiap sumber daya yang diukur, Anda akan melihat dua item `DataTransfer-Regional-Bytes` baris untuk setiap transfer data. Konfirmasikan halaman harga layanan untuk informasi lebih lanjut, karena beberapa layanan memiliki lalu lintas di wilayah tanpa biaya.
## Transfer data antar AWS Wilayah
Transfer data antar AWS Wilayah yang berbeda dapat memiliki jenis penggunaan berikut:
+ `Source Region-Destination Region-AWS-In-Bytes`: Mengukur transfer data yang masuk KE Wilayah tujuan DARI AWS Wilayah tertentu lainnya.
+ `Source Region-Destination Region-AWS-Out-Bytes`: Mengukur transfer data keluar DARI Wilayah sumber KE AWS Wilayah spesifik lainnya.
+ `Source Region-AWS-In-Bytes`: Jenis penggunaan ini muncul saat lalu lintas mengalir melalui VPC Peering.
+ `Source Region-AWS-Out-Bytes`: Jenis penggunaan ini muncul saat lalu lintas mengalir melalui VPC Peering.
Untuk setiap sumber daya, transfer data antar AWS Wilayah sesuai dengan dua item baris dalam laporan Anda:
+ Item baris untuk data yang ditransfer ke Wilayah tujuan
+ Item baris untuk data yang ditransfer keluar dari Wilayah sumber
Tidak ada biaya untuk data yang ditransfer ke Wilayah tujuan. Biaya transfer data ditentukan oleh data yang ditransfer keluar dari Wilayah sumber.
Misalnya, transfer data dari `USE2` Wilayah ke `APS3` Wilayah akan memiliki item `APS3-USE2-AWS-In-Bytes` baris dan item `USE2-APS3-AWS-Out-Bytes` baris. Item `APS3-USE2-AWS-In-Bytes` baris tidak memiliki biaya yang sesuai. Biaya transfer data dikaitkan dengan item `USE2-APS3-AWS-Out-Bytes` baris.
## Transfer data ke internet
Transfer data dari AWS ke internet memiliki **UsageType**file`Region-DataTransfer-Out-Bytes`. Misalnya, jenis `USE2-DataTransfer-Out-Bytes` penggunaan mengidentifikasi biaya untuk transfer data dari `USE2` Wilayah ke internet.
Tidak ada biaya untuk transfer data dari internet ke AWS.
**catatan**
Jenis penggunaan transfer data yang tidak memiliki awalan Region, seperti `DataTransfer-Regional-Bytes` atau`DataTransfer-Out-Bytes`, mewakili transfer data dari Wilayah AS Timur (Virginia N.).
## Direct Connect lalu lintas
Direct Connect transfer data melalui antarmuka virtual publik memiliki jenis penggunaan yang diakhiri dengan `DataXfer-In` atau`DataXfer-Out`.
Direct Connect transfer data melalui antarmuka virtual pribadi atau transit memiliki jenis penggunaan yang diakhiri dengan `DataXfer-In:dc.3` atau`DataXfer-Out:dc.3`.
## Lalu lintas Akselerasi Transfer S3
Transfer data Amazon S3 menggunakan S3 Transfer Acceleration memiliki tipe penggunaan yang berisi: `ABytes`
+ Antara Amazon S3 dan Amazon EC2: Jenis penggunaan yang diakhiri dengan atau `C3DataTransfer-In-ABytes` `C3DataTransfer-Out-ABytes`
+ Antara Amazon S3 dan internet: Jenis penggunaan yang diakhiri dengan atau `DataTransfer-In-ABytes` `DataTransfer-Out-ABytes`
+ Antara Amazon S3 dan CloudFront: Jenis penggunaan yang diakhiri dengan atau `CloudFront-In-ABytes` `CloudFront-Out-ABytes`
+ Antara ember Amazon S3 di AWS Wilayah yang berbeda: Jenis penggunaan `Source Region-Destination Region-AWS-Out-ABytes`
## CloudFront lalu lintas
CloudFront transfer data memiliki jenis penggunaan `Region-DataTransfer-Out-Bytes` atau `Region-DataTransfer-Out-OBytes` digabungkan dengan kode `AmazonCloudFront` produk. Awalan Region dalam tipe penggunaan mengacu pada lokasi CloudFront Edge yang digunakan dalam transfer data. Misalnya, jenis `AP-DataTransfer-Out-Bytes` penggunaan mengidentifikasi biaya untuk transfer data dari Wilayah AP ke internet.
**Tip**
Gunakan [lineItem/ProductCode](Lineitem-columns.md#Lineitem-details-P-ProductCode) kolom untuk membedakan transfer CloudFront data dari transfer data ke internet. Jenis penggunaan untuk tipe transfer data ini terlihat serupa.
# Memahami data alokasi biaya terpisah
Anda dapat menggunakan Laporan Biaya dan Penggunaan (AWS CUR) untuk melacak biaya penampung Amazon ECS dan Amazon EKS Anda. Dengan menggunakan data alokasi biaya terpisah, Anda dapat mengalokasikan biaya kontainer ke unit dan tim bisnis individual, berdasarkan cara beban kerja kontainer menggunakan sumber daya komputasi dan memori bersama. Data alokasi biaya terpisah memperkenalkan data biaya dan penggunaan untuk sumber daya tingkat kontainer baru (yaitu, tugas ECS dan pod Kubernetes) ke CUR. AWS Sebelumnya, AWS CUR hanya mendukung biaya di tingkat instans EC2. Data alokasi biaya terpisah menghasilkan biaya tingkat kontainer dengan melihat konsumsi sumber daya instans EC2 setiap kontainer, dan menghasilkan biaya berdasarkan biaya amortisasi instance dan persentase CPU dan sumber daya memori yang dikonsumsi oleh kontainer yang berjalan pada instance.
Untuk instans komputasi yang dipercepat yang digunakan dengan Amazon EKS, data alokasi biaya terpisah mencakup alokasi sumber daya untuk prosesor khusus bersama CPU dan memori. Ini mencakup akselerator NVIDIA dan AMD GPUs, AWS Trainium, dan AWS Inferentia. Fitur ini hanya tersedia untuk lingkungan Amazon EKS dan menyediakan data reservasi sumber daya tingkat pod untuk sumber daya komputasi yang dipercepat ini. Hal ini memungkinkan Anda untuk melacak dan mengalokasikan biaya untuk beban kerja yang menggunakan prosesor khusus ini, seperti aplikasi AI/ML dan tugas-tugas komputasi intensif lainnya. Untuk daftar instans komputasi yang dipercepat saat ini, lihat [Komputasi Akselerasi](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing).
Data alokasi biaya terpisah memperkenalkan catatan penggunaan baru dan kolom metrik biaya baru untuk setiap ID sumber daya kontainer (yaitu, tugas ECS dan pod Kubernetes) di CUR. AWS Untuk informasi selengkapnya, lihat [Membagi detail item baris](https://docs.aws.amazon.com/cur/latest/userguide/split-line-item-columns.html).
Saat memasukkan data alokasi biaya terpisah di AWS CUR, dua catatan penggunaan baru ditambahkan untuk setiap tugas ECS dan pod Kubernetes per jam untuk mencerminkan biaya CPU dan memori. Untuk memperkirakan jumlah item baris baru di AWS CUR per hari, gunakan rumus berikut:
Untuk ECS: `(number of tasks * average task lifetime * 2) * 24`
Untuk EKS: `(number of pods * average pod lifetime * 2) * 24`
Misalnya, jika Anda memiliki 1.000 pod yang berjalan setiap jam di sebuah cluster yang terdiri dari 10 instans EC2 dan masa pakai pod kurang dari 1 jam, maka:
`(1000 * 1 * 2) * 24 = 48,000 new usage records in AWS CUR`
Untuk instans komputasi yang dipercepat di Amazon EKS, tiga catatan penggunaan baru ditambahkan untuk setiap pod Kubernetes per jam untuk mencerminkan biaya akselerator, CPU, dan memori. Untuk memperkirakan jumlah item baris baru di AWS CUR per hari, gunakan rumus berikut:
Untuk EKS dengan komputasi yang dipercepat: `(number of pods * average pod lifetime * 3) * 24`
Misalnya, jika Anda memiliki 1.000 pod yang berjalan setiap jam di sebuah cluster yang terdiri dari 10 instans EC2 dan masa pakai untuk setiap pod kurang dari satu jam, maka: `(1000 * 1 * 3) * 24 = 72,000 new usage records in AWS CUR`
**catatan**
Untuk ECS: Dalam hal tag alokasi AWS biaya, Anda dapat menggunakan tag yang dikelola Amazon ECS atau tag yang ditambahkan pengguna untuk Laporan Biaya dan Penggunaan Anda. Tag ini berlaku untuk semua catatan penggunaan data alokasi biaya terpisah ECS baru. Untuk informasi selengkapnya, lihat [Menandai sumber daya ECS Anda untuk](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html#tag-resources-for-billing) penagihan.
Untuk EKS: Data alokasi biaya terpisah membuat tag alokasi biaya baru untuk beberapa atribut Kubernetes. Tag ini termasuk`aws:eks:cluster-name`,`aws:eks:deployment`,`aws:eks:namespace`,`aws:eks:node`,`aws:eks:workload-name`, dan`aws:eks:workload-type`.
`aws:eks:cluster-name`,`aws:eks:namespace`, dan diisi `aws:eks:node` secara retrospektif dengan nama cluster, namespace, dan node.
`aws:eks:workload-type`hanya diisi jika ada tepat satu beban kerja yang mengelola pod, dan merupakan salah satu beban kerja bawaan. Jenis beban kerja meliputi`ReplicaSet`,`StatefulSet`,`Job`,`DaemonSet`, atau`ReplicationController`, dan `aws:eks:workload-name` termasuk nama beban kerja. Untuk informasi selengkapnya, lihat [Beban Kerja di Dokumentasi](https://kubernetes.io/docs/concepts/workloads/) *Kubernetes*.
`aws:eks:deployment`hanya diisi untuk jenis beban kerja. `ReplicaSet` Ini adalah penerapan yang menciptakan. `ReplicaSet`
Tag ini berlaku untuk semua catatan penggunaan data alokasi biaya terpisah EKS baru. Tag ini diaktifkan untuk alokasi biaya secara default. Jika sebelumnya Anda menggunakan dan menonaktifkan `aws:eks:cluster-name` tag, data alokasi biaya terpisah akan menyimpan pengaturan ini dan tidak mengaktifkan tag. Anda dapat mengaktifkannya dari halaman konsol [tag alokasi biaya](https://console.aws.amazon.com/billing/home#/tags).
# Mengaktifkan data alokasi biaya terpisah
**catatan**
Data alokasi biaya terpisah tidak tersedia di Cost Explorer. Ini tersedia dalam Laporan Biaya dan Penggunaan lama (CUR) dan Laporan Biaya dan Penggunaan 2.0 (CUR 2.0) dengan Ekspor Data.
Merupakan prasyarat untuk memilih untuk membagi data alokasi biaya melalui preferensi Manajemen Biaya.
**Untuk memilih untuk membagi data alokasi biaya**
1. Buka Konsol Manajemen Penagihan dan Biaya di [https://console.aws.amazon.com/costmanagement/](https://console.aws.amazon.com/costmanagement/).
1. Di panel navigasi, pilih **preferensi Manajemen Biaya**.
1. Di bawah **Umum**, di bagian **Data alokasi biaya terpisah**, pilih antara yang berikut ini:
+ **Amazon Elastic Container Service (Amazon ECS**) untuk ikut serta dalam Amazon ECS saja.
+ **Amazon Elastic Kubernetes Service (Amazon EKS) untuk ikut serta di Amazon** EKS saja. Untuk Amazon EKS, pilih antara yang berikut ini:
+ **Permintaan sumber daya**: Ini mengalokasikan Amazon EC2 Anda hanya dengan CPU pod Kubernetes dan sumber daya memori. Ini akan mendorong tim aplikasi untuk hanya menyediakan apa yang mereka butuhkan.
+ **Layanan Terkelola Amazon untuk Prometheus**: Ini mengalokasikan biaya Amazon EC2 Anda dengan lebih tinggi dari permintaan CPU dan sumber daya memori Kubernetes pod dan pemanfaatan aktual yang lebih tinggi. Ini memastikan setiap tim aplikasi membayar untuk apa yang mereka gunakan. Untuk mempelajari selengkapnya tentang menyiapkan Layanan Terkelola Amazon untuk Prometheus, lihat [Menyiapkan](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-setting-up.html) di panduan pengguna *Layanan Terkelola Amazon* untuk Prometheus.
Prasyarat: Anda harus mengaktifkan semua fitur di. AWS Organizations Untuk mempelajari lebih lanjut, lihat [Mengaktifkan semua fitur di organisasi Anda](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html) di *panduan pengguna Organizations*.
+ **Amazon CloudWatch Container Insights**: Ini memberikan visibilitas biaya yang lebih terperinci untuk klaster Anda yang menjalankan beberapa wadah aplikasi menggunakan instans EC2 bersama, memungkinkan alokasi biaya yang lebih baik untuk biaya bersama kluster EKS Anda.
**catatan**
Hanya akun reguler dan pembayar yang memiliki akses ke AWS Cost Management preferensi dan dapat memilih untuk membagi data alokasi biaya. Setelah memilih, akun anggota dapat melihat data dalam Laporan Biaya dan Penggunaan.
Jika Anda memilih permintaan sumber daya, hanya pod yang dikonfigurasi dengan memori dan permintaan CPU yang digunakan oleh data alokasi biaya terpisah. Pod yang belum meminta penggunaan apa pun tidak akan melihat data biaya terpisah.
Jika memilih Amazon Managed Service for Prometheus, Anda harus mengaktifkan semua fitur di Organizations. AWS Untuk informasi selengkapnya, lihat [Mengaktifkan semua fitur di organisasi Anda](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html). Selain itu, data alokasi biaya terpisah menciptakan peran terkait layanan baru, yang memungkinkan akses ke AWS layanan dan sumber daya yang digunakan atau dikelola oleh data alokasi biaya terpisah.
Untuk instans komputasi yang dipercepat, hanya opsi permintaan Sumber Daya yang didukung. Baik Amazon Managed Service untuk Prometheus maupun CloudWatch Amazon Container Insights tidak didukung untuk instans ini. Saat menggunakan instans komputasi yang dipercepat, sistem akan default ke permintaan Sumber Daya untuk menghitung biaya akselerator, CPU, dan memori, bahkan jika opsi pengukuran lainnya diaktifkan.
Setelah memilih, Anda dapat memilih untuk memiliki data biaya dan penggunaan untuk sumber daya tingkat kontainer yang disertakan dalam laporan selama langkah pertama pembuatan laporan atau yang lebih baru dengan mengedit detail laporan.
**Untuk memasukkan data biaya dan penggunaan dalam laporan Anda**
1. Buka Konsol Manajemen Penagihan dan Biaya di [https://console.aws.amazon.com/costmanagement/](https://console.aws.amazon.com/costmanagement/).
1. Di panel navigasi, di bawah **Halaman Legacy**, pilih Laporan **Biaya dan Penggunaan**.
1. Baik membuat laporan baru atau mengedit laporan yang ada, di halaman **Tentukan detail laporan**, di bawah **Laporkan konten**, pilih **Pisahkan data alokasi biaya**.
**catatan**
Anda juga dapat menggunakan AWS CUR API atau AWS Command Line Interface (CLI) untuk mengelola preferensi data alokasi biaya terpisah Anda.
Data alokasi biaya terpisah memungkinkan visibilitas biaya untuk semua objek penampung Amazon ECS dan Amazon EKS di seluruh keluarga penagihan gabungan Anda (akun pembayar dan tertaut). Setelah diaktifkan, data alokasi biaya terpisah secara otomatis memindai tugas dan kontainer. Ini menyerap data penggunaan telemetri untuk beban kerja kontainer Anda dan menyiapkan data biaya granular untuk bulan berjalan.
**catatan**
Diperlukan waktu hingga 24 jam agar data dapat terlihat di AWS CUR.
Untuk informasi tentang mengelola akses ke halaman konsol Billing and Cost Management, [lihat Ringkasan mengelola izin akses](https://docs.aws.amazon.com/cost-management/latest/userguide/control-access-billing.html).
Untuk informasi mengenai AWS Cost Management preferensi dan mengontrol akses ke Cost Explorer, lihat [Mengontrol akses ke Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-access.html).
# Contoh data alokasi biaya terpisah
Tujuan dari contoh berikut ini adalah untuk menunjukkan kepada Anda bagaimana data alokasi biaya split dihitung dengan menghitung biaya layanan Amazon ECS individual, tugas di cluster Amazon ECS, dan namespace Kubernetes dan pod di cluster Amazon EKS. Tarif yang digunakan di seluruh contoh hanya untuk tujuan ilustrasi.
**catatan**
Contoh ini menunjukkan namespace Kubernetes dan pod yang berjalan di klaster Amazon EKS. Kami kemudian dapat menerapkan model biaya yang sama ke layanan Amazon ECS dan tugas yang berjalan di cluster Amazon ECS.
Anda memiliki penggunaan berikut dalam satu jam:
+ Instance tunggal (m5.xlarge) berbagi cluster dengan dua namespace dan empat pod, berjalan selama satu jam penuh.
+ Konfigurasi instans adalah 4 vCPU dan 16 GB memori.
+ Biaya amortisasi dari instans adalah \$11/jam.
Data alokasi biaya terpisah menggunakan bobot unit relatif untuk CPU dan memori berdasarkan rasio 9:1. Ini berasal dari per vCPU per jam dan per GB per jam harga di. [AWS Fargate](https://aws.amazon.com/fargate/pricing/)
## Langkah 1: Hitung biaya unit untuk CPU dan memori
`Unit-cost-per-resource = Hourly-instance-cost/((Memory-weight * Memory-available) + (CPU-weight * CPU-available))`
= \$11/ ((1 \$1 16GB) \$1 (9 \$1 4vCPU)) = \$10,02
`Cost-per-vCPU-hour = CPU-weight * Unit-cost-per-resource`
= 9 \$1 \$10,02 = \$10,17
`Cost-per-GB-hour = Memory-weight * Unit-cost-per-resource`
= 1 \$1 \$10,02 = \$10,02
****
| Instance | Instance type | vCPU-available | Memory-available | Amortized-cost-per-hour | Cost-per-vCPU-hour | Cost-per-GB-hour |
| --- | --- | --- | --- | --- | --- | --- |
| Instance1 | m5.xlarge | 4 | 16 | \$11 | \$10,17 | \$10,02 |
## Langkah 2: Hitung kapasitas yang dialokasikan dan misalnya kapasitas yang tidak digunakan
+ Kapasitas yang dialokasikan: Memori dan vCPU yang dialokasikan ke pod Kubernetes dari instans EC2 induk, didefinisikan sebagai kapasitas maksimum yang digunakan dan yang dicadangkan.
**catatan**
Jika data penggunaan memori atau vCPU tidak tersedia, data reservasi akan digunakan sebagai gantinya. Untuk informasi selengkapnya, lihat [laporan penggunaan Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/usage-reports.html), atau [pemantauan biaya Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/cost-monitoring.html).
+ Kapasitas instans yang tidak digunakan: Kapasitas vCPU dan memori yang tidak terpakai.
`Pod1-Allocated-vCPU = Max (1 vCPU, 0.1 vCPU)`= 1 vCPU
`Pod1-Allocated-memory = Max (4 GB, 3 GB)`= 4 GB
`Instance-Unused-vCPU = Max (CPU-available - SUM(Allocated-vCPU), 0)`= Maks (4 — 4,9, 0) = 0
`Instance-Unused-memory = Max (Memory-available - SUM(Allocated-memory), 0)`= Maks (16 - 14, 0) = 2 GB
Dalam contoh ini, instance memiliki CPU over subscription, dikaitkan dengan Pod2 yang menggunakan lebih banyak vCPU daripada yang dicadangkan.
****
| Pod name | Namespace | Reserved-vCPU | Used-vCPU | Allocated-vCPU | Reserved-memory | Used-memory | Allocated-memory |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Pod1 | Namespace1 | 1 | 0,1 | 1 | 4 | 3 | 4 |
| Pod2 | Namespace2 | 1 | 1.9 | 1.9 | 4 | 6 | 6 |
| Pod3 | Namespace1 | 1 | 0,5 | 1 | 2 | 2 | 2 |
| Pod4 | Namespace2 | 1 | 0,5 | 1 | 2 | 2 | 2 |
| Unused | Unused | | | 0 | | | 2 |
| | | | | 4.9 | | | 16 |
## Langkah 3: Hitung rasio penggunaan terpisah
+ Rasio penggunaan terpisah: Persentase CPU atau memori yang digunakan oleh pod Kubernetes dibandingkan dengan keseluruhan CPU atau memori yang tersedia pada instans EC2.
+ Rasio yang tidak terpakai: Persentase CPU atau memori yang digunakan oleh pod Kubernetes dibandingkan dengan keseluruhan CPU atau memori yang digunakan pada instans EC2 (yaitu, tidak memperhitungkan CPU atau memori yang tidak terpakai pada instance).
`Pod1-vCPU-split-usage-ratio = Allocated-vCPU / Total-vCPU`
= 1 vCPU/ 4.9vCPU = 0.204
`Pod1-Memory-split-usage-ratio = Allocated-GB / Total-GB`
= 4 GB/ 16GB = 0.250
`Pod1-vCPU-unused-ratio = Pod1-vCPU-split-usage-ratio / (Total-CPU-split-usage-ratio – Instance-unused-CPU)`(diatur ke 0 Instance-unused-CPU jika 0)
= 0 ( Instance-unused-CPUkarena 0)
`Pod1-Memory-unused-ratio = Pod1-Memory-split-usage-ratio / (Total-Memory-split-usage-ratio – Instance-unused-memory)`(diatur ke 0 Instance-unused-memory jika 0)
= 0,250/(1-0,125) = 0,286
****
| Pod name | Namespace | vCPU-split-usage-ratio | vCPU-unused-ratio | Memory-split-usage-ratio | Memory-unused-ratio |
| --- | --- | --- | --- | --- | --- |
| Pod1 | Namespace1 | 0,204 | 0 | 0,250 | 0,286 |
| Pod2 | Namespace2 | 0,388 | 0 | 0,375 | 0.429 |
| Pod3 | Namespace1 | 0,204 | 0 | 0,125 | 0,143 |
| Pod4 | Namespace2 | 0,204 | 0 | 0,125 | 0,143 |
| Unused | Unused | 0 | | 0,125 | |
| | | 1 | | 1 | |
## Langkah 4: Hitung biaya split dan biaya yang tidak terpakai
+ Biaya split: Alokasi biaya bayar per penggunaan dari biaya instans EC2 berdasarkan alokasi CPU dan penggunaan memori oleh pod Kubernetes.
+ Biaya instans yang tidak digunakan: Biaya CPU atau sumber daya memori yang tidak digunakan pada instance.
`Pod1-Split-cost = (Pod1-vCPU-split-usage-ratio * vCPU-available * Cost-per-vCPU-hour) + (Pod1-Memory-split-usage-ratio * Memory-available * Cost-per-GB-hour)`
= (0,204 \$1 4 vCPU \$1 \$10,17) \$1 (0,25 \$1 16GB \$1 \$10,02) = \$10,22
`Pod1-Unused-cost = (Pod1-vCPU-unused-ratio * Instance-vCPU-unused-ratio * vCPU-available * Cost-per-VCPU-hour) + (Pod1-Memory-unused-ratio * Instance-Memory-unused ratio * Memory-available * Cost-per-GB-hour)`
= (0 \$1 0 \$1 4 \$1 \$10,17) \$1 (0,286 \$1 0,125 \$1 16 \$1 \$10,02) = \$10,01
`Pod1-Total-split-cost = Pod1-Split-cost + Pod1-Unused-cost`
= \$10,23
****
| Pod name | Namespace | Split-cost | Unused-cost | Total-split-cost |
| --- | --- | --- | --- | --- |
| Pod1 | Namespace1 | \$10,22 | \$10,01 | \$10,23 |
| Pod2 | Namespace2 | \$10,38 | \$10,02 | \$10,40 |
| Pod3 | Namespace1 | \$10,18 | \$10,01 | \$10,19 |
| Pod4 | Namespace2 | \$10,18 | \$10,01 | \$10,19 |
| Unused | Unused | \$10,04 | | |
| | | \$11 | \$10,04 | \$11 |
Biaya layanan adalah jumlah biaya pod yang terkait dengan setiap namespace.
Total biaya Namespace1 = \$10,23 \$1 \$10,19 = \$10,42
Total biaya Namespace2 = \$10,40 \$1\$10,19 = \$10,59
## Contoh AWS CUR
Jika Anda memiliki Savings Plans yang mencakup seluruh penggunaan instans EC2 dalam periode penagihan, biaya diamortisasi dihitung menggunakan. savingsPlan/SavingsPlanEffectiveCost
![\[Table showing EC2 instance usage details with Savings Plans and cost breakdown.\]](http://docs.aws.amazon.com/id_id/cur/latest/userguide/images/savings-plan-entire-usage.png)
Jika Anda memiliki Savings Plans yang mencakup penggunaan sebagian untuk instans EC2 dalam periode penagihan dan sisa penggunaan instans EC2 ditagih dengan tarif Sesuai Permintaan, biaya amortisasi instans EC2 dihitung menggunakan savingsPlan/SavingsPlanEffectiveCost (untuk) \$1 (untuk penggunaan Sesuai Permintaan). SavingsPlanCoveredUsage lineItem/UnblendedCost
![\[Table showing EC2 instance usage details, costs, and savings plan information.\]](http://docs.aws.amazon.com/id_id/cur/latest/userguide/images/savings-plan-partial-usage.png)
# Contoh data alokasi biaya terpisah untuk instans yang dipercepat
Tujuan dari contoh berikut adalah untuk menunjukkan kepada Anda bagaimana data alokasi biaya split dihitung dengan menghitung biaya namespace Kubernetes dan pod di klaster Amazon EKS. Tarif yang digunakan di seluruh contoh hanya untuk tujuan ilustrasi.
Anda memiliki penggunaan berikut dalam satu jam:
+ Instance EC2 tunggal yang menjalankan empat pod di dua namespace, dan Anda ingin memahami biaya setiap namespace.
+ Instans EC2 adalah p3.16xlarge dengan 8 GPU, 64 vCPU, dan 488 GB RAM.
+ Biaya amortisasi dari instans adalah \$110/jam.
Data alokasi biaya terpisah menormalkan biaya per sumber daya berdasarkan rasio relatif GPU: (cpu: memori) 9:1. Ini menyiratkan bahwa satu unit GPU berharga 9x sebanyak unit CPU dan memori. CPU dan memori kemudian diberi berat 9:1. Untuk instance EC2 yang tidak dipercepat, perilaku default saat ini akan diadopsi yaitu cpu: bobot memori default ke 9:1.
## Langkah 1: Hitung biaya unit
Berdasarkan sumber daya cpu dan memori pada instans EC2 dan menggunakan rasio yang disebutkan di atas, data Alokasi Biaya Split pertama-tama menghitung biaya unit per GPU, VCPU-HR dan GB-HR.
`GPU-Weight =9`
`GPU+Memory-Weight =1`
`CPU-Weight=1*.9=.9`
`Memory-Weight=1*0.1=0.1`
`Hourly-Instance-Cost=$10`
`GPU-Available=8`
`Memory-Available=488`
`CPU-Available=64`
`UnitCostPerResource = Hourly-Instance-Cost/(( GPU-Weight * GPU-Available) + (Memory-Weight * Memory-Available) + (CPU-Weight * CPU-Available)) = $10/((9*8gpu)+ (0.1 * 488GB) + (.9 * 64vcpu)) = $0.056`
`Cost-per-GPU-Hour = GPU-Weight * UnitCostPerResource = 9 * $0.056 = $0.504`
`Cost-per-vcpu-Hour = CPU-Weight * UnitCostPerResource = .9 * $0.056 = $0.05`
`Cost-per-GB-Hour = Memory-Weight * UnitCostPerResource = .1 * $0.056 = $0.00506`
**Tabel 1: Perhitungan biaya unit**
| Instans | Tipe Instans | vCPU Tersedia | GPU Tersedia | \$1\$1 | Memori Tersedia | Biaya Amortisasi per Jam | Biaya per VCPU-jam | Biaya per GPU-jam | Biaya per GB-jam |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Instans 1 | p3.16xlarge | 64 | 8 | | 488 | \$110 | \$10,05 | \$10,50 | 0,005 |
## Langkah 2: Hitung kapasitas yang dialokasikan dan tidak terpakai
Kapasitas yang Dialokasikan
GPU, vcpu, dan Memori yang dialokasikan ke Pod Kubernetes dari Instance EC2 induk, yang didefinisikan sebagai kapasitas Maksimum (reserved, used)
Contoh Kapasitas yang Tidak Digunakan
Kapasitas GPU, vcpu, dan Memori yang tidak terpakai
`Pod1-Allocated-GPU = Max (1 GPU, 1 GPU) = 1 GPU`
`Pod1-Allocated-vcpu = Max (16 vcpu, 4 vcpu) = 16 vcpu`
`Pod1-Allocated-Memory = Max (100 GB, 60 GB) = 100 GB`
`Instance-Unused-GPU = Max (GPU-Available - SUM(Allocated-vcpu), 0)`
`= Max (8 – 8, 0) = 0`
`Instance-Unused-vcpu = Max (CPU-Available - SUM(Allocated-vcpu), 0)`
`= Max (16 – 18, 0) = 0`
`Instance-Unused-Memory = Max (Memory-Available - SUM(Allocated-Memory), 0)`
`= Max (488 – 440, 0) = 48 GB`
Dalam contoh ini, instance memiliki CPU over subscription, dikaitkan dengan Pod 2 yang menggunakan lebih banyak GPU dan vcpu daripada yang dicadangkan.
**Tabel 2: Hitung Kapasitas yang Dialokasikan dan Tidak Digunakan**
| Nama Pod | Namespace | vcpu Dilindungi | vcpu Digunakan | vcpu Dialokasikan | GPU Dilindungi | GPU digunakan | GPU Dialokasikan | Memori Cadangan | Memori yang Digunakan | Memori Dialokasikan |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Pod 1 | Ruang nama 1 | 16 | 4 | 16 | 1 | 1 | 1 | 100 | 60 | 100 |
| Pod 2 | Ruang nama 2 | 16 | 18 | 18 | 2 | 3 | 3 | 100 | 140 | 140 |
| Pod 3 | Ruang nama 1 | 16 | 4 | 16 | 2 | 1 | 2 | 100 | 60 | 100 |
| Pod 4 | Ruang nama 2 | 16 | 4 | 16 | 2 | 2 | 2 | 100 | 40 | 100 |
| Tidak terpakai | Tidak terpakai | 0 | 34 | 0 | 1 | 1 | 0 | 88 | 188 | 48 |
| \$1\$1\$1 | | 64 | 32 | 66 | 8 | 8 | 8 | 488 | 488 | 488 |
## Langkah 3: Hitung rasio penggunaan dan pemanfaatan terpisah
Rasio penggunaan split
Persentase CPU atau memori yang digunakan oleh pod Kubernetes dibandingkan dengan keseluruhan CPU atau memori yang tersedia pada instans EC2.
Rasio yang tidak digunakan
Persentase CPU atau memori yang digunakan oleh pod Kubernetes dibandingkan dengan keseluruhan CPU atau memori yang digunakan pada instans EC2 (yaitu, tidak memperhitungkan CPU atau memori yang tidak terpakai pada instance).
Persentase CPU atau memori yang digunakan oleh Kubernetes Pod dibandingkan dengan keseluruhan CPU atau memori yang tersedia pada Instance EC2.
`Pod1-GPU-Utilization-Ratio = Allocated-GPU / Total-GPU`
`= 1 gpu / 8 gpu = 0.125`
`Pod1-vcpu-Utilization-Ratio = Allocated-vcpu / Total-vcpu`
`= 16 vcpu / 66 vcpu = 0.24`
`Pod1-Memory-Utilization-Ratio = Allocated-GB / Total-GB`
`= 100 GB/ 488GB = 0.205`
`Pod1-GPU-Split-Ratio = Pod1-GPU-Utilization-Ratio / (Total-GPU-Utilization-Ratio – Instance-Unused-GPU). Set to 0 if Instance-Unused-GPU = 0`
`= 0 since Instance-Unused-GPU is 0`
`Pod1-vcpu-Split-Ratio = Pod1-CPU-Utilization-Ratio / (Total-CPU-Utilization-Ratio – Instance-Unused-CPU). Set to 0 if Instance-Unused-CPU = 0`
`= 0 since Instance-Unused-CPU is 0`
`Pod1-Memory-Split-Ratio = Pod-Memory-Utilization-Ratio / (Total-Utilization-Ratio – Instance-Unused-Memory). Set to 0 if Instance-Unused-Memory = 0`
`= 0.204/ (1-0.102) = 0.227`
**Tabel 3: Rasio Pemanfaatan Komputasi**
| Nama Pod | Namespace | Pemanfaatan vcpu | Rasio Pemisahan vcpu | Pemanfaatan GPU | Rasio Pemisahan GPU | Pemanfaatan Memori | Rasio Pemisahan Memori |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Pod 1 | Ruang nama 1 | 0,242 | 0 | 0,125 | 0 | 0.205 | 0,227 |
| Pod 2 | Ruang nama 2 | 0,267 | 0 | 0,375 | 0 | 0,287 | 0.318 |
| Pod 3 | Ruang nama 1 | 0,242 | 0 | 0,25 | 0 | 0.205 | 0,227 |
| Pod 4 | Ruang nama 2 | 0,242 | 0 | 0,25 | 0 | 0.205 | 0,227 |
| Tidak terpakai | Tidak terpakai | 0 | | | | 0,098 | |
| | | 1 | 0 | 1 | 0 | 1 | 1 |
## Langkah 4: Hitung biaya split dan biaya yang tidak terpakai
Biaya Split
Alokasi biaya bayar per penggunaan biaya Instans EC2 berdasarkan alokasi CPU dan penggunaan memori oleh Kubernetes Pods
Biaya Instans yang Tidak Digunakan
Biaya CPU atau sumber daya memori yang tidak digunakan pada instance
`Pod1-Split-Cost = (Pod1-GPU-Utilization-Ratio * GPU-Available * Cost per GPU-Hour) + (Pod1-vcpu-Utilization-Ratio * vcpu-Available * Cost per vcpu-Hour) + (Pod1-Memory-Utilization-Ratio * Memory-Available * Cost per GB-Hour)`
`= (.125*8gpu*$0.504) + (0.242 * 64 vcpu * $0.05) + (0.204 * 488GB * $0.00506) = 0.504+ 0.774 + 0.503 = $1.85`
`Pod1-Unused-Cost = (GPU-Split-Ratio * Unused-Cost) + (vcpu-Split-Ratio * Unused-Cost) + (Memory-Split-Ratio * Unused-Cost)`
`= (0*0*8*$0.504) + (0 * $0.05) + (0.227 *.102*488GB*$.00506) = $0.06`
`Pod1-Total-Split-Cost = Pod1-Split-Cost + Pod1-Unused-Cost = $1.85 + $0.06 = $1.91`
[Catatan: Biaya yang tidak digunakan = Rasio util yang tidak digunakan \$1 Total sumber daya \$1 biaya per jam sumber daya]
**Tabel 4 - Ringkasan biaya Split dan Unused yang dihitung setiap jam untuk semua Pod yang berjalan di dalam klaster**
| Nama Pod | Namespace | Biaya Split | Biaya yang tidak terpakai | Total Biaya |
| --- | --- | --- | --- | --- |
| Pod 1 | Ruang nama 1 | \$11,85 | \$10,06 | \$11.91 |
| Pod 2 | Ruang nama 2 | \$13,18 | \$10,09 | \$13,26 |
| Pod 3 | Ruang nama 1 | \$12,35 | \$10,06 | \$12,41 |
| Pod 4 | Ruang nama 2 | \$12,35 | \$10,06 | \$12,41 |
| Total | | | | \$110 |
# Menggunakan label Kubernetes untuk alokasi biaya di EKS
Data alokasi biaya terpisah mendukung label Kubernetes sebagai tag alokasi biaya untuk klaster Amazon EKS. Meskipun label ini secara otomatis diimpor sebagai tag alokasi biaya yang ditentukan pengguna, label tersebut memerlukan aktivasi di tingkat akun manajemen. Setelah diaktifkan, Anda dapat menggunakannya untuk mengatribusikan biaya tingkat pod dalam Laporan Biaya dan Penggunaan (CUR) Anda menggunakan atribut khusus seperti pusat biaya, aplikasi, unit bisnis, dan lingkungan.
Fitur ini membantu organisasi melacak dan mengalokasikan biaya secara akurat di lingkungan EKS bersama di seluruh tim, proyek, atau departemen. Dengan menggunakan label Kubernetes, Anda dapat mengalokasikan biaya Kubernetes berdasarkan kebutuhan bisnis dan desain organisasi spesifik Anda.
## Prasyarat
Sebagai prasyarat untuk menggunakan label Kubernetes dengan data alokasi biaya terpisah:
+ Anda perlu mengaktifkan data alokasi biaya terpisah di konsol AWS Billing and Cost Management. Ini harus diaktifkan di tingkat akun manajemen. Untuk detailnya, lihat [Mengaktifkan data alokasi biaya terpisah](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html).
+ Anda memerlukan kluster EKS yang ingin Anda lacak data alokasi biaya terpisah. Ini bisa berupa cluster yang sudah ada, atau Anda dapat membuat yang baru. Untuk informasi selengkapnya, lihat [Membuat klaster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) di *Panduan Pengguna Amazon EKS*.
+ Anda harus memiliki label yang ditetapkan ke pod Anda di klaster EKS. *Untuk informasi selengkapnya tentang cara membuat label di Kubernetes, lihat [Label dan Selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) di Dokumentasi Kubernetes.*
## Bekerja dengan label Kubernetes di EKS
Data alokasi biaya terpisah mendukung hingga 50 label Kubernetes per pod, yang diurutkan berdasarkan abjad sebelum diimpor sebagai tag alokasi biaya. Setiap label di luar 50 pertama secara otomatis dibuang. Jika Anda perlu menambahkan tag alokasi biaya baru setelah mencapai batas 50 label, Anda harus terlebih dahulu menghapus label yang ada dan memastikan label baru Anda masuk dalam 50 pertama saat diurutkan menurut abjad.
**catatan**
Beberapa layanan AWS terkelola secara otomatis menambahkan label ke pod EKS. Label ini dihitung terhadap batas 50 label per pod dan akan muncul di halaman tag alokasi biaya Anda.
Meskipun label Kubernetes tidak memiliki batasan ukuran, tag alokasi biaya memiliki batas karakter tertentu: 128 karakter untuk kunci tag dan 256 karakter untuk nilai tag. Label yang melebihi batas karakter ini akan dibuang dan tidak disajikan sebagai tag alokasi biaya. Disarankan untuk membuat label yang mengikuti batas karakter ini untuk tujuan alokasi biaya.
Label Kubernetes yang diimpor muncul sebagai tag alokasi biaya dan harus diaktifkan di tingkat akun pembayar. Untuk informasi selengkapnya tentang tag alokasi biaya dan aktivasi, lihat [Menggunakan tag alokasi biaya yang ditentukan pengguna](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html). Batas tag alokasi biaya berikut berlaku: 50 tag yang ditentukan pengguna per sumber daya dan 500 tag yang ditentukan pengguna per akun pembayar. Tag yang dihasilkan sistem tidak dihitung terhadap batas-batas ini.
**catatan**
Setelah Anda membuat dan menerapkan tag yang ditentukan pengguna ke sumber daya Anda, diperlukan waktu hingga 24 jam agar kunci tag muncul di halaman tag alokasi biaya Anda. Setelah Anda mengaktifkan tag, dibutuhkan waktu 24 jam tambahan agar mereka aktif.
## Mengelola label Kubernetes dan tag alokasi biaya
Anda dapat menambahkan, menghapus, dan mengedit label Kubernetes di EKS, serta menonaktifkan tag alokasi biaya terkait. Berikut ini menjelaskan perilaku yang diharapkan untuk setiap tindakan.
**Menambahkan label baru**
Anda dapat menambahkan label Kubernetes baru ke pod. Jika batas label 50 belum tercapai, label baru akan diimpor dan ditawarkan sebagai tag alokasi biaya, yang kemudian dapat diaktifkan. Namun, jika batas 50 telah tercapai, label baru tidak akan diimpor bahkan jika itu termasuk dalam urutan alfabet dari 50 label pertama. Anda harus terlebih dahulu menonaktifkan tag alokasi biaya yang ada untuk mengimpor label baru.
**Mengedit label**
Kubernetes tidak mengizinkan Anda untuk mengedit kunci label. Untuk mengubah kunci label, Anda harus menghapusnya dan menambahkan label baru. Namun, Anda dapat mengedit nilai label, yang akan tercermin dalam CUR berikutnya.
**Menghapus label**
Anda dapat menghapus label dari pod EKS. Perhatikan bahwa menghapus label tidak secara otomatis menonaktifkan tag alokasi biaya terkait. Data alokasi biaya terpisah akan terus terisi di CUR hingga Anda secara eksplisit menonaktifkan tag alokasi biaya.
**Menonaktifkan tag alokasi biaya**
Anda dapat menonaktifkan tag alokasi biaya apa pun yang dibuat dari label Kubernetes. Setelah dinonaktifkan, data tidak akan lagi terisi di kolom masing-masing, dan kolom akan dihapus dari CUR bulan depan.
## Praktik terbaik untuk mengelola label Kubernetes untuk alokasi biaya
Label Kubernetes memberikan fleksibilitas yang signifikan dalam pemodelan alokasi biaya bersama. Untuk memaksimalkan potensi kemampuan ini, kami sarankan mengikuti praktik terbaik ini untuk mengoptimalkan pendekatan manajemen biaya Anda.
**Memahami batas label**
label-per-pod Batas 50 didasarkan pada penyortiran abjad. Hanya 50 label pertama yang diurutkan menurut abjad yang akan diimpor untuk alokasi biaya. Untuk memastikan label penting disertakan, rencanakan penamaan label Anda dengan hati-hati untuk memastikan label penting muncul dalam 50 pertama saat diurutkan menurut abjad.
**Mengikuti kendala karakter**
AWS tag alokasi biaya memiliki batas karakter berikut:
+ Tombol tag: 128 karakter
+ Nilai tag: 256 karakter
Meskipun Kubernetes mengizinkan label yang lebih panjang, label apa pun yang melebihi batas ini tidak akan diimpor. Rancang label Anda dalam batas-batas ini untuk memastikan pelacakan alokasi biaya yang berhasil.
**Menambahkan label baru saat berkapasitas**
Ketika sebuah pod telah mencapai batas 50 label dan Anda perlu menambahkan label alokasi biaya baru, ikuti langkah-langkah berikut:
1. Tinjau label yang ada dan identifikasi tag alokasi biaya untuk dinonaktifkan.
1. Nonaktifkan tag yang dipilih.
1. Tambahkan label alokasi biaya baru.
1. Pastikan label baru termasuk dalam 50 label pertama yang diurutkan menurut abjad.
**catatan**
Ingatlah bahwa hanya 50 label pertama yang diurutkan menurut abjad yang digunakan untuk alokasi biaya.
# Menggunakan data alokasi biaya terpisah dengan Amazon Managed Service untuk Prometheus
Memisahkan data biaya untuk Amazon EKS mengharuskan Anda mengumpulkan dan menyimpan metrik dari cluster Anda, termasuk memori dan penggunaan CPU. Amazon Managed Service untuk Prometheus dapat digunakan untuk tujuan ini.
Setelah Anda memilih untuk membagi data alokasi biaya dan Layanan Terkelola Amazon untuk ruang kerja Prometheus mulai menerima dua metrik yang diperlukan (`container_cpu_usage_seconds_total`dan`container_memory_working_set_bytes`), data alokasi biaya terpisah mengenali metrik dan menggunakannya secara otomatis.
**catatan**
Dua metrik yang diperlukan (`container_cpu_usage_seconds_total`dan`container_memory_working_set_bytes`) hadir dalam konfigurasi scrape Prometheus default dan konfigurasi default yang disediakan dengan kolektor terkelola. AWS Namun, jika Anda menyesuaikan konfigurasi ini, jangan memberi label ulang, memodifikasi, atau menghapus label berikut dari `container_memory_working_set_bytes` metrik `container_cpu_usage_seconds_total` dan:`name`,, `namespace` dan. `pod` Jika Anda memberi label ulang, memodifikasi, atau menghapus label ini, itu dapat memengaruhi konsumsi metrik Anda.
Anda dapat menggunakan Layanan Terkelola Amazon untuk Prometheus untuk mengumpulkan metrik EKS dari satu akun penggunaan, di satu Wilayah. Layanan Terkelola Amazon untuk ruang kerja Prometheus harus ada di akun dan Wilayah tersebut. Anda memerlukan satu Layanan Terkelola Amazon untuk instans Prometheus untuk setiap akun penggunaan dan Wilayah yang ingin Anda pantau biayanya. Anda dapat mengumpulkan metrik untuk beberapa klaster di Layanan Terkelola Amazon untuk ruang kerja Prometheus, selama mereka berada di akun penggunaan dan Wilayah yang sama.
Bagian berikut menjelaskan cara mengirim metrik yang benar dari kluster EKS Anda ke Amazon Managed Service untuk ruang kerja Prometheus.
## Prasyarat
Sebagai prasyarat untuk menggunakan Amazon Managed Service untuk Prometheus dengan data alokasi biaya terpisah:
+ Anda perlu mengaktifkan data alokasi biaya terpisah di konsol AWS Billing and Cost Management. Untuk detailnya, lihat [Mengaktifkan data alokasi biaya terpisah](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html). Memilih untuk membagi data alokasi biaya akan membuat peran terkait layanan di setiap akun penggunaan untuk menanyakan Layanan Terkelola Amazon untuk Prometheus untuk metrik klaster Amazon EKS di akun tersebut. Untuk informasi selengkapnya, lihat [Peran terkait layanan untuk data alokasi biaya terpisah](https://docs.aws.amazon.com/cost-management/latest/userguide/split-cost-allocation-data-SLR.html).
+ Anda memerlukan kluster EKS yang ingin Anda lacak data alokasi biaya terpisah. Ini bisa berupa cluster yang sudah ada, atau Anda dapat membuat yang baru. Untuk informasi selengkapnya, lihat [Membuat klaster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) di *Panduan Pengguna Amazon EKS*.
**catatan**
Anda akan membutuhkan`EKS cluster ARN`,`security group IDs`, dan setidaknya dua `subnet IDs` (di zona ketersediaan yang berbeda) untuk digunakan dalam langkah selanjutnya.
(opsional) Setel mode otentikasi kluster EKS Anda ke salah satu `API` atau`API_AND_CONFIG_MAP`.
+ Anda memerlukan Layanan Terkelola Amazon untuk instans Prometheus di akun dan Wilayah yang sama dengan kluster EKS Anda. Jika Anda belum memilikinya, Anda dapat membuatnya. Untuk informasi selengkapnya tentang membuat Layanan Terkelola Amazon untuk instance Prometheus, [lihat Membuat ruang kerja](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) di Panduan Pengguna Layanan *Terkelola Amazon* untuk Prometheus.
**catatan**
Anda akan membutuhkan `Amazon Managed Service for Prometheus workspace ARN` untuk digunakan dalam langkah-langkah selanjutnya.
## Meneruskan metrik EKS ke Layanan Terkelola Amazon untuk Prometheus
Setelah Anda memiliki kluster EKS dan Layanan Terkelola Amazon untuk instance Prometheus, Anda dapat meneruskan metrik dari cluster ke instance. Anda dapat mengirim metrik dengan dua cara.
+ [Opsi 1: Gunakan kolektor AWS terkelola.](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data-resource-amp.html#use-managed-collector) Ini adalah cara paling sederhana untuk mengirim metrik dari kluster EKS ke Amazon Managed Service untuk Prometheus. Namun, itu memang memiliki batas hanya menggores metrik setiap 30 detik paling banyak.
+ [Opsi 2: Buat agen Prometheus Anda sendiri.](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data-resource-amp.html#create-prometheus-agent) Dalam hal ini, Anda memiliki kontrol lebih besar atas konfigurasi pengikisan, tetapi Anda harus mengelola agen setelah membuatnya.
### Opsi 1: Menggunakan kolektor AWS terkelola
Menggunakan kolektor AWS terkelola (*scraper*) adalah cara paling sederhana untuk mengirim metrik dari kluster EKS ke Layanan Terkelola Amazon untuk instance Prometheus. Prosedur berikut akan membantu Anda membuat kolektor AWS terkelola. Untuk informasi selengkapnya, lihat [pengumpul AWS terkelola](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector.html) di *Amazon Managed Service for Prometheus* User Guide.
**catatan**
AWS kolektor yang dikelola memiliki interval goresan minimum 30 detik. Jika Anda memiliki pod berumur pendek, rekomendasinya adalah mengatur interval scraper Anda menjadi 15 detik. Untuk menggunakan interval scraper 15 detik, gunakan opsi 2 untuk [membuat agen Prometheus Anda sendiri](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data-resource-amp.html#create-prometheus-agent).
Ada tiga langkah untuk membuat kolektor AWS terkelola:
1. Buat konfigurasi scraper.
1. Buat scraper.
1. Konfigurasikan kluster EKS Anda untuk memungkinkan scraper mengakses metrik.
*Langkah 1: Buat konfigurasi scraper*
Untuk membuat scraper, Anda harus memiliki konfigurasi scraper. Anda dapat menggunakan konfigurasi default, atau membuat sendiri. Berikut ini adalah tiga cara untuk mendapatkan konfigurasi scraper:
+ Dapatkan konfigurasi default menggunakan AWS CLI, dengan memanggil:
```
aws amp get-default-scraper-configuration
```
+ Buat konfigurasi Anda sendiri. Untuk detailnya, lihat petunjuk [konfigurasi Scraper](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-configuration) di *Amazon Managed Service for Prometheus* User Guide.
+ Salin konfigurasi sampel yang disediakan dalam instruksi [konfigurasi Scraper](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-configuration) yang sama di *Amazon Managed Service for Prometheus* User Guide.
Anda dapat mengedit konfigurasi scraper, untuk memodifikasi interval scrape atau untuk memfilter metrik yang tergores, misalnya.
Untuk memfilter metrik yang dikikis agar hanya menyertakan dua yang diperlukan untuk membagi data alokasi biaya, gunakan konfigurasi scraper berikut:
```
global:
scrape_interval: 30s
#external_labels:
#clusterArn:
scrape_configs:
- job_name: kubernetes-nodes-cadvisor
scrape_interval: 30s
scrape_timeout: 10s
scheme: https
authorization:
type: Bearer
credentials_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:
- role: node
relabel_configs:
- regex: (.+)
replacement: /api/v1/nodes/$1/proxy/metrics/cadvisor
source_labels:
- __meta_kubernetes_node_name
target_label: __metrics_path__
- replacement: kubernetes.default.svc:443
target_label: __address__
metric_relabel_configs:
- source_labels: [__name__]
regex: 'container_cpu_usage_seconds_total|container_memory_working_set_bytes'
action: keep
```
*Setelah Anda memiliki konfigurasi scraper, Anda harus mengkodekannya base64 untuk digunakan pada langkah 2.* Konfigurasi adalah file teks YAMM. Untuk menyandikan file, gunakan situs web seperti [https://www.base64encode.org/.](https://www.base64encode.org/)
*Langkah 2: Buat scraper*
Sekarang setelah Anda memiliki file konfigurasi, Anda perlu membuat scraper Anda. Buat scraper menggunakan perintah AWS CLI berikut, berdasarkan variabel yang diuraikan di bagian prasyarat. Anda harus menggunakan informasi dari kluster EKS untuk**,**, dan ** bidang, ganti ** dengan konfigurasi scraper yang Anda buat pada langkah sebelumnya, dan ganti ** dengan Layanan Terkelola Amazon untuk ARN ruang kerja Prometheus.
```
aws amp create-scraper \
--source eksConfiguration="{clusterArn=,securityGroupIds=[],subnetIds=[]}" \
--scrape-configuration configurationBlob= \
--destination ampConfiguration={workspaceArn=""}
```
Catat `scraperId` yang dikembalikan untuk digunakan pada *langkah 3*.
*Langkah 3: Konfigurasikan cluster EKS Anda untuk memungkinkan scraper mengakses metrik*
Jika mode otentikasi kluster EKS Anda disetel ke salah satu `API` atau`API_AND_CONFIG_MAP`, maka scraper Anda akan secara otomatis memiliki kebijakan akses dalam cluster yang benar, dan pencakar akan memiliki akses ke cluster Anda. Tidak diperlukan konfigurasi lebih lanjut, dan metrik harus mengalir ke Amazon Managed Service untuk Prometheus.
Jika mode otentikasi kluster EKS Anda tidak disetel ke `API` atau`API_AND_CONFIG_MAP`, Anda perlu mengonfigurasi cluster secara manual untuk memungkinkan scraper mengakses metrik Anda melalui dan. ClusterRole ClusterRoleBinding Untuk mempelajari cara mengaktifkan izin ini, lihat [Mengkonfigurasi kluster EKS secara manual untuk akses scraper di Amazon Managed Service for](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-eks-setup) *Prometheus* User Guide.
Setelah scraper aktif, verifikasi bahwa kedua metrik (`container_cpu_usage_seconds_total`dan`container_memory_working_set_bytes`) didorong ke Layanan Terkelola Amazon Anda untuk ruang kerja Prometheus.
```
awscurl --service="aps" --region="" "https://aps-workspaces..amazonaws.com/workspaces//api/v1/label/__name__/values"
```
Output:
```
{
"status": "success",
"data": [
"container_cpu_usage_seconds_total",
"container_memory_working_set_bytes",
"scrape_duration_seconds",
"scrape_samples_post_metric_relabeling",
"scrape_samples_scraped",
"scrape_series_added",
"up"
]
}
```
### Opsi 2: Membuat agen Prometheus Anda sendiri
Jika Anda tidak dapat menggunakan kolektor AWS terkelola, atau sudah memiliki server Prometheus sendiri, Anda dapat menggunakan instance Prometheus Anda sendiri sebagai agen untuk mengikis metrik dari kluster EKS Anda dan mengirimkannya ke Amazon Managed Service untuk Prometheus.
*Untuk petunjuk terperinci tentang cara menggunakan instans Prometheus Anda sendiri sebagai agen, lihat [Menggunakan instance Prometheus sebagai kolektor di Amazon Managed Service for Prometheus User Guide](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-ingest-with-prometheus.html).*
Berikut ini adalah contoh konfigurasi scrape Prometheus yang mencakup interval pengikisan server Prometheus dan metrik wadah yang diperlukan untuk membagi data alokasi biaya. Jika Anda memiliki pod yang berumur pendek, rekomendasinya adalah menurunkan interval pengikisan server Prometheus default dari 30 detik menjadi 15 detik. Perhatikan bahwa ini dapat mengakibatkan penggunaan memori server Prometheus yang tinggi.
```
global:
scrape_interval: 30s
#external_labels:
#clusterArn:
scrape_configs:
- job_name: kubernetes-nodes-cadvisor
scrape_interval: 30s
scrape_timeout: 10s
scheme: https
authorization:
type: Bearer
credentials_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:
- role: node
relabel_configs:
- regex: (.+)
replacement: /api/v1/nodes/$1/proxy/metrics/cadvisor
source_labels:
- __meta_kubernetes_node_name
target_label: __metrics_path__
- replacement: kubernetes.default.svc:443
target_label: __address__
metric_relabel_configs:
- source_labels: [__name__]
regex: 'container_cpu_usage_seconds_total|container_memory_working_set_bytes'
action: keep
```
Jika Anda mengikuti [Mengatur konsumsi dari server Prometheus baru menggunakan Helm di dalam Amazon *Managed Service for Prometheus*](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-ingest-metrics-new-Prometheus.html) User Guide, maka Anda dapat memperbarui konfigurasi scrape Anda.
**Untuk memperbarui konfigurasi scrape Anda**
1. Edit `my_prometheus_values_yaml` dari panduan dan sertakan konfigurasi scrape sampel di blok. `server`
1. Jalankan perintah berikut, menggunakan `prometheus-chart-name` dan `prometheus-namespace` dari *Amazon Managed Service for Prometheus User Guide*.
```
helm upgrade prometheus-chart-name prometheus-community/prometheus -n prometheus-namespace -f my_prometheus_values_yaml
```
[Untuk mempelajari lebih lanjut tentang `scrape_interval` atau cara menggunakan scrape\$1interval non-global, lihat konfigurasi scrape Prometheus.](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config)
Atau, Anda dapat menggunakan AWS Distro untuk OpenTelemetry kolektor yang memiliki Penerima Prometheus, Eksportir Tulis Jarak Jauh Prometheus, dan AWS Ekstensi Otentikasi Sigv4 untuk mencapai akses tulis jarak jauh ke Amazon Managed Service untuk Prometheus.
**catatan**
Setelah Anda mengatur agen Prometheus Anda, AWS tidak seperti kolektor terkelola, Anda bertanggung jawab untuk menjaga agen tetap up to date dan berjalan untuk mengumpulkan metrik.
## Memperkirakan Layanan Terkelola Amazon Anda untuk biaya Prometheus
Anda dapat menggunakan Kalkulator AWS Harga untuk memperkirakan biaya penggunaan Amazon Managed Service untuk Prometheus untuk data alokasi biaya terpisah.
**Untuk mengonfigurasi Amazon Managed Service untuk Prometheus untuk perkiraan Anda**
1. Kalkulator AWS Harga Terbuka di [https://calculator.aws/\$1/](https://calculator.aws/#/).
1. Pilih **Buat estimasi**.
1. **Pada halaman **Tambah layanan**, masukkan **Amazon Managed Service untuk Prometheus** di kolom pencarian, lalu pilih Configure.**
1. Di bidang **Deskripsi**, masukkan deskripsi untuk perkiraan Anda.
1. Pilih **Wilayah**.
1. Pilih **Hitung biaya menggunakan detail infrastruktur Anda**. Opsi ini memungkinkan Anda memperkirakan biaya konsumsi, penyimpanan, dan kueri sampel berdasarkan penyiapan infrastruktur Anda saat ini atau yang diusulkan.
1. Untuk **Jumlah instans EC2**, masukkan jumlah instans EC2 di semua klaster untuk seluruh keluarga penagihan gabungan Anda (termasuk semua akun dan Wilayah). Jika Anda menggunakan AWS Fargate, gunakan jumlah tugas Fargate sebagai proxy untuk jumlah instans EC2 Anda.
1. Data alokasi biaya terpisah membutuhkan dua metrik: `container_cpu_usage_seconds_total` dan. `container_memory_working_set_bytes` Untuk **metrik Prometheus per instans EC2**, masukkan 2.
1. Data alokasi biaya terpisah menunjukkan interval gesekan 15 detik. Untuk **interval pengumpulan Metrik (dalam detik)**, masukkan 15. Jika Anda menggunakan interval yang berbeda (misalnya, 30 detik), ubah ini ke interval yang Anda atur.
1. Data alokasi biaya terpisah tidak memaksakan persyaratan khusus apa pun untuk parameter lain, jadi masukkan nilai yang sesuai untuk parameter input lainnya sesuai kebutuhan bisnis Anda.
1. Pilih **Simpan dan tambahkan layanan**.
# Menggunakan data alokasi biaya terpisah dengan Amazon CloudWatch Container Insights
Memisahkan data biaya untuk Amazon EKS mengharuskan Anda mengumpulkan dan menyimpan metrik dari cluster Anda, termasuk memori dan penggunaan CPU. Amazon CloudWatch Container Insights dapat digunakan untuk tujuan ini.
Setelah Anda memilih untuk membagi data alokasi biaya dan menyiapkan CloudWatch agen dengan add-on observabilitas EKS di cluster EKS Anda, data alokasi biaya terpisah mulai menerima dua metrik yang diperlukan `(pod_cpu_usage_total` dan`pod_memory_working_set`) di namespace dan menggunakannya secara otomatis. `ContainerInsights` *Untuk melihat set lengkap metrik container untuk EKS, lihat metrik [Amazon EKS dan Kubernetes Container Insights di Panduan](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html) Pengguna Amazon. CloudWatch *
Bagian berikut menjelaskan cara mengirim metrik yang benar dari kluster EKS Anda untuk membagi data alokasi biaya.
## Prasyarat
Sebagai prasyarat untuk menggunakan Amazon CloudWatch Container Insights dengan data alokasi biaya terpisah:
+ Anda perlu mengaktifkan data alokasi biaya terpisah di konsol AWS Billing and Cost Management. Untuk detailnya, lihat [Mengaktifkan data alokasi biaya terpisah](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html).
+ Anda memerlukan kluster EKS yang ingin Anda lacak data alokasi biaya terpisah. Ini bisa berupa cluster yang sudah ada, atau Anda dapat membuat yang baru. Untuk informasi selengkapnya, lihat [Membuat klaster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) di *Panduan Pengguna Amazon EKS*.
## Menyiapkan Amazon CloudWatch Container Insights untuk meneruskan metrik EKS
Anda perlu mengatur dan mengonfigurasi CloudWatch agen untuk meneruskan metrik EKS. Anda dapat menggunakan [add-on Amazon CloudWatch Observability EKS atau bagan Helm CloudWatch Observability Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html) untuk menginstal CloudWatch agen dan agen Fluent-bit pada cluster EKS. Untuk informasi selengkapnya tentang cara menginstal dan menyiapkan CloudWatch agen, lihat [Menginstal add-on Amazon CloudWatch Observability EKS di CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-EKS-addon.html) *Panduan Pengguna Amazon*.
Berikut ini adalah versi minimum yang diperlukan untuk CloudWatch agen dan add-on EKS:
+ CloudWatch versi agen: v1.300045.0
+ CloudWatch Versi pengaya Observability EKS: v2.0.1-eksbuild.1
## Memperkirakan biaya Amazon CloudWatch Anda
Mengaktifkan fitur untuk menggunakan Amazon CloudWatch Container Insights dengan data alokasi biaya terpisah menambahkan dua metrik baru ke CloudWatch Amazon Container Insights: dan. `pod_cpu_usage_total` `pod_memory_working_set` *Untuk detail tentang metrik ini, lihat metrik [Amazon EKS dan Kubernetes Container Insights di Panduan Pengguna](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html) Amazon. CloudWatch *
**Untuk memahami biaya yang terkait dengan fitur**
1. Buka CloudWatch Harga Amazon dengan [https://aws.amazon.com/cloudwatch/harga/.](https://aws.amazon.com/cloudwatch/pricing/)
1. Arahkan ke bagian **Tingkat berbayar**.
1. Pilih tab **Wawasan Kontainer**.
1. Untuk perhitungan biaya secara terperinci, buka bagian **Contoh Harga, dan lihat Contoh** **13 - Wawasan Kontainer untuk Amazon EKS dan Kubernetes**.