CloudFront·Lambda 통합 — S3 7편 완결

이 글은 Amazon S3 심화 정리 시리즈의 마지막 7편입니다. 1편의 객체 스토리지 기초부터 보안·복제·라이프사이클·성능·고급 기능까지 — 여기까지 와줘서 정말 고마워요. 처음에는 "사물함이 뭐 그렇게 어려워?" 싶었지만 막상 들여다보니 버킷 이름 규칙·일관성·암호화·복제·라이프사이클·이벤트·태그 등등 외울 거리가 한 무더기였죠.

마지막 단원은 S3가 다른 AWS 서비스와 어떻게 연결되는지입니다. 솔직히 이 단원이 가장 재미있어요. S3 자체만 들여다보면 "그냥 파일 저장소" 같지만, Lambda·CloudFront·Athena 같은 서비스들과 연결하기 시작하면 갑자기 데이터 레이크·서버리스 파이프라인·글로벌 CDN·SQL 분석 플랫폼이 됩니다. 특히 CloudFront 와 묶이는 순간 S3는 전 세계 엣지 캐시를 가진 글로벌 자산 배포망이 돼요. S3가 AWS 생태계의 뼈대라는 말이 그래서 나오는 거예요. 공식 문서는 AWS 문서 허브 의 S3 사용자 가이드 와 CloudFront 가이드를 옆에 띄워 두면 도움이 됩니다.

CloudFront·Lambda 통합 단원이 처음엔 왜 어렵게 느껴질까요

이유는 단순해요. 이름이 너무 많이 등장합니다.

Lambda·CloudFront·Athena·Glacier·Storage Lens·CloudTrail·AWS Config·SNS·SQS·Cost Explorer — 한 단원에 서비스 이름이 열 개 넘게 줄지어 나오니까 머리가 어지러워집니다. 게다가 각자 자기 단원에서 책 한 권 분량이 나오는 서비스들이라, "이걸 다 알아야 하나?" 하는 압박이 들죠.

핵심은 이거예요. 이 단원은 각 서비스의 깊이를 외우는 게 아니라, "S3와 어떻게 연결되는가"라는 한 점만 보면 됩니다. Lambda 자체를 이해할 필요는 없어요. "S3에 파일이 들어오면 Lambda가 자동으로 처리한다" 그 한 줄만 잡으면 됩니다.

회사 비유로 풀면 이래요. S3는 회사의 거대한 사물함입니다. 그리고 다른 서비스들은 사물함을 둘러싼 직원·창구·검사관이에요.

• Lambda — 사물함에 자료가 들어오면 자동으로 일하는 직원
• CloudFront — 본사 사물함을 전 세계 동네 매장에서 캐싱해 주는 배달망
• Athena — 사물함 자료에 SQL 쿼리를 그대로 던지는 분석 도구
• Storage Lens — 사물함 사용 패턴을 한눈에 보여주는 대시보드
• CloudTrail — 사물함 출입·변경을 기록하는 일지
• AWS Config — 사물함 정책 위반을 자동으로 점검하는 감사관
• SNS/SQS — 사물함 이벤트를 여러 부서에 동시 통보하는 우편함
• S3 Inventory — 사물함 자료 전수조사 보고서

이 비유를 머리에 잡고 들어가면, 단원 끝에서 모든 게 한 그림으로 보입니다. 자, 시작해 볼게요.

S3가 AWS 생태계에서 어떤 자리인가요 (Lambda·CloudFront의 뿌리)

먼저 S3가 단순한 "파일 저장소"가 아닌 이유부터 짚을게요. AWS 서비스 대부분이 S3를 백엔드 스토리지로 사용합니다. 회사 비유로 — 사물함이 그냥 자료 보관소가 아니라 회사 모든 부서가 의존하는 중앙 창고인 셈이에요.

S3에 의존하는 대표 서비스를 정리하면:

• EC2 — AMI 이미지·EBS 스냅샷이 S3에 저장
• CloudFormation — 템플릿 저장소가 S3
• Elastic Beanstalk — 배포 아티팩트 저장
• CodeDeploy — 빌드 결과물 저장
• CloudTrail — 감사 로그 저장
• SageMaker — 학습된 모델 저장

여기서 시험 함정이 하나 있어요. S3가 다운되면 위 서비스들도 같이 흔들립니다. 2017년에 S3 us-east-1 장애가 났을 때 AWS 절반 이상이 영향을 받은 적이 있어요. S3는 단순한 스토리지가 아니라 AWS 인프라의 뼈대라는 말이 그래서 나오는 겁니다.

또 하나 — 데이터 레이크(Data Lake)의 핵심 스토리지가 S3예요. 회사 자료를 한곳에 모아두고 SQL로 분석하는 패턴이 데이터 레이크인데, 그 "한곳"이 거의 항상 S3입니다. 이 글 후반에서 Athena와 함께 풀어 갈게요.

> 한 줄 정리 — S3는 단순 저장소가 아니라 AWS 생태계의 뼈대. 다른 서비스가 백엔드로 의존하고, 데이터 레이크의 중심.

S3 + Lambda — 사물함에 자료 들어오면 자동으로 일하는 직원

가장 자주 쓰이는 통합 패턴이 S3 + Lambda입니다. S3에 파일이 들어오면 Lambda 함수가 자동으로 실행되는 구조예요.

회사 비유로 풀면 — 사물함에 새 자료가 들어올 때마다 자동으로 달려와서 일하는 직원이 Lambda입니다. 사람이 일일이 "자, 자료 들어왔으니 처리해 주세요"라고 부르지 않아도 알아서 움직여요. 서버를 따로 관리할 필요가 없는 게 핵심이라 서버리스 아키텍처의 중심 패턴으로 자리잡았습니다.

어디에 쓰이느냐

Lambda + S3 조합이 빛나는 자리를 정리하면:

• 이미지 처리 — 업로드 즉시 썸네일 생성·리사이즈·워터마크 추가
• 문서 처리 — PDF에서 텍스트 추출, 형식 변환
• 데이터 변환 — CSV → JSON, XML → Parquet 자동 변환
• 알림 — 새 파일 업로드 시 이메일·슬랙 통보
• 보안 스캔 — 업로드 파일 바이러스 검사

흔한 시나리오 하나 — 사용자가 사진을 업로드하면 자동으로 썸네일이 생성되어 다른 버킷에 저장되는 구조예요. 사용자는 그냥 사진만 올렸을 뿐인데 1초도 안 되어 썸네일이 만들어져 있어요. 백엔드에서 Lambda가 알아서 일했기 때문이죠.

설정 — 권한과 트리거

Lambda + S3 설정은 두 단계로 나뉘어요. 첫째는 Lambda에 "S3가 너를 호출할 수 있어"라는 권한 부여, 둘째는 S3에 "이런 이벤트가 일어나면 이 Lambda를 호출해"라고 트리거 설정입니다.

# Lambda 함수에 S3 트리거 권한 부여
aws lambda add-permission \
  --function-name ImageProcessor \
  --statement-id s3-trigger-permission \
  --action lambda:InvokeFunction \
  --principal s3.amazonaws.com \
  --source-arn arn:aws:s3:::my-image-bucket \
  --source-account 123456789012

# S3 버킷에 Lambda 트리거 설정 (uploads/ 접두사의 .jpg 파일만)
aws s3api put-bucket-notification-configuration \
  --bucket my-image-bucket \
  --notification-configuration '{
    "LambdaFunctionConfigurations": [
      {
        "Id": "ImageThumbnailGenerator",
        "LambdaFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:ImageProcessor",
        "Events": ["s3:ObjectCreated:*"],
        "Filter": {
          "Key": {
            "FilterRules": [
              {"Name": "prefix", "Value": "uploads/"},
              {"Name": "suffix", "Value": ".jpg"}
            ]
          }
        }
      }
    ]
  }'

여기서 시험 함정이 하나 있어요. 권한 부여를 빼먹으면 S3 이벤트가 발생해도 Lambda가 호출되지 않습니다. 그런데 에러 메시지가 명확하지 않아서 "왜 안 되지?" 한참 헤매는 경우가 많아요. 두 단계 모두 설정해야 작동한다는 점을 꼭 기억하세요.

또 하나 — 필터(Filter) 가 중요합니다. 위 예시처럼 prefix=uploads/, suffix=.jpg를 걸면 그 조건에 맞는 객체에만 Lambda가 실행돼요. 안 그러면 모든 파일에 대해 Lambda가 호출되어 비용이 폭증할 수 있습니다.

이미지 썸네일 생성 — 실전 코드

Lambda 함수 안에서 어떻게 동작하는지 한번 풀어 볼게요.

import boto3
import urllib.parse
from PIL import Image
import io

s3_client = boto3.client('s3')

THUMBNAIL_BUCKET = 'my-thumbnail-bucket'
THUMBNAIL_SIZE = (200, 200)

def lambda_handler(event, context):
    for record in event['Records']:
        source_bucket = record['s3']['bucket']['name']
        source_key = urllib.parse.unquote_plus(record['s3']['object']['key'])

        # 원본 이미지 다운로드
        response = s3_client.get_object(Bucket=source_bucket, Key=source_key)
        image_data = response['Body'].read()

        # 썸네일 생성
        image = Image.open(io.BytesIO(image_data))
        image.thumbnail(THUMBNAIL_SIZE)

        # 썸네일을 메모리에 저장
        thumbnail_buffer = io.BytesIO()
        image.save(thumbnail_buffer, format='JPEG', quality=85)
        thumbnail_buffer.seek(0)

        # 썸네일 업로드
        thumbnail_key = source_key.replace('uploads/', 'thumbnails/')
        s3_client.put_object(
            Bucket=THUMBNAIL_BUCKET,
            Key=thumbnail_key,
            Body=thumbnail_buffer,
            ContentType='image/jpeg'
        )

    return {'statusCode': 200, 'body': 'Thumbnails created'}

흐름이 보이시죠? 이벤트 → 다운로드 → 처리 → 업로드 4단계가 전부예요. Lambda는 이런 짧은 처리에 특화돼 있어서 — 기본 타임아웃이 3초, 최대 15분 — 무거운 작업은 다른 서비스로 빼야 합니다.

한 가지 주의할 점 — 무한 루프

여기서 시험 함정이 하나 있어요. 같은 버킷에 결과를 다시 쓰면 무한 루프가 일어날 수 있습니다. 예를 들어 my-bucket에 사진이 올라오면 Lambda가 썸네일을 만들어서 같은 my-bucket에 저장하면 — 그 썸네일도 ObjectCreated 이벤트를 발생시켜서 Lambda가 또 호출되고, 또 호출되고… 영원히 돌아갑니다.

해결법 두 가지:

1. 출력 버킷을 분리 — 원본은 uploads-bucket, 썸네일은 thumbnails-bucket
2. 접두사 필터 활용 — 같은 버킷이라면 uploads/만 트리거하고 thumbnails/는 제외

위 코드 예시처럼 출력 버킷을 다르게 잡는 게 가장 깔끔해요.

S3 + CloudFront — 본사 사물함을 전 세계 동네 매장에서 캐싱

다음은 S3 + CloudFront 통합. 이 조합은 정적 웹사이트·미디어 배포의 표준 패턴이에요.

회사 비유로 풀면 — 본사에 사물함(S3)이 있는데, 사용자가 미국·유럽·아시아·아프리카 어디에서 접근하든 본사까지 매번 다녀오면 너무 느립니다. 그래서 전 세계 주요 도시에 동네 매장(엣지 로케이션) 을 두고, 사용자가 처음 요청한 자료를 그 동네 매장에 복사해 두는 거예요. 다음 사용자는 본사까지 갈 필요 없이 바로 동네 매장에서 받습니다.

CloudFront가 그 동네 매장 역할이에요. 전 세계 400곳 이상의 엣지 로케이션에 콘텐츠를 캐싱해 줍니다.

주요 이점

• 지연 시간 최소화 — 사용자 가까운 엣지에서 응답
• S3 직접 접근 차단 — Origin Access Control(OAC)로 보안 강화
• 비용 절감 — S3 직접 요청이 줄어들어 데이터 전송 비용 감소
• HTTPS 자동 지원 — 무료 SSL/TLS 인증서
• 커스텀 도메인 — www.example.com 같은 자체 도메인 사용

OAC — 동네 매장만 본사에 직접 접근

여기서 가장 중요한 개념이 Origin Access Control(OAC) 입니다. 회사 비유로 풀면 — "외부 손님은 동네 매장으로 가시고, 본사는 동네 매장만 출입 가능" 이라는 규칙이에요.

이게 왜 중요하냐면 — CloudFront를 앞에 두는데 사용자가 그걸 우회해서 S3 URL로 직접 접근하면 캐싱 효과도 없고 보안 정책도 무력화됩니다. OAC를 걸면 CloudFront만 S3에 접근할 수 있고, 외부에서 S3 URL을 직접 호출하면 차단돼요.

# OAC 생성
OAC_ID=$(aws cloudfront create-origin-access-control \
  --origin-access-control-config '{
    "Name": "MyS3OAC",
    "Description": "OAC for S3 bucket",
    "SigningProtocol": "sigv4",
    "SigningBehavior": "always",
    "OriginAccessControlOriginType": "s3"
  }' \
  --query 'OriginAccessControl.Id' \
  --output text)

# S3 버킷 정책 — CloudFront만 접근 허용
aws s3api put-bucket-policy \
  --bucket my-bucket \
  --policy '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "AllowCloudFrontServicePrincipal",
        "Effect": "Allow",
        "Principal": {"Service": "cloudfront.amazonaws.com"},
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::my-bucket/*",
        "Condition": {
          "StringEquals": {
            "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/DISTRIBUTION_ID"
          }
        }
      }
    ]
  }'

여기서 시험 함정이 하나 있어요. 예전엔 OAI(Origin Access Identity) 라는 비슷한 개념을 썼는데 — 현재 권장되는 건 OAC입니다. OAI는 레거시예요. 시험에 OAI와 OAC가 같이 보기로 나오면 OAC를 고르는 게 맞습니다. 단, 옛날 자료에는 아직 OAI로 되어 있는 게 많아서 헷갈릴 수 있어요.

정적 웹사이트 호스팅 — S3만으로 vs CloudFront 결합

S3 자체에도 정적 웹사이트 호스팅 기능이 있어요. index.html을 올리고 호스팅을 켜면 http://my-bucket.s3-website-us-east-1.amazonaws.com 같은 URL이 만들어집니다.

그런데 이걸 단독으로 쓰면 한계가 있어요.

• HTTPS 미지원 — 직접 켜려면 CloudFront가 필요
• 커스텀 도메인 어려움 — Route 53 + CloudFront 조합이 표준
• 캐싱 없음 — 매 요청마다 S3까지 감

그래서 실무에서는 거의 항상 S3(원본) + CloudFront(CDN) + Route 53(DNS) 3종 세트로 운영합니다.

# 정적 웹사이트 파일 업로드
aws s3 sync ./website/ s3://my-website-bucket/ \
  --delete \
  --cache-control "max-age=86400"

# index.html은 짧은 캐시 (자주 바뀌니까)
aws s3 cp ./website/index.html s3://my-website-bucket/index.html \
  --cache-control "no-cache, no-store, must-revalidate"

# Route 53 — CloudFront로 alias 레코드
aws route53 change-resource-record-sets \
  --hosted-zone-id HOSTED_ZONE_ID \
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "AliasTarget": {
          "DNSName": "CLOUDFRONT_DOMAIN.cloudfront.net",
          "EvaluateTargetHealth": false,
          "HostedZoneId": "Z2FDTNDATAQYW2"
        }
      }
    }]
  }'

위 코드에서 — index.html만 캐시를 짧게 가져가는 게 작은 팁이에요. 다른 자산(CSS·JS·이미지)은 파일명에 해시가 들어가는 빌드라면 1년 캐시도 안전한데, index.html은 항상 같은 이름이라 변경이 즉시 반영되어야 하거든요.

> 한 줄 정리 — CloudFront = 글로벌 CDN. OAC = CloudFront만 S3 접근. 정적 웹사이트는 S3 + CloudFront + Route 53 3종 세트.

S3 + Athena — 사물함 자료에 SQL 그대로 던지기

다음은 시리즈에서 가장 매력적인 조합 — S3 + Athena입니다.

회사 비유로 풀면 — 사물함에 CSV·JSON·Parquet 형식의 자료가 잔뜩 쌓여 있는데, 이걸 분석하려면 보통 DB로 옮기고·로딩하고·인덱스 걸고… 한참 걸립니다. 그런데 Athena는 사물함 자료에 SQL 쿼리를 그대로 던지면 결과가 나오는 도구예요. 서버를 따로 띄울 필요가 없고, 쿼리한 만큼만 비용을 지불합니다.

Athena가 지원하는 형식

• CSV·TSV·JSON — 가장 흔한 텍스트 형식
• Apache Parquet — 컬럼형 형식, 권장
• Apache ORC — 컬럼형 형식, Hadoop 계열
• Avro — 직렬화 형식

여기서 시험 함정이 하나 있어요. Parquet를 권장하는 이유가 뭐냐면 — 컬럼형이라 필요한 컬럼만 읽을 수 있어서 스캔 데이터가 줄고, 결과적으로 비용이 줄어들기 때문입니다. CSV는 한 줄에 모든 컬럼이 들어 있어서 한 컬럼만 보려 해도 전체를 다 읽어야 하지만, Parquet는 컬럼 단위로 저장되어 그 컬럼만 쏙 읽을 수 있어요. 같은 데이터라도 Parquet로 변환하면 Athena 비용이 1/10로 줄어드는 사례가 흔합니다.

워크그룹과 결과 저장소

Athena는 쿼리를 실행하면 결과를 다른 S3 버킷에 저장해요. 그래서 결과를 받을 버킷을 미리 만들고 워크그룹에 등록해야 합니다.

# 결과 저장 버킷 생성
aws s3api create-bucket --bucket athena-query-results --region us-east-1

# 워크그룹 생성
aws athena create-work-group \
  --name MyWorkgroup \
  --configuration '{
    "ResultConfiguration": {
      "OutputLocation": "s3://athena-query-results/output/",
      "EncryptionConfiguration": {"EncryptionOption": "SSE_S3"}
    },
    "EnforceWorkGroupConfiguration": true
  }'

# 데이터베이스 생성
aws athena start-query-execution \
  --query-string "CREATE DATABASE IF NOT EXISTS my_data_lake" \
  --work-group MyWorkgroup

외부 테이블 — S3 위에 스키마 씌우기

Athena의 핵심 개념이 외부 테이블(External Table) 입니다. 데이터는 S3에 그대로 있고, 테이블은 그 위에 씌우는 스키마일 뿐이에요. 회사 비유로 — 사물함 자료에 라벨을 붙여 "이 폴더는 이런 컬럼 구조"라고 알려주는 식.

CREATE EXTERNAL TABLE IF NOT EXISTS my_data_lake.sales (
  order_id STRING,
  customer_id STRING,
  product_name STRING,
  quantity INT,
  revenue DOUBLE,
  order_date STRING
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe'
WITH SERDEPROPERTIES ('field.delim' = ',')
LOCATION 's3://my-data-bucket/sales/'
TBLPROPERTIES ('has_encrypted_data'='false');

위 SQL을 실행해도 데이터는 옮겨가지 않습니다. 그냥 "이 S3 경로의 파일들을 이런 컬럼으로 해석해라"라고 등록한 것뿐이에요. 그래서 데이터를 새로 추가해도 Athena가 자동으로 인식합니다.

파티셔닝 — 비용 줄이는 핵심 기술

여기서 시험 함정이 하나 있어요. Athena는 스캔한 데이터 양만큼 과금됩니다. TB당 약 $5예요. 그러니까 매번 1TB짜리 테이블 전체를 스캔하면 한 번에 $5씩 빠져나가는 거죠. 자주 쓰는 쿼리라면 비용이 무섭게 쌓입니다.

해결법이 파티셔닝(Partitioning) 이에요. 데이터를 year=2024/month=01/day=15/ 같은 접두사 구조로 저장하면, Athena가 WHERE year='2024' 조건으로 그 파티션만 스캔합니다. 회사 비유로 — 자료를 연·월·일별로 폴더에 나눠 두면 "2024년 1월 자료만 보여줘"라고 했을 때 그 칸만 열어 보면 된다는 식.

-- 파티션 테이블 생성
CREATE EXTERNAL TABLE IF NOT EXISTS my_data_lake.logs (
  timestamp STRING,
  level STRING,
  message STRING
)
PARTITIONED BY (year STRING, month STRING, day STRING)
STORED AS PARQUET
LOCATION 's3://my-data-bucket/logs/';

-- 파티션 자동 감지
MSCK REPAIR TABLE my_data_lake.logs;

-- 파티션 프루닝으로 비용 절감
SELECT * FROM my_data_lake.logs
WHERE year='2024' AND month='01';

위 쿼리는 2024년 1월 데이터만 스캔하기 때문에 — 전체 테이블이 1TB라도 그 한 달 분량만 비용이 발생합니다.

실전 — Python에서 Athena 쿼리

import boto3
import time
import pandas as pd

athena_client = boto3.client('athena')

def run_athena_query(query, database, output_bucket):
    response = athena_client.start_query_execution(
        QueryString=query,
        QueryExecutionContext={'Database': database},
        ResultConfiguration={
            'OutputLocation': f's3://{output_bucket}/athena-results/'
        }
    )
    query_id = response['QueryExecutionId']

    # 쿼리 완료 대기
    while True:
        resp = athena_client.get_query_execution(QueryExecutionId=query_id)
        state = resp['QueryExecution']['Status']['State']
        if state == 'SUCCEEDED':
            break
        elif state in ['FAILED', 'CANCELLED']:
            raise Exception(resp['QueryExecution']['Status']['StateChangeReason'])
        time.sleep(1)

    # 결과 가져오기
    results = athena_client.get_query_results(QueryExecutionId=query_id)
    columns = [c['Label'] for c in results['ResultSet']['ResultSetMetadata']['ColumnInfo']]
    rows = [[d.get('VarCharValue', '') for d in r['Data']]
            for r in results['ResultSet']['Rows'][1:]]
    return pd.DataFrame(rows, columns=columns)

# 사용 예시 — 월별 매출 집계
df = run_athena_query(
    query="""
        SELECT DATE_TRUNC('month', CAST(order_date AS DATE)) as month,
               SUM(revenue) as total_revenue,
               COUNT(*) as order_count
        FROM my_data_lake.sales
        WHERE order_date >= '2024-01-01'
        GROUP BY 1 ORDER BY 1
    """,
    database='my_data_lake',
    output_bucket='athena-query-results'
)

> 한 줄 정리 — Athena = 서버리스 SQL on S3. 비용은 스캔 데이터 양에 비례. Parquet + 파티셔닝이 비용 절감의 핵심.

S3 + Glacier — 외부 창고에서 다시 가져오기

5편의 라이프사이클 단원에서 Glacier 클래스로 객체를 보내는 건 풀었죠. 이번 단원에서는 Glacier에 들어간 객체를 다시 꺼내는 절차에 집중할게요.

회사 비유로 풀면 — 외부 창고에 보낸 자료를 다시 보려면 "꺼내 주세요" 신청서를 내고 며칠 기다려야 해요. Glacier도 똑같습니다. 즉시 사용할 수 있는 게 아니라 "복원(Restore) 요청"을 먼저 해야 합니다.

Glacier 클래스 vs 독립 Glacier 서비스

여기서 시험 함정이 하나 있어요. 두 개념이 헷갈립니다.

• S3 Glacier 스토리지 클래스(Instant·Flexible·Deep Archive) — S3 안에서 관리되는 클래스. 객체 단위로 다룸
• Amazon S3 Glacier (독립 서비스) — Vault·Archive 단위로 관리되는 별도 서비스

대부분의 경우 S3 스토리지 클래스로 Glacier를 쓰는 게 권장이에요. 독립 Glacier 서비스는 레거시에 가깝습니다. 시험 보기에서 둘 다 나오면 — 최신 패턴은 S3 스토리지 클래스예요.

복원 요청 — 며칠짜리 사본 만들기

Glacier에서 객체를 복원하면 원본은 그대로 Glacier에 남고, 임시 사본이 S3 Standard에 만들어져 며칠간 접근 가능한 상태가 됩니다. 그 며칠이 지나면 사본은 사라지고 원본만 남아요.

# Glacier Flexible Retrieval 객체 복원 (5일간)
aws s3api restore-object \
  --bucket archive-bucket \
  --key 2023/report.pdf \
  --restore-request '{
    "Days": 5,
    "GlacierJobParameters": {
      "Tier": "Standard"
    }
  }'

# 복원 상태 확인
aws s3api head-object \
  --bucket archive-bucket \
  --key 2023/report.pdf

head-object 응답의 Restore 헤더를 보면 상태를 알 수 있어요.

• ongoing-request="true" — 복원 진행 중 (아직 못 꺼냄)
• ongoing-request="false" — 복원 완료, expiry-date까지 사용 가능

검색 티어 다시 정리

5편에서도 나왔지만 한 번 더 짚을게요. Tier(검색 등급) 에 따라 시간과 비용이 갈립니다.

클래스	Expedited	Standard	Bulk
Glacier Flexible	1~5분	3~5시간	5~12시간
Glacier Deep Archive	지원 X	12시간	48시간

Expedited는 가장 빠른 대신 가장 비싸고, Bulk는 가장 느린 대신 가장 저렴합니다. 회사 비유로 — 외부 창고에 "오늘 안에 꼭 필요해요" vs "다음 주 중까지면 OK" 같은 차이예요.

대량 복원 — Batch Operations

객체 하나하나 복원하는 게 아니라 수만~수백만 개를 한 번에 복원해야 한다면 — S3 Batch Operations를 씁니다. Inventory 보고서나 매니페스트 파일을 입력으로 주면 그 안의 모든 객체를 한 번에 복원해 줘요. 자세한 건 6편 고급 기능 단원에서 다뤘으니 여기서는 그런 도구가 있다는 정도만 짚고 갈게요.

S3 Storage Lens — 사물함 사용 패턴 대시보드

다음은 Storage Lens — 회사 비유로 풀면 사물함을 어떻게 쓰고 있는지 한눈에 보여주는 대시보드예요.

여기 들어가면 다음 같은 정보가 다 보입니다.

• 버킷별 저장량 추이
• 스토리지 클래스 분포
• 요청 수와 패턴
• 비암호화 객체·비공개 차단 누락 같은 정책 위반
• 비용 최적화 권고사항

무료 vs 고급 티어

항목	무료 (기본)	고급 (Advanced)
사용 지표 수	15개	35개 이상
활동 지표	없음	15개
세분성	버킷 수준	접두사 수준까지
데이터 보존	14일	15개월
권고사항	없음	있음
가격	무료	백만 객체당 $0.20

여기서 시험 함정이 하나 있어요. "권고사항(Recommendations)"은 고급 티어에서만 제공됩니다. 시험 보기에 "Storage Lens 무료 티어로 비용 최적화 권고를 받는다"는 게 나오면 함정이에요.

# 기본 Storage Lens 대시보드 생성
aws s3control create-storage-lens-configuration \
  --account-id 123456789012 \
  --config-id my-storage-lens \
  --storage-lens-configuration '{
    "Id": "my-storage-lens",
    "AccountLevel": {
      "ActivityMetrics": {"IsEnabled": true},
      "BucketLevel": {
        "ActivityMetrics": {"IsEnabled": true}
      }
    },
    "IsEnabled": true
  }'

# 데이터 내보내기 — 다른 도구로 분석할 때
aws s3control create-storage-lens-configuration \
  --account-id 123456789012 \
  --config-id my-storage-lens-with-export \
  --storage-lens-configuration '{
    "Id": "my-storage-lens-with-export",
    "AccountLevel": {"BucketLevel": {}},
    "IsEnabled": true,
    "DataExport": {
      "S3BucketDestination": {
        "AccountId": "123456789012",
        "Arn": "arn:aws:s3:::my-storage-lens-bucket",
        "Format": "CSV",
        "OutputSchemaVersion": "V_1",
        "Prefix": "storage-lens/"
      }
    }
  }'

내보내기를 켜면 CSV·Parquet 형식으로 S3에 떨어뜨려서 — 그걸 다시 Athena로 SQL 분석할 수도 있어요. Storage Lens → S3 → Athena 조합이 비용 분석의 표준 패턴이에요.

> 한 줄 정리 — Storage Lens = 사물함 사용 패턴 대시보드. 권고사항·접두사 단위 분석은 고급 티어에서만.

S3 서버 액세스 로깅 — 사물함 출입 일지

S3에는 두 종류의 로깅이 있어요. 서버 액세스 로깅(Server Access Logging) 과 CloudTrail 데이터 이벤트입니다. 헷갈리니까 차례로 풀어 갈게요.

서버 액세스 로깅 — 모든 요청 기록

회사 비유로 — 사물함에 들어오고 나간 모든 사람의 출입 일지가 서버 액세스 로깅입니다. 누가·언제·어떤 객체에·무슨 작업을 했는지 모두 기록돼요.

기록되는 항목:

• 버킷 소유자·이름·요청 시간
• 요청자 IP 주소·계정
• HTTP 작업 (GET·PUT·DELETE)
• 응답 상태 코드·전송 바이트 수
• 객체 크기·총 처리 시간
• TLS 버전

# 로그 저장 버킷 권한 부여
aws s3api put-bucket-acl \
  --bucket my-logs-bucket \
  --grant-write URI=http://acs.amazonaws.com/groups/s3/LogDelivery \
  --grant-read-acp URI=http://acs.amazonaws.com/groups/s3/LogDelivery

# 소스 버킷에 로깅 설정
aws s3api put-bucket-logging \
  --bucket my-source-bucket \
  --bucket-logging-status '{
    "LoggingEnabled": {
      "TargetBucket": "my-logs-bucket",
      "TargetPrefix": "logs/my-source-bucket/"
    }
  }'

# 로그 만료 정책 (90일 뒤 삭제)
aws s3api put-bucket-lifecycle-configuration \
  --bucket my-logs-bucket \
  --lifecycle-configuration '{
    "Rules": [{
      "ID": "ExpireAccessLogs",
      "Status": "Enabled",
      "Filter": {"Prefix": "logs/"},
      "Expiration": {"Days": 90}
    }]
  }'

여기서 시험 함정이 하나 있어요. 로그 저장 버킷과 소스 버킷을 같이 두면 무한 루프가 생깁니다. 로그를 쓰는 행위 자체가 또 로그를 만들어내거든요. 반드시 별도 버킷에 저장하세요.

또 하나 — 로그는 영원히 쌓이면 비용이 폭증하니 라이프사이클 정책으로 90일·1년 뒤 삭제 또는 Glacier로 이동을 걸어두는 게 표준 패턴이에요.

S3 + CloudTrail — 사물함 API 호출 감사

서버 액세스 로깅과 비슷해 보이는데 CloudTrail은 다른 영역을 기록합니다.

차이를 표로 정리하면:

항목	서버 액세스 로깅	CloudTrail
기록 대상	모든 HTTP 요청	AWS API 호출
주요 사용처	트래픽 분석·이상 IP 감지	보안 감사·규정 준수
사용자 식별	IP 기반	IAM 사용자/역할 기반
형식	로그 파일 (텍스트)	JSON

CloudTrail은 누가(IAM 사용자/역할/서비스) 어떤 API를 호출했는지 기록해요. 회사 비유로 — 사물함 자체가 아니라 사물함 정책을 누가 바꿨는지·누가 권한을 변경했는지를 추적합니다.

데이터 이벤트 — 객체 단위 추적

기본 CloudTrail은 관리 이벤트(Management Events) — 버킷 생성·정책 변경 같은 것 — 만 기록해요. 객체 단위 작업(PutObject·GetObject)은 별도로 데이터 이벤트(Data Events) 를 켜야 추적됩니다.

# Trail 생성
aws cloudtrail create-trail \
  --name my-trail \
  --s3-bucket-name cloudtrail-logs-bucket

# S3 데이터 이벤트 활성화
aws cloudtrail put-event-selectors \
  --trail-name my-trail \
  --event-selectors '[{
    "ReadWriteType": "All",
    "IncludeManagementEvents": true,
    "DataResources": [{
      "Type": "AWS::S3::Object",
      "Values": ["arn:aws:s3:::my-sensitive-bucket/"]
    }]
  }]'

여기서 시험 함정이 하나 있어요. 데이터 이벤트는 추가 비용이 발생합니다. 모든 버킷에 켜면 비용이 빠르게 쌓이니 — 민감한 버킷에만 선택적으로 켜는 게 일반적이에요.

Athena로 CloudTrail 분석

CloudTrail 로그도 결국 S3에 JSON으로 떨어지니까 Athena로 SQL 분석이 가능해요.

CREATE EXTERNAL TABLE cloudtrail_logs (
  eventTime STRING,
  eventName STRING,
  eventSource STRING,
  awsRegion STRING,
  sourceIPAddress STRING,
  userIdentity STRUCT<type:STRING, principalId:STRING, arn:STRING>
)
ROW FORMAT SERDE 'com.amazon.emr.hive.serde.CloudTrailSerde'
STORED AS INPUTFORMAT 'com.amazon.emr.cloudtrail.CloudTrailInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION 's3://cloudtrail-logs-bucket/AWSLogs/123456789012/CloudTrail/';

-- 의심스러운 IP에서의 객체 삭제 시도 추적
SELECT eventTime, eventName, sourceIPAddress, userIdentity.arn
FROM cloudtrail_logs
WHERE eventName = 'DeleteObject'
  AND eventTime >= '2026-04-01'
ORDER BY eventTime DESC;

이 쿼리 한 방으로 — "지난달 누가 객체를 삭제했나"가 추적됩니다. 보안 사고 조사의 표준 패턴이에요.

> 한 줄 정리 — 서버 액세스 로깅 = 모든 요청. CloudTrail = AWS API 호출. 객체 단위는 CloudTrail 데이터 이벤트 켜야 잡힘.

S3 + AWS Config — 규정 준수 자동 점검

다음은 AWS Config — 회사 비유로 풀면 사물함 정책을 자동으로 점검하는 감사관입니다.

회사에서 "모든 자료는 암호화되어 있어야 한다", "공개 자료는 없어야 한다" 같은 규칙이 있어도 — 사람이 일일이 점검하면 빠뜨리기 쉽죠. AWS Config는 자동으로 모든 버킷을 검사하고 정책 위반이 있으면 알림을 보냅니다.

자주 쓰는 S3 Config 규칙

# S3 버킷 공개 읽기 차단 규칙
aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "s3-bucket-public-read-prohibited",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "S3_BUCKET_PUBLIC_READ_PROHIBITED"
    }
  }'

# S3 버킷 암호화 필수 규칙
aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "s3-bucket-server-side-encryption-enabled",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED"
    }
  }'

# S3 버킷 버전 관리 활성화 규칙
aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "s3-bucket-versioning-enabled",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "S3_BUCKET_VERSIONING_ENABLED"
    }
  }'

위 세 규칙만 걸어둬도 — 공개·암호화·버전 관리 세 영역의 위반이 자동 감지됩니다. 회사가 100개 버킷을 운영해도 매일 자동으로 검사가 돌아가는 셈이에요.

여기서 짚고 갈 점 — CloudTrail은 "변경 이력" 이고 AWS Config는 "현재 구성 + 정책 평가" 예요. 둘 다 비슷해 보이는데 자리가 달라요. CloudTrail은 "어제 누가 정책을 바꿨나", AWS Config는 "지금 이 버킷이 정책에 맞나"를 답해 줍니다.

S3 + SNS/SQS — 이벤트를 여러 부서에 동시 통보

이제 이벤트 분배 패턴이에요. S3 이벤트를 여러 곳에 동시에 통보해야 하는 시나리오에서 SNS·SQS가 등장합니다.

회사 비유로 — 사물함에 자료가 들어왔을 때 한 명의 직원만 알면 충분한 게 아니라 여러 부서에 동시에 알려야 할 때가 있어요. 마케팅 팀·보안 팀·분석 팀에 한 번에 통보하는 식.

S3 이벤트 → SNS Topic → SQS 대기열 (분석 팀)
                    → 이메일 (관리자)
                    → SMS (보안 팀)
                    → HTTP 엔드포인트 (외부 시스템)

설정 흐름

# 1. SNS Topic 생성
SNS_ARN=$(aws sns create-topic --name s3-events --query TopicArn --output text)

# 2. SQS 큐 생성
SQS_URL=$(aws sqs create-queue --queue-name s3-processing-queue --query QueueUrl --output text)
SQS_ARN=$(aws sqs get-queue-attributes \
  --queue-url $SQS_URL \
  --attribute-names QueueArn \
  --query Attributes.QueueArn --output text)

# 3. SNS → SQS 구독
aws sns subscribe \
  --topic-arn $SNS_ARN \
  --protocol sqs \
  --notification-endpoint $SQS_ARN

# 4. SNS → 이메일 구독
aws sns subscribe \
  --topic-arn $SNS_ARN \
  --protocol email \
  --notification-endpoint admin@example.com

# 5. S3 → SNS 이벤트 알림
aws s3api put-bucket-notification-configuration \
  --bucket my-bucket \
  --notification-configuration '{
    "TopicConfigurations": [{
      "Id": "S3ToSNS",
      "TopicArn": "'$SNS_ARN'",
      "Events": ["s3:ObjectCreated:*", "s3:ObjectRemoved:*"]
    }]
  }'

여기서 시험 함정이 하나 있어요. S3 이벤트를 직접 SQS에 보낼 수도 있는데 — 단일 대상이라면 그게 더 단순합니다. SNS를 끼워 넣는 이유는 여러 구독자에게 동시에 분배하기 위함이에요. 시험 보기에 "단일 SQS 대기열에만 보낸다"는 시나리오에서 SNS를 추가하라고 하면 함정입니다. 그럴 때는 S3 → SQS 직접 연결이 정답이에요.

Lambda vs SQS — 어느 쪽?

S3 이벤트를 Lambda로 직접 보낼 수도 있고 SQS에 넣어두고 컨슈머가 꺼내가게 할 수도 있어요. 차이점:

• Lambda 직접 — 즉시 처리, 짧은 작업, 동시성 자동 관리
• SQS — 처리량 제어 가능, 재시도 설정 유연, 장시간 작업 적합

흔한 패턴은 S3 → SQS → Lambda 또는 EC2 인데 — 트래픽 폭증 시 SQS가 버퍼 역할을 해서 다운스트림이 무너지지 않게 막아 줍니다.

S3 Inventory — 사물함 자료 전수조사 보고서

마지막으로 S3 Inventory — 회사 비유로 풀면 분기마다 사물함 안의 모든 자료를 한 줄씩 적어 정리하는 전수조사 보고서입니다.

S3 콘솔이나 CLI로 객체 목록을 매번 LIST API로 조회할 수도 있지만 — 객체 수가 수억 개 이상이면 LIST API로 다 훑는 데 비용도 시간도 큽니다. Inventory는 매일/매주 한 번 자동으로 모든 객체 정보를 CSV·Parquet 파일로 떨어뜨려 줘요.

포함되는 정보:

• 객체 키·크기·최종 수정일
• 스토리지 클래스
• 암호화 상태
• 복제 상태
• 객체 잠금 상태
• 멀티파트 업로드 미완료 여부

활용 시나리오

• 비용 분석 — 어떤 클래스에 얼마만큼 있는지 한눈에
• 규정 준수 확인 — 비암호화 객체 일괄 식별
• Batch Operations 입력 — 대량 작업의 매니페스트 파일로 사용
• Athena 분석 — Parquet로 출력하면 SQL 분석 가능

# Inventory 설정
aws s3api put-bucket-inventory-configuration \
  --bucket my-source-bucket \
  --id daily-inventory \
  --inventory-configuration '{
    "Id": "daily-inventory",
    "IsEnabled": true,
    "Destination": {
      "S3BucketDestination": {
        "Bucket": "arn:aws:s3:::my-inventory-bucket",
        "Format": "Parquet",
        "Prefix": "inventory-reports/"
      }
    },
    "Schedule": {"Frequency": "Daily"},
    "IncludedObjectVersions": "Current",
    "OptionalFields": [
      "Size", "LastModifiedDate", "StorageClass",
      "EncryptionStatus", "ReplicationStatus"
    ]
  }'

여기서 시험 함정이 하나 있어요. Inventory 보고서가 즉시 생성되지 않습니다. 첫 보고서는 최대 48시간 후에야 받을 수 있어요. 시험 시나리오에 "지금 당장 객체 목록이 필요하다"라고 나오면 Inventory가 아니라 LIST API 또는 콘솔 직접 조회가 답입니다.

S3 + Cost Explorer — 비용 분해

마지막 보너스로 Cost Explorer입니다. S3 비용을 어디서 가장 많이 쓰는지 분해해서 보는 도구예요.

# S3 비용 조회 (지난 30일)
aws ce get-cost-and-usage \
  --time-period Start=2024-01-01,End=2024-01-31 \
  --granularity MONTHLY \
  --filter '{
    "Dimensions": {
      "Key": "SERVICE",
      "Values": ["Amazon Simple Storage Service"]
    }
  }' \
  --group-by '[{"Type": "DIMENSION", "Key": "USAGE_TYPE"}]' \
  --metrics BlendedCost

USAGE_TYPE으로 그룹화하면 — 저장 비용·요청 비용·데이터 전송 비용·검색 비용이 따로 보여요. "왜 이번 달 S3 청구서가 많이 나왔지?" 라는 질문에 답하기 좋습니다.

태그를 활용한 팀별 비용 할당도 가능해요. 부서별로 Team 태그를 걸어 두면 어느 팀이 얼마를 쓰는지 분리해서 볼 수 있습니다. 1편의 객체 태그 단원에서 짚었던 내용이 여기서 빛을 봅니다.

통합 아키텍처 패턴 — CloudFront·Lambda 한 그림으로 보기

지금까지 다룬 통합 패턴을 실제 아키텍처로 묶어 볼게요. 시험에 자주 나오는 3가지 패턴이에요.

데이터 레이크 아키텍처

데이터 소스 (IoT·앱·DB)
    ↓
S3 Raw 버킷 (원본 데이터)
    ↓ Lambda / Glue ETL
S3 Processed 버킷 (변환된 데이터, Parquet)
    ↓ 파티셔닝
Athena / Redshift Spectrum (SQL 분석)
    ↓
QuickSight / Jupyter (시각화)

여기서 핵심은 Raw → Processed 두 단계예요. Raw는 원본 그대로, Processed는 Parquet으로 변환해서 분석이 빠르고 저렴하게. 회사 비유로 — 자료가 들어오는 대로 일단 사물함에 넣고, 분석용으로는 정리된 사본을 따로 만드는 식.

미디어 처리 파이프라인

업로드 → S3 (raw-media/)
    ↓ 이벤트 알림
Lambda (메타데이터 추출)
    ↓
SQS (처리 대기열)
    ↓
EC2 / Lambda (트랜스코딩)
    ↓
S3 (processed-media/)
    ↓
CloudFront (CDN 배포)
    ↓
최종 사용자

이 패턴이 흔한 이유는 — 트랜스코딩이 무거워서 Lambda로는 부족할 때가 많아서예요. 그래서 SQS를 버퍼로 두고 EC2 인스턴스가 큐에서 작업을 꺼내 처리합니다.

정적 웹사이트 고가용성 구성

Route 53 (DNS)
    ↓
CloudFront (CDN + HTTPS, OAC로 S3 보호)
    ↓
S3 (정적 자산: HTML·CSS·JS·이미지)
    +
API Gateway + Lambda (동적 API)
    +
DynamoDB (DB)

이게 모던 서버리스 웹앱의 표준 구조예요. EC2 한 대도 안 띄우고 글로벌 웹 서비스를 운영할 수 있어요. 트래픽이 0이면 비용도 0에 가깝고, 100배 늘어도 자동 확장.

> 한 줄 정리 — 데이터 레이크·미디어 파이프라인·정적 웹사이트 — 이 셋이 S3 통합의 대표 패턴.

시리즈 다른 편

같은 시리즈의 다른 글들도 같은 친절 톤으로 묶어 정리되어 있어요.

• 1편 — 기초
• 2편 — 보안
• 3편 — 성능 최적화
• 4편 — 복제
• 5편 — 라이프사이클
• 6편 — 고급 기능
• 7편 — AWS 통합 (완) (현재 글, 완결)

시험 직전 한 번 더 — CloudFront·Lambda 통합 함정 모음

마지막 단원의 핵심을 압축 노트로 정리할게요.

• S3 = AWS 생태계의 뼈대, EC2 AMI·CloudTrail 로그 등도 S3에 저장
• Lambda + S3 — 이벤트 기반 자동 처리. 권한 부여 + 트리거 설정 두 단계 모두 필요
• 같은 버킷에 결과 다시 쓰면 무한 루프 — 출력 버킷 분리 또는 접두사 필터로 방지
• CloudFront + S3 — 글로벌 CDN. OAC로 S3 직접 접근 차단 (OAI는 레거시)
• 정적 웹사이트 표준 = S3 + CloudFront + Route 53
• index.html은 짧은 캐시, 해시 파일명 자산은 긴 캐시
• Athena = 서버리스 SQL on S3. 스캔 데이터 양만큼 과금
• 비용 절감 핵심 — Parquet + 파티셔닝. 같은 데이터라도 비용 1/10
• 외부 테이블 = 데이터는 S3에 그대로, 스키마만 씌움
• Glacier 복원은 즉시 X — Restore 요청 후 며칠 사본 생성
• Glacier Flexible — Expedited(1~5분) / Standard(3~5h) / Bulk(5~12h)
• Glacier Deep Archive — 표준 12h / 대량 48h, Expedited 미지원
• Storage Lens 권고사항은 고급 티어에서만 제공 (백만 객체당 $0.20)
• 서버 액세스 로깅 vs CloudTrail — 모든 요청 vs AWS API 호출
• 로그 저장 버킷과 소스 버킷 분리 필수 (무한 루프 방지)
• CloudTrail 객체 단위 추적은 데이터 이벤트 별도 활성화 (추가 비용)
• AWS Config = 현재 구성 + 정책 평가, CloudTrail = 변경 이력
• S3 → SNS → 여러 SQS·이메일·HTTP 분배. 단일 대상이면 SNS 불필요
• S3 → SQS → Lambda/EC2 — 트래픽 폭증 버퍼링
• S3 Inventory — 일/주 단위 객체 전수조사. 첫 보고서는 최대 48시간 후
• Inventory는 즉시 X — 즉시 목록은 LIST API
• Cost Explorer로 USAGE_TYPE별 분해 + 태그로 팀별 할당
• 데이터 레이크 = Raw → Processed (Parquet) → Athena 패턴
• 미디어 파이프라인 = S3 → SQS → EC2/Lambda → S3 → CloudFront

시리즈 전체 압축 — CloudFront까지 7편을 한 페이지에

여기까지 7편을 통과하셨으니 — 마지막으로 시리즈 전체를 한 페이지에 압축해 둘게요. 시험 직전·실무에서 빠르게 펼쳐 볼 수 있는 카드처럼 쓰면 좋아요.

• 1편 기초 — 객체 스토리지·평면 구조·접두사·11 nines 내구성·99.99% 가용성·버킷 이름 전 세계 고유·스토리지 클래스 7종·strong consistency
• 2편 보안 — IAM·버킷 정책·ACL·CORS·Block Public Access·MFA Delete·Object Lock(생성 시점만)·Presigned URL
• 3편 성능 — 멀티파트 업로드(5GB+ 필수)·Transfer Acceleration·Byte-Range Fetch·CloudFront 캐싱·동시성 한계
• 4편 암호화 — SSE-S3·SSE-KMS·SSE-C·DSSE-KMS·CSE·Bucket Keys로 KMS 비용 절감
• 5편 라이프사이클·복제 — Lifecycle Rules로 자동 클래스 전환/삭제·CRR/SRR·복제 비용 함정·삭제 마커 복제
• 6편 고급 기능 — Object Lock(WORM)·Versioning 깊이·Batch Operations·Access Points·Multi-Region Access Points·Requester Pays
• 7편 통합 (오늘) — Lambda·CloudFront·Athena·Glacier 복원·Storage Lens·CloudTrail·AWS Config·SNS/SQS·Inventory·Cost Explorer

이 7개 단원이 머리에 한 그림으로 들어오면 — AWS Solutions Architect Associate(SAA)와 Specialty 시험의 S3 영역은 거의 다 잡혔다고 봐도 됩니다. 실무에서도 80% 이상의 시나리오는 위 카드만으로 처리됩니다.

이 시리즈를 마치며

여기까지 정말 고생 많으셨어요. 처음 1편에서 "객체 스토리지가 뭐야?" 부터 시작해서 — 보안·성능·암호화·라이프사이클·고급 기능을 거쳐 — 오늘 마지막 통합 단원까지. S3라는 한 서비스만으로도 이만큼 깊이가 있다는 게 신기하지 않나요?

S3가 단순한 파일 저장소가 아니라 — AWS 생태계의 뼈대이고·데이터 레이크의 중심이고·서버리스 아키텍처의 출발점이라는 사실이, 이 시리즈를 통해 자연스럽게 손에 잡혔으면 좋겠어요.

한 가지 마음에 새기고 가셨으면 하는 게 있어요. "S3는 사물함이다" 라는 비유. 시험에서 헷갈리거나 실무에서 새 패턴을 만났을 때 — 이 비유 한 줄로 돌아가면 항상 길이 보일 거예요.

• 자료를 어디 둘까? → 자주 보면 책상 옆, 가끔 보면 창고
• 보안은? → 사물함에 자물쇠와 출입카드
• 백업은? → 다른 지역 사물함에 사본
• 정리는? → 자동 라이프사이클로 알아서
• 분석은? → 사물함 자료에 SQL 그대로
• 글로벌 배포는? → 동네 매장에서 캐싱
• 감사는? → 출입 일지와 정책 점검

어떤 새 기능이 나와도 — 이 비유 안에 자리가 있어요. AWS가 새 서비스를 발표해도 "아, 그건 사물함의 OO 역할이구나"로 풀리니까요.

긴 시리즈 끝까지 함께해 주셔서 감사합니다. 다음 시리즈에서는 또 다른 AWS 서비스를 같은 톤으로 풀어 볼 거예요. EC2·VPC·RDS 어느 쪽이든 — 회사 비유로 처음부터 천천히 가는 그 호흡, 그대로 가져갑니다. 그때 또 만나요.