기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 다중 계정 아키텍처를 위한 네트워크 연결
## VPC 연결
많은 회사가 Amazon Virtual Private Cloud(VPC)에서 VPC 피어링을 사용하여 개발 및 프로덕션 VPC를 연결합니다. VPC 피어링 연결을 사용하면 프라이빗 IP 주소 지정을 사용하여 두 VPC 간에 트래픽을 라우팅할 수 있습니다. 연결된 VPCs는 서로 다른 AWS 계정 및 서로 다른에 있을 수 있습니다 AWS 리전. 자세한 내용은 [VPC 피어링이란](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)(Amazon VPC 설명서)을 참조하세요. 회사가 성장하고 VPC 수가 증가함에 따라 모든 VPC 간의 피어링 연결을 유지하는 것이 유지 관리 부담이 될 수 있습니다. 또한 VPC당 최대 VPC 피어링 연결 수에 따른 제한을 받을 수도 있습니다. 자세한 내용은 [VPC 피어링 연결 할당량](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-peering)(Amazon VPC 설명서)을 참조하세요.
여러에서 비프로덕션 데이터를 호스팅하는 개발, 테스트 및 스테이징 환경이 여러 개 있는 경우 모든 VPCs 간에 네트워크 연결을 제공하지만 프로덕션 환경에 대한 액세스는 허용하지 않는 AWS 계정것이 좋습니다. [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)를 사용하여 여러 계정에 걸쳐 여러 VPC를 연결할 수 있습니다. 개발 VPC가 중앙 집중식 라우터 역할을 하는 전송 게이트웨이를 통해 프로덕션 VPC와 통신하지 못하도록 라우팅 테이블을 분리할 수 있습니다. 자세한 내용은 [중앙 집중식 라우터](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-centralized-router.html)(Transit Gateway 설명서)를 참조하세요.
Transit Gateway는 다른 AWS 계정 또는 AWS 리전에 있는 Transit Gateway를 포함한 다른 Transit Gateway와의 피어링을 지원합니다. Transit Gateway는 완전관리형 고가용성 서비스이므로 각 리전에 대해 하나의 Transit Gateway만 프로비저닝하면 됩니다.
자세한 내용과 자세한 네트워크 아키텍처는 [확장 가능하고 안전한 다중 VPC AWS 네트워크 인프라 구축](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html)(AWS 백서)을 참조하세요.
## 애플리케이션 연결
동일한 환경(예: 프로덕션)의 다른 AWS 계정 에 있는 애플리케이션 간에 통신을 설정해야 하는 경우 다음 옵션 중 하나를 사용할 수 있습니다.
+ 여러 IP 주소 및 포트에 대한 광범위한 액세스를 열려는 경우 [VPC 피어링](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) 또는 [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)가 네트워크 수준에서 연결을 제공할 수 있습니다.
+ [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)는 VPC의 프라이빗 서브넷에 엔드포인트를 생성하고 이러한 엔드포인트는 [Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html)에 DNS 항목으로 등록됩니다. 애플리케이션은 DNS를 사용하여 VPC의 NAT 게이트웨이 또는 인터넷 게이트웨이 없이도 엔드포인트를 확인하고 등록된 서비스에 연결할 수 있습니다.
+ [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-service-network.html)는 여러 계정과 VPC에서 애플리케이션과 같은 서비스를 연결하고 서비스 네트워크로 수집합니다. 서비스 네트워크와 연결된 VPC의 클라이언트는 동일한 계정에 있는지 여부에 관계없이 서비스 네트워크와 연결된 다른 모든 서비스로 요청을 전송할 수 있습니다. VPC Lattice는 AWS Resource Access Manager (AWS RAM)와 통합되어 리소스를 다른 계정과 공유하거나를 통해 공유할 수 있습니다 AWS Organizations. VPC는 하나의 서비스 네트워크와만 연결할 수 있습니다. 이 솔루션은 계정 간 통신을 위해 VPC 피어링 또는 AWS Transit Gateway 를 사용할 필요가 없습니다.
## 네트워크 연결 모범 사례
+ 중앙 집중식 네트워킹에 사용하는 AWS 계정 를 생성합니다. 이 계정의 이름을 **network-prod**로 AWS Transit Gateway 지정하고 및 [Amazon VPC IP 주소 관리자](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html)(IPAM)에 사용합니다. **Infrastructure\$1Prod** 조직 단위에 이 계정을 추가합니다.
+ [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)(AWS RAM)를 사용하여 전송 게이트웨이, VPC Lattice 서비스 네트워크 및 IPAM 풀을 나머지 조직과 공유합니다. 이렇게 하면 조직 AWS 계정 내 모든가 이러한 서비스와 상호 작용할 수 있습니다.
+ IPAM 풀로 IPv4 및 IPv6 주소 할당을 중앙에서 관리하여 최종 사용자가 [AWS Service Catalog](https://aws.amazon.com/servicecatalog/)로 VPC를 자체 프로비저닝하도록 할 수 있습니다. 이를 통해 VPC 크기를 적절하게 조정하고 IP 주소 공간이 겹치는 것을 방지할 수 있습니다.
+ 인터넷으로 향하는 트래픽에는 중앙 집중식 송신 접근 방식을 사용하고, 인터넷에서 환경으로 들어오는 트래픽에는 분산 수신 접근 방식을 사용합니다. 자세한 내용은 [중앙 집중식 송신](centralized-egress.md) 및 [분산 수신](decentralized-ingress.md) 섹션을 참조하세요.
# 중앙 집중식 송신
*중앙 집중식 송신*은 인터넷으로 향하는 모든 네트워크 트래픽에 단일 공통 진입점을 사용하는 원칙입니다. 이 진입점에서 검사를 설정할 수 있으며 지정된 도메인 또는 지정된 포트 또는 프로토콜을 통해서만 트래픽을 허용할 수 있습니다. 또한 송신을 중앙 집중화하면 인터넷에 연결하기 위해 각 VPC에 NAT 게이트웨이를 배포할 필요가 없으므로 비용을 절감할 수 있습니다. 이는 맬웨어 명령 및 제어(C&C) 인프라와 같이 외부에서 액세스 가능한 악성 리소스에 대한 노출을 제한하므로 보안 관점에서 유익합니다. 중앙 집중식 송신에 대한 자세한 내용과 아키텍처 옵션은 [중앙 집중식 송신에서 인터넷으로(백서)를 참조하세요](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-egress-to-internet.html).AWS
관리형 상태 저장 Network Firewall이자 침입 탐지 및 방지 서비스인 [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html)을 송신 트래픽의 중앙 검사 지점으로 사용할 수 있습니다. 송신 트래픽을 위한 전용 VPC에서 이 방화벽을 설정합니다. Network Firewall은 특정 도메인에 대한 인터넷 액세스를 제한하는 데 사용할 수 있는 상태 저장 규칙을 지원합니다. 자세한 내용은 [Domain filtering](https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricata-examples.html#suricata-example-domain-filtering)(Network Firewall 설명서)을 참조하세요.
[Amazon Route 53 Resolver DNS 방화벽](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html)을 사용하면 송신 트래픽을 특정 도메인 이름으로 제한하여 주로 데이터의 무단 유출을 방지할 수도 있습니다. DNS 방화벽 규칙에서는 지정된 도메인에 대한 액세스를 허용하거나 거부하는 [도메인 목록](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-domain-lists.html)(Route 53 설명서)을 적용할 수 있습니다. 악성 활동 또는 기타 잠재적 위협과 관련된 도메인 이름이 포함된 AWS 관리형 도메인 목록을 사용하거나 사용자 지정 도메인 목록을 생성할 수 있습니다. DNS 방화벽 규칙 그룹을 생성한 다음 VPC에 적용합니다. 아웃바운드 DNS 요청은 도메인 이름 확인을 위해 VPC의 Resolver를 통해 라우팅되며, DNS 방화벽은 VPC에 적용된 규칙 그룹을 기반으로 요청을 필터링합니다. Resolver로 가는 재귀적 DNS 요청은 전송 게이트웨이와 Network Firewall 경로를 통해 흐르지 않습니다. Route 53 Resolver와 DNS 방화벽은 VPC에서 나가는 별도의 송신 경로로 간주해야 합니다.
다음 이미지는 중앙 집중식 송신을 위한 샘플 아키텍처를 보여줍니다. 네트워크 통신이 시작되기 전에 DNS 요청이 Route 53 Resolver로 전송됩니다. 여기서 DNS 방화벽은 통신에 사용되는 IP 주소의 확인을 허용하거나 거부합니다. 인터넷으로 향하는 트래픽은 중앙 집중식 네트워킹 계정의 전송 게이트웨이로 라우팅됩니다. 전송 게이트웨이는 검사를 위해 트래픽을 Network Firewall에 전달합니다. 방화벽 정책이 송신 트래픽을 허용하는 경우 트래픽은 NAT 게이트웨이, 인터넷 게이트웨이 및 인터넷을 통해 라우팅됩니다. AWS Firewall Manager 를 사용하여 다중 계정 인프라에서 DNS 방화벽 규칙 그룹 및 네트워크 방화벽 정책을 중앙에서 관리할 수 있습니다.
![\[네트워크 계정을 통해 다른 계정에서 인터넷으로 트래픽 라우팅\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/3_egress.png)
## 송신 트래픽 보안 모범 사례
+ [로깅 전용 모드](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-rule-actions.html)(Route 53 설명서)에서 시작합니다. 합법적인 트래픽이 영향을 받지 않는지 확인한 후 차단 모드로 변경합니다.
+ [AWS Firewall Manager 네트워크 액세스 제어 목록에 대한 정책을](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms-network-acl.html) 사용하거나를 사용하여 인터넷으로 가는 DNS 트래픽을 차단합니다 AWS Network Firewall. 모든 DNS 쿼리는 Route 53 Resolver를 통해 라우팅되어야 합니다. 여기서 Amazon GuardDuty(활성화된 경우)로 모니터링하고 [Route 53 Resolver DNS 방화벽](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html)(활성화된 경우)으로 필터링할 수 있습니다. 자세한 내용은 [Resolving DNS queries between VPCs and your network](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html)(Route 53 설명서)를 참조하세요.
+ DNS 방화벽과 Network Firewall에서 [AWS 관리형 도메인 목록](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-managed-domain-lists.html)(Route 53 설명서)을 사용합니다.
+ .info, .top, .xyz 또는 일부 국가 코드 도메인과 같이 위험도가 높고 사용되지 않는 최상위 도메인을 차단하는 것을 고려합니다.
+ 포트 1389, 4444, 3333, 445, 135, 139 또는 53과 같이 위험도가 높고 사용되지 않는 포트를 차단하는 것을 고려합니다.
+ 시작점으로 AWS 관리형 규칙이 포함된 거부 목록을 사용할 수 있습니다. 그런 다음 허용 목록 모델을 구현하기 위해 시간 경과에 따라 작업할 수 있습니다. 예를 들어, 허용 목록에 정규화된 도메인 이름의 엄격한 목록만 포함하는 대신 *\$1.example.com* 같은 일부 와일드카드를 사용하는 것으로 시작합니다. 예상한 최상위 도메인만 허용하고 다른 도메인은 모두 차단할 수도 있습니다. 그런 다음 시간이 지남에 따라 그 범위를 좁힙니다.
+ [Route 53 Profiles](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/profiles.html)(Route 53 설명서)를 사용하여 여러 VPC 및 여러 VPC에 DNS 관련 Route 53 구성을 적용할 수 있습니다 AWS 계정. VPCs
+ 이러한 모범 사례에 대한 예외를 처리하는 프로세스를 정의합니다.
# 분산 수신
*분산 수신*은 개별 계정 수준에서 인터넷 트래픽이 해당 계정의 워크로드에 도달하는 방식을 정의하는 원칙입니다. 다중 계정 아키텍처에서 분산 수신의 이점 중 하나는 각 계정이 해당 워크로드에 가장 적합한 수신 서비스 또는 리소스(예: Application Load Balancer, Amazon API Gateway 또는 Network Load Balancer)를 사용할 수 있다는 것입니다.
분산 수신은 각 계정을 개별적으로 관리해야 함을 의미하지만 [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html)를 통해 구성을 중앙에서 관리하고 유지할 수 있습니다. Firewall Manager는 [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) 및 [Amazon VPC 보안 그룹](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)과 같은 보호를 지원합니다. Application Load Balancer, Amazon CloudFront, API Gateway 또는 AWS WAF 에 연결할 수 있습니다 AWS AppSync. [중앙 집중식 송신](centralized-egress.md)에 설명된 대로 송신 VPC와 전송 게이트웨이를 사용하는 경우 각 스포크 VPC에는 퍼블릭 및 프라이빗 서브넷이 포함됩니다. 그러나 트래픽은 네트워킹 계정의 송신 VPC를 통해 라우팅되므로 NAT 게이트웨이를 배포할 필요가 없습니다.
다음 이미지는 인터넷에 액세스할 수 AWS 계정 있는 워크로드가 포함된 단일 VPC가 있는 개인의 예를 보여줍니다. 인터넷의 트래픽은 인터넷 게이트웨이를 통해 VPC에 액세스하고 퍼블릭 서브넷에서 호스팅되는 로드 밸런싱 및 보안 서비스에 도달합니다. **퍼블릭 서브넷에는 인터넷 게이트웨이에 대한 기본 경로가 포함되어 있습니다. 로드 밸런서를 퍼블릭 서브넷에 배포하고 AWS WAF 액세스 제어 목록(ACLs)을 연결하여 교차 사이트 스크립팅과 같은 악의적인 트래픽으로부터 보호합니다. 인터넷에 직접 액세스할 수 없는 **프라이빗 서브넷에 애플리케이션을 호스팅하는 워크로드를 배포합니다.
![\[인터넷 게이트웨이 AWS WAF및 로드 밸런서를 통해 VPC에 액세스하는 인터넷의 트래픽입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/4_ingress.png)
조직에 VPC가 많은 경우 전용 공유 AWS 계정에 인터페이스 VPC 엔드포인트 또는 프라이빗 호스팅 영역을 생성하여 공통 AWS 서비스 를 공유할 수 있습니다. 자세한 내용은 [인터페이스 VPC 엔드포인트를 AWS 서비스 사용하여 액세스](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)(AWS PrivateLink 문서) 및 [프라이빗 호스팅 영역 작업](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html)(Route 53 설명서)을 참조하세요.
다음 이미지는 조직 전체에서 공유할 수 AWS 계정 있는 리소스를 호스팅하는의 예를 보여줍니다. 전용 VPC에서 VPC 엔드포인트를 생성하여 여러 계정에서 공유할 수 있습니다. VPC 엔드포인트를 생성할 때 AWS 가 엔드포인트에 대한 DNS 항목을 관리하도록 할 수도 있습니다. 엔드포인트를 공유하려면 이 옵션을 선택 취소하고 별도의 Route 53 프라이빗 호스팅 영역(PHZ)에 DNS 항목을 생성합니다. 그런 다음 VPC 엔드포인트의 중앙 집중식 DNS 확인을 위해 PHZ를 조직의 모든 VPC에 연결할 수 있습니다. 또한 전송 게이트웨이 라우팅 테이블에 공유 VPC에서 다른 VPC로의 경로가 포함되어 있는지 확인해야 합니다. 자세한 내용은 [인터페이스 VPC 엔드포인트에 대한 중앙 집중식 액세스](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints)(AWS 백서)를 참조하세요.
![\[다른 멤버 계정과 공유하기 위해 서비스 엔드포인트 및 리소스를 호스팅하는 공유 계정입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/5_shared.png)
공유 AWS 계정 는 AWS Service Catalog 포트폴리오를 호스팅하기에 좋은 장소이기도 합니다. *포트폴리오*는 배포에 사용할 수 있게 하려는 IT 서비스의 모음이며 AWS포트폴리오에는 해당 서비스에 대한 구성 정보가 포함되어 있습니다. 공유 계정에서 포트폴리오를 생성하고 조직에 공유한 다음 각 멤버 계정이 포트폴리오를 자체 리전 Service Catalog 인스턴스로 가져올 수 있습니다. 자세한 내용은 [Sharing with AWS Organizations](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_portfolios_sharing_how-to-share.html#portfolio-sharing-organizations)(Service Catalog 설명서)를 참조하세요.
마찬가지로 Amazon VPC Lattice를 사용하면 공유 계정을 사용하여 환경 및 서비스 템플릿을 엔터티로 중앙에서 관리한 다음 조직 멤버 계정과의 계정 연결을 설정할 수 있습니다. 자세한 내용은 [VPC Lattice 엔터티 공유(VPC Lattice 설명서)를 참조하세요](https://docs.aws.amazon.com/vpc-lattice/latest/ug/sharing.html).