Outposts, Batch, AppFlow, Amplify আর Instance Scheduler

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

• AWS Outposts কী তা বোঝাতে (rack আর 1U/2U server, দ্বিতীয় প্রজন্মের rack), কার দায়িত্ব কী, service link আর local gateway কীভাবে কাজ করে, link ছিঁড়ে গেলে কী চলতে থাকে, আর Outposts, Local Zone, Dedicated Local Zone, Wavelength আর বন্ধ হয়ে আসা Snow family-র মধ্যে বেছে নিতে।
• AWS Batch বোঝাতে: job definition, priority-সহ job queue, managed আর unmanaged compute environment (EC2, Spot, Fargate, EKS), array job, dependency, retry strategy আর timeout, আর এটা কেন শূন্যে নেমে যায়।
• Batch, Lambda, Fargate আর Step Functions-এর মধ্যে আসল পার্থক্য (১৫ মিনিট, ১০ GB memory, GPU নেই) দিয়ে বাছতে, “শুধু Batch-ই container চালায়” এই ভুল ধারণা দিয়ে না।
• Amazon AppFlow দিয়ে Salesforce, SAP, Zendesk বা Slack-এর মতো SaaS application আর S3 বা Redshift-এর মধ্যে ডেটা আনা-নেওয়া করতে, schedule, event, filter, mapping আর PrivateLink-সহ, আর একে Glue, DMS, DataSync আর Kinesis থেকে আলাদা করতে।
• AWS Amplify বোঝাতে: Amplify Hosting (Git-ভিত্তিক CI/CD, preview, Next.js-এর SSR) আর Gen 2 backend (Cognito, DynamoDB-সহ AppSync, S3, Lambda), আর একে Elastic Beanstalk, App Runner আর S3 + CloudFront-এর সঙ্গে তুলনা করতে।
• অফিস টাইমের বাইরে dev আর test resource বন্ধ রাখতে Instance Scheduler on AWS deploy করতে, সাশ্রয় হিসাব করতে, আর এটা কী বাঁচায় না (EBS, public IPv4, Savings Plan) তা জানতে।

#পাঁচটা service, প্রতিটায় একটা করে প্রশ্ন

এই লেসন দিয়ে chapter শেষ হচ্ছে পাঁচটা service-এ, যেগুলোকে পরীক্ষা keyword-এর উত্তর হিসেবে দেখে। প্রশ্ন এক বাক্যে একটা পরিস্থিতি বলে, আর বাকিদের চেয়ে একটা service সেখানে অনেক বেশি মানায়:

এদের দুটোর সঙ্গে আগেই দেখা হয়েছে: Outposts লেসন ১.২-এ, আর Batch লেসন ২৪.৪-এ। এখানে প্রতিটা service পুরোটা দেখব: এটা কী, কেন আর কখন, কীভাবে কাজ করে, পরীক্ষার keyword কী, আর পাশে কোন ভুল উত্তরগুলো বসে থাকে।

#AWS Outposts: তোমার বিল্ডিংয়ের ভেতরে AWS

লেসন ১.২ থেকে মনে করো। Local Zone, Wavelength Zone আর Outposts তিনটাই একটা parent Region-কে বাইরের দিকে টেনে লম্বা করে; এদের মধ্যে Outposts হলো সেটা, যেটা তোমার ডেটা সেন্টারে ঢোকে। Region-এর সঙ্গে link ছিঁড়ে গেলেও চালু instance টিকে থাকে, কিন্তু management থেমে যায়।

অনেক কোম্পানি hybrid cloud চালায়: কিছু system AWS-এ, কিছু নিজের server-এ। এর মানে সাধারণত কাজ করার দুটো আলাদা পথ: এক অংশের জন্য AWS console, CLI আর API, অন্য অংশের জন্য আলাদা tool, hardware আর দক্ষতা। AWS Outposts দ্বিতীয় অংশটাই তুলে দেয়। AWS নিজের hardware তোমার জায়গায় পাঠায়, বসিয়ে দেয়, আর সেটাকে একটা AWS Region-এর অংশ হিসেবে চালায়। ফলে তুমি নিজের premises-এ EC2 instance, EBS volume বা RDS database চালু করো cloud-এর মতোই একই API, console আর tool দিয়ে।

Region-এ না রেখে কেউ AWS-এর hardware বাড়িতে আনবে কেন?

• Data residency: আইন বা regulator বলছে ডেটা দেশ বা বিল্ডিং ছাড়তে পারবে না, আর সেই দেশে AWS-এর কোনো Region নেই।
• On-premises system-এর সঙ্গে কম latency: কারখানার যন্ত্র, হাসপাতালের scanner বা ব্যাংকের core system-কে কয়েক millisecond-এ উত্তর দিতে হবে, আর সবচেয়ে কাছের Region-ও অনেক দূরে।
• স্থানীয়ভাবে ডেটা প্রসেস করা: জায়গাতেই প্রচুর ডেটা তৈরি হয়, আগে বাইরে পাঠাতে গেলে অনেক খরচ বা অনেক সময়।
• সহজে migration: আগে নিজের জায়গাতেই application-কে AWS-এর API-তে আনো, পরে Region-এ সরাও।
• পুরোপুরি managed: hardware-এর নজরদারি, patch আর বদল AWS-ই করে।

#Rack আর server

Outposts দুই আকারে আসে:

এপ্রিল ২০২৫-এ AWS দ্বিতীয় প্রজন্মের Outposts rack আনে: নতুন instance family (শুরুতে C7i, M7i, R7i, ফেব্রুয়ারি ২০২৬ থেকে C8i, M8i আর R8i), network device নষ্ট হলেও টিকে থাকে এমন আলাদা network rack, আর local gateway-এর setting নিজে করে নেওয়ার সুবিধা। এরা এখনো প্রথম প্রজন্মের service-গুলোর একটা অংশই সমর্থন করে, তাই design করার আগে বর্তমান তালিকা দেখে নিও। সেপ্টেম্বর ২০২৬-এ এসেছে এক-rack-এর দ্বিতীয় প্রজন্মের Outpost।

দাম হয় তিন বছরের মেয়াদে (সব আগে, কিছু আগে, বা আগে কিছুই না), order করার সময় যে server আর storage-এর configuration বাছো তার জন্য। Outpost-এর EC2 capacity-র জন্য instance-ঘণ্টা ধরে দাম দাও না: rack তো কিনেই ফেলেছ, তাই পুরোটা কাজে লাগানোর পরিকল্পনা করো।

#কার কাজ কী

#Service link আর local gateway

প্রতিটা Outpost তার parent Region-এর একটা Availability Zone-এর বাড়তি অংশ। এর ওপর তুমি তোমার VPC-র subnet বানাও, আর সেখানের instance একই VPC-র ভেতরে Region-এর instance-এর সঙ্গে private ভাবে কথা বলে।

• Service link হলো Outpost থেকে Region পর্যন্ত encrypted connection, internet বা Direct Connect দিয়ে (লেসন ২২.৫)। Management-এর traffic (চালু করা, বন্ধ করা, নজরদারি) আর Outpost-Region-এর মধ্যের যেকোনো traffic এটা দিয়েই যায়।
• Local gateway (rack-এ) হলো Outpost-এর subnet আর তোমার on-premises network-এর মাঝের একটা virtual router। Core banking system বা কারখানার যন্ত্রের traffic বিল্ডিংয়ের ভেতরেই থাকে। Outposts server-এ এর বদলে থাকে local network interface।

Service link বন্ধ হলে চালু instance চলতেই থাকে, স্থানীয় traffic-ও চলে, কিন্তু resource চালু, বন্ধ বা বদল করা যায় না, আর monitoring-এর ডেটা অপেক্ষায় থাকে। তাই AWS দুই পথের service link চায়, আর তুমি বাড়তি capacity আগে থেকেই চালু রাখো।

#Outposts, না অন্য কোনো edge option?

#AWS Batch: যে কাজ শুরু হয়, আর শেষও হয়

Batch job-এর একটা শুরু আর একটা শেষ আছে, web server-এর মতো সারাক্ষণ চলে না। রাতের report বানানো, genome alignment, risk simulation, video rendering, file রূপান্তর: সবই batch job। নিজে চালাতে গেলে বানাতে হয় একটা queue, একটা scheduler, একটা Auto Scaling fleet, retry-এর logic, আর শেষে সব বন্ধ করার উপায়। AWS Batch এই সবকিছুই একটা managed service হিসেবে দেয়: তুমি job submit করো, Batch ঠিকঠাক compute আর memory জোগাড় করে, job-গুলো container হিসেবে চালায়, তারপর গুছিয়ে বন্ধ করে। Batch নিজে বিনা পয়সায়; দাম দাও শুধু সে যে EC2 instance বা Fargate task চালায় তার।

লেসন ২৪.৪-এ Batch এসেছিল HPC-র জন্য (Spot-এ array job, MPI-এর জন্য multi-node parallel job)। এখানে দেখব service-টা নিজে কীভাবে কাজ করে।

#চারটা মূল অংশ

1. Job definition

   Job-এর একটা ছাঁচ: container image (ECR বা কোনো public registry থেকে), command, vCPU, memory আর GPU, environment variable, job-এর জন্য একটা IAM role, একটা retry strategy আর একটা timeout। ECS-এর task definition-এর মতো, revision ধরে version রাখা হয়।

2. Job queue

   Submit করা job যেখানে অপেক্ষা করে। প্রতিটা queue-এর একটা priority থাকে: কয়েকটা queue একই compute environment ভাগ করলে, যে queue-এর priority-র সংখ্যা বেশি, সে আগে সুযোগ পায়। একটা queue ক্রম অনুযায়ী তিনটা পর্যন্ত compute environment-এর সঙ্গে যুক্ত থাকে: আগে Spot চেষ্টা করো, তারপর On-Demand। Fair-share scheduling policy দিয়ে বিভিন্ন team-এর মধ্যে capacity ভাগ করা যায়।

3. Compute environment

   যে capacity job চালায়। Managed (Batch তোমার হয়ে instance চালু আর বন্ধ করে) বা unmanaged (ECS container instance তুমি নিজে চালাও)। এর থাকে minimum, desired আর maximum vCPU; minimum 0 হলে কোনো job অপেক্ষায় না থাকলে এটা শূন্যে নেমে যায়।

4. Scheduler

   Batch-এর scheduler queue-গুলো দেখে, কোনটা কোথায় আঁটবে হিসাব করে, compute environment বাড়ায়, job বসায়, আর queue খালি হলে কমিয়ে আনে। একটা job এই অবস্থাগুলো পার হয়: SUBMITTED → PENDING → RUNNABLE → STARTING → RUNNING → SUCCEEDED বা FAILED।

#Compute environment-এর ধরন

Documentation-এ এখন ECS Managed Instances compute environment-ও আছে; পরীক্ষার option হলো EC2, Spot আর Fargate।

#Job-এর ধরন আর dependency

• Single job: একবার একটা container চালানো।
• Array job: একবার submit করলেই ২ থেকে ১০,০০০টা child job তৈরি হয়, সবার একই definition; প্রতিটা AWS_BATCH_JOB_ARRAY_INDEX থেকে নিজের index পড়ে নিজের input file বাছে। “হাজার হাজার স্বাধীন কাজ” চালানোর চেনা উপায় এটাই।
• Dependency: একটা job আরও ২০টা পর্যন্ত job-এর ওপর নির্ভর করতে পারে, সেগুলো সফল হলেই শুরু হয়; array job উপাদান ধরে ধরে নির্ভর করতে পারে (N_TO_N) বা child-গুলোকে একটার পর একটা চালাতে পারে (SEQUENTIAL)। সহজ pipeline-এর জন্য এটুকুই যথেষ্ট; শাখা, অপেক্ষা আর error সামলানোর দরকার হলে Step Functions-কে দিয়ে Batch job submit করাও (লেসন ১৫.৭)।
• Multi-node parallel job: MPI-এর জন্য কয়েকটা EC2 instance জুড়ে একটা job, শুধু On-Demand-এ (লেসন ২৪.৪)।

Job submit করা যায় console, CLI বা SDK থেকে, একটা EventBridge rule বা schedule থেকে (S3-এ file এলো, প্রতি রাত ২টায়), বা Step Functions থেকে। Slide p849-এর উদাহরণ ঠিক এটাই: S3-এ একটা object এলো, একটা trigger Batch job submit করল, job ECS-এর মাধ্যমে EC2 বা Spot-এ চলল, আর প্রসেস করা object আবার S3-তে লিখল।

#Retry, timeout আর Spot interruption

• Batch নিজে থেকে আবার চেষ্টা করে না। Retry strategy দিয়ে ১ থেকে ১০টা attempt ঠিক করো, আর চাইলে শুধু নির্দিষ্ট কারণেই আবার চালাও, যেমন status reason Host EC2 দিয়ে শুরু হলে (Spot instance ফেরত নেওয়া হয়েছে), কিন্তু application crash করলে না।
• Batch-এ job কতক্ষণ চলবে তার কোনো সর্বোচ্চ সীমা নেই, default timeout-ও নেই: আটকে যাওয়া job চিরকাল চলবে, আর bill-ও হবে। Job definition-এ বা submit-এর সময় attemptDurationSeconds দাও (অন্তত ৬০ সেকেন্ড); তখন Batch SIGTERM পাঠায়, ৩০ সেকেন্ড পর SIGKILL। Timeout-এ থামানো job আবার চালানো হয় না। Fargate-এর job প্রায় ১৪ দিনের বেশি চলবে এমন আশা কোরো না।
• একটা job RUNNABLE-এ আটকে থাকা মানে প্রায় সবসময় compute environment সে যা চায় তা চালু করতে পারছে না: instance type খুব ছোট, maximum vCPU খুব কম, EC2 quota শেষ, বা private subnet থেকে ECR, ECS আর CloudWatch Logs-এ যাওয়ার পথ নেই (NAT gateway বা VPC endpoint, লেসন ২২.২)।

#Batch বনাম Lambda, আর Fargate কোথায় বসে

Notes চেনা নিয়মটাই দেয়: প্রসেসিংয়ে ২০ মিনিট বা কয়েক ঘণ্টা লাগলে Lambda বাদ দাও, Batch (বা Fargate) বাছো। নিয়মটা ঠিক; কারণগুলো একটু সাবধানে বুঝতে হবে।

তাহলে আসল পার্থক্য হলো সময় (১৫ মিনিট), memory (১০ GB) আর GPU, সঙ্গে কাজের ধরন: দ্রুত উত্তর চাওয়া একটা event, নাকি job-এর একটা queue। লেসন ১৫.১ (Lambda-র মূল কথা)-এ Lambda durable function (ডিসেম্বর ২০২৫)-এর কথাও আছে, যেটা checkpoint রাখে আর ধাপের মাঝে এক বছর পর্যন্ত অপেক্ষা করতে পারে, আর Lambda Managed Instances-এর কথাও; কোনোটাই একটা লম্বা, ভারী run-এর জন্য পরীক্ষার উত্তর বদলায় না।

আর Fargate? Fargate-এর একটা ECS task-এরও সময়ের কোনো সীমা নেই, ১৬ vCPU আর ১২০ GB memory পর্যন্ত, GPU নেই। প্রতি event-এ একটা লম্বা কাজ হলে (একটা upload থেকে ৪০ মিনিটের একটা রূপান্তর) EventBridge বা Step Functions দিয়ে চালু করা Fargate-এর ECS task Batch-এর মতোই ভালো। Priority, retry, Spot আর dependency-সহ queue-তে জমা অনেক job হলে Batch হলো সেই scheduler, যেটা নইলে তোমাকে নিজে বানাতে হতো। Step Functions সমন্বয় করে; নিজে ভারী code চালায় না, তাই এটা হলো আঠা, যেটা Lambda, Fargate বা Batch চালু করে।

তোমার নিজের workload নিয়ে যুক্তিটা খাটিয়ে দেখো। নিচের পছন্দগুলো পরীক্ষার প্রশ্নই ব্যবহার করে।

#Amazon AppFlow: integration code ছাড়াই SaaS-এর ডেটা

কোম্পানির জরুরি ডেটা থাকে SaaS application-এ: deal থাকে Salesforce-এ, order SAP-এ, ticket Zendesk বা ServiceNow-এ, message Slack-এ, web traffic Google Analytics-এ, campaign Marketo-তে। Analyst-রা এগুলো নিজেদের ডেটার পাশে S3 বা Redshift-এ চান। Integration code লিখতে গেলে প্রতিটা vendor-এর API শিখতে হয়, OAuth token, paging, rate limit, retry আর schema বদল সামলাতে হয়, তারপর সারাজীবন script দেখাশোনা করতে হয়। Amazon AppFlow একটা পুরোপুরি managed, code ছাড়া integration service, কয়েকটা click-এ SaaS application আর AWS-এর মধ্যে ডেটা আনা-নেওয়া করে।

#একটা flow কীভাবে কাজ করে

1. Connection

   AppFlow-কে SaaS account-এর সঙ্গে একবার জুড়ে দাও (সাধারণত OAuth)। AppFlow credential রাখে তোমার account-এর Secrets Manager-এ। কয়েক ডজন connector আগে থেকেই আছে, আর Custom Connector SDK (Python, Java) দিয়ে private API বা অন্য system যোগ করা যায়।

2. Source আর destination

   Source: Salesforce, SAP, Zendesk, Slack, ServiceNow, Google Analytics, Marketo, S3 আর আরও অনেক। Destination: S3, Redshift, Snowflake, EventBridge, আর Salesforce বা Zendesk-এর মতো SaaS application। Flow দুই দিকেই যেতে পারে: যেমন S3 থেকে আবার Salesforce-এ।

3. Trigger

   On demand (একটা click বা API call), schedule ধরে (প্রতি ঘণ্টা, প্রতিদিন; পুরো ডেটা, বা শুধু বদলানো record-এর incremental transfer), বা event-এ, সেইসব source-এর জন্য যারা change event পাঠায়, যেমন Salesforce-এর record বদল।

4. বদলে নিয়ে পৌঁছে দেওয়া

   Record filter করো (শুধু জেতা deal), field map আর একসঙ্গে জোড়া করো, স্পর্শকাতর field mask বা ছেঁটে দাও, মান validate করো (খালি amount হলে বাদ দাও বা থামো), file format বাছো (CSV, JSON, Parquet), তারিখ ধরে partition করো, আর ডেটা Glue Data Catalog-এ নথিভুক্ত করো।

ডেটা পথে encrypted থাকে (TLS), আর জমা অবস্থায় একটা KMS key দিয়ে (AWS managed বা তোমার নিজের)। যেসব SaaS application সমর্থন করে, সেখানে transfer public internet-এর বদলে AWS PrivateLink দিয়ে যায়। দাম দাও প্রতি flow run আর প্রতি GB প্রসেস করা ডেটার জন্য। প্রতিটা run-এর ফল (সফল বা fail) EventBridge-এ যায়, তাই fail করা flow একটা alarm বাজাতে পারে।

#AppFlow, না অন্য কোনো data service?

#AWS Amplify: front-end developer-দের জন্য full-stack app

একজন front-end developer React বা Next.js-এর interface, বা iOS, Android বা Flutter-এর app বানাতে পারেন, কিন্তু তাতে sign-in, database, file upload, API, HTTPS hosting আর স্বয়ংক্রিয় deployment যোগ করতে গেলে সাধারণত এক ডজন AWS service শিখতে হয়। AWS Amplify হলো tool আর service-এর একটা সেট, যেটা web আর mobile developer-দের গভীর cloud জ্ঞান ছাড়াই AWS-এ full-stack application বানাতে, জুড়তে আর deploy করতে দেয়। এর দুটো অংশ।

#Amplify Hosting

Amplify Hosting (slide-এর “Amplify Console”, নাম বদলেছে) হলো Git-ভিত্তিক CI/CD আর hosting একসঙ্গে:

• GitHub, GitLab, Bitbucket বা অন্য কোনো Git provider-এর repository জুড়ে দাও, অথবা একটা zip upload করো বা S3 থেকে deploy করো।
• জোড়া branch-এ প্রতিটা push app build করে deploy করে; প্রতিটা branch-এর নিজের environment থাকতে পারে (main → production, dev → staging)।
• Pull request preview প্রতিটা pull request-কে নিজের একটা অস্থায়ী URL দেয়।
• Static site আর server-side rendering (SSR), বিশেষ করে Next.js, চলে একটা CloudFront-ভিত্তিক CDN দিয়ে, custom domain, বিনা পয়সার managed HTTPS certificate, redirect, password দিয়ে সুরক্ষিত branch আর AWS WAF-সহ।
• Fail করা build কখনো চালু site-এর জায়গা নেয় না; আগের deployment আবার deploy করা যায়।

#Backend: Gen 2

Amplify Gen 2 (মে ২০২৪ থেকে সবার জন্য) code-first: amplify/ folder-এর TypeScript file-এ তুমি backend বর্ণনা করো, আর Amplify নিচে CDK আর CloudFormation দিয়ে সেগুলোকে AWS resource বানায় (লেসন ২৫.১):

প্রতিটা developer নিজের একটা cloud sandbox পায় (npx ampx sandbox), যেটা কয়েক সেকেন্ডে তার বদলগুলো deploy করে, আর একই file Amplify Hosting দিয়ে প্রতিটা branch-এ deploy হয়। Front-end library (React, Angular, Vue আর Next.js-এর জন্য JavaScript; Swift; Android; Flutter; React Native) আর তৈরি UI component (যেমন একটা sign-in form) app-কে backend-এর সঙ্গে জোড়ে। পুরোনো Gen 1 ব্যবহার করত Amplify CLI (amplify add auth) আর Amplify Studio, slide p853 সেটাই দেখায়; তার category-গুলো (REST বা GraphQL-এর API, publish-subscribe messaging, analytics, predictions) এখন বেশিরভাগই Gen 2 backend-এ সাধারণ CDK বা AWS service হিসেবে যোগ হয়।

#Amplify, না hosting-এর অন্য কোনো উপায়?

#Instance Scheduler on AWS: কেউ ব্যবহার না করলে বন্ধ রাখো

যে development server দিনে ২৪ ঘণ্টা, সপ্তাহে ৭ দিন চলে, সে চলে ১৬৮ ঘণ্টা। Developer-রা যদি পাঁচ কর্মদিবসে সকাল ৯টা থেকে সন্ধ্যা ৬টা ব্যবহার করে, তাহলে লাগে ৪৫ ঘণ্টা: বাকি ১২৩ ঘণ্টা পুরোটাই অপচয়। Instance Scheduler on AWS resource-এর tag দেখে schedule ধরে সেগুলো চালু আর বন্ধ করে, আর AWS বলে এতে এমন instance-এর খরচ ৭০% পর্যন্ত কমে।

এটা একটা AWS Solution, service না: AWS একটা CloudFormation template প্রকাশ করে (GitHub-এ CDK source-সহ), যেটা তুমি নিজের account-এ deploy করো। যা তৈরি হয় তার মালিক তুমি, দামও তুমি দাও; solution-টা নিজে us-east-1-এ মাসে প্রায় ১৩ ডলার।

#কীভাবে কাজ করে

• একটা EventBridge rule নির্দিষ্ট বিরতিতে (default-এ প্রতি ৫ মিনিটে) একটা Lambda function চালায়।
• Function DynamoDB table থেকে schedule আর period পড়ে। একটা period-এ থাকে শুরুর সময়, শেষের সময় আর সপ্তাহের দিন (চাইলে মাসের তারিখ বা মাস); একটা schedule কয়েকটা period-কে একসঙ্গে রাখে, একটা time zone আর কিছু option-সহ।
• যেসব resource-এর tag (default-এ Schedule) ওই schedule-এর নাম বলে, সেগুলো খুঁজে period শুরু বা শেষ হলে চালু বা বন্ধ করে।
• সমর্থিত resource: EC2 instance, EC2 Auto Scaling group (scheduled scaling action বানিয়ে), RDS instance, Aurora cluster, আর version 3.0 (জুন ২০২৪) থেকে Neptune আর DocumentDB cluster। EC2 instance বন্ধ না করে hibernate-ও করা যায়।
• Cross-account আর cross-Region: hub stack একটা account-এ deploy হয়; বাকি প্রতিটা account-এ একটা remote stack তাকে assume করার মতো একটা role দেয়। তুমি যে Region-গুলো ঠিক করে দাও, তার প্রতিটার tag-ওয়ালা resource-এ এটা কাজ করে।
• জানার মতো option: enforced (period-এর বাইরে হাতে চালু করা instance-ও বন্ধ করো), retain running (period শুরুর আগে কেউ চালু করে থাকলে শেষে বন্ধ কোরো না), আর কোনো ঘটনার সময় সব চালু বা সব বন্ধ রাখার জন্য একটা override।
• Schedule সামলাও scheduler CLI দিয়ে, DynamoDB-তে, বা CloudFormation resource হিসেবে। বর্তমান release 3.2 (অক্টোবর ২০২৬); version 3.1 (ডিসেম্বর ২০২৫) tagging event থেকে resource-এর হিসাব রাখা যোগ করেছে।

#কী বাঁচায়, আর কী বাঁচায় না

EC2 instance বন্ধ করলে থামে শুধু compute-এর দাম:

• EBS volume থেকে যায়, প্রতি GB-মাসে bill হতে থাকে; snapshot-ও।
• Public IPv4 address: instance বন্ধ থাকলেও Elastic IP-এর দাম লাগে (ফেব্রুয়ারি ২০২৪ থেকে প্রতিটা public IPv4 address-এর ঘণ্টায় প্রায় $0.005)।
• Instance store-এর ডেটা বন্ধ করলেই মুছে যায়; যেসব instance এর ওপর নির্ভর করে, সেগুলো এর জন্য উপযুক্ত না।
• Reserved Instance আর Savings Plan হলো প্রতিশ্রুতি, প্রতি ঘণ্টায় দাম দিতে হয় instance চলুক বা না চলুক (লেসন ৪.৪)। পুরোপুরি আওতাভুক্ত instance বন্ধ করলে কিছুই বাঁচে না। Fleet-এর যে অংশ On-Demand-এ চলে সেটা schedule করো, আর প্রতিশ্রুতির আকার ঠিক করো সারাক্ষণ চালু অংশের জন্য।
• বন্ধ RDS instance-ও storage আর backup-এর দাম দেয়, আর RDS ৭ দিন পর নিজেই আবার চালু করে (লেসন ৭.২); Aurora cluster-ও তাই। Scheduler পরের run-এ আবার বন্ধ করে দেয়।

#আরও সহজ, আর বিকল্প উপায়

• EventBridge Scheduler: cron expression আর time zone দিয়ে, universal target হিসেবে সরাসরি ec2:StopInstances ডাকো, বা AWS-StopEC2Instance-এর মতো একটা SSM Automation runbook চালাও (লেসন ২৫.৩)। অল্প কয়েকটা resource হলে এটাই যথেষ্ট।
• Systems Manager Quick Setup-এ tag-ওয়ালা EC2 instance-এর জন্য একটা Resource Scheduler আছে।
• Auto Scaling scheduled action: একটা group-এর desired capacity সন্ধ্যা ৬টায় ০, সকাল ৯টায় আবার আগের মতো।
• লম্বা বিরতিতে (কয়েক সপ্তাহ) snapshot নিয়ে terminate করো, পরে restore করো।

#পাঁচটার কোনটা? একটা keyword table

#কোথায় ভুল হয়

• Outpost-এ capacity কম বলে launch fail করে: Outpost-এ শুধু ততটুকুই আছে যতটুকু order করেছ। বাড়তি capacity order করো, বা হঠাৎ বাড়া কাজ Region-এ রাখো।
• Outpost-এ কিছুই চালু করা যাচ্ছে না: service link বন্ধ। চালু কাজ চলতে থাকে; link দুই পথে বানাও।
• তবুও ডেটা দেশের বাইরে গেল: Outpost-এর volume-এর EBS snapshot Region-এর S3-তে গেছে। S3 on Outposts-এ local snapshot ব্যবহার করো, আর IAM policy বা SCP দিয়ে বাইরে কপি নিষেধ করো।
• Outposts server-এ EBS নেই: server-এ শুধু instance storage; EBS, S3 বা RDS লাগলে rack বাছো।
• Batch job RUNNABLE-এ আটকে: job-এর memory বা GPU-র জন্য instance type ছোট, maximum vCPU বা EC2 quota কম, বা private subnet থেকে ECR-এ যাওয়ার পথ নেই।
• Spot-এ Batch job হারিয়ে যায়: retry strategy নেই। Attempt ঠিক করো, Host EC2* কারণে আবার চালাও।
• আটকে থাকা একটা Batch job এক সপ্তাহ bill করল: timeout নেই। attemptDurationSeconds দাও।
• Lambda বলছে “Task timed out after 900.00 seconds”: কাজটা ১৫ মিনিটের বেশি। ভাগ করো (SQS, Step Functions Map), বা Batch বা Fargate-এ সরাও।
• মাসের পর মাস ঠিক চলার পর AppFlow flow fail করছে: connection-এর পেছনের SaaS user বা OAuth token বন্ধ করা হয়েছে। Fail করা run-এ alert দাও, আবার connect করো।
• AppFlow থেকে duplicate row: incremental-এর বদলে প্রতি ঘণ্টায় পুরো transfer চলছে।
• Amplify build fail করছে: চালু site শেষ ভালো build-এই থাকে; build log পড়ো। Environment-এর secret রাখো Amplify-এর secret setting-এ, repository-তে না।
• Instance Scheduler একটা server বাদ দিচ্ছে: tag-এর value বা key-তে বানান ভুল, বা Region-টা scheduler-এর ঠিক করা Region-এর তালিকায় নেই।
• Instance Scheduler আশার চেয়ে কম বাঁচাল: instance-গুলো Savings Plan বা RI-এর আওতায়, বা bill-এর বড় অংশ EBS আর Elastic IP।
• ছুটির ৮ম দিনে একটা dev database চলছে: ৭ দিন পর RDS নিজেই চালু করেছে, আর আবার বন্ধ করার কেউ ছিল না।

#System design-এ এই service-গুলো

• Outposts দিয়ে hybrid: নিয়ন্ত্রিত ডেটা আর latency-সংবেদনশীল system Outpost-এ রাখো, নাম-পরিচয় মুছে ফেলা ডেটা আর ওঠানামা করা কাজ parent Region-এ পাঠাও, আর দুই জায়গাতেই একই CloudFormation, IAM আর monitoring ব্যবহার করো। Service link-কে জরুরি infrastructure হিসেবে দেখো।
• Event থেকে চলা batch pipeline: S3 upload → EventBridge → Spot-এ Batch array job (retry আর timeout-সহ) → ফলাফল S3-তে → Athena বা QuickSight। Pipeline-এ শাখা বা মানুষের অনুমোদন লাগলে Step Functions ব্যবহার করো।
• প্রতিটা ধাপের জন্য মানানসই compute: ছোট জোড়ার কাজে Lambda, একটা লম্বা কাজে Fargate, job-এর queue-তে Batch, পরস্পর-নির্ভর HPC-তে EC2 বা ParallelCluster।
• SaaS থেকে lake-এ: AppFlow (incremental, Parquet, Glue Data Catalog) → S3 → Athena বা Redshift; AWS-এ হিসাব করা score আবার Salesforce-এ ফেরত।
• Front-end-কেন্দ্রিক product: web app-এর জন্য Amplify Hosting, Cognito, AppSync আর S3-এর জন্য Gen 2, branch ধরে environment; app বড় হলে CDK দিয়ে আরও AWS service যোগ করো।
• খরচের পরিচ্ছন্নতা: non-production-এর জন্য Instance Scheduler, সারাক্ষণ চালু ভিত্তির জন্য প্রতিশ্রুতি (Savings Plan), batch কাজের জন্য শূন্যে নামা Batch আর Spot। অপচয় খুঁজে বের করার cost tool আছে লেসন ২৫.৪-এ; Well-Architected-এর cost optimisation pillar আসছে লেসন ২৬.১-এ।

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

এই command-গুলো বানানো ID দিয়ে AWS CLI v2 ব্যবহার করে। Outposts আগে order করতে হয়, তাই তার command শুধু পড়ে। Batch, AppFlow আর Amplify-এর resource শুধু চলার বা ডেটা রাখার সময় দাম নেয়; পরে মুছে দিও।

# Outposts: what is installed, and the local gateway to the on-premises network
aws outposts list-outposts --query 'Outposts[].[OutpostId,Name,SiteId,AvailabilityZone,LifeCycleStatus]' --output text
# op-0ab12cd34ef567890   dhaka-dc1   os-0123456789abcdef0   ap-south-1a   ACTIVE
aws ec2 describe-local-gateways --query 'LocalGateways[].[LocalGatewayId,OutpostArn,State]' --output text
# lgw-0a1b2c3d4e5f67890   arn:aws:outposts:ap-south-1:111122223333:outpost/op-0ab12cd34ef567890   available
aws outposts get-outpost-instance-types --outpost-id op-0ab12cd34ef567890 --query 'InstanceTypes[].InstanceType'
# [ "m5.xlarge", "m5.2xlarge", "r5.2xlarge" ]

# Batch: a Spot compute environment that scales to zero, a queue, a job definition with retries and a timeout
aws batch create-compute-environment --compute-environment-name sims-spot --type MANAGED \
  --compute-resources 'type=SPOT,allocationStrategy=SPOT_PRICE_CAPACITY_OPTIMIZED,minvCpus=0,maxvCpus=512,instanceTypes=optimal,subnets=subnet-0a1b2c3d4e5f67890,securityGroupIds=sg-0123456789abcdef0,instanceRole=ecsInstanceRole'
# (a second environment, sims-ondemand, is created the same way with type=EC2)
aws batch create-job-queue --job-queue-name sims --priority 10 \
  --compute-environment-order order=1,computeEnvironment=sims-spot order=2,computeEnvironment=sims-ondemand
aws batch register-job-definition --job-definition-name trial-sim --type container \
  --container-properties '{"image":"111122223333.dkr.ecr.ap-south-1.amazonaws.com/trial-sim:4","resourceRequirements":[{"type":"VCPU","value":"2"},{"type":"MEMORY","value":"4096"}],"command":["python","sim.py"]}' \
  --retry-strategy '{"attempts":3,"evaluateOnExit":[{"onStatusReason":"Host EC2*","action":"RETRY"},{"onReason":"*","action":"EXIT"}]}' \
  --timeout attemptDurationSeconds=7200

# One array job of 1,000 children; each reads AWS_BATCH_JOB_ARRAY_INDEX
aws batch submit-job --job-name trial-2026-11-01 --job-queue sims --job-definition trial-sim --array-properties size=1000
# { "jobName": "trial-2026-11-01", "jobId": "8f1e2d3c-4b5a-6978-8a9b-0c1d2e3f4a5b" }
aws batch describe-jobs --jobs 8f1e2d3c-4b5a-6978-8a9b-0c1d2e3f4a5b --query 'jobs[0].arrayProperties.statusSummary'
# { "RUNNABLE": 612, "RUNNING": 200, "SUCCEEDED": 186, "FAILED": 2 }

# AppFlow: start a flow on demand and check its runs (the flow and connection are created in the console or with create-flow)
aws appflow start-flow --flow-name salesforce-won-deals-hourly
# { "flowArn": "arn:aws:appflow:ap-south-1:111122223333:flow/salesforce-won-deals-hourly", "flowStatus": "Active", "executionId": "c0ffee00-1234-5678-9abc-def012345678" }
aws appflow describe-flow-execution-records --flow-name salesforce-won-deals-hourly \
  --query 'flowExecutions[0].[executionStatus,executionResult.recordsProcessed]' --output text
# Successful   3412

# Amplify Gen 2: a new project, a personal cloud sandbox, then hosting connected to Git
npm create amplify@latest        # adds the amplify/ folder (auth, data) to your app
npx ampx sandbox                 # deploys your own backend copy and watches for changes
# [Sandbox] Watching for file changes... amplify_outputs.json written
aws amplify create-app --name hilsa-booking --repository https://github.com/example/hilsa-booking \
  --access-token "$GITHUB_TOKEN" --platform WEB_COMPUTE
aws amplify create-branch --app-id d1a2b3c4e5f6g7 --branch-name main --stage PRODUCTION --enable-auto-build
aws amplify start-job --app-id d1a2b3c4e5f6g7 --branch-name main --job-type RELEASE

# Instance Scheduler: deploy the CloudFormation template from the solution page, then define the BD work week
scheduler-cli create-period --stack instance-scheduler --name bd-office-hours \
  --begintime 09:00 --endtime 18:00 --weekdays sun,mon-thu     # Instance Scheduler-এ mon হল day 0, তাই Sunday আলাদা করে লিখতে হয়
scheduler-cli create-schedule --stack instance-scheduler --name bd-office \
  --periods bd-office-hours --timezone Asia/Dhaka --enforced
aws ec2 create-tags --resources i-0a1b2c3d4e5f67890 --tags Key=Schedule,Value=bd-office
aws rds add-tags-to-resource --resource-name arn:aws:rds:ap-south-1:111122223333:db:dev-db \
  --tags Key=Schedule,Value=bd-office
scheduler-cli describe-schedule-usage --stack instance-scheduler --name bd-office
# Shows, per day, the periods the schedule keeps resources running and the billing hours (9 a day here)

#সারসংক্ষেপ

মূল কথা

• Outposts: তোমার facility-তে AWS-এর rack (42U) বা 1U/2U server (নতুন গ্রাহকের কাছে আর বিক্রি হয় না), AWS চালায় একটা Region-এর AZ-এর বাড়তি অংশ হিসেবে; একই API আর tool। জায়গা, বিদ্যুৎ, network আর physical security দাও তুমি। Parent Region-এর সঙ্গে service link (management); on-premises-এর সঙ্গে local gateway। Link বন্ধ → চালু কাজ চলে, নতুন launch না। Capacity নির্দিষ্ট, তিন বছরের মেয়াদ। এপ্রিল ২০২৫ থেকে দ্বিতীয় প্রজন্মের rack। Keyword: data residency, on-premises-এর সঙ্গে কম latency। Local Zone (শহর), Wavelength (5G), Snow (নভেম্বর ২০২৫ থেকে নতুন গ্রাহকের জন্য বন্ধ) না।
• Batch: container হিসেবে managed batch job; job definition → job queue (priority, ক্রম অনুযায়ী তিনটা পর্যন্ত compute environment) → compute environment (managed EC2, Spot, Fargate, EKS; unmanaged); min 0 vCPU → শূন্যে নামে; ১০,০০০ পর্যন্ত array job; dependency; retry strategy (১–১০ attempt); সর্বোচ্চ সময়ের সীমা নেই কিন্তু ঐচ্ছিক timeout (≥ ৬০ সেকেন্ড, আবার চালানো হয় না)। Batch নিজে বিনা পয়সায়।
• Batch বনাম Lambda: Lambda = event, ১৫ মিনিট, ১০ GB memory, ১০ GB /tmp, GPU নেই, ১০ GB পর্যন্ত container; Batch = যেকোনো দৈর্ঘ্য আর আকারের queue-তে থাকা job, GPU, Spot। ১৫ মিনিটের বেশি → Batch বা Fargate। Container পার্থক্য না।
• AppFlow: code ছাড়া, managed SaaS ↔ AWS data flow (Salesforce, SAP, Zendesk, Slack, ServiceNow → S3, Redshift, Snowflake, আবার Salesforce-এ); on demand, schedule (incremental), event; filter, map, mask, validate; KMS encryption, PrivateLink। Glue (code-এর ETL), DMS (database), DataSync (file), Kinesis (stream) না।
• Amplify: Hosting (Git CI/CD, branch environment, pull request preview, SSR/Next.js, CloudFront CDN-এ custom domain) + TypeScript-এ Gen 2 backend (Cognito, AppSync + DynamoDB, S3, Lambda)। Keyword: front-end/mobile developer, React app-এ auth আর storage। Beanstalk (server app) না; App Runner এপ্রিল ২০২৬ থেকে নতুন গ্রাহকের জন্য বন্ধ।
• Instance Scheduler on AWS: CloudFormation দিয়ে deploy হওয়া একটা AWS Solution; EventBridge → Lambda → DynamoDB-এর schedule; tag দেখে চলে (Schedule); EC2, ASG, RDS, Aurora, Neptune, DocumentDB; cross-account আর cross-Region; ৭০% পর্যন্ত সাশ্রয়। বন্ধ instance-ও EBS আর Elastic IP-এর দাম দেয়; আওতাভুক্ত Savings Plan/RI-তে কিছুই বাঁচে না; ৭ দিন পর RDS নিজেই চালু হয়।

নিজেকে যাচাই করো: Outposts, Batch, AppFlow, Amplify আর Instance Scheduler৩০টি প্রশ্ন