- Published on
Amazon S3 Files - file system access do S3 bez kopiowania danych
- Authors

- Name
- Piotr Kołodziejczyk

AWS ogłosiło w kwietniu 2026 roku Amazon S3 Files – usługę, która pozwala korzystać z danych w S3 jak z tradycyjnego systemu plików. Bez migracji, bez kopiowania, bez nowych API. To spora zmiana w sposobie pracy ze storage'em w chmurze, szczególnie dla projektów ML i AI.
Czym jest Amazon S3 Files?
S3 Files to warstwa file systemowa zbudowana na bazie Amazon EFS, która prezentuje obiekty z bucketu S3 jako pliki w strukturze katalogów. Aplikacje mogą operować na danych używając standardowych operacji plikowych (open, read, write, ls), bez konieczności znajomości S3 API.
Kluczowe: dane nigdy nie opuszczają S3. S3 Files to tylko interfejs dostępu, nie dodatkowa kopia danych.
S3 Files vs klasyczny S3 – główne różnice
| S3 (klasyczny) | S3 Files | |
|---|---|---|
| Interfejs | REST API (GetObject, PutObject) | NFS 4.1/4.2, POSIX |
| Latencja (małe pliki) | kilkadziesiąt ms | sub-milisekunda |
| Dostęp wielu klientów | tak | tak (25 000 połączeń jednocześnie) |
| Synchronizacja | ręczna / przez aplikację | automatyczna, dwukierunkowa |
| Semantyka | obiektowa | plikowa (locking, read-after-write) |
| Duplikacja danych | wymagana przy przejściu na EFS | brak – dane zostają w S3 |
Wcześniej, jeśli chciałeś użyć frameworka ML który wymaga file systemu (np. PyTorch DataLoader), musiałeś skopiować dane z S3 na EFS lub EBS – i płacić za dwa miejsca jednocześnie. S3 Files eliminuje ten problem.
Jak to działa – inteligentny caching
S3 Files używa warstwy high-performance storage do cache'owania aktywnie używanych danych:
- Pliki < 128 KB – ładowane do szybkiej warstwy, dostępne z sub-milisekundową latencją
- Pliki ≥ 128 KB – streamowane bezpośrednio z S3 (tańsze, bez opłat za file system)
- Dane nieużywane przez skonfigurowany czas (domyślnie 30 dni, zakres 1–365 dni) są automatycznie usuwane z cache'u – ale zawsze pozostają w S3
Nie trzeba nic provisionować. Pojemność skaluje się automatycznie, płacisz tylko za aktualnie aktywne dane w cache.
Wydajność
AWS podaje następujące liczby dla S3 Files:
- 10M+ IOPS per bucket
- 4 TB/s+ aggregate read throughput
- 25 000 równoczesnych połączeń compute
To liczby, które wcześniej były zarezerwowane dla dedykowanych, drogich klastrów storage.
Przykład użycia – trening modelu ML
Typowy problem: masz 500 GB datasetu w S3, a framework ML wymaga dostępu przez file system.
Bez S3 Files:
# Kopiujesz dane na EFS lub EBS przed treningiem
aws s3 sync s3://moj-bucket/dataset/ /mnt/efs/dataset/
# Płacisz 2x za storage, synchronizacja trwa dziesiątki minut
python train.py --data /mnt/efs/dataset/
Z S3 Files:
# Montujesz S3 Files (NFS) na EC2 / EKS
sudo mount -t nfs4 fs-xxxxxxxx.efs.eu-west-1.amazonaws.com:/ /mnt/s3files
# Używasz bezpośrednio – dane są cache'owane on-demand
python train.py --data /mnt/s3files/dataset/
Dane ładują się do szybkiej warstwy w miarę potrzeby. Przy powtórnym treningu – już z cache'u.
Montowanie – wspierane środowiska
S3 Files można zamontować na:
- Amazon EC2 – przez NFS mount target
- AWS Lambda – przez EFS integration
- Amazon EKS – przez Persistent Volume (EFS CSI Driver)
- Amazon ECS – przez volumes
Każdy mount target to punkt dostępu w jednej AZ (max 1 per AZ). Dla HA – tworzysz mount targets w każdej AZ.
Bezpieczeństwo
- Szyfrowanie danych w transit: TLS (włączone domyślnie)
- Szyfrowanie at rest: AWS KMS (klucze zarządzane przez AWS lub własne CMK)
- Uprawnienia: IAM + POSIX (UID/GID) + S3 bucket policies
Dostępność i cennik
S3 Files jest Generally Available w 34 regionach AWS od kwietnia 2026, w tym eu-west-1 (Ireland) i eu-central-1 (Frankfurt).
Opłaty składają się z:
- storage w high-performance cache (za aktywne dane)
- operacje read/write do cache
- synchronizacja z S3 (import/export)
- standardowe koszty S3 GET dla dużych plików streamowanych bezpośrednio
AWS deklaruje do 90% niższe koszty w porównaniu z utrzymywaniem równoległego EFS z pełną kopią danych z S3.
Kiedy warto użyć S3 Files?
Dobrze pasuje gdy:
- masz frameworki ML/AI wymagające file systemu (PyTorch, TensorFlow, Hugging Face)
- chcesz uniknąć kopiowania danych między S3 a EFS
- potrzebujesz wielu klientów pracujących na tych samych plikach jednocześnie
- masz istniejące aplikacje używające standardowych operacji plikowych i nie chcesz ich przepisywać
Klasyczny S3 API pozostaje lepszy gdy:
- budujesz nowe aplikacje cloudowe od zera
- potrzebujesz globalnej replikacji (S3 Cross-Region Replication)
- koszty operacji S3 są kluczowe (S3 API jest tańsze dla rzadkiego dostępu)
Linki
