AWS-এ Kubernetes ক্লাউড খরচ সংরক্ষণ করুন

নিবন্ধটির অনুবাদ কোর্স শুরুর প্রাক্কালে প্রস্তুত করা হয়েছিল "কুবারনেটসের উপর ভিত্তি করে অবকাঠামো প্ল্যাটফর্ম".

কুবারনেটসের সাথে কাজ করার সময় কীভাবে ক্লাউড খরচ বাঁচাতে হয়? কোন একক সঠিক সমাধান নেই, তবে এই নিবন্ধটি বেশ কয়েকটি সরঞ্জাম বর্ণনা করে যা আপনাকে আপনার সংস্থানগুলিকে আরও কার্যকরভাবে পরিচালনা করতে এবং আপনার ক্লাউড কম্পিউটিং খরচ কমাতে সাহায্য করতে পারে।

আমি AWS এর জন্য Kubernetes এর সাথে এই নিবন্ধটি লিখেছি, তবে এটি অন্যান্য ক্লাউড সরবরাহকারীদের ক্ষেত্রে (প্রায়) একইভাবে প্রযোজ্য হবে। আমি অনুমান করছি আপনার ক্লাস্টার(গুলি) ইতিমধ্যেই অটোস্কেলিং কনফিগার করা আছে (ক্লাস্টার-অটোস্কেলার) রিসোর্স অপসারণ করা এবং আপনার ডিপ্লোয়মেন্ট ডাউন স্কেল করা শুধুমাত্র আপনার অর্থ সাশ্রয় করবে যদি এটি আপনার কর্মী নোডের বহরকেও হ্রাস করে (EC2 দৃষ্টান্ত)।

এই নিবন্ধটি কভার করবে:

• অব্যবহৃত সম্পদ পরিষ্কার করা (কুবে-দারোয়ান)
• অ-কাজের সময় স্কেলিং হ্রাস করুন (কুবে-ডাউনস্কেলার)
• অনুভূমিক অটোস্কেলিং (HPA) ব্যবহার করে,
• অত্যধিক সম্পদ সংরক্ষণ হ্রাস (kube-সম্পদ-প্রতিবেদন, ভিপিএ)
• স্পট উদাহরণ ব্যবহার করে

অব্যবহৃত সম্পদ পরিষ্কার করা

দ্রুত গতির পরিবেশে কাজ করা দুর্দান্ত। আমরা প্রযুক্তি প্রতিষ্ঠান চাই ত্বরান্বিত. আরও দ্রুত সফ্টওয়্যার ডেলিভারি মানে আরও পিআর স্থাপনা, পূর্বরূপ পরিবেশ, প্রোটোটাইপ এবং বিশ্লেষণ সমাধান। সবকিছু কুবারনেটে স্থাপন করা হয়েছে। কার হাতে ম্যানুয়ালি পরীক্ষার স্থাপনা পরিষ্কার করার সময় আছে? এক সপ্তাহের পুরনো পরীক্ষা মুছে ফেলার কথা ভুলে যাওয়া সহজ। আমরা বন্ধ করতে ভুলে গেছি এমন কিছুর কারণে ক্লাউড বিল বাড়বে:

(হেনিং জ্যাকবস:
ঝিজা:
(উদ্ধৃতি) কোরি কুইন:
মিথ: আপনার AWS অ্যাকাউন্ট হল আপনার ব্যবহারকারীর সংখ্যার একটি ফাংশন।
ঘটনা: আপনার AWS স্কোর হল আপনার কতজন প্রকৌশলী আছে তার একটি ফাংশন।

ইভান কুরনোসভ (প্রতিক্রিয়ায়):
বাস্তব সত্য: আপনার AWS স্কোর হল এমন একটি ফাংশন যা আপনি অক্ষম/মুছে দিতে ভুলে গেছেন।)

কুবারনেটেস দারোয়ান (কুবে-দারোয়ান) আপনার ক্লাস্টার পরিষ্কার করতে সাহায্য করে। দারোয়ান কনফিগারেশন বিশ্বব্যাপী এবং স্থানীয় উভয় ব্যবহারের জন্য নমনীয়:

• ক্লাস্টার-ওয়াইড নিয়মগুলি PR/পরীক্ষা স্থাপনের জন্য সর্বাধিক টাইম-টু-লাইভ (TTL) সংজ্ঞায়িত করতে পারে।
• ব্যক্তিগত সম্পদ দারোয়ান/ttl দিয়ে টীকা করা যেতে পারে, উদাহরণস্বরূপ 7 দিন পর স্বয়ংক্রিয়ভাবে স্পাইক/প্রোটোটাইপ মুছে ফেলার জন্য।

সাধারণ নিয়মগুলি YAML ফাইলে সংজ্ঞায়িত করা হয়েছে। এর পাথ প্যারামিটারের মধ্য দিয়ে যায় --rules-file কুবে-দারোয়ান এখানে সমস্ত নামস্থান মুছে ফেলার জন্য একটি উদাহরণ নিয়ম রয়েছে -pr- দুই দিন পর নামে:

- id: cleanup-resources-from-pull-requests
  resources:
    - namespaces
  jmespath: "contains(metadata.name, '-pr-')"
  ttl: 2d

নিম্নলিখিত উদাহরণটি 2020 সালে সমস্ত নতুন স্থাপনা/StatefulSets-এর জন্য ডিপ্লোয়মেন্ট এবং স্টেটফুলসেট পডগুলিতে অ্যাপ্লিকেশন লেবেলের ব্যবহার নিয়ন্ত্রণ করে, কিন্তু একই সময়ে এই লেবেল ছাড়াই এক সপ্তাহের জন্য পরীক্ষা চালানোর অনুমতি দেয়:

- id: require-application-label
  # удалить deployments и statefulsets без метки "application"
  resources:
    - deployments
    - statefulsets
  # см. http://jmespath.org/specification.html
  jmespath: "!(spec.template.metadata.labels.application) && metadata.creationTimestamp > '2020-01-01'"
  ttl: 7d

কুবে-দারোয়ান চলমান একটি ক্লাস্টারে 30 মিনিটের জন্য একটি সময়-সীমিত ডেমো চালান:

kubectl run nginx-demo --image=nginx
kubectl annotate deploy nginx-demo janitor/ttl=30m

ক্রমবর্ধমান খরচের আরেকটি উৎস হল ক্রমাগত ভলিউম (AWS EBS)। একটি Kubernetes StatefulSet মুছে ফেলা তার স্থায়ী ভলিউম (PVC - PersistentVolumeClaim) মুছে দেয় না। অব্যবহৃত EBS ভলিউম সহজেই প্রতি মাসে শত শত ডলার খরচ হতে পারে। অব্যবহৃত PVC পরিষ্কার করার জন্য Kubernetes Janitor এর একটি বৈশিষ্ট্য রয়েছে। উদাহরণস্বরূপ, এই নিয়মটি এমন সমস্ত PVC গুলিকে সরিয়ে দেবে যেগুলি একটি মডিউল দ্বারা মাউন্ট করা হয় না এবং যেগুলি একটি StatefulSet বা CronJob দ্বারা উল্লেখ করা হয় না:

# удалить все PVC, которые не смонтированы и на которые не ссылаются StatefulSets
- id: remove-unused-pvcs
  resources:
  - persistentvolumeclaims
  jmespath: "_context.pvc_is_not_mounted && _context.pvc_is_not_referenced"
  ttl: 24h

Kubernetes Janitor আপনাকে আপনার ক্লাস্টার পরিষ্কার রাখতে এবং ক্লাউড কম্পিউটিং খরচগুলিকে ধীরে ধীরে বাড়তে বাধা দিতে সাহায্য করতে পারে। স্থাপনা এবং কনফিগারেশন নির্দেশাবলীর জন্য, অনুসরণ করুন README কুবে-দারোয়ান.

অ-কাজের সময় স্কেলিং হ্রাস করুন

পরীক্ষা এবং স্টেজিং সিস্টেমগুলি সাধারণত শুধুমাত্র ব্যবসায়িক সময়ে চালানোর জন্য প্রয়োজন। কিছু প্রোডাকশন অ্যাপ্লিকেশান, যেমন ব্যাক অফিস/অ্যাডমিন টুল, শুধুমাত্র সীমিত প্রাপ্যতা প্রয়োজন এবং রাতারাতি নিষ্ক্রিয় হতে পারে।

কুবারনেটস ডাউনস্কেলার (kube-downscaler) ব্যবহারকারী এবং অপারেটরদের অ-কাজের সময়গুলিতে সিস্টেমটি স্কেল করার অনুমতি দেয়। স্থাপনা এবং StatefulSets শূন্য প্রতিলিপি স্কেল করতে পারেন. CronJobs স্থগিত করা হতে পারে. Kubernetes Downscaler একটি সম্পূর্ণ ক্লাস্টার, এক বা একাধিক নেমস্পেস বা পৃথক সম্পদের জন্য কনফিগার করা হয়েছে। আপনি "অলস সময়" বা বিপরীতভাবে, "কাজের সময়" সেট করতে পারেন। উদাহরণস্বরূপ, রাত এবং সপ্তাহান্তে যতটা সম্ভব স্কেলিং কমাতে:

image: hjacobs/kube-downscaler:20.4.3
args:
  - --interval=30
  # не отключать компоненты инфраструктуры
  - --exclude-namespaces=kube-system,infra
  # не отключать kube-downscaler, а также оставить Postgres Operator, чтобы исключенными БД можно было управлять
  - --exclude-deployments=kube-downscaler,postgres-operator
  - --default-uptime=Mon-Fri 08:00-20:00 Europe/Berlin
  - --include-resources=deployments,statefulsets,stacks,cronjobs
  - --deployment-time-annotation=deployment-time

এখানে সপ্তাহান্তে ক্লাস্টার কর্মী নোড স্কেলিং করার জন্য একটি গ্রাফ রয়েছে:

~13 থেকে 4 কর্মী নোডগুলিকে স্কেল করা অবশ্যই আপনার AWS বিলে একটি লক্ষণীয় পার্থক্য করে।

কিন্তু ক্লাস্টার "ডাউনটাইম" এর সময় যদি আমার কাজ করার প্রয়োজন হয়? ডাউনস্কেলার/এক্সক্লুড: সত্য টীকা যোগ করে কিছু স্থাপনা স্থায়ীভাবে স্কেলিং থেকে বাদ দেওয়া যেতে পারে। বিন্যাস YYYY-MM-DD HH:MM (UTC) বিন্যাসে একটি পরম টাইমস্ট্যাম্প সহ ডাউনস্কেলার/বর্জন-অভিন্ন টীকা ব্যবহার করে অস্থায়ীভাবে বাদ দেওয়া যেতে পারে। প্রয়োজনে, টীকা সহ একটি পড স্থাপন করে পুরো ক্লাস্টারটিকে আবার স্কেল করা যেতে পারে downscaler/force-uptime, উদাহরণস্বরূপ, nginx ফাঁকা চালু করে:

kubectl run scale-up --image=nginx
kubectl annotate deploy scale-up janitor/ttl=1h # удалить развертывание через час
kubectl annotate pod $(kubectl get pod -l run=scale-up -o jsonpath="{.items[0].metadata.name}") downscaler/force-uptime=true

দেখ README kube-downscaler, আপনি যদি স্থাপনার নির্দেশাবলী এবং অতিরিক্ত বিকল্পগুলিতে আগ্রহী হন।

অনুভূমিক অটোস্কেলিং ব্যবহার করুন

অনেক অ্যাপ্লিকেশন/পরিষেবা একটি গতিশীল লোডিং প্যাটার্ন নিয়ে কাজ করে: কখনও কখনও তাদের মডিউলগুলি নিষ্ক্রিয় থাকে এবং কখনও কখনও তারা সম্পূর্ণ ক্ষমতায় কাজ করে। সর্বোচ্চ পিক লোড মোকাবেলা করার জন্য পডের একটি স্থায়ী বহর পরিচালনা করা লাভজনক নয়। Kubernetes একটি সম্পদ জুড়ে অনুভূমিক স্বয়ংক্রিয় স্কেলিং সমর্থন করে অনুভূমিক পড অটোস্ক্যালার (HPA)। সিপিইউ ব্যবহার প্রায়ই স্কেলিং জন্য একটি ভাল সূচক:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        averageUtilization: 100
        type: Utilization

Zalando সহজেই স্কেলিং এর জন্য কাস্টম মেট্রিক্স সংযোগ করার জন্য একটি উপাদান তৈরি করেছে: কুবে মেট্রিক্স অ্যাডাপ্টার (kube-metrics-adapter) হল Kubernetes-এর জন্য একটি জেনেরিক মেট্রিক্স অ্যাডাপ্টার যা পডের অনুভূমিক অটোস্কেলিংয়ের জন্য কাস্টম এবং বাহ্যিক মেট্রিক্স সংগ্রহ এবং পরিবেশন করতে পারে। এটি প্রমিথিউস মেট্রিক্স, SQS সারি এবং অন্যান্য সেটিংসের উপর ভিত্তি করে স্কেলিং সমর্থন করে। উদাহরণস্বরূপ, /মেট্রিক্স ব্যবহারে JSON হিসাবে অ্যাপ্লিকেশন দ্বারা উপস্থাপিত একটি কাস্টম মেট্রিকে আপনার স্থাপনার স্কেল করতে:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
  annotations:
    # metric-config.<metricType>.<metricName>.<collectorName>/<configKey>
    metric-config.pods.requests-per-second.json-path/json-key: "$.http_server.rps"
    metric-config.pods.requests-per-second.json-path/path: /metrics
    metric-config.pods.requests-per-second.json-path/port: "9090"
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: requests-per-second
      target:
        averageValue: 1k
        type: AverageValue

HPA এর সাথে অনুভূমিক অটোস্কেলিং কনফিগার করা রাষ্ট্রবিহীন পরিষেবাগুলির দক্ষতা উন্নত করার জন্য একটি ডিফল্ট ক্রিয়া হওয়া উচিত। Spotify তাদের অভিজ্ঞতা এবং HPA এর জন্য সুপারিশ সহ একটি উপস্থাপনা রয়েছে: আপনার ডিপ্লোয়মেন্ট স্কেল করুন, আপনার ওয়ালেট নয়.

রিসোর্স ওভারবুকিং হ্রাস করুন

কুবারনেটস ওয়ার্কলোড "রিসোর্স রিকোয়েস্ট" এর মাধ্যমে তাদের CPU/মেমরির চাহিদা নির্ধারণ করে। CPU সম্পদগুলি ভার্চুয়াল কোরে পরিমাপ করা হয় বা আরও সাধারণভাবে "মিলিকোর"-এ পরিমাপ করা হয়, উদাহরণস্বরূপ 500m মানে 50% vCPU। মেমরি সংস্থানগুলি বাইটে পরিমাপ করা হয় এবং সাধারণ প্রত্যয়গুলি ব্যবহার করা যেতে পারে, যেমন 500Mi, যার অর্থ 500 মেগাবাইট৷ রিসোর্স রিকোয়েস্ট কর্মী নোডগুলিতে "লক" ক্ষমতা, মানে 1000টি ভিসিপিইউ সহ একটি নোডে 4 মি সিপিইউ অনুরোধ সহ একটি পড অন্যান্য পডগুলিতে শুধুমাত্র 3টি ভিসিপিইউ উপলব্ধ থাকবে৷ [1]

স্ল্যাক (অতিরিক্ত রিজার্ভ) অনুরোধ করা সম্পদ এবং প্রকৃত ব্যবহারের মধ্যে পার্থক্য। উদাহরণস্বরূপ, একটি পড যা 2 GiB মেমরির অনুরোধ করে কিন্তু শুধুমাত্র 200 MiB ব্যবহার করে তার ~1,8 GiB "অতিরিক্ত" মেমরি রয়েছে। অতিরিক্ত টাকা খরচ হয়। কেউ মোটামুটি অনুমান করতে পারে যে 1 GiB অপ্রয়োজনীয় মেমরি প্রতি মাসে ~$10 খরচ করে। [2]

কুবারনেটস রিসোর্স রিপোর্ট (কুবে-রিসোর্স-রিপোর্ট) অতিরিক্ত রিজার্ভ প্রদর্শন করে এবং আপনাকে সঞ্চয়ের সম্ভাব্যতা নির্ধারণে সাহায্য করতে পারে:

কুবারনেটস রিসোর্স রিপোর্ট অ্যাপ্লিকেশন এবং কমান্ড দ্বারা একত্রিত অতিরিক্ত দেখায়। এটি আপনাকে এমন জায়গাগুলি খুঁজে পেতে দেয় যেখানে সম্পদের চাহিদা হ্রাস করা যেতে পারে। উৎপন্ন HTML রিপোর্ট শুধুমাত্র সম্পদ ব্যবহারের একটি স্ন্যাপশট প্রদান করে। পর্যাপ্ত রিসোর্স অনুরোধ নির্ধারণ করতে আপনার সময়ের সাথে CPU/মেমরি ব্যবহারের দিকে নজর দেওয়া উচিত। এখানে একটি "সাধারণ" CPU-ভারী পরিষেবার জন্য একটি Grafana চার্ট রয়েছে: সমস্ত পড 3টি অনুরোধকৃত CPU কোরের চেয়ে উল্লেখযোগ্যভাবে কম ব্যবহার করছে:

CPU অনুরোধ 3000m থেকে ~400m-এ হ্রাস করা অন্যান্য কাজের চাপের জন্য সংস্থানগুলিকে মুক্ত করে এবং ক্লাস্টারটিকে ছোট হতে দেয়।

"EC2 দৃষ্টান্তগুলির গড় CPU ব্যবহার প্রায়শই একক-অঙ্কের শতাংশ পরিসরে থাকে," লিখেছেন কোরি কুইন. যখন EC2 এর জন্য সঠিক আকার অনুমান একটি খারাপ সিদ্ধান্ত হতে পারেএকটি YAML ফাইলে কিছু Kubernetes রিসোর্স কোয়েরি পরিবর্তন করা সহজ এবং বিশাল সঞ্চয় আনতে পারে।

কিন্তু আমরা কি সত্যিই চাই মানুষ YAML ফাইলে মান পরিবর্তন করুক? না, মেশিন অনেক ভালো করতে পারে! কুবারনেটস উল্লম্ব পড অটোস্ক্যালার (VPA) ঠিক তাই করে: কাজের চাপ অনুযায়ী সম্পদের অনুরোধ এবং সীমাবদ্ধতাগুলিকে অভিযোজিত করে। এখানে প্রমিথিউস সিপিইউ অনুরোধের একটি উদাহরণ গ্রাফ (পাতলা নীল রেখা) সময়ের সাথে সাথে VPA দ্বারা অভিযোজিত:

Zalando তার সমস্ত ক্লাস্টারে VPA ব্যবহার করে অবকাঠামোগত উপাদানগুলির জন্য। অ-সমালোচনামূলক অ্যাপ্লিকেশনগুলিও ভিপিএ ব্যবহার করতে পারে।

সোনালী কেশবিশিষ্ট ব্যক্তি ফেয়ারউইন্ড থেকে একটি টুল যা একটি নেমস্পেসে প্রতিটি স্থাপনার জন্য একটি VPA তৈরি করে এবং তারপর তার ড্যাশবোর্ডে একটি VPA সুপারিশ প্রদর্শন করে। এটি ডেভেলপারদের তাদের অ্যাপ্লিকেশনের জন্য সঠিক CPU/মেমরি অনুরোধ সেট করতে সাহায্য করতে পারে:

একটা ছোট লিখেছি VPA সম্পর্কে ব্লগপোস্ট 2019 সালে, এবং সম্প্রতি CNCF শেষ ব্যবহারকারী সম্প্রদায় VPA সমস্যা নিয়ে আলোচনা করেছে.

EC2 স্পট ইনস্ট্যান্স ব্যবহার করে

শেষ কিন্তু অন্তত নয়, কুবারনেটস ওয়ার্কার নোড হিসাবে স্পট ইনস্ট্যান্স ব্যবহার করে AWS EC2 খরচ কমানো যেতে পারে [3]. অন-ডিমান্ড দামের তুলনায় স্পট ইনস্ট্যান্স 90% পর্যন্ত ছাড়ে পাওয়া যায়। EC2 Spot-এ Kubernetes চালানো একটি ভাল সমন্বয়: উচ্চতর প্রাপ্যতার জন্য আপনাকে বিভিন্ন ধরনের ইন্সট্যান্স নির্দিষ্ট করতে হবে, যার অর্থ আপনি একই বা কম দামে একটি বড় নোড পেতে পারেন এবং বর্ধিত ক্ষমতা কনটেইনারাইজড Kubernetes ওয়ার্কলোড দ্বারা ব্যবহার করা যেতে পারে।

EC2 স্পটে কুবারনেটস কিভাবে চালাবেন? বেশ কয়েকটি বিকল্প রয়েছে: SpotInst (এখন "স্পট" বলা হয়) এর মতো একটি তৃতীয় পক্ষের পরিষেবা ব্যবহার করুন, কেন আমাকে জিজ্ঞাসা করবেন না, বা আপনার ক্লাস্টারে কেবল একটি স্পট অটোস্কেলিংগ্রুপ (ASG) যুক্ত করুন৷ উদাহরণস্বরূপ, এখানে একটি "ক্ষমতা-অপ্টিমাইজড" স্পট ASG-এর জন্য একাধিক উদাহরণের ধরন সহ একটি CloudFormation স্নিপেট রয়েছে:

MySpotAutoScalingGroup:
 Properties:
   HealthCheckGracePeriod: 300
   HealthCheckType: EC2
   MixedInstancesPolicy:
     InstancesDistribution:
       OnDemandPercentageAboveBaseCapacity: 0
       SpotAllocationStrategy: capacity-optimized
     LaunchTemplate:
       LaunchTemplateSpecification:
         LaunchTemplateId: !Ref LaunchTemplate
         Version: !GetAtt LaunchTemplate.LatestVersionNumber
       Overrides:
         - InstanceType: "m4.2xlarge"
         - InstanceType: "m4.4xlarge"
         - InstanceType: "m5.2xlarge"
         - InstanceType: "m5.4xlarge"
         - InstanceType: "r4.2xlarge"
         - InstanceType: "r4.4xlarge"
   LaunchTemplate:
     LaunchTemplateId: !Ref LaunchTemplate
     Version: !GetAtt LaunchTemplate.LatestVersionNumber
   MinSize: 0
   MaxSize: 100
   Tags:
   - Key: k8s.io/cluster-autoscaler/node-template/label/aws.amazon.com/spot
     PropagateAtLaunch: true
     Value: "true"

কুবারনেটসের সাথে স্পট ব্যবহার করার কিছু নোট:

• আপনাকে স্পট টার্মিনেশনগুলি পরিচালনা করতে হবে, উদাহরণস্বরূপ নোডটি মার্জ করে যখন উদাহরণটি বন্ধ করা হয়
• Zalando ব্যবহার করে কাঁটা নোড পুল অগ্রাধিকার সহ অফিসিয়াল ক্লাস্টার অটোস্কেলিং
• স্পট নোড বাধ্য করা যেতে পারে স্পটে চালানোর জন্য কাজের চাপের "নিবন্ধন" গ্রহণ করুন

সারাংশ

আমি আশা করি আপনি আপনার ক্লাউড বিল কমাতে উপস্থাপিত কিছু সরঞ্জামগুলি উপযোগী পাবেন। আপনি নিবন্ধের বেশিরভাগ বিষয়বস্তু এখানেও খুঁজে পেতে পারেন YouTube এবং স্লাইডে DevOps Gathering 2019-এ আমার আলোচনা.

Kubernetes এ ক্লাউড খরচ বাঁচানোর জন্য আপনার সর্বোত্তম অনুশীলনগুলি কী কী? আমাকে জানাতে দয়া করে টুইটার (@try_except_).

[1] প্রকৃতপক্ষে, 3টির কম vCPU ব্যবহারযোগ্য থাকবে কারণ নোডের থ্রুপুট সংরক্ষিত সিস্টেম সংস্থান দ্বারা হ্রাস করা হয়। কুবারনেটস ফিজিক্যাল নোড ক্ষমতা এবং "বিধান করা" সংস্থানগুলির মধ্যে পার্থক্য করে (নোড বরাদ্দযোগ্য).

[2] গণনার উদাহরণ: 5 GiB মেমরি সহ একটি m8.large উদাহরণ প্রতি মাসে ~$84 ​​(eu-central-1, অন-ডিমান্ড), যেমন 1/8 নোড ব্লক করা প্রায় ~$10/মাস।

[3] আপনার EC2 বিল কমানোর আরও অনেক উপায় আছে, যেমন সংরক্ষিত উদাহরণ, সেভিংস প্ল্যান ইত্যাদি। - আমি এখানে সেই বিষয়গুলি কভার করব না, তবে আপনার অবশ্যই সেগুলি খতিয়ে দেখা উচিত!

কোর্স সম্পর্কে আরও জানুন.

উত্স: www.habr.com