• 시험 비중은 작지만 🚨
• 실제 회사에서는 돈을 아끼고(비용 최적화),
  빠르게 잘 돌아가게(성능 최적화) 하는 게 아주 중요해요.

👉 비유:

• 비용 최적화 = 용돈 절약 🪙
• 성능 최적화 = 시험 공부할 때 빠르고 효율적인 방법 찾기 ✏️

• AWS Trusted Advisor = 선생님 조언 👩‍🏫 (낭비하는 리소스 알려줌)
• Cost Explorer = 가계부 📒 (돈이 어디에 쓰였는지 확인)
• AWS Budgets = 용돈 한도 설정 💵 (넘으면 알림)
• 태그(Tag) = 이름표 붙이기 🏷️ (부서별, 프로젝트별 비용 추적)
• 스팟 인스턴스 = 땡처리 세일 상품 🛒 (싸지만 언제 사라질 수 있음)
• 예약 인스턴스/저장용량 예약 = 정기권 🎫 (장기 이용 시 할인)
• 관리형 서비스 (RDS, Fargate, EFS) = 학원 버스 🚌 (직접 운전 안 해도 됨 → 시간·돈 절약)

• EC2 인스턴스 종류 = 운동선수 선택 🏃‍♂️ (달리기, 수영, 씨름 선수처럼 필요에 맞게 선택)
• 향상된 네트워킹 / 배치 그룹 = 초고속 도로 🛣️ (빠른 데이터 통신)
• EBS 지표 확인 = 건강검진 결과 📊 (디스크 상태, 속도 확인)
• S3 Transfer Acceleration = 택배 항공편 ✈️ (멀리서도 빠르게 전송)
• S3 멀티파트 업로드 = 레고 블록 조립 🧱 (큰 파일을 조각내서 빨리 업로드)
• RDS 성능 지표 = 성적표 📑 (데이터베이스 상태 확인)
• RDS Proxy / 성능 개선 도우미 = 공부 과외 선생님 👨‍🏫 (효율적으로 연결 관리, 문제 알려줌)

📝 비용 태그(JSON 예시)

{
  "Key": "Project",     // 태그 이름: 어떤 프로젝트인지
  "Value": "ShoppingApp" // 태그 값: 쇼핑 앱 프로젝트
}

👉 설명: EC2나 S3 같은 리소스에 "이건 쇼핑앱 프로젝트용이야" 라고 이름표를 붙이는 것.
이렇게 하면 나중에 비용을 프로젝트별로 확인할 수 있어요.

💼 현업에서 어떻게 쓰일까?

1. 스타트업
   • 스팟 인스턴스 활용 → 개발 서버 비용 절감
2. 금융사
   • RDS Proxy → 동시에 많은 고객이 접속해도 빠르게 처리
3. 게임사
   • CloudFront + S3 Transfer Acceleration → 전 세계 게이머에게 업데이트 빠르게 전달
4. 대기업 IT팀
   • Cost Explorer + Budgets → 부서별 클라우드 비용 관리
   • 태그 붙여서 “마케팅팀” vs “개발팀” 비용 따로 확인
5. e커머스 회사
   • EBS 지표 보고 성능 부족하면 SSD 타입으로 교체 → 결제 지연 방지

🧾 정리

• 비용 최적화 = 돈 아끼기 (가계부, 세일 상품, 이름표 관리)
• 성능 최적화 = 빠르고 효율적으로 (초고속 도로, 택배 항공편, 과외 선생님)
• 시험 팁: 보안과 함께 비용·성능 최적화까지 고려된 답이 정답일 확률 ↑

• "더 빠르게 하려면 돈이 많이 든다" → 보통 이렇게 생각해요.
• 하지만 AWS에서는 비용(돈)과 성능(속도) 을 같이 최적화할 수 있어요!
• 즉, 똑똑하게 선택하면 빠르고 싸게 둘 다 잡을 수 있어요 😎

👉 비유:

• 비용 최적화 = 용돈 아껴 쓰기 🪙
• 성능 최적화 = 시험 문제 빨리 푸는 방법 찾기 ✏️

• AWS는 서버를 사는 게 아니라 빌리는 것 🏠
• 쓰고 싶을 때만 켜고, 다 쓰면 꺼서 요금 STOP! ⏹️

👉 예시:

• 6시간 필요한 작업 → EC2 켜서 딱 6시간만 사용

• 큰 숙제를 혼자 하면 6시간 ⏳
• 6명이 같이 하면 1시간만에 끝! 🙌
• AWS도 이렇게 병렬 처리(Parallel Workload) 를 지원해요.

👉 단점:

• 더 많은 컴퓨터(EC2)를 켜야 해서 순간 비용은 ↑
  👉 장점:
• 전체 시간 단축 → 결과적으로 효율적

• 마트에서 "땡처리 세일" 상품 사는 것과 같아요 🛒
• 싸게 빌릴 수 있지만, 언제 회수될지 몰라요.
• 긴급하지 않은 작업에 사용하면 비용 절약 👍

• EC2 인스턴스는 필요에 맞게 고를 수 있어요 🏋️‍♂️
  • 메모리 많은 서버? 🧠
  • CPU 파워 강한 서버? 💪
• 작업에 맞게 골라 쓰면 성능이 좋아져요.

📝 EC2 스팟 인스턴스 요청 JSON 예시

{
  "InstanceType": "m5.large",     // 인스턴스 종류 (중간 크기 서버)
  "SpotPrice": "0.05",            // 시간당 내가 낼 최대 가격 ($0.05)
  "InstanceCount": 3,             // 실행할 서버 개수 (3대)
  "Action": "request"             // 스팟 인스턴스 요청
}

🔎 한 줄씩 설명

• "InstanceType": "m5.large" → 필요한 서버 크기 선택
• "SpotPrice": "0.05" → "나는 5센트까지만 낼래!"
• "InstanceCount": 3 → 서버 3대 동시에 실행
• "Action": "request" → 스팟 인스턴스 요청 시작

👉 즉, "세일 서버 3대 주세요! 단, 5센트 이상이면 안 사요~" 라는 뜻이에요.

💼 현업에서 어떻게 쓰일까?

1. 연구소
   • 빅데이터 분석 작업을 병렬 처리 → 10시간 걸릴 걸 2시간 만에 끝냄
2. 게임 회사
   • 긴급하지 않은 테스트 서버는 스팟 인스턴스로 실행 → 비용 70% 절약
3. 금융사
   • RDS(데이터베이스) 지표 모니터링 → 성능 부족 시 빠른 업그레이드
4. 스타트업
   • AWS Budgets로 비용 초과 시 알람 → 클라우드 요금 폭탄 방지
5. e커머스
   • 큰 이미지 파일 업로드 시 S3 멀티파트 업로드 사용 → 업로드 실패 줄이고 성능 개선

🧾 정리

• AWS에서는 비용 절약과 성능 향상을 동시에 할 수 있어요.
• 👉 핵심 방법:
  • 필요할 때만 쓰기
  • 병렬 처리로 빨리 끝내기
  • 스팟 인스턴스로 절약
  • 작업에 맞는 인스턴스 선택

시험 문제에서도 항상 **“비용 + 성능 둘 다 고려된 답”**이 정답일 확률이 높습니다 ✅

• 네트워킹과 콘텐츠 전송은 시험 비중이 높고 광범위
• 학습 영역을 3개로 나누면 정리하기 쉬움
  1. 네트워킹 기능 및 연결 구현
  2. DNS 서비스 & 콘텐츠 전송 구성
  3. 네트워크 연결 문제 해결

• VPC (Virtual Private Cloud)
  • 서브넷, 라우팅 테이블, NACL, 보안 그룹
  • NAT 게이트웨이, 인터넷 게이트웨이
• 보안 연결
  • Systems Manager Session Manager (SSH 대체)
  • VPC 엔드포인트 (프라이빗 연결)
  • VPC 피어링, VPN 연결
• 보호 도구
  • AWS WAF (웹 방화벽)
  • AWS Shield (DDoS 방어)

• Amazon Route 53
  • 호스팅 영역, 레코드 관리
  • 라우팅 정책 (단순, 지연시간, 가중치, 장애조치 등)
• Amazon CloudFront + S3
  • 전 세계 CDN(콘텐츠 전송 네트워크) 구축
  • SSL/TLS 인증서(ACM)로 보안 강화
• 일반적인 DNS 구성
  • A 레코드, CNAME, Alias, MX 등

• 구성 확인
  • 서브넷, 라우팅, NACL, 보안 그룹 확인
• 로그 분석
  • VPC Flow Logs
  • ELB 액세스 로그
  • AWS WAF / Web ACL 로그
  • CloudFront 로그
• 문제 해결 예시
  • S3 정적 웹사이트 + CloudFront 캐싱 오류 → 캐시 무효화
  • Route 53 레코드 잘못 설정 → 도메인 불분해 문제 해결

📝 Route 53 레코드 JSON 예시

{
  "Comment": "Route 53 A 레코드 예시",   // 레코드 설명
  "Changes": [
    {
      "Action": "CREATE",               // 레코드 생성 동작
      "ResourceRecordSet": {
        "Name": "example.com",          // 도메인 이름
        "Type": "A",                    // A 레코드 (IPv4 주소 매핑)
        "TTL": 300,                     // TTL (캐싱 시간, 초 단위)
        "ResourceRecords": [
          { "Value": "192.0.2.44" }     // 연결할 IP 주소
        ]
      }
    }
  ]
}

🔎 라인별 설명

• "Comment" → 레코드에 대한 설명 문구
• "Action": "CREATE" → 새로운 레코드 생성
• "Name": "example.com" → 연결할 도메인 이름
• "Type": "A" → A 레코드 (IPv4 매핑)
• "TTL": 300 → DNS 캐싱 유지 시간 5분
• "ResourceRecords" → 연결할 실제 IP 주소 목록

👉 현업에서는 Alias 레코드를 활용해 CloudFront 배포 또는 S3 버킷과 연결하는 경우가 많습니다.

💼 현업 적용 사례

1. 스타트업: S3 정적 웹사이트 + CloudFront → 전 세계 빠른 콘텐츠 제공
2. 금융사: VPC 엔드포인트를 사용해 S3와 프라이빗 연결 → 인터넷을 거치지 않음
3. 게임사: WAF + Shield Advanced → DDoS 공격 방어
4. e커머스: Route 53 지연시간 기반 라우팅 → 사용자에게 가장 가까운 리전으로 트래픽 분산
5. 엔터프라이즈: VPC Flow Logs + GuardDuty → 네트워크 이상 징후 실시간 탐지

📌 시험 대비 핵심 키워드

• VPC: Subnet, Route Table, NACL, SG, NAT GW, IGW
• 보안 연결: Session Manager, VPC 엔드포인트, VPN, Peering
• 보호 서비스: WAF, Shield
• Route 53: 레코드 타입, 라우팅 정책, DNS 구성
• CloudFront + S3: CDN, HTTPS 전송, 캐싱
• 트러블슈팅: VPC Flow Logs, ELB Logs, WAF/CloudFront Logs

네트워크와 콘텐츠 전송을 잘 알면:

• 시험에 합격할 수 있어요 🎓
• 회사에서 실제로 안전하고 빠른 인터넷 환경을 만들 수 있어요 💻⚡

• VPC = 아파트 단지 🏢 (내가 원하는 대로 나누고 관리하는 네트워크)
• 서브넷 = 아파트 동 (각각 다른 구역)
• 라우팅 테이블 = 네비게이션 지도 🗺️ (길 안내)
• 보안 그룹 = 현관문 비밀번호 🔑 (누가 들어올지 정함)
• NACL = 아파트 단지 정문 🚪 (더 큰 단위 보안)

👉 VPN = 비밀 터널 🛤️
👉 VPC Peering = 옆 단지랑 다리 놓기 🌉
👉 Session Manager = 열쇠 없어도 관리실에서 초대해서 들어가기 🚪

• Route 53 = 인터넷 전화번호부 ☎️
  → 도메인 이름(예: www.example.com)을 진짜 집 주소(IP)랑 연결해 줌
• CloudFront = 택배 물류창고 🚚
  → 가까운 창고에서 물건(콘텐츠)을 빨리 보내줌
• S3 = 택배 물품 창고 📦 (사진, 동영상, 문서 저장)

• AWS WAF = 집 앞 CCTV + 경비 아저씨 👮 (나쁜 봇, 해커 차단)
• AWS Shield = 대규모 경찰 지원 🚔 (큰 공격, DDoS 방어)
• VPC Flow Logs = 블랙박스 🎥 (누가 드나들었는지 기록)
• ELB Logs = 공동 현관 출입 기록 📋
• CloudFront Logs = 택배 배송 기록 📝

📝 Route 53 레코드 예시 (DNS 등록)

{
  "Comment": "Route 53 A 레코드 예시",   // 설명: 도메인 연결 기록
  "Changes": [
    {
      "Action": "CREATE",               // 동작: 새로 만들기
      "ResourceRecordSet": {
        "Name": "example.com",          // 도메인 이름
        "Type": "A",                    // A레코드 (IP와 연결)
        "TTL": 300,                     // 캐싱 시간 (5분)
        "ResourceRecords": [
          { "Value": "192.0.2.44" }     // 진짜 서버 IP 주소
        ]
      }
    }
  ]
}

💼 현업에서 어떻게 쓰일까?

1. 회사 내부 직원만 데이터베이스 접근
   • VPC + VPN 으로만 접속 가능 → 외부 해커 차단
2. 게임 회사
   • CloudFront로 전 세계 게이머에게 빠르게 업데이트 배포
3. 은행
   • Route 53 장애조치 라우팅(Failover) → 서버가 멈추면 자동으로 다른 서버로 연결
4. 온라인 쇼핑몰
   • WAF로 SQL Injection 같은 공격 차단
   • Shield Advanced로 대형 DDoS 공격 방어
5. IT 운영팀
   • VPC Flow Logs와 ELB Logs 확인 → 누가 잘못된 접속을 시도했는지 추적

🧾 정리

• VPC = 네트워크의 기본 집
• Route 53 = 인터넷 전화번호부
• CloudFront = 빠른 택배 배달
• WAF/Shield = 보안 지킴이
• 로그들 = 블랙박스 (문제 생기면 추적 가능)

👉 시험에서도, 실무에서도 항상 “보안과 안정성”이 더 좋은 답을 고르면 정답일 확률이 높습니다 ✅

📘 AWS Certified SysOps Administrator - Associate (SOA-C02)

Domain 4: 보안 및 규정 준수 (Security & Compliance)

> 이 도메인은 시험 점수의 **16%**를 차지하며, AWS 보안과 규정 준수 정책을 이해하고 구현하는 능력을 평가합니다.
> 핵심은 **비밀 유지(Secrets)** 와 **보안 유지(Security)** 입니다.

---

🔑 주요 학습 주제

1. 보안 정책 및 규정 준수 정책 구현

- **IAM 관리**

• 사용자(User), 그룹(Group), 역할(Role)의 차이 이해
• 암호 정책(Password Policy), MFA 적용
• IAM 정책 JSON 해석 능력
• IAM Access Analyzer, Policy Simulator 활용

- **감사 & 모니터링**

• AWS CloudTrail: 모든 API 호출 기록
• AWS Trusted Advisor: 보안 권장 사항 확인
• 다중 계정 전략: AWS Organizations, Control Tower
• 리전 선택 시 규정 준수 고려 (GDPR, PCI DSS 등)

---

2. 데이터 및 인프라 보호 전략

- **데이터 보호 & 분류**

• 민감 데이터 vs 공개 데이터 구분
• 보관 위치 및 암호화 의무화

- **암호화 & 키 관리**

• S3 암호화 옵션 (SSE-S3, SSE-KMS, SSE-C)
• AWS KMS, CloudHSM 키 관리
• 전송 중 데이터 암호화 (VPN, TLS, ACM 인증서)

- **비밀 관리 & 보안 서비스**

• AWS Secrets Manager → DB 비밀번호, API 키 저장
• SSM Parameter Store → 설정값 안전 관리
• AWS Config, GuardDuty, Security Hub, Inspector, Macie → 보안 상태 점검

---

{
  "Version": "2012-10-17", // 정책 버전 (항상 이 날짜 형식 고정)
  "Statement": [           // 권한을 정의하는 블록
    {
      "Effect": "Allow",   // 허용(Allow) 또는 거부(Deny)
      "Action": "s3:*",    // S3 서비스에서 모든 동작 허용
      "Resource": "*"      // 모든 S3 리소스에 적용
    }
  ]
}

🔎 라인별 설명

• "Version": "2012-10-17" → AWS 정책 문서 표준 버전
• "Statement" → 실제 권한 정의하는 배열
• "Effect": "Allow" → 동작을 허용한다는 의미
• "Action": "s3:*" → S3에서 가능한 모든 API 호출 허용 (GetObject, PutObject 등)
• "Resource": "*" → 모든 S3 버킷 및 객체에 적용

👉 실제 현업에서는 Resource 를 "arn:aws:s3:::my-bucket/*" 같이 특정 리소스로 제한하는 것이 보안 모범 사례입니다.

💼 현업 적용 사례

1. IAM & MFA
   • 사내 직원 계정에 MFA를 필수 적용하여 계정 탈취 위험 방지
2. CloudTrail & GuardDuty
   • 모든 API 호출을 기록 → 비정상 로그인 시도 탐지 가능
3. 데이터 암호화
   • 고객의 금융/의료 데이터는 반드시 KMS를 사용하여 암호화
   • GDPR 등 규정에 따라 특정 리전(EU) 내 데이터 저장
4. Secrets Manager
   • RDS 데이터베이스 비밀번호를 직접 코드에 넣지 않고 Secrets Manager에 저장 → 앱이 동적으로 불러와 사용
5. Security Hub & Inspector
   • 보안 취약점 자동 탐지 → 패치 미적용 서버를 알림으로 확인 가능

📌 핵심 키워드 요약

• IAM, MFA, JSON 정책, Access Analyzer
• CloudTrail, Trusted Advisor, AWS Organizations
• 데이터 분류, 암호화 (KMS, CloudHSM, ACM, VPN)
• Secrets Manager, Parameter Store
• Config, GuardDuty, Security Hub, Inspector, Macie

🔐 AWS Certified SysOps Administrator - Associate (SOA-C02)

Domain 4: 보안 및 규정 준수에 대한 이해

📌 핵심 요약

• 보안은 AWS 인프라의 모든 단계(계획 → 구축 → 운영) 에 걸쳐 반드시 고려해야 함
• IAM 은 AWS 액세스 관리의 중심 → 최소 권한 원칙 적용 필수
• CloudTrail, CloudWatch 를 통한 감사 및 모니터링으로 규정 준수 유지
• 시험에서는 “보안성이 더 높은 선택지가 있으면 그것이 정답”인 경우가 많음

🛡️ 주요 학습 포인트

1. IAM (Identity & Access Management)

• 최소 권한 원칙 (Least Privilege)
  • 사용자에게 꼭 필요한 권한만 부여
  • Production 계정 직접 액세스는 극히 제한
• MFA(멀티 팩터 인증)
  • 콘솔 로그인 시 추가 인증 단계 요구
• 역할(Role)과 페더레이션(Federation)
  • 임시 권한 부여 / 외부 IdP 연동

2. 변경 관리 & 자동화

• 리소스 시작·종료 권한은 개인이 아닌 자동화 도구를 통해 수행
• 변경 관리 프로세스를 통해 실수·오류를 최소화

3. 감사 & 추적

• AWS CloudTrail
  • 모든 API 호출 및 이벤트 로깅
  • “누가, 언제, 무엇을” 했는지 추적 가능
• Amazon CloudWatch
  • CloudTrail 이벤트와 연동 → 알람·경보 생성
• 규정 준수 미준수 활동 탐지 및 알림 자동화 가능

📊 보안 & 규정 준수 흐름 (Mermaid)

flowchart TD
    A["보안 & 규정 준수 고려"] --> B["IAM 관리"]
    A --> C["변경 관리 & 자동화"]
    A --> D["감사 & 추적"]

    B --> B1["최소 권한 원칙"]
    B --> B2["MFA 적용"]
    B --> B3["Role / Federation 활용"]

    C --> C1["자동화 도구를 통한 리소스 제어"]
    C --> C2["프로덕션 계정 직접 액세스 최소화"]

    D --> D1["CloudTrail 로그"]
    D --> D2["CloudWatch 알람"]
    D --> D3["규정 준수 상태 점검"]


📝 예시 IAM 정책 JSON

{
"Version": "2012-10-17", // 정책 버전 (고정된 표준)
"Statement": [
{
"Effect": "Allow", // 허용 규칙
"Action": [ // 허용할 액션 목록
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "arn:aws:ec2:ap-northeast-2:123456789012:instance/*"
// 특정 계정의 모든 EC2 인스턴스
}
]
}

```

👉 실무 포인트

• Production 환경에서는 ec2:TerminateInstances 권한은 절대 직접 부여 금지
• Terraform, CloudFormation 같은 IaC 도구를 통해 관리하는 것이 안전

💼 현업 적용 사례

1. 금융회사: 고객 데이터 저장 시 반드시 KMS 키로 암호화
2. 게임사: 운영자가 실수로 서버를 종료하지 않도록 EC2 종료 권한은 자동화 도구에만 부여
3. 의료기관: CloudTrail + GuardDuty로 의심스러운 API 호출 탐지
4. 스타트업: Secrets Manager로 DB 비밀번호 관리 → 코드에 하드코딩 금지

📌 시험 대비 팁

• “두 옵션 중 하나가 보안성이 더 높다” → 보안 강화된 옵션 선택
• IAM, CloudTrail, CloudWatch, Config, GuardDuty, Security Hub 등 보안 서비스의 목적과 차이점 숙지
• Least Privilege 는 항상 답안에서 핵심 키워드

✅ 결론: 보안 및 규정 준수는 AWS 인프라의 기초 체력
시험뿐 아니라 실무에서도 IAM, 감사, 암호화는 반드시 숙지해야 하는 핵심입니다.

📘 Q311 문제 정리

📝 문제 요약

• 회사는 여러 사업부에서 Amazon EC2를 사용.
• 단, 승인된 EC2 인스턴스 구성만 사용해야 함.
• 사업부는 직접 인스턴스를 시작(provisioning) 가능해야 함.

✅ 정답: C. AWS Service Catalog

AWS Service Catalog를 사용하면 관리자가 승인된 EC2 인스턴스 템플릿을 미리 정의할 수 있음.
각 사업부는 Service Catalog 안에서만 인스턴스를 실행할 수 있으므로, 표준화된 구성만 사용 가능.

❌ 오답 포인트

1. A. Management Console에서 인스턴스 시작 구성 허용
   • 단순히 시작 구성을 지정하는 방법.
   • 승인된 인스턴스만 보장 ❌ (사업부가 다른 구성도 시작할 수 있음).
2. B. IAM 정책 + CloudFormation 템플릿 제공
   • IAM 정책만으로는 승인된 인스턴스 구성 강제 ❌.
   • CloudFormation 템플릿도 사업부가 임의로 수정 가능 → 보안 리스크.
3. D. CloudFormation 템플릿 공유
   • 템플릿을 직접 공유하는 방식도 마찬가지로 표준 강제가 어려움.
   • 관리자가 승인된 구성을 보장하기에는 불완전.

🔎 해설

• AWS Service Catalog는 기업 IT에서 표준화된 리소스 템플릿을 제공할 때 사용.
• EC2, RDS, VPC 등 미리 승인된 구성을 카탈로그로 묶어 제공 →
  사업부는 해당 카탈로그 내에서만 리소스를 시작 가능.
• 따라서 정책 준수와 운영 효율성을 동시에 만족시킴.

📊 흐름 (Mermaid 다이어그램)

 

📌 핵심 키워드

• Service Catalog → 표준화 + 승인된 구성만 제공
• IAM → 권한 제어 보완용
• CloudFormation → 리소스 자동화 (하지만 표준 강제 기능은 부족)

👉 정리: "여러 부서에서 EC2를 써야 하지만 반드시 표준화된 구성만 쓰게 하고 싶다" → 정답은 무조건 Service Catalog.

📝 Q314 분석 정리

📌 문제 요약

• 환경: Windows 파일 서버 + Amazon FSx 파일 시스템
• 조건: 사용 가능한 공간이 100GB 미만일 때 관리자에게 이메일 알림
• 요구 사항: SysOps 관리자가 SNS를 통해 이메일을 받아야 함

✅ 정답: B, E

🔎 선택지별 해설

1. A. FreeStorageCapacity 지표 + EventBridge 규칙 ❌
   • EventBridge는 주로 이벤트 기반 서비스 연동에 사용됨.
   • 스토리지 임계치 모니터링은 CloudWatch 지표와 알람이 적합.
2. B. FreeStorageCapacity 지표 + CloudWatch 경보 ✅
   • Amazon FSx는 CloudWatch 지표(FreeStorageCapacity) 제공.
   • 조건(100GB 미만)일 때 CloudWatch Alarm을 트리거하여 모니터링 가능.
3. C. CloudWatch 경보 → Lambda → SNS 게시 ❌
   • 가능은 하지만 불필요하게 Lambda를 거칠 필요 없음.
   • 문제 요구는 단순히 이메일 알림 → SNS 직접 연결이 가장 효율적.
4. D. Alarm 진입 시 EventBridge 규칙 실행 ❌
   • EventBridge로 우회할 필요 없음.
   • CloudWatch Alarm → SNS 연결로 충분.
5. E. CloudWatch Alarm → SNS 주제 알림 구성 ✅
   • CloudWatch Alarm 상태 전환 시 SNS에 게시 → 이메일 알림 발송
   • 문제에서 요구하는 알림 방식을 충족.

📊 아키텍처 흐름 (Mermaid)

🎯 정리

• B: FreeStorageCapacity 지표를 기반으로 CloudWatch Alarm 생성
• E: Alarm 상태 전환 시 SNS로 알림 → 이메일 발송

👉 즉, CloudWatch + SNS 조합이 정답!

📘 Q326 문제 정리

📝 문제 상황

• 환경: AWS Organizations → 여러 계정 관리
• 요구사항:
  • 각 계정 리소스의 메트릭 임계값 초과 시 경고 발생
  • 이를 중앙 집중식으로 알림 받을 수 있어야 함

✅ 정답: A

👉 조직의 계정에 CloudFormation StackSets을 배포하고,
👉 각 계정에서 CloudWatch Alarm을 생성하며,
👉 로그/보안 계정에 있는 SNS 주제로 알림을 전달한다.

📊 아키텍처 흐름 (Mermaid)

 

🔑 핵심 개념 정리

• CloudFormation StackSets
  • 멀티 계정/리전에 CloudFormation 리소스를 일괄 배포 가능
• CloudWatch Alarms
  • 각 계정에서 리소스 상태 모니터링 및 임계값 초과 감지
• SNS (중앙 계정)
  • 모든 계정에서 발생한 경보를 한 곳에 모아 중앙 관리자에게 전달

🚀 운영 효율 포인트

• 계정이 많아도 일관된 모니터링/알림 구조 유지 가능
• 관리 계정 하나에서만 집중 관리 → 운영 부담 최소화
• 확장성 좋고, 보안적으로도 안전한 구조

👉 이렇게 하면 Q326은 “멀티 계정 환경에서 중앙 집중식 CloudWatch 알림 체계 구축” 문제라는 게 명확해집니다 ✅

📘 Q327 문제 정리

📌 문제 요약

• 회사는 AWS Lambda 함수를 사용해 외부 소스에서 데이터를 검색.
• Lambda 함수는 VPC와 연결되지 않은 상태.
• 수정된 애플리케이션은 프라이빗 서브넷의 Amazon RDS DB 인스턴스에 접근해야 함.
• VPC는 퍼블릭 서브넷 2개, 프라이빗 서브넷 2개 존재.
• 목표: Lambda 함수가 프라이빗 DB에 액세스 가능하면서도 인터넷 접근이 가능해야 함.

✅ 정답: C

VPC 액세스를 위해 Lambda 함수를 재구성하고, NAT 게이트웨이를 통해 인터넷으로 라우팅하도록 설정

• Lambda 함수를 VPC에 연결해야 프라이빗 RDS 접근 가능
• 하지만 Lambda는 인터넷이 필요하므로, 퍼블릭 서브넷에 NAT 게이트웨이 배치 → 프라이빗 서브넷에서 인터넷으로 나가는 경로 제공
• 보안 그룹과 라우팅 테이블 규칙도 함께 설정 필요

❌ 오답 해설

• A. VPC 액세스 및 탄력적 IP 주소 → 오답
  • Lambda는 탄력적 IP로 직접 인터넷에 접근 불가
  • NAT 게이트웨이/NAT 인스턴스를 사용해야 함
• B. VPC 액세스 + 탄력적 IP 주소 + 새로운 Lambda → 오답
  • Lambda 함수 생성 방식이 잘못됨 (탄력적 IP 불필요)
  • 핵심은 NAT 게이트웨이 필요성
• D. VPC 액세스 + 인터넷 게이트웨이 → 오답
  • 프라이빗 서브넷에 배치된 Lambda는 인터넷 게이트웨이만으로 외부 접근 불가
  • 반드시 NAT 게이트웨이를 거쳐야 함

📊 정리 포인트

• Lambda가 프라이빗 서브넷 리소스(RDS) 접근 필요 → VPC 연결 필수
• Lambda가 외부 API 호출(인터넷 접근) 필요 → NAT 게이트웨이 필수
• 인터넷 게이트웨이만으로는 부족, Lambda는 퍼블릭 IP를 직접 사용하지 않음

📈 다이어그램 (Mermaid)

👉 핵심 기억: Lambda + VPC 연결 시 인터넷 접근하려면 NAT 게이트웨이 필요! 🚀

📘 Q332 문제 정리

📝 문제 요약

• 회사는 실행 중인 Amazon EC2 인스턴스 수를 모니터링하고 싶음.
• 인스턴스 수가 특정 임계값에 도달하면 서비스 할당량 증가를 자동화해야 함.

✅ 정답: A. CloudWatch 경보 + Lambda

Amazon CloudWatch 경보로 임계값을 모니터링하고,
해당 경보가 발생하면 AWS Lambda를 호출하여 할당량 증가 요청을 자동화.

❌ 오답 포인트

1. B. AWS Config
   • AWS Config는 리소스 설정 변경 추적 용도.
   • 실시간 서비스 할당량 모니터링/증가 자동화 ❌.
2. C. CloudWatch 대시보드
   • 대시보드는 시각화 도구일 뿐, 자동으로 액션 수행 ❌.
3. D. Trusted Advisor + SNS
   • Trusted Advisor는 리소스 최적화, 비용, 보안 권장사항 제공 용도.
   • 임계값에 따른 자동 증가 처리와는 무관 ❌.

🔎 해설

• CloudWatch는 메트릭 기반 경보 생성 가능 (ex: EC2 인스턴스 수 ≥ 특정 값).
• 경보가 발생하면 Lambda 함수를 트리거 →
  서비스 할당량 증가 API 호출 자동화.
• 따라서 운영 효율성과 자동화를 모두 충족.

📊 흐름 (Mermaid 다이어그램)

 

📌 핵심 키워드

• CloudWatch Alarm → 상태 감지
• Lambda Function → 자동화 액션 실행
• Service Quotas → 할당량 증가

👉 이렇게 정리해두면, 비슷한 문제에서 "모니터링 + 자동 액션" 키워드를 보면 바로 CloudWatch + Lambda 조합을 떠올리면 됩니다.

docker network ls

docker container ls -a
docker container start [my-ubuntu:0.1 Container ID]
docker container attach [my-ubuntu:0.1 Container ID]
ifconfig

nice@myserver01:~$ docker container run -it --network=host my-ubuntu:0.1 bash
root@myserver01:/# ifconfig
root@myserver01:/# exit

nice@myserver01:~$ docker container run -it --network=bridge my-ubuntu:0.1 bash
root@myserver01:/# ifconfig
root@myserver01:/# exit

nice@myserver01:~$ docker container run -it --network=none my-ubuntu:0.1 bash
root@myserver01:/# ifconfig
root@myserver01:/# exit

도커 컨테이너 네트워크 퀴즈

Q1. 네트워크 드라이버 비교

1. ubuntu 이미지를 이용해 컨테이너를 각각 네트워크 모드로 실행하시오. (net-tools 또는 iproute2 설치)
   • bridge
   • host
   • none

    2. 컨테이너 내부에서 네트워크 정보를 확인해 결과를 비교하고 차이를 확인하세요. (ifconfig 또는 ip addr)

• apt-get update && apt-get install -y iproute2
• ip a

Q2. 파일 전송

• 호스트 ↔ 컨테이너 파일 전송
  1. 호스트에서 work/ch03/ex01/hello.txt 파일을 만든다. (내용은 자유)
  2. 실행 중인 컨테이너의 /home 디렉토리로 복사하시오.
  3. 컨테이너 내부에서 해당 파일을 확인하시오.
• 컨테이너 ↔ 호스트 파일 전송
  1. 컨테이너 내부에서 /home/hello.txt 를 복사해 /home/hello2.txt 로 만든 뒤, 현재 시간(date)을 추가하시오.
  2. 이 파일을 호스트의 work/ch03/ex01 디렉토리로 복사하시오.
  3. 호스트에서 파일이 잘 복사되었는지 확인하시오.

🚀 배포, 프로비저닝 및 자동화 (Deployment, Provisioning & Automation)

1. 도메인 개요

• 비중: 시험 점수의 약 18%
• 핵심 테마
  1. 클라우드 리소스의 프로비저닝 및 유지 관리
  2. 반복 가능한 프로세스 자동화

2. 주요 학습 주제

(1) 리소스 프로비저닝 및 유지 관리

• EC2 AMI: AMI 생성·관리 (Image Builder 활용 포함)
• CloudFormation: IaC(Infrastructure as Code)로 스택 생성·관리, 문제 해결
• 리전·계정 간 리소스 관리
  • Resource Access Manager (RAM)
  • CloudFormation StackSets
  • IAM Cross-Account Role
• 배포 전략
  • Blue-Green
  • Rolling Update
  • Canary Deployment
• 서비스 할당량(Service Quotas)
  • 자원 제한 이유 (안정성·보안)
  • 제한 상향 요청 방법
• 오류 대응
  • VPC/서브넷 크기 설정
  • CloudFormation 템플릿 오류
  • OpsWorks 에러 처리

(2) 수동 또는 반복 가능한 프로세스 자동화

• 자동화 도구
  • CloudFormation (IaC)
  • AWS OpsWorks (Chef, Puppet)
  • Elastic Beanstalk (애플리케이션 배포 자동화)
  • AWS Systems Manager (패치 관리, Run Command, Automation Runbooks)
• 이벤트 기반 자동화
  • Amazon EventBridge → 일정·이벤트 기반 작업 트리거
  • AWS Config → 규정 위반 시 자동 조치
• 자동화 시나리오
  • 정기 패치 관리
  • 인스턴스 자동 시작·중지
  • 리소스 정책 자동 수정

3. 시험에서 나올 수 있는 예시 포인트

• AMI 생성·배포 프로세스에 대한 질문
• CloudFormation 스택 오류 원인 분석
• 서비스 할당량 초과 → 해결 방법? (Quotas 변경 요청)
• Blue-Green/Canary 배포 전략 비교
• Systems Manager Automation으로 패치 관리 자동화
• EventBridge 규칙으로 특정 이벤트 발생 시 Lambda 실행

4. 실무 적용 인사이트

• 운영자가 직접 리소스를 생성·변경하는 대신 IaC 및 자동화로 표준화된 환경 제공
• 반복 작업 최소화 → 인적 오류 감소
• 배포 전략(Blue-Green 등)을 통해 무중단 배포 가능
• 서비스 할당량 관리로 장애 예방
• 자동화 도구 조합 (CloudFormation + Systems Manager + EventBridge)으로 운영 효율성 극대화

✅ 핵심 요약
배포, 프로비저닝 및 자동화는 AWS 인프라를 표준화·자동화하여 운영 효율성을 극대화하는 영역입니다.
시험에서는 AMI, CloudFormation, 배포 전략, 자동화 서비스(EventBridge, Systems Manager, Config) 관련 문제가 자주 출제되며,
실무에서는 반복 작업 자동화 + 무중단 배포 전략이 가장 중요한 포인트입니다.

🚀 배포, 프로비저닝 및 자동화에 대한 이해

1. 개념 정리

• 배포(Deployment)
  애플리케이션과 인프라를 특정 환경(개발, 테스트, 운영)에 올려 실행하는 과정
  → 예: Blue-Green, Rolling, Canary 배포 전략
• 프로비저닝(Provisioning)
  클라우드 자원(EC2, VPC, DB 등)을 생성·구성하여 애플리케이션이 실행될 기반을 마련하는 것
  → 예: EC2 인스턴스 생성, VPC 서브넷 설정
• 자동화(Automation)
  반복되는 작업(패치, 업데이트, 백업 등)을 스크립트·도구로 자동 실행하는 것
  → 예: Systems Manager Run Command, EventBridge 스케줄링

2. CloudFormation의 핵심 이점

• 인프라를 코드(IaC) 로 관리
  • JSON/YAML 템플릿으로 전체 아키텍처 정의
  • 버전 관리 및 검토 가능 → GitOps 적용
• 표준화와 재사용성
  • 동일한 아키텍처를 여러 리전·계정에 손쉽게 배포
• 업데이트 및 복구 용이
  • 스택 업데이트, 롤백 기능 → 장애 시 빠른 복원
• 자동화된 배포 파이프라인과 연계
  • CodePipeline + CloudFormation → CI/CD 자동화

3. Systems Manager와 운영 자동화

• Run Command: 여러 EC2 인스턴스에 동시에 명령 실행
• Patch Manager: 자동 패치 적용 및 관리
• Automation Runbook: 미리 정의된 운영 절차 자동 실행
• State Manager: 서버 설정 자동 유지

👉 장점: 수십·수백 대 서버 운영 시 인적 오류 최소화, 반복 작업 자동화

4. 자동화 사례

• 자동 패치 관리: 새벽 시간대에 OS 업데이트 예약
• 트래픽 비활성 시간 업데이트: 피크 시간대 피해서 배포
• 로그 집계 및 보관: 월 1회 자동 실행
• 자동 시작·중지: 비용 최적화를 위해 업무 시간 외 인스턴스 종료

5. 정리

• CloudFormation → 인프라 표준화 & 코드 기반 관리
• Systems Manager → 대규모 서버 운영 효율화
• 자동화 → 인적 오류 줄이고, 비용·운영 효율성 향상

💡 핵심 요약
배포·프로비저닝·자동화를 이해하면 AWS를 더 쉽고 안전하게 운영할 수 있고,
시험에서도 CloudFormation, Systems Manager, 배포 전략, 자동화 도구(EventBridge, Config)가 자주 출제됩니다.