기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 네트워킹
Outpost 배포는 관리, 모니터링 및 서비스 운영이 제대로 작동할 수 있도록 앵커 AZ에 대한 탄력적인 연결을 필요로 합니다. 각 Outpost 랙에 중복 네트워크 연결을 제공하고 AWS 클라우드의 앵커 포인트에 다시 안정적인 연결을 제공하도록 온프레미스 네트워크를 프로비저닝해야 합니다. 또한 Outpost에서 실행되는 애플리케이션 워크로드와 해당 워크로드가 통신하는 다른 온프레미스 및 클라우드 시스템 간의 네트워크 경로를 고려해 보세요. 네트워크에서 이 트래픽을 어떻게 라우팅하시겠습니까?
**Topics**
+ [네트워크 연결](network-attachment.md)
+ [앵커 연결](anchor-connectivity.md)
+ [애플리케이션/워크로드 라우팅](applicationworkload-routing.md)
# 네트워크 연결
각 AWS Outposts 랙은 Outpost 네트워킹 디바이스(ONDs라는 중복top-of-rack 스위치로 구성됩니다. 각 랙의 컴퓨팅 및 스토리지 서버는 두 OND에 모두 연결됩니다. 각 OND를 데이터 센터의 고객 네트워킹 장치(CND)라는 별도의 스위치에 연결하여 각 Outpost 랙에 다양한 물리적 및 논리적 경로를 제공해야 합니다. OND는 광섬유 케이블과 광 트랜시버를 사용하여 하나 이상의 물리적 연결을 통해 CND에 연결합니다. [물리적 연결](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#physical-connectivity)은 논리적 [링크 집계 그룹(LAG) 링크](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#link-aggregation)에서 구성됩니다.
![\[중복 네트워크 연결이 있는 멀티랙 Outpost를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/multi-rack-outpost.png)
OND에서 CND로의 링크는 물리적 연결이 단일 광섬유 케이블인 경우에도 항상 LAG로 구성됩니다. 링크를 LAG 그룹으로 구성하면 논리적 그룹에 물리적 연결을 추가하여 링크 대역폭을 늘릴 수 있습니다. LAG 링크는 Outpost와 온프레미스 네트워크 간의 분리된 네트워킹을 가능하게 하는 IEEE 802.1q 이더넷 트렁크로 구성됩니다.
모든 Outpost에는 고객 네트워크와 통신하거나 고객 네트워크를 통해 통신해야 하는 논리적으로 분리된 네트워크가 두 개 이상 있습니다.
+ **서비스 링크 네트워크** -는 서비스 링크 IP 주소를 Outpost 서버에 할당하고 온프레미스 네트워크와의 통신을 촉진하여 서버가 리전의 Outpost 앵커 포인트에 다시 연결할 수 있도록 합니다. 단일 논리적 Outpost에 여러 랙 구현이 있는 경우 각 랙에 서비스 링크 /26 CIDR을 할당해야 합니다.
+ **로컬 게이트웨이 네트워크** - Outpost 로컬 게이트웨이(LGW)를 통해 Outpost의 VPC 서브넷과 온프레미스 네트워크 간에 통신할 수 있게 합니다.
이렇게 분리된 네트워크는 LAG 링크를 통한 일련의 [지점 간 IP 연결](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#network-layer-connectivity)을 통해 온프레미스 네트워크에 연결됩니다. 각 OND-CND LAG 링크는 VLAN IDs, point-to-point(/30 또는 /31) IP 서브넷, 분리된 각 네트워크(서비스 링크 및 LGW)에 대한 eBGP 피어링으로 구성됩니다. 지점 간 VLAN 및 서브넷이 있는 LAG 링크는 계층 2로 분할되고, 라우팅된 계층 3 연결로 간주해야 합니다. 라우팅된 IP 연결은 Outpost의 분리된 네트워크와 온프레미스 네트워크 간의 통신을 용이하게 하는 중복 논리적 경로를 제공합니다.
![\[서비스 링크 피어링을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/service-link-peering.png)
![\[로컬 게이트웨이 피어링을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/page-20-local-gateway-peering.png)
직접 연결된 CND 스위치에서 계층 2 LAG 링크(및 해당 VLAN)를 종료하고 CND 스위치에서 IP 인터페이스 및 BGP 피어링을 구성해야 합니다. 데이터 센터 스위치 간에 LAG VLAN을 연결해서는 안 됩니다. 자세한 내용은AWS Outposts 사용 설명서**의 [네트워크 계층 연결](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#network-layer-connectivity)을 참조하세요.
논리적 다중 랙 Outpost 내에서 ONDs는 중복으로 상호 연결되어 랙과 서버에서 실행되는 워크로드 간에 고가용성 네트워크 연결을 제공합니다. AWS 는 Outpost 내에서 네트워크 가용성을 담당합니다.
## ACE가 없는 고가용성 네트워크 연결에 대한 권장 사례
+ Outpost 랙의 각 Outpost 네트워킹 장치(OND)를 데이터 센터의 개별 고객 네트워킹 장치(CND) 에 연결합니다.
+ 직접 연결된 고객 네트워킹 장치(CND) 스위치에서 계층 2 링크, VLAN, 계층 3 IP 서브넷 및 BGP 피어링을 종료합니다. CND 간 또는 온프레미스 네트워크 전체에서 OND와 CND VLAN을 연결하지 마세요.
+ 링크 집계 그룹(LAG) 에 링크를 추가하여 Outpost와 데이터 센터 간의 가용 대역폭을 늘리세요. 두 OND를 통과하는 다양한 경로의 총 대역폭에 의존하지 마세요.
+ 중복 OND를 통한 다양한 경로를 사용하여 Outpost 네트워크와 온프레미스 네트워크 간에 탄력적인 연결을 제공하세요.
+ 중복을 최적화하고 운영 중단 없는 OND 유지 관리를 가능하게 하기 위해서는, 고객이 다음과 같이 BGP 알림 및 정책을 구성하는 것이 좋습니다.
+ 고객 네트워크 장비는 BGP 속성을 변경하지 않고 Outpost로부터 BGP 알림을 수신하고 BGP 다중 경로/로드 밸런싱을 통해 최적의 인바운드 트래픽 흐름(고객에서 Outpost로)을 달성할 수 있도록 해야 합니다. 유지 관리가 필요한 경우 Outpost BGP 접두사에 AS-Path 프리펜딩을 사용하여 트래픽을 특정 OND/업링크에서 멀어지게 합니다. 고객 네트워크는 AS-Path 길이가 1인 Outpost의 경로를 AS-Path 길이가 4인 경로, 즉 AS-Path 프리펜딩에 반응하는 경로보다 선호해야 합니다.
+ 고객 네트워크는 Outpost의 모든 OND에 동일한 속성을 가진 동일한 BGP 접두사를 알려야 합니다. 기본적으로 Outpost 네트워크는 모든 업링크 간에 아웃바운드 트래픽 (고객 대상) 의 부하를 분산합니다. 유지 관리가 필요한 경우 Outpost 측에서는 라우팅 정책을 사용하여 트래픽을 특정 OND에서 다른 곳으로 이동합니다. 이러한 트래픽 전환을 수행하고 운영 중단 없이 유지 관리를 수행하려면 모든 OND에서 고객 측에서 동일한 BGP 접두사를 사용해야 합니다. 고객 네트워크에 유지 관리가 필요한 경우 AS-Path 프리펜딩을 사용하여 특정 업링크 또는 장치에서 트래픽을 일시적으로 전환시키는 것이 좋습니다.
## ACE를 사용한 고가용성 네트워크 연결에 대한 권장 사례
4개 이상의 컴퓨팅 랙이 있는 다중 랙 배포의 경우 네트워크 집계 지점 역할을 하여 온프레미스 네트워킹 디바이스에 대한 광섬유 링크 수를 줄이는 집계, 코어, 엣지(ACE) 랙을 사용해야 합니다. ACE 랙은 각 Outpost 랙의 ONDs에 대한 연결을 제공하므로 AWS 는 ONDs와 ACE 네트워킹 디바이스 간의 VLAN 인터페이스 할당 및 구성을 소유합니다.
Service Link 및 Local Gateway 네트워크에 대한 격리된 네트워크 계층은 ACE 랙 사용 여부와 관계없이 여전히 필요합니다. ACE 랙은 분리된 각 네트워크에 대한 VLAN point-to-point(/30 또는 /31) IP 서브넷 및 eBGP 피어링 구성을 목표로 합니다. 제안된 아키텍처는 다음과 같이 두 아키텍처 중 하나를 따라야 합니다.
![\[2명의 고객 네트워크 디바이스\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/page-22-two-customer-networking-devices.png)
+ 이 아키텍처를 사용하면 고객은 ACE 네트워킹 디바이스를 상호 연결하여 중복성을 제공하는 두 개의 네트워킹 디바이스(CND)를 보유해야 합니다.
+ 각 물리적 연결에 대해 단일 물리적 포트인 경우에도 LAG(Outpost와 데이터 센터 간에 사용 가능한 대역폭을 늘리기 위해)를 활성화해야 하며, 2개의 point-to-point VLANs(/30 또는 /31)과 ACEs와 CNDs 간의 eBGP 구성이 있는 두 개의 네트워크 세그먼트를 전달합니다.
+ 안정적인 상태에서 트래픽은 ACE 계층에서 고객 네트워크로/에서 균등 비용 다중 경로(ECMP) 패턴에 따라 로드 밸런싱되며, ACE에서 고객으로의 트래픽 분포는 25%입니다. 이 동작을 허용하려면 ACEs와 CNDs 간의 eBGP 피어링에 BGP 다중 경로/로드 밸런싱이 활성화되어 있어야 하며 4개의 eBGP 피어링 연결에서 동일한 BGP 지표가 있는 고객 접두사를 발표했습니다.
+ 최적의 중복성을 달성하고 중단 없는 OND 유지 관리를 허용하려면 고객이 다음 권장 사항을 따르는 것이 좋습니다.
+ 고객 네트워킹 디바이스는 Outpost의 모든 ONDs에 동일한 속성을 가진 동일한 BGP 접두사를 알려야 합니다.
+ 고객 네트워킹 디바이스는 BGP 속성을 변경하지 않고 Outpost로부터 BGP 광고를 수신해야 하며 BGP 다중 경로/로드 밸런싱을 활성화해야 합니다.
![\[4명의 고객 네트워크 디바이스\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/page-23-four-customer-networking-devices.png)
이 아키텍처를 사용하면 고객은 ACE 네트워킹 디바이스를 상호 연결하는 네 개의 네트워킹 디바이스(CND)를 갖게 되며, 2 CND 아키텍처에 적용할 수 있는 VLANs, eBGP 및 ECMP를 포함하여 중복성과 동일한 네트워킹 로직을 제공합니다.
# 앵커 연결
[Outpost 서비스 링크](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html)는 Outpost의 상위 리전에 있는 특정 가용 영역(AZ)의 퍼블릭 또는 프라이빗 앵커(둘 다 아님)에 연결됩니다. Outpost 서버는 서비스 링크 IP 주소에서 앵커 AZ의 앵커 지점으로의 아웃바운드 서비스 링크 VPN 연결을 시작합니다. 이러한 연결은 UDP 및 TCP 포트 443을 사용합니다. AWS 는 리전의 앵커 포인트 가용성을 담당합니다.
Outpost 서비스 링크 IP 주소가 네트워크를 통해 앵커 AZ의 앵커 포인트에 연결할 수 있는지 확인해야 합니다. 서비스 링크 IP 주소는 온프레미스 네트워크의 다른 호스트와 통신할 필요가 없습니다.
퍼블릭 앵커 포인트는 해당 리전의 [퍼블릭 IP 범위](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html)(EC2 서비스 CIDR 블록)에 있으며 인터넷 또는 [AWS Direct Connect](https://aws.amazon.com/directconnect/)(DX) 퍼블릭 가상 인터페이스(VIF)를 통해 액세스할 수 있습니다. 퍼블릭 앵커 포인트를 사용하면 서비스 링크 트래픽이 퍼블릭 인터넷의 앵커 포인트에 성공적으로 도달할 수 있는 사용 가능한 경로를 통해 라우팅될 수 있으므로 보다 유연한 경로 선택이 가능합니다.
프라이빗 앵커 포인트를 사용하면 IP 주소 범위를 앵커 연결에 사용할 수 있습니다. 프라이빗 앵커 포인트는 고객이 할당한 IP 주소를 사용하여 [전용 VPC 내의 프라이빗 서브넷](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html#private-connectivity)에 생성됩니다. VPC는 Outpost 리소스를 소유 AWS 계정 하는에서 생성되며 VPC를 사용할 수 있고 올바르게 구성되었는지 확인할 책임은 사용자에게 있습니다. 사용자가 해당 Virtual Private Cloud(VPC)를 삭제하지 못하도록 하려면 AWSOrigamiServiceGateway Organizations의 보안 제어 정책(SCP)을 사용합니다.프라이빗 앵커 포인트는 [Direct Connect 프라이빗 VIFs](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-outposts-private-connectivity/) 사용하여 액세스해야 합니다.
Outpost와 리전 내 앵커 포인트 사이에 중복 네트워크 경로를 제공해야 하며, 두 곳 이상의 위치에 있는 개별 장치에서 연결이 종료됩니다. 연결 또는 네트워킹 장치에 장애가 발생할 경우 트래픽을 대체 경로로 자동으로 다시 라우팅하도록 동적 라우팅을 구성해야 합니다. 한 WAN 경로에 장애가 발생해도 나머지 경로에 과부하가 걸리지 않도록 충분한 네트워크 용량을 프로비저닝해야 합니다.
다음 다이어그램은를 사용하는 앵커 AZs에 대한 중복 네트워크 경로 AWS Direct Connect 와 퍼블릭 인터넷 연결이 있는 3개의 Outpost를 보여줍니다. Outpost A와 Outpost B는 같은 리전의 서로 다른 가용 영역에 고정되어 있습니다. Outpost A는 리전 1의 AZ 1에 있는 프라이빗 앵커 포인트와 연결됩니다. Outpost B는 리전 1의 AZ 2에 있는 퍼블릭 앵커 포인트와 연결됩니다. Outpost C는 리전 2의 AZ 1에 있는 퍼블릭 앵커와 연결됩니다.
![\[AWS Direct Connect 및 퍼블릭 인터넷 액세스를 통한 고가용성 앵커 연결을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/highly-available-anchor-connectivity.png)
Outpost A에는 프라이빗 앵커 포인트에 도달하기 위한 세 개의 중복 네트워크 경로가 있습니다. 단일 Direct Connect 위치의 중복 Direct Connect 회로를 통해 두 개의 경로를 사용할 수 있습니다. 세 번째 경로는 두 번째 Direct Connect 위치의 Direct Connect 회로를 통해 사용할 수 있습니다. 이 설계는 Outpost A의 서비스 링크 트래픽을 프라이빗 네트워크에 유지하고 Direct Connect 회로 중 하나의 장애 또는 전체 Direct Connect 위치의 장애를 허용하는 경로 중복성을 제공합니다.
Outpost B에는 퍼블릭 앵커 포인트에 도달하기 위한 네 개의 중복 네트워크 경로가 있습니다. Outpost A에서 사용하는 Direct Connect 회로와 위치에서 제공되는 퍼블릭 VIF를 통해 세 가지 경로를 사용할 수 있습니다. 네 번째 경로는 고객 WAN과 퍼블릭 인터넷을 통해 사용할 수 있습니다. Outpost B의 서비스 링크 트래픽은 퍼블릭 인터넷의 앵커 포인트에 성공적으로 도달할 수 있는 사용 가능한 경로를 통해 라우팅될 수 있습니다. Direct Connect 경로를 사용하면 보다 일관된 대기 시간과 더 높은 대역폭 가용성을 제공할 수 있는 반면 퍼블릭 인터넷 경로는 재해 복구(DR) 또는 대역폭 확대 시나리오에 사용될 수 있습니다.
Outpost C에는 퍼블릭 앵커 포인트에 도달하기 위한 두 개의 중복 네트워크 경로가 있습니다. Outpost C는 Outposts A 및 B와는 다른 데이터 센터에 구축되어 있습니다. Outpost C의 데이터 센터에는 고객 WAN에 연결되는 전용 회로가 없습니다. 대신 데이터 센터에는 서로 다른 두 인터넷 서비스 제공업체(ISP)가 제공하는 중복 인터넷 연결이 있습니다. Outpost C의 서비스 링크 트래픽은 ISP 네트워크 중 하나를 통해 라우팅되어 퍼블릭 인터넷의 앵커 포인트에 도달할 수 있습니다. 이 설계를 사용하면 사용 가능한 모든 퍼블릭 인터넷 연결을 통해 서비스 링크 트래픽을 유연하게 라우팅할 수 있습니다. 그러나 종단 간 경로는 대역폭 가용성과 네트워크 지연 시간이 변동하는 타사 퍼블릭 네트워크에 따라 달라집니다.
Outpost와 해당 서비스 링크 앵커 포인트 간의 네트워크 경로는 다음 대역폭 사양을 충족해야 합니다.
+ Outpost 랙당 500Mbps - 1Gbps의 가용 대역폭(예: 랙 3개: 1.5\$13Gbps의 가용 대역폭)
## 고가용성 앵커 연결에 대한 권장 사례
+ 각 Outpost와 해당 리전의 앵커 포인트 사이에 중복 네트워크 경로를 제공합니다.
+ Direct Connect(DX) 경로를 사용하여 지연 시간과 대역폭 가용성을 제어할 수 있습니다.
+ TCP 및 UDP 포트 443이 Outpost 서비스 링크 CIDR 블록에서 상위 리전의 [EC2 IP 주소 범위](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html)까지 열려 있는지(아웃바운드) 확인합니다. 모든 네트워크 경로에서 포트가 열려 있는지 확인합니다.
+ 리전에 대한 CIDR 범위의 하위 집합을 사용하는 경우 방화벽의 Amazon EC2 IP 주소 범위를 추적합니다.
+ 각 경로가 대역폭 가용성 및 지연 시간 요구 사항을 충족하는지 확인합니다.
+ 동적 라우팅을 사용하여 네트워크 장애에 대한 트래픽 리디렉션을 자동화합니다.
+ 계획된 각 네트워크 경로를 통해 서비스 링크 트래픽 라우팅을 테스트하여 경로가 예상대로 작동하는지 확인합니다.
# 애플리케이션/워크로드 라우팅
Outpost에서 애플리케이션 워크로드를 처리하는 데는 두 가지 경로가 있습니다.
+ 서비스 링크 경로: 애플리케이션 트래픽이 [MTU를 1,300바이트](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html#service-links)로 제한하는 것 외에도 Outposts 컨트롤 플레인 트래픽과 경쟁한다고 가정합니다.
+ 로컬 게이트웨이(LGW) 경로: 고객의 로컬 네트워크가 온프레미스와에 있는 두 애플리케이션에 대한 액세스를 모두 허용한다고 가정합니다 AWS 리전.
대상 네트워크에 도달하기 위한 경로 선택을 제어하도록 Outpost 서브넷 라우팅 테이블을 구성합니다. LGW를 가리키는 경로는 트래픽을 로컬 게이트웨이를 통해 온프레미스 네트워크로 전달합니다. Internet Gateway, NAT Gateway, Virtual Private Gateway 및 TGW와 같이 리전의 서비스 및 리소스를 가리키는 경로는 [서비스 링크를](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html) 사용하여 이러한 대상에 도달합니다. 동일한 Outpost에 여러 VPC가 있는 VPCs 피어링 연결이 있는 경우 VPCs 간의 트래픽은 Outpost에 남아 있으며 리전으로 서비스 링크를 다시 사용하지 않습니다. VPC 피어링에 대한 자세한 내용은 Amazon [ VPCs 사용하여 VPC 연결을 참조하세요](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html). **
![\[Outpost 서비스 링크 및 LGW 네트워크 경로의 시각화를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/outpost-service-link-and-lgw-network-paths.png)
애플리케이션 라우팅을 계획할 때는 네트워크 장애 시 정상 작동과 제한된 라우팅 및 서비스 가용성을 모두 고려하도록 주의를 기울여야 합니다. Outpost가 리전과 연결 해제된 경우 서비스 링크 경로를 사용할 수 없습니다.
다양한 경로를 제공하고 Outpost LGW와 중요한 온프레미스 애플리케이션, 시스템 및 사용자 간에 동적 라우팅을 구성해야 합니다. 중복 네트워크 경로를 통해 네트워크에서 장애가 발생한 경우 트래픽을 라우팅하고 부분적인 네트워크 장애 발생 시 온프레미스 리소스가 Outpost에서 실행되는 워크로드와 통신할 수 있습니다.
Outpost VPC 라우팅 구성은 정적입니다. AWS Management Console, CLI, APIs 및 기타 코드형 인프라(IaC) 도구를 통해 서브넷 라우팅 테이블을 구성하지만 연결 해제 이벤트 중에는 서브넷 라우팅 테이블을 수정할 수 없습니다. 라우팅 테이블을 업데이트하려면 Outpost와 리전 간의 연결을 다시 설정해야 합니다. 연결 해제 이벤트 중에 사용할 계획과 동일한 경로를 일반 운영에도 사용하세요.
Outpost의 리소스는 리전의 서비스 링크와 인터넷 게이트웨이(IGW) 또는 로컬 게이트웨이(LGW) 경로를 통해 인터넷에 연결할 수 있습니다. LGW 경로 및 온프레미스 네트워크를 통해 인터넷 트래픽을 라우팅하면 기존 온프레미스 인터넷 수신/송신 지점을 사용할 수 있으며 리전의 IGW에 대한 서비스 링크 경로를 사용하는 경우와 비교하여 지연 시간이 짧고 MTUs가 높으며 데이터 송신 요금이 절감 AWS 될 수 있습니다.
애플리케이션이 온프레미스에서 실행되어야 하고 퍼블릭 인터넷에서 액세스할 수 있어야 하는 경우, 애플리케이션 트래픽을 온프레미스 인터넷 연결을 통해 LGW로 라우팅하여 Outpost의 리소스에 도달해야 합니다.
Outpost에서 서브넷을 리전의 퍼블릭 서브넷처럼 구성할 수 있지만 대부분의 사용 사례에서는 바람직하지 않을 수 있습니다. 인바운드 인터넷 트래픽은를 통해 들어오 AWS 리전 고 서비스 링크를 통해 Outpost에서 실행되는 리소스로 라우팅됩니다.
그러면 응답 트래픽이 서비스 링크를 통해 라우팅되고 AWS 리전의 인터넷 연결을 통해 다시 라우팅됩니다. 이 트래픽 패턴은 지연 시간을 가중시킬 수 있으며, 트래픽이 Outpost로 가는 도중에 리전을 떠나 돌아오고, 돌아오는 트래픽이 리전을 통해 다시 들어와 인터넷으로 나가는 경우 데이터 송신 요금이 부과됩니다. 해당 리전에서 애플리케이션을 실행할 수 있는 경우 해당 리전에서 애플리케이션을 실행하는 것이 가장 좋습니다.
동일한 VPC에 있는 VPC 리소스 간 트래픽은 항상 로컬 VPC CIDR 경로를 따르며 암시적 VPC 라우터를 통해 서브넷 간에 라우팅됩니다.
예를 들어 Outpost에서 실행되는 EC2 인스턴스와 리전의 VPC 엔드포인트 간의 트래픽은 항상 서비스 링크를 통해 라우팅됩니다.
![\[암시적 라우터를 통한 로컬 VPC 라우팅을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/local-vpc-routing-through-implicit-routers.png)
## 애플리케이션/워크로드 라우팅에 대한 권장 사례
+ 가능하면 서비스 링크 경로 대신 로컬 게이트웨이(LGW) 경로를 사용합니다.
+ LGW 경로를 통해 인터넷 트래픽을 라우팅합니다.
+ Outpost 서브넷 라우팅 테이블을 표준 라우팅 세트로 구성합니다. 표준 라우팅 테이블은 일반 운영 및 연결 해제 이벤트 중에 모두 사용됩니다.
+ Outpost LGW와 중요한 온프레미스 애플리케이션 리소스 간에 중복 네트워크 경로를 제공합니다. 동적 라우팅을 사용하여 온프레미스 네트워크 장애에 대한 트래픽 리디렉션을 자동화하세요.