Amazon SNS

• Pub Sub(출판-구독) 모델 : 게시자가 SNS로 메시지를 보낼 때 구독자에게 Push됨 (Push 방식)
• 개별 메시지를 보내거나 대량의 메시지를 다수의 수신자에게 보낼 때 사용
• 이메일, SMS, HTTP 엔드포인트 및 SQS와 같은 엔드포인트를 지원함
• 메시지를 가져오는 동시에 메시지 삭제. 사용 가능한 수신자가 없을 경우 메시지 손실 (메시지 전달이 보장되지 않음)
• 수신자마다 다른 방식으로 메시지 처리 가능

Amazon SQS

• 분산 큐잉 시스템 : 메시지가 수신자에게 푸시되지 않고, 수신자가 메세지를 수신하기 위해 SQS를 Polling 해야함 (Pull 방식)
• 동시에 여러 수신자가 메시지를 받는 것이 아님. SNS와는 달리 폴링 방식으로, SQS에서의 메시지 전달에는 약간의 latency 존재
• 애플리케이션 분리 및 병렬 비동기 처리에 사용됨
  • 트래픽이 많이 몰리는 상황에서, 누락되는 요청을 안정적으로 받아내기 위해 특정 서비스 앞에 붙여 사용
• 수신자가 available하지 않을 경우 메시지가 최대 14일(기본값 : 4일) 동안 SQS내에 저장 (메시지 전달이 보장)
• 모든 수신자가 동일한 방식으로 메시지를 처리해야 함
• 표준 대기열
  • API 작업별 초당 무제한 호출 수 지원
  • 각 메시지 최소 1회 전달 보장
    • 2회 이상 동일한 메시지가 전달될 수도 있음.
    • 가용성을 위해 메시지를 여러 서버에 저장하고, 서버가 사용될 수 없는 경우 메시지가 삭제되지 않고, 다시 메시지를 수신할 수 있도록 설계되어 있기 때문
  • 정확한 순서 보장 X
• FIFO 대기열
  • API 작업별 초당 최대 3000개 트랜잭션 지원(초당 300번의 처리 * Batch 10회 처리)
  • 모든 메시지를 정확히 1회 처리 보장
  • 정확한 순서 보장
• DLQ (데드레터큐) : 메시지 전송 실패를 처리할 때 사용. 해당 대기열을 따로 생성해야 사용 가능

SNS with SQS

SNS 단일 사용 시 문제점

1. 메시지를 받는 수신자가 연결을 막았을 수 있음
2. 대량의 메시지로 엔드포인트가 죽을 수도 있음
3. http 엔드포인트 혹은 SMS로 보낼 때 메시지 전송 실패로 메시지가 도착하지 못하고 모두 삭제될 수 있음

• SNS와 SQS를 결합하면 원하는 속도로 메시지를 받을 수 있음!
• 클라이언트가 오프라인 상태가 되거나, 네트워크 및 호스트 장애에도 메시징에 문제가 없음 (메시지 전송을 보장)

Amazon MQ

• 온프레미스 환경에서 사용하던 코드를 클라우드로 그대로 옮기고 싶거나, MQTT, STOMP 등 다양한 프로토콜 지원이 필요한 경우

xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

mac OS를 카탈리나에서 빅서로 업데이트한 이후에 

git 명령어를 사용하려고 했더니, 위와 같은 오류가 뜨며 작동하지 않았다.

검색해보니 다음 커맨드로 XCode를 재설치하면 해결된다고 하였다.

xcode-select --install

터미널에 git을 쳐보면 잘 작동하는 것을 알 수 있다. 

Route 53

DNS 서비스에서 더 발전된 형태의 GSLB 형태의 서비스이다.
GSLB는 Global Server Load Balancing의 약자로서, 지역에 상관없이 부하를 줄여주는 기능을 제공한다.
주기적으로 연결된 서버들에 헬스 체크가 이루어지기 때문에, 기존 DNS 방식과는 달리 다운된 서버로 사용자가 연결되지 않게 한다.

DNS

• naver.com과 같은 문자열 주소를 192.168.0.1과 같은 IPv4로의 주소 변환이 필요하고, 이를 DNS 서비스라 부름
• DNS서버에는 도메인 주소와 IP주소가 서로 맵핑된다.
• 하나의 행을 레코드라고 부르며, 저장되는 타입에 따라, A 레코드와 CNAME으로 구분

Record

• A 레코드 : 도메인 주소와 서버의 IP 주소를직접 맵핑 (naver.com - 192.168.0.1)
  • 한 번의 요청으로 바로 IP 주소를 알 수 있음
  • IP 주소가 자주 바뀌는 경우 번거로움
• CNAME : 도메인 주소를 또 다른 도메인 주소로 맵핑 (post.blog.co.kr - postapi.blog.co.kr)
  • IP 주소가 자주 바뀌어도 유연하게 대응 가능
  • 실제 IP 주소를 얻을 때까지 여러 번 DNS 정보를 요청하며, 성능 저하의 가능성 존재

라우팅 정책

아래와 같은 정책 등을 통해 SLA 100%의 서비스를 제공하는 것이 Route 53이다.

1. 지연시간 기반 : 각 리전에 대한 latency 정보를 가지고 있어서, 고객 기준으로 가장 latency가 작은 서버와 연결
2. 가중치 기반 : 각 서버로 가는 트래픽의 비율을 조정하여, 특정 서버로 연결될 확률을 조정
3. 지역 기반 : 유저의 지역 정보를 기반으로 가까운 지역의 서버로 연결

Route 53 이 정상적인 레코드를 선택하는 방식

1. 라우팅 정책과 레코드에 대해 지정한 값을 기반으로 선택
2. Route 53이 레코드가 정상이라 확인한 경우
   • 상태 확인이 연결된 비별칭 레코드
   • Evaluate Target Health (대상 상태 평가)가 예로 설정된 별칭 레코드
3. 레코드가 정상인 경우 IP주소와 같이 해당되는 값으로 쿼리에 응답 / 레코드가 비정상인 경우 다른 레코드 선택하고 정상 레코드를 찾을 때까지 반복

S3 Bucket 및 객체에 대한 액세스 제어

• IAM 정책
• 액세스 제어 목록 (ACL)
• 버킷 정책

Storage Class

• Standard (액세스 주기가 짧다)

  • 자주 액세스하기 때문에, 비용은 높지만, 데이터 불러오는 속도는 빠르다

• Infrequent Access

• Glacier (액세스 주기가 길다)

  • 저장 비용이 가장 낮지만, deep archive된 만큼 데이터 불러오는 시간, 비용 크다

• 액세스 패턴이 파악되었을 때 -> 수명 주기 규칙 설정

• 액세스 패턴이 파악이 어려울 때 -> S3 Intelligent Tiering

Storage Gateway

• S3가 File System 기반이 아닌 Object 기반이며, REST/HTTP 기반 통신이기 때문에 속도/사용성에서 불편함 존재
  • iSCSI 방식을 지원해주는 것이 Storage Gateway
    • 대부분의 백업 솔루션이 iSCSI 방식을 지원하기 떄문에, 기존 온프레미스 환경의 백업 솔루션을 사용하면서
      데이터 저장만 S3에 할 수 있음 (S3의 안정성과 확장성이라는 장점만 가져올 수 있음)
  • 온프레미스 환경에 S3을 쉽게 Integration 할 수 있게 함

Storage Gateway 구성

• S3를 iSCSI 방식으로 처리하기 위한 appliance를 VM에 설치해야 한다.

Storage Gateway 구성 타입

1. Gateway-Cached Volume
   
   • 데이터 저장은 S3에 하되, 자주 access하는 데이터는 appliance의 로컬 디스크에 cache 형태로 유지
   • S3의 네트워크 latency 제약을 cache를 통해 해결
   • 전체 파일 사이즈의 20% 이상 크기를 cache용 Volume으로 설정
   • Upload Buffer용 Volume(S3에 업로드 이전에 데이터를 잠깐 저장하는 용도)도 필요함.
     • 이후 SSL로 데이터를 암호화하여 업로드 수행
   • I/O가 빈번한 메인 스토리지로서는 용도 부적합
2. Gateway-Stored Volume
   
   • 데이터 저장을 appliance 내 local storage(Local IDC)에 저장하고, 비동기적으로 S3에 스냅샷 형태로 백업하는 방식
   • Gateway-Cached 방식보다 빠른 데이터 access를 원할 때 사용
3. Gateway-VTL Volume
   
   • Tape 방식 백업을 지원하는 솔루션에서 VTL(Virtual Tape Library) 형태의 인터페이스를 제공하여, S3에 저장하고, 이를 장기 보관할 수 있도록 Glacier로 아카이빙할 수 있도록 하는 방식

VPC

사용자 지정된 가상의 네트워크 환경이다. 논리적으로 격리되어 있는 공간이다.
리전을 선택하고, 원하는 IP range를 가장 먼저 설정한다.
가용영역 단위로 서브넷을 생성하고, 서브넷의 목적에 따라 라우팅 테이블과 연결한다.

서브넷

서브넷의 종류에는 크게 Public Subnet과 Private Subnet이 있다.

• Public Subnet : Internet Gateway와 연결된 서브넷
• Priavate Subdnet : Internet Gateway와 연결되지 않은 서브넷. 펌웨어 패치 등을 위해 NAT Gateway와 연결되어 있다.

CIDR

서브넷 마스크의크기는 /16 ~ /28 사이이다.

• /16 : 16bit의 CIDR을 사용하면 B클래스와 동일하게 네트워크 할당 (16 비트 네트워크 아이디 + 16비트 호스트 아이디 => 2^16 == 65536개 IP range 사용 가능)
• /24 : 16bit 네트워크 아이디 + 8비트 서브넷 아이디 + 8비트 호스트 아이디 => 2^8 == 251개 (나머지 5개는 예약 IP)의 IP range 사용 가능

NACL & Security Group

• NACL (Network aces control list)
  • 서브넷으로 들어오려는 모든 인터넷 패킷은 NACL을 거치고, 패킷의 permission을 판단
  • Stateless (인바운드, 아웃바운드 주소/포트를 모두 선언해야 힘)
• Security Group
  • 같은 서브넷 내에서, 허용되는 IP를 제외하고 block
  • Stateful (인바인드가 허용이면, 아웃바운드는 자동으로 허용)

고가용성

• 두 번째 서브넷을 만들고, Auto Scaling을 사용해 새 리소스가 두 번째 서브넷으로 자동 시작되게 할 수 있음
• ALB는 서브넷의 엔드 포인트 간 로드를 분산할 수 있음 (A/B 테스트 및 블루/그린 배포 가능)
• 별도의 가용 영역(AZ)에 두 번째 서브넷을 유지함으로써, 한 AZ의 리소스를 사용할 수 없더라도 다른 AZ에서 사용 가능 (다중 AZ)
• 새 서브넷에서 라우팅 테이블을 따로 생성하지 않고, 이전에 생성한 라우팅 테이블과 연결
• ELB는 연결된 리소스에 상태 체크를 하여 장애 조치를 처리함

3-Tier VPC

Single Tier VPC는 모든 것을 하나의 서브넷에 넣기 떄문에 보안에 취약 (개인 블로그나 웹 사이트 등의 애플리케이션의 경우에는 비용 효율적일 수 있다.)

• NAT, ELB (Public Subnet) : 들어오는 트래픽 (ALB), 나가는 트래픽(NAT)

  • 가장 적게 IP가 필요 (ex> /22)

• App (Private Subnet)

  • 가장 많은 IP가 필요 (ex> /20)

• Data (Private Subnet)

  • 퍼블릭보다는 많이 필요하지만, App에 비해서는 적게 (ex> /21)

• 3티어 설계에 적합한 트래픽 패턴 - IGW -> ALB -> App -> Data -> App -> NAT -> IGW

• enableDnsHostnames

  • PC에서 시작된 인스턴스가 퍼블릭 DNS 호스트 이름을 가져오는지 여부
  • true인 경우 VPC의 인스턴스는 퍼블릭 DNS 호스트 이름을 갖지만, enableDnsSupport가 true인 경우에만 가능

• enableDnsSupport

  • VPC에 대해 DNS 확인이 지원되는지 여부
  • false이면 퍼블릭 DNS 호스트 이름을 IP주소로 확인하는 DNS 서버가 활성화되지 않음
  • true이면 Amazon 제공 DNS 서버에 대한 쿼리와 예약된 IP주소에 대한 쿼리가 성공

VPC Peering

• 프라이빗 IPv4 또는 IPv6 주소를 사용하여 두 VPC 간 트래픽을 라우팅하기 위한 VPC 간의 네트워킹 연결
• 온프레임과 연결시 모든 VPC에 VPN Connection을 해주어야 하는 번거로움
• VPC 당 최대 VPC Peering 가능 개수 : 125개
• 대역폭 제한 없음
  • 대역폭 제한이 문제가 된다면 VPC Peering 사용

Transit Gateway

• VPC와 온프레미스 네트워크를 단일 게이트웨이에 연결할 수 있도록 해주는 서비스
• 여러 VPC를 한번에 연결할 수 있게 함 + VPN Connection의 개수도 줄어듦
• 대역폭 제한 : 50 Gbps
• Transit Gateway당 VPC 최대 연결 개수 : 5000개
  • VPC 1개당 125개가 넘는 VPC Peering이 필요하다면, Transit Gateway 사용
  • 단순한 구조이지만, VPC Peering 보다 많은 비용 청구

온프레미스와 VPC 연결

VPN

• IPSec 네트워크 프로토콜 기반 VPN 연결
• VPN Tunnels은 기본적으로 이중화(되어 있고, TLS 통신이기 때문에 안전하게 통신 가능
• 인터넷 기반이기 때문에 성능, 품질이 전용선보다는 떨어지고, 지연이 생길 수 있다. (Bandwidth와 Latency가 가변적)
• AWS 상에 VPN을 연결하기 위한 Virtual Private Gateway(VGW)가 만들어지고, 해당 VGW와 온프레미스의 CGW(Customer Gateway)가 통신

Direct Connect

• VPN처럼 AWS와 직접 연결하지 않고, 중간에 AWS와 연결된 DX Location이 있어, 해당 DX Location 까지만 전용회선을 구축하면 되는 형태
  • 이후 DX Location 내 고객/파트너의 상면에 고객의 라우터를 설치, AWS Cage에 있는 AWS의 라우터와 연결한다. 이 작업을 Cross Connect라고 부름
• DX Location은 국내에서 가산의 KNIX, 평촌의 LG U+가 있다.
• 전용선을 사용하기 때문에 Bandwidth와 Latency가 일관적
• 이중화 방법 (반기에 한번 씩 Direct Connect의 정기 점검이 있어 고가용성 보장을 위해 이중화가 필요)
  1. Direct Connect + VPN 백업
     • 라우팅의 우선 순위는 무조건 VPN < DX
     • DX에 문제가 발생할 때 VPN으로 Failover가 되는 구성
     • 이중화 방법 중 가장 비용이 싼 방법
     • 즉, Direct Connect는 active 상태, VPN은 failover를 위해 standby 상태로 존재한다.
  2. DX Location 내에 inter-connection을 2개 설정하는 방법
  3. LAG (Link Aggregation Group) : 전용선의 최대 Bandwidth가 10Gbps까지이기 때문에, 이것을 4개 묶어 40Gbps까지 높인 방법
  4. DX Location과 전용선을 모두 2개씩 구축하는 방법 (가장 비용이 비쌈, 주로 금융권에서 사용)

Direct Connect의 active/standby 우선순위

대부분의 고객들은 일관적인 트래픽의 flow를 위해 active/standby 방식을 선호하며, BGP parameter를 통해 이것을 조절할 수 있다.

1. global적으로 longest prefix(CIDR가 더 긺)가 우선순위를 가진다.
2. AWS to On-Premise 트래픽 : AS prepending 파라미터를 통해 보다 적은 AS-PATH를 가지는 회선이 우선순위 (61000 > 61000, 61000)
3. On-Premise to AWS 트래픽 : BGP의 Local Preference 파라미터를 통해 우선순위가 높은 회선을 사용 (7300 > 7100)

따라서 동일한 회선이 항상 사용되도록 BGP parameter를 조정하는 것이 필요

Reference

• VPC Peering과 Transit Gateway 어떻게 다를까
• AWS Summit Seoul 2016 - AWS Direct Connect 및 VPN을 이용한 클라우드 아키텍쳐 설계 (Steve Seymour, AWS)
• KINX와 함께 하는 AWS Direct Connect 도입 - 남시우 매니저(KINX)
• 실전! AWS 하이브리드 네트워킹 (AWS Direct Connect 및 VPN 데모 세션) - 강동환, AWS SA:: AWS Summit Online Korea 2020

AWS IAM

• console 기반 작업 -> Script 기반 -> 프로비저닝 엔진 (CloudFornmation, Terraform) -> DOM (CDK)

  • 어떤 방식을 사용하든 API로 이루어진다.

• AWS에서 API 인증

  • AWS 자격 증명 = Access Key + 비밀 KEY (HMAC) (+ 임시는 Session Token)
  • 요청 내용과 비교하면 서명값 확인 -> 타임 스탬프 확인 -> 권한 판단 -> 허용 여부 판단

• 데이터, 어플리케이션 (클라우드 위의 보안)은 고객이 보안을 책임 (데이터 + IAM)

• IAM : AWS 전체의 권한 통제 시스템 (Identity and Access Management)

  • Identity : AWS로 요청할 수 있는 보안 주체(principal)을 만들어줌
  • Access Management : 누가 어떤 리소스에 대해 어떠 일을 할 수 있는 권한을 가지는지 정의

• Access Advisor를 통해 일정 기간동안 접근하지 않은 서비스에 대해 검사 가능 -> 이후 권한 회수할 것이 권장됨

Identity

• Root User 는 보안상 취약(권한 조정할 수 없는 슈퍼 유저), 따라서 IAM User, Role을 사용해야 함
  • IAM 사용자 : 로그인할 수 있는 보안 주체로 사용되기도 함 (장기 Credential을 이용해 서비스에 접근하는 보안 주체)
  • IAM Role
    • IAM 사용자가 장기 Credential 사용하기 때문에, 자격증명이 영구지속되기 때문에 서버 안에서 사용하든지, 하드코딩하기에는 위험
    • Role은 자동으로 로테이션 되는 임시 Credential 사용 (키값에 더해 일정 시간이 지나면 만료되는 Token 존재)
    • API적인 접근 / 외부 사용자(외부에 존재하는 보안주체)를 SAML, OpenIDC을 이용해 Role과 연계

Access Management

• AWS에서의 인가

• 디폴트가 Deny, 명시적 allow < 명시적 deny

• AND 조건으로 권한 인가

• Effect : allow or deny

• action : 어떤 행위를?

• Resource : 어떤 객체에 대해?

• Condition : 어떤 조건에서?

{
    "Effect": "Allow",
    "Action": "dynamodb:GetItem",
    "Resource": [
        "arn:aws:dynamodb:us-east-2:1111222233333:table/MyTable"
    ],
    "Condition": {
        "IpAddress": {
            "aws:SourceIp": "1.1.1.1"
        },
    }
}

IAM 정책 종류

• Identity-based : IAM User, Role (요청하는 보안 주체에게 연결)

• Resource-based : 자원에 할당 (요청을 받는 리소스에 연결) (Principal이라는 보안주체 속성이 추가)

• Permission Boundary : 권한의 최대치 규정

• SCP : 멀티 어카운트

• Session, ACL, Endpoint

• 동일 어카운트 환경에서 Identity, Resource 충돌 -> 합집합 (한쪽에만 allow 라면, 다른 쪽도 요청 허용)

• 크로스 어카운트 환경에서는 교집합 (한쪽에만 allow 라면, 다른 쪽은 요청 거부)

AWS 계정 활동 모니터링 및 감사

• AWS CloudTrail : 모든 API 활동 기록을 확인 가능, 문제가 발생했을 때 트러블 슈팅하기 위함
• AWS IAM Access analyzer : 외부 엔티티와 공유되는 리소스를 식별
• Amazon GuardDuty : CloudTrail, DNS로그, VPC Flow로그를 기반으로 해킹시도나 보안 위협을 탐지
• AWS Security Hub : 다양한 AWS 보안 서비스를 통합하여 보여주는 통합 대시보드 서비스

ABAC

• Role기반(RBAC)의 문제점 : 역할이 많거나 서비스 확장
  • ABAC : 태그를 이용하여 접근 제어
    • ARN 기반 정적 권한관리가 아닌, 보안 주체의 태그와 리소스의 태그를 비교하여, 동적 권한관리