기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Elastic Beanstalk의 개념 이해 개념과 용어에 익숙해지면 Elastic Beanstalk를 사용하여 애플리케이션을 배포하는 데 필요한 사항을 이해하는 데 도움이 됩니다. ![\[Elastic Beanstalk 애플리케이션과 웹/작업자 환경 간의 관계를 보여주는 예시 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/images/aeb-overview.png) ## 애플리케이션 Elastic Beanstalk *애플리케이션*은 *환경*, *버전* 및 *환경 구성*을 포함한 Elastic Beanstalk 구성 요소를 위한 컨테이너입니다. Elastic Beanstalk 애플리케이션 내에서 코드 실행과 관련된 모든 리소스를 관리합니다. ## 애플리케이션 버전 Elastic Beanstalk에서 *애플리케이션 버전*은 웹 애플리케이션의 배포 가능한 코드의 레이블 지정된 특정 반복을 나타냅니다. 애플리케이션 버전은 Java WAR 파일 등의 배포 가능한 코드가 포함된 Amazon Simple Storage Service(Amazon S3) 객체를 가리킵니다. 애플리케이션 버전은 애플리케이션의 일부입니다. 애플리케이션에는 많은 버전이 있을 수 있고, 각 애플리케이션 버전은 고유합니다. 실행 중인 환경에서 애플리케이션에 이미 업로드한 애플리케이션 버전을 배포하거나 새 애플리케이션 버전을 업로드하고 즉시 배포할 수 있습니다. 예를 들어 여러 애플리케이션 버전을 업로드하여 그 차이를 테스트할 수 있습니다. ## 환경 *환경*은 애플리케이션 버전을 실행하는 AWS 리소스 모음입니다. 각 환경은 한 번에 하나의 애플리케이션 버전만 실행하지만 여러 환경에서 동일한 애플리케이션 버전 또는 서로 다른 애플리케이션 버전을 동시에 실행할 수 있습니다. 환경을 생성할 때 Elastic Beanstalk는 지정한 애플리케이션 버전을 실행하는 데 필요한 리소스를 AWS 계정에 프로비저닝합니다. ## 환경 계층 Elastic Beanstalk 환경을 시작할 때 먼저 환경 티어를 선택합니다. 환경 티어는 환경에서 실행하는 애플리케이션 유형을 지정하고 Elastic Beanstalk에서 이러한 애플리케이션을 지원하기 위해 프로비저닝하는 리소스를 결정합니다. HTTP 요청을 처리하는 애플리케이션은 [웹 서버 환경 티어](concepts-webserver.md)에서 실행됩니다. Amazon Simple Queue Service(Amazon SQS) 대기열에서 작업을 가져오는 백엔드 환경은 [작업자 환경 티어](concepts-worker.md)에서 실행됩니다. ## 환경 구성 *환경 구성*은 환경 및 연관된 리소스의 작동 방법을 정의하는 파라미터 및 설정의 모음을 식별합니다. 환경의 구성 설정을 업데이트하면 Elastic Beanstalk가 자동으로 기존 리소스에 변경 사항을 적용하거나, 삭제하고 새 리소스를 배포합니다(변경 유형에 따라 다름). ## 저장된 구성 *저장된 구성*은 고유한 환경 구성을 생성하기 위한 시작점으로 사용할 수 있는 템플릿입니다. Elastic Beanstalk 콘솔, EB CLI AWS CLI또는 API를 사용하여 저장된 구성을 생성 및 수정하고 환경에 적용할 수 있습니다. API와는 저장된 구성을 *구성 템플릿*이라고 AWS CLI 합니다. ## 플랫폼 *플랫폼*은 운영 체제(OS), 프로그래밍 언어 런타임, 웹 서버, 애플리케이션 서버 및 Elastic Beanstalk 구성 요소의 조합입니다. 웹 애플리케이션을 설계하고 플랫폼에 맞게 타겟팅합니다. Elastic Beanstalk는 애플리케이션을 구축할 수 있는 플랫폼을 다양하게 지원합니다. 자세한 내용은 [Elastic Beanstalk 플랫폼](concepts-all-platforms.md) 섹션을 참조하십시오. # Elastic Beanstalk 웹 서버 환경 다음 다이어그램에서는 웹 서버 환경 티어의 Elastic Beanstalk 아키텍처 예제 및 해당 환경 티어 유형의 구성 요소가 함께 작동하는 방법을 보여 줍니다. ![\[AWS Elastic Beanstalk 웹 서버 티어 아키텍처 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/images/aeb-architecture2.png) 환경은 애플리케이션의 핵심입니다. 다이어그램에서 환경은 최상위 실선 내에 표시됩니다. 환경을 생성할 때 Elastic Beanstalk는 애플리케이션을 실행하는 데 필요한 리소스를 프로비저닝합니다. 환경에 대해 생성된 AWS 리소스에는 탄력적 로드 밸런서(다이어그램의 ELB), Auto Scaling 그룹 및 하나 이상의 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스가 포함됩니다. 모든 환경에는 로드 밸런서를 가리키는 CNAME(URL)이 있습니다. 환경에는 `myapp.us-west-2.elasticbeanstalk.com`과 같은 URL이 있습니다. 이 URL은 [Amazon Route 53](https://aws.amazon.com/route53/)에서 CNAME 레코드를 사용하여 `abcdef-123456.us-west-2.elb.amazonaws.com`과 같은 Elastic Load Balancing URL로 별칭이 지정됩니다. [Amazon Route 53](https://aws.amazon.com/route53/)는 가용성과 확장성이 뛰어난 DNS(도메인 이름 시스템) 웹 서비스입니다. 이는 인프라에 안전하고 신뢰할 수 있는 라우팅을 제공합니다. DNS 공급자에 등록한 도메인 이름이 요청을 CNAME으로 전달합니다. 로드 밸런서는 Auto Scaling 그룹의 일부인 Amazon EC2 인스턴스의 앞에 위치합니다. Amazon EC2 Auto Scaling은 추가 Amazon EC2 인스턴스를 자동으로 시작하여 애플리케이션의 증가하는 로드를 처리합니다. 애플리케이션의 로드가 감소하면 Amazon EC2 Auto Scaling은 인스턴스를 중지하지만 항상 최소 한 개의 인스턴스는 실행 상태로 둡니다. Amazon EC2 인스턴스에서 실행되는 소프트웨어 스택은 *컨테이너 유형*에 따라 다릅니다. 컨테이너 유형은 해당 환경에서 사용할 인프라 토폴로지와 소프트웨어 스택을 정의합니다. 예를 들어 Apache Tomcat 컨테이너가 있는 Elastic Beanstalk 환경에서는 Amazon Linux 운영 체제, Apache 웹 서버 및 Apache Tomcat 소프트웨어를 사용합니다. 지원되는 컨테이너 유형 목록은 [Elastic Beanstalk 지원되는 플랫폼](concepts.platforms.md)을 참조하십시오. 애플리케이션을 실행하는 각 Amazon EC2 인스턴스는 이러한 컨테이너 유형 중 하나를 사용합니다. 또한 *호스트 관리자(HM)*라고 하는 소프트웨어 구성 요소는 각 Amazon EC2 인스턴스에서 실행됩니다. 호스트 관리자는 다음을 수행합니다. + 애플리케이션 배포 + 콘솔, API, 명령줄을 통해 검색을 위해 이벤트와 측정치 집계 + 인스턴스 수준 이벤트 생성 + 애플리케이션 로그 파일을 모니터링하여 심각한 오류 검출 + 애플리케이션 서버 모니터링 + 인스턴스 구성 요소 패칭 + 애플리케이션의 로그 파일을 교체하고 이를 Amazon S3에 게시 호스트 관리자는 측정치, 오류 및 이벤트, 서버 인스턴스 상태를 보고합니다. 이는 Elastic Beanstalk 콘솔, API 및 CLI를 통해 사용할 수 있습니다. 다이어그램에 나와 있는 Amazon EC2 인스턴스는 한 *보안 그룹*에 속합니다. 보안 그룹은 인스턴스의 방화벽 규칙을 정의합니다. 기본적으로 Elastic Beanstalk는 보안 그룹을 정의하며, 이를 통해 모든 사람이 포트 80(HTTP)을 사용하여 연결할 수 있습니다. 보안 그룹을 두 개 이상 정의할 수 있습니다. 예를 들어 데이터베이스 서버의 보안 그룹을 정의할 수 있습니다. Amazon EC2 보안 그룹 및 Elastic Beanstalk 애플리케이션에 대해 이를 구성하는 방법에 대한 자세한 내용은 [EC2 보안 그룹](using-features.managing.ec2.console.md#using-features.managing.ec2.securitygroups) 단원을 참조하십시오. # Elastic Beanstalk 작업자 환경 AWS 작업자 환경 계층에 대해 생성된 리소스에는 Auto Scaling 그룹, 하나 이상의 Amazon EC2 인스턴스 및 IAM 역할이 포함됩니다. 작업자 환경 티어의 경우 Amazon SQS 대기열이 아직 없으면 Elastic Beanstalk가 이를 만들어 프로비저닝합니다. 작업자 환경을 시작하면 Elastic Beanstalk가 Auto Scaling 그룹의 각 EC2 인스턴스에 선택한 프로그래밍 언어에 필요한 지원 파일과 데몬을 설치합니다. 데몬이 Amazon SQS 대기열로부터의 메시지를 읽습니다. 데몬은 처리를 위해 읽은 각 메시지의 데이터를 작업자 환경에서 실행 중인 웹 애플리케이션으로 보냅니다. 작업자 환경에 인스턴스가 여러 개 있는 경우, 각 인스턴스에 고유의 데몬이 있으나 모두 동일한 Amazon SQS 대기열에서 읽습니다. 다음 다이어그램은 환경 및 AWS 서비스 전반의 다양한 구성 요소와 상호 작용을 보여줍니다. ![\[AWS Elastic Beanstalk 작업자 계층 아키텍처 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/images/aeb-architecture_worker.png) Amazon CloudWatch는 경보 및 상태 모니터링에 사용됩니다. 자세한 내용은 [기본 상태 보고](using-features.healthstatus.md) 섹션을 참조하세요. 작업자 환경 티어의 작동 방법에 대한 자세한 내용은 [Elastic Beanstalk 작업자 환경](using-features-managing-env-tiers.md) 단원을 참조하십시오. # Elastic Beanstalk 애플리케이션을 위한 설계 고려 사항 를 사용하여 배포된 애플리케이션은 AWS 클라우드 리소스에서 AWS Elastic Beanstalk 실행되므로 애플리케이션을 최적화하려면 *확장성*, *보안*, *영구 스토리지*, *내결함*성, *콘텐츠 전송*, *소프트웨어 업데이트 및 패치 적용*, *연결* 등 몇 가지 구성 요소를 염두에 두어야 합니다. 이 주제에서는 각 항목에 대해 별도로 다룹니다. 보안 및 경제성뿐만 아니라 아키텍처와 같은 주제를 다루는 포괄적인 기술 AWS 백서 목록은 [AWS 클라우드 컴퓨팅 백서를 참조하세요](https://aws.amazon.com/whitepapers/). ## 확장성 클라우드 환경과 달리 물리적 하드웨어 환경에서 작동하는 경우 두 가지 방법 중 하나로 확장성에 액세스할 수 있습니다. 수직 배율 조정을 통해 스케일 업하거나 수평 배율을 통해 스케일 아웃할 수 있습니다. 스케일 업 방식을 사용하려면 강력한 하드웨어에 투자해야 하며, 이는 비즈니스의 증가하는 요구를 지원할 수 있습니다. 스케일 아웃 방식을 사용하려면 분산된 투자 모델을 따라야 합니다. 따라서 하드웨어 및 애플리케이션 인수를 더 많이 타겟팅할 수 있고, 데이터 세트가 페더레이션되고, 설계가 서비스 지향적일 수 있습니다. 스케일 업 접근 방법의 경우 상당한 비용이 들 수 있으며, 여전히 수요가 용량을 초과할 우려가 있습니다. 이와 관련하여 일반적으로 스케일 아웃 접근 방식이 더 효과적입니다. 그러나 이를 사용할 때는 정기적으로 수요를 예측하고 해당 수요를 충족하기 위해 인프라를 대량으로 배포할 수 있어야 합니다. 따라서, 이 접근 방법을 택할 경우 종종 미사용 용량이 발생할 수 있으므로 세심한 모니터링이 필요합니다. 클라우드로 마이그레이션하면 클라우드의 탄력성을 활용하여 인프라와 수요를 잘 맞출 수 있습니다. 탄력성은 리소스 확보 및 릴리스를 간소화하는 데 도움이 됩니다. 수요의 변동에 따라 인프라를 빠르게 스케일 인 및 스케일 아웃할 수 있습니다. 이 기능을 사용하려면 환경에 있는 리소스의 지표를 기준으로 확장하거나 축소하도록 Auto Scaling 설정을 구성합니다. 예를 들어 서버 사용률 또는 네트워크 I/O와 같은 지표를 설정할 수 있습니다. 컴퓨터 용량에 대해 Auto Scaling을 사용하여 사용량이 증가할 때마다 자동으로 추가되고 사용량이 떨어질 때마다 제거되도록 할 수 있습니다. 시스템 지표(예: CPU, 메모리, 디스크 I/O 및 네트워크 I/O)를 Amazon CloudWatch에 게시할 수 있습니다. 그런 다음 CloudWatch를 사용하여 Auto Scaling 작업을 트리거하거나 이러한 지표를 기반으로 알림을 전송하도록 경보를 구성할 수 있습니다. Auto Scaling 구성 방법에 대한 설명은 [Elastic Beanstalk 환경 인스턴스의 Auto Scaling](using-features.managing.as.md) 단원을 참조하세요. 또한 모든 Elastic Beanstalk 애플리케이션은 필요에 따라 확장할 수 있고 느슨하게 결합된 내결함성 구성 요소를 사용하며, 가급적 *상태 비저장*으로 설계하는 것이 좋습니다. 확장 가능한 애플리케이션 아키텍처 설계에 대한 자세한 내용은 [https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)를 AWS참조하세요. ## 보안 의 보안 AWS 은 [공동 책임입니다](https://aws.amazon.com/compliance/shared-responsibility-model/). Amazon Web Services는 환경의 물리적 리소스를 보호하고 고객이 클라우드에서 애플리케이션을 안전하게 실행할 수 있도록 합니다. 고객은 Elastic Beanstalk 환경 안팎에서 오는 데이터의 보안과 애플리케이션의 보안을 책임집니다. 애플리케이션과 클라이언트 사이에 흐르는 정보를 보호하기 위해 SSL을 구성합니다. SSL을 구성하기 위해서는 AWS Certificate Manager (ACM)의 무료 인증서가 필요합니다. 이미 외부 인증 기관(CA)의 인증서를 갖고 있다면, ACM을 사용하여 해당 인증서를 가져올 수 있습니다. 그렇지 않으면를 사용하여 가져올 수 있습니다 AWS CLI. [에서 ACM을 사용할 AWS 리전](https://docs.aws.amazon.com/general/latest/gr/acm.html) 수 없는 경우 VeriSign 또는 Entrust와 같은 외부 CA에서 인증서를 구매할 수 있습니다. 그런 다음 AWS Command Line Interface (AWS CLI)를 사용하여 타사 또는 자체 서명된 인증서와 프라이빗 키를 AWS Identity and Access Management (IAM)에 업로드합니다. 이 인증서의 퍼블릭 키가 귀하의 서버에 대한 인증을 브라우저에 요청합니다. 또한 이는 데이터를 양방향으로 암호화하는 공유 세션 키를 만드는 기반 역할을 하기도 합니다. SSL 인증서를 생성 및 업로드하고 이를 환경에 할당하는 방법은 [Elastic Beanstalk 환경에 사용할 HTTPS 구성](configuring-https.md) 단원을 참조하세요. 환경에 대해 SSL 인증서를 구성하면 클라이언트와 환경의 Elastic Load Balancing 로드 밸런서 간에 데이터가 암호화됩니다. 기본적으로 암호화는 로드 밸런서에서 종료되고, 로드 밸런서와 Amazon EC2 인스턴스 간의 트래픽은 암호화되지 않습니다. ## 영구 스토리지 Elastic Beanstalk 애플리케이션은 영구 로컬 스토리지가 없는 Amazon EC2 인스턴스에서 실행됩니다. Amazon EC2 인스턴스가 종료되면 로컬 파일 시스템은 저장되지 않습니다. 새 Amazon EC2 인스턴스는 기본 파일 시스템으로 시작합니다. 영구 데이터 원본에 데이터를 저장하도록 애플리케이션을 구성하는 것이 좋습니다. AWS 는 애플리케이션에 사용할 수 있는 다양한 영구 스토리지 서비스를 제공합니다. 다음 표에는 해당 항목이 나열됩니다. | 스토리지 서비스 | 서비스 설명서 | Elastic Beanstalk 통합 | | --- | --- | --- | | [Amazon S3](https://aws.amazon.com/s3/) | [Amazon Simple Storage Service 설명서](https://aws.amazon.com/documentation/s3/) | [Amazon S3에서 Elastic Beanstalk 사용](AWSHowTo.S3.md) | | [Amazon Elastic File System](https://aws.amazon.com/efs/) | [Amazon Elastic File System 설명서](https://aws.amazon.com/documentation/efs/) | [Amazon Elastic File System에서 Elastic Beanstalk 사용](services-efs.md) | | [Amazon Elastic Block Store](https://aws.amazon.com/ebs/) | [Amazon Elastic Block Store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) [기능 설명서: Elastic Block Store](https://aws.amazon.com/articles/1667) | | | [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) | [Amazon DynamoDB 설명서](https://aws.amazon.com/documentation/dynamodb/) | [Amazon DynamoDB에서 Elastic Beanstalk 사용](AWSHowTo.dynamoDB.md) | | [Amazon Relational Database Service(RDS)](https://aws.amazon.com/rds/) | [Amazon Relational Database Service 설명서](https://aws.amazon.com/documentation/rds/) | [Amazon RDS와 함께 Elastic Beanstalk 사용](AWSHowTo.RDS.md) | **참고** Elastic Beanstalk는 *웹앱* 사용자를 생성하여 EC2 인스턴스에서 애플리케이션 디렉터리의 소유자로 설정할 수 있습니다. 또는 [2022년 2월 3일](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2022-02-03-linux.html#release-2022-02-03-linux.changes) 이후에 출시되는 Amazon Linux 2 플랫폼 버전의 경우, Elastic Beanstalk는 *웹앱* 사용자에게 새로운 환경에 대한 uid(사용자 ID) 및 gid(그룹 ID) 값 900을 할당합니다. 플랫폼 버전 업데이트 이후 기존 환경에서도 동일하게 작동합니다. 이 접근 방식을 통해 *웹앱* 사용자는 영구 파일 시스템 스토리지에 대한 일관된 액세스 허가를 유지할 수 있습니다. 드물게 발생하는 다른 사용자나 프로세스가 이미 900을 사용하고 있는 경우, 운영 체제는 *웹앱* 사용자 uid 및 gid의 기본값을 다른 값으로 지정합니다. EC2 인스턴스의 리눅스 명령 **id webapp**을 실행하여*웹앱* 사용자에 할당된 uid 및 gid 값을 확인합니다. ## 내결함성 경험상 클라우드의 아키텍처를 설계할 때 비관주의자가 되어야 합니다. 제공되는 탄력성을 활용하십시오. 항상 장애 시 자동 복구할 수 있도록 설계, 구현 및 배포합니다. Amazon EC2 인스턴스 및 Amazon RDS에 여러 가용 영역을 사용합니다. 가용 영역은 개념적으로 논리적 데이터 센터와 같습니다. Amazon CloudWatch를 사용하여 Elastic Beanstalk 애플리케이션의 상태를 보다 쉽게 파악하고 하드웨어 장애나 성능 저하 시 적절한 조치를 취합니다. 비정상 Amazon EC2 인스턴스를 새 인스턴스로 바꾸도록 Auto Scaling 설정을 구성하여 Amazon EC2 인스턴스를 일정한 크기로 유지합니다. Amazon RDS를 사용하는 경우 Amazon RDS가 자동 백업을 수행할 수 있도록 백업의 보존 기간을 설정합니다. ## 콘텐츠 전송 사용자가 웹 사이트에 연결하면 요청이 여러 개별 네트워크를 통해 라우팅될 수 있습니다. 따라서 사용자는 긴 지연 시간으로 인해 성능 저하를 경험할 수 있습니다. Amazon CloudFront는 전 세계 엣지 로케이션의 네트워크 전체에 걸쳐 이미지, 비디오와 같은 웹 콘텐츠를 배포하여 지연 시간 문제를 개선할 수 있습니다. 사용자의 요청이 가장 가까운 엣지 로케이션으로 라우팅되므로 콘텐츠 전송 성능이 뛰어납니다. CloudFront는 최종 원본 파일을 영구적으로 저장하는 Amazon S3에서 원활하게 작동합니다. CloudFront에 대한 자세한 내용은 [Amazon CloudFront 개발자 가이드](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)를 참조하세요. ## 소프트웨어 업데이트 및 패치 적용 AWS Elastic Beanstalk 는 [플랫폼 업데이트를](using-features.platform.upgrade.md) 정기적으로 릴리스하여 수정 사항, 소프트웨어 업데이트 및 새로운 기능을 제공합니다. Elastic Beanstalk는 플랫폼 업데이트를 처리할 수 있는 몇 가지 옵션을 제공합니다. [관리형 플랫폼 업데이트](environment-platform-update-managed.md)는 애플리케이션을 계속 서비스하면서 예약된 유지 관리 기간 동안 환경을 최신 플랫폼 버전으로 자동 업그레이드합니다. 2019년 11월 25일 이후 Elastic Beanstalk 콘솔을 사용하여 생성한 환경에서는 가능할 때마다 관리형 업데이트가 기본적으로 활성화됩니다. Elastic Beanstalk 콘솔 또는 EB CLI를 사용하여 수동으로 업데이트를 시작할 수도 있습니다. ## 연결 배포를 완료하려면 Elastic Beanstalk를 환경의 인스턴스에 연결할 수 있어야 합니다. Amazon VPC 내부에 Elastic Beanstalk 애플리케이션을 배포하는 경우, 연결성을 지원하는 데 필요한 구성은 생성하는 Amazon VPC 환경의 유형에 따라 다릅니다. + 단일 인스턴스 환경의 경우 추가 구성이 필요하지 않습니다. 이러한 환경에서 Elastic Beanstalk가 각 Amazon EC2 인스턴스에 퍼블릭 탄력적 IP 주소를 할당하여 인스턴스가 인터넷과 직접 통신할 수 있기 때문입니다. + 퍼블릭 서브넷과 프라이빗 서브넷이 모두 있는 Amazon VPC의 로드 밸런싱 수행 및 확장 가능 환경의 경우 다음을 수행해야 합니다. + 인터넷에서 Amazon EC2 인스턴스로 인바운드 트래픽을 라우팅할 수 있도록 퍼블릭 서브넷에 로드 밸런서를 만듭니다. + 프라이빗 서브넷의 Amazon EC2 인스턴스에서 인터넷으로 아웃바운드 트래픽을 라우팅할 수 있도록 네트워크 주소 변환(NAT) 디바이스를 만듭니다. + 프라이빗 서브넷 내부에 Amazon EC2 인스턴스의 인바운드 및 아웃바운드 라우팅 규칙을 만듭니다. + NAT 인스턴스를 사용하는 경우, 인터넷 통신을 사용하도록 NAT 인스턴스와 Amazon EC2 인스턴스의 보안 그룹을 구성합니다. + 퍼블릭 서브넷이 한 개 있는 Amazon VPC의 로드 밸런싱 수행 및 확장 가능 환경의 경우 추가 구성이 필요하지 않습니다. 이는 이러한 환경에서 Amazon EC2 인스턴스가 퍼블릭 IP 주소로 구성되어 인스턴스가 인터넷과 통신할 수 있도록 하기 때문입니다. Amazon VPC와 함께 Elastic Beanstalk 사용에 대한 자세한 내용은 [Amazon VPC에서 Elastic Beanstalk 사용](vpc.md) 단원을 참조하십시오.