aws 상에서 보안을 위해 그림과 같이 실제 사용하는 인스턴스는 private subnet에 숨기고, public에 bastion host 라는 걸 둬서 접근하는 방식이 있다.

이렇게 하면 관리할 구멍을 하나만 만들고 그 외에는 접근이 원천적으로 불가능해지기 때문에 보안적으로는 좋아지긴 하는데… 그 내부로 접근하기가 매우 귀찮아지는 단점이 있다.

결국 private subnet 안에 있는 인스턴스에 접근하려면 배스쳔호스트를 거쳐야 하는데,
매번 그 명령어를 까먹어서 기록해둔다.

방법은 아래와 같다

1.타겟의 22번 포트를 배스천호스트를 통해 로컬(내컴퓨터)의 33322 포트로 포워딩

1

ssh -i "bastion-host-key.pem" -N -L 33322:{target-private-ip}:22 ec2-user@{bastion-host-public-ip}

(주의) 새 터미널을 띄운 후

2.로컬호스트의 33322포트를 이용해 타겟으로 접속

1

ssh -i "target-key.pem" -p 33322 {target-user(대체로 ec2-user)}@localhost

타겟의 22번 포트를 배스천호스트를 통해 로컬(내컴퓨터)의 33322 포트로 포워딩

(용어정리)

• bastion-host-key.pem: bastion host에 접근할 수 있는 key,
• target-private-ip: 최종 접속할 인스턴스의 프라이빗 ip,
• target-key.pem: bastion host의 key,
• bastion-host-public-ip: 말 그대로 bastion host의 퍼블릭 ip

33322포트는 임의로 정한것이며 아무거나 남는 포트를 정하면 된다.
끝.

Lambda가 진정한 cloud native인걸까!

300원에 200만뷰 소화하기라는 포스팅을 읽은 적이 있습니다.

그리고
AWS와 함께 천만 사용자 웹서비스 만들기라는 슬라이드도 본 적이 있습니다.

저 슬라이드를 처음 봤던 때에는 Lambda에 대해서 많이 사용을 안해봐서 그런지 저 자료들만 보면 왠지 엄청난 트래픽을 아주 적은 비용으로 큰 문제 없이 수용할 수 있을 것만 같았습니다. 그러면서 언젠가 full-serverless 로 구성된 서비스를 한번 만들어 봐야겠다는 생각을 했었습니다. 생각만요.

생각해보면 단순히 REST API에 대한 요청만 받아주는 서비스라면 API GATEWAY + Lambda 로만 구성하는게 충분히 메리트 있을것 같았습니다. 그러면 정말 진정한 의미에 Pay-as-you-go 를 구현하는 클라우드 네이티브를 구현해볼 수 있지 않을까요…?

Lightsail 이라는 서비스가 나온지는 좀 되었다. 간단하게 소개하면 아마존에서 제공하는 웹 호스팅 서비스 이다. 기본적인 컨셉 자체는 AWS라는 복잡하고 어려운 클라우드 어쩌구를 몰라도 웹호스팅을 다른 업체만큼 싸게 제공해주는 데 목적이 있는 듯하다. 영세한 웹호스팅업계에 AWS라는 공룡이 침입한 게 아닌가 싶다. Digital Oceans 같은 호스팅업체와 제공하는 서비스와 심지어 UI까지 비슷하다. Digital Oceans는 점점 클라우드 업체처럼 되어가고 있고 아마존은 호스팅 업계의 영역까지 군침을 흘리고 있는 모양새다.

어쨌든 Lightsail은 그저 ‘아마존의 웹호스팅 서비스’라는 것이 중요하다.

그런데, AWS를 사용하고 있는 사람 입장에서는 그럼 AWS에서 EC2를 사용하는것과 Lightsail에서 사용하는 것과 뭐가 다른지가 궁금하다. 간단하게 그 차이점을 정리해보려고 한다.

대박사건. EC2 인스턴스 타입 중 작은타입을 지원하고, 테스트용, 혹은 작은규모의 로직을 돌리기에 적합하던 t타입의 인스턴스 중 3세대가 나왔다. 이전 세대인 t2 타입은 2014년에 처음 나왔고 2016년에 다양한 사이즈들이 추가됐다.

그러니깐, 4년만에 t타입의 새로운 세대가 나온 것.

당연히 t2 타입보다 성능은 올라가고, 가격은 떨어졌다. 버지니아 기준으로 가격은 10%정도 저렴하다.

아쉽게도 서울리전은 아직 지원이 안됨.

마찬가지로 t2에서 t3로 업그레이드 되면서 기본 네트워크 성능이 향상될 것으로 보인다.

(low to moderate -> up to 5 Gigabit)

정확한 사양은 더 테스트해봐야 알겠지만, 어쨌든 좋은소식임에는 분명하다.

참고: https://aws.amazon.com/ko/blogs/aws/new-t3-instances-burstable-cost-effective-performance/

AWS 상에서 Windows 서버를 복제하는 일은 Linux 서버를 복제하는 것보다 까다롭다. Linux 서버의 경우 ami만 생성하면 되지만, Windows 서버의 경우 ami 생성 후 다시 그 ami를 통해 인스턴스를 실행하면 여러가지 에러를 맞닥트리게 된다. 특히 AD Domain에 접속되어 있는 윈도우즈 서버를 그대로 ami를 떠서 복제한 경우 제대로 인스턴스가 실행되지 않는다. AD에 조인되어 있는 경우 컴퓨터의 sid 등을 통해 도메인의 멤버인지 확인하는데 ami로 복제하게 되면 이런 값들이 중복이 되서 충돌이 생기기 때문이다. 이런 경우 Sysprep 이라는 작업을 통해 시스템에 관한 정보를 초기화 한 후 ami를 생성해야한다.

대략적인 순서는 다음과 같다.

1. 네트워크 설정 초기화 (ip, dns 모두 자동)
2. sysprep
3. ami 생성
4. ami 복제 (선택사항)
5. 해당 ami로 인스턴스 실행
6. AD join

여기서 주의해야할 것은 sysprep 과정에서 시스템이 초기화된다는 것이다. sysprep은 시스템에 관련된 정보들을 초기화한다. 예를들어 sid, 도메인 정보 등이 초기화된다.

따라서 무작정 sysprep을 돌렸다간 해당 인스턴스를 복구 불가능한 상태로 만들수도 있다.

Active Directory 글을 보고 AWS 상에서 AD를 구성하는 것을 테스트해보고 있다. 하지만 이 글은 AWS의 인프라를 기준으로 작성되어 있지 한다. 여기저기 찾아봤으나 aws 상에서 AD를 구성하는 예제가 많지 않다. 사실 쉽게 AWS에서 quickstart로 나와있어서 굳이 구성 예제가 필요하지 않았던 것 같다. 그래도 사정상 테스트를 해야했기에… 일단은 부딪혀보기로 했다.

첫번재 AD를 만드는 데에는 아무 문제가 없었으나 두번째 AD를 만드는 과정에서 문제가 생겼다. example.com 으로 도메인을 만들었는데 두번째 윈도우 서버에서 그 도메인을 찾지를 못한다. nslookup으로 질의해보니 dns가 응답하지 않는다. 뭐가 문제인지 모르겠다. tcp 포트도 다 열려있는데… 그래서 그냥 모든 트래픽을 허용해버렸다. 된다.

모든 트래픽을 열어주는건 찜찜해서 dns가 어떤 포트를 쓰는지 궁금해졌다. 뒤져보니 나랑 비슷한 질문을 한 글을 발견했다. (질문: NSLookup, how to set to TCP from UDP?)

결론: 그냥 udp 53 포트를 열어주면 되는 문제였다… 질문을 열어보면 dns는 주로 udp 53 포트를 사용하고 512 byte가 넘을때만 tcp를 사용한다고 친절하고 내공있는 답변이 적혀있다. 세상은 넓고 고수는 많다. 어쨌든 AWS 상에서 수동으로 AD를 구성하고, 이전하는 것 까지 테스트를 해보고 긴 포스트를 올려볼 예정이다. 물론, 예정일 뿐이다.

위키피디아에 DNS 항목에도 다음과 같이 적혀있다.

DNS primarily uses the User Datagram Protocol (UDP) on port number 53 to serve requests.[3] DNS queries consist of a single UDP request from the client followed by a single UDP reply from the server. When the length of the answer exceeds 512 bytes and both client and server support EDNS, larger UDP packets are used. Otherwise, the query is sent again using the Transmission Control Protocol (TCP). TCP is also used for tasks such as zone transfers. Some resolver implementations use TCP for all queries.

(지금보니 그 고수의 댓글은 위키피디아에서 그냥 퍼온 것…) 그런데, TCP 포트는 몇번 포트로 통신하는거지? 그걸 알아야 여는 포트를 최소화 할수 있는데…