Agent Bucket: Petabyte-schaal Agent Native Storage Bucket

Nu AI Agents als paddenstoelen uit de grond schieten, bouwen ontwikkelaars in een ongekend tempo fantasierijke, intelligente applicaties. Van programmeerassistenten die je helpen code te schrijven tot creatietools die met één zin een film genereren, tot persoonlijke intelligente assistenten die altijd klaar staan, Agent herdefinieert de manier waarop we omgaan met de digitale wereld. Achter deze golf wordt een consensus steeds duidelijker: met behulp van Serverless-architectuur (zoals Lambda), grote taalmodellen (LLM) en cloudopslag (zoals S3, TOS), gecombineerd met Vibe Coding, kan iedereen in 30 minuten snel zijn eigen AI Agent bouwen.

Van "bruikbaar" naar "goed bruikbaar", Agent-ontwikkelaars moeten nog steeds problemen overwinnen om van "speelgoed" naar "productieklare applicaties" te gaan. Naarmate de business zich uitbreidt naar een enorm aantal gebruikers, worden ontwikkelaars geconfronteerd met een uiterst complexe uitdaging: hoe bouw je een compleet opslagsysteem voor een enorm aantal eindgebruikers op objectopslag? Voor de meeste ontwikkelaars is dit niet alleen een technische drempel, maar ook een kloof die de grootschalige distributie van Agent belemmert. Agent Bucket is ontworpen om het bouwproces van multi-tenant systemen volledig te vereenvoudigen door middel van AI-native opslagontwerp en vriendelijkere Agent-mogelijkheden te bieden.

Wanneer honderden miljoenen gebruikers binnenstromen, is traditionele objectopslag "niet genoeg"

Stel je voor dat je een populaire AIGC-applicatie hebt ontwikkeld. Elke gebruiker genereert en slaat een groot aantal afbeeldingen, video's en tijdelijke bestanden op. Als ontwikkelaar kies je natuurlijk voor volwassen, schaalbare objectopslagdiensten zoals S3 en TOS. Maar hier komt het probleem: hoe beheer je data voor een enorm aantal gebruikers?

De S3-blog van 2022, "Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3", beschrijft twee manieren, "elke tenant gebruikt een onafhankelijke S3-bucket" en "gedeelde S3-bucket op basis van prefix-isolatie":

• Maak een onafhankelijke "bucket" voor elke gebruiker: dit is haalbaar als er weinig gebruikers zijn, maar wanneer het aantal gebruikers groeit tot tienduizenden of miljoenen, zal het aantal buckets snel exploderen, waardoor de beheerkosten en resourcebeperkingen onhoudbaar worden. S3 biedt een totale bucketquota van 10.000 in de hele regio, maar voor populaire AI-mogelijkheden is 10.000 nog lang niet genoeg.

• Gebruik "prefixen" om gebruikers te onderscheiden in dezelfde bucket: dit is de mainstream oplossing geworden. De bestanden van gebruiker A beginnen bijvoorbeeld allemaal met user-a/, en die van gebruiker B met user-b/, net als het beheren van bestanden met mappen op een computer. Objectopslag heeft echter geen native mappen. Deze oplossing onderscheidt multi-tenants via "common prefix" in het "K-V" opslagsysteem. // K-V staat voor Key-Value, een type database.

Deze op "bucket" of "prefix" gebaseerde oplossingen worden al tien jaar lang op grote schaal gebruikt. Maar er zijn de volgende problemen:

• Multi-tenant isolatie: de data van alle gebruikers zijn vermengd in dezelfde bucket. Een abnormaal hoogfrequent bezoek van één gebruiker kan alle andere gebruikers beïnvloeden en een "buureffect" veroorzaken. Prestatie-isolatie en foutisolatie zijn onmogelijk.

• Toegangscontrole: complexe machtigingsbeleidsregels (IAM Policy) zijn moeilijk te onderhouden en er kunnen gemakkelijk configuratiefouten optreden, waardoor gebruikersdata onbedoeld toegankelijk worden, vooral wanneer interactie met andere clouddiensten vereist is, is het risico groter. // IAM staat voor Identity and Access Management.

• Kosten duidelijk: het is moeilijk om precies te weten hoeveel opslagruimte elke gebruiker verbruikt en hoeveel verkeerskosten er zijn gegenereerd. Wanneer je betaalde gebruikers wilt factureren op basis van gebruik, worden facturering en meting een onduidelijk verhaal.Waarom de implementatie van deze schijnbaar basale behoeften door Agent-ontwikkelaars op objectopslag soms 'zwaar' aanvoelt? Een diepgaand onderzoek onthult dat er in de huidige cloud-native architectuur een enorme leemte bestaat tussen 'objectopslag' zoals S3/TOS en traditionele 'bestandssystemen'. De essentie van objectopslag (S3/TOS) is 'afvlakking'; het oorspronkelijke ontwerp was bedoeld voor de eenvoudige opslag van enorme hoeveelheden data, als een gigantisch magazijn. Hoewel de capaciteit bijna onbeperkt is, is de logische structuur uiterst eenvoudig. Het ontbreekt aan native geavanceerd directorybeheer, fijnmazige metadata-controle en echte tenant-awareness. Wanneer ontwikkelaars proberen om op de 'platte' S3 een 'driedimensionaal' multi-tenant bestandssysteem te simuleren door middel van hard-coded prefixes, gebruiken we in feite een 'statische KV-opslag' om een 'directory-semantiek, sterk geïsoleerde' Agent-applicatie bestandstoegang te ondersteunen. Dat wil zeggen, de Agent moet extra tokens verbruiken om bestanden te beheren en de rechten en isolatie van meerdere tenants te controleren en op te lossen. Deze extra verbruikte tokens geven allemaal aan dat de eenvoudige opslagservice die S3 definieert, niet eenvoudig genoeg is voor de Agent.

De S3-blog uit 2025, "Design patterns for multi-tenant access control on Amazon S3", beschrijft verder S3 Access Points. Dit betekent dat er meerdere virtuele netwerktoegangspunten kunnen worden gecreëerd en dat elk toegangspunt kan worden geconfigureerd met een aangepast toegangspuntbeleid, waardoor er op het niveau van netwerkplanning enkele oplossingen zijn voor multi-tenant scenario's.

Agent Wonderland

Een ideale Agent-ontwikkelaar kan bij het ontwikkelen van een AI Agent een volledig serverless Agent bouwen op basis van "Agent SDK + opslag + MaaS-service":

• Agent kan volledig serverless draaien

• Kan bestaande productmogelijkheden combineren om een Agent te bouwen via Vibe Coding

• Hoeft alleen het python-script van de "ADK" te onderhouden

• Opslag gebruikt objectopslag

• AI-mogelijkheden gebruiken Doubao (豆包)

• Theoretisch geen ECS of andere instance-gebaseerde producten

Daarnaast moet de opslag de volgende mogelijkheden bieden:

• Agent kan een object-semantische opslag hebben (bestanden opslaan), multi-tenant toegang bieden, beginnend bij miljoenen, uitbreidbaar tot miljarden

• Agent kan elke gebruiker een onafhankelijke ruimte bieden (tussen meerdere bedrijven, bedrijfsnamen of uid's kunnen worden hergebruikt)

• Agent kan direct de bandbreedte van elke gebruiker configureren, de totale maximale objectgrootte van de gebruiker configureren

• Agent kan factureren, monitoren en observeren op basis van de gebruiker

• Agent kan toegangsbeleid configureren voor de bestanden van elke gebruiker

Agent Bucket: AI Agent voorzien van 'native multi-tenant' genen

Om dit probleem fundamenteel op te lossen, hebben we een nieuw paradigma voor objectopslag voorgesteld: Agent Bucket. De belangrijkste innovatie is de introductie van een nieuwe native resource-laag tussen de traditionele 'bucket' en 'object': objectverzamelingen (ObjectSet).

De kern van dit ontwerp is uiterst eenvoudig: koppel aan elke eindgebruiker een exclusieve ObjectSet. Je kunt ObjectSet zien als een 'data-kluis' of 'persoonlijke cloudruimte' die speciaal voor elke gebruiker is gemaakt. Het behoort logisch gezien tot jouw (ontwikkelaar) Bucket, maar fysiek en qua beheer heeft het zijn eigen onafhankelijke 'persoonlijkheid' en 'levenscyclus'.Agent Bucket ondersteunt 100 miljoen ObjectSets per bucket, wat betekent dat je met gemak diensten kunt leveren aan honderden miljoenen eindgebruikers, alsof elke eindgebruiker "leeft" in zijn eigen, onafhankelijke opslagruimte, zonder je zorgen te hoeven maken over multi-tenant opslagbeheer.

ObjectSet-ontwerp - Agent-vriendelijke mogelijkheden

In Agent Bucket is ObjectSet niet alleen een extra niveau, maar maakt het ook de meest lastige behoeften in multi-tenant scenario's direct beschikbaar als native mogelijkheden. Zodra de data-eigendom is vastgesteld op het ObjectSet-niveau, wordt een reeks mogelijkheden die in het verleden moeilijk te realiseren waren, vanzelfsprekend.

• Native isolatie: Op ObjectSet-niveau kun je onafhankelijke QPS-, bandbreedtebeperkingen en capaciteitsquota instellen voor elke gebruiker. De ervaring van betalende gebruikers kan worden gegarandeerd, en het abnormale gedrag van gratis gebruikers zal anderen niet beïnvloeden. Dit is echte foutdomeinisolatie, waardoor "buren" elkaar niet langer storen.

• Native permissies: Elke ObjectSet kan een onafhankelijk domein hebben. Dit betekent dat je gebruiker A een exclusief toegangsadres kunt geven van user-a.yourapp.com, in plaats van het domein van de hele opslagbucket bloot te leggen. Nog slimmer is het ontwerp met "twee sloten": het eerste slot is een tijdelijke toegangsreferentie (STS) uitgegeven door de cloudprovider, die de toegangsrechten op applicatieniveau controleert; het tweede slot is het onafhankelijke domein van de ObjectSet, dat toegangsverzoeken vanaf het netwerkniveau vergrendelt in de eigen dataruimte van de gebruiker. Dit verhoogt de databeveiliging aanzienlijk.

• Native monitoring: Op het monitoringdashboard kun je niet langer alleen de overzichtsgegevens van de hele bucket zien. Je kunt de monitoringgrafieken per ObjectSet uitsplitsen, duidelijk inzicht krijgen in welke eindgebruiker veel toegang heeft, en zo nauwkeurige operationele en optimalisatiebeslissingen nemen.

• Native capaciteitsverlaging: Beleid dat in het verleden alleen op bucketniveau kon worden ingesteld, kan nu worden verlaagd naar elke gebruiker. Je kunt verschillende datalevenscycli instellen voor verschillende niveaus van gebruikers, of verschillende encryptiesleutels gebruiken voor elke ObjectSet, waardoor een meer verfijnd en veiliger databeheer mogelijk is.

• Native meting: Wil je weten hoeveel opslagruimte elke gebruiker in beslag neemt? Wil je de opslagkosten nauwkeurig toewijzen aan elke gebruiker? Nu is het heel eenvoudig. Agent Bucket berekent automatisch de capaciteit en het gebruik van elke ObjectSet, waardoor je facturering en verdeling helder en duidelijk zijn.

• Native facturering: Ontwikkelaars kunnen eenvoudig kostenverdeling implementeren en de kosten die door opslag worden gegenereerd, nauwkeurig terugvoeren naar elke eindgebruiker. Bijvoorbeeld, gedifferentieerde kosten in rekening brengen op basis van de werkelijke kostenverhouding van verschillende gebruikers A, B en C, om data-ondersteuning te bieden voor de commercialisering van Agent.

• Native capaciteitslimiet: Om de operationele kosten van Agent te beheersen, kun je een Quota (capaciteitslimiet) instellen voor elke ObjectSet. Zodra de vooraf ingestelde waarde is bereikt, zal het systeem de gebruiker beperken om nieuwe bestanden te genereren, waardoor misbruik van resources in multi-tenant scenario's vanaf de bron wordt voorkomen.

• Native intelligentie: Agent Bucket laat Agent ontsnappen aan de beperkingen van traditionele eenvoudige "opslag en toegang" van bestanden, geeft Object native intelligentie en ondersteunt efficiënter de one-stop ontwikkeling van Agent. ObjectSet kan met één klik intelligente indexering inschakelen, Agent voorzien van native vriendelijke multi-modale vraag- en antwoordmogelijkheden, de mechanische werking van traditionele Object CRUD vervangen; het ondersteunt zelfs het inschakelen van de Agentself-modus met één klik, het verbinden van vectoren, kennis, modellen en prompts, en direct de functie van gescripte sub-Agent blootleggen, waardoor de bovenliggende Agent-ontwikkelaar zich kan concentreren op het creëren van de workflow van de hoofdactiviteiten en de efficiëntie van intelligente verzilvering volledig kan vrijgeven.

Technische uitdagingen als gevolg van de explosieve groei van de applicatieschaal

Agent Bucket biedt applicatieontwikkelaars een elegante en efficiënte manier om de data van honderden miljoenen eindgebruikers te beheren door de introductie van het native concept ObjectSet. De digitale activa van elke gebruiker worden veilig opgeslagen in hun eigen exclusieve ObjectSet, waardoor op natuurlijke wijze isolatie, facturering en quotabeheer worden gerealiseerd.

Met de snelle uitbreiding van de applicatieschaal komen de beheercomplexiteit, isolatiemoeilijkheden en fysieke knelpunten van een enorme hoeveelheid Sets tegelijkertijd aan het licht:

• Probleem van hiërarchisch beheer van een enorme hoeveelheid gebruikers: Wanneer een applicatie de resources en functies van een groot aantal gebruikers van verschillende niveaus differentieel beheert, moet het zijn eigen hiërarchische metadata van de gebruiker ontwerpen en implementeren, en objectopslagfunctie-schakelaars associëren. Het helpen van ontwikkelaars om de hiërarchie van gebruikers elegant te beheren op basis van het native concept van Set is belangrijk om de implementatie van de applicatie te versnellen. - Capaciteitsknelpunt van één cluster: Hoewel Agent Bucket logisch oneindig kan worden uitgebreid, worden de metadata standaard opgeslagen in één fysiek cluster. Wanneer het totale aantal objecten in de bucket honderden miljarden of zelfs biljoenen bereikt, wordt de fysieke capaciteit van één cluster een onoverkomelijke limiet.

• Probleem met het delen van toegangspunten: De diversiteit van de Agent-business en het enorme aantal gebruikers brengen grotere veiligheidsrisico's en explosieradius met zich mee voor het toegangspunt zelf. Hoe dynamische planning kan worden uitgevoerd op basis van de verschillen tussen een groot aantal verschillende bedrijven en gebruikers om gedifferentieerde veiligheid, isolatie en versnellingsmogelijkheden te realiseren, is een uitdaging.

Set Tagging: Tag-gebaseerd beheer van gebruikersclassificatie

ObjectSet biedt een native tag-gebaseerde beheermethode, waardoor Agent-ontwikkelaars eenvoudig de set tagging-mogelijkheid kunnen gebruiken om het gelaagde beheer van gebruikers te voltooien; ontwikkelaars kunnen elk gedefinieerd gebruikersniveau toewijzen aan een tag en verschillende quota's en functies inschakelen voor elke tag. Alle ObjectSets die met deze tag zijn gelabeld, passen de overeenkomstige quota's en functies toe. Neem de drie niveaus V1, V2 en V3 als voorbeeld:

• V1: Standaardniveau, gratis gebruikers, de standaardtag voor alle ObjectSets, kan worden geconfigureerd om maximaal 1 GiB aan gegevens op te slaan, de openbare netwerkdistributie mag niet meer dan 100 mbps bandbreedte bedragen en de download snelheid van één stream wordt geregeld op 1 mbps;

• V2: Betaald lid op instapniveau, geconfigureerd om maximaal 10 GiB aan gegevens op te slaan, de openbare netwerkdistributie mag niet meer dan 10 gbps bandbreedte bedragen en de download snelheid van één stream wordt geregeld op 10 mbps;

• V3: Betaald lid op hoog niveau, naast het bieden van grotere opslag- en openbare netwerkdistributiequota, ondersteunt het ook de configuratie om extra openbare netwerkzwakke netwerkversnelling en hoogwaardige mediaversnellingsmogelijkheden in te schakelen;

Agent-ontwikkelaars kunnen de V1/V2/V3-tagging flexibel gebruiken om de bronnen en toegevoegde waarde functies te beheren die deze gebruikers kunnen gebruiken, gericht op de verschillende ontwikkelingscycli van verschillende gebruikers.

Set Slice: Native isolatie van enorme gebruikersgegevens

Wanneer het aantal sets in een Agent Bucket honderden miljoenen bereikt en het aantal objecten honderden miljarden of biljoenen bereikt, brengt het feit dat "alle metadata van één Bucket gecentraliseerd zijn in één KV-cluster" op zichzelf dubbele risico's met zich mee op het gebied van capaciteit en prestaties.

Set Slice biedt een idee van "logisch niet splitsen, fysiek splitsen":

• Vanuit logisch oogpunt beheert u nog steeds slechts één Agent Bucket.

• Fysiek worden de metadata, afhankelijk van het bereik van de Set en de objectnamen in de Set, verdeeld in meerdere Slices (segmenten). Elke Slice kan worden opgeslagen in verschillende clusters, meerdere Sets zijn van nature geïsoleerd en één Set kan horizontaal worden uitgebreid.

Set Slice is een verdere uitbreiding en garantie van de ObjectSet-mogelijkheid. Het lost fundamenteel het probleem van onbeperkte fysieke capaciteitsuitbreiding op en zorgt tegelijkertijd voor de stabiliteit en consistentie van het ObjectSet-beheermodel op de bovenste laag.

• Stabiele beheer grenzen: Zelfs als de gegevens van een Agent Bucket meerdere fysieke clusters omvatten, is ObjectSet nog steeds de enige basiseenheid voor machtigingen, quota's, facturering en monitoring. Het beleid dat ontwikkelaars configureren voor ObjectSet (zoals toegangscontrole, capaciteitslimiet) wordt automatisch van kracht op alle gerelateerde Slices, zonder zich zorgen te hoeven maken over de distributie van de onderliggende gegevens.

• Eén Set kan lineair worden uitgebreid: Wanneer de hoeveelheid gegevens van een ObjectSet snel groeit, worden de gegevens op natuurlijke wijze verdeeld over meerdere Slices. Naarmate het algehele cluster wordt uitgebreid, groeit de capaciteit van de ObjectSet ook naadloos en lineair. Ontwikkelaars hoeven geen destructieve bewerkingen uit te voeren op de ObjectSet zelf, zoals splitsen of migreren.

• Bronisolatie tussen Sets: Door verschillende objectbereiken te distribueren over verschillende fysieke clusters, realiseert SetSlice een hogere dimensie van bronisolatie. In combinatie met het quotabeheer van ObjectSet kan het effectief voorkomen dat de datagroei van een "supergrote" ObjectSet alle bronnen van een enkel cluster verdringt, waardoor de stabiliteit van andere ObjectSets wordt beïnvloed en het algehele capaciteitsrisico beheersbaar wordt.- Logische eenheid en compatibiliteit: Voor bedrijven en ontwikkelaars is de Agent Bucket altijd een logisch uniforme entiteit, ongeacht hoeveel Slices er onderliggend zijn. Alle bewerkingen op buckets, ObjectSets en objecten blijven hetzelfde, waardoor de fysieke uitbreiding volledig transparant is voor de bovenliggende applicaties.

Set AccessPoint: Isoleer de toegangspunten van elke gebruiker

Agent Bucket ondersteunt het openen van onafhankelijke toegangspunten (onafhankelijke domeinnamen) voor elke ObjectSet, en breidt gedifferentieerde beveiligings-, isolatie- en versnellingsmogelijkheden uit op de toegangspunten. Het systeem moet hiervoor de planning van onafhankelijke toegangspunten op miljardenniveau en gedifferentieerde configuratiemogelijkheden ondersteunen.

Onafhankelijke toegangs domeinnaam {$apid}.tos-objectset-ap.volces.com: tweeledige beveiliging

• Eerste niveau Obscurity (verborgenheid): Onafhankelijk subdomein per gebruiker/ObjectSet, apid hoge entropie hashing, extreem lage kans op botsingen, het is onmogelijk om een specifieke gebruikersingang te raden en uit te putten vanuit het toegangs domein;

• Tweede niveau Containment (beperking): Agent-ontwikkelaars gebruiken sts om ObjectSet-toegangsrechten op niveau te distribueren, zelfs als sts wordt gelekt, kan het toegangs bereik worden beperkt tot een beperkte geldigheidsduur van een bepaalde ObjectSet;

Heuristisch planningssysteem: berekening van planningsstrategieën voor miljarden domeinen

• Gedifferentieerde toegangsstrategie per gebruiker/ObjectSet:tag

• Meerdere gebruikers/ObjectSets worden automatisch verspreid over verschillende openbare netwerk ingangen, het aantal gebruikers dat wordt beïnvloed door een enkele ingangsfout is gecontroleerd

• Volledige regionale elastische planning, elke enkele ingangsfout/overbelasting voltooit automatisch de verkeersverpakking en -verplaatsing

• Gebruikers van openbare netwerk acceleratie distributie, tag openbare netwerk transmissie acceleratie, automatische planning acceleratie ingang

• Openbare netwerk risico gebruikers, tag risico, automatische planning openbare netwerk isolatie ingang, en verminder de openbare netwerk bandbreedte quota

• Interne netwerk cross-domain gebruikers, tag cross-domain, automatische planning interne netwerk speciale lijn acceleratie pad

• Lokale acceleratie gebruikers, tag acceleratie, automatisch koppelen van lokale acceleratie

Van programmeer assistent tot AI cloud disk, de onbeperkte mogelijkheden van Agent Bucket

Agent Bucket biedt een complete oplossing voor Agent, en de ontwerp toepassingsscenario's van ObjectSet gaan veel verder dan dit, het kan gemakkelijk worden uitgebreid naar alle applicaties die diensten moeten leveren aan een groot aantal eindgebruikers:

• Code repository: In het verleden, wanneer bedrijven of individuen code in de cloud hosten, moesten ze vaak een "tenant systeem" bovenop de objectopslag bouwen om account isolatie en toegangs controle te bereiken. Nu kan aan elke ontwikkelaar een exclusieve ObjectSet worden toegewezen om code repositories, build artefacten en afhankelijkheden uniform op te slaan. Agent Skills zijn ook van nature aangepast aan ObjectSet. Het uploaden, downloaden en distribueren van Skills wordt geleverd via ObjectSet met sterke isolatie om te voorkomen dat Agent runtime buren stoort.

• Enterprise fotoalbum netwerkschijf: Traditionele fotoalbums of netwerkschijf services mengen vaak de foto's van alle gebruikers in dezelfde bucket en onderscheiden gebruikers door voorvoegsels. Dit is niet alleen complex in beheer, maar ook vatbaar voor "buureffecten". Op basis van ObjectSet vallen de foto's en video's van elke gebruiker in hun eigen Set. Piektoegang interfereert niet met elkaar, en u kunt ook capaciteitslimieten, back-up strategieën en encryptie methoden instellen per gebruiker, waardoor u echt "iedereen een veilige, controleerbare cloud fotoalbum" krijgt.

• Hadoop data warehouse: In het data warehouse van een bedrijf delen verschillende business units en verschillende databases vaak resources op dezelfde onderliggende opslag. Door elke database toe te wijzen aan een ObjectSet, kunnen bedrijven isolatie en quotum controle per database realiseren bovenop uniforme opslag. Vooral ObjectSet biedt een extra machtigingslaag op TOS, die isolatie en machtigings controle biedt voor databases en tabellen die zijn opgeslagen op TOS zonder de bestaande Proton on TOS te wijzigen. - Model Hosting Platform: In scenario's voor het hosten van grote modellen is elk model niet alleen omvangrijk, maar kan het ook verschillende versies, gewichten en inferentieconfiguraties hebben. Door voor elk model een ObjectSet te maken, kunnen modelgewichten, Tokenizers, configuratiebestanden en gerelateerde evaluatiegegevens in dezelfde ruimte worden verpakt en gehost. De operationele kant kan gedifferentieerde encryptiestrategieën, back-upstrategieën en bandbreedtebeheer instellen voor verschillende modellen. Tegelijkertijd kan de werkelijke gebruikskost van elk model worden berekend via native meetmogelijkheden, wat de basis vormt voor facturering en resourceplanning op modelniveau.

• Data SaaS-service: Data-distributieplatforms die gericht zijn op een groot aantal eindgebruikers, moeten vaak verbinding maken met veel data-providers. Het is noodzakelijk om ervoor te zorgen dat de datagrenzen van elke partij duidelijk zijn en om het prestatierisico te vermijden dat "één grote emmer iedereen vertraagt". Met behulp van Agent Bucket kan elke data-provider zijn eigen ObjectSet hebben om ruwe data en verwerkingsresultaten uniform te beheren. Vervolgens kunnen onafhankelijke domeinnamen en bandbreedte- en QPS-quota worden gebruikt om gedifferentieerde servicegaranties en snelheidsbeperkingen te bieden voor verschillende providers, waardoor een data-distributie-infrastructuur wordt gerealiseerd van "één platform, meerdere providers, geïsoleerd en controleerbaar samenwerkend".

Referentie:

• https://aws.amazon.com/cn/blogs/apn/partitioning-and-isolating-multi-tenant-saas-data-with-amazon-s3/

• https://aws.amazon.com/cn/blogs/storage/design-patterns-for-multi-tenant-access-control-on-amazon-s3/