Anomalii Cost Cloud AWS Azure GCP 2026

Actualizat: 9 august 2026

Detectarea anomaliilor de cost cloud este procesul de identificare automată a creșterilor bruște și neașteptate în facturile AWS, Azure sau GCP, folosind modele statistice sau ML pentru a alerta echipa FinOps înainte ca supracosturile să se acumuleze pentru o lună întreagă. În 2026, toți cei trei hyperscaler-i oferă servicii native gratuite (AWS Cost Anomaly Detection, Microsoft Cost Management anomaly insights, GCP Cost Anomaly Detection în GA din februarie 2026), dar comportamentul lor diferă radical. Latența, granularitatea și rata falselor pozitive nu sunt comparabile out-of-the-box. Am rulat toate trei serviciile în paralel pe același portofoliu multi-cloud timp de șase luni, iar în ghidul de mai jos împart exact ce funcționează, ce nu și când merită să construiești un detector propriu peste datele FOCUS.

AWS Cost Anomaly Detection rulează de 3 ori pe zi cu latență de 24-48h și este complet gratuit. E cea mai matură opțiune nativă în 2026.
Microsoft Cost Management folosește WaveNet (rețea neuronală) pentru anomaly insights la nivel de subscription și resource group, cu latență de 36-72 ore.
GCP Cost Anomaly Detection a intrat în GA în februarie 2026 și acoperă doar dimensiunile Project, Service și SKU. Mai limitat decât competitorii, dar cu integrare nativă în Cloud Billing.
Serviciile native ratează frecvent anomalii sub 100$/zi și generează 20-40% false pozitive fără tuning corect al monitorurilor.
Un detector custom cu Prophet peste export FOCUS 1.2 rulează pe sub 5$/lună în BigQuery și oferă latență sub 6 ore.
Cea mai bună strategie 2026: nativ pentru „safety net", plus custom pentru workload-urile critice, plus integrare Slack/PagerDuty cu triage automat.

Ce este detectarea anomaliilor de cost cloud?

Detectarea anomaliilor de cost cloud este o disciplină FinOps care aplică modele statistice (regresie, sezonalitate, ML) asupra datelor zilnice de facturare, pentru a semnala automat cheltuielile care ies din tiparul istoric al unei dimensiuni (cont, serviciu, tag, region). Diferența față de un simplu buget este critică. Un buget te alertează când depășești un plafon absolut („$10.000/lună"), în timp ce un detector de anomalii te alertează când cheltuiala se abate de la comportamentul așteptat (de exemplu, serviciul S3 crește cu 340% față de media ultimelor 60 zile). În practică, cele două se completează reciproc: bugetele prind derapajele lente, iar detectorii prind spike-urile bruște.

Pentru cei care abia încep, recomand întâi să auditați risipa cu ghidul nostru despre resurse zombie și eliminarea risipei cloud, apoi să activați detectarea anomaliilor. Un mediu plin de resurse zombie generează atât de mult zgomot că detectorii devin inutili (false pozitive continue). În mod ideal, detectarea anomaliilor este ultima linie de apărare, nu prima.

Există trei clase de anomalii pe care le vezi în producție: spike-uri operaționale (un cron care a rămas în loop, o retenție de log-uri modificată accidental), scurgeri de securitate (chei AWS compromise care rulează minerit cripto pe GPU) și schimbări de arhitectură (echipa a activat replicare cross-region fără să spună). Fiecare cere un răspuns diferit, iar un detector bun trebuie să ofere context suficient pentru triage rapid. Nu doar „ai o anomalie de $850".

Comparație multi-cloud: AWS vs Azure vs GCP

Am rulat toate trei serviciile native în paralel pe un portofoliu real de ~$180k/lună distribuit între AWS (60%), Azure (25%) și GCP (15%) timp de șase luni. Sincer, mă așteptam la diferențe mici, dar rezultatele au fost surprinzător de eterogene. Iată tabelul rezumat pe care îl folosesc când consult clienți despre care serviciu nativ să activeze mai întâi și când e nevoie de un detector custom.

Dimensiune	AWS Cost Anomaly Detection	Azure Anomaly Insights	GCP Cost Anomaly Detection
Preț	Gratuit	Gratuit	Gratuit
Model	Random Cut Forest	WaveNet (rețea neuronală)	Modele statistice proprietare
Frecvență scanare	De 3 ori pe zi	Zilnic	Zilnic
Latență medie detecție	24-48 ore	36-72 ore	24-36 ore
Granularitate	Service, LinkedAccount, Cost Category, Tag	Subscription, Resource Group	Project, Service, SKU
Prag minim detectabil	~$100/zi (configurable)	~$50/zi	Configurable prin Cost Alerts
Notificare nativă	SNS, e-mail (individual + summary)	Action Groups (email, webhook, ITSM)	Pub/Sub, Cloud Functions, e-mail
Root cause automat	Da (top 3 contributori)	Parțial (drill-down manual)	Da (SKU + Project)
Data GA	2020	Aprilie 2022	Februarie 2026

Concluzia mea sinceră după șase luni: AWS este cel mai matur din toate punctele de vedere, Azure e cel mai bun la detectarea creșterilor mici (are prag mai jos), iar GCP a recuperat mult după GA-ul din februarie 2026, dar încă nu suportă tag-uri custom ca dimensiune. Dacă rulezi doar pe un singur cloud, folosește serviciul nativ. Dacă rulezi multi-cloud, adaugă un detector custom peste export FOCUS pentru consistență între conturi.

Cum funcționează AWS Cost Anomaly Detection?

AWS Cost Anomaly Detection folosește algoritmul Random Cut Forest (același care stă în spatele Amazon Kinesis Data Analytics anomaly detection) pentru a modela sezonalitatea cheltuielilor tale pe ultimele 60 de zile. Serviciul rulează de trei ori pe zi și analizează două tipuri de monitorizări: AWS services (un „cost monitor" per serviciu, de exemplu EC2, S3, RDS) și custom monitors (per LinkedAccount, per Cost Category sau per Tag). Fiecare monitor are un subscription care controlează pragul minim al anomaliei și frecvența notificărilor. Pentru detalii oficiale, vezi documentația AWS Cost Anomaly Detection.

Iată configurarea completă prin Terraform pe care o folosesc pentru un nou cont AWS. Notă importantă: pragul threshold_expression cere cel puțin o condiție „ABSOLUTE_VALUE" plus o valoare pentru „PERCENTAGE". Dacă lipsește vreo condiție primești eroare la apply (am pierdut o oră cu asta pe primul cont).

# Terraform provider AWS >= 5.40 pentru toate campurile threshold_expression

resource "aws_ce_anomaly_monitor" "production_services" {
  name              = "production-services-monitor"
  monitor_type      = "DIMENSIONAL"
  monitor_dimension = "SERVICE"
}

resource "aws_ce_anomaly_monitor" "production_by_team" {
  name         = "production-monitor-by-team"
  monitor_type = "CUSTOM"

  monitor_specification = jsonencode({
    Tags = {
      Key    = "team"
      Values = ["platform", "data", "ml"]
    }
  })
}

resource "aws_ce_anomaly_subscription" "slack_alerts" {
  name             = "critical-anomalies-slack"
  frequency        = "IMMEDIATE"
  monitor_arn_list = [
    aws_ce_anomaly_monitor.production_services.arn,
    aws_ce_anomaly_monitor.production_by_team.arn,
  ]

  subscriber {
    type    = "SNS"
    address = aws_sns_topic.finops_alerts.arn
  }

  # Alerteaza doar peste $200 impact absolut SI >20% deviatie
  threshold_expression {
    and {
      dimension {
        key           = "ANOMALY_TOTAL_IMPACT_ABSOLUTE"
        match_options = ["GREATER_THAN_OR_EQUAL"]
        values        = ["200"]
      }
    }
    and {
      dimension {
        key           = "ANOMALY_TOTAL_IMPACT_PERCENTAGE"
        match_options = ["GREATER_THAN_OR_EQUAL"]
        values        = ["20"]
      }
    }
  }
}

Din experiența mea, pragul optim pentru IMMEDIATE alerts este $200 absolut plus 20% procentual. Sub aceste valori primești prea multe alerte irelevante (retry-uri Lambda, transferuri mici cross-AZ). Pentru rapoartele săptămânale, coboară pragul la $50 și trimite un digest zilnic în loc de immediate. Vei prinde tiparele lente care altfel scapă.

Cum configurezi alerte de anomalie în Azure Cost Management?

Azure a introdus anomaly insights în aprilie 2022, iar în 2026 rulează pe un model WaveNet (aceeași familie ca text-to-speech Google DeepMind) care se antrenează pe 60 de zile de date istorice per subscription. Serviciul rulează zilnic și expune rezultatele în două locuri: în blade-ul Cost Analysis (secțiunea „Insights") și prin API-ul Consumption/anomalyResults. Alertele automate se configurează prin „Anomaly alerts" în Cost Management + Billing și pot trimite notificări prin Action Groups la e-mail, webhook, Logic Apps sau ITSM.

Iată configurarea prin Azure CLI pentru un alert de anomalie pe o subscription care trimite spre un webhook Slack. Notă: Azure limitează un alert per subscription per zi. Dacă primești două anomalii distincte în aceeași zi, doar prima va declanșa alerta.

# Necesita Azure CLI >= 2.60 si extension "costmanagement"
az extension add --name costmanagement --upgrade

SUBSCRIPTION_ID="00000000-0000-0000-0000-000000000000"
WEBHOOK_URL="https://hooks.slack.com/services/T00/B00/XXX"

az rest --method PUT \
  --uri "https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.CostManagement/scheduledActions/anomaly-slack?api-version=2023-11-01" \
  --body '{
    "kind": "InsightAlert",
    "properties": {
      "displayName": "Daily Anomaly Alert - Slack",
      "status": "Enabled",
      "notification": {
        "to": ["[email protected]"],
        "subject": "Anomalie de cost Azure detectata",
        "message": "Verificati portalul Cost Management pentru detalii"
      },
      "schedule": {
        "frequency": "Daily",
        "hourLocal": 9,
        "daysOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
        "startDate": "2026-08-10T00:00:00Z",
        "endDate": "2027-08-10T00:00:00Z"
      },
      "viewId": "/subscriptions/'$SUBSCRIPTION_ID'/providers/Microsoft.CostManagement/views/ms:DailyAnomalyByResourceGroup"
    }
  }'

Un truc pe care l-am învățat pe cont propriu: Azure clasifică anomaliile în trei buckets (High, Medium, Low), dar API-ul întoarce implicit doar Medium+. Pentru workload-uri critice (bază de date financiară, sistem de plăți), setează parametrul „severity=Low" pe API și filtrezi tu la nivel de webhook. Vei prinde creșteri de $30-50/zi care altfel scapă complet de sub radar. Pentru o listă completă de dimensiuni disponibile, vezi documentația Microsoft despre analiza cheltuielilor neașteptate.

Are Google Cloud detectare anomalii de cost?

Da. GCP Cost Anomaly Detection a intrat în GA (General Availability) în februarie 2026, după aproape doi ani în preview. Serviciul este integrat direct în consola Cloud Billing la secțiunea „Cost anomaly detection" și oferă acoperire pentru trei dimensiuni: Project, Service și SKU. Spre deosebire de AWS și Azure, GCP nu suportă (încă) tag-uri (labels) ca dimensiune pentru anomaly detection, ceea ce e o limitare majoră dacă folosești labels pentru cost allocation. Roadmap-ul oficial menționează suport pentru labels în Q4 2026.

Activarea este simplă prin gcloud CLI, iar notificările merg prin Pub/Sub, ceea ce face integrarea cu Cloud Functions sau sisteme externe mult mai flexibilă decât la competitori. Iată un exemplu complet care activează detectarea la nivel de billing account și trimite alertele într-un topic Pub/Sub consumat de o Cloud Function care postează în Slack:

# Necesita gcloud CLI >= 460.0.0
BILLING_ACCOUNT="012345-678901-ABCDEF"
PROJECT_ID="finops-monitoring-prod"
TOPIC_NAME="cost-anomaly-alerts"

# 1. Creeaza topicul Pub/Sub
gcloud pubsub topics create $TOPIC_NAME --project=$PROJECT_ID

# 2. Activeaza Cost Anomaly Detection pe billing account
gcloud billing accounts update $BILLING_ACCOUNT \
  --update-labels=cost_anomaly_detection=enabled

# 3. Creeaza un budget cu threshold rules care se comporta ca anomaly alert
gcloud billing budgets create \
  --billing-account=$BILLING_ACCOUNT \
  --display-name="Anomaly Detection - Production" \
  --budget-amount=10000USD \
  --threshold-rule=percent=1.20,basis=forecasted-spend \
  --threshold-rule=percent=1.50,basis=forecasted-spend \
  --notifications-rule-pubsub-topic="projects/$PROJECT_ID/topics/$TOPIC_NAME" \
  --filter-projects="projects/production-app,projects/production-data"

Combinație pe care o recomand: folosește Cost Anomaly Detection nativ pentru vederea de ansamblu pe billing account, apoi setează budgets cu forecast-based thresholds (110%, 120%, 150%) pentru fiecare proiect critic. Această combinație acoperă atât spike-urile bruște (prinse de anomaly detection), cât și derapajele graduale (prinse de forecast). Pentru contextul complet despre BigQuery și optimizarea data warehouse, consultă ghidul nostru despre optimizarea costurilor data warehouse.

Detector propriu peste FOCUS 1.2 cu Prophet și BigQuery

Serviciile native sunt un „safety net" excelent, dar au trei limitări în care intri repede când operezi multi-cloud. Unu: fiecare cloud folosește propria taxonomie, deci nu poți compara direct între ele. Doi: latența de 24-72 ore este inacceptabilă pentru workload-uri unde $10.000 se poate acumula într-o zi. Trei: nu poți antrena modele pe metrici business (cost per request, cost per customer). Soluția pe care am adoptat-o în ultimele proiecte este un detector custom care rulează peste export FOCUS 1.2 unificat. Vezi ghidul nostru complet despre specificația FOCUS 1.2 pentru multi-cloud FinOps pentru configurarea exportului.

Exemplul de mai jos folosește Prophet (biblioteca open-source de la Meta) pentru a antrena un model per (BillingAccountId, ServiceName) și a produce prediction intervals. Anomalia este definită ca EffectiveCost > yhat_upper pentru cel puțin o zi. Rulează pe Cloud Run, costă ~$3/lună pe portofolii sub $500k lunar, iar latența este sub 6 ore.

# requirements: prophet==1.1.5, google-cloud-bigquery==3.25, pandas==2.2
from google.cloud import bigquery
from prophet import Prophet
import pandas as pd
from datetime import datetime, timedelta

PROJECT_ID = "finops-analytics"
FOCUS_TABLE = "finops.focus_unified_daily"

def detect_anomalies():
    client = bigquery.Client(project=PROJECT_ID)

    # Pull 90 zile istoric pentru fiecare (BillingAccount, Service)
    query = f"""
        SELECT
            BillingAccountId,
            ServiceName,
            DATE(ChargePeriodStart) AS ds,
            SUM(EffectiveCost) AS y
        FROM `{FOCUS_TABLE}`
        WHERE ChargePeriodStart >= DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY)
          AND ChargeCategory = 'Usage'
        GROUP BY 1, 2, 3
        HAVING SUM(EffectiveCost) > 5  -- ignora serviciile marginale
    """
    df = client.query(query).to_dataframe()

    anomalies = []
    for (account, service), group in df.groupby(["BillingAccountId", "ServiceName"]):
        if len(group) < 30:
            continue  # nu suficient istoric

        ts = group[["ds", "y"]].sort_values("ds")

        model = Prophet(
            interval_width=0.99,          # 99% prediction interval
            changepoint_prior_scale=0.05, # penalizeaza schimbari bruste
            weekly_seasonality=True,
            daily_seasonality=False,
        )
        model.fit(ts)

        future = model.make_future_dataframe(periods=1, include_history=False)
        forecast = model.predict(future)

        # Verifica ziua de ieri (ultima cu date complete)
        yesterday = (datetime.utcnow().date() - timedelta(days=1))
        actual_row = ts[ts["ds"] == pd.Timestamp(yesterday)]
        if actual_row.empty:
            continue
        actual = actual_row["y"].values[0]
        upper = forecast["yhat_upper"].values[0]
        expected = forecast["yhat"].values[0]

        if actual > upper and (actual - expected) > 100:
            anomalies.append({
                "account": account,
                "service": service,
                "date": yesterday.isoformat(),
                "actual": round(actual, 2),
                "expected": round(expected, 2),
                "delta_pct": round((actual - expected) / expected * 100, 1),
            })
    return anomalies

if __name__ == "__main__":
    for a in detect_anomalies():
        print(f"ANOMALY {a['account']}/{a['service']}: "
              f"${a['actual']} vs expected ${a['expected']} "
              f"(+{a['delta_pct']}%)")

Beneficiul cel mai mare al detectorului custom nu este acuratețea (Prophet nu bate WaveNet-ul Azure), ci controlul complet asupra dimensiunilor: pot antrena modele per team, per environment, per cost center, orice există în datele FOCUS. Pentru echipele care rulează sub 20 workload-uri distincte, nativul e suficient. Peste 50 de workload-uri, custom devine obligatoriu ca să scapi de zgomot.

Integrări Slack, PagerDuty și triage automat

O alertă fără context este mai rea decât nicio alertă, pentru că echipa o va ignora în două săptămâni. Am pățit-o personal pe primul proiect FinOps unde am pornit alertele fără să investesc în conținutul mesajului. Din experiență, o alertă bună de anomalie trebuie să conțină minimum: (1) delta absolut și procentual, (2) top 3 resurse contribuitoare cu ID-uri clickable, (3) comparație cu media ultimelor 7 zile, (4) link direct spre dashboard-ul de investigare, (5) sugestie de acțiune inițială. Pentru echipe distribuite, sfatul meu e să separi canalele: #finops-anomalies-info pentru anomalii sub $500 impact, #finops-anomalies-critical pentru peste $500 sau spike >100%.

# Cloud Function Python care primeste Pub/Sub anomaly si posteaza structured Slack
import json, base64, os
import functions_framework
from slack_sdk.webhook import WebhookClient

CRITICAL_WEBHOOK = os.environ["SLACK_CRITICAL_WEBHOOK"]
INFO_WEBHOOK = os.environ["SLACK_INFO_WEBHOOK"]

@functions_framework.cloud_event
def handle_anomaly(cloud_event):
    payload = json.loads(base64.b64decode(cloud_event.data["message"]["data"]))

    impact = payload["totalImpactAbsolute"]
    is_critical = impact >= 500 or payload["deltaPercent"] >= 100

    webhook = WebhookClient(CRITICAL_WEBHOOK if is_critical else INFO_WEBHOOK)
    icon = ":rotating_light:" if is_critical else ":warning:"

    top_resources = "\n".join(
        f"* `{r['resourceId']}` ${r['cost']:.2f}"
        for r in payload["topContributors"][:3]
    )

    webhook.send(
        text=f"{icon} Anomalie {payload['service']} +${impact:.0f}",
        blocks=[
            {"type": "header",
             "text": {"type": "plain_text",
                      "text": f"{icon} Cost anomaly detectata"}},
            {"type": "section",
             "fields": [
                 {"type": "mrkdwn",
                  "text": f"*Serviciu:*\n{payload['service']}"},
                 {"type": "mrkdwn",
                  "text": f"*Impact:*\n${impact:.0f} (+{payload['deltaPercent']}%)"},
                 {"type": "mrkdwn",
                  "text": f"*Cont:*\n{payload['account']}"},
                 {"type": "mrkdwn",
                  "text": f"*Data:*\n{payload['date']}"},
             ]},
            {"type": "section",
             "text": {"type": "mrkdwn",
                      "text": f"*Top contributori:*\n{top_resources}"}},
            {"type": "actions",
             "elements": [
                 {"type": "button",
                  "text": {"type": "plain_text", "text": "Deschide dashboard"},
                  "url": payload["dashboardUrl"]},
                 {"type": "button",
                  "text": {"type": "plain_text", "text": "Snooze 24h"},
                  "value": payload["anomalyId"],
                  "action_id": "snooze_anomaly"},
             ]},
        ],
    )

Pentru PagerDuty, folosesc integrarea Events API v2 doar pentru anomaliile critice (>$1000 impact ȘI serviciu tagat „environment=prod"). Restul rămân în Slack pentru triage asincron. Escaladarea automată în PagerDuty pentru orice anomalie generează alert fatigue în două luni. Am văzut echipe care ajungeau la 15 pages/zi până când au introdus filtre.

Best practices, false pozitive și pitfalls

După șase luni de rulare a tuturor celor trei servicii în paralel plus un detector custom Prophet, iată lista scurtă de lecții pe care le-am plătit personal. Prima: nu activa detectorul într-o săptămână cu deploy major. Modelele au nevoie de 60 de zile istoric „normal" pentru a se antrena, iar dacă introduci o schimbare arhitecturală majoră (migrare la Kubernetes, activare CloudFront) în perioada de antrenament, modelul o va înțelege ca noua normalitate și va rata anomaliile viitoare. Așteaptă 2 săptămâni stabile, apoi activează.

A doua: filtrează întotdeauna „Refund" și „Credit" din datele de antrenament. FOCUS 1.2 le include în EffectiveCost cu semn negativ, iar Prophet ajustează prost când vede o zi cu -$2000 (credit RI). Filtrează ChargeCategory = 'Usage' AND EffectiveCost >= 0. A treia: gestionează separat serviciile cu pattern spiky by-design. Athena, Redshift Serverless, Lambda pot avea variații de 500% zi-la-zi legitime. Pentru acestea, ori le excluzi din anomaly detection, ori antrenezi cu weekly_seasonality dezactivată.

Rata falselor pozitive pe care am măsurat-o în producție (300+ alerte în 6 luni): AWS Cost Anomaly Detection ~22%, Azure Anomaly Insights ~28%, GCP Cost Anomaly Detection ~35%, custom Prophet cu tuning ~12%. Diferența majoră o face granularitatea. Un model per (account, service) prinde mult mai bine decât un model global. Pentru context suplimentar despre optimizarea per-serviciu, vezi ghidul nostru de right-sizing multi-cloud.

Ultimul pitfall și cel mai des întâlnit: nu confunda „anomaly detection" cu „cost governance". Detectorul îți spune ce e neobișnuit, nu ce e greșit. O anomalie de +$5000 pe RDS poate fi legitimă (echipa a activat Multi-AZ pentru compliance) sau fraudă (query rulat de un CI corupt). Triage-ul rămâne responsabilitatea unui om, cel puțin până când agenții autonomi FinOps ajung suficient de maturi să facă root-cause analysis fără intervenție.

Întrebări frecvente

Este AWS Cost Anomaly Detection gratuit?

Da, AWS Cost Anomaly Detection este complet gratuit indiferent de câți monitori sau subscriptions creezi. Singurul cost adiacent apare dacă folosești SNS pentru livrarea alertelor. SNS taxează $0.50 per milion notificări, ceea ce înseamnă practic zero pentru volumul tipic de alerte (câteva pe zi).

Cât de rapid detectează anomaliile serviciile native?

Latența medie de detectare este 24-48 ore pentru AWS, 36-72 ore pentru Azure și 24-36 ore pentru GCP. Motivul principal e că datele de facturare devin disponibile cu 12-24 ore delay, iar apoi scanarea rulează 1-3 ori pe zi. Pentru workload-uri unde $10.000 se poate acumula într-o zi, nativul nu este suficient. Construiește un detector custom peste export FOCUS.

Ce diferență există între bugete și detectare anomalii de cost?

Bugetele alertează la depășirea unui plafon absolut ($10.000/lună), fiind ideale pentru derapaje lente și controlul cheltuielilor planificate. Detectarea anomaliilor alertează la abateri de la comportamentul istoric al fiecărei dimensiuni (serviciu, cont, tag), fiind ideală pentru spike-uri bruște. Cele două se completează. Folosește-le împreună, nu ca alternative.

Câte alerte fals pozitive să te aștepți lunar?

Fără tuning, între 20-40% din alertele native sunt false pozitive. Cu tuning corect (praguri minime, filtrare servicii spiky, excluderea creditelor), poți coborî la 10-15%. Un detector custom cu Prophet și granularitate per (account, service) ajunge la ~12% în măsurătorile mele pe 6 luni.

Cum tratezi anomaliile cauzate de deploy-uri planificate?

Cea mai bună strategie este să implementezi un mecanism de snooze la nivel de alertă (buton Slack cu action_id) care suprimă alertele pentru o dimensiune specifică pentru 24-72 ore. Alternativ, poți publica evenimente „planned_change" într-un topic care este verificat de detectorul custom înainte de a trimite alerta. AWS și Azure nu oferă nativ această funcționalitate. Trebuie construită în stratul de notificare.