AWS 구조 파악, VPC, EC2

용어 정리

DataCenter → 컴퓨팅 시스템 및 관련 하드웨어 장비를 저장하는 물리적 위치

Account → AWS서비스를 사용하기 위한 기본 단위

Region → 지리적 영역, 리전마다 독립적이다 (서울은 ap-northeast-2)

Availablity Zone (AZ) → 리전 안의 개별 데이터 센터, 여러개가 존재

• 왜 여러개?

  • 가용성을 높히기 위해 (하나가 멈추면? 다른 AZ가 가용되면 됨)

보안과 책임

클라우드 자체의 인프라 보안은 AWS 가 담당

클라우드 안의 프로덕트 보안은 사용자가 담당

• 데이터의 암호화

• IAM 관리 (인증/인가, 비밀번호 등)운영체제 패치

• 어플리케이션 보안

IAM

AWS 에서 누가 어떤 AWS 리소스에
무엇을 할 수 있는지를 정하고 통제하는 제어 시스템

• Who → 요청이 인증 되었는지?

• What → 어떤 작업을 하는지?

• Can → 작업의 권한이 있는지?

• 서버에 필요한 권한만 부여해야함

• 서버에도 역할을 붙여 다른 서비스 호출에도 권한 제어가 가능함

핵심 요소

User

• 사람이 AWS에 접근시 사용하는 계정

  • 영구적인 Credential 을 가짐

    • Credential → 본인임을 증명하는 정보

      • 비밀번호 → 콘솔 접근용

      • Access Key → CLI, API 접근용 (관리가 어려워 Role 이 권장)

Role

• 서버, 서비스에 권한을 부여시 사용

  • 임시적인 권한을 받아 이용

  • 만료가 되고, Credential 이 없음, 직접 로그인도 불가

Policy

• 어떤 작업의 허용, 거부를 정의

  • 단독의 사용이 아니라 User나 Role에 더하여 사용됨

  • 구조 → Json의 형태 처럼 생김

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",              ← 허용? 거부?
          "Action": "s3:GetObject",       ← 어떤 동작을?
          "Resource": "arn:aws:s3:::my-bucket/*"  ← 어떤 대상에?
        }
      ]
    }

    • Effect → 허용, 거부 설정

    • Action → 동작

    • Resource → 어떤 대상에 (ARN 형태)

      • ARN (Amazon Resouce Name)

        • 리소스의 고유 주소
          아래와 같은 형태를 지님

          arn:aws:{서비스}:… 

    • 보통 AWS 가 미리 만든 Policy 들이 많지만
      커스텀으로 지정할 때는 직접 작성해서 사용
      

      AdministratorAccess	모든 권한
      AmazonS3FullAccess	S3 전체 권한
      AmazonS3ReadOnlyAccess	S3 읽기만
      AmazonEC2FullAccess	EC2 전체 권한

Security Group

• AWS 리소스에 대한 네트워크 트래픽을 제어하는 가상 방화벽

• Whitelist 방식이라 허용 규칙만 존재, 규칙에 적히지 않은 것들은 전부 차단

• Stateful 함

  • InBound 허용시 OutBound 시엔 검사하지 않음

  • 물론 OutBound 규칙을 지정할 수는 있음

네트워크 구조

VPC

Virtual Private Cloud

AWS 클라우드 내 사설 네트워크

타 AWS 계정의 네트워크와 논리적으로 격리 되어있음

• 주소 범위

  • VPC 를 만들 때는 IP 주소 범위 (대역대)를 지정해야함

  • 외부 인터넷과 연결되지 않는 IP를 사용 (보통 10.x.x.x)

  • 표준 크기는 10.0.0.0/16 → 약 65000개

• VPC의 Region NAT Gateway
  (NAT Instance는 직접 EC2로 구성한 경우를 말함)

  • VPC 내부 Private Subent 이 외부 인터넷에

    접근해야 할 일이 분명 있음 (DB 업데이트, 리소스 업데이트 등)

  • 이럴 경우에 NAT Gateway 를 통해 접근해야함
    원래는 AZ 마다 Zonal NAT Gateway 를 지정해야줘야 하지만
    현재 Region NAT Gateway 가 개발되어 별도 지정이 필요 없음

    Private Subnet 내 EC2

    → Public Subnet 내의 NAT Gateway를 통해 IGW에 접근

    → 외부 인터넷 접근
    → 데이터 패킷이 IGW 접근
    → Public Subnet 내 NAT Gateway
    → Private Subnet 내 EC2 데이터 도달

    • NAT → Network Address Translation
      NAT Gateway는 IP 주소 변환을 통해 Private IP와 Public IP로
      서로 변환해주는 역할을 함

• VPC의 Endpoint

  • VPC의 내부 Subnet이 S3에 접근시, 엔드포인트가 없다면
    NAT Gateway 를 나갔다가 S3에 접근해야함

  • VPC의 내부 Subnet이 S3 접근시, 엔드포인트가 있다면
    엔드포인트를 통하여 S3에 접근함
    (인터넷을 타지 않음, 속도가 빠르고, 비용이 없음)

Subnet

VPC 네트워크를 관리하기 쉽게 작게 쪼갠 구역

하나의 VPC 안에는 여러개의 Subnet 이 존재할 수 있음

Route Table

네트워크 트래픽이 어디로 가는지 알려주는 규칙

모든 서브넷은 반드시 1개의 라우팅 테이블과 연결되어야함

• 트래픽을 처리하는 2가지 방식 (Subnet 의 Private / Public 의 설정)

  • Local

    • 도착지의 IP가 VPC 내부 대역대? → VPC 안에서 찾음

    • 규칙 삭제 불가, VPC 내 모든 서버는 별도 설정을 하지 않아도 통신이 됨

  • External

    • 도착지의 IP가 VPC 외부 대역대? → IGW로 보냄

    • 이 규칙의 존재 여부가 Public 과 Private 여부를 정함

  • 예시

    • 172.x.x.x/16 → local (VPC 내부) (자동 생성)
      이외에 0.0.0.0/0 → igw-xxxxx (인터넷 연결용)

      → Public (연결된 라우팅 테이블에 IGW 경로가 있다)

    • 172.x.x.x/16 → local (VPC 내부) (자동 생성)
      이외에 인터넷 연결용 라우팅 테이블 없음

      → Private (연결된 라우팅 테이블에 IGW 경로가 없다)

IGW (Internet GateWay)

VPC와 외부 인터넷을 연결하는 유일의 관문 (1개의 VPC는 1개의 IGW만 지님)

VPC 는 고립 환경, IGW 가 없으면 인터넷 접속이 불가

💡

1개의 Region
→ 여러개의 가용 영역을 지님(AZ)
 → 1개의 AZ는 여러개의 Subnet 을 지닐 수 있음

→ 여러개의 VPC 생성 가능
 → 1개의 VPC는 여러개의 Subnet이 존재 가능
  → 1개의 VPC는 1개의 IGW 를 지닐 수 있음 (연결 여부는 선택)
  → 1개의 Subnet은 1개의 AZ에 위치해야함
   → 1개의 Subnet 은 1개의 Route Table 을 지님

AWS 서비스들

EC2

서버가 필요한 경우에 이용할 서비스

• AMI (Amazon Machine Image)

  • EC2를 시작시 사용하는 설치 이미지

    • 운영체제, 패키지 도구, 보안설정 등이 담김

    • 커스텀 가능

  • EC2의 인스턴스 → 가상 서버 1대 (물리적 서버 내에 논리적으로 쪼갠 구조)

    • 유형

      R5d.xLarge
      
      R -> instance의 familiy
      5 -> instance의 Generation
      d -> instance의 additional Capability
      xLarge -> instance의 size

    • family → 용도

    • generation → 세대

    • additional Capability → g (Gravition 프로세서) (arm64)
      → g가 없음 (보통의 x86_64 프로세서)

    • size → 사양 (nano < micro < small < medium < large < …)
      보통의 스프링 은 small 이상으로 사용

    • 비용, 성능은 arm64 가 더 좋음, 범용성은 x86_64

  • EC2 인스턴스의 상태

    상태	설명	EC2 비용	퍼블릭 IP	데이터
    Pending	시작 중	-	-	유지
    Running	실행 중	유료	유료	유지
    Stopped	중지됨 (재시작 가능)	무료	해제 (재시작 시 새 IP 할당)	유지
    Terminated	삭제됨 (복구 불가)	무료	해제	삭제

    • 중지 → 재시작 (Public IP가 바뀜)

    • 종료를 안하면 계속 과금되므로 필요 없을시 종료 나 삭제가 필수

      • 종료와 중지의 차이

        • 종료 → 데이터 삭제됨, 복구 불가, Public IP 해제
          = 서버 반납

        • 중지 → 데이터 유지됨, 다시 시작 가능, Public IP 해제됨

          = 서버 전원 끄기

  • EC2 인스턴스의 IP 구조

    • Private IP
      → VPC 내부 통신용, 인스턴스 생성시 자동 할당
      → 중지/시작 모두 유지
      → 외부에서 접근 불가

    • Public IP

      → 인터넷 통신용, 인스턴시 시작시 할당되지 않게 할 수 있음
      → 중지 - 시작시 변경됨
      → Public Subnet 에서만 의미가 있음

    • Elastic IP (EIP)

      • 고정된 Public IP (재시작 시에도 고정됨)

      💡

      EIP 는 점점 사용되지 않는 추세

      → 왜냐면 한 IP당 트래픽의 처리는 한정되어 있는데
      EIP는 트래픽의 분산 처리가 안됨 (주소가 고정되어 있으므로)
      로드밸런싱이 불가능 하므로 사용하지 않는 추세

RDS

데이터베이스가 필요한 경우에 이용할 서비스

S3

스토리지가 필요한 경우에 이용할 서비스

…. 그외

사용해보기

• region 설정

  • 아시아 태평양 - 서울 (ap-northeast-2)

    

• budget 설정

  

• VPC 설정

  

• EC2 생성

  

  

  • 키 페어 생성시에 다운 받은 pem 파일은 유실되면 안된다

• SSH 접속 (키 페어 파일을 통해)

  • pem 키에 권한은 읽기만 설정되어 있어야한다
    그러므로 chmod 400 으로 읽기 권한만 주어야 한다

  • ssh -i [pem 경로] 지정한 EC2 사용자 이름@퍼블릭 IP

  • SSH 접속 완료

• 인바운드 규칙 설정

  • EC2 탭 - 보안 그룹에서 인바운드 규칙을 지정해야 브라우저에서 접근 가능

  • HTTP 80 포트를 열어주어야 한다

• SSH 접근시 모니터링 명령어들

  • free -h → 메모리 사용량

  • df -h → 디스크 사용량

  • top → CPU/메모리 사용량 실시간 모니터링

    • q 입력시 종료