원본 글)

https://www.securesign.kr/guides/kb/54

.pem
PEM (Privacy Enhanced Mail)은 Base64 인코딩된 ASCII 텍스트 이다. 파일 구분 확장자로 .pem 을 주로 사용한다.  노트패드에서 열기/수정도 가능하다. 개인키, 서버인증서, 루트인증서, 체인인증서 및  SSL 발급 요청시 생성하는 CSR 등에 사용되는 포맷이며, 가장 광범위하고 거의 99% 대부분의 시스템에 호환되는 산업 표준 포맷이다. (대부분 텍스트 파일)

.crt
거의 대부분 PEM 포맷이며, 주로 유닉스/리눅스 기반 시스템에서 인증서 파일임을 구분하기 위해서 사용되는 확장자 이다. 다른 확장자로 .cer 도 사용된다. 파일을 노트패드 등으로 바로 열어 보면 PEM 포맷인지 바이너리 포맷인지 알수 있지만 99% 는 Base64 PEM 포맷이라고 봐도 무방하다. (대부분 텍스트 파일)

.cer
거의 대부분 PEM 포맷이며, 주로 Windows 기반에서 인증서 파일임을 구분하기 위해서 사용되는 확장자 이다. crt 확장자와 거의 동일한 의미이며, cer 이나 crt 확장자 모두 윈도우에서는 기본 인식되는 확장자이다. 저장할때 어떤 포맷으로 했는지에 따라 다르며, 이름 붙이기 나름이다.

.csr
Certificate Signing Request 의 약자이며 거의 대부분 PEM 포맷이다. SSL 발급 신청을 위해서 본 파일 내용을 인증기관 CA 에 제출하는 요청서 파일임을 구분하기 위해서 붙이는 확장자 이다. (대부분 텍스트 파일)

.der
Distinguished Encoding Representation (DER) 의 약자이며, 바이너리 포맷이다. 노트패드등으로 열어 봐서는 알아 볼수 없다.  바이너리 인코딩 포맷을 읽을수 있는 인증서 라이브러리를 통해서만 내용 확인이 가능하다.  사설 또는 금융등 특수 분야 및 아주 오래된 구형 시스템을 제외하고는, 최근 웹서버 SSL 작동 시스템 에서는 흔히 사용되는 포맷은 아니다. (바이너리 이진 파일)

.pfx / .p12
PKCS#12 바이너리 포맷이며, Personal Information Exchange Format 를 의미한다. 주로 Windows IIS 기반에서  인증서 적용/이동시 활용된다. 주요 장점으로는 개인키,서버인증서,루트인증서,체인인증서를 모두 담을수 있어서 SSL 인증서 적용이나 또는 이전시 상당히 유용하고 편리하다. Tomcat 등 요즘에는 pfx 설정을 지원하는 서버가 많아지고 있다.  (바이너리 이진 파일)

.key
주로 openssl 및 java 에서 개인키 파일임을 구분하기 위해서 사용되는 확장자이다. PEM 포맷일수도 있고 DER 바이너리 포맷일수도 있으며, 파일을 열어봐야 어떤 포맷인지 알수가 있다. 저장할때 어떤 포맷으로 했는지에 따라 다르며, 확장자는 이름 붙이기 나름이다.

.jks
Java Key Store 의 약자이며, Java 기반의 독자 인증서 바이너리 포맷이다. pfx 와 마찮가지로 개인키,서버인증서,루트인증서,체인인증서를 모두 담을수 있어서 SSL 인증서 파일 관리시 유용하다. Tomcat 에서 SSL 적용시 가장 많이 사용되는 포맷이다. (바이너리 이진 파일)

VPC 를 구성 하면서 외부 통신을 위해서는 IGW 가 꼭 필요 합니다.

만약 외부 통신이 필요 하지 않은 VPC 라면 IGW 를 구성 하지 않아도 되겠죠.

NAT GW 는 VPC 구성 후 Private Subnet 에 있는 리소스가 외부와 Internet 통신을 하기 위해 필요한 서비스 입니다.

이 과정에서 Elastic IP 가 필요 합니다.

이 두 GW 의 차이점이 더 궁금하신 분은 아래 문서 참고 하세요.

https://medium.com/awesome-cloud/aws-vpc-difference-between-internet-gateway-and-nat-gateway-c9177e710af6

Internet Gateway

An Internet Gateway (IGW) is a logical connection between an Amazon VPC and the Internet. It is not a physical device. Only one can be associated with each VPC. It does not limit the bandwidth of Internet connectivity. (The only limitation on bandwidth is the size of the Amazon EC2 instance, and it applies to all traffic — internal to the VPC and out to the Internet.)

If a VPC does not have an Internet Gateway, then the resources in the VPC cannot be accessed from the Internet (unless the traffic flows via a corporate network and VPN/Direct Connect).

An Internet Gateway allows resources within your VPC to access the internet, and vice versa. In order for this to happen, there needs to be a routing table entry allowing a subnet to access the IGW.

That is to say — an IGW allows resources within your public subnet to access the internet, and the internet to access said resources.

A subnet is deemed to be a Public Subnet if it has a Route Table that directs traffic to the Internet Gateway.

NAT Gateway

A NAT Gateway does something similar, but with two main differences:

1. It allows resources in a private subnet to access the internet (think yum updates, external database connections, wget calls, OS patch, etc)
2. It only works one way. The internet at large cannot get through your NAT to your private resources unless you explicitly allow it.

AWS introduced a NAT Gateway Service that can take the place of a NAT Instance. The benefits of using a NAT Gateway service are:

• It is a fully-managed service — just create it and it works automatically, including fail-over
• It can burst up to 10 Gbps (a NAT Instance is limited to the bandwidth associated with the EC2 instance type)

However:

• Security Groups cannot be associated with a NAT Gateway
• You’ll need one in each AZ since they only operate in a single AZ