티스토리 뷰

Q1)

S3

-> 파일을 객체 단위로 저장하는 AWS의 클라우드 저장소 (객체 스토리지)

 

S3 Transfer Acceleration

-> 전 세계 어디서 업로드하든 가장 가까운 AWS 엣지(CloudFront)로 먼저 받아서,

AWS 내부 고속망으로 S3까지 빠르게 보내주는 기능.

 

CloudFront

-> CloudFront는 전 세계 엣지 로케이션을 이용해 콘텐츠를 빠르게 전달하는 AWS의 CDN 서비스다.

 

CDN(콘텐츠 전송 네트워크)

-> CDN은 전 세계에 분산된 서버를 통해 가까운 곳에서 콘텐츠를 전달하는 기술

 

 

#시험 포인트

글로벌 업로드, 빠른 업로드, S3로 직접 업로드, 운영 복잡성 최소 → S3 Transfer Acceleration


 

Q2)

Athena

-> S3 데이터를 이동 없이 SQL로 바로 조회하는 서버리스 분석 서비스

 

쿼리(Query)

-> 데이터에게 질문하는 것 (데이터 → 질문 → 결과 받기)

 

로그(Log)

-> 시스템에서 발생한 이벤트 기록 (에러·보안·사용자 행동 분석을 위해 저장)

 

SQL

-> 데이터를 조회하는 질문 언어

 

쉬운 비유]

로그 = CCTV 기록

SQL = CCTV 검색 기능

쿼리 = "오늘 오후 3시 영상 보여줘"

Athena = CCTV 저장소(S3)를 직접 검색하는 도구

 

 

#시험 포인트

S3에 로그 저장, SQL로 분석, 서버 관리 X, 빠르게 조회 → Athena


 

Q3)

aws:PrincipalOrgID

-> 리소스 정책에서 같은 AWS Organization 소속 계정만 접근하도록 제한할 사용하는 조건

 

 

#시험 포인트

Organization 전체 접근 제어 → aws:PrincipalOrgID


 

Q4)

Gateway VPC Endpoint

-> VPC에서 S3 인터넷 없이 AWS 내부망을 통해 접근하게 해주는 서비스

 

EC2 → S3 접근하려면

인터넷 게이트웨이(IGW) 또는 NAT Gateway 경로 사용

하지만 보안상 인터넷 통과하고 싶지 않음

→ Private 연결 필요

 

Gateway Endpoint 생성 시 VPC 라우트 테이블에 S3 전용 경로가 자동 추가됨

S3 가는 트래픽은 인터넷이 아니라 Endpoint 통해 AWS 내부망으로 전달됨

 

라우트테이블

→ 트래픽을 어디로 보낼지 정하는 안내판

 

VPC

-> AWS 안에 만드는 나만의 가상 네트워크 공간

(EC2 VPC 안에서 실행되는 가상 서버)

 

 

#시험 포인트

VPC → S3 → 인터넷 없이 → Gateway Endpoint


Q5)

EBS

-> 단일 EC2에 연결되는 블록 스토리지 (공유 불가)

EFS 

-> 여러 EC2가 동시에 공유 가능한 파일 스토리지

 

EBS 기본적으로 하나의 EC2에만 연결 가능

EC2 A → EBS A

EC2 B → EBS B

저장공간 서로 다르고, 사용자마다 다른 파일 보임

 

EC2 A → EFS

EC2 B → EFS

같은 파일 시스템 사용, 모든 문서 동일하게 보임, 동시에 읽기/쓰기 가능

 

 

#시험 포인트

여러 EC2 + 공유 파일 = EFS


Q6)

AWS Snowball

-> 대용량 데이터를 네트워크를 사용하지 않고 물리 장치를 통해 AWS 이전하는 오프라인 데이터 전송 서비스

 

동작방식)

  1. AWS가 Snowball 장치 배송
  2. 로컬 네트워크에서 Snowball 장치로 고속 복사
  3. 장치를 AWS로 반송
  4. AWS가 S3에 업로드

네트워크 업로드는 상대적으로 느리고, 지속적 대역폭 점유

Snowball은 네트워크 사용 거의 없이 내부 LAN속도 활용

→ 대용량 적합

 

* Snowball Edge 

Snowball에 컴퓨팅 기능(EC2, Lambda)이 추가된 확장형 장치

단순 데이터 전송이 아니라 현장에서 데이터 처리 가능

오프라인/열악한 환경에서 엣지 컴퓨팅 필요 시 사용

(현재는 대부분 Snowball Edge가 기본 선택)

 

엣지 컴퓨팅 (Edge Computing)

-> 데이터를 클라우드로 보내기 전에, 데이터가 생성되는 현장(Edge)에서 직접 처리하는 방식

 

 

#시험 포인트

50 TB 이상대용량 + 네트워크대역폭최소 + 빠른이전→ AWS Snowball


Q7)

Amazon SNS (Simple Notification Service)

-> 말하면, 듣고 있는 애들 전부 듣는다

 

SNS는 Pub/Sub(Publish / Subscribe) 모델

  • Publisher(발행자)가 메시지를 던짐
  • Subscriber(구독자)들이 그 메시지를 받음
  • 발행자와 구독자는 서로를 모름 (완전 분리)

ex. 유튜브 채널에 영상 올리면 구독자들에게 자동으로 알림 가는 구조

(PUSH 방식 → SNS가 구독자에게 직접 전달)

 

Amazon SQS (Simple Queue Service)

-> 메시지를 안전하게 저장하고 소비자가 가져가도록 하는 Queue 서비스

// 생산자와 소비자를 분리(디커플링)하는 완충지대(Buffer)

 

SQS는 Queue(대기열) 기반

  • 메시지를 큐(대기열)에 저장
  • 소비자가 Polling 방식으로 가져감
  • 버퍼 역할 수행

Queue(큐)

→ 줄 서는 구조 (FIFO 개념) // 메시지가 큐에 쌓이고 소비자가 하나씩 꺼내 처리

 

Polling 방식 (→ Pull 방식)

SQS는 Pull 모델

 

소비자가:

메시지 있어?”, “지금 처리할 있어?”

이렇게 계속 물어보는 방식이 Polling.

 

Fanout 패턴

SNS는 브로드캐스트 잘함

SQS는 버퍼링 + 안정적 처리 잘함

  1. SNS가 이벤트를 뿌림
  2. 여러 SQS 큐로 복제
  3. 각 서비스는 자기 큐만 폴링
  4. 서로 영향 없이 확장

 

#시험 포인트

다수 소비자, 디커플링, 트래픽 급증, 각 서비스 독립 처리 → SNS + SQS Fanout


Q8)

EC2 Auto Scaling
-> 부하에 따라 EC2 인스턴스를 자동으로 늘리거나 줄이는 서비스

 

레거시(Legacy)

→ 예전 방식의 확장성 떨어지는 기존 시스템

(보통 확장성 부족, 탄력성 부족, 수동 운영, 현대화 필요)

 

아키텍처 적용

레거시 구조문제 -> 작업 분산 + 탄력성 확보 필요

// SQS로 작업 큐 분리 (디커플링)

  • 생산자는 작업을 큐에 저장
  • 소비자는 큐에서 Polling으로 가져가 처리
  • 서로 직접 통신하지 않음

확장 구조

컴퓨팅 노드는 EC2 Auto Scaling 그룹으로 구성

핵심은 Queue Size(아직 처리되지 않은 작업 개수) 기준 Scaling

 

작업 많으면 → EC2 증가 (Scale-Out)

작업 적으면 → EC2 감소 (Scale-In)

 

 

#시험 포인트

분산 작업 처리 + 자동 확장” = SQS + Auto Scaling (queue length 기준)


Q9)

SMB 유지하면서 저장공간만 늘려야 함 + 최근 파일은 저지연 필요

→ File Gateway가 로컬 캐시 제공 원본 데이터는 S3로 확장 저장

→ 온프레미스 용량 압박 해소 S3 Lifecycle로 7일 이후 거의 안 보는 파일을

Glacier Deep Archive로 자동 전환 → 수명주기 관리

 

< S3는 장기 보관 창고, File Gateway는 자주 쓰는 파일을 로컬 캐시에 두는 서랍 역할 >

 

AWS Storage Gateway - File Gateway

→ SMB/NFS 인터페이스를 유지하면서 데이터를 S3에 저장 (로컬 캐시로 최근 파일은 저지연 제공, 원본은 S3에 저장)

 

*SMB

→ 네트워크를 통해 파일·폴더를 공유하기 위한 프로토콜(주로 Windows 환경)

 

Amazon S3 Lifecycle

-> S3 객체를 일정 기간 후 자동으로 다른 스토리지 클래스로 이동하거나 삭제하는 수명주기 정책 기능

 

Amazon S3 Glacier Deep Archive

-> 가장 저렴한 장기 보관 스토리지 클래스. 복구는 느리지만 비용 최소화.

 

 

#시험 포인트

SMB/NFS 유지 + 로컬 캐시 + S3로 확장 + Lifecycle = Storage Gateway File Gateway


Q10)

요구사항 핵심: 주문을 받은 순서대로 처리 → 순서 보장 필요

 

SQS FIFO Queue는 순서(order) 보장 + 중복 방지 제공

SQS Standard는 순서 보장 없음 → 부적합

 

FIFO = 줄 서기 먼저 온 사람이 먼저 계산

Standard = 여러 계산대에서 동시에 처리(높은 처리량이 목적)

순서가 바뀔 수 있음

 

 

#시험 포인트

순서 보장 필요” = SQS FIFO (정답)

 

 

 

 

 

 

 

 

 

 

 

 

 

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2026/05   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
글 보관함