스택을 다음과 같이 실행합니다. VPC

중요

더 AWS OpsWorks Stacks 서비스 수명이 2024년 5월 26일에 종료되었으며 신규 및 기존 고객 모두 사용할 수 없습니다. 고객은 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션할 것을 강력히 권장합니다. 마이그레이션에 대해 궁금한 점이 있으면 다음 연락처로 문의하십시오. AWS Support 팀 구성: AWS re:포스트 포스트 또는 스루 AWS 프리미엄 지원.

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

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

1. Amazon VPC VPC 콘솔을 사용하여 적절하게 구성된 파일을 생성하거나 API AWS CloudFormation 템플릿.

2. 스택을 생성할 때 VPC ID를 지정하십시오.

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

다음은 에서의 VPCs 작업 방식을 간략하게 설명합니다. AWS OpsWorks 스택.

중요

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

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

• Ruby 등의 자산 설치.

• Chef 실행 로그 업로드.

• 스택 명령 검색.

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

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

Agent Buckets	Asset Buckets	Log Buckets	DNA버킷
opsworks-instance-agent-sa-이스트-1 opsworks-instance-agent-ap-사우스-1 opsworks-instance-agent-ap-북동부-1 opsworks-instance-agent-ap- 북동부 - 2 opsworks-instance-agent-ap- 남동부 - 1 opsworks-instance-agent-ap- 사우스이스트 - 2 opsworks-instance-agent-ca- 센트럴 -1 opsworks-instance-agent-eu-센트럴 -1 opsworks-instance-agent-eu-웨스트-1 opsworks-instance-agent-eu-웨스트-2 opsworks-instance-agent-eu-웨스트-3 opsworks-instance-agent-us-이스트-1 opsworks-instance-agent-us-이스트-2 opsworks-instance-agent-us-웨스트-1 opsworks-instance-agent-us-웨스트-2	opsworks-instance-assets-us-이스트-2 opsworks-instance-assets-us-이스트-1 opsworks-instance-assets-ap-사우스-1 opsworks-instance-assets-ap-북동부-1 opsworks-instance-assets-ap- 북동부 - 2 opsworks-instance-assets-ap- 남동부 - 1 opsworks-instance-assets-ap- 사우스이스트 - 2 opsworks-instance-assets-ca- 센트럴 -1 opsworks-instance-assets-eu-센트럴 -1 opsworks-instance-assets-eu-웨스트-1 opsworks-instance-assets-eu-웨스트-2 opsworks-instance-assets-eu-웨스트-3 opsworks-instance-assets-sa-이스트-1 opsworks-instance-assets-us-웨스트-1 opsworks-instance-assets-us-웨스트-2	opsworks-us-east-2-로그 opsworks-us-east-1-로그 opsworks-ap-south-1-로그 opsworks-ap-northeast-1-로그 opsworks-ap-northeast-2-로그 opsworks-ap-southeast-1-로그 opsworks-ap-southeast-2-로그 opsworks-ca-central-1-로그 opsworks-eu-central-1-로그 opsworks-eu-west-1-로그 opsworks-eu-west-2-로그 opsworks-eu-west-3-로그 opsworks-sa-east-1-로그 opsworks-us-west-1-로그 opsworks-us-west-2-로그	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버킷
opsworks-instance-agent-us-이스트-2 opsworks-instance-agent-us-이스트-1 opsworks-instance-agent-ap-사우스-1 opsworks-instance-agent-ap-북동부-1 opsworks-instance-agent-ap- 북동부 - 2 opsworks-instance-agent-ap- 남동부 - 1 opsworks-instance-agent-ap- 사우스이스트 - 2 opsworks-instance-agent-ca- 센트럴 -1 opsworks-instance-agent-eu-센트럴 -1 opsworks-instance-agent-eu-웨스트-1 opsworks-instance-agent-eu-웨스트-2 opsworks-instance-agent-eu-웨스트-3 opsworks-instance-agent-us-이스트-1 opsworks-instance-agent-us-웨스트-1 opsworks-instance-agent-us-웨스트-2	opsworks-instance-assets-us-이스트-2 opsworks-instance-assets-us-이스트-1 opsworks-instance-assets-ap-사우스-1 opsworks-instance-assets-ap-북동부-1 opsworks-instance-assets-ap- 북동부 - 2 opsworks-instance-assets-ap- 남동부 - 1 opsworks-instance-assets-ap- 사우스이스트 - 2 opsworks-instance-assets-ca- 센트럴 -1 opsworks-instance-assets-eu-센트럴 -1 opsworks-instance-assets-eu-웨스트-1 opsworks-instance-assets-eu-웨스트-2 opsworks-instance-assets-eu-웨스트-3 opsworks-instance-assets-sa-이스트-1 opsworks-instance-assets-us-웨스트-1 opsworks-instance-assets-us-웨스트-2	prod_stage-log	prod_stage-dna

자세한 내용은 VPC 엔드포인트 단원을 참조하십시오.

참고

를 위해 AWS OpsWorks 스택을 활성화한 VPC 엔드포인트에 연결하려면 다음과 같이 사용자 NAT 또는 공용 IP에 대한 라우팅도 구성해야 합니다. AWS OpsWorks Stacks 에이전트는 여전히 퍼블릭 엔드포인트에 대한 액세스 권한이 필요합니다.

VPC기본 사항

에 대한 자세한 내용은 Amazon Virtual Private Cloud를 참조하십시오. VPCs 간단히 말해서 a는 하나 이상의 VPC 서브넷으로 구성되며 각 서브넷에는 하나 이상의 인스턴스가 포함되어 있습니다. 각각의 서브넷에는 대상 IP 주소를 기반으로 아웃바운드 트래픽을 전달하는 연결된 라우팅 테이블이 있습니다.

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

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

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

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

• 다음 중 하나 AWS OpsWorks 의 “지역 지원” 섹션에 나열된 서비스 엔드포인트를 스택합니다. AWS OpsWorks 스택으로 시작하기

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

  • 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 리포지토리와 같이 운영 체제가 기반하는 패키지 리포지토리.

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

다양한 방법으로 a를 구성하여 이러한 연결을 제공할 수 있습니다. VPC 다음은 컴퓨터를 위해 구성하는 방법에 VPC 대한 간단한 예입니다. AWS OpsWorks 앱 서버 스택을 스택합니다.

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

서브넷

VPC에는 두 개의 서브넷, 즉 퍼블릭 서브넷과 프라이빗 서브넷이 있습니다.

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

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

인터넷 게이트웨이

인터넷 게이트웨이를 사용하면 로드 밸런서와 같이 퍼블릭 IP 주소를 가진 인스턴스가 외부 주소와 통신할 수 있습니다. VPC

로드 밸런서

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

NAT

(NAT) 기기는 앱 서버에 제한된 인터넷 액세스를 제공하며, 이는 일반적으로 외부 저장소에서 소프트웨어 업데이트를 다운로드하는 등의 목적으로 사용됩니다. 모두 AWS OpsWorks 스택 인스턴스는 다음과 통신할 수 있어야 합니다. AWS OpsWorks 스택 및 적절한 Linux 리포지토리와 함께. 이 문제를 해결하는 한 가지 방법은 연결된 엘라스틱 IP 주소가 있는 NAT 디바이스를 퍼블릭 서브넷에 배치하는 것입니다. 그런 다음 프라이빗 서브넷의 인스턴스에서 나오는 아웃바운드 트래픽을 를 를 통해 라우팅할 수 있습니다. NAT

참고

단일 NAT 인스턴스로 인해 프라이빗 서브넷의 아웃바운드 트래픽에 단일 장애 지점이 생성됩니다. 한 쌍에 장애가 발생할 경우 서로를 대신하는 NAT 인스턴스 VPC 쌍으로 구성하여 안정성을 개선할 수 있습니다. 자세한 내용은 Amazon VPC NAT 인스턴스의 고가용성을 참조하십시오. NAT게이트웨이를 사용할 수도 있습니다. 자세한 내용은 Amazon VPC 사용 설명서를 참조하십시오 NAT.

최적의 VPC 구성은 사용자에 따라 다릅니다. AWS OpsWorks 스택 스택. 다음은 특정 VPC 구성을 사용할 수 있는 경우의 몇 가지 예입니다. 다른 VPC 시나리오의 예는 Amazon 사용 시나리오를 참조하십시오 VPC.

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

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

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

공개적으로 액세스할 수 없는 리소스가 있는 경우 퍼블릭 서브넷 VPC 하나와 프라이빗 서브넷 하나를 사용하여 리소스를 생성할 수 있습니다. 예를 들어 부하가 분산된 자동 조정 환경에서는 모든 Amazon EC2 인스턴스를 프라이빗 서브넷에, 로드 밸런서를 퍼블릭 서브넷에 배치할 수 있습니다. 이렇게 하면 인터넷에서 Amazon EC2 인스턴스에 직접 액세스할 수 없습니다. 들어오는 모든 트래픽은 로드 밸런서를 통해 라우팅되어야 합니다.

프라이빗 서브넷은 인스턴스를 Amazon의 EC2 직접 사용자 액세스로부터 격리하지만 여전히 아웃바운드 요청을 적절한 Linux 패키지 AWS 리포지토리로 보내야 합니다. 예를 들어, 자체 엘라스틱 IP 주소가 있는 네트워크 주소 변환 (NAT) 디바이스를 사용하고 이를 통해 인스턴스의 아웃바운드 트래픽을 라우팅하면 이러한 요청을 허용할 수 있습니다. NAT 이전 NAT 예와 같이 로드 밸런서와 동일한 퍼블릭 서브넷에 배치할 수 있습니다.

• Amazon RDS 인스턴스와 같은 백엔드 데이터베이스를 사용하는 경우 해당 인스턴스를 프라이빗 서브넷에 배치할 수 있습니다. Amazon RDS 인스턴스의 경우 서로 다른 가용 영역에 최소 두 개의 서로 다른 서브넷을 지정해야 합니다.

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

자체 네트워크를 다음과 같이 확장하십시오. AWS

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

를 VPC 위해 생성하십시오. AWS OpsWorks 스택 스택

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

참고

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

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

생성하려면 VPC

1. AWS CloudFormation 콘솔에서 미국 동부 (버지니아 북부) 지역을 선택하고 [Create Stack] 을 선택합니다.

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

   

   AWS CloudFormation 샘플 템플릿을 열고 다음 위치를 찾아 이 스택을 시작할 수도 있습니다. AWS OpsWorks 스택 VPC 템플릿을 선택하고 스택 시작을 선택합니다.

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

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

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

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

• 다른 지역의 템플릿 사용으로 이동하여 적절한 지역을 선택하고 해당 지역을 찾으십시오. AWS OpsWorks 스택 VPC 템플릿을 선택한 다음 Launch Stack을 선택합니다.

• 템플릿 파일을 시스템에 복사하고 해당 지역을 선택합니다. AWS CloudFormation콘솔에서 스택 생성 마법사의 Amazon S3에 템플릿 업로드 옵션을 사용하여 시스템에서 템플릿을 업로드하십시오.

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