S3

멀티파트 업로드

단일 객체를 여러 부분의 집합으로 업로드할 수 있다.
각 부분은 객체 데이터의 연속적인 부분이며 이러한 객체 부분은 독립적으로 그리고 임의의 순서로 업로드할 수 있다.
부분의 전송이 실패할 경우 다른 부분에 영향을 주지 않고도 해당 부분을 재전송할 수 있고 객체의 모든 부분이 업로드되면 Amazon S3가 이들 부분을 수집하여 객체를 생성한다.
일반적으로 객체 크기가 100MB에 근접할 경우, 단일 작업에서 객체를 업로드하는 대신 멀티파트 업로드 사용을 고려해야 한다.

전송 가속화(Transfer Acceleration)

Amazon S3 전송 가속화는 버킷 수준 기능으로, 클라이언트와 S3 버킷 간의 장거리 파일 전송을 빠르고, 쉽게, 안전하게 할 수 있도록 한다.

전 세계에서 S3 버킷으로의 전송 속도를 최적화하도록 설계되었고 Amazon CloudFront의 전 세계적으로 분산된 엣지 로케이션을 활용한다.

데이터가 엣지 로케이션에 도착하면 데이터는 최적화된 네트워크 경로를 통해 Amazon S3로 라우팅된다.

Transfer Acceleration 필요한 상황

• 전 세계 각지에서 중앙의 버킷으로 업로드하는 고객이 있는 경우

• 전 세계에 정기적으로 수 기가바이트에서 수 테라바이트의 데이터를 전송하는 경우

• Amazon S3에 업로드할 때 인터넷을 통해 사용 가능한 대역폭을 충분히 활용할 수 없는 경우, 즉 사용자가 위치한 지역의 인터넷 인프라가 열악하거나, 네트워크 혼잡으로 인해 대역폭이 제한적인 경우에 해당한다.

장점

개선된 처리량 개선 - 부분을 병렬적으로 업로드하여 처리량을 개선할 수 있다.
네트워크 문제로부터 빠른 복구 - 더 작아진 부분 크기는 네트워크 오류로 인해 실패한 업로드 재시작의 영향을 최소화한다.
객체 업로드 일시 중지 및 재개 – 객체 부분을 장시간에 걸쳐 업로드할 수 있다. 일단 멀티파트 업로드가 시작되면 제한 시간이 없다. 멀티파트 업로드를 명시적으로 완료하거나 중단해야 한다.
최종 객체 크기를 알기 전에 업로드를 시작 – 객체를 생성하는 동안 업로드할 수 있다.

정적 호스팅

생각해보면 당연한 기능인데 예를들어 스토리지에 html파일을 올리고, 브라우저에서 버킷url로 파일에 접근하면 html이 띄워질텐데, 결국 그게 홈페이지고 호스팅이다.

다만 데이터베이스와 연계하는 즉, 동적 호스팅은 불가능하다. (ajax로 lambda를 호출해서 하는 식으로 가능은 하다 → 서버리스 구성의 기초) 따라서 정적 콘텐츠 배포는 일반적인 S3 사용과 마찬가지로 S3 버킷에 저장하기만 하면 된다.

물론 EC2에 html파일을 넣어 서버를 실행하면 똑같이 웹 사이트를 구현할 수 있다. 하지만 동적인 데이터베이스 엑세스가 없는 정적인 웹 html일 경우, S3에 넣어 호스팅하는것이 훨씬 저렴하다.
또한 수천, 수만명 사람들에게 한꺼번에 서비스 되어도 상관 없을 정도로 견고하기 때문에 따로 오토스케일링이나 로드밸런서 작업이 필요없다.
사람들이 한꺼번에 몰렸다가 빠지는 페이지를 웹서버로 호스팅 하면 그것에 대비하여 미리 서버를 사두거나 오토스케일링으로 EC2를 늘려야 하지만 S3로 호스팅 했을 경우에는 필요없다.

추가로 S3의 정적 웹 사이트에는 S3의 자체적인 도메인이 할당되는데, Route53 등의 도메인 이름 서비스(DNS)를 사용해서 다른 도메인을 부여할 수 있다.
다만, 호스팅하는 버킷 이름과 도메인 이름을 맞춰줘야 한다.
S3 도메인 구조는 http://[bucket-name].s3-website.[Region].amazonaws.com 구조인데 bucket-name 부분에 ROUTE53에서 설정한 도메인을 사용하려면 호스팅할 S3의 버킷명과 도메인 이름을 일치시켜야 한다.

Amazon S3 웹 사이트 엔드포인트는 HTTPS 또는 액세스 포인트를 지원하지 않는다.
HTTPS를 사용하려면 Amazon CloudFront를 사용하여 Amazon S3에서 호스팅되는 정적 웹 사이트를 제공할 수 있다.