[AWS] S3

Feedback

1. High Availability

High Availability(고가용성)은 재해 상황에서도 살아남는 어플리케이션을 만드는 것이 목적이다. 적어도 2개의 AZ를 이용하는것이 고가용성이기 때문에, 하나의 AZ가 잘 동작하지 않는다해도 나머지 하나의 AZ에서 서비스를 진행할 수 있다.

---

2. Load Balancer의 종류

Load Balancer는 traffic을 여러 EC2로 분할해서 처리하게 도와주는 수단이다. AWS는 목적에 따라 몇가지 종류가 존재한다. 크게는 Application Load Balancer와 Network Load Balancer이다. 네트워크 로드 밸런서는 낮은 지연 시간으로 초당 수백만 개의 요청을 처리할 수 있다. 이는 레이어 4에서 작동한다.

---

3. ASG의 instance 추가

Auto Scailing Group은 traffic의 상황에 따라서, 동일한 유형의 인스턴스를 추가하거 삭제할 수 있다. 다시말해, 즉석해서 instance의 유형을 변경하는 것은 불가능하다.

 

---

Amazon S3

S3는 무한 확장가능한 AWS의 main building blocks이다. 많은 웹사이트에서 S3를 backbone으로 이용하고 있으며, AWS의 Snapshot도 S3에 저장되고 있다. S3의 주요 목적은 Backup과 Storage이지만, S3에서 영상을 시청할수도 있고, 그리고 Data lake & big data analytics로도 사용할 수 있으며, 그 외의 여러 목적으로 쓰일 수 있다.

 

Buckets

S3의 핵심은 객체라는 파일이며, 객체는 버킷이라는 디렉터리에 저장된다. 버킷은 전세계에서 유일한 이름을 가져야하며, 명명 규칙이 있다. region 수준에서 정의되어야 한다.

 

Objects

 

Objects (files)는 Key를 가진다. 객체를 저장할 때는 key가 필요하며, key는 객체의 전체 경로를 나타낸다. 예를 들어, 's3://my-bucket/my_file.txt' 라고 하면 my-bucket이 버킷 이름이 되고, my_file.txt는 key가 된다. 키의 이름은 더 길어질수 있는데, 's3://my-bucket/my_folder1/another_folder/my_file.txt' 처럼 길게 표현 되면, 키는 'my_folder1/another_folder/my_file.txt'가 된다. 다시말해, 키는 접두사와 객체 이름으로 구성되는데, 바로 전의 예시에서 my_file.txt가 객체 이름이며, 앞의것들은 접두사가 된다. 이처럼, 버킷 내에는 디렉토리의 개념이 없으며, 키는 단지 슬래시를 포함한 매우 긴 이름에 불과하다.

 

객체는 어떤 형태의 content이든 포함 가능하다. 객채의 최대 사이즈는 5TB(5000GB)이지만, 5GB이상 업로드할때는 여러부분으로 나누어서 업로드하는 작업이 필요하다.

 

 

---

Amazon S3 - Security

S3의 보안은 크게 User-Based와 Resource-Based 두 부분으로 나뉜다. 전자는 IAM 사용자를 정의한 뒤, 사용자에게 IAM Policy를 부여함으로 S3 버킷에 엑세스할 수 있게 해준다. 후자는 버킷이나 객체 수준에서 누가 무엇을 할수있는지 정의하는 것을 의미한다.

 

S3 Bucket Policies

 

Bucket policies는 위와같이 JSON 형태를 가진다. Resource는 어떤 객체와 버킷에 권한이 있는지를 나타내며, Effect는 승인하는지 거부하는지를 나타내고, Action은 어떤 행위가 가능한지를 표기한다. 위에서는 객체를 얻는것이 허용되어있다. 그리고 Principal은 누구에게 적용할것인지를 표현한다. '*' 라고 기입한다면, 모두에게 적용한다는 의미이다.

 

1) Example: Public Access - Use Bucket Policy

S3 버킷 정책을 연결해서 공용 엑세스를 허용할 수 있다. 이렇게 공용 엑섹스를 허용하면 웹사이트 방문자의 접근을 허용할 수 있다. 'Block all public access'가 기본설정으로 되어있는데, 이는 기업의 데이터 유출을 막기 위한 것이다. 만약 버킷을 공용으로 바꿔서 웹사이트처럼 사용하고 싶다면 이 설정을 해제해야한다. 공용 설정을 하지않고 웹사이트로 이용하려한다면, 403 Forbidden error가 발생한다.

 

url은 아래와 같이 표현된다. 

---

2) Example: User Access to S3 - IAM permissions

IAM Policy를 사용자에게 연결해서 S3 버킷에 대한 권한을 부여할수도 있다. 이때는 IAM 정책이 있기 때문에, S3 버킷 정책이 필요하지 않다.

---

3) Example: EC2 instance access - Use IAM Roles

EC2 instance로 S3 버킷에 접근할수도 있다. EC2 IAM같은것은 존재하지 않기 때문에, EC2 instance Role을 생성한다. 이렇게 생성된 Role에 IAM Permissions를 연결하면 S3 버킷에 접근하게 허용할 수 있다.

---

4) Advanced: Cross-Account Access - Use Bucket Policy

IAM user는 AWS 계정을 여러개 소유할 수 있다. Cross-Account 를 허용하면, 사용자가 가진 모든 계정에 대해 S3 버킷 접근을 허용하도록 설정할 수 있다.

 

---

Versioning

S3에서는 버젼을 설정할 수 있는데, 이는 버킷 수준에서 사용 가능하다. 파일을 수정한다면, 그 때마다 새로운 버전이 부여된다. 새로운 버젼이 생성되면서, 이전의 버전은 계속 누적되어 기록된다 (처음 생성한다면 version null이 된다). 이렇게 기록된 버전을 이용하면, 이전 버전으로의 롤백이 가능하도록 허용할 수 있다. 이렇게 롤백을 이용하면 의도치 않은 삭제나 잘못된 수정을 방지할 수 있다. 버킷내의 객체를 삭제하는 경우라도, type이 'Delete Marker'인 객체를 삭제하게되면 삭제하기 이전 상태로 되돌릴 수 있다. 

 

---

mazon S3 - Replication (CRR & SRR)

S3의 모든 파일은 다른 버킷으로 복제가 가능하다. 이때, 다른 버킷이라함은 다른 계정의 버킷도 포함한다. 복제를 가능하게 하기 위해서는, 복제 대상과 목적지 모두 Versioning이 활성화되어 있어야 하며, 그리고 IAM Permissions에서 S3에게 복제를 할수있는 권한도 줘야한다.

 

복제는 리전간 이루어지는 Cross-Region Replication(CRR)과, 리전 내에서 이루어지는 Same-Region Replication(SRR)이 존재한다. 전자의 경우는, 미국에 있는 파일을 한국으로 복제해서 지연시간을 감소시키는 것이 예이다. 또한 CRR은 계정간 복사를 가능하게 할수도 있다. 그리고 SRR는 로그 집계를 가능하게 한다. 그리고 production 계정과 test 계정간의 실시간 복사를 해서, 다른 워크로드로 데이터를 확인하는 것이 가능하다.

 

---

S3 Encryption

S3는 세종류의 암호화가 있다. 암호화하지 않는 경우, 서버(S3)에서 암호화를 진행하는 경우, 그리고 사용자가 암호화를 하는 경우이다. 서버 암호화(Server_side Encryption)은 사용자에게 파일을 전송받은후, 자체에서 암호화를 진행한다. 이 과정을 통해 권한없이 파일이 사용되는 경우를 방지한다. 그리고 사용자 암호화 (Client_Side Encryption)은 사용자가 업로드하기 이전에 암호화 하는 것을 의미한다. 이 상태로 버킷에 업로드하면, 버킷에 업로드된 파일은 암호화된 상태이다. 

 

 

---

Storage Gateway

S3 사용자는 데이터의 일부는 on-premise에 그리고 일부는 클라우드에 저장하는 방식을 택할 수 있다. 이런 방식을 채택하는 이유는 Cloud로 이주시간이 너무 오래걸리거나, 보안 요구사항 때문이거나, 다른 여타 전략 때문일수 있다. 그리고 이를 Hybride Coloud for Storage라고 한다.

그러나, S3는 EFS와 NFS와는 달리 독립 실행형 서비스이다. 즉, on-premise에서 S3로 데이터를 직접적으로 보내지 못한다. 이 과정을 위해서는 Storage Gateway가 필요하다. Storage Gateway는 on-premise의 데이터와 Clould간의 가교역할을 한다. 즉, 온프레미스 시스템에서도 문제없이 클라우드를 이용할수있게 만들어 Storage 기능을 확장시킨다.