Console, CLI, SDK ও CloudShell

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

• বুঝিয়ে বলতে পারবে, Management Console, CLI, SDK আর CloudShell কেন একই resource দেখে: চারটাই আসলে একই AWS API-র client।
• access key কী, এটা দিয়ে কী করা যায় আর কী যায় না, আর secret-টা তোমার মেশিন থেকে একবারও বের না করে কীভাবে একটা request sign হয়, বলতে পারবে।
• aws configure দিয়ে AWS CLI সেট করতে পারবে, তার দুটো file পড়তে পারবে, নাম দেওয়া profile ব্যবহার করতে পারবে, আর আগেই বলে দিতে পারবে CLI কোন credential নেবে।
• CloudShell ব্যবহার করতে পারবে আর তার সীমা জানবে: কার permission নিয়ে চলে, কী জমা রাখে, কতদিন, কোথায়।
• রোজকার গোলমালগুলো ধরতে পারবে: ভুল Region, credential না থাকা বা বাতিল হওয়া, ভুল signature, ঘড়ির গরমিল, আর access denied।
• access key ফাঁস হলে ঠিক কী করতে হয় জানবে, আর এমনভাবে design করতে পারবে যাতে ফাঁস হওয়ার মতো লম্বা মেয়াদের কোনো key-ই না থাকে।

#সব রাস্তা গিয়ে মেশে একই API-তে

lesson 1.2-এ দেখেছ AWS তার data center কোথায় কোথায় রাখে। এই লেসনের বিষয় হলো, তুমি নিজের laptop-এ বসে সেই data center-গুলোকে কাজের কথা কীভাবে বলো।

রোজকার কাজে ঢোকার দরজা চারটা:

1. AWS Management Console: সেই website, যেখানে password দিয়ে sign in করো। তুমি click করো।
2. AWS CLI (Command Line Interface): terminal-এর একটা program। তুমি লেখো aws s3 ls।
3. AWS SDK (Software Development Kit): তোমার নিজের program-এর ভেতরের একটা library। তোমার code ডাকে s3.list_buckets()।
4. AWS CloudShell: console-এর ভেতরেই খোলে এমন একটা terminal, যেটা আগে থেকেই তোমার নামে sign in করা।

দেখতে চারটা একদম আলাদা, কিন্তু ভেতরে সবাই হুবহু একই কাজ করে। AWS-এ যেকোনো কাজ, server চালু করা থেকে একটা file পড়া পর্যন্ত, আসলে একটা API call: ec2.us-east-1.amazonaws.com-এর মতো একটা service endpoint-এ পাঠানো একটা HTTPS request, যার সাথে থাকে একটা signature, যেটা প্রমাণ করে request-টা কে পাঠিয়েছে। তুমি button চাপলে console সেই request বানায়; তোমার command থেকে বানায় CLI; তোমার function call থেকে বানায় SDK। তুমি কোন দরজা দিয়ে এলে, AWS সেটা জানতেও পারে না, জানার দরকারও নেই। সে দেখে শুধু দুটো জিনিস: কে চাইছে (authentication) আর তার অনুমতি আছে কি না (authorization)।

এর একটা বাস্তব ফল আছে, যেটা পরীক্ষায় খুব আসে: console-এ যা বানাবে, CLI আর SDK থেকেও সেটা দেখা যাবে, উল্টোটাও সত্যি। তোমার account-এর আলাদা কোনো “console কপি” নেই।

#Endpoint আর Region

বেশির ভাগ AWS service regional: us-east-1-এর EC2 আর eu-west-1-এর EC2 দুটো আলাদা করে চলা service, যাদের endpoint-ও আলাদা (ec2.us-east-1.amazonaws.com, ec2.eu-west-1.amazonaws.com)। প্রতিটা request যায় ঠিক একটা Region-এ। console-এ Region ঠিক হয় ডান দিকের ওপরের selector দিয়ে; CLI আর SDK-তে ঠিক হয় region setting, একটা environment variable, বা --region option দিয়ে।

হাতে গোনা কয়েকটা service global, তার মধ্যে প্রথম যেটার সাথে দেখা হয় সেটা IAM: console-এ যে Region-ই দেখাক, user আর policy একই থাকে, আর console Region-এর নামের জায়গায় লেখে “Global”। (কোন service global আর কোনটা regional, তার list আছে lesson 1.2-এ।)

#Management Console

সবাই শুরু করে console দিয়েই। তুমি AWS sign-in page খুলে দুই ধরনের identity-র যেকোনো একটা দিয়ে ঢোকো:

• root user: যে email আর password দিয়ে account খোলা হয়েছিল। account-এর ওপর এর ক্ষমতা সীমাহীন, তাই setup শেষ হলেই একে তালা দিয়ে রাখা উচিত (lesson 2.3)।
• IAM user: তুমি দাও account ID (১২ অঙ্কের) বা account-এর alias, তারপর user name আর password, সাধারণত সাথে একটা MFA code। প্রতিটা account-এর নিজের একটা sign-in link থাকে, দেখতে এমন: https://<account-id>.signin.aws.amazon.com/console।

sign in করার পর console একটা অস্থায়ী session ধরে রাখে, আর তুমি যে page-ই খোলো, সেটা এই session দিয়ে API call করে। কয়েকটা কথা জেনে রাখো:

• Region selector ঠিক করে প্রতিটা page কোন regional endpoint-এর সাথে কথা বলবে। এটা page-এর ব্যাপার, account-এর না।
• search bar দিয়ে service, feature আর documentation খুঁজে পাওয়া যায়; প্রিয় service-গুলো pin করেও রাখা যায়।
• console-ও আর দশটা client-এর মতোই: তোমার permission কোনো কাজের অনুমতি না দিলে console একটা access denied banner দেখায়, ঠিক যেখানে CLI একটা error দেখাত।
• click করে করে করা কাজ আবার হুবহু করা কঠিন, review করাও কঠিন। লোকে মজা করে একে বলে ClickOps। শেখা আর দেখার জন্য console ব্যবহার করো; যে কাজ দুবার করতে হবে, তার জন্য CLI, SDK বা infrastructure as code।

#Access key: program-এর পরিচয়পত্র

একটা program তো web page-এ password টাইপ করতে পারে না, তাই AWS program-কে দেয় আলাদা ধরনের একটা credential: access key। access key আসলে একটা জোড়া:

এগুলো নিয়ে যা অবশ্যই জানতে হবে:

• এগুলো শুধু CLI, SDK আর সরাসরি API call-এর জন্য। access key দিয়ে Management Console-এ sign in করা যায় না, আবার console-এর password দিয়েও CLI চালানো যায় না। দুটো আলাদা দরজার জন্য দুটো আলাদা credential।
• এগুলো একজন IAM user-এর (অথবা, বিপজ্জনকভাবে, root user-এর), আর ঠিক সেই user-এর permission নিয়েই চলে।
• secret দেখা যায় মাত্র একবার, key বানানোর মুহূর্তে। হারিয়ে গেলে আর খুঁজে বের করা যায় না: নতুন key বানাও, পুরনোটা মুছে দাও।
• একজন user-এর সর্বোচ্চ দুটো access key থাকতে পারে। এটা পাশ কাটানোর মতো কোনো বাধা না; এটা রাখা হয়েছে যাতে কাজ না থামিয়েই rotate করা যায়: দ্বিতীয় key বানাও, application-গুলোকে তাতে সরাও, তারপর প্রথমটা inactive করে মুছে দাও।
• একটা key হয় Active, নয়তো Inactive। inactive করলে সাথে সাথে বন্ধ হয়ে যায়, কিন্তু কিছু ভেঙে গেলে আবার চালু করা যায়; delete করলে চিরতরে শেষ।
• লম্বা মেয়াদের key নিজে থেকে কখনো মেয়াদোত্তীর্ণ হয় না। এদের ID শুরু হয় AKIA দিয়ে। আর অস্থায়ী credential, যেমন role বা aws login যেটা দেয়, তার ID শুরু হয় ASIA দিয়ে, সাথে থাকে session token নামে তৃতীয় একটা অংশ, আর মেয়াদ শেষ হয় কয়েক মিনিট বা কয়েক ঘণ্টায়।
• root user-এর কোনো access key থাকাই উচিত না। থাকলে মুছে দাও।

#একটা request কীভাবে sign হয় (SigV4)

secret যদি password-এর মতোই হয়, তাহলে CLI secret না পাঠিয়ে কীভাবে প্রমাণ করে যে secret-টা তার জানা? এর জন্য সে ব্যবহার করে Signature Version 4 (SigV4), AWS-এর প্রতিটা API যে নিয়মে request sign করে।

1. request তৈরি

   CLI তোমার command-কে একটা HTTPS request বানায়: method, endpoint, path, parameter, body-র একটা hash, আর এখনকার সময়।

2. signing key বের করা

   secret access key থেকে সে এমন একটা key বের করে, যেটা শুধু এই তারিখ, এই Region আর এই service-এর জন্য কাজ করে। আজ us-east-1-এর EC2-র জন্য বানানো signature কাল অন্য Region-এর S3-র জন্য কোনো কাজে আসবে না।

3. sign করা

   সেই key দিয়ে request-এর ওপর একটা signature হিসাব করে, তারপর access key ID আর scope (তারিখ, Region, service) সহ সেটা বসিয়ে দেয় request-এর Authorization header-এ। secret নিজে request-এ কোথাও থাকে না।

4. AWS একই হিসাব আবার করে

   AWS access key ID দেখে তার সাথের secret খুঁজে নেয়, হাতে আসা request-এর ওপর একই হিসাব করে, তারপর মিলিয়ে দেখে। signature মিলে গেলে বোঝা যায় request সত্যিই key-এর মালিকের, আর পথে কিছু বদলায়নি। এরপর IAM permission দেখে।

এই design-এর জন্য একটা signature একসাথে তিনটা জিনিস রক্ষা করে:

• পরিচয়: secret যার কাছে আছে, শুধু সে-ই এই signature বানাতে পারত।
• অখণ্ডতা: একটা parameter বদলালেই (একটা instance-কে পঞ্চাশটা) hash বদলে যায়, signature ভেঙে যায়।
• টাটকা থাকা: বেশির ভাগ ক্ষেত্রে request-কে তার সময় থেকে পাঁচ মিনিটের মধ্যে AWS-এ পৌঁছাতে হয়, তাই কেউ ধরে রাখা request পরে আবার পাঠাতে পারে না।

নিজে হাতে তোমাকে প্রায় কখনো sign করতে হবে না: CLI আর SDK করে দেয়। SigV4-এর সাথে তোমার দেখা হবে কেবল যখন এটা ব্যর্থ হয়, আর তখন error-ই বলে দেয় কোন ধাপে গোলমাল হয়েছে।

#চেনা error-গুলো পড়তে শেখা

ওপরের পাঁচটা row আর ছয় নম্বরটার পার্থক্য খেয়াল করো। প্রথম পাঁচটা authentication-এর ব্যর্থতা: তুমি কে, AWS সেটা জানে না বা বিশ্বাস করে না। access denied হলো authorization-এর ব্যর্থতা: তুমি কে, AWS ঠিকই জানে, আর সিদ্ধান্ত নিয়েছে এই কাজ তুমি করতে পারবে না। পরীক্ষা আর বাস্তবের গোলমাল, দুই জায়গাতেই এই দুটো আলাদা করে চিনতে পারাটা জরুরি।

#AWS CLI

AWS CLI একটা open-source program (এর code GitHub-এ আছে), যেটা terminal থেকে সরাসরি AWS service-এর public API ব্যবহারের সুযোগ দেয়। console-এ যা করা যায়, এটা দিয়েও করা যায়, সাধারণত আরো কিছু বেশি, কারণ কিছু feature console-এ আসার আগেই API-তে চলে আসে।

• version 2 install করো। version 1 এখন maintenance mode-এ, শুধু জরুরি fix পায়; AWS version 2-এ যেতে বলে।
• এটা Linux, macOS আর Windows-এ চলে, আর CloudShell ও Amazon Linux-এ আগে থেকেই install করা থাকে।
• প্রতিটা command-এর গড়ন একই: aws <service> <operation> [options], যেমন aws ec2 describe-instances --region eu-west-1। operation-এর নাম হলো API action-এর নামটাই, ছোট হাতের অক্ষরে আর hyphen দিয়ে: DescribeInstances হয়ে যায় describe-instances।
• default output হলো JSON; --output table বা --output text পড়তে, বা shell script-এ পাঠাতে সহজ, আর --query দিয়ে শুধু দরকারি field-গুলো বেছে নেওয়া যায়।
• EC2-র অনেক command --dry-run নেয়: AWS কিছু না করেই তোমার permission আর parameter যাচাই করে দেয়।
• aws <service> help (বা aws <service> <operation> help) internet ছাড়াই পুরো reference দেখায়।

#aws configure আর দুটো file

CLI-কে credential দেওয়ার সবচেয়ে দ্রুত উপায় aws configure। এটা চারটা প্রশ্ন করে, আর উত্তরগুলো তোমার home directory-র লুকানো .aws folder-এর দুটো সাধারণ text file-এ লিখে রাখে:

$ aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: us-east-1
Default output format [None]: json

# ~/.aws/credentials   (Windows: C:\Users\<you>\.aws\credentials)
[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

[prod]
aws_access_key_id = AKIAI44QH8DHBEXAMPLE
aws_secret_access_key = je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY

# ~/.aws/config        (Windows: C:\Users\<you>\.aws\config)
[default]
region = us-east-1
output = json

[profile prod]
region = eu-west-1

• credentials-এ থাকে গোপন জিনিস: key ID, secret key, session token।
• config-এ থাকে বাকি সব: Region, output format, role-এর setting, IAM Identity Center-এর setting।
• প্রতিটা section একটা profile। কোনো নাম না বললে ব্যবহার হয় default। বাকি profile-এর নাম credentials file-এ লেখা হয় [prod], কিন্তু config file-এ [profile prod], ছোট্ট এই পার্থক্যে অনেকেই হোঁচট খায়।
• একটা command-এর জন্য profile বাছতে দাও --profile prod, আর পুরো terminal session-এর জন্য export AWS_PROFILE=prod (PowerShell-এ: $env:AWS_PROFILE = "prod")।
• file দুটো সাধারণ text। তোমার home directory যে পড়তে পারে, সে তোমার secret-ও পড়তে পারে, আর এটা অল্প মেয়াদের credential বেছে নেওয়ার আরেকটা কারণ।

“CLI আসলে কী ব্যবহার করছে?”, এই প্রশ্নের উত্তর দেয় দুটো command:

• aws sts get-caller-identity দেখায় তোমার credential কোন account-এর কোন identity-র। এর জন্য কোনো permission লাগে না, তাই credential ঠিক থাকলে এটা সবসময় কাজ করে।
• aws configure list প্রতিটা value (key, secret, Region, profile) দেখায়, আর দেখায় সেটা কোথা থেকে এল: file থেকে, environment variable থেকে, নাকি অন্য কোথাও থেকে।

#CLI credential কোথায় কোথায় খোঁজে

CLI আর SDK একটা নির্দিষ্ট ক্রমে কয়েকটা জায়গা খোঁজে, আর যেখানে প্রথম credential পায়, সেটাই নেয়। সহজ করে বললে ক্রমটা এই:

1. command-line option, যেমন --profile বা --region।
2. environment variable: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_PROFILE, AWS_REGION।
3. shared file, মানে ~/.aws/credentials আর ~/.aws/config, বেছে নেওয়া profile-এর জন্য (যে profile role assume করে, IAM Identity Center ব্যবহার করে, বা aws login ব্যবহার করে, সেগুলোও এখানেই পড়ে)।
4. container credential, যে code role সহ container task-এ চলছে তার জন্য।
5. EC2 instance role, যেটা আসে instance metadata service (IMDS) থেকে।

এই ক্রম জানলে অনেক অবাক করা ঘটনা বোঝা যায়। environment variable file-এর আগে, তাই এক ঘণ্টা আগে export করা একটা key চুপচাপ তোমার যত্ন করে বাছা profile-কে হারিয়ে দেয়। আর শেষ দুটো ধাপের কারণেই AWS-এর compute-এ চলা code-এ কিছুই configure করতে হয় না: role লাগানো থাকলে credential নিজে থেকেই চলে আসে।

#মানুষের জন্য অল্প মেয়াদের credential

laptop-এ রাখা লম্বা মেয়াদের key-ই ফাঁস হয়। মানুষের জন্য এর চেয়ে ভালো দুটো উপায় আছে:

• aws login (CLI version 2.32.0 আর তার পরের version) তোমার সাধারণ console credential দিয়ে browser-এ sign in করিয়ে CLI-কে অস্থায়ী credential দেয়, যেটা ১২ ঘণ্টা পর্যন্ত নিজে নিজে নবায়ন হতে থাকে। স্থায়ী কিছুই জমা থাকে না।
• IAM Identity Center (aws configure sso, তারপর aws sso login) পুরো প্রতিষ্ঠানের জন্য উপায়: মানুষ একবার sign in করে, আর যে account আর permission set তাকে দেওয়া আছে, সেগুলোর জন্য অল্প মেয়াদের credential পায়। এর সাথে দেখা হবে lesson 2.4-এ, আবার advanced identity অধ্যায়ে।

access key-এর জায়গা এখনো আছে, যেমন AWS-এর বাইরের এমন একটা script, যেটা নিজে sign in করতে পারে না। কিন্তু এটা হওয়া উচিত ব্যতিক্রম: যতটুকু দরকার ততটুকুই permission, আর নিয়মিত rotate।

#AWS SDK

AWS SDK হলো এমন library, যা দিয়ে তোমার নিজের code AWS-কে ডাকতে পারে। জনপ্রিয় প্রতিটা language-এর জন্য একটা করে আছে: Python (boto3), JavaScript আর TypeScript, Java, Go, .NET, PHP, Ruby, C++, Rust আরো অনেক; সাথে Android আর iOS-এর জন্য mobile library (Amplify দিয়ে) আর ছোট IoT hardware-এর জন্য device SDK। CLI নিজেও তৈরি botocore-এর ওপর, যেটা Python SDK-এর মূল অংশ।

import boto3

ec2 = boto3.client("ec2", region_name="us-east-1")
for r in ec2.describe_instances()["Reservations"]:
    for i in r["Instances"]:
        print(i["InstanceId"], i["State"]["Name"])

import { S3Client, ListBucketsCommand } from "@aws-sdk/client-s3";

const s3 = new S3Client({ region: "us-east-1" });
const { Buckets } = await s3.send(new ListBucketsCommand({}));
console.log(Buckets.map((b) => b.Name));

SDK তোমার হয়ে যা করে দেয়:

• credential খুঁজে নেয়, CLI-র মতোই খোঁজার নিয়মে, তাই একই code এক লাইনও না বদলে চলে তোমার laptop-এ (profile বা aws login), pipeline-এ (environment variable) আর EC2 বা Lambda-য় (তার role)।
• Region অনুযায়ী endpoint বেছে নেয়, আর প্রতিটা request SigV4 দিয়ে sign করে।
• throttle হওয়া বা সাময়িকভাবে ব্যর্থ request exponential backoff দিয়ে আবার চেষ্টা করে।
• লম্বা ফলাফল page ধরে ধরে আনে, আর উত্তরকে সেই language-এর নিজের object বানিয়ে দেয়।

সবচেয়ে জরুরি নিয়ম: code-এ কখনো credential লিখবে না। খেয়াল করো, ওপরের দুটো উদাহরণের কোনোটাতেই key-এর নামগন্ধ নেই। code শুধু একটা client বানায়; credential কোথা থেকে আসবে, সেটা ঠিক করে দেয় code যে পরিবেশে চলছে সেই পরিবেশ।

#AWS CloudShell

CloudShell হলো তোমার browser-এর ভেতরের একটা terminal, console-এর ওপরের bar-এর icon থেকে খোলে। পেছনে AWS তোমার জন্য একটা ছোট Linux environment চালু করে, যেখানে AWS CLI, Python, Node.js, git আর চেনা tool-গুলো আগে থেকেই install করা।

কেন এটা কাজের:

• setup নেই, key-ও নেই। console-এ যে sign in করে আছে, CloudShell নিজে থেকেই তার credential ব্যবহার করে। aws configure চালাতে হয় না, আর disk-এ ফাঁস হওয়ার মতো কোনো access key-ও থাকে না।
• ঠিক তোমার permission। console-এ তুমি যা পারো, CloudShell-ও ততটুকুই পারে, এর বেশি না। এটা কোনো পেছনের দরজা না। CloudShell ব্যবহার করতেও আলাদা permission লাগে (AWS-এর তৈরি AWSCloudShellFullAccess managed policy আছে), তাই যাদের internet-যুক্ত shell পাওয়া উচিত না, administrator তাদের জন্য এটা বন্ধ রাখতে পারেন।
• বাড়তি খরচ নেই। টাকা দিতে হয় শুধু তোমার command যে AWS resource বানায় তার জন্য।

এর সীমাগুলো, যেগুলো পরীক্ষা আর রোজকার কাজ, দুই জায়গাতেই দরকার:

প্রতিটা Region-এর home directory আলাদা, তাই us-east-1-এ রাখা একটা script eu-west-1-এ CloudShell খুললে পাবে না। Actions menu দিয়ে file upload আর download করা যায়, বা S3 দিয়ে সরানো যায়। CloudShell চাইলে তোমার কোনো VPC-র ভেতরেও চালু করা যায়, private resource-এ পৌঁছানোর জন্য; ওই VPC environment-গুলোতে কোনো স্থায়ী storage-ই থাকে না।

#ফাঁস হওয়া key: সবচেয়ে দামি ভুল

access key internet-এর যেকোনো জায়গা থেকে কাজ করে, password বা MFA ছাড়াই, তাই key ফাঁস মানে account ফাঁস। চেনা গল্পটা এরকম: একজন developer “শুধু test করার জন্য” একটা config file-এ key লিখে দেয়, project-টা একটা public GitHub repository-তে push করে, আর কয়েক মিনিটের মধ্যেই স্বয়ংক্রিয় scanner সেটা খুঁজে পায়। আক্রমণকারী console ছুঁয়েও দেখে না; নিজের মেশিন থেকে API ডেকে প্রতিটা Region-এ বড় বড় instance চালু করে, সাধারণত cryptocurrency mine করার জন্য। এক দিনেই বিল হাজার হাজার ডলারে পৌঁছাতে পারে।

AWS নিজেও public code খুঁজে দেখে। তোমার কোনো key পেলে সে user-এর সাথে AWSCompromisedKeyQuarantineV3 managed policy লাগিয়ে দেয়, যেটা instance চালু করা বা user বানানোর মতো ঝুঁকির কাজ deny করে, তারপর একটা support case খোলে আর তোমাকে email করে। এতে ক্ষতি কমে। কিন্তু যা আগেই চালু হয়ে গেছে, সেটা ফেরত যায় না, আর policy-টা নিজে থেকে সরানো উচিতও না; বরং support case-এর নির্দেশ মেনে চলো।

কী করবে, ঠিক এই ক্রমে:

1. key-টাকে অকেজো করো

   সাথে সাথে IAM-এ সেটা inactive করো (বা মুছে দাও)। file বা commit মুছে ফেলা যথেষ্ট না: key থেকে যায় git history-তে, fork-গুলোতে, আর scanner-রা আগেই যত কপি নিয়েছে সবগুলোতে।

2. বদলে দাও

   application-কে একটা বিকল্প দাও, সবচেয়ে ভালো হয় নতুন key-এর বদলে একটা IAM role। key সত্যিই লাগলে আগে নতুনটা বানাও (দ্বিতীয় key-এর জায়গাটা এই জন্যই), সেটায় সরে যাও, তারপর পুরনোটা মুছে দাও।

3. কী ঘটেছে খুঁজে বের করো

   CloudTrail দিয়ে দেখো ওই access key ID দিয়ে কোন কোন API call হয়েছে, সব Region-এ: কী কী resource বানানো হয়েছে, কোন user বা key যোগ হয়েছে, কোন policy বদলেছে।

4. পরিষ্কার করো

   অচেনা instance আর অন্য resource terminate করো, আক্রমণকারীর বানানো user, key বা role মুছে দাও, বিল দেখো, আর AWS-এর support case ধরে ধরে কাজ শেষ করো।

আটকানোর উপায় মূলত design, শুধু সাবধান থাকা না:

• code-এ কোনো credential না, কখনোই না। SDK-কে খুঁজে নিতে দাও।
• AWS-এ চলা কাজের জন্য role, মানুষের জন্য অল্প মেয়াদের credential (aws login, IAM Identity Center)।
• যে key রাখতেই হবে, তার জন্য least privilege, যাতে ফাঁস হলেও ক্ষতি সীমিত থাকে।
• একটা .gitignore, যেটা .aws/ folder আর .env file বাদ দেয়, আর একটা secret-scanning hook, যেটা key-এর মতো দেখতে লেখা থাকলে commit আটকে দেয়।
• নিয়মিত audit: IAM-এর credentials report প্রতিটা key-এর বয়স আর শেষ কবে ব্যবহার হয়েছে দেখায় (lesson 2.4)। মাসের পর মাস কেউ ছোঁয়নি এমন key মুছে দেওয়া উচিত।

#command টাইপ করার বাইরে: infrastructure as code

একটা একটা কাজের জন্য CLI দারুণ, কিন্তু বাস্তবের একটা system-এ resource থাকে শত শত। লম্বা একটা CLI script দিয়ে সেগুলো বানানো ভঙ্গুর: ৪০ নম্বর ধাপ fail করলে কী হবে, বা একই setup অন্য Region-এ লাগলে? এটাই infrastructure as code (IaC)-এর কাজ: শেষে কী চাও সেটা তুমি একটা file-এ লেখো, আর একটা tool নিজে হিসাব করে API call-গুলো করে।

• AWS CloudFormation একটা template (JSON বা YAML) পড়ে, তার সব resource একসাথে একটা stack হিসেবে বানায়, বদলায় বা মোছে। stack মুছলে তার বানানো সব মুছে যায়।
• AWS CDK (Cloud Development Kit) দিয়ে একই জিনিস লেখা যায় TypeScript, Python, Java বা অন্য language-এ; সে একটা CloudFormation template বানিয়ে deploy করে।
• Terraform আর এরকম অন্য কোম্পানির tool একই কাজ করে, কয়েকটা cloud জুড়ে।

ভেতরে সবাই CLI-র মতোই একই API, একই credential আর একই permission ব্যবহার করে। এই course-এ যখনই কোনো design-এ “বারবার একইভাবে”, “কয়েকটা account জুড়ে” বা “কয়েকটা Region জুড়ে” কথাটা আসবে, এদের দেখা পাবে।

#ঠিক দরজাটা বেছে নেওয়া

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

# ১. CLI install করো বা যাচাই করো (version 2)
aws --version                              # aws-cli/2.x ...

# ২. লম্বা মেয়াদের key ছাড়া sign in (CLI 2.32.0+), নিতান্ত দরকার হলে key দিয়ে configure
aws login                                  # browser খোলে, অস্থায়ী credential
# aws configure                            # ~/.aws/credentials আর ~/.aws/config লেখে

# ৩. আমি কে, আর প্রতিটা setting কোথা থেকে এল?
aws sts get-caller-identity
aws configure list

# ৪. একই প্রশ্ন, দুটো Region: Region-এর সীমানা নিজের চোখে দেখো
aws ec2 describe-instances --region us-east-1 --query "Reservations[].Instances[].InstanceId"
aws ec2 describe-instances --region eu-west-1 --query "Reservations[].Instances[].InstanceId"

# ৫. দ্বিতীয় একটা profile, একবারের জন্য আর পুরো session-এর জন্য
aws configure --profile prod
aws s3 ls --profile prod
export AWS_PROFILE=prod && aws sts get-caller-identity && unset AWS_PROFILE

# ৬. instance চালু না করেই AWS-কে জিজ্ঞেস করো, তুমি চালু করতে পারতে কি না
aws ec2 run-instances --dry-run --instance-type t3.micro \
  --image-id resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64
# "Request would have succeeded, but DryRun flag is set" = তোমার permission আছে

# ৭. কাজ না থামিয়ে একটা access key rotate করো (user name আর key ID নিজেরটা বসাও)
aws iam list-access-keys --user-name dev-alice
aws iam create-access-key --user-name dev-alice              # দ্বিতীয় key; secret এখনই রেখে দাও
aws iam update-access-key --user-name dev-alice --access-key-id AKIA_OLD_KEY_ID --status Inactive
aws iam delete-access-key --user-name dev-alice --access-key-id AKIA_OLD_KEY_ID

তারপর console থেকে CloudShell খোলো, সেখানে aws sts get-caller-identity চালাও (কোনো setup ছাড়াই তোমার console-এর identity দেখাবে), echo hi > ~/note.txt দিয়ে একটা file বানাও, console-কে অন্য Region-এ নিয়ে যাও, আবার CloudShell খোলো আর ls ~ চালাও: file-টা সেখানে নেই।

#সারসংক্ষেপ

মূল কথাগুলো

• Console, CLI, SDK আর CloudShell একই API-র চারটা client। প্রতিটা কাজ একটা Region-এর service endpoint-এ পাঠানো একটা sign করা HTTPS request; AWS আগে দেখে তুমি কে, তারপর দেখে তোমার অনুমতি আছে কি না।
• বেশির ভাগ service regional: ভুল Region-এ খুঁজলে account ফাঁকা দেখায়, কিছু মোছা হয় না। IAM global।
• Access key = access key ID (user name-এর মতো) + secret access key (password-এর মতো)। শুধু CLI, SDK আর API-র জন্য, console sign in-এর জন্য কখনো না। secret দেখা যায় একবারই; প্রতি user-এর সর্বোচ্চ দুটো, rotate করার জন্য; Active বা Inactive; root-এর একটাও থাকা উচিত না। AKIA = লম্বা মেয়াদের, ASIA = অস্থায়ী, সাথে session token।
• SigV4 প্রতিটা request sign করে secret থেকে বের করা এমন একটা key দিয়ে, যেটা একটা তারিখ, একটা Region আর একটা service-এর জন্যই কাজ করে। secret কখনো পাঠানো হয় না; signature প্রমাণ করে পরিচয়, অখণ্ডতা আর টাটকা থাকা (মোটামুটি পাঁচ মিনিট)।
• aws configure লেখে ~/.aws/credentials (গোপন জিনিস) আর ~/.aws/config (Region, output, profile, যেখানে নাম লেখা হয় [profile name])। --profile বা AWS_PROFILE ব্যবহার করো; aws sts get-caller-identity আর aws configure list দিয়ে যাচাই করো।
• CLI আর SDK খোঁজে option → environment variable → shared file → container role → instance role, আর প্রথম যে credential পায় সেটাই নেয়। রয়ে যাওয়া environment variable তোমার profile-কে হারিয়ে দেয়।
• অল্প মেয়াদের credential বেছে নাও: মানুষের জন্য aws login বা IAM Identity Center, AWS-এ চলা code-এর জন্য IAM role।
• CloudShell: তোমার console-এর permission নিয়ে চলা browser terminal, কোনো key নেই, খরচ নেই, প্রতি Region-এ 1 GB স্থায়ী home, ১২০ দিন অব্যবহৃত থাকলে মুছে যায়, ২০–৩০ মিনিট নিষ্ক্রিয় থাকলে session শেষ, সর্বোচ্চ মোটামুটি ১২ ঘণ্টা।
• ফাঁস হওয়া বা code-এ লেখা key: সাথে সাথে inactive আর rotate করো, CloudTrail দিয়ে খোঁজ নাও, পরিষ্কার করো, আর কাজটাকে একটা role-এ সরিয়ে নাও।
• Infrastructure as code (CloudFormation, CDK, Terraform) একটা বর্ণনাকে সেই একই API call-এ পরিণত করে, তাই environment বারবার একইভাবে বানানো আর মোছা যায়।

নিজেকে যাচাই করো: Console, CLI, SDK আর CloudShell৩০টি প্রশ্ন