# Optimizing cost with AWS Graviton-based services

ကျွန်တော်တို့ Company or Organization က AWS Managed Services တွေကို အသုံးပြုနေတယ်ဆိုရင် AWS Cost Optimization လုပ်လို့ရတဲ့ နည်းလမ်းတွေထဲကမှ အလွယ်ဆုံးနည်းလမ်းတစ်ခုကို sharing လုပ်ချင်ပါတယ်။ ရိုးရိုးရှင်းရှင်းလေးပါ လက်ရှိသုံးနေတဲ့ Managed Service x86\_64 based service တွေကနေ **AWS Graviton-Powered ( ARM based )** ကိုပြောင်းသုံးလိုက်တာပါပဲ။ Core Services ထဲကမှ ကိုယ်က **Compute** အပိုင်းထဲကဆိုရင် AWS Lambda, AWS Fargate ( WIP ), AWS Elastic Beanstalk တို့ရှိတယ်။ **Database** အပိုင်းထဲမှာဆိုရင် Amazon Aurora, Amazon RDS, Amazon ElastiCache, Amazon MemoryDB, Amazon DocumentDB, Amazon Neptune တို့ရှိတယ်။ **SIEM/AI/ML** အပိုင်းထဲမှာဆိုရင် Amazon OpenSearch, Amazon EMR, Amazon SageMaker နဲ့ **Storage** အပိုင်းမှာဆိုရင် Amazon FSx for Lustre, Open ZFS တို့ရှိတယ်။ ဒါ့အပြင် တစ်ခြား service တွေလည်းရှိသေးတယ် ရွတ်ပြနေရင်တော့ပြီးမှာ မဟုတ်တော့ဘူး 🤪

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1681760337904/791304a9-c492-4bfd-b0bb-c60ce8def5e9.png?auto=compress,format\&format=webp)

ဒီနေရာမှာ ပုံမှန်အားဖြင့် ကျွန်တော်တို့ အမြဲရွေးချယ်ကြတာက x86\_64 based တွေပဲ ဆိုတော့ကာ ကိုယ်က ဒီ service တွေကို စသုံးကတည်းက ARM based တွေကိုသုံးလိုက်မယ် သုံးလို့လည်းရတယ်ဆိုရင် သာမန် x86\_64 based တွေထက် cost 20% လောက်သက်သာသွားမယ်။ အိုကေ ကိုယ်က infrastructure provisioning လုပ်ကတည်းက ARM based ကို မသုံးခဲ့မိဘူး x86\_64 based ကိုပဲသုံးခဲ့မိတယ်ဆိုရင်လည်း ကိစ္စမရှိဘူး နောက်မှအလွယ်တကူ ပြန်ပြောင်းလို့ရတယ်။ x86\_64 based ကနေ ARM based ကို lift and shift မလုပ်ချင်သေးဘူး တဖြည်းဖြည်း Development > Staging > UAT > Performance > Production အဆင့်ဆင့် စမ်းပြီးပြောင်းကြည့်မယ် ဆိုရင်လည်း အိုကေတယ်။

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1681765559863/05656ad6-70aa-43bb-9265-4d0256723867.png?auto=compress,format\&format=webp)

x86\_64 based ကနေ ARM based ပြောင်းမယ်ဆိုရင် ဘယ် service တွေကအလွယ်ဆုံးလဲ ? 🤔

AWS Documentation တွေကိုဖတ်ပြီး ကျွန်တော့်အမြင် အတွေ့အကြုံအရဆိုရင်တော့

* Amazon Aurora
* Amazon RDS
* Amazon ElastiCache
* Amazon OpenSearch
* AWS Fargate ( WIP )
* AWS Lambda
* Amazon EC2 with containerized applications
* Amazon Elastic Kubernetes Service ( EKS )

ဒီ Managed Service တွေက production လို environment မျိုးမှာတောင် အလွယ်ဆုံး နဲ့ အမြန်ဆုံး migration လုပ်လို့ရတာပဲ။ Less Effort ပဲ။ Migration လုပ်တဲ့နေရာမှာက service တစ်ခုနဲ့ တစ်ခုပေါ်မူတည်ပြီးတော့ strategy ကတော့ မတူပြန်ဘူး။ တစ်ခြားအကြောင်းအရာတွေလည်း ထည့်ပြီးစဉ်းစားရဦးမယ် Data integrity, Performance, Compatibility, Complexity ဘာညာတွေပေါ့။ **AWS Graviton-Powered ( ARM based )** ကို ပြောင်းသုံးမယ်ဆိုရင်တော့ သာမန် x86\_64 based တွေထပ် up to 20% လောက် performance ပိုကောင်းမယ်လို့တော့ပြောထားတယ်။ Benchmarking လည်းသေချာ မလုပ်ကြည့်ရသေးတော့ တပ်အပ်ပြောဖို့တော့ မလွယ်ဘူး။ သေချာတာတစ်ခုကတော့ migration လုပ်ပြီး day-to-day operation မှာတော့အဆင်ပြေပြေချောချောမွေ့မွေ့ပဲ။ ဒီနေရာမှာပြောချင်တာက **AWS Graviton-Powered ( ARM based )** ကို ပြောင်းသုံးလို့ Performance Auto ကောင်းလာမှာတော့ မဟုတ်ဘူး။ `there is no silver bullet.` ဆိုတော့ cost Optimization ဘက်ပြန်လှည့်မယ်ဆိုရင်လည်း ကိုယ်က cost လျော့ချင်သေးတယ် ဆိုရင် migration လုပ်ပြီး ကိုယ့် application မှာလည်းဘာပြဿနာ မှမရှိဘူး အကုန်အဆင်ပြေတယ် Workload Utilization တွေကလည်း Predictable ဖြစ်တယ်ရင် ကိုယ်နဲ့ အဆင်ပြေမယ့် reserved instance သာဝယ်လိုက်။ **easy peasy lemon squeezy.**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1681767993771/9791ecc1-2b0f-4dbe-a00e-ded027c62ad9.png?auto=compress,format\&format=webp)

ဒီနေရာမှာ တစ်ခုရှိတာက တစ်ချို့ Compute Service ( EC2 ) မှာဆို လက်ရှိ ရှိနေပြီးသား workload ကနေ ပြောင်းချင်တိုင်း အလွယ်တကူ ပြောင်းဖို့အဆင်ပြေမနေဘူး။ EC2 Compute က ကျွန်တော်တို့ကို compute instance နဲ့ Operating System ( Linux/Windows ) အခွံကြီးပေးလိုက်တာ၊ အဲသည် အပေါ်မှာမှ ကိုယ်လိုချင်တဲ့ အမျိုးမျိုးသော applications တွေတင် run တာဆိုတော့ ကျွန်တော်တို့မှာ Dependencies ပြဿနာတွေ Operating System ပြဿနာတွေ ကိုယ်သုံးမယ့် Application က ARM support လုပ်တာတွေ ရှိနိုင်တယ်။ ဥပမာ Operating System က x86\_64 based မှာကျွန်တော်တို့ ARM based application တွေသွားတင် run လို့ ရမနေဘူး။ အိုကေ Operating System ကလည်း ARM based နဲ့ application ကလည်း ARM based အတွက်ထုတ်ထားတဲ့ application ဖြစ်ရင်တောင်မှ အဲ့သည် application ကသုံးတဲ့ libraries, binaries , runtimesတွေက အဆင်မပြေတာတွေ ရှိသေးတယ်။ ဒါပေမယ့်နောက်ပိုင်းတော်တော်များများ application တွေကတော့ ARM support လုပ်လာကြပြီ။ လူသုံးများတဲ့ application တွေကတော့ multi-architecture support လုပ်ကြပါတယ်။ Popular Container Image တွေကတော့ သုံးနေသလောက်မှာ အကုန်နီးပါး အဆင်ပြေတယ်။ တစ်ချို့ custom application တွေမှာတော့ ARM based ပြောင်းပြီးရင် optimization လိုက်လုပ်ရတာမျိုးတွေရှိတယ်။

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1681765249620/57eb854c-afd3-4e56-aa18-2335759e2123.png?auto=compress,format\&format=webp)

ဆိုတော့ လိုရင်းပြောရရင် လက်ရှိ x86\_64 based EC2 ပေါ်မှာ up and running ဖြစ်နေတဲ့ Application တွေကိုပြောင်းမယ်ဆိုရင်တော့ နည်းနည်းလက်ဝင်တယ်ပေါ့ဗျာ။ ဒါပေမယ့် Step by step , phase by phase စမ်းမယ်ပြောင်းမယ်ဆိုရင်တော့ အဆင်ပြေပါတယ်။ စကားချပ် ARM based တွေ ပြောင်းမယ်ဆိုရင်တော့ လက်ရှိအချိန် AWS မှာ Windows Operation System အတွက်အဆင်မပြေသေးပဲ Linux Operating System အတွက်ပဲ အဆင်ပြေပါသေးတယ်။

စမ်းကြည့်လို့ရမယ့် reference links

* <https://catalog.workshops.aws/graviton/en-US>
* <https://github.com/aws/aws-graviton-getting-started>
* <https://github.com/aws/porting-advisor-for-graviton>

Thank you.\
Wai Yan Min ( Part of AWSUGMM )


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://blog.awsugmm.org/aws-user-group-myanmar/cost_and_billing/optimizing-cost-with-aws-graviton-based-services.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.