English version
Amazon S3 is object storage. That sounds simple, but it changes how you should think about data compared with block storage or file storage.
Block storage behaves like a disk volume. File storage exposes folders and files through a filesystem-like interface. Object storage stores data as objects inside buckets. The structure is flat, but key prefixes and delimiters can make it feel hierarchical.
In S3, the main units are:
- Bucket: the durable container that holds objects.
- Object: the stored file plus metadata and permissions.
- Key: the object's unique name inside the bucket.
- Tag: a key-value label used for classification, filtering, lifecycle rules, and cost/accounting workflows.
That model is useful because it scales well and keeps the application contract simple. You do not mount S3 like a normal disk. You put objects, get objects, list keys, apply policies, and design around object-level access.
How clients talk to S3
There are several common interfaces:
- AWS Management Console for manual inspection and administration.
- AWS CLI for scripts and operations.
- AWS SDKs for application code.
- REST API for direct HTTP-based object operations.
The REST API is important conceptually because S3 operations map naturally to HTTP-style actions. A client can create a bucket, upload an object, download an object, or delete an object through standard request/response flows.
A browser can also fetch an S3 object directly, but only if the object is allowed to be read anonymously or through a signed/authenticated request. Public access should be treated as an explicit security decision, not the default.
DNS and temporary redirects
S3 is distributed. A request to an S3 endpoint may be routed through DNS to a facility that can handle the request. Around bucket creation, deletion, or regional routing changes, a client may receive a temporary redirect and need to retry against another endpoint.
The practical lesson is that S3 clients should be written with retry and redirect behavior in mind. Object storage looks like a simple URL from the outside, but the service behind that URL is distributed.
Object operations
A PUT request uploads an object into a bucket. If an object with the same key already exists, the new object can overwrite the old object unless versioning or application safeguards are in place.
A single PUT is suitable for smaller objects. For large objects, multipart upload is the normal pattern. The Velog notes record the important size boundary: a single object can be up to 5TB, while large uploads should use multipart upload instead of treating the object as one giant request.
A GET request retrieves an object. If the client only needs part of an object, it can use an HTTP Range request to fetch a byte range. That matters for large objects, resumable downloads, and systems that only need a slice of a file.
A DELETE request removes an object. The result depends heavily on bucket versioning:
- Without versioning, deleting by key removes the object permanently.
- With versioning, deleting by key usually creates a delete marker.
- A versioned object can be recovered by removing the delete marker or accessing a previous version.
- Permanent deletion requires targeting the specific version.
Versioning is the safety feature that turns many accidental deletes into recoverable operations.
Data migration choices
The migration tool depends on data size, network path, and operational constraints.
Online options include S3 uploads through the CLI, SDKs, rsync-style tooling, and application-driven migration. These are good when the network path is reliable and the data size is manageable.
Offline or hybrid options include Snowcone, Snowball, Snowmobile, Direct Connect, and Storage Gateway. These make sense when datasets are too large, network transfer is too slow, or the architecture needs a hybrid bridge between local systems and AWS.
Access security
The default S3 security posture should be least privilege. A newly created bucket is not something that should be casually exposed to the internet.
Common security controls include:
- IAM users, roles, and policies.
- Bucket policies.
- Object or bucket tags used by policy conditions.
- Presigned URLs for temporary access.
- Public access block at the account or bucket level.
- Encryption settings.
- Access logging.
The practical rule is: use IAM and bucket policy for durable permissions, use presigned URLs for temporary sharing, and keep public access block enabled unless there is a clear reason not to.
Korean notes
S3를 단순히 “파일 올리는 곳”으로만 보면 중요한 차이를 놓치기 쉽다. S3는 filesystem이 아니라 object storage다.
Block storage는 disk volume처럼 생각할 수 있고, file storage는 folder/file 구조처럼 접근한다. S3는 bucket 안에 object를 저장한다. 구조는 flat하지만 key prefix와 delimiter를 사용하면 folder처럼 보이게 구성할 수 있다.
S3의 핵심 단위는 다음과 같다.
- Bucket: object를 담는 컨테이너
- Object: 실제 파일, metadata, permission을 포함한 저장 단위
- Key: bucket 안에서 object를 식별하는 이름
- Tag: 분류, 검색, lifecycle, 비용 관리에 쓰는 key-value label
Application 입장에서는 S3를 mount된 disk처럼 다루기보다 object를 put, get, list, delete하는 API로 보는 게 맞다.
S3에 접근하는 방법
S3는 여러 방식으로 다룰 수 있다.
- AWS Management Console
- AWS CLI
- AWS SDK
- REST API
REST API 관점에서 보면 S3는 HTTP request로 bucket과 object를 생성, 조회, 삭제하는 서비스다. Browser로도 object를 가져올 수 있지만, 그 object가 public read를 허용하거나 signed URL 같은 인증된 접근을 제공해야 한다.
Public access는 기본값으로 열어두는 것이 아니라 명시적으로 결정해야 하는 보안 설정이다.
DNS routing과 temporary redirect
S3는 분산된 서비스다. Client가 S3 endpoint로 요청을 보내면 DNS를 통해 요청을 처리할 수 있는 위치로 라우팅된다.
Bucket 생성이나 삭제 직후처럼 routing 정보가 바뀌는 구간에서는 요청이 임시로 다른 region/facility로 향할 수 있고, S3가 temporary redirect를 줄 수 있다. 그래서 S3 client는 retry와 redirect를 자연스럽게 처리할 수 있어야 한다.
PUT, GET, DELETE
PUT은 bucket에 object를 업로드하는 작업이다. 같은 key의 object가 이미 있으면 새 object가 기존 object를 덮어쓸 수 있다.
작은 object는 단일 PUT으로 올릴 수 있지만, 큰 object는 multipart upload를 사용하는 것이 일반적이다. S3 object 자체는 최대 5TB까지 가능하지만, 큰 파일을 하나의 요청으로 처리하려고 하면 실패와 재시도 비용이 커진다.
GET은 object를 가져오는 작업이다. 전체 object가 아니라 일부 byte range만 필요하면 Range HTTP header를 사용할 수 있다. 큰 파일 다운로드나 재시작 가능한 다운로드에서 중요하다.
DELETE는 object를 삭제하는 작업이다. Versioning이 꺼져 있으면 key를 지정한 삭제가 영구 삭제가 될 수 있다. Versioning이 켜져 있으면 delete marker가 생기고, 이전 version을 통해 복구할 수 있다.
데이터 마이그레이션
AWS로 데이터를 옮기는 방법은 data size와 network 조건에 따라 달라진다.
Online migration은 AWS CLI, SDK, rsync류 도구, application-driven upload로 처리할 수 있다. 데이터가 너무 크지 않고 network path가 안정적이면 이 방식이 간단하다.
대용량이거나 network transfer가 부담되는 경우 Snowcone, Snowball, Snowmobile 같은 offline transfer 계열을 고려할 수 있다. Hybrid 환경에서는 Direct Connect나 Storage Gateway가 더 자연스러울 수 있다.
Access security
S3 보안의 기본은 least privilege다.
자주 쓰는 제어 수단은 다음과 같다.
- IAM user, role, policy
- Bucket policy
- Tag 기반 policy condition
- Presigned URL
- Public access block
- Encryption
- Access logging
정리하면, 오래 유지되는 권한은 IAM과 bucket policy로 관리하고, 임시 공유는 presigned URL로 처리하는 것이 안전하다. Public access block은 정말 필요한 경우가 아니라면 켜두는 편이 좋다.
Summary
S3는 filesystem이 아니라 object API다. Bucket, object, key, tag, versioning, PUT/GET/DELETE, public access block을 같이 이해하면 AWS storage 설계가 훨씬 명확해진다.