Securing Quick access from corporate networks with AWS PrivateLink

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Quick의 사내망 비공개 접속은 AWS Direct Connect 또는 AWS Site-to-Site VPN을 기반으로 사용자·API용 AWS PrivateLink VPC 엔드포인트와 데이터 조회용 VPC 연결을 구분해 구성하며, 기능별 지원 범위와 DNS 설정을 함께 고려해야 한다.

📌 핵심 요약

• Amazon Quick은 사내 방화벽 뒤의 데이터를 활용할 때 비공개 네트워크 경로가 필요하다. 원문은 AWS Direct Connect 또는 AWS Site-to-Site VPN으로 사내망과 VPC가 연결되어 있다는 전제에서, 인터넷 노출과 공격 표면을 줄이고 일관된 저지연 연결 및 감사 추적을 확보하는 구성을 설명한다.
• 사용자의 Quick 웹사이트·API·임베디드 콘텐츠 접근은 AWS PrivateLink 기반 VPC 엔드포인트가 담당하고, Quick의 사내 데이터베이스·내부 API 조회는 Quick 콘솔에서 설정하는 VPC 연결이 담당한다. Amazon Quick Sight, Flows, Automate, Quick Agents 등의 데이터 접근 방식에 맞춰 두 경로를 설계해야 한다.
• Amazon Quick Index의 지식 기반 VPC 연결은 현재 Amazon Redshift만 지원한다. Confluence, SharePoint, Box, Google Drive, OneDrive, Amazon S3는 Quick VPC 연결을 사용할 수 없으며, Amazon S3 버킷 정책으로 VPC 엔드포인트 접근을 제한하는 방식은 별도다.
• VPC 연결에는 Amazon Quick Enterprise 구독이 필요하며, Quick과 같은 AWS 리전의 VPC, 관련 IAM 권한, DNS 관리 권한이 요구된다. 웹사이트 VPC 엔드포인트는 AWS China Regions와 AWS GovCloud (US) Regions에서 제공되지 않으며, 엔드포인트 서브넷은 최소 2개 가용 영역에 배치하고 보안 그룹과 엔드포인트 정책을 적용한다.
• 완전한 비공개 사용자 접근에는 웹사이트용 quicksight-website와 API용 quicksight 인터페이스 엔드포인트가 필요하다. 웹사이트에는 리전별 A 레코드와 사내 DNS 연동이 필요하고 API는 프라이빗 DNS 활성화로 라우팅되지만, 액션 커넥터 API 8개와 플로 API 5개 등 총 13개 API는 지원되지 않아 이를 사용하는 자동화에는 퍼블릭 API 경로가 필요하다.

🧩 주요 포인트

1. 사용자 접근과 데이터 조회의 경로 분리 → AWS PrivateLink 엔드포인트 구성과 Quick VPC 연결 구성을 각각 충족해야 전체 비공개 연결이 성립한다.
2. Amazon Quick Index의 Amazon Redshift 한정 지원과 13개 API의 엔드포인트 미지원 → 비공개 접근 가능 범위는 데이터 소스와 자동화 기능에 따라 달라진다.
3. 리전·Amazon Quick Enterprise·최소 2개 가용 영역·DNS 조건의 결합 → 엔드포인트 생성뿐 아니라 배치 조건과 사내 이름 해석까지 검증해야 실제 접속 경로를 확인할 수 있다.

🧠 상세 정리

1. 사내 데이터 활용과 비공개 연결의 필요성

Amazon Quick의 AI 에이전트와 대시보드는 다양한 데이터 소스를 조회할 수 있지만, 데이터가 기업 방화벽 뒤나 사설 온프레미스 데이터 센터에 있으면 AWS에서 직접 접근할 네트워크 경로가 없다. 관리자는 AI 기반 인사이트와 작업에 필요한 접근성을 제공하면서도 민감한 기업 데이터가 퍼블릭 인터넷에 노출되지 않도록 해야 한다. 원문은 HIPAA, FedRAMP, PCI-DSS 같은 규제 체계가 민감한 데이터를 통제된 네트워크 경계 안에 유지하도록 요구하는 경우가 많다고 설명한다. 규정 준수가 주된 동기가 아니더라도 내부 데이터 경로의 공개는 공격 표면을 넓히고 감사 추적을 복잡하게 하며, 가변적인 지연으로 사용자 경험을 떨어뜨릴 수 있다. 제시된 구성은 이미 구축된 AWS Direct Connect 또는 AWS Site-to-Site VPN을 토대로 비공개 경로를 마련하고 보안 그룹과 VPC 엔드포인트 정책을 더해 이러한 문제를 줄이는 것을 목표로 한다.

2. 사용자 접근과 데이터 조회를 나누는 두 연결 방식

Amazon Quick은 검색, 분석, 연구, 자동화를 하나의 대화형 경험으로 제공하며, 어떤 구성 요소가 사설망에 접근하는지에 따라 연결 구조가 달라진다. 사용자가 Quick 콘솔을 열거나 대시보드와 상호작용하고 API 또는 Quick Desktop을 사용하는 트래픽은 AWS PrivateLink 기반 VPC 엔드포인트를 통해 처리한다. 반면 Quick 자체가 기업 네트워크에 들어가 데이터를 가져오는 트래픽은 Quick 콘솔에서 설정하는 VPC 연결을 사용한다. 이 연결은 VPC 안의 데이터베이스와 내부 API뿐 아니라, 연결된 온프레미스 네트워크의 리소스로 접근하는 경로도 담당한다. 따라서 사용자 세션을 비공개로 만드는 엔드포인트와 데이터 조회를 가능하게 하는 VPC 연결은 서로 다른 역할을 수행하며, 함께 설계해야 하는 구성 요소다.

3. 분석·자동화·에이전트 기능의 데이터 접근

Amazon Quick Sight는 VPC에 배치된 ENI를 통해 PostgreSQL, MySQL, SQL Server, Oracle 등의 온프레미스 데이터베이스를 직접 조회하며, 원문은 이를 VPC 연결을 가장 많이 사용하는 기능으로 설명한다. Amazon Quick Flows와 Amazon Quick Automate는 별개의 자동화 기능으로, Flows는 반복 작업을 처리하고 Automate는 사람이 과정에 참여하는 복잡한 다중 시스템 오케스트레이션을 담당한다. 두 기능은 VPC 내부에 비공개로 호스팅된 MCP 서버 등을 포함한 액션 커넥터를 호출하며, 내부 API를 호출하는 워크플로도 이 데이터 접근 경로를 따른다. 대화형 상호작용의 기반인 Quick Agents 역시 액션 커넥터를 직접 호출할 수 있고, 사용자 지정 에이전트가 사설 MCP 서버나 내부 API를 호출하면 VPC 연결을 사용한다. Apps in Quick은 구조화된 데이터와 액션 커넥터 위에 대화형 웹 애플리케이션을 구축하면서 Quick Sight 및 Flows와 같은 VPC 연결 방식을 이어받는다.

4. 검색·리서치 기능의 지원 범위와 예외

Amazon Quick Index는 Confluence, SharePoint, Amazon Simple Storage Service(Amazon S3) 등 연결된 소스를 통합하는 검색 계층을 구축한다. 그러나 VPC 내부나 온프레미스의 데이터를 위한 지식 기반 VPC 연결은 현재 Amazon Redshift에 대해서만 지원된다. Confluence, SharePoint, Box, Google Drive, OneDrive, Amazon S3는 현재 Quick VPC 연결을 사용할 수 없으므로, 통합 검색 대상이라는 사실만으로 사설 연결 지원까지 가정할 수 없다. Amazon S3 버킷 정책을 통해 버킷 접근을 VPC 엔드포인트로 제한하는 것은 가능하지만, 원문은 이를 Quick VPC 연결과 별개의 메커니즘으로 구분한다. Amazon Quick Research는 인용 근거가 포함된 보고서를 위해 공개 인터넷 데이터와 방화벽 뒤의 기업 소스를 함께 활용하며, 사설 소스에 접근할 때 VPC 연결을 사용한다. Quick Spaces는 앞선 기능들의 콘텐츠를 정리하지만 자체 데이터 연결을 시작하지 않는다.

5. 구성 전 필요한 구독·리전·권한 조건

구성을 시작하려면 활성 AWS 계정과 Amazon Quick Enterprise 구독이 필요하며, 특히 VPC 연결은 Enterprise 에디션에서만 제공된다. Quick이 배포된 AWS 리전에 기존 VPC가 있어야 하고, 사내망과 해당 VPC 사이에는 AWS Direct Connect 또는 Site-to-Site VPN 연결이 이미 구축되어 있어야 한다. Quick 웹사이트 VPC 엔드포인트는 AWS China Regions와 AWS GovCloud (US) Regions에서 제공되지 않으므로 리전 지원 여부도 사전에 확인해야 한다. 관리자는 VPC 엔드포인트, 보안 그룹, Quick 관리에 필요한 IAM 권한과 함께 VPC 연결 생성·조회·수정·삭제, 서브넷·VPC·보안 그룹 조회, 역할 목록 조회 권한을 갖춰야 한다. VPC 연결 실행 역할에 범위를 한정한 iam:PassRole 권한도 필요하며, 사설 주소로 트래픽을 보내기 위해 Route 53 프라이빗 호스팅 영역이나 온프레미스 DNS 전달 설정을 관리할 수 있어야 한다.

6. 엔드포인트 배치와 보안 경계 설계

원문이 제시하는 구성 순서는 사용자·API 접근용 VPC 엔드포인트, 데이터 소스용 VPC 연결, AWS 데이터 서비스용 VPC 엔드포인트, 필요한 외부 도메인으로의 아웃바운드 접근이라는 네 가지 요소다. 사용자 접근 예시에서는 사내 클라이언트의 요청이 AWS Direct Connect와 Direct Connect 게이트웨이를 거쳐 VPC에 들어오고, Quick VPC 엔드포인트 정책의 허용 여부 평가를 받은 뒤 AWS 네트워크를 통해 Quick에 도달한다. 엔드포인트는 Quick 계정과 같은 리전에 만들어야 하며, ENI를 배치할 서브넷은 여러 가용 영역에 분산하고 Direct Connect 또는 VPN을 통한 사내망 경로를 갖춰야 한다. 보안 그룹은 엔드포인트 ENI에 필요한 포트와 출발지 주소 범위만 허용하도록 설계한다. Quick이 Amazon S3, Amazon Redshift, Amazon Athena에 보내는 호출까지 비공개로 라우팅하려면 해당 서비스의 VPC 엔드포인트도 계획해야 한다. 실제 생성 절차에서는 최소 2개 가용 영역의 서브넷을 선택하고 보안 그룹과 엔드포인트 정책을 지정하도록 안내한다.

7. 웹사이트·API 엔드포인트와 미지원 API

Quick의 완전한 비공개 사용자 접근에는 웹사이트용 com.amazonaws.<region>.quicksight-website와 API용 com.amazonaws.<region>.quicksight라는 두 인터페이스 VPC 엔드포인트가 필요하다. 웹사이트 엔드포인트는 콘솔 사용자 트래픽의 대부분을 처리하며, 공개 URL과 프라이빗 DNS 이름이 달라 별도의 A 레코드 구성이 요구된다. API 엔드포인트는 프라이빗 DNS를 활성화하면 기존 quicksight.<region>.amazonaws.com 호출을 자동으로 비공개 경로로 보내며, FIPS 준수가 필요한 경우에는 com.amazonaws.<region>.quicksight-fips를 사용한다. 다만 액션 커넥터 관련 API 8개와 GetFlowMetadata, GetFlowPermissions, ListFlows, SearchFlows, UpdateFlowPermissions 등 플로 관련 API 5개는 API VPC 엔드포인트에서 지원되지 않는다. 따라서 액션 커넥터나 플로를 프로그램으로 관리하는 자동화에는 퍼블릭 API 엔드포인트로 접근할 경로가 필요하다. 관리자가 VPC를 통해 IAM 사용자로 로그인하는 경우에는 com.amazonaws.<region>.console과 com.amazonaws.<region>.signin 엔드포인트도 생성하도록 안내한다.

8. 사내 DNS 연동과 제공된 설명의 범위

웹사이트 접근을 위해서는 <region>.quicksight.aws.amazon.com의 A 레코드를 만들고 VPC 엔드포인트 DNS 이름으로 연결해, 사내 사용자의 이름 해석 결과가 비공개 엔드포인트를 가리키도록 해야 한다. API 접근은 엔드포인트의 프라이빗 DNS를 활성화하면 사설 IP 주소로 자동 해석되므로 웹사이트와 같은 추가 DNS 구성이 필요하지 않다고 설명한다. Route 53 프라이빗 호스팅 영역은 연결된 VPC 내부의 질의에만 응답하므로, 사내 DNS에서 해당 리전의 Quick 도메인 질의를 VPC의 Route 53 Resolver 인바운드 엔드포인트로 전달하거나 사내 DNS에 동등한 레코드를 구성해야 한다. 이후 사내망에서 이름을 해석해 퍼블릭 주소가 아닌 VPC 내부 사설 IP가 반환되는지 검증한다. 호스팅 영역은 us-east-1.quicksight.aws.amazon.com처럼 해당 리전으로 범위를 제한해 다른 Quick 호스트 이름을 덮어쓰지 않도록 한다. 제공된 원문은 프라이빗 호스팅 영역을 선택하고 VPC를 연결하는 절차 도중에 끝나므로, 이후 DNS 설정 단계나 앞서 예고한 다른 구성 요소의 상세 절차는 포함하지 않는다.

🧾 핵심 주장 / 시사점

• 비공개 접속의 성립 여부는 사용자 세션과 Quick의 데이터 조회 경로를 함께 살펴야 판단할 수 있다. AWS PrivateLink 엔드포인트만으로 모든 데이터 소스 연결이 구성되는 것은 아니다.
• Amazon Quick Index의 소스별 제약과 13개 API의 미지원은 비공개 연결 설계의 적용 범위를 제한한다. 원문의 비공개 접근 목표는 실제 사용하는 기능과 호출에 맞춰 해석해야 한다.
• 사내망에서는 엔드포인트 생성과 DNS 연동이 함께 작동해야 한다. 특히 웹사이트와 API의 이름 해석 방식이 다르므로, 사내 클라이언트에서 사설 IP가 반환되는지 확인하는 과정이 중요하다.

✅ 액션 아이템

• 사내망과 VPC 연결을 바탕으로 사용자 접근용 AWS PrivateLink 엔드포인트와 데이터 조회용 Quick VPC 연결을 구분해 구성한다.
• quicksight-website의 리전별 A 레코드와 사내 DNS 연동을 설정하고, quicksight의 프라이빗 DNS를 활성화해 사내 접속 경로를 검증한다.
• Amazon Quick Index의 Amazon Redshift 한정 지원과 13개 API의 엔드포인트 미지원을 반영해 데이터 소스와 자동화의 접속 경로를 정한다.

❓ 열린 질문

• 현재 환경은 Amazon Quick Enterprise 구독, Quick과 같은 AWS 리전의 VPC, 관련 IAM 권한과 DNS 관리 권한을 모두 갖추고 있는가?
• Amazon Quick Index에 연결하려는 데이터 소스 중 Amazon Redshift 한정 지원으로 VPC 연결을 사용할 수 없는 대상은 무엇인가?
• 현재 자동화가 엔드포인트 미지원 13개 API 중 어떤 API를 사용하며, 해당 호출에 필요한 퍼블릭 API 경로는 어떻게 확보할 것인가?