EC2 నుండి ప్రైవేట్ RDS: అదే VPC, peering లేదా మరేదైనా?

డెవలపర్ ల్యాప్టాప్ సిబ్బంది VPN ద్వారా ప్రైవేట్ RDS ఇన్స్టాన్స్ను చేరుకుంటుంది, కానీ EC2లోని అప్లికేషన్ అసలు కనెక్ట్ కాలేదు. ఇది విరిగిన డిప్లాయ్మెంట్ కాదు. ల్యాప్టాప్లో EC2 ఇన్స్టాన్స్ ఎప్పటికీ వారసత్వంగా పొందని టన్నెల్ ఉంది, మరియు RDSలో «ప్రైవేట్» అంటే డేటాబేస్కు పబ్లిక్ ఎండ్పాయింట్ లేదు అని, మానవ VPN వినియోగదారులే ఏకైక అనుమతించిన కాలర్లు అని కాదు. అప్లికేషన్కు దాని స్వంత అధికృత మార్గం, భద్రతా సమూహంతో దాని స్వంత సంబంధం మరియు డేటాబేస్లో దాని స్వంత గుర్తింపు అవసరం, మరియు ఈ మూడింటిని ఎంచుకునే క్రమం డీబగ్గింగ్లో ఎక్కువ భాగాన్ని ఆదా చేస్తుంది. ముందుగా మార్గాన్ని నిర్ణయించండి, తర్వాత అనుమతులు, తర్వాత మీ డెస్క్ నుండి కాకుండా డిప్లాయ్ చేసిన పరిసరం నుండి ధృవీకరించండి.

ల్యాప్టాప్ VPN అప్లికేషన్ మార్గం కాదు

సిబ్బంది VPN ప్రజలకు ఏమి చేసినా, ఆ ఇన్స్టాన్స్ అదే నెట్వర్క్ మార్గంలో స్పష్టమైన భాగం కాకపోతే అది ఇన్స్టాన్స్కు ఏమీ చేయదు. ప్రైవేట్ సబ్నెట్లోని EC2 ఇన్స్టాన్స్ VPC రూటింగ్, భద్రతా సమూహాలు మరియు నెట్వర్క్ ACLల ద్వారా RDSను చేరుకుంటుంది. అది మానవ టన్నెల్, మానవ సెషన్ లేదా మానవ ఆధారాలను వారసత్వంగా పొందదు, పొందకూడదు: పర్యవేక్షణ లేని అప్లికేషన్ కనెక్టివిటీ మరియు సిబ్బంది రిమోట్ యాక్సెస్ స్వతంత్రంగా నిర్వహించబడాలి.

ఈ స్వాతంత్ర్యం ఒక లక్షణం. VPN డౌన్ అయినప్పుడు అప్లికేషన్ పని కొనసాగిస్తుంది. అప్లికేషన్ తప్పుగా ప్రవర్తించినప్పుడు ఎవరూ తమ రిమోట్ యాక్సెస్ను కోల్పోరు. రెండింటినీ ఒకే మార్గంలో విలీనం చేసే డిజైన్లు సాధారణంగా ఒక సంఘటన సమయంలో, అత్యంత చెడ్డ క్షణంలో కనుగొనబడతాయి.

నిర్ణయం 1: అదే VPC, నేరుగా మార్గం

అప్లికేషన్ మరియు డేటాబేస్ ఒకే VPCలో నేరుగా రూటింగ్తో మరియు వాటి మధ్య ఎటువంటి తనిఖీ మధ్యవర్తి పరికరం లేకుండా ఉన్నప్పుడు, మార్గం సరళంగా ఉంటుంది మరియు భద్రతా సమూహ సూచన అందుబాటులో ఉన్న అత్యంత శక్తివంతమైన సాధనం. అప్లికేషన్కు దాని స్వంత సమూహాన్ని ఇవ్వండి, తర్వాత చిరునామా పరిధి నుండి కాకుండా ఆ సమూహం నుండి డేటాబేస్ పోర్ట్కు అనుమతి ఇవ్వండి:

aws ec2 authorize-security-group-ingress --group-id sg-0db123   --protocol tcp --port 5432 --source-group sg-0app456

aws rds describe-db-instances --db-instance-identifier prod-db   --query 'DBInstances[0].{Endpoint:Endpoint.Address,Port:Endpoint.Port,Public:PubliclyAccessible,Groups:VpcSecurityGroups}'

పోర్ట్ ఉదాహరణ మాత్రమే మరియు ఇంజిన్తో సరిపోలాలి. సమూహ సూచన అప్లికేషన్ ఇన్స్టాన్స్ల నుండి ట్రాఫిక్ను అధికృతం చేస్తుంది; అది వాటి నియమాలను కాపీ చేయదు మరియు డేటాబేస్ లాగిన్ను సృష్టించదు. రెండు వేర్వేరు సమస్యలు, రెండు వేర్వేరు పరిష్కారాలు.

తర్వాత మీరు ఇప్పుడే జోడించిన నియమం వద్ద ఆగకుండా మార్గంలోని మిగిలిన భాగాన్ని తనిఖీ చేయండి. అప్లికేషన్ యొక్క అవుట్బౌండ్ విధానం, డేటాబేస్కు జోడించిన సమూహాల పూర్తి సెట్, సబ్నెట్ రూట్ పట్టికలు మరియు ఏదైనా నెట్వర్క్ ACL అన్నీ సరిపోలాలి. భద్రతా సమూహ నియమాలు స్టేట్ఫుల్, అయితే కస్టమ్ నెట్వర్క్ ACL అభ్యర్థన మరియు తిరిగి వచ్చే ట్రాఫిక్ను వేర్వేరు నియమాలలో అనుమతించాలి, తాత్కాలిక పోర్టులతో సహా. కొత్త సన్నని డేటాబేస్ నియమం ఇప్పటికే జోడించిన పాత విస్తృత అనుమతిని కూడా రద్దు చేయదు.

నిర్ణయం 2: మరో VPC లేదా మరో ఖాతా

అప్లికేషన్ మరో VPCలో ఉంటే, నెట్వర్క్ యజమానులు మద్దతు ఉన్న ప్రైవేట్ అనుసంధానాన్ని ఎంచుకుంటారు: peering, ట్రాన్సిట్ డిజైన్ లేదా పంచుకున్న VPC ఏర్పాటు. అప్పుడు రూటింగ్ యొక్క రెండు దిశలు ఉండాలి, పేరు పరిష్కారం RDS ఎండ్పాయింట్ కోసం పని చేయాలి, మరియు డేటాబేస్ విధానం మూల్యాంకనం చేసే మూలం నిజంగా వచ్చే దానితో సరిపోలాలి. ఖాతా పేర్లు సరిపోలడం లేదా పంచుకున్న బిల్లింగ్ సంబంధం వీటిలో ఏదీ అందించదు.

భద్రతా సమూహ సూచన మారే భాగం. ఇది అనేక ప్రైవేట్ అనుసంధాన డిజైన్లలో పని చేస్తుంది, కానీ మధ్యవర్తి పరికరం మూలాన్ని తిరిగి రాసిన లేదా కనెక్షన్ను ముగించిన క్షణంలో పని చేయడం ఆపేస్తుంది, ఎందుకంటే అప్పుడు డేటాబేస్ మీ అప్లికేషన్ సమూహానికి బదులుగా మధ్యవర్తిని చూస్తుంది. RDS VPC సందర్భాలు ఒకే VPC లోపల యాక్సెస్ను ఇతర ఏర్పాట్ల నుండి వేరు చేస్తాయి, మరియు ఒక నియమ శైలి బదిలీ అవుతుందని ఊహించే ముందు మీ నిర్దిష్ట టోపాలజీని వాటితో తనిఖీ చేయడం విలువైనది.

తప్పిపోయిన మార్గాన్ని డేటాబేస్ను పబ్లిక్గా యాక్సెస్ చేయగలిగేలా చేయడం ద్వారా పరిష్కరించవద్దు. అది వేరే యజమానితో వేరే ఎక్స్పోజర్ నిర్ణయం, మరియు సాధారణంగా పరిణామానికి అత్యంత దూరంగా ఉన్న వ్యక్తి దాన్ని సూచిస్తాడు.

నిర్ణయం 3: డేటాబేస్ ఏ గుర్తింపును అంగీకరిస్తుంది

నెట్వర్క్ యాక్సెస్ మరియు డేటాబేస్ ప్రామాణీకరణ వేర్వేరు పొరలు, వాటిని కలపడం అత్యంత దారి తప్పించే లోపాలను సృష్టిస్తుంది. ఇన్స్టాన్స్ పాత్ర AWS APIలను పిలవడానికి AWS గుర్తింపు. అది డేటాబేస్ వినియోగదారు కాదు. IAM డేటాబేస్ ప్రామాణీకరణ ఇంజిన్ మరియు కాన్ఫిగరేషన్ అనుమతించిన చోట మద్దతు ఉన్న లక్షణం, మరియు అది ఇప్పటికీ డేటాబేస్ వినియోగదారుకు మ్యాపింగ్, దాని ప్రత్యామ్నాయం కాదు.

అప్లికేషన్ కాన్ఫిగరేషన్లో ఒక వెతుకుడు నుండి పట్టుకున్న చిరునామాకు బదులుగా RDS ఎండ్పాయింట్ పేరును ఉపయోగించండి. Multi-AZ ఫెయిల్ఓవర్ ఆ పేరు వెనుక ఉన్న చిరునామాను మారుస్తుంది, IPకి పిన్ చేయబడిన అప్లికేషన్ అది అవసరమైన సరైన క్షణంలో విఫలమవుతుంది. లోపాన్ని మాయం చేయడానికి ఇంజిన్ TLS ధృవీకరణను నిలిపివేయడానికి బదులుగా దాన్ని ఆన్లో ఉంచండి, ఎందుకంటే ధృవీకరణ వైఫల్యం మీరు చేరుకున్న ఎండ్పాయింట్ గురించి ఏదో చెబుతుంది.

తర్వాత డేటాబేస్ ఖాతాకు అప్లికేషన్కు అవసరమైన కనీసాన్ని, అది నిజంగా ఉపయోగించే స్కీమాలో ఇవ్వండి. ఆ పని బోరింగ్, అది ఆడిట్ చేయదగినది, మరియు సంఘటన సమీక్ష అడిగే భాగం అదే.

డిప్లాయ్ చేసిన పరిసరం నుండి ధృవీకరించండి

ఇన్స్టాన్స్ నుండి లేదా అదే సమూహం, సబ్నెట్ మరియు పాత్రతో నడిచే పని నుండి పరీక్షించండి. నాలుగు వైఫల్యాలు ల్యాప్టాప్ నుండి ఒకేలా కనిపిస్తాయి మరియు అక్కడి నుండి సులభంగా వేరు చేయవచ్చు: పరిష్కరించబడని పేరు, సమయం ముగిసే కనెక్షన్, TLS ధృవీకరణ వైఫల్యం మరియు తిరస్కరించబడిన డేటాబేస్ లాగిన్. ప్రతి ఒక్కటి వేరే సరిహద్దును సూచిస్తుంది, మీకు ఏది ఉందో తెలుసుకునే ముందు డేటాబేస్ ఎక్స్పోజర్ను మార్చడం ఊహ.

psql "host=prod-db.abc123.eu-west-1.rds.amazonaws.com port=5432 dbname=app sslmode=verify-full" -c 'select 1'

ఇన్స్టాన్స్ నుండి కనెక్షన్ విజయవంతమై మీ డెస్క్ నుండి విఫలమైతే, అప్లికేషన్ మార్గం సరిగ్గా ఉంది మరియు సరిచేయవలసినది మీ యాక్సెస్. రెండింటి నుండి విఫలమైతే, ఆధారాల నుండి కాకుండా పైన ఉన్న సమూహం మరియు మార్గ తనిఖీల నుండి ప్రారంభించండి. ఆ ఒకే పోలిక ఈ టికెట్లు సృష్టించే ఎక్కువ గందరగోళాన్ని నిరోధిస్తుంది.