<aside> ☁️

클라우드웨이브 네트워크 1주차 · 5/5 · 약 5분

클라우드웨이브 부트캠프: 네트워크에서 클라우드 네이티브까지

</aside>

네트워크 첫 주의 마지막 날에는 DHCP와 SDN을 거쳐 AWS PrivateLink까지 학습했다. 처음에는 서로 관련 없는 주제처럼 보였다. DHCP는 IP를 자동으로 받는 기술, SDN은 네트워크 자동화, PrivateLink는 AWS 기능 정도로 따로 기억했다.

한 주의 흐름 안에서 다시 보니 공통점이 있었다. 호스트에 필요한 설정을 전달하고, 네트워크 경로를 소프트웨어로 제어하며, 서비스에 들어가는 전용 진입점을 만드는 과정이었다.

이 글에서 확인할 것

DHCP는 주소만 나눠 주는 것이 아니다

DHCP를 사용하면 호스트가 네트워크에 참여하는 데 필요한 정보를 동적으로 받을 수 있다. 대표적인 흐름은 Discover, Offer, Request, Acknowledgement로 설명한다.

DHCP가 전달할 수 있는 정보에는 IP 주소뿐 아니라 서브넷 마스크, 기본 게이트웨이, DNS 서버 등이 포함된다. 주소는 정상인데 DNS나 게이트웨이 설정이 잘못돼 통신이 실패할 수도 있다는 뜻이다.

따라서 동적 할당 환경에서 문제가 생기면 “IP를 받았는가?”만 확인하지 않고, 어떤 네트워크 설정을 함께 받았는지도 확인해야 한다.

SDN을 AWS 콘솔과 연결해 보기

SDN은 네트워크의 제어 로직과 실제 패킷 전달을 분리하고, 소프트웨어로 네트워크를 구성하고 제어하는 관점이다.

AWS에서 VPC, 서브넷, 라우팅 테이블, 보안 그룹, 엔드포인트를 API나 IaC로 만드는 경험도 이 관점과 연결된다. 물리 장비의 케이블을 직접 바꾸지 않아도 논리 네트워크와 정책을 코드로 만들고 수정할 수 있다.

처음에는 AWS 콘솔의 각 메뉴가 독립된 설정처럼 보였지만, 결국 패킷의 주소·경로·허용 조건을 소프트웨어로 정의하는 구성요소였다.

PrivateLink는 VPC 전체를 연결하지 않는다

다른 VPC의 서비스를 사용해야 할 때 퍼블릭 엔드포인트를 만들 수도 있고, VPN이나 피어링으로 네트워크를 연결할 수도 있다. PrivateLink는 네트워크 전체를 넓게 연결하는 대신 필요한 서비스나 리소스에 프라이빗 진입점을 제공한다.

Interface Endpoint를 사용하는 경우 소비자 VPC의 서브넷에 프라이빗 IP를 가진 엔드포인트 네트워크 인터페이스가 만들어진다. DNS가 서비스 이름을 이 엔드포인트의 주소로 해석하면 애플리케이션은 퍼블릭 인터넷을 통과하지 않고 제공자 서비스로 접근할 수 있다.

flowchart LR
    subgraph Consumer["소비자 VPC"]
        A["Private App"] --> B["Private DNS"]
        B --> C["Interface Endpoint<br/>Private IP"]
    end
    C --> D["AWS PrivateLink"]
    subgraph Provider["서비스 제공자"]
        D --> E["Endpoint Service"]
        E --> F["Load Balancer"]
        F --> G["Private Service"]
    end

여기서 중요한 점은 소비자가 제공자 VPC의 모든 주소에 접근하게 되는 것이 아니라는 점이다. 허용된 서비스 진입점에 연결하는 구조다. 특정 API나 내부 서비스를 제공하되 네트워크 전체를 노출하고 싶지 않을 때 검토할 수 있다.