Right-Sizing на облачни ресурси: Практическо ръководство за AWS, Azure, GCP и Kubernetes (2026)

Какво е right-sizing и защо толкова много пари се губят заради него

Right-sizing е процесът на анализиране и коригиране на размера на облачните ресурси — виртуални машини, контейнери, бази данни и други услуги — така че да съответстват на реалното натоварване. Звучи просто, нали? На теория е. На практика — 84% от организациите считат управлението на облачните разходи за основно предизвикателство, според доклада на Flexera „State of the Cloud 2025".

А средно 27% от облачния бюджет просто се изпарява заради неефективно използване на ресурсите.

Сред най-сериозните причини за тези загуби е свръхпровизирането (overprovisioning) — онази практика да се заделят повече ресурси от необходимото „за всеки случай". Всички сме го правили — по-добре повече, отколкото по-малко, нали? Проблемът е, че проучванията показват 35–45% от виртуалните машини и контейнерите да работят с по-голям размер от необходимия. Това генерира допълнителни 8–12% излишни разходи.

Нека го преведем на разбираем език: за организация с месечен облачен бюджет от 100 000 долара, това означава между 8 000 и 12 000 долара на месец — или до 144 000 долара годишно — хвърлени за ресурси, които никога не се използват пълноценно. Честно казано, тази цифра е достатъчна, за да привлече вниманието на всеки CFO.

В тази статия ще разгледаме подробно как да приложите right-sizing на практика за трите водещи облачни платформи — AWS, Azure и Google Cloud Platform — както и за Kubernetes среди. Ще видите вградените инструменти на всеки доставчик, практически примери с код и стъпка по стъпка подход за внедряване на систематичен процес.

Основни принципи на right-sizing

Преди да навлезем в конкретните инструменти и техники, нека разберем фундаменталните принципи зад ефективния right-sizing. Тези принципи са валидни независимо от облачния доставчик.

Събиране на достатъчно данни

Right-sizing не трябва да се базира на моментни наблюдения. Сериозно — не правете промени на база снимка от CloudWatch в понеделник сутринта. Необходими са данни за достатъчно дълъг период, за да бъдат уловени пиковете и спадовете в натоварването.

Препоръчителният минимум е 14 дни, но за по-точни резултати е добре да анализирате данни от 30 до 90 дни. Това позволява да отчетете седмични и месечни модели — по-високо натоварване в края на месеца при счетоводни системи, пикове в трафика през уикендите при потребителски приложения и т.н.

Анализ на правилните метрики

Ефективният right-sizing изисква анализ на множество метрики едновременно:

• CPU натоварване: Средна и пикова стойност (p95/p99 перцентил). Инстанция с 5% средно CPU натоварване е очевиден кандидат за намаляване.
• Използване на памет: Критична метрика, която често се пренебрегва. Намаляването на CPU без проверка на паметта може да доведе до неприятни изненади.
• Мрежов трафик: Входящ и изходящ трафик, особено за мрежово интензивни приложения.
• Дискови операции (IOPS): Четене и запис, латентност — критично за бази данни и файлови системи.
• GPU натоварване: За машинно обучение и графични натоварвания (ако използвате такива инстанции).

Стратегия за безопасност при right-sizing

Right-sizing носи определен риск — прекалено агресивното намаляване може да доведе до влошена производителност. Затова е по-разумно да следвате подход на постепенно намаляване:

1. Започнете с ресурси, които са очевидно свръхпровизирани (под 20% средно натоварване).
2. Намалете с една стъпка (например от m5.2xlarge към m5.xlarge), а не директно до минимума.
3. Наблюдавайте поне 7 дни след промяната, преди да правите допълнителни корекции.
4. Винаги имайте план за бърз rollback — възможност за връщане към по-големия размер при нужда.

Може да изглежда предпазливо, но повярвайте — един инцидент в production заради прекалено агресивен right-sizing ще ви струва много повече от спестяванията.

Right-sizing в AWS с Compute Optimizer и Cost Explorer

Amazon Web Services предлага два основни инструмента за right-sizing: AWS Compute Optimizer и Cost Explorer Rightsizing Recommendations. И двата са безплатни за базова употреба и предоставят различни, но допълващи се анализи.

AWS Compute Optimizer

AWS Compute Optimizer използва машинно обучение, за да анализира историческите метрики на вашите ресурси и да генерира препоръки за оптимален размер. Поддържа EC2 инстанции, EBS томове, Lambda функции, ECS услуги и Auto Scaling групи — така че покрива доста голяма част от типичната AWS инфраструктура.

За да активирате Compute Optimizer, можете да използвате AWS CLI:

# Активиране на Compute Optimizer за акаунта
aws compute-optimizer update-enrollment-status \
  --status Active \
  --include-member-accounts

# Проверка на статуса
aws compute-optimizer get-enrollment-status

След активирането, Compute Optimizer се нуждае от минимум 30 часа метрични данни за първите си препоръки, но за наистина добри резултати изчакайте поне 14 дни. Можете да конфигурирате период на анализ от 14, 32 или 93 дни.

Ето как да извлечете препоръките програматично:

# Извличане на препоръки за EC2 инстанции
aws compute-optimizer get-ec2-instance-recommendations \
  --region eu-west-1 \
  --filters "name=Finding,values=OVER_PROVISIONED" \
  --output json | jq '.instanceRecommendations[] | {
    instanceId: .instanceArn,
    currentType: .currentInstanceType,
    finding: .finding,
    recommendations: [.recommendationOptions[] | {
      instanceType: .instanceType,
      projectedUtilization: .projectedUtilizationMetrics,
      performanceRisk: .performanceRisk,
      savingsOpportunity: .savingsOpportunity
    }]
  }'

# Извличане на препоръки за EBS томове
aws compute-optimizer get-ebs-volume-recommendations \
  --region eu-west-1 \
  --filters "name=Finding,values=NotOptimized"

# Извличане на препоръки за Lambda функции
aws compute-optimizer get-lambda-function-recommendations \
  --region eu-west-1

AWS Cost Explorer Rightsizing Recommendations

Cost Explorer предлага собствен набор от препоръки за right-sizing, фокусирани специално върху EC2. Ключовата разлика? Тези препоръки вземат предвид Reserved Instances и Savings Plans, което ги прави по-прецизни при изчисляването на реалните спестявания.

# Извличане на right-sizing препоръки от Cost Explorer
aws ce get-rightsizing-recommendation \
  --service "AmazonEC2" \
  --configuration '{
    "RecommendationTarget": "SAME_INSTANCE_FAMILY",
    "BenefitsConsidered": true
  }'

Автоматизиране на right-sizing процеса в AWS

За организации, които искат да автоматизират процеса, ето примерен Python скрипт, който събира препоръките и генерира доклад. Използвам нещо подобно в практиката си и мога да кажа, че спестява доста ръчна работа:

import boto3
import json
from datetime import datetime

def get_rightsizing_report():
    """Събира right-sizing препоръки и генерира доклад."""

    compute_optimizer = boto3.client('compute-optimizer')

    # Извличане на свръхпровизирани EC2 инстанции
    response = compute_optimizer.get_ec2_instance_recommendations(
        filters=[{
            'name': 'Finding',
            'values': ['OVER_PROVISIONED']
        }]
    )

    report = {
        'generated_at': datetime.utcnow().isoformat(),
        'total_instances': 0,
        'total_monthly_savings': 0,
        'recommendations': []
    }

    for rec in response.get('instanceRecommendations', []):
        instance_id = rec['instanceArn'].split('/')[-1]
        current_type = rec['currentInstanceType']

        # Вземане на най-добрата препоръка
        if rec.get('recommendationOptions'):
            best_option = rec['recommendationOptions'][0]
            recommended_type = best_option['instanceType']
            savings = best_option.get('savingsOpportunity', {})
            monthly_savings = savings.get(
                'estimatedMonthlySavings', {}
            ).get('value', 0)

            report['recommendations'].append({
                'instance_id': instance_id,
                'current_type': current_type,
                'recommended_type': recommended_type,
                'monthly_savings_usd': monthly_savings,
                'performance_risk': best_option.get(
                    'performanceRisk', 'N/A'
                )
            })
            report['total_monthly_savings'] += monthly_savings

    report['total_instances'] = len(report['recommendations'])
    return report


def apply_rightsizing(instance_id, new_instance_type, dry_run=True):
    """Прилага right-sizing чрез спиране, промяна и стартиране."""

    ec2 = boto3.client('ec2')

    if dry_run:
        print(f"[DRY RUN] Би променил {instance_id} "
              f"към {new_instance_type}")
        return

    # Спиране на инстанцията
    print(f"Спиране на {instance_id}...")
    ec2.stop_instances(InstanceIds=[instance_id])
    waiter = ec2.get_waiter('instance_stopped')
    waiter.wait(InstanceIds=[instance_id])

    # Промяна на типа
    print(f"Промяна към {new_instance_type}...")
    ec2.modify_instance_attribute(
        InstanceId=instance_id,
        InstanceType={'Value': new_instance_type}
    )

    # Стартиране на инстанцията
    print(f"Стартиране на {instance_id}...")
    ec2.start_instances(InstanceIds=[instance_id])
    waiter = ec2.get_waiter('instance_running')
    waiter.wait(InstanceIds=[instance_id])

    print(f"Успешно! {instance_id} вече е {new_instance_type}")


if __name__ == '__main__':
    report = get_rightsizing_report()
    print(json.dumps(report, indent=2, ensure_ascii=False))
    print(f"\nОбщо спестявания: ${report['total_monthly_savings']:.2f}/месец")
    print(f"Брой инстанции за оптимизиране: {report['total_instances']}")

Right-sizing в Azure с Azure Advisor и Azure Monitor

Microsoft Azure предоставя Azure Advisor като основен инструмент за right-sizing препоръки. Advisor използва алгоритми за машинно обучение, за да идентифицира слабо натоварени виртуални машини и да предложи по-подходящи размери.

Как работи Azure Advisor за right-sizing

Azure Advisor анализира CPU, памет и мрежова активност на виртуалните машини за определен период. По подразбиране периодът е 7 дни, но може да бъде конфигуриран на 14, 21, 30, 60 или 90 дни. Препоръките включват два типа:

• Resize (преоразмеряване): Промяна към по-малък SKU, който запазва достатъчна производителност при по-ниска цена.
• Shutdown (спиране): Пълно спиране на виртуални машини, които не са използвани за продължителен период. Да, понякога отговорът е просто да изключите машината.

За да получите препоръките чрез Azure CLI:

# Извличане на cost препоръки от Azure Advisor
az advisor recommendation list \
  --category Cost \
  --output table

# Филтриране само за VM right-sizing препоръки
az advisor recommendation list \
  --category Cost \
  --query "[?impactedField=='Microsoft.Compute/virtualMachines']" \
  --output json

# Детайлна информация за конкретна препоръка
az advisor recommendation list \
  --category Cost \
  --query "[?impactedField=='Microsoft.Compute/virtualMachines'] | [0]" \
  --output json | jq '{
    vm: .impactedValue,
    currentSku: .extendedProperties.currentSku,
    recommendedSku: .extendedProperties.targetSku,
    annualSavings: .extendedProperties.annualSavingsAmount,
    currency: .extendedProperties.savingsCurrency
  }'

Конфигуриране на lookback период

Периодът на анализ по подразбиране (7 дни) може да бъде недостатъчен за натоварвания с месечни пикове. Ето как да го промените:

# Задаване на 30-дневен lookback период за VM right-sizing
az advisor configuration update \
  --resource-group myResourceGroup \
  --low-cpu-threshold 15 \
  --configuration-name default

# Конфигуриране чрез REST API за по-фин контрол
az rest --method PUT \
  --url "https://management.azure.com/subscriptions/{sub-id}/providers/Microsoft.Advisor/configurations/default?api-version=2023-01-01" \
  --body '{
    "properties": {
      "lowCpuThreshold": "15",
      "exclude": false,
      "duration": "P30D"
    }
  }'

Автоматизиран скрипт за Azure right-sizing

Ето PowerShell скрипт, който автоматизира прегледа и прилагането на right-sizing в Azure. Скриптът е направен с вграден WhatIf режим, защото — да бъдем честни — никой не иска да resize-не production VM по погрешка:

# Azure Right-Sizing Automation Script

# Свързване към Azure
Connect-AzAccount

# Получаване на всички VM right-sizing препоръки
$recommendations = Get-AzAdvisorRecommendation `
    -Category Cost | Where-Object {
    $_.ImpactedField -eq "Microsoft.Compute/virtualMachines"
}

# Генериране на доклад
$report = @()
$totalSavings = 0

foreach ($rec in $recommendations) {
    $vmName = $rec.ImpactedValue
    $currentSku = $rec.ExtendedProperties["currentSku"]
    $targetSku = $rec.ExtendedProperties["targetSku"]
    $savings = [decimal]$rec.ExtendedProperties["annualSavingsAmount"]

    $report += [PSCustomObject]@{
        VMName       = $vmName
        CurrentSKU   = $currentSku
        TargetSKU    = $targetSku
        AnnualSaving = $savings
        Action       = $rec.ExtendedProperties["recommendationType"]
    }

    $totalSavings += $savings
}

# Показване на доклада
$report | Sort-Object AnnualSaving -Descending | Format-Table -AutoSize

Write-Host "`nОбщо годишни спестявания: $($totalSavings) USD" `
    -ForegroundColor Green
Write-Host "Брой VM за оптимизиране: $($report.Count)" `
    -ForegroundColor Yellow

# Функция за прилагане на right-sizing с потвърждение
function Apply-VMRightsizing {
    param(
        [string]$VMName,
        [string]$ResourceGroup,
        [string]$NewSize,
        [switch]$WhatIf
    )

    if ($WhatIf) {
        Write-Host "[WhatIf] Би променил $VMName към $NewSize" `
            -ForegroundColor Cyan
        return
    }

    Write-Host "Спиране на $VMName..." -ForegroundColor Yellow
    Stop-AzVM -Name $VMName -ResourceGroupName $ResourceGroup -Force

    Write-Host "Промяна на размера към $NewSize..."
    $vm = Get-AzVM -Name $VMName -ResourceGroupName $ResourceGroup
    $vm.HardwareProfile.VmSize = $NewSize
    Update-AzVM -VM $vm -ResourceGroupName $ResourceGroup

    Write-Host "Стартиране на $VMName..." -ForegroundColor Yellow
    Start-AzVM -Name $VMName -ResourceGroupName $ResourceGroup

    Write-Host "Готово! $VMName е с нов размер: $NewSize" `
        -ForegroundColor Green
}

Важни особености при Azure right-sizing

При работа с Azure Advisor има няколко неща, за които трябва да знаете:

• Reserved Instances не се отчитат: Препоръките на Azure Advisor не вземат предвид наличните Reserved Instances или Savings Plans. Показаните спестявания се базират на retail цени и може да не отразяват реалния ефект, ако вече имате ангажименти за отстъпки. Това е доста важен нюанс, който лесно се пропуска.
• Регионална наличност на SKU: Не всички размери на VM са налични във всички региони. Advisor проверява дали препоръчаният SKU е наличен в текущия регион, но е добра практика да проверите и ръчно.
• Рестарт при промяна: Промяната на VM размера изисква рестарт. Планирайте maintenance прозорец за production системи — това не е нещо, което правите в петък следобед.

Right-sizing в Google Cloud Platform с Recommender API

Google Cloud Platform предлага вграден Recommender, който автоматично анализира използването на Compute Engine инстанциите и генерира препоръки за оптимален размер. GCP Recommender използва данните от Cloud Monitoring за последните 8 дни.

Достъп до препоръките чрез gcloud CLI

# Извличане на right-sizing препоръки за конкретна зона
gcloud recommender recommendations list \
  --project=my-project \
  --location=europe-west1-b \
  --recommender=google.compute.instance.MachineTypeRecommender \
  --format="table(
    content.operationGroups[0].operations[0].resource,
    description,
    primaryImpact.costProjection.cost.units,
    stateInfo.state
  )"

# Подробна информация за конкретна препоръка
gcloud recommender recommendations describe RECOMMENDATION_ID \
  --project=my-project \
  --location=europe-west1-b \
  --recommender=google.compute.instance.MachineTypeRecommender

# Приемане на препоръка
gcloud recommender recommendations mark-claimed RECOMMENDATION_ID \
  --project=my-project \
  --location=europe-west1-b \
  --recommender=google.compute.instance.MachineTypeRecommender \
  --etag=ETAG_VALUE

Автоматизиране с Python и Recommender API

from google.cloud import recommender_v1
from google.cloud import compute_v1

def get_rightsizing_recommendations(project_id, zone):
    """Извлича right-sizing препоръки за GCP Compute Engine."""

    client = recommender_v1.RecommenderClient()
    parent = (
        f"projects/{project_id}/locations/{zone}/"
        f"recommenders/google.compute.instance.MachineTypeRecommender"
    )

    recommendations = []

    for rec in client.list_recommendations(request={"parent": parent}):
        if rec.state_info.state == recommender_v1.RecommendationStateInfo.State.ACTIVE:
            # Извличане на детайлите
            operation = rec.content.operation_groups[0].operations[0]
            current_machine = operation.path_filters.get(
                "/machineType", "unknown"
            )
            new_machine = operation.value_matcher.get(
                "matchesPattern", "unknown"
            )

            # Извличане на прогнозирани спестявания
            cost_impact = rec.primary_impact.cost_projection
            monthly_savings = abs(
                float(cost_impact.cost.units or 0) +
                float(cost_impact.cost.nanos or 0) / 1e9
            )

            recommendations.append({
                "instance": operation.resource,
                "current_type": current_machine,
                "recommended_type": new_machine,
                "monthly_savings": monthly_savings,
                "description": rec.description,
                "recommendation_id": rec.name
            })

    return recommendations


def apply_machine_type_change(project_id, zone, instance_name,
                               new_machine_type):
    """Прилага промяна на машинния тип в GCP."""

    instances_client = compute_v1.InstancesClient()

    # Спиране на инстанцията
    print(f"Спиране на {instance_name}...")
    operation = instances_client.stop(
        project=project_id, zone=zone, instance=instance_name
    )
    operation.result()

    # Промяна на машинния тип
    print(f"Промяна към {new_machine_type}...")
    instance_resource = compute_v1.InstancesSetMachineTypeRequest(
        machine_type=(
            f"zones/{zone}/machineTypes/{new_machine_type}"
        )
    )
    operation = instances_client.set_machine_type(
        project=project_id, zone=zone,
        instance=instance_name,
        instances_set_machine_type_request_resource=instance_resource
    )
    operation.result()

    # Стартиране на инстанцията
    print(f"Стартиране на {instance_name}...")
    operation = instances_client.start(
        project=project_id, zone=zone, instance=instance_name
    )
    operation.result()

    print(f"Готово! {instance_name} е с тип {new_machine_type}")


# Пример за използване
if __name__ == "__main__":
    project = "my-gcp-project"
    zone = "europe-west1-b"

    recs = get_rightsizing_recommendations(project, zone)

    total_savings = 0
    for r in recs:
        print(f"Инстанция: {r['instance']}")
        print(f"  Текущ тип: {r['current_type']}")
        print(f"  Препоръчан тип: {r['recommended_type']}")
        print(f"  Месечни спестявания: ${r['monthly_savings']:.2f}")
        print()
        total_savings += r["monthly_savings"]

    print(f"Общо потенциални спестявания: ${total_savings:.2f}/месец")

Особености на GCP Recommender

При работа с GCP Recommender има няколко неща, които си струва да знаете:

• Праг от $10/месец: Google не показва препоръки, ако очакваните спестявания са под 10 долара на месец. Логиката е ясна — фокус върху значимите оптимизации — но означава, че малки инстанции може просто да не получат препоръки.
• 8-дневен анализ: GCP Recommender използва данни само от последните 8 дни. Подходящ за натоварвания със седмични модели, но може да е недостатъчен за по-дълги цикли.
• Custom Machine Types: Това е уникалното предимство на GCP — възможността за създаване на инстанции с персонализиран брой vCPU и обем памет. Recommender може да предложи custom тип, точно съобразен с нуждите ви, вместо да ви ограничава до предварително дефинирани размери. Доста полезно, ако стандартните типове не пасват добре на натоварването ви.

Right-sizing на Kubernetes натоварвания

Така, стигнахме до най-интересната (и честно казано — най-сложната) част. Kubernetes добавя допълнително ниво на сложност при right-sizing, тъй като ресурсите се управляват на две нива: на ниво възел (node) и на ниво контейнер (pod). Ефективният right-sizing тук изисква оптимизация и на двете нива.

Vertical Pod Autoscaler (VPA)

VPA е вграденият механизъм на Kubernetes за автоматично коригиране на resource requests и limits на pod-овете. Той анализира историческото потребление на CPU и памет и автоматично адаптира ресурсите спрямо реалното натоварване.

VPA поддържа няколко режима на работа:

• Off: Само генерира препоръки, без да ги прилага. Идеален за начална фаза на анализ — и моят съвет е винаги да започвате оттук.
• Initial: Задава ресурсите само при създаване на pod, без да променя работещи pod-ове.
• Auto: Автоматично прилага препоръките, рестартирайки pod-ове при необходимост. Удобно, но внимавайте с production.

# Инсталиране на VPA компонентите
kubectl apply -f https://github.com/kubernetes/autoscaler/releases/latest/download/vpa-v1-crd-gen.yaml
kubectl apply -f https://github.com/kubernetes/autoscaler/releases/latest/download/vpa-rbac.yaml

---
# Пример: VPA конфигурация за web приложение (режим Off за анализ)
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-web-app-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-web-app
  updatePolicy:
    updateMode: "Off"    # Само препоръки, без автоматични промени
  resourcePolicy:
    containerPolicies:
    - containerName: web
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: 2000m
        memory: 4Gi
      controlledResources: ["cpu", "memory"]

---
# Пример: VPA в режим Auto за non-critical натоварване
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: batch-processor-vpa
  namespace: processing
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: batch-processor
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: processor
      minAllowed:
        cpu: 50m
        memory: 64Mi
      maxAllowed:
        cpu: 4000m
        memory: 8Gi

За да проверите текущите препоръки на VPA:

# Извличане на VPA препоръки
kubectl get vpa my-web-app-vpa -n production -o jsonpath='{
  "target": {
    "cpu": "{.status.recommendation.containerRecommendations[0].target.cpu}",
    "memory": "{.status.recommendation.containerRecommendations[0].target.memory}"
  },
  "lowerBound": {
    "cpu": "{.status.recommendation.containerRecommendations[0].lowerBound.cpu}",
    "memory": "{.status.recommendation.containerRecommendations[0].lowerBound.memory}"
  },
  "upperBound": {
    "cpu": "{.status.recommendation.containerRecommendations[0].upperBound.cpu}",
    "memory": "{.status.recommendation.containerRecommendations[0].upperBound.memory}"
  }
}' | jq .

# Сравнение на текущи requests с VPA препоръки
kubectl get pods -n production -o custom-columns=\
"NAME:.metadata.name,\
CPU_REQ:.spec.containers[0].resources.requests.cpu,\
MEM_REQ:.spec.containers[0].resources.requests.memory,\
CPU_LIM:.spec.containers[0].resources.limits.cpu,\
MEM_LIM:.spec.containers[0].resources.limits.memory"

Комбиниране на VPA и HPA

Vertical Pod Autoscaler и Horizontal Pod Autoscaler (HPA) могат да работят заедно, но изискват внимателна конфигурация, за да се избегнат конфликти. Препоръчителният подход е VPA да управлява паметта, а HPA да мащабира по CPU:

# VPA за оптимизиране на памет
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-server-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: api
      controlledResources: ["memory"]  # Само памет
      minAllowed:
        memory: 256Mi
      maxAllowed:
        memory: 8Gi
---
# HPA за хоризонтално мащабиране по CPU
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Right-sizing на ниво Kubernetes възел

Освен оптимизирането на pod ресурсите, е критично да се оптимизира и изборът на възли в клъстера. Инструменти като CAST AI, Karpenter (за AWS) и GKE Autopilot могат автоматично да избират оптималния тип възел за текущото натоварване.

# Пример: Karpenter NodePool конфигурация за AWS EKS
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: optimized-pool
spec:
  template:
    spec:
      requirements:
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["on-demand", "spot"]
      - key: node.kubernetes.io/instance-type
        operator: In
        values:
        - m5.large
        - m5.xlarge
        - m6i.large
        - m6i.xlarge
        - m7i.large
        - c5.large
        - c5.xlarge
        - c6i.large
      - key: topology.kubernetes.io/zone
        operator: In
        values:
        - eu-west-1a
        - eu-west-1b
  limits:
    cpu: 100
    memory: 400Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

Изграждане на систематичен процес за right-sizing

Еднократният right-sizing е полезен, но истинската стойност идва от превръщането му в непрекъснат процес. Виждал съм организации, които правят един голям right-sizing, спестяват 30%, а след шест месеца разходите пълзят обратно нагоре. Ето рамка за изграждане на устойчива right-sizing програма.

Стъпка 1: Установяване на baseline

Преди да започнете каквито и да е оптимизации, документирайте текущото състояние:

• Общ брой инстанции по тип и размер за всеки облачен доставчик.
• Средно натоварване на CPU и памет за всеки ресурс за последните 30 дни.
• Текущ месечен разход по категории (compute, storage, network, database).
• Процент на ресурси, идентифицирани като свръхпровизирани.

Без baseline няма как да измерите успеха на усилията си.

Стъпка 2: Категоризиране на натоварванията

Не всички натоварвания са подходящи за right-sizing по един и същи начин. Категоризирайте ги по няколко критерия:

• Критичност: Production, staging, development. Започнете с non-production средите, където рискът от проблеми е нисък.
• Модел на натоварване: Постоянно, циклично, burst-ово. Постоянните натоварвания са идеални за right-sizing.
• Толеранс към прекъсвания: Може ли услугата да понесе кратък рестарт? Ако да — right-sizing е лесен. Ако не — планирайте maintenance прозорец.

Стъпка 3: Приоритизиране по потенциално спестяване

Фокусирайте усилията там, където ефектът ще бъде най-голям. Приоритизирайте ресурси с:

1. Висока абсолютна стойност на разход (например инстанции, струващи над 500 долара/месец).
2. Нисък процент на използване (под 20% средно CPU/памет).
3. Дълъг период на ниско натоварване (стабилно ниски метрики за повече от 30 дни).

Стъпка 4: Внедряване на мониторинг и обратна връзка

Създайте dashboard за наблюдение на ефекта от right-sizing оптимизациите. Ето пример с Terraform за настройване на CloudWatch алерти, които да ви предупреждават, ако натоварването се повиши след right-sizing:

# CloudWatch аларма за мониторинг след right-sizing
resource "aws_cloudwatch_metric_alarm" "high_cpu_after_rightsizing" {
  alarm_name          = "high-cpu-after-rightsizing"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 3
  metric_name         = "CPUUtilization"
  namespace           = "AWS/EC2"
  period              = 300
  statistic           = "Average"
  threshold           = 80
  alarm_description   = "CPU > 80% след right-sizing — може да е необходим rollback"

  dimensions = {
    InstanceId = "i-0abcdef1234567890"
  }

  alarm_actions = [aws_sns_topic.rightsizing_alerts.arn]
}

resource "aws_sns_topic" "rightsizing_alerts" {
  name = "rightsizing-alerts"
}

resource "aws_sns_topic_subscription" "email" {
  topic_arn = aws_sns_topic.rightsizing_alerts.arn
  protocol  = "email"
  endpoint  = "[email protected]"
}

Стъпка 5: Редовен цикъл на преглед

Right-sizing не е еднократна задача. Натоварванията се променят с времето — нови функции, повече потребители, промени в данните. Установете редовен цикъл:

• Седмичен: Автоматизиран доклад с нови препоръки от Compute Optimizer / Azure Advisor / GCP Recommender.
• Месечен: Преглед на top 10 най-скъпи ресурси и техните метрики. Сравнение с baseline.
• Тримесечен: Цялостен одит — нови услуги, архитектурни промени, актуализиране на baseline.

Сравнение на right-sizing инструментите по облачни платформи

За по-лесно ориентиране, ето обобщена сравнителна информация за вградените инструменти на трите основни облачни доставчика:

• AWS Compute Optimizer: Период на анализ 14/32/93 дни. Поддържа EC2, EBS, Lambda, ECS, Auto Scaling. Безплатен (enhanced е с малка цена). Препоръчва от предварително дефинирани типове инстанции.
• Azure Advisor: Период на анализ 7/14/21/30/60/90 дни. Поддържа VM, VMSS, App Service, SQL Database. Напълно безплатен. Не отчита RI/Savings Plans при калкулацията.
• GCP Recommender: Период на анализ 8 дни. Поддържа Compute Engine, GKE. Безплатен. Може да препоръчва custom machine types. Не показва препоръки под $10/месец спестяване.
• Kubernetes VPA: Наличен за всички платформи. Режими Off/Initial/Auto. Open source. Изисква рестарт на pod за прилагане. Работи най-добре за стабилни натоварвания.

Често срещани грешки при right-sizing

Ето грешките, които се срещат най-често (и които лесно могат да бъдат избегнати с малко внимание):

1. Разчитане само на средно CPU натоварване

Средната стойност може да скрие важни пикове. Инстанция с 10% средно CPU натоварване може да достига 95% в определени периоди. Винаги проверявайте p95 и p99 перцентилите — те показват реалната картина.

2. Пренебрегване на паметта

Много екипи се фокусират изцяло върху CPU, но паметта е също толкова критична. Намаляването на инстанция може да доведе до swap на диска (при виртуални машини) или OOMKill (при контейнери), което драстично влошава производителността. Случвало се е „спестяване" от $50/месец да водеше до часове downtime.

3. Right-sizing без отчитане на бъдещ растеж

Ако знаете, че натоварването ще расте значително в следващите 1–2 месеца (нова функция, маркетингова кампания), отложете right-sizing или заложете буфер от 20–30% над текущото потребление.

4. Right-sizing на бази данни без тестване

Базите данни са особено чувствителни към промени в ресурсите. Преди да намалите размера на RDS инстанция или Cloud SQL, задължително тествайте с реалистично натоварване в staging среда. Базите данни не са нещо, с което да експериментирате на живо.

5. Липса на rollback план

Винаги имайте документиран план за бързо връщане към предишния размер. Автоматизирайте rollback-а, за да минимизирате downtime при проблеми. Ще ви трябва по-рядко, отколкото мислите, но когато ви трябва — ще е критично.

Очакван ефект и ROI на right-sizing

Въз основа на индустриални данни за 2025–2026 г., организациите могат да очакват следните резултати от систематична програма за right-sizing:

• Спестявания от 20–35% на compute разходите при първата вълна на оптимизации.
• Текущи спестявания от 5–10% при редовен месечен процес на преглед и корекция.
• Подобрена производителност при около 15% от случаите, когато under-provisioned ресурси бъдат идентифицирани и увеличени.
• Намалено въглеродно въздействие: По-малкият размер на ресурсите означава по-малко потребление на енергия — фактор, който става все по-важен за ESG целите на организациите.

Ключът към успеха е последователност и автоматизация. Еднократните оптимизации носят бърз ефект, но стойността им ерозира с времето, ако не поддържате непрекъснат процес.

Комбинирайте right-sizing с други FinOps практики — Savings Plans, Spot инстанции, автоматично спиране на неизползвани ресурси — за максимален ефект върху облачния бюджет. Right-sizing е фундаментална FinOps практика, която не изисква архитектурни промени, не налага миграции и може да бъде стартирана веднага с безплатните инструменти на всеки облачен доставчик.

Независимо дали управлявате десет или десет хиляди инстанции, систематичният подход към оптимизиране на размерите е едно от най-ефективните действия за контрол на облачните разходи. Така че — отворете Compute Optimizer (или Azure Advisor, или GCP Recommender) и вижте какво ви предлага. Може да се изненадате.