Amazon SAA-C03: 관리, 운영, 관찰 가능성 및 비용 — 학습 가이드

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

다음의 일부입니다: AWS SAA-C03 — 완벽 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

CloudWatch: 지표, 네임스페이스, 대시보드 및 경보

CloudWatch는 AWS 서비스의 기본 텔레메트리 플레인이지만, 그 유용성은 서비스가 어떤 네임스페이스로 지표를 발행하는지 아는 것에 전적으로 달려 있습니다. 네임스페이스는 서비스 간의 충돌을 방지하는 지표 컨테이너입니다. AWS/Lambda는 함수의 Invocations, Errors, Throttles를 담고 있고, AWS/Events는 EventBridge 규칙의 Invocations, FailedInvocations, TriggeredRules, MatchedEvents를 담고 있습니다. 이 차이점은 이벤트 기반 파이프라인을 진단할 때 중요합니다. 만약 EventBridge 규칙이 API 대상을 통해 서드파티 API를 호출했는데 다운스트림에 트래픽이 도착하지 않는다면, 해답은 AWS/Lambda가 아니라 AWS/Events에 있습니다. TriggeredRules를 확인하면 규칙 패턴이 실제로 일치했는지 알 수 있고, Invocations/FailedInvocations는 대상 자체가 호출되었는지 그리고 호출이 성공했는지를 알려줍니다. Lambda가 더 익숙한 서비스라는 이유로 Lambda 지표를 검색하면, 규칙이 들어오는 이벤트와 전혀 일치하지 않았을 수 있다는 사실을 놓치는 것입니다.

지표 해상도는 비용에 영향을 미치는 리소스별 설정입니다. 기본 모니터링은 추가 비용 없이 5분마다 지표를 전송하며, 이는 장기 실행되는 안정적인 워크로드에는 충분하지만, 분 단위 해상도가 필요한 오토스케일링 반응, 스파이크 감지 또는 SLO 계산에는 너무 둔감합니다. 세부 모니터링은 이 주기를 1분(사용자 지정 고해상도 지표의 경우 1초)으로 단축하며, 스케일링 그룹이 신속하게 반응해야 할 때 활성화하는 기능입니다. 이는 유료 기능이므로 기본적으로 활성화되어 있지 않습니다.

모든 서비스는 기본적으로 기본 지표 세트를 전송하지만, 하이퍼바이저는 게스트 OS 내부를 볼 수 없습니다. CPUUtilization, NetworkIn, DiskReadOps는 EC2에서 별다른 노력 없이 볼 수 있지만, 메모리 사용률 및 파일 시스템 사용률(%) 같은 지표는 CloudWatch 에이전트가 필요하며, 이를 통해야만 해당 지표를 얻을 수 있습니다. 사용자 지정 애플리케이션 지표 또한 에이전트나 PutMetricData를 통해 수집됩니다.

경보는 노이즈와 신호를 구별해야 합니다. CPU > 50%에 대한 단일 경보는 정상적인 급증 상황에서도 계속 발생하여 운영자가 이를 무시하도록 만듭니다. 복합 경보는 자식 경보 상태들을 불리언(Boolean) 규칙 표현식과 결합하여, 실제로 조치가 필요한 조건이 충족될 때만 운영자에게 알림이 가도록 합니다. 일시적인 CPU 급증은 괜찮지만, 지속적인 CPU 압박과 함께 디스크 읽기 IOPS가 높아지는 것이 실제 문제를 나타내는 워크로드의 경우 다음과 같이 설정할 수 있습니다.

HighCPUAlarm:
  MetricName: CPUUtilization
  Threshold: 50
  EvaluationPeriods: 3
  Period: 60
  ComparisonOperator: GreaterThanThreshold

HighDiskReadAlarm:
  MetricName: DiskReadOps
  Threshold: 1000
  EvaluationPeriods: 3
  Period: 60

CompositeAlarm:
  AlarmRule: >
    ALARM("HighCPUAlarm") AND ALARM("HighDiskReadAlarm")
  AlarmActions:
    - arn:aws:sns:us-east-1:111122223333:ops-pager

자식 경보는 내부적으로 ALARM 상태로 전환될 수 있지만, 복합 경보만이 SNS를 트리거합니다. 두 개의 독립적인 경보가 모두 온콜 담당자에게 알림을 보내면 노이즈 문제가 다시 발생하며, 더 높은 임계값의 단일 경보는 상관관계를 놓치게 됩니다.

대시보드는 지표 위젯, 로그 위젯, 텍스트를 통합합니다. 두 가지 공유 패턴이 존재하며 이 둘을 혼동하는 것은 흔한 함정입니다. 뷰어가 이미 AWS 계정을 가지고 있다면, cloudwatch:GetDashboard 및 cloudwatch:GetMetricData 권한을 가진 IAM 자격 증명(또는 교차 계정 관측성을 통한 역할)을 부여하십시오. 뷰어가 AWS 계정이 없는 경우(예: 제품 관리자, 고객 이해관계자)에는 내장된 대시보드 공유 기능을 사용하십시오. 이 기능은 단일 이메일/암호, Cognito 사용자 풀 또는 퍼블릭 URL(거의 사용되지 않음)로 보호되는 공유 가능한 링크를 생성합니다. 스크린샷을 이메일로 보내는 것은 관측성이 아니며, AWS를 사용하지 않는 뷰어를 위해 콘솔 접근 권한이 있는 IAM 사용자를 생성하는 것은 최소 권한 원칙에 위배됩니다.

OAM을 사용한 교차 계정 관측성

수십 개의 계정을 오가며 지표를 보는 것은 불가능합니다. CloudWatch 교차 계정 관측성은 하나의 모니터링 계정을 중앙 싱크로 지정하고, 다수의 소스 계정들이 싱크 및 링크 리소스를 통해 지표, 로그, 추적을 공유하도록 합니다. 대규모로 가장 빠르게 배포하는 방법은 모니터링 계정의 CloudWatch 콘솔을 열고 싱크를 생성한 다음, 생성된 CloudFormation StackSet 템플릿을 조직 전체에 배포하여 각 소스 계정에 AWS::Oam::Link 리소스를 생성하는 것입니다.

Resources:
  ObservabilityLink:
    Type: AWS::Oam::Link
    Properties:
      LabelTemplate: "$AccountName"
      ResourceTypes:
        - AWS::CloudWatch::Metric
        - AWS::Logs::LogGroup
        - AWS::XRay::Trace
      SinkIdentifier: arn:aws:oam:us-east-1:111122223333:sink/abc-123

교차 계정 IAM 역할과 수동 쿼리로 이 문제를 해결하는 것이 기술적으로 가능은 하지만, 통합 대시보드, 교차 계정 Metrics Insights 쿼리, 또는 OAM 링크가 제공하는 자동 계정 이름 레이블 보강 기능은 얻을 수 없습니다.

Container Insights와 분산 추적

컨테이너화된 워크로드의 경우, Container Insights가 대표적인 CloudWatch 기능입니다. EKS에서는 CloudWatch 에이전트(또는 ADOT 컬렉터)를 DaemonSet으로 배포하고, 로그 전달을 위해 Fluent Bit를 함께 배포합니다. 에이전트는 cAdvisor와 kubelet 지표를 스크랩하여 ECS/ContainerInsights 및 ContainerInsights 네임스페이스(파드, 노드, 네임스페이스, 클러스터별 CPU/메모리)로 전송하고, Fluent Bit는 stdout/stderr를 /aws/containerinsights/<cluster>/application, /dataplane, /host와 같은 로그 그룹으로 전송합니다. 자체적으로 Prometheus/Grafana 스택을 구축할 수도 있지만, 관리형 패턴은 Container Insights와 Logs Insights를 함께 사용하는 것입니다.

fields @timestamp, kubernetes.pod_name, log
| filter kubernetes.namespace_name = "payments"
| filter log like /ERROR/
| stats count() by kubernetes.pod_name

지표는 무엇이 느린지 알려주고, 추적은 어디가 느린지 알려줍니다. X-Ray는 요청 경로의 각 서비스를 계측하여(instruments) X-Amzn-Trace-Id 헤더를 통해 추적 ID를 전파하고, 세그먼트와 하위 세그먼트를 X-Ray 데몬이나 ADOT 컬렉터로 보냅니다. 서비스 맵은 지연 시간, 오류 및 결함 비율과 함께 노드와 엣지를 시각화합니다. X-Ray가 없으면 p99 급증이 원인 분석 정보 없이 CloudWatch 지표로만 나타납니다.

from aws_xray_sdk.core import xray_recorder, patch_all
patch_all()  # instruments boto3, requests, sqlalchemy, etc.

@xray_recorder.capture('checkout')
def checkout(order_id): ...

Container Insights, X-Ray, CloudWatch Logs는 마이크로서비스 관측성을 위한 세 개의 다리입니다.

세 가지 로그 스트림: CloudTrail, VPC Flow Logs, CloudWatch Logs

모든 AWS 관측성(Observability) 전략은 세 가지 고유한 로그 스트림을 구분합니다: 관리 플레인 API 활동(CloudTrail), 데이터 플레인 네트워크 활동(VPC Flow Logs), 애플리케이션/OS 출력(CloudWatch Logs). 각 로그는 서로 다른 포렌식 질문에 답하며, 이를 혼동하는 것은 흔한 설계 오류입니다.

CloudTrail은 모든 AWS API 호출을 기록합니다. 누가(userIdentity), 어떤 IP에서, 어떤 리소스를 대상으로, 어떤 파라미터로 호출했으며, 성공했는지 여부를 기록합니다. 변경 사항을 특정 IAM 보안 주체(principal)와 안정적으로 연결할 수 있는 유일한 서비스입니다. API 활동을 찾기에 적합한 곳이 CloudWatch Logs라는 오해가 흔하지만, CloudWatch Logs는 보안 주체 수준의 감사 데이터가 아닌 애플리케이션/시스템 출력을 캡처합니다. CloudTrail은 실시간 지표 필터링을 위해 이벤트를 CloudWatch Logs로 전달할 수 있지만, 근본적인 감사 레코드는 CloudTrail에서 생성됩니다.

AWS Organizations 환경에서는 관리 계정(또는 위임된 관리자 계정)에서 생성된 **조직 추적(organization trail)**을 사용하는 것이 올바른 패턴입니다. 이 방식은 새로운 멤버 계정을 자동으로 등록하고 이벤트를 전용 로그 아카이브 계정의 단일 S3 버킷으로 스트리밍합니다.

CentralTrail:
  Type: AWS::CloudTrail::Trail
  Properties:
    IsOrganizationTrail: true
    IsMultiRegionTrail: true
    IncludeGlobalServiceEvents: true
    EnableLogFileValidation: true       # SHA-256 digest chain
    S3BucketName: org-cloudtrail-logs
    KMSKeyId: !Ref TrailKmsKey

대상 버킷에는 버전 관리, s3:PutObject를 CloudTrail 서비스 보안 주체로 제한하는 버킷 정책, SSE-KMS 암호화, 감사자를 위한 교차 계정 읽기 전용 접근, 그리고 WORM(Write-Once-Read-Many) 보장을 위한 S3 객체 잠금 규정 준수 모드가 이상적으로 필요합니다. 로그 파일 검증은 서명된 다이제스트 파일을 생성하여 변조를 탐지할 수 있게 합니다. 관리 이벤트는 기본적으로 90일 동안 활성화되며, 그 이상 보존하려면 추적이 필요합니다. 데이터 이벤트(S3 객체 수준, Lambda invoke, DynamoDB 아이템 수준)는 대량의 데이터와 비용 때문에 선택적으로 활성화해야 합니다. 임시 과거 데이터 쿼리를 위해서는 CloudTrail Lake나 추적 버킷에 대한 Athena를 사용하여 SQL을 실행할 수 있습니다.

SELECT userIdentity.arn, eventTime, requestParameters
FROM cloudtrail_logs
WHERE eventName = 'AuthorizeSecurityGroupIngress'
  AND eventTime BETWEEN '2024-01-08' AND '2024-01-12';

VPC Flow Logs는 VPC, 서브넷 또는 ENI에 대한 IP 트래픽 메타데이터를 캡처합니다. 5-튜플, 바이트, 패킷, 작업(ACCEPT/REJECT), 로그 상태 등을 포함하며 페이로드는 캡처하지 않습니다. 전달 대상은 CloudWatch Logs, S3 또는 Kinesis Data Firehose입니다. 아카이빙이 목적일 때는 S3를, 의심스러운 트래픽 패턴에 대해 경보를 발생시키는 지표 필터가 필요할 때는 CloudWatch Logs를, 거의 실시간 분석이 요구될 때는 Firehose를 선택하세요. NLB, ASG, 데이터베이스가 있는 VPC를 위한 표준적인 거의 실시간 파이프라인은 다음과 같습니다.

ENIs → VPC Flow Logs (delivery: Kinesis Data Firehose)
      → Firehose delivery stream (optional Lambda transform)
      → Amazon OpenSearch Service (index: vpc-flow-*)
      → OpenSearch Dashboards

CloudWatch Logs → 구독 필터 → Firehose → OpenSearch 경로의 대안도 작동하지만, 홉(hop)과 비용을 추가합니다. 요구 사항이 “거의 실시간"일 때 S3는 잘못된 선택입니다. Flow Logs를 전혀 활성화하지 않는 것이 가장 치명적인 함정입니다. 보안 사고 발생 시 소스/목적지/포트에 대한 기록이 없고 ACCEPT와 REJECT를 구분할 수 없게 됩니다. 동일한 논리가 ALB 액세스 로그에도 적용됩니다. 이는 선택적으로 활성화하며 S3로 전달되는데, 이 로그가 없으면 클라이언트 IP, 응답 코드, 대상 지연 시간, 사용자 에이전트에 대한 요청 수준의 기록이 남지 않습니다. Flow Logs(L3/L4)와 ALB 액세스 로그(L7)는 함께 트래픽 포렌식의 기준선을 구성합니다.

CloudWatch Logs는 CloudWatch 에이전트를 통해 애플리케이션, Lambda, OS 로그를 수신합니다. 이 서비스의 강점은 지표 필터에 있습니다. 지표 필터는 들어오는 이벤트를 스캔하여 패턴이 일치할 때마다 사용자 지정 지표를 증가시키고, 이를 통해 경보를 울리는 패턴 표현식입니다.

# Metric filter detecting inbound SSH sessions from Flow Logs
[version, account, eni, source, dest, srcport, destport=22,
 protocol=6, packets, bytes, start, end, action=ACCEPT, status]

3389 포트에 대한 병렬 필터는 RDP를 다룹니다. 경보 설정 없이 로그만 수집하는 것은 예방이 아닌 사후 포렌식 분석만 가능하게 합니다.

대규모 플릿의 경우, 로그 그룹에 구독 필터를 사용하여 일치하는 이벤트를 Kinesis Data Stream, Firehose 또는 Lambda로 거의 실시간으로 스트리밍하여 처리 파이프라인으로 분산시키는 것이 표준입니다.

{
  "filterPattern": "",
  "destinationArn": "arn:aws:firehose:us-east-1:111122223333:deliverystream/logs-to-os"
}

함정은 처리 파이프라인 없이 원시 로그를 스토리지로 보내는 것입니다. Glue 카탈로그, OpenSearch 인덱스, Athena 작업 그룹 없이 S3에 쏟아붓는 것은 로그가 존재하더라도 사고 발생 시 조치를 취할 수 없음을 의미합니다. 관측성은 단순히 영구 저장된 데이터(durable bytes)가 아니라 쿼리 가능한 인터페이스(query surface)를 필요로 합니다. 또한 로그 그룹에는 명시적인 보존 정책이 필요합니다. 기본값은 ‘만료 없음’으로, 조용히 비용을 낭비하게 됩니다. 로그 그룹은 수명 주기 규칙에 따라 장기 보관을 위해 S3로 내보낼 수 있습니다.

최소한의 오버헤드로 API 수준 이벤트 탐지하기

CreateImage, AuthorizeSecurityGroupIngress, StopLogging, MFA 없는 ConsoleLogin과 같은 중요한 컨트롤 플레인 이벤트의 경우, 오버헤드가 가장 적은 패턴은 CloudTrail → EventBridge 규칙 → SNS입니다. EventBridge는 모든 CloudTrail 관리 이벤트를 네이티브로 수신하며, 이벤트 패턴이 있는 규칙은 별도의 Lambda 연결 코드가 필요 없습니다.

{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com"],
    "eventName": ["CreateImage"]
  }
}

CloudTrail을 CloudWatch Logs로 보내고 지표 필터를 적용하는 방법도 작동하지만, 로그 그룹, 필터, 경보 및 비용이 추가되므로 “API X에 대해 경보 발생"이라는 단순한 요구 사항에는 운영 오버헤드 측면에서 불리합니다.

AWS Config: 지속적인 구성 및 드리프트

Config와 CloudTrail은 종종 혼동되지만, 근본적으로 다른 질문에 답합니다. CloudTrail은 누가 무엇을 호출했는지를 기록하고, Config는 리소스가 현재 어떤 모습이며 시간이 지남에 따라 어떻게 변경되었는지를 기록합니다. Config가 API 호출을 기록할 것이라고 기대하는 것은 전형적인 오답입니다. Config는 사용자가 PutBucketAcl을 호출했다는 사실을 알지 못합니다. 대신 14:03:22에 버킷의 ACL이 상태 A에서 상태 B로 변경되었다는 것을 압니다. 주체를 식별하려면 Config 변경 기록을 동일한 타임스탬프의 CloudTrail 이벤트와 연관시켜야 합니다(Config 콘솔에서 해당 이벤트로 딥링크를 제공합니다).

Config 규칙은 리소스를 원하는 상태와 비교하여 평가합니다. 관리형 규칙은 (restricted-ssh, s3-bucket-public-read-prohibited, required-tags, ec2-instance-no-public-ip, s3-bucket-versioning-enabled, desired-instance-type)와 같은 일반적인 검사를 다루며, 사용자 지정 규칙은 Lambda 함수로 실행되거나 CloudFormation Guard를 사용합니다. 규칙은 구성 변경 시 및 예약된 일정에 따라 평가를 수행하고, 리소스를 COMPLIANT 또는 NON_COMPLIANT로 표시하며, SSM Automation 문서를 통해 자동 수정을 트리거할 수 있습니다. 이는 “열린 SSH 감지” 또는 “과도한 크기의 인스턴스 유형 감지"에 대한 운영 오버헤드가 적은 해결책입니다. 규칙이 이미 존재하며 SNS 및 Security Hub와 기본적으로 통합되기 때문입니다. 주기적인 수동 감사, 예약된 스캔 또는 직접 만든 스캐너를 제안하는 것은 Config가 이미 제공하는 코드를 직접 구축하고 유지 관리해야 함을 의미합니다.

Config는 평가 결과를 SNS에 게시합니다. 자동 수정을 위해서는 EventBridge 규칙을 규정 준수 변경 이벤트에 연결하고 SSM Automation 문서나 Lambda를 호출합니다.

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

**집계기(Aggregator)**는 조직 전체의 규정 준수 상태를 통합하고, **적합성 팩(conformance pack)**은 PCI-DSS나 HIPAA와 같은 프레임워크를 위한 규칙들을 묶음으로 제공합니다. Workload Discovery on AWS(이전 AWS Perspective)는 Config를 기반으로 구축된 솔루션으로, 리소스 관계를 시각화하고 아키텍처 다이어그램을 생성합니다. 이는 기존 환경을 다이어그램으로 표현할 수 있는 인벤토리 도구를 묻는 질문에 대한 정석적인 답변입니다. Config는 필수 구성 요소입니다.

Security Hub, GuardDuty, Control Tower

Security Hub는 보안 결과를 집계하는 통합 창구입니다. GuardDuty(VPC Flow Logs, DNS, CloudTrail 기반 위협 탐지), Inspector(취약점 결과), Macie, IAM Access Analyzer, Config로부터 결과를 수집한 다음, 모든 것을 AWS Security Finding Format(ASFF)으로 정규화합니다. Security Hub를 활성화하면 보안 표준도 활성화됩니다. 특히 AWS Foundational Security Best Practices(FSBP) 표준이 대표적이며, 이는 내부적으로 Config 규칙에 매핑된 수십 개의 자동 검사(루트 MFA, 퍼블릭 S3, 암호화되지 않은 EBS, 다중 리전 CloudTrail)를 포함합니다.

조직 규모에서는 Security Hub(및 GuardDuty, Config)에 대한 위임된 관리자 계정을 지정하고, “새 계정 자동 활성화” 토글을 사용하여 전체 조직에 대해 서비스와 FSBP 표준을 활성화하며, Security Hub Findings - Imported 이벤트를 FSBP 표준 ARN과 Compliance.Status = FAILED로 필터링하여 EventBridge를 통해 SNS로 결과를 라우팅합니다. 직접 CloudTrail 파싱용 Lambda를 만들거나 계정별 대시보드를 구축하는 것은 Security Hub가 이미 처리해주는 운영 부담을 가중시킬 뿐입니다.

중요한 개념적 차이점: Security Hub는 탐지 및 집계 역할을 하며, 예방 기능은 없습니다. 드리프트를 예방하는 것은 잘 설계된 다중 계정 랜딩 존을 오케스트레이션하는 AWS Control Tower의 역할입니다. Account Factory는 기준이 되는 네트워킹, 로깅, IAM을 갖춘 새 계정을 프로비저닝합니다. 거버넌스는 세 가지 종류의 가드레일을 통해 구현됩니다.

사전 예방적 제어는 스택이 배포되기 전에 CloudFormation 템플릿을 평가하여, 예를 들어 암호화되지 않은 RDS 인스턴스의 생성을 거부합니다. 반면 Security Hub는 암호화되지 않은 인스턴스가 실행된 후에야 그 존재를 알려줄 뿐입니다. 요구 사항이 “예방"이라면 Control Tower를, “탐지, 알림 또는 집계"라면 Security Hub나 Config를 고려해야 합니다.

Macie: 민감한 데이터 검색

Macie는 ML과 패턴 매칭을 사용하여 S3 객체 내의 민감한 데이터(개인 식별 정보(PII), 금융 데이터, 자격 증명)를 식별합니다. 중요한 함정은 Macie가 데이터를 보호한다고 가정하는 것입니다. 그렇지 않습니다. Macie는 데이터를 검색하고 보고할 뿐입니다. 올바른 사용법은 다음과 같습니다.

1. 대상 계정/리전에서 Macie를 활성화합니다.
2. 예약된 일정에 따라 버킷/접두사/태그를 대상으로 하는 민감한 데이터 검색 작업을 구성합니다.
3. EventBridge(source: aws.macie)를 통해 결과를 SNS(알림용), Lambda(격리, 버킷 정책 강화 등 수정 조치용) 또는 Security Hub로 라우팅합니다.

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

검색 작업이 없으면 Macie는 아무런 결과도 생성하지 않습니다. EventBridge → SNS 연결이 없으면 검색 결과는 Macie 콘솔 안에 방치되어 아무도 모르게 됩니다.

Organizations, SCPs 및 태그 정책

AWS Organizations는 여기서 다루는 세 가지 관련 정책 유형을 제공합니다. **태그 정책(Tag policies)**은 허용되는 태그 키, 대소문자, 값을 정의합니다. 이 정책은 규정 미준수 사항을 보고하며, aws:ResourceTag/aws:RequestTag 조건과 결합하여 강제할 수 있습니다. **서비스 제어 정책(SCP)**은 멤버 보안 주체에게 부여할 수 있는 최대 권한을 정의합니다. **백업 정책(Backup policies)**과 **AI 서비스 옵트아웃 정책(AI opt-out policies)**이 나머지 정책들입니다.

중요한 사고 모델: SCP는 절대 권한을 부여하지 않습니다. SCP는 IAM(자격 증명 정책, 리소스 정책, 권한 경계)이 허용할 수 있는 작업에 대한 필터 역할을 합니다. 보안 주체는 IAM Allow를 가지고 있어야 하며, SCP가 해당 작업을 Deny하지 않아야 합니다(또는 Allow 목록에 해당 작업이 포함되어야 합니다). “그냥 SCP를 연결하면 된다"는 권한 문제에 대한 완전한 답이 될 수 없습니다. IAM Allow가 없으면 SCP 내용과 관계없이 보안 주체는 기본적으로 거부됩니다.

리소스 생성 시 태그를 필수로 요구하려면, 태그 정책을 다음과 같은 SCP와 결합해야 합니다:

{
  "Effect": "Deny",
  "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
  "Resource": "*",
  "Condition": {
    "Null": { "aws:RequestTag/CostCenter": "true" }
  }
}

태그 정책은 스키마를 선언하고, SCP는 태그 없는 생성을 거부하며, IAM 정책은 생성 작업을 허용합니다. 이 세 가지 모두가 필요합니다. AWS Config의 required-tags 규칙은 규정을 준수하지 않는 기존 리소스를 탐지하고 수정합니다.

Systems Manager Automation 및 패치

Systems Manager(SSM)는 다수의 EC2 및 하이브리드 노드 전반의 수명 주기 활동을 위한 운영의 중심축입니다. 패치 작업에서 가장 중요한 두 가지 구성 요소는 자동화 문서(Automation documents)(AWS API나 스크립트를 호출하는 선언적 YAML/JSON 런북)와 유지 관리 기간(Maintenance Windows)(변경 기간 내에 동시성 및 오류 임계값을 설정하여 태그 기반 대상 또는 리소스 그룹에 대해 해당 런북의 실행을 예약)입니다.

표준적인 패치 적용 흐름은 Patch Group 태그로 선택된 인스턴스에 대해 AWS-RunPatchBaseline(명령 문서)을 실행하는 것입니다. 이때 OS별 승인 규칙을 정의하는 패치 기준선(Patch Baseline)을 사용합니다. 로드 밸런서 뒤에 있는 인스턴스의 경우, AWS-RunPatchBaseline을 직접 실행하면 패치 도중 연결이 끊어집니다. 인스턴스가 대상 그룹에서 InService 상태로 남아 있기 때문입니다. 올바른 패턴은 **AWSEC2-PatchLoadBalancerInstance**를 사용하는 것이며, 이 자동화 문서는 다음을 수행합니다:

1. CLB 또는 ALB 대상 그룹에서 인스턴스를 등록 취소합니다.
2. 연결 드레이닝 / 등록 취소 지연 시간 동안 대기합니다.
3. 패치 기준선 스캔 및 설치 단계를 호출합니다.
4. 기준선에서 요구하는 경우 재부팅합니다.
5. 인스턴스를 다시 등록하고 대상 상태 확인 결과가 healthy로 돌아올 때까지 대기합니다.

두 가지 사전 요구 사항이 충족되지 않으면 “오류 발생” 실패 모드로 이어질 수 있습니다. 첫째, AutomationAssumeRole로 전달된 IAM 역할에는 표준 SSM 패치 권한 외에 elasticloadbalancing:DeregisterTargets, RegisterTargets, DescribeTargetHealth가 포함되어야 합니다. 둘째, 인스턴스는 **관리형 노드(managed node)**여야 합니다. 즉, SSM Agent가 실행 중이고 인스턴스 프로파일에 AmazonSSMManagedInstanceCore가 포함되어야 합니다. 이러한 조건이 없으면 등록 취소 호출이 실패하거나 SSM이 인스턴스를 인식할 수 없습니다.

schemaVersion: '0.3'
description: Patch instance behind ALB
assumeRole: '{{ AutomationAssumeRole }}'
parameters:
  InstanceId: { type: String }
  TargetGroupArn: { type: String }
  AutomationAssumeRole: { type: String }
mainSteps:
  - name: deregister
    action: aws:executeAwsApi
    inputs:
      Service: elbv2
      Api: DeregisterTargets
      TargetGroupArn: '{{ TargetGroupArn }}'

← 보안 · 모든 도메인 · 고가용성 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Amazon 찾아보기 →