- AWS VPC डैशबोर्ड की जटिल items को समझने के लिए AWS नेटवर्किंग resources के रिश्तों को एक नज़र में देखने वाला mind map बनाया
- Toni Pasanen की AWS Networking Fundamentals को मुख्य reference material मानकर, नेटवर्किंग से जुड़े resources को उनके connection structure के आधार पर व्यवस्थित किया
- AWS नेटवर्किंग के जटिल होने की वजह connection types की विविधता है, जिनमें account-on-premises, account-account, VPC-VPC, subnet-subnet, VPC-Internet, और VPC-AWS service connections शामिल हैं
- परिणाम AWS नेटवर्किंग components को आपस में जोड़कर बनाया गया एक mind map है, और Lucidchart source भी साथ में देखा जा सकता है
- AWS नेटवर्किंग को पहली बार व्यवस्थित रूप से समझने वाले developers इसे यह visually समझने के लिए इस्तेमाल कर सकते हैं कि अलग-अलग resources किस तरह रिश्तों में बंधे हैं
VPC डैशबोर्ड से शुरू हुई उलझन
- मार्च 2023 से पहले तक AWS VPC डैशबोर्ड में क्या हो रहा है, यह समझना मुश्किल था
- बाएं panel में scrollbar लंबा होने जितने items थे, इसलिए यह समझना कठिन था कि हर resource कैसे जुड़ा हुआ है
#参考 सामग्री और整理 की दिशा
- AWS नेटवर्किंग में शामिल कई resources को समझने के लिए Toni Pasanen की AWS Networking Fundamentals का अधिकांश हिस्सा पढ़ा
- किताब पढ़ने के बाद, AWS नेटवर्किंग resources ज्यादा होने की वजह को यह माना कि संभावित connection methods बहुत हैं
AWS नेटवर्किंग में शामिल connection types
- AWS नेटवर्किंग में कई तरह के connections शामिल हैं
- AWS account और on-premises के बीच connection
- account और account के बीच connection
- VPC और VPC के बीच connection
- subnet और subnet के बीच connection
- VPC और Internet के बीच connection
- VPC और किसी खास AWS service के बीच connection
Mind map का परिणाम
- कई टुकड़ों को साथ जोड़ने के लिए AWS नेटवर्किंग concepts को mind map के रूप में बनाया
- मूल editable version Lucidchart link पर देखा जा सकता है
- यह कितना उपयोगी है या इसमें कोई error है या नहीं, इस पर feedback मांगा गया है
1 टिप्पणियां
Hacker News की राय
समझ नहीं आता कि AWS में IAM policies और authentication issues debug करना इतना बिखरा हुआ क्यों है
अगर कोई competitor बनना चाहता है, तो उसे इसी पर focus करना चाहिए। permissions नहीं होने वाली error का कारण खोजते-खोजते मैंने कई घंटे गंवा दिए, और official docs कहते हैं कि SCP, IAM, resource policies वगैरह जैसी लागू हो सकने वाली करीब 8 policies को manually खंगालो
आखिर में Athena और CloudTrail इस्तेमाल करने वाला doc मिल भी जाए, तो आधी requests बिना किसी वजह के गायब रहती हैं, और error message में request ID हो तब भी उससे आसानी से lookup नहीं किया जा सकता। request ID से सीधे lookup करके साफ दिखना चाहिए कि किस policy ने deny किया
शुरू से अंत तक पूरा mess है, और कभी-कभी लगता है कि शायद यही हालत बनाए रखनी पड़ती है ताकि support contracts ज्यादा बेचे जा सकें
personal projects में, बहुत ही rare cases को छोड़कर, मैं लगभग हमेशा ऐसे दूसरे options चुनता हूं जो बेहतर value देते हैं। करीब 10 साल पहले AWS को इस तरह बेचा गया था कि “systems हम manage करेंगे, इसलिए सारे system administrators को निकाल दो”, लेकिन अब अच्छे AWS DevOps engineers महंगे हैं और मिलना भी मुश्किल है, और खासकर बड़े setups में अगर AWS की recommendations ठीक से follow करें तो cost भी बहुत ज्यादा आती है
function app को SQL database access देना हो तो function app का actual name लिखना ही काफी था, और अगर alias हो तो object identifier तक सीमित कर सकते हैं। अब password या certificate जैसी चीजों की जरूरत नहीं, बस काम करता है
authentication package और Application Insights जैसी चीजों को साथ इस्तेमाल करने पर, बशर्ते आपको logs देखना आता हो, “आखिर हुआ क्या” पर ज्यादा देर अटकना बहुत कम होता है
हालांकि Azure में भी landmines कहां हैं यह पहले से जानना पड़ता है, और अगर नहीं जानते तो वैसी ही frustration होती है। Microsoft landmine locations के hints AWS से कहीं बेहतर छोड़ता है, लेकिन आखिरी परदा पार करके cost और complexity को 5–10 गुना बढ़ने से बचाने के लिए 20 साल के experience वाले wizard जैसे व्यक्ति की जरूरत पड़ जाए, इतने कुछ hints सुविधाजनक तरीके से गायब भी रहते हैं
service account debugging में कभी-कभी machine या cluster reboot तक करना पड़ता है, इसलिए और कठिन हो जाता है। अगर कोई “cloud traceroute” जैसा tool हो जो ठीक-ठीक बताए कि issue कहां पैदा हुआ, तो कमाल होगा
fair कहें तो कुछ least privilege tools हैं जिन्हें मैंने अभी तक इस्तेमाल नहीं किया: IAM Access Analyzer https://aws.amazon.com/blogs/security/iam-access-analyzer-ma..., AirIAM https://github.com/bridgecrewio/AirIAM, Google Cloud Policy Simulator https://cloud.google.com/policy-intelligence/docs/iam-simula...
यह वाकई irritate करता है, और design के लिए UX designers और engineers को साथ लगाना चाहिए, लेकिन ऐसा नहीं करते
अगर ऐसी service customers को दी जाती है, तो potentially attackers को भी मिल सकती है, और वास्तव में कुछ companies की security और compliance policies का violation भी हो सकता है
फिर भी, अगर customer “AWS root user के रूप में risky काम करने” जैसे बड़े risk को accept करने वाले document पर sign करे, तो मुझे लगता है कि इसे choose करने का option होना चाहिए
AWS requests बहुत distributed होती हैं, इसलिए conceptually GraphQL जैसी configuration ऐसे system के साथ fit लगती है। यह OTEL जैसे tracing systems से भी बहुत दूर नहीं है
इसलिए AWS से निपटना मुझे पसंद नहीं है। इसे सीखना technical knowledge नहीं, बल्कि product knowledge है
TCP/IP Illustrated सीरीज़ मैंने शुरू से अंत तक पढ़ी और पूरी तरह समझी, और वह knowledge दशकों तक उपयोगी रही
इसके उलट AWS knowledge अपने आप में जटिल तो है, लेकिन हर बार इसे सीखने से मन मना कर देता है। इस diagram को देखकर समझ नहीं आता कि अगर लक्ष्य सरल बनाना था, तो यह कितना सफल हुआ
उदाहरण के लिए, अगर लक्ष्य enterprise customers को virtual enterprise network या virtual data center network दोबारा बनाने देना है, तो वे client TCP stack से कहीं ज़्यादा जटिल होते हैं
सरल इस्तेमाल के लिए defaults भी सरल हैं। जटिल मामलों में AWS-specific product knowledge की ज़रूरत होती है, लेकिन ज़्यादातर बुनियादी concepts दूसरे clouds या on-premises networks के साथ साझा होते हैं। यह Nवीं programming language सीखने जैसा है
TCP/IP network programmer के लिए उपयोगी knowledge है। university networking class में हमने networks, subnets, routing tables, RIP·OSPF·BGP जैसे routing protocols, NAT वगैरह को real equipment पर संभाला था, और Cisco sponsorship काफ़ी थी, इसलिए semester के अंत तक CCNA certification level तक पहुँच गए थे
Cisco products कैसे काम करते हैं जैसी “product knowledge” भी बहुत सीखी, लेकिन ज़्यादातर भूल गया, और core concepts Azure, AWS, GCP में अच्छी तरह transfer हो गए। cloud VPC असली network का virtual counterpart है, जैसे virtual machine असली machine का counterpart होती है
ख़ासकर NAT लोगों को सचमुच बहुत confuse करता है। और भी basic स्तर पर, कई engineers CIDR notation या TCP itself को भी कठिन पाते हैं। जैसे, वे सोचते हैं कि
send()द्वारा दिया गया buffer एक unit के रूप में भेजा जाता है, याrecv()हमेशा पूरी “message” प्राप्त करता है। connection timeout और peer reset के बीच का अंतर भी बहुत लोगों को confuse करता हैहालांकि अच्छा होता अगर ऐसी knowledge की ज़रूरत ही न पड़ती। IPv6 networks को इतना बड़ा बना देता है कि subnet size planning जैसी कई चीज़ें खत्म हो जाती हैं। NAT ठंडे नरक में गायब हो जाए तो भी ठीक है। VPN भी फिर कभी न देखना पड़े तो अच्छा, बस TLS इस्तेमाल कर लें। cloud firewalls में IP address को authentication जैसा इस्तेमाल करना और उससे पैदा होने वाली misleading errors भी हटाना चाहता हूँ। Azure इस मामले में भयानक है
कई professional software की तरह, शुरुआत में ज़रूरत के कारण यह सरल था, लेकिन समय के साथ जटिल हो गया, और fully managed on-demand infrastructure services के आकर्षण और Amazon द्वारा झोंके गए resources की वजह से AWS तेज़ी से फूल गया
hardware को सीधे न संभालने की value अब भी बड़ी है, लेकिन list price के अलावा भी vendor-specific knowledge, जिसे migrate करना मुश्किल होता है, उसकी कीमत साफ़ तौर पर चुकानी पड़ती है
इसके बजाय “internet gateway”, “NAT gateway”, “egress only internet gateway”, “transit gateway” जैसे ढेरों one-off concepts हैं। अंत में शायद engineers की ऐसी पीढ़ी बनेगी जो सिर्फ “cloud” समझती होगी, पर वास्तव में चीज़ें कैसे काम करती हैं, यह नहीं जानती होगी
सभी “undifferentiated” components AWS को सौंप दें और उस business पर focus करें जिसमें वे अच्छे हैं
अगर बस सामान्य global addressing और firewall दिया होता, तो यह ज़्यादातर complexity गायब हो जाती
हम आसानी से भूल जाते हैं कि IP-level internet किसलिए है, और end-to-end architecture कौन-सी समस्याएँ हल करता है
AWS जिसे “Well-Architected™” networking सिखाता है, वह असल में profitable cargo cult के ज़्यादा करीब है, और complexity, एक-दूसरे जैसे दिखने वाले 10.x networks की भूलभुलैया, address conflicts, उन्हें आपस में communicate कराने की कोशिश में crude proxies, कमज़ोर हुई real security, और vendor lock-in की ओर ले जाता है। complexity security की दुश्मन है
ऐसा भी नहीं था कि पुराने system administrators मेरी compensation का आधा या चौथाई पाते थे; आम तौर पर एक व्यक्ति 100 developers को cover करने लायक hardware manage करता था। बाकी लोगों के लिए ऐसे scope expansion और brain damage से बचने का overhead लगभग 0.5% ही था
AWS में फिर से सचमुच expertise की मौत हो रही है
और global addressing और firewall तो public subnets वाली VPC बनाकर और security groups को firewall की तरह इस्तेमाल करके मूल रूप से संभव नहीं हैं क्या? best practice public/private subnets और NAT gateway है, लेकिन सिर्फ security groups पर rely करना असंभव तो नहीं लगता
वह भी global anycast IP के पीछे होता है
इसलिए cloud networking में हमें दिखने वाली बहुत-सी अनावश्यक complexity पैदा होती है
लगता है इस mind map को कुछ networking concepts तक और सरल किया जा सकता है
तब ज़्यादातर रिश्ते और तीर हट जाएंगे, और AWS concepts को दूसरे cloud या home network पर भी map किया जा सकेगा
https://news.ycombinator.com/item?id=18925350 basics को बहुत अच्छे से visualize करने वाला resource है। अगर नेटवर्क क्या है, अंदर और बाहर क्या है—यहीं से शुरू करें, तो mental model काफी आसान हो जाता है, और सारी details जाने बिना भी AWS features काफी समझ में आने लगते हैं
नतीजतन, इसने एक जटिल system को साफ और संक्षिप्त रूप में summarize किया है। अगली बार AWS के जंगल से रास्ता निकालते समय reference के तौर पर काम आएगा
उदाहरण के लिए, availability zone के rectangle के अंदर subnet होता है, उसके बाहर VPC होता है, और वह rectangle region के अंदर होता है। मोटे तौर पर ऐसा ही, लेकिन ज्यादा सुंदर तरीके से बनाया गया: https://images.edrawsoft.com/articles/aws-diagram-examples/e...
cloud के शुरुआती दिनों की वह उत्साहित करने वाली घड़ी याद है, जब AWS networking सरल हुआ करती थी
फिर भी पता था कि यह दिन आएगा। सबके लिए सब कुछ बनने के लिए आखिरकार legacy IPv4 datacenter networking की पागलपन भरी जटिलता को दोहराना ही पड़ता है
हाल में Azure में conceptually एक सरल काम करने की कोशिश की थी। database backups वाले storage account को internet पर expose न रखना, ताकि कोई भी आकर उसे poke न कर सके
लगा बस firewall on कर देना होगा, लेकिन allow list में केवल subnets डाल सकते थे, वह भी हर subnet को अलग-अलग। virtual network नहीं, और दूसरे जगहों पर काम करने वाला “मेरे सभी virtual networks” भी नहीं
Private Endpoint feature भी है, लेकिन वह performance घटाता है और extra cost लगती है। software-defined network settings में address को “public” से “private” में बदलना कठिन होगा, इसलिए शायद cloud fairies को compensate करना पड़ता है
लेकिन असल में यह काम नहीं करता। client को ढूंढने के लिए DNS overwrite करना पड़ता है, तो AD domain से जोड़ा, फिर PaaS service access नहीं कर पाई
आखिरकार ज्यादा cost वाली private DNS zone बनाई, उसे hub network से connect किया, फिर और cost वाली DNS Resolver service जोड़ी, और AD domain चलता रहे इसके लिए ढेर सारे rules set करते-करते एक हफ्ता निकल गया
मूल मकसद सिर्फ यह था कि storage key leak हो जाए तो भी Russian hacker backups तक access न कर पाए। अगले हफ्ते शायद subscription template update कर पाऊं ताकि updated DNS settings वाला virtual network फिर से deploy हो। idempotent नहीं है? शायद अगले साल preview में आ जाए
उसके बाद public-facing target के लिए public gateway या Front Door इस्तेमाल कर सकते हैं। मुझे यह पसंद नहीं, लेकिन पहले भी यह बेहद सरल नहीं था। फर्क इतना है कि enterprise networking की जो पागल अफरा-तफरी पहले सख्ती से operations team का काम थी, अब developers उससे ज्यादा expose हो रहे हैं
DNS settings को मैं जादू कहता हूं, क्योंकि वह हिस्सा मैं खुद नहीं छूता। खासकर App Service और कई subscriptions इस्तेमाल करें तो subnets share नहीं कर सकते, और app slots इस्तेमाल करते हुए IP address space कम न पड़ जाए, इसलिए पहले से planning करनी पड़ती है
Azure में जो बात समझ नहीं आती, वह यह है कि enterprise default “कुछ भी internet पर नहीं” क्यों नहीं है। जब internet पर डालना हो तभी खोलना चाहिए। वैसे भी load balancer जैसी कई configurations करनी पड़ती हैं, इसलिए internet पर लाने की प्रक्रिया अपने-आप में complex है। कम-से-कम enterprise settings में तो default internet के बाहर होना चाहिए
शायद Microsoft Azure certifications बेचता है इसलिए इसे कठिन बनाना पड़ता हो, लेकिन 2023 में default से ही इस complexity की चिंता क्यों करनी पड़े, समझ नहीं आता। बहुत customizable होना ठीक है
यह resource बहुत शानदार है। मुझे लगा है कि Google Cloud docs जरूरत पड़ने पर इस तरह की complexity को comparatively अच्छे से introduce करते हैं, लेकिन इतना complete overview मैंने नहीं देखा
हालांकि image देखने के लिए काफी मशक्कत करनी पड़ी। page पर यह बहुत छोटी है और click भी नहीं होती, new tab में खोलने पर imgur जैसी बेकार page पर जाती है और फिर भी छोटी ही दिखती है। आखिर image download करनी पड़ी, तभी ठीक से देख पाया
यह resource कमाल का है। cloud products या दूसरे concepts सीखते समय mind maps और diagrams कितने powerful होते हैं, यह अच्छी तरह दिखाता है
AWS certification की तैयारी करते समय मैंने इन्हें बहुत इस्तेमाल किया था; लंबी notes लिखने के बावजूद, pages की series के रूप में देखने की तुलना में map में connected services देखने पर बहुत बेहतर समझ आया। हालांकि हर व्यक्ति का सीखने का तरीका अलग होता है
इस thread की आलोचना पूरी तरह समझ नहीं आ रही। AWS द्वारा दी जाने वाली networking systems में से ज्यादातर वे हैं जिन्हें जरूरत पड़ने पर इस्तेमाल किया जाता है
यह elegant नहीं है, लेकिन काम कर देता है। ऊपर से AWS-specific components में से काफी सीधे actual networking concepts से match होते हैं। AZ cage है, VPC VLAN है, PL मोटे तौर पर accounts के बीच P2P VPN जैसा है
बाकी ज्यादातर भी वैसे ही सामान्य networking components हैं जो बड़े-scale environments में दिखते हैं
मेरी company काफी complex global network चलाती है, और कई PoPs से DX के जरिए AWS से connect होती है। हम इस diagram में मौजूद हर चीज इस्तेमाल कर रहे हैं और हर component का clearly defined purpose है
अगर यह diagram जरूरत से ज्यादा complex लगता है, तो संभवतः आप इनमें से सब इस्तेमाल नहीं कर रहे, या इन्हें intended purpose के अनुसार नहीं इस्तेमाल कर रहे, या फिर आप network engineer नहीं हैं
क्या कोई इस image को सच में पढ़ पा रहा है? desktop पर भी readable resolution में नहीं देख पा रहा
https://miparnisariblog.files.wordpress.com/2023/03/aws-netw... भी अब भी web page ही है, और image बड़ी तो है लेकिन ज्यादा पढ़ने लायक नहीं होती
फिर भी save करने पर कम-से-कम काम करता है। उसके बाद बड़ा screen चाहिए। size 7,763 × 4,684 pixels है
बेहद जटिल दिखता है। तीन बड़े cloud providers में से मैं सिर्फ GCP जानता हूँ, और वहाँ भी networking आसान नहीं है, लेकिन फिर भी कुछ हद तक intuitive और consistent है
multi-cloud experience ज़्यादा रखने वाला कोई व्यक्ति अगर Big 3 के हिसाब से internal/external communication setup की आसानी और कठिनाई की तुलना कर दे, तो अच्छा होगा
यह कोई चौंकाने वाली बात नहीं है, क्योंकि ज़्यादातर के networking standards में भी direct equivalents हैं। दोनों मूल रूप से software-defined networking की दुनिया को देखने के अलग-अलग नज़रिए ही हैं