끄적이는 보송

S3의 특정 경로에 있는 객체의 byte 단위로 정확한 Total size를 계산할 일이 있었다. 콘솔 환경에서 'Calculate total size'를 찾아 클릭하면 되겠지만 문제는 아래처럼 대략적인 total size만 출력이 된다는 것이다. --recursive --summarize 옵션을 이용하기 이 문제는 summarize 옵션을 이용한 아래의 AWS CLI 명령어로 해결할 수 있다. 아래 명령어로 최종적으로 S3에 있는 객체의 개수와 byte 단위의 크기를 확인할 수 있다. (아마도 콘손 상에 보였던 S3 버킷의 total size는 --human-readable 옵션 값을 출력하여 보여준 게 아닌가 싶다) aws s3 ls "" --recursive --summarize 명령어를 수행하면 ..

여러 파일을 CLI 명령어로 S3에 한 번에 옮기려 했으나, 내 예상과는 달리 "*"(아스타리스크)가 먹히지 않아 당황스러웠었다 (ex. s3 cp ). S3 CLI 명령어에는 파일과 폴더를 재귀적으로 처리하는 옵션이 있으며, "--recursive", "--exclude", "--include" 옵션을 활용해 여러 객체에 명령어를 수행할 수 있다. 이참에 S3 CLI 명령어로 여러 객체에 수행할 수 있는 것을 정리해볼까 한다. 예를 한번 들어보면서 시작해 보겠다. S3 버킷에 있는 모든 객체 로컬로 다운로드 aws s3 cp s3:/// ./ --recursive S3 버킷에 있는 모든 객체를 로컬 시스템의 현재 경로로 복사를 하겠다는 명령어다. 만약 해당 버킷에 폴더가 있다면, 복사 대상의 경로에도 ..

오늘은 깊게 분석할 것 없이 아래의 간단한 실습을 해볼 생각이다. 1. CloudTrail 생성 및 로그가 S3에 쌓이도록 구성 2. S3에 쌓인 로그 파일을 Athena로 분석하기 굳이 CloudTrail 로그를 S3에 올리는 이유는 CloudTrail의 최대 로그 보존 기간이 90일이기 때문이다. 그 이전의 데이터는 유지하지 않기에 간혹 과거의 데이터를 조회하지 못해 난감한 경우가 있었다. (누가 어떤 작업을 했는지, CreateInstance 로그 등등) 또한 로그 파일이 쌓이다 보면 일일이 수많은 파일을 열어 확인해야 하는 번거로움이 있는데 이를 Athena를 활용해 쿼리를 날려 내가 원하는 데이터를 추릴 수 있다. 오늘은 이 실습을 해보려 한다. 1. CloudTrail 생성 및 로그가 S3에 ..

자주 접하는 Storage 서비스지만 평소 감(?)과 대충으로만 알 뿐이었다. 이들이 정확히 어떤 녀석들이고 어떤 차이가 있는지 정리해본다. 이들에 대해서 논하기 전에 먼저 Block Level Storage와 Object Storage를 짚고 넘어가야 한다. Block Level Storage의 개념 먼저 우리들 컴퓨터에 1GB짜리 파일이 저장되어 있다고 가정하자. 그 파일은 컴퓨터 하드디스크의 몇몇 블록에 할당되어 있을 것이다. 그리고 파티셔닝에 따라 다르겠지만 여기선 각 블록을 512KB라고 가정하겠다. 그렇다면 1GB짜리 파일은 2000블록을 차지하고 있는 셈이 되겠다. 그리고 그 2000블록을 예제로 그린 것이 밑의 그림이 되겠다. (비록 25칸짜리 그림이지만 2000블록으로 상상하자) 우리는 ..

CloudFront OAI 란 OAI (Origin Access Identity)란 CloudFront가 S3에 저장된 Private 객체에 액세스 할 수 있도록 하는 특별한 식별자다. 외부 사용자가 S3 Endpoint를 통한 직접적인 요청이 아닌 CF의 배포를 통해 접근하도록 구성하고 싶다면 OAI를 고려할 수 있다. OAI와 IAM의 차이점 OAI는 IAM과 성격이 비슷해 보이지만 다르다. IAM 사용자를 생성하지도 않을뿐더러, 정책을 직접 연결할 수 없다는 점에서 조금 다르다. 반대로 IAM도 CloudFront Distribution에 할당될 수 없다. OAI는 S3 정책안에 'Principal'를 통해 참조되어 사용되며, 단순히 S3 Origin 보안 강화를 위해 요청을 식별하는 데 사용되는 ..

Pre-Signed URL (미리 서명된 url) 이란? 디폴트로 S3의 객체는 비공개이며 소유자만이 접근할 수 있다. 하지만 필요할 경우 소유자의 보안 자격 증명을 사용해 일정기간 동안 효력이 있는 URL을 생성할 수 있다. 이 URL을 미리 서명된 URL (pre-signed url)이며 이를 통해 다른 사용자는 임시적으로 해당 객체에 접근할 수 있게 된다. 참고로 pre-signed url은 이를 생성한 사용자의 권한에 의해 일부 제한된다고 하니 다음 링크를 참조해보자. https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/using-presigned-url.html#who-presigned-url 미리 서명된 URL 사용 - Amazon Sim..

VPC Endpoint란 VPC Endpoint는 VPC와 AWS 서비스 사이의 통신을 비공개로 연결할 수 있도록 해주는 서비스며 Pubilc IP 주소를 필요로 하지 않게 한다. VPC와 기타 서비스 간의 트래픽은 AWS 네트워크를 벗어나지 않는다. 리소스 통신간 외부 유출을 꺼려할 때 사용하는 서비스로 보인다. VPC Endpoint가 왜 필요할까 예를 들면 보자. VPC Endpoint가 없다면 EC2 인스턴스에서 S3로 액세스 할 때, EC2는 NAT와 Internet Gateway를 통해 외부로 나가 S3에 접속한다. (EC2와 S3 둘 다 AWS 서비스라고 둘이 내부 통신한다고 생각하면 안 된다) EC2, RDS 등의 서비스는 ENI를 탑재하고 이 ENI에 Public 혹은 Private IP..

자격 증명 없이 EC2 인스턴스가 직접 S3에 액세스 할 수 있도록 구성해보려 한다. 누군가의 부주의로 Key가 유출되는 경우가 종종 있어 아예 EC2 직접 S3권한을 부여하면 문제가 조금은 해소되지 않을까 싶어 시작했으며 이참에 겸사겸사 기록해본다. 준비물 1. 기본적인 클라우드 환경 2. EC2 3. S3 4. EC2에서 S3로 붙기위한 IAM Role 1. S3 생성 S3 버킷의 이름은 고유해야 하며 2개를 생성했다. 이 중 하나만 EC2가 접근할 수 있도록 구성해볼 생각이다. Role 정상적이라면 나머지 다른 하나에 대한 접근 권한을 없을 것이다. 2. EC2 생성 EC2 인스턴스 아무런 AWS 자격증명 정보를 입력하지 않았으며 어떠한 Role도 부여받지 않은 모습이다. 필자는 원래 돌리고 있던 ..