• HOME
  • ManVSCloud
  • Dev/Update
  • AWS
  • NCLOUD
  • IT/Linux/Kubernetes
  • Certificate
  • HCX 토큰 계산기

ManVSCloud

AWS

[AWS] ELB 액세스 로그 활성화 및 S3 수명 주기 관리

안녕하세요 ManVSCloud 김수현입니다.

오랜만에 AWS 포스팅으로 “ELB 액세스 로그 활성화 및 S3 수명 주기 관리”를 준비했습니다.


S3 생성 및 권한 정책 설정

먼저 S3 생성은 원하시는 버킷 이름으로 생성하시면 됩니다.
기존에 사용하시는 버킷이 존재한다면 기존 버킷을 사용하셔도 되지만 저는 로그를 담을 수 있는 로그 전용 버킷을 따로 생성해주도록 하겠습니다.

버킷 내 폴더를 만들 수 있습니다.
이후 수명 주기 관리 시 접두사를 이용하여 폴더별 수명 주기를 관리할 수 있어 ELB에서 액세스 로그를 활성화 후 로그를 저장할 폴더를 하나 생성해주었습니다.

여기서 중요한 부분이 나옵니다!
ELB에서 S3에 리소스를 업데이트 할 수 있는 권한이 있어야하는데 같은 아마존 내 서비스라도 권한이 없는 상태이므로 아래 이미지와 같이 버킷 정책을 [편집] 해주어야합니다.

아래 기본 양식을 사용할 수 있습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ELB계정ID:root"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::버킷이름/경로/폴더명/*"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "delivery.logs.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::버킷이름/경로/폴더명/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-acl": "bucket-owner-full-control"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "delivery.logs.amazonaws.com"
      },
      "Action": "s3:GetBucketAcl",
      "Resource": "arn:aws:s3:::버킷이름"
    }
  ]
}
  • ELB계정ID
    ELB계정ID 부분은 AWS 계정의 ID가 아니라 ELB의 계정 ID를 입력해주어야합니다.
    각 리전별 ELB의 계정 ID는 아래 표를 참고해주시면 됩니다.
Region리전 이름Elastic Load Balancing 계정 ID입니다.
us-east-1미국 동부(버지니아 북부)127311923021
us-east-2미국 동부(오하이오)033677994240
us-west-1미국 서부(캘리포니아 북부)027434742980
us-west-2미국 서부(오레곤)797873946194
af-south-1아프리카(케이프타운)098369216593
ca-central-1캐나다(중부)985666609251
eu-central-1유럽(프랑크푸르트)054676820928
eu-west-1유럽(아일랜드)156460612806
eu-west-2유럽(런던)652711504416
eu-south-1유럽(밀라노)635631232127
eu-west-3유럽(파리)009996457667
eu-north-1유럽(스톡홀름)897822967062
ap-east-1아시아 태평양(홍콩)754344448648
ap-northeast-1아시아 태평양(도쿄)582318560864
ap-northeast-2아시아 태평양(서울)600734575887
ap-northeast-3아시아 태평양(오사카)383597477331
ap-southeast-1아시아 태평양(싱가포르)114774131450
ap-southeast-2아시아 태평양(시드니)783225319266
ap-southeast-3아시아 태평양(자카르타)589379963580
ap-south-1아시아 태평양(뭄바이)718504428378
me-south-1중동(바레인)076674570225
sa-east-1남아메리카(상파울루)507241528517
us-gov-west-1*AWS GovCloud(미국 서부)048591011584
us-gov-east-1*AWS GovCloud(미국 동부)190560391635
cn-north-1*중국(베이징)638102146993
cn-northwest-1*중국(닝샤)037604701340
  • 버킷이름/경로/폴더명/*
    : S3 Bucket명 이후 로그를 저장할 경로 및 폴더를 지정하여 권한을 줍시다.
  • 버킷이름
    : S3 Bucket명을 입력합니다.

위 양식에서 ELB계정ID, 버킷이름/경로/폴더명/*, 버킷이름 부분을 수정하신 후 변경 사항 저장을 하시면 버킷 정책 설정 부분도 완료되었습니다.


ELB 액세스 로그 활성화

사용 중이거나 생성한 Elastic Load Balancer를 보면 아래 [속성]을 편집할 수 있는 부분이 있습니다.

현재는 액세스 로그가 비활성화 된 상태인데 이를 활성화 시켜줄 것입니다.

액세스 로그 부분을 활성화에 체크해주시고 로그를 저장할 S3위치 [버킷명/경로(폴더명)]를 지정해준 후 저장 버튼을 누릅니다.

(위에서 S3 버킷 정책 설정이 되지 않았다면 권한 문제로 정상적인 진행이 되지 않습니다.)


S3 수명 주기 관리

위 방법까지만 진행하면 ELB의 액세스 로그 활성화는 이미 성공하신 것입니다.
하지만 여기서 설정이 끝난다면 액세스 로그는 S3에 지속적으로 쌓일 것이고 이후 용량이 점차 커져 S3에서 발생하는 비용이 늘어나게 됩니다.

그러므로 S3 수명 주기 관리를 이용하여 일정 시간이 지난 데이터는 만료 후 자동으로 삭제될 수 있도록 해주어야합니다.

S3 – 관리 – 수명 주기 규칙 생성

수명 주기 규칙 이름을 정하신 후 접두사를 지정해줍니다.
만약 버킷 모든 객체에 적용을 선택하시면 해당 규칙이 모든 버킷 내 객체에 적용되므로 참고 부탁드립니다.

  • 스토리지 클래스 간에 객체의 현재 버전 전환
    : 원하는 스토리지 클래스 전환을 선택하고 객체 생성 후 경과 기간을 설정해주시면 됩니다.
  • 스토리지 클래스 간에 객체의 이전 버전 전환
    : 현재 버전 전환과 방법은 동일합니다.
  • 객체의 현재 버전 만료
    : 날짜를 지정하면 그 날짜 기준으로 만료 상태로 변경되며 시간이 좀 더 경과된 후 삭제됩니다.
  • 객체의 이전 버전 영구 삭제
    : 설정된 날짜 기준으로 삭제됩니다.
  • 만료된 삭제 마커 또는 완료되지 않은 멀티파트 업로드 삭제
    : 현재 날짜 기준으로 실행됩니다.

위 설정된 내용을 보면 객체의 현재 버전 만료, 객체의 이전 버전 영구 삭제를 선택하고
객체 생성 후 경과 일수를 14일, 객체가 최신이 아닌 상태로 전환된 후 경과 일수를 1로 설정하였습니다.

이와 같이 설정하게 되면 14일이 지나면 객체가 만료되고 만료된 데이터가 하루가 지나면 자동으로 삭제가 됩니다.

Amazon S3 수명 주기 규칙에 지연이 발생하는 이유
최종 업데이트 날짜: 2019년 12월 20일

수명 주기 규칙은 Amazon S3가 객체의 전환 또는 만료(삭제) 날짜를 UTC 기준으로 계산하므로 생각보다 늦게 수명 주기 규칙이 동작합니다.

자세한 내용은 위 링크를 참고하시기 바랍니다.


Personal Comments

지금까지 ELB 액세스 로그 활성화 및 S3 수명 주기 관리에 대해 알아보았습니다.
최근 AWS에 관련된 포스팅이 많이 줄었는데 조금 더 늘려보도록 하겠습니다.

긴 글 읽어주셔서 감사합니다.

2월 8, 2022 by manvscloud
Older Posts
Newer Posts

About Me

About Me

ManVSCloud Blog, 2020-09-18 ~ AWS, NCP, AZURE, etc... Welcome to my blog!! Naver Cloud Platform Support Master ManVSCloud 입니다.

SUBCRIBE & FOLLOW

SEARCH

CATEGORY

Latest Article

  • [NCLOUD] CPU 환경에서도 가능한 딥러닝: AI-Hub와 네이버 클라우드로 이미지 분류 모델 개발 도전기
  • [NCLOUD] Cloud DB for PostgreSQL 백업 to Object Storage (관리형 데이터베이스 백업이 실패한다면?)
  • [NCLOUD] Secret Manager로 Cloud DB for PostgreSQL 패스워드 관리하기
  • [NCLOUD] 관리형 데이터베이스의 백업 실패, 더 이상 놓치지 마세요!
  • [NCLOUD] Neo4j 기반 GraphRAG 구현과 CLOVA Studio를 통한 Text2SQL 변환

TAG

AI (11) Amazon Web Service (10) API (12) AWS (27) backup (13) blog (8) Certified (6) Certified Kubernetes Administrator (7) Cloud (7) cloud functions (19) CloudNet@ (9) HyperCLOVA X (6) k8s (9) kube (7) kubernetes (15) Linux (9) manvscloud (131) manvscloud blog (10) Master (10) naver (98) naver cloud (107) Naver Cloud PlatForm (108) ncloud (103) NCP (84) object storage (13) python (16) s3 (8) security (12) Serverless (16) slack (6) Support Master (9) 교육 (9) 네이버 (94) 네이버 클라우드 (97) 네이버클라우드 (21) 네이버 클라우드 교육 (8) 네이버 클라우드 플랫폼 (84) 모니터링 (8) 백업 (12) 보안 (14) 자격증 (9) 자동화 (11) 쿠버네티스 (11) 클라우드 (10) 후기 (8)
Instagram LinkedIn
ⓒ 2020 ManVSCloud, BLOG Site. Back to top