EFS, আর EBS, EFS ও Instance Store-এর মধ্যে কোনটা নেবে

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

• block, file আর object storage-এর পার্থক্য বুঝিয়ে বলতে পারবে, আর কোনটা AWS-এর কোন service দেয় তা বলতে পারবে।
• Amazon EFS আসলে কী, তা বোঝাতে পারবে: একটা managed NFS file system, যেটা কয়েকটা Availability Zone-এর অনেক Linux instance একসাথে mount করে।
• mount target আর security group দিয়ে instance-কে EFS-এর সাথে জুড়তে পারবে, আর mount আটকে গেলে কারণ খুঁজে ঠিক করতে পারবে।
• AWS-এর এখনকার default মাথায় রেখে Regional না One Zone, General Purpose না Max I/O, আর Elastic, Provisioned না Bursting throughput, ঠিকটা বেছে নিতে পারবে।
• Standard, Infrequent Access আর Archive storage class-কে lifecycle management দিয়ে কাজে লাগাতে পারবে, আর আসলে কত টাকা বাঁচে তা হিসাব করে দেখাতে পারবে।
• encryption, access point আর IAM দিয়ে EFS সুরক্ষিত করতে পারবে, AWS Backup আর replication দিয়ে data বাঁচাতে পারবে, আর কখন EFS না, FSx-ই উত্তর তা চিনতে পারবে।
• পরীক্ষার যেকোনো scenario পড়ে EBS, EFS না instance store (না FSx), ঠিকটা বেছে নিতে পারবে।

#data রাখার তিনটা ধরন

লেসন ৫.১ থেকে ৫.৩-এ তুমি EC2 instance-এর দুই ধরনের disk দেখেছ: EBS volume আর instance store। দুটোই block storage। EFS-এ ঢোকার আগে storage কত রকমভাবে দেওয়া যায়, তার একটা পরিষ্কার ছবি মাথায় রাখা দরকার।

#Amazon EFS আসলে কী

Amazon Elastic File System (EFS) একটা managed network file system। তুমি একটা file system বানাও, আর EC2 instance-গুলো Linux-এর সাধারণ NFS client দিয়ে সেটা mount করে, ঠিক অফিসের network-এ একটা shared drive যেভাবে লাগানো হয়। server, disk, replication, scaling, সব সামলায় AWS।

• Protocol: NFS version 4.0 আর NFSv4.1, TCP port 2049-এ।
• শেয়ার করা: শত শত, এমনকি হাজার হাজার instance একই file system একসাথে mount করে একই ফাইল পড়তে-লিখতে পারে। container আর Lambda function-ও এটা mount করতে পারে, আর on-premises server Site-to-Site VPN বা Direct Connect দিয়ে এতে পৌঁছাতে পারে।
• AZ জুড়ে: Regional file system তার data অন্তত তিনটা Availability Zone-এ একাধিক কপিতে রাখে, আর Region-এর প্রতিটা AZ-এর instance একসাথে এটা ব্যবহার করতে পারে।
• শুধু Linux: EFS চলে Linux instance-এ (আর EC2 Mac instance-এ)। Windows-এ এটা সমর্থিত না। এটা একদম Linux file system-এর মতো আচরণ করে: POSIX permission (owner, group, read/write/execute), directory, আর NFSv4 file locking।
• নিজে থেকে বাড়ে-কমে: আগে থেকে কোনো size বলতে হয় না। ফাইল রাখলে file system বড় হয়, মুছলে ছোট হয়, petabyte পর্যন্ত। জায়গা কখনো ফুরায় না, খালি জায়গার টাকাও দিতে হয় না।
• যতটুকু ব্যবহার, ততটুকু টাকা: প্রতি মাসে যত GB আসলে রেখেছ তার টাকা দাও (আর throughput mode অনুযায়ী throughput-এর)। আগে থেকে কিছু provision করতে হয় না।

#instance কীভাবে EFS-এ পৌঁছায়: mount target

EFS file system থাকে Region পর্যায়ে, কিন্তু instance থাকে subnet-এ। এই দুইয়ের মাঝখানের সেতুটার নাম mount target।

1. প্রতি AZ-এ একটা mount target

   mount target হলো একটা network interface, যেটা EFS তোমার VPC-র একটা subnet-এ বসায়, ওই subnet থেকে একটা private IP নিয়ে। একটা Regional file system-এর প্রতিটা AZ-এ একটা করে mount target থাকতে পারে (একই AZ-এ দুটো কখনো না)। যে যে AZ থেকে instance mount করবে, সবগুলোতে একটা করে বানিয়ে রাখো; mount target-এর কোনো খরচ নেই।

2. mount target-এর গায়ে security group

   প্রতিটা mount target-এর এক বা একাধিক security group থাকে। আসল নিয়মটা হলো instance থেকে inbound TCP 2049 (NFS), আর source হিসেবে instance-দের security group দেওয়াই সবচেয়ে ভালো। instance-এর দিক থেকে mount target-এ outbound 2049 লাগে, যেটা default “সব outbound চলবে” নিয়মটা আগেই দিয়ে রাখে।

3. নাম দিয়ে mount

   instance-এ file system mount করো তার DNS নাম দিয়ে, fs-0abc1234.efs.us-east-1.amazonaws.com। VPC-র ভেতরে (DNS resolution আর DNS hostname চালু থাকলে) এই নাম resolve হয় instance-এর নিজের AZ-এর mount target-এ, তাই traffic AZ-এর বাইরে যায় না। সবচেয়ে সহজ উপায় EFS mount helper (amazon-efs-utils package): sudo mount -t efs -o tls fs-0abc1234:/ /mnt/efs।

অন্য AZ-এর mount target দিয়েও mount করা যায়, কিন্তু AZ-এর সীমা পার হওয়া প্রতিটা GB-এর জন্য cross-AZ data transfer-এর টাকা লাগে (প্রতি দিকে প্রতি GB $0.01), latency-ও বাড়ে। তাই নিজের AZ-এর mount target-ই ব্যবহার করো।

#mount আটকে গেলে

NFS port বন্ধ থাকলে সুন্দর করে “access denied” আসে না। security group packet-গুলো চুপচাপ ফেলে দেয়, তাই mount command অপেক্ষা করতে থাকে, তারপর “Connection timed out” দিয়ে ব্যর্থ হয়। এই ক্রমে দেখো:

#EFS-এর খরচ, EBS-এর সাথে মিলিয়ে

EFS টাকা নেয় প্রতি মাসে গড়ে যত GB রাখা হয়েছে তার ওপর, প্রতিটা storage class আলাদা করে। নিচের দামগুলো লেখার সময়ের us-east-1-এর; অন্য Region-এ আলাদা, তাই সবসময় pricing page দেখে নিও।

তাহলে প্রতি GB-তে EFS Standard-এর দাম gp3-এর প্রায় চার গুণ। নোটে যে বলা আছে “EFS-এ storage খরচ একটু বেশি”, কথাটা এখান থেকেই। তবে পুরো ছবিটা মিলিয়ে দেখো:

• EBS-এ তুমি টাকা দাও যত size provision করেছ তার, ব্যবহার হোক বা না হোক। 1 TB-র একটা gp3 volume-এ 400 GB থাকলেও খরচ $80।
• EFS-এ টাকা দাও শুধু আসলে যত GB রাখা আছে তার, আর কিছুই কখনো ভরে যায় না।
• তিনটা instance-এর প্রত্যেকের যদি একই data লাগে, EBS-এ লাগবে তিনটা volume (আর সেগুলো মিলিয়ে রাখার একটা ব্যবস্থা)। একটা EFS file system একাই সবাইকে দেয়।
• lifecycle management (নিচে আছে) দিয়ে ঠান্ডা ফাইলগুলো IA বা Archive-এ নেমে যায়, তখন গড়ে প্রতি GB-র দাম অনেকখানি কমে।

#Regional না One Zone

file system বানানোর সময় তার type বেছে নিতে হয়:

নোটে One Zone-কে বলা হয়েছে একটা “storage class”। এখনকার console-এ এটা একটা file system type, যেটা বানানোর সময়েই বেছে নিতে হয়, পরে আর বদলানো যায় না। এর ভেতরের দুটো storage class হলো One Zone আর One Zone-IA।

#Performance: performance mode আর throughput mode

file system কত দ্রুত হবে, সেটা দুটো আলাদা setting ঠিক করে।

#Performance mode: সবসময় General Purpose

পুরনো course-গুলো বলে “big data আর হাজার হাজার instance হলে Max I/O নাও”। এই পরামর্শ এখন পুরনো: Elastic throughput-এর সাথে General Purpose এখন প্রতি সেকেন্ডে কয়েক লাখ read operation পর্যন্ত যায় (চাইলে আরও), তাই AWS সব জায়গায় General Purpose-ই recommend করে। পরীক্ষায় কোনো option যদি এখনো “highly parallel, বেশি latency সহ্য করা যায়” বলে Max I/O দেখায়, বুঝবে ওটা পুরনো দিনের উত্তর।

#Throughput mode: প্রতি সেকেন্ডে কত MiB

Bursting-টা হাতে-কলমে বোঝার জন্য কয়েকটা সংখ্যা: Standard-এ 100 GiB থাকলে write-এর baseline মাত্র প্রায় 5 MiB/s (read তিন ভাগের এক ভাগে গোনা হয়, তাই প্রায় 15 MiB/s)। একটা চুপচাপ দিনের পরে যত credit জমে, তাতে প্রায় ৭২ মিনিট 100 MiB/s-এ burst করা যায়। 1 TiB-এর বেশি file system সময়ের অর্ধেক burst করতে পারে। আর যেকোনো file system অন্তত 1 MiB/s পায়।

Elastic-এ ওপরের সীমা অনেক বেশি। Elastic throughput-এর একটা Regional file system মোট 20–60 GiB/s পর্যন্ত read আর 1–5 GiB/s পর্যন্ত write করতে পারে, Region ভেদে কম-বেশি হয়। Bursting-এ যেখানে read মাত্র 3–5 GiB/s। একটা client একাই সর্বোচ্চ 1,500 MiB/s পায়, তবে সেটা নতুন EFS mount helper দিয়ে mount করলে; নইলে 500 MiB/s। পুরোনো slide-এ Elastic-এর জন্য read 3 GiB/s আর write 1 GiB/s লেখা থাকে, ওই সীমা পরে বাড়ানো হয়েছে।

#Storage class আর lifecycle management

বেশিরভাগ ফাইল কয়েক দিন বা কয়েক সপ্তাহ ব্যস্ত থাকে, তারপর প্রায় আর খোলাই হয় না। EFS এই ঠান্ডা data-কে সস্তা storage class-এ রাখতে দেয়, application-এর কিছুই বদলাতে হয় না।

#Lifecycle policy

Lifecycle management ফাইলগুলোকে এক class থেকে আরেক class-এ সরায়, দেখে প্রতিটা ফাইল Standard-এ শেষ কবে access হয়েছিল। একটা file system-এর তিনটা lifecycle policy থাকে:

যে খুঁটিনাটি পরীক্ষার প্রশ্ন আর মাসের বিল, দুই জায়গাতেই কাজে লাগে:

• EFS-এর নিজস্ব একটা access timer আছে; Standard-এর কোনো ফাইল পড়া বা লেখা হলেই সেটা আবার শূন্য থেকে শুরু হয়। directory list করা বা attribute দেখার মতো metadata operation access হিসেবে ধরা হয় না।
• ফাইলের নাম, মালিকানা আর directory tree সবসময় Standard-এই থাকে, তাই folder ঘুরে দেখার অনুভূতি একই থাকে।
• IA বা Archive-এর কোনো ফাইলে লিখলে সেটা আগে Standard-এ যায়, আর ২৪ ঘণ্টা পরে আবার সরে যাওয়ার যোগ্য হয়।
• Transition into Standard = None থাকলে ঠান্ডা ফাইল প্রতিবার পড়তে access charge আর বেশি latency গুনতে হয়। যে ফাইল আবার গরম হয়ে উঠতে পারে (যেমন application যে অনেক ছোট ছোট ফাইল পড়ে), তার জন্য On first access দাও, তাহলে ফাইলটা ফিরে আসে আর পরের পড়াগুলো দ্রুত হয়, access charge-ও লাগে না।
• CLI বা API দিয়ে বানানো file system-এ put-lifecycle-configuration দিয়ে যোগ না করা পর্যন্ত কোনো lifecycle policy থাকে না।
• policy পুরো file system-এর ওপর খাটে, আলাদা আলাদা folder-এ না।

#হিসাব করে দেখি: IA কি সত্যিই ৯২% বাঁচায়?

নোটে বলা আছে EFS-IA-র খরচ সাধারণ EFS-এর চেয়ে প্রায় ৯২% কম। এখনকার us-east-1-এর দামের সাথে মিলিয়ে দেখি:

• Bursting বা Provisioned file system-এ IA: $0.025 ÷ $0.30 = 8.3%, মানে প্রায় ৯২% কম। এই ক্ষেত্রে নোটের কথা ঠিক।
• Elastic file system-এ IA (console-এর default): $0.016 ÷ $0.30 = 5.3%, মানে প্রায় ৯৫% কম।
• Archive: $0.008 ÷ $0.30 = 2.7%, মানে প্রায় ৯৭% কম।

এটা কিন্তু প্রতি GB-র দাম। বিলে বাঁচে এর চেয়ে কম, কারণ গরম data Standard-এই থাকে, আর ঠান্ডা data পড়তে access charge লাগে। ধরো Elastic throughput-ওয়ালা 1,000 GB-র একটা Regional file system, যার মধ্যে কোনো এক মাসে মাত্র 200 GB ছোঁয়া হয়:

অর্থাৎ lifecycle এই বিলটা কমায় প্রায় ৭৬%, ৯২% না, আর Archive-এর ধাপটা আরেকটু কমায়। (Elastic throughput-এর পড়া-লেখার খরচ প্রতিটা সারিতে একই, তাই হিসাবে রাখা হয়নি।) তোমার data-র যত বড় অংশ সত্যিই ঠান্ডা, তত তুমি প্রতি GB-র হিসাবের কাছাকাছি যাবে; আর যে data প্রতি সপ্তাহে ছোঁয়া হয়, সেখানে access আর tiering-এর খরচ বাঁচানো টাকা খেয়ে ফেলতে পারে।

#Security

#Encryption

• At rest: EFS data আর metadata encrypt করে একটা AWS KMS key দিয়ে, হয় AWS managed key aws/elasticfilesystem, নয়তো তোমার নিজের customer managed key। console-এ এটা default-এ চালু; CLI বা API-তে নিজে চাইতে হয় (--encrypted)। এটা ঠিক করা যায় শুধু file system বানানোর সময়। আগে থেকে থাকা unencrypted file system encrypt করতে চাইলে নতুন একটা encrypted file system বানিয়ে data কপি করে নিতে হয়।
• In transit: EFS mount helper দিয়ে tls option সহ mount করো। helper NFS traffic-কে TLS 1.2-এ মুড়ে দেয় (port সেই 2049-ই)। TLS বাধ্যতামূলক করতে একটা file system policy যোগ করো, যেটা aws:SecureTransport false হলে access আটকে দেয়; console-এ এটাই “Enforce in-transit encryption for all clients” option।

#কে mount করতে পারবে, কী করতে পারবে

তিনটা স্তর একসাথে কাজ করে:

1. Network: security group আর NACL ঠিক করে কোন machine আদৌ port 2049-এ পৌঁছাতে পারবে।
2. IAM: একটা EFS file system policy (resource policy) আর instance-এর IAM role মিলে ঠিক করে কোনো client mount করতে পারবে কিনা, লিখতে পারবে কিনা, বা root হিসেবে কাজ করতে পারবে কিনা (ClientMount, ClientWrite, ClientRootAccess)। -o tls,iam দিয়ে mount করো, যাতে client তার IAM পরিচয় দেখায়। তৈরি option-গুলোর মধ্যে আছে root access আটকানো, শুধু read-only চালানো আর anonymous access বন্ধ করা।
3. POSIX permission: file system-এর ভেতরে সাধারণ Linux-এর owner, group আর mode bit খাটে, ঠিক local disk-এর মতো।

#Access point

access point হলো file system-এ ঢোকার একটা application-নির্দিষ্ট দরজা। এটা পারে:

• এর ভেতর দিয়ে আসা প্রতিটা request-কে একটা নির্দিষ্ট POSIX user ID আর group ID ব্যবহার করতে বাধ্য করতে, client নিজেকে যা-ই দাবি করুক;
• শুধু একটা directory-কে root হিসেবে দেখাতে (যেমন /apps/billing), না থাকলে বেছে দেওয়া owner আর permission দিয়ে সেটা বানিয়েও নিতে;
• IAM policy-তে নাম ধরে ব্যবহার হতে, যাতে billing application-এর role শুধু billing access point দিয়েই mount করতে পারে।

কয়েকটা application, container বা Lambda function-কে একটা file system শেয়ার করতে দেওয়ার, অথচ কেউ কারও data দেখবে না, এমন পরিষ্কার উপায় হলো access point।

#Data বাঁচানো: backup আর replication

• AWS Backup: default EFS backup plan-এ রোজ incremental backup, ৩৫ দিন রাখা হয়। console-এ বানানো file system-এ, আর যেকোনো tool দিয়ে বানানো One Zone file system-এ automatic backup default-এ চালু; CLI/API দিয়ে বানানো Regional file system-এ নিজে চালু করতে হয় (--backup)। restore করে পুরো file system বা একটা একটা ফাইল ফেরত আনা যায়, নতুন বা পুরনো file system-এ, এমনকি অন্য AZ বা Region-এও। restore করা ফাইল Standard-এ আসে।
• EFS Replication: file system-এর একটা read-only কপি অন্য Region-এ (বা একই Region-এ) সারাক্ষণ হালনাগাদ রাখে; বেশিরভাগ file system-এর জন্য recovery point objective ১৫ মিনিট। বিপর্যয়ে replication configuration মুছে দিলে কপিটা লেখার যোগ্য হয়ে যায়, তখন client-দের সেদিকে ঘুরিয়ে দিয়ে failover করো। কপিটা Regional বা One Zone, যেকোনোটা হতে পারে।

#EFS না FSx?

Linux-এর জন্য সব কাজের shared file system হলো EFS। EFS যেসব জায়গায় খাটে না, সেখানে Amazon FSx অন্য পরিচিত file system-গুলোর পুরোপুরি managed সংস্করণ দেয়। বিস্তারিত পরের একটা chapter-এ; আপাতত যে দুটো সবচেয়ে বেশি আসে সেগুলো চিনে রাখো:

#EBS, EFS আর instance store-এর মধ্যে বেছে নেওয়া

#পুরো তুলনা

#কীভাবে বেছে নেবে

1. Windows server-রা ফাইল শেয়ার করবে?

   Windows-এর shared ফাইল → FSx for Windows File Server। EFS Windows সমর্থন করে না।

2. কয়েকটা instance-এর একসাথে একই ফাইল লাগবে?

   হ্যাঁ, আর Linux → EFS (production-এ Regional; dev/test-এ One Zone)। S3-এর data নিয়ে HPC হলে → FSx for Lustre।

3. instance stop হলে বা host নষ্ট হলে data হারালে চলবে?

   হ্যাঁ, এটা আবার বানানো যায় এমন cache, buffer বা scratch, আর সবচেয়ে বেশি IOPS দরকার → instance store (যে instance type-এ এটা আছে)।

4. বাকি সব ক্ষেত্রে

   একটা instance, data টিকে থাকতে হবে, boot volume বা database → EBS (সাধারণত gp3, সবচেয়ে বেশি টানা IOPS-এর জন্য io2, সস্তায় sequential data-র জন্য st1/sc1)। একই AZ-এর কয়েকটা instance cluster-aware application দিয়ে একটা block device শেয়ার করবে → io2 Multi-Attach।

#পরীক্ষার scenario, হাতে-কলমে

#System design-এ EFS কীভাবে ব্যবহার হয়

• load balancer-এর পেছনের web fleet: WordPress, Drupal আর অন্য CMS site-গুলো upload, theme আর plugin রাখে EFS-এ, যাতে যেকোনো instance যেকোনো request সামলাতে পারে, আর Auto Scaling ইচ্ছেমতো instance যোগ বা বাদ দিতে পারে।
• Linux user-দের shared home directory আর development environment।
• Container আর serverless: যে task আর Lambda function আসে-যায়, তাদের এমন state লাগে যা তাদের পরেও টিকে থাকে; প্রতিটা application-এর জন্য একটা access point তাদের আলাদা রাখে।
• Content আর media-র কাজ: কয়েকটা processing server একই project folder পড়ে আর লেখে।
• Machine learning: training আর inference node-গুলো একই dataset আর model লোড করে।

যেখানে EFS ভুল হাতিয়ার:

• ছোট ছোট random write-এ ভরা database: প্রতিটা operation network পার হয়ে একটা distributed file system-এ যায়, তাই latency EBS-এর চেয়ে বেশি। EBS (বা managed database) নাও।
• Windows: FSx for Windows File Server নাও।
• HTTP দিয়ে দেওয়া archive আর public asset: প্রতি GB-তে S3 অনেক সস্তা, আর যত client-ই হোক সামলায়।
• একদম সবচেয়ে কম latency চাওয়া scratch space: instance store।

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

# 1. Security groups: instances (sg-web) and mount targets (sg-efs, inbound NFS from sg-web)
aws ec2 create-security-group --group-name sg-efs --description "EFS mount targets" --vpc-id $VPC
aws ec2 authorize-security-group-ingress --group-id $SG_EFS \
  --protocol tcp --port 2049 --source-group $SG_WEB

# 2. A Regional, encrypted file system with Elastic throughput and automatic backups
FS=$(aws efs create-file-system --creation-token shared-web-1 \
  --performance-mode generalPurpose --throughput-mode elastic \
  --encrypted --backup --tags Key=Name,Value=shared-web \
  --query FileSystemId --output text)
aws efs describe-file-systems --file-system-id $FS \
  --query "FileSystems[0].[LifeCycleState,ThroughputMode,PerformanceMode,Encrypted]"

# 3. One mount target per AZ (one subnet in each)
for SUBNET in $SUBNET_A $SUBNET_B $SUBNET_C; do
  aws efs create-mount-target --file-system-id $FS --subnet-id $SUBNET --security-groups $SG_EFS
done
aws efs describe-mount-targets --file-system-id $FS \
  --query "MountTargets[].[AvailabilityZoneName,IpAddress,LifeCycleState]"

# 4. Lifecycle: IA after 30 days, Archive after 90, back to Standard on first access
aws efs put-lifecycle-configuration --file-system-id $FS --lifecycle-policies \
  TransitionToIA=AFTER_30_DAYS TransitionToArchive=AFTER_90_DAYS \
  TransitionToPrimaryStorageClass=AFTER_1_ACCESS

# 5. An access point for one application: fixed POSIX identity and its own directory
aws efs create-access-point --file-system-id $FS \
  --posix-user Uid=1001,Gid=1001 \
  --root-directory "Path=/apps/web,CreationInfo={OwnerUid=1001,OwnerGid=1001,Permissions=750}"

# 6. On an instance (Amazon Linux 2023): install the mount helper and mount with TLS
sudo dnf install -y amazon-efs-utils
sudo mkdir -p /mnt/efs
sudo mount -t efs -o tls fs-0abc1234:/ /mnt/efs
df -h /mnt/efs                     # size shows as 8.0E: there is no fixed size
echo "fs-0abc1234:/ /mnt/efs efs _netdev,tls 0 0" | sudo tee -a /etc/fstab   # remount at boot
#    Through an access point, with IAM authorisation:
sudo mount -t efs -o tls,iam,accesspoint=fsap-0123456789abcdef0 fs-0abc1234:/ /mnt/web

# 7. Troubleshoot a hanging mount: can the instance reach the mount target on 2049?
nc -zv -w 3 10.0.1.25 2049        # times out → check sg-efs inbound 2049 and the NACLs

#সারসংক্ষেপ

মূল কথাগুলো

• Block storage (EBS, instance store) একটা instance-এর জন্য কাঁচা disk; file storage (EFS, FSx) অনেকের জন্য shared file system; object storage (S3) HTTP দিয়ে পুরো পুরো object।
• EFS হলো Linux-এর জন্য managed NFSv4.1 file system। Region-এর প্রতিটা AZ-এর শত শত বা হাজার হাজার instance একসাথে এটা mount করে। নিজে থেকে বাড়ে-কমে, আর টাকা দাও যত GB রাখা আছে তার।
• instance এতে পৌঁছায় প্রতি AZ-এ একটা mount target দিয়ে। mount target-এর security group-এ instance থেকে inbound TCP 2049 খোলা থাকতে হবে; নইলে mount আটকে থেকে timeout হয়।
• Regional (৩টা বা তার বেশি AZ, recommended) বনাম One Zone (একটা AZ, দাম প্রায় অর্ধেক, Archive নেই, backup default-এ চালু, AZ গেলে সাথে যায়)।
• Performance mode: সবসময় General Purpose; Max I/O পুরনো, আর Elastic বা One Zone-এ চলে না।
• Throughput: Elastic (console-এর default, হঠাৎ চাপ আর অজানা চাহিদা, যত GB আনা-নেওয়া তত টাকা), Provisioned (MiB/s ঠিক করে দাও, তার টাকা দাও), Bursting (size অনুযায়ী, burst credit, API-র default)।
• Storage class: Standard, IA, Archive (সাথে One Zone আর One Zone-IA)। Lifecycle N দিন কেউ না ছুঁলে ফাইল সরায় (console: IA ৩০, Archive ৯০), আর বলা থাকলে প্রথম access-এ ফেরত আনে। IA আর Archive-এ প্রতি GB access charge আছে।
• Bursting/Provisioned file system-এ IA প্রতি GB-তে প্রায় ৯২% সস্তা, Elastic-এ প্রায় ৯৫%; বিলে আসলে কত বাঁচবে তা নির্ভর করে কতটা data সত্যিই ঠান্ডা তার ওপর।
• KMS দিয়ে encryption at rest শুধু বানানোর সময়েই বাছা যায়; in transit-এর জন্য mount helper-এর TLS option। Access point আর IAM ঠিক করে কে কী mount করবে। AWS Backup আর EFS Replication data বাঁচায়।
• Windows → FSx for Windows File Server; HPC → FSx for Lustre; একটা instance, স্থায়ী block → EBS; অস্থায়ী, সবচেয়ে দ্রুত → instance store; কয়েকটা AZ জুড়ে shared Linux ফাইল → EFS।

নিজেকে যাচাই করো: EFS আর storage বেছে নেওয়া৩০টি প্রশ্ন