AWS EFS vs EBS vs S3 (differenze e quando usare?)

Come per il titolo di questa domanda, quali sono le differenze pratiche tra AWS EFS, EBS e S3?

La mia comprensione di ciascuno:

  • S3 è una struttura di archiviazione accessibile ovunque
  • EBS è un dispositivo che puoi montare su EC2
  • EFS è un file system che puoi montare su EC2

Quindi, perché dovrei usare EBS su EFS? Sembra che abbiano gli stessi casi d’uso ma minori differenze semantiche? Sebbene EFS sia replicato attraverso le AZ in cui EBS è solo un dispositivo montato. Credo che la mia comprensione di EBS sia carente quindi non sono in grado di distinguere.

Perché scegliere S3 su EFS? Entrambi memorizzano file, ridimensionano e vengono replicati. Suppongo che con S3 sia necessario utilizzare l’SDK, dove, come con EFS, è un file system, è ansible utilizzare i metodi di I / O standard dal linguaggio di programmazione scelto per creare file. Ma è questa l’unica vera differenza?

    Una parola risposta: DENARO: D

    1 GB da memorizzare in US-East-1: (aggiornato al 2016.dec.20)

    • Ghiacciaio: $ 0,004 / mese (Nota: importante riduzione dei prezzi nel 2016)
    • S3: $ 0,023 / mese
    • S3-IA (annunciato nel 2015.09): $ 0,0125 / mese (+ $ 0,01 / addebito per riscossione)
    • EBS: $ 0,045-0,1 / mese (dipende dalla velocità – SSD o meno) + IOPS
    • EFS: $ 0,3 / mese

    Ulteriori opzioni di archiviazione, che possono essere utilizzate per memorizzare temporaneamente i dati durante / prima di elaborarli:

    • SNS
    • SQS
    • Flusso Kinesis
    • DynamoDB, SimpleDB

    I costi sopra sono solo dei campioni. Possono esserci differenze per regione e possono cambiare in qualsiasi momento. Inoltre ci sono costi aggiuntivi per il trasferimento dei dati (su Internet). Tuttavia mostrano un rapporto tra i prezzi dei servizi .

    Ci sono molte più differenze tra questi servizi:

    EFS è:

    • Generalmente disponibile (fuori dall’anteprima), ma potrebbe non essere ancora disponibile nella tua regione
    • File system di rete (significa che può avere latenza maggiore ma può essere condiviso tra più istanze, anche tra regioni)
    • È costoso rispetto a EBS (~ 10 volte di più) ma offre funzionalità extra.
    • È un servizio altamente disponibile.
    • È un servizio gestito
    • È ansible colbind la memoria EFS a un’istanza EC2
    • È ansible accedere simultaneamente a più istanze EC2
    • Dal 2016.dec.20 è ansible colbind lo storage EFS direttamente ai server on-premise tramite Direct Connect. ()

    EBS è:

    • Una memoria a blocchi (quindi è necessario formattarla). Ciò significa che puoi scegliere quale tipo di file system desideri.
    • Poiché si tratta di un archivio a blocchi, puoi utilizzare Raid 1 (o 0 o 10) con più blocchi di archiviazione
    • È molto veloce
    • È relativamente economico
    • Con i nuovi annunci di Amazon, è ansible memorizzare fino a 16 TB di dati per archiviazione su SSD-s.
    • È ansible eseguire un’istantanea di un EBS (mentre è ancora in esecuzione) per motivi di backup
    • Ma esiste solo in una particolare regione. Sebbene sia ansible migrarlo in un’altra regione, non è sufficiente accedervi da una regione all’altra (solo se la si condivide tramite EC2, ma ciò significa che si dispone di un file server)
    • Hai bisogno di un’istanza EC2 per collegarlo a
    • Nuova funzione (2017.Feb.15): ora è ansible aumentare le dimensioni del volume, regolare le prestazioni o modificare il tipo di volume mentre il volume è in uso. Puoi continuare a utilizzare la tua applicazione mentre la modifica ha effetto.

    S3 è:

    • Un archivio oggetti (non un file system).
    • Puoi archiviare file e “cartelle” ma non puoi avere serrature, permessi ecc. Come faresti con un file system tradizionale
    • Ciò significa che, per impostazione predefinita, non è ansible montare S3 e utilizzarlo come server Web
    • Ma è perfetto per la memorizzazione di immagini e video per il tuo sito web
    • Ottimo per l’archiviazione a breve termine (ad esempio alcune settimane). Va bene anche per l’archiviazione a lungo termine, ma il Glacier è più economico.
    • Ottimo per la memorizzazione dei registri
    • È ansible accedere ai dati di ogni regione (potrebbero essere applicati costi aggiuntivi)
    • Altamente disponibile, ridondante. Fondamentalmente la perdita di dati non è ansible (99,99999999% di durata, 99,9 SLA di operatività)
    • Molto più economico di EBS.
    • Puoi pubblicare il contenuto direttamente su Internet, puoi persino utilizzare un sito Web completo (statico) direttamente da S3, senza un’istanza EC2

    Il ghiacciaio è:

    • Archiviazione di archivi a lungo termine
    • Estremamente economico da conservare
    • Potenzialmente molto costoso da recuperare
    • Ti bastano fino a 4 ore per “leggere” i tuoi dati (quindi solo gli elementi del negozio che conosci non avrai bisogno di recuperare per un lungo periodo)

    Come è stato menzionato nel commento di JDL, ci sono diversi aspetti interessanti in termini di prezzi. Ad esempio Glacier, S3, EFS alloca lo storage per te in base al tuo utilizzo, mentre in EBS è necessario predefinire lo spazio di archiviazione allocato. Il che significa che hai bisogno di una stima eccessiva. (Tuttavia è facile aggiungere più spazio di archiviazione ai volumi EBS, richiede un po ‘di ingegneria, il che significa che si esegue sempre il “overpay” del proprio storage EBS, il che lo rende ancora più costoso.)

    Fonte: aggiornamento dello storage AWS : nuova opzione di storage S3 a costo inferiore e riduzione del prezzo del ghiacciaio

    Mi chiedo perché la gente non stia evidenziando la ragione PIÙ convincente a favore di EFS. EFS può essere montato su più di un’istanza EC2 allo stesso tempo, consentendo l’accesso ai file su EFS contemporaneamente.

    Correggere il confronto:

    • S3 è una struttura di archiviazione accessibile ovunque
    • EBS è un dispositivo che puoi montare su EC2
    • EFS è un file system che è ansible montare su più istanze EC2 contemporaneamente

    A questo punto è un po ‘prematuro confrontare EFS ed EBS: le prestazioni di EFS non sono note, né è nota la sua affidabilità.

    Perché dovresti usare S3?

    • Non è necessario che i file siano “locali” in una o più istanze EC2.
    • (efficace) capacità infinita
    • servizio web integrato, autenticazione

    Per aggiungere al confronto: (burst) lettura / scrittura-performance su EFS dipende dai crediti raccolti. La raccolta di crediti dipende dalla quantità di dati archiviati. Più data -> più crediti. Ciò significa che quando hai bisogno solo di qualche GB di spazio di archiviazione che viene letto o scritto spesso finirai di esaurire i crediti molto presto e througphput scende a circa 50kb / s. L’unico modo per risolvere questo problema (nel mio caso) era aggiungere file dummy di grandi dimensioni per aumentare la percentuale di crediti guadagnati. Tuttavia più spazio di archiviazione -> più costi.

    A parte il prezzo e le caratteristiche, anche il throughput varia notevolmente (come citato da user1677120):

    EBS

    Tratto da documenti EBS :

     | EBS volume | Throughput | Throughput | | type | MiB/s | dependent on.. | |------------|------------|-------------------------------| | gp2 (SSD) | 128-160 | volume size | | io1 (SSD) | 0.25-500 | IOPS (256Kib/s per IOPS) | | st1 (HDD) | 20-500 | volume size (40Mib/s per TiB) | | sc1 (HDD) | 6-250 | volume size (12Mib/s per TiB) | 

    Si noti che per io1, st1 e sc1 è ansible far scoppiare il traffico di throughput ad almeno 125 Mib / s, ma a 500 Mib / s, a seconda delle dimensioni del volume.

    È ansible aumentare ulteriormente la velocità effettiva, ad esempio distribuendo i volumi EBS come RAID0

    EFS

    Tratto da documenti EFS

     | Filesystem | Base | Burst | | Size | Throughput | Throughput | | GiB | MiB/s | MiB/s | |------------|------------|------------| | 10 | 0.5 | 100 | | 256 | 12.5 | 100 | | 512 | 25.0 | 100 | | 1024 | 50.0 | 100 | | 1536 | 75.0 | 150 | | 2048 | 100.0 | 200 | | 3072 | 150.0 | 300 | | 4096 | 200.0 | 400 | 

    Il throughput di base è garantito, il throughput burst utilizza i crediti accumulati mentre si trova al di sotto del throughput di base (in modo da avere questo per un periodo di tempo limitato, vedere qui per ulteriori dettagli.

    S3

    S3 è una cosa totalmente diversa, quindi non può essere realmente paragonata a EBS ed EFS. Inoltre: non sono disponibili metriche di throughput pubblicate per S3. Puoi migliorare il throughput scaricando in parallelo (io da qualche parte leggere gli stati AWS avresti praticamente un throughput illimitato in questo modo) o aggiungere CloudFront al mix