AWS RDS оптимизация 2026: Aurora + gp3

Q: Кой е най-евтиният RDS instance type?

За dev/test изборът е db.t4g.micro ($0.016/час в us-east-1), включен в AWS Free Tier за 12 месеца. За production baseline препоръчвам db.t4g.small или db.t4g.medium с burstable CPU credits. За стабилно натоварване от production мащаб, db.m7g.large или db.r7g.large с 1-годишен No Upfront Reserved Instance дава най-добро съотношение цена към производителност.

Q: Мога ли да сменя storage type на работеща RDS инстанция?

Да. Промяната от gp2 към gp3 е онлайн операция без downtime и се задейства с modify-db-instance --storage-type gp3 . За production избягвайте --apply-immediately в пиков час, защото модификацията може да задейства кратък I/O freeze; планирайте през maintenance window.

Актуализирано: 11 август 2026 г.

Оптимизацията на разходите за AWS RDS започва с три конкретни действия: миграция от gp2 към gp3 съхранение (до 20% по-евтино за същия IOPS), преминаване към Graviton-базирани инстанции db.m7g/db.r7g (до 20% по-нисък почасов ценник) и закупуване на 1-годишни Reserved Instances с No Upfront плащане (~28% отстъпка). Когато натоварването е бърстово, Aurora Serverless v2 премахва overprovisioning-а. В този наръчник ще ви покажа точните команди, ценовите разлики за 2026 г. и капаните, които виждам в почти всеки одит на реални акаунти. Честно казано, повечето екипи оставят пари на масата само защото никой не е гледал сметката от година.

Миграцията от gp2 към gp3 е онлайн операция и намалява месечната сметка за съхранение с ~20% при по-висок baseline от 3000 IOPS без допълнително заплащане.
Graviton инстанциите (db.m7g, db.r7g, db.r8g) предлагат 10–20% по-ниска цена на час спрямо x86 еквивалентите за MySQL, PostgreSQL, MariaDB и Aurora.
Aurora Serverless v2 е по-евтина от provisioned Aurora само когато средното натоварване е под ~50% от peak-а. Иначе е скъпа.
1-годишен No Upfront Reserved Instance носи ~28% отстъпка, а 3-годишен All Upfront стига до 62% за стабилни production бази.
Multi-AZ удвоява compute и storage разходите. Задължителен е за production, но не и за dev/staging.
Backup storage над размера на базата се таксува ~$0.095/GB-месец. Retention над 14 дни често струва повече от самата база.

Къде отиват парите: анатомия на сметката за RDS

Преди да режете, разберете структурата. Една типична RDS сметка се състои от пет линии: compute (почасова цена на инстанцията), storage (GB-месец, различен тарифен клас за gp2/gp3/io1/io2), backup storage над размера на базата, data transfer (най-често към cross-AZ read replicas или към други региони) и Performance Insights с retention над 7 дни. В акаунтите, които одитирам, разпределението обикновено изглежда така: 55–65% compute, 15–25% storage, 5–15% backup, 3–8% cross-AZ трафик, а останалото са Enhanced Monitoring и логове.

Компромисът е важен. Най-голямата тежест е compute-ът, затова там идват най-големите отстъпки чрез Reserved Instances и Graviton. Но storage-ът обикновено е забравеният фронт. Виждал съм production PostgreSQL инстанция с 4 TB gp2 volume, която плащаше $560/месец за IOPS, който gp3 дава на 3000 IOPS baseline без допълнителна такса. Това е чист profit за 10 минути работа. Затова започвам всяка оптимизация с преглед на DescribeDBInstances и групиране по StorageType, Iops и MultiAZ.

Ако още не сте въвели тагване по environment, team и cost-center, преди RDS оптимизацията прочетете ръководството за тагване на облачни ресурси за cost allocation. Без него не можете да отговорите на въпроса „коя база на кой продукт принадлежи", а това е предпоставка за всеки разговор с engineering за down-sizing.

Мигрирайте от gp2 към gp3 съхранение днес

gp3 е новото поколение General Purpose SSD за EBS и RDS. За RDS цената е около $0.115/GB-месец срещу $0.138/GB-месец за gp2, което е 17% по-евтино за самото място. Но истинската разлика е в IOPS. gp2 обвързва IOPS с размера (3 IOPS/GB), докато gp3 дава 3000 IOPS и 125 MB/s throughput като baseline, независимо от размера. За база под ~1 TB, която не изисква над 3000 IOPS, миграцията е чиста печалба.

Миграцията е онлайн и не изисква downtime, но първо направете snapshot. Ето точната команда, която ползвам:

aws rds modify-db-instance \
  --db-instance-identifier prod-postgres-01 \
  --storage-type gp3 \
  --allocated-storage 500 \
  --apply-immediately

# Проверете статуса
aws rds describe-db-instances \
  --db-instance-identifier prod-postgres-01 \
  --query 'DBInstances[0].[StorageType,AllocatedStorage,Iops,StorageThroughput]' \
  --output table

За база над 400 GB, ако имате нужда от повече от 3000 IOPS, платените IOPS в gp3 струват ~$0.02/IOPS-месец над baseline-а, което почти винаги е по-евтино от io1/io2. Единственият случай, в който io2 Block Express има смисъл, е за latency-sensitive OLTP workloads с изискване за над 64 000 IOPS или sub-millisecond latency.

За акаунти с десетки инстанции е по-практично да пуснете bulk скрипт. Ето един pattern, който използвам по време на одити:

#!/bin/bash
# Списък на всички gp2 RDS инстанции с оценка на месечна икономия
aws rds describe-db-instances \
  --query 'DBInstances[?StorageType==`gp2`].[DBInstanceIdentifier,AllocatedStorage,Engine]' \
  --output text | while read id size engine; do
  monthly_gp2=$(echo "$size * 0.138" | bc -l)
  monthly_gp3=$(echo "$size * 0.115" | bc -l)
  savings=$(echo "$monthly_gp2 - $monthly_gp3" | bc -l)
  printf "%-40s %s GB  %s  \$%.2f/mo savings\n" "$id" "$size" "$engine" "$savings"
done

Aurora Serverless v2 срещу provisioned: кога е по-евтино?

Aurora Serverless v2 се таксува по Aurora Capacity Units (ACU): 1 ACU е ~2 GiB памет и съответна CPU/network. Цената е $0.12/ACU-час в us-east-1 (за MySQL и PostgreSQL версии). Скалирането е с гранулярност от 0.5 ACU и се случва за секунди, което е привлекателно за бърстови или dev/staging натоварвания.

Проблемът е, че много екипи мислят Serverless за „по-евтино по подразбиране". Реалността е друга. Serverless v2 е по-евтина само ако средният ACU consumption е под ~50% от peak-а. При стабилно production натоварване provisioned Aurora с 1- или 3-годишен Reserved Instance побеждава Serverless с широка граница.

Дименсия	Aurora Serverless v2	Aurora Provisioned (RI 1y NoUpfront)
Ценообразуване	$0.12/ACU-час	~$0.29/час за db.r7g.large (2 vCPU, 16 GiB)
Скалиране	0.5 ACU стъпка, секунди	Ръчно или чрез Auto Scaling за replicas
Cold start	Няма (min ACU винаги активен)	Не се прилага
Оптимална употреба	Бърстово, dev, staging, ниска утилизация	Стабилно 24/7 production, високо натоварване
Точка на прекъсване (breakeven)	~4 ACU средно = ~$350/месец	db.r7g.large ~$210/месец с 1y RI
Multi-AZ	Автоматично (в единна цена)	+100% compute за standby

Практическо правило от моята работа: ако DBLoad метриката е под 30% през 70% от денонощието, Serverless v2 ще спести пари. Ако системата е винаги над 60% натоварване, provisioned + RI побеждава. За смесени случаи (production писане плюс аналитични read replicas) използвам provisioned за writer и Serverless за analytics endpoint, което е най-доброто и от двата свята.

За правилното оразмеряване на минимума ACU препоръчвам да прочетете практическото ръководство за right-sizing на облачни ресурси. Методът за анализ на CloudWatch метрики важи и за RDS, само със заместване на CPUUtilization с DBLoad и FreeableMemory.

Reserved Instances и Savings Plans за RDS

RDS Reserved Instances дават най-голямата единична отстъпка в целия сервиз. Актуалните нива за 2026 г. в us-east-1 за db.r7g.large изглеждат така: On-Demand $0.290/час; 1-годишен No Upfront ~$0.209/час (28% отстъпка); 1-годишен All Upfront ~$0.197/час (32%); 3-годишен All Upfront ~$0.110/час (62%). За production база, която работи 24/7 повече от година, отказът от RI е една от най-скъпите пасивни грешки, които виждам в акаунти.

За разлика от EC2 Compute Savings Plans, RDS все още изисква купуване на Reserved Instances по семейство и регион. Те са modifiable (може да смените AZ, размер надолу в семейството, Multi-AZ конфигурация), но не са конвертируеми между engines. Затова:

Резервирайте минимума от baseline consumption, не пика. За база с 2× db.r7g.xlarge production плюс 1× db.r7g.large staging резервирайте 2× db.r7g.large (може да покрие xlarge с нормализация).
Използвайте size flexibility в рамките на семейството. 1× db.r7g.xlarge RI се равнява на 2× db.r7g.large RI по нормализация.
Избягвайте 3-годишни RI за engines в бърз upgrade път (например Aurora PostgreSQL 15 → 16 → 17), за да не се заключите в остаряла версия. За стабилни MySQL 8 бази 3-годишен All Upfront е обикновено безопасен.

За детайлно сравнение между двата инструмента и как да ги комбинирате с EC2/Lambda покритие, вижте пълното ръководство за Savings Plans срещу Reserved Instances. За RDS специално правилото е просто: винаги RI, никога Savings Plan, защото RDS SP не съществува като продукт.

Официалната ценова матрица и условия са в RDS pricing страницата на AWS. Винаги проверявайте по регион, защото разликите между us-east-1 и eu-central-1 достигат 15%. За допълнителен контекст върху reservation механиките погледнете и официалната документация за Reserved DB Instances.

Graviton за RDS: db.m7g, db.r7g и db.r8g

AWS Graviton3 инстанциите за RDS (db.m7g, db.r7g) са с ~10% по-нисък почасов ценник от x86 db.m6i/db.r6i и до 35% по-добра performance-per-dollar според вътрешните benchmark-и на AWS. Graviton4 (db.r8g), пуснат през 2025 г., добавя още ~15% throughput за същата цена. Поддържат се MySQL 8, PostgreSQL 13+, MariaDB 10.11+ и Aurora MySQL/PostgreSQL.

Миграцията е рестарт на инстанцията с промяна на DBInstanceClass:

aws rds modify-db-instance \
  --db-instance-identifier prod-postgres-01 \
  --db-instance-class db.r7g.xlarge \
  --apply-immediately

# За Multi-AZ base failover ще се случи автоматично
# и downtime-ът обикновено е под 60 секунди

Единствената реална пречка е ако имате native extensions с x86-специфичен код (PostgreSQL pg_repack обикновено работи; oracle_fdw не за всички версии) или third-party monitoring агенти. Проверете compatibility матрицата преди миграция и правете тест през snapshot restore на staging. Аз хванах точно такъв бъг в предишен проект: custom C extension се компилираше без грешка, но crash-ваше при първата тежка заявка. Snapshot тест на staging го хвана за 15 минути.

За стъпка-по-стъпка миграция включително Aurora clusters, RDS Proxy и IAM auth, следвайте пълното ръководство за AWS Graviton миграция към ARM64. За RDS специално планирайте да пренапишете custom Lambda triggers или externally hosted database extensions, ако има такива.

Multi-AZ, read replicas и скритите разходи за backups

Multi-AZ удвоява compute и storage разходите за standby, който не приема четене (освен ако използвате Multi-AZ DB Cluster deployment за MySQL/PostgreSQL, който отваря два четящи standby-та). Питайте се честно: dev и staging базите наистина ли имат нужда от Multi-AZ? В повечето акаунти, които одитирам, отговорът е не. Изключването на Multi-AZ за non-production намалява compute-а за тези инстанции с 50%.

# Изключване на Multi-AZ за staging
aws rds modify-db-instance \
  --db-instance-identifier staging-postgres-01 \
  --no-multi-az \
  --apply-immediately

Read replicas в друга AZ или регион генерират cross-AZ или cross-region data transfer. Cross-AZ трафикът е $0.01/GB (двупосочен), а cross-region е $0.02–$0.09/GB в зависимост от региона. За база с интензивни replication, това добавя $200–$800/месец. За намаляване на общия egress вижте стратегиите за намаляване на разходите за data transfer в AWS, Azure и GCP.

Backup storage е скритият убиец

AWS дава безплатен backup storage равен на размера на базата. Всичко над това се таксува ~$0.095/GB-месец. Retention от 35 дни за база с висок write throughput може да генерира 3–5× размера на базата в backup storage. Виждал съм акаунт, в който backup storage-ът беше $4200/месец при $2800/месец за самата RDS база, просто защото някой преди 2 години беше сложил retention на 35 дни и никой не беше поглеждал оттогава.

# Проверка на текущото backup използване
aws rds describe-db-instances \
  --query 'DBInstances[*].[DBInstanceIdentifier,BackupRetentionPeriod,AllocatedStorage]' \
  --output table

# Cost Explorer заявка за backup storage разходи
aws ce get-cost-and-usage \
  --time-period Start=2026-07-01,End=2026-08-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --filter '{"Dimensions":{"Key":"USAGE_TYPE_GROUP","Values":["RDS: Storage Snapshot"]}}' \
  --group-by Type=DIMENSION,Key=SERVICE

Практически препоръки за retention: 7 дни за production OLTP с ниска стойност на историята; 14 дни за стандартно production; 30–35 дни само за системи с compliance изисквания (PCI-DSS, HIPAA). За дълготрайно съхранение експортвайте snapshot-и към S3 с Glacier lifecycle rule. Разликата е драстична, $0.004/GB-месец в Deep Archive вместо $0.095/GB-месец в RDS backup storage.

Как да намаля разходите за AWS RDS?

Ето кратко работно flow, което следвам за всеки нов клиентски одит и което дава над 30% икономия в 80% от случаите:

Инвентаризация с Cost Explorer: групирайте по USAGE_TYPE и DBInstanceClass, за да видите топ 10 инстанции по разход.
Миграция gp2 → gp3 за всички бази под 4 TB. Скриптирайте, документирайте, приложете. Незабавни 15–20% на storage линията.
Graviton миграция на всичко, което не блокира от extensions. 10–20% на compute линията.
Изключване на Multi-AZ за dev/staging. 50% на compute за non-production.
Right-sizing: използвайте DBLoad, CPUUtilization, FreeableMemory за 14-дневен прозорец. Инстанции под 30% средно натоварване се смаляват с една стъпка.
Backup retention одит: намалете до 7–14 дни, освен ако compliance изисква повече. Експортвайте дългосрочни snapshot-и към Glacier.
Reserved Instances за baseline production consumption, след като right-sizing-ът е приключил (иначе резервирате грешен размер).
Serverless v2 за workloads под 50% средна утилизация или очевидно бърстови.

Тази последователност е умишлена. Първо правите операциите, които не изискват commitment (storage, Graviton, Multi-AZ, right-sizing), защото RI-тата се купуват върху финалния размер, не върху сегашния. Купуване на RI преди right-sizing е класическа скъпа грешка, защото заключвате overprovisioned baseline за 1 или 3 години напред.

Мониторинг и аларми за RDS харчене

Инвестицията в оптимизация губи стойност без непрекъснат мониторинг. Настройте три аларми чрез AWS Budgets и Cost Anomaly Detection:

Абсолютна аларма: месечен бюджет за RDS с 80%, 100% и 120% прагове.
Anomaly detection: monitor за RDS сервиза с $50/ден чувствителност, хваща изведнъж появили се test инстанции.
Storage growth: CloudWatch аларма върху FreeStorageSpace под 20%, предотвратява auto-scaling до по-скъп tier без warning.

За пълна настройка на тези инструменти и Athena заявки върху CUR 2.0 данни, вижте пълното ръководство за AWS Cost Explorer, AWS Budgets и Cost Anomaly Detection. Ключовият дългосрочен reflex е следният: всеки път, когато някой стартира нова RDS инстанция без тагове или без business justification, аларма трябва да задейства review process. Не месеци по-късно на билинга.

За екипи, които оперират в multi-cloud среда, стандартизирайте отчетите чрез FOCUS 1.2 спецификацията на FinOps Foundation. Това позволява да сравнявате RDS разходи с Azure SQL или Cloud SQL без ръчна нормализация на billing данни.

Често задавани въпроси

Aurora ли е по-евтина от RDS?

Не по подразбиране. Aurora provisioned instances са около 20% по-скъпи на час от еквивалентните стандартни RDS MySQL/PostgreSQL инстанции, но storage-ът се плаща само за реалното използване (не за allocated), което може да компенсира при бази с много празно място. Aurora Serverless v2 е по-евтина от provisioned Aurora само когато средното натоварване е под ~50% от peak-а.

Кой е най-евтиният RDS instance type?

За dev/test изборът е db.t4g.micro ($0.016/час в us-east-1), включен в AWS Free Tier за 12 месеца. За production baseline препоръчвам db.t4g.small или db.t4g.medium с burstable CPU credits. За стабилно натоварване от production мащаб, db.m7g.large или db.r7g.large с 1-годишен No Upfront Reserved Instance дава най-добро съотношение цена към производителност.

Струва ли Multi-AZ двойно повече?

Да, по същество удвоява compute и storage разходите, защото standby-ът се плаща като напълно активна инстанция. За production бази това е приемлив разход за high availability, но за dev, staging и internal tooling бази е излишно и представлява една от най-често срещаните overpayments в RDS сметки.

Безплатни ли са RDS backups?

Само до размера на базата. AWS предоставя backup storage равен на allocated storage без такса; всичко над това се таксува ~$0.095/GB-месец за automated backups и manual snapshots. Retention от 35 дни за база с висок write rate често струва повече от самата база. 7–14 дни е оптимален baseline за повечето production системи.

Мога ли да сменя storage type на работеща RDS инстанция?

Да. Промяната от gp2 към gp3 е онлайн операция без downtime и се задейства с modify-db-instance --storage-type gp3. За production избягвайте --apply-immediately в пиков час, защото модификацията може да задейства кратък I/O freeze; планирайте през maintenance window.