AWS-ийн хөнгөлөлтөд шууд бүү түгж: ашиглаагүй цаг буцаад ирэхгүй

Тогтвортой Amazon EC2 ачаалалд Reserved Instances (RI) эсвэл Savings Plans сонгохдоо эхлээд ачаалал хэр өөрчлөгдөхийг, дараа нь цаг бүр хөнгөлөлтөд хамрагдаагүй үлдэх хэрэглээг хар. AWS-ийн бүтээгдэхүүний харьцуулалтаар Compute Savings Plans нь Region болон instance family солигдсон ч EC2-д, мөн Fargate, Lambda хэрэглээнд үйлчилдэг; EC2 Instance Savings Plans нь сонгосон Region дахь нэг family-д, RI нь тохирох EC2 хэрэглээнд хамаарна. Худалдан авах commitment-ийг сарын нийт EC2 зардлаас шууд гаргах нь одоо байгаа хөнгөлөлтийн хамралтыг давхар тооцох эрсдэлтэй.

AWS-ийн тооцооны дүрэмд EC2 RI эхэлж, дараа нь EC2 Instance Savings Plans, эцэст нь Compute Savings Plans тохирох хэрэглээнд үйлчилдэг бөгөөд нэг цагт ашиглаагүй Savings Plans commitment дараагийн цагт шилждэггүй гэж заасан. Иймээс өндөр ачаалалтай цаг нам ачаалалтай цагийн ашиглагдаагүй дүнг нөхөхгүй. Сонгох дүн нь сарын дундаж зардлаас илүүтэй, RI болон одоо байгаа Savings Plans-ийн дараа тогтмол үлддэг цагийн хэрэглээнд тулгуурлах ёстой.

Хамрах хүрээ нь аль сонголтыг ашигтай болгох вэ?

Ижил EC2 тохиргоо удаан ажиллах нь тодорхой бол түүнд тохирох RI-ийн саналыг харьцуул. RI-ийн төрөл, Region болон тохиргооноос хамаарч хөнгөлөлт аль instance-д үйлчлэх нь өөр тул зөвхөн «RI-тэй» гэсэн тэмдэглэгээгээр нийт хэрэглээг хасаж болохгүй. Тухайн цагт бодитоор RI-д хамрагдсан хэсгийг л шинэ Savings Plans-ийн боломжит хэрэглээнээс хасна; RI-ийн өөрийн төлбөр нийт зардлын тооцоонд хэвээр үлдэнэ.

Нэг Region, нэг instance family хэвээр байх боловч хэмжээ, үйлдлийн систем эсвэл tenancy өөрчлөгдөж болох ачаалалд EC2 Instance Savings Plans тохирч болно. Family эсвэл Region солигдох, эсвэл ачаалал Fargate, Lambda руу шилжих боломжтой бол Compute Savings Plans-ийн өргөн хамрах хүрээ хэрэгтэй. Илүү өргөн хамрах хүрээ нь бүх тохиолдолд хамгийн бага төлбөр гэсэн үг биш: өөрийн ашиглах үйлчилгээ, тухайн тохиргооны тариф, төлөвлөсөн өөрчлөлтөөр хоёр төлөвлөгөө болон RI-ийн саналыг зэрэгцүүл.

Нэг цагийн илүүдэл дараагийн цагт яагаад тус болохгүй вэ?

Дараах нь зарчмыг харуулах нөхцөлт жишээ бөгөөд AWS-ийн бодит тариф биш. Ижил EC2 instance-ийн On-Demand үнэ цагт 1 ам.доллар, тохирох Savings Plans үнэ 0.70 ам.доллар гэж үзье. Нэг RI цаг бүр нэг instance-ийг хамарч, нэмэлт Savings Plans commitment цагт 2 ам.доллар байна.

Эхний цагт гурван instance ажиллавал RI нэгийг нь хамарна. Үлдсэн хоёрын Savings Plans үнээрх хэрэглээ 1.40 ам.доллар тул 2 ам.долларын commitment-ээс 0.60 ам.доллар ашиглагдахгүй. Дараагийн цагт таван instance ажиллахад RI-ийн дараа дөрөв үлдэж, тэдний Savings Plans үнээрх хэрэглээ 2.80 ам.доллар болно. Тэр цагийн 2 ам.долларын commitment хүрэлцэхгүй ч өмнөх цагийн 0.60 ам.долларыг энд нэмэх боломжгүй.

Дараагийн цагт commitment-ээс давсан 0.80 ам.доллар нь Savings Plans үнээр илэрхийлсэн хэрэглээний хэмжээ юм. Үүнийг шууд On-Demand төлбөр гэж бичвэл зардлыг буруу гаргана: хөнгөлөлтөд хамрагдаагүй хэрэглээнд тухайн instance-ийн On-Demand тариф үйлчилнэ. Мөн RI-ээс өмнөх гурван эсвэл таван instance-ийн нийт зардлаар commitment сонговол RI-д аль хэдийн хамрагдсан хэсгийг дахин санхүүжүүлнэ. Нэг цагийн ашиглагдаагүй үүрэг, нөгөө цагийн нэмэлт On-Demand төлбөрийг тусдаа мөрөөр харах нь энэ алдааг ил болгоно.

Сүүлийн 30 хоногоос цагийн суурь хэрэглээг гарга

Тооцоонд сүүлийн 30 хоногийг ажиглах цонх болгон сонгож, хүснэгтийн нэг мөрийг нэг цаг болго. Цаг бүрт данс, үйлчилгээ, Region, EC2 instance family, ашигласан хэмжээ, On-Demand тариф, тохирох RI болон одоо үйлчилж буй Savings Plans-ийн хамралтыг ялгаж бич. Энэ нь худалдан авах хэмжээг тогтоох ажлын арга болохоос өнгөрсөн сарын дундаж зардлыг шууд ирээдүйн баталгаа гэж үзсэн хэрэг биш.

1. EC2 хэрэглээний цаг бүрт тохирох RI-г эхэлж оноо. Данс хооронд хөнгөлөлт хуваалцдаг бол аль дансны хэрэглээнд үйлчлэхийг мөн ялга; RI-д хамрагдсан хэмжээг шинэ Savings Plans-ийн хэрэгцээнд дахин бүү оруул.
2. RI-ийн дараах хэрэглээнээс одоо байгаа EC2 Instance Savings Plans, дараа нь Compute Savings Plans-д хамрагдсан хэсгийг ялга. Шинэ commitment авах боломжит суурь нь энэ хоёрын дараа үлдэх, сонгох төлөвлөгөөнд тохирох хэрэглээ юм.
3. Үлдсэн хэрэглээг сонгох төлөвлөгөөний тарифаар үнэл. AWS-ийн худалдан авах зааварт цагийн commitment-ийг On-Demand зардлаар бус, Savings Plans-ийн үнээр оруулахыг тодорхойлсон. EC2 Instance Savings Plans-д зөвхөн сонгосон Region ба family-ийн үлдэгдлийг, Compute Savings Plans-д түүнд тохирох EC2, Fargate, Lambda үлдэгдлийг хамруул.
4. Цагийн дүнг эрэмбэлж, хамгийн бага үе, ердийн өдрийн суурь түвшин, оргил үеийг тусад нь хар. Нэг удаагийн зогсолтыг бүх хугацааны суурь гэж үзэхгүйгээр шалтгааныг нь тэмдэглэ; харин давтагддаг нам ачаалалтай цагийг commitment хэмжихэд заавал оруул.

Хүснэгтэд нэр дэвшигч commitment, тухайн цагт ашиглагдах хэмжээ, ашиглагдахгүй үлдэх дүн, хөнгөлөлтөөс давсан хэрэглээ гэсэн багана нэм. Ашиглагдахгүй дүн нь commitment-ээс тэр цагт хамрагдсан хэрэглээг хассан хэмжээ; давсан хэрэглээний төлбөрийг харин On-Demand тарифаар тусад нь бодно. Хэрэв олон төрлийн хэрэглээ нэг төлөвлөгөөнд хамрагдах боломжтой бол AWS илүү өндөр хэмнэлтийн хувьтай хэрэглээнд хөнгөлөлтийг түрүүлж оноодог тул бүх үлдэгдлийг нэг дундаж тарифаар үржүүлэх нь зөвхөн ойролцоо тооцоо болно.

Ачаалал болон төгрөгийн төсөвт хэр мэдрэмтгий вэ?

Нэр дэвшигч commitment-ийг өнөөгийн хэрэглээнд тааруулсны дараа улирлын сул үе, төлөвлөсөн зогсолт, instance family эсвэл Region солих хувилбарыг ижил цагийн хүснэгтээр тооц. RI-ийн хугацаа дуусах хувилбарыг тусад нь хар: тэр үед өнөөдөр RI-д хамрагдаж буй хэрэглээ шинэ төлөвлөгөөнд тохирох үлдэгдэл болж болно. Хувилбар бүрт ашиглагдахгүй commitment үүсэх цаг, нэмэлт On-Demand хэрэглээ гарах цаг хоёрыг тоолбол өргөн хамрах хүрээний үнэ цэнийг өөрийн ачааллаар хэмжинэ.

Төсөв төгрөгөөр бол ам.доллараар илэрхийлсэн цагийн үүрэг болон нэмэлт On-Demand төлбөрийг төсөвт авсан ханшаар, дараа нь төгрөг сулрах нөхцөлт ханшаар хөрвүүл. Ханшийн өөрчлөлт нь AWS-ийн хөнгөлөлтийн хувийг өөрчлөхгүй ч төгрөгөөр төлөвлөсөн зардалд нөлөөлнө. Урьдчилгаа төлбөртэй санал сонговол эхний мөнгөн урсгалыг дараах тогтмол зардлаас тусад нь үз.

Эхний commitment-д давтагддаг нам ачаалалтай цагт ч ашиглагдах хэмжээг сонгох нь илүүдэл төлбөрийн эрсдэлийг багасгана. Тогтвортой тохиргоонд RI-ийн саналыг, нэг family ба Region-д үлдэх хэсэгт EC2 Instance Savings Plans-ийг, өөрчлөгдөж болох үлдэгдэлд Compute Savings Plans-ийг ижил нөхцөлөөр харьцуул. Оргил цаг бүрийг бүрэн хамрахын тулд commitment өсгөхөөс өмнө тэр нэмэгдлийн нам ачаалалтай цагт ашиглагдахгүй үлдэх өртгийг тооц.

Мөн уншаарай:

• DMARC-ийг шууд reject бүү болго: нэг mailto алдаа хамгаалалтыг чимээгүй унтраана
• ESA Mistral-ийн AI-г сансарт ашиглана, шийдвэрийг хүн гаргасан хэвээр
• Монголд компани бүртгүүлэх нь: 15 хоногийн мэдэгдлийг бүү март