Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 18 additions & 0 deletions docs/cloud/connections.md
Original file line number Diff line number Diff line change
Expand Up @@ -50,6 +50,24 @@ and then accept the peering connection in your AWS account console:
- Modify your relevant security groups to allow traffic from the Dragonfly Cloud private network CIDR.
- Observe the connection becoming **Active** after a few moments in the Dragonfly Cloud console.

:::warning Avoid overlapping routes
AWS route tables use **longest prefix match**, so a more specific (smaller) route always takes priority over a
broader one, even if the broader route was added for the peering connection.

If an existing route table already has a route whose destination CIDR falls **within** the Dragonfly Cloud
private network CIDR, it will silently override the peering route for that range and break connectivity, even
though both routes appear active.

For example, if the Dragonfly Cloud private network CIDR is `192.168.0.0/18`, do **not** also have a route for
`192.168.0.0/24` (or any other subset of that range) pointing to a different target, such as a NAT gateway,
internet gateway, or another peering/transit gateway connection. Traffic destined for addresses in `192.168.0.0/24`
would be sent to that route instead of the AWS peering connection, causing the data store to become unreachable
from those subnets.
Comment on lines +64 to +65

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

1. Valid alternate routes misclassified 🐞 Bug ≡ Correctness

The warning claims any more-specific route to a different target breaks connectivity, but
longest-prefix matching only proves that traffic bypasses the peering route; a transit gateway or
another connection may intentionally provide a valid path to the destination. This blanket
prohibition can make users remove a working alternate route even when the data store remains
reachable through it.
Agent Prompt
## Issue description
The warning equates bypassing the AWS peering route with loss of connectivity, although a more-specific route can intentionally reach the destination through another target.

## Issue Context
Longest-prefix matching establishes which route wins, not whether the winning target provides connectivity. Describe the route as conflicting only when its target does not provide the intended valid path, and avoid stating that every alternate target makes the data store unreachable.

## Fix Focus Areas
- docs/cloud/connections.md[57-68]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Before adding the peering route, check every route table associated with your subnets for any existing, more
specific routes that overlap with the Dragonfly Cloud private network CIDR, and remove or adjust them as needed.
:::

You can read more about AWS peering
connections [here](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html).
If you haven't done so already, create a data store with a private network and start building your applications with
Expand Down
Loading