DEV Community: KaungThant Lwin

Disaster Recovery Strategy in AWS (In Burmese - Part 1)

KaungThant Lwin — Tue, 28 Mar 2023 20:51:51 +0000

ကျွန်တော် ဒီနေ့ မျှဝေပေးချင်တဲ့ အကြောင်းအရာကတော့ AWS Cloud Environment ပေါ်မှာ ကျွန်တော်တို့အနေနဲ့ ဘယ်လိုမျိုး Disaster Recovery Strategy တွေကိုအသုံးပြုလို့ရနိုင်လဲဆိုတာ ကိုမျှဝေပေးသွားမှာ ဖြစ်ပါတယ်။

Disaster Recovery Strategies တွေလို့ပဲ ပြောပြော options လို့ပဲ ပြောပြော
ကျွန်တော်တို့အနေနဲ့ Cloud ပေါ်မှာ Disaster Recovery လုပ်မယ်ဆို အောက်ပါ
အချက် အလက်တွေ နဲ့ ရင်းနီးနေဖို့လိုပါတယ်။

Backup & Restore
Pilot Light
Warm Standby
Multi-site (Active/Active)

ဒီအထက်ပါ options တွေကို မပြောပြခင်မှာ ပထမဦးစွာ
Disaster ဆိုတဲ့အကြောင်းကို IT နဲ့ ပတ်သတ်ပြီး ရှင်းပြချင်ပါတယ်။
IT မဟုတ်တဲ့ သဘာဝပတ်ဝန်းကျင်အရဆိုရင်တော့ Disaster ဆိုတာ လေဘေး၊ ရေဘေး၊ မီးဘေး၊ မုန်းတိုင်း အစရှိတဲ့ ထိခိုက်မှုတွေဆိုတာကတော့ အားလုံးသိပြီးသားဖြစ်မှာပါ။ ဒီလို သဘာဝပတ်ဝန်းကျင်ဆိုင်ရာတွေမှာလဲ Disaster Recovery Plan တွေရှိကြပါတယ်။ အသက်ကယ်အဖွဲ့တွေ ကယ်ဆယ်ရေးတွေ အစရှိသည်တို့ဖြင့်ပေါ့လေ။ ဒါက တော့ လက်တွေ့ဘဝမှာ ရှိတဲ့ သဘာဝဘေးအန္တရာယ်တွေဖြစ်လာတဲ့အခါ ဘယ်လိုမျိုး ကြိုတင်ကာကွယ်မလဲ? ဖြစ်လာရင် ဘာလုပ်မလဲ? ဆိုတာမျိုးတွေပေါ့ဗျာ

ဒီတော့ IT ဘက်ကို ပြန်သွားကြမယ် ကျွန်တော်တို့ နည်းပညာအသိုင်းအဝိုင်းမှာတော့ Disaster ဆိုတာက တော့ မိမိတို့ manage လုပ်ရတဲ့ software တွေ infra တွေ အစရှိတဲ့ enviroments တွေက တခုခုကြောင့် Down သွားရတာမျိုး (ဥပမာ- DC မှာ မီးစက်ပျက်နေတာမျိုး ၊ Network Link တွေပျက်တောက်သွားတာမျိုး၊ နောက်ပြီး Cloud မှာဆိုလဲ Region လိုက်ကြီး Down နေတာမျိုး) ဒီလိုမျိုးအကြောင်းအရာတွေကြောင့် မိမိတို့ နဲ့ သက်ဆိုင်တဲ့ environment တွေ Down လာတဲ့အခါ ဘာလုပ်မလဲဆိုတဲ့ Disaster Recovery Plan ရှိဖို့ လိုအပ်လာပြီဖြစ်ပါတယ်။ အဓိကကတော့ Down နေတဲ့အချိန် ဘယ်လို ပြန်ပြီး Recover ဖြစ်အောင် လုပ်မလဲလို့ ဆိုလိုတာပါ။

ဒါဆိုရင်တော့ Disaster ကို နားလည်ပြီလို့ ယူဆလိုက်ပါမယ်။ ဒီတော့ Disaster ဖြစ်လာရင် သိဖို့လိုအပ်တဲ့ အသုံးအနှုန်းလေး (၂) ခုရှိပါသေးတယ်။

RTO နဲ့ RPO လို့ခေါ်တဲ့ အသုံးအနှုန်းလေး နှစ်ခုပဲဖြစ်ပါတယ်။
(၁). RTO ရဲ့ အရှည်ကောက်ကတော့ Recovery Time Objective ဖြစ်ပြီး မြန်မာလို နားလည်အောင် အဓိပ္ပါယ်ဖွင့်ဆိုရမယ်ဆိုရင် အမြင်သာဆုံးပြောမယ်ဆိုရင် Down ပြီးသွားတဲ့နောက် ဘယ်အချိန်တွင်း Recover ဖြစ်မလဲဆိုတာကို ဖော်ပြခြင်းပဲဖြစ်ပါတယ်။ ဥပမာ 1 Hour RTO လို့ project requirements မှာဖော်ပြထားတယ်ဆိုရင် ကျွန်တော်တို့အတွက် system ကြီး down ပြီးနောက် အချိန်တနာရီ အတွင်း ပြန်လည်ကောင်းမွန်အောင် ပြုလုပ်ပေးရမယ်လို့ သတ်မှတ်ပါတယ်ခဗျာ။ တကယ်လို့သာ တနာရီအတွင်း မကောင်းလာခဲ့ရင်တော့ SLA (Services Level Agreement) အလိုက် ပြန်လည်ပေးဆပ်ရမှာတွေရှိလာနိုင်ပါတယ်။ SLA အကြောင်းကိုတော့ နောက် အလျင်းသင့်ရင် ဖော်ပြပေးပါမယ်ခဗျာ။

(၂). RPO ရဲ့ အရှည်ကောက်ကတော့ Recovery Point Objective ဖြစ်ပြီး မြန်မာလို ပြောရမယ်ဆိုရင်တော့ ကျွန်တော်တို့ ရဲ့ System ကြီးက Data Loss ဘယ်လောက် ဖြစ်လို့ရလဲဆိုတာကို သတ်မှတ်တာမျိုးဖြစ်ပါတယ်။ ဥပမာအားဖြင့် 8 Hours or fewer RPO သတ်မှတ်ခဲ့မယ်ဆိုရင် ကျွန်တော်တို့ အနေနဲ့ Data ဆုံးရှူံးမှု (၈) နာရီစာ လက်ခံလို့ရတယ်လို့ ဆိုလိုချင်တာပါ။ အဓိကပြောချင်တာကတော့ဗျာ down တဲ့အချိန် မတိုင်ခင် ၈ နာရီ အတွင်း ရှိနေခဲ့တဲ့ Data တွေ ဆုံးရှူံးလို့ရတယ်လို့ ပြောချင်တာပါ။ ဥပမာဗျာ System က မနက် (၁၀) ရက်နေ့ မနက် (၁၀) နာရီမှာ Down သွားတယ်ဆိုပါစို့ ကျွန်တော်တို့ မှာက (၁၀) ရက်နေ့ မနက် (၂) နာရီမှာ Backup ရှိနေတာမျိုးကို အဓိကပြောချင်တာပါ။ ဒီတော့ ကျွန်တော်တို့အနေနဲ့ မနက် (၂) ကနေ မနက် (၁၀) နာရီကြားမှာ ရှိနေတဲ့ Data တွေကိုတော့ ဆုံးရှူံးရမှာဖြစ်ပါတယ်။ ဒါဆိုရင်တော့ မြင်ပြီးထင်ပါတယ်။ ဒီတော့ဗျာ RPO 1 hour လိုချင်ရင်တော့ တနာရီတိုင်းမှာ Backup လုပ်နေရမှာမျိုးပဲဖြစ်ပါတယ်။

ဒီလောက်ဆိုရင်တော့ RTO နဲ့ RPO ကိုနားလည်သွားပြီလို့ မျှော်လင့်ပါတယ်ခဗျာ။

ဒီတော့ ကျွန်တော်တို့ နည်းပညာသမားတွေ အထူးသဖြင့် System engineer တွေ DevOps တွေ Cloud Engineer တွေ နောက်ပြီး Cloud Architect တွေအနေနဲ့
system တခုခုကို implement လုပ်မယ် architect လုပ်မယ်ဆိုတဲ့ အချိန်တွေတိုင်းမှာ
ငါတို့ system ကြီးက RTO ဘယ်လောက်ရှိဖို့လိုမလဲ? RPO ကိုရော ဘယ်လိုသတ်မှတ်မလဲဆိုတာမျိုးကို မိမိတို့ရဲ့ System အရေးကြီးပုံပေါ်မူတည်ပြီး သတ်မှတ်ဖို့လိုပါတယ်ခဗျာ။

လုံးဝကို အရေးကြီးတဲ့ critical ဖြစ်တဲ့ system တွေ (ဥပမာ- Banking, medical, etc) ဆိုရင်တော့ RTO & RPO တွေကို အချိန်အနည်းငယ်ပဲ သတ်မှတ်ကြပါတယ်။ Medium size business တွေဆိုတဖုံ small business တွေဆိုရင်တော့ ကြာကြာ down လဲရတာမျိုးတွေတော့ ရှိတာပေါ့ခဗျာ။

RTO & RPO သတ်မှတ်ချက်တွေပေါ်မူတည်ပြီး Recovery Options တွေကလဲ ကုန်ကျစားရိတ် အနည်းအများ ကွာခြားသွားပါတယ်ခဗျာ။ ဒီ Recovery Options/Strategy အကြောင်းကိုတော့ ကျွန်တော် နောက်ထပ် အပိုင်း(၂) မှာ တင်ဆက်သွားပါမယ်ခဗျာ။
အားလုံး စောင့်မျှော်ဖတ်ရှူပေးကြဖို့ မျှော်လင့်ပါတယ်ခဗျာ။

အားလုံး သဘောကျနှစ်သက်ရင်တော့ Like & Share, Comment လေးတွေ ပြုလုပ်ပေးသွားလို့ရပါတယ်ခဗျာ...

Kaung Thant Lwin
AWS Community Builder
Myanmar

What is AWS RDS and RDS Pricing?(Part-2) (In Burmese)

KaungThant Lwin — Thu, 02 Mar 2023 18:33:46 +0000

အားလုံး မင်္ဂလာပါ RDS နဲ့ ပတ်သတ်ပြီး ကျန်ရှိနေသေးတဲ့ အပိုင်း(၂)ကို ယခုပို့စ်မှာ ဖော်ပြပေးချင်ပါတယ်ခဗျာ။
အပိုင်း(၁) ဖတ်ရန် -

RDS အတွက် ကုန်ကျစားရိတ်ကို တွက်ချက်ရမှာတော့ နောက်ထပ်ကျန်ရှိနေတဲ့ Data Transfer (Bandwidth) cost ပဲဖြစ်ပါတယ်ခဗျာ။

Data Transfer cost ဆိုတာကတော့ ကျွန်တော်တို့ရဲ့ RDS Instance ကို create လုပ်ထားတဲ့ AWS ရဲ့ Data Centre ကနေ Data အသွင်း/အထုတ်လုပ်တဲ့ အခါ ကုန်တဲ့ ကုန်ကျစားရိတ်ပဲဖြစ်ပါတယ်။ Data ပမာဏပေါ်မှာ မူတည်ပြီးတော့ ကုန်ကျစားရိတ်ကွဲပြားသလို ကျွန်တော်တို့ RDS instance ရှိတဲ့ Region ပေါ်မှာ မူတည်ပြီးတော့လဲ ကုန်ကျစားရိတ်နှုန်းထားတွေ ကွဲပြားပါတယ်။

Data အသွင်း/အထုတ်ကို Inbound Data Transfer နဲ့ Outbound Data Transfer လို့ သတ်မှတ်ပါတယ်။

အတွင်းသို့ ဒေတာ ကူးပြောင်းခြင်း(Inboud Data Transfer) - အင်တာနက်ကနေ သို့မဟုတ် အခြားသော AWS Region မှာရှိတဲ့ Services တွေ (ဥပမာ- App တင်ထားတဲ့ EC2 instance လိုမျိုး) ကနေ မိမိရဲ့ RDS ထဲကို ဝင်လာတာမျိုးကို ဆိုလိုတာပါ၊
အပြင်သို့ ဒေတာ ပို့ဆောင်ခြင်း (Outbound Data Transfer) - မိမိရဲ့ RDS instance ကနေ အင်တာနက် သို့မဟုတ် အခြားသော AWS Region မှာရှိတဲ့ services တွေဆီကို Data တွေ ပို့ဆောင်ပေးခြင်းပဲဖြစ်ပါတယ်၊

အဓိကကတော့ ဘယ် နှ GB ပို့ဆောင်တယ် လက်ခံတယ်ဆိုတာမျိုးပါပဲ AWS ရဲ့ Pricing Calculator မှာ အနီးစပ်ဆုံး တွက်ချက် ကြည့်လို့ရပါတယ်ခဗျာ။

အခြားသော ကုန်ကျနိုင်ချေရှိတဲ့ အပိုင်းတွေကတော့ မိမိတို့ရဲ့ RDS Database ကြီးကို Backup လုပ်တာတို့ Mutli-Az Deployment သုံးတာတို့ဆို အပိုကုန်ကျ စားရိတ်တွေရှိနိုင်ပါတယ်။

RDS Cost တွေသက်သာအောင် ဘယ်လိုလုပ်မလဲ?

မှန်ကန်တဲ့ RDS Instance type ကို ရွေးချယ်ပေးရပါမယ် -

ဆိုလိုချင်တာကတော့ မိမိတို့ရဲ့ applicaiton, website တွေအနေနဲ့ ဒေတာဘေ့စ် performance ဘယ်လောက်လိုလဲဆိုတာ ကောင်းကောင်းနားလည်ဖို့ လိုပါတယ်။ RAM ဘယ်လောက်လိုတယ် CPU ဘယ်လောက်လိုတယ် နောက်ပြီး ဘယ်လိုမျိုး workloads တွေအသုံးပြုမှာလဲ? သာမန် application တွေ အတွက်ပဲလား? အသွင်း/အထုတ်များတဲ့ transaction တွေများတဲ့ app မျိုးလား? ဒီလို app အမျိုးအစားပေါ်မူတည်ပြီး သုံးသင့်တဲ့ RDS Instace type ကို ရွေးချယ်ပေးရပါမယ်။

မှှန်ကုန်တဲ့ storage (SSD) အမျိုးအစားကိုလဲ ရွေးချယ်တတ်ဖို့လိုပါတယ် -

ကျွန်တော်တို့ RDS မှာ storage အဖြစ် အသုံးပြုမယ့် Disk က ဘယ်အတွက်သုံးမှာလဲဆိုတာကို နားလည်ပြီး သေချာရွေးချယ်ဖို့လိုပါတယ်။ ကျွန်တော်တို့ App က Input/Output များတဲ့ database လိုရင် provisioned IOPS ဖြစ်တဲ့ EBS Volume အမျိုးအစားကို အသုံးပြုရမှာဖြစ်သလို သာမန် app မျိုးအတွက်ဆိုရင် သာမန် EBS Volume အမျိုးအစားကို အသုံးပြုရမှာဖြစ်ပါတယ်။ ဒီ EBS Volume အမျိုးအစားပေါ်မှာ မူတည်ပြီးတော့လဲ သာမန်အတွက်ဆို စျေးသက်သာပြီး IOPS လိုအပ်တာမျိုးအတွက်ဆို ပိုက်ဆံ ပိုကုန်ကျစေမှာဖြစ်ပါတယ်။

RDS resources တွေကို အမြဲ စောင့်ကြည့်စစ်ဆေးခြင်းကိုလဲ ပြုလုပ်ဖို့လိုအပ်ပါတယ်-

အထူးသဖြင့် ကျွန်တော်တို့ ရွေးချယ် အသုံးပြုထားတဲ့ CPUတွေ RAMတွေ ဘယ်လောက်သုံးနေလဲ? ဥပမာ usage တွေက နည်းနေတယ်ဆိုရင် ကျွန်တော်တို့က လျော့သင့်ရင် လျော့ပြီး cost သက်သာအောင် ပြုလုပ်ဖို့လိုအပ်ပါတယ်။ Disk storage အတွက်လဲ ထိုနည်း၄င်းပါပဲ ခဗျာ။

အမြဲတမ်း အသုံးပြုစရာမလိုသော RDS Instance များကို ခဏရပ်ထားခြင်း -

အဓိကကတော့ Test လုပ်ဖို့အတွက် အသုံးပြုထားတာတို့ Developement အတွက် အသုံးပြုထားတဲ့ instance တွေဆိုရင် ကျွန်တော်တို့အနေနဲ့ အသုံးပြုစရာမရှိတဲ့ အချိန်တွေမှာ ရပ်ထားပြီး ကုန်ကျစားရိတ်ကို လျော့ချသင့်ပါတယ်ခဗျာ။ ဆိုလိုတာကတော့ ပိတ်ရက်မှာ အသုံးမပြုရဘူးဆို ပိတ်ရက်အတွက် schedule လုပ်ပြီး ရပ်တာမျိုး (Lambda နဲ့ လုပ်လို့ရ အချိန်ရရင် ရေးပေးပါမယ်)၊ ရုံးချိန်ပြင်ပမှာ အသုံးမပြုရင် ရပ်ထားတာမျိုးတို့ကို ပြုလုပ်ခြင်းအားဖြင့် ကုန်ကျစားရိတ်သက်သာအောင် လျော့ချလို့ရပါတယ်ခဗျာ။

နောက်တခုကတော့ ကျွန်တာ်အပိုင်း(၁)မှာ payment terms တွေနဲ့ပတ်သတ်ပြီး ပြောခဲ့တဲ့ အကြောင်းအရာထဲကမှ Reserve plan ဝယ်ယူပြီး လျော့စျေးတွေနဲ့တကွ သက်သာအောင် ပြုလုပ်ပေးလို့ရပါတယ်ခဗျာ။

သတိထားရမှာတော့ တစ်နှစ်စာ သို့မဟုတ် သုံးနှစ်စာ ဝယ်ယူရတာမျိုးဖြစ်တဲ့အတွက် မိမိအသုံးပြုဖို့လိုအပ်တဲ့ instance အမျိုးအစား capacity ဘယ်လောက်လဲဆိုတာမျိုး တိတိကျကျ သိပြီး ဝယ်ယူသင့်ပါကြောင်း အကြံပေးရင်းနဲ့ပဲ အပိုင်း(၂) ကို ဒီမှာပဲ ရပ်နားလိုက်ရပါတယ်ခဗျာ။

ကျွန်တော်ရဲ့ မျှဝေခြင်းတွေက အထောက်အကူပြုခဲ့ရင်တော့ dev.to မှာအကောင့်ဆောက်ပြီး Like, Comment လေးတွေ လုပ်ပေးကြပါအုံးခဗျာ။
မိမိတို့ရဲ့ social media မှာလဲ share လုပ်ပေးလို့ရပါတယ်ခဗျာ

အားလုံးကို ကျေးဇူးတင်စွာဖြင့်
Kaung Thant Lwin (aka) DevKTOps
AWS Community Builder
Myanmar

What is AWS RDS and RDS Pricing?(Part-1) (In Burmese)

KaungThant Lwin — Sun, 19 Feb 2023 19:16:24 +0000

AWS ရဲ့ fully-managed ဒေတာဘေ့စ်ဆိုတာ ဘာလဲ?

ကျွန်တာ်ဒီနေ့ မျှဝေပေးသွားမှာကတော့ AWS ရဲ့ RDS ဆိုတဲ့ Service အကြောင်းပဲဖြစ်ပါတယ်။ RDS ဆိုတာကတော့ Relational Database Services ရဲ့အတိုကောက်ဖြစ်ပါတယ်။ ဒီ service ကတော့ AWS ရဲ့ fully-managed (မြန်မာလိုဆို AWS က အရာအားလုံး စီမံပေးထားတယ်လို့ပဲပြောရမှာပေါ့လေ) အကုန်လုံးကို စီမံ, ထိန်းချုပ်ပေးထားတဲ့ service တခုလဲ ဖြစ်ပါတယ်။ အဓိကကတော့ Developer တွေရဲ့ Business တွေကလိုအပ်တဲ့ ဒေတာဘေ့စ်တွေကို အလွယ်တကူ တည်ဆောက်လို့ရမယ်၊ အလွယ်တကူ scale up/scale down လုပ်လို့ရမယ်၊ ကျွန်တော်တို့အနေနဲ့ နောက်ကွယ်က infra ကို ဂရုစိုက်စရာမလိုပဲ အချိန်တိုအတွင်းမှာ လိုအပ်တာတွေကို ပြုလုပ်လို့ရနိုင်တာပဲဖြစ်ပါတယ်။

RDS မှာ ဘယ်လို ဒေတာဘေ့စ် အမျိုးအစားတွေကို တည်ဆောက်လို့ရနိုင်လဲ?

RDS မှာ ကျွန်တော်တို့အနေနဲ့ အသုံးများတဲ့ အောက်ပါ ဒေတာဘေ့စ် အမျိုးအစားတွေကို ရွေးချယ် အသုံးပြုနိုင်ပါတယ်။

MySQL
PostgreSQL
MariaDB
Oracle နဲ့
Microsoft SQL server တို့ပဲဖြစ်ပါတယ်။

RDS ရဲ့ အကျိုးကျေးဇူးများကတော့ အောက်ပါအတိုင်းဖြစ်ပါတယ်

၁. ကျွန်တော်တို့အနေနဲ့ အလွယ်တကူ တည်ဆောက်နိုင်ပြီးတော့ စီမံခန့်ခွဲရတာ လည်း လွယ်ကူစေပါတယ်။
၂. ကျွန်တော်တို့ လိုအပ်တဲ့ Storage နဲ့ compute capacity တွေကိုလည်း လိုအပ်ချက်အရ အတိုးအလျော့ လုပ်ဖို့လွယ်ကူစေပါတယ်။ ကိုယ်အသုံးပြုဖို့လိုအပ်တဲ့ specification ကို အလွယ်တကူ ရွေးချယ်ပြီး တည်ဆောက်နိုင်ပါတယ်။
၃. နောက်တခုကတော့ RDS က အလိုအလျောက် failover လုပ်ပေးတာမျိုး Replicaiton တွေ setup လုပ်ပေးတာမျိုးတွေ ပြုလုပ်ပေးခြင်းဖြင့် ကျွန်တော်တို့ အတွက် High Availability ကောင်းအောင် လုပ်ဆောင်ပေးပါတယ်။
၄. ကုန်ကျစရိတ်အနေနဲ့တော့ pay-as-you-go (သုံးသလောက်ပေး) ဖြစ်တဲ့အတွက် ကျွန်တော်တို့ အသုံးပြုတဲ့ capacity တွေ run time တွေ အတွက်သာ ပိုက်ဆံပေးရမှာဖြစ်ပါတယ်။

RDS ရဲ့ ပိုက်ဆံကုန်ကျမှုကို တွက်ချက်ရမယ်ဆိုရင်တော့

ပိုက်ဆံကုန်ကျမှု မှာဆိုရင် အောက်ပါ အတိုင်း (၄) မျိုး ရှိပါတယ် -
၁. Instance Costs (Hourly rate)
၂. On-Demand or Reserved (Payment Plan)
၃. Storage (EBS-Volumes)(SSD လိုမျိုး hard disk လိုမျိုးကို ဆိုလို)
၄. Data Transfer(Bandwidth)

၁. Instance Cost (Hourly rate)

ဒီတခုကတော့ ကျွန်တော်တို့ရွေးချယ်လိုက်တဲ့ instance type အမျိုးအစားပေါ်မူတည်ပြီး တနာရီကို ဘယ်လောက်ကျမလဲဆိုတဲ့ အပေါ်မှာ တွက်ချက်ထားတာပဲဖြစ်ပါတယ်။ Instance type တွေအကြောင်းတော့ ကျွန်တော် နောက်မှ ရေးပေးပါအုံးမယ်။ ကျွန်တော်တို့အနေနဲ့ မိမိတို့ အသုံးပြုမယ့် Workload ပေါ်မှာ မူတည်ပြီး instance type တွေကိုရွေးချယ်ဖို့လိုပါတယ်။ အောက်ပါ AWS Calculator ကနေ Pricing အကြမ်းဖျဥ်းကို ကြည့်နိုင်ပါတယ်။ AWS Calculator Link : https://calculator.aws

ပုံထဲကလိုဆိုရင် ကျွန်တော်တို့အနေနဲ့ General Instnce type ထဲကဖြစ်တဲ့ db.m4.large(2 CPU x 8GB RAM x 30GB SSD) ရှိတဲ့ Mysql Database အမျိုးအစားကို $219.49 ကုန်ကျမှာဖြစ်ပါတယ်
Estimation Link : Estimation Link

ဒီနေရာမှာ Instance type အမျိုးအစားအလိုက် ပိုက်ဆံပေးရမယ့် amount ကလည်းကွဲပြားသွားနိုင်ပါတယ်။ High-performance instance type တွေဆိုရင် ပိုပြီးတော့ ပိုက်ဆံကုန်မှာ ဖြစ်ပါတယ်။

၂. On-Demand? (သို့မဟုတ်) Reserved?

ဒီနှစ်ခုကတော့ RDS ရဲ့ Instance တွေပေးချေဖို့ရမှာ အသုံးပြုလို့ရတဲ့ Pricing Models တွေပဲဖြစ်ပါတယ်။

On-demand - ကတော့ ကျွန်တော်တို့အနေနဲ့ instance ကို ခဏအသုံးပြုဖို့ စမ်းဖို့လည်းကောင်း၊အသုံးပြုရမယ့် Capacity အတိအကျမသိရသေးခင် အချိန်တွေမှာလည်းကောင်း၊ အလွယ်တကူ တည်ဆောက် လုပ်လို့လဲရ ဖျက်လို့လဲ ရ ဆိုတဲ့အခြေအနေမှာ လည်းကောင်း တနာရီကို ဘယ်လောက်ဆိုပြီး ပေးသုံးတာမျိုးပဲဖြစ်ပါတယ်၊ ၁၀ နာရီသုံးရင် တနာရီကို ဘယ်လောက်ဆိုတာနဲ့ မြှောက်ပြီး ၁၀ နာရီစာအတွက် ပေးရတာမျိုးဖြစ်ပါတယ်။
Reserved - ကတော့ ကျွန်တော်တို့အနေနဲ့ အသုံးပြုဖို့လိုတဲ့ capacity တိတိကျကျသိရပြီးတဲ့ အချိန်ကျရင် တစ်နှစ်စာ သို့မဟုတ် သုံးနှစ်စာ အသုံးပြုမယ်ဆိုပြီး commitment ပေးပြီး ပေးချေတာပဲဖြစ်ပါတယ်။
Reserved payment model ကိုအသုံးပြုခဲ့ရင်တော့ သိသိသာသာ ပိုက်ဆံပေးရတာ သက်သာမှာဖြစ်ပြီး သတိပြုစရာအနေနဲ့ကတော့ capacity တိုးဖို့လိုလာတာတော့ လျော့ဖို့လိုလာတာမျိုး ( instance type ချိန်းဖို့) တို့ဆိုရင်တော့ အလွယ်တကူ ချိန်းလို့မရနိုင်ပါဘူး၊ နောက်တခုကတော့ မသုံးခင်ကလည်း ကြိုတင်ပြီး ပိုက်ဆံပေးရတာမျိုးလည်းရှိပါတယ်ခဗျာ၊ တစ်နှစ်စာဆို တနှစ်စာအတွက် ပေးလိုက်ရတာမျိုးပါခဗျာ။
Storage - ဒီတခုကတော့ ကျွန်တော်တို့ သိထားတဲ့ SSD လိုမျိုး disk usage အတွက်ပေးချေရတာမျိုးပဲဖြစ်ပါတယ်။ အပေါ်က ကျွန်တော်ပြထားတဲ့ example မှာဆို 30GB SSD အတွက် အောက်ပါ အတိုင်းပေးချေရတာမျိုးဖြစ်ပါတယ်။

Storage မှာသုံးမျိုးရှိပြီးတော့ ကျန်တဲ့ Data Transfer အကြောင်းနဲ့ Cost Optimize ဘယ်လိုလုပ်မလဲဆိုတာကိုတော့ နောက်ထပ် အပိုင်း (၂) မှာ ဆက်လက်ဖော်ပြပေးပါမယ်ခဗျာ။

အားလုံကိုကျေးဇူးတင်ပါတယ်ခဗျာ။ တခုခုအကျိုးရှိခဲ့ရင်တော့ Like, Comment & Share လေးလုပ်ခဲ့ပေးပါအုံးခဗျာ

ကောင်းသန့်လွင် aka DevKTOps
AWS Community Builder
Myanmar

Ref :
AWS
AWS Fundamentals Blog

Deployment Method / Strategy in AWS (Burmese)

KaungThant Lwin — Mon, 09 Jan 2023 19:35:45 +0000

ဒီနေ့ Blog လေးမှာတော့ ကျွန်တော် လူသုံးများတဲ့ Deployment Method တွေနဲ့ AWS မှာရော ဘယ် Services တွေနဲ့ အသုံးချလဲဆိုတာကု ပြောပြပေးသွားမှာ ဖြစ်ပါတယ်။
အောက်ပါ Deployment Strategies တွေအကြောင်းကိုပြောပြသွားမှာ ဖြစ်ပါတယ်။

In-Place Deployments
Blue/Green Deployments
Canary Deployments
Linear Deployments
All-at-once Deployments

(၁)။ ပထမဦးစွာ In-Place Deployments အကြောင်းကို ပြောပြပါမယ်။ ဒီ
ဖြစ်စဥ်အတွင်းမှာတော့ ကျွန်တော်တို့ရဲ့ လက်ရှိ Run နေတဲ့ server ထဲမှာပဲ update ဖြစ်တဲ့ အရာတွေကို deploy လုပ်ခြင်းပဲဖြစ်ပါတယ်။ ဆိုလိုတာကတော့ server အသစ် infra အသစ်တွေမလုပ်ပဲနဲ့ လက်ရှိရှိနေပြီးသားဖြစ်တဲ့ server မှာပဲ update လုပ်ခြင်းဖြစ်ပါတယ်။ သူရဲ့ အားနည်းချက်ကတော့ ကျွန်တော့်တို့ရဲ့ app, website တွေက downtime ရှိပါတယ်။ ဒါကြောင့်မို့ zero downtime ဖြစ်ဖို့ လိုအပ်တဲ့ infra တွေအတွက်တော့ သုံးဖို့တော့မသင့်တော်ဘူးလို့ ယူဆမိပါတယ်။ Testing server, UAT server လိုမျိုးတွေအတွက်တော့ သုံးလို့ အဆင်ပြေမယ်လို့ ထင်ပါတယ်ခဗျာ။
AWS မှာတော့ အထက်ပါ In-Place Deployment ကို AWS CodeDeploy services နဲ့ AWS Elastic Beanstalk တို့မှာ ပြုလုပ်လို့ရပါတယ်ခဗျာ၊ အထူးသဖြင့်တော့ EC2 သို့မဟုတ် on-premise server တွေမှာ ပြုလုပ်ကြပါတယ်ခဗျာ။

(၂)။ နောက်တခုကတော့ တော်တော်များများ ရင်းနီးပြီးသားဖြစ်မယ့် Blue/Green Deployments ပဲဖြစ်ပါတယ်။ ဒီ deployment ကတော့ အပေါ်မှာ ပြောခဲ့တဲ့ In-Place မှာ ရှိနေတဲ့ challenges တချို့ကို ဖြေရှင်းပေးနိုင်လာပါတယ်။

အထက်ပါပုံကို ကြည့်လိုက်ရင်တော့ နားလည်သွားမယ်လို့ထင်ပါတယ်။ Blue Environment ဆိုတာက ကျွန်တော်တို့ရဲ့ လက်ရှိ Version 1 run နေတဲ့ Environment ဖြစ်ပြီးတော့ Green env ကတော့ ကျွန်တော်တို့ update လုပ်မယ့် Version 2 ကို run မယ့် Env ပဲဖြစ်ပါတယ်။ ဆိုလိုတာကတော့ deployment စလုပ်တာနဲ့ code အသစ် Version အသစ်က အသစ်ဖြစ်တဲ့ Green env မှာသွားပြီး Deploy လုပ်ပါလိမ့်မယ် Deploy လုပ်လို့ အားလုံးပြီးဆုံးသွားပြီ application လည်းကောင်းကောင်း run နေပြီဆိုတဲ့အခါကြရင်တော့ များသော အားဖြင့် ကျွန်တော်တို့ရဲ့ Load Balancer ကနေ point လုပ်ထားတာကို Blue Env ကနေ Green Env ကို ချိန်းလိုက်တဲ့ သဘောပါပဲခဗျ။ Production env ဖြစ်တဲ့ Green Env မှာ issues ရှိလာခဲ့ရင်လည်း အလွယ်တကူ Blue Envကို rollback လုပ်လို့လဲရနိုင်ပါတယ်ခဗျာ။ တကယ်လို့နောက်ထပ် update ရှိလာခဲ့ရင်တော့ Blue Env မှာ Deploy လုပ် အစစအရာရာ အဆင်ပြေရင် လက်ရှိ နောက်ဆုံး run နေတဲ့ Green Env ကနေ Blue Env ကို ချိန်းပေးလိုက်ရုံပေါ့ဗျာ။ ဒီ strategy ကိုတော့ Blue/Green deployment လို့ ကျွန်တော်တို့ မှတ်ယူနိုင်ပါတယ်ခဗျာ။ AWS BeanStalk မှာ ဒီ deployment ကို စမ်းကြည့်လို့ရပါတယ်ခဗျာ။ နောက်အခွင့်အခါသင့်ရင် tutorial ရေးပေးပါအုံးမယ်ခဗျာ။

(၃)။ အခုထပ်မံဆွေးနွေးမှာကတော့ Canary Deployments အကြောင်းပဲဖြစ်ပါတယ်။ Canary ကတော့ အပေါ်က ပြောခဲ့တဲ့ Blue/Green လို public မလုပ်ခင် Green env ကို အပြည့်အဝ internally စမ်းသပ်စစ်ဆေးတာမျိုးတော့မဟုတ်ပါဘူး။ သူအလုပ်လုပ်ပုံကတော့ အောက်ပါပုံလေးကို တချက်ကြည့်ပေးပါ။

အပေါ်က ပုံထဲကကို အရှင်းဆုံးပြောရမယ်ဆို ကျွန်တော်တို့ရဲ့ အသစ်ဖြစ်တဲ့ version ကို live user (production users) အနည်းငယ်ကို စမ်းသပ်အသုံးပြုခိုင်းခြင်းပဲဖြစ်ပါတယ်။ တကယ်လို့ အဆင်မပြေတာတွေရှိရင်တော့ ပြန်ပြီး roll back လုပ်ပေါ့ (ဥပမာ- apple ရဲ့ developer beta program) လိုမျိုးနဲ့ ဆင်တူနိုင်မယ်ထင်ပါတယ်။ Version အသစ်ကို တကယ့်လက်တွေ့အသုံးပြုနေတဲ့ public users တွေကနေ သုံးကြည့်မယ် feedback တွေတောင်းမယ် တကယ်လို့ အားလုံးအဆင်ပြေသွားပြီဆိုရင်တော့ ကျွန်တော်တို့ရဲ့ Version အသစ်ကြီးကို server တိုင်းမှာ roll out လုပ်လိုက်မယ်ဆိုတဲ့ အနေအထားပေါ့ဗျာ။ ဒီversion အသစ်မှာပါတဲ့ feature က customer တွေကြိုက်လား မကြိုက်လား စမ်းစစ်ကြည့်တာမျိုးပေါ့။ တချို့လည်း သတိထားမိတာမျိုးတွေရှိလောက်ပါတယ် "ကျွန်တော်တို့ facebook acc မှာဆိုရင်တောင်မှာ တချို့အကောင့်မှာ dark mode ရပြီး တချို့တွေမရသေးတာမျိုးတွေဆိုရင် ဒီ deployment strategy ကိုသုံးထားတယ်လို့ ထင်မိတာပါပဲ" ။

(၄)။ နောက်ထပ်တခုကတော့ Linear Deployment ပဲဖြစ်ပါတယ်။ ဒီတခုကတော့ အပေါ်က ပြောထားတဲ့ Canary နဲ့ နည်းနည်းဆင်တူပါတယ်။ သူကလည်း production users traffic % တခုကို version အသစ်ဖြစ်တဲ့ environment ကို ပို့ဆောင်ပေးတာမျိုးပါပဲ ကွဲသွားတဲ့တချက်ကတော့ ကျွန်တော်တို့အနေနဲ့ updated env ကို တူညီတဲ့ ဆတိုး ပမာဏ ဘယ်ချိန်မှာ ဘယ်လောက် ရွေ့မယ်ဆိုတာမျိုးဖြစ်သွားပါတယ်။ မြင်အောင်ပြောမယ်ဆိုရင် user 100 ရှိတယ်ဆိုပါစို့ env အသစ်ကို ၅ မိနစ်တခါ ၁၀ရာခိုင်းနှုန်းပို့နေတာမျိုးပေါ့ ၁၀ မိနစ်ဖြစ်သွားတဲ့အခါ ၂၀ ရာခိုင်နှုန်းသော users တွေက updated env ကို ရောက်ရှိနေပြီဖြစ်တယ်ဆိုတာမျိုးပေါ့ဗျာ။ AWS Lambda မှာဒီ options တွေ အသုံးပြုကြတာ များပါတယ်။

(၅)။ နောက်ဆုံးတခုအနေနဲ့ကတော့ *All-at-once Deployments ပဲဖြစ်ပါတယ်။
ဒီတခုကတော့ ခေါင်းစဥ်လိုပဲ တကြိမ်ထဲမှာပဲ လက်ရှိ run နေတဲ့ env တွေကို updated ဖြစ်သွားအောင် တခါထဲလုပ်လိုက်တာမျိုးဖြစ်ပါတယ်။ တကယ်လို့ သာ deployment failed ဖြစ်သွားခဲ့ရင်တော့ သေချာပါတယ် ကျွန်တော်တို့ရဲ့ SLA ကတော့ တိုင်ပတ်ပြီပဲဖြစ်ပါတယ်။ တော်တော်များများမှာတော့ သိပ်မသုံးကြတဲ့ deployment တခုပဲဖြစ်ပါတယ်ခဗျာ။

ဒီနေ့ကတော့ ဒီအကြောင်းအရာတွေကို ပြောပြခဲ့ပြီးဖြစ်လို့ နောက်ထပ် Rolling update, Immutable infrastructure, Pet & Cattle အစရှိသော deployment strategy ကိုလည်းနောက်ထပ် blog post တခုမှာ ဖော်ပြနိုင်ဖို့ ကြိုးစားနေပါအုံးမယ်ခဗျာ။

သဘောကြနှစ်သက်ရင်တော့ follow, like ပြုလုပ်ပြီး share လေးပါ လုပ်ပေးလို့ပါတယ်ခဗျာ။

အမှားပါပါ က ထောက်ပြပြီး နားလည်ပေးပါခဗျာ...

လေးစားစွာဖြင့်
Kaung Thant Lwin || DevKTOps
AWS Community Builder
Myanmar

Ref: https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/deployment-strategies.html

https://medium.com/4th-coffee/on-devops-24-deployment-strategy-in-place-all-at-once-rolling-update-blue-green-and-canary-c3dbe1672ec5

How to pass the AWS Solution Architect Associate Exam in Burmese Language - PART-1?

KaungThant Lwin — Sun, 17 Jul 2022 20:06:12 +0000

အားလုံး မင်္ဂလာပါခဗျာ...
ကျွန်တော် ဒီနေ့ မျှဝေပေးသွားချင်တဲ့အကြောင်းအရာလေးကတော့ AWS ရဲ့ Solution Architect Associate Exam နဲ့ပတ်သတ်ပြီး ဘယ်လိုမျိုး လေ့လာလို့ရမလဲဆိုတာကို ပြောပြပေးသွားမှာ ဖြစ်ပါတယ်။

ပထမဦးစွာ ဘယ်လိုမျိုးလူတွေဖြေသင့်လဲဆိုတော့
၁။ AWS Services တွေကိုနဲ့ပတ်သတ်ပြီး လက်တွေ့ ထိတွေ့မှုရှိတဲ့သူတွေအနေနဲ့ ဖြေလို့ရနိုင်ပါတယ်။
၂။ AWS Technology တွေကိုအသုံးချပြီး လိုအပ်တဲ့ solution ကို ပေးနိုင်တဲ့ အရည်အချင်းရှိတဲ့သူမျိုးတွေ ဖြေလို့ရနိုင်ပါတယ်။
၃။ AWS ရဲ့ Well-Architect Framework ကိုကောင်းကောင်းနားလည်ပြီး Solution ပေးနိုင်ရင် ဖြေလို့ရပါတယ်။
၄။ AWS ရဲ့ Global Infrastructure အကြောင်းကိုလည်း နားလည်ထားဖို့လိုပါတယ်။
၅။ AWS ရဲ့ Security Services တွေရဲ့ အခြေခံအကြောင်းအရာတွေ နဲ့ AWS ရဲ့ Traditional Services(Core Services) တွေနဲ့ ဆက်စပ်မှုတွေကို နားလည်ထားရင် ဖြေလို့ရနိုင်ပါတယ်။

အောက်ပါ အချက်အလက်တွေကတော့ လက်ရှိ exam မှာ မပါဝင်တဲ့အချက်အလက်တွေဖြစ်ပါတယ်။ ကျွန်တော်တို့အနေနဲ့
၁။ ရှူပ်ထွေးတဲ့ network architecture တွေကို ဒီဇိုင်းလုပ်ဖို့မလိုပါဘူး
၂။ အကောင့်များစွာကို စီမန့်ခန့်ခွဲရတဲ့အကြောင်းအရာတွေ မပါဝင်ပါဘူး
၃။ လိုအပ်တဲ့ compliance နဲ့ ကိုက်ညီဖို့ လိုအပ်တဲ့ ဒီဇိုင်းတွေ လုပ်ဖို့ မလို်အပ်ပါဘူး
၄။ Deployment strategies တွေကိုလည်း လုပ်ဆောင်ဖို့ မလိုအပ်ပါဘူး
၅။ ရှူပ်ထွေးလှတဲ့ mutli-tier applications တွေအတွက်လည်း migration strategy တွေဖန်တီးဖိ်ု့ မလိုအပ်ပါဘူ:။

ကဲ ဒီတော့ အပေါ်မှာတော့ သိသင့်သိထိုက်တဲ့ အကြောင်းအရာတွေနဲ့ မလိုအပ်သေးတဲ့ အကြောင်းအရာတွေတော့ ပြောထားပြီးပါပြီ.. ဒီတော့ စာမေးပွဲပုံစံကိုပြောဖို့လိုအပ်လာပါပြီ.

စာမေးပွဲကတော့ အားလုံးလည်းသိထားပြီးမယ်ထင်ပါတယ် မေးခွန်းပုံစံနှစ်ခုရှိပါတယ်။

၁။ Multiple Choice (အဖြေမှန်တခုရွေးပြီး ကျန်တဲ့ သုံးခု သို့မဟုတ် လေးခုက အမှားပေါ့)
၂။ Multiple Response (အဖြေမှန် နှစ်ခု သို့မဟုတ် နှစ်ခုမက ရွေးပြီး ကျန်တာအမှားပေါ့)

ဒီလိုမျိုး မေးခွန်း ပေါင်း ၆၅ ခု ပါဝင်ပါတယ်။ ၆၅ ခုမှာ မေးခွန်း အခု ၅၀ ကသာ ဖြေဆိုသူတွေရဲ့ အရည်အချင်းကို အကဲဖြတ်အမှတ်ပေးမှာဖြစ်ပြီး ကျန်တဲ့ ၁၅ ခုကတော့ မိတ်ဆွေတို့ရဲ့ အမှတ်မှာ အကျူံးဝင်မှာ မဟုတ်ပါဘူး၊ နောက်စာမေးပွဲတွေမှာ မေးသင့်မမေးသင့်ဆုံးဖြတ်ဖို့ပဲထည့်သွင်းထားတာမျိုးပဲ ဖြစ်ပါတယ်။ ဒါပေမယ့် မေးခွန်း ၆၅ ပုဒ်စလုံးကိုတော့ တတ်နိုင်သမျှ မှန်ကန်အောင် ဖြေဖို့လိုပါလိမ့်မယ်ခဗျာ မိတ်ဆွေတို့အနေနဲ့ အမှတ်ယူ၊ မယူမသိနိုင်လို့ပါခဗျာ။ မဖြေခဲ့တဲ့ မေးခွန်းတွေအတွက်တော့ အမှားဖြစ်မှာပါ။

မေးခွန်းတွေကို အပိုင်း(၄) ခုနဲ့ ခွဲခြားထားပါတယ်။

အပိုင်း(၁)ကတော့ ကျွန်တော်တို့ အနေနဲ့ ၃၀% ထိမေးတဲ့ Resilient Architecture နဲ့ ပတ်သတ်ပြီး အောက်ပါအချက်အလက်တွေကို နားလည်ထားဖို့လိုအပ်ပါတယ် လေ့လာထားဖို့လို်အပ်ပါတယ်။

Multi-tier architecture solution နဲ့ပတ်သတ်ပြီး သိသင့်သိထိုက်တဲ့ AWS Services တွေ ပါဝင်တဲ့ Services တွေရဲ့ scaling ပိုင်းဆိုင်ရာတွေကို သိဖို့လိုပါတယ်။ နောက်ပြီးဘယ်လိုမျိုး Database အမျိုးအစားကို သုံးမလဲ ဘယ်လိုမျိုး compute instance types တွေကိုသုံးမလဲ ဆိုတာမျိုးတွေကို requirements ပေါ်မူတည်ပြီးရွေးချယ်ပေးဖိ်ု့ လိုအပ်ပါတယ်။

High Available ဖြစ်ဖို့ fault-tolerant ဖြစ်ဖို့ ဘာတွေလုပ်ဖို့လိုလဲ ဘယ်လ်ိုမျိုး AWS Services တွေကိုသုံးပြီး လုပ်လို့ရမလဲ? Sinle points of failuer ဖြစ်လာတဲ့အခါ ဘယ်လိုမျိုး HA ဖြစ်အောင် လုပ်ထားမလဲ ဆိုတာမျိုးတွေ နောက်ပြီး Disaster တခုဖြစ်လာခဲ့ရင်ရော ဘယ်လိုမျိုးတွေ လုပ်မလဲဆိုတာမျိုးတွေ အစရှိသည်တို့ကိုနားလည်ထားဖို့လိုအပ်ပါတယ်။

Decoupling ဆိုတာဘာလဲ? ဘယ်လိုမျိုး AWS Services တွေက Decoupling ဖြစ်ဖို့ ကူညီပေးနိုင်မလဲဆိုတာမျိုးတွေ နောက်ပြီး Serverless technology နဲ့ပတ်သတ်တဲ့ သိသင့်သိထိုက်တဲ့ အခြေခံသဘောတရားတွေကို နားလည်ထားဖို့လိုပါတယ်။

နောက်တခုကတော့ Resilient storage နဲ့ပတ်သတ်ပြီး data တွေကိုဘယ်လိုမျိုး သိမ်းဆည်းမလဲ ဘယ် services တွေကတော့ hybrid cloud environment တွေမှာသုံးလို့ရမလဲဆိုတာမျိုးတွေ ကို သိထားရပါမယ်။ appliciton ရဲ့ requirements ပေါ်မူတည်ပြီး ဘယ်လိုမျိုး data နဲ့ပတ်သတ်တဲ့ services တွေသုံးလို့ရမလဲဆိုတာမျိုးတွေ နားလည်နေရပါမယ်။

အပိုင်း(၂) ကတော့ ၂၈% ထိမေးတဲ့ High Performance Architectures နဲ့ ပတ်သတ်တဲ့ အချက်အလက်တွေဖြစ်ပါတယ်။

လိုအပ်တဲ့ လိုအပ်ချက်တွေအရ ဘယ်လိုမျိုး compute power ကိုသုံးမလဲ ဘယ်လိုမျိုး storage services တွေကိုသုံးမလဲ နောက်ပြီး လိုအပ်တဲ့ performance နဲ့ကိုက်ညီဖို့ ဘယ်လိုမျိုး scaling တွေလုပ်မလဲ ဘယ် services တွေက ဘယ်လို scaling တွေလုပ်လို့ရလဲဆိုတာမျိုးတွေ သိထားရပါမယ်။ နောက်ထပ်ကတော့ ဒီ performance တွေကို ဘယ်လို monitor လုပ်မလဲဆိုတာမျိုးတွေပေါ့ဗျာ။

network connections တွေနဲ့ပတ်သတ်ပြီးတော့လည်း ဘယ်လိုမျိုး AWS နဲ့ connectivity လုပ်လို့ရမလဲ low-latency ရဖို့ဘယ်လိုမျိုး ဆားဗစ်တွေသုံးမလဲဆိုတာမျိုးတွေ သိထားရပါမယ်။ နောက်ပြီး performance အတွက် မရှိမဖြစ်လိုအပ်တဲ့ caching services တွေကို နားလည်ထားရပါမယ်။ နောက်ပြီး migration တွေ ingestion တွေအတွက် သင့်တော်တဲ့ data transfer services တွေကိုသိဖိ့လုအပ်ပါတယ်။

database နဲ့ပတ်သတ်ပြီး ဘယဉ်လိုမျိုး scaling လုပ်လို့ရမလဲ ဘယ်လို sclaing options တွေရှိလဲဆိုတာမျိုး နောက်ပြီး database caching နဲ့ပတ်သတ်ပြီး ဘယ်လိုမျိုးလုပ်လို့ရနိုင်မလဲဆိုတာမျိုးတွေ performance အရလိုအပ်တဲ့ သင့်တော်တဲ့ database services တွေကိုလည်း နားလည်ထားဖို့လိုပါတယ်။

အပိုင်း(၃) ကတော့ ၂၄% ထိမေးတဲ့ Secure Applications and Architectures ဆိုတဲ့အပိုင်းပါ။

ကျွန်တော်တို့အနေနဲ့ IAM ဆိုတာ ဘာလဲ? IAM Users, IAM Roles, IAM Groups ဘယ်လိုအလုပ်လုပ်လဲ ဘယ်လိုအချိန်မျိုးမှာ ဘယ်လိုသုံးလို့ရလဲ ဆိုတာမျိုးတွေ သိဖို့လိုတယ်။ နောက်ပြီး Access policy တွေနဲ့ ပတ်သတ်ပြီး နားလည်ထားရပါတယ် နောက်ပြီး root account ဆိုတာ ဘာလဲ IAM နဲ့ဘာကွာလဲ root account ကိုဘယ်လို လုံခြုံအောင်ထားမလဲဆိုတာမျိုးတွေ နားလည်ဖို့လိုပါတယ်။ နောက်ပြီးတော့ Credentials တွေကို ဘယ်လိုလုံခြုံအောင်လုပ်မလဲဆိုတာမျိုးတွေက အစပေါ့။ နောက်ပြီး ကျွန်တော်တို့ရဲ့ AWS resouces တွေကိုဘယ်လို trace လုပ်လို့ရလဲ? ဘယ်လိုမျိုး နည်းလမ်းတွေနဲ့ AWS APIs တွေကို လုံခြုံအောင် access လုပ်ကြမလဲ ဆိုတာမျိုးတွေ သိထားရပါမယ်။

နောက် တခုကတော့ ကျွန်တော်တို့ Applicaitons tiers တွေနဲ့ပတ်သတ်ပြီး ဘယ်လို လုံခြုံအောင် လုပ်မလဲဆိုတာတွေပါပဲ။ ဥပမာ- traffic တွေကိုဘယ်လို control လုပ်မလဲ? Security groups ကိုသုံးမလာ:? network ACLs တွေကိုသုံးမလား သူတို့တွေက ဘယ်လိုအလုပ်လုပ်တာလဲ ဘာတွေကွဲပြားသလဲဆိုတာမျိုးတွေပေါ့ဗျာ.. private subnets နဲ့ public subnets ကရော ဘာတွေလဲ ဘယ်ချိန်မှာ ဘယ်လိုသုံးမလဲဆိုတာမျိုးတွေပေါ့။ Amazon VPC ကိုရော ဘယ်လိ်ုမျိုး လုံခြုံအောင်ထားမလဲ access points တွေကိုရော ဘယ်လိုမျိုး လုံလုံခြုံခြုံ route လုပ်ကြမလဲဆိုတာမျိုးတွေ နားလည်ထားဖို့လိုပါတယ်။ နောက်ထပ်ကတော့ ပြင်ပက ဝင်ရောက်လာနိုင်တဲ့ threats တွေကိုရော ကာကွယ်နိုင်ဖို့ AWS ရဲ့ ဘယ် services တွေကို သုံးလို့ရလဲဆိုတာမျိုးတွေကို သိထားရပါမယ်။

နောက်တခုကတော့ Data Security နဲ့ပတ်သတ်ပြီး objects တွေကိုဘယ်လိုမျိုး access policies တွေထားမလဲ? ဘယ်လိုမျိုး access patterns တွေထားမလဲ နောက်ပြီး data ကို at rest မှာ encrypt မလား in transit မှာ encrypt မှာလား ဆိုတာမျိုးတွေ နောက်ပြီး key တွေကို ဘယ်လိုမျိုး manage လုပ်မလဲဆိုတာမျိုးတွေကို လိုအပ်ချက်တွေပေါ် မှာ ဆုံးဖြတ်နိုင်ဖို့ အကောင်းဆုံး သော solution ကိုပေးနိုင်ဖို့ လိုအပ်ပါတယ်။

အပိုင်း(၄) အနေနဲ့ကတော့ ၁၈% မေးတဲ့ Cost Optimization နဲ့ပတ်သတ်တဲ့ အကြောင်းအရာတွေပဲဖြစ်ပါတယ်။

ကျွန်တော်တို့အနေနဲ့ စျေးသက်သာတဲ့ Storage solution တွေကိုနားလည်ထားဖို့လိုပါတယ်။ data တွေကို ဘယ်လိုမျိုး storage services မှာ သိမ်းပြီး သုံးမှာလဲ? ဘယ်လိုမျိုးဆို စျေးသက်သာမလဲဆိုတာမျိုးပေါ့ဗျာ နောက်တခုကတော့ စျေးသက်သာဖို့ အသုံးမများတဲ့ data တွေကို ဘယ်လိုမျိုး automate လုပ်ပြီး စျေးသက်သာတဲ့ services ဆီပြောင်းမလဲဆိုတာမျိုးတွေပေါ့။

နောက်တခုကတော့ အရေးကြီးတဲ့ EC2 service နဲ့ပတ်သတ်ပြီး ကျွန်တော်တို့ က ဘယ်လိုမျိုး Billing options တွေရှိလဲ? နောက်ပြီး Database မှာဆိုလဲ ဘယ်လို options တွေရှိလဲ? cost သက်သာဖို့ ဘယ်လိုမျိုး scaling options တွေလုပ်ထားလို့ရမလဲ (ဥပမာ schedule လုပ်ထားတာမျိုး) နောက်ပြီး ကျွန်တော်တို့ ရဲ့ workload နဲကိုက်ညီတဲ့ instance type, instance size ကိုသုံးပေးတာမျိုးတွေပေါ့ဗျာ

နောက်တခုကတော့ ကျွန်တော်တို့ network တွေမှာရှိတဲ့ data transfer cost တွေကို ဘယ်လိုလျော့ချမလဲ? နောက်ပြီး ဘယ်လိုမျိုး AWS နဲ့ ကျွန်တော်တို့ local data centers တွေကြားမှာရှိတဲ့ connectivity cost တွေကို လျော့ချလို့ရမလဲ ဘယ်လိုမျိုးသက်သာအောင် လုပ်လို့ရမလဲဆိုတာမျိုးတွေကို နားလည်ထားဖို့လိုပါတယ်။

ဒီအပိုင်းမှာတော့ ကျွန်တော့်အနေနဲ့ AWS Solution Architect Associate exam မှာပါတဲ့ မေးခွန်းပုံစံတွေနဲ့ သိထားသင့်တဲ့ အကြောင်းအရာလေးတွေကို ဦးစွာမျှဝေထားတာဖြစ်ပါတယ် နောက်အပိုင်းတွေမှာတော့ ဘယ်လိုမျိုး Services တွေကို ကြည့်ထားရမလဲ ဘယ်လိုမျိုး Study Resources တွေကို အသုံးပြုပြီး လေ့လာရမလဲဆိုတာမျိုးတွေကို ထပ်မံမျှဝေပေးသွားမှာဖြစ်ပါတယ်။

လေးစားစွာဖြင့်
Kaung Thant Lwin
DevKTOps
AWS Community Builder for Myanmar

ref: https://d1.awsstatic.com/training-and-certification/docs-sa-assoc/AWS-Certified-Solutions-Architect-Associate_Exam-Guide.pdf

How to use IAM Policy to allow creating specific EC2 instances?

KaungThant Lwin — Tue, 19 Apr 2022 07:46:57 +0000

Today I would like to share about IAM policy to control access while creating EC2 instances. Especially, I just using this for sharing IAM user access to my lab sharing "Thingyan AWS Lab" for our People, Myanmar.

Because, I just want them to use free tier only cause they are 1st time trying to create EC2 instance. So I just using IAM policy as the following one.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "s3:*", "cloudfront:*", "cloudwatch:*", "elasticloadbalancing:*", "iam:CreateServiceLinkedRole" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestedRegion": "ap-southeast-1" } } }, { "Effect": "Deny", "Action": "ec2:*", "Resource": "*", "Condition": { "ForAnyValue:StringNotLike": { "ec2:InstanceType": [ "t2.micro" ] } } } ] }

First statement path is for allowing EC2, S3, CloudFront, Cloudwatch, Elasticloadbalancing, to access these services within specific AWS Region (ap-southeast-1 - Singapore). I would like to create services in singapore region only.
{ "Effect": "Allow", "Action": [ "ec2:*", "s3:*", "cloudfront:*", "cloudwatch:*", "elasticloadbalancing:*", "iam:CreateServiceLinkedRole" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestedRegion": "ap-southeast-1" } } },

Second statement is to allow only to create t2.micro EC2 instance. So, I like to use the condition that the requested instance type is not like t2.micro, it will deny everything. That is all and please check the following step by steps.

First step is creating IAM policy.
Go to IAM Policy Page

And click on create policy and I will create the custom policy with json

paste the above policy json code to this and after this please click on Next Tags

If you want to add tags, you can add and if not, you can click on Next:Review,

You have to add the policy name and description and check the policy summary.

If everything is looking fine, you can go ahead to create policy.

After creating policy you have to create IAM User Groups at

Click on create group and add the IAM and attach the policy you created before.

After everything is complete, your IAM user can only access to the services within specific AWS region.