Meer informatie over factureringsmodellen voor Azure Files

De kosten van een implementatie van Azure Files worden bepaald door vier belangrijke factoren:

• Factureringsmodel: Azure Files ondersteunt drie verschillende factureringsmodellen die de kostenstructuur van een Azure Files-implementatie vormgeven:

  • Ingericht v2: Een ingericht factureringsmodel waarin u opslag, IOPS en doorvoer afzonderlijk kunt inrichten. U betaalt op basis van wat u inricht, ongeacht hoeveel u daadwerkelijk gebruikt. We raden het ingerichte v2-model aan voor alle nieuwe Azure Files-implementaties.
  • Ingericht v1: Een ingericht factureringsmodel waarin u de hoeveelheid opslagruimte inricht die u nodig hebt, terwijl IOPS en doorvoer worden bepaald door de hoeveelheid opslagruimte die u inricht. We raden u aan het ingerichte v2-model te gebruiken, tenzij u een specifieke reden hebt om het ingerichte v1-model te gebruiken.
  • Betalen per gebruik: een factureringsmodel op basis van gebruik waarin de kosten worden bepaald op basis van hoeveel u de bestandsshare gebruikt, in de vorm van gebruikte opslag, transactie en kosten voor gegevensoverdracht. U wordt aangeraden het ingerichte v2-model te gebruiken, tenzij u een specifieke reden hebt om het model voor betalen per gebruik te gebruiken.

• Medialaag: Azure Files ondersteunt twee verschillende medialagen opslag, SSD en HDD. Hiermee kunt u uw bestandsshares aanpassen aan de prestatie- en prijsvereisten van uw scenario.

  • SSD (premium): bestandsshares die worden gehost op SSD's (Solid State Drives) bieden consistente hoge prestaties en lage latentie, met latentie van één milliseconden voor de meeste IO-bewerkingen.
  • HDD (standaard): bestandsshares die worden gehost op harde schijven (HDD's) bieden rendabele opslag voor algemeen gebruik.

• Redundantie: Azure Files ondersteunt vier verschillende redundantieopties waarmee u kunt bepalen hoeveel kopieën van uw gegevens zijn opgeslagen en waar de gekopieerde kopieën in de infrastructuur van Azure worden geplaatst. Tolerantere opties bieden meer duurzaamheid en beschikbaarheid, maar tegen hogere kosten:

  • Lokaal: Lokaal redundante opslag (LRS) bewaart drie kopieën van uw gegevens in één datacenter in één regio.
  • Zone: Zone-redundante opslag (ZRS) slaat drie kopieën van uw gegevens op in onafhankelijke datacenters (beschikbaarheidszones) binnen een regio.
  • Geo: Geografisch redundante opslag (GRS) slaat drie kopieën van de gegevens op in de primaire regio en repliceert asynchroon naar een gekoppelde regio, voor in totaal zes exemplaren. Alleen beschikbaar op HDD-opslag.
  • GeoZone: GeoZone-redundante opslag (GZRS) combineert zoneredundantie in de primaire regio met asynchrone replicatie naar een secundaire regio. Alleen beschikbaar op HDD-opslag.

• Resourcemodel: Azure Files ondersteunt twee verschillende typen resources, beheerbare items die u maakt en configureert binnen uw Azure-abonnementen en -resourcegroepen. Elk resourcetype ondersteunt enigszins verschillende opties voor het factureringsmodel, wat op zijn beurt van invloed is op zowel kosten- als kostenstructuur:

  • Opslagaccounts vertegenwoordigen een gedeelde opslaggroep, IOPS en doorvoer waarin u klassieke bestandsshares of andere opslagbronnen kunt implementeren, afhankelijk van het type opslagaccount. Opslagaccounts ondersteunen alle factureringsmodellen, medialagen en redundantieopties. Alle opslagresources die in een opslagaccount worden geïmplementeerd, delen de limieten die van toepassing zijn op dat opslagaccount. Klassieke bestandsshares ondersteunen zowel de SMB- als NFS-protocollen, hoewel NFS alleen wordt ondersteund op SSD-opslag. Opslagaccounts worden aangeboden door de Microsoft.Storage resourceprovider.

  • Bestandsshares (preview) zijn een nieuw resourcetype van het hoogste niveau dat de implementatie van Azure Files vereenvoudigt door de noodzaak van een opslagaccount te elimineren. Bestandsshares ondersteunen alleen het aanbevolen ingerichte v2-model en ondersteunen alleen de SSD-medialaag met het NFS-bestandssysteemprotocol. Bestandsshares worden aangeboden door de resource provider Microsoft.FileShares.

Voor Azure Files prijsinformatie, zie de Azure Files prijspagina.

Opslageenheden

Azure Files maakt gebruik van de maateenheden base-2 om de opslagcapaciteit te vertegenwoordigen: KiB, MiB, GiB en TiB.

De maateenheidseenheden met grondtal 2 worden vaak gebruikt door de meeste besturingssystemen en hulpprogramma's om opslaghoeveelheden te meten. Ze worden echter vaak verkeerd gelabeld als de basis-10-eenheden, waarmee u mogelijk vertrouwder bent: KB, MB, GB en TB. De veelvoorkomende reden waarom besturingssystemen zoals Windows de opslageenheden verkeerd labelen, is omdat veel besturingssystemen deze acroniemen begonnen te gebruiken voordat ze werden gestandaardiseerd door de International Electrotechnical Commission (IEC), International Bureau of Weights and Measures (BIPM) en US National Institute of Standards and Technology (NIST).

In de volgende tabel ziet u hoe algemene besturingssystemen opslag meten en labelen:

Neem contact op met de leverancier van uw besturingssysteem als uw besturingssysteem niet wordt vermeld.

Controlelijst voor totale eigendomskosten voor bestandsshares

Als u van on-premises naar Azure Files migreert of Azure Files vergelijkt met andere cloudopslag, moet u rekening houden met de volgende factoren om een eerlijke en gelijkwaardige vergelijking te garanderen:

• Hoe betaalt u voor opslag, IOPS en bandbreedte? De meeste cloudoplossingen hebben modellen die zijn afgestemd op de principes van ingerichte opslag, zoals prijsdeterminisme en eenvoud, of opslag met betalen per gebruik, die kosten kan optimaliseren door alleen kosten in rekening te brengen voor wat u daadwerkelijk gebruikt. Voorzieningsfactureringsmodellen kunnen verschillen op basis van de minimale voorzieningsdeelsgrootte, de provisioneringseenheid en de mogelijkheid om de voorziening te vergroten en te verkleinen.

• Zijn er methoden om de opslagkosten te optimaliseren? U kunt Azure Files-reserveringen gebruiken om maximaal 36% korting op opslag te krijgen. Andere oplossingen kunnen gebruikmaken van strategieën zoals ontdubbeling of compressie om de opslagefficiëntie optioneel te optimaliseren. Deze strategieën voor opslagoptimalisatie hebben echter vaak niet-monetaire kosten, zoals het verminderen van de prestaties. Azure Files-reserveringen hebben geen neveneffecten op prestaties.

• Hoe bereikt u opslagtolerantie en redundantie? Met Azure Files worden tolerantie en redundantie van opslag opgenomen in het productaanbod. Alle lagen en redundantieniveaus zorgen ervoor dat gegevens maximaal beschikbaar zijn en ten minste drie kopieën van uw gegevens toegankelijk zijn. Overweeg bij het overwegen van andere opties voor bestandsopslag of opslagtolerantie en redundantie is ingebouwd, of iets dat u zelf moet samenstellen.

• Wat moet u beheren? Azure Files is een volledig beheerde oplossing. Andere oplossingen vereisen mogelijk besturingssysteemupdates of het beheren van virtuele resources, zoals VM's, schijven en netwerk-IP-adressen.

• Wat zijn de kosten van toegevoegde waardeproducten? Azure Files biedt ondersteuning voor integraties met meerdere eerst- en externe services met toegevoegde waarde. Services met toegevoegde waarde, zoals Azure Backup, Azure File Sync en Microsoft Defender for Storage, bieden back-ups, replicatie en caching en beveiligingsfunctionaliteit voor Azure Files. Oplossingen met toegevoegde waarde, on-premises of in de cloud, hebben hun eigen licentie- en productkosten, maar worden vaak beschouwd als onderdeel van de totale eigendomskosten voor bestandsopslag.

Geprovisioneerd v2-model

Het ingerichte v2-model voor Azure Files combineert voorspelbaarheid van de totale eigendomskosten met flexibiliteit, waardoor u een bestandsshare kunt creëren die aan uw exacte opslag- en prestatievereisten voldoet. Wanneer u een nieuwe ingerichte v2-bestandsshare maakt, geeft u op hoeveel opslagruimte, IOPS en doorvoer uw bestandsshare nodig heeft. Het aantal van elke hoeveelheid die u bestelt, bepaalt uw totale factuur.

De hoeveelheid opslag, IOPS en doorvoer die u inricht, zijn de gegarandeerde limieten voor het gebruik van uw bestandsshare. Als u bijvoorbeeld een 2 TiB-share inricht en 2 TiB aan gegevens uploadt naar uw share, is uw share vol. U kunt niet meer gegevens toevoegen, tenzij u de grootte van uw share vergroot of een deel van de gegevens verwijdert. IOPS-bursting op basis van tegoed zorgt voor extra flexibiliteit in gebruik, op een best-effort basis, zolang er tegoeden zijn.

De hoeveelheid opslag, IOPS en doorvoer die u inricht, kan dynamisch omhoog of omlaag worden geschaald naarmate uw behoeften veranderen. U kunt echter alleen een ingerichte hoeveelheid verlagen nadat 24 uur is verstreken sinds de laatste toename van de hoeveelheid. Wijzigingen in opslag, IOPS en doorvoer worden binnen enkele minuten na een inrichtingswijziging doorgevoerd.

Wanneer u een nieuwe bestandsshare maakt met behulp van het ingerichte v2-model, wordt standaard een aanbeveling geboden voor het aantal IOPS en hoeveel doorvoer u nodig hebt. Dit wordt berekend op basis van de hoeveelheid ingerichte opslag die u opgeeft. Deze aanbevelingen zijn gebaseerd op typisch klantgebruik voor die hoeveelheid ingerichte opslag voor de medialaag die u kiest. Het kan echter zijn dat uw workload meer of minder IOPS en doorvoer vereist dan de 'typische bestandsshare'. In dit geval kunt u desgewenst meer of minder IOPS en doorvoer inrichten, afhankelijk van de vereisten voor uw afzonderlijke bestandsshares.

Voorziening van v2 beschikbaarheid

Het ingerichte v2-model is beschikbaar voor de volgende combinaties van medialaag, redundantie en protocol voor het delen van bestanden:

Medialeigang	Redundantie	Protocol voor het delen van bestanden	Klassieke bestandsdeling (Microsoft.Storage)	Gedeelde bestanden (Microsoft.FileShares)
Solid State Drive (SSD)	Local	KMO
Solid State Drive (SSD)	Zone	KMO
Solid State Drive (SSD)	Local	NFS (Netwerkbestandssysteem)
Solid State Drive (SSD)	Zone	NFS (Netwerkbestandssysteem)
HDD	Local	KMO
HDD	Zone	KMO
HDD	Geo	KMO
HDD	GeoZone	KMO
HDD	Local	NFS (Netwerkbestandssysteem)
HDD	Zone	NFS (Netwerkbestandssysteem)
HDD	Geo	NFS (Netwerkbestandssysteem)
HDD	GeoZone	NFS (Netwerkbestandssysteem)

Momenteel is het ingerichte v2-model algemeen beschikbaar in een beperkte subset van regio's:

• Alle openbare Azure-cloudregio's.
• Alle Azure US Government-cloudregio's.

Details van de v2-voorziening

Wanneer u een ingerichte v2-bestandsshare maakt, geeft u de ingerichte capaciteit voor de bestandsshare op in termen van opslag, IOPS en doorvoer. Bestandsshares zijn beperkt op basis van de volgende kenmerken.

Standaard raden we IOPS en doorvoerinrichting aan op basis van de ingerichte opslag die u opgeeft. Deze aanbevelingsformules zijn gebaseerd op typisch klantgebruik voor die hoeveelheid ingerichte opslag voor die medialaag in Azure Files:

Afhankelijk van uw vereisten voor afzonderlijke bestandsshares, is het mogelijk dat u meer of minder IOPS of doorvoer nodig hebt dan onze aanbevelingen. U kunt deze aanbevelingen desgewenst overschrijven met uw eigen waarden.

Geconfigureerde v2-bursting

IOPS-bursting op basis van krediet biedt extra flexibiliteit bij IOPS-gebruik. Deze flexibiliteit wordt het beste gebruikt als buffer tegen onverwachte IO-pieken. Voor vastgestelde I/O-patronen raden we u aan om te voorzien in I/O-pieken.

Burst IOPS-tegoed wordt verzameld wanneer het verkeer voor uw bestandsdeling lager is dan de ingerichte IOPS (basislijn). Wanneer het IOPS-gebruik van een bestandsshare groter is dan de ingerichte IOPS en er beschikbaar IOPS-tegoeden voor bursts beschikbaar zijn, kan de bestandsshare maximaal de maximaal toegestane burst IOPS-limiet bereiken. Bestandsshares kunnen blijven pieken zolang er nog tegoeden over zijn, gebaseerd op het aantal opgebouwde piek-tegoeden. Elke IO buiten de voorziene IOPS verbruikt één tegoed. Zodra alle tegoeden zijn verbruikt, keert de share terug naar de ingerichte IOPS. IOPS voor de bestandsshare hoeven niets speciaals te doen om bursting te gebruiken. Bursting werkt op basis van best effort.

Deelkredieten hebben drie staten:

• Opbouwen wanneer de bestandsshare minder dan de ingerichte IOPS gebruikt.
• Aflopend, wanneer de bestandsshare meer gebruikt dan de ingerichte IOPS en in de burst-modus.
• Constant, wanneer de bestandsdeling precies de toegewezen IOPS gebruikt en er geen tegoeden zijn opgebouwd of verbruikt.

Een nieuwe bestandsshare begint met het volledige aantal tegoeden in de zogenaamde "burst-bucket". Burst-tegoeden worden niet opgebouwd als de share-IOPS onder de geprovisioneerde limiet vallen vanwege throttling door de server. De volgende formules worden gebruikt om de burst IOPS-limiet en het aantal tegoeden dat mogelijk is voor een bestandsshare te bepalen:

In de volgende tabel ziet u enkele voorbeelden van deze formules voor verschillende ingerichte IOPS-bedragen:

Ingerichte v2-resourcemodellen

Het ingerichte v2-factureringsmodel is beschikbaar voor beide resourcetypen die worden gebruikt door Azure Files. U kunt een voorgeconfigureerde v2-bestandsshare maken binnen een opslagaccount als een klassieke bestandsshare (Microsoft.Storage) of rechtstreeks als bestandsshare op het hoogste niveau (Microsoft.FileShares).

Ingerichte v2 klassieke bestandsshares (Microsoft.Storage)

Als u een klassieke bestandsshare wilt maken met het ingerichte v2-model, moet uw opslagaccount een van de volgende combinaties van instellingen gebruiken:

Zie Een klassieke bestandsshare maken voor meer informatie over het maken van een klassieke bestandsshare met behulp van het ingerichte v2-model.

Klassieke bestandsdelingen die in dezelfde opslagaccount zijn gemaakt, delen de limieten voor opslag, IOPS en doorvoer van dat opslagaccount.

Als u azure Files correct wilt implementeren met het ingerichte v2-factureringsmodel op klassieke bestandsshares, moet u rekening houden met de volgende dimensies van capaciteitsplanning:

• Hoeveel ingerichte opslag, IOPS en doorvoer hebt u nodig voor elke klassieke bestandsshare? Hoe veranderen deze vereisten na verloop van tijd?
  Omdat opslagaccounts gedeelde limieten hebben wanneer u klassieke bestandsshares toewijst aan opslagaccounts, moet u rekening houden met de behoeften van elke klassieke bestandsshare, zowel nu als na verloop van tijd. De inrichtingslogica voor het ingerichte v2-model voorkomt dat u meer opslag, IOPS of doorvoer inricht dan het opslagaccount ondersteunt. Als er voldoende klassieke bestandsshares in één opslagaccount worden geplaatst, zodat een van deze dimensies maximaal is, kunnen bestaande klassieke bestandsshares niet groeien zonder eerst naar een ander opslagaccount te migreren. Om dit risico te verminderen, moet u voldoende ruimte plannen in elk opslagaccount, zodat u de koppelingen van klassieke bestandsshares aan opslagaccounts ten minste 3 tot 5 jaar kunt behouden.

• Hebt u speciale vereisten met betrekking tot het bijhouden van de factuur voor elke klassieke bestandsdeling voor afzonderlijke projecten, afdelingen of klanten?
  In Azure is het kleinst mogelijke niveau waarvoor u facturering kunt bekijken de resource, dat wil zeggen dat als u twee klassieke bestandsdelingen in hetzelfde opslagaccount plaatst, u hun kosten niet gemakkelijk kunt terugleiden naar afzonderlijke projecten, afdelingen of klanten. U kunt dit oplossen door klassieke bestandsshares te groeperen in opslagaccounts op basis van hoe ze vanuit factureringsperspectief moeten worden bijgehouden.

• Hoeveel opslagaccounts zijn er beschikbaar in uw abonnement voor uw doelregio?
  Een extra complicerende factor is het aantal opslagaccounts dat u kunt hebben per regio per abonnement. Zie Microsoft.Storage limieten voor besturingsvlak voor meer informatie. Afhankelijk van het aantal opslagaccounts dat u nodig hebt, moet u mogelijk extra abonnementen gebruiken om extra opslagaccounts te bereiken.

Geconfigureerde v2-bestandsshares (Microsoft.FileShares)

Het maken van bestandsshares met behulp van het beheermodel maakt het Microsoft.FileShares implementeren van Azure Files aanzienlijk eenvoudiger:

• U hoeft niet na te denken over de huidige en toekomstige behoeften van elke bestandsshare om te bepalen waar die bestandsshare moet worden geïmplementeerd.
  De inrichting van elke bestandsshare is onafhankelijk van de inrichting van elke andere bestandsshare. De enige overweging over de groei van de bestandsdeling is de limieten van de bestandsdeling, die worden beschreven in de details van de voorzieningen van versie 2.

• De factuur voor elke bestandsshare wordt onafhankelijk bijgehouden.
  Omdat bestandsshares resources op het hoogste niveau zijn, kunt u de factuur voor elke bestandsshare onafhankelijk van elke andere bestandsshare bijhouden. U kunt tags ook gebruiken om de resources eenvoudig te groeperen om de kosten voor projecten, afdelingen of klanten bij te houden.

• Hoewel bestandsshares nog steeds een limiet per abonnement per regio hebben, is de limiet van bestandsshares veel hoger dan de limiet van opslagaccounts.
  Zie limieten voor besturingsvlak voor meer informatieMicrosoft.FileShares.

Geconfigureerde v2-momentopnamen

Azure Files ondersteunt momentopnamen, die vergelijkbaar zijn met volumeschaduwkopieën (VSS) op Windows File Server. Voor meer informatie over momentopnamen van shares, zie Overzicht van momentopnamen voor Azure Files.

Momentopnamen verschillen altijd van de liveshare en van elkaar. Als in het ingerichte v2-factureringsmodel de totale differentiële grootte van alle momentopnamen binnen de overtollige ingerichte opslagruimte van de bestandsshare past, zijn er geen extra kosten verbonden aan de opslag van momentopnamen. Als de grootte van de live share-gegevens plus de differentiële momentopnamegegevens groter is dan de toegewezen opslag van de share, wordt de overtollige gebruikte capaciteit van de momentopnamen gefactureerd op basis van de Overflow Snapshot Usage meter. De formule voor het bepalen van de hoeveelheid overloop is: MAX((LiveShareUsedGiB + SnapshotDifferentialUsedGiB) - ProvisionedStorageGiB, 0)

Sommige services met toegevoegde waarde voor Azure Files maken gebruik van momentopnamen als onderdeel van hun waardepropositie. Zie services met toegevoegde waarde voor Azure Files voor meer informatie.

"Geconfigureerd v2 soft delete"

Verwijderde bestandsshares in opslagaccounts waarvoor voorlopig verwijderen is ingeschakeld, worden gefactureerd op basis van de gebruikte opslagcapaciteit van de verwijderde share voor de gedefinieerde bewaarperiode. Om ervoor te zorgen dat een verwijderde bestandsshare altijd kan worden hersteld, worden de ingerichte opslag, IOPS en doorvoer van de share geteld tegen de limieten van het opslagaccount totdat de bestandsshare is opgeschoond. Ze worden echter niet gefactureerd. Zie Voorlopig verwijderen inschakelen voor Azure-bestandsshares voor meer informatie over voorlopig verwijderen.

Geconfigureerde v2-factureringsmeters

Bestandsshares die zijn toegewezen met het v2-factureringsmodel, worden gefactureerd aan de hand van de volgende kostenmeters:

• Geconfigureerde opslag: de hoeveelheid opslag die is geconfigureerd in GiB.
• Ingerichte IOPS: de hoeveelheid IOPS (IO/sec) die is ingericht.
• Ingerichte doorvoer MiBPS: de hoeveelheid doorvoer die is ingericht in MiB per seconde.
• Overloopmomentopnamegebruik: elke hoeveelheid differentiële momentopnamegebruik in GiB die niet binnen de ingerichte opslagcapaciteit past. Zie geprovisioneerde v2-momentopnamen voor meer informatie.
• Zacht verwijderd gebruik: gebruikte opslagcapaciteit in GiB voor zacht verwijderde bestandsdeling. Zie voorwaarde v2 soft-delete voor meer informatie.

Verbruikseenheden op basis van de ingerichte v2-factureringsmeters worden elk uur verzonden. Voor een share met 1.024 GiB ingericht, zou je bijvoorbeeld het volgende moeten zien:

• 1.024 eenheden tegen de geprovisioneerde opslag meter voor een individueel uur.
• 24,576 eenheden tegenover de ingerichte opslagmeter, indien geaggregeerd voor een dag.
• Een variabel aantal eenheden indien geaggregeerd voor een maand, afhankelijk van het aantal dagen in de maand:
  • 28-daagse maand (normaal februari): 688.128 eenheden ten opzichte van de geconfigureerde opslagmeter.
  • Maand van 29 dagen (schrikkeljaar februari): 712.704 eenheden ten opzichte van de geprovisioneerde opslagmeter.
  • Maand van 30 dagen: 737.280 eenheden tegen de Provisioned Storage-meter.
  • Maand van 31 dagen: 761.856 eenheden tegen de geprovisioneerde opslagmeter.

Ingeplaatste v2-migraties

Het proces voor het migreren van uw SMB Azure-bestandsshares van een betalen per gebruik-model naar het ingerichte v2-factureringsmodel verschilt, afhankelijk van of u Azure File Sync gebruikt.

• Als u Azure Files zonder Azure File Sync gebruikt, raadpleegt u bestanden migreren van de ene SMB Azure-bestandsshare naar de andere.
• Indien u Azure File Sync gebruikt, raadpleeg Bestanden migreren van de ene Azure-bestandsshare naar de andere.

Geconfigureerd v1 model

De ingerichte v1-methode biedt opslag, IOPS en doorvoer in een vaste verhouding tot elkaar, vergelijkbaar met de manier waarop opslag wordt aangeschaft in een on-premises opslagoplossing. Wanneer u een nieuwe ingerichte v1 klassieke bestandsshare maakt, geeft u op hoeveel opslagruimte uw share nodig heeft en worden de IOPS- en doorvoerwaarden berekend. Het ingerichte v1-model voor Azure Files is alleen beschikbaar voor de SSD-medialaag.

De hoeveelheid opslagruimte die u inricht, bepaalt de gegarandeerde opslag-, IOPS- en doorvoerlimieten van het gebruik van uw klassieke bestandsshare. Als u bijvoorbeeld een 2 TiB-share inricht en 2 TiB aan gegevens uploadt naar uw klassieke bestandsshare, is deze vol. U kunt niet meer gegevens toevoegen, tenzij u de grootte van de klassieke bestandsshare vergroot of een deel van de gegevens verwijdert. IOPS-bursting op basis van tegoed zorgt voor extra flexibiliteit in gebruik, op een best-effort basis, zolang er tegoeden zijn.

In tegenstelling tot het aanschaffen van opslag op locatie, kunnen klassieke v1-bestandsshares dynamisch omhoog of omlaag worden geschaald naar behoefte. U kunt echter alleen de ingerichte opslag verminderen nadat 24 uur is verstreken sinds de laatste toename van de opslag. Wijzigingen in opslag, IOPS en doorvoer worden binnen enkele minuten na een inrichtingswijziging doorgevoerd.

Het is mogelijk om de grootte van uw geconfigureerde opslag kleiner te maken dan het aantal gebruikte Gibibytes. Als u dit wel doet, verliest u geen gegevens, maar wordt u nog steeds gefactureerd voor de gebruikte grootte. U ontvangt de prestaties van de ingerichte share, niet de gebruikte grootte.

Geconfigureerde v1-beschikbaarheid

Het ingerichte v1-model is beschikbaar voor de volgende combinaties van medialaag, redundantie en protocol voor het delen van bestanden:

Medialeigang	Redundantie	Protocol voor het delen van bestanden	Klassieke bestandsdeling (Microsoft.Storage)	Gedeelde bestanden (Microsoft.FileShares)
Solid State Drive (SSD)	Local	KMO
Solid State Drive (SSD)	Zone	KMO
Solid State Drive (SSD)	Local	NFS (Netwerkbestandssysteem)
Solid State Drive (SSD)	Zone	NFS (Netwerkbestandssysteem)
HDD	Local	KMO
HDD	Zone	KMO
HDD	Geo	KMO
HDD	GeoZone	KMO
HDD	Local	NFS (Netwerkbestandssysteem)
HDD	Zone	NFS (Netwerkbestandssysteem)
HDD	Geo	NFS (Netwerkbestandssysteem)
HDD	GeoZone	NFS (Netwerkbestandssysteem)

Klassieke SSD-bestandsshares met behulp van het ingerichte v1-model zijn algemeen beschikbaar in de meeste Azure-regio's. Zie Azure-producten per regio voor meer informatie.

Details van v1-voorziening

Wanneer u een ingerichte v1 klassieke bestandsshare maakt, geeft u op hoeveel opslagruimte uw share nodig heeft. Elke GiB die u configureert, geeft u recht op meer IOPS en doorvoer in een vaste verhouding. Ingerichte v1 klassieke bestandsdelingen zijn beperkt op basis van de volgende kenmerken:

De volgende formules bepalen de hoeveelheid IOPS en doorvoer die voor de share is ingericht:

Afhankelijk van uw individuele vereiste voor de klassieke bestandsshare, is het mogelijk dat u meer IOPS of doorvoer nodig hebt dan onze inrichtingsformules bieden. In dit geval moet u meer opslagruimte inrichten om de vereiste IOPS of doorvoer op te halen.

Ingerichte v1-burstcapaciteit

Het ingerichte v1-model ondersteunt twee typen bursting: op tegoed gebaseerde bursting, die gratis is opgenomen als onderdeel van de inrichting en betaalde bursting. Dit is een geavanceerde functie die u optioneel kunt inschakelen om facturering op basis van gebruik te ondersteunen wanneer de IOPS en doorvoer het ingerichte bedrag overschrijden.

Geconfigureerd v1-bursting op kredietbasis

IOPS-bursting op basis van krediet biedt extra flexibiliteit bij IOPS-gebruik. Deze flexibiliteit wordt het beste gebruikt als buffer tegen onverwachte IO-pieken. Voor vastgestelde I/O-patronen raden we u aan om te voorzien in I/O-pieken.

Burst IOPS-tegoed wordt verzameld wanneer het verkeer voor uw klassieke file share lager is dan de geprovisioneerde IOPS (basislijn). Wanneer het IOPS-gebruik van een klassieke bestandsshare groter is dan de ingerichte IOPS en er beschikbare burst-IOPS-tegoeden beschikbaar zijn, kan de klassieke bestandsshare maximaal de maximaal toegestane burst IOPS-limiet bereiken. Klassieke bestandsshares kunnen blijven bursten zolang er nog tegoeden zijn, op basis van het aantal opgebouwde burst-tegoeden. Elke IO buiten de voorziene IOPS verbruikt één tegoed. Zodra alle tegoeden zijn verbruikt, keert de klassieke bestandsshare terug naar de ingerichte IOPS. IOPS voor de klassieke bestandsshare hoeft niets speciaals te doen om bursting te gebruiken. Bursting werkt op basis van best effort.

Deelkredieten hebben drie staten:

• Oplopend, wanneer de klassieke bestandsshare minder gebruikmaakt dan de ingerichte IOPS.
• Aflopend, wanneer de klassieke bestandsshare meer gebruikt dan de ingerichte IOPS en in de bursting-modus.
• Constant, wanneer de klassieke bestandsshare exact gebruikmaakt van de ingerichte IOPS en er geen tegoed is opgebouwd of gebruikt.

Een nieuwe klassieke bestandsshare begint met het volledige aantal tegoeden in de burst-bucket. Burst-tegoeden worden niet opgebouwd als de share-IOPS onder de geprovisioneerde limiet vallen vanwege throttling door de server. De volgende formules worden gebruikt om de burst IOPS-limiet en het aantal tegoeden dat mogelijk is voor een klassieke bestandsshare te bepalen:

In de volgende tabel ziet u enkele voorbeelden van deze formules voor de ingerichte grootten:

Betaalde v1 capaciteitsuitbreiding ingericht

Betaalde bursting is een geavanceerde functie van het voorgeconfigureerde v1-model, ontworpen om klanten te ondersteunen die nooit willen worden vertraagd. Betaalde burst-facturering voegt extra gebruiksfacturering toe voor IOPS of doorvoer boven de toegewezen opslag. Dit verschilt van bursting op basis van tegoed, dat gratis is opgenomen als onderdeel van geprovisioneerde opslag. Hoewel betaalde bursting krachtige flexibiliteit kan bieden voor het inrichten van uw klassieke bestandsshare, kan dit ook leiden tot onverwachte facturering als deze onjuist wordt gebruikt.

Net als bij bursting op basis van tegoed is betaalde bursting geen vervanging voor het inrichten van de juiste hoeveelheid IOPS en doorvoer. In plaats daarvan biedt het verdere bescherming tegen beperking als u onverwachte vraag krijgt. Als u een consistent niveau van IOPS- of doorvoergebruik hebt, is het goedkoper om voldoende IOPS en doorvoer (via opslagvoorziening) toe te wijzen om aan de vraag te voldoen dan afhankelijk te zijn van betaalde bursting.

Betaalde bursting is standaard uitgeschakeld, maar u kunt deze inschakelen door de instructies te volgen om de kosten- en prestatiekenmerken van een ingerichte v1 klassieke bestandsshare te wijzigen (alleen PowerShell en CLI). Als betaalde bursting is ingeschakeld, raden we u aan om IOPS en doorvoergebruik zorgvuldig te controleren met behulp van de volgende metrische gegevens die beschikbaar zijn via Azure Monitor:

• Geprovisioneerde IOPS voor bestandsdeling
• MiB/s voor geconfigureerde bandbreedte van bestandsdeling (doorvoer)
• Transacties per max. IOPS
• Bandbreedte per maximaal MiB/s (doorvoer)
• Burst-tegoed voor IOPS (bursting op basis van tegoed)
• Betaalde Bursting IOS (IOs)
• Betaalde piekbandbreedte

Voorziene v1-resourcemodellen

U kunt een aangemaakte v1-bestandsshare alleen maken als een klassieke bestandsshare binnen een opslagaccount (Microsoft.Storage).

Ingerichte v1 klassiek bestandsdeling (Microsoft.Storage)

Als u een klassieke bestandsshare wilt maken met het ingerichte v1-model, moet uw opslagaccount een van de volgende combinaties van instellingen gebruiken:

Zie Een klassieke bestandsshare maken voor meer informatie over het maken van een klassieke bestandsshare met behulp van het ingerichte v1-model.

Klassieke bestandsdelingen die in dezelfde opslagaccount zijn gemaakt, delen de limieten voor opslag, IOPS en doorvoer van dat opslagaccount.

Als u azure Files correct wilt implementeren met het ingerichte v1-factureringsmodel op klassieke bestandsshares, moet u rekening houden met de volgende dimensies van capaciteitsplanning:

• Hoeveel ingerichte opslag, IOPS en doorvoer hebt u nodig voor elke klassieke bestandsshare? Hoe veranderen deze vereisten na verloop van tijd?
  Vanwege de beperkingen van gedeelde opslagaccountlimieten, moet u bij het toewijzen van klassieke bestandsshares aan opslagaccounts rekening houden met de behoeften van elke klassieke bestandsshare, zowel nu als in de loop van de tijd. De inrichtingslogica voor het ingerichte v1-model voorkomt dat u meer opslag inricht dan het opslagaccount ondersteunt. Hoewel u meer IOPS en doorvoer mag inrichten dan het opslagaccount biedt, kunt u niet meer gebruiken dan de limieten van het opslagaccount voor IOPS en doorvoer. Om onverwachte beperking te voorkomen, moet u niet meer IOPS of doorvoer toewijzen dan het opslagaccount ondersteunt.

  Bovendien kan het plaatsen van te veel klassieke bestandsshares in een opslagaccount toekomstige groei beperken. Zodra een opslagaccount vol is, kunt u bestaande klassieke bestandsshares niet uitbreiden zonder eerst een aantal naar een ander opslagaccount te migreren. Om dit risico te beperken, moet u voldoende marge inplannen in uw opslagaccounts zodat u de toewijzingen van klassieke bestandschijven aan opslagaccounts gedurende ten minste 3 tot 5 jaar kunt handhaven.

• Hebt u speciale vereisten met betrekking tot het bijhouden van de factuur voor elke klassieke bestandsdeling voor afzonderlijke projecten, afdelingen of klanten?
  In Azure is het kleinst mogelijke niveau waarvoor u facturering kunt bekijken de resource, dat wil zeggen dat als u twee klassieke bestandsdelingen in hetzelfde opslagaccount plaatst, u hun kosten niet gemakkelijk kunt terugleiden naar afzonderlijke projecten, afdelingen of klanten. U kunt dit oplossen door klassieke bestandsshares te groeperen in opslagaccounts op basis van hoe ze vanuit factureringsperspectief moeten worden bijgehouden.

• Hoeveel opslagaccounts zijn er beschikbaar in uw abonnement voor uw doelregio?
  Een extra complicerende factor is het aantal opslagaccounts dat u kunt hebben per regio per abonnement. Zie Microsoft.Storage limieten voor besturingsvlak voor meer informatie. Afhankelijk van het aantal opslagaccounts dat u nodig hebt, moet u mogelijk extra abonnementen gebruiken om extra opslagaccounts te bereiken.

Voorzien van v1-momentopnamen

Azure Files ondersteunt momentopnamen, die vergelijkbaar zijn met volumeschaduwkopieën (VSS) op Windows File Server. Voor meer informatie over momentopnamen van shares, zie Overzicht van momentopnamen voor Azure Files.

Momentopnamen verschillen altijd van de liveshare en van elkaar. In het ingerichte v1-factureringsmodel wordt de totale differentiële grootte gefactureerd op basis van een gebruiksmeter, ongeacht hoeveel ingerichte opslag niet wordt gebruikt. De gebruikte opslagmeter voor momentopnamen heeft een lagere prijs dan de ingerichte opslagprijs.

Voorzien van v1 soft delete

Verwijderde klassieke bestandsshares in opslagaccounts waarvoor voorlopig verwijderen is ingeschakeld, worden gefactureerd op basis van de gebruikte opslagcapaciteit van de verwijderde share voor de gedefinieerde bewaarperiode. De zacht verwijderde gebruiksopslagcapaciteit wordt tegenover de gebruikte opslagmeter voor momentopnamen geplaatst. Zie Voorlopig verwijderen inschakelen voor Azure-bestandsshares voor meer informatie over voorlopig verwijderen.

Geconfigureerde v1-facturatiemeters

Klassieke bestandsshares die zijn ingericht met het ingerichte v1-factureringsmodel, worden gefactureerd op basis van de volgende meters:

• Premium geconfigureerd: de hoeveelheid opslagruimte die is geconfigureerd in GiB.
• Premium-momentopnamen: het aantal gebruikte momentopnamen en de gebruikte tijdelijk verwijderde capaciteit.

Verbruik op basis van de ingerichte v1-factureringsmeters wordt elk uur verzonden in termen van maandelijkse eenheden. Voor een share met 1.024 GiB ingericht, zou je bijvoorbeeld het volgende moeten zien:

• Een variabel aantal eenheden voor een afzonderlijk uur, afhankelijk van het aantal dagen in de maand:
  • Maand van 28 dagen (normaal februari): 1,5238 eenheden ten opzichte van de voorgeconfigureerde Premium-meter.
  • Maand van 29 dagen (schrikkeljaar februari): 1.4713 eenheden ten opzichte van de Premium Provisioned-meter.
  • Maand van 30 dagen: 1.4222 eenheden tegen de geconfigureerde Premium-meter.
  • Maand van 31 dagen: 1.3763 eenheden ten opzichte van de Premium Geconfigureerde meter.
• Een variabel aantal eenheden indien geaggregeerd voor een dag, afhankelijk van het aantal dagen in de maand:
  • Maand van 28 dagen (normaal februari): 36.5714 eenheden bij de Premium Provisioned-meter.
  • Maand van 29 dagen (schrikkeljaar februari): 35,3103 eenheden ten opzichte van de Premium-geconfigureerde meter.
  • Maand van 30 dagen: 34.1333 eenheden voor de Premium Provisioned meter.
  • Maand van 31 dagen: 33,0323 eenheden tegen de Premium Provisioned-meter.
• 1.024 eenheden tegen de Premium-geprovisioneerde meter als ze voor een maand worden geaggregeerd.

Model voor betalen per gebruik

In het model betalen per gebruik wordt u gefactureerd hoeveel opslagruimte u gebruikt, niet hoeveel u inricht. Op hoog niveau betaalt u kosten voor de hoeveelheid logische gegevens die zijn opgeslagen en worden er ook kosten in rekening gebracht voor transacties op basis van uw gebruik van die gegevens. Facturering per gebruik kan lastig zijn om te plannen als onderdeel van een budgetteringsproces, omdat u betaalt op basis van verbruik door eindgebruikers. Daarom raden we u aan het ingerichte v2-model te gebruiken voor nieuwe klassieke bestandsshareimplementaties. Het pay-as-you-go-model is alleen beschikbaar voor HDD-opslag.

Beschikbaarheid van pay-as-you-go

Het model voor betalen per gebruik is beschikbaar voor de volgende combinaties van medialaag, redundantie en protocol voor het delen van bestanden:

Medialeigang	Redundantie	Protocol voor het delen van bestanden	Klassieke bestandsdeling (Microsoft.Storage)	Gedeelde bestanden (Microsoft.FileShares)
Solid State Drive (SSD)	Local	KMO
Solid State Drive (SSD)	Zone	KMO
Solid State Drive (SSD)	Local	NFS (Netwerkbestandssysteem)
Solid State Drive (SSD)	Zone	NFS (Netwerkbestandssysteem)
HDD	Local	KMO
HDD	Zone	KMO
HDD	Geo	KMO
HDD	GeoZone	KMO
HDD	Local	NFS (Netwerkbestandssysteem)
HDD	Zone	NFS (Netwerkbestandssysteem)
HDD	Geo	NFS (Netwerkbestandssysteem)
HDD	GeoZone	NFS (Netwerkbestandssysteem)

Klassieke HDD-bestandsshares met het model betalen per gebruik zijn algemeen beschikbaar in alle Azure-regio's.

Verschillen in toegangsniveaus

Wanneer u een klassieke bestandsshare maakt in een opslagaccount voor betalen per gebruik, kiest u tussen de volgende toegangslagen: geoptimaliseerd voor transacties, hot en cool. Alle drie de toegangsniveaus worden opgeslagen op exact dezelfde opslagapparatuur. Het belangrijkste verschil voor deze drie toegangsniveaus zijn hun opslagprijzen voor data-at-rest, die lager zijn in koelere lagen, en de transactieprijzen, die hoger zijn in de koelere lagen. Dit houdt in:

• Transactie geoptimaliseerd, zoals de naam al aangeeft, optimaliseert de prijs voor transactieworkloads met hoge IOPS (input/output bewerkingen per seconde). Transactie-geoptimaliseerd heeft de hoogste opslagprijs voor gegevens in rust, maar de laagste transactieprijzen.
• Hot is bedoeld voor actieve workloads die geen groot aantal transacties omvatten. Het heeft een iets lagere prijs voor opgeslagen data, maar iets hogere transactieprijzen in vergelijking met transactie-optimalisatie. U kunt het beschouwen als de gulden middenweg tussen de voor transacties geoptimaliseerde en koele lagen.
• Cool optimaliseert de prijs voor workloads die geen hoge activiteit hebben en biedt de laagste opslagprijs voor stilstaande gegevens, maar daar tegenover staan wel de hoogste transactieprijzen.

Als u de juiste toegangslaag voor uw use-case selecteert, kunt u uw kosten aanzienlijk verlagen. Als u een zelden benaderde workload in de transactie-geoptimaliseerde toegangslaag plaatst, betaalt u bijna niets voor de paar keer per maand dat u transacties uitvoert op uw klassieke bestandsshare. U betaalt echter een hoge hoeveelheid voor de kosten voor gegevensopslag. Als u dezelfde share naar de koude toegangslaag hebt verplaatst, betaalt u nog steeds bijna niets voor de transactiekosten, omdat u voor deze workload zelden transacties uitvoert. De koele toegangslaag heeft een lagere prijs voor gegevensopslag.

Als u een workload met hoge toegang in de koele toegangslaag plaatst, betaalt u veel meer transactiekosten, maar minder voor gegevensopslagkosten. Dit kan leiden tot een situatie waarbij de verhoogde kosten van de transactieprijzen groter zijn dan de besparingen van de verlaagde prijs voor gegevensopslag. U betaalt mogelijk meer voor cool dan u zou hebben betaald voor transacties die zijn geoptimaliseerd. Voor sommige gebruiksniveaus is het mogelijk dat de warme toegangslaag het meest kostenefficiënt is en de koele toegangslaag duurder is dan de voor transacties geoptimaliseerde laag.

Uw workload- en activiteitsniveau bepalen de meest kostenefficiënte toegangslaag voor uw klassieke bestandsshare met betalen per gebruik. In de praktijk is het de beste manier om de meest rendabele toegangslaag te kiezen, waarbij wordt gekeken naar het werkelijke resourceverbruik van de share (gegevens opgeslagen, schrijftransacties, enzovoort). Voor klassieke bestandsshares met betalen per gebruik raden we u aan om tijdens de eerste migratie naar Azure Files te beginnen in de transactielaag die is geoptimaliseerd en vervolgens de juiste toegangslaag te kiezen op basis van gebruik nadat de migratie is voltooid. Transactiegebruik tijdens de migratie wijst doorgaans niet op normaal transactiegebruik.

Wat zijn transacties?

Wanneer u een klassieke bestandsdeling koppelt met behulp van het pay-as-you-go-model op een computer met SMB, wordt de klassieke bestandsdeling op uw computer weergegeven alsof het lokale opslag is. Dit betekent dat toepassingen, scripts en andere programma's op uw computer toegang hebben tot de bestanden en mappen op de klassieke bestandsshare zonder dat ze hoeven te weten dat ze zijn opgeslagen in Azure.

Wanneer u een bestand leest of schrijft, voert de toepassing die u gebruikt een reeks API-aanroepen uit naar de bestandssysteem-API die door uw besturingssysteem wordt geleverd. Uw besturingssysteem interpreteert deze aanroepen vervolgens in SMB-protocoltransacties, die via de wire naar Azure Files worden verzonden om te voldoen. Een eenvoudige taak die de eindgebruiker beschouwt als één bewerking, zoals het lezen van een bestand van begin tot eind, kan worden omgezet in meerdere SMB-transacties die worden geleverd door Azure Files.

De klassieke bestandsshares maken gebruik van het pay-as-you-go-model en factureren op basis van gebruik. SMB- en FileREST-transacties die zijn gemaakt door toepassingen en scripts vertegenwoordigen het gebruik van uw klassieke bestandsshare en worden weergegeven als onderdeel van uw factuur. Hetzelfde concept is van toepassing op cloudservices met toegevoegde waarde die u aan uw share kunt toevoegen, zoals Azure File Sync of Azure Backup.

Transacties worden gegroepeerd in vijf verschillende transactiecategorieën die verschillende prijzen hebben op basis van hun invloed op de klassieke bestandsshare. Deze categorieën zijn: schrijven, vermelden, lezen, andere en verwijderen.

In de volgende tabel ziet u de categorisatie van elke transactie:

Schakelen tussen toegangsniveaus

Hoewel u de toegangslaag van een klassieke bestandsshare kunt wijzigen met behulp van het model betalen per gebruik, kunt u het beste de kosten optimaliseren na de eerste migratie door de meest kosten optimale toegangslaag te kiezen en daar te blijven, tenzij uw toegangspatroon verandert. Dit komt doordat het wijzigen van de toegangslaag van een klassieke bestandsshare als volgt leidt tot extra kosten:

• Transacties: Wanneer u een share verplaatst van een dynamischere toegangslaag naar een koelere toegangslaag, worden de kosten voor schrijftransacties van de statischere toegangslaag in rekening gebracht voor elk bestand in de klassieke bestandsshare. Als u een klassieke bestandsshare verplaatst van een koelere toegangslaag naar een hetere toegangslaag, worden de leestransactiekosten van de koelere toegangslaag voor elk bestand in de klassieke bestandsshare in rekening gebracht.

• Gegevens ophalen: als u overstapt van de statische toegangslaag naar dynamisch of geoptimaliseerd voor transacties, worden kosten in rekening gebracht voor het ophalen van gegevens op basis van de grootte van gegevens die zijn verplaatst. Alleen de koel toegangslaag heeft opvraagkosten voor het ophalen van gegevens.

De volgende tabel illustreert de kostenanalyse van het verschuiven van toegangsniveaus.

U kunt de toegangslaag van een klassieke bestandsshare maximaal vijf keer binnen een periode van 30 dagen wijzigen. De eerste dag van het venster van 30 dagen begint wanneer de eerste laag wordt gewijzigd. Wijzigingen tussen toegangslagen gebeuren echter onmiddellijk, maar wanneer u de toegangslaag van een share wijzigt, kunt u deze niet meer binnen 24 uur wijzigen, zelfs niet als u de eigenschap van de toegangslaag minder dan vijf keer in de afgelopen 30 dagen hebt gewijzigd.

Een toegangslaag kiezen

Ongeacht hoe u bestaande gegevens migreert naar Azure Files, raden we u aan in eerste instantie de klassieke bestandsshare te maken in de voor transactie geoptimaliseerde toegangslaag. Dit komt door het grote aantal transacties dat tijdens de migratie wordt gemaakt. Nadat uw migratie is voltooid en u een paar dagen of weken met regelmatig gebruik werkt, kunt u het aantal transacties in de prijscalculator aansluiten om te bepalen welke toegangslaag het meest geschikt is voor uw workload.

Omdat opslagaccounts met betaling per gebruik alleen transactiegegevens weergeven op het niveau van het opslagaccount, is het een onvolmaakte wetenschap om te schatten welk toegangsniveau goedkoper is voor klassieke bestandsshares. Indien mogelijk raden we u aan slechts één klassieke bestandsshare in elk opslagaccount te implementeren om volledige zichtbaarheid van facturering te garanderen.

Vorige transacties bekijken:

1. Navigeer naar uw opslagaccount in de Azure-portal.
2. Selecteer in het servicemenu onder Bewaking de optie Metrische gegevens.
3. Selecteer Bereik als de naam van uw opslagaccount, metrische naamruimte als 'Bestand', Metrische waarde als 'Transacties' en Aggregatie als 'Som'.
4. Kies Splitsing toepassen.
5. Selecteer waarden als 'API-naam'. Selecteer de gewenste limiet en sorteerbewerking.
6. Selecteer de gewenste periode.

Resourcemodellen voor betalen per gebruik

U kunt een betalen per gebruik-bestandsshare alleen maken als een klassieke bestandsshare binnen een opslagaccount (Microsoft.Storage).

Klassieke bestandsshares voor betalen per gebruik (Microsoft.Storage)

Als u een klassieke bestandsshare wilt maken met het model betalen per gebruik, moet uw opslagaccount een van de volgende combinaties van instellingen gebruiken:

Klassieke bestandsdelingen die in dezelfde opslagaccount zijn gemaakt, delen de limieten voor opslag, IOPS en doorvoer van dat opslagaccount.

Zie limieten voor het gegevensvlak van het opslagaccount voor meer informatie, waaronder welke regio's verhoogde limieten voor IOPS en doorvoer ondersteunen.

Als u azure Files correct wilt implementeren met het factureringsmodel voor betalen per gebruik op klassieke bestandsshares, moet u rekening houden met de volgende dimensies van capaciteitsplanning:

• Hoeveel gebruikte opslag, IOPS en doorvoer hebt u nodig voor elke klassieke bestandsshare? Hoe veranderen deze vereisten na verloop van tijd?
  Vanwege de beperkingen van gedeelde opslagaccountlimieten, moet u bij het toewijzen van klassieke bestandsshares aan opslagaccounts rekening houden met de behoeften van elke klassieke bestandsshare, zowel nu als in de loop van de tijd. In tegenstelling tot de ingerichte v2- en ingerichte v1-modellen biedt het model betalen per gebruik enkele beveiligingen om u te helpen de limieten van het opslagaccount te delen tussen klassieke bestandsshares in hetzelfde opslagaccount. Elke klassieke bestandsdeling in een pay-as-you-go opslagaccount kan maximaal de limieten voor grootte van de klassieke bestandsdeling omvatten en tot de limieten voor IOPS en doorvoer van het opslagaccount. Als u twee klassieke bestandsshares in hetzelfde opslagaccount voor betalen per gebruik plaatst, kan dit leiden tot IOPS- of doorvoerconflicten. Om onverwachte snelheidsbeperkingen te voorkomen, beperkt u het aantal klassieke bestandsshares dat u plaatst in een opslagaccount met betalingen naar gebruik.

• Hebt u speciale vereisten met betrekking tot het bijhouden van de factuur voor elke klassieke bestandsdeling voor afzonderlijke projecten, afdelingen of klanten?
  In Azure is de laagste nauwkeurigheid waarvoor u facturering kunt zien het niveau van de resource, wat betekent dat als u twee klassieke bestandsdelen in een opslagaccount plaatst, u hun kosten niet eenvoudig kunt traceren tot op het niveau van afzonderlijke projecten, afdelingen of klanten. U kunt dit oplossen door klassieke bestandsshares te groeperen in opslagaccounts op basis van hoe ze vanuit factureringsperspectief moeten worden bijgehouden.

• Hoeveel opslagaccounts zijn er beschikbaar in uw abonnement voor uw doelregio?
  Een extra complicerende factor is het aantal opslagaccounts dat u kunt hebben per regio per abonnement. Zie Microsoft.Storage limieten voor besturingsvlak voor meer informatie. Afhankelijk van het aantal opslagaccounts dat u nodig hebt, moet u mogelijk extra abonnementen gebruiken om extra opslagaccounts te bereiken.

Momentopnamen op basis van betalen per gebruik

Azure Files ondersteunt momentopnamen, die vergelijkbaar zijn met volumeschaduwkopieën (VSS) op Windows File Server. Voor meer informatie over momentopnamen van shares, zie Overzicht van momentopnamen voor Azure Files.

Momentopnamen verschillen altijd van de liveshare en van elkaar. In het factureringsmodel voor betalen per gebruik wordt de totale differentiële grootte gefactureerd op basis van de normale gebruikte opslagmeter. Dit betekent dat u geen afzonderlijke regel op uw factuur ziet die snapshots voor uw betalen-per-gebruik-opslagaccount vertegenwoordigt. Dit betekent ook dat het gebruik van differentiële momentopnamen telt voor reserveringen die zijn gekocht voor klassieke bestandsshares met betalen per gebruik.

Zacht verwijderen bij betalen per gebruik

Verwijderde klassieke bestandsshares in opslagaccounts waarvoor voorlopig verwijderen is ingeschakeld, worden gefactureerd op basis van de gebruikte opslagcapaciteit voor de gedefinieerde bewaarperiode. De voorlopig verwijderde gebruikte opslagcapaciteit wordt verrekend tegen de normale gebruikte opslagmeter. Dit betekent dat u geen afzonderlijk regelitem op uw factuur ziet dat klassieke bestandsdeling voor uw opslagaccount op basis van betalen per gebruik vertegenwoordigt. Dit betekent ook dat het gebruik van voorlopig verwijderde klassieke bestandsshares wordt geteld voor reserveringen die zijn gekocht voor klassieke bestandsshares met betalen per gebruik.

Meters voor afrekening per gebruik

Klassieke bestandsshares die zijn gemaakt met het factureringsmodel betalen na gebruik, worden gefactureerd op basis van de volgende meterstanden:

• Opgeslagen gegevens: de gebruikte opslag, waaronder de liveshares, differentiële momentopnamen en voorlopig verwijderde klassieke bestandsshares in GiB.
• Metagegevens: de grootte van de metagegevens van het bestandssysteem die zijn gekoppeld aan bestanden en mappen, zoals toegangsbeheerlijsten (ACL's) en andere eigenschappen in GiB. Deze factureringsmeter wordt alleen gebruikt voor klassieke bestandsdeling in de hot of cool toegangsniveaus.
• Schrijfbewerkingen: het aantal buckets voor schrijftransacties (één bucket = 10.000 transacties).
• Lijstbewerkingen: het aantal buckets voor lijsttransacties (één bucket = 10.000 transacties).
• Leesbewerkingen: het aantal buckets voor leestransacties (één bucket = 10.000 transacties).
• Andere bewerkingen / Protocolbewerkingen: het aantal andere transactiebuckets (één bucket = 10.000 transacties).
• Gegevens ophalen: de hoeveelheid gegevens die is gelezen uit de klassieke bestandsshare in GiB. Deze meter wordt alleen gebruikt voor klassieke bestandsshares in de koele toegangslaag.
• Geo-Replication gegevensoverdracht: Als de klassieke bestandsdeling de Geo- of GeoZone-redundantie heeft, wordt de hoeveelheid aan gegevens die naar de klassieke bestandsdeling is geschreven, gerepliceerd naar de secundaire regio in GiB.

Verbruikseenheden op basis van de factureringsmeters voor gegevens opgeslagen en metagegevens worden elk uur verzonden in termen van maandelijkse eenheden. Voor een aandeel met 1.024 gebruikte GiB, zou u bijvoorbeeld zien:

• Een variabel aantal eenheden voor een afzonderlijk uur, afhankelijk van het aantal dagen in de maand:
  • Maand van 28 dagen (normaal februari): 1,5238 eenheden ten opzichte van de data stored meter.
  • Maand van 29 dagen (schrikkeljaar februari): 1.4713 eenheden ten opzichte van de data stored meter.
  • Maand van 30 dagen: 1.4222 eenheden ten opzichte van de data stored meter.
  • Maand van 31 dagen: 1.3763 eenheden ten opzichte van de data stored meter.
• Een variabel aantal eenheden indien geaggregeerd voor een dag, afhankelijk van het aantal dagen in de maand:
  • Maand van 28 dagen (normaal februari): 36.5714 eenheden ten opzichte van de data stored meter.
  • Maand van 29 dagen (schrikkeljaar februari): 35.3103 eenheden ten opzichte van de data stored meter.
  • Maand van 30 dagen: 34.1333 eenheden ten opzichte van de data stored meter.
  • Maand van 31 dagen: 33.0323 eenheden ten opzichte van de data stored meter.
• 1024 eenheden ten opzichte van de data stored meter indien geaggregeerd voor een maand.

Verbruik ten opzichte van de andere meters (bijvoorbeeld schrijfbewerkingen of het ophalen van gegevens) wordt elk uur verzonden, maar omdat deze meters geen specifiek tijdsbestek aan deze meters hebben gekoppeld, hebben ze geen speciale eenheidstransformaties om rekening mee te houden.

Geconfigureerd/quotum, logische grootte en fysieke grootte

Azure Files houdt drie afzonderlijke hoeveelheden bij met betrekking tot het delen van capaciteit:

• Ingerichte grootte of quotum: Met zowel ingerichte als betalen per gebruik-bestandsshares geeft u de maximale grootte op waarnaar de bestandsshare mag groeien. In ingegeven bestandsshares wordt deze waarde de ingegeven grootte genoemd. Het bedrag dat u inricht, is waarvoor u betaalt, ongeacht hoeveel u daadwerkelijk gebruikt. In pay-as-you-go bestandsshares wordt deze waarde quotum genoemd en beïnvloedt die uw factuur niet rechtstreeks. De aangewezen grootte is een vereist veld voor bestandsdeling. Voor bestandsshares met betalen per gebruik, als de ingerichte grootte niet rechtstreeks is opgegeven, wordt de share standaard ingesteld op de maximale waarde die het opslagaccount ondersteunt (100 TiB).

• Logische grootte: de logische grootte van een bestandsshare of bestand heeft betrekking op hoe groot het is zonder rekening te houden met hoe het daadwerkelijk wordt opgeslagen, zonder opslagoptimalisatie. De logische grootte van het bestand is hoeveel KiB/MiB/GiB via de kabel wordt overgedragen als u het naar een andere locatie hebt gekopieerd. In zowel ingerichte als naar gebruik bestandsdelingen wordt de totale logische grootte van de bestandsdeling gebruikt om de ingerichte grootte/quotum af te dwingen. In bestandsdeling met betalen per gebruik is de logische grootte de hoeveelheid die wordt gebruikt voor de facturering van het gebruik van data in rusttoestand. Logische grootte wordt 'grootte' genoemd in het dialoogvenster met Windows-eigenschappen van een bestand of map en als 'inhoudslengte' door Azure Files-metrieken.

• Fysieke grootte: de fysieke grootte van het bestand heeft betrekking op de grootte van het bestand als gecodeerd op schijf. De fysieke grootte kan overeenkomen met de logische grootte van het bestand of kan kleiner zijn, afhankelijk van de wijze waarop het bestand is geschreven door het besturingssysteem. Een veelvoorkomende reden waarom de logische grootte en fysieke grootte anders moeten zijn, is door gebruik te maken van sparse-bestanden. De fysieke grootte van de bestanden in de gedeelde map wordt gebruikt voor facturering van momentopnamen, hoewel toegewezen bereiken worden gedeeld tussen momentopnamen als ze ongewijzigd zijn (verschillende opslag).

Services met toegevoegde waarde

Net als bij veel on-premises opslagoplossingen biedt Azure Files integratiepunten voor producten van de eerste en derde partij die kunnen worden geïntegreerd met bestandsshares die eigendom zijn van de klant. Hoewel deze oplossingen aanzienlijke extra waarde kunnen bieden voor Azure Files, moet u rekening houden met de extra kosten die deze services toevoegen aan de totale kosten van een Azure Files-oplossing.

Kosten worden onderverdeeld in drie buckets:

• Licentiekosten voor de service met toegevoegde waarde. Licentiekosten kunnen de vorm hebben van vaste kosten per klant, eindgebruiker (ook wel hoofdkosten genoemd), bestandsshare of opslagaccount. Ze kunnen ook worden gebaseerd op eenheden van opslaggebruik, zoals vaste kosten voor elk 500 GiB-segment van gegevens in de bestandsshare.

• Transactiekosten voor de service met toegevoegde waarde. Sommige services met toegevoegde waarde hebben hun eigen concept van transacties boven op het Azure Files-factureringsmodel dat is geselecteerd. Deze transacties worden weergegeven op uw factuur onder de kosten van de toegevoegde waardeservice; Ze hebben echter rechtstreeks betrekking op de wijze waarop u de service met toegevoegde waarde gebruikt met uw bestandsshare.

• Azure Files kosten betreffende het gebruik van een service met toegevoegde waarde. Azure Files brengt klanten niet rechtstreeks kosten in rekening voor het toevoegen van services met toegevoegde waarde, maar als onderdeel van het toevoegen van waarde aan de Azure-bestandsshare, kan de service met toegevoegde waarde de kosten verhogen die u op uw Azure-bestandsshare ziet. Deze kosten zijn gemakkelijk te zien bij bestandsdeling op basis van betalen per gebruik, door transactiekosten. Als de service met toegevoegde waarde transacties uitvoert op basis van de bestandsshare namens u, worden ze weergegeven in uw Azure Files-transactiefactuur, ook al hebt u deze transacties zelf niet rechtstreeks uitgevoerd. Dit geldt ook voor ingerichte bestandsshares, hoewel dit mogelijk minder merkbaar is. Transacties op basis van ingerichte bestandsshares van toegevoegde waardeservices tellen mee op basis van uw ingerichte IOPS-nummers, wat betekent dat services met toegevoegde waarde mogelijk meer opslagruimte moeten inrichten om voldoende IOPS of doorvoer beschikbaar te maken voor uw workload.

Wanneer u de totale eigendomskosten voor uw bestandsshare wilt berekenen, moet u rekening houden met de kosten van Azure Files en alle services die u wilt gebruiken met Azure Files.

Er zijn meerdere services met toegevoegde waarden en services van derden. In dit document wordt een subset behandeld van de algemene first-party-services die klanten gebruiken met Azure-bestanden. Meer informatie over services die hier niet worden vermeld, vindt u op de pagina met prijzen voor die service.

Azure File Sync

Azure File Sync is een service met toegevoegde waarde voor Azure Files waarmee een of meer on-premises Windows-bestandsshares worden gesynchroniseerd met een Azure-bestandsshare. Omdat de Azure-bestandsshare in de cloud een volledige kopie heeft van de gegevens in een gesynchroniseerde bestandsshare die on-premises beschikbaar is, kunt u uw on-premises Windows-bestandsserver transformeren in een cache van de Azure-bestandsshare om uw on-premises footprint te verminderen. Lees inleiding tot Azure File Sync voor meer informatie.

Wanneer u rekening houdt met de totale eigendomskosten voor een oplossing die is geïmplementeerd met Behulp van Azure File Sync, moet u rekening houden met de volgende kostenaspecten:

• Kapitaal- en operationele kosten van Windows-bestandsservers met een of meer servereindpunten. Azure File Sync als replicatieoplossing is neutraal van waar de Windows-bestandsservers die worden gesynchroniseerd met Azure Files zijn; ze kunnen on-premises, in een virtuele Azure-machine of zelfs in een andere cloud worden gehost. De kosten voor synchronisatieservers die on-premises of in andere cloudproviders worden gehost, omvatten zowel kapitaal- als operationele kosten die niet worden bijgehouden als onderdeel van uw Azure-factuur, maar maken nog steeds deel uit van de totale eigendomskosten van de oplossing. Kapitaalkosten zijn de vooraf gemaakte hardwarekosten van uw oplossing. Operationele kosten zijn de lopende kosten van arbeid, elektriciteit, enz. U moet rekening houden met de hoeveelheid gegevens die u on-premises moet opslaan, het aantal CPU's en de hoeveelheid geheugen die uw Windows-bestandsservers nodig hebben om Azure File Sync-workloads te hosten en andere organisatiespecifieke kosten die u mogelijk hebt. Zie aanbevolen systeemresources voor meer informatie.

• Licentiekosten per server voor servers die zijn geregistreerd bij Azure File Sync. Als u Azure File Sync wilt gebruiken met een specifieke Windows-bestandsserver, moet u deze eerst registreren bij de Azure-resource van Azure File Sync, de opslagsynchronisatieservice. Elke server die u registreert na de eerste server heeft een vast maandelijks tarief. Hoewel deze vergoeding klein is, is het een onderdeel van uw factuur om rekening mee te houden. Als u de huidige prijs van de serverregistratiekosten voor uw gewenste regio wilt zien, raadpleegt u de sectie File Sync op de pagina met prijzen van Azure Files.

• Kosten voor Azure Files. Azure File Sync verbruikt resources van uw Azure-bestandsshare. Sommige van deze resources, zoals opslagverbruik, zijn relatief duidelijk, terwijl andere resources, zoals transactie- en momentopnamegebruik, mogelijk niet zijn. Voor de meeste klanten raden we u aan hdd-ingerichte v2-bestandsshares te gebruiken met Azure File Sync, hoewel Azure File Sync volledig wordt ondersteund op alle Azure Files-factureringsmodellen (SSD ingericht v2, ingerichte SSD v1 of HDD betalen per gebruik).

  • Opslaggebruik. Azure File Sync repliceert eventuele wijzigingen die u aanbrengt in uw servereindpunt naar uw Azure-bestandsshare, waardoor opslag wordt verbruikt. Bij ingerichte bestandsshares verbruiken wijzigingen ingerichte ruimte, dus het is uw verantwoordelijkheid om de inrichting zo nodig periodiek te verhogen om rekening te houden met de groei van bestandsshares. Bij bestandsshares met betalen per gebruik zorgt het toevoegen of vergroten van de grootte van bestaande bestanden op servereindpunten ervoor dat de gebruikte opslagkosten toenemen omdat de wijzigingen worden gerepliceerd.

  • Momentopnamegebruik. Azure File Sync maakt momentopnamen op share- en bestandsniveau als onderdeel van normaal gebruik. Hoewel het gebruik van momentopnamen altijd differentieel is, kan dit op een merkbare manier bijdragen aan de totale Azure Files-factuur.

  • IOPS/doorvoergebruik: Azure File Sync stations IOPS en doorvoergebruik om wijzigingen van uw servereindpunten over te dragen naar uw Azure-bestandsshare. Als u een ingerichte bestandsshare gebruikt, moet u het gebruik van de bestandsshare controleren om ervoor te zorgen dat u voldoende IOPS en doorvoer hebt ingericht die u niet beperkt. Als u een betalen per gebruik-bestandsshare gebruikt, worden er kosten in rekening gebracht voor het IOPS-gebruik in de vorm van transacties. Over het algemeen zijn er twee soorten transacties om rekening mee te houden:

    • Transacties van klantverloop. Wanneer bestanden op servereindpunten veranderen, worden de wijzigingen geüpload naar de cloudshare, waardoor transacties worden gegenereerd. Wanneer cloud-tiering is ingeschakeld, worden er extra transacties gegenereerd voor het beheren van gelaagde bestanden, waaronder I/O-bewerkingen op gelaagde bestanden, naast de uitgiftekosten. Hoewel de hoeveelheid en het type transacties moeilijk te voorspellen zijn vanwege verloopsnelheden en cache-efficiëntie, kunt u uw vorige transactiepatronen gebruiken om toekomstige kosten te schatten als u denkt dat uw toekomstige gebruik vergelijkbaar is met uw huidige gebruik.

    • Transacties uit cloud-inventarisatie. Azure File Sync inventariseert de Azure-bestandsshare eenmaal per dag in de cloud om wijzigingen te detecteren die rechtstreeks zijn aangebracht in de share, zodat ze kunnen worden gesynchroniseerd met de servereindpunten. Met deze scan worden transacties gegenereerd die worden gefactureerd voor het opslagaccount met een tarief van één ListFiles transactie per directory per dag. U kunt dit nummer in de prijscalculator plaatsen om de scankosten te schatten.

    Aanbeveling

    Als u niet weet hoeveel mappen u hebt, bekijkt u het hulpprogramma TreeSize van JAM Software GmbH.

Azure Backup

Azure Backup biedt een serverloze back-upoplossing voor Azure Files die naadloos kan worden geïntegreerd met uw bestandsshares en met andere services met toegevoegde waarde, zoals Azure File Sync. Azure Backup voor Azure Files is een back-upoplossing op basis van momentopnamen die een planningsmechanisme biedt voor het automatisch maken van momentopnamen volgens een door de beheerder gedefinieerd schema. Het biedt ook een gebruiksvriendelijke interface voor het herstellen van verwijderde bestanden/mappen of de hele share naar een bepaald tijdstip. Voor meer informatie, zie Over de back-up van Azure-bestandsshares.

Houd rekening met de volgende factoren wanneer u rekening houdt met de kosten voor het gebruik van Azure Backup:

• Licentiekosten voor beveiligde exemplaren voor Azure-bestandssharegegevens. Azure Backup brengt kosten in rekening voor een beveiligd exemplaarlicentie per opslagaccount met een back-up van Azure-bestandsshares. Een beveiligd exemplaar wordt gedefinieerd als 250 GiB van Azure-bestandsshareopslag. Opslagaccounts met minder dan 250 GiB zijn onderhevig aan fractionele kosten voor beschermde instanties. Zie prijzen voor Azure Backup voor meer informatie. U moet Azure Files selecteren in de lijst met services die Azure Backup kan beveiligen.

• Kosten voor Azure Files. Azure Backup verhoogt de kosten van Azure Files op de volgende manieren:

  • Differentiële kosten van momentopnamen van Azure-bestandsshares. Azure Backup automatiseert het maken van momentopnamen van Azure-bestandsshares volgens een door de beheerder gedefinieerd schema. Momentopnamen zijn altijd differentieel; de toegevoegde kosten zijn echter afhankelijk van de periode waarin de momentopnamen worden bewaard en de hoeveelheid wijzigingen in de bestandsshare gedurende die tijd. Deze factoren bepalen hoe verschillend de momentopname is van de live bestandsshare en daarom hoeveel extra gegevens worden opgeslagen door Azure Files.

  • Transactiekosten van herstelbewerkingen. Herstelbewerkingen van de momentopname naar de liveshare leiden tot transactiekosten. Voor standaardbestandsshares worden leesbewerkingen van momentopnamen/schrijfbewerkingen vanuit herstelbewerkingen gefactureerd als normale bestandssharetransacties. Voor ingerichte bestandsshares tellen deze bewerkingen mee voor de ingerichte IOPS voor de bestandsshare.

Microsoft Defender voor Storage

Microsoft Defender ondersteunt Azure Files als onderdeel van het Microsoft Defender for Storage-product. Microsoft Defender voor Storage detecteert ongebruikelijke en mogelijk schadelijke pogingen om uw Azure-bestandsshares te openen of misbruiken via SMB of FileREST. Microsoft Defender voor Storage is op abonnementsniveau ingeschakeld voor alle bestandsshares in de opslagaccounts van dat abonnement.

Microsoft Defender voor Storage biedt geen ondersteuning voor antivirusmogelijkheden voor Azure-bestandsshares.

De belangrijkste kosten van Microsoft Defender for Storage zijn een extra set transactiekosten die door het product worden geheven boven op de transacties die worden uitgevoerd op basis van de Azure-bestandsshare. Hoewel deze kosten zijn gebaseerd op de transacties die in Azure Files worden gemaakt, maken ze geen deel uit van de facturering voor Azure Files, maar maken ze deel uit van de prijzen van Microsoft Defender. Microsoft Defender for Storage brengt transactiekosten in rekening, zelfs op geconfigureerde bestandsshares, waarbij Azure Files transacties omvat als onderdeel van de IOPS-configuratie. Het huidige transactietarief vindt u op Microsoft Defender voor Cloud pagina met prijzen onder de tabelrij Microsoft Defender for Storage.

Voor transacties met zware bestandsshares worden aanzienlijke kosten in rekening gebracht met behulp van Microsoft Defender for Storage. Op basis van deze kosten wilt u zich mogelijk afmelden voor Microsoft Defender for Storage voor specifieke opslagaccounts. Zie Een opslagaccount uitsluiten van Microsoft Defender for Storage-beveiliging voor meer informatie.

Reserveringen

Azure Files ondersteunt reserveringen (ook wel gereserveerde instanties genoemd) voor de ingerichte v1- en betalen per gebruik-modellen. Met reserveringen kunt u korting krijgen op opslag door vooraf gebruik te maken van opslag. Overweeg gereserveerde exemplaren te kopen voor enige productieworkload of ontwikkel- en testworkloads met consistente werklastpatronen. Wanneer u een reservering aanschaft, moet u de volgende dimensies opgeven:

• Capaciteitsgrootte: Reserveringen kunnen voor 10 TiB of 100 TiB zijn, met aanzienlijke kortingen voor het kopen van een reservering met een hogere capaciteit. U kunt meerdere reserveringen aanschaffen, inclusief reserveringen van verschillende capaciteitsgrootten om te voldoen aan uw workloadvereisten. Als uw productie-implementatie bijvoorbeeld 120 TiB van klassieke bestandsshares heeft, kunt u één 100 TiB-reservering en twee 10 TiB-reserveringen aanschaffen om te voldoen aan de totale opslagcapaciteitsvereisten.
• Termijn: U kunt reserveringen kopen voor een termijn van één jaar of drie jaar, met meer significante kortingen voor het kopen van een langere reserveringsperiode.
• Laag: de laag van Azure Files met betrekking tot de reservering. Reserveringen zijn momenteel beschikbaar voor de factureringsmodellen voor SSD-geconfigureerde v1 (als 'premium') en HDD betalen per gebruik (alleen 'hete en koele' toegangslagen).
• Locatie: De Azure-regio voor de reservering. Reserveringen zijn beschikbaar in een subset van Azure-regio's.
• Redundantie: de opslagredundantie voor de reservering. Reserveringen worden ondersteund voor alle redundantie die Azure Files ondersteunt, waaronder LRS, ZRS, GRS en GZRS.
• Factureringsfrequentie: Geeft aan hoe vaak het account wordt gefactureerd voor de reservering. Opties zijn maandelijks of vooraf.

Zodra u een reservering hebt gekocht, wordt deze automatisch gebruikt door uw bestaande opslaggebruik. Als u meer opslagruimte gebruikt dan u hebt gereserveerd, betaalt u een catalogusprijs voor het saldo dat niet wordt gedekt door de reservering. Transactie-, bandbreedte-, gegevensoverdracht- en metagegevensopslagkosten worden niet opgenomen in de reservering.

Er zijn verschillen in hoe reserveringen werken met momentopnamen van gedeelde bestanden voor betalen naar gebruik en geprovisioneerde v1-bestandsshares. Als u momentopnamen maakt van klassieke bestandsdelen op basis van gebruik, tellen de verschillen in momentopnamen mee voor de reservering en worden ze gefactureerd als onderdeel van de normale opslaggebruiksmeter. Als u echter momentopnamen maakt van geprovisioneerde klassieke v1-bestandsshares, worden de momentopnamen gefactureerd met behulp van een afzonderlijke meter en worden ze niet meegeteld voor de reservering.

Voor meer informatie over het aanschaffen van reserveringen, zie Kosten optimaliseren voor Azure Files met reserveringen.

Zie ook

• Prijzen voor Azure Files
• Voorbeelden van kostenramingen
• Planning voor een Azure Files-implementatie en planning voor een Azure File Sync-implementatie
• Een klassieke bestandsshare maken
• Een bestandsshare maken (preview)