AWS 기타 서비스들

대규모 인프라 배포 및 관리

CloudFormation

• 리소스 자동 생성
• 대부분의 리소스를 지원한다.
• 예시
  보안 그룹이 필요하고 보안그룹을 사용항 EC2 2개가 필요하고, S3와 이 모든 머신에 로드 밸런서가 필요한 경우 CloudFormation은 이 모든 것을 자동으로 생성한다.
• 장점
  • 모든 인프라를 코드로 구축할 수 있다(IaC)
    자동으로 인프라 구성
    AWS 작동 방식을 변경할 때마다 코드 리뷰를 통해 검토
  • 비용을 절약
    - 스택 내의 각 리소스는 스택 내에서 만들어진 다른 리소스들과 비슷하게 태그될 것.
    - CloudFormation 템플릿을 사용해 리소스 비용을 쉽게 예측 가능.
    - 어떤 환경에서 오후 5시에 자동으로 모든 템플릿을 삭제하도록 해 절약 전략을 세울 수 있다.
    템플릿과 연결된 모든 리소스를 삭제한 다음 오전9시에 다시 생성하도록 할 수 있음.
  • 생산성
    - 인프라를 그때 그때마다 생성하고 지울 수 있음.
    - 템플릿을 위한 다이어그램을 만들 수 있음.
    - 선언적 프로그래밍이 된다.
    EC2에서 DynamoDB 테이블을 먼저 만들어야하는지 한 번에 만들어야하는지 알 필요가 없다.
    CloudFormation이 알아서 만든다.
  • 재사용성
    - 웹에 존재하는 기존 템플릿을 활용할 수 있다.
    - 문서 활용 가능
  • CloudFormation은 거의 모든 AWS 리소스를 지원한다.
    - 지원하지 않는 리소스는 사용자 지정 리소스라는 것을 사용할 수 있다.

CloudFormation + Application Composer

• CloudFormation 템플릿을 시각화 할 수 있다.
  이를 위해 애플리케이션 컴포저 서비스를 사용한다.

• 예시

  • WordPress CloudFormation 스택을 사용하고, 이를 애플리케이션 컴포저에서 시각화
    
    - 템플릿의 모든 리소스를 시각화할 수 있다.
    - ALB 리스너, DB 보안그룹, SQL DB, 다른 보안 그룹, LaunchConfig, 등등
    - 그리고 모든 구성 요소 간의 관계와 어떻게 연결되어 있는지 확인 가능.

• 따라서 CloudFormation은 IaC를 사용해 다른 환경, 다른 지역, 다른 AWS 계정 에서 아키텍처를 반복할 때 사용

CloudFormation 서비스 역할

• CloudFormation은 서비스 역할을 사용할 수 있다.
  • IAM 역할을 만들어 CloudFormation을 통해 사용자를 대신해 스택 리소스를 실제로 생성/업데이트/삭제할 수 있다.
• 사용자에게 스택 리소스를 실제로 생성/업데이트/삭제할 수 있는 기능을 부여하고 싶지만 리소스로 직접 작업할 권한이 없는경우 서비스 역할을 사용하면 된다.
  
  - 예를 들어 템플릿을 정의하면 사용자로써의 IAM 권한은 CloudFormation에서 작업을 수행할 수 있는 것이다.
  - 그리고 IAM Passrole이 있ek.
  - CloudFormation에 전념할 서비스 역할을 만들었다.
  - 이 서비스 역할에는 버킷을 생성/업데이트/삭제하는 등의 S3:*Bucket 권한이 있다.
  여기서는 사용자가 서비스 역할을 CloudFormation에 전달할 수 있었기 때문에 CloudFormation이 이 S3 버킷을 만들 수 있다.
• 사용 사례
  • 최소 권한 원칙을 달성하고 사용자에게 스택 리소스를 만들 수 있는 모든 권한을 부여하고 싶지 않고 CloudFormation에서 서비스 역할을 호출할 수 있는 권한만 부여하고 싶은 경우
• 이 작업을 수행하려면 사용자에게 AWS에서 특정 서비스에 역할을 부여하는 데 필요한 권한인 IAM Passrole 권한이 있어야 한다.
• CloudFormation에 역할을 부여하면 내 개인 권한을 사용하지않고 부여한 권한 내에서 사용한다.
  
  
  

Amazon Simple Email Service(Amazon SES)

• 이메일을 전 세계로 대규모로 안전하게 보낼 수 있는 서비스
  애플리케이션이 SES API 또는 SMTP 서버를 사용하면 Amazon SES가 사용자들에게 대량으로 이메일을 보낸다.
• 아웃바운드 뿐 아니라 인바운드 이메일도 허용해 답장을 주고 받을 수 있다.
• 이메일을 열었는지 여부를 알려주는 평판 대시보드와 성과 인사이트, 스팸 방지 피드백을 제공한다.
  사람들이 이메일을 스팸으로 평가했는지 알 수 있음.
• 이메일 통계 제공
  배달, 반송, 피드백 루프 결과, 이메일을 열었는지 여부
• 이메일 전송에 대한 최신 보안 기준을 지원
  DKIM(DomainKeys Identified Mail)과 SPF(Sender Policy Framework) 기능이 있다.
• 유연한 배포
  공용 IP, 사설 IP, 고객 소유 IP등, 특정 IP주소에서 이메일을 보냄
• AWS API또는 SMTP 프로토콜에서 콘솔로 액세스 가능
• 사용 사례
  이메일 트랜잭션, 마케팅 이메일, 대량 이메일 커뮤니케이션

Amazon Pinpoint

• Amazon Pinpoint: 확장 가능한 양방향 인바운드/아웃바운드 마케팅 커뮤니케이션 서비스
• Pinpoint를 통해 이메일,SMS, 푸시 알림, 음성, 인앱 메시지를 보낼 수 있다.
• 사용 사례: SMS, 마케팅 이메일을 대량으로 보내기, 트랜잭션 SMS 메시지를 전송해 캠페인 실행
  
• 고객에게 적합한 콘텐츠로 메시지를 세분화하고 개인화할 수 있다.
  그룹이나 세그먼트 등을 만들 수 있음.
• 답장을 받을 수도 있다.
• 하루에 수십억 개의 메시지를 보낼 수도 있다.
• 이메일에 누군가 응답하거나 성공하면 TEXT_SUCCECC, TEXT_DELIVERED, REPLIED와 같은 모든 이벤트가 SNS, Kinesis Data Firehose, CloudWatch Logs로 전달된다.
  즉, Pinpoint로 모든 종류의 자동화를 쉽게 구축할 수 있다.
• Pinpoint VS SNS,SES
  • SNS와 SES에서는 각 메시지의 대상, 내용, 전달 일정을 관리해야한다.
  • PinPoint에서는 직접 메시지 템플릿, 전달 일정, 대상 세그먼트, 전체 캠페인 등을 만들지 않고 Pinpoint로 관리할 수 있다.
• 완전한 마케팅 커뮤니케이션 서비스를 하고 싶다면 SNS및SES의 차세대 제품인 Pinpoint가 적합하다.

Systems Manager - SSM Session Manager

• SSM 세션 관리자로 EC2와 온프레미스 서버에서 보안 셸을 시작할 수 있다.
• SSH 액세스, bastion 호스트, SSH 키가 필요없게 된다.
  즉, EC2 22포트가 필요없음.
  
  - EC2 인스턴스에 SSM 에이전트가 있고, 그 에이전트는 세션 관리자 서비스에 연결된다.
  - 즉, 사용자는 세션 관리자 서비스를 통해 EC2 인스턴스에 액세스할 수 있다.
• Linux, MacOS, Windows를 지원한다.
• 로그 데이터를 S3, CloudWatch Logs로 안전하게 보낼 수 있다.

System Manager - Run Command

• 문서를 실행하는데 사용된다.
  스크립트이거나 명령 하나이다.
• 리소스 그룹을 사용하는 여러 인스턴스에서 실행된다.
  시스템 관리자 서비스에 등록된 EC2 또는 온프레미스 서버들에서 실행
• 이 명령들을 실행할 때는 SSH가 필요없다.
  세션 관리자에서의 메커니즘을 사용하기 때문 - 에이전트를 이용
• 실행 명령으로 실행된 명령의 결과는 모두 S3나 CloudWatch Logs로 보내진다.
• 실패가 일어나면 SNS로 전송된다.
  진행중/성공/실패 등 모든 업데이트를 SNS로 보낼 수 있다.
• 보안을 위해 IAM과 완벽하게 통합된다.
• 그리고 CloudTrail에서 누가 어떤 명령을 실행하는지 확인할 수 있다.
• EventBridge로 실행명령을 직접 실행할 수 있다.
  
  - EC2 또는 온프레미스 서버가 있고, SSM 에이전트로 세션 관리자의 명령 실행 기능을 통해 간단하게 명령을 실행할 수 있다.
  - 출력 결과는 S3 또는 CloudWatch 로그로 전송할 수 있다.
  - 모든 상태 알림은 SNS로 전송된다.
  - 사용자가 트리거하거나 EventBridge로 자동으로 트리거할 수 있다.

System Manager - Patch Manager

• 인스턴스 관리 과정 패칭을 자동화하는 데 사용된다.
  OS, 애플리케이션 업데이트, 보안 업데이트를 적용하는 데 사용된다.
• EC2와 온프레미스 서버도 지원한다.
  Linux, Mac, Windows 지원
• 필요에 따라 즉시 패치할 수 있고 또는 유지 관리 기간을 사용해 패치 일정을 잡을 수 있다.
• 패치 관리자 내에서도 인스턴스를 스캔해 패치 규정 준수 보고서를 생성할 수 있다.
  모든 인스턴스가 올바르게 패치되었는지 확인하고 패치가 누락된 사람이나 경우가 있는지 찾을 수 있음.
  
  - 콘솔이나 SDK 또는 유지 관리 기간에서 패치 관리자를 호출할 수 있다.
  이를 AWS-RunBatchBaseline 실행명령이라 한다.
  - 그러면 모든 EC2 인스턴스를 패치한다.
  패치 관리자 내에서 보고서를 찾을 수 있다.

System Manager - Maintenance Windows(유지 관리 기간)

• 인스턴스에서 작업을 수행할 일정을 정의하는 데 사용
  OS 패치, 드라이버 업데이트, 소프트웨어 설치 등 원하는 작업을 수행하기 위해 유지 관리 기간을 정의할 수 있다.
• 유지 관리 기간 정의
  • 일정: 언제 트리거 될지 정의
  • 기간
  • 적용할 인스턴스 지정
  • 적용할 작업 지정
    
    - 24시간마다 트리거
    명령 실행이든 EC2 업데이트든 패치 작업이든 무엇이든 자유롭게 설정

System Manager - Automation(자동화)

• EC2 또는 기타 AWS 리소스에서의 명령 유지 관리 및 배포 작업을 단순화하는 데 사용
• 예시
  자동화를 사용하면 인스턴스들을 한 번에 다시 시작할 수 있다.
  AMI를 생성하거나 EBS 스냅샷을 생성하는 작업 가능
• 자동화 런북
  • EC2 또는 AWS 리소스에 동일한 문서로 표시된 미리 정의된 작업
    
    • 이 런북은 SSM 자동화에서 사용된다.
    • EC2에서 특정 작업을 실행한다.
      예를 들어 모두 재시작 같은 작업
      또는 AWS 리소스에서 작업을 실행할 때 사용(RDS DB의 스냅샷 생성)
• 콘솔, SDK 및 CLI, EventBridge, 유지 관리 기간, AWS config를 사용해 트리거 될 수 있다.
  통합 가능
  - 예를 들어 config에서 리소스가 준수되지 않은 것을 알게 된 경우 SSM 자동화를 실행하기 위해 자동으로 수정 조치를 취할 수 있다.
  --> 비준수 리소스를 수정하는 것

Cost Explorer(비용 탐색기)

• AWS 비용 및 시간에 따른 사용량을 시각화하고 관리
• 사용자 정의보고서를 생성해 비용과 사용량 데이터를 분석
  대시보드, 도면도 얻을 수 있음.
• 전체 계정 간 총비용 및 사용량 같은 전체적인 데이터를 분석
• 매달, 매시간, 리소스 레벨의 세부 단위로 비용을 볼 수 있음.
• 비용을 낮추기 위한 최적의 절감형 플랜을 선택할 수 있음
• 향후 12개월까지 사용량을 예측 가능

예시

• AWS 서비스의 월별 비용
  
• 시간별 리소스 레벨
  
• 비용 탐색기로 절감형 플랜 찾기
  
  - 절감형 플랜은 예약 인스턴스의 대안
  - 비용 탐색기를 사용해 사용량에 따라 어떤 절감형 플랜을 선택할 수 있는지 알려준다.
  - 추천 플랜, 예상 월별 지출 제공
• 사용량 예측
  
  - 과거 지출했던 비용을 기반으로 예측

비용 이상 탐지 서비스

• 비용 및 사용량 데이터를 지속적으로 모니터링
• 기계학습을 사용해 비정상적인 범위를 감지
• 일회성 비용 급증, 지속적인 비용 증가를 감지
• AWS 서비스, 회원 계정, 비용 할당 태그 및 비용 범주를 모니터링하고 계정에서 발생하는 문제에 대한 근본 원인 분석이 포함된 이상 탐지 보고서를 보내준다.
• 개별 알림이나 SNS를 활용한 일간 또는 주간 요약을 통해 알림을 받을 수 있다.
• 요약
  - 기계학습을 사용해 비용을 확인
  - 알림을 받고 근본 원인을 빠르게 분석
  - 모두 AWS 비용 이상 탐지 서비스를 사용한다.

AWS Batch

• 완전 관리형 배치 처리 서비스
  어떤 규모의 배치라도 처리할 수 있다.
• Batch 서비스를 사용하면 AWS에서 수십만 개의 컴퓨팅 배치 작업을 매우 쉽고 효율적으로 실행할 수 있다.
• 배치 작업이란?
  - 시작과 끝이 있는 작업
  - 연속적인, 끝나지 않는 스트리밍 작업은 항상 실행 중이다.
  - 배치 작업은 반대이다.
  예를 들어 오전 1시에 시작해 오전 3시에 끝난다.
• 배치 작업에는 시작 시점이 있다.
  따라서 Batch 서비스는 배치 작업을 로드하기 위해 동적으로 EC2 또는 스팟 인스턴스를 시작한다.
• Batch는 배치 대기열을 처리할 수 있도록 적절한 양의 컴퓨팅 및 메모리를 프로비저닝한다.
• 배치 작업을 배치 대기열에 올리거나 예약하기만하면, Batch 서비스가 나머지 작업을 수행한다.
• 배치 작업 정의
  • 도커 이미지와 ECS 서비스에서 실행되는 작업 정의이다.
    즉, ECS에서 실행될 수 있는 것이라면 배치에서도 실행될 수 있다.
• Batch를 사용해 배치 작업을 실행하면 매우 좋다.
  작업에 필요한 EC2 인스턴스 또는 스팟 인스턴스의 적절한 수를 자동으로 조정해주기 때문이다.
  그래서 비용이 최적화되고 인프라에 덜 신경써도된다.

Batch 간단한 예시

- 사용자가 S3에 넣은 이미지를 배치 방식으로 처리하고 싶다
- 이미지가 S3에 입력되면 배치 작업이 트리거 된다.
- Batch는 자동으로 EC2 또는 스팟 인스턴스로 구성된 ECS 클러스터를 갖게 되고
- Batch는 배치 대기열에 있는 배치 작업을 수행할 수 있는 인스턴스가 있는지 확인한다.
- 그리고 인스턴스는 작업을 수행할 도커 이미지를 실행한다.
- 작업은 처리된 객체를 삽입하는 일이거나 이미지를 다른 S3 버킷으로 넣는 필터일 수도 있다.

Batch VS Lambda

• Lambda
  • 시간 제한이 있다(15분)
  • 프로그래밍 언어 몇 개로만 액세스할 수 있다.
  • 작업을 실행하는 임시 디스크 공간이 제한되어 있다.
  • 서버리스
• Batch
  • 시간 제한이 없다
  • 도커 이미지로 패키징하는 한, 런타임의 길이는 상관없다.
  • 스토리지는 EC2와 같이 제공되는 스토리지를 사용하면 된다.
    EBS볼륨이 될 수도 있고 디스크 공간을 위한 EC2 인스턴스 스토어일 수도 있다.
    Lambda 보다 훨씬 더 많을 수 있다.
  • 서버리스가 아닌 관리형 서비스(만들어지는 실제 EC2에 의존)
    이 EC2는 AWS가 관리하므로 오토 스케일링 등에 대해 신경쓸 필요가 없다.

Amazon AppFlow

• SaaS 애플리케이션 및 AWS 사이에 데이터를 전송할 수 있는 완전 관리형 통합 서비스
• 데이터 소스: Salesforce, SAP, Zendesk, Slack, ServiceNow
• 데이터 목적지: S3, Redshift, Snowflake, Saleforce와 같이 AWS가 아닌 곳으로도 데이터를 보낼 수 있다.
• 빈도: 일정에 따라 또는 특정 이벤트에 대한 응답으로 또는 주문형으로 통합되도록 정의 가능.
• AppFlow 내에서 필터링, 유효성 검사와 같은 데이터 변환도 할 수 있다.
• 암호화: 데이터는 공용 인터넷을 통해 암호화되거나, PrivateLink를 사용해 비공개로 전송할 수 있다.
• AppFlow를 사용하면 통합을 만드는 데 시간을 쓰지 않아도 된다.

AWS Amplify - 웹과 모바일 애플리케이션

• 간단히 말해 웹 및 모바일 애플리케이션 개발 도구이다.
• Amplify를 사용하면 AWS의 많은 스택을 한 곳에 통합해서 웹 및 모바일 애플리케이션을 빌드할 수 있다.
  
  - 개발자가 있고 백엔드를 만들려고 한다
  - Amplify CLI를 사용해 Amplify 백엔드를 만든다.
  - 그리고 이 백엔드는 많은 AWS 리소스를 내부적으로 사용할 것이다.
  - 데이터 저장을 위해 S3를 사용하고 신원 증명을 위해 Cognito를 사용하고 API에 AppSync를 사용하고 API Gateway도 사용한다. 추가로 SageMaker,Lex,Lambda, DynamoDB등 사용하고 싶은 리소스를 사용
• Amplify로 한 곳에서 인증, 스토리지 REST API나 GraphQL API 등의 API CICD, PubSub, Analytics, AI/ML 예측, 모니터링 등을 설정할 수 있다.
• 그리고 코드를 연결
  출처는 모든 곳이 될 수 있다.(GitHub, AWS CodeCommit, Bitbucket, GitLab 등) + 직접 코드를 업로드할 수도 있다.
• 이 모든 백엔드 서비스를 Amplify 안에서 직접 통합한다.
• 그리고 Amplify 프론트엔드 라이브러리를 추가해서 우리의 Amplify 백엔드에 연결한다.
• 웹이나 모바일 애플리케이션 용으로 많은 프론트엔드 라이브러리가 있고, 프레임워크도 많다.
• 마지막으로 Amplify 콘솔을 이용해 Amplify 자체에 배포하거나 Amazon CloudFront에 배포해 애플리케이션 제공
• Amplify를 웹 및 모바일 애플리케이션을 위한 Elastic Beanstalk라 생각하면 된다.
• Amplify를 사용하면 AWS의 모든 것들을 하나의 장소로 통합해 개발자가 웹과 모바일 애플리케이션을 만들기 위한 원스톱 쇼핑몰이 된다는 것만 알자.