AWS PrivateLink, VPC Lattice, EventBridge 및 Step Functions를 사용하여 VPC 및 계정 경계를 넘어 AWS 리소스 공유

언제부턴가 모든 AWS 고객은 저에게 가능한 한 빨리 미래로 나아가고 싶다고 말합니다. 고객은 현대화 작업을 간소화하고, 성장을 주도하고, 클라우드에 적응하는 동시에 진행 과정에서 비용을 절감하고자 합니다.

이러한 고객은 일반적으로 조직의 여러 부서에서 관리하는 다양한 기술 스택에서 실행되며 온프레미스에서도 실행 가능한 대규모 레거시 애플리케이션 제품군을 보유하고 있습니다. 이러한 문제가 상황을 더 어렵게 만들면서 엄격한 보안 및 규정 준수 요구 사항을 충족해야 하는 경우가 많습니다.

공유 준비
이제 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, Amazon Elastic Container Service(Amazon ECS) 및 Amazon Elastic Kubernetes Service(Amazon EKS) 컨테이너 서비스와 같은 AWS 리소스와 Amazon Virtual Private Cloud(Amazon VPC) 및 여러 AWS 계정에서 자체 HTTPS 서비스를 공유하고 이를 사용하여 Amazon EventBridge를 통해 이벤트 기반 앱을 빌드하고 AWS Step Functions를 통해 워크플로를 오케스트레이션할 수 있습니다. 기존 워크로드를 업데이트하고, 최신 클라우드 네이티브 앱을 온프레미스 레거시 시스템에 연결하고, 모든 통신을 프라이빗 엔드포인트 및 네트워크로 라우팅할 수 있습니다.

이러한 새로운 기능은 Amazon VPC Lattice와 AWS PrivateLink를 기준으로 하며, 전체 기술 스택에서 통합 및 오케스트레이션할 수 있는 멋지고 새로운 방법과 함께 네트워크를 설계하고 제어할 수 있는 다양한 새로운 옵션을 제공합니다. 예를 들어 기존 온프레미스 애플리케이션을 사용하는 하이브리드 이벤트 기반 아키텍처를 빌드할 수 있습니다.

오늘날 일부 고객은 AWS Lambda 함수 또는 Amazon Simple Queue Service(Amazon SQS) 대기열을 사용하여 데이터를 VPC로 전송합니다. 이렇게 일상적이고 번거로운 작업 부담은 이제 더 간단하고 효율적인 솔루션으로 대체될 수 있습니다.

이 모든 것을 종합하여 애플리케이션 위치와 관계없이 현대화 작업을 가속화하고 애플리케이션 간 통합을 간소화하는 데 도움이 되는 일련의 서비스를 얻을 수 있습니다. EventBridge 및 Step Functions는 PrivateLink 및 VPC Lattice와 함께 작동하여 퍼블릭 및 프라이빗 HTTPS 기반 애플리케이션을 이벤트 기반 아키텍처 및 워크플로에 통합할 수 있습니다.

필수 용어와 개념은 다음과 같습니다.

리소스 소유자 VPC – 공유할 리소스가 있는 VPC입니다. 이 VPC의 소유자는 하나 이상의 관련 리소스 구성이 포함된 리소스 게이트웨이를 생성한 다음, AWS Resource Access Manager(RAM)를 사용하여 다른 AWS 계정이나 EventBridge 및 Step Functions를 사용하여 이벤트 기반 아키텍처 및 워크플로를 빌드하는 개발자와 같은 리소스 소비자와 리소스 구성을 공유합니다. 리소스 소유자를 조직 내에서 이 VPC의 관리 및 공급을 담당하는 사람(귀하)으로 정의해 보겠습니다.

리소스 게이트웨이 – 게이트웨이와 연결된 리소스 구성에 표시된 대로 클라이언트가 리소스 소유자 VPC의 리소스에 액세스할 수 있도록 VPC에 수신 지점을 제공합니다. 하나의 리소스 게이트웨이에서 여러 리소스를 사용할 수 있습니다.

리소스 – 리소스 소유자 VPC 내의 HTTPS 엔드포인트입니다. 여기에는 데이터베이스, 데이터베이스 클러스터, EC2 인스턴스, 여러 EC2 인스턴스 앞에 있는 Application Load Balancer, AWS Cloud Map을 통해 검색 가능한 ECS 서비스, Network Load Balancer를 지원하는 Amazon Elastic Kubernetes Service(Amazon EKS) 서비스, AWS Site-to-Site VPN 또는 AWS Direct Connect를 통해 온프레미스에서 실행되는 레거시 서비스가 포함될 수 있습니다.

리소스 구성 – 특정 리소스 게이트웨이를 통해 액세스할 수 있는 리소스 세트를 정의합니다. 리소스는 IP 주소, DNS 이름 또는 ARN(AWS 리소스의 경우)으로 참조할 수 있습니다.

리소스 소비자 – 리소스 소유자 VPC의 리소스에서 제공하는 서비스와 연결되고 이러한 서비스를 사용하는 애플리케이션을 빌드하는 조직 내 사람입니다.

리소스 공유
이 모든 기능을 다양한 방식으로 활용할 수 있습니다. 여기서는 그중 한 가지 방식을 중점적으로 살펴볼 것입니다.

먼저 리소스 소유자 역할을 수행하겠습니다. VPC 콘솔에서 리소스 게이트웨이를 클릭하고 게이트웨이가 없는 것을 확인한 다음, 리소스 게이트웨이 생성을 클릭합니다.

이름(main-rg)과 IP 주소 유형을 할당한 다음, 게이트웨이가 배치될 VPC와 프라이빗 서브넷을 선택합니다. 이 선택은 일회성으로 진행되며 새 리소스 게이트웨이를 생성하지 않고는 변경할 수 없습니다. 또한 인바운드 트래픽을 제어할 보안 그룹을 최대 5개 선택합니다.

아래로 스크롤하여 원하는 태그를 지정하고 리소스 게이트웨이 생성을 클릭하여 계속 진행합니다.

새 게이트웨이가 몇 초 만에 활성화됩니다. 인정한다는 의미로 고개를 끄덕이고 리소스 구성 생성을 클릭하여 계속 진행합니다.

이제 첫 번째 리소스 구성을 생성해야 합니다. 리소스 소유자 VPC의 프라이빗 서브넷에 있는 EC2 인스턴스에서 HTTPS 서비스를 실행하고 있다고 가정해 보겠습니다. 서비스에 DNS 이름을 할당하고 인스턴스의 IP 주소를 반환하는 Amazon Route 53 별칭 레코드를 사용합니다.

이 예시에서는 퍼블릭 호스팅 영역을 사용합니다. 이미 프라이빗 호스팅 영역을 지원하기 위해 작업 중입니다.

DNS가 모두 설정되었으면 리소스 구성 생성을 클릭하여 계속 진행합니다. 이름(rc-service1)을 입력하고 유형으로 리소스를 선택한 다음, 이전에 생성한 리소스 게이트웨이를 선택합니다.

아래로 스크롤하여 EC2 인스턴스를 리소스로 정의하고 DNS 이름을 입력한 후 포트 80 및 443에 대한 공유를 설정합니다.

이제 조금 우회하여 RAM 콘솔로 이동한 후 다른 AWS 계정이 리소스에 액세스할 수 있도록 리소스 공유를 생성합니다. 이 작업은 선택 사항이며 교차 계정 시나리오에만 해당됩니다. 각 서비스에 대해 하나의 리소스 공유를 생성할 수 있지만, 대부분의 경우에는 하나의 공유를 생성한 후 관련 서비스 컬렉션을 패키징하는 데 사용합니다. 이렇게 작업할 예정이므로 이 공유를 shared-services로 지칭하겠습니다.

다시 돌아와서 리소스 공유 목록을 새로 고치고 생성한 리소스 공유 목록을 선택한 다음, 리소스 구성 생성을 클릭합니다.

리소스 구성은 몇 초 내에 준비됩니다.

요약 및 계획 시간
진행하기 전에 간단히 요약하고 몇 가지 계획을 세워보겠습니다. 리소스 제공자 역할을 맡아 지금까지 수행한 작업은 다음과 같습니다.

• MainVPC – 내 리소스 소유자 VPC.
• main-rg – MainVPC의 리소스 게이트웨이.
• rc-service1 – main-rg에 대한 리소스 구성.
• service1 – MainVPC의 프라이빗 서브넷에 있는 EC2 인스턴스에서 고정 IP 주소로 호스팅되는 HTTPS 서비스.

다음 단계는 무엇일까요?

공유 – 최우선적이고 가장 확실한 용도입니다. AWS Resource Access Manager(RAM)를 사용하여 리소스 구성을 다른 AWS 계정과 공유하고 다른 VPC에서 서비스에 액세스할 수 있습니다. 한편으로(리소스 소비자 입장에서) 공유된 서비스에 연결하기 위해 몇 가지 간단한 단계를 거치게 됩니다.

• 서비스 네트워크 – 서비스 네트워크를 생성하고, 서비스 네트워크에 리소스 구성을 추가하고, VPC에 VPC 엔드포인트를 생성하여 서비스 네트워크에 연결할 수 있습니다.
• 엔드포인트 – VPC에 VPC 엔드포인트를 생성하고 엔드포인트를 통해 공유 리소스에 액세스할 수 있습니다.

현대화 – 레거시 Lambda 또는 SQS 통합을 제거하여 번거로운 작업 부담을 해소할 수 있습니다.

빌드 – EventBridge와 Step Functions를 사용하여 이벤트 기반 아키텍처를 빌드하고 애플리케이션을 오케스트레이션할 수 있습니다. 이 옵션을 선택하겠습니다.

EventBridge와 Step Functions를 사용하여 프라이빗 리소스에 액세스
EventBridge와 Step Functions를 사용하면 이미 Slack, Salesforce, Adobe와 같은 SaaS 제공업체에서 제공하는 것과 같은 퍼블릭 HTTPS 엔드포인트에 쉽게 액세스할 수 있습니다. 오늘 출시되므로 프라이빗 HTTPS 서비스를 사용하는 것도 그만큼 쉬워졌습니다.

리소스 소비자는 EventBridge 연결을 생성하고, 공유된 리소스 구성을 참조하고, 이벤트 기반 애플리케이션에서 서비스를 호출하기만 하면 됩니다. 이미 알고 있는 모든 기능이 그대로 제공되며, 이제 프라이빗 서비스에 액세스할 새로운 권한을 갖게 되었습니다.

EventBridge 연결을 생성하려면 EventBridge 콘솔을 열고 통합 메뉴에서 연결을 클릭합니다.

기존 연결을 검토한 다음(지금까지는 없음) 연결 생성을 클릭하여 계속 진행합니다.

연결에 대한 이름(MyService1)과 설명을 입력하고 API 유형으로 프라이빗을 선택한 다음, 이전에 생성한 리소스 구성을 선택합니다.

아래로 스크롤하여 연결 중인 서비스에 대한 인증을 구성해야 합니다. 사용자 지정 구성 및 기본 인증을 선택하고 서비스의 사용자 이름과 암호를 입력합니다. 또한 쿼리 문자열에 Action=Forecast를 추가하고(아시다시피 많은 권한 부여 옵션이 있음) 생성을 클릭합니다.

연결은 몇 분 안에 생성되고 준비됩니다. 그런 다음 HTTP 태스크를 사용하고, 연결을 선택하고, API 엔드포인트의 URL을 입력하고, HTTP 메서드를 선택하여 Step Functions 워크플로우에서 사용합니다.

이제 끝났습니다. 이제 Step Functions 워크플로에서 프라이빗 리소스를 사용할 수 있습니다!

또한 이 연결을 이벤트 버스 및 파이프에서 EventBridge API 대상으로 사용할 수도 있습니다.

알아야 할 사항
멋진 새 기능에 대해 알아야 할 몇 가지 사항은 다음과 같습니다.

요금 – VPC로의 데이터 전송에 대한 GB당 요금을 포함하여 Step Functions, EventBridge, PrivateLink 및 VPC Lattice의 기존 요금이 적용됩니다.

리전 – 미국 동부(오하이오, 버지니아 북부), 미국 서부(캘리포니아 북부, 오레곤), 아프리카(케이프타운), 아시아 태평양(서울, 홍콩, 뭄바이, 오사카, 싱가포르, 시드니, 도쿄), 캐나다(중부), 유럽(프랑크푸르트, 아일랜드, 런던, 밀라노, 파리, 스톡홀름), 중동(바레인) 및 남아메리카(상파울루)를 포함하는 21개 AWS 리전에서 리소스 게이트웨이 및 리소스 구성을 생성하고 사용할 수 있습니다.

작업 중인 영역 – 앞서 말씀드린 대로 프라이빗 호스팅 영역을 지원하기 위해 작업 중입니다. 또한 EventBridge와 Step Functions를 통해 다른 유형의 AWS 리소스에 대한 액세스도 지원할 계획입니다.

– Jeff