Regional resource — cloud provider scope modelida bitta geografik regionga tegishli, lekin ma’lum availability zone bilan cheklanmagan resurs. U regional API endpoint, quota va failure boundary ostida boshqariladi. Regional deb atalishi resurs avtomatik ravishda barcha zonalarda redundant yoki zone nosozligiga chidamli ekanini anglatmaydi.
Scope farqlari
Cloud resurslar global, regional yoki zonal bo‘lishi mumkin. Zonal VM va disk aniq zonada joylashadi. Regional load balancer, virtual network yoki managed service bir nechta zonadagi komponentlarni qamrashi mumkin. Global DNS yoki anycast frontend esa regionlardan yuqori scope’da ishlaydi.
Scope resurs nomi, API URL, IAM path va lifecyclega ta’sir qiladi. Bir regiondagi nom boshqa regionda takrorlanishi mumkin. Infrastructure as code konfiguratsiyasida regionni implicit defaultga qoldirish noto‘g‘ri joyda resurs yaratish xavfini oshiradi.
Availability semantikasi
Regional service control plane’i ko‘p zonali bo‘lishi mumkin, ammo data plane foydalanuvchi tanlagan bitta subnet yoki zonal backendga bog‘lanishi ehtimol. Managed database “regional” bo‘lsa ham multi-zone option alohida yoqilishi mumkin. Providerning architecture va SLA tavsifi tekshiriladi.
Regional resource region outage paytida ishlamasligi mumkin. Multi-region recovery uchun configuration, data replication, DNS yoki global traffic management alohida yaratiladi.
Tarmoq va ma’lumot
Regional virtual network zonalarni bog‘lasa, subnet scope’i providerga qarab regional yoki zonal bo‘ladi. Firewall rule regional tarmoqqa tegishli bo‘lsa ham target instance label yoki interface orqali tanlanadi. Cross-zone traffic fee va routing path servicega qarab farq qiladi.
Data residency talabi resource regionini tanlash bilan boshlanadi, lekin backup, log, telemetry va encryption keylar qayerda saqlanishini ham qamraydi. Control plane metadata boshqa joyda qayta ishlanishi mumkinligi hujjatdan aniqlanadi.
Ekspluatatsiya
Quota odatda region bo‘yicha hisoblanadi. Disaster paytida boshqa regionda birdan capacity olish uchun quota va image oldindan tayyorlanadi. Monitoring region labelini saqlaydi, shunda error va latency geografiya bo‘yicha ajratiladi.
Resource dependency graph scope’larni ko‘rsatishi kerak: regional load balancer ortidagi bitta zonal backend regional availability bermaydi. Deployment kamida ikki zonaga backend qo‘yadi, health check va capacityni zone loss sharoitida sinaydi. Regional resource tanlash arxitektura qarorining bir qismi, tayyor high availability yechimi emas.
Hayot sikli
Regional resource boshqa regionga “move” qilinmasligi mumkin. Clone, export-import yoki yangi resource yaratib trafficni ko‘chirish talab etiladi. Resource ID o‘zgarsa IAM policy, monitoring, DNS va application configuration ham yangilanadi. Terraform kabi vositada region provider aliasi aniq ko‘rsatilmasa destroy-create reja kutilmagan ta’sir berishi mumkin.
Deletion protection va backup policy region scope’iga moslanadi. Region disabled yoki account policy bilan taqiqlansa recovery operatori target regionda kerakli permissionga ega bo‘lishi kerak. Service catalog regional resursning owneri, data classificationi, dependencylari va recovery usulini saqlaydi. Bu ma’lumot incident vaqtida faqat console nomiga qarab scope va durabilityni taxmin qilish zaruratini kamaytiradi.
Tagging standartida region takror yozilishi shart bo‘lmasligi mumkin, ammo cost allocation va inventory export source regionni saqlaydi. Bir xil logical service’ning turli regional nusxalari common service ID va unique resource ID bilan ajratiladi.
Bog‘liq tushunchalar
Cloud region, Availability zone, Zonal resource, Global resource, Multi-zone deployment, Data residency, Regional quota, Disaster recovery