쿠키 기본 설정 선택

당사는 사이트와 서비스를 제공하는 데 필요한 필수 쿠키 및 유사한 도구를 사용합니다. 고객이 사이트를 어떻게 사용하는지 파악하고 개선할 수 있도록 성능 쿠키를 사용해 익명의 통계를 수집합니다. 필수 쿠키는 비활성화할 수 없지만 '사용자 지정' 또는 ‘거부’를 클릭하여 성능 쿠키를 거부할 수 있습니다.

사용자가 동의하는 경우 AWS와 승인된 제3자도 쿠키를 사용하여 유용한 사이트 기능을 제공하고, 사용자의 기본 설정을 기억하고, 관련 광고를 비롯한 관련 콘텐츠를 표시합니다. 필수가 아닌 모든 쿠키를 수락하거나 거부하려면 ‘수락’ 또는 ‘거부’를 클릭하세요. 더 자세한 내용을 선택하려면 ‘사용자 정의’를 클릭하세요.

설정
문의하기
피드백
AWS Documentation
AWS 계정 생성
VPC에서 스택 실행 - AWS OpsWorks
VPC 기초AWS OpsWorks Stacks Stack용 VPC 생성

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

VPC에서 스택 실행

PDFRSS
중요

이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 만료되었으며 신규 및 기존 고객 모두에 대해 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 AWS re:Post 또는 AWS Premium Support를 통해 AWS Support 팀에 문의하세요.

Virtual Private Cloud(VPC)에서 스택의 인스턴스를 생성하여 이에 대한 사용자 액세스를 제어할 수 있습니다. 예를 들어 스택의 앱 서버나 데이터베이스에 사용자들이 직접 액세스하는 대신 모든 퍼블릭 트래픽을 탄력적 로드 밸런서를 통해 채널링되도록 해야 할 경우가 있습니다.

VPC에서 스택을 실행하는 기본적 절차는 다음과 같습니다.

  1. Amazon VPC 콘솔이나 API 또는 AWS CloudFormation 템플릿을 사용하여 적절히 구성된 VPC를 생성합니다.

  2. 스택을 생성할 때 VPC ID를 지정합니다.

  3. 적절한 서브넷에서 스택의 인스턴스를 시작합니다.

다음은 AWS OpsWorks Stacks에서 VPC가 작동하는 방식에 대한 간략한 설명입니다.

중요

VPC 엔드포인트 기능을 사용하는 경우, 스택의 각 인스턴스는 Amazon Simple Storage Service(S3)에서 다음 작업을 완료할 수 있어야 합니다.

  • 인스턴스 에이전트 설치.

  • Ruby 등의 자산 설치.

  • Chef 실행 로그 업로드.

  • 스택 명령 검색.

이러한 작업이 가능하려면 스택의 인스턴스는 스택의 리전과 일치하는 다음 버킷에 액세스할 수 있어야 합니다. 그렇지 않으면 이전 작업이 실패합니다.

Chef 12 Linux 및 Chef 12.2 Windows의 경우, 버킷은 다음과 같습니다.

Agent Buckets Asset Buckets Log Buckets DNA Buckets

  • opsworks-instance-agent-sa-east-1

  • opsworks-instance-agent-ap-south-1

  • opsworks-instance-agent-ap-northeast-1

  • opsworks-instance-agent-ap-northeast-2

  • opsworks-instance-agent-ap-southeast-1

  • opsworks-instance-agent-ap-southeast-2

  • opsworks-instance-agent-ca-central-1

  • opsworks-instance-agent-eu-central-1

  • opsworks-instance-agent-eu-west-1

  • opsworks-instance-agent-eu-west-2

  • opsworks-instance-agent-eu-west-3

  • opsworks-instance-agent-us-east-1

  • opsworks-instance-agent-us-east-2

  • opsworks-instance-agent-us-west-1

  • opsworks-instance-agent-us-west-2

  • opsworks-instance-assets-us-east-2

  • opsworks-instance-assets-us-east-1

  • opsworks-instance-assets-ap-south-1

  • opsworks-instance-assets-ap-northeast-1

  • opsworks-instance-assets-ap-northeast-2

  • opsworks-instance-assets-ap-southeast-1

  • opsworks-instance-assets-ap-southeast-2

  • opsworks-instance-assets-ca-central-1

  • opsworks-instance-assets-eu-central-1

  • opsworks-instance-assets-eu-west-1

  • opsworks-instance-assets-eu-west-2

  • opsworks-instance-assets-eu-west-3

  • opsworks-instance-assets-sa-east-1

  • opsworks-instance-assets-us-west-1

  • opsworks-instance-assets-us-west-2

  • opsworks-us-east-2-log

  • opsworks-us-east-1-log

  • opsworks-ap-south-1-log

  • opsworks-ap-northeast-1-log

  • opsworks-ap-northeast-2-log

  • opsworks-ap-southeast-1-log

  • opsworks-ap-southeast-2-log

  • opsworks-ca-central-1-log

  • opsworks-eu-central-1-log

  • opsworks-eu-west-1-log

  • opsworks-eu-west-2-log

  • opsworks-eu-west-3-log

  • opsworks-sa-east-1-log

  • opsworks-us-west-1-log

  • opsworks-us-west-2-log

  • opsworks-us-east-2-dna

  • opsworks-us-east-1-dna

  • opsworks-ap-south-1-dna

  • opsworks-ap-northeast-1-dna

  • opsworks-ap-northeast-2-dna

  • opsworks-ap-southeast-1-dna

  • opsworks-ap-southeast-2-dna

  • opsworks-ca-central-1-dna

  • opsworks-eu-central-1-dna

  • opsworks-eu-west-1-dna

  • opsworks-eu-west-2-dna

  • opsworks-eu-west-3-dna

  • opsworks-sa-east-1-dna

  • opsworks-us-west-1-dna

  • opsworks-us-west-2-dna

Linux용 Chef 11.10 및 이전 버전의 경우, 버킷은 다음과 같습니다. Chef 11.4 스택은 미국 동부(버지니아 북부) 밖의 리전 엔드포인트에서는 지원되지 않습니다.

Agent Buckets Asset Buckets Log Buckets DNA Buckets

  • opsworks-instance-agent-us-east-2

  • opsworks-instance-agent-us-east-1

  • opsworks-instance-agent-ap-south-1

  • opsworks-instance-agent-ap-northeast-1

  • opsworks-instance-agent-ap-northeast-2

  • opsworks-instance-agent-ap-southeast-1

  • opsworks-instance-agent-ap-southeast-2

  • opsworks-instance-agent-ca-central-1

  • opsworks-instance-agent-eu-central-1

  • opsworks-instance-agent-eu-west-1

  • opsworks-instance-agent-eu-west-2

  • opsworks-instance-agent-eu-west-3

  • opsworks-instance-agent-us-east-1

  • opsworks-instance-agent-us-west-1

  • opsworks-instance-agent-us-west-2

  • opsworks-instance-assets-us-east-2

  • opsworks-instance-assets-us-east-1

  • opsworks-instance-assets-ap-south-1

  • opsworks-instance-assets-ap-northeast-1

  • opsworks-instance-assets-ap-northeast-2

  • opsworks-instance-assets-ap-southeast-1

  • opsworks-instance-assets-ap-southeast-2

  • opsworks-instance-assets-ca-central-1

  • opsworks-instance-assets-eu-central-1

  • opsworks-instance-assets-eu-west-1

  • opsworks-instance-assets-eu-west-2

  • opsworks-instance-assets-eu-west-3

  • opsworks-instance-assets-sa-east-1

  • opsworks-instance-assets-us-west-1

  • opsworks-instance-assets-us-west-2

  • prod_stage-log

  • prod_stage-dna

자세한 내용은 VPC 엔드포인트를 참조하세요.

참고

AWS OpsWorks Stacks 에이전트는 여전히 퍼블릭 엔드포인트에 액세스해야 하므로 AWS OpsWorks Stacks가 활성화한 VPC 엔드포인트에 연결하려면 NAT 또는 퍼블릭 IP에 대한 라우팅도 구성해야 합니다.

VPC 기초

VPC에 대한 자세한 논의는 Amazon Virtual Private Cloud를 참조하세요. 간략히 말해 VPC는 각각 하나 이상의 인스턴스를 포함하고 있는 하나 이상의 서브넷으로 구성됩니다. 각각의 서브넷에는 대상 IP 주소를 기반으로 아웃바운드 트래픽을 전달하는 연결된 라우팅 테이블이 있습니다.

  • VPC 내의 인스턴스는 기본적으로 서브넷에 상관없이 서로 통신할 수 있습니다. 하지만 네트워크 ACL(액세스 제어 목록) 또는 보안 그룹 정책을 변경하거나 고정 IP 주소를 사용할 경우 이 통신이 불가능할 수 있습니다.

  • 인스턴스가 인터넷과 통신할 수 있는 서브넷을 퍼블릭 서브넷이라고 합니다.

  • 인스턴스가 VPC 내의 다른 인스턴스와만 통신할 수 있고 인터넷과 직접 통신할 수 없는 서브넷은 프라이빗 서브넷이라고 합니다.

AWS OpsWorks Stacks는 프라이빗 서브넷의 인스턴스를 포함하여 스택의 모든 인스턴스가 다음 엔드포인트에 액세스할 수 있도록 VPC를 구성해야 합니다.

  • 의 "리전 지원" 섹션에 나열된 AWS OpsWorks Stacks 서비스 엔드포인트 중 하나입니다AWS OpsWorks Stacks 시작하기.

  • AWS OpsWorks Stacks 에이전트에서 사용하는 다음 인스턴스 서비스 엔드포인트 중 하나입니다. 이 에이전트는 관리형 고객 인스턴스에서 실행되면서 서비스와 데이터를 교환합니다.

    • opsworks-instance-service.us-east-2.amazonaws.com

    • opsworks-instance-service.us-east-1.amazonaws.com

    • opsworks-instance-service.us-west-1.amazonaws.com

    • opsworks-instance-service.us-west-2.amazonaws.com

    • opsworks-instance-service.ap-south-1.amazonaws.com

    • opsworks-instance-service.ap-northeast-1.amazonaws.com

    • opsworks-instance-service.ap-northeast-2.amazonaws.com

    • opsworks-instance-service.ap-southeast-1.amazonaws.com

    • opsworks-instance-service.ap-southeast-2.amazonaws.com

    • opsworks-instance-service.ca-central-1.amazonaws.com

    • opsworks-instance-service.eu-central-1.amazonaws.com

    • opsworks-instance-service.eu-west-1.amazonaws.com

    • opsworks-instance-service.eu-west-2.amazonaws.com

    • opsworks-instance-service.eu-west-3.amazonaws.com

  • Amazon S3

  • Amazon Linux 또는 Ubuntu Linux 리포지토리와 같이 운영 체제가 기반하는 패키지 리포지토리.

  • 앱 및 사용자 지정 쿡북 리포지토리.

이 연결을 제공하도록 VPC를 구성하는 방법은 다양합니다. 다음은 AWS OpsWorks Stacks 앱 서버 스택에 대한 VPC를 구성하는 방법의 간단한 예입니다.

VPC diagram showing public and private subnets, NAT, load balancing, and connections to external services.

이 VPC에는 몇 가지 구성 요소가 있습니다.

서브넷

VPC에는 2개의 서브넷(퍼블릭 서브넷 1개, 프라이빗 서브넷 1개)이 있습니다.

  • 퍼블릭 서브넷에는 로드 밸런서와 외부 주소 및 프라이빗 서브넷의 인스턴스와 통신할 수 있는 네트워크 주소 변환(NAT) 디바이스가 포함됩니다.

  • 프라이빗 서브넷에는 퍼블릭 서브넷의 NAT 및 로드 밸런서와 통신할 수 있지만 직접 외부 주소와는 통신할 수 없는 애플리케이션 서버가 포함됩니다.

인터넷 게이트웨이

인터넷 게이트웨이는 로드 밸런서처럼 퍼블릭 IP 주소를 가진 인스턴스가 VPC 외부의 주소와 통신할 수 있도록 합니다.

로드 밸런서

Elastic Load Balancing 로드 밸런서는 사용자에게서 오는 트래픽을 받아 프라이빗 서브넷의 앱 서버에 분산시키고 응답을 사용자에게 반환합니다.

NAT

(NAT) 디바이스가 앱 서버에 제공하는 제한적인 인터넷 액세스는 일반적으로 외부 리포지토리에서 소프트웨어 업데이트를 다운로드하는 등의 용도에 사용됩니다. 모든 AWS OpsWorks Stacks 인스턴스는 AWS OpsWorks Stacks 및 적절한 Linux 리포지토리와 통신할 수 있어야 합니다. 이 문제를 처리하는 한 가지 방법은 연결된 탄력적 IP 주소가 있는 NAT 디바이스를 퍼블릭 서브넷에 두는 것입니다. 그러면 NAT을 통해 프라이빗 서브넷의 인스턴스에서 아웃바운드 트래픽을 라우팅할 수 있습니다.

참고

단일 NAT 인스턴스는 프라이빗 서브넷의 아웃바운드 트래픽에서 단일 장애 지점을 생성합니다. 한 인스턴스에 장애가 발생하면 다른 인스턴스가 대체하는 NAT 인스턴스 쌍으로 VPC를 구성하면 안정성을 높일 수 있습니다. 자세한 내용은 Amazon VPC NAT 인스턴스의 고가용성을 참조하세요. NAT 게이트웨이도 사용할 수 있습니다. 자세한 정보는 Amazon VPC 사용 설명서의 NAT 섹션을 참조하세요.

최적의 VPC 구성은 AWS OpsWorks Stacks 스택에 따라 달라집니다. 다음은 일부 VPC 구성을 사용할 수 있는 몇 가지 예입니다. 다른 VPC 시나리오의 예는 Amazon VPC 시나리오를 참조하세요.

Working with one instance in a public subnet(퍼블릭 서브넷에서 단일 인스턴스로 작업)

공개적으로 액세스할 수 없는 Amazon RDS 인스턴스와 같이 프라이빗 리소스가 연결되어 있지 않은 단일 인스턴스 스택이 있는 경우, 퍼블릭 서브넷 하나로 VPC를 만들고 해당 서브넷에 인스턴스를 배치할 수 있습니다. 기본 VPC를 사용하지 않는 경우, 인스턴스의 계층이 인스턴스에 탄력적 IP 주소를 할당하도록 해야 합니다. 자세한 내용은 OpsWorks 계층 기초 단원을 참조하십시오.

[프라이빗 리소스 사용하기]

공용 액세스가 가능하면 안 되는 리소스가 있는 경우, 퍼블릭 서브넷 1개와 프라이빗 서브넷 1개가 있는 VPC를 생성할 수 있습니다. 예를 들어 로드 밸런싱된 자동 조정 환경에서는 모든 Amazon EC2 인스턴스를 프라이빗 서브넷에 두고 로드 밸런서를 퍼블릭 서브넷에 둘 수 있습니다. 이렇게 하면 Amazon EC2 인스턴스는 인터넷에서 직접 액세스할 수 없으며, 모든 수신 트래픽은 로드 밸런서를 통해 라우팅되어야 합니다.

프라이빗 서브넷은 Amazon EC2 직접 사용자 액세스로부터 인스턴스를 격리시키지만, 여전히 AWS 및 적절한 Linux 패키지 리포지토리로 아웃바운드 요청을 전송해야 합니다. 이러한 요청을 허용하려면 예컨대 네트워크 주소 변환(NAT) 디바이스를 탄력적 IP 주소와 함께 사용한 다음 NAT을 통해 인스턴스의 아웃바운드 트래픽을 라우팅할 수 있습니다. 앞의 예에 나온 것처럼 로드 밸런서와 같은 퍼블릭 서브넷에 NAT을 둘 수 있습니다.

  • Amazon RDS 인스턴스와 같은 백엔드 데이터베이스를 사용하는 경우, 이러한 인스턴스를 프라이빗 서브넷에 둘 수 있습니다. Amazon RDS 인스턴스의 경우, 서로 다른 가용 영역에 2개 이상의 서로 다른 서브넷을 지정해야 합니다.

  • 프라이빗 서브넷의 인스턴스에 직접 액세스해야 하는 경우(예: SSH를 사용하여 인스턴스에 로그인하려는 경우) 인터넷의 요청을 프록시하는 퍼블릭 서브넷에 Bastion Host를 배치할 수 있습니다.

[AWS로 자체 네트워크 확장하기]

네트워크를 클라우드로 확장하고 VPC에서 직접 인터넷에 액세스하려는 경우, VPN 게이트웨이를 생성할 수 있습니다. 자세한 내용은 시나리오 3: 퍼블릭 및 프라이빗 서브넷이 있고 하드웨어 VPN 액세스를 제공하는 VPC를 참조하세요.

AWS OpsWorks Stacks Stack용 VPC 생성

이 섹션에서는 예제 AWS CloudFormation 템플릿을 사용하여 AWS OpsWorks Stacks 스택에 대한 VPC를 생성하는 방법을 보여줍니다. 템플릿은 OpsWorksVPCtemplates.zip 파일로 다운로드할 수 있습니다. 이 주제에서 설명한 것과 같은 VPC를 수동으로 생성하는 방법에 대한 자세한 내용은 시나리오 2: 퍼블릭 및 프라이빗 서브넷이 있는 VPC를 참조하세요. 라우팅 테이블, 보안 그룹 등등의 구성 방법에 대한 자세한 정보는 예제 템플릿 단원을 참조하세요.

참고

기본적으로 AWS OpsWorks Stacks는와 같은 CIDR 범위와 가용 영역을 연결하여 서브넷 이름을 표시합니다10.0.0.1/24 - us-east-1b. 이름을 더 읽기 쉽게 만들려면 키가 로, Name 값이 서브넷 이름으로 설정된 각 서브넷에 대한 태그를 생성합니다. 그런 다음 AWS OpsWorks 스택은 서브넷 이름을 기본 이름에 추가합니다. 예를 들어 다음 예제의 프라이빗 서브넷에는 이름이 Private으로 설정된 태그가 있으며, OpsWorks는 이를 10.0.0.1/24 us-east - 1b - Private으로 표시합니다.

몇 단계만 거치면 AWS CloudFormation 콘솔을 사용하여 VPC 템플릿을 시작할 수 있습니다. 다음 절차에서는 예제 템플릿을 사용하여 미국 동부(버지니아 북부) 리전에 VPC를 생성합니다. 템플릿을 사용해 다른 리전에서 VPC를 생성하는 방법에 대한 지침은 절차 뒤에 나오는 참고를 참조하세요.

VPC를 생성하려면

  1. AWS CloudFormation 콘솔을 열고, 미국 동부(버지니아 북부) 리전을 선택한 다음 스택 생성을 선택합니다.

  2. 템플릿 선택 페이지에서 템플릿 업로드를 선택합니다. OpsWorksVPCtemplates.zip 파일에서 다운로드한 OpsWorksinVPC.template 파일을 찾아봅니다. 계속을 선택합니다.

    CloudFormation 템플릿 선택 페이지

    AWS CloudFormation 샘플 템플릿을 열고, AWS OpsWorks Stacks VPC 템플릿을 찾은 다음, 스택 시작을 선택하여이 스택을 시작할 수도 있습니다.

  3. 파라미터 지정 페이지에서 기본값을 수락하고 계속을 선택합니다.

  4. 태그 추가 페이지에서 키는 Name으로, 값은 VPC 이름으로 설정하여 태그를 생성합니다. 이 태그를 사용하면 AWS OpsWorks Stacks 스택을 생성할 때 VPC를 더 쉽게 식별할 수 있습니다.

  5. 계속 및 닫기를 차례로 선택하여 스택을 시작합니다.

참고: 다음 방법 중 하나를 사용하여 다른 리전에서 VPC를 생성할 수 있습니다.

  • 다른 리전에서 템플릿 사용으로 이동하여 적절한 리전을 선택하고 AWS OpsWorks 스택 VPC 템플릿을 찾은 다음 스택 시작을 선택합니다.

  • 템플릿을 시스템에 복사하고 AWS CloudFormation 콘솔에서 적절한 리전을 선택한 다음 스택 생성 마법사의 Amazon S3에 템플릿 업로드 옵션을 사용해 시스템에서 템플릿을 업로드합니다.

예제 템플릿에는 Stacks 스택을 생성하는 데 필요한 VPC, 서브넷 및 로드 AWS OpsWorks 밸런서 IDs를 제공하는 출력이 포함되어 있습니다. AWS CloudFormation 콘솔 창 하단의 출력 탭을 선택하여 볼 수 있습니다.

Stack outputs table showing VPC, subnet, and load balancer IDs for an OpsWorks-in-VPC stack.

다음 주제:

스택 업데이트

이전 주제:

새 스택 생성

도움이 필요하십니까?

프라이버시사이트 이용 약관쿠키 기본 설정
© 2025, Amazon Web Services, Inc. 또는 계열사. All rights reserved.