My tiny life in DE

독일어 공부 - 주격 변화 #1

ReinaMoon — Sun, 17 Aug 2025 04:31:51 +0900

소유자	남성 (der Hund)	여성 (die Katze)	중성 (das Auto)	복수 (die Kinder)
ich	mein / meinen Das ist mein Hund. (이것은 나의 강아지이다.) Ich mag meinen Hund. (나는 나의 강아지를 좋아한다.)	meine / meine Das ist meine Katze. (이것은 나의 고양이이다.) Ich mag meine Katze.(나는 나의 고양이를 좋아한다.)	mein / mein Das ist mein Auto. (이것은 나의 자동차이다.) Ich mag mein Auto. (나는 나의 자동차를 좋아한다.)	meine / meine Das sind meine Kinder. (이것들은 나의 아이들이다.) Ich mag meine Kinder. (나는 나의 아이들을 좋아한다.)
du	dein / deinen Das ist dein Hund. (이것은 너의 강아지이다.) Ich mag deinen Hund. (나는 너의 강아지를 좋아한다.)	deine / deine Das ist deine Katze. (이것은 너의 고양이이다.) Ich mag deine Katze. (나는 너의 고양이를 좋아한다.)	dein / dein Das ist dein Auto. (이것은 너의 자동차이다.) Ich mag dein Auto. (나는 너의 자동차를 좋아한다.)	deine / deine Das sind deine Kinder. (이것들은 너의 아이들이다.) Ich mag deine Kinder. (나는 너의 아이들을 좋아한다.)
er	sein / seinen Das ist sein Hund. (이것은 그의 강아지이다.) Ich mag seinen Hund. (나는 그의 강아지를 좋아한다.)	seine / seine Das ist seine Katze. (이것은 그의 고양이이다.) Ich mag seine Katze. (나는 그의 고양이를 좋아한다.)	sein / sein Das ist sein Auto. (이것은 그의 자동차이다.) Ich mag sein Auto. (나는 그의 자동차를 좋아한다.)	seine / seine Das sind seine Kinder. (이것들은 그의 아이들이다.) Ich mag seine Kinder. (나는 그의 아이들을 좋아한다.)
sie (그녀)	ihr / ihren Das ist ihr Hund. (이것은 그녀의 강아지이다.) Ich mag ihren Hund. (나는 그녀의 강아지를 좋아한다.)	ihre / ihre Das ist ihre Katze. (이것은 그녀의 고양이이다.) Ich mag ihre Katze. (나는 그녀의 고양이를 좋아한다.)	ihr / ihr Das ist ihr Auto. (이것은 그녀의 자동차이다.) Ich mag ihr Auto. (나는 그녀의 자동차를 좋아한다.)	ihre / ihre Das sind ihre Kinder. (이것들은 그녀의 아이들이다.) Ich mag ihre Kinder. (나는 그녀의 아이들을 좋아한다.)
wir	unser / unseren Das ist unser Hund. (이것은 우리의 강아지이다.) Ich mag unseren Hund. (나는 우리의 강아지를 좋아한다.)	unsere / unsere Das ist unsere Katze. (이것은 우리의 고양이이다.) Ich mag unsere Katze. (나는 우리의 고양이를 좋아한다.)	unser / unser Das ist unser Auto. (이것은 우리의 자동차이다.) Ich mag unser Auto. (나는 우리의 자동차를 좋아한다.)	unsere / unsere Das sind unsere Kinder. (이것들은 우리의 아이들이다.) Ich mag unsere Kinder.(나는 우리의 아이들을 좋아한다.)
ihr	euer / euren Das ist euer Hund. (이것은 너희의 강아지이다.) Ich mag euren Hund. (나는 너희의 강아지를 좋아한다.)	eure / eure Das ist eure Katze. (이것은 너희의 고양이이다.) Ich mag eure Katze. (나는 너희의 고양이를 좋아한다.)	euer / euer Das ist euer Auto. (이것은 너희의 자동차이다.) Ich mag euer Auto. (나는 너희의 자동차를 좋아한다.)	eure / eure Das sind eure Kinder. (이것들은 너희의 아이들이다.) Ich mag eure Kinder. (나는 너희의 아이들을 좋아한다.)
sie (그들)	ihr / ihren Das ist ihr Hund. (이것은 그들의 강아지이다.) Ich mag ihren Hund. (나는 그들의 강아지를 좋아한다.)	ihre / ihre Das ist ihre Katze. (이것은 그들의 고양이이다.) Ich mag ihre Katze. (나는 그들의 고양이를 좋아한다.)	ihr / ihr Das ist ihr Auto. (이것은 그들의 자동차이다.) Ich mag ihr Auto. (나는 그들의 자동차를 좋아한다.)	ihre / ihre Das sind ihre Kinder. (이것들은 그들의 아이들이다.) Ich mag ihre Kinder. (나는 그들의 아이들을 좋아한다.)
Sie (존칭)	Ihr / Ihren Das ist Ihr Hund. (이것은 당신의 강아지입니다.) Ich mag Ihren Hund. (나는 당신의 강아지를 좋아합니다.)	Ihre / Ihre Das ist Ihre Katze. (이것은 당신의 고양이입니다.) Ich mag Ihre Katze. (나는 당신의 고양이를 좋아합니다.)	Ihr / Ihr Das ist Ihr Auto. (이것은 당신의 자동차입니다.) Ich mag Ihr Auto. (나는 당신의 자동차를 좋아합니다.)	Ihre / Ihre Das sind Ihre Kinder. (이것들은 당신의 아이들입니다.) Ich mag Ihre Kinder. (나는 당신의 아이들을 좋아합니다.)

AWS CLF-02(AWS Certified Cloud Practitioner) 시험 전 최종 요약

ReinaMoon — Tue, 12 Aug 2025 07:21:44 +0900

이 시험은 "클라우드의 가치를 이해하고, AWS의 주요 서비스들이 어떤 문제를 해결하기 위해 존재하는지 알고 있습니까?"를 묻는 기초(Foundational) 시험임.

따라서 시험의 90% 이상은 핵심 서비스들의 목적, 개념, 그리고 비즈니스 가치를 묻는 질문으로 구성됨.

"어떤 서비스가 웹 공격을 막나요?" -> WAF
"어떤 서비스가 비용을 예측하고 알려주나요?" -> Budgets
"어떤 서비스가 우리 회사와 AWS를 전용선으로 연결해주나요?" -> Direct Connect

Part 1: 클라우드의 기본 규칙 - 이것 모르면 시작도 못해요!

"이것만 알면 끝!": 비싼 초기 투자 대신 쓴 만큼만 내고, 빠르고, 전 세계로 확장하고, 민첩하게 움직일 수 있다!

자본 비용을 가변 비용으로 전환 (CAPEX -> OPEX):
- 설명: 서버를 사기 위해 큰돈을 미리 쓸 필요 없이, 매달 전기요금처럼 사용한 만큼만 비용을 낸다.
- 시험 포인트: "회사가 대규모 초기 하드웨어 투자를 피하고 싶어 한다" -> 이 장점을 고르세요.
규모의 경제로 인한 이점:
- 설명: AWS가 전 세계 수백만 고객을 대상으로 엄청나게 많은 서버를 구매하므로, 개인이 구매하는 것보다 훨씬 저렴하게 우리에게 제공할 수 있다.
- 시험 포인트: "수많은 사용자의 사용량을 집계하여 더 낮은 종량제 요금을 제공하는 것" -> 규모의 경제.
용량 추정 불필요:
- 설명: "서버를 몇 대나 사야 할까?" 고민할 필요 없이, 필요하면 늘리고(Scale-up/out), 필요 없으면 줄이면(Scale-down/in) 된다.
- 시험 포인트: "트래픽 예측의 불확실성을 제거해 주는 이점은?" -> 용량 추정 불필요.
속도 및 민첩성 향상:
- 설명: 서버 한 대 주문하고 설치하는 데 몇 주씩 걸리던 일을, 단 몇 분 만에 클릭 몇 번으로 끝낼 수 있다.
- 시험 포인트: "개발팀이 몇 주가 아닌 몇 분 만에 새로운 인프라를 프로비저닝할 수 있게 되었다." -> 속도 및 민첩성.
데이터 센터 운영 및 유지 관리에 비용 투자 불필요:
- 설명: 서버실 전기세, 냉방비, 물리 보안, 하드웨어 교체 같은 귀찮은 일을 AWS가 대신해 주니, 우리는 우리 비즈니스에만 집중할 수 있다.
- 시험 포인트: "기업이 핵심 비즈니스 가치에 집중할 수 있게 해주는 이점은?" -> 데이터 센터 유지 관리 비용 불필요.
몇 분 만에 전 세계로 서비스 확장:
- 설명: 미국에서 서비스를 시작하고, 다음 날 유럽과 아시아에도 클릭 몇 번으로 똑같은 서비스를 배포할 수 있다.
- 시험 포인트: "애플리케이션을 여러 지리적 위치에 쉽게 배포할 수 있는 능력" -> 글로벌 확장.

"이것만 알면 끝!": AWS는 건물(클라우드 자체)을 책임지고, 우리는 집 안(클라우드 안의 데이터)을 책임진다.

AWS의 책임 (클라우드 OF 보안):
- 핵심: AWS가 제공하는 인프라 자체에 대한 보안.
- 예시: 데이터 센터 물리적 보안, 서버 하드웨어, 네트워크 장비, 하이퍼바이저(가상화 기술).
- 비유: 아파트 건설사. 튼튼한 건물, 완벽한 전기/수도 시설, 24시간 경비 시스템을 제공.
고객의 책임 (클라우드 IN 보안):
- 핵심: 우리가 클라우드 안에 올리는 모든 것.
- 예시: 우리의 데이터 암호화, IAM을 통한 사용자 접근 제어, 보안 그룹 설정, 운영 체제(OS) 패치, 애플리케이션 보안.
- 비유: 아파트 입주민. 현관문 비밀번호 설정, 집 안 귀중품 관리, 가스 밸브 잠그기.

"시험에 이렇게 나옵니다":

"데이터 센터의 물리적 보안은 누가 책임지는가?" -> AWS
"EC2 인스턴스에 설치된 운영 체제의 보안 패치는 누가 책임지는가?" -> 고객
"S3 버킷에 저장된 데이터를 암호화할 책임은 누구에게 있는가?" -> 고객

"이것만 알면 끝!": 안정적이고, 안전하고, 빠르고, 저렴하고, 운영하기 편하고, 친환경적인 클라우드 아키텍처를 만들기 위한 6가지 기둥.

운영 우수성 (Operational Excellence): 운영을 자동화하고, 절차를 개선하며, 장애로부터 빠르게 복구하는 능력.
보안 (Security): 정보와 시스템을 보호하는 능력. (공동 책임 모델, IAM 등)
신뢰성 (Reliability): 장애를 견디고, 인프라나 서비스 장애로부터 자동으로 복구하는 능력. (Auto Scaling, 다중 AZ)
성능 효율성 (Performance Efficiency): 컴퓨팅 리소스를 효율적으로 사용하여 최적의 성능을 유지하는 능력.
비용 최적화 (Cost Optimization): 불필요한 비용을 제거하고 가장 저렴하게 시스템을 운영하는 능력.
지속 가능성 (Sustainability): 클라우드 워크로드의 환경적 영향을 최소화하는 능력. (필요한 만큼만 사용)

"시험에 이렇게 나옵니다":

"실패를 견디고 자동으로 복구하는 아키텍처는 어떤 원칙을 따르는가?" -> 신뢰성
"불필요한 리소스를 제거하여 비용을 절감하는 것은 어떤 원칙에 해당하는가?" -> 비용 최적화

Part 2: AWS 핵심 서비스 - 레고 블록처럼 조립하기

"이것만 알면 끝!": 인터넷용 파일 창고(S3), EC2 전용 외장하드(EBS), 여러 EC2가 함께 쓰는 회사 공유 폴더(EFS).

구분 항목	️ S3 (Simple Storage Service)	EBS (Elastic Block Store)	EFS (Elastic File System)
스토리지 유형	객체(Object) 스토리지	블록(Block) 스토리지	파일(File) 스토리지
주요 용도	이미지, 동영상 등 파일 저장, 백업, 정적 웹사이트 호스팅	EC2 인스턴스의 운영체제(OS) 및 데이터 디스크	여러 EC2 인스턴스에서 동시 접근하는 데이터 공유
연결 방식	인터넷을 통해 HTTP/HTTPS로 접근	단 하나의 EC2 인스턴스에 연결	여러 EC2 인스턴스에 동시 연결
비유	구글 드라이브 / 드롭박스	컴퓨터에 꽂는 외장 하드	사내 네트워크 공유 드라이브

"시험에 이렇게 나옵니다":

"웹사이트의 이미지와 동영상을 저장하고 싶다. 어떤 서비스를 써야 하는가?" -> S3
"EC2 인스턴스의 부팅 디스크로 사용할 스토리지는?" -> EBS
"여러 웹 서버가 동시에 로그 파일을 쓰고 읽어야 한다. 어떤 스토리지를 써야 하는가?" -> EFS

"이것만 알면 끝!": 24시간 켜두는 내 가상 컴퓨터(EC2)와, 필요할 때만 잠깐 나타나서 일하고 사라지는 이벤트 처리 알바생(Lambda).

구분 항목	EC2 (Elastic Compute Cloud)	⚡ Lambda
개념	가상 서버 (컴퓨터 한 대를 빌리는 것)	서버리스 컴퓨팅 (코드만 올리면 알아서 실행)
관리 주체	OS, 보안 패치, 소프트웨어 설치 등 고객이 직접 관리	AWS가 모두 관리 (고객은 코드만 신경 씀)
과금 방식	시간 단위 (켜져 있는 동안 계속 과금)	실행 시간(ms) 및 호출 횟수 (실행될 때만 과금)
비유	내 소유의 자동차 (유지보수, 주유 직접 해야 함)	택시 (필요할 때 부르고, 탄 만큼만 요금 냄)

"시험에 이렇게 나옵니다":

"완전한 제어 권한을 가지고 웹 서버를 운영하고 싶다." -> EC2
"S3에 이미지가 업로드될 때마다 자동으로 썸네일을 생성하는 기능을 만들고 싶다. 서버 관리는 하고 싶지 않다." -> Lambda

"이것만 알면 끝!": 정해진 표 형식의 데이터를 다루는 관계형 DB(RDS)와, 자유로운 형식의 데이터를 엄청나게 빠르게 처리하는 NoSQL DB(DynamoDB).

구분 항목	RDS (Relational Database Service)	DynamoDB
데이터 유형	관계형(SQL)	비관계형(NoSQL)
구조	스키마(엄격한 표 구조)가 미리 정해져 있음	스키마가 없음 (유연한 구조)
주요 엔진	MySQL, PostgreSQL, Aurora 등	자체 엔진
최적 용도	정형 데이터, 복잡한 쿼리, 트랜잭션	대규모 트래픽, 한 자릿수 밀리초의 빠른 응답, 유연한 데이터 모델
비유	엑셀 시트 (행과 열이 명확함)	메모장 (어떤 형식이든 자유롭게 기록 가능)

"시험에 이렇게 나옵니다":

"기존의 MySQL 데이터베이스를 클라우드로 이전하고 싶다." -> RDS 또는 Aurora
"모바일 게임의 사용자 순위표처럼, 초당 수백만 건의 읽기/쓰기 요청을 처리해야 한다." -> DynamoDB

"이것만 알면 끝!": 집(VPC)을 짓고, 방(Subnet)을 나누고, 현관문(IGW)을 달고, 길 안내(Route Table)를 설정한다.

VPC (Virtual Private Cloud):
- 개념: AWS 클라우드 내의 나만의 격리된 네트워크 공간.
- 비유: 내가 살 집의 부지.
서브넷 (Subnet):
- 개념: VPC를 더 작은 네트워크로 나눈 것. Public Subnet과 Private Subnet이 있다.
- 비유: 집 안의 방. 거실(Public)과 침실(Private)로 나눌 수 있다.
인터넷 게이트웨이 (IGW):
- 개념: VPC와 인터넷을 연결하는 통로.
- 비유: 집의 현관문. 이 문이 있어야 인터넷(집 밖)으로 나갈 수 있다.
라우트 테이블 (Route Table):
- 개념: 네트워크 트래픽이 어디로 가야 할지 알려주는 규칙 모음.
- 비유: 집 안의 길 안내 표지판 또는 스마트폰 GPS. "인터넷으로 가려면 현관문(IGW)으로 가세요" 라고 알려준다.

"시험에 이렇게 나옵니다":

"VPC가 인터넷과 통신하려면 무엇이 필요한가?" -> 인터넷 게이트웨이
"데이터베이스 서버처럼 외부에서 직접 접근하면 안 되는 리소스는 어디에 두어야 하는가?" -> 프라이빗 서브넷

Part 3: 관리, 배포, 지원 - 클라우드를 더 잘 쓰기 위한 도구들

"이것만 알면 끝!": 교통정리(ELB)를 하다가 차가 많아지면 도로를 넓힌다(Auto Scaling).

ELB (Elastic Load Balancing):
- 개념: 들어오는 트래픽을 여러 대의 EC2 인스턴스에 자동으로 분산시켜주는 서비스.
- 비유: 마트의 계산대 여러 개. 한 계산대에 줄이 길어지면 다른 계산대로 안내해 준다.
Auto Scaling:
- 개념: 트래픽(부하)에 따라 EC2 인스턴스 수를 자동으로 늘리거나 줄이는 기능.
- 비유: 마트에 손님이 많아지면 닫혀 있던 계산대를 추가로 여는 것.

"시험에 이렇게 나옵니다":

"애플리케이션의 가용성과 내결함성을 높이기 위해 트래픽을 여러 인스턴스에 분산시키려면?" -> ELB
"트래픽이 많을 때 자동으로 서버 수를 늘리고, 적을 때 줄여서 비용을 절감하려면?" -> Auto Scaling

"이것만 알면 끝!": 인프라 전체의 설계도. 버튼 하나로 설계도대로 집을 짓고, 부술 수 있다.

개념: EC2, VPC, 데이터베이스 등 필요한 모든 인프라를 코드로 정의하고, 이 템플릿(설계도)을 사용하여 인프라를 자동으로 생성, 업데이트, 삭제하는 서비스.
비유: 레고 조립 설명서. 설명서만 있으면 누구나, 언제든지 똑같은 모양의 레고를 만들 수 있다.

"이것만 알면 끝!": 리소스의 성능을 보는 건강검진(CloudWatch)과, 계정 내 모든 활동 기록을 보는 CCTV(CloudTrail).

구분 항목	CloudWatch	CloudTrail
모니터링 대상	AWS 리소스의 성능 지표(Metrics)	AWS 계정 내의 API 호출 기록
수집 정보	EC2의 CPU 사용률, 네트워크 사용량, 디스크 I/O 등	"누가, 언제, 어디서, 어떤 작업을 했는가" (예: "김대리가 오후 3시에 EC2 인스턴스를 중지시켰다")
주요 용도	성능 모니터링, 경보 설정(예: CPU 80% 이상이면 알림)	보안 감사, 규정 준수, 문제 해결
비유	자동차 계기판 (속도, RPM, 기름 양)	자동차 블랙박스 (운전 기록, 사고 영상)

"이것만 알면 끝!": 돈을 더 낼수록 더 빠르고 전문적인 기술 지원을 받는다.

플랜	핵심 특징	최적 사용자
Basic	무료. 결제 및 계정 관련 문의만 가능.	모든 사용자
Developer	월 $29~. 업무 시간 내 이메일 기술 지원.	개발 및 테스트 환경
Business	월 $100~. 24x7 전화, 이메일, 채팅 기술 지원. 1시간 내 응답.	프로덕션(실제 서비스) 환경
Enterprise	월 $15,000~. 15분 내 응답. 전담 기술 관리자(TAM) 배정.	미션 크리티컬한 워크로드

"시험에 이렇게 나옵니다":

"프로덕션 환경에서 장애가 발생하여 1시간 이내에 전문가의 도움이 필요하다면 어떤 플랜 이상을 사용해야 하는가?" -> Business
"전담 기술 관리자(TAM)가 제공되는 플랜은?" -> Enterprise

Part 4: 글로벌 인프라와 콘텐츠 전송 - 전 세계를 내 집 앞처럼!

"이것만 알면 끝!": 전 세계 사용자에게 내 웹사이트의 사진과 동영상을 가장 빠르게 전달하는 콘텐츠 전송 네트워크(CDN).

구분 항목	️ 내 서버 (Origin)	CloudFront (CDN) & 엣지 로케이션
역할	원본 데이터(이미지, 동영상 등)를 보관	원본 데이터를 전 세계 엣지 로케이션에 미리 복사(캐싱)해 둠
사용자 경험	한국 사용자가 미국 서버에 접속하면 느림	한국 사용자는 가장 가까운 한국 엣지 로케이션에 접속하므로 매우 빠름
주요 서비스	EC2, S3 등	CloudFront
비유	물류센터 본사	전국 각지의 프랜차이즈 편의점

상세 설명 및 핵심 암기 비유:

당신이 S3(물류센터 본사)에 '신상 과자'(이미지 파일)를 보관하고 있다고 상상해 보세요. 전국의 고객들이 모두 이 물류센터로 주문하면 배송이 느립니다.
CloudFront는 이 '신상 과자'를 전국의 **엣지 로케이션(프랜차이즈 편의점)**에 미리 갖다 놓습니다. 고객은 이제 멀리 있는 물류센터가 아니라, 자기 집 앞 편의점에 가서 과자를 바로 살 수 있습니다. 속도가 엄청나게 빨라지겠죠?

"시험에 이렇게 나옵니다":

"전 세계 사용자들에게 웹사이트의 로딩 속도를 개선하고 싶다." -> CloudFront
"정적 콘텐츠(이미지, CSS, Javascript)와 동적 콘텐츠를 모두 빠르게 전송하려면?" -> CloudFront
"DDoS 공격으로부터 웹사이트를 보호하는 추가적인 이점도 얻고 싶다." -> CloudFront (WAF, Shield와 통합 가능)

Part 5: 하이브리드 클라우드 - 우리 회사와 AWS를 연결하기

"이것만 알면 끝!": 우리 회사와 AWS를 전용 고속도로(Direct Connect)로 연결할 것인가, 아니면 인터넷 위에 암호화된 터널(VPN)로 연결할 것인가.

구분 항목	️ AWS Direct Connect	사이트 간 VPN
연결 방식	전용 사설 네트워크 연결 (물리적)	기존 인터넷 회선 위에 암호화된 터널 생성
성능	일관되고 안정적인 고성능	인터넷 상태에 따라 성능 변동 가능
비용	비쌈 (전용선 설치 비용)	저렴 (기존 인터넷 사용)
보안	매우 높음 (인터넷을 거치지 않음)	높음 (강력한 암호화 사용)
비유	KTX 전용선 (빠르고 안정적이지만 비쌈)	경부고속도로의 버스전용차선 (기존 도로를 쓰지만, 우리만 쓰는 터널)

"시험에 이렇게 나옵니다":

"대규모 데이터를 안정적이고 일관된 속도로 AWS에 전송해야 한다." -> Direct Connect
"빠르고 저렴하게 온프레미스 네트워크와 VPC를 안전하게 연결하고 싶다." -> 사이트 간 VPN

Part 6: 데이터 이전 - 큰 데이터를 AWS로 옮기는 방법

"이것만 알면 끝!": 인터넷이 너무 느려서 대용량 데이터를 옮기기 힘들 때, 물리적인 저장 장치를 택배로 보내는 서비스.

AWS Snowball Edge:
- 개념: 여행 가방 크기의 튼튼한 휴대용 저장 장치. 데이터를 담아서 AWS 데이터 센터로 배송하면 AWS가 S3에 업로드해 줌.
- 용량: 약 80TB (Storage Optimized 기준)
- 비유: 데이터 이삿짐센터. 내 데이터를 이삿짐 트럭(Snowball)에 실어 보낸다.
AWS Snowmobile:
- 개념: 컨테이너 트럭 크기의 거대한 모바일 데이터 센터. 페타바이트(PB)를 넘어 엑사바이트(EB) 규모의 데이터를 옮길 때 사용.
- 용량: 최대 100PB
- 비유: 국가 전체가 이사하는 수준의 데이터.

"시험에 이렇게 나옵니다":

"수십 테라바이트(TB)의 데이터를 네트워크 대역폭 제약 때문에 AWS로 이전하기 어렵다. 어떻게 해야 하는가?" -> Snowball
"엑사바이트(EB) 규모의 데이터 센터 전체를 마이그레이션하려고 한다." -> Snowmobile

Part 7: 애플리케이션 통합 - 서비스들을 똑똑하게 연결하기

"이것만 알면 끝!": 주문을 하나씩 처리하는 1:1 편지함(SQS)과, 공지사항을 모두에게 동시에 보내는 1:N 단체 문자(SNS). 이 둘은 애플리케이션을 **분리(Decoupling)**하여 안정성을 높입니다.

구분 항목	SQS (Simple Queue Service)	SNS (Simple Notification Service)
목적	메시지 큐(대기열)	게시/구독 (Pub/Sub) 및 알림
전달 방식	폴링(Polling): 수신자가 큐를 주기적으로 확인하여 메시지를 가져감	푸시(Push): SNS가 구독자에게 메시지를 직접 밀어줌
수신자	단 한 명의 소비자가 메시지를 처리 (처리 후 삭제)	여러 명의 구독자가 동일한 메시지를 수신
비유	은행 창구의 번호표 시스템	긴급 재난 문자 / 학교의 방송 시스템

상세 설명:

SQS: 쇼핑몰에서 주문이 폭주할 때, 주문을 바로 처리하지 않고 SQS라는 대기열에 쌓아둡니다. 그리고 주문 처리 시스템이 자신의 처리 능력에 맞게 큐에서 주문을 하나씩 꺼내어 처리합니다. 이렇게 하면 주문 처리 시스템에 과부하가 걸리지 않습니다.
SNS: 신상품이 출시되면, "신상품 출시!"라는 메시지를 SNS 토픽에 한 번만 보냅니다. 그러면 이 토픽을 구독하고 있는 모든 채널(이메일, SMS, Lambda 등)로 메시지가 동시에 전송됩니다.

"시험에 이렇게 나옵니다":

"애플리케이션 구성 요소 간의 작업을 **분리(Decouple)**하여 한 쪽이 실패해도 다른 쪽에 영향을 주지 않게 하려면?" -> SQS
"이벤트가 발생했을 때, 여러 다른 서비스(Lambda, 이메일 등)에 동시에 알림을 보내려면?" -> SNS

Part 8: 보안, 규정 준수 및 거버넌스 - 신뢰를 위한 도구들

"이것만 알면 끝!": S3, EBS, RDS 등에 저장된 우리 데이터를 암호화하는 데 사용되는 암호화 키(열쇠)를 안전하게 만들고 관리하는 서비스.

개념: 암호화 키의 생성, 저장, 사용, 교체 등 전체 수명 주기를 관리합니다. "데이터를 암호화한다"는 얘기가 나오면 KMS를 떠올리세요.
비유: 은행의 안전 금고 관리인. 고객(사용자)은 금고(데이터)를 직접 열지 않고, 관리인(KMS)에게 "내 금고 좀 열어줘"라고 요청하면 관리인이 열어주는 방식.

"이것만 알면 끝!": 내 EC2 인스턴스와 컨테이너 이미지에 보안 취약점이나 의도하지 않은 네트워크 노출이 있는지 자동으로 검사해 주는 보안 점검 서비스.

개념: 운영 체제에 알려진 취약점(CVE)이 있는지, 인스턴스가 위험하게 인터넷에 노출되어 있는지 등을 스캔하여 보고서를 제공합니다.
비유: 자동차 정기 검사소. 내 차(EC2)에 브레이크 결함이나 타이어 마모 같은 잠재적인 위험이 있는지 점검해 줍니다.

"이것만 알면 끝!": AWS의 보안 및 규정 준수 보고서를 다운로드할 수 있는 포털.

개념: 우리 회사가 특정 규제(예: PCI-DSS, ISO 27001)를 준수해야 할 때, "AWS는 이 규제를 잘 지키고 있습니다"라는 증거 자료(보고서)가 필요합니다. Artifact는 바로 이 보고서들을 제공하는 서비스입니다.
비유: 아파트 관리사무소에서 발급해 주는 소방 안전 점검 필증.

"이것만 알면 끝!": 여러 개의 AWS 계정을 중앙에서 통합 관리하고 비용을 합쳐서 내는 서비스.

핵심 기능:
1. 통합 결제 (Consolidated Billing): 모든 계정의 비용을 하나의 마스터 계정에서 관리하고 결제.
2. 서비스 제어 정책 (SCP - Service Control Policies): 조직 내 특정 계정에서 특정 서비스(예: 위험한 서비스)를 아예 사용하지 못하도록 중앙에서 권한을 제한.
비유: 대기업의 본사. 각 지점(계정)을 관리하고, 전체 회계(결제)를 처리하며, "지점에서는 이런 활동은 절대 금지"와 같은 회사 정책(SCP)을 내릴 수 있습니다.

"이것만 알면 끝!": 내 AWS 계정을 5가지 항목에 대해 자동으로 검사하고, 모범 사례에 따라 개선할 점을 알려주는 개인 컨설턴트.

5가지 검사 항목:
1. 비용 최적화: 사용하지 않는 EC2, 유휴 로드 밸런서 등을 찾아 비용 절감 제안.
2. 성능: 성능 병목 현상을 일으킬 수 있는 설정을 찾아 개선 제안.
3. 보안: MFA 미사용, S3 버킷 공개 등 보안 허점 지적.
4. 내결함성: 단일 AZ에만 리소스가 있는 등 장애에 취약한 구성을 찾아 개선 제안.
5. 서비스 한도: 곧 한계에 도달할 리소스(예: EC2 인스턴스 수)를 미리 알려줌.
비유: 건강검진 결과 상담 의사. 내 생활 습관(AWS 사용 패턴)을 보고 "운동이 부족합니다(비용 낭비). 술을 줄이세요(보안 허점)." 라고 조언해 줍니다.

최종 점검: 시험장에 들어가기 전, 스스로에게 물어볼 마지막 질문 리스트

클라우드 개념: AWS 클라우드의 6가지 장점을 말할 수 있는가?
공동 책임 모델: AWS가 책임지는 것과 내가 책임져야 하는 것을 구분할 수 있는가?
보안: 보안 그룹과 NACL의 차이점을 설명할 수 있는가? WAF와 Shield의 차이를 아는가?
컴퓨팅: EC2와 Lambda 중 어떤 상황에 무엇을 써야 하는지 아는가?
스토리지: S3, EBS, EFS의 용도를 각각 설명할 수 있는가?
데이터베이스: RDS와 DynamoDB는 어떤 종류의 데이터에 적합한지 아는가?
네트워킹: VPC, 서브넷, 인터넷 게이트웨이, 라우트 테이블의 관계를 설명할 수 있는가?
비용: Budgets와 Cost Explorer의 차이를 아는가? **EC2 구매 옵션(온디맨드, RI, 스팟)**을 상황에 맞게 고를 수 있는가?
모니터링: CloudWatch와 CloudTrail이 무엇을 감시하는지 아는가?
글로벌 & 성능: 전 세계 사용자에게 콘텐츠를 빠르게 보내려면 CloudFront를 써야 한다는 것을 아는가?
애플리케이션 통합: 메시지 대기열이 필요하면 SQS, 동시 알림이 필요하면 SNS라는 것을 아는가?
관리 및 거버넌스: Organizations의 두 가지 핵심 기능(통합 결제, SCP)과, Trusted Advisor의 5가지 점검 항목을 아는가?

Well-Architected Framework 에 대한 개념 정리 테이블 (CLF-C02 버전)

Pillar (원칙)	핵심 목표 (이 원칙은 무엇을 추구하는가?)	반드시 알아야 할 개념/모범 사례	짝지어 외워야 할 대표 서비스
운영 우수성	"어떻게 하면 더 잘 운영하고, 더 빨리 개선할 수 있을까?"	코드형 인프라(IaC) 통한 자동화 변경 사항을 작고, 되돌릴 수 있게 만들기 운영 절차를 자주 개선하기 실패로부터 배우기	AWS CloudFormation: 인프라 배포 자동화 AWS CloudTrail: 모든 활동을 기록하여 문제 추적 Amazon CloudWatch: 시스템 상태 실시간 모니터링 및 경보 AWS Config: 리소스 구성 변경 추적 및 감사
보안	"어떻게 하면 데이터와 시스템을 완벽하게 보호할 수 있을까?"	강력한 자격 증명 기반 구현 (IAM) 최소 권한의 원칙 적용 모든 계층에서 보안 적용 (심층 방어)저장 시/전송 중 데이터 암호화	AWS IAM: 사용자 및 권한 관리의 모든 것 보안 그룹 / NACL: 네트워크 트래픽 제어 AWS Shield / WAF: DDoS 및 웹 공격 방어 Amazon GuardDuty / Inspector: 위협 탐지 및 취약점 분석 AWS KMS: 데이터 암호화 키 관리
신뢰성	"어떻게 하면 장애가 발생해도 서비스가 중단되지 않게 할 수 있을까?"	장애로부터 자동으로 복구 고가용성을 위한 수평 확장 용량 추측을 멈추고 수요에 따라 조절 단일 장애점(SPOF) 제거	Auto Scaling: 장애 인스턴스 자동 교체 및 확장/축소 다중 가용 영역(Multi-AZ): 지리적 이중화의 핵심 Elastic Load Balancing (ELB): 여러 인스턴스로 트래픽 분산 Amazon Route 53: DNS 수준의 장애 조치(Failover) AWS Backup: 데이터 복구를 위한 자동 백업
성능 효율성	"어떻게 하면 가장 효율적인 리소스로 최고의 성능을 낼 수 있을까?"	워크로드에 적합한 리소스 유형과 크기 선택 글로벌 배포를 통해 지연 시간 감소 서버리스 아키텍처 사용 고려 기계적인 작업 대신 고급 기술에 집중	Amazon CloudFront (CDN): 사용자와 가장 가까운 곳에서 콘텐츠 제공 Amazon ElastiCache: 데이터베이스 읽기 속도 향상을 위한 인메모리 캐시 AWS Lambda: 서버 관리 없이 효율적인 컴퓨팅 Amazon S3 전송 가속화: 장거리 파일 업로드 속도 향상 EBS IOPS 프로비저닝: 디스크 성능 최적화
비용 최적화	"어떻게 하면 불필요한 비용을 없애고 가장 저렴하게 운영할 수 있을까?"	사용한 만큼만 비용 지불 올바른 요금 모델 선택 (예약/스팟) 총 소유 비용(TCO) 측정 관리 부담이 없는 관리형/서버리스 서비스 사용	AWS Trusted Advisor: 비용 절감 방안 권장 Savings Plans / 예약 인스턴스(RI): 약정을 통한 요금 할인 스팟 인스턴스: 가장 저렴한 EC2 구매 옵션 AWS Budgets: 예산 초과 시 알림 AWS Cost Explorer: 비용 내역 시각화 및 분석
지속 가능성	"어떻게 하면 환경에 미치는 영향을 최소화하며 클라우드를 사용할 수 있을까?"	관리형 서비스 및 효율적인 아키텍처 채택 필요할 때만 리소스 사용 (서버리스, Auto Scaling) 워크로드의 영향 이해 및 측정 하드웨어 및 소프트웨어 수명 주기 최적화	AWS Lambda / Fargate: 서버리스를 통한 유휴 자원 최소화 서버리스 아키텍처: 필요 시에만 리소스 사용 AWS Graviton 프로세서: 더 적은 에너지로 높은 성능 제공 AWS Cost & Usage Report: 리소스 사용량 분석을 통한 최적화

내가 헷갈렸던 부분들

1. 성능 최적화: CloudFront vs. Global Accelerator

핵심 질문: "무엇을 빠르게 만들 것인가? 콘텐츠인가, 네트워크 경로인가?"

구분	Amazon CloudFront	AWS Global Accelerator
핵심 목적	콘텐츠 전송 네트워크 (CDN)	글로벌 트래픽 관리자
작동 방식	콘텐츠(이미지, 동영상)를 캐싱하여 사용자와 가까운 엣지에서 전달	애플리케이션 트래픽(TCP/UDP)의 네트워크 경로 자체를 최적화
키워드	콘텐츠 캐싱, 정적/동적 웹 콘텐츠, 엣지 로케이션	네트워크 지연 시간 감소, 경로 최적화, Non-HTTP 트래픽(게임 등)

2. 컨설턴트 3대장: Trusted Advisor vs. Inspector vs. Config

핵심 질문: "무엇을 점검할 것인가? 모범 사례인가, 소프트웨어 취약점인가, 구성 변경인가?"

구분	AWS Trusted Advisor	Amazon Inspector	AWS Config
핵심 목적	모범 사례 권장 (개인 컨설턴트)	소프트웨어 취약점 분석 (보안 형사)	리소스 구성 추적 및 감사 (역사 기록관)
점검 대상	AWS 환경 전체 (5개 영역)	EC2/컨테이너 내부의 소프트웨어	AWS 리소스의 구성 항목
결과물	"비용 절감 가능", "보안 그룹이 너무 개방됨" 등 권장 사항	"이 소프트웨어에 알려진 보안 버그(CVE)가 있습니다" 등 취약점 보고서	"어제 이 보안 그룹 규칙이 변경되었습니다" 등 구성 변경 기록

3. 데이터베이스 마이그레이션: Rehosting vs. Replatforming

핵심 질문: "그대로 옮길 것인가, 살짝 바꿔서 옮길 것인가?"

구분	리호스팅 (Rehosting)	리플랫포밍 (Replatforming)
개념	리프트 앤 시프트 (Lift and Shift)	리프트 앤 리셰이프 (Lift and Reshape)
실행 방식	온프레미스 데이터베이스 서버를 그대로 EC2 인스턴스에 옮겨 설치	온프레미스 데이터베이스를 AWS의 관리형 서비스(예: Amazon RDS)로 전환
키워드	변경 없음, 가장 빠른 마이그레이션	관리형 서비스로 전환, 약간의 최적화

4. 유연한 할인 플랜: Savings Plans vs. 예약 인스턴스 (RI)

핵심 질문: "특정 '차종'을 예약할 것인가, '시간당 렌트비'를 약정할 것인가?"

구분	Savings Plans	예약 인스턴스 (Reserved Instances)
약정 대상	시간당 컴퓨팅 사용량 (예: $10/시간)	특정 인스턴스 유형/리전 (예: m5.large 서울)
유연성	높음 (인스턴스 유형, 리전 변경 가능)	낮음 (약정한 유형에 묶임, 일부만 변경 가능)
키워드	사용량 약정, 유연성	인스턴스 약정, 특정 워크로드

5. 보안 정보 관리: Secrets Manager vs. KMS

핵심 질문: "비밀번호 '자체'를 관리할 것인가, '암호화 키'를 관리할 것인가?"

구분	AWS Secrets Manager	AWS KMS (Key Management Service)
관리 대상	비밀 정보 자체 (DB 자격 증명, API 키)	암호화 키 (Encryption Keys)
핵심 기능	비밀 정보의 자동 교체(Rotation), 안전한 저장	암호화 키의 생성, 관리, 사용 제어
키워드	비밀번호 자동 교체, API 키 관리	암호화 키, 고객 관리형 키(CMK)

정확한 정의와 역할의 범위를 알아ㅏ야함.

Amazon RDS 엔진의 종류
- 관계형 엔진 (O): Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, Microsoft SQL Server
- 관계형이 아닌 것 (X): MongoDB는 NoSQL 데이터베이스입니다. (DocumentDB가 MongoDB 호환 서비스)
온프레미스 지원팀 역할 구분 (Enterprise 플랜)
- 기술 계정 관리자 (TAM): 기술적인 조언, 아키텍처 검토, 사전 예방적 지침을 제공하는 기술 자문가입니다.
- 컨시어지 팀: 청구 및 계정 관련 문의를 전문적으로 처리해주는 행정 지원팀입니다.
데이터 분석 서비스의 역할 구분
- AWS Glue: 데이터를 분석하기 좋게 준비하는(ETL) 서비스입니다. 쿼리 도구가 아닙니다.
- Amazon Athena: S3 데이터를 로드 없이 바로 SQL로 쿼리하는 서비스입니다.
- Amazon Redshift: 데이터를 자체 클러스터로 로드한 후 깊이 있게 분석하는 데이터 웨어하우스입니다.

AWS 철학의 근간. 마지막으로 한 번 더 점검할 것.

공동 책임 모델 (Shared Responsibility Model)
- 가장 중요한 규칙: 사용하는 서비스가 IaaS(예: EC2)인가, PaaS(예: RDS)인가에 따라 고객의 책임 범위가 달라짐
- EC2 (IaaS): 고객은 OS 패치, 보안 설정, 애플리케이션 관리까지 책임져야 함
- RDS (PaaS): AWS가 OS 패치, 데이터베이스 소프트웨어 업데이트까지 책임져 줍니다. 고객은 데이터와 접근 제어만 신경 쓰면 됨
비용 관리 3신기 (언제 쓰는가?)
1. 사용 전 (견적): AWS 요금 계산기 (Pricing Calculator)
2. 사용 중 (경고): AWS Budgets (예산 설정 및 알림)
3. 사용 후 (분석): AWS Cost Explorer (비용 내역 시각화 및 원인 파악)

다시 풀어봐야하는 AWS-CLF02 모의고사 문제들

https://github.com/ReinaMoon/Get_A_Certification/blob/main/exam_aws_clf02.md

AWS CLF-02 #6 상세 정리

ReinaMoon — Tue, 12 Aug 2025 04:47:01 +0900

공유 책임 모델

AWS 공유 책임 모델

리소스에는 Amazon EC2 인스턴스, Amazon S3 버킷 및 Amazon RDS 데이터베이스가 포함됩니다. 이러한 리소스의 보안 유지 책임은 고객과 AWS 중 누구에게 있을까요?

정답은 둘 다입니다. 그 이유는 AWS 환경을 단일 개체로 취급하지 않기 때문입니다. 그보다는 환경을 서로를 기반으로 하는 여러 부분의 집합으로 취급합니다. AWS는 환경의 일부에 대한 책임을 지고, 고객(고객)은 다른 부분에 대한 책임을 집니다. 이 개념을공유 책임 모델이라고 합니다.

공유 책임 모델은 고객 책임(일반적으로 "클라우드의 보안"이라고 함)과 AWS 책임(일반적으로 "클라우드의 보안"이라고 함)으로 나뉩니다.

이 모델은 주택 소유자와 주택 건설업자 간의 책임 분담과 유사하다고 생각할 수 있습니다. 건축업자(AWS)는 집을 짓고 견고하게 지을 책임이 있습니다. 주택 소유자(고객)는 문을 닫고 잠그는 등 집 안의 모든 것을 안전하게 보호할 책임이 있습니다.

고객 : 클라우드 보안

고객은 AWS클라우드에생성하고 저장하는 모든 것의 보안에 대한 책임이 있습니다.

AWS 서비스를 사용할 때 고객은 자신의 콘텐츠에 대한 완전한 통제권을 유지합니다. 고객은 AWS에 저장하기로 선택한 콘텐츠, 사용하는 AWS 서비스, 해당 콘텐츠에 액세스할 수 있는 사용자를 포함하여 콘텐츠에 대한 보안 요구 사항을 관리할 책임이 있습니다. 또한 액세스 권한을 부여, 관리 및 취소하는 방법도 제어할 수 있습니다.

보안 단계는 사용하는 서비스, 시스템의 복잡성, 회사의 특정 운영 및 보안 요구 사항과 같은 요인에 따라 달라집니다. 단계에는 Amazon EC2 인스턴스에서 실행할 운영 체제 선택, 구성 및 패치 적용, 보안 그룹 구성 및 사용자 계정 관리가 포함됩니다.

AWS: 클라우드 보안

AWS는 클라우드의 보안을 책임집니다.

AWS는 인프라의 모든 계층에서 구성 요소를 운영, 관리 및 제어합니다. 여기에는 호스트 운영 체제, 가상화 계층, 심지어 서비스가 운영되는 데이터 센터의 물리적 보안과 같은 영역이 포함됩니다.

AWS는 AWS 클라우드에서 제공되는 모든 서비스를 실행하는 글로벌 인프라를 보호할 책임이 있습니다. 이 인프라에는 AWS 리전, 가용 영역, 에지 위치가 포함됩니다.

AWS는 클라우드의 보안, 특히 리소스를 호스팅하는 물리적 인프라를 관리하며, 여기에는 다음이 포함됩니다:

데이터 센터의 물리적 보안
하드웨어 및 소프트웨어 인프라
네트워크 인프라
가상화 인프라

AWS 데이터 센터를 직접 방문하여 이러한 보안을 직접 확인할 수는 없지만, AWS는 타사 감사자가 작성한 여러 보고서를 제공합니다. 이러한 감사자는 다양한 컴퓨터 보안 표준 및 규정을 준수하는지 확인했습니다.

사용자 권한 및 액세스

AWS ID 및 액세스 관리(IAM)

AWS ID 및 액세스 관리(IAM)를 사용하면 AWS 서비스 및 리소스에 대한 액세스를 안전하게 관리할 수 있습니다.

IAM을 사용하면 회사의 특정 운영 및 보안 요구 사항에 따라 액세스를 유연하게 구성할 수 있습니다.

IAM 사용자, 그룹 및 역할
IAM 정책
다단계 인증

또한 이러한 각 기능에 대한 모범 사례도 배웁니다.

AWS 계정 루트 사용자

AWS 계정을 처음 만들면루트 사용자라는 ID로 시작합니다.

루트 사용자는 AWS 계정을 만들 때 사용한 이메일 주소와 비밀번호로 로그인하여 액세스할 수 있습니다. 루트 사용자는 커피숍의 주인과 비슷하다고 생각하시면 됩니다. 계정의 모든 AWS 서비스 및 리소스에 대한 완전한 액세스 권한이 있습니다.

모범 사례:

일상적인 작업에는 루트 사용자를 사용하지마세요.
대신 루트 사용자를 사용하여 첫 번째 IAM 사용자를 만들고 다른 사용자를 만들 수 있는 권한을 할당하세요.
그런 다음 다른 IAM 사용자를 계속 생성하고 해당 ID에 액세스하여 AWS 전반에서 일반적인 작업을 수행하세요. 루트 사용자만 사용할 수 있는 제한된 수의 작업을 수행해야 하는 경우에만 루트 사용자를 사용하세요. 이러한 작업의 예로는 루트 사용자 이메일 주소 변경 및 AWS 지원 플랜 변경 등이 있습니다.

IAM 사용자

IAM 사용자는 AWS에서 생성하는 ID입니다. 이는 AWS 서비스 및 리소스와 상호 작용하는 사람 또는 애플리케이션을 나타냅니다. 이름과 자격 증명으로 구성됩니다.

기본적으로 AWS에서 새 IAM 사용자를 생성하면 해당 사용자에 연결된 권한이 없습니다. IAM 사용자가 AWS에서 Amazon EC2 인스턴스를 시작하거나 Amazon S3 버킷을 만드는 등의 특정 작업을 수행할 수 있도록 하려면 해당 사용자에게 필요한 권한을 부여해야 합니다.

모범 사례:

AWS에 액세스해야 하는 각 사람에 대해 개별 IAM 사용자를 만드는 것이 좋습니다.
동일한 수준의 액세스가 필요한 직원이 여러 명 있는 경우에도 각 직원에 대해 개별 IAM 사용자를 만들어야 합니다. 이렇게 하면 각 IAM 사용자가 고유한 보안 자격 증명 집합을 가질 수 있어 보안이 강화됩니다.

IAM 정책

IAM 정책은 AWS 서비스 및 리소스에 대한 권한을 허용하거나 거부하는 문서입니다.

IAM 정책을 사용하면 리소스에 대한 사용자의 액세스 수준을 사용자 지정할 수 있습니다. 예를 들어 사용자가 AWS 계정 내의 모든 Amazon S3 버킷에 액세스하도록 허용하거나 특정 버킷에만 액세스하도록 허용할 수 있습니다.

모범 사례:

권한을 부여할 때는최소 권한의 보안 원칙을 따르세요.
이 원칙을 따르면 사용자나 역할이 작업을 수행하는 데 필요한 것보다 더 많은 권한을 갖지 못하도록 방지할 수 있습니다.
예를 들어 직원이 특정 버킷에만 액세스해야 하는 경우 IAM 정책에서 버킷을 지정하세요. 직원에게 AWS 계정의 모든 버킷에 대한 액세스 권한을 부여하는 대신 이렇게 하세요.

IAM 그룹

IAM 그룹은 IAM 사용자의 모음입니다. 그룹에 IAM 정책을 할당하면 그룹의 모든 사용자에게 정책에 지정된 권한이 부여됩니다.

다음은 커피숍에서 이것이 어떻게 작동하는지에 대한 예입니다. 소유자는 계산원에게 한 번에 하나씩 권한을 할당하는 대신 "계산원" IAM 그룹을 만들 수 있습니다. 그런 다음 소유자는 그룹에 IAM 사용자를 추가한 다음 그룹 수준에서 권한을 연결할 수 있습니다.

그룹 수준에서 IAM 정책을 할당하면 직원이 다른 직종으로 이동하는 경우에도 권한을 쉽게 조정할 수 있습니다. 예를 들어, 계산원이 재고 전문가가 되는 경우 커피숍 소유자는 해당 직원을 '계산원' IAM 그룹에서 제거하고 '재고 전문가' IAM 그룹에 추가할 수 있습니다. 이렇게 하면 직원이 현재 역할에 필요한 권한만 갖도록 할 수 있습니다.

커피숍 직원이 영구적으로 직무를 전환하지 않고 하루 종일 다른 워크스테이션으로 순환하는 경우 어떻게 해야 할까요? 이 직원은IAM 역할을 통해 필요한 액세스 권한을 얻을 수 있습니다.

IAM 역할

커피숍에서 직원은 하루 종일 다른 워크스테이션으로 교대 근무를 합니다. 커피숍의 직원 배치에 따라 이 직원은 금전 등록기 작업, 재고 시스템 업데이트, 온라인 주문 처리 등 여러 가지 업무를 수행할 수 있습니다.

직원이 다른 업무로 전환해야 하는 경우 한 워크스테이션에 대한 액세스 권한을 포기하고 다음 워크스테이션에 액세스 권한을 얻습니다. 직원은 워크스테이션 간에 쉽게 전환할 수 있지만 특정 시점에서는 하나의 워크스테이션에만 액세스할 수 있습니다. 이와 동일한 개념이 AWS의 IAM 역할에도 존재합니다.

IAM 역할은 권한에 대한 임시 액세스 권한을 얻기 위해 가정할 수 있는 ID입니다.

IAM 사용자, 애플리케이션 또는 서비스가 IAM 역할을 맡으려면 먼저 해당 역할로 전환할 수 있는 권한을 부여받아야 합니다. 누군가가 IAM 역할을 맡으면 이전 역할에서 가지고 있던 모든 이전 권한이 포기되고 새 역할의 권한을 갖게 됩니다.

모범 사례:

IAM 역할은 서비스나 리소스에 대한 액세스 권한을 장기간이 아닌 일시적으로 부여해야 하는 상황에 이상적입니다.

다단계 인증

신원 확인을 위해 여러 가지 정보를 제공해야 하는 웹사이트에 로그인한 적이 있나요? 비밀번호를 입력한 다음 휴대폰으로 전송된 임의의 코드와 같은 두 번째 인증 수단을 제공해야 했을 수도 있습니다. 이것이 바로다단계 인증의 예입니다.

IAM에서 다단계 인증(MFA)은 AWS 계정에 대한 추가 보안 계층을 제공합니다.

AWS 조직

AWS 조직

회사에 여러 개의 AWS 계정이 있다고 가정해 보세요.AWS 조직을 사용하여 중앙 위치에서 여러 AWS 계정을 통합하고 관리할수 있습니다.

조직을 만들면 AWS 조직이 자동으로루트를 생성하며, 이루트는 조직의 모든 계정에 대한 상위 컨테이너입니다.

AWS 조직에서는SCP(서비스 제어 정책)를 사용하여 조직 내 계정에 대한 권한을 중앙에서 제어할 수 있습니다. SCP를 사용하면 각 계정의 사용자 및 역할이 액세스할 수 있는 AWS 서비스, 리소스 및 개별 API 작업을 제한할 수 있습니다.

통합 청구는 AWS 조직의 또 다른 기능입니다. 이후 모듈에서 통합 청구에 대해 배우게 됩니다.

조직 단위

AWS 조직에서는 계정을 OU(조직 단위)로 그룹화하여 비즈니스 또는 보안 요구 사항이 유사한 계정을 더 쉽게 관리할 수 있습니다. OU에 정책을 적용하면 OU의 모든 계정이 정책에 지정된 권한을 자동으로 상속받습니다.

별도의 계정을 OU로 구성하면 특정 보안 요구 사항이 있는 워크로드나 애플리케이션을 더 쉽게 격리할 수 있습니다. 예를 들어, 회사에서 특정 규제 요건을 충족하는 AWS 서비스에만 액세스할 수 있는 계정이 있는 경우, 이러한 계정을 하나의 OU에 넣을 수 있습니다. 그런 다음 규제 요구 사항을 충족하지 않는 다른 모든 AWS 서비스에 대한 액세스를 차단하는 정책을 OU에 첨부할 수 있습니다.

규정 준수

AWS 아티팩트

회사의 업종에 따라 특정 표준을 준수해야 할 수도 있습니다. 감사 또는 점검을 통해 회사가 이러한 표준을 충족했는지 확인할 수 있습니다.

AWS 아티팩트는 AWS 보안 및 규정 준수 보고서와 일부 온라인 계약에 대한 온디맨드 액세스를 제공하는 서비스입니다. AWS 아티팩트는 크게 두 가지 섹션으로 구성됩니다: AWS 아티팩트 계약과 AWS 아티팩트 보고서입니다.

AWS 아티팩트 계약

회사에서 AWS 서비스 전반에 걸쳐 특정 유형의 정보 사용과 관련하여 AWS와 계약을 체결해야 한다고 가정해 보겠습니다.AWS 아티팩트 계약을 통해 이를 수행할 수 있습니다.

AWS 아티팩트 계약에서 개별 계정 및 AWS 조직의 모든 계정에 대한 계약을 검토, 수락 및 관리할 수 있습니다. 건강 보험 양도 및 책임에 관한 법률(HIPAA)과 같은 특정 규정의 적용을 받는 고객의 요구 사항을 해결하기 위해 다양한 유형의 계약이 제공됩니다.

AWS 아티팩트 보고서

다음으로, 귀사의 개발 팀원이 애플리케이션을 구축 중이며 특정 규제 표준을 준수해야 하는 책임에 대한 자세한 정보가 필요하다고 가정해 보겠습니다. 이 팀원에게AWS 아티팩트 보고서에서 이 정보에 액세스하도록 조언할 수 있습니다.

AWS 아티팩트 보고서는 타사 감사자의 규정 준수 보고서를 제공합니다. 이러한 감사자는 AWS가 다양한 글로벌, 지역 및 산업별 보안 표준 및 규정을 준수하는지 테스트하고 확인했습니다. AWS 아티팩트 보고서는 최신 보고서로 최신 상태를 유지합니다. AWS 감사 아티팩트를 감사자 또는 규제 기관에 AWS 보안 제어의 증거로 제공할 수 있습니다.

서비스 거부 공격

고객은 커피숍에 전화하여 주문할 수 있습니다. 각 전화를 받은 계산원이 주문을 받아 바리스타에게 전달합니다.

그러나 한 장난꾸러기가 여러 번 전화를 걸어 주문만 하고 음료를 받지 않는다고 가정해 보겠습니다. 이로 인해 계산원은 다른 고객의 전화를 받을 수 없게 됩니다. 커피숍은 장난꾼이 사용하는 전화번호를 차단하여 잘못된 요청을 중지할 수 있습니다.

이 시나리오에서 장난꾼의 행동은서비스 거부 공격과 유사합니다.

서비스 거부 공격

서비스 거부(DoS) 공격은 사용자가 웹사이트나 애플리케이션을 사용할 수 없도록 의도적으로 시도하는 것입니다.

예를 들어, 공격자는 표적이 된 웹사이트나 애플리케이션이 과부하가 걸려 더 이상 응답할 수 없을 때까지 과도한 네트워크 트래픽을 웹사이트나 애플리케이션에 쏟아 부을 수 있습니다. 웹사이트나 애플리케이션을 사용할 수 없게 되면 합법적인 요청을 하려는 사용자에 대한 서비스가 거부됩니다.

분산 서비스 거부 공격

이제 장난꾼이 친구들의 도움을 받았다고 가정해 보겠습니다.

장난꾼과 친구들은 주문을 받을 의도가 없음에도 불구하고 커피숍에 반복적으로 전화를 걸어 주문을 요청합니다. 이러한 요청은 서로 다른 전화번호로 걸려오기 때문에 커피숍에서 이를 모두 차단하는 것은 불가능합니다. 또한 전화가 폭주하면서 고객이 전화를 연결하기가 점점 더 어려워지고 있습니다. 이는분산 서비스 거부 공격과 유사합니다.

분산 서비스 거부(DDoS) 공격에서는 여러 소스를 사용하여 웹사이트나 애플리케이션을 사용할 수 없게 만드는 것을 목표로 공격을 시작합니다. 이는 공격자 그룹 또는 한 명의 공격자로부터 시작될 수 있습니다. 한 명의 공격자가 여러 대의 감염된 컴퓨터("봇"이라고도 함)를 사용하여 웹사이트 또는 애플리케이션에 과도한 트래픽을 전송할 수 있습니다.

애플리케이션에 대한 DoS 및 DDoS 공격의 영향을 최소화하기 위해AWS Shield를 사용할 수 있습니다.

AWS 쉴드

AWS Shield는 DDoS 공격으로부터 애플리케이션을 보호하는 서비스입니다. AWS Shield는 두 가지 보호 수준을 제공합니다: 스탠다드 및 어드밴스드.

AWS Shield 스탠다드

AWS Shield Standard는 모든 AWS 고객을 무료로 자동으로 보호합니다. 가장 일반적이고 빈번하게 발생하는 DDoS 공격 유형으로부터 AWS 리소스를 보호합니다.

네트워크 트래픽이 애플리케이션으로 유입될 때 AWS Shield Standard는 다양한 분석 기법을 사용하여 악성 트래픽을 실시간으로 탐지하고 자동으로 완화합니다.

AWS Shield Advanced

AWS Shield Advanced는 상세한 공격 진단과 정교한 DDoS 공격을 탐지하고 완화할 수 있는 기능을 제공하는 유료 서비스입니다.

또한 Amazon CloudFront, Amazon Route 53, Elastic Load Balancing과 같은 다른 서비스와 통합됩니다. 또한, 사용자 정의 규칙을 작성하여 복잡한 DDoS 공격을 완화하는 방식으로 AWS Shield를 AWS WAF와 통합할 수 있습니다.

추가 보안 서비스

AWS 키 관리 서비스(AWS KMS)

커피숍에는 커피 머신, 페이스트리, 금전 등록기의 돈 등 많은 물품이 있습니다. 이러한 품목을 데이터라고 생각할 수 있습니다. 커피숍 주인은 이러한 물품이 창고에 보관되어 있든 매장 간에 이동 중이든 모두 안전하게 보호되기를 원합니다.

마찬가지로 애플리케이션의 데이터가 저장소에 있는 동안(저장 중 암호화)과 전송되는 동안(전송 중 암호화)에도 보안을 유지해야 합니다.

AWS 키 관리 서비스(AWS KMS)를 사용하면암호화 키를 사용하여 암호화 작업을 수행할 수 있습니다. 암호화 키는 데이터를 잠그고(암호화) 잠금 해제(암호 해독)하는 데 사용되는 임의의 숫자 문자열입니다. AWS KMS를 사용하여 암호화 키를 생성, 관리 및 사용할 수 있습니다. 또한 다양한 서비스와 애플리케이션에서 키 사용을 제어할 수 있습니다.

AWS KMS를 사용하면 키에 필요한 특정 액세스 제어 수준을 선택할 수 있습니다. 예를 들어, 키를 관리할 수 있는 IAM 사용자 및 역할을 지정할 수 있습니다. 또는 키를 일시적으로 비활성화하여 누구도 더 이상 사용하지 못하도록 할 수도 있습니다. 키는 AWS KMS를 벗어나지 않으며, 항상 사용자가 키를 제어할 수 있습니다.

AWS WAF

AWS WAF는 웹 애플리케이션으로 들어오는 네트워크 요청을 모니터링할 수 있는 웹 애플리케이션 방화벽입니다.

AWS WAF는 Amazon CloudFront 및 애플리케이션 로드 밸런서와 함께 작동합니다. 이전 모듈에서 배운 네트워크 액세스 제어 목록을 기억하세요. AWS WAF는 트래픽을 차단하거나 허용하는 비슷한 방식으로 작동합니다. 하지만웹 액세스 제어 목록(ACL)을 사용하여 AWS 리소스를 보호합니다.

아마존 인스펙터

커피숍의 개발자가 새로운 주문 애플리케이션을 개발 및 테스트하고 있다고 가정해 보겠습니다. 개발자는 보안 모범 사례에 따라 애플리케이션을 설계하고 있는지 확인하려고 합니다. 그러나 개발해야 할 다른 애플리케이션이 여러 개 있기 때문에 수동 평가를 수행하는 데 많은 시간을 할애할 수 없습니다. 자동화된 보안 평가를 수행하기 위해Amazon Inspector를 사용하기로 결정합니다.

Amazon Inspector는 자동화된 보안 평가를 실행하여 애플리케이션의 보안 및 규정 준수를 개선하는 데 도움을 줍니다. 이 도구는 애플리케이션의 보안 취약성 및 보안 모범 사례(예: Amazon EC2 인스턴스에 대한 개방형 액세스 및 취약한 소프트웨어 버전 설치)에서 벗어난 부분이 있는지 확인합니다.

Amazon Inspector가 평가를 수행한 후에는 보안 결과 목록을 제공합니다. 이 목록에는 각 보안 문제에 대한 자세한 설명과 해결 방법에 대한 권장 사항을 포함하여 심각도 수준에 따라 우선 순위가 지정됩니다. 그러나 AWS는 제공된 권장 사항을 따른다고 해서 모든 잠재적 보안 문제가 해결된다고 보장하지 않습니다. 공유 책임 모델에 따라 고객은 AWS 서비스에서 실행되는 애플리케이션, 프로세스 및 도구의 보안에 대한 책임이 있습니다.

Amazon GuardDuty

Amazon GuardDuty는 AWS 인프라 및 리소스에 대한 지능적인 위협 탐지를 제공하는 서비스입니다. AWS 환경 내에서 네트워크 활동과 계정 동작을 지속적으로 모니터링하여 위협을 식별합니다.

AWS 계정에 대해 GuardDuty를 사용하도록 설정하면 GuardDuty가 네트워크 및 계정 활동을 모니터링하기 시작합니다. 추가 보안 소프트웨어를 배포하거나 관리할 필요가 없습니다. 그런 다음 GuardDuty는 VPC 플로우 로그 및 DNS 로그를 비롯한 여러 AWS 소스의 데이터를 지속적으로 분석합니다.

GuardDuty가 위협을 감지하면 AWS 관리 콘솔에서 해당 위협에 대한 자세한 결과를 검토할 수 있습니다. 결과에는 해결을 위한 권장 단계가 포함됩니다. 또한 GuardDuty의 보안 발견에 따라 자동으로 해결 단계를 수행하도록 AWS Lambda 함수를 구성할 수도 있습니다.

서비스명 정의 주요 특징 시험 키워드

서비스명	정의	주요 특징	시험 키워드
AWS Identity and Access Management (IAM)	AWS 리소스에 대한 접근을 안전하게 제어하는 서비스	사용자·그룹·역할 생성 / 세분화된 권한 / MFA 지원	인증, 권한, MFA, 역할, 정책
AWS IAM Identity Center (SSO)	여러 AWS 계정 및 애플리케이션에 대한 단일 로그인 제공	중앙 집중식 접근 제어 / SAML, OIDC 연동 / 사용자 관리	SSO, 통합 인증, 다계정 관리
AWS Organizations	여러 AWS 계정을 중앙에서 관리하는 서비스	계정 생성·조직 단위(OU) 관리 / 서비스 제어 정책(SCP) / 통합 결제	다계정 관리, OU, SCP, 통합 청구
AWS Key Management Service (KMS)	데이터 암호화 키 생성 및 관리 서비스	대칭/비대칭 키 지원 / AWS 서비스와 통합 / 규정 준수	암호화, KMS, 키 관리, 규정 준수
AWS CloudHSM	전용 하드웨어 기반 암호화 키 관리	HSM 클러스터 제공 / FIPS 140-2 Level 3 인증	HSM, 하드웨어 암호화, 보안 모듈
AWS Shield	DDoS 공격 방어 서비스	Standard(기본 제공) / Advanced(추가 보호 및 지원)	DDoS, 네트워크 보호
AWS WAF	웹 애플리케이션 방화벽	IP 차단/허용 / SQL Injection, XSS 방어 / CloudFront, ALB 통합	웹 방화벽, SQL Injection, XSS
Amazon GuardDuty	지능형 위협 탐지 서비스	악성 활동·무단 접근 감지 / 머신러닝 기반 / 지속 모니터링	위협 탐지, 지속 모니터링, AI 기반
Amazon Inspector	자동 보안 취약점 스캐닝 서비스	EC2, ECR 이미지, Lambda 스캔 / CVE 기반 취약점 분석	취약점 스캔, 보안 점검, 자동화
AWS Security Hub	AWS 보안 상태를 통합 관리하는 대시보드	GuardDuty, Inspector, Macie 통합 / 규정 준수 체크	보안 통합, 규정 준수, 대시보드
Amazon Macie	민감 데이터(PII) 자동 식별 서비스	S3 내 데이터 스캔 / 머신러닝 기반 PII 탐지	PII, 개인정보 보호, 데이터 식별
AWS Artifact	규정 준수 보고서와 인증서 제공	ISO, SOC, PCI 보고서 다운로드 / AWS 규정 준수 확인	규정 준수, 감사 보고서
AWS Secrets Manager	애플리케이션 비밀(Secret) 관리 서비스	DB 자격 증명, API 키 암호화 / 자동 회전 / 감사 가능	비밀번호 관리, 자동 회전, API 키
AWS Certificate Manager (ACM)	SSL/TLS 인증서 발급 및 관리 서비스	자동 갱신 / AWS 서비스와 통합	SSL/TLS, 인증서, 암호화

리소스

AWS CLF-02 #5 상세 정리

ReinaMoon — Mon, 11 Aug 2025 22:00:08 +0900

우선 알아야 할 항목

스토리지 타입 구분

객체(Object): Amazon S3 계열 — 파일 단위(객체) 저장, 메타데이터, 웹·아카이브에 적합
블록(Block): Amazon EBS — EC2에 붙여 쓰는 디스크, DB·트랜잭션 처리에 적합
파일(File): Amazon EFS, FSx — 여러 서버가 동시에 파일 수준으로 접근해야 할 때 사용
하이브리드 / 오프라인: Storage Gateway, Snow Family — 온프레↔클라우드 연동, 대용량 물리 이동

인스턴스 스토어 및 Amazon EBS(Amazon Elastic Block Store)

인스턴스 스토어

블록 레벨 스토리지 볼륨은 물리적 하드 드라이브처럼 작동합니다.

인스턴스 스토어는 Amazon EC2 인스턴스를 위한 임시 블록 수준 스토리지를 제공합니다. 인스턴스 스토어는 EC2 인스턴스를 위해 호스트 컴퓨터에 물리적으로 연결된 디스크 스토리지이므로 인스턴스와 동일한 수명을 갖습니다. 인스턴스가 종료되면 인스턴스 스토어에 있는 모든 데이터가 손실됩니다.

Amazon Elastic 블록 스토리지(Amazon EBS)

Amazon EBS(Amazon Elastic Block Store)는 Amazon EC2 인스턴스와 함께 사용할 수 있는 블록 수준의 스토리지 볼륨을 제공하는 서비스입니다. Amazon EC2 인스턴스를 중지하거나 종료해도 연결된 EBS 볼륨의 모든 데이터는 계속 사용할 수 있습니다.

EBS 볼륨을 생성하려면 볼륨 크기 및 유형과 같은 구성을 정의하고 프로비저닝합니다. EBS 볼륨을 생성한 후에는 Amazon EC2 인스턴스에 연결할 수 있습니다.

EBS 볼륨은 지속해야 하는 데이터를 위한 것이므로 데이터를 백업하는 것이 중요합니다. Amazon EBS 스냅샷을 생성하여 EBS 볼륨의 증분 백업을 수행할 수 있습니다

Amazon EBS 스냅샷

EBS 스냅샷은 증분 백업입니다. 즉, 볼륨의 첫 번째 백업은 모든 데이터를 복사합니다. 이후 백업의 경우 가장 최근 스냅샷 이후 변경된 데이터 블록만 저장됩니다.

증분 백업은 백업이 수행될 때마다 스토리지 볼륨의 모든 데이터가 복사되는 전체 백업과는 다릅니다. 전체 백업에는 가장 최근 백업 이후 변경되지 않은 데이터가 포함됩니다.

아마존 심플 스토리지 서비스(Amazon S3)

오브젝트 스토리지

객체 스토리지에서 각 객체는 데이터, 메타데이터, 키로 구성됩니다.

데이터는 이미지, 동영상, 텍스트 문서 또는 기타 모든 유형의 파일일 수 있습니다. 메타데이터에는 데이터의 종류, 사용 방법, 개체 크기 등에 대한 정보가 포함됩니다. 객체의 키는 객체의 고유 식별자입니다.

블록 스토리지에서 파일을 수정하면 변경된 부분만 업데이트된다는 점을 기억하세요. 오브젝트 스토리지의 파일을 수정하면 전체 오브젝트가 업데이트됩니다.

아마존 심플 스토리지 서비스(Amazon S3)

AmazonS3(Amazon Simple Storage Service)는 객체 수준 스토리지를 제공하는 서비스입니다. Amazon S3는 데이터를 버킷에 오브젝트로 저장합니다.

이미지, 동영상, 텍스트 파일 등 모든 유형의 파일을 Amazon S3에 업로드할 수 있습니다. 예를 들어 Amazon S3를 사용하여 백업 파일, 웹사이트용 미디어 파일 또는 보관된 문서를 저장할 수 있습니다. Amazon S3는 무제한 저장 공간을 제공합니다. Amazon S3에서 개체의 최대 파일 크기는 5TB입니다.

Amazon S3에 파일을 업로드할 때 권한을 설정하여 파일에 대한 가시성 및 액세스를 제어할 수 있습니다. 또한 Amazon S3 버전 관리 기능을 사용하여 시간 경과에 따른 개체의 변경 사항을 추적할 수 있습니다.

Amazon S3 스토리지 클래스

Amazon S3를 사용하면 사용한 만큼만 비용을 지불합니다.다양한 스토리지 클래스 중에서 비즈니스 및 비용 요구 사항에 적합한 것을 선택할 수 있습니다. Amazon S3 스토리지 클래스를 선택할 때는 다음 두 가지 요소를 고려하세요:

데이터를 얼마나 자주 검색할 계획인지
데이터의 가용성이 얼마나 필요한지

Amazon S3 스탠다드

Amazon S3 Standard(S3 Standard)

자주 액세스하는 데이터를 위한 설계
최소 3개의 가용 영역에 데이터 저장

Amazon S3 Standard는 오브젝트에 고가용성을 제공합니다. 따라서 웹사이트, 콘텐츠 배포, 데이터 분석 등 다양한 사용 사례에 적합한 선택입니다. Amazon S3 Standard는 자주 액세스하지 않는 데이터 및 아카이브 스토리지를 위한 다른 스토리지 클래스보다 비용이 더 높습니다.

Amazon S3 스탠다드-빈번하지 않은 액세스(S3 스탠다드-IA)

Amazon S3 Standard-Infrequent Access(S3 Standard-IA)

자주 액세스하지 않는 데이터에 적합
Amazon S3 Standard와 유사하지만 저장 가격은 더 낮고 검색 가격은 더 높습니다

Amazon S3 Standard-IA는 액세스 빈도는 낮지만 필요할 때 고가용성이 필요한 데이터에 이상적입니다. Amazon S3 Standard와 Amazon S3 Standard-IA는 모두 최소 3개의 가용 영역에 데이터를 저장합니다. S3 Standard-IA는 Amazon S3 Standard와 동일한 수준의 가용성을 제공하지만 스토리지 가격은 더 낮고 검색 가격은 더 높습니다.

Amazon S3 하나의 영역-빈번하지 않은 액세스(S3 하나의 영역-IA)

Amazon S3 One Zone-Infrequent Access(S3 One Zone-IA)

단일 가용성 영역에 데이터 저장
Amazon S3 Standard-IA보다 스토리지 가격이 저렴합니다

최소 3개의 가용 영역에 데이터를 저장하는 Amazon S3 Standard 및 Amazon S3 Standard-IA와 비교하여 Amazon S3 One Zone-IA는 단일 가용 영역에 데이터를 저장합니다. 따라서 다음 조건에 해당하는 경우 고려할 수 있는 좋은 스토리지 클래스입니다:

스토리지 비용을 절감하려는 경우.
가용 영역에 장애가 발생할 경우 데이터를 쉽게 복제할 수 있습니다.

Amazon S3 인텔리전트 티어링

Amazon S3 Intelligent-Tiering(S3 Intelligent-Tiering)

액세스 패턴을 알 수 없거나 변화하는 데이터에 이상적
개체당 소액의 월별 모니터링 및 자동화 요금이 필요합니다

Amazon S3 인텔리전트-티어링 스토리지 클래스에서 Amazon S3는 오브젝트의 액세스 패턴을 모니터링합니다. 30일 연속으로 오브젝트에 액세스하지 않은 경우, Amazon S3는 해당 오브젝트를 액세스 빈도가 낮은 계층인 Amazon S3 Standard-IA로 자동으로 이동합니다. 자주 액세스하지 않는 계층에 있는 개체에 액세스하면 Amazon S3는 해당 개체를 자주 액세스하는 계층인 Amazon S3 Standard로 자동으로 이동합니다.

Amazon S3 Glacier 즉시 검색

Amazon S3 Glacier Instant Retrieval

즉각적인 액세스가 필요한 아카이브 데이터에 적합합니다
몇 밀리초 내에 개체를 검색할 수 있습니다

아카이브 스토리지 옵션을 결정할 때는 아카이브된 개체를 얼마나 빨리 검색해야 하는지 고려하세요. Amazon S3 Glacier 즉시 검색 스토리지 클래스에 저장된 오브젝트는 Amazon S3 Standard와 동일한 성능으로 밀리초 이내에 검색할 수 있습니다.

Amazon S3 Glacier 유연한 검색

Amazon S3 Glacier Flexible Retrieval(이전 S3 Glacier)

데이터 아카이빙을 위해 설계된 저비용 스토리지
몇 분에서 몇 시간 내에 오브젝트 검색 가능

Amazon S3 Glacier Flexible Retrieval은 데이터 아카이빙에 적합한 저비용 스토리지 클래스입니다. 예를 들어 이 스토리지 클래스를 사용하여 아카이브된 고객 기록이나 오래된 사진 및 비디오 파일을 저장할 수 있습니다.

Amazon S3 글래시어 딥 아카이브

Amazon S3 Glacier Deep Archive

아카이빙에 이상적인 최저 비용 오브젝트 스토리지 클래스
12시간 이내에 오브젝트 검색 가능

Amazon S3 딥 아카이브는 1년에 한두 번 액세스할 수 있는 데이터에 대한 장기 보존 및 디지털 보존을 지원합니다. 이 스토리지 클래스는 AWS 클라우드에서 가장 저렴한 스토리지로, 12시간에서 48시간까지 데이터를 검색할 수 있습니다. 이 스토리지 클래스의 모든 오브젝트는 지리적으로 분산된 최소 3개의 가용 영역에 복제되어 저장됩니다.

Amazon S3 전초 기지

Amazon S3 on Outposts

Amazon S3 전초 기지에 S3 버킷을 생성합니다
AWS 아웃포스트에서 데이터를 더 쉽게 검색, 저장 및 액세스할 수 있습니다

Amazon S3 Outposts는 온프레미스 AWS Outposts 환경에 오브젝트 스토리지를 제공합니다. Amazon S3 아웃포스트는 아웃포스트의 여러 장치와 서버에 걸쳐 데이터를 내구성 있고 이중화하여 저장하도록 설계되었습니다. 데이터를 온프레미스 애플리케이션에 가깝게 유지하여 까다로운 성능 요구 사항을 충족해야 하는 로컬 데이터 상주 요구 사항이 있는 워크로드에 적합합니다.

스토리지 클래스 주요 특징 가용성 / 복제 비용 구조 사용 사례

스토리지 클래스	주요특징	가용성	복제 비용 구조	사용 사례
S3 Standard	자주 액세스하는 데이터를 위한 범용 스토리지	최소 3개의 AZ에 저장	저장비 ↑ / 검색비 ↓	웹사이트 콘텐츠, 데이터 분석, 스트리밍
S3 Standard-IA	자주 액세스하지 않지만 필요 시 빠른 접근이 필요한 데이터	최소 3개의 AZ에 저장	저장비 ↓ / 검색비 ↑	백업, 재해 복구 데이터
S3 One Zone-IA	단일 AZ에 저장하는 저비용 옵션	1개의 AZ에만 저장	저장비 ↓↓ / 검색비 ↑	복제 가능 데이터, 임시 저장소
S3 Intelligent-Tiering	액세스 패턴에 따라 자동으로 티어 변경	최소 3개의 AZ에 저장	모니터링 소액 요금 + 티어별 요금	액세스 패턴이 불규칙한 데이터
S3 Glacier Instant Retrieval	밀리초 단위 검색 가능한 아카이브	최소 3개의 AZ	저장비 ↓ / 검색비 보통	오래된 이미지·문서 아카이브
S3 Glacier Flexible Retrieval	몇 분~몇 시간 내 검색 가능, 저비용	최소 3개의 AZ	저장비 ↓↓ / 검색비 ↑	장기 보관 기록, 규제 데이터
S3 Glacier Deep Archive	최저가 아카이브, 검색 12~48시간	최소 3개의 AZ	저장비 ↓↓↓ / 검색비 ↑↑	1년에 1~2회 조회 데이터
S3 on Outposts	온프레미스 AWS Outposts에서 제공	로컬 Outposts 내 저장	Outposts 기반 요금	로컬 데이터 레지던시, 저지연 워크로드

CLF-C02 스토리지 서비스 요약

Amazon S3
- 객체 스토리지, 무제한 확장
- 다양한 스토리지 클래스 제공
- 버전 관리, 수명 주기 정책 지원
Amazon EBS
- 블록 스토리지, EC2 인스턴스 전용
- SSD(HDD) 옵션 제공, IOPS 설정 가능
- 스냅샷으로 S3에 백업 가능
Amazon EFS
- 공유 파일 스토리지, 자동 확장
- 리눅스 기반 NFS 프로토콜
- 다중 AZ 지원
Amazon FSx
- 관리형 파일 서버 (Windows / Lustre)
- Windows → SMB 프로토콜, AD 통합
- Lustre → HPC 워크로드, S3와 통합
AWS Storage Gateway
- 온프레미스 ↔ AWS 스토리지 연동
- File, Volume, Tape Gateway 지원

Amazon Elastic 파일 시스템(Amazon EFS)

파일 스토리지

파일 스토리지에서는 여러 클라이언트(사용자, 애플리케이션, 서버 등)가 공유 파일 폴더에 저장된 데이터에 액세스할 수 있습니다. 이 접근 방식에서 스토리지 서버는 로컬 파일 시스템과 함께 블록 스토리지를 사용하여 파일을 구성합니다. 클라이언트는 파일 경로를 통해 데이터에 액세스합니다.

블록 스토리지와 객체 스토리지에 비해 파일 스토리지는 많은 수의 서비스와 리소스가 동시에 동일한 데이터에 액세스해야 하는 사용 사례에 이상적입니다.

AmazonEFS(Amazon Elastic File System)는 AWS 클라우드 서비스 및 온프레미스 리소스와 함께 사용되는 확장 가능한 파일 시스템입니다. 파일을 추가하고 제거할 때 Amazon EFS는 자동으로 확장 및 축소됩니다. 애플리케이션을 중단하지 않고도 필요에 따라 페타바이트까지 확장할 수 있습니다.

Amazon EBS와 Amazon EFS 비교

Amazon EBS

Amazon EBS 볼륨은단일 가용 영역에 데이터를 저장합니다.
Amazon EC2 인스턴스를 EBS 볼륨에 연결하려면 Amazon EC2 인스턴스와 EBS 볼륨이 모두 동일한 가용 영역 내에 있어야 합니다.

Amazon EFS

Amazon EFS는 리전 서비스입니다.여러 가용 영역에 걸쳐 데이터를 저장합니다.
중복 스토리지를 사용하면 파일 시스템이 위치한 리전의 모든 가용 영역에서 동시에 데이터에 액세스할 수 있습니다. 또한 온프레미스 서버는 AWS 다이렉트 커넥트를 사용하여 Amazon EFS에 액세스할 수 있습니다.

Amazon 관계형 데이터베이스 서비스(Amazon RDS)

관계형 데이터베이스

관계형 데이터베이스에서 데이터는 다른 데이터와 연관되는 방식으로 저장됩니다.

관계형 데이터베이스의 예로는 커피숍의 재고 관리 시스템을 들 수 있습니다. 데이터베이스의 각 레코드에는 제품 이름, 크기, 가격 등과 같은 단일 품목에 대한 데이터가 포함됩니다.

관계형 데이터베이스는구조화된 쿼리 언어(SQL)를 사용하여 데이터를 저장하고 쿼리합니다. 이 접근 방식을 사용하면 데이터를 쉽게 이해할 수 있고 일관되며 확장 가능한 방식으로 저장할 수 있습니다. 예를 들어, 커피숍 주인은 SQL 쿼리를 작성하여 가장 자주 구매하는 음료가 미디엄 라떼인 고객을 모두 식별할 수 있습니다.

관계형 데이터베이스의 데이터 예시:

ID	제품 이름	사이즈	가격
1	미디엄 로스트 그라운드 커피	12 온스	$5.30
2	다크 로스트 분쇄 커피	20 온스	$9.27

Amazon 관계형 데이터베이스 서비스

Amazon 관계형데이터베이스 서비스(Amazon RDS)는 AWS 클라우드에서 관계형 데이터베이스를 실행할 수 있는 서비스입니다.

Amazon RDS는 하드웨어 프로비저닝, 데이터베이스 설정, 패치 및 백업과 같은 작업을 자동화하는 관리형 서비스입니다. 이러한 기능을 사용하면 관리 작업을 완료하는 데 소요되는 시간을 줄이고 데이터를 사용하여 애플리케이션을 혁신하는 데 더 많은 시간을 할애할 수 있습니다. 서버리스 애플리케이션에서 데이터베이스를 쿼리하기 위해 AWS Lambda를 사용하는 등 비즈니스 및 운영 요구 사항을 충족하기 위해 Amazon RDS를 다른 서비스와 통합할 수 있습니다.

Amazon RDS는 다양한 보안 옵션을 제공합니다. 많은 Amazon RDS 데이터베이스 엔진은 미사용 암호화(데이터가 저장되는 동안 데이터 보호) 및 전송 중 암호화(데이터를 주고받는 동안 데이터 보호)를 제공합니다.

Amazon RDS 데이터베이스 엔진

Amazon RDS는 메모리, 성능 또는 입출력(I/O)을 최적화하는 6개의 데이터베이스 엔진에서 사용할 수 있습니다. 지원되는 데이터베이스 엔진은 다음과 같습니다:

Amazon Aurora
PostgreSQL
MySQL
MariaDB
Oracle 데이터베이스
Microsoft SQL Server

Amazon Aurora

Amazon Aurora는 엔터프라이즈급 관계형 데이터베이스입니다. MySQL 및 PostgreSQL 관계형 데이터베이스와 호환됩니다. 표준 MySQL 데이터베이스보다 최대 5배, 표준 PostgreSQL 데이터베이스보다 최대 3배 빠릅니다.

Amazon Aurora는 데이터베이스 리소스의 안정성과 가용성을 유지하면서 불필요한 입출력(I/O) 작업을 줄여 데이터베이스 비용을 절감하는 데 도움이 됩니다.

워크로드에 고가용성이 필요한 경우 Amazon Aurora를 고려하세요. 이 서비스는 3개의 가용 영역에 걸쳐 6개의 데이터 사본을 복제하고 Amazon S3에 데이터를 지속적으로 백업합니다.

Amazon DynamoDB

비관계형 데이터베이스

비관계형 데이터베이스에서는 테이블을 만듭니다. 테이블은 데이터를 저장하고 쿼리할 수 있는 공간입니다.

비관계형 데이터베이스는 행과 열이 아닌 다른 구조를 사용하여 데이터를 구성하기 때문에 "NoSQL 데이터베이스"라고도 합니다. 비관계형 데이터베이스의 구조적 접근 방식 중 한 가지 유형은 키-값 쌍입니다. 키-값 쌍을 사용하면 데이터가 항목(키)으로 구성되고 항목에는 속성(값)이 있습니다. 속성은 데이터의 다양한 특징이라고 생각할 수 있습니다.

키-값 데이터베이스에서는 언제든지 테이블의 항목에서 속성을 추가하거나 제거할 수 있습니다. 또한 테이블의 모든 항목이 동일한 속성을 가질 필요는 없습니다.

비관계형 데이터베이스의 데이터 예시:

Key	Value
1	Name: John Doe 주소 123 애니 스트리트 좋아하는 음료: 미디엄 라떼
2	이름 메리 메이저 주소 100 메인 스트리트 생일 1994년 7월 5일

아마존 다이나모DB

Amazon DynamoDB는 키-값 데이터베이스 서비스입니다. 모든 규모에서 한 자릿수 밀리초 성능을 제공합니다.

서버리스

DynamoDB는 서버리스이므로 서버를 프로비저닝, 패치 또는 관리할 필요가 없습니다.
또한 소프트웨어를 설치, 유지, 운영할 필요도 없습니다.

자동 확장

데이터베이스의 크기가 줄어들거나 커지면 DynamoDB는 일관된 성능을 유지하면서 용량 변화에 맞게 자동으로 확장합니다.
따라서 확장하는 동안 고성능이 필요한 사용 사례에 적합한 선택입니다.

아마존 레드시프트

Amazon Redshift는 빅 데이터 분석에 사용할 수 있는 데이터 웨어하우징 서비스입니다. 다양한 소스에서 데이터를 수집할 수 있는 기능을 제공하며 데이터 전반의 관계와 추세를 파악하는 데 도움이 됩니다.

AWS 데이터베이스 마이그레이션 서비스(AWS DMS)

AWS데이터베이스 마이그레이션 서비스(AWS DMS)를 사용하면 관계형 데이터베이스, 비관계형 데이터베이스 및 기타 유형의 데이터 저장소를 마이그레이션할 수 있습니다.

AWS DMS를 사용하면 소스 데이터베이스와 대상 데이터베이스 간에 데이터를 이동할 수 있습니다.소스 데이터베이스와 대상 데이터베이스는 동일한 유형이거나 다른 유형일 수 있습니다. 마이그레이션하는 동안 소스 데이터베이스는 계속 작동하므로 데이터베이스에 의존하는 모든 애플리케이션의 다운타임을 줄일 수 있습니다.

예를 들어 Amazon EC2 인스턴스 또는 Amazon RDS에 온프레미스에 저장된 MySQL 데이터베이스가 있다고 가정해 보겠습니다. MySQL 데이터베이스를 소스 데이터베이스로 간주합니다. AWS DMS를 사용하면 Amazon Aurora 데이터베이스와 같은 대상 데이터베이스로 데이터를 마이그레이션할 수 있습니다.

AWS DMS의 기타 사용 사례

개발 및 테스트 데이터베이스 마이그레이션

개발자가 프로덕션 사용자에게 영향을 주지 않고 프로덕션 데이터에 대해 애플리케이션을 테스트할 수 있도록 지원

데이터베이스 통합

여러 데이터베이스를 단일 데이터베이스로 결합

지속적인 복제

일회성 마이그레이션 대신 다른 대상 소스로 데이터의 지속적인 복사본 전송

추가 데이터베이스 서비스

Amazon DocumentDB

Amazon DocumentDB는 MongoDB 워크로드를 지원하는 문서 데이터베이스 서비스입니다. (MongoDB는 문서 데이터베이스 프로그램입니다.)

Amazon Neptune

Amazon Neptune은 그래프 데이터베이스 서비스입니다.

Amazon Neptune을 사용하여 추천 엔진, 사기 탐지 및 지식 그래프와 같이 고도로 연결된 데이터 집합으로 작동하는 애플리케이션을 빌드하고 실행할 수 있습니다.

Amazon 퀀텀 원장 데이터베이스(Amazon QLDB)

Amazon퀀텀 원장 데이터베이스(Amazon QLDB)는 원장 데이터베이스 서비스입니다.

Amazon QLDB를 사용하여 애플리케이션 데이터에 적용된 모든 변경 사항의 전체 이력을 검토할 수 있습니다.

Amazon 관리형 블록체인

Amazon 관리형 블록체인은 오픈 소스 프레임워크로 블록체인 네트워크를 생성하고 관리하는 데 사용할 수 있는 서비스입니다.

블록체인은 중앙 기관 없이 여러 당사자가 트랜잭션을 실행하고 데이터를 공유할 수 있는 분산 원장 시스템입니다.

Amazon ElastiCache

Amazon ElastiCache는 데이터베이스 위에 캐싱 레이어를 추가하여 일반적인 요청의 읽기 시간을 개선하는 데 도움이 되는 서비스입니다.

두 가지 유형의 데이터 저장소를 지원합니다: Redis와 Memcached.

Amazon DynamoDB 액셀러레이터

Amazon DynamoDB Accelerator(DAX)는 DynamoDB용 인메모리 캐시입니다.

응답 시간을 한 자릿수 밀리초에서 마이크로초로 개선하는 데 도움이 됩니다

서비스명	정의	주요 특징	시험 키워드
Amazon RDS	관리형 관계형 데이터베이스 서비스	MySQL, PostgreSQL, MariaDB, Oracle, SQL Server 지원 / 자동 백업, 패치 / Multi-AZ, 읽기 전용 복제본 지원	관계형 DB, 관리형, 자동 백업, 고가용성
Amazon Aurora	클라우드 최적화된 MySQL 및 PostgreSQL 호환 관계형 DB	표준 MySQL 대비 최대 5배, PostgreSQL 대비 최대 3배 성능 / 고가용성 / 자동 확장 스토리지	고성능, 고가용성, MySQL 호환, PostgreSQL 호환
Amazon DynamoDB	완전 관리형 NoSQL 키-값 및 문서 데이터베이스	밀리초 단위 응답 / 서버리스 / 자동 확장 / 글로벌 테이블 지원	NoSQL, 키-값, 문서, 서버리스, 초고속
Amazon Redshift	완전 관리형 데이터 웨어하우스 서비스	페타바이트 규모 분석 / SQL 기반 쿼리 / BI 도구 통합 / 열 기반 저장	데이터 웨어하우스, 분석, BI, 대규모 데이터
Amazon ElastiCache	인메모리 캐싱 서비스	Redis, Memcached 지원 / 마이크로초 응답 속도 / 세션 저장, 캐싱, 실시간 분석	인메모리, 캐싱, Redis, Memcached
Amazon Neptune	완전 관리형 그래프 데이터베이스	관계 중심 데이터 모델링 / RDF, LPG 지원 / 그래프 쿼리 언어 지원	그래프 DB, RDF, LPG
Amazon DocumentDB	MongoDB 호환 관리형 문서 데이터베이스	JSON 기반 문서 저장 / MongoDB API 호환 / 자동 백업	문서형, JSON, MongoDB 호환
AWS Database Migration Service (DMS)	데이터베이스 간 이관 지원 서비스	다운타임 최소화 / 동종·이기종 간 마이그레이션 지원	DB 마이그레이션, 최소 다운타임

AWS CLF-02 #4 상세 정리

ReinaMoon — Mon, 11 Aug 2025 20:45:49 +0900

AWS에 연결

Amazon 가상 프라이빗 클라우드(Amazon VPC)

AWS 서비스를 사용하는 수백만 명의 고객을 상상해 보세요. 또한 이러한 고객이 Amazon EC2 인스턴스와 같이 생성한 수백만 개의 리소스를 상상해 보세요. 이러한 모든 리소스에 경계가 없다면 네트워크 트래픽이 리소스 간에 제한 없이 이동할 수 있을 것입니다.

AWS 리소스에 경계를 설정하는 데 사용할 수 있는 네트워킹 서비스는Amazon 가상 프라이빗 클라우드(Amazon VPC)입니다.

Amazon VPC를 사용하면 AWS 클라우드의 격리된 섹션을 프로비저닝할 수 있습니다. 이 격리된 섹션에서는 정의한 가상 네트워크에서 리소스를 시작할 수 있습니다. 가상 프라이빗 클라우드(VPC) 내에서 리소스를 서브넷으로 구성할 수 있습니다.서브넷은 Amazon EC2 인스턴스와 같은 리소스를 포함할 수 있는 VPC의 섹션입니다.

인터넷 게이트웨이

인터넷의 공용 트래픽이 VPC에 액세스할 수 있도록 하려면인터넷 게이트웨이를 VPC에 연결합니다.

인터넷 게이트웨이는 VPC와 인터넷 간의 연결입니다. 인터넷 게이트웨이는 고객이 커피숍에 들어올 때 사용하는 출입구와 비슷하다고 생각하면 됩니다. 인터넷 게이트웨이가 없으면 아무도 VPC 내의 리소스에 액세스할 수 없습니다.

프라이빗 리소스만 포함된 VPC가 있다면 어떨까요?

가상 사설 게이트웨이

다음은 가상 사설 게이트웨이의 작동 방식에 대한 예시입니다. 인터넷을 집과 커피숍 사이의 도로라고 생각하면 됩니다. 여러분을 보호하기 위해 경호원과 함께 이 도로를 여행하고 있다고 가정해 봅시다. 여전히 다른 고객과 같은 도로를 이용하지만 추가 보호 계층이 있습니다.

보디가드는 주변의 다른 모든 요청으로부터 인터넷 트래픽을 암호화(또는 보호)하는 가상 사설망(VPN) 연결과 같습니다.

가상 사설 게이트웨이는 보호된 인터넷 트래픽이 VPC로 들어갈 수 있도록 하는 구성 요소입니다. 커피숍에 대한 연결이 추가적으로 보호되더라도 다른 고객과 같은 도로를 사용하기 때문에 트래픽 정체가 발생할 수 있습니다.

가상 사설 게이트웨이를 사용하면 VPC와 온프레미스 데이터 센터 또는 기업 내부 네트워크와 같은 사설 네트워크 간에 가상 사설망(VPN) 연결을 설정할 수 있습니다. 가상 사설 게이트웨이는 트래픽이 승인된 네트워크에서 오는 경우에만 VPC로 트래픽을 허용합니다.

AWS 다이렉트 커넥트

AWS 다이렉트 커넥트는 데이터 센터와 VPC 간에 전용 프라이빗 연결을 설정할 수 있는 서비스입니다.

건물과 커피숍을 직접 연결하는 복도가 있는 아파트 건물이 있다고 가정해 보겠습니다. 아파트 거주자만 이 복도를 통과할 수 있습니다.

이 전용 복도는 AWS 다이렉트 커넥트와 동일한 유형의 전용 연결을 제공합니다. 주민들은 다른 고객과 공유하는 공용 도로를 이용할 필요 없이 커피숍에 들어갈 수 있습니다.

AWS 다이렉트 커넥트가 제공하는 전용 연결은 네트워크 비용을 절감하고 네트워크를 통해 이동할 수 있는 대역폭의 양을 늘리는 데 도움이 됩니다.

서브넷 및 네트워크 액세스 제어 목록

VPC 내에서 서브넷의 역할에 대해 자세히 알아보려면 다음 커피숍의 예를 검토하세요.

먼저 고객이 계산원에게 주문을 전달합니다. 그러면 계산원이 바리스타에게 주문을 전달합니다. 이 프로세스를 통해 더 많은 고객이 들어와도 줄을 원활하게 운영할 수 있습니다.

일부 고객이 계산대 줄을 건너뛰고 바리스타에게 직접 주문을 하려고 한다고 가정해 보겠습니다. 이로 인해 트래픽 흐름이 중단되고 고객이 커피숍의 제한된 부분만 이용할 수 있게 됩니다.

이 문제를 해결하기 위해 커피숍 주인은 계산원과 바리스타를 별도의 워크스테이션에 배치하여 카운터 공간을 나눕니다. 계산원의 워크스테이션은 공개적으로 고객을 맞이하도록 설계되었습니다. 바리스타의 영역은 개인 공간입니다. 바리스타는 여전히 계산원으로부터 주문을 받을 수 있지만 고객으로부터 직접 주문을 받을 수는 없습니다.

이는 AWS 네트워킹 서비스를 사용하여 리소스를 분리하고 네트워크 트래픽의 흐름을 정확하게 결정하는 방법과 유사합니다.

커피숍에서는 카운터 영역을 VPC로 생각할 수 있습니다. 카운터 영역은 계산원의 워크스테이션과 바리스타의 워크스테이션을 위한 두 개의 별도 영역으로 나뉩니다. VPC에서서브넷은 리소스를 함께 그룹화하는 데 사용되는 별도의 영역입니다.

서브넷

서브넷은 보안 또는 운영상의 필요에 따라 리소스를 그룹화할 수 있는 VPC의 섹션입니다. 서브넷은 공용 또는 비공개일 수 있습니다.

공용 서브넷에는 온라인 스토어 웹사이트와 같이 일반인이 액세스할 수 있어야 하는 리소스가 포함됩니다.

비공개 서브넷에는 고객의 개인 정보 및 주문 내역이 포함된 데이터베이스와 같이 비공개 네트워크를 통해서만 액세스해야 하는 리소스가 포함됩니다.

VPC에서 서브넷은 서로 통신할 수 있습니다. 예를 들어 공용 서브넷에 있는 Amazon EC2 인스턴스가 사설 서브넷에 있는 데이터베이스와 통신하는 애플리케이션이 있을 수 있습니다.

VPC의 네트워크 트래픽

고객이 AWS 클라우드에서 호스팅되는 애플리케이션에서 데이터를 요청하면 이 요청은 패킷으로 전송됩니다.패킷은 인터넷이나 네트워크를 통해 전송되는 데이터의 단위입니다.

패킷은 인터넷 게이트웨이를 통해 VPC로 들어갑니다. 패킷이 서브넷으로 들어가거나 서브넷에서 나가기 전에 패킷은 권한을 확인합니다. 이러한 권한은 패킷을 보낸 사람과 패킷이 서브넷의 리소스와 통신하려는 방법을 나타냅니다.

서브넷에 대한 패킷 권한을 확인하는 VPC 구성 요소는네트워크 액세스 제어 목록(ACL)입니다.

네트워크 액세스 제어 목록(ACL)

네트워크 액세스 제어 목록(ACL)은 서브넷 수준에서 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽입니다.

예를 들어 커피숍 밖으로 나와 공항에 있다고 상상해 보세요. 공항에서는 여행자들이 다른 나라로 입국하려고 합니다. 여행자를 패킷으로, 여권 심사관을 네트워크 ACL로 생각할 수 있습니다. 여권 심사관은 여행자가 입국할 때와 출국할 때 모두 여행자의 자격 증명을 확인합니다. 여행자가 승인된 목록에 있는 경우 통과할 수 있습니다. 그러나 승인된 목록에 없거나 명시적으로 금지된 여행자 목록에 있는 경우, 해당 여행자는 입국할 수 없습니다.

각 AWS 계정에는 기본 네트워크 ACL이 포함되어 있습니다. VPC를 구성할 때 계정의 기본 네트워크 ACL을 사용하거나 사용자 지정 네트워크 ACL을 만들 수 있습니다.

기본적으로 계정의 기본 네트워크 ACL은 모든 인바운드 및 아웃바운드 트래픽을 허용하지만 자체 규칙을 추가하여 수정할 수 있습니다. 사용자 지정 네트워크 ACL의 경우 허용할 트래픽을 지정하는 규칙을 추가하기 전까지는 모든 인바운드 및 아웃바운드 트래픽이 거부됩니다. 또한 모든 네트워크 ACL에는 명시적 거부 규칙이 있습니다. 이 규칙은 패킷이 목록의 다른 규칙과 일치하지 않는 경우 패킷이 거부되도록 합니다.

상태 비저장 패킷 필터링

네트워크 ACL은상태 비저장 패킷 필터링을 수행합니다. 아무것도 기억하지 않고 서브넷 경계를 통과하는 패킷을 인바운드와 아웃바운드 양방향으로 확인합니다.

다른 나라로 입국하려는 여행자의 이전 예를 떠올려 보세요. 이는 Amazon EC2 인스턴스에서 인터넷으로 요청을 보내는 것과 유사합니다.

해당 요청에 대한 패킷 응답이 서브넷으로 돌아올 때 네트워크 ACL은 이전 요청을 기억하지 못합니다. 네트워크 ACL은 패킷 응답을 규칙 목록과 대조하여 허용 또는 거부 여부를 결정합니다.

패킷이 서브넷에 들어온 후에는 Amazon EC2 인스턴스와 같은 서브넷 내의 리소스에 대한 권한을 평가해야 합니다.

Amazon EC2 인스턴스에 대한 패킷 권한을 확인하는 VPC 구성 요소는보안 그룹입니다.

보안 그룹

보안 그룹은 Amazon EC2 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽입니다.

기본적으로 보안 그룹은 모든 인바운드 트래픽을 거부하고 모든 아웃바운드 트래픽을 허용합니다. 사용자 지정 규칙을 추가하여 허용하거나 거부할 트래픽을 구성할 수 있습니다.

이 예제에서는 로비에서 손님을 맞이하는 도어 어텐던트가 있는 아파트 건물에 있다고 가정합니다. 손님을 패킷으로, 도어 어텐던트를 보안 그룹으로 생각할 수 있습니다. 손님이 도착하면 도어 어텐던트는 명단을 확인하여 건물에 들어갈 수 있는지 확인합니다. 그러나 도어 어텐던트는 게스트가 건물에서 나갈 때 목록을 다시 확인하지 않습니다

서브넷 내에 여러 Amazon EC2 인스턴스가 있는 경우, 동일한 보안 그룹에 연결하거나 각 인스턴스에 대해 다른 보안 그룹을 사용할 수 있습니다.

스테이트풀 패킷 필터링

보안 그룹은상태 저장 패킷 필터링을 수행합니다. 보안 그룹은 들어오는 패킷에 대해 이전에 내린 결정을 기억합니다.

Amazon EC2 인스턴스에서 인터넷으로 요청을 보내는 동일한 예를 생각해 보겠습니다.

해당 요청에 대한 패킷 응답이 인스턴스로 돌아오면 보안 그룹은 이전 요청을 기억합니다. 보안 그룹은 인바운드 보안 그룹 규칙에 관계없이 응답을 계속 진행하도록 허용합니다.

네트워크 ACL과 보안 그룹을 모두 사용하면 VPC의 트래픽에 대한 사용자 지정 규칙을 구성할 수 있습니다. AWS 보안 및 네트워킹에 대해 계속 알아가면서 네트워크 ACL과 보안 그룹의 차이점을 이해해야 합니다

글로벌 네트워킹

도메인 이름 시스템(DNS)

애니컴퍼니에 AWS 클라우드에서 호스팅되는 웹사이트가 있다고 가정해 보겠습니다. 고객이 브라우저에 웹 주소를 입력하면 웹사이트에 액세스할 수 있습니다. 이는도메인 이름 시스템(DNS) 확인으로 인해 발생합니다. DNS 확인에는 DNS 서버가 웹 서버와 통신하는 것이 포함됩니다.

DNS는 인터넷의 전화번호부라고 생각하면 됩니다. DNS 확인은 도메인 이름을 IP 주소로 변환하는 프로세스입니다.

예를 들어 애니컴퍼니의 웹사이트를 방문한다고 가정해 보겠습니다.

브라우저에 도메인 이름을 입력하면 이 요청이 DNS 서버로 전송됩니다.
DNS 서버는 웹 서버에 애니컴퍼니 웹사이트에 해당하는 IP 주소를 요청합니다.
웹 서버는 애니컴퍼니 웹사이트의 IP 주소인 192.0.2.0을 제공함으로써 응답합니다.

Amazon Route 53

Amazon Route 53은 DNS 웹 서비스입니다. 이 서비스는 개발자와 기업이 최종 사용자를 AWS에서 호스팅되는 인터넷 애플리케이션으로 라우팅할 수 있는 안정적인 방법을 제공합니다.

Amazon Route 53은 사용자 요청을 AWS에서 실행되는 인프라(예: Amazon EC2 인스턴스 및 로드 밸런서)에 연결합니다. 사용자를 AWS 외부의 인프라로 라우팅할 수도 있습니다.

Route 53의 또 다른 기능은 도메인 이름에 대한 DNS 레코드를 관리하는 기능입니다. Route 53에서 직접 새 도메인 네임을 등록할 수 있습니다. 다른 도메인 등록기관에서 관리하는 기존 도메인 네임에 대한 DNS 레코드를 이전할 수도 있습니다. 이를 통해 단일 위치에서 모든 도메인 네임을 관리할 수 있습니다.

이전 모듈에서는 콘텐츠 전송 서비스인 Amazon CloudFront에 대해 배웠습니다. 다음 예에서는 고객에게 콘텐츠를 전달하기 위해 Route 53과 Amazon CloudFront가 함께 작동하는 방법을 설명합니다.

예제: Amazon Route 53과 Amazon CloudFront가 콘텐츠를 전달하는 방법

AnyCompany의 애플리케이션이 여러 Amazon EC2 인스턴스에서 실행되고 있다고 가정합니다. 이러한 인스턴스는 애플리케이션 로드 밸런서에 연결되는 자동 확장 그룹에 있습니다.

고객이 AnyCompany의 웹사이트로 이동하여 애플리케이션에서 데이터를 요청합니다.
Amazon Route 53은 DNS 확인을 사용하여 AnyCompany.com의 해당 IP 주소인 192.0.2.0을 식별합니다. 이 정보는 고객에게 다시 전송됩니다.
고객의 요청은 Amazon CloudFront를 통해 가장 가까운 엣지 위치로 전송됩니다.
Amazon CloudFront는 애플리케이션 로드 밸런서에 연결하여 들어오는 패킷을 Amazon EC2 인스턴스로 보냅니다.

리소스

AWS CLF-02 #3 상세 정리

ReinaMoon — Mon, 11 Aug 2025 20:39:34 +0900

지역 선택

서비스, 데이터 및 애플리케이션에 적합한 지역을 결정할 때는 다음 네 가지 비즈니스 요소를 고려하세요.

데이터 거버넌스 및 법적 요건 준수

회사 및 위치에 따라 특정 지역에서 데이터를 실행해야 할 수도 있습니다. 예를 들어, 회사에서 모든 데이터를 영국 경계 내에 저장해야 하는 경우 런던 리전을 선택할 수 있습니다.

모든 회사에 위치별 데이터 규정이 있는 것은 아니므로 다른 세 가지 요소에 더 집중해야 할 수도 있습니다.

고객과의 근접성

고객과 가까운 지역을 선택하면 고객에게 콘텐츠를 더 빠르게 제공하는 데 도움이 됩니다. 예를 들어 회사가 워싱턴 DC에 기반을 두고 있고 많은 고객이 싱가포르에 거주한다고 가정해 보겠습니다. 회사 본사와 가까운 북부 버지니아 리전에서 인프라를 실행하고 싱가포르 리전에서 애플리케이션을 실행하는 것을 고려할 수 있습니다.

리전 내에서 사용 가능한 서비스

때로는 가장 가까운 리전에 고객에게 제공하려는 모든 기능이 없을 수도 있습니다. AWS는 새로운 서비스를 만들고 기존 서비스 내에서 기능을 확장하는 방식으로 혁신을 거듭하고 있습니다. 그러나 전 세계에 새로운 서비스를 제공하려면 AWS가 리전 하나하나에 물리적 하드웨어를 구축해야 하는 경우가 있습니다.

개발자가 Amazon Braket(AWS 양자 컴퓨팅 플랫폼)을 사용하는 애플리케이션을 구축하고자 한다고 가정해 보겠습니다. 이 과정에서는 아직 전 세계 모든 AWS 리전에서 Amazon Braket을 사용할 수 있는 것은 아니므로 개발자는 이미 이를 제공하는 리전 중 하나에서 실행해야 합니다.

가격

미국과 브라질에서 애플리케이션을 실행하는 것을 고려하고 있다고 가정해 보겠습니다. 브라질의 세금 구조가 설정되어 있기 때문에 동일한 워크로드를 상파울루 리전에서 실행하는 것이 오레곤 리전에서 실행하는 것보다 50% 더 많은 비용이 들 수 있습니다.

가용성 영역

가용성영역은 리전 내의 단일 데이터 센터 또는 데이터 센터 그룹입니다. 가용 영역은 서로 수십 마일 떨어진 곳에 위치합니다. 이는 가용 영역 간의 지연 시간(콘텐츠 요청과 수신 사이의 시간)이 짧을 정도로 충분히 가깝습니다. 그러나 리전의 한 부분에서 재해가 발생하면 여러 가용 영역이 영향을 받을 가능성을 줄일 수 있을 만큼 충분히 멀리 떨어져 있습니다.

여러 가용 영역에서 Amazon EC2 인스턴스 실행하기

단일 가용 영역의 Amazon EC2 인스턴스

북부 캘리포니아 리전에 있는 단일 Amazon EC2 인스턴스에서 애플리케이션을 실행하고 있다고 가정해 보겠습니다. 이 인스턴스는 us-west-1a 가용 영역에서 실행 중입니다. Us-west-1a에 장애가 발생하면 인스턴스를 잃게 됩니다.

여러 가용 영역에 있는 Amazon EC2 인스턴스

모범 사례는 리전 내 2개 이상의 가용 영역에서 애플리케이션을 실행하는 것입니다. 이 예에서는 us-west-1b에서 두 번째 Amazon EC2 인스턴스를 실행하도록 선택할 수 있습니다.

가용 영역 장애

Us-west-1a에 장애가 발생해도 애플리케이션은 여전히 us-west-1b에서 실행됩니다.

에지 위치는 Amazon CloudFront가 더 빠른 전송을 위해 고객과 더 가까운 곳에 콘텐츠의 캐시된 사본을 저장하는 데 사용하는 사이트입니다.

Origin회사 데이터가 브라질에 저장되어 있고 중국에 거주하는 고객이 있다고 가정해 보겠습니다. 이러한 고객에게 콘텐츠를 제공하기 위해 모든 콘텐츠를 중국 리전 중 하나로 이동할 필요는 없습니다.

엣지 위치

고객이 브라질에서 데이터를 가져오도록 요청하는 대신 중국의 고객과 가까운 엣지 위치에 로컬로 사본을 캐시할 수 있습니다.

고객

중국에 있는 고객이 파일 중 하나를 요청하면 Amazon CloudFront가 에지 위치의 캐시에서 파일을 검색하여 고객에게 파일을 전달합니다. 브라질의 원본 소스가 아닌 중국 근처의 엣지 위치에서 파일을 가져왔기 때문에 고객에게 파일이 더 빨리 전달됩니다.

AWS 서비스와 상호 작용하는 방법

AWS 관리 콘솔

AWS 관리 콘솔은 AWS 서비스에 액세스하고 관리하기 위한 웹 기반 인터페이스입니다. 최근에 사용한 서비스에 빠르게 액세스하고 이름, 키워드 또는 약어로 다른 서비스를 검색할 수 있습니다. 콘솔에는 작업 완료 프로세스를 간소화할 수 있는 마법사와 자동화된 워크플로가 포함되어 있습니다. 또한 AWS 콘솔 모바일 애플리케이션을 사용하여 리소스 모니터링, 알람 보기, 청구 정보 액세스 등의 작업을 수행할 수 있습니다. 여러 ID가 동시에 AWS 콘솔 모바일 앱에 로그인 상태를 유지할 수 있습니다

AWS 명령줄 인터페이스

API 요청 시 시간을 절약하기 위해AWS 명령줄 인터페이스(AWS CLI)를 사용할 수 있습니다. AWS CLI를 사용하면 하나의 도구 내에서 명령줄로 여러 AWS 서비스를 직접 제어할 수 있습니다. AWS CLI는 Windows, macOS, Linux 사용자가 사용할 수 있습니다.

AWS CLI를 사용하면 스크립트를 통해 서비스 및 애플리케이션이 수행하는 작업을 자동화할 수 있습니다. 예를 들어, 명령을 사용하여 Amazon EC2 인스턴스를 시작하고, Amazon EC2 인스턴스를 특정 자동 스케일링 그룹에 연결하는 등의 작업을 수행할 수 있습니다.

소프트웨어 개발 키트 (SDK)

AWS 서비스에 액세스하고 관리하기 위한 또 다른 옵션은소프트웨어 개발 키트(SDK)입니다. SDK를 사용하면 프로그래밍 언어 또는 플랫폼에 맞게 설계된 API를 통해 AWS 서비스를 더 쉽게 사용할 수 있습니다. SDK를 사용하면 기존 애플리케이션과 함께 AWS 서비스를 사용하거나 AWS에서 실행될 완전히 새로운 애플리케이션을 만들 수 있습니다.

SDK 사용을 시작하는 데 도움이 되도록 AWS는 지원되는 각 프로그래밍 언어에 대한 문서와 샘플 코드를 제공합니다. 지원되는 프로그래밍 언어에는 C++, Java, .NET 등이 있습니다.

AWS Elastic Beanstalk 및 AWS CloudFormation

AWS Elastic Beanstalk

AWS Elastic Beanstalk를 사용하면 사용자가 코드와 구성 설정을 제공하고, Elastic Beanstalk가 다음 작업을 수행하는 데 필요한 리소스를 배포합니다:

용량 조정
로드 밸런싱
자동 확장
애플리케이션 상태 모니터링

AWS CloudFormation

AWS CloudFormation을 사용하면 인프라를 코드로 취급할 수 있습니다. 즉, 리소스를 개별적으로 프로비저닝하기 위해 AWS 관리 콘솔을 사용하는 대신 코드 한 줄을 작성하여 환경을 구축할 수 있습니다.

AWS CloudFormation은 안전하고 반복 가능한 방식으로 리소스를 프로비저닝하므로 수동 작업을 수행하거나 사용자 정의 스크립트를 작성할 필요 없이 인프라 및 애플리케이션을 자주 빌드할 수 있습니다. 스택을 관리할 때 수행해야 할 올바른 작업을 결정하고 오류가 감지되면 자동으로 변경 사항을 롤백합니다.

리소스

AWS CLF-02 #2 상세 정리

ReinaMoon — Sun, 10 Aug 2025 06:23:27 +0900

Amazon Elastic Compute Cloud(Amazon EC2)

Amazon EC2(Amazon Elastic Compute Cloud)는 클라우드에서 Amazon EC2 인스턴스로 안전하고 크기 조정이 가능한 컴퓨팅 용량을 제공합니다.

회사 리소스의 아키텍처를 책임지고 있으며 새로운 웹사이트를 지원해야 한다고 가정해 보세요. 기존의 온프레미스 리소스를 사용하면 다음과 같은 작업을 수행해야 합니다:

하드웨어를 구매하기 위해 선불로 돈을 지출합니다.
서버가 배송될 때까지 기다립니다.
물리적 데이터 센터에 서버를 설치합니다.
필요한 모든 구성을 수행합니다.

이에 비해 Amazon EC2 인스턴스를 사용하면 가상 서버를 사용하여 AWS 클라우드에서 애플리케이션을 실행할 수 있습니다.

몇 분 안에 Amazon EC2 인스턴스를 프로비저닝하고 시작할 수 있습니다.
워크로드 실행이 끝나면 사용을 중단할 수 있습니다.
인스턴스를 중지하거나 종료할 때가 아니라 실행 중일 때 사용한 컴퓨팅 시간에 대해서만 비용을 지불합니다.
필요하거나 원하는 서버 용량에 대해서만 비용을 지불하여 비용을 절감할 수 있습니다.

Amazon EC2 작동 방식

시작

먼저 인스턴스를 시작합니다. 인스턴스에 대한 기본 구성이 포함된 템플릿을 선택하여 시작합니다. 이러한 구성에는 운영 체제, 애플리케이션 서버 또는 애플리케이션이 포함됩니다. 또한 인스턴스의 특정 하드웨어 구성인 인스턴스 유형도 선택합니다.

인스턴스 시작을 준비할 때 인스턴스 안팎으로 유입 및 유출될 수 있는 네트워크 트래픽을 제어하기 위한 보안 설정을 지정합니다.

연결하기

다음으로 인스턴스에 연결합니다. 여러 가지 방법으로 인스턴스에 연결할 수 있습니다. 프로그램과 애플리케이션은 인스턴스에 직접 연결하여 데이터를 교환할 수 있는 여러 가지 방법을 사용할 수 있습니다. 사용자는 로그인하여 컴퓨터 데스크톱에 액세스하여 인스턴스에 연결할 수도 있습니다.

사용

인스턴스에 연결한 후에는 인스턴스 사용을 시작할 수 있습니다. 명령을 실행하여 소프트웨어 설치, 스토리지 추가, 파일 복사 및 정리 등의 작업을 수행할 수 있습니다.

Amazon EC2 인스턴스 유형

Amazon EC2 인스턴스 유형은 다양한 작업에 최적화되어 있습니다. 인스턴스 유형을 선택할 때는 워크로드 및 애플리케이션의 특정 요구 사항을 고려하세요. 여기에는 컴퓨팅, 메모리 또는 스토리지 기능에 대한 요구 사항이 포함될 수 있습니다.

범용 인스턴스

범용 인스턴스는 컴퓨팅, 메모리 및 네트워킹 리소스의 균형을 제공합니다. 다음과 같은 다양한 워크로드에 사용할 수 있습니다:

애플리케이션 서버
게임 서버
엔터프라이즈 애플리케이션용 백엔드 서버
중소규모 데이터베이스

컴퓨팅, 메모리 및 네트워킹에 필요한 리소스가 거의 동일한 애플리케이션이 있다고 가정해 보겠습니다. 이 애플리케이션은 단일 리소스 영역에서 최적화가 필요하지 않으므로 범용 인스턴스에서 실행하는 것을 고려할 수 있습니다.

컴퓨팅 최적화 인스턴스

컴퓨팅최적화 인스턴스는 고성능 프로세서의 이점을 활용하는 컴퓨팅 기반 애플리케이션에 이상적입니다. 범용 인스턴스와 마찬가지로 웹, 애플리케이션, 게임 서버와 같은 워크로드에 컴퓨팅 최적화 인스턴스를 사용할 수 있습니다.

그러나 컴퓨팅 최적화 애플리케이션은 고성능 웹 서버, 컴퓨팅 집약적인 애플리케이션 서버 및 전용 게임 서버에 이상적이라는 차이점이 있습니다. 또한 단일 그룹에서 많은 트랜잭션을 처리해야 하는 일괄 처리 워크로드에도 컴퓨팅 최적화 인스턴스를 사용할 수 있습니다.

메모리 최적화 인스턴스

메모리최적화 인스턴스는 메모리에서 대규모 데이터 세트를 처리하는 워크로드에 빠른 성능을 제공하도록 설계되었습니다. 컴퓨팅에서 메모리는 임시 저장 영역입니다. 메모리는 중앙 처리 장치(CPU)가 작업을 완료하는 데 필요한 모든 데이터와 명령을 저장합니다. 컴퓨터 프로그램이나 애플리케이션을 실행하기 전에 스토리지에서 메모리로 로드됩니다. 이 사전 로드 프로세스를 통해 CPU는 컴퓨터 프로그램에 직접 액세스할 수 있습니다.

애플리케이션을 실행하기 전에 대량의 데이터를 미리 로드해야 하는 워크로드가 있다고 가정해 보겠습니다. 이 시나리오는 고성능 데이터베이스 또는 대량의 비정형 데이터를 실시간으로 처리하는 워크로드일 수 있습니다. 이러한 유형의 사용 사례에서는 메모리 최적화 인스턴스 사용을 고려하세요. 메모리 최적화 인스턴스를 사용하면 메모리를 많이 필요로 하는 워크로드를 실행하고 뛰어난 성능을 얻을 수 있습니다.

가속 컴퓨팅 인스턴스

가속 컴퓨팅 인스턴스는 하드웨어 가속기 또는 코프로세서를 사용하여 CPU에서 실행되는 소프트웨어에서 가능한 것보다 더 효율적으로 일부 기능을 수행합니다. 이러한 기능의 예로는 부동 소수점 숫자 계산, 그래픽 처리, 데이터 패턴 일치 등이 있습니다.

컴퓨팅에서 하드웨어 가속기는 데이터 처리 속도를 높일 수 있는 구성 요소입니다. 가속 컴퓨팅 인스턴스는 그래픽 애플리케이션, 게임 스트리밍, 애플리케이션 스트리밍과 같은 워크로드에 이상적입니다.

스토리지 최적화 인스턴스

스토리지 최적화 인스턴스는 로컬 스토리지의 대용량 데이터 세트에 대한 순차적인 읽기 및 쓰기 액세스가 필요한 워크로드를 위해 설계되었습니다. 스토리지 최적화 인스턴스에 적합한 워크로드의 예로는 분산 파일 시스템, 데이터 웨어하우징 애플리케이션, 빈도가 높은 온라인 트랜잭션 처리(OLTP) 시스템 등이 있습니다.

컴퓨팅에서 초당 입출력 작업 수(IOPS)라는 용어는 스토리지 장치의 성능을 측정하는 지표입니다. 이는 장치가 1초 동안 수행할 수 있는 다양한 입력 또는 출력 작업의 수를 나타냅니다. 스토리지에 최적화된 인스턴스는 애플리케이션에 수만 개의 낮은 지연 시간, 랜덤 IOPS를 제공하도록 설계되었습니다.

입력 작업은 데이터베이스에 입력된 레코드와 같이 시스템에 입력되는 데이터로 생각할 수 있습니다. 출력 작업은 서버에서 생성된 데이터입니다. 출력의 예로는 데이터베이스의 레코드에 대해 수행되는 분석을 들 수 있습니다. IOPS 요구 사항이 높은 애플리케이션이 있는 경우 스토리지에 최적화된 인스턴스가 이러한 종류의 사용 사례에 최적화되지 않은 다른 인스턴스 유형에 비해 더 나은 성능을 제공할 수 있습니다.

Amazon EC2 가격

Amazon EC2를 사용하면 사용한 컴퓨팅 시간에 대해서만 비용을 지불하면 됩니다. Amazon EC2는 다양한 사용 사례에 맞는 다양한 가격 옵션을 제공합니다. 예를 들어, 사용 사례에서 중단을 견딜 수 있는 경우 스팟 인스턴스를 사용하여 비용을 절약할 수 있습니다. 또한 예약 인스턴스를 통해 조기에 커밋하고 최소 사용 수준을 고정하여 비용을 절감할 수도 있습니다.

온디맨드

온디맨드 인스턴스는 중단할 수 없는 단기간의 불규칙한 워크로드에 이상적입니다. 선불 비용이나 최소 계약이 적용되지 않습니다. 인스턴스는 사용자가 중지할 때까지 계속 실행되며, 사용한 컴퓨팅 시간만큼만 비용을 지불하면 됩니다. 온디맨드 인스턴스의 샘플 사용 사례에는 애플리케이션 개발 및 테스트, 예측할 수 없는 사용 패턴을 가진 애플리케이션 실행 등이 있습니다. 온디맨드 인스턴스는 1년 이상 지속되는 워크로드에는 권장되지 않습니다. 이러한 워크로드는 예약 인스턴스를 사용하면 비용을 더 많이 절감할 수 있기 때문입니다.

Amazon EC2 절약 요금제

AWS는 Amazon EC2를 비롯한 여러 컴퓨팅 서비스에 대한 절약 플랜을 제공합니다.Amazon EC2 절약 플랜을 사용하면 1년 또는 3년 동안 일정한 양의 컴퓨팅 사용량을 약정하여 컴퓨팅 비용을 절감할 수 있습니다. 이 기간 약정을 통해 온디맨드 비용보다 최대 72%까지 절감할 수 있습니다.

약정까지의 사용량은 할인된 절약 요금제 요율(예: 시간당 $10)로 청구됩니다. 약정을 초과하는 사용량은 일반 온디맨드 요금으로 청구됩니다.

절약형 요금제 옵션을 고려 중인 경우, AWS 비용 탐색기를 통해 지난 7일, 30일 또는 60일 동안의 Amazon EC2 사용량을 분석할 수 있습니다. 또한 AWS 비용 탐색기는 절약 요금제에 대한 맞춤형 권장 사항도 제공합니다. 이러한 권장 사항은 이전 Amazon EC2 사용량과 1년 또는 3년 저축 플랜의 시간당 약정 금액을 기반으로 월별 Amazon EC2 비용을 얼마나 절약할 수 있는지 추정합니다.

예약 인스턴스

예약 인스턴스는 계정의 온디맨드 인스턴스 사용에 적용되는 청구 할인입니다. 1년 또는 3년 기간의 표준 예약 및 전환 예약 인스턴스와 1년 기간의 예약 예약 인스턴스를 구매할 수 있습니다. 3년 옵션을 사용하면 더 큰 비용 절감 효과를 얻을 수 있습니다.

예약 인스턴스 기간이 끝나면 중단 없이 Amazon EC2 인스턴스를 계속 사용할 수 있습니다. 그러나 다음 중 하나를 수행할 때까지 주문형 요금이 청구됩니다:

인스턴스를 종료합니다.
인스턴스 속성(인스턴스 유형, 리전, 테넌시 및 플랫폼)과 일치하는 새 예약 인스턴스를 구매합니다.

스팟 인스턴스

스팟 인스턴스는 시작 및 종료 시간이 유연하거나 중단을 견딜 수 있는 워크로드에 이상적입니다. 스팟 인스턴스는 사용하지 않는 Amazon EC2 컴퓨팅 용량을 사용하며 온디맨드 가격에서 최대 90% 할인된 가격으로 비용을 절감할 수 있습니다. 필요에 따라 시작 및 중지할 수 있는 백그라운드 처리 작업(예: 고객 설문 조사를 위한 데이터 처리 작업)이 있다고 가정해 보겠습니다. 비즈니스의 전체 운영에 영향을 주지 않고 처리 작업을 시작 및 중지하려고 합니다. 스팟 요청을 하고 Amazon EC2 용량을 사용할 수 있는 경우, 스팟 인스턴스가 시작됩니다. 그러나 스팟 요청을 했는데 Amazon EC2 용량을 사용할 수 없는 경우, 용량을 사용할 수 있을 때까지 요청이 성공하지 못합니다. 사용할 수 없는 용량으로 인해 백그라운드 처리 작업의 시작이 지연될 수 있습니다. 스팟 인스턴스를 시작한 후 용량을 더 이상 사용할 수 없거나 스팟 인스턴스에 대한 수요가 증가하면 인스턴스가 중단될 수 있습니다. 이 경우 백그라운드 처리 작업에는 문제가 발생하지 않을 수 있습니다. 그러나 애플리케이션 개발 및 테스트의 앞선 예에서는 예기치 않은 중단을 피하고 싶을 가능성이 높습니다. 따라서 이러한 작업에 적합한 다른 EC2 인스턴스 유형을 선택하세요.

전용 호스트

전용호스트는사용 전용으로 완전히 전용화된 Amazon EC2 인스턴스 용량을 갖춘 물리적 서버입니다.

기존의 소켓당, 코어당 또는 VM당 소프트웨어 라이선스를 사용하여 라이선스 규정 준수를 유지할 수 있습니다. 온디맨드 전용 호스트 및 전용 호스트 예약을 구매할 수 있습니다. 모든 Amazon EC2 옵션 중에서 전용 호스트가 가장 비쌉니다.

#1. Amazon EC2 확장하기

확장성

확장성은 필요한 리소스로만 시작하여 스케일 아웃 또는 스케일 인을 통해 변화하는 수요에 자동으로 대응하도록 아키텍처를 설계하는 것을 포함합니다. 결과적으로 사용한 리소스에 대해서만 비용을 지불합니다. 고객의 요구를 충족하기 위한 컴퓨팅 용량 부족에 대해 걱정할 필요가 없습니다.

확장 프로세스가 자동으로 수행되기를 원한다면 어떤 AWS 서비스를 사용하시겠습니까? Amazon EC2 인스턴스에 이 기능을 제공하는 AWS 서비스는Amazon EC2 자동 확장입니다.

Amazon EC2 자동 확장

로딩이 되지 않고 자주 시간 초과되는 웹사이트에 접속하려고 시도한 적이 있다면 웹사이트가 처리할 수 있는 것보다 많은 요청을 받았을 수 있습니다. 이 상황은 바리스타가 한 명밖에 없는 커피숍에서 고객의 주문을 받기 위해 긴 줄을 서서 기다리는 것과 비슷합니다.

Amazon EC2 자동 확장을 사용하면 변화하는 애플리케이션 수요에 대응하여 Amazon EC2 인스턴스를 자동으로 추가하거나 제거할 수 있습니다. 필요에 따라 인스턴스를 자동으로 확장 및 축소함으로써 애플리케이션 가용성을 더욱 안정적으로 유지할 수 있습니다.

Amazon EC2 자동 확장에서는 동적 확장과 예측 확장이라는 두 가지 접근 방식을 사용할 수 있습니다.

동적 확장은 변화하는 수요에 대응합니다.
예측확장은 예측된 수요에 따라 적절한 수의 Amazon EC2 인스턴스를 자동으로 스케줄링합니다.

#2 Amazon EC2 확장하기

클라우드에서 컴퓨팅 성능은 프로그래밍 리소스이므로 확장 문제에 대해 보다 유연한 접근 방식을 취할 수 있습니다. 애플리케이션에 Amazon EC2 자동 확장을 추가하면 필요할 때 애플리케이션에 새 인스턴스를 추가하고 더 이상 필요하지 않을 때 종료할 수 있습니다.

Amazon EC2 인스턴스에서 애플리케이션을 시작할 준비를 하고 있다고 가정해 보겠습니다. 자동 확장 그룹의 크기를 구성할 때 최소 Amazon EC2 인스턴스 수를 1개로 설정할 수 있습니다. 즉, 항상 하나 이상의 Amazon EC2 인스턴스가 실행 중이어야 합니다.

자동 확장 그룹을 생성할 때 최소 Amazon EC2 인스턴스 수를 설정할 수 있습니다.최소 용량은 자동 확장 그룹을 생성한 후 즉시 시작되는 Amazon EC2 인스턴스 수입니다. 이 예제에서 자동 확장 그룹의 최소 용량은 Amazon EC2 인스턴스 1개입니다.

다음으로 애플리케이션을 실행하는 데 최소 하나의 Amazon EC2 인스턴스가 필요하지만원하는 용량을 Amazon EC2 인스턴스 2개로 설정할 수 있습니다.

참고: 자동 확장 그룹에서 원하는 Amazon EC2 인스턴스 수를 지정하지 않으면 원하는 용량이 최소 용량으로 기본 설정됩니다.

자동 스케일링 그룹에서 설정할 수 있는 세 번째 구성은최대 용량입니다. 예를 들어, 수요 증가에 대응하여 스케일 아웃하도록 자동 확장 그룹을 구성할 수 있지만 최대 4개의 Amazon EC2 인스턴스까지만 확장할 수 있습니다.

Amazon EC2 자동 확장은 Amazon EC2 인스턴스를 사용하기 때문에 사용한 인스턴스에 대해서만 비용을 지불합니다.

탄력적 로드 밸런서

Elastic Load Balancing은 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스와 같은 여러 리소스에 자동으로 분산하는 AWS 서비스입니다.

로드 밸런서는 자동 확장 그룹으로 들어오는 모든 웹 트래픽에 대한 단일 접점 역할을 합니다. 즉, 들어오는 트래픽의 양에 따라 Amazon EC2 인스턴스를 추가하거나 제거할 때 이러한 요청은 먼저 로드 밸런서로 라우팅됩니다. 그런 다음 요청은 요청을 처리할 여러 리소스로 분산됩니다. 예를 들어, Amazon EC2 인스턴스가 여러 개 있는 경우, Elastic Load Balancing은 워크로드를 여러 인스턴스에 분산하여 단일 인스턴스가 대부분의 워크로드를 처리하지 않도록 합니다.

Elastic Load Balancing과 Amazon EC2 자동 확장은 별도의 서비스이지만, 함께 작동하여 Amazon EC2에서 실행되는 애플리케이션이 높은 성능과 가용성을 제공할 수 있도록 도와줍니다.

예시: 탄력적 부하 분산

수요가 적은 기간

다음은 Elastic Load Balancing이 어떻게 작동하는지에 대한 예시입니다. 몇 명의 고객이 커피숍에 와서 주문을 할 준비가 되었다고 가정해 보겠습니다.

계산대가 몇 개만 열려 있다면 이는 서비스를 필요로 하는 고객의 수요와 일치합니다. 커피숍에 손님이 없는 계산대가 열려 있을 가능성은 적습니다. 이 예제에서는 계산대를 Amazon EC2 인스턴스로 생각할 수 있습니다

수요가 많은 기간

하루 종일 고객 수가 증가함에 따라 커피숍은 고객을 수용하기 위해 더 많은 계산대를 엽니다. 다이어그램에서 자동 확장 그룹은 이를 나타냅니다.

또한 커피숍 직원이 고객을 가장 적합한 계산대로 안내하여 요청 수가 열려 있는 계산대 전체에 고르게 분산될 수 있도록 합니다. 이 커피숍 직원을 로드 밸런서라고 생각할 수 있습니다.

모놀리식 애플리케이션 및 마이크로서비스

모놀리식 애플리케이션

애플리케이션은 여러 구성 요소로 이루어져 있습니다. 구성 요소는 서로 통신하여 데이터를 전송하고 요청을 처리하며 애플리케이션을 계속 실행합니다.

컴포넌트가 긴밀하게 결합된 애플리케이션이 있다고 가정해 봅시다. 이러한 구성 요소에는 데이터베이스, 서버, 사용자 인터페이스, 비즈니스 로직 등이 포함될 수 있습니다. 이러한 유형의 아키텍처는모놀리식 애플리케이션으로 간주할 수 있습니다.

이러한 애플리케이션 아키텍처 접근 방식에서는 단일 구성 요소에 장애가 발생하면 다른 구성 요소도 장애를 일으키고 전체 애플리케이션이 장애를 일으킬 수 있습니다.

마이크로서비스

단일 구성 요소에 장애가 발생했을 때 애플리케이션 가용성을 유지하기 위해마이크로서비스 접근 방식을 통해 애플리케이션을 설계할 수 있습니다.

마이크로서비스 접근 방식에서는 애플리케이션 구성 요소가 느슨하게 결합됩니다. 이 경우 단일 구성 요소에 장애가 발생해도 다른 구성 요소는 서로 통신하기 때문에 계속 작동합니다. 느슨한 결합은 전체 애플리케이션이 실패하는 것을 방지합니다.

AWS에서 애플리케이션을 설계할 때는 서로 다른 기능을 수행하는 서비스 및 구성 요소를 사용하여 마이크로서비스 접근 방식을 취할 수 있습니다. 두 가지 서비스가 애플리케이션 통합을 용이하게 합니다: Amazon SNS(Amazon Simple Notification Service)와 Amazon SQS(Amazon Simple Queue Service)입니다.

아마존 간편 알림 서비스(아마존 SNS)

Amazon 단순 알림 서비스(Amazon SNS)는 게시/구독 서비스입니다. 게시자는 Amazon SNS 토픽을 사용하여 구독자에게 메시지를 게시합니다. 이는 커피숍에서 계산원이 음료를 만드는 바리스타에게 커피 주문을 제공하는 것과 유사합니다.

Amazon SNS에서 구독자는 웹 서버, 이메일 주소, AWS 람다 함수 또는 기타 여러 옵션이 될 수 있습니다.

단일 주제에서 업데이트 게시

커피숍에 비즈니스의 모든 영역에 대한 업데이트가 포함된 단일 뉴스레터가 있다고 가정해 보겠습니다. 여기에는 쿠폰, 커피 상식, 신제품 등의 주제가 포함됩니다. 이 모든 주제는 단일 뉴스레터이므로 그룹화되어 있습니다. 뉴스레터를 구독하는 모든 고객은 쿠폰, 커피 퀴즈, 신제품에 대한 업데이트를 받게 됩니다.

얼마 후 일부 고객은 관심 있는 특정 주제에 대해서만 별도의 뉴스레터를 받고 싶다는 의사를 표시합니다. 커피숍 소유주는 이 방법을 시도하기로 결정합니다.

여러 주제의 업데이트 게시

이제 이 커피숍은 모든 주제에 대한 단일 뉴스레터 대신 세 개의 개별 뉴스레터로 나누었습니다. 각 뉴스레터는 쿠폰, 커피 관련 퀴즈, 신제품 등 특정 주제를 다루고 있습니다.

이제 구독자는 자신이 구독한 특정 주제에 대한 업데이트만 즉시 받게 됩니다.

구독자는 단일 주제 또는 여러 주제를 구독할 수 있습니다. 예를 들어 첫 번째 고객은 쿠폰 주제만 구독하고, 두 번째 고객은 커피 퀴즈 주제만 구독하는 식입니다. 세 번째 고객은 커피 퀴즈와 신제품 주제를 모두 구독합니다.

아마존 단순 대기열 서비스(Amazon SQS)

AmazonSQS(Amazon Simple Queue Service)는 메시지 큐 서비스입니다.

Amazon SQS를 사용하면 메시지가 손실되거나 다른 서비스를 사용할 수 없어도 소프트웨어 구성 요소 간에 메시지를 보내고, 저장하고, 받을 수 있습니다. Amazon SQS에서 애플리케이션은 메시지를 큐로 보냅니다. 사용자 또는 서비스가 대기열에서 메시지를 검색하여 처리한 다음 대기열에서 삭제합니다.

예시: 주문 처리

커피숍에서 계산원이 주문을 받고 바리스타가 주문을 만드는 주문 프로세스가 있다고 가정해 보겠습니다. 계산원과 바리스타를 애플리케이션의 두 가지 개별 구성 요소로 생각하면 됩니다.

먼저 계산원이 주문을 받아 종이에 적습니다. 다음으로 계산원이 바리스타에게 종이를 전달합니다. 마지막으로 바리스타가 음료를 만들어 고객에게 제공합니다.

다음 주문이 들어오면 이 과정이 반복됩니다. 이 과정은 계산원과 바리스타가 서로 협력하는 한 원활하게 진행됩니다.

만약 계산원이 주문을 받아 바리스타에게 전달하러 갔는데 바리스타가 휴식 중이거나 다른 주문으로 바쁘다면 어떻게 될까요? 계산원은 바리스타가 주문을 받을 준비가 될 때까지 기다려야 합니다. 이렇게 되면 주문 프로세스가 지연되고 고객은 주문을 받기까지 더 오래 기다려야 합니다.

커피숍의 인기가 높아지고 주문 라인이 더 느리게 움직이면서 점주는 현재 주문 프로세스가 시간이 많이 걸리고 비효율적이라는 것을 알게 됩니다. 그래서 대기열을 사용하는 다른 접근 방식을 시도하기로 결정합니다.

예시: 대기열에 있는 주문

계산원과 바리스타는 애플리케이션의 두 가지 개별 구성 요소라는 점을 기억하세요. Amazon SQS와 같은 메시지 큐 서비스를 사용하면 분리된 애플리케이션 구성 요소 간에 메시지를 주고받을 수 있습니다.

이 예에서 프로세스의 첫 번째 단계는 이전과 동일하게 고객이 계산원에게 주문을 하는 것입니다.

계산원이 주문을 대기열에 넣습니다. 이를 계산원과 바리스타 사이의 완충 역할을 하는 주문 보드라고 생각하면 됩니다. 바리스타가 휴식 중이거나 다른 주문으로 바쁘더라도 계산원은 대기열에 새 주문을 계속 넣을 수 있습니다.

그런 다음 바리스타가 대기열을 확인하고 주문을 가져옵니다.

바리스타가 음료를 준비하여 고객에게 제공합니다.

그런 다음 바리스타는 완료된 주문을 대기열에서 제거합니다.

바리스타가 음료를 준비하는 동안 계산원은 계속해서 새 주문을 받아 대기열에 추가할 수 있습니다.

서버리스 컴퓨팅

이 모듈의 앞부분에서는 클라우드에서 가상 서버를 실행할 수 있는 서비스인 Amazon EC2에 대해 배웠습니다. Amazon EC2에서 실행하려는 애플리케이션이 있는 경우 다음을 수행해야 합니다:

인스턴스(가상 서버)를 프로비저닝합니다.
코드를 업로드합니다.
애플리케이션이 실행되는 동안 인스턴스를 계속 관리합니다.

"서버리스"라는 용어는 코드가 서버에서 실행되지만 이러한 서버를 프로비저닝하거나 관리할 필요가 없음을 의미합니다. 서버리스 컴퓨팅을 사용하면 서버를 유지 관리하는 대신 새로운 제품과 기능을 혁신하는 데 더 집중할 수 있습니다.

서버리스 컴퓨팅의 또 다른 장점은 서버리스 애플리케이션을 자동으로 확장할 수 있는 유연성입니다. 서버리스 컴퓨팅은 처리량 및 메모리와 같은 소비 단위를 수정하여 애플리케이션의 용량을 조정할 수 있습니다.

서버리스 컴퓨팅을 위한 AWS 서비스로는AWS Lambda가 있습니다.

AWS 람다

AWS Lambda는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있는 서비스입니다.

AWS Lambda를 사용하는 동안에는 사용한 컴퓨팅 시간만큼만 비용을 지불하면 됩니다. 요금은 코드가 실행 중인 경우에만 적용됩니다. 또한 거의 모든 유형의 애플리케이션 또는 백엔드 서비스에 대한 코드를 관리 없이 실행할 수 있습니다.

예를 들어, 간단한 람다 함수는 업로드된 이미지의 크기를 AWS 클라우드에 자동으로 조정하는 기능을 포함할 수 있습니다. 이 경우 새 이미지를 업로드할 때 함수가 트리거됩니다.

AWS Lambda의 작동 방식

Lambda에 코드를 업로드합니다.
AWS 서비스, 모바일 애플리케이션 또는 HTTP 엔드포인트와 같은 이벤트 소스에서 트리거되도록 코드를 설정합니다.
Lambda는 트리거될 때만 코드를 실행합니다.
사용한 컴퓨팅 시간에 대해서만 비용을 지불합니다. 이미지 크기 조정의 이전 예제에서는 새 이미지를 업로드할 때 사용한 컴퓨팅 시간에 대해서만 비용을 지불합니다. 이미지를 업로드하면 Lambda가 이미지 크기 조정 기능을 위한 코드를 실행합니다.

컨테이너

AWS에서는컨테이너화된 애플리케이션을 빌드하고 실행할 수도 있습니다.

컨테이너는 애플리케이션의 코드와 종속성을 단일 객체로 패키징하는 표준 방법을 제공합니다. 또한 보안, 안정성 및 확장성에 대한 필수 요구 사항이 있는 프로세스 및 워크플로우에 컨테이너를 사용할 수도 있습니다.

예시

여러 컨테이너가 있는 하나의 호스트

회사의 애플리케이션 개발자가 자신의 컴퓨터에 IT 운영 담당자가 사용하는 컴퓨터의 환경과 다른 환경을 가지고 있다고 가정해 보세요. 개발자는 배포에 관계없이 애플리케이션의 환경이 일관되게 유지되기를 원하므로 컨테이너화된 접근 방식을 사용합니다. 이렇게 하면 애플리케이션을 디버깅하고 컴퓨팅 환경의 차이를 진단하는 데 소요되는 시간을 줄일 수 있습니다.

수백 개의 컨테이너가 있는 수십 개의 호스트

컨테이너화된 애플리케이션을 실행할 때는 확장성을 고려하는 것이 중요합니다. 여러 개의 컨테이너가 있는 단일 호스트 대신 수백 개의 컨테이너가 있는 수십 개의 호스트를 관리해야 한다고 가정해 보세요. 또는 수천 개의 컨테이너로 수백 개의 호스트를 관리해야 한다고 가정해 보세요. 대규모로 메모리 사용량, 보안, 로깅 등을 모니터링하는 데 얼마나 많은 시간이 소요될지 상상해 보세요.

Amazon Elastic Container Service(Amazon ECS)는 확장성이 뛰어난 고성능 컨테이너 관리 시스템으로, AWS에서 컨테이너화된 애플리케이션을 실행하고 확장할 수 있도록 지원합니다.

Amazon ECS는 Docker 컨테이너를 지원합니다.Docker는 애플리케이션을 신속하게 빌드, 테스트 및 배포할 수 있는 소프트웨어 플랫폼입니다. AWS는 오픈 소스 Docker 커뮤니티 에디션과 구독 기반 Docker 엔터프라이즈 에디션의 사용을 지원합니다. Amazon ECS를 사용하면 API 호출을 사용하여 Docker 지원 애플리케이션을 시작하고 중지할 수 있습니다.

AWS CLF-02 #1 상세 정리

ReinaMoon — Sun, 10 Aug 2025 06:07:53 +0900

클라이언트-서버 모델이란 무엇인가요?

컴퓨팅에서 클라이언트는 사람이 컴퓨터 서버에 요청을 하기 위해 상호 작용하는 웹 브라우저 또는 데스크톱 애플리케이션일 수 있습니다.서버는 가상 서버의 일종인 Amazon EC2(Amazon Elastic Compute Cloud)와 같은 서비스일 수 있습니다.

예를 들어 클라이언트가 뉴스 기사, 온라인 게임의 점수 또는 재미있는 동영상을 요청한다고 가정해 보겠습니다. 서버는 이 요청의 세부 사항을 평가하고 정보를 클라이언트에 반환하여 요청을 이행합니다.

클라우드 컴퓨팅을 위한 배포 모델

클라우드 전략을 선택할 때 기업은 필요한 클라우드 애플리케이션 구성 요소, 선호하는 리소스 관리 도구, 레거시 IT 인프라 요구 사항 등의 요소를 고려해야 합니다.

클라우드 컴퓨팅 배포 모델에는 클라우드 기반, 온프레미스, 하이브리드의 세 가지가 있습니다.

클라우드 기반 배포

애플리케이션의 모든 부분을 클라우드에서 실행합니다.
기존 애플리케이션을 클라우드로 마이그레이션합니다.
클라우드에서 새 애플리케이션을 설계하고 빌드합니다.

클라우드 기반 배포 모델에서는 기존 애플리케이션을 클라우드로 마이그레이션하거나 클라우드에서 새 애플리케이션을 설계 및 빌드할 수 있습니다. IT 직원이 관리해야 하는 낮은 수준의 인프라에서 이러한 애플리케이션을 빌드할 수 있습니다. 또는 핵심 인프라의 관리, 아키텍처 및 확장 요구 사항을 줄여주는 상위 수준 서비스를 사용하여 구축할 수도 있습니다.

예를 들어, 회사에서 클라우드에 완전히 기반한 가상 서버, 데이터베이스 및 네트워킹 구성 요소로 구성된 애플리케이션을 만들 수 있습니다.

온프레미스 배포

가상화 및 리소스 관리 도구를 사용하여 리소스를 배포하세요.
애플리케이션 관리 및 가상화 기술을 사용하여 리소스 활용도를 높일 수 있습니다.

온프레미스 배포는프라이빗 클라우드 배포라고도 합니다. 이 모델에서는 가상화 및 리소스 관리 도구를 사용하여 리소스를 온프레미스에 배포합니다. 예를 들어, 온프레미스 데이터 센터에 완전히 보관된 기술에서 실행되는 애플리케이션이 있을 수 있습니다. 이 모델은 레거시 IT 인프라와 매우 유사하지만 애플리케이션 관리 및 가상화 기술을 통합하여 리소스 활용도를 높이는 데 도움이 됩니다.

하이브리드 배포

클라우드 기반 리소스를 온프레미스 인프라에 연결하세요.
클라우드 기반 리소스를 레거시 IT 애플리케이션과 통합하세요.

하이브리드 배포에서는 클라우드 기반 리소스가 온프레미스 인프라에 연결됩니다. 이 접근 방식은 여러 상황에서 사용할 수 있습니다. 예를 들어, 온프레미스에서 더 잘 유지 관리되는 레거시 애플리케이션이 있거나 정부 규정에 따라 비즈니스에서 특정 기록을 온프레미스에 보관해야 하는 경우입니다.

예를 들어, 한 회사에서 일괄 데이터 처리 및 분석을 자동화할 수 있는 클라우드 서비스를 사용하고자 한다고 가정해 보겠습니다. 하지만 이 회사에는 온프레미스에 더 적합하고 클라우드로 마이그레이션하지 않을 레거시 애플리케이션이 몇 개 있습니다. 하이브리드 배포를 통해 이 회사는 레거시 애플리케이션을 온프레미스에 유지하면서 클라우드에서 실행되는 데이터 및 분석 서비스의 이점을 누릴 수 있습니다.

클라우드 컴퓨팅의 이점

기업이 비즈니스 요구 사항을 해결할 때 특정 클라우드 컴퓨팅 접근 방식을 선택하는 이유를 고려하세요.

선불 비용과 변동 비용의 교환

초기 비용은 데이터 센터, 물리적 서버 및 기타 리소스를 사용하기 전에 투자해야 하는 비용을 말합니다. 변동 비용은 사용 방법을 알기 전에 데이터 센터와 서버에 막대한 비용을 투자하는 대신 사용한 컴퓨팅 리소스에 대해서만 비용을 지불하는 것을 의미합니다.

변동 비용의 이점을 제공하는 클라우드 컴퓨팅 접근 방식을 채택함으로써 기업은 비용을 절감하면서 혁신적인 솔루션을 구현할 수 있습니다.

데이터센터 운영 및 유지에 드는 비용 지출 중단

데이터 센터에서 컴퓨팅하려면 인프라와 서버 관리에 더 많은 비용과 시간을 투자해야 하는 경우가 많습니다. 클라우드 컴퓨팅의 이점은 이러한 작업에 덜 집중하고 애플리케이션과 고객에 더 집중할 수 있다는 것입니다.

용량 추측 중단

클라우드 컴퓨팅을 사용하면 애플리케이션을 배포하기 전에 필요한 인프라 용량을 예측할 필요가 없습니다. 예를 들어, 필요할 때 Amazon EC2 인스턴스를 시작하고 사용한 컴퓨팅 시간에 대해서만 비용을 지불할 수 있습니다. 사용하지 않은 리소스에 대한 비용을 지불하거나 제한된 용량에 대처할 필요 없이 필요한 용량만 액세스할 수 있습니다. 또한 수요에 따라 스케일 인 또는 스케일 아웃할 수도 있습니다.

대규모 규모의 경제를 통한 이점

클라우드 컴퓨팅을 사용하면 자체적으로 사용할 때보다 낮은 변동 비용을 달성할 수 있습니다. 수십만 고객의 사용량을 클라우드에 모을 수 있으므로 AWS와 같은 제공업체는 더 높은 규모의 경제를 달성할 수 있습니다. 규모의 경제는 종량제 가격 인하로 이어집니다.

속도와 민첩성 향상

클라우드 컴퓨팅의 유연성 덕분에 애플리케이션 개발 및 배포가 더 쉬워집니다.

이러한 유연성은 실험과 혁신에 더 많은 시간을 할애할 수 있게 해줍니다. 데이터 센터에서 컴퓨팅할 경우 필요한 새로운 리소스를 확보하는 데 몇 주가 걸릴 수 있습니다. 이에 비해 클라우드 컴퓨팅을 사용하면 몇 분 안에 새로운 리소스에 액세스할 수 있습니다.

몇 분 안에 글로벌 진출

AWS 클라우드의 글로벌 풋프린트를 통해 전 세계 고객에게 애플리케이션을 신속하게 배포하는 동시에 짧은 지연 시간을 제공할 수 있습니다. 즉, 귀사가 고객과 전 세계 다른 지역에 있더라도 고객은 최소한의 지연으로 애플리케이션에 액세스할 수 있습니다.

AWS CLF-02 시험 요약 - #1

ReinaMoon — Sun, 10 Aug 2025 05:59:37 +0900

1. 클라우드 개념 및 아키텍처 원칙

글로벌 인프라
- 리전(Region): 물리적으로 분리된 지리적 영역. 각 리전은 2개 이상의 가용 영역(AZ)으로 구성됨.
- 가용 영역(Availability Zone): 리전 내의 데이터 센터. 전원, 냉각, 네트워크가 독립되어 있음. 고가용성(HA)을 위해 여러 AZ에 리소스를 배포함.
- 엣지 로케이션(Edge Location): Amazon CloudFront(CDN)가 사용자와 가까운 곳에 콘텐츠(비디오, 사진, 웹페이지 등)를 캐시하여 전송 속도를 높이는 위치.
AWS Well-Architected Framework (반드시 암기!)
- 운영 우수성 (Operational Excellence)
- 보안 (Security)
- 신뢰성 (Reliability)
- 성능 효율성 (Performance Efficiency)
- 비용 최적화 (Cost Optimization)
- 지속 가능성 (Sustainability)

PART 2. 네트워킹 및 콘텐츠 전송 (연결의 모든 것)

서비스	핵심 기능 및 역할
Amazon VPC (Virtual Private Cloud)	AWS 클라우드 내의 논리적으로 격리된 나만의 가상 네트워크. IP 주소 범위, 서브넷, 라우팅 테이블, 게이트웨이 등을 직접 제어.
서브넷 (Subnet)	VPC 내부의 IP 주소 범위. 퍼블릭 서브넷(인터넷과 통신 가능)과 프라이빗 서브넷(내부 통신만 가능)으로 나뉨.
인터넷 게이트웨이 (IGW)	VPC와 인터넷 간의 통신을 가능하게 하는 구성 요소.
AWS Direct Connect	데이터 센터와 AWS 간에 전용 프라이빗 회선을 구축하여 안정적이고 빠른 네트워크를 제공. (VPN이 아님!)
Amazon Route 53	가용성이 높은 DNS(도메인 이름 시스템) 서비스. 도메인 이름을 IP 주소로 변환.
Amazon CloudFront	CDN 서비스. 전 세계 엣지 로케이션에 콘텐츠를 캐시하여 사용자에게 낮은 지연 시간으로 제공.

★ 시험 단골 비교: 보안 그룹 vs. 네트워크 ACL (NACL)

구분	보안 그룹 (Security Group)	네트워크 ACL (NACL)
적용 단위	인스턴스 수준 (EC2의 가상 방화벽)	서브넷 수준 (서브넷의 출입문)
상태	Stateful (상태 저장): 허용한 인바운드 요청의 응답은 자동으로 허용.	Stateless (상태 비저장): 인바운드와 아웃바운드 규칙을 각각 설정해야 함.
기본 규칙	모든 인바운드 거부, 모든 아웃바운드 허용.	모든 인/아웃바운드 허용.

PART 3. 스토리지 (데이터 저장의 모든 방법)

★ 시험 단골 비교: S3 vs. EBS vs. EFS

구분	Amazon S3 (객체 스토리지)	Amazon EBS (블록 스토리지)	Amazon EFS (파일 스토리지)
개념	무한 용량의 인터넷 웹하드	EC2 전용 외장 하드 드라이브	여러 EC2가 공유하는 네트워크 폴더 (NAS)
접속	인터넷 (HTTP/HTTPS)	하나의 EC2에만 연결 (동일 AZ 내)	여러 EC2에서 동시 접속 (리전 내 여러 AZ)
수정 방식	파일 전체를 다시 업로드	파일의 특정 부분만 수정 가능	파일의 특정 부분만 수정 가능
주요 용도	이미지/동영상 저장, 백업, 정적 웹 호스팅	EC2의 부팅 디스크, 데이터베이스 스토리지	웹 서버 콘텐츠 공유, 중앙 파일 저장소

Amazon S3 (Simple Storage Service)
- 객체(Object): 파일(데이터)과 메타데이터로 구성. 최대 크기 5TB.
- S3 스토리지 클래스 (비용 최적화를 위해 비교 필수!)
  - S3 Standard: 자주 액세스하는 데이터용. 최고의 성능과 가용성 (최소 3개 AZ에 저장).
  - S3 Standard-IA (Infrequent Access): 자주 액세스하지 않지만 필요할 때 빠르게 꺼내야 하는 데이터용. 저장 비용은 저렴, 검색 비용은 비쌈.
  - S3 Intelligent-Tiering: 액세스 패턴을 알 수 없을 때 사용. AWS가 자동으로 데이터를 비용 효율적인 계층으로 이동시켜 줌.
  - S3 Glacier Instant Retrieval: 수 밀리초 내 검색이 필요한 아카이브 데이터용. (빠른 아카이브)
  - S3 Glacier Flexible Retrieval: 몇 분 ~ 몇 시간 내 검색이 가능한 저비용 아카이브. (일반 아카이브)
  - S3 Glacier Deep Archive: 12시간 이내 검색. 가장 저렴한 아카이브 스토리지. (장기 보관용)
Amazon EBS (Elastic Block Store)
- EC2 인스턴스의 하드 디스크. EC2와 EBS는 반드시 같은 가용 영역(AZ)에 있어야 함.
- EBS 스냅샷: EBS 볼륨을 특정 시점으로 S3에 백업하는 기능. 첫 스냅샷은 전체 복사, 이후에는 변경된 부분만 저장(증분 백업).

PART 4. 데이터베이스 (데이터 관리의 목적별 선택)

★ 시험 단골 비교: RDS vs. DynamoDB

구분	Amazon RDS (관계형)	Amazon DynamoDB (NoSQL)
데이터 구조	테이블, 행, 열 (엄격한 스키마)	Key-Value, 문서 (유연한 스키마)
핵심 기능	SQL, 복잡한 쿼리, JOIN, 트랜잭션	초고속(한 자릿수 ms 응답), 자동 확장
관리	AWS가 패치, 백업 등 관리 (관리형 서비스)	서버리스 (서버 관리 전혀 필요 없음)
주요 용도	일반적인 웹 앱, 전자상거래	게임 랭킹, 쇼핑 카트, 실시간 대규모 앱

관계형 데이터베이스
- Amazon RDS: 관리형 관계형 데이터베이스 서비스. (엔진: Aurora, MySQL, PostgreSQL, MariaDB, Oracle, SQL Server)
- Amazon Aurora: AWS가 만든 고성능/고가용성 관계형 데이터베이스. MySQL 및 PostgreSQL과 호환. 표준보다 훨씬 빠름.
NoSQL 데이터베이스
- Amazon DynamoDB: Key-Value 및 문서 기반의 완전관리형 NoSQL DB.
- Amazon DocumentDB: MongoDB와 호환되는 문서 데이터베이스 서비스.
- Amazon Neptune: 소셜 네트워크, 추천 엔진 등 관계 탐색에 최적화된 그래프 데이터베이스.
기타 데이터베이스
- Amazon Redshift: 페타바이트급 데이터 웨어하우징(DW) 서비스. 빅데이터 분석에 사용.
- Amazon ElastiCache: 데이터베이스 앞단에 캐시 계층을 두어 읽기 속도를 향상시키는 인메모리 캐시 서비스. (Redis, Memcached 지원)
- AWS DMS (Database Migration Service): 다운타임을 최소화하며 데이터베이스를 AWS로 마이그레이션하는 서비스.

PART 5. 컴퓨팅 및 서버리스 (코드 실행의 모든 방법)

서비스	개념/역할	언제 사용하는가?
Amazon EC2 (Elastic Compute Cloud)	클라우드 상의 가상 서버. OS, CPU, 메모리 등을 선택하여 완전한 제어권을 가짐.	기존 서버 이전, OS 제어가 필요할 때
AWS Lambda	서버리스 컴퓨팅. 이벤트가 발생할 때만 코드를 실행. 서버 관리가 전혀 필요 없음.	파일 업로드 시 이미지 변환, 간단한 API 백엔드
AWS Fargate	컨테이너를 위한 서버리스 컴퓨팅 엔진. EC2 인스턴스 없이 도커 컨테이너를 실행.	마이크로서비스 아키텍처, 서버 관리 없는 컨테이너 앱
AWS Elastic Beanstalk	코드를 업로드하면 자동으로 환경을 프로비저닝하고 배포해주는 PaaS. (내부적으로 EC2, 로드밸런서 등 사용)	웹 애플리케이션을 쉽고 빠르게 배포하고 싶을 때
AWS CloudFormation	코드형 인프라(IaC). 템플릿(JSON/YAML)을 사용하여 AWS 리소스를 모델링하고 자동 생성.	인프라를 코드로 관리하고 반복적으로 배포할 때

PART 6. 비용 및 지원 (놓치면 안 되는 부분)

EC2 구매 옵션
- 온디맨드: 약정 없이 사용한 만큼 지불. (가장 비쌈)
- 예약 인스턴스(RI) / Savings Plans: 1년 또는 3년 약정으로 큰 할인. (꾸준한 사용량에 적합)
- 스팟 인스턴스: AWS의 남는 자원을 경매로 사용. 최대 90% 저렴. (중단되어도 되는 작업에 적합)
AWS Support 플랜 (Business 플랜이 핵심!)
- Basic/Developer: 기본적인 지원.
- Business: 24x7 기술 지원, 1시간 내 응답, Trusted Advisor 전체 기능 제공.
- Enterprise: Business 플랜의 모든 것 + 전담 기술 계정 관리자(TAM) 배정.

AWS 시험 대비 정리

ReinaMoon — Wed, 16 Jul 2025 23:21:26 +0900

주요 AWS 서비스 및 개념 요약

1. 클라우드 개념 및 이점

클라우드 컴퓨팅: 인터넷을 통해 온디맨드 방식으로 IT 리소스를 제공. 종량 과금 방식.
배포 모델: 퍼블릭 클라우드(AWS 등), 프라이빗 클라우드(온프레미스), 하이브리드 클라우드
AWS 6대 이점: 가변 비용, 규모의 경제, 용량 추정 불필요, 민첩성, 데이터센터 제거, 글로벌 배포 가능
CapEx vs OpEx: 자본지출(CapEx) 대신 운영비용(OpEx)으로 전환 가능
Well-Architected Framework: 운영 우수성, 보안, 신뢰성, 성능 효율성, 비용 최적화, 지속 가능성
Cloud Adoption Framework (CAF): 조직의 클라우드 채택을 위한 6가지 관점 (비즈니스, 인력, 거버넌스 등)

2. 컴퓨팅 서비스

Amazon EC2: 다양한 인스턴스 타입/구매 옵션 제공
- 온디맨드, Savings Plan, 예약 인스턴스, 스팟 인스턴스, 전용 호스트
Auto Scaling / ELB: 자동 확장 및 부하 분산
AWS Lambda: 서버리스 컴퓨팅, 요청당 15분 이하 실행에 적합
컨테이너 서비스: ECS, EKS, Fargate
AWS Lightsail: 소규모 프로젝트용 간편 컴퓨팅 서비스

3. 스토리지 및 데이터베이스

Amazon S3: 객체 스토리지. 다양한 스토리지 클래스 존재 (Standard, IA, Glacier 등)
Amazon EBS: EC2 전용 블록 스토리지 (영구적)
Amazon EFS: EC2 여러 인스턴스가 공유하는 파일 스토리지
Amazon RDS: 관리형 관계형 DB (Aurora, MySQL 등)
Amazon Aurora: 고성능 RDS 엔진 (MySQL/PostgreSQL 호환)
Amazon DynamoDB: 서버리스 NoSQL DB, 밀리초 응답속도
Amazon Redshift: 데이터 웨어하우징 서비스 (분석용)
마이그레이션: DMS, SCT, Snow Family
AWS Backup / Storage Gateway: 하이브리드 및 백업 전용

4. 네트워킹 및 콘텐츠 전송

Amazon VPC: 사용자 정의 가상 네트워크
- 서브넷, IGW, VGW, Direct Connect
- NACL (상태 비저장), 보안 그룹 (상태 저장)
Amazon Route 53: DNS 서비스
Amazon CloudFront: 글로벌 CDN 서비스
VPC 피어링 / Global Accelerator: 리전 간 연결 / 저지연 라우팅

5. 보안, 자격 증명 및 규정 준수

공동 책임 모델: AWS는 인프라, 고객은 데이터/애플리케이션 보안 책임
IAM: 사용자, 그룹, 역할, 정책 기반의 권한 관리
AWS Organizations: 계정 통합 관리, SCP로 액세스 제한 가능
Artifact: 감사/규정 준수 보고서 액세스
Shield, WAF, Inspector, GuardDuty: 보안/위협 탐지/자동화된 평가
KMS: 암호화 키 관리
Secrets Manager / Parameter Store: 자격증명 저장 및 로테이션
AWS Control Tower: 계정 거버넌스 자동화

6. 모니터링 및 분석

Amazon CloudWatch: 메트릭, 로그, 알림
AWS CloudTrail: API 호출 감사 로그
Trusted Advisor: 비용/보안/성능/제한/내결함성 진단
Amazon Athena / QuickSight / X-Ray: SQL 분석 / 시각화 / 트레이싱

7. 요금 및 지원

프리 티어 종류: 12개월 무료, 항상 무료, 평가판
요금 체계: 온디맨드, 예약, 스팟, Savings Plan, 종량 과금제
요금 도구: Pricing Calculator, Budgets, Cost Explorer
통합 결제: Organizations로 계정 비용 통합
지원 플랜:
- Basic: 무료
- Developer: 이메일, 12~24시간 내 응답
- Business: 24/7 전화, 1시간 응답
- Enterprise On-Ramp / Enterprise: TAM, 15분 응답, 워크숍 포함
Marketplace / APN: 타사 솔루션, AWS 파트너 네트워크

8. 글로벌 인프라

리전 (Region): 물리적으로 분리된 AWS 데이터 센터 지역
가용 영역 (AZ): 리전 내의 독립된 데이터센터 단위
엣지 로케이션: CDN 및 DNS 캐시 제공 지점
Local Zone / Wavelength Zone: 초저지연 지역 인프라 확장

III. 시험 대비 퀴즈 & 에세이 주제 (요약)

단답형 예시

- 공동 책임 모델의 고객 vs AWS 책임은?
  - AWS 책임: 물리적 인프라, 네트워크, 하이퍼바이저 등 클라우드 기반 인프라의 보안
  - 고객 책임: 애플리케이션, 데이터, 네트워크 구성, IAM 등 클라우드 내부 리소스 보안
- EC2 인스턴스의 구매 옵션 4가지?
  - 온디맨드 인스턴스
  - 예약 인스턴스
  - 스팟 인스턴스
  - Savings Plan (또는 전용 호스트도 허용됨)
- S3에서 저빈도 액세스에 적합한 클래스 2가지?
  - S3 Standard-IA (Infrequent Access)
  - S3 Intelligent-Tiering (또는 S3 One Zone-IA도 인정 가능)
- VPC 내 트래픽 제어 장치와 특징 (NACL)?
  - 이름: NACL (Network ACL)
  - 특징: 서브넷 단위 제어, 상태 비저장, 허용 및 거부 규칙 둘 다 설정 가능
- RDS와 DynamoDB의 차이점?
  - RDS: 관리형 관계형 데이터베이스, SQL 기반 (예: MySQL, PostgreSQL)
  - DynamoDB: 완전 관리형 NoSQL, 지연 시간이 낮고 고성능
- AWS CloudTrail의 기능은?
  - AWS 계정에서 발생한 모든 API 호출을 기록하고, 감사 및 추적 용도로 사용됨
- AWS Well-Architected Framework의 6대 원칙은?
  - 운영 우수성, 보안, 신뢰성, 성능 효율성, 비용 최적화, 지속 가능성
- AWS Organizations의 장점 2가지?
  - 통합 결제로 여러 계정의 비용을 하나로 관리
  - **SCP(서비스 제어 정책)**를 통한 계정 액세스 중앙 제어
- Trusted Advisor 전체 검사 기능을 제공하는 Support Plan은?
  - Business Support
  - Enterprise On-Ramp / Enterprise Support

에세이형 주제 예시

- CAF가 클라우드 마이그레이션에 기여하는 방식은?
  AWS CAF는 조직의 클라우드 채택을 비즈니스, 인력, 거버넌스, 플랫폼, 보안, 운영의 6가지 관점에서 진단하여 현재 상태를 평가하고, 실행 전략 및 갭 분석을 통해 성공적인 클라우드 이전을 지원합니다. 변화 관리에도 효과적입니다.
- EC2 vs S3에서 공동 책임 모델 적용 차이는?
  - EC2: 고객은 OS 패치, 방화벽 설정, 애플리케이션 보안 등 더 많은 책임
  - S3: AWS는 저장 인프라 보안, 고객은 버킷 정책, 암호화, 데이터 접근 제어 책임
    즉, EC2는 IaaS로 책임 범위가 넓고, S3는 PaaS 성격이 강해 비교적 책임이 작습니다.
- EC2, Lambda, ECS의 워크로드 적용 비교는?
  - EC2: 장기 실행 애플리케이션, 커스터마이징 필요 시\n - Lambda: 이벤트 기반 짧은 실행, 서버리스 환경\n - ECS: 컨테이너 기반 마이크로서비스에 적합\n 각각은 확장성, 탄력성, 관리 편의성의 균형점이 다릅니다.
- 비용 최적화 도구 및 사용 사례?
  - AWS Budgets: 예산 초과 알림 설정
  - Cost Explorer: 과거 비용 트렌드 분석
  - Savings Plan: 장기 사용량 기반 할인 적용
  - Trusted Advisor: 미사용 리소스 권장 정리
    실제로 EC2 예약 인스턴스 미사용 시 Trusted Advisor의 알림으로 비용 절감 가능
- 글로벌 인프라가 고가용성에 기여하는 원리?
  - 리전과 AZ의 물리적 격리를 통해 장애 격리 가능
  - 앱을 멀티-AZ/멀티-리전에 배포하면 하나의 장애가 전체 서비스에 영향 없음
  - CloudFront의 엣지 로케이션은 전 세계 사용자에게 지연 없이 콘텐츠 제공 가능

IV. 핵심 용어집 (선별 주요 용어)

IAM: 권한 및 자격 증명 관리
EC2 / Lambda / Lightsail: 주요 컴퓨팅 서비스
EBS / S3 / EFS / Glacier: 스토리지 계층
RDS / DynamoDB / Aurora: 데이터베이스 계열
CloudFront / Route 53: 콘텐츠 및 네임 서비스
CloudWatch / CloudTrail / Trusted Advisor: 모니터링 및 분석
Shield / WAF / GuardDuty: 보안
VPC / 서브넷 / NACL / 보안 그룹: 네트워크 보안
Organizations / SCP / Control Tower: 계정 및 정책 관리
Pricing Calculator / Cost Explorer / Budgets: 비용 예측 및 추적