2023. 3. 15. 17:19ㆍstudy
Machine Learning
Amazon Rekognition
• ML을 사용하여 이미지 및 비디오에서 객체, 사람, 텍스트, 장면 찾기
• 사용자 확인을 위한 얼굴 분석 및 얼굴 검색, 사람 수 계산
• "익숙한 얼굴"의 데이터베이스를 만들거나 유명인과 비교합니다
• 사용 사례:
• 라벨링
• 내용 조정
• 텍스트 탐지
• 얼굴 감지 및 분석(성별, 연령 범위, 감정...)
• 얼굴 검색 및 확인
• 연예인 인지도
• 경로 지정(예: 스포츠 게임 분석용)
Amazon Rekognition – Content Moderation
• 부적절하거나 원하지 않거나 모욕적인 내용 탐지(이미지 및 비디오)
• 소셜 미디어, 방송 미디어, 광고 및 전자 상거래 상황에서 사용하여 보다 안전한 사용자 환경을 만듭니다
• 플래그가 지정될 항목에 대한 최소 신뢰 임계값 설정
• Amazon Augmented AI(A2I)에서 수동 검토를 위해 중요한 콘텐츠 플래그 지정
• 규정 준수 지원
Amazon Transcribe
• 음성을 텍스트로 자동 변환
• 자동 음성 인식(ASR)이라는 딥 러닝 프로세스를 사용하여 음성을 텍스트로 빠르고 정확하게 변환합니다
• 수정 작업을 사용하여 개인 식별 가능 정보(PII) 자동 제거
• 다국어 오디오에 대한 자동 언어 식별 지원
• 사용 사례:
• 고객 서비스 호출을 기록하다
• 자막 및 자막 자동화
• 미디어 자산에 대한 메타데이터를 생성하여 전체 검색 가능 아카이브 생성
Amazon Polly
• 딥 러닝을 사용하여 텍스트를 실제와 같은 음성으로 전환
• 대화하는 응용프로그램을 만들 수 있습니다
Amazon Polly – Lexicon & SSML
• 발음 어휘를 사용하여 단어의 발음 사용자 정의
• 양식어: St3ph4ne => "스테판"
• 약어: AWS => "Amazon Web Services"
• 사전을 업로드하고 합성에 사용합니다음성 연산
• 일반 텍스트 또는 SSML(Speech Synthesis Markup Language)로 표시된 문서에서 음성 생성 - 더 많은 사용자 지정 가능
• 특정 단어 또는 구문 강조하기
• 음성 발음을 사용하여
• 숨쉬는 소리, 속삭이는 소리를 포함해서
• 뉴스 캐스터 말하기 스타일 사용
Amazon Polly를 사용하면 텍스트를 음성으로 변환할 수 있습니다. 이 서비스에는 두 가지 중요한 기능이 있습니다. 첫 번째 기능은 단어의 발음을 사용자 정의할 수 있는 ………………입니다(예: "Amazon EC2"의 발음을 "Amazon Elastic Compute Cloud"로 지정). 두 번째는 기능은 숨소리, 속삭임 등을 포함한 단어를 강조할 수 있는 ………………..입니다.
Amazon Translate
• 자연스럽고 정확한 언어 번역
• Amazon Translate를 사용하면 웹 사이트 및 응용 프로그램과 같은 콘텐츠를 해외 사용자를 위해 현지화할 수 있으며 대량의 텍스트를 효율적으로 쉽게 번역할 수 있습니다
Amazon Lex & Connect
• Amazon Lex: (알렉사를 작동시키는 동일한 기술)
• 음성을 텍스트로 변환하는 자동 음성 인식(ASR)
• 텍스트, 발신자의 의도를 인식하기 위한 자연어 이해
• 챗봇, 콜센터 봇 구축 지원
• Amazon 연결:
• 통화 수신, 연락처 흐름 생성, 클라우드 기반 가상 연락 센터
• 다른 CRM 시스템 또는 AWS와 통합 가능
• 선불 없이 기존 컨택센터 솔루션보다 80% 저렴
Amazon Comprehend
• 자연어 처리용 – NLP
• 완벽하게 관리되고 서버가 없는 서비스
• 기계 학습을 사용하여 텍스트에서 통찰력과 관계를 찾습니다
• 텍스트 언어
• 주요 구문, 장소, 사람, 브랜드 또는 이벤트를 추출합니다
• 텍스트가 얼마나 긍정적인지 또는 부정적인지 이해합니다
• 토큰화 및 음성 부분을 사용하여 텍스트 분석
• 주제별로 텍스트 파일 모음을 자동으로 구성
• 샘플 사용 사례:
• 고객과의 상호작용(데이터)을 분석하여 긍정적 또는 부정적 경험으로 이어지는 요소를 찾습니다
• 이해하기 쉬운 주제별로 기사를 작성하고 그룹화
Amazon Comprehend Medical
• Amazon Comprehend Medical은 구조화되지 않은 임상 텍스트에서 유용한 정보를 탐지하고 반환합니다:
• 의사의 소견
• 퇴원요약
• 테스트 결과
• 사례 노트
• NLP를 사용하여 PHI(보호된 상태 정보) 탐지 - 탐지PHI API
• 아마존 S3에 문서를 저장하거나, 키네시스 데이터 파이어호스로 실시간 데이터를 분석하거나, 아마존 트랜스크립을 사용하여 환자의 내러티브를 아마존 컴펜드 메디컬이 분석할 수 있는 텍스트로 전사할 수 있습니다.
Amazon SageMaker
• 개발자/데이터 과학자가 ML 모델을 구축할 수 있도록 완벽하게 관리되는 서비스
• 일반적으로 모든 프로세스를 한 곳에서 수행하고 서버를 프로비저닝하는 것이 어렵습니다
• 기계 학습 프로세스(간소화): 시험 점수 예측
Amazon Forecast
• ML을 사용하여 매우 정확한 예측을 제공하는 완벽한 관리 서비스
• 예: 레인코트의 향후 판매를 예측합니다
• 데이터 자체를 보는 것보다 50% 더 정확함
• 예측 시간을 몇 개월에서 몇 시간으로 단축
• 활용 사례: 제품 수요 계획, 재무 계획, 리소스 계획 등…
Amazon Kendra
• 기계 학습을 통해 완벽하게 관리되는 문서 검색 서비스
• 문서 내에서 답변 추출(텍스트, PDF, HTML, PowerPoint, MS Word, FAQ 등)
• 자연어 검색 기능
• 사용자 상호 작용/피드백을 통해 학습하여 선호하는 결과를 촉진합니다(증분 학습)
• 검색 결과를 수동으로 미세 조정할 수 있는 기능(데이터의 중요성, 신선도, 사용자 정의 등)
Amazon Personalize
• 완벽하게 관리되는 ML 서비스를 통해 실시간으로 맞춤형 권장 사항을 제공하는 애플리케이션 구축
• 예: 맞춤형 제품 추천/순위 조정, 맞춤형 직접 마케팅
• 예: 사용자가 정원 가꾸기 도구를 구입하고, 다음에 구입할 도구에 대한 권장 사항을 제공합니다
• Amazon.com에서 사용하는 것과 동일한 기술
• 기존 웹 사이트, 애플리케이션, SMS, 이메일 마케팅 시스템 등에 통합됩니다…
• 월 단위가 아닌 일 단위로 구현(ML 솔루션을 구축, 교육 및 구축할 필요 없음)
• 활용 사례: 소매점, 미디어 및 엔터테인먼트...
Amazon Textract
• AI 및 ML을 사용하여 스캔한 문서에서 텍스트, 필기 및 데이터를 자동으로 추출합니다
• 양식 및 테이블에서 데이터 추출
• 모든 유형의 문서 읽기 및 처리(PDF, 이미지 등)
• 사용 사례:
• 금융 서비스(예: 송장, 재무 보고서)
• 의료(예: 의료 기록, 보험 청구)
• 공공 부문(예: 세금 양식, 신분증 문서, 여권)
AWS Machine Learning - Summary
• Rekognition(인식): 얼굴 감지, 라벨링, 유명인 인식
• Transcribe(전사): 오디오에서 텍스트로(ex: 자막)
• Polly(폴리): 텍스트에서 오디오로
• 번역: 번역
• Lex: 대화형 봇 구축 – 챗봇
• Connect(연결): 클라우드 컨택 센터
• Comprehend(이해): 자연어 처리
• SageMaker(세이지메이커): 모든 개발자와 데이터 과학자를 위한 기계 학습
• Forecast(예측): 매우 정확한 예측 구축
• Kendra(켄드라): ML 기반 검색 엔진
• Personalize(개인 설정): 실시간 개인 설정 권장 사항
• Texttract: 문서에서 텍스트 및 데이터 탐지
AWS Monitoring, Audit and Performance
Amazon CloudWatch Metrics
• CloudWatch는 AWS의 모든 서비스에 대한 메트릭을 제공합니다
• 메트릭은 모니터링할 변수입니다(CPU 활용률, 네트워크 입력...)
• 메트릭이 네임스페이스에 속함
• 차원은 메트릭(인스턴스 ID, 환경 등)의 속성입니다.
• 메트릭당 최대 10차원
• 메트릭에 타임스탬프가 있음
• 메트릭의 CloudWatch 대시보드를 생성할 수 있습니다
• CloudWatch 사용자 지정 메트릭 생성 가능(예: RAM)
CloudWatch Metric Streams
• 실시간에 가까운 제공과 짧은 대기 시간으로 CloudWatch 메트릭을 원하는 대상으로 지속적으로 스트리밍할 수 있습니다.
• Amazon Kinesis Data Firehose(및 그 대상)
• 타사 서비스 공급자: Datadog, Dynatrace, New Resilt, Splunk, Sumo Logic...
• 메트릭 중 일부만 스트리밍하도록 메트릭을 필터링하는 옵션
CloudWatch Logs
• 로그 그룹: 임의 이름, 일반적으로 응용 프로그램을 나타냅니다
• 로그 스트림: 응용 프로그램/로그 파일/컨테이너 내 인스턴스
• 로그 만료 정책( 만료 안 함, 30일 등)을 정의할 수 있습니다..)
• CloudWatch 로그는 다음 위치로 로그를 전송할 수 있습니다:
• 아마존 S3(수출)
• 키네시스 데이터 스트림
• 키네시스 데이터 파이어호스
• AWS 람다
• 검색 열기
CloudWatch Logs - Sources
• SDK, CloudWatch 로그 에이전트, CloudWatch Unified 에이전트
• Elastic Beanstalk: 응용 프로그램의 로그 모음
• ECS: 컨테이너에서 수집
• AWS Lambda: 기능 로그
• VPC 흐름 로그: VPC 관련 로그
• API 게이트웨이
• 필터 기반 Cloudtrail
• Route53: DNS 쿼리 로그
CloudWatch Logs Metric Filter & Insights
• CloudWatch 로그에서 필터 식을 사용할 수 있음
• 예를 들어 로그에서 특정 IP 찾기
• 또는 로그에서 "ERROR" 발생 횟수를 계산합니다
• 메트릭 필터를 사용하여 CloudWatch 경보를 트리거할 수 있습니다
• CloudWatch Logs Insights를 사용하여 로그를 쿼리하고 CloudWatch 대시보드에 쿼리를 추가할 수 있습니다
CloudWatch Logs – S3 Export
• 로그 데이터를 내보낼 수 있게 되기까지 최대 12시간이 소요될 수 있습니다
• API 호출은 CreateExportTask입니다
• 실시간 또는 실시간이 아닌 로그 구독을 대신 사용하십시오
CloudWatch Logs Subscriptions
•
CloudWatch Logs Aggregation Multi-Account & Multi Region
•
CloudWatch Logs for EC2
• 기본적으로 EC2 시스템의 로그는 CloudWatch로 전송되지 않습니다
• EC2에서 CloudWatch 에이전트를 실행하여 원하는 로그 파일을 푸시해야 합니다
• IAM 권한이 올바른지 확인하십시오
• CloudWatch 로그 에이전트는 사내에서도 설정할 수 있습니다
CloudWatch Logs Agent & Unified Agent
• 가상 서버의 경우(EC2 인스턴스, 사내 서버 등)
• CloudWatch 로그 에이전트
• 에이전트의 이전 버전
• CloudWatch 로그로만 전송할 수 있음
• CloudWatch Unified 에이전트
• RAM, 프로세스 등과 같은 추가 시스템 레벨 메트릭 수집...
• CloudWatch 로그로 보낼 로그 수집
• SSM 매개 변수 저장소를 사용한 중앙 집중식 구성
CloudWatch Unified Agent – Metrics
• Linux 서버/EC2 인스턴스에서 직접 수집됨
• CPU(액티브, 게스트, 유휴, 시스템, 사용자, 도용)
• Disk metrics(디스크 메트릭)(사용 가능, 사용됨, 총계), 디스크 IO(쓰기, 읽기, 바이트, IOPS)
• RAM(사용 가능, 비활성, 사용됨, 총, 캐시됨)
• Netstat(TCP 및 UDP 연결 수, Net 패킷, 바이트)
• 프로세스(총, 비활성, 차단, 유휴, 실행, 절전)
• Swap Spqce(사용 가능, 사용됨, 사용됨 %)
• Reminder(알림): EC2에 대한 기본 제공 메트릭 – 디스크, CPU, 네트워크(고급)
MCloudWatch Alarms
• 경보는 메트릭에 대한 알림을 트리거하는 데 사용됩니다
• 다양한 옵션(샘플링, %, 최대값, 최소값 등)
• 경보 상태:
• OK
• INSUFFICIENT_DATA
• Alarm
• 기간:
• 메트릭을 평가하는 시간(초)
• 고해상도 사용자 지정 메트릭: 10초, 30초 또는 60초의 배수
CloudWatch Alarm Targets
• EC2 인스턴스 중지, 종료, 재부팅 또는 복구
• 트리거 자동 스케일링 작업
• SNS로 알림 보내기(거의 모든 작업을 수행할 수 있음)
CloudWatch Alarms – Composite Alarms
• CloudWatch 경보가 단일 메트릭을 기반으로 함
• 복합 경보가 다른 여러 경보의 상태를 모니터링하고 있습니다
• AND 및 OR 조건
• 복잡한 복합 경보를 생성하여 "경보 소음"을 줄이는 데 도움이 됩니다
EC2 Instance Recovery
• Status Check:
• Instance status = check the EC2 VM
• System status = check the underlying hardware
CloudWatch Alarm: good to know
• CloudWatch 로그 메트릭 필터를 기반으로 경보를 생성할 수 있습니다
• 경보 및 알림을 테스트하려면 CLI를 사용하여 경보 상태를 경보로 설정합니다(이벤트 패턴에 반응.)
(이벤트가 발생하면 SNS 주제로 메시지를 보내고 이메일 알림을 받을 수 잇음. -> 계정보안 기능 좋음.)
aws cloudwatch set-alarm-state --alarm-name "My alarm" --state-value ALARM --state-reason "testing purpose"
Amazon EventBridge (formerly CloudWatch Events)
• Schedule(예약): Cron 작업(스크립트 예약가능.)
• 이벤트 패턴: 서비스에서 수행할 작업에 대응하는 이벤트 규칙
• 람다 기능 트리거, SQS/SNS 메시지 전송...
Amazon EventBridge Rules
• 리소스 기반 정책을 사용하여 다른 AWS 계정에서 이벤트 버스에 액세스할 수 있음
• 이벤트 버스로 전송된 이벤트(모두/필터)를 아카이브할 수 있습니다(무제한 또는 기간 설정)
• 아카이브된 이벤트 재생 기능
Amazon EventBridge로 전송되는 이벤트에
필터를 설정할 수 있는데요
예를 들어 Amazon S3에 있는 특정 버킷의 이벤트만 필터링하도록 하면 Amazon EventBridge는 이벤트의 세부 사항을 나타내는 JSON 문서를 생성할 겁니다
어떤 인스턴스가 이 ID로 실행되는지 등을 나타내고 시간, IP 등의 정보가 담깁니다 JSON 문서 생성이 끝나면 이벤트들을 다양한 대상으로 전송할 수 있고 유용한 통합 기능을 사용할 수 있습니다
Amazon EventBridge
• EventBridge는 버스의 이벤트를 분석하고 스키마를 추론할 수 있습니다
• 스키마 레지스트리를 사용하면 이벤트 버스에서 데이터가 어떻게 구성되는지 미리 알 수 있는 프로그램에 대한 코드를 생성할 수 있습니다
• • Ability to replay archived events(스키마를 버전화할 수 있습니다)
Amazon EventBridge – Schema Registry
• EventBridge는 버스의 이벤트를 분석하고 스키마를 추론할 수 있습니다
• 스키마 레지스트리를 사용하면 이벤트 버스에서 데이터가 어떻게 구성되는지 미리 알 수 있는 프로그램에 대한 코드를 생성할 수 있습니다
• 스키마를 버전화할 수 있습니다
Amazon EventBridge – Resource-based Policy
• 특정 이벤트 버스에 대한 사용 권한 관리
• 예: 다른 AWS 계정 또는 AWS 영역의 이벤트 허용/거부
• 사용 사례: 단일 AWS 계정 또는 AWS 지역에 있는 AWS 조직의 모든 이벤트 집계
CloudWatch Container Insights
• 컨테이너에서 메트릭 및 로그 수집, 집계, 요약
• 다음의 컨테이너에 사용할 수…
• Amazon ECS(Amazon Elastic Container Service)
• 아마존 엘라스틱 쿠버네티스 서비스(Amazon EKS)
• EC2의 쿠버네티스 플랫폼
• Fargate(ECS 및 EKS 모두)
• Amazon EKS 및 Kubernetes에서 CloudWatch Insights는 컨테이너형 버전의 CloudWatch Agent를 사용하여 컨테이너를 검색합니다
한 DevOps 엔지니어가 회사에서 근무하며 AWS에서 인프라와 리소스를 관리하고 있습니다. 회사의 주요 애플리케이션에 대한 트래픽이 갑자기 폭증했는데, 이는 시기적으로 봤을 때 일반적이지 않은 현상입니다. 애플리케이션은 프라이빗 서브넷에 있는 몇 개의 EC2 인스턴스에서 호스팅되고, 퍼블릭 서브넷에 있는 애플리케이션 로드 밸런서에 의해 배포됩니다. DevOps 엔지니어는 이것이 정상적인 트래픽 증가인지 공격인지 확인하기 위하여 서브넷의 VPC 흐름 로그(Flow Logs)를 활성화하고 CloudWatch 로그 그룹에 로그를 저장했습니다. DevOps 엔지니어는 이 로그를 분석하여 웹 사이트에 요청을 보내는 상위 IP 주소를 찾아 공격 의도가 있는지 확인하려고 합니다. 다음 중 DevOps 엔지니어가 로그를 분석하는 데 도움을 받을 수 있는 것은 무엇입니까?
Amazon EventBridge – Schema Registry
• EventBridge는 버스의 이벤트를 분석하고 스키마를 추론할 수 있습니다
• 스키마 레지스트리를 사용하면 이벤트 버스에서 데이터가 어떻게 구성되는지 미리 알 수 있는 프로그램에 대한 코드를 생성할 수 있습니다
• 스키마를 버전화할 수 있습니다
Amazon EventBridge – Resource-based Policy
• 특정 이벤트 버스에 대한 사용 권한 관리
• 예: 다른 AWS 계정 또는 AWS 영역의 이벤트 허용/거부
• 사용 사례: 단일 AWS 계정 또는 AWS 지역에 있는 AWS 조직의 모든 이벤트 집계
CloudWatch Container Insights
• 컨테이너에서 메트릭 및 로그 수집, 집계, 요약
• 다음의 컨테이너에 사용할 수…
• Amazon ECS(Amazon Elastic Container Service)
• 아마존 엘라스틱 쿠버네티스 서비스(Amazon EKS)
• EC2의 쿠버네티스 플랫폼
• Fargate(ECS 및 EKS 모두)
• Amazon EKS 및 Kubernetes에서 CloudWatch Insights는 컨테이너형 버전의 CloudWatch Agent를 사용하여 컨테이너를 검색합니다
CloudWatch Lambda Insights
• AWS Lambda에서 실행되는 서버리스 애플리케이션을 위한 모니터링 및 문제 해결 솔루션
• CPU 시간, 메모리, 디스크 및 네트워크를 포함한 시스템 레벨 메트릭을 수집, 집계 및 요약합니다
• 콜드 스타트 및 람다 작업자 종료와 같은 진단 정보를 수집, 집계 및 요약합니다
• 람다 인사이트는 람다 레이어로 제공됩니다
CloudWatch Contributor Insights
• 로그 데이터를 분석하고 기여자 데이터를 표시하는 시계열을 만듭니다.
• 상위 N개 기여자에 대한 메트릭 보기
• 고유한 기여자의 총 수 및 사용.
• 이를 통해 최고 수준의 대화자를 찾고 시스템 성능에 영향을 미치는 사용자 또는 사용자를 파악할 수 있습니다.
• 모든 AWS 생성 로그(VPC, DNS 등)에 대해 작동합니다..)
• 예를 들어 잘못된 호스트를 찾거나, 가장 무거운 네트워크 사용자를 식별하거나, 가장 많은 오류를 생성하는 URL을 찾을 수 있습니다.
• 처음부터 규칙을 구축하거나 AWS가 만든 샘플 규칙을 사용하여 CloudWatch 로그를 활용할 수 있습니다
• CloudWatch는 다른 AWS 서비스의 메트릭을 분석하는 데 사용할 수 있는 기본 제공 규칙도 제공합니다.
CloudWatch Application Insights
• 모니터링되는 애플리케이션의 잠재적인 문제를 보여주는 자동화된 대시보드를 제공하여 진행 중인 문제를 격리합니다
• 애플리케이션은 선택된 기술로만 Amazon EC2 인스턴스에서 실행됩니다(Java, ).NET, Microsoft IIS 웹 서버, 데이터베이스...)
• 또한 Amazon EBS, RDS, ELB, ASG, 람다, SQS, DynamoDB, S3 버킷, ECS, EKS, SNS, API Gateway 등의 다른 AWS 리소스를 사용할 수 있습니다…
• 세이지메이커에 의해 구동됨
• 애플리케이션 상태에 대한 가시성 향상으로 애플리케이션 문제 해결 및 복구에 소요되는 시간 단축
• 결과 및 경고가 Amazon EventBridge 및 SSM OpsCenter로 전송됨
CloudWatch Insights and Operational Visibility
• CloudWatch 컨테이너 통찰력
• EC2의 ECS, EKS, 쿠버네티스, 파게이트, 쿠버네티스의 에이전트가 필요합니다
• 메트릭 및 로그
• CloudWatch 람다 통찰력
• 서버리스 애플리케이션 문제 해결을 위한 세부 메트릭
• CloudWatch 기여자 통찰력
• CloudWatch 로그를 통해 "Top-N" 기여자 찾기
• CloudWatch 애플리케이션 통찰력
• 애플리케이션 및 관련 AWS 서비스의 문제를 해결하는 자동 대시보드
AWS CloudTrail
• AWS 계정에 대한 거버넌스, 규정 준수 및 감사 제공
• CloudTrail은 기본적으로 활성화되어 있습니다!
• 다음을 통해 AWS 계정 내에서 수행된 이벤트/API 호출 기록을 가져옵니다:
• 콘솔
• SDK
• CLI
• AWS 서비스
• CloudTrail의 로그를 CloudWatch 로그 또는 S3에 넣을 수 있습니다
• 추적을 모든 영역(기본값) 또는 단일 영역에 적용할 수 있습니다.
• AWS에서 리소스가 삭제된 경우 먼저 CloudTrail을 조사하십시오!
CloudTrail Diagram
•
CloudTrail Events
• 관리 이벤트:
• AWS 계정의 리소스에 대해 수행되는 작업
• 예:
• 보안 구성(IAM AttachRolePolicy)
• 라우팅 데이터에 대한 규칙 구성(Amazon EC2 CreateSubnet)
• 로깅 설정(AWS CloudTrail CreateTrail)
• 기본적으로 추적은 관리 이벤트를 기록하도록 구성됩니다.
• 읽기 이벤트(리소스를 수정하지 않음)와 쓰기 이벤트(리소스를 수정할 수 있음)를 구분할 수 있습니다
• 데이터 이벤트:
• 기본적으로 데이터 이벤트는 기록되지 않습니다(대량 작업으로 인해)
• Amazon S3 개체 수준 작업(예: GetObject, DeleteObject, PutObject): 읽기 이벤트와 쓰기 이벤트를 구분할 수 있습니다
• AWS 람다 함수 실행 활동(Invoke API)
• 클라우드 추적 통찰력 이벤트:
• 다음 슬라이드 J 참조
CloudTrail Insights
• CloudTrail Insights를 사용하여 귀하의 계정에서 비정상적인 활동을 탐지할 수 있습니다:
• 부정확한 리소스 프로비저닝
• 서비스 제한에 도달
• AWS IAM 작업의 버스트
• 정기적인 유지보수 활동의 격차
• CloudTrail Insights는 정상적인 관리 이벤트를 분석하여 기준 생성
• 그런 다음 쓰기 이벤트를 지속적으로 분석하여 비정상적인 패턴을 탐지합니다
• CloudTrail 콘솔에 이상 징후가 표시됨
• 이벤트가 Amazon S3로 전송됨
• EventBridge 이벤트가 생성됨(자동화 필요)
CloudTrail Events Retention
• 이벤트는 CloudTrail에 90일 동안 저장됩니다
• 이 기간을 초과하는 이벤트를 유지하려면 이벤트를 S3에 기록하고 Athena를 사용하십시오
Amazon EventBridge – Intercept API Calls
•
AWS Config
• AWS 리소스의 컴플라이언스 감사 및 기록 지원
• 시간 경과에 따른 구성 및 변경 사항 기록 지원
• AWS Config에서 해결할 수 있는 질문:
• 보안 그룹에 대한 SSH 액세스가 제한되지 않습니까?
• 제 양동이에 공용 액세스 권한이 있나요?
• 시간이 지남에 따라 ALB 구성이 어떻게 변경되었습니까?
• 변경 사항에 대한 알림(SNS 알림)을 수신할 수 있습니다
• AWS 구성은 지역별 서비스입니다
• 지역 및 계정 전반에 걸쳐 집계 가능
• S3에 구성 데이터 저장 가능성(아테나 분석)
Config Rules
• AWS 관리 구성 규칙 사용 가능(75개 이상)
• 사용자 지정 구성 규칙을 만들 수 있음(AWS 람다에서 정의해야 함)
• 예: 각 EBS 디스크가 gp2 유형인지 여부를 평가합니다
• 예: 각 EC2 인스턴스가 t2.micro인지 평가합니다
• 규칙을 평가/트리거할 수 있습니다:
• 각 구성 변경에 대해
• And/Or: 일정한 시간 간격으로
• AWS 구성 규칙으로 인해 작업이 발생하지 않음(거부 없음)
• 가격: 무료 계층 없음, 지역별 구성 항목당 $0.003, 지역별 구성 규칙 평가당 $0.001
84번 포트가 취약한 것으로 알려진 OS를 지닌 EC2 인스턴스 플릿에서 웹사이트를 실행하고 있습니다. 84번 포트가 노출된 경우에는 EC2 인스턴스를 지속적으로 모니터링하려 합니다. 이 경우, 어떻게 해야 할까요?
AWS Config Resource
• 시간 경과에 따른 리소스 규정 준수 보기
• 시간 경과에 따른 리소스 구성 보기
• 시간 경과에 따른 리소스의 CloudTrail API 호출 보기
Config Rules – Remediations
• SSM Automation Documents를 사용하여 비준수 리소스의 교정 자동화
• AWS 관리 자동화 문서 사용 또는 사용자 정의 자동화 문서 생성
• 팁: 람다 기능을 호출하는 사용자 정의 자동화 문서를 만들 수 있습니다
• 자동 업데이트 적용 후에도 리소스가 여전히 규정을 준수하지 않는 경우 업데이트 적용 재시도를 설정할 수 있습니다
Config Rules – Notifications
• AWS 리소스가 규정을 준수하지 않을 경우 EventBridge를 사용하여 알림 트리거
• 구성 변경 사항 및 규정 준수 상태 알림을 SNS로 전송하는 기능(모든 이벤트 – 클라이언트 측에서 SNS 필터링 또는 필터 사용)
CloudWatch vs CloudTrail vs Config
• CloudWatch
• 성능 모니터링(메트릭, CPU, 네트워크 등) 및 대시보드
• 이벤트 및 알림
• 로그 집계 및 분석
• CloudTrail
• 모든 사용자가 계정 내에서 호출한 API 기록
• 특정 리소스에 대한 추적을 정의할 수 있음
• 글로벌 서비스
• Config
• 구성 변경 기록
• 규정 준수 규칙을 기준으로 리소스 평가
• 변경사항 및 규정 준수 일정 확인
For an Elastic Load Balancer
• CloudWatch:
• 수신 연결 메트릭 모니터링
• 시간 경과에 따른 오류 코드를 %로 시각화
• 대시보드를 만들어 로드 밸런서 성능 파악
• Config:
• 로드 밸런서에 대한 Security Group 규칙 추적
• 로드 밸런서에 대한 구성 변경 추적
• SSL 인증서가 항상 로드 밸런서에 할당되었는지 확인하십시오(준수성)
• Cloudtrail:
• API 호출을 사용하여 로드 밸런서를 변경한 사용자 추적
Advanced Identity in AWS
Organizational Units (OU) - Examples
•
AWS Organizations
• 글로벌 서비스
• 여러 AWS 계정을 관리할 수 있습니다
• 주 계정은 관리 계정입니다
• 다른 계정은 회원 계정입니다
• 구성원 계정은 하나의 조직에만 속할 수 있습니다
• 모든 계정에 대한 통합 청구 - 단일 결제 방법
• 집계된 사용량으로 인한 가격 이점(EC2, S3의 경우 볼륨 할인...)
• 예약된 인스턴스 공유 및 계정 간 절감 계획 할인
• API를 사용하여 AWS 계정 생성 자동화
• 루트 조직 단위(Organizational Unit) 안에 부분 OU(개발, 관리 등) 생성해서 관리
• 장점
• 다중 계정 대 단일 계정 다중 VPC
• 청구 목적으로 태그 표준 사용
• 모든 계정에서 CloudTrail 사용, 중앙 S3 계정으로 로그 전송
• CloudWatch 로그를 중앙 로깅 계정으로 전송
• 관리 목적을 위한 상호 계정 역할 설정
• 보안: 서비스 제어 정책(SCP)
• 사용자 및 역할을 제한하기 위해 OU 또는 계정에 적용되는 IAM 정책
• 관리 계정에는 적용되지 않습니다(전체 관리 권한)
• 명시적 허용(IAM과 같이 기본적으로 어떤 것도 허용하지 않음)이 있어야 합니다
AWS Resource Access Manager(RAM)는 AWS 계정이나 AWS 조직 내에서 AWS 리소스를 쉽고 안전하게 공유할 수 있는 서비스입니다. AWS Transit Gateway, 서브넷, AWS License Manager 구성 및 Amazon Route 53 Resolver 규칙 리소스를 RAM과 공유할 수 있습니다. RAM을 사용하면 여러 계정에서 중복 리소스를 생성할 필요가 없으므로 소유하고 있는 모든 단일 계정에서 해당 리소스를 관리하는 운영 오버헤드가 줄어듭니다. 다중 계정 환경에서 중앙에서 리소스를 생성하고 RAM을 사용하여 리소스 공유 생성, 리소스 지정 및 계정 지정이라는 간단한 세 단계를 통해 계정 간에 해당 리소스를 공유할 수 있습니다. RAM은 추가 비용 없이 사용할 수 있습니다.
올바른 솔루션은 RAM을 사용하여 VPC 내에서 서브넷을 공유하는 것입니다. 이렇게 하면 모든 EC2 인스턴스가 동일한 VPC에 배포되고(다른 계정에서) 서로 쉽게 통신할 수 있습니다.
SCP Hierarchy
• ex)
루트 OU에는 FullAWSAccess SCP 적용.
관리 계정에는 DenyAccessAthena SCP 적용.
OU 에는 DenyRedshift SCP
등등
SCP Examples Blocklist and Allowlist strategies
•
IAM Conditions
•
IAM for S3
•
Resource Policies & aws:PrincipalOrgID
• aws:PrincipalOrgID는 모든 리소스 정책에서 사용하여 AWS 조직의 구성원인 계정에 대한 액세스를 제한할 수 있습니다
IAM Roles vs Resource Based Policies
• 교차 계정:
• 리소스에 리소스 기반 정책 연결(예: S3 버킷 정책)
• 또는 역할을 프록시로 사용
IAM Roles vs Resource-Based Policies
• • 교차 계정: 역할(사용자, 애플리케이션 또는 서비스)을 가정할 때 원래 사용 권한을 포기하고 역할에 할당된 사용 권한을 갖습니다
• 리소스 기반 정책을 사용할 때 주체는 사용 권한을 포기할 필요가 없습니다
• 예: A 계정의 사용자는 A 계정의 DynamoDB 테이블을 스캔하여 B 계정의 S3 버킷에 덤프해야 합니다.
• 지원 대상: Amazon S3 버킷, SNS 주제, SQS 대기열 등…
• 리소스에 리소스 기반 정책 연결(예: S3 버킷 정책)
• 또는 역할을 프록시로 사
Amazon EventBridge – Security
• 규칙이 실행될 때 대상에 대한 사용 권한이 필요함
• 리소스 기반 정책: 람다, SNS, SQS, CloudWatch 로그, API 게이트웨이...
• IAM 역할: Kinesis 스트림, 시스템 매니저 실행 명령, ECS 작업...
IAM Permission Boundaries
• IAM 권한 경계는 사용자 및 역할(그룹이 아님)에 대해 지원됩니다
• 관리되는 정책을 사용하여 IAM 엔티티가 얻을 수 있는 최대 권한을 설정하는 고급 기능입니다
IAM Permission Boundaries
• AWS 조직 SCP 조합으로 사용 가능
https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html
사용 사례
• 권한 범위 내에서 관리자가 아닌 사용자에게 책임 위임(예: 새 IAM 사용자
• 개발자가 정책을 자체 정의하고 자신의 권한을 관리할 수 있도록 허용하는 동시에 자신의 권한을 "관리"할 수 없도록 합니다(= 스스로 관리)
• 조직 및 SCP를 사용하는 전체 계정 대신 특정 사용자를 제한하는 데 유용합니다
IAM Policy Evaluation Logic
•
Example IAM Policy
• Can you perform sqs:CreateQueue? (수행하다)
• Can you perform sqs:DeleteQueue?
• Can you perform ec2:DescribeInstances?
AWS IAM Identity Center (successor to AWS Single Sign-On)
• 모든 사용자를 위한 단일 로그인(단일 로그인)
• AWS 조직의 AWS 계정
• 비즈니스 클라우드 애플리케이션(예: Salesforce, Box, Microsoft 365 등)
• SAML 2.0 지원 애플리케이션
• EC2 윈도우즈 인스턴스
• ID 제공자
• IAM ID 센터에 내장된 ID 저장소
• 타사: Active Directory(AD), OneLogin, Okta...
AWS IAM Identity Center – Login Flow
•
AWS IAM Identity Center
•
IAM Identity Center
•
AWS IAM Identity Center Fine-grained Permissions and Assignments
• • Multi-Account Permissions(다중 계정 권한)
• AWS 조직에서 AWS 계정 간 액세스 관리
• 권한 세트 – AWS 액세스를 정의하기 위해 사용자 및 그룹에 할당된 하나 이상의 IAM 정책 모음
• Application Assignments(응용 프로그램 할당)
• 많은 SAML 2.0 비즈니스 애플리케이션(Salesforce, Box, Microsoft 365 등)에 대한 SSO 액세스
• 필요한 URL, 인증서 및 메타데이터 제공
• Attribute-Based Access Control(ABAC)(속성 기반 액세스 제어)
• IAM Identity Center Identity Store에 저장된 사용자 속성을 기반으로 세분화된 권한
• 예: 비용 센터, 제목, 로케일 등…
• 사용 사례: 사용 권한을 한 번 정의한 다음 속성을 변경하여 AWS 액세스 수정
What is Microsoft Active Directory (AD)?
• AD 도메인 서비스가 있는 모든 윈도우즈 서버에서 발견됨
• 개체(objects) 데이터베이스: 사용자 계정, 컴퓨터, 프린터, 파일 공유, 보안 그룹
• 중앙 집중식 보안 관리, 계정 생성, 권한 할당
• 개체가 트리에 정리되어 있습니다
• 나무들의 무리는 숲이다
AWS Directory Services
• AWS 관리 마이크로소프트 AD
• AWS에서 자체 AD 생성, 로컬 사용자 관리, MFA 지원
• on-premises AD와의 "신뢰" 연결을 설정합니다
• AD 커넥터
• on-premises AD로 리디렉션되는 디렉토리 게이트웨이(프록시), MFA 지원
• 사용자가 사내 AD에서 관리
• 단순 AD
• AWS의 AD 호환 관리 디렉터리
• on-premises AD와 결합할 수 없습니다
IAM Identity Center – Active Directory Setup
• AWS Managed Microsoft AD(디렉토리 서비스)에 연결
• 기본적인 통합
• (on-premises에 있을 경우. )자체 관리 디렉토리에 연결
• AWS Managed Microsoft AD를 사용하여 양방향 신뢰 관계 생성
• AD 커넥터 만들기
AWS Control Tower
• 모범 사례를 기반으로 안전하고 규정을 준수하는 다중 계정 AWS 환경을 손쉽게 설정 및 관리할 수 있는 방법
• AWS Control Tower에서 AWS 조직을 사용하여 계정 생성
• 이점:
• 클릭 몇 번으로 환경 설정 자동화
• 가드레일을 사용하여 지속적인 정책 관리 자동화
• 정책 위반 탐지 및 업데이트 적용
• 대화형 대시보드를 통해 규정 준수 모니터링
AWS Control Tower – Guardrails
• Control Tower 환경(AWS 계정)에 지속적인 거버넌스 제공
• Preventive Guardrail – SCP 사용(예: 모든 계정에서 지역 제한)
• Detective Guardrail – AWS Config 사용(예: 태그 없는 리소스 식별)
AWS Security & Encryption
Why encryption? Encryption in flight (SSL)
• 데이터는 전송하기 전에 암호화되고 수신 후 암호 해독됩니다
• 암호화(HTTPS)에 도움이 되는 SSL 인증서
• 비행 중 암호화는 MITM(중간 공격자)이 발생하지 않도록 보장합니다
Why encryption? Server side encryption at rest
• • 데이터가 서버에 의해 수신된 후 암호화됨
• 데이터가 전송되기 전에 암호가 해독됨
• 키(일반적으로 데이터 키) 덕분에 암호화된 형태로 저장됩니다
• 암호화/암호 해독 키는 어딘가에서 관리되어야 하며 서버가 해당 키에 액세스할 수 있어야 합니다
Why encryption? Client side encryption
• 데이터가 클라이언트에 의해 암호화되고 서버에 의해 암호 해독되지 않음
• 데이터가 수신 클라이언트에 의해 해독됩니다
• 서버에서 데이터의 암호를 해독할 수 없습니다
• 봉투 암호화를 활용할 수 있음
AWS KMS (Key Management Service)
• AWS 서비스에 대한 "암호화"를 들을 때마다 KMS일 가능성이 높습니다
• AWS가 암호화 키를 관리합니다
• 인증을 위해 IAM과 완벽하게 통합됨
• 데이터 액세스를 쉽게 제어할 수 있는 방법
• CloudTrail을 사용하여 KMS Key 사용 감사 가능
• 대부분의 AWS 서비스(EBS, S3, RDS, SSM…)에 완벽하게 통합
• 절대로 비밀을 평문, 특히 코드에 저장하지 마세요!
• KMS 키 암호화는 API 호출(SDK, CLI)을 통해서도 사용할 수 있습니다
• 암호화된 비밀을 코드/환경 변수에 저장할 수 있음
KMS Keys Types
• KMS 키는 KMS 고객 마스터 키의 새 이름입니다
• Symmetric(AES-256 키)
• 암호화 및 암호 해독에 사용되는 단일 암호화 키
• KMS와 통합된 AWS 서비스는 Symmetric CMK를 사용합니다
• 암호화되지 않은 KMS 키에 액세스할 수 없습니다(사용하려면 KMS API를 호출해야 함)
• Asymmetric(비대칭)(RSA 및 ECC 키 쌍)
• 공용(암호화) 및 개인 키(암호 해독) 쌍
• 암호화/암호 해독 또는 서명/확인 작업에 사용됩니다
• 공개 키는 다운로드할 수 있지만 암호화되지 않은 개인 키에는 액세스할 수 없습니다
• 사용 사례: KMS API를 호출할 수 없는 사용자에 의한 AWS 외부 암호화
AWS KMS (Key Management Service)
• KMS 키 유형:
• AWS 소유 키(무료): SSE-S3, SSE-SQS, SSE-DDB(기본 키)
• AWS 관리 키: 무료(aws/service-name, 예: aws/rds 또는 aws/ebs)
• KMS에서 생성된 고객 관리 키: 월 1달러
• 고객 관리 키 가져오기(대칭 키여야 함): 월 1달러
• + KMS에 API 통화료($0.03/10000 통화)를 지불합니다
• 자동 키 회전:
• AWS 관리 KMS Key: 1년마다 자동 실행
• 고객 관리 KMS 키: (활성화해야 함) 1년마다 자동 실행
• 가져온 KMS 키: 별칭을 사용하여 수동 회전만 가능
Copying Snapshots across regions
• 암호화된 스냅샷을 다른 리즌으로 복사시
먼저 같은 리즌에서 암호화된 스냅샷을 복사하면 생성된 스냅샷 역시 동일한 KMS 키로 암호화
다른 리즌으로 복사시 다른 KMS 키를 사용해서 스냅샷을 다시 암호화해야함.
KMS Key Policies
• S3 버킷 정책과 "비슷한" KMS 키에 대한 액세스 제어
• 차이점: 사용자가 없으면 액세스를 제어할 수 없습니다
• 기본 KMS 키 정책:
• 특정 KMS 키 정책을 제공하지 않을 경우 생성됨
• 루트 사용자에 대한 키에 대한 완전한 액세스 = 전체 AWS 계정
• 기본적으로 계정의 모든 사람이 키에 액세스하도록 허용. (액세스를 허용하는 IAM 정책만 있으면 가능.)
• 사용자 지정 KMS 키 정책:
• KMS 키에 액세스할 수 있는 사용자, 역할 정의
• 키를 관리할 수 있는 사용자 정의
• KMS 키의 교차 계정 액세스에 유용합니다
KMS키는 대칭일 수도, 비대칭일 수도 있습니다. 대칭 KMS 키는 암호화와 복호화에 사용되는 256비트 키를 나타냅니다. 비대칭 KMS 키는 암호화 및 복호화, 혹은 서명과 검증에 사용되는 RSA 키 쌍을 나타내지만, 둘 다에 사용되지는 않습니다. 혹은 서명 및 검증에 사용되는 타원 곡선(ECC) 키 쌍을 나타냅니다.
Copying Snapshots across accounts
• 1. 자신의 KMS 키(고객 관리 키)로 암호화된 스냅샷 생성
2. 교차 계정 액세스를 허용하는 KMS 키 정책 첨부(고객 키 정책을 연결해야 하므로 고객 관리형 키가 되며)
3. (대상 계정에)암호화된 스냅샷 공유
4. (대상에서) 스냅샷 복사본을 생성하고 계정의 다른 CMK로 암호화합니다
5. 스냅샷에서 볼륨 생성
KMS Multi -Region Keys
• 서로 다른 AWS 지역에 있는 동일한 KMS 키를 서로 바꾸어 사용할 수 있습니다
• 다중 영역 키의 키 ID, 키 재료, 자동 회전...
• 한 지역에서 암호화하고 다른 지역에서 암호 해독
• 지역 간 API 호출을 다시 암호화하거나 수행할 필요 없음
• KMS 다중 영역은 전역이 아닙니다(기본 + 복제본)
• 하나의 KMS Keys로 관리하는게 아닌 각 리즌에 Keys를 복제해서 이용.
• 각 다중 영역 키는 독립적으로 관리됩니다
• 사용 사례: 글로벌 클라이언트 측 암호화, Global DynamoDB의 암호화, Global Aurora
DynamoDB Global Tables and KMS MultiRegion Keys Client-Side encryption
• Amazon DynamoDB Encryption Client를 사용하여 DynamoDB 테이블의 특정 속성을 클라이언트 측에서 암호화할 수 있습니다
• 글로벌 테이블과 결합하면 클라이언트 측 암호화된 데이터가 다른 영역으로 복제됩니다
• DynamoDB Global 테이블과 동일한 영역에서 복제된 다중 영역 키를 사용하는 경우 이러한 영역의 클라이언트는 해당 영역의 KMS에 대한 대기 시간이 짧은 API 호출을 사용하여 데이터 클라이언트 측의 암호를 해독할 수 있습니다
(DB관리자도 모름.)
• 클라이언트 측 암호화를 사용하여 특정 필드를 보호하고 클라이언트가 API 키에 액세스할 수 있는 경우에만 암호 해독을 보장할 수 있습니다
Global Aurora and KMS Multi-Region Keys Client-Side encryption
• AWS Encryption SDK를 사용하여 Aurora 테이블의 클라이언트 측 특정 속성을 암호화할 수 있습니다
col(SSN) 열을 제외한 다른 열의 데이터는 암호화되지 않습니다.
• Aurora Global Tables와 결합하여 클라이언트 측 암호화된 데이터가 다른 지역으로 복제됨
• Global Aurora DB와 동일한 영역에서 복제된 다중 영역 키를 사용하는 경우 이러한 영역의 클라이언트는 해당 영역의 KMS에 대한 대기 시간이 짧은 API 호출을 사용하여 데이터 클라이언트 측의 암호를 해독할 수 있습니다
• 클라이언트 측 암호화를 사용하여 특정 필드를 보호하고 클라이언트가 API 키에 액세스할 수 있는 경우에만 암호 해독을 보장할 수 있으며, 데이터베이스 관리자로부터도 특정 필드를 보호할 수 있습니다
S3 Replication Encryption Considerations
• • 암호화되지 않은 개체 및 SSE-S3로 암호화된 개체는 기본적으로 복제됩니다
• SSE-C(고객이 제공한 키)로 암호화된 개체는 복제되지 않음
• SSE-KMS로 암호화된 개체의 경우 이 옵션을 사용하도록 설정해야 합니다
• 대상 버킷 내의 개체를 암호화할 KMS 키 지정
• 대상 키에 대한 KMS 키 정책 적용
• KMS가 포함된 IAM 역할:소스 KMS 키 및 kms에 대한 암호 해독:대상 KMS 키에 대한 암호화
• KMS 조절 오류가 발생할 수 있으며, 이 경우 서비스 할당량 증가를 요청할 수 있습니다
• 다중 영역 AWS KMS 키를 사용할 수 있지만 현재 Amazon S3에서 독립 키로 처리됩니다(개체는 계속 암호 해독된 다음 암호화됨)
AMI Sharing Process Encrypted via KMS
1. 소스 계정의 AMI가 소스 계정의 KMS 키로 암호화됨
2. 지정된 대상 AWS 계정에 해당하는 시작 권한을 추가하려면 이미지 속성을 수정해야 합니다
3. AMI가 참조하는 스냅샷을 암호화하는 데 사용되는 KMS 키를 대상 계정/IAM 역할과 공유해야 합니다
4. 대상 계정의 IAM 역할/사용자에게 DescriptionKey, ReEencrypted, CreateGrant, Decrypt 권한이 있어야 합니다
5. AMI에서 EC2 인스턴스를 시작할 때 선택적으로 대상 계정이 자신의 계정에 새 KMS 키를 지정하여 볼륨을 다시 암호화할 수 있습니다
SSM Parameter Store
• 구성 및 암호을 위한 보안 스토리지
• KMS를 사용한 원활한 암호화(선택 사항)
• 서버리스, 확장성, 내구성, 간편한 SDK(Software Development Kit)
• 구성/비밀에 대한 버전 추적
• IAM을 통한 보안
• Amazon Event Bridge를 통한 알림
• 클라우드 형성과의 통합
SSM Parameter Store Hierarchy(계층)
•
Standard and advanced parameter tiers
•
Parameters Policies (for advanced parameters)
• 암호와 같은 중요한 데이터를 강제로 업데이트하거나 삭제하기 위해 TTL을 매개 변수(만료 날짜)에 할당할 수 있습니다
• 한 번에 여러 정책을 할당할 수 있음
AWS Secrets Manager
• 비밀을 저장하기 위한 새로운 서비스
• X일마다 암호를 강제로 순환시키는 기능
• 회전 시 비밀 생성 자동화(람다 사용)
• Amazon RDS(MySQL, Postgre)와의 통합SQL, Aurora)
• 비밀은 KMS를 사용하여 암호화됩니다
• 대부분 RDS 통합에 사용됩니다
AWS Secrets Manager – Multi-Region Secrets
• 여러 AWS 영역에 걸쳐 암호 복제
• Secrets Manager는 읽기 복제본을 기본 Secret과 동기화합니다
• 읽기 복제본 암호를 독립 실행형 암호로 승격하는 기능
• 활용 사례: 다중 영역 애플리케이션, 재해 복구 전략, 다중 영역 DB…
AWS Certificate Manager (ACM)
• TLS 인증서(Certificates)를 쉽게 프로비저닝, 관리 및 배포
• 웹 사이트(HTTPS)에 대한 기내 암호화 제공
• 공용 및 개인 TLS 인증서 모두 지원
• 공용 TLS 인증서의 경우 무료
• TLS 인증서 자동 갱신
• 와 통합(TLS 인증서 로드)
• 탄성 하중 균형 장치(CLB, ALB, NLB)
• 클라우드 프런트 배포
• API 게이트웨이의 API
• EC2와 함께 ACM을 사용할 수 없음(추출할 수 없음)
ACM – Requesting Public Certificates
1. 인증서에 포함할 도메인 이름 나열
• FQDN(정규화된 도메인 이름): corp.example.com
• 와일드카드 도메인: *.example.com
2. 유효성 검사 방법: DNS 유효성 검사 또는 이메일 유효성 검사를 선택합니다
• 자동화를 위해 DNS 검증이 선호됨
• 이메일 유효성 검사는 WHOIS 데이터베이스의 연락처 주소로 이메일을 보냅니다
• DNS 검증은 CNAME 레코드를 DNS 구성에 활용합니다(예: Route 53)
3. 확인하는 데 몇 시간이 걸릴 것입니다
4. 공인인증서가 자동 갱신에 등록됩니다
• ACM은 만료 60일 전에 ACM 생성 인증서를 자동으로 갱신합니다
ACM – Importing Public Certificates
• ACM 외부에서 인증서를 생성한 다음 가져오는 옵션
• 자동 갱신 없음. 만료 전에 새 인증서를 가져와야 합니다
• ACM은 만료 45일 전부터 매일 만료 이벤트를 전송합니다
• 일 수를 구성할 수 있습니다
• EventBridge에 이벤트가 표시됩니다
• AWS Config에는 만료된 인증서를 확인하는 acm-certificate-expiration-check라는 관리 규칙이 있습니다(구성 가능한 일 수)
ACM – Integration with ALB
•
API Gateway - Endpoint Types
• Edge-Optimized (default)에지 최적화: 글로벌 고객의 경우
• 요청이 CloudFront Edge 위치를 통해 라우팅됨(지연 시간 개선)
• API 게이트웨이가 여전히 하나의 영역에만 있음
• Regional:
• 동일한 지역 내 클라이언트의 경우
• CloudFront와 수동으로 결합 가능(캐싱 전략 및 배포에 대한 제어 강화)
• Private:
• 인터페이스 VPC 끝점(ENI)을 사용하여 VPC에서만 액세스할 수 있습니다
• 리소스 정책을 사용하여 액세스 정의
엣지 최적화 API Gateway는 배후에서 AWS가 관리하는 사용자 지정 CloudFront 배포를 사용하여 CloudFront 엣지 로케이션을 거쳐 전 세계로 요청을 라우팅하기 때문에 ACM 인증서는 us-east-1 리전에 생성해야 합니다.
ACM – Integration with API Gateway
• API 게이트웨이에서 사용자 지정(Custom) 도메인 이름 생성
• Edge-Optimized(default): 글로벌 고객의 경우
• 요청이 CloudFront Edge 위치를 통해 라우팅됨(지연 시간 개선)
• API 게이트웨이가 여전히 하나의 영역에만 있음
• TLS 인증서는 us-east-1의 CloudFront와 동일한 영역에 있어야 합니다
• 그런 다음 Route53로에서 CNAME 또는 (더 나은) A-Alias 레코드를 설정합니다
• 지역:
• 동일한 지역 내 클라이언트의 경우
• API Stage와 동일한 영역의 API Gateway에서 TLS 인증서를 가져와야 합니다
• 그런 다음 53번 도로에서 CNAME 또는 (더 나은) A-Alias 레코드를 설정합니다
AWS WAF – Web Application Firewall
• • 일반적인 웹 악용(레이어 7)으로부터 웹 응용 프로그램 보호
• 계층 7은 HTTP(계층 4는 TCP/UDP)입니다
• 배포 대상
• 애플리케이션 로드 밸런서
• API 게이트웨이
• CloudFront
• AppSync GraphQL API
• Cognito User Pool
•웹 ACL(웹 액세스 제어 목록) 규칙 정의:
• IP Set: up to 10,000 IP addresses – 더 많은 IP에 대해 여러 규칙 사용
• HTTP 헤더, HTTP 본문 또는 URI 문자열 - 일반 공격으로부터 보호 - SQL 주입 및 사이트 간 스크립팅(XSS)
• 크기 제약 조건, 지리적 일치(블록 국가)
• 속도 기반 규칙(이벤트 발생 횟수 계산) – DDoS 보호
• 웹 ACL은 CloudFront를 제외하고 지역적입니다
• 규칙 그룹은 웹 ACL에 추가할 수 있는 재사용 가능한 규칙 집합입니다
WAF – Fixed IP while using WAF with a Load Balancer
• WAF가 네트워크 로드 밸런서(계층 4)를 지원하지 않음
• 이 문제는 ALB에서 고정 IP 및 WAF에 Global Accelerator를 사용할 수 있습니다
AWS Shield: protect from DDoS attack
• DDoS: 분산 서비스 거부 – 동시에 많은 요청
• AWS 실드 표준:
• 모든 AWS 고객에게 활성화되는 무료 서비스
• SYN/UDP Floods, Reflection 공격 및 기타 계층 3/4 공격과 같은 공격으로부터 보호합니다
• AWS Shield Advanced:
• 옵션 DDoS 완화 서비스(조직당 월 3,000달러)
• Amazon EC2, ELB(Elastic Load Balancing), Amazon CloudFront, AWS Global Accelerator 및 Route 53에 대한 보다 정교한 공격으로부터 보호
• AWS DDoS 대응 팀(DRP) 24x7 액세스
• DDoS로 인해 사용량이 급증하는 동안 더 높은 수수료로부터 보호
• Shield 고급 자동 애플리케이션 계층 DDoS 완화를 통해 자동으로 AWS WAF 규칙을 생성, 평가 및 배포하여 계층 7 공격을 완화합니다
AWS Firewall Manager
• AWS 조직의 모든 계정에서 규칙 관리
• 보안 정책: 공통 보안 규칙 집합
• WAF 규칙(애플리케이션 로드 밸런서, API 게이트웨이, CloudFront)
• AWS Shield Advanced(ALB, CLB, NLB, Elastic IP, CloudFront)
• VPC의 EC2, 애플리케이션 로드 밸런서 및 ENI 리소스에 대한 Security Group
• AWS 네트워크 방화벽(VPC 수준)
• Amazon Route 53 Resolver DNS 방화벽
• 정책이 지역 수준에서 생성됨
• 조직의 모든 계정과 향후 계정에 걸쳐 새로운 리소스가 생성될 때 규칙이 적용됩니다(준수에 적합)
WAF vs. Firewall Manager vs. Shield
• WAF, Shield 및 Firewall Manager를 함께 사용하여 포괄적인 보호
• WAF에서 웹 ACL 규칙 정의
• 리소스를 세밀하게 보호하려면 WAF만 사용하는 것이 좋습니다
• 계정 간에 AWS WAF를 사용하고, WAF 구성을 가속화하고, 새 리소스 보호를 자동화하려면 AWS WAF와 함께 Firewall Manager를 사용하십시오
• 쉴드 어드밴스드는 쉴드 대응팀(SRT)의 전용 지원과 고급 보고 등 AWS WAF에 추가 기능을 추가했다.
• DDoS 공격이 자주 발생하는 경우 Shield Advanced 구매를 고려해 보십시오
AWS Best Practices for DDoS Resiliency Edge Location Mitigation (BP1, BP3)
• BP1 – 클라우드 전면
• 가장자리의 웹 애플리케이션 전송
• DDoS 일반 공격으로부터 보호(SYN 플러드, UDP 리플렉션 등)
• BP1 – 글로벌 가속기
• 에지에서 애플리케이션 액세스
• DDoS 보호를 위한 실드와의 통합
• 백엔드가 CloudFront와 호환되지 않는 경우 유용
• BP3 – Route 53
• 가장자리의 도메인 이름 확인
• DDoS 보호 메커니즘
AWS Best Practices for DDoS Resiliency Best pratices for DDoS mitigation
• 인프라 계층 방어(BP1, BP3, BP6)
• 높은 트래픽으로부터 Amazon EC2 보호
• 여기에는 글로벌 가속기, Route 53, CloudFront, Elastic Load Balancing 사용이 포함됩니다
• ASG 기능이 있는 Amazon EC2(BP7)
• 플래시 군중 또는 DDoS 공격을 포함한 갑작스러운 트래픽 급증 시 확장 지원
• ELB(BP6)
• 트래픽이 증가함에 따라 탄력적인 로드 밸런싱이 확장되고 트래픽이 많은 EC2 인스턴스로 분산됨
AWS Best Practices for DDoS Resiliency Application Layer Defense
• 악의적인 웹 요청 탐지 및 필터링(BP1, BP2)
• CloudFront는 정적 컨텐츠를 캐슁하여 에지 위치에서 제공하여 백엔드를 보호합니다
• AWS WAF는 CloudFront 및 애플리케이션 로드 밸런서를 기반으로 요청을 필터링하고 차단하는 데 사용됩니다
• WAF 속도 기반 규칙은 자동으로 불량 행위자의 IP를 차단할 수 있다
• WAF에서 관리되는 규칙을 사용하여 IP 평판을 기반으로 공격 차단 또는 익명 Ips 차단
• CloudFront는 특정 지역을 차단할 수 있습니다
• 실드 고급(BP1, BP2, BP6)
• Shield 고급 자동 애플리케이션 계층 DDoS 완화를 통해 자동으로 AWS WAF 규칙을 생성, 평가 및 배포하여 계층 7 공격을 완화합니다
AWS Best Practices for DDoS Resiliency Attack surface reduction
• Obfuscating AWS resources (BP1, BP4, BP6)
• CloudFront, API Gateway, Elastic Load Balancing을 사용하여 백엔드 리소스 숨기기(Lambda 함수, EC2 인스턴스)
• Security groups and Network ACLs (BP5)
• 보안 그룹 및 NACL을 사용하여 서브넷 또는 ENI 수준의 특정 IP를 기준으로 트래픽 필터링
• AWS Shield Advanced에 의해 Elastic IP가 보호됨
• Protecting API endpoints (BP4)
• EC2, 람다 등 숨기기
• 에지 최적화 모드 또는 CloudFront + 지역 모드(DDoS에 대한 제어 강화)
• WAF + API 게이트웨이: 버스트 제한, 헤더 필터링, API 키 사용
Amazon GuardDuty
• AWS 계정을 보호하는 지능형 위협 검색
• 기계 학습 알고리즘, 이상 징후 감지, 타사 데이터 사용
• 클릭 한 번으로 활성화(30일 평가판), 소프트웨어 설치 필요 없음
• 입력 데이터에는 다음이 포함됩니다:
• CloudTrail Event Logs – 비정상적인 API 호출, 무단 배포
• CloudTrail Management Event – VPC 서브넷 생성, 추적 생성 등…
• CloudTrail S3 Data Events – 객체 가져오기, 객체 나열, 객체 삭제 등…
• VPC Flow Logs – 비정상적인 내부 트래픽, 비정상적인 IP 주소
• DNS 로그 – DNS 쿼리 내에서 인코딩된 데이터를 전송하는 손상된 EC2 인스턴스
• Kubernetes 감사 로그 – 의심스러운 작업 및 잠재적인 EKS 클러스터 손상
• 발견된 경우 알림을 받도록 EventBridge 규칙을 설정할 수 있습니다
• EventBridge 규칙은 AWS 람다 또는 SNS를 대상으로 할 수 있습니다
• 암호화폐 공격으로부터 보호할 수 있음(전용 "찾기"가 있음)
Amazon Inspector
• 자동화된 보안 평가
• EC2 인스턴스의 경우
• AWS 시스템 매니저(SSM) 에이전트 활용
• 의도하지 않은 네트워크 접근성에 대한 분석
• 실행 중인 OS를 알려진 취약성과 비교 분석
• 컨테이너 이미지의 경우 Amazon ECR로 푸시
• 용기 이미지 푸시 시 평가
• 람다 함수의 경우
• 기능 코드 및 패키지 종속성에서 소프트웨어 취약성 식별
• 배치된 기능의 평가
• 보고 및 AWS Security Hub와의 통합
• Amazon Event Bridge로 결과 전송
What does Amazon Inspector evaluate?
• Remember: EC2 인스턴스, 용기 이미지 및 람다 기능에 대해서만
• 필요한 경우에만 인프라를 지속적으로 검색
• 패키지 취약성(EC2, ECR 및 람다) – CVE 데이터베이스
• 네트워크 도달 가능성(EC2)
• 위험 점수는 우선 순위 지정에 대한 모든 취약성과 연결됩니다
AWS Macie
• Amazon Macie는 기계 학습 및 패턴 매칭을 사용하여 AWS에서 중요한 데이터를 검색하고 보호하는 완전 관리 데이터 보안 및 데이터 개인 정보 보호 서비스입니다.
• Macie는 개인 식별 가능 정보(PII)와 같은 중요한 데이터를 식별하고 사용자에게 경고하는 데 도움을 줍니다
Virtual Private Cloud (VPC)
VPC Components Diagram
•
Understanding CIDR – IPv4
• 클래스리스 도메인 간 라우팅 - IP 주소 할당 방법
• 일반적으로 Security Groups 규칙 및 AWS 네트워킹에서 사용됩니다
• IP 주소 범위를 정의하는 데 도움이 됩니다:
• WW.XX 봤어요.YY.ZZ/32 => 하나의 IP
• 0.0.0.0/0 => all IPs
• 그러나 다음을 정의할 수 있습니다.192.168.0.0/26 => 192.168.0.0 – 192.168.0.63(64 IP 주소)
• CIDR은 두 개의 구성 요소로 구성됩니다
• 기본 IP
• 범위(XX)에 포함된 IP를 나타냅니다.XX.XX.XX)
• 예: 10.0.0, 192.168.0.0, …
• 서브넷 마스크
• IP에서 변경할 수 있는 비트 수를 정의합니다
• 예: /0, /24, /32
• 두 가지 형식을 사용할 수 있습니다:
• /8 o 255.0.0.0
• /16 o 255.255.0.0
• /24 o 255.255.255.0
• /32 o 255.255.255.255
Understanding CIDR – Subnet Mask
• 서브넷 마스크는 기본적으로 기본 IP의 일부가 기본 IP에서 추가 다음 값을 가져올 수 있도록 합니다
Understanding CIDR – Little Exercise
•
Public vs. Private IP (IPv4)
• IANA(Internet Assigned Numbers Authority)는 개인(LAN) 및 Public(인터넷) 주소를 사용하기 위해 특정 IPv4 주소 블록을 설정했습니다
• Private IP는 특정 값만 허용할 수 있습니다:
• 빅 네트워크에서 10.0.0 – 10.255.255(10.0.0/8) s
• 172.16.0.0 – 172.31.255.255 (172.16.0.0/12) cs 해당 범위의 AWS 기본 VPC
• 192.168.0.0 – 192.168.255.255(192.168.0.0/16) 예: 홈 네트워크
• 인터넷의 나머지 IP 주소는 모두 공용입니다
Default VPC Walkthrough
• 모든 새 AWS 계정에는 기본 VPC가 있습니다
• 서브넷이 지정되지 않은 경우 새 EC2 인스턴스가 기본 VPC로 시작됩니다
• 기본 VPC에 인터넷 연결이 있고 내부의 모든 EC2 인스턴스에 공용 IPv4 주소가 있음
• 공용 및 개인 IPv4 DNS 이름도 사용할 수 있습니다
VPC in AWS – IPv4
• VPC = Virtual Private Cloud
• AWS 영역에 여러 개의 VPC를 사용할 수 있습니다(영역당 최대 5개 – 소프트 제한)
• VPC당 최대 CIDR은 5입니다. 각 CIDR에 대해:
• 최소 크기는 /28(16 IP 주소)입니다
• 최대 크기는 /16(65536 IP 주소)입니다
• VPC는 비공개이므로 전용 IPv4 범위만 허용됩니다:
• 10.0.0.0 – 10.255.255.255 (10.0.0.0/8)
• 172.16.0.0 – 172.31.255.255 (172.16.0.0/12)
• 192.168.0.0 – 192.168.255.255 (192.168.0.0/16)
• VPC CIDR이 다른 네트워크(예: 기업)와 겹치지 않아야 합니다
기업 네트워크의 크기는 10.0.0.0/8이고, 위성 사무실의 크기가 192.168.0.0/16입니다. 추후 두 네트워크를 연결할 계획이라면, AWS VPC에 적합한 CIDR은 다음 중 무엇인가요?
172.16.0.0/16
CIDR이 겹쳐서는 안 되며, AWS 내 최대 CIDR의 크기는 /16입니다.
State of Hands -on
•
Adding Subnets
•
VPC – Subnet (IPv4)
• AWS는 각 서브넷에 5개의 IP 주소(처음 4개 및 마지막 1개)를 예약합니다
• 이 5개의 IP 주소는 사용할 수 없으며 EC2 인스턴스에 할당할 수 없습니다
• 예: CIDR이 10.0.0/24를 차단하는 경우 예약된 IP 주소는 다음과 같습니다:
• 10.0.0.0 – 네트워크 주소
• 10.0.0.1 – AWS에 의해 VPC 라우터용으로 예약됨
• 10.0.0.2 – AWS에서 Amazon에서 제공하는 DNS에 매핑하기 위해 예약됨
• 10.0.0.3 – 향후 사용을 위해 AWS에서 예약
• 10.0.0.255 – 네트워크 브로드캐스트 주소. AWS가 VPC에서 브로드캐스트를 지원하지 않으므로 주소가 예약됨
• Exam 팁: EC2 인스턴스에 대해 29개의 IP 주소가 필요한 경우:
• 크기가 /27인 서브넷은 선택할 수 없습니다(32 IP 주소, 32 – 5 = 27 < 29)
• 크기가 /26인 서브넷을 선택해야 합니다(64 IP 주소, 64 – 5 = 59 > 29)
Internet Gateway (IGW)
• VPC의 리소스(예: EC2 인스턴스)를 인터넷에 연결할 수 있습니다
• 수평적으로 확장되며 가용성과 중복성이 높음
• VPC와 별도로 생성해야 함
• 하나의 VPC를 하나의 IGW에만 연결할 수 있으며 그 반대의 경우도 마찬가지입니다
• 인터넷 게이트웨이 자체는 인터넷 액세스를 허용하지 않습니다…
• 경로 테이블도 편집해야 합니다!
Adding Internet Gateway
•
Editing Route Tables
•
Bastion Hosts
• Bastion Host를 사용하여 프라이빗 EC2 인스턴스에 SSH를 적용할 수 있습니다
• bastion은 다른 모든 개인 서브넷에 연결된 공용 서브넷에 있습니다
• Bastion Host 보안 그룹은 제한된 CIDR(예: 회사의 공용 CIDR)에서 포트 22의 인터넷에서 인바운드를 허용해야 합니다
• EC2 인스턴스의 Security Group은 Bastion 호스트의 Security Group 또는 Bastion 호스트의 개인 IP를 허용해야 합니다
NAT Instance (outdated, but still at the exam)
• NAT = Network Address Translation
• 개인 서브넷의 EC2 인스턴스가 인터넷에 연결할 수 있도록 허용합니다
• 공용 서브넷에서 시작해야 함
• EC2 설정을 사용하지 않도록 설정해야 합니다: Source/destination Check
• Elastic IP가 연결되어 있어야 합니다
• 개인 서브넷에서 NAT 인스턴스로 트래픽을 라우팅하도록 라우팅 테이블을 구성해야 함
NAT Instance
• AMI마켓 or AMI Community에서 적절한거 찾아서 이용한후 만들어진 NAT Instance에 Networking 에서 소스/목적지(Change source/destination check)에서 stop 설정하기.
private instance와 NAT Instance와 연결해주고
NAT Instance에 보안그룹 All ICMP - iPv4에 CIDR은 서브넷 IP로 설정.
그리고 private Instance 연결확인.
NAT Instance – Comments
• 미리 구성된 Amazon Linux AMI를 사용할 수 있음
• 2020년 12월 31일 표준 지원 종료에 도달했습니다
• 즉시 사용할 수 있는 고가용성/복원성 설정 제공
• 다중 AZ + 복원력 있는 사용자 데이터 스크립트에서 ASG를 생성해야 합니다
• 인터넷 트래픽 대역폭은 EC2 인스턴스 유형에 따라 달라집니다
• Security Group 및 규칙을 관리해야 합니다:
• 인바운드:
• 개인 서브넷에서 수신되는 HTTP/HTTPS 트래픽 허용
• 홈 네트워크에서 SSH 허용(인터넷 게이트웨이를 통해 액세스 제공)
• 아웃바운드:
• 인터넷에 대한 HTTP/HTTPS 트래픽 허용
NAT Gateway
• AWS 관리 NAT, 더 높은 대역폭, 고가용성(HA), 관리 없음
• 사용량 및 대역폭에 대한 시간당 지불
• NATGW는 특정 가용성 영역에서 생성되며 Elastic IP를 사용합니다
• 동일한 서브넷의 EC2 인스턴스에서 사용할 수 없음(다른 서브넷에서만)
• IGW 필요(전용 서브넷 => NATGW => IGW)
• 최대 45Gbps의 자동 확장 기능을 갖춘 5Gbps 대역폭
• 관리할 Security Group 없음/필수
NAT Gateway
•
NAT Gateway with High Availability
• NAT 게이트웨이는 단일 가용성 영역 내에서 탄력적임
• Fault Tolerance를 위해 여러 AZ에 여러 NAT 게이트웨이를 생성해야 함
• AZ가 중단된 경우 NAT이 필요하지 않으므로 크로스 AZ 페일오버가 필요하지 않습니다
NAT Gateway vs. NAT Instance
•
Security Groups & NACLs
• NACL은 무상태 SG는 상태유지.(SG는 들어간게 그대로 나옴.)
Network Access Control List (NACL)
• NACL은 서브넷에서 송수신되는 트래픽을 제어하는 방화벽과 같습니다
• 서브넷당 하나의 NACL, 새 서브넷에는 기본 NACL이 할당됩니다
• NACL 규칙을 정의합니다:
• 규칙에 숫자(1-32766)가 있고 우선 순위가 높을수록 숫자가 작음
• 첫 번째 규칙 일치가 결정을 주도합니다
• 예: #100 ALLOW 10.0.0.10/32 및 #200 DENY 10.0.0.10/32를 정의하면 100이 200보다 우선 순위가 높기 때문에 IP 주소가 허용됩니다
• 마지막 규칙은 별표(*)이며 일치하는 규칙이 없는 경우 요청을 거부합니다
• AWS는 규칙을 100씩 추가할 것을 권장합니다
• 새로 생성된 NACL은 모든 것을 거부합니다
• NACL은 서브넷 수준에서 특정 IP 주소를 차단하는 좋은 방법입니다
NACLs
•
Default NACL
• 연결된 서브넷의 인바운드/아웃바운드를 모두 허용합니다
• 기본 NACL을 수정하지 않고 사용자 지정 NACL을 만듭니다
Ephemeral Ports
• 두 끝점이 연결을 설정하려면 포트를 사용해야 합니다
• 클라이언트가 Defined port에 연결하고 사용 후 Ephemeral Ports에 대한 응답을 기대합니다
• 운영 체제마다 포트 범위가 다릅니다. 예:
• IANA & MS 윈도우 10 è 49152 – 65535
• 많은 리눅스 커널 è 32768 – 609999
클라이언트와 웹서버에 IP가 있고 합 번의 요청 또는 연결에만 임시포트를 개방.
NACL with Ephemeral Ports
•
Create NACL rules for each target subnets CIDR
• 각 NACL 조합이 NACL 내에서 허용되어야 함.
멀티 인스턴스(Public 인스턴스) - 멀티 디비(Private 서브넷)
Security Group vs. NACLs
| Security Group | NACL |
| 인스턴스 수준에서 작동합니다 |
서브넷 수준에서 작동합니다
|
| 허용 규칙만 지원 |
허용 규칙 및 거부 규칙 지원
|
| 상태 저장: 규칙에 관계없이 반환 트래픽이 자동으로 허용됩니다 | 상태 비저장: 반환 트래픽은 규칙에 의해 명시적으로 허용되어야 합니다(사용 후 삭제 포트 생각) |
| 트래픽 허용 여부를 결정하기 전에 모든 규칙이 평가됨 | 트래픽 허용 여부를 결정할 때 규칙이 가장 낮은 순서에서 가장 높은 순서로 평가되며 첫 번째 일치가 승리함 |
| 다른 사용자가 지정한 경우 EC2 인스턴스에 적용됩니다 |
연결된 서브넷의 모든 EC2 인스턴스에 자동으로 적용됩니다
|
•
VPC Peering
• AWS의 네트워크를 사용하여 두 개의 VPC를 개인적으로 연결합니다
• 동일한 네트워크에 있는 것처럼 동작하도록 합니다
• 중복되는 CIDR이 없어야 함
• VPC 피어링 연결이 과도적이지 않음(NOT transitive)(서로 통신해야 하는 각 VPC에 대해 설정해야 함)
• EC2 인스턴스가 서로 통신할 수 있도록 각 VPC의 서브넷에서 경로 테이블을 업데이트해야 합니다
VPC Peering – Good to know
• 서로 다른 AWS 계정/지역에 있는 VPC 간에 VPC 피어링 연결을 생성할 수 있습니다
• 피어링된 VPC에서 Security Group을 참조할 수 있습니다(계정 간 작업 – 동일한 지역)
VPC Peering
•
VPC Endpoints
•
VPC Endpoints (AWS PrivateLink)
• 모든 AWS 서비스가 공개적으로 노출됨(공개 URL)
• AWS PrivateLink를 통해 제공되는 VPC Endpoints를 사용하면 공용 인터넷을 사용하는 대신 전용 네트워크를 사용하여 AWS 서비스에 연결할 수 있습니다
• 이중화되고 수평적으로 확장됩니다
• 또한 AWS 서비스에 액세스하기 위해 IGW, NATGW 등을 사용할 필요가 없습니다
• 문제가 발생한 경우:
• VPC에서 DNS 설정 확인
• 경로 테이블 확인
•비용절약 : Private Subnet의 EC2 Instance에서 Public Subnet 안에 있는 NAT Gateway 를 통과해 Internet Gateway를 이용해서 다른 AWS 서비스를 이용하는 것보다 싸게 이용가능.
Types of Endpoints
• 인터페이스 끝점(PrivateLink에서 제공)
• 진입점(entry point)으로 ENI(개인 IP 주소)를 프로비저닝합니다(보안 그룹을 연결해야 함)
• 대부분의 AWS 서비스 지원
• 시간당 비용 + GB당 비용 처리된 데이터
• 게이트웨이 끝점
• 게이트웨이를 프로비저닝하고 루트 테이블에서 대상으로 사용해야 합니다(보안 그룹 사용 안 함)
• S3 및 Dynamo 모두 지원DB
• 무료
Gateway or Interface Endpoint for S3?
• 게이트웨이는 검사에서 항상 선호될 가능성이 높습니다
• 비용: 게이트웨이의 경우 무료, 인터페이스 끝점의 경우 $
• 인터페이스 Endpoint는 사내(사이트에서 사이트 VPN 또는 Direct Connect), 다른 VPC 또는 다른 지역에서 액세스해야 합니다
S3와 연결할 경우 Interface Gateway Endpoint를 쓸 때는 on-premises일 때
Lambda in VPC accessing DynamoDB
• DynamoDB는 AWS의 공개 서비스입니다
• 옵션 1: 공용 인터넷에서 액세스
• 람다는 VPC에 있으므로 공용 서브넷과 인터넷 게이트웨이에 NAT 게이트웨이가 필요합니다
• 옵션 2(더 우수하고 무료): 전용 VPC 네트워크에서 액세스
• Dynamo용 VPC 게이트웨이 끝점 배포DB
• Route Tables 변경
VPC Flow Logs
• • 인터페이스로 전송되는 IP 트래픽에 대한 정보를 캡처합니다:
• VPC Flow Logs
• 서브넷 Flow Logs
• ENI(Elastic Network Interface) Flow Logs
• 연결 문제를 모니터링하고 해결하는 데 도움이 됩니다
• 흐름 로그 데이터가 S3 / CloudWatch 로그로 이동할 수 있음
• AWS 관리 인터페이스에서도 ELB, RDS, ElastiCache, Redshift, WorkSpaces, NATGW, Transit Gateway 등의 네트워크 정보를 캡처합니다…
VPC Flow Logs
•
VPC Flow Logs Syntax
• srcaddr & dstaddr – 문제가 있는 IP를 식별하는 데 도움이 됩니다
• srcport & dstport – 문제가 있는 포트를 식별하는 데 도움이 됩니다
• Action – Security Group / NACL로 인한 요청의 성공 또는 실패
• 사용 패턴 또는 악의적인 동작에 대한 분석에 사용할 수 있습니다
• S3의 Athena 또는 CloudWatch Logs Insight를 사용하여 VPC 흐름 로그 쿼리
• 흐름 로그 예: https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs- records-discles.discles
VPC Flow Logs –Troubleshoot SG & NACL issues
Look at the “ACTION” field
Incoming Requests
• Inbound REJECT => NACL or SG문제
(EC2 외부에서 전송한 인바운드 요청이 거부되었다는 뜻)
• Inbound ACCEPT, Outbound REJECT => NACL문제
Outgoing Requests
• Outbound REJECT => NACL or SG
• Outbound ACCEPT, Inbound REJECT =>
NACL
VPC Flow Logs – Architectures
•
생성 방법
VPC안에 Flow logs가 있고 거기서 생성
10분 추천.
AWS Site-to-Site VPN
•
AWS Site-to-Site VPN
• 가상 사설 게이트웨이(VGW)
• VPN 연결의 AWS 측 VPN 집선 장치
• VGW가 생성되어 사이트 간 VPN 연결을 만들 VPC에 연결됩니다
• ASN(자율 시스템 번호) 사용자 지정 가능성
• 고객 게이트웨이(CGW)
• 고객 측 VPN 연결의 소프트웨어 애플리케이션 또는 물리적 장치
• • https://docs.aws.amazon.com/vpn/latest/s2svpn/your-cgw.html#Devices테스트됨
Site-to-Site VPN Connections
시험나옴
• • 고객 게이트웨이 장치(사내)
• 사용할 IP 주소를 선택하십시오?
• 고객 게이트웨이 장치의 공용 인터넷 라우팅 IP 주소
• NAT 트래버설(NAT-T)을 사용하도록 설정된 NAT 장치 뒤에 있는 경우 NAT 장치의 공용 IP 주소를 사용합니다
• 중요 단계: 서브넷과 연결된 경로 테이블에서 가상 사설 게이트웨이에 대한 경로 전파(Route Propagation) 사용
(서브넷의 VPC에서 라우트 전파를 활성화 해야 Site-to-Site VPN연결이 실제로 작동.)
• 사내에서 EC2 인스턴스를 ping해야 하는 경우 보안 그룹의 인바운드에 ICMP 프로토콜을 추가해야 합니다
(온프레미스에서 AWS로 EC2인스턴스 상태를 진단할 때 보안그룹 인바둔드 ICMP 프로토콜이 활성화 됐는지 확인해야 합니다.)
AWS VPN CloudHub
• • 여러 개의 VPN 연결이 있는 경우 여러 사이트 간에 보안 통신 제공
• 서로 다른 위치 간의 기본 또는 보조 네트워크 연결을 위한 저비용 허브 앤 스포크 모델(VPN만 해당)
• VPN 연결이므로 공용 인터넷을 통해 이동합니다
• 설정하려면 동일한 VGW에서 여러 VPN 연결을 연결하고 동적 라우팅을 설정하고 경로 테이블을 구성합니다
(서로 다른 Customer Network는 VPN연결을 통해 서로 소통할 수 있게 됨.)
여러분의 기업은 미국 전역에 몇 개의 온프레미스 사이트를 갖고 있습니다. 이 사이트들은 현재 프라이빗 연결을 사용해 연결되어 있으나, 최근에는 프라이빗 연결 제공자가 상당히 불안정해져 IT 아키텍처의 일부가 오프라인 상태가 되었습니다. 여러분은 온프레미스 사이트들을 연결하기 위해 공용 인터넷을 사용하는 백업 연결을 생성하여, 제공 업체에 문제가 발생한 경우 장애 조치로 사용을 하려 합니다. 어떤 방법을 추천할 수 있을까요?
AWS VPN CloudHub는 AWS VPN을 통한 다수 사이트 간의 안전한 통신을 가능하게 해줍니다. 이는 VPC와 함께, 또는 VPC 없이 사용할 수 있는 단순한 허브 및 스포크 모델로 운용됩니다.
Direct Connect (DX)
• 원격 네트워크에서 VPC로 전용 Private 연결 제공
• DC와 AWS Direct Connect 위치 간에 전용 연결을 설정해야 합니다
• VPC에 가상 사설 게이트웨이를 설정해야 합니다
• 동일한 연결에서 공용 리소스(S3) 및 개인(EC2) 액세스
• 사용 사례:
• 대역폭 처리량 향상 - 대규모 데이터 세트로 작업 - 비용 절감
• 보다 일관된 네트워크 환경 - 실시간 데이터 피드를 사용하는 애플리케이션
• 하이브리드 환경(프리엠 + 클라우드)
• IPv4 및 IPv6 모두 지원
IPsec VPN 연결, AWS VPN CloudHub 또는 타사 소프트웨어 VPN 어플라이언스가 될 수 있는 VPN 연결을 사용하여 VPC를 원격 네트워크에 연결할 수 있습니다. VPC VPN 연결은 IPSec을 사용하여 인터넷을 통해 인트라넷과 Amazon VPC 간에 암호화된 네트워크 연결을 설정합니다.
Direct Connect Diagram
•
Direct Connect Gateway
Direct Connect – Connection Types
• Dedicated Connections: 1Gbps, 10Gbps 및 100Gbps 용량
• 고객 전용 물리적 이더넷 포트
• 먼저 AWS에 요청한 후 AWS Direct Connect 파트너가 완료
• 호스트 연결: 50Mbps, 500Mbps, 최대 10Gbps
• 연결 요청은 AWS Direct Connect 파트너를 통해 이루어집니다
• 필요에 따라 용량을 추가하거나 제거할 수 있습니다
• 일부 AWS Direct Connect 파트너에서 1, 2, 5, 10Gbps 제공
• 새 연결을 설정하는 데 리드 타임이 1개월 이상 걸리는 경우가 많습니다
Direct Connect – Encryption
• 전송 중인 데이터가 암호화되지 않았지만 개인 데이터임
• AWS Direct Connect + VPN은 IPsec 암호화 전용 연결을 제공합니다
• 보안 수준을 높이기에는 좋지만, 배치하기에는 약간 더 복잡합니다
Direct Connect - Resiliency
•
Site-to-Site VPN connection as a backup
예를 들어 회사 데이터 센터가 Direct Connect를 통해 VPC에 연결할 때
• Direct Connect가 실패할 경우 백업 Direct Connect 연결(비싼 비용) 또는 Site-to-Site VPN 연결을 설정할 수 있습니다
시험나옴
Network topologies can become complicated
•
Transit Gateway
위의 상황을 관리하기 위해서
• 수천 대의 VPC와 사내, 허브 앤 스포크(스타) 연결 간 전환적 피어링 지원
• 지역 리소스, 지역 간 작업 가능
• RAM(리소스 액세스 관리자)을 사용하여 교차 계정 공유
• 여러 지역에 걸쳐 중계 게이트웨이를 피어할 수 있습니다
• 경로 테이블: 다른 VPC와 통신할 수 있는 VPC 제한
• Direct Connect Gateway, VPN 연결과 함께 작동합니다
• IP 멀티캐스트 지원(다른 AWS 서비스에서는 지원되지 않음)
온프레미스 데이터와 AWS 클라우드 사이에 설정된 AWS Site-to-Site VPN 연결의 처리량을 단일 IPsec 터널의 최대 대역폭인 1.25Gbps보다 크게 확장하려고 합니다. 어떻게 해야 합니까?
Transit Gateway: Site-to-Site VPN ECMP
• ECMP = 등가 비용 다중 경로 라우팅
• 다중 최적 경로를 통해 패킷을 전달할 수 있는 라우팅 전략
• 사용 사례: 여러 사이트 간 VPN 연결을 생성하여 AWS에 대한 연결 대역폭을 늘립니다
Transit Gateway: throughput with ECMP
•약간 이해안감
Transit Gateway – Share Direct Connect between multiple accounts
•
VPC –Traffic Mirroring
보안기능.
• VPC에서 네트워크 트래픽을 캡처하고 검사할 수 있습니다
• 관리하는 보안 어플라이언스로 트래픽 라우팅
• 트래픽 캡처
• From (Source)(출처) – ENI
• To (Targets)(대상) – ENI 또는 네트워크 로드 밸런서
• 모든 패킷 캡처 또는 원하는 패킷 캡처(선택 사항, 패킷 잘라내기)
• 소스 및 대상은 동일한 VPC 또는 다른 VPC(VPC 피어링)에 있을 수 있습니다
• 활용 사례: 컨텐츠 검사, 위협 모니터링, 문제 해결 등…
What is IPv6?
• 43억 개의 주소를 제공하도록 설계된 IPv4(곧 소진될 예정)
• IPv6는 IPv4의 후속 제품입니다
• IPv6는 3.4 × 10 이상의 고유 IP 주소를 제공하도록 설계되었습니다
• 모든 IPv6 주소는 공용이며 인터넷 라우팅이 가능합니다(개인 범위 없음)
• 형식 èx.x.x.x.x.x.x(x는 16진수이며 범위는 0000 ~ ffff일 수 있습니다)
• Examples:
• 2001:db8:3333:4444:5555:6666:7777:8888
• 2001:db8:3333:4444:cccc:dddd:eeee:ffff
• :: è all 8 segments are zero
• 2001:db8:: è the last 6 segments are zero
• ::1234:5678 è the first 6 segments are zero
• 2001:db8::1234:5678 è the middle 4 segments are zero
IPv6 in VPC
VPC 및 서브넷에 대해 IPv4를 사용하지 않도록 설정할 수 없음
• IPv6(공용 IP 주소)이 이중 스택 모드에서 작동하도록 설정할 수 있습니다
• EC2 인스턴스는 적어도 내부 IPv4 및 공용 IPv6을 받습니다
• 인터넷 게이트웨이를 통해 IPv4 또는 IPv6을 사용하여 인터넷에 통신할 수 있습니다
IPv6 Troubleshooting
• VPC 및 서브넷에 대해 IPv4를 사용하지 않도록 설정할 수 없음
• 따라서 서브넷에서 EC2 인스턴스를 시작할 수 없는 경우
• IPv6를 획득할 수 없기 때문이 아닙니다(공간이 매우 큽니다)
• 서브넷에 사용 가능한 IPv4가 없기 때문입니다
• 솔루션: 서브넷에 새 IPv4 CIDR 생성
정보기술(IT)업계의 용어로 시스템에서 발생하는 복잡한 문제들을 종합적으로 진단해 처리한다는 뜻이다. 정부 측에선 규제 권한을 갖고 있는 중앙부처와 지자체가 한데 모여 문제를 일괄 타결하는 조정 방식으로 불린다
[네이버 지식백과] 트러블 슈팅 [trouble shooting] (한경 경제용어사전)
Egress-only Internet Gateway
• IPv6에만 사용됨
• (NAT 게이트웨이와 유사하지만 IPv6용)
• 인터넷이 인스턴스에 대한 IPv6 연결을 시작하지 못하도록 하면서 IPv6을 통한 VPC 아웃바운드 연결의 인스턴스를 허용합니다
(역할 : VPC 인스턴스에서 IPv6상에서 아웃바운드 연결을 허용하고 동시에 인터넷이 인스턴스로 IPv6 연결을 시작하지 못하게 막습니다.)
• 경로 테이블을 업데이트해야 합니다
IPv6 Routing
•
VPC Section Summary (1/3)
• CIDR – IP 범위
• VPC – Virtual Private Cloud => IPv4 및 IPv6 CIDR 목록을 정의합니다
• 서브넷 – AZ에 연결, CIDR을 정의합니다
• 인터넷 게이트웨이 – VPC 수준에서 IPv4 및 IPv6 인터넷 액세스 제공
• 경로 테이블 – 서브넷에서 IGW, VPC 피어링 연결, VPC 끝점 등으로 경로를 추가하려면 편집해야 합니다…
• Bastion Host – 프라이빗 서브넷의 EC2 인스턴스에 SSH 연결이 가능한 SSH에 대한 공용 EC2 인스턴스
• NAT 인스턴스 – 개인 서브넷의 EC2 인스턴스에 대한 인터넷 액세스를 제공합니다. 이전 버전. 공용 서브넷에 설정해야 합니다. 소스/대상 확인 플래그 사용 안 함
• NAT 게이트웨이 – AWS에서 관리하며 프라이빗 EC2 인스턴스에 대한 확장 가능한 인터넷 액세스를 제공합니다(IPv4만 해당)
• Private DNS + 경로 53 – DNS 확인 + DNS 호스트 이름(VPC) 사용
DNS 호스트 이름 및 DNS 확인은 프라이빗 호스팅 영역에 대한 필수 설정입니다. 프라이빗 호스팅 영역에 대한 DNS 쿼리는 Amazon 제공 VPC DNS 서버에서만 확인할 수 있습니다. 따라서 프라이빗 호스팅 영역이 작동하려면 이러한 옵션을 활성화해야 합니다.
DNS 호스트 이름: Amazon VPC 마법사를 사용하여 생성되지 않은 기본이 아닌 가상 프라이빗 클라우드의 경우 이 옵션은 기본적으로 비활성화되어 있습니다. 도메인에 대한 프라이빗 호스팅 영역을 생성하고 DNS 호스트 이름을 활성화하지 않고 해당 영역에 레코드를 생성하면 프라이빗 호스팅 영역이 활성화되지 않습니다. 프라이빗 호스팅 영역을 사용하려면 이 옵션을 활성화해야 합니다.
DNS 확인: 프라이빗 호스팅 영역은 VPC DNS 서버의 DNS 쿼리만 수락합니다. VPC DNS 서버의 IP 주소는 VPC IPv4 네트워크 범위의 기본에 2를 더한 예약된 IP 주소입니다. DNS 확인을 활성화하면 VPC DNS 서버를 DNS 확인을 수행하기 위한 확인자로 사용할 수 있습니다. DHCP 옵션 세트에서 사용자 지정 DNS 서버를 사용하고 프라이빗 호스팅 영역을 사용하지 않는 경우 이 옵션을 비활성화된 상태로 유지합니다.
• NACL – 인바운드 및 아웃바운드에 대한 상태 비저장 서브넷 규칙, 사용 후 삭제 포트를 잊지 마십시오
• Security Groups – 상태 저장, EC2 인스턴스 수준에서 작동
• Reachability Analyzer(도달 가능성 분석기) – AWS 리소스 간 네트워크 연결 테스트 수행, 디버그
• VPC Peering – 중복되지 않는 CIDR, 비전이적으로 두 개의 VPC를 연결합니다
• VPC Endpoints – VPC 내에서 AWS 서비스(S3, DynamoDB, Cloud Formation, SSM)에 대한 개인 액세스 제공
• VPC Flow Logs – ACCEPT 및 REJECT 트래픽에 대해 VPC/Subnet/ENI 레벨에서 설정할 수 있으며, Athena 또는 CloudWatch Logs Insights를 사용하여 공격을 식별하고 분석하는 데 도움이 됩니다
• 사이트 간 VPN – DC에 고객 게이트웨이, VPC에 가상 사설 게이트웨이 및 공용 인터넷을 통한 사이트 간 VPN 설정
• AWS VPN CloudHub – 사이트를 연결하는 허브 앤 스포크 VPN 모델
• Direct Connect – VPC에 Virtual Private Gateway를 설정하고 AWS Direct Connect Location에 대한 직접 사설 연결을 설정합니다
• Direct Connect Gateway – 다양한 AWS 지역의 많은 VPC에 직접 연결 설정
• AWS PrivateLink / VPC Endpoint 서비스:
• 서비스 VPC에서 고객 VPC로 개인적으로 서비스 연결
• VPC 피어링, 공용 인터넷, NAT 게이트웨이, 경로 테이블 필요 없음
• 네트워크 로드 밸런서 및 ENI와 함께 사용해야 함
• ClassicLink – EC2-Classic EC2 인스턴스를 VPC에 개인적으로 연결합니다
• Transit Gateway – VPC, VPN 및 DX용 전환 피어링 연결
• 트래픽 미러링 – 추가 분석을 위해 ENI에서 네트워크 트래픽 복사
• 출력 전용 인터넷 게이트웨이 – NAT 게이트웨이와 유사하지만 IPv6용
Networking Costs in AWS per GB - Simplified
• 비용 절감 및 네트워크 성능 향상을 위해 공용 IP 대신 개인 IP 사용
• 동일한 AZ를 사용하여 최대 비용 절감(고가용성 비용
Minimizing egress traffic network cost
• 송신 트래픽: 아웃바운드 트래픽(AWS에서 외부로)
• 수신 트래픽: 인바운드 트래픽 - 외부에서 AWS(일반적으로 무료)
• 비용을 최소화하기 위해 AWS 내에서 인터넷 트래픽을 최대한 유지합니다
• 동일한 AWS 영역에 위치한 Direct Connect 위치로 인해 송신 네트워크의 비용이 절감됨
S3 Data Transfer Pricing – Analysis for USA
• S3 ingress: 무료
• S3 to 인터넷: GB당 $0.09
• S3 Transfer Acceleration:
• 전송 시간 단축(50~500% 향상)
• 데이터 전송 가격 외에 추가 비용: GB당 +0.04달러 ~ 0.08달러
• S3에서 CloudFront로: GB당 $0.00
• 클라우드 프런트-인터넷: GB당 0.085달러(S3보다 약간 저렴함)
• 캐쉬 기능(지연 시간 단축)
• S3 요청 가격과 관련된 비용 절감(CloudFront를 통해 7배 더 저렴)
• S3 CRR: GB당 $0.02
Pricing: NAT Gateway vs Gateway VPC Endpoint
•
Network Protection on AWS
• AWS에서 네트워크를 보호하는 방법은 다음과 같습니다
• 네트워크 액세스 제어 목록(NACL)
• Amazon VPC 보안 그룹
• AWS WAF(악의적인 요청으로부터 보호)
• AWS Shield 및 AWS Shield Advanced
• AWS 방화벽 관리자(계정 간에 관리)
• 하지만 전체 VPC를 정교한 방식으로 보호하려면 어떻게 해야 할까요?
AWS Network Firewall
• 전체 Amazon VPC 보호
• 계층 3에서 계층 7로 보호
• 어떤 방향이든, 당신은 검사할 수 있다
• VPC 간 트래픽
• 인터넷으로 아웃바운드
• 인터넷에서 인바운드
• 직접 연결 및 사이트 간 VPN 연결
• 내부적으로 AWS 네트워크 방화벽은 AWS 게이트웨이 로드 밸런서를 사용합니다
• 규칙을 AWS Firewall Manager가 여러 VPC에 적용할 수 있도록 교차 계정을 통해 중앙에서 관리할 수 있음
Network Firewall – Fine Grained Controls
• 1000개의 규칙 지원
• IP 및 포트 - 예: 10,000s의 IP 필터링
• 프로토콜 – 예: 아웃바운드 통신을 위한 SMB 프로토콜 차단
• 상태 저장 도메인 목록 규칙 그룹: *.mycorp.com 또는 타사 소프트웨어 repo에 대한 아웃바운드 트래픽만 허용
• 정규식을 사용한 일반 패턴 일치
• 트래픽 필터링: 규칙과 일치하는 트래픽 허용, 삭제 또는 경고
• Active flow inspection(침입 방지 기능)(예: 게이트웨이 로드 밸런서, 모두 AWS에서 관리)을 통해 네트워크 위협으로부터 보호하는 활성 흐름 검사
• 규칙 일치 로그를 Amazon S3, CloudWatch 로그, Kinesis Data Firehose로 전송
'study' 카테고리의 다른 글
| AWS blog Summary 1 - 탄소 (0) | 2023.04.01 |
|---|---|
| AWS 整理 5-r ーSolution Architecture (0) | 2023.03.15 |
| AWS 整理 3-r ーSolution Architecture (0) | 2023.03.15 |
| AWS 整理 2 ーSolution Architecture (0) | 2023.03.15 |
| AWS 整理 １ ーSolution Architecture (0) | 2023.03.14 |