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

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/)

VMC의 대략적인 내용과 서버/스토리지 부분만 정리하였으며, VMWare Cloud on AWS 는 워낙 이름이 길어서 이제부터는 VMC로 약칭 하겠습니다.

개념만큼은 중복되더라도 다시 언급드립니다. AWS의 베어메탈 호스트에 VMWare를 설치하고, 그 위에 VM을 생성하여 사용한다는

컨셉입니다. 따라서, VMC 상에서 만들어지는 VM은 EC2 인스턴스가 아닙니다. 비용 역시 VMWare Host 가 기준입니다. VMC의 VM을

AWS로 이동시키려면 On-Premise 에서의 마이그레이션과 마찬가지로 AMI 로 변환하였다가 EC2로 생성하는 과정이 필요합니다.

 

아직 한국 리전에는 없다고 하는데, 장표상으로는 올해 2분기에 오픈 예정이라고 합니다. 그래서 요즘 한창 세미나와 교육 지원을 해 주는 것 같습니다.

 

 

괜찮은 점은, vSphere 를 통해 On-Premise 의 VMWare와 AWS 상의 VMC를 함께 관리할 수 있다는 점입니다. 위의 그림에 vCenter 가 2개 보이는데, 하나는 On-Premise에, 하나는 AWS에 있는 vCenter 입니다. 서로 VM을 이동시킬 수도 있습니다.

 

 

AWS의 IaaS와 결정적으로 다른 것은, AWS의 EBS와 VPC 등도 관리할 필요가 없는 것입니다. 그냥 로컬 데이터센터의 VMWare 를 관리하는 것처럼, VMWare Horizon 에서 디스크나 네트웍을 만들에서 사용할 수 있습니다.

 

 

또한, AWS 의 VPC 와 연결하여, AWS의 EC2, RDS, S3 등과 연계하여 사용하는 것도 가능합니다.(VMC에서 적절한 네트웍 구성은 필요) 기존의 S/W 라이센스를 사용해야 넘들은 VMC로, 안그런 넘들은 EC2로, 리팩토링이 가능하면 RDS나 S3 등으로, 이런 식으로 아키텍처 구성이 가능합니다.

 

 

On Premise 서버들이 VM으로 되어 있다면, DR 센터를 AWS에 구성하는 방법 중 VMC를 사용하는 게 가장 간편해 보입니다. AMI 로 변환할 필요도 없고, 동기화도 해 줍니다.

 

 

On-Premise 와 AWS의 VMC를 통합해 주는 HCX 라는 것도 핫(Hot)한 제품인데, 대충 그림 보고 이해하시면 됩니다. 이 서비스에 대한 내용은 별첨 마지막 슬라이드에 자세히 소개되어 있으니 참고하시기 바랍니다.

 

 

VMC는 AWS에서 사는(?) 서비스가 아니라, VMWare 에서 사는 서비스입니다. VMC 의 VM을 사용하는 비용은 AWS가 아닌 VMWare 에 내는 것입니다. 최소 4개 Host 서버로 구성된 환경부터 판매한다고 합니다.

 

 

VMC의 인프라 구성에 대한 슬라이드들입니다. AWS에서 제공하는 강력한 파워의 베어메탈 EC2를 사용한다는 내용입니다.(i3.16XL)

 

 

VM 아래에는 당연히 여러 대의 Host 서버(베어메탈 EC2)가 있고, DRS로 클러스터링 되어 있겠지만, 이러한 아키텍처에 대해 사용자는 전혀 신경쓰지 않고 사용할 수 있다는 내용입니다.

 

 

용량이 딸려서(?) Host를 추가해 달라고 요청하면, VMWare에서 알아서 클러스터 내에 호스트를 추가합니다. 네트웍이니 SAN 구성이니 고객이 고민할 것이 하나도 없습니다.

 

 

Host 서버에 장애가 나도 사용자는 알 필요도, 알 수도 없습니다. VMWare 에서 알아서 교체해 줍니다.

 

 

심지어는 사용량에 따른 Auto Scaling 기능도 있다네요.

 

 

 Affinity - Anti-Affinity 기능으로 특정 Host에 특정 VM이 탑재되거나, 탑재되지 않도록 할 수도 있다고 합니다.

 

 

멀티 가용 영역으로 구성할 수도 있는데, 단순한 분산 배치의 개념이 아니고 복제의 개념인 것 같습니다. 당연히 옵션이겠죠.

 

 

 

 스토리지에 대한 내용입니다. 고성능의 NVMe, SSD를 사용한다는 슬라이드입니다.

 

 

VMC 의 모든 스토리지는 암호화 되어 있다고 하네요.

 

 

 데이터의 중요성과 요구되는 성능에 따라 RAID 수준을 정해서 사용할 수도 있습니다.

 

 

 글씨가 작아 잘 보일런지 모르겠지만, RAID-1 을 선택한 Data 입니다.

 

 

 따로 RAID-5 정책을 선택한 스토리지가 있다면 요런식으로 데이터가 저장된답니다.

 

 

RAID-5 와 RAID-6 를 혼용했을 때의 그림입니다.

 

 

 너무나 당연한(?) 내용이지만, 디스크가 깨지면 VMWare에서 알아서 갈겠다. 고객은 쓰기만 해라, 이거죠.

 

 

 

스토리지의 확장도 간편합니다. 늘여달라고만 하고 돈만 내면, 알아서 늘여줍니다.

 

 

 

가용 영역 장애에 대비한 스토리지 구성이라고 합니다. 돈은 두배로 들겠지만요.

 

 

 AWS의 EBS를 뒷단에 달아서 스토리지로 사용할 수 있는 Elastic vSAN 이라는 서비스도 출시되었다는데, 실제 VMC도 사용해 보지 않았는데 여기까지 잘 알고 있을 필요는 없을 것 같습니다.

 

 

다만 문서상으로는 대용량(35TB)이면서 높은 성능을 요구하지 않으면 고려해 볼 만하다고 하네요.(DW, 배치, DR 등)

 

VMWARE가 AWS의 퍼블릭 클라우드 인프라를 이용하여 vSphere, VSAN,NSX의 VMware 환경을
구축할 수 있는 VMware Cloud on AWS(VMC) 서비스 제공한다고 합니다.


이 VMware Cloud on AWS는 AWS의 베어메탈을 이용한 네이티브 가상화 인프라 서비스로 100% VMware사에 의해
관리되는 관리형 서비스라고 하네요.

 

 

일전에 제가 AWS "기술 에센셜" 정리한 내용 중에 AWS의 "전용 호스트 방식의 EC2 서비스" 를 기억 하시나요?
전용 호스트방식으로 AWS로 부터 호스트를 할당받아 VMware Clound on AWS를 제공하는 것 같습니다.

 

 

이용자는 AWS의 원하는 리전에 vCenter를 포함한 vSphere 환경을 구축이 가능하며, AWS상에 설치한 vCenter를
통해 온프레미스의 vSphere 환경을 관리할 수 있습니다. 온프레미스와 AWS상의 vSphere 사이의 Vmotion도 가능하며,
온프레미스의 라이선스를 VMC용으로 이용할 수 도 있다고 합니다.


호스트가 고정이되므로, 온프레미스의 라이선스를 활용할 수 있는 부분은 대단한 장점인것 같습니다.

 

실습 자료는 아래 url 참고하시면 될 것 같습니다.

https://vmc-field-team.github.io/

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


https://brunch.co.kr/@topasvga/1



http://cloud.hosting.kr/techblog_180209_startupkit/


VPC란 무엇인가?

https://docs.aws.amazon.com/ko_kr/AmazonVPC/latest/UserGuide/VPC_Introduction.html

+ Recent posts