Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
MongoDB Branding Shape
Click here >
Docs Menu

Atlas 네트워크 보안을 위한 지침

Atlas 데이터베이스 배포를 위한 다음과 같은 보안 네트워크 구성 기본값을 제공합니다.

  • 필수 TLS 연결 암호화

  • 하나 이상의 전용 클러스터가 있는 모든 프로젝트에 대한VPC

  • IP 액세스 목록을 사용하고 명시적으로 선언한 소스에서만 데이터베이스 연결을 허용하는 인증

고유한 보안 요구 사항과 기본 설정을 충족하도록 이러한 보호 기능을 추가로 구성할 수 있습니다.

이 페이지의 권장 사항을 사용하여 클러스터의 네트워크 보안 구성을 계획하세요.

참고

MongoDB Atlas 공동 책임 모델은 안전하고 복원력이 뛰어난 데이터 환경을 유지 관리하는 데 있어 MongoDB 와 MongoDB 고객의 보완 의무를 정의합니다. 이 프레임워크 에서 MongoDB 기본 플랫폼의 보안 및 운영 무결성을 관리하고 고객은 특정 배포의 구성, 관리 및 데이터 정책을 책임집니다. 보안 및 운영 우수성에 대한 소유권에 대한 자세한 분석은 공유 책임 모델을 참조하세요.

Atlas 데이터베이스에 대한 모든 연결에 TLS 암호화 시행합니다.

M110+ 전용 클러스터 사용을 권장합니다. 모든 Atlas 프로젝트에서 하나 이상의 M10+ 전용 클러스터가 있으면 각 클러스터는 고유의 전용 클러스터를 받기 때문입니다.

  • AWS 또는 Google Cloud의 VPC

  • AzureVNet.

Atlas 모든 전용 클러스터를 이 VPC 또는 VNet 내에 배포합니다.

기본적으로 클러스터에 대한 모든 액세스는 차단됩니다. 다음 방법 중 하나로 인바운드 연결을 명시적으로 허용해야 합니다.

  • Atlas IP 액세스 목록 에 자동으로 추가하는 비공개 엔드포인트 추가합니다. 다른 액세스 자동으로 추가되지 않습니다.

  • VPC 또는 VNet 피어링을 사용하여 비공개 IP 주소를 추가합니다.

  • IP 액세스 목록 에 공용 IP 주소를 추가합니다.

보안을 강화하기 위해 여러 방법을 함께 사용할 수도 있습니다.

Atlas 데이터베이스에 대한 연결에 TLS 암호화 강제로 적용합니다. TLS 1.2 이 기본값 프로토콜 입니다. 자세한 학습 은 추가 설정 구성Set Minimum TLS Protocol Version 섹션을 참조하세요.

Atlas 관리자로서 다음 작업을 수행할 수 있습니다.

IP 액세스 목록을 구성하여 어떤 IP 주소가 데이터베이스에 인증 시도를 할 수 있는지 제한합니다.

IP 액세스 목록에 추가한 IP 주소 및 CIDR 차단 IP 범위에서만 액세스 허용합니다. 개별 /32 주소 와 같이 가능한 한 가장 작은 네트워크 세그먼트에 대한 액세스 허용하는 것이 좋습니다.

애플리케이션 서버 및 기타 클라이언트의 IP 주소가 IP 액세스 목록에 포함되어 있지 않은 경우 Atlas 클러스터에 대한 액세스를 차단할 수 있습니다.

사용자가 지정한 기간이 지나면 자동으로 만료되는 임시 액세스 목록의 항목을 설정할 수 있습니다.

클라이언트 애플리케이션 서버에서 Atlas 로 연결하고 아웃바운드 네트워크 연결을 차단하는 방화벽 통과할 때는 애플리케이션이 Atlas 호스트의 TCP 트래픽에 아웃바운드 연결을 할 수 있도록 방화벽 도 구성해야 합니다. 이렇게 하면 애플리케이션에 클러스터에 대한 액세스 부여됩니다.

수직 확장, 토폴로지 변경 또는 유지 관리 이벤트와 같은 클러스터 변경 대부분의 경우에 Atlas 클러스터의 공용 IP는 동일하게 유지됩니다. 그러나 복제본 세트에서 샤딩된 클러스터로의 변환, 샤드 추가 또는 지역 변경과 같은 특정 토폴로지 변경은 새로운 IP 주소를 사용해야 합니다.

복제본 세트 에서 샤딩된 클러스터 로 변환하는 경우 애플리케이션 클라이언트를 다시 연결하지 못하면 애플리케이션 데이터 중단이 발생할 수 있습니다.DNS 시드 목록 연결 문자열 사용하는 경우 애플리케이션 은 샤딩된 클러스터 의 에 자동으로 연결됩니다. 표준 연결 문자열 사용하는 경우 새 클러스터 토폴로지 를 반영하도록 연결 문자열 업데이트 해야 합니다.

새 샤드를 추가하는 경우 애플리케이션 클라이언트를 다시 연결하지 못하면 애플리케이션 데이터 중단이 발생할 수 있습니다.

비공개 엔드포인트는 Atlas 상호 연결을 시작하는 것을 허용하지 않고 사용자가 직접 관리 VPC 에서 Atlas VPC 로의 단방향 연결을 용이하게 합니다. 이를 통해 네트워크 신뢰 경계를 확장하지 않고도 Atlas 에 대한 보안 연결을 사용할 수 있습니다. 다음과 같은 비공개 엔드포인트 사용할 수 있습니다.

" MongoDB Atlas 비공개 엔드포인트 작동 방식을 나타내는 이미지입니다."

네트워크 피어링을 통해 자체 VPC를 Atlas VPC와 연결하여 트래픽을 비공개로 라우팅하고 데이터 흐름을 공용 인터넷에서 격리할 수 있습니다. Atlas는 VPC를 일대일로 Atlas 프로젝트에 매핑합니다.

VPC 연결을 통해 수행되는 대부분의 작업은 애플리케이션 환경에서 시작되므로 Atlas 피어 VPC에 아웃바운드 액세스 요청을 할 필요성을 최소화합니다. 그러나 LDAP 인증 사용하도록 Atlas 구성하는 경우, LDAP 프로토콜 통해 피어 VPC 의 인증 엔드포인트에 아웃바운드 연결하려면 Atlas 활성화 해야 합니다. LDAP 인증 Atlas 에서 더 이상 사용되지 8.0 않습니다. 대신 Workforce Identity FederationWorkload Identity Federation 을 사용하는 것이 좋습니다.

첫 번째 클러스터 배포 전에 VPC 피어링 마법사를 사용하여 Atlas CIDR 차단 선택할 수 있습니다. Atlas VPC CIDR 차단 피어링하려는 VPC 의 CIDR 차단 과 겹치지 않아야 합니다. Atlas CIDR 차단 기반으로 VPC 당 MongoDB 인스턴스 수를 제한합니다. 예시 들어 CIDR 차단 있는 프로젝트 /24 27 3에 해당하는 노드 복제본 세트로 제한됩니다.

" MongoDB Atlas VPC/VNet 피어링의 작동 방식을 나타내는 이미지입니다."

단일 리전 배포서버에만 적용되는 권장사항

단일 리전 배포에는 Atlas 네트워크 보안에 대한 특별한 고려 사항이 없습니다.

멀티 리전 또는 여러 클라우드 공급자에 걸친 배포서버에만 적용되는 권장사항

비공개 엔드포인트로 보호되는 멀티 리전 배포에는 다음과 같은 고유한 고려 사항이 있습니다.

  • 글로벌 비공개 엔드포인트 의 경우, Atlas 모든 Atlas cluster 노드를 가리키는 SRV 기록 자동으로 생성합니다. MongoDB 운전자가 애플리케이션의 각 SRV 기록에 연결을 시도합니다. 이를 통해 운전자 DNS 복제 기다리지 않고 드라이버의 연결 문자열 업데이트 필요 없이 페일오버 이벤트 처리하다 할 수 있습니다.

  • Atlas cluster 의 모든 노드에 대한 자동 SRV 기록 생성을 용이하게 하려면 애플리케이션 VPC 간에 VPC피어링 연결을 설정하고 PrivateLink 또는 이와 동등한 기능을 사용하여 애플리케이션 VPC 를 MongoDB VPC 에 연결해야 합니다.

  • Atlas 클러스터가 배포된 모든 리전에서 비공개 엔드포인트를 활성화해야 합니다.

  • Google Cloud Private Service Connect는 리전별로 다릅니다. 그러나 글로벌 액세스를 구성하여 다른 리전의 비공개 엔드포인트에 액세스할 수 있습니다.

    자세한 내용은 멀티 리전 지원을 참조하세요.

다음 권장사항은 모든 배포서버 패러다임에 적용됩니다.

네트워크 신뢰 경계 확장을 제한하기 위해 모든 신규 스테이징 및 프로덕션 프로젝트에 비공개 엔드포인트를 설정할 것이 좋습니다.

일반적으로 모든 Atlas 프로젝트에 비공개 엔드포인트를 사용하는 것을 권장합니다. 이러한 접근 방식은 가장 세분화된 보안을 제공하고 클라우드 네트워크가 확장됨에 따라 IP 액세스 목록 및 대규모 IP 주소 블록 관리에 따르는 관리 부담을 덜어주기 때문입니다. 각 엔드포인트에 비용이 부과됩니다. 따라서 낮은 환경에서는 비공개 엔드포인트가 필요하지 않을 수 있지만, 높은 환경에서는 네트워크 신뢰 경계의 확장을 제한하기 위해 비공개 엔드포인트를 활용해야 합니다.

온프레미스와 클라우드 배포 조합 때문에 애플리케이션이 배포된 VPC 또는 VNet이 서로 피어링할 수 없는 경우에는 리전 비공개 엔드포인트를 고려하는 것이 좋습니다

리전 비공개 엔드포인트를 사용하면 다음을 수행할 수 있습니다.

  • 단일 비공개 엔드포인트를 여러 VNet 또는 VPC에 직접 피어링하지 않고 연결합니다.

  • 리전 내 하나 이상의 서비스에 장애가 발생하는 부분 리전 장애를 완화할 수 있습니다.

리전 엔드포인트와 네트워크를 연결하려면 다음을 수행해야 합니다.

  • 클러스터와 애플리케이션 간의 성공적인 연결 및 작동을 확인하기 위해 정기적이고 철저한 상태 점검을 수행할 수 있습니다. 클러스터와의 연결 상태를 빠르게 확인하려면 db.runCommand("ping") 명령어로 핑을 보내거나 rs.conf()를 실행하여 클러스터의 각 노드에 대한 세부 정보를 얻을 수 있습니다.

  • 각 리전에 대해 고유한 연결 문자열을 사용해야 합니다.

  • Atlas 로의 리전 간 라우팅을 사용하여 Atlas VPC 연결이 끊어지는 경우에도 가용성을 유지합니다.

제한 사항 및 고려 사항을 포함하여 Atlas 의 비공개 엔드포인트 에 대해 자세히 학습 Atlas 의 비공개 엔드포인트에 대해 알아보기를 참조하세요. 클러스터의 비공개 엔드포인트 설정하다 하는 방법을 학습 전용 클러스터에 대한 비공개 엔드포인트 설정을 참조하세요.

  • Amazon Web Services: Atlas 에 연결해야 하는 모든 자체 관리형 VPC 에서 VPC 피어링을 권장합니다. 글로벌 비공개 엔드포인트 활용하세요.

  • Azure: Atlas 에 연결해야 하는 모든 자체 관리형 VNet에서 VNet 피어링을 권장합니다. 글로벌 비공개 엔드포인트 활용하세요.

  • GCP: GlobalConnect를 사용할 때는 자체 관리형 VPC 전체에서 피어링 필요하지 않습니다. 모든 Atlas 리전은 각 리전 의 자체 관리 VPC 대한 비공개 엔드포인트 와 네트워크로 연결되어야 합니다.

Atlas 서비스는 1024부터 시작하는 포트의 GCP Private Service Connect 엔드포인트를 통해 액세스할 수 있습니다. 포트는 클러스터 변경을 포함하되 이에 국한되지 않는 특정 상황에서 변경될 수 있습니다.

  • 멀티 리전 클러스터를 배포하려면 모든 지역에서 GCP Private Service Connect가 활성화되어 있어야 합니다. 대상 리전 중 일부에서만 GCP Private Service Connect가 활성화되어 있는 경우 오류가 발생합니다.

  • 드라이버가 멀티 리전 클러스터 내 모든 노드에 연결할 수 있도록 내부적으로 저장되는 연결 문자열의 수를 관리 가능한 수준으로 유지해야 합니다. 이는 드라이버가 클러스터 내에서 동적으로 할당되는 프라이머리 노드에 연결되어 데이터베이스의 모든 작업을 수행할 수 있도록 보장하기 위함입니다. 이를 위해서는 다음 방법 중 하나만 선택할 수 있습니다.

    • 둘 이상의 리전 에 노드를 배포하고 리전당 하나 리전 비공개 엔드포인트를 갖습니다.

    • 한 리전 에 여러 비공개 엔드포인트 가 있고 다른 비공개 엔드포인트 는 없습니다.

      중요

      이 제한은 모든 cloud 제공자에 적용됩니다. 예시 들어, GCP 의 단일 리전 에서 둘 이상의 비공개 엔드포인트를 생성하는 경우, Amazon Web Services 또는 다른 GCP 리전 에서 비공개 엔드포인트 생성할 수 없습니다.

    더 자세한 내용은 샤딩된 클러스터에서만 리전화된 엔드포인트를 사용할 수 있는 이유를 참조하세요.

    샤딩된 클러스터에서는 노드 간 트래픽이 기본적으로 클러스터 내 모든 노드에 연결된 mongos 프로세스를 통해 라우팅됩니다. 따라서 특정 리전에서 원하는 만큼의 비공개 엔드포인트를 생성할 수 있습니다. 자세한 내용은 멀티 리전 샤딩 클러스터를 위한 리전화된 비공개 엔드포인트(선택 사항)를 참조하세요.

  • 여러 리전에 걸쳐 GCP Private Service Connect를 사용하는 Atlas 프로젝트를 배포 때 최대 40 개의 노드를 가질 수 있습니다. 이 합계에는 다음 인스턴스가 제외됩니다.

    • 서로 통신하는GCP 리전

    • 무료 클러스터 또는 공유 크러스터

  • 주소 지정이 가능한 대상에는 다음이 포함됩니다.

    • 복제본 세트 배포서버 의 각 인스턴스 ( 샤딩된 클러스터 제외).

    • 샤딩된 클러스터 배포서버 의 각 인스턴스 .

    • 프로젝트에 있는 모든 전용 클러스터의 Atlas 인스턴스에 대한 각 BI Connector.

  • GCP Private Service Connect는 가상 머신당 최대 1024 개의 발신 연결을 지원합니다. 따라서 단일 GCP 가상 머신에서 Atlas cluster 로의 연결은 1024 개를 초과할 수 없습니다.

    자세한 학습 은 GCP cloud NAT 문서를 참조하세요.

  • GCP Private Service Connect는 리전별로 다릅니다. 그러나 다른 리전 에서 비공개 엔드포인트 에 액세스 글로벌 액세스 구성할 수 있습니다.

    자세한 내용은 멀티 리전 지원을 참조하세요.

CI/CD 파이프라인 또는 오케스트레이션 시스템과 같은 신뢰할 수 있는 IP 주소에서만 액세스 허용하도록 API 키 및 프로그래밍 방식 액세스 에 대한 IP 액세스 목록 구성하는 것이 좋습니다. 이러한 IP 액세스 목록은 서비스 계정을 프로비저닝 할 때 Atlas 컨트롤 플레인에서 설정하다 되며 클러스터 연결을 위해 Atlas 프로젝트 데이터 플레인에서 설정하다 수 있는 IP 액세스 목록과는 별개입니다.

IP 액세스 목록 구성할 때는 다음을 수행하는 것이 좋습니다.

  • 팀 구성원이 임시 작업 위치에서 환경에 액세스해야 하거나 프로덕션 중단 상황을 해결하기 위해 사람이 프로덕션에 액세스해야 하는 긴급 상황에서는 임시 액세스 목록 항목을 사용합니다. 이러한 상황에 대비하기 위해 임시 액세스를 빠르게 추가할 수 있는 자동화 스크립트를 작성할 것이 좋습니다.

  • 가능한 가장 작은 네트워크 세그먼트를 포함하도록 IP 액세스 목록 항목을 정의합니다. 이 작업을 수행하려면 가능한 경우 개별 IP 주소를 사용하고 대규모 CIDR 블록을 피합니다.

VPC 또는 VNet 피어링을 구성하는 경우 다음을 권장합니다.

  • 엄격한 네트워크 신뢰 경계를 유지하려면 보안 그룹 및 네트워크 ACL 을 구성하여 Atlas 측 VPC 에서 애플리케이션 VPC 내부의 시스템에 대한 인바운드 액세스를 방지합니다.

  • 민감한 애플리케이션 인프라와 Atlas VPC 사이에서 중개자 역할을 하는 새로운 VPC를 생성합니다. VPC는 비전이적이므로 Atlas에 액세스가 필요한 애플리케이션 구성 요소만 노출할 수 있습니다.

다음 예제에서는 IP 액세스 목록, VPC 피어링, 비공개 엔드포인트를 사용하여 애플리케이션 환경과 Atlas cluster 간의 연결을 구성합니다.

이러한 예시는 다음을 포함한 다른 권장 구성에도 적용됩니다.

  • 개발/테스트 환경을 위해 클러스터 계층을 M10으로 설정합니다. 애플리케이션 크기에 맞는 권장 클러스터 계층을 알아보려면 클러스터 크기 가이드를 참조하세요.

  • 단일 리전, 3-노드 복제본 세트/샤드 배포 토폴로지

이 예제에서는 Amazon Web Services, Azure 및 Google Cloud Platform 서로 바꿔서 사용합니다. 이 세 가지 cloud 제공자 중 하나를 사용할 수 있지만 cloud 제공자 와 일치하도록 리전 이름을 변경해야 합니다. cloud 제공자 및 해당 리전에 대해 학습 클라우드 제공자를 참조하세요.

  • 중간 규모 애플리케이션을 위해 클러스터 계층을 M30으로 설정합니다. 애플리케이션 크기에 맞는 권장 클러스터 계층을 알아보려면 클러스터 크기 가이드를 참조하세요.

  • 단일 리전, 3-노드 복제본 세트/샤드 배포 토폴로지

이 예제에서는 Amazon Web Services, Azure 및 Google Cloud Platform 서로 바꿔서 사용합니다. 이 세 가지 cloud 제공자 중 하나를 사용할 수 있지만 cloud 제공자 와 일치하도록 리전 이름을 변경해야 합니다. cloud 제공자 및 해당 리전에 대해 학습 클라우드 제공자를 참조하세요.

참고

Atlas CLI로 연결을 구성하기 전에 다음을 수행해야 합니다.

허용하려는 각 연결에 대해 다음 명령을 실행하세요. 항목을 적절한 옵션과 실제 값으로 변경하세요.

atlas accessList create 192.0.2.15 --type ipAddress --projectId 5e2211c17a3e5a48f5497de3 --comment "IP address for app server 2" --output json

이 예시 에 대한 자세한 구성 옵션 및 자세한 내용은 Atlas accessLists 생성을 참조하세요.

Amazon Web Services, GCPAzure 사용하여 IP 액세스 목록 항목을 생성하는 방법에 대한 자세한 내용은 전용 클러스터에 대한 비공개 엔드포인트 설정을 참조하세요.

Atlas VPC 에 피어링하려는 각 VPC 에 대해 다음 코드를 실행합니다. awsazure 또는 gcp 로 적절히 바꾸고 옵션과 값을 VPC 또는 VNet에 적합한 것으로 변경합니다.

atlas networking peering create aws --accountId 854333054055 --atlasCidrBlock 192.168.0.0/24 --region us-east-1 --routeTableCidrBlock 10.0.0.0/24 --vpcId vpc-078ac381aa90e1e63

이 예시 에 대한 자세한 구성 옵션 및 정보는 다음을 참조하세요.

생성하려는 각 비공개 엔드포인트에 대해 다음 명령을 실행합니다. aws 을(를) azure 또는 gcp(으)로 적절히 바꾸고 옵션과 값을 VPC 또는 VNet에 적합한 것으로 변경합니다.

atlas privateEndpoints aws create --region us-east-1 --projectId 5e2211c17a3e5a48f5497de3 --output json

이 예시 에 대한 자세한 구성 옵션 및 정보는 다음을 참조하세요.

참고

Terraform으로 리소스를 생성하기 전에 다음을 수행해야 합니다.

  • 결제 조직을 생성하고 해당 결제 조직에 대한 API 키를 생성합니다. 터미널에서 다음 명령을 실행하여 API 키를 환경 변수로 저장하세요.

    export MONGODB_ATLAS_PUBLIC_KEY="<insert your public key here>"
    export MONGODB_ATLAS_PRIVATE_KEY="<insert your private key here>"

We also suggest 환경에 맞는 작업 공간을 만드는 것이 좋습니다.

IP 액세스 목록 에 항목을 추가하려면 다음 파일 만들어 액세스 부여하려는 프로젝트 의 디렉토리 에 배치합니다. 값을 사용하도록 ID와 이름을 변경합니다.

# Add an entry to your IP Access List
resource "mongodbatlas_access_list_api_key" "address_1" {
org_id = "<org-id>"
ip_address = "2.3.4.5"
api_key_id = "a29120e123cd"
}

파일을 생성한 후 프로젝트 디렉토리로 이동하여 다음 명령을 실행하여 Terraform을 초기화합니다.

terraform init

Terraform 계획을 보려면 다음 명령을 실행합니다.

terraform plan

다음 명령을 실행하여 프로젝트 의 IP 액세스 목록 에 항목을 하나 추가합니다. 이 명령은 파일 과 MongoDB & HashiCorp Terraform 을 사용하여 항목을 추가합니다.

terraform apply

메시지가 표시되면 yes를 입력하고 Enter 키를 눌러 구성을 적용합니다.

애플리케이션 VPC 와 Atlas VPC 간에 피어링 연결을 생성하려면 다음 파일 생성하여 액세스 부여하려는 프로젝트의 디렉토리에 배치합니다. 값을 사용하도록 ID와 이름을 변경합니다.

# Define your application VPC
resource "aws_default_vpc" "default" {
tags = {
Name = "Default VPC"
}
}
# Create the peering connection request
resource "mongodbatlas_network_peering" "mongo_peer" {
accepter_region_name = "us-east-2"
project_id = local.project_id
container_id = one(values(mongodbatlas_advanced_cluster.test.container_id))
provider_name = "AWS"
route_table_cidr_block = "172.31.0.0/16"
vpc_id = aws_default_vpc.default.id
aws_account_id = local.AWS_ACCOUNT_ID
}
# Accept the connection
resource "aws_vpc_peering_connection_accepter" "aws_peer" {
vpc_peering_connection_id = mongodbatlas_network_peering.mongo_peer.connection_id
auto_accept = true
tags = {
Side = "Accepter"
}
}

파일 생성한 후 프로젝트 디렉토리 로 이동하여 다음 명령을 실행 Terraform을 초기화합니다.

terraform init

Terraform 계획을 보려면 다음 명령을 실행합니다.

terraform plan

다음 명령을 실행하여 애플리케이션에서 프로젝트로 VPC 피어링 연결을 추가합니다. 이 명령은 파일과 MongoDB & HashiCorp Terraform 을 사용하여 항목을 추가합니다.

terraform apply

메시지가 표시되면 yes를 입력하고 Enter 키를 눌러 구성을 적용합니다.

애플리케이션 VPC 에서 Atlas VPC 로 PrivateLink를 생성하려면 다음 클라우드 제공자별 모듈 중 하나를 사용하세요. 다음 파일 생성하여 연결하려는 프로젝트 의 디렉토리 에 배치합니다. 값을 사용하도록 ID와 이름을 변경합니다.

For Amazon Web Services:

module "atlas_aws" {
source = "terraform-mongodbatlas-modules/atlas-aws/mongodbatlas"
version = "~> 0.3"
project_id = "<project-id>"
privatelink_endpoints = [
{
region = "<aws-region>"
subnet_ids = ["<subnet-id>"]
}
]
}

Azure의 경우, privatelink_endpoints 속성과 함께 atlas-azure 모듈 을(를) 사용합니다. 전체 예시는 atlas-azure privatelink 예시를 참조하세요.

파일 생성한 후 프로젝트 디렉토리 로 이동하여 다음 명령을 실행 Terraform을 초기화합니다.

terraform init

Terraform 계획을 보려면 다음 명령을 실행합니다.

terraform plan

애플리케이션에서 프로젝트로 PrivateLink 엔드포인트를 추가하려면 다음 명령을 실행합니다. 명령은 파일과 MongoDB & HashiCorp Terraform을 사용하여 항목을 추가합니다.

terraform apply

메시지가 표시되면 yes를 입력하고 Enter 키를 눌러 구성을 적용합니다.