AWS

newhyork·2022년 6월 5일

aws boto3 cloud

AWS

Amazon Web Service

Amazon에서 제공하는 클라우드 컴퓨팅 서비스이다.
- 클라우드 컴퓨팅에 간단히 알아보자면 다음과 같다.
  - 인터넷(클라우드)을 통해 IT 리소스(서버, 스토리지, 네트워크 인프라 등)을
    on demand로 제공하는 것이다.
  - 물리적 형태의 실물 컴퓨팅 리소스를 네트워크 기반의 서비스 형태로써 제공한다.
    즉, 사용자들은 네트워크 상에서 클라우드 서비스의 리소스를 사용하는 것이다.
  - 대표적으로 IaaS, PaaS, SaaS가 있고, 제공하는 서비스 종류로 나눈다.
    - AWS에서 제공하는 대표적인 리소스들은 보통 IaaS 형태이고,
    구글 드라이브나 네이버의 Mybox 같은 것은 SaaS라 할 수 있다.
    PaaS로는 heroku를 생각해볼 수 있다.
서버(EC2 등), 스토리지(S3 등), 네트워크 인프라(Route53 등) 등 다양한 서비스가 있다.

AWS EC2

Elastic Compute Cloud

직접 서버(하드웨어 장비)를 구입하는 대신,
클라우드에 서버를 띄워 운영할 수 있는 기능을 제공하는 서비스이다.
각각의 서버를 인스턴스라고 칭한다.
ELB를 통해 트래픽을 분산한다거나 Auto Scaling을 통해 서버를 확장하는 기능을 이용하여,
애플리케이션에 대해 고가용성 및 고성능 인프라로 개발할 수 있다.
region을 선택하는 것으로 해당 지역에 있는 데이터 센터를 이용하게 된다.

AWS Lambda

Serverless architecture로 구축하고자 할 때 주로 사용한다.
서버 자체가 없다는 게 아니고, EC2처럼 개발자가 서버를 운영하는 형태가 아닌 것이다.
쉽게 말해 그냥 함수이다.
클라우드에 함수를 저장해 놓고, 해당 함수를 사용한 시간만큼 요금을 지불하는 방식이다.
- 지원되는 언어로 Lambda 함수의 코드를 구성한다.
- event-driven 기반이다. (trigger)
AWS의 다른 서비스와 연계하여 주로 사용하곤 한다.
- API Gateway를 사용하여 HTTP 요청을 Lambda의 함수로 라우팅하는 방식으로 사용.
- SQS message를 처리.
- 스토리지(S3 등)나 DB(Dynamo 등)의 데이터 처리와 관련한 작업.

AWS EB

Elastic Beanstalk

지원되는 언어로 작성된 코드 파일들을 압축하여 업로드하기만 하면,
하나의 애플리케이션을 알아서 배포까지 해주는 서비스를 제공한다.
- 즉, 따로 직접 서버를 구축하는 작업 등이 불필요하다.
- 해당 애플리케이션 구축에 사용된 인프라(EC2 등)에 대해 비용이 청구되는 방식이다.
- 하나의 애플리케이션에 대해 여러 환경을 구성할 수도 있다.
ELB, Auto scailing도 자동으로 해줄 수 있고,
이 밖에 버전 관리, 모니터링, 로깅 등도 지원한다.
주로 웹 애플리케이션을 배포하는 용도로써 웹 서버 환경을 채택하여 사용하지만,
SQS를 이용하는 message 처리를 위한 애플리케이션에 대해서는
작업자(worker) 환경으로 채택하여 사용할 수 있다.

AWS S3

Simple Storage Service

클라우드 저장소(Storage)이다.
(저장소는 데이터베이스(DB)와는 다르다. 디스크에 가깝다.)
- PDF, 로그, 이미지, 동영상 파일 등을 저장할 수 있다.
용어
- 객체: 저장하는 파일 각각을 의미한다.
- 버킷: 연관된 객체들을 grouping한 루트 디렉터리라 할 수 있다.
  버킷 단위로 region을 지정할 수 있다.
  (S3의 region이 글로벌로 고정된 것과는 다르다)
용도에 맞게 적절히 설계된 구조를 클래스라는 것으로써 제공한다.
객체의 액세스 패턴에 따라 결정하는 것이 좋다.
버전 관리 기능이 제공되어 복원할 수 있다.
버킷에 객체를 무한대로 저장할 수 있는 구조로, 확장 및 축소가 유연하다.
비교적 중요하지 않은 데이터는 RSS 방식을 사용하여 효율성을 꾀할 수 있다.
파일 업로드 시, 암호화할 수도 있다.
퍼블릭 액세스 차단 설정으로 버킷 단위의 전체적인 설정이 가능하다.
하위 항목인 버킷 정책과 버킷 및 객체의 ACL은 이 설정 값에 종속된다.
- 위 체크 값에 따라 버킷 정책은 무시될 수도 있다.
  - 버킷 정책이 유효한 경우 이에 따라 버킷이 공개 혹은 비공개 되며,
    객체 URL을 통한 퍼블릭 액세스 가능 여부를 결정한다.
- 전체 차단 시에는 객체 단위에서 설정한 ACL과 관계없이 퍼블릭 액세스가 불가능하다.
  즉, 객체에 ACL 설정을 해주었더라도 객체 URL을 통해 접근할 수 없다.
  - 파일(객체) 업로드 시 ACL(액세스 제어 목록)에서는
    AWS 계정별 및 퍼블릭의 객체에 대한 읽기/쓰기 권한을 각각 다르게 부여할 수 있다.
    즉 버킷은 비공개, 객체는 공개하는 형태로 액세스를 따로 설정할 수 있다.
    (단, 이러한 객체 단위의 ACL 설정이 유효하기 위해서는
    버킷의 모든 퍼블릭 액세스 차단 설정이 비활성화 되어야 한다.)
  - 버킷 단위로도 ACL이 있다.
정적 웹 사이트를 호스팅 하는 데에 사용할 수도 있다.

AWS RDS

Relational Database Service

EC2가 기존의 하드웨어 서버를 대신하듯이, 이는 RDB 서버를 대신할 수 있다.
EC2에 RDB 서버를 직접 띄우는 것과
따로 AWS RDS를 두고 운영하여 서비스를 제공하는 것의 가장 큰 차이는
DBMS 관리에 따른 부담을 줄일 수 있다는 것이다.
MySQL의 경우, workbench로 RDS에 접속하여 작업하는 것이 가능하다.

AWS DynamoDB

RDB를 대신하는 것이 있다면 NoSQL을 대신하는 것도 있을 것이다.
그러한 예 중 하나이다.
(이외에는 MongoDB기반의 DocumentDB가 있다.)
RDS와는 달리 꼭 EC2와 함께 사용할 필요는 없다.
따라서 Serverless 기반인 Lambda나 SQS와 연동하여 사용하곤 한다.
(AWS에서 개발한, DBMS 자체로써, 서버와는 독립적으로 사용할 수 있는 것으로 간주된다.)

AWS Route 53

AWS에서 제공하는 DNS(Domain Name System)이다.
도메인 이름에 따라 IP주소를 알려주는 등 DNS이 구축된 서비스를 제공한다.
- 도메인 이름이 있다면, 여러 DNS서버를 통해서 이에 연결된 IP주소를 찾게 된다.
  따라서, 거치는 단계가 많을 수록(지구 반대편에 있는 등, 멀수록)
  호스팅 서버(도메인 이름에 연결된 IP주소를 갖는 서버)에 늦게 도착한다.
  (단지 도메인 이름 만으로 해당 IP주소를 찾아갈 수 있는 것이 아니라
  DNS서버 덕분에 도메인 이름으로 IP주소를 알아내어 접속할 수 있게 되는 것이다.)
호스팅 영역 1개가 도메인 1개에 대응되며,
레코드라는 필드에서 해당 도메인 이름에 관련한 사항들을 설정할 수 있다.
- NS: DNS서버의 역할을 한다.
  기본적으로 4개가 주어지며, SOA와 함께 필수적인 레코드이다.
- A: 도메인 이름으로 특정 IP주소로 연결될 수 있게 설정한다.
- CNAME: 별칭을 통해 도메인 이름에 접근할 수 있게 한다.
  서브 도메인을 매핑시킬 때 사용한다.
호스트 영역을 Public(일반 DNS) 혹은 Private(AWS 내부)으로 선택할 수 있다.
EC2, S3 등 다양한 AWS와 연동하여 사용한다.
DNS 서비스를 제공하는 다른 서비스로는 가비아 등이 있다.
(도메인 이름을 파는 곳은 보통 자체적인 DNS서버를 구축하고 있다.)

AWS API Gateway

어떤 서비스를 MSA에 따라 작은 단위로 나누어 개발하였을 때,
endpoint 등을 통합적으로 관리할 수 있도록 해주는 서비스를 제공한다.
- 클라이언트는 각 서비스의 endpoint 대신 API Gateway로 요청을 보내게 되고,
  요청을 받은 API Gateway는 설정에 따라 각 서비스의 endpoint로 사용자 대신 요청하며,
  응답을 받으면 다시 사용자에게 전달하는 proxy 역할을 한다. (reverse proxy server)
- 구조 상으로는, 클라이언트와 API 서버 중간에 위치한다.
  - API 서버 대신 Lambda와 연동하여 사용하는 방법도 있다.
    Lambda 함수를 생성하고, trigger로써 API Gateway를 사용하는 방식이다.
    API Gateway의 endpoint는 호출할 Lambda 함수의 URL이다.
- 언어나 프레임워크에 얽매이지 않고 API를 개발할 수 있게 해준다.
- 여러 군데 흩어져 있는 API들을 하나로 통합하여 사용하고자 할 때,
  이를 쉽게 가능하게 해준다.
  즉, 서로 다른 서비스의 공통된 로직을 중복하여 구현해야 할 때 용이하다는 말이다.
API 요청을 한 데 모아 로깅, 모니터링 등을 할 수 있게 해준다.
이 밖에, 인증/인가 요청도 처리할 수 있고
IP주소를 제한함으로써 API를 통한 리소스 액세스도 제어할 수 있다.
현재는 REST API 뿐만 아니라 HTTP API도 지원하지만,
특별한 경우가 아니라면 보통 REST API 형태로 사용한다.

AWS CloudFront

AWS에서 제공하는 CDN(Contents Delivery Network) 서비스이다.
원본 데이터를 가지고 있는 서버를 오리진 서버라 하며,
이용하기에 따라 S3, EC2 인스턴스 등이 해당된다.
AWS가 제공하는 CDN 서버는 엣지 서버라고 한다.
- edge location: 컨텐츠를 캐싱하여, 클라이언트에게 제공하는 지점. (엣지 서버)
  전 세계 주요 도시에 300개 이상 분포되어있다.
- regional edge cache: 오리진 서버와 edge location 사이에 위치한다.
  edge location에서 캐싱할 만큼이 아닌 컨텐츠를 캐싱한다.
  대신 이곳에서 캐싱하는 컨텐츠는 더 오래 남아 있으며, 캐시 스토리지 용량이 크다.
  이를 통해 오리진 서버까지 요청하는 일을 줄일 수 있다.
정적 컨텐츠와 동적 컨텐츠 둘 다 캐싱할 수 있다.
HTTPS 방식을 이용할 경우, 오리진 서버에서 별도로 HTTPS를 지원하지 않더라도
클라이언트와 엣지 서버는 HTTPS로 통신을 하게 할 수 있다.
오리진 서버와 엣지 서버는 HTTP로 통신을 한다. (설정하기 나름이다)
특정 지역으로부터의 컨텐츠 접근을 제한할 수 있는 기능이 있다.
허용된 사용자만 접근할 수 있는 signed URL 기능이 있다.
- 유료 컨텐츠 제공에 사용될 수 있다.
- 해당 클라이언트만이 그 URL을 통해 컨텐츠를 이용할 수 있게 할 때 사용한다.
- 이와 비슷하게 signed cookie 기능도 있다.
  허용된 클라이언트가 다수의 유료 컨텐츠 등을 이용할 수 있게 할 때 사용한다.

AWS VPC

Virtual Private Cloud

VPC 이해에 필요한 네트워크 사전 지식을 먼저 짚어본다.
- VPN(Virtual Private Network)
  - 실제로 같은 네트워크 안에 있지만 논리적으로 분리하여,
    다른 네트워크에 있는 것처럼 구성하는 것이다.
  - 회사에서 모두가 같은 네트워크를 사용하고 있는 상황에서
    보안을 위해, 중요한 것들에는 통신을 분리해두고 사용하고자 할 경우에 쓰이곤 한다.
- IP 주소
  - IP 주소는 network ID와 host ID로 이루어지며,
    IP 주소의 클래스에 따라 네트워크의 크기가 달라진다.
  - host나 router 등에서 쓸 수 없는 특별한 용도의 IP 주소
    - network IP 주소
      - host ID가 0인 것.
      - 전체 네트워크에서 작은 네트워크를 식별하는 데 사용된다.
      즉, 해당 네트워크 전체를 대표하는 주소이다.
    - broadcast IP 주소
      - host ID가 255인 것.
      - 해당 네트워크에 있는 host 들에게 한 번에 데이터를 전송할 때 사용된다.
  - private IP 주소
    - 10.0.0.0 ~ 10.255.255.255 (10/8 prefix. 00001010.~)
    - 172.16.0.0 ~ 172.31.255.255 (172.16/12 prefix. 0101100.0001~)
    - 192.168.0.0 ~ 192.168.255.255 (192.168/16 prefix. 11000000.10101000.~)
- subnet
  - 하나의 큰 네트워크를 여러 개의 작은 네트워크로 분할한 것이다.
  - network ID + host ID 에서, network ID + subnet ID + host ID 로 구성된다.
    - host ID에서 할당된 bit의 일부를 subnet ID로 사용하는 것이다.
  - subnet mask
    - IP 주소에서, network ID와 host ID의 범위를 나타낸다.
      - network ID는 255, host ID는 0으로 표기한다.
      - subnet으로 인한 subnet ID를 고려하기 위함이다.
    - prefix 표기법으로, 255.255.255.0을 /24로 표기할 수도 있다.
    - 만약 subnet으로써 host ID로부터 4bit를 subnet ID로 사용한다면,
      subent mask는 255.255.255.240 혹은 /28로 표기한다. (240 = 2진수 11110000)
- router
  - 서로 다른 네트워크와 통신할 수 있게 해주는 장치이다.
    - 현재 네트워크에서 다른 네트워크로, router를 통해 packet을 전송할 수 있다.
    - router의 각 port는 서로 다른 네트워크들을 분리해두고 있다.
      - port에는, 각 네트워크의 default gateway(host ID가 1)가 할당된다.
  - routing table
    - 각 router는 routing으로, 최적의 경로를 통해
      현재 네트워크에서 다른 네트워크로 데이터를 전송하게 되는데,
      이 경로에 대한 정보는 각 router의 routing table에 저장되어 있다.
현재 사용하고 있는 각종 AWS 리소스들을, 동일한 네트워크가 아닌
논리적으로 여러 가상의 네트워크로 분리하여 구성하고,
각 네트워크에 맞는 설정을 부여하여 사용하곤 한다.
모든 AWS 리소스에 VPC를 강제하기 때문에, VPC를 별도로 설정해두지 않았다면
자동으로 default VPC에 따라 AWS 리소스들이 배치되어 있을 것이다.
각종 용어 및 개념 정리
- VPC
  - VPC를 구성하기 위한 CIDR 블록에는 private IP 주소가 쓰이며,
    net mask와 함께 prefix 표기법으로 나타낸다.
    - net mask는 /16~28 이다.
    - AWS에서 예약해 놓은 주소는 사용할 수 없다.
      (10.0.0.0/16 기준)
      - 10.0.0.0: 네트워크 주소
      - 10.0.0.1: AWS VPC 라우터 주소
      - 10.0.0.2: AWS DNS 서버 주소
      - 10.0.0.3: 예비용
      - 10.0.255.255: 브로드 캐스트 주소
      (나머지 65536-5개의 IP 주소를 host에서 사용할 수 있다.)
  - 한 번 설정된 IP 주소 대역은 변경할 수 없다.
  - 기본적으로 각 VPC는 독립적이며, 하나의 region에 종속된다.
- subnet
  - 하나의 VPC 내에서 더 많은 네트워크를 만들기 위해, 이를 쪼개는 것이다.
  - VPC보다 subnet mask는 더 커지고, IP주소 범위는 더 작아진다.
    - subnet mask 범위는 /16~28 이다.
  - subnet 내에 EC2, RDS와 같은 AWS 리소스들을 위치시킨다.
- routing table, router
  - 각 subnet의 트래픽은 router의 routing table에 따라,
    subnet 마다 정해진 경로로 전송된다.
  - VPC 네트워크 범위 내에 대한 트래픽의 목적지는 로컬이다.
  - 외부로 통하는 트래픽을 처리할 때는 Internet gateway를 사용한다.
- Internet gateway
  - VPC와 Internet을 연결해준다.
  - 어떤 subnet의 routing table에 0.0.0.0/0과 같이 정의되어 있다면,
    앞서 매칭되지 않은 모든 트래픽을 Internet gateway로 향하게 할 수 있다.
  - subnet 중, Internet gateway와 연결된 것을 public subnet,
    그렇지 않은 것을 private subnet이라 한다.
    - public subnet에 존재하는 인스턴스는 Internet에 연결되어,
      인바운드, 아웃바운드 트래픽을 주고받을 수 있다.
    - private subnet은 외부에 노출되어 있지 않아 접근할 수 없다.
- NAT gateway
  - private subnet이 외부(Internet)에서 요청되는 인바운드는 필요하지 않더라도,
    아웃바운드 트래픽은 필요할 경우가 있을 때 사용되는, 아웃바운드 인스턴스이다.
  - private subnet이 Internet과 통신해야 할 경우,
    직접적으로는 불가능하고, public subnet에 있는 인스턴스를 통해 가능하다.
    - private subnet에서 발생한 트래픽의 목적지가 VPC 내부가 아니라면,
      public subnet에 존재하는 NAT gateway로 전송한다.
    - NAT gateway는 public subnet의 routing table에 따라 트래픽을 처리함으로써,
      private subnet이 Internet과 통신할 수 있도록 한다.
    - 이처럼, private subnet의 트래픽이라고 모두 VPC 내에서만 처리되는 것이 아니다.
- VPC endpoint
  - Internet gateway 나 NAT gateway와 같은 별도의 gateway 없이
    AWS 리소스와 연결하여 통신할 수 있도록 private connection을 가능하게 해준다.
- 네트워크 ACL
  - subnet 단에서, 트래픽을 제어하기 위한 방화벽이다.
- 보안 그룹
  - 인스턴스 단에서, 트래픽을 제어하기 위한 방화벽이다.
  - EC2 인스턴스를 사용하고자 한다면,
    해당 인스턴스에서 사용하는 보안 그룹의 인바운드 규칙에
    프로토콜 유형(SSH), 포트 번호(22), public IP 주소 등을 지정해주어야,
    (PuTTY 등을 통해) SSH로 해당 인스턴스에 접속할 수 있다.

AWS SQS

Simple Queue Service

서버끼리 사용할 수 있는 메시지 큐 서비스를 제공한다.
- 메시지를 전송하는 서버 A와 이를 처리하는 서버 여럿(B, C, D ..)가 있다고 가정하자.
  1. 서버 A에서는 SQS에 메시지를 전송한다.
    이 때, 이 메시지는 SQS 여러 곳에 분산되어 같은 값으로 중복으로 저장된다.
  2. 메시지 처리를 대기 중인 여러 서버 중 B가 큐에 있는 메시지를 가져온다.
    (B가 해당 메시지를 처리하는 동안 SQS에서는 메시지가 없어지지 않고 그대로 남아있다.
    서버 B와 같은 역할을 하는 다른 서버들이 여럿 있다면 중복 처리가 일어날 수 있기에,
    이와 관련하여 timeout을 설정할 수 있다.)
  3. 서버 B에서 메시지를 처리했다면 SQS에 delete 메시지를 보내,
    SQS 여러 곳에 분산되어 있는 해당 메시지를 삭제한다.
  - 메시지를 전송하는 서버는 고정된 것이 아니므로,
    서버 B에서도 서버 A로 메시지를 보내야 하는 구조가 필요하다면
    위와 같이 구현하면 된다.
  - 메시지를 전송하는 서버도 단일한 것이 아니라, 여럿이 있을 수 있다.
- 메시지 관점에서 흐름을 살펴보며 특징을 알아보자.
  1. 최초에 메시지를 SQS로 전송할 때, delivery delay를 설정할 수 있다.
    이는 SQS로 메시지를 전송할 때, 큐에 바로 넣을지 말지에 대한 설정이다.
    sync 등의 이유로 큐에서 메시지를 바로 consume하면 안될 때 사용하곤 한다.
  2. 메시지가 SQS에 머무르는 단계에 대하여,
    그 시간(retention)과 메시지의 사이즈를 설정할 수 있다.
    최대 시간을 넘으면 메시지는 삭제된다.
  3. consuming 서버에서 SQS의 메시지를 가져가는 단계에서는
    visibility timeout, polling message count, long/short time polling을 설정할 수 있다.
    visibility timeout이란 중복 처리를 막기 위한 대기 시간 설정이다.
    다른 consuming 서버에서는 해당 시간 동안 그 메시지를 consume 할 수 없다.
    polling message count는 consuming서버에서 한 번의 요청으로 가져올 수 있는 수이다.
    long/short time polling은 consuming서버에서 consume시,
    만약 큐가 비어 있다면 얼마나 대기할 건 지에 대한 설정이다.
- DLQ(dead letter queue): 메시지를 가져갔지만 처리에 실패하여 삭제 요청이 오지 않는 등
  최대 몇 번까지 수신할 것인지에 대한 설정을 할 수 있는데,
  그마저도 결국 실패할 시 해당 메시지는 DLQ에 저장된다.
SQS 타입에는 standard와 FIFO 가 있다.
- FIFO: 선입선출을 반드시 지키며 중복 제거를 통해 중복 처리를 방지한다.
  단점으로는, 초당 300개의 메시지(전송, 수신, 삭제 합쳐서)를 처리하여 느리다. (TPS)
  순서가 중요할 때 사용한다.
- standard: 무제한적인 트랜잭션(메시지)을 처리할 수 있어 빠르다.
  단점으로는, 선입선출을 지키지않으며 중복 처리를 완전히 방지할 수 없다.
  처리량이 중요할 때 사용한다.
분산형 시스템을 구축하여 시스템 간 메시지를 주고받을 필요가 있을 때 사용하곤 한다.
- Producer(메시지를 보내는 서버)가 보낸 요청 메시지가
  반드시 바로(동기적으로) 성공/실패 여부를 알아야 하는 경우가 아닐 때,
  즉 Consumer가 메시지를 처리하고 나서 알려주는,
  비동기적인 처리로 해도 되는 구조에서 사용된다.

AWS SES

Simple Email Service

애플리케이션에서 이메일 송수신을 가능하게 해주는 서비스이다.
EC2에서는 SMTP(25번 포트)가 기본적으로 막혀있기 때문에,
이를 사용하여 문제를 해결하곤 한다.
마케팅, 주문 확인서, 뉴스 레터, 이메일 인증 등에 사용되곤 한다.
사용자 이메일 주소 혹은 도메인 자체를 인증하여 서비스를 이용한다.
시나리오는 다음과 같다.
1. 발신자(애플리케이션)는 SES에게, 수신자에게 이메일을 전송한다는 요청을 보낸다.
2. 요청이 유효하다면 SES가 이를 수락한다.
3. SES는 인터넷을 통해 수신자에게 메시지를 보낸다.
4. 결과는 다음 중 하나로 이어진다.
  - ISP가 성공적으로 수신자에게 이메일을 전송한다.
  - 수신자의 이메일 주소가 존재하지 않아, ISP는 SES에게 반송 알림을 전송한다.
  - 수신자가 해당 이메일을 수신하였으나 스팸으로 여겨, ISP에게 거부를 제기한다.
실제 서비스 상에 이용하기 위해서는 sandbox 상태를 벗어나야 한다.
그렇지 않으면 verified status인 이메일 주소에게만 전송이 가능하다.

AWS ES

Elasticsearch Service

과거에 AWS에서 elasticsearch를 open source로써 fork하여 자체 개발하여 서비스로 제공하였고,
현재는 elasticsearch 개발사가 제공하는 것과는 독립적인 형태로 서비스를 제공한다.
따라서 OpenSearch Service로 개명하여 업그레이드 및 서비스를 제공하고 있다.
- (라이센스 정책 등.. 복잡한 이야기가 있다.)
Elasticsearch와 관련하여, 클러스터를 쉽게 배포 및 운영할 수 있도록 해준다.
Elasticsearch API에 직접적인 액세스를 지원함에 따라
기존 코드 및 애플리케이션에도 충분히 원활하게 사용할 수 있다.
- 이는 다른 AWS 리소스와 연계할 수도 있다.
- 현재는 boto3와 같은 SDK를 통해 opensearch로써 더욱 간편하게 사용할 수 있다.
주로 S3, DynamoDB, RDS 등의 AWS 리소스와 함께 사용하곤 한다.

AWS CloudWatch

사용 중인 AWS 리소스에 대한 모니터링을 제공하는 서비스이다.
- 원하는 형태의 위젯으로, 각종 지표(metric)에 대한 통계(statisctics)를 확인할 수 있다.
- boto3와 같은 SDK를 통해, 이미지 파일로 추출할 수도 있다.
이벤트 및 Alarm을 이용하여, Lambda 및 SNS 등과 연계하여 사용하곤 한다.

AWS SSM

Systems Manager

AWS 리소스를 중앙에서 전체적으로 관리할 수 있는 서비스이다.
parameter store: 애플리케이션에 사용되는 환경 변수 등의 데이터를
안전하게 관리하기 위한 스토리지를 제공한다.
- 암호, DB 접속 정보, 외부 API access key 등의 데이터를 parameter 값으로 저장한다.
- 값은 일반 텍스트 또는 암호화된 데이터로 저장할 수 있으며,
  IAM을 이용하여 제한된 사용자의 접근을 제어할 수 있다.
- parameter 생성 시 지정한 고유 이름을 사용하여
  스크립트, 커맨드, 자동화 workflow 등에서 SSM parameter를 참조할 수 있다.
  (AWS CLI 등)
- parameter name은 ‘/’를 이용하여 계층적인 구조로 작성한다.
- 무료이다.
- env파일을 따로 두고 gitignore에 설정하는 방식으로 민감한 데이터를 관리해도 되지만,
  서버를 EC2 등에 배포하는 경우는 얘기가 다르다.
  remote repository에는 해당 파일이 올라가지 않아 숨길 수 있지만
  EC2에서 서버 실행하기 위해는 다시 파일을 만들어줘야 하고,
  권한이 없는 사용자가 열람하는 경우가 발생할 수도 있다. (chmod가 있긴 하지만..)
  또한, 설정이 변경됨에 따라 매번 EC2에서 해당 파일을 변경해줘야 하므로 번거로울 수 있다.
  SSM을 이용하면 이러한 상황 등과 관련하여 불편함을 줄일 수 있다.
EC2에 접근할 때, key pair를 생성하여 SSH를 통한 접속 대신, SSM을 이용할 수도 있다.
- 이를 통해, private subnet에 있는 호스트(EC2)에도 쉽게 접근할 수 있다.

AWS Cognito

AWS에서 제공하는, 웹 및 모바일 애플리케이션의 유저 인증 및 권한 부여 서비스이다.
즉, 유저를 관리할 수 있다.
유저 풀과 자격 증명 풀로 구성되어 있으며,
이 둘을 조합하거나 별개의 형태로 사용할 수 있다.
- 유저 풀: 유저의 회원 가입 혹은 로그인을 제공하기 위해 유저 정보를 저장한다.
  유저는 유저풀을 통해 웹 및 모바일 앱에 회원 가입 및 로그인할 수 있다.
  - 기본적으로 JWT 방식으로 인증한다.
  - 각종 소셜 로그인 및 MFA 등도 지원한다.
- 자격 증명 풀: 유저 풀 혹은 다른 경로로 인증에 성공한 유저에게
  임시 AWS 자격 증명을 주어, AWS 리소스에 액세스할 수 있는 권한을 부여할 수 있다.
  - IAM의 role 설정으로, 각 자격 증명에 따른 AWS 리소스 액세스 권한을 지정한다.
- 조합해서 사용할 시의 시나리오는 다음과 같다.
  1. 유저는 유저 풀을 통해 로그인하여, 인증 성공 시 유저 풀 토큰을 받는다.
  2. 애플리케이션은 자격 증명 풀을 통해 유저 풀 토큰을 AWS 자격 증명으로 교환해준다.
  3. 유저는 AWS 자격 증명을 사용하여, AWS 리소스에 액세스할 수 있다.
- 쉽게 생각하면 유저 DB와 관계 로직을 Cognito에서 대신 해주는 것이다.
  유저 풀은 인증, 자격 증명 풀은 권한 부여라고 생각할 수 있다.
serverless 애플리케이션의 유저 관리에 주로 사용하곤 한다.

AWS IAM

Identity and Access Management

AWS 리소스에 대한 액세스를 제어할 수 있는 서비스이다.
즉, AWS 리소스에 대한 인증과 권한을 담당한다.
AWS 회원 가입을 통한 최초에 생성된 사용자 계정은 root이며,
모든 AWS 리소스에 대해 액세스할 수 있다.
root에서 IAM을 통해 사용자 계정을 생성하고,
해당 사용자에 대해 AWS 리소스 액세스 권한을 설정할 수 있다.
- 로그인 자격 증명에서, 인증 시 MFA(Multi Factor Authentication)를 사용할 수도 있다.
  (모바일 디바이스를 사용하곤 한다)

AWS CLI

Command Line Interface

AWS에서 제공하는 서비스를 통합하여 관리할 수 있는 패키지 도구이다.
shell에서 명령어로 AWS 리소스와 상호작용 할 수 있게 해준다.
aws configure를 통해 자격 증명 파일을 생성할 수 있다.
- 이에 따라, 애플리케이션 서버에서 AWS를 이용할 수 있다.
  즉, shell에서 CLI를 통해 자격 증명이 되면, 권한에 따라 AWS 리소스에 접근할 수 있고
  이와 연계하여 (python을 예로 들자면 boto3 라이브러리로)
  애플리케이션 서버단에서 작성한 코드로 AWS 리소스를 이용하는 방식인 것이다.
- access key ID, Secret access key, region을 설정해야 하는데,
  이는 IAM-사용자-보안 자격 증명에서 생성할 수 있다.
  즉, 해당 계정으로 자격 증명을 하여 그에 따른 리소스 접근 권한을 갖는다.
사용을 위해 AWS CLI를 설치하고, 재부팅 해야 한다.

boto3

python으로 작성된 애플리케이션에서 AWS 리소스를 사용하고자 할 때
쉽게 사용할 수 있도록, AWS에서 SDK로써 제공해주는 라이브러리이다.
boto3를 사용할 때 필요한 AWS의 자격 증명은
함수에 매개 변수로 직접 전달하거나,
CLI에서 configure를 통해 생성된 자격 증명 파일이 있는 ~/<user_name>/.aws/에서
credentials 파일을 자동으로 탐색하게 하는 등의 방식으로 이루어진다.

newhyork

이전 포스트

Elasticsearch

다음 포스트

AWS

AWS