sehee

VPC Components Diagram

AWS Site-to-Site VPN

기업 데이터 센터를 AWS와 비공개로 연결하기 위해 기업은 고객 게이트웨이를 VPC는 VPN 게이트웨이를 갖춰야 함
공용 인터넷을 통해 사설 Site-to-Site VPN 연결

Site-to-Site VPN Connection

고객 게이트웨이가 있는 기업 데이터 센터와 가상 프라이빗 게이트웨이를 갖춘 VPC가 있음
온프레미스 고객에게 게이트웨이를 어떻게 구축해야 할까?

-> 고객 게이트웨이가 공용이라면 인터넷 라우팅이 가능한 IP 주소가 고객 게이트웨이 장치에 있음

고객 게이트웨이의 공용 IP를 사용해서 VGW와 CGW를 연결하면 됨

-> 고객 게이트웨이를 비공개로 남겨 사설 IP를 갖는 경우, 대부분 NAT-T를 활성화하는 NAT 장치 뒤에 있음
NAT 장치에 공용 IP가 있을 시 이 공용 IP를 CGW에 사용해야 함

+ 서브넷의 VPC에서 라우트 전파를 활성화해야 Site-to-Site VPN 연결이 실제로 작동함

+ 온프레미스에서 AWS로 EC2 인스턴스 상태를 진단할 때 보안 그룹 인바운드 ICMP 프로토콜이 활성화됐는지 확인해야 함(그렇지 않으면 연결되지 않음)

AWS VPN CloudHub

VGW를 갖춘 VPC가 있고, 고객 네트워크와 데이터 센터마다 고객 게이트웨이가 마련된 상황

Hands-on#0n - Site-to-Site VPN

1) create customer gateways

- Site-to-Site VPN 연결을 구성하기 위해서는 온프레미스 호스팅이 된 고객 게이트웨이가 필요하므로

- create Site-to-Site VPN connections ...

Direct Connect (DX)

원격 네트워크로부터 VPC로의 전용 프라이빗 연결을 뜻함
DX를 사용할 때는 전용 연결을 생성해야 하고, AWS DX 로케이션을 사용함

VPC에는 가상 프라이빗 게이트웨이를 설치해야 온프레미스 데이터 센터와 AWS 간 연결이 가능

설치 기간이 한 달보다 길어질 때도 있음

Direct Connect Gateway

다른 리전에 있는 하나 이상의 VPC와 연결할 경우

Direct Connect - Resiliency

복원력, 아키텍처 모드

핵심 워크로드의 복원력을 높이기 위해서는 여러 DX를 설치하는 것이 좋음
기업 데이터 센터가 2개이고 DX location도 둘일 때 중복이 발생 - 프라이빗 VIF가 하나 있는데 다른 곳에 또 있다면 하나의 연결을 여러 로케이션에 수립한 것이므로 DX 하나가 망가져도 다른 하나가 예비로 남아있기 때문에 복원력이 강해짐

핵심 워크로드 복원력을 최대로 끌어올리고 싶다면, (Maximum Resiliency for Critical Workloads)

각 DX location에 독립적인 연결을 두 개씩 수립하면 복원력을 최대로 만들 수 있음

Transit Gateway

네트워크 토폴로지 복잡성 문제로 만듦

IP Multicast할 때 사용

Transit Gateway: Site-to-Site VPN ECMP

Site-to-Site VPN 연결 대역폭을 ECMP를 사용해 늘리는 경우

- ECMP: Equal-cost multi-path, 여러 최적 경로를 통해 패킷을 전달하는 라우팅 전략

Transit Gateway: throughput with ECMP

VPN을 Transit Gateway로 연결하면 Site-to-Site VPN 하나가 여러 VPC에 생성됨 (동일한 Transit Gateway에 모두 전이적으로 연결되기 때문)

VPC - Traffic Mirroring

사례: 콘텐츠 검사, 위협 모니터링, 네트워킹 문제 해결

IPv6 Troubleshooting

IPv4는 VPC 및 서브넷에서 비활성화될 수 없음
IPv6가 활성화된 VPC가 있을 때, 서브넷에서 EC2 인스턴스를 실행할 수 없다고 하면 인스턴스가 IPv6를 받지 못해서가 아님 (실제로 공간이 크고 EC2 인스턴스를 위한 IPv6도 충분하기 때문)

-> 진짜 원인은 서브넷이나 VPC에 이용 가능한 IPv4가 없기 때문

-> solution: 서브넷에 IPv4 CIDR를 생성하는 것 (create a new IPv4 CIDR in your subnet)

Hands-on#0n -

1) VPC Edit CIDRs - Amazon-provided IPv6 CIDR block

2) Subnet - edit IPv6 CIDRs > subnet CIDR block

3) Subnet - edit subnet settings > auto-assign IP settings: Enable auto-assign IPv6 address

4) Instance (BastionHost) - networking: Manage IP addresses > eth0: IPv6 addresses Auto-assign

5) 해당 instance security group edit inbound rules - add SSH IPv6

Test your IPv6

6) Route tables - Public routes > IPv6 target: local로 설정되어 있음

Egress-only Internet Gateway

송신 전용 인터넷 게이트웨이, NAT Gateway와 비슷하지만 IPv6 전용

Hands-on#0n - Egress only internet gateway

1) create egress only internet gateway (DemoEIGW)

2) private route tables edit routes - ::/0, eggress only internet gateway

-> 사설 서브넷의 EC2 인스턴스가 IPv6로 인터넷에 액세스하지만 인터넷에는 도달하지 못함

VPC Section Summary

01. CIDR: IP Range

02. VPC: virtual private cloud, IPv4와 IPv6를 위해 작동함

03. Subnets: CIDR를 정의하는 AZ에 연결됨, public/private

04. Internet Gateway: at the VPC level, public subnet은 인터넷 게이트웨이 연결시키고, 퍼블릭 서브넷에서부터 인터넷 게이트웨이로 경로 생성

05. Route Tables: 네트워크가 VPC 내에서 흐르도록 하는 키, 수정됨, 인터넷 게이트웨이 경로들, VPC Peering connections, VPC Endpoints 등 포함

06. Bastion Host: SSH에 들어갈 수 있는 public EC2 instance, 비공개 서브넷의 다른 EC2 인스턴스들과 SSH 연결

07. NAT Instances: 퍼블릭 서브넷에 배포된 EC2 인스턴스, 프라이빗 서브넷의 EC2 인스턴스에게 인터넷 접근을 제공, 오래되었고 사용이 권장되지 않고 있기 때문에 소스 / 대상 확인 플래그를 비활성화해야 함 (그렇게 해야 작동을 할 것이고 보안 그룹 규칙을 수정할 수 있음)

08. NAT Gateway: 프라이빗 EC2 인스턴스에 확장 가능한 인터넷 접근을 제공하고, 요청의 타켓이 IPv4 주소일 때 사용

09. NACL: 네트워크 ACL, 서브넷 레벨에서 인바운드와 아웃바운드 접근을 정의하는 방화벽 규칙, stateless 상태라 인바운드와 아웃바운드 규칙은 항상 평가되고 있음

10. Security Groups: Stateful 상태 - 인바운드가 허용되었을 경우 아웃바운드도 자동적으로 허용되고 그 반대도 마찬가지, 보안 그룹 규칙은 EC2 인스턴스 레벨에 적용됨

11. VPC Peering: 두 개의 VPC를 연결, 겹치지 않는 CIDR을 가지는 경우에 해당, VPC 피어링 연결은 비전이적 (따라서 세 개의 VPC를 연결하고자 한다면 세 개의 VPC 피어링 연결이 필요함)

12. VPC Endpoints: 프라이빗 접근을 허용 - VPC 내의 AWS 서비스라면 Amazon S3, DynamoDB, CloudFormation, SSM 등 무엇이든 가능 (Amazon S3와 DynamoDB에는 게이트웨이 엔드포인트가 있는 것도 보았고 나머지는 모두 인터페이스 엔드포인트)

13. VPC Flow Logs: VPC 내의 모든 패킷에 관련된 로그 레벨의 메타데이터를 갖는 데 가장 좋은 방법, 허용과 비허용 트래픽과 관련된 정보도 조금 있음, VPC 서브넷이나 ENA 레벨에서 생성 (Amazon S3로 전송되어 분석되고 Athena에서 분석될 수 있었으며, CloudWatchLogs로 전송되어 CloudWatchLog Insights를 통해 분석될 수도 있었음)

VPC를 데이터 센터로 연결하기 위한 두 가지 방법

14. 1) Site-to-Site VPN: 공공 인터넷을 통한 VPN 연결이기 때문에 AWS에 버추얼 비공개 게이트웨이를 생성해야 하고 데이터 센터에 고객 게이트웨이를 생성하고 그 후에 VPN 연결을 설립, 여러개의 VPN 연결을 설립할 때 같은 virtual private gateway를 사용하면 VPN CloudHub를 사용해서 hub-and-spoke VPN모델을 만들어 사이트들을 연결할 수 있기도 함

15. 2) Direct Connect: 연결이 완전히 프라이빗 상태, 공공 인터넷을 통하지 않지만 설립하는 데에 시간이 소요됨, 데이터 센터를 Direct Connect 위치로 연결해야 작동함 (더 복잡하지만 더 보안적으로 안전함, 연결도 안정적)

16. Direct Connect Gateway: 다른 AWS 리전의 많은 VPC와 Direct Connect를 만들기 위한 것

17. AWS PrivateLink / VPC Endpoint Services: 고객 VPC에 직접 생성한 VPC 내에서 서비스로 비공개적으로 연결하기 위한 것, 좋은 점은 VPC 피어링이나 공공 인터넷이나 NAT 게이트웨이나 라우팅 테이블을 요구하지 않음, 주로 Network Load Balancer와 ENI와만 사용됨 - VPC 내의 서비스를 네트워크를 노출시키지 않고 수백, 수천개의 고객 VPC에게 노출시킬 수 있도록 함

18. ClassicLink: EC2-Classic 인스턴스를 VPC로 비공개로 연결하기 위한 것, 사용이 권장되지 않음

19. Transit Gateway: VPC, VPN, 그리고 Direct Connect를 위한 전송 피어링 연결

20. Traffic Mirroring: 네트워크 트래픽을 ENI에서 복사하여 분석을 하는 것

21. Egress-only Internet Gateway: NAT Gateway와 비슷하지만 IPv6 트래픽이 인터넷 밖으로 가는 것을 위한 것

Networking Costs in AWS per GB - Simplified

첫번째 AZ에 EC2 인스턴스가 있을 경우 EC2 인스턴스로 향하는 트래픽은 무료

같은 가용영역 내 두 EC2 인스턴스 간 트래픽은 사설 IP로 통신할 시 무료

같은 리전 내 다른 두 AZ에 있는 EC2 인스턴스 두 개가 소통하기 위해 공용 IP나 탄력적 IP를 사용하는 경우, 청구 비용은 GB당 2센트(사설 IP를 사용할 경우 반으로 절감)

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 27

VPC Components Diagram

VPC Peering

다양한 리전과 계정에서 VPC를 생성할 수 있는데, AWS 네트워크를 통해 연결하고 싶을 때 사용
왜 필요한가? VPC가 모두 같은 네트워크에서 작동하도록 만들기 위해

서로 다른 VPC가 통신하려면 VPC 피어링을 활성화해야 함

A-B, B-C가 연결되어 있더라도 A와 C의 VPC 피어링 연결을 활성화해야 그 둘이 통신할 수 있음

VPC Peering - Good to know

다른 계정 간에도 가능 - 계정 A에서 계정 B로 VPC 연결이 가능
리전 간 연결도 가능

Hands-on#05 - VPC Peering

1) edit default VPC name: DefaultVPC

2) launch Instance (DefaultVPCInstance)
- private IPv4 address: 172.31.0.0/16 (PrivateInstance: 10.0.0.0/16, 다른 VPC)
- BastionHost IP(10.x.x.x)로 DefaultVPCInstance ssh에서 curl 명령시 연결되지 않음

3) create Peering connections
- VPC ID (Requester): DemoVPC, 10.0.0.0/16
- VPC ID (Accepter): DefaultVPC, 172.31.0.0/16

+ Actions: Accept request

4) edit default Route tables name: DefaultVPCMainRouteTable
5) public route table - add Routes > peering connection
- DefaultVPC IPv4 CIDR(172.31.0.0/16)

6) default route table - add Routes > peering connection - 10.0.0.0/16

(The destination CIDR block 10.0.0.0/16 is equal to or more specific than one of this VPC's CIDR blocks. This route can target only an interface or an instance.)

VPC Endpoints (AWS PrivateLink)

프라이빗 서브넷의 EC2 인스턴스를 VPC 엔드포인트를 거쳐 직접 Amazon SNS 서비스에 연결할 수 있음, 이 때 네트워크가 AWS 내에서만 이루어짐

VPC 엔드포인트를 사용하면 AWS PrivateLink를 통해 프라이빗으로 액세스하므로 AWS에 있는 모든 서비스에 액세스할 때 퍼블릭 인터넷을 거치지 않고도 프라이빗 네트워크를 사용할 수 있음

Types of Endpoints

1. Interface Endpoints (powered by PrivateLink)

인터페이스 엔드포인트는 ENI를 프로비저닝하는데 ENI는 VPC의 프라이빗 IP 주소이자 AWS의 엔트리 포인트임

ENI가 있으면 반드시 보안 그룹을 연결해야 함, 대부분의 AWS 서비스를 지원함

2. Gateway Endpoints

게이트웨이를 프로비저닝, 게이트웨이는 라우팅 테이블의 대상이 되어야 함

IP 주소를 사용하거나 보안 그룹을 사용하지 않고 라우팅 테이블의 대상이 될 뿐임

게이트웨이 엔드포인트 대상: Amazon S3, DynamoDB

Gateway or Interface Endpoint for S3?

Amazon S3에 액세스하는 방법 중 게이트웨이를 선택하는 편이 대부분 유리함 - 라우팅 테이블만 수정하면 되기 때문

인터페이스 엔드포인트가 권장되는 경우: 온프레미스에서 액세스해야 할 필요가 있을 때, 다른 VPC에 연결할 때

Hands-on#05 - VPC Endpoints

7) PrivateInstance > Security - Modify IAM role > role 생성 후 추가

- create role: AWS service, EC2, policies-AmazonS3ReadOnlyAccess

8) BastionHost > PrivateInstance ssh connect + 명령 입력

aws s3 ls
curl google.com

9) Private Route Table의 NAT Gateway로 인터넷에 연결하는 라우트 0.0.0.0/0 삭제

- 이 인스턴스가 인터넷에 접속하지 못하게 하도록

- 8번 동일 명령 실행되지 않음

-> VPC 엔드포인트를 통해 Amazon S3에 프라이빗 접속이 가능해짐

10) VPC Endpoints create (DemoVPC) - 아래 둘 중 Gateway endpoints로 생성

Interface

- service name: 맨 상단(aws.sagemaker.ap-northeast-2.notebook)

- subnets: Private subnet A, B 지정

Gateway

- service name: com.amazonaws.ap-northeast-2.s3

- Route tables: PrivateRouteTable

-> PrivateRouteTable routes edit 시 NAT Gateway 생성되어 있음

11) 이후 PrivateInstance ssh connect 후 명령 실행

- CLI 리전은 기본적으로 us-east-1으로 설정됨

# 해당하는 리전으로 입력
aws s3 ls --region ap-northeast-2

VPC Flow Logs

인터페이스로 들어오는 IP 트래픽에서 정보를 포착할 수 있음

Hands-on#06 - VPC Flow Logs

1) DemoVPC create flow log (DemoS3FlowLog)

- send to an Amazon S3 bucket
- 2)의 buckets properties ARN(Amazon Resource Name) 붙여넣기

2) create S3 (demo-(alias) vpc-flow-logs-v2)

3) DemoVPC create flow log 2nd (DemoFlowLogCWLogs)
- send to CloudWatch Logs

- 4)에서 생성한 flowlogsRole

4) create IAM role
- type: custom trust policy

"Principal": {
    "Service": "vpc-flow-logs.amazonaws.com"
},

- CloudWatchLogsFullAccess

- role name: flowlogsRole

5) CloudWatch create Log groups (VPCFlowLogs)

6) S3 Buckets / CloudWatch Log groups 확인

- BastionHost network interface ID에 해당하는 CloudWatch log streams: EC2 인스턴스에서 일어나고 있는 트래픽

7) Amazon Athena를 사용해서 S3 버킷에 들어가는 데이터 쿼리 연습
(1) query editor - settings - S3에서 생성한 bucket 추가

- S3에서 create bucket (demo-athena-(alias)-v2)

search > aws vpc logs athena query 붙여넣기

CREATE EXTERNAL TABLE IF NOT EXISTS `vpc_flow_logs` (
  version int,
  account_id string,
  interface_id string,
  srcaddr string,
  dstaddr string,
  srcport int,
  dstport int,
  protocol bigint,
  packets bigint,
  bytes bigint,
  start bigint,
  `end` bigint,
  action string,
  log_status string,
  vpc_id string,
  subnet_id string,
  instance_id string,
  tcp_flags int,
  type string,
  pkt_srcaddr string,
  pkt_dstaddr string,
  region string,
  az_id string,
  sublocation_type string,
  sublocation_id string,
  pkt_src_aws_service string,
  pkt_dst_aws_service string,
  flow_direction string,
  traffic_path int
)
PARTITIONED BY (`date` date)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ' '
LOCATION 's3://DOC-EXAMPLE-BUCKET/prefix/AWSLogs/{account_id}/vpcflowlogs/{region_code}/'
TBLPROPERTIES ("skip.header.line.count"="1");

- query LOCATION에 - S3 region url 대체 (demo-(alias) vpc-flow-logs-v2)

(2) query 변경

ALTER TABLE vpc_flow_logs
ADD PARTITION (`date`='YYYY-MM-dd')
LOCATION 's3://DOC-EXAMPLE-BUCKET/prefix/AWSLogs/{account_id}/vpcflowlogs/{region_code}/YYYY/MM/dd';

- S3 일자까지 클릭 후 properties S3 URL 붙여넣기

- query results: 테이블에 파티션 하나 추가

(3) 데이터 쿼리

SELECT day_of_week(date) AS
  day,
  date,
  interface_id,
  srcaddr,
  action,
  protocol
FROM vpc_flow_logs
WHERE action = 'REJECT' AND protocol = 6
LIMIT 100;

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 27

VPC Components Diagram

Understanding CIDR - IPv4

클래스 없는 도메인 간 라우팅: Classless Inter-Domain Routing

IP address range
1) ww.xx.yy.zz/32 : one IP
2) 0.0.0.0/0 : all IPs
3) we can define 192.168.0.0/26 : 192.168.0.0 - 192.168.0.63 (64 IP addresses)

octets: 1st . 2nd . 3rd . 4th
/32: no octet can change, /24: last octet can change

https://www.ipaddressguide.com/cidr

Public vs. Private IP (IPv4)

10.0.0.0 - 10.255.255.255 (10.0.0.0/8) <- in big networks
172.16.0.0 - 172.31.255.255 (172.16.0.0/12) <- AWS default VPC in that range
192.168.0.0 - 192.168.255.255 (192.168.0.0/16) <- e.g., home networks

Default VPC Walkthrough

새로운 AWS 계정은 모두 기본 VPC가 있음, 새로운 EC2 인스턴스는 서브넷을 지정하지 않으면 기본 VPC에 실행됨

VPC in AWS - IPv4

단일 AWS 리전에 여러 VPC를 둘 수 있음, 리전 당 최대 5개까지 가능(늘릴 수 있음), VPC마다 할당된 CIDR는 다섯 개
각 CIDR의 최소 크기는 /28, IP 주소는 최소 16개(2^4), 최대 크기는 /16, IP 주소는 최대 65,536개
VPC가 사설 리소스이기 때문에 사설 IPv4 범위만 허용됨
VPC CIDR가 다른 VPC나 네트워크 혹은 기업 네트워크와 겹치지 않도록 주의할 것

VPC - Subnet (IPv4)

서브넷이란: VPC 내부에 있는 IPv4 주소의 부분 범위
범위 내 AWS가 IP 주소 다섯 개를 예약함

Example: if CIDR block 10.0.0.0/24, then reserved IP addresses are:
.0: network address
.1: reserved by AWS for the VPC router
.2: reserved by AWS for mapping to Amazon-provided DNS
.3: reserved by AWS for future use
.255: network broadcast address. AWS does not support broadcast in a VPC, therefore the address is reserved

EC2 인스턴스 서브넷에서 IP 주소 29개가 필요할 때, /27 서브넷은 사용할 수 없음 (32 - 5 = 27 < 29)

Hands-on#01 - Adding Subnets

1) VPC 생성
2) Public/Private Subnet 생성

Internet Gateway (IGW)

인터넷 Gateway는 VPC의 리소스를 인터넷에 연결하도록 하는 EC2 인스턴스나 람다 함수 등
수평 확장, VPC와 별개로 생성해야 함
VPC는 인터넷 Gateway 하나에만 연결됨
VPC에 인터넷 Gateway를 만드는 정도로는 서브넷에 인터넷 액세스를 제공하지 못함, 라우팅 테이블도 수정해야 함

∴ 공용 서브넷에 공용 EC2 인스턴스 만들기 -> 라우팅 테이블을 수정 -> EC2 인스턴스를 라우터에 연결 -> 인터넷 Gateway에 연결

Hands-on#02 - Adding Internet Gateway & Editing Route Tables

1) launch instance (BastionHost)
- 퍼블릭 서브넷을 위한 자동 할당 퍼블릭 IPv4 주소 활성화 시 Network settings에서 Auto-assign public IP 활성화(enable)된 상태
2) Internet gateways 생성 및 attach to VPC
- VPC에 인터넷 액세스 제공
3) public/private route table 생성
- subnet associations 추가
- routes 0.0.0.0/0 target Internet GW 추가

4) Instance connect

Bastion Hosts

사용자가 프라이빗 서브넷에 없는 EC2 인스턴스에 액세스하고자 함, 이 때 배스천 호스트를 통해 프라이빗 EC2 인스턴스에 SSH로 액세스할 수 있으며 배스천 호스트는 반드시 퍼블릭 서브넷에 있어야 함

배스천 호스트를 위해서는, 
- 보안 그룹이 반드시 인터넷 액세스를 허용해야 함(기업의 퍼블릭 CIDR 액세스, 사용자 인터넷 액세스만 허용하는 등 EC2 보안 그룹을 제한하여 인프라 보안상 위험 방지)
- 프라이빗 서브넷의 EC2 인스턴스 보안 그룹에서는 반드시 SSH 액세스를 허용해야 함(포트 22번이 배스천호스트의 프라이빗 IP가 되거나 배스천 호스트의 보안 그룹이 되는 셈)

Hands-on#03 - NAT Instance

1) launch instance (PrivateInstance)
- private, network settings - Inbound Security Group Rules custom (Allow SSH from the Bastion Host)

- 프라이빗 서브넷에 위치하므로 EC2 인스턴스로 연결할 수 없음 (∵ 인터넷 게이트웨이 라우팅 테이블을 수정하면 이 서브넷이 공개되기 때문)

2) public instance 실행 후 SSH

# copy + paste
vi EC2KeyPair.pem

chmod 0400 EC2KeyPair.pem
ssh ec2-user@(private IP) -i EC2KeyPair.pem

# doesn't work
ping google.com

- private subnet의 Amazon Linux 2 AMI에 SSH 액세스 실행

NAT Instance (outddated, but still at the exam)

NAT: 네트워크 주소 변환, 사설 서브넷 EC2 인스턴스가 인터넷에 연결되도록 허용함
NAT 인스턴스에는 고정된 탄력적 IP가 연결되어야 함

NAT 인스턴스의 작동 방식: 공용 서브넷에 NAT 인스턴스를 생성하고, 거기에 탄력적 IP를 연결, 그리고 라우팅 테이블을 통해 사설 인스턴스가 NAT 인스턴스에서 인터넷 Gateway까지 통신하도록 함

Hands-on#03 - NAT Instance

3) launch instance (NAT Instance)

- Community AMIs - architectures: x86_64bit, vpc-nat

- Security group name: nat-instance-sg
- Security group rule: add HTTP, HTTPS
4) Change source/destination check
- Stop to allow your instance to send and receive traffic when the source or destination is not itself.

- NAT 인스턴스 자체가 소스 및 목적지가 아니라면 트래픽을 송수신할 수 있어야 함

5) private Route Table 인터넷 통신하기 위한 인스턴스 추가
- routes: 0.0.0.0/0 NAT Instance
6) NAT Instance 포트 추가
- All ICMP
7) PrivateInstance ping google.com
- BistionHost SSH connect > ssh Private

NAT Gateway

AWS-managed NAT, 높은 대역폭, 가용성이 높고 관리할 필요가 없음

특정 AZ에서 생성되고 탄력적 IP를 이어 받음

NAT Gateway with High Availabiltiy

AZ가 중지될 경우를 위해 다중 NAT Gateway를 여러 AZ에 두면 결함 허용을 할 수 있음

Hands-on#04 - NAT Gateway

1) create NAT gateway
- subnet: public subnet A
- Elastic IP allocation

2) edit private routes
- 기존 NAT Instance stop/terminal 시 status: Blackhole로 변경됨
- NAT Instance network interface -> NAT Gateway로 변경

Security Groups & NACLs

NACL: 요청이 EC2 인스턴스 내부로 이동하는 것

Network Access Control List (NACL)

서브넷을 오가는 트래픽을 제어하는 방화벽
서브넷마다 하나의 NACL이 있고, 새로운 서브넷에는 기본 NACL이 할당됨

1-32766번 (우선순위가 제일 높은 것은 1)
newly created NACLs will deny everything

Default NACL

연결된 서브넷을 가지고 inbound/outbound의 모든 요청을 허용하는 특수성을 가짐
기본 NACL을 수정하지 않는 것을 추천
기본적으로 NACL이 서브넷과 연결된다면 모든 것이 드나들도록 허용된다는 뜻

Ephemeral Ports

클라이언트와 서버가 연결되면 포트를 사용해야 함

Create NACL rules for each target subnets CIDR

다중 NACL 및 서브넷이 있다면 각 NACL 조합이 NACL 내에서 허용되어야 함, CIDR 사용 시 서브넷이 고유의 CIDR를 갖기 때문

NACL에 서브넷을 추가하면 NACL 규칙도 업데이트해서 연결 조합이 가능한지 확인해야 함

Hands-on#04 - NACLs

3) BastionHost ssh 연결

sudo yum install -y httpd
sudo systemctl enable httpd
sudo systemctl start httpd
echo "hello world" > /var/www/html/index.html
# 이전 명령을 sudo로 실행
sudo !!

# if permission denied
sudo su
echo "hello world" > /var/www/html/index.html

4) add security group HTTP

- public IP 접속 허용

5) edit Network ACLs inbound/outbound rules (for test)

- inbound rule: 80, type: http, source: 0.0.0.0/0, Deny
or outbound rules 100 Deny

- public IP 접속 차단

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 27

Vertical Scalability

수직 확장성, 인스턴스의 크기를 확장

Horizental Scalability

수평 확장, 애플리케이션에서 인스턴스나 시스템의 수를 늘리는 방법, 분배 시스템

High Availability

수직 확장, 적어도 2 데이터 센터(AZ)에서 애플리케이션을 구동시키는 것

High Availability & Scalability For EC2

scale out / in

What is load balancing?

서버 혹은 서버셋으로 트래픽을 백엔드나 다운스트림 EC2 instances 또는 서버들로 전달하는 역할
EC2 인스턴스가 3개, 인스턴스 앞에는 Load Balancer, 사용자는 ELB로 바로 연결됨

Why use a load balancer?

부하를 다수의 다운스트림 인스턴스로 분산하기 위해

Why use an Elastic Load Balancer?

a managed load balancer

다른 서비스들과 통합 가능

Health Checks

EC2 인스턴스가 잘 동작하는지 상태 확인, 포트와 라우트에서 이루어짐
e.g., protocol: HTTP, port: 4567, endpoint: /health -> 인스턴스 응답 200(OK)이 아니라면 unhealthy하다고 판단

Types of load balancer on AWS

Classic load balancer: HTTP, HTTPS, TCP, SSL (secure TCP), 현재는 AWS에서 지원하지 않음

Application Load Balancer(ALB): HTTP, HTTPS, WebSocket
Network Load Balancer(NLB): TCP, TLS (secure TCP), UDP
Gateway Load Balancer(GLB): Operates at layer 3 (Network layer)

Application Load Balancer (v2)

HTTP/2와 WebSocket이 가능
URL 대상 경로에 의한 라우팅이 가능함

Application Load Balancer (v2) Target Groups

EC2 인스턴스가 대상 그룹, ECS tasks, Lambda functions

Network Load Balancer (v2)

가용 영역별로 하나의 고정 IP를 갖는다는 점

Network Load Balancer - Target Groups

NLB를 ALB 앞에 배치하는 경우

NLB: 고정 IP 주소를 얻음, ALB: HTTP 유형의 트래픽을 처리하는 규칙을 얻음

Gateway Load Balancer

모든 로드밸런서보다 낮은 계층에서 동작

Users - GWLB - Target Group - GWLB - Application

uses the GENEVE protocol on port 6081

Sticky Sessions (Session Affinity)

고정성, 고정 세션을 실행, 1번째 클라이언트가 요청을 생성해 EC2에서 첫번째 인스턴스로 이동한다면, 새로운 요청을 했을 때에도 동일한 인스턴스로 이동하도록 함

Sticky Sessions - Cookie Names

고정 세션에는 2가지 유형의 쿠키가 있음, 애플리케이션 기반, 기간 기반 쿠키

Application-based Cookies

Logging IP traffic using Flow Logs

Target Group attributes stickiness 활성 시

Cross-Zone Load Balancing

EC2 인스턴스 2개짜리 로드 밸런서

Without Cross Zone Load Balancing: 각 가용영역 안에서 부하 분산됨

ALB의 Cross-zone LB는 항상 켜져 있음

SSL/TLS - Basics

SSL 인증서: 클라이언트와 로드 밸런서 사이 트래픽이 이동하는 동안 암호화, 전송 중(in-flight) 암호화

송신자-수신자 측에서만 복호화 가능

SSL: 보안 소켓 계층을 의미, 연결을 암호화하는데 사용
TLS: 새로운 버전의 SSL, 전송 계층 보안

퍼블릭 인증서는 인증 기관(CA)에서 발급, 인증 기관에는 Comodo, Symantec, GoDaddy, ...

Load Balancer - SSL Certificates

ACM: AWS Certificate Manager

SSL - Server Name Indication

SNI: 여러 개의 SSL 인증서를 하나의 웹 서버에 로드해 하나의 웹 서버가 여러 개의 웹 사이트에 지원할 수 있게 해줌

What's an Auto Scaling Group?

자동화

ASG(Auto Scaling Group)의 목표: scale out - 증가한 로드에 맞춰 EC2 인스턴스를 추가하거나, scale in - 감소한 로드에 맞춰 EC2 인스턴스를 제거하는 것

로드 밸런싱과 페어링하는 경우

Auto Scaling - CloudWatch Alarms & Scaling

CloudWatch 기반으로 ASG를 스케일 인 및 아웃할 수 있음

지표(metric), ASG 전체의 평균 CPU가 너무 높으면 EC2 인스턴스가 필요 -> 지표에 따라 경보가 울림 -> 경보가 ASG의 스케일링 활동을 유발함 -> 오토 스케일링 그룹이라고 불림 (경보에 의해 내부에서 자동적인 스케일링이 이루어짐)

Auto Scaling Groups - Dynamic Scaling Policies

세 가지 유형

Target Tracking Scaling(대상 추적 스케일링): 기본 기준선을 기준으로 상시 사용이 가능하도록
Simple / Step Scaling: CloudWatch 알람으로 CPU 사용률에 따라 유닛 하나를 추가/제거하는 설정 가능
Scheduled Actions

Auto Scaling Groups - Predictive Scaling

CPU 사용량, 인스턴스 요청이 갈 때마다 연산이 수행되어야 하므로
EC2 인스턴스를 갖는 오토스케일링 그룹, e.g., 요청 수 지표는 3
애플리케이션이 네트워크에 연결된 경우 평균 네트워크 입출력량을 기반으로 스케일링을 수행해서 임계값에 도달할 때 스케일링ㅇ을 수행하도록 설정
직접 CloudWatch에서 애플리케이션 별 지표를 설정하고 이를 기반으로 스케일링 정책을 변경

Auto Scaling Groups - Scaling Cooldowns

EC2 인스턴스 구성 시간을 단축하고 요청을 속히

search > install stress amazon linux 2

sudo amazon-linux-extras install epel -y
sudo yum install stress -y

stress -c 4

[Quiz#05]

1) EC2 인스턴스를 r4.large에서 r4.4xlarge로 확장하는 것은 수직 확장성

2) EC2 인스턴스 수를 스케일링하는 오토 스케일링 그룹을 실행하는 것은 수평 확장성

3) ELB는 애플리케이션에 사용 가능한 정적 DNS 이름을 제공함
- AWS 기반 인프라가 변경되어도, AWS가 정적 엔드 포인트를 사용해 로드 밸런스로 액세스할 수 있기를 원하는 이유

4) Elastic Load Balancer가 관리하는 10개의 EC2 인스턴스 상에서 웹사이트를 실행 중입니다. 웹사이트의 사용자들은 웹사이트에서 다른 페이지로 이동할 대마다 새로 인증을 해야한다는 점에 대해 불만을 토로하고 있습니다. 하지만 여러분의 기기와 하나의 EC2 인스턴스를 지닌 개발 환경에서는 아무 문제 없이 작동을 하고 있기 때문에 곤혹스러운 상황입니다. 무엇이 원인일까요? - ELB가 고정 세션을 활성화하지 않은 것
- ELB 고정 세션 기능은 동일한 클라이언트에 대한 트래픽이 항상 동일한 대상으로 리다이렉트되도록 해줌.(예: EC2 인스턴스) 이는 클라이언트들이 세션 데이터를 소실하지 않게 해줌

5) ALB
- X-Forwarded-Port: 클라이언트의 요청 포트를 가져오기 위해 사용
- X-Forwarded-Proto: 클라이언트의 요청 프로토콜을 가져오기 위해 사용

- X-Forwarded-For: (웹사이트로 연결된) 클라이언트의 IP 주소를 포함하는 헤더

6) Elastic Load Balancer가 관리하는 한 세트의 EC2 인스턴스 상에 애플리케이션을 호스팅했습니다. 일주일 후, 사용자들은 가끔씩 애플리케이션이 작동하지 않는다며 호소하기 시작했습니다. 문제점을 조사한 결과, 일부 EC2 인스턴스가 이따금 충돌한다는 문제점이 발견되었습니다. 사용자들이 충돌하는 EC2 인스턴스에 연결되지 않도록 보호하기 위해서는 어떻게 해야 할까요?

- ELB 상태 확인 활성화 -> ELB가 비정상(충돌) EC2 인스턴스로는 트래픽을 보내지 않게 됨

7) NLB: 가장 높은 성능, 가장 낮은 지연 시간

8) ALB 지원 프로토콜: HTTP, HTTPS, WebSocket / NLB: TCP, UDP

9) ALB는 트래픽을 다른 대상 그룹으로 라우팅할 수 있음 - 기반: 요청 URL 경로, 호스트 이름, HTTP 헤더, 쿼리 문자열, 소스 IP 주소

10) ALB 대상 그룹에 등록된 대상: EC2 인스턴스, 사설 IP 주소, Lambda 함수 등 (NLB는 등록된 대상이 될 수 없음)

11) ALB에 탄력적 IP를 연결할 수 없음, NLB는 AZ 당 하나의 정적 IP 주소를 가지며, 여기에 탄력적 IP 주소를 연결할 수 있음. ALB와 CLB를 정적 DNS 이름으로 사용할 수 있음

12) ELB가 선점하고 있는 쿠키 이름: AWSALB, AWSALBAPP, AWSALBTG

13) 영역간 로드 밸런싱을 활성화하면, ELB가 모든 AZ에 있는 등록된 EC2 인스턴스 전체에 동등하게 분배됨

14) ALB 기능 중 하나의 리스너로 다수의 SSL 인증서를 가져올 수 있도록 해주는 기능: 서버 이름 표식(SNI)

15) 호스트 이름을 기반으로, 트래픽을 3개의 대상 그룹으로 리다이렉팅하도록 구성된 ALB에서 각 호스트 이름에 HTTPS를 구성하려고 할 때 ALB에 서버 이름 표식(SNI)을 사용함

16) 오토 스케일링 그룹은 스케일 아웃 시, 구성된 최대 용량을 넘어설 수 없음

17) Application Load Balancer가 관리하는 오토 스케일링 그룹이 있습니다. ASG가 ALB 상태 확인을 사용하도록 구성을 해둔 상태인데, EC2 인스턴스가 비정상인 것으로 보고되었습니다. EC2 인스턴스에는 무슨 일이 일어나게 될까요?
- 오토 스케일링 그룹이 EC2 상태 확인(기본 설정)이 아닌 Application Load Balancer의 상태 확인을 기반으로 EC2 인스턴스의 상태를 판단하도록 구성할 수 있음. EC2 인스턴스가 ALB의 상태 확인에 실패할 경우, 이는 비정상인 것으로 표시되어 종료되며 ASG는 새로운 EC2 인스턴스를 실행함

18) 분당 요청 수를 기반으로 오토 스케일링 그룹을 스케일링할 때: 백엔드-데이터베이스 연결에는 ‘분당 요청'에 해당하는 CloudWatch 지표가 존재하지 않기에 CloudWatch 경보를 생성하려면 CloudWatch 사용자 지정 지표를 먼저 생성해야 함
- CloudWatch 사용자 지정 지표를 생성한 후 ASG를 스케일링하기 위한 CloudWatch 경보를 생성

19) ALB의 크기를 수동으로 조정해 EC2 인스턴스의 평균 연결 개수를 약 1,000개가 되도록 조정 정책을 정의하려고 할 때, 대상 추적 조정 정책을 수행함
- ALB만이 EC2 인스턴스로 액세스할 수 있게 하는 가장 안전한 방법임. 규칙에서 보안 그룹을 참조하는 것은 매우 강력한 규칙⭐️

20) 한 웹 사이트가 애플리케이션 로드 밸런서 뒤에 있는 오토 스케일링 그룹의 EC2 인스턴스에서 호스팅되고 있습니다. 현재 HTTP로 서비스 중인 웹 사이트를 HTTPS로 바꾸는 작업을 진행하고 있습니다. ACM 인증서를 발급받아 애플리케이션 로드 밸런서에 적용한 상태입니다. 사용자들이 HTTP가 아닌 HTTPS를 사용해 웹 사이트에 접속하게 하려면 어떻게 해야 합니까?
- 애플리케이션 로드 밸런서가 HTTP를 HTTPS로 리디렉션하도록 설정함

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 8

How can users access AWS?

three options: AWS Management Console, Command Line Interface(CLI), Software Developer Kit(SDK)

don't share your access keys

What's the AWS CLI?

AWS 서비스들과 상호작용할 수 있도록 도와주는 도구 (e.g., aws s3 cp)

What's the AWS SDK?

프로그래밍을 위한 액세스가 가능하도록 하는 것, 코딩을 통해 애플리케이션 내 자체적으로 지원, 프로그래밍 언어

search > aws cli install macos

aws --version

aws-cli/2.16.10 Python/3.11.8 Darwin/23.5.0 exe/x86_64

IAM > Users > (account) > Create access key

region: ap-northeast-2

aws iam list-users

AWS에 액세스하기 위해서는 관리 콘솔을 사용하거나 액세스 키와 비밀 액세스 키를 구성하여 CLI을 구성할 수 있다.

AWS CloudShell는 다음의 AWS 리전에서 사용할 수 있다.

• US East (Ohio)
• US East (N. Virginia)
• US West (N. California)
• US West (Oregon)
• Asia Pacific (Mumbai)
• Asia Pacific (Osaka)
• Asia Pacific (Seoul)
• Asia Pacific (Sydney)
• Asia Pacific (Singapore)
• Asia Pacific (Tokyo)
• Canada (Central)
• Europe (Frankfurt)
• Europe (Ireland)
• Europe (London)
• Europe (Paris)
• Europe (Stockholm)
• South America (São Paulo)

CloudShell: AWS 클라우드에서 무료로 사용 가능한 터미널

IAM Roles for Services

EC2 인스턴스: 가상 서버, AWS에서 어떤 작업을 수행하려고 할 때 권한을 부여하기 위해 IAM Role을 만들어 이들을 하나의 개체로 만든다. EC2 인스턴스가 AWS에 있는 어떤 정보에 접근(액세스)하려고 할 때 IAM Role을 사용한다.

Common roles: EC2 instance roles, Lambda function roles, roles for CloudFormation

IAM Security Tools

IAM Credentials Reports (account-level)
IAM Accesss Advisor (user-level)

IAM Guidelines &  Best Practices

one physical user = one AWS user

never share IAM users & access keys

IAM Section - Summary

Users, Group, Policies, Roles, Security, AWS CLI, AWS SDK, Access Keys, Audit

-

[Quiz#01]

IAM 사용자 그룹은 다른 사용자 그룹에 속할 수 없다. IAM 사용자만을 포함할 수 있다.

IAM 정책의 문장은 시드, 효과, 원칙, 조치, 리소스, 조건으로 구성된다. (버전은 IAM 정책 자체의 일부이며, 문장의 일부가 아니다.)

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03

Route 53

리전이 필요하지 않음: Global

ref: aws global infrastructure > AWS regional services 제공 서비스 및 가용성 확인

IAM: Users & Groups

Identity and Access Management, Global service
사용자 생성, 그룹에 배치하기 때문에 글로벌 서비스에 해당
Root account created by default + Users
- Groups은 사용자만 배치할 수 있음
- 그룹에 포함되지 않은 사용자가 있을 수 있음(비추천)

- 한 사용자가 다수의 그룹에 속할 수 있음

사용자와 그룹을 구성하는 이유

IAM: Permissions

사용자, 그룹에게 JSON 문서를 지정할 수 있음

최소 권한의 원칙(least privilege principle) 부여

IAM은 글로벌 서비스라 선택할 리전이 없음, 즉 IAM에서 사용자를 생성하면 어디에서나 사용할 수 있음

root를 사용하는 것은 바람직하지 않음, 사용자 생성 필요

IAM Policies Structure

Consists of

1) Version: 2012-10-17 - 정책 언어 버전

2) Id: 정책 식별(optional)

3) Statement

Ststement consists of

(1) Sid: 문장 ID, 문장 식별자(optional)

(2) Effect: 문장이 특정 API에 접근하는걸 허용할 지 거부할 지(Allow/Deny)

(3) Principal: 특정 정책이 적용될 사용자, 계정, 역할

(4) Action: API 호출 목록

(5) Resource: 적용될 action의 리소스 목록

-

[Troubleshooting#01]

Access denied

You don't have permission to iam:ListUsers. To request access, copy the following text and send it to your AWS administrator. Learn more about troubleshooting access denied errors. 

root 계정 IAM > Users > 계정 Permissions policies (0) > Add permissions > Attach policies directly - IAMReadOnlyAccess

User group was not created.
User: arn:aws:iam::058264561455:user/saraheee is not authorized to perform: iam:CreateGroup on resource: arn:aws:iam::058264561455:group/dev because no identity-based policy allows the iam:CreateGroup action

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03

AWS is a Cloud Provider
use on demand and scale easily

Services

AWS Regions

all around the world, names can be us-east-1, eu-west-3

a region is a cluster of data centers

How to choose an AWS Region?

1) Compliance(법률 준수): with data governance and legal requirements

2) Proximity(접근성) to customers: reduced latency

3) Available services within a Region

4) Pricing(요금): pricing varies region to region and is transparent in the service pricing page

AWS Availability Zones

Each region has many availability zones

(usually 3, min is 3, max is 6)

example: ap-southeast-2a, ap-southeast-2b, ap-southeast-2c

- they're separate from each other

- they're connected with high bandwidth, ultra-low latency networking

Tour of the AWS Console

Identity and Access Management (IAM)
Route 53 (DNS service)

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03