ಎರಡು AWS ಖಾತೆಗಳು, ಒಂದು ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್: ಯಾವ ಮಾರ್ಗ?
ಹಂಚಿಕೆಯ Transit Gateway, ಎರಡು ಸ್ವತಂತ್ರ VPNಗಳು ಅಥವಾ ಒಂದು ಸಂಕುಚಿತ ಪ್ರಾಕ್ಸಿ: ಇಂದು ಯಾವ ಮಾರ್ಗವನ್ನು ಸೇರಿಸುವುದು ಸುಲಭ ಎಂಬುದರ ಬದಲು ಮಾಲೀಕತ್ವ ಮತ್ತು ಪರಿಣಾಮದ ವ್ಯಾಪ್ತಿಯ ಆಧಾರದಲ್ಲಿ ಆಯ್ಕೆಮಾಡಿ.
ಸ್ಪಷ್ಟ ಚೌಕಟ್ಟು peering ವಿರುದ್ಧ VPN, ಮತ್ತು ಅದು ತಪ್ಪು ಚೌಕಟ್ಟು. ಪೀರ್ ಮಾಡಿದ VPC ತನ್ನ ನೆರೆಯವರ VPN ಸಂಪರ್ಕವನ್ನು ಅಂಚಿನಿಂದ ಅಂಚಿಗೆ ರೂಟಿಂಗ್ಗಾಗಿ ಎರವಲು ಪಡೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಆ ಆಯ್ಕೆ ಎಂದೂ ಮೇಜಿನ ಮೇಲಿರಲಿಲ್ಲ, ರೂಟ್ ಕೋಷ್ಟಕ ಏನೇ ಸೂಚಿಸಲಿ. ನೀವು ನಿಜವಾಗಿ ಆಯ್ಕೆ ಮಾಡುವುದು ಹಂಚಿಕೆಯ ನೆಟ್ವರ್ಕ್ ಹಬ್, ಎರಡು ಸ್ವತಂತ್ರ VPN ಮಾರ್ಗಗಳು ಮತ್ತು ಒಂದು ಸಂಕುಚಿತ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರವೇಶದ್ವಾರದ ನಡುವೆ. ಪ್ರತಿಯೊಂದೂ ರೂಟಿಂಗ್ನ ಮಾಲೀಕತ್ವದ ಬಗ್ಗೆ ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ.
ಮೂರು ಆಯ್ಕೆಗಳು ಮತ್ತು ಆಯ್ಕೆ ಅಲ್ಲದ ಒಂದು
peering ಕಲ್ಪನೆಯನ್ನು ಅಳಿಸುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಿ, ನಂತರ ಉಳಿದದ್ದನ್ನು ರೇಖಾಚಿತ್ರದ ಸರಳತೆಗಿಂತ ಮಾಲೀಕತ್ವದ ಆಧಾರದಲ್ಲಿ ಹೋಲಿಸಿ. ಕೆಳಗಿನ ಕೋಷ್ಟಕ ಸಂಕ್ಷಿಪ್ತ ರೂಪದಲ್ಲಿ ನಿರ್ಣಯ.
| Option | Who owns the path | Main cost |
|---|---|---|
| Shared transit gateway | Hub owner, used by both VPC owners | Shared blast radius, attachment and data-processing charges |
| Separate VPNs per account | Each account independently | Peer capacity, duplicated tunnels, overlapping prefixes to coordinate |
| Application proxy | The account that hosts the intermediary | New auth, logging and availability surface, and only one service |
ಖಾತೆ A ಗೆ ಇಡೀ ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ಗೆ ತಲುಪುವಿಕೆ ಬೇಕಾದರೆ, ಪ್ರಾಕ್ಸಿ ಸಾಲು ತಪ್ಪು ಆಕಾರದಲ್ಲಿದೆ. ಖಾತೆ A ಗೆ ಒಂದು API ಬೇಕಾದರೆ, ಮೊದಲ ಎರಡು ಸಾಲುಗಳು ಅಗತ್ಯ ಕೇಳಿದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚು ನೆಟ್ವರ್ಕ್.
ಹಂಚಿಕೆಯ Transit Gateway ಯಾವಾಗ ಗೆಲ್ಲುತ್ತದೆ
Transit Gateway ಪ್ರತಿ VPC ಮತ್ತು VPN ಅನ್ನು ಪ್ರತ್ಯೇಕ ನೆಟ್ವರ್ಕ್ಗಳಾಗಿ ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಮತ್ತು ಖಾತೆಗಳ ನಡುವಿನ ಹಂಚಿಕೆ VPC ಮಾಲೀಕರಿಗೆ ಖಾತೆಗಳನ್ನು ವಿಲೀನಗೊಳಿಸದೆ ಹಬ್ ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಅದೇ ಆಕರ್ಷಣೆ: ಸ್ಥಳೀಯ ಪ್ರಿಫಿಕ್ಸ್ಗಳು AWS ನೆಟ್ವರ್ಕ್ಗಳನ್ನು ಭೇಟಿಯಾಗುವ ಒಂದು ಸ್ಥಳ, ಮತ್ತು ಯಾವ ಲಗತ್ತು ಯಾವ ಮಾರ್ಗವನ್ನು ಕಲಿಯುತ್ತದೆ ಎಂದು ಯೋಚಿಸುವ ಒಂದು ಸ್ಥಳ.
ಎಲ್ಲವನ್ನೂ ಸಂಪರ್ಕಿಸುವುದು ಎಲ್ಲವನ್ನೂ ಅನುಮತಿಸುವುದಲ್ಲ. ಸಂಯೋಜನೆ ಮತ್ತು ಪ್ರಸರಣ ಯಾವ ಲಗತ್ತು ಯಾವ ರೂಟ್ ಕೋಷ್ಟಕವನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಎರಡು VPC ಪ್ರಿಫಿಕ್ಸ್ಗಳು ಪ್ರತಿಯೊಂದೂ ಸ್ಥಳೀಯ ಸೇವೆಯನ್ನು ತಲುಪಬಹುದು, ಆದರೆ ಅವುಗಳ ಪರಸ್ಪರ ಪ್ರವೇಶ ಹಬ್ನ ವಿನ್ಯಾಸದಿಂದ ಹೊರಗಿರುತ್ತದೆ. ಸ್ಥಳೀಯ ಬದಿಗೆ ಇನ್ನೂ AWS ಪ್ರಿಫಿಕ್ಸ್ಗಳಿಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗಗಳು ಬೇಕು, ಮತ್ತು ಅದು ಇನ್ನೊಂದು ತಂಡದ ಬದಲಾವಣೆ ಟಿಕೆಟ್.
ವೆಚ್ಚವು ಆರ್ಥಿಕವಷ್ಟೇ ಸಾಂಸ್ಥಿಕವೂ ಆಗಿದೆ. ಹಬ್ನ ಮಾಲೀಕರು ಇತರ ತಂಡಗಳು ಅವಲಂಬಿಸಿರುವ ರೂಟಿಂಗ್ ಸಂಬಂಧಗಳನ್ನು ನಿಯಂತ್ರಿಸುತ್ತಾರೆ, ಆದ್ದರಿಂದ ಒಂದು ಲಗತ್ತಿನಲ್ಲಿನ ಬದಲಾವಣೆ ಹಬ್ ಮಾಲೀಕರು ಎಂದೂ ಕೇಳದ ಸೇವೆಯ ಸಂಚಾರವನ್ನು ಸರಿಸಬಹುದು. ಲಗತ್ತು ಗಂಟೆಗಳು ಮತ್ತು ಡೇಟಾ ಸಂಸ್ಕರಣೆ ನೀವು ಸಂಪರ್ಕಿಸುವ ಪ್ರತಿ ನೆಟ್ವರ್ಕ್ ಜೊತೆ ಸೇರುತ್ತವೆ, ಆದ್ದರಿಂದ ಹಬ್ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಅವನ್ನು ನಡೆಸುವ ತಂಡಕ್ಕಿಂತ ವೇಗವಾಗಿ ಬೆಳೆಯುತ್ತವೆ.
ಪ್ರತ್ಯೇಕ VPN ಅಥವಾ ಸಂಕುಚಿತ ಪ್ರಾಕ್ಸಿ ಯಾವಾಗ ಗೆಲ್ಲುತ್ತದೆ
ಎರಡು ಸ್ವತಂತ್ರ VPN ನೈಜ ಕಾರ್ಯಾಚರಣಾ ಗಡಿಗಳಿರುವ ಸಣ್ಣ ನಿಯೋಜನೆಗೆ ಸರಿಹೊಂದುತ್ತವೆ: ಪ್ರತಿ ಖಾತೆ ತನ್ನದೇ ಸುರಂಗಗಳನ್ನು ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ಯಾವುದೂ ರೂಟ್ ಕೋಷ್ಟಕವನ್ನು ಸಂಪಾದಿಸಿ ಇನ್ನೊಂದನ್ನು ಒಡೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ಮಿತಿಗಳು ಸ್ಥಳೀಯ ಬದಿಯಲ್ಲಿವೆ. ಜೋಡಿ ಗೇಟ್ವೇಗೆ ಹೆಚ್ಚುವರಿ ಸುರಂಗಗಳಿಗೆ ಸಾಮರ್ಥ್ಯ ಬೇಕು, ವಿಳಾಸ ಯೋಜನೆಗಳು ಜೋಡಣೆಯಾಗಬಾರದು, ಮತ್ತು ಅದೇ ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ಜಾಹೀರಾತು ಮಾಡುವ ಎರಡು ಸಂರಚನೆಗಳಿಗೆ ನಿರೀಕ್ಷೆಯ ಬದಲು ಉದ್ದೇಶಪೂರ್ವಕ ಆದ್ಯತೆ ಬೇಕು.
ಪ್ರಾಕ್ಸಿ ಅತ್ಯಂತ ಸಂಕುಚಿತ ಇಂಟರ್ಫೇಸ್. ಖಾತೆ A ಗೆ ಖಾತೆ B ಯಲ್ಲಿ ಒಂದು ಡೇಟಾಬೇಸ್ ಅಥವಾ ಒಂದು API ಬೇಕಾದರೆ, ಸೀಮಿತ ಮಧ್ಯವರ್ತಿ ನಿಮಗೆ ತನ್ನದೇ ದೃಢೀಕರಣ, ಲಾಗಿಂಗ್ ಮತ್ತು ಲಭ್ಯತೆಯ ಕಥೆಯೊಂದಿಗೆ ನಿರ್ಧಿಷ್ಟ ಪ್ರವೇಶವನ್ನು ನೀಡುತ್ತದೆ. ಇದು ಅತ್ಯಂತ ದುರುಪಯೋಗವಾಗುವ ಆಯ್ಕೆಯೂ ಆಗಿದೆ: ಪ್ರತಿ ಖಾಸಗಿ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಮುಂದೂಡುವ ಮಧ್ಯವರ್ತಿ ಹೆಚ್ಚುವರಿ ಹಂತಗಳೊಂದಿಗೆ ಅನಿಯಂತ್ರಿತ ರಿಲೇ ಆಗಿದೆ, ಮತ್ತು ಬೇರೆ ಯಾವುದಕ್ಕೂ ಇದು VPC ಯಿಂದ ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ಗೆ ಪಾರದರ್ಶಕ ಸಾಗಣೆಯಂತೆ ವರ್ತಿಸುವುದಿಲ್ಲ.
ಇದೆಲ್ಲದಕ್ಕೂ ಮೊದಲು VPC peering ನ ಮಿತಿಗಳನ್ನು ಓದುವುದು ಯೋಗ್ಯ, ಏಕೆಂದರೆ ನಾಲ್ಕನೇ ಕಲ್ಪನೆ ಏಕೆ ಪದೇ ಪದೇ ಮರಳುತ್ತದೆ ಮತ್ತು ಏಕೆ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂಬುದನ್ನು ಅವು ವಿವರಿಸುತ್ತವೆ.
ಅಗತ್ಯವನ್ನು ಪೂರೈಸುವ ಅತ್ಯಂತ ಸಂಕುಚಿತ ಇಂಟರ್ಫೇಸ್ ಆಯ್ಕೆಮಾಡಿ
ಪ್ರಶ್ನೆಗಳನ್ನು ಜೋಡಿಸಿ: A ಗೆ ಒಂದು ನೆಟ್ವರ್ಕ್, ನೆಟ್ವರ್ಕ್ಗಳ ಗುಂಪು ಅಥವಾ ಒಂದು ಸೇವೆ ಬೇಕೇ? ಸ್ಥಳೀಯ ತಂಡ ಒಂದು ಮಾರ್ಗ ಬಯಸುತ್ತದೆಯೇ ಅಥವಾ ಹಲವನ್ನು? ಇನ್ನೊಂದು ತಂಡದ ಸಂಚಾರದ ರೂಟಿಂಗ್ ಅನ್ನು ಯಾರು ಬದಲಿಸಬಹುದು? ಅತ್ಯಂತ ಸಂಕುಚಿತ ಇಂಟರ್ಫೇಸ್ ಉತ್ಪಾದಿಸುವ ಮೊದಲ ಉತ್ತರವೇ ವಾಸ್ತುಶಿಲ್ಪ, ಮತ್ತು ಅದರ ನಂತರದ್ದೆಲ್ಲ ಅನುಷ್ಠಾನ.
ಉತ್ತರವನ್ನು ಪ್ರಿಫಿಕ್ಸ್ ಯೋಜನೆ, ಮಾರ್ಗಗಳ ಮಾಲೀಕತ್ವ, ಸುರಂಗಗಳು ಅಥವಾ ಲಗತ್ತುಗಳ ಪಟ್ಟಿ ಮತ್ತು ಪ್ರತಿ ಬದಿ ನಿರೀಕ್ಷಿಸುವ ವೈಫಲ್ಯ ವಿಧಾನದೊಂದಿಗೆ ದಾಖಲಿಸಿ. ನಂತರ ಯಾರಾದರೂ ಖಾತೆ A ಸರಳವಾಗಿ ಖಾತೆ B ಯ VPN ಏಕೆ ಬಳಸಲಾಗದು ಎಂದು ಕೇಳಿದಾಗ, ಆ ದಾಖಲೆಯೇ ಉತ್ತರ, ಮತ್ತು ಮುಂದಿನ ಯೋಜನೆಯಲ್ಲಿ ಅದೇ ಮೂರು ಆಯ್ಕೆಗಳನ್ನು ಮತ್ತೆ ಚರ್ಚಿಸುವುದನ್ನು ಇದು ತಪ್ಪಿಸುತ್ತದೆ.