AWS Cloud Service 종류

2SEONGA·2025년 2월 19일
awscloud

AWS

목록 보기
4/6
post-thumbnail

이 외에 더 많은 서비스들이 존재하지만, 학습한 내용만 다루고 있습니다.

1. AWS RDS / DynamoDB : 관계형 / 비관계형 데이터베이스

공동 책임 모델 내 AWS 가 데이터베이스들을 간편한게 사용할 수 있도록 관리

  • Quick Provisioning 빠른 프로비저닝
  • High Availability 높은 가용성
  • Vertical / Horizontal Scaling 수직 / 수평적 확장
  • Automated Backup & Restore, Operations, Upgrade 자동 백업 및 복원, 운영, 업그레이드
  • Monitoring, Alerting 모니터링 및 경고

관계형 데이터베이스 (SQL) : RDS

  • PostgresQL(PQL, PSQL), MySQL, MSSQL 등
    • 금융권이나 만들어진지 오래된 레거시 서비스 = Oracle 사용
    • 오래되긴했는데 적당히 나이든 서비스 = MSSQL(Microsoft SQL Server) 사용
    • 사이드 프로젝트나 스타트업 서비스 = MySQL 혹은 PostgresQL(PQL) 사용

Q. "EC2에 데이터베이스(정확히는 DBMS)를 설치하여 사용하면되는데, 굳이 RDS 를 사용하는 이유는?"
A. RDS = “Managed” Service 로, 아래와 같은 관리 제공
1. DBMS 버전 패치
2. 백업 (시간 단위, 개발자가 개별 정의 가능) : 정적 복사 - 파일로 되어있어 복구 시 리드타임 발생
3. Replica (Master / Read) : 동적 복사 - DB로 되어있어 복구 시 리드타임 사실상 0 (트래픽 전환)
4. Scaling Capability (Vertical / Horizontal) : 수직적 / 수평적 확장성

추가 : 비관계형 데이터베이스 (NoSQL)

웹 2.0 과 빅데이터 시대에 데이터 저장을 위한 관계형 데이터베이스의 대안

  • 빅데이터 특성에 따른 무한 확장 가능한 DB 필요
    1. 비정형성 : 복잡한 데이터 구조 저장 가능, 불확실성 높은 데이터 우선 쌓고보자 → Schemaless
      • 웹 2.0 JSON, XML 포맷 및 빅데이터 등장으로 복잡한 데이터 형태 저장 필요
        • Flexibility
    2. 대용량 : 방대한 트래픽 및 데이터양의 처리 → 수평적 확장에 유리한 분산 저장 및 효율적 쿼리
      • 며칠 안에 수 TB가 쌓이는 상황에서 수직적 확장 시, 매번 인스턴스 교체 필요
        • Scailability
        • High-Performance
        • Highly Functional
  • 가장 쉽게 접할 수 있는 NoSQL → JSON
    • 데이터가 중첩됨 = 관계형 데이터베이스와 달리 관계가 중첩으로 표현됨

2. AWS Route53 : DNS 설정

GoDaddy, Namecheap, Gabia 와 같은 Domain Registar 로써 도메인 구매 및 등록 가능

  • Routing Policies : Weighted 적용 시 유사 Load Balancing 혹은 A/B 테스팅 가능
    • Simple Routing Policy (No Health Check)
    • Weighted Routing Policy : hello.aaron.com → A(70%) + B(20%) + C(10%)
    • Latency Routing Policy : 여러 리전에 서버들이 분산되어있을 때의 Load Balancing
    • Failover Routing Policy (Disaster Recovery)

도메인 구매 과정 : Domain Registry 와 Domain Registar

  • ICANN : Root Server 관리
  • Domain Registry : TLD Server 관리 (.com, .net 등) (ICANN 이 TLD 관리를 위임)
    • ex ) VeriSign
  • Domain Registrar : NS (Name Server) 관리 즉, 실제 우리가 구매, 등록하는 모든 DNS 서비스 제공
    • ex ) GoDaddy, NameCheap, Gabia 등
    • Record : 다양한 타입의 Record 중 자주 접할 6가지
      • A Record : DOMAIN NAME → IP SERVER
        (a.bootsrap.io → 1.0.0.1)
        • CNAME : DOMAIN NAME → DOMAIN NAME
          (b.bootsrap.io → a.bootsrap.io)
          - Record TTL(Time To Live) : DNS Resolver 가 얼마동안 캐싱하고있을 지
          → 길면 트래픽 감소
        • NS : DOMAIN NAME → NAME SERVERS
          (bootsrap.io → ns.a.net / ns.b.net / ns.c.net..)
        • MX : MAIN DOMAIN NAME → MAIL SERVER
          (@c.bootsrap.io → mail.nv.server)
  • 실제 사례
    bootstrap.io 도메인을 구매했다면, 다양한 파생 도메인들을 등록 가능
    우리가 사용하는 서버의 IP 와 도메인과 연결하려면..
  1. 먼저 서버의 IP 와 도메인과 연결해주는 플랫폼에 들어가서 도메인 구매
  2. 그 후 플랫폼 웹 페이지에서 서버의 IP 와 도메인과 연결하면
  3. 플랫폼 뒷단의 백엔드에서 자신들의 NS 에 서버의 IP — 도메인 연결 등록

    AWS EC2 서버의 IP 라고 AWS Route53 에서 등록할 필요는 없다!
    NS 에 기록만 하는 것,
    AWS EC2 서버의 공인 IP 값만 가져와 카페24 NS 에 등록가능

  • Domain Reseller : Domain Registrar 의 DNS 관리를 대신해주면서 돈버는 곳, 웹 호스팅 등을 제공
    • ex ) 카페24

Route53 실무 사용 시 레코드 유형

  • NS (Name Server) | bootstrap.codes
    → 일반적으로 4개 정도의 Authoritative Name Server 기입
    • Authoritative 본연의 기능만 가지고 있는, 네임서버는 질의 응답 시 AA(Authoritative Answer) 설정
  • SOA (Start of Authority) | bootstrap.codes
    → 도메인에 관련된 중요한 정보 저장
    • 관리자 이메일 주소, 도메인이 마지막으로 업데이트된 시간, 새로고침 사이 서버가 대기해야 하는 시간 등

기본 정보

필드 이름값
이름example.com
레코드 유형SOA
MNAMEns.primaryserver.com
RNAMEadmin.example.com

여기서 'RNAME' 값은 관리자의 이메일 주소를 나타내며
admin.example.com이 admin@example.com과 동일

시간 설정

필드 이름값
일련1111111111
새로 고침86400
재시도7200
만료40000000
TTL11200
  • CNAME | staging.bootstrap.codes
    → ELB 에 연결 = ELB 에 도메인 설정
    • 나머지 CNAME 들은 AWS Certificate Manager 를 통한 HTTPS 인증서 적용을 위한 검증 서버 연결

3. AWS S3 : 정적 데이터 저장

Nginx(WS) 와 유사하게 정적 데이터(HTML/CSS/JS, 이미지, 영상, 폰트 등) 제공

  • Infinite Scailing
  • → Nginx(WS) 와 유사하게 정적 웹 사이트 호스팅(Static Website Hosting) 가능
    • Application Hosting
    • React 와 같은 SPA (번들된 파일 집합 - HTML/CSS/JS)
    • 정말 많은 웹 사이트들이 S3 를 Backbone (핵심 네트워크) 으로 사용
  • Media Hosting 도 가능 = 이미지, 영상 등
  • Software Delivery : 개발한 코드(JAVA) 혹은 개발한 코드를 기반으로 빌드한 산출물(JAR, WAR)

S3 장점

  • 용량은 가용적으로 늘어나 무제한으로 사용 가능 + 직접적인 스케일링 작업 불필요
  • S3 내 저장된 파일들의 업로드 혹은 삭제와 같은 작업을 HTTP / HTTPS 를 통해 관리 가능
  • EC2 의 스토리지(EBS)를 사용하여 데이터를 저장하는 것보다 비용이 월등히 저렴
  • Versioning 제공, Backup 혹은 문제가 발생했을 때의 Recovery 솔루션까지 제공

S3 구성

  • Bucket : Object 담는 바구니 - 리전 서비스(서울, 도쿄 등)
    → 지역성 이슈로 CDN 사실상 반필수
  • Object : s3://my-bucket/folder1/folder2/hello.txt
    • 디렉토리 구조로 객체들이 저장되는 것처럼 보이겠지만, 실제로 UX 도 그렇게 표기하지만 단지 Trick
      • /folder1/folder2 : Prefix
      • /hello.txt : Object name

S3 접근 권한 보안

  • User-based = IAM Policies
    : 어느 누가 접근을 시도하는지 기반으로
  • Resource-based = Bucket Policies or Bucket/Object ACL
    : 어디에 접근을 시도하는지 기반으로

    JSON 기반의 정책 설정

    • Resources : Bucket 혹은 Object
    • Effect : 허용 ALLOW / 거절 DENY
    • Action : 어떤 작업들에 대해
    • Principle : 본 정책을 적용하고자하는 자원 혹은 IAM 계정

    기본적으로 Public Reads 열어주어야지 외부에서 접근 가능
    그렇지 않으면 403 Forbidden 에러

Pre-Signed URL

백엔드가 이미지를 S3 에 전송 X → 프론트엔드가 이미지를 S3 에 전송
즉, 인증 정보 없이 업로드 가능

4. AWS CloudFront : CDN 설정

CDN = Content Delivery Network

: 웹사이트의 컨텐츠들을 캐싱하여 읽기 성능을 향상

"CDN 적용 목적 = 캐시"
: 지역성(엣지 로케이션을 통해), 속도, S3 혹은 EC2(서버) 부하 감소

  • 콘텐츠가 이미 지연 시간이 가장 낮은 엣지 로케이션에 있는 경우,
    CloudFront가 콘텐츠를 즉시 제공

  • 콘텐츠가 엣지 로케이션에 없는 경우,
    콘텐츠의 최종 버전에 대한 소스로 지정된 오리진(Amazon S3 버킷, MediaPackage 채널, HTTP 서버(예: 웹 서버) 등)에서 콘텐츠를 검색

  • S3-CloudFront 사용 시 장점

  1. 웹사이트 로딩 속도 개선
  2. 대역폭 사용 비용 절감
  3. 컨텐츠 제공의 안정성
  4. 웹사이트 보안
  • S3-CORS 보안 헤더도 캐싱 가능
    : Method 제어 GET, HEAD + Origin 제어

Edge (Location)

전 세계에 분포되어있는 캐시 서버를 지칭하는 용어

Origins

  1. S3 Bucket
    • OAC (Origin Access Control 최신버전) / OAI (Origin Access Identity 구버전)
      • [S3 에 대한 CloudFront 레벨에서의 접근제한 (IAM과 유사)
        • S3 에 대한 유저의 퍼블릭 엑세스를 모두 닫고, CloudFront 로만 Private 엑세스로 접근가능
        • S3 버킷 노출을 방지하고, HTTPS, WAF 나 AWS Shield 통해 DDoS 방어 등 추가 보안적용
          • S3 버킷 노출 시 Brutal Force 를 통해 S3 버킷 내 어떤 객체들이 있는지 모두 조회 가능
          • S3 버킷명은 전세계적으로 유일한 값을 가져, 객체 추론뿐만 아니라 DDoS 공격 등에 취약
    • S3 자체적으로 CORS 와 유사하게 Referral 로 방어 가능하나, 궁극적으론 버킷을 가리는 게 이상적
  • CloudFront 를 S3 에 자원 업로드를 위한 중간 서버와 같은 Ingress 로도 활용 가능
    • Ingress : 외부로부터 서버 내부로 유입되는 네트워크 트래픽을 처리하는 것
  1. HTTP (EC2 과 같은 웹 서버 혹은 WAS)

CloudFront Functions (과거에는 AWS Lambda 를 연결하여 사용)

  • CDN 캐시 조회 시(HIT) 혹은 실패 시(MISS) S3 접근할 때,
    수행할 Middleware 격 함수 정의 가능
    • 과거 : AWS Lambda 로 생성하여 직접 연결
    • 현재 : 간편하게 CloudFront 자체 함수 정의 가능
      • ex ) 기술 블로그 자체 배포 시 글마다 .html 붙어 저장
        • 웹 브라우저에서 접근 시 .html 없이 접근하게 되는데
        • CloudFront 함수를 통해 웹 브라우저에서 해당 리소스에 접근 시 붙는.html

5. AWS CloudFormation / Terraform 비교 : Infrastructure as Code(IaC)

Infrastructure as Code(IaC)

  • 인프라 설정 시 처음하는 사람이든, 오랜 기간동안 해온 경력자든
    • 인프라 자원이 너무 많아서 잘못만드는 실수가 발생하기 마련,
    • 잘못만들었다가 다시 지우고 만들면 비용 문제가 발생,
    • 예전에 만들었던 인프라 자원이 더 이상 사용되지 않은 좀비로 남아있게 되는 경우 등의 문제가 발생
  • 이런 인프라 설정을 스크립트(코드)로 관리하게 된다면 생산성이 굉장히 높아진다.
    • 실수를 방지할 수 있고,
    • 잘못만들어도 다시 만드는 데에 시간이 적게 걸리고,
    • 더 이상 사용되지 않는 것으로 판단되는 코드는 지워버리면 끝
  • + 클라우드 인프라는 사실 하나하나 거의 다 돈이기에 태그를 통해 추정도 가능, 깔끔한 상태로 유지 가능
  • Savings Strategy :
    • 개발존 인프라의 경우 개발자들이 굉장히 많은 인프라 생성 실험과 학습을 하기에 좀비 인프라도 다수 존재
    • 오후 5시에 모든 인프라를 템플릿(코드) 기준으로 삭제 후 오전 8시에 다시 새로 띄우는것도 가능
      • 15시간동안 굉장히 많은 양의 돈을 절약 가능

1. CloudFormation (CF 혹은 CFn)

명령형이 아닌 선언적 방식 = What
어떤 구성이 되어야하는지만 스크립트를 통해 명시하면 → 그대로 설정

  • 다음과 같이 스크립트에 명시하면 아래 내용대로 그대로 인프라를 설정
    • SG (Security Group) 은 어떻게 구성할 것인지 선언
    • 앞서 만든 SG 내부에 2개의 EC2 를 생성하고싶다고 선언
    • S3 도 필요하니까 사용하겠다고 선언
    • 앞서 만든 EC2 에다가 ELB(ALB) 배치하겠다고 선언

2. Terraform

마찬가지로 명령형이 아닌 선언적 방식으로 인프라를 설정하는 Infrastructure as Code(IaC)

  • CF 와 똑같이 스크립트에 인프라 관련 내용들을 명시하면 그대로 인프라를 설정
  • CF 보다 압도적인 성능과 벤더 독립성 그리고 수정 용이성 덕분에 더 많이 활용

수정 용이성에 있어, 변경 사항 적용 시 →

  • CF : 변경된 부분만을 수정하기가 어려워서 전체 템플릿 재배포
  • Terraform : 변경된 부분만을 업데이트하고 기존 리소스 다시 생성하지 않고도 인프라 업데이트 가능

6. AWS Elastic Beanstalk : CI/CD 자동화

WAS 배포 시 전형적인 AWS 아키텍쳐 : 3-Tier 아키텍쳐

  1. 유저는 여러 가용영역을 커버할 수 있는 Multi AZ - ELB 에 요청
  2. ELB 는 Auto Scaling Group(ASG) 에서 관리하는 여러 Multi AZ 에 위치한 EC2 에 요청 전달
  3. 각 EC2 는 RDS DBMS 로부터 데이터에 대한 CRUD 처리
    • Aurora, DynamoDB 사용도 가능, ElasticCache 통해 세션 관리도 가능

[ 사진 출처 : AWS Workshop Studio > AWS Three Tier Web Architecture ]

  • 이 모든 인프라를 앞서 배운 CloudFormation 을 활용하여 구축할 수 있지만 사실 귀찮기도하고
    • 처음 개발을 배우고 배포까지 하려는 개발자들에겐 장애물
    • 일반적인 (인프라에 익숙치 않은) 개발자들의 관심사는 단순히 “내가 만든 앱을 배포하고싶다!” 일 뿐
      • 다양한 애플리케이션과 환경 속에서도 “내가 열심히 만든 앱이 구동되길 바래!”

Elastic Beanstalk

: 앱만 전달해주면 배포의 모든 것은 제가 알아서 할게요!

어플리케이션 배포에 대한 개발자 중심적인 관심사를 제공
= 배포에 필요한 모든 것들을 추상화

  • EC2, ASG, ALB, RDS 모두 개발자가 쉽게 설정할 수 있도록 돕는 역할
  • 그래서 Elastic Beanstalk 은 PaaS = Platform as a Service
    • 인스턴스, OS 구성을 자기가 알아서 해주고, 배포 전략을 설정하면 알아서 배포까지
    • Capacity Provisioning, Load Balancing & Auto-scaling 등
  • 일관된 환경과 상태를 계속해서 유지

    개발한 새로운 버전의 어플리케이션 코드(Create Application)를 업로드하는 것만(Upload Version)으로
    새로운 환경(Manage Environment)에 배포하는 것(Deploy New Version)이 가능한 흐름

Elastic Beanstalk 과 ECS 는 어떤 차이?

  • Elastic Beanstalk = PaaS (Platform as a Service)
  • ECS(Elastic Container Service) = CaaS (Container as a Service)

회색 : 제공되는 부분 | 주황색 : 사용자(개발자)가 커스터마이즈 가능한 부분

  • AWS Lambda 에는 Application 만 얹으면 바로 실행
  • AWS Elastic Beanstalk 에는 Application 와 Data
  • AWS ECS 는 EC2 및 OS 선택이 이미 된 상태로 Middleware + Runtime 설정 뒤 Application 수행
    • 앞서 배웠지만 ECS 는 번거롭게 서브넷이라던가 SG 라던가 개별 생성과 설정이 필요
  • AWS EC2 는 AWS AMI 통해 OS 를 선택한 다음 Middleware + Runtime 설정 뒤 Application 수행

3개 종류의 아키텍쳐

  • Single Instance Deployment : 운영존에는 ELB 가 필요한데 개발존에는 사실상 필요없으니까
  • ASG + LB(Load Balancer) : Production 운영존 혹은 Pre-production 스테이징존에 적합
  • ASG Only : 데이터베이스에 대한 특별한 배치성 작업이나 주기적 이메일 전송과 같은 Worker 에 적합
    • Non-web App Worker 라고 부르는 듯

Elastic Beanstalk 는 Docker 도 구동 가능

Docker 를 위해서 꼭 ECS 를 써야한다는 강박을 갖지 않아도 된다는 뜻

  • Single Container Docker
  • Multi-Container Docker
  • Preconfigured Docker

Multi-Container Docker 형태로 Elastic Beanstalk 사용 시 구성도

  • 오토스케일링을 통해 트래픽이 초과하면 동일한 환경구성이 계속해서 복사되는 방식으로 인스턴스 확장
  • 쉬운 배포라는 측면에서 매우 좋지만 여러 종류의 컨테이너들을 클러스터 단위로 관리하고 배포하기엔 부적합
    • 아래서 ECS (Elastic Container Service)를 사용하면 가능 = 클러스터 단위의 컨테이너 배포

모니터링 측면에서 두각

Elastic Beanstalk 이 알아서 CloudWatch 위한 Agent 를 EC2 에 설치한 뒤 CloudWatch 로 상태 전송

  • Monitoring, Overview : 다양한 매트릭 제공(Response Time, Network In/Out, CPU Utilization 등)
  • Recent Event : 배포 시 서버 상태확인에 유용

7. AWS CodePipeline = CI/CD = CodeCommit → CodeBuild → CodeDeploy

CodePipeline = CI/CD = CodeCommit + CodeBuild + CodeDeploy

CodeCommit → CodeBuild → CodeDeploy 전 과정에 대한 오케스트레이션

  • (Code 개발 → Test 테스트) ⇒ (Test 테스트 → Build 빌드) ⇒ (Provision 배포 준비 → Deploy 배포)
    • CI, Continuous Integration
      • CodeCommit = (Code 개발 → Test 테스트)
      • CodeBuild = (Test 테스트 → Build 빌드) - 테스트를 어느 시점에 할지는 마음대로
    • CD, Continuous Deployment or Delivery
      • CodeDeploy = (Provision 배포 준비 → Deploy 배포)

  • 3개 요소들의 Pipeline 만이 아닌 Elastic Beanstalk 이나 CloudFormation, Github 등도 설정 가능

1. CodeCommit : AWS 의 Github Repository 라고 생각하기

굳이 Github 대신에 CodeCommit 을 사용하는 이유라면

  • 계정 안에 저장되기때문에 외부 유출이 불가능하다는 점에서 보안적인 측면에서는 강한 장점
  • 그 외의 특성은 Github 과 사실상 동일

2. CodeBuild : AWS 의 Github Actions 혹은 Jenkins 라고 생각하기

굳이 Github Actions 나 Jenkins 대신에 CodeBuild 을 사용하는 이유라면

  • AWS 서비스이기에 CI/CD 파이프라인 구축과 기술적 결합성을 극한으로 끌어올리기 가능
  • 그 외의 특성은 Github Actions 와 사실상 동일한데, 과금이되니까 Github Actions 을 택하는 편

3. CodeDeploy : EC2 내 자동 배포

EC2 에 CodeDeploy Agent 미리 설치 후, 배포를 위한 YAML(appspec.yml) 파일을 Agent 에 전달해 배포

  • Elastic Beanstalk 이나 CloudFormation 을 사용하지 않는 완전히 독립적인 배포
    • 이말은 즉슨 CodeDeploy 의 관심사는 정말 딱 EC2 에만
    • Elastic Beanstalk 이나 CloudFormation 은 EC2 주변부의 인프라에 대한 설정들도 함께했었다면
  • EC2 인스턴스뿐만 아니라 온프레미스 물리 서버에도 CodeDeploy Agent 만 설치되어있으면 적용 가능
  • CodeDeploy 는 EC2 자체 배포에 대해서 관심사를 갖는데, Blue/Green 등의 배포 방식도 설정 가능

8. AWS Lambda : Serverless

람다라고 불렀던 익명함수는 필요할때 바로 정의해서 사용한 뒤 재사용하지 않는 것

  • Lambda 도 이와 비슷하게 서버를 계속 띄워놓고 재사용하는게 아닌 실행할 때만 잠깐 서버를 띄워 수행
    • Event-Driven = On-demand 로 실행된다는 것 = 필요할 때 짧게 서버를 띄워 수행
    • Short Executions : 짧게 수행할 로직에 가장 적합
  • Serverless 인 Fargate 타입의 ECS 에서 봤던 것과 동일한 특성
    • = EC2 서버가 없기 때문에 Provisioning & Infrastructure 불필요
    • = CPU, Memory 성능 제한값 내에서 유동적으로 사용 = 매우 간단한 테스크 수행에 유리
    • 추가적으로 비용이 매우 저렴하고 (호출 빈도수가 낮다는 전제하에)
      • 심지어 Free Tier 의 경우에는 매달 100만개의 호출과 40만GBs 의 컴퓨팅 시간을 주기에
      • 사실상 Free Tier 기간내에는 공짜로 어플리케이션 제공이 가능하다는 이야기
  • 개발 언어는 어떤것이든 상관없이 이제는 거의 다 실행 가능 (한정적 언어만 수행가능했던 과거와 달리)
    • Node.js, Python, Java, Go 정말 무엇이든 가능

괜찮은 Lambda 사용 예시 : Serverless Thumbnail Creation

[ 사진 출처 : Creating a serverless thumbnail service with AWS CDK ]

9. AWS API Gateway : Serverless API = AWS Lambda 연결

일반적으로 외부 유저가 직접 Lambda 호출할 수 없어 중간 Proxy 로 API GW 이용
[ 사진 출처 : API Gateway to a Lambda function using Lambda proxy and non-proxy integration, with OpenAPI ]

10. AWS IAM : 계정 및 권한 설정

IAM : AWS 계정 및 자원에 대한 권한 관리

Identity and Access Management, 글로벌 서비스 (모든 리전과 글로벌에 배치된 서비스들에 적용하기위해)

  • Identity : 다양한 User 사용자 계정을 제작 가능
  • Access : User & Group 혹은 Role 에 권한 정책을 부여

Root Account → 다수의 Users 생성

  • Root Account : AWS 에 최초 회원 가입한 각자의 계정 = 모든 서비스와 결제관리 가능 = 마스터키
    • 절대로 누구에게도 공유되어서는 안된다 (하지만 스타트업이나 사이드 프로젝트에서 가끔 이렇게 사용)
    • 최고 권한을 가진 마스터키인 Root Account 로 User 사용자 계정을 만들어서 개발자들에게 배부
      • Root Account 에 부여된 Account ID 계정 ID 로 만들어진 User 사용자 계정으로 로그인 가능

User & Group 혹은 Role

순서대로 조합 : 권한(Action) → 정책(Policy) → 계정(사용자 (User), 그룹 (User Group), 역할 (Role))

1. 권한(Action)

가능여부의 소단위 = 권한

  • S3 에 쓰기 가능 권한
  • S3 에 읽기 가능 권한 등

2. 권한 정책(Policy) = 권한들(Actions)

가능여부의 집합 = 정책

  • S3 에 대한 기본 조회 접근 정책
    • S3 에 읽기 가능 권한
    • S3 메타데이터 읽기 가능 권한 등
  • S3 에 대한 기본 CRUD 접근 정책
  • S3 에 대한 DML 까지 조작 가능 어드민 접근 정책
  • Policy 구성
    • Version : AWS 에서 제공하는 Policy 작성을 위한 언어 버전
    • Id : Policy 정책에 개별 명칭을 붙여주고싶을때
    • Statement
      • Sid : 다수의 Statement 가 있을때 구분을 위한 Statement ID
      • Effect : Allow 허용 O | Deny 거부 X
      • Principal : (A) 누가 (User & Group 혹은 Role)
      • Resource : (B) 어떤 리소스에 대해
      • Action : (C) 어떤 (매우 작은 소단위) 권한들을 갖게할 것인가
      • Condition : (D) 어떠한 조건 내에서

3. 계정(User, Group, Role) = 권한 정책들(Policies) + 권한들(Actions)

계정에는 미리 잘 정의된 정책을 할당할 수도, 당장 필요할땐 급하게 권한을 할당해서 쓸 수도

  • Policies = 권한들 : 앞서 여러 권한들을(Actions) 한데 모아서 권한 정책(Policy)으로 정의해놓은 것
  • Actions = 인라인 권한 정책 : 긴급히 해당 계정에 대해서만 필요할 때마다
  • 일반적으로 권한 정책으로 원하는 권한들만 적용할것 + 관리에 있어 User Group 사용을 권장
    • 개인 프로젝트는 괜찮으나, 회사에서는 그렇게하면 관리가 아예 되지않거나 전체 권한(*)을 주게 되는 불상사 발생
    • 심지어 어떤 회사에서는 루트 계정을 그대로 사용하는 경우도 존재

(1) 사용자(User)

자원이 아닌 사람

예를 들어, 어떤 사람이 자신의 컴퓨터로 AWS CLI 프로그램을 통해 외부에서(로컬 서버에서) 접근할 때

(2) 사용자 그룹(User Group)

사용자(User)를 그룹화 한것

(3) 역할(Role)

사람이 아닌 자원

예를 들어, AWS 서비스(예, EC2)에서 AWS 서비스(예, S3)에 접근할 때

IAM 권한은 언제 사용하나?

  • AWS Management Console : 일반적으로 여러분이 사용하는 웹 브라우저 ← ID/PW 로 로그인하여 사용
  • AWS CLI : 터미널 명령어를 통해 수행 ← Access Key + Secret Access Key 사용
  • AWS SDK : 개발언어마다의 라이브러리를 통해 코드로 수행 ← Access Key + Secret Access Key 사용
    • Access Key (ID) ~= username
    • Secret Access Key ~= password

Identity-based Policy vs Resource-based Policy

11. AWS EC2 : 클라우드 서버 임대

1. EC2 새로 생성 시 설정하는 요소들

  • 운영체제 (OS, Operating System) 선택
  • 인스턴스 타입 (CPU + Memory) 선택
  • 스토리지 (네트워크 통해 연결하여 사용하는 스토리지 EBS, EFS 혹은 하드웨어 EC2 인스턴스 스토어) 선택
  • IP (서브넷) 설정
  • 방화벽 (SG, 인스턴스 단위인 Security Group) 설정
  • 부트스트랩 (EC2 유저 데이터, 매번 EC2 부팅 시 실행할 명령어 등의 프로비져닝) 설정
    • 패키지 매니저 설치나 업데이트
    • 라이브러리나 프로그램 설치
    • AWS 서비스 관련 에이전트 설치
    • 외부 인터넷으로부터 다운로드 받을 무언가 등등
  • 추가적으로, EC2 인스턴스 종료 방지를 위해 Termination Protection 종료 방어 설정 가능

2. EC2 인스턴스 타입

T2, T3, T3a, T4g 인스턴스 타입에 따른 비용 차이
메모리 성능에 따라 네트워크 성능이 달라진다!

  • 인스턴스 타입 네이밍 규칙 : m5.xlarge
    • m : 인스턴스 클래스 (t = 일반목적, c4 = 컴퓨팅 중심, m = 메모리 중심)
    • 5. : 세대
    • xlarge : 사이즈 (CPU + Memory + Network I/O)

12. AWS AMI : 이미지 = 운영체제, 환경설정, 프로그램 등 미리 만들어진 서버 설정

AMI : EC2 서버 구동을 위한 OS 및 환경을 포함한 “이미지”

  • AMI(Image) 는 케익을 층층히 쌓는 것이라고 생각하기 = 이 점은 Docker Image 와 거의 유사
    • 가장 밑바닥에는 OS (Ubuntu, Linux, Windows 등) 를 깔아두고
    • 배포하여 구동하려는 프로그램의 언어가 무엇인지에 따라 런타임 환경 구축 (Python 이나 Node.js 등)
    • 모니터링이나 배포 자동화 등을 위해 사용하는 AWS 서비스의 Agent 를 미리 설치하거나
    • EC2 서버를 사용하는데 필요한 기타 환경설정 등
  • 이렇게 쌓아올려 정의한 AMI(Image) 는 아래와 같이 분류 가능
    • Public AMI : AWS 가 미리 만들어서 제공하는것
    • AWS Marketplace AMI : 누군가가 미리 만들어둔 것 = AWS 가 원래 제공하다 제공안하는 AMI 경우
    • Our own AMI : 직접 만들어서 재사용하는 것

AMI 용례

어떤 EC2 를 선택하더라도, Ubuntu, Linux, Windows 와 같은 다양한 OS 를 상황에 맞게 써야할 때가 있을 것

  • 이떄 AMI 는 Ubuntu, Linux, Windows 와 같은 다양한 OS 에 대한 이미지를 제공
    • ex ) Ubuntu 10 버전이 필요해 ← Ubuntu 10 버전 이미지를 선택하여 EC2 를 구동
  • 단순하게 OS 를 제공할수도 있고, JVM 이나 NAT Instance 처럼 미들웨어나 런타임을 제공하기도
    • ex ) AWS 실습 중 NAT Instance 를 위한 EC2 서버를 만들때 NAT Instance 용 AMI 를 선택

AMI = Provisioning Image 프로비져닝 이미지

"프로비저닝(Provisioning)"
= 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것
하드웨어, 소프트웨어, 네트워크 리소스 등 다양한 IT 자원을 포함할 수 있으며, 자동화 도구를 사용하여 효율적으로 수행 가능

EC2 내에 여려 Docker Container 들을 실행시키기 위해서는 당연히 EC2 내 Docker 설치 필수

  • Docker = Container 를 통해 어플리케이션 구동을 위한 런타임 환경 자동 프로비저닝 Provisioning
  • AWS AMI = 어플리케이션 구동을 위한 OS 및 런타임 환경 자동 프로비저닝 Provisioning
    • AWS AMI 는 OS + 런타임 환경에 대한 프로비저닝이지만
    • Docker 는 런타임 환경에 대한 프로비저닝이라서 AMI 대비 Lightweight and Portable 특성

(1) Provisioning Image = AWS AMI

  • AWS AMI
    그래서 아예 설치하고자하는 OS 그리고 모든 패키지들과, 필요한 네트워크 설정을 마친 AMI 이미지를 미리 준비해놓은채 그걸로 바로 EC2 를 구동
    편리한 것은 맞지만, 패키지의 버전이 바뀌었거나 변경 사항이 있을 때마다 수많은 AMI 들이 생겨나기에 저장소 비용도 증가할 뿐더러 AMI 간 버전 컨트롤도 난해

(2) Provisioning Script = Packer for AWS AMI + Ansible for Configuration

  • (1) AWS AMI 생성을 위한 Provisioning Script → Packer
  • (2) Configuration (Python 설치 등)을 위한 Provisioning Script → Ansible

이러한 스크립트(코드)로 인프라 관련 생성이나 설치 관리 → Infrastructure as Code = IaC
- = Creation, Management, and Versioning of Infrastructure

설치해야할 것들과 각각의 관계, 네트워크 등의 설정 모두 Static 하게 실존하는 것으로 구성하기보다는 Script 를 통해 기술하는 프로비저닝 방식을 사용하면 저장 비용, 버전 관리 등에서 이득

13. AWS ELB : Load Balancer = L2 Reverse Proxy

1. Scalability 확장성

더 많은 트래픽이 발생하더라도 충분히 커버할 수 있는 시스템의 특성

(1) Vertical Scalability 수직 확장성

Scale up/down = 단일 인스턴스 성능 업그레이드 (한 인스턴스의 성능을 업그레이드하는 것)

  • 1개 t2.**micro** → 1개 t2.**large**
  • 단점 : 하드웨어 성능을 높히는데에 한계가 있고, 동작중인 서버를 내리고 다시 띄워야하는 중단 배포가 발생

(2) Horizontal Scalability 수평 확장성 = Elasticity 탄력성

Scale out/in = 인스턴스 개수 증가 (인스턴스의 개수를 늘리는 것)

  • 1개 t2.micro → 10개 t2.micro
  • 장점 : 하드웨어 개수를 늘리는데에 한계가 없고, 동작중인 서버는 그대로두고 새 서버를 늘리는 무중단 배포
  • Auto Scaling Group (ASG)
    특정 기준에 따라 인스턴스의 개수를 직접 늘리거나 줄이기 위한 그룹
  • Load Balancer : Target Group (TG)
    타겟 그룹 내 다수 인스턴스들에 트래픽을 공평하게 (혹은 어떤 기준을 갖고) 분산

2. High Availability 가용성

Scalability 확장성과 High Availability 가용성은 서로 관련있는 개념이지만, 각자 다른 것을 의미

  • vailability 가용성은 시스템에 부분적으로 문제가 생겨도 서비스를 사용하는데 문제가 없는 것 즉, 가용한 것
  • High Availability 가용성을 한마디로 줄여 정의하라하면 = Multi-AZ (Availability Zone)

(1) Multi-AZ (Availability Zone)

AWS 클라우드 서비스는 하나의 리전(국가)에 데이터센터를 최소 2개 이상의 지역으로 분산
하나의 리전(국가) 내 하나의 지역이 정전이나 화재와 같은 문제가 발생 시, 남아있는 다른쪽 지역이 커버하기 위해서

3. Elasticity 탄력성 위한 기술

(1) ELB : Load Balancer = L2 Reverse Proxy

  • 사용 목적
    • 다수 인스턴스(서버)에 트래픽 분산
    • 일부 인스턴스(서버) 문제 발생 시에도 문제 없이 서비스 서빙
      • 지속적으로 LB 에 연결되어있는 인스턴스(서버)들에게 매번 Health Check 진행으로 상태 확인
    • 단일 엑세스 포인트를 통한 HTTPS 와 DNS 적용
      • 단일 엑세스 포인트로 HTTPS 를 그 뒷단 다수의 서버 대신해주는 것 = SSH Termination
    • High Availability 가용성
  • 종류
    • CLB (Classic)
      : L4 (Transport) & L7 (Application) 기준 트래픽 분류
    • ALB (Application)
      : L7 (Application) 기준 트래픽 분류 = HTTP/HTTPS 페이로드 기준
      • 정적 DNS 제공
    • NLB (Network)
      : L4 (Transport) 기준 트래픽 분류 = Ultra-high Performance (IP + PORT) 기준
      • 정적 IP 제공 = EIP (Elastic IP)
    • GLB (Gateway)
      : L3 (Network) 기준 트래픽 분류 = IP 기준 방화벽 역할 (침입 감지, 심층 패킷 검사 등)

(2) ASG : Auto Scaling Group

  • 동작
    • 트래픽이 증가하면 → EC2 인스턴스 수 증가
    • 트래픽이 감소하면 → EC2 인스턴스 수 감소
    • EC2 인스턴스 삭제나 추가 시 자동으로 ASG 내 Detach/Attach
    • 인스턴스에 문제가 생길 경우 해당 인스턴스- 를 죽이고, 새 인스턴스를 생성
  • 설정값
    • Minimum Size 최소 용량 : 최소한으로 살아있어야하는 인스턴스 수 (이거 때문에 인스턴스 못지우는 사례 빈번)
    • Desired Capacity 원하는 용량 : ASG 가 실제로 갖는 인스턴스 수 = 기본 개수
    • Maximum Size 최대 용량 : 트래픽이 쏟아질때 최대로 증가시킬 수 있는 인스턴스 수

Scalability 확장성 vs Elasticity 탄력성 = 가용성 vs Agility 기민성

  • Scalability 확장성 : 단일 인스턴스 성능 업그레이드(Scale up) 혹은 인스턴스 개수 증가(Scale out)
  • Elasticity 탄력성 : Scalability 확장성 중 Horizontal Scalability 수평적 확장을 콕 집어 지칭한것
  • Agility 기민성 : 애자일 개발 방법론
profile
2SEONGA
(와.. 정말 Chill하다..)
이전 포스트

AWS Network

다음 포스트

AWS VPC 및 서브넷 설정하기 & Public EC2 생성 후 외부 접근 허용 실습

0개의 댓글