[Week 2] 12,13. Amazon S3 소개, 고급 Amazon S3

Jin/S3/12. Amazon S3 소개.md

@@ -0,0 +1,227 @@
+## S3 사용 용도
+1. 백업이랑 스토리지
+2. 복구용도 (region이 다운될 경우에 데이터를 다른 region으로 이동시킬것임. 이때에 백업 용도로 )
+3. 아카이브
+4. 하이브리드 클라우드 스토리지 (온프레이스 +아마존)
+5. 애플리케이션 호스팅
+6. 미디어 호스팅
+7. 데이터 저장 빅데이터 분석
+8. 소프트웨어 전달
+9. 정적 웹사이트
+> 생각보다 많음
+
+
+## buckets
+- ==버킷에는 전역에서 고유한 이름이 있어야함.== 
+	- 버킷 이름은 3~63자여야 하며 글로벌 네임스페이스 내에서 고유해야 합니다. 
+	- 버킷 이름은 문자나 숫자로 시작하고 끝나야 합니다. 
+	- 유효한 문자는 a-z, 0-9, 마침표(.), 하이픈(-)입니다. 
+- 버킷의 파일 = 객체 object 
+## object
+- key = 파일 전체의 경로
+	- 키 접두사(prefix) + object 이름
+- value는 본문 내용
+	- ==5TB가 최대임==
+	- ==5기가가 넘으면 나눠서 올림 "multi-part upload"== (100MB가 넘는 경우부터 권장)
+- 메타데이터
+- tags
+	- 보안과 수명 주기에 유용
+
+
+## 실습
+
+1. 버킷만들기
+	- General purpose로 
+	- 버킷 이름은 모든 region에서 Unique해야함. 
+	- ACLs는 보안 설정. 기본으로 두셈
+	- Block Public Access도 기본
+	- 버저닝 일단은 비활성화
+	- tag x
+	- encryption
+	- 첫번째 것
+	- 버킷키 활성화
+> 우리가 설정한것은 버킷의 이름 뿐. 나머지는 다 그냥 디폴트로 
+
+2. 만든 버킷에 이미지 업로드 해보기
+	1. open
+	2. obejct url -> 엑세스 거부
+		1. 서명된 url 
+	3. public url로 만드는법 해보겠음
+3.  폴더 생성
+
+
+
+4. public url로 만드는법 해보겠음
+	1. 버킷 정책을 만들어서 public url로 만드는법
+		1. 퍼블릭 액세스 차단(버킷 설정)
+			1. Block all public access를 체크 해제!!
+			2. 데이터 유출 문제가 걱정될 수 잇음 
+		2. 버킷 정책
+		```
+		{
+		    "Version": "2012-10-17",
+		    "Id": "Policy1746344883222",
+		    "Statement": [
+		        {
+		            "Sid": "Stmt1746344880658",
+		            "Effect": "Allow",
+		            "Principal": "*",
+		            "Action": "s3:GetObject",
+		            "Resource": "arn:aws:s3:::hi-urssu/*"
+		        }
+		    ]
+		}
+		```
+	> 그럼 이제 객체 url 클릭했을때 누구나 접근이 가능함
+
+
+
+5. static website hosting
+	- HTML이랑 이미지로 정적인 웹사이트를 호스팅 해보기
+	- public으로 허용 ~ 안하면 403
+	- index.html 파일 만들어서 올려보면 그걸로 정적 웹사이틀 잘 배포가 되어있음~
+
+## versioning
+- 버킷의 레벨을 설정
+- 의도하지 않게 삭제되는 것을 막아줌
+- 버전적용하게 되면 버전 적용 이전은 버전이 null이 됨
+
+
+1. 버저닝 실습
+	- 버전 활성화
+	- 이제 파일 덮어쓰게 되면 버전으로 관리됨
+		- show versions 활성화
+			- 버전 id 확인 가능 / ==이전 거는 null==
+	- 이전으로 rollback 할 수 있음.
+		- 특정한 버전을 지워. 그러면 이 전으로 돌아감.
+		- 되돌릴 수 없음
+			- permanently delet
+	- 삭제하는 다른 방법
+		- 버전 Id를 삭제하는게 아니라 삭제 마커를 부여해서 삭제처리를 하게 됨 
+		- delete 
+		- delete marker를 다시 지우면 복구가 됨
+
+
+## 복제 Replication
+
+비동기 
+
+- 둘다 버저닝 켜야함
+- 복제는 백그라우드에서
+- 같은 aws 계정이어야함
+- IAM에 s3 권한 주기
+
+
+CRR Cross-Region Replication 교차 리전 복제
+SRR Same-Region Replication  동일 리전 복제
+
+
+- S3 배치 replication
+- source 버킷에서 target 버킷으로 삭제 마커를 복제하면 됨
+- chaining 복제는 안됨
+	- 1번에 2번, 2번에 3번 했다고해서 1번에서 3번 복제는 안됨
+
+- 실습
+	- 버킷 두개 만들고 Source 버킷에서 `Create replication rule`
+	- IAM role도 만들어
+	- 이전 객체도 복제하려면 batch를 해야함 -> yes하면 됨. 이건 다른 기능임
+	- 기존 객체 복제 x -> no
+		- 복제 이후로 새로 올라간 파일만 생김.
+		- 복제는 한 5초~10초 정도 걸림
+		- 버전 id가 아예 같음. 
+	- Management에서 `Delete marker replication`을 활성화로 체크하면 삭제한 마커도 한 버킷에서 다른 버킷으로 복제됨!
+		- 복제되는건 삭제 그 자체가 아니라 삭제 마커임.
+## 스토리지 클래스
+
+
+종류가 많음~
+스토리지 클래스 설정 가능, 자동도 가능 생명주기
+
+
+- 내구성 Durability
+	- S3로 인해서 객체가 손실되는 횟수
+	- 대체로 내구성 아주 높은편. 10000년에 한번 예상
+	- 모든 스토리지 클래스의 내구성은 다 같음
+- 가용성 Availability
+	- 서비스가 얼마나 용이하게 제공되는지
+	- 이건 스토리지 클래스에 따라 다름
+	- 스탠다드는 99.99% 1년에 53분은 에러..
+
+
+
+### S3 standrad - general purpose
+- 99.99% 가용성
+- 기본적으로 사용하는 스토리지 유형이죠
+- 지연 시간이 짧고 처리량이 높으며
+- AWS에서 두 개의 기능 장애를 동시에 버틸 수 있습니다
+- 사용 사례
+	- 빅 데이터 분석, 모바일과 게임 애플리케이션 그리고 콘텐츠 배포가 있습니다
+
+### infrequent access (IA)
+- 자주 엑세스 하지는 않지만 필요한 경우 빠르게 엑세스 해야하는 데이터 
+- 비용이 더 작음
+- standard 보다 검색 비용이 발생
+- 가용성 99.9% standrad에 비해 조금 떨어짐 
+- 사용사례
+	- 재해 복구와 백업
+- S3 standard-IA (infrequent access)
+	- 
+- S3 one zone-IA  (infrequent access)
+	- 단일 AZ 내에서는 높은 내구성을 갖지만 AZ가 파괴된 경우 데이터를 잃게 됩니다 
+	- 가용성은 더 낮은 수준인 99.5%입니다
+	- 온프레미스 데이터를 2차 백업 할때 재생성 가능한 데이터를 저장 할때
+
+### Glacier
+- 아카이빙과 백업을 위한 저비용 객체 스토리지 
+- 비용 = 스토리지 비용 + 검색 비용
+- 3가지 클래스 
+	- Glacier Instante Retrieval (즉시 처리된다)
+		- 밀리초 단위로 검색 가능
+		- 분기에 한번 엑세스하는 데이터에 적합
+		- 최소 보관이 90일. 백업이지만 빠르게 밀리초 이내에 엑세스 해야하는 경우에 적합
+	- Glacier Flexible Retrieval (데이터를 검색하는데 최대 12시간까지 기다려야한다)
+		- 옵션
+			- expedited 1~5분내에 데이터 받을 수 있음 
+			- standard. 데이터 받는데 3~5시간
+			- bulk 무료. 데이터 돌려받는데 5~12시간
+	- Glacier deep archive 
+		- 장기보관을 위함 
+		- 티어
+			- standard 12시간
+			- bulk 48시간
+		- 데이터를 검색하는데 오래걸리긴 하지만 아주 저렴
+		- 최소 보관기간 180일
+
+
+
+### S3 intelligent tiering
+- 사용자 패턴에 따라 엑세스 된 티어 간에 객체 이동을 할 수 있게 해줌 
+- 소액의 월별 모니터링 비용, 티어링 비용이 발생하지만, 검색 비용 없음
+- 티어
+	- Frequent access: 자동. 기본 티어. 
+	- infrequent access: 30일 동안 액세스하지 않는 객체 전용 티어
+	- Archive Instant Access(optional): 자동 티어. 90일 동안 액세스하지 않는 티어 전용. 90일에서 700일 이상까지 구성할 수 있음
+	- Deep Archive Access(optional) : 180일에서 700일 이상 액세스하지 않는 객체에 구성할 수 있음 
+- S3 Intelligent Tiering은 알아서 객체를 이동시켜 주기 때문에 편하게 스토리지를 관리할 수 있어요
+
+## Class 비교 정리
+숫자를 외울 필요는 없고 그냥 각 클래스가 무엇인지만 이해
+![[Pasted image 20250504230708.png]]
+![[Pasted image 20250504230651.png]]
+- 실습
+	- 프로퍼티에서 설정 가능함.
+	- Standard: 기본으로 설정되는 것
+	- Intelligent-Tiering:  데이터에 대한 접근 패턴을 알 지 못할 때 사용하는 클래스입니다. 접근 패턴에 따라 자동으로 스토리지 티어를 정하게끔 함.
+	- Standard-IA: 접근 횟수는 적지만, 접근시의 지연 시간은 낮게 유지하고자 할 때 씁니다
+	- One Zone-IA: 재생성 가능하지만, 하나의 존에만 생성되는 객체입니다. 따라서 객체 손실의 위험성이 어느 정도 있습니다
+	- Glacier는 총 3개의 선택 사항이 있군요: Glacier Instant Retrieval, Glacier Flexible Retrieval, Glacier Deep Archive인데요. 객체가 어떤 상태일 때 사용하는지 명시가 되어 있고
+	- Reduced redundancy: S3에서는 사용하지 않는 기능으로 이에 대해서는 다루지 않습니다
+	- 
+> Standard-IA로 선택. One Zone-IA로도 바꿔봄. 결론 그냥 다양한 스토리지로 바꿔볼 수 있다~ 
+
+변경을 자동화하기? 
+Management에서 Create Lifecycle rule 
+- Apply to all objects in the bucket
+- move current verison~ 액션 중 첫번째꺼 
+- Standard-IA 로  30일 뒤에 바꾸도록 , Intelligent-Tiering로 60일 뒤로, Glacier Flexible Retrieval로 60일 뒤에 바꾸도록 설정 할 수 있음.
+> 결론) 며칠 뒤에 자동으로 00 클래스로 변경하도록 설정할 수 있음