AWS 핵심 서비스 2

데이터베이스

데이터베이스의 종류

• 관계형 데이터베이스
  • Amazon RDS : Oracle, MySQL 등등
  • Amazon Aurora : AWS에서 직접 DBMS를 튜닝해서, AWS에서 최적화된 기능 제공.
  • Amazon Redshift : 특수 목적으로 사용함.
• 비관계형 데이터베이스
  • Amazon DynamoDB : 키-밸류 형태의 데이터를 적재하기 적합
• 비관계형 문서
  • Amazon DocumentDB
• 비관계형 인메모리
  • Amazon ElastiCache
• 비관계형 그래프
  • Amazon Neptune
• 비관계형 원장
  • Amazon QLDB

DIY(설치형)와 AWS 데이터베이스 서비스 비교

• Amazon EC2의 데이터베이스
  • 설치가 필요한 설치형 DB
  • OS레벨의 설정이 필요하다면 이 버전이 좋음.
  • 운영체제 액세스
  • 특정 애플리케이션의 기능 필요
• AWS 데이터베이스 서비스
  • 관리형태로 제공
  • PaaS형태의 서비스
  • 관리형태로 제공되기 때문에 OS 설정등을 할 필요가 없지만, 개입할 여지도 없음.
  • AWS에서 제공하는 특정 기능들만 사용 가능.
  • 대부분의 경우 관리의 용이성, 백업, 유지보수 등의 측면에서 선호됨.
  • 손쉬운 설정, 관리, 유지
  • 즉각적인 고가용성 구현
  • 성능에 초점
  • 관리형 인프라
• EC2에 DBMS를 설치해서 사용할 것인가, 설치되어 있는 관리형 서비스를 사용할 것인가 두 가지 선택지가 있다.

네트워크

Amazon Virtual Private Cloud(Amazon VPC)

• 리전 + 가용영역 + VPC
  리전과 가용영역은 물리적인 관점에서의 네트워크 영역이라면, 논리적인 네트워크 망으로써의 기준은 VPC.
• VPC : 가상의 사설 클라우드
  기본적으로 AWS 한 계정 당 세개가 생성됨. 최대 16bit, 즉 6만 4천여개의 IP개수를 가지는 레인지를 설정 가능함.
• 금융권의 경우 운영 네트워크 환경과 개발 네트워크 환경이 완전히 분리되어야 하고, AWS에서는 VPC를 나누는 기준으로 사용할 수 있다.
  분리된 VPC는 VPC 피어링이라는 별도의 연결 작업을 하지 않는 이상 상호간 통신이 불가능하게 된다.
  상호 통신이 분리되어야 논리적으로 망이 분리되었다고 할 수 있음.
• 기본적으로 AWS에서 작업을 할 때에는 VPC를 만들고 그 위에 서브넷을 만들고 그 위에 서버나 RDS 등을 올리게 된다.
• VPC 단위로 리소스가 생성이 되고 권한이나 보안 등의 설정이 적용됨.
  VPC가 달라졌다면 환경이 달라졌다고 생각해도 무방

서브넷을 사용하여 VPC 분리

• 서브넷은 리소스 그룹을 격리할 수 있는 VPC IP 주소 범위의 세그먼트 또는 파티션
• 서브넷은 인터넷 접근성을 정의
• 퍼븍릭은 인터넷에서 직접 액세스 가능
• 프라이빗 서브넷
  • 인터넷 게이트웨이에 대한 라우팅 테이블 항목 없음
  • 퍼블릭 인터넷에서 직접 액세스 불가

• 그림의 경우 가용영역을 걸쳐서 VPC를 생성했음.
  하나의 VPC에는 3개 혹은 2개의 가용영역을 넣어서 가용영역을 최대한 활용할 수 있는 아키텍쳐를 구성하게 된다.
• 서브넷 같은 경우에는 tier를 나눈다고 했을 때, 인터넷 페이싱의 DMZ티어, WEB 티어, 마스터 티어, DB 티어 등 세로로 분리가 된다. 각 티어마다 서브넷을 에이지 별로 생성하게 된다.
  (그림에서는 에이지가 두 개. 퍼블릭 서브넷을 에이지 하나씩에 할당해 에이지 이중화를 했다.)
• 서브넷에 대한 경로 설정은 라우팅 테이블에서 하게 되는데, 라우팅 테이블은 서브넷을 기준으로 적용이 됨.
  특정 서브넷이 특정 영역과 통신을 한다고 했을 때, 해당 경로를 라우팅 테이블 업데이트 하면 특정 서브넷만 특정 영역과 통신할 수 있도록 구성할 수 있다.
• 주로 퍼블릭 서브넷에는 로드밸런서를 위치시키게 된다. 로드밸런서는 공인 IP를 갖고 인터넷과 통신을 하고, 그 밑으로는 WEB WAS DB를 프라이빗 서브넷에 위치시킨다. 로드 밸런서와 WEB WAS DB는 사설 IP 통신을 해서 외부에서는 프라이빗 서브넷에 있는 리소스들을 볼 수 없다.
• 더욱 안전하게 만들 수 있다는 것.

VPC의 계층화된 네트워크 방어

1. 라우팅 테이블을 통한 접근 제어

• 접근 제어 : 어떤 네트워크, IP가 들어올 수 있는지 라우팅 테이블로 설정 가능
• VPC 하나를 하나의 라우팅 테이블로 구성할수도 있지만, 티어별로 라우팅 테이블을 따로 구성하고, 별도의 라우팅 정책을 구성할수도 있다.
  티어별로 라우팅 테이블을 별도 설정하는 것이 일반적.

2. VPC 세그먼트를 나누는 서브넷 단위의 네트워크 액세스 컨트롤

• 인바운드(들어오고)/아웃바운드(나가는) IP나 포트를 허용하고 제한할 수 있음.

3. 보안 그룹을 통해 EC2에 들어오는 특정 네트워크에 대해 허용하고 거부할 수 있음.
4. 서드파티, 다른 상용 제품을 설치하는 것으로 OS레벨, 네트워크 레벨에서 보호할 수 있다.

   계층적인 방어가 되는, 보안적으로 잘 꾸려진 아키텍쳐 생성 가능.

인프라 구조화

• 인터넷 게이트웨이 : 외부 인터넷과 내부 인터넷의 인터페이스 통신을 조절하는 리소스
• 라우팅 테이블 : 설정을 통해 네트워크의 접근 허용/거부
• 네트워크 ACL & 서브넷 : 서브넷 ACL에서 허용된 IP, 프로토콜, 포트만 접근 가능.
• 인스턴스 수준의 SG를 통해서 제어.
• 이정도 구성을 해야 외부 공격자의 침해에 대해서 방어할 수 있다.
  내부의 사용자가 악의적인 목적으로 데이터를 유출하는 사태에 대해서도 방어 가능.
• ACL의 경우 들어온 것과 나가는 경로에 대해서 모두 허용이 되어야 하지만,
  SG같은 경우 들어온 것은 경로를 명시해주지 않아도 나갈 수 있다.
• ACL과 SG를 모두 적용했을 때 관리 포인트가 많아지고 특정 트래픽이 문제가 되는 경우, 즉 통신이 되어야 하는데 그렇지 않은 경우 그것을 해결하기 위한 트러블슈팅 과정에서 많은 어려움이 생기기 때문에 ACL은 웬만해서는 사용하지 않고, SG만 사용하는 경우가 많다.

Elastic Load Balancing(ELB)

• 수신되는 애플리케이션 트래픽을 여러 Amazon EC2 인스턴스, 컨테이너, IP 주소에 분산하는 관리형 로드 밸런싱 서비스

• 고가용성
• 상태 확인
• 보안 기능
  • SG을 통해서 인바운드/아웃바운드 통제

• 여러 사용자가 특정 서비스에 접속하게 될 때 로드밸런서에 접속하게된다.
  라운드 로빈이 가장 일반적인데, 첫번째 트래픽-첫번째 인스턴스, 두번째 트랙픽-두번째 인스턴스 같이 고르게 트래픽을 분산하는 방식.
• 인스턴스가 부족하게 될 때 자동으로 확장하는 역할도 수행한다.
• 클라우드 아키텍쳐에서 로드밸런서를 정말 많이 사용하게 되는데, 로드밸런서가 EC2 앞에 위치해야 확장성, 오트스케일 등의 설정이 용이해진다.

• 어플리케이션 로드밸런서(ALB), 네트워크 로드밸런서(NLB), 게이트웨이 로드밸런서 등이 있음. (게이트웨이 로드밸런서는 일반적인 경우에는 사용하지 않음.)
• ALB : 도메인, URL 까지 볼 수 있는 L7 계층의 로드밸런서.
  웹 서버가 인터넷을 접하지 않고, L7 로드밸런서가 공인IP 또는 서비스 도메인을 ELB에 적용을 하고 ELB가 인터넷 페이싱을 하는 구성을 할 수 있음.
• NLB : L4 - IP, 포트, 프로토콜에 대해서 로드밸런싱을 수행함.
• 성능 면에서는 NLB가 훨씬 빠르고 더 많은 작업을 수행할 수 있음.
  하지만 ALB를 더 많이 사용하는데, API를 통한 애플리케이션 연계가 많고 그에 따른 DNS, URL 베이스로 통신이 많이 이루어지기 때문.

Amazon Route 53

• 가용성과 확장성이 뛰어난 클라우드 Domain Name System(DNS) 서비스

• DNS는 도메인 이름을 IP주소로 변환
• 도메인 이름을 구입하여 관리하고 DNS 설정을 자동으로 구성할 수 있음
• AWS에서 유연한 고성능, 고가용성 아키텍처를 위한 도구를 제공
• 멀티플 라우팅 옵션

• Public Hosted Zone : VPC 외부의 사용자가 도메인을 검색했을 때 IP를 찾아줌.
• Private Hosted Zone : 내부에 권한이 있는 사용자들이 내부 시스템 연결을 위한 URL을 통해 애플리케이션을 연결한다고 할 때 실제 리소스 IP와 연계해서 통신을 도와줌.

보안

• 보안은 AWS의 최우선 과제

• 많은 기업들의 클라우드 이행에 가장 걱정점이 보안에 관한 부분.
  이런 걱정을 불식시키기위해 AWS에서는 보안에 많은 신경을 쓰고 있다.

공동 책임 모델

• 누가 어느 영역에 대한 보안을 책임질 것인가에 대해 명시.
• 물리적인 부분과 하드웨어적인 부분에 대한 보안책임은 AWS가 전담해서 책임을 짐.
• 네트워크 트래픽 : WAS 서버와 WEB 서버, WAS 서버와 데이터 서버 간의 네트워크.

AWS Identity and Access Management(IAM)

• AWS 리소스에 대한 액세스를 안전하게 제어
• AWS 계정을 생성하면 root account가 생성된다.
  root account로는 모두 설정 가능.

• 다양한 권한 제어 옵션
• 사용자, 그룹 또는 역할에 세분화된 권한 할당
• WAS, WEB서버와 같은 경우에도 역할을 부여하고 권한을 제어해서, 서버가 DBMS의 특정 기능만 사용할 수 있도록 설정 가능.
  • 외부의 공격자가 WAS서버의 공격에 성공해서 WAS서버의 전체 권한을 획득했을 때 WAS서버가 타 서비스에 대해 권한을 갖고 있다면 공격자는 WAS서버를 이용해서 모든 것에 접근이 가능함.
    따라서 WAS서버 역시 필수적인 최소한의 권한만을 부여해서 서비스가 운영되도록 설정해야 발생할지도 모르는 공격에 대처를 하거나, 피해를 줄일 수 있다.
• AWS 계정에 대한 임시 액세스 공유
• 회사 네트워크의 사용자 연동 또는 인터넷 자격 증명 공급자와 연동

IAM 구성요소

• root account로 사용자 계정, IAM 계정을 생성한다.
  사용자는 보안담당자, 서버담당자, 네트워크 담당자 등 그룹을 생성한다.
  그룹에 역할과 권한과 정책을 부여할 수 있다.
• IAM은 AWS에서 발생하는 액세스를 관리하는 리소스.
• 시스템을 오픈했을 때 검사 체크리스트가 있다.
  IAM을 통해서 요구사항을 만족할 수 있다.

IAM 사용자

• 별도의 AWS계정이 아닌, 루트 계정 밑에서 생성된 IAM 사용자를 말함.
• (사용자는 사용자 자체에도 권한을 부여할 수 있지만) 그룹에다가 권한을 부여하고 그룹에 사용자를 할당하는 방식을 사용.
• 잘 짜여진 권한 체계는 특정 작업을 하는 사용자 그룹별로 권한 분리 가능.

Amazon S3 액세스 제어 : 일반

• 일부 서비스는 S3 버킷 정책과 같은 리소스 기반 정책을 지원.

• 인터넷에 노출시켜서 외부 사용자가 이용할 수 있도록 하는 것.
• 왼쪽 : 관리자는 접근이 가능하지만, 외부 사용자는 프라이빗 버켓에 접근할 수 없음.
• 중간 : 모든 사람이 퍼블릭 S3에 접근 가능함
• 오른쪽 : 제한된 사람에게만 접근을 허용함.

AWS CloundTrail

• AWS 계정의 사용자 활동 및 API 사용 추적

• 지속적으로 사용자 활동을 모니터링하고 API 호출 이력을 기록
• 규정 준수 감사, 보안문제, 문제 해결에 유용
• 로그 파일은 Amazon S3 버켓으로 전송됨.
• 침해사고가 발생하거나 애플리케이션 장애가 났을 때 등에 활용할 수 있다.

AWS Trusted Advisor

• 비용 절감, 성능 개선, 보안 강화에 도움이 되는 지침을 제공하는 서비스

• 각 사용자에게 맞는 조언을 제공한다.