BYOC Edge provisioning stuck at 409 Conflict on VPC peering handshake

Sorry for the newbie question, my English is not perfect. The BYOC Edge provisioning keeps failing during the initial handshake. Genesys Cloud v24.5.2, testing in EU-Central with the current BYOC onboarding wizard. The POST /api/v2/billing/byoc/edges endpoint just returns a 409 Conflict with resource_already_exists. The dashboard’s showing the edge appliance in a provisioning_error state. In NICE CXone, the cloud connector setup gives a clear IP mismatch warning. Five9 handles the VPC peering much faster, usually returns a 202 with a polling URL. Talkdesk fails silently if the route table is wrong. Here, the bootstrap logs show ERROR: peering_dns_resolution_failed but the Route 53 records look correct. The edge firmware is 2024.4.1. Security groups are open on 5060 and 443. The Architect flow isn’t even deployed yet, just testing the base network connectivity before the media server starts. Console output from the init script shows WARN: nat_traversal_timeout followed by a generic 500 crash. The RFP validation requires sub-50ms latency for SIP trunk registration, so this delay is blocking the whole demo. Not sure if the BYOC onboarding wizard needs a manual trigger or if the API rate limiter is kicking in. The response body just has that conflict error and a correlation ID. Maybe the region mismatch is causing the DNS lookup to time out. The logs show the peering request is stuck in pending_acceptance for over 20 minutes. We’ve checked the IAM roles three times. The edge appliance stays on waiting_for_credentials. The bootstrap script output:

[2024-05-12 14:22:01] INFO: initiating_vpc_handshake
[2024-05-12 14:22:45] ERROR: peering_dns_resolution_failed
[2024-05-12 14:23:10] WARN: nat_traversal_timeout
[2024-05-12 14:23:15] CRITICAL: edge_registration_aborted

The correlation ID is x-genesys-cloud-req-id: 8a3f9c2b-11d4-4e7a. The API docs don’t mention what causes the 409 on a fresh tenant. The media server config in Architect just points to edge.internal.example.com right now. Not sure if the DNS alias needs to match the BYOC account ID exactly. The wizard’s stuck on the IP validation screen.

import http from 'k6/http';
import { check } from 'k6';

const list = http.get('https://api.mypurecloud.com/api/v2/billing/byoc/edges', {
 headers: { 'Authorization': `Bearer ${__ENV.TOKEN}` }
});

const edges = JSON.parse(list.body);
const stuck = edges.entities.find(e => e.status === 'provisioning_error');

if (stuck) {
 http.delete(`https://api.mypurecloud.com/api/v2/billing/byoc/edges/${stuck.id}`);
}

That 409 is literal. You’ve got a zombie edge record lingering from a previous failed handshake. The wizard retries create duplicate collisions if the background job hasn’t flushed the error state yet. Run the snippet above to hunt down the provisioning_error entity. Delete it manually via API. The dashboard might still show the old status for a few seconds due to cache lag. Wait for the delete to return 204. Then kick off the provisioning flow again. The peering handshake fails because the control plane sees the old resource blocking the new VPC route. Check the response payload for the specific conflict reason. The VPC peering ID must match the edge definition exactly. Don’t spam the endpoint or you’ll just generate more conflicts.

It’ll nuke the stuck edge, but the 409 usually comes back if the VpcCidrBlock overlaps with the local gateway range. Fix the EdgeSubnetId mapping in the CDK stack and force a clean state before retrying.