[AWS] AWS TGC 내용 정리

2주차 세션: AWS 네트워크의 이해

• S3 는 VPC에 종속적이지 않는다.

• RFC1918 (private IP 표준)에 따르면 사설망 내부 IP대역을 할당시 특정 대역 IP를 미리 사용하기로 약속한다. IP의 앞 구역을 몇자리를 고정할건지에 따라 사용할 IP대역이 결정되며 크게 3가지로 나뉘어진다.

• 서브넷마다 라우팅 테이블이 붙는다.
• 프라이빗, 퍼블릭 서브넷의 차이는 라우팅 테이블에 ‘인터넷 게이트 웨이(IGW)’를 통해 외부 통신 가능하도록 설정되어 있는지 여부이다.
• 인터넷 게이트웨이랑 NAT 게이트웨이 두 개를 한 번에 서브넷에 붙일수 없다.

NAT 게이트웨이

• 퍼블릭 서브넷에 NAT 게이트웨이를 붙인다 (프라이빗 서브넷 x)
• 인터넷 게이트웨이는 VPC에 위치한다(서브넷 단위가 아님)
• 퍼블릭 서브넷에 NAT 게이트웨이를 추가하나, “Public” 연결 유형으로 추가해줘야 인터넷 통신이 가능하게 된다. 그래서 “NAT 게이트웨이 퍼블릭 <-> 인터넷 게이트웨이” 구조로 외부 인터넷과 통신하는 방식이 된다.
• NAT 게이트웨이 private 연결 유형도 존재하나, 인터넷 게이트웨이와 연결이 불가하게 된다. 즉, 인터넷망을 사용하려는 목적이 아니면 VPC간 연결을 위해 사용하게 된다.
• 고정 IP를 통해 외부 인터넷 통신이 가능하게 된다. (참고)
  • Outbound만! 만약 고객사에서 서버 요청에 대한 방화벽 해제를 해줘야한다면 NAT 게이트웨이 IP주소를 알려주면 된다.
• DNS와 DHCP
• public IP 는 AWS에서 랜덤하게 할당되며 EC2 생성시 public IP를 할당해줘야 한다.
• 퍼블릭 서브넷만 외부에 나가기 위해선 public IP 가 필요하다.

NACL

• 서브넷 단위 방화벽 => 큰 단위
• Inbound / Outbound 별도 설정
• Allow/Deny 둘 다 바꿀 수 있음
• 특정 IP 만 막아줄 수 있다.
• 기본적으로 ALL-DENY 로 세팅하고 필요한것만 열어주는 정책으로 보통 Rull을 가져간다.

보안 그룹

• 인스턴스 단위 방화벽
• 디폴트는 DENY고 필요한 IP만 열어주는 방식

VPC

• 디폴트 VPC(모든 리젼 동일 대역 사용) 보단 커스텀 VPC를 활용해야 한다.

VPC간 연결

• private 연결 유형의 NAT 게이트웨이는 다른 VPC의 프라이빗 서브넷에 잇는 인스턴스와 통신할 수 있도록 한다.
• VPN 또는 AWS Direct Connect를 통해 연결된 VPC에서만 접근 가능하다.
• 인터넷 게이트웨이와 직접 연결할 수 없다.
• NAT GW를 사용하면 프라이빗망에 있는 인스턴스에서 외부 인터넷 통신이 가능하다.
• 다만 내부 인스턴스에서 외부로 나가는것만 가능하고, 외부에서 내부로 들어오는 인터넷 통신은 불가능하다.

VPC Perring(VPC 연결)

• VPC 간의 통신을 내부 통신 할 수 있도록한다. 인터넷 게이트 웨이를 통한 외부통신의 경우 보안에 취약하다.
• 1:1 로 VPC를 별도로 맺어줘야 한다.

AWS Transit Gateway (VPC 연결)

• VP와 같은 다양한 연결옵션

VPC Endpoint

• 게이트웨이 타입
  • VPC 외부에 있는 S3와 같은 서비스를 ‘인터넷 게이트웨이’를 통해 나가면 보안에 취약하고 비용이 발생하게 된다. 그래서 이러한 케이스를 내부 통신으로 바꿔준다.
• 인터페이스 타입
  • API GW 포함 VPC 에 종속적이지 않다.
  • 보안에 취약하다.
  • 프라이빗 서브넷에 외부 인터넷 통신 가능한 내부칩 같은걸 꽂게된다.
  • private Link는 내부가 블랙박스 영역이라 IP가 API-GW로 찍히게 된다.

VPC Direct Connect

• 전용선을 통해 통신

VPN

• 사설망 통신

ELB

• 오토 스케일링 그룹과 연동
• 디폴트는 라운드 로빈 방식
• 유형

Application LB

• 7계층에서 동작 (HTTP, HTTPS, WebSocket)
• Path & Host 기반 라우팅
• Microservice, Fargate 컨테이너 방식에 주로 사용

Network LB

• 4계층에서 동작
• ALB보다 고성능

네트워크 과제

시나리오

• OOO 은 AWS 를 접하고 AWS 를 활용하여 회사들에 “사내 네트워크 구성 및 가상 PC 자원을 제공”하는 사업을 구상했다.
• 해당 아이템을 가지고 회사 A 를 차린 OOO 은 다양한 요청을 가진 고객사의 네트워크 환경을 알맞게 구축하여 사업을 유지할 수 있을까..?
• 기본정보
  • 가상 PC 제공은 하나의 PC 당 EC2 한 대(private ip 할당)를 제공한다고 가정한다.
  • 네트워크 구성시 기본적으로 private subnet 과 public subnet 을 구분하여 구성한다.
  • Private Subnet 의 외부 통신은 NAT Gateway 를 활용한다.
  • 고객사 요청에 맞게 네트워크 (ex. CIDR / subnet / Connect / VPN) 를 구성한다.
    • 적절한 크기의 VPC 대역을 확보하여 네트워크를 구성한다.
    • 주소범위의 중복을 고려하여 네트워크를 구성한다.
    • 기본적으로 서비스의 가용성 달성을 위한 서브넷 환경을 구성하도록 한다. (최소 2+)
  • 회사 A (본사) 의 네트워크 구성도는 다음과 같다.

• 시나리오 1 - 회사 B
  • 회사 B 는 대기업으로 회사 구성원은 2000명 이다.
    • 사업 도메인 특성상 구성원은 최대 4000명으로 제한된다.
  • 회사 B 는 사업 특성상 2개의 지사를 가지고 있습니다. (총 3개 - 본사 / 지사 1 / 지사 2)
    • 각 본사 + 지사별로 다른 Subnet 으로 분리되기를 원합니다.
• 시나리오 2 - 회사 C
  • 회사 C 는 스타트업으로 회사 구성원은 10명이 되지 않는다. (IoT 제품)
    • 사업 도메인 특성상 구성원은 최대 200명으로 제한된다.
  • 기본적인 사내 구성원들의 가상 PC 제공 요청 외로 제품 홍보 홈페이지 제작을 위한 서비스도 VPC 에 올리고자 한다.
    • 기본적인 보안 구성을 맞춰 3-tier 로 subnet 을 분리하여 구성 한다.
      • 참고 : 사내 네트워크 구성도 (public - private - private)
    • 제품 홍보 홈페이지는 외부의 사용자들이 접근할 수 있어야 한다.
      • 해당 제품 홈페이지는 하루 50명 정도 접근하는 사이트이다. (많은 트래픽 X)
• 시나리오 3 - 통합 / 연결
  • 해당 사업을 운영하고 있는 회사 A 는 고객사 요청에 따라 각 회사별 PC 에 접근 하여 유지보수까지 지원하게 되었습니다.
  • 회사 A 의 AWS 네트워크 환경에서 B / C 회사에 접근하여 PC 를 점검할 수 있는 방안에 대해 모색하고 네트워크 구성도로 작성해주세요.
    • ex. VPC Peering / Transit Gateway

네트워크 과제 제출안

• [캡쳐1] 회사 B 의 네트워크 구성도

• [캡쳐2] 회사 C 의 네트워크 구성도

[캡쳐3] 회사 A/B/C 통합 네트워크 구성도

네트워크 과제 답안

• [캡쳐1] 회사 B 의 네트워크 구성도

• [캡쳐2] 회사 C 의 네트워크 구성도

• [캡쳐3] 회사 A/B/C 통합 네트워크 구성도

• 캡처1은 총 서브넷 12개 => 4096 x 12 = 49152개, VPC CIDR: 65000개
• CIDR은 16단위로 적으면 됨
  • 10.1.0.0 ~
  • 10.1.16.0 ~
  • 10.1.32.0 ~

• Transit Gateway 는 비용이 비싸다보니 VPC 피어링으로 구성해도 된다.
• VPC 별로 네트워크 대역을 나누는게 좋다. 나누지 않으면 Transit Gateway 적용이 불가능해진다.
• 퍼블릭 서브넷에 EC2 인스턴스를 두면 외부 사용자가 접근 가능하다. 프라이빗 서브넷에 두면 외부 사용자가 일반적으로 접근 불가하다.
• 라우팅 테이블과 ALB는 하나로 생성하여 각 서브넷 및 AZ에 연결시키는 방식이다.
  • LB: 외부 요청을 받는다면
  • NAT GW: 프라이빗 서브넷의 인스턴스가 외부로 요청을 보낸다면

Note: AWS 네트워크와 관련된 학습을 위해서 유튜브 영상을 추가적으로 참고하면 좋음

3주차 세션: AWS 기반 서비스의 이해 (EC2/RDS/S3)

컴퓨팅 서비스

• EC2
• ECS, EKS, Fargate
• Lambda

AMI (Amazon Machine Image)

• 인스턴스 시작에 필요한 정보 제공 역할
• 1)기본 AMI 로 인스턴스 띄우기
• 2)띄워진 AMI 커스텀하여(외장 톰캣 설치 등) 사용자 정의 AMI를 만든다.
• 3)사용자 정의 AMI로 여러 인스턴스 띄우기
• 아마존에서 제공하는 AMI 를 쓰면 aws-cli 등 기본적으로 많이 깔려 있기에 주로 많이 사용한다.

EC2 인스턴스 스토어

• 인스턴스 수명기간 동안만 지속
• 스냅샹 기능 미지원
• 잘 사용 안함

DBS

• 블록 스수준 영구 스토리지
• EC2를 내려도 영구적이다.
• 주로 거의 사용

팁

• 큰 인스턴스보단 작은 인스턴스 여러 개를 띄우는게 비용 측면에서 효율적이다.
• 스팟 인스턴스 => 경매 방식
  • 기본적으로 유지 => RI, 절감형 플랜, 급증하는 워크로드를 위해 온디맨드를 사용하여 확장

ELB

• 네트워크 트래픽 분산을 통한 애플리케이션 확장성 개선
• EC2, Container, 람다에 물릴수 있다.
• LB - Target - ASG(오토스케일링 그룹)

EC2 오토 스케일링

• 변화하는 수요에 동적으로 대응하고 비용 최적화
  • 1)비정상 인스턴스 교체
  • 2)수요에 맞게 확장
• 인스턴스 시작시 사용자 데이터 입력
• 시작 템플릿으로 인스턴스 시작 (대부분 이를 통해 관리하긴함)
• EC2 는 키페어가 필수다.

AWS 스토리지

• 블록 스토리지 - EBS
• 파일 스토리지 - EFS
  • 파게이트나 람다에도 붙을수 잇다.
  • 적용 범위가 더 넓고 비싸다.
  • 다양한 서비스별로 공유된 스토리지 환경을 공유할 수 있다.
• 오브젝트 스토리지 (IO상대적으로 느리고 재수정 불가) - S3
  • S3 “라이프 사이클” (룰셋)
  • 90일 동안 접근되지 않는것에 대해선 다음 단계 (Glacier 등)로 넘어가도록 룰셋 지정 가능
  • 2년 동안 접근되지 않는것은 삭제도 가능
  • 개발시 temp 성 데이터는 expired 만료시간을 지정해서 put 해두면 좋음

5주차 세션: AWS ECS 및 CI/CD 이해

ECS

• 구성요소
  • Task
  • ECS Service
  • ECS Cluseter
• Fargate 는 AWS 가 완전관리하는 영역이다. EC2 에 비해 비용은 좀 더 비쌈(약 1.25배)
• ECS Cluster

• 태스크 하나에 컨테이너 두 개를 띄울 수 있다. (예외적인 경우 하나로 FireLens)

CICD

1) 롤링 배포

• 단점: 롤백이 용이하지 않다, 호환 안되는 API의 경우 문제 발생

2) 블루그린 배포

• 단점: 자원을 두배 쓴다.

3) 카나리

• CodeDeploy 내에서도 카나리 배포 기능을 지원한다.

6주차 세션: 서버리스의 이해 (Lambda/API GW/SNS/SQS)

Lambda 람다

• 람다 비동기 처리시 실패한 경우 2번 retry 후 DLT(Dead Letter Queue)를 활용하도록 하는게 좋다.
• Amazon RDS Proxy를 RDS 앞단에 둠으로써 커넥션풀 고갈문제를 고민해볼수있다.

• alias, versioning 지정 가능하다.
• API-GW 캐슁 기능은 HTTP API는 지원 x(Rest API만 지원한다)

SNS

• 타입
  • standard => 구독자 여러개일때, 순서보장x
  • fifo => 순서보장

SQS

SAM (Serverless Application Model)

Reference

• https://www.notion.so/2024-2a0f933efaa74d0ba0cd16b2efe359f6