Placement Group, ENI আর Hibernate

এই লেসন শেষে তুমি যা পারবে

• কোনো scenario পড়ে cluster, spread আর partition placement group-এর মধ্যে ঠিকটা বেছে নিতে পারবে, আর কোনটা কোন বিপদ থেকে বাঁচায় তা বুঝিয়ে বলতে পারবে।
• আসল সংখ্যাগুলো মনে রাখতে পারবে: spread group-এ প্রতি AZ-এ ৭টা running instance, partition group-এ প্রতি AZ-এ ৭টা partition, আর cluster group মানে একটাই AZ।
• placement group-এ “insufficient capacity” মানে কী আর তখন কীভাবে আবার চেষ্টা করতে হয়, সেটা বলতে পারবে; কখন precision time placement group বা Amazon Time Sync-ই উত্তর, সেটাও চিনতে পারবে।
• elastic network interface (ENI) কী, তার ভেতরে কী থাকে আর তার সীমা কোথায়, তা বোঝাতে পারবে; secondary ENI দিয়ে একটা private IP-কে standby instance-এ সরিয়ে failover করতে পারবে।
• ENI, ENA আর EFA আলাদা করে চিনতে পারবে।
• EC2 Hibernate কীভাবে stop-এর পরেও RAM ধরে রাখে, এর জন্য কী কী শর্ত লাগে, সেটা বলতে পারবে, আর ধীরে চালু হওয়া application-এর জন্য এটা বেছে নিতে পারবে।

#instance কোথায় বসল, সেটা নিয়ে মাথা ঘামাবে কেন

তুমি যখন একটা instance চালু করো, EC2 Availability Zone-এর কোথাও একটা physical server বেছে নিয়ে সেখানে বসিয়ে দেয়। সাধারণত এটাই ভালো: AWS তার hardware-এর ওপর instance-গুলো ছড়িয়ে রাখে, যাতে একটা server বা একটা rack নষ্ট হলে যত কম সম্ভব customer-এর ক্ষতি হয়।

কিন্তু কিছু application-এর জন্য এই স্বাভাবিক ব্যবস্থাটা ঠিক খাটে না:

• একটা high performance computing (HPC) job, বা এমন big data job যেখানে সব server একে অপরের ওপর নির্ভর করে, চায় তার instance-গুলো যত কাছাকাছি সম্ভব থাকুক, যাতে নিজেদের মধ্যে সবচেয়ে কম latency আর সবচেয়ে বেশি bandwidth-এ কথা বলতে পারে।
• হাতে গোনা কয়েকটা জরুরি server (দুটো database node, তিনটা domain controller) যেন কখনো একই rack-এ না থাকে, যাতে hardware-এর একটা গোলমালে দুটো একসাথে না পড়ে।
• Kafka, Cassandra বা HDFS-এর মতো বড় distributed system চায় তার node-গুলো rack-এর দলে দলে ভাগ হয়ে থাকুক, আর কোন node কোন দলে আছে সেটা সে জানুক, যাতে data-র কপিগুলো আলাদা দলে রাখতে পারে।

তুমি কোনটা চাও, সেটা EC2-কে জানানোর উপায় হলো placement group। একটা strategy দিয়ে group বানাও, তারপর তার ভেতরে instance launch করো। placement group-এর জন্য কোনো টাকা লাগে না; টাকা দাও শুধু instance-এর।

#Placement group

#Cluster: যত কাছে সম্ভব

cluster placement group instance-গুলোকে একটা Availability Zone-এর ভেতরে, AWS network-এর একই high-bandwidth অংশে, গায়ে গায়ে বসায় (প্রায়ই একই rack-এ, নয়তো পাশের rack-এ)।

• লাভ: instance-গুলোর মধ্যে latency সবচেয়ে কম, প্রতি সেকেন্ডে packet সবচেয়ে বেশি। enhanced networking থাকলে group-এর দুটো instance-এর মধ্যে একটা TCP flow 10 Gbps পর্যন্ত যেতে পারে; cluster group-এর বাইরে একটা flow-এর সীমা 5 Gbps। মোট bandwidth কত হবে, সেটা ঠিক করে instance type (বড় type-গুলোতে 100 Gbps বা তারও বেশি)।
• ঝুঁকি: সবকিছু এক জায়গায়। ভাগাভাগি করা hardware নষ্ট হলে, আর AZ নষ্ট হলে তো অবশ্যই, group-এর সব instance একসাথে বন্ধ হয়ে যেতে পারে।
• কাজে লাগে: HPC, একে অপরের ওপর নির্ভর করা big data job যেগুলো দ্রুত শেষ করতে হবে, আর যেসব application-এর বেশিরভাগ traffic group-এর instance-গুলোর নিজেদের মধ্যেই যায়।

এর থেকে সবচেয়ে বেশি সুবিধা পেতে:

• সব instance একটা request-এই চালু করো, আর সবগুলো একই instance type-এর রাখো। পরে instance যোগ করলে বা type মিশিয়ে ফেললে insufficient capacity error-এর সম্ভাবনা বাড়ে।
• enhanced networking আছে এমন instance type নাও (ENA, আর HPC হলে EFA; দুটোই নিচে আছে)। T2/T3-এর মতো burstable type cluster group-এ চলে না।
• জায়গা পাক্কা করে রাখতে চাইলে cluster placement group-এর ভেতরে একটা On-Demand Capacity Reservation বানাও।
• দুটো instance-এর মধ্যে গতি কত হবে, তা ঠিক করে দুজনের মধ্যে যেটা ধীর সেটা।

#Spread: প্রত্যেক instance আলাদা hardware-এ

spread placement group প্রতিটা instance-কে আলাদা hardware-এ বসায়: আলাদা rack, যার power আর network নিজস্ব।

• লাভ: hardware-এ একটা গোলমাল হলে group-এর বড়জোর একটা instance-এর ক্ষতি হয়।
• সীমা: প্রতি group-এ, প্রতি Availability Zone-এ সর্বোচ্চ ৭টা running instance। spread group একই Region-এর কয়েকটা AZ জুড়ে থাকতে পারে, তাই ৩টা AZ-ওয়ালা Region-এ একটা group-এ ২১টা running instance রাখা যায় (প্রতি AZ-এ ৭টা করে)।
• কাজে লাগে: অল্প কয়েকটা জরুরি instance, যেগুলোকে আলাদা রাখতেই হবে: একটা primary আর একটা standby database, তিন বা পাঁচটা coordination node-এর cluster, দুটো license server।
• এখানে instance type মেশানো যায়, পরে পরে instance যোগও করা যায়, কারণ প্রতিটা নতুন instance-এর শুধু একটা খালি rack দরকার।
• spread group-এ Dedicated Instance চলে না। (AWS Outposts-এ host-level spread-ও আছে; Region-এ সবসময় rack-level।)

#Partition: rack-এর দল, যারা আলাদা আলাদা নষ্ট হয়

partition placement group তার instance-গুলোকে কয়েকটা partition-এ ভাগ করে। প্রতিটা partition পায় নিজের rack-এর সেট, আর দুটো partition কখনো একই rack ভাগ করে না। hardware নষ্ট হলে একটা partition-এর অনেক instance পড়ে যেতে পারে, কিন্তু অন্য partition-গুলোর গায়ে আঁচড়ও লাগে না।

• সীমা: প্রতি AZ-এ সর্বোচ্চ ৭টা partition। group একই Region-এর কয়েকটা AZ জুড়ে থাকতে পারে। instance কয়টা রাখা যাবে, তার সীমা শুধু তোমার account-এর EC2 quota, তাই শত শত instance খুবই স্বাভাবিক।
• কে কোথায়, দেখা যায়: প্রতিটা instance instance metadata থেকে নিজের partition নম্বর পড়তে পারে (placement/partition-number), আর API থেকেও দেখা যায় কোন instance কোন partition-এ।
• কাজে লাগে: বড় distributed আর replicated system, যারা topology বোঝে: HDFS, HBase, Cassandra, Kafka। তুমি system-টাকে বলে দাও প্রতিটা partition-কে একটা “rack” ধরতে, আর সে প্রতিটা data-র কপি আলাদা partition-এ রাখে।
• তুমি যতগুলো partition চেয়েছ, EC2 সেগুলোতে instance সমানভাবে ভাগ করার চেষ্টা করে, তবে গ্যারান্টি দেয় না। চাইলে নির্দিষ্ট একটা partition-এও launch করা যায় (PartitionNumber=2)।
• Dedicated Instance হলে partition group-এ সর্বোচ্চ ২টা partition।

#তিনটা strategy পাশাপাশি

#Precision time placement group আর Amazon Time Sync

distributed database, শেয়ার বাজারের trading বা event log প্রায়ই ঘটনাগুলো timestamp দেখে সাজায়। দুটো server-এর ঘড়ি যদি না মেলে, পরে লেখা data আগের বলে মনে হতে পারে আর জিতে যেতে পারে; রেকর্ডের ক্রম এলোমেলো হয়ে যায়।

প্রতিটা EC2 instance এমনিতেই, বিনা খরচে, Amazon Time Sync Service ব্যবহার করতে পারে:

• এটা link-local address 169.254.169.123-এ উত্তর দেয় (Nitro instance-এ IPv6-এ fd00:ec2::123), তাই এর জন্য Internet-এর দরকারই হয় না। Amazon Linux আপনা-আপনি এটাই ব্যবহার করে।
• এর পেছনে প্রতিটা Region-এ আছে satellite-এর সাথে যুক্ত আর atomic reference clock-এর একটা বহর।
• সমর্থিত instance type-এ Linux-এর জন্য একটা PTP hardware clock-ও থাকে, যেটা microsecond পর্যায়ের নির্ভুলতা দেয়।

সবচেয়ে নতুন strategy, precision time placement group, নিশ্চিত করে যে তোমার instance-গুলো এমন hardware-এ বসবে, যেখান থেকে এই উচ্চ-নির্ভুল সময়ের উৎসে সরাসরি পৌঁছানো যায়। এর instance-গুলো পায় আরও নিখুঁত local NTP উৎস, PTP hardware clock (শুধু Linux) আর hardware packet timestamping (শুধু Linux)। এর জন্য বাড়তি কোনো খরচ নেই। একটা cluster group চাইলে একটা precision time group-কে নিজের parent হিসেবে দেখাতে পারে; তাতে tightly coupled cluster-ও নিখুঁত সময় পায়।

#সব placement group-এর জন্য যে নিয়মগুলো খাটে

• একটা instance একবারে একটাই placement group-এ থাকতে পারে, আর দুটো group জোড়া লাগানো যায় না।
• চালু একটা instance-কে কোনো group-এ ঢোকাতে (বা বের করতে) হলে আগে stop করো, তার placement বদলাও (modify-instance-placement), তারপর আবার start করো।
• group-এর নাম একটা account-এর একটা Region-এ অনন্য হতে হয়।
• placement group-এর কোনো খরচ নেই।
• placement group-এর কোনো instance stop করে আবার start করলে সেটা group-এই থাকে, তবে ঠিক সেই মুহূর্তে মানানসই জায়গা না থাকলে start ব্যর্থ হয়।
• Capacity Reservation জায়গা আটকে রাখতে পারে শুধু cluster group-এ, spread বা partition-এ না। আর zonal Reserved Instance কোনো placement group-এই জায়গা আটকাতে পারে না।

#Insufficient capacity: মানে কী, আর তখন কী করবে

placement group প্রতিটা launch-এর সাথে একটা শর্ত জুড়ে দেয়। AZ-এ অনেক খালি server থাকার পরও EC2 তোমার request ফিরিয়ে দিতে পারে, কারণ সেগুলোর কোনোটাই group-এর নিয়ম মানে না:

তুমি যে error দেখবে সেটা InsufficientInstanceCapacity। এটা quota-র সমস্যা না: account-এর limit বাড়ালে এটা মেটে না।

#Elastic network interface (ENI)

elastic network interface (ENI) হলো একটা virtual network card, যেটা থাকে একটা VPC-র একটা subnet-এ। প্রতিটা instance-এ অন্তত একটা থাকে; instance-এর networking setting বলতে আসলে তার ENI-গুলোর setting-ই বোঝায়।

#একটা ENI-তে কী কী থাকে

#Primary আর secondary ENI

• primary ENI (device index 0, Linux-এ সাধারণত eth0) instance-এর সাথেই তৈরি হয়, আর কখনো খোলা যায় না।
• secondary ENI (eth1, eth2…) আলাদাভাবে বানানো যায়, তারপর লাগানো আর খোলা যায়। instance চলা অবস্থায় (hot attach), stopped অবস্থায় (warm attach), বা launch-এর সময় (cold attach), যেকোনো সময় লাগানো যায়।
• একটা instance-এ সর্বোচ্চ কয়টা ENI, আর প্রতি ENI-তে কয়টা IP, সেটা instance type-এর ওপর নির্ভর করে। ছোট type-এ হয়তো ২-৩টা ENI; সবচেয়ে বড় type-গুলোতে কয়েক ডজন।
• hot বা warm attach করা ENI Amazon Linux আর Windows Server নিজেরাই সেট করে নেয়; অন্য operating system-এ হয়তো তোমাকে নিজে interface চালু করে route ঠিক করতে হবে।

#ENI কোথায় যেতে পারে

• একটা ENI একটা subnet-এর, তাই সেটা ওই subnet-এর Availability Zone-এ বাঁধা। শুধু একই AZ-এর instance-এ এটা লাগানো যায়।
• instance-টা ওই AZ-এর অন্য subnet-এ থাকতে পারে, এমনকি একই account-এর অন্য VPC-তেও থাকতে পারে, যতক্ষণ AZ এক।
• দ্বিতীয় ENI লাগালে bandwidth দ্বিগুণ হয় না। bandwidth ঠিক করে instance type, card-এর সংখ্যা না।
• কোনো instance-এ একাধিক ENI থাকলে, stop আর start-এর পর তার আপনা-আপনি দেওয়া public IPv4 আর ফেরত আসে না। একাধিক ENI-ওয়ালা instance-এর স্থায়ী public address লাগলে Elastic IP ব্যবহার করো।

#ENI কী কাজে লাগে

• secondary ENI সরিয়ে failover। client-রা connect করে একটা secondary ENI-র private IP-তে (হয়তো একটা Elastic IP-তেও)। instance নষ্ট হলে ENI-টা খুলে একই AZ-এর একটা standby-তে লাগিয়ে দাও। standby তখন পায় একই private IP, একই MAC, একই security group আর একই Elastic IP; client-দের কিছুই বদলাতে হয় না।
• Dual-homed instance। একটা instance-এর একটা ENI production subnet-এ, আরেকটা management subnet-এ, প্রতিটার নিজের security group। যেমন একটা monitoring appliance, বা এমন server যেখানে admin-রা শুধু management network দিয়েই ঢোকে।
• MAC address-এর সাথে বাঁধা software license। license-টা একটা secondary ENI-তে রাখো, তাহলে instance বদলালেও license টিকে থাকে।
• network আর security appliance, যাদের প্রতিটা network-এর জন্য আলাদা একটা interface লাগে।

#ENI, ENA আর EFA

শুনতে প্রায় একই রকম তিনটা নাম:

পরীক্ষার shortcut: “MPI দিয়ে HPC, অনেক node-এর মধ্যে যোগাযোগ, OS bypass” → EFA (সাথে cluster placement group)। সাধারণ workload-এ “enhanced networking, বেশি bandwidth, কম latency” → ENA।

#EC2 Hibernate

#সাধারণ stop আর start-এ কী হয়

একটা EC2 instance stop করলে তার EBS volume থেকে যায়, কিন্তু RAM-এ যা ছিল সব মুছে যায়। আবার start করলে:

1. instance সাধারণত নতুন একটা physical host-এ চালু হয়।
2. operating system একদম শুরু থেকে boot হয়।
3. তোমার application চালু হয়, যাদের ওপর নির্ভর করে তাদের সাথে connect করে, আর cache গরম করে (data memory-তে তোলে, code compile করে, connection pool ভরে)।

(নতুন instance-এর একদম প্রথম start-এ ৩ নম্বর ধাপের আগে user data script-ও চলে; lesson 4.3-এ সেটা আছে।)

অনেক application-এর ৩ নম্বর ধাপেই কয়েক মিনিট লাগে, কখনো আরও অনেক বেশি, আর প্রথম দিকের user-রা একটা ধীর system দেখে।

#hibernate তার বদলে কী করে

EC2 Hibernate দিয়ে stop করা ঠিক ল্যাপটপ hibernate করার মতো:

1. তুমি EC2-কে বলো hibernation সহ stop করতে। instance চলে যায় stopping অবস্থায়।
2. EC2 operating system-কে suspend to disk করার সংকেত দেয়: সে সব process জমিয়ে দেয় আর RAM-এর পুরোটা root EBS volume-এর একটা ফাইলে লিখে রাখে। root volume encrypted, তাই সেভ করা memory-ও encrypted থাকে।
3. operating system বন্ধ হয়, instance হয়ে যায় stopped। তখন তুমি টাকা দাও EBS storage-এর (আর Elastic IP থাকলে তার), instance-এর না।
4. start করলে instance boot হয়, operating system root volume থেকে সেভ করা RAM আবার তুলে আনে আর process-গুলো আবার চালু করে দেয়। application ঠিক যেখানে ছিল সেখান থেকে চলতে থাকে, cache-ও গরম।

operating system আসলে restart হয়নি, তাই তার uptime যেখানে ছিল সেখান থেকেই গুনতে থাকে, আর অনেকক্ষণ ধরে চলা process-গুলো ভাঙে না। সাধারণ stop আর start-এর পর uptime আবার ০ থেকে শুরু হয়।

hibernation-এর আগে-পরে instance তার private IPv4 আর IPv6 address আর Elastic IP ধরে রাখে। আপনা-আপনি দেওয়া public IPv4 ছেড়ে দেওয়া হয়, start-এর সময় নতুন একটা আসে, ঠিক সাধারণ stop-এর মতো। instance store volume-এর data হারিয়ে যায়।

#hibernate ব্যবহারের শর্ত

#কখন ব্যবহার করবে

• অনেকক্ষণ ধরে চলা processing, যেটা মাঝে থামিয়ে আবার চালু করতে চাও, memory-তে জমা কাজ না হারিয়ে।
• যেসব service চালু হতে অনেক সময় নেয়: বড় in-memory cache, আগে থেকে data তুলে রাখা application, অনেকক্ষণ warm-up লাগা Java service।
• আগে থেকে গরম করা environment-এ খরচ বাঁচানো (যেমন test বা development instance), যেটা রাতে বন্ধ রাখো কিন্তু সকালে কয়েক সেকেন্ডে তৈরি চাও।

#সব মিলিয়ে: “big data fleet” scenario

অনেক পরীক্ষার প্রশ্নে একটা লাইন বারবার আসে: “You have an application performing big data analysis hosted on a fleet of EC2 instances.” মানে একটা server দিয়ে কাজ হচ্ছে না, তাই কয়েকটা instance-এর একটা দল মিলে কাজ ভাগ করে নিচ্ছে; যেমন লাখ লাখ user-এর log বিশ্লেষণ, machine learning model train করা বা genomics গবেষণা। প্রশ্নের শেষ লাইন বলে দেয় কোন অংশটা জানতে চাওয়া হচ্ছে:

#নিজে করে দেখো

# ১. প্রতিটা strategy-র একটা করে placement group
aws ec2 create-placement-group --group-name hpc-pg   --strategy cluster
aws ec2 create-placement-group --group-name crit-pg  --strategy spread --spread-level rack
aws ec2 create-placement-group --group-name kafka-pg --strategy partition --partition-count 3
aws ec2 create-placement-group --group-name time-pg  --strategy precision-time
aws ec2 describe-placement-groups --query "PlacementGroups[].[GroupName,Strategy,PartitionCount]"

# ২. group-এ launch: পুরো cluster এক request-এ, এক instance type-এ
aws ec2 run-instances --image-id $AMI --instance-type c7i.8xlarge --count 8 \
  --subnet-id $SUBNET_A --placement "GroupName=hpc-pg"
# ...আর partition group-এর partition 2-এ একটা Kafka broker
aws ec2 run-instances --image-id $AMI --instance-type m7i.xlarge --count 1 \
  --subnet-id $SUBNET_A --placement "GroupName=kafka-pg,PartitionNumber=2"

# ৩. broker-এর ভেতরে: instance metadata (IMDSv2) থেকে partition নম্বর পড়া
TOKEN=$(curl -sX PUT http://169.254.169.254/latest/api/token \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/placement/partition-number    # → 2

# ৪. ঘড়ি Amazon Time Sync (169.254.169.123) ব্যবহার করছে কিনা দেখা
chronyc sources -v

# ৫. স্থায়ী private IP-ওয়ালা একটা secondary ENI, eth1 হিসেবে লাগানো, তারপর standby-তে সরানো
ENI=$(aws ec2 create-network-interface --subnet-id $SUBNET_A --private-ip-address 10.0.1.50 \
  --groups $SG_APP --query NetworkInterface.NetworkInterfaceId --output text)
aws ec2 attach-network-interface --network-interface-id $ENI --instance-id $PRIMARY --device-index 1
ATT=$(aws ec2 describe-network-interfaces --network-interface-ids $ENI \
  --query "NetworkInterfaces[0].Attachment.AttachmentId" --output text)
aws ec2 detach-network-interface --attachment-id $ATT        # --force একদম শেষ উপায় হিসেবে
aws ec2 attach-network-interface --network-interface-id $ENI --instance-id $STANDBY --device-index 1

# ৬. Hibernate: launch-এর সময় চালু, root volume encrypted আর RAM ধরার মতো বড়
aws ec2 run-instances --image-id $AL2023_AMI --instance-type m7i.large \
  --hibernation-options Configured=true \
  --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"VolumeSize":30,"VolumeType":"gp3","Encrypted":true}}]'
aws ec2 stop-instances --instance-ids $ID --hibernate
aws ec2 start-instances --instance-ids $ID
uptime          # instance-এর ভেতরে: hibernation-এর আগের হিসাব থেকেই গুনছে

#সারসংক্ষেপ

মূল কথাগুলো

• placement group EC2-কে বলে দেয় instance-গুলো hardware-এ কীভাবে বসাতে হবে। এর কোনো খরচ নেই; scenario দেখে strategy বাছো।
• Cluster: একটা AZ, গায়ে গায়ে, সবচেয়ে কম latency, একটা flow-এ 10 Gbps, আর সব একসাথে নষ্ট হওয়ার ঝুঁকিও সবচেয়ে বেশি। সব instance একবারে, একই type-এ, enhanced networking সহ চালু করো। চেনার শব্দ: HPC, low latency, high throughput।
• Spread: প্রতিটা instance আলাদা hardware-এ, প্রতি group-এ প্রতি AZ-এ ৭টা running instance, কয়েকটা AZ জুড়ে হতে পারে। চেনার শব্দ: অল্প কয়েকটা জরুরি instance, যাদের আলাদা রাখতে হবে।
• Partition: প্রতি AZ-এ সর্বোচ্চ ৭টা partition, প্রতিটা নিজের rack-এ, শত শত instance, metadata-তে partition নম্বর। চেনার শব্দ: HDFS, HBase, Cassandra, Kafka।
• Insufficient capacity মানে এই মুহূর্তে group-এর নিয়ম মানে এমন hardware নেই: এক request-এ launch করো, পুরো cluster group stop করে start করে আবার চেষ্টা করো, অন্য AZ বা অন্য group নাও, নয়তো পরে চেষ্টা করো। এটা quota-র সমস্যা না।
• Precision time group instance বসায় উচ্চ-নির্ভুল সময়ের উৎসে সরাসরি পৌঁছানো যায় এমন hardware-এ; আর প্রতিটা instance বিনা খরচে 169.254.169.123-এ Amazon Time Sync ব্যবহার করতে পারে।
• ENI হলো virtual network card: primary আর secondary private IP, প্রতিটা private IP-র জন্য একটা Elastic IP, একটা public IP, security group, একটা MAC। এটা একটা AZ-এ বাঁধা। primary ENI কখনো খোলা যায় না; failover-এর জন্য secondary ENI standby-তে সরানো যায়। ENI কয়টা হবে, তা instance type-এর ওপর নির্ভর করে।
• ENA = enhanced networking; EFA = ENA, সাথে HPC/MPI-র জন্য OS bypass, cluster group-এর সাথে ব্যবহার হয়।
• Hibernate RAM লিখে রাখে encrypted root EBS volume-এ আর start-এর সময় ফিরিয়ে আনে, তাই process আর cache টিকে থাকে, uptime-ও চলতে থাকে। launch-এর সময় চালু করতে হয়; RAM 150 GB-এর কম (Linux), root volume যথেষ্ট বড়, ৬০ দিনের বেশি না, On-Demand আর Spot।

নিজেকে যাচাই করো: placement group, ENI আর hibernate৩০টি প্রশ্ন