OpenTech by Phue

AWS - Common Data Transfer Cost
- - -

Architecture ဆွဲတဲ့အခါ service fee နဲ့ compute fee တွေကိုသာမက၊ ကိုယ် Workload ပေါ်မူတည်ပြီး data transfer cost တွေကိုပါ ထည့်သွင်းစဥ်းစားသင့်ပါတယ်။

AWS SAA Exam မှာလဲ Domain 4 မှာ Design Cost-Optimized Architectures ဆိုပြီး 20% အထိ ထည့်သွင်းထားတာမို့ အချိန်ရရင် AWS documentation နဲ့ Pricing Calculator ကိုသွားပြီး အသေးစိတ် လေ့လာထားပြီး ရင်းနီးအောင် လုပ်ထားသင့်ပါတယ်။

၁။ AWS နှင့် Internet ကြား Data Transfer Cost
--
Inbound (Ingress) ဆိုတာက အပြင်ဘက် Internet ကနေ AWS ထဲကို ဝင်လာတဲ့ Data ဖြစ်ပါတယ်။ အများအားဖြင့် AWS Inbound Data Transfer ဟာ Free ဖြစ်ပါတယ်။

(ဥပမာအနေနဲ့ သုံးစွဲသူတွေက Web Application ကို File Upload လုပ်တာ၊ API Request တွေ AWS Server ဆီ ပို့လာတာတွေကို Inbound Traffic လို့ခေါ်နိုင်ပါတယ်။)

Outbound (Egress) ဆိုတာက AWS ထဲကနေ အပြင်ဘက် Internet ဆီ Data ပြန်ထွက်သွားတာကို ဆိုလိုပါတယ်။ ဒီ Outbound Data Transfer ဟာ အများအားဖြင့် ကုန်ကျစရိတ်ရှိ ပါတယ်။

(ဥပမာအနေနဲ့ User တွေဆီ Web Page, Image, Video File တွေကို ပြန်ပို့ပေးတာ၊ S3 Bucket ထဲက Object တွေကို Internet ကနေ Download လုပ်တာတွေဟာ Outbound Traffic ဖြစ်ပါတယ်။)

E-commerce လို usage မျိုးမှာတော့ Amazon CloudFront ကို အသုံးပြုကာ Outbound Data Transfer ပမာဏကို လျော့ချနိုင်ပါတယ်။ CloudFront က Edge Location တွေမှာ Content ကို Cache လုပ်ထားပေးတာကြောင့် User Request တွေကို Origin (ဥပမာ S3 သို့မဟုတ် ALB) ဆီ မသွားဘဲ Edge Location ကနေပဲ Response ပေးနိုင်ပါတယ်။ ဒါကြောင့် Origin မှ ထွက်တဲ့ Outbound Data Transfer ပမာဏကို လျော့ချနိုင်ပြီး Cost Optimize ဖြစ်ပါတယ်။

၂။ AWS အတွင်း Data Transfer Cost (Intra-AWS Data Transfer)
--
(က) Workload နှင့် အခြား AWS Services များကြား Data Transfer
-
Single Region အတွင်း မှာ Internet Gateway ကို ဖြတ်သွားတဲ့ Traffic အတွက် Data Transfer Fee မရှိပါဘူး။
ဒါပေမယ့် Private Subnet ထဲမှာရှိတဲ့ resource တွေက NAT Gateway မှတဆင့် ဖြတ်သွားတဲ့ အတွက်တော့ Per-GB Data Processing Charge ကျပါတယ်။

Inter-Region Data Transfer ဆိုတာက Region တစ်ခုကနေ တစ်ခုဆီ Data ပို့တဲ့အခါ ကုန်ကျတဲ့ Fee ဖြစ်ပါတယ်။ Source Region နဲ့ Destination Region ပေါ်မူတည်ပြီး GB အလိုက် charge မတူနိုင်ပါဘူး။
(ဥပမာ us-east-1 ကနေ ap-southeast-1 ကို Data ပို့ရင် Inter-Region Data Transfer Charge ကျပါမယ်။)

အဲ့အတွက် Private Subnet ထဲကနေ Amazon S3 သို့မဟုတ် DynamoDB ကို Access လုပ်ချင်ရင် VPC Gateway Endpoint ကို အသုံးပြုနိုင်ပါတယ်။ VPC Endpoint ကို သုံးလိုက်တဲ့အခါ Traffic က AWS ရဲ့ Private Network ထဲမှာပဲ လည်ပတ်သွားပြီး NAT Gateway ကို မဖြတ်ရတော့သလို Internet ထွက်စရာလည်း မလိုတော့ပါဘူး။

(ခ) Workload Components အကြား Data Transfer
-
Availability Zone (AZ) တစ်ခုအတွင်း မှာရှိတဲ့ Resource တွေအကြား Data Transfer ဟာ Free ဖြစ်ပါတယ်။ (ဥပမာ us-east-1a ထဲမှာရှိတဲ့ EC2 Instance နှစ်ခုကြား Data Transfer ဖြစ်ပါတယ်။)

မတူညီသော Availability Zone များကြား (Cross-AZ) Data Transfer အတွက်တော့ per GB နှုန်းနဲ့ ကုန်ကျစရိတ်ရှိပါတယ်။
(ဥပမာ EC2 (AZ A) နဲ့ EC2 (AZ 😎 ကြား၊ EC2 (AZ A) နဲ့ RDS (AZ 😎 ကြား Data Transfer မျိုးကိုဆိုလိုတာဖြစ်ပါတယ်။)

RDS Multi-AZ Deployment မှာဆိုရင် Primary နဲ့ Standby Instance ကြား Replication Traffic အတွက်တော့ User ဘက်က Data Transfer Fee မပေးရပါဘူး။

ဒါပေမယ့် Application Server (EC2) က RDS Primary Instance နဲ့ မတူညီတဲ့ AZ မှာရှိနေပြီး Database ကို Access လုပ်တဲ့အခါ၊ အဲဒီ Application Traffic အတွက်တော့ Cross-AZ Data Transfer Charge ကျသင့်ပါတယ်။

အချိန်ရရင် အောက်က aws blogsလေးထဲမှာ ဖတ်နိုင်ပါတယ်။ တကယ်လဲ အသုံး၀င်ပါတယ်။

https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/

AWS Security Group & NACL ကိုတွဲသုံးတဲ့အခါ Traffic Flow, Stateful vs Stateless, Best Practice

AWS Cloud Networking မှာ Security Group (SG) နဲ့ Network Access Control List (NACL) ကိုအတူသုံးတဲ့အချိန် Traffic Flow, Stateful/Stateless လုပ်ဆောင်ချက်၊ Best Practice စတာတွေကိုနားလည်ထားရင် Security အတွက်လဲ အဆင်ပြေသလို Troubleshooting လဲ လွယ်ကူစေပါတယ်။

၁. SG & NACL Traffic Flow
Client တစ်ယောက်က EC2 Instance ဆီ Traffic ပို့တဲ့အချိန်မှာ AWS အတွင်း Flow က အောက်ကအတိုင်း ဖြစ်ပါတယ်။

Inbound Flow:
Client → NACL → Security Group → EC2

Outbound Flow:
EC2 → Security Group → NACL → Internet

ဆိုတော့ NACL က Subnet Layer မှာ first gatekeeper အဖြစ်လုပ်ဆောင်ပြီး, SG က Instance Layer မှာ last gatekeeper အဖြစ် Instance ထဲကို ဝင်လာမယ့်/ထွက်သွားမယ့် traffic ကို filter လုပ်ပေးတာပါ။

၂. Stateful vs Stateless Impact

SG က Stateful ဖြစ်တဲ့အတွက် Inbound rule တစ်ခု Allow လုပ်ထားရင် Return traffic ကို AWS က auto allow လုပ်ပေးတာကြောင့် Outbound reply route အတွက် rule အသစ်ထည့်ပေးဖို့မလိုပါဘူး။

NACL က Stateless ဖြစ်တဲ့အတွက် Inbound traffic ကို Allow လုပ်ထားပေမယ့် Return traffic အတွက် Outbound rule ကိုလည်း explicit လုပ်ပေးရပါမယ်။ ဥပမာ - NACL Inbound → Port 22 Allow, NACL Outbound → Ephemeral Ports (1024–65535) မရေးထားရင် SSH connection က timeout ဖြစ်သွားမှာပါ။

ဒီ အချက်က Connection success အတွက် အရေးကြီးတဲ့အချက်ဖြစ်ပြီး, NACL ကို configure လုပ်တဲ့အချိန် သတိထားရမဲ့ အချက်တစ်ခုဖြစ်ပါတယ်။

၃. Best Practice

Production-level VPC setup မှာ NACL ကို Broad-Level Blacklist, SG ကို Service-Level Whitelist အနေနဲ့ configure လုပ်ရင် အဆင်ပြေပါတယ်။

NACL: Malicious IP ranges, Suspicious subnets စတာတွေကို Wide-level filtering လုပ်ပြီး Root-level Block/Allow လုပ်မယ်။

SG: Required ports, Trusted source IPs, Instance/Service-specific granular control တွေကို only allow လုပ်ပြီး Service-level access control ကို handle လုပ်မယ်။ ဒီ practice က Security ကိုကောင်းမွန်စေသလို၊ Maintainability အတွက်လည်း အထူးသင့်တော်ပြီး Troubleshooting လုပ်ရာမှာလည်း လွယ်ကူစေပါတယ်။





https://www.learndevopsnow-mm.blog/articles/aws-security-group-nacl--dec-5-2025/