이 시험은 "클라우드의 가치를 이해하고, 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 계정을 중앙에서 통합 관리하고 비용을 합쳐서 내는 서비스.
- 핵심 기능:
- 통합 결제 (Consolidated Billing): 모든 계정의 비용을 하나의 마스터 계정에서 관리하고 결제.
- 서비스 제어 정책 (SCP - Service Control Policies): 조직 내 특정 계정에서 특정 서비스(예: 위험한 서비스)를 아예 사용하지 못하도록 중앙에서 권한을 제한.
- 비유: 대기업의 본사. 각 지점(계정)을 관리하고, 전체 회계(결제)를 처리하며, "지점에서는 이런 활동은 절대 금지"와 같은 회사 정책(SCP)을 내릴 수 있습니다.
"이것만 알면 끝!": 내 AWS 계정을 5가지 항목에 대해 자동으로 검사하고, 모범 사례에 따라 개선할 점을 알려주는 개인 컨설턴트.
- 5가지 검사 항목:
- 비용 최적화: 사용하지 않는 EC2, 유휴 로드 밸런서 등을 찾아 비용 절감 제안.
- 성능: 성능 병목 현상을 일으킬 수 있는 설정을 찾아 개선 제안.
- 보안: MFA 미사용, S3 버킷 공개 등 보안 허점 지적.
- 내결함성: 단일 AZ에만 리소스가 있는 등 장애에 취약한 구성을 찾아 개선 제안.
- 서비스 한도: 곧 한계에 도달할 리소스(예: 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신기 (언제 쓰는가?)
- 사용 전 (견적): AWS 요금 계산기 (Pricing Calculator)
- 사용 중 (경고): AWS Budgets (예산 설정 및 알림)
- 사용 후 (분석): AWS Cost Explorer (비용 내역 시각화 및 원인 파악)
다시 풀어봐야하는 AWS-CLF02 모의고사 문제들
https://github.com/ReinaMoon/Get_A_Certification/blob/main/exam_aws_clf02.md
반응형
'CS > 시험 공부' 카테고리의 다른 글
| AWS CLF-02 #6 상세 정리 (3) | 2025.08.12 |
|---|---|
| AWS CLF-02 #5 상세 정리 (3) | 2025.08.11 |
| AWS CLF-02 #4 상세 정리 (3) | 2025.08.11 |
| AWS CLF-02 #3 상세 정리 (0) | 2025.08.11 |
| AWS CLF-02 #2 상세 정리 (3) | 2025.08.10 |
