AWS-auto-assign IP settings

기본 VPC의 경우에는 EC2를 생성할때 자동으로 인스턴스에 Public IP가 자동으로 붙는다.

이퍼블릭 IP는 생성되면 뗄수도없고 인스턴스를 종료후 재생성 해야지만 된다.
Private subnet 에서도 Public IP가 생성되는것이므로 보안상의 취약점을 초래한다.

따라서 인스턴스를 생성할때는

이렇게 퍼블릭 IP가 비활성화로 생성해야하는데 매번 일일이 신경써서 하기엔 불편하다.

VPC-서브넷 에서 자동 할당 IP 설정 수정 옵션을 해제해주면 된다.

해제하고 저장후 인스턴스를 생성해보면 아래와 같이 확인된다.

스샷에서 보이듯 서브넷의 기본설정을 수정하여 자동으로 비활성화 할수있다.

이미붙은 Public IP는 뗄수 없다.

명심하자. 모든 EC2는 Public IP 없이 생성해야한다.

읽어주셔서 감사하다!

좋은하루 되시라!

AWS-GCP-Azure-network-none-rfc1918

VPC를 생성하는 경우, 다음과 같이 /16RFC 1918:규격에 따라 프라이빗(비공개적으로 라우팅 가능) IPv4 주소 범위에 속하는 CIDR 블록( 또는 이하)을 지정하는 것이 좋습니다.

-_-;공인IP를 쓸수있는건 아니지만 걍 아무대역 가져다 써도 VPC는 생성 가능하다.

갑자기 궁금해져서 퍼블릭클라우드는 비RFC1918을 지원하는지 모두 테스트 해보았고 모두 지원한다~

DOCS에서 명확하게 적혀있는것은 AWS 뿐이었다.

Azure

VNet 내에서 사용할 수 있는 주소 범위는 무엇입니까?

RFC 1918에 정의되어 있는 모든 IP 주소 범위를 사용할 수 있습니다. 예를 들어 10.0.0.0/16을 사용할 수 있습니다. 다음 주소 범위는 추가할 수 없습니다.

  • 224.0.0.0/4(멀티캐스트)
  • 255.255.255.255/32(브로드캐스트)
  • 127.0.0.0/8(루프백)
  • 169.254.0.0/16(링크-로컬)
  • 168.63.129.16/32(내부 DNS)

GCP

서브넷 및 IP 범위

서브넷을 만들 때 기본 IP 주소 범위를 정의해야 합니다. 선택사항으로 보조 IP 주소 범위를 정의할 수 있습니다.

  • 기본 IP 주소 범위: 서브넷의 기본 IP 주소 범위에 대한 비공개 RFC 1918 CIDR 블록을 선택할 수 있습니다. 이러한 IP 주소는 VM 기본 내부 IP 주소, VM 별칭 IP 주소, 내부 부하 분산기의 IP 주소에 사용할 수 있습니다.

뭐야.. 애매하잖아 다되는데

AWS-Security-Group-Tip

지금까지는 대량의 IP를 컨트롤 할땐..CLI를 이용하거나..

한줄씩 넣었다.

그도 그럴게..

(구)인터페이스 를 보면 한번에 하나의 IP만 넣을수 있게 되어있어 보이는 것이다.
그래서 지금까지의 나는 여러개의 IP에 동일한 프로토콜일 경우 여러개의 규칙을 추가했었다.

그런데 오늘 대량의 IP를 추가하려고 보니 CLI를 쓰기 너무 귀찮았다.

그래서..설마 구분자가 먹는거아냐? 싶어서 콤마를 써봤다.

ex) 192.168.1.1/32,192.168.2.1/32,192.168.3.1/32,192.168.4.1/32,192.168.5.1/32

다섯개의 32bit IP를 ,로 구분하고 이건 소스 IP에 넣는다

이런식으로..그리고 저장

한꺼번에 추가가 된게 보인다. 그럼 새로운 인터페이스에선?

이렇게 추가된다...하...왜이걸 몰랐지..?

나만 몰랐던걸로 하자.

하..씁슬

읽어주셔서 감사하다!

AWS Certified Security-Specialty-review

5월6일 SCS 시험을 봤다. 결과는 합격이다.

5월4일 연습시험을 봤는데...

 AWS Certified Security Specialty - Practice 시험에 응시해 주셔서 감사합니다. 다음 정보를 살펴보고 준비가 더 필요한 주제를 확인하십시오.
총점: 65%
주제별 채점:
1.0  Incident Response: 66%
2.0  Logging and Monitoring: 75%
3.0  Infrastructure Security: 83%
4.0  Identity and Access Management: 50%
5.0  Data Protection: 33%

65% 나와서 정말 많이 당황했다. 그래서 공부를 더 많이했다.

시험을 보게된 계기는 master.seo 님의 URL 공유로 부터 시작되었다.
udemy 강의가 무료로 풀려서..그걸 한번 봤는데 반타작이 가능했다.

각이보이길래 바로 준비했다.

SCS는 IAM / Policy / KMS 가 비중이 높다.

나머지는 SAP를 준비하면서 기본개념을 익힌것으로 커버가 가능한 수준이다.
실무에서 또한 ISMS관련한 작업을하면서 익힌 내용도 은근 포함되었다.

공부하면서 개념정리를 위해 작성한 노트는 링크를 확인하시길.

이제 다음 자격증인 ANS를 준비해야겠다.

각을 보여주신 Master.seo님께 감사를 드린다!

아래는 Master.seo님의 브런치다!

https://brunch.co.kr/@topasvga

AWS-CloudWatch-Synthetics-Canary-review

드디어!!드디어!!드디어!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

AWS에도 웹모니터링 기능이 생겼다.

진짜 너무 기다려왔던 기능이다.

사용법도 간단하고 지표도 바로나오고..이거 완전 물건이다.

바로 셋팅해봤다.

블루 프린트를 사용해서 테스트를 했다.

4가지의 블루프린트를 제공하고 스크립트를 수정할수도 있으나 귀찮다.

일정은 뭐....알아서 나는 5분으로 만들고 나중에 1분으로 수정했다. 일단 나머지 파라메터를 다 기본으로 설정하고 진행했다.

생성하면 진짜 간단하게 보여준다.

핵심은 이거다. 그냥 사이트 모니터링을 해주고

지연된 URL을 체크해준다.

나같은경우엔 사이트 모니터링을

1분마다 하고 5분 평균 임계값을 1로 설정하여 상당히 예민한 모니터링 설정을 하였다. 사이트 URL 체크가 1번만 실패해도 SNS로 경보가 동작한다.

t2.micro 의 경우에는 인스턴스의 CPU가 좀 오르는게 보였으나.. 뭐 이정도는 감당할 만하다. 모니터링으로 인해 부하가 발생하는것이 불편하다면 특정 모니터링 URL만 만들어서 부하를 줄여서 모니터링 하는것이 방법일것이다.

지금 까지는 target group에 의존한 모니터링을 사용하였는데 이젠 서비스에 대한 모니터링이 가능한 순간이 와서 너무 즐겁다.

일단 블로그에 충분한 테스트 이후에 api 와 프로덕션 환경에서 사용해 봐야겠다.

포스팅을 작성하고 나중에 비용계산을 진행해 보았다.

단순계산으로

1분마다 모니터링 하면 60*24*31=44604*0.0012 USD=53.568=USD

5분마다 면....11USD 정도 이다-_-;;;

음....모니터링 치고 비싼데...????????????????ㅠㅠ

적용하기 전에 비용꼭 계산해보고 사용하자..

읽어줏셔서 감사하다!

aws-waf.ver2-review-2-test

Hostcenter 의 Acunetix 취약점 점검툴을 사용하였습니다.

https://www.hostcenter.co.kr/Security/security01.aspx

aws waf.ver2 관리형룰의 성능을 테스트 하고 싶었다.

마침 회사에 web 취약점 점검툴이 있었다. 그래서 테스트를 진행했다.

먼저 COUNT 모드로 점검을 진행했다.

총 점검시간 4시간 15000번의 리퀘스트가 있었다. 첫번째 테스트는 1월10일 두번째 테스트는 1월 30일 이었다.

빨리 진행하고 싶었는데 좀 바빳다.

1월10일 모니터링 모드 스캔 결과
1월 30일 차단모드 스캔결과

간략한 결과로만 봐도 high단계의 취약점이 사라리고 medium 단계의 취약점이 하나 사라졌다.

그럼 어떻게 막혔는지 리뷰를 해야하는데...

일단 테스트시간에 막힌 리퀘스트는 3000개 정도. 15000만건중 20%정도가 막혔다.

Description
Contains rules that are generally applicable to web applications. This provides protection against exploitation of a wide range of vulnerabilities, including those described in OWASP publications and common Common Vulnerabilities and Exposures (CVE).
Capacity: 700

룰중 가장 많은 Capacity 를 사용하는 AWS-AWSManagedRulesCommonRuleSet 룰에서 역시나 많은 지분을 차지했다.

분석결과를 설명하기 보단 waf 를 사용해서 확인한 취약점리포트의 일부를 공개하는쪽으로 블로깅을 마친다.

waf 사용전

waf 사용후

블로깅이 좀 애매한데 다음엔 로깅을 남겨서 다음 포스팅을 준비해보겠다.

cloudwatch log 매트릭 경보 생성 - log monitoring

오늘의 주제는 인스턴스에서 발생하는 로그를 cloudwatch 로 전송하여 사용하는 법을 포스팅 할거다.

먼저 역할에 정책부터 생성해 보자. 사용하는 정책은 아래와 같다.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogStreams"
],
"Resource": [
"arn:aws:logs:*:*:*"
]
}
]
}

역할을 인스턴스에 부여하고 인스턴스 내부에서 패키지를 설치해야 한다.

나는 이미 이전에 테스트로 설치해 뒀다.

설치로그이다.

Nov 18 17:17:19 Installed: aws-cli-plugin-cloudwatch-logs-1.4.4-1.amzn2.0.1.noarch
Nov 18 17:17:20 Installed: awslogs-1.1.4-3.amzn2.noarch

실제 설치방법은 yum install 이나 wget 으로 받아 실행하는 방법이 있다.

# yum install awslogs -y

or

# curl https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py -O
# python ./awslogs-agent-setup.py --region ap-northeast-2

리전지정 옵션을 넣어주는게 좋다 그렇지 않으면 따로 지정해야 한다.

# vi /etc/awslogs/awscli.conf
[plugins]
cwlogs = cwlogs
[default]
region = ap-northeast-2

그리고 cloudwatch 로 전송할 로그를 지정한다.

# vi /etc/awslogs/awslogs.conf
[/var/log/messages]
datetime_format = %b %d %H:%M:%S
file = /var/log/messages
buffer_duration = 5000
log_stream_name = test
initial_position = end_of_file
log_group_name = linuxer-blog-WG

테스트를 위해 /var/log/messages 를 cloudwatch 로 전송하는 로그이다.

log_stream_name = test
initial_position = end_of_file
log_group_name = linuxer-blog-WG

세개의 옵션이 중요하다. end_of_file 은 뒤부터 추가되는 로그를 watch 로 전송한다.

amazon linux 2 는 systemctl 명령어로 서비스를 시작한다

# systemctl restart awslogsd

설정대로 로그가 올라 오는게 보인다.

중요한 부분은 이벤트 만료시점을 지정해서 로그로 전송된 용량이 과하게 쌓이지 않도록 해야한다.

로그 그룹을 체크하면 지표 필터 생성 버튼이 활성화 되고 지표를 생성한다.

지표는 대충 만들어 볼까한다.

HealthCheck 라는 이름으로 패턴을 설정했다. 보면 샘플로그에서 일치하는 패턴이 보인다. 그리고 지표를 할당한다.

지표생성은 커스텀 매트릭으로 비용이 발생할수 있으니 조심하도록 하자.

생성된 지표를 확인하면 위와같다. 그럼 지표를 확인해보자.

커스텀메트릭이 정상적으로 만들어진걸 확인할수 있다.

그래프도 잘생성 됬는지 보면 잘 올라오는게 보인다. 그럼 실제 로그가 발생해서 그래프가 생성됬는지 확인해보자.

로그가 올라와서 매트릭이 생성된것을 확인할수 있다. 그럼이제 경보를 생성해 보자.

뭔가 훅지나간거 같겠지만 빠진부분은 sns 설정 뿐이다. SNS는 주제를 만들고 구독을 생성하고 구독으로 watch 에서 sns를 추가하면 된다.

경보생성하는 방법은 따로 자세하게 설명하겠다. 블로깅이 시리즈 물이 될 기미가 보인다.

그래프처럼 임계치를 지나서 경보상태로 변경됬다가 정상으로 업데이트가 되는 과정이 보인다 정상적으로 지표로 경보가 작동하는것 까지 확인 되었다.

오늘의 목표인 로그전송으로 지표생성 후 경보 생성까지 완료되었다.

이케이스는 tomcat log로 지표를 생성하거나 어플리케이션에서 에러가 발생한 로그 경보를 생성시키는 등으로 사용할 수 있다.

자세하게 만들고 싶었는데 흐름만 구성한거 같아 좀 찜찜한 부분은 차차 보강하겠다.

읽어주셔 감사하다!

서울-도쿄 리전간 레이턴시 줄이기-실패경험담

페이스북 AKUG에서 다음과 같은 포스팅을 봤다.

https://aws.amazon.com/ko/about-aws/whats-new/2019/10/aws-global-accelerator-supports-ec2-instance-endpoints/?fbclid=IwAR2spSZzdtmHMDVqYwEpZS8W5pEs86t7SMNArZ2fyT81M55QDoDA1dqKuy4

처음엔 아무생각이 없었으나 급 아이디어가 떠올랐다.

EC2 엔드포인트를 지원하면 리전간의 레이턴시를 줄일수 있지 않을까? 그러니까..궁금증은 오픈카톡에서 시작된거였다.

한국과 도쿄리전 간의 레이턴시를 20ms 로 줄일수 있는지가 관건이었다.

AWS Global Accelerator는 TCP/UDP를 지원한다. 그렇다면 OPENVPN을 TCP로 셋팅해서 인스턴스의 앞단에 AWS Global Accelerator 둔다면 과연 빨라질까?

그런 궁금증이었다.

엣지로케이션을 이용하여 라우팅 최적화라고 생각하면 가장 간단하다.

테스트 방식은 총4가지였다

openvpn-도쿄리전(인스턴스) -프라이빗 IP 22 port tcping

openvpn-가속기-도쿄리전(인스턴스) -프라이빗 IP 22 port tcping

openvpn-한국리전(인스턴스)-vpc 피어링-도쿄리전- 프라이빗 IP 22 port tcping

openvpn-가속기- 한국리전(인스턴스)-vpc 피어링-도쿄리전- 프라이빗 IP 22 port tcping

AWS Global Accelerator 셋팅은 아주 간단하다.

Accelerator 를 생성하고 Listeners ID 를 생성할떄 region 을 지정하고 Endpoint groups 을 인스턴스 ID로 설정하면 status 를 업데이트 한다. ALL healthy 로 보이면 정상적으로 연결된것이다.

생성된 Accelerator 은 총3개의 endpoint 를 가진다. IP 두개와 DNS 하나이다.

그럼 테스트로 넘어간다.

가속기를 쓰지않고 도쿄리전의 인스턴스에 openvpn 으로 연결하여 프라이빗 IP로 22번 포트로 tcping 을 테스트 하였다. 총 100회의 tcping 의 time 을 확인할 계획이다.

172.31.26.253에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 34ms, 최대 = 35ms, 평균 = 34ms

C:>tcping.exe -n 100 172.31.26.253 22

Ping statistics for 172.31.26.253:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 43.180ms, Maximum = 81.995ms, Average = 64.100ms

가속기를 사용하지 않은 값으로 icmp 34ms / tcping 64ms 가 나온다.

172.31.26.253에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 34ms, 최대 = 35ms, 평균 = 34ms

Ping statistics for 172.31.26.253:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 43.065ms, Maximum = 78.722ms, Average = 61.323ms

평균 icmp 34ms / tcping 61ms 정도 확인할수 있었다.

tcping은 속도가 늘어지는 감이 있어서 ping 까지 체크해 보았다.

ping 로는 유효한 내용을 확인할수 없었다. openvpn 으로 접속하여 1194포트로 ping 를 확인하므로 실제 전송은 tcp로 이루어진다.

구성에 대해서 간략하게 설명하고 다음테스트를 진행하려고한다.

피어링은 신청하고 수락하는 단계를 거쳐서 허용된다.

피어링으로 끝이 아니라 두개의 VPC에서 라우팅을 설정해줘야 한다.

현재 서울 172.29.0.0/24 -> pcx 도쿄 172.31.0.0/20 -> pcx 로 라우팅 테이블을 설정 하였다. 테스트는 인스턴스 내부에서 ping 으로 확인하면된다.

사실 이때쯤 테스트가 잘못된것을 알았다.

--- 172.29.0.110 ping statistics ---
22 packets transmitted, 22 received, 0% packet loss, time 21036ms
rtt min/avg/max/mdev = 33.540/33.606/33.679/0.244 ms

vpc 피어링으로 묶은 속도의 평균이 33.5ms 였다.

망내 속도는 두 리전간의 피어링이 제일 빠를거라 생각했기 때문이다.
그래도 포기하지 않고 유효한 데이터를 쌓기위해 테스트를 진행했다.

이즈음 site to site vpn 셋팅이 가물가물 기억이 안나서 좀 이것저것 봤다.

다음 테스트구성은 서울리전 인스턴스에 openvpn으로 연결하고 vpc peering 으로 도쿄 리전과 연결한다. 그리고 ping / tcping 22 번 테스트를 한다.

172.29.0.110에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 39ms, 최대 = 40ms, 평균 = 39ms

Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 45.206ms, Maximum = 79.891ms, Average = 60.589ms

Accelerator 를 사용하지 않은 결과로 icmp 39 / tcping 22 60ms 이다.
ICMP는 늘어지는데 TCP는 빨라지는 결과가 나왔다. 뭐지..

그래서 한번더 했다.

Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 46.106ms, Maximum = 85.099ms, Average = 64.571ms

늘어지네... 39/ 60 / 64

172.29.0.110에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 40ms, 최대 = 41ms, 평균 = 40ms

Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 46.406ms, Maximum = 78.911ms, Average = 65.489ms

Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 45.652ms, Maximum = 81.980ms, Average = 66.764ms

40 / 65 /66 시간이 지날수록 속도가 느려졌다. 왜지? Accelerator 가 가까운 거리에선 라우팅을 한번 더 들어가게 되는건 아닐까 하는 생각이 들었다.

실제론 엣지를 타게되지만 전송거리가 더 먼건 아닐까...
그런 생각이 들어서 결국 오레곤 리전에 셋팅을 했다. 이젠 근성이다.

10.0.0.227에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 136ms, 최대 = 193ms, 평균 = 141ms

Ping statistics for 10.0.0.227:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 145.219ms, Maximum = 283.356ms, Average = 168.073ms

141 / 168 역시 오레곤은 멀다. 그럼 Accelerator 를 사용해 본다.

10.0.0.227에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 126ms, 최대 = 127ms, 평균 = 126ms

Ping statistics for 10.0.0.227:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 132.458ms, Maximum = 224.706ms, Average = 154.244ms

126 / 154 드디어 Accelerator 를 사용했을때 유효한 결과가 보인다.

한국에서 거리가 먼~오레곤 정도 되어야..속도가 오르는게 확인이 된다.

물론 라우팅이 꼬일대로 꼬인 지역에선 Accelerator가 매우큰 도움이 될것이다.

하지만..여기서 끝내기엔 너무 아쉬웠다. 하.

또 한국리전에 최근에 적용된 기능이 생각났다.

https://aws.amazon.com/ko/about-aws/whats-new/2019/10/aws-client-vpn-now-available-seoul-canada-central-stockholm-northern-california-regions/?fbclid=IwAR3wIXq6EsYCxAV7FN05mDsmVc_mkQH1EzwVF-wUN8EpxTGB1f1zUiZ0_s8

이 테스트는 다음을 기약해야 할것같다..
ㅜㅜ실패의 충격이 크다.

하지만 얻게된 aws의 내부 망에 대한 추측이다.

서울 리전과 도쿄리전은 라우팅이 복잡해서 지연이 있는게 아니라 실제 회선이 지연이 있어서 발생하는 레이턴시다. 그래서 이 레이턴시를 줄이기 위해선 라우팅 최적화나 다른 시도가 필요한게 아니라 회선의 질적인 상향이 필요하다는게 내 결론이다.

오늘의 우승 구성은 " openvpn-가속기-도쿄리전(인스턴스) -프라이빗 IP 22 port tcping " 이다.

오늘은 도쿄에 테스트 했으니까 사요나라!

AWS 기본 교육자료

aws 를 설명하기 전에 먼저 클라우드란? 무엇인지 부터 알아야합니다.

일반적으로 가상화를 이용하여 노드를 관리하는 기술을 클라우드라고 지칭합니다.

클라우드는 퍼블릭 클라우드 / 프라이빗 클라우드로 나뉘는데 AWS는 퍼블릭 클라우드를 지양하는 플랫폼입니다.

AWS에 대해서 알기위해선 먼저 기본적인 용어에 익숙해 져야 합니다.

이 기본적인 용어를 설명할것입니다.

on-premise / off- premise 입니다.

일반적으로 하드웨어 기반의 가상화가 아닌 IDC에 종속적인 레거시 인프라를 온프레미스라고 칭합니다. 당연히 반대의 클라우드환경은 오프프레미스라고 하겠죠.

클라우드에서 가장 많이 쓰이는 단어는 On-Demand 입니다. 언제나 사용할수 있는 정도로 이해 하면 될것 같습니다.

간단하게 AWS체로 말하자면

"온프레미스에선 리소스를 온디맨드 하게 쓸수 없잖아요?"

등과 같이 말할 수 있습니다.

오늘은 간단하게 AWS 의 기본 인프라를 소개하려합니다.

기본 인프라 라고 함은 보통 vpc / ec2 / ebs / elb /eip / RDS 등을 뜻 합니다.

VPC
EC@
EBS
ELB
EIP

등으로 표현합니다. aws.ver2 아이콘으로 간단하게 서비스를 나열해 보았습니다.

AWS VPC 안에 인스턴스(서버)를 생성하고 ELB(L4)로 로드벨런싱을 합니다.

EBS는 블럭스토리지로 파일시스템을 생성하여 데이터를 저장하고 스토리지의 타입에 따라 성능과 비용을 조절가능합니다.

퍼블릭 서브넷에 속해있는 인스턴스는 EIP를 가집니다.

인스턴스에 접근을 제어할수 있는 방법은

security group

보안그룹 포트별 제어할수 있으며,



Network access control list

NACL로 IP list 에 대한 컨트롤이 가능합니다.

일반적으로 인스턴스가 퍼블릭에 노출되는경우는 없으며 퍼블릭에 노출되는 인프라는 ELB입니다. 프라이빗 서브넷에서

RDS

web-rds 는 통신을 합니다. 일반적으로 web/rds 는 2 tier 라고 칭합니다.

2tier 구성도는 위와 같습니다.

여기에 ELB-WEB-ELB-WAS-RDS 구성으로 변경된다면 3tier 구성이 됩니다.

기본적인 aws 인프라의 설명을 마치겠습니다.

route53 에서 한글 도메인 사용법. 부제 - 장난으로 리눅서.com 구매한 이야기

흔히들 한글도메인을 많이 사용한다.
처음 한글도메인을 사용하시는분들이 겪게 되는 이야기다.

route53에서 한글 도메인 구입은되는데 hosted zone 생성은 안된다고 한다.

간단하다 모든 네임서버는 한글을 인식할수 없다.

그런데 우리는 한글도메인을 사용한다. 사용할때 필요한것이 퓨니코드다.

퓨니코드(Punycode)는 유니코드 문자열을 호스트 이름에서 허용된 문자만으로 인코딩하는 방법으로, RFC 3492에 기술되어 있다. 퓨니코드는 유니코드가 지원하는 모든 언어로 국제화 도메인을 쓸 수 있게 한 IDNA의 일부로, 변환은 전적으로 웹 브라우저와 같은 클라이언트에서 이루어진다.

뭐그렇단다.

그래서 퓨니코드로 인코딩된 문자열로 hosted zone 을 생성하면 사용할수 있다.

갑자기 든 의문이다. 퓨니코드 서브도메인은 생성이 가능할까?

도전해 본다.

https://후이즈검색.한국/idnconv/index.jsp

에서 변환가능하다.

리눅서.linuxer.name 를 변환하면 xn--pd1b38litg.linuxer.name 가 된다.

퓨니코드로 변환된 서브도메인으로 접속시에 잘된다.

결론. 한글서브도메인 route53에서 사용가능하다. 그럼 혹시 com 도메인도 퓨니코드로 변환해서 등록이 가능하지 않을까?

xn--pd1b38litg.com 으로 검색이 되고 구매까지 이어진다.

크래딧으로는 도메인을 구매할수 없다.

등록대기중 뜨고.

결제도 되구..
엥? 진짜? 리눅스.com 생성되는거야??????????????????????

리얼리? 농담인데;;;;;;;;;;;;

자동으로 hosted zone 도 생성됬고.......돌이킬수 없게 됬다.

나는 장난으로 리눅서.com을 가지게 되었다...

1년시한부로..

당연히 될건 알았는데 사고나니 좀 웃기기도 하고 그렇다.

리눅서.com 출격합니다.

acm도 잘추가되고!

웹사이트도 잘열리고!

감사합니다.