Posts [AWS] AWS TGC 내용 정리
Post
Cancel

[AWS] AWS TGC 내용 정리

jeonyoungho Oct 22 2024-10-22T00:00:00+09:00
Nov 20 2024-11-20T10:27:14+09:00 17 min

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

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

image

  • RFC1918 (private IP 표준)에 따르면 사설망 내부 IP대역을 할당시 특정 대역 IP를 미리 사용하기로 약속한다. IP의 앞 구역을 몇자리를 고정할건지에 따라 사용할 IP대역이 결정되며 크게 3가지로 나뉘어진다.
IP 대역CIDR
10.0.0.010.255.255.255(10/8 prfix)
172.16.0.0172.31.255.255(172.16/12 prefix)
192.168.0.01192.168.255.255(192.168/16 prefix)
  • 서브넷마다 라우팅 테이블이 붙는다.
  • 프라이빗, 퍼블릭 서브넷의 차이는 라우팅 테이블에 ‘인터넷 게이트 웨이(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 (본사) 의 네트워크 구성도는 다음과 같다.

image

  • 시나리오 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 의 네트워크 구성도 image

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

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

image

네트워크 과제 답안

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

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

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

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

image

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

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

image

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(오토스케일링 그룹)

image

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

image

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

image

image

CICD

1) 롤링 배포

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

2) 블루그린 배포

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

3) 카나리

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

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

Lambda 람다

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

image

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

SNS

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

SQS

SAM (Serverless Application Model)

Reference

AWS
aws network ecs serverless cicd
This post is licensed under CC BY 4.0 by the author.
Recent Update
Contents

[Database] MySQL VARCHAR vs TEXT

[디자인패턴] Visitor 패턴