[AWS] SAA-C03 오답노트 (2)

 

 

 

대상 추적 정책 = CPU 사용률.

 

Amazon Web Services (AWS)에서도 ingress와 egress 용어가 사용되며, 주로 보안 그룹(Security Group)과 네트워크 액세스 제어 목록(Network Access Control List, ACL) 등과 관련이 있습니다.

 

1. ingress (인그레스):
 - AWS에서 Ingress는 허용된 트래픽이 보안 그룹이나 ACL을 통해 EC2 인스턴스 또는 다른 리소스로 들어오는 것을 나타냅니다.
 - 예를 들어, 특정 포트에서의 외부에서 내부로의 연결을 허용하거나, 특정 IP 주소 범위로부터의 트래픽을 허용하는 경우 Ingress 규칙을 구성할 수 있습니다.

 

2. egress (이그레스):
 - egress는 리소스에서 외부로 나가는 트래픽을 나타냅니다.
 - 보안 그룹이나 ACL을 사용하여 EC2 인스턴스 등에서 특정 목적지, 포트, 프로토콜 등으로의 트래픽을 허용 또는 차단할 수 있습니다.

 

프라이빗 서브넷의 인스턴스가 egress는 되지만 ingress는 막아야함. 이 때 NAT 게이트웨이를 사용한다. NAT 게이트웨이를 한 AZ에만 둔다면 거기에 장애가 발생한 경우 두 AZ의 프라이빗 인스턴스들이 egress가 안된다. AZ마다 NAT 게이트웨이를 둬야 함. 이후 서브넷 라우팅 테이블이 같은 AZ의 NAT 게이트웨이로 트래픽을 보낸다. NAT 인스턴스는 EC2 기반이라 직접 관리해야 하니 별로임. 

 

온프레미스에서 AWS 로 데이터 마이그레이션 할 때 DataSync를 사용한다. EC2 인스턴스가 EFS를 사용하는 구조로 호스팅되려면 EFS를 사용할 EC2 환경을 구성하는 것 까지가 작업의 일부. 

 

AWS Glue의 작업 북마크는 Glue가 이전 실행에서 어디까지 처리했는지를 상태로 기억한다. 이걸 사용하면 새로 추가된 데이터만 처리할 수 있음. Glue는 대규모 데이터에 대한 ETL 을 처리한다. 

 

AWS Shield Advanced는 모니터링을 통해 DDoS 공격에 대한 실시간 알림을 제공한다. GuardDuty는 AWS 계정 보호 서비스일 뿐임. CloudFront는 정적과 동적 모두 적용할 수 있으니 DDoS 공격에 대한 방어도 가능하다. DDoS는 PC IP를 일일이 차단하면서 막을 수 없는 공격이다. 

 

EventBridge가 Lambda를 호출하니 EventBridge 서비스가 Lambda 함수를 실행할 수 있다는 권한을 받아야 한다. 실행 역할이 아니라 리소스 기반 정책이 필요하다. 

 

API Gateway를 앞에 두고 Lambda가 처리하도록 하자. 데이터는 API Gateway로 REST API형태로 들어오게 된다. 서버리스 조합이니 피크 시간에 트래픽이 몰려도 자동으로 확장된다. 

 

웬만하면 그냥 SQS를 사용하고, 순서나 중복이 비즈니스 로직을 깰 때만 FIFO를 사용한다. FIFO는 표준 대기열보다 제약사항이 많으니 필요할 때만 사용한다. RDS 이벤트 알림은 데이터 안의 변화를 감지하지는 못한다. 그냥 데이터베이스 자체에 무슨 일이 있으면 알려줄 수 있지만.

 

커플링은 내부 구성 요소간 의존성이 높음을 의미하고 디커플링은 의존성이 적은걸 의미한다. 브라우저에서 S3로 이미지를 직접 업로드하도록 설정할 수 있음. Presigned URL을 사용하면. 

 

일단 ActiveMQ나 MySQL을 직접 EC2에 올리면 운영 복잡성이 높다. 그러니 Amazon MQ나 RDS로 전환하는게 좋음. 단순히 AZ에 EC2를 배치하는거로는 자동 복구가 안된다. Auto Scaling 그룹을 설정해 줘야 함. 

 

추가 워크로드에 사용할 네트워크 대역폭이 없다면 DataSync는 사용할 수 없다. 그러니 온프레미스에서 AWS로 데이터를 전송하는 Snowball 디바이스가 필요하다. 

 

인터넷을 거치지 않고 S3에 접근하려면 S3 게이트웨이 VPC 엔드포인트를 사용한다. 이러면 VPC와 S3 사이에 인터넷을 거치지 않는 통로를 만들 수 있음. 즉 EC2에서 바로 AWS 내부 네트워크를 통해 갈 수 있음. EC2에서 다른 네트워크 접근이 필요 없다면 프라이빗 서브넷으로 옮기는게 더 안전하다. 

 

CloudFront는 캐싱도 하지만 앞에 HTTPS도 적용하기도 함. 이러면 DDoS 방어도 된다. S3 정적 웹사이트 호스팅 자체는 HTTPS 지원하지 않으니 앞에 CloudFront를 두는게 표준이다. 그리고 애초에 WAF는 HTTPS를 제공하는 서비스가 아니다. SQL 인젝션같은 공격을 차단하는 보안 서비스임. 

 

CloudWatch Logs에는 구독 필터가 있음. 로그를 실시간으로 지정한 대상으로 스트리밍 해준다. OpenSearch Lambda Kinesis 모두 지원함. 이미 로그가 CloudWatch Logs에 있으니 이게 가장 나음. 

 

AWS Firewall Manager는 여러 계정과 리소스에 걸쳐 WAF 규칙을 중앙에서 관리하는 서비스로 한 곳에서 정의하면 그걸 여러 리전의 API Gateway에 적용할 수 있다. ACL은 Access Control List로 WAF에서 사용하는 규칙의 묶음이다. 

 

Global Accelerator는 NLB ALB EC2 등 엔드포인트를 하나로 묶어서 전 세계 사용자를 AWS 백본 네트워크를 통해 정상적인 리전으로 라우팅하는 서비스이다. 가장 가까운 엣지로 트래픽을 받아서 AWS 내부망으로 전달하고 장애 발생 시 다른 정상 리전으로 옮김. NLB와는 더욱 시너지가 좋다. Accelerator는 계층 4에서 사용하기 때문. Route 53은 DNS 기반이라 페일오버가 느리다. 만약 NLB가 아니라면 CloudFront랑 경쟁하게 된다. 

 

RDS의 암호화된 DB 인스턴스는 모든 로그 및 백업 스냅샷이 암호화된다. DB 인스턴스가 생성된 후에는 암호화가 불가능함. 이미 있는 인스턴스를 암호화하려면 스냅샷을 경유해야 함. 먼저 현재 인스턴스의 스냅샷을 뜨고 복사본을 만들면서 암호화를 활성화한다. 

 

중단되어도 부정적인 영향이 없다면 스팟 인스턴스가 매우 유력하다. 상태 비저장인것도 단서임. 람다는 최대 실행 시간 제한이 있다. 15분까지만 실행될 수 있음. 

 

Ingress와 Egress는 서로 다르다. Egress만 필요하고 Ingress는 필요없다면 프라이빗 서브넷에 EC2를 배치하고 NAT 게이트웨이를 사용한다. NAT 게이트웨이는 프라이빗 인스턴스의 아웃바운드 인터넷 접근은 허용하지만 직접 들어오는건 막아준다. 고가용성을 위해서는 각 AZ마다 프라이빗 퍼블릭 서브넷이 있어야 한다. 2개면 각각 2개씩 필요함. 

 

EC2 인스턴스 스토어는 EC2에 붙어있는 로컬디스크(물리). EBS는 네트워크로 연결된 별도의 스토리지임. 인스턴스 스토어는 네트워크를 타지 않으니 빠르다. 다만 휘발성이라 끄면 다 삭제됨. 

 

컨테이너화 되어있다면 ECS/EKS + Fargate. Aurora 는 여러 상용 DB와 호환되고 다중 리전과 AZ를 기본적으로 지원하니 인프라 및 용량 계획을 쉽게 다룰 수 있음. ECS와 EKS는 모두 컨테이너 오케스트레이션 서비스이고 Fargate는 컨테이너를 실행하는 방식이다. EC2 시작 유형도 가능함. 크기 개수 패치 확장을 직접 관리해야 함. Fargate는 서버리스 방식으로 EC2같은거 전혀 안써도 됨. ECS는 그냥 컨테이너 관리임. 다만 EKS는 쿠버기반이라 강력하지만 부담이 좀 된다. 

 

CloudFront가 S3를 오리진으로 쓸 때 CloudFront를 통해서만 접근 가능하게 하려면 OAI를 사용하는 것. CloudFront 배포에 붙는 특수 신원이다. 배포 ID 자체는 IAM Principal이 될 수 없다. S3 직접 접근 차단 + CloudFront 쓸 때는 OAI/OAC를 사용한다. 

 

Aurora에는 Oracle 엔진이 없다. MySQL과 PostgreSQL만 호환됨. 그러니 만약 Aurora에서 Oracle 쓰려면 Heterogeneous Migration이 필요함. RDS는 EC2 + EBS라고 보면 됨. 디비 지원도 많다. Aurora는 새로 설계한거임. 컴퓨트 스토리지 분리되어 있음. RDS Custom은 RDS와 EC2의 중간 지점의 서비스임. OS 접근이 필요한 레거시 Oracle을 옮길 때 좋음. 

 

비공개 연결 + 특정 서비스만 노출 + 회사 VPC에서 시작하면 PrivateLink를 사용한다. 회사는 VPC 엔드포인트 생성한다. 트래픽은 AWS 백본 네트워크만 타고 흘러감. NAT 게이트웨이 퍼블릭 IP 등 다른 것들은 전부 불필요하다. 

 

모든 알림을 놓치지 않아야 하니 수신자가 여러 명이여야 하고, 알림은 계정 관리자로 제한한다. Distribution List를 사용하면 여기로 온 메일이 등록된 관리자 여러 명에게 자동 전달함. 루트 이메일 주소는 유니크여서 여러개 만들 수 없음. 근데 서브어드레싱 사용하면 되긴 함. 

 

EC2 인스턴스에 RabbitMQ를 직접 운영하면 자체 관리형이고 Amazon MQ for RabbitMQ를 쓰면 AWS 관리형이다. 엔드포인트만 바꾸면 되지만 아마존이 알아서 관리해준다. SQS는 AMQP를 지원하지 않고 HTTP API를 쓴다. 그러니 별로임. Auto Scaling Group은 데이터를 복제하지 않음. 

 

SageMaker Pipelines는 S3 이벤트 알림의 대상이 될 수 없다. S3는 SNS SQS Lambda EventBridge에게만 이벤트를 보낼 수 있음. 다만 EventBridge는 보낼 수 있음. 

 

Computing Saving Plans는 비용 절감 가능한 유연 한 요금 모델으로 인스턴스 사용량에 따라 적용됨. Fargate Lambda EC2 모두 적용 가능함. 사용량을 예측할 수 있다면 할인받을 수 있다. 

 

항상 이게 오버킬은 아닌지 생각하기 RedShift를 도입한다면 별도 클러스터 비용이 상시 발생하고 ETL 파이프라인도 새로 구축해야 한다. 다만 Aurora 복제본에서 하면 이 네 가지를 처리하지 않아도 된다. 

 

AWS Amplify는 프론트를 빠르게 만들 때 사용함. 백엔드 구성하지 않고 인증 API 스토리지 붙이기 가능. 프론트는 Amplify 백엔드는 Beanstalk이다. 개발 테스트는 Beanstalk를 사용하면 환경을 쉽게 구축할 수 있음.

 

인스턴스를 여러개 두고 Auto Scaling 설정을 해 줘야 확장성이 보장된다. S3 Lifecycle은 같은 객체를 더 저렴한 스토리지로 옮기는 것. 원본 자체를 이동하지만 AWS Backup은 별도의 사본을 만들어 필요할 때 복원하는 작업이다. 

 

 대시보드는 시각화 도구지 경보가 아님. SCP는 계정의 권한 상한선을 정하는 정책이다. 여기서 거부되면 누구도 작업을 수행할 수 없음. Control Tower는 SCP를 포함한 멀티 계정 거버넌스를 자동화하는 상위 서비스이다. 

 

하루에 12시간만 쓰이는데 RDS는 24시간 돌아가면 12시간이 낭비된다. 껐다 켜서 인스턴스 요금을 50% 절감하면 됨. EventBridge 예약 규칙과 Lambda를 사용하면 스케쥴 기반 자동화를 구현할 수 있음. 서버리스는 관리할 인스턴스가 없어서 좋다. 

 

S3 Inventory는 S3에서 스토리지 관리를 지원하기 위해 사용하는 도구로 객체의 복제 및 암호화 상태를 감시하고 보고할 수 있음. 규정 준수 모드에서는 루트 계정 사용자를 포함해서 어떤 사용자도 보호 객체 버전을 삭제할 수 없다. 거버넌스 모드는 특별 권한자는 해제할 수 있고 보존 기간 단축도 가능하다. 

 

특정 국가라는 조건을 처리할 수 있는건 WAF 밖에 없다. 보안 그룹과 네트워크 ACL은 3계층과 4계층에서 동작하니 국가라는 개념은 7계층에서 처리하는 WAF 를 사용해야 함. 

 

HTTPS 는 전송 중 암호화라서 구간별로 보호된다. CloudFront에 도착하면 TLS가 종료되고 데이터는 평문이 된다. 다시 암호화해서 보내야함. 즉, 중간중간 평문으로 노출되는 순간이 있음. 필드 수준 암호화는 특정 필드만 골라서 RSA로 암호화한다. 

 

ALB는 리전 경계를 넘지 못하니 같은 리전 내의 AZ에만 대상을 등록할 수 있다. 리전을 나눈다면 리전마다 ALB가 필요함. Auto Scaling 그룹도 리전 내에서만 동작한다. 여러 리전에 걸치는건 불가능. 

 

Lambda는 요청이 몰리면 실행 인스턴스를 수천개까지 늘리는데 얘내는 자기만의 DB 커넥션을 열게 된다. 이러면 DB 커넥션 수 제한을 초과한다. 그러니 Lambda와 DB 사이에 커넥션 풀을 관리하는 RDS Proxy를 두는게 좋음. DynamoDB는 NoSQL이다. 

 

AWS 내부망을 타려면 VPC 엔드포인트를 사용해야 한다. DynamoDB S3같은 AWS 서비스는 VPC 안에 없다. VPC 밖에 있는 퍼블릭 엔드포인트를 가진 서비스임. 그러니 프라이빗에 있는 EC2가 DynamoDB에 접근하려면 VPC 밖으로 가야 함. VPC 엔드포인트는 AWS로 가는 전용 통로를 VPC 안에 뚫어준다. 

 

DynamoDB에 DynamoDB Accelerator를 사용하면 성능을 한 단계 업그레이드해서 읽기 중심 워크로드에서 성능을 극도로 끌어올릴 수 있음. 완전관리형이라 편하다. 

 

AWS Backup은 백업 프로세스를 간소화하고 백업을 다른 리전으로 자동 복사해서 EC2나 RDS에 대한 별도의 백업 프로세스 관리에 대한 오버헤드를 줄일 수 있다. Data Lifecycle Manager는 RDS 백업을 별도 리전에 복사하도록 설계하지 않음. 

 

IAM 정책을 EC2 인스턴스에 붙이는건 불가능. 정책은 권한을 기술한 JSON문서일 뿐이다. 역할은 정책을 담는 신원으로 AWS 리소스가 맡을 수 있는 자격을 의미한다. 

 

API Gateway와 NLB는 함께 사용할 수 있다. 계층이 다르니까. API Gateway는 인증 인가 응답 변환을 하고 NLB는 EC2 인스턴스에 트래픽을 L4에서 분산하는 역할을 수행함. 이 둘을 이어주는게 VPC Link이다. API Gateway는 VPC 바깥의 서비스라서 VPC에 접근할 수 없으니 이게  필요함. WAF는 L7에서 HTTP 프로토콜을 골라낸다. SQL 인젝션 등.. 이거는 API Gateway에다가 붙여야 함. 

 

읽기 및 쓰기 용량을 빠르게 확장해야 하면 Aurora가 아니라 DynamoDB를 사용해야 한다. Aurora Auto Scaling은 읽기 복제본만 늘리고 쓰기는 확장할 수 없음. 주문 데이터는 ID로 조회하는 단순 엑세스 패턴이니 굳이 RDB가 아니여도 상관없음. 

 

Lambda는 기본적으로 AWS의 VPC에서 실행된다. 그러니 사용자 VPC 안의 리소스에 접근할 수 없음. Lambda 설정에서 VPC 서브넷 보안 그룹을 지정하면 Lambda가 그 안에 ENI를 생성하고 프라이빗 IP를 가진다. 그럼 이제 VPC로 접근이 가능해짐. 

 

IAM은 이 작업을 할 권한이 있는지 확인한다. 403과 연관됨. 보안 그룹은 이 IP와 포트번호로 통신할 수 있는지를 확인한다. IP주소 포트 프로토콜을 사용함. AWS API 호출은 IAM을 확인해야 함. 포트 및 IP로 직접 연결할 때는 보안 그룹을 확인한다. takeRoleArn은 ECS에서 태스크 단위로 권한을 부여할 때 사용한다. 

 

Transfer Family는 완전 관리형 파일 전송 서비스이다. STFP로 업로드하면 그게 바로 S3 객체가 됨. S3 FIle Gateway는 SFTP를 지원하지 않음. 

 

DynamoDB의 TTL 속성을 사용하면 오래된 항목을 알아서 삭제해준다. 삭제는 쓰기 용량을 소비하지 않음. 온드맨드 요금에도 영향이 없음. Lambda로 삭제하는것도 좋아보이지만 호출 횟수가 크니까 최선은 아니다. 

 

배포 방법을 변경할 수 없으면 k8s를 유지해야 하고 EKS를 사용해야 한다. ECS로 옮기면 배포 방식이 완전히 바뀌게 됨. 코드 변경 불가능하니 MongoDB를 그대로 써야 함. DynamoDB를 사용할 수 없다. 다만 DocumentDB는 MongoDB 호환이라서 편하다. 

 

AWS Transcribe를 사용하면 다중 Speaker를 인식할 수 있다. Translate는 번역 서비스이고 Rekognition은 이미지 및 비디오 분석 서비스임. 

 

Cognito는 사용자 인증과 권한 부여를 관리해주는 서비스이다. AWS 계정이 없는 외부 사용자를 다룸. 토큰을 받고 임시 AWS 자격 증명으로 교환해준다. 

 

API Gateway에서 호스팅되는 REST API는 API Gateway에서 REST API 자체를 호스팅하는 것. 람다를 통해서 하든.. 스프링부트같은 서버가 있는게 아니다. 있었으면 NLB 뒤에 있는 EC2 같은 식으로 서술됨. 

 

PinPoint는 고객 참여 및 마케팅 커뮤니케이션 서비스로 사용자에게 메세지를 보내고 그 결과를 분석하는 역할을 수행함. 사용자가 SMS에 회신할 수 있어야 하는건 PinPoint 밖에 없음.

 

초대장 도착에 시간이 오래 걸린다면 요청은 SQS에 쌓이고 있음을 의미함. Consumer가 처리 속도를 못 따라가는거니까 Auto Scaling으로 확장해주면 된다. DAX는 읽기 캐시로 DynamoDB에서 사용함. 

 

Lake Formation은 데이터 레이크를 구축하고 중앙에서 권한을 관리한다. 내부적으로 Glue 데이터 카탈로그를 쓰고 그 위에 권한 계층을 얹음. 이러면 특정 팀에서는 특정 열을 제외한 데이터를 보도록 할 수 있음. 

 

EventBridge는 이벤트를 받아서 대상으로 라우팅하는 서버리스 이벤트 버스. CloudTrail은 API 호출을 기록하고 EventBridge는 그 기록을 실시간 이벤트로 흘려보냄. SNS는 pub-sub 으로 메세지 뿌리는 서비스임. EventBridge로 이벤트 감지하고 라우팅. SNS로 그 결과를 전달함. 

 

게이트웨이 엔드포인트에는 보안 그룹을 연결할 수 없음. 라우팅 테이블만 항목에 추가되는 방식이다. S3는 게이트웨이 엔드포인트와 인터페이스 엔드포인트를 모두 지원한다. 

 

ElastiCache로 세션 데이터를 관리하자. 세션을 인스턴스 안에 저장하지 말고. 보통 Redis 쓰긴 하는데 코드 변경 가능하니 ElastiCache쓰면 됨. 스티키 세션은 분산 세션 관리가 아니라 특정 사용자를 같은 인스턴스로 보내는 기능이다. 

 

유지 관리할 인스턴스당 허용 가능한 백로그인 대상 값과 함께 인스턴스 메트릭당 백로그를 사용한다. SQS 대기열을 사용하는게 올바른 방법은 맞음. 

 

여러 리전에 흩어진 리소스를 태그로 식별할 때는 Tag Editor를 사용한다. 여러 리전 여러 서비스의 리소스를 한 번에 검색하고 관리할 수 있음. CloudTrail은 API 호출 기록일 뿐이다. 리소스 목록을 지정하지 않음. CLI도 가능하지만 너무 느림. CloudWatch Logs 는 로그 분석 도구지 태그 정보는 없음. 

 

Glue는 csv 파일을 스캔해서 컬럼 이름과 데이터 타입을 자동으로 추론하고 테이블에 등록할 수 있음. 스키마를 사람이 정의하지 않아도 된다. 콘솔에서 소스와 대상을 지정하고 Parquet으로 출력형식을 선택해주면 끝임. Glue Studio를 사용하면 자동으로 다 처리된다. Glue는 Extract Transform Load를 해준다. Spark를 서버리스로 감싸준 것. 쿼리는 아니다. 작업 시작에 딜레이가 좀 있음. 배치 시스템임. 

 

S3는 생성 후 암호화 활성화가 가능함. 객체 하나하나를 암호화 할 수 있음. 기존 객체는 자기 자신 위에 복사하는 식으로 다시 쓸 수 있다. RDS랑은 좀 다르다. 

 

Route53은 DNS인데 DNS로 장애 조치를 처리함. 도메인 이름을 어떤 IP로 연결하는지에서 상황에 따라 그 대상을 바꿀 수 있으면 장애조치임. 같은 주소를 쓰는데 Route53이 가리키는 곳만 바뀜. 헬스체크하고 응답을 바꿔버리는거다. 리전간 트래픽 전환은 DNS 계층밖에 안되니 Route53이 그 역할을 수행함. Backup을 사용하지 않아도 Aurora Cross Region Replica를 사용하면 된다. 

 

클라이언트는 임시 포트를 열어서 접속한다. 서버가 응답할 때는 임시 포트로 보내야 함. 아웃바운드 응답의 목적지는 443이 아니라 임시 포트임. 32768 - 65535 가 임시 포트 범위임. 기존 보안 그룹은 모든 인바운드를 차단하니 443을 허용하는 규칙이 필요하다. 아웃바운드는 설정 안해도 됨. 기본 보안 그룹의 아웃바운드는 전체 허용임. 기본 NACL도 인/아웃 전체 허용한다. 그러니 아웃바운드는 아무것도 안해도 모든 트래픽을 허용함. 

 

        인터넷
          ↓
   ┌──────────────────┐
   │   서브넷 경계     │  ←  NACL (동네 입구 검문소)
   │  ┌────────────┐  │
   │  │   EC2      │  │  ←  보안 그룹 (집 현관문)
   │  └────────────┘  │
   └──────────────────┘

 

 

Network ACL은 서브넷 전체에 적용해 그 안의 모든 인스턴스가 영향받고 보안 그룹은 인스턴스 하나에만 적용된다. 

PC는 51234 포트에서 시작해서 웹서버의 443에 도착함. 인바운드 443 걸리니까 패스. 서버 응답 할 때는 443에서 51234로 나가니까 NACL 아웃바운드 규칙을 설정해야 한다. 소스는 사용자 컴퓨터이고 대상은 웹서버를 의미함. 

 

인메모리 작업은 메모리가 병목이니 메모리 최적화가 필요하다. M5는 범용이고 R5로 교체하면 좋음. CloudWatch는 기본적으로 메모리 사용률을 수집하지 않으니 에이전트를 인스턴스에 설치해야 한다. EC2 내장 메모리 메트릭이라는건 존재하지 않음. CloudFormation은 인프라를 코드로 정의하고 자동 배포하는 서비스로 IaC의 AWS 버전이라고 보면 됨. 저거로 만들고 손으로 수정하면 어긋나게 된다. 

 

정책은 문서고 역할은 정책을 담는 그릇이다. 정책을 연결한다는건 권한을 채우는 것. 다른 계정의 IAM 사용자를 내 계정 그룹에 추가하는건 불가능하다. 같은 계정 내의 IAM 사용자만 담을 수 있음. 권한을 주는 방법은 역할. 

 

Route53 라우팅 정책 중 Failover는 평소에는 한 곳만 하고 죽으면 대체로 전환함. 다중값 응답은 여러 IP를 한 번에 반환하고 클라이언트가 그 중 하나를 무작위로 선택한다. 가중치를 설정하면 지정한 비율대로 분배하고.

 

Redshift는 페타바이트 규모의 데이터 웨어하우스 서비스로 초고용량임. 분석 시 사용함. 

 

Elastic IP는 AWS 계정에 할당받아 계속 보유하는 고정 퍼블릭 IP를 의미한다. 인스턴스 껐다가 켜도 유지됨. VPC 피어링을 사용하면 내부망을 탈 수 있음. 두 VPC가 프라이빗 IP로 직접 통신한다. 다만 피어링 연결에는 보안 그룹이 없음. 라우팅 구성일 뿐이다. 필터를 걸 수 없음. 참고로 VPC에도 보안그룹을 적용하는건 불가능하다. 네트워크 단위로 걸 때는 NACL을 사용함. 

 

RDP SSH 연결은 AWS API를 호출하지 않음. 그냥 인스턴스 포트로 들어오는 TCP 연결일 뿐임. CloudTrail에도 아무런 기록도 남지 않으니 네트워크 수준에서 잡아야 한다. 그래서 EventBridge도 불가능함. 그러기 위해 VPC 플로우 로그를 확인해야 함. 

 

KMS는 암호화 키를 다룬다. 유휴 데이터를 암호화하는 역할임. ACM은 인증서를 다루고 전송 중 데이터를 암호화한다. 두 가지를 섞으면 완전한 암호화를 구현할 수 있음. KMS 는 인증서를 다루지 않고 ACM은 스토리지를 암호화 할 수 없음. Bitlockersㅡㄴ 윈도우의 하드드라이브를 잠구는 디스크 암호화 기능이다. 

 

Heterogeneous DB 이관은 DMS와 SCT를 사용해야 함. DataSync는 파일 전송 서비스지 데이터베이스 마이그레이션 도구가 아니다. 데이터 불일치를 피하기 위해 모든 테이블을 선택해야 한다. 

 

AWS에서 ingress는 무료고 egress는 과금된다. 그리고 같은 리전 안에서의 통신은 사실상 무료. 그러니 비용 절약을 위해 큰 데이터 흐름은 AWS 안에 두고 작은 흐름만 밖으로 내보내야 함. 동일한 리전의 위치에 있을 때 egress 단가가 가장 낮다. 

 

다중 AZ는 다중 리전이 아님. 서로 Orthogonal 하다. 스냅샷은 특정 시점에서 정지된 백업 파일으로 쿼리를 던질 수 없음. 사용하려면 복원 후 새 DB 인스턴스를 만들어야 함. 재해 복구용이지 상시 조회용이 아니다. 

 

Storage Gateway는 온프레미스가 이해하는 프로토콜을 AWS 스토리지로 번역하는 게이트웨이. 온프레미스에는 VM으로 배포하고 앱은 그대로 접근하는데 실제 데이터는 AWS에 저장된다. 

 

Dynamo는 서버리스, 키-값. MongoDB호환 및 문서는 DocumentDB, 관계 및 경로 탐색 추천은 Neptune, RDB는 RDS나 Aurora, q분석 및 OLAP 집계 쿼리는 Redshift.

 

프라이빗 서브넷에 있는 EC2도 ALB를 통해 인터넷 요청을 바을 수 있다. 다만 ALB는 퍼블릭으로 보내야 함. ALB와 대상 사이는 VPC 내부 통신임. ALB는 인터넷 연결을 자기 선에서 끊고 새로운 연결을 만들어 프라이빗 IP로 보낸다. 그리고 나서 EC2의 보안 그룹 인바운드에 ALB의 보안 그룹으로부터의 트래픽 허용 규칙을 설정해야 함.

 

RDS는 읽기 복제본을 만들 때 세 단계를 거친다. 스냅샷 -> 복제본 -> binlog 동기화. 자동 백업이 없으면 물리적으로 저게 불가능하다. 그러니 백업 보존 기간을 0 말고 다른 값으로 설정해야 하고 장기 트랜잭션을 종료시켜야 함. binlog 복제 활성화는 RDS가 알아서 활성화 해 준다. RDS인데 MySQL 내부 설정을 할 필요가 없음. 

 

앱이 AWS 내부에 있으면 EFS나 FSx를 붙이면 된다. FSx for Windows File Server는 SMB 프로토콜을 사용한다. 

 

인터넷 게이트웨이는 양방향이고 퍼블릭 IP가 필요하다. 이걸 서브넷에 붙이면 그 서브넷은 퍼블릭 서브넷이 되는거임. 다만 NAT 게이트웨이는 아웃바운드 전용이다. 외부가 먼저 연결하는건 불가능함. VPC가 IGW에 연결되어있어야 인스턴스가 네트워크와 통신할 수 있다. 인스턴스에 퍼블릭 IP가 있어야 한다. 보안 그룹과 ACL이 허용해야 한다. VPC와 인터넷 관문은 셋 뿐이다. 인터넷 게이트웨이, NAT 게이트웨이, 로드밸런서. 셋은 모두 퍼블릭 서브넷에 있고 EC2는 프라이빗에 남는다. NAT 인스턴스는 NAT 게이트웨이에 비해 더 많은 수동 구성이 필요하니 NAT 게이트웨이를 사용한다. 

 

보안 그룹 규칙에 인스턴스 아이디는 넣을 수 없음. VPC CIDR이나 서브넷 CIDR은 가능하지만 그닥임. 그러니 그냥 보안 그룹 ID를 소스로 설정하면 된다. 최소 권한 계층 간 통신이 나오면 보안 그룹 ID를 소스로 사용. 

 

CloudWatch 지표 스트림은 지표를 목적지로 흘려보내는 관리형 기능임. API 호출이 아니고 생기는 대로 밀어주는 방식. Auto Scaling 상태 데이터는 CloudWatch에 있음. 부트스트랩 스크립트로 Kinesis 에이전트를 설치하면 시작 속도에 영향을 주고 서버리스가 아니다. 

 

RDS 자동 백업의 보존 기간은 최대 35일이다. 그리고 Data Lifecycle Manager의 관리 대상은 EBS이다. RDS 스냅샷은 DLM으로 관리할 수 없다. 그러니 Backup이 필요함. 일일 일정 설정 가능하고 보존 기간도 지정할 수 있음. 리소스 할당도 알아서 해준다. 

 

IAM은 파일 하나의 접근 권한을 판단할 수 없다. 파일, 폴더 단위의 권한은 Active Directory가 다룬다. IAM은 파일 시스템을 다룰 뿐임.

 

DNS는 캐시된다. DNS가 로드밸런서 역할을 수행하는게 문제임. 인스턴스가 죽으면 Route53은 IP에서 그 응답을 빼는데, 그 IP를 받아간 클라이언트들은 TTL 동안 캐시하기에 사용자들이 죽은 서버로 계속 접속함. ALB는 이 문제가 아예 없다. DNS 답변은 항상 ALB 주소 하나로 고정되니까 바뀌지 않음. 

 

오리진은 원본 서버를 의미한다. CloudFront는 사본만 가지는 캐시임. 만료됐을 때 가져오는 곳을 오리진이라고 부름. 웬만하면 EC2 대신 ALB를 오리진으로 설정하는 편이다. VPC 오리진이 가장 깔끔한 방법이긴 함. 이제는 오리진이 반드시 퍼블릭일 필요는 없음. 

 

실시간 트래픽은 캐싱이 의미가 없음. 오히려 캐싱이 별로임. CloudFront는 HTTP 7계층만 지원하는데 게임은 TCP/UDP 커스텀 프로토콜을 사용한다. Global Accelerator는 4계층에서 작동함. 

 

Firehose에는 Record Format Conversion 기능이 있어서 Parquet 형식으로 데이터를 저장할 수 있고 암호화도 SSE로 가능함. S3로 자동 전달도 해준다. 완전 관리형 ETL + 적재 파이프라인이다. 최소한의 운영 오버헤드에 적합함. Kinesis Data Stream은 원시 스트림 저장소로 둘은 아예 계층이 다른 서비스임. Data Stream은 데이터 보관도 되지만 Firehose는 그냥 전달만 하고 보관 개념이 없음. 순서가 중요하거나 실패 처리가 필요하면 Data Stream을 사용한다. EMR은 EC2 클러스터여서 운영 오버헤드가 크고 배치 처리 엔진임. 그러니 Kinesis Data Analytics로 실시간 분석을 처리한다. 

 

ElastiCache는 자주 액세스하는 데이터를 캐싱해서 읽기 성능을 향상시킬 수 있지만 아키텍처를 변경해야 함. RDS Proxy는 앱과 DB 사이에 놓는 커넥션 풀이다. 소수의 실제 DB 커넥션으로 묶어서 재사용성을 높임. 

 

S3에서 암호화를 켠다고 해도 그건 S3에 도착한 후에 암호화되는거임. 업로드되기 전에 암호화 되어야 하면 클라이언트에서 직접 암호화를 수행해야 한다. 

 

RTO는 복구 시간 목표 RPO는 복구 지점 목표. 전략을 정리하자. Backup & Restore는 백업 데이터만 있고 인프라가 없으니 RTO는 오래 걸린다. Pilot Light는 DB만 복제 중이고 서버는 꺼져 있음. RTO는 수시간 걸린다. Warm Standby는 축소된 규모로 가동 중이다. RTO는 수 분. Multi-Site Active는 그냥 되고 있다는거임. RTO 0분. RDS 다중 AZ는 한 리전 기능이다. Aurora는 여러 리전 간 복제를 지원하니 이걸 사용하자. 

 

오전 중반까지는 잘 돌아가지만 출근 러시에 부하가 오고 확장이 뒤늦게 따라간다면 CPU 임계값이 너무 높고 Cooldown 시간이 너무 길다는거임. 대상을 추적하는게 좋음. 

 

RDS 스토리지 Auto Scaling으로 다운타임 없이 데이터베이스 확장. EC2 인스턴스 과부하는 평균 CPU를 조정 지표로 사용해서 처리한다. CloudWatch 지표는 기본으로 제공함. 메모리는 기본 CloudWatch 지표가 아니다. CPU 사용률은 가능함. 

 

DynamoDB는 고성능 NoSQL 이라 트래픽이 많은 쿼리에 대해 최소 대기시간 응답을 수행할 수 있음. Macie와 EventBridge와 SNS를 함께 사용하면 민감한 데이터를 보호하고 월별 이메일 알림을 받을 수 있음. Macie로 월별 재무정보 포함 여부를 감시함. 

 

DynamoDB 기본 백업은 콜드 스토리지 전환 기능이 없다. S3처럼 수명 주기로 넘기는건 불가능함. 그러니 AWS Backup 기능을 사용해야 함. 그리고 애초에 기본 백업은 S3에 저장되는게 아님. 

 

청구서 메뉴에서 볼 수 있는건 서비스별이나 리전별 총액 합계임. 누가 얼마나 썼는지는 확인할 수 없다. 사용자별로 나열된 보고서를 보려면 Cost Explorer를 사용해야 함. 여러 필터링 옵션을 적용해서 보고서를 생성할 수 있다. 

 

S3에 동적 처리를 추가하려면 서버리스를 사용한다. 정적 호스팅과 서버리스 백엔드가 정답임. Lambda는 사용한 만큼만 과금되니까 이 경우에 최적임. Lightsail도 가상 사설 서버를 월정액으로 24시간 켜두는거라 낭비가 심함. 

 

온프레미스 스토리지 백업과 모든 데이터 로컬 액세스 유지는 Storage Gateway를 사용한다. Stored Volume은 딱 이 목적을 위해 만들어짐. 모든 데이터는 온프레미스에 저장한다. Storage Gateway는 온프레미스에 저장되는 데이터들을 스냅샷으로 저장함. Cached Volume은 일부 데이터만 캐싱하는거고 Stored Volume은 모든 데이터를 저장하는 것. Snowball은 대용량 환경에서 주고받는 것. 

 

트래픽은 인터넷을 통과하면 안됨. S3와 DynamDB는 게이트웨이 엔드포인트를 지원하니 AWS 백본 네트워크만으로 안전하게 S3에 접근하도록 설정할 수 있음. NAT 게이트웨이를 두면 퍼블릭 인터넷을 통과하게 된다. 

 

VPC 피어링 규칙은 IP 대역이 겹치면 안됨. 두 VPC 간의 CIDR 블록이 서로 겹치거나 동일하면 안된다. 똑같은 대역은 절대 안됨. 가장 작은 CIDR은 /28이다. /32는 VPC CIDR로 절대 생성할 수 없음. 문법적으로 불가능함. 

 

SSD는 물리적인 보터 없이 반도체 메모리로 동작하니 초저지연을 보장하지만 HDD는 플래터가 회전하면서 데이터를 읽으니 데이터 지연이 좀 있다. FSx for Lustre는 HPC 머신러닝에서 대용량 데이터를 빠르게 처리한다. FSx for NetApp ONTAP은 Lustre 보다는 성능이 떨어짐.

 

예약 인스턴스는 CPU와 메모리만 예약하는거임. 컴퓨팅 엔진을 예약해서 할인받는 것. 어차피 스토리지는 쓴 만큼 따로 과금된다. 계속 늘어나는 데이터는 Aurora가 알아서 늘려주면서 용량비만 따로 받는것. 예약 인스턴스는 1년 3년 내내 켜두는 경우 온디맨드보다 저렴하다.