Cloud pohrana: Smanjite troškove 70% (2026)

Zašto su troškovi pohrane tihi ubojica cloud proračuna

Kad netko spomene optimizaciju troškova oblaka, većina nas odmah pomisli na računalne resurse — instance, kontejnere, serverless funkcije. No postoji jedan trošak koji tiho raste iz mjeseca u mjesec, a rijetko tko mu posvećuje dovoljno pažnje: pohrana podataka.

I tu brojke stvarno govore same za sebe. Prema podacima iz 2026., organizacije u prosjeku troše 30 do 40 posto više na cloud pohranu nego što bi trebale. Razlog? Uglavnom drže podatke na skupim razredima pohrane dugo nakon što im je zadnji put itko pristupio.

Problem je posebno podmukao jer se troškovi pohrane akumuliraju. Dok računalni resursi generiraju troškove samo dok rade, podaci jednom pohranjeni u oblak tamo ostaju — i svaki mjesec se naplaćuju. Evo konkretnog primjera: tvrtka koja pohranjuje 100 TB podataka na AWS S3 Standard plaća oko 2.300 dolara mjesečno samo za pohranu. Prebacivanjem neaktivnih podataka na S3 Glacier Deep Archive, taj trošak pada na samo 99 dolara. To je ušteda od preko 95%, i nije pretjerivanje.

U ovom vodiču proći ćemo kako implementirati lifecycle politike na sva tri velika cloud providera — AWS S3, Azure Blob Storage i Google Cloud Storage — s konkretnim primjerima koda, JSON konfiguracijama i Terraform predlošcima koje možete odmah primijeniti u svojem okruženju.

Razumijevanje razreda pohrane: Usporedba S3, Azure Blob i GCS

Prije nego krenemo s konfiguracijom, vrijedi razumjeti kakve razrede pohrane svaki provider nudi. Svi funkcioniraju na istom principu: što rjeđe pristupate podacima, to je pohrana jeftinija, ali je pristup skuplji i sporiji. Zvuči jednostavno, ali iznenađujuće je koliko timova nikad ne iskoristi te niže razrede.

AWS S3 — sedam razreda pohrane

Amazon S3 nudi najgranularnije opcije sa čak sedam razreda:

S3 Standard: ~0,023 $/GB — za podatke kojima se često pristupa
S3 Intelligent-Tiering: automatski prebacuje objekte između razreda na temelju pristupa (više o ovome kasnije)
S3 Standard-IA (Infrequent Access): ~0,0125 $/GB — za podatke kojima se pristupa rjeđe od jednom mjesečno
S3 One Zone-IA: ~0,01 $/GB — isto kao Standard-IA, ali u jednoj zoni dostupnosti
S3 Glacier Instant Retrieval: ~0,004 $/GB — za rijetko pristupane podatke s trenutačnim dohvatom
S3 Glacier Flexible Retrieval: ~0,0036 $/GB — za arhivske podatke s dohvatom od nekoliko minuta do sati
S3 Glacier Deep Archive: ~0,00099 $/GB — najjeftinija opcija za dugoročnu arhivu

Azure Blob Storage — pet razreda

Microsoft Azure nudi nešto jednostavniji sustav s pet razreda:

Hot: ~0,018 $/GB — za česte pristupe, najjeftiniji za čitanje
Cool: ~0,01 $/GB — za podatke kojima se pristupa rjeđe od jednom mjesečno
Cold: pozicioniran između Cool i Archive — nudi trenutni pristup po nižoj cijeni
Archive: ~0,002 $/GB — za rijetko pristupane podatke, dohvat traje satima

Zanimljiv detalj: Hot razred na Azureu je tipično 15 do 20% jeftiniji od AWS S3 Standard za istu količinu podataka. Ako imate većinu podataka u "hot" kategoriji, to nije zanemariva razlika.

Google Cloud Storage — četiri razreda plus Autoclass

Google nudi četiri razreda i jedinstven Autoclass mehanizam:

Standard: ~0,020 $/GB — za podatke kojima se često pristupa
Nearline: za podatke kojima se pristupa rjeđe od jednom mjesečno
Coldline: za podatke kojima se pristupa rjeđe od jednom u 90 dana
Archive: ~0,001 $/GB — za podatke kojima se pristupa manje od jednom godišnje
Autoclass: automatski sustav koji koristi strojno učenje za prebacivanje objekata između razreda

AWS S3 Lifecycle politike: Korak po korak

Ajmo na stvar. S3 Lifecycle politike omogućuju definiranje pravila koja automatski prebacuju objekte između razreda pohrane na temelju starosti ili ih brišu nakon određenog vremena. Iskreno, ovo je najmoćniji alat za automatiziranu optimizaciju troškova pohrane na AWS-u — i jednom kad ga postavite, radi sam.

JSON konfiguracija za S3 Lifecycle

Evo primjera JSON politike koja progresivno prebacuje podatke kroz razrede i na kraju ih briše:

{
  "Rules": [
    {
      "ID": "OptimizacijaLogova",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "logs/"
      },
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER_IR"
        },
        {
          "Days": 180,
          "StorageClass": "DEEP_ARCHIVE"
        }
      ],
      "Expiration": {
        "Days": 730
      }
    },
    {
      "ID": "CiscenjePrivremenihDatoteka",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "temp/"
      },
      "Expiration": {
        "Days": 7
      }
    },
    {
      "ID": "ArhiviranjeSigurnosnihKopija",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "backups/"
      },
      "Transitions": [
        {
          "Days": 7,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 30,
          "StorageClass": "GLACIER"
        }
      ],
      "Expiration": {
        "Days": 365
      }
    }
  ]
}

Što ova politika zapravo radi? Logove prebacuje na Standard-IA nakon 30 dana, na Glacier Instant Retrieval nakon 90, na Deep Archive nakon 180, a briše ih nakon 2 godine. Privremene datoteke briše nakon samo 7 dana (jer, budimo realni, ako vam trebaju nakon tjedan dana, nešto nije u redu). Sigurnosne kopije se arhiviraju progresivno i brišu nakon godinu dana.

Primjena putem AWS CLI-ja

Spremite gornji JSON u datoteku lifecycle-policy.json i primijenite ga:

# Primjena lifecycle politike na S3 bucket
aws s3api put-bucket-lifecycle-configuration \
  --bucket naziv-vaseg-bucketa \
  --lifecycle-configuration file://lifecycle-policy.json

# Provjera trenutne lifecycle konfiguracije
aws s3api get-bucket-lifecycle-configuration \
  --bucket naziv-vaseg-bucketa

Terraform implementacija

Ako koristite Terraform za upravljanje infrastrukturom (a trebali biste, ali to je tema za drugi članak), evo kako definirati lifecycle politiku pomoću resursa aws_s3_bucket_lifecycle_configuration:

resource "aws_s3_bucket" "data_lake" {
  bucket = "tvrtka-data-lake-prod"

  tags = {
    Environment  = "production"
    Team         = "data-engineering"
    CostCenter   = "CC-3201"
  }
}

resource "aws_s3_bucket_lifecycle_configuration" "data_lake_lifecycle" {
  bucket = aws_s3_bucket.data_lake.id

  rule {
    id     = "OptimizacijaLogova"
    status = "Enabled"

    filter {
      prefix = "logs/"
    }

    transition {
      days          = 30
      storage_class = "STANDARD_IA"
    }

    transition {
      days          = 90
      storage_class = "GLACIER_IR"
    }

    transition {
      days          = 180
      storage_class = "DEEP_ARCHIVE"
    }

    expiration {
      days = 730
    }
  }

  rule {
    id     = "CiscenjePrivremenihDatoteka"
    status = "Enabled"

    filter {
      prefix = "temp/"
    }

    expiration {
      days = 7
    }
  }

  rule {
    id     = "ArhiviranjeSigurnosnihKopija"
    status = "Enabled"

    filter {
      prefix = "backups/"
    }

    transition {
      days          = 7
      storage_class = "STANDARD_IA"
    }

    transition {
      days          = 30
      storage_class = "GLACIER"
    }

    expiration {
      days = 365
    }
  }
}

Važna napomena: argument lifecycle_rule unutar resursa aws_s3_bucket je zastarjeo (deprecated). Uvijek koristite zaseban resurs aws_s3_bucket_lifecycle_configuration — stari pristup može uzrokovati konflikte i neočekivano ponašanje.

S3 Intelligent-Tiering: Kada ga koristiti umjesto lifecycle politika

S3 Intelligent-Tiering je alternativa ručnim lifecycle politikama koja automatski prati pristup svakom objektu i prebacuje ga u optimalan razred. Otkad je pokrenut 2018. godine, korisnici su uštedjeli ukupno preko 6 milijardi dolara u usporedbi sa S3 Standard pohranom. Nije loše za značajku koju samo uključite.

Koristite Intelligent-Tiering kada:

Ne poznajete obrasce pristupa podacima unaprijed
Obrasci pristupa se mijenjaju tijekom vremena
Želite potpuno automatiziran pristup bez održavanja pravila

Koristite ručne lifecycle politike kada:

Točno znate kada podaci postaju neaktivni (npr. logovi stariji od 30 dana)
Trebate automatsko brisanje objekata nakon određenog perioda
Imate mnogo malih objekata (manji od 128 KB) koje Intelligent-Tiering ne premješta

Ali znate što? Najbolji pristup je zapravo kombinacija oboje — koristite lifecycle politike za poznate obrasce i automatsko brisanje, a Intelligent-Tiering za sve ostalo:

resource "aws_s3_bucket_lifecycle_configuration" "kombinirani_pristup" {
  bucket = aws_s3_bucket.data_lake.id

  # Prebaci sve na Intelligent-Tiering za automatsku optimizaciju
  rule {
    id     = "PrebacujNaIntelligentTiering"
    status = "Enabled"

    filter {
      prefix = "data/"
    }

    transition {
      days          = 0
      storage_class = "INTELLIGENT_TIERING"
    }
  }

  # Brisi privremene datoteke nakon 7 dana
  rule {
    id     = "BrisiTemp"
    status = "Enabled"

    filter {
      prefix = "temp/"
    }

    expiration {
      days = 7
    }
  }
}

Azure Blob Storage: Lifecycle Management politike

Azure Blob Storage koristi sličan koncept s lifecycle management politikama koje se definiraju u JSON formatu. Jedna od prednosti Azurea je dodatni Cold razred pohrane koji pruža trenutni pristup po cijeni nižoj od Cool razreda — nešto što AWS nema u direktnom ekvivalentu.

JSON politika za Azure Blob

Evo politike koja pokriva logove, sigurnosne kopije i upravljanje verzijama:

{
  "rules": [
    {
      "enabled": true,
      "name": "PrebacujLogoveCool",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "tierToCold": {
              "daysAfterModificationGreaterThan": 90
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 180
            },
            "delete": {
              "daysAfterModificationGreaterThan": 730
            }
          },
          "snapshot": {
            "delete": {
              "daysAfterCreationGreaterThan": 90
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["logs/", "diagnostics/"]
        }
      }
    },
    {
      "enabled": true,
      "name": "ArhivirajSigurnosneKopije",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 7
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 30
            },
            "delete": {
              "daysAfterModificationGreaterThan": 365
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["backups/"]
        }
      }
    },
    {
      "enabled": true,
      "name": "CistiStareVerzije",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "delete": {
              "daysAfterCreationGreaterThan": 60
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"]
        }
      }
    }
  ]
}

Primjena putem Azure CLI-ja

# Primjena lifecycle politike na storage account
az storage account management-policy create \
  --account-name naziv-storage-accounta \
  --policy @lifecycle-policy.json \
  --resource-group naziv-resource-grupe

# Pregled trenutne politike
az storage account management-policy show \
  --account-name naziv-storage-accounta \
  --resource-group naziv-resource-grupe

Terraform implementacija za Azure

resource "azurerm_storage_management_policy" "lifecycle" {
  storage_account_id = azurerm_storage_account.main.id

  rule {
    name    = "PrebacujLogoveCool"
    enabled = true

    filters {
      prefix_match = ["logs/", "diagnostics/"]
      blob_types   = ["blockBlob"]
    }

    actions {
      base_blob {
        tier_to_cool_after_days_since_modification_greater_than    = 30
        tier_to_cold_after_days_since_modification_greater_than    = 90
        tier_to_archive_after_days_since_modification_greater_than = 180
        delete_after_days_since_modification_greater_than          = 730
      }
      snapshot {
        delete_after_days_since_creation_greater_than = 90
      }
    }
  }

  rule {
    name    = "ArhivirajSigurnosneKopije"
    enabled = true

    filters {
      prefix_match = ["backups/"]
      blob_types   = ["blockBlob"]
    }

    actions {
      base_blob {
        tier_to_cool_after_days_since_modification_greater_than    = 7
        tier_to_archive_after_days_since_modification_greater_than = 30
        delete_after_days_since_modification_greater_than          = 365
      }
    }
  }
}

Jedno upozorenje koje sam naučio na teži način: nakon kreiranja ili ažuriranja Azure lifecycle politike, promjene mogu trebati do 24 sata da postanu aktivne. Nemojte paničariti ako ne vidite učinak odmah. Također, Azure podržava do 100 pravila po politici, a svako pravilo može imati do 10 prefiksa — za većinu scenarija to je više nego dovoljno.

Google Cloud Storage: Autoclass nasuprot ručnim Lifecycle pravilima

Google Cloud Storage nudi nešto drugačiji pristup s Autoclass značajkom — sustavom temeljenim na strojnom učenju koji automatski prebacuje objekte između razreda na temelju stvarnog pristupa. Zvuči sjajno na papiru, ali ima i svoja ograničenja.

Kako Autoclass funkcionira

Kad je Autoclass omogućen, objekti se automatski prebacuju prema sljedećem rasporedu:

Kad se objektu pristupi → prebacuje se na Standard
30 dana bez pristupa → prebacuje se na Nearline
90 dana bez pristupa → prebacuje se na Coldline
365 dana bez pristupa → prebacuje se na Archive

Velika prednost Autoclassa: nema naknada za dohvat podataka, nema naknada za prijevremeno brisanje i nema naknada za tranzicije između razreda. Za bucket od 500 TB s mješovitim pristupom, godišnja ušteda može doseći oko 40.000 dolara. Prilično uvjerljivo.

Ograničenja Autoclassa

Ali Autoclass nije savršen za svaki scenarij. Evo gdje zapinje:

Male datoteke: objekti manji od 128 KB ne premještaju se u hladnije razrede — ostaju trajno na Standard razredu
Spore tranzicije: treba punih 365 dana da objekt dođe do Archive razreda, bez mogućnosti ubrzanja
Nema brisanja: Autoclass upravlja samo tranzicijama, ne i brisanjem objekata
Ponovno zagrijavanje: jedan jedini pristup arhiviranom objektu vraća ga na Standard, i čitav ciklus od 365 dana počinje ispočetka
Nekompatibilnost: Autoclass i Object Lifecycle Management pravila za promjenu razreda ne mogu koegzistirati na istom bucketu

Ručna Lifecycle pravila na GCS-u

Za predvidljive obrasce pristupa, ručna pravila mogu ostvariti veće uštede jer ne morate čekati da sustav "nauči" vaše obrasce:

{
  "lifecycle": {
    "rule": [
      {
        "action": {
          "type": "SetStorageClass",
          "storageClass": "NEARLINE"
        },
        "condition": {
          "age": 30,
          "matchesPrefix": ["logs/"]
        }
      },
      {
        "action": {
          "type": "SetStorageClass",
          "storageClass": "COLDLINE"
        },
        "condition": {
          "age": 90,
          "matchesPrefix": ["logs/"]
        }
      },
      {
        "action": {
          "type": "SetStorageClass",
          "storageClass": "ARCHIVE"
        },
        "condition": {
          "age": 180,
          "matchesPrefix": ["logs/", "backups/"]
        }
      },
      {
        "action": {
          "type": "Delete"
        },
        "condition": {
          "age": 730,
          "matchesPrefix": ["logs/"]
        }
      },
      {
        "action": {
          "type": "Delete"
        },
        "condition": {
          "age": 7,
          "matchesPrefix": ["temp/"]
        }
      }
    ]
  }
}

Primjena putem gcloud CLI-ja

# Primjena lifecycle konfiguracije
gsutil lifecycle set lifecycle-config.json gs://naziv-vaseg-bucketa

# Pregled trenutne lifecycle konfiguracije
gsutil lifecycle get gs://naziv-vaseg-bucketa

# Alternativno, pomocu gcloud naredbe
gcloud storage buckets update gs://naziv-vaseg-bucketa \
  --lifecycle-file=lifecycle-config.json

Terraform implementacija za GCS

resource "google_storage_bucket" "data_bucket" {
  name     = "tvrtka-data-prod"
  location = "EU"

  # Opcija 1: Autoclass za nepredvidive obrasce pristupa
  autoclass {
    enabled                = true
    terminal_storage_class = "ARCHIVE"
  }

  # NAPOMENA: Ne mozete koristiti Autoclass i lifecycle_rule istovremeno
  # Odkomentirajte donje blokove ako zelite rucna pravila umjesto Autoclassa

  # lifecycle_rule {
  #   condition {
  #     age = 30
  #     matches_prefix = ["logs/"]
  #   }
  #   action {
  #     type          = "SetStorageClass"
  #     storage_class = "NEARLINE"
  #   }
  # }

  # lifecycle_rule {
  #   condition {
  #     age = 90
  #     matches_prefix = ["logs/"]
  #   }
  #   action {
  #     type          = "SetStorageClass"
  #     storage_class = "COLDLINE"
  #   }
  # }

  # lifecycle_rule {
  #   condition {
  #     age = 7
  #     matches_prefix = ["temp/"]
  #   }
  #   action {
  #     type = "Delete"
  #   }
  # }

  labels = {
    environment = "production"
    team        = "data-engineering"
    cost-center = "cc-3201"
  }
}

Kada koristiti Autoclass, a kada ručna pravila

Evo kako donijeti tu odluku:

Autoclass: novi projekti bez povijesnih podataka, nepredvidivi obrasci pristupa, timovi bez kapaciteta za održavanje pravila
Ručna lifecycle pravila: poznati obrasci (logovi, sigurnosne kopije), potreba za automatskim brisanjem, strogi regulatorni zahtjevi, veliki bucketi s poznatim hladnim podacima
Kombinacija: možete omogućiti Autoclass za tranzicije i dodati lifecycle pravila isključivo za brisanje objekata — što je po mom iskustvu često najelegantniji pristup

Skriveni troškovi koje mnogi zanemaruju

Osim samih troškova pohrane, postoji nekoliko skrivenih generatora troškova na koje biste trebali obratiti pažnju. Ovo su stavke koje se ne vide na prvi pogled u dashboardu, ali znaju ozbiljno naštimati mjesečni račun.

Egress troškovi (izlazni promet)

Prijenos podataka iz oblaka može činiti 10 do 15% ukupnih troškova pohrane — iznenađujuće velik postotak. AWS naplaćuje oko 0,09 $/GB za prvih 10 TB izlaznog prometa, dok Azure i GCP imaju slične tarife. Kopiranje 10 TB mjesečno iz S3-a na GCS košta oko 900 dolara samo za izlazni promet iz AWS-a.

Kako smanjiti egress troškove:

Držite podatke i računalne resurse kod istog providera kada je moguće
Koristite CDN (CloudFront, Azure CDN, Cloud CDN) za česte pristupe javnim podacima
Razmotrite Cloudflare R2 koji ne naplaćuje egress — da, nula dolara za izlazni promet

Troškovi zahtjeva (API poziva)

Svaki PUT, GET, LIST i DELETE zahtjev se naplaćuje. Ovo posebno pogađa workloade s mnogo malih datoteka. Na primjer, milijun GET zahtjeva na S3 Standard košta 0,40 dolara, ali isti broj zahtjeva na Glacier Instant Retrieval košta 10 dolara — 25 puta više. Ako imate workload koji često čita podatke, dobro razmislite prije nego ih prebacite na hladniji razred.

Troškovi verzioniranja objekata

Object versioning je korisna značajka za zaštitu od slučajnog brisanja, ali neograničeno zadržavanje verzija može brzo napuhati troškove. Vidjao sam buckete gdje su stare verzije zauzimale tri puta više prostora od aktualnih podataka. Ograničite broj verzija i obavezno konfigurirajte lifecycle pravila za automatsko brisanje starih verzija.

Napušteni (orphaned) resursi

EBS volumeni odvojeni od terminiranih instanci, stari snapshotovi, neiskorišteni Elastic IP-jevi — svi ovi resursi generiraju troškove, a ne služe ničemu. Redovito pregledavajte i čistite resurse koji nemaju vlasnika ili svrhu. Ovo je jedno od onih područja gdje se mali iznosi tijekom mjeseci pretvore u ozbiljan trošak.

Praktična strategija za implementaciju u 5 koraka

Umjesto da pokušavate optimizirati sve odjednom (što gotovo nikad ne završi dobro), slijedite ovaj strukturirani pristup:

Korak 1: Analiza trenutnog stanja

Koristite alate svog providera za uvid u obrasce korištenja:

# AWS: Analiza S3 bucketa pomocu S3 Storage Lens
aws s3control list-storage-lens-configurations \
  --account-id 123456789012

# Azure: Pregled troškova pohrane
az cost management query \
  --type Usage \
  --timeframe MonthToDate \
  --dataset-filter "{\"dimensions\":{\"name\":\"ServiceName\",\"operator\":\"In\",\"values\":[\"Storage\"]}}"

# GCP: Analiza troškova pohrane
bq query --use_legacy_sql=false \
  'SELECT service.description, SUM(cost) as total_cost
  FROM `projekt.dataset.gcp_billing_export`
  WHERE service.description LIKE "%Storage%"
  GROUP BY service.description
  ORDER BY total_cost DESC'

Korak 2: Identificirajte brze pobjede

Počnite s najočitijim uštedama — ovo su stvari koje možete riješiti u jednom popodnevu:

Obrišite privremene datoteke i stare sigurnosne kopije
Uklonite neiskorištene EBS volumene i snapshotove
Prebacite poznate hladne podatke na arhivske razrede

Korak 3: Implementirajte lifecycle politike

Na temelju analize iz prvog koraka, definirajte i primijenite lifecycle politike za svaki bucket ili kontejner. Počnite s ne-proizvodnim okruženjima za testiranje — to je ključno. Nikad ne želite da vas prvi lifecycle run iznenadi u produkciji.

Korak 4: Postavite praćenje i alerte

Konfigurirajte alerte za nagle poraste troškova pohrane. Koristite AWS Cost Anomaly Detection, Azure Cost Management alerte ili GCP Budget alerte. Postavljanje ovog koraka traje doslovno 10 minuta, a može vas spasiti od neugodnih iznenađenja.

Korak 5: Redovito pregledavajte i prilagođavajte

Lifecycle politike nisu nešto što postavite jednom i zaboravite. Pregledavajte ih kvartalno i prilagođavajte na temelju promjena u obrascima korištenja, novih razreda pohrane ili promjena cijena providera. Cloud provideri redovito uvode nove opcije, a vi biste ih trebali iskoristiti.

Usporedna tablica: S3 vs. Azure Blob vs. GCS

Evo pregleda ključnih razlika za brzu referencu:

Broj razreda: AWS S3 — 7, Azure Blob — 5, GCS — 4 + Autoclass
Cijena "hot" razreda: AWS — ~0,023 $/GB, Azure — ~0,018 $/GB, GCS — ~0,020 $/GB
Cijena arhivskog razreda: AWS — ~0,00099 $/GB, Azure — ~0,002 $/GB, GCS — ~0,001 $/GB
Automatizacija: AWS — Intelligent-Tiering, Azure — pravila temeljena na pravilima, GCS — Autoclass (ML)
Egress cijena: AWS — 0,09 $/GB, Azure — 0,087 $/GB, GCS — varijabilno
Maksimalan broj lifecycle pravila: AWS — 1000, Azure — 100, GCS — 100

Često postavljana pitanja

Koliko mogu uštedjeti implementacijom lifecycle politika za cloud pohranu?

Tipične uštede kreću se od 40 do 70% na troškovima pohrane, ovisno o omjeru aktivnih i neaktivnih podataka. Organizacije koje nikad nisu implementirale lifecycle politike obično imaju 60 do 80% podataka na najskupljem razredu pohrane, iako im se pristupa rjeđe od jednom mjesečno. Prebacivanje tih podataka na odgovarajuće razrede može dramatično smanjiti mjesečni račun.

Koja je razlika između S3 Intelligent-Tiering i lifecycle politika?

Lifecycle politike prebacuju podatke prema rasporedu koji vi definirate — npr. "nakon 30 dana prebaci na Standard-IA". Intelligent-Tiering automatski prati pristup svakom objektu i prebacuje ga na temelju stvarnog korištenja. Ključna razlika: ako "hladni" objekt iznenada postane aktivan, lifecycle pravila to neće prepoznati, dok Intelligent-Tiering automatski promovira objekt nazad na brži razred. S druge strane, lifecycle politike omogućuju automatsko brisanje objekata, što Intelligent-Tiering ne podržava.

Mogu li kombinirati Autoclass i lifecycle pravila na Google Cloud Storage?

Djelomično. Autoclass i standardna lifecycle pravila za promjenu razreda pohrane ne mogu koegzistirati na istom bucketu. Međutim, možete kombinirati Autoclass s lifecycle pravilima koja se koriste isključivo za brisanje objekata — što je zapravo preporučeni pristup za većinu scenarija jer Autoclass sam po sebi ne podržava automatsko brisanje.

Trebam li se brinuti o troškovima dohvata kod arhivskih razreda?

Apsolutno da. Troškovi dohvata mogu biti značajni i trebali bi utjecati na vašu strategiju. Na primjer, dohvat 1 TB iz S3 Glacier Flexible Retrieval košta oko 10 dolara za standardni dohvat. Pravilo palca: nikad ne arhivirajte podatke kojima mislite često pristupati. Koristite alate poput S3 Storage Lens ili Azure Storage Analytics za analizu stvarnih obrazaca pristupa prije odluke o tranziciji.

Kako početi s optimizacijom ako imam stotine bucketa ili kontejnera?

Počnite s identifikacijom najvećih bucketa — u većini organizacija 20% bucketa čini 80% troškova (klasično Pareto pravilo). Koristite AWS S3 Storage Lens, Azure Storage Explorer ili GCS Monitoring za identifikaciju najvećih potrošača. Zatim primijenite lifecycle politike najprije na te buckete, testirajte u ne-proizvodnom okruženju, i postupno širite na ostatak infrastrukture. Automatizacija putem Terraforma ili CloudFormation olakšava konzistentnu primjenu na svim bucketima.