aws 도메인 등록

A 레코드 

 

도메인 이름을 test라고 지정 레코드 타입은 A로 지정 IP 주소는 무작위로 입력을 해주었습니다. TTL -> 타임 투 리브 300초로 지정 라우티은 Simple 지정

 

 

해당 서버가 없기때문에   11.22.33.44 을 연결을 해도 아무것도 없을겁니다

 

 

aws의 cloudTrall 환경에 접속합니다. 만약 윈도우에서는 nslookup 명령어를 해주시면 됩니다.  sudo yum install -y bind-uutils 를 설치 해줍니다. 이제 nslookup  test.stephanietheacher.com 을 명령어 입력합니다. 11.22.33.44 로 보내지는걸 확인할수있습니다. 그리고 dig URL 을 입력하면 좀더 자세한 화면을 볼수있습니다.

 

 

다시 접속하면 확인할수있다

 

CNAME 레코드

 

레코드 타입은 CNAME으로 하고 볼륨에는 ALB URL주소 입력했습니다.

 

 

결과 화면입니다. 저는 인스턴스 3개를 리전을 다르게 해서 로드밸런서를 등록했습니다.

 

Alias 별칭 레코드

 

전에 방법 보다 더 좋은 방법이있습니다 Alias를 키고 Load Balaner를 선택합니다. 이후 URL을 접속 하면 됩니다.

 

 

여기서 저는 stephanetheteacher.com 만으로 사용해 이페이지로 리다이렉트로 하려는 경우 오류나 나옵니다. apex에 허용되지 않는다고 합니다. 이것은 이 구역은 stephanetheteacher.com이며 apex도 stephanetheteacher.com 이기 때문에 설정을 할 수 없습니다. 이걸 해결 방법은

 

 

별칭 레코드를 사용해주시면 해결이됩니다.

 

Multiple Value 

 

 

Value을 여러개를 넣을 수 있습니다.

 

가중치

 

각 레코드에 가중치 값을 설정할 수 있습니다. 높은 가중치 일수록 첫번쨰 인스턴스로 리다이렉팅합니다.

 

 

값을 입력할수있습니다.

 

 

3개의 레코드를 만들면 70값이 먼저이고 두번쨰는 20값이 입니다.

 

대기시간

 

지연 시간 라우팅 정책은 가장 가까운 리소스로 리다이렉팅을 하는 정책입니다. 지연 시간이 민감한 웹사이트나 애플리케이션이 있는 경우에 아주 유용한 정책입니다.

 

 

각각 다른 리전을 설정했습니다.

 

 

윈도우 확인 지금은 이런게 나오지만 만약 VPN으로 다른곳으로 옮기면 이 화면 리전도 바뀌게 된다

 

상태 확인

 

 

 

 

 

상태 확인 요청 간격에 관한 표준인 30초와 더 빠른 10초를 선택할 수 있는데 10초는 비용이 더 들기 때문에 30초를 선택합니다. 장애로 간주되기 전에 몇 번의 장애가 발생해야 하는지를 설정합니다. 시간 경과에 따른 지연 시간 확인을 지연 시간 그래프를 볼지 선택합니다.  상태를 바꿀지도 선택할 수 있는데 정상에서 비정상 혹은 그 반대입니다. 비활성화도 가능합니다. 상태 확인의 리전을 지정하거나 권장 사항을 선택할 수 있는데 권장 사항을 선택겠습니다.

 

 

상태 확인 장애 시 알림을 받을지 여부를 선택합니다. 지금은 선택하지 않겠습니다.

 

 

같은 방법으로 두개 더 만들었습니다 이제 싱가폴에 있는 인스턴스의 보안 그룹에서 80번 포트를 차단하고 이 규칙을 삭제하겠습니다.

 

 

나머지는 정상으로 나오지만 싱가폴만 오류로 나옵니다.

 

 

더 자세한 내용도 볼수있습니다.

 

 

모니터링할수있는 상태 확인 설정입니다.

 

라우팅 정책 장애 조치

 

 

 

현재 상태는 정상입니다.

 

 

us-central-1 리전에 가서 보안그룹 정책을 삭제 해줍니다.

 

 

us-central-1를 보면 비정상인걸 확인할수있습니다.

 

 

모니터랩을 보면 1에있다가 0으로 바뀐걸 볼수있습니다.

 

 

URL을 새로고침을 하면 자동으로 조치를 한걸볼수있습니다.

 

라우팅 정책 지리적 위치

 

이런씩으로 두개더 만들어줍니다.

 

지금 윈도우에 접속하면 정상적으로 나옵니다.

 

 

이제 VPN을 활용하여 인도로 바꿔줍니다. 그럼 가까운 리전으로 접속된걸알수있습니다.

 

라우팅 정책 지리적 근접성

 

us-west-1의 리소스와 us-east-1 리소스를 예로 들겠습니다. 각 리전의 편향값은 0으로 설정됩니다. 이는 미국 전역에 사용자가 이 리소스에 액세스를 시도하며 미국을 둘로 나눈다는 뜻입니다. 왼쪽 사용자는 us-west-1으로 이동 오른쪽 사용자는 us-east-1으로 이동합니다. 이건 평향값이 없기때문에 아주 간단합니다.

 

 

us-west-1는 편향값 0이고 us-east-150으로 평향값을 가집니다. 그리고 편향으로 해당 리소스에 더 많은 사용자의 트래픽이 발생됩니다. 그 이유는 편향으로 2가지 리소스 사이의 분할 선이 조금씩 왼쪽으로 이동하는 것이며 이는 us-east-1의 편향이 더 높기 때문입니다. 이는 왼쪽의 사용자는 us-west-1으로 이동하고 오른쪽의 사용자는 us-east-1으로 이동합니다. 왜 그럴까요 예를 들어 전 세계로 리소스를 설정하고 특정 리전에 더 많은 트래픽을 더 보내야 한다고 하면 지리 근접 라우팅 정책을 사용해 특정 리전의 편향을 증가시키면 더 많은 사용자가 생기게 되고 특정 리전에 더 많은 트래픽이 발생하게 됩니다.

 

라우팅 정책 IP based

 

- IP 기반 라우팅입니다.

- Route 53에서 CIDR 목록을 정의한 클라이언트의 IP 범위 입니다.

- CIDR에 따라 트래픽을 어느 로케이션을 보내야 하는지 정합니다.

- IP를 미리 알기때문에 성능 최적화가 가능합니다. 

- IP가 어디로 오는지 알기때문에 네트워크 비용을 절감이 가능합니다.

이 그림으로 예를 들면 Route 53에서 두 로케이션을 서로 다른 두 CIDR 블록으로 정의합니다. 하나는 203으로 시작하고 다른 하나는 200으로 시작합니다. 그러면 IP 범위도 정의됩니다. 이제 로케이션을 레코드에 연결합니다. example.com인데요 로케이션1 에서는 첫 번째 CIDR 블록을 값 1,2,3,4로 보내고, 두 번쨰 로케이션2 에서는 두 번째 CIDR 블록을 5,6,7,8로 보냅니다. 이 값들은 두 개의 EC2 인스턴스의 공용 IP를 나타냅니다.  사용자 A가 로케이션 1 CIDR 블록에 속하는 특정 IP로 들어오면 첫 번쨰 EC2 인스턴스인 IP 1,2,3,4로 보내집니다. 리디렉션되어 IP 5,6,7,8의 EC2 인스턴스에 대한 DNS 쿼리 응답을 받게 됩니다.

 

라우팅 정책 다중 

 

- 트래픽을 다중 리소스로 라우팅할 때 사용합니다. 그래서 Route 53은 다중 값과 리소스를 반환합니다.

- 상태 확인과 연결하면 다중 값 정책에서 반환되는 유일한 리소스는 정상 상태 확인과 관련이 있습니다.

- 각각의 다중 값 쿼리에 최대 8개의 정상 레코드가 반환됩니다. 

- ELB와 유사해 보이지만 ELB를 대체할 수는 없습니다.

이 그림으로 예를 들면 example.com에서 다중 A 레코드를 설정하고 상태 확인과 연결합니다. 클라이언트에서 다중 값 쿼리를 실행하면 최대 8개의 레코드를 수신하게 되고 클라이언트는 하나를 선택합니다. 하지만 최소한 상태 확인과 결합하면 반환되는 8개 레코드 중 1개 혹은 최대 8개의 레코드가 정상일 것을 알고 있습니다. 정상일 것을 알고 있습니다. 그래서 클라이언트는 안전한 쿼리를 가질 수 있습니다.  다중 값이 있는 단순한 라우팅의 경우에는 단순 라우팅 정책은 상태 확인을 허용하지 않기 때문에 단순 라우팅 정책의 쿼리가 반환하는 리소스 중 하나는 비정상일 가능성이 있습니다. 바로 다중 값이 조금 더 강력한 레코드 유형인 이유입니다.

 

 

이런게 2두개 더만듭니다.

 

 

aws shell에 연결 후 dig URL 3개의 주소를 볼수있습니다.

 

 

 

eu-central-1를 비정상으로 설정하겠습니다.

 

 

다시 확인해보니 원래는 3개였는데 2개가 됐습니다.