AWS 아키텍쳐 교육 정리한 내용입니다.

교육을 듣지 않고, 아래 내용 만으로 이해하기 어려운 부분이 있을 수 있습니다.

교육 듣고 나서 정리하는 차원에서 편하게 읽으시면 됩니다.

잘못된 내용은 과감히 거르시고 읽으시면 됩니다.

 

 

            >>  아  래 <<


--------------------------------------------------------------------

AWS architecure center  --- 아키텍쳐 참고 가능 (https://aws.amazon.com/ko/architecture/)
aws quick starts -- 자동화된 표준 배포 (https://aws.amazon.com/ko/quickstart)
aws simple icon  - 아키텍처 다이어그램 구축을 위해 설정된 공식 AWS 아이콘 (https://aws.amazon.com/ko/architecture/icons/)

--------------------------------------------------------------------

firefox - Console record for AWS (add-on)
 - console 화면 녹화하여 그 결과를 JSON이나 YMAL 형태로 만들어 줌.

--------------------------------------------------------------------

 


WAF- 백서로 제공 됨. ( AWS Well-Architected Framework 한국어 기술 백서(PDF 버전)를 공개합니다.)
  - 한글 버전은 영문버전 보다 1~1.5년 늦음.


 AWS Well-Architected Tool
모든 AWS 고객이 Well-Architected 검토를 이용할 수 있도록 하기 위해 AWS Well-Architected Tool을 새롭게 선보입니다. 이 도구는 아키텍트와 담당 관리자가 AWS 솔루션스 아키텍트의 도움 없이도 언제든지 AWS 워크로드를 검토할 수 있도록 설계된 셀프 서비스 도구입니다.


보안

 - IAM : 무료 서비스
   . 자격증명연동 가능 : AD, IdP (자격 증명 공급자) 등...
   . CloudTrail : 추적 가능성 활성화.. S3에 저장 가능.(버킷을 통해 접근)
       S3에 object lock 기능제공(worm 기능 : write once read many)

 

안정성
 - auto-scaling

 

비용최적화
  - aws calculator
  - aws cost explorer
  - aws trusted advisor (standard, advance 두종류)


  EBS 비용 청구 개념 : 초기 할당 공간에 대한 비용 청구
  s3나 다른 스토리지는 사용하는 만큼 비용청구함.

 

운영우수성
  - cloud watch

성능효율성


--------------------------------------

AWS 글로벌 인프라 3가지 기억해야 함.

 1. 리전  : 인프라 위치를 지리적 대표 도시 이름으로 논리적으로 표현한 의미임. ex)서울리전, 도쿄리전

 2. 가용영역 : 하나 이상의 데이터 센터로 구성, 별도의 지역에 별도의 시설별로 분리.
 
 3. 엣지로케이션 : aws 4가지 기능제공
        Route53 (DNS), Cloud Front (CDN), AWS Shield,  AWS Web Application Firewall(WAF)


spot instance 요금제 : 시장가와 입찰가를 고려하여 요금 부여
    가용영역 단위로 시장가가 결정됨.
 단점 : 시장가가 입찰가보다 높아지면 instance를 회수함.

 auto-scaling 시 on demand , spot 인스턴스 사용에 대한 우선순위 정할 수 있음.

 

.아래 아키텍처 다이어그램의 모든 구성요소를 이해할 수 있어야 함.

 

 

---------------------------------------------------

모듈 2.


S3 : 오브젝트 스토리지
내구성 : 견고성, 보안 99.999999999% 내구성 (파일 1만개를 천만년동안 보관할때, 1개 깨질 확률)
 S3에 파일 업로드시 내부적으로 3복제 함.
 이벤트 트리거 기능.
 - 정적 웹 호스팅 가능
 - 기본 버킷은 private이지만, public, 액세스 정책 가능함.
 - 권한은 Json 파일 형태로 제어 가능

  - 버전관리 기능은 디폴트는 비활성화 상태임.
  - CORS(Cross-Origin Resource Sharing) 가능

 

 S3에 인터넷을 통해 대량의 데이터를 보내야 하는데, 방법은?
   1. 멀티파트 업로드 (병렬방식) 를 통해 해결..
   2. S3 transfer acceleration (엣지 로케이션 이용)
        ; 엣지 로케이션 까지는 인터넷, 이 이후는 AWS 네트워크를 이용
   3. AWS Snowball, Snowmobile 이용

 

비용추가 방식
  . 저장공간 + 인터넷전송 (put, copy, post, list, get)
   but S3로 수신하는것, 동일 리전 내 EC2 전송, Cloud Front전송 제외

 

S3 Glacier : 온프리미스 환경의 tape 으로 생각하면 됨.
  데이터 조회 요청시  아카이브된 데이터를 S3에 풀어서 제공함.

S3 종류
 . S3 Standard  : 범용 (여러 가용영역에 여러 복제본으로 보관)
 . S3 Standard IA  : 자주는 아니지만 빠른 액세스
 . S3 One zone IA : 자주 액세스하지 않는 재생성 가능한 데이터 (하나의 가용영역에 여러 복제본 으로 보관)
 . S3 Glacier/Deep : 사용 가능한 가장 저렴한 스토리지 티어에 데이터 보관

 

리전선택
  - 데이터 주권 및 규정 준수
  - 사용자와 데이터간 근접성  
  - 서비스 및 기능 가용성
  - 비용 효율성

 


사용자 데이터
 ; AMI에 포함되지 않은 사용자가 필요한 쉘 등 스크립트등..
 ; 최초 구성시 1회 수행됨.

메타 데이터
 ; 인스턴스 id, mac, ip등..

인스턴스 스토리지 : 호스트에 직접 연결된 스토리지, 휘발성 스토리지.
EC2 인스턴스를 stop/start시 host가 변경됨.
EBS 내구성은 99.999% 임. => 백업을 받아야 하는데, 스냅샷으로 수행되며, S3에 저장됨.
aws에서는 백업을 스냅샷으로 나타냄.

 

SSD 기반
 - 범용 SSD
   1GB당 3 IOPS 제공함.
      if) app가 150 IOPS가 필요하면 최소함 50GB를 할당 받아야 함.(최대 3000 IOPS까지 지원됨)

 - 프로비저닝된 IOPS SSD
   필요한 IOPS를 직접수치로 지정함.
    ex) 3만 IOPS로 지정을 해서 사용하려면 EC2 인스턴스도 높은 걸로 선택해야 함.
    최대 64,000 IOPS 지원가능함.

 

HDD 기반
   - 처리량 최적화 HDD
   - 콜드 HDD

EBS 최적화 인스턴스


크레딧 : 항상 컴퓨팅 파워을 전부 사용하지 않기 때문에
적게 사용할때 크레딧을 모아두고, 컴퓨팅 파워가 부족할때 모아진
크레딧을 사용하게됨(버스트 기능)

패밀리에 따라 인스턴스 스토리지 가능한 것들이 있음.
T패밀리 : 크레딧 가능
C패밀리 : 크레딧 불가

H패밀리 인스턴스 스토리지 사용가능


온디맨드 인스턴스 : 리눅스와 우분투인 경우만 초단위 요금제, 나머지는 시간단위 요금제임
예약 인스턴스 : 3가지 선불제 요금제, 온디맨드 대비 최대 70% 저렴. 환불안됨. but 마켓플레이스에 판매 가능함.
  if) 3년 약정으로 t2사용시 1년 후 t3가 나왔을경우 t3로 바꿀수 있다.
스팟 인스턴스 : 종료 2분전 공지. 시장가+입찰가로 가격책정됨. 시장가는 가용영역으로 결정됨. 스팟블록 가능 (1~6시간 가능)


전용 호스트 : 고객에게 하드웨어 가시성 제공
  특정 벤터 소프트웨어 라이센스 사용시 고려시 사용

 

전용 인스턴스 : stop/start시 호스트는 변경됨.
   stop -> 보류중 -> start 상태 변경시 보류중 상태에서 내부적으로 호스트 검색함.

사용자의 인스턴스 추적

  - 대소문자 구분함.

 


모듈 4. 데이터베이스 계층 추가

관계형 데이터베이스
 - RDS
 - Redshift (DW, 병렬처리)

비관계형 데이터베이스
 - DynamoDB (키:값,  데이터 크기에 관계없이 10ms 내 응답시간 보장, 사용자는 테이블만 정의하면 나머지는 모두 AWS에서 수행함. ex EC2, 스토리지등.. 모두 aws가 관리)
 - ElastiCache
 - Neptune (그래프 형식 DB)


Aurora - 16개 노드가 클러스터로 구성되어 제공됨. (1개의 마스터, 15개의 슬레이브로 구성)

DynamoDB 글로벌 테이블 :

DynamoDB 일관성 옵션
 - 최종 일관성
 - 강력한 일관성


ASW DMS (Database Migration Service)
 ; 온프레미스 - 클라우드간 데이터 이관 지원
 데이터베이스가 너무 크거나, 연결이 느리거나, 개인정보 보호 및 보안 문제가 있을때는
AWS snowball edga 사용하여 이관


AWS SCT (Schema Conversion Tool)
 ; 기존 데이터 베이스 스키마를 이관

 


모듈 5: AWS에서의 네트워킹 1부


VPC는 AWS리전중 1개 리전에 배포

다중 VPC 및 복수 계정

 

- 다중 VPC 패턴
계정 한개에 여러 VPC를 생성하여 관리, 기본 5개 생성가능함.(soft limit)
만일 더 필요할경우 AWS에 요청하면 더 증설 가능함.

 

- 복수 계정 패턴
생성한 인프라를 다른 조직으로 이관 가능함.
VPC뿐만 아니라 다른 자원에 대해서도 limit이 존재하기 때문에 설계시 고려해야 함.

CIDR
10.0.0.0/16 = 10.0.0.0 에서 10.0.255.255 까지의모든 IP사용

AWS는 각 서브넷에서 5개의 IP주소를 예약하여 사용자가 사용불가함.
만일 서브넷을 10개로 만들면 50개의 IP를 사용하지 못함.


NAT 게이트웨이
 퍼블릭 아웃바운드는 가능하나 인바운드 불가함.
 ex) 패치가 필요할경우 사용


웹티어인스턴스를 퍼블릭 서브넷에 넣을수 있지만
AWS는퍼블릭서브넷에 배치된로드밸런서 뒷쪽의 프라이빗서브넷 내부에 이 인스턴스를배치할것을 권장함.
일부환경에서는 웹애플리케이션 인스턴스를 탄력적 IP에직접 연결해야하며(탄력적 IP를로드밸런서에연결할수있더라도), 그런경우웹 애플리케이션인스턴스는퍼블릭서브넷에있어야합니다. 로드밸런서는이후 모듈에서자세히다루기로하겠습니다. (AWS)

웹 애플리케이션을 프라이빗에 둘 경우 해당 정보가 사용자에게 공유 되지 않아
보안에 좋음.


서브넷 권장 사항

큰 크기로 서브넷 설정
차후 ip 부족시 VPC 를 재구성 해야함.

 

탄력적 IP 주소 (EIP)

EIP 는 고정해서 사용가능.
인스턴스간 이동 가능


보안그룹(Security-Group) 은 기본적으로 모든 인바인드 트래픽 차단 , 모든 아웃바운드 트래픽 허용 상태임.

네트워크 ACL (NACL)
 ; 보안그룹 보다 더 큰 범위의 보안임. (설정시 관리적 측면이 늘어남)
 ; 서브넷 경계의 방화벽
 ; 기본적으로 모든 인바인드/아웃바운드 허용되어 있음

다중보호 계층이 있는 인프라구조(p. 237)

 

 

가상 프라이빗 게이트웨이 (VGW)
 ; 온프레미스와 AWS 를 네트워크 연결 (VPN)

 

AWS Direct Connect(DX)

 

하이브리드 클라우드 아키텍쳐
 ; 데이터 보안등..컴플라이언스 충족을 위해.. 사용 고려.
 ; 빅뱅방식으로 클라우드 전환이 어려울 경우 사용 고려

비용절약을 위해, 주 회선은 DX로, 보조회선은 VGW로 구성하는것도 고려

 

VPC 피어링
  ; 1-1로만 구성 가능함.
  ; 타 계정, 다른 리전의 VPC와 피어링 가능
  ; IP 중복될 수 없음.

AWS 서비스는 기본적으로 확장성, 가용성, 내결합성 지원함.

 

VPC연결 - Transit Gateway
 ; 단일 게이트웨이로 최대 5000개의 VPC와 온프레미스 환경에 연결
   네트워크에 흐르는 모든 트래픽의 허브 역할 담당


VPC 엔드포인트
 ; AWS를 벗어나지 않고, EC2인스턴스를 VPC 외부 서비스와 프라이빗하게 연결함.
 ; 동일한 리전에 있어야 함.

 

VPC 피어링 : VPC 간의 연결


VPC 엔드포인트 : VPC와 AWS 서비스간 연결

 

VPC 엔드포인트
  - 게이트웨이 엔드포인트 - 라우팅 경로 거처서 접근
  - 인터페이스 엔드포인트 - IP로 접근

 

EBL
 . ALB
 . NLB

가용영역당 50:50으로 분배함.
25:25 25:25 (가용영역 두군대에 2대씩 구성시 부하분산)
25:25 50    (가용영역 두군대중 1군대 서버 1대만 서비스 가능시 부하분산)

교착영역 로드 밸런스 기능을 활성화 하면 가용영역이 아니라,
사용가능한 인스턴스로 세션을 보냄
33:33:33

Connection Draining 기능 :  고객이등록해지한백엔드 인스턴스가등록해지되기전에진행중이던요청을먼저완료 (AWS)
Secutiry Group 도 추가적으로 구성가능함.

 

 

Route 53 라우팅 옵션
- 간단한 라운드 로빈
- 가중치 기반 라운드 로빈
- 지연 시간 기반 라우팅
- 상태확인 및 DNS 장애 조치
- 지리 위치 라우팅
- 트래픽 바이어스를 통한 지리근접 라우팅
- 다중 값 응답

 

 

모듈 7. IAM

AWS 계정 루트 사용자
  - 리눅스의 root, 윈도우의 administartor 와 같음

IAM 사용자는 별도의 AWS 계정이 아니라 계정 내 사용자입니다.
기본적으로 주어진 권한은 없음.

리소스 기반  - AWS 서비스에 부여, 항상 인라인 정책임 (필요한 리소스를 하나하나 입력 해야 한다는 뜻)
자격 증명 기반 - IAM 보안 주체


IAM 정책시 NotResource는 여기에 정의된 항목만 제외한다는 뜻

IAM 역할
 - 권한을 IAM 사용자 또는 그룹에 연결하지 않음.
 - 권한을 역할에 연결하고 역할을 사용자 또는 서비스에 위임함.


Amazon Cognito

여러 AWS 계정을 사용하기 위한 전략

AWS Organizations
 ; 통합결제 가능

 

 

모듈 8. 탄력성, 고가용성 및 모니터링

Cost Explorer - 13개월 데이터를 참고하여 지출패턴 확인 (가계부같은 역할)

CloudWatch
 ; 리소스 지표 수집, 경보 생성, 트리거 가능


CloudTrail : 계정에서 이루어지는 모든 API 호출을 기록하고 지정된 S3버킷에 로그를 저장
   S3에 object lock, glacier에는 vault lock 설정하여 위변조 방지


VPC flow log : 트래픽 흐름 세부 정보 캡쳐


Auto Scaling
 - 예약 : 예측 가능한 워크로드에 적합 (야간 및 개발 테스트 인스턴스 종료)
 - 동적 : ex) cpu 사용율 기반으로 조정
 - 예측 : 기계학습 기반 조정

Auto scaling 구매 옵션 , 아래 옵셧을 섞어서 구성할 수 있음.
 - 온디맨드
 - 예약
 - 스팟


auto scaling 최소 용량 기준은 ? 가용영역을 기준으로 설정
최대 용량은? 비용기준으로..


cpu 사용율이 50% 넘으면 인스턴스 1개 추가
지연시간이 ? 이상이면 인스턴스 2개 추가
이럴경우 동시 발생시 인스턴스 2개 이벤트 부터 수행됨.

if cpu 50% 1개 추가, 45% 1개 제외 이렇게 설정했을 경우
추가는 빠르게 지원되며, 제거는 천천히 됨.
핑퐁치는걸 방지하기 위해.

수명주기후크
정책이 발동되어도 세션정보/상태정보를 다른 DB나 저장공간에 옮긴후
인스턴스가 삭제 되도록 하는것. 최대 2시간 유보함.


SQLServer, Oracle은 Read replica 를 지원하지 않음.

Amazon RDS 확장시 : 가동중지 없이 스토리지를 늘릴 수 있지만, 인스턴스 유형을 변화하려면 가동 중지 시간이 필요함.

 


모듈 9. 자동화

 AWS ColudFormation : AWS 리소스를 자동화된 방식으로 생성하고 구축 (JSON, YAML사용)

    드리프트 감지 지원 : 기존에 만든 템플릿과 수작업으로 변경한 구성정보를 비교하여 다른점을 바로 감지함.


AWS Quick Start : AWS 클라우드에서 모범 표준 배포

AWS Systems Manager : 자동화된 구성 및 대규모 시스템의 지속적 관리가 가능한 기능의 집합
  ; AWS에서 뿐만 아니라 온프레미스 환경에서도 사용가능
   AMI 에는 agent가 설치되어 별도 구성이 필요없지만, 온프레미스 환경에서 사용할려면 agent 구성을해야함.
  - 명령실행, 유지관리 기간, 패치관리, 상태 관리자

Cloud Trail 서비스와 상태관리자와 연계하여 분석 진행가능함.


AWS OpsWorks
 

CloudFormation 관 OpsWorks 와 다른점은 CloudFormation 은 AWS 서비스만 자동 구성 관리 가능하지만, OpsWorks는 더 세부적인 것까지 설정가능함. 더 큰범위임.
두 서비스 같이 합쳐서 사용하여 구성가능함.

예) AWS CloudFormation 을 사용하여 인프라 (VPC, IAM 역할)를 구축하고 AWS OpsWorks를 사용하여 애플리케이션 게층을 배포함.


AWS Elastic Beanstalk
 - 인프라를 프로비저닝 및 운영하고 사용자를 위해 애플리케이션 스택을 관리

 

 

모듈 10. 캐싱

무엇을 캐싱해야 하나? 자주 변경되지 않는 정적인 데이터 우선.
                            자주 액세스 하는 데이터

엣지캐싱 : CDN


Amazon Virtual Private Colud에서 Bring Your Own IP 공식 출시 발표


Amazon CloudFront
  - Amazon의 글로벌 CDN
  - 다중 계층 캐시와 광범위한 유연성으로 모든 전송 사례에 최적화

콘텐츠 만료 방법
  - Time To Live (TTL)
   . 기간고정, 고객이 설정
 - 객체이름 변경
 - 객체 무효화

 

 

모듈 11. 결합 해제된 아키텍쳐 구축

밀결합  <--> 소결합

Amazon Simple Queue Service(Amazon SQS) - 완전 관리형 서비스
 대기열 유형
 . 표준 대기열
 . FIFO 대기열

Amazon Simple Notification Service(SNS)
 ; 클라우드에서 손쉽게 알림기능을 설정, 작동 및 전송할 수 있는 웹 서비스임.


                             SNS         vs         SQS
- 메시지 지속성        아니요                   예
- 전송 메커니즘        푸시(수동적)          폴링(능동적)
- 생산자/소비자        게시/구독             송신/수신
- 배포 모델              일대다                 일대일

 

 

모듈 12. 마이크로 서비스 및 서비리스 아키텍쳐

 마이크로 서비스 (MSA)
 ; 잘 정의된 API를 통해 통신하는 독립서비스로 구성된 애플리케이션

컨테이너 서비스

Amazon Elastic Container(ECS)
 - EC2 사용하기
 - AWS Fargate - 완전 관리형 컨테이너 서비스 사용하기


서버리스 환경 구현
 ; 서버를 관리하지 않고, 앱과 서비스를 구축하고 실행

. AWS Lambda (최대 15분 수행가능)
 완전 관리형 컴퓨팅 서비스
상태 비저장 코드실행

Lambda가 처리하는 작업

Lambda가 할 수 있는 작업


Amazon API Gateway
 ; 애플리케이션의 "현관" 역할을 하는 API를 생성할 수 있음.
 ; 캐싱역할도 수행함.


AWS Step Functions
 ; 시각적 워크플로를 사용한 마이크로서비스 조정


Lambda 에서 코드 수행을 더 빠르게 하기 위해 더 빠른 서버 선택 가능함.
 - cpu가 아니라 메모리만으로 조정 가능함.(default 128MB, 최대 3GB 까지 가능함)


if. Lambda 를 15분 4회 연속사용하여 1시간 사용비용과 EC2 1시간 사용비용을 단순히 비교하면
Lambda가 더 비싸다.

 

 

모듈 13. RTO/RPO

S3 -  교차 리전 복제

Amazon RDS
Amazon DynamoDB
자동백업 수행해 주지만, 최대 35일만 보관됨.

자동백업이 회사정책을 만족하지 못하면 수동 백업을 설정해야 함.

AWS Storage Gateway
 ; AWS Storage Gateway는온프레미스소프트웨어어플라이언스를클라우드기반 스토리지와연결하여온프레미스 IT 환경과AWS 스토리지인프라간에 원활하면서도매우안전한통합을제공합니다. 이서비스를사용하면확장 가능하고비용효율적인스토리지인AWS 클라우드에데이터를안전하게저장할 수있습니다. Storage Gateway는기존애플리케이션과연동하는업계표준 스토리지프로토콜을지원하는동시에Amazon S3 또는Amazon Glacier에서 암호화된모든데이터를안전하게저장합니다.
AWS Storage Gateway를사용하면AWS 관리서비스를로컬로확장할수있습니다. 이서비스는Amazon CloudWatch, AWS CloudTrail, AWS KMS, AWS IAM 등과도 통합됩니다.
AWS Storage Gateway는파일, 볼륨및테이프라는 3가지스토리지인터페이스를 지원합니다. 각게이트웨이에서는 1가지유형의인터페이스를제공할수 있습니다.
파일게이트웨이를사용하면NFS 및SMB 파일프로토콜을사용하여Amazon S3에서객체를저장및검색할수있습니다. 파일게이트웨이를통해작성된 객체는 S3에서직접액세스할수있습니다.
 (AWS)
 


AWS 기반 재해복구 사례 
 - 백업/복원
 - 파일럿 라이트
 - 완전 동작 저용량 스탠바이
 - 다중 사이트 액티브-액티브

AWS와 연결해서 생각해보면 무슨 "보안 서비스"나 "방화벽" 같은 느낌이 들기도 하는데, 사실은 우리가 소위 말하는

"Gateway Server"에 가깝습니다. 아니면, "서버접근제어" 라고 해도 될 것 같구요.

 

아시다시피, Private Subnet에 배포된 instance의 경우 외부에서 접근이 차단이 되어 있어서, 운영자 입장에서 ssh로 접근할 방법이 없습니다. 이 경우 Bastion host를 구성해서 외부에서 ssh로 접근이 가능하도록 할 수 있습니다.

 

모든 private subnet에 있는 instance들을 Bastion host를 통해 접속하도록 설정 및 관리할 수 있습니다.

다만, 보안적으로 Bastion Host가 공격 당하면 내부 네트워크 전체가 위험해 질 수 있으므로, 관리를 잘 해야할 것 같습니다.

- Bastion Host는 Public Subnet에 위치하도록 EC2 Instance를 생성함.

- 외부 사용자들은 Bastion host를 통해 접속함

- 외부 사용자의 특정 IP만 허용하여 Bastion host에 접속 가능하도록 ACL과 Security Group을 설정

- Bastion host를 통해 Private Subnet에 있는 instance로 접속

 

 

AWS 공식 사이트에서의 특징을 몇가지 정리해보면

 > 두 가용 영역에 걸쳐 있는 고가용성 아키텍쳐 구성

 > Private subnet의 리소스에 대한 outbound 인터넷 access 허용하기 위한 NAT G/W  (NAT G/W역할도 하나봅니다)

 > EC2 auto scaling 그룹 구성

 > Elastic IP 사용 (인터넷에서 접속이 되어야 하니 당연한거 같습니다)

 > 세분화된 inbound access 제어를 위한 Security Group

Task를 flow에 따라 수행하도록 하는 부분은 같은데, 세부적인 내용을 살펴보면 약간 다른 부분이 있습니다.

 

완전관리형이냐 아니냐의 차이와 serverless환경에서 수행되느냐 , 모든 리전에서 서비스 하느냐

정도의 차이가 있는 것 같습니다.

 

SWF (Simple WorkFlow)
 - 2012년 발표
 - 모든 리전에서 서비스 제공
 - Task 통합 관리할 때 세분화된 컨트롤 가능
 - workflow를 배포 및 시작할 수 있는 host(EC2와 같은)가 필요함
 - host의 위치는 상관없음(인터넷을 통해 통신 가능)
 - 비관리형 서비스
 - 사용자가 다루어야할 activity가 많은 대신 복잡해 질 수 있음(자유도 높음)
 - 비교적 긴 사용시간이 필요한 경우 사용


Step Functions
 - 2016년 발표
 - 특정 리전에서만 서비스 제공
 - 완전 관리형 서비스
 - SWF에 비해 Task 통합관리시에 세분화된 컨트롤이 약함
 - AWS Lamda functions을 이용해 배포되므로, 별도의 host 불필요
 - 완전 관리형 서비스의 특성으로 인해 사용자 제어 측면에서는 어느정도 유연성이 떨어짐.
 - 비교적 짧은 사용시간이 필요할 경우 사용

ElastiCache는 주로 DB의 처리 결과를 메모리에 저장했다가 다음 요청시에 저장된 결과를 반환함으로써, 애플리케이션을 빠르게 구동할 수 있게 해줍니다.

 

앞에서 설명드린 CloudFront와 컨셉만 보면 매우 비슷하죠? 캐싱기능이라는 점에서 유사성이 있긴 합니다. 물론, 사용하는 곳은 전혀 다르지만요... 아키텍쳐 설계 시 두가지를 함께 써서 설계를 하는 문제가 나올 수도...나왔을 수도 있습니다.^^;;;

 

 

ElastiCache는 인 메모리 캐시를 간편하게 배포,운영할 수 있도록 도와주는 AWS의 서비스입니다.

인 메모리 캐시는 일반적인 데이터베이스와는 다르게 데이터를 메모리에 올려놓고 사용한다고 하네요.

따라서, 상대적으로 느린 디스크 기반의 데어터 베이스가 아닌 메모리 캐시에서 정보를 검색하고 분석하기

때문에 처리량을 개선할 수 있고, 그로 인해 더욱 고성능의 서비스를 제공할 수 있습니다.

 

그리고, ElastiCache는 우리가 일반적으로 생각하는 캐싱과 달리, 캐시에도 쓰고, DB에도 함께 쓰는 방식이며, 읽을때만 캐시에서 읽어오는 구조라고 합니다. (흐름도를 그려야 할 경우에 주의가 필요해 보입니다)

 

아래 그림의 7번,8번 흐름도를 참고하시면 될 것 같네요.

 

 

ElastiCache는 현재 Memcached와 Redis 캐싱 엔진을 지원하고 있습니다.

두 캐싱엔진은 특성이 다르기때문에, 사용할 때 특성을 잘 알고 사용해야 합니다.

 

1. Memcached

  > 클러스터 노드를 추가하여 용량을 증설할 수 있음

  > 간단하게 처리할 때 주로 사용

  > Memcached로 묶인 모든 서버는 동일한 가상 메모리 풀을 공유

  > 분산 메모리 캐시를 적용하게 되므로, 캐싱을 통해 DB나 API호출에 대한 횟수를 줄일 수 있고,

     이로 인해 부하를 줄일 수 있음.

 

 

2. Redis

  > 클러스터 구성이 불가하며, 노드 추가로 인한 용량증설 효과를 볼 수 없음

  > 스냅샷 생성과 Read  Replica 기능 사용 가능

  > Read Replica 마스터 캐시 노드의 Failover 기능(Read Replica 승격) 사용 가능

  > Key-Value 저장방식이며, Value에는 일반적인 string외에 set,list,hash와 같은 집합형 데이터 구조를 지원

  > 저장된 데이터에 대한 연산이나 추가 작업 가능

 

 

 

 내용이 조금 복잡해 보일 수 있는데, 찾아보니 대부분의 경우에 Redis를 사용하는 것이 더 좋다고 하네요.

 

이부분은 아래 사이트에 잘 정리가 되어 있습니다.

 

http://blog.leekyoungil.com/?p=200

 

AWS 공식 홈페이지에서 정의하는 CloudFront에 대한 설명을 보시면....

 

Amazon CloudFront는 .html, .css, .js 및 이미지 파일과 같은 정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 지원하는 웹 서비스입니다.

CloudFront는 엣지 위치라고 하는 데이터 센터의 전 세계 네트워크를 통해 콘텐츠를 제공합니다. CloudFront를 통해 서비스하는 콘텐츠를 사용자가

요청하면 지연 시간이 가장 낮은 엣지 로케이션으로 라우팅되므로 콘텐츠 전송 성능이 뛰어납니다.

 

 라고 되어 있습니다.

일반적으로 CDN(Contents Delivery Network)하고 동일한 개념으로 알려져 있습니다.

 

 

조금 풀어서 정리해보면, 아래와 같습니다.

 

1. 웹 콘텐츠(정적 및 동적 콘텐츠)를 사용자에게 빨리 배포하기 위한 서비스이다.

 

2. Edge location을 통해 서비스를 제공한다.

 

3. 사용자 요청시 가장 지연지간이 낮은 Edge location에서 서비스 한다.

 

 

일반적으로 웹 콘텐츠를 S3에 보관을 하게 됩니다. 다시말해서 CloudFront 와 S3 조합을 많이 사용하게 되죠.

다행히도, S3에서 CloudFront로 데이터 전송비용은 무료라고 하네요.(CloudFront 서비스가 무료라는 얘기는 아닙니다)

 

 

그럼, 동작 원리를 한번 보시죠...(AWS 공식 홈페이지에서 퍼왔습니다.)

 

 

위에 번호하고 아래 설명을 맵핑해서 보시면 됩니다.

 

먼저 CloudFront 를 구성한 후,

 

1. 사용자가 객체를 요청합니다.

 

2. DNS가 최적으로 서비스할 수 있는 CloudFront Edge-Location으로 요청을 라우팅합니다.

   (위에서 설명드린대로, 가장 지연시간이 낮은 Edge-Location으로 라우팅합니다.)

 

3. 파일이 Edge-Location의 캐시에 있으면, CloudFront는 요청한 파일을 사용자에게 반환합니다.

 

   파일이 없을 경우에는

   3a. 오리진 서버에 파일 요청을 합니다.

   3b. 오리진 서버는 파일을 Cloud Edge-Location으로 보냅니다.

   3c. Edge-Location은 사용자에게 파일을 전달합니다.

 

 > 다른 사용자가 동일한 파일을 요청할 경우 Edge-Location은 캐시에 있는 파일을 사용자에게 반환합니다. (1->2->3)

 

VPC간 연결 방법으로 가장 쉽게 생각할 수 있는 방법에는 VPC Peering 이 있습니다.

 

교육후기에 공유했듯이 VPC Peering을 할 경우 VPC의 IP대역대가 겹치면 안되고요,
Internet Gateway는 필요하지 않습니다.

 

Public N/W을 타지 않기때문에 인터넷망에서 발생할 수 있는 보안 이슈 및 DDOS로 인한 영향을
받지 않습니다.


다만, 아래와 같이 여러 VPC간 VPC peering을 사용할 경우 네트워크가 복잡해 질 수 있습니다.


이 경우 사용할 수 있는 것이 AWS Transit Gateway입니다.


아래와 같이 Transit Gateway를 사용하여 네트워킹 모델을 단순화 할 수 있습니다.

 

 


Transit Gateway는 다른 VPC들의 Hub가 되어 VPC간 통신 연계를 가능하게 해줍니다.
Resource Manager를 통해서 Transit Gateway를 타 계정에 공유해서 타 계정의 VPC와 연동도 가능합니다.
On-Premise에서는 Transit Gateway로의 접근은 VPN방식으로만 가능하며, 일부 리전에서만 Direcet connet를
지원한다고 하네요. (매우 중요)

 

 

 

 

 

AWS 공식 사이트에서 언급한 특징은 아래와 같습니다.

==================================================

다음은 VPC Transit Gateway에 대해 알아두어야 할 몇 가지 다른 사항입니다.

 

> AWS 통합 – Transit Gateway는 Amazon CloudWatch에 지표를 게시하고 VPC Flow Log 레코드를 생성합니다.

 

> VPN ECMP 지원 – VPN 연결에 대해 ECMP(Equal-Cost Multi-Path) 지원을 활성화할 수 있습니다. 여러 연결에서 동일한

                          CIDR 블록을 알리는 경우 트래픽이 해당 연결 간에 균등하게 분산됩니다.

 

> 라우팅 도메인 – 동일한 Transit Gateway에 여러 개의 라우팅 테이블을 사용하고, 연결별로 라우팅을 제어하는 데 이러한
                        라우팅 테이블을 사용할 수 있습니다. VPC 트래픽을 격리하거나 특정 VPC에서 별도의 점검 도메인으로
                        트래픽을 우회시킬 수 있습니다.

> 보안 – VPC 보안 그룹과 네트워크 ACL을 사용하여 온프레미스 네트워크 간의 트래픽 흐름을 제어할 수 있습니다.

 

> 요금 – Transit Gateway가 연결되어 있는 시간에 대한 시간당 요금과 GB당 데이터 처리 요금을 지불합니다.
      
> Direct Connect – 현재 AWS Direct Connect 지원 기능을 개발하는 중입니다.

----------------------------------------------------------------------------------------------------

AWS architecure center  --- 아키텍쳐 참고 가능 (https://aws.amazon.com/ko/architecture/)
aws quick starts -- 자동화된 표준 배포 (https://aws.amazon.com/ko/quickstart)
aws simple icon  - 아키텍처 다이어그램 구축을 위해 설정된 공식 AWS 아이콘 (https://aws.amazon.com/ko/architecture/icons/)

AWS 용어 - 용어집 https://docs.aws.amazon.com/ko_kr/general/latest/gr/glos-chap.html

----------------------------------------------------------------------------------------------------

firefox - Console record for AWS (add-on)
         - console 화면 녹화하여 그 결과를 JSON이나 YMAL 형태로 만들어 줌.

----------------------------------------------------------------------------------------------------


WAF- 백서로 제공 됨. ( AWS Well-Architected Framework 한국어 기술 백서(PDF 버전)를 공개합니다.)
      - 한글 버전은 영문버전 보다 1~1.5년 늦음.


AWS Well-Architected Tool(https://aws.amazon.com/ko/well-architected-tool/)
모든 AWS 고객이 Well-Architected 검토를 이용할 수 있도록 하기 위해 AWS Well-Architected Tool을 새롭게 선보입니다. 이 도구는 아키텍트와 담당 관리자가 AWS 솔루션스 아키텍트의 도움 없이도 언제든지 AWS 워크로드를 검토할 수 있도록 설계된 셀프 서비스 도구입니다.

 

아키텍쳐에서 네트워킹이 가장중요함

 

VPC끼리 연결하려면 VPC peering 해야 서로 통신 가능함.(VPC간 IP대역이 중복되면 안됨, IGW는 필요없음)
-Public NW을 이용않음으로 보안이슈 및 DDoS 영향이 없음, 다만, NW이 복잡해짐으로 Transit G/W로 단순화 가능
 *Transit gateway : 다른 VPC의 허브역할 수행(VPC연결을 많이 할 경우에 사용), Resource Manager를 통해서 
                         Transit G/W를 타 계정에 공유해서 타계정의 VPC와 연동도 가능함.
  →Transit G/W로 접근은 on-premise는 VPN방식만 가능, 일부 리전에서만 Direct Connect지원 됨.

 

EIP : 고정 public IP

 

Transit gateway : 허브개념 (최근에 나왔으며 문의가 많음)
 - 연결을 많이 할 경우에 사용

 

cloudWatch: 모니터링 서비스


Cloudtrail- 호출되는 모든 로그를 기록하는 서비스

 

Elastic Beanstalk - 소스코드로 만드는 게 아니고 클릭 몇번으로 웹서버 등 구축 가능
  > cloudFormaion 등도 생성(소스코드도...)

 

cloudFormaion : 소스코드로 인프라를 만들어 줌

 

[컨테이너서비스]
1. ECS (ALB로구성) - 컨테이너 Orchestration (EC2에 컨테이터를 만드는 대신 fargate로 생성)
                       AWS의 내부 리소스와 밀접하게 연결하여 사용하고 싶다면 선택
        *fargate - 서버 또는 클러스터를 관리할 필요 없이 컨테이너 서비스를 가능하게 해주는 ECS를 위한 컴퓨팅엔진
                      (리소스 제어영역을 AWS에 넘겨서 ECS를 서버리스 환경같이 사용하게 함)

2. EKS (ELB외 내부에 Proxy 를 두어 Pods로 부하분산구성) - 컨테이너 Orchestration을 쿠버네티스 기반
                      외부 요소들 (Monitoring Tools 및 Hybrid Cloud 등등)과 연결하여 사용하고 싶다면 선택 

 

step function - 순서도 만들어주는 서비스, lambda 로 설정시 lambda끼리 서로 동작하는게 아니라
              step function에서 제어?


AWS란? - 프로그래밍 가능한 리소스, 동적 기능, 종량 과금제

 > 장점
   . 자본 비용을 가변 비용으로 대체
   . 규모의 경제로 얻게 되는 이점
   . 용량 추정 불필요
   . 속도 및 민첩성 개선
   . 중요한 문제에 집중
   . 몇 분 만에 전 세계에 배포


AWS well architected 프레임워크(AWS Well-Architected Framework)
 > 다섯가지 핵심 요소 : 보안, 안정성, 비용최적화,성능 효율성, 운영 우수성
    1)보안 : IAM으로 자격증명 연동가능(AD, LDAP,등) - Cloud Trail로 추적 기능 활성화(S3에 data저장)

    2)안정성 : Auto-Scaling

    3)비용최적화 : Calculator, cost explorer, trusted advisor(standard, advanced 2개버전)

    4)운영 우수성 : Cloud watch

    5)성능 효율성


AWS 리전 표
 > 어떤 리전에서는 제공하는 서비스가 다른 리전에서는 동일 서비스를 제공하지 않을 수 있음.


인프라에 대한 용어 (4가지) -AWS 글로벌 인프라 3가지 기억해야 함.

  > AZ(가용영역) - 사용자 선택,
  1. 리전 - 인프라 위치를 지리적 대표 도시 이름으로 논리적으로 표현한 의미임. ex)서울리전, 도쿄리전, 2개이상의 AZ (총 21개)
  2. 엣지 로케이션 - 리전하고 별도의 시설
     > 리저널 엣지 캐시
     > aws 4가지 기능제공
        Route53 (DNS), Cloud Front (CDN), AWS Shield,  AWS Web Application Firewall(WAF)
=================================================================================

AZ-AZ간 : private link

리전-리전간 : AWS 백본 네트웍 연결

 

Edge location (4가지 서비스 제공)
  >  CloudFront
  > Route53
  > WAF
  > shield

 

Regional edge cache

 > 리전과 edge location 사이쯤에  Regional edge cache 가 있음

 > edge location과 regional edge cache는 선택이 불가함

 

AWS 서비스
1. global

2. Region : S3, DDB
    VPC 내부, VPC 외부에 만드는게 있음.

3. AZ : EC2,EBS,RDS

  > 버킷 속 파일 중간에 디렉토리 만든다고 해서 파일 정보가 디렉토리에 속하지않음
    . 디렉토리+파일 => 키값으로 저장

 

S3 서비스

  > S3 객체 잠금 기능 : 위변조 하지 못하도록 할때 사용

  > S3 - 객체 크기 5TB 제한, 그 외에 제한 없음.
         -  대용량 분속 시 사용 가능
         - 백업 도구로 사용 가능
   > S3 transfer acceleration
      -  cloudFront edge locatiion 사용하여  아마존 네트웍 사용(중간 구간) : 비용발생


snowball- 테라 이동

  > 디스크 box같은 것으로 데이터 배송하여 migration함

 

snowmobile- 페타 이동

  > 컨테이너 트럭 같은 것으로 데이터 migration(트럭으로 이동)


저장후 액세스 안할경우 - S3 galcier 사용이 유리

cloudFront는 S3와 사용하는 것이 좋다(리전과 통신하는 비용 발생하지 않음)


검색을 해야하는 경우는 S3 galcier를 사용하지 않는 것이 좋다.

 

=====================================================

실습1

Amazon S3에 버킷 생성
사용자의 버킷에 콘텐츠 업로드
객체에 대한 액세스 활성화 
웹 사이트 업데이트

============================================================

시험칠때 한국어로 보면 이해 안될때 영문 전환해서 잠깐 볼수 있음
영문으로 신청하면 한글로 못봄
30분 연장신청 가능하여, 신청 전에 30분 연장한 후 신청해야함.
130분=>160분(영문 시험)

solutions architect associate
 > 2018년 8월 이후 신버전으로 변경됨.

비용효율적인 것은?
> 일단 구성은 다 됨.

============================================================

비관리형 서비스
 - EC2에 EBS붙여서 DB설치하여 만들어야 함.


관리형 서비스
 - RDS : 기존 오라클에서 쓰는 기능 중 안되는거 있을 수 있음.
        이 경우 비관리형 서비스를 써야함

 
EC2 생성
 AMI - Amazon Machine Image
     - 사전구축, marketplace, 자체 생성(3가지 경우)
     - 루트볼륨용 텔플릿, 시작권한, 블록 디바이스 매핑(EBS가 대부분,Instance 볼륨이 가능하나 휘발성임)
     - AMI만들면 S3(아마존, 내 계정 S3가 아님)에 저장됨(비용발생)

 

EC2 사용자 데이터는 EC2 생성시 1번만 수행 됨(주의사항)
 - 재기동할때는 수행되지 않음

 

*NAS서비스
EFS  : 공유볼륨 (리눅스) - EC2에 연결(여러 EC2동시 Access, 리전간 공유가능)
  - 가용영역,리전,VP, 계정

FSx : 공유볼륨 (윈도우)
  - 가용영역

  > NFS버전은 4.0만 지원함

 

EC2 요금 옵션
 > 온디맨드 인스턴스 : 사용한 만큼
 > 예약 인스턴스 : 1~3년 미리 예약 (앞보다 70% 저렴)
 > 스팟 블록 : 온디맨드보다 90% 저렴
 > 전용 옵션
   - 전용 인스턴스 : 처음 선점한 사용자가 호스트 사용
   - 전용 호스트 : 호스트가 지정, 호스트 아이디 제공

 

사용자의 인스턴스 추적 : 태그 활용
 > 관리,검색, 필터링 가능
 > 비용 분리 등 관리 용이함
 > 태그 기준으로 패치 적용도 가능함.
 > 운영자에게 꼭 필요함. 정책 만드는게 좋음. 태크 표준 만드는 게 좋음.


amazon RDS 마스터
 > EC2 인스턴스와 연결
 > AZ가 다른 EC2와 연결 가능함.


aurora - serverless 기능 추가
  > 쿼리시에만 비용과금


dynamoDB - 완전 관리형 비관계형 데이터베이스
           이벤트 중심 프로그래밍(서버리스) > lamda 수행
           최상의 수평 확장 기능

         - 글로벌 테이블 : 리전에 테이블 만들면, 다른 리전에 업데이트(복제) 됨
       > 최근에 aurora도지원

     -세션 정보는 dynamoDB 에 저장.(매우 중요, 고속 저장)
     - 임시 데이터

      기본 3개 복제됨(비동기 방식)

   -일관성 옵션
    > 최종 일관성    : 1개에만 쓰여도 읽기 가능(업데이트 되지 않은 정보 읽을 가능성 있음) ->  재 조회시 ....
    > 강력한 일관성 : 3개가 모두 복제가 된 후 읽기 가능

   -s3 와 유사하게 만들어짐. AZ 밖에 구성

 


============================================================================


(((네트웍 구성)))

 

VPC - Virtual Private Cloud
 > 프라이빗 네트워크 공간
 > 워크로드 논리적 격리
 > 액세스 제어 및 보안설정
 > 보안그룹, NACL 설정
 > 가용영역에 걸쳐서 생성
 > 단일 계정에 다중 VPC => 결제 1개
 > 다중 계정 및 다중 VPC => 대규모 조직
 > 계정당 리전당 VPC 5개까지...20개 리전에 총 100개 VPC 생성 가능
 > CIDR 지정

 

subnet
 > subnet 당 5개의 IP주소를 예약하여, 할당하여 사용할 수 없음.
 > 하나의 가용영역에 존재
 > 서브넷당 1개의 라우팅 테이블을 만드는 것을 권장
   . 라우팅 테이블 1개로 여러 서브넷 연결하는 것이 가능하긴 함.

 

인터넷 게이트웨이
 > 관리형 서비스

 

NAT 게이트웨이
 > 관리형 서비스
 > 퍼블릿 서브넷에 생성해야함.

 

NAT 인스턴스
 > 비관리형 서비스


ELB 구성시 웹도 private에 구성해도 됨.


ENI


EIP
 > 리전당 5개 허용
 > 안써도 비용 발생
 > NAT G/W에는 반드시 사용

 

보안그룹
 > 방화벽
 > 인스턴스 레벨에서 설정
 > 상태저장 - 인바운드만 설정

 

NACL
 > 서브넷 경계의 방화벽
 > 모든 인바운드 아웃바운드 허용
 > 상태 비저장 - 인바운드,아웃바운드 모두 설정

보안그룹과 NACL은 certi.에 많이 나옴

intelligent teering
> 날짜가 지나면 자동으로 이동

> access가 적은 데이터는 조금 더 저렴한 스토리지로 이동하여 비용을 줄일 수 있음.


정적 EC2는 S3만으로도 만들 수 있다.(정적 웹사이트)


S3는 무제한 갯수, 용량 (단 1개의 객체 최대 크기만 5테라 제한)

 

EC2 만들때 ID/PW로 접속하는 것을 권장 하지 않음
> keypair이용하여 접근

 

RDS - 수직 확장만 가능

 

DynamoDB- key, value - 비관계형
> 파티션키 : 중복제거 (필수)
> 정렬키:옵션
> 클로벌 테이블 - 여러 리전에 복제

 

multi-aging : standby DB : 작업 시 넘겨놓고 작업

 

ELB
> CLB : Classic
> ALB : application
> NLB : Network

 

VGW(Virtual private G/W) : VPN 연결시 사용
> 속도가 좀 떨어짐, 네트웍도 일정하지 않음
그래서 Aws Direct connet 사용 (1 or 10gbps 사용)


Aws Direct connet : DX로케이션이 있으며, AWS와 전용선 사용
> 고객사에서 DX로케이션까지 연결하면 AWS전용선 사용

> DX 로케이션이 가산센터(?) 인 것 같습니다.

 

VPC는 기본적으로 VPC끼리 격리
> 연결하려면 VPC peering 써야함.
> peering 하려면 사설 IP대역을 다르게 써야함
> 다른 리전간 VPC peering 쓸수 있음.
> 다른 계정의 VPC도 peering 가능
> 전이적 피어링관계는 안됨
A-B간, B-C간 피어링할때 A-C간은 자동으로 안됨
> 다른 VPC의 I-G를 사용하여 외부통신은 할 수 없음.
> VPC피어링 시 라우팅테이블 추가해야함(대상을 VPC피어링 이름으로...)


EndPoint : VPC내 Ec2가 VPC외부에 있는 S3,dynamoDB 연결할때 IGW가 아닌 사설망 형태도 연결하기 위해 사용
> 동일한 리전에서 써야함
> NAT G/W 없어도 S3 연결가능 (중요 포인트)
> 인터페이스 엔드포인트 : 프라이빗 IP가 만들어지며 통신
> 게이트웨이 엔드포인트 : ID가 생성되어 라우팅 테이블에 설정 가능

 

AWS transit Gateway : 여러 VPC와 연결, Direct connect, VPN 등을 연결해주는 허브역할
> VPC간 각각 peering 하지 않고 gateway사용 (매우 중요)


ELB connection Draining
> ELB에서 해시체크 하다가 이상있는 EC2를 제거해야하지만, 기존 사용자들을 위해 기다려주는 기능

ELB는 EC2의 상태확인

 

Route53 : DNS서비스
> ELB의 상태 확인


IAM

사용자: 1. 사용자명,암호 -> console작업
2. 액세스키ID, 비밀액세스키-> CLI,SDK

 

IAM정책은 AWS 서비스에 대한 액세스만 제어함.


정책(Json) 1. 자격증명 기반(대부분 서비스)
2. 리소스 기반 - 몇가지 리소스에만(S3,S3 glacier,KMS) 예)버킷

 

IAM정책은 거부가 우선임

 

정책은 사용자
그룹
역할에 권한부여
> 어플리케이션에는 정책 부여불가

 

역할은 사용자와 서비스에만 정책적용가능
> 사용자에게는 임시 권한을 부여하는 형태임 (로그인 직후엔 권한없음)

 

역할은 스위치다*****
> s3권한이 없던 유저가 역할을 통해 s3 접근 권한을 받으면, s3 접근가능함.
명시적 거부가 우선이지만 이경우는 다름.

 

역할
> 외부 인증 사용자에게 액세스 제공

 

AWS STS : 자격증명 서비스 (service token service)

SAML : SSO같은 기능


AWS Oraganizaions : 정책설정. 통합관리, 결제 통합 관리, 개별 권한 보다 우선함

 

S3 권한 부여(3가지방법)
> 자격증명(IAM)
> 버킷정책
> ACL

 

Auto scaling 방법(3가지)
- 예약 : 시간 정해서 조정
- 모니터링 : 사용율 변화에 따라 조정
- 예측 (서울리전에는 없음) : 머신러닝을 통해 예측해서 조정


===========================================

시험에 관한 FAQ :
http://bit.ly/aws-study-resource

 

acloud.guru : 교육 사이트

 > discussion에서 tip 보면 좋음 , 7일 무료

==========================================

 

* AWS 클라우드 장점

  - 자본비용을가변비용으로대체: 데이터센터와서버에 대규모의투자대신 사용한만큼만 비용을 지불 

  - 규모의경제로얻게되는이점: CSP는 많은 사용자들로 더높은 규모의 경제 달성으로 사용량에 따른요금이 더낮아져서, 
                                        인프라를 소유할때보다 가변비용이낮다. 

  - 용량추정 불필요: 필요한만큼의 리소스에 액세스하고 필요에 따라 몇분만에 확장또는축소 할수있어서 과투자 예방  

  - 속도및민첩성개선: 개발자는 해당리소스를 몇주가아니라 단몇분만에 사용할 수 있어서 실험및개발에드는 비용절감과
                            시간이 단축되므로, 조직의 민첩성이 크게향상됨 

  - 데이터센터 운영 및 유지관리에 비용투자 불필요: 수많은 서버를 관리하느라 시간을 단축 고객에게더욱집중 가능.

  - 몇분만에 전세계에 배포: 짧은 시간내 전세계에 애플리케이션을 손쉽게 배포, 고객에게 더짧은 지연시간과 더나은 경험을 제공 (DR센터로 손쉽게 이용가능 - Data Replication은 필요)

*AWS 서비스 관리주체에 따른구분 
  1.비관리형-사용자가 직접 모든관리, AWS 관리안함 : EC2

  2.관리형
     - 일반관리형-사용자가 일부관리, AWS 일부관리 : EIP, Elasticsearch Service, DynamoDB(NoSQL), 
                                                                     RDS(RDB)-자동백업(replica),이중화,인스턴스확장

     - 완전관리형-사용자 관리안함, AWS가 모든관리 : ELB, S3, Route53, Elastic Beanstalk, Aurora

 

* AWS 서비스 Scope

  1.Global : Route53, CloudFront, WAF, Shiled, IAM

  2.Region : EF, S3(버켓이름은 Global하게 unique해야함), VPC, EKS

  3.AZ : EC2, EBS, RDS(EC2기반 서버구성), Subnet, Routing Table

 

* EBS(SAN/DAS), EFS(NAS: NFS 기반의 관리형서비스-서버level은 AWS관보)

  보안그룹 : EC2구성시 EC2에 반드시 적용, Network ACL : Network 방화벽

  Elastic Beanstalk : Docker 컨테이너(OS+Platform)를 기반으로 애플리케이션을 쉽게 배포, 운영, 관리를 도와주는 서비스
                                (서비스 사용료x, 리소스 사용료O)
                 →애플리케이션을 업로드하기만 하면 용량 프로비저닝, 로드 밸런싱, 조정, 오토스케일링, 애플리케이션
                    상태 모니터링에 대한 세부 정보를 자동으로 처리(예: AutoScale시 자동으로 in/out 해줌) 

Beanstalk 구성도 - Amazon SQS를 이용한 메세지기반 백그라운드에서 처리하는 특수 애플리케이션을 구성할 때 사용(내결함성 강화)

* 엣지로케이션 

  - End User의 지연시간을 줄이고 성능을 향상하고 보안을 위해 구성한 로컬지점(AZ간 고속Network구성)

  → Route53(DNS), CloudFront(CDN), WAF(Firewall), Shield(DDoS완화)

 

* 리전(2개 이상의 AZ로 구성, 다른 AZ의 장애와 격리) 선택 기준

  1. compliance
    - 지역마다 법에 따라 서비스가 안되는 경우가 있음

  2. 지연시간
    - 가능한 가까운 곳을 선택

  3. 서비스 유무
    - 모든 리전에 모든 서비스가 있는것이 아님.

  4. 서비스 가격
    - 리전마다 가격이 다름

 

* EC2 태그 기준으로 과금 상태 확인이 가능함 (초단위 종량제 요금)
  - 태그하지 않을 경우 EC2 전체에 대한 비용만 표시됨.

 

* AMI = OS 이미지 + α  : α - S/W 인 경우가 대부분임.
  - template AMI : 아마존에서 제공
  - Golden Image 를 사용자가 만들 수 도 있음.
    ▶ t2.micro (AMI 이미지 이름에 대한 설명)
      > t-family
      > 2-generation
      > micro- scale


* EC2
 - 전용 인스턴스 : 한대의 기계를 나만 쓰지만 기계가 정해져 있지 않음
 - 전용 호스트 : 기계를 나만 쓰고 기계가 정해져 있음


* VPC
 > 기본적으로 public에 연결되지 않음, 격리된 프라이빗 가상 네트웍
 

※ 버킷 이름은 유니크 해야함 : 교차 리전 지원


<리소스 접근 제어 정책>
1. 사용자 기반
  > IAM

2. 리소스 기반


* S3에서 사용하던 데이터를 백업할 경우 glacier 사용
 > 자주 엑세스 하지 않는 데이터에 최적, 검색시간이 오래 걸림


* S3는 S3에서 송신한 데이터를 기준으로 전송 비용 과금
 > cloudfront (CDN) 와 연결해서 사용할 수 있음.


* EBS는 용량 제한 있음(16테라)
 > 반드시 EC2에 마운트해야함
 > 스냅샷을 뜨면 S3에 저장
 > EC2 제거시 스냅샷은 삭제가 안되므로, 잘 확인해야함.

 

 

* EBS
 > SSD
  . gp2 (범용SSD)- 1GB당 3 IOPS : IOPS확보를 위해 용량을 늘려야함
  . io1 (프로비저닝) - IOPS지정가능

 

*EC2 인스턴스 스토리지
 > 로컬 직접 연결된 스토리지
 > 속도 빠름
 > 지속성 없고, 휘발성 스토리지 -> 다른 하드웨어에서 EC2가 기동될 수 있어서 데이터를 가져갈 수 없음.

 

* 인증방법
   1. user 계정/ password
     ->  AWS management console
   2. access key ID
      secret access key
       -> CLI,API
   3. key pair -> EC2 ssh

 

<서버 scaling 방법>

1.scale up/down -> 수직적

2.scale out/in -> 수평적

http://bit.ly/TESSLAB

 

 

* dynamo DB
 > 프로비저닝된 처리용량 지정
  . WCU : 1KB단위
  . RCU : 4KB단위

 

 

Region > VPC > AZ > Subnet > EC2 

 - Region : 지역 (ex. 서울, 도쿄, etc)

 - VPC(Virtual Private Cloud) : 논리적 IDC (하나 or 여러개의 물리적 IDC 그룹)

 - AZ(Avaliability Zones) : 물리적 IDC (물리적 격리)

 - Subnet : 네트워크 분할 (ex. Public or Private Subnet)

 - EC2(Elastic Computing Cloud) : Computing Instance (Server)

 

 - VPC Router : 다른 Subnet 간에 통신이 가능하게 설정 (Routing Table 설정)

 - Internet Gateway(IGW) : 원하는 Subnet을 외부(인터넷) 통신이 되도록 설정(양방향)

 - NAT Gateway : Private Subnet 에서 Public Subnet을 통한 외부 통신(단방향)

 

 - ELB(Elastic Load Balancer) : Application(HTTP, HTTPS) LB, Network(TC) LB

 - Auto-Scaling : Scale In/Out 자동화

 - CloudWatch : Application/Resource 모니터링/알림

 

 - Security Group : Instance 단위 (Firewall, All-deny)

 - Network ACL : Subnet 단위 (All-allow)

 

 

[구성 예제]

 - 10.10.0.0/16 (B 클래스 대역)의 가상 네트워크(VPC)를 서울 Region(ap-northeast-2)에 생성

 - AZ1(ap-northeast-2a)에 Sbnet 2개(Public:1, Private:1), AZ2(ap-northeast-2c)에 Subnet2개 생성(Public:1, Private:1)

 - EC2(Subnet당 1개) 생성

 - IGW(외부통신 목적) 생성

 - VPC Router 설정 : route table 을 생성 -> 외부 통신을 위한 public-subnet-01/02에 route table assign

                           -> public route table의 traffic을 IGW로 가도록 설정

 

공식 AWS 아이콘 (https://aws.amazon.com/ko/architecture/icons/)

* AWS  : https://docs.aws.amazon.com
* Azure : https://docs.microsoft.com/en-us/learn/
            https://www.microsoft.com/handsonlabs
* GCP   : https://cloud.google.com/docs/

 

+ Recent posts