AWS App Runner 는 2026년 4월 30일부터 신규 고객에게 더 이상 공개되지 않습니다. App Runner를 사용하려면 해당 날짜 이전에 가입하세요. 기존 고객은 정상적으로 서비스를 계속 이용할 수 있습니다. 자세한 내용은 [AWS App Runner 가용성 변경](https://docs.aws.amazon.com/apprunner/latest/dg/apprunner-availability-change.html)을 참조하세요.

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

# 인스턴스를 시작하거나 확장할 IP 주소가 충분하지 않은 경우
<a name="troubleshooting-not-enough-ips"></a>

**참고**  
 퍼블릭 서비스의 경우 App Runner는 VPCs에 탄력적 네트워크 인터페이스(ENI)를 생성하지 않으므로 퍼블릭 서비스는이 변경의 영향을 받지 않습니다.

 이 가이드는 발신 트래픽에 대한 VPC 액세스가 활성화된 App Runner 서비스에서 발생할 수 있는 IP 소진 오류를 해결하는 데 도움이 됩니다.

 App Runner는 VPC 커넥터와 연결된 서브넷에서 인스턴스를 시작합니다. App Runner는 인스턴스가 시작되는 서브넷에서 인스턴스당 1개의 ENI를 생성합니다. 각 ENI는 해당 서브넷에서 프라이빗 IP를 사용합니다. 서브넷에는 해당 서브넷과 연결된 CIDR 블록에 따라 사용 가능한 IPs 수가 고정되어 있습니다. App Runner가 ENI를 생성하기에 충분한 IPs 있는 서브넷(들)을 찾을 수 없는 경우 App Runner 서비스에 대한 새 인스턴스를 시작하지 못합니다. 이로 인해 서비스 확장에 문제가 발생할 수 있습니다. 이 경우 App Runner가 사용 가능한 IPs가 있는 서브넷을 찾을 수 없음을 나타내는 App Runner 이벤트 로그가 표시됩니다. 아래 지침에 따라 서비스를 업데이트하여 이러한 오류를 해결할 수 있습니다.

## 사용 가능한 IPs 더 많도록 서비스를 업데이트하는 방법
<a name="troubleshooting-not-enough-ips.service-steps"></a>

 서브넷에서 사용 가능한 IP 주소 수는 해당 서브넷과 연결된 CIDR 블록을 기반으로 합니다. 서브넷과 연결된 CIDR 블록은 생성 후 업데이트할 수 없습니다. App Runner VPC 커넥터는 생성된 후에는 업데이트할 수 없습니다. 발신 트래픽에 대한 VPC 액세스가 활성화된 App Runner 서비스에 더 많은 IPs를 제공하려면: 

1. 더 큰 CIDR 블록을 사용하여 새 서브넷(들)을 생성합니다.

1. 새 서브넷(들)을 사용하여 새 VPC 커넥터를 생성합니다.

1. 새 VPC 커넥터를 사용하도록 App Runner 서비스를 업데이트합니다.

## 서비스에 필요한 IPs 계산
<a name="troubleshooting-not-enough-ips.calculate-ips"></a>

 더 큰 CIDR 블록으로 새 서브넷(들)을 생성하기 전에 App Runner 서비스 전체에서 필요한 IPs 수를 결정합니다. 다음과 같이 커넥터에 필요한 IPs 계산하는 것이 좋습니다.

1. 발신 트래픽에 대한 VPC 액세스가 활성화된 각 서비스에 대해 Auto Scaling 구성의 [최대 크기(최대 인스턴스)](manage-autoscaling.md)를 기록해 둡니다.

1. 모든 서비스에서 값을 합산합니다.

1. 블루-그린 배포 중에 시작된 새 인스턴스를 고려하려면이 합계를 두 배로 늘립니다.

### 예제
<a name="troubleshooting-not-enough-ips.calculate-ips.example"></a>

 동일한 VPC 커넥터를 사용하여 두 서비스 A와 B를 고려합니다.

1. 서비스 A의 최대 크기는 25로 구성됩니다.

1. 서비스 B의 최대 크기는 15로 구성되어 있습니다.

 **필수 IPs** 2 × (25 \$1 15) = 80 

 서브넷에 사용 가능한 IPs가 80개 이상 결합되어 있는지 확인합니다.

## 새 서브넷(들) 생성
<a name="troubleshooting-not-enough-ips.create-subnets"></a>

1.  이 공식을 사용하여 IPv4에 필요한 CIDR 블록 크기를 결정합니다(AWS에서 5IPs를 예약함: [ 서브넷 크기 조정](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-sizing.html)).

   ```
   Number of available IP addresses = 2^(32 - prefix length) - 5
   ```

   ```
   Example :
   For 192.168.1.0/24:
   Prefix length is 24
   Number of available IP addresses = 2^(32 - 24) - 5 = 2^8-5 = 251 IP addresses
   
   For 10.0.0.0/16:
   Prefix length is 16
   Number of available IP addresses = 2^(32 - 16) - 5 = 2^16-5 = 65,531 IP addresses
   
   Quick reference:
   /24 = 251 IP addresses
   /16 = 65,531 IP addresses
   ```

1. AWS EC2 CLI를 사용하여 새 서브넷을 생성합니다.

   ```
   aws ec2 create-subnet --vpc-id <my-vpc-id> --cidr-block <cidr-block>
   ```

   예제(IP가 4,096IPs 서브넷 생성): 

   ```
   aws ec2 create-subnet --vpc-id my-vpc-id --cidr-block 10.0.0.0/20
   ```

1. 새 VPC 커넥터를 생성합니다. 참조: [VPC 액세스 관리](network-vpc.md)

1. 이 새 VPC 커넥터를 사용하도록 VPC로 송신 트래픽이 활성화된 상태로 서비스를 업데이트합니다. 서비스가 업데이트되면 App Runner가 새 서브넷 사용을 시작합니다.

**참고**  
 또한 VPCs는 CIDR 블록을 통해 서브넷에 할당할 수 있는 사용 가능한 IPs 수로 제한됩니다. 더 큰 CIDR 블록이 있는 서브넷을 생성할 수 없는 경우 새 서브넷(들)을 생성하기 전에 보조 CIDR 블록으로 VPC를 업데이트해야 할 수 있습니다.

## VPC에 보조 CIDR 블록 연결
<a name="troubleshooting-not-enough-ips.attach-secondary-ip"></a>

보조 CIDR 블록을이 VPC에 연결합니다.

```
 aws ec2 associate-vpc-cidr-block --vpc-id <my-vpc-id> --cidr-block <cidr-block> 
```

예제 : 

```
aws ec2 associate-vpc-cidr-block --vpc-id my-vpc-id --cidr-block 10.1.0.0/16 
```

## Verification(확인)
<a name="troubleshooting-not-enough-ips.verification"></a>

서비스를 업데이트한 후 다음을 사용하여 수정 사항을 확인할 수 있습니다.

1. **이벤트 로그 모니터링: ** App Runner 서비스 이벤트 [로그](monitor-cwl.md)를 모니터링하여 새 IP 또는 ENI 비가용성 오류가 표시되지 않는지 확인합니다.

1. **서비스 조정 확인: **

   1. Auto Scaling 구성에서 최소 인스턴스 수를 변경하여 서비스를 완전히 확장합니다.

   1. 모든 새 인스턴스가 IP 관련 오류 없이 시작되었는지 확인 

   1. 여러 조정 이벤트를 모니터링하여 일관된 성능 보장 

1. **콘솔 배너: ** AWS 관리 콘솔을 사용하는 경우 App Runner가 더 이상 IP 부족IPs 확인합니다.

1. **VPC 및 서브넷 IP 사용률: **

   1. VPC 대시보드 또는 CLI 명령을 사용하여 새 서브넷의 IP 주소 사용률을 확인합니다.

   1. 서비스가 스케일 업된 후에도 여전히 사용 가능한 IPs의 정상 마진이 있는지 확인 

## 일반적인 함정
<a name="troubleshooting-not-enough-ips.common-pitfalls"></a>

App Runner 서비스의 IP 소진 문제를 해결할 때는 다음과 같은 잠재적 문제에 유의하세요.

1. ** 부적절한 IP 주소 계획: ** 향후 IP 요구 사항을 과소 평가하면 반복적인 소진 문제가 발생할 수 있습니다. 잠재적 서비스 증가 및 최대 사용량 시나리오를 고려하여 철저한 용량 계획을 수행합니다.

1. **VPC 전체 IP 사용량 검토:** 동일한 VPC 내의 다른 AWS 서비스도 IP 주소를 사용합니다. VPC 및 서브넷 구성을 계획할 때 모든 서비스의 IP 요구 사항을 고려합니다.

1. **서비스 업데이트 무시: ** 새 서브넷 또는 VPC 커넥터를 생성한 후 새 구성을 사용하도록 App Runner 서비스를 업데이트해야 합니다. 이렇게 하지 않으면 소진된 IP 범위가 계속 사용됩니다.

1. **CIDR 블록 오버랩의 오해:** VPC에 보조 CIDR 블록을 추가할 때 기존 블록과 겹치지 않도록 합니다. CIDR 블록이 겹치면 라우팅 충돌과 IP 주소 모호성이 발생할 수 있습니다.

1. **VPC 제한 초과: ** VPC는 최대 5개의 CIDR 블록(기본 블록 1개와 보조 블록 4개)을 가질 수 있습니다. 이러한 제약 내에서 IP 주소 공간 확장을 계획합니다.

1. **서브넷 AZ 배포 무시: ** 새 서브넷을 생성할 때 고가용성 및 내결함성을 위해 여러 가용 영역에 분산되어 있는지 확인합니다.

1. **ENI 제한 검토: ** 인스턴스에 연결할 수 있는 ENIs 수에는 제한이 있습니다. AWS 계정 제한이 계획된 네트워크 인터페이스 사용량과 일치하는지 확인합니다.

이러한 위험을 인식하면 VPC 리소스를 보다 효과적으로 관리하고 App Runner 서비스의 IP 소진 문제를 방지할 수 있습니다.

## 추가 리소스
<a name="troubleshooting-not-enough-ips.common-additional-resources"></a>

1. [ AWS VPC 설명서 ](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)

1. [ CIDR 블록 이해 ](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html#VPC_Sizing)

1. [App Runner VPC 커넥터](network-vpc.md)

## 용어집
<a name="troubleshooting-not-enough-ips.glossary"></a>

1. **ENI:**Elastic Network Interface, AWS의 가상 네트워크 인터페이스.

1. **CIDR:**Classless Inter-Domain Routing, IP 주소를 할당하는 방법입니다.

1. **VPC 커넥터: **App Runner가 VPC에 연결할 수 있도록 하는 리소스입니다.