ਦੋ 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 ਕਿਉਂ ਨਹੀਂ ਵਰਤ ਸਕਦਾ, ਤਾਂ ਉਹ ਰਿਕਾਰਡ ਹੀ ਜਵਾਬ ਹੈ, ਅਤੇ ਅਗਲੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਉਹੀ ਤਿੰਨ ਵਿਕਲਪ ਦੁਬਾਰਾ ਬਹਿਸ ਕਰਨ ਤੋਂ ਇਹ ਤੁਹਾਨੂੰ ਬਚਾਉਂਦਾ ਹੈ।