woongs dogfoot

CIDR (Classless Inter-Domain Routing)

• CIDR (Classless Inter-Domain Routing) : ip주소를 할당하는 방법 (ex. 122.149.196.85/32, 0.0.0.0/0 등)
  
  
  

• 구성요소

1. Base IP

2. Subnet Mask
   
   
   

3. Private IP : IANA (The Internet Assigned Numbers Authority)에서 생성한 IP 주소

   • AWS VPC Private IP : 172.16.0.0 ~ 172.31.255.255 (172.16.0.0/12)
   • Home networks : 192.168.0.0 ~ 192.168.255.255 (192.168.0.0/16)
     
     
     

Default VPC

• 특징

1. AWS 계정은 Default VPC가 1개씩 있음
2. EC2 인스턴스를 생성할 때, 서브넷을 지정하지 않으면 기본 VPC에 생성됨
3. 처음부터 인터넷에 연결되어 있음 -> 해당 VPC에 생성되는 EC2는 public IP, public/private DNS를 할당받게 됨
   
   
   

VPC

• 특징

1. 단일 region에 여러 VPC 생성 가능 (region당 최대 5개)
2. VPC마다 CIDR 5개 할당
3. 각 CIDR의 최소크기는 /28, 최대크기는 /16
4. VPC내부에서는 private IP만 허용
5. VPC에 CIDR설정 시, 다른 VPC네트워크나 기업 네트워크와 겹치지않도록 주의해야 함
   
   
   

Subnets

• Subnets : VPC 내부에 있는 IP주소 범위의 일부
  
  
  

• 특징

1. Subnet마다 AWS가 IP주소 5개를 미리 지정함 (처음 4개, 마지막 1개) -> 해당IP는 사용도 안되고 인스턴스에 할당도 안됨
   • 첫번째 : Network Address
   • 두번째 : VPC Router용
   • 세번째 : Amazon 제공 DNS에 매핑
   • 네번째 : 예비
   • 마지막 : 브로드캐스트용 (실제로 사용은 불가)
2. public Subnet크기는 작을수록 좋음
   
   
   

Internet Gateway

• Internet Gateway : Subnet에 인터넷을 연결하기 위한 EC2 또는 Lambda
  
  
  

• 특징

1. 수평 확장 가능
2. 가용성 및 중복성이 좋음
3. VPC와 별도 생성 필요
4. 하나의 VPC는 하나의 Internet Gateway만 연결 가능
5. Internet Gateway에 Internet을 허용하기 위해 별도 설정 필요 -> EC2인스턴스에 public IP 자동할당해도 Internet Gateway가 없으면 인터넷 연결 불가
6. Subnet내부의 인스턴스와 Internet Gateway를 연결하기 위해 라우팅 테이블 설정 필요 -> EC2 인스턴스와 라우터 연결 후, 해당 라우터를 Internet Gateway에 연결
   • 라우팅 테이블 생성 후, 서브넷에 할당
   • 라우팅 테이블에서 인터넷상 모든 IP를 Internet Gateway에 연결

Bastion Hosts

• Bastion Hosts : Bastion Host라는 보안 그룹으로 설정된 public subnet에 있는 EC2 인스턴스 -> 동일 VPC 내부의 private subnet의 EC2에 접근하기 위함

• 특징

1. Bastion Host 보안 그룹은 반드시 인터넷 엑세스를 허용해야 함
2. private Subnet 내부의 보안 그룹은 Bastion Host의 트래픽을 허용해야 함
   
   
   

NAT Instance (구형)

• NAT : Network Address Transition
• NAT Instance : private Subnet상의 EC2 인스턴스가 인터넷에 연결될 수 있도록 허용

• 특징

1. public Subnet에서 실행되어야 함
2. Source/Destination Check 비활성화 필요 -> NAT 인스턴스에서 네트워크 패킷을 재작성해야하기 때문
3. Elastic IP 할당 필요 -> VPC 외부로 트래픽이 전달될 때, Source IP가 할당된 Elastic IP가 됨 -> NAT 인스턴스의 네트워크 패킷 재작성
4. 라우팅 테이블을 수정하여 public/private Subnet 상의 EC2 트래픽이 NAT 인스턴스로 전송되도록 함 -> Destination이 어디일 때, Target으로 NAT Instance 설정
5. 현재는 NAT Gateway 서비스 권장 -> 가용성이 좋지 않기 때문
6. 보안그룹 및 규칙 관리 필요
7. EC2 인스턴스로 생성할 때, NAT 전용 AMI가 있음
   
   
   

NAT Gateway

• NAT Gateway : AWS 관리형 NAT Instance
  
  
  

• 특징

1. 고가용성
2. 관리할 필요 없음
3. 특정 AZ에 생성되고 Elastic IP를 할당받음
4. EC2 인스턴스와 같은 Subnet에서 사용할 수 없음 -> 다른 Subnet에서 접근할 때 도움됨
   • 일반적인 case : Private Subnet -> NAT Gateway -> Internet Gateway
5. 대역폭은 초당 5Gbps, 최대 45Gbps까지 확장 가능
6. 보안그룹 관리 필요 x
7. private Subnet의 Route Table을 수정하여 트래픽이 NAT Gateway로 갈 수 있게끔 설정

• NAT Gateway의 고가용성

1. 단일 AZ에서 복원 가능 -> AZ가 중단되었을 경우를 대비하여 Multi-AZ 배치 가능
2. Multi-AZ일 때, AZ간 서로 연결할 필요 없음

• NAT Gateway vs NAT Instance

Security Groups and NACL (Network ACL)

• NACL : Subnet 보안 Level, Subnet을 오가는 트래픽을 제어하는 방화벽이라 보면될 듯
  
  
  

• Incoming Request : 요청이 Subnet으로 들어가기 전에 NACL로 이동 (요청이 허용되지 않으면 Subnet으로 못들어감) -> NACL을 통과하면 Security Group 인바운드 규칙 검증

• Outbound Request : Security Group 아웃바운드 규칙 검증 -> Security Group을 통과하면 NACL 아웃바운드 규칙 검증

• 특징

1. NACL은 무상태 Security Group은 상태유지 -> Inbound 규칙이 허용되면 Outbound 규칙은 자동으로 허용됨 (상태유지) -> NACL Outbound 규칙은 검증 필요 (무상태)
2. Subnet마다 1개의 NACL 할당 -> 새로운 Subnet 생성 시, Default NACL 할당
3. NACL의 우선순위는 index가 낮을수록 높음
4. Subnet 수준에서 특정 IP를 제한하는 데 적합함
5. 우선순위가 높은 Rule중 맞는 Rule이 있다면, 후순위의 Rule은 검증하지 않음
6. 마지막 우선순위 Rule은 모든 요청을 제한하는 Rule
   
   
   

• Default NACL

1. 인바운드와 아웃바운드에 대한 모든 요청을 허용
2. 수정하지 않는 것을 권장
   
   
   

• 임시포트

1. 클라이언트는 규정된 포트로 접근 (ex. HTTP : 80)
2. 서버가 클라이언트에 응답을 주려면 포트가 있어야하는데, 클라이언트는 기본적으로 개방된 포트가 없어서 클라이언트가 서버에 접속할 때 자체적으로 특정 포트를 열게됨 -> 임시포트, 연결되는 동안만 열려있음
3. 운영체제에 따라 임시포트의 범위는 달라짐 (ex. Windows 10 : 49152 ~ 65535)

• NACL with 임시포트
  : client측에서 server의 응답을 받기 위해 client측 Subnet Inbound Rule에 임시포트 범위를 허용하고, server측 Subnet Outbound Rule에 임시포트 범위를 허용해야 함

• Security Group vs NACL

VPC Peering

• VPC Peering : 다양한 region/계정에서 생성되는 VPC를 AWS 네트워크를 통해 연결하고 싶을 때 활용 -> 연결되는 VPC가 모두 같은 네트워크에 있을 수 있도록 함
  
  
  

• 특징

1. VPC Peering이 필요하다면 CIDR이 겹치지않도록 설정해야 함
2. VPC Peering은 무조건 직접 연결되어 있어야 함
3. VPC Peering 이후 Subnet마다 Route Table을 업데이트 해야 Subnet 내부의 EC2 인스턴스간 통신이 가능해짐
4. 다른 계정간에도 통신 가능
5. Security Group 참조 가능

VPC Endpoints

• VPC Endpoints : AWS 네트워크를 통해 VPC에서 AWS 서비스를 이용할 수 있도록 해주는 서비스

• 특징

1. public internet이 아닌 AWS 네트워크를 통해 AWS 서비스 접근 가능 (AWS PrivateLink)
2. 거쳐가는 노드가 적기 때문에 internet보다는 비용 효율적
3. 에러 발생 시, VPC DNS 설정이나 Route Table 확인하면 됨
   
   
   

• Types of Endpoints

1. Interface Endpoints (PrivateLink)
   • ENI 프로비저닝
   • ENI : VPC의 Private IP Address, AWS의 Entry Point -> Security Group 설정 필요
   • ENI 비용 청구는 시간 단위의 데이터 처리량에 따라 달라짐
2. Gateway Endpoints
   • Gateway 프로비저닝
   • Gateway는 Route Table의 대상 (IP or Security Group or Gateway)
   • Amazon S3와 DynamoDB에 활용 가능 -> 해당 서비스에서 Interface Endpoint가 권장되는 경우는 온프레미스 or 다른 VPC에 접근해야할 경우
   • 요금은 무료
   • Auto Scale 가능 -> Route Table만 수정하면 됨

VPC Flow Logs

• VPC Flow Logs : Interface로 들어오는 IP 트래픽에서 정보를 확인할 수 있음 (VPC/Subnet/ENI level)
  
  
  

• 특징

1. S3, CloudWatch Logs, Kinesis Data Firehose에 전송 가능
2. AWS 서비스로의 트래픽으로부터 정보를 캡처 (ELB, RDS, ElastiCache, Redshift, NATGW 등)
3. VPC Flow Logs에 쿼리하는 방법 : Athena + S3, CloudWatch Logs Insights (스트리밍 분석)
   
   
   

• VPC Flow logs Syntax

• VPC Flow logs를 이용하여 Security Group과 NACL issues 해결하는 방법

1. ACTION 필드 확인
   • Inbound REJECT : 외부로부터 EC2 인스턴스로 들어오는 트래픽이 제한됨 -> NACL or SG이 거부
   • Inbound ACCEPT, Outbound REJECT : NACL issue -> SG는 상태유지
     
     
     

• VPC Flow logs Architecture

Site-to-Site VPN

• Site-to-Site VPN : AWS 외부 온프레미스 Data Center와 VPC를 private으로 연결하기 위한 VPN

• 특징

1. public internet을 거치지만, VPN연결이므로 암호화되어 있음
2. 필요한 것
   • Virtual Private Gateway (VPG) : VPN역할을 하는 Gateway로 VPC에 연결됨
     • 해당 Subnet Route Table의 Route Propogation 활성화 필요
   • Customer Gateway (CGW) : VPN에 연결하기 위한 고객측 Gateway -> AWS에서 생성
     • IP주소 확인 (VPG와 연결할 용도) -> private으로 유지하고 싶다면 NAT 장치를 활용하게 됨 (NAT 장치의 IP가 public용도로 활용됨)
       
       
       

• AWS VPN CloudHub

1. 여러 VPN연결을 통해 안전한 통신을 보장
2. 저비용의 Hub&Spoke 모델
3. 고객 네트워크 간에도 VPN을 통해 통신 가능
4. 모든 트래픽은 public internet을 경유
5. 방법 : VGW에 여러 VPN연결을 생성한 후에 동적 Routing을 활성화하고 Route Table을 설정하면 됨

Direct Connect (DX)

• Direct Connect (DX) : 사설 Data Center에서 VPC로의 전용 private connect 제공

• 특징

1. 방법 : VPC에 Virtual Private Gateway (VPG) 생성 -> Direct Connect (DX) 생성 -> 외부 온프레미스에서 DX를 통해 private AWS Resource 접근 가능
2. public internet을 거치지 않음
3. 큰 데이터를 처리할 때 속도가 빠름
4. 비용 절약 가능
5. IPv4, IPv6 모두 지원
6. private resource에 접근할 때에는 Private Virtual Interface 사용
7. public resource에 접근할 때에는 Public Virtual Interface 사용
8. 암호화 기능이 없지만, private 전송은 보장됨 -> 암호화가 필요할 경우, DX + VPN 결합 방법이 있음
   
   
   

• Direct Connect Gateway
  : 다른 region에 있는 하나 이상의 VPC와 연결해야할 때 활용

• Connection Types : 연결을 새로 만들 때, 최소 한달이상 걸림

1. Dedicated Connection
   • 1Gbps ~ 100Gbps 용량
   • 물리적 전용 이더넷 포트 할당
2. Hosted Connection
   • 50Mbps ~ 10Gbps 용량
   • 필요 시, 용량을 증설하거나 감축시킬 수 있음
     
     
     

• Resilincy (복원력)
  : Multiple DX 설치 (Multiple Connection Location and Multiple Connection)

• VPC + DX의 backup
  : VPC, DX 둘 중 하나가 문제가 생기면 서로 전환하면서 장애복구 가능

Transit Gateway

• Transit Gateway : 여러 VPC를 연결하기 위한 Gateway -> VPC간 peering 때문에 야기되는 복잡한 AWS 네트워크 토폴로지를 보완 (mesh -> 중앙집중형?)
  
  
  

• 특징

1. region간 활용 가능
2. 계정간 활용 필요할 시에는 Resource Access Manager 설정
3. Transit Gateway의 Route Table을 통해 Routing 설정 가능
4. AWS 유일 IP Multicast 지원

• Use case1 : ECMP 활용하여 Site-to-Site VPN 대역폭 늘리기
  => ECMP (Equal-cost multi-path, 여러 최적 경로를 통해 패킷을 전달하는 Routing 전략) : Site-to-Site VPN을 활용할 때 VPC에 있는 두 개의 터널중 하나만 사용하지만, Transit Gateway를 경유하는 경우에는 두 개의 터널을 동시에 사용함 (Transit Gateway의 전이특성 때문) -> Transit Gateway를 이용하면 다수의 VPN을 만들 수 있고, 두 번째 VPN을 만드는 경우에는 4개의 터널이 생김 -> 연결 처리량 증가

• Use case2 : 계정간 Direct Connect (DX) 공유 (Transit Gateway의 계정 공유 특성 활용)

Traffic Mirroring

• Traffic Mirroring : VPC에서 네트워크 트래픽을 수집하고 검사하되 방해되지 않는 방식으로 실행하는 기능

• 특징

1. 관리중인 Security Appliance대로 트래픽을 라우팅 (Traffic Mirroring Routing 설정) -> 수집하려는 트래픽이 있는 Source측 ENI 정보를 정의하고, 어디로 트래픽을 보낼지 Target ENI or NLB 정의해야 함 -> Target에는 트래픽을 분석하는 Software가 있음
   
   
   

VPC용 IPv6

• IPv6 특징

1. private 전용 ip가 따로 있진 않음
   
   
   

• 특징

1. private IPv4 주소, public IPv6 주소를 만들어 동시에 사용 가능
   
   
   

Egress-only Internet Gateway (송신 전용)

• Egress-only Internet Gateway : IPv6 아웃바운드 연결을 허용하고 동시에 인터넷이 인스턴스로 IPv6 연결이 불가하도록 제한함

• 특징

1. IPv6 트래픽에만 사용 가능
2. 라우팅 테이블 업데이트 필요
   
   
   

• IPv6 라우팅

AWS 네트워크 비용

1. public internet 보단 private AWS 인프라가 네트워크 비용이 절감됨
2. 동일 가용영역 내에서는 네트워크 비용 무료

3. AWS에서 public으로 보내는 트래픽은 비용발생
4. public에서 AWS로 들어오는 트래픽은 무료

5. Transfer acceleration 기능은 추가비용 발생
6. S3 -> CloudFront 비용은 무료
7. CloudFront에서 인터넷으로 보내는 비용(GB당 0.085달러)이 S3에서 인터넷으로 보내는 비용(GB당 0.09달러)보다 저렴

8. NAT Gateway vs Gateway VPC Endpoint

AWS Network Firewall

• AWS에서 제공하는 네트워크 보호 방법

1. NACL
2. VPC Security Group
3. AWS WAF (취약점 공격 보호)
4. AWS Sheild (DDoS 공격 보호)
5. AWS Firewall Manager
   
   
   

• AWS Network Firewall : VPC의 Inbound/Outbound 트래픽을 모두 감시함

• 특징

1. 내부적으로 AWS Gateway Load Balancer 사용
2. 네트워크 3계층부터 7계층까지 모두 보호
3. 여러 계정과 여러 VPC에 모두 적용
4. 수천개의 규칙을 생성할 수 있음
5. IP/Port/Protocol/도메인별 필터링 가능
6. 패턴매칭 방식으로 필터링 가능

암호화 종류

• 전송중 암호화 (TLS/SSL)

1. public network를 경유하게 되면 source-target사이의 중간 서버를 이용하게 되는데, 해당 서버를 통해 중간에 패킷이 탈취되어 정보가 유출되는 것을 방지하기 위해 활용
2. 인증서를 통해 암호화/복호화 진행
3. 전송중 암호화가 적용된 경우, HTTPS 프로토콜 활용

• 저장중 암호화 (Server-Side 암호화)

1. 서버가 데이터를 받은 후 어딘가로 저장되기 위해 암호화
2. 저장된 암호화 데이터를 고객에게 응답으로 주기 위해 복호화
3. 암호화/복호화는 특정 key를 통해 진행 (특정 key를 관리하는 방법은 다양함)

• Client-side 암호화

1. 서버는 해당 암호화 데이터를 복호화할 수 없음 (only client) -> 서버를 신뢰할 수 없는 경우에 활용
2. 암호화 key도 client에서 관리

KMS (Key Management Service)

• 특징

1. KMS의 권한기능이 IAM과 통합되어 있음
2. KMS Key를 이용한 API호출은 모두 CloudTrail에 의해 모니터링됨
3. 활용이 간단함 (EBS에 KMS적용을 위해 활성화 체크만 하면 됨)
4. API호출을 통해서도 KMS Key 활용 가능
   
   
   

• KMS Keys Types

1. Symmetric (대칭, AES-256 key)
   • 하나의 key로 암호화/복호화 모두 수행
   • key 자체에 직접 접근은 불가하나 key관련 AWS API를 이용할 수는 있음
2. Asymmetric (비대칭, RSA & ECC key pairs)
   • key 2개, 하나는 암호화를 위한 public key, 하나는 복호화를 위한 private key
   • public key는 직접 접근 가능하나, private key는 API를 이용한 접근밖에 허용하지 않음
   • AWS Cloud 외부의 사용자가 KMS key를 이용해 암호화하려는 경우 주로 활용됨
     
     
     

• KMS Key 종류 (서비스에 대한 API 호출 건당 비용 청구)

1. AWS 소유 key
   • SSE-S3, SSE-SQS, SSE-DDB (DynamoDB) : SSE 타입의 암호화 사용
   • 사용자가 볼 수 없음
2. AWS 관리형 key
   • aws/service-name
   • 자동 key rotation
3. 고객 관리형 key
   • 한달에 1달러 이상의 비용
   • 수작업 key rotation -> alias 설정 필요
     
     
     

• region단위의 KMS key 다른 region으로 이동 방법

1. KMS key가 저장되어 있는 EBS 볼륨의 Snapshot 생성
2. 생성된 Snapshot을 다른 region으로 옮길 때, 해당 region의 KMS key로 Snapshot 암호화
3. EBS Volume을 생성할 때, 해당 region의 KMS key로 복호화

• KMS Key Policies

1. KMS Key에 대한 접근을 관리하기 위한 정책
2. KMS Key에 대한 정책이 없을 경우, 아무도 해당 Key에 접근하지 못함
3. Default Policy
   • 계정에 있는 모든 사람들이 KMS Key에 접근할 수 있음
4. Custom Policy
   • KMS에 접근할 수 있는 사용자와 Role을 정의
   • Key를 누가 관리할 수 있는지 정의
   • 다른 계정에서 Key에 접근하려는 경우 유용한 정책 (ex. 암호화된 Snapshot을 계정간에 복사하고 싶을 때 사용)
     
     
     

• 교차계정을 위한 KMS Key Policy

KMS Multi-Region Keys

• 특정 Region에 기본키를 두고 다른 다수의 Region에 해당 키를 복제하는 방식 (key id가 모두 동일)

• 특정 region에서 암호화 후, 다른 region에서 복호화 가능 -> not global

• 각 region의 key는 각각 자체적인 정책으로 독립적으로 관리됨
• 특정 사례를 제외하고 단일 region key 활용 권장

• Use case : DynamoDB Global Tables and KMS Multi-Region Keys Client-Side Encryption
  : Client-Side Encryption 사용을 통해 데이터의 특정 필드(컬럼)나 속성을 DB관리자로부터 보호 (client에서만 복호화 가능), Multi-Region의 Global DynamoDB 데이터에 접근 가능

S3 Replication Encryption

• S3 복제가 생성될 때, 암호화되지 않는 객체와 SSE-S3로 암호화된 객체는 복제됨
• SSE-KMS로 암호화된 객체를 복제할 때에는 target bucket에 대해서 어떤 KMS Key를 사용할 것인지 선택하고 활성화해야 함.
• target KMS key에 KMS Policy 적용 필요
• 복제 시, 암/복호화를 위해 IAM Role 생성 필요
• S3에 Multi-Region key 적용은 가능하나 실질적인 효과는 없음
  
  
  

AMI Sharing Process Encrypted via KMS

• A계정의 암호화된 AMI를 B계정의 EC2에서 실행하는 방법

1. AMI는 KMS key로 암호화되어 있음
2. B계정의 Launch Permission에서 실행하고자 하는 AMI를 허용
3. KMS key 공유를 위해 default key policy 적용
4. B계정에서 A계정의 key를 활용할 수 있도록 IAM Role 생성 (DescribeKey, ReEncrypted, CreateGrant, Decrypt API)

SSM Parameter Store (SSM)

• SSM Parameter Store (SSM) : application의 설정을 KMS key를 통해 암호화하여 저장할 수 있는 store

• 특징

1. App의 설정이나 secret을 암호화하여 저장
2. Serverless
3. 확장성, 내구성
4. 저장된 설정의 version을 추적할 수 있음
5. IAM을 통한 보안설정 가능
6. EventBridge를 통한 알림 기능 가능
7. CloudFormation을 통해 SSM의 매개변수가 입력될 수 있음
8. AWS 계정 내 모든 파라미터를 중앙에서 한번에 관리
   
   
   

• SSM 계층 구조
  : SSM 저장소를 구조화할 수 있음, 디렉토리 접근 형태로 SSM저장소에 접근하여 원하는 파라미터 정보를 가져올 수 있음

• Secret Manager Tier

• 고급 tier에서만 사용할 수 있는 Parameter Policy

1. TTL를 파라미터로 입력할 수 있음 -> 비밀번호와 같은 정보를 update하거나 삭제하도록 강제 -> SSM으로 TTL설정을 강제한 후에 EventBridge를 통해 TTL 만료여부를 확인하여 알림

AWS Secrets Manager

• AWS Secrets Manager : AWS 암호 저장 서비스 (ex. DB 계정 비밀번호 등)
  
  
  

• 특징

1. 특정 주기마다 강제로 암호를 교체하는 기능이 있음
2. 자동 암호 변경을 위해 Lambda Function 정의 필요
3. RDS, Aurora 등과 호환 가능 -> 호환되는 서비스에 접근하기 위한 암호를 저장하고, 해당 암호가 변경되었을 때, RDS와 같은 서비스에도 동기화됨
4. 암호는 KMS를 통해 암호화됨
   
   
   

• Multi-Region Secrets

1. 다른 Region에 암호 복사 -> 기존 암호를 다른 Region에 동기화하여 복사 진행
2. 기존 암호에 문제가 생기면 다른 복제된 암호가 Primary로 승격됨
3. 재해복구 전략 수립 가능
   
   
   

AWS Certificate Manager (ACM)

• AWS Certificate Manager (ACM) : TLS인증서를 AWS에서 프로비저닝하고 관리 및 배포하게 해줌 -> HTTPS의 endpoint가 되는 ALB가 직접 ACM에 접근하여 TLS를 프로비저닝하고 관리 및 배포할 수 있게됨

• 특징

1. public/private TLS 모두 지원
2. TLS 자동 갱신기능
3. ELB에 TLS 인증서를 불러올 수 있음 (CLB/ALB/NLB)
4. CloudFront, API Gateway, APIs 등에서도 통합 가능 (EC2와는 통합 불가)
   
   
   

• Public 인증서가 요청되는 과정

1. 인증서가 포함한 도메인의 목록 나열
2. 유효성 검증방법 (DNS 검증, EMAIL 검증) 결정 -> 관리자 선택
   • DNS 검증의 경우, 해당 DNS 구성에서 CNAME 레코드를 생성하여 도메인 소유권을 증명해야 함 -> Route53 + ACM
3. 유효성 검증이 완료되면 인증서가 발행됨
4. 발행된 인증서는 자동 갱신 목록에 추가됨
   
   
   

• ACM으로부터 public 인증서를 가져오는 방법

1. ACM 외부에서 생성된 인증서를 ACM으로 가져올 수 있음 -> 자동갱신은 불가
2. 인증서 만료 45일전부터 만료메일 발송에 대한 알림을 EventBridge에 전송 -> EventBridge는 SNS나 SQS, Lambda를 통해 트리거 발생
3. AWS Config를 통해 인증서 만료 규칙을 설정 (acm-certificate-expiration-check) -> ACM 서비스를 검사하여 해당 규칙에 위배되는 인증서가 있을 경우, EventBridge에 이벤트 전송

• ACM + ALB : HTTP요청이 오면 ALB가 HTTPS로 리다이렉트 해줌

• ACM + API Gateway

1. Endpoint 유형
   • Edge-Optimized (default) : for global client, 요청을 CrontFront Edge Location에 우선적으로 보내지게 하는 방법이고 이후 하나의 Region에 있는 API Gateway에 요청이 전달됨
   • Regional : client와 API Gateway가 같은 region에 있는 경우, CloudFront 사용은 불가하지만 자체 CloudFront 캐싱 및 배포전략을 사용할 수는 있음
   • Private : VPC endpoint인 ENI를 통해 VPC 내부에만 접속할 수 있음 -> API Gateway에 대한 리소스 정책 필요
2. 통합 방법
   1. API Gateway에 사용자 지정 도메인을 정의함
   2. Edge-Optimized 유형의 경우, CloudFront로 먼저 요청이 전달되기 때문에 TLS 인증서(ACM)가 CloudFront와 같은 Region에 있어야 함
   3. Route53에 CNAME이나 A-Alias 레코드가 도메인을 가리키도록 설정
   4. Regional 유형의 경우, 요청이 바로 API Gateway로 가기 떄문에 TLS 인증서(ACM)가 API Gateway와 같은 Region에 있어야 함
   5. Route53에 CNAME이나 A-Alias 레코드가 도메인을 가리키도록 설정

Web Application Firewall (AWS WAF)

• Web Application Firewall (AWS WAF) : 7번째 계층(HTTP)에서 일어나는 웹 취약점 공격으로부터 application을 보호
  
  
  

• WAF 배포가 적용되는 서비스 (배포 후, ACL(Web Access Control List, IP주소기반 필터링하는 등의 규칙)이 적용되어야 함) -> ACL은 하나의 Region에만 적용되고 CloudFront는 Global로 적용됨)

1. ALB
2. API Gateway
3. CloudFront
4. AppSync GraphQL API
5. Congnito User Pool
   
   
   

• Use case : 고정IP가 지원되는 WAF적용된 Load Balancer -> 고정IP가 지원되는 NLB에는 WAF가 적용될 수 없음

• ALB활용 후, Global Accelator를 통해 고정 IP를 할당받은 후 WAF를 활성화 -> WAF에는 고정ip에 대한 ACL 정의

AWS Sheild

• AWS Sheild : DDoS 공격으로부터 보호하기 위한 서비스
  
  
  

• 특징

1. SYN/UDP 공격이나, layer3/layer4에서의 공격을 보호해줌 -> AWS Sheild Standard
2. 조직당 월 3,000달러, 정교한 DDoS 공격 방지, 자동으로 WAF규칙 생성, AWS DDoS 대응팀 항시 대기, DDoS 공격으로 인한 요금상승 감면 -> AWS Sheild Advanced
   
   
   

AWS Firewall Manager

• AWS Firewall Manager : AWS 조직내의 모든 게정에 대한 방화벽 규칙을 관리하는 서비스
  
  
  

• 특징

1. 보안규칙의 집합인 보안정책 설정 가능 -> WAF Rule, AWS Sheild Advanced, Security Groups, AWS Network Firewall (VPC Level), Route53 DNS Firewall 포함
2. region level의 정책 생성
3. 조직에 등록된 모든 게정에 적용
4. 새로운 ALB 서비스를 런칭한다고 해도 기존에 생성되어 있는 보안 규칙을 자동으로 적용시켜줌
   
   
   

• WAF vs Firewall Manager vs Sheild

1. WAF : Web ACL Rule 설정 -> 리소스별 보호 구성에 적절
2. Firewall Manager : 여러 계정에서 WAF를 사용하고 WAF 구성 적용 및 새로 생성된 리소스 보호를 자동화에 적절 -> 모든 계정과 모든 리소스를 기존 정책으로 자동 적용시켜줌
3. Sheild Advanced : DDoS 공격으로부터 고객을 보호하고 대응팀 지원, WAF규칙 자동생성 등의 부가적인 기능 제공
   
   
   

Best Practice for DDoS Resiliency Edge Location Mitigation

• Edge 유형에 따른 DDoS 보호 -> 어떤 백엔드를 활용하더라도 Edge에서 DDoS공격을 막을 수 있음

1. CloudFront
   • Shield 설정을 통해 SYN floods, UDP reflection과 같은 DDoS 일반 공격은 방어 가능
2. Global Accelerator
   • Shield와 완전히 통합되어 DDoS 공격 방어에 유용함
3. Route53
   • 도메인 이름 변환을 global로 설정 -> DNS에도 DDoS 보호 메커니즘 적용 가능
     
     
     

• 인프라 레벨의 DDoS 완화

1. CloudFront, Global Accelerator, Route53, ELB를 활용하면 많은 트래픽으로부터 EC2를 보호할 수 있음
2. ASG를 활용하면 많은 트래픽이 들어와도 스케일을 확장하여 방어할 수 있음 -> ELB가 여러 인스턴스에 부하를 자동으로 분산시킴
   
   
   

• Application 계층 방어

1. 악성 요청을 감지하고 필터링
2. 정적 컨텐츠는 CloudFront에서 보냄으로써 백엔드를 보호
3. ALB나 CloudFront + WAF를 사용 -> WAF에서 여러 관리 규칙을 설정하여 필터링
4. Sheild Advanced을 통해 자동으로 WAF 규칙 생성
   
   
   

• 공격 지점을 줄이는 방법

1. CloudFront, API Gateway, ELB 활용하여 백엔드를 숨김
2. 보안그룹과 네트워크 ACL 등 설정하여 특정 ip를 필터링
   
   
   

Amazon GuardDuty

• Amazon GuardDuty : AWS 계정을 보호하기 위한 지능형 위협 탐지 서비스
  
  
  

• 특징

1. 머신러닝 알고리즘을 통한 이상 탐지
2. 서드파티 데이터를 통한 이상 탐지
3. CloudTrail Event logs, DNS logs 등과 같은 log 데이터를 확인하여 비정상적인 API 호출을 탐지
4. EventBridge규칙을 설정하여 이상 탐지될 경우, 자동으로 알림을 발송할 수 있음 -> SNS, Lambda 활용
5. 암호화폐 공격을 방어하기 위한 좋은 서비스

Amazon Inspector

• Amazon Inspector : 자동화된 보안 평가를 실행할 수 있는 서비스
  
  
  

• EC2 예시

1. EC2에 SSM Agent 설치
2. Agent는 인스턴스 보안 평가 실시 (비정상 네트워크, 취약점 분석 등)
   
   
   

• 특징

1. EC2에 Agent를 설치하여 실행
2. 컨테이너 이미지를 ECR로 푸시할 때 실행 -> 이미지에 대한 취약점 검사
3. Lambda가 실행될 때 실행 -> 종속성 등에 대한 취약점 검사
4. 검사가 완료되면 AWS 보안 허브에 보고
5. 검사 결과를 Amazon EventBridge에 전송 -> 자동화 구현

Amazon Macie

• Amazon Macie : 머신러닝을 통한 패턴 매칭을 이용해서 AWS에 있는 고객의 민감 데이터를 발견하고 보호

AWS Organizations

• AWS Organizations : AWS 계정 조직
  
  
  

• 특징

1. 하나의 관리계정, 다수의 기타계정으로 이루어짐
2. Organization내 member계정의 비용은 하나의 관리계정에서 지불
3. 비용할인은 member계정의 서비스 사용 총액을 기반으로 매겨짐
4. reserved instances, saving plan 등 Organization내 다른 계정들과 공유됨 -> 다른 계정에서 사용하지 않는 reserved instance가 있을 경우, 다른 계정이 사용 가능

• 장점

1. 다수의 VPC를 가진 단일 계정에 비해 보안이 좋음 -> 계정간 독립성이 좋음
2. 모든 계정의 CloudTrail log를 중앙 계정의 S3로 전송가능
3. 모든 CloudWatch logs를 중앙 계정으로 전송 가능
4. 관리 계정에서 모든 멤버 계정을 관리 가능
5. SCP (Service Control Policies) 정의 가능, OU or 계정에 적용되는 IAM 정책 -> 관리계정에는 적용되지 않음 -> IAM 권한은 default가 모든 권한을 허용하지 않음
6. SCP는 차단목록과 허용목록 두 가지 전략이 있음
   
   
   

• SCP Example

IAM Conditions

• IAM Conditions : 특정 resource에 대한 IAM Policy의 조건
  
  
  

1. aws:SourceIp : API호출에서 Client ID를 제한하는 데 사용
2. aws:RequestedRegion : API호출에 대한 region 제한
3. ec2:ResourceTag : EC2 인스턴스에 한해 특정 tag를 가지고 있으면 명시되어 있는 action 허용/제한
4. aws:PrincipalTag : 해당 tag의 사용자는 명시되어 있는 action 허용/제한
5. aws:MultiFactorAuthPresent : MFA 여부에 따라 명시되어 있는 action 허용/제한
6. aws:PrincipalOrgID : AWS Organization 멤버 계정에만 리소스정책이 적용되도록 제한 (organization ID 명시 필요)

• IAM for S3 (bucket policy)

1. bucket 수준의 policy는 bucket을 특정해야 함 -> Resource에 특정 s3 arn(Amazon Resource Number)을 명시하면 됨 (ex. arn:aws:s3:::test -> test bucket)
2. 객체 수준의 policy는 object를 특정해야 함 -> ex. arn:aws:s3:::test/* -> test bucket내의 모든 객체
3. action example : s3:GetObject, s3:PutObject, s3:DeleteObject
   
   
   

IAM Roles vs Resource Based Policies

• Resource Based Policies을 지원하는 서비스 : S3, SNS topic, SQS queue, Lambda, CloudWatch logs, API Gateway etc...
  
  
  

• 서로 다른 계정간 접근일 경우

1. IAM Role을 이용한 접근 : 기존 권한을 모두 버리고 IAM Role을 통해 할당받은 권한만 활용 (기존권한 활용x)
2. S3 Bucket Policy를 통한 접근 (Resource Based Policies) : IAM Role을 할당받는 것이 아니기 때문에 기존 권한을 버리지 않음

• Amazon EventBridge를 사용할 때

1. target이 Resource Based Policies을 지원하는 서비스일 경우, RBP 설정 필요
2. target이 Resource Based Policies을 지원하지 않는 서비스일 경우, EventBridge에 IAM Role 설정 필요

IAM Permission Boundaries

• IAM Permission Boundaries : IAM의 최대 권한을 정의하는 기능, 해당 기능을 특정 IAM User에 할당하게되면, 할당된 권한 Boundary내의 권한만 얻을 수 있음 (Boundary 외의 IAM Role권한을 할당받을 경우, 권한 활용 불가)

• 특징

1. user/role에 한함 (group은 지원 안함)
   
   
   

• AWS Organization 권한과 중첩이 된다면?

1. Identity-based policy : user나 group에 할당되는 Identity기반 권한
2. Permission Boundary : user나 role에 적용
3. Organization SCP : 계정 내 모든 IAM User에 적용

-> Effective permission만 행사 가능

• 정책 평가 과정

1. Deny가 명시되어 있으면 Deny 우선
2. 명시적 Deny가 없어도 명시적 Allow 역시 없으면 실행 불가

AWS Control Tower

• AWS Control Tower : 규정을 준수하는 다중 계정의 AWS 환경을 손쉽게 설정하고 관리할 수 있음

• AWS Organization을 통해 계정을 자동 생성

• 정책 위반 감지 및 자동 교정 가능

• guardrail을 활용하여 지속적인 정책관리 가능

• 모든 계정의 규정 준수여부를 대시보드를 통해 모니터링 가능
  
  
  

• Guardrail : 특정 항목 일괄 제한 및 특정 유형의 규정 준수여부 모니터링, Control Tower에 대한 모든 계정의 거버넌스 제공

1. Prevent Guardrail : Control Tower에서 Organization에 SCP를 사용하도록 강제
2. Detective Guardrail : AWS Config 서비스를 활용하여 규정을 준수하지 않는 것을 탐지 (AWS Config 규정준수 여부 탐지 -> Guardrail trigger -> SNS...)

CloudWatch Metrics

• Metrics : AWS 서비스를 모니터링하기 위한 변수 값 (ex. CPUUtilization, Networkln...)
  
  
  

• 특징

1. 각 Metric은 각기 다른 namespace에 저장 (AWS 서비스당 namespace는 1개)
2. Dimension : 측정 기준, metric의 속성 (instance id, environment, etc...)
3. metric당 최대 측정 기준은 30개
4. metric은 timestamp가 필수
5. 많은 지표를 한번에 볼 수 있는 CloudWatch dashboard가 있음
6. Custom Metrics를 만들 수도 있음 (ex. EC2인스턴스의 Memory 사용량)
   
   
   

• CloudWatch Metric Streams : CloudWatch 외부로 스트리밍하는 기능

1. 원하는 AWS 서비스에 실시간 저지연 성능으로 Metric을 전달할 수 있음 (Kinesis Data Firehose, 타사서비스 등)
2. 모든 namespace의 metric을 전달하거나, 특정 namespace만 선택하여 metric을 전달할 수도 있음

CloudWatch Logs

• CloudWatch Logs : AWS의 app log를 저장할 수 있는 서비스

• Log groups : app log를 저장할 group, 이름은 보통 app의 이름으로 설정

• Log stream : app안의 인스턴스나 log files, containers 형태로 존재
  
  
  

• 특징

1. log 만료정책 정의 (1일~무한대)
2. 다양한 서비스로 log를 보낼 수도 있음
3. 모든 log는 암호화됨 -> KMS기반으로 암호화 설정 가능
4. CloudWatch에 Log 전송 방법
   • SDK
   • CloudWatch Logs Agent
   • CloudWatch Unified Agent
   • Elastic Beanstalk : app으로부터 직접 log를 수집하고 CloudWatch에 전송
   • ECS : Container로부터 log를 수집하여 CloudWatch에 전송
   • AWS Lambda : 해당 서비스 자체적으로 log 전송
   • VPC Flow Logs : VPC 메타데이터 트래픽 log 전송
   • API Gateway : 해당 서비스로 오는 요청에 대한 log를 모두 전송
   • CloudTail : 필터에 기반하여 직접 log 전송
   • Route53 : 모든 DNS쿼리에 대한 log 전송
5. CloudWatch Logs Insight 기능을 이용하여 log에 쿼리를 할 수 있음 -> 로그 데이터 검색 및 분석 가능 -> console상에서 샘플 쿼리 제공 -> CloudWatch 대시보드에 적용할 수도 있음 -> 다수의 log group을 쿼리할 수도 있음 -> 과거 데이터만 쿼리 가능
   
   
   

• S3 Export : Batch Export, 최대 12시간 소요, CreateExportTask API 활용

• CloudWatch Logs Subscriptions

1. log를 실시간으로 받아서 분석할 수 있음
2. Kinesis Data Streams, Kinesis Data Firehose, Lambda 등에 보낼 수 있음
3. Subscription Filter 기능을 활용하여 내보내려는 대상 log를 선별하여 보낼 수 있음
4. 원리 : Sender계정에서 Recipient계정의 서비스로 log를 보낼 때, Sender 계정에서는 Subscriptions Filter를 활용하게 되고, Recipient 계정에서는 가상의 Subscription Destination을 만들어 데이터를 받아 대상 서비스로 전달 -> Destination Access Policy를 통해 Subscriptino Filter를 허용해야 함 -> Subscription Destination에서 Kinesis 서비스로 접근하기 위한 IAM Role 생성 필요

• Aggregation Multi-Account & Multi-Region : CloudWatch Logs Subscriptions 기능 활용 -> 다양한 계정 및 다양한 region에서 온 CloudWatch Logs 데이터를 특정 계정의 하나의 Kinesis Data Streams 등에 통합할 수 있음

• LiveTail : Log Stream으로 전송된 log들을 실시간으로 console UI에서 확인할 수 있음
  
  
  

CloudWatch Agent

• 기본적으로 EC2에서는 CloudWatch로 어떤 log도 옮기지지 않음 -> EC2에 CloudWatch Agent를 실행시켜 CloudWatch로 push해야 함
• EC2 -> CloudWatch로의 IAM Role 생성 필요
• CloudWatch Agent는 온프레미스에서도 실행가능

• CloudWatch Logs Agent (older)

1. EC2나 온프레미스 서버를 위한 Agent
2. CloudWatch logs로 log만 보냄
   
   
   

• CloudWatch Unified Agent (통합 Agent, newer)

1. EC2나 온프레미스 서버를 위한 Agent
2. log만 보낼 뿐만 아니라 프로세스나 RAM과 같은 시스템 레벨의 metrics도 수집 -> CloudWatch logs에 통합 전송
3. Metric과 log 둘다 활용
4. SSM Parameter Store를 이용하여 Agent를 보다 쉽게 구성할 수 있음 -> 중앙 집중형으로 설정 가능
   
   
   

• CloudWatch Unified Agent - Metrics

1. 수집 metric
   • CPU
   • DISK
   • RAM
   • Netstat
   • Processes
   • Swap Space
2. 일반적인 EC2 모니터링 기능보다 더 많은 metric을 수집함 (좀더 세부적인 metric 수집 가능)
   
   
   

CloudWatch Alarms

• CloudWatch Alarms : Metric에서 나오는 알림을 트리거함 (샘플링, 퍼센티지, 최대, 최소 등 정의 필요)
  
  
  

• Alarm 상태

  1. OK : 알람이 트리거되지 않음
  2. INSUFFICIENT_DATA : 상태를 결정하기 위한 충분한 데이터가 없음
  3. ALARM : 기준 값을 초과하여 알림 전송

• Period : 얼마나 오랫동안 Metric을 평가할지? (10s, 30s, 60s의 배수 등)
  
  
  

• Alarm Targets

1. EC2 인스턴스에 대한 동작 (Stop, Terminate, Reboot 등)
2. Auto Scaling에 대한 동작 (Scale-out, Scale-In 등)
3. SNS에 알림 전송 (SNS를 Lambda와 연결하여 알림에 대한 동작까지 정의할 수 있음)
   
   
   

• Composite Alarms

1. 기본 CloudWatch Alarm은 싱글 metric 기반
2. 다수의 metric 기반일 경우, Composite Alarm 사용 필요 -> 다수의 다른 알람들의 상태를 모니터링하는 방식
3. 다른 알람들의 상태를 모니터링하면서 AND 또는 OR로 최종 상태 결정
4. 알람 노이즈를 줄이는 데 유용

• Use case : EC2 Instance Recovery

1. EC2 VM과 연관된 Instance status와 하드웨어와 연관된 System status 두 가지의 상태를 검사할 수 있음
2. 위 두가지 상태 검사에 대해 CloudWatch Alarms을 정의할 수 있음
3. 해당 알람이 발생하면 EC2 인스턴스 Recovery를 시작
4. 복구가 완료되면 SNS에 알림을 전송함으로써 복구완료를 알림

• Good to know

1. Metric Filter 기반의 Alarm을 생성할 수 있음 (ex. error와 같은 키워드를 많이 받은 경우에 Alarm을 발생시킴)
2. 알람 테스트를 위해 set-alarm-state라는 CLI 호출 사용 가능

EventBridge (formerly CloudWatch Events)

• 활용 유형

1. Schedule : Cron jobs

2. Event Pattern : 특정 패턴의 이벤트를 감지하여 정의된 서비스를 수행 (ex. root 계정 login 시, 이벤트를 감지하여 SNS Topic에 알림을 전송 -> 해당 알림을 받은 서비스가 이메일 발송)

3. Trigger Lambda : Lambda Function을 트리거할 수도 있음 (ex. 다수의 사용자에게 알림을 보내야 할 때, Lambda를 Trigger하여 다수 사용자가 구독 및 polling하는 SNS/SQS 알림을 발송하도록 함)
   
   
   

• EventBridge Rules

1. filter 설정 : S3 Bucket중 특정 Bucket의 이벤트만 수신
2. 여러 AWS 서비스가 source가 될 수 있음 + cron job
3. 발생된 이벤트를 EventBridge가 수신하면, JSON문서를 생성함 (JSON에는 이벤트가 발생한 인스턴스 유형과 인스턴스ID등의 정보가 담겨있음)
4. Destination 서비스에는 생성된 JSON을 전달함

• EventBridge Types

1. Default Event Bus : 위에서 살펴본 Bus
2. Partner Event Bus : 파트너사의 소프트웨어에서 발생한 이벤트도 수신 가능
3. Custom Event Bus : 자체적으로 만든 app에서 발생한 이벤트를 수신 가능
   
   
   

• 특징

1. 리소스 기반의 정책을 통해 다른 계정의 Event Bus에도 접근할 수 있음
2. 이벤트를 저장할 수도 있음 (모든/필터링된 이벤트 대상, 기간은 설정 가능) -> 저장된 이벤트를 다시 재생할 수 있음 (ex. Lambda Function의 버그를 수정하고 이벤트를 다시 발행)
   
   
   

• Schema Registry

1. 스키마 기반으로 App 코드 생성 가능
2. Event Bus의 데이터가 어떻게 정형화되는지 알 수 있음 (to JSON)
3. EventBrdige가 Event Bus로부터 어떻게 스키마를 추론하는지? 데이터는 어떻게 정형화하는지 파악 가능 -> JSON 데이터에 어떤 데이터가 어떤 데이터형식으로 구성되어 있는지 -> 해당 스키마를 통해 Java/Python 등 이벤트를 전송 받는 app 코드 생성 가능
4. 스키마 Versioning 가능 -> 스키마 반복 가능

• Resource-based Policy

1. 특정 Event Bus의 권한을 관리할 수 있음 (ex. 다른 region의 이벤트 허용/거부, 다른 계정의 이벤트 허용/거부 등)
2. Use case : AWS Organization에 Event Bus를 두고 모든 계정의 Event를 하나에 수집 -> 리소스기반 정책 추가 필요

CloudWatch Insight

• CloudWatch Container Insight
  : Container로부터 Metric과 log를 수집/집계/요약하는 서비스

• 활용 서비스

1. Amazon ECS
2. Amazon EKS
3. kubernetes platforms on EC2
4. Fargate
   
   
   

• 특징

1. Container버전의 CloudWatch Agent 활용 필요
   
   
   

• CloudWatch Lambda Insight
  : Lambda와 같은 서버리스 app을 위한 모니터링/트러블슈팅 솔루션
  
  
  

• 특징

1. 시스템 수준의 Lambda Metric을 수집/집계/요약
2. Lambda Function 옆에서 실행
   
   
   

• CloudWatch Contributor Insight
  : Contributor 데이터를 표시하는 시계열 데이터를 생성하고 log를 분석하는 서비스 (VPC log, DNS log 등)
  
  
  

• Use cases : 사용량이 가장 많은 네트워크 사용자를 찾을 수 있음, DNS log에서 오류를 가장 많이 생성하는 URL을 알 수 있음

• 특정 패턴(ex. 사용량이 많은 네트워크 사용자순)에 대해 상위 TOP N을 추출 후 분석

• CloudWatch Application Insight
  : app의 잠재적인 문제와 진행중인 문제를 분리할 수 있도록 자동화된 대시보드 제공
  
  
  

• app에 문제가 있는 경우, 대시보드를 통해 잠재적인 문제를 보여줌

• 대시보드를 보여줄 때, 내부적으로 SageMaker가 활용됨

• app 상태의 가시성을 높여줌

• 결론, 문제가 발생하면 대시보드에 표시하는 서비스

• 발견된 문제와 알림은 Amazon EventBridge와 SSM OpsCenter로 전달
  
  
  

CloudTail

• CloudTail : AWS 계정의 거버넌스, 컴플라이언스, 감사를 실현하는 방법
  
  
  

• 특징

1. 기본값으로 활성화되어 있음
2. 계정에서 일어난 이벤트와 API 호출이력, SDK, CLI 활용이력 등을 얻을 수 있음 -> 로그로서 발생
3. 발생한 log를 CloudWatch Logs나 Amazon S3에 Insert
4. 모든 region의 log를 하나의 S3에 넣고싶을 때, trail을 생성하여 하나의 region에 적용할 수 있음

• Event 유형

1. Management Events : AWS 계정 안에서 리소스에 대해 수행된 작업을 나타냄 (읽기/쓰기 이벤트 모두 나타냄)
2. Data Events
   • 기본 값은 로깅되지 않음 (고용량 작업)
   • S3 객체 조회/수정과 같은 데이터관련 작업을 나타냄
   • 읽기 이벤트/쓰기 이벤트 분리 가능
   • Lambda Function 실행 작업도 해당
3. CloudTrail Insights Events
   
   
   

• CloudTrail Insights

1. API 호출 등의 리소스 작업에 대해 정상/비정상을 확인할 수 있는 기능
2. 활성화하는 순간 비용 부과
3. log를 분석하여 정상기준을 수립한 후, 비정상적인 패턴을 탐지하는 원리
   • 부정확한 리소스 프로비저닝
   • 서비스 한도 도달
   • AWS IAM 액션의 폭증
   • 주기적 유지보수 활동 누락

• CloudTrail Events Retention

1. 기본적으로 이벤트는 CloudTrail에 90동안 보관 -> 더 오래 보관할 수도 있음 -> S3 전송 및 Athena 분석 필요 (Event 데이터 조회)

CloudTrail + EventBridge 사례

AWS Config

• AWS Config : AWS에 대한 감사와 규정준수 여부를 기록할 수 있게하는 서비스, 시간에 따른 변화를 기록 -> 문제가 있을 경우, 인프라를 빠르게 롤백하고 문제점 파악 가능
  
  
  

• 해결할 수 있는 유형

1. 보안 그룹에 제한되지 않는 SSH 접근이 있나?
2. S3 Bucket에 public access가 있나?
3. 시간이 지나며 설정이 변화한 ALB가 있나?
   
   
   

• 원리 : AWS Config에 등록된 rule에 대해 리소스의 변화가 생길 때마다 rule이 준수가 되고 있는지 확인함 -> 미준수 시, EventBridge, 자체 알림 기능 등으로 조치도 취할 수 있음
  
  
  

• 특징

1. 규정 준수 여부에 관계없이 시간에 따라 변화가 있을 경우, SNS알림 수신 가능
2. region별 구성 필요
3. 데이터 중앙화를 위해 region과 계정간 데이터 통합 가능
4. 모든 리소스의 구성을 S3에 저장하여 나중에 분석할 수도 있음
5. 규정미준수 때마다 트리거를 걸 수도 있음
6. EventBridge를 통해 트리거를 걸어 규정미준수에 대한 어떤 조치를 취할 수도 있음
   7, EventBridge를 사용하지 않고도 SNS로 알림을 직접 보낼 수도 있음
7. Custom Rule 작성 시, rule 미준수에 따른 action도 설정 가능

CloudWatch vs CloudTrail vs AWS Config

: ELB 예제