에서 스택 실행 VPC - AWS OpsWorks
VPC 기본 사항AWS OpsWorks Stacks StackVPC용 생성

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

에서 스택 실행 VPC

중요

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

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

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

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

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

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

다음은 AWS OpsWorks Stacks에서 VPCs가 작동하는 방식을 간략하게 설명합니다.

중요

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-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 버킷

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

VPC 기본 사항

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

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

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

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

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

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

  • 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 있습니다. 다음은 Stacks 앱 서버 스택에 VPC 대해 AWS OpsWorks 를 구성하는 방법의 간단한 예입니다.

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

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

서브넷

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

  • 퍼블릭 서브넷에는 외부 주소 및 프라이빗 서브넷의 인스턴스와 통신할 수 있는 로드 밸런서와 네트워크 주소 변환(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으로를 생성하고 해당 서브넷에 인스턴스를 배치할 수 있습니다. 기본를 사용하지 않는 경우 인스턴스의 계층이 인스턴스에 탄력적 IP 주소를 할당해야 VPC합니다. 자세한 내용은 OpsWorks 계층 기본 사항 단원을 참조하십시오.

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

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

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

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

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

자체 네트워크를 로 확장 AWS

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

AWS OpsWorks Stacks StackVPC용 생성

이 섹션에서는 예제 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. 템플릿 선택 페이지에서 템플릿 업로드를 선택합니다. .zip OpsWorksinVPC.template 파일에서 다운로드한 파일을 찾습니다.계속을 선택합니다. OpsWorksVPCtemplates

    CloudFormation 템플릿 선택 페이지

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

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

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

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

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

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

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

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

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