일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 1697
- c++ 정규식
- 정규식 활용
- c3 축 없애기
- linux시간으로 변경
- grafana dashboard
- influxdb 설치
- semanage
- subporcess path
- gcc 업데이트
- gcc regex
- 정규식 문자열 출력
- snmp
- c3 second
- snmp test
- g++ 업데이트
- c3 초
- 백준
- telegraf
- c3 축 가리기
- c3 step graph
- CentOS7
- 정규식 컴파일
- regex_search
- python os
- python popen
- InfluxDB
- centos pyhon 설치
- python subprocess
- selinux port 등록
- Today
- Total
리셋 되지 말자
Private Subnet to Endpoint - s3 본문
Endpoint 사용 이유
- Private subnet은 Internet gateway와 연결되어 있지 않으므로 외부에서 접근할 수 없지만, 외부로 연결할 수 없다.
- S3나 ECR은 VPC 내부 서비스가 아닌 Public 서비스 이므로 외부 연결이 가능해야 접근 가능하다.
- Private subnet에서 S3 사용을 위해 Internet gateway에 연결하면 Private인 이유가 없어진다. 이를 해결하기 위해 NAT gateway를 사용할 수는 있다. 하지만 외부를 통해 S3로 연결하는 것은 변하지 않는다.
- 외부를 통해 S3에 접근하면 내부 -> 외부 -> S3로 접근하고, S3 -> 외부 -> 내부로 트래픽이 발생하기 때문에 비용도 증가한다.
위의 단점들을 해결하기 위해 Private subnet에서도 바로 S3나 ECR과 같은 Public 서비스에 바로 접근할 수 있도록 Endpoint 서비스가 있다. 이를 이용하면 외부 인터넷을 통하지 않고 바로 S3, ECR에 접근할 수 있으므로 비용절감 효과도 있다고 한다.
여기서는 외부 인터넷이 불가능한 Private subnet에 생성한 Server에서 S3와 ECR에 접근할 수 있는지 테스트 해본다.
테스트 구성
Private subnet에 생성한 Server는 Public subnet에 생성한 Bastion에서 접속한다.
- Bastion : 192.168.0.73
- EC2 : 192.168.1.244
외부 ping 테스트
Bastion은 외부 통신이 가능하지만, EC2는 불가능하다.
- Bastion
[ec2-user@ip-192-168-0-73 ~]$ ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=101 time=32.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=101 time=32.3 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=101 time=32.3 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 32.311/32.323/32.343/0.208 ms
- EC2
[ec2-user@ip-192-168-1-244 ~]$ ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2045ms
S3 서비스 주소 확인
nslookup을 사용해 192.168.0.2 DNS에서 S3 서비스 주소를 반환하는 것을 확인할 수 있다. 해당 주소로 ping을 보내면 ping이 간다.
[ec2-user@ip-192-168-0-73 ~]$ nslookup https://<AWS ID>.s3.ap-northeast-2.amazonaws.com
Server: 192.168.0.2
Address: 192.168.0.2#53
Non-authoritative answer:
https://<AWS ID>.s3.ap-northeast-2.amazonaws.com canonical name = s3-r-w.ap-northeast-2.amazonaws.com.
Name: s3-r-w.ap-northeast-2.amazonaws.com
Address: <s3 address>
Bucket 조회
aws configure
위 명령어로 버킷에 대한 자격 증명을 실행한 뒤, 버킷 리스트를 조회해본다. Bastion에서는 bucket 조회가 가능하지만, EC2에서는 조회가 불가능하다.
- Bastion
[ec2-user@ip-192-168-0-73 ~]$ aws s3 ls
2021-11-24 04:27:49 csapi-bucket
Endpoint 생성 및 Router 연결
1. VPC -> 엔드포인트 -> 엔드포인트 생성
2. s3 검색 후, s3 Gateway 선택한 뒤 생성
3. VPC 선택 후, private subnet에 연결된 라우팅 테이블을 선택한 뒤 생성
4. 라우팅 테이블에 Endpoint가 추가된 것을 확인
Private subnet에서 S3 접근이 가능한지 확인
- EC2
[ec2-user@ip-192-168-1-244 ~]$ aws s3 ls
2021-11-24 04:27:49 csapi-bucket
Endpoint 연결 전엔 s3 연결이 불가능했던 것과 달리, 연결 후에는 s3 접근이 가능하다.
nslookup으로 알아낸 s3 서비스 ip 주소로 traceroute 명령어를 사용해보면 Bastion에서는 공인 ip를 거쳐서 s3 서비스에 도달하는 반면, EC2 에서는 아래와 같이 비공개 라우터들을 거쳐서 도착하는 것을 확인할 수 있다.
- Bastion
- EC2
'AWS' 카테고리의 다른 글
ECR 사용 (0) | 2021.11.29 |
---|---|
Private Subnet to Endpoint - ecr api (0) | 2021.11.28 |
Certificate Manager (0) | 2021.09.07 |
Route 53 (0) | 2021.09.07 |
Auto Scaling (0) | 2021.09.07 |