woody

아래는 기본 CloudFormation 환경이다. 위와 같은 환경에서는 아직 피어링 연결이 안됐기 때문에, 두 VPC는 기본적으로 서로 통신이 불가능하다. SSH 접근을 통해 각 EC2의 퍼블릭 IP로 접속 후 프라이빗 IP로 통신이 되는지 확인해보자. 위와 같이 통신 불가임을 알 수 있다.(반대도 마찬가지) 피어링을 생성해보자. ​ 이후 수락자에서 수락을 해야 피어링 생성이 완료된다. 현재까지 진행된 내용은 다음과 같다. 이제 각 VPC에서 반대편 VPC의 서브넷과 프라이빗 통신을 하기위한 라우팅 테이블을 작성하자. ​ 위처럼 상대 대역을 설정하고, 대상으로 VPC 피어링을 지정해준다. 마찬가지로 VPC2에서도 동일하게 라우팅 테이블을 추가해준다. ​ 그럼 위와같이 연결이 완료된다. 마지막으로, 인스턴..

시드니와 상파울루에 구성된 웹 서버에 대해 Global Accelerator를 통해 연결하고 다양한 검증을 한다. ​ 기본 CloudFormation 환경이다. ​ 서울 리전에 기본 인스턴스 하나를 생성하고 SSH 접근하여 시드니와 상파울루에 생성한 리소스와 통신해본다. ​ 여기까지는, Global Accelerator가 아닌 여러 ISP 네트워크를 거쳐서 통신 되고있다. ​ Global Accelerator의 서비스 관리는 오레곤 리전(us-east-2)에서 수행한다. 따라서 서비스에 접근하면 자동으로 오레곤 리전으로 설정된다. ​ Global Accelerator를 생성해보자 이름설정 ​ 2. 리스너 설정 ​ 3. 엔드포인트 그룹 추가 ​ 4. 엔드포인트 추가 시드니 리전 엔드포인트 추가(ALB) 상..

상파울루 리전에 웹서버 EC2 인스턴스를 구성 후 사용자 PC에서 직접적인 연결과 AWS CloudFront를 통한 CDN 서비스의 연결 차이를 비교해보자. ​ 리전을 상파울루 SA-EAST-1로 이동 후 CloudFormation을 통해 환경을 구성한다. ​ ​ 이후 Routee 53 A 레코드를 생성하여 SA-EC2와 도메인을 연결한다. ​ 구글 크롬에 접속해 F12키를 눌러 개발자 도구를 출력하고, 네트워크 탭을 클릭해 지연시간을 확인해본다. 대용량 이미지에 의해 5.55s의 높은 지연시간을 가지고 있다. ​ 이제 CloudFront를 사용해 CDN 기능을 사용해보자. 먼저 Distribution을 생성한다. CloudFront --> Distribution(배포) --> Create Distrib..

ALB를 통해 부하분산되는 2개의 인스턴스 환경에서 Route 53을 통해 직접 설정한 도메인으로 접속해보자. ​ 기본 CloudFormation 환경은 아래와 같다. ​ 생성된 ALB의 DNS 이름을 확인하고 인터넷 브라우저에서 해당 주소로 접근해보면 라운드 로빈 형태로 번갈아 접근되는 것을 확인할 수 있다. ​ 로드밸런서 DNS 주소와 생성한 도메인 주소와 연결하기 위해 Route 53 -> 호스팅영역 -> 도메인 선택 -> 레코드 생성 -> 단순라우팅, 별칭체크, ALB/CLB에 대한 별칭, 레코드 유형 A선택 후 레코드 생성완료 ​ 레코드 생성 후 해당 도메인 주소로 접근하면 위 사진과 동일하게 접속이 가능해진다. Failover 환경을 구성해보자. 우선 Route 53 -> 상태검사 에 진입해 ..

NLB 로드 밸런서를 생성하여 UDP 프로토콜 중 SNMP 서비스에 대한 부하 분산을 해보자. ​ SNMP는 Simple Network Management Protocol의 약자로 네트워크 관리를 위한 규약이다. OID(Object Identifier)라는 값을 호출하여 시스템에 대한 정보를 파악할 수 있다. SNMP는 UDP 161포트를 사용한다. ​ NLB 생성과정은 다음과 같다. 로드밸런서 생성 -> NLB 선택 -> 이름 지정 및 인터넷 경계 선택 -> 리스너에 UDP선택 및 포트번호 161 지정 -> VPC를 ELB-VPC로 지정하고 가용영역 2개 모두 체크 후 서브넷 지정 -> 새 대상 그룹 생성 -> 이름 지정 및 프로토콜 UDP 지정 후 포트번호 161 설정 -> 상태검사 프로토콜은 HTT..

CloudFormation을 통한 기본 환경이다. ​ ALB 로드 밸런서를 생성해 HTTP 서비스에 대한 부하 분산을 해보자. 로드밸런서 생성을 클릭 -> ALB 선택 -> 리스너에 HTTP(포트80) 선택 -> 가용영역에서 ALB가 포함될 VPC 선택하고, 두개의 가용영역과 각 서브넷을 선택 -> 이후 보안그룹 지정 -> 대상 그룹을 생성하여 라우팅 지정(상태검사 까지 모든 프로토콜을 HTTP로 지정) ​ 다음과 같이 도식화가 완성된다. 검증 ​ 생성한 ALB의 DNS주소를 복사하고, putty를 통해 My-VPC내의 인스턴스로 SSH접근을 시도하고, curl 명령을 통해 ALB로 HTTP 접근을 시도한다. 다음과 같이 로드밸런서를 통해 번갈아 가면서 ELB-VPC 내의 인스턴스에 접근하는 것을 확인할..

엔드포인트 서비스는 사용자가 직접 생성한 서비스에 프라이빗 연결을 하기위해 사용한다. ​ 실습을 위한 기본 CloudFormation 환경은 이렇다. 엔드포인트 서비스를 생선하기 전, 로드밸런서의 DNS 주소에 대한 IP주소 정보를 확인해보자. 다음과 같이 dig 명령을 통해 ip주소를 확인할 수 있고, curl 명령으로 HTML 정보를 확인할 수 있다. ​ 이제 엔드포인트 서비스를 생성해 프라이빗 통신을 해보자. 우선 엔드포인트 서비스 생성버튼을 누르고, 생성한 로드밸런서를 선택한다. 생성을 완료하면 엔드포인트 서비스의 서비스 이름을 복사해둔다. 다음으로 연결할 인터페이스 엔드포인트를 생성한다. 서비스 범주를 기존의 AWS 서비스에서 이름별 서비스 찾기로 변경하고 복사해둔 엔드포인트 서비스를 붙여넣기하..

게이트웨이 엔드포인트 주어진 템플릿을 활용해 CloudFormation으로 기본환경을 구성했다. -> VPC, 퍼블릭 &프라이빗 서브넷, 라우팅테이블, 인터넷 게이트웨이, EC2 인스턴스 ​ SSH를 통해 퍼블릭&프라이빗 EC2인스턴스에 접속하고 S3서비스에 핑 확인을 해보면, 퍼블릭 EC2는 인터넷 게이트웨이를 통해 통신이 가능하고 프라이빗 EC2는 통신할 수 없다는 것을 알 수 있다. ​ 이 때, 통신대상이 AWS 서비스 중 S3이므로 게이트웨이 엔드포인트를 생성해보자. 생성과정에서 S3를 대상으로 하고, 생성한 VPC, 생성한 퍼블릭&프라이빗 라우팅 테이블을 연결한다. ​ 생성 후 퍼블릭&프라이빗 라우팅 테이블에 접속하면 S3 서비스에 대한 경로가 생성된 것을 확인할 수 있다. ​ 이후 SSH를 통..

퍼블릭 VPC 순서는 다음과 같다. VPC 생성 퍼블릭 서브넷 생성 인터넷 게이트 웨이 생성 및 VPC 연결 퍼블릭 라우팅 테이블 생성 및 서브넷 연결 퍼블릭 라우팅 테이블 경로 설정 ​ VPC 생성 기본 VPC 인프라와 구분짓기 위해 이름 태그를 통해 새로운 VPC 인프라를 생성한다. IPv4 CIDR은 10.0.0.0/16 ​ 퍼블릭 서브넷 생성 IPv4 CIDR을 10.0.0.0/24로 설정하고, 가용 영역을 2a로 설정한다. (아직은 인터넷 게이트웨이가 연결되지 않은 상황이라 프라이빗 서브넷이다.) ​ 인터넷 게이트웨이 생성 및 VPC 연결 게이트웨이를 생성하고 Detached 상태를 새로 생성한 VPC와 연결해준다. (인터넷 게이트웨이가 생성되고 VPC에 연결되었지만 라우팅 경로가 없기 때문에 ..

CloudFormation 은 AWS 인프라에 대해 코딩으로 선언하는 방법이다. (JSON이나 YAML) ​ 이때, 필요한 IT리소스가 코드로 정의되어 있는 파일을 템플릿이라 하며, 템플릿을 CloudFormationdp 업로드하여 스택을 생성 할 수 있다. 스택을 생성하면 템플릿에 정의된 AWS 인프라 자원에 대해 순서대로 생성한다. 순서에 맞게 스택을 생성하면 실습 1과 같이 자동으로 EC2 인스턴스가 생성되며 이전 실습과 동일한 환경이 된다. 스택으로 생성된 인스턴스와 실습 1에서 생성한 인스턴스를 삭제하는 모습이다. 출처 : 따라하며 배우는 AWS 네트워크 입문