AWS

aws-route53-review

요 며칠간 CF관련 이슈로 고민이 많았다.

ipv6 부터 SK LTE까지...

이문제가 발생한 원인은 먼저

SK LTE DNS 에서의 ipv6라우팅이 가장 큰 원인일테고..
같은 cloudfront에서도 발생하는 빈도차가 있었으므로 그 원인을 파악하고 해결하는 법을 서술하려고한다.

먼저 A alias는 ipv4로 라우팅한다. - A record 는 ipv4를 라우팅 하므로..

>linuxer.name
이름: linuxer.name
Addresses: 52.85.231.10
52.85.231.111
52.85.231.68
52.85.231.42

그렇다면 alias 를쓰는 사용자는 cf관련 문제를 겪지 않았을 것이다.

Route 53 별칭 레코드는 AWS 리소스와 같은 별칭 대상의 DNS 이름에 내부적으로 매핑됩니다. Route 53은 조정 작업과 소프트웨어 업데이트를 위해 별칭 대상의 DNS 이름과 연결된 IP 주소를 모니터링합니다. Route 53 이름 서버의 신뢰할 수 있는 응답에는 A 레코드(IPv4 주소에 대한 레코드) 또는 AAAA 레코드(IPv6 주소에 대한 레코드)와 별칭 대상의 IP 주소가 포함되어 있습니다.
https://aws.amazon.com/ko/premiumsupport/knowledge-center/route-53-create-alias-records/

내용을 확인해 보면 신뢰할수 있는 응답에 ipv4-ipv6를 응답하게 되어있다고 나와있다.

따라서..alias는 문제가 없었다.

그렇다면 문제가 있었을 cf는 무엇일까?

cname 을 사용하던 도메인들이다.

cname을 설정하면 이렇다.

>test2.linuxer.name
서버: UnKnown
Address: 210.219.173.151
권한 없는 응답:
이름: d19f2uxthc0s83.cloudfront.net
Addresses: 2600:9000:2150:1a00:10:3683:b8c0:93a1
2600:9000:2150:8000:10:3683:b8c0:93a1
2600:9000:2150:c000:10:3683:b8c0:93a1
2600:9000:2150:6400:10:3683:b8c0:93a1
2600:9000:2150:8c00:10:3683:b8c0:93a1
2600:9000:2150:1000:10:3683:b8c0:93a1
2600:9000:2150:7800:10:3683:b8c0:93a1
2600:9000:2150:e200:10:3683:b8c0:93a1
52.85.231.10
52.85.231.111
52.85.231.68
52.85.231.42
Aliases: test2.linuxer.name

ipv6 와 ipv4를 모두응답한다. 이 경우 ipv6가 우선라우팅이 된다.

그래서 결국 route53 공식문서를 확인해보니 A/AAAA를 같이쓰라고 되어있다.

cloudfront 는 cname 을 제공하고 A record를 사용할경우 cloudfront 의 IP변경에 대응할수 없다. 그렇기 때문에 일반적으로 A alias 를 사용하라 한것이다.

명시적인 레코드의 분리를 뜻하는 것이다. 일반적으로 잘 발생하는 문제는 아닌것으로 보이나, cname 을 사용하게되면 이렇다.

일반적으로 도메인에 요청을 할때 레코드를 지정해서 쿼리하진 않는다.
그래서 cname 으로 요청하게되면 cname 에 연결된 모든 record가 응답하게 되고 그 결과 값에 따라서 ipv6 가 존재하면 ipv6 로 라우팅 된다.

nslookup 결과
>test2.linuxer.name
서버: dns.google
Address: 8.8.8.8권한 없는 응답:
이름: d19f2uxthc0s83.cloudfront.net
Addresses: 2600:9000:2139:e200:10:3683:b8c0:93a1
2600:9000:2139:fa00:10:3683:b8c0:93a1
2600:9000:2139:4c00:10:3683:b8c0:93a1
2600:9000:2139:7400:10:3683:b8c0:93a1
2600:9000:2139:5400:10:3683:b8c0:93a1
2600:9000:2139:aa00:10:3683:b8c0:93a1
2600:9000:2139:2600:10:3683:b8c0:93a1
2600:9000:2139:6c00:10:3683:b8c0:93a1
99.86.144.35
99.86.144.128
99.86.144.34
99.86.144.126
Aliases: test2.linuxer.name

따라서 route53을 사용할때 A/AAAA를 분리해서 사용하라는 말이다.

그런데 말입니다.

그런데 말입니다에 대한 이미지 검색결과

A레코드는 쓸수 없잖아? cf는 IP가 바뀌니까..

그래서 결론이 난다. 확실하게 정해준다.

A Alias AAAA alias 를 사용하는걸 권장한다.
같은계정내 자원이라면!

아니라면?

cname 을 사용할수 밖에 없다면 CloudFront 의 IPv6 를 끄자.

CloudFront Distributions > General > Enable IPv6

체크박스만 누르고 Yes, Edit 만 누르면 된다.

참쉽죠.

참곤란한 이슈였다. 참고-URL

https://www.facebook.com/groups/awskrug/permalink/2278291878939490/

https://tools.ietf.org/html/rfc3484?fbclid=IwAR0Ca2JDM55CpyhZSjtiR7EYhySfzADdLMRX2q-rWZoAM-z8BHbqismCQfk#section-2.1

읽어주셔서 감사하다!

2020년 1월 28일 by AWS 기타 0

aws route53 의 응답이상-1.

얼마전부터 route53 에서 cf 관련 느린이슈가 발생했다.

skt lte 망에서 발생하는 이슈인지 아니면 다른 이슈가 있는지 애매한 느낌이 있었다.

나도 ipv6 를 꺼서 지연문제가 해결될거라 생각했는데 조금 이상한 부분이 있어서 글을쓰게되었다.

먼저 route53의 응답이 이상하다.

linuxer.name 의 ns 레코드는

>linuxer.name
서버: [205.251.196.29]
Address: 205.251.196.29
linuxer.name nameserver = ns-1053.awsdns-03.org
linuxer.name nameserver = ns-1958.awsdns-52.co.uk
linuxer.name nameserver = ns-406.awsdns-50.com
linuxer.name nameserver = ns-544.awsdns-04.net

총 4개의 ns 를 가지고있다. 이 ns를 지정해보기로 한다.

>server ns-544.awsdns-04.net
기본 서버: ns-544.awsdns-04.net
Addresses: 2600:9000:5302:2000::1
205.251.194.32

서버를 ns-544.awsdns-04.net로 지정하면 ipv6 와 ipv4를 응답한다.

그 후에 다시 내도메인을 쿼리한다.

>linuxer.name
서버: ns-544.awsdns-04.net
Addresses: 2600:9000:5302:2000::1
205.251.194.32
*** ns-544.awsdns-04.net이(가) linuxer.name을(를) 찾을 수 없습니다. No response from server

그냥 도메인에 대한 응답인데..응답하지 않는다.

그럼 ns-544.awsdns-04.net 도메인의 서버IP인 205.251.194.32 로 쿼리를 날려본다.

>server 205.251.194.32
기본 서버: [205.251.194.32]
Address: 205.251.194.32

>linuxer.name
서버: [205.251.194.32]
Address: 205.251.194.32
linuxer.name internet address = 52.85.231.111
linuxer.name internet address = 52.85.231.10
linuxer.name internet address = 52.85.231.68
linuxer.name internet address = 52.85.231.42
linuxer.name nameserver = ns-1053.awsdns-03.org
linuxer.name nameserver = ns-1958.awsdns-52.co.uk
linuxer.name nameserver = ns-406.awsdns-50.com
linuxer.name nameserver = ns-544.awsdns-04.net
linuxer.name
primary name server = ns-1053.awsdns-03.org
responsible mail addr = awsdns-hostmaster.amazon.com
serial = 1
refresh = 7200 (2 hours)
retry = 900 (15 mins)
expire = 1209600 (14 days)
default TTL = 86400 (1 day)
linuxer.name name = 13.209.129.220
linuxer.name MX preference = 10, mail exchanger = mail.linuxer.name
linuxer.name ??? unknown type 257 ???

정리하자면 ipv4인 IP로 연결하면 응답하고 ipv6/ipv4로 응답하는 DNS로는 도메인에 대한 응답을 하지않는다...

이게 cf문제는 아니고 route53에서 ipv6 에 대한 응답을 정상적으로 못해서 발생하는 증상이 아닐까...하고 생각해본다..

다른의견이 있으시면 고견을 들려주시기 바란다.

https://www.facebook.com/groups/awskrug/permalink/2278291878939490/

https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/routing-to-cloudfront-distribution.html?fbclid=IwAR3xOqsWf-xhh5cB0AOQfLW7zTKr-Cvd6mJEHfgIX607K1Rv6_HavoLPsnE

추가 댓글도 있으니 참고하시기 바란다.

2020/01/28 추가

https://tools.ietf.org/html/rfc3484#section-2.1

rfs3484에 의해 route53은 정상적인 응답을 하는것으로 보인다.

발생한 문제는 SK LTE 망내의 DNS에서 ipv6를 사용하므로서 정상적으로 라우팅하지 못한 문제로 보인다.

추가적인 내용은 다음포스팅에서 진행하겠다.

2020년 1월 24일 by AWS 0

aws-ami-Permissions-ami공유

ami 를 공유하는 방법을 포스팅해 볼까한다.

계정간 인스턴스 이동을 진행하려면 꼭 알아야한다.

ami 메뉴에서 권한수정을 클릭한다.

공유할 계정의 aws 계정 번호를 입력하여 권한을 추가한다.

공유된 계정에서 인스턴스 생성 페이지에서 나의 AMI에서 소유권에 나와 공유됨만 체크해본다.

공유된 AMI를 확인한다.

다른 방법으로 ami 를 확인할수 있는데

공유 받은 계정에서 프라이빗 이미지를 검색해서 확인할수 있다.

리전이 다르다면 스냅샷을 리전복사 한다음에 공유를 하자.

끝!

2020년 1월 20일 by AWS 0

aws-cloudfront-s3-lambda cross-account access

cloudfront - s3 를 이용하게되면 결국 OAI를 이용한 Bucket policy를 사용하게 된다.

단일 계정에서 사용할 경우엔 cloudfront 에서 자동으로 생성까지 해주므로 어려울것이 전혀없다.

그런데 이제 이게 파트너사를 통해서 cloudfront 전용계정을 사용하게 된다던거 multi account 로 프로젝트를 진행할경우 자동으로 생성이 되지 않는다. 이 경우에 어떤방식으로 s3 Bucket policy 를 설정해야 하는지 포스팅하려 한다.

먼저 Bucket policy 를보자

{
"Version": "2012-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": " Grant a CloudFront Origin Identity access to support private content",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E39X8K28W3EQ"
]
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::*"
}
]
}

일반적으로 계정에서 버킷정책을 설정하면 위와같은 형태로 적용을 한다.
가끔 정상적으로 적용이되지않는경우엔

{
"Version": "2012-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": " Grant a CloudFront Origin Identity access to support private content",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity 49821f785cce6ee4f575de3f01c503dade8a7b15003aa337faa471d830d07493cbb195eec14f0d86d4a914622e1e42"
]
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::*"
}
]
}

이런식으로 caninucal user id 를 이용하여 정책을 설정하면 자동으로 OAI ID로 정책이 적용되게 된다.

여기까진 아주 쉬웠다. 그런데

람다 엣지를 이용한 리사이즈를 하는 프로세스에서 단일계정이 아니라 교차계정을 구성하게 되면 lambda가 A 계정에서 B 계정으로 접근하게 해줘야한다. 이부분에서 조금 헤멧는데 결국엔 굉장히 간단한 부분이었다.

s3 Bucket policy 에서 계정의 role을 허용해주면 끝..

{
"Version": "2012-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": " Grant a CloudFront Origin Identity access to support private content",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E39X8K58WRN3EQ",
"arn:aws:iam::328341115633:role/lambda-resize-cloudfront"
]
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::linuxer-resize/*"
}
]
}

arn:aws:iam::328341115633:role/lambda-resize-cloudfront

json 문법에 또 약해서 좀 해멧는데 금새 해결할수 있었다..

2020년 1월 18일 by AWS 0

aws-EFS-backup-restore

EFS를 사용하고 백업/복구 이야기를 하려고한다.

EFS는 NFS기반의 편리한 서비스다. aws backup로 스냅샷 방식의 백업이 가능하다.

현재 측정크기가 6.0kib인데

# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 475M 0 475M 0% /dev
tmpfs 492M 0 492M 0% /dev/shm
tmpfs 492M 404K 492M 1% /run
tmpfs 492M 0 492M 0% /sys/fs/cgroup
/dev/xvda1 8.0G 4.6G 3.5G 57% /
tmpfs 99M 0 99M 0% /run/user/0
fs-7eb4fb1f.s.ap-northeast-2.amazonaws.com:/ 8.0E 0 8.0E 0% /mnt/efs

root@ip-10-0-0-12 wordpress]# cd /mnt/efs
# du --max-depth=1 -h
258M ./ftp
258M .

실제론 그렇지 않다. 일정 GB이상의 데이터가 쌓여야 명령어가아닌 gui에서 확인할수 있다.

오늘은 이 파일시스템을 백업할거다.

aws backup를 사용할때 유의할점은 백업볼트를 생성할때 각각 목적에 맞게 분할해서 사용하라는 거다. 급하게 작업하다가 관리가 너무 불편해져서 결국 나눴다.

일반적으론 볼트생성->계획생성->규칙생성->리소스할당 순서다.

리소스할당은 tag 기반으로도 가능하고 리소스ID 유형으로도 가능하다.

여기까지 백업계획을 이용한 스케줄 백업이었고 단발성 백업은 대시보드에서 온디멘드 백업으로 진행하면 된다.

진행중인 jab는 작업부분에서 확인할수 있다.

용량이 작어서 금방 백업이 완료됬다.

백업은 증분방식이고 복구지점에 카운트가 올라간다.

복원을 진행해 보면

전체/부분/소스/새 이렇게 선택지가 나눠지는데 얼마전 나에게 혼란을 줬던 부분은 전체-소스 파일 시스템에 복원이다.

복원을 누르면 작업탭에 복원에서 확인할수 있다.

Pending-> Running -> Completed 단계를 거친다.

Pending 이 한국어 에선 보류중으로 나오는데 처음에 좀 당황했다.
보류...??????????????????????????????????????????????
하고 Pending 좀 오래걸린다. 거의 10분 이상걸린적도있다.

root@ip-10-0-0-12 ~]# cd /mnt/efs/
root@ip-10-0-0-12 efs]# ll
total 16
drwxr-xr-x 4 root root 6144 Jan 18 11:24 aws-backup-restore_2020-01-18T03-33-30-039Z
drwxr-xr-x 4 root root 6144 Jan 18 11:24 aws-backup-restore_2020-01-18T03-47-22-912Z
drwxr-xr-x 4 root root 6144 Jan 18 11:24 aws-backup-restore_2020-01-18T03-49-03-261Z
drwxr-xr-x 3 jth-ftp jth-ftp 6144 Aug 21 21:20 jth-ftp

aws-backup-restore_2020-01-18T03-33-30-039Z 같은 형식으로 복원 시작시간으로 디렉토리가 생성되고 복원이 된다. 당연히 복원되는 양에 따라서 속도도 다르다.

3번 복원을해서 3개의 디렉토리가 추가 생성된거다. 사용용량이 df 로는 안보이지만 aws 콘솔에선 보인다.

처음 복구할 땐 덮어쓰기로 생각해서 한참을 기다려도 복구가 안되는거같아 EFS의 /를 마운트 해보고서야 알았다. 아 디렉토리 생성 후 복구되는구나.

그래서 이제 추가로 파일 복구를 해보기로 했다.

root@ip-10-0-0-12 wp-admin]# pwd
/mnt/efs/jth-ftp/wordpress/wp-admin
root@ip-10-0-0-12 wp-admin]# ll
total 980

/mnt/efs/jth-ftp/wordpress/wp-admin 디렉토리를 복구해보겠다.

부분 복원으로 선택하고~ 작업은 부분복원이 좀더 걸리는거 같았다.

/mnt/efs/aws-backup-restore_2020-01-18T04-09-39-782Z/jth-ftp/wordpress/wp-admin

경로로 이동해서 복구 확인해봤다.

root@ip-10-0-0-12 wp-admin]# ll
total 980

정상적으로 잘복구 된것을 확인할수 있었다.

efs 를 매우 애용하는 입장에서 파일복구가 가능해진것은 매우 반길 일이다.

아 추가로 EFS 에서 Bursting 모드를 사용할경우 BurstCreditBalance 를 가지게 되고 사용시 소모가 된다. 그런데 백업이나 복구시에는 크레딧을 따로 소모하지 않았다.

읽어주셔서 감사하다!

2020년 1월 18일 by AWS 1