[AWS] AWS 공부 정리
AWS 발표를 위해 약 2주간 공부했던 내용과 정보를 정리한 내용이다. (AWS 도큐먼트, 티스토리, 구글링 활용)
아직 실무에 적용은 못해봤지만 클라우드에 대한 중요성이 커지고 있는 요즘, 공부했던 내용을 까먹지 않고 한 번 더 복기 하기 위해 공부했던 내용을 업로드 해두려고 한다.
실제로는 AWS 계정을 이용해 개인 EC2 인스턴스를 제작하고 우분투 서버에 WAS 배포 직전까지 갔지만..!
세팅의 오류인지 우분투에 MySQL이 설치되지 않고 Socket 에러가 반복되어 현재 인스턴스를 중단시켜 놓았다.
내가 마주쳤던 Socket 오류에 대해서는 추후 정리 예정이고 아직 MySQL 설치를 성공하지 못했다 ㅜㅜ
* AWS란?
- AWS : (Amazon Web Services(AWS))의 약자
- 아마존닷컴에서 개발한 클라우드 컴퓨팅 플랫폼
* Amazon EC2란?
- Amazon Elastic Compute Cloud 의 약자로 AWS에서 제공하는 '클라우드 컴퓨팅 서비스'다.
- AWS의 가장 핵심 서비스!
- 이 서비스를 통해서 아마존이 각 세계에 구축한 데이터 센터의 서버용 컴퓨터들의 자원을 원격으로 사용할 수 있다.
쉽게 말해, 아마존으로 부터 (가상의) 컴퓨터 한 대를 임대하는 것이다.
AWS가 제공하는 URL(Public DNS(도메인 네임 서비스))를 통해 이 컴퓨터에 접근할 수 있다.
* EC2의 장점
1. 용량을 늘리거나 줄일 수 있다. (탄력성, 확장성) - Amazon auto scaling 이용
2. 사용자가 인스턴스를 완전히 제어할 수 있다. (완전 제어)
3. 보안 및 네트워크 구성, 스토리지 관리 효과적이다. (보안, 통합성)
4. 빠르게 애플리케이션을 개발, 배포가 가능하고 교체 인스턴스를 빠르고 예측 가능하게 실행할 수 있는 환경을 제공한다. (안정성)
5. 사용한만큼 지불하므로 저렴하다.
* AWS 의 용어
-클라우드 : 물리적인 서버가 없이도 인터넷에 접속하여 다양한 자원을 사용할 수 있게 하는 컴퓨터 리소스 이용형태
'사용자 입장'에서 시간과 장소 제약 없이 어디서든 접근할 수 있는 서비스
- IDC(인터넷 데이터 센터)
데이터센터는 네트워크와 하드웨어 자원을 공유하도록 도와주는 서버 장치, 데이터 패킷의 저장공간인 스토리지, 통신망 연결을 위한 네트워크, 전력 분배장치, 데이터센터의 온도 및 습도를 유지하는 장치, 온도 조절을 위한 냉수 공급 장치 등 IT 장비와 안정적인 환경을 유지하기 위한 인프라로 구성되어 있다.
데이터 저장 및 처리, 공유를 위한 통합관리 시설이다.
- EC2 : AWS 클라우드 컴퓨팅 서비스, 기본적으로 동적 IP 제공(인스턴스 재실행시 IP 변경) -> 탄력적 IP를 할당받아서 사용
- 인스턴스 : 클라우드의 가상 서버
- 스토리지 : 데이터를 저장하는 저장 장소
- Amazon EBS 볼륨 : 내구성이 있는 블록 수준 스토리지 디바이스
- AMI : 아마존 머신 이미지 (서버에 필요한 운영체제와 여러 소프트웨어들로 구성된 템플릿 형태로 이를 이용해 인스턴스를 쉽게 생성 가능, 인스턴스 복사 가능)
- 키 페어 : 퍼블릭 키 + 프라이빗 키(.pem), 인스턴스에 연결할 때 자격 증명 입증에 사용하는 보안 자격 증명 집합이다.
키 페어를 분실하면 인스턴스 접근이 불가능하기 때문에 잘 보관해야 한다!(반대로 프라이빗 키를 갖고 있는 사람은 누구나 인스턴스에 접근 가능)
퍼블릭 키는 AWS에서 제공해준다.
- 탄력적 IP 주소(EIP) : 동적 클라우드 컴퓨팅을 위한 고정 IPv4 주소
- 리전(지역) : 가용 영역을 그룹화 한 것, 개별 지리 영역으로 다른 리전들과 완전히 격리되어 있다. (강력한 내결함성 및 안전성을 가짐)
- 엣지(Edge Location) : 콘텐츠 혹은 정적 파일을 빠르게 전달하기 위한 배포 서비스 인프라(개별 지역에서 사용자에게 더 빠르게 파일을 배포 할 수 있어서 서비스 속도를 높임)
# 리전이란?
1. 말 그대로 지리적 위치를 말한다. -> 아마존 웹 서비스들의 서버가 어디에 위치 하는가?
2. 내가 서비스 하려는 지역의 주 고객들이 거주하는 지역과 서버의 거리가 멀면 멀수록 느려진다.
-> 웹 사이트를 운영한다고 하면 내 싸이트를 이용하는 고객이 어디에 위치하는지에 따라 중요
(ex) 서울 고객인데 미국 리전으로 서버를 구축하면 안된다.)
3. 즉 주 고객들이 거주하고 있는 곳과 가까운 리전을 사용하는 것이 당연히 좋다.
4. 최소한 2개이상의 가용 영역(AZ)로 구성된다.
5. 2019년 2월 기준 20개의 리전
- VPC (Virtual Private Clouds) : 사용자의 AWS 계정 전용 가상 네트워크, Amazon EC2 인스턴스와 같은 AWS 리소스를 VPC에서 실행할 수 있는 클라우드의 격리된 네트워크 환경이다.
VPC는 다양한 리소스를 시작하는 장소이고, 사용자 환경 및 환경의 리소스 상호 격리에 대한 탁월한 제어 기능을 제공하도록 설계되어있다.
VPC는 리전 안에 존재한다.(해당 리전에 종속) 따라서 하나의 VPC는 하나의 리전 내에서만 생성 가능, 하나의 VPC가 여러개의 AZ를 가질 수 있음
VPC는 아마존 콘솔에서 생성된다.
VPC는 AWS 내의 논리적 데이터센터라 생각하면 된다.
1 Subnet = 1 Availability Zone
# 기본적으로 AWS는 여러 사용자가 함께 쓰는 공용 환경이다.
여기서 다양한 리소스(인스턴스, RDS)를 생성해서 사용한다.
이 리소스는 네트워크를 통해 접근이 가능하다.
특정 사용자가 만든 리소스를 격리하여 다른 사람이 접근하지 못하고 공유하지 못하게 해주는 것이 VPC의 역할!
# AWS에서 기본으로 제공하는 Amazon-EC2-VPC 와 Amazon VPC 두 종류가 있다.
Amazon VPC는 확장 가능한 인프라(시스템 구조 및 체계)를 사용한다는 이점이 있다.
AWS VPC는 AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리되어 있다.
- VPN(Virtual Private Network) : 가상사설망
네트워크A와 네트워크B가 실제로 같은 네트워크상에 있지만 논리적으로 다른네트워크인것처럼 동작한다.
따라서 VPC라는 가상 네트워크 클라우드를 만들어 독립적으로 작동하게 한다.
(완전히 독립적이기 때문에 서로 다른 ip를 사용, 한번 설정된 아이피대역은 수정 불가)
# VPC를 쓰는 이유
VPC가 없다면 EC2 인스턴스들이 서로 거미줄처럼 연결되고 인터넷과 연결됩니다.
이런 구조는 시스템의 복잡도를 엄청나게 끌어올릴뿐만 아니라 하나의 인스턴스만 추가되도 모든 인스턴스를 수정해야하는 불편함이 생깁니다.
VPC를 적용하면 위 그림과 같이 VPC별로 네트워크를 구성할 수 있고 각각의 VPC에따라 다르게 네트워크 설정을 줄 수 있습니다.
또한 각각의 VPC는 완전히 독립된 네트워크처럼 작동하게 됩니다.
# VPC에서 사용하는 사설 아이피(Private IP) 대역은 아래와 같다. - 하나의 VPC에서 최대 65536개의 IP만 할당 가능
- 10.0.0.0 ~ 10.255.255.255(10/8 prefix)
- 172.16.0.0 ~ 172.31.255.255(182.16/12 prefix)
- 192.168.0.0 ~ 192.168.255.255(192.168/16 prefix)
@이 외의 IP는 모두 인터넷에서 사용할 수 있는 IP이다! 그래서 AWS는 사설망 대역을 사용하는 것을 권장한다.@
# VPC Peering : 프라이빗 IP주소들을 이용해서 VPC 끼리 다이렉트 네트워크 루트로 연결
다른 AWS 계정의 VPC와도 연결할 수 있고, 같은 계정의 VPC와도 연결할 수 있다.
- Availability Zone (AZ) = 가용 영역 : 리전이 갖고 있는 여러개의 격리된 위치 - 가용영역을 여러개 모아놓은 것이 리전!
# 가용 영역(AZ) 이란?
1. 데이터센터의 클러스터(집합체) - 전용선으로 연결 되어 있기 때문에 마치 한 건물인 것과 같이 빠르게 데이터를 주고 받을 수 있다.
2. 한 리전에는 여러 가용성 영역이 있다 (한 리전당 최소 2AZ) -> 그렇기 때문에 빠르게 데이터를 백업하고 데이터를 이전할 수 있는 구조
3. 다른 가용영역(AZ)의 장애로부터 격리됨 - 중요!!*
4. 즉, 현재 서울의 AZ는 2개이고 한개의 AZ가 장애가 나더라도 다른 AZ를 통해 서비스가 가능한 구조이다.
- subnet(서브넷) : VPC의 IP 주소 범위, 인터넷에 연결되어야 하는 리소스 - 퍼블릭 서브넷, 인터넷에 연결되지 않는 리소스 - 프라이빗 서브넷(기본적으로 외부와 차단되어 있다.)을 사용
하나의 VPC안에 여러개의 서브넷 생성 가능(서브넷 생성 시 가용영역 지정)
서브넷은 VPC를 쪼개는 과정
서브넷 (서브)넷마스크 범위는 16(65535개)에서 28(16개)를 사용할 수 있다.
하나의 서브넷은 하나의 가용 영역과 연결된다.
기본적으로 하나의 리전에서 2개 이상의 가용 영역을 사용하기 때문에 서브넷도 기본 2개가 생성된다. (더 많은 서브넷도 생성 가능, 하나의 가용영역에 최소 1개의 서브넷 존재해야 함!, 하나의 가용영역이 여러개의 서브넷 가질 수 있음)
(이때, 넷마스크 20의 서브넷들이 자동적으로 생성된다. -> 그림 - VPC 모식도를 보면 서브넷마스크가 20인 것 확인 가능)
이 역시 장애 대응을 위한 측면 중 하나이다.
# 서브넷 CIDR 블록 첫 4개, 마지막 1개 -> 총 5개 IP 주소는 사용 불가능
각 서브넷 CIDR 블록에서 첫 4개의 IP 주소와 마지막 IP 주소는 사용자가 사용할 수 없으므로 인스턴스에 할당할 수 없습니다.
예를 들어 10.0.0.0/24 CIDR 블록의 서브넷에서는 다음 5개 IP 주소가 예약되어 있습니다.
10.0.0.0: 네트워크 주소.
10.0.0.1: AWS에서 VPC 라우터용으로 예약한 주소.
10.0.0.2: AWS에서 예약한 주소. DNS 서버의 IP 주소는 항상 VPC 네트워크 범위를 기초로 2를 더한 것입니다. 그러나 에서는 각 서브넷 범위를 기초로 2를 더한 것도 예약합니다. CIDR 블록이 여러 개인 VPC의 경우, DNS 서버의 IP 주소가 기본 CIDR에 위치합니다. 자세한 내용은 Amazon DNS 서버 단원을 참조하십시오.
10.0.0.3: AWS에서 앞으로 사용하려고 예약한 주소.
10.0.0.255: 네트워크 브로드캐스트 주소. VPC에서는 브로드캐스트를 지원하지 않으므로, 이 주소를 예약합니다.
# 서브넷을 나누는 이유(퍼블릭과 프라이빗 두 종류)
더 많은 네트워크망을 만들기 위해서이다.
각각의 서브넷은 가용 영역안에 존재하며 서브넷 안에 RDS, EC2와같은 리소스들을 위치시킬 수 있습니다.
*** @최종@ ***
AWS > 리전 > VPC > AZ(여러개) - 최소 2개 > 서브넷(여러개) > EC2, RDS(여러개)
# 서브넷을 만들면 라우터에 연결되며, VPC 내에 있는 서브넷들은 라우터를 통해 연결되고, 라우터를 통해서만 인터넷 게이트웨이로 갈 수 있다.
- 라우터 or 라우팅 테이블 : 라우팅 테이블에는 서브넷 또는 게이트웨이의 네트워크 트래픽이 전송되는 위치를 결정하는 데 사용되는 라우팅이라는 규칙 집합이 포함되어 있다.
서브넷에서 네트워크 요청이 발생하면 데이터는 우선 라우터로 향하게 된다. 라우터란 목적지이고, 라우팅 테이블은 각 목적지에 대한 이정표이다.
라우트 테이블은 VPC와 서브넷과 연결되어 있는 리소스이다.
# 라우터 : 라우터는 직접 설정하거나 볼 수 없고 VPC 생성시 같이 생성된다.
# 라우팅 테이블 : VPC 생성시 같이 생성되고 변경 가능
라우팅 테이블도 자원으로 관리되어 하나의 라우팅 테이블을 다수의 서브넷에 붙일 수도 있다.
자동 생성되는 기본 라우트 테이블의 경우 타켓이 local인 규칙 하나만 정의되어 있다. (VPC 내부에서만 리소스를 찾는다.)
-> 인터넷을 연결하거나 다른 VPC와 통신하기 위해서는 다른 규칙을 추가적으로 정의해야 한다. (private ip를 이용하는 게 좋다.)
- 인터넷 게이트웨이(IGW) : 인터넷게이트웨이는 VPC(기본적으로 격리되어 있는 네트워크 환경)의 리소스와 인터넷을 연결해주는 하나의 관문
수평 확장되고 가용성이 높은 중복 VPC 구성 요소로, VPC의 인스턴스와 인터넷 간에 통신할 수 있게 해줍니다.
* 단, 단순 연결만으로는 인터넷을 사용할 수 없음 -> 인터넷을 사용하고자 하는 리소스는 퍼블릭 IP를 가지고 있어야 한다.
-> 인터넷 게이트웨이에는 인터넷 라우팅 가능 트래픽에 대한 VPC 라우팅 테이블에 대상을 제공하고, 퍼블릭 IPv4 주소가 할당된 인스턴스에 대해 NAT(네트워크 주소 변환)를 수행하는 두 가지 목적이 있다.
인터넷과 연결된 서브넷 - 퍼블릭 서브넷,
인터넷과 연결되지 않은 서브넷 - 프라이빗 서브넷
# 서브넷이 인터넷으로 나가는 방법
- 퍼블릭 서브넷 -> 라우터 -> IGW -> 인터넷
- 프라이빗 서브넷 -> 라우터 -> 퍼블릭 서브넷의 NAT Gateway -> 라우터 -> IGW -> 인터넷
(Private Subnet내의 웹서버들이 외부로 통신을 하기 위해서 보통 NAT서버를 Public Subnet안에 구축하여 NAT를 통해 외부로 통신을 한다.)
# 안전한 네트워크 환경 구축
- 네트워크 ACL(Access Control List) : VPC가 구성 되어야만 사용 가능, 외부간 통신을 담당하는 보안기능(트래픽 제어) - subnet 단위로 설정 가능
Stateless 필터링 방식(요청 정보를 따로 저장하지 않아서 응답하는 트래픽에 대한 필터링을 설정해야 함)
하나의 네트워크 ACL은 여러 서브넷에서 재사용 가능
- Security Group(보안그룹) : 내부간 통신을 담당(트래픽 제어) - 서버 단위로 정책 설정 (인스턴스 앞단에서 트래픽 제어)
Stateful 필터링 방식(요청 정보를 저장하여 응답하는 트래픽 제어를 하지 않음)
# 결론
1. subnet이 다를 경우
: Network ACL 정책이 적용 됨
2. subnet이 같을 경우
: Security Group 정책만 적용 됨
3. Network ACL
: Stateless 기반으로 인바운드(받는 것) / 아웃바운드(주는 것) 정책에 1024-65535(번호는 다를 수 있음) 포트에 대하여 허용하여야 통신이 가능하다.
4. Security Group
: (가상) 방화벽과 비슷한 개념
5. 두 개가 충돌할 경우 우선순위
: Security Group > Network ACL
# Stateless VS Stateful
- Stateless : 프로세스 또는 애플리케이션이 격리된 것으로 간주된다.
과거 트랜잭션에 대한 정보 또는 참조가 저장되지 않는다. -> 각 트랜잭션은 모두 처음부터 시작된다. (단기 요청처리)
ex) 검색창에 질문을 입력하고 엔터키를 누르는 형식으로 진행되는 온라인 검색, 자동 판매기와 비슷
- Stateful : 컨텍스트와 내역이 저장되므로 중단되어도 중단된 곳부터 다시 시작할 수 있다.
사용자에게 받은 요청을 처리할 때마다 같은 서버를 사용한다.
ex) 온라인 뱅킹, 이메일
# AWS에서 NAT를 구성하는 방법은 2가지
1. EC2 Instance를 NAT용도로 사용한다. -> EC2의 Instance를 Nat Instance로 이용해 프라이빗 서브넷 인터넷으로 보내기 그림 활용
NAT instance는 반드시 public subnet에 구성되어있어야 한다.
subnet이 public 인지, private 인지를 구분하는 것은 그림 오른쪽의 Route Table에 의해 결정되는데 public subnet의 Routing Table에는 반드시 0.0.0.0/0 이 igw-id(인터넷 게이트웨이)와 연결되어 있어야 한다.
(인터넷으로 통신을 하려면 igw 필수!)
반면에 private subnet 에는 igw가 없고 nat-instance-id 라는 것이 설정 되어있습니다. 이것은 public subnet에 있는 NAT instance를 뜻하는 것입니다.
Private subnet에서 Nat instance를 거쳐 외부 인터넷과 통신이 가능 한 것입니다. 따라서 외부에서 Private subnet에 있는 private ip를 알 수가 없다!(보안유지)
2. AWS의 완전관리형 서비스인 NAT Gateway를 사용한다. -> NATgateway를 이용해 프라이빗 서브넷 인터넷으로 보내기 그림 활용
별도의 EC2 instance를 사용하지 않으며 AWS에서 제공하는 NAT전용 서비스인 Natgateway를 사용
public subnet안에 NAT gateway 존재
Private subnet의 Route table에는 nat-gateway-id 설정
# 그렇다면 1번과 2번의 차이는?
가장큰 차이가 금액입니다. NAT gateway는 완전관리형 이므로 가격이 비쌉니다.
서비스 특성상 다량의 트래픽이 발생하거나 혹시 모를 EC2 instance의 장애를 생각해보면
안정성에 있어서 유리한 NAT gateway를 사용하는 것이 서비스 품질에 있어서 더 좋을 것이다. 비싼 이유가 다 있다.
- NAT Gateway : private subnet이 인터넷과 통신하기 위한 아웃바운드 인스턴스
- NAT Instance : 반드시 public subnet에 존재
# NAT 인스턴스의 한계
NAT 인스턴스로 구성하는것은 단일 인스턴스에 단일 AZ이기 때문에 병목현상에 취약하고, 문제발생시 Private Subnet 안의 모든 서비스가 인터넷 엑세스를 잃게 된다.
(multiple AZ 등을 이용할 수 있지만 복잡해져서 비추)
- Amazon RDS : 아마존에서 지원하는 관계형 데이터 베이스 웹 서비스, EC2에 직접 구축
- Elastic Load Balancing (ELB) : 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스, 컨테이너, IP 주소와 같은 여러 대상에 자동으로 분산시킨다. -> 내결함성, 가용성 향상
3종류의 로드 밸런서가 있다.
트래픽을 여러대의 EC2로 분산
Auto Scaling 제공 -> 트래픽이 급증할 때 EC2를 자동으로 생성한 후 트래픽이 감소하면 삭제
- IPv4 : IPv4 의 주소는 2진수 8자리를 10진수로 바꿔서 표현한 것, 각자리를 Octet이라고 부르며 "."으로 구별 하고, IP주소는 4개의 Octet으로 이루어져있다 ex) 172.16.0.0
- CIDR : 최신의 IP주소 할당 방법
(CIDR block 이란 IP address들의 그룹이며, CIDR이란 IP address들의 그룹을 관리 하면서 기존 IP Address Class보다 유연하게 동작하는 방식이다.)
* VPC와 인터넷 게이트 연결 과정
1. VPC 구축
2. 서브넷 생성(CIDR 이용, AZ(가용영역) 지정) AZ > 서브넷
3. 인터넷 게이트웨이 생성
4. 생성한 VPC와 인터넷 게이트웨이 연결
* 추가 사항
- AWS EC2 Container Service(ECS)
: Docker 컨테이너를 이용하여 인프라 환경을 좀 더 편리하게 운영하고 관리할 수 있도록 해주는 서비스
- Docker : 컨테이너 기술
- Amazon Aurora : Aamzon RDS의 일부
* bastion 조사
- Bastion host는 내부 네트워크와 외부 네트워크 사이의 게이트웨이라고 볼 수 있습니다. (그리고 인스턴스의 일종)
내부 네트워크에 직접 접속하는 것을 방지하기 위해 내부 네트워크의 앞단에 위치하여 보안을 조금 더 강화할 수 있는 역할을 해준다.
SSH 규칙의 소스에 아까 복사해둔 bastion의 보안그룹 ID를 입력합니다. (퍼블릭)
위와 같이 설정하면, bastion 보안그룹에 속해 있는 인스턴스만 web server쪽(프라이빗)으로 접근이 가능해집니다.
aws 상에서 보안을 위해 그림과 같이 실제 사용하는 인스턴스는 private subnet에 숨기고, public에 bastion host 라는 걸 둬서 접근하는 방식이 있다.
이렇게 하면 관리할 구멍을 하나만 만들고 그 외에는 접근이 원천적으로 불가능해지기 때문에 보안적으로는 좋아지긴 하는데… 그 내부로 접근하기가 매우 귀찮아지는 단점이 있다.
- Elastic Load Balancing (ELB) : 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스, 컨테이너, IP 주소와 같은 여러 대상에 자동으로 분산시킨다. -> 내결함성, 가용성 향상
3종류의 로드 밸런서가 있다.
트래픽을 여러대의 EC2로 분산
Auto Scaling 제공 -> 트래픽이 급증할 때 EC2를 자동으로 생성한 후 트래픽이 감소하면 삭제
* S3
- S3 ( Simple Storage Service ) : 높은 내구성과 높은 가용성을 저렴한 가격으로 제공하는 인터넷 스토리지 서비스
객체 스토리지 : 물리적 한계를 논리적인 방식으로 극복하고자 한 구성 (기본적으로 내부 복제를 전제로 한다.)
- S3의 경우 동일 region 내의 여러 AZ에 걸쳐 복제본을 생성