소프트웨어 마에스트로에서 좋은 기회가 있어서 AWS 오피스 교육을 다녀왔다. AWS에 대해 맨땅에 헤딩을 하고 있었는데, 오피셜로 배울 수 있었던 부분이 아니였던 것이라 상당히 좋은 기회라 생각하고 교육에 참가했다. 해당 포스트는 본 교육에서 배웠던 내용을 작성하였고, 알고 있던 내용은 생략하였다.

모듈 1 : 아키텍팅 기본 사항

클라우드 사용 이유

• 출시 시간 단축
• 더욱 광범위한 혁신 추진
• 원활한 크기 조정
• 비용 최적화
• 보안 취약성 최소화
• 복잡한 관리 작업 감소

AWS 인프라

리전

• AWS가 서비스를 하는 지리적인 위치
• Region이 서울이라 해서 데이터센터가 서울에 있는 것은 아니다
• 하나의 Region은 최소 2개의 가용영역이 있어야 한다 (가용성 이중화)

AZ(가용영역)

• AWS 클라우드 영역을 쓸 수 있는 곳
• 여러개의 AZ가 합쳐서 Region이 만들어진다.

모듈 2 : 계정 보안(IAM)

루트 계정을 사용하는 것은 굉장히 위험해서 AWS에서 권장하지 않는다.

IAM 4가지 개념

1. USER
2. GROUP

• 공통 권한을 갖는 사용자의 모음
• 정책이 충돌할 때는 항상 거부를 따라간다 (명시적 거부)

3. POLICY

• 권한 부여하는 JSON 형식 문서
• Effect - 허용 or 거부
• Action - 작업 목록 (S3fullaccess)
• Best Practice : User가 아니라 GROUP에 권한을 부여해라

4. ROLE

• 임시로 권한을 부여하는 객체
• 임시이기 때문에 만료시간이 있다
• POLICY를 사용하면 만료가 되었을 때 권한 회수를 잘 하면 상관없지만, 그게 아니라면 보안 사고가 날 수도 있다.
• IAM USER에게도 권한을 줄 수 있지만, AWS 서비스에도 ROLE을 줄 수 있다.
• 원래 권한이 있었던 사람이 ROLE을 부여 받는 순간 원래 권한은 없어진다
• ROLE을 여러개 받을 수는 없다

다중 계정 관리(Organizations)

단일 계정에서는 IAM을 사용하지만, 통합 결제를 할 때에는 다중 계정을 사용한다.

모듈 3 : 네트워킹

VPC 트래픽 보안

NACL

• Subnet 수준에서 방화벽 설정
• 상태 비저장으로 패킷 저장(Stateless)
• 허용 / 거부 규칙 지정 가능
• default가 나가고 들어오는게 모두 허용

SG(Security Group)

• EC2 단에서 설정할 수 잇는 방화벽
• 상태 저장 방식(Statefull)
• 허용 규칙만 지정 가능
• 항상 보안 그룹 위주로 보안 세팅을 해야하기 때문에 SG가 우선이 되어서 보안 세팅이 되어야 한다

모듈 4 : EC2 인스턴스

EC2 Storage

EBS

• Ec2와 연결한 영구적인 블록 스토리지 (저장 장치)
• SSD OR HDD
• 인스턴스와 동일한 가용영역에 있다
• default값으로 EC2를 지우면 EBS는 삭제된다

Instance Store

• 휘발성 데이터
• 인스턴스 중지/종료하면 데이터가 날아간다
• 제공하는 유형이 따로 있다
• EBS보다 더 가까이 있어서 고성능으로 사용할 수 있다

요금옵션

On Demand

쓰는 만큼 돈을 지불하는 방식

R1 SAVINGS PLAN

예약 인스턴스로, 어느 정도 사용할지를 계산해서 해당 금액만큼의 EC2인스턴스 용량을 부여 받는 것

스팟 Instance

아무도 안 쓰는 미사용 인스턴스를 90%가격으로 할인받아서 사용할 수 있다. 하지만, 종료 2분전에 Notice가 오기 때문에(?) Notice가 왔을 때 어떻게 할지에 대한 자동화된 Script를 준비해놓는게 중요하다.

실습

시나리오

팀이 새로운 웹 기반 애플리케이션의 아키텍처 프로토타입 생성 업무를 맡았다. 아키텍처를 정의하려면 퍼블릭 및 프라이빗 서브넷, 라우팅, Amazon EC2 인스턴스 옵션에 대한 이해를 높여야 한다

VPC 생성

AWS 콘솔에서 VPC를 검색한 뒤 생성 버튼을 눌러 아래와 같이 세팅해주면 된다

CIDR은 위에서 언급했듯이 맨 뒤에 16을 넣으면 2^(32-16) 갯수 만큼의 IP 갯수를 사용할 수 있다.

DNS host 이름 활성화

위와 같이 VPC 편집 페이지에서 DNS 호스트 이름 활성화를 체크하면 EC2 인스턴스에 친숙한 도메인 이름(DNS)을 할당한다

퍼블릭 서브넷 생성

VPC 창의 왼쪽 탐색 창에서 서브넷을 누른 뒤 아래와 같이 세팅해주면 된다

서브넷에는 VPC보다 더 작은 10.0.0.0/24의 CIDR 범위를 설정해주며, 포함되게 만들어 놓았다.

자동 할당 IP 설정

이 설정까지 마무리하면 서브넷 안에서 시작되는 모든 인스턴스에서 퍼블리 IP 주소가 자동으로 할당되도록 서브넷을 구성할 수 있다.

이렇게 했다고 해서 Public Subnet이 되는 것은 아니다. Public Subnet에는 IGW(Internet GateWay)와 인터넷 게이트웨이까지의 경로가 있어야 한다.

프라이빗 서브넷 생성

인터넷과 격리된 상태를 유지해야 하는 리소스에 사용되는 프라이빗 서브넷을 생성해보자

CIDR 블록 10.0.2.0/23에는 10.0.2.x 및 10.0.3.x 로 시작하는 모든 IP 주소가 포함되어 있다. 인터넷에서 액세스할 수 있어야 하는 특별한 경우를 제외하고 프라이빗 서브넷은 대부분의 리소스를 프라이빗으로 유지해야 하기 때문에 크기가 퍼블릭 서브넷의 두 배 이다.

인터넷 게이트웨이 생성

이제 생성한 퍼블릭 서브넷이 인터넷 트래픽에 액세스할 수 있도록 인터넷 게이트웨이를 생성해야 한다. 그리고 VPC의 서브넷에 있는 인스턴스에서 인터넷에 액세스하는 권한이나 인터넷에서 해당 인스턴스에 액세스하는 권한을 부여하기 위해 인터넷 게이트웨이를 생성하여 VPC에 연결한다. 그런 다음 인터넷 바운드 트래픽을 인터넷 게이트웨이로 보내는 경로를 서브넷의 라우팅 테이블에 추가한다

따로 설정없이 생성해줄 수 있다.

그 다음에 만들어 주었던 VPC에 연결하면 Internet Gateway가 연결이 된다. 하지만 연결이 되었지 라우팅이 된것은 아니다. 이말인 즉슨 도로는 깔았지만, 방향 지시표가 없어 어디로 가야하는지 모른다는 말이다. 그렇기 때문에 라우팅 테이블을 생성해주어야 한다.

퍼블릭 서브넷의 인터넷 트래픽을 인터넷 게이트웨이로 라우팅

라우팅 테이블을 생성하고 인터넷 바운드 트래픽을 인터넷 게이트웨이로 보내는 경로를 라우팅 테이블에 추가한 다음 퍼블릭 서브넷을 라우팅 테이블과 연결한다. VPC에 있는 각 서브넷은 라우팅 테이블에 연결되어 있어야 한다. 이 테이블이 서브넷에 대한 라우팅을 제안한다.(방향 지시표) 서브넷은 한 번에 하나의 라우팅 테이블에만 연결할 수 있지만, 여러 서브넷을 같은 라우팅 테이블에 연결할 수 있다.

인터넷 게이트웨이를 사용하려면 Internet Bound Traffic을 인터넷 게이트웨이로 보내는 경로가 서브넷의 라우팅 테이블에 포함되어야 한다. 라우팅 테이블에 명시적으로 알려지지 않은 모든 대상으로 경로의 범위를 지정하거나 이보다 좁은 범위의 IP 주소로 경로의 범위를 지정할 수 있다.

위 세팅처럼 라우팅 테이블을 생성해주면 된다

그 후 Edit routes를 통해 위 사진과 같이 세팅을 하면 인터넷 게이트웨이를 통과하여 인터넷과 통신할 수 있게 된다.

퍼블릭 보안 그룹 생성

이제 EC2인스턴스에서 액세스할 수 있도록 보안 그룹을 생성해주어야 한다. VPC의 보안 그룹은 EC2 인스턴스에 허용되는 트래픽을 지정한다. VPC의 보안 그룹을 통해 각 EC2 인스턴스에 허용되는 인바운드 및 아웃바운드 네트워크 트래픽을 지정할 수 있다. 인스턴스에 명시적으로 허용되지 않은 트래픽은 자동으로 거부된다.

위 세팅처럼 VPC를 세팅해주고 보안 그룹을 생성해주면 된다.