Repository navigation
docs: November freshness pass (1:1 NAT, DX Manchester and Bangalore) - #19
Conversation
…oad map The overlapping-CIDR advice (plan advisor, P7, docs 05/06/12/13) now points whole-network overlap at 1:1 NAT on the hub attachment. Road-map prices and quotas were re-checked against the Price List API on 2026-11-09 and are unchanged.
…f dates DX prices, quotas, locations and SLA were re-checked on 2026-11-09 and are unchanged apart from the two October 100G expansions.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars.
 |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| @@ -1,8 +1,8 @@ | |||
| /** The date every fact and list price on the site was last verified. */ | |||
| export const AS_OF = "2026-10-10"; | |||
| export const AS_OF = "2026-11-09"; | |||
There was a problem hiding this comment.
AS_OF and DX_AS_OF are bumped to 2026-11-09, but other places that state the date were not. README.md:35 and README.ja.md:35 still say 2026-10-10. README.md:59 and README.ja.md:59 still say 2026-10-12. docs/README.md:3 says "All pages were verified on 2026-10-10". docs/direct-connect/{05,06,07,08,09,11,12}-*.md still say "Last verified: 2026-10-12", and docs/direct-connect/02-connections.md:63 still says "as of 2026-10-12". The site and the notes now disagree about when the facts were verified. Either update all of them, or don't bump a date for pages that weren't re-read.
Also, 2026-11-09 is today's date. The diff changes no price or quota value, so nothing in it shows the full re-check actually happened (every VPN/TGW/PrivateLink/Resolver price, DX locations, SLA). The freshness checklist in .github/workflows/freshness.yml lists far more than this PR touches. If only the 1:1 NAT and two DX locations were checked, the "re-checked" wording overclaims.
There was a problem hiding this comment.
Fixed in 4009eac. Prices and quotas were re-checked against the Price List API (AmazonVPC 2026-11-05, AWSDirectConnect 2026-11-08, AmazonRoute53 2026-11-04), and the DX quotas, locations and SLA against their pages. All were unchanged, which is why the diff only touches dates. The READMEs, docs/README.md and the DX pages that were re-checked (01, 02, 07, 12) now say what was re-checked on 2026-11-09. Pages that were not re-checked keep their 2026-10-12 "Last verified" line.
|
|
||
| - First choice, **expose services rather than networks**: PrivateLink endpoint services (NLB-fronted), or PrivateLink resource endpoints and VPC Lattice resource configurations (2024-12). These reach a database or IP in an overlapping network without routing the whole CIDR. | ||
| - Second choice, **private NAT gateway**: add a routable secondary CIDR, use the private NAT gateway for source NAT and an internal ALB or NLB for destination NAT, and route through TGW or VGW. This is the pattern in the multi-VPC whitepaper and the re:Post Knowledge Center. | ||
| - When whole networks must talk, **1:1 NAT on the TGW or Cloud WAN attachment** (2026-10-23): a per-attachment rule maps an original CIDR to a NAT CIDR of the same prefix length, statelessly and in both directions, so either side can start connections. Supported on TGW VPC, DXGW, Site-to-Site VPN, Connect and peering attachments; IPv4 only; not on a VPC attachment with appliance mode. |
There was a problem hiding this comment.
The list of supported attachment types for 1:1 NAT differs between pages.
docs/12-security-and-operations.mdadds VPN Concentrator and says "not Client VPN".- This line lists VPC, DXGW, Site-to-Site VPN, Connect and peering.
docs/06-routing-and-path-selection.mdlists VPC, DXGW, VPN, Connect and peering.
These are recalled details and should be sourced and made the same everywhere. The same applies to "IPv4 only" and "not on appliance mode". The only link is the What's New URL in the timeline, whose slug I could not confirm. Cite the TGW user guide page for the NAT feature in the Sources sections of 05, 06, 12 and 13. docs/05-hubs.md has no source for it at all.
The line also says "so either side can start connections". That holds only if both sides get translation rules, which the text doesn't say.
There was a problem hiding this comment.
Fixed in 4009eac. Docs 05, 06, 12 and 13 now use one list taken from https://docs.aws.amazon.com/vpc/latest/tgw/tgw-nat.html (VPC, DXGW, Site-to-Site VPN incl. Private IP VPN, Connect, peering, VPN Concentrator; not Client VPN; IPv4 only; not with appliance mode), and each links that page.
| | 2026-03 | Equinix SY5, Sydney (tenth in Australia) | 10G, 100G with MACsec | | ||
| | 2026-04 | Datacom Orbit DH6, Auckland (100G expansion) | 100G with MACsec | | ||
| | 2026-07 | Cirion, Lima, Peru (100G expansion, first 100G/MACsec in Peru) | 100G with MACsec | | ||
| | 2026-10 | Equinix MA3, Manchester (100G expansion, third 100G location in England); Netmagic DC2, Bangalore (100G expansion) | Manchester 10G, 100G with MACsec; Bangalore 100G (the locations page marks MACsec) | |
There was a problem hiding this comment.
This row makes several specific claims that look recalled, not sourced: "third 100G location in England", "Manchester 10G, 100G with MACsec", and the facility names "Equinix MA3" and "Netmagic DC2". The Bangalore MACsec status is hedged as "the locations page marks", but the Manchester one isn't. The two What's New links (2026-10-21 and 2026-10-22) appear only in the Sources list of 12-timeline.md. Confirm each claim against them or the locations page. Also, 01-overview.md:101 and 12-timeline.md:82 fold both locations into "2026-10" lists without any of this detail, so keep them consistent with whatever is verified here.
There was a problem hiding this comment.
Fixed in 4009eac. The facility names, the Manchester 10G/100G MACsec claim and Bangalore 100G come from the two What's New posts, which the row now links. I dropped "third 100G location in England" because I couldn't confirm it on a re-read, and the Bangalore MACsec note because that post doesn't mention MACsec.
| en: "PrivateLink or VPC Lattice resource configurations first, a private NAT gateway second, re-IP from an IPAM plan in the long run. No hub can route between identical CIDRs.", | ||
| ja: "まず PrivateLink か VPC Lattice のリソース設定、次にプライベート NAT ゲートウェイ、長期的には IPAM 計画で再採番。同一 CIDR 間はどのハブもルーティングできない。", | ||
| en: "PrivateLink or VPC Lattice resource configurations for single services; for whole networks, 1:1 NAT on the Transit Gateway or Cloud WAN attachment (2026-10) maps each side to its own NAT CIDR. Re-IP from an IPAM plan in the long run. No hub routes between identical CIDRs untranslated.", | ||
| ja: "単一サービスなら PrivateLink か VPC Lattice のリソース設定。ネットワーク同士なら Transit Gateway / Cloud WAN のアタッチメントの 1:1 NAT (2026-10) で各側に専用の NAT CIDR を割り当てる。長期的には IPAM 計画で再採番。変換なしで同一 CIDR 間をルーティングできるハブはない。", |
There was a problem hiding this comment.
The EN and JA texts differ. EN ends "No hub routes between identical CIDRs untranslated", and JA says "変換なしで同一 CIDR 間をルーティングできるハブはない", which is the same. But "maps each side to its own NAT CIDR" assumes both sides are translated. The 1:1 NAT mapping is per attachment, and the docs say "give one side a distinct NAT CIDR", so the wording is inconsistent across files (docs/05-hubs.md says one side, here and in PlanSection.tsx it implies both). Pick one. The EN "Re-IP" sentence now starts a new sentence while the JA folds it in with a period, which is fine, but "(2026-10)" is the only date hint. The statement that this applies to "whole networks" also drops the appliance-mode and IPv4-only limits from the docs, so the advisor can recommend it where it doesn't work.
There was a problem hiding this comment.
Fixed in 4009eac. EN and JA now both say "the overlapping side, or each side", which matches docs/05, and they keep the IPv4-only and appliance-mode limits.
|
Review of the date bump, 1:1 NAT additions and two new DX locations. No injection or workflow issues; this change only touches docs, data and UI strings. Four findings are posted inline:
|
… location detail Addresses review on #19: one sourced list of 1:1 NAT attachment types across docs 05/06/12/13, the advisor keeps the IPv4-only and appliance-mode limits, the READMEs and re-checked pages say what was re-checked on 2026-11-09, and the Manchester/Bangalore row links its What's New posts instead of repeating unsourced detail.
| @@ -1,8 +1,8 @@ | |||
| /** The date every fact and list price on the site was last verified. */ | |||
| export const AS_OF = "2026-10-10"; | |||
| export const AS_OF = "2026-11-09"; | |||
There was a problem hiding this comment.
Bumping AS_OF and DX_AS_OF to 2026-11-09 makes the site say everything was verified that day. The docs pages disagree: docs/11-edge-and-data-paths.md:275 and docs/12-security-and-operations.md:252 still list Price List fetches dated 2026-10-10, and several docs/direct-connect/* pages still say "Last verified: 2026-10-12". Either the pages were re-checked, in which case update their source dates, or the as-of claim is broader than what was done. I can't confirm the "no price changed" statement in dxPricing.ts from the repo.
|
Review of the 1:1 NAT and 2026-11-09 re-check changes. EN/JA parity looks fine in
|
… as-of footer The footer and the DX as-of line now say the date covers prices, quotas and launches; each research note keeps its own verification date.
|
Addressed the second review in 9f3cf40: HubsSection, docs/05 and docs/14 now mention 1:1 NAT where they describe TGW and identical CIDRs. The site footer, the DX as-of line and the asOf.ts comments now say the date covers prices, quotas and launches (plus locations and the SLA for DX), and that each research note keeps its own verification date. The 1:1 NAT limits are from https://docs.aws.amazon.com/vpc/latest/tgw/tgw-nat.html and the two DX dates are from their What's New posts; I fetched all three while making the change. |
| why: { | ||
| en: "PrivateLink or VPC Lattice resource configurations first, a private NAT gateway second, re-IP from an IPAM plan in the long run. No hub can route between identical CIDRs.", | ||
| ja: "まず PrivateLink か VPC Lattice のリソース設定、次にプライベート NAT ゲートウェイ、長期的には IPAM 計画で再採番。同一 CIDR 間はどのハブもルーティングできない。", | ||
| en: "PrivateLink or VPC Lattice resource configurations for single services; for whole networks, 1:1 NAT on the Transit Gateway or Cloud WAN attachment (2026-10) maps the overlapping side, or each side, to its own NAT CIDR (IPv4 only, not with appliance mode); re-IP from an IPAM plan in the long run. No hub routes between identical CIDRs untranslated.", |
There was a problem hiding this comment.
The "(IPv4 only, not with appliance mode)" limits are attached to "the Transit Gateway or Cloud WAN attachment". The TGW user guide, which is the only source cited, documents them for TGW only. docs/05, 06, 12 and 13 all scope the same list to "On TGW". Nothing in the repo sources the Cloud WAN limits. Either scope the parenthetical to TGW or cite a Cloud WAN source. The JA string on line 339 has the same drift.
There was a problem hiding this comment.
Fixed in a1844f6: EN and JA now scope the limits to TGW, as docs 05, 06, 12 and 13 do.
|
The 1:1 NAT limits in the docs match the TGW user guide (IPv4 only, no appliance mode, the attachment list, same-length prefixes). EN and JA agree on the strings I checked. I couldn't read the diff itself because One finding: the limits in I didn't re-check the Manchester and Bangalore 100G entries or the 2026-10-23 launch date. Only the TGW user guide was fetched. |
| * verification date. | ||
| */ | ||
| export const AS_OF = "2026-11-09"; | ||
|
|
There was a problem hiding this comment.
AS_OF moves to 2026-11-09, but most docs/ pages (01, 04, 08, 11 and others) still say 2026-10-10 and were not re-checked. The footer now says "Prices, quotas and launches checked ... as of 2026-11-09". That claim covers every page, and the diff only shows a re-check of the pages it edits. Either record what was re-checked per page, or keep the footer date at the date the full pass was done.
| why: { | ||
| en: "PrivateLink or VPC Lattice resource configurations first, a private NAT gateway second, re-IP from an IPAM plan in the long run. No hub can route between identical CIDRs.", | ||
| ja: "まず PrivateLink か VPC Lattice のリソース設定、次にプライベート NAT ゲートウェイ、長期的には IPAM 計画で再採番。同一 CIDR 間はどのハブもルーティングできない。", | ||
| en: "PrivateLink or VPC Lattice resource configurations for single services; for whole networks, 1:1 NAT on the Transit Gateway or Cloud WAN attachment (2026-10) maps the overlapping side, or each side, to its own NAT CIDR (on TGW: IPv4 only, not with appliance mode); re-IP from an IPAM plan in the long run. No hub routes between identical CIDRs untranslated.", |
There was a problem hiding this comment.
The title just above (line 335, "Expose services, not networks") now contradicts this text, which recommends 1:1 NAT for whole networks. PlanSection and docs/13 rule 16 were reworded, but the title was not. Please reword it to match. Check advisor.test.ts too, since it asserts on overlap behaviour.
| - Blackhole routes drop matching traffic and are the standard way to isolate segments. | ||
| - The TGW shows only the preferred route for a prefix. A backup (for example VPN behind DX) appears only after the preferred route is withdrawn. | ||
| - If a new VPC has the same CIDR as an already attached VPC, its CIDR is not propagated. TGW cannot route between identical CIDRs. | ||
| - If a new VPC has the same CIDR as an already attached VPC, its CIDR is not propagated. TGW cannot route between identical CIDRs; since 2026-10-23, 1:1 NAT on the attachment can map the overlapping side (or each side) to its own NAT CIDR ([TGW user guide](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-nat.html)). |
There was a problem hiding this comment.
The 1:1 NAT claims here (and at lines 259 and 265) have no entry in this page's Sources section. The TGW NAT user guide (tgw-nat.html) and the What's New post are cited inline only. The same applies to docs 06, 12 and 13, which repeat the attachment-type list. The project promises that every page ends with its sources, so please add them. Also, every limit listed (attachment types, IPv4 only, no appliance mode) is TGW-specific, while the claim at lines 259 and 162 covers "TGW and Cloud WAN" with no Cloud WAN doc cited. Cite a Cloud WAN source or limit the claim to what is sourced.
|
Reviewed the 1:1 NAT additions and the 2026-11-09 as-of bump. EN/JA strings agree, and I found no injection or workflow issues. Three findings are posted inline:
I could not check the AWS facts (the 2026-10-23 date, the attachment-type list, the IPv4-only and appliance-mode limits) against live AWS sources. Please confirm them against |
|
Addressed in 8db8852: docs 05, 06, 12 and 13 now list the TGW 1:1 NAT user guide and the What's New post under Sources, and the advisor card is retitled "Expose services; translate networks". I fetched tgw-nat.html myself when I made the change, and the date, the attachment list and the limits match it. The as-of date covers the monthly checklist only (prices, quotas, launches). The footer says each research note keeps its own date, so I left the page-level 2026-10-10 lines alone on purpose. |
|
No blocking findings. EN and JA agree in every changed string (Footer, DX ui, HubsSection, PlanSection, advisor, timeline, both READMEs). The 1:1 NAT limits match the TGW user guide page cited in I could not confirm two things:
The 2026-11-09 "re-checked unchanged" statements for prices, quotas, locations and the SLA ( |
Monthly freshness pass for both pages. Closes #13.
Prices, quotas and the DX SLA were re-checked against the AWS Price List API (AmazonVPC 2026-11-05, AWSDirectConnect 2026-11-08, AmazonRoute53 2026-11-04) and the AWS docs; nothing changed. Three launches since the last pass are added:
AS_OFandDX_AS_OFmove to 2026-11-09.Not verified: 1:1 NAT pricing (the docs say "Not checked"), and launches between 2026-10-10 and 10-27 were found through AWS doc search rather than the What's New feed.
Verification (local)