Amazon Network Service

VPC(Amazon Virtual Private Cloud)

: AWS 클라우드에서 논리적으로 격리(분리)된 공간을 프로비저닝하여 고객이 정의하는 가상 네트워크에서 AWS 리소스를 시작할 수 있다.

IP 주소 범위 선택(CIDR), 서브넷 생성, 라우팅 테이블 및 네트워크 게이트웨이(인터넷 게이트웨이, ...) 구성 등 가상 네트워킹 환경을 완벽하게 제어할 수 있다.
IPv4와 IPv6를 모두 사용하여 리소스와 애플리케이션에 안전하고 쉽게 액세스할 수 있다.
양방향(인/아웃바운드) 액세스를 제공하고 공개적으로 제어가 가능하다.

-> 네트워크 환경을 직접 설계할 수 있다.

리소스에 대한 사용자 지정 액세스 제어, 통제 및 보안 설정을 허용하고 감시할 수 있는 모니터링을 제공한다.
VPC vs VPC 연결 => VPC peering

리소스가 차지할 특정 CIDR을 지정할 수 있다. 이 지정을 통해 private 네트워크의 사용할 수 있는 네트워크 범위를 지정한다.
엄격한 인바운드, 아웃바운드 트래픽 규칙을 제공한다.
하나의 AWS region에 배포해야 하지만 해당 region 내의 모든 가용 영역에서 리소스를 호스팅 할 수 있다. 기본적으로 계정 당 region 당 최대 5개의 VPC를 보유할 수 있다.

클라우드에서 CIDR은 RFC1918을 기준으로 지정한다.

VPC 패턴

1. 단일 VPC 패턴
: 소규모 팀이 운영하는 소규모 단일 애플리케이션인 경우

2. 다중 VPC 패턴
: 하나의 팀이 여러개의 VPC를 관리하는 경우
대규모 전자 상거래 애플리케이션을 개발하는 단일팀은 개발자가 개발/프로덕션 환경에 대한 전체 액세스 권한이 있을 때 유용

3. 다중 계정을 활용햔 VPC 패턴
: 대규모 조직 및 여러 IT 팀이 있는 조직, 빠른 성장이 예상되는 중간 규모의 조직

Subnet을 사용하여 VPC 분리

서브넷은 리소스 그룹을 격리할 수 있는 VPC IP 주소 범위의 세그먼트 또는 파티션이다.

ex) 만약 10.10.0.0/22으로 VPC를 설정했다면?
=> 10.10.0.0 ~ 10.10.3.255(1024개) 각 층 별로 배분을 해준다.

AWS의 가용영역에 의해 subnet을 구분하며 더 많은 네트워크를 구성하기 위한 목적으로 사용한다. IGW와 연결이 가능하면 public subnet, 불가능하면 private subnet으로 구분된다.

• public subnet : 인터넷에 연결해야 하는 리소스(서비스)
  Internet Gateway, ELB, Public IP/Elastic IP를 가진 인스턴스를 내부에 가지고 있따.
  특히, public subnet 내에 있는 NAT Gateway를 통하여 private subnet 내에 있는 인스턴스의 연결이 가능하게 된다.

• private subnet : 인터넷과 격리된 상태를 유지해야하는 리소스(서비스)
  기본적으로 외부와 차단되어 있다.
  private subnet 내의 인스턴스들은 private IP만을 가지고 있으며 internet inbound/outbound가 불가능하고 오직 다른 서브넷과의 연결만이 가능하다.
  일반적으로 제한된 아웃바운드 퍼블릭 인터넷 액세스를 지원하기 위해 NAT Gateway를 사용한다.

=> 서브넷을 사용하여 인터넷 액세스 접근정을 정의(제어)한다.

권장 Subnet 구성

데이터 스토어 인스턴스 - 프라이빗 서브넷
배치 처리 인스턴스 - 프라이빗 서브넷
백엔드 인스턴스 - 프라이빗 서브넷
웹 애플리케이션 인스턴스 - 퍼블릭 또는 프라이빗 서브넷

Routing table

VPC 리소스 간에 트래픽 연결에 필요하다. 모든 서브넷에는 연결된 라우팅 테이블이 요구된다. VPC를 생성하면 자동으로 기본 라우팅 테이블이 생성된다. 처음에는 기본 라우팅 테이블에 단일 경로 즉, VPC 내 모든 리소스에 대하여 통신을 허용하는 로컬 경로만 포함한다. 라우팅 테이블의 로컬 경로는 수정이 불가하다. VPC에서 인스턴스를 시작할 때마다 로컬경로는 해당 인스턴스에 자동으로 적용된다.

인터넷 게이트웨이(IGW)

: VPC와 인터넷 간의 연결
인터넷 게이트웨이가 없으면 아무도 VPC 내의 리소스에 액세스할 수 없다.

고객이 커피숍에 들어갈 때 사용하는 출입구와 유사하다.

인터넷 게이트웨이와 특정 인스턴스와 트래픽을 주고받아야 한다. 이 라인을 잡아주는 것이 라우팅 테이블이다.
라우팅 테이블에서 상위부터 매칭되는 IP에 대한 타깃을 찾고, 없으면 가장 마지막 대상 igw-id를 찾아 주소를 확인한다.
인터넷으로 라우팅 가능한 트래픽에 대한 서브넷 라우팅 테이블에 대상을 제공한다.

가상 프라이빗 게이트웨이(VPG)

: VPC의 프라이빗 리소스에 액세스하기 위해 가상 프라이빗 게이트웨이를 사용한다.
VPG를 사용하면 VPC와 사설 네트워크 간에 VPN(가상 사설망) 연결을 설정할 수 있다.
VPG는 승인된 네트워크에서 오는 경우에만 VPC로의 트래픽을 허용한다.

AWS Direct Connect(DX)

: 데이터 센터와 VPC 간에 전용 프라이빗 연결을 설정할 수 있는 서비스이다.
네트워크 비용을 줄이고 네트워크를 통해 이동할 수 있는 대역폭의 양을 늘리는데 도움이 된다.

NAT 게이트웨이(NGW)

: private subnet이 인터넷과 연결하기 위한 아웃바운드 인스턴스

public subnet상에서 동작하는 NAT 게이트웨이는 private subnet에서 외부로 요청하는 아웃바운드 트래픽을 받아 인터넷 게이트웨이와 연결된다. public subnet에 존재하는 인스턴스들은 인터넷 게이트웨이와 연결되어 있기 때문에 private subnet의 인스턴스들도 인터넷 사용이 가능해진다.

NAT 게이트웨이 생성시 public IP 할당이 필요하다.
=> public IP는 public IP와의 통신 연결이 필요하기 때문이다.

탄력적 네트워크 인터페이스(ENI, Elastic Network Interface)

: 동일한 가용 영역의 EC2 인스턴스 간에 이동할 수 있는 가상 네트워크 인터페이스
프라이빗 IP 주소, 탄력적 IP 주소, MAC 주소 유지

여러 네트워크 인터페이스를 하나의 인스턴스에 연결하면 유용하다.
-> 관리 네트워크 생성, VPC에서 네트워크 및 보안 어플라이언스 사용, 별도의 서브넷에 있는 워크로드/역할로 이중 홈 인스턴스 생성, 저예산 고가용성 솔루션 생성

탄력적 IP 주소

: 동적 클라우드 컴퓨팅을 위해 설계된 고정 퍼블릭 IPv4 주소
EIP를 사용하지 않으면 인스턴스를 재부팅할 때마다 할당 받은 IP 주소가 변경된다. 주소를 VPC의 다른 인스턴스에 신속하게 다시 매핑하여 인스턴스의 장애에 대비 가능하다.
EIP를 인스턴스와 직접 연결하는 대신 네트워크 인터페이스에 연결하면 네트워크 인터페이스의 모든 속성을 한번에 한 인스턴스에서 다른 인스턴스로 이동 가능하다.

VPC 간의 연결

온프레미스와 VPC

온프레미스와 VPC - DX

VPC peering

: 양쪽 VPC간의 동의를 통해 구성된다. peering 요청과 peering 승인 후 route table을 작성한다.
인터넷 게이트웨이나 가상 게이트웨이를 거치지 않고 직접적으로 연결된다.
PCW(Peering Connection Gateway)를 통해 구성한다.

ex) 공유 서비스용 VPC peering

ex) 다수의 VPC 피어링 서비스, Transit Gateway

보안 그룹(Security Group)

: 하나 이상의 인스턴스에 대한 인바운드, 아웃바운드에 대한 가상의 방화벽을 제공한다.
기본값은 모든 것을 차단(deny)하는 정책이다. 모든 인바운드는 차단, 모든 아웃바운드는 허용이다.
같은 security group을 사용하는 인스턴스간의 통신은 허용된다.
상태 저장 규칙 기반이기 떄문에 인바운드 요청이 허용되는 경우 자동으로 아웃바운드가 허용된다. 들어올 때 connection을 그대로 기억하여 나갈 때 그 연결성을 그대로 사용한다.

보안 그룹 체인

: 보안 그룹과 보안 그룹을 연결한다.

Network ACL(NACL)

: 서브넷 단위로 가상의 방화벽을 만들어 트래픽을 제어한다.
기본값은 모든 것을 허용(allow)하는 정책이다. 모든 인바운드, 아웃바운드 트래픽을 허용한다.
상태 비저장이므로 인바운드 및 아웃바운드 트래픽 모두에 대한 명시적인 규칙이 필요하다. 들어가고 나오는 규칙을 반드시 설정해야 한다.

VPC 생성 실습 1

• VPC 생성 클릭
  

• VPC 등 선택
  

• 그림 확인
  

• 이름과 cidr 설정
  

• 가용 영역 수 설정
  

• 서브넷 개수 설정
  

• NAT 게이트웨이, VPC 엔드포인트 설정
  

• 만들어지는 과정 확인
  

• 생성 확인
  

• 서브넷 생성 확인
  

• 탄력적 IP도 생겼다.
  

• 보안 그룹 탭 이동
  

• 이름 설정하고 VPC 선택 - default 삭제하고 다시 선택해야 한다
  

• SSH, HTTP 허용
  

• EC2에서 인스턴스 생성
  

• 이름 설정
  

• 기존 이미지 선택
  

• 인스턴스 유형, 키 페어 선택
  

• 네트워크를 생성한 VPC로 설정
  

• 보안 그룹도 생성한 보안 그룹으로 선택
  

• 생성 완료
  

• db 인스턴스 생성
  

• 이미지 사용
  

• 인스턴스 유형, 키 페어 선택
  

• 네트워크 선택
  

  • 보안 그룹 만들기
    
  • 만든 VPC 선택
    
  • mysql을 허용해준다
    

• 보안 그룹 선택
  

• 인스턴스 생성
  

• public(web)에서 private(db)로 들어가기

• mykakao-web의 퍼블릭 주소로 putty 연결
  

• winscp로 pem key를 넣어준다.
  

• db 보안 그룹 인바운드 규칙 편집
  

• SSH 허용
  

• pem key를 넣고 ssh 접속을 한다.

[ec2-user@ip-10-0-7-132 ~]$ vi kakao-oeckikek.pem

## ssh 접속
[ec2-user@ip-10-0-7-132 ~]$ sudo ssh -i kakao-oeckikek.pem ec2-user@10.0.135.82

## 접속 성공
[ec2-user@ip-10-0-135-82 ~]$

• SSM 방법으로도 가능하다

삭제 순서

NAT gateway 삭제
EIP release
route table subnet 연결 제거
route table 삭제
subnet 삭제
IGW detach
IGW 삭제
VPC 삭제

VPC 생성 실습 2

AWS Database Service

: 데이터베이스는 수집, 저장, 분석 생태계로 구성되어 있다.

Amazon은 데이터를 캡처하고 저장하는 트랜잭션 데이터베이스, 대량 데이터의 추세를 분석하고 발견할 수 있는 다양한 데이터웨어하우스를 제공한다.

데이터베이스 선정 시 고려사항

• 확장성
  : 얼마나 많은 처리량이 필요한가(초당/분당 트랜잭션)
  나중에 확장이 가능한가

• 스토리지 요구 사항
  : 데이터베이스가 얼마나 커야 하는가(GB, TB, PB 규모인가)
  어디에 담을지 - All flash-Disk(SSD) / HDD
  IOPS/MBPS

• 객체 크기 및 유형
  : 데이터베이스에 무얼 담을까. 단순 데이터 구조, 대용량 데이터 객체
  객체 유형에 따라서 데이터베이스를 다르게 선택한다.

• 내구성(=내결함성) => Multi-AZ를 사용해야 하는지
  : 어떤 수준의 데이터 내구성, 데이터 가용성 및 복구성이 필요한가 - master/standby
  관련 규제 의무가 있는가

데이터베이스 유형

• 관계형(정형데이터)
  : 데이터를 넣는 방식, 규칙이 정해져 있다.
  엄격한 스키마 규칙 및 데이터 품질(성능) 적용이 필요하다. 형식이 다르면 입력이 불가능하다.
  데이터베이스가 과도한(실시간) 읽기/쓰기 용량을 필요로 하지 않는다.
  => Dynamo DB가 더 좋다.
  ex) Amazon Aurora, MYSQL, MariaDB, Oracle Database, ...

  RDS로 어려운 부분?
  : 시계열성 데이터 처리가 어렵다. 센서 데이터 같은 실시간으로 입력, 처리, 조회 등의 읽기/쓰기가 많은 경우는 RDS 보다는 NoSQL이 적합하다.
  

• 비관계형(비정형데이터)
  : 데이터를 넣는 방식, 규칙이 정해져 있지 않다. key, value 구조이다.
  데이터베이스를 수평적으로 확장해야 한다. 데이터가 기존 스키마에 적합하지 않다.
  ex) Amazon DynamoDB, MongoDB, ...

NoSQL 데이터베이스를 사용해야 하는 이유

: 유연성, 확장성, 고성능, 고기능성

Amazon Database 유형

Amazon RDS : 완전 관리형 서비스

: 스키마 구조가 복잡한 데이터를 사용하는 애플리케이션
특정한 포맷 형식의 구문 규칙을 만족하는 경우에만 입력이 되도록 설계가 필요한 애플리케이션

H/W의 사전 준비, 데이터베이스 설치/패치/백업 등의 시간 소모적인 관리 작업을 자동화하여 비용 효율적이며, 언제든 크기 조정 가능한 용량을 제공한다. 따라서 사용자는 application에 집중하여 빠른 성능, 고가용성, 보안 등을 제공할 수 있도록 지원한다.

RDS instance에 직접 접근 하는 것은 불가능하다.(DB 접근만 가능하다)

cloudwatch 연결을 통해 DB instance monitoring이 가능하다.

실습

• 데이터베이스 탭 클릭
  
• 데이터베이스 생성
  
• 표준 생성으로 선택
  
• MySQl 엔진 옵션 선택
  
• 프로덕션에서만 master/standby를 지원한다. - 프리티어로 선택
  
• 이름과 비밀번호 설정
  
• 스토리지
  
• 보안 그룹 선택
  
• 데이터베이스 옵션 선택
  
• 생성 완료
  
• 보안 그룹에서 mysql port 열어주기
  

## EC2 instance에서 연결
[ec2-user@ip-172-31-40-76 ~]$ mysql -uadmin -p -h kakao-instance.cl36vm2fbrhx.ap-northeast-2.rds.amazonaws.com
Enter password:
MySQL [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| kakaodb            |
| mysql              |
| performance_schema |
| sys                |
+--------------------+