EFS(Elastic File System)

EFS는 Linux 기반 워크로드를 AWS 클라우드 서비스와 온프레미스 리소스에서 사용할 수 있도록 확장 가능하며 탄력적인 파일 시스템을 제공합니다.

파일 시스템을 생성하여 EC2 인스턴스에 탑재한 다음 해당 파일 시스템에서 데이터를 읽고 쓸 수 있습니다. EFS 파일 시스템을 NFS(Network File System) 버전 4.0 및 4.1(NFSv4) 프로토콜을 통해 VPC에 탑재할 수 있습니다. 스토리지 용량 필요가 증가함에 따라 파일 시스템을 확장하기 위해 조치할 필요가 없습니다.

VPC의 여러 EC2 인스턴스에서 동시에 EFS 파일 시스템에 액세스할 수 있으므로 단일 연결을 넘어 확장되는 애플리케이션이 파일 시스템에 액세스할 수 있습니다.

EFS 파일 시스템은 AWS 리전 내에서 데이터를 중복 저장하므로 우수한 가용성과 내구성이 보장됩니다. 파일 시스템의 가용성 및 내구성을 고려하여 다음과 같은 스토리지 등급을 선택할 수 있습니다.

• Standard 스토리지 등급을 선택하면 AWS 리전의 모든 가용 영역에 파일 시스템 데이터와 메타 데이터를 중복 저장하는 파일 시스템이 생성됩니다. AWS 리전의 각 가용 영역에 탑재 대상을 생성할 수도 있습니다. Standard 스토리지 등급에서는 최고 수준의 가용성과 내구성을 제공합니다.
• One Zone 스토리지 등급을 선택하면 단일 가용 영역 내에 파일 시스템 데이터와 메타 데이터를 저장하는 파일 시스템이 생성됩니다. One Zone 스토리지 등급을 사용하는 파일 시스템은 탑재 대상을 하나만 포함할 수 있습니다. 이 탑재 대상은 파일 시스템이 생성된 가용 영역에 있습니다.

EFS 이점

EFS에서 제공하는 공유 영구 계층에서는 상태 저장 애플리케이션이 탄력적으로 확장 및 축소를 수행할 수 있습니다. DevOps, 웹 서비스, 웹 콘텐츠 시스템, 미디어 처리, 기계 학습, 분석, 검색 인덱스, 상태 저장 마이크로 서비스 애플리케이션 등을 예로 들 수 있습니다. EFS는 페타바이트급 파일 시스템을 지원할 수 있으며, 파일 시스템 용량이 늘어나면 파일 시스템 처리량도 높아집니다.

EFS는 서버리스 방식이므로 인프라나 용량을  프로비저닝 또는 관리할 필요가 없습니다. 유형에 관계없이 최대 수만 개의 동시 클라이언트가 EFS 파일 시스템을 공유할 수 있습니다. 이러한 클라이언트는 기존 EC2 인스턴스일 수도 있고 셀프 매니지드 클러스터 중 하나에서 싱행되는 컨테이너일 수도 있습니다.

클라이언트는 AWS 컨테이너 서비스인 ECS(Elastic Container Service), EKS(Elastic Kubernetes Service), Fargate 중 하나에서 실행될 수도 있고 Lambda에서 실행되는 서버리스 함수에서 실행될 수도 있습니다.

EFS를 사용하면 공유 파일 스토리지의 총 소유 비용을 줄일 수 있습니다. 여러 가용 영역에 복제하지 않아도 되는 데이터는 EFS One Zone을 선택하면 스토리지 비용을 절약할 수 있습니다. 매일 액세스하지 않는 파일용 스토리지 등급인 EFS Standarrd-IA(EFS Standard-Infrequent Access)는 이러한 파일의 비용 측면에서 최적화된 가격과 성능을 제공합니다.

EFS 크기 조정 및 자동화 기능을 사용하면 관리 비용을 절약할 수 있으며 실제 사용한 만큼만 요금을 지불하면 됩니다.

FSx

FSx 사용 시에는 다양한 기능을 제공하는 고성능 파일 시스템을 빠르게 시작하고 실행할 수 있습니다. 이 서비스에서는 4개 파일 시스템 중 선택할 수 있습니다. 사용법을 가장 잘 알고 있는 파일 시스템을 선택할 수도 있고 요구에 맞는 기능 세트, 성능 프로파일, 데이터 관리 기능을 제공하는 파일 시스템을 선택할 수도 있습니다.

1. FSx for Windows File  Server
   네이티브 Windows 파일 시스템이 지원하지 않는 완전관리형 Microsoft Windows 파일 서버를 제공합니다. Windows Server에 구축되는 FSx에서는 데이터 중복 제거, 최종 사용자 파일 복원, Microsoft Active Directory와 같은 광범위한 관리 기능을 제공합니다.
   
   
2. FSx for Lustre
   비용 효율적인 고성능 스토리지를 제공하는 완전관리형 서비스입니다. Amazon Linux, Amazon Linux 2, Red Hat Enterprise Linux(RHEL), CentOS, SUSE Linux, Ubuntu 등의 널리 상요되는 대다수 Linux 기반 AMI와 호환됩니다.
3. FSx for NETapp ONTAP
   AWS 클라우드에서 완전관리형 공유 스토리지를 제공합니다. 해당 스토리지에는 ONTAP에서 많이 사용되는 데이터 액세스 및 관리 기능이 포함되어 있습니다.
   
   
4. FSx for OpenZFS
   완전 관리형 공유 파일 스토리지를 제공합니다. OpenZFS 파일 시스템을 기반으로 구축된 이 스토리지는 AWS Graviton 프로세서 패밀리를 통해 구동되며, NFS 프로토콜(v3, v4, v4.1, v4.2)을 통해 액세스 가능합니다.

자세한 내용

S3 멀티 파트 업로드

멀티 파트 업로드를 사용하면 대용량 객체를 관리 가능한 수준의 파트로 분할하여 일관되게 업로드할 수 있습니다. 이 프로세스에서는 다음 세 단계를 수행합니다.

1. 업로스 시작
2. 객체 파트 업로드
3. 멀티 파트 업로드 완료

멀티 파트 업로드 요청이 완료되면 S3에서 개별 부분으로 전체 객체를 재생성합니다. 다음 기능을 활용해 대형 객체 업로드 프로세스를 개선할 수 있습니다.

• 처리량 개선 - 파트를 병렬로 업로드하여 처리량을 개선할 수 있습니다.
• 네트워크 문제로부터 빠른 복구 - 더 작은 파트 크기가 네트워크 오류로 인해 실패한 업로드의 재시작 시 영향을 최소화합니다.
• 객체 업로드 일시 중지 및 재개 - 객체 파트를 장시간에 걸쳐 업로드할 수 있습니다. 시작한 멀티 파트 업로드는 만료되지 않습니다. 멀티파트 업로드를 명시적으로 완료하거나 취소해야 합니다.
• 최종 객체 크기를 알기 전에 업로드 시작 - 객체를 생성하는 동안 업로드할 수 있습니다.
• 대용량 객체를 업로드 - 멀티파트 업로드 API를 사용해 최대 5TB 크기의 대용량 객체를 업로드할 수 있습니다.

* 콘솔을 통해 멀티 파트 업로드를 수동으로 진행할 수는 없습니다.

상세한 내용

S3 Transfer Acceleration

전 세계에 배포된 AWS 엣지 로케이션을 통해 S3 Transfer Acceleration에서는 S3 버킷으로 데이터를 빠르고 쉽게 전송할 수 있습니다. 데이터는 최적화된 네트워크 경로를 통해 S3로 라우팅됩니다.

다음과 같은 경우에 Transfer Acceleration을 사용합니다.

1. 전 세계 고객이 중앙 버킷에 데이터를 업로드하는 경우
2. GB ~ TB 단위 데이터를 대륙 간에 정기적으로 전송하는 경우
3. 인터넷을 통해 S3에 데이터를 업로드할 때 사용 가능한 대역폭을 모두 활용하지 않는 경우

S3 Transfer Acceleration에서는 AWS 서버와 클라이언트 애플리케이션 간 거리를 줄일 수 있습니다. 전 세계에 분산된 수백 개의 엣지 로케이션 네트워크를 사용하기 떄문입니다. AWS는 애플리케이션과 가장 가까운 엣지 로케이션을 통해 업로드와 다운로드를 자동으로 라우팅합니다.

이를 S3 Transfer Acceleration Speed Comparison 도구를 사용하여 S3 리전의 가속 적용 업로드 속도와 가속 미적용 업로드 속도를 비교할 수 있습니다.

자세한 내용

S3 이벤트 알림

S3 이벤트 알림을 사용하면 버킷에서 특정 객체 이벤트가 발생할 때 알림을 받을 수 있습니다. 이러한 이벤트 중심 모델에서는 더 이상 객체 변경 사항을 확인하기 위해 서버 기반 폴링 인프라를 구축하거나 유지 관리할 필요가 없습니다. 그리고 처리할 변경 사항이 없을 때는 해당 인프라의 유휴 시간에 대한 요금을 지불하지 않아도 됩니다.

S3는 다음 대상 위치로 이벤트 알림 메시지를 전송할 수 있습니다.

• Simple Notification Service(SNS) 주제
• Simple Queue Service(SQS) 대기열
• lambda 함수

알림 구성에서 이러한 대상 위치의 ARN(Amazon Resource Name) 값을 지정해야 합니다.

위 이미지에서 웹 사이트가 사용하는 이미지 버킷에 JPEG 이미지를 업로드합니다. 웹 사이트는 업로드하는 각 파일의 작은 썸네일 미리보기 이미지를 전송할 수 있어야 한다고 가정하겠습니다. S3 버킷에 이미지 객체를 업로드하면 이벤트 알림이 전송되어 일련의 AWS Lambda 함수가 호출됩니다. 함수 실행이 완료되면 썸네일 버킷에 객체가 추가됩니다. S3 이벤트 알림이 버킷의 활동을 관리하며 썸네일을 자동으로 생성합니다.

• Lambda 함수의 출력은 원래 JPEG 이미지의 작은 버전입니다. 

자세한 내용

S3 비용 관련 요인

S3에서 고려해야 하는 몇 가지 비용 관련 요인은 다음과 같습니다.

• 스토리지
  객체 저장 시에 발생하는 GB당 비용을 고려해야 합니다. S3 버킷에서는 객체 저장 요금을 지불해야합니다. 부과되는 요금은 객체 크기, 월별 객체 저장 기간 및 스토리지 등급에 따라 달라집니다. PUT, COPY 또는 수명 주기 규측을 사용하여 S3 스토리지 등급으로 데이터를 이동할 때는 요청당 수집 요금이 부과됩니다.
  
  
• 요청 및 검색
  API 호출(PUT 및 GET 요청)의 수를 고려합니다. S3 버킷 및 객체를 대상으로 이루어지는 요청에 대한 요금을 지불합니다. S3 요청 비용은 요청 유형을 기준으로 책정되며 요청의 양에 따라 부과됩니다. S3 콘솔을 사용하여 스토리지를 검색하면 GET, LIST 및 원활한 검색을 위해 실행하는 기타 요청에 대한 요금이 부과됩니다.
  
  
• 데이터 전송
  일반적으로 인터넷으로부터의 데이터 수신에는 전송 요금이 부과되지 않습니다. 요청자의 롤케이션과 데이터 전송 매체에 따라 뎅터 송신에는 각기 다른 요금이 부과될 수 있습니다.
  
  
• 관리 및 분석
  계정 버킷에서 활성화하는 스토리지 관리 기능 및 분석에 대한 비용을 지불해야 합니다. 이 교육 ㄱ ㅘ정에서는 이러한 기능에 대해 자세히 설명하는 않습니다.
  
  
• 복제 및 버전 관리
  해당 서비스 사용 시 AWS 결제 금액이 크게 늘어날 수 있습니다. 이러한 서비스는 객체 복사본을 여러 개 생성하므로 스토리지 티어 요금 외에 각 PUT 요청 요금도 지불해야 합니다. S3 교차 리전 복제 사용 시에도 AWS 리전 간에 데이터를 전송해야 합니다.

S3 비용 상세

S3 버전 관리

S3는 객체 스토리지가 사용됩니다. 그러므로 파일의 일부를 변경하려면 변경한 다음 수정된 파일 전체를 다시 업로드 해야합니다. 하지만 버전 관리를 사용하는 버킷에서는 실수로 삭제하거나 덮어쓴 객체를 복구할 수 있습니다.

• S3에서는 삭제된 객체가 영구적으로 제거되지 않으며 삭제 마커가 삽입됩니다. 그러면 해당 객체가 현재 객체 버전이 됩니다.
• 객체를 덮어쓰면 버킷에 새 객체 버전이 생성됩니다.

S3 버전 관리를 활성화하면 잘못 변경한 객체의 이전 버전을 쉽게 복원할 수 있습니다. 버전 관리를 사용하는 버킷에서는 각 버전의 ID가 부여됩니다. 특정 버전을 영구 삭제하기 위해서는 DELETE Object versionld을 사용해 삭제하고자 하는 버전 ID를 삭제합니다.

데이터 보존 또는 보호를 위해 S3 객체 잠금을 사용할 수 있습니다. WORM(Write Once, Read Many) 모델을 사용하면 S3 스토리지 내에서 실수로 덮어쓰거나 삭제하는 일을 방지할 수 있습니다. 객체를 일정 기간 동안 잠그려면 보존 기간을 사용하고 명시적으로 제거할 때까지 잠그려면 법적 보존을 사용하면 됩니다.

버전 관리 상세 / 객체 잠금 상세

수명 주기 정책

S3 수명 주기 정책을 사용해 생성 후 기간을 기준으로 객체를 삭제 또는 이동할 수 있습니다. S3에 저장된 데이터의 숨여 주기를 자동화해야 합니다. S3 수명 주기 정책을 사용하면 다양한 S3 스토리지 유형 간에 데이터가 주기적으로 순환되도록 할 수 있습니다.

이러한 방식을 통해 시간이 지나면서 데이터의 중요도가 감소하면 비용을 더 적게 지불함으로써 전체 비용을 줄일 수 있습니다. 객체별로 수명 주기 규칙을 설정할 수도 있습니다. 또한, S3는 스토리지 등급 간 전환을 위한 폭포형 모델을 지원합니다. 수명 주기 구성은 데이터 스토리지 티어를 자동으로 변경합니다.

예시: S3 standard 객체 생성 > 30일 후 S3 Standard-IA로 이동 > 365일 이상 오래된 객체는 S3 Glacier Deep Archive로 이동

S3 수명 주기 / 스토리지 수명 주기 관리

S3 객체 복제

S3를 사용하면 고객은 모든 AWS 리전에서 데이터에 대한 높은 수준의 가용성 및 내성을 확보할 수 있습니다. 모든 S3 스토리지 등급에 저장된 데이터는 최소 3개 가용 영역에 걸쳐 저장됩니다. 각 가용 영역은 리전 내에서 몇 킬로미터 이상 떨어져 있습니다. 이 때문에 많이 AWSA 고객이 비즈니스 크리티컬 데이터와 애플리케이션 크리티컬 데이터를 S3에 저장하고 있습니다. 유일한 예외는 S3 One Zone-IA로, 이름처럼 단일 영역에서 제공되는 서비스입니다.

복제 시에는 다음과 같은 테스크를 수행할 수 있습니다.

• 메타데이터를 유지하면서 객체 복제 - 필요한 경우 소스 객체와 동일한 복제본을 생성할 수 있습니다.
• 여러 스토리지 등급에 객체 복제 - 복제 기능을 사용해 S3 Glacier Flexible Retrieval, S3 Glacier Deep Archive 또는 대상 버킷의 기타 스토리지 등급에 객체를 직접 추가할 수 있습니다.
• 소유권이 서로 다른 객체 복사본 유지 - 대상 버킷을 소유한 AWS 계정으로 복제본 소유권을 변경하도록 S3에 지시할 수 있습니다.
• 여러 AWS 리전에 저장된 객체 유지 - 다른 AWS 리전으로 데이터를 복제하여 규정 준수 요구 사항을 충족할 수 있습니다.

상세 내용

S3 스토리지 클래스

S3의 각 객체에는 객체와 연결된 스토리지 등급이 있습니다. 모든 스토리지는 99.999999999% 내구성을 보장합니다. 사용 사례 시나리오와 성능 액세스 요구 사항에 따라 등급을 선택해 사용할 수 있습니다.

• S3 Standard: 자주 액세스하는 데이터의 일반적인 스토리지용
• S3 Standard-IA(Infrequent Access): 장시간 사용하며 액세스 빈도는 낮은 데이터용
• S3 One Zone-IA: 장기간 사용하고 액세스 빈도가 낮으며 가용 영역 하나에 저장할 수 있는 데이터용
• S3 Glacier Instant Retrieval: 거의 액세스 하지 않지만 복원 시간은 밀리초 단위여야 하는 아카이브 데이터용
• S3 Glacier Flexible Retrieval: 합리적인 비용에 가장 유동적인 검색 옵션을 제공하며 액세스 시간은 몇 분 ~ 몇 시간 범위 서비스 제공 및 여러 Retrieval 옵션 제공
  • 신속 검색: 1~5분 내에 복원
  • 표준 검색: 3~5시간 내에 복원
  • 대량 검색: 5~12시간 내에 복원 및 추가 요금 없이 이용 가능
    (* Retrieval = 저렴한 정액제 스토리지 요금으로 필요할 때 모든 아카이브에 액세스할 수 있습니다.)
• S3 Glacier Deep Archive: 장기간 보관해야 하는 스토리지 아카이브와 디지털 컨텐츠 보존용으로 12시간 이내 객체 복원 가능
• S3 Intelligent-Tiering: 액세스 패턴이 바뀌거나 알 수 없는 데이터에 유동적으로 활용가능한 추가 스토리지 등급으로, 이 등급에서는 스토리지 등급 간에 객체를 자동으로 이동함으로써 비용을 최소화할 수 있습니다.
• S3 on Outposts: 온프레미스 AWS Outposts 환경에 객체 스토리지를 제공

S3 요금 자세한 내용

S3 Intelligent-Tiering

S3 Intelligent-Tiering은 성능에 영향을 주지 않고 데이터 액세스 패턴이 변경될 때 자동으로 스토리지 비용을 절감할 수 있는 유일한 스토리지 등급니다. 이 스토리지 등급에서는 사용 패턴 변화에 따라 데이터가 액세스 티어 간에 이동합니다.

1. Intelligent-Tiering에 객체를 할당하면 Frequent Access 티어에 배치됩니다. 이 티어의 스토리지 비용은 S3 Standard와 동일합니다.
2. 30일 동안 액세스하지 않은 객체는 Infrequent Access 티어로 이동합니다. 이 티어의 스토리지 비용은 S3 Standard-IA와 동일합니다.
3. 90일 동안 액세스하지 않은 객체는 Archive Instant Access 티어로 이동합니다. 이 티어의 비용은 S3 glacier Instant Retrieval과 동일합니다.

S3 Intelligent-Tiering은 객체 크기나 보존 기간에 관계없이 액세스  패턴이 확인되지 않았거나 계속 변경되거나 예측할 수 없는 데이터에 적합한 스토리지 등급입니다. 이 스토리지는 사실상 모든 워크로드(특히 데이터 레이크, 데이터 분석, 새 어플리케이션 및 사용자 생성 콘텐츠)의 기본 스토리지 등급으로 사용할 수 있습니다.

S3 Glacier 스토리지 클래스의 장점

1. 비용 효율적 스토리지
   매우 저렴하고 우수한 성능과 유연성을 보장하는 데이터 스토리지 솔루션을 제공합니다. Glacier에서는 아카이브된 데이터용 목적별 스토리지가 제공됩니다.
   
   
2. 유동적인 데이터 검색
   세 가지 스토리지 등급 옵션 중에서 검색해야 하는 데이터와 검색 속도에 맞는 옵션을 선택하면 비용을 최적화할 수 있습니다.
   
   
3. 보안 및 규정 준수
   Glacier의 데이터는 저장 시에 암호화할 수 있습니다. 또한 AWS CloudTrail를 통해 규정 준수, 감사 로깅, 비용 관리 등의 기능 집합도 제공됩니다. 기존 아카이빙 솔루션에서는 이러한 기능이 제공되지 않을 수 있습니다.
   
   
4. 확장성과 내구성
   다른 S3 스토리지와 마찬가지로 데이터의 양(GB~EB)에 따라 유동적으로 크기를 조정할 수 있고, 내구성 99.999999999%를 보장합니다. 이 수치는 천만년 동안 객체 1만개 중 1개가 손실된다는 의미입니다.

S3 Glacier 스토리지 등급 자세한 내용

S3 액세스 제어

기본적으로 버킷, 객체, 관련 리소스 등의 모든 S3 리소스(예_ 수명주기, 웹사이트 구성 등)는 프라이빗으로 설정됩니다. 리소스 소유자는 액세스 정책을 작성하여 다른 사용자에게 액세스 권한을 부여할 수 있습니다.

S3의 특정 리소스를 퍼블릭으로 설정할 수 있습니다. 그러면 누구나 해당 리소스에 액세스할 수 있겍 됩니다. 그러나 대부분의 S3 사용 사례에서는 퍼블릭 액세스 권한이 필요하지 않습니다. S3는 대개 다른 애플리케이션의 데이터를 저장합니다.  이러한 유형의 버킷에는 퍼블릭 액세스를 사용하지 않는 것이 좋습니다. S3에는 퍼블릭 액세스 차단 기능이 포함되어 있습니다. 이 기능은 실수로 인한 고객 데이터 노출을 방지하기 위해 추가 보 호 계층 역할을 합니다.

리소스 소유자는 리소스에 대해 제어 간으한 액세스 권한을 제공할 수 있습니다. 액세스 정책을 작성하여 다른 사용자에게 액세스 권한을 부여할 수 있습니다.

자세한 내용

버킷 정책

버킷 정책을 작성 및 구성하여 S3 버킷과 객체에 대한 권한을 부여할 수 있습니다. 버킷 정책은 S3 버킷용 리소스 기반 정책입니다. IAM 정책, S3 버킷 정책, AWS Organiztions 서비스 제어 정책(SCP)등의 정책을 기반으로 데이터 액세스를 제어합니다.

JSON 기반 액세스 정책 언어를 사용해 버킷 정책을 작성합니다. 버킷 정책을 사용하면 버킷의 객체에 대한 권한을 추가하거나 거부할 수 있습니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
        }
    ]
}

위 예시는 버킷 정책을 JSON 형식으로 표현한 것입니다. 이 버킷 정책은 모든 보안 주체가 버킷을 나열하고 버킷에서 객체를 가져올 수 있도록 허용되어 있습니다. 하지만 이런 방식의 버킷과 객체에 대한 퍼블릭 액세스는 제한해야 합니다. S3에는 이와 같이 액세스를 지나치게 허용하는 퍼블릭 버킷 생성을 방지할 수 있는 도구가 포함되어 있습니다.

S3 퍼블릭 액세스 차단

경우에 따라 버킷에 퍼블릭 액세스가 절대 없도록 해야할 수 있습니다. 새로 생성된 S3 버킷과 객체는 기본적으로 비공개이며 보호되고 있습니다. S3 액세스 제어를 사용해 ACL, 버킷 정책 및 교차 오리진 리소스 공유(CORS) 설정에 의한 모든 버킷 액세스를 차단할 수 있습니다.

ACL이나 버킷 정책 중 하나 또는 두 가지를 모두 사용하여 버킷과 객체에 대한 퍼블릭 액세스 권한을 부여합니다. 모든 S3 버킷과 객체에 대한 퍼블릭 액세스를 방지하려면 계정 수준에서 모든 퍼블릭 액세스 차단을 활성화합니다. 이러한 설정은 계정 전체에서 현재 버킷과 앞으로 생성하는 버킷에 적용됩니다.

 S3 퍼블릭 액세스 차단 설정을 사용하면 정보 유출로부터 본인과 조직을 보호할 수 있습니다. 이 설정을 활성화하면 운영자가 실수로 버킷을 퍼블릭으로 설정해 공개하는 상황을 방지할 수 있습니다.

S3에서 차단되는 퍼블릭 액세스 유형

• 새  ACL을 통해 부여된 버킷 및 객체에 대한 액세스 권한
• 모든 ACL을 통해 부여된 버킷과 객체에 대한 액세스 권한
• 새 퍼블릭 버킷이나 액세스 포인트 정책을 통해 부여된 버킷과 객체에 대한 액세스 권한
• 모든 퍼블릭 버킷이나 액세스 포인트 정책을 통해 적용되는 버킷과 객체에 대한 교차 계정 액세스 권한

ACL(Access Control List)
컴퓨터 네트워크에서 특정 사용자 또는 그룹에 대한 액세스 권한을 제어하는 목적으로 사용되는 목록입니다. ACL은 일반적으로 IP 주소, 포트 번호, 프로토콜과 같은 요소를 기반으로 작성되며, 해당 요건을 충족하는 사용자 또는 그룹은 네트워크 리소스에 대한 액세스 권한을 갖게 됩니다.

ACL은 네트워크 보안을 강화하고 네트워크 리소스를 보호하는 데 중요한 역할을 합니다. 예를 들어, 특정 IP 주소에서만 특정 웹 사이트에 액세스할 수 있도록 허용하는 ACL을 생성할 수 있습니다. 또한, 특정 포트 번호에서만 특정 서비스에 액세스할 수 있도록 허용하는 ACL을 생성할 수도 있습니다.

ACL은 네트워크 보안을 강화하는 데 매우 효과적인 도구이지만, ACL을 잘못 설정하면 네트워크 보안을 오히려 약화시킬 수 있습니다. 따라서 ACL을 설정할 때는 신중하게 고려해야 합니다.

S3 액세스 포인트

S3 액세스 포인트를 활용하면 S3의 공유 데이터 집합에서 데이터 액세스를 대규모로 간편하게 관리할 수 있습니다. S3 액세스 포인트는 GetObject, PutObject 등의 S3 객체 작업을 수행한느 데 사용할 수 있는 명명된 네트워크 엔드포인트입니다. 액세스 포인트는 버킷에 연결됩니다. 각 액세스포인트는 해당 액세스 포인트를 통해 이루어진 요청에 대해 S3가 적용하고 고유한 구너한 및 네트워크 제어가 있습니다.

위 그림에서 재무 팀 IAM 역할을 수임한 재무 담당 직원이 재무 액세스 포인트에 GetObject 요청을 전송합니다. 액세스 포인트 정책을 적용하면 재무 담당 역할이 doc-example-bucket에서 접두가 /finance 및 /tax인 객체를 가져올 수 있습니다. 이 재무 담당 역할은 접두사가 sales, marketing인 객체나 S3 버킷의 기타 객체에는 액세스할 수 없습니다. 즉, S3 버킷 정책을 적용하여 각 사용자가 필요한 만큼만 액세스를 허용할 수 있습니다.

각 액세스 포인트는 사용자 정의된 액세스 포인트 정책을 적용합니다. 이 정책은 기본 버킷에 연결된 버킷 정책과 동시에 적용됩니다. S3 데이터 액세스를 프라이빗 네트워크로 제한하려는 경우 VPC의 요청만 수락하도록 액세스 포인트를 구성하면 됩니다. 각 액세스 포인트를 대상으로 사용자 정의 퍼블릭 액세스 차단 설정을 구성할 수도 있습니다.

액세스 포인트는 객체에서 작업을 수행할 때만 사용 가능합니다. 액세스 포인트를 사용하여 버킷 수정이나 삭제 등의 기타 S3 작업을 수행할 수 는 없습니다. S3 액세스 포인트는 일부 AWS 서비스 및 기능에서만 함께 사용할 수 있습니다. 예를 들어, S3 교차 리전 복제가 액세스 포인트를 통해 작동하도록 구성할 수는 없습니다.

서버 측 암호화 키 유형

암호화 키를 사용하여 저장 데이터를 암호화합니다. S3에서는 3 가지 객체 암호화 옵션이 제공됩니다.

1. S3 관리형 키(SSE-S3)를 사용하는 서버 측 암호화(SSE)
   SSE-S3를 사용하는 경우 각 객체가 고유 키로 암호화됩니다. 추가적인 보안 조치로, 주기적으로 교체되는 기본 키를 사용하여 키 자체를 암호화합니다. S3 서버 측 암호화는 AES-256(256비트 Advenced Encryption Standard)를 사용하여 데이터를 암호화합니다.
2. AWS Key Management Service(AWS KMS)에 저장된 AWS KMS 키(SSE-KMS)를 사용하는 서버 측 암호화
   SSE-KMS에 저장된 KMS 키는 SSE-S3와 비슷하지만 몇 가지 추가 이점이 제공되며 관련 요금이 청구됩니다. KMS 키 사용 시에는 별도의 권한이 있어야 합니다. 그러므로 S3 객체 무단 액세스를 더욱 철저하게 방어할 수 있습니다.
   
   
3. 고객 제공 키(SSE-C)를 사용하는 서버측 암호화
   SSE-C 사용 시에는 사용자가 암호화 키를 관리하고 S3는 디스크에 쓰는 데이터의 암호화를 관리합니다. 또한 S3는 사용자가 객체에 액세스할 때 복호화를 관리합니다.

SSE(Server-Side Encryption)
서버 측 암호화는 데이터를 저장하는 서버에서 데이터를 암호화하는 기술입니다. 서버 측 암호화를 사용하면 데이터가 전송 중 또는 저장 중일 때에도 악의적인 공격으로부터 보호할 수 있습니다.

암호화와 복호화
암호화는 데이터를 숨기는 것입니다. 복호화는 암호화된 데이터를 원래의 데이터로 되돌리는 것입니다. 암호화와 복호화는 모두 암호화 키를 사용합니다. 암호화 키는 데이터를 암호화하고 복호화하는 데 사용되는 고유한 문자열입니다. 암호화 키는 안전하게 보관되어야 합니다. 암호화 키가 유출되면 누구나 암호화된 데이터를 복호화할 수 있습니다.

클라우드 스토리지

1. 블록 스토리지
   데이터 베이스 또는 전사적 자원 관리(ERP) 시스템과 같은 기타 엔터프라이즈 애플리케이션은 호스트별로 대기 시간이 짧은 정용 스토리지가 필요한 경우가 많습니다. 이러한 스토리지는 직업 연결 스토리지(DAS) 또는 스토리지 영역 기반 네트워크(SAN)과 유사합니다. EBS(Elastic Block Store)같은 블록 기반 클라우드 스토리지 솔루션은 개별 가상 서버로 함께 프로비저닝되기 때문에 고성능 워크로드에 필요한 엄청나게 짧은 대기 시간을 제공합니다.
   
   예시: EBS(Elastic Block Store)
   
   
2. 파일 스토리지
   대부분 애플리케이션은 공유 파일에 액세스해야 하며, 파일 시스템이 있어야 합니다. 이러한 유형의 스토리지는 NAS(Network Attached Storage) 서버에서 주로 지원합니다. EFS(Elastic File System)과 같은 파일 스토리지 솔류션은 대규모 콘텐츠 리포지토리, 개발 환경, 미디어 스토어 또는 사용자 홈 디렉터리 등과 같은 사용 사례에 적합합니다.
   
   예시: EFS(Elastic File System), FSx
   
   
3. 객체 스토리지
   클라우드에서 개발된 애플리케이션은 객체 스토리지의 방대한 확장성 및 메타데이터가 필요합니다. S3 같은 객체 스토리지 솔루션은 현대적 애플리케이션을 빌드하는 데 이상적입니다. S3는 확장성과 유연성을 제공합니다. 분석, 백업 또는 아카이빙을 위해 기존 데이터 스토어를 가져오는 데 사용할 수 있습니다.
   
   예시: S3(Simple Storage Service), S3 Glacler

S3(Simple Storage Service)

S3는 객체 수준 스토리지입니다. 객체에는 파일 데이터, 메타데이터, 고유 식별자가 포함됩니다. 객체 스토리지에는 기존의 파일 및 폴더 구조가 사용되지 않습니다.

파일 데이터와 메타 데이터?
파일 데이터는 컴퓨터 파일에 저장된 데이터입니다. 파일 데이터는 텍스트, 이미지, 비디오, 오디오 등 다양한 형식으로 저장될 수 있습니다. 파일 데이터는 컴퓨터 프로그램에서 처리되거나 사용자에게 표시될 수 있습니다.

메타 데이터는 파일 데이터에 대한 정보를 저장하는 데이터입니다. 메타 데이터는 파일의 이름, 크기, 생성 날짜, 저자, 태그 등과 같은 정보를 포함할 수 있습니다. 메타 데이터는 파일 데이터를 검색, 정리 및 관리하는 데 사용됩니다.

모든 S3 스토리지 티어는 객체에 대해 연중 99.999999999%(9-11개)의 데이터 내구성을 제공하도록 설계되었습니다. 기본적으로 S3 에서 데이터는 여러 시설과 각 시설의 여러 디바이스에 중복으로 저장됩니다. S3는 웹 기반 AWS 관리 콘솔을 통해, API 및 SDK를 통해 프로그래밍 방식으로 또는 API 및 SDK를 사용하는 서드 파티 솔루션을 통해 액세스할 수 있습니다.

S3 활용 방안

• 신속한 혁신 추진 - S3 버킷을 정적 파일용 스토리지 솔루션으로 통합하면 기존 파일 시스템에 대한 의존도를 줄일 수 있습니다.
• 민첩성 향상 - 객체 스토리지를 호스트하면 데이터의 양과 크기가 늘어나도 스토리지를 확장할 필요가 없습니다. 개별 객체의 크기는 5TB를 초과할 수 없지만 총 데이터 양은 필요한 만큼 저장할 수 있습니다.
• 비용 절감 - S3 의 다양한 스토리지 티어를 사용하면 액세스 빈도가 낮은 데이터의 비용을 줄일 수 있습니다. 장기 저장해야 하는 데이터는 S3에 아카이브 하면됩니다.
• 보안 강화 - 데이터를 S3에 저장하면 암호화 기능과 액세스 관리 도구를 통해 무단 액세스로부터 데이터를 보호할 수 있습니다. S3에서는 지불 카드 보안 표준(PCI-DSS), HIPAA/HITECH, FedRAMP, EU 데이터 보안지침, FISMA 등과 같은 규정 준스를 위한 프로그램이 운영됩니다. 이러한 규정 준수 프로그램을 통해 규정 관련 요구 사항을 쉽게 충족할 수 있습니다.

S3 사용 사례

1. 백업 및 복원
   S3를 사용해 언제든지 원하는 양의 데이터를 저장핳고 검색할 수 있습니다. S3를 애플리케이션 데이터 및 파일 수준 백업 및 복원 프로세스를 위한 내구성이 우수한 저장소로 사용할 수 있습니다. S3는 9-11을 보장하도록 설개되었습니다.
   
   
2. 분석용 데이터 레이크
   빅 데이터 분석, AI, 기계 학습, 고성능 컴퓨팅(HPC) 애플리케이션을 실행하여 데이터 인사이트를 파악할 수 있습니다.
   
   
3. 미디어 저장 및 스트리밍
   S3를 CloudFront 엣지 로케이션과 함께 활용하면 안전하고 확장이 가능한 방식으로 온디맨드 비디오를 호스트할 수 있습니다. 온디맨드 비디오(VOD) 스트리밍은 비디오 콘텐츠가 서버에 저장되고 싲청자가 언제든지 시청할 수 있는 방식입니다.
   
   
4. 정적 웹 사이트
   S3를 사용해 정적 웹 사이트를 호스트할 수 있습니다. 정적 웹 사이트에서 개별 웹 페이지는 정적 콘텐츠를 포함합니다. 웹 페이지는 클라이언트 측 스크립트를 포함할 수도 있습니다. S3의 객체 스토리지를 활용하면 정적 파일의 데이터 액세스, 복제 및 데이터 보호를 더욱 쉽게 관리할 수 있습니다.
   
   
5. 아카이빙 및 규정 준수
   테이프 대신 저렴한 클라우드 백업 워크플로를 진행할 수 있을 뿐 아니라 기업, 계약 및 규정 준수 요구 사항도 준수할 수 있습니다.

데이터를 자주 변경하거나 블록 스토리지 요구 사항이 적용되는 경우 다른 스토리지 솔루션을 고려해야합니다.

서비스 호스트?
서비스를 호스트한다는 것은 서비스를 제공하기 위해 필요한 하드웨어와 소프트웨어를 준비하고, 이를 관리하는 것을 의미합니다.

정적 웹 사이트 VS 동적 웹 사이트
정적 웹 사이트는 서버에 저장된 HTML 파일로 구성된 웹 사이트입니다. 정적 웹 사이트는 사용자의 요청에 따라 내용이 변경되지 않습니다. 예를 들어, 블로그, 포트폴리오, 뉴스 사이트 등이 정적 웹 사이트입니다.

동적 웹 사이트는 사용자의 요청에 따라 내용이 변경되는 웹 사이트입니다. 동적 웹 사이트는 웹 서버에서 실행되는 스크립트 언어를 사용하여 생성됩니다. 예를 들어, 온라인 쇼핑몰, 게시판, 커뮤니티 등이 동적 웹 사이트입니다.

특징
- 정적 웹 사이트는 사용자의 요청에 따라 내용이 변경되지 않지만, 동적 웹 사이트는 사용자의 요청에 따라 내용이 변경됩니다.
- 정적 웹 사이트는 생성하기 쉽고 관리하기 쉽지만, 동적 웹 사이트는 생성하기 어렵고 관리하기 어렵습니다.
- 정적 웹 사이트는 동적 웹 사이트보다 빠릅니다.

버킷 및 객체

S3에는 데이터가 버킷 내에 객체로 저장됩니다. 객체는 파일과 해당 파일을 설명하는 모든 메타데이터로 구성됩니다. S3에 객체를 저장하려면 버킷에 객체를 업로드해야 합니다.

파일을 업로드하면 객체에 대한 권한을 설정하고 메타데이터를 추가할 수 있습니다. 계정에 하나 이상의 버킷을 만들 수 있습니다. 각 버킷에 대해, 고객이 버킷 내에서 객체를 생성, 삭제 및 나열할 수 있는 사용자를 제어합니다. S3가 버킷과 버킷의 콘텐츠를 저장할 지리적 AWS 리전을 선택합니다. 버킷 및 그 안의 객체에 대한 로그에 액세스할 수 있습니다. S3에서는 계정마다 최대 100개의 버킷을 보유할 수 있습니다.

위 그림에는 버킷에서 시작되는 가상 호스트 스타일 액세스 URL과 객체 키가 나와있습니다. 객체 키는 버킷 내 객체의 고유한 식별자입니다. 버킷, 키, 버전 ID의 조합이 각 객체를 고유하게 식별합니다. 웹 서비스 엔드포인트, 버킷 이름, 키, 버전(선택 사항)을 조합하여 모든 객체에 고유한 주소를 지정할 수 있습니다.

객체 키 이름 상세 내용