블라베의 취향편지

https://co-no.tistory.com/entry/Linux-CentOS7-%EC%97%90%EC%84%9C-User-%EC%83%9D%EC%84%B1useradd%EA%B3%BC-User-%ED%99%88-%EB%94%94%EB%A0%89%ED%86%A0%EB%A6%AC-%EC%84%A4%EC%A0%95

https://wooono.tistory.com/371

AWS Account의 운영 업무를 맡게된 당신에게 ~

Hi OkMan,

이번에 AWS 클라우드 운영 업무를 맡아 취업하게 된 걸 축하해. 
앞으로 학교 학원에서 배운 것 이상의 다양한 환경을 마주하게 될테니 AWS Document와 더더욱 친하게 지내길 바래.
그렇다고 AWS Document 만 너무 맹신하지 말길 바래. AWS는 기능 변경이 자주 있어서 Document가 바뀐 기능을 따라가지 못하는 경우가 많아. Document에서 본 화면과 실제 접속한 Console의 메뉴 배치나 기능이 약간씩 다른 경우가 아주 많으니까 놀라지 말고, 필요한 기능은 꼭 테스트를 해본 뒤에 사용하는 것을 추천한다.

이제 회사에서 사용하는 여러개의 AWS Account의 운영 업무를 맡게 됬으니, 여러 Account의 Console을 로그인 로그아웃하면서 환경을 바꿔가면서 일을 하는게 여간 번거로운게 아닐거야.
만일, AWS Account가 두세개 정도라면 몇가지 웹브라우저(크롬, 파이어폭스, 아파치, 엣지 등)을 동시에 열어놓고, 각각 다른 Account의 Console을 로그인해두고 사용하면 되겠지.
하지만, Account 갯수가 그 보다 더 많다면 그렇게 작업하긴 곤란하겠지. 회사에 프로젝트는 여러개인데 AWS 운영자는 그보다 수가 적은게 보통이니까, 운영자 한명당 맡게 되는 AWS Account가 십여개씩 되는 건 일반적인 상황일걸.
그런 환경에서 이쪽 저쪽 Account를 옮겨다니면서 작업하는 불편을 덜어줄 수 있는 AWS 의 Switch Role을 소개해볼게.
 
SwitchRole의 기본개념은 Gateway 개념과 유사해.
먼저, 내가 주로 사용할 AWS Account를 하나를 정해야되. 일명 Gateway Acoount라고 부를게.
그리고, 관리해야할 여러개의 AWS Account들에서 위의 Gateway Account의 Console Access 권한을 허용해주는거야.
그러면, Gateway Account에만 로그인한 상태로 SwitchRole 기능을 이용해서 별도의 로그인 없이 
한번의 클릭만으로 다른 AWS Account의 Console을 접속할 수 있어.

그러면, SwitchRole을 사용하기 위한 환경 설정을 해볼게.

우선, 테스트할 환경을 소개하지.
AWS Account 두개 또는 세개를 준비해.
 AWS Account ID는 12자리 숫자로 되어있지. 여기선 별칭으로 A, B, C라고 할게.
  - AWS Account ID "A" (1111 1111 1111)   
  - AWS Account ID "B" (2222 2222 2222)   
  - AWS Account ID "C" (3333 3333 3333)

 위 ID 중에서 Account A를 Gateway 역할로 사용할게.
 그리고, 관리할 대상은 Account B와 C라고 할게.
 
그럼 이제부터 설정을 시작할거야.
 

Chapter 1. AWS Account "A" 콘솔에서 설정할 내용

 1.1) create an IAM user

    웹브라우저(예:크롬)에서 AWS Account ID "A"로 AWS Management Console에 로그인한다. 
    IAM 메뉴에서 AWS Switch Role (역할전환)에 사용할 IAM user 를 원하는 이름으로 만든다.

    내 경우에는  IAM user 를'maestro'라는 이름으로 만들었다.
    root Account를 그대로 이용할 수도 있겠지만, 
    user별 역할 분리와 보안성 강화를 위해서는 SwitchRole에 사용할 IAM user 를 이용하고,
    콘솔 로그인 옵션에 MFA(멀티 팩터 인증)을 추가할 것을 권장한다.
    물론, 기존에 사용하던 IAM user가 있다면 그대로 이용해도 관계는 없다.

    IAM user 만드는 방법과 MFA 설정하는 방법은 다른 문서를 참고하길 바란다.
    이제 Account A 콘솔에서는 더 이상 설정할 것이 없다.
  

Chapter 2. AWS Account "B"콘솔에서 설정할 내용 

 2.1) create a role for allow IAM user 'maestro' of Account "A"

    이번 작업은 다른 웹브라우저(예:파이어폭스)를 이용하는게 편할 것이다. 
    Account ID B의  AWS Management Console에 접속할 Account ID A의 maestro user를 위한 권한을 허용하는 Role을 설정을 하자.

    Account ID B의  AWS Management Console에 로그인하고, IAM 메뉴에서 아래와 깉이 역할(Role)을 하나 만든다.

    ---------------------------------------------------------------------------------------------------------------------------------
    Role Name : switchrole-maestro-of-A-to-B

    Step 1. Select trusted entity
     - Trusted entity type : select "AWS account"
     - An AWS account
       > select "Another AWS account"
       > Account id [ 111111111111 ] <-- 여기엔 AWS Account A의 ID 번호 12자리 숫자를 입력해.
       > Options : select "Require MFA"   

Step 2. Add permissions
 - Permissions policies
   . select "AdministratorAccess"
   여기에서는 maestro user에게 허용할 권한을 필요한 만큼 설정해주면 된다.
   이 예제에서는 쉬운 설명을 위해 full access 권한인 AdministratorAccess를 선택하였는데,
   실제 적용할 때는 user가 하는 일과 역할에 맞게 권한을 나눠서 주는것을 검토해보길 바래.

Step 3. Name, review, and create

   처음 계획했던 Role name을 입력하고,  필요한 tag를 추가하고,  [Create role] 버튼을 클릭하여 작업을 완료한다.
   이 단계에서는 Trust policy를 수정하지 말고, 이후에 policy를 완성한 후 필요한 부분을 수정하는 것을 추천한다.

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

그러면, 역할(Role)이 아래와 같이 만들어졌어.

 2.2) Edit  role 

    위 1)과 같이 역할(Role)을 만든 후 신뢰관계(Trust relationships) 의 JSON 코드를 보면 root 계정을 기준으로 설정이 되어있다. 
처음 계획했던 대로 AWS Account "A"의 'maestro' user에게만 권한을 주기 위해 신뢰할 수 있는 엔터티(Trusted entities)의 Principal 부분의 내용을 이렇게 수정한다.

(before) "arn:aws:iam::111111111111/root"
(after)    "arn:aws:iam::111111111111:user/maestro"

 * 변경 후의 JSON code

이렇게 하면 AWS Account ID "B"에서 설정을 마쳤다.

* AWS Account ID "C"의 콘솔에서도 이 chapter 2의 내용과 동일하게 설정해주면 되므로, AWS Account ID "C"의 콘솔에서 설정할 내용은 생략한다.

Chapter 3. switchrole 링크 만들기 

이제, AWS Management Console에 Account ID A의 maestro user로 로그인했을 때,
Account ID B와 C의 콘솔로 연결되는 switchrole 링크를 만들어야 한다.

 3.1) Account ID A의 maestro user에서 역할전환(SwitchRole) 정보 등록하기

AWS Management Console에 Account ID A의 maestro user로 로그인하고,
Console 우측 상단의 "maestro" id를 클릭하면 역할전환(SwitchRole) 버튼이 보일것이다.

역할전환(SwitchRole) 버튼을 클릭하고, Account B 와 C에서 설정했던 Role 정보를 등록해주면 된다.

a. Account B(222222222222)에 만들었던 Role 정보를 등록한다 
   [Switch Role]
   Account ID : 222222222222
   IAM role name : switchrole-maestro-of-A-to-B
   Display name (optional) : maestro-of-A-to-B
   Display color (optional) : Red 
   내용 입력하고 [Switch Role] 버튼을 클릭한다.

b. Account C(333333333333)에 만들었던 Role 정보를 등록한다 
   [Switch Role]
   Account ID : 333333333333
   IAM role name : switchrole-maestro-of-A-to-C
   Display name (optional) : maestro-of-A-to-C
   Display color (optional) : Orange
   내용 입력하고 [Switch Role] 버튼을 클릭한다.

 3.2) 역할전환(SwitchRole) 링크를 클릭하여 다른 계정의 콘솔에 접속하기 

이제, WS Management Console에 Account ID A의 maestro user로 로그인하고,
Console 우측 상단의 "maestro" id를 클릭하면 역할전환(SwitchRole) 버튼 위쪽에 B와 C로 이동하는 링크가 보일 것이다. 

[maestro-of-A-to-B] 링크를 클릭하면 Account B의 Console로 접속이 된다.

ID를 클릭하면 [다시 전환] 이라는 버튼이 표시되며, 이것은 Account ID A의 maestro 의 Console로 다시 돌아갈 때 사용하는 링크이다.

정리하면,

 이제부터는 새로운 AWS 클라우드 계정을 만들 때마다 위와 같이 역할전환 설정을 해두면 되고, 
 클라우드 운영업무를 할 때는, Account ID A의 maestro user로 콘솔 로그인한 뒤, 관리할 계정으로 역할전환하면 된다.
 
그럼 오늘도 Good Luck 하길 ~
 

AWS SAA 시험 합격 후기

회사가 AWS 파트너쉽 자격 유지를 위해 직원들이 일정 갯수 이상 자격증을 보유해야되서, 업무에도 필요하니 겸사겸사 자격증을 취득하게 됬다.

다음 공부때도 참고하고, SAA 자격증에 도전하는 분들에게 쬐끔이나마 도움이 될까하여 후기를 적어본다.

  
자격증 종류와 차이점

  참고: https://aws.amazon.com/ko/certification/
  모든 시험은 선수 과정이 없이 임의로 지원할 수 있다. 즉, Professional이든 Speciality 이든 한번에 도전할 수 있다는 것.
  
   1) 기초 등급 : Cloud Practitioner : 기초과정, 온라인 무료 학습만으로도 시험 패스 할 수 있는 입문자용 시험 
   2) Associate 등급 : SAA, DA, SOAA 등 : 1년 정도의 경험을 요구한다
   3) Professional 등급 : SAP, DOPE 등 : 2년 이상의 경험 
   4) Speciality 등급 : 특정 전문 분야, Networking, Data Analytics, Database 등 
   

SAA 시험에 대한 이해 

  참고자료: https://aws.amazon.com/ko/certification/certified-solutions-architect-associate/
  위 사이트에 있는 '시험가이드' 문서를  읽고, 이 시험이 요구하는 지식과 기술 배경을 파악하는 것이 중요하다.
  특히, '시험가이드' 문서 하단의 '부록'에 서비스 및 기능 목록이 시험 범위가 된다.
  
  SAA의 시험 수준은 최소 1년 이상의 실무 경험자가 할 수 있는 Architecture 지식을 기준으로 한다.
  하지만, 1~2년 실무 경험자라고 하더라도, 여기에 나열된 지식과 기술 경험을 모두 갖추는 것은 거의 불가능에 가깝다.
  경험하지 못한 나머지 부분은 이론과 실습으로 채울 수 밖에 없다.
  그리고, 이것은 객관식 이론 시험이기 때문에 실무 경험이 적거나, 이론 학습만으로도 자격취득을 할 수 있다.
  

  
학습 방법

  AWS 실무 경험이 부족하다면, 문서나 시험문제를 먼저 보지 말고, 기본적인 AWS 서비스를 직접 체험해보는 것이 좋다.
  유튜브 또는 인강을 활욯하여 AWS 기초 과정을 학습하고, 실습해보면서, AWS의 주요 기술의 구현 방법과 AWS 콘솔의 주요 용어들을 체득한다.
  시험 범위의 서비스들에 대해서, 기본 개념, AWS 콘솔 설정 화면에 나오는 필수 용어들을 이해하고 Architecture를 설명할 수 있는 정도를 목표로 한다. 
  추천하는 강의는 Udemy 사이트에 리뷰 많은 SAA 강의 과정을 고르거나, 한국어 강의를 듣고 싶다면 인프런(Inflearn) 사이트에 SAA 강의가 간결하고 알차게 되어 있다.
  
  

  1) 인강 듣기

   SAA 수준의 강의는 유튜브에도 있고, 인프런 같은 인강에도 가성비 좋은 SAA 강의가 나와있다.
   한가지를 선정하여 1회 학습하여 시험의 범위를 완강한다.
   내 경우에는, 2~3회 돌려보면서 나만의 요약 노트를 만들고, 모르는 용어나 설명을 추가적으로 보완하였다.
 

  2) 인강 보충 자료는 AWS 콘솔과 AWS Document를 활용 

    인강을 보면서, AWS 콘솔로 설정하는 화면을 직접 보고, 설정하는 화면에 표시되는 기능과 옵션들을 이해하려고 노력했다.
비용때문에 최종 실행까지는 하지 않았다.
하지만, 약간의 실습이라도  화면구성과 용어, 옵션 기능들을 실제로 보니 개념과 동작을 이해하고 느끼는데 도움이 됬다.
그리고, 인강에서 모르는 용어가 나오거나,콘솔 화면에 표시되는 기능과 옵션의 설명은 AWS Document를 활용했다.

    AWS Document는 분량이 방대하고, SAA 수준에서 필요없는 디테일한 설명이 많다.
이 자료에서는, 기본 개념, 동작원리, 사용방법(콘솔,CLI,API), 모범사례, 모니터링 항목 정도만 참고로 했다.

    AWS 자료 찾는 방법은, 예를 들어, "dynamodb 란 무엇인가" 이렇게 구글링하면 대부분 최상단에
   https://docs.aws.amazon.com › latest › Introduction
   What is Amazon DynamoDB? - 작동 방식
   ...
이렇게 검색되는 AWS Document를 참고했다.
 
실제 시험 문제에, 서비스의 옵션에 대한 이해를 요구하는 문제가 출제된다.
    예를 들면, '인스턴스 배치 그룹'의 종류 중에 가장 고성능인 것을 고르거나, 가장 고가용성인 것을 고르는 문제가 나온다.
인스턴스 배치 그룹의 옵션은,
      - 클러스터 : 근접네트워크, 짧은 지연시간, 고속
      - 파티션 : 다른 랙의 여러 하드웨어를 그룹화 , 서버 장애 영향적음, 하둡 등 분산처리용
      - 분산형 : 같은 랙의 서버를 그룹화, 서버랙 장애 영향 적음, 안전 고가용성 목적
~으로 정리할 수 있다.
 

  3) 연습문제 풀기

    내 경우엔 인강 뒤의 모의고사 10회와 구글링으로 찾은 SAA Dump문제를 포함하여 약 1000문제 정도를 소화했다.
   문제를 풀고, 오답 체크하면서 부족한 부분은 AWS Document를 다시 확인했고, 내 요약노트를 업데이트했다.

    '인프런' 인강의 SAA 강의 뒷부분에 나오는 400문제 정도를 풀고 학습이 되고 나서부터는 반복되는 문제와 패턴들이 보이기 시작했다.
   간단한 문제는 질문의 핵심 단어와 답을 빠르게 연결 할 수 있었다.
   구글링해서 찾은 SAA 한글 Dump 블로그 자료(블로그 링크 여기 "SAA-02 덤프 풀이 by 바교망")도 많은 도움이 됬다.
       - 좋은 자료를 공개해주셔서 감사드립니다 -

 여기서 추가로   500~600문제를 소화하면서 점수가 커트라인 72% 수준으로 나오기 시작했다.
  1000문제 정도를 소화한 후에는 오답문제만 모아서 다시 풀기를 했다.
   문제 풀이는 충분히 많이 푸는 것이 확실히 도움이 됬다. 실제 시험에도 상당히 유사하거나 거의 같은 문제가 많이 나왔다.

  4) 두개의 요약노트

   a. 첫번째 노트는, 인강 노트

인강 강의 순서+ 시험 가이드의 '목록' 순으로 노트를 만들어서
각 서비스의 개념 이해와 중요 기능 및 옵션 설명과 차이점을 정리했다
연습문제에서 보충되는 자료를 계속 추가하였고,
연습문제 2-3회를 푼 다음에 인강 노트 리뷰를 한번씩 했다.

   b. 두번째 노트는, 기능 비교 노트 
    유사한 용어가 나오는 서비스와 기능들을 따로 묶어서 비교 노트를 만들었다.
예를 들면, 
  서버리스 종류와 차이점은? Lambda, Fargate, S3, DynamoDB, aurora-serverless, SNS, SQS, API Gateway ...
  응답 시간 비교 ? : 마이크로 초=DAX, 밀리 초=DynamoDB, RDS, ElastiCache ...
  네트워크 보안 서비스 종류와 차이점은?  SecurityGroup, NACL, WAF, AWS Shield ...
  감사 모니터링 종류와 차이점은? CloudWatch, Cloudtrail, Config, GuardDuty,...
  ACL 기능이 있는 서비스는? NACL, RDS, ...
  Global Routing 지원하는 서비스는? CloudFront, Global Accelerator
  S3와 Glacier의 종류별 비용 차이점
     등등

    연습문제 dump를 풀면서, 기능 비교 노트를 만든 것이 문제 풀때 많은 도움이 됬다.  
 

시험시 주의사항

 시험장 선택 PSI와 PearsonVUE
  시험 방법은 PSI와 PearsonVUE 두가지가 있는데, 
  PSI는 시험장에 방문하여 시험장의 컴퓨터로 시험을 보는 것이고,
  PearsonVUE는 내 방에서 혼자 내 컴퓨터로 시험을 보는 것이다.
  PSI 방식이 가장 안전한 방법이다.
  PearsonVUE는 웹캠과 마이크를 이용해 감독관과 영어 또는 일본어로 소통하면서 
  시험장소와 내 컴퓨터가 시험에 적합한지 확인을 하는 과정을 거쳐야 하는데, 영어 또는 일본어에 아주 익숙하지 않다면 추천하고 싶지 않다.
  내 경우엔 PearsonVUE로 시험을 봤는데, 감독관이 남아시아계 영어를 써서 리스닝에 어려움이 많았고 나 또한 영어에 능통하지 않아서 
  시험 전 단계에서 에너지 소모가 심했다. 다음엔 시험장에 가서 시험을 보려한다.

 복수 답안 문제를 놓치지 않게 주의한다
 시험편의 지원요청 - 비영어권 지원자는 시험 시가을 30분 더 제공 받을 수 있다, 연습문제를 충분히 풀었다면 시험 시간은 부족하지 않을테지만, 혜택이니 시험 예약하기 전에 미리 신청해둔다.
 

그럼, 다음 시험은 Professional에 도전해보자 홧팅.

AWS 다른 계정으로 버킷 복제 설정하기

여러개의 AWS 계정들에서 생성되는 Cloudtrail 로그를 대표AWS 계정 한곳으로 모아서 통합 로그 분석을 해보기 위해서
 각 AWS 계정의 Cloudtrail이 저장되는 S3 버킷을 대표계정의 버킷으로 복제하는 작업을 해봤습니다.

통합 로그 분석은 따로 다루겠습니다
 
 여기에서는, CloudTrail을 설정하면서 남겨지는 로그를 다른 AWS계정으로 복제하는 과정만 진행해봅니다.

account-1 계정의 bucket-a 에서, account-2 계정의 bucket-b로 복제해보겠습니다.
 
 작업 순서는,
 Cloudtrail 설정, S3 bucket 설정, IAM 역할 및 정책 설정, S3 복제규칙 설정, 복사테스트 순으로 진행합니다.
 

  0. 실습 준비

 AWS 계정 두개
  : account-1  (ID 000000000001 가칭)
  : account-2  (ID 000000000002 가칭) 

1. account-1에서, cloudtrail 생성시 추적 설정하면서 새 버킷을 생성 

추적명 : cloudtrail-account-1
스토리지 위치 : account-1-bucket-a 새버킷생성
추적 로그 위치 : bucket-a/AWSLogs/000000000001
옵션
다중리전추적:예
로그파일암호화:비활성화
로그파일검증:활성화
SNS알림:비활성화
Cloudwatch Log 활성화 

2. account-2에서, s3 bucket account-2-bucket-b 생성 

버킷명: account-2-bucket-b
버킷 옵션
퍼블릭 액세스 - 모든 퍼블릭 액세스 차단 - 활성화
버킷 버전 관리 - 활성화
암호화 - 비활성화  (활성화 사용시 KMS 연동 필요)
객체 소유권 - 버킷 소유자 적용
ACL적용안함

3. IAM 역할 및 정책 생성

 1) account-1에서, IAM 정책(Policy) 생성 
   - 버킷에 Replicate 관련 작업의 권한을 정의 
 
정책이름 : s3-replicate-policy-from-bucket-a-to-b  (임의의 이름)
  
정책 json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "s3:ListBucket",
                "s3:GetReplicationConfiguration",
                "s3:GetObjectVersionForReplication",
                "s3:GetObjectVersionAcl",
                "s3:GetObjectVersionTagging",
                "s3:GetObjectRetention",
                "s3:GetObjectLegalHold"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::account-1-bucket-a",
                "arn:aws:s3:::account-1-bucket-a/*",
                "arn:aws:s3:::account-2-bucket-b",
                "arn:aws:s3:::account-2-bucket-b/*"
            ]
        },
        {
            "Action": [
                "s3:ReplicateObject",
                "s3:ReplicateDelete",
                "s3:ReplicateTags",
                "s3:ObjectOwnerOverrideToBucketOwner"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::account-1-bucket-a/*",
                "arn:aws:s3:::account-2-bucket-b/*"
            ]
        }
    ]
}
 
 2) account-1에서, IAM 역할(role) 생성 
   - S3를 위 정책과 연결 
    대상 리소스 : s3 선택 
역할이름:  s3-replicate-role-from-bucket-a-to-b (임의의 이름)
연결 정책 : s3-replicate-policy-from-bucket-a-to-b (앞서 만든 정책 이름)
  생성된 역할 ARN: arn:aws:iam::000000000001:role/s3-replicate-role-from-bucket-a-to-b
 
 3) account-2에서, 수신할 account-2-bucket-b버킷에 "버킷 정책" (리소스정책) 추가
{
    "Version": "2012-10-17",
    "Id": "",
    "Statement": [
        {
            "Sid": "SetPermissionsForObjects",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::000000000001:role/s3-replicate-role-from-bucket-a-to-b"
            },
            "Action": [
                "s3:ReplicateObject",
                "s3:ReplicateDelete"
            ],
            "Resource": "arn:aws:s3:::account-2-bucket-b/*"
        },
        {
            "Sid": "SetPermissionsOnBucket",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::000000000001:role/s3-replicate-role-from-bucket-a-to-b"
            },
            "Action": [
                "s3:List*",
                "s3:GetBucketVersioning",
                "s3:PutBucketVersioning"
            ],
            "Resource": "arn:aws:s3:::account-2-bucket-b"
        }
    ]
}

4. S3의 복제규칙 설정 

 account-1에서, account-1-bucket-a 버킷 선택하여, 관리 메뉴에서, 복제 규칙 생성 
복제규칙이름 : replicate-from-bucket-a-to-b 
상태 : 활성화
소스버킷 : account-1-bucket-a
적용옵션: 버킷의 모든 객체에 적용 
접두사 : 생략 (생략하면 해당 버킷 전체가 복제되고, 접두사에 폴더 이름을 지정하면, 해당 폴더와 하위 컨텐츠만 복제 적용됨 )
대상버킷
다른 계정의 버킷 지정 
계정ID : account-2 id(000000000002)
버킷이름 : account-2-bucket-b
옵션 : 객체 소유자를 대상 버킷 수유자로 변경 선택 
IAM역할 : 위 account-2에서 생성한 역할이름 지정 
암호화 : 선택안함
AWS KMS로 암호화된 객체 복제: AWS Key Management Service(AWS KMS) 키로 암호화된 객체를 복제할 수도 있다.
대상스토리지 클래스 : 지정안함 (지정할수도있다, 테스트 더 필요)
추가 복제 옵션 : 복제지표 및 알림 선택, 삭제 마커 복제 선택, 복제 시간제어 선택안함, 복제본 수정 동기화 선택안함 
추가 복제 옵션 설명 (선택 안해도 복제 동작에 영향없음) 
  -복제 시간 제어(RTC) - 선택안함 
복제 시간 제어는 새 객체의 99.99%를 15분 만에 복제했으며, 복제 지표 및 알림을 제공합니다. 추가 요금이 적용됩니다. 자세히 알아보기 

  -복제 지표 및 알림 - 선택함 
Cloudwatch 지표를 통해 복제 규칙의 진행 상황을 모니터링합니다. 자세히 알아보기  또는 Amazon Cloudwatch 요금  참조

  -삭제 마커 복제 - 선택함 
S3 삭제 작업에 의해 생성된 삭제 마커는 복제됩니다. 수명 주기 규칙에 의해 생성된 삭제 마커는 복제되지 않습니다. 자세히 알아보기 

  -복제본 수정 동기화 - 선택안함 
이 버킷의 복제본에 적용된 메타데이터 변경 사항을 대상 버킷에 복제합니다. 자세히 알아보기 
저장 
저장시 옵션
기존 객체를 복제하시겠습니까?
예. 기존 객체를 복제합니다 --> 복제작업 생성화면으로 들어감
아니요. 복제하지 않습니다 --> 저장하고 종료됨 

5. 테스트

 - 정책 적용위해 약 1시간 정도 적용 시간 기다려준다 (적용됬는지 여부를 알 수는 없다, 경험상 복잡한 정책은 1~2시간 적용되는데 시간이 걸렸었다)
 - account-1-bucket-1에 파일 업로드하고, account-2-bucket-b에 파일이 복제되는지 확인
 - account-1-bucket-a에 cloudtrail 로그가 생성되면, account-2-bucket-b에도 같이 생성되는지 확인
   cloudtrail 로그는 파일 사이즈가 크지 않아서 약 1분 내로 복제되는 것을 경험했다
 - S3 버킷 account-1-bucket-a의 '지표' 메뉴에서 '복제지표' 차트로 복제보류상태, 복제지연시간 확인 가능함
   버킷의 컨텐츠 속성을 보면 복제상태를 확인할 수 있다. 복제지연이나 복제오류가 발생하면, 설정이나 권한 문제로 볼 수 있다. 왜 복제가 실패했는지 자세한 설명은 나오지 않는다

CloudTrail 로그는 AWS 계정의 관리, 규정 준수, 운영 및 위험 감사를 지원하는 AWS 서비스로서,
CloudTrail 로그 및 CloudTrail 콘솔에 기록된 정보를 사용하여 사용자, 역할 또는 AWS 서비스에서 수행한 작업에 대한 정보를 검토할 수 있다.

AWS참고자료를 보면, 최신 UI가 반영되지 않은 오래된 문서들이 자주 눈에 띄어서, AWS 문서 그대로 따라하기가 쉽지 않은 경우가 자주 있다. 많이 테스트 해보고, 검색해보면서 다른 고수들의 경험치를 참고할 수 밖에...

내가 참고한 자료들

https://docs.aws.amazon.com/ko_kr/awscloudtrail/latest/userguide/cloudtrail-user-guide.html

https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/replication-example-walkthroughs.html

IAM - https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/introduction.html

Hi Orchid,

오늘은 AWS의 Elastic Load Balancer (ELB)에 인증서 추가하는 방법을 알려줄게.

어제 얘기했듯이 ELB는 아래처럼 3가지 유형이 있는데,

https(443 port) 프로토콜을 이용하고 웹사이트 인증서를 이용하려면

Application layer를 다룰 수 있는 Application LB(ALB) 혹은 Classic LB(CLB)를 이용해야해.

둘 다 세팅방법은 유사한데, https web site의 load balancing과 확장된 기능을 고려할 수 있도록

Application에 기능이 포커스된 ALB에서 세팅을 해볼게.

메뉴 선택 단계,

AWS Console > EC2 > Load Balancer(로드밸런서) 메뉴로 가서 "Load Balancer 생성"을 클릭

LB 유형 선택에서 Application Load Balancer를 선택

설정 1단계 : 기본구성, 리스너, 가용영역, 추가서비스

 - 체계에서, "인터넷 경계"는 외부 사용자 대상의 웹 인터넷 서비스용, "내부"는 말 그대로 내부망(사설망)에서 시스템들간 요청 처리용도

 - 인증서 등록 위해 "리스너 추가" 클릭하고 "HTTPS" 선택

 - 가용영역은, 로드밸런싱할 EC2 host들이 포함된 모든 subnet을 선택해준다. 복수개 subnet 선택이 필수.

 - 추가 서비스는, http/https 가속(액셀러레이터) 기능을 추가할 경우 선택 (요금추가)

설정 2단계 보안 설정 구성 : 기본 인증서 선택, 보안정책 선택

 - 인증서 유형에서,
    기존 AWS에 등록해둔 인증서가 있다면 "선택" 항목에서 선택하면 되고
    신규 등록이라면 "업로드"항목을 선택하고, 빈칸에 맞는 인증서 텍스트를 복사해서 붙여준다.

   인증서에서 복사할 텍스트 내용은
   "-----BEGIN CERTIFICATE-----" 부터 "-----END CERTIFICATE-----"까지 포함한 텍스트를 붙여 넣어야한다.

   * 주의할 점은, 인증서 발급회사마다 제공하는 파일이 조금씩 다른데,
      예1) 프라이빗키(***_key.pem), 인증서본문(***_crt.pem), 인증서체인(***_chain**.pem) 파일을 각각 분리하여
             제공하는 업체가 있는데, 이 경우는 각 파일을 열어서 텍스트를 붙여주면 된다.

      예2) 프라이빗키파일(***_key.pem) + 인증서본문과 체인이 결합된 파일(***_crt.pem)로 제공하는 업체가 있다.
             이 경우는 위 그림처럼 각 부분을 잘라서 붙여주면 된다.

 - 보안정책 선택에서는, 어떤 프로토콜(SSL, TLS1.0, TLS1.1, TLS1.2 등)을 사용할지 Preset을 선택하는 부분이다.
    TLS 1.1과 TLS 1.2를 같이 선택하려면 아래와 같이 하면 되고,

   각 preset에 어떤 옵션이 있는지는 여기 링크 문서 참조 --> [Application Load Balancer용 HTTPS 리스너 생성]  
   필요에 맞게 선택하면 되고, 나중에 수정할 수 있다.

설정 3단계 : 보안 그룹 구성

   기존 보안 그룹을 선택하거나, 새 보안 그룹을 선택하고, http/https를 허용하는 보안그룹을 만든다.

   * 보안그룹 만드는 상세 설명은 여기 링크 문서 참조    --> [보안 그룹 작업]

설정 4단계 : 라우팅 구성

- 로드밸런싱할 대상 (EC2 host 등)들을 어떤 프로토콜로 체크하여 요청을 넘겨줄 건지 정한다.
    대상의 유형을 지정해야 한다. 인스턴스(EC2 host), IP (EC2 등에 지정된 IP), Lambda함수를 선택할 수 있다.

설정 5단계 : 대상 등록 (EC2 인스턴스의 경우)

앞서 선택한 subnet들에 있는 running 중인 인스턴스들이 나타나면, 로드밸런싱할 인스턴스들을 선택해서
"등록된 항목에 추가" 클릭

6단계 : 검토

- 설정한 값들이 맞는지 최종 확인하고 "생성"클릭

이렇게 해서 Application Load Balancer 설정을 완료.

미션 컴플릿!

#LoadBalancer #인증서 #pem파일 #awsloadbalancersetting #ApplicationLoadBalancer #로드밸런서 #ELB

Hi, Ropez

넌 이제, 리눅스에서 iptables 사용법도 알고, 방화벽 룰 세팅 원리도 이해하고 있는데,

AWS의 기능으로 특정한 외부 IP를 차단하는 방법을 모른다고 했지?

AWS EC2 로 리눅스 등의 서버를 사용하고 있다면, 서버 OS내에서 iptables로 ip deny 하면 되겠지.

너가 말한 것처럼, AWS의 Console에서 VPC를 제어하는 Security Group 사용법을 배웠겠지만,

Security Group에서는 왜 안되나,

Security Group의 기본 구조는 White List 방식, 즉 기본적으로 모든 것을 막아두고, 일부만 지정하여 허용한다는 구조라서, http/https 서비스를 하는 환경으로 Security Group을 만들어 둔 상태에서, 특정 IP의 http/https 액세스를 막지는 못해. 최근에 이렇게 바뀐것 같은데, 허용하는 기능만 있고, 차단하는 기능은 없는게 Security Group의 특징이라서 그래.

예를 들어, EC2 instance에 리눅스 서버로 웹서비스를 구성하고, Security Group을 만든다면,

아래와 같이 http/https를 외부( source) ip를 all로 지정해서, 해당 프로토콜&포트번호&Source IP를 허용해준다는 뜻인데, 보통 이렇게 하쟌니? (다른 방법도 있을려나? 있다면 알려줘~)

위와 같이 설정한 상태에서,

외부(source)의 특정 IP에서 우리 시스템을 공격하는 것을 차단하기 위해, 특정 IP를 막는 룰을 쓸 수가 없지.

그러면, 어떻게 할까...

첫번째 방법은,

EC2에 설치된 서버 OS에서 iptables 같은 방화벽 기능으로 특정 IP를 deny 설정할 수 있지. 이 방법이 서버 엔지니어에겐 가장 편한 방법이겠지만, iptables의 list가 너무 많아지면 OS 응답성능에 영향을 상당히 준다는 건 알고 있겠지? 그리고, 모든 서버들의 iptables에 IP deny 설정을 다 해줘야되서, 관리의 불편함이 있지.

두번째 방법은,

VPC의 Security 기능 중에, Security Group말고, Network ACLs 라는 기능이야. Network ACLs는 물리적 인프라에서 방화벽과 같은 기능이야. Security Group과는 반대 개념으로, Black List 방식으로 동작해. 즉, 모든 것은 열어두고, 지정한 것만 막아주지. 외부의 특정 IP가 우리 VPC내의 어떤 것에도 액세스하지 못하게 막을 수 있지.

 IP 대역, Protocol, tcp/udp port range, deny/allow 선택이 가능해.

아래 화면의 규칙 80번과 같이, VPC를 선택하고, 인바운드규칙(Inbound rule)에서 규칙을 작성하면 되.

주의 할 점 두가지가 있는데,

첫번째 주의사항은,

규칙 번호 # 숫자가 작은 규칙이 먼저 적용된다는 점이야. 일반적인 방화벽과 동일한 구조니까.

두번째 주의사항은,

  '휘발성 포트' 라는 기법인데, 위의 예제와 같이 인바운드 및 아웃바운드의 100번 규칙이 모든 트래픽을 ALLOW하고 있다면 관계없지만, 좀 더 디테일하게 ACL 룰을 설정한다면, 서비스 유형별로 아웃바운드의 응답 포트에 대한 고려를 해줘야해.
  좀 복잡하지만, 이 링크를 열어서 공부해두자구. https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-network-acls.html

정리하자면, Network ACL의 장점은,

VPC내 모든 리소스에 적용되니까, 여러 서버에 세팅할 필요없지.

반대로 생각해보면, 모든 리소스에 영향을 미치는 정책이니 신중하게 결정하고 적용해야겠지? 그건 네 판단의 몫이야.

저장을 누르기 전에 한번 더 생각해보고 적용하도록 해~ 

직접하기 불안하면 사람 불러~ call me~

그럼, bye~

Hi, Orchid,

지난번에 물어본거야.

AWS 최신뉴스에서, AWS Elemental에서 RIST프로토콜을 지원한다는 기사가 나왔길래,

RIST가 뭔지 좀 찾아봤어~

                                                                <RIST Forum 로고>

RIST

RIST Forum에서 공동연구개발은 오래전부터 되왔었네.

2018년 IBC세미나에서 RIST Forum과 솔루션벤더들이 성과물을 공개하면서 많이 알려진 것 같고,

2019-9-12 발표로 AWS Elemental에서 결과물을 이번에 내놓은 것 같아~

# AWS 뉴스

AWS Elemental MediaConnect, 이제 RIST 프로토콜 지원

AWS Elemental MediaConnect가 아제 Reliable Internet Stream Transport(RIST) 표준을 지원합니다.

RIST 프로토콜을 사용하면 낮은 지연 시간과 높은 패킷 손실 복원력을 바탕으로 라이브 동영상을 전송할 수 있습니다.

MediaConnect의 이 추가적인 전송 옵션을 활용하면 브로드캐스트 스트림을 처리를 위해 AWS 클라우드에 전송할 때는 물론,

RIST를 지원하는 디바이스를 사용하여 스트림을 다시 온프레미스로 가져올 때 더 높은 유연성을 누릴 수 있습니다.

...

                                                AWS Elemental MediaConnect & MediaLive (출처:AWS)

# RIST 기술을 서칭해보니...

- 안정적인 RTP(UDP) 기술을 인터넷 환경에 맞게 개선. 특징은 안정적, Low latency, 다양한 솔루션간 상호운영성.

- 정상 데이터는 송수신간 확인(ack,syn 등) 하지 않고 단방향 송수신. 에러패킷만 재전송. (그래서 빠르다는 듯...)

- 제한된 버퍼용량 내에서 에러교정이 가능.(단점이 없는건 아니네...)

- 향후 방송 기술의 중심이 될거다 (라는 RIST forum의 주장)

                                                                   <RIST Data Flow, 출처:RIST Forum>

                                                              <Compare SRT and RIST, 출처:RIST Forum>

# 참고자료야~

RIST 프로토콜의 구조와 설명들, 타 프로토콜과의 비교 (구글 번역기야~ 고마워...)

요약설명: http://www.videoservicesforum.org/activity_groups/RIST_poster_for_VidTrans2018Feb25.pdf

길게설명: http://www.ipshowcase.org/wp-content/uploads/2018/11/Rick-Ackermans-Rick-Ackermans-RIST-Presentation-18-Sept-2018-1400.pdf

RIST, RTMP 등 video protocol들을 비교 설명 : https://www.thebroadcastbridge.com/content/entry/13531/compressed-video-over-ip-transport-report-part-1

RISP에 대해 더 길게 설명 : https://www.thebroadcastbridge.com/content/entry/13584/compressed-ip-video-transport-report-part-2-tweaking-internet-video-with-ri

# RIST를 활용하는 솔루션 벤더들 (잠깐 서칭해본것)

https://zixi.com/solutions/delivery/

https://openheadend.tv/how-rist-and-srt-will-change-the-face-of-broadcast/

# 마무리...

#WOWZA측에서는 아직 RIST를 지원하지 않는것 같고,

기존 프로토콜, 솔루션간 실질적인 비교자료는 아직 없는 것 같아. 발견되면 덧붙여줄게

AWS가 관심을 갖고 자기네 솔루션 스펙에 추가를 했다니, 어느 정도 효과 검증이 된게 아닐까 추측해본다능~

그럼, 빠이~

취향편지