কীভাবে আমি আমার ওয়েবসাইটের জন্য AWS S3 Bucket তৈরি করলাম — একদম শুরু থেকে ধাপে ধাপে
অনেক দিন ধরেই আমি আমার ওয়েবসাইটের জন্য একটি নির্ভরযোগ্য ফাইল স্টোরেজ ব্যবস্থা করতে চাচ্ছিলাম। কারণ ওয়েবসাইটে শুধু লেখালেখি বা কনটেন্ট থাকলেই হয় না — এর সাথে লাগে ছবি, প্রশ্নের ইমেজ, স্টাডি মেটেরিয়াল, থাম্বনেইল, ইউজার আপলোড করা ফাইলসহ আরও অনেক কিছু।
শুরুতে ভাবছিলাম, “এগুলো কোথায় রাখা যায়?”
সার্ভারের ভিতর ফাইল রেখে দেওয়া যায় ঠিকই, কিন্তু সেটা দীর্ঘমেয়াদে খুব ভালো সমাধান না। স্টোরেজ ম্যানেজ করা কঠিন হয়, স্কেল করা কঠিন হয়, আবার কখনও সার্ভার পরিবর্তন করলে ফাইল মাইগ্রেশনও ঝামেলা হয়ে দাঁড়ায়।
তাই সিদ্ধান্ত নিলাম, AWS S3 ব্যবহার করব।
এই লেখায় আমি একদম সহজভাবে শেয়ার করছি, কীভাবে আমি আমার ওয়েবসাইটের জন্য একটি S3 bucket তৈরি করলাম, কী কী সেটিংস বুঝলাম, কোথায় একটু কনফিউশন ছিল, আর কীভাবে ধাপে ধাপে এগোলাম।
কেন S3 ব্যবহার করার কথা ভাবলাম?
আমার মূল প্রয়োজন ছিল:
ওয়েবসাইটের ইমেজ রাখা
প্রশ্নের সাথে সম্পর্কিত ইমেজ রাখা
স্টাডি মেটেরিয়াল বা PDF/ফাইল রাখা
পরে যেন সহজে বড় করা যায়
ভবিষ্যতে CDN বা CloudFront যোগ করা যায়
এই সবদিক চিন্তা করে S3-ই সবচেয়ে ভালো মনে হলো। কারণ এটি স্কেলেবল, নির্ভরযোগ্য, এবং AWS ecosystem-এর সাথে খুব ভালোভাবে কাজ করে।
প্রথম ধাপ: S3 Console-এ যাওয়া
আমি AWS Console-এ গিয়ে S3 ওপেন করলাম।
তারপর নতুন bucket তৈরি করার অপশন পেলাম।
Bucket তৈরি করার সময় বেশ কিছু সেটিংস আসে। শুরুতে একটু ভয় লাগতেই পারে, কারণ অনেক অপশন দেখায়। কিন্তু আসলে সবকিছু একসাথে বুঝতে হয় না। কোনটা এখন দরকার, কোনটা পরে করা যাবে — এটা বুঝে এগোলেই সহজ হয়।
Bucket name এবং region নির্বাচন
Bucket name এমন হতে হবে যা ইউনিক।
S3-তে bucket name globally unique হয়। মানে সারা AWS-এ সেই নামটি আর কেউ আগে ব্যবহার করে থাকলে আপনি সেটি নিতে পারবেন না।
আমি শিখলাম, খুব generic নাম না দিয়ে একটু পরিষ্কার, অর্থবহ নাম দেওয়া ভালো। যেমন:
banglatechnologies-assets
biddaan-storage
myproject-prod-assets
এরপর আসে region।
Bangladesh-এর ইউজারদের কথা চিন্তা করলে কাছাকাছি region ব্যবহার করাই ভালো। তাই Asia Pacific (Singapore) region নির্বাচন করা যুক্তিযুক্ত।
এতে latency কিছুটা কম থাকে, আর ভবিষ্যতের জন্যও ভালো ভিত্তি তৈরি হয়।
Object Ownership: ACL disabled
Bucket তৈরি করার সময় একটা জায়গায় Object Ownership আসে। সেখানে ACLs disabled (recommended) অপশন ছিল।
এটা AWS নিজেই recommended হিসেবে দেখাচ্ছিল। তাই এটা অপরিবর্তিত রাখলাম।
এই সেটিংসের মূল কথা হলো, ACL নিয়ে আলাদা ঝামেলা না করে bucket policy দিয়েই permissions ম্যানেজ করা। এতে setup অনেক cleaner হয়।
Public access নিয়ে প্রথম কনফিউশন
এখানেই প্রথম একটু কনফিউশন তৈরি হয়।
আমার bucket-এর ভিতরে আমি এমন ইমেজ রাখতে চাই, যেগুলো ওয়েবসাইটে দেখানো হবে।
যেমন:
পোস্টের কভার ইমেজ
প্রশ্নের ইমেজ
ম্যাটেরিয়ালের thumbnail
পাবলিক কনটেন্টের ফাইল
তাই naturally আমার দরকার ছিল কিছু ফাইল publicভাবে accessible হওয়া।
কিন্তু bucket তৈরি করার সময় AWS-এর default setting ছিল Block all public access।
শুরুতে এটা দেখে মনে হতে পারে, “এটা নিশ্চয়ই অন রাখাই ভালো।” কিন্তু আমার use case অনুযায়ী, আমি তো চাই কিছু ফাইল public URL দিয়ে খোলা যাক।
তাই বুঝলাম, public images serve করতে হলে public access block সেটিংস নিয়ে সচেতন হতে হবে।
Bucket Policy কোথায়?
Bucket তৈরি হয়ে যাওয়ার পর আমি খুঁজছিলাম, Bucket Policy কোথায় পাব।
এটা S3 bucket-এর ভেতরে ঢুকে Permissions tab-এর মধ্যে থাকে।
সেখানে scroll করলে Bucket policy নামে একটি সেকশন পাওয়া যায়।
এই policy ব্যবহার করেই আমি bucket-এর objects-এর জন্য public read access দিতে পারি।
যে policy-টা ব্যবহার করা যায়, তার ধারণা এমন:
সবার জন্য s3:GetObject allow করা
কিন্তু শুধু bucket-এর objects-এর উপর
bucket name সঠিকভাবে বসানো
এই policy দেওয়ার পর bucket-এর ভেতরের ফাইল URL দিয়ে খোলা সম্ভব হয়।
Public file access কাজ করানোর জন্য কী বুঝলাম
শুধু policy দিলেই সবসময় কাজ নাও করতে পারে।
কারণ তার আগে Block public access সেটিং ঠিক করতে হয়।
অর্থাৎ, দুইটা জিনিস একসাথে মিলতে হয়:
Public access block সঠিকভাবে কনফিগার করা
Bucket policy দিয়ে GetObject allow করা
এই দুইটা বিষয় ঠিক হওয়ার পরই public image URL কাজ করা শুরু করে।
Bucket-এর ভিতরে ফোল্ডার স্ট্রাকচার নিয়ে ভাবনা
Bucket বানিয়ে শুধু সব ফাইল root-এ ফেলে দিলেই কাজ হয়ে যায় না।
শুরু থেকেই একটা সুন্দর structure রাখা খুব দরকার।
আমি ভাবলাম, এভাবে ভাগ করলে ভালো হয়:
images/questions/
images/materials/
images/profiles/
images/thumbnails/
এর সুবিধা হলো:
পরে ফাইল খুঁজে পাওয়া সহজ
আলাদা আলাদা content type manage করা সহজ
ভবিষ্যতে migration বা CDN setup সহজ হয়
backend code-এ naming convention maintain করা সহজ হয়
শুরুর সময় structure ছোট হলেও, পরে project বড় হলে এই discipline অনেক কাজে দেয়।
Global namespace — এটা কী?
Bucket তৈরি করার সময় Global namespace অপশন দেখে একটু কনফিউশন হয়েছিল।
পরে বুঝলাম, S3 bucket name-এর concept-টাই এমন যে নাম globally unique হতে হয়।
অর্থাৎ, পুরো AWS জুড়ে সেই নাম আর কেউ ব্যবহার করতে পারবে না।
তাই এই অংশটা দেখে ভয় পাওয়ার কিছু নেই।
আসলে bucket name ঠিক করার সময় শুধু এটুকু মাথায় রাখতে হয় — নামটা unique এবং meaningful হতে হবে।
CloudFront কি এখনই লাগবে?
একটা পর্যায়ে production best practice নিয়ে আলোচনা করতে গিয়ে CloudFront-এর কথাও আসে।
CloudFront ব্যবহার করলে:
content দ্রুত serve হয়
caching পাওয়া যায়
custom CDN domain ব্যবহার করা যায়
S3 bucket private রেখে secure access setup করা যায়
শুনতে দারুণ। কিন্তু প্রশ্ন হলো — এটা কি এখনই দরকার?
আমার জন্য বাস্তব উত্তর ছিল: না, এখনই না। পরে করা যাবে।
এবং এটা আসলে খুবই practical সিদ্ধান্ত।
শুরুর পর্যায়ে যদি project এখনও grow করছে, traffic খুব বেশি না হয়, এবং দ্রুত কাজ শুরু করাই মূল লক্ষ্য হয়, তাহলে প্রথমে simple S3 public bucket setup দিয়েই শুরু করা যায়।
পরে যখন দরকার হবে, তখন architecture evolve করে:
Frontend → CloudFront → Private S3
এই setup-এ যাওয়া যাবে।
“Production best practice” পরে করার সিদ্ধান্ত
এই জায়গায় আমি একটা জিনিস পরিষ্কারভাবে বুঝলাম —
সবকিছু একদিনে perfect করতে গেলে অনেক সময় কাজই শুরু হয় না।
তাই better approach হলো:
এখন simple, working setup করা
clean naming রাখা
good folder structure রাখা
পরে CloudFront, signed URL, private content security যোগ করা
এই approach-টা আমার কাছে বেশি practical মনে হয়েছে।
Bucket তৈরি হয়ে গেছে, এবার কী?
Bucket create হওয়ার পর স্বাভাবিক প্রশ্ন হলো:
“এখন আমি কীভাবে শুরু করব?”
প্রথমে manual test করা যায়।
অর্থাৎ:
bucket-এর ভিতরে ফোল্ডার তৈরি করা
একটি image upload করা
object URL কপি করে browser-এ দেখা
public access ঠিকমতো কাজ করছে কি না যাচাই করা
এই ছোট্ট test-টাই অনেক confidence দেয়।
কারণ এতে বোঝা যায়, bucket, permission, policy — সব ঠিকভাবে কাজ করছে কি না।
“Key” বলতে আসলে কী বোঝায়?
এখানেও একটা গুরুত্বপূর্ণ বিষয় আছে।
S3-তে “key” শব্দটা দুইভাবে আসে।
১. Object Key
এটা হলো মূলত file path বা file name।
যেমন:
images/questions/q1.png
images/materials/chapter-1.pdf
এটা ফাইলের অবস্থান বোঝায়।
২. Access Key
এটা IAM credentials-এর অংশ।
যেটা backend application AWS-এ authenticate করার জন্য ব্যবহার করে।
এই দুইটা জিনিস এক না — এটা বুঝে নেওয়া জরুরি।
Access Key কোথা থেকে আসে?
Bucket তৈরি হয়ে গেলেই access key পাওয়া যায় না।
এটা আসে IAM থেকে।
আমি বুঝলাম, যদি আমার backend application — যেমন NestJS — S3-তে ফাইল upload করতে চায়, তাহলে backend-এর AWS credentials লাগবে।
এজন্য IAM-এ গিয়ে:
user select করতে হয়
Security credentials tab-এ যেতে হয়
access key create করতে হয়
তারপর Access Key ID এবং Secret Access Key সংরক্ষণ করতে হয়
এখানে সবচেয়ে গুরুত্বপূর্ণ ব্যাপার হলো —
এই keys কখনও frontend-এ রাখা যাবে না।
Angular বা browser-এর code-এর ভিতর access key রেখে দিলে সেটা বড় security risk হয়ে যাবে।
Backend-এই keys ব্যবহার করা উচিত
এই অংশটা খুবই গুরুত্বপূর্ণ।
S3-র সাথে প্রোগ্রামmatically কাজ করতে হলে সবচেয়ে নিরাপদ উপায় হলো:
key backend-এ রাখা
.env file-এ রাখা
GitHub-এ push না করা
frontend থেকে সরাসরি key expose না করা
শুরুর জন্য backend দিয়ে upload handle করা যায়।
আর পরে আরও ভালো architecture হিসেবে pre-signed URL ব্যবহার করা যায়।
Pre-signed URL — পরে কেন দরকার হবে?
এখনই না করলেও, ভবিষ্যতে এটা খুব useful হবে।
কারণ এতে flow দাঁড়ায় এমন:
frontend backend-কে request দেয়
backend একটি temporary upload URL তৈরি করে
frontend সরাসরি S3-তে upload করে
AWS keys browser-এ যায় না
এটা performance এবং security — দুই দিক থেকেই ভালো।
কিন্তু শুরুতে সবকিছু একসাথে না করে, আগে S3 setup ও basic upload flow বুঝে নেওয়াই বুদ্ধিমানের কাজ।
আমার শেখা সবচেয়ে গুরুত্বপূর্ণ কিছু বিষয়
এই পুরো setup করতে গিয়ে কিছু জিনিস খুব পরিষ্কার হয়েছে।
প্রথমত, AWS-এ অনেক অপশন থাকলেও সবকিছু একবারে করতে হয় না।
দ্বিতীয়ত, public content আর private content-এর use case আলাদা।
তৃতীয়ত, clean folder structure এবং naming শুরু থেকেই গুরুত্বপূর্ণ।
চতুর্থত, CloudFront বা advanced production setup পরে যোগ করা সম্পূর্ণ সম্ভব।
আর পঞ্চমত, security নিয়ে shortcut নেওয়া উচিত না — বিশেষ করে access key frontend-এ কখনও রাখা যাবে না।
এখন আমার practical plan কী?
আমার বর্তমান পরিকল্পনা হলো:
S3 bucket দিয়ে শুরু করা
images ও static assets সেখানে রাখা
public URL দিয়ে ওয়েবসাইটে ব্যবহার করা
backend থেকে upload flow তৈরি করা
পরে CloudFront যোগ করা
private content-এর জন্য future-এ signed URL বা restricted access যোগ করা
এই roadmap-টা আমার কাছে balanced মনে হয়েছে।
অর্থাৎ, এখন কাজ শুরু করা যাচ্ছে, আবার future growth-এর পথও খোলা থাকছে।
উপসংহার
AWS S3 bucket setup প্রথমে একটু জটিল মনে হতে পারে।
বিশেষ করে যখন public access, bucket policy, IAM keys, CloudFront — এই সব terms একসাথে সামনে আসে।
কিন্তু ধাপে ধাপে এগোলে বিষয়টা অনেক সহজ হয়ে যায়।
আমার জন্য সবচেয়ে helpful ছিল এই mindset:
এখন যা দরকার, এখন সেটা করি।
যা পরে করা যাবে, সেটা পরে করব।
কিন্তু foundation clean রাখব।
এই approach-এ S3 bucket setup করা শুধু সম্ভবই না, বরং অনেক manageable হয়ে যায়।
যারা নিজেদের ওয়েবসাইট, learning platform, quiz system, বা content-based project-এর জন্য file storage setup করতে চান, তাদের জন্য S3 সত্যিই খুব ভালো শুরু হতে পারে।
Comments (0)
Login to leave a comment.