sehee

Route 53 - Routing Policies

라우팅 정책은 Route 53가 DNS 쿼리에 응답하는 것을 도움, DNS 관점(DNS는 트래픽 라우팅하지 않음, 트래픽은 DNS를 통과하지 않음)
- 로드 밸런서가 트래픽을 백엔드 EC2 인스턴스에 라우팅하는 것과는 다름
- DNS는 DNS 쿼리에만 응답하게 되고 클라이언트들은 이를 통해 HTTP 쿼리 등을 어떻게 처리해야 하는지를 알 수 있게 됨
- DNS는 호스트 이름들을 클라이언트가 실제 사용 가능한 엔드 포인트로 변환하는 것을 도움
Route 53이 지원하는 라우팅 정책: 단순, 가중치 기반, 장애 조치, 지연 시간 기반, 지리적, 다중 값 응답, 지리 근접 라우팅 정책
(Simple, Weighted, Failover, Latency based, Geolocation, Multi-Value Answer, Geoproximity (using Route 53 Traffic Flow feature)

Routing Policies - Simple

트래픽을 단일 리소스로 보내는 방식
클라이언트가 foo.example.com으로 가고자 한다면 Route 53이 IP 주소를 알려주는 것 (A 레코드 주소)
동일한 레코드에 여러 개의 값을 지정하는 것도 가능함. DNS에 의해 다중 값을 받은 경우에는 클라이언트 쪽에서 그 중 하나를 무작위로 고르게 됨 (e.g., 클라이언트가 foo.example.com으로 가기를 요청하고, Route 53은 세 개의 IP 주소로 답할 때(A 레코드에 임베딩된 주소), 클라이언트가 셋 중 하나를 골라 라우팅에 적용함)
단순 라우팅 정책에 별칭 레코드를 함께 사용하면 하나의 AWS 리소스만을 대상으로 지정할 수 있음 - 그렇기 때문에 상태 확인은 불가

Hands-on#04. Simple

value IP 추가하면서 테스트

Routing Policies - Weighted

가중치를 활용해 요청의 일부 비율을 특정 리소스로 보내는 식의 제어가 가능
한 DNS 이름 하에 있는 다른 레코드들과 비교했을 때 해당 레코드로 트래픽을 얼마나 보낼지, 각 레코드에 상대적으로 가중치를 할당함
이렇게 하면 DNS 레코드들은 동일한 이름과 유형을 가져야 하고 상태 확인과도 관련될 수 있음
사용되는 경우: 서로 다른 지역들에 걸쳐 로드 밸런싱을 할 때, 적은 양의 트래픽을 보내 새 애플리케이션을 테스트하는 경우
- 가중치 0의 값을 보내게 되면 특정 리소스에 트래픽 보내기를 중단해 가중치를 바꿀 수 있음
- 만약 모든 리소스 레코드 가중치의 값이 0인 경우는 모든 레코드가 다시 동일한 가중치를 갖게 됨

Hands-on#05. Weighted

Record ID: 가중치 레코드 설정에서 이 특정 레코드를 식별하기 위해 사용됨
- simple 레코드는 여러 개의 IP 주소를 가진 반면 weighted 세 개의 레코드는 각각 하나의 값을 가짐

Routing Policies - Latency-based

지연 시간이 가장 짧은, 가장 가까운 리소스로 리다이렉팅하는 정책
지연 시간에 민감한 웹사이트나 애플리케이션이 있는 경우 유용한 정책
지연 시간은 유저가 레코드로 가장 가까운 식별된 AWS 리전에 연결하기까지 걸리는 시간을 기반으로 측정
(e.g., 유저가 독일에 있고 미국에 있는 리소스의 지연 시간이 가장 짧다면, 해당 유저는 미국으로 리다이렉팅이 될 것)
- 두 개의 다른 리전에 애플리케이션을 배포할 때

Hands-on#06. Latency-based

별칭이 해당 IP가 어느 지역에 있는 EC2 인스턴스에서 왔다는 것을 알 수 없기 때문에,
값에 IP 주소를 입력해도 이 IP의 리전을 표시해줘야 함

Route 53 - Health Checks

상태 확인은 공용 리소스에 대한 상태를 확인하는 방법
e.g., (다중 지역 셋업) 서로 다른 두 지역에 하나씩 로드 밸런서가 있고 둘은 모두 공용 로드 밸런서임, 그리고 그 둘의 뒤에서 애플리케이션이 작동 중 - 지역 레벨에서 고가용성을 원하는 상황
- Route 53을 이용해 DNS 레코드를 만들 것
- 유저가 mydomain.com과 같은 URL을 이용해 접속하면 해당 유저는 가장 가까운 로드 밸런서로 연결됨 (지연 시간 기반 레코드)
만약 한 지역이 사용 불가능 상태면 유저를 보내고 싶지 않기 때문에 Route 53에서 상태 확인을 생성해야 함
- 두 지역의 상태 확인을 Route 53의 레코드와 연결할 수 있음 (DNS의 장애 조치를 자동화하기 위한 작업)
세 가지의 상태 확인(Health Check)이 가능함
- 각 상태 확인은 각자의 메트릭을 사용하는데 CloudWatch의 지표에서도 확인 가능
1) 공용 엔드 포인트를 모니터링하는 상태 확인
- 애플리케이션, 서버, 다른 AWS 리소스
2) 다른 상태 확인을 모니터링하는 상태 확인 (계산된 상태 확인)
3) CloudWatch 경보의 상태를 모니터링하는 상태 확인
- 제어가 쉽고 개인 리소스들에 유용함

Health Checks - Monitor an Endpoint

ALB에 대한 특정 지역의 상태 확인을 한다고 하면, 전 세계로부터 15개 정도의 AWS 상태 확인이 옴
→ 우리가 루트를 설정한 공용 엔드 포인트로 모두 요청을 보냄
→ 엔드 포인트의 상태를 확인하고 임계값을 정상 혹은 비정상으로 설정함 (200 OK 코드 또는 우리가 정의한 코드를 받으면 리소스는 정상으로 간주됨)
- 간격: 30초마다 정기적으로 확인 혹은 10초마다(더 높은 비용)
- 지원 프로토콜: HTTP, HTTPS, TCP
- 18% 이상의 상태 확인이 엔드 포인트를 정상이라고 판단하면 Route 53도 이를 정상이라고 간주함
- 상태 확인에 사용될 위치 선택 가능
- 로드 밸런서로부터 2xx나 3xx의 코드를 받아야만 통과가 됨
텍스트 기반 응답일 경우 상태 확인은 응답의 처음 5120 byte를 확인함 (응답 자체에 해당 텍스트가 있는지 보기 위해)
상태 확인의 작동이 가능하려면 상태 확인이 ALB나 엔드 포인트에 접근이 가능해야 함
Route 53의 상태 확인 IP 주소 범위에서 들어오는 모든 요청을 허용해야 함 (주소 범위는 https://ip-ranges.amazonaws.com/ip-ranges.json 참고)

Route 53 - Calculated Health Checks

여러 개의 상태 확인 결과를 하나로 합쳐주는 기능
- 조건: OR, AND, NOT
하위 상태 확인을 256개까지 모니터링할 수 있고 상위 상태 확인이 통과하기 위해 몇 개의 상태 확인을 통과해야 하는지도 지정할 수 있음
→ 상태 확인이 실패하는 일 없이 상위 상태 확인이 웹사이트를 유지 관리하도록 하는 경우

Health Checks - Private Hosted Zones

개인의 리소스를 모니터링하는 것은 어려울 수 있음
Route 53 상태 확인이 공용 웹에 있기 때문에 health checkers는 VPC 외부에 있음
개인 엔드 포인트에 접근 불가능 (개인 VPC나 온프레미스 리소스)
그래서 CloudWatch 지표를 만들어 CloudWatch 알람을 할당하는 식으로 이 문제를 해결할 수 있음
→ CloudWatch 경보를 상태 확인에 할당할 수 있음 (CloudWatch 메트릭을 이용해 개인 서브넷 안에 있는 EC2 인스턴스를 모니터링하는 것)
메트릭이 침해되는 경우 CloudWatch 알람을 생성하게 되고, 알람이 ALARM 상태가 되면 상태 확인은 자동으로 비정상이 됨
→ 개인 리소스에 대한 상태 확인 완료

Hands-on#07. Health Check

1) 엔드 포인트가 될 region 인스턴스의 상태 확인을 생성 (세 리전 모두)
path: /health (엔드 포인트 자체의 상태에 대한 응답)
Advanced configuration: String matching - 첫 5120 바이트 문자열을 비교할지 여부를 선택
2) 특정 region에 있는 한 인스턴스의 보안 그룹에서 80번 포트를 차단하고 security groups의 HTTP 관련 rule을 삭제 (상태 확인 장애를 발생시킴)
3) create health check - name: calculated / status of other health checks (calculated health check)
4) create health check - state of CloudWatch alarm
- 개인 EC2 인스턴스의 상태를 모니터링할 수 있음
- 개인 리소스의 상태 확인을 Route 53 상태 확인에 연결하는 것

Routing Policies - Failover (Active-Passive)

장애 조치에 관한 것
Route 53에 대해 하나는 기본 EC2 인스턴스, 하나는 보조 EC2 인스턴스(재해 복구 EC2 인스턴스)일 때
상태 확인과 기본 레코드를 연결하는데 필수적
상태 확인이 비정상이면 자동으로 Route 53은 두번째의 EC2 인스턴스로 장애 조치하며 결과를 보내기 시작함
보조 EC2 인스턴스도 상태 확인을 연결할 수 있지만 기본과 보조가 각각 하나씩만 있을 수 있음
→ 클라이언트의 DNS 요청은 정상으로 생각되는 리소스를 자동으로 얻음

Hands-on#08. Failover

상태 확인을 통해 장애 조치 레코드를 생성 (호스팅 영역에서 레코드를 생성)
보안 그룹 수정하여 장애 조치가 실행되는 위치를 확인

Routing Policies - Geolocation

사용자의 실제 위치를 기반으로 함 (지연 시간 기반의 정책과는 다르게)
사용자가 특정 대륙이나 국가 또는 어떤 주에 있는지 지정하는 것이며, 가장 정확한 위치가 선택되어 그 IP로 라우팅되는 것
일치하는 위치가 없는 경우는 기본 레코드를 생성해야 함
사용 사례: 콘텐츠 분산을 제한하고 로드 밸런싱 등을 실행하는 웹사이트 현지화
- 상태 확인과 연결할 수 있음
e.g., 유럽의 지도에서, 독일의 유저가 독일어 버전의 앱을 포함한 IP로 접속되도록 독일의 지리 레코드를 정의할 수 있음, 프랑스는 프랑스어의 버전의 앱을 가진 IP로 가야 함, 그 외의 다른 곳은 앱에서 영어 버전이 포함된 기본 IP로 이동해야 함

Hands-on#09. Geolocation

Location이 다른 IP에 대해 테스트

Geoproximity Routing Policy

사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅함
이 정책으로 편향값을 사용해 특정 위치를 기반으로 리소스를 더 많은 트래픽을 이동하는 것
→ 지리적 위치를 변경하려면 편향값을 지정해야 함, 특정 리소스에 더 많은 트래픽을 보내려면 편향값을 증가시켜서 확장하면 됨, 리소스에 트래픽을 줄이려면 편향값을 음수로 축소시키면 됨
리소스는 AWS의 리소스로 속한 특정 리전을 지정하면 목록에서 자동으로 올바른 라우팅을 계산하거나, AWS 리소스가 아닌 온프레미스 데이터 센터의 경우 위도와 경도를 지정해서 AWS가 위치를 파악하도록 해야 함
기능을 선택하는데 편향 활용을 위해 고급 Route 53 트래픽 플로우를 사용함
- 편향이 없다면, 사용자 위치에서 가장 가까운 리소스 리전으로 이동하는 것
- 편향으로 인해 다른 방식으로 사용자를 다른 리전으로 라우팅할 수 있음, 편향으로 해당 리소스에 더 많은 사용자와 트래픽이 발생함 (편향이 높을 경우)
예를 들어, 전 세계로 리소스를 설정하고 특정 리전에 더 많은 트래픽을 더 보내야 한다고 하면 지리 근접 라우팅 정책을 사용해 특정 리전의 편향을 증가시키면 더 많은 사용자가 생기게 되고 특정 리전에 더 많은 트래픽이 발생하게 됨
- 지리 근접 라우팅은 편향을 증가시켜 한 리전에서 다른 리전으로 트래픽을 보낼 때 유용하다는 것

Routing Policies - IP-based Routing

클라이언트 IP 주소를 기반으로 라우팅을 정의함 → Route 53에서 CIDR 목록을 정의함 (클라이언트 IP 범위) → CIDR에 따라 트래픽을 어느 로케이션으로 보내야 하는지를 정함
- 이것을 사용하면 성능을 최적화할 수 있음, IP를 미리 알고 있기 때문
- 네트워크 비용을 절감할 수 있음, IP가 어디에서 오는지 알기 때문
예를 들어 특정 ISP가 특정 IP 주소 셋을 사용하는걸 안다면 특정 엔드포인트로 라우팅할 수 있음
e.g., Route 53에서 두 로케이션을 서로 다른 두 CIDR 블록으로 정의함 (location-1: 203.x.x.x/24, location-2: 200.x.x.x/24)
→ 로케이션을 레코드에 연결 (record name: example.com / value: 1.2.3.4 and 5.6.7.8 / IP-based: location1 and location2)
- 이 값들은 두 개의 EC2 인스턴스의 공용 IP를 나타냄
→ 사용자 A가 location-1 CIDR blocks에 속하는 특정 IP로 들어오면 첫번째 EC2 인스턴스인 IP 1.2.3.4로 보내짐
+ 사용자 B가 location-2에 속하는 IP 주소로 들어오면 리디렉션되어 IP 5.6.7.8의 EC2 인스턴스에 대한 DNS 쿼리 응답을 받게 됨

Routing Policies - Multi-Value

- 트래픽을 다중 리소스로 라우팅할 때 사용함, 그래서 Route 53은 다중 값과 리소스를 반환함
- 상태 확인과 연결하면 다중 값 정책에서 반환되는 유일한 리소스는 정상 상태 확인과 관련이 있음
- 각 다중 값 쿼리에 최대 8개의 정상 레코드가 반환됨
- ELB와 유사해 보이지만 ELB를 대체할 수는 없음 (클라이언트 측면의 로드 밸런싱)
e.g., example.com에서 다중 A 레코드를 설정하고 상태 확인과 연결함
클라이언트에서 다중 값 쿼리를 실행하면 최대 8개의 레코드를 수신하게 되고 클라이언트는 하나를 선택함, 하지만 최소한 상태 확인과 결합하면 반환되는 8개 레코드 중 1개 혹은 최대 8개의 레코드가 정상일 것을 알고 있음
그래서 클라이언트는 안전한 쿼리를 가질 수 있음
e.g., 다중 값이 있는 단순한 라우팅의 경우에는 단순 라우팅 정책은 상태 확인을 허용하지 않기 때문에 단순 라우팅 정책의 쿼리가 반환하는 리소스 중 하나는 비정상일 가능성이 있음, 이것이 다중 값이 조금 더 강력한 레코드 유형인 이유

Hands-on#10. Multi-Value

세 리전에 대한 multi
Health checks에서 Invert health check status 체크하여 정상에서 비정상으로 변경

Domain Registar vs. DNS Service

도메인 이름 레지스트라를 통해 원하는 도메인 이름을 구매할 수 있음, 레지스트라를 통해 도메인을 등록하면 DNS 레코드 관리를 위한 DNS 서비스를 제공함, 그래서 Amazon 호스트 이름으로 DNS 이름을 등록했다면 DNS 레코드 관리를 위한 Route 53 호스팅 존을 가짐
도메인 이름을 등록하면 네임 서버 옵션이 생기는데 사용자 정의 이름 서버를 지정할 수 있음 (Route 53에서 원하는 도메인의 공용 호스팅 영역을 생성하고 호스팅 영역 상세의 우측 네임 서버를 구매한 사이트(GoDaddy 등)에서 변경해야 함)
GoDaddy에서 사용할 이름 서버에 관한 쿼리에 응답하면 네임 서버가 Amazon의 Route 53 이름 서버를 가리키고 그렇게 Route 53을 사용해서 해당 콘솔에서 직접 전체 DNS 레코드를 관리함
- 정리: 도메인을 타사 등록 대행사에서 구매해도 DNS 서비스 제공자로 Route 53을 사용 가능한데, 사용하려면 Route 53에서 공용 호스팅 영역을 생성한 뒤 도메인을 구매한 타사 웹사이트에서 NS 혹은 이름 서버를 업데이트하면 Route 53 이름 서버를 가리키게 됨
→ 도메인 이름 레지스트라는 모두 비슷해 보이지만 DNS 서비스가 다름

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 10: Route 53

DNS: Domain Name System which translates the human friendly hostnames into the machine IP addresses

DNS Terminologies (관련 용어)

Domain Registrar(도메인 이름 등록하는 곳): Amazon Route 53, GoDaddy, ...

DNS Records: A, AAAA, CNAME, NS, ...

Zone File: contains DNS records

Name Server: resolves DNS queries

1) Web Browser가 example.com에 접근하기 위해서는 Local DNS server에 물어볼 것
* Local DNS Server: 보통 회사에 의해 할당되고 관리되거나 ISP에 동적으로 할당됨
2) Local DNS Server가 이 쿼리를 본 적이 없다면 먼저 ICANN에 관리된 Root DNS Server에 물어볼 것
→ .com은 알고 있음 (.com NS 1.2.3.4) 반환
3) 1.2.3.4에 있는 .com 도메인 서버에게 쿼리의 답을 요청 (TLD DNS Server, Managed by IANA, Branch of ICANN)
→ DNS 서버는 example.com을 모르지만 example.com 이라는 서버는 알고 있음 (example.com NS 5.6.7.8)
4) 로컬 DNS 서버(서브도메인의 DNS 서버)에 질의: 도메인 네임 레지스트라(Route 53 등)에 의해 관리되는 서버, 최종 서버
→ example.com에 대해 알고 있음. example.com은 A 레코드이고 이것의 결과로 IP 9.10.11.12를 얻음

Route 53

a highly, available, scalable, fully managed and authoritative DNS, DNS 레코드를 업데이트할 수 있음
DNS 레코드를 아마존 Route 53의 호스팅 존에 쓰려고 함, 클라이언트가 example.com을 요청하면 Route 53 서비스가 IP 54.22.33.44를 찾고 있다고 응답함 → 클라이언트는 바로 EC2 인스턴스에 접근함, Route 53도 도메인 이름 레지스트라로 도메인 이름을 example.com으로 등록함
Route 53에서 여러 DNS 레코드를 정의하고 레코드를 통해 특정 도메인으로 라우팅하는 방법을 정의함
각 레코드는 도메인이나 example.com과 같은 서브도메인 이름과 같은 정보를 포함함
* TTL: DNS 리졸버에서 레코드가 캐싱되는 시간

Route 53 - Record Types

A - maps a hostname to IPv4
AAAA - maps a hostname to IPv6
CNAME - maps a hostname to another hostname
- 대상 호스트 이름은 A나 AAAA 레코드가 될 수 있음
- Route 53에서 DNS namespace 또는 Zone Apex의 상위 노드에 대한 CNAME을 생성할 수 없음
(e.g., example.com에 대한 CNAME을 만들 수는 없지만, www.example.com에 대한 CNAME 레코드는 만들 수 있음)
NS - Name Servers for the Hosted Zone
- 서버의 DNS 이름 또는 IP 주소로 호스팅 존에 대한 DNS 쿼리에 응답할 수 있음
- 트래픽이 도메인으로 라우팅되는 방식을 제어함

Route 53 - Hosted Zones

a container for records, 도메인과 서브도메인으로 가는 트래픽의 라우팅 방식을 정의함
Public Hosted Zones - 쿼리에 도메인 이름 application1.mypublicdomain.com의 IP가 무엇인지 알 수 없음
Private Hosted Zones - 공개되지 않은 도메인 이름을 지원, 가상 프라이빗 클라우드(VPC)만이 URL을 resolve할 수 있음(e.g., application1.company.internal)

Route 53 - Public vs. Private Hosted Zones

Public Hosted Zones: 공개된 클라이언트로부터 온 쿼리에 응답할 수 있음, 웹 브라우저에서 example.com을 요청하면 IP를 반환함
- 퍼블릭 레코드를 위한 호스팅 존
Private Hosted Zones: 해당 VPC에만 동작, 비공개 도메인 이름의 프라이빗 리소스를 식별할 수 있음
- 프라이빗 리소스, 예컨대, VPC에서만 쿼리할 수 있음

EC2 인스턴스가 1개 있고, webapp.example.internal을 식별하고자 함
또 다른 EC2 인스턴스에서는 api.example.internal을 식별하기 원하고 데이터베이스에서는 db.example.internal을 식별하고자 함
private hosted zone에 등록하고자 하는데, 첫번째 EC2 인스턴스가 api.example.internal을 요청하는 경우 프라이빗 호스팅 존은 프라이빗 IP 10.0.0.10이라는 답을 갖고 있음. EC2 인스턴스는 데이터베이스에 연결이 필요할 수도 있는 두번째 EC2 인스턴스에 연결하여 db.example.internal이 무엇인지 물어보면 프라이빗 호스팅 존은 프라이빗 IP를 알려줌

Hands-on#01. Route 53 setting up

1) Registered domains
2) Hosted zones - Create record A
3) cloudshell

sudo yum install -y bind-utils
nslookup domain.com
dig domain.com

4) Create EC2 Instances
- 서로 다른 리전에 세 인스턴스 생성(e.g., NRT, ICN, KIX - Tokyo, Seoul, Osaka)
- proceed without a key pair
- allow HTTP traffic from the internet

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
EC2_AVAIL_ZONE=$(curl -s http://169.254.169.254/meta-data/placement/availability-zone)
echo “<h1>Hello World from $(hostname -f) in AZ $EC2_AVAIL_ZONE </h1>” > /var/www/html/index.html

- Hello World 뒤에 인스턴스 정보를 출력할 것, 인스턴스가 시작되는 가용 영역도 포함시키는 과정에서 환경 변수 $EC2_AVAIL_ZONE을 사용
5) Create Load Balancer (DemoRoute53ALB)
- create TG
6) open addresses & LB에서 DNS name이 프로비저닝 되었는지 확인
ap-northeast-1(Tokyo): 54.199.162.15x
ap-northeast-2(Seoul): 43.201.64.18x
ap-northeast-3(Osaka): 13.208.191.12x

Route 53 - Records TTL (Time To Live)

클라이언트가 DNS Route 53와 웹 서버에 접속한다고 할 때,
myapp.example.com에서 DNS 요청을 보내면 DNS로부터 회신을 받음 (회신 내용: A 레코드, IP 주소, TTL(300초 정도))
TTL은 클라이언트에게 이 결과를 캐시하도록 요청함 (클라이언트는 300초 동안 결과를 캐시함)
→ 클라이언트가 재요청을 보내거나 같은 호스트 이름으로 접속할 경우, 클라이언트는 답변을 캐시에 저장해서 답을 알기 때문에 DNS 시스템에게 쿼리를 보내지 않아도 된다는 의미
하지만 캐시에도 시간이 소요되어 캐시 TTL이 발생, DNS 요청 쿼리를 계속해서 자주 보내는 상황을 원치 않기 때문
저장된 답변을 이용함으로써 웹 서버에 접속이 가능하고 HTTP 요청 및 회신을 보낼 수 있음
1) High TTL - e.g., 24 hr
TTL을 24시간으로 높게 설정하면 결과가 24시간 동안 캐시되므로 Route 53의 트래픽은 현저히 적음 (클라이언트가 요청을 적게 보냄)
-> 클라이언트가 오래된 레코드를 받을 가능성이 있음 (레코드를 바꾸고자 한다면 모든 클라이언트들이 새 레코드를 캐시에 저장할 때까지 24시간을 기다려야 한다는 뜻)
2) Low TTL - e.g., 60 sec.
TTL을 60초 정도로 짧게 설정한다면 DNS에는 트래픽 양의 많아져서 비용이 많이 듦 (Route 53에 들어오는 요청의 양에 따라 요금이 책정되기 때문)
오래된 레코드의 보관 시간은 짧아짐 -> 레코드 변경이 빨라짐

Hands-on#02. TTL

1) Create A record - IP region
2) record name으로 사이트 접속 혹은 cloudshell nslookup or dig
3) edit Record value
- 레코드 캐시가 만료될 때까지 확인

CNAME vs Alias

AWS 리소스(로드밸런서나 CloudFrond 등)를 사용하는 경우 호스트 이름이 노출됨, 그리고 보유한 도메인에 호스트 이름을 매핑하고자 할 수 있음
myapp.mydomain.com에 로드 밸런서를 매핑하는 경우 두 가지 옵션이 있는데,
1) CNAME 레코드로 호스트 이름이 다른 호스트 이름으로 향하도록 할 수 있음 (e.g., app.mydomain.com → blabla.anything.com)
- 루트 도메인 이름이 아닌 경우에만 가능 (aka. something.mydomain.com)
2) Alias: Route 53에 한정하여, 호스트 이름이 특정 AWS 리소스로 향하도록 할 수 있음 (e.g., app.mydomain.com → blabla.amazonaws.com)
- 루트 도메인과 비루트 도메인 모두에 작동함 (aka. mydomain.com, mydomain.com을 별칭으로 사용해 AWS 리소스로 향하도록 할 수 있음)
- 무료, 자체적으로 상태 확인 가능

Route 53 - Alias Records

AWS 리소스에만 매핑이 되어 있음
예를 들어 Route 53에서 example.com을 A 레코드의 별칭 레코드로 하고 그 값은 로드 밸런서의 DNS 이름을 지정하려 한다고 해보자.

기반이 되는 ALB에서 IP가 바뀌면 별칭 레코드는 바로 인식함
CNAME과 달리 별칭 레코드는 Zone Apex라는 DNS 네임 스페이스의 상위 노드로 사용될 수 있음
AWS 리소스를 위한 별칭 레코드의 타입은 항상 A 또는 AAAA (리소스는 IPv4나 IPv6 중 하나)
별칭 레코드를 사용하면 TTL을 설정할 수 없음 (Route 53에 의해 자동으로 설정됨)

Route 53 - Alias Records Targets

별칭 레코드의 대상은? ELB, CloudFront 배포, API Gateway, Elastic Beanstalk environments, S3 Websites(S3 버킷은 안됨, 버킷들이 웹사이트로 활성화될 시 S3 웹사이트는 가능), VPC Interface Endpoints, Global Accelerator accelerator, Route 53 record in the same hosted zone
- EC2의 DNS 이름은 별칭 레코드의 대상이 될 수 없음

Hands-on#03. CNAME vs. Alias

1) create CNAME record
- value: ALB DNS name
2) create A record
- Alias > Route traffic to ALB
- 별칭 레코드이기 때문에 Evaluate target health는 자동으로 Yes 체크되어 있음
3) create A record without subdomain

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 10: Route 53

0. Connecting to an Instance

AWS CLI를 사용하여 인스턴스의 Linux OS 플랫폼 및 버전 정보 확인

uname
cat /proc/version

Linux version ~ ... ~ (Red Hat 11.4.1-2), ~ ...

Redhat 계열(centOS) - yum
Debian, Ubuntu - apt-get

1. Installing Nginx

nginx directory 생성
Nginx: 정적 컨텐츠를 제공해주는 프록시 서버

sudo yum install nginx
cd /etc && ls | grep nginx // check settings

sudo mkdir /etc/nginx/sites-available
sudo mkdir /etc/nginx/sites-enabled

2. Setting up config

1) nginx.conf 수정
: nginx 관련 설정을 블록 단위로 설정, sites-enable에 존재하는 파일 불러옴

sudo vi /etc/nginx/nginx.conf

    include /etc/nginx/sites-enabled/*.conf;

#    server {
#        listen       80;
#        listen       [::]:80;
#        server_name  _;
#        root         /usr/share/nginx/html;
#
#        # Load configuration files for the default server block.
#        include /etc/nginx/default.d/*.conf;
#
#        error_page 404 /404.html;
#        location = /404.html {
#        }
#
#        error_page 500 502 503 504 /50x.html;
#        location = /50x.html {
#        }
#    }

2) server 설정
: nginx 최신 버전을 따로 설치하지 않고 기본 설정된 repository에 있는 버전을 install nginx로 바로 설치한 경우에는 nginx 환경 설정 파일 위치가 /etc/nginx/sites-available/default로 설정됨,
최신 버전을 설치했을 경우 /etc/nginx/conf.d/default.conf [5]

sudo vi /etc/nginx/sites-available/default.conf

    server {
        listen 80;
        location / {
                root /project/nginx-project;  // path to deploy
                index index.html index.htm;
                try-files $url $url/ /index.html;
        }       
    }   

3) symbolic link 설정
: sites-enabled directory에 default.conf 바로가기 생성
sites-available에 존재하는 설정 파일들 중, 사용하는 설정 파일만 link해서 사용할 수 있도록 하는 디렉터리

cd /etc/nginx/sites-enabled
sudo ln -s /etc/nginx/sites-available/default.conf
ls -l

total 0
lrwxrwxrwx. 1 root root 39 Jul 30 04:42 default.conf → /etc/nginx/sites-available/default.conf
4) 웹서버 html 설정

sudo vi /project/nginx-project/index.html

<!DOCTYPE html>
<html>
<head>
    <title>Welcome to Nginx!</title>
</head>
<body>
    <h1>Welcome to Nginx!</h1>
    <p>If you see this page, the Nginx web server is successfully installed and working.</p>
    <p>Further configuration is required.</p>
</body>
</html>

3. Run the server

sudo systemctl start nginx

오류 시
status : Failed to start nginx.service - The nginx HTTP and reverse proxy server

sudo systemctl start nginx

Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xeu nginx.service" for details.

: 80번 포트에 수신 대기중인 프로세스 삭제

fuser -k 80/tcp

4. Prepare SSL/TLS Certificate

- Generate a self-signed certificate or obtain a certificate from a Certificate Authority (CA)
1) Ensure that OpenSSL is installed on your operating system

openssl version

nginx가 ssl 적용이 가능한 모듈이 있는지 확인 (--with-http_ssl_module)

nginx -V

nginx version: nginx/1.24.0
built with OpenSSL 3.0.8 7 Feb 2023
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-compat --with-debug --with-file-aio --with-google_perftools_module --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_degradation_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_mp4_module --with-http_perl_module=dynamic --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-http_xslt_module=dynamic --with-mail=dynamic --with-mail_ssl_module --with-openssl-opt=enable-ktls --with-pcre --with-pcre-jit --with-stream=dynamic --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads --with-cc-opt='-O2 -ftree-vectorize -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' —with-ld-opt='-Wl,-z,relro -Wl,—as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,—build-id=sha1 -Wl,-dT,/builddir/build/BUILD/nginx-1.24.0/.package_note-nginx-1.24.0-1.amzn2023.0.2.x86_64.ld -Wl,-E’

2) 인증서 작업할 폴더 생성 (/usr/local/ssl)
3) Generate the Private Key
- Use the following OpenSSL command to generate the private key: 

openssl genrsa -des3 -out server.key 2048

Enter PEM pass phrase: 
> server.key 생성

4) Create a Certificate Signing Request (CSR)
- Use the following OpenSSL command to generate the certificate signing request (CSR) file: 

openssl req -new -key server.key -out server.csr

- During this process, you will be prompted to enter information such as country, state, city, company name, and domain name

5) Generate the Self-Signed Certificate
- Use the following OpenSSL command to generate the self-signed certificate: 

openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt

- -days 3650: 3650일짜리(10년) 인증서
- -in server.csr -signkey server.key: 개인 키와 서버 요청서를 가지고 인증서 server.crt 생성

5. Configure the Nginx configuration file

- Add the following HTTPS-related settings inside the server block: 
- Use the listen directive to specify port 443
- Use the ssl_certificate and ssl_certificate_key directives to specify the paths to the certificate files

> cd /etc/nginx/conf.d/
> sudo cp www.example.com.conf www.example.com.conf.bak
> sudo mkdir /etc/nginx/ssl
> sudo chmod 700 /etc/nginx/ssl
> sudo nano www.example.com.conf

server {
    listen       443 ssl;
    server_name  www.example.com;

    ssl_certificate /usr/local/ssl/server.crt;
    ssl_certificate_key /usr/local/ssl/server.key;
    
    ## omitted below
}

+ 공인 인증기관에서 발급하지 않은 인증서는 윈도우에서 host 파일을 수정하여 접근할 것
(참고)

vi /etc/nginx/conf.d/default.conf
vi /etc/nginx/sites-available/default.conf

    server {
            listen      443 ssl;
            server_name nginx-ssl-test.com;
            
            ssl_certificate     /usr/local/ssl/server.crt;
            ssl_certificate_key /usr/local/ssl/server.key;
            ssl_session_timeout 5m;
            ssl_protocols       SSLv2 SSLv3 TLSv1;
            ssl_ciphers         HIGH:!aNULL:!MD5;
            ssl_prefer_server_ciphers   on;
            
            location / {
                    root        /home/espeniel;
                    index       index.html index.htm;
            }       
    }   

6. Set up HTTP to HTTPS redirection

- Configure the server block to redirect HTTP (port 80) requests to HTTPS
- Use the return 301 directive to achieve the redirection

vi /etc/nginx/sites-available/default.conf

server {
    listen       80 default_server;
    server_name  nginx-ssl-test.com;
    return 301 https://$host$request_uri;
}

- nginx 서비스 확인

ps -ef | grep nginx

systemctl restart nginx

오류 시
(1) /usr/local/ssl/server.key 파일의 권한과 소유자 확인

sudo chmod 644 server.key
sudo chown nginx:nginx server.key

(2) openssl rsa -check -in /usr/local/ssl/server.key
(3) 로그 확인

sudo journalctl -u nginx

Jul 30 08:59:35 ip-172-31-39-33.ec2.internal nginx[3006]: nginx: [emerg] cannot load certificate key "/usr/local/ssl/server.key": PEM_read_bio_PrivateKey() failed (SSL: error:1400006B:UI routines::processing error:while reading strings error:0480006D:PEM routin>
Jul 30 08:59:35 ip-172-31-39-33.ec2.internal nginx[3006]: nginx: configuration file /etc/nginx/nginx.conf test failed

→ The private key has a passphrase requirement but nginx is not configured to use a passphrase.

7. delete key passphrase

1) Rename the existing server.key filename to server_pass.key

mv server.key server_pass.key

2) Create a new key without a passphrase requirement. It is assumed that the RSA key in use, otherwise adjust the command accordingly. When prompted, type the passphrase and press enter

openssl rsa -in server_pass.key -out server.key

3) Stop, start nginx service and check that no error message are displayed

8. local test
- www.example.com은 공인된 도메인이 아니라 사내에서 사용할 가상 도메인이므로 클라이언트 측 도메인에 대한 hosts 파일을 등록해야 함

9. (optional) Additional SSL/TLS-related Settings
- Use the ssl_session_cache and ssl_session_timeout directives to configure the SSL session cache
- Use the ssl_prefer_server_ciphers direcactive to prefer the server's cipher suites
- Use the add_header directive to add security-related headers

10. Test Configuration and Restart Nginx
- Use the nginx -t command to check the syntax of the configuration file
- Use the systemctl restart nginx command to restart the Nginx service

sudo nginx -t
sudo nginx -s reload

References:

[1] [AWS] EC2 인스턴스에 Nginx 적용하기
[2] [AWS] EC2 NGINX 설치하고 Config설정 및 배포하기
[3] OpenSSL로 개인키 발급 및 SSL 인증서 생성#1
[4] Nginx https 적용하기 openssl 사용, http https로 리다이렉트
[5] Ubuntu에서 Nginx SSL 인증서 설정하는 방법
[6] DPSearch - Nginx service fails to start after installing new SSL certificate

Topics

What is VPC?

AWS Service scope with respect to Region, AZ and VPC

AWS Services inside and outside of VPC

VPC Addressing (CIDR)

VPC Subnets and Route Tables (Public/Private)

IP Addresses (IPv4, IPv6, Private/Public/Elastic)

Security Groups and Network ACL

NAT gateway and NAT instance

Transit Gateway: 2018년 출시한 네트워킹 라우터

VPC의 서브넷: 개별 LAN 네트워크, VPC로부터의 작은 주소 범위

서브넷이 사용자 지정 route table을 생성하여 Main Route Table을 따르지 않으면, 두 다른 AZ의 서브넷이 Local Router를 통해 연결할 수 없음

VPC의 모든 서브넷이 같은 종류의 네트워크 연결을 원할 경우 메인 루트 테이블 수정

Amazon에서 제공하는 IPv6 DNS가 없음

Security groups are stateful

Network Access Control List(NACL):

1) works at Subnet level

2) Stateless(inbound/outbound 별도)

3) contains both Allow and Deny rules

4) 규칙 번호 순서대로 평가

5) default NACL allows all inbound and outbound traffic
6) NACL are a great way of blooking a specific IP at the subnet level

Hands-on#01

1) create VPC public

2) create Internet Gateways > Attach to VPC

3) create subnet > modify auto-assign IP settings

4) create Route Table > routes 0.0.0.0/0 IGW

VPC 내 고립된 라우트 테이블

5) create VPC private

VPC secondary CIDR blocks

ENI: IP 주소 제공, 네트워크 통신 가능하게 하는 VPC의 논리적 구성 요소, 가상 네트워크 카드

IP주소는 EC2 인스턴스를 실행할 때 AWS가 만드는 ENI를 이용해 할당됨

Bring Your Own IP

Hands-on#02

EC2 인스턴스 2개 - app / DB server

Domain-name = corp.internal

Steps

1) Create a VPC with Public & Private subnet

2) (Optional) Create DHCP Option set with domain as corp.internal and associate with your VPC

- Domain name: corp.internal / Domain name servers: AmazonProvidedDNS

- Edit VPC settings: option set - corp.internal

3) Launch one EC2 instance in Public subnet (say app) and one instance in Private subnet (say db).

- Allow SSH (source type: My IP) and ICMP IPv4 (source type: 10.0.0.0/16) in the security group

4) Create Route 53 Private hosted zone and associate with the VPC

- NS, SOA + app (10.10.0.206), db (10.10.1.173)

5) Create A records for ec2 instances pointing to their Private IPs

6) SSH into Public EC2 instance and ping to other instance using it's DNS name

- cat /etc/resolv.conf : nameserver

- ping db.corp.internal or ping db

VPC DNS with custom DNS server

Step - Setup a VPC and launch instances

- Create a VPC with public and private subnets

- Launch DNS server ec2 instance: Security group to allow UDP 53 from VPC CIDR, SSH (22)

- Launch an app server & db server ec2 instances: Security group to allow SSH (22), ICMP IPv4 All (ping)

----------------------------------------------
Step 4a – Configure on-premise DNS server
----------------------------------------------
1. Login to on-premise DNS server (via SSH into VPN server first)
2. Install DNS server packages

sudo su
yum update –y
# DNS를 위한 패키지 설치, util을 binding
yum install bind bind-utils –y

3. Create file /var/named/corp.internal.zone

$TTL 86400
@ IN  SOA     ns1.corp.internal. root.corp.internal. (
  2013042201  ;Serial
  3600        ;Refresh
  1800        ;Retry
  604800      ;Expire
  86400       ;Minimum TTL
)
; Specify our two nameservers
IN  NS    dnsA.corp.internal.
IN  NS    dnsB.corp.internal.
; Resolve nameserver hostnames to IP, replace with your two droplet IP addresses.
dnsA IN  A   1.1.1.1
dnsB IN  A   8.8.8.8
; Define hostname -> IP pairs which you wish to resolve
@ IN  A   10.0.11.191
app IN A   10.0.11.191
db IN A   10.0.0.221

# APP 10.0.11.191
# DB 10.0.0.221

4. Create file /etc/named.conf [Replace X.X with your DNS server IP]

options {
  directory "/var/named";
  dump-file "/var/named/data/cache_dump.db";
  statistics-file "/var/named/data/named_stats.txt";
  memstatistics-file "/var/named/data/named_mem_stats.txt";
  allow-query { any; };
  allow-transfer { localhost; 10.0.11.191; };
  recursion yes;
  forward first;
  forwarders {
    10.0.0.2;
  };
  dnssec-enable yes;
  dnssec-validation yes;
  dnssec-lookaside auto;
  /* Path to ISC DLV key */
  bindkeys-file "/etc/named.iscdlv.key";
  managed-keys-directory "/var/named/dynamic";
};
zone "corp.internal" IN {
    type master;
    file "corp.internal.zone";
    allow-update { none; };
};

# DNS 10.0.11.191

5. Restart named service

service named restart
chkconfig named on

+ create DHCP Option sets

+ edit VPC DHCP option set

+ reboot App, DNS, DB server

----------------------------------------------
Step 5b – Configure on-premise DNS server
----------------------------------------------
1. Add following to /etc/named.conf. Replace ENDPOINT IPs with Route53 inbound resolver IPs.

zone "cloud.com" { 
  type forward; 
  forward only;
  forwarders { INBOUND_ENDPOINT_IP1; INBOUND_ENDPOINT_IP2; }; 
};

2. Restart named service
sudo service named restart

VPC DNS & DHCP exam essentials

- VPC has a default DNS server AmazonProvidedDNS

ALB는 여러 Listener를 가지며, 한 listener 당 한 가지 이상의 rule이 존재

e.g., Listener 1이 target group에 트래픽을 보내는 한 가지 규칙이 있을 때

target group은 여러 target을 갖고 있음 EC2 인스턴스나 health check 등

ALB는 TG에 등록된 target으로 요청을 라우팅하기 전에 사용자를 인증할 수 있음

ALB에 SSL, TLS, SSL 인증서를 로드할 수 있음

NLB는 두 AZ 사이에 있고, 클라이언트는 NLB에 연결되어 있음

NLB는 고정된 IP 주소가 있어서 고정 IP로 ENI에 연결됨

NLB는 AZ당 고정 IP가 하나 있어서 elastic IP를 할당할 수 있음

EC2 instance가 NLB의 다른 VPC에 있다면, 이 인스턴스를 NLB에 ID로 등록할 수 없음

ID로 인스턴스를 등록하거나 ECS 작업 내에서 자동으로 클라이언트의 IP는 보존되고 EC2 인스턴스는 클라이언트로부터 직접 발생하는 트래픽을 봄

NLB가 3개의 AZ로 활성화되어 있고 NLB DNS 이름에 대한 DNS 쿼리를 하면 3개의 IP를 갖게 됨, 활성화되어 있는 3개의 AZ와 부합함

NLB는 각 노드에 대해 DNS 이름을 갖고, 사용 가능한 AZ에 기반해 DNS name을 써서 IP 주소 하나만 확인할 수 있음

Connection Idle Timeout

client-ELB connection & ELB-target connection

NLB works without cookies

SSL - Server Name Indication (SNI): 다중 SSL 인증서를 하나의 웹 서버에 로딩하는 문제를 해결함 (다중 웹사이트와 도메인을 지원하는 서버)

Hands-on#01: ALB X-Forwarded Headers

1) create instance

instance user data

#!/bin/bash
# Use this for your user data (script without newlines)
# Installs httpd (Linux 2 version)
yum update -y
yum install -y httpd.x86_64
systemctl start httpd
systemctl enable httpd
echo "Hello World from $(hostname -f)" > /var/www/html/index.html

2) create ALB

- create TG

3) connect ssh

4) Edit the file httpd.conf, edit the LogFormat section with the following

sudo nano /etc/httpd/conf/httpd.conf

<IfModule log_config_module>

#

# The following ... a CustomLog directive (see below).

# 

>> LogFormat "%{X-Forwarded-For}i %{X-Forwarded-Proto}i %{X-Forwarded-Port}i ...

5) Reload Apache

sudo systemctl reload httpd

6) Run the following command to watch your Apache Access Logs

sudo tail -f /var/log/httpd/access_log

172.31.x.x - - [19/Jul/2024:09:26:59 +0000] "GET / HTTP/1.1" 200 64 "-" "ELB-HealthChecker/2.0"
172.31.y.y - - [19/Jul/2024:09:27:07 +0000] "GET / HTTP/1.1" 200 64 "-" "ELB-HealthChecker/2.0"
...
- - - 172.31.x.x - - [19/Jul/2024:09:28:59 +0000] "GET / HTTP/1.1" 200 64 "-" "ELB-HealthChecker/2.0"
- - - 172.31.y.y - - [19/Jul/2024:09:29:07 +0000] "GET / HTTP/1.1" 200 64 "-" "ELB-HealthChecker/2.0"
15.248.a.a http 80 172.31.x.x - - [19/Jul/2024:09:29:53 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"
15.248.b.b http 80 172.31.x.x - - [19/Jul/2024:09:29:53 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"

- 기존에는 X-Forwarded 헤더가 없지만, ALB DNS name으로 접속(새로고침) 시 IP, protocol, port 정보 확인

Hands-on#02: NLB Proxy Protocol

1) create instance (same user data)

2) create NLB

- create TG

  - choose type IP addresses

  - VPC subnet: EC2 instance private addresses

3) repeat #01 6)

# public IP
15.248.a.a - - [19/Jul/2024:10:02:22 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"
# NLB DNS
172.31.x.x - - [19/Jul/2024:10:02:28 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"

4) edit TG attributes

- Traffic configuration: enable Proxy protocol v2, Preserve client IP addresses

5) Verify the module mod_remoteip loaded successfully

sudo /usr/sbin/httpd -M | grep -i remoteip

You'll have the following output

> remoteip_module (shared) - 원격 IP 모듈이 응답으로 공유되었다면 모듈이 성공적으로 로드됐다는 의미

6) edit the file

sudo nano /etc/httpd/conf/httpd.conf

Add this line to enable Proxy Protocol - Listen 80 다음 줄에 삽입

>> RemoteIPProxyProtocol On

7) repeat #01 5), 6)

# NLB DNS
15.248.a.a - - [19/Jul/2024:10:12:26 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"

- NLB와 EC2 instance 사이에 proxy protocol이 작동한다는 것을 증명

References

Udemy, Pass the AWS Certified Advanced Networking Specialty Certification ANS-C01. Taught by an AWS Networking and VPC Expert!, Section 18: Elastic Load Balancers

 
CloudFront: 뛰어난 성능, 보안 및 개발자 편의를 위해 구축된 콘텐츠 전송 네트워크(CDN) 서비스
CloudWatch: 온프레미스 및 기타 클라우드에서 리소스 및 애플리케이션을 관측하고 모니터링
CloudTrail: AWS와 하이브리드 및 멀티클라우드 환경에서 사용자 활동과 API 사용량 추적
Snowball: 페타바이트 규모의 데이터를 AWS로 마이그레이션
Aurora: 기본 제공 보안, 연속적인 백업, 서버리스 컴퓨팅, 최대 15개의 읽기 전용 복제본, 자동 다중 리전 복제 및 다른 AWS 서비스와의 통합을 제공
Redshift: SQL을 사용하여 여러 데이터 웨어하우스, 운영 데이터베이스 및 데이터 레이크에서 정형 데이터 및 반정형 데이터를 분석하고 AWS가 설계한 하드웨어 및 기계 학습을 사용해 어떤 규모에서든 최고의 가격 대비 성능을 지원
Kinesis: 모든 규모의 스트리밍 데이터를 비용 효율적으로 처리하고 분석하는 완전관리형 서비스
Glacier: 최저 비용과 밀리초 단위의 액세스로 데이터를 보관할 수 있는 안전하며 내구성 있는 장기 스토리지 클래스
Macie: 데이터 보안 및 데이터 프라이버시 서비스로서, 기계 학습(ML) 및 패턴 일치를 활용하여 민감한 데이터를 검색하고 보호
Inspector: 규모에 맞는 지속적인 자동 취약성 관리, Amazon EC2 인스턴스, 컨테이너 및 Lambda 함수와 같은 워크로드를 자동으로 검색하고 소프트웨어 취약성과 의도하지 않은 네트워크 노출이 있는지 스캔
Athena: 오픈소스 프레임워크에 구축된 서버리스 대화형 분석 서비스로 개방형 테이블과 파일 형식을 지원, 페타바이트 규모의 데이터를 상주 위치에서 분석하는 간소화되고 유연한 방식을 제공
FSx for Windows File Server: Windows Server에 구축된 완전관리형 공유 스토리지와 함께 다양한 데이터 액세스, 데이터 관리 기능을 제공
FSx for Lustre: 널리 사용되는 Lustre 파일 시스템의 확장성과 성능을 가진 완전관리형 공유 스토리지를 제공
Rekognition: 기계 학습을 통해 이미지 인식 및 비디오 분석을 자동화하고 비용을 절감
SageMaker: 완전관리형 인프라, 도구 및 워크플로를 활용하여 모든 사용 사례에 적합한 기계 학습(ML) 모델을 구축, 훈련 및 배포
Fargate: 컨테이너에 적합한 서버리스 컴퓨팅
Secrets Manager: 보안 암호의 수명 주기를 중앙에서 관리
Comprehend: 기계 학습을 사용하여 텍스트에서 유용한 인사이트 및 관계를 찾아내는 자연어 처리(NLP) 서비스
Glue: 분석, 기계 학습(ML) 및 애플리케이션 개발을 위해 여러 소스에서 데이터를 쉽게 탐색, 준비, 이동 및 통합할 수 있도록 하는 확장 가능한 서버리스 데이터 통합 서비스
Fargate: 컨테이너에 적합한 서버리스 컴퓨팅

 
port 1433 is the default port for SQL Server communication
 
API Gateway + Lambda
CloudFront + ALB + ASG
CloudFront + S3
ALB + ASG with Multi-AZ
 
 

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