AWS

AWS Private Link 써보기

moonganzi 2023. 5. 11. 14:56

S3나 CloudWatch 같은 일부 AWS 서비스 들은 VPC 내부에 위치한 것이 아니기 때문에 퍼블릭 네트워크(인터넷)을 거쳐야 사용이 가능하다. 따라서 VPC 내부의 서비스 들이 인터넷을 통해야 하는 서비스를 사용하고자 할때 인터넷을 경유하기에 쓸데없는 인터넷 트래픽이 발생 하며, 그에 따라 트래픽이 외부에 노출되게 된다.

 

이러한 상황을 해결하기 위해 AWS 에서는 PrivateLink 란 기술을 지원한다. (서비스로 출시 된 것이 아닌 VPC를 서비스에 프라이빗 하게 연결하여 서비스를 VPC에 있는 것처럼 이용할 수 있는 기술)

 

PrivateLink의 작동 방식은 간단히 말하자면 서비스 사용자가 인터페이스 VPC 엔드포인트를 생성하여 서비스 공급자가 호스팅하는 엔드포인트 서비스에 연결하는 식으로 이루어 진다.

 

이를 위해 서비스 사용자는 VPC 엔드포인트를 생성해야 한다. VPC 엔드포인트는 여러 유형이 있으며, 아래와 같다.

  • Interface - TCP 트래픽을 엔드포인트로 전송하는 인터페이스 엔드포인트를 생성합니다. 엔드포인트 서비스로 전송되는 트래픽은 DNS를 사용하여 확인됩니다.
  • GatewayLoadBalancer - 프라이빗 IP 주소를 사용하여 가상 어플라이언스 플릿에 트래픽을 보내는 Gateway Load Balancer 엔드포인트를 생성합니다. 라우팅 테이블을 사용하여 VPC의 트래픽을 Gateway Load Balancer 엔드포인트로 라우팅합니다. Gateway Load Balancer는 트래픽을 가상 어플라이언스로 분산하며 수요에 맞게 확장될 수 있습니다.

PriaveLink를 사용하고자 하는 서비스에 대한 VPC 엔드포인트를 생성하게 된다면, VPC의 트래픽은 VPC 엔드포인트와 엔드포인트 서비스 간 연결을 사용하여 엔드포인트 서비스로 전송된다. VPC 엔드포인트와 엔드포인트 서비스 간 트래픽은 공개 인터넷을 통과하지 않고 AWS 네트워크 내에 머무른다.

 

글로만 보면 내용 파악이 어려우니 직접 한 번 해보자.

 

테스트는 CloudWatch를 통해 수집되는 EC2의 메트릭이 인터넷이 되지 않는 환경에서도 수집이 되는 지 확인하는 방식으로 진행해보겠다.

 

1. EC2 생성 및 CloudWatch Agent 설치

  1) EC2 생성

  • EC2 콘솔 접속 후 EC2 생성 하자. CloudWatch Agent 사용 및 CloudWatch VPC Endpoint를 사용해야 하기에 EC2에 CloudWatch 권한을 넣어야 한다. 실습에서는 편의성 Admin 권한을 부여했다.

  2) CloudWatch Agent 설치

  • EC2의 경우 CloudWatch를 통해 기본적으로 CPU 사용량, Network 트래픽 In/Out 등에 대한 모니터링만 가능하다. 메모리나 디스크 사용량을 확인하기 위해서는 Agent 설치가 필요하다.
  • CloudWatch Agent 설치 과정은 아래와 같다. (Amazon Linux 기준, Basic 지표만 수집. Custom 가능)
yum install amazon-cloudwatch-agent
cd /opt/aws/amazon-cloudwatch-agent/bin/
sudo ./amazon-cloudwatch-agent-config-wizard

================================================================
= Welcome to the Amazon CloudWatch Agent Configuration Manager =
=                                                              =
= CloudWatch Agent allows you to collect metrics and logs from =
= your host and send them to CloudWatch. Additional CloudWatch =
= charges may apply.                                           =
================================================================
On which OS are you planning to use the agent?
1. linux
2. windows
3. darwin
default choice: [1]:
1
Trying to fetch the default region based on ec2 metadata...
Are you using EC2 or On-Premises hosts?
1. EC2
2. On-Premises
default choice: [1]:
1
Which user are you planning to run the agent?
1. root
2. cwagent
3. others
default choice: [1]:
2
Do you want to turn on StatsD daemon?
1. yes
2. no
default choice: [1]:
2
Do you want to monitor metrics from CollectD? WARNING: CollectD must be installed or the Agent will fail to start
1. yes
2. no
default choice: [1]:
2
Do you want to monitor any host metrics? e.g. CPU, memory, etc.
1. yes
2. no
default choice: [1]:
1
Do you want to monitor cpu metrics per core?
1. yes
2. no
default choice: [1]:
2
Do you want to add ec2 dimensions (ImageId, InstanceId, InstanceType, AutoScalingGroupName) into all of your metrics if the info is available?
1. yes
2. no
default choice: [1]:
1
Do you want to aggregate ec2 dimensions (InstanceId)?
1. yes
2. no
default choice: [1]:
1
Would you like to collect your metrics at high resolution (sub-minute resolution)? This enables sub-minute resolution for all metrics, but you can customize for specific metrics in the output json file.
1. 1s
2. 10s
3. 30s
4. 60s
default choice: [4]:
4
Which default metrics config do you want?
1. Basic
2. Standard
3. Advanced
4. None
default choice: [1]:
1
Current config as follows:
{
        "agent": {
                "metrics_collection_interval": 60,
                "run_as_user": "cwagent"
        },
        "metrics": {
                "aggregation_dimensions": [
                        [
                                "InstanceId"
                        ]
                ],
                "append_dimensions": {
                        "AutoScalingGroupName": "${aws:AutoScalingGroupName}",
                        "ImageId": "${aws:ImageId}",
                        "InstanceId": "${aws:InstanceId}",
                        "InstanceType": "${aws:InstanceType}"
                },
                "metrics_collected": {
                        "disk": {
                                "measurement": [
                                        "used_percent"
                                ],
                                "metrics_collection_interval": 60,
                                "resources": [
                                        "*"
                                ]
                        },
                        "mem": {
                                "measurement": [
                                        "mem_used_percent"
                                ],
                                "metrics_collection_interval": 60
                        }
                }
        }
}
Are you satisfied with the above config? Note: it can be manually customized after the wizard completes to add additional items.
1. yes
2. no
default choice: [1]:

Do you have any existing CloudWatch Log Agent (http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AgentReference.html) configuration file to import for migration?
1. yes
2. no
default choice: [2]:

Do you want to monitor any log files?
1. yes
2. no
default choice: [1]:
2
Saved config file to /opt/aws/amazon-cloudwatch-agent/bin/config.json successfully.
Current config as follows:
{
        "agent": {
                "metrics_collection_interval": 60,
                "run_as_user": "cwagent"
        },
        "metrics": {
                "aggregation_dimensions": [
                        [
                                "InstanceId"
                        ]
                ],
                "append_dimensions": {
                        "AutoScalingGroupName": "${aws:AutoScalingGroupName}",
                        "ImageId": "${aws:ImageId}",
                        "InstanceId": "${aws:InstanceId}",
                        "InstanceType": "${aws:InstanceType}"
                },
                "metrics_collected": {
                        "disk": {
                                "measurement": [
                                        "used_percent"
                                ],
                                "metrics_collection_interval": 60,
                                "resources": [
                                        "*"
                                ]
                        },
                        "mem": {
                                "measurement": [
                                        "mem_used_percent"
                                ],
                                "metrics_collection_interval": 60
                        }
                }
        }
}
Please check the above content of the config.
The config file is also located at /opt/aws/amazon-cloudwatch-agent/bin/config.json.
Edit it manually if needed.
Do you want to store the config in the SSM parameter store?
1. yes
2. no
default choice: [1]:
2
Program exits now.
  • 설치 완료 시 아래와 같이 메모리, 디스크 사용량에 대한 지표 확인이 가능하다.

  3) EC2 접속 후 AWS CLI 명령어 및 nslookup을 통한 CloudWatch 인터넷 통신 확인

  • AWS CLI

  • nslookup

 

2. 라우팅 수정을 통해 인터넷 불가 환경 만든 뒤 확인해보기

  1) 라우팅 테이블 수정

  • EC2가 설치된 서브넷에 대한 라우팅 테이블에서 IGW 를 제거한다.

  2) CloudWatch 확인 및 EC2 내에서 명령어 실행해보기

  • CloudWatch 지표 수집 불가 확인

  • EC2 내에서 CLI 실행 무반응 확인 (EC2 직렬 콘솔 통해 접속)

3. VPC Endpoint 생성

  1) VPC Endpoint 생성 과정

  • VPC 콘솔 접속 및 엔드포인트 생성 클릭

  • 임의의 이름 태그 설정 후 서비스 범주에서 AWS 서비스, 서비스에서 monitoring 선택

  • 엔드포인트가 위치할 VPC, 서브넷 (프라이빗 서브넷) 선택 -> 인터페이스에 설정할 보안그룹 (Outbound 443 Open) 설정 후 생성 진행

 

4. 엔드포인트 생성 후 서비스 확인

  1) CloudWatch 콘솔 확인

  • 엔드포인트 생성 후 정상 수집 확인

  2) EC2에서 CLI 명령어 실행 및 nslookup 실행 확인

  •   CLI 명령어 실행 결과

  • nslookup 실행 결과 (엔드포인트 생성 시 설정한 서브넷 대역의 IP 확인)

 

실습을 통해 AWS PrivateLink 를 적용해보았다. AWS 를 통한 서비스 운영 중 트래픽 보호나 아웃바운드 차단 과 같이 요구사항이 있을 경우에는 충분히 도입해볼만 하다.

(단, VPC 엔드포인트 비용이 있다.https://aws.amazon.com/ko/privatelink/pricing/

 

만약 여러 개의 계정을 운영 중이며, 중앙 관리 계정을 통해 여러 계정 간의 서비스 들을 내부 통신 하고 싶다면 아래 링크를 참고하여 작업 해보자.

https://aws.amazon.com/ko/blogs/networking-and-content-delivery/integrating-aws-transit-gateway-with-aws-privatelink-and-amazon-route-53-resolver/

 

Integrating AWS Transit Gateway with AWS PrivateLink and Amazon Route 53 Resolver | Amazon Web Services

I want to take some time to dive more deeply into a use case outlined in NET301 Best Practices for AWS PrivateLink. The use case involves using AWS Transit Gateway, along with Amazon Route 53 Resolver, to share AWS PrivateLink interface endpoints between

aws.amazon.com

 

 

- 참고 자료 : https://docs.aws.amazon.com/ko_kr/vpc/latest/privatelink/what-is-privatelink.html