티스토리 뷰
AWS (Amazon Web Service)
AWS는 다양한 서비스와, 글로벌 인프라(리전)을 가지고 있다.
어디에서든 이 글로벌 인프라를 이용할 수 있는 방식을 취한다.
EC2 서비스
Amazon EC2 : 가상 서버 서비스
Virtual Machine
재구성이 가능한 컴퓨팅 리소스
쉽게 확장/축소되는 컴퓨팅 용량
'고객 업무' 영역에 따른 다양한 인스턴스 타입 제공
사용한 만큼만 과금 (pay-as-you-go) 제공
EC2 지원 OS
- Windows 2003R2/2008/2008R2/2012/2012R2/2016
- Amazon Linux
- Debian
- Suse
- CentOS
- Red Hat Enterprise Linux
- Ubuntu
- macOS
- iOS
- iPadOS
- Etc...
그 이외에 폭 넓은 컴퓨팅 인스턴스 타입을 제공한다.
범용 : T2,T3,M4,M5,A1
컴퓨팅 최적화 : C4,C5
스토리지 / IO 최적화 : I3, D2, D3
GPU 사용 : P2, P3,G3
메모리 최적화 : X1,R4,R5
인스턴스 읽는 법
알파벳은 인스턴스 종류,
숫자는 인스턴스 세대
.large는 인스턴스 사이즈
Xl, 2XL도 있다.
EC2 구매 옵션
On-Demand 인스턴스
컴퓨터를 사용한 만큼 비용 지불한다.
사전 계약금 지불은 하지 않는다.
단기간 사용할 어플리케이션 혹은 예상 밖의 갑작스런 워크로드, 어플리케이션 개발 및 테스팅
Reserved 인스턴스
1년 또는 3년 단위 계약금 지불 / 한번에 전체 구매(One Time Pay)
일정 계약금 사전 지불 후, 저렴한 사용 요금 부과
장점: 비용절감, 필요 인스턴스 예약 및 필요할 때 해당 인스턴스 타입의 가용성을 보장
꾸준한 사용량을 가지는 어플리케이션이나, 재해복구와 같은 예약된 용량을 확보해 두어야 하는경우 사용한다.
Spot 인스턴스
사용되지 않는 EC2 용량을 경매한다.
가격은 수요 공급 법칙에 따라 결정된다.
지금 종료되도 크게 문제가 없는 어플리케이션에 사용해야 한다.
장점 : 비용절감/대규모, 동적 워크로드
해당 인스턴스에 대해 더 높은 비용이 제시될 시 사용중인 인스턴스가 중단된다.
유연한 시작/종료 시간을 가진 어플리케이션이나, 저렴한 컴퓨팅을 사용해야만 하는 어플리이션에 사용한다.
급하게 많은 양의 컴퓨팅 용량을 필요로 하면 사용한다.
EC2 Security Group
방화벽이라고 생각하면 된다.
보안 그룹 규칙
name, Description, Protocol, Port range, IP address, IP range, Security Group name 등을 설정 가능
In/out bound 지정 가능, 모든 인터넷 프로토콜 지원, 인스턴스 동작 중에도 규칙 변경이 가능하다.
IP Range 대신, 어느 SG로부터의 트래픽을 허용할지 지정가능하다.
계층적인 네트워크 구조 생성 가능하다.
예를 들어, web 방화벽은 80, 22만 열어두고, App은 8080,22만 열어두고, DB는 3306과 22만 열어두고, Mgmt라는 시큐리티 그룹이라는 것에 속해있는 그룹들만 넣어둘 수 있다.
HTTP(80) / TCP 6 / Port Range 80 / Source 가 0.0.0.0/0 이라면, 이 그룹의 호스트는 인터넷에서 80(HTTP)로만 연결 가능하다.
Custom TCP Rule / TCP 6 / Port Range 2345 / Source가 암호화되어 있다면, 이 그룹의 호스트는 MyWebServers Security Group에 속한 인스턴스만 포트 2345로 연결 가능하다.
즉, Source는 해당하는 IP range를 정해줄 수 있는 것이다.
EC2 접속 암호
표준 SSH RSA key pair
Public/Private Keys
Private keys 는 AWS에 저장되지 않음
EC2 key pairs
Linux –최초 로그인시 SSH key pair 생성
Windows –관리자 암호 불러오기
AWS가 제공하는 초기 OS 접속 방법
높은 보안성 제공
Personalized
VPC 서비스
Virtual Private Cloud
사용자가 정의한 가상의 네트워크 환경
통신을 위한 기본 네트워크이다.
보안 강화 목적
공인 아이피로만 사용하지 말고, 일정 부분 뗴어서 private IP로 사용하자는 개념이 생겼다.
부족한 IP를 할당해준다.
VPC 생성 과정
Region 설정 (IP 대역을 결정 한다)
가용영역(AZ)에 Subnet 생성
Routing 설정
Traffic 통제(In/Out)의 순서
IP range 결정
IP address group을 결정하고, CIDR 기법을 이용해서 결정
CIDR 클래스 없는 도메인 간 IP 할당 기법이다.
Class는 IP Class이다.
IP Class
IP는 2진수로 변경시 총 32자리이다. 그걸 4 구간으로 나눠서 표현한다.
앞의 8자리(첫번쨰 옥텟)는 Network = 할당하고자 하는 IP 대역 지정
나머지 24자리는 Host = 지정한 Network 내 할당 가능한 IP이다.
A class = 0~127을 NetWork 주소로 정한다. (123 / 0. 0.0) - 나머지 3개(Host)의 범위는 16777214개
B class = 두번째 옥텟까지 사용하여 128~191.255까지 표현한다. 나머지 2개의 범위는 65534개
C class = 세번째 옥텟까지 사용하여 192.0~223.255.255까지 표현한다. 나머지 1개의 범위는 254이다.
즉, Host의 개수에 따라서 몇개의 기기를 사용할 건지에 대해 결정해준다.
장점 : IP의 Network를 단순하게 나눠서 범위를 관리할 수 있다.
단점 : Network 할당에 대한 자유도가 낮다. - 하나의 Network에 300개가 필요하다면?
세밀하게 관리해보기 위해서 나오는 게 Subnet Mask
Subnet Mask
Ip class 방식의 Network를 좀 더 잘게 쪼개서 사용한다.
172.16.0.0 은 B 클래스인데,
111111.11111111, 1111111, 000000을 위와 AND로 해준다.(IP Class로는 255.255.255.0)
그러면 사실상 세번쨰 0이 그대로 내려오므로, Host 대역이 Network 대역으로 바뀐다.
만약에 11111111.11111111.0000000.0000000과 AND 해주면?
B class 자체로 활용할 수 있다.
그러면 IP range 상 B Class 임에도, subnet mask를 활용해서 Host 대역은 Class와 동일하게 분할해 주는 효과가 있다.
Network 범위를 Subnet mask를 활용하면 훨씬 유연하게 지정 가능하다.
Class 라는 분류가 굳이 필요한지에 대한 의문이 든다.
따라서 서브넷 마스크의 세번째, 네번째 숫자가 관건이 된다.
만약 255.255.255.255라면, Host는 1개 밖에 없다.
그러나 255.255.255.000이라면, 256개가 된다.
그래서 CIDR 숫자가 높을 수록, Network 내 할당 가능한 Host 개수가 줄어든다.
타이트하게 IP를 관리하고 싶다면, CIDR 숫자를 높여 Network를 촘촘하게 관리한다.
다만 CIDR 숫자를 너무 타이트하게 관리하는 경우, 추후 동일 Network에 대해 IP 부족 현상이 일어난다.
VPC CIDR 설정
VPC 내 위치한 서버들이 사용할 Private IP의 범위를 지정하는 것
CIDR은 VPC 생성 이후로는 변경이 불가하다.
VPC CIDR은 16~28 bit 사이로 설정이 가능하다.
RPC 1918 가이드에 따라 사설 네트워크 대역으로 설정할 것을 권장한다.
https://tools.ietf.org/html/rfc1918
구축할 서비스의 규모는 얼마나 되는가
IP소모가 많은 시스템인가
추후 서비스 확장 가능성이 높은가
타 시스템과 연계 가능성은 있는가
Subnet 설정
VPC의 IP 대역을 적절한 단위로 분할 지정
172.16.0.0 대역이라는 건, 172.16.255.255까지 사용하겠다고 한 건데,
172.16.0.0/24 = VPC subnet으로 사용
172.16.1.0/24 = 172.16.1.0~24
172.16.2.0/24 ... 172.16.2.0~24
등등, IP 대역 자체를 또 쪼갠다.
각 Subnet도 VPC와 마찬가지로 CIDR을 이용해 IP 범위를 지정, 각 Subnet의 대역은 VPC의 대역에 존재해야 한다.
당연하지만 각 Subnet의 대역은 중복이 불가능하다.
본래 Subnetting의 주요 목적 중 하나는 Broadcating(전체를 데이터를 전달하는) 영역 분리이다.
하지만, AWS VPC는 Broadcat와 Multicat를 지원하지 않는다.
여기서의 주 목적은, Subnet 별로 경로를 제어해서, 원하는 트래픽만 Subnet 별로 받을 수 있도록 네트워크 레벨에서 격리 시키는 게 목적이다.
즉, Subnet 별로 보안 그룹을 설정해서, 해당하는 곳에서만 통신할 수 있도록 만드는 것이다.
Subnet의 Routing 설정
이렇게 Subnet이 각각 쪼개져 있으므로, 각 Subnet들이 통신하라면 라우팅 설정이 필요하다.
각 Subnet 쌍마다 routing에 대한 설정이 있고, 라우팅 테이블이 적힌다.
이 라우팅 테이블에는 Destination, Target, Status를 알려준다.
Destination이 172.16.0.0/16, Target이 Local, Status가 Active라면, 해당하는 곳으로 subnet이 다른 subnet으로 갈 수 있다.
Subnet 생성 시 고려 사항
- Subnet의 CIDR은 생성 후 변경 불가능하다.
- IP 대역을 너무 작게 하면 서비스 확장시 문제가 될 수 있으니 주의
Routing Table의 특징
- VPC 생성시 자동으로 Main Routing Table이 생성된다.
- Main Routing Table에는 기본적으로 VPC 내 모든 통신이 허락된 경로가 설정되어 있다.
기본 라우팅 테이블인 Main Routing 테이블은 삭제 불가능하다.
: https://aivleai.signin.aws.amazon.com/console
id와 비밀번호 입력해서 들어간다.
리전 이동은 콘솔 홈에서 오른쪽 위에서 리전을 선택해서 들어간다.
VPC 만들기 : Custom Route Table
VPC 내에 생성된 Subnet은 기본적으로 Local Router를 통하여 상호 통신이 가능하다.
그 외의 경우 (internet, on-premise와의 VPN 통신 및 DirectConnect 통신, VPC perring등)을 위한 추가적인 Route table 등록이 필요할 수 있습니다.